[PATCH v11 20/24] arm64: dts: rockchip: enable vop2 and hdmi tx on rock-3a

Sat Jun 25 06:18:23 PDT 2022

> Wiadomość napisana przez Peter Geis <pgwipeout at gmail.com> w dniu 25.06.2022, o godz. 01:50:
> 
> On Fri, Jun 24, 2022 at 2:57 PM Piotr Oniszczuk
> <piotr.oniszczuk at gmail.com> wrote:
>> 
>> 
>> 
>>> Wiadomość napisana przez Peter Geis <pgwipeout at gmail.com> w dniu 24.06.2022, o godz. 14:40:
>>> 
>>>> 
>>>> Sascha, Peter
>>>> 
>>>> I returned to trying to find why hdmi-cec is not working on rock3-a v1.31 hw.
>>>> 
>>>> I'm on vop2 v11 on 5.18 mainline.
>>>> 
>>>> Current findings:
>>>> 
>>>> (1) the same sw. stack/binaries works on rock-3b (where cec uses hdmitx_m0 instead of hdmitx_m1 I/O line);
>>>> 
>>>> (2) gpio-cec however works no problem on rock3-a;
>>>> 
>>>> (3) monitoring cec messages with v4-utils 'cec-follower -s' shows exact the same events in non-working rock3-a and working rock3-b
>>>> (tested by issue configure cec by 'cec-ctl -d /dev/cec0 --phys-addr=1.0.0.0 --playback' command)
>>> 
>>> --phys-addr isn't a valid command for this controller. The device
>>> designation is only required if you have more than one cec device.
>>> 
>>>> 
>>>> --> i'm interpreting this as confirmation that low level phy layer receives ok cec data from connected device on non-working rock3-a;
>>>> 
>>>> (4) debug sysfs for cec shows "has CEC follower (in passthrough mode)" for working rock-3b and there is NO "has CEC follower" debug message in failing rock3-a.
>>> 
>>> This makes me suspect you are in fact not using the same software
>>> stack, or are not running the same commands.
>> 
>> It was the same SD card - with only DT declaration changed in boot.scr
>> Such SD card has cec perfectly working in rock3b
>> 
>>> Running `cec-follower -v -m -T` on a rk3566 device with working cec
>>> using 5.19-rc1, I see no mention of cec-follower in the debugfs cec0
>>> status entry.
>>> 
>>>> 
>>>> For me It looks like low-level hdmi-cec works ok on failing rock3-a - but upper layers (in hdmi vop2?) are not registering (or failing to register) cec-follower filehandle. This happens just when hdmitx I/O in DT is changed from hdmitx_m0 to hdmutx_m1. A bit strange - but all my tests consistently confirming this observation....
>>> 
>>> There is nothing wrong with vop2 as it is not involved at all in this.
>>> The rockchip hdmi driver (which is not specific to vop2) does nothing
>>> more than call the cec registration method in the dw hdmi bridge
>>> driver, which then calls the kernel cec registration functions.
>>> Changing pinmux changes nothing in how this functions.
>>> 
>>>> 
>>>> I'm too weak in kernel cec internals - so maybe you have any pointers how to further debug/investigate this issue?
>>> 
>>> As we discussed in the pine64 room, this is still very likely a
>>> hardware issue with this board. A configuration issue with your u-boot
>>> or tf-a is also a possibility, but is less likely.
>>> 
>>> You showed with your logic analyzer with nothing plugged in and cec
>>> not muxed to m1, data was present on m1.
>> 
>> Issue of presence of data on m1 with nothing plugged was mistake from my side: wrong board pin used to connect logic analyser GND.
>> After correctly connecting GND - all is ok (no any unexpected data; pulses appears only after cec commands; pulses timings are ok so cec protocol analyser shows reasonable data; no cec timing errors reported by protocol analyser).
>> 
>> 
>>> I requested you investigate
>>> the following, to which you haven't replied:
>>> Have you tried forcing m0 to be assigned to a device other than hdmi-cec?
>> 
>> I'm a bit lost here: v1.31 hw uses m1 and m0 is unused.
>> Is you idea to verify that m0 is not used by hdmi-cec - even when m1 is declared for hdmi-cec in DT?
>> May you pls hint me with any example of DT snippet for Your m0 assignment idea?
> 
> As pinctrl is only assigned when a device explicitly requests it in
> the kernel driver, it is possible to have multiple pinctrl pins
> assigned to a single device if it was left that way by previous
> software or userspace has fun with it. Such as both the m0 and m1 pins
> are assigned to the cec-controller. Such a case is broken.
> 
> You can assign the m0 pin to another device explicitly, but before
> doing so I'd read the register manually just to see if it. For example
> that pin also is the spi3m1_cs1 pin.

So done test where I assigned m0 for gpio-cec.
2nd cec device appeared.
But this changed nothing regarding hdmi-cec.  Sill dead :-(

> 
>> 
>>> Have you checked if m1 is shorted to another pin?
>> 
>> Yes. Looks ok for me.
>> (as radxa debian has working ok hdmi-cec i think hw is ok)
>> 
>>> 
>>> In regards to your data frames for 4.19 vs 5.18, image-view-on is not
>>> a valid command if the topology doesn't detect a device on the bus.
>>> I recommend running the same test, except run `cec-ctl -S --playback`
>>> and post the results for both.
>> 
>> Pls find results for command `cec-ctl -S --playback`:
>> 
>> 1.  radxa ubuntu 4.19 bsp:
>> logic analyser cec proto decoded + timings: https://pastebin.com/hHPmKv4i
>> FYI logic analyser output (first 350msec): https://paste.pics/63cb4dc7f9b51d8825d377b45bf71ae4
>> 
>> 2. mainline 5.18.6:
>> logic analyser cec proto decoded + timings: https://pastebin.com/YYDUY4x1
>> FYI logic analyser output (first 350msec): https://paste.pics/0d894b8ceba164dc6d743f8044c7e01e
>> 
>> 
> 
> Now this is interesting, the TV is responding in both cases. The TV
> does not show up at all in the return sequence in case 2?

So I started to compare `cec-ctl -S --playback`on rock3a and rock3b - but this time after cold reboots of: TV and board. 

overview of whole comm: 
working OK rock3-b ( https://pastebin.com/ffthT5UQ )
non-working rock3-a ( https://pastebin.com/Qdn71qwS )

First difference i see is idle/no idle between cec commands:
non-working: https://paste.pics/bb1616312d1f75b8808aff30f186ed76
working: https://paste.pics/96d96f4950f4d87defbfd8172819de2d

i.e.
working: has 20ms idle before opcode 0xA6 https://paste.pics/346f482310baa0d6ed0a3d5b2e820e09
while non-working has no any idle https://paste.pics/640ee190e0d501d4fc9b05c746a68502
data in frames is the same

or
working: has 20ms idle before opcode 0x84 https://paste.pics/93cb7c3cd72ab0f91c9a5b6ff24cadf3
while non-working has no any idle https://paste.pics/e9afed93f5b3acf6e11aa00d390d52bc
data in frames is the same

for opcode 0x87 data in frames is also the same

generally:
working has always around 16..20ms of idle between commands while non-working has no any idles.  

How this is possible that changing m0->m1 changes timings in such way?   