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

[Igor Grinberg]

Hi,

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).

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


-- 
Regards,
Igor.