On Fri, Jun 24, 2022 at 2:57 PM Piotr Oniszczuk <piotr.oniszczuk@xxxxxxxxx> wrote: > > > > > 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? 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. > > > 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?
