1<html><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.78.1"><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="gadget.html" title="Chapter 5. Gadget Drivers"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><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="gadget.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> </td></tr></table><hr></div><div class="chapter"><div class="titlepage"><div><div><h1 class="title"><a name="otg"></a>Chapter 6. USB On-The-GO (OTG)</h1></div></div></div><p>USB OTG support on Linux 2.6 was initially developed 2by Texas Instruments for 3<a class="ulink" href="http://www.omap.com" target="_top">OMAP</a> 16xx and 17xx 4series processors. 5Other OTG systems should work in similar ways, but the 6hardware level details could be very different. 7</p><p>Systems need specialized hardware support to implement OTG, 8notably including a special <span class="emphasis"><em>Mini-AB</em></span> jack 9and associated transceiver to support <span class="emphasis"><em>Dual-Role</em></span> 10operation: 11they can act either as a host, using the standard 12Linux-USB host side driver stack, 13or as a peripheral, using this "gadget" framework. 14To do that, the system software relies on small additions 15to those programming interfaces, 16and on a new internal component (here called an "OTG Controller") 17affecting which driver stack connects to the OTG port. 18In each role, the system can re-use the existing pool of 19hardware-neutral drivers, layered on top of the controller 20driver interfaces (<span class="emphasis"><em>usb_bus</em></span> or 21<span class="emphasis"><em>usb_gadget</em></span>). 22Such drivers need at most minor changes, and most of the calls 23added to support OTG can also benefit non-OTG products. 24</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>Gadget drivers test the <span class="emphasis"><em>is_otg</em></span> 25 flag, and use it to determine whether or not to include 26 an OTG descriptor in each of their configurations. 27 </p></li><li class="listitem"><p>Gadget drivers may need changes to support the 28 two new OTG protocols, exposed in new gadget attributes 29 such as <span class="emphasis"><em>b_hnp_enable</em></span> flag. 30 HNP support should be reported through a user interface 31 (two LEDs could suffice), and is triggered in some cases 32 when the host suspends the peripheral. 33 SRP support can be user-initiated just like remote wakeup, 34 probably by pressing the same button. 35 </p></li><li class="listitem"><p>On the host side, USB device drivers need 36 to be taught to trigger HNP at appropriate moments, using 37 <code class="function">usb_suspend_device()</code>. 38 That also conserves battery power, which is useful even 39 for non-OTG configurations. 40 </p></li><li class="listitem"><p>Also on the host side, a driver must support the 41 OTG "Targeted Peripheral List". That's just a whitelist, 42 used to reject peripherals not supported with a given 43 Linux OTG host. 44 <span class="emphasis"><em>This whitelist is product-specific; 45 each product must modify <code class="filename">otg_whitelist.h</code> 46 to match its interoperability specification. 47 </em></span> 48 </p><p>Non-OTG Linux hosts, like PCs and workstations, 49 normally have some solution for adding drivers, so that 50 peripherals that aren't recognized can eventually be supported. 51 That approach is unreasonable for consumer products that may 52 never have their firmware upgraded, and where it's usually 53 unrealistic to expect traditional PC/workstation/server kinds 54 of support model to work. 55 For example, it's often impractical to change device firmware 56 once the product has been distributed, so driver bugs can't 57 normally be fixed if they're found after shipment. 58 </p></li></ul></div><p> 59Additional changes are needed below those hardware-neutral 60<span class="emphasis"><em>usb_bus</em></span> and <span class="emphasis"><em>usb_gadget</em></span> 61driver interfaces; those aren't discussed here in any detail. 62Those affect the hardware-specific code for each USB Host or Peripheral 63controller, and how the HCD initializes (since OTG can be active only 64on a single port). 65They also involve what may be called an <span class="emphasis"><em>OTG Controller 66Driver</em></span>, managing the OTG transceiver and the OTG state 67machine logic as well as much of the root hub behavior for the 68OTG port. 69The OTG controller driver needs to activate and deactivate USB 70controllers depending on the relevant device role. 71Some related changes were needed inside usbcore, so that it 72can identify OTG-capable devices and respond appropriately 73to HNP or SRP protocols. 74</p></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="gadget.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> 75