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

[Stephan Gerhold <stephan.gerhold@linaro.org>]

On Mon, Jul 15, 2024 at 03:01:57PM +0200, Neil Armstrong wrote:
> On 15/07/2024 14:54, Stephan Gerhold wrote:
> > On Mon, Jul 15, 2024 at 02:42:12PM +0200, Neil Armstrong wrote:
> > > On 15/07/2024 14:15, Stephan Gerhold wrote:
> > > > This reverts commit 8ebb1fc2e69ab8b89a425e402c7bd85e053b7b01.
> > > > 
> > > > The panel should be handled through the samsung-atna33xc20 driver for
> > > > correct power up timings. Otherwise the backlight does not work correctly.
> > > > 
> > > > 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.
> > > > 
> > > > Reviewed-by: Douglas Anderson <dianders@chromium.org>
> > > > Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
> > > > ---
> > > >    drivers/gpu/drm/panel/panel-edp.c | 2 --
> > > >    1 file changed, 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c
> > > > index 3a574a9b46e7..d2d682385e89 100644
> > > > --- a/drivers/gpu/drm/panel/panel-edp.c
> > > > +++ b/drivers/gpu/drm/panel/panel-edp.c
> > > > @@ -1960,8 +1960,6 @@ static const struct edp_panel_entry edp_panels[] = {
> > > >    	EDP_PANEL_ENTRY('L', 'G', 'D', 0x05af, &delay_200_500_e200_d200, "Unknown"),
> > > >    	EDP_PANEL_ENTRY('L', 'G', 'D', 0x05f1, &delay_200_500_e200_d200, "Unknown"),
> > > > -	EDP_PANEL_ENTRY('S', 'D', 'C', 0x416d, &delay_100_500_e200, "ATNA45AF01"),
> > > > -
> > > >    	EDP_PANEL_ENTRY('S', 'H', 'P', 0x1511, &delay_200_500_e50, "LQ140M1JW48"),
> > > >    	EDP_PANEL_ENTRY('S', 'H', 'P', 0x1523, &delay_80_500_e50, "LQ140M1JW46"),
> > > >    	EDP_PANEL_ENTRY('S', 'H', 'P', 0x153a, &delay_200_500_e50, "LQ140T1JH01"),
> > > > 
> > > 
> > > 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.
> 
> I consider this as a regression
> 

Personally, I don't think we can regress something that was already
broken. There is no point in continuing to use the broken state - it is
rather frustrating if your display goes off for power saving or suspend
and you cannot get it back on until you reboot.

> > 
> > > 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 don't know how to answer this, I'll let the DT maintainer comment this.
> 
> The problem is I do not think we can pass the whole patchset as fixes
> for v6.11, patches 2 & 3 could, patches 1 & 4 definitely can't.
> 

Fair enough, I'm also fine if these patches go just into 6.12. I think
there are no changes in the patches needed for that, the Fixes tag is
still appropriate and I intentionally omitted the Cc stable tag.

Thanks,
Stephan