Hi, On Thu, Jul 29, 2021 at 1:27 PM Rob Herring <robh@xxxxxxxxxx> wrote: > > IMO, you should move any applicable compatibles to the edp-panel schema. > Also, I don't think you should add 'edp-panel' to them. If they can work > better with the generic eDP driver, then that should be an internal > kernel change without a DT change. Also, if 2 different drivers match on > compatible, it's a roll of the dice which driver binds. So overall what I was going for is this: 1. I want to be able to specify _just_ "edp-panel" for new boards. We'll make sure this is how it looks on devices that go through the factory and thus we can make sure that the driver can recognize all panels that get shipped. 2. For existing boards, I'd like to be able to move them to use "edp-panel" but I'm less confident that I can really say exactly what panels are out there in the field. Even though our device tree has always listed only one panel, in truth boards have shipped with more than one and they've just been "compatible enough" with each other (this "white lie" is what I'm trying to fix). If somehow the generic "edp-panel" doesn't recognize a panel then I wanted to be able to use the old timings we'd always had before as a "fallback". That means that logically I wanted "edp-panel" to be first and only fallback to the old compatible string if we didn't recognize the panel ID that came from the EDID. In truth, both compatible strings are handled by the same driver the driver patch I submitted tried to be smart. Perhaps that above is over ambitious and it'd be better to just drop the whole "fallback" concept. If a board manufacturer wants to start using the "edp-panel" concept then maybe the right idea is to force them to bump the "board id" and then we can pick a new device tree revision. Then we can make sure all boards that come out of the factory with that new "board id" can be identified properly in the EDID. This will also get rid of some of the complexity in the driver patch, which is nice. I'll plan on doing this and address your other feedback for a v2. -Doug
