Re: clk_set_parent() by name ?

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Tue, Mar 20, 2018 at 05:26:15PM -0300, Jared McNeill wrote:
> On Tue, 20 Mar 2018, Manuel Bouyer wrote:
> 
> > but pushing driver-specific clock setup in the ccu also looks wrong
> > to me, and could appear as black magic.
> 
> It's not driver specific. The TCON needs a clock input at a certain
> frequency and requests it from the clk driver. The clk driver for that soc
> knows how to program the video PLL to supply a clock at that frequency.

I started hacking the sun4i ccu driver and it's a bit more involved than
that. the TCON and the HDMI which are connected together needs to use matching
clocks and also have clock muxes and dividers in their registers (not
everything is in the CCU).

I can probably deal with it in the tcon and hdmi drivers, but this
means that these drivers have some knowledges of the clock hierarchy
to guess some of the parameters.
And will also have to compute dividers.

> 
> > It seems they have display-specific clock drivers (e.g.
> > ./drivers/clk/sunxi/clk-sun4i-display.c
> > ./drivers/clk/sunxi/clk-sun4i-tcon-ch1.c
> > )
> > So we'll probably have to do the same, instead of using the
> > PLL generic drivers.
> > This will also probably need an update of the clock interface (like
> > reference counts for enable/disable, "exclusive" clocks, maybe others).
> 
> Those are old clock drivers, you should look in drivers/clk/sunxi-ng for the
> new style bindings (which is all we support in NetBSD).

Ha yes, I didn't pay attention to the path. So what's in Documentation/
is not up to date ...

> 
> But yeah, you can see them on the tcon nodes, named by the
> "clock-output-names" property. It looks like those clocks use the "tcon-ch0"
> xref as their parent, and are used by CH0. The "tcon-ch1" xref is used
> directly by CH1.

Yes. tcon-ch0 is an example of the problem I'm talking about: to generate
the pixel clock we have to setup a multiplier and a divider; but the
multiplier is in the CCU (it's pll3/pll7) and the divider is in tcon.
In order to compute the best divider the tcon driver has to know what
the CCU can generate.

In allwinner this is awin_tcon0_set_video(). It calls awin_tcon_set_pll(),
which will compute multiplier and divider, but in this case
awin_tcon_set_pll() won't use the divider itself: it stores it in
sc_clk_div, for use by awin_tcon0_set_video() later.

awin_tcon1_set_video() doens't have this issue; the divider is in the CCU.

hdmi also has the divider in its register, but in this case the pll is already
setup (by awin_tcon1_set_video()). Actually it retrives the
divider from tcon but it could recompute it locally.

So we'll end up with 3 places where we compute the same divider: CCU,
tcon and hdmi ...

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--