On 04/07/2015 12:25 AM, Martin Sperl wrote:
On 06.04.2015, at 19:21, Mark Brown <broonie@xxxxxxxxxx> 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.
--
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
