Hi, On Thu, Jul 18, 2024 at 9:25 AM Rob Clark <robdclark@xxxxxxxxx> wrote: > > On Thu, Jul 18, 2024 at 9:00 AM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > > > Hi, > > > > On Wed, Jul 17, 2024 at 6:09 PM Rob Clark <robdclark@xxxxxxxxx> wrote: > > > > > > On Wed, Jul 17, 2024 at 5:19 PM Doug Anderson <dianders@xxxxxxxxxxxx> wrote: > > > > > > > > Hi, > > > > > > > > On Wed, Jul 17, 2024 at 2:58 PM Rob Clark <robdclark@xxxxxxxxx> wrote: > > > > > > > > > > From: Rob Clark <robdclark@xxxxxxxxxxxx> > > > > > > > > > > Just a guess on the panel timings, but they appear to work. > > > > > > > > > > Signed-off-by: Rob Clark <robdclark@xxxxxxxxxxxx> > > > > > --- > > > > > This adds the panel I have on my lenovo yoga slim 7x laptop. I couldn't > > > > > find any datasheet so timings is just a guess. But AFAICT everything > > > > > works fine. > > > > > > > > > > drivers/gpu/drm/panel/panel-edp.c | 2 ++ > > > > > 1 file changed, 2 insertions(+) > > > > > > > > Given that this is a Samsung ATNA<mumble>, is there any chance it's an > > > > OLED panel? Should it be supported with the Samsung OLED panel driver > > > > like this: > > > > > > > > https://lore.kernel.org/r/20240715-x1e80100-crd-backlight-v2-0-31b7f2f658a3@xxxxxxxxxx > > > > > > it is an OLED panel, and I did see that patchset and thought that > > > samsung panel driver would work. But changing the compat string on > > > the yoga dts only gave me a black screen (and I didn't see any of the > > > other mentioned problems with bl control or dpms with panel-edp). So > > > :shrug:? It could be I overlooked something else, but it _seems_ like > > > panel-edp is fine for this panel. Plus, it would avoid awkwardness if > > > it turned out there were other non-samsung 2nd sources, but so far > > > with a sample size of two 100% of these laptops have the same panel > > > > Hmm, OK. One question for you: are you using the "enable" GPIO in > > panel-edp? IMO the code handling that GPIO in panel-edp is somewhat > > dodgy, but it predates my deeper involvement with panels. I've never > > seen an eDP panel that could use panel-edp where it was actually > > required--every instance where someone thought it was required was > > better modeled by using that GPIO as the backlight enable. On the > > other hand, the "enable" GPIO in the Samsung OLED panel driver came > > straight from the panel datasheet and it makes sense for it to be in > > the panel driver since the backlight is handled straight by the > > panel... > > hmm, at least current dts doesn't have an enable gpio. Which could be > why panel-samsung-atna33xc20 wasn't working. > > It is entirely possible we are relying on something left on by the bootloader. That would be my best guess. Is there any way for you to find out if there's an enable GPIO? > > In any case, I guess if things are working it doesn't really hurt to > > take it in panel-edp for now... > > > > I wonder if using compatible="edp-panel" everywhere isn't a great idea > if we want to switch drivers later. But I guess that is already water > under the bridge (so to speak) For panels that aren't OLED it's all very standard and we're kinda forced to use something generic since manufacturers want lots of 2nd (and 3rd and 4th and ...) sourcing. As far as I've been able to tell you can't do 2nd sourcing between OLED panels and other panels since the wires hooked up to the panels are a little different for the OLED panels and the power sequencing is a bit different. It would also be pretty obvious to an end user if some of their devices had an OLED panel and some didn't. I'm not aware of OLED panels other than the Samsung ones, but I haven't done any real research here... -Doug
