Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Wed, May 29, 2019 at 01:58:16PM -0600, Jeffrey Hugo wrote: > On 5/29/2019 1:30 PM, Brian Masney wrote: > > On Wed, May 29, 2019 at 08:41:31AM -0600, Jeffrey Hugo wrote: > > > On Wed, May 29, 2019 at 4:28 AM Brian Masney > > > wrote: > > > > > > > > On Tue, May 28, 2019 at 08:53:49PM -0600, Jeffrey Hugo wrote: > > > > > On Tue, May 28, 2019 at 8:46 PM Brian Masney > > > > > wrote: > > > > > > > > > > > > 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 > > > > > > > > > > Ok, so CTL_0 path, command mode, ping pong 0, with the output going > > > > > to DSI 1. > > > > > > > > > > Next one please: > > > > > > > > > > busybox devmem 0xFD912D30 > > > > > > > > It's 0x on mainline and 4.17. I used the following script to > > > > dump the entire mdp5 memory region and attached the dump from 4.17 and > > > > 5.2rc1. > > > > > > > > > > ok, 0 means autorefresh is not on. Which is fine. My next guess > > > would be the vblank code checking the hardware vblank counter, which > > > doesn't exist. > > > In video mode, there is a frame counter which increments, which can be > > > used as the vblank counter. Unfortunately, that hardware isn't active > > > in command mode, and there isn't an equivalent. > > > > > > So, the vblank code is going to read the register, and look for an > > > update, which will never happen, thus it will timeout. There is a > > > backup path which uses timestamps (no hardware), which you can > > > activate with a quick hack - make max_vblank_count = 0 at the > > > following line > > > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c#L753 > > > > That fixed the issue! > > Awesome. I'm glad it was something simple. > > > > > I previously observed that mdp5_get_vblank_counter, specifically > > mdp5_encoder_get_framecount, would always return 0. > > > > What's the best way to fix this in mainline? Set that to zero if any > > of the interface modes is MDP5_INTF_DSI_MODE_COMMAND? > > > > Short version, yes. Long version: > > I still have that hack in my tree and haven't come back to formulating > a proper fix yet. Feel free to run with it. > > Thinking about it briefly, we could do two things. We could fake a > hardware counter by just increment an int every time the vblank irq is > processed, but that seems clunky. Otherwise, we could force a > fallback onto the timestamp solution, which seems less invasive. > > In theory, we could service multiple displays, with different > properties (ie a combination of command and video mode). The hack > then, is not good, because it would break video mode (at-least we > wouldn't be using the register when we could). It would be great if > the use of the hardware register could be done per display. > > Luckily, it looks like someone just made that possible - > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/drm_vblank.c?h=v5.2-rc2=ed20151a7699bb2c77eba3610199789a126940c4 I'll work on this for the msm driver. Thanks for the info! Brian ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On 5/29/2019 1:30 PM, Brian Masney wrote: On Wed, May 29, 2019 at 08:41:31AM -0600, Jeffrey Hugo wrote: On Wed, May 29, 2019 at 4:28 AM Brian Masney wrote: On Tue, May 28, 2019 at 08:53:49PM -0600, Jeffrey Hugo wrote: On Tue, May 28, 2019 at 8:46 PM Brian Masney wrote: 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 Ok, so CTL_0 path, command mode, ping pong 0, with the output going to DSI 1. Next one please: busybox devmem 0xFD912D30 It's 0x on mainline and 4.17. I used the following script to dump the entire mdp5 memory region and attached the dump from 4.17 and 5.2rc1. ok, 0 means autorefresh is not on. Which is fine. My next guess would be the vblank code checking the hardware vblank counter, which doesn't exist. In video mode, there is a frame counter which increments, which can be used as the vblank counter. Unfortunately, that hardware isn't active in command mode, and there isn't an equivalent. So, the vblank code is going to read the register, and look for an update, which will never happen, thus it will timeout. There is a backup path which uses timestamps (no hardware), which you can activate with a quick hack - make max_vblank_count = 0 at the following line https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c#L753 That fixed the issue! Awesome. I'm glad it was something simple. I previously observed that mdp5_get_vblank_counter, specifically mdp5_encoder_get_framecount, would always return 0. What's the best way to fix this in mainline? Set that to zero if any of the interface modes is MDP5_INTF_DSI_MODE_COMMAND? Short version, yes. Long version: I still have that hack in my tree and haven't come back to formulating a proper fix yet. Feel free to run with it. Thinking about it briefly, we could do two things. We could fake a hardware counter by just increment an int every time the vblank irq is processed, but that seems clunky. Otherwise, we could force a fallback onto the timestamp solution, which seems less invasive. In theory, we could service multiple displays, with different properties (ie a combination of command and video mode). The hack then, is not good, because it would break video mode (at-least we wouldn't be using the register when we could). It would be great if the use of the hardware register could be done per display. Luckily, it looks like someone just made that possible - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/drm_vblank.c?h=v5.2-rc2=ed20151a7699bb2c77eba3610199789a126940c4 -- Jeffrey Hugo Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Wed, May 29, 2019 at 08:41:31AM -0600, Jeffrey Hugo wrote: > On Wed, May 29, 2019 at 4:28 AM Brian Masney wrote: > > > > On Tue, May 28, 2019 at 08:53:49PM -0600, Jeffrey Hugo wrote: > > > On Tue, May 28, 2019 at 8:46 PM Brian Masney > > > wrote: > > > > > > > > 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 > > > > > > Ok, so CTL_0 path, command mode, ping pong 0, with the output going to > > > DSI 1. > > > > > > Next one please: > > > > > > busybox devmem 0xFD912D30 > > > > It's 0x on mainline and 4.17. I used the following script to > > dump the entire mdp5 memory region and attached the dump from 4.17 and > > 5.2rc1. > > > > ok, 0 means autorefresh is not on. Which is fine. My next guess > would be the vblank code checking the hardware vblank counter, which > doesn't exist. > In video mode, there is a frame counter which increments, which can be > used as the vblank counter. Unfortunately, that hardware isn't active > in command mode, and there isn't an equivalent. > > So, the vblank code is going to read the register, and look for an > update, which will never happen, thus it will timeout. There is a > backup path which uses timestamps (no hardware), which you can > activate with a quick hack - make max_vblank_count = 0 at the > following line > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c#L753 That fixed the issue! I previously observed that mdp5_get_vblank_counter, specifically mdp5_encoder_get_framecount, would always return 0. What's the best way to fix this in mainline? Set that to zero if any of the interface modes is MDP5_INTF_DSI_MODE_COMMAND? Brian ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Wed, May 29, 2019 at 08:23:17AM +0200, Linus Walleij wrote: > On Wed, May 29, 2019 at 3:17 AM Brian Masney 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 1 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 ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Wed, May 29, 2019 at 3:17 AM Brian Masney 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 1 ms or something and see what happens. drivers/gpu/drm/drm_atomic_helper.c: msecs_to_jiffies(50) Yours, Linus Walleij ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
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 0x # busybox devmem 0xFD900814 0x # busybox devmem 0xFD900914 0x # busybox devmem 0xFD900A14 0x I get the same values with the mainline kernel and 4.17. Brian ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Tue, May 28, 2019 at 8:15 PM Rob Clark wrote:
>
> On Tue, May 28, 2019 at 6:17 PM Brian Masney 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 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__DONE instead of
> MDP5_IRQ_PING_PONG__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.
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Tue, May 28, 2019 at 6:17 PM Brian Masney 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 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__DONE instead of
MDP5_IRQ_PING_PONG__RD_PTR, which seems likely and possibly related
to vblank timing issues..
BR,
-R
>
> Brian
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Tue, May 28, 2019 at 7:37 PM Brian Masney 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 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
> > > > 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
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Tue, May 28, 2019 at 07:32:14PM -0600, Jeffrey Hugo wrote:
> On Tue, May 28, 2019 at 7:17 PM Brian Masney 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 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
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Tue, May 28, 2019 at 7:17 PM Brian Masney 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 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.
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> On Thu, May 9, 2019 at 4:04 AM 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 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
___
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
On Thu, May 9, 2019 at 4:04 AM 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 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 ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
Re: [Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
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 [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 5.1.0-rc6-next-20190426-9-g75891c3edac4-dirty (masneyb@ins7386) (gcc version 8.1.1 20180626 (Red Hat Cross 8.1.1-3) (GCC)) #303 SMP PREEMPT Wed May 8 21:59:17 EDT 2019 [0.00] CPU: ARMv7 Processor [512f06f0] revision 0 (ARMv7), cr=10c5787d [0.00] CPU: div instructions available: patching division code [0.00] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache [0.00] OF: fdt: Machine model: LGE MSM 8974 HAMMERHEAD [0.00] Memory policy: Data cache writealloc [0.00] cma: Reserved 256 MiB at 0x2000 [0.00] On node 0 totalpages: 491776 [0.00] Normal zone: 1536 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 164096 pages, LIFO batch:31 [0.00] HighMem zone: 327680 pages, LIFO batch:63 [0.00] percpu: Embedded 17 pages/cpu s39756 r8192 d21684 u69632 [0.00] pcpu-alloc: s39756 r8192 d21684 u69632 alloc=17*4096 [0.00] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0.00] Built 1 zonelists, mobility grouping on. Total pages: 490240 [0.00] Kernel command line: console=tty0 console=ttyMSM0,115200,n8 rootwait androidboot.hardware=hammerhead user_debug=31 maxcpus=2 msm_watchdog_v2.enable=1 PMOS_NO_OUTPUT_REDIRECT=1 uart_console=enable gpt=enable lge.kcal=0|0|0|x lge.rev=rev_11 androidboot.laf androidboot.emmc=true fastboot=true androidboot.serialno=019eef1708e40fd2 androidboot.bootloader=HHZ20h androidboot.baseband=msm androidboot.hardware.sku=D820 androidboot.hardware.ddr=hynix androidboot.hardware.display=orise androidboot.revision=11 [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 1633208K/1967104K available (8192K kernel code, 834K rwdata, 3436K rodata, 1024K init, 266K bss, 71752K reserved, 262144K cma-reserved, 1310720K highmem) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [0.00] rcu: Preemptible hierarchical RCU implementation. [0.00] Tasks RCU enabled. [0.00] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies. [0.00] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16 [0.00] random: get_random_bytes called from start_kernel+0x300/0x490 with crng_init=0 [0.00] arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt). [0.00] clocksource: arch_sys_counter: mask: 0xff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns [0.05] sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns [0.17] Switching to timer-based delay loop, resolution 52ns [0.000410] Console: colour dummy device 80x30 [0.000785] printk: console [tty0] enabled [0.000823] Calibrating delay loop (skipped), value calculated using timer frequency.. 38.40 BogoMIPS (lpj=192000) [0.000854] pid_max: default: 32768 minimum: 301 [0.000984] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.001014] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.001504] *** VALIDATE proc *** [0.001629] *** VALIDATE cgroup1 *** [0.001651] *** VALIDATE cgroup2 *** [0.001676] CPU: Testing write buffer coherency: ok [0.001939] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.059943] Setting up static identity map for 0x30 - 0x300060 [0.079942] rcu: Hierarchical SRCU implementation. [0.120017] smp: Bringing up secondary CPUs ... [0.200453] CPU1: thread -1, cpu 1, socket 0, mpidr 8001 [0.200671] smp: Brought up 1 node, 2 CPUs [0.200705] SMP: Total of 2 processors activated (76.80 BogoMIPS). [0.200725] CPU: All CPU(s) started in SVC mode. [0.202148] devtmpfs: initialized [0.211750] VFP support v0.3: implementor 51 architecture 64 part 6f variant 2 rev 0 [0.212072] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns [0.212111] futex hash table entries: 1024 (order: 4, 65536 bytes) [0.221586] pinctrl core: initialized pinctrl subsystem [0.222779] NET: Registered protocol family 16 [0.224668] DMA: preallocated 256 KiB pool for atomic coherent
[Freedreno] [PATCH RFC v2 0/6] ARM: qcom: initial Nexus 5 display support
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-6-g35c0d32a96e1-dirty #191 Hardware name: Generic DT based system Workqueue: events deferred_probe_work_func [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [] (show_stack) from [] (dump_stack+0x78/0x8c) [] (dump_stack) from [] (__warn.part.3+0xb8/0xd4) [] (__warn.part.3) from [] (warn_slowpath_fmt+0x64/0x88) [] (warn_slowpath_fmt) from [] (drm_atomic_helper_wait_for_vblanks.part.1+0x288/0x290) [] (drm_atomic_helper_wait_for_vblanks.part.1) from [] (mdp5_complete_commit+0x14/0x40) [] (mdp5_complete_commit) from [] (msm_atomic_commit_tail+0xa8/0x140) [] (msm_atomic_commit_tail) from [] (commit_tail+0x40/0x6c) [] (drm_atomic_helper_commit) from [] (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 ___ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno
