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..
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
