On Tue Oct 13, 2026 at 1:57 PM CEST, Dmitry Baryshkov wrote: > 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?).
There's a simple notifier mechanism: see core [0] (with currently psoposed events [1]) and users [2][3]. The events [1] and their semantics are not well defined as of now, so we are still on time to decide from the beginning whether it should be very bridge-hotplug-specific or have a wider scope. [0] https://lore.kernel.org/lkml/[email protected]/ [1] https://lore.kernel.org/lkml/[email protected]/#Z31include:drm:drm_event_notifier.h [2] https://lore.kernel.org/lkml/[email protected]/ [3] https://lore.kernel.org/lkml/[email protected]/ Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
