That makes sense and there's not much that can be done to fix it so back to working out the delay between bytes. :)
On 6 August 2016 at 01:40, Chris Brandt <[email protected]> wrote: >> The issue with the CS being held low so long makes me think there is a >> little bit more to it. > > If you look at function rspi_setup, you'll see that bit SPCMD_SSLKP is set so > the CS will stay low after every transfer until SW comes back in and manually > puts it back high. > I would guess the delay you are seeing there is a kernel scheduling delay of > letting the driver resume running again after the wait_event_timeout call. > > > Chris
