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. 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. ...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? -Doug
