On Thu, May 12, 2022 at 8:17 AM Robin Murphy <robin.murphy@xxxxxxx> wrote: > > On 2022-05-08 17:53, Peter Geis wrote: > > On Sun, May 8, 2022 at 9:40 AM Piotr Oniszczuk > > <piotr.oniszczuk@xxxxxxxxx> wrote: > >> > >> > >> > >>> Wiadomość napisana przez Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> w dniu 22.04.2022, o godz. 09:28: > >>> > >>> From: Michael Riesch <michael.riesch@xxxxxxxxxxxxxx> > >>> > >>> Enable the RK356x Video Output Processor (VOP) 2 on the Radxa > >>> ROCK3 Model A. > >>> > >>> Signed-off-by: Michael Riesch <michael.riesch@xxxxxxxxxxxxxx> > >>> Reported-by: kernel test robot <lkp@xxxxxxxxx> > >>> Link: https://lore.kernel.org/r/20220310210352.451136-4-michael.riesch@xxxxxxxxxxxxxx > >>> Signed-off-by: Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> > >>> --- > >> > >> 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
