Hi Peter, On Tue, Aug 02, 2011 at 10:18:51AM +0800, Peter Chen wrote: > On Mon, Aug 01, 2011 at 05:29:13PM +0300, Heikki Krogerus wrote: > Great ideas. So is it right that your OTG framework like below: > > otg > | otg.c > | vendor_otg.c > | phy.c > | vendor_utmi.c > | vendor_ulpi.c > gadget > |vendor_udc.c > host > |ehci-vendor.c > > gadget/host's platform suspend/resume routine can call phy's suspend/resume. > My questions are: > - The vendor_utmi.c will call usb_register_transceiver to register a phy, > how host matches a specific phys? At some platform, the otg host uses utmi, > but the host only port uses external ulpi phys. Interesting case. Do you mean that this platform has both a host only port and an otg port, or that this platform may come with host only port _or_ otg? How is it handled now? > - Usually, charger detect routine should be before bus enumeration due to > pullup dp will be used to detect charger. How your usb_charger_work co-work > with vendor_udc.c? The charger expects that the udc drivers have filled the link_connect and the link_data members. If you look at the usb_charger_work() you will see that with SDP and CDP the code always tries to call the link_connect hook after detection. Br, -- heikki -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
