On Saturday 18 October 2008, Felipe Balbi wrote: > > Partial fixup patch appended; doesn't resolve $SUBJECT > > issue, I think, but it's in the right direction. > > Looks fine. I recall talking to you about this some months ago but my > approach was about introducing a drivers/usb/otg layer to which we would > usb_otg_register_driver() or something similar thus allowing musb (or > any other consumer) just use the otg_tranceiver that is registered now. Right now all we need is a way to make sure the MUSB code isn't assuming an integrated transceiver ... the patch I just sent is *only* to git rid of that "use an out-of-date copy of the original transceiver" logic. There are certainly some improvements that can be made in the area of OTG transceiver handling. There are some PXA related patches in that area, too. ISTR one of them was just to provide calls to register and unregister the OTG transceiver, moving them out of platform code (where they live today)... What I recall about your drivers/usb/otg notion (maybe not entirely correctly) was that it covered a lot of stuff which, it seemed to me, didn't need abstracting. Maybe once we get the current MUSB stuff to work within the current framework -- which splits out otg_transceiver as an entity that host and peripheral side controller drivers talk to -- we should revisit such stuff. > The good thing about it is that it would allow us to switch otg > transceivers and not have to add aditional conditional code to handle > it. > > Your approach looks good but case we have to change the transceiver (not > twl4030-usb, let's say) it's a bit difficult to handle that. I don't follow *that* at all. If some driver other than twl4030-usb registers as the system's OTG transceiver, MUSB on OMAP3x should just use that. All musb should do is ask for the transceiver, and then talk to it ... but the current code can't do that. > I'd say your fix is good as a short term, right ? Let's make sure it doesn't break DaVinci and TUSB first. It'd be good to remove the musb->xceiv->state doubled indirections in most places too, just as cleanup. (Plus cope with the $SUBJECT issue "for real"!) > We have already > blackfin support for musb and most likely they won't usb twl4030 chips, Right. Does Blackfin have an integrated transceiver like DaVinci and TUSB? Or does it use a discrete one? > I also got a mail from another company asking about adding their musb > glue to our code so this problem with the otg transceiver might soon be > a big pain. > > What do you say ?? I'm thinking this issue needs resolving before twl4030-usb can go upstream. :) Does mainline work with tusb6010 today? I see lots of USB patches merged yesterday. And enough ARM/DaVinci patches merged (a few days back) that its MUSB might work too. - Dave > > -- > balbi > > -- 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
