All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Tyser <ptyser@xes-inc.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	linux-kernel@vger.kernel.org, Alek Du <alek.du@intel.com>,
	Samuel Ortiz <sameo@linux.intel.com>,
	David Brownell <dbrownell@users.sourceforge.net>,
	Eric Miao <eric.y.miao@gmail.com>,
	Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Joe Perches <joe@perches.com>
Subject: Re: [PATCH 1/3] gpiolib: Add ability to get GPIO pin direction
Date: Mon, 14 Feb 2011 11:45:20 -0600	[thread overview]
Message-ID: <1297705520.965.5657.camel@petert> (raw)
In-Reply-To: <AANLkTimyD=U-+=HpXWmF2B9KjrDf8HMCZenAgW3SQgDK@mail.gmail.com>

> > We need four states for a gpio pin direction though. A pin can be
> >
> > - input
> > - output
> 
> There are actually multiple output modes that a specific gpio
> controller could implement, but the gpio api only has a boolean
> understanding of output.  I don't know if it is really worthwhile to
> try and encode all the possible configurations in this API.
> 
> > - unknown (hardware lacks get functionality and it has not been set by
> >  software yet)

I'm not sure how we could handle unknown directions in a better way.  We
really should know the direction by this point for most (all?) GPIO
chips.  I'd think the proper fix would be to make sure we can detect a
direction for all chips - either by reading hardware bits or by having
the platform code let us know (eg pdata->n_latch in pcf857x.c).  If you
have a suggestion about how unknown pins should be used, I can look into
it and submit a follow up patch.

> > - alt_func (pin is in use for some other purpose)
> 
> What is the use-case for alt_func?  From the point of view of a GPIO
> driver, I don't think it cares if the pin has been dedicated to
> something else.  It can twiddle all it wants, but if the pin is routed
> to something else then it won't have any external effects (pin mux is
> often a separate logic block from the gpio controller).  Also with
> GPIOs, the engineers fiddling with them *really* needs to know what
> the gpios are routed to.  It is highly unlikely to have any kind of
> automatic configuration of gpios; ie. if it isn't wired as a gpio,
> then don't go twiddling it.

Additionally, for this case I thought the low level GPIO driver should
implement a request() function to prevent a non-GPIO pin from being used
in the first place.  Eg like chip_gpio_request() in cs5535-gpio.c, or
ichx_gpio_request() in patch 3 of this series.

> > (and being able to set them alt_func was proposed a while ago and I think
> > wants revisiting judging by the number of platforms which use gpio, and
> > in their own arch code are privately handling alt_func stuff)
> 
> Fair enough; convince me on alt_func.  What is the use case that I'm missing?

Peter


  parent reply	other threads:[~2011-02-14 17:46 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-06 19:54 [PATCH 1/3] gpiolib: Add ability to get GPIO pin direction Peter Tyser
2011-01-06 19:54 ` [PATCH 2/3] gpio: pca953x: Implement get_direction() hook Peter Tyser
2011-01-06 23:16   ` David Brownell
2011-01-06 19:54 ` [PATCH 3/3] gpio: Add support for Intel ICHx/3100/Series[56] GPIO Peter Tyser
2011-01-06 23:12   ` David Brownell
2011-02-14 15:48 ` [PATCH 1/3] gpiolib: Add ability to get GPIO pin direction Peter Tyser
2011-02-14 16:02   ` Grant Likely
2011-02-14 19:14     ` Grant Likely
2011-02-14 20:01       ` Peter Tyser
2011-02-14 17:08   ` Alan Cox
2011-02-14 17:26     ` Grant Likely
2011-02-14 17:39       ` Mark Brown
2011-02-14 17:45       ` Peter Tyser [this message]
2011-02-14 18:04         ` Grant Likely
2011-02-14 18:46           ` Peter Tyser
2011-02-14 19:35       ` Alan Cox
2011-02-14 23:35         ` Peter Tyser
2011-02-15 11:42           ` Alan Cox
2011-02-15 17:05             ` Peter Tyser
2011-02-15 17:19               ` Alan Cox
2011-02-15 17:49                 ` Peter Tyser
2011-02-15 19:41                   ` Alan Cox
2011-02-17  8:06                   ` Uwe Kleine-König
2011-03-06  7:53               ` Grant Likely
2011-02-15 23:55           ` Mark Brown
2011-03-06  7:49         ` Grant Likely

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=1297705520.965.5657.camel@petert \
    --to=ptyser@xes-inc.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=alek.du@intel.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=dbrownell@users.sourceforge.net \
    --cc=eric.y.miao@gmail.com \
    --cc=grant.likely@secretlab.ca \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sameo@linux.intel.com \
    --cc=u.kleine-koenig@pengutronix.de \
    /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.