Re: clk_set_parent() by name ?

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

On Tue, Mar 20, 2018 at 06:20:12PM -0300, Jared McNeill wrote:
> On Tue, 20 Mar 2018, Manuel Bouyer wrote:
> 
> > > 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.
> 
> The code for the pixel clock would be part of the display driver. The parent
> of that clock is part the CCU. Maybe we need a clk_try_rate or something to
> help the pixel clock driver set the best parent rate.

but parts of the pixel clock registers are in the CCU too. For example
the divider for ch0 is in the tcon, but the divider for ch1 is in the CCU.

I don't know why is was done this way, but that's how it is, unfortunably.

> 
> > 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.
> 
> I don't know that I would use the allwinner code as a shining example of how
> to do this stuff :) There's a reason I started from scratch..
> 
> > 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.
> 
> How does the sunxi-ng driver solve this?

This is in sun4i_dclk_round_rate(). Basically it tries to set the
parent clock rate for every possible divider value and keep the best one.

THere indeed is something like a clk_try_rate().

> 
> --
> 
> Somewhat related question, since you seem to be porting the existing driver
> over, are you DRM-ifying it in the process? We really need to go that way
> for dynamic output config (think xrandr) and to support the GPU in the
> future.

No that's not in my plans. I know nothing about DRM and I'm not even sure
what we have in sys/external/bsd/drm2/ is up to the task. it looks
awfully x86-centric. What's in linux/drivers/gpu/drm/ is completely
different now.

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