GPIO_MASK was introduced in commit "df694daa3c01 [ALSA] hda-codec - Add
the support of ALC262,ALC883,ALC885,ALC861" but it's not being used. So
we can simply remove it.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The PIN number for Dell headset mode of ALC3271 is wrong.
Fixes: fcc6c877a0 ("ALSA: hda/realtek - Support Dell headset mode for ALC3271")
Signed-off-by: Shih-Yuan Lee (FourDollars) <sylee@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
platform_get_irq() returns an error code, but the ac97c
driver ignores it and always returns -ENXIO. This is not correct,
and prevents -EPROBE_DEFER from being propagated properly.
Notice that platform_get_irq() no longer returns 0 on error.
Print and propagate the return value of platform_get_irq on failure.
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
platform_get_irq() returns an error code, but the intel_hdmi_audio
driver ignores it and always returns -ENODEV. This is not correct,
and prevents -EPROBE_DEFER from being propagated properly. Also,
notice that platform_get_irq() no longer returns 0 on error.
Print error message and propagate the return value of platform_get_irq
on failure.
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
0x0285 Device ID was not used.
It just assigned for alias of ALC293 as backup.
So, remove it first.
Because our new codec will use this device ID.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In the commit fcc88d91cd ("ALSA: hda - Bind with i915 component
before codec binding"), the binding with i915 audio component is moved
to be performed always at probing the controller. This fixed the
potential problems on IVB, but now it brought another issue on HSW and
BDW. These two platforms give two individual HD-audio controllers,
one for the analog codec on PCH and another for HDMI over gfx. Since
I decided to take a lazy path to check only AZX_DRIVER_PCH type in the
commit above, now both controllers try to bind with i915, and you see
a kernel WARNING.
This patch tries to address it again properly. Now a new DCAPS bit,
AZX_DCAPS_I915_COMPONENT, is introduced for indicating the binding
with i915 component in addition to the existing I915_POWERWELL bit
flag. Each PCI entry has to give this new flag if it requires the
binding with i915 component. For HSW/BDW PCH (i.e. the ones defined
by AZX_DCAPS_INTEL_PCH) doesn't contain AZX_DCAPS_I915_COMPONENT bit
while others have it.
While we're at it, add parentheses around the bit flag check for
avoiding possible compiler warnings, too.
The bug was spotted by Intel CI tests.
Fixes: fcc88d91cd ("ALSA: hda - Bind with i915 component before codec binding")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196219
Reported-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/device.h> work with const
attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
995 608 0 1603 643 sound/pci/hda/hda_sysfs.o
File size After adding 'const':
text data bss dec hex filename
1035 544 0 1579 62b sound/pci/hda/hda_sysfs.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/device.h> work with const
attribute_group. So mark the non-const structs as const.
File size before:
text data bss dec hex filename
9781 240 8 10029 272d sound/core/pcm.o
File size After adding 'const':
text data bss dec hex filename
9813 176 8 9997 270d sound/core/pcm.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add DELL4_MIC_NO_PRESENCE model.
Add the pin configuration value of this machine into the pin_quirk
table to make DELL4_MIC_NO_PRESENCE apply to this machine.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We used a on-demand i915 component binding for IvyBridge and
SandyBridge HDMI codecs, but it has a potential problem of the nested
module loading. For avoiding that situation, assure the i915 binding
happening at the controller driver level for PCH controller devices,
where the initialization is performed in a detached work, instead of
calling from the codec driver probe.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It's nonsense to register a card object when no codec is bound on it,
as we don't support the deferred codec binding. Instead of
registering an empty card object, just skip the registration by
returning an error from azx_codec_configure().
Signed-off-by: Takashi Iwai <tiwai@suse.de>
azx_codec_configure() loops over the codecs found on the given
controller via a linked list. The code used to work in the past, but
in the current version, this may lead to an endless loop when a codec
binding returns an error.
The culprit is that the snd_hda_codec_configure() unregisters the
device upon error, and this eventually deletes the given codec object
from the bus. Since the list is initialized via list_del_init(), the
next object points to the same device itself. This behavior change
was introduced at splitting the HD-audio code code, and forgotten to
adapt it here.
For fixing this bug, just use a *_safe() version of list iteration.
Fixes: d068ebc25e ("ALSA: hda - Move some codes up to hdac_bus struct")
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In the commit 3d774d5ef0 ("ALSA: seq: Allow the tristate build of
OSS emulation") we changed CONFIG_SND_SEQUENCER_OSS to tristate, but a
couple of places were forgotten, namely, opl3 and emux Makefile.
These contain the line like
snd-opl3-synth-$(CONFIG_SND_SEQUENCER_OSS) += opl3_oss.o
and this doesn't work any longer as expected because snd-opl3-synth
can be built-in while CONFIG_SND_SEQUENCER_OSS=m.
This patch fixes these places to build properly for the new kconfig
dependency. In the end, we had to use ifneq() to satisfy the
requirement. It's a bit ugly, but lesser evil.
Fixes: 3d774d5ef0 ("ALSA: seq: Allow the tristate build of OSS emulation")
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
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.
Fixes: 3a65bcdc57 ("ALSA: hda - Fix inconsistent input_paths after ADC reduction")
Cc: <stable@vger.kernel.org>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now that user-space (typically alsa-lib) can specify which protocol
version it supports, we can optimize the kernel code depending on the
reported protocol version.
In this patch, we change the previous hack for enforcing the appl_ptr
sync by disabling status/control mmap. Instead of forcibly disabling
both mmaps, we disable only the control mmap when user-space declares
the supported protocol version new enough. For older user-space,
still both PCM status and control mmaps are disabled when requested by
the driver due to the compatibility reason.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We have an ioctl to inform the PCM protocol version the running kernel
supports, but there is no way to know which protocol version the
user-space can understand. This lack of information caused headaches
in the past when we tried to extend the ABI. For example, because we
couldn't guarantee the validity of the reserved bytes, we had to
introduce a new ioctl SNDRV_PCM_IOCTL_STATUS_EXT for assigning a few
new fields in the formerly reserved bits. If we could know that it's
a new alsa-lib, we could assume the availability of the new fields,
thus we could have reused the existing SNDRV_PCM_IOCTL_STATUS.
In order to improve the ABI extensibility, this patch adds a new ioctl
for user-space to inform its supporting protocol version to the
kernel. By reporting the supported protocol from user-space, the
kernel can judge which feature should be provided and which not.
With the addition of the new ioctl, the PCM protocol version is bumped
to 2.0.14, too. User-space checks the kernel protocol version via
SNDRV_PCM_INFO_PVERSION, then it sets the supported version back via
SNDRV_PCM_INFO_USER_PVERSION.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We have a Lenovo machine with the codec ALC294 on it, without the
patch, the Node 0x0b is regarded as the loopback mixer, but the Node
0x0b in this codec is "Vendor Defined Widget" instead of the audio
mixer, please see the log below:
Node 0x0b [Vendor Defined Widget] wcaps 0xf00000: Mono
Control: name="Beep Playback Volume", index=0, device=0
ControlAmp: chs=3, dir=In, idx=4, ofs=0
Control: name="Beep Playback Switch", index=0, device=0
ControlAmp: chs=3, dir=In, idx=4, ofs=0
And I have consulted with Realtek, so far the ALC234/274/294 all don't
have loopback mixer.
Cc: Kailang Yang <kailang@realtek.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently x86 platforms use the PCM status/control mmaps for
transferring the PCM status and appl_ptr between kernel and
user-spaces. The mmap is a most efficient way of communication, but
it has a drawback per its nature, namely, it can't notify the change
explicitly to kernel.
The lack of appl_ptr update notification is a problem on a few
existing drivers, but it's mostly a small issue and negligible.
However, a new type of driver that uses DSP for a deep buffer
management requires the exact position of appl_ptr for calculating the
buffer prefetch size, and the asynchronous appl_ptr update between
kernel and user-spaces becomes a significant problem for it.
How can we enforce user-space to report the appl_ptr update? The way
is relatively simple. Just by disabling the PCM control mmap, the
user-space is supposed to fall back to the mode using SYNC_PTR ioctl,
and the kernel gets control over that. This fallback mode is used in
all non-x86 platforms as default, and also in the 32bit compatible
model on all platforms including x86. It's been implemented already
over a decade, so we can say it's fairly safe and stably working.
With the help of the knowledge above, this patch introduces a new PCM
info flag SNDRV_PCM_INFO_SYNC_APPLPTR for achieving the appl_ptr sync
from user-space. When a driver sets this flag at open, the PCM status
/ control mmap is disabled, which effectively switches to SYNC_PTR
mode in user-space side.
In this version, both PCM status and control mmaps are disabled
although only the latter, control mmap, is the target. It's because
the current alsa-lib implementation supposes that both status and
control mmaps are always coupled, thus it handles a fatal error when
only one of them fails.
Of course, the disablement of the status/control mmaps may bring a
slight performance overhead. Thus, as of now, this should be used
only for the dedicated devices that deserves.
Note that the disablement of mmap is a sort of workaround. In the
later patch, we'll introduce the way to identify the protocol version
alsa-lib supports, and keep mmap working while the sync_ptr is
performed together.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Except ALC269.
This will reduce pop noise from headset or headphone.
If codec enter to power save state, when plug headset or headphone....
It has a chance to cut off power by system.
Our new codec use this procedure will be more stable during suspend
and resume state.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch will enable headset mode for ALC234/ALC274/ALC294 platform.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The ALSA PCM core refers to the appl_ptr value stored on the mmapped
page that is shared between kernel and user-space. Although the
reference is performed in the PCM stream lock, it doesn't guarantee
the atomic access when the value gets updated concurrently from the
user-space on another CPU.
In most of codes, this is no big problem, but still there are a few
places that may result in slight inconsistencies because they access
runtime->control->appl_ptr multiple times; that is, the second read
might be a different value from the first value. It can be even
backward or jumping, as we have no control for it. Hence, the
calculation may give an unexpected value. Luckily, there is no
security vulnerability by that, as far as I've checked. But still we
should address it.
This patch tries to reduce such possible cases. The fix is simple --
we just read once, store it to a local variable and use it for the
rest calculations. The READ_ONCE() macro is used for it in order to
avoid the ill-effect by possible compiler optimizations.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When the codec device is unregistered / freed, it may release the
resource while being used in an unsolicited event like the jack
detection work. This leads to use-after-free.
The fix here is to unregister the device at first, i.e. removing the
codec from the list, then flushing the pending works to assure that
all unsol events are gone. After this point, we're free from
accessing the codec via unsol events, thus can release the resources
gracefully.
The issue was spotted originally by Intel CI, but it couldn't be
reproduced reliably by its nature. So let's hope this fix really
addresses the whole issues.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196045
Reported-by: Martin Peres <martin.peres@free.fr>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We checked the quirks specific to the recent Intel chips by checking
the PCI IDs manually, but it's becoming messy with lots of IS_SKL()
and other macros, as the amount accumulated.
For simplification, here the new AZX_DRIVER_SKL type is introduced,
and check chip->driver_type instead of the manual PCI ID. The short
name for this is still "HDA Intel PCH", so that it doesn't break the
existing user-space unnecessarily.
Suggested-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Broxton-T was a forgotten child and we didn't apply the quirks for
Skylake+ properly. Meanwhile, a quirk for reducing the DMA latency
seems specific to the early Broxton model, so we leave as is.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Remove Initialization from POD HD500X because it's not needed.
Every time the device is connected dmesg gives the following output:
"receive length failed (error -11)".
To solve this problem, another flags is introduced
(LINE6_CAP_CONTROL_INFO) and it is only used for PODX3 in: sysfs
entries, call podhd_startup_finalize(pod) and disconnection.
With this patch the error disappear.
Signed-off-by: Hans P. Moller <hmoller@uc.cl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add support for the Line6 POD HD500X multi effect processor for
playback and capture (in/out audio) through USB.
Signed-off-by: Hans P. Moller <hmoller@uc.cl>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
At Linux v3.5, packet processing can be done in process context of ALSA
PCM application as well as software IRQ context for OHCI 1394. Below is
an example of the callgraph (some calls are omitted).
ioctl(2) with e.g. HWSYNC
(sound/core/pcm_native.c)
->snd_pcm_common_ioctl1()
->snd_pcm_hwsync()
->snd_pcm_stream_lock_irq
(sound/core/pcm_lib.c)
->snd_pcm_update_hw_ptr()
->snd_pcm_udpate_hw_ptr0()
->struct snd_pcm_ops.pointer()
(sound/firewire/*)
= Each handler on drivers in ALSA firewire stack
(sound/firewire/amdtp-stream.c)
->amdtp_stream_pcm_pointer()
(drivers/firewire/core-iso.c)
->fw_iso_context_flush_completions()
->struct fw_card_driver.flush_iso_completion()
(drivers/firewire/ohci.c)
= flush_iso_completions()
->struct fw_iso_context.callback.sc
(sound/firewire/amdtp-stream.c)
= in_stream_callback() or out_stream_callback()
->...
->snd_pcm_stream_unlock_irq
When packet queueing error occurs or detecting invalid packets in
'in_stream_callback()' or 'out_stream_callback()', 'snd_pcm_stop_xrun()'
is called on local CPU with disabled IRQ.
(sound/firewire/amdtp-stream.c)
in_stream_callback() or out_stream_callback()
->amdtp_stream_pcm_abort()
->snd_pcm_stop_xrun()
->snd_pcm_stream_lock_irqsave()
->snd_pcm_stop()
->snd_pcm_stream_unlock_irqrestore()
The process is stalled on the CPU due to attempt to acquire recursive lock.
[ 562.630853] INFO: rcu_sched detected stalls on CPUs/tasks:
[ 562.630861] 2-...: (1 GPs behind) idle=37d/140000000000000/0 softirq=38323/38323 fqs=7140
[ 562.630862] (detected by 3, t=15002 jiffies, g=21036, c=21035, q=5933)
[ 562.630866] Task dump for CPU 2:
[ 562.630867] alsa-source-OXF R running task 0 6619 1 0x00000008
[ 562.630870] Call Trace:
[ 562.630876] ? vt_console_print+0x79/0x3e0
[ 562.630880] ? msg_print_text+0x9d/0x100
[ 562.630883] ? up+0x32/0x50
[ 562.630885] ? irq_work_queue+0x8d/0xa0
[ 562.630886] ? console_unlock+0x2b6/0x4b0
[ 562.630888] ? vprintk_emit+0x312/0x4a0
[ 562.630892] ? dev_vprintk_emit+0xbf/0x230
[ 562.630895] ? do_sys_poll+0x37a/0x550
[ 562.630897] ? dev_printk_emit+0x4e/0x70
[ 562.630900] ? __dev_printk+0x3c/0x80
[ 562.630903] ? _raw_spin_lock+0x20/0x30
[ 562.630909] ? snd_pcm_stream_lock+0x31/0x50 [snd_pcm]
[ 562.630914] ? _snd_pcm_stream_lock_irqsave+0x2e/0x40 [snd_pcm]
[ 562.630918] ? snd_pcm_stop_xrun+0x16/0x70 [snd_pcm]
[ 562.630922] ? in_stream_callback+0x3e6/0x450 [snd_firewire_lib]
[ 562.630925] ? handle_ir_packet_per_buffer+0x8e/0x1a0 [firewire_ohci]
[ 562.630928] ? ohci_flush_iso_completions+0xa3/0x130 [firewire_ohci]
[ 562.630932] ? fw_iso_context_flush_completions+0x15/0x20 [firewire_core]
[ 562.630935] ? amdtp_stream_pcm_pointer+0x2d/0x40 [snd_firewire_lib]
[ 562.630938] ? pcm_capture_pointer+0x19/0x20 [snd_oxfw]
[ 562.630943] ? snd_pcm_update_hw_ptr0+0x47/0x3d0 [snd_pcm]
[ 562.630945] ? poll_select_copy_remaining+0x150/0x150
[ 562.630947] ? poll_select_copy_remaining+0x150/0x150
[ 562.630952] ? snd_pcm_update_hw_ptr+0x10/0x20 [snd_pcm]
[ 562.630956] ? snd_pcm_hwsync+0x45/0xb0 [snd_pcm]
[ 562.630960] ? snd_pcm_common_ioctl1+0x1ff/0xc90 [snd_pcm]
[ 562.630962] ? futex_wake+0x90/0x170
[ 562.630966] ? snd_pcm_capture_ioctl1+0x136/0x260 [snd_pcm]
[ 562.630970] ? snd_pcm_capture_ioctl+0x27/0x40 [snd_pcm]
[ 562.630972] ? do_vfs_ioctl+0xa3/0x610
[ 562.630974] ? vfs_read+0x11b/0x130
[ 562.630976] ? SyS_ioctl+0x79/0x90
[ 562.630978] ? entry_SYSCALL_64_fastpath+0x1e/0xad
This commit fixes the above bug. This assumes two cases:
1. Any error is detected in software IRQ context of OHCI 1394 context.
In this case, PCM substream should be aborted in packet handler. On the
other hand, it should not be done in any process context. TO distinguish
these two context, use 'in_interrupt()' macro.
2. Any error is detect in process context of ALSA PCM application.
In this case, PCM substream should not be aborted in packet handler
because PCM substream lock is acquired. The task to abort PCM substream
should be done in ALSA PCM core. For this purpose, SNDRV_PCM_POS_XRUN is
returned at 'struct snd_pcm_ops.pointer()'.
Suggested-by: Clemens Ladisch <clemens@ladisch.de>
Fixes: e9148dddc3c7("ALSA: firewire-lib: flush completed packets when reading PCM position")
Cc: <stable@vger.kernel.org> # 4.9+
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Just a tidy up to follow the standard EXPORT_SYMBOL*() declarations
in order to improve grep-ability.
- Move EXPORT_SYMBOL*() to the position right after its definition
- Remove superfluous blank line before EXPORT_SYMBOL*() lines
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Just a tidy up to follow the standard EXPORT_SYMBOL*() declarations
in order to improve grep-ability.
- Move EXPORT_SYMBOL*() to the position right after its definition
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Just a tidy up to follow the standard EXPORT_SYMBOL*() declarations
in order to improve grep-ability.
- Move EXPORT_SYMBOL*() to the position right after its definition
- Remove superfluous blank line before EXPORT_SYMBOL*() lines
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Just a tidy up to follow the standard EXPORT_SYMBOL*() declarations
in order to improve grep-ability.
- Remove superfluous blank line before EXPORT_SYMBOL*() lines
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add this functions, it could support ALC256 for HP depop functions.
It also can solve some ALC256 machine plug headset cause power
off issue.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Use dma_alloc_attrs directly instead of the dma_alloc_noncoherent wrapper.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The standard PCM chmap helper callbacks treat the NULL info->chmap as
a fatal error and spews the kernel warning with stack trace when
CONFIG_SND_DEBUG is on. This was OK, originally it was supposed to be
always static and non-NULL. But, as the recent addition of Intel LPE
audio driver shows, the chmap content may vary dynamically, and it can
be even NULL when disconnected. The user still sees the kernel
warning unnecessarily.
For clearing such a confusion, this patch simply removes the
snd_BUG_ON() in each place, just returns an error without warning.
Cc: <stable@vger.kernel.org> # v4.11+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Drivers can implement 'struct snd_pcm_ops.ioctl' to handle some requests
from ALSA PCM core. These requests are internal purpose in kernel land.
Usually common set of operations are used for it.
SNDRV_PCM_IOCTL1_INFO is one of the requests. According to code comment,
it has been obsoleted in the old days.
We can see old releases in ftp.alsa-project.org. The command was firstly
introduced in v0.5.0 release as SND_PCM_IOCTL1_INFO, to allow drivers to
fill data of 'struct snd_pcm_channel_info' type. In v0.9.0 release,
this was obsoleted by the other commands for ioctl(2) such as
SNDRV_PCM_IOCTL_CHANNEL_INFO.
This commit removes the long-abandoned command, bye.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Coffelake is another Intel part, so need to add PCI ID for it.
Signed-off-by: Megha Dey <megha.dey@intel.com>
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We call ack callback whenever appl_ptr gets updated via
pcm_lib_apply_appl_ptr(). There are various code paths to call this
function. A part of them are for read/write/forward/rewind, where the
appl_ptr is always changed and thus the call of ack is mandatory.
OTOH, another part of code paths are from the explicit user call,
e.g. via SYNC_PTR ioctl. There, we may receive the same appl_ptr
value, and in such a case, calling ack is obviously superfluous.
This patch adds the check of the given appl_ptr value, and returns
immediately if it's no real update.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Calling PREPARE ioctl to the stream in either PAUSED or SUSPENDED
state may confuse some drivers that don't handle the state properly.
Instead of fixing each driver, PCM core should take care of the proper
state change before actually trying to (re-)prepare the stream.
Namely, when the stream is in PAUSED state, it triggers PAUSE_RELEASE,
and when in SUSPENDED state, it triggers STOP, before calling prepare
callbacks.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
So far, the PCM core refuses DROP ioctl when the stream in the
suspended state. This was basically to avoid the invalid state change
*during* the suspend. But since we protect the power change globally
in the common PCM ioctl caller side, it's guaranteed that
snd_pcm_drop() is called at the right power state. So we can assume
that the drop of stream is safe immediately after SUSPENDED state.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
All PCM common ioctls should run only in the powered up state, but
currently only a few ioctls do the proper snd_power_lock() and
snd_power_wait() invocations. Instead of adding to each place, do it
commonly in the caller side, so that all these ioctls are assured to
be operated at the power up state.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Use snd_pcm_action_lock_irq() helper instead of open coding.
No functional change.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As long as I know, in userspace, '%c' format on printing format for
tracepoint is replaced with '>c<' by existent tracing program; i.g.
'perf-trace' and 'trace-cmd'. This is inconvenient.
This commit replaces the format with '%s'. The length of letters in the
format string is not changed, thus this commit doesn't increase object
size.
In theory, I should work for improvements of these tracing programs, but
here I'd like to save my time to work for the other projects.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In design of ALSA PCM core, status and control data for runtime of ALSA
PCM substream are shared between kernel/user spaces by page frame
mapping with read-only attribute. Both of hardware-side and
application-side position on PCM buffer are maintained as a part of
the status data. In a view of ALSA PCM application, these two positions
can be updated by executing ioctl(2) with some commands.
There's an event of tracepoint for hardware-side position; 'hwptr'.
On the other hand, no events for application-side position. This commit
adds a new event for this purpose; 'applptr'. When the application-side
position is changed in kernel space, this event is probed with useful
information for developers.
I note that the event is not probed for all of ALSA PCM applications, When
applications are written by read/write programming scenario, the event is
surely probed. The applications execute ioctl(2) with
SNDRV_PCM_IOCTL_[READ|WRITE][N/I]_FRAMES to read/write any PCM frame, then
ALSA PCM core updates the application-side position in kernel land.
However, when applications are written by mmap programming scenario, if
maintaining the application side position in kernel space accurately,
applications should voluntarily execute ioctl(2) with
SNDRV_PCM_IOCTL_SYNC_PTR to commit the number of handled PCM frames. If
not voluntarily, the application-side position is not changed, thus the
added event is not probed.
There's a loophole, using architectures to which ALSA PCM core judges
non cache coherent. In this case, the status and control data is not mapped
into processe's VMA for any applications. Userland library, alsa-lib, is
programmed for this case. It executes ioctl(2) with
SNDRV_PCM_IOCTL_SYNC_PTR command every time to requiring the status and
control data.
ARM is such an architecture. Below is an example with serial sound interface
(ssi) on i.mx6 quad core SoC. I use v4.1 kernel released by fsl-community
with patches from VIA Tech. Inc. for VAB820, and my backport patches for
relevant features for this patchset. I use Ubuntu 17.04 from
ports.ubuntu.com as user land for armhf architecture.
$ aplay -v -M -D hw:imx6vab820sgtl5,0 /dev/urandom -f S16_LE -r 48000 --period-size=128 --buffer-size=256
Playing raw data '/dev/urandom' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono
Hardware PCM card 0 'imx6-vab820-sgtl5000' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : MMAP_INTERLEAVED
format : S16_LE
subformat : STD
channels : 1
rate : 48000
exact rate : 48000 (48000/1)
msbits : 16
buffer_size : 256
period_size : 128
period_time : 2666
tstamp_mode : NONE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 128
period_event : 0
start_threshold : 256
stop_threshold : 256
silence_threshold: 0
silence_size : 0
boundary : 1073741824
appl_ptr : 0
hw_ptr : 0
mmap_area[0] = 0x76f98000,0,16 (16)
$ trace-cmd record -e snd_pcm:hwptr -e snd_pcm:applptr
$ trace-cmd report
...
60.208495: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=0, period=128, buf=256
60.208633: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=0, period=128, buf=256
60.210022: hwptr: pcmC0D0p/sub0: IRQ: pos=128, old=1536, base=1536, period=128, buf=256
60.210202: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256
60.210344: hwptr: pcmC0D0p/sub0: POS: pos=128, old=1664, base=1536, period=128, buf=256
60.210348: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256
60.210486: applptr: pcmC0D0p/sub0: prev=1792, curr=1792, avail=128, period=128, buf=256
60.210626: applptr: pcmC0D0p/sub0: prev=1792, curr=1920, avail=0, period=128, buf=256
60.211002: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256
60.211142: hwptr: pcmC0D0p/sub0: POS: pos=128, old=1664, base=1536, period=128, buf=256
60.211146: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256
60.211287: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=0, period=128, buf=256
60.212690: hwptr: pcmC0D0p/sub0: IRQ: pos=0, old=1664, base=1536, period=128, buf=256
60.212866: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256
60.212999: hwptr: pcmC0D0p/sub0: POS: pos=0, old=1792, base=1792, period=128, buf=256
60.213003: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256
60.213135: applptr: pcmC0D0p/sub0: prev=1920, curr=1920, avail=128, period=128, buf=256
60.213276: applptr: pcmC0D0p/sub0: prev=1920, curr=2048, avail=0, period=128, buf=256
60.213654: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256
60.213796: hwptr: pcmC0D0p/sub0: POS: pos=0, old=1792, base=1792, period=128, buf=256
60.213800: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256
60.213937: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=0, period=128, buf=256
60.215356: hwptr: pcmC0D0p/sub0: IRQ: pos=128, old=1792, base=1792, period=128, buf=256
60.215542: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256
60.215679: hwptr: pcmC0D0p/sub0: POS: pos=128, old=1920, base=1792, period=128, buf=256
60.215683: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256
60.215813: applptr: pcmC0D0p/sub0: prev=2048, curr=2048, avail=128, period=128, buf=256
60.215947: applptr: pcmC0D0p/sub0: prev=2048, curr=2176, avail=0, period=128, buf=256
...
We can surely see 'applptr' event is probed even if the application run
for mmap programming scenario ('-M' option and 'hw' plugin). Below is a
result of strace:
02:44:15.886382 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.887203 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
02:44:15.887471 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.887637 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.887805 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.887969 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.888132 read(3, "..."..., 256) = 256
02:44:15.889040 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.889221 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.889431 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.889606 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
02:44:15.889833 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.889998 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.890164 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.891048 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.891228 read(3, "..."..., 256) = 256
02:44:15.891497 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.891661 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.891829 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
02:44:15.891991 poll([{fd=4, events=POLLOUT|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
02:44:15.893007 ioctl(4, SNDRV_PCM_IOCTL_SYNC_PTR, 0x56a32b30) = 0
We can see 7 calls of ioctl(2) with SNDRV_PCM_IOCTL_SYNC_PTR per loop with
call of poll(2). 128 PCM frames are transferred per loop of one poll(2),
because the PCM substream is configured with S16_LE format and 1 channel
(2 byte * 1 * 128 = 256 bytes). This equals to the size of period of PCM
buffer. Comparing to the probed data, one of the 7 calls of ioctl(2) is
actually used to commit the number of copied PCM frames to kernel space.
The other calls are just used to check runtime status of PCM substream;
e.g. XRUN.
The tracepoint event is useful to investigate this case. I note that below
modules are related to the above sample.
* snd-soc-dummy.ko
* snd-soc-imx-sgtl5000.ko
* snd-soc-fsl-ssi.ko
* snd-soc-imx-pcm-dma.ko
* snd-soc-sgtl5000.ko
My additional note is lock acquisition. The event is probed under acquiring
PCM stream lock. This means that calculation in the event is free from
any hardware events.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In a series of recent work, ALSA PCM core got some arrangements to handle
application-side position on PCM buffer. However, relevant codes still
disperse to two translation units
This commit unifies these codes into a helper function.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
