Yet more preliminary work for the upcoming USB gadget support.
Now export the helpers to convert between legacy MIDI1 and UMP data
for handling the MIDI 1.0 USB interface. The header file is moved to
include/sound.
The API functions are slightly changed, so that they can be used
without the direct access to snd_ump object. The allocation is done
in ump.c itself as it's a simple kcalloc().
Link: https://lore.kernel.org/r/20230623075530.10976-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is another preliminary patch for USB MIDI 2.0 gadget driver.
Export the currently local snd_ump_receive_ump_val(). It can be used
by the gadget driver for processing the UMP data.
Link: https://lore.kernel.org/r/20230621110241.4751-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is another preliminary patch for USB MIDI 2.0 gadget driver.
Add a new flag, no_process_stream, to snd_ump for suppressing the UMP
Stream message handling in UMP core.
Link: https://lore.kernel.org/r/20230621110241.4751-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a preliminary patch for MIDI 2.0 USB gadget driver.
Export a new helper to allow changing the current MIDI protocol from
the outside.
Link: https://lore.kernel.org/r/20230621110241.4751-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
UMP v1.1 supports the protocol switch via a UMP Stream message. When
it's received, we need to take care of the midi_version field in the
corresponding sequencer client, too.
This patch introduces a new ops to notify the protocol change to
snd_seq_ump_ops for handling it.
Link: https://lore.kernel.org/r/20230612081054.17200-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch implements the handling of the dynamic update of FB info.
When the FB info update is received after the initial parsing, it
means the dynamic FB info update. We compare the result, and if the
actual update is detected, it's notified via a new ops,
notify_fb_change, to the sequencer client, and the corresponding
sequencer ports are updated accordingly.
Link: https://lore.kernel.org/r/20230612081054.17200-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The UMP Utility and Stream messages are "groupless", i.e. an incoming
groupless packet should be sent only to the UMP EP port, and the event
with the groupless message is sent to UMP EP as is without the group
translation per port.
Also, the former reserved bit 0 for the client group filter is now
used for groupless events. When the bit 0 is set, the groupless
events are filtered out and skipped.
Link: https://lore.kernel.org/r/20230612081054.17200-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds the basic support for UMP Endpoint and UMP Function
Block parsing, which are extended in the new UMP v1.1 spec.
The patch provides a new helper function to perform the query of the
UMP Endpoint information and builds up the UMP blocks based on UMP
Function Block information. For the communication over the UMP
Endpoint, it opens the rawmidi device once internally, inquiries the
UMP Endpoint and Function Block info by sending new UMP Stream
messages, and waits for the response for each query.
The new UMP spec allows to update the FB info and change its
associated groups or its activeness on the fly, too. For catching it,
the UMP core keeps watching the incoming UMP messages, and
snd_ump_receive() handles the incoming UMP Stream messages to refresh
the FB info.
Link: https://lore.kernel.org/r/20230612081054.17200-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The #endif is placed obviously at a wrong position, which caused a
build error on the big endian machine.
Fixes: 0b5288f5fe ("ALSA: ump: Add legacy raw MIDI support")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://lore.kernel.org/r/20230524135448.3ecad334@canb.auug.org.au
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch introduces a new ALSA sequencer client for the kernel UMP
object, snd-seq-ump-client. It's a UMP version of snd-seq-midi
driver, while this driver creates a sequencer client per UMP endpoint
which contains (fixed) 16 ports.
The UMP rawmidi device is opened in APPEND mode for output, so that
multiple sequencer clients can share the same UMP endpoint, as well as
the legacy UMP rawmidi devices that are opened in APPEND mode, too.
For input, on the other hand, the incoming data is processed on the
fly in the dedicated hook, hence it doesn't open a rawmidi device.
The UMP packet group is updated upon delivery depending on the target
sequencer port (which corresponds to the actual UMP group).
Each sequencer port sets a new port type bit,
SNDRV_SEQ_PORT_TYPE_MIDI_UMP, in addition to the other standard
types for MIDI.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-33-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Starting from this commit, we add the basic support of UMP (Universal
MIDI Packet) events on ALSA sequencer infrastructure. The biggest
change here is that, for transferring UMP packets that are up to 128
bits, we extend the data payload of ALSA sequencer event record when
the client is declared to support for the new UMP events.
A new event flag bit, SNDRV_SEQ_EVENT_UMP, is defined and it shall be
set for the UMP packet events that have the larger payload of 128
bits, defined as struct snd_seq_ump_event.
For controlling the UMP feature enablement in kernel, a new Kconfig,
CONFIG_SND_SEQ_UMP is introduced. The extended event for UMP is
available only when this Kconfig item is set. Similarly, the size of
the internal snd_seq_event_cell also increases (in 4 bytes) when the
Kconfig item is set. (But the size increase is effective only for
32bit architectures; 64bit archs already have padding there.)
Overall, when CONFIG_SND_SEQ_UMP isn't set, there is no change in the
event and cell, keeping the old sizes.
For applications that want to access the UMP packets, first of all, a
sequencer client has to declare the user-protocol to match with the
latest one via the new SNDRV_SEQ_IOCTL_USER_PVERSION; otherwise it's
treated as if a legacy client without UMP support.
Then the client can switch to the new UMP mode (MIDI 1.0 or MIDI 2.0)
with a new field, midi_version, in snd_seq_client_info. When switched
to UMP mode (midi_version = 1 or 2), the client can write the UMP
events with SNDRV_SEQ_EVENT_UMP flag. For reads, the alignment size
is changed from snd_seq_event (28 bytes) to snd_seq_ump_event (32
bytes). When a UMP sequencer event is delivered to a legacy sequencer
client, it's ignored or handled as an error.
Conceptually, ALSA sequencer client and port correspond to the UMP
Endpoint and Group, respectively; each client may have multiple ports
and each port has the fixed number (16) of channels, total up to 256
channels.
As of this commit, ALSA sequencer core just sends and receives the UMP
events as-is from/to clients. The automatic conversions between the
legacy events and the new UMP events will be implemented in a later
patch.
Along with this commit, bump the sequencer protocol version to 1.0.3.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-26-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Create a new variant of snd_seq_expand_var_event() for expanding the
data starting from the given byte offset. It'll be used by the new
UMP sequencer code later.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-19-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch extends the UMP core code to support the legacy MIDI 1.0
rawmidi devices. When the new kconfig CONFIG_SND_UMP_LEGACY_RAWMIDI
is set, the UMP core allows to attach an additional rawmidi device for
each UMP Endpoint. The rawmidi device contains 16 substreams where
each substream corresponds to a UMP Group belonging to the EP. The
device reads/writes the legacy MIDI 1.0 byte streams and translates
from/to UMP packets.
The legacy rawmidi devices are exclusive with the UMP rawmidi devices,
hence both of them can't be opened at the same time unless the UMP
rawmidi is opened in APPEND mode.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-15-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a code refactoring for abstracting the rawmidi access to the
UMP's own helpers. It's a preliminary work for the later code
refactoring of the UMP layer.
Until now, we access to the rawmidi substream directly from the
driver via rawmidi access helpers, but after this change, the driver
is supposed to access via the newly introduced snd_ump_ops and
receive/transmit via snd_ump_receive() and snd_ump_transmit() helpers.
As of this commit, those are merely wrappers for the rawmidi
substream, and no much function change is seen here.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-14-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
UMP devices may have more interesting information than the traditional
rawmidi. Extend the rawmidi_global_ops to allow the optional proc
info output and show some more bits in the proc file for UMP.
Note that the "Groups" field shows the first and the last UMP Groups,
and both numbers are 1-based (i.e. the first group is 1).
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This patch adds the support helpers for UMP (Universal MIDI Packet) in
ALSA core.
The basic design is that a rawmidi instance is assigned to each UMP
Endpoint. A UMP Endpoint provides a UMP stream, typically
bidirectional (but can be also uni-directional, too), which may hold
up to 16 UMP Groups, where each UMP (input/output) Group corresponds
to the traditional MIDI I/O Endpoint.
Additionally, the ALSA UMP abstraction provides the multiple UMP
Blocks that can be assigned to each UMP Endpoint. A UMP Block is a
metadata to hold the UMP Group clusters, and can represent the
functions assigned to each UMP Group. A typical implementation of UMP
Block is the Group Terminal Blocks of USB MIDI 2.0 specification.
For distinguishing from the legacy byte-stream MIDI device, a new
device "umpC*D*" will be created, instead of the standard (MIDI 1.0)
devices "midiC*D*". The UMP instance can be identified by the new
rawmidi info bit SNDRV_RAWMIDI_INFO_UMP, too.
A UMP rawmidi device reads/writes only in 4-bytes words alignment,
stored in CPU native endianness.
The transmit and receive functions take care of the input/out data
alignment, and may return zero or aligned size, and the params ioctl
may return -EINVAL when the given input/output buffer size isn't
aligned.
A few new UMP-specific ioctls are added for obtaining the new UMP
endpoint and block information.
As of this commit, no ALSA sequencer instance is attached to UMP
devices yet. They will be supported by later patches.
Along with those changes, the protocol version for rawmidi is bumped
to 2.0.3.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-4-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A new callback, ioctl, is added to snd_rawmidi_global_ops for allowing
the driver to deal with the own ioctls. This is another preparation
patch for the upcoming UMP support.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
snd_rawmidi_kernel_open() is used only internally from ALSA sequencer,
so far, and parsing the card / device matching table at each open is
redundant, as each sequencer client already gets the rawmidi object
beforehand.
This patch optimizes the path by passing the rawmidi object directly
at snd_rawmidi_kernel_open(). This is also a preparation for the
upcoming UMP rawmidi I/O support.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20230523075358.9672-2-tiwai@suse.de
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.
Firstly, fix the distribution between public and private headers.
Otherwise, some of the already public macros wouldn't actually work, and
the SNDRV_EMU10K1_IOCTL_DBG_READ result for Audigy would be useless.
Secondly, add condition code registers for Audigy. These are just
aliases for selected constant registers, and thus are generation-
specific. At least A_CC_REG_ZERO is actually correct ...
Finally, shuffle around some defines to more logical places while at it,
and fix up some more comments.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230422161021.1143903-7-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For documentation purposes and later use.
Some pre-existing but (mostly) unused definitions were renamed for
consistency.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230422161021.1143903-6-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Firstly, remove the FXWC_* defines - the comment on FXWC implies that
the relevant defines are the (A_)EXTOUT_* ones. It's unclear where this
came from - it was in the initial ALSA import, but neither the driver
from Creative nor kX-project have these defines.
Secondly, remove A_HR, which made plain no sense (was unused, and
clashed with FXRT). Amends commit cbb7d8f9b7 ("emu10k1: Update
registers defines for the Audigy 2/emu10k2.5").
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230422161021.1143903-5-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Move comments to better locations, de-duplicate, fix/remove incorrect/
outdated ones, add new ones, and unify spacing somewhat.
While at it, also add testing credits for Jonathan Dowland (SB Live!
Platinum) and myself (E-MU 0404b).
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230422161021.1143903-2-oswald.buddenhagen@gmx.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Unlike the Alice2 chips used on 1st generation E-MU cards, the
Tina/Tina2 chips used on the 2nd gen cards have only six GPIN pins,
which means that we need to use a smaller mask. Failure to do so would
falsify the read data if the FPGA tried to raise an IRQ right at that
moment. This wasn't a problem so far, as we didn't actually enable FPGA
IRQs, but that's going to change soon.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230422132430.1057490-1-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>
The use of the variable was removed in commit 2b637da5a1 ("clean up
card features"). That commit also broke user space (the ioctl
structure), at which point the defines became meaningless, so I don't
think purging them is a problem.
Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
Link: https://lore.kernel.org/r/20230421141006.1005452-3-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>
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>
Rename the mixer source defines from CS35L56_INPUT_SRC_SWIRE_RXn
to CS35L56_INPUT_SRC_SWIRE_DP1_CHANNELn to match the latest
datasheet.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230418144309.1100721-5-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The mixer source index value for SDW2RX1 is different between
A1 and B0 silicon. As the driver doesn't provide a DAI for SDW2
just remove it as a mixer source option.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230418144309.1100721-4-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Reduce SDW1 to 4 channels and remove the controls for SDW1
TX5 and TX6.
The TX5 and TX6 channels have been removed from B0 silicon.
There is no need to support them on A1 silicon.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230418144309.1100721-3-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC need to use card->mutex with _INIT or _RUNTIME,
but there is no helper function for it.
This patch adds its helper function and use it.
Because people might misunderstand that _init() is mutex initialization,
this patch renames _INIT to _ROOT and adds new
snd_soc_card_mutex_lock_root() for it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87a5zlx3tw.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
soc-pcm.c has snd_soc_dpcm_mutex_lock/unlock(),
but other files can't use it because it is static function.
It requests snd_soc_pcm_runtime as parameter (A), but sometimes we
want to use it by snd_soc_card (B).
(A) static inline void snd_soc_dpcm_mutex_lock(struct snd_soc_pcm_runtime *rtd)
{
mutex_lock_nested(&rtd->card->pcm_mutex, rtd->card->pcm_subclass);
} ^^^^^^^^^
(B) mutex_lock_nested(&card->pcm_mutex, card->pcm_subclass);
^^^^
We want to use it with both "rtd" and "card" for dapm lock/unlock.
To enable it, this patch uses _Generic macro.
This patch makes snd_soc_dpcm_mutex_{un}lock() global function, and use it on
each files.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87bkk1x3ud.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
soc.h has snd_soc_dapm_mutex_lock/unlock() definition and
many drivers are using it, but soc-dapm.c is not.
1st reason is snd_soc_dapm_mutex_lock/unlock() requests
snd_soc_dapm_context pointer as parameter (A), but sometimes soc-dapm.c
needs to use snd_soc_card (B).
(A) static inline void snd_soc_dapm_mutex_lock(struct snd_soc_dapm_context *dapm)
{
mutex_lock_nested(&dapm->card->dapm_mutex, SND_SOC_DAPM_CLASS_RUNTIME);
} ^^^^^^^^^^
(B) mutex_lock_nested(&card->dapm_mutex, SND_SOC_DAPM_CLASS_RUNTIME);
^^^^
2nd reason is it want to use SND_SOC_DAPM_CLASS_INIT for mutex_lock_nested(),
but helper is using _RUNTIME (A).
The conclusion is we want to use "dapm vs card" and "_RUNTIME vs _INIT"
for dapm lock/unlock. To enable this selfish request, this patch uses
_Generic macro. We can use snd_soc_dapm_mutex_lock/unlock() for both
dapm and card case.
snd_soc_dapm_mutex_lock(dapm); snd_soc_dapm_mutex_unlock(dapm);
snd_soc_dapm_mutex_lock(card); snd_soc_dapm_mutex_unlock(card);
Current soc-dapm.c is using both mutex_lock() and mutex_lock_nested().
This patch handles mutex_lock() as mutex_lock_nested(..., 0),
in other words, handles below as same.
mutex_lock(&card->dapm_mutex);
mutex_lock_nested(&card->dapm_mutex, SND_SOC_DAPM_CLASS_INIT);
Because people might misunderstand that _init() is mutex initialization,
this patch renames _INIT to _ROOT and adds new
snd_soc_dapm_mutex_lock_root() for it.
This patch also moves snd_soc_dapm_subclass definition from soc-dapm.h
to soc.h to keep related code together.
Because very complex soc.h vs soc-dapm.h relationship,
it is difficult/impossible to define these helper into soc-dapm.h.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87cz4hx3v0.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Check during cs35l56_system_resume() whether the firmware patch must
be applied again.
The FIRMWARE_MISSING flag in the PROTECTION_STATUS register indicates
whether the firmware has been patched.
In non-secure mode the FIRMWARE_MISSING flag is cleared at the end of
dsp_work(). If it is set after system-resume we know that dsp_work()
must be run again.
In secure mode the pre-OS loader will have done the secure patching
and cleared the FIRMWARE_MISSING flag. So this flag does not tell us
whether firmware memory was lost. But the driver could only be
downloading non-secure tunings, which is always safe to do.
If the driver has control of RESET we will have asserted it during
suspend so the firmware patch will have been lost. The driver would only
have control of RESET in non-secure mode.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/168122674550.26.8545058503709956172@mailman-core.alsa-project.org
Signed-off-by: Mark Brown <broonie@kernel.org>
For SoundWire usages, we need to use the global eml_lock to
serialize/protect all accesses to shared registers. Due to the split
implementation across two subsystems, we need to pass a pointer
around.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@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>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20230404104127.5629-19-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
For DMIC and SSP, the DSP will be responsible for programming the
blobs and link registers.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@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>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20230404104127.5629-18-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Small helpers to make DAI ops simpler.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@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>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20230404104127.5629-17-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Each SoundWire peripheral can be programmed from the manager side
either with a regular command FIFO, or with the HDaudio CORB/RIRB
DMA-based mechanism. The mapping between SoundWire peripheral and SDI
address is handled with the LSDIID register.
This mapping only works of course if each peripheral has a unique
address across all links. This has already been enforced in previous
Intel contributions allowing for an IDA-based solution for the device
number allocation.
The checks on the dev_num are handled at the SoundWire level, but the
locking is handled at the hda-mlink level.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@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>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20230404104127.5629-16-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This helper is an optimization where sync_go is only called when the
cmdsync field is actually set to a non-zero value.
Since this is also only used by SoundWire for now, only expose the
_unlocked version.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@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>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20230404104127.5629-15-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The multi-link synchronization uses the same concept and registers,
but moved to the HDAudio extended links.
Add helpers for sync_arm and sync_go which are the basic for the bus
reset, bank switch and clock stop.
Since SoundWire is the only user of those helpers, only expose the
_unlocked versions for now.
Note that SYNCGO is a write-only bit, so no error can be reported. We
still return 0 for compatibility with the SoundWire stream management
headers.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@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>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20230404104127.5629-14-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
These helpers configure the ratio between the base clock and the
hardware signal used for link synchronization.
The SYNCPRD is written before the first sublink is powered-up. The
SYNCPU bit is set, but it will only be cleared after the link is
powered-up, hence the implementation with a set/wait pattern.
These helpers are currently only needed by SoundWire support, where
the lock is taken at a higher level, so only the _unlocked versions
are exposed for now.
Note that the _wait_bit() implementation is similar to previous
helpers in drivers/soundwire, but with sleep duration and timeout
aligned with hardware recommendations. If desired, this helper could
be modified in a second step with e.g. readl_poll_timeout().
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@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>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20230404104127.5629-13-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
