* 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. 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. Regards, Tony -- 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
