Delay between stop condition and start condition

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Wolfram,

While working out what's needed to add HDMI support to the iwg23s from iWave I have stumbled across a problem with the HDMI transmitter (SiI9022ACNU). Such an HDMI transmitter has a DDC pass through mode that allows the SoC to talk directly to the monitor (to allow the SoC to read the EDID back from the monitor, for example). While in this working mode, if the SoC generates a start condition too close to the previous stop condition, then the monitor will miss the start condition, alongside a clock cycle. The consequences of this may be catastrophic, as you can imagine. I have attached a picture of a trace grabbed with my logic analyser, where SDA and SDL are related to the I2C bus between the SoC and the HDMI transmitter, while DDCT_SDA and DDCT_SCL (digital and analogic traces) are related to the I2C bus connecting the HDMI transmitter to the monitor.

What's the best way to address this? I could pull in the HDMI transmitter driver the code to read the EDID back from the monitor so that I can fit device specific delays without impacting the generic implementation of the EDID readback, but that would replicate some code and the driver would not benefit from fixes made to the generic implementation. I could change the RCar I2C driver in order to fit a new DT parameter (i2c-delay-after-stop-us?), and the driver would put in the desired delay after every stop condition, but isn't this parameter something every I2C controller would benefit from (now that we know we have a use case for it)? What are your thoughts and recommendations?

Thanks,
Fab



Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.

Attachment: bug.png
Description: bug.png


[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux