Documentation/DocBook/device-drivers.tmpl

   1 <?xml version="1.0" encoding="UTF-8"?>
   2 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
   3         "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
   4
   5 <book id="LinuxDriversAPI">
   6  <bookinfo>
   7   <title>Linux Device Drivers</title>
   8
   9   <legalnotice>
  10    <para>
  11      This documentation is free software; you can redistribute
  12      it and/or modify it under the terms of the GNU General Public
  13      License as published by the Free Software Foundation; either
  14      version 2 of the License, or (at your option) any later
  15      version.
  16    </para>
  17
  18    <para>
  19      This program is distributed in the hope that it will be
  20      useful, but WITHOUT ANY WARRANTY; without even the implied
  21      warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
  22      See the GNU General Public License for more details.
  23    </para>
  24
  25    <para>
  26      You should have received a copy of the GNU General Public
  27      License along with this program; if not, write to the Free
  28      Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
  29      MA 02111-1307 USA
  30    </para>
  31
  32    <para>
  33      For more details see the file COPYING in the source
  34      distribution of Linux.
  35    </para>
  36   </legalnotice>
  37  </bookinfo>
  38
  39 <toc></toc>
  40
  41   <chapter id="Basics">
  42      <title>Driver Basics</title>
  43      <sect1><title>Driver Entry and Exit points</title>
  44 !Iinclude/linux/init.h
  45      </sect1>
  46
  47      <sect1><title>Atomic and pointer manipulation</title>
  48 !Iarch/x86/include/asm/atomic.h
  49      </sect1>
  50
  51      <sect1><title>Delaying, scheduling, and timer routines</title>
  52 !Iinclude/linux/sched.h
  53 !Ekernel/sched/core.c
  54 !Ikernel/sched/cpupri.c
  55 !Ikernel/sched/fair.c
  56 !Iinclude/linux/completion.h
  57 !Ekernel/time/timer.c
  58      </sect1>
  59      <sect1><title>Wait queues and Wake events</title>
  60 !Iinclude/linux/wait.h
  61 !Ekernel/sched/wait.c
  62      </sect1>
  63      <sect1><title>High-resolution timers</title>
  64 !Iinclude/linux/ktime.h
  65 !Iinclude/linux/hrtimer.h
  66 !Ekernel/time/hrtimer.c
  67      </sect1>
  68      <sect1><title>Workqueues and Kevents</title>
  69 !Iinclude/linux/workqueue.h
  70 !Ekernel/workqueue.c
  71      </sect1>
  72      <sect1><title>Internal Functions</title>
  73 !Ikernel/exit.c
  74 !Ikernel/signal.c
  75 !Iinclude/linux/kthread.h
  76 !Ekernel/kthread.c
  77      </sect1>
  78
  79      <sect1><title>Kernel objects manipulation</title>
  80 <!--
  81 X!Iinclude/linux/kobject.h
  82 -->
  83 !Elib/kobject.c
  84      </sect1>
  85
  86      <sect1><title>Kernel utility functions</title>
  87 !Iinclude/linux/kernel.h
  88 !Ekernel/printk/printk.c
  89 !Ekernel/panic.c
  90 !Ekernel/sys.c
  91 !Ekernel/rcu/srcu.c
  92 !Ekernel/rcu/tree.c
  93 !Ekernel/rcu/tree_plugin.h
  94 !Ekernel/rcu/update.c
  95      </sect1>
  96
  97      <sect1><title>Device Resource Management</title>
  98 !Edrivers/base/devres.c
  99      </sect1>
 100
 101   </chapter>
 102
 103   <chapter id="devdrivers">
 104      <title>Device drivers infrastructure</title>
 105      <sect1><title>The Basic Device Driver-Model Structures </title>
 106 !Iinclude/linux/device.h
 107      </sect1>
 108      <sect1><title>Device Drivers Base</title>
 109 !Idrivers/base/init.c
 110 !Edrivers/base/driver.c
 111 !Edrivers/base/core.c
 112 !Edrivers/base/syscore.c
 113 !Edrivers/base/class.c
 114 !Idrivers/base/node.c
 115 !Edrivers/base/firmware_class.c
 116 !Edrivers/base/transport_class.c
 117 <!-- Cannot be included, because
 118      attribute_container_add_class_device_adapter
 119  and attribute_container_classdev_to_container
 120      exceed allowed 44 characters maximum
 121 X!Edrivers/base/attribute_container.c
 122 -->
 123 !Edrivers/base/dd.c
 124 <!--
 125 X!Edrivers/base/interface.c
 126 -->
 127 !Iinclude/linux/platform_device.h
 128 !Edrivers/base/platform.c
 129 !Edrivers/base/bus.c
 130      </sect1>
 131      <sect1><title>Device Drivers DMA Management</title>
 132 !Edrivers/dma-buf/dma-buf.c
 133 !Edrivers/dma-buf/fence.c
 134 !Edrivers/dma-buf/seqno-fence.c
 135 !Iinclude/linux/fence.h
 136 !Iinclude/linux/seqno-fence.h
 137 !Edrivers/dma-buf/reservation.c
 138 !Iinclude/linux/reservation.h
 139 !Edrivers/base/dma-coherent.c
 140 !Edrivers/base/dma-mapping.c
 141      </sect1>
 142      <sect1><title>Device Drivers Power Management</title>
 143 !Edrivers/base/power/main.c
 144      </sect1>
 145      <sect1><title>Device Drivers ACPI Support</title>
 146 <!-- Internal functions only
 147 X!Edrivers/acpi/sleep/main.c
 148 X!Edrivers/acpi/sleep/wakeup.c
 149 X!Edrivers/acpi/motherboard.c
 150 X!Edrivers/acpi/bus.c
 151 -->
 152 !Edrivers/acpi/scan.c
 153 !Idrivers/acpi/scan.c
 154 <!-- No correct structured comments
 155 X!Edrivers/acpi/pci_bind.c
 156 -->
 157      </sect1>
 158      <sect1><title>Device drivers PnP support</title>
 159 !Idrivers/pnp/core.c
 160 <!-- No correct structured comments
 161 X!Edrivers/pnp/system.c
 162  -->
 163 !Edrivers/pnp/card.c
 164 !Idrivers/pnp/driver.c
 165 !Edrivers/pnp/manager.c
 166 !Edrivers/pnp/support.c
 167      </sect1>
 168      <sect1><title>Userspace IO devices</title>
 169 !Edrivers/uio/uio.c
 170 !Iinclude/linux/uio_driver.h
 171      </sect1>
 172   </chapter>
 173
 174   <chapter id="parportdev">
 175      <title>Parallel Port Devices</title>
 176 !Iinclude/linux/parport.h
 177 !Edrivers/parport/ieee1284.c
 178 !Edrivers/parport/share.c
 179 !Idrivers/parport/daisy.c
 180   </chapter>
 181
 182   <chapter id="message_devices">
 183         <title>Message-based devices</title>
 184      <sect1><title>Fusion message devices</title>
 185 !Edrivers/message/fusion/mptbase.c
 186 !Idrivers/message/fusion/mptbase.c
 187 !Edrivers/message/fusion/mptscsih.c
 188 !Idrivers/message/fusion/mptscsih.c
 189 !Idrivers/message/fusion/mptctl.c
 190 !Idrivers/message/fusion/mptspi.c
 191 !Idrivers/message/fusion/mptfc.c
 192 !Idrivers/message/fusion/mptlan.c
 193      </sect1>
 194   </chapter>
 195
 196   <chapter id="snddev">
 197      <title>Sound Devices</title>
 198 !Iinclude/sound/core.h
 199 !Esound/sound_core.c
 200 !Iinclude/sound/pcm.h
 201 !Esound/core/pcm.c
 202 !Esound/core/device.c
 203 !Esound/core/info.c
 204 !Esound/core/rawmidi.c
 205 !Esound/core/sound.c
 206 !Esound/core/memory.c
 207 !Esound/core/pcm_memory.c
 208 !Esound/core/init.c
 209 !Esound/core/isadma.c
 210 !Esound/core/control.c
 211 !Esound/core/pcm_lib.c
 212 !Esound/core/hwdep.c
 213 !Esound/core/pcm_native.c
 214 !Esound/core/memalloc.c
 215 <!-- FIXME: Removed for now since no structured comments in source
 216 X!Isound/sound_firmware.c
 217 -->
 218   </chapter>
 219
 220   <chapter id="mediadev">
 221      <title>Media Devices</title>
 222
 223      <sect1><title>Video2Linux devices</title>
 224 !Iinclude/media/tuner.h
 225 !Iinclude/media/tuner-types.h
 226 !Iinclude/media/tveeprom.h
 227 !Iinclude/media/v4l2-async.h
 228 !Iinclude/media/v4l2-ctrls.h
 229 !Iinclude/media/v4l2-dv-timings.h
 230 !Iinclude/media/v4l2-event.h
 231 !Iinclude/media/v4l2-flash-led-class.h
 232 !Iinclude/media/v4l2-mediabus.h
 233 !Iinclude/media/v4l2-mem2mem.h
 234 !Iinclude/media/v4l2-of.h
 235 !Iinclude/media/v4l2-subdev.h
 236 !Iinclude/media/videobuf2-core.h
 237 !Iinclude/media/videobuf2-v4l2.h
 238 !Iinclude/media/videobuf2-memops.h
 239      </sect1>
 240      <sect1><title>Digital TV (DVB) devices</title>
 241 !Idrivers/media/dvb-core/dvb_ca_en50221.h
 242 !Idrivers/media/dvb-core/dvb_frontend.h
 243 !Idrivers/media/dvb-core/dvb_math.h
 244 !Idrivers/media/dvb-core/dvb_ringbuffer.h
 245 !Idrivers/media/dvb-core/dvbdev.h
 246         <sect1><title>Digital TV Demux API</title>
 247             <para>The kernel demux API defines a driver-internal interface for
 248             registering low-level, hardware specific driver to a hardware
 249             independent demux layer. It is only of interest for Digital TV
 250             device driver writers. The header file for this API is named
 251             <constant>demux.h</constant> and located in
 252             <constant>drivers/media/dvb-core</constant>.</para>
 253
 254         <para>The demux API should be implemented for each demux in the
 255         system. It is used to select the TS source of a demux and to manage
 256         the demux resources. When the demux client allocates a resource via
 257         the demux API, it receives a pointer to the API of that
 258         resource.</para>
 259         <para>Each demux receives its TS input from a DVB front-end or from
 260         memory, as set via this demux API. In a system with more than one
 261         front-end, the API can be used to select one of the DVB front-ends
 262         as a TS source for a demux, unless this is fixed in the HW platform.
 263         The demux API only controls front-ends regarding to their connections
 264         with demuxes; the APIs used to set the other front-end parameters,
 265         such as tuning, are not defined in this document.</para>
 266         <para>The functions that implement the abstract interface demux should
 267         be defined static or module private and registered to the Demux
 268         core for external access. It is not necessary to implement every
 269         function in the struct <constant>dmx_demux</constant>. For example,
 270         a demux interface might support Section filtering, but not PES
 271         filtering. The API client is expected to check the value of any
 272         function pointer before calling the function: the value of NULL means
 273         that the &#8220;function is not available&#8221;.</para>
 274         <para>Whenever the functions of the demux API modify shared data,
 275         the possibilities of lost update and race condition problems should
 276         be addressed, e.g. by protecting parts of code with mutexes.</para>
 277         <para>Note that functions called from a bottom half context must not
 278         sleep. Even a simple memory allocation without using GFP_ATOMIC can
 279         result in a kernel thread being put to sleep if swapping is needed.
 280         For example, the Linux kernel calls the functions of a network device
 281         interface from a bottom half context. Thus, if a demux API function
 282         is called from network device code, the function must not sleep.
 283         </para>
 284     </sect1>
 285
 286     <section id="demux_callback_api">
 287         <title>Demux Callback API</title>
 288         <para>This kernel-space API comprises the callback functions that
 289         deliver filtered data to the demux client. Unlike the other DVB
 290         kABIs, these functions are provided by the client and called from
 291         the demux code.</para>
 292         <para>The function pointers of this abstract interface are not
 293         packed into a structure as in the other demux APIs, because the
 294         callback functions are registered and used independent of each
 295         other. As an example, it is possible for the API client to provide
 296         several callback functions for receiving TS packets and no
 297         callbacks for PES packets or sections.</para>
 298         <para>The functions that implement the callback API need not be
 299         re-entrant: when a demux driver calls one of these functions,
 300         the driver is not allowed to call the function again before
 301         the original call returns. If a callback is triggered by a
 302         hardware interrupt, it is recommended to use the Linux
 303         &#8220;bottom half&#8221; mechanism or start a tasklet instead of
 304         making the callback function call directly from a hardware
 305         interrupt.</para>
 306         <para>This mechanism is implemented by
 307         <link linkend='API-dmx-ts-cb'>dmx_ts_cb()</link> and
 308         <link linkend='API-dmx-section-cb'>dmx_section_cb()</link>.</para>
 309     </section>
 310
 311 !Idrivers/media/dvb-core/demux.h
 312     </sect1>
 313     <sect1><title>Remote Controller devices</title>
 314 !Iinclude/media/rc-core.h
 315 !Iinclude/media/lirc_dev.h
 316     </sect1>
 317     <sect1><title>Media Controller devices</title>
 318 !Iinclude/media/media-device.h
 319 !Iinclude/media/media-devnode.h
 320 !Iinclude/media/media-entity.h
 321     </sect1>
 322
 323   </chapter>
 324
 325   <chapter id="uart16x50">
 326      <title>16x50 UART Driver</title>
 327 !Edrivers/tty/serial/serial_core.c
 328 !Edrivers/tty/serial/8250/8250_core.c
 329   </chapter>
 330
 331   <chapter id="fbdev">
 332      <title>Frame Buffer Library</title>
 333
 334      <para>
 335        The frame buffer drivers depend heavily on four data structures.
 336        These structures are declared in include/linux/fb.h.  They are
 337        fb_info, fb_var_screeninfo, fb_fix_screeninfo and fb_monospecs.
 338        The last three can be made available to and from userland.
 339      </para>
 340
 341      <para>
 342        fb_info defines the current state of a particular video card.
 343        Inside fb_info, there exists a fb_ops structure which is a
 344        collection of needed functions to make fbdev and fbcon work.
 345        fb_info is only visible to the kernel.
 346      </para>
 347
 348      <para>
 349        fb_var_screeninfo is used to describe the features of a video card
 350        that are user defined.  With fb_var_screeninfo, things such as
 351        depth and the resolution may be defined.
 352      </para>
 353
 354      <para>
 355        The next structure is fb_fix_screeninfo. This defines the
 356        properties of a card that are created when a mode is set and can't
 357        be changed otherwise.  A good example of this is the start of the
 358        frame buffer memory.  This "locks" the address of the frame buffer
 359        memory, so that it cannot be changed or moved.
 360      </para>
 361
 362      <para>
 363        The last structure is fb_monospecs. In the old API, there was
 364        little importance for fb_monospecs. This allowed for forbidden things
 365        such as setting a mode of 800x600 on a fix frequency monitor. With
 366        the new API, fb_monospecs prevents such things, and if used
 367        correctly, can prevent a monitor from being cooked.  fb_monospecs
 368        will not be useful until kernels 2.5.x.
 369      </para>
 370
 371      <sect1><title>Frame Buffer Memory</title>
 372 !Edrivers/video/fbdev/core/fbmem.c
 373      </sect1>
 374 <!--
 375      <sect1><title>Frame Buffer Console</title>
 376 X!Edrivers/video/console/fbcon.c
 377      </sect1>
 378 -->
 379      <sect1><title>Frame Buffer Colormap</title>
 380 !Edrivers/video/fbdev/core/fbcmap.c
 381      </sect1>
 382 <!-- FIXME:
 383   drivers/video/fbgen.c has no docs, which stuffs up the sgml.  Comment
 384   out until somebody adds docs.  KAO
 385      <sect1><title>Frame Buffer Generic Functions</title>
 386 X!Idrivers/video/fbgen.c
 387      </sect1>
 388 KAO -->
 389      <sect1><title>Frame Buffer Video Mode Database</title>
 390 !Idrivers/video/fbdev/core/modedb.c
 391 !Edrivers/video/fbdev/core/modedb.c
 392      </sect1>
 393      <sect1><title>Frame Buffer Macintosh Video Mode Database</title>
 394 !Edrivers/video/fbdev/macmodes.c
 395      </sect1>
 396      <sect1><title>Frame Buffer Fonts</title>
 397         <para>
 398            Refer to the file lib/fonts/fonts.c for more information.
 399         </para>
 400 <!-- FIXME: Removed for now since no structured comments in source
 401 X!Ilib/fonts/fonts.c
 402 -->
 403      </sect1>
 404   </chapter>
 405
 406   <chapter id="input_subsystem">
 407      <title>Input Subsystem</title>
 408      <sect1><title>Input core</title>
 409 !Iinclude/linux/input.h
 410 !Edrivers/input/input.c
 411 !Edrivers/input/ff-core.c
 412 !Edrivers/input/ff-memless.c
 413      </sect1>
 414      <sect1><title>Multitouch Library</title>
 415 !Iinclude/linux/input/mt.h
 416 !Edrivers/input/input-mt.c
 417      </sect1>
 418      <sect1><title>Polled input devices</title>
 419 !Iinclude/linux/input-polldev.h
 420 !Edrivers/input/input-polldev.c
 421      </sect1>
 422      <sect1><title>Matrix keyboars/keypads</title>
 423 !Iinclude/linux/input/matrix_keypad.h
 424      </sect1>
 425      <sect1><title>Sparse keymap support</title>
 426 !Iinclude/linux/input/sparse-keymap.h
 427 !Edrivers/input/sparse-keymap.c
 428      </sect1>
 429   </chapter>
 430
 431   <chapter id="spi">
 432       <title>Serial Peripheral Interface (SPI)</title>
 433   <para>
 434         SPI is the "Serial Peripheral Interface", widely used with
 435         embedded systems because it is a simple and efficient
 436         interface:  basically a multiplexed shift register.
 437         Its three signal wires hold a clock (SCK, often in the range
 438         of 1-20 MHz), a "Master Out, Slave In" (MOSI) data line, and
 439         a "Master In, Slave Out" (MISO) data line.
 440         SPI is a full duplex protocol; for each bit shifted out the
 441         MOSI line (one per clock) another is shifted in on the MISO line.
 442         Those bits are assembled into words of various sizes on the
 443         way to and from system memory.
 444         An additional chipselect line is usually active-low (nCS);
 445         four signals are normally used for each peripheral, plus
 446         sometimes an interrupt.
 447   </para>
 448   <para>
 449         The SPI bus facilities listed here provide a generalized
 450         interface to declare SPI busses and devices, manage them
 451         according to the standard Linux driver model, and perform
 452         input/output operations.
 453         At this time, only "master" side interfaces are supported,
 454         where Linux talks to SPI peripherals and does not implement
 455         such a peripheral itself.
 456         (Interfaces to support implementing SPI slaves would
 457         necessarily look different.)
 458   </para>
 459   <para>
 460         The programming interface is structured around two kinds of driver,
 461         and two kinds of device.
 462         A "Controller Driver" abstracts the controller hardware, which may
 463         be as simple as a set of GPIO pins or as complex as a pair of FIFOs
 464         connected to dual DMA engines on the other side of the SPI shift
 465         register (maximizing throughput).  Such drivers bridge between
 466         whatever bus they sit on (often the platform bus) and SPI, and
 467         expose the SPI side of their device as a
 468         <structname>struct spi_master</structname>.
 469         SPI devices are children of that master, represented as a
 470         <structname>struct spi_device</structname> and manufactured from
 471         <structname>struct spi_board_info</structname> descriptors which
 472         are usually provided by board-specific initialization code.
 473         A <structname>struct spi_driver</structname> is called a
 474         "Protocol Driver", and is bound to a spi_device using normal
 475         driver model calls.
 476   </para>
 477   <para>
 478         The I/O model is a set of queued messages.  Protocol drivers
 479         submit one or more <structname>struct spi_message</structname>
 480         objects, which are processed and completed asynchronously.
 481         (There are synchronous wrappers, however.)  Messages are
 482         built from one or more <structname>struct spi_transfer</structname>
 483         objects, each of which wraps a full duplex SPI transfer.
 484         A variety of protocol tweaking options are needed, because
 485         different chips adopt very different policies for how they
 486         use the bits transferred with SPI.
 487   </para>
 488 !Iinclude/linux/spi/spi.h
 489 !Fdrivers/spi/spi.c spi_register_board_info
 490 !Edrivers/spi/spi.c
 491   </chapter>
 492
 493   <chapter id="i2c">
 494      <title>I<superscript>2</superscript>C and SMBus Subsystem</title>
 495
 496      <para>
 497         I<superscript>2</superscript>C (or without fancy typography, "I2C")
 498         is an acronym for the "Inter-IC" bus, a simple bus protocol which is
 499         widely used where low data rate communications suffice.
 500         Since it's also a licensed trademark, some vendors use another
 501         name (such as "Two-Wire Interface", TWI) for the same bus.
 502         I2C only needs two signals (SCL for clock, SDA for data), conserving
 503         board real estate and minimizing signal quality issues.
 504         Most I2C devices use seven bit addresses, and bus speeds of up
 505         to 400 kHz; there's a high speed extension (3.4 MHz) that's not yet
 506         found wide use.
 507         I2C is a multi-master bus; open drain signaling is used to
 508         arbitrate between masters, as well as to handshake and to
 509         synchronize clocks from slower clients.
 510      </para>
 511
 512      <para>
 513         The Linux I2C programming interfaces support only the master
 514         side of bus interactions, not the slave side.
 515         The programming interface is structured around two kinds of driver,
 516         and two kinds of device.
 517         An I2C "Adapter Driver" abstracts the controller hardware; it binds
 518         to a physical device (perhaps a PCI device or platform_device) and
 519         exposes a <structname>struct i2c_adapter</structname> representing
 520         each I2C bus segment it manages.
 521         On each I2C bus segment will be I2C devices represented by a
 522         <structname>struct i2c_client</structname>.  Those devices will
 523         be bound to a <structname>struct i2c_driver</structname>,
 524         which should follow the standard Linux driver model.
 525         (At this writing, a legacy model is more widely used.)
 526         There are functions to perform various I2C protocol operations; at
 527         this writing all such functions are usable only from task context.
 528      </para>
 529
 530      <para>
 531         The System Management Bus (SMBus) is a sibling protocol.  Most SMBus
 532         systems are also I2C conformant.  The electrical constraints are
 533         tighter for SMBus, and it standardizes particular protocol messages
 534         and idioms.  Controllers that support I2C can also support most
 535         SMBus operations, but SMBus controllers don't support all the protocol
 536         options that an I2C controller will.
 537         There are functions to perform various SMBus protocol operations,
 538         either using I2C primitives or by issuing SMBus commands to
 539         i2c_adapter devices which don't support those I2C operations.
 540      </para>
 541
 542 !Iinclude/linux/i2c.h
 543 !Fdrivers/i2c/i2c-boardinfo.c i2c_register_board_info
 544 !Edrivers/i2c/i2c-core.c
 545   </chapter>
 546
 547   <chapter id="hsi">
 548      <title>High Speed Synchronous Serial Interface (HSI)</title>
 549
 550      <para>
 551         High Speed Synchronous Serial Interface (HSI) is a
 552         serial interface mainly used for connecting application
 553         engines (APE) with cellular modem engines (CMT) in cellular
 554         handsets.
 555
 556         HSI provides multiplexing for up to 16 logical channels,
 557         low-latency and full duplex communication.
 558      </para>
 559
 560 !Iinclude/linux/hsi/hsi.h
 561 !Edrivers/hsi/hsi.c
 562   </chapter>
 563
 564   <chapter id="pwm">
 565     <title>Pulse-Width Modulation (PWM)</title>
 566     <para>
 567       Pulse-width modulation is a modulation technique primarily used to
 568       control power supplied to electrical devices.
 569     </para>
 570     <para>
 571       The PWM framework provides an abstraction for providers and consumers
 572       of PWM signals. A controller that provides one or more PWM signals is
 573       registered as <structname>struct pwm_chip</structname>. Providers are
 574       expected to embed this structure in a driver-specific structure. This
 575       structure contains fields that describe a particular chip.
 576     </para>
 577     <para>
 578       A chip exposes one or more PWM signal sources, each of which exposed
 579       as a <structname>struct pwm_device</structname>. Operations can be
 580       performed on PWM devices to control the period, duty cycle, polarity
 581       and active state of the signal.
 582     </para>
 583     <para>
 584       Note that PWM devices are exclusive resources: they can always only be
 585       used by one consumer at a time.
 586     </para>
 587 !Iinclude/linux/pwm.h
 588 !Edrivers/pwm/core.c
 589   </chapter>
 590
 591 </book>