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

[Maxime Ripard <mripard@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3196 bytes --]

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.

> 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.

> 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.

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]