On Fri, Jun 5, 2026 at 10:44 AM Doug Anderson <[email protected]> wrote: > > Hi, > > On Fri, Jun 5, 2026 at 8:28 AM Rob Herring <[email protected]> wrote: > > > > > > --- > > > > a/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml > > > > +++ > > > > b/Documentation/devicetree/bindings/display/panel/samsung,atna33xc20.yaml > > > > @@ -25,6 +25,8 @@ properties: > > > > - samsung,atna40ct06 > > > > # Samsung 14" WQXGA+ (2880x1800 pixels) eDP AMOLED panel > > > > - samsung,atna40cu11 > > > > + # Samsung 14" WQXGA+ (2880x1800 pixels) eDP AMOLED panel > > > > + - samsung,atna40hq08 > > > > > > Sure. I'll repeat the same comment I made the last time someone landed > > > a change to this file [1] in the hopes that maybe someone will post a > > > patch one day: > > > > > > <repeat> > > > Given how many of these we're up to now, I'm starting to wonder if we > > > should come up with a generic compatible like we did with "edp-panel" > > > and then we can stop having to merge CLs like this. All of these > > > Samsung OLED eDP panels have the same power up sequence and once we do > > > that then we can read them via EDID or via DP AUX bus to identify > > > which specific panel we have and if they need additional tweaking, > > > just like we do with "edp-panel". Do DT folks have any opinion about > > > that? Coming up with a name would be a pain since I wouldn't want to > > > assert that all future Samsung OLED eDP panels will have the same > > > powerup sequence. Maybe "samsung,amoled-edp-panel-v1" even though that > > > sounds terrible and there's no known need for a "-v2"? > > > </repeat> > > > > If things are the same, then perhaps there should be a fallback > > compatible. Or just reuse an existing compatible. > > Right, there already is a fallback comparible. This patch is just > adding a string to the enum that has the fallback compatible > "samsung,atna33xc20". So someone using this new panel will use: > > compatible = "samsung,atna40hq08", "samsung,atna33xc20" > > My point was that listing specific panel isn't really valuable here. > Though the "samsung" power sequence isn't completely compatible with > the generic "eDP panel" power sequence (which is why they have > separate drivers), just like generic "eDP panel"s we can query the > panel ID if there are any per-panel quirks.
Unless the quirk is how to power on/off the panel... > So the question is: should we stop adding specific panels and just > always list "samsung,atna33xc20" for all Samsung panels with a > compatible power sequence, is it worth it to add a more generic name, > or should we really keep listing all these individual panels for no > real gain. > > > > I can in no way > > prevent someone from using 'foo-panel' in their DT when the h/w is > > actually a foobar panel if the differences are transparent to s/w. (But > > I will reject a quirk property later on when foobar turns out to be > > different than foo.) > > It's more a question of what guidance we tell people. Here, Konrad is > trying to do "the right thing" by listing his specific panel and then > using the fallback. I'm saying "listing the specific panel isn't > gaining you anything" and I'd rather not have to review / apply these > pointless additions to the bindings. I think the guidance is clear. Overall, doing something special here because Samsung panels are special just muddies what the right thing is for everyone else. > ...but I can imagine people will be upset if I tell them to list > "samsung,atna33xc20" for all compatible Samsung AMOLED panels. It > would be nicer to come up with some sort of generic name? Well yes, people have a hard time using compatible strings that don't sound generic. That's too bad for them. Rob
