Re: [PATCH RFC 0/9] drm/panel: add atomic state

[Dmitry Baryshkov]

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