| Message ID | afc6fb02d51a5378e315ade84a134eaf7a58a94f@8b5064a13e22126c1b9329f0dc35b8915774b7c3.invalid |
|---|---|
| State | Superseded |
| Headers | show |
On Tue, Nov 24, 2015 at 08:19:37PM -0000, Simon Arlott wrote: > Add device tree binding for NAND on the BCM63268. > > The BCM63268 has a NAND interrupt register with combined status and enable > registers. > > Signed-off-by: Simon Arlott <simon@fire.lp0.eu> Acked-by: Rob Herring <robh@kernel.org> > --- > .../devicetree/bindings/mtd/brcm,brcmnand.txt | 35 ++++++++++++++++++++++ > 1 file changed, 35 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt > b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt > index 4ff7128..f2a71c8 100644 > --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt > +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt > @@ -72,6 +72,14 @@ we define additional 'compatible' properties and associated register resources w > and enable registers > - reg-names: (required) "nand-int-base" > > + * "brcm,nand-bcm63268" > + - compatible: should contain "brcm,nand-bcm<soc>", "brcm,nand-bcm63268" > + - reg: (required) the 'NAND_INTR_BASE' register range, with combined status > + and enable registers, and boot address registers > + - reg-names: (required) "nand-intr-base" > + - clock: (required) reference to the clock for the NAND controller > + - clock-names: (required) "nand" > + > * "brcm,nand-iproc" > - reg: (required) the "IDM" register range, for interrupt enable and APB > bus access endianness configuration, and the "EXT" register range, > @@ -148,3 +156,30 @@ nand@f0442800 { > }; > }; > }; > + > +nand@10000200 { > + compatible = "brcm,nand-bcm63168", "brcm,nand-bcm63268", > + "brcm,brcmnand-v4.0", "brcm,brcmnand"; > + reg = <0x10000200 0x180>, > + <0x10000600 0x200>, > + <0x100000b0 0x10>; > + reg-names = "nand", "nand-cache", "nand-intr-base"; > + interrupt-parent = <&periph_intc>; > + interrupts = <50>; > + clocks = <&periph_clk 20>; > + clock-names = "nand"; > + > + #address-cells = <1>; > + #size-cells = <0>; > + > + nand0: nandcs@0 { > + compatible = "brcm,nandcs"; > + reg = <0>; > + nand-on-flash-bbt; > + nand-ecc-strength = <1>; > + nand-ecc-step-size = <512>; > + > + #address-cells = <0>; > + #size-cells = <0>; > + }; > +}; > -- > 2.1.4 > > -- > Simon Arlott
+ Broadcom list + Kamal On Tue, Nov 24, 2015 at 08:19:37PM -0000, Simon Arlott wrote: > Add device tree binding for NAND on the BCM63268. > > The BCM63268 has a NAND interrupt register with combined status and enable > registers. > > Signed-off-by: Simon Arlott <simon@fire.lp0.eu> > --- > .../devicetree/bindings/mtd/brcm,brcmnand.txt | 35 ++++++++++++++++++++++ > 1 file changed, 35 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt > b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt > index 4ff7128..f2a71c8 100644 > --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt > +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt > @@ -72,6 +72,14 @@ we define additional 'compatible' properties and associated register resources w > and enable registers > - reg-names: (required) "nand-int-base" > > + * "brcm,nand-bcm63268" > + - compatible: should contain "brcm,nand-bcm<soc>", "brcm,nand-bcm63268" Looks like you're aiming to support bcm63168? Is bcm63268 the first chip to include this style of register then? The numbering seems backwards, but that may just be reality. > + - reg: (required) the 'NAND_INTR_BASE' register range, with combined status > + and enable registers, and boot address registers > + - reg-names: (required) "nand-intr-base" > + - clock: (required) reference to the clock for the NAND controller > + - clock-names: (required) "nand" > + > * "brcm,nand-iproc" > - reg: (required) the "IDM" register range, for interrupt enable and APB > bus access endianness configuration, and the "EXT" register range, > @@ -148,3 +156,30 @@ nand@f0442800 { > }; > }; > }; > + > +nand@10000200 { > + compatible = "brcm,nand-bcm63168", "brcm,nand-bcm63268", > + "brcm,brcmnand-v4.0", "brcm,brcmnand"; > + reg = <0x10000200 0x180>, > + <0x10000600 0x200>, > + <0x100000b0 0x10>; > + reg-names = "nand", "nand-cache", "nand-intr-base"; > + interrupt-parent = <&periph_intc>; > + interrupts = <50>; > + clocks = <&periph_clk 20>; > + clock-names = "nand"; > + > + #address-cells = <1>; > + #size-cells = <0>; > + > + nand0: nandcs@0 { > + compatible = "brcm,nandcs"; > + reg = <0>; > + nand-on-flash-bbt; > + nand-ecc-strength = <1>; > + nand-ecc-step-size = <512>; > + > + #address-cells = <0>; > + #size-cells = <0>; What are these {address,size}-cells for? If you need them for partitioning, then those are wrong -- they shouldn't be zero. Maybe just drop them? (I can cut them out when applying, if that's the only change to make.) > + }; > +}; Brian
On Wed, Dec 2, 2015 at 8:05 PM, Brian Norris <computersforpeace@gmail.com> wrote: > + Broadcom list + Kamal > > On Tue, Nov 24, 2015 at 08:19:37PM -0000, Simon Arlott wrote: >> Add device tree binding for NAND on the BCM63268. >> >> The BCM63268 has a NAND interrupt register with combined status and enable >> registers. >> >> Signed-off-by: Simon Arlott <simon@fire.lp0.eu> >> --- >> .../devicetree/bindings/mtd/brcm,brcmnand.txt | 35 ++++++++++++++++++++++ >> 1 file changed, 35 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> index 4ff7128..f2a71c8 100644 >> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> @@ -72,6 +72,14 @@ we define additional 'compatible' properties and associated register resources w >> and enable registers >> - reg-names: (required) "nand-int-base" >> >> + * "brcm,nand-bcm63268" >> + - compatible: should contain "brcm,nand-bcm<soc>", "brcm,nand-bcm63268" > > Looks like you're aiming to support bcm63168? Is bcm63268 the first > chip to include this style of register then? The numbering seems > backwards, but that may just be reality. There are four chip variants, bcm63168, bcm63268, bcm63169 and bcm63269, and they were all introduced at the same time. the *16x have less features than *26x (IIRC only two rgmii ports instead of four, no hw crypto, maybe no dect?), and the *9 ones have no xDSL support. From a registers location/layout, clocks, etc standpoint, there is no difference between bcm63168 and bcm63268 (and the x9's). As a reference, Broadcom uses bcm63268 as the "generic" name for the chip family in their code, but on their website only advertise the bcm63168. Both chips do exist though, and at least the bcm63169, I have devices with these three here. Jonas
2015-12-02 11:05 GMT-08:00 Brian Norris <computersforpeace@gmail.com>: > + Broadcom list + Kamal > > On Tue, Nov 24, 2015 at 08:19:37PM -0000, Simon Arlott wrote: >> Add device tree binding for NAND on the BCM63268. >> >> The BCM63268 has a NAND interrupt register with combined status and enable >> registers. >> >> Signed-off-by: Simon Arlott <simon@fire.lp0.eu> >> --- >> .../devicetree/bindings/mtd/brcm,brcmnand.txt | 35 ++++++++++++++++++++++ >> 1 file changed, 35 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> index 4ff7128..f2a71c8 100644 >> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> @@ -72,6 +72,14 @@ we define additional 'compatible' properties and associated register resources w >> and enable registers >> - reg-names: (required) "nand-int-base" >> >> + * "brcm,nand-bcm63268" >> + - compatible: should contain "brcm,nand-bcm<soc>", "brcm,nand-bcm63268" > > Looks like you're aiming to support bcm63168? Is bcm63268 the first > chip to include this style of register then? The numbering seems > backwards, but that may just be reality. 6362 (NAND rev 2.1, ann. Sep 8, 2009), 6368 (v0.1?!?, ann. Jan 7, 2009) and 6328 (v2.1, can't find release date) are earlier chips that have an identical combined interrupt enable + status register and a NAND controller within the same 32-bits word, so these would qualify as a better compatible string for this specific addition integration stub here. I would gowith 6368 here then?
On 02/12/15 19:05, Brian Norris wrote: > + Broadcom list + Kamal > > On Tue, Nov 24, 2015 at 08:19:37PM -0000, Simon Arlott wrote: >> Add device tree binding for NAND on the BCM63268. >> >> The BCM63268 has a NAND interrupt register with combined status and enable >> registers. >> >> Signed-off-by: Simon Arlott <simon@fire.lp0.eu> >> --- >> .../devicetree/bindings/mtd/brcm,brcmnand.txt | 35 ++++++++++++++++++++++ >> 1 file changed, 35 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> index 4ff7128..f2a71c8 100644 >> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >> @@ -72,6 +72,14 @@ we define additional 'compatible' properties and associated register resources w >> and enable registers >> - reg-names: (required) "nand-int-base" >> >> + * "brcm,nand-bcm63268" >> + - compatible: should contain "brcm,nand-bcm<soc>", "brcm,nand-bcm63268" > > Looks like you're aiming to support bcm63168? Is bcm63268 the first > chip to include this style of register then? The numbering seems > backwards, but that may just be reality. Yes, I have a BCM963168VX (BCM63168) but all the Broadcom code refers to this SoC as BCM63268. This is the only one with these registers in the source code of similar MIPS that I have. https://github.com/lp0/bcm963xx_4.12L.06B_consumer/blob/master/bcmdrivers/opensource/char/board/bcm963xx/impl1/board.c#L6595 int kerSysGetChipId() { ... /* Force BCM63168, BCM63169, and BCM63269 to be BCM63268) */ if( ( (r & 0xffffe) == 0x63168 ) || ( (r & 0xffffe) == 0x63268 )) r = 0x63268; >> + - reg: (required) the 'NAND_INTR_BASE' register range, with combined status >> + and enable registers, and boot address registers >> + - reg-names: (required) "nand-intr-base" >> + - clock: (required) reference to the clock for the NAND controller >> + - clock-names: (required) "nand" >> + >> * "brcm,nand-iproc" >> - reg: (required) the "IDM" register range, for interrupt enable and APB >> bus access endianness configuration, and the "EXT" register range, >> @@ -148,3 +156,30 @@ nand@f0442800 { >> }; >> }; >> }; >> + >> +nand@10000200 { >> + compatible = "brcm,nand-bcm63168", "brcm,nand-bcm63268", >> + "brcm,brcmnand-v4.0", "brcm,brcmnand"; >> + reg = <0x10000200 0x180>, >> + <0x10000600 0x200>, >> + <0x100000b0 0x10>; >> + reg-names = "nand", "nand-cache", "nand-intr-base"; >> + interrupt-parent = <&periph_intc>; >> + interrupts = <50>; >> + clocks = <&periph_clk 20>; >> + clock-names = "nand"; >> + >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + nand0: nandcs@0 { >> + compatible = "brcm,nandcs"; >> + reg = <0>; >> + nand-on-flash-bbt; >> + nand-ecc-strength = <1>; >> + nand-ecc-step-size = <512>; >> + >> + #address-cells = <0>; >> + #size-cells = <0>; > > What are these {address,size}-cells for? If you need them for > partitioning, then those are wrong -- they shouldn't be zero. Maybe just > drop them? (I can cut them out when applying, if that's the only change > to make.) This is the correct way to do partitioning, there would be a "partitions" block with no address/size that contains the partitions as child nodes. [Documentation/devicetree/bindings/mtd/partition.txt] I think they're also implicit so you can just remove those two lines. I've created a bcm963268part driver so there won't need to be any partitions in DT for bcm63268. >> + }; >> +}; > > Brian >
Hi, On Wed, Dec 02, 2015 at 07:41:07PM +0000, Simon Arlott wrote: > >> + nand0: nandcs@0 { > >> + compatible = "brcm,nandcs"; > >> + reg = <0>; > >> + nand-on-flash-bbt; > >> + nand-ecc-strength = <1>; > >> + nand-ecc-step-size = <512>; > >> + > >> + #address-cells = <0>; > >> + #size-cells = <0>; > > > > What are these {address,size}-cells for? If you need them for > > partitioning, then those are wrong -- they shouldn't be zero. Maybe just > > drop them? (I can cut them out when applying, if that's the only change > > to make.) > > This is the correct way to do partitioning, there would be a > "partitions" block with no address/size that contains the partitions as > child nodes. [Documentation/devicetree/bindings/mtd/partition.txt] That doc says nothing about {address,size}-cells = 0. When using the new binding with a 'partitions' subnode, I'm not sure the address translation specification really matters anyway; the flash space is a new address space unrelated to the parents, and we don't do any translation from the 'flash' node to the 'partitions' node. So you don't need #{address,size}-cells in the flash node, but you do in the 'partitions' node. > I think they're also implicit so you can just remove those two lines. From ePAPR: "The #address-cells and #size-cells properties are not inherited from ancestors in the device tree. They shall be explicitly defined." But we don't want to define them. I'd drop them, at least from the example, as they're not relevant. > I've created a bcm963268part driver so there won't need to be any > partitions in DT for bcm63268. Just curious, do you plan to submit this driver? We're working on matching up partition parsers to flash devices via device tree of_match_table's, so you could do something like this: nand0: nandcs@0 { compatible = "brcm,nandcs"; ... partitions { compatible = "brcm,bcm963268-partitions"; ... }; }; FYI. > >> + }; > >> +}; Brian
On 02/12/15 19:38, Florian Fainelli wrote: > 2015-12-02 11:05 GMT-08:00 Brian Norris <computersforpeace@gmail.com>: >> + Broadcom list + Kamal >> >> On Tue, Nov 24, 2015 at 08:19:37PM -0000, Simon Arlott wrote: >>> Add device tree binding for NAND on the BCM63268. >>> >>> The BCM63268 has a NAND interrupt register with combined status and enable >>> registers. >>> >>> Signed-off-by: Simon Arlott <simon@fire.lp0.eu> >>> --- >>> .../devicetree/bindings/mtd/brcm,brcmnand.txt | 35 ++++++++++++++++++++++ >>> 1 file changed, 35 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >>> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >>> index 4ff7128..f2a71c8 100644 >>> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >>> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >>> @@ -72,6 +72,14 @@ we define additional 'compatible' properties and associated register resources w >>> and enable registers >>> - reg-names: (required) "nand-int-base" >>> >>> + * "brcm,nand-bcm63268" >>> + - compatible: should contain "brcm,nand-bcm<soc>", "brcm,nand-bcm63268" >> >> Looks like you're aiming to support bcm63168? Is bcm63268 the first >> chip to include this style of register then? The numbering seems >> backwards, but that may just be reality. > > 6362 (NAND rev 2.1, ann. Sep 8, 2009), 6368 (v0.1?!?, ann. Jan 7, > 2009) and 6328 (v2.1, can't find release date) are earlier chips that > have an identical combined interrupt enable + status register and a > NAND controller within the same 32-bits word, so these would qualify > as a better compatible string for this specific addition integration > stub here. I would gowith 6368 here then? > I could change it to 6368 but there's no documented NAND_INTR_BASE for it. Only the 63268 and 6818 have a #define for NAND_INTR_BASE.
On 02/12/15 20:00, Brian Norris wrote: > Hi, > > On Wed, Dec 02, 2015 at 07:41:07PM +0000, Simon Arlott wrote: >> >> + nand0: nandcs@0 { >> >> + compatible = "brcm,nandcs"; >> >> + >> >> + #address-cells = <0>; >> >> + #size-cells = <0>; > >> I think they're also implicit so you can just remove those two lines. > > From ePAPR: "The #address-cells and #size-cells properties are not > inherited from ancestors in the device tree. They shall be explicitly > defined." > > But we don't want to define them. I'd drop them, at least from the > example, as they're not relevant. Ok. >> I've created a bcm963268part driver so there won't need to be any >> partitions in DT for bcm63268. > > Just curious, do you plan to submit this driver? We're working on Yes, it's just the most recent one I've been working on. I still have USBH and IUDMA to submit > matching up partition parsers to flash devices via device tree > of_match_table's, so you could do something like this: > > nand0: nandcs@0 { > compatible = "brcm,nandcs"; > ... > > partitions { > compatible = "brcm,bcm963268-partitions"; > ... > }; > }; I modified brcmnand to look for a machine matching "brcm,bcm963268", but that way is ok with me. Presumably "ofpart" defers to another matching partition parser? Is there a patch for that method of parser detection available?
Hi Simon, On Wed, Dec 02, 2015 at 08:12:32PM +0000, Simon Arlott wrote: > On 02/12/15 20:00, Brian Norris wrote: > > On Wed, Dec 02, 2015 at 07:41:07PM +0000, Simon Arlott wrote: > >> I've created a bcm963268part driver so there won't need to be any > >> partitions in DT for bcm63268. > > > > Just curious, do you plan to submit this driver? We're working on > > Yes, it's just the most recent one I've been working on. I still have > USBH and IUDMA to submit > > > matching up partition parsers to flash devices via device tree > > of_match_table's, so you could do something like this: > > > > nand0: nandcs@0 { > > compatible = "brcm,nandcs"; > > ... > > > > partitions { > > compatible = "brcm,bcm963268-partitions"; > > ... > > }; > > }; > > I modified brcmnand to look for a machine matching "brcm,bcm963268", but Like this? http://patchwork.ozlabs.org/patch/473180/ I'd like to avoid that (hence the "Rejected" status). > that way is ok with me. Presumably "ofpart" defers to another matching > partition parser? Yes, "ofpart" is for specifying the entire partition table in the device tree as subnodes of either the flash node or of the flash's "partitions" subnode. It's not the most flexible, but it does work generically. > Is there a patch for that method of parser detection available? I have something working here, but I haven't had time to finish cleaning it up and submitting it. There's an older patch that works similarly, though it has some deficiencies: http://patchwork.ozlabs.org/patch/475988/ The main difference between that and my (yet-to-be-submitted) proposal is that I'd like parsers to opt in by adding a proper of_match_table with non-Linux-specific DT bindings, and then we can drop the "linux,..." naming and make it a reasonably generic property. Regards, Brian
On Wed, Dec 02, 2015 at 12:21:27PM -0800, Brian Norris wrote: > On Wed, Dec 02, 2015 at 08:12:32PM +0000, Simon Arlott wrote: > > Is there a patch for that method of parser detection available? > > I have something working here, but I haven't had time to finish cleaning > it up and submitting it. There's an older patch that works similarly, > though it has some deficiencies: > > http://patchwork.ozlabs.org/patch/475988/ > > The main difference between that and my (yet-to-be-submitted) proposal > is that I'd like parsers to opt in by adding a proper of_match_table > with non-Linux-specific DT bindings, and then we can drop the > "linux,..." naming and make it a reasonably generic property. For other related work: Linus Walleij attempted something similar here: http://lists.infradead.org/pipermail/linux-mtd/2015-October/062899.html
On 02/12/15 20:21, Brian Norris wrote: > Hi Simon, > > On Wed, Dec 02, 2015 at 08:12:32PM +0000, Simon Arlott wrote: >> On 02/12/15 20:00, Brian Norris wrote: >> > On Wed, Dec 02, 2015 at 07:41:07PM +0000, Simon Arlott wrote: >> >> I've created a bcm963268part driver so there won't need to be any >> >> partitions in DT for bcm63268. >> > >> > Just curious, do you plan to submit this driver? We're working on >> >> Yes, it's just the most recent one I've been working on. I still have >> USBH and IUDMA to submit >> >> > matching up partition parsers to flash devices via device tree >> > of_match_table's, so you could do something like this: >> > >> > nand0: nandcs@0 { >> > compatible = "brcm,nandcs"; >> > ... >> > >> > partitions { >> > compatible = "brcm,bcm963268-partitions"; >> > ... >> > }; >> > }; >> >> I modified brcmnand to look for a machine matching "brcm,bcm963268", but > > Like this? > > http://patchwork.ozlabs.org/patch/473180/ > > I'd like to avoid that (hence the "Rejected" status). I exported default_mtd_part_types, copied it, and then added to it: + for (i = 0; i < nr_types; i++) + part_types[i] = default_mtd_part_types[i]; + + /* Add partition type based on machine */ + if (of_machine_is_compatible("brcm,bcm963268")) + part_types[i++] = "bcm963268part"; + else + part_types[i++] = NULL; + + part_types[i++] = NULL; >> that way is ok with me. Presumably "ofpart" defers to another matching >> partition parser? > > Yes, "ofpart" is for specifying the entire partition table in the device > tree as subnodes of either the flash node or of the flash's "partitions" > subnode. It's not the most flexible, but it does work generically. > >> Is there a patch for that method of parser detection available? > > I have something working here, but I haven't had time to finish cleaning > it up and submitting it. There's an older patch that works similarly, > though it has some deficiencies: > > http://patchwork.ozlabs.org/patch/475988/ > > The main difference between that and my (yet-to-be-submitted) proposal > is that I'd like parsers to opt in by adding a proper of_match_table > with non-Linux-specific DT bindings, and then we can drop the > "linux,..." naming and make it a reasonably generic property. I'll submit my parser without any means of using it, let me know if you want me to work on a patch for a match table. > Regards, > Brian >
On Wed, Dec 02, 2015 at 08:34:38PM +0000, Simon Arlott wrote: > On 02/12/15 20:21, Brian Norris wrote: > > On Wed, Dec 02, 2015 at 08:12:32PM +0000, Simon Arlott wrote: > >> On 02/12/15 20:00, Brian Norris wrote: > >> > On Wed, Dec 02, 2015 at 07:41:07PM +0000, Simon Arlott wrote: > >> >> I've created a bcm963268part driver so there won't need to be any > >> >> partitions in DT for bcm63268. > >> > > >> > Just curious, do you plan to submit this driver? We're working on > >> > >> Yes, it's just the most recent one I've been working on. I still have > >> USBH and IUDMA to submit > >> > >> > matching up partition parsers to flash devices via device tree > >> > of_match_table's, so you could do something like this: > >> > > >> > nand0: nandcs@0 { > >> > compatible = "brcm,nandcs"; > >> > ... > >> > > >> > partitions { > >> > compatible = "brcm,bcm963268-partitions"; > >> > ... > >> > }; > >> > }; > >> > >> I modified brcmnand to look for a machine matching "brcm,bcm963268", but > > > > Like this? > > > > http://patchwork.ozlabs.org/patch/473180/ > > > > I'd like to avoid that (hence the "Rejected" status). > > I exported default_mtd_part_types, copied it, and then added to it: > + for (i = 0; i < nr_types; i++) > + part_types[i] = default_mtd_part_types[i]; > + > + /* Add partition type based on machine */ > + if (of_machine_is_compatible("brcm,bcm963268")) > + part_types[i++] = "bcm963268part"; > + else > + part_types[i++] = NULL; > + > + part_types[i++] = NULL; OK, so even uglier :) > >> that way is ok with me. Presumably "ofpart" defers to another matching > >> partition parser? > > > > Yes, "ofpart" is for specifying the entire partition table in the device > > tree as subnodes of either the flash node or of the flash's "partitions" > > subnode. It's not the most flexible, but it does work generically. > > > >> Is there a patch for that method of parser detection available? > > > > I have something working here, but I haven't had time to finish cleaning > > it up and submitting it. There's an older patch that works similarly, > > though it has some deficiencies: > > > > http://patchwork.ozlabs.org/patch/475988/ > > > > The main difference between that and my (yet-to-be-submitted) proposal > > is that I'd like parsers to opt in by adding a proper of_match_table > > with non-Linux-specific DT bindings, and then we can drop the > > "linux,..." naming and make it a reasonably generic property. > > I'll submit my parser without any means of using it, Sounds fine. > let me know if you > want me to work on a patch for a match table. If you're interested, I may CC you on my patches for testing/review. Brian
On 02/12/15 12:02, Simon Arlott wrote: > On 02/12/15 19:38, Florian Fainelli wrote: >> 2015-12-02 11:05 GMT-08:00 Brian Norris <computersforpeace@gmail.com>: >>> + Broadcom list + Kamal >>> >>> On Tue, Nov 24, 2015 at 08:19:37PM -0000, Simon Arlott wrote: >>>> Add device tree binding for NAND on the BCM63268. >>>> >>>> The BCM63268 has a NAND interrupt register with combined status and enable >>>> registers. >>>> >>>> Signed-off-by: Simon Arlott <simon@fire.lp0.eu> >>>> --- >>>> .../devicetree/bindings/mtd/brcm,brcmnand.txt | 35 ++++++++++++++++++++++ >>>> 1 file changed, 35 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >>>> b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >>>> index 4ff7128..f2a71c8 100644 >>>> --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >>>> +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt >>>> @@ -72,6 +72,14 @@ we define additional 'compatible' properties and associated register resources w >>>> and enable registers >>>> - reg-names: (required) "nand-int-base" >>>> >>>> + * "brcm,nand-bcm63268" >>>> + - compatible: should contain "brcm,nand-bcm<soc>", "brcm,nand-bcm63268" >>> >>> Looks like you're aiming to support bcm63168? Is bcm63268 the first >>> chip to include this style of register then? The numbering seems >>> backwards, but that may just be reality. >> >> 6362 (NAND rev 2.1, ann. Sep 8, 2009), 6368 (v0.1?!?, ann. Jan 7, >> 2009) and 6328 (v2.1, can't find release date) are earlier chips that >> have an identical combined interrupt enable + status register and a >> NAND controller within the same 32-bits word, so these would qualify >> as a better compatible string for this specific addition integration >> stub here. I would gowith 6368 here then? >> > > I could change it to 6368 but there's no documented NAND_INTR_BASE for > it. Only the 63268 and 6818 have a #define for NAND_INTR_BASE. > It looks exactly the same as the 63268 layout, and double checking, this appears to be a v2.1 controller as well, it was not just properly documented as such.
diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt index 4ff7128..f2a71c8 100644 --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt @@ -72,6 +72,14 @@ we define additional 'compatible' properties and associated register resources w and enable registers - reg-names: (required) "nand-int-base" + * "brcm,nand-bcm63268" + - compatible: should contain "brcm,nand-bcm<soc>", "brcm,nand-bcm63268" + - reg: (required) the 'NAND_INTR_BASE' register range, with combined status + and enable registers, and boot address registers + - reg-names: (required) "nand-intr-base" + - clock: (required) reference to the clock for the NAND controller + - clock-names: (required) "nand" + * "brcm,nand-iproc" - reg: (required) the "IDM" register range, for interrupt enable and APB bus access endianness configuration, and the "EXT" register range, @@ -148,3 +156,30 @@ nand@f0442800 { }; }; }; + +nand@10000200 { + compatible = "brcm,nand-bcm63168", "brcm,nand-bcm63268", + "brcm,brcmnand-v4.0", "brcm,brcmnand"; + reg = <0x10000200 0x180>, + <0x10000600 0x200>, + <0x100000b0 0x10>; + reg-names = "nand", "nand-cache", "nand-intr-base"; + interrupt-parent = <&periph_intc>; + interrupts = <50>; + clocks = <&periph_clk 20>; + clock-names = "nand"; + + #address-cells = <1>; + #size-cells = <0>; + + nand0: nandcs@0 { + compatible = "brcm,nandcs"; + reg = <0>; + nand-on-flash-bbt; + nand-ecc-strength = <1>; + nand-ecc-step-size = <512>; + + #address-cells = <0>; + #size-cells = <0>; + }; +};
Add device tree binding for NAND on the BCM63268. The BCM63268 has a NAND interrupt register with combined status and enable registers. Signed-off-by: Simon Arlott <simon@fire.lp0.eu> --- .../devicetree/bindings/mtd/brcm,brcmnand.txt | 35 ++++++++++++++++++++++ 1 file changed, 35 insertions(+)