[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTint6DGgosVkjK-sveyA9SL9WVS4Mg@mail.gmail.com>
Date: Wed, 20 Apr 2011 22:26:14 +0800
From: Haojian Zhuang <haojian.zhuang@...il.com>
To: Kyungmin Park <kmpark@...radead.org>
Cc: Alan Cox <alan@...rguk.ukuu.org.uk>,
Ben Nizette <bn@...sdigital.com>,
Linus Walleij <linus.walleij@...ricsson.com>,
Linus Walleij <linus.walleij@...aro.org>,
linux-kernel@...r.kernel.org,
Grant Likely <grant.likely@...retlab.ca>,
Lee Jones <lee.jones@...aro.org>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib
On Tue, Apr 19, 2011 at 4:51 PM, Kyungmin Park <kmpark@...radead.org> wrote:
>>
>> Leaving aside the current input/output and on/off bits I would go for
>> being able to do
>>
>> gpio_get_property(gpio, GPIO_BIAS, GPIO_BIAS_WHATEVER);
>> gpio_set_property(gpio, GPIO_BIAS, GPIO_BIAS_WHATEVER_ELSE);
>
> One more consideration, not mentioned previous time, is that pin
> configuration for power down mode.
> Samsung SoCs has retention GPIO configurations at sleep (suspend)
> mode. and restore it at resume time.
> it's need to reduce power and proper operation after suspend.
>
I have a little confusion. In ARM SoC, a lot of pins are used as
multi-functions.
Before suspend, it may be configured as some function that isn't GPIO.
Is it a goal
that avoid declaring gpio_request() for suspend and updating the setting of pin?
Linus,
Are these two patches are post in mailing list? I can't find your
second patch in this
patch series?
--
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