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