* Rajendra Nayak <rnayak@xxxxxx> [130821 01:54]:
> On Wednesday 21 August 2013 01:15 PM, Tony Lindgren wrote:
> > * Rajendra Nayak <rnayak@xxxxxx> [130820 00:41]:
> >> On OMAP we have co-processor IPs, memory controllers,
> >> GPIOs which control regulators and power switches to
> >> PMIC, and SoC internal Bus IPs, some or most of which
> >> should either not be reset or idled or both. Have a
> >> way to pass this information from DT.
> >> (In some cases there are erratas which prevent an IPs
> >> from being reset)
> >>
> >> Also update omap_hwmod to extract this from DT.
> >>
> >> Signed-off-by: Rajendra Nayak <rnayak@xxxxxx>
> >> ---
> >> .../devicetree/bindings/arm/omap/omap.txt | 3 ++-
> >> arch/arm/mach-omap2/omap_hwmod.c | 22 +++++++++++++-------
> >> 2 files changed, 17 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
> >> index 6d498c7..a08647e 100644
> >> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> >> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> >> @@ -21,7 +21,8 @@ Required properties:
> >> Optional properties:
> >> - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
> >> during suspend.
> >> -
> >> +- ti,no-reset: When present, the module should not be reset
> >> +- ti,no-idle: When present, the module should not be idled
> >
> > This naming is a bit confusing as people may think that the
> > hardware has no reset support or no idle support. Let's try
> > to make this to describe the hardware a bit more instead.
> >
> > Then ideally we'd not map individual bits of data to properties,
> > but describe few basic types of hardware instead and build
> > lists of things instead of tagging things. Or maybe we
> > can get this data from the bus hierarchy instead?
>
> Yeah, I thought if I could do this without any new bindings.
> For instance, never reset or idle something which is a "cpu" or an
> "interrupt-controller" or a "memory-controller" or a "bus".
> For some like memory-controllers though there are no bindings which
> describe them as memory-controllers.
>
> >
> > If these options don't work, and the choice may be board
> > specific, then how about ti,skip-reset-on-init, and
> > ti,skip-idle-on-init?
>
> This looks fine too.
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.
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
