> There will be three separate drivers: host, client, otg transceiver > (for ULPI system not a really transceiver driver).
Rather than "transceiver" driver, I'd say "OTG" driver ... the thing responsible for role detection and switching. So for drivers that touch hardware, (a) OTG driver, (b) HCD, and (c) peripheral controller drivers. Plus (d) a gadget driver, talking to a host through that peripheral controller driver, and (e) two or more "usb device drivers" on the host side, including the hub driver. (You need to support at least root hubs. OTG of course doesn't require supporting external hubs, but for EHCI or OHCI there'd be no point in trying to remove that capability.) > User chooses what functions to use by configure kernel or selectively > insert modules. If user only load host/gadget driver, the board will act > as solely host/device. Actually there is CONFIG_USB_OTG which is needed to enable OTG behavior during host-side enumeration, like updating peripheral HNP state. And when OTG is enabled, the OTG driver had better do _nothing_ until both host and peripheral drivers are fully active ... you could use hotplug to load the (e) host side drivers, but not the (d) gadget driver unless you can somehow guarantee it modprobes quickly enough to meet the enumeration timing constraints. > If the otg driver is loaded, each host/gadget > driver will register themselves to the otg driver. Otg driver will use > suspend() function to set both controller drivers to stop state until > otg driver determines which driver to take control. Using suspend() is probably not going to work as well as it should because of the general lack of runtime PM support in Linux. I'd certainly expect the (b) HCD and (c) peripheral controller drivers to stay inactive until they're needed, but just how that's arranged could be up to some private agreement between those collaborating drivers. > OTG state machine will be maintained and accessible in otg driver only, > and otg driver will use standard xhci/gadget operations to control > host/client through state changes. No, the OTG states are visible outside the OTG driver. See for example the HNP state flags in usb_bus and usb_gadget. And it's usbcore that causes those state flags to change. The specific state may not be represented outside that OTG driver though. > Assume there is a role change. For > device mode, it initializes hardware and waits for reset. For host mode, > how to trigger reset and enumeration? By "role change" you must mean HNP, since the other cases are nothing more than normal enumeration. (With OTG driver sensing the state of the ID pin, using it to activate the right driver.) HNP is initiated by the host, when it suspends the device after HNP has been enabled. Maybe because the peripheral isn't on the list of supported devices, or maybe it's just done using the peripheral. > If the host/client/otg use only one interrupt, should it be processed with > shared irq or centralized in otg driver and designate to special handler? That's an implementation-specific choice. Do what's most natural. - Dave ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
