linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: hanumant <hanumant@codeaurora.org>
To: linux-kernel@vger.kernel.org
Cc: linus.walleij@linaro.org, swarren@wwwdotorg.org
Subject: [RFC] Pinctrl: driver design supporting gpiolib
Date: Tue, 16 Apr 2013 13:18:59 -0700	[thread overview]
Message-ID: <516DB233.5070504@codeaurora.org> (raw)

Hi

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.

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.
3) The function can be gpio or a number of other functionalities.
4) By default all pins are configured as GPIO.

The SOC using this pinmuxer hardware has various peripherals(clients) 
that utilize this pinmuxer for example, spi, uart etc

Usecases:
The use cases can broadly fall into 3 cattegories.

1) Client defines atleast 2 configurations (active, suspend)
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)

2) Client uses 2 configurations (active, suspend) 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.

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)

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.

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

Solution For usecase 3) Have the client use the above 2 solutions
for respective situations.

Please let me know if you believe there is a better way to handle use case 2
and 3

Thanks
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
-- 

             reply	other threads:[~2013-04-16 20:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-16 20:18 hanumant [this message]
2013-04-17 16:05 ` [RFC] Pinctrl: driver design supporting gpiolib Linus Walleij
2013-04-18 17:14   ` hanumant

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=516DB233.5070504@codeaurora.org \
    --to=hanumant@codeaurora.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=swarren@wwwdotorg.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).