> Wiadomość napisana przez Peter Geis <pgwipeout@xxxxxxxxx> w dniu 25.06.2022, o godz. 01:50: > > 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. 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?
