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: Tue, 22 Nov 2011 16:07:08 -0500 [thread overview]
Message-ID: <201111221607.09360.vapier@gentoo.org> (raw)
In-Reply-To: <4ECB5A33.5040502@denx.de>
On Tuesday 22 November 2011 03:15:47 Stefano Babic wrote:
> On 21/11/2011 22:22, Mike Frysinger wrote:
> >> 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.
>
> In fact it would be nicer if gpio_request() takes care of the pinmux,
> in the way I can see on the davinci SOCs. However, on the IMXs a
> single GPIO can be connected (not at the same time, of course) to
> different PADs, depending on a general setup (GPR register) or if the
> daisy chain in the multiplexer is activated.
if it's different physical pins, then perhaps it should be different GPIO
numbers ?
> The second point I will arise is that, mainly due to the different
> internal layout but also for historical reasons, the setup and the
> provided function for the multiplexer is very different among the SOCs.
>
> Only mx35 and mx5 expone the same interface (mxc_request_iomux), while
> mx31/mx25/mx27/mx28 have its own. Because we use and we want to use
> the GPIO framework, the gpio driver, common to all IMX SOCs, should be
> able to set up the multiplexer independently from the SOC type, that
> means we should have the same interface for the multiplexer, and we
> have not (yet ?).
this is shaking out in Linux with the pinmux framework, so probably best to
grit our teeth until that's done and then adopt what they implement.
-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/20111122/8f5fe6bc/attachment.pgp>
next prev parent reply other threads:[~2011-11-22 21:07 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
2011-11-22 8:15 ` Stefano Babic
2011-11-22 21:07 ` Mike Frysinger [this message]
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=201111221607.09360.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox