Hi Daniel,
On Monday 29 October 2012 06:02 PM, Daniel Mack wrote:
On 29.10.2012 12:28, Afzal Mohammed wrote:
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 ...>;
I think you meant cs-regs = <0x00000000 ..>
0x0 - 0x1fffffff is gpmc external memory address space, while
0x50000000 to plus 16MB is gpmc configuration address space.
You may refer other gpmc peripheral init's that are NOR type.
Changing the meaning of the reg property of children from "cs number" to
"memory sub-region" later is something I would like to avoid.
Changing any of the properties later is something we have
to avoid. Let us get feedback from DT maintainers.
Regards
Afzal
--
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
