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

Tony Lindgren tony at atomide.com
Wed Aug 21 03:45:14 EDT 2013


* Rajendra Nayak <rnayak at 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 at 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.

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?

Regards,

Tony



More information about the linux-arm-kernel mailing list