On Mon, Nov 12, 2018 at 04:50:37PM +0000, Peter Rosin wrote: > On 2018-08-02 08:06, Peter Rosin wrote: > > On 2018-08-01 11:35, Russell King - ARM Linux wrote: > >> On Wed, Aug 01, 2018 at 11:01:12AM +0200, Peter Rosin wrote: > >>> I don't think it's a problem with the atmel I2C driver. IIRC, the > >>> tda998x driver issues the command a initiate the EDID read, but that > >>> times out. So it appears to be the TDA19988 that fails to read the > >>> EDID over the DDC bus? Which brings me to the double problem with the > >>> scopes mentioned above... > >> > >> It sounds like it. > >> > >> It may be helpful to know that there are HDMI pass-through boards > >> available that give access to all the HDMI signals: > >> > >> https://elabbay.myshopify.com/collections/camera > >> https://elabbay.myshopify.com/collections/camera/products/hdmi-af-af-v1a-hdmi-type-a-female-to-hdmi-type-a-male-pass-through-adapter-breakout-board > >> > >> I've never bought from them, so please don't take this as a > >> recommendation - the fact that there seems to be no company details > >> on their site doesn't seem good, and as the whois for elabbay.com is > >> obscured also doesn't give me any confidence to buy from them. > > > > I still will not be able to inspect the DDC bus between the TDA19988 > > and the buffer circuit (IP4786), but the gadget seems useful enough and > > it's not a shitload of money. We'll see how long it takes for it to get > > here... > > > > Thanks for the pointer! Maybe :-) > > I got the pass-through board a while back, and that board works as expected > and there was no problem with ordering etc. What I could see with that was > that the TDA19988 was able to initiate a start condition (SDA -> low) but > then nothing more happened. > > Then last week, someone noticed that even though the TDA19988 is driven by > 1.8V, it still needs the high signals of the DDC bus to be above 3V, which > was unexpected and not catered for by the design. Changing VCC(SYS) of the > buffer circuit in place (IP4786, pin 27) to 3.3V fixed the issue and EDID > reading works, and this was confirmed earlier today. > > So, the problem was that the TDA19988 only ever saw "low" DDC signals, and > probably aborted when the bus appeared busy. Or something. Thanks for following up on this issue. Normally, if a master device sees that the I2C clock is being held low, it assumes that a slave is "clock stretching" and it will wait until it is raised. I wonder if that's what is causing this issue here. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
