All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] efikamx: Configure the pins as GPIOs prior to using gpio_get_value.
Date: Mon, 21 Nov 2011 16:22:33 -0500	[thread overview]
Message-ID: <201111211622.34820.vapier@gentoo.org> (raw)
In-Reply-To: <201111212153.45505.marek.vasut@gmail.com>

On Monday 21 November 2011 15:53:45 Marek Vasut wrote:
> > On Monday 21 November 2011 14:29:50 Marek Vasut wrote:
> > > > On Monday 21 November 2011 09:20:49 Marek Vasut wrote:
> > > > > > Configure the pins as GPIOs prior to using gpio_get_value
> > > > > > 
> > > > > > +	else {
> > > > > > +		mxc_request_iomux(MX51_PIN_GPIO1_8, IOMUX_CONFIG_ALT0);
> > > > > >  		*absent = gpio_get_value(IOMUX_TO_GPIO(MX51_PIN_GPIO1_8));
> > > > > > -
> > > > > > +	}
> > > > > 
> > > > > NAK. There should be some common function for setting up iomux of
> > > > > those pins. You souldn't set it in repeatedly called functions.
> > > > 
> > > > that's what gpio_request() is for
> > > 
> > > I mean in efika.c ... there should be a common place for these iomux
> > > configurations being done. This is unrelated to gpio ...
> > 
> > not really ... imo, if someone does gpio_request(PIN), the gpio core
> > should take care of putting it into GPIO mode.  people shouldn't have to
> > pinmux_request(PIN, GPIO_MODE) before doing gpio_request(PIN).
> 
> Of course ... considering there's always one correct setting for the pin to
> be in GPIO mode, which I suspect might not be completely true today
> anymore.

i find it hard to envision a pinmux system where individual pins would have 
different pinmux configurations to get it into GPIO mode.  probably be saner to 
have gpio_request() do the right thing and wait for someone to come forward 
with the unusual setup -- worry about it then.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20111121/a31056ea/attachment.pgp>

  reply	other threads:[~2011-11-21 21:22 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-21 14:09 [U-Boot] [PATCH 1/2] efikamx: Configure the pins as GPIOs prior to using gpio_get_value Fabio Estevam
2011-11-21 14:09 ` [U-Boot] [PATCH 2/2] vision2: " Fabio Estevam
2011-11-21 14:20 ` [U-Boot] [PATCH 1/2] efikamx: " Marek Vasut
2011-11-21 18:53   ` Mike Frysinger
2011-11-21 19:29     ` Marek Vasut
2011-11-21 20:14       ` Mike Frysinger
2011-11-21 20:53         ` Marek Vasut
2011-11-21 21:22           ` Mike Frysinger [this message]
2011-11-22  8:15             ` Stefano Babic
2011-11-22 21:07               ` Mike Frysinger
2011-11-23  7:02                 ` Igor Grinberg
2011-11-23 19:43                   ` Mike Frysinger
2011-11-23  8:19                 ` Stefano Babic
2011-11-23 19:44                   ` Mike Frysinger

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=201111211622.34820.vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --cc=u-boot@lists.denx.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.