From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Linux PM list <linux-pm@vger.kernel.org>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
LKML <linux-kernel@vger.kernel.org>,
Matthew Garrett <mjg59@srcf.ucam.org>,
Magnus Damm <magnus.damm@gmail.com>,
Arnd Bergmann <arnd@arndb.de>,
Grant Likely <grant.likely@secretlab.ca>,
"Linux-sh list" <linux-sh@vger.kernel.org>
Subject: Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains)
Date: Sat, 21 Jul 2012 19:17:12 +0200 [thread overview]
Message-ID: <201207211917.12519.rjw@sisk.pl> (raw)
In-Reply-To: <201207162315.49073.rjw@sisk.pl>
On Monday, July 16, 2012, Rafael J. Wysocki wrote:
> On Thursday, July 05, 2012, Rafael J. Wysocki wrote:
> > On Wednesday, July 04, 2012, Mark Brown wrote:
> > > On Tue, Jul 03, 2012 at 11:02:17PM +0200, Rafael J. Wysocki wrote:
> > >
> > > > I actually don't have any ideas how to do that at the moment, but I wonder
> > > > if anyone has already thought about it?
> > >
> > > > For one, I don't think that representing a power domain as a platform device
> > > > would be a good approach and I'm not sure how to represent the relationships
> > > > between devices and the domains they belong to.
> > >
> > > I guess the OMAP hwmod stuff is the closest thing we've got at the
> > > minute (I don't recall seeing any other implementations in mainline) but
> > > the hwmods themselves don't appear in the DTS right now. They have a
> > > ti,hwmods property on each device naming the hwmod it's in, something
> > > like that seems like a reasonable approach, possibly a reference to
> > > another DT node rather than or as well as a string? That seems fairly
> > > easy.
> >
> > Well, it looks like (and please tell me if I'm wrong) the hwmons are just
> > string attributes that are parsed by the platform-specific code through
> > a platform bus type notifier.
> >
> > We could do that for power domains too, but then each platform wanting to
> > use them would need to implement such a notifier and add its own routine
> > for parsing those strings. Would that be acceptable to everyone concerned?
>
> I tried to follow the above suggestion and prepared the following patchset
> that allows power domain information for Renesas platforms to be passed as
> "renesas,pmdomain" string attribute of device nodes. It adds functions
> allowing the generic PM domains framework to use names for domain
> identification in various situations and reworks the ARM/shmobile power domains
> support code to used those functions instead of the "raw" ones that take
> domain pointers as their arguments. Finally, it defines a platform bus type
> notifier that will add devices whose DT nodes contain the "renesas,pmdomain"
> attribute to the power domains indicated by it (the value of that attribute
> should be the name of the PM domain to add the device to after it's been
> registered). All of this should allow platform devices to be added to
> appropriate power domains automatically based on the information read from
> a DT.
>
> The patches are on top of the current linux-next tree.
>
> I've tested the patches that could be tested on the Mackerel board, except
> for the last one (I'm still working on testing it).
Well, no comments, no objections. Good!
I've just tested [14/14] too and it works as expected.
Thanks,
Rafael
next prev parent reply other threads:[~2012-07-21 17:11 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-03 21:02 [RFD] PM: Device tree representation of power domains Rafael J. Wysocki
2012-07-04 11:56 ` Mark Brown
2012-07-05 20:17 ` Rafael J. Wysocki
2012-07-16 21:15 ` [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains) Rafael J. Wysocki
2012-07-16 21:17 ` [RFC][PATCH 1/14] PM / Domains: Make it possible to use domain names when adding devices Rafael J. Wysocki
2012-07-16 21:18 ` [RFC][PATCH 2/14] ARM: shmobile: Use names of power domains for adding devices to them Rafael J. Wysocki
2012-07-16 21:19 ` [RFC][PATCH 3/14] ARM: shmobile: Drop r8a7779_add_device_to_domain() Rafael J. Wysocki
2012-07-16 21:20 ` [RFC][PATCH 4/14] PM / Domains: Make it possible to use names when adding subdomains Rafael J. Wysocki
2012-07-16 21:21 ` [RFC][PATCH 5/14] ARM: shmobile: Use domain names when adding subdomains to power domains Rafael J. Wysocki
2012-07-16 21:23 ` [RFC][PATCH 6/14] RM: shmobile: Add routine for automatic PM domains initialization Rafael J. Wysocki
2012-07-16 21:24 ` [RFC][PATCH 7/14] ARM: shmobile: Remove dead sh7372 power management code Rafael J. Wysocki
2012-07-16 21:25 ` [RFC][PATCH 8/14] PM / Domains: Add power-on function using names to identify domains Rafael J. Wysocki
2012-07-16 21:26 ` [RFC][PATCH 9/14] ARM: shmobile: Move sh7372's PM domain objects to a table Rafael J. Wysocki
2012-07-16 21:27 ` [RFC][PATCH 10/14] ARM: shmobile: Move r8a7740's " Rafael J. Wysocki
2012-07-16 21:28 ` [RFC][PATCH 11/14] ARM: shmobile: Move r8a7779's " Rafael J. Wysocki
2012-07-16 21:29 ` [RFC][PATCH 12/14] ARM: shmobile: Make rmobile_init_pm_domain() static Rafael J. Wysocki
2012-07-16 21:30 ` [RFC][PATCH 13/14] PM / Domains: Introduce pm_genpd_present() Rafael J. Wysocki
2012-07-16 21:32 ` [RFC][PATCH 14/14] ARM: shmobile: Add support for storing PM domain information in DTs Rafael J. Wysocki
2012-07-21 17:17 ` Rafael J. Wysocki [this message]
2012-07-24 15:20 ` [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device tree representation of power domains) Arnd Bergmann
2012-07-24 19:34 ` Rafael J. Wysocki
2012-07-24 19:56 ` Arnd Bergmann
2012-07-24 20:37 ` Rafael J. Wysocki
2012-07-25 9:29 ` Rafael J. Wysocki
2012-07-25 13:00 ` Arnd Bergmann
2012-07-25 22:32 ` Rafael J. Wysocki
2012-07-26 0:38 ` Kevin Hilman
2012-07-26 20:55 ` Rafael J. Wysocki
2012-07-26 21:09 ` Mark Brown
2012-07-26 21:34 ` Rafael J. Wysocki
2012-07-26 21:45 ` Kevin Hilman
2012-07-26 21:55 ` Mark Brown
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=201207211917.12519.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=arnd@arndb.de \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=grant.likely@secretlab.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=mjg59@srcf.ucam.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).