On Wednesday 21 August 2013 02:23 PM, Tony Lindgren wrote:
> * 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.
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.
>
> Tony
>
--
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
