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

[Maxime Ripard]

On Wed, May 14, 2025 at 12:22:40PM +0300, Jani Nikula wrote:
> On Tue, 13 May 2025, Maxime Ripard <mripard at 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.

That's the thing though: i915 deviates pretty heavily from the helpers,
in general. If it wants to consume them, then it must also be ready to
make some adjustments. Or just roll its own thing like it has done in
the past.

Otherwise, where do we draw the line when anyone isn't happy with the
helpers in general and ask for an exception because reworking the driver
is too much work?

We did this on pretty much every ARM platform, we did this for amdgpu,
but somehow i915 should get a pass?

On what ground? What should we tell the next driver that uses the same
argument?

> > 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'm not sure how pointing fingers at who has the right design,
overlooked some hypothetical usages 10y down the line, or is being
offhand helps the conversation in any way.

I've been asking questions to understand what you could work with, and
some are still left unanswered, and had to ask others multiple times to
get an answer.

And maybe I do indeed underestimate the amount of work it would take. I
don't believe so, and I still believe that it wouldn't be too hard. But
maybe you're right. You still haven't explained why it would take
anything more than registering a dumb device at probe time though.

> > 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.

I believe calling drm_panel_init would be a middle ground, if we add a
bunch of warnings, checks here and there and move things around a bit.
But to keep it, we do need a good reason for it, even more so if we
don't have any in-tree users anymore.

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20250519/300f26ad/attachment.sig>