Hi, On Fri, Oct 26, 2012 at 12:32:46AM +0100, Grant Likely wrote: > On Thu, Oct 25, 2012 at 11:58 AM, Felipe Balbi <balbi@xxxxxx> wrote: > > Hi, > > > > On Thu, Oct 25, 2012 at 10:19:19AM +0000, Grant Likely wrote: > >> Felipe Balbi <balbi@...> writes: > >> > >> > > >> > we are compiling the driver always with full OTG > >> > capabilities, so that board_mode trick becomes > >> > useless. > >> > > >> > Signed-off-by: Felipe Balbi <balbi@...> > >> > >> This patch breaks ti816x/am3894 support for the MUSB device because > >> the hardware doesn't support OTG mode. The driver needs to be > > > > the HW *does* support OTG. MUSB is configured with OTG support in all TI > > SoCs (or at least the ones I know of). > > > > Let me rephrase, all TI SoCs support DRD (acting as host and as device), > > OTG might be a mis-use of the acronym here. > > Yes, it is a full implementation of the MUSB device in the am3894, but > the problem is that the ID pin is not routed out of the package and so > OTG mode is not supported (according to the reference manual). The > driver needs to be told explicitly if the port should be in host or a > peripheral mode because it cannot ask the hardware. if ID pin isn't exposed, then board should only act as peripheral, actually, since that's the default mode ;-) Still, we can't support cable-based mode changes, but we can definitely support both host and device roles. We can change mode through SW. > >> configured to do either only- host or only-device at setup time. I > >> don't currently have a workaround for this. > >> I'm investigating, but I could use some pointers as how best to handle > >> this. > > > > Well, debugging logs would really help :-) > > I've attached "good" and "bad" logs. I haven't had time today to > re-run with #define DEBUG to provide more detailed output. I'll get to > that tomorrow. Both are from a 3.6.1 based kernel with that particular > commit from mainline merged in on the 'bad' log. cool, will have a loot. > > ps: you could've Cced myself since that's a commit I wrote and I > > maintain the driver. > > Normally I would have, but I didn't have a copy of the original mail > since I wasn't subscribed to linux-usb. I resorted to using the gmane > interface to reply which doesn't give the option of adding CCs. I do > apologize for the inconvenience. no problem. Inconvenience was minimal ;-) -- balbi
Attachment:
signature.asc
Description: Digital signature
