June 2017 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH] ALSA: hda - set input_path bitmap to zero after moving it to new place
by Hui Wang 28 Jun '17

28 Jun '17

Recently we met a problem, the codec has valid adcs and input pins, and they can form valid input paths, but the driver does not build valid controls for them like "Mic boost", "Capture Volume" and "Capture Switch". Through debugging, I found the driver needs to shrink the invalid adcs and input paths for this machine, so it will move the whole column bitmap value to the previous column, after moving it, the driver forgets to set the original column bitmap value to zero, as a result, the driver will invalidate the path whose index value is the original colume bitmap value. After executing this function, all valid input paths are invalidated by a mistake, there are no any valid input paths, so the driver won't build controls for them. Cc: <stable(a)vger.kernel.org> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> --- the alsa-info.txt of this machine (without this patch) is pasted here: http://paste.ubuntu.com/24967758/ sound/pci/hda/hda_generic.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/pci/hda/hda_generic.c b/sound/pci/hda/hda_generic.c index 557ecfc..28e265a 100644 --- a/sound/pci/hda/hda_generic.c +++ b/sound/pci/hda/hda_generic.c @@ -3216,6 +3216,7 @@ static int check_dyn_adc_switch(struct hda_codec *codec) spec->input_paths[i][nums]); spec->input_paths[i][nums] = spec->input_paths[i][n]; + spec->input_paths[i][n] = 0; } } nums++; -- 1.9.1

2 1

[alsa-devel] [PATCH v3 0/3] Add support for es8323 and hdmi audio to the firefly-rk3288
by Romain Perier 27 Jun '17

27 Jun '17

This set of patches enables support for the es8323 codecs on the firefly-rk3288. It adds the required DT definitions to link rockchip-i2s to the es8388 analog output. As the support for HDMI audio is also built-in in the corresponding ASoC machine driver, HDMI audio output is also enabled. Changes in v3: - Synced DT with the one of the Rock2, the properties have been lexically re-ordered in the right order, I have splitted the headphone pinctrl in two: phone_ctl and hp_det Changes in v2: - Adapted DT for the firefly-rk3288 to the ASoC machine driver rk3288-hdmi-analog - Added patch 02/03 to this series - Re-wrote this cover letter Romain Perier (3): SoC: es8328-i2c: Add compatible for ES8323 arm: dts: rockchip: Don't set otp-gpio pinctrl by default in rk3288.dtsi arm: dts: Add support for ES8323 to the Firefly-RK3288 Documentation/devicetree/bindings/sound/es8328.txt | 5 ++- arch/arm/boot/dts/rk3288-evb.dtsi | 4 +++ arch/arm/boot/dts/rk3288-firefly.dtsi | 38 ++++++++++++++++++++++ arch/arm/boot/dts/rk3288-veyron.dtsi | 4 +++ arch/arm/boot/dts/rk3288.dtsi | 4 --- sound/soc/codecs/es8328-i2c.c | 2 ++ 6 files changed, 52 insertions(+), 5 deletions(-) -- 2.11.0

3 20

[alsa-devel] [PATCH 0/2] ASoC: stm32: add SPDIFRX driver
by olivier moysan 27 Jun '17

27 Jun '17

This patch-set handles the SPDIFRX on STM32 platforms. The SPDIFRX peripheral, is designed to receive an S/PDIF flow compliant with IEC-60958 and IEC-61937 standards. SPDIFRX uses two DMA channels: - one DMA channel for S/PDIF data stream. - one DMA channel for control flow (channel status and user data bits). DMA is used for control flow instead of interrupts to get better performances, as channel status and user data are retrieved byte per byte. Note: This patch-set depends on "change SAI configuration flag" patch, which introduces a change on Kconfig file. olivier moysan (2): dt-bindings: Document the STM32 SPDIFRX interface ASoC: stm32: Add SPDIFRX support .../devicetree/bindings/sound/st,stm32-spdifrx.txt | 56 ++ sound/soc/stm/Kconfig | 10 + sound/soc/stm/Makefile | 4 + sound/soc/stm/stm32_spdifrx.c | 998 +++++++++++++++++++++ sound/soc/stm/stm32_spdifrx.h | 224 +++++ 5 files changed, 1292 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/st,stm32-spdifrx.txt create mode 100644 sound/soc/stm/stm32_spdifrx.c create mode 100644 sound/soc/stm/stm32_spdifrx.h -- 1.9.1

3 6

[alsa-devel] [PATCH v3 0/2] ALSA: Add PCM USER_PVERSION ioctl
by Takashi Iwai 27 Jun '17

27 Jun '17

Hi, this is a revised patchset that is applied on top of the current for-next branch, in order to optimize the appl_ptr sync on x86-64, adapting the alsa-lib side change by Sakamoto-san's patchset. Basically it adds a new ioctl for receiving the supported PCM protocol version from user-space side, and change the mmap code to allow only disabling the PCM status record depending on the supported protocol version. The former patch is identical with the previous version, only the latter one differs. The corresponding alsa-lib patch will follow. thanks, Takashi === Takashi Iwai (2): ALSA: pcm: Add an ioctl to specify the supported protocol version ALSA: pcm: Disable only control mmap for explicit appl_ptr sync include/sound/pcm.h | 1 + include/uapi/sound/asound.h | 3 ++- sound/core/pcm_compat.c | 1 + sound/core/pcm_native.c | 29 ++++++++++++++++++++++++----- 4 files changed, 28 insertions(+), 6 deletions(-) -- 2.13.2

2 5

[alsa-devel] [PATCH v2 alsa-lib 0/6] pcm: hw: maintain fallback mode for status/control data separately
by Takashi Sakamoto 27 Jun '17

27 Jun '17

Hi, This patchset is a revised version for a part of my previous RFC: [alsa-devel] [alsa-lib][RFC][PATCH 0/9] pcm: handle status/control mapping independently http://mailman.alsa-project.org/pipermail/alsa-devel/2017-June/122130.html As I described, we found an advantage to handle results of page mapping for status/control data separately in a discussion about ALSA PCM protocol v2.0.14. In this version, when kernel-land drivers support SNDRV_PCM_INFO_SYNC_APPLPTR for a certain design of hardware, userspace applications are expected to issue current position of applptr for several merits. This should be performed even if applications are programmed to run with mmap operation for PCM buffer. In the above discussion, the way to take applications to perform it is one of important issues. On platforms without enough cache coherency support such as ARM, this doesn't matter. On the platforms, ALSA PCM core already disallows any of mappings for the status/control data of runtime of PCM substream. For this case, userland stuffs were already programmed to go to fallback mode, in which ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR is used to issue/query the status/control data. Even if handling PCM frames on PCM buffer by mmap operation, the position of applptr is issues into ALSA PCM core by a call of ioctl(2) with the command. As a solution for old stuffs in userland, the above mechanism is used for cache coherent architecture such as x86. A patch was already merged into kernel land[1]. This patch changes behaviours of ALSA PCM core to disallow userland to map the status/control data according to drivers' support for SNDRV_PCM_INFO_SYNC_APPLPTR. However, disallowing mappings for both of status/control data has a slight overhead to increase calls of ioctl(2), than usual operation on x86. As I reported[2]. Furthermore, it's clear that current proposals make no sense for drivers because 'struct snd_pcm_ops.ack' in driver implementation is not called expectedly due to a commit[4]. Even if the applptr is issued by ioctl(2), the callback is skipped as long as mapped status includes the updated value for the applptr. In the above discussion, some solutions were suggested[5]. One of them is to enable map of the status data and disable map of the control data. This idea can archive both of the aim of v2.0.14 protocol and reduction of calls for status data, for newer userland stuffs. This patchset for alsa-lib is a preparation for the idea. In current implementation of this library, results of mapping operation for status/control data are not handled separately. This patchset is a similar to code refactoring, thus this includes no essential behaviour changes against released kernel lands. [1] ALSA: pcm: Add the explicit appl_ptr sync support https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?id=… [2] ALSA: pcm: add 'applptr' event of tracepoint https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=f… [3] [alsa-devel] [PATCH 0/3] ALSA: Add the explicit appl_ptr sync support http://mailman.alsa-project.org/pipermail/alsa-devel/2017-June/122092.html [4] ALSA: pcm: Skip ack callback without actual appl_ptr update https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git/commit/?h=f… [5] [alsa-devel] [PATCH 0/3] ALSA: Add the explicit appl_ptr sync support http://mailman.alsa-project.org/pipermail/alsa-devel/2017-June/122093.html Takashi Sakamoto (6): pcm: hw: add helper functions to map/unmap status/control data for runtime of PCM substream pcm: hw: add an arrangement for initialization of appl_ptr/avail_min pcm: hw: deallocate fallback buffer when trials of unmapping finished pcm: hw: allocate fallback buffer in advance of trials of mapping pcm: hw: maintain fallback mode for status data mapping pcm: hw: maintain fallback mode for control data mapping independently src/pcm/pcm_hw.c | 192 +++++++++++++++++++++++++++++++++---------------------- 1 file changed, 115 insertions(+), 77 deletions(-) -- 2.11.0

2 12

[alsa-devel] [PATCH alsa-lib v2] pcm: hw: Call USER_PVERSION ioctl at open
by Takashi Iwai 27 Jun '17

27 Jun '17

Up from the new PCM protocol 2.0.14, user-space can inform the protocol version it supports to kernel, so that the kernel may switch its behavior depending on it. Add this ioctl call in the PCM hw plugin at opening. The patch contains also the addition of SNDRV_PCM_INFO_SYNC_APPLPTR carried from the upstream kernel commit 42f945970af9 ("ALSA: pcm: Add the explicit appl_ptr sync support"), as well as the trivial change (an addition of comma) to sync with the kernel asound.h. Reviewed-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> Tested-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> --- include/sound/asound.h | 6 ++++-- src/pcm/pcm_hw.c | 10 ++++++++++ 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/include/sound/asound.h b/include/sound/asound.h index fb8d7d7ef8ad..1949923a40bf 100644 --- a/include/sound/asound.h +++ b/include/sound/asound.h @@ -111,7 +111,7 @@ enum { SNDRV_HWDEP_IFACE_FW_FIREFACE, /* RME Fireface series */ /* Don't forget to change the following: */ - SNDRV_HWDEP_IFACE_LAST = SNDRV_HWDEP_IFACE_FW_FIREFACE, + SNDRV_HWDEP_IFACE_LAST = SNDRV_HWDEP_IFACE_FW_FIREFACE }; struct snd_hwdep_info { @@ -152,7 +152,7 @@ struct snd_hwdep_dsp_image { * * *****************************************************************************/ -#define SNDRV_PCM_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 13) +#define SNDRV_PCM_VERSION SNDRV_PROTOCOL_VERSION(2, 0, 14) typedef unsigned long snd_pcm_uframes_t; typedef signed long snd_pcm_sframes_t; @@ -268,6 +268,7 @@ typedef int __bitwise snd_pcm_subformat_t; #define SNDRV_PCM_INFO_MMAP_VALID 0x00000002 /* period data are valid during transfer */ #define SNDRV_PCM_INFO_DOUBLE 0x00000004 /* Double buffering needed for PCM start/stop */ #define SNDRV_PCM_INFO_BATCH 0x00000010 /* double buffering */ +#define SNDRV_PCM_INFO_SYNC_APPLPTR 0x00000020 /* need the explicit sync of appl_ptr update */ #define SNDRV_PCM_INFO_INTERLEAVED 0x00000100 /* channels are interleaved */ #define SNDRV_PCM_INFO_NONINTERLEAVED 0x00000200 /* channels are not interleaved */ #define SNDRV_PCM_INFO_COMPLEX 0x00000400 /* complex frame organization (mmap only) */ @@ -563,6 +564,7 @@ enum { #define SNDRV_PCM_IOCTL_INFO _IOR('A', 0x01, struct snd_pcm_info) #define SNDRV_PCM_IOCTL_TSTAMP _IOW('A', 0x02, int) #define SNDRV_PCM_IOCTL_TTSTAMP _IOW('A', 0x03, int) +#define SNDRV_PCM_IOCTL_USER_PVERSION _IOW('A', 0x04, int) #define SNDRV_PCM_IOCTL_HW_REFINE _IOWR('A', 0x10, struct snd_pcm_hw_params) #define SNDRV_PCM_IOCTL_HW_PARAMS _IOWR('A', 0x11, struct snd_pcm_hw_params) #define SNDRV_PCM_IOCTL_HW_FREE _IO('A', 0x12) diff --git a/src/pcm/pcm_hw.c b/src/pcm/pcm_hw.c index 5573fce2d43d..64188b2258d6 100644 --- a/src/pcm/pcm_hw.c +++ b/src/pcm/pcm_hw.c @@ -1494,6 +1494,16 @@ int snd_pcm_hw_open_fd(snd_pcm_t **pcmp, const char *name, int fd, if (SNDRV_PROTOCOL_INCOMPATIBLE(ver, SNDRV_PCM_VERSION_MAX)) return -SND_ERROR_INCOMPATIBLE_VERSION; + if (SNDRV_PROTOCOL_VERSION(2, 0, 14) <= ver) { + /* inform the protocol version we're supporting */ + unsigned int user_ver = SNDRV_PCM_VERSION; + if (ioctl(fd, SNDRV_PCM_IOCTL_USER_PVERSION, &user_ver) < 0) { + ret = -errno; + SNDMSG("USER_PVERSION failed\n"); + return ret; + } + } + #if defined(HAVE_CLOCK_GETTIME) && defined(CLOCK_MONOTONIC) if (SNDRV_PROTOCOL_VERSION(2, 0, 9) <= ver) { struct timespec timespec; -- 2.13.2

1 0

[alsa-devel] remove dma_alloc_noncoherent
by Christoph Hellwig 26 Jun '17

26 Jun '17

For many years we've had the dma_alloc_attrs API that is more flexible than dma_alloc_noncoherent. This series moves the remaining users over to the attrs API.

7 24

[alsa-devel] [PATCH] Fix bug in arecord --max-file-time where the file size could overflow 32 bits
by Gilliland, Scott M 26 Jun '17

26 Jun '17

From: Scott Gilliland <scott.gilliland(a)gatech.edu> Fix bug in arecord --max-file-time where the file size could overflow 32 bits Signed-off-by: Scott Gilliland <scott.gilliland(a)gatech.edu> --- aplay/aplay.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/aplay/aplay.c b/aplay/aplay.c index f793c82..00af662 100644 --- a/aplay/aplay.c +++ b/aplay/aplay.c @@ -3027,7 +3027,7 @@ static void capture(char *orig_name) if (count == 0) count = LLONG_MAX; /* compute the number of bytes per file */ - max_file_size = max_file_time * + max_file_size = (long long) max_file_time * snd_pcm_format_size(hwparams.format, hwparams.rate * hwparams.channels); /* WAVE-file should be even (I'm not sure), but wasting one byte -- 2.11.0

2 1

[alsa-devel] [PATCH] ALSA: pcm: add a documentation for tracepoints
by Takashi Sakamoto 26 Jun '17

26 Jun '17

In PCM interface/protocol for userspace, parameters of runtime for PCM substream is decided by an interaction between applications and ALSA PCM core. In former commits, some tracepoints were added to probe a part of the interaction. This commit adds a documentation about the interaction and the tracepoints. Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- Documentation/sound/designs/index.rst | 1 + Documentation/sound/designs/tracepoints.rst | 177 ++++++++++++++++++++++++++++ 2 files changed, 178 insertions(+) create mode 100644 Documentation/sound/designs/tracepoints.rst diff --git a/Documentation/sound/designs/index.rst b/Documentation/sound/designs/index.rst index 04dcdae3e4f2..f0749943ccb2 100644 --- a/Documentation/sound/designs/index.rst +++ b/Documentation/sound/designs/index.rst @@ -9,6 +9,7 @@ Designs and Implementations compress-offload timestamping jack-controls + tracepoints procfile powersave oss-emulation diff --git a/Documentation/sound/designs/tracepoints.rst b/Documentation/sound/designs/tracepoints.rst new file mode 100644 index 000000000000..b45e9f765451 --- /dev/null +++ b/Documentation/sound/designs/tracepoints.rst @@ -0,0 +1,177 @@ +=================== +Tracepoints in ALSA +=================== + +2017/06/26 +Takasahi Sakamoto + +Tracepoints in ALSA PCM core +============================ + +ALSA PCM core registers ``snd_pcm`` subsystem to kernel tracepoint system. +This subsystem includes two categories of tracepoints; for state of PCM buffer +and for processing of PCM hardware parameters. These tracepoints are available +when corresponding kernel configurations are enabled. When ``CONFIG_SND_DEBUG`` +is enabled, the latter tracepoints are available. When additional +``SND_PCM_XRUN_DEBUG`` is enabled too, the former trace points are enabled. + +Tracepoints for state of PCM buffer +------------------------------------ + +This category includes four tracepoints; ``hwptr``, ``applptr``, ``xrun`` and +``hw_ptr_error``. + +Tracepoints for processing of PCM hardware parameters +----------------------------------------------------- + +This category includes two tracepoints; ``hw_mask_param`` and +``hw_interval_param``. + +In a design of ALSA PCM core, data transmission is abstracted as PCM substream. +Applications manage PCM substream to maintain data transmission for PCM frames. +Before stating the data transmission, applications need to configure PCM +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 hardware parameters are described in :c:type:`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 querying 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: + +``flags`` + Configurable. ALSA PCM core and some drivers handle this flag to select + convenient parameters or change their behaviour. As of PCM protocol + v2.0.13, three flags are defined. + + - SNDRV_PCM_HW_PARAMS_NORESAMPLE + - SNDRV_PCM_HW_PARAMS_EXPORT_BUFFER + - SNDRV_PCM_HW_PARAMS_NO_PERIOD_WAKEUP +``masks`` + Configurable. This type of parameter is described in + :c:type:`struct snd_mask` and represent mask values. As of PCM protocol + v2.0.13, three types are defined. + + - SNDRV_PCM_HW_PARAM_ACCESS + - SNDRV_PCM_HW_PARAM_FORMAT + - 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 + PCM protocol v2.0.13, twelve types are defined. + + - SNDRV_PCM_HW_PARAM_SAMPLE_BITS + - SNDRV_PCM_HW_PARAM_FRAME_BITS + - SNDRV_PCM_HW_PARAM_CHANNELS + - SNDRV_PCM_HW_PARAM_RATE + - SNDRV_PCM_HW_PARAM_PERIOD_TIME + - SNDRV_PCM_HW_PARAM_PERIOD_SIZE + - SNDRV_PCM_HW_PARAM_PERIOD_BYTES + - SNDRV_PCM_HW_PARAM_PERIODS + - SNDRV_PCM_HW_PARAM_BUFFER_TIME + - SNDRV_PCM_HW_PARAM_BUFFER_SIZE + - SNDRV_PCM_HW_PARAM_BUFFER_BYTES + - SNDRV_PCM_HW_PARAM_TICK_TIME +``rmask`` + Configurable. This is evaluated at ioctl(2) with + SNDRV_PCM_IOCTL_HW_REFINE only. Applications can select which + mask/interval parameter should be queried to ALSA PCM core. For + SNDRV_PCM_IOCTL_HW_PARAMS, this mask makes no sense and all of + parameters 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. This mask represents + which mask/interval parameter is actually changed. +``info`` + Read-only. This represents hardware/driver capabilities as bit flags + with SNDRV_PCM_INFO_XXX. Typically, applications execute ioctl(2) with + SNDRV_PCM_IOCTL_HW_REFINE to retrieve this flag, then decide candidates + of parameters and execute ioctl(2) with SNDRV_PCM_IOCTL_HW_PARAMS to + configure PCM substream. +``msbits`` + Read-only. This value represents available bit width in MSB side of + a PCM sample. When a parameter of SNDRV_PCM_HW_PARAM_SAMPLE_BITS was + decided as a fixed number, this value is also calculated according to + it. Else, zero. But this behaviour depends on implementations in driver + side. +``rate_num`` + Read-only. This value represents numerator of sampling rate in fraction + notation. Basically, when a parameter of SNDRV_PCM_HW_PARAM_RATE was + decided as a fixed number, this value is also calculated according to + it. Else, zero. But this behaviour depends on implementations in driver + side. +``rate_den`` + Read-only. This value represents denominator of sampling rate in + fraction notation. Basically, when a parameter of + SNDRV_PCM_HW_PARAM_RATE was decided as a fixed number, this value is + also calculated according to it. Else, zero. But this behaviour depends + on implementations in driver side. +``fifo_size`` + Read-only. This value represents the size of FIFO in serial sound + interface of hardware. Basically, each driver can assigns a proper + 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 +applications execute ioctl(2) with SNDRV_PCM_HW_REFINE or SNDRV_PCM_HW_PARAMS. +Pamraeters in the buffer are changed according to +:c:type:`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 +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`. + +1. In the callback, drivers are expected to change a member of + :c:type:`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 +content. + +Tracepoints in this category are designed to trace changes of the +mask/interval parameters. When ALSA PCM core changes them, ``hw_mask_param`` or +``hw_interval_param`` event is probed according to type of the changed parameter. + +ALSA PCM core also has a pretty print format for each of the tracepoints. Below +is an example for ``hw_mask_param``. + +:: + + hw_mask_param: pcmC0D0p 001/023 FORMAT 00000000000000000000001000000044 00000000000000000000001000000044 + + +Below is an example for ``hw_interval_param``. + +:: + + hw_interval_param: pcmC0D0p 000/023 BUFFER_SIZE 0 0 [0 4294967295] 0 1 [0 4294967295] + +The first three fields are common. They represent ALSA PCM character device, +rules of constraint and name of the changed parameter, in order. The field for +rules of constraint consists of two sub-fields; index of applied rule and +total number of rules added to the runtime. The index 000 means that the +parameter is changed by ALSA PCM core regardless of the rules. + +The rest of field represent state of the parameter before/after changing. These +fields are different according to type of the parameter. For parameter of mask +type, the fields represent hexadecimal dump of content of the parameter. For +parameter of interval type, the fields represent values of each member of +``empty``, ``integer``, ``openmin``, ``min``, ``max``, ``openmax`` in +:c:type:`struct snd_interval`. + +Tracepoints in drivers +====================== + +Some drivers have tracepoints for developers' convenience. For them, please +refer to each documentation or implementation. -- 2.11.0

2 1

[alsa-devel] [PATCH][sound-next] ASoC: zx_aud96p22: make aud96p22_dt_ids static
by Colin King 26 Jun '17

26 Jun '17

From: Colin Ian King <colin.king(a)canonical.com> The structure aud96p22_dt_ids does not need to be in global scope, so make it static. Cleans up sparse warning: "warning: symbol 'aud96p22_dt_ids' was not declared. Should it be static?" Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- sound/soc/codecs/zx_aud96p22.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/codecs/zx_aud96p22.c b/sound/soc/codecs/zx_aud96p22.c index 032fb7cf6cbd..bc23ce1a30a1 100644 --- a/sound/soc/codecs/zx_aud96p22.c +++ b/sound/soc/codecs/zx_aud96p22.c @@ -382,7 +382,7 @@ static int aud96p22_i2c_remove(struct i2c_client *i2c) return 0; } -const struct of_device_id aud96p22_dt_ids[] = { +static const struct of_device_id aud96p22_dt_ids[] = { { .compatible = "zte,zx-aud96p22", }, { } }; -- 2.11.0

2 1