| Age | Commit message (Collapse) | Author |
|---|
|
This doesn't do anything snd_emu10k1_init() wouldn't do later, and none
of the things it does seem relevant for the function itself (which is
pretty much about setting up the FPGA). It was probably a Windows
driver behavior cargo-culting artifact.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230421141006.1005539-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
As the register definition clearly states, this is a 16-bit register,
yet we did all accesses as 32-bit. The writes in particular would have
the potential to clear the TIMER register (depending on how the bus/card
actually handles the too long writes).
This commit also introduces a separate define A_GPIO which aliases
A_IOCFG, which better reflects the distinct usage on E-MU cards.
This is done in the same commit to keep the churn down, as we're
touching all involved lines anyway.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230421141006.1005539-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Assert the validity of the registers and values, as them being out of
range would indicate an error in the driver. Consequently, don't bother
returning error codes; they were ignored everywhere anyway.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230421141006.1005539-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Detach it better from the main PCM driver, which it really doesn't have
much in common with.
In particular, this moves the interrupt handler implementation into
p16v.c, and makes it access the substream runtime status more directly,
so it doesn't need to abuse structs snd_emu10k1_pcm and
snd_emu10k1_voice any more.
We don't need private pcm runtime data at all, as the only thing it was
used for (except the back-link to the substream) was the `running` flag.
So store that directly in runtime->private_data.
This somewhat radical strip-down shows that this driver contains some
complexity that was never actually utilized. I suppose the right way to
fully utilize the hardware in a simple way would be introducing more
substreams. This wouldn't require any of the removed code.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230421141006.1005452-7-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
It was written, but never read from. Its value is available via the epcm
field.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230421141006.1005452-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
It's just an (outdated) copy of snd_emu10k1_playback_pointer().
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230421141006.1005452-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Or actually, replace snd_emu10k1_playback_hw_free() with it, as that is
a subset.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230421141006.1005452-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
extin_mask and extout_mask are used only by the SbLive! microcode, so
they have no effect on Audigy.
Eliminate fxbus_mask entirely, as it wasn't actually used for anything.
As a drive-by, remove the pointless pad1 field from struct
snd_emu10k1_fx8010 - it is not visible to user space, so it has no
binary compatibility constraints.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230421141006.1005509-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
When an error occurs during USB disconnection sometimes things can go
wrong as endpoint_set_interface may end up being called repeatedly. For
example:
% dmesg --notime | grep 'usb 3-7.1.4' | sort | uniq -c | head -2
3069 usb 3-7.1.4: 1:1: usb_set_interface failed (-19)
908 usb 3-7.1.4: 1:1: usb_set_interface failed (-71)
In my case, there sometimes are hundreds of these usb_set_interface
failure messages a second when I disconnect the hub that has my USB
audio device.
These messages can take a huge amount of the kmsg ringbuffer and don't
provide any extra information over the previous ones, so ratelimit them.
Signed-off-by: Chris Down <chris@chrisdown.name>
Link: https://lore.kernel.org/r/ZEKf8UYBYa1h4JWR@chrisdown.name
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The auto-silencer supports two modes: "thresholded" to fill up "just
enough", and "top-up" to fill up "as much as possible". The two modes
used rather distinct code paths, which this patch unifies. The only
remaining distinction is how much we actually want to fill.
This fixes a bug in thresholded mode, where we failed to use new_hw_ptr,
resulting in under-fill.
Top-up mode is now more well-behaved and much easier to understand in
corner cases.
This also updates comments in the proximity of silencing-related data
structures.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230420113324.877164-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_property/of_find_property functions for reading properties.
Convert reading boolean properties to to of_property_read_bool().
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230310144734.1546587-1-robh@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
It is preferred to use typed property access functions (i.e.
of_property_read_<type> functions) rather than low-level
of_get_property/of_find_property functions for reading properties. As
part of this, convert of_get_property/of_find_property calls to the
recently added of_property_present() helper when we just want to test
for presence of a property and nothing more.
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230310144733.1546500-1-robh@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
These snd_BUG_ON() can never trigger, so just remove them to save a few
LoC.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/91a31341f32d493bcc6c4515178ce0755ac1aa70.1681710069.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Add HD Audio PCI ID for Intel Lunarlake platform.
Signed-off-by: Fred Oh <fred.oh@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20230406152500.15104-1-pierre-louis.bossart@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
... in wait_for_avail() and snd_pcm_drain().
t was calculated in seconds, so it would be pretty much always zero, to
be subsequently de-facto ignored due to being max(t, 10)'d. And then it
(i.e., 10) would be treated as secs, which doesn't seem right.
However, fixing it to properly calculate msecs would potentially cause
timeouts when using twice the period size for the default timeout (which
seems reasonable to me), so instead use the buffer size plus 10 percent
to be on the safe side ... but that still seems insufficient, presumably
because the hardware typically needs a moment to fire up. To compensate
for this, we up the minimal timeout to 100ms, which is still two orders
of magnitude less than the bogus minimum.
substream->wait_time was also misinterpreted as jiffies, despite being
documented as being in msecs. Only the soc/sof driver sets it - to 500,
which looks very much like msecs were intended.
Speaking of which, shouldn't snd_pcm_drain() also use substream->
wait_time?
As a drive-by, make the debug messages on timeout less confusing.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230405201219.2197774-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The newer E-MU cards weren't mentioned at all.
The "partially supported" is removed ahead of it becoming mostly untrue.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230405201220.2197908-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
clang with W=1 reports
sound/pci/asihpi/hpi6000.c:1256:6: error: variable
'loop_count' set but not used [-Werror,-Wunused-but-set-variable]
u32 loop_count = 0;
^
This variable is not used so remove it.
Signed-off-by: Tom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20230326205712.1358918-1-trix@redhat.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The macro for said register already exists, so just use it, to make the
code more readable.
Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
Link: https://lore.kernel.org/r/20230329043918.179352-1-tasos@tasossah.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
There's no need to switch between unsigned short and u16, especially since
all the functions that end up using old_legacy_ctrl specify u16 anyway.
Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
Link: https://lore.kernel.org/r/20230329043627.178899-1-tasos@tasossah.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
YMF744 and newer store the base IO ports in separate PCI config registers.
Since these registers were not restored, when set to a non-default value,
features that rely on them (FM, MPU401, gameport) were not functional
after restore, as their respective IO ports were reset to their defaults.
Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
Link: https://lore.kernel.org/r/20230329041440.177363-5-tasos@tasossah.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
In preparation for storing more than two legacy PCI registers, the
existing ones are moved into a new array.
Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
Link: https://lore.kernel.org/r/20230329041440.177363-4-tasos@tasossah.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The registers were previously allocated when CONFIG_PM_SLEEP was set,
however this only saved an insignificant amount of memory otherwise.
Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
Link: https://lore.kernel.org/r/20230329041440.177363-3-tasos@tasossah.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Since commit 1a3c7bb08826 ("PM: core: Add new *_PM_OPS macros, deprecate
old ones") SIMPLE_DEV_PM_OPS has been marked deprecated.
The intent is to remove CONFIG_PM_SLEEP guards for PM callbacks. As such
the ifdefs are now removed.
Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
Link: https://lore.kernel.org/r/20230329041440.177363-2-tasos@tasossah.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
As an end user, it can be confusing to request an arbitrary IO port be
used only to find out that it doesn't work without an obvious reason,
especially since /sys/module/snd_ymfpci/parameters/{fm,joystick,mpu}_port
indicate 0 after the module has been loaded.
In my case, I was unaware that the YMF724 did not support such usage, and
thus ended up spending time attempting to debug the issue.
Now, when a user attempts to request an IO port that isn't supported by
the hardware, the following message is printed:
[ 25.549530] snd_ymfpci 0000:06:05.0: The Yamaha DS-1 (YMF724F) does not support arbitrary IO ports for FM (requested 0x1234)
Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
Link: https://lore.kernel.org/r/20230329034204.171901-1-tasos@tasossah.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Back-merge of 6.3 devel branch for further changes of PCM and
documentation.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
It's been reported that the recent kernel can't probe the PCM devices
on Roland VS-100 properly, and it turned out to be a regression by the
recent addition of the bit shift range check for the format bits.
In the old code, we just did bit-shift and it resulted in zero, which
is then corrected to the standard PCM format, while the new code
explicitly returns an error in such a case.
For addressing the regression, relax the check and fallback to the
standard PCM type (with the info output).
Fixes: 43d5ca88dfcd ("ALSA: usb-audio: Fix potential out-of-bounds shift")
Cc: <stable@vger.kernel.org>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217084
Link: https://lore.kernel.org/r/20230324075005.19403-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
clang with W=1 reports
sound/pci/rme9652/hdspm.c:6149:19: error: unused function
'copy_u32_le' [-Werror,-Wunused-function]
static inline int copy_u32_le(void __user *dest, void __iomem *src)
^
This function is not used so remove it.
Signed-off-by: Tom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20230323202713.2637150-1-trix@redhat.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Unfortunately, in commit 5911d78fabbb a wrong codec patch was selected.
The model=alc283-dac-wcaps is equivalent to ALC283_FIXUP_CHROME_BOOK not
ALC295_FIXUP_CHROME_BOOK.
Fixes: 5911d78fabbb ("ALSA: hda/realtek: Improve support for Dell Precision 3260")
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230322153404.386473-1-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The recent support of low latency playback in USB-audio driver made
the snd_usb_queue_pending_output_urbs() function to be called via PCM
ack ops. In the new code path, the function is performed already in
the PCM stream lock. The problem is that, when an XRUN is detected,
the function calls snd_pcm_xrun() to notify, but snd_pcm_xrun() is
supposed to be called only outside the stream lock. As a result, it
leads to a deadlock of PCM stream locking.
For avoiding such a recursive locking, this patch adds an additional
check to the code paths in PCM core that call the ack callback; now it
checks the error code from the callback, and if it's -EPIPE, the XRUN
is handled in the PCM core side gracefully. Along with it, the
USB-audio driver code is changed to follow that, i.e. -EPIPE is
returned instead of the explicit snd_pcm_xrun() call when the function
is performed already in the stream lock.
Fixes: d5f871f89e21 ("ALSA: usb-audio: Improved lowlatency playback support")
Reported-and-tested-by: John Keeping <john@metanate.com>
Link: https://lore.kernel.org/r/20230317195128.3911155-1-john@metanate.com
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Reviewed-by; Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20230320142838.494-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The recent commit f83bb2592482 ("ALSA: hda/conexant: Add quirk for
LENOVO 20149 Notebook model") introduced a quirk for the device with
17aa:3977, but this caused a regression on another model (Lenovo
Ideadpad U31) with the very same PCI SSID. And, through skimming over
the net, it seems that this PCI SSID is used for multiple different
models, so it's no good idea to apply the quirk with the SSID.
Although we may take a different ID check (e.g. the codec SSID instead
of the PCI SSID), unfortunately, the original patch author couldn't
identify the hardware details any longer as the machine was returned,
and we can't develop the further proper fix.
In this patch, instead, we partially revert the change so that the
quirk won't be applied as default for addressing the regression.
Meanwhile, the quirk function itself is kept, and it's now made to be
applicable via the explicit model=lenovo-20149 option.
Fixes: f83bb2592482 ("ALSA: hda/conexant: Add quirk for LENOVO 20149 Notebook model")
Reported-by: Jetro Jormalainen <jje-lxkl@jetro.fi>
Link: https://lore.kernel.org/r/20230308215009.4d3e58a6@mopti
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230320140954.31154-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
If there is no driver match function, the driver core assumes that each
candidate pair (driver, device) matches, see driver_match_device()
Drop the bus's match function that always returned 1 and so
implements the same behaviour as when there is no match function.
Signed-off-by: Lizhe <sensor1010@163.com>
Link: https://lore.kernel.org/r/20230319044733.327091-1-sensor1010@163.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
clang with W=1 reports
sound/drivers/portman2x4.c:185:18: error: unused function
'portman_read_command' [-Werror,-Wunused-function]
static inline u8 portman_read_command(struct portman *pm)
^
sound/drivers/portman2x4.c:195:18: error: unused function
'portman_read_data' [-Werror,-Wunused-function]
static inline u8 portman_read_data(struct portman *pm)
^
These static functions are not used, so remove them.
Signed-off-by: Tom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20230318135229.1685266-1-trix@redhat.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
clang with W=1 reports
sound/pci/ymfpci/ymfpci_main.c:34:18: error:
unused function 'snd_ymfpci_readb' [-Werror,-Wunused-function]
static inline u8 snd_ymfpci_readb(struct snd_ymfpci *chip, u32 offset)
^
This static function is not used, so remove it.
Signed-off-by: Tom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20230318132708.1684504-1-trix@redhat.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Add the audio quirk for some of Clevo's latest RPL laptops:
- NP50RNJS (ALC256)
- NP70SNE (ALC256)
- PD50SNE (ALC1220)
- PE60RNE (ALC1220)
Co-authored-by: Jeremy Soller <jeremy@system76.com>
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230317141825.11807-1-tcrawford@system76.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
tuning_ctl_set() might have buffer overrun at (X) if it didn't break
from loop by matching (A).
static int tuning_ctl_set(...)
{
for (i = 0; i < TUNING_CTLS_COUNT; i++)
(A) if (nid == ca0132_tuning_ctls[i].nid)
break;
snd_hda_power_up(...);
(X) dspio_set_param(..., ca0132_tuning_ctls[i].mid, ...);
snd_hda_power_down(...); ^
return 1;
}
We will get below error by cppcheck
sound/pci/hda/patch_ca0132.c:4229:2: note: After for loop, i has value 12
for (i = 0; i < TUNING_CTLS_COUNT; i++)
^
sound/pci/hda/patch_ca0132.c:4234:43: note: Array index out of bounds
dspio_set_param(codec, ca0132_tuning_ctls[i].mid, 0x20,
^
This patch cares non match case.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87sfe9eap7.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
control_message() might be called with pao = NULL.
Here indicates control_message() as sample.
(B) static void control_message(struct hpi_adapter_obj *pao, ...)
{ ^^^
struct hpi_hw_obj *phw = pao->priv;
... ^^^
}
(A) void _HPI_6205(struct hpi_adapter_obj *pao, ...)
{ ^^^
...
case HPI_OBJ_CONTROL:
(B) control_message(pao, phm, phr);
break; ^^^
...
}
void HPI_6205(...)
{
...
(A) _HPI_6205(NULL, phm, phr);
... ^^^^
}
Therefore, We will get too many warning via cppcheck, like below
sound/pci/asihpi/hpi6205.c:238:27: warning: Possible null pointer dereference: pao [nullPointer]
struct hpi_hw_obj *phw = pao->priv;
^
sound/pci/asihpi/hpi6205.c:433:13: note: Calling function '_HPI_6205', 1st argument 'NULL' value is 0
_HPI_6205(NULL, phm, phr);
^
sound/pci/asihpi/hpi6205.c:401:20: note: Calling function 'control_message', 1st argument 'pao' value is 0
control_message(pao, phm, phr);
^
Set phr->error like many functions doing, and don't call _HPI_6205()
with NULL.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87ttypeaqz.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Wireless USB host controller support has been removed
from Linux Kernel more than 3 years ago in commit
caa6772db4c1 ("Staging: remove wusbcore and UWB from the
kernel tree."), and the associated code in the
snd-usb-audio driver became unused and untested.
If in the future somebody will return WUSB/UWB support
back to the kernel, the snd-usb-audio driver will reject
Wireless USB audio devices at probe stage, and this patch
should be reverted.
Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com>
Link: https://lore.kernel.org/r/20230312222857.296623-1-ruslan.bilovol@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v6.3
More fixes that came in since -rc1, a lot from Intel - looks like
they've been busy test. Everything is driver specific.
|
|
Currently only one stream is supported. This isn't usally a problem
until you have a multi codec audio card. Because the audio card will run
startup and shutdown on both capture and playback streams. So if your
hdmi-codec only support either playback or capture. Then ALSA can't open
for playback and capture.
This patch will ignore if startup and shutdown are called with a non
supported stream. Thus, allowing an audio card like this:
+-+
cpu1 <--@-| |-> codec1 (HDMI-CODEC)
| |<- codec2 (NOT HDMI-CODEC)
+-+
Signed-off-by: Emil Svendsen <emas@bang-olufsen.dk>
Link: https://lore.kernel.org/r/20230309065432.4150700-2-emas@bang-olufsen.dk
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The following traceback is reported if mutex debugging is enabled.
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: CPU: 0 PID: 17 at kernel/locking/mutex.c:950 __mutex_lock_common+0x31c/0x11d4
Modules linked in:
CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 5.10.172-lockdep-21846-g849884cfca5a #1 fd2de466502012eb58bc8beb467f07d0b925611f
Hardware name: MediaTek kakadu rev0/rev1 board (DT)
Workqueue: events da7219_aad_jack_det_work
pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)
pc : __mutex_lock_common+0x31c/0x11d4
lr : __mutex_lock_common+0x31c/0x11d4
sp : ffffff80c0317ae0
x29: ffffff80c0317b50 x28: ffffff80c0317b20
x27: 0000000000000000 x26: 0000000000000000
x25: 0000000000000000 x24: 0000000100000000
x23: ffffffd0121d296c x22: dfffffd000000000
x21: 0000000000000000 x20: 0000000000000000
x19: ffffff80c73d7190 x18: 1ffffff018050f52
x17: 0000000000000000 x16: 0000000000000000
x15: 0000000000000000 x14: 0000000000000000
x13: 0000000000000001 x12: 0000000000000001
x11: 0000000000000000 x10: 0000000000000000
x9 : 83f0d991da544b00 x8 : 83f0d991da544b00
x7 : 0000000000000000 x6 : 0000000000000001
x5 : ffffff80c03176a0 x4 : 0000000000000000
x3 : ffffffd01067fd78 x2 : 0000000100000000
x1 : ffffff80c030ba80 x0 : 0000000000000028
Call trace:
__mutex_lock_common+0x31c/0x11d4
mutex_lock_nested+0x98/0xac
da7219_aad_jack_det_work+0x54/0xf0
process_one_work+0x6cc/0x19dc
worker_thread+0x458/0xddc
kthread+0x2fc/0x370
ret_from_fork+0x10/0x30
irq event stamp: 579
hardirqs last enabled at (579): [<ffffffd012442b30>] exit_to_kernel_mode+0x108/0x138
hardirqs last disabled at (577): [<ffffffd010001144>] __do_softirq+0x53c/0x125c
softirqs last enabled at (578): [<ffffffd01009995c>] __irq_exit_rcu+0x264/0x4f4
softirqs last disabled at (573): [<ffffffd01009995c>] __irq_exit_rcu+0x264/0x4f4
---[ end trace 26da674636181c40 ]---
Initialize the mutex to fix the problem.
Cc: David Rau <David.Rau.opensource@dm.renesas.com>
Fixes: 7fde88eda855 ("ASoC: da7219: Improve the IRQ process to increase the stability")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Link: https://lore.kernel.org/r/20230307155111.1985522-1-linux@roeck-us.net
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
CONTROLLER_IN_GPU() is clearly intended to match only Intel devices, but
previously it checked only the PCI Device ID, not the Vendor ID, so it
could match devices from other vendors that happened to use the same Device
ID.
Update CONTROLLER_IN_GPU() so it matches only Intel devices.
Fixes: 535115b5ff51 ("ALSA: hda - Abort the probe without i915 binding for HSW/B")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/r/20230307214054.886721-1-helgaas@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Samsung Galaxy Book2 Pro (13" 2022 NP930XED-KA1DE) with codec SSID
144d:c868 requires the same workaround for enabling the speaker amp
like other Samsung models with ALC298 code.
Signed-off-by: Hamidreza H. Fard <nitocris@posteo.net>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230307163741.3878-1-nitocris@posteo.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
There is a HP platform needs ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED quirk to
make mic-mute/audio-mute/speaker working.
Signed-off-by: Jeremy Szu <jeremy.szu@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230307135317.37621-1-jeremy.szu@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Use SOF as default audio driver.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Gongjun Song <gongjun.song@intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230306074101.3906707-1-yung-chuan.liao@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
We have recently noticed that the ops_free callback was missed for the device
descriptions on Intel platforms.
|
|
Recent firmware changes modified the curve duration from 32 to 64 bits,
which breaks volume ramps. A simple solution would be to change the
definition, but unfortunately the ASoC topology framework only supports
up to 32 bit tokens.
This patch suggests breaking the 64 bit value in low and high parts, with
only the low-part extracted from topology and high-part only zeroes. Since
the curve duration is represented in hundred of nanoseconds, we can still
represent a 400s ramp, which is just fine. The defacto ABI change has no
effect on existing users since the IPC4 firmware has not been released just
yet.
Link: https://github.com/thesofproject/linux/issues/4026
Signed-off-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20230307110656.1816-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
When an IPC error happens while setting-up a widget during the FE
hw_params phase, the existing logic will unwind all previous
configurations but will overwrite the return status. The ALSA/ASoC
logic will then proceed with the prepare and trigger phases, even
though the firmware resources are not available.
Fix by returning the initial error code and ignoring the code returned
in the UNPREPARE phase.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Chao Song <chao.song@linux.intel.com>
Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20230307114659.4614-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This reverts commit a09d82ce0a867 ("ASoC: SOF: Intel: hda-ctrl: remove
useless sleep")
It was a mistake to remove those delays, in light of comments in the
HDaudio spec captured in snd_hdac_bus_reset_link() that the codec
needs time for its initialization and PLL lock.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20230307095412.3416-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add delay between set and wait command according to hardware programming
sequence. Also add debug log to detect error.
Signed-off-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20230307095453.3719-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Dmic dai index was set incorrectly to bits 5-7, when it is actually using
just the lowest 3. Fix the macro for setting the bits.
Fixes: aa84ffb72158 ("ASoC: SOF: ipc4-topology: Add support for SSP/DMIC DAI's")
Signed-off-by: Jaska Uimonen <jaska.uimonen@linux.intel.com>
Reviewed-by: Adrian Bonislawski <adrian.bonislawski@intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20230307110730.1995-1-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
