Question on OTG transceivers
Guys:
I have a Beagleboard-like unit here that uses two SMSC USB3320C-EZK
PHYs: one for EHCI (usb1), the other for OTG (usb0).
Two questions. First, the code in drivers/usb/otg/ulpi.c looks like it might be what I need (my attempts so far with the "nop" transceiver have ended in failure). Am I right?
Second, it looks like otg_set_transceiver() assumes there is only one transceiver in the system. On a device like the OMAP3530 with multiple ports, this seems like an odd assumption--- and one that clearly isn't accurate for my platform. Or am I paying attention to the wrong stuff?
Can anyone help navigate me through the trees in this forest? :)
Thanks!
b.g.
Signature · 4 lines
Bill Gatliff Embedded systems training and consulting http://billgatliff.com [email protected]
Quoted 12 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Bill Gatliff
Sent: Thursday, March 18, 2010 3:05 AM
To: [email protected]
Subject: Question on OTG transceiversGuys:
Quoted 7 lines
I have a Beagleboard-like unit here that uses two SMSC USB3320C-EZK
PHYs: one for EHCI (usb1), the other for OTG (usb0).Two questions. First, the code in
drivers/usb/otg/ulpi.clooks like it might be what I need (my attempts so far with the "nop" transceiver have ended in failure). Am I right?
Actually, the way the ehci-omap driver is currently written, it assumes the transceiver is present and available - you don't need a separate driver to access it.
For that matter, the same probably holds for the OTG driver as well - you really don't need a driver for transparent transceivers like the SMSC332x.
I'm not sure why the code was written this way to introduce NOP XCEIVs (need to go through the changelog to find out why, maybe).
Quoted 6 lines
Second, it looks like
otg_set_transceiver()assumes there is only one transceiver in the system. On a device like the OMAP3530 with multiple ports, this seems like an odd assumption--- and one that clearly isn't accurate for my platform. Or am I paying attention to the wrong stuff?Can anyone help navigate me through the trees in this forest? :)
I think this assumption comes from some part of the OTG spec which says that OTG devices can have only one external USB port.
But embedded devices can certainly have more than one transceiver (for example to connect an on-board USB device without exposing an external port) - so maybe there's no point keeping this restriction any more.
- Anand
Quoted 8 lines · Anand
Actually, the way the ehci-omap driver is currently written, it assumes the transceiver is present and available - you don't need a separate driver to access it.
For that matter, the same probably holds for the OTG driver as well - you really don't need a driver for transparent transceivers like the SMSC332x.
But I get an OOPS and the system halts when I don't have a transceiver driver...
b.g.
Quoted 6 lines · Bill Gatliff
Quoted 5 lines · Anand
Actually, the way the ehci-omap driver is currently written, it assumes the transceiver is present and available - you don't need a separate driver to access it.
Quoted 6 lines
Quoted 3 lines
For that matter, the same probably holds for the OTG driver as well - you really don't need a driver for transparent transceivers like the SMSC332x.
But I get an OOPS and the system halts when I don't have a transceiver driver...
that smells like you're using the otg port.
Signature · 1 line
balbi
Quoted 5 lines · Bill Gatliff
Quoted 4 lines · Anand
Actually, the way the ehci-omap driver is currently written, it assumes the transceiver is present and available - you don't need a separate driver to access it.
Quoted 7 lines
Quoted 3 lines
For that matter, the same probably holds for the OTG driver as well - you really don't need a driver for transparent transceivers like the SMSC332x.
But I get an OOPS and the system halts when I don't have a transceiver driver...
Care to post a bootlog and your .config file? Maybe it's just a simple CONFIG option that you are missing?