The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Since the driver requires the DMA32 allocation, it passes the
specially encoded device to snd_pcm_lib_preallocate_pages().
Link: https://lore.kernel.org/r/20191105151856.10785-17-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Since the driver requires the DMA32 allocation, it passes the
specially encoded device to snd_pcm_lib_preallocate_pages().
Link: https://lore.kernel.org/r/20191105151856.10785-16-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-15-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-14-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-13-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-12-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page
mapping in the default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-10-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Also, since the SG-buffer-specific PCM ops becomes identical with the
normal PCM ops, unify them again to the single ops, too.
Link: https://lore.kernel.org/r/20191105151856.10785-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c55: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c55: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c55: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c55: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c55: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (commit 08422d2c55: "ALSA: memalloc: Allow NULL
device for SNDRV_DMA_TYPE_CONTINUOUS type") made the PCM preallocation
helper accepting NULL as the device pointer for the default usage.
Drop the snd_dma_continuous_data() usage that became superfluous from
the callers.
Link: https://lore.kernel.org/r/20191105151856.10785-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It makes little sense to create prealloc proc files for streams that
have the zero max size, which is a typical case for vmalloc buffers.
Skip the proc file creations to save resources in such a case.
Link: https://lore.kernel.org/r/20191105191007.18150-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Warn if snd_pcm_lib_preallocate_pages*() is applied to the stream that
has already the preallocated buffers and skip the allocation. It's a
clearly a driver bug.
Link: https://lore.kernel.org/r/20191105191007.18150-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When a driver needs to deal with a special buffer like a SG or a
vmalloc buffer, it has to set up the PCM page ops explicitly for the
corresponding helper function. This is rather error-prone and many
people forgot or incorrectly used it.
For simplifying the call patterns and avoiding such a potential bug,
this patch enhances the PCM default mmap handler to check the
(pre-)allocated buffer type and handles the page gracefully depending
on the buffer type. If the PCM page ops is given, the ops is still
used in a higher priority. The new code path is only for the default
(NULL page ops) case.
Link: https://lore.kernel.org/r/20191105080138.1260-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds the vmalloc buffer support to ALSA memalloc core. A
new type, SNDRV_DMA_TYPE_VMALLOC was added.
The vmalloc buffer has been already supported in the PCM via a few own
helper functions, but the user sometimes get confused and misuse
them. With this patch, the whole buffer management is integrated into
the memalloc core, so they can be used in a sole common way.
Link: https://lore.kernel.org/r/20191105080138.1260-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently we pass the artificial device pointer to the allocation
helper in the case of SNDRV_DMA_TYPE_CONTINUOUS for passing the GFP
flags. But all common cases are the allocations with GFP_KERNEL, and
it's messy to put this in each place.
In this patch, the memalloc core helper is changed to accept the NULL
device pointer and it treats as the default mode, GFP_KERNEL, so that
all callers can omit the complex argument but just leave NULL.
Link: https://lore.kernel.org/r/20191105080138.1260-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Since we apply the own mutex (bus->cmd_mutex) in HDA core side, the
internal locking in regmap is superfluous. This patch adds the flag
to indicate that.
Also, an infamous side-effect by this change is that it disables the
regmap debugfs, too, and this is seen rather good; the regmap debugfs
isn't quite useful for HD-audio as it provides the very sparse
registers and its debugfs access tends to lead to the way too high
resource usages or sometimes hang up. So it'd be rather safe to
disable it altogether.
Link: https://lore.kernel.org/r/2029139028.10333037.1572874551626.JavaMail.zimbra@redhat.com
Link: https://lore.kernel.org/r/20191105081806.4896-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The check for the mmap support via hw_support_mmap() function misses
the case where the device is with SNDRV_DMA_TYPE_DEV_UC, which should
have been treated equally as SNDRV_DMA_TYPE_DEV. Let's fix it.
Note that this bug doesn't hit any practical problem, because
SNDRV_DMA_TYPE_DEV_UC is used only for x86-specific drivers
(snd-hda-intel and snd-intel8x0) for the specific platforms that need
the non-cached buffers. And, on such platforms, hw_support_mmap()
already returns true in anyway. That's the reason I didn't put
Cc-to-stable mark here. This is only for any theoretical future
extension.
Fixes: 425da15970 ("ALSA: pcm: use dma_can_mmap() to check if a device supports dma_mmap_*")
Fixes: 42e748a0b3 ("ALSA: memalloc: Add non-cached buffer type")
Link: https://lore.kernel.org/r/20191104101115.27311-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Originally BeBeB ASICs and firmware supports clock mode to synchronizing
to syt field of received isoc packet. This mode is known as 'SYT Match'
slightly described in IEC 61883-6 (but no detail mechanisms). In this
mode, drivers can control sampling clock in device. Driver for Windows
and macOS uses this feature to perform synchronization for devices
on the same bus.
In this mode, a plug of Music subunit for synchronization is connected
to a plug of isoc unit for incoming packet streaming, then the order to
establish connections is INPUT_PLUG first, OUTPUT_PLUG second.
This commit implements the above.
Actually each device works with its own clock for sampling, therefore
the original design is hardly implemented to vendor's products.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191101131323.17300-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As long as I investigated, there's some cases about the delay for device
between establishing OUTPUT_PLUG and transmitting first isoc packet. For
devices which support BeBoB protocol version 1 can transmit the packet
within several hundred milliseconds, while for devices which support
BeBoB protocol version 3 can transmit the packet within 2 seconds.
Devices with protocol version 1:
* Edirol FA-66
* Yamaha GO46
* Terratec Phase x24 FW
* M-Audio FireWire AudioPhile
* M-Audio FireWire Solo
* M-Audio FireWire 1814
* M-Audio FireWire 410
* Focusrite Saffire Pro 26 I/O
Devices with protocol version 3:
* M-Audio Profire Lightbridge
* Behringer FCA610
* Phonic Firefly 202
At present ALSA bebob driver postpones starting IR context during
1.5 sec for all of supported devices. The delay is too long for
devices with protocol version 1, while it's not enough for devices with
protocol version 3.
This commit improves the delay for these protocols.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191101131323.17300-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As long as I investigated, some devices with BeBoB protocol version 1
can be freezed during several hundreds milliseconds after breaking
connections. When accessing during the freezed time, any transaction
is corrupted. In the worst case, the device is going to reboot.
I can see this issue in:
* Roland FA-66
* M-Audio FireWire Solo
This commit expands sleep just after breaking connections to avoid
the freezed time as much as possible. I note that the freeze/reboot
behaviour is similar to below models:
* Focusrite Saffire Pro 10 I/O
* Focusrite Saffire Pro 26 I/O
The above models certainly reboot after breaking connections.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191101131323.17300-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Just fix a typo of "S/PDIF" in the clock name string.
Fixes: 4638ec6ede ("ALSA: firewire-motu: add proc node to show current statuc of clock and packet formats")
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191030100921.3826-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In MOTU FireWire series, devices which support protocol version 2 have
several types of hardware design to process audio data frames for isoc
packet. Roughly devices are categorized into three groups:
- 828mkII
- Traveler/896HD
- UltraLite/8pre FireWire
Some bit flags in register addressed by 0x'ffff'f000'0b14
includes device-specific effects.
This commit cleanups implementation of protocol v2 in this point.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191030080644.1704-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit adds some helper functions to parse register value for
source of sampling clock and nominal sampling transmission frequency.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191030080644.1704-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In MOTU FireWire series, devices have a mode to generate sampling clock
from a sequence of source packet header (SPH) included in each data block
of received packet. This mode is used for several purposes such as mode
for SMPTE time code, sync to the other sound cards and so on.
This commit adds support for the SPH mode.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191030080644.1704-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When unknown source is detected for sampling clock, corresponding label
was not added for node on procfs.
This commit adds it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191030080644.1704-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Use true/false for bool type return in uac_clock_source_is_valid().
Signed-off-by: Saurav Girepunje <saurav.girepunje@gmail.com>
Link: https://lore.kernel.org/r/20191029175200.GA7320@saurav
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent addition of snd_intel_dsp_driver_probe() check caused a
spurious kernel warning when the driver is loaded for a non-Intel
hardware due to snd_BUG_ON(). Moreover, for such a hardware, we
should always return SND_INTEL_DSP_DRIVER_ANY, not check the
dsp_driver option at all.
This patch fixes these issues for non-Intel devices.
Fixes: 82d9d54a6c ("ALSA: hda: add Intel DSP configuration / probe code")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20191028130634.3501-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is an alternative fix attemp for the issue reported in the commit
caa8422d01 ("ALSA: hda: Flush interrupts on disabling") that was
reverted later due to regressions. Instead of tweaking the hardware
disablement order and the enforced irq flushing, do calling
cancel_work_sync() of the unsol work early enough, and explicitly
ignore the unsol events during the shutdown by checking the
bus->shutdown flag.
Fixes: caa8422d01 ("ALSA: hda: Flush interrupts on disabling")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://lore.kernel.org/r/s5h1ruxt9cz.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit caa8422d01.
It turned out that this commit caused a regression at shutdown /
reboot, as the synchronize_irq() calls seems blocking the whole
shutdown. Also another part of the change about shuffling the call
order looks suspicious; the azx_stop_chip() call disables the CORB /
RIRB while the others may still need the CORB/RIRB update.
Since the original commit itself was a cargo-fix, let's revert the
whole patch.
Fixes: caa8422d01 ("ALSA: hda: Flush interrupts on disabling")
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=205333
BugLinK: https://bugs.freedesktop.org/show_bug.cgi?id=111174
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://lore.kernel.org/r/20191028081056.22010-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A helper function of ALSA bebob driver returns negative value in a
function which has a prototype to return unsigned value.
This commit fixes it by changing the prototype.
Fixes: eb7b3a056c ("ALSA: bebob: Add commands and connections/streams management")
Cc: <stable@vger.kernel.org> # v3.16+
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191026030620.12077-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
platform_get_irq() will call dev_err() itself on failure,
so there is no need for the driver to also do this.
This is detected by coccinelle.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20191025093905.14888-1-yuehaibing@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
These 2 ThinkCentres installed a new realtek codec ID 0x623,
it has 2 front mics with the same location on pin 0x18 and 0x19.
Apply fixup ALC283_FIXUP_HEADSET_MIC to change 1 front mic
location to right, then pulseaudio can handle them.
One "Front Mic" and one "Mic" will be shown, and audio output works
fine.
Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191024114439.31522-1-aaron.ma@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reshuffle list of devices by historical order and add correct
information as needed.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20191022174313.29087-2-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For distributions, we need one place where we can decide
which driver will be activated for the auto-configation of the
Intel's HDA hardware with DSP. Actually, we cover three drivers:
* Legacy HDA
* Intel SST
* Intel Sound Open Firmware (SOF)
All those drivers registers similar PCI IDs, so the first
driver probed from the PCI stack can win. But... it is not
guaranteed that the correct driver wins.
This commit changes Intel's NHLT ACPI module to a common
DSP probe module for the Intel's hardware. All above sound
drivers calls this code. The user can force another behaviour
using the module parameter 'dsp_driver' located in
the 'snd-intel-dspcfg' module.
This change allows to add specific dmi checks for the specific
systems. The examples are taken from the pull request:
https://github.com/thesofproject/linux/pull/927
Tested on Lenovo Carbon X1 7th gen.
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Tested-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20191022174313.29087-1-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recently introduced USB-audio descriptor validator had a stupid
copy&paste error that may lead to an unexpected overlook of too short
descriptors for processing and extension units. It's likely the cause
of the report triggered by syzkaller fuzzer. Let's fix it.
Fixes: 57f8770620 ("ALSA: usb-audio: More validations of descriptor units")
Reported-by: syzbot+0620f79a1978b1133fd7@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/s5hsgnkdbsl.wl-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The inline prefix was missing in the dummy function pci_pr3_present()
definition. Fix it.
Reported-by: kbuild test robot <lkp@intel.com>
Fixes: 52525b7a3c ("PCI: Add a helper to check Power Resource Requirements _PR3 existence")
Link: https://lore.kernel.org/r/201910212111.qHm6OcWx%lkp@intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Nvidia proprietary driver doesn't support runtime power management, so
when a user only wants to use the integrated GPU, it's a common practice
to let dGPU not to bind any driver, and let its upstream port to be
runtime suspended. At the end of runtime suspension the port uses
platform power management to disable power through _OFF method of power
resource, which is listed by _PR3.
After commit b516ea586d ("PCI: Enable NVIDIA HDA controllers"), when
the dGPU comes with an HDA function, the HDA won't be suspended if the
dGPU is unbound, so the power resource can't be turned off by its
upstream port driver.
Commit 37a3a98ef6 ("ALSA: hda - Enable runtime PM only for
discrete GPU") only allows HDA to be runtime suspended once GPU is
bound, to keep APU's HDA working.
However, HDA on dGPU isn't that useful if dGPU is not bound to any
driver. So let's relax the runtime suspend requirement for dGPU's HDA
function, to disable the power source to save lots of power.
BugLink: https://bugs.launchpad.net/bugs/1840835
Fixes: b516ea586d ("PCI: Enable NVIDIA HDA controllers")
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Link: https://lore.kernel.org/r/20191018073848.14590-2-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
