Skip to contentSkip to conversation

mtd: nand: add Broadcom NAND controller support

PATCH Applied Brian Norris 3 participants 22 messages May 13, 2015 – May 15, 2015

Subsystems (6)
lore
Share & tools
lore
#0 lore raw

v4 cover mtd: nand: add Broadcom NAND controller support

Hi,

This is the fourth (and final?) version of support for the Broadcom BCM7xxx Set-Top Box NAND controller. This controller has been used in a variety of Broadcom SoCs.

Tested to work on Cygnus, BCM7445, and BCM63138.

Summary changelog:

v1 -> v2:
* add NAND to DTS for BCM7445 / BCM97445SVMB
* rename DT binding file to have 'brcm,' prefix
* catch DMA mapping errors
* fixup timeout / error messages (hex, remove misleading info)
* MODULE_LICENSE("GPL v2")
* fix incorrect comments
* print why we fail, when checking for supported controller revisions
* disable prefetch when using Flash DMA (see FIXME); will re-enable once we get a good erased-page verification scheme merged

v2 -> v3:
* rebase to v4.1-rc1
* add SoC-specific infrastructure, to help support other SoCs:
- add BCM63138 support
- add iProc/Cygnus support
* disable prefetch on v6.1

v3 -> v4:
* move to brcmnand/ subdirectory
* add MAINTAINERS entry
* fixup endianness issues (only use __raw_xxx on MIPS BE)
* split core NAND support into library, with tiny platform drivers for STB (BCM7xxx), iProc, and BCM63138
* restructure DT binding, so all SoC extras become part of main controller node

Brian Norris (10):
Documentation: devicetree: add binding doc for Broadcom NAND
controller
mtd: nand: add NAND driver "library" for Broadcom STB NAND controller
mtd: brcmnand: add support for STB chips
ARM: bcm7445: add NAND to DTS
Documentation: devicetree: brcmstb_nand: add BCM63138 and Cygnus/iProc
mtd: brcmnand: add extra SoC support to library
mtd: brcmnand: add support for Broadcom's IPROC family
mtd: brcmnand: add BCM63138 support
ARM: bcm63138: add NAND DT support
MAINTAINERS: add entry for new brcmnand/ directory

Ray Jui (1):
ARM: dts: cygnus: Enable NAND support for Cygnus

 .../devicetree/bindings/mtd/brcm,brcmnand.txt      |  150 ++
 MAINTAINERS                                        |    6 +
 arch/arm/boot/dts/bcm-cygnus.dtsi                  |   12 +
 arch/arm/boot/dts/bcm63138.dtsi                    |   11 +
 arch/arm/boot/dts/bcm7445-bcm97445svmb.dts         |   23 +
 arch/arm/boot/dts/bcm7445.dtsi                     |   22 +
 arch/arm/boot/dts/bcm958300k.dts                   |   16 +
 arch/arm/boot/dts/bcm963138dvt.dts                 |   12 +
 drivers/mtd/nand/Kconfig                           |    8 +
 drivers/mtd/nand/Makefile                          |    1 +
 drivers/mtd/nand/brcmnand/Makefile                 |    6 +
 drivers/mtd/nand/brcmnand/bcm63138_nand.c          |  111 +
 drivers/mtd/nand/brcmnand/brcmnand.c               | 2246 ++++++++++++++++++++
 drivers/mtd/nand/brcmnand/brcmnand.h               |   73 +
 drivers/mtd/nand/brcmnand/brcmstb_nand.c           |   44 +
 drivers/mtd/nand/brcmnand/iproc_nand.c             |  150 ++
 16 files changed, 2891 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
 create mode 100644 drivers/mtd/nand/brcmnand/Makefile
 create mode 100644 drivers/mtd/nand/brcmnand/bcm63138_nand.c
 create mode 100644 drivers/mtd/nand/brcmnand/brcmnand.c
 create mode 100644 drivers/mtd/nand/brcmnand/brcmnand.h
 create mode 100644 drivers/mtd/nand/brcmnand/brcmstb_nand.c
 create mode 100644 drivers/mtd/nand/brcmnand/iproc_nand.c
Signature · 1 line
1.9.1
#1 lore raw

PATCH v4 1/11 Documentation: devicetree: add binding doc for Broadcom NAND controller

---
v4: no change

 .../devicetree/bindings/mtd/brcm,brcmnand.txt      | 110 +++++++++++++++++++++
 1 file changed, 110 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt new file +110 -0
new file mode 100644
index 000000000000..662c857e74fe
@@ -0,0 +1,110 @@
+* Broadcom STB NAND Controller
+
+The Broadcom Set-Top Box NAND controller supports low-level access to raw NAND
+flash chips. It has a memory-mapped register interface for both control
+registers and for its data input/output buffer. On some SoCs, this controller is
+paired with a custom DMA engine (inventively named "Flash DMA") which supports
+basic PROGRAM and READ functions, among other features.
+
+This controller was originally designed for STB SoCs (BCM7xxx) but is now
+available on a variety of Broadcom SoCs, including some BCM3xxx, BCM63xx, and
+iProc/Cygnus. Its history includes several similar (but not fully register
+compatible) versions.
+
+Required properties:
+- compatible       : should contain "brcm,brcmnand" and an appropriate version
+                      compatibility string, like "brcm,brcmnand-v7.0"
+                      Possible values:
+                         brcm,brcmnand-v4.0
+                         brcm,brcmnand-v5.0
+                         brcm,brcmnand-v6.0
+                         brcm,brcmnand-v6.1
+                         brcm,brcmnand-v7.0
+                         brcm,brcmnand-v7.1
+                         brcm,brcmnand
+- reg              : the register start and length for NAND register region.
+                     (optional) Flash DMA register range (if present)
+                     (optional) NAND flash cache range (if at non-standard offset)
+- reg-names        : a list of the names corresponding to the previous register
+                     ranges. Should contain "nand" and (optionally)
+                     "flash-dma" and/or "nand-cache".
+- interrupts       : The NAND CTLRDY interrupt and (if Flash DMA is available)
+                     FLASH_DMA_DONE
+- interrupt-names  : May be "nand_ctlrdy" or "flash_dma_done"
+- interrupt-parent : See standard interrupt bindings
+- #address-cells   : <1> - subnodes give the chip-select number
+- #size-cells      : <0>
+
+Optional properties:
+- brcm,nand-has-wp          : Some versions of this IP include a write-protect
+                              (WP) control bit. It is always available on >=
+                              v7.0. Use this property to describe the rare
+                              earlier versions of this core that include WP
+
+* NAND chip-select
+
+Each controller (compatible: "brcm,brcmnand") may contain one or more subnodes
+to represent enabled chip-selects which (may) contain NAND flash chips. Their
+properties are as follows.
+
+Required properties:
+- compatible                : should contain "brcm,nandcs"
+- reg                       : a single integer representing the chip-select
+                              number (e.g., 0, 1, 2, etc.)
+- #address-cells            : see partition.txt
+- #size-cells               : see partition.txt
+- nand-ecc-strength         : see nand.txt
+- nand-ecc-step-size        : must be 512 or 1024. See nand.txt
+
+Optional properties:
+- nand-on-flash-bbt         : boolean, to enable the on-flash BBT for this
+                              chip-select. See nand.txt
+- brcm,nand-oob-sector-size : integer, to denote the spare area sector size
+                              expected for the ECC layout in use. This size, in
+                              addition to the strength and step-size,
+                              determines how the hardware BCH engine will lay
+                              out the parity bytes it stores on the flash.
+                              This property can be automatically determined by
+                              the flash geometry (particularly the NAND page
+                              and OOB size) in many cases, but when booting
+                              from NAND, the boot controller has only a limited
+                              number of available options for its default ECC
+                              layout.
+
+Each nandcs device node may optionally contain sub-nodes describing the flash
+partition mapping. See partition.txt for more detail.
+
+Example:
+
+nand@f0442800 {
+	compatible = "brcm,brcmnand-v7.0", "brcm,brcmnand";
+	reg = <0xF0442800 0x600>,
+	      <0xF0443000 0x100>;
+	reg-names = "nand", "flash-dma";
+	interrupt-parent = <&hif_intr2_intc>;
+	interrupts = <24>, <4>;
+
+	#address-cells = <1>;
+	#size-cells = <0>;
+
+	nandcs@1 {
+		compatible = "brcm,nandcs";
+		reg = <1>; // Chip select 1
+		nand-on-flash-bbt;
+		nand-ecc-strength = <12>;
+		nand-ecc-step-size = <512>;
+
+		// Partitions
+		#address-cells = <1>;  // <2>, for 64-bit offset
+		#size-cells = <1>;     // <2>, for 64-bit length
+		flash0.rootfs@0 {
+			reg = <0 0x10000000>;
+		};
+		flash0@0 {
+			reg = <0 0>; // MTDPART_SIZ_FULL
+		};
+		flash0.kernel@10000000 {
+			reg = <0x10000000 0x400000>;
+		};
+	};
+};
Signature · 6 lines
1.9.1


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
#2 lore raw

PATCH v4 2/11 mtd: nand: add NAND driver "library" for Broadcom STB NAND controller

In reply to Brian Norris

This core originated in Set-Top Box chips (BCM7xxx) but is used in a variety of other Broadcom chips, including some BCM63xxx, BCM33xx, and iProc/Cygnus. It's been used only on ARM and MIPS SoCs, so restrict it to those architectures.

There are multiple revisions of this core throughout the years, and almost every version broke register compatibility in some small way, but with some effort, this driver is able to support v4.0, v5.0, v6.x, v7.0, and v7.1. It's been tested on v5.0, v6.0, v6.1, v7.0, and v7.1 recently, so there hopefully are no more lurking inconsistencies.

This patch adds just some library support, on which platform drivers can be built.

---
v4: library-ized, with platform-driver support moved to a different module

 drivers/mtd/nand/Kconfig             |    8 +
 drivers/mtd/nand/Makefile            |    1 +
 drivers/mtd/nand/brcmnand/Makefile   |    1 +
 drivers/mtd/nand/brcmnand/brcmnand.c | 2195 ++++++++++++++++++++++++++++++++++
 drivers/mtd/nand/brcmnand/brcmnand.h |   58 +
 5 files changed, 2263 insertions(+)
 create mode 100644 drivers/mtd/nand/brcmnand/Makefile
 create mode 100644 drivers/mtd/nand/brcmnand/brcmnand.c
 create mode 100644 drivers/mtd/nand/brcmnand/brcmnand.h
drivers/mtd/nand/Kconfig +8 -0
index 5897d8d8fa5a..3587017b209a 100644
@@ -394,6 +394,14 @@ config MTD_NAND_GPMI_NAND
 	 block, such as SD card. So pay attention to it when you enable
 	 the GPMI.
 
+config MTD_NAND_BRCMSTB
+	tristate "Broadcom STB NAND controller"
+	depends on ARM || MIPS
+	help
+	  Enables the Broadcom NAND controller driver. The controller was
+	  originally designed for Set-Top Box but is used on various BCM7xxx,
+	  BCM3xxx, BCM63xxx, iProc/Cygnus and more.
+
 config MTD_NAND_BCM47XXNFLASH
 	tristate "Support for NAND flash on BCM4706 BCMA bus"
 	depends on BCMA_NFLASH
drivers/mtd/nand/Makefile +1 -0
index 582bbd05aff7..7fd5f1e7ad5e 100644
@@ -52,5 +52,6 @@ obj-$(CONFIG_MTD_NAND_XWAY)		+= xway_nand.o
 obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH)	+= bcm47xxnflash/
 obj-$(CONFIG_MTD_NAND_SUNXI)		+= sunxi_nand.o
 obj-$(CONFIG_MTD_NAND_HISI504)	        += hisi504_nand.o
+obj-$(CONFIG_MTD_NAND_BRCMSTB)		+= brcmnand/
 
 nand-objs := nand_base.o nand_bbt.o nand_timings.o
drivers/mtd/nand/brcmnand/Makefile new file +1 -0
new file mode 100644
index 000000000000..a1b3e3ebe440
@@ -0,0 +1 @@
+obj-$(CONFIG_MTD_NAND_BRCMSTB)		+= brcmnand.o
drivers/mtd/nand/brcmnand/brcmnand.c new file +2195 -0

2,195 lines not on this page · raw message

drivers/mtd/nand/brcmnand/brcmnand.h new file +58 -0

58 lines not on this page · raw message

Signature · 1 line
1.9.1
#3 lore raw

PATCH v4 3/11 mtd: brcmnand: add support for STB chips

In reply to Brian Norris

BCM7xxx chips are supported entirely by the library code, since they use generic irqchip interfaces and don't need any extra SoC-specific configuration.

---
v4: pulled stub platform driver into its own file as part of the
library-ization. This is also important, to keep the STB driver from overriding the iproc_nand driver, when seeing a compatible property like:

compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1", "brcm,brcmnand";

 drivers/mtd/nand/brcmnand/Makefile       |  1 +
 drivers/mtd/nand/brcmnand/brcmstb_nand.c | 44 ++++++++++++++++++++++++++++++++
 2 files changed, 45 insertions(+)
 create mode 100644 drivers/mtd/nand/brcmnand/brcmstb_nand.c
drivers/mtd/nand/brcmnand/Makefile +1 -0
index a1b3e3ebe440..b7b24f8277cc 100644
@@ -1 +1,2 @@
+obj-$(CONFIG_MTD_NAND_BRCMSTB)		+= brcmstb_nand.o
 obj-$(CONFIG_MTD_NAND_BRCMSTB)		+= brcmnand.o
drivers/mtd/nand/brcmnand/brcmstb_nand.c new file +44 -0

44 lines not on this page · raw message

Signature · 1 line
1.9.1
#4 lore raw

PATCH v4 4/11 ARM: bcm7445: add NAND to DTS

In reply to Brian Norris

---
v4: no change

 arch/arm/boot/dts/bcm7445-bcm97445svmb.dts | 23 +++++++++++++++++++++++
 arch/arm/boot/dts/bcm7445.dtsi             | 22 ++++++++++++++++++++++
 2 files changed, 45 insertions(+)
arch/arm/boot/dts/bcm7445-bcm97445svmb.dts +23 -0
index 9eec2ac1112f..0bb8d17e4c2d 100644
@@ -12,3 +12,26 @@
 		      <0x00 0x80000000 0x00 0x40000000>;
 	};
 };
+
+&nand {
+	status = "okay";
+
+	nandcs@1 {
+		compatible = "brcm,nandcs";
+		reg = <1>;
+		nand-ecc-step-size = <512>;
+		nand-ecc-strength = <8>;
+		nand-on-flash-bbt;
+
+		#size-cells = <2>;
+		#address-cells = <2>;
+
+		flash1.rootfs0@0 {
+			reg = <0x0 0x0 0x0 0x80000000>;
+		};
+
+		flash1.rootfs1@80000000 {
+			reg = <0x0 0x80000000 0x0 0x80000000>;
+		};
+	};
+};
arch/arm/boot/dts/bcm7445.dtsi +22 -0
index 39ac7840d7ee..33447d82b7cf 100644
@@ -108,6 +108,28 @@
 			brcm,int-map-mask = <0x25c>, <0x7000000>;
 			brcm,int-fwd-mask = <0x70000>;
 		};
+
+		hif_intr2_intc: interrupt-controller@3e1000 {
+			compatible = "brcm,l2-intc";
+			reg = <0x3e1000 0x30>;
+			interrupt-controller;
+			#interrupt-cells = <1>;
+			interrupts = <GIC_SPI 0x20 0x0>;
+			interrupt-parent = <&gic>;
+			interrupt-names = "hif";
+		};
+
+		nand: nand@3e2800 {
+			status = "disabled";
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "brcm,brcmnand-v7.1", "brcm,brcmnand";
+			reg-names = "nand", "flash-dma";
+			reg = <0x3e2800 0x600>, <0x3e3000 0x2c>;
+			interrupt-parent = <&hif_intr2_intc>;
+			interrupts = <24>, <4>;
+			interrupt-names = "nand_ctlrdy", "flash_dma_done";
+		};
 	};
 
 	smpboot {
Signature · 1 line
1.9.1
#5 lore raw

PATCH v4 5/11 Documentation: devicetree: brcmstb_nand: add BCM63138 and Cygnus/iProc

In reply to Brian Norris

Add notes to describe how some SoCs integrate this NAND core a little differently, and so we define extra compatibility strings and register resources/names.

---
v4: reworked to include all NAND + SoC info directly in the NAND controller
node

 .../devicetree/bindings/mtd/brcm,brcmnand.txt      | 48 ++++++++++++++++++++--
 1 file changed, 44 insertions(+), 4 deletions(-)
Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt +44 -4
index 662c857e74fe..4ff7128ee3b2 100644
@@ -12,9 +12,14 @@ iProc/Cygnus. Its history includes several similar (but not fully register
 compatible) versions.
 
 Required properties:
-- compatible       : should contain "brcm,brcmnand" and an appropriate version
-                      compatibility string, like "brcm,brcmnand-v7.0"
-                      Possible values:
+- compatible       : May contain an SoC-specific compatibility string (see below)
+                     to account for any SoC-specific hardware bits that may be
+                     added on top of the base core controller.
+                     In addition, must contain compatibility information about
+                     the core NAND controller, of the following form:
+                     "brcm,brcmnand" and an appropriate version compatibility
+                     string, like "brcm,brcmnand-v7.0"
+                     Possible values:
                          brcm,brcmnand-v4.0
                          brcm,brcmnand-v5.0
                          brcm,brcmnand-v6.0
@@ -30,7 +35,11 @@ Required properties:
                      "flash-dma" and/or "nand-cache".
 - interrupts       : The NAND CTLRDY interrupt and (if Flash DMA is available)
                      FLASH_DMA_DONE
-- interrupt-names  : May be "nand_ctlrdy" or "flash_dma_done"
+- interrupt-names  : May be "nand_ctlrdy" or "flash_dma_done", if broken out as
+                     individual interrupts.
+                     May be "nand", if the SoC has the individual NAND
+                     interrupts multiplexed behind another custom piece of
+                     hardware
 - interrupt-parent : See standard interrupt bindings
 - #address-cells   : <1> - subnodes give the chip-select number
 - #size-cells      : <0>
@@ -41,6 +50,36 @@ Optional properties:
                               v7.0. Use this property to describe the rare
                               earlier versions of this core that include WP
 
+ -- Additonal SoC-specific NAND controller properties --
+
+The NAND controller is integrated differently on the variety of SoCs on which it
+is found. Part of this integration involves providing status and enable bits
+with which to control the 8 exposed NAND interrupts, as well as hardware for
+configuring the endianness of the data bus. On some SoCs, these features are
+handled via standard, modular components (e.g., their interrupts look like a
+normal IRQ chip), but on others, they are controlled in unique and interesting
+ways, sometimes with registers that lump multiple NAND-related functions
+together. The former case can be described simply by the standard interrupts
+properties in the main controller node. But for the latter exceptional cases,
+we define additional 'compatible' properties and associated register resources within the NAND controller node above.
+
+ - compatible: Can be one of several SoC-specific strings. Each SoC may have
+   different requirements for its additional properties, as described below each
+   bullet point below.
+
+   * "brcm,nand-bcm63138"
+     - reg: (required) the 'NAND_INT_BASE' register range, with separate status
+       and enable registers
+     - reg-names: (required) "nand-int-base"
+
+   * "brcm,nand-iproc"
+     - reg: (required) the "IDM" register range, for interrupt enable and APB
+       bus access endianness configuration, and the "EXT" register range,
+       for interrupt status/ack.
+     - reg-names: (required) a list of the names corresponding to the previous
+       register ranges. Should contain "iproc-idm" and "iproc-ext".
+
+
 * NAND chip-select
 
 Each controller (compatible: "brcm,brcmnand") may contain one or more subnodes
@@ -74,6 +113,7 @@ Optional properties:
 Each nandcs device node may optionally contain sub-nodes describing the flash
 partition mapping. See partition.txt for more detail.
 
+
 Example:
 
 nand@f0442800 {
Signature · 6 lines
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#6 lore raw

PATCH v4 6/11 mtd: brcmnand: add extra SoC support to library

In reply to Brian Norris

There are a few small hooks required for chips like BCM63138 and the iProc family. Let's introduce those now.

---
v4: refactored along with the library-ization

 drivers/mtd/nand/brcmnand/brcmnand.c | 61 +++++++++++++++++++++++++++++++++---
 drivers/mtd/nand/brcmnand/brcmnand.h | 15 +++++++++
 2 files changed, 71 insertions(+), 5 deletions(-)
drivers/mtd/nand/brcmnand/brcmnand.c +56 -5
index fb81aac8d4ef..a780768fe5e0 100644
@@ -119,6 +119,9 @@ struct brcmnand_controller {
 	unsigned int		dma_irq;
 	int			nand_version;
 
+	/* Some SoCs provide custom interrupt status register(s) */
+	struct brcmnand_soc	*soc;
+
 	int			cmd_pending;
 	bool			dma_pending;
 	struct completion	done;
@@ -965,6 +968,17 @@ static irqreturn_t brcmnand_ctlrdy_irq(int irq, void *data)
 	return IRQ_HANDLED;
 }
 
+/* Handle SoC-specific interrupt hardware */
+static irqreturn_t brcmnand_irq(int irq, void *data)
+{
+	struct brcmnand_controller *ctrl = data;
+
+	if (ctrl->soc->ctlrdy_ack(ctrl->soc))
+		return brcmnand_ctlrdy_irq(irq, data);
+
+	return IRQ_NONE;
+}
+
 static irqreturn_t brcmnand_dma_irq(int irq, void *data)
 {
 	struct brcmnand_controller *ctrl = data;
@@ -1153,12 +1167,18 @@ static void brcmnand_cmdfunc(struct mtd_info *mtd, unsigned command,
 	if (native_cmd == CMD_PARAMETER_READ ||
 			native_cmd == CMD_PARAMETER_CHANGE_COL) {
 		int i;
+
+		brcmnand_soc_data_bus_prepare(ctrl->soc);
+
 		/*
 		 * Must cache the FLASH_CACHE now, since changes in
 		 * SECTOR_SIZE_1K may invalidate it
 		 */
 		for (i = 0; i < FC_WORDS; i++)
 			ctrl->flash_cache[i] = brcmnand_read_fc(ctrl, i);
+
+		brcmnand_soc_data_bus_unprepare(ctrl->soc);
+
 		/* Cleanup from HW quirk: restore SECTOR_SIZE_1K */
 		if (host->hwcfg.sector_size_1k)
 			brcmnand_set_sector_size_1k(host,
@@ -1371,10 +1391,15 @@ static int brcmnand_read_by_pio(struct mtd_info *mtd, struct nand_chip *chip,
 		brcmnand_send_cmd(host, CMD_PAGE_READ);
 		brcmnand_waitfunc(mtd, chip);
 
-		if (likely(buf))
+		if (likely(buf)) {
+			brcmnand_soc_data_bus_prepare(ctrl->soc);
+
 			for (j = 0; j < FC_WORDS; j++, buf++)
 				*buf = brcmnand_read_fc(ctrl, j);
 
+			brcmnand_soc_data_bus_unprepare(ctrl->soc);
+		}
+
 		if (oob)
 			oob += read_oob_from_regs(ctrl, i, oob,
 					mtd->oobsize / trans,
@@ -1546,12 +1571,17 @@ static int brcmnand_write(struct mtd_info *mtd, struct nand_chip *chip,
 				   lower_32_bits(addr));
 		(void)brcmnand_read_reg(ctrl, BRCMNAND_CMD_ADDRESS);
 
-		if (buf)
+		if (buf) {
+			brcmnand_soc_data_bus_prepare(ctrl->soc);
+
 			for (j = 0; j < FC_WORDS; j++, buf++)
 				brcmnand_write_fc(ctrl, j, *buf);
-		else if (oob)
+
+			brcmnand_soc_data_bus_unprepare(ctrl->soc);
+		} else if (oob) {
 			for (j = 0; j < FC_WORDS; j++)
 				brcmnand_write_fc(ctrl, j, 0xffffffff);
+		}
 
 		if (oob) {
 			oob += write_oob_to_regs(ctrl, i, oob,
@@ -1995,6 +2025,11 @@ static int brcmnand_resume(struct device *dev)
 	brcmnand_write_reg(ctrl, BRCMNAND_CS_XOR, ctrl->nand_cs_nand_xor);
 	brcmnand_write_reg(ctrl, BRCMNAND_CORR_THRESHOLD,
 			ctrl->corr_stat_threshold);
+	if (ctrl->soc) {
+		/* Clear/re-enable interrupt */
+		ctrl->soc->ctlrdy_ack(ctrl->soc);
+		ctrl->soc->ctlrdy_set_enabled(ctrl->soc, true);
+	}
 
 	list_for_each_entry(host, &ctrl->host_list, node) {
 		struct mtd_info *mtd = &host->mtd;
@@ -2139,8 +2174,24 @@ int brcmnand_probe(struct platform_device *pdev, struct brcmnand_soc *soc)
 		return -ENODEV;
 	}
 
-	ret = devm_request_irq(dev, ctrl->irq, brcmnand_ctlrdy_irq, 0,
-			DRV_NAME, ctrl);
+	/*
+	 * Some SoCs integrate this controller (e.g., its interrupt bits) in
+	 * interesting ways
+	 */
+	if (soc) {
+		ctrl->soc = soc;
+
+		ret = devm_request_irq(dev, ctrl->irq, brcmnand_irq, 0,
+				       DRV_NAME, ctrl);
+
+		/* Enable interrupt */
+		ctrl->soc->ctlrdy_ack(ctrl->soc);
+		ctrl->soc->ctlrdy_set_enabled(ctrl->soc, true);
+	} else {
+		/* Use standard interrupt infrastructure */
+		ret = devm_request_irq(dev, ctrl->irq, brcmnand_ctlrdy_irq, 0,
+				       DRV_NAME, ctrl);
+	}
 	if (ret < 0) {
 		dev_err(dev, "can't allocate IRQ %d: error %d\n",
 			ctrl->irq, ret);
drivers/mtd/nand/brcmnand/brcmnand.h +15 -0
index 5118b29555f0..a20c73630b7b 100644
@@ -23,8 +23,23 @@ struct dev_pm_ops;
 struct brcmnand_soc {
 	struct platform_device *pdev;
 	void *priv;
+	bool (*ctlrdy_ack)(struct brcmnand_soc *soc);
+	void (*ctlrdy_set_enabled)(struct brcmnand_soc *soc, bool en);
+	void (*prepare_data_bus)(struct brcmnand_soc *soc, bool prepare);
 };
 
+static inline void brcmnand_soc_data_bus_prepare(struct brcmnand_soc *soc)
+{
+	if (soc && soc->prepare_data_bus)
+		soc->prepare_data_bus(soc, true);
+}
+
+static inline void brcmnand_soc_data_bus_unprepare(struct brcmnand_soc *soc)
+{
+	if (soc && soc->prepare_data_bus)
+		soc->prepare_data_bus(soc, false);
+}
+
 static inline u32 brcmnand_readl(void __iomem *addr)
 {
 	/*
Signature · 6 lines
1.9.1


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
#7 lore raw

PATCH v4 7/11 mtd: brcmnand: add support for Broadcom's IPROC family

In reply to Brian Norris

---
v4: split into its own proper platform driver

 drivers/mtd/nand/brcmnand/Makefile     |   3 +
 drivers/mtd/nand/brcmnand/iproc_nand.c | 150 +++++++++++++++++++++++++++++++++
 2 files changed, 153 insertions(+)
 create mode 100644 drivers/mtd/nand/brcmnand/iproc_nand.c
drivers/mtd/nand/brcmnand/Makefile +3 -0
index b7b24f8277cc..e78c3b932fd1 100644
@@ -1,2 +1,5 @@
+# link order matters; don't link the more generic brcmstb_nand.o before the
+# more specific iproc_nand.o, for instance
+obj-$(CONFIG_MTD_NAND_BRCMSTB)		+= iproc_nand.o
 obj-$(CONFIG_MTD_NAND_BRCMSTB)		+= brcmstb_nand.o
 obj-$(CONFIG_MTD_NAND_BRCMSTB)		+= brcmnand.o
drivers/mtd/nand/brcmnand/iproc_nand.c new file +150 -0

150 lines not on this page · raw message

Signature · 6 lines
1.9.1


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
#8 lore raw

PATCH v4 8/11 mtd: brcmnand: add BCM63138 support

In reply to Brian Norris

---
v4: split into its own proper platform driver

 drivers/mtd/nand/brcmnand/Makefile        |   1 +
 drivers/mtd/nand/brcmnand/bcm63138_nand.c | 111 ++++++++++++++++++++++++++++++
 2 files changed, 112 insertions(+)
 create mode 100644 drivers/mtd/nand/brcmnand/bcm63138_nand.c
drivers/mtd/nand/brcmnand/Makefile +1 -0
index e78c3b932fd1..45a091e0550f 100644
@@ -1,5 +1,6 @@
 # link order matters; don't link the more generic brcmstb_nand.o before the
 # more specific iproc_nand.o, for instance
 obj-$(CONFIG_MTD_NAND_BRCMSTB)		+= iproc_nand.o
+obj-$(CONFIG_MTD_NAND_BRCMSTB)		+= bcm63138_nand.o
 obj-$(CONFIG_MTD_NAND_BRCMSTB)		+= brcmstb_nand.o
 obj-$(CONFIG_MTD_NAND_BRCMSTB)		+= brcmnand.o
drivers/mtd/nand/brcmnand/bcm63138_nand.c new file +111 -0

111 lines not on this page · raw message

Signature · 6 lines
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#9 lore raw

Re: [PATCH v4 08/11] mtd: brcmnand: add BCM63138 support

Quoted 13 lines · On Tuesday 12 May 2015 17:53:41 Brian Norris wrote:
drivers/mtd/nand/brcmnand/bcm63138_nand.c new file +13 -0
+static bool bcm63138_nand_intc_ack(struct brcmnand_soc *soc)
+{
+       struct bcm63138_nand_soc_priv *priv = soc->priv;
+       void __iomem *mmio = priv->base + BCM63138_NAND_INT_STATUS;
+       u32 val = brcmnand_readl(mmio);
+
+       if (val & BCM63138_CTLRDY) {
+               brcmnand_writel(val & ~BCM63138_CTLRDY, mmio);
+               return true;
+       }
+
+       return false;
+}

...

Quoted 5 lines
drivers/mtd/nand/brcmnand/bcm63138_nand.c new file +5 -0
+static int bcm63138_nand_probe(struct platform_device *pdev)
+{
+       struct device *dev = &pdev->dev;
+       struct bcm63138_nand_soc_priv *priv;
+       struct brcmnand_soc *soc;

drivers/mtd/nand/brcmnand/bcm63138_nand.c line 78

Quoted 10 lines
drivers/mtd/nand/brcmnand/bcm63138_nand.c new file +10 -0
+       struct resource *res;
+
+       soc = devm_kzalloc(dev, sizeof(*soc), GFP_KERNEL);
+       if (!soc)
+               return -ENOMEM;
+
+       priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+       if (!priv)
+               return -ENOMEM;
+

This is a slightly unconventional method of doing the abstraction. For consistency with a lot of other drivers, I'd do it like this:

struct bcm63138_controller {
	void __iomem *base;
	brcmnand_controller parent;
};

static bool bcm63138_nand_intc_ack(struct brcmnand_controller *parent)

{
	struct bcm63138_controller *controller;
	controller = container_of(parent, struct brcmnand_controller, parent);

	...
}

static int bcm63138_nand_probe(...)

{
	struct bcm63138_controller *controller;

	controller = devm_kzalloc(dev, sizeof(*controller), GFP_KERNEL);
	...
	return brcmnand_probe(pdev, &controller->parent);
}

This also simplifies the probe() functions and means less pointer chasing.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#10 lore raw

Re: [PATCH v4 08/11] mtd: brcmnand: add BCM63138 support

Quoted 34 lines · Arnd Bergmann
Quoted 13 lines · On Tuesday 12 May 2015 17:53:41 Brian Norris wrote:
drivers/mtd/nand/brcmnand/bcm63138_nand.c new file +13 -0
+static bool bcm63138_nand_intc_ack(struct brcmnand_soc *soc)
+{
+       struct bcm63138_nand_soc_priv *priv = soc->priv;
+       void __iomem *mmio = priv->base + BCM63138_NAND_INT_STATUS;
+       u32 val = brcmnand_readl(mmio);
+
+       if (val & BCM63138_CTLRDY) {
+               brcmnand_writel(val & ~BCM63138_CTLRDY, mmio);
+               return true;
+       }
+
+       return false;
+}

...

Quoted 5 lines
drivers/mtd/nand/brcmnand/bcm63138_nand.c new file +5 -0
+static int bcm63138_nand_probe(struct platform_device *pdev)
+{
+       struct device *dev = &pdev->dev;
+       struct bcm63138_nand_soc_priv *priv;
+       struct brcmnand_soc *soc;

drivers/mtd/nand/brcmnand/bcm63138_nand.c line 78

Quoted 10 lines
drivers/mtd/nand/brcmnand/bcm63138_nand.c new file +10 -0
+       struct resource *res;
+
+       soc = devm_kzalloc(dev, sizeof(*soc), GFP_KERNEL);
+       if (!soc)
+               return -ENOMEM;
+
+       priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+       if (!priv)
+               return -ENOMEM;
+

This is a slightly unconventional method of doing the abstraction. For consistency with a lot of other drivers, I'd do it like this:

Quoted 4 lines
struct bcm63138_controller {
	void __iomem *base;
	brcmnand_controller parent;
};

Does it really make sense to publicize all of the brcmnand_controller details to each of the constituent drivers? I was intentionally keeping them private, with a very small and well-defined interface provided for shim SoC drivers.

This is kind of a problem that has plagued the wider MTD (and esp. NAND) subsystem in general; we expose a ton of details to low-level drivers, and they're free to muck with things however they want, as long as it ends up working. I'd rather be more intentional in what I expose.

Quoted 17 lines

static bool bcm63138_nand_intc_ack(struct brcmnand_controller *parent)

{
	struct bcm63138_controller *controller;
	controller = container_of(parent, struct brcmnand_controller, parent);

	...
}

static int bcm63138_nand_probe(...)

{
	struct bcm63138_controller *controller;

	controller = devm_kzalloc(dev, sizeof(*controller), GFP_KERNEL);
	...
	return brcmnand_probe(pdev, &controller->parent);
}
Quoted 1 line

This also simplifies the probe() functions and means less pointer chasing.

I could still avoid one pointer chase and one extra memory allocation by embedding 'struct brcmnand_soc' in a 'struct bcm63138_nand_soc'. e.g.:

struct bcm63138_nand_soc {
	void __iomem *base;
	struct brcmnand_soc soc;
};

static bool bcm63138_nand_intc_ack(struct brcmnand_soc *soc)

{
	struct bcm63138_nand_soc *priv;
	priv = container_of(soc, struct bcm63138_nand_soc, soc);

	...
}

static int bcm63138_nand_probe(...)

{
	struct bcm63138_nand_soc *priv;

	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
	...
	return brcmnand_probe(pdev, &priv->soc);
}

Brian

#11 lore raw

Re: [PATCH v4 08/11] mtd: brcmnand: add BCM63138 support

Quoted 16 lines · On Wednesday 13 May 2015 12:45:21 Brian Norris wrote:
Quoted 9 lines · Arnd Bergmann

On Tuesday 12 May 2015 17:53:41 Brian Norris wrote:

This is a slightly unconventional method of doing the abstraction. For consistency with a lot of other drivers, I'd do it like this:

struct bcm63138_controller {
	void __iomem *base;
	brcmnand_controller parent;
};

Does it really make sense to publicize all of the brcmnand_controller details to each of the constituent drivers? I was intentionally keeping them private, with a very small and well-defined interface provided for shim SoC drivers.

Quoted 4 lines

This is kind of a problem that has plagued the wider MTD (and esp. NAND) subsystem in general; we expose a ton of details to low-level drivers, and they're free to muck with things however they want, as long as it ends up working. I'd rather be more intentional in what I expose.

In most cases like this, the soc-specific glue drivers eventually need access to some of the struct members anyway, but of course it's possible that you don't need that here.

Quoted 35 lines
Quoted 17 lines

static bool bcm63138_nand_intc_ack(struct brcmnand_controller *parent)

{
	struct bcm63138_controller *controller;
	controller = container_of(parent, struct brcmnand_controller, parent);

	...
}

static int bcm63138_nand_probe(...)

{
	struct bcm63138_controller *controller;

	controller = devm_kzalloc(dev, sizeof(*controller), GFP_KERNEL);
	...
	return brcmnand_probe(pdev, &controller->parent);
}
Quoted 1 line

This also simplifies the probe() functions and means less pointer chasing.

I could still avoid one pointer chase and one extra memory allocation by embedding 'struct brcmnand_soc' in a 'struct bcm63138_nand_soc'. e.g.:

struct bcm63138_nand_soc {
	void __iomem *base;
	struct brcmnand_soc soc;
};

static bool bcm63138_nand_intc_ack(struct brcmnand_soc *soc)

{
	struct bcm63138_nand_soc *priv;
	priv = container_of(soc, struct bcm63138_nand_soc, soc);

	...
}
Quoted 8 lines

static int bcm63138_nand_probe(...)

{
	struct bcm63138_nand_soc *priv;

	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
	...
	return brcmnand_probe(pdev, &priv->soc);
}

That would make struct brcmnand_soc an empty structure, right? I think that's fine though, at least it avoids passing void pointers and it avoids one of the two allocations you do.

There is another variation of this model, which some drivers use:

static int bcm63138_nand_probe(...)

{
	struct bcm63138_nand_soc *priv;
	struct brcmnand_controller *controller;

	controller = brcmnand_controller_alloc(dev, sizeof (*priv));

	priv = brcmnand_controller_priv(controller);

	...

	return brcmnand_register(controller);
}

struct brcmnand_controller *brcmnand_controller_alloc(struct device *pdev, size_t extra)

{
	struct brcmnand_controller *p = dev_kzalloc(dev, sizeof(*p) + extra);

	...

	return p;
}

void *brcmnand_controller_priv(brcmnand_controller *p)

{
	/* extra data follows at the next byte after the controller structure */
	return p + 1;
}

Some subsystem maintainers prefer this model over the other one, up to you.

Arnd

#12 lore raw

Re: [PATCH v4 08/11] mtd: brcmnand: add BCM63138 support

Quoted 21 lines · Arnd Bergmann
Quoted 20 lines · On Wednesday 13 May 2015 12:45:21 Brian Norris wrote:

I could still avoid one pointer chase and one extra memory allocation by embedding 'struct brcmnand_soc' in a 'struct bcm63138_nand_soc'. e.g.:

struct bcm63138_nand_soc {
	void __iomem *base;
	struct brcmnand_soc soc;
};

static bool bcm63138_nand_intc_ack(struct brcmnand_soc *soc)

{
	struct bcm63138_nand_soc *priv;
	priv = container_of(soc, struct bcm63138_nand_soc, soc);

	...
}

static int bcm63138_nand_probe(...)

{
	struct bcm63138_nand_soc *priv;
Quoted 6 lines
Quoted 4 lines
	priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
	...
	return brcmnand_probe(pdev, &priv->soc);
}

That would make struct brcmnand_soc an empty structure, right?

No, it still contains the function pointers for our callbacks, which is the entire point. I guess it's more of a 'nand_soc_ops' structure than a 'nand_soc' pointer now though.

Quoted 28 lines

I think that's fine though, at least it avoids passing void pointers and it avoids one of the two allocations you do.

There is another variation of this model, which some drivers use:

static int bcm63138_nand_probe(...)

{
	struct bcm63138_nand_soc *priv;
	struct brcmnand_controller *controller;

	controller = brcmnand_controller_alloc(dev, sizeof (*priv));

	priv = brcmnand_controller_priv(controller);

	...

	return brcmnand_register(controller);
}

struct brcmnand_controller *brcmnand_controller_alloc(struct device *pdev, size_t extra)

{
	struct brcmnand_controller *p = dev_kzalloc(dev, sizeof(*p) + extra);

	...

	return p;
}
Quoted 5 lines

void *brcmnand_controller_priv(brcmnand_controller *p)

{
	/* extra data follows at the next byte after the controller structure */
	return p + 1;
}

Ah, so this allows the driver to still be agnostic about the contents of brcmnand_controller.

Quoted 1 line

Some subsystem maintainers prefer this model over the other one, up to you.

I'll probably stick with mine. But thanks for the suggestion. I'll keep it in mind. I was actually thinking of imitating this model for other larger portions of drivers/mtd/nand/, to aid in bounding what drivers are expected to do vs. allowing the core subsystem to handle things.

Brian

#13 lore raw

Re: [PATCH v4 08/11] mtd: brcmnand: add BCM63138 support

Quoted 10 lines · On Wednesday 13 May 2015 13:24:15 Brian Norris wrote:
Quoted 10 lines
Quoted 9 lines

static int bcm63138_nand_probe(...)

{
    struct bcm63138_nand_soc *priv;

    priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
    ...
    return brcmnand_probe(pdev, &priv->soc);
}
Quoted 6 lines
Quoted 1 line

That would make struct brcmnand_soc an empty structure, right?

No, it still contains the function pointers for our callbacks, which is the entire point. I guess it's more of a 'nand_soc_ops' structure than a 'nand_soc' pointer now though.

Ah, I see.

This is fine for a small number of function pointers, but if you ever get a structure like this with a lot of pointers, it's better to keep them separate, so you can define the structure of function pointers as 'static const' in the client driver, as we do for a number of other operations.

The main advantage of that is that you don't have to assign the members manually at run-time, but also putting them into the read-only segment makes it harder for an attacker to overwrite a known function pointer with a pointer to an exploit (assuming they have limited control over writing to kernel memory).

Arnd

#14 lore raw

PATCH v4 9/11 ARM: bcm63138: add NAND DT support

In reply to Brian Norris

---
v4: account for reworked DT binding

 arch/arm/boot/dts/bcm63138.dtsi    | 11 +++++++++++
 arch/arm/boot/dts/bcm963138dvt.dts | 12 ++++++++++++
 2 files changed, 23 insertions(+)
arch/arm/boot/dts/bcm63138.dtsi +11 -0
index f46329c8ad75..6c14b4c93b2d 100644
@@ -131,5 +131,16 @@
 			clock-names = "periph";
 			status = "disabled";
 		};
+
+		nand: nand@2000 {
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "brcm,nand-bcm63138", "brcm,brcmnand-v7.0", "brcm,brcmnand";
+			reg = <0x2000 0x600>, <0xf0 0x10>;
+			reg-names = "nand", "nand-int-base";
+			status = "disabled";
+			interrupts = <GIC_SPI 38 0>;
+			interrupt-names = "nand";
+		};
 	};
 };
arch/arm/boot/dts/bcm963138dvt.dts +12 -0
index 69c93395ecd2..370aa2cfddf2 100644
@@ -28,3 +28,15 @@
 &serial1 {
 	status = "okay";
 };
+
+&nand {
+	status = "okay";
+
+	nandcs@0 {
+		compatible = "brcm,nandcs";
+		reg = <0>;
+		nand-ecc-strength = <4>;
+		nand-ecc-step-size = <512>;
+		brcm,nand-oob-sectors-size = <16>;
+	};
+};
Signature · 1 line
1.9.1
#15 lore raw

PATCH v4 10/11 ARM: dts: cygnus: Enable NAND support for Cygnus

In reply to Brian Norris

From: Ray Jui <rjui-dY08KVG/lbpWk0Htik3J/[email protected]>

Enable NAND support for Broadcom Cygnus SoC

---
v4: account for reworked DT binding

 arch/arm/boot/dts/bcm-cygnus.dtsi | 12 ++++++++++++
 arch/arm/boot/dts/bcm958300k.dts  | 16 ++++++++++++++++
 2 files changed, 28 insertions(+)
arch/arm/boot/dts/bcm-cygnus.dtsi +12 -0
index 7b52c33ea69a..e1ac07a16f92 100644
@@ -212,6 +212,18 @@
 		status = "disabled";
 	};
 
+	nand: nand@18046000 {
+		compatible = "brcm,nand-iproc", "brcm,brcmnand-v6.1", "brcm,brcmnand";
+		reg = <0x18046000 0x600>, <0xf8105408 0x600>, <0x18046f00 0x20>;
+		reg-names = "nand", "iproc-idm", "iproc-ext";
+		interrupts = <GIC_SPI 69 IRQ_TYPE_LEVEL_HIGH>;
+
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		brcm,nand-has-wp;
+	};
+
 	gic: interrupt-controller@19021000 {
 		compatible = "arm,cortex-a9-gic";
 		#interrupt-cells = <3>;
arch/arm/boot/dts/bcm958300k.dts +16 -0
index c9eb8565eac5..2f63052f9d48 100644
@@ -58,4 +58,20 @@
 	uart3: serial@18023000 {
 		status = "okay";
 	};
+
+	nand: nand@18046000 {
+		nandcs@1 {
+			compatible = "brcm,nandcs";
+			reg = <0>;
+			nand-on-flash-bbt;
+
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			nand-ecc-strength = <24>;
+			nand-ecc-step-size = <1024>;
+
+			brcm,nand-oob-sector-size = <27>;
+		};
+	};
 };
Signature · 6 lines
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#16 lore raw

PATCH v4 11/11 MAINTAINERS: add entry for new brcmnand/ directory

In reply to Brian Norris

---
v4: new to series

 MAINTAINERS | 6 ++++++
 1 file changed, 6 insertions(+)
MAINTAINERS +6 -0
index 2e5bbc0d68b2..d41800e369b2 100644
@@ -2242,6 +2242,12 @@ S:	Supported
 F:	drivers/gpio/gpio-bcm-kona.c
 F:	Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt
 
+BROADCOM STB NAND FLASH DRIVER
+M:	Brian Norris <[email protected]>
+L:	[email protected]
+S:	Maintained
+F:	drivers/mtd/nand/brcmnand/
+
 BROADCOM SPECIFIC AMBA DRIVER (BCMA)
 M:	Rafał Miłecki <[email protected]>
 L:	[email protected]
Signature · 6 lines
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#17 lore raw
In reply to Brian Norris
Quoted 7 lines · On Tuesday 12 May 2015 17:53:33 Brian Norris wrote:

This is the fourth (and final?) version of support for the Broadcom BCM7xxx Set-Top Box NAND controller. This controller has been used in a variety of Broadcom SoCs.

Tested to work on Cygnus, BCM7445, and BCM63138.

Looks very nice overall. I have one remaining comment about the way that the base driver interacts with the subdrivers, I'll reply to one of the patches directly.

Arnd

#18 lore raw
In reply to Brian Norris
Quoted 7 lines · Brian Norris

Hi,

This is the fourth (and final?) version of support for the Broadcom BCM7xxx Set-Top Box NAND controller. This controller has been used in a variety of Broadcom SoCs.

Tested to work on Cygnus, BCM7445, and BCM63138.

Applied patches 4, 9 and 10 to devicetree/next, the others should go via your tree, right?

Quoted 71 lines

Summary changelog:

v1 -> v2:
* add NAND to DTS for BCM7445 / BCM97445SVMB
* rename DT binding file to have 'brcm,' prefix
* catch DMA mapping errors
* fixup timeout / error messages (hex, remove misleading info)
* MODULE_LICENSE("GPL v2")
* fix incorrect comments
* print why we fail, when checking for supported controller revisions
* disable prefetch when using Flash DMA (see FIXME); will re-enable once we get a good erased-page verification scheme merged

v2 -> v3:
* rebase to v4.1-rc1
* add SoC-specific infrastructure, to help support other SoCs:
- add BCM63138 support
- add iProc/Cygnus support
* disable prefetch on v6.1

v3 -> v4:
* move to brcmnand/ subdirectory
* add MAINTAINERS entry
* fixup endianness issues (only use __raw_xxx on MIPS BE)
* split core NAND support into library, with tiny platform drivers for STB (BCM7xxx), iProc, and BCM63138
* restructure DT binding, so all SoC extras become part of main controller node

Brian Norris (10):
Documentation: devicetree: add binding doc for Broadcom NAND
controller
mtd: nand: add NAND driver "library" for Broadcom STB NAND controller
mtd: brcmnand: add support for STB chips
ARM: bcm7445: add NAND to DTS
Documentation: devicetree: brcmstb_nand: add BCM63138 and Cygnus/iProc
mtd: brcmnand: add extra SoC support to library
mtd: brcmnand: add support for Broadcom's IPROC family
mtd: brcmnand: add BCM63138 support
ARM: bcm63138: add NAND DT support
MAINTAINERS: add entry for new brcmnand/ directory

Ray Jui (1):
ARM: dts: cygnus: Enable NAND support for Cygnus

 .../devicetree/bindings/mtd/brcm,brcmnand.txt      |  150 ++
 MAINTAINERS                                        |    6 +
 arch/arm/boot/dts/bcm-cygnus.dtsi                  |   12 +
 arch/arm/boot/dts/bcm63138.dtsi                    |   11 +
 arch/arm/boot/dts/bcm7445-bcm97445svmb.dts         |   23 +
 arch/arm/boot/dts/bcm7445.dtsi                     |   22 +
 arch/arm/boot/dts/bcm958300k.dts                   |   16 +
 arch/arm/boot/dts/bcm963138dvt.dts                 |   12 +
 drivers/mtd/nand/Kconfig                           |    8 +
 drivers/mtd/nand/Makefile                          |    1 +
 drivers/mtd/nand/brcmnand/Makefile                 |    6 +
 drivers/mtd/nand/brcmnand/bcm63138_nand.c          |  111 +
 drivers/mtd/nand/brcmnand/brcmnand.c               | 2246 ++++++++++++++++++++
 drivers/mtd/nand/brcmnand/brcmnand.h               |   73 +
 drivers/mtd/nand/brcmnand/brcmstb_nand.c           |   44 +
 drivers/mtd/nand/brcmnand/iproc_nand.c             |  150 ++
 16 files changed, 2891 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
 create mode 100644 drivers/mtd/nand/brcmnand/Makefile
 create mode 100644 drivers/mtd/nand/brcmnand/bcm63138_nand.c
 create mode 100644 drivers/mtd/nand/brcmnand/brcmnand.c
 create mode 100644 drivers/mtd/nand/brcmnand/brcmnand.h
 create mode 100644 drivers/mtd/nand/brcmnand/brcmstb_nand.c
 create mode 100644 drivers/mtd/nand/brcmnand/iproc_nand.c
Signature · 5 lines
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#19 lore raw
Quoted 11 lines · Florian Fainelli
Quoted 7 lines · Brian Norris

Hi,

This is the fourth (and final?) version of support for the Broadcom BCM7xxx Set-Top Box NAND controller. This controller has been used in a variety of Broadcom SoCs.

Tested to work on Cygnus, BCM7445, and BCM63138.

Applied patches 4, 9 and 10 to devicetree/next, the others should go via your tree, right?

Yes. Not sure if I'll be reworking the others any more based on Arnd's comments, but at least the device tree stuff has stabilized, I expect.

Thanks,
Brian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#20 lore raw
Quoted 8 lines · On Wednesday 13 May 2015 11:14:47 Brian Norris wrote:
Quoted 7 lines · Florian Fainelli
Quoted 6 lines · Brian Norris

Hi,

This is the fourth (and final?) version of support for the Broadcom BCM7xxx Set-Top Box NAND controller. This controller has been used in a variety of Broadcom SoCs.

Quoted 7 lines
Quoted 4 lines
Quoted 1 line

Tested to work on Cygnus, BCM7445, and BCM63138.

Applied patches 4, 9 and 10 to devicetree/next, the others should go via your tree, right?

Yes. Not sure if I'll be reworking the others any more based on Arnd's comments, but at least the device tree stuff has stabilized, I expect.

You can always change it with a patch on top, but that's between you and the drivers/mtd maintainer ;-)

Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

#21 lore raw
In reply to Brian Norris
Quoted 7 lines · Brian Norris

Hi,

This is the fourth (and final?) version of support for the Broadcom BCM7xxx Set-Top Box NAND controller. This controller has been used in a variety of Broadcom SoCs.

Tested to work on Cygnus, BCM7445, and BCM63138.

Pushed everything but the ARM/dts patches to l2-mtd.git, with a small fixup on the Kconfig symbols (s/MTD_NAND_BRCMSTB/MTD_NAND_BRCMNAND/). Diff appended to this email. I have a few insubstantial fixups that I'll send out later, but there seems to be no more comments on the core stuff.

Quoted 61 lines

Summary changelog:

v1 -> v2:
* add NAND to DTS for BCM7445 / BCM97445SVMB
* rename DT binding file to have 'brcm,' prefix
* catch DMA mapping errors
* fixup timeout / error messages (hex, remove misleading info)
* MODULE_LICENSE("GPL v2")
* fix incorrect comments
* print why we fail, when checking for supported controller revisions
* disable prefetch when using Flash DMA (see FIXME); will re-enable once we get a good erased-page verification scheme merged

v2 -> v3:
* rebase to v4.1-rc1
* add SoC-specific infrastructure, to help support other SoCs:
- add BCM63138 support
- add iProc/Cygnus support
* disable prefetch on v6.1

v3 -> v4:
* move to brcmnand/ subdirectory
* add MAINTAINERS entry
* fixup endianness issues (only use __raw_xxx on MIPS BE)
* split core NAND support into library, with tiny platform drivers for STB (BCM7xxx), iProc, and BCM63138
* restructure DT binding, so all SoC extras become part of main controller node

Brian Norris (10):
Documentation: devicetree: add binding doc for Broadcom NAND
controller
mtd: nand: add NAND driver "library" for Broadcom STB NAND controller
mtd: brcmnand: add support for STB chips
ARM: bcm7445: add NAND to DTS
Documentation: devicetree: brcmstb_nand: add BCM63138 and Cygnus/iProc
mtd: brcmnand: add extra SoC support to library
mtd: brcmnand: add support for Broadcom's IPROC family
mtd: brcmnand: add BCM63138 support
ARM: bcm63138: add NAND DT support
MAINTAINERS: add entry for new brcmnand/ directory

Ray Jui (1):
ARM: dts: cygnus: Enable NAND support for Cygnus

 .../devicetree/bindings/mtd/brcm,brcmnand.txt      |  150 ++
 MAINTAINERS                                        |    6 +
 arch/arm/boot/dts/bcm-cygnus.dtsi                  |   12 +
 arch/arm/boot/dts/bcm63138.dtsi                    |   11 +
 arch/arm/boot/dts/bcm7445-bcm97445svmb.dts         |   23 +
 arch/arm/boot/dts/bcm7445.dtsi                     |   22 +
 arch/arm/boot/dts/bcm958300k.dts                   |   16 +
 arch/arm/boot/dts/bcm963138dvt.dts                 |   12 +
 drivers/mtd/nand/Kconfig                           |    8 +
 drivers/mtd/nand/Makefile                          |    1 +
 drivers/mtd/nand/brcmnand/Makefile                 |    6 +
 drivers/mtd/nand/brcmnand/bcm63138_nand.c          |  111 +
 drivers/mtd/nand/brcmnand/brcmnand.c               | 2246 ++++++++++++++++++++
 drivers/mtd/nand/brcmnand/brcmnand.h               |   73 +
 drivers/mtd/nand/brcmnand/brcmstb_nand.c           |   44 +
 drivers/mtd/nand/brcmnand/iproc_nand.c             |  150 ++
Quoted 9 lines
 16 files changed, 2891 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt
 create mode 100644 drivers/mtd/nand/brcmnand/Makefile
 create mode 100644 drivers/mtd/nand/brcmnand/bcm63138_nand.c
 create mode 100644 drivers/mtd/nand/brcmnand/brcmnand.c
 create mode 100644 drivers/mtd/nand/brcmnand/brcmnand.h
 create mode 100644 drivers/mtd/nand/brcmnand/brcmstb_nand.c
 create mode 100644 drivers/mtd/nand/brcmnand/iproc_nand.c

The following was squashed into the appropriate patches.

drivers/mtd/nand/Kconfig +1 -1
index 3587017b209a..376b538a5d1f 100644
@@ -394,7 +394,7 @@ config MTD_NAND_GPMI_NAND
 	 block, such as SD card. So pay attention to it when you enable
 	 the GPMI.
 
-config MTD_NAND_BRCMSTB
+config MTD_NAND_BRCMNAND
 	tristate "Broadcom STB NAND controller"
 	depends on ARM || MIPS
 	help
drivers/mtd/nand/Makefile +1 -1
index 7fd5f1e7ad5e..1f897ec3c242 100644
@@ -52,6 +52,6 @@ obj-$(CONFIG_MTD_NAND_XWAY)		+= xway_nand.o
 obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH)	+= bcm47xxnflash/
 obj-$(CONFIG_MTD_NAND_SUNXI)		+= sunxi_nand.o
 obj-$(CONFIG_MTD_NAND_HISI504)	        += hisi504_nand.o
-obj-$(CONFIG_MTD_NAND_BRCMSTB)		+= brcmnand/
+obj-$(CONFIG_MTD_NAND_BRCMNAND)		+= brcmnand/
 
 nand-objs := nand_base.o nand_bbt.o nand_timings.o
drivers/mtd/nand/brcmnand/Makefile +4 -4
index 45a091e0550f..3b1fbfd27d4f 100644
@@ -1,6 +1,6 @@
 # link order matters; don't link the more generic brcmstb_nand.o before the
 # more specific iproc_nand.o, for instance
-obj-$(CONFIG_MTD_NAND_BRCMSTB)		+= iproc_nand.o
-obj-$(CONFIG_MTD_NAND_BRCMSTB)		+= bcm63138_nand.o
-obj-$(CONFIG_MTD_NAND_BRCMSTB)		+= brcmstb_nand.o
-obj-$(CONFIG_MTD_NAND_BRCMSTB)		+= brcmnand.o
+obj-$(CONFIG_MTD_NAND_BRCMNAND)		+= iproc_nand.o
+obj-$(CONFIG_MTD_NAND_BRCMNAND)		+= bcm63138_nand.o
+obj-$(CONFIG_MTD_NAND_BRCMNAND)		+= brcmstb_nand.o
+obj-$(CONFIG_MTD_NAND_BRCMNAND)		+= brcmnand.o