On Tue, Oct 13, 2026 at 10:37:19AM +0200, Maxime Ripard wrote: > On Tue, Oct 13, 2026 at 10:51:38AM +0300, Dmitry Baryshkov wrote: > > On Mon, Oct 12, 2026 at 08:40:33AM +0200, Maxime Ripard wrote: > > > On Thu, Oct 08, 2026 at 04:14:22PM +0300, Dmitry Baryshkov wrote: > > > > Panel drivers don't have an atomic state and so they can't handle > > > > additional data to be stored at the atomic_check time or to be retrieved > > > > at the enable/disable time. For example, it prevents panel drivers from > > > > supporting multiple display modes or making DSC being optional in a > > > > clean way. Drivers like panel-novatek-nt35950, save the connector > > > > pointer in get_modes() and later dereference > > > > connector->state->crtc->state from prepare() without holding any locks. > > > > The panels also have no way to reject the configuration they cann't > > > > handle, as it doesn't take part in the atomic check. > > > > > > > > The panel already embeds a drm_bridge, and the bridge has an atomic > > > > state which is property handled. Subclass it to provide atomic state for > > > > the panels. The callbacks can find the state of the other related > > > > objects (e.g. CRTC state to get the display mode). > > > > > > > > The atomic state is opt-in. A panel that doesn't implement the state > > > > callbacks keeps working exactly as before, with the plain bridge state, > > > > so there is no need to touch the existing drivers. The panels which do > > > > implement them can only be driven through the embedded bridge, since > > > > there is no commit to hand over when the host calls drm_panel_prepare() > > > > and friends directly. Those entry points warn and refuse to handle such > > > > panels. There are still a dozen of display drivers calling these > > > > functions, and the panels used with them can not be converted until the > > > > hosts are switched to the panel bridge. > > > > > > I really don't think we should extend the panel API. All panels are > > > bridges now, consumers only care about bridges as well, and the bridges > > > API provides what you want already. > > > > > > Why not simply turn the panel drivers we want into bridges, possibly > > > with a bunch of specialized helpers to manage a panel state, and call it > > > a day? > > > > I think that panels provide good abstraction on top of the drm_bridge. > > For example, bridges don't have orientation, panels do. > > That's easy to add.
What would it mean for the bridge? I was thinking about pulling orientation from the per-panel code to a generic code path, including reading and handling it. I'm not sure if it should be done in the drm_bridge code if we declare drm_panel deprecated. > > Also panels have followers, while bridges do not. > > Ditto > > > I don't think that either of those APIs make sense for bridge. > > Why not? In a world where we have bridge hotplug for example, it would > make total sense to me to have bridge followers. I think Luca even had > that at some point in his series (and still might?). > > > Last, but not least, we have drivers that were not converted to the > > bridged approach (*). > > I'm not disputing that, but it's a matter of months at this point, Luca > already did a significant part of it. Sure. > > As such I think we should evolve the drm_panel, extending it to > > support atomic state. > > I still think that drm_panel is on the way out with bridges taking over > for years now, and we should accept it. Otherwise we'll just end up with > two concepts with the same purpose which isn't great. Ack. Let me check if I can get rid of drm_panel_funcs easily, because then we can start using atomic ops for the panels, while phasing out the drm_panel abstraction. -- With best wishes Dmitry
