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

["Luca Ceresoli" <luca.ceresoli@bootlin.com>]

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/20261001-drm-bridge-hotplug-v2-14-8e34986dcb68@bootlin.com/
[1] https://lore.kernel.org/lkml/20261001-drm-bridge-hotplug-v2-14-8e34986dcb68@bootlin.com/#Z31include:drm:drm_event_notifier.h
[2] https://lore.kernel.org/lkml/20261001-drm-bridge-hotplug-v2-15-8e34986dcb68@bootlin.com/
[3] https://lore.kernel.org/lkml/20261001-drm-bridge-hotplug-v2-16-8e34986dcb68@bootlin.com/

Luca

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com