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 <Chris.Brandt@xxxxxxxxxxx> 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
