* Ben Gamari <bgamari.f...@gmail.com> [100314 19:41]: > > P.P.S. Is it just me or does the omap_pinmux interface need some refinement. > Using it has been an exercise in frustration, between extremely sparse > documentation, quirky behavior (I still haven't figure out how to get gpio_130 > configured. omap_mux_init_gpio fails with "multiple paths for gpio130" > whereas > omap_mux_init_signal fails to even recognize the signal name), and general > complexity. The idea behind the interface seems excellent, but it seems it > hasn't been used enough not to be a complete pain in the ass to figure out and > use.
Hopefully incrementally less frustrating now than earlier though :) So far the new mux code has been tested pretty much only with the existing mux settings, so I'm sure quite a some quirks still remain. The problem of omap_mux_init_gpio not recognizing full signal names is known. At least it correctly gives you warnings and refuses to do anything. The real fix probably in the long run is to change everything to use omap_mux_init_signal instead. But what's the issue of omap_mux_init_signal not recognizing the signal name? It should be just "mode0_name.desired_mode". Is some entry maybe missing from mux34xx.c? Some of the complexity disappears once I get around to converting the 24xx muxing to the new code so we can get rid of the old code. Some complexity is caused by the need to support bootloader-only muxing while still dynamically muxing the GPIO pins for PM idle. Got some good ideas on how to cut down the complexity further? 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
