Patchwork [v4,04/39] ARM: OMAP2+: gpmc: Acquire NAND CS value

login
register
mail settings
Submitter Mohammed Afzal
Date May 1, 2012, 12:20 p.m.
Message ID <10220de398d22fad5de783d8f58fc55ebac85338.1335874494.git.afzal@ti.com>
Download mbox | patch
Permalink /patch/156095/
State New
Headers show

Comments

Mohammed Afzal - May 1, 2012, 12:20 p.m.
Some boards depend on bootloader to update chip select value for NAND.
It is felt that Kernel should not depend on bootloader to get CS, as
for a particular board CS is hardwired and is fixed, hence this can
directly be updated in Kernel. But as CS value for boards that depend
on this behaviour is not available, educate gpmc driver to acquire
chip select value for NAND. this ideally should be removed once CS
for those boards are available.

Signed-off-by: Afzal Mohammed <afzal@ti.com>
---
 arch/arm/mach-omap2/gpmc.c |   32 +++++++++++++++++++++++++++++++-
 1 file changed, 31 insertions(+), 1 deletion(-)
Hunter, Jon - May 1, 2012, 9:16 p.m.
Hi Afzal,

On 05/01/2012 07:20 AM, Afzal Mohammed wrote:
> Some boards depend on bootloader to update chip select value for NAND.
> It is felt that Kernel should not depend on bootloader to get CS, as
> for a particular board CS is hardwired and is fixed, hence this can
> directly be updated in Kernel. But as CS value for boards that depend
> on this behaviour is not available, educate gpmc driver to acquire
> chip select value for NAND. this ideally should be removed once CS
> for those boards are available.

Do you know how many boards require this? If so which are those boards?

> Signed-off-by: Afzal Mohammed <afzal@ti.com>
> ---
>  arch/arm/mach-omap2/gpmc.c |   32 +++++++++++++++++++++++++++++++-
>  1 file changed, 31 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 657ce95..ecd3384 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -892,6 +892,30 @@ static int __init gpmc_init(void)
>  }
>  postcore_initcall(gpmc_init);
>  
> +static __devinit int gpmc_acquire_nand_cs(struct gpmc *gpmc,
> +					struct gpmc_device_pdata *gdp)
> +{
> +	int cs = 0;
> +	struct omap_nand_platform_data *nand = gdp->pdata;
> +
> +	if ((nand->cs >= 0) && (nand->cs < GPMC_CS_NUM))
> +		return 0;
> +
> +	while (cs < GPMC_CS_NUM) {
> +		u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
> +
> +		if ((l & GPMC_CONFIG1_DEVICETYPE(~0)) ==
> +				GPMC_CONFIG1_DEVICETYPE_NAND) {
> +			dev_info(gpmc->dev, "found NAND on CS: %d\n", cs);
> +			nand->cs = cs;
> +			gdp->cs_data->cs = cs;
> +			return 0;
> +		}
> +		cs++;
> +	}
> +	return -ENODEV;
> +}
> +
>  static __devinit void gpmc_update_nand_reg(struct gpmc *gpmc,
>  				struct omap_nand_platform_data *nand)
>  {
> @@ -1450,8 +1474,14 @@ static __devinit int gpmc_probe(struct platform_device *pdev)
>  
>  	for (i = 0, gdq = gp->device_pdata, gd = gpmc->device;
>  			(i < gp->num_device) && (*gdq); i++, gdq++) {
> -		if ((*gdq)->is_nand)
> +		if ((*gdq)->is_nand) {
> +			ret = gpmc_acquire_nand_cs(gpmc, *gdq);
> +			if (IS_ERR_VALUE(ret)) {
> +				dev_err(gpmc->dev, "CS error: %d\n", ret);
> +				continue;
> +			}

Should this code be marked with a FIXME?

Cheers
Jon
Mohammed Afzal - May 3, 2012, 8:42 a.m.
Hi Jon,

On Wed, May 02, 2012 at 02:46:02, Hunter, Jon wrote:
> > Some boards depend on bootloader to update chip select value for NAND.
> > It is felt that Kernel should not depend on bootloader to get CS, as
> > for a particular board CS is hardwired and is fixed, hence this can
> > directly be updated in Kernel. But as CS value for boards that depend
> > on this behaviour is not available, educate gpmc driver to acquire
> > chip select value for NAND. this ideally should be removed once CS
> > for those boards are available.
> 
> Do you know how many boards require this? If so which are those boards?

devkit8000, beagle board, omap3touchbook, overo.

Beagle board, found out to be zero.

> Should this code be marked with a FIXME?

Will let Tony decide it.

Regards
Afzal
Mohammed Afzal - May 14, 2012, 10:33 a.m.
Hi All,

On Thu, May 03, 2012 at 14:12:11, Mohammed, Afzal wrote:

> > > Some boards depend on bootloader to update chip select value for NAND.
> > > It is felt that Kernel should not depend on bootloader to get CS, as
> > > for a particular board CS is hardwired and is fixed, hence this can
> > > directly be updated in Kernel. But as CS value for boards that depend
> > > on this behaviour is not available, educate gpmc driver to acquire
> > > chip select value for NAND. this ideally should be removed once CS
> > > for those boards are available.
> > 
> > Do you know how many boards require this? If so which are those boards?
> 
> devkit8000, beagle board, omap3touchbook, overo.
> 
> Beagle board, found out to be zero.

I need a help.

Can someone familiar with boards - devkit8000, omap3touchbook, overo boards,
let me know GPMC CS on which NAND is connected.

Hi Tony,

I am planning to provide actual CS # used for NAND on above boards instead of
finding the value at runtime. Is there any reason that NAND CS# is found out
at runtime ? (hence remove necessity of omap_nand_flash_init()).

Presence of this also causes an additional dependency of bootloader.

As CS # depends on wiring on the board, my understanding is that it will be
fixed for a given board. Are you ok if acquiring NAND CS # is removed ?

Removal of this helps in simplifying gpmc driver (undergoing conversion).

Regards
Afzal
Thomas Weber - May 15, 2012, 6:30 a.m.
Hello Afzal,

On 05/14/12 12:33, Mohammed, Afzal wrote:
> Hi All,
>
> On Thu, May 03, 2012 at 14:12:11, Mohammed, Afzal wrote:
>
>>>> Some boards depend on bootloader to update chip select value for NAND.
>>>> It is felt that Kernel should not depend on bootloader to get CS, as
>>>> for a particular board CS is hardwired and is fixed, hence this can
>>>> directly be updated in Kernel. But as CS value for boards that depend
>>>> on this behaviour is not available, educate gpmc driver to acquire
>>>> chip select value for NAND. this ideally should be removed once CS
>>>> for those boards are available.
>>> Do you know how many boards require this? If so which are those boards?
>> devkit8000, beagle board, omap3touchbook, overo.
>>
>> Beagle board, found out to be zero.
> I need a help.
>
> Can someone familiar with boards - devkit8000, omap3touchbook, overo boards,
> let me know GPMC CS on which NAND is connected.
On Devkit8000 the NAND is connected to CS0.
I thought that all NAND devices for booting are connected to CS0, 
because of ROM code?

According to spruf98w.pdf:

25.4.7.4 NAND
...
  * The device is connected to CS0.
...

Regards,
Thomas

> Hi Tony,
>
> I am planning to provide actual CS # used for NAND on above boards instead of
> finding the value at runtime. Is there any reason that NAND CS# is found out
> at runtime ? (hence remove necessity of omap_nand_flash_init()).
>
> Presence of this also causes an additional dependency of bootloader.
>
> As CS # depends on wiring on the board, my understanding is that it will be
> fixed for a given board. Are you ok if acquiring NAND CS # is removed ?
>
> Removal of this helps in simplifying gpmc driver (undergoing conversion).
>
> Regards
> Afzal
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Mohammed Afzal - May 15, 2012, 6:37 a.m.
Hi Thomas,

On Tue, May 15, 2012 at 12:00:32, Thomas Weber wrote:

> > I need a help.
> >
> > Can someone familiar with boards - devkit8000, omap3touchbook, overo boards,
> > let me know GPMC CS on which NAND is connected.
> On Devkit8000 the NAND is connected to CS0.

Thanks for the information

> I thought that all NAND devices for booting are connected to CS0, 
> because of ROM code?
> 
> According to spruf98w.pdf:
> 
> 25.4.7.4 NAND
> ...
>   * The device is connected to CS0.

Yes, expecting they should be, looking for confirmation.

Regards
Afzal
Tony Lindgren - May 25, 2012, 9:50 a.m.
* Mohammed, Afzal <afzal@ti.com> [120514 03:37]:
> 
> Hi Tony,
> 
> I am planning to provide actual CS # used for NAND on above boards instead of
> finding the value at runtime. Is there any reason that NAND CS# is found out
> at runtime ? (hence remove necessity of omap_nand_flash_init()).

Yes makes sense. All the board specific data like that should come from
device tree eventually.

Regards,

Tony

Patch

diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 657ce95..ecd3384 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -892,6 +892,30 @@  static int __init gpmc_init(void)
 }
 postcore_initcall(gpmc_init);
 
+static __devinit int gpmc_acquire_nand_cs(struct gpmc *gpmc,
+					struct gpmc_device_pdata *gdp)
+{
+	int cs = 0;
+	struct omap_nand_platform_data *nand = gdp->pdata;
+
+	if ((nand->cs >= 0) && (nand->cs < GPMC_CS_NUM))
+		return 0;
+
+	while (cs < GPMC_CS_NUM) {
+		u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1);
+
+		if ((l & GPMC_CONFIG1_DEVICETYPE(~0)) ==
+				GPMC_CONFIG1_DEVICETYPE_NAND) {
+			dev_info(gpmc->dev, "found NAND on CS: %d\n", cs);
+			nand->cs = cs;
+			gdp->cs_data->cs = cs;
+			return 0;
+		}
+		cs++;
+	}
+	return -ENODEV;
+}
+
 static __devinit void gpmc_update_nand_reg(struct gpmc *gpmc,
 				struct omap_nand_platform_data *nand)
 {
@@ -1450,8 +1474,14 @@  static __devinit int gpmc_probe(struct platform_device *pdev)
 
 	for (i = 0, gdq = gp->device_pdata, gd = gpmc->device;
 			(i < gp->num_device) && (*gdq); i++, gdq++) {
-		if ((*gdq)->is_nand)
+		if ((*gdq)->is_nand) {
+			ret = gpmc_acquire_nand_cs(gpmc, *gdq);
+			if (IS_ERR_VALUE(ret)) {
+				dev_err(gpmc->dev, "CS error: %d\n", ret);
+				continue;
+			}
 			gpmc_update_nand_reg(gpmc, (*gdq)->pdata);
+		}
 		ret = gpmc_setup_device(gpmc, gd, *gdq);
 		if (IS_ERR_VALUE(ret))
 			dev_err(gpmc->dev, "gpmc setup on %s failed\n",