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

From: Michael Hennerich

Signed-off-by: Michael Hennerich
Signed-off-by: Bryan Wu
---
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
-
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/

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

-
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/

On Nov 23, 2007 6:19 PM, David Woodhouse 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/
>
-
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/

On Fri, 23 Nov 2007 22:25:29 +0800
"Bryan Wu" wrote:

> On Nov 23, 2007 6:19 PM, David Woodhouse 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
-
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/

On Fri 23 Nov 2007 16:52, Arjan van de Ven pondered:
> On Fri, 23 Nov 2007 22:25:29 +0800
> "Bryan Wu" wrote:
>
> > On Nov 23, 2007 6:19 PM, David Woodhouse 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
-
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/

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

-
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/

On Nov 24, 2007 2:43 PM, David Woodhouse 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
-
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/

On Sat 24 Nov 2007 02:15, Bryan Wu pondered:
> On Nov 24, 2007 2:43 PM, David Woodhouse 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
-
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/