On 21/08/2013 14:51, Tony Lindgren wrote:
* Rajendra Nayak <rnayak@xxxxxx> [130821 05:46]:
On Wednesday 21 August 2013 05:53 PM, Tony Lindgren wrote:
* Rajendra Nayak <rnayak@xxxxxx> [130821 02:29]:
On Wednesday 21 August 2013 02:23 PM, Tony Lindgren wrote:
Or you could also have various bus specific bindings for the ocp
with lists of phandles?
ocp {
reg = <...>;
interrupts = <...>;
ti,reset-on-init = <&module1, &module2>;
...
};
Or something similar.
The only problem I see with this is that some of these modules could be
board specific ones and need to be part of the board dts files, like
some boards which have PMIC power switch hooked up to some gpio etc.
So there could be some SoC specific modules (like emif/gpmc on OMAPs)
and some which depend on how the boards are designed.
You can still override the ocp entry in the board specific .dts file.
Would probably be a lot easier than to override each module separately
in the board specific .dts file.
So, If I understand this right we would have the dt entries
something like,
omap4.dtsi
------
ocp {
reg = <...>;
interrupts = <...>;
ti,no-reset-on-init = <&emif1, &emif2, &gpmc>;
...
};
omap4-panda-es.dts
------
ocp {
ti,no-reset-on-init = <&emif1, &emif2, &gpmc, &gpio4>;
...
};
Is it that, or you suggesting we can _append_ the soc list of
modules with board specific modules, which I am not sure if its
possible.
Yes I think the board specific entry just overrides the .dtsi
entry.
That's the issue of using a single attribute with a list. You cannot add
or remove an entry. That's why I think it is better to stick to a per
device attribute.
Moreover, in term of SW, this is managed at device level today. I'm not
convince it will make sense to move that to the OCP level for the moment.
Even if we consider that in the future an omap-ocp bus driver will
handle most of the PM/reset glue managed today by hwmod, it will still
be a per device attribute. The bus driver, being the parent of the
device, will anyway be able to retrieve the information at device level
if needed.
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
