we can now recover from an I2C timeout and get the PMIC data
out, but mysteriously, when we leave the routine, the CPU hangs.
I think fundamentally the I2C instability is due to something
very wonky inside the chip itself, so the recovery only papers
over an issue that is only fixed with a reboot...
Got up to version 8 to decode, although version 8 is a bit fussy.
Fairly sensitive to camera focal distance - hard to see focus
issues on B/W display. This needs to be improved in the HW.
There is a hardware bug that causes SPIM RX packets to fail when
the UDMA bus is busy (like when streaming video). This causes
swap memory to fail because it relies on the SPIM bus.
This patch causes the video to sample *after* any computation
happens, so that any swap memory that might be hit taken care of.
This reduces the efficiency of the loop somewhat, because without
the decongesting, we could kick off the camera read and do useful
computation while the camera streamed data. Now we have to keep
them separate to work around this bug.
hope to trim this down a bit - using rqrr to do some back
end processing but after intiial evaulation the right path
is probably going to be fork and slim down the code, which
is fine by me.
The USB hardware stack is different enough that I think it
doesn't make sense to wedge it into the existing USB driver.
Instead it will be a separate driver that has the same `lib` level
API calls, but a totally different implementation underneath.
This allows us to make better architectural decisions that will
make the USB stack more reliable because the hardware has some
pretty strict latency requirements on responding to packets that
can't be met with the previous abstraction.
