Re: [PATCH v3 00/16] eDP: Support probing eDP panels dynamically instead of hardcoding

2021-09-08 Thread Doug Anderson
Hi, On Sun, Sep 5, 2021 at 11:55 AM Sam Ravnborg wrote: > > Hi Douglas, > > On Wed, Sep 01, 2021 at 01:19:18PM -0700, Douglas Anderson wrote: > > The goal of this patch series is to move away from hardcoding exact > > eDP panels in device tree files. As discussed in the various patches > > in thi

Re: [PATCH v3 00/16] eDP: Support probing eDP panels dynamically instead of hardcoding

2021-09-05 Thread Sam Ravnborg
Hi Douglas, On Wed, Sep 01, 2021 at 01:19:18PM -0700, Douglas Anderson wrote: > The goal of this patch series is to move away from hardcoding exact > eDP panels in device tree files. As discussed in the various patches > in this series (I'm not repeating everything here), most eDP panels > are 99%

Re: [PATCH v3 00/16] eDP: Support probing eDP panels dynamically instead of hardcoding

2021-09-02 Thread Doug Anderson
Hi, On Thu, Sep 2, 2021 at 3:10 PM Andrzej Hajda wrote: > > Removed most CC: SMTP server protested. Yeah, it was because of the dang defconfig patches. My general policy is to send the cover letter to everyone even if not everyone gets CCed on all patches, but it ended up as a lot... Speaking of

Re: [PATCH v3 00/16] eDP: Support probing eDP panels dynamically instead of hardcoding

2021-09-02 Thread Andrzej Hajda
Removed most CC: SMTP server protested. On 01.09.2021 22:19, Douglas Anderson wrote: > The goal of this patch series is to move away from hardcoding exact > eDP panels in device tree files. As discussed in the various patches > in this series (I'm not repeating everything here), most eDP panels

[PATCH v3 00/16] eDP: Support probing eDP panels dynamically instead of hardcoding

2021-09-01 Thread Douglas Anderson
The goal of this patch series is to move away from hardcoding exact eDP panels in device tree files. As discussed in the various patches in this series (I'm not repeating everything here), most eDP panels are 99% probable and we can get that last 1% by allowing two "power up" delays to be specified