linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] PM: Provide an always on power domain governor
Date: Tue, 6 Dec 2011 14:33:19 +0000	[thread overview]
Message-ID: <20111206143319.GF17731@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <008101ccb40f$4385c0d0$ca914270$%szyprowski@samsung.com>

On Tue, Dec 06, 2011 at 01:04:53PM +0100, Marek Szyprowski wrote:

Please fix your mailer to word wrap at less than 80 columns, I've
reflowed your text for legibility.

> What about similar patches for S5PV210/S5PC110 series and Exynos4?

I don't really have access to these systems (well, I have a Nexus S I
can use but that doesn't boot mainline) and I don't have datasheets so
it's hard for me to actively work on them myself.

> gen_pd based power domain code for Exynos4 have been rejected in favor
> of custom platform-device based power domain drivers. It would be much

Oh, that's very surprising to me - looking at the code it appeared that
it just predated gen_pd, I didn't see anything in there that suggested
an active decision to avoid using it.  What was then thinking there?  Is
this something we can fix by enhancing gen_pd?

> easier to have only one type of the drivers across different Samsung
> SoCs. This will also help to hide some differences between the series
> from the device drivers (clock gating, power management). 

When I looked at the code I'd expected the other SoCs to also transition
over to gen_pd and then start pulling things out from there.

Looking at what you can do on s3c64xx the power domain code looked very
small once you use the gen_pd stuff (which is very nice to use, it
really makes the whole thing very easy) so I'm not sure how much win it
is immediately.  How much win it is long term will depend on where
things get implemented - a lot of the stuff I could tink of doing seemed
like it might be more of a fit for the opp or PM QoS stuff than for the
power domains, with the power domains staying pretty thin and just
providing inputs but perhaps that's not a sensible approach.

The main trick is going to be actually putting the devices into the
power domains which is entertaining as currently every board directly
registers platform devices so it's hard for core code to work out what
Linux knows about.

In terms of the drivers I wasn't expecting to see much impact as the
power domain and runtime PM APIs provide a pretty good abstraction
already - the actual implementation of things is totally transparent to
them.  The only device actively able to use the power domains on the
S3C6410 is the framebuffer and the driver there just worked with the
existing runtime PM code.

  reply	other threads:[~2011-12-06 14:33 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-01 18:48 [PATCH 1/3] PM: Provide an always on power domain governor Mark Brown
2011-12-01 18:48 ` [PATCH 2/3] ARM: mach-shmobile: Use common " Mark Brown
2011-12-01 20:37   ` Rafael J. Wysocki
2011-12-02  0:33     ` Mark Brown
2011-12-02 22:36       ` Rafael J. Wysocki
2011-12-03 11:03         ` Mark Brown
2011-12-03 22:31           ` Rafael J. Wysocki
2011-12-04  1:22             ` Mark Brown
2011-12-04 19:53               ` Rafael J. Wysocki
2011-12-04  1:24           ` [PATCH v2] " Mark Brown
2011-12-01 18:48 ` [PATCH 3/3] ARM: S3C64XX: Implement basic power domain support Mark Brown
2011-12-02  0:35   ` Kyungmin Park
2011-12-02  0:56     ` Mark Brown
2011-12-02 18:25       ` Tomasz Figa
2011-12-02 18:57         ` Mark Brown
2011-12-02 19:06           ` Tomasz Figa
2011-12-02 20:10   ` Sylwester Nawrocki
2011-12-02 21:07     ` Mark Brown
2011-12-07 21:44       ` Rafael J. Wysocki
2011-12-08  1:09         ` Mark Brown
2011-12-08 22:15           ` Rafael J. Wysocki
2011-12-08 22:22             ` Rafael J. Wysocki
2011-12-04 20:56 ` [PATCH 1/3] PM: Provide an always on power domain governor Rafael J. Wysocki
2011-12-04 23:10   ` Mark Brown
2011-12-05  0:15     ` Rafael J. Wysocki
2011-12-05  0:15       ` Mark Brown
2011-12-06 10:20         ` Kukjin Kim
2011-12-06 12:04           ` Marek Szyprowski
2011-12-06 14:33             ` Mark Brown [this message]
2011-12-06 21:39           ` Rafael J. Wysocki
2011-12-07 12:35             ` Mark Brown
2011-12-07 21:28               ` Rafael J. Wysocki
2011-12-08  0: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=20111206143319.GF17731@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.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).