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. >> 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. > 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. g.
Attachment:
usb-good.log
Description: Binary data
Attachment:
usb-bad.log
Description: Binary data
