<?xml version="1.0" encoding="ANSI_X3.4-1968" standalone="no"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=ANSI_X3.4-1968" /><title>Chapter 6. USB On-The-GO (OTG)</title><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /><link rel="home" href="index.html" title="USB Gadget API for Linux" /><link rel="up" href="index.html" title="USB Gadget API for Linux" /><link rel="prev" href="ch05.html" title="Chapter 5. Gadget Drivers" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 6. USB On-The-GO (OTG)</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="ch05.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> </td></tr></table><hr /></div><div class="chapter" title="Chapter 6. USB On-The-GO (OTG)"><div class="titlepage"><div><div><h2 class="title"><a id="otg"></a>Chapter 6. USB On-The-GO (OTG)</h2></div></div></div><p>USB OTG support on Linux 2.6 was initially developed by Texas Instruments for <a class="ulink" href="http://www.omap.com" target="_top">OMAP</a> 16xx and 17xx series processors. Other OTG systems should work in similar ways, but the hardware level details could be very different. </p><p>Systems need specialized hardware support to implement OTG, notably including a special <span class="emphasis"><em>Mini-AB</em></span> jack and associated transciever to support <span class="emphasis"><em>Dual-Role</em></span> operation: they can act either as a host, using the standard Linux-USB host side driver stack, or as a peripheral, using this "gadget" framework. To do that, the system software relies on small additions to those programming interfaces, and on a new internal component (here called an "OTG Controller") affecting which driver stack connects to the OTG port. In each role, the system can re-use the existing pool of hardware-neutral drivers, layered on top of the controller driver interfaces (<span class="emphasis"><em>usb_bus</em></span> or <span class="emphasis"><em>usb_gadget</em></span>). Such drivers need at most minor changes, and most of the calls added to support OTG can also benefit non-OTG products. </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>Gadget drivers test the <span class="emphasis"><em>is_otg</em></span> flag, and use it to determine whether or not to include an OTG descriptor in each of their configurations. </p></li><li class="listitem"><p>Gadget drivers may need changes to support the two new OTG protocols, exposed in new gadget attributes such as <span class="emphasis"><em>b_hnp_enable</em></span> flag. HNP support should be reported through a user interface (two LEDs could suffice), and is triggered in some cases when the host suspends the peripheral. SRP support can be user-initiated just like remote wakeup, probably by pressing the same button. </p></li><li class="listitem"><p>On the host side, USB device drivers need to be taught to trigger HNP at appropriate moments, using <code class="function">usb_suspend_device()</code>. That also conserves battery power, which is useful even for non-OTG configurations. </p></li><li class="listitem"><p>Also on the host side, a driver must support the OTG "Targeted Peripheral List". That's just a whitelist, used to reject peripherals not supported with a given Linux OTG host. <span class="emphasis"><em>This whitelist is product-specific; each product must modify <code class="filename">otg_whitelist.h</code> to match its interoperability specification. </em></span> </p><p>Non-OTG Linux hosts, like PCs and workstations, normally have some solution for adding drivers, so that peripherals that aren't recognized can eventually be supported. That approach is unreasonable for consumer products that may never have their firmware upgraded, and where it's usually unrealistic to expect traditional PC/workstation/server kinds of support model to work. For example, it's often impractical to change device firmware once the product has been distributed, so driver bugs can't normally be fixed if they're found after shipment. </p></li></ul></div><p> Additional changes are needed below those hardware-neutral <span class="emphasis"><em>usb_bus</em></span> and <span class="emphasis"><em>usb_gadget</em></span> driver interfaces; those aren't discussed here in any detail. Those affect the hardware-specific code for each USB Host or Peripheral controller, and how the HCD initializes (since OTG can be active only on a single port). They also involve what may be called an <span class="emphasis"><em>OTG Controller Driver</em></span>, managing the OTG transceiver and the OTG state machine logic as well as much of the root hub behavior for the OTG port. The OTG controller driver needs to activate and deactivate USB controllers depending on the relevant device role. Some related changes were needed inside usbcore, so that it can identify OTG-capable devices and respond appropriately to HNP or SRP protocols. </p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ch05.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> </td></tr><tr><td width="40%" align="left" valign="top">Chapter 5. Gadget Drivers </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> </td></tr></table></div></body></html>
