| Message ID | 1384962416-14862-3-git-send-email-ivan.khoronzhuk@ti.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
> + the chip select signal. > + Minimum value is 1 (0 treated as 1). > + > +- ti,cs-wsetup: write setup width, ns > + Time between the beginning of a memory cycle > + and the activation of write strobe. > + Minimum value is 1 (0 treated as 1). > + > +- ti,cs-wstrobe: write strobe width, ns > + Time between the activation and deactivation of > + the write strobe. > + Minimum value is 1 (0 treated as 1). > + > +- ti,cs-whold: write hold width, ns > + Time between the deactivation of the write > + strobe and the end of the cycle (which may be > + either an address change or the deactivation of > + the chip select signal. > + Minimum value is 1 (0 treated as 1). > + > +If any of the above parameters are absent, current parameter value will be taken > +from the corresponding HW reg. > + > +The name for cs node must be in format csN, where N is the cs number. this is wired we should use reg instead to represent the cs as done for SPI or a an other property Best Regards, J.
On 11/20/2013 08:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: >> + the chip select signal. >> + Minimum value is 1 (0 treated as 1). >> + >> +- ti,cs-wsetup: write setup width, ns >> + Time between the beginning of a memory cycle >> + and the activation of write strobe. >> + Minimum value is 1 (0 treated as 1). >> + >> +- ti,cs-wstrobe: write strobe width, ns >> + Time between the activation and deactivation of >> + the write strobe. >> + Minimum value is 1 (0 treated as 1). >> + >> +- ti,cs-whold: write hold width, ns >> + Time between the deactivation of the write >> + strobe and the end of the cycle (which may be >> + either an address change or the deactivation of >> + the chip select signal. >> + Minimum value is 1 (0 treated as 1). >> + >> +If any of the above parameters are absent, current parameter value will be taken >> +from the corresponding HW reg. >> + >> +The name for cs node must be in format csN, where N is the cs number. > > this is wired we should use reg instead to represent the cs as done for SPI > or a an other property > > Best Regards, > J. > Ok, I will add new property cs-chipselect like following : ti,cs-chipselect: number of chipselect. Indicates on the aemif driver which chipselect is used for accessing the memory. For compatibles "ti,davinci-aemif" and "ti,keystone-aemif" it can be in range [0-3]. For compatible "ti,omap-L138-aemif" range is [2-5]. Is it OK?
On 21:03 Wed 20 Nov , ivan.khoronzhuk wrote: > On 11/20/2013 08:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: > >> + the chip select signal. > >> + Minimum value is 1 (0 treated as 1). > >> + > >> +- ti,cs-wsetup: write setup width, ns > >> + Time between the beginning of a memory cycle > >> + and the activation of write strobe. > >> + Minimum value is 1 (0 treated as 1). > >> + > >> +- ti,cs-wstrobe: write strobe width, ns > >> + Time between the activation and deactivation of > >> + the write strobe. > >> + Minimum value is 1 (0 treated as 1). > >> + > >> +- ti,cs-whold: write hold width, ns > >> + Time between the deactivation of the write > >> + strobe and the end of the cycle (which may be > >> + either an address change or the deactivation of > >> + the chip select signal. > >> + Minimum value is 1 (0 treated as 1). > >> + > >> +If any of the above parameters are absent, current parameter value will be taken > >> +from the corresponding HW reg. > >> + > >> +The name for cs node must be in format csN, where N is the cs number. > > > > this is wired we should use reg instead to represent the cs as done for SPI > > or a an other property > > > > Best Regards, > > J. > > > > Ok, I will add new property cs-chipselect like following : > > ti,cs-chipselect: number of chipselect. Indicates on the > aemif driver which chipselect is used > for accessing the memory. > For compatibles "ti,davinci-aemif" and > "ti,keystone-aemif" it can be in range [0-3]. > For compatible "ti,omap-L138-aemif" range is [2-5]. > > Is it OK? yes I just have one issue the whole memory concept for me we should do as done on pinctrl have a phandle on the device that require it and handle it at device core level as the memory controller is not necessarely on the same bus as the memory device them selves Best Regards, J. > > -- > Regards, > Ivan Khoronzhuk
On Nov 20, 2013, at 9:46 AM, Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> wrote: > Add bindings for AEMIF controller drivers/memory/ti-aemif.c > Binding shouldn’t normally refer to code. Just saying something like: Adding binging for TI Async External Memory Interface (AEMIF) controller. > Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> > --- > .../bindings/memory-controllers/ti-aemif.txt | 198 ++++++++++++++++++++ > 1 file changed, 198 insertions(+) > create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt > > diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt > new file mode 100644 > index 0000000..be0c0cb > --- /dev/null > +++ b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt > @@ -0,0 +1,198 @@ > +* Device tree bindings for Texas instruments AEMIF controller > + > +Th Async External Memory Interface (EMIF16/AEMIF) controller is intended to The? > +provide a glue-less interface to a variety of asynchronous memory devices like > +ASRA M, NOR and NAND memory. A total of 256M bytes of any of these memories > +can be accessed at any given time via four chip selects with 64M byte access > +per chip select. Synchronous memories such as DDR1 SD RAM, SDR SDRAM > +and Mobile SDR are not supported. > + > +Documentation: > +Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf > +OMAP-L138 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf > +Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf > + > +Required properties: > + > +- compatible: "ti,davinci-aemif" > + "ti,keystone-aemif" > + "ti,omap-L138-aemif" > + > +- #address-cells: Must be 2. The first cell is the memory partition > + number. The 0 partition is for chip selects. And the > + second cell is the offset into the partition, for the 0 > + partition it corresponds to chip select offset. > + Is the first cell just the chip select number? I’m wondering if this is similar to FSL Localbus controller, see the binding: bindings/powerpc/fsl/lbc.txt > +- #size-cells: Must be set to 1. > + > +- reg: contains offset/length value for AEMIF control registers > + space. > + > +- ranges: Must be set up to reflect the memory layout for 4 > + chipselects and for AEMIF control range. > + > +- clocks: phandle reference to the controller clock. Required only > + if clock tree data present in device tree. > + See clock-bindings.txt > + > +- clock-names: clock name. It has to be "aemif". Required only if clock > + tree data present in device tree, in another case don't > + use it. > + See clock-bindings.txt > + > +- clock-ranges: Empty property indicating that child nodes can inherit > + named clocks. Required only if clock tree data present > + in device tree. > + See clock-bindings.txt > + > + > +Child chip-select (cs) nodes contain the memory devices nodes connected to > +such as NOR (e.g. cfi-flash) and NAND (ti,davinci-nand, see davinci-nand.txt). > +There might be board specific devices like FPGAs. > + > +Required child cs node properties: > + > +- compatible: "ti,aemif-cs" > + > +- #address-cells: Must be 2. The first cell is the memory partition > + number. The 0 partition is for chip selects. And the > + second cell is the offset into the partition, for the 0 > + partition it corresponds to chip select offset. > + > +- #size-cells: Must be 1. > + > +- ranges: Empty property indicating that child nodes can inherit > + memory layout. > + > +- clock-ranges: Empty property indicating that child nodes can inherit > + named clocks. Required only if clock tree data present > + in device tree. > + > +Optional child cs node properties: > + > + > +- ti,bus-width: width of the asynchronous device's data bus > + 8 or 16 if not preset 8 > + > +- ti,cs-ss: enable/disable select strobe mode > + In select strobe mode chip select behaves as > + the strobe and is active only during the strobe > + period. If present then enable. > + > +- ti,cs-ew: enable/disable extended wait mode > + if set, the controller monitors the EMIFWAIT pin > + mapped to that chip select to determine if the > + device wants to extend the strobe period. If > + present then enable. > + > +- ti,cs-ta: minimum turn around time, ns > + Time between the end of one asynchronous memory > + access and the start of another asynchronous > + memory access. This delay is not incurred > + between a read followed by read or a write > + followed by a write to same chip select. > + > +- ti,cs-rsetup: read setup width, ns > + Time between the beginning of a memory cycle > + and the activation of read strobe. > + Minimum value is 1 (0 treated as 1). > + > +- ti,cs-rstobe: read strobe width, ns > + Time between the activation and deactivation of > + the read strobe. > + Minimum value is 1 (0 treated as 1). > + > +- ti,cs-rhold: read hold width, ns > + Time between the deactivation of the read > + strobe and the end of the cycle (which may be > + either an address change or the deactivation of > + the chip select signal. > + Minimum value is 1 (0 treated as 1). > + > +- ti,cs-wsetup: write setup width, ns > + Time between the beginning of a memory cycle > + and the activation of write strobe. > + Minimum value is 1 (0 treated as 1). > + > +- ti,cs-wstrobe: write strobe width, ns > + Time between the activation and deactivation of > + the write strobe. > + Minimum value is 1 (0 treated as 1). > + > +- ti,cs-whold: write hold width, ns > + Time between the deactivation of the write > + strobe and the end of the cycle (which may be > + either an address change or the deactivation of > + the chip select signal. > + Minimum value is 1 (0 treated as 1). > + > +If any of the above parameters are absent, current parameter value will be taken > +from the corresponding HW reg. > + > +The name for cs node must be in format csN, where N is the cs number. > +For compatibles "ti,davinci-aemif" and "ti,keystone-aemif" N = [0-3]. > +For compatible "ti,omap-L138-aemif" N = [2-5]. > + > +Example for aemif, davinci nand and nor flash chip select shown below. > + > +memory-controller@21000A00 { > + compatible = "ti,keystone-aemif"; > + #address-cells = <2>; > + #size-cells = <1>; > + clocks = <&clkaemif 0>; > + clock-names = "aemif"; > + clock-ranges; > + reg = <0x2100A00 0x00000100>; > + ranges = <0 0 0x70000000 0x10000000 > + 1 0 0x21000A00 0x0000100>; > + > + nand:cs2 { > + compatible = "ti,aemif-cs"; > + #address-cells = <2>; > + #size-cells = <1>; > + clock-ranges; > + ranges; > + > + /* all timings in nanoseconds */ > + ti,cs-ta = <0>; > + ti,cs-rhold = <7>; > + ti,cs-rstrobe = <42>; > + ti,cs-rsetup = <14>; > + ti,cs-whold = <7>; > + ti,cs-wstrobe = <42>; > + ti,cs-wsetup = <14>; > + > + nand@0,0x8000000 { > + compatible = "ti,davinci-nand"; > + reg = <0 0x8000000 0x4000000 > + 1 0x0000000 0x0000100>; > + > + .. see davinci-nand.txt > + }; > + }; > + > + nor:cs0 { > + compatible = "ti,aemif-cs"; > + #address-cells = <2>; > + #size-cells = <1>; > + clock-ranges; > + ranges; > + > + /* all timings in nanoseconds */ > + ti,cs-ta = <0>; > + ti,cs-rhold = <8>; > + ti,cs-rstrobe = <40>; > + ti,cs-rsetup = <14>; > + ti,cs-whold = <7>; > + ti,cs-wstrobe = <40>; > + ti,cs-wsetup = <14>; > + ti,cs-asize = <1>; > + > + flash@0,0x0000000 { > + compatible = "cfi-flash"; > + reg = <0 0x0000000 0x4000000>; > + > + ... > + }; > + }; > +}; > -- > 1.7.9.5 > > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On Nov 20, 2013, at 1:03 PM, ivan.khoronzhuk <ivan.khoronzhuk@ti.com> wrote: > On 11/20/2013 08:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: >>> + the chip select signal. >>> + Minimum value is 1 (0 treated as 1). >>> + >>> +- ti,cs-wsetup: write setup width, ns >>> + Time between the beginning of a memory cycle >>> + and the activation of write strobe. >>> + Minimum value is 1 (0 treated as 1). >>> + >>> +- ti,cs-wstrobe: write strobe width, ns >>> + Time between the activation and deactivation of >>> + the write strobe. >>> + Minimum value is 1 (0 treated as 1). >>> + >>> +- ti,cs-whold: write hold width, ns >>> + Time between the deactivation of the write >>> + strobe and the end of the cycle (which may be >>> + either an address change or the deactivation of >>> + the chip select signal. >>> + Minimum value is 1 (0 treated as 1). >>> + >>> +If any of the above parameters are absent, current parameter value will be taken >>> +from the corresponding HW reg. >>> + >>> +The name for cs node must be in format csN, where N is the cs number. >> >> this is wired we should use reg instead to represent the cs as done for SPI >> or a an other property >> >> Best Regards, >> J. >> > > Ok, I will add new property cs-chipselect like following : > > ti,cs-chipselect: number of chipselect. Indicates on the > aemif driver which chipselect is used > for accessing the memory. > For compatibles "ti,davinci-aemif" and > "ti,keystone-aemif" it can be in range [0-3]. > For compatible "ti,omap-L138-aemif" range is [2-5]. > > Is it OK? Why do you need this? As it was mentioned just use reg: So you’d have something like: memory-controller@21000A00 { … nand:cs2@2 { reg = <2 0 0>; ranges; ... }: }; However, I’m confused by the example in which you have: + nand@0,0x8000000 { + compatible = "ti,davinci-nand"; + reg = <0 0x8000000 0x4000000 + 1 0x0000000 0x0000100>; + + .. see davinci-nand.txt + }; What chipselects is this on 0 & 1? - k > > -- > Regards, > Ivan Khoronzhuk > -- > To unsubscribe from this list: send the line "unsubscribe devicetree" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/22/2013 11:04 PM, Kumar Gala wrote: > > On Nov 20, 2013, at 9:46 AM, Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> wrote: > >> Add bindings for AEMIF controller drivers/memory/ti-aemif.c >> > > Binding shouldn’t normally refer to code. > > Just saying something like: > > Adding binging for TI Async External Memory Interface (AEMIF) controller. > > >> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> >> --- >> .../bindings/memory-controllers/ti-aemif.txt | 198 ++++++++++++++++++++ >> 1 file changed, 198 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt >> >> diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt >> new file mode 100644 >> index 0000000..be0c0cb >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt >> @@ -0,0 +1,198 @@ >> +* Device tree bindings for Texas instruments AEMIF controller >> + >> +Th Async External Memory Interface (EMIF16/AEMIF) controller is intended to > > The? > >> +provide a glue-less interface to a variety of asynchronous memory devices like >> +ASRA M, NOR and NAND memory. A total of 256M bytes of any of these memories >> +can be accessed at any given time via four chip selects with 64M byte access >> +per chip select. Synchronous memories such as DDR1 SD RAM, SDR SDRAM >> +and Mobile SDR are not supported. >> + >> +Documentation: >> +Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf >> +OMAP-L138 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf >> +Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf >> + >> +Required properties: >> + >> +- compatible: "ti,davinci-aemif" >> + "ti,keystone-aemif" >> + "ti,omap-L138-aemif" >> + >> +- #address-cells: Must be 2. The first cell is the memory partition >> + number. The 0 partition is for chip selects. And the >> + second cell is the offset into the partition, for the 0 >> + partition it corresponds to chip select offset. >> + > > Is the first cell just the chip select number? No. It's rather memory range/partition number. Now there are 2 partitions: - control partition which is common for all CS interfaces - CS-specific partition/range (this one can be splitted according to specific SoC requirement) As per Keystone TCI6638K2K Datasheet http://www.ti.com/lit/ds/sprs836d/sprs836d.pdf: 1) the memory range 0 will be from 0x30000000 size 0x10000000: 00 3000 0000 - 00 33FF FFFF 64M EMIF16 CE0 00 3400 0000 - 00 37FF FFFF 64M EMIF16 CE1 00 3800 0000 - 00 3BFF FFFF 64M EMIF16 CE2 00 3C00 0000 - 00 3FFF FFFF 64M EMIF16 CE3 2) the memory range 1: 00 2100 0A00 - 00 2100 0AFF 256 AEMIF Config And AEMIF node contains definition: ranges = <0 0 0x30000000 0x10000000 1 0 0x21000A00 0x0000100>; Child node has (nand): reg = <0 0 0x4000000 (cs0) - or - 0 0x4000000 0x4000000 (cs1) - or - 0 0x8000000 0x4000000 (cs2) - or - 0 0xC000000 0x4000000 (cs3) - and - 1 0 0x0000100>; (for all cs) For example for cs2 child node the resulting mem range 0 will be calculated as from: 0x30000000 + (0 0x8000000 - 0 0) size: 0x4000000 We don't encode CS number in reg/ranges, because it will allow simply change AEMIF DT definitions depending on each SoC (AEMIF CS memory range can be continuous as above or not, if not - additional range/partition can be added and child device can select the proper one). > > I’m wondering if this is similar to FSL Localbus controller, see the binding: > > bindings/powerpc/fsl/lbc.txt Don't think so :) it looks similar just because of using standard bindings (gpmc-nand.c mvebu-devbus.txt ti-gpmc.txt and etc.) > >> +- #size-cells: Must be set to 1. >> + >> +- reg: contains offset/length value for AEMIF control registers >> + space. >> + >> +- ranges: Must be set up to reflect the memory layout for 4 >> + chipselects and for AEMIF control range. >> + >> +- clocks: phandle reference to the controller clock. Required only >> + if clock tree data present in device tree. >> + See clock-bindings.txt [..] >> More majordomo info at http://vger.kernel.org/majordomo-info.html > Regards, -grygorii
On 11/22/2013 11:04 PM, Kumar Gala wrote: > > On Nov 20, 2013, at 9:46 AM, Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> wrote: > >> Add bindings for AEMIF controller drivers/memory/ti-aemif.c >> > > Binding shouldn’t normally refer to code. > > Just saying something like: > > Adding binging for TI Async External Memory Interface (AEMIF) controller. > > Ok >> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> >> --- >> .../bindings/memory-controllers/ti-aemif.txt | 198 ++++++++++++++++++++ >> 1 file changed, 198 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt >> >> diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt >> new file mode 100644 >> index 0000000..be0c0cb >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt >> @@ -0,0 +1,198 @@ >> +* Device tree bindings for Texas instruments AEMIF controller >> + >> +Th Async External Memory Interface (EMIF16/AEMIF) controller is intended to > > The? > The >> +provide a glue-less interface to a variety of asynchronous memory devices like >> +ASRA M, NOR and NAND memory. A total of 256M bytes of any of these memories >> +can be accessed at any given time via four chip selects with 64M byte access >> +per chip select. Synchronous memories such as DDR1 SD RAM, SDR SDRAM >> +and Mobile SDR are not supported. >> + >> +Documentation: >> +Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf >> +OMAP-L138 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf >> +Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf >> + >> +Required properties: >> + >> +- compatible: "ti,davinci-aemif" >> + "ti,keystone-aemif" >> + "ti,omap-L138-aemif" >> + >> +- #address-cells: Must be 2. The first cell is the memory partition >> + number. The 0 partition is for chip selects. And the >> + second cell is the offset into the partition, for the 0 >> + partition it corresponds to chip select offset. >> + > > Is the first cell just the chip select number? > > I’m wondering if this is similar to FSL Localbus controller, see the binding: > > bindings/powerpc/fsl/lbc.txt > No, it is a memory range number >> +- #size-cells: Must be set to 1. >> + >> +- reg: contains offset/length value for AEMIF control registers >> + space. >> + >> +- ranges: Must be set up to reflect the memory layout for 4 >> + chipselects and for AEMIF control range. >> + >> +- clocks: phandle reference to the controller clock. Required only >> + if clock tree data present in device tree. >> + See clock-bindings.txt >> + >> +- clock-names: clock name. It has to be "aemif". Required only if clock >> + tree data present in device tree, in another case don't >> + use it. >> + See clock-bindings.txt >> + >> +- clock-ranges: Empty property indicating that child nodes can inherit >> + named clocks. Required only if clock tree data present >> + in device tree. >> + See clock-bindings.txt >> + >> + >> +Child chip-select (cs) nodes contain the memory devices nodes connected to >> +such as NOR (e.g. cfi-flash) and NAND (ti,davinci-nand, see davinci-nand.txt). >> +There might be board specific devices like FPGAs. >> + >> +Required child cs node properties: >> + >> +- compatible: "ti,aemif-cs" >> + >> +- #address-cells: Must be 2. The first cell is the memory partition >> + number. The 0 partition is for chip selects. And the >> + second cell is the offset into the partition, for the 0 >> + partition it corresponds to chip select offset. >> + >> +- #size-cells: Must be 1. >> + >> +- ranges: Empty property indicating that child nodes can inherit >> + memory layout. >> + >> +- clock-ranges: Empty property indicating that child nodes can inherit >> + named clocks. Required only if clock tree data present >> + in device tree. >> + >> +Optional child cs node properties: >> + >> + >> +- ti,bus-width: width of the asynchronous device's data bus >> + 8 or 16 if not preset 8 >> + >> +- ti,cs-ss: enable/disable select strobe mode >> + In select strobe mode chip select behaves as >> + the strobe and is active only during the strobe >> + period. If present then enable. >> + >> +- ti,cs-ew: enable/disable extended wait mode >> + if set, the controller monitors the EMIFWAIT pin >> + mapped to that chip select to determine if the >> + device wants to extend the strobe period. If >> + present then enable. >> + >> +- ti,cs-ta: minimum turn around time, ns >> + Time between the end of one asynchronous memory >> + access and the start of another asynchronous >> + memory access. This delay is not incurred >> + between a read followed by read or a write >> + followed by a write to same chip select. >> + >> +- ti,cs-rsetup: read setup width, ns >> + Time between the beginning of a memory cycle >> + and the activation of read strobe. >> + Minimum value is 1 (0 treated as 1). >> + >> +- ti,cs-rstobe: read strobe width, ns >> + Time between the activation and deactivation of >> + the read strobe. >> + Minimum value is 1 (0 treated as 1). >> + >> +- ti,cs-rhold: read hold width, ns >> + Time between the deactivation of the read >> + strobe and the end of the cycle (which may be >> + either an address change or the deactivation of >> + the chip select signal. >> + Minimum value is 1 (0 treated as 1). >> + >> +- ti,cs-wsetup: write setup width, ns >> + Time between the beginning of a memory cycle >> + and the activation of write strobe. >> + Minimum value is 1 (0 treated as 1). >> + >> +- ti,cs-wstrobe: write strobe width, ns >> + Time between the activation and deactivation of >> + the write strobe. >> + Minimum value is 1 (0 treated as 1). >> + >> +- ti,cs-whold: write hold width, ns >> + Time between the deactivation of the write >> + strobe and the end of the cycle (which may be >> + either an address change or the deactivation of >> + the chip select signal. >> + Minimum value is 1 (0 treated as 1). >> + >> +If any of the above parameters are absent, current parameter value will be taken >> +from the corresponding HW reg. >> + >> +The name for cs node must be in format csN, where N is the cs number. >> +For compatibles "ti,davinci-aemif" and "ti,keystone-aemif" N = [0-3]. >> +For compatible "ti,omap-L138-aemif" N = [2-5]. >> + >> +Example for aemif, davinci nand and nor flash chip select shown below. >> + >> +memory-controller@21000A00 { >> + compatible = "ti,keystone-aemif"; >> + #address-cells = <2>; >> + #size-cells = <1>; >> + clocks = <&clkaemif 0>; >> + clock-names = "aemif"; >> + clock-ranges; >> + reg = <0x2100A00 0x00000100>; >> + ranges = <0 0 0x70000000 0x10000000 >> + 1 0 0x21000A00 0x0000100>; >> + >> + nand:cs2 { >> + compatible = "ti,aemif-cs"; >> + #address-cells = <2>; >> + #size-cells = <1>; >> + clock-ranges; >> + ranges; >> + >> + /* all timings in nanoseconds */ >> + ti,cs-ta = <0>; >> + ti,cs-rhold = <7>; >> + ti,cs-rstrobe = <42>; >> + ti,cs-rsetup = <14>; >> + ti,cs-whold = <7>; >> + ti,cs-wstrobe = <42>; >> + ti,cs-wsetup = <14>; >> + >> + nand@0,0x8000000 { >> + compatible = "ti,davinci-nand"; >> + reg = <0 0x8000000 0x4000000 >> + 1 0x0000000 0x0000100>; >> + >> + .. see davinci-nand.txt >> + }; >> + }; >> + >> + nor:cs0 { >> + compatible = "ti,aemif-cs"; >> + #address-cells = <2>; >> + #size-cells = <1>; >> + clock-ranges; >> + ranges; >> + >> + /* all timings in nanoseconds */ >> + ti,cs-ta = <0>; >> + ti,cs-rhold = <8>; >> + ti,cs-rstrobe = <40>; >> + ti,cs-rsetup = <14>; >> + ti,cs-whold = <7>; >> + ti,cs-wstrobe = <40>; >> + ti,cs-wsetup = <14>; >> + ti,cs-asize = <1>; >> + >> + flash@0,0x0000000 { >> + compatible = "cfi-flash"; >> + reg = <0 0x0000000 0x4000000>; >> + >> + ... >> + }; >> + }; >> +}; >> -- >> 1.7.9.5 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe devicetree" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >
On 11/22/2013 11:06 PM, Kumar Gala wrote: > > On Nov 20, 2013, at 1:03 PM, ivan.khoronzhuk <ivan.khoronzhuk@ti.com> wrote: > >> On 11/20/2013 08:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: >>>> + the chip select signal. >>>> + Minimum value is 1 (0 treated as 1). >>>> + >>>> +- ti,cs-wsetup: write setup width, ns >>>> + Time between the beginning of a memory cycle >>>> + and the activation of write strobe. >>>> + Minimum value is 1 (0 treated as 1). >>>> + >>>> +- ti,cs-wstrobe: write strobe width, ns >>>> + Time between the activation and deactivation of >>>> + the write strobe. >>>> + Minimum value is 1 (0 treated as 1). >>>> + >>>> +- ti,cs-whold: write hold width, ns >>>> + Time between the deactivation of the write >>>> + strobe and the end of the cycle (which may be >>>> + either an address change or the deactivation of >>>> + the chip select signal. >>>> + Minimum value is 1 (0 treated as 1). >>>> + >>>> +If any of the above parameters are absent, current parameter value will be taken >>>> +from the corresponding HW reg. >>>> + >>>> +The name for cs node must be in format csN, where N is the cs number. >>> >>> this is wired we should use reg instead to represent the cs as done for SPI >>> or a an other property >>> >>> Best Regards, >>> J. >>> >> >> Ok, I will add new property cs-chipselect like following : >> >> ti,cs-chipselect: number of chipselect. Indicates on the >> aemif driver which chipselect is used >> for accessing the memory. >> For compatibles "ti,davinci-aemif" and >> "ti,keystone-aemif" it can be in range [0-3]. >> For compatible "ti,omap-L138-aemif" range is [2-5]. >> >> Is it OK? > > Why do you need this? As it was mentioned just use reg: > > So you’d have something like: > > memory-controller@21000A00 { > … > nand:cs2@2 { > reg = <2 0 0>; > ranges; > ... > > }: > }; > > However, I’m confused by the example in which you have: > > + nand@0,0x8000000 { > + compatible = "ti,davinci-nand"; > + reg = <0 0x8000000 0x4000000 It means, use memory of 0 AEMIF range beginning from 0x800000 (started from beginning of this range) and with size 0x4000000 > + 1 0x0000000 0x0000100>; It means, use memory of 1 AEMIF range + 0x0000000 and with size 0x0000100 > + > + .. see davinci-nand.txt > + }; > > What chipselects is this on 0 & 1? Any of them is not cs number. 0 - is just a memory range number. > > - k > The ranges property provides a means of defining a mapping or translation between the address space of the AEMIF and the address space of the cs nodes. The reg property describes the address of the cs's resources within the address space defined by AEMIF. The reg is the memory range, not cs number. See Grygorii Starshko comment on it, he described it very well. >> >> -- >> Regards, >> Ivan Khoronzhuk >> -- >> To unsubscribe from this list: send the line "unsubscribe devicetree" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >
Hi Jean-Christophe, On 11/22/2013 08:42 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: > On 21:03 Wed 20 Nov , ivan.khoronzhuk wrote: >> On 11/20/2013 08:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: >>>> + the chip select signal. >>>> + Minimum value is 1 (0 treated as 1). >>>> + >>>> +- ti,cs-wsetup: write setup width, ns >>>> + Time between the beginning of a memory cycle >>>> + and the activation of write strobe. >>>> + Minimum value is 1 (0 treated as 1). >>>> + >>>> +- ti,cs-wstrobe: write strobe width, ns >>>> + Time between the activation and deactivation of >>>> + the write strobe. >>>> + Minimum value is 1 (0 treated as 1). >>>> + >>>> +- ti,cs-whold: write hold width, ns >>>> + Time between the deactivation of the write >>>> + strobe and the end of the cycle (which may be >>>> + either an address change or the deactivation of >>>> + the chip select signal. >>>> + Minimum value is 1 (0 treated as 1). >>>> + >>>> +If any of the above parameters are absent, current parameter value will be taken >>>> +from the corresponding HW reg. >>>> + >>>> +The name for cs node must be in format csN, where N is the cs number. >>> >>> this is wired we should use reg instead to represent the cs as done for SPI >>> or a an other property >>> >>> Best Regards, >>> J. >>> >> >> Ok, I will add new property cs-chipselect like following : >> >> ti,cs-chipselect: number of chipselect. Indicates on the >> aemif driver which chipselect is used >> for accessing the memory. >> For compatibles "ti,davinci-aemif" and >> "ti,keystone-aemif" it can be in range [0-3]. >> For compatible "ti,omap-L138-aemif" range is [2-5]. >> >> Is it OK? > > yes > > I just have one issue the whole memory concept > > for me we should do as done on pinctrl have a phandle on the device that > require it and handle it at device core level > > as the memory controller is not necessarely on the same bus as the memory > device them selves Could you clarify your point a bit, pls? Are you talking about external ASRAM, NOR and NAND chips wired to CS interface? Regards, - grygorii
Hi Kumar Gala, On 11/22/2013 11:06 PM, Kumar Gala wrote: > > On Nov 20, 2013, at 1:03 PM, ivan.khoronzhuk <ivan.khoronzhuk@ti.com> wrote: > >> On 11/20/2013 08:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: >>>> + the chip select signal. >>>> + Minimum value is 1 (0 treated as 1). >>>> + >>>> +- ti,cs-wsetup: write setup width, ns >>>> + Time between the beginning of a memory cycle >>>> + and the activation of write strobe. >>>> + Minimum value is 1 (0 treated as 1). >>>> + >>>> +- ti,cs-wstrobe: write strobe width, ns >>>> + Time between the activation and deactivation of >>>> + the write strobe. >>>> + Minimum value is 1 (0 treated as 1). >>>> + >>>> +- ti,cs-whold: write hold width, ns >>>> + Time between the deactivation of the write >>>> + strobe and the end of the cycle (which may be >>>> + either an address change or the deactivation of >>>> + the chip select signal. >>>> + Minimum value is 1 (0 treated as 1). >>>> + >>>> +If any of the above parameters are absent, current parameter value will be taken >>>> +from the corresponding HW reg. >>>> + >>>> +The name for cs node must be in format csN, where N is the cs number. >>> >>> this is wired we should use reg instead to represent the cs as done for SPI >>> or a an other property >>> >>> Best Regards, >>> J. >>> >> >> Ok, I will add new property cs-chipselect like following : >> >> ti,cs-chipselect: number of chipselect. Indicates on the >> aemif driver which chipselect is used >> for accessing the memory. >> For compatibles "ti,davinci-aemif" and >> "ti,keystone-aemif" it can be in range [0-3]. >> For compatible "ti,omap-L138-aemif" range is [2-5]. >> >> Is it OK? > > Why do you need this? As it was mentioned just use reg: > > So you’d have something like: > > memory-controller@21000A00 { > … > nand:cs2@2 { > reg = <2 0 0>; > ranges; > ... > > }: > }; I'd prefer to continue with "ti,cs-chipselect" (this is more human friendly definition, as for me), but if you insist - it can be changed as: memory-controller@21000A00 { compatible = "ti,keystone-aemif"; ... cs2 { compatible = "ti,aemif-cs"; reg = <2>; ... } cs0 { compatible = "ti,aemif-cs"; reg = <0>; ... } > > However, I’m confused by the example in which you have: > > + nand@0,0x8000000 { > + compatible = "ti,davinci-nand"; > + reg = <0 0x8000000 0x4000000 > + 1 0x0000000 0x0000100>; > + > + .. see davinci-nand.txt > + }; > > What chipselects is this on 0 & 1? As I described in https://lkml.org/lkml/2013/11/26/282 we are not encoding CS number in reg - it's memory partition number. Also, I'd like to note that we *DO NOT introduce* NAND device bindings here. The Davinci NAND bindings was introduced and accepted more then one year ago, and we've just updated its a bit (keeping full compatibility) and reused (see https://lkml.org/lkml/2013/11/21/182). And the CS number is encoded for Davinci NAND node using standalone property "ti,davinci-chipselect" and we need to provide (2) two memory ranges to it, as result we can't encode CS number in "reg" for AEMIF child devices (NAND/NOR/etc), as it will break bindings compatibility. In this document, NAND node is used just as an example of child node. Regards, - grygorii
On Friday 29 November 2013 09:56 AM, Grygorii Strashko wrote: > Hi Jean-Christophe, > > On 11/22/2013 08:42 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: >> On 21:03 Wed 20 Nov , ivan.khoronzhuk wrote: >>> On 11/20/2013 08:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: >>>>> + the chip select signal. >>>>> + Minimum value is 1 (0 treated as 1). >>>>> + >>>>> +- ti,cs-wsetup: write setup width, ns >>>>> + Time between the beginning of a memory cycle >>>>> + and the activation of write strobe. >>>>> + Minimum value is 1 (0 treated as 1). >>>>> + >>>>> +- ti,cs-wstrobe: write strobe width, ns >>>>> + Time between the activation and deactivation of >>>>> + the write strobe. >>>>> + Minimum value is 1 (0 treated as 1). >>>>> + >>>>> +- ti,cs-whold: write hold width, ns >>>>> + Time between the deactivation of the write >>>>> + strobe and the end of the cycle (which may be >>>>> + either an address change or the deactivation of >>>>> + the chip select signal. >>>>> + Minimum value is 1 (0 treated as 1). >>>>> + >>>>> +If any of the above parameters are absent, current parameter value will be taken >>>>> +from the corresponding HW reg. >>>>> + >>>>> +The name for cs node must be in format csN, where N is the cs number. >>>> >>>> this is wired we should use reg instead to represent the cs as done for SPI >>>> or a an other property >>>> >>>> Best Regards, >>>> J. >>>> >>> >>> Ok, I will add new property cs-chipselect like following : >>> >>> ti,cs-chipselect: number of chipselect. Indicates on the >>> aemif driver which chipselect is used >>> for accessing the memory. >>> For compatibles "ti,davinci-aemif" and >>> "ti,keystone-aemif" it can be in range [0-3]. >>> For compatible "ti,omap-L138-aemif" range is [2-5]. >>> >>> Is it OK? >> >> yes >> >> I just have one issue the whole memory concept >> >> for me we should do as done on pinctrl have a phandle on the device that >> require it and handle it at device core level >> >> as the memory controller is not necessarely on the same bus as the memory >> device them selves > > Could you clarify your point a bit, pls? > Are you talking about external ASRAM, NOR and NAND chips wired to CS interface? > Thats probably what he means. The mtd devices can be interface with different memory controllers having different layouts to set-up timing registers. If these layouts were standard, then it would have been possible to manage the information at the core layers. Regards, Santosh
On Friday 29 November 2013 10:00 AM, Grygorii Strashko wrote: > Hi Kumar Gala, > > On 11/22/2013 11:06 PM, Kumar Gala wrote: >> >> On Nov 20, 2013, at 1:03 PM, ivan.khoronzhuk <ivan.khoronzhuk@ti.com> wrote: >> >>> On 11/20/2013 08:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: >>>>> + the chip select signal. >>>>> + Minimum value is 1 (0 treated as 1). >>>>> + >>>>> +- ti,cs-wsetup: write setup width, ns >>>>> + Time between the beginning of a memory cycle >>>>> + and the activation of write strobe. >>>>> + Minimum value is 1 (0 treated as 1). >>>>> + >>>>> +- ti,cs-wstrobe: write strobe width, ns >>>>> + Time between the activation and deactivation of >>>>> + the write strobe. >>>>> + Minimum value is 1 (0 treated as 1). >>>>> + >>>>> +- ti,cs-whold: write hold width, ns >>>>> + Time between the deactivation of the write >>>>> + strobe and the end of the cycle (which may be >>>>> + either an address change or the deactivation of >>>>> + the chip select signal. >>>>> + Minimum value is 1 (0 treated as 1). >>>>> + >>>>> +If any of the above parameters are absent, current parameter value will be taken >>>>> +from the corresponding HW reg. >>>>> + >>>>> +The name for cs node must be in format csN, where N is the cs number. >>>> >>>> this is wired we should use reg instead to represent the cs as done for SPI >>>> or a an other property >>>> >>>> Best Regards, >>>> J. >>>> >>> >>> Ok, I will add new property cs-chipselect like following : >>> >>> ti,cs-chipselect: number of chipselect. Indicates on the >>> aemif driver which chipselect is used >>> for accessing the memory. >>> For compatibles "ti,davinci-aemif" and >>> "ti,keystone-aemif" it can be in range [0-3]. >>> For compatible "ti,omap-L138-aemif" range is [2-5]. >>> >>> Is it OK? >> >> Why do you need this? As it was mentioned just use reg: >> >> So you’d have something like: >> >> memory-controller@21000A00 { >> … >> nand:cs2@2 { >> reg = <2 0 0>; >> ranges; >> ... >> >> }: >> }; > > I'd prefer to continue with "ti,cs-chipselect" (this is more human friendly definition, as for me), > but if you insist - it can be changed as: > memory-controller@21000A00 { > compatible = "ti,keystone-aemif"; > ... > > cs2 { > compatible = "ti,aemif-cs"; > reg = <2>; > ... > } > > cs0 { > compatible = "ti,aemif-cs"; > reg = <0>; > ... > } > >> >> However, I’m confused by the example in which you have: >> >> + nand@0,0x8000000 { >> + compatible = "ti,davinci-nand"; >> + reg = <0 0x8000000 0x4000000 >> + 1 0x0000000 0x0000100>; >> + >> + .. see davinci-nand.txt >> + }; >> >> What chipselects is this on 0 & 1? > > As I described in https://lkml.org/lkml/2013/11/26/282 we are not encoding CS number in reg > - it's memory partition number. > > Also, I'd like to note that we *DO NOT introduce* NAND device bindings here. > The Davinci NAND bindings was introduced and accepted more then one year ago, and > we've just updated its a bit (keeping full compatibility) and reused > (see https://lkml.org/lkml/2013/11/21/182). > And the CS number is encoded for Davinci NAND node using standalone property > "ti,davinci-chipselect" and we need to provide (2) two memory ranges to it, > as result we can't encode CS number in "reg" for AEMIF child devices (NAND/NOR/etc), > as it will break bindings compatibility. > > In this document, NAND node is used just as an example of child node. > The above should have been really captured in the commit log to get a better picture. No way on earth, a reviewer can figure out whether this is new bindings or copy of bindings already used. Regards, Santosh
On 11/29/2013 05:10 PM, Santosh Shilimkar wrote: > On Friday 29 November 2013 10:00 AM, Grygorii Strashko wrote: >> Hi Kumar Gala, >> >> On 11/22/2013 11:06 PM, Kumar Gala wrote: >>> >>> On Nov 20, 2013, at 1:03 PM, ivan.khoronzhuk <ivan.khoronzhuk@ti.com> wrote: >>> >>>> On 11/20/2013 08:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote: >>>>>> + the chip select signal. >>>>>> + Minimum value is 1 (0 treated as 1). >>>>>> + >>>>>> +- ti,cs-wsetup: write setup width, ns >>>>>> + Time between the beginning of a memory cycle >>>>>> + and the activation of write strobe. >>>>>> + Minimum value is 1 (0 treated as 1). >>>>>> + >>>>>> +- ti,cs-wstrobe: write strobe width, ns >>>>>> + Time between the activation and deactivation of >>>>>> + the write strobe. >>>>>> + Minimum value is 1 (0 treated as 1). >>>>>> + >>>>>> +- ti,cs-whold: write hold width, ns >>>>>> + Time between the deactivation of the write >>>>>> + strobe and the end of the cycle (which may be >>>>>> + either an address change or the deactivation of >>>>>> + the chip select signal. >>>>>> + Minimum value is 1 (0 treated as 1). >>>>>> + >>>>>> +If any of the above parameters are absent, current parameter value will be taken >>>>>> +from the corresponding HW reg. >>>>>> + >>>>>> +The name for cs node must be in format csN, where N is the cs number. >>>>> >>>>> this is wired we should use reg instead to represent the cs as done for SPI >>>>> or a an other property >>>>> >>>>> Best Regards, >>>>> J. >>>>> >>>> >>>> Ok, I will add new property cs-chipselect like following : >>>> >>>> ti,cs-chipselect: number of chipselect. Indicates on the >>>> aemif driver which chipselect is used >>>> for accessing the memory. >>>> For compatibles "ti,davinci-aemif" and >>>> "ti,keystone-aemif" it can be in range [0-3]. >>>> For compatible "ti,omap-L138-aemif" range is [2-5]. >>>> >>>> Is it OK? >>> >>> Why do you need this? As it was mentioned just use reg: >>> >>> So you’d have something like: >>> >>> memory-controller@21000A00 { >>> … >>> nand:cs2@2 { >>> reg = <2 0 0>; >>> ranges; >>> ... >>> >>> }: >>> }; >> >> I'd prefer to continue with "ti,cs-chipselect" (this is more human friendly definition, as for me), >> but if you insist - it can be changed as: >> memory-controller@21000A00 { >> compatible = "ti,keystone-aemif"; >> ... >> >> cs2 { >> compatible = "ti,aemif-cs"; >> reg = <2>; >> ... >> } >> >> cs0 { >> compatible = "ti,aemif-cs"; >> reg = <0>; >> ... >> } >> >>> >>> However, I’m confused by the example in which you have: >>> >>> + nand@0,0x8000000 { >>> + compatible = "ti,davinci-nand"; >>> + reg = <0 0x8000000 0x4000000 >>> + 1 0x0000000 0x0000100>; >>> + >>> + .. see davinci-nand.txt >>> + }; >>> >>> What chipselects is this on 0 & 1? >> >> As I described in https://lkml.org/lkml/2013/11/26/282 we are not encoding CS number in reg >> - it's memory partition number. >> >> Also, I'd like to note that we *DO NOT introduce* NAND device bindings here. >> The Davinci NAND bindings was introduced and accepted more then one year ago, and >> we've just updated its a bit (keeping full compatibility) and reused >> (see https://lkml.org/lkml/2013/11/21/182). >> And the CS number is encoded for Davinci NAND node using standalone property >> "ti,davinci-chipselect" and we need to provide (2) two memory ranges to it, >> as result we can't encode CS number in "reg" for AEMIF child devices (NAND/NOR/etc), >> as it will break bindings compatibility. >> >> In this document, NAND node is used just as an example of child node. >> > The above should have been really captured in the commit log to get a better > picture. No way on earth, a reviewer can figure out whether this is new bindings > or copy of bindings already used. > > Regards, > Santosh > Ok, I will add it.
Kumar, On Tuesday 26 November 2013 11:27 AM, Grygorii Strashko wrote: > On 11/22/2013 11:04 PM, Kumar Gala wrote: >> >> On Nov 20, 2013, at 9:46 AM, Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> wrote: >> >>> Add bindings for AEMIF controller drivers/memory/ti-aemif.c >>> >> >> Binding shouldn’t normally refer to code. >> >> Just saying something like: >> >> Adding binging for TI Async External Memory Interface (AEMIF) controller. >> >> >>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> >>> --- >>> .../bindings/memory-controllers/ti-aemif.txt | 198 ++++++++++++++++++++ >>> 1 file changed, 198 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt >>> >>> diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt >>> new file mode 100644 >>> index 0000000..be0c0cb >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt >>> @@ -0,0 +1,198 @@ >>> +* Device tree bindings for Texas instruments AEMIF controller >>> + >>> +Th Async External Memory Interface (EMIF16/AEMIF) controller is intended to >> >> The? >> >>> +provide a glue-less interface to a variety of asynchronous memory devices like >>> +ASRA M, NOR and NAND memory. A total of 256M bytes of any of these memories >>> +can be accessed at any given time via four chip selects with 64M byte access >>> +per chip select. Synchronous memories such as DDR1 SD RAM, SDR SDRAM >>> +and Mobile SDR are not supported. >>> + >>> +Documentation: >>> +Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf >>> +OMAP-L138 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf >>> +Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf >>> + >>> +Required properties: >>> + >>> +- compatible: "ti,davinci-aemif" >>> + "ti,keystone-aemif" >>> + "ti,omap-L138-aemif" >>> + >>> +- #address-cells: Must be 2. The first cell is the memory partition >>> + number. The 0 partition is for chip selects. And the >>> + second cell is the offset into the partition, for the 0 >>> + partition it corresponds to chip select offset. >>> + >> >> Is the first cell just the chip select number? > > No. It's rather memory range/partition number. Now there are 2 partitions: > - control partition which is common for all CS interfaces > - CS-specific partition/range > (this one can be splitted according to specific SoC requirement) > > As per Keystone TCI6638K2K > Datasheet http://www.ti.com/lit/ds/sprs836d/sprs836d.pdf: > > 1) the memory range 0 will be from 0x30000000 size 0x10000000: > 00 3000 0000 - 00 33FF FFFF 64M EMIF16 CE0 > 00 3400 0000 - 00 37FF FFFF 64M EMIF16 CE1 > 00 3800 0000 - 00 3BFF FFFF 64M EMIF16 CE2 > 00 3C00 0000 - 00 3FFF FFFF 64M EMIF16 CE3 > > 2) the memory range 1: > 00 2100 0A00 - 00 2100 0AFF 256 AEMIF Config > > And AEMIF node contains definition: > ranges = <0 0 0x30000000 0x10000000 > 1 0 0x21000A00 0x0000100>; > > > Child node has (nand): > reg = <0 0 0x4000000 (cs0) > - or - 0 0x4000000 0x4000000 (cs1) > - or - 0 0x8000000 0x4000000 (cs2) > - or - 0 0xC000000 0x4000000 (cs3) > - and - > 1 0 0x0000100>; (for all cs) > > For example for cs2 child node the resulting mem range 0 will be calculated as > > from: 0x30000000 + (0 0x8000000 - 0 0) > size: 0x4000000 > > We don't encode CS number in reg/ranges, because it will allow simply change > AEMIF DT definitions depending on each SoC > (AEMIF CS memory range can be continuous as above or not, if not - additional > range/partition can be added and child device can select the proper one). > >> >> I’m wondering if this is similar to FSL Localbus controller, see the binding: >> >> bindings/powerpc/fsl/lbc.txt > > Don't think so :) it looks similar just because of using standard bindings > (gpmc-nand.c mvebu-devbus.txt ti-gpmc.txt and etc.) > >> >>> +- #size-cells: Must be set to 1. >>> + >>> +- reg: contains offset/length value for AEMIF control registers >>> + space. >>> + >>> +- ranges: Must be set up to reflect the memory layout for 4 >>> + chipselects and for AEMIF control range. >>> + >>> +- clocks: phandle reference to the controller clock. Required only >>> + if clock tree data present in device tree. >>> + See clock-bindings.txt Are you ok with above description on why cs property is needed. We will need your ack ;-) to take these patches forward. Regards, Santosh
On Nov 26, 2013, at 10:27 AM, Grygorii Strashko <grygorii.strashko@ti.com> wrote: > On 11/22/2013 11:04 PM, Kumar Gala wrote: >> >> On Nov 20, 2013, at 9:46 AM, Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> wrote: >> >>> Add bindings for AEMIF controller drivers/memory/ti-aemif.c >>> >> >> Binding shouldn’t normally refer to code. >> >> Just saying something like: >> >> Adding binging for TI Async External Memory Interface (AEMIF) controller. >> >> >>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> >>> --- >>> .../bindings/memory-controllers/ti-aemif.txt | 198 ++++++++++++++++++++ >>> 1 file changed, 198 insertions(+) >>> create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt >>> >>> diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt >>> new file mode 100644 >>> index 0000000..be0c0cb >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt >>> @@ -0,0 +1,198 @@ >>> +* Device tree bindings for Texas instruments AEMIF controller >>> + >>> +Th Async External Memory Interface (EMIF16/AEMIF) controller is intended to >> >> The? >> >>> +provide a glue-less interface to a variety of asynchronous memory devices like >>> +ASRA M, NOR and NAND memory. A total of 256M bytes of any of these memories >>> +can be accessed at any given time via four chip selects with 64M byte access >>> +per chip select. Synchronous memories such as DDR1 SD RAM, SDR SDRAM >>> +and Mobile SDR are not supported. >>> + >>> +Documentation: >>> +Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf >>> +OMAP-L138 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf >>> +Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf >>> + >>> +Required properties: >>> + >>> +- compatible: "ti,davinci-aemif" >>> + "ti,keystone-aemif" >>> + "ti,omap-L138-aemif" >>> + >>> +- #address-cells: Must be 2. The first cell is the memory partition >>> + number. The 0 partition is for chip selects. And the >>> + second cell is the offset into the partition, for the 0 >>> + partition it corresponds to chip select offset. >>> + >> >> Is the first cell just the chip select number? > > No. It's rather memory range/partition number. Now there are 2 partitions: > - control partition which is common for all CS interfaces > - CS-specific partition/range > (this one can be splitted according to specific SoC requirement) > > As per Keystone TCI6638K2K > Datasheet http://www.ti.com/lit/ds/sprs836d/sprs836d.pdf: > > 1) the memory range 0 will be from 0x30000000 size 0x10000000: > 00 3000 0000 - 00 33FF FFFF 64M EMIF16 CE0 > 00 3400 0000 - 00 37FF FFFF 64M EMIF16 CE1 > 00 3800 0000 - 00 3BFF FFFF 64M EMIF16 CE2 > 00 3C00 0000 - 00 3FFF FFFF 64M EMIF16 CE3 > > 2) the memory range 1: > 00 2100 0A00 - 00 2100 0AFF 256 AEMIF Config > > And AEMIF node contains definition: > ranges = <0 0 0x30000000 0x10000000 > 1 0 0x21000A00 0x0000100>; > > > Child node has (nand): > reg = <0 0 0x4000000 (cs0) > - or - 0 0x4000000 0x4000000 (cs1) > - or - 0 0x8000000 0x4000000 (cs2) > - or - 0 0xC000000 0x4000000 (cs3) > - and - > 1 0 0x0000100>; (for all cs) > > For example for cs2 child node the resulting mem range 0 will be calculated as > > from: 0x30000000 + (0 0x8000000 - 0 0) > size: 0x4000000 > > We don't encode CS number in reg/ranges, because it will allow simply change > AEMIF DT definitions depending on each SoC > (AEMIF CS memory range can be continuous as above or not, if not - additional > range/partition can be added and child device can select the proper one). This is quite confusing. I think the ranges property needs far more description as part of the top level controller node. It spec out what the various fields are in the ranges property. - k
On 12/10/2013 01:09 AM, Kumar Gala wrote: > > On Nov 26, 2013, at 10:27 AM, Grygorii Strashko <grygorii.strashko@ti.com> wrote: > >> On 11/22/2013 11:04 PM, Kumar Gala wrote: >>> >>> On Nov 20, 2013, at 9:46 AM, Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> wrote: >>> >>>> Add bindings for AEMIF controller drivers/memory/ti-aemif.c >>>> >>> >>> Binding shouldn’t normally refer to code. >>> >>> Just saying something like: >>> >>> Adding binging for TI Async External Memory Interface (AEMIF) controller. >>> >>> >>>> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> >>>> --- >>>> .../bindings/memory-controllers/ti-aemif.txt | 198 ++++++++++++++++++++ >>>> 1 file changed, 198 insertions(+) >>>> create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt >>>> >>>> diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt >>>> new file mode 100644 >>>> index 0000000..be0c0cb >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt >>>> @@ -0,0 +1,198 @@ >>>> +* Device tree bindings for Texas instruments AEMIF controller >>>> + >>>> +Th Async External Memory Interface (EMIF16/AEMIF) controller is intended to >>> >>> The? >>> >>>> +provide a glue-less interface to a variety of asynchronous memory devices like >>>> +ASRA M, NOR and NAND memory. A total of 256M bytes of any of these memories >>>> +can be accessed at any given time via four chip selects with 64M byte access >>>> +per chip select. Synchronous memories such as DDR1 SD RAM, SDR SDRAM >>>> +and Mobile SDR are not supported. >>>> + >>>> +Documentation: >>>> +Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf >>>> +OMAP-L138 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf >>>> +Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf >>>> + >>>> +Required properties: >>>> + >>>> +- compatible: "ti,davinci-aemif" >>>> + "ti,keystone-aemif" >>>> + "ti,omap-L138-aemif" >>>> + >>>> +- #address-cells: Must be 2. The first cell is the memory partition >>>> + number. The 0 partition is for chip selects. And the >>>> + second cell is the offset into the partition, for the 0 >>>> + partition it corresponds to chip select offset. >>>> + >>> >>> Is the first cell just the chip select number? >> >> No. It's rather memory range/partition number. Now there are 2 partitions: >> - control partition which is common for all CS interfaces >> - CS-specific partition/range >> (this one can be splitted according to specific SoC requirement) >> >> As per Keystone TCI6638K2K >> Datasheet http://www.ti.com/lit/ds/sprs836d/sprs836d.pdf: >> >> 1) the memory range 0 will be from 0x30000000 size 0x10000000: >> 00 3000 0000 - 00 33FF FFFF 64M EMIF16 CE0 >> 00 3400 0000 - 00 37FF FFFF 64M EMIF16 CE1 >> 00 3800 0000 - 00 3BFF FFFF 64M EMIF16 CE2 >> 00 3C00 0000 - 00 3FFF FFFF 64M EMIF16 CE3 >> >> 2) the memory range 1: >> 00 2100 0A00 - 00 2100 0AFF 256 AEMIF Config >> >> And AEMIF node contains definition: >> ranges = <0 0 0x30000000 0x10000000 >> 1 0 0x21000A00 0x0000100>; >> >> >> Child node has (nand): >> reg = <0 0 0x4000000 (cs0) >> - or - 0 0x4000000 0x4000000 (cs1) >> - or - 0 0x8000000 0x4000000 (cs2) >> - or - 0 0xC000000 0x4000000 (cs3) >> - and - >> 1 0 0x0000100>; (for all cs) >> >> For example for cs2 child node the resulting mem range 0 will be calculated as >> >> from: 0x30000000 + (0 0x8000000 - 0 0) >> size: 0x4000000 >> >> We don't encode CS number in reg/ranges, because it will allow simply change >> AEMIF DT definitions depending on each SoC >> (AEMIF CS memory range can be continuous as above or not, if not - additional >> range/partition can be added and child device can select the proper one). > > This is quite confusing. I think the ranges property needs far more description as part of the top level controller node. It spec out what the various fields are in the ranges property. > Yes, you are right, description is quite poor. I should describe it more clearly
diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt new file mode 100644 index 0000000..be0c0cb --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt @@ -0,0 +1,198 @@ +* Device tree bindings for Texas instruments AEMIF controller + +Th Async External Memory Interface (EMIF16/AEMIF) controller is intended to +provide a glue-less interface to a variety of asynchronous memory devices like +ASRA M, NOR and NAND memory. A total of 256M bytes of any of these memories +can be accessed at any given time via four chip selects with 64M byte access +per chip select. Synchronous memories such as DDR1 SD RAM, SDR SDRAM +and Mobile SDR are not supported. + +Documentation: +Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf +OMAP-L138 - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf +Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf + +Required properties: + +- compatible: "ti,davinci-aemif" + "ti,keystone-aemif" + "ti,omap-L138-aemif" + +- #address-cells: Must be 2. The first cell is the memory partition + number. The 0 partition is for chip selects. And the + second cell is the offset into the partition, for the 0 + partition it corresponds to chip select offset. + +- #size-cells: Must be set to 1. + +- reg: contains offset/length value for AEMIF control registers + space. + +- ranges: Must be set up to reflect the memory layout for 4 + chipselects and for AEMIF control range. + +- clocks: phandle reference to the controller clock. Required only + if clock tree data present in device tree. + See clock-bindings.txt + +- clock-names: clock name. It has to be "aemif". Required only if clock + tree data present in device tree, in another case don't + use it. + See clock-bindings.txt + +- clock-ranges: Empty property indicating that child nodes can inherit + named clocks. Required only if clock tree data present + in device tree. + See clock-bindings.txt + + +Child chip-select (cs) nodes contain the memory devices nodes connected to +such as NOR (e.g. cfi-flash) and NAND (ti,davinci-nand, see davinci-nand.txt). +There might be board specific devices like FPGAs. + +Required child cs node properties: + +- compatible: "ti,aemif-cs" + +- #address-cells: Must be 2. The first cell is the memory partition + number. The 0 partition is for chip selects. And the + second cell is the offset into the partition, for the 0 + partition it corresponds to chip select offset. + +- #size-cells: Must be 1. + +- ranges: Empty property indicating that child nodes can inherit + memory layout. + +- clock-ranges: Empty property indicating that child nodes can inherit + named clocks. Required only if clock tree data present + in device tree. + +Optional child cs node properties: + + +- ti,bus-width: width of the asynchronous device's data bus + 8 or 16 if not preset 8 + +- ti,cs-ss: enable/disable select strobe mode + In select strobe mode chip select behaves as + the strobe and is active only during the strobe + period. If present then enable. + +- ti,cs-ew: enable/disable extended wait mode + if set, the controller monitors the EMIFWAIT pin + mapped to that chip select to determine if the + device wants to extend the strobe period. If + present then enable. + +- ti,cs-ta: minimum turn around time, ns + Time between the end of one asynchronous memory + access and the start of another asynchronous + memory access. This delay is not incurred + between a read followed by read or a write + followed by a write to same chip select. + +- ti,cs-rsetup: read setup width, ns + Time between the beginning of a memory cycle + and the activation of read strobe. + Minimum value is 1 (0 treated as 1). + +- ti,cs-rstobe: read strobe width, ns + Time between the activation and deactivation of + the read strobe. + Minimum value is 1 (0 treated as 1). + +- ti,cs-rhold: read hold width, ns + Time between the deactivation of the read + strobe and the end of the cycle (which may be + either an address change or the deactivation of + the chip select signal. + Minimum value is 1 (0 treated as 1). + +- ti,cs-wsetup: write setup width, ns + Time between the beginning of a memory cycle + and the activation of write strobe. + Minimum value is 1 (0 treated as 1). + +- ti,cs-wstrobe: write strobe width, ns + Time between the activation and deactivation of + the write strobe. + Minimum value is 1 (0 treated as 1). + +- ti,cs-whold: write hold width, ns + Time between the deactivation of the write + strobe and the end of the cycle (which may be + either an address change or the deactivation of + the chip select signal. + Minimum value is 1 (0 treated as 1). + +If any of the above parameters are absent, current parameter value will be taken +from the corresponding HW reg. + +The name for cs node must be in format csN, where N is the cs number. +For compatibles "ti,davinci-aemif" and "ti,keystone-aemif" N = [0-3]. +For compatible "ti,omap-L138-aemif" N = [2-5]. + +Example for aemif, davinci nand and nor flash chip select shown below. + +memory-controller@21000A00 { + compatible = "ti,keystone-aemif"; + #address-cells = <2>; + #size-cells = <1>; + clocks = <&clkaemif 0>; + clock-names = "aemif"; + clock-ranges; + reg = <0x2100A00 0x00000100>; + ranges = <0 0 0x70000000 0x10000000 + 1 0 0x21000A00 0x0000100>; + + nand:cs2 { + compatible = "ti,aemif-cs"; + #address-cells = <2>; + #size-cells = <1>; + clock-ranges; + ranges; + + /* all timings in nanoseconds */ + ti,cs-ta = <0>; + ti,cs-rhold = <7>; + ti,cs-rstrobe = <42>; + ti,cs-rsetup = <14>; + ti,cs-whold = <7>; + ti,cs-wstrobe = <42>; + ti,cs-wsetup = <14>; + + nand@0,0x8000000 { + compatible = "ti,davinci-nand"; + reg = <0 0x8000000 0x4000000 + 1 0x0000000 0x0000100>; + + .. see davinci-nand.txt + }; + }; + + nor:cs0 { + compatible = "ti,aemif-cs"; + #address-cells = <2>; + #size-cells = <1>; + clock-ranges; + ranges; + + /* all timings in nanoseconds */ + ti,cs-ta = <0>; + ti,cs-rhold = <8>; + ti,cs-rstrobe = <40>; + ti,cs-rsetup = <14>; + ti,cs-whold = <7>; + ti,cs-wstrobe = <40>; + ti,cs-wsetup = <14>; + ti,cs-asize = <1>; + + flash@0,0x0000000 { + compatible = "cfi-flash"; + reg = <0 0x0000000 0x4000000>; + + ... + }; + }; +};
Add bindings for AEMIF controller drivers/memory/ti-aemif.c Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com> --- .../bindings/memory-controllers/ti-aemif.txt | 198 ++++++++++++++++++++ 1 file changed, 198 insertions(+) create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt