From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Felipe Balbi <balbi@ti.com>, Benoit Cousson <b-cousson@ti.com>,
Sourav Poddar <sourav.poddar@ti.com>,
tony@atomide.com, linux-omap@vger.kernel.org,
linux-kernel@vger.kernel.org,
devicetree-discuss@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org,
linux-input@vger.kernel.org, Kevin Hilman <khilman@ti.com>
Subject: Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Date: Tue, 30 Oct 2012 14:37:16 +0000 [thread overview]
Message-ID: <20121030143715.GP4511@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CACRpkdapQJY0aoam741O0fb8EeM9BLk_Psq5TaPG84J7wEvCLw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2127 bytes --]
On Tue, Oct 30, 2012 at 03:02:23PM +0100, Linus Walleij wrote:
> I worry that we will end up with power/resource domain
> code that start to look like this:
> suspend()
> switch (device.id) {
> case DEV_FOO:
> clk_disable();
> pinctrl_set_state();
> power_domain_off();
> case DEV_BAR:
Well, if we're doing that then either we'd presumably either get the
same result if we open code it in the drivers or whoever wrote the
resource domain code for the platform should be creating multiple
domains.
> Another effect is that moving all resource handling to
> power domains is that if we do that for a widely shared
> device driver like the PL011 that mandates that power
> domains need to be implemented for U300, Ux500,
> Nomadik, SPEAr 13xx, 3xx, 6xx, Versatile, Versatile
> Express, Integrator (AP & CP) and BCM2835. Probably
> more.
> Basically power (resource) domains have the side-effect
> of in this light not doing one thing (power domains) but
> instead imposing all-or-nothing imperialistic characteristics.
For me that's happening anyway with explicit control, just in different
places - for example the Freescale guys have had issues with IPs shared
between m68k and i.MX requiring that stub clocks be provided on m68k for
things that are always on there and similarly with all the platforms
that get affected when some widely used chip acquires regulator support.
It seems easier to organise things if the platform has responsibility
for coordinating this stuff than if we add stuff in the drivers.
> I worry that the per-SoC power domain implementation
> which will live in arch/arm/mach-* as of today will become
> the new board file problem, overburdening the arch/* tree.
> Maybe I'm mistaken as to the size of these things,
> but just doing ls arch/arm/mach-omap2/powerdomain*
> makes me start worrying.
One thing to remember is that OMAP has some of the most featureful
hardware out there in terms of software control for power so it's
unlikely to ever get much more complex than that. IME most SoCs
are very much simpler than that and should be able to punt lots of
stuff to device tree data.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2012-10-30 14:37 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 13:13 [PATCHv2] Input: omap4-keypad: Add pinctrl support Sourav Poddar
2012-10-22 15:50 ` Dmitry Torokhov
2012-10-23 9:13 ` Linus Walleij
2012-10-23 9:35 ` Benoit Cousson
2012-10-23 10:04 ` Linus Walleij
2012-10-23 10:03 ` Felipe Balbi
2012-10-23 10:23 ` Thomas Petazzoni
2012-10-23 10:29 ` Linus Walleij
2012-10-23 10:29 ` Felipe Balbi
2012-10-23 10:45 ` Linus Walleij
2012-10-23 10:42 ` Felipe Balbi
2012-10-23 11:11 ` Thomas Petazzoni
2012-10-23 17:02 ` Mitch Bradley
2012-10-23 17:20 ` Felipe Balbi
2012-10-23 17:51 ` Mitch Bradley
[not found] ` <5086D91A.5080109-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>
2012-10-23 17:51 ` Felipe Balbi
[not found] ` <20121022155028.GA13791-WlK9ik9hQGAhIp7JRqBPierSzoNAToWh@public.gmane.org>
2012-10-23 9:18 ` Benoit Cousson
2012-10-23 20:02 ` Dmitry Torokhov
[not found] ` <20121023200249.GA2712-WlK9ik9hQGAhIp7JRqBPierSzoNAToWh@public.gmane.org>
2012-10-24 8:37 ` Felipe Balbi
2012-10-24 16:14 ` Dmitry Torokhov
2012-10-24 16:51 ` Linus Walleij
2012-10-24 17:28 ` Dmitry Torokhov
2012-10-24 18:58 ` Felipe Balbi
[not found] ` <20121024185818.GB772-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2012-10-25 20:59 ` Mark Brown
2012-10-26 6:20 ` Felipe Balbi
2012-10-26 16:03 ` Mark Brown
2012-10-29 19:49 ` Felipe Balbi
2012-10-30 11:24 ` Mark Brown
2012-10-30 11:49 ` Felipe Balbi
2012-10-30 14:07 ` Mark Brown
2012-10-30 14:16 ` Linus Walleij
2012-10-30 14:54 ` Mark Brown
2012-10-30 15:16 ` Felipe Balbi
2012-10-30 15:58 ` Mark Brown
2012-10-30 17:25 ` Felipe Balbi
2012-10-30 18:20 ` Dmitry Torokhov
2012-10-30 18:48 ` Felipe Balbi
2012-10-30 18:37 ` Mark Brown
2012-10-30 21:51 ` Linus Walleij
2012-10-30 22:57 ` Rafael J. Wysocki
2012-11-02 18:26 ` Mark Brown
2012-10-30 14:11 ` Linus Walleij
2012-10-28 20:12 ` Linus Walleij
[not found] ` <CACRpkdaiLXVeUg1quuw3XPTenbKOjn+aWbGQezpcyvzQCtCWow-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-10-30 11:34 ` Mark Brown
2012-10-30 14:02 ` Linus Walleij
2012-10-30 14:37 ` Mark Brown [this message]
2012-10-31 20:10 ` Kevin Hilman
[not found] ` <87obji8kta.fsf-1D3HCaltpLuhEniVeURVKkEOCMrvLtNR@public.gmane.org>
2012-11-01 8:54 ` Linus Walleij
2012-11-01 8:56 ` Fwd: " Linus Walleij
2012-11-01 11:42 ` Kevin Hilman
2012-11-01 13:22 ` Linus Walleij
2012-11-01 12:07 ` Mark Brown
2012-11-01 14:01 ` Linus Walleij
2012-11-01 14:19 ` Mark Brown
2012-11-11 12:32 ` Linus Walleij
2012-10-31 13:19 ` Jean-Christophe PLAGNIOL-VILLARD
[not found] ` <20121024161429.GA16350-WlK9ik9hQGAhIp7JRqBPierSzoNAToWh@public.gmane.org>
2012-10-24 16:52 ` Felipe Balbi
2012-10-24 17:13 ` Linus Walleij
2012-10-24 17:34 ` Dmitry Torokhov
2012-10-24 17:46 ` Benoit Cousson
2012-10-24 12:54 ` Linus Walleij
2012-10-24 16:18 ` Dmitry Torokhov
2012-10-24 16:57 ` Felipe Balbi
2012-10-24 17:18 ` Linus Walleij
2012-10-24 17:58 ` Dmitry Torokhov
2012-10-24 19:10 ` Felipe Balbi
[not found] ` <20121024191042.GC772-S8G//mZuvNWo5Im9Ml3/Zg@public.gmane.org>
2012-10-24 19:38 ` Dmitry Torokhov
2012-10-24 19:51 ` Felipe Balbi
2012-10-24 17:01 ` Linus Walleij
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=20121030143715.GP4511@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=b-cousson@ti.com \
--cc=balbi@ti.com \
--cc=devicetree-discuss@lists.ozlabs.org \
--cc=dmitry.torokhov@gmail.com \
--cc=khilman@ti.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=sourav.poddar@ti.com \
--cc=tony@atomide.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;
as well as URLs for NNTP newsgroup(s).