* Gadiyar, Anand <gadiyar@xxxxxx> [091214 09:07]: > Kevin Hilman wroteL > > > > > > 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. > > > > At least the debug prints would have pointed me to this driver. > > Okay, I'll try and cook something up for updating the debobs driver. Sounds like debobs should only set the pins based on platform_data passed from the board-*.c file. Then maybe allow override from cmdline on boards that have both debobs and ehci? 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
