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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 24 Feb 2015 08:55:29 +0900
From:	Chanwoo Choi <cw00.choi@...sung.com>
To:	Tobias Jakobi <tjakobi@...h.uni-bielefeld.de>
Cc:	Tobias Jakobi <liquid.acid@....net>, 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

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

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


--
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/