Re: [RFC] Pinctrl: driver design supporting gpiolib

[hanumant]

On 04/17/2013 09:05 AM, Linus Walleij wrote:
> On Tue, Apr 16, 2013 at 10:18 PM, hanumant <hanumant@xxxxxxxxxxxxxx> wrote:
>
> > I am trying to implement a pinctrl driver.
> > I have given a brief description of the relevant pinctrl hw features as well
> > as a the use cases and my proposed solution for them. Please advise/comment.
>
> OK! Generic background material:
>
> Brief overview by LWN editor Jon Corbet:
> http://lwn.net/Articles/468759/
>
> Documentation/pinctrl.txt latest version from Torvald's HEAD:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/pinctrl.txt;hb=HEAD
>
> My slides from the Embedded Linux Conference presenting the pin
> control subsystem:
> http://www.df.lth.se/~triad/papers/pincontrol.pdf
> A video recording of my seminar from the ELC:
> http://video.linux.com/videos/pin-control-subsystem-overview
>
> Another presentation dealing with the software side of things:
> http://www.df.lth.se/~triad/papers/Linaro_pinctrl_overview.pdf
>
> > HW:
> > The pin controller has the following properties
> > 1) Each pin has its own 32 bit register at a fixed offset from base.
> > 2) Register supports configuration like drive strength, pull, function.
>
> Makes it sound like you can use the generic pinconfig in
> drivers/pinctrl/pinconf-generic.c
> include/linux/pinctrl/pinconf-generic.h
>
> > 3) The function can be gpio or a number of other functionalities.
>
> Regarding this, please read carefully the section named
> "GPIO mode pitfalls" in Documentation/pinctrl.txt from the latest
> linux-next.
>
> > 4) By default all pins are configured as GPIO.
>
> You mean they are configured like that at power-on or something?
>
> > The SOC using this pinmuxer hardware has various peripherals(clients) that
> > utilize this pinmuxer for example, spi, uart etc
>
> OK this is normal.
>
> > Usecases:
> > The use cases can broadly fall into 3 cattegories.
> >
> > 1) Client defines atleast 2 configurations (active, suspend)
>
> We call these "default" and "sleep", see:
> include/linux/pinctrl/pinctrl-state.h
>
> > for its pin groups, with different drive strength and pull up values for
> > each configuration and both configurations have function as being not gpio
> > but the specified use case. (For eg pin 1 used for UART TX
> > and pin 2 used for UART RX. Both should have function = 1 => uart will drive
> > them. If function = 0 they can be used as gpio.If function = 3
> > spi will drive them)
>
> This is supported by the pinctrl subsystem.
>
> > 2) Client uses 2 configurations (active, suspend)
>
> (So again I refer to these as default and sleep.)
>
> > with the function being
> > gpio (function = 0). Both configurations use different pull up and drive
> > strength values but in each case the pins are used in gpio mode.
>
> Refer to the document about GPIO mode pitfall.
>
> Pin mode in datasheet named "GPIO" does not mean
> Linux GPIO subsystem shall be used by necessity.
>
> The important question is if the consumer in the Linux
> kernel (such as a driver) is using gpio_request() etc to
> access these pins, or if it is an ordinary driver.
>
> > 3) Client uses more then 2 configurations (pull, drive strength) with a
> > combination of the same group of pins being configured as gpio and non gpio
> > (specific function)
>
> The pinctrl subsystem actually even allows you to use the same
> pin for a function and GPIO *at the same time*. This is because
> some systems will allow these two things to mess with each other,
> e.g. to use a GPIO pin to "spy" on a UART.
>
> > Solutions:
> > Solution For usecase 1) I believe the existing framework supports this by
> > having the client define states that would correspond to the same function
> > mapping to different configurations. With each map being identified by the
> > state name.
>
> Yes.
>
> > Solution For usecase 2) my proposal is
> > a) to have the client select the state that configures the drive strength
> > and the pull up values.
> > b) call gpio_request to own the gpio. (Add support for giolib in the
> > pinctrl)
> > c) set direction
> > d) set/read value
>
> Yes if the individual GPIO pins is what the driver needs to acces,
> like it needs to drive them high and low or read the value.
> Then this is the right way.
>
> > Solution For usecase 3) Have the client use the above 2 solutions
> > for respective situations.
>
> Yes pinctrl and GPIO can be used at the same time.
>
> > Please let me know if you believe there is a better way to handle use case 2
> > and 3
>
> No I think you've got it! :-)
>
> Yours,
> Linus Walleij
Thanks for all the information and your help.

Hanumant

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
Forum, hosted by The Linux Foundation
--
--
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/