All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Thierry Reding <treding@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] drm: panels: Add MAINTAINERS entry for LVS panel driver
Date: Tue, 11 Apr 2017 12:10:47 -0500	[thread overview]
Message-ID: <CAL_JsqL=skn0XBbw7Twb0U+01w=E=5rNUYDsEdEgH4T-p_Vf-A@mail.gmail.com> (raw)
In-Reply-To: <20170407173308.GA3984@ulmo.ba.sec>

On Fri, Apr 7, 2017 at 12:33 PM, Thierry Reding <treding@nvidia.com> wrote:
> On Fri, Apr 07, 2017 at 05:44:15AM +1000, Dave Airlie wrote:
>> On 5 April 2017 at 16:51, Laurent Pinchart
>> <laurent.pinchart+renesas@ideasonboard.com> wrote:
>> > As the DRM LVDS panel driver uses a different approach to DT bindings
>> > compared to what Thierry Reding advocates, add a specific MAINTAINERS
>> > entry to avoid bothering Thierry with requests related to that driver.

This is not a good split. Panels should not be diverging based on
interface. That's not to say we can't have sub-classed bindings based
on interfaces.

>> Could you document a bit more in the patch summary the finer points of
>> panel/dt doctrine, as I haven't got as much knowledge as I'd like.
>>
>> Just I believe, Thierry believes.
>
> I'm somewhat surprised how we arrived at the current situation. A very
> long time ago when we first discussed device tree bindings for panels, a
> number of attempts were made to generically describe everything in
> device tree. All of those attempts failed because you simply couldn't
> describe all of the required properties in DT in a sane way.
>
> Eventually everyone involved agreed that we would have to stick with the
> device-specific compatible, and in the best case we would be able to
> support many panels with a fairly generic driver. I think we did pretty
> well with the panel-simple driver. It started out very simple and then
> got improved over time as necessary to deal with more panels. And for
> cases where it wasn't suitable we simply added a custom driver. That's a
> completely natural way to write drivers. We do the same thing in other
> areas, nothing special here.

That is still the case here.

> Ever since the simple-panel binding was introduced, which is now about
> 3 1/2 years ago, people have kept asking why we couldn't simply put all
> data in DT and why kernel drivers had to be modified in order to add
> support for a new panel. I kept repeating myself a number of times until
> I finally wrote it all up[0], after which it was enough to point people
> to it. Still not everyone was convinced, but the people that were there
> when we made the decision all agreed that this was still the right thing
> to do. So, despite the many complaints I stuck to what we had agreed on
> because I am convinced that it is the right thing to do.

The big difference was folks wanted "simple-panel" compatible strings
and nothing else. That remains wrong and is a constant discussion. I'd
say at least 30% of my reviews contain "needs a more specific
compatible string". Panels are not the only "simple" or "generic"
hardware. :)

Parameterizing everything is indeed a losing battle. That doesn't mean
we can't parameterize some things in DT if they are completely
standard. IMO, roughly anything that can be in EDID could be in DT. So
I don't have a big problem with timings or physical size of the
display in DT. After all, we can always just ignore it.

> Now we have arrived at a point where apparently that decision has been
> revoked, and I don't understand what's changed. This puts me in a very
> difficult position. All of a sudden it's okay to do what everyone has
> been asking for the last three years, and I'm the jerk who told everyone
> that it couldn't be done.
>
> Maybe the discussions that we had back at the time are now far enough in
> the past that people have forgotten about the earlier failures. I still
> don't see how this new panel-lvds would be any more successful in
> solving the problems we failed to solve with simple-panel. The issues
> are still fundamentally the same. Now if this was a generic driver that
> dealt with a different subset of panels because they are different, that
> would've been okay with me. What I don't understand is why this has to
> deviate from the simple-panel binding in fundamental ways. Now we've got
> two bindings and we make life miserable for people because they have to
> choose between the two.
>
> Thierry
>
> [0]: https://sietch-tagr.blogspot.de/2016/04/display-panels-are-not-special.html

I appreciate your excellent write-up very much. I've directed people
to it numerous times.

Rob
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2017-04-11 17:11 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-04 14:17 [GIT PULL FOR v4.12] Renesas R-Car Gen3 DU HDMI support Laurent Pinchart
2017-04-04 15:21 ` Thierry Reding
2017-04-04 15:38   ` Laurent Pinchart
2017-04-04 16:03     ` Daniel Vetter
2017-04-07 17:40       ` Thierry Reding
2017-04-05  6:51 ` [PATCH] drm: panels: Add MAINTAINERS entry for LVS panel driver Laurent Pinchart
2017-04-05  6:56   ` Laurent Pinchart
2017-04-05  7:47     ` Jani Nikula
2017-04-06 19:44   ` Dave Airlie
2017-04-07 17:33     ` Thierry Reding
2017-04-09 12:31       ` Emil Velikov
2017-04-10  7:17         ` Thierry Reding
2017-04-10  9:03           ` Laurent Pinchart
2017-04-10 19:27             ` Dave Airlie
2017-04-11  4:41               ` Laurent Pinchart
2017-04-11 18:56               ` Rob Herring
2017-04-12 15:44                 ` Thierry Reding
2017-04-12 17:42                   ` Daniel Vetter
2017-04-12 19:46                     ` Alex Deucher
2017-04-10  9:58           ` Lucas Stach
2017-04-10 11:38             ` Emil Velikov
2017-04-11  5:00             ` Laurent Pinchart
2017-04-11 10:03               ` Thierry Reding
2017-04-11 17:10       ` Rob Herring [this message]
2017-04-12 15:26         ` Thierry Reding
2017-04-12 23:27           ` Rob Herring

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='CAL_JsqL=skn0XBbw7Twb0U+01w=E=5rNUYDsEdEgH4T-p_Vf-A@mail.gmail.com' \
    --to=robh@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=treding@nvidia.com \
    /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.