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

From: peda@axentia.se (Peter Rosin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/7] tda998x: allow use with bridge based devices
Date: Mon, 12 Nov 2018 16:50:37 +0000	[thread overview]
Message-ID: <fd70023a-815b-697a-d01f-6ae9efb83653@axentia.se> (raw)
In-Reply-To: <1ad8d087-40a8-7a00-31cf-c4d34a9a12fb@axentia.se>

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.

If anyone cares...

Cheers,
Peter