linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: Re: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
@ 2015-02-24  1:23 MyungJoo Ham
  2015-02-24 12:22 ` Tobias Jakobi
  0 siblings, 1 reply; 2+ messages in thread
From: MyungJoo Ham @ 2015-02-24  1:23 UTC (permalink / raw)
  To: Tobias Jakobi, 최찬우, Tobias Jakobi
  Cc: kgene, 박경민,
	rafael.j.wysocki, mark.rutland, ABHILASH KESAVAN, tomasz.figa,
	Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz, robh+dt,
	대인기,
	linux-pm, linux-kernel, linux-arm-kernel, linux-samsung-soc

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 3892 bytes --]

> 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Ç+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Re: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
  2015-02-24  1:23 Re: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver MyungJoo Ham
@ 2015-02-24 12:22 ` Tobias Jakobi
  0 siblings, 0 replies; 2+ messages in thread
From: Tobias Jakobi @ 2015-02-24 12:22 UTC (permalink / raw)
  To: myungjoo.ham
  Cc: 최찬우,
	Tobias Jakobi, kgene, 박경민,
	rafael.j.wysocki, mark.rutland, ABHILASH KESAVAN, tomasz.figa,
	Krzysztof Kozlowski, Bartlomiej Zolnierkiewicz, robh+dt,
	대인기,
	linux-pm, linux-kernel, linux-arm-kernel, linux-samsung-soc

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-02-24 12:22 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-24  1:23 Re: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver MyungJoo Ham
2015-02-24 12:22 ` Tobias Jakobi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).