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@60000000 { >>> + compatible = "ti,davinci-aemif"; >>> + #address-cells = <2>; >>> + #size-cells = <1>; >>> + reg = <0x68000000 0x80000>; >>> + ranges = <2 0 0x60000000 0x02000000 >>> + 3 0 0x62000000 0x02000000 >>> + 4 0 0x64000000 0x02000000 >>> + 5 0 0x66000000 0x02000000 >>> + 6 0 0x68000000 0x02000000>; >>> + 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>". -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html