[PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver
From: Tobias Jakobi <hidden>
Date: 2015-02-23 19:58:09
Also in:
linux-pm, linux-samsung-soc, lkml
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 at 13:1280x720 -v setting mode 1280x720-60Hz at 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