Hi Afzal,
On 29.10.2012 12:28, Afzal Mohammed wrote:
> On Monday 29 October 2012 04:45 PM, Daniel Mack wrote:
>> On 29.10.2012 09:10, Afzal Mohammed wrote:
>
>>> Also perhaps memory size (and offset if
>>> needed) to be mapped for peripherals can go with reg
>>> property of child.
>
>> Which detail are you referring to here? The only "size" property that is
>> effective is the one of the generic GPMC block, and there it's in the
>> "reg"-property.
>
> I was referring to that of child, now in gpmc_nand_init(),
> gpmc_cs_request() is being done, later on if we want to
> make it generic and remove gpmc_nand_init(), additional
> information that would be required from DT at least is the
> memory size to be reserved in gpmc address space for
> the connected peripheral (assuming gpmc_cs_request()
> would be done by gpmc driver generically later)
>
> What I had in mind was example for external bus in [1],
> but I had not looked deep into this aspect yet.
Ok, now I see what you mean.
I would say we can use the "reg" property in child node for CS numbers
purely and if we want to get rid of the memory node allocation, we
should use a property in the gpmc top-node for this, something like:
gpmc: gpmc@50000000 {
compatible = "ti,gpmc";
cs-regs = <0x51000000 0x10000000 ...>;
};
Changing the meaning of the reg property of children from "cs number" to
"memory sub-region" later is something I would like to avoid.
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
