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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54EB8645.4060608@math.uni-bielefeld.de>
Date:	Mon, 23 Feb 2015 20:57:57 +0100
From:	Tobias Jakobi <tjakobi@...h.uni-bielefeld.de>
To:	Chanwoo Choi <cw00.choi@...sung.com>,
	Tobias Jakobi <liquid.acid@....net>
CC:	myungjoo.ham@...sung.com, kgene@...nel.org,
	kyungmin.park@...sung.com, rafael.j.wysocki@...el.com,
	mark.rutland@....com, a.kesavan@...sung.com, tomasz.figa@...il.com,
	k.kozlowski@...sung.com, b.zolnierkie@...sung.com,
	robh+dt@...nel.org, inki.dae@...sung.com, linux-pm@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-samsung-soc@...r.kernel.org
Subject: Re: [PATCHv3 0/8] devfreq: Add generic exynos memory-bus
 frequency driver

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@...4 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/