Here is a patch series that adds initial display support for the LG
Nexus 5 (hammerhead) phone. It's not fully working so that's why some
of these patches are RFC until we can get it fully working.
The phones boots into terminal mode, however there is a several second
(or more) delay when writing to tty1 compared to when the changes are
actually shown on the screen. The following errors are in dmesg:
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:49:crtc-0] flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:32:plane-0] flip_done timed out
WARNING: CPU: 0 PID: 5 at drivers/gpu/drm/drm_atomic_helper.c:1430 drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290
[CRTC:49:crtc-0] vblank wait timed out
Modules linked in:
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.1.0-rc6-next-20190426-00006-g35c0d32a96e1-dirty #191
Hardware name: Generic DT based system
Workqueue: events deferred_probe_work_func
[<c031229c>] (unwind_backtrace) from [<c030d5ac>] (show_stack+0x10/0x14)
[<c030d5ac>] (show_stack) from [<c0ac134c>] (dump_stack+0x78/0x8c)
[<c0ac134c>] (dump_stack) from [<c0321660>] (__warn.part.3+0xb8/0xd4)
[<c0321660>] (__warn.part.3) from [<c03216e0>] (warn_slowpath_fmt+0x64/0x88)
[<c03216e0>] (warn_slowpath_fmt) from [<c0761a0c>] (drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290)
[<c0761a0c>] (drm_atomic_helper_wait_for_vblanks.part.1) from [<c07b0a98>] (mdp5_complete_commit+0x14/0x40)
[<c07b0a98>] (mdp5_complete_commit) from [<c07ddb80>] (msm_atomic_commit_tail+0xa8/0x140)
[<c07ddb80>] (msm_atomic_commit_tail) from [<c0763304>] (commit_tail+0x40/0x6c)
[<c07633f4>] (drm_atomic_helper_commit) from [<c07667f0>] (restore_fbdev_mode_atomic+0x168/0x1d4)
....
I can get the text console to work with a 4.17 kernel with this patch
https://patchwork.kernel.org/patch/10321845/ plus about a dozen or more
other patches that have been mainlined since that release.
I'm new to the DRM subsystem and continuing to dig into the issue,
however I'd appreciate any suggestions. I suspect the issue lies
somewhere in the second patch in this series.
Changes since v1:
- Shortened problem description above. I'll reply to this email and send
a full dmesg with the boot log with debugging turned on.
- Dropped patch 'fix null pointer dereference in
msm_atomic_prepare_fb()'
- New patch: Remove resv fields from msm_gem_object struct that was
incorrectly being referenced by the prepare_fb callbacks.
- Add drm_plane_enable_fb_damage_clips() to plane init for mdp4, mdp5,
and dpu1.
- Add Linus Walleij's reviewed-by to patches 3-6
Brian Masney (6):
drm: msm: remove resv fields from msm_gem_object struct
drm: msm: add dirty framebuffer helper
ARM: qcom_defconfig: add display-related options
ARM: dts: msm8974: add display support
ARM: dts: qcom: msm8974-hammerhead: add support for backlight
ARM: dts: qcom: msm8974-hammerhead: add support for display
.../qcom-msm8974-lge-nexus5-hammerhead.dts | 79 +++++++++++
arch/arm/boot/dts/qcom-msm8974.dtsi | 132 ++++++++++++++++++
arch/arm/configs/qcom_defconfig | 5 +
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 7 +-
drivers/gpu/drm/msm/disp/mdp4/mdp4_plane.c | 3 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 3 +
drivers/gpu/drm/msm/msm_atomic.c | 4 +-
drivers/gpu/drm/msm/msm_fb.c | 2 +
drivers/gpu/drm/msm/msm_gem.c | 3 -
drivers/gpu/drm/msm/msm_gem.h | 4 -
10 files changed, 229 insertions(+), 13 deletions(-)
--
2.20.1
On Wed, May 08, 2019 at 10:03:46PM -0400, Brian Masney wrote:
> Here is a patch series that adds initial display support for the LG
> Nexus 5 (hammerhead) phone. It's not fully working so that's why some
> of these patches are RFC until we can get it fully working.
>
> The phones boots into terminal mode, however there is a several second
> (or more) delay when writing to tty1 compared to when the changes are
> actually shown on the screen. The following errors are in dmesg:
I attached the full dmesg output with this patch series applied. I
enabled debugging messages for just the DRM subsystem.
Brian
On Thu, May 9, 2019 at 4:04 AM Brian Masney <[email protected]> wrote:
> Here is a patch series that adds initial display support for the LG
> Nexus 5 (hammerhead) phone. It's not fully working so that's why some
> of these patches are RFC until we can get it fully working.
>
> The phones boots into terminal mode, however there is a several second
> (or more) delay when writing to tty1 compared to when the changes are
> actually shown on the screen. The following errors are in dmesg:
I tested to apply patches 2-6 and got the console up on the phone as well.
I see the same timouts, and I also notice the update is slow in the
display, as if the DSI panel was running in low power (LP) mode.
Was booting this to do some other work, but happy to see the progress!
Yours,
Linus Walleij
On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> On Thu, May 9, 2019 at 4:04 AM Brian Masney <[email protected]> wrote:
>
> > Here is a patch series that adds initial display support for the LG
> > Nexus 5 (hammerhead) phone. It's not fully working so that's why some
> > of these patches are RFC until we can get it fully working.
> >
> > The phones boots into terminal mode, however there is a several second
> > (or more) delay when writing to tty1 compared to when the changes are
> > actually shown on the screen. The following errors are in dmesg:
>
> I tested to apply patches 2-6 and got the console up on the phone as well.
> I see the same timouts, and I also notice the update is slow in the
> display, as if the DSI panel was running in low power (LP) mode.
>
> Was booting this to do some other work, but happy to see the progress!
Thanks!
I've had three people email me off list regarding the display working on
4.17 before the msm kms/drm driver was converted to the DRM atomic API so
this email is to get some more information out publicly.
I pushed up a branch to my github with 15 patches applied against 4.17
that has a working display:
https://github.com/masneyb/linux/commits/display-works-4.17
It's in low speed mode but its usable. The first 10 patches are in
mainline now and the last 5 are in essence this patch series with the
exception of 'drm/atomic+msm: add helper to implement legacy dirtyfb'.
There's a slightly different version of that patch in mainline now.
I'm planning to work on the msm8974 interconnect support once some of
the outstanding interconnect patches for the msm kms/drm driver arrive
in mainline. I'd really like to understand why the display works on
4.17 with those patches though. I assume that it's related to the
vblank events not working properly? Let me preface this with I'm a
total DRM newbie, but it looked like the pre-DRM-atomic driver wasn't
looking for these events in the atomic commits before the migration?
See commit 70db18dca4e0 ("drm/msm: Remove msm_commit/worker, use atomic
helper commit"), specifically the drm_atomic_helper_wait_for_vblanks()
call that was added.
Brian
On Tue, May 28, 2019 at 7:17 PM Brian Masney <[email protected]> wrote:
>
> On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > On Thu, May 9, 2019 at 4:04 AM Brian Masney <[email protected]> wrote:
> >
> > > Here is a patch series that adds initial display support for the LG
> > > Nexus 5 (hammerhead) phone. It's not fully working so that's why some
> > > of these patches are RFC until we can get it fully working.
> > >
> > > The phones boots into terminal mode, however there is a several second
> > > (or more) delay when writing to tty1 compared to when the changes are
> > > actually shown on the screen. The following errors are in dmesg:
> >
> > I tested to apply patches 2-6 and got the console up on the phone as well.
> > I see the same timouts, and I also notice the update is slow in the
> > display, as if the DSI panel was running in low power (LP) mode.
> >
> > Was booting this to do some other work, but happy to see the progress!
>
> Thanks!
>
> I've had three people email me off list regarding the display working on
> 4.17 before the msm kms/drm driver was converted to the DRM atomic API so
> this email is to get some more information out publicly.
>
> I pushed up a branch to my github with 15 patches applied against 4.17
> that has a working display:
>
> https://github.com/masneyb/linux/commits/display-works-4.17
>
> It's in low speed mode but its usable. The first 10 patches are in
> mainline now and the last 5 are in essence this patch series with the
> exception of 'drm/atomic+msm: add helper to implement legacy dirtyfb'.
> There's a slightly different version of that patch in mainline now.
>
> I'm planning to work on the msm8974 interconnect support once some of
> the outstanding interconnect patches for the msm kms/drm driver arrive
> in mainline. I'd really like to understand why the display works on
> 4.17 with those patches though. I assume that it's related to the
> vblank events not working properly? Let me preface this with I'm a
> total DRM newbie, but it looked like the pre-DRM-atomic driver wasn't
> looking for these events in the atomic commits before the migration?
> See commit 70db18dca4e0 ("drm/msm: Remove msm_commit/worker, use atomic
> helper commit"), specifically the drm_atomic_helper_wait_for_vblanks()
> call that was added.
Do you know if the nexus 5 has a video or command mode panel? There
is some glitchyness with vblanks and command mode panels.
On Tue, May 28, 2019 at 07:32:14PM -0600, Jeffrey Hugo wrote:
> On Tue, May 28, 2019 at 7:17 PM Brian Masney <[email protected]> wrote:
> >
> > On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > > On Thu, May 9, 2019 at 4:04 AM Brian Masney <[email protected]> wrote:
> > >
> > > > Here is a patch series that adds initial display support for the LG
> > > > Nexus 5 (hammerhead) phone. It's not fully working so that's why some
> > > > of these patches are RFC until we can get it fully working.
> > > >
> > > > The phones boots into terminal mode, however there is a several second
> > > > (or more) delay when writing to tty1 compared to when the changes are
> > > > actually shown on the screen. The following errors are in dmesg:
> > >
> > > I tested to apply patches 2-6 and got the console up on the phone as well.
> > > I see the same timouts, and I also notice the update is slow in the
> > > display, as if the DSI panel was running in low power (LP) mode.
> > >
> > > Was booting this to do some other work, but happy to see the progress!
> >
> > Thanks!
> >
> > I've had three people email me off list regarding the display working on
> > 4.17 before the msm kms/drm driver was converted to the DRM atomic API so
> > this email is to get some more information out publicly.
> >
> > I pushed up a branch to my github with 15 patches applied against 4.17
> > that has a working display:
> >
> > https://github.com/masneyb/linux/commits/display-works-4.17
> >
> > It's in low speed mode but its usable. The first 10 patches are in
> > mainline now and the last 5 are in essence this patch series with the
> > exception of 'drm/atomic+msm: add helper to implement legacy dirtyfb'.
> > There's a slightly different version of that patch in mainline now.
> >
> > I'm planning to work on the msm8974 interconnect support once some of
> > the outstanding interconnect patches for the msm kms/drm driver arrive
> > in mainline. I'd really like to understand why the display works on
> > 4.17 with those patches though. I assume that it's related to the
> > vblank events not working properly? Let me preface this with I'm a
> > total DRM newbie, but it looked like the pre-DRM-atomic driver wasn't
> > looking for these events in the atomic commits before the migration?
> > See commit 70db18dca4e0 ("drm/msm: Remove msm_commit/worker, use atomic
> > helper commit"), specifically the drm_atomic_helper_wait_for_vblanks()
> > call that was added.
>
> Do you know if the nexus 5 has a video or command mode panel? There
> is some glitchyness with vblanks and command mode panels.
Its in command mode. I know this because I see two 'pp done time out'
messages, even on 4.17. Based on my understanding, the ping pong code is
only applicable for command mode panels.
Brian
On Tue, May 28, 2019 at 7:37 PM Brian Masney <[email protected]> wrote:
>
> On Tue, May 28, 2019 at 07:32:14PM -0600, Jeffrey Hugo wrote:
> > On Tue, May 28, 2019 at 7:17 PM Brian Masney <[email protected]> wrote:
> > >
> > > On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > > > On Thu, May 9, 2019 at 4:04 AM Brian Masney <[email protected]> wrote:
> > > >
> > > > > Here is a patch series that adds initial display support for the LG
> > > > > Nexus 5 (hammerhead) phone. It's not fully working so that's why some
> > > > > of these patches are RFC until we can get it fully working.
> > > > >
> > > > > The phones boots into terminal mode, however there is a several second
> > > > > (or more) delay when writing to tty1 compared to when the changes are
> > > > > actually shown on the screen. The following errors are in dmesg:
> > > >
> > > > I tested to apply patches 2-6 and got the console up on the phone as well.
> > > > I see the same timouts, and I also notice the update is slow in the
> > > > display, as if the DSI panel was running in low power (LP) mode.
> > > >
> > > > Was booting this to do some other work, but happy to see the progress!
> > >
> > > Thanks!
> > >
> > > I've had three people email me off list regarding the display working on
> > > 4.17 before the msm kms/drm driver was converted to the DRM atomic API so
> > > this email is to get some more information out publicly.
> > >
> > > I pushed up a branch to my github with 15 patches applied against 4.17
> > > that has a working display:
> > >
> > > https://github.com/masneyb/linux/commits/display-works-4.17
> > >
> > > It's in low speed mode but its usable. The first 10 patches are in
> > > mainline now and the last 5 are in essence this patch series with the
> > > exception of 'drm/atomic+msm: add helper to implement legacy dirtyfb'.
> > > There's a slightly different version of that patch in mainline now.
> > >
> > > I'm planning to work on the msm8974 interconnect support once some of
> > > the outstanding interconnect patches for the msm kms/drm driver arrive
> > > in mainline. I'd really like to understand why the display works on
> > > 4.17 with those patches though. I assume that it's related to the
> > > vblank events not working properly? Let me preface this with I'm a
> > > total DRM newbie, but it looked like the pre-DRM-atomic driver wasn't
> > > looking for these events in the atomic commits before the migration?
> > > See commit 70db18dca4e0 ("drm/msm: Remove msm_commit/worker, use atomic
> > > helper commit"), specifically the drm_atomic_helper_wait_for_vblanks()
> > > call that was added.
> >
> > Do you know if the nexus 5 has a video or command mode panel? There
> > is some glitchyness with vblanks and command mode panels.
>
> Its in command mode. I know this because I see two 'pp done time out'
> messages, even on 4.17. Based on my understanding, the ping pong code is
> only applicable for command mode panels.
Actually, the ping pong element exists in both modes, but 'pp done
time out' is a good indicator that it is command mode.
Are you also seeing vblank timeouts?
Do you have busybox?
Can you run -
sudo busybox devmem 0xFD900614
sudo busybox devmem 0xFD900714
sudo busybox devmem 0xFD900814
sudo busybox devmem 0xFD900914
sudo busybox devmem 0xFD900A14
On Tue, May 28, 2019 at 6:17 PM Brian Masney <[email protected]> wrote:
>
> On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > On Thu, May 9, 2019 at 4:04 AM Brian Masney <[email protected]> wrote:
> >
> > > Here is a patch series that adds initial display support for the LG
> > > Nexus 5 (hammerhead) phone. It's not fully working so that's why some
> > > of these patches are RFC until we can get it fully working.
> > >
> > > The phones boots into terminal mode, however there is a several second
> > > (or more) delay when writing to tty1 compared to when the changes are
> > > actually shown on the screen. The following errors are in dmesg:
> >
> > I tested to apply patches 2-6 and got the console up on the phone as well.
> > I see the same timouts, and I also notice the update is slow in the
> > display, as if the DSI panel was running in low power (LP) mode.
> >
> > Was booting this to do some other work, but happy to see the progress!
>
> Thanks!
>
> I've had three people email me off list regarding the display working on
> 4.17 before the msm kms/drm driver was converted to the DRM atomic API so
> this email is to get some more information out publicly.
>
> I pushed up a branch to my github with 15 patches applied against 4.17
> that has a working display:
>
> https://github.com/masneyb/linux/commits/display-works-4.17
>
> It's in low speed mode but its usable. The first 10 patches are in
> mainline now and the last 5 are in essence this patch series with the
> exception of 'drm/atomic+msm: add helper to implement legacy dirtyfb'.
> There's a slightly different version of that patch in mainline now.
>
> I'm planning to work on the msm8974 interconnect support once some of
> the outstanding interconnect patches for the msm kms/drm driver arrive
> in mainline. I'd really like to understand why the display works on
> 4.17 with those patches though. I assume that it's related to the
> vblank events not working properly? Let me preface this with I'm a
> total DRM newbie, but it looked like the pre-DRM-atomic driver wasn't
> looking for these events in the atomic commits before the migration?
> See commit 70db18dca4e0 ("drm/msm: Remove msm_commit/worker, use atomic
> helper commit"), specifically the drm_atomic_helper_wait_for_vblanks()
> call that was added.
interconnect probably good to get going anyways (and I need to find
some time to respin those mdp5/dpu patches) but I guess not related to
what you see (ie. I'd expect interconnect issue would trigger
underflow irq's)..
I'm not entirely sure why atomic would break things but cmd mode
panels aren't especially well tested. I can't find it now but there
was a thread (or IRC discussion?) that intf2vblank() should be
returning MDP5_IRQ_PING_PONG_<n>_DONE instead of
MDP5_IRQ_PING_PONG_<n>_RD_PTR, which seems likely and possibly related
to vblank timing issues..
BR,
-R
>
> Brian
On Tue, May 28, 2019 at 8:15 PM Rob Clark <[email protected]> wrote:
>
> On Tue, May 28, 2019 at 6:17 PM Brian Masney <[email protected]> wrote:
> >
> > On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > > On Thu, May 9, 2019 at 4:04 AM Brian Masney <[email protected]> wrote:
> > >
> > > > Here is a patch series that adds initial display support for the LG
> > > > Nexus 5 (hammerhead) phone. It's not fully working so that's why some
> > > > of these patches are RFC until we can get it fully working.
> > > >
> > > > The phones boots into terminal mode, however there is a several second
> > > > (or more) delay when writing to tty1 compared to when the changes are
> > > > actually shown on the screen. The following errors are in dmesg:
> > >
> > > I tested to apply patches 2-6 and got the console up on the phone as well.
> > > I see the same timouts, and I also notice the update is slow in the
> > > display, as if the DSI panel was running in low power (LP) mode.
> > >
> > > Was booting this to do some other work, but happy to see the progress!
> >
> > Thanks!
> >
> > I've had three people email me off list regarding the display working on
> > 4.17 before the msm kms/drm driver was converted to the DRM atomic API so
> > this email is to get some more information out publicly.
> >
> > I pushed up a branch to my github with 15 patches applied against 4.17
> > that has a working display:
> >
> > https://github.com/masneyb/linux/commits/display-works-4.17
> >
> > It's in low speed mode but its usable. The first 10 patches are in
> > mainline now and the last 5 are in essence this patch series with the
> > exception of 'drm/atomic+msm: add helper to implement legacy dirtyfb'.
> > There's a slightly different version of that patch in mainline now.
> >
> > I'm planning to work on the msm8974 interconnect support once some of
> > the outstanding interconnect patches for the msm kms/drm driver arrive
> > in mainline. I'd really like to understand why the display works on
> > 4.17 with those patches though. I assume that it's related to the
> > vblank events not working properly? Let me preface this with I'm a
> > total DRM newbie, but it looked like the pre-DRM-atomic driver wasn't
> > looking for these events in the atomic commits before the migration?
> > See commit 70db18dca4e0 ("drm/msm: Remove msm_commit/worker, use atomic
> > helper commit"), specifically the drm_atomic_helper_wait_for_vblanks()
> > call that was added.
>
> interconnect probably good to get going anyways (and I need to find
> some time to respin those mdp5/dpu patches) but I guess not related to
> what you see (ie. I'd expect interconnect issue would trigger
> underflow irq's)..
>
> I'm not entirely sure why atomic would break things but cmd mode
> panels aren't especially well tested. I can't find it now but there
> was a thread (or IRC discussion?) that intf2vblank() should be
> returning MDP5_IRQ_PING_PONG_<n>_DONE instead of
> MDP5_IRQ_PING_PONG_<n>_RD_PTR, which seems likely and possibly related
> to vblank timing issues..
That was an irc discussion, and I've changed my mind on that.
My big issue ended up being that autorefresh was enabled (which
basically turns the command panel into a pseudo video mode panel),
which appears incompatible with using the start kick. If FW is
configuring things in autorefresh mode, the driver likely doesn't
know, and will make a mess of things by using the start kick.
Disabling autorefresh would make the driver work as is, but fbcon
wouldn't work well (you'd need to do a start kick per frame, which
doesn't seem to happen). Removing the start kick and using the
autorefresh feature seemed better in my testing, but I haven't cleaned
up my code tree to send something up.
However, lets see how the hardware is actually configured in Brian's case.
On Tue, May 28, 2019 at 07:42:19PM -0600, Jeffrey Hugo wrote:
> > > Do you know if the nexus 5 has a video or command mode panel? There
> > > is some glitchyness with vblanks and command mode panels.
> >
> > Its in command mode. I know this because I see two 'pp done time out'
> > messages, even on 4.17. Based on my understanding, the ping pong code is
> > only applicable for command mode panels.
>
> Actually, the ping pong element exists in both modes, but 'pp done
> time out' is a good indicator that it is command mode.
>
> Are you also seeing vblank timeouts?
Yes, here's a snippet of the first one.
[ 2.556014] WARNING: CPU: 0 PID: 5 at drivers/gpu/drm/drm_atomic_helper.c:1429 drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290
[ 2.556020] [CRTC:49:crtc-0] vblank wait timed out
[ 2.556023] Modules linked in:
[ 2.556034] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.2.0-rc1-00178-g72c3c1fd5f86-dirty #426
[ 2.556038] Hardware name: Generic DT based system
[ 2.556056] Workqueue: events deferred_probe_work_func
...
> Do you have busybox?
>
> Can you run -
> sudo busybox devmem 0xFD900614
> sudo busybox devmem 0xFD900714
> sudo busybox devmem 0xFD900814
> sudo busybox devmem 0xFD900914
> sudo busybox devmem 0xFD900A14
# busybox devmem 0xFD900614
0x00020020
# busybox devmem 0xFD900714
0x00000000
# busybox devmem 0xFD900814
0x00000000
# busybox devmem 0xFD900914
0x00000000
# busybox devmem 0xFD900A14
0x00000000
I get the same values with the mainline kernel and 4.17.
Brian
On Wed, May 29, 2019 at 3:17 AM Brian Masney <[email protected]> wrote:
> It's in low speed mode but its usable.
How low speed is that?
> I assume that it's related to the
> vblank events not working properly?
They are only waiting for 50 ms before timing out, I raised it
to 100ms in the -next kernel. I'm still suspicious about this
even though I think you said this was not the problem.
For a command mode panel in LP mode it will nevertheless
be more than 100ms for sure, the update is visible to the
naked eye.
Raise it to 10000 ms or something and see what happens.
drivers/gpu/drm/drm_atomic_helper.c:
msecs_to_jiffies(50)
Yours,
Linus Walleij
On Wed, May 29, 2019 at 08:23:17AM +0200, Linus Walleij wrote:
> On Wed, May 29, 2019 at 3:17 AM Brian Masney <[email protected]> wrote:
>
> > It's in low speed mode but its usable.
>
> How low speed is that?
I don't have a number but my test with 4.17 is to run
'cat /etc/passwd > /dev/tty1' over a serial cable. The first 2-3 calls
will fill up the screen and the file contents appear to show up on the
screen immediately to the human eye. The next time that I run it
requires scrolling the entire console and there is a small fraction of
a second where I see the entire framebuffer contents scroll up. I
don't have a graphics background, but I believe that this is the
tearing effect that I'm seeing based on what I've read. I believe that
disp-te-gpios can be used to mitigate this tearing effect. I have a few
questions about this later once we get the basic display working.
> > I assume that it's related to the
> > vblank events not working properly?
>
> They are only waiting for 50 ms before timing out, I raised it
> to 100ms in the -next kernel. I'm still suspicious about this
> even though I think you said this was not the problem.
>
> For a command mode panel in LP mode it will nevertheless
> be more than 100ms for sure, the update is visible to the
> naked eye.
>
> Raise it to 10000 ms or something and see what happens.
> drivers/gpu/drm/drm_atomic_helper.c:
> msecs_to_jiffies(50)
I previously raised those timeouts as high as 5 seconds and it still
has the same issue. Writing to /dev/tty1 can take anywhere between a few
seconds to 30 seconds or more.
Brian