On Thursday 27 November 2008, Gupta, Ajay Kumar wrote: > > This is obviously wrong. One does set_transceiver(), > > the other does get_transceiver() ... > > For OMAP3EVM we don't need twl4030 support for musb and thus > otg_set_transceiver() which was done > in twl4030-usb.c, is now done here itself for OMAP3EVM. Which is obviously wrong. Some other code should have called otg_set_transceiver() ... *NEVER* the musb driver, except with silicon that integrates an OTG transceiver (like DaVinci and Blackfin). Yes, the MUSB driver hasn't fully sorted this out yet; it started with DaVinci EVMs, and only later started to support discrete transceivers. Patches are in the works to fix that, I'm not sure of their status. That's an example of why you must not discard your basic intuition when updating drivers ... like noticing that since two branches of an #if do entirely different things, at least one branch must accordingly be wrong. > Whereas for SDP and Beagle twol4030-usb would be enabled and > thus otg_set_transceiver() would > have been done in twl4030-usb.c file itself. > > > > > It seems that some boards need some kind of basic > > OTG transceiver stub. The newish drivers/usb/otg > > directory is the place to keep such stuff. So the answer for you is obviously to have something other than the musb driver hold your otg_transceiver driver. Like ... an isp1504.c I2C driver, which will eventually move to drivers/usb/otg and which calls the otg_set_transceiver() utility. Board-specific logic would presumably involve just declaring the i2c board info for the isp1504 chip. - Dave -- 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
