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

[Piotr Oniszczuk <piotr.oniszczuk@gmail.com>]

> Wiadomość napisana przez Peter Geis <pgwipeout@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?  
 
> 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