[U-Boot] [PATCH 1/2] efikamx: Configure the pins as GPIOs prior to using gpio_get_value.

[Mike Frysinger <vapier@gentoo.org>]

On Wednesday 23 November 2011 02:02:25 Igor Grinberg wrote:
> On 11/22/11 23:07, Mike Frysinger wrote:
> > 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 ?
> 
> I think, currently, you are right, but if we look in some other
> AF (Alternate Functions) (not GPIO), same AF can be available on
> different physical pins. This means that in theory, same GPIO number
> can also be connected to different physical pins.
> I think it should be board controllable instead of gpiolib hard coded,
> or of course pinmux controlled (which is board controllable).

i understand AF for peripheral pins, but i'm not seeing the same-gpio-number-
for-different-pins part.

> >> 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.
> 
> This is probably the best way and correct me if I'm wrong,
> this means stick with board control over the pinmux
> instead of gpiolib.

*shrug* whatever the maintainer of the gpio/drivers want to do.  as long as 
it's not common code, i won't worry about it for now.
-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/20111123/2b129252/attachment.pgp>