Re: MMC3 Overo

[Tony Lindgren <tony@atomide.com>]

* Vladimir Pantelic <pan@nt.tu-darmstadt.de> [090807 12:24]:
> Tony Lindgren wrote:
>
> <snip>
>>>  Here's an idea:
>>>
>>>  1) Replace index with enum search in pin table - this breaks the
>>>  requirement that the enum list and table align - a good thing as
>>>  misalingment has bitten me multiple times when adding pins to the
>>>  current mux table.  Also, pinmux setup is done infrequently, so the
>>>  search doesn't add much overall execution time.
>>
>> Yeh something like that sounds good. We should just move the omap1
>> specific code to live in mach-omap1 and keep it as it is for now.
>>
>> You might also want to take a look at what the sh people have done:
>>
>> $ find arch/sh -name \*mux*
>>
>>>  2) Break up mux table into two parts, the "common" mux list, and a
>>>  "custom" mux list - the latter in the board file, and add a function to
>>>  add the custom mux list to mux lists searched by omap_cfg_reg().
>>>
>>>  3) Search the custom mux list first (if specified - allows replacing an
>>>  entry in the common table if hardware required differences in
>>>  termination, custom pins for GPIO, etc).
>>>
>>>  For example, on the OMAP3530, balls H18-H21 can be associated with
>>>  either UART3, or GPIOs 163-166. In the common mux list (where multiple
>>>  boards use those pins for UART3, the common mux file can have the
>>>  entries:
>>>
>>>  H18_35XX_UART3_CTS
>>>  H19_35XX_UART3_RTS
>>>  H20_35XX_UART3_RX
>>>  H21_35XX_UART_TX
>>>
>>>  that sets up the mux for those pines as a UART.  If a board wants to use
>>>  those pins instead for GPIO, then in the board file it can have a custom
>>>  mux list with:
>>>
>>>  H18_35XX_GPIO_163
>>>  H19_35XX_GPIO_164
>>>  H20_35XX_GPIO_165
>>>  H21_35XX_GPIO_166
>>>
>>>  and call into the mux code to add the custom mux list to be searched
>>>  first.
>>>
>>>  Thoughts?
>>
>> Sounds pretty good to me!
>
> but does not solve yet the "package" issue, where different omap3 packages have
> different balls connected, no? It would be ok for board files, assuming that a
> board has only one package, but what about the common code?
>
> Or are the package differences only for a few pins, in this case they could be
> "banned" from common and must live in board files..

Well we need to mux all the pins that can potentially conflict only in the
board-*.c files.

For naming, I think we should use the default mode0 name in the mux register as the
key, and then link package specific pin names to that key. The pin names are
very handy to see for debugging at least.

Another thing to consider is if we want to support dynamic muxing. That means
we need to keep the mux tables in the memory.

Or do init time muxing in board-*.c files, then re-register the pins needed for
dynamic muxing in board-*.c files. That way most of the mux data can be __initdata,
and only the pins that have been registered for dynamic muxing need to be kept
in the memory.

Regard,

Tony