devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Philipp Zabel <p.zabel@pengutronix.de>
Cc: linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Grant Likely <grant.likely@secretlab.ca>,
	Rob Herring <rob.herring@calxeda.com>,
	Paul Gortmaker <paul.gortmaker@windriver.com>,
	Shawn Guo <shawn.guo@linaro.org>,
	Huang Shijie <shijie8@gmail.com>,
	Dong Aisheng <dong.aisheng@linaro.org>,
	Matt Porter <mporter@ti.com>,
	Fabio Estevam <fabio.estevam@freescale.com>,
	Javier Martin <javier.martin@vista-silicon.com>,
	kernel@pengutronix.de, devicetree-discuss@lists.ozlabs.org
Subject: Re: [PATCH v9 RESEND 2/4] misc: Generic on-chip SRAM allocation driver
Date: Wed, 27 Mar 2013 15:27:23 -0700	[thread overview]
Message-ID: <20130327152723.723cd65e884413df405abe2d@linux-foundation.org> (raw)
In-Reply-To: <1363776767-2635-3-git-send-email-p.zabel@pengutronix.de>

On Wed, 20 Mar 2013 11:52:45 +0100 Philipp Zabel <p.zabel@pengutronix.de> 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.
> 
>  Documentation/devicetree/bindings/misc/sram.txt |   16 +++
>  drivers/misc/Kconfig                            |    9 ++
>  drivers/misc/Makefile                           |    1 +
>  drivers/misc/sram.c                             |  121 +++++++++++++++++++++++

drivers/misc/sram.c is a pretty generic-sounding thing.  Is it really
Linux's One True SRAM driver?  How many different sorts of sram devices
do we expect this can be used with?  If I don't use DT?

In other words, perhaps this should have a more specific and accurate
name?

> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -510,6 +510,15 @@ config LATTICE_ECP3_CONFIG
>  
>  	  If unsure, say N.
>  
> ...
>
> +static int sram_probe(struct platform_device *pdev)
> +{
> +	void __iomem *virt_base;
> +	struct sram_dev *sram;
> +	struct resource *res;
> +	unsigned long size;
> +	int ret;
> +
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	if (!res)
> +		return -EINVAL;
> +
> +	size = resource_size(res);
> +
> +	virt_base = devm_request_and_ioremap(&pdev->dev, res);
> +	if (!virt_base)
> +		return -EADDRNOTAVAIL;

EADDRNOTAVAIL is a networking error.  If your users see this error pop
up on their console they'll start wiggling ethernet cables, wondering
why that didn't fix it.

> +	sram = devm_kzalloc(&pdev->dev, sizeof(*sram), GFP_KERNEL);
> +	if (!sram)
> +		return -ENOMEM;
> +
> +	sram->clk = devm_clk_get(&pdev->dev, NULL);
> +	if (IS_ERR(sram->clk))
> +		sram->clk = NULL;
> +	else
> +		clk_prepare_enable(sram->clk);
> +
> +	sram->pool = devm_gen_pool_create(&pdev->dev, ilog2(SRAM_GRANULARITY), -1);
> +	if (!sram->pool)
> +		return -ENOMEM;
> +
> +	ret = gen_pool_add_virt(sram->pool, (unsigned long)virt_base,
> +				res->start, size, -1);
> +	if (ret < 0) {
> +		gen_pool_destroy(sram->pool);
> +		return ret;
> +	}
> +
> +	platform_set_drvdata(pdev, sram);
> +
> +	dev_dbg(&pdev->dev, "SRAM pool: %ld KiB @ 0x%p\n", size / 1024, virt_base);
> +
> +	return 0;
> +}
>
> ...
>
> +int __init sram_init(void)
> +{
> +	return platform_driver_register(&sram_driver);
> +}
> +
> +postcore_initcall(sram_init);

Why is it postcore_initcall()?


Fixlets:

From: Andrew Morton <akpm@linux-foundation.org>
Subject: misc-generic-on-chip-sram-allocation-driver-fix

fix Kconfig text, make sram_init static

Cc: Dong Aisheng <dong.aisheng@linaro.org>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Huang Shijie <shijie8@gmail.com>
Cc: Javier Martin <javier.martin@vista-silicon.com>
Cc: Matt Porter <mporter@ti.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 drivers/misc/Kconfig |    6 +++---
 drivers/misc/sram.c  |    2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff -puN Documentation/devicetree/bindings/misc/sram.txt~misc-generic-on-chip-sram-allocation-driver-fix Documentation/devicetree/bindings/misc/sram.txt
diff -puN drivers/misc/Kconfig~misc-generic-on-chip-sram-allocation-driver-fix drivers/misc/Kconfig
--- a/drivers/misc/Kconfig~misc-generic-on-chip-sram-allocation-driver-fix
+++ a/drivers/misc/Kconfig
@@ -523,9 +523,9 @@ config SRAM
 	depends on HAS_IOMEM
 	select GENERIC_ALLOCATOR
 	help
-	  This driver allows to declare a memory region to be managed
-	  by the genalloc API. It is supposed to be used for small
-	  on-chip SRAM areas found on many SoCs.
+	  This driver allows you to declare a memory region to be managed by
+	  the genalloc API. It is supposed to be used for small on-chip SRAM
+	  areas found on many SoCs.
 
 source "drivers/misc/c2port/Kconfig"
 source "drivers/misc/eeprom/Kconfig"
diff -puN drivers/misc/Makefile~misc-generic-on-chip-sram-allocation-driver-fix drivers/misc/Makefile
diff -puN drivers/misc/sram.c~misc-generic-on-chip-sram-allocation-driver-fix drivers/misc/sram.c
--- a/drivers/misc/sram.c~misc-generic-on-chip-sram-allocation-driver-fix
+++ a/drivers/misc/sram.c
@@ -113,7 +113,7 @@ static struct platform_driver sram_drive
 	.remove = sram_remove,
 };
 
-int __init sram_init(void)
+static int __init sram_init(void)
 {
 	return platform_driver_register(&sram_driver);
 }
_

  parent reply	other threads:[~2013-03-27 22:27 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-20 10:52 [PATCH v9 RESEND 0/4] Add generic driver for on-chip SRAM Philipp Zabel
2013-03-20 10:52 ` [PATCH v9 RESEND 1/4] genalloc: add devres support, allow to find a managed pool by device Philipp Zabel
2013-03-22 12:47   ` Michal Simek
     [not found] ` <1363776767-2635-1-git-send-email-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2013-03-20 10:52   ` [PATCH v9 RESEND 2/4] misc: Generic on-chip SRAM allocation driver Philipp Zabel
2013-03-22 12:47     ` Michal Simek
2013-03-27 22:27     ` Andrew Morton [this message]
2013-03-28  7:42       ` Michal Simek
2013-03-28 10:52       ` Philipp Zabel
2013-04-15 13:50       ` Grant Likely
2013-03-20 10:52   ` [PATCH v9 RESEND 3/4] media: coda: use genalloc API Philipp Zabel
2013-03-28  1:15     ` Shawn Guo
2013-03-20 10:52 ` [PATCH v9 RESEND 4/4] ARM: dts: add sram for imx53 and imx6q Philipp Zabel
2013-03-27 22:29   ` Andrew Morton
2013-03-28  1:16     ` Shawn Guo
2013-03-28  2:54   ` Shawn Guo
2013-03-28  9:05     ` Philipp Zabel
2013-03-28 14:22       ` Shawn Guo
2013-03-28 15:23         ` Philipp Zabel
2013-03-22 12:49 ` [PATCH v9 RESEND 0/4] Add generic driver for on-chip SRAM Michal Simek
2013-03-27  8:33 ` Philipp Zabel
2013-03-27 12:00   ` Shawn Guo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130327152723.723cd65e884413df405abe2d@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=dong.aisheng@linaro.org \
    --cc=fabio.estevam@freescale.com \
    --cc=grant.likely@secretlab.ca \
    --cc=gregkh@linuxfoundation.org \
    --cc=javier.martin@vista-silicon.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mporter@ti.com \
    --cc=p.zabel@pengutronix.de \
    --cc=paul.gortmaker@windriver.com \
    --cc=rob.herring@calxeda.com \
    --cc=shawn.guo@linaro.org \
    --cc=shijie8@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).