| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Add implementation for reading the LDP (Linear DMA Position) to be used as
get_host_byte_counter().
The LDP is counting the number of bytes moved between the DSP and host
memory.
Set the get_dai_frame_counter to hda_dsp_get_stream_llp, which is counting
the frames on the link side of the DSP.
Cc: [email protected] # 6.8
Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
For delay calculation we need two information:
Number of bytes transferred between the DSP and host memory (ALSA buffer)
Number of frames transferred between the DSP and external device
(link/codec/DMIC/etc).
The reason for the different units (bytes vs frames) on host and dai side
is that the format on the dai side is decided by the firmware and might
not be the same as on the host side, thus the expectation is that the
counter reflects the number of frames.
The kernel know the host side format and in there we have access to the
DMA position which is in bytes.
In a simplified way, the DSP caused delay is the difference between the
two counters.
The existing get_stream_position callback is defined to retrieve the frame
counter on the DAI side but it's name is too generic to be intuitive and
makes it hard to define a callback for the host side.
This patch introduces a new set of callbacks to replace the
get_stream_position and define the host side equivalent:
get_dai_frame_counter
get_host_byte_counter
Subsequent patches will remove the old callback.
Cc: [email protected] # 6.8
Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Drop the MTL mtl_dsp_get_stream_hda_link_position() function and related
defines since it can only work on platforms which have 19 streams because
of the use of 0x948 as base offset for the LLP registers.
The generic hda_dsp_get_stream_hda_link_position() takes the number of
streams into consideration when reading the LLP registers for the stream
and can handle different HDA configurations.
Cc: [email protected] # 6.8
Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Rander Wang <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
When the Linear Link Position is not available in firmware SRAM window we
use the host accessible position registers to read it.
The address of the PPLCLLPL/U registers depend on the number of streams
(playback+capture).
At probe time the pplc_addr is calculated for each stream and we can use
it to read the LLP without the need of address re-calculation.
Set the get_stream_position callback in sof_hda_common_ops for all
platforms:
The callback is used for IPC4 delay calculations only but the register is
a generic HDA register, not tied to any specific IPC version.
Cc: [email protected] # 6.8
Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Rander Wang <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
If the PCM have the dsp_max_burst_size_in_ms set then place a constraint
to limit the minimum buffer time to avoid xruns caused by DMA bursts
spinning on the ALSA buffer.
Cc: [email protected] # 6.8
Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
When setting up the pcm widget, save the DSP buffer size (in ms) for
platform code to place a constraint on playback.
On playback the DMA will fill the buffer on start and if the period
size is smaller it will immediately overrun.
On capture the DMA will move data in 1ms bursts.
Cc: [email protected] # 6.8
Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
The dsp_max_burst_size_in_ms can be used to save the length of the maximum
burst size in ms the host DMA will use.
Platform code can place constraint using this to avoid user space
requesting too small ALSA buffer which will result xruns.
Cc: [email protected] # 6.8
Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
The endpoint in NHLT table for a SSP port could have the device type
NHLT_DEVICE_BT or NHLT_DEVICE_I2S. Use intel_nhlt_ssp_device_type()
function to retrieve the device type before querying the endpoint
blob to make sure we are always using correct device type parameter.
Signed-off-by: Brent Lu <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Acked-by: Mark Brown <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Message-ID: <[email protected]>
|
|
The recent introduction of the ACP/PSP communication for IRAM/DRAM fence
register modification breaks the audio support on Valve's Steam Deck
OLED device.
It causes IPC timeout errors when trying to load DSP topology during
probing:
1707255557.688176 kernel: snd_sof_amd_vangogh 0000:04:00.5: ipc tx timed out for 0x30100000 (msg/reply size: 48/0)
1707255557.689035 kernel: snd_sof_amd_vangogh 0000:04:00.5: ------------[ IPC dump start ]------------
1707255557.689421 kernel: snd_sof_amd_vangogh 0000:04:00.5: dsp_msg = 0x0 dsp_ack = 0x91d14f6f host_msg = 0x1 host_ack = 0xead0f1a4 irq_stat >
1707255557.689730 kernel: snd_sof_amd_vangogh 0000:04:00.5: ------------[ IPC dump end ]------------
1707255557.690074 kernel: snd_sof_amd_vangogh 0000:04:00.5: ------------[ DSP dump start ]------------
1707255557.690376 kernel: snd_sof_amd_vangogh 0000:04:00.5: IPC timeout
1707255557.690744 kernel: snd_sof_amd_vangogh 0000:04:00.5: fw_state: SOF_FW_BOOT_COMPLETE (7)
1707255557.691037 kernel: snd_sof_amd_vangogh 0000:04:00.5: invalid header size 0xdb43fe7. FW oops is bogus
1707255557.694824 kernel: snd_sof_amd_vangogh 0000:04:00.5: unexpected fault 0x6942d3b3 trace 0x6942d3b3
1707255557.695392 kernel: snd_sof_amd_vangogh 0000:04:00.5: ------------[ DSP dump end ]------------
1707255557.695755 kernel: snd_sof_amd_vangogh 0000:04:00.5: Failed to setup widget PIPELINE.6.ACPHS1.IN
1707255557.696069 kernel: snd_sof_amd_vangogh 0000:04:00.5: error: tplg component load failed -110
1707255557.696374 kernel: snd_sof_amd_vangogh 0000:04:00.5: error: failed to load DSP topology -22
1707255557.697904 kernel: snd_sof_amd_vangogh 0000:04:00.5: ASoC: error at snd_soc_component_probe on 0000:04:00.5: -22
1707255557.698405 kernel: sof_mach nau8821-max: ASoC: failed to instantiate card -22
1707255557.701061 kernel: sof_mach nau8821-max: error -EINVAL: Failed to register card(sof-nau8821-max)
1707255557.701624 kernel: sof_mach: probe of nau8821-max failed with error -22
Introduce a new member skip_iram_dram_size_mod to struct acp_quirk_entry and
use it to skip IRAM/DRAM size modification for Vangogh Galileo device.
Fixes: 55d7bbe43346 ("ASoC: SOF: amd: Add acp-psp mailbox interface for iram-dram fence register modification")
Signed-off-by: Cristian Ciocaltea <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
The signed_fw_image member of struct sof_amd_acp_desc is used to enable
signed firmware support in the driver via the acp_sof_quirk_table.
In preparation to support additional use cases of the quirk table (i.e.
adding new flags), move signed_fw_image to a new struct acp_quirk_entry
and update all references to it accordingly.
No functional changes intended.
Signed-off-by: Cristian Ciocaltea <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Merge series from Cezary Rojewski <[email protected]>:
The avs-driver continues to be utilized on more recent Intel machines.
As TGL-based (cAVS 2.5) e.g.: RPL, inherit most of the functionality
from previous platforms:
SKL <- APL <- CNL <- ICL <- TGL
rather than putting everything into a single file, the platform-specific
bits are split into cnl/icl/tgl.c files instead. Makes the division clear
and code easier to maintain.
Layout of the patchset:
First are two changes combined together address the sound-clipping
problem, present when only one stream is running - specifically one
CAPTURE stream.
Follow up is naming-scheme adjustment for some of the existing functions
what improves code incohesiveness. As existing IPC/IRQ code operates
solely on cAVS 1.5 architecture, it needs no abstraction. The situation
changes when newer platforms come into the picture. Thus the next two
patches abstract the existing IPC/IRQ handlers so that majority of the
common code can be re-used.
The ICCMAX change stands out a bit - the AudioDSP firmware loading
procedure differs on ICL-based platforms (and onwards) and having a
separate commit makes the situation clear to the developers who are
going to support the solution from LTS perspective. For that reason
I decided not to merge it into the commit introducing the icl.c file.
|
|
The soundwire-amd driver has a bit of a layering violation requiring
the SOF driver to directly call into its exported symbols rather than
through an abstraction.
The SND_SOC_SOF_AMD_SOUNDWIRE Kconfig symbol tries to deal with the
dependency by selecting SOUNDWIRE_AMD in a complicated set of conditions,
but gets it wrong for a configuration involving SND_SOC_SOF_AMD_COMMON=y,
SND_SOC_SOF_AMD_ACP63=m, and SND_SOC_SOF_AMD_SOUNDWIRE_LINK_BASELINE=m
SOUNDWIRE_AMD=m, which results in a link failure:
ld.lld: error: undefined symbol: sdw_amd_get_slave_info
>>> referenced by acp-common.c
ld.lld: error: undefined symbol: amd_sdw_scan_controller
ld.lld: error: undefined symbol: sdw_amd_probe
ld.lld: error: undefined symbol: sdw_amd_exit
>>> referenced by acp.c
>>> sound/soc/sof/amd/acp.o:(amd_sof_acp_remove) in archive vmlinux.a
In essence, the SND_SOC_SOF_AMD_COMMON option cannot be built-in when
trying to link against a modular SOUNDWIRE_AMD driver.
Since CONFIG_SOUNDWIRE_AMD is a user-visible option, it really should
never be selected by another driver in the first place, so replace the
extra complexity with a normal Kconfig dependency in SND_SOC_SOF_AMD_SOUNDWIRE,
plus a top-level check that forbids any of the AMD SOF drivers from being
built-in with CONFIG_SOUNDWIRE_AMD=m.
In normal configs, they should all either be built-in or all loadable
modules anyway, so this simplification does not limit any real usecases.
Fixes: d948218424bf ("ASoC: SOF: amd: add code for invoking soundwire manager helper functions")
Signed-off-by: Arnd Bergmann <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Smatch complains about "head->full_size - head->header_size" can
underflow. To some extent, we're always going to have to trust the
firmware a bit. However, it's easy enough to add a check for negatives,
and let's add a upper bounds check as well.
Fixes: d2458baa799f ("ASoC: SOF: ipc3-loader: Implement firmware parsing and loading")
Signed-off-by: Dan Carpenter <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Merge series from Peter Ujfalusi <[email protected]>:
For both ChainDMA and DSPless mode the requirement is that the link must
be serviced by HD-DMA.
On pre Lunar Lake platforms this was only valid for HDAudio links but with
Lunar Lake all link types now serviced by HD-DMA.
This allows us to enable ChainDMA and DSPless mode for SoundWire links as
well.
|
|
Merge series from Peter Ujfalusi <[email protected]>:
Hi,
Align the IPC4 firmware path/name and the topology path to the documentation:
default_fw_path: intel/sof-ipc4/{platform_name}
default_lib_path: intel/sof-ipc4-lib/{platform_name}
default_tplg_path: intel/sof-ipc4-tplg
default_fw_filename: sof-{platform_name}.ri
Tiger Lake and Lunar Lake support is not yet available via the official
firmware release, the paths can be changed now to avoid misalignment in the
future.
Regards,
Peter
---
Peter Ujfalusi (2):
ASoC: SOF: Intel: pci-tgl: Change the default paths and firmware names
ASoC: SOF: Intel: pci-lnl: Change the topology path to
intel/sof-ipc4-tplg
sound/soc/sof/intel/pci-lnl.c | 2 +-
sound/soc/sof/intel/pci-tgl.c | 64 +++++++++++++++++------------------
2 files changed, 33 insertions(+), 33 deletions(-)
--
2.43.0
|
|
Set ipc4_copier->data.gtw_cfg.config_length dynamically based on
blob->alh_cfg.device_count to align with the other OS.
Signed-off-by: Bard Liao <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
If the retain context is enabled we will unconditionally increment the
device's pm use count on each exception and when the drivers are unloaded
we do not correct this (as we don't know how many times we 'prevented
d3 entry').
Introduce a flag to make sure that we do not increment the use count more
than once and on module unload decrement the use count if needed to
balance it.
Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
For SoundWire/ALH, we need to have a dai configured, but we don't want
to send a DMA_TLV to firmware. Add additional code branches.
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
When DSPless mode is selected the DMIC/SSP offload status should not be
changed since the DSP is not in use.
Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
This mode is only supported starting with LunarLake (ACE_2_0).
DMIC and SSP remain supported with the DSP only for now, since they
need a DAI configuration that is provided to firmware.
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Now that we have the dai_type we can remove any dependencies on
copiers.
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Starting with LunarLake, the dspless mode can handle SoundWire/ALH,
DMIC and SSPs, so we need to identify the dai type from topology.
Signed-off-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
The SoundWire integration is different from previous platforms, with
no dependencies on the DSP enablement. We can start the SoundWire
links in the probe instead of waiting for the post_fw_run stage.
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
For dspless mode, we need to allocate and store an 'sdai'
structure. The existing code allocate the data on the stack and does
not set the widget->private pointer.
This minor change should not have any impact on existing DAIs, even
when the DSP is used.
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
The existing code forces a parameter to be NULL but that parameter is
not used yet. Remove the special case in preparation for additional
changes.
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Now that we have a 'is_chain_dma_supported' callback we can use it to
double-check possible disconnects between a topology file enabling
chain-dma for a DAI and the hardware/firmware capabilities.
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Reviewed-by: Rander Wang <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
The existing code uses (stream_tag - 1) for the host and link dma id.
This is correct for playback, but for capture this results in an
invalid dma_type being used. The firmware assumes that the dma_id for
capture is always larger than DAI_NUM_HDA_OUT
This patch adds the offset for num_playback_streams, filled on Intel
platforms with the value extracted from the hardware capabilities.
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
The CHAIN_DMA IPC needs the number of playback streams as a start
offset for the dma_id of a capture stream.
This offset can be retrieved on Intel platforms from the GCAP
information, and stored in the sof_ipc4_fw_data structure.
One could argue that the fields added are not really dependent on any
firmware definitions but rather on hardware capabilities, but they are
required for the IPC CHAIN_DMA definitions so adding them in
ipc4_fw_data isn't completely silly.
The CHAIN_DMA IPC is currently only functional on Intel HDaudio DMAs,
and gated by the snd_sof_is_chain_dma_supported() helper.
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Use the existing callbacks and mix/match of HDaudio and SoundWire
support.
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Reviewed-by: Rander Wang <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Reuse existing function to get the interface mask and expose it to the
SOF core with a callback - the main user is the IPC4 topology so only
HDaudio platforms provide this callback.
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Reviewed-by: Rander Wang <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
IPC4 introduced a 'chain-dma' mode when host and link DMA are
connected by firmware without using a regular pipeline or the ability
to add intermediate connections. This mode is not available on all
platforms and all links, so add a platform-specific callback to help
the SOF ipc4-topology core handle different hardware+firmware
configurations.
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Reviewed-by: Rander Wang <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
The chain_dma mode is currently only handled for HDaudio, but can be
used for orther DAIs starting with LunarLake. Move the chain_dma
handling earlier.
Error detection for the chain_dma case for older platforms is handled
at a different level.
Signed-off-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Reviewed-by: Rander Wang <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
commit 74ad8ed65121 ("ASoC: SOF: ipc3: Implement rx_msg IPC ops")
introduced a new allocation before the upper bounds check in
do_rx_work. As a result A DSP can cause bad allocations if spewing
garbage.
Fixes: 74ad8ed65121 ("ASoC: SOF: ipc3: Implement rx_msg IPC ops")
Reported-by: Tim Van Patten <[email protected]>
Cc: [email protected]
Signed-off-by: Curtis Malainey <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Reviewed-by: Daniel Baluta <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
When the system is suspended while audio is active, the
sof_ipc4_pcm_hw_free() is invoked to reset the pipelines since during
suspend the DSP is turned off, streams will be re-started after resume.
If the firmware crashes during while audio is running (or when we reset
the stream before suspend) then the sof_ipc4_set_multi_pipeline_state()
will fail with IPC error and the state change is interrupted.
This will cause misalignment between the kernel and firmware state on next
DSP boot resulting errors returned by firmware for IPC messages, eventually
failing the audio resume.
On stream close the errors are ignored so the kernel state will be
corrected on the next DSP boot, so the second boot after the DSP panic.
If sof_ipc4_trigger_pipelines() is called from sof_ipc4_pcm_hw_free() then
state parameter is SOF_IPC4_PIPE_RESET and only in this case.
Treat a forced pipeline reset similarly to how we treat a pcm_free by
ignoring error on state sending to allow the kernel's state to be
consistent with the state the firmware will have after the next boot.
Link: https://github.com/thesofproject/sof/issues/8721
Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
The firmware release which going to introduce support for Lunar Lake will
use the documented default topology directory for IPC4:
intel/sof-ipc4-tplg
Change the default path accordingly before sof-bin (sof-firmware) release
includes Lunar Lake firmware and topologies.
Link: https://github.com/thesofproject/sof-docs/blob/master/getting_started/intel_debug/introduction.rst#2-topology-file
Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Mengdong Lin <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Chao Song <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
The currently used paths and firmware name reflects the reference firmware
convention:
default_fw_path: intel/avs/{platform_name}
default_lib_path: intel/avs-lib/{platform_name}
default_tplg_path: intel/avs-tplg
default_fw_filename: dsp_basefw.bin
The SOF supports building the firmware for cAVS2.5 platforms using IPC4 and
it is the preferred IPC4 implementation to be used on these devices.
Change the paths and firmware names to reflect this:
default_fw_path: intel/sof-ipc4/{platform_name}
default_lib_path: intel/sof-ipc4-lib/{platform_name}
default_tplg_path: intel/sof-ipc4-tplg
default_fw_filename: sof-{platform_name}.ri
Signed-off-by: Peter Ujfalusi <[email protected]>
Reviewed-by: Bard Liao <[email protected]>
Reviewed-by: Kai Vehmanen <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
We describe tplg_file_name and drv_name using snd_sof_of_mach
array and select correct machine description based on dts compatible
string.
Signed-off-by: Daniel Baluta <[email protected]>
Reviewed-by: Iuliana Prodan <[email protected]>
Reviewed-by: Laurentiu Mihalcea <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Ranjani Sridharan <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
A recent change in acp_irq_thread() was meant to address a potential race
condition while trying to acquire the hardware semaphore responsible for
the synchronization between firmware and host IPC interrupts.
This resulted in an improper use of the IPC spinlock, causing normal
kernel memory allocations (which may sleep) inside atomic contexts:
1707255557.133976 kernel: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:315
...
1707255557.134757 kernel: sof_ipc3_rx_msg+0x70/0x130 [snd_sof]
1707255557.134793 kernel: acp_sof_ipc_irq_thread+0x1e0/0x550 [snd_sof_amd_acp]
1707255557.134855 kernel: acp_irq_thread+0xa3/0x130 [snd_sof_amd_acp]
1707255557.134904 kernel: ? irq_thread+0xb5/0x1e0
1707255557.134947 kernel: ? __pfx_irq_thread_fn+0x10/0x10
1707255557.134985 kernel: irq_thread_fn+0x23/0x60
Moreover, there are attempts to lock a mutex from the same atomic
context:
1707255557.136357 kernel: =============================
1707255557.136393 kernel: [ BUG: Invalid wait context ]
1707255557.136413 kernel: 6.8.0-rc3-next-20240206-audio-next #9 Tainted: G W
1707255557.136432 kernel: -----------------------------
1707255557.136451 kernel: irq/66-AudioDSP/502 is trying to lock:
1707255557.136470 kernel: ffff965152f26af8 (&sb->s_type->i_mutex_key#2){+.+.}-{3:3}, at: start_creating.part.0+0x5f/0x180
...
1707255557.137429 kernel: start_creating.part.0+0x5f/0x180
1707255557.137457 kernel: __debugfs_create_file+0x61/0x210
1707255557.137475 kernel: snd_sof_debugfs_io_item+0x75/0xc0 [snd_sof]
1707255557.137494 kernel: sof_ipc3_do_rx_work+0x7cf/0x9f0 [snd_sof]
1707255557.137513 kernel: sof_ipc3_rx_msg+0xb3/0x130 [snd_sof]
1707255557.137532 kernel: acp_sof_ipc_irq_thread+0x1e0/0x550 [snd_sof_amd_acp]
1707255557.137551 kernel: acp_irq_thread+0xa3/0x130 [snd_sof_amd_acp]
Fix the issues by reducing the lock scope in acp_irq_thread(), so that
it guards only the hardware semaphore acquiring attempt. Additionally,
restore the initial locking in acp_sof_ipc_irq_thread() to synchronize
the handling of immediate replies from DSP core.
Fixes: 802134c8c2c8 ("ASoC: SOF: amd: Refactor spinlock_irq(&sdev->ipc_lock) sequence in irq_handler")
Signed-off-by: Cristian Ciocaltea <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
With the change in the widget free logic to power down the cores only
when the scheduler widgets are freed, we need to ensure that the
scheduler widget is freed only after all the widgets associated with the
scheduler are freed. This is to ensure that the secondary core that the
scheduler is scheduled to run on is kept powered on until all widgets
that need them are in use. While this works well for dynamic pipelines,
in the case of static pipelines the current logic does not take this into
account and frees all widgets in the order they occur in the
widget_list. So, modify this to ensure that the scheduler widgets are freed
only after all other types of widgets in the widget_list are freed.
Link: https://github.com/thesofproject/linux/issues/4807
Fixes: 31ed8da1c8e5 ("ASoC: SOF: sof-audio: Modify logic for enabling/disabling topology cores")
Signed-off-by: Ranjani Sridharan <[email protected]>
Reviewed-by: Pierre-Louis Bossart <[email protected]>
Reviewed-by: Péter Ujfalusi <[email protected]>
Signed-off-by: Peter Ujfalusi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Merge series from Vijendar Mukunda <[email protected]>:
This patch series is to redesign existing platform device creation logic
for SoundWire managers and Implement generic functions for SoundWire
manager probe, start and exit sequence which are common for both Legacy
(NO DSP enabled) and SOF stack, and add SoundWire Interface support for
AMD SOF stack (ACP 6.3 based platform).
The patch series was reviewed in
https://github.com/thesofproject/linux/pull/4699
|
|
Refactor acp driver pm ops to support SoundWire interface.
When SoundWire configuration is enabled, In case of ClockStopMode,
DSP soft reset should be applied and for rest of the scenarios
acp init/deinit sequence should be invoked.
Signed-off-by: Vijendar Mukunda <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Select SoundWire dependency flag for acp6.3 based platform for SoundWire
configuration.
Signed-off-by: Vijendar Mukunda <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Update acp descriptor fields for acp6.3 version based platform.
Signed-off-by: Vijendar Mukunda <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Add machine select logic for soundwire endpoints for AMD platforms.
Signed-off-by: Vijendar Mukunda <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Add support for configuring AMD Soundwire DAI from topology.
Signed-off-by: Vijendar Mukunda <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Add support for interrupt handling for soundwire manager platform
devices.
Signed-off-by: Vijendar Mukunda <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Add code for invoking Soundwire manager helper functions
when SoundWire configuration is selected.
Signed-off-by: Vijendar Mukunda <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Commit 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version fallback if
firmware files are missing") changed the order of some operations and
the firmware paths are not available anymore at snd_sof_probe() time.
Precisely, fw_filename_prefix is set by sof_select_ipc_and_paths() via
plat_data->fw_filename_prefix = out_profile.fw_path;
but sof_init_environment() which calls this function was moved from
snd_sof_device_probe() to sof_probe_continue(). Moreover,
snd_sof_probe() was moved from sof_probe_continue() to
sof_init_environment(), but before the call to
sof_select_ipc_and_paths().
The problem here is that amd_sof_acp_probe() uses fw_filename_prefix to
compute fw_code_bin and fw_data_bin paths, and because the field is not
yet initialized, the paths end up containing (null):
snd_sof_amd_vangogh 0000:04:00.5: Direct firmware load for (null)/sof-vangogh-code.bin failed with error -2
snd_sof_amd_vangogh 0000:04:00.5: sof signed firmware code bin is missing
snd_sof_amd_vangogh 0000:04:00.5: error: failed to load DSP firmware -2
snd_sof_amd_vangogh: probe of 0000:04:00.5 failed with error -2
Move usage of fw_filename_prefix right before request_firmware() calls
in acp_sof_load_signed_firmware().
Fixes: 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version fallback if firmware files are missing")
Signed-off-by: Cristian Ciocaltea <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
The ACP driver for Vangogh platform uses a quirk for Valve Galileo
device to setup a custom firmware loader, which neither requires nor
uses the firmware file indicated via the default_fw_filename member of
struct sof_dev_desc.
Since commit 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version
fallback if firmware files are missing"), the provided filename gets
verified and triggers a fatal error on probe:
[ 7.719337] snd_sof_amd_vangogh 0000:04:00.5: enabling device (0000 -> 0002)
[ 7.721486] snd_sof_amd_vangogh 0000:04:00.5: SOF firmware and/or topology file not found.
[ 7.721565] snd_sof_amd_vangogh 0000:04:00.5: Supported default profiles
[ 7.721569] snd_sof_amd_vangogh 0000:04:00.5: - ipc type 0 (Requested):
[ 7.721573] snd_sof_amd_vangogh 0000:04:00.5: Firmware file: amd/sof/sof-vangogh.ri
[ 7.721577] snd_sof_amd_vangogh 0000:04:00.5: Topology file: amd/sof-tplg/sof-vangogh-nau8821-max.tplg
[ 7.721582] snd_sof_amd_vangogh 0000:04:00.5: Check if you have 'sof-firmware' package installed.
[ 7.721585] snd_sof_amd_vangogh 0000:04:00.5: Optionally it can be manually downloaded from:
[ 7.721589] snd_sof_amd_vangogh 0000:04:00.5: https://github.com/thesofproject/sof-bin/
[ 7.721997] snd_sof_amd_vangogh: probe of 0000:04:00.5 failed with error -2
According to AMD, a combined ".ri" file which includes the code and data
segments cannot be used due to a limitation preventing the code image to
be signed on build time.
Fix the issue by skipping the firmware file test if a custom loader is
being used instead of the generic one.
Fixes: 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version fallback if firmware files are missing")
Co-developed-by: Péter Ujfalusi <[email protected]>
Signed-off-by: Péter Ujfalusi <[email protected]>
Signed-off-by: Cristian Ciocaltea <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|
|
Valve's Steam Deck OLED is uniquely identified by vendor and product
name (Galileo) DMI fields.
Simplify the quirk by removing the unnecessary match on product family.
Additionally, fix the related comment as it points to the old product
variant.
Signed-off-by: Cristian Ciocaltea <[email protected]>
Reviewed-by: Emil Velikov <[email protected]>
Link: https://msgid.link/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>
|