Hi Brian, On 28-May-26 1:03 AM, Brian Masney wrote: > Hi Hans, > > On Wed, May 27, 2026 at 11:48:08AM +0200, Hans de Goede wrote: >> 2) One option considered was detaching the simple-framebuffer driver later, >> after the real display driver has had a chance to claim the clocks. But >> this won't work in cases where the real display driver picks different >> parent clocks then the boot firmware did and needs to reparent clocks. > > Why won't that work in the case where different parent clocks are selected? > I'll describe a scenario below. > >> >> Basically the goal is for things to behave as if the simple-framebuffer >> driver was not there at all, because that leaves the hw in the state >> the real display driver expects. > > I think the deferred unbinding could have some potential here where > there is some kind of notification mechanism between simple-framebuffer > and the real drm driver. So: > > - simple-framebuffer driver takes reference(s) to the clk(s). > > - real drm driver eventually loads, takes reference(s) to the necessary > clk(s). > > - real drm driver sends a notification to simple-framebuffer that it's > done, and has control. > > - simple-framebuffer can unbind and release its references to the clks. > > No clks will be shutdown prematurely in this scenario. > > If the real drm driver needs a different parent, then presumably things > should be setup correctly, and simple-framebuffer can have the clocks > shut down when it calls clk_disable_unprepare().
If the real drm driver needs a different parent, then how does it do the reparenting while the simple-framebuffer driver is holding a reference to the clock ? In that case the clock might have a protected_count of non 0 (depends on the core-clk flags) and reparenting won't work. We could have the drm driver claim the clks, then call some release function and only then do the reparenting. But this makes things somewhat complicated for the drm drivers. So my conclusion is that having a clk equivalent of e.g. pm_runtime_put_noidle() which just lowers the counts without actually doing anything is still the most KISS approach here. With the downside of needing a new clk-core function for this. > If the real drm driver > needed those clks, then it should hold a reference to them. > > I'm intentionally not going through how to do the notification mechanism> > here. Ack. Regards, Hans
