* Premi, Sanjeev <pr...@ti.com> [091229 05:41]:
> Hi,
>
> I am trying to define the mux settings for keypad on the omap3evm.
> I had a few queries on the same.
>
> 1) Is it enough to me this change:
>
> static struct omap_board_mux board_mux[] __initdata = {
> +
> + /* SYS_NIRQ */
> + OMAP3_MUX(SYS_NIRQ, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP |
> + OMAP_PIN_OFF_INPUT_PULLUP),
> +
> { .reg_offset = OMAP_MUX_TERMINATOR },
This will do the trick for board specific things. If you want, you can
dump the whole mux table set by the bootloader via debugfs if you cat
/sys/kernel/debug/omap_mux. Then you can check and edit the table as
needed.
> 2) Or should I follow with this (in the evm init code):
>
> + omap_mux_init_signal("af26", OMAP_PIN_INPUT_PULLUP |
> + OMAP_PIN_OFF_INPUT_PULLUP);
This can be used too if you prefer. The mux_init_gpio and mux_init_signal
functions are mostly intended for platform init functions for common
hardware, like MMC, USB etc. For board specific pins, I'd go with
#1 abobve.
> 3) OR is this a better(or worse)
>
> static struct omap_board_mux board_mux[] __initdata = {
> +
> + /* SYS_NIRQ */
> + OMAP3_MUX(SYS_NIRQ, OMAP_MUX_MODE0),
> +
> { .reg_offset = OMAP_MUX_TERMINATOR },
>
> ..and later
>
> + omap_mux_init_signal("af26", OMAP_PIN_INPUT_PULLUP |
> + OMAP_PIN_OFF_INPUT_PULLUP);
>
Then you're doing it twice, which is not needed.
Eventually we should have common init functions using hwmod for all
the omap internal devices and do the muxing there too. But some
board specific muxing will always be still needed.
Regards,
Tony
--
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
