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

[Anusha Srivatsa <asrivats@redhat.com>]

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

On Wed, May 14, 2025 at 5:22 AM Jani Nikula <jani.nikula@linux.intel.com>
wrote:

> On Tue, 13 May 2025, Maxime Ripard <mripard@kernel.org> wrote:
> > Is it really surprising you get some pushback when you are using a
> > design that is the complete opposite to what every user of it for the
> > last decade has been doing?
>
> The opposite is also true.
>
> If you create a design that does not cleanly fit the model of the
> biggest drivers in the subsystem, and expect massive refactors just for
> the sake of conforming to the design to be able to use any of it, you'll
> also get pushback.
>
> > This one is usable, but you rule out the way you could use it.
>
> I think you're off-hand and completely dismissing the amount of work it
> would be. And still I'm not even ruling it out, but there has to be a
> way to start off in small incremental steps, and use the parts that
> work. And it's not like we're averse to refactoring in the least,
> everyone knows that.
>
> > I guess it's clear now that you won't consider anything else. I wonder
> > why you started that discussion in the first place if you already have
> > a clear mind on how to get things moving forward.
>
> I pointed out what I think is a bug in drm_panel, with nothing but good
> intentions, and everything snowballed from there.
>
> There has to be a middle ground instead of absolutes. Otherwise we'll
> just end up in deeper silos. And more arguments.
>
> BR,
> Jani.
>
>
Jani, Maxime,

Thinking out loud of different solutions we can have to make sure we take
this forward.

Is it possible to have a variant of drm_panel_follower for the non ARM
devices? That way if at any point in
the future, the drm_panel_follower infrastructure has to be used, the
refcounting allocation can be bypassed?

Adding Uma and VIlle to the thread here.

Thanks!
Anusha


> --
> Jani Nikula, Intel
>
>

[-- Attachment #2: Type: text/html, Size: 2726 bytes --]