plat-orion multi purpose pins problem for mv78200

[Joey Oravec]

On 7/3/2011 8:46 AM, saeed bishara wrote:
>> It doesn't seems the code was behaving differently before 3.0-rc. I mean
>> before the MPP and GPIO consolidation work. It was ?
> that's right, this issue was before the consolidation work.
Agreed. I only meant to say that the MPP code is broken for mv78200 in 
3.0-rc5, so the maintainers should consider a short-term fix of 
disabling the checks in orion_gpio_is_valid().

>> Does hardware allows a configuration like MPP0_GE0_COL and MPP32_GPIO
>> simultaneously ?
> yes, this is possible.
Agreed. MPP is the pin that can be mux'ed to 7 resources. GPIO is just 
one of those resources. Yes the hardware supports your example. Most 
resources can be routed to several different pins to allow flexibility 
in board design.

Since MPP is just a pin-mux, it's possible for Marvell to build an SoC 
in the future that can route a few different GPIOs onto a given MPP pin. 
It seems like any solution should account for this.

>> If not (and only if not), the problem is simply mapping a MPP number on
>> the correct GPIO number. Isn't it ?
>>
>> In that case, what about using the MPPxx_GPIO definitions (found in
>> mach-mv78xx0/mpp.h) to map the right GPIO number ?
>>
>> For example:
>>
>> #define MPP32_GPIO        MPP(32, 0x1, 1, 1, 1)
>>
>> could be replaced by:
>>
>> #define MPP32_GPIO        MPP(0, 0x1, 1, 1, 1)
> that won't work because the num (first number) is used as the mpp
> index. see orion_mpp_conf() implementation.
> I think the solution is to extend the MPP define to include the
> explicit gpio number, so it will look like:
> #define MPP(_num, _gpio _sel, _in, _out, _78100_A0)
That could work as long as a value is reserved to mean "not gpio" like:

#define MPP0_GPIO        MPP(0, 0, 0x0, 1, 1, 1)
#define MPP0_GE0_COL        MPP(0, -1, 0x1, 1, 0, 1)

Note that orion_gpio_set_valid() and orion_gpio_is_valid() would both 
need rework. The functions need to handle that a GPIO can be mux'ed onto 
any MPP pin. I described this problem in another email on the thread.

There has been some discussion of a pinmux API. Does this API offer any 
simpler solution?

-joey