"Gadiyar, Anand" <gadiyar@xxxxxx> writes: > Gadiyar, Anand wrote: >> Gupta, Ajay Kumar wrote: >> > > >> > > I'm seeing some strange behavior with linux-omap-pm branch >> > > and possibly with linux-omap master as well. I booted up >> > > a 3430 SDP with an image built using omap3_pm_defconfig. >> > > (I enabled EHCI in the menuconfig). >> > >> > Check if CONFIG_OMAP_MUX=y set. >> > >> >> It's set. >> >> Also, dumping the registers just after the usb-echi.c makes >> these mux calls shows they are okay. >> >> Something seems to be changing these later - debugging now. >> > > > Found it - I remember that these lines are muxed with ETK signals > and with the hwdebug signals. > > So I looked at the debobs driver - and that's the culprit! > (Cc-ing the author of that driver) > > How should this be handled? IMO, this driver has should use the > MUX framework for changing the mux modes. > > What say? Yes, the debobs driver needs to be updated to use the MUX API. But even with that, AFAICT, the new mux API will still allow the last caller to "win" as there is no request/free API to get pins. Kevin -- 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
