From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>,
robert.marklund@stericsson.com, netdev@vger.kernel.org,
Sascha Hauer <kernel@pengutronix.de>
Subject: Re: Regulator support for smsc911x
Date: Wed, 8 Feb 2012 11:35:25 +0000 [thread overview]
Message-ID: <20120208113524.GE3120@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20120208083141.GM3852@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]
On Wed, Feb 08, 2012 at 09:31:41AM +0100, Sascha Hauer wrote:
> There is also option e), something I've been thinking about for a while.
> Implement a list of resources which can be attached to a device. By
> resources I mean regulators, clocks and pinmux for example. A device
> would then just call a make_me_work(state) function which iterates over
> this list and enables/disables all resources as necessary. This way we
> could attach everything we need to a device without cluttering the
> driver code like we do today.
That gets tricky where you have resources that are only needed some of
the time (for example, many of the CODECs I work with can happily have
some of the supplies disabled while they are operational - some systems
may never enable certain supplies) and there are fun interactions with
things like runtime PM and system suspend to consider (wake on LAN would
be one for an ethernet driver). Once you start hitting low power states
and pursuing optimisations there you start to find that the driver needs
to make decisions about what's going on that can't easily be completely
removed from it.
I have been meaning to do something like that which devices can
request if they happen to have trivial or common usage patterns (of
which there's a few) so all they need to do is set flags but I'm really
not sure it's a good idea by default. Gets fiddly with the device core
though.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
prev parent reply other threads:[~2012-02-08 11:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-03 1:02 Regulator support for smsc911x Fabio Estevam
2012-02-03 3:17 ` Fabio Estevam
2012-02-03 7:44 ` Sascha Hauer
2012-02-03 11:11 ` Mark Brown
2012-02-07 19:25 ` Fabio Estevam
2012-02-07 19:39 ` Mark Brown
2012-02-07 20:29 ` Fabio Estevam
2012-02-08 8:31 ` Sascha Hauer
2012-02-08 11:35 ` Mark Brown [this message]
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=20120208113524.GE3120@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=festevam@gmail.com \
--cc=kernel@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=robert.marklund@stericsson.com \
--cc=s.hauer@pengutronix.de \
/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).