Currently the msbits constraints requires to specify a specific sample
format width for which the constraint should be applied. But often the
number of most significant bits is not sample format specific, but rather a
absolute limit. E.g. the PCM interface might accept 32-bit and 24-bit
samples, but the DAC has a 16-bit resolution and throws away the LSBs. In
this case for both 32-bit and 24-bit format msbits should be set to 16. This
patch extends snd_pcm_hw_constraint_msbits() so that a wildcard constraint
can be setup that is applied for all formats with a sample width larger than
the specified msbits. Choosing the wildcard constraint is done by setting
the sample width parameter of the function to 0.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
If the sound card is made up of discrete components, each with their own
driver (e.g. like in the ASoC case), we might end up with multiple msbits
constraint rules installed. Currently this will result in msbits being set
to whatever the last rule set it to.
This patch updates the behavior of the rule to choose the minimum (other
than zero) of all the installed rules.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The commit [7a2e9ddc: ALSA: usb-audio: Add native DSD support for
Denon/Marantz DACs] requires the new format definition that has
landed only in for-next branch.
The functions snd_seq_oss_timer_delete() and vunmap() perform also input
parameter validation. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch fixes XMOS DSD sample format to DSD_U32_BE and also adds
DSD_U16_BE and DSD_U32_BE sample formats.
Signed-off-by: Jussi Laako <jussi@sonarnerd.net>
Acked-by: Jurgen Kramer <gtmkramer@xs4all.nl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fix a copy & paste error:
Warning(sound/core/pcm_native.c:1112): Excess function parameter 'state' description in 'snd_pcm_stop_xrun'
The state argument was dropped from snd_pcm_stop_xrun().
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add a new helper function snd_pcm_stop_xrun() to the standard sequnce
lock/snd_pcm_stop(XRUN)/unlock by a single call, and replace the
existing open codes with this helper.
The function checks the PCM running state to prevent setting the wrong
state, too, for more safety.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We want to know the offset for the id that was passed to the function, not
the offset of the first id of the control (which is always 0).
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some state changes (e.g. snd_pcm_stop()) sets the runtime state after
calling snd_timer_notify(). This is basically racy, since the
notification may wakes up the user even before the state change.
Although the possibility is low, we should set the state before the
notifications.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This merges the USB-audio disconnect fix and resolves the conflicts
so that we can continue working on development of usb-audio stuff.
Conflicts:
sound/usb/card.c
This patch adds a new proc entry for PCM substreams to inject an
XRUN. When a PCM substream is running and any value is written to its
xrun_injection proc file, the driver triggers XRUN. This is a useful
feature for debugging XRUN and error handling code paths.
Note that this entry is enabled only when CONFIG_SND_PCM_XRUN_DEBUG is
set.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA PCM core has a mechanism tracking the PCM hwptr updates for
analyzing XRUNs. But its log is limited (up to 10) and its log output
is a kernel message, which is hard to handle.
In this patch, the hwptr logging is moved to the tracing
infrastructure instead of its own. Not only the hwptr updates but
also XRUN and hwptr errors are recorded on the trace log, so that user
can see such events at the exact timing.
The new "snd_pcm" entry will appear in the tracing events:
# ls -F /sys/kernel/debug/tracing/events/snd_pcm
enable filter hw_ptr_error/ hwptr/ xrun/
The hwptr is for the regular hwptr update events. An event trace
looks like:
aplay-26187 [004] d..3 4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384
"POS" shows the hwptr update by the explicit position update call and
"IRQ" means the hwptr update by the interrupt,
i.e. snd_pcm_period_elapsed() call. The "pos" is the passed
ring-buffer offset by the caller, "old" is the previous hwptr, "base"
is the hwptr base position, "period" and "buf" are period- and
buffer-size of the target PCM substream.
(Note that the hwptr position displayed here isn't the ring-buffer
offset. It increments up to the PCM position boundary.)
The XRUN event appears similarly, but without "pos" field.
The hwptr error events appear with the PCM identifier and its reason
string, such as "Lost interrupt?".
The XRUN and hwptr error reports on kernel message are still left, can
be turned on/off via xrun_debug proc like before. But the bit 3, 4, 5
and 6 bits of xrun_debug proc are dropped by this patch. Also, along
with the change, the message strings have been reformatted to be a bit
more consistent.
Last but not least, the hwptr reporting is enabled only when
CONFIG_SND_PCM_XRUN_DEBUG is set.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
While converting to dev_*(), the message showing the invalid PCM
position was wrongly tagged as if an XRUN although it's actually a
BUG. This patch corrects the message again.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The function snd_pcm_action_lock_irq() can be much simplified by
simply wrapping snd_pcm_action() with the stream lock. This was
rather the original idea, but later it was open coded for
optimization. However, looking at the optimization part closely, one
notices that the probability of the optimized path is quite low; in
normal situations, the linked stream action happens only for the
triggered substream, thus the operation becomes identical. So the
code simplification has a clear win, especially because we have now
doubly codes for both atomic and non-atomic locks.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A few functions have no proper documentation yet, so let's add them.
Along with it, remove superfluous blank line between the closing brace
and EXPORT_SYMBOL() line.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In compat mode, we copy each field of snd_pcm_status struct but don't
touch the reserved fields, and this leaves uninitialized values
there. Meanwhile the native ioctl does zero-clear the whole
structure, so we should follow the same rule in compat mode, too.
Reported-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On x86, using dma_mmap_coherent() for the pages allocated via
dma_alloc_coherent() results in a warning like:
aplay:32536 map pfn RAM range req uncached-minus for [mem 0x21d500000-0x21d51ffff], got write-back
Until the issue is addressed in the core side, take back to the old
good way in PCM code only for x86.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
this is a series of patches to just convert the plain info callback
for enum ctl elements to snd_ctl_elem_info(). Also, it includes the
extension of snd_ctl_elem_info(), for catching the unexpected string
cut-off and handling the zero items.
Some architectures like PARISC is known not to support mmap properly
with the DMA buffer, where dma_mmap_coherent() returns -EINVAL
unconditionally. From the API POV, we should rather drop the mmap
support there and expose it before the user-space tries to call mmap.
The patch contains again ugly ifdef's, unfortunately, as there is no
global flag indicating this. Once when such macro is defined, we can
get rid of this instead.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Since we have consistently dma_mmap_coherent() for all architectures,
the current ifdef and arch-specific codes in pcm core can be cleaned
up gracefully.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As PCM core handles the multiple linked streams in parallel, lockdep
gets confused (partly because of weak annotations) and spews the
false-positive warnings. This hasn't been a problem for long time but
the latest PCM lock path update seems to have woken up a sleeping
dog.
Here is an attempt to paper over this issue: pass the lock subclass
just calculated from the depth in snd_pcm_action_group(). Also, a
(possibly) wrong lock subclass set in snd_pcm_action_lock_mutex() is
dropped, too.
Reported-and-tested-by: Arthur Marsh <arthur.marsh@internode.on.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Although this is weird, some drivers want to allow empty control
elements intentionally, e.g. the number of items may change depending
on the firmware status. Let the function simply returning in such a
case.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Since we're calling request_module() asynchronously now, we can get
rid of the autoload lock in snd_seq_device_register_driver(), as well
as in the snd-seq driver registration itself. This enables the
automatic loading of dependent sequencer modules, such as
snd-seq-virmidi from snd-emu10k1-synth.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently the sequencer module binding is performed independently from
the card module itself. The reason behind it is to keep the sequencer
stuff optional and allow the system running without it (e.g. for using
PCM or rawmidi only). This works in most cases, but a remaining
problem is that the binding isn't done automatically when a new driver
module is probed. Typically this becomes visible when a hotplug
driver like usb audio is used.
This patch tries to address this and other potential issues. First,
the seq-binder (seq_device.c) tries to load a missing driver module at
creating a new device object. This is done asynchronously in a workq
for avoiding the deadlock (modprobe call in module init path).
This action, however, should be enabled only when the sequencer stuff
was already initialized, i.e. snd-seq module was already loaded. For
that, a new function, snd_seq_autoload_init() is introduced here; this
clears the blocking of autoloading, and also tries to load all pending
driver modules.
Reported-by: Adam Goode <agoode@chromium.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In the unlock loop of snd_pcm_action_group(), the object "s" is used
as the check of nonatomic PCM, but it should be rather "s1", which is
the iterator of the loop. This supposedly causes a kernel panic when
the substreams in operatino are linked.
Fixes: 257f8cce5d ('ALSA: pcm: Allow nonatomic trigger operations')
Reported-and-tested-by: Arthur Marsh <arthur.marsh@internode.on.net>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add a NULL check in snd_pci_quirk_lookup() so that NULL can be passed
as a pci_dev pointer. This fixes the possible NULL dereferences in
HD-audio drivers.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
- More componentisation work from Lars-Peter, this time mainly
cleaning up the suspend and bias level transition callbacks.
- Real system support for the Intel drivers and a bunch of fixes and
enhancements for the associated CODEC drivers, this is going to need
a lot quirks over time due to the lack of any firmware description of
the boards.
- Jack detect support for simple card from Dylan Reid.
- A bunch of small fixes and enhancements for the Freescale drivers.
- New drivers for Analog Devices SSM4567, Cirrus Logic CS35L32, Everest
Semiconductor ES8328 and Freescale cards using the ASRC in newer i.MX
processors.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJUMoHRAAoJECTWi3JdVIfQGXUH/RWQ6/Ey70SPgUdWWQ42PFey
sBq/Hl69F8/JNxW6EDA4GEg6ue880Gek0oGqioxtN6Ku0Vm/WSqDWnKcTAGl4dDO
AefC4FwekZWCYQi3VTNIvMEqfUWkcofTLVwjdh/PUZxniahkiGA81UJ1mQNXBxLF
UusrK0fIAxQgiNsCcPZ94knJiqZVBWgbRv/mCXY9K1/jqITNKd/ZVEMkOPk/p00q
cH9LIx8EknRV3HyJNZQ0xpmhpuMzLy6Agf7Oeq/m5kDqq1stmClvibPYkdqkdkto
jYwKaPh18dNHlUmm1w/G7X20kCidhbiwRjS/iIzx3cfIrWkiz90/BSRFKs8pqSo=
=7PPg
-----END PGP SIGNATURE-----
Merge tag 'asoc-v3.18' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
ASoC: Updates for v3.18
- More componentisation work from Lars-Peter, this time mainly
cleaning up the suspend and bias level transition callbacks.
- Real system support for the Intel drivers and a bunch of fixes and
enhancements for the associated CODEC drivers, this is going to need
a lot quirks over time due to the lack of any firmware description of
the boards.
- Jack detect support for simple card from Dylan Reid.
- A bunch of small fixes and enhancements for the Freescale drivers.
- New drivers for Analog Devices SSM4567, Cirrus Logic CS35L32, Everest
Semiconductor ES8328 and Freescale cards using the ASRC in newer i.MX
processors.
The calculated frame size was wrong because snd_pcm_format_physical_width()
actually returns the number of bits, not bytes.
Use snd_pcm_format_size() instead, which not only returns bytes, but also
simplifies the calculation.
Fixes: 8bea869c5e ("ALSA: PCM midlevel: improve fifo_size handling")
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
XMOS based USB DACs with native DSD support expose this feature via a USB
alternate setting. The audio format is either 32-bit raw or a 32-bit PCM format.
To utilize this feature on linux this patch introduces a new 32-bit DSD
sampleformat DSD_U32_LE.
A follow up patch will add a quirk for XMOS based devices to utilize the new format.
Further patches will add support to alsa-lib.
Signed-off-by: Jurgen Kramer <gtmkramer@xs4all.nl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Changing an interval boundary to a multiple of the step size makes that
boundary exact.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The min parameter was not used by any caller. And if it were used,
underflows in the calculations could lead to incorrect results.
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The previous commit for the non-atomic PCM ops added more codes to
snd_pcm_stream_lock() and its variants. Since they are inlined
functions, it resulted in a significant code size bloat. For reducing
the size bloat, this patch changes the inline functions to the normal
function calls. The export of rwlock and rwsem are removed as well,
since they are referred only in pcm_native.c now.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently, many PCM operations are performed in a critical section
protected by spinlock, typically the trigger and pointer callbacks are
assumed to be atomic. This is basically because some trigger action
(e.g. PCM stop after drain or xrun) is done in the interrupt handler.
If a driver runs in a threaded irq, however, this doesn't have to be
atomic. And many devices want to handle trigger in a non-atomic
context due to lengthy communications.
This patch tries all PCM calls operational in non-atomic context.
What it does is very simple: replaces the substream spinlock with the
corresponding substream mutex when pcm->nonatomic flag is set. The
driver that wants to use the non-atomic PCM ops just needs to set the
flag and keep the rest as is. (Of course, it must not handle any PCM
ops in irq context.)
Note that the code doesn't check whether it's atomic-safe or not, but
trust in 100% that the driver sets pcm->nonatomic correctly.
One possible problem is the case where linked PCM substreams have
inconsistent nonatomic states. For avoiding this, snd_pcm_link()
returns an error if one tries to link an inconsistent PCM substream.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Right now we set 0 as the silence data for DSD_U8 and DSD_U16 formats,
but this is actually wrong. 0 is rather the most negative value.
Alternatively, we may take the repeating 0x69 pattern like ffmpeg
deploys.
Reference: https://ffmpeg.org/pipermail/ffmpeg-cvslog/2014-April/076427.html
Suggested-by: Alexander E. Patrakov <patrakov@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_info_get_line() documents that its last parameter must be one
less than the buffer size, but this API design guarantees that
(literally) every caller gets it wrong.
Just change this parameter to have its obvious meaning.
Reported-by: Tommi Rantala <tt.rantala@gmail.com>
Cc: <stable@vger.kernel.org> # v2.2.26+
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This has been a pretty exciting release in terms of the framework, we've
finally got support for multiple CODECs attached to a single DAI link
which has been something there's been interest in as long as I've been
working on ASoC. A big thanks to Benoit and Misael for their work on
this.
Otherwise it's been a fairly standard release for development, including
more componentisation work from Lars-Peter and a good selection of both
CODEC and CPU drivers.
- Support for multiple CODECs attached to a single DAI, enabling
systems with for example multiple DAC/speaker drivers on a single
link, contributed by Benoit Cousson based on work from Misael Lopez
Cruz.
- Support for byte controls larger than 256 bytes based on the use of
TLVs contributed by Omair Mohammed Abdullah.
- More componentisation work from Lars-Peter Clausen.
- The remainder of the conversions of CODEC drivers to params_width()
- Drivers for Cirrus Logic CS4265, Freescale i.MX ASRC blocks, Realtek
RT286 and RT5670, Rockchip RK3xxx I2S controllers and Texas Instruments
TAS2552.
- Lots of updates and fixes, especially to the DaVinci, Intel,
Freescale, Realtek, and rcar drivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJT37EhAAoJELSic+t+oim9ELcP/j4ve2Zb3zqVn+md2fJNLFt6
7rD8eZTvy9XEoYVLIxNOroiM4Dl6m0FlA3gigzbpHLRUlZWH6JB1EDsn/kuB910Y
E9T76HVzznUtmoEbbo2CRYelsO2I3RmlpJWYrzfkwQVAnSd+tQmWixypZzKEJcvP
F+1gUA5DlTnSrDtFAcA0n5xhqczbrJ51l5l2irVf1eKdWTepixk0tMBonadb/s3V
Uh+EPl2htEmjpo4fHDzcULGCQABtiPn9ebV4urQnhWMifJehk5md9WyQchaRCz8c
95ERNc+hLbrTUEALSgI46PWP497hdz4kd1B1jahLGSnWqRIgm/NwyhjqC47kgJfv
8006v4nY4+T8d1yU4kFpB72f/xL6dxI53K6jRkie2WUQy+4L7kNp3egDJ4at9MdA
iFSq+XzOmN978XVlYOj/9KXVS/fpgslYYwa+omok45MbqCWg8EZbWdFwv/uXlbza
ldDjPKvz5LYfnSNES30Q29TMKnqvmdbIzbgqWPnT2RR4x0mxT6MWh5yM0WBBXqNV
TM791q5cgUr07+f8LeeCS5J99H0OuElqn0OPIWOcqN2MI4Qp+8ZuswBCQtZ6i1V7
oleSIPc4clchsXuRF83vD4JjZYkx7wqTOmmRHbKDB4d/LFLH3J2DHJH99CD1IX0a
4J4h5Bmi2f3CCih7KLBD
=pnce
-----END PGP SIGNATURE-----
Merge tag 'asoc-v3.17' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v3.17
This has been a pretty exciting release in terms of the framework, we've
finally got support for multiple CODECs attached to a single DAI link
which has been something there's been interest in as long as I've been
working on ASoC. A big thanks to Benoit and Misael for their work on
this.
Otherwise it's been a fairly standard release for development, including
more componentisation work from Lars-Peter and a good selection of both
CODEC and CPU drivers.
- Support for multiple CODECs attached to a single DAI, enabling
systems with for example multiple DAC/speaker drivers on a single
link, contributed by Benoit Cousson based on work from Misael Lopez
Cruz.
- Support for byte controls larger than 256 bytes based on the use of
TLVs contributed by Omair Mohammed Abdullah.
- More componentisation work from Lars-Peter Clausen.
- The remainder of the conversions of CODEC drivers to params_width()
- Drivers for Cirrus Logic CS4265, Freescale i.MX ASRC blocks, Realtek
RT286 and RT5670, Rockchip RK3xxx I2S controllers and Texas Instruments
TAS2552.
- Lots of updates and fixes, especially to the DaVinci, Intel,
Freescale, Realtek, and rcar drivers.
