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 needed those clks, then it should hold a reference to them. I'm intentionally not going through how to do the notification mechanism here. Brian
