From: Igor Grinberg <grinberg@compulab.co.il>
To: Stephen Warren <swarren@nvidia.com>
Cc: Linus Walleij <linus.walleij@stericsson.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Grant Likely <grant.likely@secretlab.ca>,
Barry Song <21cnbao@gmail.com>,
Shawn Guo <shawn.guo@freescale.com>,
Thomas Abraham <thomas.abraham@linaro.org>,
Linus Walleij <linus.walleij@linaro.org>
Subject: Re: [PATCH] pinctrl: indicate GPIO direction on single GPIO request
Date: Tue, 15 Nov 2011 09:15:40 +0200 [thread overview]
Message-ID: <4EC2119C.5030405@compulab.co.il> (raw)
In-Reply-To: <74CDBE0F657A3D45AFBB94109FB122FF1740805AAE@HQMAIL01.nvidia.com>
On 11/14/11 19:18, Stephen Warren wrote:
> Linus Walleij wrote at Monday, November 14, 2011 2:11 AM:
>> When requesting a single GPIO pin to be muxed in, some controllers
>> will need to poke a different value into the control register
>> depending on whether the pin will be used for GPIO output or GPIO
>> input. So pass this info along for the gpio_request_enable()
>> function, we assume this is not needed for the gpio_free_disable()
>> function for the time being.
>
> I'm not sure this API change makes sense.
>
> Functions gpio_direction_{input,output} already exist to configure the
> direction of a GPIO, and drivers should already be using them. These have
> to work to allow drivers to toggle the direction dynamically. Requiring
> them to additionally pass this same information to the pinmux driver when
> setting up the pinmux seems like extra redundant work.
>
> Instead, shouldn't it work like this:
>
> * If the pinmux driver implementation behind pinmux_request_gpio() needs
> to know the direction when configuring the HW, default to input for safety;
> that will prevent the SoC driving a signal on a GPIO that's driven by some
> other device.
If the GPIO has been configured for output by boot loader
and drives a value, and now you want Linux to take control over it,
then configuring it for input will not be safe at all.
I think this kind of flexibility is necessary (although it can be
implemented in different ways).
>
> * Rely exclusively on gpio_direction_{input,output} to allow drivers to
> configure the direction.
>
> * If the pinmux HW needs programming in response to the gpio_direction_*
> calls, have the GPIO and pinmux driver internally communicate to achieve
> this.
>
> Does that seem reasonable?
>
--
Regards,
Igor.
prev parent reply other threads:[~2011-11-15 7:15 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-14 9:10 [PATCH] pinctrl: indicate GPIO direction on single GPIO request Linus Walleij
2011-11-14 11:08 ` Igor Grinberg
2011-11-14 17:18 ` Stephen Warren
2011-11-14 18:00 ` Thomas Abraham
2011-11-15 19:04 ` Stephen Warren
2011-11-17 10:04 ` Linus Walleij
2011-11-17 17:15 ` Stephen Warren
2011-11-21 10:47 ` Linus Walleij
2011-11-21 19:00 ` Stephen Warren
2011-11-21 21:44 ` Linus Walleij
2011-11-21 21:54 ` Stephen Warren
2011-11-23 12:50 ` Linus Walleij
2011-11-15 7:15 ` Igor Grinberg [this message]
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=4EC2119C.5030405@compulab.co.il \
--to=grinberg@compulab.co.il \
--cc=21cnbao@gmail.com \
--cc=grant.likely@secretlab.ca \
--cc=linus.walleij@linaro.org \
--cc=linus.walleij@stericsson.com \
--cc=linux-kernel@vger.kernel.org \
--cc=shawn.guo@freescale.com \
--cc=swarren@nvidia.com \
--cc=thomas.abraham@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.