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?

Maxime