On 21/08/2013 09:45, 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.
Yeah, I do agree here. That should look like a real HW property and nor
a configuration.
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?
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?
It looks like a configuration as well :-).
I was thinking of something like "ti,do-not-support-reset-on-init", but
that a little bit too long.
Regards,
Benoit
--
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
