> -----Original Message----- > From: David Brownell [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 01, 2006 12:59 PM > To: Li Yang-r58472 > Cc: linux-usb-devel@lists.sourceforge.net > Subject: Re: Question about OTG operations > > 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. > You are right. It helps me understanding. > > > > 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. :) I mean contributors to open source. :P I'm not a marketing guy. But as far as I know most companies like to think in a different way. They look at the features Linux already have. If Linux meet their expectation they choose Linux. Otherwise they develop their own system or buy commercial solutions. I do hope Linux can have a better business model to make money (of coz making contributors' life much easier). :) > > 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! Yup. If there are some ready (or almost ready) solutions around, it will be easier for device makers to choose OTG. >
> > - 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
