| Message ID | 10220de398d22fad5de783d8f58fc55ebac85338.1335874494.git.afzal@ti.com |
|---|---|
| State | Not Applicable |
| Headers | show |
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
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
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
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
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
* 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
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",
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(-)