Re: [linux-usb-devel] Re: Question about OTG operations
From: David Brownell [EMAIL PROTECTED] To: linux-usb-devel@lists.sourceforge.net CC: Steve Calfee [EMAIL PROTECTED] Subject: Re: [linux-usb-devel] Re: Question about OTG operations Date: Tue, 28 Feb 2006 23:42:35 -0800 On Tuesday 28 February 2006 11:03 pm, Steve Calfee wrote: Yes, it is a huge drawback to the spec. Being host does not say you provide power, being A connector does. How do you communicate the fact that your handheld can use and get power from a device if it is plugged in properly. That one's easy: there's now a battery powered device feature (from wireless usb). Use that ... What's harder is the other way around: I have power to spare, from the AC outlet. Because the handheld gadget would likely be the one to detect that case and suggest switching the cable. Of course one could apply heuristics too. Most printers have AC power, so if your handheld hooks up to an OTG printer in host role, and its battery is low enough, then suggest re-cabling. OTG printer? Presumably they exist by now ... It is very hard to find OTG devices. They also don't seem to be advertised even if a device supports OTG. Google shows some lists, many cameras, a few printers. A camera/printer pair makes sense because both can be devices to some PC, but maybe you would like to print directly from a camera, so OTG could handle that. Someone said that the Sony PSP (handheld game) was OTG, presumably mainly used to connect two PSPs for linked play. Probably having both A and B connectors is a more sane and clear indication of power and connections. I thought only hubs were allowed to do that, though... Think of a Linux PC with a gadget card. it has both A and B connectors and does not violate the USB bus topology because they are really on two USB buses. Increasingly many of the SOC chips now becoming available (such as the samsung s3c2410 ARM chip) have multiple device and host cores so being both a host and a device is quite possible. I have not seen one (yet) with a built in OTG phy, so you would have to use an external phy to do OTG. So as a system designer you could choose either or both of OTG or having both A and B connectors. Regards, Steve --- 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=lnkkid=110944bid=241720dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Question about OTG operations
FYI the original didn't make it to the list due to an HTML attachment. On Tue, 28 Feb 2006, David Brownell wrote: 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=lnkkid=110944bid=241720dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel -- /+-\ |Stephen J. Gowdy | SLAC, MailStop 34, | |http://www.slac.stanford.edu/~gowdy/ | 2575 Sand Hill Road, | |http://calendar.yahoo.com/gowdy | Menlo Park CA 94025, USA | |EMail: [EMAIL PROTECTED] | Tel: +1 650 926 3144 | \+-/ --- 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=lnkkid=110944bid=241720dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] 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. One other really useful aspect of OTG is power. If you have a battery powered device connecting to another powered device it is useful to have the A end pointed at the powered device. So for instance if you have a battery powered PC and wish to connect it to a powered printer or a display device it would be nice if the A connector goes into the peripheral and the b into the computer that way the computer would get power and the device could hand off the awesome responsibility of knowing what to do to the computer. Regards, Steve --- 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=lnkkid=110944bid=241720dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] Re: Question about OTG operations
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Calfee Sent: Wednesday, March 01, 2006 2:21 PM To: [EMAIL PROTECTED] Cc: linux-usb-devel@lists.sourceforge.net Subject: RE: [linux-usb-devel] 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. One other really useful aspect of OTG is power. If you have a battery powered device connecting to another powered device it is useful to have the A end pointed at the powered device. So for instance if you have a battery powered PC and wish to connect it to a powered printer or a display device it would be nice if the A connector goes into the peripheral and the b into the computer that way the computer would get power and the device could hand off the awesome responsibility of knowing what to do to the computer. That will need the user to plug the cable _correctly_. HNP won't change the responsibility of power supply to the bus. Is it a drawback of current OTG spec? Regards, Steve --- 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=lnkkid=110944bid=241720dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel --- 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=lnkkid=110944bid=241720dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Question about OTG operations
On Tuesday 28 February 2006 10:20 pm, Steve Calfee wrote: So for instance if you have a battery powered PC and wish to connect it to a powered printer or a display device it would be nice if the A connector goes into the peripheral and the b into the computer that way the computer would get power and the device could hand off the awesome responsibility of knowing what to do to the computer. That's a very interesting example ... though it'd work better with a battery powered PDA/phone/etc so it could also draw enough power to recharge its little battery! But I'm not entirely sure I'd expect most users to get that A-end of cable goes into the printer right. The best visual indicator is that the inside of that connector is white, not black; it's pretty subtle. - 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=lnkkid=110944bid=241720dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
RE: [linux-usb-devel] Re: Question about OTG operations
From: Li Yang-r58472 [EMAIL PROTECTED] To: Steve Calfee [EMAIL PROTECTED], [EMAIL PROTECTED] CC: linux-usb-devel@lists.sourceforge.net Subject: RE: [linux-usb-devel] Re: Question about OTG operations Date: Wed, 1 Mar 2006 14:44:31 +0800 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Calfee Sent: Wednesday, March 01, 2006 2:21 PM To: [EMAIL PROTECTED] Cc: linux-usb-devel@lists.sourceforge.net Subject: RE: [linux-usb-devel] 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. One other really useful aspect of OTG is power. If you have a battery powered device connecting to another powered device it is useful to have the A end pointed at the powered device. So for instance if you have a battery powered PC and wish to connect it to a powered printer or a display device it would be nice if the A connector goes into the peripheral and the b into the computer that way the computer would get power and the device could hand off the awesome responsibility of knowing what to do to the computer. That will need the user to plug the cable _correctly_. HNP won't change the responsibility of power supply to the bus. Is it a drawback of current OTG spec? Yes, it is a huge drawback to the spec. Being host does not say you provide power, being A connector does. How do you communicate the fact that your handheld can use and get power from a device if it is plugged in properly. I have seen more devices with both A and B connectors, but that do not have an OTG connector. However, the A device is only guaranteed to supply 8ma, so only a system involving both a battery powered pc and a powered device could even handle the obvious power handling used in OTG. Probably having both A and B connectors is a more sane and clear indication of power and connections. Regards, Steve --- 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=lnkkid=110944bid=241720dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Question about OTG operations
From: David Brownell [EMAIL PROTECTED] To: Steve Calfee [EMAIL PROTECTED] CC: linux-usb-devel@lists.sourceforge.net Subject: Re: [linux-usb-devel] Re: Question about OTG operations Date: Tue, 28 Feb 2006 22:46:42 -0800 On Tuesday 28 February 2006 10:20 pm, Steve Calfee wrote: So for instance if you have a battery powered PC and wish to connect it to a powered printer or a display device it would be nice if the A connector goes into the peripheral and the b into the computer that way the computer would get power and the device could hand off the awesome responsibility of knowing what to do to the computer. That's a very interesting example ... though it'd work better with a battery powered PDA/phone/etc so it could also draw enough power to recharge its little battery! But I'm not entirely sure I'd expect most users to get that A-end of cable goes into the printer right. The best visual indicator is that the inside of that connector is white, not black; it's pretty subtle. As I said to Leo: Yes, it is a huge drawback to the spec. Being host does not say you provide power, being A connector does. How do you communicate the fact that your handheld can use and get power from a device if it is plugged in properly. I have seen more devices with both A and B connectors, but that do not have an OTG connector. However, the A device is only guaranteed to supply 8ma, so only a system involving both a battery powered pc and a powered device could even handle the obvious power handling used in OTG. Probably having both A and B connectors is a more sane and clear indication of power and connections. Regards, Steve --- 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=lnkkid=110944bid=241720dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
Re: [linux-usb-devel] Re: Question about OTG operations
On Tuesday 28 February 2006 11:03 pm, Steve Calfee wrote: Yes, it is a huge drawback to the spec. Being host does not say you provide power, being A connector does. How do you communicate the fact that your handheld can use and get power from a device if it is plugged in properly. That one's easy: there's now a battery powered device feature (from wireless usb). Use that ... What's harder is the other way around: I have power to spare, from the AC outlet. Because the handheld gadget would likely be the one to detect that case and suggest switching the cable. Of course one could apply heuristics too. Most printers have AC power, so if your handheld hooks up to an OTG printer in host role, and its battery is low enough, then suggest re-cabling. OTG printer? Presumably they exist by now ... Probably having both A and B connectors is a more sane and clear indication of power and connections. I thought only hubs were allowed to do that, though... - 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=lnkkid=110944bid=241720dat=121642 ___ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
