linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] ARM: OMAP2+: Add new bindings for OMAP
Date: Wed, 21 Aug 2013 01:53:31 -0700	[thread overview]
Message-ID: <20130821085330.GH7656@atomide.com> (raw)
In-Reply-To: <52147E95.5000606@ti.com>

* Rajendra Nayak <rnayak@ti.com> [130821 01:54]:
> On Wednesday 21 August 2013 01:15 PM, 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.
> > 
> > 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.

Tony

  reply	other threads:[~2013-08-21  8:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-20  7:32 [PATCH 0/3] OMAP: Add DT bindings to specify when devices should not be idled or reset Rajendra Nayak
2013-08-20  7:32 ` [PATCH 1/3] ARM: OMAP2+: hwmod: cleanup HWMOD_INIT_NO_RESET usage Rajendra Nayak
2013-08-20  7:32 ` [PATCH 2/3] ARM: OMAP2+: Add new bindings for OMAP Rajendra Nayak
2013-08-21  7:45   ` Tony Lindgren
2013-08-21  8:47     ` Rajendra Nayak
2013-08-21  8:53       ` Tony Lindgren [this message]
2013-08-21  9:22         ` Rajendra Nayak
2013-08-21 12:23           ` Tony Lindgren
2013-08-21 12:39             ` Rajendra Nayak
2013-08-21 12:44               ` Rajendra Nayak
2013-08-21 12:51               ` Tony Lindgren
2013-08-21 13:12                 ` Benoit Cousson
2013-08-21  9:29     ` Benoit Cousson
2013-08-21 11:49       ` Rajendra Nayak
2013-08-20  7:32 ` [PATCH 3/3] ARM: OMAP2+: Let DT say what devices should not to idled or reset Rajendra Nayak
2013-10-09  7:24   ` Paul Walmsley
2013-10-09  7:37     ` Rajendra Nayak
2013-10-09  8:19       ` Benoit Cousson
2013-10-09  8:49         ` Rajendra Nayak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130821085330.GH7656@atomide.com \
    --to=tony@atomide.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).