Message-ID: <87obji8kta.fsf@deeprootsystems.com>
Date:	Wed, 31 Oct 2012 21:10:09 +0100
From:	Kevin Hilman <khilman@...prootsystems.com>
To:	Linus Walleij <linus.walleij@...aro.org>
Cc:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Felipe Balbi <balbi@...com>, Benoit Cousson <b-cousson@...com>,
	Sourav Poddar <sourav.poddar@...com>, tony@...mide.com,
	linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org,
	linux-arm-kernel@...ts.infradead.org, linux-input@...r.kernel.org
Subject: Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support

Linus Walleij <linus.walleij@...aro.org> writes:

> On Tue, Oct 30, 2012 at 12:34 PM, Mark Brown
> <broonie@...nsource.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists