Pin the interrupt handler for the 16505 driver to a different core
I played with also trying to actually implement a pico-side buffer to
allow the pi to more easily catch up when/if it gets behind. However,
my implementation seemed to actually degrade performance, I suspect that
because whatever is causing the pi to get behind on reading from the
pico makes further reading dubious as well, so it is safer to just
drop the sample and move on. Not worth debugging right now.
This alone reduces packet drops by 3-5x (haven't checked things too
rigorously) when pushing using scp to copy a file over at ~10MB / sec.
Change-Id: I50799eb5aa45cd5f58a0d205b8c5c42c097477bd
Signed-off-by: James Kuszmaul <jabukuszmaul@gmail.com>
diff --git a/frc971/raspi/rootfs/chrt.sh b/frc971/raspi/rootfs/chrt.sh
index 535f4c6..d5edafe 100755
--- a/frc971/raspi/rootfs/chrt.sh
+++ b/frc971/raspi/rootfs/chrt.sh
@@ -35,3 +35,7 @@
chrtirq "irq/[0-9]*-vc4 crtc" -o 0
chrtirq "irq/23-uart-pl0" -o 0
chrtirq "irq/[0-9]*-eth0" -f 10
+
+# Route data-ready interrupts to the second core
+SPI_IRQ="$(cat /proc/interrupts | grep fe204000.spi | awk '{print $1}' | grep '[0-9]*' -o)"
+echo 2 > /proc/irq/"${SPI_IRQ}"/smp_affinity