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

[Peter Geis]

On Fri, Jun 24, 2022 at 4:30 AM Piotr Oniszczuk
<piotr.oniszczuk at gmail.com> wrote:
>
>
>
> > Wiadomość napisana przez Piotr Oniszczuk <piotr.oniszczuk at gmail.com> w dniu 14.05.2022, o godz. 15:58:
> >
> >
> >
> >> Wiadomość napisana przez Peter Geis <pgwipeout at gmail.com> w dniu 09.05.2022, o godz. 18:00:
> >>
> >> If you want to confirm the hardware is configured correctly you can
> >> remove the cec pin from the hdmi node and set up a cec-gpio node.
> >> https://elixir.bootlin.com/linux/v5.18-rc5/source/Documentation/devicetree/bindings/media/cec-gpio.txt
> >
> > Peter, Sascha
> >
> > I configured cec-gpio and can confirm: with gpio cec works on my rock3-a board v1.31.
> >
> > So summarising my tests:
> >
> >                                        rock3-a v1.1   rock3-a v1.31   rock3-b
> >
> > radxa debian:                               ok             ok                ok
> >
> > other ppl mainline 5.18:               ok             n/t                n/t
> >
> > me with mainline 5.18:                 n/t            nok              ok
> >
> > me with mainline 5.18 gpio-cec:  n/t             ok                n/t
> >
> > Non-working combination is: rock3-a v1.31 hw on mainline 5.18.
> > For me it looks like there is bug in case when rk3568 using cec on hdmitxm1_cec line.
> > (The same binaries working ok on my rock3-b where cec is on hdmitxm0_cec line. It also works on Peter's rock3a v1.1 - which also uses hdmitxm0_cec line).
> >
> > It looks like upper cec driver can talk to lower driver (dw-hdmi?) but nothing is received from lower driver, as my app says:
> > CECAdapter: CEC device can't poll TV: TV does not respond to CEC polls
> >
> > btw: I verified with oscilloscope connected to hdmitxm1_cec line: starting cec-compliance -v -T shows expected series of 0V pulses on hdmitxm1_cec line....
> >
> >
>
> 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.
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. 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?
Have you checked if m1 is shorted to another pin?

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.

>
>
>
> BTW: i'm not alone with cec issue on rock3a v1.31 - already 2 other users contacted me with the same issue...
>
>