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

[Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]

On Sat, Apr 04, 2015 at 07:49:41PM -0600, Stephen Warren wrote:
> On 03/30/2015 11:25 PM, Mark Brown wrote:
> > On Mon, Mar 30, 2015 at 09:16:21PM -0600, Stephen Warren wrote:
> >> On 03/29/2015 08:03 AM, Martin Sperl wrote:

> >>> There have been rare cases where short (<200ns) chip-select
> >>> switches with native CS have been observed during such
> >>> operation, this is why this optimization is only enabled for
> >>> GPIO-CS.

> >> 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?

> > I think both the comment and the commit message answer that
> > question - something triggers spurious chip select changes?

> I must admit I don't feel either the commit message or the comment
> explain the situation. They certainly state that there are glitches in
> the "native CS" case, but that doesn't *explain* them. It seems more
> likely the under-filling the FIFO would cause periods where the FIFO
> was empty which would be aout the only case I could naively think of
> for the CS to be de-asserted. More investigation would be useful.

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]