| Message ID | 4ea124ab817db6e3dee2067aadd6db14643990f5.1407312577.git.stefan@agner.ch |
|---|---|
| State | Changes Requested |
| Delegated to: | Scott Wood |
| Headers | show |
On 6 Aug 2014, stefan@agner.ch wrote: > This adds initial support for Freescale NFC (NAND Flash Controller). > The IP is used in ARM based Vybrid SoCs as well as on some PowerPC > devices. This driver is only tested on Vybrid. > > Signed-off-by: Stefan Agner <stefan@agner.ch> > --- > drivers/mtd/nand/Makefile | 1 + > drivers/mtd/nand/fsl_nfc.c | 676 > ++++++++++++++++++++++++++++++++++++++++++++> + > 2 files changed, 677 insertions(+) > create mode 100644 drivers/mtd/nand/fsl_nfc.c > diff --git a/drivers/mtd/nand/fsl_nfc.c b/drivers/mtd/nand/fsl_nfc.c > new file mode 100644 > index 0000000..df2c8be > --- /dev/null > +++ b/drivers/mtd/nand/fsl_nfc.c > @@ -0,0 +1,676 @@ [snip] > +#define NFC_TIMEOUT (1000) > + > +/* ECC status placed at end of buffers. */ > +#define ECC_SRAM_ADDR ((PAGE_2K+256-8) >> 3) > +#define ECC_STATUS_MASK 0x80 > +#define ECC_ERR_COUNT 0x3F > + > +struct fsl_nfc { > + struct mtd_info *mtd; > + struct nand_chip chip; > + struct device *dev; > + void __iomem *regs; > + //wait_queue_head_t irq_waitq; I think u-boot doesn't like C++ comments? > + uint column; > + int spareonly; > + int page; > + /* Status and ID are in alternate locations. */ > + int alt_buf; > +#define ALT_BUF_ID 1 > +#define ALT_BUF_STAT 2 > + struct clk *clk; > +}; > + > +#define mtd_to_nfc(_mtd) (struct fsl_nfc *)((struct nand_chip > *)_mtd->priv)->priv; [snip] > +static int nfc_correct_data(struct mtd_info *mtd, u_char *dat, > + u_char *read_ecc, u_char *calc_ecc) > +{ > + struct fsl_nfc *nfc = mtd_to_nfc(mtd); > + u32 ecc_status; > + u8 ecc_count; > + int flip; > + > + /* Some extra ws here Ie, '/* ' with a space after the star. Maybe that is from me? > + * Errata: ECC status is stored at NFC_CFG[ECCADD] +4 for > + * little-endian and +7 for big-endian SOC. Access as 32 bits > + * and use low byte. > + */ This appears to be documented in the latest Vybrid manual (Rev7). > + ecc_status = __raw_readl(nfc->regs + ECC_SRAM_ADDR * 8 + 4); > + ecc_count = ecc_status & ECC_ERR_COUNT; > + if (!(ecc_status & ECC_STATUS_MASK)) > + return ecc_count; [snip] > +static void nfc_enable_hwecc(struct mtd_info *mtd, int mode) > +{ > +} > + > +struct nfc_config { > + int hardware_ecc; > + int width; > + int flash_bbt; > +}; > + > +//static int nfc_probe(struct platform_device *pdev) Another C++ comment. All minor nits. I am certainly ok with this code being included in u-boot. Regards, Bill Pringlemeir.
On Wed, 2014-08-06 at 10:59 +0200, Stefan Agner wrote: > This adds initial support for Freescale NFC (NAND Flash Controller). > The IP is used in ARM based Vybrid SoCs as well as on some PowerPC > devices. This driver is only tested on Vybrid. > > Signed-off-by: Stefan Agner <stefan@agner.ch> > --- > drivers/mtd/nand/Makefile | 1 + > drivers/mtd/nand/fsl_nfc.c | 676 +++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 677 insertions(+) > create mode 100644 drivers/mtd/nand/fsl_nfc.c > > diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile > index bf1312a..85cb0dd 100644 > --- a/drivers/mtd/nand/Makefile > +++ b/drivers/mtd/nand/Makefile > @@ -51,6 +51,7 @@ obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o > obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o > obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o > obj-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o > +obj-$(CONFIG_NAND_FSL_NFC) += fsl_nfc.o > obj-$(CONFIG_NAND_MXC) += mxc_nand.o Could you explain how this differs from mpc5121_nfc, mxc_nand, etc? If it's truly different enough to deserve its own driver, it should at least get a more specific name. > +static u32 nfc_read(struct mtd_info *mtd, uint reg) > +{ > + struct fsl_nfc *nfc = mtd_to_nfc(mtd); > + > + if (reg == NFC_FLASH_STATUS1 || > + reg == NFC_FLASH_STATUS2 || > + reg == NFC_IRQ_STATUS) > + return __raw_readl(nfc->regs + reg); > + /* Gang read/writes together for most registers. */ > + else > + return *(u32 *)(nfc->regs + reg); > +} > + > +static void nfc_write(struct mtd_info *mtd, uint reg, u32 val) > +{ > + struct fsl_nfc *nfc = mtd_to_nfc(mtd); > + > + if (reg == NFC_FLASH_STATUS1 || > + reg == NFC_FLASH_STATUS2 || > + reg == NFC_IRQ_STATUS) > + __raw_writel(val, nfc->regs + reg); > + /* Gang read/writes together for most registers. */ > + else > + *(u32 *)(nfc->regs + reg) = val; > +} You should always be using raw I/O accessors. If the intent is to bypass I/O ordering for certain registers, the raw accessors should already be skipping that. > +int board_nand_init(struct nand_chip *chip) > +{ [snip] > + /* second phase scan */ > + if (nand_scan_tail(mtd)) { > + err = -ENXIO; > + goto error; > + } > + board_nand_init() should only call nand_scan_tail if CONFIG_SYS_NAND_SELF_INIT is defined -- and if it is defined, then board_nand_init() takes no arguments. -Scott
Am 2014-08-12 00:33, schrieb Scott Wood: > On Wed, 2014-08-06 at 10:59 +0200, Stefan Agner wrote: >> This adds initial support for Freescale NFC (NAND Flash Controller). >> The IP is used in ARM based Vybrid SoCs as well as on some PowerPC >> devices. This driver is only tested on Vybrid. >> >> Signed-off-by: Stefan Agner <stefan@agner.ch> >> --- >> drivers/mtd/nand/Makefile | 1 + >> drivers/mtd/nand/fsl_nfc.c | 676 +++++++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 677 insertions(+) >> create mode 100644 drivers/mtd/nand/fsl_nfc.c >> >> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile >> index bf1312a..85cb0dd 100644 >> --- a/drivers/mtd/nand/Makefile >> +++ b/drivers/mtd/nand/Makefile >> @@ -51,6 +51,7 @@ obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o >> obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o >> obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o >> obj-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o >> +obj-$(CONFIG_NAND_FSL_NFC) += fsl_nfc.o >> obj-$(CONFIG_NAND_MXC) += mxc_nand.o > > Could you explain how this differs from mpc5121_nfc, mxc_nand, etc? If > it's truly different enough to deserve its own driver, it should at > least get a more specific name. > I'm not really an expert in NAND devices, but from looking into the reference manuals and drivers, I summarize those differences: mxc_nand: Supports 3 NAND Flash controller found in i.MX ARM SoCs: V1: MX31/MX27, 16 Bit Registers V2.1: MX25/MX35, 16 Bit Registers, V3.2: MX51/MX53, 32 Bit Registers, 12 address registers... All three have no DMA controller integrated. mpc5121_nfc: Supports the MPC5121 Power Architecture Processor NAND flash controller. Big Endian, but other than this, this IP looks very similar to the V2.1 NFC above (looking at the registers and the block diagram). fsl_nfc: Supports VF610 (2011), however should be easily portable to MPC5125 Power Architecture Processor (2009) and MCF5441X ColdFire V4 Microprocessor (2009) All three share the almost identical Register Layout, similar block diagram and have integrated DMA controller. IMHO, this IP really deserves a own driver. Also, from my humble perspective, it might have made more sense to integrate mpc5121_nfc into mxc_nand. In return, splitting out mxc_nand NFC V3.2 (looking at the ifdefs and quite different register layout). Anyway, not part of the topic here.. Regarding naming: A more specific name makes sense since Freescale calls all its Flash Controllers "NFC". I suggest vf610_nfc because that SoC is really is making use of the driver today... Looking at release dates, mpc5125_nfc would make sense as well. >> +static u32 nfc_read(struct mtd_info *mtd, uint reg) >> +{ >> + struct fsl_nfc *nfc = mtd_to_nfc(mtd); >> + >> + if (reg == NFC_FLASH_STATUS1 || >> + reg == NFC_FLASH_STATUS2 || >> + reg == NFC_IRQ_STATUS) >> + return __raw_readl(nfc->regs + reg); >> + /* Gang read/writes together for most registers. */ >> + else >> + return *(u32 *)(nfc->regs + reg); >> +} >> + >> +static void nfc_write(struct mtd_info *mtd, uint reg, u32 val) >> +{ >> + struct fsl_nfc *nfc = mtd_to_nfc(mtd); >> + >> + if (reg == NFC_FLASH_STATUS1 || >> + reg == NFC_FLASH_STATUS2 || >> + reg == NFC_IRQ_STATUS) >> + __raw_writel(val, nfc->regs + reg); >> + /* Gang read/writes together for most registers. */ >> + else >> + *(u32 *)(nfc->regs + reg) = val; >> +} > > You should always be using raw I/O accessors. If the intent is to > bypass I/O ordering for certain registers, the raw accessors should > already be skipping that. > Ok, will do. >> +int board_nand_init(struct nand_chip *chip) >> +{ > [snip] >> + /* second phase scan */ >> + if (nand_scan_tail(mtd)) { >> + err = -ENXIO; >> + goto error; >> + } >> + > > board_nand_init() should only call nand_scan_tail if > CONFIG_SYS_NAND_SELF_INIT is defined -- and if it is defined, then > board_nand_init() takes no arguments. > Ok, we need the page size during initialization, hence nand_scan_ident needs to be in the init code. I remove the argument from board_nand_init then. -- Stefan
On Tue, 2014-08-12 at 23:13 +0200, Stefan Agner wrote: > Am 2014-08-12 00:33, schrieb Scott Wood: > > On Wed, 2014-08-06 at 10:59 +0200, Stefan Agner wrote: > >> This adds initial support for Freescale NFC (NAND Flash Controller). > >> The IP is used in ARM based Vybrid SoCs as well as on some PowerPC > >> devices. This driver is only tested on Vybrid. > >> > >> Signed-off-by: Stefan Agner <stefan@agner.ch> > >> --- > >> drivers/mtd/nand/Makefile | 1 + > >> drivers/mtd/nand/fsl_nfc.c | 676 +++++++++++++++++++++++++++++++++++++++++++++ > >> 2 files changed, 677 insertions(+) > >> create mode 100644 drivers/mtd/nand/fsl_nfc.c > >> > >> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile > >> index bf1312a..85cb0dd 100644 > >> --- a/drivers/mtd/nand/Makefile > >> +++ b/drivers/mtd/nand/Makefile > >> @@ -51,6 +51,7 @@ obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o > >> obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o > >> obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o > >> obj-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o > >> +obj-$(CONFIG_NAND_FSL_NFC) += fsl_nfc.o > >> obj-$(CONFIG_NAND_MXC) += mxc_nand.o > > > > Could you explain how this differs from mpc5121_nfc, mxc_nand, etc? If > > it's truly different enough to deserve its own driver, it should at > > least get a more specific name. > > > > I'm not really an expert in NAND devices, but from looking into the > reference manuals and drivers, I summarize those differences: > mxc_nand: Supports 3 NAND Flash controller found in i.MX ARM SoCs: > V1: MX31/MX27, 16 Bit Registers > V2.1: MX25/MX35, 16 Bit Registers, > V3.2: MX51/MX53, 32 Bit Registers, 12 address registers... > All three have no DMA controller integrated. > > mpc5121_nfc: Supports the MPC5121 Power Architecture Processor NAND > flash controller. Big Endian, but other than this, this IP looks very > similar to the V2.1 NFC above (looking at the registers and the block > diagram). Yes, this is the similarity that prompted me to ask the question... I asked it back when those drivers were submitted, but was unable to get the submitter of each to work together on a common driver. > fsl_nfc: Supports VF610 (2011), however should be easily portable to > MPC5125 Power Architecture Processor (2009) and MCF5441X ColdFire V4 > Microprocessor (2009) > All three share the almost identical Register Layout, similar block > diagram and have integrated DMA controller. > > IMHO, this IP really deserves a own driver. > > Also, from my humble perspective, it might have made more sense to > integrate mpc5121_nfc into mxc_nand. In return, splitting out mxc_nand > NFC V3.2 (looking at the ifdefs and quite different register layout). > Anyway, not part of the topic here.. > > Regarding naming: A more specific name makes sense since Freescale calls > all its Flash Controllers "NFC". I suggest vf610_nfc because that SoC is > really is making use of the driver today... Looking at release dates, > mpc5125_nfc would make sense as well. OK. > >> +static u32 nfc_read(struct mtd_info *mtd, uint reg) > >> +{ > >> + struct fsl_nfc *nfc = mtd_to_nfc(mtd); > >> + > >> + if (reg == NFC_FLASH_STATUS1 || > >> + reg == NFC_FLASH_STATUS2 || > >> + reg == NFC_IRQ_STATUS) > >> + return __raw_readl(nfc->regs + reg); > >> + /* Gang read/writes together for most registers. */ > >> + else > >> + return *(u32 *)(nfc->regs + reg); > >> +} > >> + > >> +static void nfc_write(struct mtd_info *mtd, uint reg, u32 val) > >> +{ > >> + struct fsl_nfc *nfc = mtd_to_nfc(mtd); > >> + > >> + if (reg == NFC_FLASH_STATUS1 || > >> + reg == NFC_FLASH_STATUS2 || > >> + reg == NFC_IRQ_STATUS) > >> + __raw_writel(val, nfc->regs + reg); > >> + /* Gang read/writes together for most registers. */ > >> + else > >> + *(u32 *)(nfc->regs + reg) = val; > >> +} > > > > You should always be using raw I/O accessors. If the intent is to > > bypass I/O ordering for certain registers, the raw accessors should > > already be skipping that. > > > > Ok, will do. Sorry, the above should say "always be using I/O accesors", not always raw ones. > >> +int board_nand_init(struct nand_chip *chip) > >> +{ > > [snip] > >> + /* second phase scan */ > >> + if (nand_scan_tail(mtd)) { > >> + err = -ENXIO; > >> + goto error; > >> + } > >> + > > > > board_nand_init() should only call nand_scan_tail if > > CONFIG_SYS_NAND_SELF_INIT is defined -- and if it is defined, then > > board_nand_init() takes no arguments. > > > > Ok, we need the page size during initialization, hence nand_scan_ident > needs to be in the init code. I remove the argument from board_nand_init > then. Look at fsl_elbc_nand.c and fsl_ifc_nand.c for examples of how to use CONFIG_SYS_NAND_SELF_INIT. -Scott
On 12 Aug 2014, scottwood@freescale.com wrote: > On Tue, 2014-08-12 at 23:13 +0200, Stefan Agner wrote: >> Am 2014-08-12 00:33, schrieb Scott Wood: >>> On Wed, 2014-08-06 at 10:59 +0200, Stefan Agner wrote: >>>> This adds initial support for Freescale NFC (NAND Flash >>>> Controller). The IP is used in ARM based Vybrid SoCs as well as on >>>> some PowerPC devices. This driver is only tested on Vybrid. >>>> >>>> Signed-off-by: Stefan Agner <stefan@agner.ch> >>>> --- >>>> drivers/mtd/nand/Makefile | 1 + >>>> drivers/mtd/nand/fsl_nfc.c | 676 >>>> +++++++++++++++++++++++++++++++++++++++++++++ >>>> 2 files changed, 677 insertions(+) >>>> create mode 100644 drivers/mtd/nand/fsl_nfc.c >>>> >>>> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile >>>> index bf1312a..85cb0dd 100644 >>>> --- a/drivers/mtd/nand/Makefile >>>> +++ b/drivers/mtd/nand/Makefile >>>> @@ -51,6 +51,7 @@ obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o >>>> obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o >>>> obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o >>>> obj-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o >>>> +obj-$(CONFIG_NAND_FSL_NFC) += fsl_nfc.o >>>> obj-$(CONFIG_NAND_MXC) += mxc_nand.o >>> >>> Could you explain how this differs from mpc5121_nfc, mxc_nand, etc? >>> If it's truly different enough to deserve its own driver, it should >>> at least get a more specific name. >>> >> >> I'm not really an expert in NAND devices, but from looking into the >> reference manuals and drivers, I summarize those differences: >> mxc_nand: Supports 3 NAND Flash controller found in i.MX ARM SoCs: >> V1: MX31/MX27, 16 Bit Registers >> V2.1: MX25/MX35, 16 Bit Registers, >> V3.2: MX51/MX53, 32 Bit Registers, 12 address registers... >> All three have no DMA controller integrated. >> mpc5121_nfc: Supports the MPC5121 Power Architecture Processor NAND >> flash controller. Big Endian, but other than this, this IP looks very >> similar to the V2.1 NFC above (looking at the registers and the block >> diagram). > Yes, this is the similarity that prompted me to ask the question... I > asked it back when those drivers were submitted, but was unable to get > the submitter of each to work together on a common driver. I am familiar with the mxc_nand on the imx. The register set might look similar (ie, the register names) but when you look in depth at the bits and their function, it is pretty clear it is different. Some people inside Freescale have said that this is a completely different IP. >> fsl_nfc: Supports VF610 (2011), however should be easily portable to >> MPC5125 Power Architecture Processor (2009) and MCF5441X ColdFire V4 >> Microprocessor (2009) >> All three share the almost identical Register Layout, similar block >> diagram and have integrated DMA controller. >> >> IMHO, this IP really deserves a own driver. >> >> Also, from my humble perspective, it might have made more sense to >> integrate mpc5121_nfc into mxc_nand. In return, splitting out >> mxc_nand NFC V3.2 (looking at the ifdefs and quite different register >> layout). Anyway, not part of the topic here.. >> >> Regarding naming: A more specific name makes sense since Freescale >> calls all its Flash Controllers "NFC". I suggest vf610_nfc because >> that SoC is really is making use of the driver today... Looking at >> release dates, mpc5125_nfc would make sense as well. > OK. Here we talked about the name, http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/251698.html It is also present on a Kinetis K70 chip. What should be important is that we use the same name in both U-boot and Linux? Won't it be confusing to call it something different? I really don't care what it is called as long as it is consistent. >>>> +static u32 nfc_read(struct mtd_info *mtd, uint reg) >>>> +{ >>>> + struct fsl_nfc *nfc = mtd_to_nfc(mtd); >>>> + >>>> + if (reg == NFC_FLASH_STATUS1 || >>>> + reg == NFC_FLASH_STATUS2 || >>>> + reg == NFC_IRQ_STATUS) >>>> + return __raw_readl(nfc->regs + reg); >>>> + /* Gang read/writes together for most registers. */ >>>> + else >>>> + return *(u32 *)(nfc->regs + reg); >>>> +} >>>> + >>>> +static void nfc_write(struct mtd_info *mtd, uint reg, u32 val) >>>> +{ >>>> + struct fsl_nfc *nfc = mtd_to_nfc(mtd); >>>> + >>>> + if (reg == NFC_FLASH_STATUS1 || >>>> + reg == NFC_FLASH_STATUS2 || >>>> + reg == NFC_IRQ_STATUS) >>>> + __raw_writel(val, nfc->regs + reg); >>>> + /* Gang read/writes together for most registers. */ >>>> + else >>>> + *(u32 *)(nfc->regs + reg) = val; >>>> +} >>> >>> You should always be using raw I/O accessors. If the intent is to >>> bypass I/O ordering for certain registers, the raw accessors should >>> already be skipping that. >> Ok, will do. > Sorry, the above should say "always be using I/O accesors", not always > raw ones. This is probably because of me. There are lines like this for configuration, /* Set configuration register. */ nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_ADDR_AUTO_INCR_BIT); nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_BUFNO_AUTO_INCR_BIT); nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_BOOT_MODE_BIT); nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_DMA_REQ_BIT); nfc_set(mtd, NFC_FLASH_CONFIG, CONFIG_FAST_FLASH_BIT); If you use some sort of 'volatile', you are saying to the compiler that these lines are *not*, ldr r0, [r1, #CONFIG] # read previous value ldr r2, =~MASK orr r0, #FAST_FLASH_BIT # set one bit. and r0, r2 # clear all bits at once. str r0, [r1, #CONFIG] # write it back. Instead it will change into five different load/modify/stores. The memory itself is just like SRAM except a few registers that are actually volatile; ie changed via the hardware. Particularly bad are the memcpy_io() on the ARM. Using these results in about 1/2 to 1/4 of the performance of the drivers through-put on the Vybrid. I can see that using accessors is good, but just replacing this with 'writel' will result in significantly more code and slower throughput. If people insist on this, then something like, val = nfc_read(mtd, NFC_REG); val = nfc_clear(val, CONFIG_ADDR_AUTO_INCR_BIT); val = nfc_clear(val, CONFIG_BUFNO_AUTO_INCR_BIT); val = nfc_clear(val, CONFIG_BOOT_MODE_BIT); val = nfc_clear(val, CONFIG_DMA_REQ_BIT); val = nfc_set(val, CONFIG_FAST_FLASH_BIT); nfc_write(mtd, NFC_REG, val); would result in the same code with 'nfc_read()' and 'nfc_write()' using the I/O accessors. I found this more difficult to read for the higher level functions. Instead some some standard macros for setting and clearing bits could be used. The original driver was using 'nfc_set()' and 'nfc_clear()'. Maybe they should just go. >>>> +int board_nand_init(struct nand_chip *chip) >>>> +{ >>> [snip] >>>> + /* second phase scan */ >>>> + if (nand_scan_tail(mtd)) { >>>> + err = -ENXIO; >>>> + goto error; >>>> + } >>>> + >>> >>> board_nand_init() should only call nand_scan_tail if >>> CONFIG_SYS_NAND_SELF_INIT is defined -- and if it is defined, then >>> board_nand_init() takes no arguments. >>> >> >> Ok, we need the page size during initialization, hence >> nand_scan_ident needs to be in the init code. I remove the argument >> from board_nand_init then. > > Look at fsl_elbc_nand.c and fsl_ifc_nand.c for examples of how to use > CONFIG_SYS_NAND_SELF_INIT.
Am 2014-08-13 00:58, schrieb Bill Pringlemeir: > On 12 Aug 2014, scottwood@freescale.com wrote: > >> On Tue, 2014-08-12 at 23:13 +0200, Stefan Agner wrote: >>> Am 2014-08-12 00:33, schrieb Scott Wood: >>>> On Wed, 2014-08-06 at 10:59 +0200, Stefan Agner wrote: >>>>> This adds initial support for Freescale NFC (NAND Flash >>>>> Controller). The IP is used in ARM based Vybrid SoCs as well as on >>>>> some PowerPC devices. This driver is only tested on Vybrid. >>>>> >>>>> Signed-off-by: Stefan Agner <stefan@agner.ch> >>>>> --- >>>>> drivers/mtd/nand/Makefile | 1 + >>>>> drivers/mtd/nand/fsl_nfc.c | 676 >>>>> +++++++++++++++++++++++++++++++++++++++++++++ >>>>> 2 files changed, 677 insertions(+) >>>>> create mode 100644 drivers/mtd/nand/fsl_nfc.c >>>>> >>>>> diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile >>>>> index bf1312a..85cb0dd 100644 >>>>> --- a/drivers/mtd/nand/Makefile >>>>> +++ b/drivers/mtd/nand/Makefile >>>>> @@ -51,6 +51,7 @@ obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o >>>>> obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o >>>>> obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o >>>>> obj-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o >>>>> +obj-$(CONFIG_NAND_FSL_NFC) += fsl_nfc.o >>>>> obj-$(CONFIG_NAND_MXC) += mxc_nand.o >>>> >>>> Could you explain how this differs from mpc5121_nfc, mxc_nand, etc? >>>> If it's truly different enough to deserve its own driver, it should >>>> at least get a more specific name. >>>> >>> >>> I'm not really an expert in NAND devices, but from looking into the >>> reference manuals and drivers, I summarize those differences: >>> mxc_nand: Supports 3 NAND Flash controller found in i.MX ARM SoCs: >>> V1: MX31/MX27, 16 Bit Registers >>> V2.1: MX25/MX35, 16 Bit Registers, >>> V3.2: MX51/MX53, 32 Bit Registers, 12 address registers... >>> All three have no DMA controller integrated. > >>> mpc5121_nfc: Supports the MPC5121 Power Architecture Processor NAND >>> flash controller. Big Endian, but other than this, this IP looks very >>> similar to the V2.1 NFC above (looking at the registers and the block >>> diagram). > >> Yes, this is the similarity that prompted me to ask the question... I >> asked it back when those drivers were submitted, but was unable to get >> the submitter of each to work together on a common driver. > > I am familiar with the mxc_nand on the imx. The register set might look > similar (ie, the register names) but when you look in depth at the bits > and their function, it is pretty clear it is different. Some people > inside Freescale have said that this is a completely different IP. > >>> fsl_nfc: Supports VF610 (2011), however should be easily portable to >>> MPC5125 Power Architecture Processor (2009) and MCF5441X ColdFire V4 >>> Microprocessor (2009) >>> All three share the almost identical Register Layout, similar block >>> diagram and have integrated DMA controller. >>> >>> IMHO, this IP really deserves a own driver. >>> >>> Also, from my humble perspective, it might have made more sense to >>> integrate mpc5121_nfc into mxc_nand. In return, splitting out >>> mxc_nand NFC V3.2 (looking at the ifdefs and quite different register >>> layout). Anyway, not part of the topic here.. >>> >>> Regarding naming: A more specific name makes sense since Freescale >>> calls all its Flash Controllers "NFC". I suggest vf610_nfc because >>> that SoC is really is making use of the driver today... Looking at >>> release dates, mpc5125_nfc would make sense as well. > >> OK. > > Here we talked about the name, > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/251698.html > > It is also present on a Kinetis K70 chip. > > What should be important is that we use the same name in both U-boot > and Linux? Won't it be confusing to call it something different? I > really don't care what it is called as long as it is consistent. > I agree, we should take the same name. But so far, nobody expressed a preference in the MTD mailing list. Probably before settling with a name, we should write that to the MTD mailing list as well so we could change the name in case somebody does not agree. Since the Kinetis K70 chip is not really suited for Linux I guess naming it according to this chip is not really a good option. I'm not entirely happy with vf610_nfc, but I guess it's the best we have. Any objections/other ideas? >>>>> +static u32 nfc_read(struct mtd_info *mtd, uint reg) >>>>> +{ >>>>> + struct fsl_nfc *nfc = mtd_to_nfc(mtd); >>>>> + >>>>> + if (reg == NFC_FLASH_STATUS1 || >>>>> + reg == NFC_FLASH_STATUS2 || >>>>> + reg == NFC_IRQ_STATUS) >>>>> + return __raw_readl(nfc->regs + reg); >>>>> + /* Gang read/writes together for most registers. */ >>>>> + else >>>>> + return *(u32 *)(nfc->regs + reg); >>>>> +} >>>>> + >>>>> +static void nfc_write(struct mtd_info *mtd, uint reg, u32 val) >>>>> +{ >>>>> + struct fsl_nfc *nfc = mtd_to_nfc(mtd); >>>>> + >>>>> + if (reg == NFC_FLASH_STATUS1 || >>>>> + reg == NFC_FLASH_STATUS2 || >>>>> + reg == NFC_IRQ_STATUS) >>>>> + __raw_writel(val, nfc->regs + reg); >>>>> + /* Gang read/writes together for most registers. */ >>>>> + else >>>>> + *(u32 *)(nfc->regs + reg) = val; >>>>> +} >>>> >>>> You should always be using raw I/O accessors. If the intent is to >>>> bypass I/O ordering for certain registers, the raw accessors should >>>> already be skipping that. > >>> Ok, will do. > >> Sorry, the above should say "always be using I/O accesors", not always >> raw ones. > > This is probably because of me. There are lines like this for > configuration, > > /* Set configuration register. */ > nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_ADDR_AUTO_INCR_BIT); > nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_BUFNO_AUTO_INCR_BIT); > nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_BOOT_MODE_BIT); > nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_DMA_REQ_BIT); > nfc_set(mtd, NFC_FLASH_CONFIG, CONFIG_FAST_FLASH_BIT); > > If you use some sort of 'volatile', you are saying to the compiler that > these lines are *not*, > > ldr r0, [r1, #CONFIG] # read previous value > ldr r2, =~MASK > orr r0, #FAST_FLASH_BIT # set one bit. > and r0, r2 # clear all bits at once. > str r0, [r1, #CONFIG] # write it back. > > Instead it will change into five different load/modify/stores. The > memory itself is just like SRAM except a few registers that are actually > volatile; ie changed via the hardware. > > Particularly bad are the memcpy_io() on the ARM. Using these results > in about 1/2 to 1/4 of the performance of the drivers through-put on the > Vybrid. I can see that using accessors is good, but just replacing this > with 'writel' will result in significantly more code and slower > throughput. > > If people insist on this, then something like, > > val = nfc_read(mtd, NFC_REG); > val = nfc_clear(val, CONFIG_ADDR_AUTO_INCR_BIT); > val = nfc_clear(val, CONFIG_BUFNO_AUTO_INCR_BIT); > val = nfc_clear(val, CONFIG_BOOT_MODE_BIT); > val = nfc_clear(val, CONFIG_DMA_REQ_BIT); > val = nfc_set(val, CONFIG_FAST_FLASH_BIT); > nfc_write(mtd, NFC_REG, val); > > would result in the same code with 'nfc_read()' and 'nfc_write()' using > the I/O accessors. I found this more difficult to read for the higher > level functions. Instead some some standard macros for setting and > clearing bits could be used. The original driver was using 'nfc_set()' > and 'nfc_clear()'. Maybe they should just go. > I like the nfc_read/(nfc_set/nfc_clear)/nfc_write approach more then having nfc_set doing the nfc_read/nfc_write hidden and rely on compiler optimization. Additionally, this really shows that the programmer _want_ this register written in one step. I will try to alter the driver again to use this kind of access to see how it looks in reality. >>>>> +int board_nand_init(struct nand_chip *chip) >>>>> +{ >>>> [snip] >>>>> + /* second phase scan */ >>>>> + if (nand_scan_tail(mtd)) { >>>>> + err = -ENXIO; >>>>> + goto error; >>>>> + } >>>>> + >>>> >>>> board_nand_init() should only call nand_scan_tail if >>>> CONFIG_SYS_NAND_SELF_INIT is defined -- and if it is defined, then >>>> board_nand_init() takes no arguments. >>>> >>> >>> Ok, we need the page size during initialization, hence >>> nand_scan_ident needs to be in the init code. I remove the argument >>> from board_nand_init then. >> >> Look at fsl_elbc_nand.c and fsl_ifc_nand.c for examples of how to use >> CONFIG_SYS_NAND_SELF_INIT.
On Tue, 2014-08-12 at 18:58 -0400, Bill Pringlemeir wrote: > On 12 Aug 2014, scottwood@freescale.com wrote: > > > On Tue, 2014-08-12 at 23:13 +0200, Stefan Agner wrote: > >> Am 2014-08-12 00:33, schrieb Scott Wood: > >>> You should always be using raw I/O accessors. If the intent is to > >>> bypass I/O ordering for certain registers, the raw accessors should > >>> already be skipping that. > > >> Ok, will do. > > > Sorry, the above should say "always be using I/O accesors", not always > > raw ones. > > This is probably because of me. There are lines like this for > configuration, > > /* Set configuration register. */ > nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_ADDR_AUTO_INCR_BIT); > nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_BUFNO_AUTO_INCR_BIT); > nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_BOOT_MODE_BIT); > nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_DMA_REQ_BIT); > nfc_set(mtd, NFC_FLASH_CONFIG, CONFIG_FAST_FLASH_BIT); > > If you use some sort of 'volatile', you are saying to the compiler that > these lines are *not*, > > ldr r0, [r1, #CONFIG] # read previous value > ldr r2, =~MASK > orr r0, #FAST_FLASH_BIT # set one bit. > and r0, r2 # clear all bits at once. > str r0, [r1, #CONFIG] # write it back. > > Instead it will change into five different load/modify/stores. The > memory itself is just like SRAM except a few registers that are actually > volatile; ie changed via the hardware. If this is performance-critical then it would be best to modify the code to explicitly do one read from I/O (if you can't know in advance what the existing value will be), clear all the bits you're going to clear, then have one explicit write back to the I/O device -- rather than treating it as ordinary memory for the compiler to optimize accesses to. If nothing else, it makes the code clearer to make I/O accesses explicit, and reduces the likelihood that people see I/O accesses without accessors and go on to do the same in some other less safe circumstance. -Scott
On 13 Aug 2014, scottwood@freescale.com wrote: > On Tue, 2014-08-12 at 18:58 -0400, Bill Pringlemeir wrote: >> On 12 Aug 2014, scottwood@freescale.com wrote: >> >>> On Tue, 2014-08-12 at 23:13 +0200, Stefan Agner wrote: >>>> Am 2014-08-12 00:33, schrieb Scott Wood: >>>>> You should always be using raw I/O accessors. If the intent is to >>>>> bypass I/O ordering for certain registers, the raw accessors >>>>> should already be skipping that. >> >>>> Ok, will do. >> >>> Sorry, the above should say "always be using I/O accesors", not >>> always raw ones. >> >> This is probably because of me. There are lines like this for >> configuration, >> >> /* Set configuration register. */ >> nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_ADDR_AUTO_INCR_BIT); >> nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_BUFNO_AUTO_INCR_BIT); >> nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_BOOT_MODE_BIT); >> nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_DMA_REQ_BIT); >> nfc_set(mtd, NFC_FLASH_CONFIG, CONFIG_FAST_FLASH_BIT); >> >> If you use some sort of 'volatile', you are saying to the compiler >> that these lines are *not*, >> >> ldr r0, [r1, #CONFIG] # read previous value >> ldr r2, =~MASK >> orr r0, #FAST_FLASH_BIT # set one bit. >> and r0, r2 # clear all bits at once. >> str r0, [r1, #CONFIG] # write it back. >> >> Instead it will change into five different load/modify/stores. The >> memory itself is just like SRAM except a few registers that are >> actually volatile; ie changed via the hardware. > If this is performance-critical then it would be best to modify the > code to explicitly do one read from I/O (if you can't know in advance > what the existing value will be), clear all the bits you're going to > clear, then have one explicit write back to the I/O device -- rather > than treating it as ordinary memory for the compiler to optimize > accesses to. > If nothing else, it makes the code clearer to make I/O accesses > explicit, and reduces the likelihood that people see I/O accesses > without accessors and go on to do the same in some other less safe > circumstance. Yes, absolutely. The issue is that the 'nfc_clear()', etc seems more programmer friendly to me. It was from an original driver. I believe this is what Stefan means by 'optimized' and not 'raw_readl/raw_writel' versus 'readl/writel'. I believe that this is smaller/faster in all cases; not just hot paths as the code should be smaller. I tried to modify the accessor to leave the original code as is. The registers are a bunch of bit fields. It is clear to read them each as being set/cleared on a different lines? However, the whole group can be set at once at the machine level. Sometimes the bit fields aren't so related. So, if you are trying to write the code about what is happening to the NAND flash (Ie cycles to run) then ganging the NFC controller registers together can make things a little more obscure. Maybe this is a small price to pay if the register ordering is more of an issue to people. The accesses are generally all order independent *when idle*. There is one bit of the NFC_FLASH_CMD2 register as bit0 or START_BIT in the code. When it is toggled, the NFC controller starts it's business and then only a few register can be polled or an interrupt generated. In this phase, no register changes should take place or at least care should be taken. I have only compiler barriers in the driver I submitted to the Linux MTD. It is possible that the PowerPC or other multi-issue CPUs might need the iowmb() or otherwise when the 'START_BIT' is toggled. I had thought of this in the mean time, so thank-you for bringing it up. Allowing the compiler to re-order the settings of the registers when idle can let it decide to do all the zeroing at once, etc depending on what is optimal. The 'read/modify many/write' is a happy medium for me. Minimizing accesses to the registers is important as these often involve a slow bus interface and also generate a lot of code for load/store CPUs. Regarding "can't know in advance", I think that some of the register values maybe set by the boot rom. This might make more sense for Linux than U-Boot. However, after the initial configuration, many do need the 'read/modify/write' as there are many bit fields with different functionality. Thanks, Bill Pringlemeir.
On Wed, 2014-08-13 at 17:44 -0400, Bill Pringlemeir wrote: > Regarding "can't know in advance", I think that some of the register > values maybe set by the boot rom. This might make more sense for Linux > than U-Boot. However, after the initial configuration, many do need the > 'read/modify/write' as there are many bit fields with different > functionality. If the register is only modified by software, and not asynchronously by hardware, then you could read the value once when the driver starts, and cache its value to avoid a reportedly expensive I/O access every time you need to modify it. -Scott
On 13 Aug 2014, scottwood@freescale.com wrote: > On Wed, 2014-08-13 at 17:44 -0400, Bill Pringlemeir wrote: >> Regarding "can't know in advance", I think that some of the register >> values maybe set by the boot rom. This might make more sense for >> Linux than U-Boot. However, after the initial configuration, many do >> need the 'read/modify/write' as there are many bit fields with >> different functionality. > If the register is only modified by software, and not asynchronously > by hardware, then you could read the value once when the driver > starts, and cache its value to avoid a reportedly expensive I/O access > every time you need to modify it. Yes, that is a good point. The regmap interface could be used in the Linux kernel. I don't see any infrastructure like that in U-Boot? It is fairly simple to re-invent as this driver only needs the flat structure. Regards, Bill Pringlemeir.
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index bf1312a..85cb0dd 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -51,6 +51,7 @@ obj-$(CONFIG_NAND_KB9202) += kb9202_nand.o obj-$(CONFIG_NAND_KIRKWOOD) += kirkwood_nand.o obj-$(CONFIG_NAND_KMETER1) += kmeter1_nand.o obj-$(CONFIG_NAND_MPC5121_NFC) += mpc5121_nfc.o +obj-$(CONFIG_NAND_FSL_NFC) += fsl_nfc.o obj-$(CONFIG_NAND_MXC) += mxc_nand.o obj-$(CONFIG_NAND_MXS) += mxs_nand.o obj-$(CONFIG_NAND_NDFC) += ndfc.o diff --git a/drivers/mtd/nand/fsl_nfc.c b/drivers/mtd/nand/fsl_nfc.c new file mode 100644 index 0000000..df2c8be --- /dev/null +++ b/drivers/mtd/nand/fsl_nfc.c @@ -0,0 +1,676 @@ +/* + * Copyright 2009-2014 Freescale Semiconductor, Inc. and others + * + * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver. + * Ported to U-Boot by Stefan Agner + * Based on RFC driver posted on Kernel Mailing list by Bill Pringlemeir + * Jason ported to M54418TWR and MVFA5. + * Authors: Stefan Agner <stefan.agner@toradex.com> + * Bill Pringlemeir <bpringlemeir@nbsps.com> + * Shaohui Xie <b21989@freescale.com> + * Jason Jin <Jason.jin@freescale.com> + * + * Based on original driver mpc5121_nfc.c. + * + * This is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * Limitations: + * - Untested on MPC5125 and M54418. + * - DMA not used. + * - 2K pages or less. + * - Only 2K page w. 64+OOB and hardware ECC. + */ + +#include <common.h> +#include <malloc.h> + +#include <linux/mtd/mtd.h> +#include <linux/mtd/nand.h> +#include <linux/mtd/partitions.h> + +#include <nand.h> +#include <errno.h> +#include <asm/io.h> +#include <asm/processor.h> + +#define DRV_NAME "fsl_nfc" + +/* Register Offsets */ +#define NFC_FLASH_CMD1 0x3F00 +#define NFC_FLASH_CMD2 0x3F04 +#define NFC_COL_ADDR 0x3F08 +#define NFC_ROW_ADDR 0x3F0c +#define NFC_ROW_ADDR_INC 0x3F14 +#define NFC_FLASH_STATUS1 0x3F18 +#define NFC_FLASH_STATUS2 0x3F1c +#define NFC_CACHE_SWAP 0x3F28 +#define NFC_SECTOR_SIZE 0x3F2c +#define NFC_FLASH_CONFIG 0x3F30 +#define NFC_IRQ_STATUS 0x3F38 + +/* Addresses for NFC MAIN RAM BUFFER areas */ +#define NFC_MAIN_AREA(n) ((n) * 0x1000) + +#define PAGE_2K 0x0800 +#define OOB_64 0x0040 + +/* + * NFC_CMD2[CODE] values. See section: + * - 31.4.7 Flash Command Code Description, Vybrid manual + * - 23.8.6 Flash Command Sequencer, MPC5125 manual + * + * Briefly these are bitmasks of controller cycles. + */ +#define READ_PAGE_CMD_CODE 0x7EE0 +#define PROGRAM_PAGE_CMD_CODE 0x7FC0 +#define ERASE_CMD_CODE 0x4EC0 +#define READ_ID_CMD_CODE 0x4804 +#define RESET_CMD_CODE 0x4040 +#define STATUS_READ_CMD_CODE 0x4068 + +/* NFC ECC mode define */ +#define ECC_BYPASS 0 +#define ECC_45_BYTE 6 + +/*** Register Mask and bit definitions */ + +/* NFC_FLASH_CMD1 Field */ +#define CMD_BYTE2_MASK 0xFF000000 +#define CMD_BYTE2_SHIFT 24 + +/* NFC_FLASH_CM2 Field */ +#define CMD_BYTE1_MASK 0xFF000000 +#define CMD_BYTE1_SHIFT 24 +#define CMD_CODE_MASK 0x00FFFF00 +#define CMD_CODE_SHIFT 8 +#define BUFNO_MASK 0x00000006 +#define BUFNO_SHIFT 1 +#define START_BIT (1<<0) + +/* NFC_COL_ADDR Field */ +#define COL_ADDR_MASK 0x0000FFFF +#define COL_ADDR_SHIFT 0 + +/* NFC_ROW_ADDR Field */ +#define ROW_ADDR_MASK 0x00FFFFFF +#define ROW_ADDR_SHIFT 0 +#define ROW_ADDR_CHIP_SEL_RB_MASK 0xF0000000 +#define ROW_ADDR_CHIP_SEL_RB_SHIFT 28 +#define ROW_ADDR_CHIP_SEL_MASK 0x0F000000 +#define ROW_ADDR_CHIP_SEL_SHIFT 24 + +/* NFC_FLASH_STATUS2 Field */ +#define STATUS_BYTE1_MASK 0x000000FF + +/* NFC_FLASH_CONFIG Field */ +#define CONFIG_ECC_SRAM_ADDR_MASK 0x7FC00000 +#define CONFIG_ECC_SRAM_ADDR_SHIFT 22 +#define CONFIG_ECC_SRAM_REQ_BIT (1<<21) +#define CONFIG_DMA_REQ_BIT (1<<20) +#define CONFIG_ECC_MODE_MASK 0x000E0000 +#define CONFIG_ECC_MODE_SHIFT 17 +#define CONFIG_FAST_FLASH_BIT (1<<16) +#define CONFIG_16BIT (1<<7) +#define CONFIG_BOOT_MODE_BIT (1<<6) +#define CONFIG_ADDR_AUTO_INCR_BIT (1<<5) +#define CONFIG_BUFNO_AUTO_INCR_BIT (1<<4) +#define CONFIG_PAGE_CNT_MASK 0xF +#define CONFIG_PAGE_CNT_SHIFT 0 + +/* NFC_IRQ_STATUS Field */ +#define IDLE_IRQ_BIT (1<<29) +#define IDLE_EN_BIT (1<<20) +#define CMD_DONE_CLEAR_BIT (1<<18) +#define IDLE_CLEAR_BIT (1<<17) + +#define NFC_TIMEOUT (1000) + +/* ECC status placed at end of buffers. */ +#define ECC_SRAM_ADDR ((PAGE_2K+256-8) >> 3) +#define ECC_STATUS_MASK 0x80 +#define ECC_ERR_COUNT 0x3F + +struct fsl_nfc { + struct mtd_info *mtd; + struct nand_chip chip; + struct device *dev; + void __iomem *regs; + //wait_queue_head_t irq_waitq; + uint column; + int spareonly; + int page; + /* Status and ID are in alternate locations. */ + int alt_buf; +#define ALT_BUF_ID 1 +#define ALT_BUF_STAT 2 + struct clk *clk; +}; + +#define mtd_to_nfc(_mtd) (struct fsl_nfc *)((struct nand_chip *)_mtd->priv)->priv; + +static u8 bbt_pattern[] = {'B', 'b', 't', '0' }; +static u8 mirror_pattern[] = {'1', 't', 'b', 'B' }; + +static struct nand_bbt_descr bbt_main_descr = { + .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE | + NAND_BBT_2BIT | NAND_BBT_VERSION, + .offs = 11, + .len = 4, + .veroffs = 15, + .maxblocks = 4, + .pattern = bbt_pattern, +}; + +static struct nand_bbt_descr bbt_mirror_descr = { + .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE | + NAND_BBT_2BIT | NAND_BBT_VERSION, + .offs = 11, + .len = 4, + .veroffs = 15, + .maxblocks = 4, + .pattern = mirror_pattern, +}; + +static struct nand_ecclayout nfc_ecc45 = { + .eccbytes = 45, + .eccpos = {19, 20, 21, 22, 23, + 24, 25, 26, 27, 28, 29, 30, 31, + 32, 33, 34, 35, 36, 37, 38, 39, + 40, 41, 42, 43, 44, 45, 46, 47, + 48, 49, 50, 51, 52, 53, 54, 55, + 56, 57, 58, 59, 60, 61, 62, 63}, + .oobfree = { + {.offset = 8, + .length = 11} } +}; + +static u32 nfc_read(struct mtd_info *mtd, uint reg) +{ + struct fsl_nfc *nfc = mtd_to_nfc(mtd); + + if (reg == NFC_FLASH_STATUS1 || + reg == NFC_FLASH_STATUS2 || + reg == NFC_IRQ_STATUS) + return __raw_readl(nfc->regs + reg); + /* Gang read/writes together for most registers. */ + else + return *(u32 *)(nfc->regs + reg); +} + +static void nfc_write(struct mtd_info *mtd, uint reg, u32 val) +{ + struct fsl_nfc *nfc = mtd_to_nfc(mtd); + + if (reg == NFC_FLASH_STATUS1 || + reg == NFC_FLASH_STATUS2 || + reg == NFC_IRQ_STATUS) + __raw_writel(val, nfc->regs + reg); + /* Gang read/writes together for most registers. */ + else + *(u32 *)(nfc->regs + reg) = val; +} + +static void nfc_set(struct mtd_info *mtd, uint reg, u32 bits) +{ + nfc_write(mtd, reg, nfc_read(mtd, reg) | bits); +} + +static void nfc_clear(struct mtd_info *mtd, uint reg, u32 bits) +{ + nfc_write(mtd, reg, nfc_read(mtd, reg) & ~bits); +} + +static void nfc_set_field(struct mtd_info *mtd, u32 reg, + u32 mask, u32 shift, u32 val) +{ + nfc_write(mtd, reg, (nfc_read(mtd, reg) & (~mask)) | val << shift); +} + +/* Clear flags for upcoming command */ +static void nfc_clear_status(struct mtd_info *mtd) +{ + nfc_set(mtd, NFC_IRQ_STATUS, CMD_DONE_CLEAR_BIT); + nfc_set(mtd, NFC_IRQ_STATUS, IDLE_CLEAR_BIT); +} + +/* Wait for complete operation */ +static void nfc_done(struct mtd_info *mtd) +{ + uint start; + + nfc_set(mtd, NFC_FLASH_CMD2, START_BIT); + barrier(); + + start = get_timer(0); + + while (!(nfc_read(mtd, NFC_IRQ_STATUS) & IDLE_IRQ_BIT)) { + if (get_timer(start) > NFC_TIMEOUT) + printf("Timeout while waiting for BUSY.\n"); + } + nfc_clear_status(mtd); +} + +static u8 nfc_get_id(struct mtd_info *mtd, int col) +{ + u32 flash_id; + + if (col < 4) { + flash_id = nfc_read(mtd, NFC_FLASH_STATUS1); + return (flash_id >> (3-col)*8) & 0xff; + } else { + flash_id = nfc_read(mtd, NFC_FLASH_STATUS2); + return flash_id >> 24; + } +} + +static u8 nfc_get_status(struct mtd_info *mtd) +{ + return nfc_read(mtd, NFC_FLASH_STATUS2) & STATUS_BYTE1_MASK; +} + +/* Single command */ +static void nfc_send_command(struct mtd_info *mtd, u32 cmd_byte1, + u32 cmd_code) +{ + nfc_clear_status(mtd); + + nfc_set_field(mtd, NFC_FLASH_CMD2, CMD_BYTE1_MASK, + CMD_BYTE1_SHIFT, cmd_byte1); + + nfc_clear(mtd, NFC_FLASH_CMD2, BUFNO_MASK); + + nfc_set_field(mtd, NFC_FLASH_CMD2, CMD_CODE_MASK, + CMD_CODE_SHIFT, cmd_code); +} + +/* Two commands */ +static void nfc_send_commands(struct mtd_info *mtd, u32 cmd_byte1, + u32 cmd_byte2, u32 cmd_code) +{ + nfc_send_command(mtd, cmd_byte1, cmd_code); + + nfc_set_field(mtd, NFC_FLASH_CMD1, CMD_BYTE2_MASK, + CMD_BYTE2_SHIFT, cmd_byte2); +} + +static void nfc_addr_cycle(struct mtd_info *mtd, int column, int page) +{ + if (column != -1) { + struct fsl_nfc *nfc = mtd_to_nfc(mtd); + if (nfc->chip.options | NAND_BUSWIDTH_16) + column = column/2; + nfc_set_field(mtd, NFC_COL_ADDR, COL_ADDR_MASK, + COL_ADDR_SHIFT, column); + } + if (page != -1) + nfc_set_field(mtd, NFC_ROW_ADDR, ROW_ADDR_MASK, + ROW_ADDR_SHIFT, page); +} + +/* Send command to NAND chip */ +static void nfc_command(struct mtd_info *mtd, unsigned command, + int column, int page) +{ + struct fsl_nfc *nfc = mtd_to_nfc(mtd); + + nfc->column = max(column, 0); + nfc->spareonly = 0; + nfc->alt_buf = 0; + + switch (command) { + case NAND_CMD_PAGEPROG: + nfc->page = -1; + nfc_send_commands(mtd, NAND_CMD_SEQIN, + command, PROGRAM_PAGE_CMD_CODE); + nfc_addr_cycle(mtd, column, page); + break; + + case NAND_CMD_RESET: + nfc_send_command(mtd, command, RESET_CMD_CODE); + break; + /* + * NFC does not support sub-page reads and writes, + * so emulate them using full page transfers. + */ + case NAND_CMD_READOOB: + nfc->spareonly = 1; + case NAND_CMD_SEQIN: /* Pre-read for partial writes. */ + case NAND_CMD_READ0: + column = 0; + /* Already read? */ + if (nfc->page == page) + return; + nfc->page = page; + nfc_send_commands(mtd, NAND_CMD_READ0, + NAND_CMD_READSTART, READ_PAGE_CMD_CODE); + nfc_addr_cycle(mtd, column, page); + break; + + case NAND_CMD_ERASE1: + if (nfc->page == page) + nfc->page = -1; + nfc_send_commands(mtd, command, + NAND_CMD_ERASE2, ERASE_CMD_CODE); + nfc_addr_cycle(mtd, column, page); + break; + + case NAND_CMD_READID: + nfc->alt_buf = ALT_BUF_ID; + nfc_send_command(mtd, command, READ_ID_CMD_CODE); + break; + + case NAND_CMD_STATUS: + nfc->alt_buf = ALT_BUF_STAT; + nfc_send_command(mtd, command, STATUS_READ_CMD_CODE); + break; + default: + return; + } + + nfc_done(mtd); +} + +static void nfc_read_spare(struct mtd_info *mtd, void *buf, int len) +{ + struct fsl_nfc *nfc = mtd_to_nfc(mtd); + + len = min(mtd->oobsize, (uint)len); + if (len > 0) + memcpy(buf, nfc->regs + mtd->writesize, len); +} + +/* Read data from NFC buffers */ +static void nfc_read_buf(struct mtd_info *mtd, u_char *buf, int len) +{ + struct fsl_nfc *nfc = mtd_to_nfc(mtd); + uint c = nfc->column; + uint l; + + /* Handle main area */ + if (!nfc->spareonly) { + + l = min((uint)len, mtd->writesize - c); + nfc->column += l; + + if (!nfc->alt_buf) + memcpy(buf, nfc->regs + NFC_MAIN_AREA(0) + c, l); + else + if (nfc->alt_buf & ALT_BUF_ID) + *buf = nfc_get_id(mtd, c); + else + *buf = nfc_get_status(mtd); + buf += l; + len -= l; + } + + /* Handle spare area access */ + if (len) { + nfc->column += len; + nfc_read_spare(mtd, buf, len); + } +} + +/* Write data to NFC buffers */ +static void nfc_write_buf(struct mtd_info *mtd, const u_char *buf, int len) +{ + struct fsl_nfc *nfc = mtd_to_nfc(mtd); + uint c = nfc->column; + uint l; + + l = min((uint)len, mtd->writesize + mtd->oobsize - c); + nfc->column += l; + memcpy(nfc->regs + NFC_MAIN_AREA(0) + c, buf, l); +} + +/* Read byte from NFC buffers */ +static u8 nfc_read_byte(struct mtd_info *mtd) +{ + u8 tmp; + nfc_read_buf(mtd, &tmp, sizeof(tmp)); + return tmp; +} + +/* Read word from NFC buffers */ +static u16 nfc_read_word(struct mtd_info *mtd) +{ + u16 tmp; + nfc_read_buf(mtd, (u_char *)&tmp, sizeof(tmp)); + return tmp; +} + +/* If not provided, upper layers apply a fixed delay. */ +static int nfc_dev_ready(struct mtd_info *mtd) +{ + /* NFC handles R/B internally; always ready. */ + return 1; +} + +/* + * Vybrid only. MPC5125 has full RB and four CS. Assume boot loader + * has set this register for now. + */ +static void +nfc_select_chip(struct mtd_info *mtd, int chip) +{ +#ifdef CONFIG_VF610 + nfc_set_field(mtd, NFC_ROW_ADDR, ROW_ADDR_CHIP_SEL_RB_MASK, + ROW_ADDR_CHIP_SEL_RB_SHIFT, 1); + + if (chip == 0) + nfc_set_field(mtd, NFC_ROW_ADDR, ROW_ADDR_CHIP_SEL_MASK, + ROW_ADDR_CHIP_SEL_SHIFT, 1); + else if (chip == 1) + nfc_set_field(mtd, NFC_ROW_ADDR, ROW_ADDR_CHIP_SEL_MASK, + ROW_ADDR_CHIP_SEL_SHIFT, 2); + else + nfc_clear(mtd, NFC_ROW_ADDR, ROW_ADDR_CHIP_SEL_MASK); +#endif +} + +/* Count the number of 0's in buff upto max_bits */ +static int count_written_bits(uint8_t *buff, int size, int max_bits) +{ + int k, written_bits = 0; + + for (k = 0; k < size; k++) { + written_bits += hweight8(~buff[k]); + if (written_bits > max_bits) + break; + } + + return written_bits; +} + +static int nfc_correct_data(struct mtd_info *mtd, u_char *dat, + u_char *read_ecc, u_char *calc_ecc) +{ + struct fsl_nfc *nfc = mtd_to_nfc(mtd); + u32 ecc_status; + u8 ecc_count; + int flip; + + /* + * Errata: ECC status is stored at NFC_CFG[ECCADD] +4 for + * little-endian and +7 for big-endian SOC. Access as 32 bits + * and use low byte. + */ + ecc_status = __raw_readl(nfc->regs + ECC_SRAM_ADDR * 8 + 4); + ecc_count = ecc_status & ECC_ERR_COUNT; + if (!(ecc_status & ECC_STATUS_MASK)) + return ecc_count; + + /* If 'ecc_count' zero or less then buffer is all 0xff or erased. */ + flip = count_written_bits(dat, nfc->chip.ecc.size, ecc_count); + + /* ECC failed. */ + if (flip > ecc_count) + return -1; + + /* Erased page. */ + memset(dat, 0xff, nfc->chip.ecc.size); + return 0; +} + +static int nfc_calculate_ecc(struct mtd_info *mtd, const u_char *dat, + u_char *ecc_code) +{ + return 0; +} + +static void nfc_enable_hwecc(struct mtd_info *mtd, int mode) +{ +} + +struct nfc_config { + int hardware_ecc; + int width; + int flash_bbt; +}; + +//static int nfc_probe(struct platform_device *pdev) +int board_nand_init(struct nand_chip *chip) +{ + struct fsl_nfc *nfc; + struct mtd_info *mtd; + uint chips_no = 0; + int err = 0; + int page_sz; + struct nfc_config cfg = { + .hardware_ecc = 1, +#ifdef CONFIG_SYS_NAND_BUSWIDTH_16BIT + .width = 16, +#else + .width = 8, +#endif + .flash_bbt = 1, + }; + + if (chip->IO_ADDR_R == NULL) + return -1; + + nfc = malloc(sizeof(*nfc)); + if (!nfc) { + printf(KERN_ERR DRV_NAME ": Memory exhausted!\n"); + return -ENOMEM; + } + + nfc->regs = (void __iomem *)chip->IO_ADDR_R; //CONFIG_SYS_NAND_BASE; + + mtd = &nand_info[chips_no++]; + mtd->priv = chip; + chip->priv = nfc; + + if (cfg.width == 16) { + chip->options |= NAND_BUSWIDTH_16; + nfc_set(mtd, NFC_FLASH_CONFIG, CONFIG_16BIT); + } else { + chip->options &= ~NAND_BUSWIDTH_16; + nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_16BIT); + } + + chip->dev_ready = nfc_dev_ready; + chip->cmdfunc = nfc_command; + chip->read_byte = nfc_read_byte; + chip->read_word = nfc_read_word; + chip->read_buf = nfc_read_buf; + chip->write_buf = nfc_write_buf; + chip->select_chip = nfc_select_chip; + + /* Bad block options. */ + if (cfg.flash_bbt) + chip->bbt_options = NAND_BBT_USE_FLASH | NAND_BBT_CREATE; + + /* Default to software ECC until flash ID. */ + nfc_set_field(mtd, NFC_FLASH_CONFIG, + CONFIG_ECC_MODE_MASK, + CONFIG_ECC_MODE_SHIFT, ECC_BYPASS); + + chip->bbt_td = &bbt_main_descr; + chip->bbt_md = &bbt_mirror_descr; + + page_sz = PAGE_2K + OOB_64; + page_sz += cfg.width == 16 ? 1 : 0; + nfc_write(mtd, NFC_SECTOR_SIZE, page_sz); + + /* Set configuration register. */ + nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_ADDR_AUTO_INCR_BIT); + nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_BUFNO_AUTO_INCR_BIT); + nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_BOOT_MODE_BIT); + nfc_clear(mtd, NFC_FLASH_CONFIG, CONFIG_DMA_REQ_BIT); + nfc_set(mtd, NFC_FLASH_CONFIG, CONFIG_FAST_FLASH_BIT); + + /* Enable Idle IRQ */ + nfc_set(mtd, NFC_IRQ_STATUS, IDLE_EN_BIT); + + /* PAGE_CNT = 1 */ + nfc_set_field(mtd, NFC_FLASH_CONFIG, CONFIG_PAGE_CNT_MASK, + CONFIG_PAGE_CNT_SHIFT, 1); + + /* Set ECC_STATUS offset */ + nfc_set_field(mtd, NFC_FLASH_CONFIG, + CONFIG_ECC_SRAM_ADDR_MASK, + CONFIG_ECC_SRAM_ADDR_SHIFT, ECC_SRAM_ADDR); + + /* first scan to find the device and get the page size */ + if (nand_scan_ident(mtd, CONFIG_SYS_MAX_NAND_DEVICE, NULL)) { + err = -ENXIO; + goto error; + } + + chip->ecc.mode = NAND_ECC_SOFT; /* default */ + + page_sz = mtd->writesize + mtd->oobsize; + + /* Single buffer only, max 256 OOB minus ECC status */ + if (page_sz > PAGE_2K + 256 - 8) { + dev_err(nfc->dev, "Unsupported flash size\n"); + err = -ENXIO; + goto error; + } + page_sz += cfg.width == 16 ? 1 : 0; + nfc_write(mtd, NFC_SECTOR_SIZE, page_sz); + + if (cfg.hardware_ecc) { + if (mtd->writesize != PAGE_2K && mtd->oobsize < 64) { + dev_err(nfc->dev, "Unsupported flash with hwecc\n"); + err = -ENXIO; + goto error; + } + + chip->ecc.layout = &nfc_ecc45; + + /* propagate ecc.layout to mtd_info */ + mtd->ecclayout = chip->ecc.layout; + chip->ecc.calculate = nfc_calculate_ecc; + chip->ecc.hwctl = nfc_enable_hwecc; + chip->ecc.correct = nfc_correct_data; + chip->ecc.mode = NAND_ECC_HW; + + chip->ecc.bytes = 45; + chip->ecc.size = PAGE_2K; + chip->ecc.strength = 24; + + /* set ECC mode to 45 bytes OOB with 24 bits correction */ + nfc_set_field(mtd, NFC_FLASH_CONFIG, + CONFIG_ECC_MODE_MASK, + CONFIG_ECC_MODE_SHIFT, ECC_45_BYTE); + + /* Enable ECC_STATUS */ + nfc_set(mtd, NFC_FLASH_CONFIG, CONFIG_ECC_SRAM_REQ_BIT); + + } + + /* second phase scan */ + if (nand_scan_tail(mtd)) { + err = -ENXIO; + goto error; + } + + return 0; + +error: + return err; +}
This adds initial support for Freescale NFC (NAND Flash Controller). The IP is used in ARM based Vybrid SoCs as well as on some PowerPC devices. This driver is only tested on Vybrid. Signed-off-by: Stefan Agner <stefan@agner.ch> --- drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/fsl_nfc.c | 676 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 677 insertions(+) create mode 100644 drivers/mtd/nand/fsl_nfc.c