Re: [PATCH v2 2/4] Revert "drm/panel-edp: Add SDC ATNA45AF01"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 15, 2024 at 02:54:59PM +0200, Stephan Gerhold wrote:
> On Mon, Jul 15, 2024 at 02:42:12PM +0200, Neil Armstrong wrote:

> > How will we handle current/old crd DT with new kernels ?
> 
> I think this is answered in the commit message:
> 
> > > We have existing users of this panel through the generic "edp-panel"
> > > compatible (e.g. the Qualcomm X1E80100 CRD), but the screen works only
> > > partially in that configuration: It works after boot but once the screen
> > > gets disabled it does not turn on again until after reboot. It behaves the
> > > same way with the default "conservative" timings, so we might as well drop
> > > the configuration from the panel-edp driver. That way, users with old DTBs
> > > will get a warning and can move to the new driver.
> 
> Basically with the entry removed, the panel-edp driver will fallback to
> default "conservative" timings when using old DTBs. There will be a
> warning in dmesg, but otherwise the panel will somewhat work just as
> before. I think this is a good way to remind users to upgrade.
> 
> > Same question for patch 3, thie serie introduces a bindings that won't be valid
> > if we backport patch 3. I don't think patch should be backported, and this patch
> > should be dropped.
> 
> There would be a dtbs_check warning, yeah. Functionally, it would work
> just fine. Is that reason enough to keep display partially broken for
> 6.11? We could also apply the minor binding change for 6.11 if needed.
> 
> I'm also fine if this just goes into 6.12 though.

No, we should definitely fix this for 6.11. This machine is not very
useable without it. Whether to backport is a separate question, but note
that patch 3 is not even marked for backport currently.

Fixing the backlight at the cost of a dtb checker warning should not be
an issue, but backporting would break existing setups unless people have
the new panel driver enabled and this may be a valid concern. On the
other hand, support for this platform is in a bit of flux already and it
looks like most fixes aren't even tagged for stable (presumably for that
reason).

Johan




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux