RE: gpio126: Multiple gpio paths (2) : CAM_STROBE & SDMMC1_DAT4

[Anand Gadiyar <gadiyar@ti.com>]

Koyamangalath, Abhilash wrote:
> There is this boot-time message on the am3517evm (and possibly
> other omap 35xx based boards as well)
> [    0.000000] _omap_mux_init_gpio: Multiple gpio paths
>  (2) for gpio126
> I realized that this happens due to dual mappings for
> gpio_126 in arch/arm/mach-omap2/mux34xx.c:
>
> static struct omap_mux __initdata omap3_muxmodes[] = {
> :
> _OMAP3_MUXENTRY(CAM_STROBE, 126,
>                 "cam_strobe", NULL, NULL, NULL,
>                 "gpio_126", "hw_dbg11", NULL, "safe_mode"),
> :
> _OMAP3_MUXENTRY(SDMMC1_DAT4, 126,
>                 "sdmmc1_dat4", NULL, "sim_io", NULL,
>                 "gpio_126", NULL, NULL, "safe_mode"),
> :
> #if defined(CONFIG_OMAP_MUX) &&
> defined(CONFIG_OMAP_PACKAGE_CBB) static struct omap_mux
> __initdata omap3_cbb_subset[] = {
> :
>        _OMAP3_MUXENTRY(CAM_STROBE, 126,
>                 "cam_strobe", NULL, NULL, NULL,
>                 "gpio_126", NULL, NULL, "safe_mode"),
>
> Removing one instance of CAM_STROBE from omap3_muxmodes rids us
> of this (pr_info) message and should be fine as this is defined in
> omap3_xxx_subset as well. But I'm concerned if this would
> break things
> on the other omap3 boards?
>
> For completeness, I've listed my patch (only for the CBB
> package) below
> (this also modifies the Mode 5 value of CAM_STROBE from NULL
> to hw_dbg11
> in omap3_cbb_subset, which is incorrect right now); please comment:
>
> ---

The GPIO 126 signal is available on two pads of that package.
You will therefore need to update the caller to use
omap_mux_init_signal specifying the full name as "cam_strobe.gpio_126"
or equivalent.

I'm not sure if you can do something similar using omap_mux_init_gpio.

Dropping an entry from the table is not the right way to go.

- Anand