Re: clk_set_parent() by name ?

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

On Tue, Mar 20, 2018 at 07:09:15PM -0300, Jared McNeill wrote:
> On Tue, 20 Mar 2018, Manuel Bouyer wrote:
> 
> > > 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.
> 
> Yes this is expressed in the device tree! There is a "pixel clock" clock on
> the tcon node used for CH0.
> 
> So TCON driver creates a clock in its own domain for the pixel clock. The
> parent of this clock is the "tcon-ch0" clock. All of this code lives in
> sunxi_tcon.c (or whatever you call it).
> 
> When you need to set the CH0 rate, you clk_set_rate on the pixel clock
> (which is responsible for configuring its parent clock, "tcon-ch0").
> 
> When you need to set the CH1 rate, you clk_set_rate directly on the
> "tcon-ch1" xref.
> 
> > > 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().
> 
> Ok, I'd be happy with something like that (but I'm bad at naming things, so
> feel free to make a better suggestion -- clk_calc_rate() maybe?)

linux calls it round_rate() and it's really what it's doing.
so clk_round_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.
> 
> Not sure what gave you the impression that it's x86-centric -- we use it
> today on NetBSD/arm for the NVIDIA Tegra K1 display driver. IMHO it really
> simplifies things (separates things like encoders, crtcs, planes, etc) and
> if you're just doing a simple unaccelerated driver it is fairly straight
> forward. Something to think about for the future.

Probably I'm not looking at the right place then.
But I'll keep that for later.

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