Re: [PATCH] [RFC] pinctrl: add a driver for Energy Micro's efm32 SoCs

[Linus Walleij]

On Mon, Dec 12, 2011 at 3:37 PM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote:
> On Sat, Dec 10, 2011 at 01:18:43AM +0100, Linus Walleij wrote:
>> On Fri, Dec 9, 2011 at 12:08 PM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> wrote:
>>
>> > Drivers should not be bothered with pin muxing *at all*.
>>
>> Not if they are simple. Like - set them up once and for all and
>> then forget about it.
>>
>> It gets problematic when we get to sleep states and the system
>> need to reconfigure all pins on say idle or deep sleep.
>
> If you need to reconfigure your pins in deep sleep and you control
> the pins in the driver this seems to suggest that your device won't
> suspend properly if the driver is not loaded?

In our case (ux500) it's more like all pins have a defined nice
state for active, sleep and idle. (Pull-ups, downs, wakeups etc
set in a certain way.)

Then there are some real agressive stuff PM people start to do.
Some of them require you to shut down things in a certain
sequence, like this device has to have its pins turned off first,
the clock released, then regulator, etc. And others do it in the
reverse order, or any order.

If all your hardware was engineered the
same way with this in mind it could probably be done
centrally, like the nice stuff Magnus Damm has for managing
clocks in drivers/base/power/clock_ops.c for all SHmobile
clocks. Would be real nice if it worked for us, sadly not all
hardware is designed in such a consistent way.

For our hardware it's better to spread it out across the
drivers and then consolidate once we have the entire
picture, I'm afraid. For others it will be different, maybe
your systems will never need it and you can keep all in
central places.

Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/