[PATCH 3/6] spi: bcm2835: fill FIFO before enabling interrupts to

[Stephen Warren]

On 04/07/2015 12:25 AM, Martin Sperl wrote:
>
>> On 06.04.2015, at 19:21, Mark Brown <broonie at kernel.org> wrote:
>> Right, and I have to say I do suspect that the underlying thing is that
>> the FIFO is underrunning, but as far as the optimization is concerned
>> that's a separate thing.  The reason this isn't enabled for native chip
>> selects is that it's not working, the reason it's not working is
>> something that should indeed probably be investigated.
 >
> Actually it happens exactly when setting the CS-register with the
> interrupt flags enabled - typically observed in the middle of a transmit
> of a byte the CS jumps, but the clock and data continue the transfers
> correctly
>
> As the CS register contains the interrupt flags as well as the
> control for the native-chip-selects this is impacting the chip select
> lines in native mode.

Is the driver simply programming the HW incorrectly then? I would expect 
the driver to do something roughly like:

* Set up the HW to execute the transaction; everything except enabling 
IRQs and telling the HW to "go"
* Clear stale IRQ status (perhaps do this right at the start)
* Enable IRQs
* Tell the HW to "go"

... then not touch any CS-related register for the entire transfer. 
There shouldn't be a need to enable/disable IRQs during the transfer; 
just leave them enabled the entire time, until all bytes have been 
transferred.