On Thu, May 28, 2026 at 12:12:10PM +0200, Hans de Goede wrote: > 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.
The only case where it should reparent you listed was that you might need to pick up a different resolution. However, that can only be enforced by an ioctl or a client. simplefb/drm is removed in msm_drm_kms_init. The device is published drm_dev_register called right after msm_drm_kms_init, and the clients are registered in msm_drm_kms_post_init, called after drm_dev_register. There's no way in the current msm architecture to have a modeset happen while the simpledrm driver is still active. Maxime
signature.asc
Description: PGP signature
