mtd: nand: add Broadcom NAND controller support
Subsystems (6)
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
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
@@ -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/
PATCH v4 2/11 mtd: nand: add NAND driver "library" for Broadcom STB NAND controller
In reply to Brian NorrisThis 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
@@ -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
@@ -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
@@ -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
PATCH v4 3/11 mtd: brcmnand: add support for STB chips
In reply to Brian NorrisBCM7xxx 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
@@ -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
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
@@ -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
@@ -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
PATCH v4 5/11 Documentation: devicetree: brcmstb_nand: add BCM63138 and Cygnus/iProc
In reply to Brian NorrisAdd 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
@@ -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
PATCH v4 6/11 mtd: brcmnand: add extra SoC support to library
In reply to Brian NorrisThere 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
@@ -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
@@ -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/
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
@@ -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/
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
@@ -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
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
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
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_controllerdetails 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 'structbcm63138_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
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 'structbcm63138_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_socan 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_textra){ 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
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_socan 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
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
@@ -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
@@ -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
PATCH v4 10/11 ARM: dts: cygnus: Enable NAND support for Cygnus
In reply to Brian NorrisFrom: 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
@@ -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
@@ -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
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
@@ -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
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
Florian Fainelli
AppliedQuoted 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 mergedv2 -> 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.1v3 -> v4:
* move to brcmnand/ subdirectory
* addMAINTAINERSentry
* fixup endianness issues (only use__raw_xxxon 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 nodeBrian 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/ directoryRay 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
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
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
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 mergedv2 -> 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.1v3 -> v4:
* move to brcmnand/ subdirectory
* addMAINTAINERSentry
* fixup endianness issues (only use__raw_xxxon 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 nodeBrian 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/ directoryRay 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
@@ -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
@@ -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
@@ -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