Hi Rob, On Oct 29, 2012 10:49 PM, "Rob Herring" <robherri...@gmail.com> wrote: > > On 10/29/2012 12:22 PM, Daniel Mack wrote: > > On 29.10.2012 16:09, Rob Herring wrote: > >> On 10/29/2012 09:39 AM, Daniel Mack wrote: > >>> Hi, > >>> > >>> we're currently working on a DT binding for the GPMC bus that is found > >>> on SoCs by TI. The implementation is based on CS lines and an 8, 16 or > >>> 32 bit parallel interface. That IP is quite flexible, and it can for > >>> example be used for physmap flash, external peripherals or even NAND. > >>> > >>> Depending on which CS is used to control the device, different memory > >>> regions are reserved, and there's code to calculate the location and > >>> size of them, given a CS number (see arch/arm/mach-omap2/gpmc.c). > >> > >> I don't know the details of the h/w, but I would think the DT core code > >> should be able work out the addresses. This can be done using ranges > >> property which defines the mapping of a child bus into the parent bus > >> addresses. > > > > In this case, the controller is @0x50000000 while the external device is > > mapped to address 0x0. > > Okay, so it's not fixed or some sub-range of the memory map.
It still haz a fixed position i the memory map (0 - 0x1fffffff), but how that space is divided for peripherals depends on the configuration. > > >>> The binding will use one top-level node to describe the GPMC controller > >>> itself and register the actual devices as sub-nodes to it. The NAND type > >>> is the only one that is currently supported. This is how it currently looks: > >>> > >>> gpmc: gpmc@50000000 { > >>> compatible = "ti,gpmc"; > >>> ti,hwmods = "gpmc"; > >>> reg = <0x50000000 0x2000>; > >>> interrupt-parent = <&intc>; > >>> interrupts = <100>; > >>> #address-cells = <1>; > >>> #size-cells = <0>; > >>> > >>> nand@0 { > >> > >> You may want a CS0 node with nand as a child node of that. > > > > Hmm, I don't see what that would buy us. The question is which way is > > feasible for storing both the memory region and the cs number in the > > device tree. The CS number should certainly go to the child node, no? > > I was thinking of if you had per CS properties you needed to setup each > CS. So something like this (using non-zero address to show the > translation better): > > gpmc { > compatible = "ti,gpmc", "simple-bus"; > ti,hwmods = "gpmc"; > reg = <0x50000000 0x2000>; > > CS0 { > // map 1MB @ gpmc offset 0 to host address 0x10000000 > ranges = <0x10000000 0x0 <0x100000>; The most important bit has a syntax error ;-) Was that property meant to carry 3 values? > // other gpmc specific per CS properties. > nand { > reg = <0x0 0x100000>; > } > }; > so that way, the child has the awareness about the gpmc controller config (the offset in the memory map), and is agnostic to the cs number in use, right? I think this is not really the most convenient approach from a user's perspective. > The core code will look at parents' ranges properties to translate the > local offset of 0 into host address of 0x10000000 Then the nand node's > reg address will get translated to 0x10000000. That part is understood, I'm just not sure whether this is the most useful way of describing the h/w capabilities. Thanks, Daniel > > The gpmc code can then use the ranges properties to setup the mapping of > each chip select to the host address. You don't need a new property to > describe the cs mapping. > > Rob > > > > > IOW, would it be a good idea to have something like the following layout? > > > > gpmc: gpmc@50000000 { > > compatible = "ti,gpmc"; > > ti,hwmods = "gpmc"; > > reg = <0x50000000 0x2000>; > > > > /* cs-reg stores the setup of the controller's > > memory map */ > > > > /* offset size */ > > cs-reg = <0x0 0x1000000 > > .... ..... > > .... .....>; > > > > nand: child@0 { > > /* timings */ > > /* peripheral specifics */ > > }; > > }; > > > > I would actually much prefer that approach. > > > > Afzal, because because that way, we can leave the code as-is for now and > > add the "cs-reg" property once the code is switched to dynamic handling. > > What do you think? > > > > > > Thanks, > > Daniel > > >
_______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss