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

[Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>]

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.
> 
>>> +	/* fill in fifo if we have gpio-cs +	 * note that there have
>>> been rare events where the native-CS +	 * flapped for <1us
>>> which may change the behaviour +	 * with gpio-cs this does not
>>> happen, so it is implemented +	 * only for this case +	 */
> 
>> 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.

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html