* [RFC PATCH v2 0/5] MTD: Add Initial Hyperbus support @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang, Sergei Shtylyov Cypress HyperBus is Low Signal Count, High Performance Double Data Rate Bus interface between a host system master and one or more slave interfaces. HyperBus is used to connect microprocessor, microcontroller, or ASIC devices with random access NOR flash memory(called HyperFlash) or self refresh DRAM(called HyperRAM). Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) signal and either Single-ended clock(3.0V parts) or Differential clock (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. At bus level, it follows a separate protocol described in HyperBus specification[1]. HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, its equivalent to x16 parallel NOR flash wrt bits per clk. But Hyperbus operates at >166MHz frequencies. HyperRAM provides direct random read/write access to flash memory array. Framework is modelled along the lines of spi-nor framework. HyperBus memory controller(HBMC) drivers call hyperbus_register_device() to register a single HyperFlash device. HyperFlash core parses MMIO access information from DT, sets up the map_info struct, probes CFI flash and registers it with MTD framework. This is an early RFC, to know if its okay to use maps framework and existing CFI compliant flash support code to support Hyperflash Also would like input on different types of HBMC master IPs out there and their programming sequences. Would appreciate any testing/review. Tested on modified TI AM654 EVM with Cypress Hyperflash S26KS512 by creating a UBIFS partition and writing and reading files to it. Stress tested by writing/reading 16MB flash repeatedly at different offsets using dd commmand. HyperBus specification can be found at[1] HyperFlash datasheet can be found at[2] TI's HBMC controller details at[3] [1] https://www.cypress.com/file/213356/download [2] https://www.cypress.com/file/213346/download [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf Table 12-5741. HyperFlash Access Sequence Enumeration log: https://pastebin.ubuntu.com/p/GhqxJ8XTTx/ Change log: Since RFC v1: * Re-work Hyperbus core to provide separate struct representation for controller and slave devices * Rename all files and func names to have hyperbus_ prefix * Provide default calibration routine for use by controller drivers * Fix up errors with patch spliting * Address comments by Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Vignesh Raghavendra (5): mtd: cfi_cmdset_0002: Add support for polling status register dt-bindings: mtd: Add binding documentation for Hyperbus memory devices mtd: Add support for Hyperbus memory devices dt-bindings: mtd: Add bindings for TI's AM654 Hyperbus memory controller mtd: hyperbus: Add driver for TI's Hyperbus memory controller .../bindings/mtd/cypress,hyperbus.txt | 6 + .../devicetree/bindings/mtd/ti,am654-hbmc.txt | 27 +++ MAINTAINERS | 8 + drivers/mtd/Kconfig | 2 + drivers/mtd/Makefile | 1 + drivers/mtd/chips/cfi_cmdset_0002.c | 50 +++++ drivers/mtd/hyperbus/Kconfig | 21 ++ drivers/mtd/hyperbus/Makefile | 4 + drivers/mtd/hyperbus/hbmc_am654.c | 108 +++++++++++ drivers/mtd/hyperbus/hyperbus-core.c | 183 ++++++++++++++++++ include/linux/mtd/cfi.h | 5 + include/linux/mtd/hyperbus.h | 91 +++++++++ 12 files changed, 506 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt create mode 100644 drivers/mtd/hyperbus/Kconfig create mode 100644 drivers/mtd/hyperbus/Makefile create mode 100644 drivers/mtd/hyperbus/hbmc_am654.c create mode 100644 drivers/mtd/hyperbus/hyperbus-core.c create mode 100644 include/linux/mtd/hyperbus.h -- 2.21.0 ^ permalink raw reply [flat|nested] 67+ messages in thread
* [RFC PATCH v2 0/5] MTD: Add Initial Hyperbus support @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Sergei Shtylyov, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Cypress HyperBus is Low Signal Count, High Performance Double Data Rate Bus interface between a host system master and one or more slave interfaces. HyperBus is used to connect microprocessor, microcontroller, or ASIC devices with random access NOR flash memory(called HyperFlash) or self refresh DRAM(called HyperRAM). Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) signal and either Single-ended clock(3.0V parts) or Differential clock (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. At bus level, it follows a separate protocol described in HyperBus specification[1]. HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, its equivalent to x16 parallel NOR flash wrt bits per clk. But Hyperbus operates at >166MHz frequencies. HyperRAM provides direct random read/write access to flash memory array. Framework is modelled along the lines of spi-nor framework. HyperBus memory controller(HBMC) drivers call hyperbus_register_device() to register a single HyperFlash device. HyperFlash core parses MMIO access information from DT, sets up the map_info struct, probes CFI flash and registers it with MTD framework. This is an early RFC, to know if its okay to use maps framework and existing CFI compliant flash support code to support Hyperflash Also would like input on different types of HBMC master IPs out there and their programming sequences. Would appreciate any testing/review. Tested on modified TI AM654 EVM with Cypress Hyperflash S26KS512 by creating a UBIFS partition and writing and reading files to it. Stress tested by writing/reading 16MB flash repeatedly at different offsets using dd commmand. HyperBus specification can be found at[1] HyperFlash datasheet can be found at[2] TI's HBMC controller details at[3] [1] https://www.cypress.com/file/213356/download [2] https://www.cypress.com/file/213346/download [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf Table 12-5741. HyperFlash Access Sequence Enumeration log: https://pastebin.ubuntu.com/p/GhqxJ8XTTx/ Change log: Since RFC v1: * Re-work Hyperbus core to provide separate struct representation for controller and slave devices * Rename all files and func names to have hyperbus_ prefix * Provide default calibration routine for use by controller drivers * Fix up errors with patch spliting * Address comments by Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Vignesh Raghavendra (5): mtd: cfi_cmdset_0002: Add support for polling status register dt-bindings: mtd: Add binding documentation for Hyperbus memory devices mtd: Add support for Hyperbus memory devices dt-bindings: mtd: Add bindings for TI's AM654 Hyperbus memory controller mtd: hyperbus: Add driver for TI's Hyperbus memory controller .../bindings/mtd/cypress,hyperbus.txt | 6 + .../devicetree/bindings/mtd/ti,am654-hbmc.txt | 27 +++ MAINTAINERS | 8 + drivers/mtd/Kconfig | 2 + drivers/mtd/Makefile | 1 + drivers/mtd/chips/cfi_cmdset_0002.c | 50 +++++ drivers/mtd/hyperbus/Kconfig | 21 ++ drivers/mtd/hyperbus/Makefile | 4 + drivers/mtd/hyperbus/hbmc_am654.c | 108 +++++++++++ drivers/mtd/hyperbus/hyperbus-core.c | 183 ++++++++++++++++++ include/linux/mtd/cfi.h | 5 + include/linux/mtd/hyperbus.h | 91 +++++++++ 12 files changed, 506 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt create mode 100644 drivers/mtd/hyperbus/Kconfig create mode 100644 drivers/mtd/hyperbus/Makefile create mode 100644 drivers/mtd/hyperbus/hbmc_am654.c create mode 100644 drivers/mtd/hyperbus/hyperbus-core.c create mode 100644 include/linux/mtd/hyperbus.h -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 67+ messages in thread
* [RFC PATCH v2 0/5] MTD: Add Initial Hyperbus support @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Sergei Shtylyov, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Cypress HyperBus is Low Signal Count, High Performance Double Data Rate Bus interface between a host system master and one or more slave interfaces. HyperBus is used to connect microprocessor, microcontroller, or ASIC devices with random access NOR flash memory(called HyperFlash) or self refresh DRAM(called HyperRAM). Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) signal and either Single-ended clock(3.0V parts) or Differential clock (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. At bus level, it follows a separate protocol described in HyperBus specification[1]. HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, its equivalent to x16 parallel NOR flash wrt bits per clk. But Hyperbus operates at >166MHz frequencies. HyperRAM provides direct random read/write access to flash memory array. Framework is modelled along the lines of spi-nor framework. HyperBus memory controller(HBMC) drivers call hyperbus_register_device() to register a single HyperFlash device. HyperFlash core parses MMIO access information from DT, sets up the map_info struct, probes CFI flash and registers it with MTD framework. This is an early RFC, to know if its okay to use maps framework and existing CFI compliant flash support code to support Hyperflash Also would like input on different types of HBMC master IPs out there and their programming sequences. Would appreciate any testing/review. Tested on modified TI AM654 EVM with Cypress Hyperflash S26KS512 by creating a UBIFS partition and writing and reading files to it. Stress tested by writing/reading 16MB flash repeatedly at different offsets using dd commmand. HyperBus specification can be found at[1] HyperFlash datasheet can be found at[2] TI's HBMC controller details at[3] [1] https://www.cypress.com/file/213356/download [2] https://www.cypress.com/file/213346/download [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf Table 12-5741. HyperFlash Access Sequence Enumeration log: https://pastebin.ubuntu.com/p/GhqxJ8XTTx/ Change log: Since RFC v1: * Re-work Hyperbus core to provide separate struct representation for controller and slave devices * Rename all files and func names to have hyperbus_ prefix * Provide default calibration routine for use by controller drivers * Fix up errors with patch spliting * Address comments by Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Vignesh Raghavendra (5): mtd: cfi_cmdset_0002: Add support for polling status register dt-bindings: mtd: Add binding documentation for Hyperbus memory devices mtd: Add support for Hyperbus memory devices dt-bindings: mtd: Add bindings for TI's AM654 Hyperbus memory controller mtd: hyperbus: Add driver for TI's Hyperbus memory controller .../bindings/mtd/cypress,hyperbus.txt | 6 + .../devicetree/bindings/mtd/ti,am654-hbmc.txt | 27 +++ MAINTAINERS | 8 + drivers/mtd/Kconfig | 2 + drivers/mtd/Makefile | 1 + drivers/mtd/chips/cfi_cmdset_0002.c | 50 +++++ drivers/mtd/hyperbus/Kconfig | 21 ++ drivers/mtd/hyperbus/Makefile | 4 + drivers/mtd/hyperbus/hbmc_am654.c | 108 +++++++++++ drivers/mtd/hyperbus/hyperbus-core.c | 183 ++++++++++++++++++ include/linux/mtd/cfi.h | 5 + include/linux/mtd/hyperbus.h | 91 +++++++++ 12 files changed, 506 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt create mode 100644 drivers/mtd/hyperbus/Kconfig create mode 100644 drivers/mtd/hyperbus/Makefile create mode 100644 drivers/mtd/hyperbus/hbmc_am654.c create mode 100644 drivers/mtd/hyperbus/hyperbus-core.c create mode 100644 include/linux/mtd/hyperbus.h -- 2.21.0 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* [RFC PATCH v2 0/5] MTD: Add Initial Hyperbus support @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Sergei Shtylyov, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Cypress HyperBus is Low Signal Count, High Performance Double Data Rate Bus interface between a host system master and one or more slave interfaces. HyperBus is used to connect microprocessor, microcontroller, or ASIC devices with random access NOR flash memory(called HyperFlash) or self refresh DRAM(called HyperRAM). Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) signal and either Single-ended clock(3.0V parts) or Differential clock (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. At bus level, it follows a separate protocol described in HyperBus specification[1]. HyperFlash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, its equivalent to x16 parallel NOR flash wrt bits per clk. But Hyperbus operates at >166MHz frequencies. HyperRAM provides direct random read/write access to flash memory array. Framework is modelled along the lines of spi-nor framework. HyperBus memory controller(HBMC) drivers call hyperbus_register_device() to register a single HyperFlash device. HyperFlash core parses MMIO access information from DT, sets up the map_info struct, probes CFI flash and registers it with MTD framework. This is an early RFC, to know if its okay to use maps framework and existing CFI compliant flash support code to support Hyperflash Also would like input on different types of HBMC master IPs out there and their programming sequences. Would appreciate any testing/review. Tested on modified TI AM654 EVM with Cypress Hyperflash S26KS512 by creating a UBIFS partition and writing and reading files to it. Stress tested by writing/reading 16MB flash repeatedly at different offsets using dd commmand. HyperBus specification can be found at[1] HyperFlash datasheet can be found at[2] TI's HBMC controller details at[3] [1] https://www.cypress.com/file/213356/download [2] https://www.cypress.com/file/213346/download [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf Table 12-5741. HyperFlash Access Sequence Enumeration log: https://pastebin.ubuntu.com/p/GhqxJ8XTTx/ Change log: Since RFC v1: * Re-work Hyperbus core to provide separate struct representation for controller and slave devices * Rename all files and func names to have hyperbus_ prefix * Provide default calibration routine for use by controller drivers * Fix up errors with patch spliting * Address comments by Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Vignesh Raghavendra (5): mtd: cfi_cmdset_0002: Add support for polling status register dt-bindings: mtd: Add binding documentation for Hyperbus memory devices mtd: Add support for Hyperbus memory devices dt-bindings: mtd: Add bindings for TI's AM654 Hyperbus memory controller mtd: hyperbus: Add driver for TI's Hyperbus memory controller .../bindings/mtd/cypress,hyperbus.txt | 6 + .../devicetree/bindings/mtd/ti,am654-hbmc.txt | 27 +++ MAINTAINERS | 8 + drivers/mtd/Kconfig | 2 + drivers/mtd/Makefile | 1 + drivers/mtd/chips/cfi_cmdset_0002.c | 50 +++++ drivers/mtd/hyperbus/Kconfig | 21 ++ drivers/mtd/hyperbus/Makefile | 4 + drivers/mtd/hyperbus/hbmc_am654.c | 108 +++++++++++ drivers/mtd/hyperbus/hyperbus-core.c | 183 ++++++++++++++++++ include/linux/mtd/cfi.h | 5 + include/linux/mtd/hyperbus.h | 91 +++++++++ 12 files changed, 506 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt create mode 100644 drivers/mtd/hyperbus/Kconfig create mode 100644 drivers/mtd/hyperbus/Makefile create mode 100644 drivers/mtd/hyperbus/hbmc_am654.c create mode 100644 drivers/mtd/hyperbus/hyperbus-core.c create mode 100644 include/linux/mtd/hyperbus.h -- 2.21.0 ^ permalink raw reply [flat|nested] 67+ messages in thread
* [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register 2019-03-21 17:45 ` Vignesh Raghavendra (?) (?) @ 2019-03-21 17:45 ` Vignesh Raghavendra -1 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang, Sergei Shtylyov HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c can be use as is. But these devices do not support DQ polling method of determining chip ready/good status. These flashes provide Status Register whose bits can be polled to know status of flash operation. Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu Extended Query version 1.5. Bit 0 of "Software Features supported" field of CFI Primary Vendor-Specific Extended Query table indicates presence/absence of status register and Bit 1 indicates whether or not DQ polling is supported. Using these bits, its possible to determine whether flash supports DQ polling or need to use Status Register. Add support for polling status register to know device ready/status of erase/write operations when DQ polling is not supported. [1] https://www.cypress.com/file/213346/download Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- drivers/mtd/chips/cfi_cmdset_0002.c | 50 +++++++++++++++++++++++++++++ include/linux/mtd/cfi.h | 5 +++ 2 files changed, 55 insertions(+) diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c index 72428b6bfc47..29987d8e6c6e 100644 --- a/drivers/mtd/chips/cfi_cmdset_0002.c +++ b/drivers/mtd/chips/cfi_cmdset_0002.c @@ -49,6 +49,14 @@ #define SST49LF008A 0x005a #define AT49BV6416 0x00d6 +/* + * Bits of Status Register definition for flash devices that don't + * support DQ polling (Eg.: Hyperflash) + */ +#define CFI_SR_DRB BIT(7) +#define CFI_SR_ESB BIT(5) +#define CFI_SR_PSB BIT(4) + static int cfi_amdstd_read (struct mtd_info *, loff_t, size_t, size_t *, u_char *); static int cfi_amdstd_write_words(struct mtd_info *, loff_t, size_t, size_t *, const u_char *); static int cfi_amdstd_write_buffers(struct mtd_info *, loff_t, size_t, size_t *, const u_char *); @@ -97,6 +105,18 @@ static struct mtd_chip_driver cfi_amdstd_chipdrv = { .module = THIS_MODULE }; +/* + * Use status register to poll for Erase/write completion when DQ is not + * supported. This is indicated by Bit[1:0] of SoftwareFeatures field in + * CFI Primary Vendor-Specific Extended Query table 1.5 + */ +static int cfi_use_status_reg(struct cfi_private *cfi) +{ + struct cfi_pri_amdstd *extp = cfi->cmdset_priv; + + return (extp->MinorVersion >= '5') && + (extp->SoftwareFeatures & 0x11) == 1; +} /* #define DEBUG_CFI_FEATURES */ @@ -744,8 +764,21 @@ static struct mtd_info *cfi_amdstd_setup(struct mtd_info *mtd) */ static int __xipram chip_ready(struct map_info *map, unsigned long addr) { + struct cfi_private *cfi = map->fldrv_priv; map_word d, t; + if (cfi_use_status_reg(cfi)) { + /* + * For chips that support status register, check device + * ready bit + */ + cfi_send_gen_cmd(0x70, cfi->addr_unlock1, 0, map, cfi, + cfi->device_type, NULL); + d = map_read(map, addr); + + return d.x[0] & CFI_SR_DRB; + } + d = map_read(map, addr); t = map_read(map, addr); @@ -769,8 +802,25 @@ static int __xipram chip_ready(struct map_info *map, unsigned long addr) */ static int __xipram chip_good(struct map_info *map, unsigned long addr, map_word expected) { + struct cfi_private *cfi = map->fldrv_priv; map_word oldd, curd; + if (cfi_use_status_reg(cfi)) { + /* + * For chips that support status register, check device + * ready bit and Erase/Program status bit to know if + * operation succeeded. + */ + cfi_send_gen_cmd(0x70, cfi->addr_unlock1, 0, map, cfi, + cfi->device_type, NULL); + curd = map_read(map, addr); + + if (curd.x[0] & CFI_SR_DRB) + return !(curd.x[0] & (CFI_SR_PSB | CFI_SR_ESB)); + + return 0; + } + oldd = map_read(map, addr); curd = map_read(map, addr); diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h index cbf77168658c..92ac82ac2329 100644 --- a/include/linux/mtd/cfi.h +++ b/include/linux/mtd/cfi.h @@ -233,6 +233,11 @@ struct cfi_pri_amdstd { uint8_t VppMin; uint8_t VppMax; uint8_t TopBottom; + /* Below field are added from version 1.5 */ + uint8_t ProgramSuspend; + uint8_t UnlockBypass; + uint8_t SecureSiliconSector; + uint8_t SoftwareFeatures; } __packed; /* Vendor-Specific PRI for Atmel chips (command set 0x0002) */ -- 2.21.0 ^ permalink raw reply related [flat|nested] 67+ messages in thread
* [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Sergei Shtylyov, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c can be use as is. But these devices do not support DQ polling method of determining chip ready/good status. These flashes provide Status Register whose bits can be polled to know status of flash operation. Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu Extended Query version 1.5. Bit 0 of "Software Features supported" field of CFI Primary Vendor-Specific Extended Query table indicates presence/absence of status register and Bit 1 indicates whether or not DQ polling is supported. Using these bits, its possible to determine whether flash supports DQ polling or need to use Status Register. Add support for polling status register to know device ready/status of erase/write operations when DQ polling is not supported. [1] https://www.cypress.com/file/213346/download Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- drivers/mtd/chips/cfi_cmdset_0002.c | 50 +++++++++++++++++++++++++++++ include/linux/mtd/cfi.h | 5 +++ 2 files changed, 55 insertions(+) diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c index 72428b6bfc47..29987d8e6c6e 100644 --- a/drivers/mtd/chips/cfi_cmdset_0002.c +++ b/drivers/mtd/chips/cfi_cmdset_0002.c @@ -49,6 +49,14 @@ #define SST49LF008A 0x005a #define AT49BV6416 0x00d6 +/* + * Bits of Status Register definition for flash devices that don't + * support DQ polling (Eg.: Hyperflash) + */ +#define CFI_SR_DRB BIT(7) +#define CFI_SR_ESB BIT(5) +#define CFI_SR_PSB BIT(4) + static int cfi_amdstd_read (struct mtd_info *, loff_t, size_t, size_t *, u_char *); static int cfi_amdstd_write_words(struct mtd_info *, loff_t, size_t, size_t *, const u_char *); static int cfi_amdstd_write_buffers(struct mtd_info *, loff_t, size_t, size_t *, const u_char *); @@ -97,6 +105,18 @@ static struct mtd_chip_driver cfi_amdstd_chipdrv = { .module = THIS_MODULE }; +/* + * Use status register to poll for Erase/write completion when DQ is not + * supported. This is indicated by Bit[1:0] of SoftwareFeatures field in + * CFI Primary Vendor-Specific Extended Query table 1.5 + */ +static int cfi_use_status_reg(struct cfi_private *cfi) +{ + struct cfi_pri_amdstd *extp = cfi->cmdset_priv; + + return (extp->MinorVersion >= '5') && + (extp->SoftwareFeatures & 0x11) == 1; +} /* #define DEBUG_CFI_FEATURES */ @@ -744,8 +764,21 @@ static struct mtd_info *cfi_amdstd_setup(struct mtd_info *mtd) */ static int __xipram chip_ready(struct map_info *map, unsigned long addr) { + struct cfi_private *cfi = map->fldrv_priv; map_word d, t; + if (cfi_use_status_reg(cfi)) { + /* + * For chips that support status register, check device + * ready bit + */ + cfi_send_gen_cmd(0x70, cfi->addr_unlock1, 0, map, cfi, + cfi->device_type, NULL); + d = map_read(map, addr); + + return d.x[0] & CFI_SR_DRB; + } + d = map_read(map, addr); t = map_read(map, addr); @@ -769,8 +802,25 @@ static int __xipram chip_ready(struct map_info *map, unsigned long addr) */ static int __xipram chip_good(struct map_info *map, unsigned long addr, map_word expected) { + struct cfi_private *cfi = map->fldrv_priv; map_word oldd, curd; + if (cfi_use_status_reg(cfi)) { + /* + * For chips that support status register, check device + * ready bit and Erase/Program status bit to know if + * operation succeeded. + */ + cfi_send_gen_cmd(0x70, cfi->addr_unlock1, 0, map, cfi, + cfi->device_type, NULL); + curd = map_read(map, addr); + + if (curd.x[0] & CFI_SR_DRB) + return !(curd.x[0] & (CFI_SR_PSB | CFI_SR_ESB)); + + return 0; + } + oldd = map_read(map, addr); curd = map_read(map, addr); diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h index cbf77168658c..92ac82ac2329 100644 --- a/include/linux/mtd/cfi.h +++ b/include/linux/mtd/cfi.h @@ -233,6 +233,11 @@ struct cfi_pri_amdstd { uint8_t VppMin; uint8_t VppMax; uint8_t TopBottom; + /* Below field are added from version 1.5 */ + uint8_t ProgramSuspend; + uint8_t UnlockBypass; + uint8_t SecureSiliconSector; + uint8_t SoftwareFeatures; } __packed; /* Vendor-Specific PRI for Atmel chips (command set 0x0002) */ -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 67+ messages in thread
* [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Sergei Shtylyov, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c can be use as is. But these devices do not support DQ polling method of determining chip ready/good status. These flashes provide Status Register whose bits can be polled to know status of flash operation. Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu Extended Query version 1.5. Bit 0 of "Software Features supported" field of CFI Primary Vendor-Specific Extended Query table indicates presence/absence of status register and Bit 1 indicates whether or not DQ polling is supported. Using these bits, its possible to determine whether flash supports DQ polling or need to use Status Register. Add support for polling status register to know device ready/status of erase/write operations when DQ polling is not supported. [1] https://www.cypress.com/file/213346/download Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- drivers/mtd/chips/cfi_cmdset_0002.c | 50 +++++++++++++++++++++++++++++ include/linux/mtd/cfi.h | 5 +++ 2 files changed, 55 insertions(+) diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c index 72428b6bfc47..29987d8e6c6e 100644 --- a/drivers/mtd/chips/cfi_cmdset_0002.c +++ b/drivers/mtd/chips/cfi_cmdset_0002.c @@ -49,6 +49,14 @@ #define SST49LF008A 0x005a #define AT49BV6416 0x00d6 +/* + * Bits of Status Register definition for flash devices that don't + * support DQ polling (Eg.: Hyperflash) + */ +#define CFI_SR_DRB BIT(7) +#define CFI_SR_ESB BIT(5) +#define CFI_SR_PSB BIT(4) + static int cfi_amdstd_read (struct mtd_info *, loff_t, size_t, size_t *, u_char *); static int cfi_amdstd_write_words(struct mtd_info *, loff_t, size_t, size_t *, const u_char *); static int cfi_amdstd_write_buffers(struct mtd_info *, loff_t, size_t, size_t *, const u_char *); @@ -97,6 +105,18 @@ static struct mtd_chip_driver cfi_amdstd_chipdrv = { .module = THIS_MODULE }; +/* + * Use status register to poll for Erase/write completion when DQ is not + * supported. This is indicated by Bit[1:0] of SoftwareFeatures field in + * CFI Primary Vendor-Specific Extended Query table 1.5 + */ +static int cfi_use_status_reg(struct cfi_private *cfi) +{ + struct cfi_pri_amdstd *extp = cfi->cmdset_priv; + + return (extp->MinorVersion >= '5') && + (extp->SoftwareFeatures & 0x11) == 1; +} /* #define DEBUG_CFI_FEATURES */ @@ -744,8 +764,21 @@ static struct mtd_info *cfi_amdstd_setup(struct mtd_info *mtd) */ static int __xipram chip_ready(struct map_info *map, unsigned long addr) { + struct cfi_private *cfi = map->fldrv_priv; map_word d, t; + if (cfi_use_status_reg(cfi)) { + /* + * For chips that support status register, check device + * ready bit + */ + cfi_send_gen_cmd(0x70, cfi->addr_unlock1, 0, map, cfi, + cfi->device_type, NULL); + d = map_read(map, addr); + + return d.x[0] & CFI_SR_DRB; + } + d = map_read(map, addr); t = map_read(map, addr); @@ -769,8 +802,25 @@ static int __xipram chip_ready(struct map_info *map, unsigned long addr) */ static int __xipram chip_good(struct map_info *map, unsigned long addr, map_word expected) { + struct cfi_private *cfi = map->fldrv_priv; map_word oldd, curd; + if (cfi_use_status_reg(cfi)) { + /* + * For chips that support status register, check device + * ready bit and Erase/Program status bit to know if + * operation succeeded. + */ + cfi_send_gen_cmd(0x70, cfi->addr_unlock1, 0, map, cfi, + cfi->device_type, NULL); + curd = map_read(map, addr); + + if (curd.x[0] & CFI_SR_DRB) + return !(curd.x[0] & (CFI_SR_PSB | CFI_SR_ESB)); + + return 0; + } + oldd = map_read(map, addr); curd = map_read(map, addr); diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h index cbf77168658c..92ac82ac2329 100644 --- a/include/linux/mtd/cfi.h +++ b/include/linux/mtd/cfi.h @@ -233,6 +233,11 @@ struct cfi_pri_amdstd { uint8_t VppMin; uint8_t VppMax; uint8_t TopBottom; + /* Below field are added from version 1.5 */ + uint8_t ProgramSuspend; + uint8_t UnlockBypass; + uint8_t SecureSiliconSector; + uint8_t SoftwareFeatures; } __packed; /* Vendor-Specific PRI for Atmel chips (command set 0x0002) */ -- 2.21.0 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply related [flat|nested] 67+ messages in thread
* [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang, Sergei Shtylyov HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c can be use as is. But these devices do not support DQ polling method of determining chip ready/good status. These flashes provide Status Register whose bits can be polled to know status of flash operation. Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu Extended Query version 1.5. Bit 0 of "Software Features supported" field of CFI Primary Vendor-Specific Extended Query table indicates presence/absence of status register and Bit 1 indicates whether or not DQ polling is supported. Using these bits, its possible to determine whether flash supports DQ polling or need to use Status Register. Add support for polling status register to know device ready/status of erase/write operations when DQ polling is not supported. [1] https://www.cypress.com/file/213346/download Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- drivers/mtd/chips/cfi_cmdset_0002.c | 50 +++++++++++++++++++++++++++++ include/linux/mtd/cfi.h | 5 +++ 2 files changed, 55 insertions(+) diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c index 72428b6bfc47..29987d8e6c6e 100644 --- a/drivers/mtd/chips/cfi_cmdset_0002.c +++ b/drivers/mtd/chips/cfi_cmdset_0002.c @@ -49,6 +49,14 @@ #define SST49LF008A 0x005a #define AT49BV6416 0x00d6 +/* + * Bits of Status Register definition for flash devices that don't + * support DQ polling (Eg.: Hyperflash) + */ +#define CFI_SR_DRB BIT(7) +#define CFI_SR_ESB BIT(5) +#define CFI_SR_PSB BIT(4) + static int cfi_amdstd_read (struct mtd_info *, loff_t, size_t, size_t *, u_char *); static int cfi_amdstd_write_words(struct mtd_info *, loff_t, size_t, size_t *, const u_char *); static int cfi_amdstd_write_buffers(struct mtd_info *, loff_t, size_t, size_t *, const u_char *); @@ -97,6 +105,18 @@ static struct mtd_chip_driver cfi_amdstd_chipdrv = { .module = THIS_MODULE }; +/* + * Use status register to poll for Erase/write completion when DQ is not + * supported. This is indicated by Bit[1:0] of SoftwareFeatures field in + * CFI Primary Vendor-Specific Extended Query table 1.5 + */ +static int cfi_use_status_reg(struct cfi_private *cfi) +{ + struct cfi_pri_amdstd *extp = cfi->cmdset_priv; + + return (extp->MinorVersion >= '5') && + (extp->SoftwareFeatures & 0x11) == 1; +} /* #define DEBUG_CFI_FEATURES */ @@ -744,8 +764,21 @@ static struct mtd_info *cfi_amdstd_setup(struct mtd_info *mtd) */ static int __xipram chip_ready(struct map_info *map, unsigned long addr) { + struct cfi_private *cfi = map->fldrv_priv; map_word d, t; + if (cfi_use_status_reg(cfi)) { + /* + * For chips that support status register, check device + * ready bit + */ + cfi_send_gen_cmd(0x70, cfi->addr_unlock1, 0, map, cfi, + cfi->device_type, NULL); + d = map_read(map, addr); + + return d.x[0] & CFI_SR_DRB; + } + d = map_read(map, addr); t = map_read(map, addr); @@ -769,8 +802,25 @@ static int __xipram chip_ready(struct map_info *map, unsigned long addr) */ static int __xipram chip_good(struct map_info *map, unsigned long addr, map_word expected) { + struct cfi_private *cfi = map->fldrv_priv; map_word oldd, curd; + if (cfi_use_status_reg(cfi)) { + /* + * For chips that support status register, check device + * ready bit and Erase/Program status bit to know if + * operation succeeded. + */ + cfi_send_gen_cmd(0x70, cfi->addr_unlock1, 0, map, cfi, + cfi->device_type, NULL); + curd = map_read(map, addr); + + if (curd.x[0] & CFI_SR_DRB) + return !(curd.x[0] & (CFI_SR_PSB | CFI_SR_ESB)); + + return 0; + } + oldd = map_read(map, addr); curd = map_read(map, addr); diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h index cbf77168658c..92ac82ac2329 100644 --- a/include/linux/mtd/cfi.h +++ b/include/linux/mtd/cfi.h @@ -233,6 +233,11 @@ struct cfi_pri_amdstd { uint8_t VppMin; uint8_t VppMax; uint8_t TopBottom; + /* Below field are added from version 1.5 */ + uint8_t ProgramSuspend; + uint8_t UnlockBypass; + uint8_t SecureSiliconSector; + uint8_t SoftwareFeatures; } __packed; /* Vendor-Specific PRI for Atmel chips (command set 0x0002) */ -- 2.21.0 ^ permalink raw reply related [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register 2019-03-21 17:45 ` Vignesh Raghavendra (?) (?) @ 2019-03-21 18:11 ` Joakim Tjernlund -1 siblings, 0 replies; 67+ messages in thread From: Joakim Tjernlund @ 2019-03-21 18:11 UTC (permalink / raw) To: robh+dt, computersforpeace, vigneshr, bbrezillon, marek.vasut, dwmw2, richard Cc: nsekhar, linux-kernel, linux-mtd, devicetree, masonccyang, tudor.ambarus, sergei.shtylyov, gregkh, linux-arm-kernel, arnd On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: > > HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command > Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c > can be use as is. But these devices do not support DQ polling method of > determining chip ready/good status. These flashes provide Status > Register whose bits can be polled to know status of flash operation. > > Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu > Extended Query version 1.5. Bit 0 of "Software Features supported" field > of CFI Primary Vendor-Specific Extended Query table indicates > presence/absence of status register and Bit 1 indicates whether or not > DQ polling is supported. Using these bits, its possible to determine > whether flash supports DQ polling or need to use Status Register. > > Add support for polling status register to know device ready/status of > erase/write operations when DQ polling is not supported. Isn't this new Status scheme just a copy of Intels(cmdset_0001)? If so I think the new status impl. in 0002 should borrow from 0001 as this is a hardened and battle tested impl. I know other modern 0002 chips supports both old and new impl. of Status and I world guess that we will see more chips with new Status only. Jocke ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-21 18:11 ` Joakim Tjernlund 0 siblings, 0 replies; 67+ messages in thread From: Joakim Tjernlund @ 2019-03-21 18:11 UTC (permalink / raw) To: robh+dt, computersforpeace, vigneshr, bbrezillon, marek.vasut, dwmw2, richard Cc: devicetree, arnd, sergei.shtylyov, tudor.ambarus, gregkh, nsekhar, linux-kernel, linux-mtd, masonccyang, linux-arm-kernel On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: > > HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command > Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c > can be use as is. But these devices do not support DQ polling method of > determining chip ready/good status. These flashes provide Status > Register whose bits can be polled to know status of flash operation. > > Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu > Extended Query version 1.5. Bit 0 of "Software Features supported" field > of CFI Primary Vendor-Specific Extended Query table indicates > presence/absence of status register and Bit 1 indicates whether or not > DQ polling is supported. Using these bits, its possible to determine > whether flash supports DQ polling or need to use Status Register. > > Add support for polling status register to know device ready/status of > erase/write operations when DQ polling is not supported. Isn't this new Status scheme just a copy of Intels(cmdset_0001)? If so I think the new status impl. in 0002 should borrow from 0001 as this is a hardened and battle tested impl. I know other modern 0002 chips supports both old and new impl. of Status and I world guess that we will see more chips with new Status only. Jocke _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-21 18:11 ` Joakim Tjernlund 0 siblings, 0 replies; 67+ messages in thread From: Joakim Tjernlund @ 2019-03-21 18:11 UTC (permalink / raw) To: robh+dt, computersforpeace, vigneshr, bbrezillon, marek.vasut, dwmw2, richard Cc: devicetree, arnd, sergei.shtylyov, tudor.ambarus, gregkh, nsekhar, linux-kernel, linux-mtd, masonccyang, linux-arm-kernel On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: > > HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command > Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c > can be use as is. But these devices do not support DQ polling method of > determining chip ready/good status. These flashes provide Status > Register whose bits can be polled to know status of flash operation. > > Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu > Extended Query version 1.5. Bit 0 of "Software Features supported" field > of CFI Primary Vendor-Specific Extended Query table indicates > presence/absence of status register and Bit 1 indicates whether or not > DQ polling is supported. Using these bits, its possible to determine > whether flash supports DQ polling or need to use Status Register. > > Add support for polling status register to know device ready/status of > erase/write operations when DQ polling is not supported. Isn't this new Status scheme just a copy of Intels(cmdset_0001)? If so I think the new status impl. in 0002 should borrow from 0001 as this is a hardened and battle tested impl. I know other modern 0002 chips supports both old and new impl. of Status and I world guess that we will see more chips with new Status only. Jocke ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-21 18:11 ` Joakim Tjernlund 0 siblings, 0 replies; 67+ messages in thread From: Joakim Tjernlund @ 2019-03-21 18:11 UTC (permalink / raw) To: robh+dt, computersforpeace, vigneshr, bbrezillon, marek.vasut, dwmw2, richard Cc: nsekhar, linux-kernel, linux-mtd, devicetree, masonccyang, tudor.ambarus, sergei.shtylyov, gregkh, linux-arm-kernel, arnd On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: > > HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command > Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c > can be use as is. But these devices do not support DQ polling method of > determining chip ready/good status. These flashes provide Status > Register whose bits can be polled to know status of flash operation. > > Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu > Extended Query version 1.5. Bit 0 of "Software Features supported" field > of CFI Primary Vendor-Specific Extended Query table indicates > presence/absence of status register and Bit 1 indicates whether or not > DQ polling is supported. Using these bits, its possible to determine > whether flash supports DQ polling or need to use Status Register. > > Add support for polling status register to know device ready/status of > erase/write operations when DQ polling is not supported. Isn't this new Status scheme just a copy of Intels(cmdset_0001)? If so I think the new status impl. in 0002 should borrow from 0001 as this is a hardened and battle tested impl. I know other modern 0002 chips supports both old and new impl. of Status and I world guess that we will see more chips with new Status only. Jocke ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register 2019-03-21 18:11 ` Joakim Tjernlund (?) (?) @ 2019-03-25 12:57 ` Vignesh Raghavendra -1 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-25 12:57 UTC (permalink / raw) To: Joakim Tjernlund, robh+dt, computersforpeace, bbrezillon, marek.vasut, dwmw2, richard Cc: nsekhar, linux-kernel, linux-mtd, devicetree, masonccyang, tudor.ambarus, sergei.shtylyov, gregkh, linux-arm-kernel, arnd Hi, On 21/03/19 11:41 PM, Joakim Tjernlund wrote: > On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: >> >> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command >> Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c >> can be use as is. But these devices do not support DQ polling method of >> determining chip ready/good status. These flashes provide Status >> Register whose bits can be polled to know status of flash operation. >> >> Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu >> Extended Query version 1.5. Bit 0 of "Software Features supported" field >> of CFI Primary Vendor-Specific Extended Query table indicates >> presence/absence of status register and Bit 1 indicates whether or not >> DQ polling is supported. Using these bits, its possible to determine >> whether flash supports DQ polling or need to use Status Register. >> >> Add support for polling status register to know device ready/status of >> erase/write operations when DQ polling is not supported. > > Isn't this new Status scheme just a copy of Intels(cmdset_0001)? Yes, but with one difference: At the end of program/erase operation, device directly enters status register mode and starts reflecting status register content at any address. The device remains in the read status register state until another command is written to the device. Therefore there is notion of device is in "status register read mode" (FL_STATUS) state But in case of cfi_cmdset_0002, once program/erase operation is complete, device returns to previous address space overlay from which operation was started from (mostly read mode) In order to enter status register overlay mode, Read Status command is to be written to addr_unlock1(0x555) address. The overlay is in effect for one read access, specifically the next read access that follows the Status Register Read command Therefore code around FL_STATUS state in cfi_cmdset_0001 is not applicable to cfi_cmdset_0002 as is. > If so I think the new status impl. in 0002 should borrow from 0001 as this is a > hardened and battle tested impl. > In case of cfi_cmdset_0001.c, program/erase is followed by inval_cache_and_wait_for_operation() to poll ready bit and based on status register value, success or the error handling is done. Most of the code corresponding to inval_cache_and_wait_for_operation() is already in cfi_cmdset_0002.c. So, whats missing in this patch is handling and reporting of errors as reflected in status register after write/erase failures. I will add that in the next version. But, I don't see much to borrow apart from error handling sequence. Please, let me know if I missed something. > I know other modern 0002 chips supports both old and new impl. of Status and I world > guess that we will see more chips with new Status only. > Agreed. Newer devices would mostly be CFI 1.5. -- Regards Vignesh ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-25 12:57 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-25 12:57 UTC (permalink / raw) To: Joakim Tjernlund, robh+dt, computersforpeace, bbrezillon, marek.vasut, dwmw2, richard Cc: devicetree, arnd, sergei.shtylyov, tudor.ambarus, gregkh, nsekhar, linux-kernel, linux-mtd, masonccyang, linux-arm-kernel Hi, On 21/03/19 11:41 PM, Joakim Tjernlund wrote: > On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: >> >> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command >> Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c >> can be use as is. But these devices do not support DQ polling method of >> determining chip ready/good status. These flashes provide Status >> Register whose bits can be polled to know status of flash operation. >> >> Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu >> Extended Query version 1.5. Bit 0 of "Software Features supported" field >> of CFI Primary Vendor-Specific Extended Query table indicates >> presence/absence of status register and Bit 1 indicates whether or not >> DQ polling is supported. Using these bits, its possible to determine >> whether flash supports DQ polling or need to use Status Register. >> >> Add support for polling status register to know device ready/status of >> erase/write operations when DQ polling is not supported. > > Isn't this new Status scheme just a copy of Intels(cmdset_0001)? Yes, but with one difference: At the end of program/erase operation, device directly enters status register mode and starts reflecting status register content at any address. The device remains in the read status register state until another command is written to the device. Therefore there is notion of device is in "status register read mode" (FL_STATUS) state But in case of cfi_cmdset_0002, once program/erase operation is complete, device returns to previous address space overlay from which operation was started from (mostly read mode) In order to enter status register overlay mode, Read Status command is to be written to addr_unlock1(0x555) address. The overlay is in effect for one read access, specifically the next read access that follows the Status Register Read command Therefore code around FL_STATUS state in cfi_cmdset_0001 is not applicable to cfi_cmdset_0002 as is. > If so I think the new status impl. in 0002 should borrow from 0001 as this is a > hardened and battle tested impl. > In case of cfi_cmdset_0001.c, program/erase is followed by inval_cache_and_wait_for_operation() to poll ready bit and based on status register value, success or the error handling is done. Most of the code corresponding to inval_cache_and_wait_for_operation() is already in cfi_cmdset_0002.c. So, whats missing in this patch is handling and reporting of errors as reflected in status register after write/erase failures. I will add that in the next version. But, I don't see much to borrow apart from error handling sequence. Please, let me know if I missed something. > I know other modern 0002 chips supports both old and new impl. of Status and I world > guess that we will see more chips with new Status only. > Agreed. Newer devices would mostly be CFI 1.5. -- Regards Vignesh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-25 12:57 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-25 12:57 UTC (permalink / raw) To: Joakim Tjernlund, robh+dt, computersforpeace, bbrezillon, marek.vasut, dwmw2, richard Cc: devicetree, arnd, sergei.shtylyov, tudor.ambarus, gregkh, nsekhar, linux-kernel, linux-mtd, masonccyang, linux-arm-kernel Hi, On 21/03/19 11:41 PM, Joakim Tjernlund wrote: > On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: >> >> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command >> Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c >> can be use as is. But these devices do not support DQ polling method of >> determining chip ready/good status. These flashes provide Status >> Register whose bits can be polled to know status of flash operation. >> >> Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu >> Extended Query version 1.5. Bit 0 of "Software Features supported" field >> of CFI Primary Vendor-Specific Extended Query table indicates >> presence/absence of status register and Bit 1 indicates whether or not >> DQ polling is supported. Using these bits, its possible to determine >> whether flash supports DQ polling or need to use Status Register. >> >> Add support for polling status register to know device ready/status of >> erase/write operations when DQ polling is not supported. > > Isn't this new Status scheme just a copy of Intels(cmdset_0001)? Yes, but with one difference: At the end of program/erase operation, device directly enters status register mode and starts reflecting status register content at any address. The device remains in the read status register state until another command is written to the device. Therefore there is notion of device is in "status register read mode" (FL_STATUS) state But in case of cfi_cmdset_0002, once program/erase operation is complete, device returns to previous address space overlay from which operation was started from (mostly read mode) In order to enter status register overlay mode, Read Status command is to be written to addr_unlock1(0x555) address. The overlay is in effect for one read access, specifically the next read access that follows the Status Register Read command Therefore code around FL_STATUS state in cfi_cmdset_0001 is not applicable to cfi_cmdset_0002 as is. > If so I think the new status impl. in 0002 should borrow from 0001 as this is a > hardened and battle tested impl. > In case of cfi_cmdset_0001.c, program/erase is followed by inval_cache_and_wait_for_operation() to poll ready bit and based on status register value, success or the error handling is done. Most of the code corresponding to inval_cache_and_wait_for_operation() is already in cfi_cmdset_0002.c. So, whats missing in this patch is handling and reporting of errors as reflected in status register after write/erase failures. I will add that in the next version. But, I don't see much to borrow apart from error handling sequence. Please, let me know if I missed something. > I know other modern 0002 chips supports both old and new impl. of Status and I world > guess that we will see more chips with new Status only. > Agreed. Newer devices would mostly be CFI 1.5. -- Regards Vignesh ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-25 12:57 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-25 12:57 UTC (permalink / raw) To: Joakim Tjernlund, robh+dt, computersforpeace, bbrezillon, marek.vasut, dwmw2, richard Cc: devicetree, arnd, sergei.shtylyov, tudor.ambarus, gregkh, nsekhar, linux-kernel, linux-mtd, masonccyang, linux-arm-kernel Hi, On 21/03/19 11:41 PM, Joakim Tjernlund wrote: > On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: >> >> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command >> Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c >> can be use as is. But these devices do not support DQ polling method of >> determining chip ready/good status. These flashes provide Status >> Register whose bits can be polled to know status of flash operation. >> >> Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu >> Extended Query version 1.5. Bit 0 of "Software Features supported" field >> of CFI Primary Vendor-Specific Extended Query table indicates >> presence/absence of status register and Bit 1 indicates whether or not >> DQ polling is supported. Using these bits, its possible to determine >> whether flash supports DQ polling or need to use Status Register. >> >> Add support for polling status register to know device ready/status of >> erase/write operations when DQ polling is not supported. > > Isn't this new Status scheme just a copy of Intels(cmdset_0001)? Yes, but with one difference: At the end of program/erase operation, device directly enters status register mode and starts reflecting status register content at any address. The device remains in the read status register state until another command is written to the device. Therefore there is notion of device is in "status register read mode" (FL_STATUS) state But in case of cfi_cmdset_0002, once program/erase operation is complete, device returns to previous address space overlay from which operation was started from (mostly read mode) In order to enter status register overlay mode, Read Status command is to be written to addr_unlock1(0x555) address. The overlay is in effect for one read access, specifically the next read access that follows the Status Register Read command Therefore code around FL_STATUS state in cfi_cmdset_0001 is not applicable to cfi_cmdset_0002 as is. > If so I think the new status impl. in 0002 should borrow from 0001 as this is a > hardened and battle tested impl. > In case of cfi_cmdset_0001.c, program/erase is followed by inval_cache_and_wait_for_operation() to poll ready bit and based on status register value, success or the error handling is done. Most of the code corresponding to inval_cache_and_wait_for_operation() is already in cfi_cmdset_0002.c. So, whats missing in this patch is handling and reporting of errors as reflected in status register after write/erase failures. I will add that in the next version. But, I don't see much to borrow apart from error handling sequence. Please, let me know if I missed something. > I know other modern 0002 chips supports both old and new impl. of Status and I world > guess that we will see more chips with new Status only. > Agreed. Newer devices would mostly be CFI 1.5. -- Regards Vignesh ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register 2019-03-25 12:57 ` Vignesh Raghavendra (?) (?) @ 2019-03-25 13:51 ` Joakim Tjernlund -1 siblings, 0 replies; 67+ messages in thread From: Joakim Tjernlund @ 2019-03-25 13:51 UTC (permalink / raw) To: richard, computersforpeace, vigneshr, bbrezillon, marek.vasut, robh+dt, dwmw2 Cc: nsekhar, linux-kernel, linux-mtd, devicetree, masonccyang, tudor.ambarus, gregkh, sergei.shtylyov, linux-arm-kernel, arnd On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > Hi, > > On 21/03/19 11:41 PM, Joakim Tjernlund wrote: > > On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: > > > HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command > > > Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c > > > can be use as is. But these devices do not support DQ polling method of > > > determining chip ready/good status. These flashes provide Status > > > Register whose bits can be polled to know status of flash operation. > > > > > > Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu > > > Extended Query version 1.5. Bit 0 of "Software Features supported" field > > > of CFI Primary Vendor-Specific Extended Query table indicates > > > presence/absence of status register and Bit 1 indicates whether or not > > > DQ polling is supported. Using these bits, its possible to determine > > > whether flash supports DQ polling or need to use Status Register. > > > > > > Add support for polling status register to know device ready/status of > > > erase/write operations when DQ polling is not supported. > > > > Isn't this new Status scheme just a copy of Intels(cmdset_0001)? > > Yes, but with one difference: At the end of program/erase operation, > device directly enters status register mode and starts reflecting > status register content at any address. > The device remains in the read status register state until another > command is written to the device. Therefore there is notion of device is > in "status register read mode" (FL_STATUS) state That seems to vary and long time ago RMK added this: /* If the flash has finished erasing, then 'erase suspend' * appears to make some (28F320) flash devices switch to * 'read' mode. Make sure that we switch to 'read status' * mode so we get the right data. --rmk */ map_write(map, CMD(0x70), chip->in_progress_block_addr); > > But in case of cfi_cmdset_0002, once program/erase operation is > complete, device returns to previous address space overlay from which > operation was started from (mostly read mode) I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. Also, I think you need to use the various map_word_xxx as in: status = map_read(map, chip->in_progress_block_addr); if (map_word_andequal(map, status, status_OK, status_OK)) break; otherwise you will break interleaved setups(like two 8-bit flashes in parallel to form one 16 bit bus). Maybe this is not supported for CMDSET 0002 ? Jocke > > In order to enter status register overlay mode, Read Status command is > to be written to addr_unlock1(0x555) address. The overlay is in effect > for one read access, specifically the next read access that follows the > Status Register Read command > Therefore code around FL_STATUS state in cfi_cmdset_0001 is not > applicable to cfi_cmdset_0002 as is. > > > > If so I think the new status impl. in 0002 should borrow from 0001 as this is a > > hardened and battle tested impl. > > > > In case of cfi_cmdset_0001.c, program/erase is followed by > inval_cache_and_wait_for_operation() to poll ready bit and based on > status register value, success or the error handling is done. > > Most of the code corresponding to inval_cache_and_wait_for_operation() > is already in cfi_cmdset_0002.c. So, whats missing in this patch is > handling and reporting of errors as reflected in status register after > write/erase failures. I will add that in the next version. > > But, I don't see much to borrow apart from error handling sequence. > Please, let me know if I missed something. > > > I know other modern 0002 chips supports both old and new impl. of Status and I world > > guess that we will see more chips with new Status only. > > > > Agreed. Newer devices would mostly be CFI 1.5. > > -- > Regards > Vignesh ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-25 13:51 ` Joakim Tjernlund 0 siblings, 0 replies; 67+ messages in thread From: Joakim Tjernlund @ 2019-03-25 13:51 UTC (permalink / raw) To: richard, computersforpeace, vigneshr, bbrezillon, marek.vasut, robh+dt, dwmw2 Cc: devicetree, arnd, sergei.shtylyov, tudor.ambarus, gregkh, nsekhar, linux-kernel, linux-mtd, masonccyang, linux-arm-kernel On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > Hi, > > On 21/03/19 11:41 PM, Joakim Tjernlund wrote: > > On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: > > > HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command > > > Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c > > > can be use as is. But these devices do not support DQ polling method of > > > determining chip ready/good status. These flashes provide Status > > > Register whose bits can be polled to know status of flash operation. > > > > > > Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu > > > Extended Query version 1.5. Bit 0 of "Software Features supported" field > > > of CFI Primary Vendor-Specific Extended Query table indicates > > > presence/absence of status register and Bit 1 indicates whether or not > > > DQ polling is supported. Using these bits, its possible to determine > > > whether flash supports DQ polling or need to use Status Register. > > > > > > Add support for polling status register to know device ready/status of > > > erase/write operations when DQ polling is not supported. > > > > Isn't this new Status scheme just a copy of Intels(cmdset_0001)? > > Yes, but with one difference: At the end of program/erase operation, > device directly enters status register mode and starts reflecting > status register content at any address. > The device remains in the read status register state until another > command is written to the device. Therefore there is notion of device is > in "status register read mode" (FL_STATUS) state That seems to vary and long time ago RMK added this: /* If the flash has finished erasing, then 'erase suspend' * appears to make some (28F320) flash devices switch to * 'read' mode. Make sure that we switch to 'read status' * mode so we get the right data. --rmk */ map_write(map, CMD(0x70), chip->in_progress_block_addr); > > But in case of cfi_cmdset_0002, once program/erase operation is > complete, device returns to previous address space overlay from which > operation was started from (mostly read mode) I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. Also, I think you need to use the various map_word_xxx as in: status = map_read(map, chip->in_progress_block_addr); if (map_word_andequal(map, status, status_OK, status_OK)) break; otherwise you will break interleaved setups(like two 8-bit flashes in parallel to form one 16 bit bus). Maybe this is not supported for CMDSET 0002 ? Jocke > > In order to enter status register overlay mode, Read Status command is > to be written to addr_unlock1(0x555) address. The overlay is in effect > for one read access, specifically the next read access that follows the > Status Register Read command > Therefore code around FL_STATUS state in cfi_cmdset_0001 is not > applicable to cfi_cmdset_0002 as is. > > > > If so I think the new status impl. in 0002 should borrow from 0001 as this is a > > hardened and battle tested impl. > > > > In case of cfi_cmdset_0001.c, program/erase is followed by > inval_cache_and_wait_for_operation() to poll ready bit and based on > status register value, success or the error handling is done. > > Most of the code corresponding to inval_cache_and_wait_for_operation() > is already in cfi_cmdset_0002.c. So, whats missing in this patch is > handling and reporting of errors as reflected in status register after > write/erase failures. I will add that in the next version. > > But, I don't see much to borrow apart from error handling sequence. > Please, let me know if I missed something. > > > I know other modern 0002 chips supports both old and new impl. of Status and I world > > guess that we will see more chips with new Status only. > > > > Agreed. Newer devices would mostly be CFI 1.5. > > -- > Regards > Vignesh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-25 13:51 ` Joakim Tjernlund 0 siblings, 0 replies; 67+ messages in thread From: Joakim Tjernlund @ 2019-03-25 13:51 UTC (permalink / raw) To: richard, computersforpeace, vigneshr, bbrezillon, marek.vasut, robh+dt, dwmw2 Cc: devicetree, arnd, sergei.shtylyov, tudor.ambarus, gregkh, nsekhar, linux-kernel, linux-mtd, masonccyang, linux-arm-kernel On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > Hi, > > On 21/03/19 11:41 PM, Joakim Tjernlund wrote: > > On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: > > > HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command > > > Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c > > > can be use as is. But these devices do not support DQ polling method of > > > determining chip ready/good status. These flashes provide Status > > > Register whose bits can be polled to know status of flash operation. > > > > > > Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu > > > Extended Query version 1.5. Bit 0 of "Software Features supported" field > > > of CFI Primary Vendor-Specific Extended Query table indicates > > > presence/absence of status register and Bit 1 indicates whether or not > > > DQ polling is supported. Using these bits, its possible to determine > > > whether flash supports DQ polling or need to use Status Register. > > > > > > Add support for polling status register to know device ready/status of > > > erase/write operations when DQ polling is not supported. > > > > Isn't this new Status scheme just a copy of Intels(cmdset_0001)? > > Yes, but with one difference: At the end of program/erase operation, > device directly enters status register mode and starts reflecting > status register content at any address. > The device remains in the read status register state until another > command is written to the device. Therefore there is notion of device is > in "status register read mode" (FL_STATUS) state That seems to vary and long time ago RMK added this: /* If the flash has finished erasing, then 'erase suspend' * appears to make some (28F320) flash devices switch to * 'read' mode. Make sure that we switch to 'read status' * mode so we get the right data. --rmk */ map_write(map, CMD(0x70), chip->in_progress_block_addr); > > But in case of cfi_cmdset_0002, once program/erase operation is > complete, device returns to previous address space overlay from which > operation was started from (mostly read mode) I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. Also, I think you need to use the various map_word_xxx as in: status = map_read(map, chip->in_progress_block_addr); if (map_word_andequal(map, status, status_OK, status_OK)) break; otherwise you will break interleaved setups(like two 8-bit flashes in parallel to form one 16 bit bus). Maybe this is not supported for CMDSET 0002 ? Jocke > > In order to enter status register overlay mode, Read Status command is > to be written to addr_unlock1(0x555) address. The overlay is in effect > for one read access, specifically the next read access that follows the > Status Register Read command > Therefore code around FL_STATUS state in cfi_cmdset_0001 is not > applicable to cfi_cmdset_0002 as is. > > > > If so I think the new status impl. in 0002 should borrow from 0001 as this is a > > hardened and battle tested impl. > > > > In case of cfi_cmdset_0001.c, program/erase is followed by > inval_cache_and_wait_for_operation() to poll ready bit and based on > status register value, success or the error handling is done. > > Most of the code corresponding to inval_cache_and_wait_for_operation() > is already in cfi_cmdset_0002.c. So, whats missing in this patch is > handling and reporting of errors as reflected in status register after > write/erase failures. I will add that in the next version. > > But, I don't see much to borrow apart from error handling sequence. > Please, let me know if I missed something. > > > I know other modern 0002 chips supports both old and new impl. of Status and I world > > guess that we will see more chips with new Status only. > > > > Agreed. Newer devices would mostly be CFI 1.5. > > -- > Regards > Vignesh ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-25 13:51 ` Joakim Tjernlund 0 siblings, 0 replies; 67+ messages in thread From: Joakim Tjernlund @ 2019-03-25 13:51 UTC (permalink / raw) To: richard, computersforpeace, vigneshr, bbrezillon, marek.vasut, robh+dt, dwmw2 Cc: nsekhar, linux-kernel, linux-mtd, devicetree, masonccyang, tudor.ambarus, gregkh, sergei.shtylyov, linux-arm-kernel, arnd On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > Hi, > > On 21/03/19 11:41 PM, Joakim Tjernlund wrote: > > On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: > > > HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command > > > Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c > > > can be use as is. But these devices do not support DQ polling method of > > > determining chip ready/good status. These flashes provide Status > > > Register whose bits can be polled to know status of flash operation. > > > > > > Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu > > > Extended Query version 1.5. Bit 0 of "Software Features supported" field > > > of CFI Primary Vendor-Specific Extended Query table indicates > > > presence/absence of status register and Bit 1 indicates whether or not > > > DQ polling is supported. Using these bits, its possible to determine > > > whether flash supports DQ polling or need to use Status Register. > > > > > > Add support for polling status register to know device ready/status of > > > erase/write operations when DQ polling is not supported. > > > > Isn't this new Status scheme just a copy of Intels(cmdset_0001)? > > Yes, but with one difference: At the end of program/erase operation, > device directly enters status register mode and starts reflecting > status register content at any address. > The device remains in the read status register state until another > command is written to the device. Therefore there is notion of device is > in "status register read mode" (FL_STATUS) state That seems to vary and long time ago RMK added this: /* If the flash has finished erasing, then 'erase suspend' * appears to make some (28F320) flash devices switch to * 'read' mode. Make sure that we switch to 'read status' * mode so we get the right data. --rmk */ map_write(map, CMD(0x70), chip->in_progress_block_addr); > > But in case of cfi_cmdset_0002, once program/erase operation is > complete, device returns to previous address space overlay from which > operation was started from (mostly read mode) I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. Also, I think you need to use the various map_word_xxx as in: status = map_read(map, chip->in_progress_block_addr); if (map_word_andequal(map, status, status_OK, status_OK)) break; otherwise you will break interleaved setups(like two 8-bit flashes in parallel to form one 16 bit bus). Maybe this is not supported for CMDSET 0002 ? Jocke > > In order to enter status register overlay mode, Read Status command is > to be written to addr_unlock1(0x555) address. The overlay is in effect > for one read access, specifically the next read access that follows the > Status Register Read command > Therefore code around FL_STATUS state in cfi_cmdset_0001 is not > applicable to cfi_cmdset_0002 as is. > > > > If so I think the new status impl. in 0002 should borrow from 0001 as this is a > > hardened and battle tested impl. > > > > In case of cfi_cmdset_0001.c, program/erase is followed by > inval_cache_and_wait_for_operation() to poll ready bit and based on > status register value, success or the error handling is done. > > Most of the code corresponding to inval_cache_and_wait_for_operation() > is already in cfi_cmdset_0002.c. So, whats missing in this patch is > handling and reporting of errors as reflected in status register after > write/erase failures. I will add that in the next version. > > But, I don't see much to borrow apart from error handling sequence. > Please, let me know if I missed something. > > > I know other modern 0002 chips supports both old and new impl. of Status and I world > > guess that we will see more chips with new Status only. > > > > Agreed. Newer devices would mostly be CFI 1.5. > > -- > Regards > Vignesh ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register 2019-03-25 13:51 ` Joakim Tjernlund (?) (?) @ 2019-03-25 17:06 ` Vignesh Raghavendra -1 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-25 17:06 UTC (permalink / raw) To: Joakim Tjernlund, richard, computersforpeace, bbrezillon, marek.vasut, robh+dt, dwmw2 Cc: Nori, Sekhar, linux-kernel, linux-mtd, devicetree, masonccyang, tudor.ambarus, gregkh, sergei.shtylyov, linux-arm-kernel, arnd On 25/03/19 7:21 PM, Joakim Tjernlund wrote: > On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >> >> >> Hi, >> >> On 21/03/19 11:41 PM, Joakim Tjernlund wrote: >>> On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: >>>> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command >>>> Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c >>>> can be use as is. But these devices do not support DQ polling method of >>>> determining chip ready/good status. These flashes provide Status >>>> Register whose bits can be polled to know status of flash operation. >>>> >>>> Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu >>>> Extended Query version 1.5. Bit 0 of "Software Features supported" field >>>> of CFI Primary Vendor-Specific Extended Query table indicates >>>> presence/absence of status register and Bit 1 indicates whether or not >>>> DQ polling is supported. Using these bits, its possible to determine >>>> whether flash supports DQ polling or need to use Status Register. >>>> >>>> Add support for polling status register to know device ready/status of >>>> erase/write operations when DQ polling is not supported. >>> >>> Isn't this new Status scheme just a copy of Intels(cmdset_0001)? >> >> Yes, but with one difference: At the end of program/erase operation, >> device directly enters status register mode and starts reflecting >> status register content at any address. >> The device remains in the read status register state until another >> command is written to the device. Therefore there is notion of device is >> in "status register read mode" (FL_STATUS) state > > That seems to vary and long time ago RMK added this: > /* If the flash has finished erasing, then 'erase suspend' > * appears to make some (28F320) flash devices switch to > * 'read' mode. Make sure that we switch to 'read status' > * mode so we get the right data. --rmk > */ > map_write(map, CMD(0x70), chip->in_progress_block_addr); > This behavior is expected with cmdset_0001. Because "The device remains in the read status register state until another command is written", therefore "erase suspend' command after erase completion will switch device to read mode. And therefore read status is safe thing to do for cmdset_0001. But in case of cmdset_0002 erase completion will not put device to read status mode and therefore no special status tracking is required. >> >> But in case of cfi_cmdset_0002, once program/erase operation is >> complete, device returns to previous address space overlay from which >> operation was started from (mostly read mode) > > I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. Even if we issue Read Status command to enter read status mode, any single subsequent read will put device back to read mode. So, sending explicit Status CMD is of not much use. As long as cmdset_0002 driver ensures sending Read Status cmd and next single read can be done in one go (ie. mutex held), I don't see any trouble here. This is already take care off. > > Also, I think you need to use the various map_word_xxx as in: > status = map_read(map, chip->in_progress_block_addr); > if (map_word_andequal(map, status, status_OK, status_OK)) > break; Yes, I will fixup this patch to use map_word_* wherever necessary in the next revision. > otherwise you will break interleaved setups(like two 8-bit flashes in parallel to > form one 16 bit bus). Maybe this is not supported for CMDSET 0002 ? > Interleaved is indeed supported by cmdset_0002. Thanks for pointing that out! > Jocke > >> >> In order to enter status register overlay mode, Read Status command is >> to be written to addr_unlock1(0x555) address. The overlay is in effect >> for one read access, specifically the next read access that follows the >> Status Register Read command >> Therefore code around FL_STATUS state in cfi_cmdset_0001 is not >> applicable to cfi_cmdset_0002 as is. >> >> >>> If so I think the new status impl. in 0002 should borrow from 0001 as this is a >>> hardened and battle tested impl. >>> >> >> In case of cfi_cmdset_0001.c, program/erase is followed by >> inval_cache_and_wait_for_operation() to poll ready bit and based on >> status register value, success or the error handling is done. >> >> Most of the code corresponding to inval_cache_and_wait_for_operation() >> is already in cfi_cmdset_0002.c. So, whats missing in this patch is >> handling and reporting of errors as reflected in status register after >> write/erase failures. I will add that in the next version. >> >> But, I don't see much to borrow apart from error handling sequence. >> Please, let me know if I missed something. >> >>> I know other modern 0002 chips supports both old and new impl. of Status and I world >>> guess that we will see more chips with new Status only. >>> >> >> Agreed. Newer devices would mostly be CFI 1.5. >> >> -- >> Regards >> Vignesh > -- Regards Vignesh ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-25 17:06 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-25 17:06 UTC (permalink / raw) To: Joakim Tjernlund, richard, computersforpeace, bbrezillon, marek.vasut, robh+dt, dwmw2 Cc: devicetree, arnd, sergei.shtylyov, tudor.ambarus, gregkh, Nori, Sekhar, linux-kernel, linux-mtd, masonccyang, linux-arm-kernel On 25/03/19 7:21 PM, Joakim Tjernlund wrote: > On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >> >> >> Hi, >> >> On 21/03/19 11:41 PM, Joakim Tjernlund wrote: >>> On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: >>>> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command >>>> Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c >>>> can be use as is. But these devices do not support DQ polling method of >>>> determining chip ready/good status. These flashes provide Status >>>> Register whose bits can be polled to know status of flash operation. >>>> >>>> Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu >>>> Extended Query version 1.5. Bit 0 of "Software Features supported" field >>>> of CFI Primary Vendor-Specific Extended Query table indicates >>>> presence/absence of status register and Bit 1 indicates whether or not >>>> DQ polling is supported. Using these bits, its possible to determine >>>> whether flash supports DQ polling or need to use Status Register. >>>> >>>> Add support for polling status register to know device ready/status of >>>> erase/write operations when DQ polling is not supported. >>> >>> Isn't this new Status scheme just a copy of Intels(cmdset_0001)? >> >> Yes, but with one difference: At the end of program/erase operation, >> device directly enters status register mode and starts reflecting >> status register content at any address. >> The device remains in the read status register state until another >> command is written to the device. Therefore there is notion of device is >> in "status register read mode" (FL_STATUS) state > > That seems to vary and long time ago RMK added this: > /* If the flash has finished erasing, then 'erase suspend' > * appears to make some (28F320) flash devices switch to > * 'read' mode. Make sure that we switch to 'read status' > * mode so we get the right data. --rmk > */ > map_write(map, CMD(0x70), chip->in_progress_block_addr); > This behavior is expected with cmdset_0001. Because "The device remains in the read status register state until another command is written", therefore "erase suspend' command after erase completion will switch device to read mode. And therefore read status is safe thing to do for cmdset_0001. But in case of cmdset_0002 erase completion will not put device to read status mode and therefore no special status tracking is required. >> >> But in case of cfi_cmdset_0002, once program/erase operation is >> complete, device returns to previous address space overlay from which >> operation was started from (mostly read mode) > > I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. Even if we issue Read Status command to enter read status mode, any single subsequent read will put device back to read mode. So, sending explicit Status CMD is of not much use. As long as cmdset_0002 driver ensures sending Read Status cmd and next single read can be done in one go (ie. mutex held), I don't see any trouble here. This is already take care off. > > Also, I think you need to use the various map_word_xxx as in: > status = map_read(map, chip->in_progress_block_addr); > if (map_word_andequal(map, status, status_OK, status_OK)) > break; Yes, I will fixup this patch to use map_word_* wherever necessary in the next revision. > otherwise you will break interleaved setups(like two 8-bit flashes in parallel to > form one 16 bit bus). Maybe this is not supported for CMDSET 0002 ? > Interleaved is indeed supported by cmdset_0002. Thanks for pointing that out! > Jocke > >> >> In order to enter status register overlay mode, Read Status command is >> to be written to addr_unlock1(0x555) address. The overlay is in effect >> for one read access, specifically the next read access that follows the >> Status Register Read command >> Therefore code around FL_STATUS state in cfi_cmdset_0001 is not >> applicable to cfi_cmdset_0002 as is. >> >> >>> If so I think the new status impl. in 0002 should borrow from 0001 as this is a >>> hardened and battle tested impl. >>> >> >> In case of cfi_cmdset_0001.c, program/erase is followed by >> inval_cache_and_wait_for_operation() to poll ready bit and based on >> status register value, success or the error handling is done. >> >> Most of the code corresponding to inval_cache_and_wait_for_operation() >> is already in cfi_cmdset_0002.c. So, whats missing in this patch is >> handling and reporting of errors as reflected in status register after >> write/erase failures. I will add that in the next version. >> >> But, I don't see much to borrow apart from error handling sequence. >> Please, let me know if I missed something. >> >>> I know other modern 0002 chips supports both old and new impl. of Status and I world >>> guess that we will see more chips with new Status only. >>> >> >> Agreed. Newer devices would mostly be CFI 1.5. >> >> -- >> Regards >> Vignesh > -- Regards Vignesh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-25 17:06 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-25 17:06 UTC (permalink / raw) To: Joakim Tjernlund, richard, computersforpeace, bbrezillon, marek.vasut, robh+dt, dwmw2 Cc: devicetree, arnd, sergei.shtylyov, tudor.ambarus, gregkh, Nori, Sekhar, linux-kernel, linux-mtd, masonccyang, linux-arm-kernel On 25/03/19 7:21 PM, Joakim Tjernlund wrote: > On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >> >> >> Hi, >> >> On 21/03/19 11:41 PM, Joakim Tjernlund wrote: >>> On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: >>>> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command >>>> Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c >>>> can be use as is. But these devices do not support DQ polling method of >>>> determining chip ready/good status. These flashes provide Status >>>> Register whose bits can be polled to know status of flash operation. >>>> >>>> Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu >>>> Extended Query version 1.5. Bit 0 of "Software Features supported" field >>>> of CFI Primary Vendor-Specific Extended Query table indicates >>>> presence/absence of status register and Bit 1 indicates whether or not >>>> DQ polling is supported. Using these bits, its possible to determine >>>> whether flash supports DQ polling or need to use Status Register. >>>> >>>> Add support for polling status register to know device ready/status of >>>> erase/write operations when DQ polling is not supported. >>> >>> Isn't this new Status scheme just a copy of Intels(cmdset_0001)? >> >> Yes, but with one difference: At the end of program/erase operation, >> device directly enters status register mode and starts reflecting >> status register content at any address. >> The device remains in the read status register state until another >> command is written to the device. Therefore there is notion of device is >> in "status register read mode" (FL_STATUS) state > > That seems to vary and long time ago RMK added this: > /* If the flash has finished erasing, then 'erase suspend' > * appears to make some (28F320) flash devices switch to > * 'read' mode. Make sure that we switch to 'read status' > * mode so we get the right data. --rmk > */ > map_write(map, CMD(0x70), chip->in_progress_block_addr); > This behavior is expected with cmdset_0001. Because "The device remains in the read status register state until another command is written", therefore "erase suspend' command after erase completion will switch device to read mode. And therefore read status is safe thing to do for cmdset_0001. But in case of cmdset_0002 erase completion will not put device to read status mode and therefore no special status tracking is required. >> >> But in case of cfi_cmdset_0002, once program/erase operation is >> complete, device returns to previous address space overlay from which >> operation was started from (mostly read mode) > > I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. Even if we issue Read Status command to enter read status mode, any single subsequent read will put device back to read mode. So, sending explicit Status CMD is of not much use. As long as cmdset_0002 driver ensures sending Read Status cmd and next single read can be done in one go (ie. mutex held), I don't see any trouble here. This is already take care off. > > Also, I think you need to use the various map_word_xxx as in: > status = map_read(map, chip->in_progress_block_addr); > if (map_word_andequal(map, status, status_OK, status_OK)) > break; Yes, I will fixup this patch to use map_word_* wherever necessary in the next revision. > otherwise you will break interleaved setups(like two 8-bit flashes in parallel to > form one 16 bit bus). Maybe this is not supported for CMDSET 0002 ? > Interleaved is indeed supported by cmdset_0002. Thanks for pointing that out! > Jocke > >> >> In order to enter status register overlay mode, Read Status command is >> to be written to addr_unlock1(0x555) address. The overlay is in effect >> for one read access, specifically the next read access that follows the >> Status Register Read command >> Therefore code around FL_STATUS state in cfi_cmdset_0001 is not >> applicable to cfi_cmdset_0002 as is. >> >> >>> If so I think the new status impl. in 0002 should borrow from 0001 as this is a >>> hardened and battle tested impl. >>> >> >> In case of cfi_cmdset_0001.c, program/erase is followed by >> inval_cache_and_wait_for_operation() to poll ready bit and based on >> status register value, success or the error handling is done. >> >> Most of the code corresponding to inval_cache_and_wait_for_operation() >> is already in cfi_cmdset_0002.c. So, whats missing in this patch is >> handling and reporting of errors as reflected in status register after >> write/erase failures. I will add that in the next version. >> >> But, I don't see much to borrow apart from error handling sequence. >> Please, let me know if I missed something. >> >>> I know other modern 0002 chips supports both old and new impl. of Status and I world >>> guess that we will see more chips with new Status only. >>> >> >> Agreed. Newer devices would mostly be CFI 1.5. >> >> -- >> Regards >> Vignesh > -- Regards Vignesh ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-25 17:06 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-25 17:06 UTC (permalink / raw) To: Joakim Tjernlund, richard, computersforpeace, bbrezillon, marek.vasut, robh+dt, dwmw2 Cc: Nori, Sekhar, linux-kernel, linux-mtd, devicetree, masonccyang, tudor.ambarus, gregkh, sergei.shtylyov, linux-arm-kernel, arnd On 25/03/19 7:21 PM, Joakim Tjernlund wrote: > On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: >> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >> >> >> Hi, >> >> On 21/03/19 11:41 PM, Joakim Tjernlund wrote: >>> On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: >>>> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command >>>> Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c >>>> can be use as is. But these devices do not support DQ polling method of >>>> determining chip ready/good status. These flashes provide Status >>>> Register whose bits can be polled to know status of flash operation. >>>> >>>> Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu >>>> Extended Query version 1.5. Bit 0 of "Software Features supported" field >>>> of CFI Primary Vendor-Specific Extended Query table indicates >>>> presence/absence of status register and Bit 1 indicates whether or not >>>> DQ polling is supported. Using these bits, its possible to determine >>>> whether flash supports DQ polling or need to use Status Register. >>>> >>>> Add support for polling status register to know device ready/status of >>>> erase/write operations when DQ polling is not supported. >>> >>> Isn't this new Status scheme just a copy of Intels(cmdset_0001)? >> >> Yes, but with one difference: At the end of program/erase operation, >> device directly enters status register mode and starts reflecting >> status register content at any address. >> The device remains in the read status register state until another >> command is written to the device. Therefore there is notion of device is >> in "status register read mode" (FL_STATUS) state > > That seems to vary and long time ago RMK added this: > /* If the flash has finished erasing, then 'erase suspend' > * appears to make some (28F320) flash devices switch to > * 'read' mode. Make sure that we switch to 'read status' > * mode so we get the right data. --rmk > */ > map_write(map, CMD(0x70), chip->in_progress_block_addr); > This behavior is expected with cmdset_0001. Because "The device remains in the read status register state until another command is written", therefore "erase suspend' command after erase completion will switch device to read mode. And therefore read status is safe thing to do for cmdset_0001. But in case of cmdset_0002 erase completion will not put device to read status mode and therefore no special status tracking is required. >> >> But in case of cfi_cmdset_0002, once program/erase operation is >> complete, device returns to previous address space overlay from which >> operation was started from (mostly read mode) > > I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. Even if we issue Read Status command to enter read status mode, any single subsequent read will put device back to read mode. So, sending explicit Status CMD is of not much use. As long as cmdset_0002 driver ensures sending Read Status cmd and next single read can be done in one go (ie. mutex held), I don't see any trouble here. This is already take care off. > > Also, I think you need to use the various map_word_xxx as in: > status = map_read(map, chip->in_progress_block_addr); > if (map_word_andequal(map, status, status_OK, status_OK)) > break; Yes, I will fixup this patch to use map_word_* wherever necessary in the next revision. > otherwise you will break interleaved setups(like two 8-bit flashes in parallel to > form one 16 bit bus). Maybe this is not supported for CMDSET 0002 ? > Interleaved is indeed supported by cmdset_0002. Thanks for pointing that out! > Jocke > >> >> In order to enter status register overlay mode, Read Status command is >> to be written to addr_unlock1(0x555) address. The overlay is in effect >> for one read access, specifically the next read access that follows the >> Status Register Read command >> Therefore code around FL_STATUS state in cfi_cmdset_0001 is not >> applicable to cfi_cmdset_0002 as is. >> >> >>> If so I think the new status impl. in 0002 should borrow from 0001 as this is a >>> hardened and battle tested impl. >>> >> >> In case of cfi_cmdset_0001.c, program/erase is followed by >> inval_cache_and_wait_for_operation() to poll ready bit and based on >> status register value, success or the error handling is done. >> >> Most of the code corresponding to inval_cache_and_wait_for_operation() >> is already in cfi_cmdset_0002.c. So, whats missing in this patch is >> handling and reporting of errors as reflected in status register after >> write/erase failures. I will add that in the next version. >> >> But, I don't see much to borrow apart from error handling sequence. >> Please, let me know if I missed something. >> >>> I know other modern 0002 chips supports both old and new impl. of Status and I world >>> guess that we will see more chips with new Status only. >>> >> >> Agreed. Newer devices would mostly be CFI 1.5. >> >> -- >> Regards >> Vignesh > -- Regards Vignesh ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register 2019-03-25 17:06 ` Vignesh Raghavendra (?) (?) @ 2019-03-25 17:24 ` Joakim Tjernlund -1 siblings, 0 replies; 67+ messages in thread From: Joakim Tjernlund @ 2019-03-25 17:24 UTC (permalink / raw) To: dwmw2, computersforpeace, vigneshr, bbrezillon, marek.vasut, richard, robh+dt Cc: nsekhar, linux-kernel, linux-mtd, devicetree, masonccyang, tudor.ambarus, sergei.shtylyov, gregkh, linux-arm-kernel, arnd On Mon, 2019-03-25 at 22:36 +0530, Vignesh Raghavendra wrote: > > On 25/03/19 7:21 PM, Joakim Tjernlund wrote: > > On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > > > > > > Hi, > > > > > > On 21/03/19 11:41 PM, Joakim Tjernlund wrote: > > > > On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: > > > > > HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command > > > > > Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c > > > > > can be use as is. But these devices do not support DQ polling method of > > > > > determining chip ready/good status. These flashes provide Status > > > > > Register whose bits can be polled to know status of flash operation. > > > > > > > > > > Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu > > > > > Extended Query version 1.5. Bit 0 of "Software Features supported" field > > > > > of CFI Primary Vendor-Specific Extended Query table indicates > > > > > presence/absence of status register and Bit 1 indicates whether or not > > > > > DQ polling is supported. Using these bits, its possible to determine > > > > > whether flash supports DQ polling or need to use Status Register. > > > > > > > > > > Add support for polling status register to know device ready/status of > > > > > erase/write operations when DQ polling is not supported. > > > > > > > > Isn't this new Status scheme just a copy of Intels(cmdset_0001)? > > > > > > Yes, but with one difference: At the end of program/erase operation, > > > device directly enters status register mode and starts reflecting > > > status register content at any address. > > > The device remains in the read status register state until another > > > command is written to the device. Therefore there is notion of device is > > > in "status register read mode" (FL_STATUS) state > > > > That seems to vary and long time ago RMK added this: > > /* If the flash has finished erasing, then 'erase suspend' > > * appears to make some (28F320) flash devices switch to > > * 'read' mode. Make sure that we switch to 'read status' > > * mode so we get the right data. --rmk > > */ > > map_write(map, CMD(0x70), chip->in_progress_block_addr); > > > > This behavior is expected with cmdset_0001. Because "The device remains > in the read status register state until another command is written", > therefore "erase suspend' command after erase completion will switch > device to read mode. And therefore read status is safe thing to do for > cmdset_0001. > > But in case of cmdset_0002 erase completion will not put device to read > status mode and therefore no special status tracking is required. > > > > But in case of cfi_cmdset_0002, once program/erase operation is > > > complete, device returns to previous address space overlay from which > > > operation was started from (mostly read mode) > > > > I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. > > Even if we issue Read Status command to enter read status mode, any > single subsequent read will put device back to read mode. So, sending > explicit Status CMD is of not much use. > > As long as cmdset_0002 driver ensures sending Read Status cmd and next > single read can be done in one go (ie. mutex held), I don't see any > trouble here. This is already take care off. Ouch, a non sticky Status sounds borken. Are you sure that nothing can change the chip between you issue the Status CMD and read out of status bits? Like if an erase/suspend/resume completes just after Status CMD but before Status readout? Jocke > > > Also, I think you need to use the various map_word_xxx as in: > > status = map_read(map, chip->in_progress_block_addr); > > if (map_word_andequal(map, status, status_OK, status_OK)) > > break; > > Yes, I will fixup this patch to use map_word_* wherever necessary in the > next revision. > > > > otherwise you will break interleaved setups(like two 8-bit flashes in parallel to > > form one 16 bit bus). Maybe this is not supported for CMDSET 0002 ? > > > > Interleaved is indeed supported by cmdset_0002. Thanks for pointing that > out! > > > Jocke > > > > > In order to enter status register overlay mode, Read Status command is > > > to be written to addr_unlock1(0x555) address. The overlay is in effect > > > for one read access, specifically the next read access that follows the > > > Status Register Read command > > > Therefore code around FL_STATUS state in cfi_cmdset_0001 is not > > > applicable to cfi_cmdset_0002 as is. > > > > > > > > > > If so I think the new status impl. in 0002 should borrow from 0001 as this is a > > > > hardened and battle tested impl. > > > > > > > > > > In case of cfi_cmdset_0001.c, program/erase is followed by > > > inval_cache_and_wait_for_operation() to poll ready bit and based on > > > status register value, success or the error handling is done. > > > > > > Most of the code corresponding to inval_cache_and_wait_for_operation() > > > is already in cfi_cmdset_0002.c. So, whats missing in this patch is > > > handling and reporting of errors as reflected in status register after > > > write/erase failures. I will add that in the next version. > > > > > > But, I don't see much to borrow apart from error handling sequence. > > > Please, let me know if I missed something. > > > > > > > I know other modern 0002 chips supports both old and new impl. of Status and I world > > > > guess that we will see more chips with new Status only. > > > > > > > > > > Agreed. Newer devices would mostly be CFI 1.5. > > > > > > -- > > > Regards > > > Vignesh ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-25 17:24 ` Joakim Tjernlund 0 siblings, 0 replies; 67+ messages in thread From: Joakim Tjernlund @ 2019-03-25 17:24 UTC (permalink / raw) To: dwmw2, computersforpeace, vigneshr, bbrezillon, marek.vasut, richard, robh+dt Cc: devicetree, arnd, sergei.shtylyov, tudor.ambarus, gregkh, nsekhar, linux-kernel, linux-mtd, masonccyang, linux-arm-kernel On Mon, 2019-03-25 at 22:36 +0530, Vignesh Raghavendra wrote: > > On 25/03/19 7:21 PM, Joakim Tjernlund wrote: > > On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > > > > > > Hi, > > > > > > On 21/03/19 11:41 PM, Joakim Tjernlund wrote: > > > > On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: > > > > > HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command > > > > > Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c > > > > > can be use as is. But these devices do not support DQ polling method of > > > > > determining chip ready/good status. These flashes provide Status > > > > > Register whose bits can be polled to know status of flash operation. > > > > > > > > > > Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu > > > > > Extended Query version 1.5. Bit 0 of "Software Features supported" field > > > > > of CFI Primary Vendor-Specific Extended Query table indicates > > > > > presence/absence of status register and Bit 1 indicates whether or not > > > > > DQ polling is supported. Using these bits, its possible to determine > > > > > whether flash supports DQ polling or need to use Status Register. > > > > > > > > > > Add support for polling status register to know device ready/status of > > > > > erase/write operations when DQ polling is not supported. > > > > > > > > Isn't this new Status scheme just a copy of Intels(cmdset_0001)? > > > > > > Yes, but with one difference: At the end of program/erase operation, > > > device directly enters status register mode and starts reflecting > > > status register content at any address. > > > The device remains in the read status register state until another > > > command is written to the device. Therefore there is notion of device is > > > in "status register read mode" (FL_STATUS) state > > > > That seems to vary and long time ago RMK added this: > > /* If the flash has finished erasing, then 'erase suspend' > > * appears to make some (28F320) flash devices switch to > > * 'read' mode. Make sure that we switch to 'read status' > > * mode so we get the right data. --rmk > > */ > > map_write(map, CMD(0x70), chip->in_progress_block_addr); > > > > This behavior is expected with cmdset_0001. Because "The device remains > in the read status register state until another command is written", > therefore "erase suspend' command after erase completion will switch > device to read mode. And therefore read status is safe thing to do for > cmdset_0001. > > But in case of cmdset_0002 erase completion will not put device to read > status mode and therefore no special status tracking is required. > > > > But in case of cfi_cmdset_0002, once program/erase operation is > > > complete, device returns to previous address space overlay from which > > > operation was started from (mostly read mode) > > > > I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. > > Even if we issue Read Status command to enter read status mode, any > single subsequent read will put device back to read mode. So, sending > explicit Status CMD is of not much use. > > As long as cmdset_0002 driver ensures sending Read Status cmd and next > single read can be done in one go (ie. mutex held), I don't see any > trouble here. This is already take care off. Ouch, a non sticky Status sounds borken. Are you sure that nothing can change the chip between you issue the Status CMD and read out of status bits? Like if an erase/suspend/resume completes just after Status CMD but before Status readout? Jocke > > > Also, I think you need to use the various map_word_xxx as in: > > status = map_read(map, chip->in_progress_block_addr); > > if (map_word_andequal(map, status, status_OK, status_OK)) > > break; > > Yes, I will fixup this patch to use map_word_* wherever necessary in the > next revision. > > > > otherwise you will break interleaved setups(like two 8-bit flashes in parallel to > > form one 16 bit bus). Maybe this is not supported for CMDSET 0002 ? > > > > Interleaved is indeed supported by cmdset_0002. Thanks for pointing that > out! > > > Jocke > > > > > In order to enter status register overlay mode, Read Status command is > > > to be written to addr_unlock1(0x555) address. The overlay is in effect > > > for one read access, specifically the next read access that follows the > > > Status Register Read command > > > Therefore code around FL_STATUS state in cfi_cmdset_0001 is not > > > applicable to cfi_cmdset_0002 as is. > > > > > > > > > > If so I think the new status impl. in 0002 should borrow from 0001 as this is a > > > > hardened and battle tested impl. > > > > > > > > > > In case of cfi_cmdset_0001.c, program/erase is followed by > > > inval_cache_and_wait_for_operation() to poll ready bit and based on > > > status register value, success or the error handling is done. > > > > > > Most of the code corresponding to inval_cache_and_wait_for_operation() > > > is already in cfi_cmdset_0002.c. So, whats missing in this patch is > > > handling and reporting of errors as reflected in status register after > > > write/erase failures. I will add that in the next version. > > > > > > But, I don't see much to borrow apart from error handling sequence. > > > Please, let me know if I missed something. > > > > > > > I know other modern 0002 chips supports both old and new impl. of Status and I world > > > > guess that we will see more chips with new Status only. > > > > > > > > > > Agreed. Newer devices would mostly be CFI 1.5. > > > > > > -- > > > Regards > > > Vignesh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-25 17:24 ` Joakim Tjernlund 0 siblings, 0 replies; 67+ messages in thread From: Joakim Tjernlund @ 2019-03-25 17:24 UTC (permalink / raw) To: dwmw2, computersforpeace, vigneshr, bbrezillon, marek.vasut, richard, robh+dt Cc: devicetree, arnd, sergei.shtylyov, tudor.ambarus, gregkh, nsekhar, linux-kernel, linux-mtd, masonccyang, linux-arm-kernel On Mon, 2019-03-25 at 22:36 +0530, Vignesh Raghavendra wrote: > > On 25/03/19 7:21 PM, Joakim Tjernlund wrote: > > On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > > > > > > Hi, > > > > > > On 21/03/19 11:41 PM, Joakim Tjernlund wrote: > > > > On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: > > > > > HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command > > > > > Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c > > > > > can be use as is. But these devices do not support DQ polling method of > > > > > determining chip ready/good status. These flashes provide Status > > > > > Register whose bits can be polled to know status of flash operation. > > > > > > > > > > Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu > > > > > Extended Query version 1.5. Bit 0 of "Software Features supported" field > > > > > of CFI Primary Vendor-Specific Extended Query table indicates > > > > > presence/absence of status register and Bit 1 indicates whether or not > > > > > DQ polling is supported. Using these bits, its possible to determine > > > > > whether flash supports DQ polling or need to use Status Register. > > > > > > > > > > Add support for polling status register to know device ready/status of > > > > > erase/write operations when DQ polling is not supported. > > > > > > > > Isn't this new Status scheme just a copy of Intels(cmdset_0001)? > > > > > > Yes, but with one difference: At the end of program/erase operation, > > > device directly enters status register mode and starts reflecting > > > status register content at any address. > > > The device remains in the read status register state until another > > > command is written to the device. Therefore there is notion of device is > > > in "status register read mode" (FL_STATUS) state > > > > That seems to vary and long time ago RMK added this: > > /* If the flash has finished erasing, then 'erase suspend' > > * appears to make some (28F320) flash devices switch to > > * 'read' mode. Make sure that we switch to 'read status' > > * mode so we get the right data. --rmk > > */ > > map_write(map, CMD(0x70), chip->in_progress_block_addr); > > > > This behavior is expected with cmdset_0001. Because "The device remains > in the read status register state until another command is written", > therefore "erase suspend' command after erase completion will switch > device to read mode. And therefore read status is safe thing to do for > cmdset_0001. > > But in case of cmdset_0002 erase completion will not put device to read > status mode and therefore no special status tracking is required. > > > > But in case of cfi_cmdset_0002, once program/erase operation is > > > complete, device returns to previous address space overlay from which > > > operation was started from (mostly read mode) > > > > I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. > > Even if we issue Read Status command to enter read status mode, any > single subsequent read will put device back to read mode. So, sending > explicit Status CMD is of not much use. > > As long as cmdset_0002 driver ensures sending Read Status cmd and next > single read can be done in one go (ie. mutex held), I don't see any > trouble here. This is already take care off. Ouch, a non sticky Status sounds borken. Are you sure that nothing can change the chip between you issue the Status CMD and read out of status bits? Like if an erase/suspend/resume completes just after Status CMD but before Status readout? Jocke > > > Also, I think you need to use the various map_word_xxx as in: > > status = map_read(map, chip->in_progress_block_addr); > > if (map_word_andequal(map, status, status_OK, status_OK)) > > break; > > Yes, I will fixup this patch to use map_word_* wherever necessary in the > next revision. > > > > otherwise you will break interleaved setups(like two 8-bit flashes in parallel to > > form one 16 bit bus). Maybe this is not supported for CMDSET 0002 ? > > > > Interleaved is indeed supported by cmdset_0002. Thanks for pointing that > out! > > > Jocke > > > > > In order to enter status register overlay mode, Read Status command is > > > to be written to addr_unlock1(0x555) address. The overlay is in effect > > > for one read access, specifically the next read access that follows the > > > Status Register Read command > > > Therefore code around FL_STATUS state in cfi_cmdset_0001 is not > > > applicable to cfi_cmdset_0002 as is. > > > > > > > > > > If so I think the new status impl. in 0002 should borrow from 0001 as this is a > > > > hardened and battle tested impl. > > > > > > > > > > In case of cfi_cmdset_0001.c, program/erase is followed by > > > inval_cache_and_wait_for_operation() to poll ready bit and based on > > > status register value, success or the error handling is done. > > > > > > Most of the code corresponding to inval_cache_and_wait_for_operation() > > > is already in cfi_cmdset_0002.c. So, whats missing in this patch is > > > handling and reporting of errors as reflected in status register after > > > write/erase failures. I will add that in the next version. > > > > > > But, I don't see much to borrow apart from error handling sequence. > > > Please, let me know if I missed something. > > > > > > > I know other modern 0002 chips supports both old and new impl. of Status and I world > > > > guess that we will see more chips with new Status only. > > > > > > > > > > Agreed. Newer devices would mostly be CFI 1.5. > > > > > > -- > > > Regards > > > Vignesh ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-25 17:24 ` Joakim Tjernlund 0 siblings, 0 replies; 67+ messages in thread From: Joakim Tjernlund @ 2019-03-25 17:24 UTC (permalink / raw) To: dwmw2, computersforpeace, vigneshr, bbrezillon, marek.vasut, richard, robh+dt Cc: devicetree, arnd, sergei.shtylyov, tudor.ambarus, gregkh, nsekhar, linux-kernel, linux-mtd, masonccyang, linux-arm-kernel On Mon, 2019-03-25 at 22:36 +0530, Vignesh Raghavendra wrote: > > On 25/03/19 7:21 PM, Joakim Tjernlund wrote: > > On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: > > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > > > > > > > > > Hi, > > > > > > On 21/03/19 11:41 PM, Joakim Tjernlund wrote: > > > > On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: > > > > > HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command > > > > > Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c > > > > > can be use as is. But these devices do not support DQ polling method of > > > > > determining chip ready/good status. These flashes provide Status > > > > > Register whose bits can be polled to know status of flash operation. > > > > > > > > > > Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu > > > > > Extended Query version 1.5. Bit 0 of "Software Features supported" field > > > > > of CFI Primary Vendor-Specific Extended Query table indicates > > > > > presence/absence of status register and Bit 1 indicates whether or not > > > > > DQ polling is supported. Using these bits, its possible to determine > > > > > whether flash supports DQ polling or need to use Status Register. > > > > > > > > > > Add support for polling status register to know device ready/status of > > > > > erase/write operations when DQ polling is not supported. > > > > > > > > Isn't this new Status scheme just a copy of Intels(cmdset_0001)? > > > > > > Yes, but with one difference: At the end of program/erase operation, > > > device directly enters status register mode and starts reflecting > > > status register content at any address. > > > The device remains in the read status register state until another > > > command is written to the device. Therefore there is notion of device is > > > in "status register read mode" (FL_STATUS) state > > > > That seems to vary and long time ago RMK added this: > > /* If the flash has finished erasing, then 'erase suspend' > > * appears to make some (28F320) flash devices switch to > > * 'read' mode. Make sure that we switch to 'read status' > > * mode so we get the right data. --rmk > > */ > > map_write(map, CMD(0x70), chip->in_progress_block_addr); > > > > This behavior is expected with cmdset_0001. Because "The device remains > in the read status register state until another command is written", > therefore "erase suspend' command after erase completion will switch > device to read mode. And therefore read status is safe thing to do for > cmdset_0001. > > But in case of cmdset_0002 erase completion will not put device to read > status mode and therefore no special status tracking is required. > > > > But in case of cfi_cmdset_0002, once program/erase operation is > > > complete, device returns to previous address space overlay from which > > > operation was started from (mostly read mode) > > > > I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. > > Even if we issue Read Status command to enter read status mode, any > single subsequent read will put device back to read mode. So, sending > explicit Status CMD is of not much use. > > As long as cmdset_0002 driver ensures sending Read Status cmd and next > single read can be done in one go (ie. mutex held), I don't see any > trouble here. This is already take care off. Ouch, a non sticky Status sounds borken. Are you sure that nothing can change the chip between you issue the Status CMD and read out of status bits? Like if an erase/suspend/resume completes just after Status CMD but before Status readout? Jocke > > > Also, I think you need to use the various map_word_xxx as in: > > status = map_read(map, chip->in_progress_block_addr); > > if (map_word_andequal(map, status, status_OK, status_OK)) > > break; > > Yes, I will fixup this patch to use map_word_* wherever necessary in the > next revision. > > > > otherwise you will break interleaved setups(like two 8-bit flashes in parallel to > > form one 16 bit bus). Maybe this is not supported for CMDSET 0002 ? > > > > Interleaved is indeed supported by cmdset_0002. Thanks for pointing that > out! > > > Jocke > > > > > In order to enter status register overlay mode, Read Status command is > > > to be written to addr_unlock1(0x555) address. The overlay is in effect > > > for one read access, specifically the next read access that follows the > > > Status Register Read command > > > Therefore code around FL_STATUS state in cfi_cmdset_0001 is not > > > applicable to cfi_cmdset_0002 as is. > > > > > > > > > > If so I think the new status impl. in 0002 should borrow from 0001 as this is a > > > > hardened and battle tested impl. > > > > > > > > > > In case of cfi_cmdset_0001.c, program/erase is followed by > > > inval_cache_and_wait_for_operation() to poll ready bit and based on > > > status register value, success or the error handling is done. > > > > > > Most of the code corresponding to inval_cache_and_wait_for_operation() > > > is already in cfi_cmdset_0002.c. So, whats missing in this patch is > > > handling and reporting of errors as reflected in status register after > > > write/erase failures. I will add that in the next version. > > > > > > But, I don't see much to borrow apart from error handling sequence. > > > Please, let me know if I missed something. > > > > > > > I know other modern 0002 chips supports both old and new impl. of Status and I world > > > > guess that we will see more chips with new Status only. > > > > > > > > > > Agreed. Newer devices would mostly be CFI 1.5. > > > > > > -- > > > Regards > > > Vignesh ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register 2019-03-25 17:24 ` Joakim Tjernlund (?) (?) @ 2019-04-02 9:03 ` Vignesh Raghavendra -1 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-04-02 9:03 UTC (permalink / raw) To: Joakim Tjernlund, dwmw2, computersforpeace, bbrezillon, marek.vasut, richard, robh+dt Cc: nsekhar, linux-kernel, linux-mtd, devicetree, masonccyang, tudor.ambarus, sergei.shtylyov, gregkh, linux-arm-kernel, arnd On 25/03/19 10:54 PM, Joakim Tjernlund wrote: > On Mon, 2019-03-25 at 22:36 +0530, Vignesh Raghavendra wrote: >> >> On 25/03/19 7:21 PM, Joakim Tjernlund wrote: >>> On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: >>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >>>> >>>> >>>> Hi, >>>> >>>> On 21/03/19 11:41 PM, Joakim Tjernlund wrote: >>>>> On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: >>>>>> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command >>>>>> Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c >>>>>> can be use as is. But these devices do not support DQ polling method of >>>>>> determining chip ready/good status. These flashes provide Status >>>>>> Register whose bits can be polled to know status of flash operation. >>>>>> >>>>>> Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu >>>>>> Extended Query version 1.5. Bit 0 of "Software Features supported" field >>>>>> of CFI Primary Vendor-Specific Extended Query table indicates >>>>>> presence/absence of status register and Bit 1 indicates whether or not >>>>>> DQ polling is supported. Using these bits, its possible to determine >>>>>> whether flash supports DQ polling or need to use Status Register. >>>>>> >>>>>> Add support for polling status register to know device ready/status of >>>>>> erase/write operations when DQ polling is not supported. >>>>> >>>>> Isn't this new Status scheme just a copy of Intels(cmdset_0001)? >>>> >>>> Yes, but with one difference: At the end of program/erase operation, >>>> device directly enters status register mode and starts reflecting >>>> status register content at any address. >>>> The device remains in the read status register state until another >>>> command is written to the device. Therefore there is notion of device is >>>> in "status register read mode" (FL_STATUS) state >>> >>> That seems to vary and long time ago RMK added this: >>> /* If the flash has finished erasing, then 'erase suspend' >>> * appears to make some (28F320) flash devices switch to >>> * 'read' mode. Make sure that we switch to 'read status' >>> * mode so we get the right data. --rmk >>> */ >>> map_write(map, CMD(0x70), chip->in_progress_block_addr); >>> >> >> This behavior is expected with cmdset_0001. Because "The device remains >> in the read status register state until another command is written", >> therefore "erase suspend' command after erase completion will switch >> device to read mode. And therefore read status is safe thing to do for >> cmdset_0001. >> >> But in case of cmdset_0002 erase completion will not put device to read >> status mode and therefore no special status tracking is required. >> >>>> But in case of cfi_cmdset_0002, once program/erase operation is >>>> complete, device returns to previous address space overlay from which >>>> operation was started from (mostly read mode) >>> >>> I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. >> >> Even if we issue Read Status command to enter read status mode, any >> single subsequent read will put device back to read mode. So, sending >> explicit Status CMD is of not much use. >> >> As long as cmdset_0002 driver ensures sending Read Status cmd and next >> single read can be done in one go (ie. mutex held), I don't see any >> trouble here. This is already take care off. > > Ouch, a non sticky Status sounds borken. Are you sure that nothing can change the > chip between you issue the Status CMD and read out of status bits? > Like if an erase/suspend/resume completes just after Status CMD but before Status readout? > Yes, I did some tests(with HyperFlash) and erase/program completion/suspend in b/w issue of Status CMD but before status readout does not result in exiting status read address space overlay. So we are safe here with non sticky Status. -- Regards Vignesh ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-04-02 9:03 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-04-02 9:03 UTC (permalink / raw) To: Joakim Tjernlund, dwmw2, computersforpeace, bbrezillon, marek.vasut, richard, robh+dt Cc: devicetree, arnd, sergei.shtylyov, tudor.ambarus, gregkh, nsekhar, linux-kernel, linux-mtd, masonccyang, linux-arm-kernel On 25/03/19 10:54 PM, Joakim Tjernlund wrote: > On Mon, 2019-03-25 at 22:36 +0530, Vignesh Raghavendra wrote: >> >> On 25/03/19 7:21 PM, Joakim Tjernlund wrote: >>> On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: >>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >>>> >>>> >>>> Hi, >>>> >>>> On 21/03/19 11:41 PM, Joakim Tjernlund wrote: >>>>> On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: >>>>>> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command >>>>>> Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c >>>>>> can be use as is. But these devices do not support DQ polling method of >>>>>> determining chip ready/good status. These flashes provide Status >>>>>> Register whose bits can be polled to know status of flash operation. >>>>>> >>>>>> Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu >>>>>> Extended Query version 1.5. Bit 0 of "Software Features supported" field >>>>>> of CFI Primary Vendor-Specific Extended Query table indicates >>>>>> presence/absence of status register and Bit 1 indicates whether or not >>>>>> DQ polling is supported. Using these bits, its possible to determine >>>>>> whether flash supports DQ polling or need to use Status Register. >>>>>> >>>>>> Add support for polling status register to know device ready/status of >>>>>> erase/write operations when DQ polling is not supported. >>>>> >>>>> Isn't this new Status scheme just a copy of Intels(cmdset_0001)? >>>> >>>> Yes, but with one difference: At the end of program/erase operation, >>>> device directly enters status register mode and starts reflecting >>>> status register content at any address. >>>> The device remains in the read status register state until another >>>> command is written to the device. Therefore there is notion of device is >>>> in "status register read mode" (FL_STATUS) state >>> >>> That seems to vary and long time ago RMK added this: >>> /* If the flash has finished erasing, then 'erase suspend' >>> * appears to make some (28F320) flash devices switch to >>> * 'read' mode. Make sure that we switch to 'read status' >>> * mode so we get the right data. --rmk >>> */ >>> map_write(map, CMD(0x70), chip->in_progress_block_addr); >>> >> >> This behavior is expected with cmdset_0001. Because "The device remains >> in the read status register state until another command is written", >> therefore "erase suspend' command after erase completion will switch >> device to read mode. And therefore read status is safe thing to do for >> cmdset_0001. >> >> But in case of cmdset_0002 erase completion will not put device to read >> status mode and therefore no special status tracking is required. >> >>>> But in case of cfi_cmdset_0002, once program/erase operation is >>>> complete, device returns to previous address space overlay from which >>>> operation was started from (mostly read mode) >>> >>> I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. >> >> Even if we issue Read Status command to enter read status mode, any >> single subsequent read will put device back to read mode. So, sending >> explicit Status CMD is of not much use. >> >> As long as cmdset_0002 driver ensures sending Read Status cmd and next >> single read can be done in one go (ie. mutex held), I don't see any >> trouble here. This is already take care off. > > Ouch, a non sticky Status sounds borken. Are you sure that nothing can change the > chip between you issue the Status CMD and read out of status bits? > Like if an erase/suspend/resume completes just after Status CMD but before Status readout? > Yes, I did some tests(with HyperFlash) and erase/program completion/suspend in b/w issue of Status CMD but before status readout does not result in exiting status read address space overlay. So we are safe here with non sticky Status. -- Regards Vignesh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-04-02 9:03 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-04-02 9:03 UTC (permalink / raw) To: Joakim Tjernlund, dwmw2, computersforpeace, bbrezillon, marek.vasut, richard, robh+dt Cc: devicetree, arnd, sergei.shtylyov, tudor.ambarus, gregkh, nsekhar, linux-kernel, linux-mtd, masonccyang, linux-arm-kernel On 25/03/19 10:54 PM, Joakim Tjernlund wrote: > On Mon, 2019-03-25 at 22:36 +0530, Vignesh Raghavendra wrote: >> >> On 25/03/19 7:21 PM, Joakim Tjernlund wrote: >>> On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: >>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >>>> >>>> >>>> Hi, >>>> >>>> On 21/03/19 11:41 PM, Joakim Tjernlund wrote: >>>>> On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: >>>>>> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command >>>>>> Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c >>>>>> can be use as is. But these devices do not support DQ polling method of >>>>>> determining chip ready/good status. These flashes provide Status >>>>>> Register whose bits can be polled to know status of flash operation. >>>>>> >>>>>> Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu >>>>>> Extended Query version 1.5. Bit 0 of "Software Features supported" field >>>>>> of CFI Primary Vendor-Specific Extended Query table indicates >>>>>> presence/absence of status register and Bit 1 indicates whether or not >>>>>> DQ polling is supported. Using these bits, its possible to determine >>>>>> whether flash supports DQ polling or need to use Status Register. >>>>>> >>>>>> Add support for polling status register to know device ready/status of >>>>>> erase/write operations when DQ polling is not supported. >>>>> >>>>> Isn't this new Status scheme just a copy of Intels(cmdset_0001)? >>>> >>>> Yes, but with one difference: At the end of program/erase operation, >>>> device directly enters status register mode and starts reflecting >>>> status register content at any address. >>>> The device remains in the read status register state until another >>>> command is written to the device. Therefore there is notion of device is >>>> in "status register read mode" (FL_STATUS) state >>> >>> That seems to vary and long time ago RMK added this: >>> /* If the flash has finished erasing, then 'erase suspend' >>> * appears to make some (28F320) flash devices switch to >>> * 'read' mode. Make sure that we switch to 'read status' >>> * mode so we get the right data. --rmk >>> */ >>> map_write(map, CMD(0x70), chip->in_progress_block_addr); >>> >> >> This behavior is expected with cmdset_0001. Because "The device remains >> in the read status register state until another command is written", >> therefore "erase suspend' command after erase completion will switch >> device to read mode. And therefore read status is safe thing to do for >> cmdset_0001. >> >> But in case of cmdset_0002 erase completion will not put device to read >> status mode and therefore no special status tracking is required. >> >>>> But in case of cfi_cmdset_0002, once program/erase operation is >>>> complete, device returns to previous address space overlay from which >>>> operation was started from (mostly read mode) >>> >>> I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. >> >> Even if we issue Read Status command to enter read status mode, any >> single subsequent read will put device back to read mode. So, sending >> explicit Status CMD is of not much use. >> >> As long as cmdset_0002 driver ensures sending Read Status cmd and next >> single read can be done in one go (ie. mutex held), I don't see any >> trouble here. This is already take care off. > > Ouch, a non sticky Status sounds borken. Are you sure that nothing can change the > chip between you issue the Status CMD and read out of status bits? > Like if an erase/suspend/resume completes just after Status CMD but before Status readout? > Yes, I did some tests(with HyperFlash) and erase/program completion/suspend in b/w issue of Status CMD but before status readout does not result in exiting status read address space overlay. So we are safe here with non sticky Status. -- Regards Vignesh ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-04-02 9:03 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-04-02 9:03 UTC (permalink / raw) To: Joakim Tjernlund, dwmw2, computersforpeace, bbrezillon, marek.vasut, richard, robh+dt Cc: devicetree, arnd, sergei.shtylyov, tudor.ambarus, gregkh, nsekhar, linux-kernel, linux-mtd, masonccyang, linux-arm-kernel On 25/03/19 10:54 PM, Joakim Tjernlund wrote: > On Mon, 2019-03-25 at 22:36 +0530, Vignesh Raghavendra wrote: >> >> On 25/03/19 7:21 PM, Joakim Tjernlund wrote: >>> On Mon, 2019-03-25 at 18:27 +0530, Vignesh Raghavendra wrote: >>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. >>>> >>>> >>>> Hi, >>>> >>>> On 21/03/19 11:41 PM, Joakim Tjernlund wrote: >>>>> On Thu, 2019-03-21 at 23:15 +0530, Vignesh Raghavendra wrote: >>>>>> HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command >>>>>> Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c >>>>>> can be use as is. But these devices do not support DQ polling method of >>>>>> determining chip ready/good status. These flashes provide Status >>>>>> Register whose bits can be polled to know status of flash operation. >>>>>> >>>>>> Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu >>>>>> Extended Query version 1.5. Bit 0 of "Software Features supported" field >>>>>> of CFI Primary Vendor-Specific Extended Query table indicates >>>>>> presence/absence of status register and Bit 1 indicates whether or not >>>>>> DQ polling is supported. Using these bits, its possible to determine >>>>>> whether flash supports DQ polling or need to use Status Register. >>>>>> >>>>>> Add support for polling status register to know device ready/status of >>>>>> erase/write operations when DQ polling is not supported. >>>>> >>>>> Isn't this new Status scheme just a copy of Intels(cmdset_0001)? >>>> >>>> Yes, but with one difference: At the end of program/erase operation, >>>> device directly enters status register mode and starts reflecting >>>> status register content at any address. >>>> The device remains in the read status register state until another >>>> command is written to the device. Therefore there is notion of device is >>>> in "status register read mode" (FL_STATUS) state >>> >>> That seems to vary and long time ago RMK added this: >>> /* If the flash has finished erasing, then 'erase suspend' >>> * appears to make some (28F320) flash devices switch to >>> * 'read' mode. Make sure that we switch to 'read status' >>> * mode so we get the right data. --rmk >>> */ >>> map_write(map, CMD(0x70), chip->in_progress_block_addr); >>> >> >> This behavior is expected with cmdset_0001. Because "The device remains >> in the read status register state until another command is written", >> therefore "erase suspend' command after erase completion will switch >> device to read mode. And therefore read status is safe thing to do for >> cmdset_0001. >> >> But in case of cmdset_0002 erase completion will not put device to read >> status mode and therefore no special status tracking is required. >> >>>> But in case of cfi_cmdset_0002, once program/erase operation is >>>> complete, device returns to previous address space overlay from which >>>> operation was started from (mostly read mode) >>> >>> I hope you can do the same as Intel here, issue an explicit Status CMD or you will be in trouble. >> >> Even if we issue Read Status command to enter read status mode, any >> single subsequent read will put device back to read mode. So, sending >> explicit Status CMD is of not much use. >> >> As long as cmdset_0002 driver ensures sending Read Status cmd and next >> single read can be done in one go (ie. mutex held), I don't see any >> trouble here. This is already take care off. > > Ouch, a non sticky Status sounds borken. Are you sure that nothing can change the > chip between you issue the Status CMD and read out of status bits? > Like if an erase/suspend/resume completes just after Status CMD but before Status readout? > Yes, I did some tests(with HyperFlash) and erase/program completion/suspend in b/w issue of Status CMD but before status readout does not result in exiting status read address space overlay. So we are safe here with non sticky Status. -- Regards Vignesh ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register 2019-03-21 17:45 ` Vignesh Raghavendra (?) @ 2019-03-24 16:23 ` Sergei Shtylyov -1 siblings, 0 replies; 67+ messages in thread From: Sergei Shtylyov @ 2019-03-24 16:23 UTC (permalink / raw) To: Vignesh Raghavendra, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang Hello! On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote: > HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command > Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c > can be use as is. But these devices do not support DQ polling method of > determining chip ready/good status. These flashes provide Status > Register whose bits can be polled to know status of flash operation. > > Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu > Extended Query version 1.5. Bit 0 of "Software Features supported" field > of CFI Primary Vendor-Specific Extended Query table indicates > presence/absence of status register and Bit 1 indicates whether or not > DQ polling is supported. Using these bits, its possible to determine > whether flash supports DQ polling or need to use Status Register. We need? > Add support for polling status register to know device ready/status of > erase/write operations when DQ polling is not supported. > > [1] https://www.cypress.com/file/213346/download > > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> > --- > drivers/mtd/chips/cfi_cmdset_0002.c | 50 +++++++++++++++++++++++++++++ > include/linux/mtd/cfi.h | 5 +++ > 2 files changed, 55 insertions(+) > > diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c > index 72428b6bfc47..29987d8e6c6e 100644 > --- a/drivers/mtd/chips/cfi_cmdset_0002.c > +++ b/drivers/mtd/chips/cfi_cmdset_0002.c [...] > diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h > index cbf77168658c..92ac82ac2329 100644 > --- a/include/linux/mtd/cfi.h > +++ b/include/linux/mtd/cfi.h > @@ -233,6 +233,11 @@ struct cfi_pri_amdstd { > uint8_t VppMin; > uint8_t VppMax; > uint8_t TopBottom; > + /* Below field are added from version 1.5 */ The below fields are. > + uint8_t ProgramSuspend; > + uint8_t UnlockBypass; > + uint8_t SecureSiliconSector; > + uint8_t SoftwareFeatures; > } __packed; > > /* Vendor-Specific PRI for Atmel chips (command set 0x0002) */ > MBR, Sergei ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-24 16:23 ` Sergei Shtylyov 0 siblings, 0 replies; 67+ messages in thread From: Sergei Shtylyov @ 2019-03-24 16:23 UTC (permalink / raw) To: Vignesh Raghavendra, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Hello! On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote: > HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command > Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c > can be use as is. But these devices do not support DQ polling method of > determining chip ready/good status. These flashes provide Status > Register whose bits can be polled to know status of flash operation. > > Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu > Extended Query version 1.5. Bit 0 of "Software Features supported" field > of CFI Primary Vendor-Specific Extended Query table indicates > presence/absence of status register and Bit 1 indicates whether or not > DQ polling is supported. Using these bits, its possible to determine > whether flash supports DQ polling or need to use Status Register. We need? > Add support for polling status register to know device ready/status of > erase/write operations when DQ polling is not supported. > > [1] https://www.cypress.com/file/213346/download > > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> > --- > drivers/mtd/chips/cfi_cmdset_0002.c | 50 +++++++++++++++++++++++++++++ > include/linux/mtd/cfi.h | 5 +++ > 2 files changed, 55 insertions(+) > > diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c > index 72428b6bfc47..29987d8e6c6e 100644 > --- a/drivers/mtd/chips/cfi_cmdset_0002.c > +++ b/drivers/mtd/chips/cfi_cmdset_0002.c [...] > diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h > index cbf77168658c..92ac82ac2329 100644 > --- a/include/linux/mtd/cfi.h > +++ b/include/linux/mtd/cfi.h > @@ -233,6 +233,11 @@ struct cfi_pri_amdstd { > uint8_t VppMin; > uint8_t VppMax; > uint8_t TopBottom; > + /* Below field are added from version 1.5 */ The below fields are. > + uint8_t ProgramSuspend; > + uint8_t UnlockBypass; > + uint8_t SecureSiliconSector; > + uint8_t SoftwareFeatures; > } __packed; > > /* Vendor-Specific PRI for Atmel chips (command set 0x0002) */ > MBR, Sergei _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register @ 2019-03-24 16:23 ` Sergei Shtylyov 0 siblings, 0 replies; 67+ messages in thread From: Sergei Shtylyov @ 2019-03-24 16:23 UTC (permalink / raw) To: Vignesh Raghavendra, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Hello! On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote: > HyperFlash devices are compliant with CFI AMD/Fujitsu Extended Command > Set(0x0002) for flash operations, therefore drivers/mtd/chips/cfi_cmdset_0002.c > can be use as is. But these devices do not support DQ polling method of > determining chip ready/good status. These flashes provide Status > Register whose bits can be polled to know status of flash operation. > > Cypress HyperFlash datasheet here[1], talks about CFI Amd/Fujitsu > Extended Query version 1.5. Bit 0 of "Software Features supported" field > of CFI Primary Vendor-Specific Extended Query table indicates > presence/absence of status register and Bit 1 indicates whether or not > DQ polling is supported. Using these bits, its possible to determine > whether flash supports DQ polling or need to use Status Register. We need? > Add support for polling status register to know device ready/status of > erase/write operations when DQ polling is not supported. > > [1] https://www.cypress.com/file/213346/download > > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> > --- > drivers/mtd/chips/cfi_cmdset_0002.c | 50 +++++++++++++++++++++++++++++ > include/linux/mtd/cfi.h | 5 +++ > 2 files changed, 55 insertions(+) > > diff --git a/drivers/mtd/chips/cfi_cmdset_0002.c b/drivers/mtd/chips/cfi_cmdset_0002.c > index 72428b6bfc47..29987d8e6c6e 100644 > --- a/drivers/mtd/chips/cfi_cmdset_0002.c > +++ b/drivers/mtd/chips/cfi_cmdset_0002.c [...] > diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h > index cbf77168658c..92ac82ac2329 100644 > --- a/include/linux/mtd/cfi.h > +++ b/include/linux/mtd/cfi.h > @@ -233,6 +233,11 @@ struct cfi_pri_amdstd { > uint8_t VppMin; > uint8_t VppMax; > uint8_t TopBottom; > + /* Below field are added from version 1.5 */ The below fields are. > + uint8_t ProgramSuspend; > + uint8_t UnlockBypass; > + uint8_t SecureSiliconSector; > + uint8_t SoftwareFeatures; > } __packed; > > /* Vendor-Specific PRI for Atmel chips (command set 0x0002) */ > MBR, Sergei ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* [RFC PATCH v2 2/5] dt-bindings: mtd: Add binding documentation for Hyperbus memory devices 2019-03-21 17:45 ` Vignesh Raghavendra (?) (?) @ 2019-03-21 17:45 ` Vignesh Raghavendra -1 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang, Sergei Shtylyov Add DT binding documentation for Hyperbus memory devices. Only Hyperflash is supported at the moment. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt diff --git a/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt new file mode 100644 index 000000000000..cb408f80b868 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt @@ -0,0 +1,6 @@ +Bindings for Hyperflash NOR flash chips compliant with Cypress Hyperbus +specification and supports Cypress CFI specification 1.5 command set. + +Required properties: +- compatible : "cypress,hyperflash" for Hyperflash NOR chips +- reg : Address where flash's memory mapped space -- 2.21.0 ^ permalink raw reply related [flat|nested] 67+ messages in thread
* [RFC PATCH v2 2/5] dt-bindings: mtd: Add binding documentation for Hyperbus memory devices @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Sergei Shtylyov, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Add DT binding documentation for Hyperbus memory devices. Only Hyperflash is supported at the moment. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt diff --git a/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt new file mode 100644 index 000000000000..cb408f80b868 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt @@ -0,0 +1,6 @@ +Bindings for Hyperflash NOR flash chips compliant with Cypress Hyperbus +specification and supports Cypress CFI specification 1.5 command set. + +Required properties: +- compatible : "cypress,hyperflash" for Hyperflash NOR chips +- reg : Address where flash's memory mapped space -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 67+ messages in thread
* [RFC PATCH v2 2/5] dt-bindings: mtd: Add binding documentation for Hyperbus memory devices @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Sergei Shtylyov, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Add DT binding documentation for Hyperbus memory devices. Only Hyperflash is supported at the moment. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt diff --git a/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt new file mode 100644 index 000000000000..cb408f80b868 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt @@ -0,0 +1,6 @@ +Bindings for Hyperflash NOR flash chips compliant with Cypress Hyperbus +specification and supports Cypress CFI specification 1.5 command set. + +Required properties: +- compatible : "cypress,hyperflash" for Hyperflash NOR chips +- reg : Address where flash's memory mapped space -- 2.21.0 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply related [flat|nested] 67+ messages in thread
* [RFC PATCH v2 2/5] dt-bindings: mtd: Add binding documentation for Hyperbus memory devices @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang, Sergei Shtylyov Add DT binding documentation for Hyperbus memory devices. Only Hyperflash is supported at the moment. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt diff --git a/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt new file mode 100644 index 000000000000..cb408f80b868 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt @@ -0,0 +1,6 @@ +Bindings for Hyperflash NOR flash chips compliant with Cypress Hyperbus +specification and supports Cypress CFI specification 1.5 command set. + +Required properties: +- compatible : "cypress,hyperflash" for Hyperflash NOR chips +- reg : Address where flash's memory mapped space -- 2.21.0 ^ permalink raw reply related [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 2/5] dt-bindings: mtd: Add binding documentation for Hyperbus memory devices 2019-03-21 17:45 ` Vignesh Raghavendra (?) @ 2019-03-24 16:18 ` Sergei Shtylyov -1 siblings, 0 replies; 67+ messages in thread From: Sergei Shtylyov @ 2019-03-24 16:18 UTC (permalink / raw) To: Vignesh Raghavendra, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang Hello! On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote: > Add DT binding documentation for Hyperbus memory devices. Only > Hyperflash is supported at the moment. > > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> > --- > Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt | 6 ++++++ > 1 file changed, 6 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt > > diff --git a/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt > new file mode 100644 > index 000000000000..cb408f80b868 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt > @@ -0,0 +1,6 @@ > +Bindings for Hyperflash NOR flash chips compliant with Cypress Hyperbus > +specification and supports Cypress CFI specification 1.5 command set. > + > +Required properties: > +- compatible : "cypress,hyperflash" for Hyperflash NOR chips What about "cfi-flash", shouldn't it be also specified? > +- reg : Address where flash's memory mapped space MBR, Sergei ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 2/5] dt-bindings: mtd: Add binding documentation for Hyperbus memory devices @ 2019-03-24 16:18 ` Sergei Shtylyov 0 siblings, 0 replies; 67+ messages in thread From: Sergei Shtylyov @ 2019-03-24 16:18 UTC (permalink / raw) To: Vignesh Raghavendra, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Hello! On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote: > Add DT binding documentation for Hyperbus memory devices. Only > Hyperflash is supported at the moment. > > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> > --- > Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt | 6 ++++++ > 1 file changed, 6 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt > > diff --git a/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt > new file mode 100644 > index 000000000000..cb408f80b868 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt > @@ -0,0 +1,6 @@ > +Bindings for Hyperflash NOR flash chips compliant with Cypress Hyperbus > +specification and supports Cypress CFI specification 1.5 command set. > + > +Required properties: > +- compatible : "cypress,hyperflash" for Hyperflash NOR chips What about "cfi-flash", shouldn't it be also specified? > +- reg : Address where flash's memory mapped space MBR, Sergei _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 2/5] dt-bindings: mtd: Add binding documentation for Hyperbus memory devices @ 2019-03-24 16:18 ` Sergei Shtylyov 0 siblings, 0 replies; 67+ messages in thread From: Sergei Shtylyov @ 2019-03-24 16:18 UTC (permalink / raw) To: Vignesh Raghavendra, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Hello! On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote: > Add DT binding documentation for Hyperbus memory devices. Only > Hyperflash is supported at the moment. > > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> > --- > Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt | 6 ++++++ > 1 file changed, 6 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt > > diff --git a/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt > new file mode 100644 > index 000000000000..cb408f80b868 > --- /dev/null > +++ b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt > @@ -0,0 +1,6 @@ > +Bindings for Hyperflash NOR flash chips compliant with Cypress Hyperbus > +specification and supports Cypress CFI specification 1.5 command set. > + > +Required properties: > +- compatible : "cypress,hyperflash" for Hyperflash NOR chips What about "cfi-flash", shouldn't it be also specified? > +- reg : Address where flash's memory mapped space MBR, Sergei ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 2/5] dt-bindings: mtd: Add binding documentation for Hyperbus memory devices 2019-03-24 16:18 ` Sergei Shtylyov (?) (?) @ 2019-03-25 13:10 ` Vignesh Raghavendra -1 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-25 13:10 UTC (permalink / raw) To: Sergei Shtylyov, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang Hi, On 24/03/19 9:48 PM, Sergei Shtylyov wrote: > Hello! > > On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote: > >> Add DT binding documentation for Hyperbus memory devices. Only >> Hyperflash is supported at the moment. >> >> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> >> --- >> Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt | 6 ++++++ >> 1 file changed, 6 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt >> >> diff --git a/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt >> new file mode 100644 >> index 000000000000..cb408f80b868 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt >> @@ -0,0 +1,6 @@ >> +Bindings for Hyperflash NOR flash chips compliant with Cypress Hyperbus >> +specification and supports Cypress CFI specification 1.5 command set. >> + >> +Required properties: >> +- compatible : "cypress,hyperflash" for Hyperflash NOR chips > > What about "cfi-flash", shouldn't it be also specified? Oh, right. I missed that. Hyperflash is CFI compliant. Will add that next time. Thanks! > >> +- reg : Address where flash's memory mapped space > > MBR, Sergei > -- Regards Vignesh ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 2/5] dt-bindings: mtd: Add binding documentation for Hyperbus memory devices @ 2019-03-25 13:10 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-25 13:10 UTC (permalink / raw) To: Sergei Shtylyov, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Hi, On 24/03/19 9:48 PM, Sergei Shtylyov wrote: > Hello! > > On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote: > >> Add DT binding documentation for Hyperbus memory devices. Only >> Hyperflash is supported at the moment. >> >> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> >> --- >> Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt | 6 ++++++ >> 1 file changed, 6 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt >> >> diff --git a/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt >> new file mode 100644 >> index 000000000000..cb408f80b868 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt >> @@ -0,0 +1,6 @@ >> +Bindings for Hyperflash NOR flash chips compliant with Cypress Hyperbus >> +specification and supports Cypress CFI specification 1.5 command set. >> + >> +Required properties: >> +- compatible : "cypress,hyperflash" for Hyperflash NOR chips > > What about "cfi-flash", shouldn't it be also specified? Oh, right. I missed that. Hyperflash is CFI compliant. Will add that next time. Thanks! > >> +- reg : Address where flash's memory mapped space > > MBR, Sergei > -- Regards Vignesh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 2/5] dt-bindings: mtd: Add binding documentation for Hyperbus memory devices @ 2019-03-25 13:10 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-25 13:10 UTC (permalink / raw) To: Sergei Shtylyov, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Hi, On 24/03/19 9:48 PM, Sergei Shtylyov wrote: > Hello! > > On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote: > >> Add DT binding documentation for Hyperbus memory devices. Only >> Hyperflash is supported at the moment. >> >> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> >> --- >> Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt | 6 ++++++ >> 1 file changed, 6 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt >> >> diff --git a/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt >> new file mode 100644 >> index 000000000000..cb408f80b868 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt >> @@ -0,0 +1,6 @@ >> +Bindings for Hyperflash NOR flash chips compliant with Cypress Hyperbus >> +specification and supports Cypress CFI specification 1.5 command set. >> + >> +Required properties: >> +- compatible : "cypress,hyperflash" for Hyperflash NOR chips > > What about "cfi-flash", shouldn't it be also specified? Oh, right. I missed that. Hyperflash is CFI compliant. Will add that next time. Thanks! > >> +- reg : Address where flash's memory mapped space > > MBR, Sergei > -- Regards Vignesh ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 2/5] dt-bindings: mtd: Add binding documentation for Hyperbus memory devices @ 2019-03-25 13:10 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-25 13:10 UTC (permalink / raw) To: Sergei Shtylyov, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang Hi, On 24/03/19 9:48 PM, Sergei Shtylyov wrote: > Hello! > > On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote: > >> Add DT binding documentation for Hyperbus memory devices. Only >> Hyperflash is supported at the moment. >> >> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> >> --- >> Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt | 6 ++++++ >> 1 file changed, 6 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt >> >> diff --git a/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt >> new file mode 100644 >> index 000000000000..cb408f80b868 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt >> @@ -0,0 +1,6 @@ >> +Bindings for Hyperflash NOR flash chips compliant with Cypress Hyperbus >> +specification and supports Cypress CFI specification 1.5 command set. >> + >> +Required properties: >> +- compatible : "cypress,hyperflash" for Hyperflash NOR chips > > What about "cfi-flash", shouldn't it be also specified? Oh, right. I missed that. Hyperflash is CFI compliant. Will add that next time. Thanks! > >> +- reg : Address where flash's memory mapped space > > MBR, Sergei > -- Regards Vignesh ^ permalink raw reply [flat|nested] 67+ messages in thread
* [RFC PATCH v2 3/5] mtd: Add support for Hyperbus memory devices 2019-03-21 17:45 ` Vignesh Raghavendra (?) (?) @ 2019-03-21 17:45 ` Vignesh Raghavendra -1 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang, Sergei Shtylyov Cypress' Hyperbus is Low Signal Count, High Performance Double Data Rate Bus interface between a host system master and one or more slave interfaces. Hyperbus is used to connect microprocessor, microcontroller, or ASIC devices with random access NOR flash memory (called Hyperflash) or self refresh DRAM (called HyperRAM). Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) signal and either Single-ended clock(3.0V parts) or Differential clock (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. At bus level, it follows a separate protocol described in Hyperbus specification[1]. Hyperflash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, its equivalent to x16 parallel NOR flash wrt bits per clock cycle. But Hyperbus operates at >166MHz frequencies. HyperRAM provides direct random read/write access to flash memory array. But, Hyperbus memory controllers seem to abstract implementation details and expose a simple MMIO interface to access connected flash. Add support for registering Hyperflash devices with MTD framework. MTD maps framework along with CFI chip support framework are used to support communicating with flash. Framework is modelled along the lines of spi-nor framework. Hyperbus memory controller (HBMC) drivers calls hyperbus_register_device() to register a single Hyperflash device. Hyperflash core parses MMIO access information from DT, sets up the map_info struct, probes CFI flash and registers it with MTD framework. Some HBMC masters need calibration/training sequence[3] to be carried out, in order for DLL inside the controller to lock, by reading a known string/pattern. This is done by repeatedly reading CFI Query Identification String. Calibration needs to be done before trying to detect flash as part of CFI flash probe. HyperRAM is not supported at the moment. Hyperbus specification can be found at[1] Hyperflash datasheet can be found at[2] [1] https://www.cypress.com/file/213356/download [2] https://www.cypress.com/file/213346/download [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf Table 12-5741. HyperFlash Access Sequence Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- MAINTAINERS | 7 + drivers/mtd/Kconfig | 2 + drivers/mtd/Makefile | 1 + drivers/mtd/hyperbus/Kconfig | 11 ++ drivers/mtd/hyperbus/Makefile | 3 + drivers/mtd/hyperbus/hyperbus-core.c | 183 +++++++++++++++++++++++++++ include/linux/mtd/hyperbus.h | 91 +++++++++++++ 7 files changed, 298 insertions(+) create mode 100644 drivers/mtd/hyperbus/Kconfig create mode 100644 drivers/mtd/hyperbus/Makefile create mode 100644 drivers/mtd/hyperbus/hyperbus-core.c create mode 100644 include/linux/mtd/hyperbus.h diff --git a/MAINTAINERS b/MAINTAINERS index 74e28172c637..48f1f227f65b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7188,6 +7188,13 @@ F: include/uapi/linux/hyperv.h F: tools/hv/ F: Documentation/ABI/stable/sysfs-bus-vmbus +HYPERBUS SUPPORT +M: Vignesh Raghavendra <vigneshr@ti.com> +S: Supported +F: drivers/mtd/hyperbus/ +F: include/linux/mtd/hyperbus.h +F: Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt + HYPERVISOR VIRTUAL CONSOLE DRIVER L: linuxppc-dev@lists.ozlabs.org S: Odd Fixes diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 79a8ff542883..a915ff300390 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -290,4 +290,6 @@ source "drivers/mtd/spi-nor/Kconfig" source "drivers/mtd/ubi/Kconfig" +source "drivers/mtd/hyperbus/Kconfig" + endif # MTD diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index 58fc327a5276..04c154906631 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -35,3 +35,4 @@ obj-y += chips/ lpddr/ maps/ devices/ nand/ tests/ obj-$(CONFIG_MTD_SPI_NOR) += spi-nor/ obj-$(CONFIG_MTD_UBI) += ubi/ +obj-$(CONFIG_MTD_HYPERBUS) += hyperbus/ diff --git a/drivers/mtd/hyperbus/Kconfig b/drivers/mtd/hyperbus/Kconfig new file mode 100644 index 000000000000..febbb4cdc25f --- /dev/null +++ b/drivers/mtd/hyperbus/Kconfig @@ -0,0 +1,11 @@ +menuconfig MTD_HYPERBUS + tristate "Hyperbus support" + select MTD_CFI + select MTD_MAP_BANK_WIDTH_2 + select MTD_CFI_AMDSTD + select MTD_COMPLEX_MAPPINGS + help + This is the framework for the Hyperbus which can be used by + the Hyperbus Controller driver to communicate with + Hyperflash. See Cypress Hyperbus specification for more + details diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile new file mode 100644 index 000000000000..ca61dedd730d --- /dev/null +++ b/drivers/mtd/hyperbus/Makefile @@ -0,0 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0 + +obj-$(CONFIG_MTD_HYPERBUS) += hyperbus-core.o diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c new file mode 100644 index 000000000000..4c2876c367fc --- /dev/null +++ b/drivers/mtd/hyperbus/hyperbus-core.c @@ -0,0 +1,183 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ +// Author: Vignesh Raghavendra <vigneshr@ti.com> + +#include <linux/err.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/mtd/hyperbus.h> +#include <linux/mtd/map.h> +#include <linux/mtd/mtd.h> +#include <linux/mtd/cfi.h> +#include <linux/of.h> +#include <linux/of_address.h> +#include <linux/types.h> + +#define HYPERBUS_CALIB_COUNT 25 + +static struct hyperbus_device *map_to_hbdev(struct map_info *map) +{ + return container_of(map, struct hyperbus_device, map); +} + +static map_word hyperbus_read16(struct map_info *map, unsigned long addr) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + map_word read_data; + + read_data.x[0] = ctlr->ops->read16(hbdev, addr); + + return read_data; +} + +static void hyperbus_write16(struct map_info *map, map_word d, + unsigned long addr) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + + ctlr->ops->write16(hbdev, addr, d.x[0]); +} + +static void hyperbus_copy_from(struct map_info *map, void *to, + unsigned long from, ssize_t len) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + + ctlr->ops->copy_from(hbdev, to, from, len); +} + +static void hyperbus_copy_to(struct map_info *map, unsigned long to, + const void *from, ssize_t len) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + + ctlr->ops->copy_to(hbdev, to, from, len); +} + +/* Default calibration routine for use by Hyperbus controller. + * Controller is calibrated by repeatedly reading known pattern ("QRY" + * string from CFI space) + * It is not enough to just ensure "QRY" string is read correctly, need + * to read mulitple times to ensure stability of the DLL lock. + */ +int hyperbus_calibrate(struct hyperbus_device *hbdev) +{ + struct map_info *map = &hbdev->map; + struct cfi_private cfi; + int count = HYPERBUS_CALIB_COUNT; + int ret; + + cfi.interleave = 1; + cfi.device_type = CFI_DEVICETYPE_X16; + cfi_send_gen_cmd(0xF0, 0, 0, map, &cfi, cfi.device_type, NULL); + cfi_send_gen_cmd(0x98, 0x55, 0, map, &cfi, cfi.device_type, NULL); + + while (count--) + cfi_qry_present(map, 0, &cfi); + + ret = cfi_qry_present(map, 0, &cfi); + cfi_qry_mode_off(0, map, &cfi); + + return ret; +} +EXPORT_SYMBOL_GPL(hyperbus_calibrate); + +int hyperbus_register_device(struct hyperbus_device *hbdev) +{ + const struct hyperbus_ops *ops; + struct hyperbus_ctlr *ctlr; + struct device_node *np; + struct map_info *map; + struct resource res; + struct device *dev; + int ret; + + if (!hbdev || !hbdev->np || !hbdev->ctlr || !hbdev->ctlr->dev) { + pr_err("hyperbus: please fill all the necessary fields!\n"); + return -EINVAL; + } + + np = hbdev->np; + ctlr = hbdev->ctlr; + if (!of_device_is_compatible(np, "cypress,hyperflash")) + return -ENODEV; + + hbdev->memtype = HYPERFLASH; + + if (of_address_to_resource(np, 0, &res)) + return -EINVAL; + + dev = ctlr->dev; + map = &hbdev->map; + map->size = resource_size(&res); + map->virt = devm_ioremap_resource(dev, &res); + if (IS_ERR(map->virt)) + return PTR_ERR(map->virt); + + map->name = dev_name(dev); + map->bankwidth = 2; + + simple_map_init(map); + ops = ctlr->ops; + if (ops) { + if (ops->read16) + map->read = hyperbus_read16; + if (ops->write16) + map->write = hyperbus_write16; + if (ops->copy_to) + map->copy_to = hyperbus_copy_to; + if (ops->copy_from) + map->copy_from = hyperbus_copy_from; + + if (ops->calibrate && !ctlr->calibrated) { + ret = ops->calibrate(hbdev); + if (!ret) { + dev_err(dev, "Calibration failed\n"); + return -ENODEV; + } + ctlr->calibrated = true; + } + } + + hbdev->mtd = do_map_probe("cfi_probe", map); + if (!hbdev->mtd) { + dev_err(dev, "probing of hyperbus device failed\n"); + return -ENODEV; + } + + hbdev->mtd->dev.parent = dev; + mtd_set_of_node(hbdev->mtd, np); + + ret = mtd_device_register(hbdev->mtd, NULL, 0); + if (ret) { + dev_err(dev, "failed to register mtd device\n"); + map_destroy(hbdev->mtd); + return ret; + } + hbdev->registered = true; + + return 0; +} +EXPORT_SYMBOL_GPL(hyperbus_register_device); + +int hyperbus_unregister_device(struct hyperbus_device *hbdev) +{ + int ret = 0; + + if (hbdev && hbdev->mtd && hbdev->registered) { + ret = mtd_device_unregister(hbdev->mtd); + map_destroy(hbdev->mtd); + } + + return ret; +} +EXPORT_SYMBOL_GPL(hyperbus_unregister_device); + +MODULE_DESCRIPTION("Hyperbus Framework"); +MODULE_LICENSE("GPL v2"); +MODULE_AUTHOR("Vignesh Raghavendra <vigneshr@ti.com>"); diff --git a/include/linux/mtd/hyperbus.h b/include/linux/mtd/hyperbus.h new file mode 100644 index 000000000000..57f273e87f29 --- /dev/null +++ b/include/linux/mtd/hyperbus.h @@ -0,0 +1,91 @@ +/* SPDX-License-Identifier: GPL-2.0 + * + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ + */ + +#ifndef __LINUX_MTD_HYPERBUS_H__ +#define __LINUX_MTD_HYPERBUS_H__ + +#include <linux/mtd/map.h> + +enum hyperbus_memtype { + HYPERFLASH, + HYPERRAM, +}; + +/** + * struct hyerbus_device - struct representing Hyperbus slave device + * @map: map_info struct for accessing MMIO Hyperbus flash memory + * @np: pointer to Hyperbus slave device node + * @mtd: pointer to MTD struct + * @ctlr: pointer to Hyperbus controller struct + * @memtype: type of memory device: Hyperflash or HyperRAM + * @registered: flag to indicate whether device is registered with MTD core + */ + +struct hyperbus_device { + struct map_info map; + struct device_node *np; + struct mtd_info *mtd; + struct hyperbus_ctlr *ctlr; + enum hyperbus_memtype memtype; + bool registered; +}; + +/** + * struct hyperbus_ops - struct representing custom Hyperbus operations + * @read16: read 16 bit of data, usually from register/ID-CFI space + * @write16: write 16 bit of data, usually to register/ID-CFI space + * @copy_from: copy data from flash memory + * @copy_to: copy data to flash memory + * @calibrate: calibrate Hyperbus controller + */ + +struct hyperbus_ops { + u16 (*read16)(struct hyperbus_device *hbdev, unsigned long addr); + void (*write16)(struct hyperbus_device *hbdev, + unsigned long addr, u16 val); + void (*copy_from)(struct hyperbus_device *hbdev, void *to, + unsigned long from, ssize_t len); + void (*copy_to)(struct hyperbus_device *dev, unsigned long to, + const void *from, ssize_t len); + int (*calibrate)(struct hyperbus_device *dev); +}; + +/** + * struct hyperbus_ctlr - struct representing Hyperbus controller + * @calibrated: flag to indicate ctlr calibration sequence is complete + * @ops: Hyperbus controller ops + */ +struct hyperbus_ctlr { + struct device *dev; + bool calibrated; + + const struct hyperbus_ops *ops; +}; + +/** + * hyperbus_calibrate - default calibration routine for use by Hyperbus ctlr. + * @hbdev: hyperbus_device to be used for calibration + * + * Return: 0 for success, others for failure. + */ +int hyperbus_calibrate(struct hyperbus_device *hbdev); + +/** + * hyperbus_register_device - probe and register a Hyperbus slave memory device + * @hbdev: hyperbus_device struct with dev, np and ctlr field populated + * + * Return: 0 for success, others for failure. + */ +int hyperbus_register_device(struct hyperbus_device *hbdev); + +/** + * hb_unregister_device - deregister Hyperbus slave memory device + * @hbdev: hyperbus_device to be unregistered + * + * Return: 0 for success, others for failure. + */ +int hyperbus_unregister_device(struct hyperbus_device *hbdev); + +#endif /* __LINUX_MTD_HYPERBUS_H__ */ -- 2.21.0 ^ permalink raw reply related [flat|nested] 67+ messages in thread
* [RFC PATCH v2 3/5] mtd: Add support for Hyperbus memory devices @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Sergei Shtylyov, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Cypress' Hyperbus is Low Signal Count, High Performance Double Data Rate Bus interface between a host system master and one or more slave interfaces. Hyperbus is used to connect microprocessor, microcontroller, or ASIC devices with random access NOR flash memory (called Hyperflash) or self refresh DRAM (called HyperRAM). Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) signal and either Single-ended clock(3.0V parts) or Differential clock (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. At bus level, it follows a separate protocol described in Hyperbus specification[1]. Hyperflash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, its equivalent to x16 parallel NOR flash wrt bits per clock cycle. But Hyperbus operates at >166MHz frequencies. HyperRAM provides direct random read/write access to flash memory array. But, Hyperbus memory controllers seem to abstract implementation details and expose a simple MMIO interface to access connected flash. Add support for registering Hyperflash devices with MTD framework. MTD maps framework along with CFI chip support framework are used to support communicating with flash. Framework is modelled along the lines of spi-nor framework. Hyperbus memory controller (HBMC) drivers calls hyperbus_register_device() to register a single Hyperflash device. Hyperflash core parses MMIO access information from DT, sets up the map_info struct, probes CFI flash and registers it with MTD framework. Some HBMC masters need calibration/training sequence[3] to be carried out, in order for DLL inside the controller to lock, by reading a known string/pattern. This is done by repeatedly reading CFI Query Identification String. Calibration needs to be done before trying to detect flash as part of CFI flash probe. HyperRAM is not supported at the moment. Hyperbus specification can be found at[1] Hyperflash datasheet can be found at[2] [1] https://www.cypress.com/file/213356/download [2] https://www.cypress.com/file/213346/download [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf Table 12-5741. HyperFlash Access Sequence Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- MAINTAINERS | 7 + drivers/mtd/Kconfig | 2 + drivers/mtd/Makefile | 1 + drivers/mtd/hyperbus/Kconfig | 11 ++ drivers/mtd/hyperbus/Makefile | 3 + drivers/mtd/hyperbus/hyperbus-core.c | 183 +++++++++++++++++++++++++++ include/linux/mtd/hyperbus.h | 91 +++++++++++++ 7 files changed, 298 insertions(+) create mode 100644 drivers/mtd/hyperbus/Kconfig create mode 100644 drivers/mtd/hyperbus/Makefile create mode 100644 drivers/mtd/hyperbus/hyperbus-core.c create mode 100644 include/linux/mtd/hyperbus.h diff --git a/MAINTAINERS b/MAINTAINERS index 74e28172c637..48f1f227f65b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7188,6 +7188,13 @@ F: include/uapi/linux/hyperv.h F: tools/hv/ F: Documentation/ABI/stable/sysfs-bus-vmbus +HYPERBUS SUPPORT +M: Vignesh Raghavendra <vigneshr@ti.com> +S: Supported +F: drivers/mtd/hyperbus/ +F: include/linux/mtd/hyperbus.h +F: Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt + HYPERVISOR VIRTUAL CONSOLE DRIVER L: linuxppc-dev@lists.ozlabs.org S: Odd Fixes diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 79a8ff542883..a915ff300390 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -290,4 +290,6 @@ source "drivers/mtd/spi-nor/Kconfig" source "drivers/mtd/ubi/Kconfig" +source "drivers/mtd/hyperbus/Kconfig" + endif # MTD diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index 58fc327a5276..04c154906631 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -35,3 +35,4 @@ obj-y += chips/ lpddr/ maps/ devices/ nand/ tests/ obj-$(CONFIG_MTD_SPI_NOR) += spi-nor/ obj-$(CONFIG_MTD_UBI) += ubi/ +obj-$(CONFIG_MTD_HYPERBUS) += hyperbus/ diff --git a/drivers/mtd/hyperbus/Kconfig b/drivers/mtd/hyperbus/Kconfig new file mode 100644 index 000000000000..febbb4cdc25f --- /dev/null +++ b/drivers/mtd/hyperbus/Kconfig @@ -0,0 +1,11 @@ +menuconfig MTD_HYPERBUS + tristate "Hyperbus support" + select MTD_CFI + select MTD_MAP_BANK_WIDTH_2 + select MTD_CFI_AMDSTD + select MTD_COMPLEX_MAPPINGS + help + This is the framework for the Hyperbus which can be used by + the Hyperbus Controller driver to communicate with + Hyperflash. See Cypress Hyperbus specification for more + details diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile new file mode 100644 index 000000000000..ca61dedd730d --- /dev/null +++ b/drivers/mtd/hyperbus/Makefile @@ -0,0 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0 + +obj-$(CONFIG_MTD_HYPERBUS) += hyperbus-core.o diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c new file mode 100644 index 000000000000..4c2876c367fc --- /dev/null +++ b/drivers/mtd/hyperbus/hyperbus-core.c @@ -0,0 +1,183 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ +// Author: Vignesh Raghavendra <vigneshr@ti.com> + +#include <linux/err.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/mtd/hyperbus.h> +#include <linux/mtd/map.h> +#include <linux/mtd/mtd.h> +#include <linux/mtd/cfi.h> +#include <linux/of.h> +#include <linux/of_address.h> +#include <linux/types.h> + +#define HYPERBUS_CALIB_COUNT 25 + +static struct hyperbus_device *map_to_hbdev(struct map_info *map) +{ + return container_of(map, struct hyperbus_device, map); +} + +static map_word hyperbus_read16(struct map_info *map, unsigned long addr) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + map_word read_data; + + read_data.x[0] = ctlr->ops->read16(hbdev, addr); + + return read_data; +} + +static void hyperbus_write16(struct map_info *map, map_word d, + unsigned long addr) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + + ctlr->ops->write16(hbdev, addr, d.x[0]); +} + +static void hyperbus_copy_from(struct map_info *map, void *to, + unsigned long from, ssize_t len) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + + ctlr->ops->copy_from(hbdev, to, from, len); +} + +static void hyperbus_copy_to(struct map_info *map, unsigned long to, + const void *from, ssize_t len) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + + ctlr->ops->copy_to(hbdev, to, from, len); +} + +/* Default calibration routine for use by Hyperbus controller. + * Controller is calibrated by repeatedly reading known pattern ("QRY" + * string from CFI space) + * It is not enough to just ensure "QRY" string is read correctly, need + * to read mulitple times to ensure stability of the DLL lock. + */ +int hyperbus_calibrate(struct hyperbus_device *hbdev) +{ + struct map_info *map = &hbdev->map; + struct cfi_private cfi; + int count = HYPERBUS_CALIB_COUNT; + int ret; + + cfi.interleave = 1; + cfi.device_type = CFI_DEVICETYPE_X16; + cfi_send_gen_cmd(0xF0, 0, 0, map, &cfi, cfi.device_type, NULL); + cfi_send_gen_cmd(0x98, 0x55, 0, map, &cfi, cfi.device_type, NULL); + + while (count--) + cfi_qry_present(map, 0, &cfi); + + ret = cfi_qry_present(map, 0, &cfi); + cfi_qry_mode_off(0, map, &cfi); + + return ret; +} +EXPORT_SYMBOL_GPL(hyperbus_calibrate); + +int hyperbus_register_device(struct hyperbus_device *hbdev) +{ + const struct hyperbus_ops *ops; + struct hyperbus_ctlr *ctlr; + struct device_node *np; + struct map_info *map; + struct resource res; + struct device *dev; + int ret; + + if (!hbdev || !hbdev->np || !hbdev->ctlr || !hbdev->ctlr->dev) { + pr_err("hyperbus: please fill all the necessary fields!\n"); + return -EINVAL; + } + + np = hbdev->np; + ctlr = hbdev->ctlr; + if (!of_device_is_compatible(np, "cypress,hyperflash")) + return -ENODEV; + + hbdev->memtype = HYPERFLASH; + + if (of_address_to_resource(np, 0, &res)) + return -EINVAL; + + dev = ctlr->dev; + map = &hbdev->map; + map->size = resource_size(&res); + map->virt = devm_ioremap_resource(dev, &res); + if (IS_ERR(map->virt)) + return PTR_ERR(map->virt); + + map->name = dev_name(dev); + map->bankwidth = 2; + + simple_map_init(map); + ops = ctlr->ops; + if (ops) { + if (ops->read16) + map->read = hyperbus_read16; + if (ops->write16) + map->write = hyperbus_write16; + if (ops->copy_to) + map->copy_to = hyperbus_copy_to; + if (ops->copy_from) + map->copy_from = hyperbus_copy_from; + + if (ops->calibrate && !ctlr->calibrated) { + ret = ops->calibrate(hbdev); + if (!ret) { + dev_err(dev, "Calibration failed\n"); + return -ENODEV; + } + ctlr->calibrated = true; + } + } + + hbdev->mtd = do_map_probe("cfi_probe", map); + if (!hbdev->mtd) { + dev_err(dev, "probing of hyperbus device failed\n"); + return -ENODEV; + } + + hbdev->mtd->dev.parent = dev; + mtd_set_of_node(hbdev->mtd, np); + + ret = mtd_device_register(hbdev->mtd, NULL, 0); + if (ret) { + dev_err(dev, "failed to register mtd device\n"); + map_destroy(hbdev->mtd); + return ret; + } + hbdev->registered = true; + + return 0; +} +EXPORT_SYMBOL_GPL(hyperbus_register_device); + +int hyperbus_unregister_device(struct hyperbus_device *hbdev) +{ + int ret = 0; + + if (hbdev && hbdev->mtd && hbdev->registered) { + ret = mtd_device_unregister(hbdev->mtd); + map_destroy(hbdev->mtd); + } + + return ret; +} +EXPORT_SYMBOL_GPL(hyperbus_unregister_device); + +MODULE_DESCRIPTION("Hyperbus Framework"); +MODULE_LICENSE("GPL v2"); +MODULE_AUTHOR("Vignesh Raghavendra <vigneshr@ti.com>"); diff --git a/include/linux/mtd/hyperbus.h b/include/linux/mtd/hyperbus.h new file mode 100644 index 000000000000..57f273e87f29 --- /dev/null +++ b/include/linux/mtd/hyperbus.h @@ -0,0 +1,91 @@ +/* SPDX-License-Identifier: GPL-2.0 + * + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ + */ + +#ifndef __LINUX_MTD_HYPERBUS_H__ +#define __LINUX_MTD_HYPERBUS_H__ + +#include <linux/mtd/map.h> + +enum hyperbus_memtype { + HYPERFLASH, + HYPERRAM, +}; + +/** + * struct hyerbus_device - struct representing Hyperbus slave device + * @map: map_info struct for accessing MMIO Hyperbus flash memory + * @np: pointer to Hyperbus slave device node + * @mtd: pointer to MTD struct + * @ctlr: pointer to Hyperbus controller struct + * @memtype: type of memory device: Hyperflash or HyperRAM + * @registered: flag to indicate whether device is registered with MTD core + */ + +struct hyperbus_device { + struct map_info map; + struct device_node *np; + struct mtd_info *mtd; + struct hyperbus_ctlr *ctlr; + enum hyperbus_memtype memtype; + bool registered; +}; + +/** + * struct hyperbus_ops - struct representing custom Hyperbus operations + * @read16: read 16 bit of data, usually from register/ID-CFI space + * @write16: write 16 bit of data, usually to register/ID-CFI space + * @copy_from: copy data from flash memory + * @copy_to: copy data to flash memory + * @calibrate: calibrate Hyperbus controller + */ + +struct hyperbus_ops { + u16 (*read16)(struct hyperbus_device *hbdev, unsigned long addr); + void (*write16)(struct hyperbus_device *hbdev, + unsigned long addr, u16 val); + void (*copy_from)(struct hyperbus_device *hbdev, void *to, + unsigned long from, ssize_t len); + void (*copy_to)(struct hyperbus_device *dev, unsigned long to, + const void *from, ssize_t len); + int (*calibrate)(struct hyperbus_device *dev); +}; + +/** + * struct hyperbus_ctlr - struct representing Hyperbus controller + * @calibrated: flag to indicate ctlr calibration sequence is complete + * @ops: Hyperbus controller ops + */ +struct hyperbus_ctlr { + struct device *dev; + bool calibrated; + + const struct hyperbus_ops *ops; +}; + +/** + * hyperbus_calibrate - default calibration routine for use by Hyperbus ctlr. + * @hbdev: hyperbus_device to be used for calibration + * + * Return: 0 for success, others for failure. + */ +int hyperbus_calibrate(struct hyperbus_device *hbdev); + +/** + * hyperbus_register_device - probe and register a Hyperbus slave memory device + * @hbdev: hyperbus_device struct with dev, np and ctlr field populated + * + * Return: 0 for success, others for failure. + */ +int hyperbus_register_device(struct hyperbus_device *hbdev); + +/** + * hb_unregister_device - deregister Hyperbus slave memory device + * @hbdev: hyperbus_device to be unregistered + * + * Return: 0 for success, others for failure. + */ +int hyperbus_unregister_device(struct hyperbus_device *hbdev); + +#endif /* __LINUX_MTD_HYPERBUS_H__ */ -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 67+ messages in thread
* [RFC PATCH v2 3/5] mtd: Add support for Hyperbus memory devices @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Sergei Shtylyov, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Cypress' Hyperbus is Low Signal Count, High Performance Double Data Rate Bus interface between a host system master and one or more slave interfaces. Hyperbus is used to connect microprocessor, microcontroller, or ASIC devices with random access NOR flash memory (called Hyperflash) or self refresh DRAM (called HyperRAM). Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) signal and either Single-ended clock(3.0V parts) or Differential clock (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. At bus level, it follows a separate protocol described in Hyperbus specification[1]. Hyperflash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, its equivalent to x16 parallel NOR flash wrt bits per clock cycle. But Hyperbus operates at >166MHz frequencies. HyperRAM provides direct random read/write access to flash memory array. But, Hyperbus memory controllers seem to abstract implementation details and expose a simple MMIO interface to access connected flash. Add support for registering Hyperflash devices with MTD framework. MTD maps framework along with CFI chip support framework are used to support communicating with flash. Framework is modelled along the lines of spi-nor framework. Hyperbus memory controller (HBMC) drivers calls hyperbus_register_device() to register a single Hyperflash device. Hyperflash core parses MMIO access information from DT, sets up the map_info struct, probes CFI flash and registers it with MTD framework. Some HBMC masters need calibration/training sequence[3] to be carried out, in order for DLL inside the controller to lock, by reading a known string/pattern. This is done by repeatedly reading CFI Query Identification String. Calibration needs to be done before trying to detect flash as part of CFI flash probe. HyperRAM is not supported at the moment. Hyperbus specification can be found at[1] Hyperflash datasheet can be found at[2] [1] https://www.cypress.com/file/213356/download [2] https://www.cypress.com/file/213346/download [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf Table 12-5741. HyperFlash Access Sequence Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- MAINTAINERS | 7 + drivers/mtd/Kconfig | 2 + drivers/mtd/Makefile | 1 + drivers/mtd/hyperbus/Kconfig | 11 ++ drivers/mtd/hyperbus/Makefile | 3 + drivers/mtd/hyperbus/hyperbus-core.c | 183 +++++++++++++++++++++++++++ include/linux/mtd/hyperbus.h | 91 +++++++++++++ 7 files changed, 298 insertions(+) create mode 100644 drivers/mtd/hyperbus/Kconfig create mode 100644 drivers/mtd/hyperbus/Makefile create mode 100644 drivers/mtd/hyperbus/hyperbus-core.c create mode 100644 include/linux/mtd/hyperbus.h diff --git a/MAINTAINERS b/MAINTAINERS index 74e28172c637..48f1f227f65b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7188,6 +7188,13 @@ F: include/uapi/linux/hyperv.h F: tools/hv/ F: Documentation/ABI/stable/sysfs-bus-vmbus +HYPERBUS SUPPORT +M: Vignesh Raghavendra <vigneshr@ti.com> +S: Supported +F: drivers/mtd/hyperbus/ +F: include/linux/mtd/hyperbus.h +F: Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt + HYPERVISOR VIRTUAL CONSOLE DRIVER L: linuxppc-dev@lists.ozlabs.org S: Odd Fixes diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 79a8ff542883..a915ff300390 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -290,4 +290,6 @@ source "drivers/mtd/spi-nor/Kconfig" source "drivers/mtd/ubi/Kconfig" +source "drivers/mtd/hyperbus/Kconfig" + endif # MTD diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index 58fc327a5276..04c154906631 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -35,3 +35,4 @@ obj-y += chips/ lpddr/ maps/ devices/ nand/ tests/ obj-$(CONFIG_MTD_SPI_NOR) += spi-nor/ obj-$(CONFIG_MTD_UBI) += ubi/ +obj-$(CONFIG_MTD_HYPERBUS) += hyperbus/ diff --git a/drivers/mtd/hyperbus/Kconfig b/drivers/mtd/hyperbus/Kconfig new file mode 100644 index 000000000000..febbb4cdc25f --- /dev/null +++ b/drivers/mtd/hyperbus/Kconfig @@ -0,0 +1,11 @@ +menuconfig MTD_HYPERBUS + tristate "Hyperbus support" + select MTD_CFI + select MTD_MAP_BANK_WIDTH_2 + select MTD_CFI_AMDSTD + select MTD_COMPLEX_MAPPINGS + help + This is the framework for the Hyperbus which can be used by + the Hyperbus Controller driver to communicate with + Hyperflash. See Cypress Hyperbus specification for more + details diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile new file mode 100644 index 000000000000..ca61dedd730d --- /dev/null +++ b/drivers/mtd/hyperbus/Makefile @@ -0,0 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0 + +obj-$(CONFIG_MTD_HYPERBUS) += hyperbus-core.o diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c new file mode 100644 index 000000000000..4c2876c367fc --- /dev/null +++ b/drivers/mtd/hyperbus/hyperbus-core.c @@ -0,0 +1,183 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ +// Author: Vignesh Raghavendra <vigneshr@ti.com> + +#include <linux/err.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/mtd/hyperbus.h> +#include <linux/mtd/map.h> +#include <linux/mtd/mtd.h> +#include <linux/mtd/cfi.h> +#include <linux/of.h> +#include <linux/of_address.h> +#include <linux/types.h> + +#define HYPERBUS_CALIB_COUNT 25 + +static struct hyperbus_device *map_to_hbdev(struct map_info *map) +{ + return container_of(map, struct hyperbus_device, map); +} + +static map_word hyperbus_read16(struct map_info *map, unsigned long addr) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + map_word read_data; + + read_data.x[0] = ctlr->ops->read16(hbdev, addr); + + return read_data; +} + +static void hyperbus_write16(struct map_info *map, map_word d, + unsigned long addr) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + + ctlr->ops->write16(hbdev, addr, d.x[0]); +} + +static void hyperbus_copy_from(struct map_info *map, void *to, + unsigned long from, ssize_t len) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + + ctlr->ops->copy_from(hbdev, to, from, len); +} + +static void hyperbus_copy_to(struct map_info *map, unsigned long to, + const void *from, ssize_t len) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + + ctlr->ops->copy_to(hbdev, to, from, len); +} + +/* Default calibration routine for use by Hyperbus controller. + * Controller is calibrated by repeatedly reading known pattern ("QRY" + * string from CFI space) + * It is not enough to just ensure "QRY" string is read correctly, need + * to read mulitple times to ensure stability of the DLL lock. + */ +int hyperbus_calibrate(struct hyperbus_device *hbdev) +{ + struct map_info *map = &hbdev->map; + struct cfi_private cfi; + int count = HYPERBUS_CALIB_COUNT; + int ret; + + cfi.interleave = 1; + cfi.device_type = CFI_DEVICETYPE_X16; + cfi_send_gen_cmd(0xF0, 0, 0, map, &cfi, cfi.device_type, NULL); + cfi_send_gen_cmd(0x98, 0x55, 0, map, &cfi, cfi.device_type, NULL); + + while (count--) + cfi_qry_present(map, 0, &cfi); + + ret = cfi_qry_present(map, 0, &cfi); + cfi_qry_mode_off(0, map, &cfi); + + return ret; +} +EXPORT_SYMBOL_GPL(hyperbus_calibrate); + +int hyperbus_register_device(struct hyperbus_device *hbdev) +{ + const struct hyperbus_ops *ops; + struct hyperbus_ctlr *ctlr; + struct device_node *np; + struct map_info *map; + struct resource res; + struct device *dev; + int ret; + + if (!hbdev || !hbdev->np || !hbdev->ctlr || !hbdev->ctlr->dev) { + pr_err("hyperbus: please fill all the necessary fields!\n"); + return -EINVAL; + } + + np = hbdev->np; + ctlr = hbdev->ctlr; + if (!of_device_is_compatible(np, "cypress,hyperflash")) + return -ENODEV; + + hbdev->memtype = HYPERFLASH; + + if (of_address_to_resource(np, 0, &res)) + return -EINVAL; + + dev = ctlr->dev; + map = &hbdev->map; + map->size = resource_size(&res); + map->virt = devm_ioremap_resource(dev, &res); + if (IS_ERR(map->virt)) + return PTR_ERR(map->virt); + + map->name = dev_name(dev); + map->bankwidth = 2; + + simple_map_init(map); + ops = ctlr->ops; + if (ops) { + if (ops->read16) + map->read = hyperbus_read16; + if (ops->write16) + map->write = hyperbus_write16; + if (ops->copy_to) + map->copy_to = hyperbus_copy_to; + if (ops->copy_from) + map->copy_from = hyperbus_copy_from; + + if (ops->calibrate && !ctlr->calibrated) { + ret = ops->calibrate(hbdev); + if (!ret) { + dev_err(dev, "Calibration failed\n"); + return -ENODEV; + } + ctlr->calibrated = true; + } + } + + hbdev->mtd = do_map_probe("cfi_probe", map); + if (!hbdev->mtd) { + dev_err(dev, "probing of hyperbus device failed\n"); + return -ENODEV; + } + + hbdev->mtd->dev.parent = dev; + mtd_set_of_node(hbdev->mtd, np); + + ret = mtd_device_register(hbdev->mtd, NULL, 0); + if (ret) { + dev_err(dev, "failed to register mtd device\n"); + map_destroy(hbdev->mtd); + return ret; + } + hbdev->registered = true; + + return 0; +} +EXPORT_SYMBOL_GPL(hyperbus_register_device); + +int hyperbus_unregister_device(struct hyperbus_device *hbdev) +{ + int ret = 0; + + if (hbdev && hbdev->mtd && hbdev->registered) { + ret = mtd_device_unregister(hbdev->mtd); + map_destroy(hbdev->mtd); + } + + return ret; +} +EXPORT_SYMBOL_GPL(hyperbus_unregister_device); + +MODULE_DESCRIPTION("Hyperbus Framework"); +MODULE_LICENSE("GPL v2"); +MODULE_AUTHOR("Vignesh Raghavendra <vigneshr@ti.com>"); diff --git a/include/linux/mtd/hyperbus.h b/include/linux/mtd/hyperbus.h new file mode 100644 index 000000000000..57f273e87f29 --- /dev/null +++ b/include/linux/mtd/hyperbus.h @@ -0,0 +1,91 @@ +/* SPDX-License-Identifier: GPL-2.0 + * + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ + */ + +#ifndef __LINUX_MTD_HYPERBUS_H__ +#define __LINUX_MTD_HYPERBUS_H__ + +#include <linux/mtd/map.h> + +enum hyperbus_memtype { + HYPERFLASH, + HYPERRAM, +}; + +/** + * struct hyerbus_device - struct representing Hyperbus slave device + * @map: map_info struct for accessing MMIO Hyperbus flash memory + * @np: pointer to Hyperbus slave device node + * @mtd: pointer to MTD struct + * @ctlr: pointer to Hyperbus controller struct + * @memtype: type of memory device: Hyperflash or HyperRAM + * @registered: flag to indicate whether device is registered with MTD core + */ + +struct hyperbus_device { + struct map_info map; + struct device_node *np; + struct mtd_info *mtd; + struct hyperbus_ctlr *ctlr; + enum hyperbus_memtype memtype; + bool registered; +}; + +/** + * struct hyperbus_ops - struct representing custom Hyperbus operations + * @read16: read 16 bit of data, usually from register/ID-CFI space + * @write16: write 16 bit of data, usually to register/ID-CFI space + * @copy_from: copy data from flash memory + * @copy_to: copy data to flash memory + * @calibrate: calibrate Hyperbus controller + */ + +struct hyperbus_ops { + u16 (*read16)(struct hyperbus_device *hbdev, unsigned long addr); + void (*write16)(struct hyperbus_device *hbdev, + unsigned long addr, u16 val); + void (*copy_from)(struct hyperbus_device *hbdev, void *to, + unsigned long from, ssize_t len); + void (*copy_to)(struct hyperbus_device *dev, unsigned long to, + const void *from, ssize_t len); + int (*calibrate)(struct hyperbus_device *dev); +}; + +/** + * struct hyperbus_ctlr - struct representing Hyperbus controller + * @calibrated: flag to indicate ctlr calibration sequence is complete + * @ops: Hyperbus controller ops + */ +struct hyperbus_ctlr { + struct device *dev; + bool calibrated; + + const struct hyperbus_ops *ops; +}; + +/** + * hyperbus_calibrate - default calibration routine for use by Hyperbus ctlr. + * @hbdev: hyperbus_device to be used for calibration + * + * Return: 0 for success, others for failure. + */ +int hyperbus_calibrate(struct hyperbus_device *hbdev); + +/** + * hyperbus_register_device - probe and register a Hyperbus slave memory device + * @hbdev: hyperbus_device struct with dev, np and ctlr field populated + * + * Return: 0 for success, others for failure. + */ +int hyperbus_register_device(struct hyperbus_device *hbdev); + +/** + * hb_unregister_device - deregister Hyperbus slave memory device + * @hbdev: hyperbus_device to be unregistered + * + * Return: 0 for success, others for failure. + */ +int hyperbus_unregister_device(struct hyperbus_device *hbdev); + +#endif /* __LINUX_MTD_HYPERBUS_H__ */ -- 2.21.0 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply related [flat|nested] 67+ messages in thread
* [RFC PATCH v2 3/5] mtd: Add support for Hyperbus memory devices @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang, Sergei Shtylyov Cypress' Hyperbus is Low Signal Count, High Performance Double Data Rate Bus interface between a host system master and one or more slave interfaces. Hyperbus is used to connect microprocessor, microcontroller, or ASIC devices with random access NOR flash memory (called Hyperflash) or self refresh DRAM (called HyperRAM). Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) signal and either Single-ended clock(3.0V parts) or Differential clock (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. At bus level, it follows a separate protocol described in Hyperbus specification[1]. Hyperflash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, its equivalent to x16 parallel NOR flash wrt bits per clock cycle. But Hyperbus operates at >166MHz frequencies. HyperRAM provides direct random read/write access to flash memory array. But, Hyperbus memory controllers seem to abstract implementation details and expose a simple MMIO interface to access connected flash. Add support for registering Hyperflash devices with MTD framework. MTD maps framework along with CFI chip support framework are used to support communicating with flash. Framework is modelled along the lines of spi-nor framework. Hyperbus memory controller (HBMC) drivers calls hyperbus_register_device() to register a single Hyperflash device. Hyperflash core parses MMIO access information from DT, sets up the map_info struct, probes CFI flash and registers it with MTD framework. Some HBMC masters need calibration/training sequence[3] to be carried out, in order for DLL inside the controller to lock, by reading a known string/pattern. This is done by repeatedly reading CFI Query Identification String. Calibration needs to be done before trying to detect flash as part of CFI flash probe. HyperRAM is not supported at the moment. Hyperbus specification can be found at[1] Hyperflash datasheet can be found at[2] [1] https://www.cypress.com/file/213356/download [2] https://www.cypress.com/file/213346/download [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf Table 12-5741. HyperFlash Access Sequence Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- MAINTAINERS | 7 + drivers/mtd/Kconfig | 2 + drivers/mtd/Makefile | 1 + drivers/mtd/hyperbus/Kconfig | 11 ++ drivers/mtd/hyperbus/Makefile | 3 + drivers/mtd/hyperbus/hyperbus-core.c | 183 +++++++++++++++++++++++++++ include/linux/mtd/hyperbus.h | 91 +++++++++++++ 7 files changed, 298 insertions(+) create mode 100644 drivers/mtd/hyperbus/Kconfig create mode 100644 drivers/mtd/hyperbus/Makefile create mode 100644 drivers/mtd/hyperbus/hyperbus-core.c create mode 100644 include/linux/mtd/hyperbus.h diff --git a/MAINTAINERS b/MAINTAINERS index 74e28172c637..48f1f227f65b 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7188,6 +7188,13 @@ F: include/uapi/linux/hyperv.h F: tools/hv/ F: Documentation/ABI/stable/sysfs-bus-vmbus +HYPERBUS SUPPORT +M: Vignesh Raghavendra <vigneshr@ti.com> +S: Supported +F: drivers/mtd/hyperbus/ +F: include/linux/mtd/hyperbus.h +F: Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt + HYPERVISOR VIRTUAL CONSOLE DRIVER L: linuxppc-dev@lists.ozlabs.org S: Odd Fixes diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 79a8ff542883..a915ff300390 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -290,4 +290,6 @@ source "drivers/mtd/spi-nor/Kconfig" source "drivers/mtd/ubi/Kconfig" +source "drivers/mtd/hyperbus/Kconfig" + endif # MTD diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile index 58fc327a5276..04c154906631 100644 --- a/drivers/mtd/Makefile +++ b/drivers/mtd/Makefile @@ -35,3 +35,4 @@ obj-y += chips/ lpddr/ maps/ devices/ nand/ tests/ obj-$(CONFIG_MTD_SPI_NOR) += spi-nor/ obj-$(CONFIG_MTD_UBI) += ubi/ +obj-$(CONFIG_MTD_HYPERBUS) += hyperbus/ diff --git a/drivers/mtd/hyperbus/Kconfig b/drivers/mtd/hyperbus/Kconfig new file mode 100644 index 000000000000..febbb4cdc25f --- /dev/null +++ b/drivers/mtd/hyperbus/Kconfig @@ -0,0 +1,11 @@ +menuconfig MTD_HYPERBUS + tristate "Hyperbus support" + select MTD_CFI + select MTD_MAP_BANK_WIDTH_2 + select MTD_CFI_AMDSTD + select MTD_COMPLEX_MAPPINGS + help + This is the framework for the Hyperbus which can be used by + the Hyperbus Controller driver to communicate with + Hyperflash. See Cypress Hyperbus specification for more + details diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile new file mode 100644 index 000000000000..ca61dedd730d --- /dev/null +++ b/drivers/mtd/hyperbus/Makefile @@ -0,0 +1,3 @@ +# SPDX-License-Identifier: GPL-2.0 + +obj-$(CONFIG_MTD_HYPERBUS) += hyperbus-core.o diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c new file mode 100644 index 000000000000..4c2876c367fc --- /dev/null +++ b/drivers/mtd/hyperbus/hyperbus-core.c @@ -0,0 +1,183 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ +// Author: Vignesh Raghavendra <vigneshr@ti.com> + +#include <linux/err.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/mtd/hyperbus.h> +#include <linux/mtd/map.h> +#include <linux/mtd/mtd.h> +#include <linux/mtd/cfi.h> +#include <linux/of.h> +#include <linux/of_address.h> +#include <linux/types.h> + +#define HYPERBUS_CALIB_COUNT 25 + +static struct hyperbus_device *map_to_hbdev(struct map_info *map) +{ + return container_of(map, struct hyperbus_device, map); +} + +static map_word hyperbus_read16(struct map_info *map, unsigned long addr) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + map_word read_data; + + read_data.x[0] = ctlr->ops->read16(hbdev, addr); + + return read_data; +} + +static void hyperbus_write16(struct map_info *map, map_word d, + unsigned long addr) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + + ctlr->ops->write16(hbdev, addr, d.x[0]); +} + +static void hyperbus_copy_from(struct map_info *map, void *to, + unsigned long from, ssize_t len) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + + ctlr->ops->copy_from(hbdev, to, from, len); +} + +static void hyperbus_copy_to(struct map_info *map, unsigned long to, + const void *from, ssize_t len) +{ + struct hyperbus_device *hbdev = map_to_hbdev(map); + struct hyperbus_ctlr *ctlr = hbdev->ctlr; + + ctlr->ops->copy_to(hbdev, to, from, len); +} + +/* Default calibration routine for use by Hyperbus controller. + * Controller is calibrated by repeatedly reading known pattern ("QRY" + * string from CFI space) + * It is not enough to just ensure "QRY" string is read correctly, need + * to read mulitple times to ensure stability of the DLL lock. + */ +int hyperbus_calibrate(struct hyperbus_device *hbdev) +{ + struct map_info *map = &hbdev->map; + struct cfi_private cfi; + int count = HYPERBUS_CALIB_COUNT; + int ret; + + cfi.interleave = 1; + cfi.device_type = CFI_DEVICETYPE_X16; + cfi_send_gen_cmd(0xF0, 0, 0, map, &cfi, cfi.device_type, NULL); + cfi_send_gen_cmd(0x98, 0x55, 0, map, &cfi, cfi.device_type, NULL); + + while (count--) + cfi_qry_present(map, 0, &cfi); + + ret = cfi_qry_present(map, 0, &cfi); + cfi_qry_mode_off(0, map, &cfi); + + return ret; +} +EXPORT_SYMBOL_GPL(hyperbus_calibrate); + +int hyperbus_register_device(struct hyperbus_device *hbdev) +{ + const struct hyperbus_ops *ops; + struct hyperbus_ctlr *ctlr; + struct device_node *np; + struct map_info *map; + struct resource res; + struct device *dev; + int ret; + + if (!hbdev || !hbdev->np || !hbdev->ctlr || !hbdev->ctlr->dev) { + pr_err("hyperbus: please fill all the necessary fields!\n"); + return -EINVAL; + } + + np = hbdev->np; + ctlr = hbdev->ctlr; + if (!of_device_is_compatible(np, "cypress,hyperflash")) + return -ENODEV; + + hbdev->memtype = HYPERFLASH; + + if (of_address_to_resource(np, 0, &res)) + return -EINVAL; + + dev = ctlr->dev; + map = &hbdev->map; + map->size = resource_size(&res); + map->virt = devm_ioremap_resource(dev, &res); + if (IS_ERR(map->virt)) + return PTR_ERR(map->virt); + + map->name = dev_name(dev); + map->bankwidth = 2; + + simple_map_init(map); + ops = ctlr->ops; + if (ops) { + if (ops->read16) + map->read = hyperbus_read16; + if (ops->write16) + map->write = hyperbus_write16; + if (ops->copy_to) + map->copy_to = hyperbus_copy_to; + if (ops->copy_from) + map->copy_from = hyperbus_copy_from; + + if (ops->calibrate && !ctlr->calibrated) { + ret = ops->calibrate(hbdev); + if (!ret) { + dev_err(dev, "Calibration failed\n"); + return -ENODEV; + } + ctlr->calibrated = true; + } + } + + hbdev->mtd = do_map_probe("cfi_probe", map); + if (!hbdev->mtd) { + dev_err(dev, "probing of hyperbus device failed\n"); + return -ENODEV; + } + + hbdev->mtd->dev.parent = dev; + mtd_set_of_node(hbdev->mtd, np); + + ret = mtd_device_register(hbdev->mtd, NULL, 0); + if (ret) { + dev_err(dev, "failed to register mtd device\n"); + map_destroy(hbdev->mtd); + return ret; + } + hbdev->registered = true; + + return 0; +} +EXPORT_SYMBOL_GPL(hyperbus_register_device); + +int hyperbus_unregister_device(struct hyperbus_device *hbdev) +{ + int ret = 0; + + if (hbdev && hbdev->mtd && hbdev->registered) { + ret = mtd_device_unregister(hbdev->mtd); + map_destroy(hbdev->mtd); + } + + return ret; +} +EXPORT_SYMBOL_GPL(hyperbus_unregister_device); + +MODULE_DESCRIPTION("Hyperbus Framework"); +MODULE_LICENSE("GPL v2"); +MODULE_AUTHOR("Vignesh Raghavendra <vigneshr@ti.com>"); diff --git a/include/linux/mtd/hyperbus.h b/include/linux/mtd/hyperbus.h new file mode 100644 index 000000000000..57f273e87f29 --- /dev/null +++ b/include/linux/mtd/hyperbus.h @@ -0,0 +1,91 @@ +/* SPDX-License-Identifier: GPL-2.0 + * + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ + */ + +#ifndef __LINUX_MTD_HYPERBUS_H__ +#define __LINUX_MTD_HYPERBUS_H__ + +#include <linux/mtd/map.h> + +enum hyperbus_memtype { + HYPERFLASH, + HYPERRAM, +}; + +/** + * struct hyerbus_device - struct representing Hyperbus slave device + * @map: map_info struct for accessing MMIO Hyperbus flash memory + * @np: pointer to Hyperbus slave device node + * @mtd: pointer to MTD struct + * @ctlr: pointer to Hyperbus controller struct + * @memtype: type of memory device: Hyperflash or HyperRAM + * @registered: flag to indicate whether device is registered with MTD core + */ + +struct hyperbus_device { + struct map_info map; + struct device_node *np; + struct mtd_info *mtd; + struct hyperbus_ctlr *ctlr; + enum hyperbus_memtype memtype; + bool registered; +}; + +/** + * struct hyperbus_ops - struct representing custom Hyperbus operations + * @read16: read 16 bit of data, usually from register/ID-CFI space + * @write16: write 16 bit of data, usually to register/ID-CFI space + * @copy_from: copy data from flash memory + * @copy_to: copy data to flash memory + * @calibrate: calibrate Hyperbus controller + */ + +struct hyperbus_ops { + u16 (*read16)(struct hyperbus_device *hbdev, unsigned long addr); + void (*write16)(struct hyperbus_device *hbdev, + unsigned long addr, u16 val); + void (*copy_from)(struct hyperbus_device *hbdev, void *to, + unsigned long from, ssize_t len); + void (*copy_to)(struct hyperbus_device *dev, unsigned long to, + const void *from, ssize_t len); + int (*calibrate)(struct hyperbus_device *dev); +}; + +/** + * struct hyperbus_ctlr - struct representing Hyperbus controller + * @calibrated: flag to indicate ctlr calibration sequence is complete + * @ops: Hyperbus controller ops + */ +struct hyperbus_ctlr { + struct device *dev; + bool calibrated; + + const struct hyperbus_ops *ops; +}; + +/** + * hyperbus_calibrate - default calibration routine for use by Hyperbus ctlr. + * @hbdev: hyperbus_device to be used for calibration + * + * Return: 0 for success, others for failure. + */ +int hyperbus_calibrate(struct hyperbus_device *hbdev); + +/** + * hyperbus_register_device - probe and register a Hyperbus slave memory device + * @hbdev: hyperbus_device struct with dev, np and ctlr field populated + * + * Return: 0 for success, others for failure. + */ +int hyperbus_register_device(struct hyperbus_device *hbdev); + +/** + * hb_unregister_device - deregister Hyperbus slave memory device + * @hbdev: hyperbus_device to be unregistered + * + * Return: 0 for success, others for failure. + */ +int hyperbus_unregister_device(struct hyperbus_device *hbdev); + +#endif /* __LINUX_MTD_HYPERBUS_H__ */ -- 2.21.0 ^ permalink raw reply related [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 3/5] mtd: Add support for Hyperbus memory devices 2019-03-21 17:45 ` Vignesh Raghavendra (?) @ 2019-03-25 20:13 ` Sergei Shtylyov -1 siblings, 0 replies; 67+ messages in thread From: Sergei Shtylyov @ 2019-03-25 20:13 UTC (permalink / raw) To: Vignesh Raghavendra, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang Hello! On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote: > Cypress' Hyperbus is Low Signal Count, High Performance Double Data Rate It's HyperBus, according to the spec... > Bus interface between a host system master and one or more slave > interfaces. Hyperbus is used to connect microprocessor, microcontroller, > or ASIC devices with random access NOR flash memory (called Hyperflash) > or self refresh DRAM (called HyperRAM). > > Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) > signal and either Single-ended clock(3.0V parts) or Differential clock > (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. > At bus level, it follows a separate protocol described in Hyperbus > specification[1]. HyperBus. > Hyperflash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar > to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, > its equivalent to x16 parallel NOR flash wrt bits per clock cycle. But > Hyperbus operates at >166MHz frequencies. > HyperRAM provides direct random read/write access to flash memory > array. > > But, Hyperbus memory controllers seem to abstract implementation details HyperBus. > and expose a simple MMIO interface to access connected flash. > > Add support for registering Hyperflash devices with MTD framework. MTD HyperFlash. > maps framework along with CFI chip support framework are used to support > communicating with flash. > > Framework is modelled along the lines of spi-nor framework. Hyperbus HyperBus. > memory controller (HBMC) drivers calls hyperbus_register_device() to > register a single Hyperflash device. Hyperflash core parses MMIO access HyperFlash. > information from DT, sets up the map_info struct, probes CFI flash and > registers it with MTD framework. > > Some HBMC masters need calibration/training sequence[3] to be carried > out, in order for DLL inside the controller to lock, by reading a known > string/pattern. This is done by repeatedly reading CFI Query > Identification String. Calibration needs to be done before trying to detect > flash as part of CFI flash probe. > > HyperRAM is not supported at the moment. > > Hyperbus specification can be found at[1] > Hyperflash datasheet can be found at[2] HyperBus & HyperFlash. > [1] https://www.cypress.com/file/213356/download > [2] https://www.cypress.com/file/213346/download > [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf > Table 12-5741. HyperFlash Access Sequence > > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> [...] > diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c > new file mode 100644 > index 000000000000..4c2876c367fc > --- /dev/null > +++ b/drivers/mtd/hyperbus/hyperbus-core.c > @@ -0,0 +1,183 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// > +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ > +// Author: Vignesh Raghavendra <vigneshr@ti.com> > + > +#include <linux/err.h> > +#include <linux/kernel.h> > +#include <linux/module.h> > +#include <linux/mtd/hyperbus.h> > +#include <linux/mtd/map.h> > +#include <linux/mtd/mtd.h> > +#include <linux/mtd/cfi.h> > +#include <linux/of.h> > +#include <linux/of_address.h> > +#include <linux/types.h> > + > +#define HYPERBUS_CALIB_COUNT 25 As I said, this seems platform specific... [...] > +/* Default calibration routine for use by Hyperbus controller. No, there should be easy opt-out from the calibration method. Currently, the driver will have to define its own calibrate method, even if does't need any calibration... > + * Controller is calibrated by repeatedly reading known pattern ("QRY" > + * string from CFI space) > + * It is not enough to just ensure "QRY" string is read correctly, need > + * to read mulitple times to ensure stability of the DLL lock. > + */ > +int hyperbus_calibrate(struct hyperbus_device *hbdev) > +{ > + struct map_info *map = &hbdev->map; > + struct cfi_private cfi; > + int count = HYPERBUS_CALIB_COUNT; > + int ret; > + > + cfi.interleave = 1; > + cfi.device_type = CFI_DEVICETYPE_X16; > + cfi_send_gen_cmd(0xF0, 0, 0, map, &cfi, cfi.device_type, NULL); > + cfi_send_gen_cmd(0x98, 0x55, 0, map, &cfi, cfi.device_type, NULL); > + > + while (count--) > + cfi_qry_present(map, 0, &cfi); I still don't understand why we have to spin all 25 times here if QRY appears earlier than that. > + > + ret = cfi_qry_present(map, 0, &cfi); > + cfi_qry_mode_off(0, map, &cfi); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(hyperbus_calibrate); [...] > diff --git a/include/linux/mtd/hyperbus.h b/include/linux/mtd/hyperbus.h > new file mode 100644 > index 000000000000..57f273e87f29 > --- /dev/null > +++ b/include/linux/mtd/hyperbus.h > @@ -0,0 +1,91 @@ > +/* SPDX-License-Identifier: GPL-2.0 > + * > + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ > + */ > + > +#ifndef __LINUX_MTD_HYPERBUS_H__ > +#define __LINUX_MTD_HYPERBUS_H__ > + > +#include <linux/mtd/map.h> > + > +enum hyperbus_memtype { > + HYPERFLASH, > + HYPERRAM, > +}; > + > +/** > + * struct hyerbus_device - struct representing Hyperbus slave device hyperbus_device. > + * @map: map_info struct for accessing MMIO Hyperbus flash memory > + * @np: pointer to Hyperbus slave device node > + * @mtd: pointer to MTD struct > + * @ctlr: pointer to Hyperbus controller struct > + * @memtype: type of memory device: Hyperflash or HyperRAM HyperFlash. [...] > +/** > + * hyperbus_calibrate - default calibration routine for use by Hyperbus ctlr. > + * @hbdev: hyperbus_device to be used for calibration HyperBus. [...] MBR, Sergei ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 3/5] mtd: Add support for Hyperbus memory devices @ 2019-03-25 20:13 ` Sergei Shtylyov 0 siblings, 0 replies; 67+ messages in thread From: Sergei Shtylyov @ 2019-03-25 20:13 UTC (permalink / raw) To: Vignesh Raghavendra, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Hello! On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote: > Cypress' Hyperbus is Low Signal Count, High Performance Double Data Rate It's HyperBus, according to the spec... > Bus interface between a host system master and one or more slave > interfaces. Hyperbus is used to connect microprocessor, microcontroller, > or ASIC devices with random access NOR flash memory (called Hyperflash) > or self refresh DRAM (called HyperRAM). > > Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) > signal and either Single-ended clock(3.0V parts) or Differential clock > (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. > At bus level, it follows a separate protocol described in Hyperbus > specification[1]. HyperBus. > Hyperflash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar > to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, > its equivalent to x16 parallel NOR flash wrt bits per clock cycle. But > Hyperbus operates at >166MHz frequencies. > HyperRAM provides direct random read/write access to flash memory > array. > > But, Hyperbus memory controllers seem to abstract implementation details HyperBus. > and expose a simple MMIO interface to access connected flash. > > Add support for registering Hyperflash devices with MTD framework. MTD HyperFlash. > maps framework along with CFI chip support framework are used to support > communicating with flash. > > Framework is modelled along the lines of spi-nor framework. Hyperbus HyperBus. > memory controller (HBMC) drivers calls hyperbus_register_device() to > register a single Hyperflash device. Hyperflash core parses MMIO access HyperFlash. > information from DT, sets up the map_info struct, probes CFI flash and > registers it with MTD framework. > > Some HBMC masters need calibration/training sequence[3] to be carried > out, in order for DLL inside the controller to lock, by reading a known > string/pattern. This is done by repeatedly reading CFI Query > Identification String. Calibration needs to be done before trying to detect > flash as part of CFI flash probe. > > HyperRAM is not supported at the moment. > > Hyperbus specification can be found at[1] > Hyperflash datasheet can be found at[2] HyperBus & HyperFlash. > [1] https://www.cypress.com/file/213356/download > [2] https://www.cypress.com/file/213346/download > [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf > Table 12-5741. HyperFlash Access Sequence > > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> [...] > diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c > new file mode 100644 > index 000000000000..4c2876c367fc > --- /dev/null > +++ b/drivers/mtd/hyperbus/hyperbus-core.c > @@ -0,0 +1,183 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// > +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ > +// Author: Vignesh Raghavendra <vigneshr@ti.com> > + > +#include <linux/err.h> > +#include <linux/kernel.h> > +#include <linux/module.h> > +#include <linux/mtd/hyperbus.h> > +#include <linux/mtd/map.h> > +#include <linux/mtd/mtd.h> > +#include <linux/mtd/cfi.h> > +#include <linux/of.h> > +#include <linux/of_address.h> > +#include <linux/types.h> > + > +#define HYPERBUS_CALIB_COUNT 25 As I said, this seems platform specific... [...] > +/* Default calibration routine for use by Hyperbus controller. No, there should be easy opt-out from the calibration method. Currently, the driver will have to define its own calibrate method, even if does't need any calibration... > + * Controller is calibrated by repeatedly reading known pattern ("QRY" > + * string from CFI space) > + * It is not enough to just ensure "QRY" string is read correctly, need > + * to read mulitple times to ensure stability of the DLL lock. > + */ > +int hyperbus_calibrate(struct hyperbus_device *hbdev) > +{ > + struct map_info *map = &hbdev->map; > + struct cfi_private cfi; > + int count = HYPERBUS_CALIB_COUNT; > + int ret; > + > + cfi.interleave = 1; > + cfi.device_type = CFI_DEVICETYPE_X16; > + cfi_send_gen_cmd(0xF0, 0, 0, map, &cfi, cfi.device_type, NULL); > + cfi_send_gen_cmd(0x98, 0x55, 0, map, &cfi, cfi.device_type, NULL); > + > + while (count--) > + cfi_qry_present(map, 0, &cfi); I still don't understand why we have to spin all 25 times here if QRY appears earlier than that. > + > + ret = cfi_qry_present(map, 0, &cfi); > + cfi_qry_mode_off(0, map, &cfi); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(hyperbus_calibrate); [...] > diff --git a/include/linux/mtd/hyperbus.h b/include/linux/mtd/hyperbus.h > new file mode 100644 > index 000000000000..57f273e87f29 > --- /dev/null > +++ b/include/linux/mtd/hyperbus.h > @@ -0,0 +1,91 @@ > +/* SPDX-License-Identifier: GPL-2.0 > + * > + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ > + */ > + > +#ifndef __LINUX_MTD_HYPERBUS_H__ > +#define __LINUX_MTD_HYPERBUS_H__ > + > +#include <linux/mtd/map.h> > + > +enum hyperbus_memtype { > + HYPERFLASH, > + HYPERRAM, > +}; > + > +/** > + * struct hyerbus_device - struct representing Hyperbus slave device hyperbus_device. > + * @map: map_info struct for accessing MMIO Hyperbus flash memory > + * @np: pointer to Hyperbus slave device node > + * @mtd: pointer to MTD struct > + * @ctlr: pointer to Hyperbus controller struct > + * @memtype: type of memory device: Hyperflash or HyperRAM HyperFlash. [...] > +/** > + * hyperbus_calibrate - default calibration routine for use by Hyperbus ctlr. > + * @hbdev: hyperbus_device to be used for calibration HyperBus. [...] MBR, Sergei _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 3/5] mtd: Add support for Hyperbus memory devices @ 2019-03-25 20:13 ` Sergei Shtylyov 0 siblings, 0 replies; 67+ messages in thread From: Sergei Shtylyov @ 2019-03-25 20:13 UTC (permalink / raw) To: Vignesh Raghavendra, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Hello! On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote: > Cypress' Hyperbus is Low Signal Count, High Performance Double Data Rate It's HyperBus, according to the spec... > Bus interface between a host system master and one or more slave > interfaces. Hyperbus is used to connect microprocessor, microcontroller, > or ASIC devices with random access NOR flash memory (called Hyperflash) > or self refresh DRAM (called HyperRAM). > > Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) > signal and either Single-ended clock(3.0V parts) or Differential clock > (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. > At bus level, it follows a separate protocol described in Hyperbus > specification[1]. HyperBus. > Hyperflash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar > to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, > its equivalent to x16 parallel NOR flash wrt bits per clock cycle. But > Hyperbus operates at >166MHz frequencies. > HyperRAM provides direct random read/write access to flash memory > array. > > But, Hyperbus memory controllers seem to abstract implementation details HyperBus. > and expose a simple MMIO interface to access connected flash. > > Add support for registering Hyperflash devices with MTD framework. MTD HyperFlash. > maps framework along with CFI chip support framework are used to support > communicating with flash. > > Framework is modelled along the lines of spi-nor framework. Hyperbus HyperBus. > memory controller (HBMC) drivers calls hyperbus_register_device() to > register a single Hyperflash device. Hyperflash core parses MMIO access HyperFlash. > information from DT, sets up the map_info struct, probes CFI flash and > registers it with MTD framework. > > Some HBMC masters need calibration/training sequence[3] to be carried > out, in order for DLL inside the controller to lock, by reading a known > string/pattern. This is done by repeatedly reading CFI Query > Identification String. Calibration needs to be done before trying to detect > flash as part of CFI flash probe. > > HyperRAM is not supported at the moment. > > Hyperbus specification can be found at[1] > Hyperflash datasheet can be found at[2] HyperBus & HyperFlash. > [1] https://www.cypress.com/file/213356/download > [2] https://www.cypress.com/file/213346/download > [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf > Table 12-5741. HyperFlash Access Sequence > > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> [...] > diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c > new file mode 100644 > index 000000000000..4c2876c367fc > --- /dev/null > +++ b/drivers/mtd/hyperbus/hyperbus-core.c > @@ -0,0 +1,183 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// > +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ > +// Author: Vignesh Raghavendra <vigneshr@ti.com> > + > +#include <linux/err.h> > +#include <linux/kernel.h> > +#include <linux/module.h> > +#include <linux/mtd/hyperbus.h> > +#include <linux/mtd/map.h> > +#include <linux/mtd/mtd.h> > +#include <linux/mtd/cfi.h> > +#include <linux/of.h> > +#include <linux/of_address.h> > +#include <linux/types.h> > + > +#define HYPERBUS_CALIB_COUNT 25 As I said, this seems platform specific... [...] > +/* Default calibration routine for use by Hyperbus controller. No, there should be easy opt-out from the calibration method. Currently, the driver will have to define its own calibrate method, even if does't need any calibration... > + * Controller is calibrated by repeatedly reading known pattern ("QRY" > + * string from CFI space) > + * It is not enough to just ensure "QRY" string is read correctly, need > + * to read mulitple times to ensure stability of the DLL lock. > + */ > +int hyperbus_calibrate(struct hyperbus_device *hbdev) > +{ > + struct map_info *map = &hbdev->map; > + struct cfi_private cfi; > + int count = HYPERBUS_CALIB_COUNT; > + int ret; > + > + cfi.interleave = 1; > + cfi.device_type = CFI_DEVICETYPE_X16; > + cfi_send_gen_cmd(0xF0, 0, 0, map, &cfi, cfi.device_type, NULL); > + cfi_send_gen_cmd(0x98, 0x55, 0, map, &cfi, cfi.device_type, NULL); > + > + while (count--) > + cfi_qry_present(map, 0, &cfi); I still don't understand why we have to spin all 25 times here if QRY appears earlier than that. > + > + ret = cfi_qry_present(map, 0, &cfi); > + cfi_qry_mode_off(0, map, &cfi); > + > + return ret; > +} > +EXPORT_SYMBOL_GPL(hyperbus_calibrate); [...] > diff --git a/include/linux/mtd/hyperbus.h b/include/linux/mtd/hyperbus.h > new file mode 100644 > index 000000000000..57f273e87f29 > --- /dev/null > +++ b/include/linux/mtd/hyperbus.h > @@ -0,0 +1,91 @@ > +/* SPDX-License-Identifier: GPL-2.0 > + * > + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ > + */ > + > +#ifndef __LINUX_MTD_HYPERBUS_H__ > +#define __LINUX_MTD_HYPERBUS_H__ > + > +#include <linux/mtd/map.h> > + > +enum hyperbus_memtype { > + HYPERFLASH, > + HYPERRAM, > +}; > + > +/** > + * struct hyerbus_device - struct representing Hyperbus slave device hyperbus_device. > + * @map: map_info struct for accessing MMIO Hyperbus flash memory > + * @np: pointer to Hyperbus slave device node > + * @mtd: pointer to MTD struct > + * @ctlr: pointer to Hyperbus controller struct > + * @memtype: type of memory device: Hyperflash or HyperRAM HyperFlash. [...] > +/** > + * hyperbus_calibrate - default calibration routine for use by Hyperbus ctlr. > + * @hbdev: hyperbus_device to be used for calibration HyperBus. [...] MBR, Sergei ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 3/5] mtd: Add support for Hyperbus memory devices 2019-03-25 20:13 ` Sergei Shtylyov (?) @ 2019-03-26 7:51 ` Sergei Shtylyov -1 siblings, 0 replies; 67+ messages in thread From: Sergei Shtylyov @ 2019-03-26 7:51 UTC (permalink / raw) To: Vignesh Raghavendra, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang On 25.03.2019 23:13, Sergei Shtylyov wrote: >> Cypress' Hyperbus is Low Signal Count, High Performance Double Data Rate > > It's HyperBus, according to the spec... > >> Bus interface between a host system master and one or more slave >> interfaces. Hyperbus is used to connect microprocessor, microcontroller, >> or ASIC devices with random access NOR flash memory (called Hyperflash) >> or self refresh DRAM (called HyperRAM). >> >> Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) >> signal and either Single-ended clock(3.0V parts) or Differential clock >> (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. >> At bus level, it follows a separate protocol described in Hyperbus >> specification[1]. > > HyperBus. >> Hyperflash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar >> to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, >> its equivalent to x16 parallel NOR flash wrt bits per clock cycle. But >> Hyperbus operates at >166MHz frequencies. >> HyperRAM provides direct random read/write access to flash memory >> array. >> >> But, Hyperbus memory controllers seem to abstract implementation details > > HyperBus. > >> and expose a simple MMIO interface to access connected flash. >> >> Add support for registering Hyperflash devices with MTD framework. MTD > > HyperFlash. > >> maps framework along with CFI chip support framework are used to support >> communicating with flash. >> >> Framework is modelled along the lines of spi-nor framework. Hyperbus > > HyperBus. > >> memory controller (HBMC) drivers calls hyperbus_register_device() to >> register a single Hyperflash device. Hyperflash core parses MMIO access > > HyperFlash. > >> information from DT, sets up the map_info struct, probes CFI flash and >> registers it with MTD framework. >> >> Some HBMC masters need calibration/training sequence[3] to be carried >> out, in order for DLL inside the controller to lock, by reading a known >> string/pattern. This is done by repeatedly reading CFI Query >> Identification String. Calibration needs to be done before trying to detect >> flash as part of CFI flash probe. >> >> HyperRAM is not supported at the moment. >> >> Hyperbus specification can be found at[1] >> Hyperflash datasheet can be found at[2] > > HyperBus & HyperFlash. > >> [1] https://www.cypress.com/file/213356/download >> [2] https://www.cypress.com/file/213346/download >> [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf >> Table 12-5741. HyperFlash Access Sequence >> >> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> > [...] >> diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c >> new file mode 100644 >> index 000000000000..4c2876c367fc >> --- /dev/null >> +++ b/drivers/mtd/hyperbus/hyperbus-core.c >> @@ -0,0 +1,183 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +// >> +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ >> +// Author: Vignesh Raghavendra <vigneshr@ti.com> >> + >> +#include <linux/err.h> >> +#include <linux/kernel.h> >> +#include <linux/module.h> >> +#include <linux/mtd/hyperbus.h> >> +#include <linux/mtd/map.h> >> +#include <linux/mtd/mtd.h> >> +#include <linux/mtd/cfi.h> >> +#include <linux/of.h> >> +#include <linux/of_address.h> >> +#include <linux/types.h> >> + >> +#define HYPERBUS_CALIB_COUNT 25 > > As I said, this seems platform specific... > > [...] >> +/* Default calibration routine for use by Hyperbus controller. > > No, there should be easy opt-out from the calibration method. > Currently, the driver will have to define its own calibrate method, even > if does't need any calibration... Nevermind -- the method ptr can be NULL, of course, so there's easy opt-out... [...] MBR, Sergei ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 3/5] mtd: Add support for Hyperbus memory devices @ 2019-03-26 7:51 ` Sergei Shtylyov 0 siblings, 0 replies; 67+ messages in thread From: Sergei Shtylyov @ 2019-03-26 7:51 UTC (permalink / raw) To: Vignesh Raghavendra, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel On 25.03.2019 23:13, Sergei Shtylyov wrote: >> Cypress' Hyperbus is Low Signal Count, High Performance Double Data Rate > > It's HyperBus, according to the spec... > >> Bus interface between a host system master and one or more slave >> interfaces. Hyperbus is used to connect microprocessor, microcontroller, >> or ASIC devices with random access NOR flash memory (called Hyperflash) >> or self refresh DRAM (called HyperRAM). >> >> Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) >> signal and either Single-ended clock(3.0V parts) or Differential clock >> (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. >> At bus level, it follows a separate protocol described in Hyperbus >> specification[1]. > > HyperBus. >> Hyperflash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar >> to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, >> its equivalent to x16 parallel NOR flash wrt bits per clock cycle. But >> Hyperbus operates at >166MHz frequencies. >> HyperRAM provides direct random read/write access to flash memory >> array. >> >> But, Hyperbus memory controllers seem to abstract implementation details > > HyperBus. > >> and expose a simple MMIO interface to access connected flash. >> >> Add support for registering Hyperflash devices with MTD framework. MTD > > HyperFlash. > >> maps framework along with CFI chip support framework are used to support >> communicating with flash. >> >> Framework is modelled along the lines of spi-nor framework. Hyperbus > > HyperBus. > >> memory controller (HBMC) drivers calls hyperbus_register_device() to >> register a single Hyperflash device. Hyperflash core parses MMIO access > > HyperFlash. > >> information from DT, sets up the map_info struct, probes CFI flash and >> registers it with MTD framework. >> >> Some HBMC masters need calibration/training sequence[3] to be carried >> out, in order for DLL inside the controller to lock, by reading a known >> string/pattern. This is done by repeatedly reading CFI Query >> Identification String. Calibration needs to be done before trying to detect >> flash as part of CFI flash probe. >> >> HyperRAM is not supported at the moment. >> >> Hyperbus specification can be found at[1] >> Hyperflash datasheet can be found at[2] > > HyperBus & HyperFlash. > >> [1] https://www.cypress.com/file/213356/download >> [2] https://www.cypress.com/file/213346/download >> [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf >> Table 12-5741. HyperFlash Access Sequence >> >> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> > [...] >> diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c >> new file mode 100644 >> index 000000000000..4c2876c367fc >> --- /dev/null >> +++ b/drivers/mtd/hyperbus/hyperbus-core.c >> @@ -0,0 +1,183 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +// >> +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ >> +// Author: Vignesh Raghavendra <vigneshr@ti.com> >> + >> +#include <linux/err.h> >> +#include <linux/kernel.h> >> +#include <linux/module.h> >> +#include <linux/mtd/hyperbus.h> >> +#include <linux/mtd/map.h> >> +#include <linux/mtd/mtd.h> >> +#include <linux/mtd/cfi.h> >> +#include <linux/of.h> >> +#include <linux/of_address.h> >> +#include <linux/types.h> >> + >> +#define HYPERBUS_CALIB_COUNT 25 > > As I said, this seems platform specific... > > [...] >> +/* Default calibration routine for use by Hyperbus controller. > > No, there should be easy opt-out from the calibration method. > Currently, the driver will have to define its own calibrate method, even > if does't need any calibration... Nevermind -- the method ptr can be NULL, of course, so there's easy opt-out... [...] MBR, Sergei _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 3/5] mtd: Add support for Hyperbus memory devices @ 2019-03-26 7:51 ` Sergei Shtylyov 0 siblings, 0 replies; 67+ messages in thread From: Sergei Shtylyov @ 2019-03-26 7:51 UTC (permalink / raw) To: Vignesh Raghavendra, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel On 25.03.2019 23:13, Sergei Shtylyov wrote: >> Cypress' Hyperbus is Low Signal Count, High Performance Double Data Rate > > It's HyperBus, according to the spec... > >> Bus interface between a host system master and one or more slave >> interfaces. Hyperbus is used to connect microprocessor, microcontroller, >> or ASIC devices with random access NOR flash memory (called Hyperflash) >> or self refresh DRAM (called HyperRAM). >> >> Its a 8-bit data bus (DQ[7:0]) with Read-Write Data Strobe (RWDS) >> signal and either Single-ended clock(3.0V parts) or Differential clock >> (1.8V parts). It uses ChipSelect lines to select b/w multiple slaves. >> At bus level, it follows a separate protocol described in Hyperbus >> specification[1]. > > HyperBus. >> Hyperflash follows CFI AMD/Fujitsu Extended Command Set (0x0002) similar >> to that of existing parallel NORs. Since Hyperbus is x8 DDR bus, >> its equivalent to x16 parallel NOR flash wrt bits per clock cycle. But >> Hyperbus operates at >166MHz frequencies. >> HyperRAM provides direct random read/write access to flash memory >> array. >> >> But, Hyperbus memory controllers seem to abstract implementation details > > HyperBus. > >> and expose a simple MMIO interface to access connected flash. >> >> Add support for registering Hyperflash devices with MTD framework. MTD > > HyperFlash. > >> maps framework along with CFI chip support framework are used to support >> communicating with flash. >> >> Framework is modelled along the lines of spi-nor framework. Hyperbus > > HyperBus. > >> memory controller (HBMC) drivers calls hyperbus_register_device() to >> register a single Hyperflash device. Hyperflash core parses MMIO access > > HyperFlash. > >> information from DT, sets up the map_info struct, probes CFI flash and >> registers it with MTD framework. >> >> Some HBMC masters need calibration/training sequence[3] to be carried >> out, in order for DLL inside the controller to lock, by reading a known >> string/pattern. This is done by repeatedly reading CFI Query >> Identification String. Calibration needs to be done before trying to detect >> flash as part of CFI flash probe. >> >> HyperRAM is not supported at the moment. >> >> Hyperbus specification can be found at[1] >> Hyperflash datasheet can be found at[2] > > HyperBus & HyperFlash. > >> [1] https://www.cypress.com/file/213356/download >> [2] https://www.cypress.com/file/213346/download >> [3] http://www.ti.com/lit/ug/spruid7b/spruid7b.pdf >> Table 12-5741. HyperFlash Access Sequence >> >> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> > [...] >> diff --git a/drivers/mtd/hyperbus/hyperbus-core.c b/drivers/mtd/hyperbus/hyperbus-core.c >> new file mode 100644 >> index 000000000000..4c2876c367fc >> --- /dev/null >> +++ b/drivers/mtd/hyperbus/hyperbus-core.c >> @@ -0,0 +1,183 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +// >> +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ >> +// Author: Vignesh Raghavendra <vigneshr@ti.com> >> + >> +#include <linux/err.h> >> +#include <linux/kernel.h> >> +#include <linux/module.h> >> +#include <linux/mtd/hyperbus.h> >> +#include <linux/mtd/map.h> >> +#include <linux/mtd/mtd.h> >> +#include <linux/mtd/cfi.h> >> +#include <linux/of.h> >> +#include <linux/of_address.h> >> +#include <linux/types.h> >> + >> +#define HYPERBUS_CALIB_COUNT 25 > > As I said, this seems platform specific... > > [...] >> +/* Default calibration routine for use by Hyperbus controller. > > No, there should be easy opt-out from the calibration method. > Currently, the driver will have to define its own calibrate method, even > if does't need any calibration... Nevermind -- the method ptr can be NULL, of course, so there's easy opt-out... [...] MBR, Sergei ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 67+ messages in thread
* [RFC PATCH v2 4/5] dt-bindings: mtd: Add bindings for TI's AM654 Hyperbus memory controller 2019-03-21 17:45 ` Vignesh Raghavendra (?) (?) @ 2019-03-21 17:45 ` Vignesh Raghavendra -1 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang, Sergei Shtylyov Add binding documentation for TI's Hyperbus memory controller present on AM654 SoC. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- .../devicetree/bindings/mtd/ti,am654-hbmc.txt | 27 +++++++++++++++++++ MAINTAINERS | 1 + 2 files changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt new file mode 100644 index 000000000000..b70fd1795fc5 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt @@ -0,0 +1,27 @@ +Bindings for Hyperbus Memory Controller on TI's K3 family of SoCs + +Required properties: +- compatible : "ti,am654-hbmc" for AM654 SoC +- reg : Two entries: + First entry pointed to the register space of HBMC controller + Second entry pointing to the memory map region dedicated for + MMIO access to attached flash devices +- ranges : Address range allocated for each Chipselect in the MMIO space + +Example: + hbmc: hbmc@47034000 { + compatible = "ti,am654-hbmc"; + reg = <0x0 0x47034000 0x0 0x100>, + <0x5 0x00000000 0x1 0x0000000>; + power-domains = <&k3_pds 55>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */ + <0x1 0x5 0x04000000 0x4000000>; /* CS1 - 64MB + + /* Slave flash node */ + flash@0{ + compatible = "cypress,hyperflash"; + reg = <0x0 0x4000000>; + }; + }; diff --git a/MAINTAINERS b/MAINTAINERS index 48f1f227f65b..3453f397ad87 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7194,6 +7194,7 @@ S: Supported F: drivers/mtd/hyperbus/ F: include/linux/mtd/hyperbus.h F: Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt +F: Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt HYPERVISOR VIRTUAL CONSOLE DRIVER L: linuxppc-dev@lists.ozlabs.org -- 2.21.0 ^ permalink raw reply related [flat|nested] 67+ messages in thread
* [RFC PATCH v2 4/5] dt-bindings: mtd: Add bindings for TI's AM654 Hyperbus memory controller @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Sergei Shtylyov, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Add binding documentation for TI's Hyperbus memory controller present on AM654 SoC. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- .../devicetree/bindings/mtd/ti,am654-hbmc.txt | 27 +++++++++++++++++++ MAINTAINERS | 1 + 2 files changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt new file mode 100644 index 000000000000..b70fd1795fc5 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt @@ -0,0 +1,27 @@ +Bindings for Hyperbus Memory Controller on TI's K3 family of SoCs + +Required properties: +- compatible : "ti,am654-hbmc" for AM654 SoC +- reg : Two entries: + First entry pointed to the register space of HBMC controller + Second entry pointing to the memory map region dedicated for + MMIO access to attached flash devices +- ranges : Address range allocated for each Chipselect in the MMIO space + +Example: + hbmc: hbmc@47034000 { + compatible = "ti,am654-hbmc"; + reg = <0x0 0x47034000 0x0 0x100>, + <0x5 0x00000000 0x1 0x0000000>; + power-domains = <&k3_pds 55>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */ + <0x1 0x5 0x04000000 0x4000000>; /* CS1 - 64MB + + /* Slave flash node */ + flash@0{ + compatible = "cypress,hyperflash"; + reg = <0x0 0x4000000>; + }; + }; diff --git a/MAINTAINERS b/MAINTAINERS index 48f1f227f65b..3453f397ad87 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7194,6 +7194,7 @@ S: Supported F: drivers/mtd/hyperbus/ F: include/linux/mtd/hyperbus.h F: Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt +F: Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt HYPERVISOR VIRTUAL CONSOLE DRIVER L: linuxppc-dev@lists.ozlabs.org -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 67+ messages in thread
* [RFC PATCH v2 4/5] dt-bindings: mtd: Add bindings for TI's AM654 Hyperbus memory controller @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Sergei Shtylyov, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Add binding documentation for TI's Hyperbus memory controller present on AM654 SoC. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- .../devicetree/bindings/mtd/ti,am654-hbmc.txt | 27 +++++++++++++++++++ MAINTAINERS | 1 + 2 files changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt new file mode 100644 index 000000000000..b70fd1795fc5 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt @@ -0,0 +1,27 @@ +Bindings for Hyperbus Memory Controller on TI's K3 family of SoCs + +Required properties: +- compatible : "ti,am654-hbmc" for AM654 SoC +- reg : Two entries: + First entry pointed to the register space of HBMC controller + Second entry pointing to the memory map region dedicated for + MMIO access to attached flash devices +- ranges : Address range allocated for each Chipselect in the MMIO space + +Example: + hbmc: hbmc@47034000 { + compatible = "ti,am654-hbmc"; + reg = <0x0 0x47034000 0x0 0x100>, + <0x5 0x00000000 0x1 0x0000000>; + power-domains = <&k3_pds 55>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */ + <0x1 0x5 0x04000000 0x4000000>; /* CS1 - 64MB + + /* Slave flash node */ + flash@0{ + compatible = "cypress,hyperflash"; + reg = <0x0 0x4000000>; + }; + }; diff --git a/MAINTAINERS b/MAINTAINERS index 48f1f227f65b..3453f397ad87 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7194,6 +7194,7 @@ S: Supported F: drivers/mtd/hyperbus/ F: include/linux/mtd/hyperbus.h F: Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt +F: Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt HYPERVISOR VIRTUAL CONSOLE DRIVER L: linuxppc-dev@lists.ozlabs.org -- 2.21.0 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply related [flat|nested] 67+ messages in thread
* [RFC PATCH v2 4/5] dt-bindings: mtd: Add bindings for TI's AM654 Hyperbus memory controller @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang, Sergei Shtylyov Add binding documentation for TI's Hyperbus memory controller present on AM654 SoC. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- .../devicetree/bindings/mtd/ti,am654-hbmc.txt | 27 +++++++++++++++++++ MAINTAINERS | 1 + 2 files changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt new file mode 100644 index 000000000000..b70fd1795fc5 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt @@ -0,0 +1,27 @@ +Bindings for Hyperbus Memory Controller on TI's K3 family of SoCs + +Required properties: +- compatible : "ti,am654-hbmc" for AM654 SoC +- reg : Two entries: + First entry pointed to the register space of HBMC controller + Second entry pointing to the memory map region dedicated for + MMIO access to attached flash devices +- ranges : Address range allocated for each Chipselect in the MMIO space + +Example: + hbmc: hbmc@47034000 { + compatible = "ti,am654-hbmc"; + reg = <0x0 0x47034000 0x0 0x100>, + <0x5 0x00000000 0x1 0x0000000>; + power-domains = <&k3_pds 55>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */ + <0x1 0x5 0x04000000 0x4000000>; /* CS1 - 64MB + + /* Slave flash node */ + flash@0{ + compatible = "cypress,hyperflash"; + reg = <0x0 0x4000000>; + }; + }; diff --git a/MAINTAINERS b/MAINTAINERS index 48f1f227f65b..3453f397ad87 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7194,6 +7194,7 @@ S: Supported F: drivers/mtd/hyperbus/ F: include/linux/mtd/hyperbus.h F: Documentation/devicetree/bindings/mtd/cypress,hyperbus.txt +F: Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt HYPERVISOR VIRTUAL CONSOLE DRIVER L: linuxppc-dev@lists.ozlabs.org -- 2.21.0 ^ permalink raw reply related [flat|nested] 67+ messages in thread
* [RFC PATCH v2 5/5] mtd: hyperbus: Add driver for TI's Hyperbus memory controller 2019-03-21 17:45 ` Vignesh Raghavendra (?) (?) @ 2019-03-21 17:45 ` Vignesh Raghavendra -1 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang, Sergei Shtylyov Add driver for Hyperbus memory controller on TI's AM654 SoC. Programming IP is pretty simple and provides direct memory mapped access to connected Flash devices. Add basic support for the IP without DMA. Second ChipSelect is not supported for now. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- drivers/mtd/hyperbus/Kconfig | 10 +++ drivers/mtd/hyperbus/Makefile | 1 + drivers/mtd/hyperbus/hbmc_am654.c | 108 ++++++++++++++++++++++++++++++ 3 files changed, 119 insertions(+) create mode 100644 drivers/mtd/hyperbus/hbmc_am654.c diff --git a/drivers/mtd/hyperbus/Kconfig b/drivers/mtd/hyperbus/Kconfig index febbb4cdc25f..4e026eb0f045 100644 --- a/drivers/mtd/hyperbus/Kconfig +++ b/drivers/mtd/hyperbus/Kconfig @@ -9,3 +9,13 @@ menuconfig MTD_HYPERBUS the Hyperbus Controller driver to communicate with Hyperflash. See Cypress Hyperbus specification for more details + +if MTD_HYPERBUS + +config HBMC_AM654 + tristate "Hyperbus controller driver for AM65x SoC" + help + This is the driver for Hyperbus controller on TI's AM65x and + other SoCs + +endif # MTD_HYPERBUS diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile index ca61dedd730d..24abd1d43ade 100644 --- a/drivers/mtd/hyperbus/Makefile +++ b/drivers/mtd/hyperbus/Makefile @@ -1,3 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_MTD_HYPERBUS) += hyperbus-core.o +obj-$(CONFIG_HBMC_AM654) += hbmc_am654.o diff --git a/drivers/mtd/hyperbus/hbmc_am654.c b/drivers/mtd/hyperbus/hbmc_am654.c new file mode 100644 index 000000000000..abf2b0959a35 --- /dev/null +++ b/drivers/mtd/hyperbus/hbmc_am654.c @@ -0,0 +1,108 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ +// Author: Vignesh Raghavendra <vigneshr@ti.com> + +#include <linux/err.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/mtd/hyperbus.h> +#include <linux/mtd/mtd.h> +#include <linux/of.h> +#include <linux/platform_device.h> +#include <linux/pm_runtime.h> +#include <linux/types.h> + +struct am654_hbmc_priv { + struct hyperbus_ctlr ctlr; + struct hyperbus_device hbdev; + void __iomem *regbase; +}; + +static const struct hyperbus_ops am654_hbmc_ops = { + .calibrate = hyperbus_calibrate, +}; + +static int am654_hbmc_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct am654_hbmc_priv *priv; + struct resource *res; + int ret; + + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; + + platform_set_drvdata(pdev, priv); + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (!res) { + dev_err(&pdev->dev, "failed to get memory resource\n"); + return -ENOENT; + } + + priv->regbase = devm_ioremap_resource(dev, res); + if (IS_ERR(priv->regbase)) + return PTR_ERR(priv->regbase); + + pm_runtime_enable(&pdev->dev); + ret = pm_runtime_get_sync(&pdev->dev); + if (ret < 0) { + pm_runtime_put_noidle(&pdev->dev); + goto disable_pm; + } + + priv->ctlr.dev = &pdev->dev; + priv->ctlr.ops = &am654_hbmc_ops; + priv->hbdev.ctlr = &priv->ctlr; + priv->hbdev.np = of_get_next_child(dev->of_node, NULL); + ret = hyperbus_register_device(&priv->hbdev); + if (ret) { + dev_err(&pdev->dev, "failed to register controller\n"); + pm_runtime_put_sync(&pdev->dev); + goto disable_pm; + } + + return 0; +disable_pm: + pm_runtime_disable(&pdev->dev); + return ret; +} + +static int am654_hbmc_remove(struct platform_device *pdev) +{ + struct am654_hbmc_priv *priv = platform_get_drvdata(pdev); + int ret; + + ret = hyperbus_unregister_device(&priv->hbdev); + pm_runtime_put_sync(&pdev->dev); + pm_runtime_disable(&pdev->dev); + + return ret; +} + +static const struct of_device_id am654_hbmc_dt_ids[] = { + { + .compatible = "ti,am654-hbmc", + }, + { /* end of table */ } +}; + +MODULE_DEVICE_TABLE(of, am654_hbmc_dt_ids); + +static struct platform_driver am654_hbmc_platform_driver = { + .probe = am654_hbmc_probe, + .remove = am654_hbmc_remove, + .driver = { + .name = "hbmc-am654", + .of_match_table = am654_hbmc_dt_ids, + }, +}; + +module_platform_driver(am654_hbmc_platform_driver); + +MODULE_DESCRIPTION("HBMC driver for AM654 SoC"); +MODULE_LICENSE("GPL v2"); +MODULE_ALIAS("platform:hbmc-am654"); +MODULE_AUTHOR("Vignesh Raghavendra <vigneshr@ti.com>"); -- 2.21.0 ^ permalink raw reply related [flat|nested] 67+ messages in thread
* [RFC PATCH v2 5/5] mtd: hyperbus: Add driver for TI's Hyperbus memory controller @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Sergei Shtylyov, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Add driver for Hyperbus memory controller on TI's AM654 SoC. Programming IP is pretty simple and provides direct memory mapped access to connected Flash devices. Add basic support for the IP without DMA. Second ChipSelect is not supported for now. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- drivers/mtd/hyperbus/Kconfig | 10 +++ drivers/mtd/hyperbus/Makefile | 1 + drivers/mtd/hyperbus/hbmc_am654.c | 108 ++++++++++++++++++++++++++++++ 3 files changed, 119 insertions(+) create mode 100644 drivers/mtd/hyperbus/hbmc_am654.c diff --git a/drivers/mtd/hyperbus/Kconfig b/drivers/mtd/hyperbus/Kconfig index febbb4cdc25f..4e026eb0f045 100644 --- a/drivers/mtd/hyperbus/Kconfig +++ b/drivers/mtd/hyperbus/Kconfig @@ -9,3 +9,13 @@ menuconfig MTD_HYPERBUS the Hyperbus Controller driver to communicate with Hyperflash. See Cypress Hyperbus specification for more details + +if MTD_HYPERBUS + +config HBMC_AM654 + tristate "Hyperbus controller driver for AM65x SoC" + help + This is the driver for Hyperbus controller on TI's AM65x and + other SoCs + +endif # MTD_HYPERBUS diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile index ca61dedd730d..24abd1d43ade 100644 --- a/drivers/mtd/hyperbus/Makefile +++ b/drivers/mtd/hyperbus/Makefile @@ -1,3 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_MTD_HYPERBUS) += hyperbus-core.o +obj-$(CONFIG_HBMC_AM654) += hbmc_am654.o diff --git a/drivers/mtd/hyperbus/hbmc_am654.c b/drivers/mtd/hyperbus/hbmc_am654.c new file mode 100644 index 000000000000..abf2b0959a35 --- /dev/null +++ b/drivers/mtd/hyperbus/hbmc_am654.c @@ -0,0 +1,108 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ +// Author: Vignesh Raghavendra <vigneshr@ti.com> + +#include <linux/err.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/mtd/hyperbus.h> +#include <linux/mtd/mtd.h> +#include <linux/of.h> +#include <linux/platform_device.h> +#include <linux/pm_runtime.h> +#include <linux/types.h> + +struct am654_hbmc_priv { + struct hyperbus_ctlr ctlr; + struct hyperbus_device hbdev; + void __iomem *regbase; +}; + +static const struct hyperbus_ops am654_hbmc_ops = { + .calibrate = hyperbus_calibrate, +}; + +static int am654_hbmc_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct am654_hbmc_priv *priv; + struct resource *res; + int ret; + + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; + + platform_set_drvdata(pdev, priv); + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (!res) { + dev_err(&pdev->dev, "failed to get memory resource\n"); + return -ENOENT; + } + + priv->regbase = devm_ioremap_resource(dev, res); + if (IS_ERR(priv->regbase)) + return PTR_ERR(priv->regbase); + + pm_runtime_enable(&pdev->dev); + ret = pm_runtime_get_sync(&pdev->dev); + if (ret < 0) { + pm_runtime_put_noidle(&pdev->dev); + goto disable_pm; + } + + priv->ctlr.dev = &pdev->dev; + priv->ctlr.ops = &am654_hbmc_ops; + priv->hbdev.ctlr = &priv->ctlr; + priv->hbdev.np = of_get_next_child(dev->of_node, NULL); + ret = hyperbus_register_device(&priv->hbdev); + if (ret) { + dev_err(&pdev->dev, "failed to register controller\n"); + pm_runtime_put_sync(&pdev->dev); + goto disable_pm; + } + + return 0; +disable_pm: + pm_runtime_disable(&pdev->dev); + return ret; +} + +static int am654_hbmc_remove(struct platform_device *pdev) +{ + struct am654_hbmc_priv *priv = platform_get_drvdata(pdev); + int ret; + + ret = hyperbus_unregister_device(&priv->hbdev); + pm_runtime_put_sync(&pdev->dev); + pm_runtime_disable(&pdev->dev); + + return ret; +} + +static const struct of_device_id am654_hbmc_dt_ids[] = { + { + .compatible = "ti,am654-hbmc", + }, + { /* end of table */ } +}; + +MODULE_DEVICE_TABLE(of, am654_hbmc_dt_ids); + +static struct platform_driver am654_hbmc_platform_driver = { + .probe = am654_hbmc_probe, + .remove = am654_hbmc_remove, + .driver = { + .name = "hbmc-am654", + .of_match_table = am654_hbmc_dt_ids, + }, +}; + +module_platform_driver(am654_hbmc_platform_driver); + +MODULE_DESCRIPTION("HBMC driver for AM654 SoC"); +MODULE_LICENSE("GPL v2"); +MODULE_ALIAS("platform:hbmc-am654"); +MODULE_AUTHOR("Vignesh Raghavendra <vigneshr@ti.com>"); -- 2.21.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 67+ messages in thread
* [RFC PATCH v2 5/5] mtd: hyperbus: Add driver for TI's Hyperbus memory controller @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Sergei Shtylyov, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel Add driver for Hyperbus memory controller on TI's AM654 SoC. Programming IP is pretty simple and provides direct memory mapped access to connected Flash devices. Add basic support for the IP without DMA. Second ChipSelect is not supported for now. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- drivers/mtd/hyperbus/Kconfig | 10 +++ drivers/mtd/hyperbus/Makefile | 1 + drivers/mtd/hyperbus/hbmc_am654.c | 108 ++++++++++++++++++++++++++++++ 3 files changed, 119 insertions(+) create mode 100644 drivers/mtd/hyperbus/hbmc_am654.c diff --git a/drivers/mtd/hyperbus/Kconfig b/drivers/mtd/hyperbus/Kconfig index febbb4cdc25f..4e026eb0f045 100644 --- a/drivers/mtd/hyperbus/Kconfig +++ b/drivers/mtd/hyperbus/Kconfig @@ -9,3 +9,13 @@ menuconfig MTD_HYPERBUS the Hyperbus Controller driver to communicate with Hyperflash. See Cypress Hyperbus specification for more details + +if MTD_HYPERBUS + +config HBMC_AM654 + tristate "Hyperbus controller driver for AM65x SoC" + help + This is the driver for Hyperbus controller on TI's AM65x and + other SoCs + +endif # MTD_HYPERBUS diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile index ca61dedd730d..24abd1d43ade 100644 --- a/drivers/mtd/hyperbus/Makefile +++ b/drivers/mtd/hyperbus/Makefile @@ -1,3 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_MTD_HYPERBUS) += hyperbus-core.o +obj-$(CONFIG_HBMC_AM654) += hbmc_am654.o diff --git a/drivers/mtd/hyperbus/hbmc_am654.c b/drivers/mtd/hyperbus/hbmc_am654.c new file mode 100644 index 000000000000..abf2b0959a35 --- /dev/null +++ b/drivers/mtd/hyperbus/hbmc_am654.c @@ -0,0 +1,108 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ +// Author: Vignesh Raghavendra <vigneshr@ti.com> + +#include <linux/err.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/mtd/hyperbus.h> +#include <linux/mtd/mtd.h> +#include <linux/of.h> +#include <linux/platform_device.h> +#include <linux/pm_runtime.h> +#include <linux/types.h> + +struct am654_hbmc_priv { + struct hyperbus_ctlr ctlr; + struct hyperbus_device hbdev; + void __iomem *regbase; +}; + +static const struct hyperbus_ops am654_hbmc_ops = { + .calibrate = hyperbus_calibrate, +}; + +static int am654_hbmc_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct am654_hbmc_priv *priv; + struct resource *res; + int ret; + + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; + + platform_set_drvdata(pdev, priv); + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (!res) { + dev_err(&pdev->dev, "failed to get memory resource\n"); + return -ENOENT; + } + + priv->regbase = devm_ioremap_resource(dev, res); + if (IS_ERR(priv->regbase)) + return PTR_ERR(priv->regbase); + + pm_runtime_enable(&pdev->dev); + ret = pm_runtime_get_sync(&pdev->dev); + if (ret < 0) { + pm_runtime_put_noidle(&pdev->dev); + goto disable_pm; + } + + priv->ctlr.dev = &pdev->dev; + priv->ctlr.ops = &am654_hbmc_ops; + priv->hbdev.ctlr = &priv->ctlr; + priv->hbdev.np = of_get_next_child(dev->of_node, NULL); + ret = hyperbus_register_device(&priv->hbdev); + if (ret) { + dev_err(&pdev->dev, "failed to register controller\n"); + pm_runtime_put_sync(&pdev->dev); + goto disable_pm; + } + + return 0; +disable_pm: + pm_runtime_disable(&pdev->dev); + return ret; +} + +static int am654_hbmc_remove(struct platform_device *pdev) +{ + struct am654_hbmc_priv *priv = platform_get_drvdata(pdev); + int ret; + + ret = hyperbus_unregister_device(&priv->hbdev); + pm_runtime_put_sync(&pdev->dev); + pm_runtime_disable(&pdev->dev); + + return ret; +} + +static const struct of_device_id am654_hbmc_dt_ids[] = { + { + .compatible = "ti,am654-hbmc", + }, + { /* end of table */ } +}; + +MODULE_DEVICE_TABLE(of, am654_hbmc_dt_ids); + +static struct platform_driver am654_hbmc_platform_driver = { + .probe = am654_hbmc_probe, + .remove = am654_hbmc_remove, + .driver = { + .name = "hbmc-am654", + .of_match_table = am654_hbmc_dt_ids, + }, +}; + +module_platform_driver(am654_hbmc_platform_driver); + +MODULE_DESCRIPTION("HBMC driver for AM654 SoC"); +MODULE_LICENSE("GPL v2"); +MODULE_ALIAS("platform:hbmc-am654"); +MODULE_AUTHOR("Vignesh Raghavendra <vigneshr@ti.com>"); -- 2.21.0 ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply related [flat|nested] 67+ messages in thread
* [RFC PATCH v2 5/5] mtd: hyperbus: Add driver for TI's Hyperbus memory controller @ 2019-03-21 17:45 ` Vignesh Raghavendra 0 siblings, 0 replies; 67+ messages in thread From: Vignesh Raghavendra @ 2019-03-21 17:45 UTC (permalink / raw) To: Vignesh R, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang, Sergei Shtylyov Add driver for Hyperbus memory controller on TI's AM654 SoC. Programming IP is pretty simple and provides direct memory mapped access to connected Flash devices. Add basic support for the IP without DMA. Second ChipSelect is not supported for now. Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> --- drivers/mtd/hyperbus/Kconfig | 10 +++ drivers/mtd/hyperbus/Makefile | 1 + drivers/mtd/hyperbus/hbmc_am654.c | 108 ++++++++++++++++++++++++++++++ 3 files changed, 119 insertions(+) create mode 100644 drivers/mtd/hyperbus/hbmc_am654.c diff --git a/drivers/mtd/hyperbus/Kconfig b/drivers/mtd/hyperbus/Kconfig index febbb4cdc25f..4e026eb0f045 100644 --- a/drivers/mtd/hyperbus/Kconfig +++ b/drivers/mtd/hyperbus/Kconfig @@ -9,3 +9,13 @@ menuconfig MTD_HYPERBUS the Hyperbus Controller driver to communicate with Hyperflash. See Cypress Hyperbus specification for more details + +if MTD_HYPERBUS + +config HBMC_AM654 + tristate "Hyperbus controller driver for AM65x SoC" + help + This is the driver for Hyperbus controller on TI's AM65x and + other SoCs + +endif # MTD_HYPERBUS diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile index ca61dedd730d..24abd1d43ade 100644 --- a/drivers/mtd/hyperbus/Makefile +++ b/drivers/mtd/hyperbus/Makefile @@ -1,3 +1,4 @@ # SPDX-License-Identifier: GPL-2.0 obj-$(CONFIG_MTD_HYPERBUS) += hyperbus-core.o +obj-$(CONFIG_HBMC_AM654) += hbmc_am654.o diff --git a/drivers/mtd/hyperbus/hbmc_am654.c b/drivers/mtd/hyperbus/hbmc_am654.c new file mode 100644 index 000000000000..abf2b0959a35 --- /dev/null +++ b/drivers/mtd/hyperbus/hbmc_am654.c @@ -0,0 +1,108 @@ +// SPDX-License-Identifier: GPL-2.0 +// +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ +// Author: Vignesh Raghavendra <vigneshr@ti.com> + +#include <linux/err.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/mtd/hyperbus.h> +#include <linux/mtd/mtd.h> +#include <linux/of.h> +#include <linux/platform_device.h> +#include <linux/pm_runtime.h> +#include <linux/types.h> + +struct am654_hbmc_priv { + struct hyperbus_ctlr ctlr; + struct hyperbus_device hbdev; + void __iomem *regbase; +}; + +static const struct hyperbus_ops am654_hbmc_ops = { + .calibrate = hyperbus_calibrate, +}; + +static int am654_hbmc_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct am654_hbmc_priv *priv; + struct resource *res; + int ret; + + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; + + platform_set_drvdata(pdev, priv); + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + if (!res) { + dev_err(&pdev->dev, "failed to get memory resource\n"); + return -ENOENT; + } + + priv->regbase = devm_ioremap_resource(dev, res); + if (IS_ERR(priv->regbase)) + return PTR_ERR(priv->regbase); + + pm_runtime_enable(&pdev->dev); + ret = pm_runtime_get_sync(&pdev->dev); + if (ret < 0) { + pm_runtime_put_noidle(&pdev->dev); + goto disable_pm; + } + + priv->ctlr.dev = &pdev->dev; + priv->ctlr.ops = &am654_hbmc_ops; + priv->hbdev.ctlr = &priv->ctlr; + priv->hbdev.np = of_get_next_child(dev->of_node, NULL); + ret = hyperbus_register_device(&priv->hbdev); + if (ret) { + dev_err(&pdev->dev, "failed to register controller\n"); + pm_runtime_put_sync(&pdev->dev); + goto disable_pm; + } + + return 0; +disable_pm: + pm_runtime_disable(&pdev->dev); + return ret; +} + +static int am654_hbmc_remove(struct platform_device *pdev) +{ + struct am654_hbmc_priv *priv = platform_get_drvdata(pdev); + int ret; + + ret = hyperbus_unregister_device(&priv->hbdev); + pm_runtime_put_sync(&pdev->dev); + pm_runtime_disable(&pdev->dev); + + return ret; +} + +static const struct of_device_id am654_hbmc_dt_ids[] = { + { + .compatible = "ti,am654-hbmc", + }, + { /* end of table */ } +}; + +MODULE_DEVICE_TABLE(of, am654_hbmc_dt_ids); + +static struct platform_driver am654_hbmc_platform_driver = { + .probe = am654_hbmc_probe, + .remove = am654_hbmc_remove, + .driver = { + .name = "hbmc-am654", + .of_match_table = am654_hbmc_dt_ids, + }, +}; + +module_platform_driver(am654_hbmc_platform_driver); + +MODULE_DESCRIPTION("HBMC driver for AM654 SoC"); +MODULE_LICENSE("GPL v2"); +MODULE_ALIAS("platform:hbmc-am654"); +MODULE_AUTHOR("Vignesh Raghavendra <vigneshr@ti.com>"); -- 2.21.0 ^ permalink raw reply related [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 5/5] mtd: hyperbus: Add driver for TI's Hyperbus memory controller 2019-03-21 17:45 ` Vignesh Raghavendra (?) @ 2019-03-26 10:40 ` Sergei Shtylyov -1 siblings, 0 replies; 67+ messages in thread From: Sergei Shtylyov @ 2019-03-26 10:40 UTC (permalink / raw) To: Vignesh Raghavendra, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: Greg Kroah-Hartman, Arnd Bergmann, linux-mtd, devicetree, linux-kernel, linux-arm-kernel, tudor.ambarus, nsekhar, Mason Yang On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote: > Add driver for Hyperbus memory controller on TI's AM654 SoC. Programming > IP is pretty simple and provides direct memory mapped access to > connected Flash devices. > > Add basic support for the IP without DMA. Second ChipSelect is not > supported for now. > > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> [...] > diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile > index ca61dedd730d..24abd1d43ade 100644 > --- a/drivers/mtd/hyperbus/Makefile > +++ b/drivers/mtd/hyperbus/Makefile > @@ -1,3 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0 > > obj-$(CONFIG_MTD_HYPERBUS) += hyperbus-core.o > +obj-$(CONFIG_HBMC_AM654) += hbmc_am654.o > diff --git a/drivers/mtd/hyperbus/hbmc_am654.c b/drivers/mtd/hyperbus/hbmc_am654.c > new file mode 100644 > index 000000000000..abf2b0959a35 > --- /dev/null > +++ b/drivers/mtd/hyperbus/hbmc_am654.c > @@ -0,0 +1,108 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// > +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ > +// Author: Vignesh Raghavendra <vigneshr@ti.com> > + > +#include <linux/err.h> > +#include <linux/kernel.h> > +#include <linux/module.h> > +#include <linux/mtd/hyperbus.h> > +#include <linux/mtd/mtd.h> > +#include <linux/of.h> > +#include <linux/platform_device.h> > +#include <linux/pm_runtime.h> > +#include <linux/types.h> > + > +struct am654_hbmc_priv { > + struct hyperbus_ctlr ctlr; > + struct hyperbus_device hbdev; > + void __iomem *regbase; > +}; > + > +static const struct hyperbus_ops am654_hbmc_ops = { > + .calibrate = hyperbus_calibrate, > +}; > + > +static int am654_hbmc_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct am654_hbmc_priv *priv; > + struct resource *res; > + int ret; > + > + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); > + if (!priv) > + return -ENOMEM; > + > + platform_set_drvdata(pdev, priv); > + > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + if (!res) { This is redundant as devm_ioremap_resource() checks for !res anyway. > + dev_err(&pdev->dev, "failed to get memory resource\n"); > + return -ENOENT; > + } > + > + priv->regbase = devm_ioremap_resource(dev, res); BTW, there's devm_platform_ioremap_resource() now... [...] MBR, Sergei ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 5/5] mtd: hyperbus: Add driver for TI's Hyperbus memory controller @ 2019-03-26 10:40 ` Sergei Shtylyov 0 siblings, 0 replies; 67+ messages in thread From: Sergei Shtylyov @ 2019-03-26 10:40 UTC (permalink / raw) To: Vignesh Raghavendra, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote: > Add driver for Hyperbus memory controller on TI's AM654 SoC. Programming > IP is pretty simple and provides direct memory mapped access to > connected Flash devices. > > Add basic support for the IP without DMA. Second ChipSelect is not > supported for now. > > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> [...] > diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile > index ca61dedd730d..24abd1d43ade 100644 > --- a/drivers/mtd/hyperbus/Makefile > +++ b/drivers/mtd/hyperbus/Makefile > @@ -1,3 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0 > > obj-$(CONFIG_MTD_HYPERBUS) += hyperbus-core.o > +obj-$(CONFIG_HBMC_AM654) += hbmc_am654.o > diff --git a/drivers/mtd/hyperbus/hbmc_am654.c b/drivers/mtd/hyperbus/hbmc_am654.c > new file mode 100644 > index 000000000000..abf2b0959a35 > --- /dev/null > +++ b/drivers/mtd/hyperbus/hbmc_am654.c > @@ -0,0 +1,108 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// > +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ > +// Author: Vignesh Raghavendra <vigneshr@ti.com> > + > +#include <linux/err.h> > +#include <linux/kernel.h> > +#include <linux/module.h> > +#include <linux/mtd/hyperbus.h> > +#include <linux/mtd/mtd.h> > +#include <linux/of.h> > +#include <linux/platform_device.h> > +#include <linux/pm_runtime.h> > +#include <linux/types.h> > + > +struct am654_hbmc_priv { > + struct hyperbus_ctlr ctlr; > + struct hyperbus_device hbdev; > + void __iomem *regbase; > +}; > + > +static const struct hyperbus_ops am654_hbmc_ops = { > + .calibrate = hyperbus_calibrate, > +}; > + > +static int am654_hbmc_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct am654_hbmc_priv *priv; > + struct resource *res; > + int ret; > + > + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); > + if (!priv) > + return -ENOMEM; > + > + platform_set_drvdata(pdev, priv); > + > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + if (!res) { This is redundant as devm_ioremap_resource() checks for !res anyway. > + dev_err(&pdev->dev, "failed to get memory resource\n"); > + return -ENOENT; > + } > + > + priv->regbase = devm_ioremap_resource(dev, res); BTW, there's devm_platform_ioremap_resource() now... [...] MBR, Sergei _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [RFC PATCH v2 5/5] mtd: hyperbus: Add driver for TI's Hyperbus memory controller @ 2019-03-26 10:40 ` Sergei Shtylyov 0 siblings, 0 replies; 67+ messages in thread From: Sergei Shtylyov @ 2019-03-26 10:40 UTC (permalink / raw) To: Vignesh Raghavendra, David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut, Richard Weinberger, Rob Herring Cc: devicetree, Arnd Bergmann, tudor.ambarus, Greg Kroah-Hartman, nsekhar, linux-kernel, linux-mtd, Mason Yang, linux-arm-kernel On 03/21/2019 08:45 PM, Vignesh Raghavendra wrote: > Add driver for Hyperbus memory controller on TI's AM654 SoC. Programming > IP is pretty simple and provides direct memory mapped access to > connected Flash devices. > > Add basic support for the IP without DMA. Second ChipSelect is not > supported for now. > > Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> [...] > diff --git a/drivers/mtd/hyperbus/Makefile b/drivers/mtd/hyperbus/Makefile > index ca61dedd730d..24abd1d43ade 100644 > --- a/drivers/mtd/hyperbus/Makefile > +++ b/drivers/mtd/hyperbus/Makefile > @@ -1,3 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0 > > obj-$(CONFIG_MTD_HYPERBUS) += hyperbus-core.o > +obj-$(CONFIG_HBMC_AM654) += hbmc_am654.o > diff --git a/drivers/mtd/hyperbus/hbmc_am654.c b/drivers/mtd/hyperbus/hbmc_am654.c > new file mode 100644 > index 000000000000..abf2b0959a35 > --- /dev/null > +++ b/drivers/mtd/hyperbus/hbmc_am654.c > @@ -0,0 +1,108 @@ > +// SPDX-License-Identifier: GPL-2.0 > +// > +// Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/ > +// Author: Vignesh Raghavendra <vigneshr@ti.com> > + > +#include <linux/err.h> > +#include <linux/kernel.h> > +#include <linux/module.h> > +#include <linux/mtd/hyperbus.h> > +#include <linux/mtd/mtd.h> > +#include <linux/of.h> > +#include <linux/platform_device.h> > +#include <linux/pm_runtime.h> > +#include <linux/types.h> > + > +struct am654_hbmc_priv { > + struct hyperbus_ctlr ctlr; > + struct hyperbus_device hbdev; > + void __iomem *regbase; > +}; > + > +static const struct hyperbus_ops am654_hbmc_ops = { > + .calibrate = hyperbus_calibrate, > +}; > + > +static int am654_hbmc_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct am654_hbmc_priv *priv; > + struct resource *res; > + int ret; > + > + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); > + if (!priv) > + return -ENOMEM; > + > + platform_set_drvdata(pdev, priv); > + > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + if (!res) { This is redundant as devm_ioremap_resource() checks for !res anyway. > + dev_err(&pdev->dev, "failed to get memory resource\n"); > + return -ENOENT; > + } > + > + priv->regbase = devm_ioremap_resource(dev, res); BTW, there's devm_platform_ioremap_resource() now... [...] MBR, Sergei ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 67+ messages in thread
end of thread, other threads:[~2019-04-02 9:03 UTC | newest] Thread overview: 67+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-03-21 17:45 [RFC PATCH v2 0/5] MTD: Add Initial Hyperbus support Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-21 17:45 ` [RFC PATCH v2 1/5] mtd: cfi_cmdset_0002: Add support for polling status register Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-21 18:11 ` Joakim Tjernlund 2019-03-21 18:11 ` Joakim Tjernlund 2019-03-21 18:11 ` Joakim Tjernlund 2019-03-21 18:11 ` Joakim Tjernlund 2019-03-25 12:57 ` Vignesh Raghavendra 2019-03-25 12:57 ` Vignesh Raghavendra 2019-03-25 12:57 ` Vignesh Raghavendra 2019-03-25 12:57 ` Vignesh Raghavendra 2019-03-25 13:51 ` Joakim Tjernlund 2019-03-25 13:51 ` Joakim Tjernlund 2019-03-25 13:51 ` Joakim Tjernlund 2019-03-25 13:51 ` Joakim Tjernlund 2019-03-25 17:06 ` Vignesh Raghavendra 2019-03-25 17:06 ` Vignesh Raghavendra 2019-03-25 17:06 ` Vignesh Raghavendra 2019-03-25 17:06 ` Vignesh Raghavendra 2019-03-25 17:24 ` Joakim Tjernlund 2019-03-25 17:24 ` Joakim Tjernlund 2019-03-25 17:24 ` Joakim Tjernlund 2019-03-25 17:24 ` Joakim Tjernlund 2019-04-02 9:03 ` Vignesh Raghavendra 2019-04-02 9:03 ` Vignesh Raghavendra 2019-04-02 9:03 ` Vignesh Raghavendra 2019-04-02 9:03 ` Vignesh Raghavendra 2019-03-24 16:23 ` Sergei Shtylyov 2019-03-24 16:23 ` Sergei Shtylyov 2019-03-24 16:23 ` Sergei Shtylyov 2019-03-21 17:45 ` [RFC PATCH v2 2/5] dt-bindings: mtd: Add binding documentation for Hyperbus memory devices Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-24 16:18 ` Sergei Shtylyov 2019-03-24 16:18 ` Sergei Shtylyov 2019-03-24 16:18 ` Sergei Shtylyov 2019-03-25 13:10 ` Vignesh Raghavendra 2019-03-25 13:10 ` Vignesh Raghavendra 2019-03-25 13:10 ` Vignesh Raghavendra 2019-03-25 13:10 ` Vignesh Raghavendra 2019-03-21 17:45 ` [RFC PATCH v2 3/5] mtd: Add support " Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-25 20:13 ` Sergei Shtylyov 2019-03-25 20:13 ` Sergei Shtylyov 2019-03-25 20:13 ` Sergei Shtylyov 2019-03-26 7:51 ` Sergei Shtylyov 2019-03-26 7:51 ` Sergei Shtylyov 2019-03-26 7:51 ` Sergei Shtylyov 2019-03-21 17:45 ` [RFC PATCH v2 4/5] dt-bindings: mtd: Add bindings for TI's AM654 Hyperbus memory controller Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-21 17:45 ` [RFC PATCH v2 5/5] mtd: hyperbus: Add driver for TI's " Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-21 17:45 ` Vignesh Raghavendra 2019-03-26 10:40 ` Sergei Shtylyov 2019-03-26 10:40 ` Sergei Shtylyov 2019-03-26 10:40 ` Sergei Shtylyov
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.