[PATCHv3 0/8] devfreq: Add generic exynos memory-bus frequency driver

Hi Tobias,

On 02/24/2015 04:57 AM, Tobias Jakobi wrote:

Hello Chanwoo!

Chanwoo Choi wrote:

quoted

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.

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