| Message ID | 20220422072841.2206452-21-s.hauer@pengutronix.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | drm/rockchip: RK356x VOP2 support | expand |
> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 22.04.2022, o godz. 09:28: > > From: Michael Riesch <michael.riesch@wolfvision.net> > > Enable the RK356x Video Output Processor (VOP) 2 on the Radxa > ROCK3 Model A. > > Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net> > Reported-by: kernel test robot <lkp@intel.com> > Link: https://lore.kernel.org/r/20220310210352.451136-4-michael.riesch@wolfvision.net > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> > --- Sascha, Michael, I'm using v11 series on 5.18-rc5 on rk3566 tvbox with great success. Recently i started to work on rock3-a (rk3568). v11 gives me video, audio - but cec is not working on rock3-a. I was told: 32k clock needed for cec and this clock is generated by the rtc which is embedded in the rk8xx regulator. So you should make sure it is enabled when hdmi is powerd on, eg adding it to the RK3568_PD_VO powerdomain should help I was trying to do this in dts https://pastebin.com/67wu9QrH but cec is still non-functional Maybe You have some hints/pointers here? br btw: my dts gives me working usb2 port0/port1 and usb3 port0. but usb3 port1 is non-working maybe you know what is missing?
On Sun, May 8, 2022 at 9:40 AM Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote: > > > > > Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 22.04.2022, o godz. 09:28: > > > > From: Michael Riesch <michael.riesch@wolfvision.net> > > > > Enable the RK356x Video Output Processor (VOP) 2 on the Radxa > > ROCK3 Model A. > > > > Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net> > > Reported-by: kernel test robot <lkp@intel.com> > > Link: https://lore.kernel.org/r/20220310210352.451136-4-michael.riesch@wolfvision.net > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> > > --- > > Sascha, Michael, Good Afternoon, > > I'm using v11 series on 5.18-rc5 on rk3566 tvbox with great success. > Recently i started to work on rock3-a (rk3568). > v11 gives me video, audio - but cec is not working on rock3-a. > > I was told: > > 32k clock needed for cec and this clock is generated by the rtc which is embedded in the rk8xx regulator. > So you should make sure it is enabled when hdmi is powerd on, eg adding it to the RK3568_PD_VO powerdomain should help > > I was trying to do this in dts https://pastebin.com/67wu9QrH but cec is still non-functional > > Maybe You have some hints/pointers here? Add the following to the HDMI node: assigned-clocks = <&cru CLK_HDMI_CEC>; assigned-clock-rates = <32768>; The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to function. I submitted a patch to have the hdmi driver handle this, but it broke other SoCs because 32k is an optional clock. Since this is the case, I'd like Robin to weigh in on going the assigned-clock route again. > > br > > btw: my dts gives me working usb2 port0/port1 and usb3 port0. but usb3 port1 is non-working > maybe you know what is missing? You're missing &usb2phy0_otg. Very Respectfully, Peter Geis
> Wiadomość napisana przez Peter Geis <pgwipeout@gmail.com> w dniu 08.05.2022, o godz. 18:53: > >> >> I was trying to do this in dts https://pastebin.com/67wu9QrH but cec is still non-functional >> >> Maybe You have some hints/pointers here? > > Add the following to the HDMI node: > assigned-clocks = <&cru CLK_HDMI_CEC>; > assigned-clock-rates = <32768>; I think i have this already (pls see L231/L232 in https://pastebin.com/67wu9QrH ) > >> >> br >> >> btw: my dts gives me working usb2 port0/port1 and usb3 port0. but usb3 port1 is non-working >> maybe you know what is missing? > > You're missing &usb2phy0_otg. Maybe i miss something but adding: &usb2phy0_otg { phy-supply = <&vcc5v0_usb_host>; status = "okay"; }; breaks working usb3 port0 (so none of usb3 ports are working)
On Sun, May 8, 2022 at 1:36 PM Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote: > > > > > Wiadomość napisana przez Peter Geis <pgwipeout@gmail.com> w dniu 08.05.2022, o godz. 18:53: > > > >> > >> I was trying to do this in dts https://pastebin.com/67wu9QrH but cec is still non-functional > >> > >> Maybe You have some hints/pointers here? > > > > Add the following to the HDMI node: > > assigned-clocks = <&cru CLK_HDMI_CEC>; > > assigned-clock-rates = <32768>; > > I think i have this already (pls see L231/L232 in https://pastebin.com/67wu9QrH ) I see you have hdmitxm1_cec as the enabled pin. Are you certain it's the m1 pin and not the m0 pin? > > > > >> > >> br > >> > >> btw: my dts gives me working usb2 port0/port1 and usb3 port0. but usb3 port1 is non-working > >> maybe you know what is missing? > > > > You're missing &usb2phy0_otg. > > Maybe i miss something but adding: > > &usb2phy0_otg { > phy-supply = <&vcc5v0_usb_host>; > status = "okay"; > }; > > breaks working usb3 port0 > (so none of usb3 ports are working) Please pass along a full dmesg in this configuration. > >
>> >> I think i have this already (pls see L231/L232 in https://pastebin.com/67wu9QrH ) > > I see you have hdmitxm1_cec as the enabled pin. Are you certain it's > the m1 pin and not the m0 pin? It depends on board ver. pls look: https://github.com/radxa/kernel/commit/c1d727692e85c0a265913a72e517cf2bd71131ba >> >> Maybe i miss something but adding: >> >> &usb2phy0_otg { >> phy-supply = <&vcc5v0_usb_host>; >> status = "okay"; >> }; >> >> breaks working usb3 port0 >> (so none of usb3 ports are working) > > Please pass along a full dmesg in this configuration. Here it is: https://pastebin.com/uArtBLaZ
On Sun, May 8, 2022 at 2:21 PM Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote: > > > >> > >> I think i have this already (pls see L231/L232 in https://pastebin.com/67wu9QrH ) > > > > I see you have hdmitxm1_cec as the enabled pin. Are you certain it's > > the m1 pin and not the m0 pin? > > It depends on board ver. > pls look: https://github.com/radxa/kernel/commit/c1d727692e85c0a265913a72e517cf2bd71131ba 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 For some reason the board developers decided to make this selectable, check the location of R90652 and R90653. > > >> > >> Maybe i miss something but adding: > >> > >> &usb2phy0_otg { > >> phy-supply = <&vcc5v0_usb_host>; > >> status = "okay"; > >> }; > >> > >> breaks working usb3 port0 > >> (so none of usb3 ports are working) > > > > Please pass along a full dmesg in this configuration. > > Here it is: https://pastebin.com/uArtBLaZ I have some concerns about the DTS you've built here. For instance how come you are modifying the power domains? USB3 is broken because the rock3-a is a rk3568 device and you're missing combophy0. > >
> > 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 > > For some reason the board developers decided to make this selectable, > check the location of R90652 and R90653. > Peter, my board is v1.31 and is using HDMITX_CEC_M1 i think. I verified this by temp. changing to HDMITX_CEC_M0 For M1: 2022-05-09 21:12:37.130188 I CECAdapter: Using physical address 1.0.0.0 from EDID 2022-05-09 21:12:37.173267 I CECAdapter: Found 1 CEC devices(s). 2022-05-09 21:12:37.173299 I CECAdapter: Device 1: path '/dev/cec0' com port 'Linux' SELECTED 2022-05-09 21:12:37.173307 I CECAdapter: Trying to open device /dev/cec0 (Linux). 2022-05-09 21:12:37.180095 I CECAdapter: connection opened 2022-05-09 21:12:37.545229 I CECAdapter: setting HDMI port to 1 on device TV (0) 2022-05-09 21:12:37.904145 I CECAdapter: >> source deactivated: Playback 1 (4) 2022-05-09 21:12:37.904311 I CECAdapter: Source 4 Deactivated 2022-05-09 21:12:38.284452 I CECAdapter: >> source activated: Playback 1 (4) 2022-05-09 21:12:38.284492 I CECAdapter: Source 4 Activated 2022-05-09 21:12:38.284694 I CECAdapter: CEC client registered: libCEC version = 6.0.2, client version = 6.0.2, firmware version = 0, logical address(es) = Playback 1 (4) , physical address: 1.0.0.0, git revision: v12.0.0-v32.0-16-g611cac15cc+59-07dc900~dirty, compiled on 2022-04-23 05:50:57 by piotro@/bin/sh: hostname: command not found on Linux 5.16.14-arch1-4 (x86_64), features: P8_USB, DRM, P8_detect, randr, Linux 2022-05-09 21:12:38.519394 I CECAdapter: Opened CEC device. 2022-05-09 21:12:38.636950 I CECAdapter: << powering on 'TV' (0) 2022-05-09 21:12:38.754023 E CECAdapter: Failed to turn TV on. 2022-05-09 21:12:38.754313 I CECAdapter: >> source activated: Playback 1 (4) 2022-05-09 21:12:38.754343 I CECAdapter: Source 4 Activated 2022-05-09 21:12:38.872079 I CECAdapter: << Playback 1 (4) -> broadcast (F): active source (1000) 2022-05-09 21:12:38.974698 I CECAdapter: Asked TV to switch to this input. 2022-05-09 21:13:07.292069 W CECAdapter: CEC device can't poll TV: TV does not respond to CEC polls 2022-05-09 21:13:37.296372 W CECAdapter: CEC device can't poll TV: TV does not respond to CEC polls for M0: 2022-05-09 21:37:47.632175 I CECAdapter: Using physical address 1.0.0.0 from EDID 2022-05-09 21:37:47.680618 I CECAdapter: Found 1 CEC devices(s). 2022-05-09 21:37:47.680644 I CECAdapter: Device 1: path '/dev/cec0' com port 'Linux' SELECTED 2022-05-09 21:37:47.680654 I CECAdapter: Trying to open device /dev/cec0 (Linux). 2022-05-09 21:37:47.694974 I CECAdapter: connection opened 2022-05-09 21:37:56.341846 I CECAdapter: setting HDMI port to 1 on device TV (0) 2022-05-09 21:38:17.675457 I CECAdapter: >> source activated: Playback 1 (4) 2022-05-09 21:38:17.675561 I CECAdapter: Source 4 Activated 2022-05-09 21:38:17.675657 I CECAdapter: CEC client registered: libCEC version = 6.0.2, client version = 6.0.2, firmware version = 0, logical address(es) = Playback 1 (4) , physical address: 1.0.0.0, git revision: v12.0.0-v32.0-16-g611cac15cc+59-07dc900~dirty, compiled on 2022-04-23 05:50:57 by piotro@/bin/sh: hostname: command not found on Linux 5.16.14-arch1-4 (x86_64), features: P8_USB, DRM, P8_detect, randr, Linux 2022-05-09 21:38:30.475336 I CECAdapter: Opened CEC device. 2022-05-09 21:38:34.741846 I CECAdapter: << Playback 1 (4) -> broadcast (F): active source (1000) 2022-05-09 21:38:39.008432 I CECAdapter: << powering on 'TV' (0) 2022-05-09 21:38:39.008506 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 2022-05-09 21:38:39.008526 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 2022-05-09 21:38:43.275094 E CECAdapter: Failed to turn TV on. 2022-05-09 21:38:43.275201 I CECAdapter: >> source activated: Playback 1 (4) 2022-05-09 21:38:43.275224 I CECAdapter: Source 4 Activated 2022-05-09 21:38:43.275375 W CECAdapter: CEC device can't poll TV: TV does not respond to CEC polls 2022-05-09 21:38:47.541811 I CECAdapter: << Playback 1 (4) -> broadcast (F): active source (1000) 2022-05-09 21:38:47.541898 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 2022-05-09 21:38:47.541909 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 2022-05-09 21:38:47.541924 E CECAdapter: Failed to switch to this input. 2022-05-09 21:38:51.808626 I CECAdapter: << Playback 1 (4) -> broadcast (F): active source (1000) 2022-05-09 21:38:51.808722 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 2022-05-09 21:38:51.808735 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 2022-05-09 21:38:57.142091 I CECAdapter: << Playback 1 (4) -> broadcast (F): active source (1000) 2022-05-09 21:38:57.142109 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 2022-05-09 21:38:57.142117 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 2022-05-09 21:39:02.475097 I CECAdapter: << Playback 1 (4) -> broadcast (F): active source (1000) 2022-05-09 21:39:02.475115 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 2022-05-09 21:39:02.475123 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 > I have some concerns about the DTS you've built here. For instance how > come you are modifying the power domains? This was experiment as I was advised: "32k clock needed for cec and this clock is generated by the rtc which is embedded in the rk8xx regulator. So you should make sure it is enabled when hdmi is powerd on, eg adding it to the RK3568_PD_VO powerdomain should help" power domains entries in dts was attempt to play with above cec clock sugestion. M0/M1 logs in this email are from cleaned dts: https://pastebin.com/0pgwpdsS > USB3 is broken because the rock3-a is a rk3568 device and you're > missing combophy0. Perfect. all 4 usb ports are now working. Also no errors in dmesg. Thx!
On Mon, May 9, 2022 at 3:49 PM Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote: > > > > > 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 > > > > For some reason the board developers decided to make this selectable, > > check the location of R90652 and R90653. > > > > Peter, > > my board is v1.31 and is using HDMITX_CEC_M1 i think. > I verified this by temp. changing to HDMITX_CEC_M0 > > For M1: > 2022-05-09 21:12:37.130188 I CECAdapter: Using physical address 1.0.0.0 from EDID > 2022-05-09 21:12:37.173267 I CECAdapter: Found 1 CEC devices(s). > 2022-05-09 21:12:37.173299 I CECAdapter: Device 1: path '/dev/cec0' com port 'Linux' SELECTED > 2022-05-09 21:12:37.173307 I CECAdapter: Trying to open device /dev/cec0 (Linux). > 2022-05-09 21:12:37.180095 I CECAdapter: connection opened > 2022-05-09 21:12:37.545229 I CECAdapter: setting HDMI port to 1 on device TV (0) > 2022-05-09 21:12:37.904145 I CECAdapter: >> source deactivated: Playback 1 (4) > 2022-05-09 21:12:37.904311 I CECAdapter: Source 4 Deactivated > 2022-05-09 21:12:38.284452 I CECAdapter: >> source activated: Playback 1 (4) > 2022-05-09 21:12:38.284492 I CECAdapter: Source 4 Activated > 2022-05-09 21:12:38.284694 I CECAdapter: CEC client registered: libCEC version = 6.0.2, client version = 6.0.2, firmware version = 0, logical address(es) = Playback 1 (4) , physical address: 1.0.0.0, git revision: v12.0.0-v32.0-16-g611cac15cc+59-07dc900~dirty, compiled on 2022-04-23 05:50:57 by piotro@/bin/sh: hostname: command not found on Linux 5.16.14-arch1-4 (x86_64), features: P8_USB, DRM, P8_detect, randr, Linux > 2022-05-09 21:12:38.519394 I CECAdapter: Opened CEC device. > 2022-05-09 21:12:38.636950 I CECAdapter: << powering on 'TV' (0) > 2022-05-09 21:12:38.754023 E CECAdapter: Failed to turn TV on. > 2022-05-09 21:12:38.754313 I CECAdapter: >> source activated: Playback 1 (4) > 2022-05-09 21:12:38.754343 I CECAdapter: Source 4 Activated > 2022-05-09 21:12:38.872079 I CECAdapter: << Playback 1 (4) -> broadcast (F): active source (1000) > 2022-05-09 21:12:38.974698 I CECAdapter: Asked TV to switch to this input. > 2022-05-09 21:13:07.292069 W CECAdapter: CEC device can't poll TV: TV does not respond to CEC polls > 2022-05-09 21:13:37.296372 W CECAdapter: CEC device can't poll TV: TV does not respond to CEC polls > > for M0: > 2022-05-09 21:37:47.632175 I CECAdapter: Using physical address 1.0.0.0 from EDID > 2022-05-09 21:37:47.680618 I CECAdapter: Found 1 CEC devices(s). > 2022-05-09 21:37:47.680644 I CECAdapter: Device 1: path '/dev/cec0' com port 'Linux' SELECTED > 2022-05-09 21:37:47.680654 I CECAdapter: Trying to open device /dev/cec0 (Linux). > 2022-05-09 21:37:47.694974 I CECAdapter: connection opened > 2022-05-09 21:37:56.341846 I CECAdapter: setting HDMI port to 1 on device TV (0) > 2022-05-09 21:38:17.675457 I CECAdapter: >> source activated: Playback 1 (4) > 2022-05-09 21:38:17.675561 I CECAdapter: Source 4 Activated > 2022-05-09 21:38:17.675657 I CECAdapter: CEC client registered: libCEC version = 6.0.2, client version = 6.0.2, firmware version = 0, logical address(es) = Playback 1 (4) , physical address: 1.0.0.0, git revision: v12.0.0-v32.0-16-g611cac15cc+59-07dc900~dirty, compiled on 2022-04-23 05:50:57 by piotro@/bin/sh: hostname: command not found on Linux 5.16.14-arch1-4 (x86_64), features: P8_USB, DRM, P8_detect, randr, Linux > 2022-05-09 21:38:30.475336 I CECAdapter: Opened CEC device. > 2022-05-09 21:38:34.741846 I CECAdapter: << Playback 1 (4) -> broadcast (F): active source (1000) > 2022-05-09 21:38:39.008432 I CECAdapter: << powering on 'TV' (0) > 2022-05-09 21:38:39.008506 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 > 2022-05-09 21:38:39.008526 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 > 2022-05-09 21:38:43.275094 E CECAdapter: Failed to turn TV on. > 2022-05-09 21:38:43.275201 I CECAdapter: >> source activated: Playback 1 (4) > 2022-05-09 21:38:43.275224 I CECAdapter: Source 4 Activated > 2022-05-09 21:38:43.275375 W CECAdapter: CEC device can't poll TV: TV does not respond to CEC polls > 2022-05-09 21:38:47.541811 I CECAdapter: << Playback 1 (4) -> broadcast (F): active source (1000) > 2022-05-09 21:38:47.541898 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 > 2022-05-09 21:38:47.541909 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 > 2022-05-09 21:38:47.541924 E CECAdapter: Failed to switch to this input. > 2022-05-09 21:38:51.808626 I CECAdapter: << Playback 1 (4) -> broadcast (F): active source (1000) > 2022-05-09 21:38:51.808722 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 > 2022-05-09 21:38:51.808735 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 > 2022-05-09 21:38:57.142091 I CECAdapter: << Playback 1 (4) -> broadcast (F): active source (1000) > 2022-05-09 21:38:57.142109 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 > 2022-05-09 21:38:57.142117 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 > 2022-05-09 21:39:02.475097 I CECAdapter: << Playback 1 (4) -> broadcast (F): active source (1000) > 2022-05-09 21:39:02.475115 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 > 2022-05-09 21:39:02.475123 E CECAdapter: CLinuxCECAdapterCommunication::Write - ioctl CEC_TRANSMIT failed - tx_status=00 errno=22 > > > I have some concerns about the DTS you've built here. For instance how > > come you are modifying the power domains? > > This was experiment as I was advised: > > "32k clock needed for cec and this clock is generated by the rtc which is embedded in the rk8xx regulator. > So you should make sure it is enabled when hdmi is powerd on, eg adding it to the RK3568_PD_VO powerdomain should help" Could you grab the clock tree from /sys/kernel/debug/clk/clk_summary for the clk_hdmi_cec tree? > > power domains entries in dts was attempt to play with above cec clock sugestion. > > M0/M1 logs in this email are from cleaned dts: https://pastebin.com/0pgwpdsS > > > USB3 is broken because the rock3-a is a rk3568 device and you're > > missing combophy0. > > Perfect. all 4 usb ports are now working. > Also no errors in dmesg. > Thx! Good news! >
> Wiadomość napisana przez Peter Geis <pgwipeout@gmail.com> w dniu 10.05.2022, o godz. 03:35: > > Could you grab the clock tree from /sys/kernel/debug/clk/clk_summary > for the clk_hdmi_cec tree? Here it is: enable prepare protect duty hardware clock count count count rate accuracy phase cycle enable ------------------------------------------------------------------------------------------------------- clk_rtc32k_frac 1 1 0 32768 0 0 50000 Y clk_rtc_32k 1 1 0 32768 0 0 50000 Y clk_hdmi_cec 1 2 0 32768 0 0 50000 Y
On Tue, May 10, 2022 at 3:29 AM Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote: > > > > > Wiadomość napisana przez Peter Geis <pgwipeout@gmail.com> w dniu 10.05.2022, o godz. 03:35: > > > > Could you grab the clock tree from /sys/kernel/debug/clk/clk_summary > > for the clk_hdmi_cec tree? > > Here it is: > enable prepare protect duty hardware > clock count count count rate accuracy phase cycle enable > ------------------------------------------------------------------------------------------------------- > clk_rtc32k_frac 1 1 0 32768 0 0 50000 Y > clk_rtc_32k 1 1 0 32768 0 0 50000 Y > clk_hdmi_cec 1 2 0 32768 0 0 50000 Y You are on the clk_rtc32k_frac which is a fractional divider that is fed from the 24m clock. Your clock likely isn't the issue here. I'd recommend setting up the cec-gpio node to validate your hardware works.
> Wiadomość napisana przez Peter Geis <pgwipeout@gmail.com> w dniu 10.05.2022, o godz. 14:08: > > > You are on the clk_rtc32k_frac which is a fractional divider that is > fed from the 24m clock. Your clock likely isn't the issue here. I'd > recommend setting up the cec-gpio node to validate your hardware > works. Peter, Here is what i done to verify my rock3-a HW: 1.download & burn on SD Radxa Ubuntu 2.boot and install v4l-utils 3.run cec-compliance -v -T. It fails with error -22 4.decompile Ubunntu DT. 5.Check what HDMITX_CEC_M hdmi uses. It was M0 6.Chenge to HDMITX_CEC_M1; compile dtb; install on sd 7.reboot. 8.cec-compliance -v -T gives all tests OK 9.cec-ctl --image-view-on -t0 turns-on my TV hope this proves my HW is ok?
On Tue, May 10, 2022 at 9:49 AM Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote: > > > > > Wiadomość napisana przez Peter Geis <pgwipeout@gmail.com> w dniu 10.05.2022, o godz. 14:08: > > > > > > You are on the clk_rtc32k_frac which is a fractional divider that is > > fed from the 24m clock. Your clock likely isn't the issue here. I'd > > recommend setting up the cec-gpio node to validate your hardware > > works. > > Peter, > > Here is what i done to verify my rock3-a HW: > > 1.download & burn on SD Radxa Ubuntu > 2.boot and install v4l-utils > 3.run cec-compliance -v -T. It fails with error -22 > 4.decompile Ubunntu DT. > 5.Check what HDMITX_CEC_M hdmi uses. It was M0 > 6.Chenge to HDMITX_CEC_M1; compile dtb; install on sd > 7.reboot. > 8.cec-compliance -v -T gives all tests OK > 9.cec-ctl --image-view-on -t0 turns-on my TV > > hope this proves my HW is ok? > That does show that the hardware works with the oem image. It does not unfortunately prove if it works with your current dts. cec-gpio will show if it's an issue with the cec controller or an external problem.
On Tue, May 10, 2022 at 4:54 PM Peter Geis <pgwipeout@gmail.com> wrote: > > On Tue, May 10, 2022 at 9:49 AM Piotr Oniszczuk > <piotr.oniszczuk@gmail.com> wrote: > > > > > > > > > Wiadomość napisana przez Peter Geis <pgwipeout@gmail.com> w dniu 10.05.2022, o godz. 14:08: > > > > > > > > > You are on the clk_rtc32k_frac which is a fractional divider that is > > > fed from the 24m clock. Your clock likely isn't the issue here. I'd > > > recommend setting up the cec-gpio node to validate your hardware > > > works. > > > > Peter, > > > > Here is what i done to verify my rock3-a HW: > > > > 1.download & burn on SD Radxa Ubuntu > > 2.boot and install v4l-utils > > 3.run cec-compliance -v -T. It fails with error -22 > > 4.decompile Ubunntu DT. > > 5.Check what HDMITX_CEC_M hdmi uses. It was M0 > > 6.Chenge to HDMITX_CEC_M1; compile dtb; install on sd > > 7.reboot. > > 8.cec-compliance -v -T gives all tests OK > > 9.cec-ctl --image-view-on -t0 turns-on my TV > > > > hope this proves my HW is ok? > > > > That does show that the hardware works with the oem image. It does not > unfortunately prove if it works with your current dts. cec-gpio will > show if it's an issue with the cec controller or an external problem. I've pulled your dts and with a few fixes got a working system from it. At least on the v1.1 board cec is functional: Total for dwhdmi-rockchip device /dev/cec0: 1, Succeeded: 1, Failed: 0, Warnings: 0
> Wiadomość napisana przez Peter Geis <pgwipeout@gmail.com> w dniu 11.05.2022, o godz. 00:49: > > I've pulled your dts and with a few fixes got a working system from > it. At least on the v1.1 board cec is functional: > Total for dwhdmi-rockchip device /dev/cec0: 1, Succeeded: 1, Failed: > 0, Warnings: 0 Peter, Thx for this. This is good news. I see 4 potential root causes why it not works for me: not mutual-exclusive: 1\my DTS has errors needed fix 2\my kernel config needs tweaking for cec on rk3568 3\my rock3 v1.31 hw needs some extra dt love (over yours v1.1) to get cec working 4\my bootloader passes hw to kernel in state that cec is non-functional May you pls send me via PM to piotr.oniszczuk@gmail.com yours kernel config & working for you dts? If i fail with 1/2/3 then i'll need go with yours booloader... lets try see is 1/2/3 with your dt and .config please?
On 2022-05-08 17:53, Peter Geis wrote: > On Sun, May 8, 2022 at 9:40 AM Piotr Oniszczuk > <piotr.oniszczuk@gmail.com> wrote: >> >> >> >>> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 22.04.2022, o godz. 09:28: >>> >>> From: Michael Riesch <michael.riesch@wolfvision.net> >>> >>> Enable the RK356x Video Output Processor (VOP) 2 on the Radxa >>> ROCK3 Model A. >>> >>> Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net> >>> Reported-by: kernel test robot <lkp@intel.com> >>> Link: https://lore.kernel.org/r/20220310210352.451136-4-michael.riesch@wolfvision.net >>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> >>> --- >> >> Sascha, Michael, > > Good Afternoon, >> >> I'm using v11 series on 5.18-rc5 on rk3566 tvbox with great success. >> Recently i started to work on rock3-a (rk3568). >> v11 gives me video, audio - but cec is not working on rock3-a. >> >> I was told: >> >> 32k clock needed for cec and this clock is generated by the rtc which is embedded in the rk8xx regulator. >> So you should make sure it is enabled when hdmi is powerd on, eg adding it to the RK3568_PD_VO powerdomain should help >> >> I was trying to do this in dts https://pastebin.com/67wu9QrH but cec is still non-functional >> >> Maybe You have some hints/pointers here? > > Add the following to the HDMI node: > assigned-clocks = <&cru CLK_HDMI_CEC>; > assigned-clock-rates = <32768>; > > The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which > feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to > function. > I submitted a patch to have the hdmi driver handle this, but it broke > other SoCs because 32k is an optional clock. > Since this is the case, I'd like Robin to weigh in on going the > assigned-clock route again. (did you mean to CC me or have I missed another thread elsewhere?) FWIW I still think it would be good to fix the clock driver(s) and/or DTs to correctly deal with the availability and configuration of xin_32k where appropriate. However, much like the HCLK_VO mess I guess that's a larger cleanup tangent in its own right, so using "assigned-clocks" for this one case in the meantime doesn't seem unreasonable. I was optimistic for the cleanest, most generic solution, but if reality gets in the way then oh well. Judging by the datasheet, RK3568 might actually have a similar situation with its clk32k_in pin, so you may want "assigned-clock-parents" as well to ensure the whole clk_rtc32k branch is really set up the way you currently expect - baking any more assumptions into DTBs now only seems to add potential for breakage if kernel behaviour changes in future. Robin.
On Thu, May 12, 2022 at 8:17 AM Robin Murphy <robin.murphy@arm.com> wrote: > > On 2022-05-08 17:53, Peter Geis wrote: > > On Sun, May 8, 2022 at 9:40 AM Piotr Oniszczuk > > <piotr.oniszczuk@gmail.com> wrote: > >> > >> > >> > >>> Wiadomość napisana przez Sascha Hauer <s.hauer@pengutronix.de> w dniu 22.04.2022, o godz. 09:28: > >>> > >>> From: Michael Riesch <michael.riesch@wolfvision.net> > >>> > >>> Enable the RK356x Video Output Processor (VOP) 2 on the Radxa > >>> ROCK3 Model A. > >>> > >>> Signed-off-by: Michael Riesch <michael.riesch@wolfvision.net> > >>> Reported-by: kernel test robot <lkp@intel.com> > >>> Link: https://lore.kernel.org/r/20220310210352.451136-4-michael.riesch@wolfvision.net > >>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> > >>> --- > >> > >> Sascha, Michael, > > > > Good Afternoon, > >> > >> I'm using v11 series on 5.18-rc5 on rk3566 tvbox with great success. > >> Recently i started to work on rock3-a (rk3568). > >> v11 gives me video, audio - but cec is not working on rock3-a. > >> > >> I was told: > >> > >> 32k clock needed for cec and this clock is generated by the rtc which is embedded in the rk8xx regulator. > >> So you should make sure it is enabled when hdmi is powerd on, eg adding it to the RK3568_PD_VO powerdomain should help > >> > >> I was trying to do this in dts https://pastebin.com/67wu9QrH but cec is still non-functional > >> > >> Maybe You have some hints/pointers here? > > > > Add the following to the HDMI node: > > assigned-clocks = <&cru CLK_HDMI_CEC>; > > assigned-clock-rates = <32768>; > > > > The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which > > feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to > > function. > > I submitted a patch to have the hdmi driver handle this, but it broke > > other SoCs because 32k is an optional clock. > > Since this is the case, I'd like Robin to weigh in on going the > > assigned-clock route again. > > (did you mean to CC me or have I missed another thread elsewhere?) Apologies, I made an unsafe assumption here. > > FWIW I still think it would be good to fix the clock driver(s) and/or > DTs to correctly deal with the availability and configuration of xin_32k > where appropriate. However, much like the HCLK_VO mess I guess that's a > larger cleanup tangent in its own right, so using "assigned-clocks" for > this one case in the meantime doesn't seem unreasonable. I was > optimistic for the cleanest, most generic solution, but if reality gets > in the way then oh well. I was thinking about this problem and came to a realization. The root dtsi files all have clk32k_in defined, even though it's listed as an optional clock. I think this should move to the device boards (much like the gmac input clock) that have it. The clock driver might need some help coping with it being missing, I haven't tested this. > > Judging by the datasheet, RK3568 might actually have a similar situation > with its clk32k_in pin, so you may want "assigned-clock-parents" as well > to ensure the whole clk_rtc32k branch is really set up the way you > currently expect - baking any more assumptions into DTBs now only seems > to add potential for breakage if kernel behaviour changes in future. rk3568 defaults to using a clock divider from the 24m clock, so it works even in the absence of clk32_in. It seemed rk3399 did as well, but unlike rk3568 it would switch to clk32k_in if the exact frequency was chosen. Implementing the above would fix that issue, and we can then implement the driver fix. > > Robin. Very Respectfully, Peter
> Wiadomość napisana przez Peter Geis <pgwipeout@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....
> Wiadomość napisana przez Piotr Oniszczuk <piotr.oniszczuk@gmail.com> w dniu 14.05.2022, o godz. 15:58: > > > >> Wiadomość napisana przez Peter Geis <pgwipeout@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) --> 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. 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.... I'm too weak in kernel cec internals - so maybe you have any pointers how to further debug/investigate this issue? BTW: i'm not alone with cec issue on rock3a v1.31 - already 2 other users contacted me with the same issue...
On Fri, Jun 24, 2022 at 4:30 AM Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote: > > > > > Wiadomość napisana przez Piotr Oniszczuk <piotr.oniszczuk@gmail.com> w dniu 14.05.2022, o godz. 15:58: > > > > > > > >> Wiadomość napisana przez Peter Geis <pgwipeout@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... > >
> Wiadomość napisana przez Peter Geis <pgwipeout@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? > 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
On Fri, Jun 24, 2022 at 2:57 PM Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote: > > > > > Wiadomość napisana przez Peter Geis <pgwipeout@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. > > > 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?
> Wiadomość napisana przez Peter Geis <pgwipeout@gmail.com> w dniu 25.06.2022, o godz. 01:50: > > On Fri, Jun 24, 2022 at 2:57 PM Piotr Oniszczuk > <piotr.oniszczuk@gmail.com> wrote: >> >> >> >>> Wiadomość napisana przez Peter Geis <pgwipeout@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 :-( > >> >>> 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?
On Sat, Jun 25, 2022 at 9:18 AM Piotr Oniszczuk <piotr.oniszczuk@gmail.com> wrote: > > > > > Wiadomość napisana przez Peter Geis <pgwipeout@gmail.com> w dniu 25.06.2022, o godz. 01:50: > > > > On Fri, Jun 24, 2022 at 2:57 PM Piotr Oniszczuk > > <piotr.oniszczuk@gmail.com> wrote: > >> > >> > >> > >>> Wiadomość napisana przez Peter Geis <pgwipeout@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.
> Wiadomość napisana przez Peter Geis <pgwipeout@gmail.com> w dniu 25.06.2022, o godz. 16:00: > > > The first issue you have is the TV isn't responding until the absolute > end. I suspect this is because lack on idle gaps between cec commands sent from board to tv. Maybe TV sw. can't deal with consecutive commands without any idle between them? It is interesting that disconnecting TV - so CEC line is driven only by board - rock3a still don't have any idle gaps while rock3b (and radxa 4.19 bsp) has them (very similar between 5.18mailine and 4.19 bsp). How this is possible that change I/O from m0->m1 impacts _timings_ on free hanging CEC line? > 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. Indeed - i will verify this with digital oscilloscope. Already ordered and must await week or 2 for delivery :-( My analog oscilloscope shows correct levels and slopes "seems" to be the same like in working (no memory so i can compare only visually on fuzzy screen) For me key is to understand why on rock3a there is no any idles between cec commands - even when nothing is connected to bard (so cec is only sending and nothing external impacts cec state machine)....
> Wiadomość napisana przez Piotr Oniszczuk <piotr.oniszczuk@gmail.com> w dniu 25.06.2022, o godz. 17:31: > > > >> Wiadomość napisana przez Peter Geis <pgwipeout@gmail.com> w dniu 25.06.2022, o godz. 16:00: >> >> >> The first issue you have is the TV isn't responding until the absolute >> end. > > I suspect this is because lack on idle gaps between cec commands sent from board to tv. > Maybe TV sw. can't deal with consecutive commands without any idle between them? > > It is interesting that disconnecting TV - so CEC line is driven only by board - rock3a still don't have any idle gaps while rock3b (and radxa 4.19 bsp) has them (very similar between 5.18mailine and 4.19 bsp). > > How this is possible that change I/O from m0->m1 impacts _timings_ on free hanging CEC line? > >> 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. > > Indeed - i will verify this with digital oscilloscope. Peter, fyi I got my oscilloscope and do measurements on hdmi cable cec line on: working rock3b and non-working rock3a. sw was exactly the same (same sd card; only dtb changed) Pls see measurements for: start pulse "0" pulse "1" pulse non-working rock3-a: http://warped.inet2.org/rock3a-one.png http://warped.inet2.org/rock3a-start.png http://warped.inet2.org/rock3a-zero.png working rock3-b http://warped.inet2.org/rock3b-one.png http://warped.inet2.org/rock3b-start.png http://warped.inet2.org/rock3b-zero.png Now i'm 99% sure issue is not hw related but sw (kernel)... br
On 2022-06-25 16:31, Piotr Oniszczuk wrote: > > >> Wiadomość napisana przez Peter Geis <pgwipeout@gmail.com> w dniu 25.06.2022, o godz. 16:00: >> >> >> The first issue you have is the TV isn't responding until the absolute >> end. > > I suspect this is because lack on idle gaps between cec commands sent from board to tv. > Maybe TV sw. can't deal with consecutive commands without any idle between them? > > It is interesting that disconnecting TV - so CEC line is driven only by board - rock3a still don't have any idle gaps while rock3b (and radxa 4.19 bsp) has them (very similar between 5.18mailine and 4.19 bsp). > > How this is possible that change I/O from m0->m1 impacts _timings_ on free hanging CEC line? Check all the pinctrl settings beyond just the function mux - pulls, drive strength, output type, etc. - the defaults tend to be all over the place, and rarely what you want. Robin. >> 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. > > Indeed - i will verify this with digital oscilloscope. > Already ordered and must await week or 2 for delivery :-( > > My analog oscilloscope shows correct levels and slopes "seems" to be the same like in working (no memory so i can compare only visually on fuzzy screen) > > For me key is to understand why on rock3a there is no any idles between cec commands - even when nothing is connected to bard (so cec is only sending and nothing external impacts cec state machine).... > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip
> Wiadomość napisana przez Robin Murphy <robin.murphy@arm.com> w dniu 11.07.2022, o godz. 12:41: > > On 2022-06-25 16:31, Piotr Oniszczuk wrote: >>> Wiadomość napisana przez Peter Geis <pgwipeout@gmail.com> w dniu 25.06.2022, o godz. 16:00: >>> >>> >>> The first issue you have is the TV isn't responding until the absolute >>> end. >> I suspect this is because lack on idle gaps between cec commands sent from board to tv. >> Maybe TV sw. can't deal with consecutive commands without any idle between them? >> It is interesting that disconnecting TV - so CEC line is driven only by board - rock3a still don't have any idle gaps while rock3b (and radxa 4.19 bsp) has them (very similar between 5.18mailine and 4.19 bsp). >> How this is possible that change I/O from m0->m1 impacts _timings_ on free hanging CEC line? > > Check all the pinctrl settings beyond just the function mux - pulls, drive strength, output type, etc. - the defaults tend to be all over the place, and rarely what you want. > > Robin. Robin, I'm not sure do I looked in right place... but: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi?h=v5.18.10#n788 vs. https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi?h=v5.18.10#n795 are looking ok? > >>> 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. >> Indeed - i will verify this with digital oscilloscope. >> Already ordered and must await week or 2 for delivery :-( >> My analog oscilloscope shows correct levels and slopes "seems" to be the same like in working (no memory so i can compare only visually on fuzzy screen) >> For me key is to understand why on rock3a there is no any idles between cec commands - even when nothing is connected to bard (so cec is only sending and nothing external impacts cec state machine).... >> _______________________________________________ >> Linux-rockchip mailing list >> Linux-rockchip@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-rockchip
On 2022-07-11 12:04, Piotr Oniszczuk wrote: > > >> Wiadomość napisana przez Robin Murphy <robin.murphy@arm.com> w dniu 11.07.2022, o godz. 12:41: >> >> On 2022-06-25 16:31, Piotr Oniszczuk wrote: >>>> Wiadomość napisana przez Peter Geis <pgwipeout@gmail.com> w dniu 25.06.2022, o godz. 16:00: >>>> >>>> >>>> The first issue you have is the TV isn't responding until the absolute >>>> end. >>> I suspect this is because lack on idle gaps between cec commands sent from board to tv. >>> Maybe TV sw. can't deal with consecutive commands without any idle between them? >>> It is interesting that disconnecting TV - so CEC line is driven only by board - rock3a still don't have any idle gaps while rock3b (and radxa 4.19 bsp) has them (very similar between 5.18mailine and 4.19 bsp). >>> How this is possible that change I/O from m0->m1 impacts _timings_ on free hanging CEC line? >> >> Check all the pinctrl settings beyond just the function mux - pulls, drive strength, output type, etc. - the defaults tend to be all over the place, and rarely what you want. >> >> Robin. > > Robin, > > I'm not sure do I looked in right place... > > but: > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi?h=v5.18.10#n788 > > vs. > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi?h=v5.18.10#n795 > > are looking ok? I meant more in terms of dumping out the actual hardware state to compare across both axes of cec_m0 vs. cec_m1 and mainline vs. BSP. However from a quick skim of the Rock3 schematic there doesn't appear to be an external pull-up, so the internal pull-up also being disabled is a clear suspect to start with. Robin.
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts index 18d2d8e5e6933..e568ce3770551 100644 --- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts +++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts @@ -4,6 +4,7 @@ #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/leds/common.h> #include <dt-bindings/pinctrl/rockchip.h> +#include <dt-bindings/soc/rockchip,vop2.h> #include "rk3568.dtsi" / { @@ -20,6 +21,17 @@ chosen: chosen { stdout-path = "serial2:1500000n8"; }; + hdmi-con { + compatible = "hdmi-connector"; + type = "a"; + + port { + hdmi_con_in: endpoint { + remote-endpoint = <&hdmi_out_con>; + }; + }; + }; + leds { compatible = "gpio-leds"; @@ -134,6 +146,24 @@ &gpu { status = "okay"; }; +&hdmi { + avdd-0v9-supply = <&vdda0v9_image>; + avdd-1v8-supply = <&vcca1v8_image>; + status = "okay"; +}; + +&hdmi_in { + hdmi_in_vp0: endpoint { + remote-endpoint = <&vp0_out_hdmi>; + }; +}; + +&hdmi_out { + hdmi_out_con: endpoint { + remote-endpoint = <&hdmi_con_in>; + }; +}; + &i2c0 { status = "okay"; @@ -499,3 +529,20 @@ &usb2phy1_otg { phy-supply = <&vcc5v0_usb_host>; status = "okay"; }; + +&vop { + assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP1>; + assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>; + status = "okay"; +}; + +&vop_mmu { + status = "okay"; +}; + +&vp0 { + vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 { + reg = <ROCKCHIP_VOP2_EP_HDMI0>; + remote-endpoint = <&hdmi_in_vp0>; + }; +};