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

Sat Jun 25 14:00:48 UTC 2022

On Sat, Jun 25, 2022 at 9:18 AM Piotr Oniszczuk
<piotr.oniszczuk at gmail.com> wrote:
>
>
>
> > 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 :-(

On Rockchip devices, pinctrl and gpio are separate blocks. Even if you
enable gpio, the pinctrl will still be assigned to the underlying
device. You need to change the pinctrl assignment to another device.
What was the result of your read of the register?

>
> >
> >>
> >>> 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?
>
>

The first issue you have is the TV isn't responding until the absolute
end. This strikes me as a signal integrity issue. Do you have an
oscilloscope (not a logic analyzer, you need voltages and ramp times)
to compare the working vs non-working signals? Check both sides of the
level shifter.

You can try bumping the drive levels for the m1 pin as well.

The m1 pin lives in the pmuio domain, whereas the other devices live
in the normal domain. That could be affecting the signal strength.