From: Maxime Ripard <maxime@cerno.tech>
To: Roman Stratiienko <r.stratiienko@gmail.com>
Cc: wens@csie.org, "Jernej Škrabec" <jernej.skrabec@gmail.com>,
airlied@linux.ie, "Daniel Vetter" <daniel@ffwll.ch>,
"Samuel Holland" <samuel@sholland.org>,
dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org,
linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org,
megi@xff.cz
Subject: Re: [PATCH] drm/sun4i: sun8i: Add the ability to keep scaler enabled for VI layer
Date: Fri, 3 Jun 2022 16:19:37 +0200 [thread overview]
Message-ID: <20220603141937.modhvsqa3urmpcxr@penduick> (raw)
In-Reply-To: <CAGphcdkPJ57bkw4nxuSnk0TD1RGW5j9M-A0ek6t1rDnMY2PS8Q@mail.gmail.com>
On Fri, Jun 03, 2022 at 11:57:35AM +0300, Roman Stratiienko wrote:
> Hi Maxime,
>
> пт, 3 июн. 2022 г. в 11:24, Maxime Ripard <maxime@cerno.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@gmail.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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2022-06-03 14:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-02 18:01 [PATCH] drm/sun4i: sun8i: Add the ability to keep scaler enabled for VI layer Roman Stratiienko
2022-06-02 21:55 ` Ondřej Jirman
2022-06-03 7:16 ` Roman Stratiienko
2022-06-03 8:24 ` Maxime Ripard
2022-06-03 8:57 ` Roman Stratiienko
2022-06-03 14:19 ` Maxime Ripard [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220603141937.modhvsqa3urmpcxr@penduick \
--to=maxime@cerno.tech \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=jernej.skrabec@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sunxi@lists.linux.dev \
--cc=megi@xff.cz \
--cc=r.stratiienko@gmail.com \
--cc=samuel@sholland.org \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox