All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Tyser <ptyser@xes-inc.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Cc: 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>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	Joe Perches <joe@perches.com>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Grant Likely <grant.likely@secretlab.ca>
Subject: Re: [PATCH v3 2/4] gpiolib: Add ability to get GPIO pin direction
Date: Fri, 18 Feb 2011 11:36:26 -0600	[thread overview]
Message-ID: <1298050586.965.20444.camel@petert> (raw)
In-Reply-To: <20110218085734.GX22310@pengutronix.de>

On Fri, 2011-02-18 at 09:57 +0100, Uwe Kleine-König wrote:
> On Thu, Feb 17, 2011 at 05:03:17PM -0600, Peter Tyser wrote:
> > Add a new get_direction() function to the gpio_chip structure.  This is
> > useful so that the direction of a pin can be determined when its
> > initially exported.  Previously, the direction defaulted to "unknown"
> > regardless of the actual configuration of the GPIO pin.
> > 
> > If a GPIO driver implements get_direction(), it is called in
> > gpio_request() to set the initial direction of the pin accurately.
> IMHO the commit log is conceptually wrong, because it talks about a
> "pin".  Better use gpio here.

I don't follow.  I used "pin" to make it clear that the get_direction()
function operates on a pin-by-pin basis, and to help reduce any
ambiguity about if a gpio chip or gpio pin is being referred to.  Would
you prefer that the "pin" references are clarified to be "GPIO pin"?

> > Cc: Alek Du <alek.du@intel.com>
> > Cc: Samuel Ortiz <sameo@linux.intel.com>
> > Cc: David Brownell <dbrownell@users.sourceforge.net>
> > Cc: Eric Miao <eric.y.miao@gmail.com>
> > Cc: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> > Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> > Cc: Joe Perches <joe@perches.com>
> > Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > Cc: Grant Likely <grant.likely@secretlab.ca>
> > Signed-off-by: Peter Tyser <ptyser@xes-inc.com>
> > ---
> > Changes since v1:
> > - Add support for "unknown" direction
> > 
> > Changes since v2:
> >   Based on Wolfram's feedback:
> > - Use GPIOF_DIR_* flags as returns from get_direction()
> > - Call spin_lock_irqsave() to before setting flags
> > 
> >  drivers/gpio/gpiolib.c     |   23 +++++++++++++++++++++++
> >  include/asm-generic/gpio.h |    4 ++++
> >  2 files changed, 27 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> > index eb74311..a656a2c 100644
> > --- a/drivers/gpio/gpiolib.c
> > +++ b/drivers/gpio/gpiolib.c
> > @@ -1174,6 +1174,7 @@ int gpio_request(unsigned gpio, const char *label)
> >  	struct gpio_desc	*desc;
> >  	struct gpio_chip	*chip;
> >  	int			status = -EINVAL;
> > +	int			dir;
> >  	unsigned long		flags;
> >  
> >  	spin_lock_irqsave(&gpio_lock, flags);
> > @@ -1214,6 +1215,28 @@ int gpio_request(unsigned gpio, const char *label)
> >  		}
> >  	}
> >  
> > +	if (chip->get_direction) {
> > +		/* chip->get_direction may sleep */
> > +		spin_unlock_irqrestore(&gpio_lock, flags);
> might_sleep_if(chip->can_sleep) ?

Makes sense.  I was following the lead of chip->request() in the same
function, which doesn't use might_sleep_if().  I assume might_sleep_if()
should be added to it as well in a separate patch?

> > +		dir = chip->get_direction(chip, gpio - chip->base);
> > +		spin_lock_irqsave(&gpio_lock, flags);
> > +		switch (dir) {
> > +		case GPIOF_DIR_OUT:
> > +			set_bit(FLAG_DIR_OUT, &desc->flags);
> > +			clear_bit(FLAG_DIR_IN, &desc->flags);
> > +			break;
> > +		case GPIOF_DIR_IN:
> > +			set_bit(FLAG_DIR_IN, &desc->flags);
> > +			clear_bit(FLAG_DIR_OUT, &desc->flags);
> > +			break;
> > +		default:
> > +			/* Direction isn't known */
> > +			clear_bit(FLAG_DIR_OUT, &desc->flags);
> > +			clear_bit(FLAG_DIR_IN, &desc->flags);
> > +			break;
> > +		}
> Alternatively to my suggestion for patch1:
> 	} else {
> 		clear_bit(FLAG_DIR_OUT, &desc->flags);
> 		clear_bit(FLAG_DIR_IN, &desc->flags);

I like this way better too.  I'll initialize dir = -1 and pull the
switch statement out of the conditional, like:

	if (chip->get_direction) {
		/* chip->get_direction may sleep */
		spin_unlock_irqrestore(&gpio_lock, flags);
		might_sleep_if(chip->can_sleep);
		dir = chip->get_direction(chip, gpio - chip->base);
		spin_lock_irqsave(&gpio_lock, flags);
	}

	switch (dir) {
	case GPIOF_DIR_OUT:
		set_bit(FLAG_DIR_OUT, &desc->flags);
		clear_bit(FLAG_DIR_IN, &desc->flags);
		break;
	case GPIOF_DIR_IN:
		set_bit(FLAG_DIR_IN, &desc->flags);
		clear_bit(FLAG_DIR_OUT, &desc->flags);
		break;
	default:
		/* Direction isn't known */
		clear_bit(FLAG_DIR_OUT, &desc->flags);
		clear_bit(FLAG_DIR_IN, &desc->flags);
		break;
	}

Thanks for the comments,
Peter


  reply	other threads:[~2011-02-18 17:37 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-17 23:03 [PATCH v3 1/4] gpiolib: Add "unknown" direction support Peter Tyser
2011-02-17 23:03 ` [PATCH v3 2/4] gpiolib: Add ability to get GPIO pin direction Peter Tyser
2011-02-18  8:57   ` Uwe Kleine-König
2011-02-18 17:36     ` Peter Tyser [this message]
2011-02-18 18:49       ` Uwe Kleine-König
2011-02-18 20:27         ` Peter Tyser
2011-02-17 23:03 ` [PATCH v3 3/4] gpio: pca953x: Implement get_direction() hook Peter Tyser
2011-02-17 23:03 ` [PATCH v3 4/4] gpio: Add support for Intel ICHx/3100/Series[56] GPIO Peter Tyser
2011-02-18 17:58   ` Vincent Palatin
2011-02-18 20:28     ` Peter Tyser
2011-02-18  0:07 ` [PATCH v3 1/4] gpiolib: Add "unknown" direction support Ryan Mallon
2011-02-18  0:33   ` Peter Tyser
2011-02-18  8:51 ` Uwe Kleine-König

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=1298050586.965.20444.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.