public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Linus Walleij <linus.walleij@stericsson.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Stephen Warren <swarren@nvidia.com>,
	Anmar Oueja <anmar.oueja@linaro.org>,
	Pankaj Dev <pankaj.dev@st.com>
Subject: Re: [PATCH] pinctrl: document the "GPIO mode" pitfall
Date: Sat, 27 Apr 2013 03:16:47 +0200	[thread overview]
Message-ID: <2359346.pRaN3J5Bl7@avalon> (raw)
In-Reply-To: <CACRpkdaMdU4DHWULnSB_dvGk8pTRbirL1HVTGqJ2rwqXR798uQ@mail.gmail.com>

Hi Linus,

On Friday 26 April 2013 10:49:12 Linus Walleij wrote:
> On Fri, Apr 26, 2013 at 1:15 AM, Laurent Pinchart wrote:
> > On Thursday 25 April 2013 23:39:18 Linus Walleij wrote:
> >> On Tue, Apr 23, 2013 at 3:33 PM, Laurent Pinchart wrote:
> >> > Could you clarify the exact scope of the two configuration parameters ?
> >> 
> >> PIN_CONFIG_OUTPUT is left a bit unspecified, but here the idea was a
> >> passive drive, like just connecting the pin to VDD or GND without any
> >> driver stage at all.
> > 
> > Isn't that a driver stage ? :-)
> 
> OK something that is not a totempole type drive ...
> push/pull surely implies a totempole type design.
> 
> > What is unclear to me is the interaction between OUTPUT and DRIVE_*.
> > That's the part I would like to see clarified.
> 
> I sent some patch now, check it ... hm reported-by still doesn't add
> you to CC :-/ better patch git-send-email...
> 
> > Does DRIVE_* imply that the pin is driven by the selected function, and
> > OUTPUT imply that the pin is driven to a fixed level ?
> 
> That is unclear, but I suggest DRIVE* implies that everything on the pin
> is driven according to that configuration. (Else it is getting ignored...)
> 
> OUTPUT would be used when you don't know the particulars or when
> the driving cannot be controlled in a fine-grained manner like with the
> DRIVE* configs.
> 
> Does this make sense?

Kinda, but it's still unclear to me. While the options are (briefly) 
documented, how they interact isn't.
 
> > If so, how do you configure the drive type of a pin that will be used
> > through the GPIO API ?
> 
> It is possible to use the pinctrl and GPIO APIs orthogonally.
> 
> For example the pinctrl can use hogs to reconfigure the pins during sleep
> without intervention from the GPIO API.
> 
> So they will be fingering on the same pins registers. Maybe even the same
> register (if access can be protected properly) from different APIs.
>
> > What about cases where I want to drive the pin to a fixed level in a non
> > low-power output mode (for instance because I need more current that what
> > the low-power output mode provides) ?
> 
> Just use pinconfig for that?

How would you do so ? Only OUTPUT allows setting the output level explictly, 
the other DRIVE_* options don't specify the output level.

> Is the usecase something like a power-supplying GPIO pin and then sometimes
> you want to provide more power from it?
> 
> Then use pinconfig to shunt in the driver stages, and GPIO API to
> enable/disable it.

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2013-04-27  1:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-15 11:07 [PATCH] pinctrl: document the "GPIO mode" pitfall Linus Walleij
2013-03-15 20:53 ` Stephen Warren
2013-04-23 13:33 ` Laurent Pinchart
2013-04-25 21:39   ` Linus Walleij
2013-04-25 23:15     ` Laurent Pinchart
2013-04-26  8:49       ` Linus Walleij
2013-04-27  1:16         ` Laurent Pinchart [this message]
2013-05-12 23:36           ` Linus Walleij

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=2359346.pRaN3J5Bl7@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=anmar.oueja@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pankaj.dev@st.com \
    --cc=swarren@nvidia.com \
    /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