[PATCH] drm: panels: Add MAINTAINERS entry for LVS panel driver

[Rob Herring]

On Fri, Apr 7, 2017 at 12:33 PM, Thierry Reding <treding at 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 at 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