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. Also panels have followers, while bridges do not. I don't think that either of those APIs make sense for bridge. Last, but not least, we have drivers that were not converted to the bridged approach (*). As such I think we should evolve the drm_panel, extending it to support atomic state. (*) git grep points out the following direct users of drm_panel API: drivers/gpu/drm/bridge/analogix/analogix-anx6345.c: drm_panel_enable(anx6345->panel); drivers/gpu/drm/bridge/ssd2825.c: drm_panel_enable(priv->output.panel); drivers/gpu/drm/exynos/exynos_drm_dpi.c: drm_panel_enable(ctx->panel); drivers/gpu/drm/logicvc/logicvc_interface.c: drm_panel_enable(interface->drm_panel); drivers/gpu/drm/panel/panel-sitronix-st7703.c: drm_panel_enable(&ctx->panel); drivers/gpu/drm/rockchip/rockchip_lvds.c: drm_panel_enable(lvds->panel); drivers/gpu/drm/rockchip/rockchip_lvds.c: drm_panel_enable(lvds->panel); drivers/gpu/drm/sti/sti_dvo.c: drm_panel_enable(dvo->panel); drivers/gpu/drm/stm/lvds.c: drm_panel_enable(lvds->panel); drivers/gpu/drm/sun4i/sun4i_lvds.c: drm_panel_enable(lvds->panel); drivers/gpu/drm/sun4i/sun4i_rgb.c: drm_panel_enable(rgb->panel); drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c: drm_panel_enable(dsi->panel); drivers/gpu/drm/tegra/dsi.c: drm_panel_enable(output->panel); drivers/gpu/drm/tegra/sor.c: drm_panel_enable(output->panel); -- With best wishes Dmitry
