[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAN1soZwEj2SYa9eqH-Nyw0wvVF8kk7tn_gLu+BPDS3ZT1Has+Q@mail.gmail.com>
Date: Tue, 20 Dec 2011 10:22:26 +0800
From: Haojian Zhuang <haojian.zhuang@...il.com>
To: Stephen Warren <swarren@...dia.com>
Cc: Linus Walleij <linus.walleij@...ricsson.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Grant Likely <grant.likely@...retlab.ca>,
Barry Song <21cnbao@...il.com>,
Shawn Guo <shawn.guo@...escale.com>,
Thomas Abraham <thomas.abraham@...aro.org>,
Dong Aisheng <dong.aisheng@...aro.org>,
Rajendra Nayak <rajendra.nayak@...aro.org>,
Haojian Zhuang <haojian.zhuang@...vell.com>,
Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH v2] pinctrl: add support for group and pinmux states
On Tue, Dec 20, 2011 at 8:24 AM, Stephen Warren <swarren@...dia.com> wrote:
> Linus Walleij wrote at Sunday, December 18, 2011 4:07 PM:
>> This makes it possible for pin groups and pin muxes to go into
>> different states, which is especially useful for power management,
>> both runtime and across suspend/resume.
>
>> diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
>
>> +Pin group states
>> +================
>> +
>> +To simplify handling of specific group states, such as when a group of
>> +pins need to be deactivated or put in a specific sleep state, the pin controller
>> +may implement a .pin_group_set_state() callback. This will for example be
>> +called automatically to set a certain pin group in active state when the groups
>> +are selected for use in a certain pin multiplexing configuration (see below).
>> +This is a good opportunity to set up any default pin configuration (see below)
>> +for the pins in a group.
>
> I don't think it's possible for a pinctrl driver to implement such a
> callback; the appropriate state for a pin may well be board-specific,
> and the pinctrl driver itself can't possibly know what that state is.
>
> For example, for some random pin that a board happens to be using as a
> GPIO - how does the pinctrl driver know whether that GPIO actually does
> something while in suspend; if the GPIO isn't used, the SoC can probably
> just turn off all drivers and pull-up/downs on the pin, but if the GPIO
> is used to control some aspect of a PMIC, it probably needs to be in a
> specific state during suspend. This kind of thing is entirely board-
> specific.
>
> Similarly, the sequencing of reprogramming of the various pins when
> entering/leaving suspend is most likely board specific, e.g. there may
> be a need to assert a "speaker mute" GPIO before de-asserting a GPIO
> that enables power to speaker amplifiers etc.
>
Do we really need to configure low power mode in device driver? In most time,
user will set and tune the low power mode of pins. If the low power setting
could be configured via sysfs, it could save a lot of time to rebuild kernel.
Especially GPIO pins are board specific. I think that configure all low power
setting in board specific code is more reasonable.
Thanks
Haojian
--
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