* [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
^ 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
_______________________________________________
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 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: 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 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: 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 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: 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 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: 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 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: 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 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: 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 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: 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 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: 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 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: 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 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: 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
* 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: 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 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: 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 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 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
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 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 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-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-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
^ 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
_______________________________________________
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
(?)
(?)
@ 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: 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 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: 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 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: 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 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: 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
(?)
(?)
@ 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: 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 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: 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
(?)
(?)
@ 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
^ 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
_______________________________________________
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-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 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
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
(?)
@ 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 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-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 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 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 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 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
^ 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
_______________________________________________
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
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.