linux-kernel - Re: [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen

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:	Mon, 1 Oct 2012 08:32:42 -0400
From:	Matt Porter <mporter@...com>
To:	Sekhar Nori <nsekhar@...com>
Cc:	Linux DaVinci Kernel List 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	Paul Walmsley <paul@...an.com>,
	Russell King <linux@....linux.org.uk>,
	Benoit Cousson <b-cousson@...com>,
	Tony Lindgren <tony@...mide.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Hans J. Koch" <hjk@...sjkoch.de>,
	Linux OMAP List <linux-omap@...r.kernel.org>,
	Linux ARM Kernel List <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 4/7] ARM: davinci: Add support for an L3RAM gen_pool

On Mon, Oct 01, 2012 at 05:34:02PM +0530, Sekhar Nori wrote:
> Hi Matt,
> 
> On 9/29/2012 1:07 AM, Matt Porter wrote:
> > L3RAM (shared SRAM) is needed for use by several drivers.
> > This creates a genalloc pool and a hook for the platform code
> > to provide the struct gen_pool * in platform data.
> > 
> > Signed-off-by: Matt Porter <mporter@...com>
> 
> I am not sure if any of the DaVinci devices have a need to allocate from
> *both* ARM RAM and shared RAM. Shared RAM is not present on all DaVinci
> devices AFAIR, and on DA850, there is just 8KB ARM RAM so I am not sure
> if there is much point in trying to allocate from there.
> 
> Can you instead see if Ben's earlier patch[1] to use shared RAM for SRAM
> allocation on DA850 makes sense for your case? If yes, can you repost
> with Ben's patch included in your series instead of this patch? I would
> prefer that over creating a new pool for shared RAM.

Hrm, I did look at Ben's earlier patch. The reason I added a separate
pool mostly was so I didn't have to touch the PM code at all. That can
continue using the private SRAM API with the ARM RAM as it is now. The
idea here was to allow that to be separate since no other bus masters
can access the ARM RAM anyway and do something that didn't require
regression testing PM. Also, I figured there's really no reason to use
even a tiny bit of the shared SRAM on PM if we have that ARM RAM there
and working fine for that use case.

The other thing is that Ben's patch needs to be rewritten to at least
have the hook I added so we can provide the gen_pool in platform data.
If you prefer this path still, I can add the needed hook on top of his
original patch. Ultimately, I only *need* genalloc support for the
shared sram so I can remove the private SRAM API from uio_pruss...so I'm
happy with any way to get at it.

Oh, and to be honest...it's not just for uio_pruss, but also to cleanly
remove the private SRAM API usage from the davinci ASoC driver too.

Thanks,
Matt
--
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/