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?)
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.
Cheers, Jared