From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matt Porter Subject: Re: [PATCH v8 2/4] misc: Generic on-chip SRAM allocation driver Date: Mon, 4 Feb 2013 12:02:04 -0500 Message-ID: <20130204170204.GX2244@beef> References: <1359977538-5859-1-git-send-email-p.zabel@pengutronix.de> <1359977538-5859-3-git-send-email-p.zabel@pengutronix.de> <20130204155344.GA14171@linux-sh.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20130204155344.GA14171-M7jkjyW5wf5g9hUCZPvPmw@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Paul Mundt Cc: Fabio Estevam , Dong Aisheng , kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org, Greg Kroah-Hartman , devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring , Paul Gortmaker , Richard Zhao , Javier Martin , Philipp Zabel , Huang Shijie List-Id: devicetree@vger.kernel.org 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 > > Reviewed-by: Shawn Guo > > 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