В общем, есть проект на iMX6q (на модуле Kontron), где бежит ядро 3.10.17 взятое из yocto c BSP 1.5. В этом ядре драйвер SPI пропатчен чтобы включить поддержку slave режима (патч сделан на основе патча для ltib ядра 3.0 найденного на просторах freescale community сайта) Этот проект цепляется к SPI мастеру и получает от оного данные блоками фиксированной длинны, CS остается активным все время передачи блока.
Теперь, внимание, проблема! Если получать данные максимально быстро, то уже в первом слове второго блока уходит крайнее слово первого блока (ну и, естественно, все тут же ломается). В конце каждого трансфера читаются счетчики для обоих FIFO и они всегда нулевые, так что это не забытые данные в TX FIFO. Логический анализатор показывает, что в шину одно и тоже слово уезжает дважды (то есть как бы подтверждает вышенаписанное), так что это не проблема мастера, преждевременно снимающего тактовую. Самое интересное тут заключается в том, что если между трансферами внести задержку в, примерно, 300 мкс, то проблема уходит. Если попытаться заресететь SPI блок между трансферами, то в качестве первого слова втророго блока уйдут нули. Но если же подождать 300 мкс, то все работает как и должно (кто бы сомневался) В общем, риторический вопрос кто виноват и что делать? Риторический потому, что глюкавость SPI у фрискейла суть всем известна и это все как бы указывает на баг в чипе, но все же.