IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Adds the required quirk to enable the Cirrus amp and correct pins
on the ASUS ROG G614J series which uses an SPI connected Cirrus amp.
While this works if the related _DSD properties are made available, these
aren't included in the ACPI of these laptops (yet).
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20230704044619.19343-5-luke@ljones.dev
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Adds the required quirk to enable the Cirrus amp and correct pins
on the ASUS ROG GA402X series which uses an I2C connected Cirrus amp.
While this works if the related _DSD properties are made available, these
aren't included in the ACPI of these laptops (yet).
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20230704044619.19343-3-luke@ljones.dev
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Adds the required quirk to enable the Cirrus amp and correct pins
on the ASUS ROG GV601V series which uses an I2C connected Cirrus amp.
While this works if the related _DSD properties are made available, these
aren't included in the ACPI of these laptops (yet).
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20230704044619.19343-2-luke@ljones.dev
Signed-off-by: Takashi Iwai <tiwai@suse.de>
These models use NSIWAY amplifiers for internal speaker, but cannot put
sound outside from these amplifiers. So eapd verbs are needed to initialize
the amplifiers. They can be added during boot to get working sound out
of internal speaker.
Signed-off-by: dengxiang <dengxiang@nfschina.com>
Link: https://lore.kernel.org/r/20230703021751.2945750-1-dengxiang@nfschina.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This applies a SND_PCI_QUIRK(...) to the Clevo NPx0SNx barebones fixing the
microphone not being detected on the headset combo port.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230628155434.584159-1-wse@tuxedocomputers.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A fairly quiet release from a core and framework point of view, but a
very big one from the point of view of new drivers:
- More refectoring from Morimoto-san, this time mainly around DAI
links and how we control the ordering of trigger() callbacks.
- Convert a lot of drivers to use maple tree based caches.
- Lots of work on the x86 driver stack.
- Compressed audio support for Qualcomm.
- Support for AMD SoundWire, Analog Devices SSM3515, Google Chameleon,
Ingenic X1000, Intel systems with various CODECs, Longsoon platforms,
Maxim MAX98388, Mediatek MT8188, Nuvoton NAU8825C, NXP platforms with
NAU8822, Qualcomm WSA884x, StarFive JH7110, Texas Instruments TAS2781.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmSZjIQACgkQJNaLcl1U
h9Dm0wf/X1q4n6KSXLvSyoSUxS/RWzWgyDDX7a4iLcFiov3ehHpVwzhwI/+1xSzs
SGhg6q2rud05SejFBh+2L7HMZfdXWSfW9ukaGz3UsCdqw3/7zAUFgY1RGtjZO4lA
eH50vEME9RbkIDgyxzYe9eViaKGh2fNxIbQ2d9hx6+nIVNfuuSikvGz4K/9PD0DN
2tBgzuIWwrPIbvMV2zHDCycmVG0lqScMWjIrdpDFxa63aPTr920YqYWSoQfOUR1s
j9zlZWnclTjrqRl1GZHxnM8N70vmutZWXAB1WFjal6mmMd6lUG71CyYHvA5h5D0V
ygNpn9B5REYlHBVzI43uT3nog+iS4Q==
=dbjW
-----END PGP SIGNATURE-----
Merge tag 'asoc-v6.5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v6.5
A fairly quiet release from a core and framework point of view, but a
very big one from the point of view of new drivers:
- More refectoring from Morimoto-san, this time mainly around DAI
links and how we control the ordering of trigger() callbacks.
- Convert a lot of drivers to use maple tree based caches.
- Lots of work on the x86 driver stack.
- Compressed audio support for Qualcomm.
- Support for AMD SoundWire, Analog Devices SSM3515, Google Chameleon,
Ingenic X1000, Intel systems with various CODECs, Longsoon platforms,
Maxim MAX98388, Mediatek MT8188, Nuvoton NAU8825C, NXP platforms with
NAU8822, Qualcomm WSA884x, StarFive JH7110, Texas Instruments TAS2781.
On HP EliteBook 835/845/845W G10, the audio LEDs can be enabled by
ALC285_FIXUP_HP_MUTE_LED. So use it accordingly.
Signed-off-by: Andy Chi <andy.chi@canonical.com>
Cc: <stable@vger.kernel.org>
Fixes: 3e10f6ca76 ("ALSA: hda/realtek: Add quirk for HP EliteBook G10 laptops")
Link: https://lore.kernel.org/r/20230626130301.301712-1-andy.chi@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Adds the required quirk to enable the Cirrus amp and correct pins
on the ASUS ROG GV601V series.
While this works if the related _DSD properties are made available, these
aren't included in the ACPI of these laptops (yet).
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20230621085715.5382-1-luke@ljones.dev
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Adds the required quirk to enable the Cirrus amp and correct pins
on the ASUS ROG G634Z series.
While this works if the related _DSD properties are made available, these
aren't included in the ACPI of these laptops (yet).
Signed-off-by: Luke D. Jones <luke@ljones.dev>
Link: https://lore.kernel.org/r/20230619060320.1336455-1-luke@ljones.dev
Signed-off-by: Takashi Iwai <tiwai@suse.de>
smatch error:
sound/pci/ac97/ac97_codec.c:2354 snd_ac97_mixer() error:
we previously assumed 'rac97' could be null (see line 2072)
remove redundant assignment, return error if rac97 is NULL.
Fixes: da3cec35dd ("ALSA: Kill snd_assert() in sound/pci/*")
Signed-off-by: Su Hui <suhui@nfschina.com>
Link: https://lore.kernel.org/r/20230615021732.1972194-1-suhui@nfschina.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The file is called spdif-in, but we abused it to show only sample rates
from various sources. Rectify it as far as possible (the FPGA doesn't
give us a lot of information).
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-10-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is only a very partial fix - the frequency-dependent envelope & LFO
register values aren't adjusted.
But I'm not sure they were even correct at 48 kHz to start with, as most
of them are precalculated by common code which assumes an EMU8K-specific
44.1 kHz word clock, and it seems somewhat unlikely that the hardware's
register interpretation was adjusted to compensate for the different
word clock.
In any case I'm not going to spend time on fixing that, as this code is
unlikely to be actually used by anyone today.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-6-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Now that we know the actual word clock, we can:
- Put the resulting rate into the hardware info
- At 44.1 kHz word clock shift the rate for the pitch calculations,
which presume a 48 kHz word clock
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The value isn't used yet; the subsequent commits will do that.
This ignores the existence of rates above 48 kHz, which is fine, as the
hardware will just switch to the fallback clock source when fed with a
rate which is incompatible with the base clock multiplier, which
currently is always x1.
The sample rate display in /proc spdif-in is adjusted to reflect our
understanding of the input rates.
This is tested only with an 0404b card without sync card, so there is a
lot of room for improvement.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The actually available clock sources depend on the available audio input
ports and dedicated clock input ports.
This includes refactoring the code to be data-driven to remain
manageable.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
So far, we set the fallback as a side effect of setting the source. But
the fallback makes no sense at all when an internal clock is selected.
Defaulting to 48k for S/PDIF & ADAT makes sense, but as that is the
global default and we're not changing it automatically any more, it's
just fine to leave it entirely to the explicit setting.
This changes the name of the pre-existing control to something more
appropriate (regardless of the split), so users will need to adjust
their mixer settings.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230612191325.1315854-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On loongson controller, the value of WALLCLK register
is always 0, which is meaningless, so we return directly.
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Signed-off-by: Yingkun Meng <mengyingkun@loongson.cn>
Acked-by: Huacai Chen <chenhuacai@loongson.cn>
Link: https://lore.kernel.org/r/185df71ef413ab190460eb377703214ee7288aeb.1686128807.git.siyanteng@loongson.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On loongson controller, after calling snd_hdac_stream_updateb()
to enable DMA engine, the SDnCTL.STRM will become to zero. We
need to access SDnCTL in dword to keep SDnCTL.STRM is not changed.
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Signed-off-by: Yingkun Meng <mengyingkun@loongson.cn>
Acked-by: Huacai Chen <chenhuacai@loongson.cn>
Link: https://lore.kernel.org/r/27aeddf5ebbe7c69631cec0e489c1b264be94990.1686128807.git.siyanteng@loongson.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On loongson controller, RIRBSTS.RINTFL cannot be cleared,
azx_interrupt() is called all the time. We disable RIRB
interrupt, and use polling mode by default.
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Signed-off-by: Yingkun Meng <mengyingkun@loongson.cn>
Acked-by: Huacai Chen <chenhuacai@loongson.cn>
Link: https://lore.kernel.org/r/d309a75424d438b958d90d797b4f1ba45468e090.1686128807.git.siyanteng@loongson.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In the commit 7bb6234095 ("ALSA: hda/realtek: fix speaker, mute/micmute
LEDs not work on a HP platform"), speakers and LEDs are fixed but only 2
CS35L41 amplifiers on SPI bus connected to Realtek codec are enabled. Need
the ALC245_FIXUP_CS35L41_SPI_4_HP_GPIO_LED to get all amplifiers working.
Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Fixes: 7bb6234095 ("ALSA: hda/realtek: fix speaker, mute/micmute LEDs not work on a HP platform")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230606145747.135966-1-chris.chiu@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Ensure Firmware Load control and Firmware Type control
returns 1 when the value changes.
Remove fw_mutex from firmware load control put, since it is
unnecessary, and prevents any possibility of mutex inversion.
Signed-off-by: Stefan Binding <sbinding@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230606103436.455348-2-sbinding@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
HD-audio core code replaces the kctl->id.index of SPDIF-related
controls after assigning via snd_ctl_add(). This doesn't work any
longer with the new Xarray lookup change. The change of the kctl->id
content has to be done via snd_ctl_rename_id() helper, instead.
Fixes: c27e1efb61 ("ALSA: control: Use xarray for faster lookups")
Cc: <stable@vger.kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230606093855.14685-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
cmipci driver replaces the kctl->id.device after assigning the kctl
via snd_ctl_add(). This doesn't work any longer with the new Xarray
lookup change. It has to be set before snd_ctl_add() call instead.
Fixes: c27e1efb61 ("ALSA: control: Use xarray for faster lookups")
Cc: <stable@vger.kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230606093855.14685-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ymfpci driver replaces the kctl->id.device after assigning the kctl
via snd_ctl_add(). This doesn't work any longer with the new Xarray
lookup change. It has to be set before snd_ctl_add() call instead.
Fixes: c27e1efb61 ("ALSA: control: Use xarray for faster lookups")
Cc: <stable@vger.kernel.org>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230606093855.14685-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The new xarray lookup code requires to know complete kcontrol->id before
snd_ctl_add() call. Reorder the code to make the initialization properly.
Cc: stable@kernel.org # v5.19+
Reported-by: Martin Zidek <zidek@master.cz>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230606073122.597491-1-perex@perex.cz
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Headset microphone on this platform does not work without
ALC897_FIXUP_HEADSET_MIC_PIN fixup.
Signed-off-by: RenHai <kean0048@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230602003604.975892-1-kean0048@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
- Include the FX bus map, without which the already present send routing
info would require looking up the documentation.
- Include the physical I/O channels as known to the driver
- Make the multi-channel capture map actually name the mapped input
channels rather than "FXBUS" (Audigy) or even "???" (SbLive)
- The latter two are omitted for E-MU cards, as their physical I/O is
routed through the FPGA
- While at it, make the "Card" field somewhat more useful
This includes de-duplicating the label tables between emuproc and emufx,
updating/improving the FX bus label table, and making the SB Live! 5.1
multi-track capture channel mapping hack data-driven.
Tested-by: Jonathan Dowland <jon@dow.land>
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230526101659.437969-7-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Include the routing information, which can be actually read back.
Somewhat as a drive-by, make the register dump format less obscure - the
previous one made no sense at all.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230526101659.437969-6-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It seems to make little sense to include the FX send routing, but not
the amounts.
This also simplifies the code somewhat, and lines up the output.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230526101659.437969-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The limits were appropriate only for the 2nd set.
FWIW, the channel count 4 for the 2nd set is suspicious as well - at
least P17V_PLAYBACK_FIFO_PTR actually has 8 channels, and comments on
HCFG2 hint at that as well. But all bitmasks are documented only for 4
channels. Anyway, rectifying that is out of scope for this patch.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230526101659.437969-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The 2nd register set belongs to the P16V chip (or embedded P17V module),
so there is nothing to show when no such part is present. Gen2 E-MU
cards have a P17V, but it's entirely unused, so we hide it there as
well.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230526101659.437969-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
After commit b8a1a4cd5a ("i2c: Provide a temporary .probe_new()
call-back type"), all drivers being converted to .probe_new() and then
03c835f498 ("i2c: Switch .probe() to not take an id parameter") convert
back to (the new) .probe() to be able to eventually drop .probe_new() from
struct i2c_driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://lore.kernel.org/r/20230525203640.677826-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Merge series from Cristian Ciocaltea <cristian.ciocaltea@collabora.com>:
This patch series handles a few issues related to the ES8316 audio
codec, discovered while doing some testing on the Rock 5B board.
Lenovo M70/M90 Gen4 are equipped with ALC897, and they need
ALC897_FIXUP_HEADSET_MIC_PIN quirk to make its headset mic work.
The previous quirk for M70/M90 is for Gen3.
Signed-off-by: Bin Li <bin.li@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230524113755.1346928-1-bin.li@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On SB cards the number of captured channels is derived from the voice
mask mixer control. But for E-MU cards this wasn't actually "wired up",
so changing the mask would simply mess up the recording.
We could fix that, but the channel routing through the FPGA makes the
masking redundant. So instead we hide the control, and let the user
specify the PCM channel count the traditional way.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230523200709.236059-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The hardware can deal with primes up to 7 and power-of-two multiples
thereof; the limitation is reflected by the possible buffer sizes.
Note that setting the voice mask will not allow more than 16 channels
even on Sound Blaster Audigy anymore, as 32 seems a bit excessive (the
code overall appears to think so, just not in this case).
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230523200709.236059-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We need to specify that the hardware supports non-standard rates, as
otherwise the sound core creates a constraint which limits the rate to
the specified standard rates. That also made the rate constraint we were
already adding meaningless.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230523200709.236059-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The buffer size register sets the size of the whole buffer, not just one
period. We actually handled it like that, except that the constraint was
set on the wrong parameter. The period size is implicitly constrained by
the buffer size and the fixed period count of 2.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230523200709.236059-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We use independent voices for the channels, so we need to make an effort
to ensure that they are actually in sync.
The hardware doesn't provide atomicity, so we may need to retry a few
times, due to NMIs, PCI contention, and the wrong phase of the moon.
Solution inspired by kX-project.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230523200709.236023-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For unclear reasons, the extra voice was set up with half the buffer
size instead of the period size. Commit 27ae958cf6 ("emu10k1 driver -
add multichannel device hw:x,3 [2-8/8]") mentions half-loop interrupts,
so maybe this was an artifact of an earlier iteration of the patch.
While at it, also fix periods_min of the regular playback - one period
makes just no sense.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230523200709.236023-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Do not include pm_runtime.h header in files where APIs exported by
pm_runtime.h are not used.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com> # for omap-mcbsp-st.c
Link: https://lore.kernel.org/r/20230517094903.2895238-2-claudiu.beznea@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
... instead of passing in a high-level mixer struct. Let the
higher-level functions handle the differences between the voice types.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230523104612.198884-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This adds snd_emu10k1_pcm_init_{voices,extra_voice}() and
snd_emu10k1_playback_{un,}mute_voices() to slightly abstract by voice
function and potential stereo property.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230523104612.198884-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
Co-developed-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Acked-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230522105049.1467313-33-schnelle@linux.ibm.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
One-element arrays are deprecated, and we are replacing them with flexible
array members instead. However, in this case it seems those one-element
arrays have never actually been used as fake flexible arrays.
See this code that dates from Linux-2.6.12-rc2 initial git repository build
(commit 1da177e4c3 ("Linux-2.6.12-rc2")):
sound/pci/mixart/mixart_core.h:
215 struct mixart_stream_state_req
216 {
217 u32 delayed;
218 u64 scheduler;
219 u32 reserved4np[3];
220 u32 stream_count; /* set to 1 for instance */
221 struct mixart_flow_info stream_info; /* could be an array[stream_count] */
222 } __attribute__((packed));
sound/pci/mixart/mixart.c:
388
389 memset(&stream_state_req, 0, sizeof(stream_state_req));
390 stream_state_req.stream_count = 1;
391 stream_state_req.stream_info.stream_desc.uid_pipe = stream->pipe->group_uid;
392 stream_state_req.stream_info.stream_desc.stream_idx = stream->substream->number;
393
So, taking the code above as example, replace multiple one-element
arrays with simple object declarations, and refactor the rest of the
code, accordingly.
This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
routines on memcpy() and help us make progress towards globally
enabling -fstrict-flex-arrays=3 [1].
This results in no differences in binary output.
Link: https://github.com/KSPP/linux/issues/79
Link: https://github.com/KSPP/linux/issues/296
Link: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602902.html [1]
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/ZGfiFjcL8+r3mayq@work
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Instead of separate voices, we now allocate non-interleaved channels,
which may in turn contain two interleaved voices each. The higher-level
code keeps only one pointer per channel. The channels are not allocated
in one block any more, as there is no reason to do that. As a
consequence of that, and because it is cleaner regardless, we now let
the allocator store these pointers at a specified location, rather than
returning only the first one and having the calling code deduce the
remaining ones.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518140947.3725394-8-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The voice allocator clearly knows about the field (it resets it), so
it's more consistent (and leads to less duplicated code) to have the
constructor take it as a parameter.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518140947.3725394-7-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This allows us to drop the code that tries to preserve already allocated
voices upon repeated hw_param callback invocations. Getting it right for
multi-channel voices would otherwise get a bit hairy.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518140947.3725394-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Eliminate the MIDI type, as there is no such thing - the MPU401 port
doesn't have anything to do with voices.
For clarity, differentiate between regular and extra voices.
Don't atomize the enum into bits in the table display.
Simplify/optimize the storage.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518140947.3725394-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The subsequent allocation may still fail after freeing some voices, so
we shouldn't leave them in their programmed state.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518140947.3725394-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
On Audigy, the send amounts are merely targets, presumably to avoid
sound distortion due to sudden changes, which the EMU8K docu explicitly
warns about.
However, that "soft-start" would prevent bit-for-bit reproduction, so
we now force the current send amounts to their final values at PCM
playback init.
One might want to do that for the MIDI synthesizer as well, though it
seems mostly pointless due to the attack phase each note has anyway.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518140339.3722279-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
CPF_CURRENTPITCH starts swerving towards PTRX_PITCHTARGET as soon as
that is set. In practice this means that CPF_FRACADDRESS may acquire a
non-zero value before we manage to force CPF_CURRENTPITCH to the final
value, which would prevent bit-for-bit reproduction.
To avoid that this state persists, we now reset CPF_FRACADDRESS when
setting CPF_CURRENTPITCH, and to (mostly) avoid that it progresses too
far in the first place (possibly even reaching CCCA_CURRADDR), we write
PTRX and CPF in one critical section (though NMIs, etc. still make this
unreliable).
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518140339.3722279-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Make terminate_voice() actually do at all what it's supposed to do:
instantly and completely shut down the note.
The bogus behavior was mostly harmless, as usually the voice is freed
right afterwards, which implicitly terminates it anyway.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518140339.3722308-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Compensate for the cache delay, and actually populate the cache.
Without these, the playback would start with garbage (which would be
(mostly?) masqueraded by the attack phase).
Unlike for the PCM voices, this doesn't try to compensate for the
interpolator read-ahead, because it's pointless to be super-exact here.
Note that this code is probably still broken for particularly short
samples, because we ignore the loop-related parts of CCR. But I'm not
going to reverse-engineer that now ...
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518140339.3722308-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
smatch reports
sound/pci/emu10k1/emumixer.c:519:39: warning: symbol
'emu1010_routing_info' was not declared. Should it be static?
sound/pci/emu10k1/emumixer.c:859:36: warning: symbol
'emu1010_pads_info' was not declared. Should it be static?
These variables are only used in their defining file, so it should be static
Signed-off-by: Tom Rix <trix@redhat.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518123826.925752-1-trix@redhat.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
While this nicely denoises the code, the real intent is being able to
write many registers pseudo-atomically, which will come in handy later.
Idea stolen from kX-project.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518093134.3697955-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We'd try to iterate the voices twice without resetting the pointer.
This went unnoticed, because the code isn't actually in use.
Amends commit 27ae958cf6 ("emu10k1 driver - add multichannel device
hw:x,3 [2-8/8]").
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518093047.3697887-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Handle the "timeout" (actually the retry counter) such that it's more
obvious and causes less cost in the normal case.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518093047.3697887-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Remove weird INTE_* clearing code. The bits were a subset of the
actually handled interrupts, which kind of contradicted the stated
purpose. I suppose it would make sense to complete the set and negate
it, but interrupts being enabled out of the blue is neither something
that happens a lot, nor should it result in just one error message, IMO.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518093047.3697887-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
IPR_CHANNELNUMBERMASK cannot be non-zero when IPR_CHANNELLOOP is unset,
so join marking them as handled.
This logically reverts part of commit f453e20d8a0 ("ALSA update
0.9.3a"), which made the inverse change with no explanation.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518093047.3697887-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The period_bytes_min parameter and the buffer_bytes minimum constraint
made no sense at all, as they didn't reflect any hardware limitation.
Instead, apply a frame-based period_size minimum constraint, which is
derived from the cache size (it would be actually possible to go below
that, but it would require special handling, and it would be practically
impossible to keep up with the IRQ rate anyway).
Sync up the constraints of the EFX playback with those of the regular
playback, as there is no reason for them to diverge.
N.b., the maximum buffer size is actually arbitrary - the hardware could
go waay beyond 128 KiB.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230518092224.3696958-9-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Pull the special handling of extra voices out of
snd_emu10k1_pcm_init_voice(), simplify snd_emu10k1_playback_pointer(),
and make the logic overall clearer. Also, add verbose comments.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230517174256.3657060-9-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Rename snd_emu10k1_playback_invalidate_cache() to the more apt
snd_emu10k1_playback_fill_cache(), and factor out
snd_emu10k1_playback_prepare_voices(), which calls the former for all
channels.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230517174256.3657060-8-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Originally, there was a 1:1 relationship between the PCM streams' and
the low-level voices' parameters. The addition of multi-channel playback
partially invalidated that, but didn't introduce proper layering, so
things kept working only by virtue of the multi-channel device never
having two channels (yet). The upcoming addition of 32-bit playback
would complete upending the relationships.
So this patch detaches the low-level parameters from the high-level
ones: we pass pre-calculated bit width and stereo flags to the low-level
manipulation functions instead of calculating them in-place from the
stream parameters.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230517174256.3657060-7-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The cache causes a fixed delay regardless of stream parameters.
Consequently, all that "cache invalidate size" calculation stuff was
garbage (which can be traced right back to Creative's OSS driver).
This also removes the definitions of registers CD1..CDF, because they
are accessed only relative to CD0 anyway.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230517174256.3657060-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Given that the data is going to be ignored anyway, and that the cache
does not influence interrupt timing (which is the purpose of the extra
voices), it's pointless to pre-fill the cache.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230517174256.3657060-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The idea is to make the extra voice lag behind the "real" voices, but
moving the buffer address around doesn't contribute to that, as the CCCA
write below uses the same address. The exact address is unimportant, as
the data is discarded anyway.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230517174256.3657060-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This workaround fails to address the underlying problem, which is
actually wholly self-made. Subsequent patches will fix it.
This reverts commit 56385a12d9.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230517174256.3657060-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Shrink the {in,out}put_source arrays and their data type to what is
actually necessary.
To be still on the safe side, add some static asserts.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536508-11-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Unlike the other models, this is actually a distinct card, rather than
an E-MU 1010 with different "dongles". It is stereo only, and supports
no ADAT (there is no trace of ADAT in the manual, switching the output
mode to ADAT has no effect, and switching the input mode to ADAT just
breaks input (presumably ... my only ADAT source is the card's output)).
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536508-10-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The more card models are handled separately, the more code duplication
this saves.
add_emu1010_source_mixers() is factored out the save duplication in a
later commit.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536508-8-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
... and move it to the mixer init, as it's logically part of it.
As a side effect, this fixes the initial values of the input destination
mixer controls, which would have previously remained at "Silent" despite
different defaults. This didn't really matter, though, as ALSA state
restoration would hide that bug beyond first use.
Note that this completely does away with clearing the output routing
registers, as it was rather pointless - we just programmed the FPGA
(resetting it first if necessary), so everything is zeroed anyway
(that's documented by Xilinx, and as further evidence, some of the loops
terminated too early, and we didn't bother clearing the high channels of
the input routes at all, all with no observed adverse effects).
As a drive-by, this also fixes some capture channel defaults - any
EMU_SRC_*2 isn't a sensible value in 1x clock mode.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536508-7-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Instead of hard-coding the card-specific arrays and their sizes in each
function, use a more data-driven approach.
As a drive-by, also hide the unavailable I2S input destinations on the
1616 cardbus card.
Also as a drive-by, use more assignments at variable declaration for
brevity. This also removes the pointless masking of kctl.private_value.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536508-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Define arrays of strings instead of snd_kcontrol_new.
While at it, move the E-MU source & destination enum defs next to their
hardware defs, which is a lot more logical and will come in handy in a
followup commit. And add some static asserts to verify that the array
sizes match.
This also applies the compactization from the previous commit to the
destination registers.
While reshuffling the arrays anyway, switch the order of the HAMOA_DAC
& HANA_SPDIF output destinations for the 1010 card, so they follow a
more regular pattern. This should have no functional impact.
The code is somewhat de-duplicated by the extraction of add_ctls().
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536508-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Use macros to avoid duplication. Arguably, this is somewhat less
legible, but future additions would grow this part of the file to
completely unmanageable dimensions.
The EMU*_COMMON_TEXTS macros will save duplication in a future commit;
I pulled them ahead to reduce churn.
While rewriting the tables anyway, rearrange them such that each card's
strings and registers are adjacent.
Also, add some static asserts to verify that the array sizes match.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536508-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Many registers are meaningless for stereo slaves and the extra voices.
This patch cleans up these unnecessary register writes.
snd_emu10k1_playback_{trigger,stop}_voice() is not called for stereo
slaves any more.
snd_emu10k1_playback_prepare_voice() is renamed to
snd_emu10k1_playback_unmute_voice(), as this better reflects its
remaining function. It's not called for the extra voices any more.
Accordingly, snd_emu10k1_playback_mute_voice() is factored out from
snd_emu10k1_playback_stop_voice(), and is called selectively as well.
This doesn't add conditionals which would avoid initializing
sub-registers, as that wouldn't pull its weight.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536451-6-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We now enable ints even before triggering, and disable them only after
stopping - otherwise there is a race condition we may plausibly run into
when we pause/resume near the end of the buffer.
Updating the epcm->running flag is moved the same way, as it affects the
*_pointer() functions, which are called by the interrupt handler.
Also, factor these out to own functions, for clarity.
For multi-channel, the extra voice is now triggered after all regular
voices - we wouldn't want to receive an int before all channels have
passed the period boundary.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536451-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We initialize them at card init and don't touch them later, so there is
no need to reset them again at voice start.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536451-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
We (rightfully) don't enable the envelope engine for PCM voices, so any
related setup is entirely pointless - the EMU8K documentation makes that
very clear, and the fact that the various open drivers all use different
values to no observable detriment pretty much confirms it.
The remaining initializations are regrouped for clarity.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536451-3-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The mixer structures were filled in two places: on driver init, and when
the devices are opened. The latter made the former pointless, so we
remove the former. This implies that mixer dumps may now return all
zeroes, which is OK, as restoring them is meaningless as well.
Things were even weirder for the (generally unused) secondary sends:
Some of the initialization loops were forgotten when support for Audigy
was added, thus creating the technically illegal state of multiple sends
being routed to the same FX accumulator (though it apparently doesn't
matter when the amount is zero).
The global multi-channel init used some rather bizarre values for the
secondary sends, and the init on open actually forgot to re-initialize
them. We now use a not really more useful, but simpler formula.
The direct register init was also bogus. This doesn't really matter, as
the value is overwritten when a voice comes into use, but still.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230516093612.3536451-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
These IDs are for AD102, AD103, AD104, AD106, and AD107 gpus with
audio functions that are largely similar to the existing ones.
Tested audio using gnome-settings, over HDMI, DP-SST and DP-MST
connections on AD106 gpu.
Signed-off-by: Nikhil Mahale <nmahale@nvidia.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230517090736.15088-1-nmahale@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_cs46xx_download_image() was originally called from dsp_spos.c, but
is now local to cs46xx_lib.c. Mark it as 'static' to avoid a warning
about it lacking a declaration, and '__maybe_unused' to avoid a warning
about it being unused when CONFIG_SND_CS46XX_NEW_DSP is disabled:
sound/pci/cs46xx/cs46xx_lib.c:534:5: error: no previous prototype for 'snd_cs46xx_download_image'
Fixes: 89f157d9e6 ("[ALSA] cs46xx - Fix PM resume")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20230516195046.550584-1-arnd@kernel.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
get_line_out_pfx() may trigger an Oops by overflowing the static array
with more than 8 channels. This was reported for MacBookPro 12,1 with
Cirrus codec.
As a workaround, extend for the 9.1 channels and also fix the
potential Oops by unifying the code paths accessing the same array
with the proper size check.
Reported-by: Olliver Schinagl <oliver@schinagl.nl>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/64d95eb0-dbdb-cff8-a8b1-988dc22b24cd@schinagl.nl
Link: https://lore.kernel.org/r/20230516184412.24078-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The voice volume is a raw fractional multiplier that can't actually
represent 1.0. To still enable real pass-through, we now set the volume
to 0.5 (which results in no loss of precision, as the FX bus provides
fractional values) and scale up the samples in DSP code.
To maintain backwards compatibility with existing configuration files,
we rescale the values in the mixer controls. The range is extended
upwards from 0xffff to 0x1fffd, which actually introduces the
possibility of specifying an amplification.
There is still a minor incompatibility with user space, namely if
someone loaded custom DSP code. They'll just get half the volume, so
this doesn't seem like a big deal.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230514170323.3408834-8-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fractional multiplication with the maximal value 2^31-1 causes some tiny
distortion. Instead, we want to multiply with the full 2^31. The catch
is of course that this cannot be represented in the DSP's signed 32 bit
registers.
One way to deal with this is to encode 1.0 as a negative number and
special-case it. As a matter of fact, the SbLive! code path already
contained such code, though the controls never actually exercised it.
A more efficient approach is to use negative values, which actually
extend to -2^31. Accordingly, for all the volume adjustments we now use
the MAC1 instruction which negates the X operand.
The range of the controls in highres mode is extended downwards, so -1
is the new zero/mute. At maximal excursion, real zero is not mute any
more, but I don't think anyone will notice this behavior change. ;-)
That also required making the min/max/values in the control structs
signed. This technically changes the user space interface, but it seems
implausible that someone would notice - the numbers were actually
treated as if they were signed anyway (and in the actual mixer iface
they _are_). And without this change, the min value didn't even make
sense in the first place (and no-one noticed, because it was always 0).
Tested-by: Jonathan Dowland <jon@dow.land>
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230514170323.3408834-7-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The microphone capture device is a feature of the AC97 codec, so its
availability should be coupled to the presence of that codec.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230514170323.3408834-6-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The E-MU cards don't try very hard to be Sound Blasters. All sound I/O
goes through the Hana FPGA, thus making the regular extin/out controls
useless. Still showing them just serves to clutter up the interface and
confuse the user.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230514170323.3408834-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
User space could pass arbitrary ranges, which were uncritically
accepted. This could lead to table lookups out of range.
I don't think that this is a security issue, as it only allowed someone
with CAP_SYS_ADMIN to crash the kernel, but still.
Setting an invalid translation mode will also be rejected now. That did
no harm, but it's still better to detect errors.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230514170323.3408834-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
- Pull ahead all fixed allocations, so we don't rely on the semi-
dynamic ones not crossing the arbitrarily determined limit
- Use an enum for the fixed allocations
- Stop arbitrarily wasting registers on unexplained "reservations"
- Don't reserve two regs for the master volume control - it's mono
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230514170323.3408834-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Rather than applying masks to the provided values, make assertions
about them being valid - otherwise we'd just try to paper over bugs.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230514170323.3408798-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
There's yet another laptop that needs the fixup to enable mute and
micmute LEDs. So do it accordingly.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230512083417.157127-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The Pavilion 15 line has B&O top speakers similar to the x360 and
applying the same profile produces good sound. Without this, the
sound would be tinny and underpowered without either applying
model=alc295-hp-x360 or booting another OS first.
Signed-off-by: Ryan Underwood <nemesis@icequake.net>
Fixes: 563785edfc ("ALSA: hda/realtek - Add quirk entry for HP Pavilion 15")
Link: https://lore.kernel.org/r/ZF0mpcMz3ezP9KQw@icequake.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Instead of using lots of instructions to mix wet and dry signals,
simply skip over the whole code block if tone control is disabled.
This also allows us doing away with the "shadow" playback channels.
Tested-by: Jonathan Dowland <jon@dow.land>
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230510173917.3073107-7-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Evidently, the channel delay bug exists in all E-MU cards; it's in the
Hana FPGA program, and was never fixed.
Note that the implementation is somewhat lazy - to localize the code
paths, we actually waste a GPR and a DSP instruction by keeping two
delay registers for the same physical source.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230510173917.3073107-6-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Instead of spending lots of instructions on masking and transplanting
the sign bit, sidestep the issue by replacing the last bit shift with
a wrapping addition to self.
Solution stolen from kX-project, after I pondered other ideas first.
Also, the function really doesn't need to return a constant int value.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230510173917.3073107-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Presumably, JDC added the seemingly superfluous indirection over the
temporary register because without it he'd get only zero readings.
However, switching the X and Y operands (or using EMU32 as the A
operand in the temporary load) works just fine. Presumably a DSP bug?
The original code was also actually buggy, though: both channels used
the left volume control.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230510173917.3073107-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It controls the whole surround set, so stereo can't work. As a
consequence, only the left channel was paid attention to.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230510173917.3073107-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
These models use 2 CS35L41 amplifiers using SPI for down-facing
speakers.
alc285_fixup_speaker2_to_dac1 is needed to fix volume control of the
down-facing speakers.
Pin configs are needed to enable headset mic detection.
Note that these models lack the ACPI _DSD properties needed to
initialize the amplifiers. They can be added during boot to get working
sound out of the speakers:
https://gist.github.com/lamperez/862763881c0e1c812392b5574727f6ff
Signed-off-by: Alexandru Sorodoc <ealex95@gmail.com>
Link: https://lore.kernel.org/r/20230511161510.315170-1-ealex95@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add support for HP EliteBook 835/845/845W/865 G10 laptops
with CS35L41 amplifiers on I2C/SPI bus connected to Realtek codec.
Signed-off-by: Vitaly Rodionov <vitalyr@opensource.cirrus.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230510142227.32945-1-vitalyr@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
- Fix mixer source port names. These will require some users to
re-adjust their mixer settings, which seems acceptable:
- The S/PDIF port is on the main 1010 card, not the 0202 daughter card
- The 1616m CardBus card has all inputs on the dock, so there is
no point in specifying it
- Conversely, the 1010 card has "dispersed" inputs, so say where the
ADAT port is, consistently with the S/PDIF port
- The 1616m CardBus card is actually named E-MU 02 (due to the headphone
output jack it has)
- Fix capitalization of "E-MU"
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230428095941.1706335-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Since commit 5bbb1ab5bd ("control: use counting semaphore as write lock
for ELEM_WRITE operation"), mixer values have been fully read-write
locked. This means that it is now unnecessary to apply any additional
locks to values that are accessed solely by mixer callbacks. Values that
are read outside mixer callbacks still need write locking. There are no
cases of mixer values being written outside mixer callbacks, so no read
locks remain in mixer callbacks.
Note that the removed locks refer only to the emu data structure, not
the card's registers as the lock's name suggests.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230428095941.1706278-7-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The function does read-modify-write cycles on the card's registers, and
doesn't access mutable members of the emu data structure.
I suppose this might have been a mixup due to the lock names being
logically swapped.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230428095941.1706278-4-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Contrary to its name, reg_lock locks the emu data structure, not the
registers. As the functions access only data which is set once at card
initialization, there is no point in locking it.
Actually locking the registers would be pointless as well, as
snd_emu10k1_intr_{en,dis}able() does its own locking, and TIMER is
accessed only in this one place.
Locking snd_emu10k1_timer_{start,stop}() against each other also
wouldn't buy us anything; the functions interleaving their I/O accesses
wouldn't introduce new problems.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230428095941.1706278-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Here are collections of small fixes for rc1.
The only (LOC-wise) dominant change was ASoC Qualcomm fix, but most
of it was merely a code shuffling.
Another significant change here is for ALSA PCM core; it received a
revert and a series of fixes for PCM auto-silencing where it caused
a regression in the previous PR for rc1.
Others are all small: ASoC Intel fixes, various quirks for ASoC AMD,
HD-audio and USB-audio, the continued legacy emu10k1 code cleanup,
and some documentation updates.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmRWACMOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE8vPA//Vh+gO0e1wcmCqeoIIJUwr5G0hQYY2Fp5Ke6A
3MuQAW3JyZ7hj5Xkor1PRalelinHUuvGMFDeazLnr92MV9zplnTisbKxp7EmDhJE
3iEdvj9evKTyMk7RpIhX1rhrHy0QLaCHDgDZDrv7IapyDpLUOl0lFtJQrlYV8DbS
b0uSBJ/kpMi5AH+W7RWpdnPIFd2j8tDiyKGBDpAo3l8TIjkwdsdKo9jBz7uNpf0R
tL8J6U4dA/Yo86XPAwg0g5tkug0vWOhZY8tdqNvJJFNgo9dW8ofqkCC4lg7JSmqM
ugTm/l0CZnEC09t2GSw7k7bsUGxZkWus7r8PTEw9CryGsR2pQYAvcjMMFpXqTu6K
Rc0PPkvFdmX2PIGtbkebwr/5y5Dbr2SmzqJjdkOSH91PZdle9RwN6k19dlXi1OFr
ucS9g5gAxGWMNwOnLFud3x+qIN1XwZuuHI1CZd7jhlQ3krV+dEl6m9sttFs4saPs
MNCMOXdVcKZ6NCBPRaCCwAEgP6Ttitdj25edTy1tKMr3td7ECInXQZiAPlAXLLwm
8aRscx07jj9cpfuk9fBTBvZdiAoK9KqYCLFSle4DzOJkyLuA9OiVFp3iixeoVIsb
fRQdaYdwq166SWtJSBbsRnfxI5zxKhxz/vx0SLNf32Flh2SyIU0kQ6Wk88V716L7
D4tPskk=
=jd8l
-----END PGP SIGNATURE-----
Merge tag 'sound-fix-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A collection of small fixes for rc1.
The only (LOC-wise) dominant change was ASoC Qualcomm fix, but most of
it was merely a code shuffling.
Another significant change here is for ALSA PCM core; it received a
revert and a series of fixes for PCM auto-silencing where it caused a
regression in the previous PR for rc1.
Others are all small: ASoC Intel fixes, various quirks for ASoC AMD,
HD-audio and USB-audio, the continued legacy emu10k1 code cleanup, and
some documentation updates"
* tag 'sound-fix-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (23 commits)
ALSA: pcm: use exit controlled loop in snd_pcm_playback_silence()
ALSA: pcm: simplify top-up mode init in snd_pcm_playback_silence()
ALSA: pcm: playback silence - move silence variable updates to separate function
ALSA: pcm: playback silence - remove extra code
ALSA: pcm: fix playback silence - correct incremental silencing
ALSA: pcm: fix playback silence - use the actual new_hw_ptr for the threshold mode
ALSA: pcm: Revert "ALSA: pcm: rewrite snd_pcm_playback_silence()"
ALSA: hda/realtek: Fix mute and micmute LEDs for an HP laptop
ALSA: caiaq: input: Add error handling for unsupported input methods in `snd_usb_caiaq_input_init`
ALSA: usb-audio: Add quirk for Pioneer DDJ-800
ALSA: hda/realtek: support HP Pavilion Aero 13-be0xxx Mute LED
ASoC: Intel: soc-acpi-cht: Add quirk for Nextbook Ares 8A tablet
ASoC: amd: yc: Add Asus VivoBook Pro 14 OLED M6400RC to the quirks list for acp6x
ASoC: codecs: wcd938x: fix accessing regmap on unattached devices
ALSA: docs: Fix code block indentation in ALSA driver example
ALSA: docs: Extend module parameters description
ALSA: hda/realtek: Add quirk for ASUS UM3402YAR using CS35L41
ALSA: emu10k1: use more existing defines instead of open-coded numbers
ASoC: amd: yc: Add ASUS M3402RA into DMI table
ALSA: hda/realtek: Add quirk for ThinkPad P1 Gen 6
...
There's another laptop that needs the fixup to enable mute and micmute
LEDs. So do it accordingly.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230505125925.543601-1-kai.heng.feng@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds support for the mute LED on the HP Pavilion Aero Laptop
13-be0xxx. The current behavior is that the LED does not turn on at any
time and does not indicate to the user whether the sound is muted.
The solution is to add a PCI quirk to properly recognize and support the
LED on this device.
This change has been tested on the device in question using modified
versions of kernels 6.0.7-6.2.12 on Arch Linux.
Signed-off-by: Caleb Harper <calebharp2005@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230503175026.6796-1-calebharp2005@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This Asus Zenbook laptop uses Realtek HDA codec combined with
2xCS35L41 Amplifiers using I2C with External Boost.
Signed-off-by: Mark Asselstine <asselsm@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230501231346.54979-1-asselsm@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Using the *_MASK defines for "maximal value" is debatable. I got the
idea from FreeBSD, and it sorta makes sense to me.
Some hunks look a bit incomplete, because code that is going to be
subsequently removed is not touched here.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230428080732.1697695-1-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A fairly standard release for SPI with the exception of a change to the
API for specifying chip selects done in preparation for supporting
devices with more than one chip select, this required some mechanical
changes throughout the tree which have been cooking in -next happily for
a while. There's also a new API to allow us to TPM chips on half duplex
controllers.
There's three commits in here that were mangled by a bad interaction
between the alsa-devel mailing list software and b4, I didn't notice
until there were merges on top with it being SPI not ALSA. It seemed
clear enough to not be worth going back and fixing.
- Refactoring in preparation for supporting multiple chip selects for a
single device, needed by some flash devices, which required a change
in the SPI device API visible throughout the tree.
- Support for hardware assisted interaction with SPI TPMs on half
duplex controllers, implemented on nVidia Tedra210 QuadSPI.
- Optimisation for large transfers on fsl-cpm devices.
- Cleanups around device property use which fix some sisues with
fwnode.
- Use of both void remove() and devm_platform_.*ioremap_resource().
- Support for AMD Pensando Elba, Amlogic A1, Cadence device mode,
Intel MetorLake-S and StarFive J7110 QuadSPI.
The final commit converting to DEV_PM_OPS() was applied late to fix a
warning that was introduced by some of the earlier work.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmRIFQgACgkQJNaLcl1U
h9BJOwf+JF2RySdn5g1LsyTndPZhLfw4iJgTHaMlnv5tiPHvYVYMM/mNMbMr5Znh
Y2T0OUkzuRfOK273C+hItC1bTYFTa2cEbDb5dpmKBOZdQ3hjGsZQBvuH2bScUQ+a
H7UgD3FYOJST6k6rRgZQxVMPePFrXAOaO1gmFWTR3v1EcEr2JeQnjZsmymFXcTnc
CtPg9N3RvhVnq5aXuxSgQeyyKIjo4LJh/eZ2mexPIu0DeUq3MftaWwSwCXFIoeNC
DMLA4mZWTgf/yt6JUALwLr+bIiJjb4qGjp3xGZ2wmX7zn73f9QQvuunKb1V4zbNF
EdXLo2VjA9cZjsihenBaKeHnkfgNfA==
=IRqY
-----END PGP SIGNATURE-----
Merge tag 'spi-v6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi updates from Mark Brown:
"A fairly standard release for SPI with the exception of a change to
the API for specifying chip selects done in preparation for supporting
devices with more than one chip select, this required some mechanical
changes throughout the tree which have been cooking in -next happily
for a while.
There's also a new API to allow us to support TPM chips on half duplex
controllers.
Summary:
- Refactoring in preparation for supporting multiple chip selects for
a single device, needed by some flash devices, which required a
change in the SPI device API visible throughout the tree
- Support for hardware assisted interaction with SPI TPMs on half
duplex controllers, implemented on nVidia Tedra210 QuadSPI
- Optimisation for large transfers on fsl-cpm devices
- Cleanups around device property use which fix some sisues with
fwnode
- Use of both void remove() and devm_platform_.*ioremap_resource()
- Support for AMD Pensando Elba, Amlogic A1, Cadence device mode,
Intel MetorLake-S and StarFive J7110 QuadSPI"
* tag 'spi-v6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: (185 commits)
spi: bcm63xx: use macro DEFINE_SIMPLE_DEV_PM_OPS
spi: tegra210-quad: Enable TPM wait polling
spi: Add TPM HW flow flag
spi: bcm63xx: remove PM_SLEEP based conditional compilation
spi: cadence-quadspi: use macro DEFINE_SIMPLE_DEV_PM_OPS
spi: spi-cadence: Add support for Slave mode
spi: spi-cadence: Switch to spi_controller structure
spi: cadence-quadspi: fix suspend-resume implementations
spi: dw: Add support for AMD Pensando Elba SoC
spi: dw: Add AMD Pensando Elba SoC SPI Controller
spi: cadence-quadspi: Disable the SPI before reconfiguring
spi: cadence-quadspi: Update the read timeout based on the length
spi: spi-loopback-test: Add module param for iteration length
spi: add support for Amlogic A1 SPI Flash Controller
dt-bindings: spi: add Amlogic A1 SPI controller
spi: fsl-spi: No need to check transfer length versus word size
spi: fsl-spi: Change mspi_apply_cpu_mode_quirks() to void
spi: fsl-cpm: Use 16 bit mode for large transfers with even size
spi: fsl-spi: Re-organise transfer bits_per_word adaptation
spi: fsl-spi: Fix CPM/QE mode Litte Endian
...
At this time, it's an interesting mixture of changes for both old and
new stuff. Majority of changes are about ASoC (lots of systematic
changes for converting remove callbacks to void, and cleanups), while
we got the fixes and the enhancements of very old PCI cards, too.
Here are some highlights:
ALSA/ASoC Core:
- Continued effort of more ASoC core cleanups
- Minor improvements for XRUN handling in indirect PCM helpers
- Code refactoring of PCM core code
ASoC:
- Continued feature and simplification work on SOF, including addition
of a no-DSP mode for bringup, HDA MLink and extensions to the IPC4
protocol
- Hibernation support for CS35L45
- More DT binding conversions
- Support for Cirrus Logic CS35L56, Freescale QMC, Maxim MAX98363,
nVidia systems with MAX9809x and RT5631, Realtek RT712, Renesas R-Car
Gen4, Rockchip RK3588 and TI TAS5733
ALSA:
- Lots of works for legacy emu10k1 and ymfpci PCI drivers
- PCM kselftest fixes and enhancements
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmRJBkcOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE8S/Q/+If1MEW+XXYushYU6VcWbHevwsRwmUZPtIJzT
Nx4PE4Ia8rX++GbsH5Iqt6tmldbb/vMbwy7TGbn/Q4ju2cO5qGT4/qgWdC2TuUX6
icWRHslJ//TffSd/yh1g6JIKBlcCmQeYcw5KoaLzBE/qO3iRP0IQUc17gkLKYNni
u1XOGrU9zuh3uwz+UQFfUhB8NlKhD3HVYjwrbd3gwcDsE/0G+q76A/wWghfA+RAb
0ruDhIDtJoem6PKQTwC05UgDpmwd7XFAIgcbOu7E7t/lr4YKwQZhQmJI0IexCR9i
aLPqg3Q/6S+WFKpcPcGCHNljqRNp9lUlIXak+NsbCZ7mXKE6tALywAtuB57sZ0sO
QM1YrmUAsi0RaD7foPcT64CAq8IVQ6aLWusXwvcxzzvJuHvJdeiBKiI5gmF0GqMu
ZLpAMGCoKxft4Il2r+BPTbLHe57uHmp1fKMWUK4NfyIUW7jEdKmf7ALSSJmvcqwU
+R0PXikc0lOo1GH9ZQojpVNFwV8XLOd2CWaNfoPl85A0+ngYhTY3ZRQ3qbYWHlU6
zXAu06IUOef5phsn3zerJ1orV729Xdjf+JUbL0uxJvANsX6R93CQWw0tgrUI62EZ
0vhoOp3PPZUKmDKvUo/NtIyuvSGREg3wDug5tiDOb53Qwfr2VIThJa999kNzH76c
lHUfrv4=
=7XGG
-----END PGP SIGNATURE-----
Merge tag 'sound-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound updates from Takashi Iwai:
"At this time, it's an interesting mixture of changes for both old and
new stuff. Majority of changes are about ASoC (lots of systematic
changes for converting remove callbacks to void, and cleanups), while
we got the fixes and the enhancements of very old PCI cards, too.
Here are some highlights:
ALSA/ASoC Core:
- Continued effort of more ASoC core cleanups
- Minor improvements for XRUN handling in indirect PCM helpers
- Code refactoring of PCM core code
ASoC:
- Continued feature and simplification work on SOF, including
addition of a no-DSP mode for bringup, HDA MLink and extensions to
the IPC4 protocol
- Hibernation support for CS35L45
- More DT binding conversions
- Support for Cirrus Logic CS35L56, Freescale QMC, Maxim MAX98363,
nVidia systems with MAX9809x and RT5631, Realtek RT712, Renesas
R-Car Gen4, Rockchip RK3588 and TI TAS5733
ALSA:
- Lots of works for legacy emu10k1 and ymfpci PCI drivers
- PCM kselftest fixes and enhancements"
* tag 'sound-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (586 commits)
ALSA: emu10k1: use high-level I/O in set_filterQ()
ALSA: emu10k1: use high-level I/O functions also during init
ALSA: emu10k1: fix error handling in snd_audigy_i2c_volume_put()
ALSA: emu10k1: don't stop DSP in _snd_emu10k1_{,audigy_}init_efx()
ALSA: emu10k1: fix SNDRV_EMU10K1_IOCTL_SINGLE_STEP
ALSA: emu10k1: skip Sound Blaster-specific hacks for E-MU cards
ALSA: emu10k1: fixup DSP defines
ALSA: emu10k1: pull in some register definitions from kX-project
ALSA: emu10k1: remove some bogus defines
ALSA: emu10k1: eliminate some unused defines
ALSA: emu10k1: fix lineup of EMU_HANA_* defines
ALSA: emu10k1: comment updates
ALSA: emu10k1: fix snd_emu1010_fpga_read() input masking for rev2 cards
ALSA: emu10k1: remove unused emu->pcm_playback_efx_substream field
ALSA: emu10k1: remove unused `resume` parameter from snd_emu10k1_init()
ALSA: emu10k1: minor optimizations
ALSA: emu10k1: remove remaining cruft from snd_emu10k1_emu1010_init()
ALSA: emu10k1: remove apparently pointless EMU_HANA_OPTION_CARDS reads
ALSA: emu10k1: remove apparently pointless FPGA reads
ALSA: emu10k1: stop doing weird things with HCFG in snd_emu10k1_emu1010_init()
...
Add a set of HD Audio PCI IDS, and the HDMI codec vendor IDs for
Glenfly Gpus.
- In default_bdl_pos_adj, set bdl to 128 as Glenfly Gpus have hardware
limitation, need to increase hdac interrupt interval.
- In azx_first_init, enable polling mode for Glenfly Gpu. When the codec
complete the command, it sends interrupt and writes response entries to
memory, howerver, the write requests sometimes are not actually
synchronized to memory when driver handle hdac interrupt on Glenfly Gpus.
If the RIRB status is not updated in the interrupt handler,
azx_rirb_get_response keeps trying to recevie a response from rirb until
1s timeout. Enabling polling mode for Glenfly Gpu can fix the issue.
- In patch_gf_hdmi, set Glenlfy Gpu Codec's no_sticky_stream as it need
driver to do actual clean-ups for the linked codec when switch from one
codec to another.
Signed-off-by: jasontao <jasontao@glenfly.com>
Signed-off-by: Reaper Li <reaperlioc@glenfly.com>
Link: https://lore.kernel.org/r/20230426013059.4329-1-reaperlioc@glenfly.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The bulk of the commits here are for the conversion of drivers to use
void remove callbacks but there's a reasonable amount of other stuff
going on, the pace of development with the SOF code continues to be high
and there's a bunch of new drivers too:
- More core cleanups from Morimto-san.
- Update drivers to have remove() callbacks returning void, mostly
mechanical with some substantial changes.
- Continued feature and simplification work on SOF, including addition
of a no-DSP mode for bringup, HDA MLink and extensions to the IPC4
protocol.
- Hibernation support for CS35L45.
- More DT binding conversions.
- Support for Cirrus Logic CS35L56, Freescale QMC, Maxim MAX98363,
nVidia systems with MAX9809x and RT5631, Realtek RT712, Renesas R-Car
Gen4, Rockchip RK3588 and TI TAS5733.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmRGdEsACgkQJNaLcl1U
h9BNVAf+Ijupg3dhAl6847v1PRYXkYK6YjAayhNd0xRoRePKnnv1zkrsXSBzxZUM
8KHpQDUJyfQbPnE2JRmr1WfHSoNDl/NXdJl+lefPBgol5bzxRji68hDPGjA0645o
R6vzrqLNw8mh3jwptXfEpQfKH8tIvwOeMeLkncDvsm0ZCUR2GhYnjB1g82ih0ssx
lvh36PdCRF0e/ruHxkiVn9b/riID65oTRkN6IxJqoPnqJZVyCiqmiJcfWePpaPir
4R9Dyk+REos/aCLdne1g6H21Tgi0td+blv6empqwdEXG41VSdRMTrOZb1ZISKmpF
ggPbKsk9BjJFBCewllHXJ0YEcBp9/g==
=TVxt
-----END PGP SIGNATURE-----
Merge tag 'asoc-v6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
ASoC: Updates for v6.4
The bulk of the commits here are for the conversion of drivers to use
void remove callbacks but there's a reasonable amount of other stuff
going on, the pace of development with the SOF code continues to be high
and there's a bunch of new drivers too:
- More core cleanups from Morimto-san.
- Update drivers to have remove() callbacks returning void, mostly
mechanical with some substantial changes.
- Continued feature and simplification work on SOF, including addition
of a no-DSP mode for bringup, HDA MLink and extensions to the IPC4
protocol.
- Hibernation support for CS35L45.
- More DT binding conversions.
- Support for Cirrus Logic CS35L56, Freescale QMC, Maxim MAX98363,
nVidia systems with MAX9809x and RT5631, Realtek RT712, Renesas R-Car
Gen4, Rockchip RK3588 and TI TAS5733.
