[PATCH v2 0/7] tda998x: allow use with bridge based devices

[Russell King - ARM Linux]

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