diff options
Diffstat (limited to 'Documentation/sound')
| -rw-r--r-- | Documentation/sound/cards/audigy-mixer.rst | 2 | ||||
| -rw-r--r-- | Documentation/sound/cards/sb-live-mixer.rst | 2 | ||||
| -rw-r--r-- | Documentation/sound/designs/timestamping.rst | 2 | ||||
| -rw-r--r-- | Documentation/sound/designs/tracepoints.rst | 22 | ||||
| -rw-r--r-- | Documentation/sound/kernel-api/alsa-driver-api.rst | 1 | ||||
| -rw-r--r-- | Documentation/sound/kernel-api/writing-an-alsa-driver.rst | 110 |
6 files changed, 64 insertions, 75 deletions
diff --git a/Documentation/sound/cards/audigy-mixer.rst b/Documentation/sound/cards/audigy-mixer.rst index 998f76e19cdd..f3f4640ee2af 100644 --- a/Documentation/sound/cards/audigy-mixer.rst +++ b/Documentation/sound/cards/audigy-mixer.rst @@ -332,7 +332,7 @@ WO 9901953 (A1) US Patents (https://www.uspto.gov/) ----------------------------------- +----------------------------------- US 5925841 Digital Sampling Instrument employing cache memory (Jul. 20, 1999) diff --git a/Documentation/sound/cards/sb-live-mixer.rst b/Documentation/sound/cards/sb-live-mixer.rst index eccb0f0ffd0f..2ce41d3822d8 100644 --- a/Documentation/sound/cards/sb-live-mixer.rst +++ b/Documentation/sound/cards/sb-live-mixer.rst @@ -337,7 +337,7 @@ WO 9901953 (A1) US Patents (https://www.uspto.gov/) ----------------------------------- +----------------------------------- US 5925841 Digital Sampling Instrument employing cache memory (Jul. 20, 1999) diff --git a/Documentation/sound/designs/timestamping.rst b/Documentation/sound/designs/timestamping.rst index 2b0fff503415..7c7ecf5dbc4b 100644 --- a/Documentation/sound/designs/timestamping.rst +++ b/Documentation/sound/designs/timestamping.rst @@ -143,7 +143,7 @@ timestamp shows when the information is put together by the driver before returning from the ``STATUS`` and ``STATUS_EXT`` ioctl. in most cases this driver_timestamp will be identical to the regular system tstamp. -Examples of typestamping with HDaudio: +Examples of timestamping with HDAudio: 1. DMA timestamp, no compensation for DMA+analog delay :: diff --git a/Documentation/sound/designs/tracepoints.rst b/Documentation/sound/designs/tracepoints.rst index 78bc5572f829..b0a7e3010187 100644 --- a/Documentation/sound/designs/tracepoints.rst +++ b/Documentation/sound/designs/tracepoints.rst @@ -34,20 +34,20 @@ substream. In this procedure, PCM hardware parameters are decided by interaction between applications and ALSA PCM core. Once decided, runtime of the PCM substream keeps the parameters. -The parameters are described in :c:type:`struct snd_pcm_hw_params`. This +The parameters are described in struct snd_pcm_hw_params. This structure includes several types of parameters. Applications set preferable value to these parameters, then execute ioctl(2) with SNDRV_PCM_IOCTL_HW_REFINE or SNDRV_PCM_IOCTL_HW_PARAMS. The former is used just for refining available set of parameters. The latter is used for an actual decision of the parameters. -The :c:type:`struct snd_pcm_hw_params` structure has below members: +The struct snd_pcm_hw_params structure has below members: ``flags`` Configurable. ALSA PCM core and some drivers handle this flag to select convenient parameters or change their behaviour. ``masks`` Configurable. This type of parameter is described in - :c:type:`struct snd_mask` and represent mask values. As of PCM protocol + struct snd_mask and represent mask values. As of PCM protocol v2.0.13, three types are defined. - SNDRV_PCM_HW_PARAM_ACCESS @@ -55,7 +55,7 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members: - SNDRV_PCM_HW_PARAM_SUBFORMAT ``intervals`` Configurable. This type of parameter is described in - :c:type:`struct snd_interval` and represent values with a range. As of + struct snd_interval and represent values with a range. As of PCM protocol v2.0.13, twelve types are defined. - SNDRV_PCM_HW_PARAM_SAMPLE_BITS @@ -78,7 +78,7 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members: are going to be changed. ``cmask`` Read-only. After returning from ioctl(2), buffer in user space for - :c:type:`struct snd_pcm_hw_params` includes result of each operation. + struct snd_pcm_hw_params includes result of each operation. This mask represents which mask/interval parameter is actually changed. ``info`` Read-only. This represents hardware/driver capabilities as bit flags @@ -110,10 +110,10 @@ The :c:type:`struct snd_pcm_hw_params` structure has below members: value to this parameter but some drivers intentionally set zero with a care of hardware design or data transmission protocol. -ALSA PCM core handles buffer of :c:type:`struct snd_pcm_hw_params` when +ALSA PCM core handles buffer of struct snd_pcm_hw_params when applications execute ioctl(2) with SNDRV_PCM_HW_REFINE or SNDRV_PCM_HW_PARAMS. Parameters in the buffer are changed according to -:c:type:`struct snd_pcm_hardware` and rules of constraints in the runtime. The +struct snd_pcm_hardware and rules of constraints in the runtime. The structure describes capabilities of handled hardware. The rules describes dependencies on which a parameter is decided according to several parameters. A rule has a callback function, and drivers can register arbitrary functions @@ -121,17 +121,17 @@ to compute the target parameter. ALSA PCM core registers some rules to the runtime as a default. Each driver can join in the interaction as long as it prepared for two stuffs -in a callback of :c:type:`struct snd_pcm_ops.open`. +in a callback of struct snd_pcm_ops.open. 1. In the callback, drivers are expected to change a member of - :c:type:`struct snd_pcm_hardware` type in the runtime, according to + struct snd_pcm_hardware type in the runtime, according to capacities of corresponding hardware. 2. In the same callback, drivers are also expected to register additional rules of constraints into the runtime when several parameters have dependencies due to hardware design. The driver can refers to result of the interaction in a callback of -:c:type:`struct snd_pcm_ops.hw_params`, however it should not change the +struct snd_pcm_ops.hw_params, however it should not change the content. Tracepoints in this category are designed to trace changes of the @@ -163,7 +163,7 @@ fields are different according to type of the parameter. For parameters of mask type, the fields represent hexadecimal dump of content of the parameter. For parameters of interval type, the fields represent values of each member of ``empty``, ``integer``, ``openmin``, ``min``, ``max``, ``openmax`` in -:c:type:`struct snd_interval` in this order. +struct snd_interval in this order. Tracepoints in drivers ====================== diff --git a/Documentation/sound/kernel-api/alsa-driver-api.rst b/Documentation/sound/kernel-api/alsa-driver-api.rst index c8cc651eccf7..d24c64df7069 100644 --- a/Documentation/sound/kernel-api/alsa-driver-api.rst +++ b/Documentation/sound/kernel-api/alsa-driver-api.rst @@ -132,3 +132,4 @@ ISA DMA Helpers Other Helper Macros ------------------- .. kernel-doc:: include/sound/core.h +.. kernel-doc:: sound/sound_core.c diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index aa9d5ab183d2..73bbd59afc33 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -194,7 +194,7 @@ The minimum flow for PCI soundcards is as follows: - create ``remove`` callback. -- create a :c:type:`struct pci_driver <pci_driver>` structure +- create a struct pci_driver structure containing the three pointers above. - create an ``init`` function just calling the @@ -487,7 +487,7 @@ The destructor, remove callback, simply releases the card instance. Then the ALSA middle layer will release all the attached components automatically. -It would be typically just :c:func:`calling snd_card_free()`: +It would be typically just calling :c:func:`snd_card_free()`: :: @@ -560,16 +560,15 @@ return the card instance. The extra_size argument is used to allocate card->private_data for the chip-specific data. Note that these data are allocated by :c:func:`snd_card_new()`. -The first argument, the pointer of struct :c:type:`struct device -<device>`, specifies the parent device. For PCI devices, typically -``&pci->`` is passed there. +The first argument, the pointer of struct device, specifies the parent +device. For PCI devices, typically ``&pci->`` is passed there. Components ---------- After the card is created, you can attach the components (devices) to the card instance. In an ALSA driver, a component is represented as a -:c:type:`struct snd_device <snd_device>` object. A component +struct snd_device object. A component can be a PCM instance, a control interface, a raw MIDI interface, etc. Each such instance has one component entry. @@ -628,7 +627,7 @@ argument of :c:func:`snd_card_new()`, i.e. err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE, sizeof(struct mychip), &card); -:c:type:`struct mychip <mychip>` is the type of the chip record. +struct mychip is the type of the chip record. In return, the allocated record can be accessed as @@ -890,7 +889,7 @@ functions. These resources must be released in the destructor function (see below). Now assume that the PCI device has an I/O port with 8 bytes and an -interrupt. Then :c:type:`struct mychip <mychip>` will have the +interrupt. Then struct mychip will have the following fields: :: @@ -1094,7 +1093,7 @@ PCI Entries ----------- So far, so good. Let's finish the missing PCI stuff. At first, we need a -:c:type:`struct pci_device_id <pci_device_id>` table for +struct pci_device_id table for this chipset. It's a table of PCI vendor/device ID number, and some masks. @@ -1110,19 +1109,17 @@ For example, }; MODULE_DEVICE_TABLE(pci, snd_mychip_ids); -The first and second fields of the :c:type:`struct pci_device_id -<pci_device_id>` structure are the vendor and device IDs. If you -have no reason to filter the matching devices, you can leave the -remaining fields as above. The last field of the :c:type:`struct -pci_device_id <pci_device_id>` struct contains private data -for this entry. You can specify any value here, for example, to define -specific operations for supported device IDs. Such an example is found -in the intel8x0 driver. +The first and second fields of the struct pci_device_id are the vendor +and device IDs. If you have no reason to filter the matching devices, you can +leave the remaining fields as above. The last field of the +struct pci_device_id contains private data for this entry. You can specify +any value here, for example, to define specific operations for supported +device IDs. Such an example is found in the intel8x0 driver. The last entry of this list is the terminator. You must specify this all-zero entry. -Then, prepare the :c:type:`struct pci_driver <pci_driver>` +Then, prepare the struct pci_driver record: :: @@ -1439,8 +1436,8 @@ corresponding argument. If a chip supports multiple playbacks or captures, you can specify more numbers, but they must be handled properly in open/close, etc. callbacks. When you need to know which substream you are referring to, -then it can be obtained from :c:type:`struct snd_pcm_substream -<snd_pcm_substream>` data passed to each callback as follows: +then it can be obtained from struct snd_pcm_substream data passed to each +callback as follows: :: @@ -1639,10 +1636,9 @@ In the sections below, important records are explained. Hardware Description ~~~~~~~~~~~~~~~~~~~~ -The hardware descriptor (:c:type:`struct snd_pcm_hardware -<snd_pcm_hardware>`) contains the definitions of the fundamental -hardware configuration. Above all, you'll need to define this in the -`PCM open callback`_. Note that the runtime instance holds the copy of +The hardware descriptor (struct snd_pcm_hardware) contains the definitions of +the fundamental hardware configuration. Above all, you'll need to define this +in the `PCM open callback`_. Note that the runtime instance holds the copy of the descriptor, not the pointer to the existing descriptor. That is, in the open callback, you can modify the copied descriptor (``runtime->hw``) as you need. For example, if the maximum number of @@ -1800,14 +1796,13 @@ Running Status ~~~~~~~~~~~~~~ The running status can be referred via ``runtime->status``. This is -the pointer to the :c:type:`struct snd_pcm_mmap_status -<snd_pcm_mmap_status>` record. For example, you can get the current +the pointer to the struct snd_pcm_mmap_status record. +For example, you can get the current DMA hardware pointer via ``runtime->status->hw_ptr``. The DMA application pointer can be referred via ``runtime->control``, -which points to the :c:type:`struct snd_pcm_mmap_control -<snd_pcm_mmap_control>` record. However, accessing directly to -this value is not recommended. +which points to the struct snd_pcm_mmap_control record. +However, accessing directly to this value is not recommended. Private Data ~~~~~~~~~~~~ @@ -1843,8 +1838,8 @@ error number such as ``-EINVAL``. To choose an appropriate error number, it is advised to check what value other parts of the kernel return when the same kind of request fails. -The callback function takes at least the argument with :c:type:`struct -snd_pcm_substream <snd_pcm_substream>` pointer. To retrieve the chip +The callback function takes at least the argument with +struct snd_pcm_substream pointer. To retrieve the chip record from the given substream instance, you can use the following macro. @@ -2313,10 +2308,10 @@ non-atomic contexts. For example, the function :c:func:`snd_pcm_period_elapsed()` is called typically from the interrupt handler. But, if you set up the driver to use a threaded interrupt handler, this call can be in non-atomic context, too. In such -a case, you can set ``nonatomic`` filed of :c:type:`struct snd_pcm -<snd_pcm>` object after creating it. When this flag is set, mutex -and rwsem are used internally in the PCM core instead of spin and -rwlocks, so that you can call all PCM functions safely in a non-atomic +a case, you can set ``nonatomic`` filed of struct snd_pcm object +after creating it. When this flag is set, mutex and rwsem are used internally +in the PCM core instead of spin and rwlocks, so that you can call all PCM +functions safely in a non-atomic context. Constraints @@ -2357,8 +2352,7 @@ There are many different constraints. Look at ``sound/pcm.h`` for a complete list. You can even define your own constraint rules. For example, let's suppose my_chip can manage a substream of 1 channel if and only if the format is ``S16_LE``, otherwise it supports any format -specified in the :c:type:`struct snd_pcm_hardware -<snd_pcm_hardware>` structure (or in any other +specified in struct snd_pcm_hardware> (or in any other constraint_list). You can build a rule like this: :: @@ -2467,7 +2461,7 @@ Definition of Controls To create a new control, you need to define the following three callbacks: ``info``, ``get`` and ``put``. Then, define a -:c:type:`struct snd_kcontrol_new <snd_kcontrol_new>` record, such as: +struct snd_kcontrol_new record, such as: :: @@ -2602,8 +2596,8 @@ info callback ~~~~~~~~~~~~~ The ``info`` callback is used to get detailed information on this -control. This must store the values of the given :c:type:`struct -snd_ctl_elem_info <snd_ctl_elem_info>` object. For example, +control. This must store the values of the given +struct snd_ctl_elem_info object. For example, for a boolean control with a single element: :: @@ -2774,13 +2768,11 @@ In the simplest way, you can do like this: if (err < 0) return err; -where ``my_control`` is the :c:type:`struct snd_kcontrol_new -<snd_kcontrol_new>` object defined above, and chip is the object -pointer to be passed to kcontrol->private_data which can be referred -to in callbacks. +where ``my_control`` is the struct snd_kcontrol_new object defined above, +and chip is the object pointer to be passed to kcontrol->private_data which +can be referred to in callbacks. -:c:func:`snd_ctl_new1()` allocates a new :c:type:`struct -snd_kcontrol <snd_kcontrol>` instance, and +:c:func:`snd_ctl_new1()` allocates a new struct snd_kcontrol instance, and :c:func:`snd_ctl_add()` assigns the given control component to the card. @@ -2797,10 +2789,9 @@ can call :c:func:`snd_ctl_notify()`. For example, This function takes the card pointer, the event-mask, and the control id pointer for the notification. The event-mask specifies the types of notification, for example, in the above example, the change of control -values is notified. The id pointer is the pointer of :c:type:`struct -snd_ctl_elem_id <snd_ctl_elem_id>` to be notified. You can -find some examples in ``es1938.c`` or ``es1968.c`` for hardware volume -interrupts. +values is notified. The id pointer is the pointer of struct snd_ctl_elem_id +to be notified. You can find some examples in ``es1938.c`` or ``es1968.c`` +for hardware volume interrupts. Metadata -------- @@ -2915,9 +2906,8 @@ with an ``ac97_bus_ops_t`` record with callback functions. The bus record is shared among all belonging ac97 instances. -And then call :c:func:`snd_ac97_mixer()` with an :c:type:`struct -snd_ac97_template <snd_ac97_template>` record together with -the bus pointer created above. +And then call :c:func:`snd_ac97_mixer()` with an struct snd_ac97_template +record together with the bus pointer created above. :: @@ -3118,11 +3108,10 @@ devices on the card, set ``MPU401_INFO_IRQ_HOOK`` (see Usually, the port address corresponds to the command port and port + 1 corresponds to the data port. If not, you may change the ``cport`` -field of :c:type:`struct snd_mpu401 <snd_mpu401>` manually afterward. -However, :c:type:`struct snd_mpu401 <snd_mpu401>` pointer is +field of struct snd_mpu401 manually afterward. +However, struct snd_mpu401 pointer is not returned explicitly by :c:func:`snd_mpu401_uart_new()`. You -need to cast ``rmidi->private_data`` to :c:type:`struct snd_mpu401 -<snd_mpu401>` explicitly, +need to cast ``rmidi->private_data`` to struct snd_mpu401 explicitly, :: @@ -3326,8 +3315,7 @@ data and removes them from the buffer at once: } If you know beforehand how many bytes you can accept, you can use a -buffer size greater than one with the -:c:func:`snd_rawmidi_transmit\*()` functions. +buffer size greater than one with the ``snd_rawmidi_transmit*()`` functions. The ``trigger`` callback must not sleep. If the hardware FIFO is full before the substream buffer has been emptied, you have to continue @@ -3772,7 +3760,7 @@ For creating the SG-buffer handler, call :c:func:`snd_pcm_set_managed_buffer_all()` with ``SNDRV_DMA_TYPE_DEV_SG`` in the PCM constructor like other PCI pre-allocator. You need to pass ``&pci->dev``, where pci is -the :c:type:`struct pci_dev <pci_dev>` pointer of the chip as +the struct pci_dev pointer of the chip as well. :: @@ -3927,7 +3915,7 @@ the maximum size of the proc file access. The read/write callbacks of raw mode are more direct than the text mode. You need to use a low-level I/O functions such as -:c:func:`copy_from/to_user()` to transfer the data. +:c:func:`copy_from_user()` and :c:func:`copy_to_user()` to transfer the data. :: |