Hello,
I've tested the series on my Odroid-X2 (by adapting the TRATS2 changes),
and so far I haven't seen any issues. With the system being idle one can
see that the 'simple_ondemand' devfreq governor clocks down both memory
busses to the lowest state.
With best wishes,
Tobias
Hello again,
Tobias Jakobi wrote
> I've tested the series on my Odroid-X2 (by adapting the TRATS2 changes),
> and so far I haven't seen any issues. With the system being idle one can
> see that the 'simple_ondemand' devfreq governor clocks down both memory
> busses to the lowest state.
looks I was too hasty the last time. Actually this series breaks HDMI
output for me (or at least with 'simple_ondemand' governor, haven't
tried with performance yet).
I tried to run some simple application, but it hangs in uninterruptible
sleep immediately, probably before the first page flip. Going to check
this more thoroughly.
Maybe some parts of the hdmi subsystem don't like the lower clocks?
With best wishes,
Tobias
Hi Tobias,
First of all, thanks for your test.
On 02/19/2015 05:59 AM, Tobias Jakobi wrote:
> Hello again,
>
> Tobias Jakobi wrote
>> I've tested the series on my Odroid-X2 (by adapting the TRATS2 changes),
>> and so far I haven't seen any issues. With the system being idle one can
>> see that the 'simple_ondemand' devfreq governor clocks down both memory
>> busses to the lowest state.
>
> looks I was too hasty the last time. Actually this series breaks HDMI
> output for me (or at least with 'simple_ondemand' governor, haven't
> tried with performance yet).
>
> I tried to run some simple application, but it hangs in uninterruptible
> sleep immediately, probably before the first page flip. Going to check
> this more thoroughly.
>
> Maybe some parts of the hdmi subsystem don't like the lower clocks?
As you thought, when maintaining lower clock of memory bus frequency,
some issue related to multimedia feature will happen.
Separately, We have to check the miminum lower clock for working of multimedia feature.
and then multimedia or other IP have to request it to DVFS driver (memory busfreq driver).
But, latest mainline kernel currently has not some way to inform minimum clock to DVFS driver.
So, If you check the miminum clock for hdmi, I'll use this clock as minumu frequency of dvfs table.
Thanks,
Chanwoo Choi
Hello Chanwoo!
Chanwoo Choi wrote:
> As you thought, when maintaining lower clock of memory bus frequency,
> some issue related to multimedia feature will happen.
>
> Separately, We have to check the miminum lower clock for working of multimedia feature.
> and then multimedia or other IP have to request it to DVFS driver (memory busfreq driver).
> But, latest mainline kernel currently has not some way to inform minimum clock to DVFS driver.
>
> So, If you check the miminum clock for hdmi, I'll use this clock as minumu frequency of dvfs table.
>
> Thanks,
> Chanwoo Choi
>
First I have to apologize. I didn't check carefully. Actually it's not
the HDMI subsystem which seems to hang during my test, but the G2D
subsystem.
Here's a snippet of the kernel log with drm.debug=0xff:
[ 1157.911264] [drm:drm_framebuffer_reference] ee144e00: FB ID: 27 (2)
[ 1157.911271] [drm:drm_framebuffer_unreference] ee37fb80: FB ID: 25 (2)
[ 1157.911277] [drm:drm_framebuffer_unreference] ee144e00: FB ID: 27 (3)
[ 1157.911315] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
EXYNOS_G2D_GET_VER
[ 1158.434439] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
EXYNOS_G2D_SET_CMDLIST
[ 1158.434536] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1, EXYNOS_G2D_EXEC
[ 1158.437484] [drm:drm_vm_close_locked] 0xaf840000,0x00140000
[ 1158.437507] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
DRM_IOCTL_GEM_CLOSE
[ 1158.437524] [drm:exynos_drm_gem_destroy] handle count = 0
[ 1158.437532] [drm:lowlevel_buffer_deallocate] dma_addr(0x20500000),
size(0x140000)
[ 1158.437810] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
EXYNOS_GEM_CREATE
[ 1158.437819] [drm:exynos_drm_init_buf] desired size = 0x256000
[ 1158.437851] [drm:exynos_drm_gem_init] created file object = 0xe97c8d00
[ 1158.445506] [drm:lowlevel_buffer_allocate] dma_addr(0x21400000),
size(0x256000)
[ 1158.445535] [drm:exynos_drm_gem_handle_create] gem handle = 0x1
[ 1158.445556] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
DRM_IOCTL_MODE_MAP_DUMB
[ 1158.445570] [drm:exynos_drm_gem_dumb_map_offset] offset = 0x101c2000
[ 1158.445600] [drm:drm_vm_open_locked] 0xaec15000,0x00256000
[ 1158.445608] [drm:update_vm_cache_attr] flags = 0x0
[ 1158.457696] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
EXYNOS_G2D_SET_CMDLIST
[ 1158.457745] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1, EXYNOS_G2D_EXEC
So G2D_EXEC seems to work once, but the second time it hangs forever. I
even fail at attaching gdb to the application then (gdb then also hangs
in D state).
If I just use the 'vsynced page flipping' test, then everything works:
./modetest -M exynos -s 16@13:1280x720 -v
setting mode 1280x720-60Hz@XR24 on connectors 16, crtc 13
freq: 61.08Hz
freq: 60.00Hz
freq: 60.00Hz
<etc.>
I'm going to do some tests with the G2D in the next time, checking how
much I can lower MIF/INT clocks before the engine becomes unstable.
With best wishes,
Tobias
Hi Tobias,
On 02/24/2015 04:57 AM, Tobias Jakobi wrote:
> Hello Chanwoo!
>
> Chanwoo Choi wrote:
>> As you thought, when maintaining lower clock of memory bus frequency,
>> some issue related to multimedia feature will happen.
>>
>> Separately, We have to check the miminum lower clock for working of multimedia feature.
>> and then multimedia or other IP have to request it to DVFS driver (memory busfreq driver).
>> But, latest mainline kernel currently has not some way to inform minimum clock to DVFS driver.
>>
>> So, If you check the miminum clock for hdmi, I'll use this clock as minumu frequency of dvfs table.
>>
>> Thanks,
>> Chanwoo Choi
>>
>
> First I have to apologize. I didn't check carefully. Actually it's not
> the HDMI subsystem which seems to hang during my test, but the G2D
> subsystem.
>
> Here's a snippet of the kernel log with drm.debug=0xff:
> [ 1157.911264] [drm:drm_framebuffer_reference] ee144e00: FB ID: 27 (2)
> [ 1157.911271] [drm:drm_framebuffer_unreference] ee37fb80: FB ID: 25 (2)
> [ 1157.911277] [drm:drm_framebuffer_unreference] ee144e00: FB ID: 27 (3)
> [ 1157.911315] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
> EXYNOS_G2D_GET_VER
> [ 1158.434439] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
> EXYNOS_G2D_SET_CMDLIST
> [ 1158.434536] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1, EXYNOS_G2D_EXEC
> [ 1158.437484] [drm:drm_vm_close_locked] 0xaf840000,0x00140000
> [ 1158.437507] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
> DRM_IOCTL_GEM_CLOSE
> [ 1158.437524] [drm:exynos_drm_gem_destroy] handle count = 0
> [ 1158.437532] [drm:lowlevel_buffer_deallocate] dma_addr(0x20500000),
> size(0x140000)
> [ 1158.437810] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
> EXYNOS_GEM_CREATE
> [ 1158.437819] [drm:exynos_drm_init_buf] desired size = 0x256000
> [ 1158.437851] [drm:exynos_drm_gem_init] created file object = 0xe97c8d00
> [ 1158.445506] [drm:lowlevel_buffer_allocate] dma_addr(0x21400000),
> size(0x256000)
> [ 1158.445535] [drm:exynos_drm_gem_handle_create] gem handle = 0x1
> [ 1158.445556] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
> DRM_IOCTL_MODE_MAP_DUMB
> [ 1158.445570] [drm:exynos_drm_gem_dumb_map_offset] offset = 0x101c2000
> [ 1158.445600] [drm:drm_vm_open_locked] 0xaec15000,0x00256000
> [ 1158.445608] [drm:update_vm_cache_attr] flags = 0x0
> [ 1158.457696] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
> EXYNOS_G2D_SET_CMDLIST
> [ 1158.457745] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1, EXYNOS_G2D_EXEC
>
>
> So G2D_EXEC seems to work once, but the second time it hangs forever. I
> even fail at attaching gdb to the application then (gdb then also hangs
> in D state).
>
> If I just use the 'vsynced page flipping' test, then everything works:
> ./modetest -M exynos -s 16@13:1280x720 -v
> setting mode 1280x720-60Hz@XR24 on connectors 16, crtc 13
> freq: 61.08Hz
> freq: 60.00Hz
> freq: 60.00Hz
> <etc.>
>
> I'm going to do some tests with the G2D in the next time, checking how
> much I can lower MIF/INT clocks before the engine becomes unstable.
Thanks for your test. If you have any question or help, please feel free to ask me.
I'm working to implemnet new generic exynos memoby-bus frequency driver (exynos-busfreq.c).
because this version of patch-set used the 'virtual operating-points'.
So, I'm working to implment this drvier without 'virtual operation-points'.
After finishing the implmentaion, I'll add you to mailing list ac Cc.
Best Regards,
Chanwoo Choi
> Hello Chanwoo!
>
> Chanwoo Choi wrote:
> > As you thought, when maintaining lower clock of memory bus frequency,
> > some issue related to multimedia feature will happen.
> >
> > Separately, We have to check the miminum lower clock for working of multimedia feature.
> > and then multimedia or other IP have to request it to DVFS driver (memory busfreq driver).
> > But, latest mainline kernel currently has not some way to inform minimum clock to DVFS driver.
> >
> > So, If you check the miminum clock for hdmi, I'll use this clock as minumu frequency of dvfs table.
> >
> > Thanks,
> > Chanwoo Choi
> >
>
> First I have to apologize. I didn't check carefully. Actually it's not
> the HDMI subsystem which seems to hang during my test, but the G2D
> subsystem.
>
> Here's a snippet of the kernel log with drm.debug=0xff:
> [ 1157.911264] [drm:drm_framebuffer_reference] ee144e00: FB ID: 27 (2)
> [ 1157.911271] [drm:drm_framebuffer_unreference] ee37fb80: FB ID: 25 (2)
> [ 1157.911277] [drm:drm_framebuffer_unreference] ee144e00: FB ID: 27 (3)
> [ 1157.911315] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
> EXYNOS_G2D_GET_VER
> [ 1158.434439] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
> EXYNOS_G2D_SET_CMDLIST
> [ 1158.434536] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1, EXYNOS_G2D_EXEC
> [ 1158.437484] [drm:drm_vm_close_locked] 0xaf840000,0x00140000
> [ 1158.437507] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
> DRM_IOCTL_GEM_CLOSE
> [ 1158.437524] [drm:exynos_drm_gem_destroy] handle count = 0
> [ 1158.437532] [drm:lowlevel_buffer_deallocate] dma_addr(0x20500000),
> size(0x140000)
> [ 1158.437810] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
> EXYNOS_GEM_CREATE
> [ 1158.437819] [drm:exynos_drm_init_buf] desired size = 0x256000
> [ 1158.437851] [drm:exynos_drm_gem_init] created file object = 0xe97c8d00
> [ 1158.445506] [drm:lowlevel_buffer_allocate] dma_addr(0x21400000),
> size(0x256000)
> [ 1158.445535] [drm:exynos_drm_gem_handle_create] gem handle = 0x1
> [ 1158.445556] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
> DRM_IOCTL_MODE_MAP_DUMB
> [ 1158.445570] [drm:exynos_drm_gem_dumb_map_offset] offset = 0x101c2000
> [ 1158.445600] [drm:drm_vm_open_locked] 0xaec15000,0x00256000
> [ 1158.445608] [drm:update_vm_cache_attr] flags = 0x0
> [ 1158.457696] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1,
> EXYNOS_G2D_SET_CMDLIST
> [ 1158.457745] [drm:drm_ioctl] pid=2569, dev=0xe200, auth=1, EXYNOS_G2D_EXEC
>
>
> So G2D_EXEC seems to work once, but the second time it hangs forever. I
> even fail at attaching gdb to the application then (gdb then also hangs
> in D state).
>
> If I just use the 'vsynced page flipping' test, then everything works:
> ./modetest -M exynos -s 16@13:1280x720 -v
> setting mode 1280x720-60Hz@XR24 on connectors 16, crtc 13
> freq: 61.08Hz
> freq: 60.00Hz
> freq: 60.00Hz
> <etc.>
>
> I'm going to do some tests with the G2D in the next time, checking how
> much I can lower MIF/INT clocks before the engine becomes unstable.
>
> With best wishes,
> Tobias
>
>
Unless you are willing to wait for 2 minutes after the kernal hangs,
you may want to adjust "DEFAULT_HUNG_TASK_TIMEOUT" to shorter value
(120 --> 5 for 5 seconds). It seems that you've cut it off in the middle
of that "120 sec" wait.
If it's in D state (in kernel), gdb won't work as you are experiencing.
Sorry for not testing with HDMI; my Exynos devices do not have HDMI. :)
To Chanwoo, wouldn't it be ok to have the corresponding devfreq driver
to set minimum higher IFF HDMI is enabled? (either by build time or
run time) I guess Exynos HDMI driver should express PM-QoS requests later.
(Or let Exynos HDMI driver not hung even if its memory transactions are
not fast enough)
Cheers,
MyungJoo
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
Hello MyungJoo!
On 2015-02-24 02:22, MyungJoo Ham wrote:
> Unless you are willing to wait for 2 minutes after the kernal hangs,
> you may want to adjust "DEFAULT_HUNG_TASK_TIMEOUT" to shorter value
> (120 --> 5 for 5 seconds). It seems that you've cut it off in the
> middle
> of that "120 sec" wait.
Thanks for the hint! Yes, I should probably adjust this value when
doing more tests.
> If it's in D state (in kernel), gdb won't work as you are experiencing.
> Sorry for not testing with HDMI; my Exynos devices do not have HDMI. :)
Well, like I said above, the HDMI doesn't seen to be affected by the low
MIF/INT clocks. I have tested this with 1280x720 here on my Odroid X2,
but I also have another user (with a U3 if I remember correctly) who
also confirms that HDMI is working in combination with devfreq and
simple_ondemand.
I guess it's just the G2D engine that doesn't like the low clocks. Maybe
it also affects the IPP subsystem, but I have no means to test this.
With best wishes,
Tobias