On Fri, Apr 7, 2017 at 12:33 PM, Thierry Reding <treding@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
