On Mon, Jul 5, 2010 at 10:36 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > * Grazvydas Ignotas <notasas@xxxxxxxxx> [100703 00:21]: >> Hi, >> >> on OMAP3 CBB package GPIO126 can be muxed on 2 pins: mmc1_dat4 and >> cam_strobe. On pandora mmc1_dat4 is connected to mmc1 write protect, >> this makes omap2_mmc_mux() call omap_mux_init_gpio() on GPIO126, which >> muxes both pins and warns: >> mux: Multiple gpio paths for gpio126 > > OK. > >> This results in unusable GPIO. I wonder how should I handle this, >> perhaps overriding mux by calling omap_mux_init_signal() after >> omap2_hsmmc_init() call? Or maybe omap_mux_init_gpio() should be >> patched not to set up GPIOs if it encounters multiple paths? > > To me the safest route is the second option you suggest where > we refuse to mux GPIO pins that have multiple outputs. > > We should just print a warning and return an error. Then we should > also start checking the return values for omap_mux_init_gpio > now that the code is converted over to use the new mux code. Hm, not sure about return checking, what omap2_mmc_mux() can do when it sees omap_mux_init_gpio failing because of that inevitable gpio126 multipath error? > If you do a patch, please do it against omap for-next branch > as omap_mux_init_gpio has a pending patch for MUXABLE_GPIO_MODE3. ok -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
