From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Shuah Khan <shuahkhan@gmail.com>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [TECH TOPIC] PM dependencies
Date: Mon, 19 May 2014 09:30:33 +0200 [thread overview]
Message-ID: <CAMuHMdWUh3daPm6PkLAmjfiy=sPC5xAA-H8NSmO7HUNE5cFgEA@mail.gmail.com> (raw)
In-Reply-To: <CAKocOONFuv5paQ8S8R8CTwa=pPu6034+qH7dJ_ohc_Y8xoFxPA@mail.gmail.com>
On Mon, May 19, 2014 at 3:00 AM, Shuah Khan <shuahkhan@gmail.com> wrote:
> On Thu, May 15, 2014 at 5:43 PM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
>> On Tuesday 13 May 2014 08:26:09 Shuah Khan wrote:
>>>
>>> Can we use pm domains concept to solve the problem? As it exists today, it
>>> probably can't support loosely associated devices, however, could it be
>>> extended to support handling device groups that don't necessarily share
>>> power source and/or clock.
>>
>> If I understand them properly, power domains model groups of devices that
>> share common power handling. I'm not sure how they could be used to model PM
>> dependencies between devices. Feel free to prove me wrong though :-)
>>
>>> I started looking at this as a way to solve media device PM issues,
>>> however I haven't had a chance to experiment with this idea.
>
> Right now, PM domains currently support grouping of devices that share
> power source. What if we extended PM domains to support a concept of
Physical power domain...
> logical grouping of devices that have PM dependencies with a way to
> specify dependency ordering?
>
> For example, a media usb device example:
> The main driver could create a logical power domain and rest of the
> drivers add their devices to the same domain specifying their
> dependencies. logical power domain pm handlers can handle ordering. In
... and logical power domain...
> some cases, there is a need to save and restore state of tuner i2c and
> the existing save_state and restore_state could be used to within the
> scope of this logical domain.
>
> I think PM domains can definitely be used for media device case, but I
> am not sure about the specific case you are looking at where there is
> a clearly identified master driver/device.
Sure, it can be done.
> These are at the moment ideas and I need to do some work to test these
> theories. :)
.. and we also have clock power domains (cfr. pm_clk_notify()).
Now we do have hardware that would benefit from all three of the above.
AFAIK a device can be a member of only one power domain, through
the struct device.pm_domain pointer. Can/should this be extended,
cfr. the RPM_GET_CALLBACK() stack for Runtime PM (but we do want
to call into more than one of them).
I'm still too pm_domain-illiterate to say much more about this though...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
next prev parent reply other threads:[~2014-05-19 7:30 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-12 17:43 Laurent Pinchart
2014-05-12 17:51 ` Shuah Khan
2014-05-18 15:42 ` Mauro Carvalho Chehab
2014-05-12 18:09 ` Tomasz Figa
2014-05-12 20:14 ` Mark Brown
2014-05-12 20:27 ` Laurent Pinchart
2014-05-12 20:31 ` Mark Brown
2014-05-12 21:16 ` Tomasz Figa
2014-05-12 22:07 ` Mark Brown
2014-05-13 7:43 ` Daniel Vetter
2014-05-13 10:31 ` Laurent Pinchart
2014-05-13 14:26 ` Shuah Khan
2014-05-15 23:43 ` Laurent Pinchart
2014-05-19 1:00 ` Shuah Khan
2014-05-19 7:30 ` Geert Uytterhoeven [this message]
2014-05-13 22:27 ` Rafael J. Wysocki
2014-05-13 22:34 ` Rafael J. Wysocki
2014-05-14 12:59 ` Rafael J. Wysocki
2014-05-15 23:34 ` Laurent Pinchart
2014-05-20 16:57 ` Kevin Hilman
2014-05-20 18:51 ` Mark Brown
2014-05-21 9:26 ` Ulf Hansson
2014-05-21 11:16 ` Geert Uytterhoeven
2014-05-22 0:19 ` Rafael J. Wysocki
2014-05-22 10:14 ` Mark Brown
2014-05-23 23:15 ` Rafael J. Wysocki
2014-05-24 10:53 ` Mark Brown
2014-05-25 12:56 ` Rafael J. Wysocki
2014-05-22 17:35 ` Kevin Hilman
2014-05-23 23:26 ` Rafael J. Wysocki
2014-05-23 0:18 ` Laurent Pinchart
2014-05-23 0:39 ` Kevin Hilman
2014-05-23 8:32 ` Linus Walleij
2014-05-23 15:26 ` Kevin Hilman
2014-05-24 0:13 ` Rafael J. Wysocki
2014-05-24 0:08 ` Rafael J. Wysocki
2014-05-26 14:30 ` Peter De Schrijver
2014-05-23 8:25 ` Linus Walleij
2014-05-23 9:10 ` Ulf Hansson
2014-05-24 0:00 ` Rafael J. Wysocki
2014-05-15 22:45 ` Laurent Pinchart
2014-05-14 21:08 ` Kevin Hilman
2014-05-14 12:11 ` Rafael J. Wysocki
2014-05-14 11:57 ` Mark Brown
2014-05-14 12:32 ` Rafael J. Wysocki
2014-05-14 15:14 ` Mark Brown
2014-05-14 15:26 ` Laurent Pinchart
2014-05-14 15:40 ` 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='CAMuHMdWUh3daPm6PkLAmjfiy=sPC5xAA-H8NSmO7HUNE5cFgEA@mail.gmail.com' \
--to=geert@linux-m68k.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=shuahkhan@gmail.com \
/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