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