Thanks Dave, So the current application of HNP is only to correct wrongly connected cable? I don't think it's the original target of adding OTG to USB. Though we don't have much examples of OTG usage in the market, I do think OTG is to add the peer-to-peer ability to the previous client/server USB architecture. Both sides have the ability to initialize connection and transmit. As more and more hand held devices are becoming PC alike, the peer-to-peer communication between them should be very useful. However, Bluetooth is also a good option for providing this. What do you think of the future of USB OTG? How can we drive it from the software point of view?
Best Regards, Leo > -----Original Message----- > From: David Brownell [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 01, 2006 6:04 AM > To: Li Yang-r58472 > Cc: linux-usb-devel@lists.sourceforge.net > Subject: Re: Question about OTG operations > > On Tuesday 28 February 2006 4:15 am, Li Yang-r58472 wrote: > > > > I'm doing OTG support on a Freescale PowerPC platform. > > The basic ID specified role change can work correctly. > > Good ... that's the first milestone! I'm assuming you're > using a 2.6.10 (or newer) kernel, since that's where the > first OTG implementation (for OMAP) was merged. If not, > then upgrade ASAP. > > > > However, when I dig into the HNP role change, I don't > > quite understand the operation mechanism for current > > OTG design. The HNP is triggered by host suspend, but > > current host stack doesn't seem to suspend automatically. > > See drivers/usb/core/hub.c in usb_new_device() ... > > - it checks devices for OTG descriptors, and sets > the host and peripheral side HNP capability bits > appropriately; > > - when the device isn't in the whitelist (a.k.a. the > "Targeted Peripherals List" of the OTG spec) then > it's either (a) suspended if it supports HNP, or > else (b) enumeration is aborted. > > That's all clearly #ifdef CONFIG_USB_OTG so it should > be easy to find. On the peripheral side it should all > be pretty automatic, both setting B_HNP_ENABLE feature > and then kicking in HNP when the peripheral is suspended. > > > > As far as I understand, the inputs of OTG state machine > > a_bus_drop, a_suspend_req, a_bus_req and b_bus_req should > > be set/cleared by high level application. > > For now we assume *_bus_req are true, though on the host > side drivers will eventually be able to suspend themselves > and thus implicitly clear their bus request. > > > > What is the proper interface to control these parameters > > according to the current design? > > Most of those are implicit; there's no requirement for any > explicit control. > > When we start seeing more OTG-enabled products or systems, > then we'll start learning more about what additional use > cases are important. > > - Dave ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
