Re: [PATCH 2/2] spi: pxa2xx: Fix too early chipselect deassert

[Robert Jarzmik <robert.jarzmik@xxxxxxx>]

Jarkko Nikula <jarkko.nikula@xxxxxxxxxxxxxxx> writes:

> There is a chance that chipselect is deasserted too early while the last
> clock cycle is still running. Protocol analyzers will see this as a failed
> last byte. This is more likely to occur with slow bitrates, for instance
> at 25 kbps.
>
> Reason for this is when using SPI mode 0 that both SPI host controller and
> SPI slave will drive the data lines at the falling edge of clock signal
> and sample at the rising edge. Receive FIFO gets the last bit now at the
> rising edge and code sees transfer to be finished either by the interrupt
> in PIO mode or by the DMA completion in DMA mode.
>
> The SSP Time Out register SSTO should take care of delaying the
> completion but it does not seems to have effect at least on Intel
> Skylake and Broxton even when using long enough values. Depending on
> timing code may get into point where chipselect is deasserted while the
> last clock cycle is still running at its second half cycle.
>
> Fix this by adding a wait loop in giveback() that waits until SSP becomes
> idle before deasserting the chipselect.
>
> Reported-by: Weifeng Voon <weifeng.voon@xxxxxxxxx>
> Signed-off-by: Jarkko Nikula <jarkko.nikula@xxxxxxxxxxxxxxx>
> ---
> For normal development cycle. This is not a fatal issue and I guess real SPI
> slaves may not hickup because of it. But you never know.

I feel quite nervous about this one, as it will affect all pxa variants, for a
Skylake and Broxton issues.

What makes me even more nervous is that I don't have a way to test it yet ...

I will neither ack nor block it, let's have others judge it first.

Cheers.

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