lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20220603141937.modhvsqa3urmpcxr@penduick>
Date:   Fri, 3 Jun 2022 16:19:37 +0200
From:   Maxime Ripard <maxime@...no.tech>
To:     Roman Stratiienko <r.stratiienko@...il.com>
Cc:     wens@...e.org,
        Jernej Škrabec <jernej.skrabec@...il.com>,
        airlied@...ux.ie, Daniel Vetter <daniel@...ll.ch>,
        Samuel Holland <samuel@...lland.org>,
        dri-devel@...ts.freedesktop.org,
        linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
        linux-kernel@...r.kernel.org, megi@....cz
Subject: Re: [PATCH] drm/sun4i: sun8i: Add the ability to keep scaler enabled
 for VI layer

On Fri, Jun 03, 2022 at 11:57:35AM +0300, Roman Stratiienko wrote:
> Hi Maxime,
> 
> пт, 3 июн. 2022 г. в 11:24, Maxime Ripard <maxime@...no.tech>:
> >
> > Hi,
> >
> > On Thu, Jun 02, 2022 at 06:01:18PM +0000, Roman Stratiienko wrote:
> > > According to DE2.0/DE3.0 manual VI scaler enable register is double
> > > buffered, but de facto it doesn't, or the hardware has the shadow
> > > register latching issues which causes single-frame picture corruption
> > > after changing the state of scaler enable register.
> > >
> > > Allow the user to keep the scaler always enabled, preventing the UI
> > > glitches on the transition from scaled to unscaled state.
> > >
> > > NOTE:
> > > UI layer scaler has more registers with double-buffering issue and can't
> > > be workarounded in the same manner.
> > >
> > > You may find a python test and a demo video for this issue at [1]
> > >
> > > [1]: https://github.com/GloDroid/glodroid_tests/issues/4
> >
> > Please describe the issue entirely here. The commit log must be self-sufficient.
> 
> Commit message already states "single-frame picture corruption after
> changing the state of scaler enable register", therefore I find it
> already self-sufficient
> 
> Also I find demo videos and link to tests useful for the followers to
> go further with investigation.

Until a couple of years, where that URL isn't valid anymore and it's just useless.

> If you have something specific in mind when asking to enhance the
> commit message please say it.

What sequence of events trigger the issue, what issue it triggers and
why your solution addresses it would be nice

> > > Signed-off-by: Roman Stratiienko <r.stratiienko@...il.com>
> > > ---
> > >  drivers/gpu/drm/sun4i/sun8i_mixer.c    | 12 ++++++++++++
> > >  drivers/gpu/drm/sun4i/sun8i_vi_layer.c |  4 +++-
> > >  2 files changed, 15 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > > index 71ab0a00b4de..15cad0330f66 100644
> > > --- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > > +++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
> > > @@ -27,6 +27,18 @@
> > >  #include "sun8i_vi_layer.h"
> > >  #include "sunxi_engine.h"
> > >
> > > +/* According to DE2.0/DE3.0 manual VI scaler enable register is double
> > > + * buffered, but de facto it doesn't, or the hardware has the shadow
> > > + * register latching issues which causes single-frame picture corruption
> > > + * after changing the state of scaler enable register.
> > > + * Allow the user to keep the scaler always enabled, preventing the UI
> > > + * glitches on the transition from scaled to unscaled state.
> > > + */
> > > +int sun8i_vi_keep_scaler_enabled;
> > > +MODULE_PARM_DESC(keep_vi_scaler_enabled,
> > > +              "Keep VI scaler enabled (1 = enabled, 0 = disabled (default))");
> > > +module_param_named(keep_vi_scaler_enabled, sun8i_vi_keep_scaler_enabled, int, 0644);
> > > +
> >
> > It's not clear to me why we would want to make that a parameter?
> >
> >1 If it never works, we should fix it once and for all and not allow a broken setup at all.
> 
> It's a hardware issue and can be fixed only within the hardware.
> 
> Current patch is a workaround that if enabled can cause increased
> power consumption for existing users. Therefore I think it is better
> to give existing distro-maintainers a chance to test it prior to
> delivery.

Except distro-maintainers are likely never going to notice that flag
exists in the first place, won't be using it and thus the issue will
remain.

Maxime

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ