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

[Peter Geis]

On Thu, May 12, 2022 at 8:17 AM Robin Murphy <robin.murphy at 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 at gmail.com> wrote:
> >>
> >>
> >>
> >>> Wiadomość napisana przez Sascha Hauer <s.hauer at pengutronix.de> w dniu 22.04.2022, o godz. 09:28:
> >>>
> >>> From: Michael Riesch <michael.riesch at wolfvision.net>
> >>>
> >>> Enable the RK356x Video Output Processor (VOP) 2 on the Radxa
> >>> ROCK3 Model A.
> >>>
> >>> Signed-off-by: Michael Riesch <michael.riesch at wolfvision.net>
> >>> Reported-by: kernel test robot <lkp at intel.com>
> >>> Link: https://lore.kernel.org/r/20220310210352.451136-4-michael.riesch@wolfvision.net
> >>> Signed-off-by: Sascha Hauer <s.hauer at 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