All of lore.kernel.org
 help / color / mirror / Atom feed
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: Thu, 05 Aug 2010 08:12:04 -0700	[thread overview]
Message-ID: <8739ut2iwr.fsf@deeprootsystems.com> (raw)
In-Reply-To: <AANLkTimUeFf_Z5pi3x7PWNb0YpooxPb3aN1cmtv1XjQx@mail.gmail.com> (Magnus Damm's message of "Thu, 5 Aug 2010 12:07:53 +0900")

Magnus Damm <magnus.damm@gmail.com> writes:

> On Thu, Aug 5, 2010 at 8:10 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On Tue, Aug 3, 2010 at 9:56 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
>>> On Wed, Aug 4, 2010 at 1:16 AM, Kevin Hilman
>>> <khilman@deeprootsystems.com> wrote:
>>>> 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.
>>>>
>>>> [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/018925.html
>>>
>>> Thanks for the pointer. I've been thinking of using a custom bus as
>>> well, but from my point of view it's always looked like a lot of
>>> coding without any clear benefit. I understand the idea of wanting to
>>> use a single binary on a wide range of systems, and solving that seems
>>> like a good plan.
>>>
>>> I'm not sure if a custom bus is the best idea. I wouldn't mind being
>>> able to create platform bus instances though.
>>
>> The only problem with multiple platform_bus instances would be that
>> drivers intended to work on both would need to be registered twice;
>> once on the regular platform bus, and once on the custom bus. ?All the
>> rest of the code would be shared, but it probably still doesn't
>> reflect the model that you're shooting for.
>
> Do they really have to be registered twice? With the current driver
> model yes, but perhaps it's possible to adjust the platform bus to
> allow device<->driver matching across buses somehow. I would prefer to
> register drivers only once.

I would too.  My primary objection to the custom bus approach is because
I don't want drivers to have to care what bus (or SoC) they are
connected to.

Kevin

  parent reply	other threads:[~2010-08-05 15:12 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 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
2010-07-22  8:06           ` [linux-pm] " Magnus Damm
2010-07-24 20:24             ` Grant Likely
2010-07-24 20:24             ` [linux-pm] " Grant Likely
2010-07-26  1:51               ` Magnus Damm
2010-08-03 16:16                 ` Kevin Hilman
2010-08-03 16:16                 ` [linux-pm] " Kevin Hilman
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 [this message]
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                     ` [linux-pm] " Kevin Hilman
2010-08-04 22:54                   ` Grant Likely
2010-08-04 22:41                 ` [linux-pm] " Grant Likely
2010-08-05  2:53                   ` Magnus Damm
2010-08-05  2:53                   ` [linux-pm] " Magnus Damm
2010-08-04 22:41                 ` Grant Likely
2010-07-26  1:51               ` Magnus Damm
2010-07-22  8:06           ` Magnus Damm
2009-10-26 23:13         ` Kevin Hilman

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=8739ut2iwr.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.