Re: [PATCH 2/3] Documentation: devicetree: add binding doc for Broadcom NAND controller
Hi Brian, On 15-03-16 04:46 PM, Brian Norris wrote: On Mon, Mar 16, 2015 at 04:40:13PM -0700, Scott Branden wrote: On 15-03-16 04:37 PM, Brian Norris wrote: On Mon, Mar 16, 2015 at 04:07:51PM -0700, Scott Branden wrote: So, what's the standard? Company prefix? Long name? Commas? Hyphens? The problem with devicetree binding is there is no standard for much of anything. Some others use the vendor prefix for all their binding documentation. We can try to do the same? Ok, but we already have 3 versions for Broadcom. I can use 'brcm,' if that helps... Yes, it helps if we try standardizing on the brcm vendor prefix in Documentation/devicetree/bindings/vendor-prefixes.txt. If you sift through the bindings directory you will find some of the other vendors have done the same. Also, of note. In Documentation/devicetree/bindings/submitting-patches.txt it states the Documentation should be the first patch in the series. Perhaps this helps the devicetree maintainer in reviewing bindings? Scott Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Documentation: devicetree: add binding doc for Broadcom NAND controller
On Mon, Mar 16, 2015 at 04:40:13PM -0700, Scott Branden wrote: > > On 15-03-16 04:37 PM, Brian Norris wrote: > >On Mon, Mar 16, 2015 at 04:07:51PM -0700, Scott Branden wrote: > >>On 15-03-06 05:18 PM, Brian Norris wrote: > >>>Signed-off-by: Brian Norris > >>>--- > >>> .../devicetree/bindings/mtd/brcmstb_nand.txt | 109 > >>> + > >>> 1 file changed, 109 insertions(+) > >>> create mode 100644 Documentation/devicetree/bindings/mtd/brcmstb_nand.txt > >>> > >>>diff --git a/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt > >>>b/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt > >>>new file mode 100644 > >>>index ..933d44943cbb > >>>--- /dev/null > >> > >>Could you change the binding document with the vendor prefix to > >>match all the other drivers we have been submitting? ie. > >>"brcm,brcmnand.txt" > > > >$ find Documentation/devicetree/ -name 'broadcom*' > >Documentation/devicetree/bindings/net/broadcom-systemport.txt > >Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt > >Documentation/devicetree/bindings/net/broadcom-mdio-unimac.txt > >Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt > >Documentation/devicetree/bindings/net/broadcom-sf2.txt > > > >$ find Documentation/devicetree/ -name 'brcm[^,]*' > >Documentation/devicetree/bindings/arm/brcm-brcmstb.txt > > > >$ find Documentation/devicetree/ -name 'brcm,*' > >Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt > >Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt > >Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt > >Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt > >Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt > >Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt > >Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt > >Documentation/devicetree/bindings/rng/brcm,bcm2835.txt > >Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt > >Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt > >Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt > >Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt > >Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method > >Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt > >Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt > > > >$ find Documentation/devicetree/bindings -name '*.txt' | grep -v ','| wc -l > >1227 > >$ find Documentation/devicetree/bindings -name '*.txt' | grep ','| wc -l > >352 > > > >So, what's the standard? Company prefix? Long name? Commas? Hyphens? > > The problem with devicetree binding is there is no standard for much > of anything. Some others use the vendor prefix for all their > binding documentation. We can try to do the same? Ok, but we already have 3 versions for Broadcom. I can use 'brcm,' if that helps... Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Documentation: devicetree: add binding doc for Broadcom NAND controller
On 15-03-16 04:37 PM, Brian Norris wrote: On Mon, Mar 16, 2015 at 04:07:51PM -0700, Scott Branden wrote: On 15-03-06 05:18 PM, Brian Norris wrote: Signed-off-by: Brian Norris --- .../devicetree/bindings/mtd/brcmstb_nand.txt | 109 + 1 file changed, 109 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/brcmstb_nand.txt diff --git a/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt b/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt new file mode 100644 index ..933d44943cbb --- /dev/null Could you change the binding document with the vendor prefix to match all the other drivers we have been submitting? ie. "brcm,brcmnand.txt" $ find Documentation/devicetree/ -name 'broadcom*' Documentation/devicetree/bindings/net/broadcom-systemport.txt Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt Documentation/devicetree/bindings/net/broadcom-mdio-unimac.txt Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt Documentation/devicetree/bindings/net/broadcom-sf2.txt $ find Documentation/devicetree/ -name 'brcm[^,]*' Documentation/devicetree/bindings/arm/brcm-brcmstb.txt $ find Documentation/devicetree/ -name 'brcm,*' Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt Documentation/devicetree/bindings/rng/brcm,bcm2835.txt Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt $ find Documentation/devicetree/bindings -name '*.txt' | grep -v ','| wc -l 1227 $ find Documentation/devicetree/bindings -name '*.txt' | grep ','| wc -l 352 So, what's the standard? Company prefix? Long name? Commas? Hyphens? The problem with devicetree binding is there is no standard for much of anything. Some others use the vendor prefix for all their binding documentation. We can try to do the same? Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Documentation: devicetree: add binding doc for Broadcom NAND controller
On Mon, Mar 16, 2015 at 04:07:51PM -0700, Scott Branden wrote: > On 15-03-06 05:18 PM, Brian Norris wrote: > >Signed-off-by: Brian Norris > >--- > > .../devicetree/bindings/mtd/brcmstb_nand.txt | 109 > > + > > 1 file changed, 109 insertions(+) > > create mode 100644 Documentation/devicetree/bindings/mtd/brcmstb_nand.txt > > > >diff --git a/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt > >b/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt > >new file mode 100644 > >index ..933d44943cbb > >--- /dev/null > > Could you change the binding document with the vendor prefix to > match all the other drivers we have been submitting? ie. > "brcm,brcmnand.txt" $ find Documentation/devicetree/ -name 'broadcom*' Documentation/devicetree/bindings/net/broadcom-systemport.txt Documentation/devicetree/bindings/net/broadcom-bcm87xx.txt Documentation/devicetree/bindings/net/broadcom-mdio-unimac.txt Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt Documentation/devicetree/bindings/net/broadcom-sf2.txt $ find Documentation/devicetree/ -name 'brcm[^,]*' Documentation/devicetree/bindings/arm/brcm-brcmstb.txt $ find Documentation/devicetree/ -name 'brcm,*' Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7120-l2-intc.txt Documentation/devicetree/bindings/net/wireless/brcm,bcm43xx-fmac.txt Documentation/devicetree/bindings/i2c/brcm,iproc-i2c.txt Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt Documentation/devicetree/bindings/rng/brcm,bcm2835.txt Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt Documentation/devicetree/bindings/watchdog/brcm,bcm2835-pm-wdog.txt Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt $ find Documentation/devicetree/bindings -name '*.txt' | grep -v ','| wc -l 1227 $ find Documentation/devicetree/bindings -name '*.txt' | grep ','| wc -l 352 So, what's the standard? Company prefix? Long name? Commas? Hyphens? Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Documentation: devicetree: add binding doc for Broadcom NAND controller
Hi Brian, On 15-03-06 05:18 PM, Brian Norris wrote: Signed-off-by: Brian Norris --- .../devicetree/bindings/mtd/brcmstb_nand.txt | 109 + 1 file changed, 109 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/brcmstb_nand.txt diff --git a/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt b/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt new file mode 100644 index ..933d44943cbb --- /dev/null Could you change the binding document with the vendor prefix to match all the other drivers we have been submitting? ie. "brcm,brcmnand.txt" Regards, Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] Documentation: devicetree: add binding doc for Broadcom NAND controller
On 06/03/15 17:18, Brian Norris wrote:
> Signed-off-by: Brian Norris
Reviewed-by: Florian Fainelli
> ---
> .../devicetree/bindings/mtd/brcmstb_nand.txt | 109
> +
> 1 file changed, 109 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
> b/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
> new file mode 100644
> index ..933d44943cbb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
> @@ -0,0 +1,109 @@
> +* 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-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-pa
[PATCH 2/3] Documentation: devicetree: add binding doc for Broadcom NAND controller
Signed-off-by: Brian Norris
---
.../devicetree/bindings/mtd/brcmstb_nand.txt | 109 +
1 file changed, 109 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
diff --git a/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
b/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
new file mode 100644
index ..933d44943cbb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/brcmstb_nand.txt
@@ -0,0 +1,109 @@
+* 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-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-stren
