On 10/8/26 10:14 AM, 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.

The previous attempt by Val Packett <[email protected]> ([1]), but it had
issues with the API design, passing NULL for the state. This approach
follows closer the path that was chosen for drm_bridge conversion.

The series is marked as RFC as it is only compiled-tested only.

[1] https://lore.kernel.org/r/[email protected]/

Tested-by: Val Packett <[email protected]>

Converted my nt37701 WIP to this, temporarily at:

https://github.com/valpackett/linux-qclaptops/commit/a0a3a25e1ce484ffe072e4399014ced605c78852

Everything works as it did with my initial hacky attempt. :)

~val

Reply via email to