Hi, On Fri, Jun 5, 2026 at 10:14 AM Rob Herring <[email protected]> wrote: > > 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...
Well, only if the quirk is how to power "on" the panel. ;-) If a panel does need different power-on processing, then I'd expect a new compatible string unless we end up in the situation we had with eDP panels where there is a ton of second-sourcing going on and the quirk is relatively benign (like the "hpd-reliable-delay-ms" and "hpd-absent-delay-ms" properties for "edp-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. OK, so sounds like going forward I should NAK changes to this file and tell people to just use: compatible = "samsung,atna33xc20"; ...to mean "Generic Samsung AMOLED panel with power sequencing that matches atna33xc20" Yes, it means that if we find quirks with a specific panel later, it could possibly be harder to work around them. However, since we have several ways to identify the panel (via EDID and via DDC) this seems fairly low risk. You can't perfectly predict the future anyway. -Doug
