Lines Matching full:and
12 within peripherals and other USB devices that embed Linux. It provides
13 an overview of the API structure, and shows how that fits into a system
26 and alternate interface settings.
31 - Sharing data structures and API models with the Linux-USB host side
32 API. This helps the OTG support, and looks forward to more-symmetric
33 frameworks (where the same I/O model is used by both host and device
47 driver is the master (or "client driver") and the gadget driver is the
51 queues of request objects to package I/O buffers, and those requests may
53 USB *Chapter 9* messages, structures, and constants. Also, both APIs
54 bind and unbind drivers to devices. The APIs differ in detail, since the
56 details and assumptions that are inappropriate for a gadget API. While
57 the model for control transfers and configuration management is
66 layers inside the kernel to handle USB protocol processing, and may have
75 to hardware, through registers, fifos, dma, irqs, and the like. The
78 objects, which accept streams of IN/OUT buffers, and through
86 (found within many PDAs), and a variety of other products.
91 hardware varies widely in capabilities and restrictions, and is used
104 - returning configuration and string descriptors
106 - (re)setting configurations and interface altsettings, including
107 enabling and configuring endpoints
110 hardware, USB suspend/resume, remote wakeup, and disconnection
113 - managing IN and OUT transfers on all currently enabled endpoints
121 data which the gadget driver produces and/or consumes through
131 test and measurement hardware.
141 - ... and more
147 ``read()`` and ``write()``. On newer systems, POSIX Async I/O calls may
154 List", and so forth. There will also be an *OTG Controller Driver*,
155 which is visible to gadget and device driver developers only indirectly.
156 That helps the host and device side USB controllers implement the two
157 new OTG protocols (HNP and SRP). Roles switch (host to peripheral, or
158 vice versa) using HNP during USB suspend processing, and SRP can be
163 from vectors of descriptors for the configurations interfaces and
164 endpoints is now automated, and many drivers now use autoconfiguration
165 to choose hardware endpoints and initialize their descriptors. A
181 the gadget, and submitting one or more struct usb_request buffers to
182 transfer data. Understand those four data types, and their operations,
183 and you will understand how this API works.
188 types and functions are described here.
192 autoconfiguration. You'll have to read the header file, and use
198 and upper kernel versions include a *driver model* framework that has
212 types, addressing, packet sizes, buffering, and availability. As a rule,
214 device configuration and management. The API supports limited run-time
224 of USB messages: I/O requests are in terms of one or more "packets", and
227 frame, multipoint addressing, host as the primary station and devices as
232 protocols where packet boundaries (and "short packets") are not
244 found in Linux PDAs, and so on. At this point the device is logically
245 in the USB ch9 initial state (``attached``), drawing no power and not
255 are to accept USB ``power`` and ``set_address`` requests. Other steps are
260 on what the bus interface hardware provides and on the functionality
275 6. Do real work and perform data transfers, possibly involving changes
278 requests to each endpoint. It may be suspended and resumed several
300 request, and the option to invoke HNP during some suspend callbacks.
303 USB 2.0 Chapter 9 Types and Constants
306 Gadget drivers rely on common USB structures and constants defined in
308 Linux 2.6+ kernels. These are the same types and constants used by host side
309 drivers (and usbcore).
311 Core Objects and Methods
314 These are declared in ``<linux/usb/gadget.h>``, and are used by gadget
337 (with more than one function in a given configuration), and also
340 framework which makes it easier to reuse and combine functions.
366 which supports USB 2.0 high speed and is based on PCI. This is the
368 and 2.6; contact NetChip Technologies for development boards and product
372 25x and IXP42x series processors (``pxa2xx_udc``), Toshiba TC86c001
376 (``lh7a40x_udc``), and more. Most of those are full speed controllers.
384 endpoints and device speeds; and it simulates control, bulk, and to some
386 driver on a normal PC, without any special hardware, and perhaps with
393 Support for other controllers is expected to be developed and
399 In addition to *Gadget Zero* (used primarily for testing and development
415 Pengutronix and Auerswald GmbH. This is like CDC Ethernet, but it runs
418 versions of Windows, using drivers that Microsoft bundles and supports,
423 file descriptor. I/O is done using normal ``read()`` and ``read()`` calls.
424 Familiar tools like GDB and pthreads can be used to develop and debug
431 solution for interoperability with systems such as MS-Windows and MacOS.
439 a USB modem, and so on most hardware it can interoperate easily with
444 Support for other kinds of gadget is expected to be developed and
451 Instruments for `OMAP <http://www.omap.com>`__ 16xx and 17xx series
456 including a special *Mini-AB* jack and associated transceiver to support
460 additions to those programming interfaces, and on a new internal
465 Such drivers need at most minor changes, and most of the calls added to
468 - Gadget drivers test the ``is_otg`` flag, and use it to determine
475 suffice), and is triggered in some cases when the host suspends the
490 Non-OTG Linux hosts, like PCs and workstations, normally have some
494 and where it's usually unrealistic to expect traditional
501 and :c:type:`usb_gadget` driver interfaces; those aren't discussed here in any
503 Peripheral controller, and how the HCD initializes (since OTG can be
505 *OTG Controller Driver*, managing the OTG transceiver and the OTG state
507 The OTG controller driver needs to activate and deactivate USB
510 and respond appropriately to HNP or SRP protocols.