[PATCH 1/1] [MTD/NAND]: Add Blackfin BF52x on-chip NAND Flash controller driver support in bf5xx_nand driver

[PATCH 1/1] [MTD/NAND]: Add Blackfin BF52x on-chip NAND Flash controller driver support in bf5xx_nand driver

[Bryan Wu]

From: Michael Hennerich <michael.hennerich@analog.com>

Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Bryan Wu <bryan.wu@analog.com>
---
 drivers/mtd/nand/Kconfig      |    2 +-
 drivers/mtd/nand/bf5xx_nand.c |   20 ++++++++++++++++++--
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 246d451..bf0e9b0 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -93,7 +93,7 @@ config MTD_NAND_AU1550
 
 config MTD_NAND_BF5XX
 	tristate "Blackfin on-chip NAND Flash Controller driver"
-	depends on BF54x && MTD_NAND
+	depends on (BF54x || BF52x) && MTD_NAND
 	help
 	  This enables the Blackfin on-chip NAND flash controller
 
diff --git a/drivers/mtd/nand/bf5xx_nand.c b/drivers/mtd/nand/bf5xx_nand.c
index 1657ecd..542850c 100644
--- a/drivers/mtd/nand/bf5xx_nand.c
+++ b/drivers/mtd/nand/bf5xx_nand.c
@@ -74,7 +74,22 @@ static int hardware_ecc = 1;
 static int hardware_ecc;
 #endif
 
-static unsigned short bfin_nfc_pin_req[] = {P_NAND_CE, P_NAND_RB, 0};
+static unsigned short bfin_nfc_pin_req[] =
+	{P_NAND_CE,
+	 P_NAND_RB,
+	 P_NAND_D0,
+	 P_NAND_D1,
+	 P_NAND_D2,
+	 P_NAND_D3,
+	 P_NAND_D4,
+	 P_NAND_D5,
+	 P_NAND_D6,
+	 P_NAND_D7,
+	 P_NAND_WE,
+	 P_NAND_RE,
+	 P_NAND_CLE,
+	 P_NAND_ALE,
+	 0};
 
 /*
  * Data structures for bf5xx nand flash controller driver
@@ -507,12 +522,13 @@ static int bf5xx_nand_dma_init(struct bf5xx_nand_info *info)
 
 	init_completion(&info->dma_completion);
 
+#ifdef CONFIG_BF54x
 	/* Setup DMAC1 channel mux for NFC which shared with SDH */
 	val = bfin_read_DMAC1_PERIMUX();
 	val &= 0xFFFE;
 	bfin_write_DMAC1_PERIMUX(val);
 	SSYNC();
-
+#endif
 	/* Request NFC DMA channel */
 	ret = request_dma(CH_NFC, "BF5XX NFC driver");
 	if (ret < 0) {
-- 
1.5.3.4

[PATCH 1/1] [MTD/NAND]: Add Blackfin BF52x on-chip NAND Flash controller driver support in bf5xx_nand driver

[Bryan Wu]

From: Michael Hennerich <michael.hennerich@analog.com>

Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Bryan Wu <bryan.wu@analog.com>
---
 drivers/mtd/nand/Kconfig      |    2 +-
 drivers/mtd/nand/bf5xx_nand.c |   20 ++++++++++++++++++--
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 246d451..bf0e9b0 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -93,7 +93,7 @@ config MTD_NAND_AU1550
 
 config MTD_NAND_BF5XX
 	tristate "Blackfin on-chip NAND Flash Controller driver"
-	depends on BF54x && MTD_NAND
+	depends on (BF54x || BF52x) && MTD_NAND
 	help
 	  This enables the Blackfin on-chip NAND flash controller
 
diff --git a/drivers/mtd/nand/bf5xx_nand.c b/drivers/mtd/nand/bf5xx_nand.c
index 1657ecd..542850c 100644
--- a/drivers/mtd/nand/bf5xx_nand.c
+++ b/drivers/mtd/nand/bf5xx_nand.c
@@ -74,7 +74,22 @@ static int hardware_ecc = 1;
 static int hardware_ecc;
 #endif
 
-static unsigned short bfin_nfc_pin_req[] = {P_NAND_CE, P_NAND_RB, 0};
+static unsigned short bfin_nfc_pin_req[] =
+	{P_NAND_CE,
+	 P_NAND_RB,
+	 P_NAND_D0,
+	 P_NAND_D1,
+	 P_NAND_D2,
+	 P_NAND_D3,
+	 P_NAND_D4,
+	 P_NAND_D5,
+	 P_NAND_D6,
+	 P_NAND_D7,
+	 P_NAND_WE,
+	 P_NAND_RE,
+	 P_NAND_CLE,
+	 P_NAND_ALE,
+	 0};
 
 /*
  * Data structures for bf5xx nand flash controller driver
@@ -507,12 +522,13 @@ static int bf5xx_nand_dma_init(struct bf5xx_nand_info *info)
 
 	init_completion(&info->dma_completion);
 
+#ifdef CONFIG_BF54x
 	/* Setup DMAC1 channel mux for NFC which shared with SDH */
 	val = bfin_read_DMAC1_PERIMUX();
 	val &= 0xFFFE;
 	bfin_write_DMAC1_PERIMUX(val);
 	SSYNC();
-
+#endif
 	/* Request NFC DMA channel */
 	ret = request_dma(CH_NFC, "BF5XX NFC driver");
 	if (ret < 0) {
-- 
1.5.3.4

Re: [PATCH 1/1] [MTD/NAND]: Add Blackfin BF52x on-chip NAND Flash controller driver support in bf5xx_nand driver

[David Woodhouse]

On Fri, 2007-11-23 at 18:14 +0800, Bryan Wu wrote:
> 
> +#ifdef CONFIG_BF54x
>         /* Setup DMAC1 channel mux for NFC which shared with SDH */
>         val = bfin_read_DMAC1_PERIMUX();
>         val &= 0xFFFE;
>         bfin_write_DMAC1_PERIMUX(val);
>         SSYNC();
> -
> +#endif

You can't build a multiplatform kernel which runs on BF52x and BF54x?
And want to make it harder to do so in future?

-- 
dwmw2

Re: [PATCH 1/1] [MTD/NAND]: Add Blackfin BF52x on-chip NAND Flash controller driver support in bf5xx_nand driver

[Bryan Wu]

On Nov 23, 2007 6:19 PM, David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Fri, 2007-11-23 at 18:14 +0800, Bryan Wu wrote:
> >
> > +#ifdef CONFIG_BF54x
> >         /* Setup DMAC1 channel mux for NFC which shared with SDH */
> >         val = bfin_read_DMAC1_PERIMUX();
> >         val &= 0xFFFE;
> >         bfin_write_DMAC1_PERIMUX(val);
> >         SSYNC();
> > -
> > +#endif
>
> You can't build a multiplatform kernel which runs on BF52x and BF54x?

There are some hardware difference between BF52x and BF54x. We have to do this.

> And want to make it harder to do so in future?
>
Any idea to make it easier? providing a specific hardware init hook
function from each platform board files?

Regards,
-Bryan

> --
> dwmw2
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [PATCH 1/1] [MTD/NAND]: Add Blackfin BF52x on-chip NAND Flash controller driver support in bf5xx_nand driver

[Arjan van de Ven]

On Fri, 23 Nov 2007 22:25:29 +0800
"Bryan Wu" <cooloney.lkml@gmail.com> wrote:

> On Nov 23, 2007 6:19 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > On Fri, 2007-11-23 at 18:14 +0800, Bryan Wu wrote:
> > >
> > > +#ifdef CONFIG_BF54x
> > >         /* Setup DMAC1 channel mux for NFC which shared with SDH
> > > */ val = bfin_read_DMAC1_PERIMUX();
> > >         val &= 0xFFFE;
> > >         bfin_write_DMAC1_PERIMUX(val);
> > >         SSYNC();
> > > -
> > > +#endif
> >
> > You can't build a multiplatform kernel which runs on BF52x and
> > BF54x?
> 
> There are some hardware difference between BF52x and BF54x. We have
> to do this.
> 

well does it need to be an #ifdef, or can it be a runtime if() ?

-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [PATCH 1/1] [MTD/NAND]: Add Blackfin BF52x on-chip NAND Flash controller driver support in bf5xx_nand driver

[Robin Getz]

On Fri 23 Nov 2007 16:52, Arjan van de Ven pondered:
> On Fri, 23 Nov 2007 22:25:29 +0800
> "Bryan Wu" <cooloney.lkml@gmail.com> wrote:
> 
> > On Nov 23, 2007 6:19 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> > >
> > > On Fri, 2007-11-23 at 18:14 +0800, Bryan Wu wrote:
> > > >
> > > > +#ifdef CONFIG_BF54x
> > > >         /* Setup DMAC1 channel mux for NFC which shared with SDH
> > > > */ val = bfin_read_DMAC1_PERIMUX();
> > > >         val &= 0xFFFE;
> > > >         bfin_write_DMAC1_PERIMUX(val);
> > > >         SSYNC();
> > > > -
> > > > +#endif
> > >
> > > You can't build a multiplatform kernel which runs on BF52x and
> > > BF54x?
> > 
> > There are some hardware difference between BF52x and BF54x. We have
> > to do this.
> > 
> 
> well does it need to be an #ifdef, or can it be a runtime if() ?

It could be a runtime if() but we don't currently have the is_mach() all set 
up properly today.

This is because on most systems that Blackfin ships on - memory is the 
dominate cost of the system, and end users don't want to take the either the 
storage (flash) hit of having code they don't use, or the run time (DRAM) 
overhead. They are fine with compiling 2 kernels for two platforms if it 
means things are cheaper. :)

That being said, we still need to go back, and add things properly - and just 
let gcc optimise things away if it is not used - c code is more maintainable 
than all the ifdefs we have today.

This is the goal - it will just take a little bit to get there.

-Robin

Re: [PATCH 1/1] [MTD/NAND]: Add Blackfin BF52x on-chip NAND Flash controller driver support in bf5xx_nand driver

[David Woodhouse]

On Fri, 2007-11-23 at 17:04 -0500, Robin Getz wrote:
> It could be a runtime if() but we don't currently have the is_mach() all set 
> up properly today.
> 
> This is because on most systems that Blackfin ships on - memory is the 
> dominate cost of the system, and end users don't want to take the either the 
> storage (flash) hit of having code they don't use, or the run time (DRAM) 
> overhead. They are fine with compiling 2 kernels for two platforms if it 
> means things are cheaper. :)
> 
> That being said, we still need to go back, and add things properly - and just 
> let gcc optimise things away if it is not used - c code is more maintainable 
> than all the ifdefs we have today.
> 
> This is the goal - it will just take a little bit to get there.

For now I suspect you could at least define machine_is_bf52x() and
machine_is_bf54x() which are hard-coded to either zero or one according
to the configuration, and at least you wouldn't need to add ifdefs to
drivers.

-- 
dwmw2

Re: [PATCH 1/1] [MTD/NAND]: Add Blackfin BF52x on-chip NAND Flash controller driver support in bf5xx_nand driver

[Bryan Wu]

On Nov 24, 2007 2:43 PM, David Woodhouse <dwmw2@infradead.org> wrote:
>
> On Fri, 2007-11-23 at 17:04 -0500, Robin Getz wrote:
> > It could be a runtime if() but we don't currently have the is_mach() all set
> > up properly today.
> >
> > This is because on most systems that Blackfin ships on - memory is the
> > dominate cost of the system, and end users don't want to take the either the
> > storage (flash) hit of having code they don't use, or the run time (DRAM)
> > overhead. They are fine with compiling 2 kernels for two platforms if it
> > means things are cheaper. :)
> >
> > That being said, we still need to go back, and add things properly - and just
> > let gcc optimise things away if it is not used - c code is more maintainable
> > than all the ifdefs we have today.
> >
> > This is the goal - it will just take a little bit to get there.
>
> For now I suspect you could at least define machine_is_bf52x() and
> machine_is_bf54x() which are hard-coded to either zero or one according
> to the configuration, and at least you wouldn't need to add ifdefs to
> drivers.
>

We got some plan to do this, but maybe cpu_is_bf52x() and
cpu_is_bf54x() are better.
Thanks.

-Bryan

Re: [PATCH 1/1] [MTD/NAND]: Add Blackfin BF52x on-chip NAND Flash controller driver support in bf5xx_nand driver

[Robin Getz]

On Sat 24 Nov 2007 02:15, Bryan Wu pondered:
> On Nov 24, 2007 2:43 PM, David Woodhouse <dwmw2@infradead.org> wrote:
> >
> > On Fri, 2007-11-23 at 17:04 -0500, Robin Getz wrote:
> > > It could be a runtime if() but we don't currently have the is_mach() all
> > > set up properly today.
> > >
> > > This is because on most systems that Blackfin ships on - memory is the
> > > dominate cost of the system, and end users don't want to take the either
> > > the storage (flash) hit of having code they don't use, or the run time
> > > (DRAM) overhead. They are fine with compiling 2 kernels for two
> > > platforms if it means things are cheaper. :)
> > >
> > > That being said, we still need to go back, and add things properly - and
> > > just let gcc optimise things away if it is not used - c code is more
> > > maintainable than all the ifdefs we have today.
> > >
> > > This is the goal - it will just take a little bit to get there.
> >
> > For now I suspect you could at least define machine_is_bf52x() and
> > machine_is_bf54x() which are hard-coded to either zero or one according
> > to the configuration, and at least you wouldn't need to add ifdefs to
> > drivers.
> >
> 
> We got some plan to do this, but maybe cpu_is_bf52x() and
> cpu_is_bf54x() are better.

Which was one of the reasons I think we were waiting/confused. There doesn't 
seem to be any consistancy between:

cpu_is_

which I assume refers to specific processor/chipset/SoC implementation?
cpu_is_ixp42x
cpu_is_ixp43x
cpu_is_ixp46x

mach_is_

which I assume refers to a specific platform:

mach_is_dreamcast
mach_is_hp6xx
mach_is_r7780mp
mach_is_r7780rp

machine_is_xxxx

which I assume refers to a specific platform:

machine_is_jornada56x
machine_is_jornada720
machine_is_nokia770

So, we should use cpu_is_ as Bryan suggested?

-Robin