All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Maxime Ripard <mripard@kernel.org>
Cc: Anusha Srivatsa <asrivats@redhat.com>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Jessica Zhang <quic_jesszhan@quicinc.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	Luca Ceresoli <luca.ceresoli@bootlin.com>
Subject: Re: [PATCH v4 2/4] drm/panel: Add refcount support
Date: Wed, 14 May 2025 12:22:40 +0300	[thread overview]
Message-ID: <875xi3im1r.fsf@intel.com> (raw)
In-Reply-To: <molexnyjkiryvhetfdc66gmzecrf6f7kxl656qn46djdkixrkb@fdgnp5hispbf>

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 Nikula, Intel

  reply	other threads:[~2025-05-14  9:22 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-31 15:15 [PATCH v4 0/4] drm/panel: Panel Refcounting infrastructure Anusha Srivatsa
2025-03-31 15:15 ` [PATCH v4 1/4] drm/panel: Add new helpers for refcounted panel allocatons Anusha Srivatsa
2025-03-31 15:15 ` [PATCH v4 2/4] drm/panel: Add refcount support Anusha Srivatsa
2025-04-28 16:31   ` Jani Nikula
2025-04-29  9:00     ` Maxime Ripard
2025-04-29  9:22       ` Jani Nikula
2025-05-05  6:53         ` Maxime Ripard
2025-05-05 18:52           ` Anusha Srivatsa
2025-05-08 14:27             ` Jani Nikula
2025-05-08 21:48               ` Anusha Srivatsa
2025-05-09  9:24                 ` Jani Nikula
2025-05-09 11:41               ` Maxime Ripard
2025-05-09 12:45                 ` Jani Nikula
2025-05-13  2:40                   ` Anusha Srivatsa
2025-05-13 12:19                     ` Jani Nikula
2025-05-13 13:06                   ` Maxime Ripard
2025-05-14  9:22                     ` Jani Nikula [this message]
2025-05-16 19:43                       ` Anusha Srivatsa
2025-05-19 12:23                         ` Jani Nikula
2025-05-19 16:05                       ` Maxime Ripard
2025-05-20 10:09                         ` Jani Nikula
2025-05-23 11:34                           ` Jani Nikula
2025-05-27 15:04                             ` Maxime Ripard
2025-05-27 19:24                               ` Jani Nikula
2025-05-27 14:57                           ` Maxime Ripard
2025-05-27 19:40                             ` Jani Nikula
2025-06-06  7:33                               ` Maxime Ripard
2025-06-06  9:11                                 ` Jani Nikula
2025-03-31 15:15 ` [PATCH v4 3/4] drm/panel: deprecate old-style panel allocation Anusha Srivatsa
2025-03-31 15:15 ` [PATCH v4 4/4] drm/panel/panel-simple: Use the new allocation in place of devm_kzalloc() Anusha Srivatsa
2025-04-01 15:05 ` [PATCH v4 0/4] drm/panel: Panel Refcounting infrastructure Maxime Ripard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875xi3im1r.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=airlied@gmail.com \
    --cc=asrivats@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luca.ceresoli@bootlin.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=quic_jesszhan@quicinc.com \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.