Message ID | 1446713231-1559-2-git-send-email-thomas@wytron.com.tw |
---|---|
State | Accepted, archived |
Delegated to: | Thomas Chou |
Headers | show |
On 5 November 2015 at 14:17, Thomas Chou <thomas@wytron.com.tw> wrote: > Add Altera Generic Quad SPI Controller support. The controller > converts SPI NOR flash to parallel flash interface. So it is > not like other SPI flash, but rather like CFI flash. Can you wait till spi-nor ready? it doesn't make sense to have Serial NOR to created as parallel NOR. > > Signed-off-by: Thomas Chou <thomas@wytron.com.tw> > --- > v2 > use memcpy_toio() for mtd_write() as suggested by Chin Liang > and Marek. > > doc/device-tree-bindings/mtd/altera_qspi.txt | 35 ++++ > drivers/mtd/Kconfig | 9 + > drivers/mtd/Makefile | 1 + > drivers/mtd/altera_qspi.c | 276 +++++++++++++++++++++++++++ > 4 files changed, 321 insertions(+) > create mode 100644 doc/device-tree-bindings/mtd/altera_qspi.txt > create mode 100644 drivers/mtd/altera_qspi.c > > diff --git a/doc/device-tree-bindings/mtd/altera_qspi.txt b/doc/device-tree-bindings/mtd/altera_qspi.txt > new file mode 100644 > index 0000000..3361ac9 > --- /dev/null > +++ b/doc/device-tree-bindings/mtd/altera_qspi.txt > @@ -0,0 +1,35 @@ > +Altera QUADSPI driver > + > +Required properties: > +- compatible: Should be "altr,quadspi-1.0" > +- reg: Address and length of the register set for the device. It contains > + the information of registers in the same order as described by reg-names > +- reg-names: Should contain the reg names > + "avl_csr": Should contain the register configuration base address > + "avl_mem": Should contain the data base address > +- #address-cells: Must be <1>. > +- #size-cells: Must be <0>. > +- flash device tree subnode, there must be a node with the following fields: > + - compatible: Should contain the flash name: > + 1. EPCS: epcs16, epcs64, epcs128 > + 2. EPCQ: epcq16, epcq32, epcq64, epcq128, epcq256, epcq512, epcq1024 > + 3. EPCQ-L: epcql256, epcql512, epcql1024 > + - #address-cells: please refer to /mtd/partition.txt > + - #size-cells: please refer to /mtd/partition.txt > + For partitions inside each flash, please refer to /mtd/partition.txt > + > +Example: > + > + quadspi_controller_0: quadspi@0x180014a0 { > + compatible = "altr,quadspi-1.0"; > + reg = <0x180014a0 0x00000020>, > + <0x14000000 0x04000000>; > + reg-names = "avl_csr", "avl_mem"; > + #address-cells = <1>; > + #size-cells = <0>; > + flash0: epcq512@0 { > + compatible = "altr,epcq512"; > + #address-cells = <1>; > + #size-cells = <1>; > + }; > + }; > diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig > index 367c4fe..c16b1d0 100644 > --- a/drivers/mtd/Kconfig > +++ b/drivers/mtd/Kconfig > @@ -19,6 +19,15 @@ config CFI_FLASH > option. Visit <http://www.amd.com/products/nvd/overview/cfi.html> > for more information on CFI. > > +config ALTERA_QSPI > + bool "Altera Generic Quad SPI Controller" > + depends on MTD > + help > + This enables access to Altera EPCQ/EPCS flash chips using the > + Altera Generic Quad SPI Controller. The controller converts SPI > + NOR flash to parallel flash interface. Please find details on the > + "Embedded Peripherals IP User Guide" of Altera. > + > endmenu > > source "drivers/mtd/nand/Kconfig" > diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile > index c23c0c1..7f018a4 100644 > --- a/drivers/mtd/Makefile > +++ b/drivers/mtd/Makefile > @@ -11,6 +11,7 @@ endif > obj-$(CONFIG_MTD) += mtd-uclass.o > obj-$(CONFIG_MTD_PARTITIONS) += mtdpart.o > obj-$(CONFIG_MTD_CONCAT) += mtdconcat.o > +obj-$(CONFIG_ALTERA_QSPI) += altera_qspi.o > obj-$(CONFIG_HAS_DATAFLASH) += at45.o > obj-$(CONFIG_FLASH_CFI_DRIVER) += cfi_flash.o > obj-$(CONFIG_FLASH_CFI_MTD) += cfi_mtd.o > diff --git a/drivers/mtd/altera_qspi.c b/drivers/mtd/altera_qspi.c > new file mode 100644 > index 0000000..c32b1d3 > --- /dev/null > +++ b/drivers/mtd/altera_qspi.c > @@ -0,0 +1,276 @@ > +/* > + * Copyright (C) 2015 Thomas Chou <thomas@wytron.com.tw> > + * > + * SPDX-License-Identifier: GPL-2.0+ > + */ > + > +#include <common.h> > +#include <dm.h> > +#include <errno.h> > +#include <fdt_support.h> > +#include <flash.h> > +#include <mtd.h> > +#include <asm/io.h> > + > +DECLARE_GLOBAL_DATA_PTR; > + > +/* > + * The QUADSPI_MEM_OP register is used to do memory protect and erase operations > + */ > +#define QUADSPI_MEM_OP_BULK_ERASE 0x00000001 > +#define QUADSPI_MEM_OP_SECTOR_ERASE 0x00000002 > +#define QUADSPI_MEM_OP_SECTOR_PROTECT 0x00000003 > + > +/* > + * The QUADSPI_ISR register is used to determine whether an invalid write or > + * erase operation trigerred an interrupt > + */ > +#define QUADSPI_ISR_ILLEGAL_ERASE BIT(0) > +#define QUADSPI_ISR_ILLEGAL_WRITE BIT(1) > + > +struct altera_qspi_regs { > + u32 rd_status; > + u32 rd_sid; > + u32 rd_rdid; > + u32 mem_op; > + u32 isr; > + u32 imr; > + u32 chip_select; > +}; > + > +struct altera_qspi_platdata { > + struct altera_qspi_regs *regs; > + void *base; > + unsigned long size; > +}; > + > +flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS]; /* FLASH chips info */ > + > +void flash_print_info(flash_info_t *info) > +{ > + printf("Altera QSPI flash Size: %ld MB in %d Sectors\n", > + info->size >> 20, info->sector_count); > +} > + > +int flash_erase(flash_info_t *info, int s_first, int s_last) > +{ > + struct mtd_info *mtd = info->mtd; > + struct erase_info instr; > + int ret; > + > + memset(&instr, 0, sizeof(instr)); > + instr.addr = mtd->erasesize * s_first; > + instr.len = mtd->erasesize * (s_last + 1 - s_first); > + ret = mtd_erase(mtd, &instr); > + if (ret) > + return ERR_NOT_ERASED; > + > + return 0; > +} > + > +int write_buff(flash_info_t *info, uchar *src, ulong addr, ulong cnt) > +{ > + struct mtd_info *mtd = info->mtd; > + struct udevice *dev = mtd->dev; > + struct altera_qspi_platdata *pdata = dev_get_platdata(dev); > + ulong base = (ulong)pdata->base; > + loff_t to = addr - base; > + size_t retlen; > + int ret; > + > + ret = mtd_write(mtd, to, cnt, &retlen, src); > + if (ret) > + return ERR_NOT_ERASED; > + > + return 0; > +} > + > +unsigned long flash_init(void) > +{ > + struct udevice *dev; > + > + /* probe every MTD device */ > + for (uclass_first_device(UCLASS_MTD, &dev); > + dev; > + uclass_next_device(&dev)) { > + } > + > + return flash_info[0].size; > +} > + > +static int altera_qspi_erase(struct mtd_info *mtd, struct erase_info *instr) > +{ > + struct udevice *dev = mtd->dev; > + struct altera_qspi_platdata *pdata = dev_get_platdata(dev); > + struct altera_qspi_regs *regs = pdata->regs; > + size_t addr = instr->addr; > + size_t len = instr->len; > + size_t end = addr + len; > + u32 sect; > + u32 stat; > + > + instr->state = MTD_ERASING; > + addr &= ~(mtd->erasesize - 1); /* get lower aligned address */ > + while (addr < end) { > + sect = addr / mtd->erasesize; > + sect <<= 8; > + sect |= QUADSPI_MEM_OP_SECTOR_ERASE; > + debug("erase %08x\n", sect); > + writel(sect, ®s->mem_op); > + stat = readl(®s->isr); > + if (stat & QUADSPI_ISR_ILLEGAL_ERASE) { > + /* erase failed, sector might be protected */ > + debug("erase %08x fail %x\n", sect, stat); > + writel(stat, ®s->isr); /* clear isr */ > + instr->state = MTD_ERASE_FAILED; > + return -EIO; > + } > + addr += mtd->erasesize; > + } > + instr->state = MTD_ERASE_DONE; > + mtd_erase_callback(instr); > + > + return 0; > +} > + > +static int altera_qspi_read(struct mtd_info *mtd, loff_t from, size_t len, > + size_t *retlen, u_char *buf) > +{ > + struct udevice *dev = mtd->dev; > + struct altera_qspi_platdata *pdata = dev_get_platdata(dev); > + > + memcpy_fromio(buf, pdata->base + from, len); > + *retlen = len; > + > + return 0; > +} > + > +static int altera_qspi_write(struct mtd_info *mtd, loff_t to, size_t len, > + size_t *retlen, const u_char *buf) > +{ > + struct udevice *dev = mtd->dev; > + struct altera_qspi_platdata *pdata = dev_get_platdata(dev); > + struct altera_qspi_regs *regs = pdata->regs; > + u32 stat; > + > + memcpy_toio(pdata->base + to, buf, len); > + /* check whether write triggered a illegal write interrupt */ > + stat = readl(®s->isr); > + if (stat & QUADSPI_ISR_ILLEGAL_WRITE) { > + /* write failed, sector might be protected */ > + debug("write fail %x\n", stat); > + writel(stat, ®s->isr); /* clear isr */ > + return -EIO; > + } > + *retlen = len; > + > + return 0; > +} > + > +static void altera_qspi_sync(struct mtd_info *mtd) > +{ > +} > + > +static int altera_qspi_probe(struct udevice *dev) > +{ > + struct altera_qspi_platdata *pdata = dev_get_platdata(dev); > + struct altera_qspi_regs *regs = pdata->regs; > + unsigned long base = (unsigned long)pdata->base; > + struct mtd_info *mtd; > + flash_info_t *flash = &flash_info[0]; > + u32 rdid; > + int i; > + > + rdid = readl(®s->rd_rdid); > + debug("rdid %x\n", rdid); > + > + mtd = calloc(1, sizeof(struct mtd_info)); > + if (!mtd) > + return -ENOMEM; > + dev->uclass_priv = mtd; > + mtd->dev = dev; > + mtd->name = "nor0"; > + mtd->type = MTD_NORFLASH; > + mtd->flags = MTD_CAP_NORFLASH; > + mtd->size = 1 << ((rdid & 0xff) - 6); > + mtd->writesize = 1; > + mtd->writebufsize = mtd->writesize; > + mtd->_erase = altera_qspi_erase; > + mtd->_read = altera_qspi_read; > + mtd->_write = altera_qspi_write; > + mtd->_sync = altera_qspi_sync; > + mtd->numeraseregions = 0; > + mtd->erasesize = 0x10000; > + if (add_mtd_device(mtd)) > + return -ENOMEM; > + > + flash->mtd = mtd; > + flash->size = mtd->size; > + flash->sector_count = mtd->size / mtd->erasesize; > + flash->flash_id = rdid; > + flash->start[0] = base; > + for (i = 1; i < flash->sector_count; i++) > + flash->start[i] = flash->start[i - 1] + mtd->erasesize; > + gd->bd->bi_flashstart = base; > + > + return 0; > +} > + > +static int altera_qspi_ofdata_to_platdata(struct udevice *dev) > +{ > + struct altera_qspi_platdata *pdata = dev_get_platdata(dev); > + void *blob = (void *)gd->fdt_blob; > + int node = dev->of_offset; > + const char *list, *end; > + const fdt32_t *cell; > + void *base; > + unsigned long addr, size; > + int parent, addrc, sizec; > + int len, idx; > + > + /* > + * decode regs. there are multiple reg tuples, and they need to > + * match with reg-names. > + */ > + parent = fdt_parent_offset(blob, node); > + of_bus_default_count_cells(blob, parent, &addrc, &sizec); > + list = fdt_getprop(blob, node, "reg-names", &len); > + if (!list) > + return -ENOENT; > + end = list + len; > + cell = fdt_getprop(blob, node, "reg", &len); > + if (!cell) > + return -ENOENT; > + idx = 0; > + while (list < end) { > + addr = fdt_translate_address((void *)blob, > + node, cell + idx); > + size = fdt_addr_to_cpu(cell[idx + addrc]); > + base = ioremap(addr, size); > + len = strlen(list); > + if (strcmp(list, "avl_csr") == 0) { > + pdata->regs = base; > + } else if (strcmp(list, "avl_mem") == 0) { > + pdata->base = base; > + pdata->size = size; > + } > + idx += addrc + sizec; > + list += (len + 1); > + } > + > + return 0; > +} > + > +static const struct udevice_id altera_qspi_ids[] = { > + { .compatible = "altr,quadspi-1.0" }, > + {} > +}; > + > +U_BOOT_DRIVER(altera_qspi) = { > + .name = "altera_qspi", > + .id = UCLASS_MTD, > + .of_match = altera_qspi_ids, > + .ofdata_to_platdata = altera_qspi_ofdata_to_platdata, > + .platdata_auto_alloc_size = sizeof(struct altera_qspi_platdata), > + .probe = altera_qspi_probe, > +}; > -- > 2.5.0 > > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot
Hi Jagan, On 2015年11月05日 22:25, Jagan Teki wrote: > On 5 November 2015 at 14:17, Thomas Chou <thomas@wytron.com.tw> wrote: >> Add Altera Generic Quad SPI Controller support. The controller >> converts SPI NOR flash to parallel flash interface. So it is >> not like other SPI flash, but rather like CFI flash. > > Can you wait till spi-nor ready? it doesn't make sense to have Serial > NOR to created as parallel NOR. The altera quad spi core is very special that the hardware handle the spi-nor protocol. The core is designed to replace the CFI flash interface. So there is nothing to do with SPI from the parallel flash interface. It is memory mapped. There is no SPI interface. There is nothing related to SPI programming. So please don't worry about the progress on spi-nor. The core should belong to parallel flash, but not serial flash. Best regards, Thomas
Hi Thomas, On 5 November 2015 at 20:15, Thomas Chou <thomas@wytron.com.tw> wrote: > Hi Jagan, > > On 2015年11月05日 22:25, Jagan Teki wrote: >> >> On 5 November 2015 at 14:17, Thomas Chou <thomas@wytron.com.tw> wrote: >>> >>> Add Altera Generic Quad SPI Controller support. The controller >>> converts SPI NOR flash to parallel flash interface. So it is >>> not like other SPI flash, but rather like CFI flash. >> >> >> Can you wait till spi-nor ready? it doesn't make sense to have Serial >> NOR to created as parallel NOR. > > > The altera quad spi core is very special that the hardware handle the > spi-nor protocol. The core is designed to replace the CFI flash interface. > So there is nothing to do with SPI from the parallel flash interface. It is > memory mapped. There is no SPI interface. There is nothing related to SPI > programming. So please don't worry about the progress on spi-nor. The core > should belong to parallel flash, but not serial flash. Agreed that this is not doing any generic spi things, but it's a spi-nor controller all spi-nor controller should be part of spi-nor subsystem Linux agreed and have a framework for that. drivers/mtd/spi-nor/fsl-quadspi.c drivers/mtd/spi-nor/nxp-spifi.c all these are spi-nor controller which doesn't do any generic spi things but should be in spi-nor subsystem. Even Marek send altera_qspi as spi-nor controller [1] Since I'm working on similar spi-nor subsystem what Linux have + driver model little worried about this because once we have spi-nor again it should be a re-work. [1] http://lists.infradead.org/pipermail/linux-mtd/2015-April/058650.html
On Thursday, November 05, 2015 at 03:57:01 PM, Jagan Teki wrote: > Hi Thomas, > > On 5 November 2015 at 20:15, Thomas Chou <thomas@wytron.com.tw> wrote: > > Hi Jagan, > > > > On 2015年11月05日 22:25, Jagan Teki wrote: > >> On 5 November 2015 at 14:17, Thomas Chou <thomas@wytron.com.tw> wrote: > >>> Add Altera Generic Quad SPI Controller support. The controller > >>> converts SPI NOR flash to parallel flash interface. So it is > >>> not like other SPI flash, but rather like CFI flash. > >> > >> Can you wait till spi-nor ready? it doesn't make sense to have Serial > >> NOR to created as parallel NOR. > > > > The altera quad spi core is very special that the hardware handle the > > spi-nor protocol. The core is designed to replace the CFI flash > > interface. So there is nothing to do with SPI from the parallel flash > > interface. It is memory mapped. There is no SPI interface. There is > > nothing related to SPI programming. So please don't worry about the > > progress on spi-nor. The core should belong to parallel flash, but not > > serial flash. > > Agreed that this is not doing any generic spi things, but it's a > spi-nor controller all spi-nor controller should be part of spi-nor > subsystem Linux agreed and have a framework for that. The underlying technology is not exposed to the programmer, so this argument is moot. The behavior of this device is closer to CFI flash. > drivers/mtd/spi-nor/fsl-quadspi.c > drivers/mtd/spi-nor/nxp-spifi.c > > all these are spi-nor controller which doesn't do any generic spi > things but should be in spi-nor subsystem. Even Marek send altera_qspi > as spi-nor controller [1] This is because that thing communicates like a SPI controller. > Since I'm working on similar spi-nor subsystem what Linux have + > driver model little worried about this because once we have spi-nor > again it should be a re-work. Your work and this driver are orthogonal things. > [1] http://lists.infradead.org/pipermail/linux-mtd/2015-April/058650.html Best regards, Marek Vasut
Hi Jagan, On 2015年11月05日 22:57, Jagan Teki wrote: > The altera quad spi core is very special that the hardware handle the >> spi-nor protocol. The core is designed to replace the CFI flash interface. >> So there is nothing to do with SPI from the parallel flash interface. It is >> memory mapped. There is no SPI interface. There is nothing related to SPI >> programming. So please don't worry about the progress on spi-nor. The core >> should belong to parallel flash, but not serial flash. > > Agreed that this is not doing any generic spi things, but it's a > spi-nor controller all spi-nor controller should be part of spi-nor > subsystem Linux agreed and have a framework for that. > > drivers/mtd/spi-nor/fsl-quadspi.c > drivers/mtd/spi-nor/nxp-spifi.c > > all these are spi-nor controller which doesn't do any generic spi > things but should be in spi-nor subsystem. Even Marek send altera_qspi > as spi-nor controller [1] > > Since I'm working on similar spi-nor subsystem what Linux have + > driver model little worried about this because once we have spi-nor > again it should be a re-work. > > [1] http://lists.infradead.org/pipermail/linux-mtd/2015-April/058650.html I had been a hardware engineer. I designed chips and boards. I believe this should depend on the programming interface. Eg, there are SSDs of SATA interfaces which build with NAND or EMMC, and it dose not make sense to classify them as NAND or MMC. The altera quadspi core is a similar case, because the hardware converts the programming interface. There is no way to send spi-nor commands that the spi frame work does. It is ridiculous to insist it to use under the spi-nor framework. The altera quadspi hides details about the underlying spi-nor. We may even choose to build interface that convert EMMC to like cfi flash. The users can run code directly on the flash or use memory command like "cp.b" of u-boot to program the flash. This can be a advantage over the "sf" command. Best regards, Thomas
Hi Thomas, On 6 November 2015 at 05:48, Thomas Chou <thomas@wytron.com.tw> wrote: > Hi Jagan, > > On 2015年11月05日 22:57, Jagan Teki wrote: >> >> The altera quad spi core is very special that the hardware handle the >>> >>> spi-nor protocol. The core is designed to replace the CFI flash >>> interface. >>> So there is nothing to do with SPI from the parallel flash interface. It >>> is >>> memory mapped. There is no SPI interface. There is nothing related to SPI >>> programming. So please don't worry about the progress on spi-nor. The >>> core >>> should belong to parallel flash, but not serial flash. >> >> >> Agreed that this is not doing any generic spi things, but it's a >> spi-nor controller all spi-nor controller should be part of spi-nor >> subsystem Linux agreed and have a framework for that. >> >> drivers/mtd/spi-nor/fsl-quadspi.c >> drivers/mtd/spi-nor/nxp-spifi.c >> >> all these are spi-nor controller which doesn't do any generic spi >> things but should be in spi-nor subsystem. Even Marek send altera_qspi >> as spi-nor controller [1] >> >> Since I'm working on similar spi-nor subsystem what Linux have + >> driver model little worried about this because once we have spi-nor >> again it should be a re-work. >> >> [1] http://lists.infradead.org/pipermail/linux-mtd/2015-April/058650.html > > > I had been a hardware engineer. I designed chips and boards. I believe this > should depend on the programming interface. Eg, there are SSDs of SATA > interfaces which build with NAND or EMMC, and it dose not make sense to > classify them as NAND or MMC. The altera quadspi core is a similar case, > because the hardware converts the programming interface. There is no way to > send spi-nor commands that the spi frame work does. It is ridiculous to > insist it to use under the spi-nor framework. I appreciate your hardware expertise and am not questioning about that as well. I do agree with the hw logic about altera qspi controller and I don't have any questions with hw either. But my main intention here was about the software support since Linux discussed about this subject and finally moved to spi-nor controllers (though they don't use spi bus at-all) to spi-nor framework and Marek knows this topic very well. I believe discussion about this topic much more clear if we send this driver to Linux. > > The altera quadspi hides details about the underlying spi-nor. We may even > choose to build interface that convert EMMC to like cfi flash. The users can > run code directly on the flash or use memory command like "cp.b" of u-boot > to program the flash. This can be a advantage over the "sf" command. thanks!
Hi Marek, On 5 November 2015 at 21:21, Marek Vasut <marex@denx.de> wrote: > On Thursday, November 05, 2015 at 03:57:01 PM, Jagan Teki wrote: >> Hi Thomas, >> >> On 5 November 2015 at 20:15, Thomas Chou <thomas@wytron.com.tw> wrote: >> > Hi Jagan, >> > >> > On 2015年11月05日 22:25, Jagan Teki wrote: >> >> On 5 November 2015 at 14:17, Thomas Chou <thomas@wytron.com.tw> wrote: >> >>> Add Altera Generic Quad SPI Controller support. The controller >> >>> converts SPI NOR flash to parallel flash interface. So it is >> >>> not like other SPI flash, but rather like CFI flash. >> >> >> >> Can you wait till spi-nor ready? it doesn't make sense to have Serial >> >> NOR to created as parallel NOR. >> > >> > The altera quad spi core is very special that the hardware handle the >> > spi-nor protocol. The core is designed to replace the CFI flash >> > interface. So there is nothing to do with SPI from the parallel flash >> > interface. It is memory mapped. There is no SPI interface. There is >> > nothing related to SPI programming. So please don't worry about the >> > progress on spi-nor. The core should belong to parallel flash, but not >> > serial flash. >> >> Agreed that this is not doing any generic spi things, but it's a >> spi-nor controller all spi-nor controller should be part of spi-nor >> subsystem Linux agreed and have a framework for that. > > The underlying technology is not exposed to the programmer, so this argument > is moot. The behavior of this device is closer to CFI flash. > >> drivers/mtd/spi-nor/fsl-quadspi.c >> drivers/mtd/spi-nor/nxp-spifi.c >> >> all these are spi-nor controller which doesn't do any generic spi >> things but should be in spi-nor subsystem. Even Marek send altera_qspi >> as spi-nor controller [1] > > This is because that thing communicates like a SPI controller. OK, the driver you sent to Linux is not same as this - means not same controller? > >> Since I'm working on similar spi-nor subsystem what Linux have + >> driver model little worried about this because once we have spi-nor >> again it should be a re-work. > > Your work and this driver are orthogonal things. OK, let's park my work a side - do you agree with me like this driver should be part of spi-nor? > >> [1] http://lists.infradead.org/pipermail/linux-mtd/2015-April/058650.html thanks!
Hi Jagan, On 2015年11月06日 16:07, Jagan Teki wrote: > I appreciate your hardware expertise and am not questioning about that > as well. I do agree with the hw logic about altera qspi controller and > I don't have any questions with hw either. > > But my main intention here was about the software support since Linux > discussed about this subject and finally moved to spi-nor controllers > (though they don't use spi bus at-all) to spi-nor framework and Marek > knows this topic very well. > > I believe discussion about this topic much more clear if we send this > driver to Linux. Sorry that I was absent and didn't know about the topic discussed on Linux. The purpose of u-boot and Linux is quite different thought they may share some code. The drivers are different, too. Whatever they chose on Linux is not related here. Marek did agree that "The behavior of this device is closer to CFI flash.". This is what the core designed for, to replace the CFI flash. I am more concerned with users. Users can use memory commands to display and modify the content directly. This is very point where the driver should stand. Thanks. Best regards, Thomas
Hi Thomas, On 6 November 2015 at 14:58, Thomas Chou <thomas@wytron.com.tw> wrote: > Hi Jagan, > > On 2015年11月06日 16:07, Jagan Teki wrote: >> >> I appreciate your hardware expertise and am not questioning about that >> as well. I do agree with the hw logic about altera qspi controller and >> I don't have any questions with hw either. >> >> But my main intention here was about the software support since Linux >> discussed about this subject and finally moved to spi-nor controllers >> (though they don't use spi bus at-all) to spi-nor framework and Marek >> knows this topic very well. >> >> I believe discussion about this topic much more clear if we send this >> driver to Linux. > > > Sorry that I was absent and didn't know about the topic discussed on Linux. > The purpose of u-boot and Linux is quite different thought they may share > some code. The drivers are different, too. Whatever they chose on Linux is > not related here. I'm trying to interface the same standard wrt Linux stack, So adding new features is reasonable and easy for developers to send the patches if we have same stand-point as what Linux or vice-versa. Yes drivers are bit different wrt Linux ie OK, anyway we need to implement with dm-driven but the functionality flow will be same like Linux --> u-boot mtd_utils --> cmd_sf mtd_info -->mtd_info spi-nor --> spi-nor m25p80.c --> spi-nor-flash (dm-driven) fsl-quadspi --> fsl-qspi (dm-driven) Finally, what is the main issue if we move to spi-nor instead of cfi? agreed that it never used generic spi but even if it there in spi-nor also it never used generic spi, spi-nor should also use mtd as cfi and also it's serial flash it should be part of spi-nor that make more sense to me. > > Marek did agree that "The behavior of this device is closer to CFI flash.". > This is what the core designed for, to replace the CFI flash. I am more > concerned with users. Users can use memory commands to display and modify > the content directly. This is very point where the driver should stand. Yes from uses point of view, it's a cfi flash but generally all cfi's are parallel in nature so it's shouldn't treated as serial. If we use sf user at least thought he would doing serial flash operations. thanks!
Hi Thomas, On 6 November 2015 at 15:22, Jagan Teki <jteki@openedev.com> wrote: > Hi Thomas, > > On 6 November 2015 at 14:58, Thomas Chou <thomas@wytron.com.tw> wrote: >> Hi Jagan, >> >> On 2015年11月06日 16:07, Jagan Teki wrote: >>> >>> I appreciate your hardware expertise and am not questioning about that >>> as well. I do agree with the hw logic about altera qspi controller and >>> I don't have any questions with hw either. >>> >>> But my main intention here was about the software support since Linux >>> discussed about this subject and finally moved to spi-nor controllers >>> (though they don't use spi bus at-all) to spi-nor framework and Marek >>> knows this topic very well. >>> >>> I believe discussion about this topic much more clear if we send this >>> driver to Linux. >> >> >> Sorry that I was absent and didn't know about the topic discussed on Linux. >> The purpose of u-boot and Linux is quite different thought they may share >> some code. The drivers are different, too. Whatever they chose on Linux is >> not related here. > > I'm trying to interface the same standard wrt Linux stack, So adding > new features is reasonable and easy for developers to send the patches > if we have same stand-point as what Linux or vice-versa. Yes drivers > are bit different wrt Linux ie OK, anyway we need to implement with > dm-driven but the functionality flow will be same like > > Linux --> u-boot > mtd_utils --> cmd_sf > mtd_info -->mtd_info > spi-nor --> spi-nor > m25p80.c --> spi-nor-flash (dm-driven) > fsl-quadspi --> fsl-qspi (dm-driven) > > Finally, what is the main issue if we move to spi-nor instead of cfi? > agreed that it never used generic spi but even if it there in spi-nor > also it never used generic spi, spi-nor should also use mtd as cfi and > also it's serial flash it should be part of spi-nor that make more > sense to me. > >> >> Marek did agree that "The behavior of this device is closer to CFI flash.". >> This is what the core designed for, to replace the CFI flash. I am more >> concerned with users. Users can use memory commands to display and modify >> the content directly. This is very point where the driver should stand. > > Yes from uses point of view, it's a cfi flash but generally all cfi's > are parallel in nature so it's shouldn't treated as serial. If we use > sf user at least thought he would doing serial flash operations. My intention is not to hold this, but once spi-nor is ready will you able to move it from here? thanks!
Hi Jagan, On 2015年11月06日 19:48, Jagan Teki wrote: > My intention is not to hold this, but once spi-nor is ready will you > able to move it from here? Sure, I will look at the new spi-nor interface then. And I will think again if it is good to move. Thanks a lot for your help. Best regards, Thomas
On Friday, November 06, 2015 at 09:11:20 AM, Jagan Teki wrote: [...] > >> all these are spi-nor controller which doesn't do any generic spi > >> things but should be in spi-nor subsystem. Even Marek send altera_qspi > >> as spi-nor controller [1] > > > > This is because that thing communicates like a SPI controller. > > OK, the driver you sent to Linux is not same as this - means not same > controller? This is correct, the controller we're discussing here is completely different from the Cadence QSPI I submitted for Linux kernel. > >> Since I'm working on similar spi-nor subsystem what Linux have + > >> driver model little worried about this because once we have spi-nor > >> again it should be a re-work. > > > > Your work and this driver are orthogonal things. > > OK, let's park my work a side - do you agree with me like this driver > should be part of spi-nor? No Best regards, Marek Vasut
diff --git a/doc/device-tree-bindings/mtd/altera_qspi.txt b/doc/device-tree-bindings/mtd/altera_qspi.txt new file mode 100644 index 0000000..3361ac9 --- /dev/null +++ b/doc/device-tree-bindings/mtd/altera_qspi.txt @@ -0,0 +1,35 @@ +Altera QUADSPI driver + +Required properties: +- compatible: Should be "altr,quadspi-1.0" +- reg: Address and length of the register set for the device. It contains + the information of registers in the same order as described by reg-names +- reg-names: Should contain the reg names + "avl_csr": Should contain the register configuration base address + "avl_mem": Should contain the data base address +- #address-cells: Must be <1>. +- #size-cells: Must be <0>. +- flash device tree subnode, there must be a node with the following fields: + - compatible: Should contain the flash name: + 1. EPCS: epcs16, epcs64, epcs128 + 2. EPCQ: epcq16, epcq32, epcq64, epcq128, epcq256, epcq512, epcq1024 + 3. EPCQ-L: epcql256, epcql512, epcql1024 + - #address-cells: please refer to /mtd/partition.txt + - #size-cells: please refer to /mtd/partition.txt + For partitions inside each flash, please refer to /mtd/partition.txt + +Example: + + quadspi_controller_0: quadspi@0x180014a0 { + compatible = "altr,quadspi-1.0"; + reg = <0x180014a0 0x00000020>, + <0x14000000 0x04000000>; + reg-names = "avl_csr", "avl_mem"; + #address-cells = <1>; + #size-cells = <0>; + flash0: epcq512@0 { + compatible = "altr,epcq512"; + #address-cells = <1>; + #size-cells = <1>; + }; + }; diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 367c4fe..c16b1d0 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -19,6 +19,15 @@ config CFI_FLASH option. Visit <http://www.amd.com/products/nvd/overview/cfi.html> for more information on CFI. +config ALTERA_QSPI + bool "Altera Generic Quad SPI Controller" + depends on MTD + help + This enables access to Altera EPCQ/EPCS flash chips using the + Altera Generic Quad SPI Controller. The controller converts SPI + NOR flash to parallel flash interface. Please find details on the + "Embedded Peripherals IP User Guide" of Altera. + endmenu source "drivers/mtd/nand/Kconfig" diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index c23c0c1..7f018a4 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -11,6 +11,7 @@ endif obj-$(CONFIG_MTD) += mtd-uclass.o obj-$(CONFIG_MTD_PARTITIONS) += mtdpart.o obj-$(CONFIG_MTD_CONCAT) += mtdconcat.o +obj-$(CONFIG_ALTERA_QSPI) += altera_qspi.o obj-$(CONFIG_HAS_DATAFLASH) += at45.o obj-$(CONFIG_FLASH_CFI_DRIVER) += cfi_flash.o obj-$(CONFIG_FLASH_CFI_MTD) += cfi_mtd.o diff --git a/drivers/mtd/altera_qspi.c b/drivers/mtd/altera_qspi.c new file mode 100644 index 0000000..c32b1d3 --- /dev/null +++ b/drivers/mtd/altera_qspi.c @@ -0,0 +1,276 @@ +/* + * Copyright (C) 2015 Thomas Chou <thomas@wytron.com.tw> + * + * SPDX-License-Identifier: GPL-2.0+ + */ + +#include <common.h> +#include <dm.h> +#include <errno.h> +#include <fdt_support.h> +#include <flash.h> +#include <mtd.h> +#include <asm/io.h> + +DECLARE_GLOBAL_DATA_PTR; + +/* + * The QUADSPI_MEM_OP register is used to do memory protect and erase operations + */ +#define QUADSPI_MEM_OP_BULK_ERASE 0x00000001 +#define QUADSPI_MEM_OP_SECTOR_ERASE 0x00000002 +#define QUADSPI_MEM_OP_SECTOR_PROTECT 0x00000003 + +/* + * The QUADSPI_ISR register is used to determine whether an invalid write or + * erase operation trigerred an interrupt + */ +#define QUADSPI_ISR_ILLEGAL_ERASE BIT(0) +#define QUADSPI_ISR_ILLEGAL_WRITE BIT(1) + +struct altera_qspi_regs { + u32 rd_status; + u32 rd_sid; + u32 rd_rdid; + u32 mem_op; + u32 isr; + u32 imr; + u32 chip_select; +}; + +struct altera_qspi_platdata { + struct altera_qspi_regs *regs; + void *base; + unsigned long size; +}; + +flash_info_t flash_info[CONFIG_SYS_MAX_FLASH_BANKS]; /* FLASH chips info */ + +void flash_print_info(flash_info_t *info) +{ + printf("Altera QSPI flash Size: %ld MB in %d Sectors\n", + info->size >> 20, info->sector_count); +} + +int flash_erase(flash_info_t *info, int s_first, int s_last) +{ + struct mtd_info *mtd = info->mtd; + struct erase_info instr; + int ret; + + memset(&instr, 0, sizeof(instr)); + instr.addr = mtd->erasesize * s_first; + instr.len = mtd->erasesize * (s_last + 1 - s_first); + ret = mtd_erase(mtd, &instr); + if (ret) + return ERR_NOT_ERASED; + + return 0; +} + +int write_buff(flash_info_t *info, uchar *src, ulong addr, ulong cnt) +{ + struct mtd_info *mtd = info->mtd; + struct udevice *dev = mtd->dev; + struct altera_qspi_platdata *pdata = dev_get_platdata(dev); + ulong base = (ulong)pdata->base; + loff_t to = addr - base; + size_t retlen; + int ret; + + ret = mtd_write(mtd, to, cnt, &retlen, src); + if (ret) + return ERR_NOT_ERASED; + + return 0; +} + +unsigned long flash_init(void) +{ + struct udevice *dev; + + /* probe every MTD device */ + for (uclass_first_device(UCLASS_MTD, &dev); + dev; + uclass_next_device(&dev)) { + } + + return flash_info[0].size; +} + +static int altera_qspi_erase(struct mtd_info *mtd, struct erase_info *instr) +{ + struct udevice *dev = mtd->dev; + struct altera_qspi_platdata *pdata = dev_get_platdata(dev); + struct altera_qspi_regs *regs = pdata->regs; + size_t addr = instr->addr; + size_t len = instr->len; + size_t end = addr + len; + u32 sect; + u32 stat; + + instr->state = MTD_ERASING; + addr &= ~(mtd->erasesize - 1); /* get lower aligned address */ + while (addr < end) { + sect = addr / mtd->erasesize; + sect <<= 8; + sect |= QUADSPI_MEM_OP_SECTOR_ERASE; + debug("erase %08x\n", sect); + writel(sect, ®s->mem_op); + stat = readl(®s->isr); + if (stat & QUADSPI_ISR_ILLEGAL_ERASE) { + /* erase failed, sector might be protected */ + debug("erase %08x fail %x\n", sect, stat); + writel(stat, ®s->isr); /* clear isr */ + instr->state = MTD_ERASE_FAILED; + return -EIO; + } + addr += mtd->erasesize; + } + instr->state = MTD_ERASE_DONE; + mtd_erase_callback(instr); + + return 0; +} + +static int altera_qspi_read(struct mtd_info *mtd, loff_t from, size_t len, + size_t *retlen, u_char *buf) +{ + struct udevice *dev = mtd->dev; + struct altera_qspi_platdata *pdata = dev_get_platdata(dev); + + memcpy_fromio(buf, pdata->base + from, len); + *retlen = len; + + return 0; +} + +static int altera_qspi_write(struct mtd_info *mtd, loff_t to, size_t len, + size_t *retlen, const u_char *buf) +{ + struct udevice *dev = mtd->dev; + struct altera_qspi_platdata *pdata = dev_get_platdata(dev); + struct altera_qspi_regs *regs = pdata->regs; + u32 stat; + + memcpy_toio(pdata->base + to, buf, len); + /* check whether write triggered a illegal write interrupt */ + stat = readl(®s->isr); + if (stat & QUADSPI_ISR_ILLEGAL_WRITE) { + /* write failed, sector might be protected */ + debug("write fail %x\n", stat); + writel(stat, ®s->isr); /* clear isr */ + return -EIO; + } + *retlen = len; + + return 0; +} + +static void altera_qspi_sync(struct mtd_info *mtd) +{ +} + +static int altera_qspi_probe(struct udevice *dev) +{ + struct altera_qspi_platdata *pdata = dev_get_platdata(dev); + struct altera_qspi_regs *regs = pdata->regs; + unsigned long base = (unsigned long)pdata->base; + struct mtd_info *mtd; + flash_info_t *flash = &flash_info[0]; + u32 rdid; + int i; + + rdid = readl(®s->rd_rdid); + debug("rdid %x\n", rdid); + + mtd = calloc(1, sizeof(struct mtd_info)); + if (!mtd) + return -ENOMEM; + dev->uclass_priv = mtd; + mtd->dev = dev; + mtd->name = "nor0"; + mtd->type = MTD_NORFLASH; + mtd->flags = MTD_CAP_NORFLASH; + mtd->size = 1 << ((rdid & 0xff) - 6); + mtd->writesize = 1; + mtd->writebufsize = mtd->writesize; + mtd->_erase = altera_qspi_erase; + mtd->_read = altera_qspi_read; + mtd->_write = altera_qspi_write; + mtd->_sync = altera_qspi_sync; + mtd->numeraseregions = 0; + mtd->erasesize = 0x10000; + if (add_mtd_device(mtd)) + return -ENOMEM; + + flash->mtd = mtd; + flash->size = mtd->size; + flash->sector_count = mtd->size / mtd->erasesize; + flash->flash_id = rdid; + flash->start[0] = base; + for (i = 1; i < flash->sector_count; i++) + flash->start[i] = flash->start[i - 1] + mtd->erasesize; + gd->bd->bi_flashstart = base; + + return 0; +} + +static int altera_qspi_ofdata_to_platdata(struct udevice *dev) +{ + struct altera_qspi_platdata *pdata = dev_get_platdata(dev); + void *blob = (void *)gd->fdt_blob; + int node = dev->of_offset; + const char *list, *end; + const fdt32_t *cell; + void *base; + unsigned long addr, size; + int parent, addrc, sizec; + int len, idx; + + /* + * decode regs. there are multiple reg tuples, and they need to + * match with reg-names. + */ + parent = fdt_parent_offset(blob, node); + of_bus_default_count_cells(blob, parent, &addrc, &sizec); + list = fdt_getprop(blob, node, "reg-names", &len); + if (!list) + return -ENOENT; + end = list + len; + cell = fdt_getprop(blob, node, "reg", &len); + if (!cell) + return -ENOENT; + idx = 0; + while (list < end) { + addr = fdt_translate_address((void *)blob, + node, cell + idx); + size = fdt_addr_to_cpu(cell[idx + addrc]); + base = ioremap(addr, size); + len = strlen(list); + if (strcmp(list, "avl_csr") == 0) { + pdata->regs = base; + } else if (strcmp(list, "avl_mem") == 0) { + pdata->base = base; + pdata->size = size; + } + idx += addrc + sizec; + list += (len + 1); + } + + return 0; +} + +static const struct udevice_id altera_qspi_ids[] = { + { .compatible = "altr,quadspi-1.0" }, + {} +}; + +U_BOOT_DRIVER(altera_qspi) = { + .name = "altera_qspi", + .id = UCLASS_MTD, + .of_match = altera_qspi_ids, + .ofdata_to_platdata = altera_qspi_ofdata_to_platdata, + .platdata_auto_alloc_size = sizeof(struct altera_qspi_platdata), + .probe = altera_qspi_probe, +};
Add Altera Generic Quad SPI Controller support. The controller converts SPI NOR flash to parallel flash interface. So it is not like other SPI flash, but rather like CFI flash. Signed-off-by: Thomas Chou <thomas@wytron.com.tw> --- v2 use memcpy_toio() for mtd_write() as suggested by Chin Liang and Marek. doc/device-tree-bindings/mtd/altera_qspi.txt | 35 ++++ drivers/mtd/Kconfig | 9 + drivers/mtd/Makefile | 1 + drivers/mtd/altera_qspi.c | 276 +++++++++++++++++++++++++++ 4 files changed, 321 insertions(+) create mode 100644 doc/device-tree-bindings/mtd/altera_qspi.txt create mode 100644 drivers/mtd/altera_qspi.c