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

[Martin Sperl <kernel@xxxxxxxxxxxxxxxx>]

> On 31.03.2015, at 05:16, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
> 
> I can understand perfectly why the code fills the FIFO before enabling
> interrupts; it avoids having to immediately service an interrupt simply
> to fill the FIFO.
> 
> However, I'm not sure why this is in any way related to whether the
> chip-select GPIO is valid. Surely we always want to do this? How does
> the mechanism used to control chip selects influence whether we want to
> pre-fill the FIFO?

During the time I was building a DMA only driver I saw "rare" glitches
in the CS line when using native CS. The "glitch" is that the CS drops
to inactive for a short period of time - typically 1 sample length at
10MHz sample rate, so <0.1us.

These "glitches" also once have been observed with the current driver
when using native-CS, so I think it is prudent to avoid native-CS when
enabling this optimization.

Hence this limitation or maybe even the full move to GPIO-CS for all.
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html