On Tue, Feb 05, 2013 at 12:53:45AM +0900, Paul Mundt wrote: > On Mon, Feb 04, 2013 at 12:32:16PM +0100, Philipp Zabel wrote: > > This driver requests and remaps a memory region as configured in the > > device tree. It serves memory from this region via the genalloc API. > > It optionally enables the SRAM clock. > > > > Other drivers can retrieve the genalloc pool from a phandle pointing > > to this drivers' device node in the device tree. > > > > The allocation granularity is hard-coded to 32 bytes for now, > > to make the SRAM driver useful for the 6502 remoteproc driver. > > There is overhead for bigger SRAMs, where only a much coarser > > allocation granularity is needed: At 32 bytes minimum allocation > > size, a 256 KiB SRAM needs a 1 KiB bitmap to track allocations. > > > > Signed-off-by: Philipp Zabel <p.za...@pengutronix.de> > > Reviewed-by: Shawn Guo <shawn....@linaro.org> > > How exactly is this "generic" if you have randomly hard-coded an > allocation granularity that is larger than half of the in-tree SRAM pool > users today can even support? Did you even bother to look at in-tree SRAM > pool users other than the one you are working on? > > There also doesn't seem to be any real reason for the hard-coding either, > this information could easily be fetched via platform data or the device > tree, and the driver in question would simply need to be able to > determine whether the size is suitable for it or not.
Please see http://thread.gmane.org/gmane.linux.kernel/1377702 for the original discussion on my patch for configurable allocation granularity. I believe there was an implied agreement from Grant that it was ok if we went with a more descriptive name even though it hits the grey area of not describing hardware. -Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/