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>
Add helpers to program SPA/CPA bits, using a mutex to access the
shared LCTL register if required.
All links are managed with the same LCTLx.SPA bits. However there are
quite a few implementation details to be aware of:
Legacy HDaudio multi-links are powered-up when exiting reset, which
requires the ref_count to be manually set to one when initializing the
link.
Alternate links for SoundWire/DMIC/SSP need to be explicitly
powered-up before accessing the SHIM/IP/Vendor-Specific SHIM space for
each sublink. DMIC/SSP/SoundWire are all different cases with a
different device/dai/hlink relationship.
SoundWire will handle power management with the auxiliary device
resume/suspend routine. The ref_count is not necessary in this case.
The DMIC/SSP will by contrast handle the power management from DAI
.startup and .shutdown callbacks.
The SSP has a 1:1 mapping between sublink and DAI, but it's
bidirectional so the ref_count will help avoid turning off the sublink
when one of the two directions is still in use.
The DMIC has a single link but two DAIs for data generated at
different sampling frequencies, again the ref_count will make sure the
two DAIs can be used concurrently.
And last the SoundWire Intel require power-up/down and bank switch to
be handled with a lock already taken, so the 'eml_lock' is made
optional with the _unlocked versions of the helpers.
Note that the _check_power_active() implementation is similar to
previous helpers in sound/hda/ext, 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-9-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Extend hdac_ext_link to store information needed for ALT
links. Follow-up patches will include more functional patches for
power-up and down.
Note that this patch suggests the use of an 'eml_lock' to serialize
access to shared registers. SoundWire-specific sequence require the
lock to be taken at a higher level, as a result the helpers added in
follow-up patches will provide 'unlocked' versions when needed.
Also note that the low-level sequences with the 'hdaml_' prefix are
taken directly from the hardware specifications - naming conventions
included. The code will be split in two, with locking and linked-list
management handled separately to avoid mixing required hardware setup
and Linux-based resource management.
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-7-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Srinivas Kandagatla <srinivas.kandagatla@linaro.org>:
Click/Pop Noise was a long pending issue with WSA Codecs which are prone
to accumlate DC when ports are active but without any data streams.
There are multiple places in the current setup, where this could happen
in both startup as well as shutdown path.
dapm_connect_dai_pair() handles
"Normal/Codec2Codec" x "CPU/Codec" x "Playback/Capture".
(A) is "Codec2Codec" case of "CPU" widget x "Playback/Capture",
(B) is "Normal" case of "CPU" widget x "Playback/Capture",
(C) is each case of "Codec" widget.
(X) is handling "Playback" case DAI connecting,
(Y) is handling "Capture" case DAI connecting.
static void dapm_connect_dai_pair(...)
{
...
(A) if (dai_link->params) {
playback_cpu = ...
capture_cpu = ...
(B) } else {
playback_cpu = ...
capture_cpu = ...
}
^ /* connect BE DAI playback if widgets are valid */
| stream = SNDRV_PCM_STREAM_PLAYBACK;
| (C) codec = codec_dai->playback_widget;
|
| if (playback_cpu && codec) {
(X) if (dai_link->params && !rtd->c2c_widget[stream]) {
| ...
| }
|
| (z) dapm_connect_dai_routes(...);
v }
capture:
^ /* connect BE DAI capture if widgets are valid */
| stream = SNDRV_PCM_STREAM_CAPTURE;
| (C) codec = codec_dai->capture_widget;
|
| if (codec && capture_cpu) {
(Y) if (dai_link->params && !rtd->c2c_widget[stream]) {
| ...
| }
|
| (z) dapm_connect_dai_routes(...);
v }
}
(X) part and (Y) part are almost same.
Main purpose of these parts (and this function) is calling
dapm_connect_dai_routes() (= z) on each cases.
The difference is "parameter"
(= Normal/Codec2Codec x CPU/Codec x Playback/Capture).
This patch cleanup these, but nothing changed for meaning.
Link: https://lore.kernel.org/r/87ilen6ni4.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/877cuqvswc.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:
ASoC is supporting Codec2Codec, but its parameter name is
"params" and "num_params" which are very unclear naming.
This patch-set clarifies it by replacing to c2c_params / num_c2c_params.
Merge series from Peter Ujfalusi <peter.ujfalusi@linux.intel.com>:
This series will add support for SOF Linux stack to run without using the DSP.
DSPless mode provides a good tool for verification that the hardware itself
works correctly by taking the DSP use out from the picture.
It can only work with interfaces which supports this mode: Intel HDA at the
moment but with LNL it could be possible to support other audio interfaces.
The main driver for this mode is to be able to test programming sequences,
low-level code and for low-level verification of a platform.
The feature is not targetted for end-users and it will not make the SOF stack
to work on hardware without DSP, but it is giving us a tool to debug and enable
platforms earlier (when for example t he firmware is not mature enough).
Smatch Warns:
sound/soc/tegra/tegra20_ac97.c:321 tegra20_ac97_platform_probe()
warn: missing unwind goto?
The goto will set the "soc_ac97_ops" and "soc_ac97_bus" operations to
NULL. But they are already NULL at this point so it is a no-op.
However, just for consistency, change the direct return to a goto. No
functional change.
Signed-off-by: Zihao Wang <u202012060@hust.edu.cn>
Reviewed-by: Dan Carpenter <error27@gmail.com>
Link: https://lore.kernel.org/r/20230404084622.1202-1-u202012060@hust.edu.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
When the DSP is disabled in the BIOS, the DSP_BAR and PP_BAR cannot be
accessed.
One possible objection noted in initial reviews is that this patch
adds a number of branches. However the number of branches is actually
limited in probe/suspend/resume routines mostly, so there isn't really
a degradation in terms of readability and maintainability. Adding yet
another level of abstraction/ops/callbacks would increase complexity
and not really help in terms of code reuse or readability and
maintainability. A split between controller and DSP driver would be
even more invasive.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20230404092115.27949-7-peter.ujfalusi@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
ACP SOF driver supports different audio configurations.
Explicit condition check for I2S configuration will break
other audio endpoint configurations.
acp_dai_probe() function is not required as we have
machine select logic to select the exact machine.
Remove acp_dai_probe() from existing AMD PCI driver code base.
Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@amd.com>
Link: https://lore.kernel.org/r/20230403071651.919027-2-Vijendar.Mukunda@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The file named 'controls' in the DSP's debugfs root contains a
formatted table describing the controls defined within the loaded DSP
firmware, it is of the form
name: len region:offset addr fwname algid ctltype flags en dirty
Where flags is represented as a character for each flag if set, or '-',
enabled is whether the control is enabled or disabled and dirty is
whether the control value is set in the cache but not the hardware.
Signed-off-by: Simon Trimmer <simont@opensource.cirrus.com>
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20230328131018.6820-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
