On Wednesday 21 August 2013 02:59 PM, Benoit Cousson wrote: > 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. How about 'ti,no-reset-on-init' :) which is what I had initially which I then moved to 'ti,no-reset' > > 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
