[RFC v2 PATCH 2/2] mtd: davinci - remove DaVinci architecture depedency
DaVinci NAND driver is a controller driver based on the AEMIF hardware
IP found on TI SoCs. It is also used on SoCs that are not DaVinci based. This
patch removes the driver dependency on DaVinci architecture so that it
can be used on other architectures such as c6x, keystone etc.
Also migrate the driver to use the new AEMIF platform driver API and
moving Documentation to Documentation/devicetree/bindings/mtd/davinci-nand.txt
as this is expected to be used outside of arm/davinci.
Signed-off-by: Murali Karicheri
---
.../devicetree/bindings/arm/davinci/nand.txt | 59 -
.../devicetree/bindings/mtd/davinci-nand.txt | 59 +
drivers/mtd/nand/Kconfig |6 +-
drivers/mtd/nand/davinci_nand.c| 40 -
include/linux/platform_data/davinci-nand.h | 87
5 files changed, 166 insertions(+), 85 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/davinci/nand.txt
create mode 100644 Documentation/devicetree/bindings/mtd/davinci-nand.txt
create mode 100644 include/linux/platform_data/davinci-nand.h
diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt
b/Documentation/devicetree/bindings/arm/davinci/nand.txt
deleted file mode 100644
index 4746452..000
--- a/Documentation/devicetree/bindings/arm/davinci/nand.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-* Texas Instruments Davinci NAND
-
-This file provides information, what the device node for the
-davinci nand interface contain.
-
-Required properties:
-- compatible: "ti,davinci-nand";
-- reg : contain 2 offset/length values:
-- offset and length for the access window
-- offset and length for accessing the aemif control registers
-- ti,davinci-chipselect: Indicates on the davinci_nand driver which
- chipselect is used for accessing the nand.
-
-Recommended properties :
-- ti,davinci-mask-ale: mask for ale
-- ti,davinci-mask-cle: mask for cle
-- ti,davinci-mask-chipsel: mask for chipselect
-- ti,davinci-ecc-mode: ECC mode valid values for davinci driver:
- - "none"
- - "soft"
- - "hw"
-- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
-- ti,davinci-nand-buswidth: buswidth 8 or 16
-- ti,davinci-nand-use-bbt: use flash based bad block table support.
-
-nand device bindings may contain additional sub-nodes describing
-partitions of the address space. See partition.txt for more detail.
-
-Example (enbw_cmc board):
-aemif@6000 {
- compatible = "ti,davinci-aemif";
- #address-cells = <2>;
- #size-cells = <1>;
- reg = <0x6800 0x8>;
- ranges = <2 0 0x6000 0x0200
- 3 0 0x6200 0x0200
- 4 0 0x6400 0x0200
- 5 0 0x6600 0x0200
- 6 0 0x6800 0x0200>;
- nand@3,0 {
- compatible = "ti,davinci-nand";
- reg = <3 0x0 0x807ff
- 6 0x0 0x8000>;
- #address-cells = <1>;
- #size-cells = <1>;
- ti,davinci-chipselect = <1>;
- ti,davinci-mask-ale = <0>;
- ti,davinci-mask-cle = <0>;
- ti,davinci-mask-chipsel = <0>;
- ti,davinci-ecc-mode = "hw";
- ti,davinci-ecc-bits = <4>;
- ti,davinci-nand-use-bbt;
-
- partition@18 {
- label = "ubifs";
- reg = <0x18 0x7e8>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt
b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
new file mode 100644
index 000..4746452
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
@@ -0,0 +1,59 @@
+* Texas Instruments Davinci NAND
+
+This file provides information, what the device node for the
+davinci nand interface contain.
+
+Required properties:
+- compatible: "ti,davinci-nand";
+- reg : contain 2 offset/length values:
+- offset and length for the access window
+- offset and length for accessing the aemif control registers
+- ti,davinci-chipselect: Indicates on the davinci_nand driver which
+ chipselect is used for accessing the nand.
+
+Recommended properties :
+- ti,davinci-mask-ale: mask for ale
+- ti,davinci-mask-cle: mask for cle
+- ti,davinci-mask-chipsel: mask for chipselect
+- ti,davinci-ecc-mode: ECC mode valid values for davinci driver:
+ - "none"
+ - "soft"
+ - "hw"
+- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
+- ti,davinci-nand-buswidth: buswidth 8 or 16
+- ti,davinci-nand-use-bbt: use flash based bad block table support.
+
+nand device bindings may contain additional sub-nodes describing
+partitions of the address space. See partition.txt for more detail.
+
+Example (enbw_cmc board):
+aemif@60
Re: [RFC v2 PATCH 2/2] mtd: davinci - remove DaVinci architecture depedency
On 11/06/2012 02:47 PM, Murali Karicheri wrote:
> DaVinci NAND driver is a controller driver based on the AEMIF hardware
> IP found on TI SoCs. It is also used on SoCs that are not DaVinci based. This
> patch removes the driver dependency on DaVinci architecture so that it
> can be used on other architectures such as c6x, keystone etc.
>
> Also migrate the driver to use the new AEMIF platform driver API and
> moving Documentation to Documentation/devicetree/bindings/mtd/davinci-nand.txt
> as this is expected to be used outside of arm/davinci.
> delete mode 100644 Documentation/devicetree/bindings/arm/davinci/nand.txt
> create mode 100644 Documentation/devicetree/bindings/mtd/davinci-nand.txt
> create mode 100644 include/linux/platform_data/davinci-nand.h
Using "git format-patch -M" might show this as a file move/rename rather
than a delete/add, which would be useful to highlight any changes you
made at the same time.
> diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt
> b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
> +Example (enbw_cmc board):
> +aemif@6000 {
> + compatible = "ti,davinci-aemif";
> + #address-cells = <2>;
> + #size-cells = <1>;
> + reg = <0x6800 0x8>;
> + ranges = <2 0 0x6000 0x0200
> + 3 0 0x6200 0x0200
> + 4 0 0x6400 0x0200
> + 5 0 0x6600 0x0200
> + 6 0 0x6800 0x0200>;
> + nand@3,0 {
Here, isn't 3,0 the aemif chip-select ID that is decoding the NAND accesses?
> + compatible = "ti,davinci-nand";
> + reg = <3 0x0 0x807ff
> + 6 0x0 0x8000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ti,davinci-chipselect = <1>;
So I don't understand why that chipselect property is needed, or has a
different value. Is this muxing the AEMIF output chip-selects onto
different SoC package pins or something? Seems like a job for pinctrl
perhaps?
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC v2 PATCH 2/2] mtd: davinci - remove DaVinci architecture depedency
On 11/07/2012 03:08 PM, Stephen Warren wrote:
On 11/06/2012 02:47 PM, Murali Karicheri wrote:
DaVinci NAND driver is a controller driver based on the AEMIF hardware
IP found on TI SoCs. It is also used on SoCs that are not DaVinci based. This
patch removes the driver dependency on DaVinci architecture so that it
can be used on other architectures such as c6x, keystone etc.
Also migrate the driver to use the new AEMIF platform driver API and
moving Documentation to Documentation/devicetree/bindings/mtd/davinci-nand.txt
as this is expected to be used outside of arm/davinci.
delete mode 100644 Documentation/devicetree/bindings/arm/davinci/nand.txt
create mode 100644 Documentation/devicetree/bindings/mtd/davinci-nand.txt
create mode 100644 include/linux/platform_data/davinci-nand.h
Using "git format-patch -M" might show this as a file move/rename rather
than a delete/add, which would be useful to highlight any changes you
made at the same time.
diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt
b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
+Example (enbw_cmc board):
+aemif@6000 {
+ compatible = "ti,davinci-aemif";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <0x6800 0x8>;
+ ranges = <2 0 0x6000 0x0200
+ 3 0 0x6200 0x0200
+ 4 0 0x6400 0x0200
+ 5 0 0x6600 0x0200
+ 6 0 0x6800 0x0200>;
+ nand@3,0 {
Here, isn't 3,0 the aemif chip-select ID that is decoding the NAND accesses?
Yes.
+ compatible = "ti,davinci-nand";
+ reg = <3 0x0 0x807ff
+ 6 0x0 0x8000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ti,davinci-chipselect = <1>;
So I don't understand why that chipselect property is needed, or has a
different value. Is this muxing the AEMIF output chip-selects onto
different SoC package pins or something? Seems like a job for pinctrl
perhaps?
Actually this was added by somebody else. Do you know what 0 in 3,0
stands for? Is there a way I can retrieve the chip-select id so that I
can remove the davinci-chipselect property. The driver uses a cs index
of 0-3 and the hardware documentation refers CS2-5. Actually cs2 is CE0
signal. So internally driver
translates to 2-5 to 0-3. pinmux is currently done in platform specific
init code and probably need to migrate to use pictrl later.
Murali
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [RFC v2 PATCH 2/2] mtd: davinci - remove DaVinci architecture depedency
On 11/08/2012 08:57 AM, Murali Karicheri wrote:
> On 11/07/2012 03:08 PM, Stephen Warren wrote:
>> On 11/06/2012 02:47 PM, Murali Karicheri wrote:
>>> DaVinci NAND driver is a controller driver based on the AEMIF hardware
>>> IP found on TI SoCs. It is also used on SoCs that are not DaVinci
>>> based. This
>>> patch removes the driver dependency on DaVinci architecture so that it
>>> can be used on other architectures such as c6x, keystone etc.
>>>
>>> Also migrate the driver to use the new AEMIF platform driver API and
>>> moving Documentation to
>>> Documentation/devicetree/bindings/mtd/davinci-nand.txt
>>> as this is expected to be used outside of arm/davinci.
>>> delete mode 100644
>>> Documentation/devicetree/bindings/arm/davinci/nand.txt
>>> create mode 100644
>>> Documentation/devicetree/bindings/mtd/davinci-nand.txt
>>> create mode 100644 include/linux/platform_data/davinci-nand.h
>> Using "git format-patch -M" might show this as a file move/rename rather
>> than a delete/add, which would be useful to highlight any changes you
>> made at the same time.
>>
>>> diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt
>>> b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
>>> +Example (enbw_cmc board):
>>> +aemif@6000 {
>>> +compatible = "ti,davinci-aemif";
>>> +#address-cells = <2>;
>>> +#size-cells = <1>;
>>> +reg = <0x6800 0x8>;
>>> +ranges = <2 0 0x6000 0x0200
>>> + 3 0 0x6200 0x0200
>>> + 4 0 0x6400 0x0200
>>> + 5 0 0x6600 0x0200
>>> + 6 0 0x6800 0x0200>;
>>> +nand@3,0 {
>> Here, isn't 3,0 the aemif chip-select ID that is decoding the NAND
>> accesses?
>>
> Yes.
>>> +compatible = "ti,davinci-nand";
>>> +reg = <3 0x0 0x807ff
>>> +6 0x0 0x8000>;
>>> +#address-cells = <1>;
>>> +#size-cells = <1>;
>>> +ti,davinci-chipselect = <1>;
>> So I don't understand why that chipselect property is needed, or has a
>> different value. Is this muxing the AEMIF output chip-selects onto
>> different SoC package pins or something? Seems like a job for pinctrl
>> perhaps?
>
> Actually this was added by somebody else. Do you know what 0 in 3,0
> stands for? Is there a way I can retrieve the chip-select id so that I
> can remove the davinci-chipselect property. The driver uses a cs index
> of 0-3 and the hardware documentation refers CS2-5. Actually cs2 is CE0
> signal. So internally driver
> translates to 2-5 to 0-3. pinmux is currently done in platform specific
> init code and probably need to migrate to use pictrl later.
for a node named "nand@3,0", the "3,0" is the address value from the
first entry in the reg property "reg = <3 0x0 0x807ff ...". Given your
previous email, that means chip-select 3 offset 0, I believe. Presumably
you can read the reg property directly to find these numbers, or perhaps
there are already some helper functions for this. I have no idea why
there's a "3" in the node name and reg property, but
"ti,davinci-chipselect = <1>" not "= <3>".
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
