MIME-Version: 1.0
In-Reply-To: <516DB233.5070504@codeaurora.org>
References: <516DB233.5070504@codeaurora.org>
Date: Wed, 17 Apr 2013 18:05:43 +0200
Message-ID: <CACRpkda_V7qKUKF9o5kNpra7VQbu+hEoAsr1z1_0upFw5s0wQA@mail.gmail.com>
Subject: Re: [RFC] Pinctrl: driver design supporting gpiolib
From: Linus Walleij <linus.walleij@linaro.org>
To: hanumant <hanumant@codeaurora.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Stephen Warren <swarren@wwwdotorg.org>
Content-Type: text/plain; charset=ISO-8859-1
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4585
Lines: 127

On Tue, Apr 16, 2013 at 10:18 PM, hanumant <hanumant@codeaurora.org> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/