On Tuesday 28 February 2006 7:44 pm, Li Yang-r58472 wrote: > Thanks Dave, > > So the current application of HNP is only to correct wrongly connected cable?
That's not what I said, but it _is_ the only scenario that's completely spelled out in the specs. Once HNP is enabled, if the host side interface driver(s) do stuff that causes device suspend, HNP will kick in. At this time, those Linux device drivers don't do that. It can be done from userspace using some power management primitives in sysfs; and custom drivers could do it, even though standard ones won't. So if you have OTG system design that wants to use HNP for more than that, you should already be set. Remember also that connecting two HNP-capable devices is going to be rare for some time ... and that's the only case where HNP applies. Billions of standard USB hosts and peripherals will never talk HNP. > 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. I think you mis-read both OTG and USB. There's still only one master at a time; HNP (and ID-pin sensing in Mini-AB sockets) means that devices don't need to be designed any more to serve just one role. I think end users will find that cable based role switching to be far more immediately useful. Smart gadgets will be able to talk to PCs, and also get much expansion capability for things like printers, standard keyboards, and expansion storage. The aftermarket for those fancy gadgets _could_ be pretty open, and from the end-user perspective that'd be a very nice thing. (Folk profiting from small/closed aftermarkets may disagree though...) As for peer-to-peer ... I've heard that said, but I don't buy it. It's not true at the hardware level, and at the software level there's never been a reason for application protocols to avoid peer-to-peer models. Here's one simple counter-example: since you can run peer-to-peer over TCP/IP stacks, and you can run TCP/IP over USB (in many ways), then clearly USB already supports peer-to-peer application models as well as, say, Ethernet. > 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? What, you mean "we, Freescale"? Start by providing Linux support, and then make it easy to productize Linux-based OTG systems. There's a technology issue there of course; and from a marketing perspective, feel free to push money into the hands of folk who will be doing that productization. :) My theory is that a critical mass of understanding hasn't yet developed among the folk who build such products. Many embedded environments only cover the peripheral role of USB (such as, last I looked, Symbian) and not the host role; that's a MAJOR difference in terms of user interfacing and end-user scenarios. (Linux has some of the converse problem.) That critical mass will develop once OTG-capable development platforms become more widely available. The effort to prototype OTG products will go down, and then OTG-based product concepts will naturally start to surface. Some will even be good enough to catch on. And then Fry's will finally have a reason to stock OTG cables! - Dave > > 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
