From: khilman@deeprootsystems•com (Kevin Hilman)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Date: Wed, 31 Oct 2012 21:10:09 +0100 [thread overview]
Message-ID: <87obji8kta.fsf@deeprootsystems.com> (raw)
In-Reply-To: <CACRpkdapQJY0aoam741O0fb8EeM9BLk_Psq5TaPG84J7wEvCLw@mail.gmail.com> (Linus Walleij's message of "Tue, 30 Oct 2012 15:02:23 +0100")
Linus Walleij <linus.walleij@linaro•org> writes:
> On Tue, Oct 30, 2012 at 12:34 PM, Mark Brown
> <broonie@opensource•wolfsonmicro.com> wrote:
>> On Sun, Oct 28, 2012 at 09:12:52PM +0100, Linus Walleij wrote:
>
>>> Moving this handling to bus code or anywhere else
>>> invariably implies that resource acquisition/release order
>>> does not matter, and my point is that it does.
>>
>> Doing this in the buses is definitely wrong, as you say it's not bus
>> specific. I do however think we can usefully do this stuff in a SoC
>> specific place like a power domain, keeping the SoC integration code
>> together and out of the drivers. IME the SoCs where you need to do
>> different things for different IPs shoudl mostly still get some reuse
>> out of such an approach.
>
> Talking to Kevin Hilman today he was also stressing that
> power domains is a good thing for handling resources, especially
> when replacing prior hacks in the custom clk code. However
> he pointed specifically to clocks and voltages, which may
> be true.
>
> What worries me is when knowledge of the hardware which
> is traditionally a concern for the device driver start to
> bubble up to the power domain (or better renamed resource
> domain if use like this, as Felipe points out).
>
> 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:
> pinctrl_set_state();
> clk_disable();
> // Always-on domain
> case DEV_BAZ:
> pinctrl_set_state();
> clk_disable();
> power_domain_off();
> case ...
>
> Mutate the above with silicon errata, specific tweaks etc that
> Felipe was mentioning.
like this, as well as a bunch more. This is why we have a generic
description of IP blocks (omap_hwmod) which abstracts all of these
differences and keeps the PM domain layer rather simple.
I agree with Mark. Either you have to take care of this with
conditional code in the driver, and the drivers become bloated with a
mess of SoC integration details, or you hide it away in SoC-specific
code that can handle this, and keep the drivers portable.
Now that we have PM domains (PM domains didn't exist when we created
omap_device/omap_hwmod), I suspect the cleanest way to do this is to
create separate PM domains for each "class" of devices that have
different set of behavior.
> What is happening is that device-specific behaviour which
> traditionally handled in the driver is now inside the
> power/resource domain.
>
> piece of hardware, this would be the right thing to do,
> and I think the in-kernel examples are all "simple",
> e.g. arch/arm/mach-omap2/powerdomain* is all about
> power domains and nothing else,
FYI... that code isn't the same as PM domain. That code is for the
*hardware* powerdomains, not the software concept of "PM domain." In
OMAP, PM domain is implmented at the omap_device level. And omap_device
is the abstraction of an IP block that knows about all the PM related
register settings, clocks, HW powerdomain, voltage domain, PM related
pin-muxing etc. etc. All of these things are abstracted in an
omap_device, so that the PM domain implementation for OMAP looks rather
simple (c.f. omap_device_pm_domain in arch/arm/plat-omap/omap_device.c.)
Note that the callbacks just call omap_device_enable(),
omap_device_disable() and all the HW ugliness, SoC-specific integration
mess is hidden away.
[...]
> I think the lesser of two evils is the distributed approach,
> and then I'm talking about pinctrl only, disregarding the
> fact that clocks and power domains are basically subject to
> the same kind of argument. I still buy into the concept of
> using power domains for exactly power domains only.
> Arguably this is an elegance opinion...
The pinctrl examples I've seen mentioned so far are all PM related
(sleep, idle, wakeup, etc.) so to me I think they still belong in
PM domains (and that's how we handle the PM related pins in OMAP.)
> 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.
Yes, I agree that this means more code/data in arch/arm/mach-*, but
IMO, that's really where it belongs. It really is SoC integration
details, and driver should really not know about it.
Kevin
next prev parent reply other threads:[~2012-10-31 20:10 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
2012-10-23 17:51 ` Felipe Balbi
2012-10-23 9:18 ` Benoit Cousson
2012-10-23 20:02 ` Dmitry Torokhov
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
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
2012-10-30 11:34 ` Mark Brown
2012-10-30 14:02 ` Linus Walleij
2012-10-30 14:37 ` Mark Brown
2012-10-31 20:10 ` Kevin Hilman [this message]
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
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
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=87obji8kta.fsf@deeprootsystems.com \
--to=khilman@deeprootsystems$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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