From: khilman@deeprootsystems.com (Kevin Hilman)
To: linux-arm-kernel@lists.infradead.org
Subject: [linux-pm] [PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata
Date: Tue, 03 Aug 2010 09:16:00 -0700 [thread overview]
Message-ID: <87k4o7r7sv.fsf@deeprootsystems.com> (raw)
In-Reply-To: <AANLkTikHUcgBcTmv+=NrYMwgn-UC_Q0Vv3ytfuJbkyRB@mail.gmail.com> (Magnus Damm's message of "Mon, 26 Jul 2010 10:51:44 +0900")
Magnus Damm <magnus.damm@gmail.com> writes:
> On Sun, Jul 25, 2010 at 5:24 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> "Magnus Damm" <magnus.damm@gmail.com> wrote:
>>>On Tue, Oct 27, 2009 at 8:13 AM, Kevin Hilman
>>><khilman@deeprootsystems.com> wrote:
>>>> Eric Miao <eric.y.miao@gmail.com> writes:
>>>>> On Thu, Sep 24, 2009 at 7:28 AM, Kevin Hilman
>>>>> <khilman@deeprootsystems.com> wrote:
>>>>>> Mikael Pettersson wrote:
>>>>>>> Eric Miao writes:
>>>>>>> ?> On Wed, Sep 23, 2009 at 9:50 AM, Kevin Hilman
>>>>>>> ?> <khilman@deeprootsystems.com> wrote:
>>>>>>> ?> > On ARM platforms, power management can be very platform specific.
>>>>>>> ?> > This patch allows ARM subarches to extend the platform_device
>>>>>>> ?> > pdev_archdata for each subarch by creating a new struct pdev_machdata
>>>>>>> ?> > and allowing each subarch to customize it as needed.
>
>>>Do you remember what happened with this patch?
>>
>> I don't have all the details in front of me because I'm on my phone,
>> but I advised against pdev_archdata because it is
>> multiplatform-unfriendly.
>
> Ok, I did not expect that. =) But after thinking a bit it does make
> sense. I wonder what my options are. I'm not so fond of the idea to
> wrap the platform devices - that's not more multi-platform friendly,
> is it?
[sorry for the lag, been on vacation]
Wrapping is more multi-platform friendly because only platform-specific
code accesses the wrapped code. It's also logically consistent as
a struct device is contained by a platform_device which is then
contained by an omap_device (in our case.) Only OMAP-specific code
ever knows about or touches that layer.
> How about using devres and platform bus notifiers?
That seems fine too, and probably better if the amount of data/code you need
is small. In the OMAP case, it's rather complicated so it's cleaner
IMHO to keep it in a separate omap_device layer and struct.
> For a Runtime PM prototype using devres (instead of pdev_archdata or
> wrapping) look here:
> https://patchwork.kernel.org/patch/113605/
>
> To make it work with modules I propose adding a driver bind event:
> https://patchwork.kernel.org/patch/113865/
>
> Looks pretty multi-platform friendly to me. Any suggestions?
Your patches look multi-platform friendly, but there are still some
outstanding issues with making runtime PM support multi-platform
friendly that are not direclty related to the above patches.
1) weak symbols
We need to change the overriding of weak symbols into some form of
register/unregister so multiple platforms in the same kernel could work.
That's the easy one.
2) custom vs. platform bus.
The other issue under discussion between Grant & myself[1] has been the
use of a custom bus instead of the platform bus. Following your lead,
(and preferring that option) I continued to use the platform_bus since
I only need to override a few of the dev_pm_ops functions.
However, Grant is not happy about overriding the platform_bus. He would
rather see each platform create a custom bus with it's own PM methods.
In this thread[1], I did a quick and dirty proof of concept to show that
it is possible, but quite frankly, I still much prefer continuing to use
the platform_bus since it is mostly identical.
After I catch up on the rest of my mail, I will get back to this topic.
Kevin
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/018925.html
next prev parent reply other threads:[~2010-08-03 16:16 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-23 1:50 [PATCH/RFC] Runtime PM: ARM: subarch-specific extensions of pdev_archdata Kevin Hilman
2009-09-23 1:50 ` Kevin Hilman
2009-09-23 3:54 ` Ben Dooks
2009-09-23 23:26 ` Kevin Hilman
2009-09-23 23:26 ` Kevin Hilman
2009-09-23 3:54 ` Ben Dooks
2009-09-23 4:53 ` Eric Miao
2009-09-23 4:53 ` Eric Miao
2009-09-23 10:23 ` Mikael Pettersson
2009-09-23 23:28 ` Kevin Hilman
2009-09-23 23:28 ` Kevin Hilman
2009-09-23 23:30 ` Eric Miao
2009-09-23 23:30 ` Eric Miao
2009-09-23 23:36 ` Kevin Hilman
2009-09-23 23:36 ` Kevin Hilman
2009-10-26 23:13 ` Kevin Hilman
2009-10-26 23:13 ` Kevin Hilman
2010-07-22 8:06 ` Magnus Damm
2010-07-22 8:06 ` [linux-pm] " Magnus Damm
2010-07-24 20:24 ` Grant Likely
2010-07-26 1:51 ` Magnus Damm
2010-07-26 1:51 ` [linux-pm] " Magnus Damm
2010-08-03 16:16 ` Kevin Hilman [this message]
2010-08-04 3:56 ` Magnus Damm
2010-08-04 23:10 ` Grant Likely
2010-08-05 3:07 ` Magnus Damm
2010-08-05 15:12 ` Kevin Hilman
2010-08-05 15:12 ` Kevin Hilman
2010-08-05 3:07 ` Magnus Damm
2010-08-04 23:10 ` Grant Likely
2010-08-04 3:56 ` Magnus Damm
2010-08-04 22:54 ` [linux-pm] " Grant Likely
2010-08-05 15:19 ` Kevin Hilman
2010-08-05 15:19 ` Kevin Hilman
2010-08-04 22:54 ` Grant Likely
2010-08-03 16:16 ` Kevin Hilman
2010-08-04 22:41 ` Grant Likely
2010-08-04 22:41 ` [linux-pm] " Grant Likely
2010-08-05 2:53 ` Magnus Damm
2010-08-05 2:53 ` Magnus Damm
2010-07-24 20:24 ` Grant Likely
2009-09-23 10:23 ` Mikael Pettersson
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=87k4o7r7sv.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.