Re: [PATCH v6 03/10] drm: link connectors to backlight devices

[Maxime Ripard <mripard@kernel.org>]

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

On Fri, Jun 26, 2026 at 04:40:56PM -0500, Mario Limonciello wrote:
> > > + * Drivers have to call drm_backlight_alloc() after allocating a connector via
> > > + * drm_connector_init(). This will automatically add a backlight device to the
> > > + * given connector. Drivers must then link a hardware backlight by calling
> > > + * drm_backlight_link() with the registered backlight_device. If no link is
> > > + * established, the DRM backlight property reports an empty range and
> > > + * brightness changes are no-ops.
> > > + */
> > 
> > It's not clear to me why we need to dynamically allocate them at all. If
> > we're using the backlight subsystem we'll already have a handle to it.
> > If we don't and want to implement something like DDC/CI, then it just
> > becomes a hassle. Why not treat it like i2c, add a backlight field to
> > drm_connector, and create the link at registration, add a new hook to
> > set luminance, and then provide helpers to either use the backlight API,
> > or anything else if the driver wants to.
> 
> I did envision that later on we can have displays with DDC use this
> infrastructure as well.  But I didn't want to hold up the series
> implementing that.

Oh absolutely. My point wasn't that you should support it right away,
but rather that the architecture you work on would be extensible enough
to accomodate for them later on.

I'm exagerating, but for example having an architecture built around
having a backlight device doesn't work, but having one where you have a
set of helpers built around the backlight API does, because then we can
easily create new helpers to deal with DDC/CI, MIPI-DCS, etc. without
reworking the core part.

Maxime

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