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