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] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 27 Dec 2013 18:34:10 +0200
From:	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>
To:	Pavel Machek <pavel@....cz>,
	Ivaylo Dimitrov <ivo.g.dimitrov.75@...il.com>
CC:	tomi.valkeinen@...com, tony@...mide.com, linux@....linux.org.uk,
	pali.rohar@...il.com, linux-omap@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Ivaylo Dimitrov <freemangordon@....bg>
Subject: Re: [PATCH] ARM: omapfb: Add early framebuffer memory allocator


On 27.12.2013 11:48, Pavel Machek wrote:
> On Thu 2013-12-26 01:12:39, Ivaylo Dimitrov wrote:
>> From: Ivaylo Dimitrov <freemangordon@....bg>
>>
>> On memory limited devices, CMA fails easily when asked to allocate big
>> chunks of memory like framebuffer memory needed for video playback.
>>
>> Add boot parameter "omapfb_memsize" which allocates memory to be used
>> as dma coherent memory, so dma_alloc_attrs won't hit CMA allocator when
>> trying to allocate memory for the framebuffers
>>
>> Signed-off-by: Ivaylo Dimitrov <freemangordon@....bg>
> Hmm, would it make sense to add a parameter to reserve certain ammount
> of memory for CMA? omapfb is probably not the only user hitting
> this...?
> 									Pavel

But that would mean that one must have CMA enabled to use that 
functionality and it is an additional memory overhead. Also, I don't 
think we will have much of a benefit of that - for video playback we'll 
still have to preallocate the same amount of RAM as now - but with the 
additional overhead of page migration when that RAM becomes needed by 
DSP and OMAPFB. However, even if such functionality is someday 
implemented in CMA, it doesn't conflict with the proposed patch - by 
simply not preallocating memory for omapfb, one will automatically use it.

BTW there is CMEM driver (not upstreamed afaik) which does exactly that 
- it manages a contiguous ("stolen")memory pool. No idea how easy it 
would be to merge CMEM into CMA. Neither I am the right guy for the 
task, IMO :)

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ