On Mon, Nov 21, 2016 at 10:43:29AM +0000, Russell King - ARM Linux wrote:

On Mon, Nov 21, 2016 at 12:29:01PM +0200, Mika Westerberg wrote:

quoted

On Fri, Nov 18, 2016 at 07:35:42PM +0000, Russell King - ARM Linux wrote:

quoted

Another mitigation would be to lower the I2C bus frequency on Juno from
400kHz to 100kHz, so that there's 4x longer IRQ latency possible.
However, even that isn't going to be reliable - even going to 100kHz
isn't going to allow the above case to be solved - the interrupt is
delayed by around 2ms, and it takes about 1.4ms to send/receive 16 bytes
at 100kHz.  (9 * 16 / (100*10^3)).

So, I think all hope is lost for i2c-designware on Juno to cope with
reading the EDID from TDA998x reliably.

:-(

I wonder if we can get it work more reliably by using DMA (provided that
there are DMA channels available for I2C in Juno)? That would allow the
hardware to perform longer reads without relying on how fast the
interrupt handler is able to empty the Rx FIFO.

It would need to DMA to the Tx FIFO to keep it filled - it triggers the
stop condition when the Tx FIFO empties.  From what I can see in the
driver, the Tx FIFO not only takes the data but also a "command" to tell
the hardware what to do.

Yes, the command is either "read" or "write" (meaning even for Rx a
write to the Tx FIFO is needed).

The Rx FIFO would also need DMA to avoid it overflowing due to high
interrupt latency.

I guess for Rx we would need to supply a dummy buffer of "read" commands
for the Tx FIFO in addition to reading bytes from Rx FIFO. But still
that might help to improve reliability in case of Juno.

I don't know what state DMA is in on the Juno, or even whether it has
DMA - it has a PL330 DMA controller, but I see nothing in the DT files
making use of it.

OK