Re: [PATCH v5 1/4] genalloc: add a global pool list, allow to find pools by phys address

On Thu, Nov 15, 2012 at 8:25 AM, Philipp Zabel [off-list ref]wrote:

Hi Paul,

Am Freitag, den 26.10.2012, 15:46 -0400 schrieb Paul Gortmaker:

quoted

On Thu, Oct 18, 2012 at 10:27 AM, Philipp Zabel [off-list ref]

wrote:

quoted

quoted

This patch keeps all created pools in a global list and adds two
functions that allow to retrieve the gen_pool pointer from a known
physical address and from a device tree node.

So, I'm not seeing any added users of the of_get_named_gen_pool,
or the other exported "reverse-lookup" function.  Without that, the
anticipated use case is not clear to me.

My use case is the coda video codec driver, for a video codec IP core
that is integrated in various SoCs. It can use on-SoC SRAM as temporary

memory.

Thanks Philipp,

So perhaps it makes sense to somehow tie this patch to the user
patch, since from what I recall reading in the past, the infrastructure
additions that are immediately used are far more favourably rec'd
than those that are weakly bound to a hand-wavey possibly vapour
ware like use case that may or may not materialize going forward.

Paul.
--

Other possible use cases are the TI Davinci sound driver.
Or the PXA frame buffer driver could allocate a frame buffer in SRAM for
low-resolution devices.

quoted

Is there an example of some pending driver or similar, that has
a phys addr from an unknown source and needs to know what
pool it may or may not be in?  With the use case, someone might
be able to suggest alternative ways to get what you want done.

drivers/media/platform/coda.c right now uses imx specific
iram_alloc/free wrappers around gen_pool_alloc/free.
I'd like to use of_get_named_gen_pool to obtain the struct gen_pool
pointer and use gen_pool_alloc/free directly, instead.

sound/soc/davinci/davinci-pcm.c right now uses davinci specific
sram_alloc/free wrappers around gen_pool_alloc/free.

drivers/dma/mmp_tdma.c and sound/soc/pxa/mmp-pcm.c already use
gen_pool_alloc/free directly, but they use a arch-mmp specific
sram_get_gpool function to obtain the struct gen_pool pointer.

quoted

It might also be worth cross compiling this for powerpc, since the
header files you implicitly get included varies from one arch to
the next, and there might be some compile fails lurking there.

Thanks, I'll do that.

regards
Philipp


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