Re: [PATCH v4 2/4] drm/panel: Add refcount support

[Maxime Ripard <mripard@kernel.org>]

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

On Tue, May 27, 2025 at 10:40:49PM +0300, Jani Nikula wrote:
> On Tue, 27 May 2025, Maxime Ripard <mripard@kernel.org> wrote:
> > On Tue, May 20, 2025 at 01:09:47PM +0300, Jani Nikula wrote:
> >> 
> >> Maxime -
> >> 
> >> I'm cutting a lot of context here. Not because I don't think it deserves
> >> an answer, but because I seem to be failing at communication.
> >> 
> >> On Mon, 19 May 2025, Maxime Ripard <mripard@kernel.org> wrote:
> >> > You still haven't explained why it would take anything more than
> >> > registering a dumb device at probe time though.
> >> 
> >> With that, do you mean a dumb struct device, or any struct device with a
> >> suitable lifetime, that we'd pass to devm_drm_panel_alloc()?
> >> 
> >> Is using devm_drm_panel_alloc() like that instead of our own allocation
> >> with drm_panel_init() the main point of contention for you? If yes, we
> >> can do that.
> >
> > Yeah, I was thinking of something along the lines of:
> >
> > const struct drm_panel_funcs dummy_funcs = {};
> >
> > struct drm_panel *register_panel() {
> >     struct faux_device *faux;
> >     struct drm_panel *panel;
> >     int ret;
> >
> >     faux = faux_device_create(...);
> >     if IS_ERR(faux)
> >        return ERR_CAST(faux);
> >
> >     return __devm_drm_panel_alloc(&faux->dev, sizeof(*panel), 0, &dummy_funcs, $CONNECTOR_TYPE);
> > }
> >
> > And you have a panel, under your control, with exactly the same
> > setup than anyone else.
> 
> This [1] is what I'm toying with now, but again, draft stuff. Using
> __devm_drm_panel_alloc() directly like above does make it cleaner.
> 
> Long term it can be improved, but my first dab at refactoring to make
> that happen is already like 15-20 patches, and it'll just have to wait
> until after making stuff work at all first.
> 
> I'm not sure if the ACPI device I'm passing to devm_drm_panel_alloc() is
> correct, but it'll have to be *some* ACPI device for the lookup to
> work. I am blissfully ignorant about its lifetime, but as long as
> drm_panel_add() and drm_panel_remove() remain as they are, I don't think
> it leaks anything. Fingers crossed.

Thanks for working on that. Your two patches (the one you sent here, and
the one in the other subthread) look good to me. So if that works, it
looks like we have a way forward.

Thanks!
Maxime

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