[PATCH 0/1][SRU][OEM-OSP1-B][B][E][F] Another Dell AIO backlight issue

[AceLan Kao]

No, I only verified it on the buggy machine.

This patch make the retry block to also contain write command, so we
not only keep reading the response,
but also re-sending our commands while retrying.
This shouldn't introduce any regression, and also fixes the previous
issue that we tried to increase the retry timeout.

>From what ODM describes, the scalar also responsible for activating panel,
so it's busy during booting up and can't respond UART commands quick enough.

>From what we observed, it usually responds the UART command around 2 seconds,
and in some rare cases, it doesn't respond the first command, and the
read retry will keep reading the response until at around 18th second
of kernel time.
Keep re-sending our commands in retry block fixed both issues, and the
worst case I see on the buggy machine is we receive the response
at around 13th second. And after around 13th second, scalar is able to
respond the UART commands immediately.


Seth Forshee <seth.forshee at canonical.com> 於 2020年2月20日 週四 下午9:37寫道：
>
> On Thu, Feb 20, 2020 at 09:20:31AM +0800, AceLan Kao wrote:
> > BugLink: https://bugs.launchpad.net/bugs/1863880
> >
> > [Impact]
> > The scalar which controls the backlight sometimes doesn't respond the first
> > command, so driver can't determinate whether this scalar is in charge of
> > the backlight or not.
> >
> > [Fix]
> > Move the retry block not only to read the response, but also includes
> > write command, so that it re-send the command, too.
> >
> > [Test]
> > Verified on the buggy Dell AIO, it passes 30 times and should be more
> > reliable.
> >
> > [Regression Potential]
> > Low, there is no code flow change, just move the retry block to include
> > both write and read command.
>
> Did you do regression testing on any machines besides the one fixed by
> this patch?
>
> Thanks,
> Seth