[PATCH 2/3] ARM: OMAP2+: Add new bindings for OMAP

[rnayak@ti.com (Rajendra Nayak)]

On Wednesday 21 August 2013 02:59 PM, Benoit Cousson wrote:
> On 21/08/2013 09:45, Tony Lindgren wrote:
>> * Rajendra Nayak <rnayak@ti.com> [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@ti.com>
>>> ---
>>>   .../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
>