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 <bou...@antioche.eu.org> NetBSD: 26 ans d'experience feront toujours la difference --