Re: [PATCH v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-11-17 Thread Harvey Hunt 

Hi Boris,

On 04/11/15 07:51, Boris Brezillon wrote:

Paul, Harvey,

On Fri, 16 Oct 2015 11:48:48 +0100
Paul Burton  wrote:


On Fri, Oct 16, 2015 at 11:31:12AM +0100, James Hogan wrote:

+
+ {
+ status = "okay";
+
+ nand: nand@1 {
+ compatible = "ingenic,jz4780-nand";


Isn't the NAND a micron part? This doesn't seem right. Is the device
driver and binding already accepted upstream with that compatible
string?


This is the compatible string for the JZ4780 NAND driver, this patch
is part of the series adding that. Detection of the NAND part is
handled by the MTD subsystem.


Right (didn't spot that it was part of a series).

The node appears to describe the NAND interface itself, i.e. a part of
the SoC, so should be in the SoC dtsi file, with overrides in the board
file if necessary for it to work with a particular NAND part
(potentially utilising status="disabled"). Would you agree?


Hi James,

The "nemc" node there is for the Nand & External Memory Controller which
is a hardware block inside the SoC. It has 6 banks (ie. 6 chip select
pins, each associated with a different address range, that connect to
different devices). NAND flash is one such possible device, but a board
could connect it to any of the 6 chip selects, or banks. To represent
that in the SoC dtsi you'd want to have 6 NAND nodes, each disabled by
default, which doesn't make a whole lot of sense to me. Other, non-NAND
devices can connect to the NEMC too - for example the ethernet
controller on the CI20 is connected to one bank.

The NAND device nodes are sort of a mix of describing the NAND flash
(ie. Micron part as you point out) and its connections & properties, the
way the NEMC should be used to interact with it alongside the BCH block,
and the configuration for the NEMC such as timing parameters.

I imagine the most semantically correct means of describing it would
probably be for the compatible string to reflect the Micron NAND part,
and the NEMC driver to pick up on the relevant properties of its child
nodes for configuring timings, whether the device is NAND etc. However
the handling of registering NAND devices with MTD would probably then
have to be part of the NEMC driver, which feels a bit off too.


Another solution would be to describe both the NAND controller and the
NAND chip in the DT (with the NAND chip being a chip of the NAND
controller).
Actually this is already what other binding are doing [1][2]. I know
those bindings are representing NAND controllers which can interface
with more than one NAND chip, but I think that even in the 1:1 case it
would make it clearer to represent both the NAND chip and the NAND
controller.

In your case this would give the following representation

+ {
+   status = "okay";
+
+   nandc: nand-controller@1 {
+   compatible = "ingenic,jz4780-nand";
+   reg = <1 0 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ingenic,bch-controller = <>;
+
+   nand@0 {
+   nand-ecc-mode = "hw";
+   nand-on-flash-bbt;
+   nand-ecc-size = <1024>;
+   nand-ecc-strength = <24>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   partition@0 {
+   label = "u-boot-spl";
+   reg = <0x0 0x0 0x0 0x80>;
+   };
+   /* ... */
+
+   };
+   };
+};


I'll implement this in v8 - thanks for the example DT. :-)


Best Regards,

Boris

[1]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt#L119
[2]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/sunxi-nand.txt#L28



Thanks,
 Paul

__
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/






Best regards,

Harvey Hunt
--
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 v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-11-17 Thread Harvey Hunt 

Hi Boris,

On 04/11/15 07:51, Boris Brezillon wrote:

Paul, Harvey,

On Fri, 16 Oct 2015 11:48:48 +0100
Paul Burton  wrote:


On Fri, Oct 16, 2015 at 11:31:12AM +0100, James Hogan wrote:

+
+ {
+ status = "okay";
+
+ nand: nand@1 {
+ compatible = "ingenic,jz4780-nand";


Isn't the NAND a micron part? This doesn't seem right. Is the device
driver and binding already accepted upstream with that compatible
string?


This is the compatible string for the JZ4780 NAND driver, this patch
is part of the series adding that. Detection of the NAND part is
handled by the MTD subsystem.


Right (didn't spot that it was part of a series).

The node appears to describe the NAND interface itself, i.e. a part of
the SoC, so should be in the SoC dtsi file, with overrides in the board
file if necessary for it to work with a particular NAND part
(potentially utilising status="disabled"). Would you agree?


Hi James,

The "nemc" node there is for the Nand & External Memory Controller which
is a hardware block inside the SoC. It has 6 banks (ie. 6 chip select
pins, each associated with a different address range, that connect to
different devices). NAND flash is one such possible device, but a board
could connect it to any of the 6 chip selects, or banks. To represent
that in the SoC dtsi you'd want to have 6 NAND nodes, each disabled by
default, which doesn't make a whole lot of sense to me. Other, non-NAND
devices can connect to the NEMC too - for example the ethernet
controller on the CI20 is connected to one bank.

The NAND device nodes are sort of a mix of describing the NAND flash
(ie. Micron part as you point out) and its connections & properties, the
way the NEMC should be used to interact with it alongside the BCH block,
and the configuration for the NEMC such as timing parameters.

I imagine the most semantically correct means of describing it would
probably be for the compatible string to reflect the Micron NAND part,
and the NEMC driver to pick up on the relevant properties of its child
nodes for configuring timings, whether the device is NAND etc. However
the handling of registering NAND devices with MTD would probably then
have to be part of the NEMC driver, which feels a bit off too.


Another solution would be to describe both the NAND controller and the
NAND chip in the DT (with the NAND chip being a chip of the NAND
controller).
Actually this is already what other binding are doing [1][2]. I know
those bindings are representing NAND controllers which can interface
with more than one NAND chip, but I think that even in the 1:1 case it
would make it clearer to represent both the NAND chip and the NAND
controller.

In your case this would give the following representation

+ {
+   status = "okay";
+
+   nandc: nand-controller@1 {
+   compatible = "ingenic,jz4780-nand";
+   reg = <1 0 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ingenic,bch-controller = <>;
+
+   nand@0 {
+   nand-ecc-mode = "hw";
+   nand-on-flash-bbt;
+   nand-ecc-size = <1024>;
+   nand-ecc-strength = <24>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   partition@0 {
+   label = "u-boot-spl";
+   reg = <0x0 0x0 0x0 0x80>;
+   };
+   /* ... */
+
+   };
+   };
+};


I'll implement this in v8 - thanks for the example DT. :-)


Best Regards,

Boris

[1]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt#L119
[2]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/sunxi-nand.txt#L28



Thanks,
 Paul

__
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/






Best regards,

Harvey Hunt
--
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 v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-11-03 Thread Boris Brezillon 
Paul, Harvey,

On Fri, 16 Oct 2015 11:48:48 +0100
Paul Burton  wrote:

> On Fri, Oct 16, 2015 at 11:31:12AM +0100, James Hogan wrote:
> > > >> +
> > > >> + {
> > > >> + status = "okay";
> > > >> +
> > > >> + nand: nand@1 {
> > > >> + compatible = "ingenic,jz4780-nand";
> > > >
> > > > Isn't the NAND a micron part? This doesn't seem right. Is the device
> > > > driver and binding already accepted upstream with that compatible
> > > > string?
> > > 
> > > This is the compatible string for the JZ4780 NAND driver, this patch
> > > is part of the series adding that. Detection of the NAND part is
> > > handled by the MTD subsystem.
> > 
> > Right (didn't spot that it was part of a series).
> > 
> > The node appears to describe the NAND interface itself, i.e. a part of
> > the SoC, so should be in the SoC dtsi file, with overrides in the board
> > file if necessary for it to work with a particular NAND part
> > (potentially utilising status="disabled"). Would you agree?
> 
> Hi James,
> 
> The "nemc" node there is for the Nand & External Memory Controller which
> is a hardware block inside the SoC. It has 6 banks (ie. 6 chip select
> pins, each associated with a different address range, that connect to
> different devices). NAND flash is one such possible device, but a board
> could connect it to any of the 6 chip selects, or banks. To represent
> that in the SoC dtsi you'd want to have 6 NAND nodes, each disabled by
> default, which doesn't make a whole lot of sense to me. Other, non-NAND
> devices can connect to the NEMC too - for example the ethernet
> controller on the CI20 is connected to one bank.
> 
> The NAND device nodes are sort of a mix of describing the NAND flash
> (ie. Micron part as you point out) and its connections & properties, the
> way the NEMC should be used to interact with it alongside the BCH block,
> and the configuration for the NEMC such as timing parameters.
> 
> I imagine the most semantically correct means of describing it would
> probably be for the compatible string to reflect the Micron NAND part,
> and the NEMC driver to pick up on the relevant properties of its child
> nodes for configuring timings, whether the device is NAND etc. However
> the handling of registering NAND devices with MTD would probably then
> have to be part of the NEMC driver, which feels a bit off too.

Another solution would be to describe both the NAND controller and the
NAND chip in the DT (with the NAND chip being a chip of the NAND
controller).
Actually this is already what other binding are doing [1][2]. I know
those bindings are representing NAND controllers which can interface
with more than one NAND chip, but I think that even in the 1:1 case it
would make it clearer to represent both the NAND chip and the NAND
controller.

In your case this would give the following representation

+ {
+   status = "okay";
+
+   nandc: nand-controller@1 {
+   compatible = "ingenic,jz4780-nand";
+   reg = <1 0 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ingenic,bch-controller = <>;
+
+   nand@0 {
+   nand-ecc-mode = "hw";
+   nand-on-flash-bbt;
+   nand-ecc-size = <1024>;
+   nand-ecc-strength = <24>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   partition@0 {
+   label = "u-boot-spl";
+   reg = <0x0 0x0 0x0 0x80>;
+   };
+   /* ... */
+
+   };
+   };
+};

Best Regards,

Boris

[1]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt#L119
[2]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/sunxi-nand.txt#L28

> 
> Thanks,
> Paul
> 
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-11-03 Thread Boris Brezillon 
Paul, Harvey,

On Fri, 16 Oct 2015 11:48:48 +0100
Paul Burton  wrote:

> On Fri, Oct 16, 2015 at 11:31:12AM +0100, James Hogan wrote:
> > > >> +
> > > >> + {
> > > >> + status = "okay";
> > > >> +
> > > >> + nand: nand@1 {
> > > >> + compatible = "ingenic,jz4780-nand";
> > > >
> > > > Isn't the NAND a micron part? This doesn't seem right. Is the device
> > > > driver and binding already accepted upstream with that compatible
> > > > string?
> > > 
> > > This is the compatible string for the JZ4780 NAND driver, this patch
> > > is part of the series adding that. Detection of the NAND part is
> > > handled by the MTD subsystem.
> > 
> > Right (didn't spot that it was part of a series).
> > 
> > The node appears to describe the NAND interface itself, i.e. a part of
> > the SoC, so should be in the SoC dtsi file, with overrides in the board
> > file if necessary for it to work with a particular NAND part
> > (potentially utilising status="disabled"). Would you agree?
> 
> Hi James,
> 
> The "nemc" node there is for the Nand & External Memory Controller which
> is a hardware block inside the SoC. It has 6 banks (ie. 6 chip select
> pins, each associated with a different address range, that connect to
> different devices). NAND flash is one such possible device, but a board
> could connect it to any of the 6 chip selects, or banks. To represent
> that in the SoC dtsi you'd want to have 6 NAND nodes, each disabled by
> default, which doesn't make a whole lot of sense to me. Other, non-NAND
> devices can connect to the NEMC too - for example the ethernet
> controller on the CI20 is connected to one bank.
> 
> The NAND device nodes are sort of a mix of describing the NAND flash
> (ie. Micron part as you point out) and its connections & properties, the
> way the NEMC should be used to interact with it alongside the BCH block,
> and the configuration for the NEMC such as timing parameters.
> 
> I imagine the most semantically correct means of describing it would
> probably be for the compatible string to reflect the Micron NAND part,
> and the NEMC driver to pick up on the relevant properties of its child
> nodes for configuring timings, whether the device is NAND etc. However
> the handling of registering NAND devices with MTD would probably then
> have to be part of the NEMC driver, which feels a bit off too.

Another solution would be to describe both the NAND controller and the
NAND chip in the DT (with the NAND chip being a chip of the NAND
controller).
Actually this is already what other binding are doing [1][2]. I know
those bindings are representing NAND controllers which can interface
with more than one NAND chip, but I think that even in the 1:1 case it
would make it clearer to represent both the NAND chip and the NAND
controller.

In your case this would give the following representation

+ {
+   status = "okay";
+
+   nandc: nand-controller@1 {
+   compatible = "ingenic,jz4780-nand";
+   reg = <1 0 0x100>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ingenic,bch-controller = <>;
+
+   nand@0 {
+   nand-ecc-mode = "hw";
+   nand-on-flash-bbt;
+   nand-ecc-size = <1024>;
+   nand-ecc-strength = <24>;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   partition@0 {
+   label = "u-boot-spl";
+   reg = <0x0 0x0 0x0 0x80>;
+   };
+   /* ... */
+
+   };
+   };
+};

Best Regards,

Boris

[1]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt#L119
[2]http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/mtd/sunxi-nand.txt#L28

> 
> Thanks,
> Paul
> 
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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 v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-10-16 Thread Paul Burton 
On Fri, Oct 16, 2015 at 11:31:12AM +0100, James Hogan wrote:
> > >> +
> > >> + {
> > >> + status = "okay";
> > >> +
> > >> + nand: nand@1 {
> > >> + compatible = "ingenic,jz4780-nand";
> > >
> > > Isn't the NAND a micron part? This doesn't seem right. Is the device
> > > driver and binding already accepted upstream with that compatible
> > > string?
> > 
> > This is the compatible string for the JZ4780 NAND driver, this patch
> > is part of the series adding that. Detection of the NAND part is
> > handled by the MTD subsystem.
> 
> Right (didn't spot that it was part of a series).
> 
> The node appears to describe the NAND interface itself, i.e. a part of
> the SoC, so should be in the SoC dtsi file, with overrides in the board
> file if necessary for it to work with a particular NAND part
> (potentially utilising status="disabled"). Would you agree?

Hi James,

The "nemc" node there is for the Nand & External Memory Controller which
is a hardware block inside the SoC. It has 6 banks (ie. 6 chip select
pins, each associated with a different address range, that connect to
different devices). NAND flash is one such possible device, but a board
could connect it to any of the 6 chip selects, or banks. To represent
that in the SoC dtsi you'd want to have 6 NAND nodes, each disabled by
default, which doesn't make a whole lot of sense to me. Other, non-NAND
devices can connect to the NEMC too - for example the ethernet
controller on the CI20 is connected to one bank.

The NAND device nodes are sort of a mix of describing the NAND flash
(ie. Micron part as you point out) and its connections & properties, the
way the NEMC should be used to interact with it alongside the BCH block,
and the configuration for the NEMC such as timing parameters.

I imagine the most semantically correct means of describing it would
probably be for the compatible string to reflect the Micron NAND part,
and the NEMC driver to pick up on the relevant properties of its child
nodes for configuring timings, whether the device is NAND etc. However
the handling of registering NAND devices with MTD would probably then
have to be part of the NEMC driver, which feels a bit off too.

Thanks,
Paul
--
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 v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-10-16 Thread James Hogan 
Hi Alex,

On Fri, Oct 16, 2015 at 11:11:29AM +0100, Alex Smith wrote:
> Hi James,
> 
> On 15 October 2015 at 09:47, James Hogan  wrote:
> >> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
> >> b/arch/mips/boot/dts/ingenic/ci20.dts
> >> index 9fcb9e7..453f1d3 100644
> >> --- a/arch/mips/boot/dts/ingenic/ci20.dts
> >> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
> >> @@ -42,3 +42,57 @@
> >>   {
> >>   status = "okay";
> >>  };
> >> +
> >> + {
> >> + status = "okay";
> >> +
> >> + nand: nand@1 {
> >> + compatible = "ingenic,jz4780-nand";
> >
> > Isn't the NAND a micron part? This doesn't seem right. Is the device
> > driver and binding already accepted upstream with that compatible
> > string?
> 
> This is the compatible string for the JZ4780 NAND driver, this patch
> is part of the series adding that. Detection of the NAND part is
> handled by the MTD subsystem.

Right (didn't spot that it was part of a series).

The node appears to describe the NAND interface itself, i.e. a part of
the SoC, so should be in the SoC dtsi file, with overrides in the board
file if necessary for it to work with a particular NAND part
(potentially utilising status="disabled"). Would you agree?

Cheers
James


signature.asc
Description: Digital signature

Re: [PATCH v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-10-16 Thread Alex Smith 
Hi James,

On 15 October 2015 at 09:47, James Hogan  wrote:
>> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
>> b/arch/mips/boot/dts/ingenic/ci20.dts
>> index 9fcb9e7..453f1d3 100644
>> --- a/arch/mips/boot/dts/ingenic/ci20.dts
>> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
>> @@ -42,3 +42,57 @@
>>   {
>>   status = "okay";
>>  };
>> +
>> + {
>> + status = "okay";
>> +
>> + nand: nand@1 {
>> + compatible = "ingenic,jz4780-nand";
>
> Isn't the NAND a micron part? This doesn't seem right. Is the device
> driver and binding already accepted upstream with that compatible
> string?

This is the compatible string for the JZ4780 NAND driver, this patch
is part of the series adding that. Detection of the NAND part is
handled by the MTD subsystem.

Thanks,
Alex
--
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 v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-10-16 Thread James Hogan 
Hi Alex,

On Fri, Oct 16, 2015 at 11:11:29AM +0100, Alex Smith wrote:
> Hi James,
> 
> On 15 October 2015 at 09:47, James Hogan  wrote:
> >> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
> >> b/arch/mips/boot/dts/ingenic/ci20.dts
> >> index 9fcb9e7..453f1d3 100644
> >> --- a/arch/mips/boot/dts/ingenic/ci20.dts
> >> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
> >> @@ -42,3 +42,57 @@
> >>   {
> >>   status = "okay";
> >>  };
> >> +
> >> + {
> >> + status = "okay";
> >> +
> >> + nand: nand@1 {
> >> + compatible = "ingenic,jz4780-nand";
> >
> > Isn't the NAND a micron part? This doesn't seem right. Is the device
> > driver and binding already accepted upstream with that compatible
> > string?
> 
> This is the compatible string for the JZ4780 NAND driver, this patch
> is part of the series adding that. Detection of the NAND part is
> handled by the MTD subsystem.

Right (didn't spot that it was part of a series).

The node appears to describe the NAND interface itself, i.e. a part of
the SoC, so should be in the SoC dtsi file, with overrides in the board
file if necessary for it to work with a particular NAND part
(potentially utilising status="disabled"). Would you agree?

Cheers
James


signature.asc
Description: Digital signature

Re: [PATCH v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-10-16 Thread Alex Smith 
Hi James,

On 15 October 2015 at 09:47, James Hogan  wrote:
>> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
>> b/arch/mips/boot/dts/ingenic/ci20.dts
>> index 9fcb9e7..453f1d3 100644
>> --- a/arch/mips/boot/dts/ingenic/ci20.dts
>> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
>> @@ -42,3 +42,57 @@
>>   {
>>   status = "okay";
>>  };
>> +
>> + {
>> + status = "okay";
>> +
>> + nand: nand@1 {
>> + compatible = "ingenic,jz4780-nand";
>
> Isn't the NAND a micron part? This doesn't seem right. Is the device
> driver and binding already accepted upstream with that compatible
> string?

This is the compatible string for the JZ4780 NAND driver, this patch
is part of the series adding that. Detection of the NAND part is
handled by the MTD subsystem.

Thanks,
Alex
--
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 v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-10-16 Thread Paul Burton 
On Fri, Oct 16, 2015 at 11:31:12AM +0100, James Hogan wrote:
> > >> +
> > >> + {
> > >> + status = "okay";
> > >> +
> > >> + nand: nand@1 {
> > >> + compatible = "ingenic,jz4780-nand";
> > >
> > > Isn't the NAND a micron part? This doesn't seem right. Is the device
> > > driver and binding already accepted upstream with that compatible
> > > string?
> > 
> > This is the compatible string for the JZ4780 NAND driver, this patch
> > is part of the series adding that. Detection of the NAND part is
> > handled by the MTD subsystem.
> 
> Right (didn't spot that it was part of a series).
> 
> The node appears to describe the NAND interface itself, i.e. a part of
> the SoC, so should be in the SoC dtsi file, with overrides in the board
> file if necessary for it to work with a particular NAND part
> (potentially utilising status="disabled"). Would you agree?

Hi James,

The "nemc" node there is for the Nand & External Memory Controller which
is a hardware block inside the SoC. It has 6 banks (ie. 6 chip select
pins, each associated with a different address range, that connect to
different devices). NAND flash is one such possible device, but a board
could connect it to any of the 6 chip selects, or banks. To represent
that in the SoC dtsi you'd want to have 6 NAND nodes, each disabled by
default, which doesn't make a whole lot of sense to me. Other, non-NAND
devices can connect to the NEMC too - for example the ethernet
controller on the CI20 is connected to one bank.

The NAND device nodes are sort of a mix of describing the NAND flash
(ie. Micron part as you point out) and its connections & properties, the
way the NEMC should be used to interact with it alongside the BCH block,
and the configuration for the NEMC such as timing parameters.

I imagine the most semantically correct means of describing it would
probably be for the compatible string to reflect the Micron NAND part,
and the NEMC driver to pick up on the relevant properties of its child
nodes for configuring timings, whether the device is NAND etc. However
the handling of registering NAND devices with MTD would probably then
have to be part of the NEMC driver, which feels a bit off too.

Thanks,
Paul
--
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 v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-10-15 Thread James Hogan 
Hi Harvey,

On Tue, Oct 06, 2015 at 05:27:17PM +0100, Harvey Hunt wrote:
> From: Alex Smith 
> 
> Add device tree nodes for the NEMC and BCH to the JZ4780 device tree,
> and make use of them in the Ci20 device tree to add a node for the
> board's NAND.
> 
> Note that since the pinctrl driver is not yet upstream, this includes
> neither pin configuration nor busy/write-protect GPIO pins for the
> NAND. Use of the NAND relies on the boot loader to have left the pins
> configured in a usable state, which should be the case when booted
> from the NAND.
> 
> Signed-off-by: Alex Smith 
> Cc: Zubair Lutfullah Kakakhel 
> Cc: David Woodhouse 
> Cc: Brian Norris 
> Cc: Paul Burton 
> Cc: linux-...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-m...@linux-mips.org
> Cc: Alex Smith 
> Signed-off-by: Harvey Hunt 
> ---
> v6 -> v7:
>  - Add nand-ecc-mode to DT.
>  - Add nand-on-flash-bbt to DT.
> 
> v4 -> v5:
>  - New patch adding DT nodes for the NAND so that the driver can be
>tested.
> 
>  arch/mips/boot/dts/ingenic/ci20.dts| 54 
> ++
>  arch/mips/boot/dts/ingenic/jz4780.dtsi | 26 
>  2 files changed, 80 insertions(+)
> 
> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
> b/arch/mips/boot/dts/ingenic/ci20.dts
> index 9fcb9e7..453f1d3 100644
> --- a/arch/mips/boot/dts/ingenic/ci20.dts
> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
> @@ -42,3 +42,57 @@
>   {
>   status = "okay";
>  };
> +
> + {
> + status = "okay";
> +
> + nand: nand@1 {
> + compatible = "ingenic,jz4780-nand";

Isn't the NAND a micron part? This doesn't seem right. Is the device
driver and binding already accepted upstream with that compatible
string?

Cheers
James

> + reg = <1 0 0x100>;
> +
> + ingenic,nemc-tAS = <10>;
> + ingenic,nemc-tAH = <5>;
> + ingenic,nemc-tBP = <10>;
> + ingenic,nemc-tAW = <15>;
> + ingenic,nemc-tSTRV = <100>;
> +
> + ingenic,bch-controller = <>;
> + ingenic,ecc-size = <1024>;
> + ingenic,ecc-strength = <24>;
> +
> + nand-ecc-mode = "hw";
> + nand-on-flash-bbt;
> +
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + partition@0 {
> + label = "u-boot-spl";
> + reg = <0x0 0x0 0x0 0x80>;
> + };
> +
> + partition@0x80 {
> + label = "u-boot";
> + reg = <0x0 0x80 0x0 0x20>;
> + };
> +
> + partition@0xa0 {
> + label = "u-boot-env";
> + reg = <0x0 0xa0 0x0 0x20>;
> + };
> +
> + partition@0xc0 {
> + label = "boot";
> + reg = <0x0 0xc0 0x0 0x400>;
> + };
> +
> + partition@0x8c0 {
> + label = "system";
> + reg = <0x0 0x4c0 0x1 0xfb40>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi 
> b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> index 65389f6..b868b42 100644
> --- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> @@ -108,4 +108,30 @@
>  
>   status = "disabled";
>   };
> +
> + nemc: nemc@1341 {
> + compatible = "ingenic,jz4780-nemc";
> + reg = <0x1341 0x1>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <1 0 0x1b00 0x100
> +   2 0 0x1a00 0x100
> +   3 0 0x1900 0x100
> +   4 0 0x1800 0x100
> +   5 0 0x1700 0x100
> +   6 0 0x1600 0x100>;
> +
> + clocks = < JZ4780_CLK_NEMC>;
> +
> + status = "disabled";
> + };
> +
> + bch: bch@134d {
> + compatible = "ingenic,jz4780-bch";
> + reg = <0x134d 0x1>;
> +
> + clocks = < JZ4780_CLK_BCH>;
> +
> + status = "disabled";
> + };
>  };
> -- 
> 2.6.0
> 
> 


signature.asc
Description: Digital signature

Re: [PATCH v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-10-15 Thread James Hogan 
Hi Harvey,

On Tue, Oct 06, 2015 at 05:27:17PM +0100, Harvey Hunt wrote:
> From: Alex Smith 
> 
> Add device tree nodes for the NEMC and BCH to the JZ4780 device tree,
> and make use of them in the Ci20 device tree to add a node for the
> board's NAND.
> 
> Note that since the pinctrl driver is not yet upstream, this includes
> neither pin configuration nor busy/write-protect GPIO pins for the
> NAND. Use of the NAND relies on the boot loader to have left the pins
> configured in a usable state, which should be the case when booted
> from the NAND.
> 
> Signed-off-by: Alex Smith 
> Cc: Zubair Lutfullah Kakakhel 
> Cc: David Woodhouse 
> Cc: Brian Norris 
> Cc: Paul Burton 
> Cc: linux-...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-m...@linux-mips.org
> Cc: Alex Smith 
> Signed-off-by: Harvey Hunt 
> ---
> v6 -> v7:
>  - Add nand-ecc-mode to DT.
>  - Add nand-on-flash-bbt to DT.
> 
> v4 -> v5:
>  - New patch adding DT nodes for the NAND so that the driver can be
>tested.
> 
>  arch/mips/boot/dts/ingenic/ci20.dts| 54 
> ++
>  arch/mips/boot/dts/ingenic/jz4780.dtsi | 26 
>  2 files changed, 80 insertions(+)
> 
> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
> b/arch/mips/boot/dts/ingenic/ci20.dts
> index 9fcb9e7..453f1d3 100644
> --- a/arch/mips/boot/dts/ingenic/ci20.dts
> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
> @@ -42,3 +42,57 @@
>   {
>   status = "okay";
>  };
> +
> + {
> + status = "okay";
> +
> + nand: nand@1 {
> + compatible = "ingenic,jz4780-nand";

Isn't the NAND a micron part? This doesn't seem right. Is the device
driver and binding already accepted upstream with that compatible
string?

Cheers
James

> + reg = <1 0 0x100>;
> +
> + ingenic,nemc-tAS = <10>;
> + ingenic,nemc-tAH = <5>;
> + ingenic,nemc-tBP = <10>;
> + ingenic,nemc-tAW = <15>;
> + ingenic,nemc-tSTRV = <100>;
> +
> + ingenic,bch-controller = <>;
> + ingenic,ecc-size = <1024>;
> + ingenic,ecc-strength = <24>;
> +
> + nand-ecc-mode = "hw";
> + nand-on-flash-bbt;
> +
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + partition@0 {
> + label = "u-boot-spl";
> + reg = <0x0 0x0 0x0 0x80>;
> + };
> +
> + partition@0x80 {
> + label = "u-boot";
> + reg = <0x0 0x80 0x0 0x20>;
> + };
> +
> + partition@0xa0 {
> + label = "u-boot-env";
> + reg = <0x0 0xa0 0x0 0x20>;
> + };
> +
> + partition@0xc0 {
> + label = "boot";
> + reg = <0x0 0xc0 0x0 0x400>;
> + };
> +
> + partition@0x8c0 {
> + label = "system";
> + reg = <0x0 0x4c0 0x1 0xfb40>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi 
> b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> index 65389f6..b868b42 100644
> --- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
> +++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
> @@ -108,4 +108,30 @@
>  
>   status = "disabled";
>   };
> +
> + nemc: nemc@1341 {
> + compatible = "ingenic,jz4780-nemc";
> + reg = <0x1341 0x1>;
> + #address-cells = <2>;
> + #size-cells = <1>;
> + ranges = <1 0 0x1b00 0x100
> +   2 0 0x1a00 0x100
> +   3 0 0x1900 0x100
> +   4 0 0x1800 0x100
> +   5 0 0x1700 0x100
> +   6 0 0x1600 0x100>;
> +
> + clocks = < JZ4780_CLK_NEMC>;
> +
> + status = "disabled";
> + };
> +
> + bch: bch@134d {
> + compatible = "ingenic,jz4780-bch";
> + reg = <0x134d 0x1>;
> +
> + clocks = < JZ4780_CLK_BCH>;
> +
> + status = "disabled";
> + };
>  };
> -- 
> 2.6.0
> 
> 


signature.asc
Description: Digital signature

RE: [PATCH v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-10-14 Thread Harvey Hunt 
On 8 October 2015 at 22:23, Ezequiel Garcia < ezequ...@vanguardiasur.com.ar> 
wrote:
>On 6 October 2015 at 13:27, Harvey Hunt  wrote:
>> From: Alex Smith 
>>
>> Add device tree nodes for the NEMC and BCH to the JZ4780 device tree,
>> and make use of them in the Ci20 device tree to add a node for the
>> board's NAND.
>>
>> Note that since the pinctrl driver is not yet upstream, this includes
>> neither pin configuration nor busy/write-protect GPIO pins for the
>> NAND. Use of the NAND relies on the boot loader to have left the pins
>> configured in a usable state, which should be the case when booted
>> from the NAND.
>>
>> Signed-off-by: Alex Smith 
>> Cc: Zubair Lutfullah Kakakhel 
>> Cc: David Woodhouse 
>> Cc: Brian Norris 
>> Cc: Paul Burton 
>> Cc: linux-...@lists.infradead.org
>> Cc: devicet...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-m...@linux-mips.org
>> Cc: Alex Smith 
>> Signed-off-by: Harvey Hunt 
>> ---
>> v6 -> v7:
>>  - Add nand-ecc-mode to DT.
>>  - Add nand-on-flash-bbt to DT.
>>
>> v4 -> v5:
>>  - New patch adding DT nodes for the NAND so that the driver can be
>>tested.
>>
>>  arch/mips/boot/dts/ingenic/ci20.dts| 54 
>> ++
>>  arch/mips/boot/dts/ingenic/jz4780.dtsi | 26 
>>  2 files changed, 80 insertions(+)
>>
>> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
>> b/arch/mips/boot/dts/ingenic/ci20.dts
>> index 9fcb9e7..453f1d3 100644
>> --- a/arch/mips/boot/dts/ingenic/ci20.dts
>> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
>> @@ -42,3 +42,57 @@
>>   {
>> status = "okay";
>>  };
>> +
>> + {
>> +   status = "okay";
>> +
>> +   nand: nand@1 {
>> +   compatible = "ingenic,jz4780-nand";
>> +   reg = <1 0 0x100>;
>> +
>
>Why is this in the ci20.dts instead of the SoC dtsi?
>
>Seems at least compatible and reg is not board-specific.
>
>Thanks,
>-- 
>Ezequiel García, VanguardiaSur
>www.vanguardiasur.com.ar

Hi Ezequiel,

The number of NAND nodes under the NEMC node is board specific - some devices
could have 2 NAND banks and others could have none. Including the compatible
property in jz4780.dtsi would imply that all JZ4780 boards have at least one 
NAND bank.

The size in the reg property would be the same for all NAND devices (as it 
refers to the
NAND registers), however the bank number would be different, so that can also 
be seen
as board specific.

Thanks,

Harvey

RE: [PATCH v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-10-14 Thread Harvey Hunt 
On 8 October 2015 at 22:23, Ezequiel Garcia < ezequ...@vanguardiasur.com.ar> 
wrote:
>On 6 October 2015 at 13:27, Harvey Hunt  wrote:
>> From: Alex Smith 
>>
>> Add device tree nodes for the NEMC and BCH to the JZ4780 device tree,
>> and make use of them in the Ci20 device tree to add a node for the
>> board's NAND.
>>
>> Note that since the pinctrl driver is not yet upstream, this includes
>> neither pin configuration nor busy/write-protect GPIO pins for the
>> NAND. Use of the NAND relies on the boot loader to have left the pins
>> configured in a usable state, which should be the case when booted
>> from the NAND.
>>
>> Signed-off-by: Alex Smith 
>> Cc: Zubair Lutfullah Kakakhel 
>> Cc: David Woodhouse 
>> Cc: Brian Norris 
>> Cc: Paul Burton 
>> Cc: linux-...@lists.infradead.org
>> Cc: devicet...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-m...@linux-mips.org
>> Cc: Alex Smith 
>> Signed-off-by: Harvey Hunt 
>> ---
>> v6 -> v7:
>>  - Add nand-ecc-mode to DT.
>>  - Add nand-on-flash-bbt to DT.
>>
>> v4 -> v5:
>>  - New patch adding DT nodes for the NAND so that the driver can be
>>tested.
>>
>>  arch/mips/boot/dts/ingenic/ci20.dts| 54 
>> ++
>>  arch/mips/boot/dts/ingenic/jz4780.dtsi | 26 
>>  2 files changed, 80 insertions(+)
>>
>> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
>> b/arch/mips/boot/dts/ingenic/ci20.dts
>> index 9fcb9e7..453f1d3 100644
>> --- a/arch/mips/boot/dts/ingenic/ci20.dts
>> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
>> @@ -42,3 +42,57 @@
>>   {
>> status = "okay";
>>  };
>> +
>> + {
>> +   status = "okay";
>> +
>> +   nand: nand@1 {
>> +   compatible = "ingenic,jz4780-nand";
>> +   reg = <1 0 0x100>;
>> +
>
>Why is this in the ci20.dts instead of the SoC dtsi?
>
>Seems at least compatible and reg is not board-specific.
>
>Thanks,
>-- 
>Ezequiel García, VanguardiaSur
>www.vanguardiasur.com.ar

Hi Ezequiel,

The number of NAND nodes under the NEMC node is board specific - some devices
could have 2 NAND banks and others could have none. Including the compatible
property in jz4780.dtsi would imply that all JZ4780 boards have at least one 
NAND bank.

The size in the reg property would be the same for all NAND devices (as it 
refers to the
NAND registers), however the bank number would be different, so that can also 
be seen
as board specific.

Thanks,

Harvey

Re: [PATCH v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-10-08 Thread Ezequiel Garcia 
On 6 October 2015 at 13:27, Harvey Hunt  wrote:
> From: Alex Smith 
>
> Add device tree nodes for the NEMC and BCH to the JZ4780 device tree,
> and make use of them in the Ci20 device tree to add a node for the
> board's NAND.
>
> Note that since the pinctrl driver is not yet upstream, this includes
> neither pin configuration nor busy/write-protect GPIO pins for the
> NAND. Use of the NAND relies on the boot loader to have left the pins
> configured in a usable state, which should be the case when booted
> from the NAND.
>
> Signed-off-by: Alex Smith 
> Cc: Zubair Lutfullah Kakakhel 
> Cc: David Woodhouse 
> Cc: Brian Norris 
> Cc: Paul Burton 
> Cc: linux-...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-m...@linux-mips.org
> Cc: Alex Smith 
> Signed-off-by: Harvey Hunt 
> ---
> v6 -> v7:
>  - Add nand-ecc-mode to DT.
>  - Add nand-on-flash-bbt to DT.
>
> v4 -> v5:
>  - New patch adding DT nodes for the NAND so that the driver can be
>tested.
>
>  arch/mips/boot/dts/ingenic/ci20.dts| 54 
> ++
>  arch/mips/boot/dts/ingenic/jz4780.dtsi | 26 
>  2 files changed, 80 insertions(+)
>
> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
> b/arch/mips/boot/dts/ingenic/ci20.dts
> index 9fcb9e7..453f1d3 100644
> --- a/arch/mips/boot/dts/ingenic/ci20.dts
> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
> @@ -42,3 +42,57 @@
>   {
> status = "okay";
>  };
> +
> + {
> +   status = "okay";
> +
> +   nand: nand@1 {
> +   compatible = "ingenic,jz4780-nand";
> +   reg = <1 0 0x100>;
> +

Why is this in the ci20.dts instead of the SoC dtsi?

Seems at least compatible and reg is not board-specific.

Thanks,
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
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 v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-10-08 Thread Ezequiel Garcia 
On 6 October 2015 at 13:27, Harvey Hunt  wrote:
> From: Alex Smith 
>
> Add device tree nodes for the NEMC and BCH to the JZ4780 device tree,
> and make use of them in the Ci20 device tree to add a node for the
> board's NAND.
>
> Note that since the pinctrl driver is not yet upstream, this includes
> neither pin configuration nor busy/write-protect GPIO pins for the
> NAND. Use of the NAND relies on the boot loader to have left the pins
> configured in a usable state, which should be the case when booted
> from the NAND.
>
> Signed-off-by: Alex Smith 
> Cc: Zubair Lutfullah Kakakhel 
> Cc: David Woodhouse 
> Cc: Brian Norris 
> Cc: Paul Burton 
> Cc: linux-...@lists.infradead.org
> Cc: devicet...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-m...@linux-mips.org
> Cc: Alex Smith 
> Signed-off-by: Harvey Hunt 
> ---
> v6 -> v7:
>  - Add nand-ecc-mode to DT.
>  - Add nand-on-flash-bbt to DT.
>
> v4 -> v5:
>  - New patch adding DT nodes for the NAND so that the driver can be
>tested.
>
>  arch/mips/boot/dts/ingenic/ci20.dts| 54 
> ++
>  arch/mips/boot/dts/ingenic/jz4780.dtsi | 26 
>  2 files changed, 80 insertions(+)
>
> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
> b/arch/mips/boot/dts/ingenic/ci20.dts
> index 9fcb9e7..453f1d3 100644
> --- a/arch/mips/boot/dts/ingenic/ci20.dts
> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
> @@ -42,3 +42,57 @@
>   {
> status = "okay";
>  };
> +
> + {
> +   status = "okay";
> +
> +   nand: nand@1 {
> +   compatible = "ingenic,jz4780-nand";
> +   reg = <1 0 0x100>;
> +

Why is this in the ci20.dts instead of the SoC dtsi?

Seems at least compatible and reg is not board-specific.

Thanks,
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar
--
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/

[PATCH v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-10-06 Thread Harvey Hunt 
From: Alex Smith 

Add device tree nodes for the NEMC and BCH to the JZ4780 device tree,
and make use of them in the Ci20 device tree to add a node for the
board's NAND.

Note that since the pinctrl driver is not yet upstream, this includes
neither pin configuration nor busy/write-protect GPIO pins for the
NAND. Use of the NAND relies on the boot loader to have left the pins
configured in a usable state, which should be the case when booted
from the NAND.

Signed-off-by: Alex Smith 
Cc: Zubair Lutfullah Kakakhel 
Cc: David Woodhouse 
Cc: Brian Norris 
Cc: Paul Burton 
Cc: linux-...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: Alex Smith 
Signed-off-by: Harvey Hunt 
---
v6 -> v7:
 - Add nand-ecc-mode to DT.
 - Add nand-on-flash-bbt to DT.

v4 -> v5:
 - New patch adding DT nodes for the NAND so that the driver can be
   tested.

 arch/mips/boot/dts/ingenic/ci20.dts| 54 ++
 arch/mips/boot/dts/ingenic/jz4780.dtsi | 26 
 2 files changed, 80 insertions(+)

diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
b/arch/mips/boot/dts/ingenic/ci20.dts
index 9fcb9e7..453f1d3 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -42,3 +42,57 @@
  {
status = "okay";
 };
+
+ {
+   status = "okay";
+
+   nand: nand@1 {
+   compatible = "ingenic,jz4780-nand";
+   reg = <1 0 0x100>;
+
+   ingenic,nemc-tAS = <10>;
+   ingenic,nemc-tAH = <5>;
+   ingenic,nemc-tBP = <10>;
+   ingenic,nemc-tAW = <15>;
+   ingenic,nemc-tSTRV = <100>;
+
+   ingenic,bch-controller = <>;
+   ingenic,ecc-size = <1024>;
+   ingenic,ecc-strength = <24>;
+
+   nand-ecc-mode = "hw";
+   nand-on-flash-bbt;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   partition@0 {
+   label = "u-boot-spl";
+   reg = <0x0 0x0 0x0 0x80>;
+   };
+
+   partition@0x80 {
+   label = "u-boot";
+   reg = <0x0 0x80 0x0 0x20>;
+   };
+
+   partition@0xa0 {
+   label = "u-boot-env";
+   reg = <0x0 0xa0 0x0 0x20>;
+   };
+
+   partition@0xc0 {
+   label = "boot";
+   reg = <0x0 0xc0 0x0 0x400>;
+   };
+
+   partition@0x8c0 {
+   label = "system";
+   reg = <0x0 0x4c0 0x1 0xfb40>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi 
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index 65389f6..b868b42 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -108,4 +108,30 @@
 
status = "disabled";
};
+
+   nemc: nemc@1341 {
+   compatible = "ingenic,jz4780-nemc";
+   reg = <0x1341 0x1>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <1 0 0x1b00 0x100
+ 2 0 0x1a00 0x100
+ 3 0 0x1900 0x100
+ 4 0 0x1800 0x100
+ 5 0 0x1700 0x100
+ 6 0 0x1600 0x100>;
+
+   clocks = < JZ4780_CLK_NEMC>;
+
+   status = "disabled";
+   };
+
+   bch: bch@134d {
+   compatible = "ingenic,jz4780-bch";
+   reg = <0x134d 0x1>;
+
+   clocks = < JZ4780_CLK_BCH>;
+
+   status = "disabled";
+   };
 };
-- 
2.6.0

--
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/

[PATCH v7,3/3] MIPS: dts: jz4780/ci20: Add NEMC, BCH and NAND device tree nodes

2015-10-06 Thread Harvey Hunt 
From: Alex Smith 

Add device tree nodes for the NEMC and BCH to the JZ4780 device tree,
and make use of them in the Ci20 device tree to add a node for the
board's NAND.

Note that since the pinctrl driver is not yet upstream, this includes
neither pin configuration nor busy/write-protect GPIO pins for the
NAND. Use of the NAND relies on the boot loader to have left the pins
configured in a usable state, which should be the case when booted
from the NAND.

Signed-off-by: Alex Smith 
Cc: Zubair Lutfullah Kakakhel 
Cc: David Woodhouse 
Cc: Brian Norris 
Cc: Paul Burton 
Cc: linux-...@lists.infradead.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: Alex Smith 
Signed-off-by: Harvey Hunt 
---
v6 -> v7:
 - Add nand-ecc-mode to DT.
 - Add nand-on-flash-bbt to DT.

v4 -> v5:
 - New patch adding DT nodes for the NAND so that the driver can be
   tested.

 arch/mips/boot/dts/ingenic/ci20.dts| 54 ++
 arch/mips/boot/dts/ingenic/jz4780.dtsi | 26 
 2 files changed, 80 insertions(+)

diff --git a/arch/mips/boot/dts/ingenic/ci20.dts 
b/arch/mips/boot/dts/ingenic/ci20.dts
index 9fcb9e7..453f1d3 100644
--- a/arch/mips/boot/dts/ingenic/ci20.dts
+++ b/arch/mips/boot/dts/ingenic/ci20.dts
@@ -42,3 +42,57 @@
  {
status = "okay";
 };
+
+ {
+   status = "okay";
+
+   nand: nand@1 {
+   compatible = "ingenic,jz4780-nand";
+   reg = <1 0 0x100>;
+
+   ingenic,nemc-tAS = <10>;
+   ingenic,nemc-tAH = <5>;
+   ingenic,nemc-tBP = <10>;
+   ingenic,nemc-tAW = <15>;
+   ingenic,nemc-tSTRV = <100>;
+
+   ingenic,bch-controller = <>;
+   ingenic,ecc-size = <1024>;
+   ingenic,ecc-strength = <24>;
+
+   nand-ecc-mode = "hw";
+   nand-on-flash-bbt;
+
+   #address-cells = <2>;
+   #size-cells = <2>;
+
+   partition@0 {
+   label = "u-boot-spl";
+   reg = <0x0 0x0 0x0 0x80>;
+   };
+
+   partition@0x80 {
+   label = "u-boot";
+   reg = <0x0 0x80 0x0 0x20>;
+   };
+
+   partition@0xa0 {
+   label = "u-boot-env";
+   reg = <0x0 0xa0 0x0 0x20>;
+   };
+
+   partition@0xc0 {
+   label = "boot";
+   reg = <0x0 0xc0 0x0 0x400>;
+   };
+
+   partition@0x8c0 {
+   label = "system";
+   reg = <0x0 0x4c0 0x1 0xfb40>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
diff --git a/arch/mips/boot/dts/ingenic/jz4780.dtsi 
b/arch/mips/boot/dts/ingenic/jz4780.dtsi
index 65389f6..b868b42 100644
--- a/arch/mips/boot/dts/ingenic/jz4780.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4780.dtsi
@@ -108,4 +108,30 @@
 
status = "disabled";
};
+
+   nemc: nemc@1341 {
+   compatible = "ingenic,jz4780-nemc";
+   reg = <0x1341 0x1>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <1 0 0x1b00 0x100
+ 2 0 0x1a00 0x100
+ 3 0 0x1900 0x100
+ 4 0 0x1800 0x100
+ 5 0 0x1700 0x100
+ 6 0 0x1600 0x100>;
+
+   clocks = < JZ4780_CLK_NEMC>;
+
+   status = "disabled";
+   };
+
+   bch: bch@134d {
+   compatible = "ingenic,jz4780-bch";
+   reg = <0x134d 0x1>;
+
+   clocks = < JZ4780_CLK_BCH>;
+
+   status = "disabled";
+   };
 };
-- 
2.6.0

--
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/