On Tue, May 28, 2019 at 08:53:49PM -0600, Jeffrey Hugo wrote:
On Tue, May 28, 2019 at 8:46 PM Brian Masney masneyb@onstation.org 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 0x00000000 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.
POS="0XFD900100" while [ "${POS}" != "0XFD925000" ] ; do echo -n "${POS} = " busybox devmem "${POS}" POS=$(printf '%#X' "$((${POS} + 4))") done
Brian
On Wed, May 29, 2019 at 4:28 AM Brian Masney masneyb@onstation.org 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 masneyb@onstation.org 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 0x00000000 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...
On Wed, May 29, 2019 at 08:41:31AM -0600, Jeffrey Hugo wrote:
On Wed, May 29, 2019 at 4:28 AM Brian Masney masneyb@onstation.org 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 masneyb@onstation.org 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 0x00000000 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...
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
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 masneyb@onstation.org 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 masneyb@onstation.org 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 0x00000000 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...
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/dr...
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 masneyb@onstation.org 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 masneyb@onstation.org 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 0x00000000 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...
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/dr...
I'll work on this for the msm driver.
Thanks for the info!
Brian
dri-devel@lists.freedesktop.org
-
Brian Masney -
Jeffrey Hugo -
Jeffrey Hugo