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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
As the runtime PM issue was addressed by the recent fix 4961167bf748
("ALSA: hda/via: Apply the workaround generically for Clevo machines")
for VIA codecs, we need no longer to keep the Clevo device off from
the power saving as default. Drop the deny list entry accordingly.
Depends: 4961167bf748 ("ALSA: hda/via: Apply the workaround generically for Clevo machines")
Link: https://lore.kernel.org/r/20210202092744.20321-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
As with most Pioneer devices, the device descriptor is vendor specific
and as such, the number of channels, the PCM format, endpoints and
sample rate need to be specified. This device has 8 inputs and 8 outputs
and a sample rate of 48000 only. The PCM format is S24_3LE like other
devices.
There seems to be an appetite for reducing duplication amongs these
Pioneer patches but again, I feel this is a step to be taken after
support has been added as it's not completely clear where the
commonalities are.
Signed-off-by: Olivia Mackintosh <livvy@base.nu>
Link: https://lore.kernel.org/r/20210202134225.3217-3-livvy@base.nu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Like the DJM-750, ensure that the format control message is passed to
the device when opening a stream. It seems as though fmt->sync_ep is not
always set when this function is called hence the passing of the value
at the call site. If this can be fixed, fmt->sync_up should be used as
the wvalue.
There doesn't seem to be a "cpu_to_le24" type function defined hence for
the open code but I did see a similar thing done in Bluez lib. Perhaps
we can get these definitions defined in byteorder.h. See hci_cpu_to_le24
in include/net/bluetooth/hci.h:2543 for similar usage.
Signed-off-by: Olivia Mackintosh <livvy@base.nu>
Link: https://lore.kernel.org/r/20210202134225.3217-2-livvy@base.nu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Had a typo in lpass platform driver that resulted in crash
during suspend/resume with an HDMI dongle connected.
The regmap read/write/volatile regesters validation callbacks in lpass-cpu
were using MI2S rdma_channels count instead of hdmi_rdma_channels.
This typo error causing to read registers from the regmap beyond the length
of the mapping created by ioremap().
This fix avoids the need for reducing number hdmi_rdma_channels,
which is done in
commit 7dfe20ee92f6 ("ASoC: qcom: Fix number of HDMI RDMA channels on sc7180").
So reverting the same.
Fixes: 7cb37b7bd0d3c ("ASoC: qcom: Add support for lpass hdmi driver")
Signed-off-by: Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
Link: https://lore.kernel.org/r/20210202062727.22469-1-srivasam@codeaurora.org
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Tested-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
When creating topology templates and overriding data in specific test
cases it should be done with cpu_to_le32 macro, so we operate on correct
data on all architectures, as topology parser use le32_to_cpu to parse
data from structures.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
Link: https://lore.kernel.org/r/20210202163123.3942040-1-amadeuszx.slawinski@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
DT properties "dmic-mode" and "mic-type-X" are optional. Reduces the
log verbosity and changes the message a bit to avoid misleading.
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20210202033557.1621029-1-tzungbi@google.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Fixup BE DAI links channel count to match topology settings. Normally the
channel count of BE is equal to FE's so we don't have any issue. For some
cases like DSM with 2-channel FE and 4-channel BE the mismatch of BE and
topology will result in audio issues.
Signed-off-by: Rander Wang <rander.wang@intel.com>
Reviewed-by: Keyon Jie <yang.jie@intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210201092345.1214232-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
All amba drivers return 0 in their remove callback. Together with the
driver core ignoring the return value anyhow, it doesn't make sense to
return a value here.
Change the remove prototype to return void, which makes it explicit that
returning an error value doesn't work as expected. This simplifies changing
the core remove callback to return void, too.
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org> # for drivers/memory
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> # for hwtracing/coresight
Acked-By: Vinod Koul <vkoul@kernel.org> # for dmaengine
Acked-by: Guenter Roeck <linux@roeck-us.net> # for watchdog
Acked-by: Wolfram Sang <wsa@kernel.org> # for I2C
Acked-by: Takashi Iwai <tiwai@suse.de> # for sound
Acked-by: Vladimir Zapolskiy <vz@mleia.com> # for memory/pl172
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20210126165835.687514-5-u.kleine-koenig@pengutronix.de
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
This change adds audio jack injection feature through debugfs, with
this feature, we could validate alsa userspace changes by injecting
plugin or plugout events to the non-phantom audio jacks.
With this change, the sound core will build the folders
$debugfs_mount_dir/sound/cardN if SND_DEBUG and DEBUG_FS are enabled.
And if users also enable the SND_JACK_INJECTION_DEBUG, the jack
injection nodes will be built in the folder cardN like below:
$tree $debugfs_mount_dir/sound
$debugfs_mount_dir/sound
├── card0
│ ├── HDMI_DP_pcm_10_Jack
│ │ ├── jackin_inject
│ │ ├── kctl_id
│ │ ├── mask_bits
│ │ ├── status
│ │ ├── sw_inject_enable
│ │ └── type
...
│ └── HDMI_DP_pcm_9_Jack
│ ├── jackin_inject
│ ├── kctl_id
│ ├── mask_bits
│ ├── status
│ ├── sw_inject_enable
│ └── type
└── card1
├── HDMI_DP_pcm_5_Jack
│ ├── jackin_inject
│ ├── kctl_id
│ ├── mask_bits
│ ├── status
│ ├── sw_inject_enable
│ └── type
...
├── Headphone_Jack
│ ├── jackin_inject
│ ├── kctl_id
│ ├── mask_bits
│ ├── status
│ ├── sw_inject_enable
│ └── type
└── Headset_Mic_Jack
├── jackin_inject
├── kctl_id
├── mask_bits
├── status
├── sw_inject_enable
└── type
The nodes kctl_id, mask_bits, status and type are read-only, users
could check jack or jack_kctl's information through them.
The nodes sw_inject_enable and jackin_inject are directly used for
injection. The sw_inject_enable is read-write, users could check if
software injection is enabled or not on this jack, and users could
echo 1 or 0 to enable or disable software injection on this jack. Once
the injection is enabled, the jack will not change by hardware events
anymore, once the injection is disabled, the jack will restore the
last reported hardware events to the jack. The jackin_inject is
write-only, if the injection is enabled, users could echo 1 or 0 to
this node to inject plugin or plugout events to this jack.
For the detailed usage information on these nodes, please refer to
Documentation/sound/designs/jack-injection.rst.
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Link: https://lore.kernel.org/r/20210127085639.74954-2-hui.wang@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Output loopback is a feature where you can record what you hear.
The HDSP series of the RME interfaces provides this functionality
at the hardware level and this patch exposes controls to enable or
disable it per output (playback) channel.
This probably works on other cards but due to a lack of hardware
it is only tested and enabled for the HDSP9632 card with this patch.
Should this patch be accepted a separate patch will be posted to
https://github.com/alsa-project/alsa-tools/tree/master/hdspmixer
which adds "LPBK" buttons to each output in the playback strip for
the user to be able to control this feature from the user land.
Users from Windows tool TotalMixFX should be familiar with this.
Signed-off-by: Jasmin Fazlic <superfassl@gmail.com>
Link: https://lore.kernel.org/r/95cb3117-e85a-51a6-c2ce-bf736e70fc4c@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The correct mask is 0x1f8 (Bit 3-8), but due to missing BIT() 0xf (Bit
0-3) was set instead. This means setting of CPCAP_BIT_MIC1_RX_TIMESLOT0
(Bit 3) still worked (part of both masks). On the other hand the code
does not properly clear the other MIC timeslot bits. I think this
is not a problem, since they are probably initialized to 0 and not
touched by the driver anywhere else. But the mask also contains some
wrong bits, that will be cleared. Bit 0 (CPCAP_BIT_SMB_CDC) should be
safe, since the driver enforces it to be 0 anyways.
Bit 1-2 are CPCAP_BIT_FS_INV and CPCAP_BIT_CLK_INV. This means enabling
audio recording forces the codec into SND_SOC_DAIFMT_NB_NF mode, which
is obviously bad.
The bug probably remained undetected, because there are not many use
cases for routing microphone to the CPU on platforms using cpcap and
user base is small. I do remember having some issues with bad sound
quality when testing voice recording back when I wrote the driver.
It probably was this bug.
Fixes: f6cdf2d3445d ("ASoC: cpcap: new codec")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20210123172945.3958622-1-sre@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Audio Graph Card based Tegra driver is only useful on NVIDIA Tegra SoCs.
Hence add a dependency on SND_SOC_TEGRA, to prevent asking the user
about this driver when configuring a kernel without Tegra sound support.
Wrap all Tegra sound config options inside a big if/endif block, instead
of just adding the dependency to the single config option that does not
have it yet, to preventing similar future mistakes.
Fixes: 202e2f7745437aa5 ("ASoC: tegra: Add audio graph based card driver")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/20210129125915.2652952-1-geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
When there is no TLV data in topology, extracting the TLV data
could result in a NULL pointer exception. Prevent this by making
sure that the TLV data exists before extracting it.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Reviewed-by: Paul Olaru <paul.olaru@oss.nxp.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210201093128.1226603-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
When device_type == DEVICE_ALI, we should also check the return
value of pci_iomap() to avoid potential null pointer dereference.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
Link: https://lore.kernel.org/r/20210131100916.7915-1-dinghao.liu@zju.edu.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The only usage of hdac_dev_attr_group is to put its address in an array
of pointers to const attribute_group structs. Make it const to allow the
compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20210131001241.2278-3-rikard.falkeborn@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The only usage of ac97_adapter_attr_group is to put its address in an
array of pointers to const attribute_group structs. Make it const to
allow the compiler to put it in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Link: https://lore.kernel.org/r/20210131001241.2278-2-rikard.falkeborn@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
microblaze-linux-gcc (GCC) 9.3.0 complains about missing __ffssi2
symbol while using __builtin_ffs at runtime.
This is because arch/h8300 is compiled with -fno-builtin option.
so fallback and use kernel ffs() instead to all the arch builds happy!
Fixes: 1da0b9899abd ("ASoC: soc-component: add snd_soc_component_read/write_field()")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20210129100539.23459-1-srinivas.kandagatla@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Series to refactor the DSP core management:
- move tracking of powered up DSP cores to common SOF code
- add logic filter unnecessary power actions
- modify existing implementations to use common code
whenever DSP cores are powered, so the state in common
code stays in sync
Bard Liao (5):
ASoC: SOF: Intel: hda: use snd_sof_dsp_core_power_up/down API
ASoC: SOF: Intel: hda-loader: keep init cores alive
ASoC: SOF: update dsp core power status in common APIs
ASoC: SOF: Filter out unneeded core power up/downs
ASoC: SOF: intel: hda-loader: use snd_sof_dsp_core_power_down/up APIs
sound/soc/sof/intel/hda-dsp.c | 2 +-
sound/soc/sof/intel/hda-loader.c | 9 +++++----
sound/soc/sof/intel/hda.c | 2 +-
sound/soc/sof/loader.c | 6 ------
sound/soc/sof/ops.h | 24 ++++++++++++++++++------
sound/soc/sof/pm.c | 1 -
sound/soc/sof/topology.c | 8 --------
7 files changed, 25 insertions(+), 27 deletions(-)
base-commit: e32df142359fb6f4d27977b7652549f0844aa62f
--
2.29.2
The snd-soc-acpi-intel-match has duplicate module tags for all
platforms separately. Remove all but one and save some storage
space and cleanup modinfo output.
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210128105751.1049837-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
To manage enabled_cores_mask flag, we should always use snd_sof_dsp_
core_power_down/up APIs to power up/down dsp cores. The APIs do
a little bit more than the original functions, but it is harmless.
Suggested-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210128093850.1041387-6-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Exclude cores that are already powered on/off correctly. This allows to
simplify dsp_power_up/down() implementations and avoid unexpected error.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210128093850.1041387-5-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Only manage enabled_cores_mask in common snd_sof_dsp_core_power_up/down
APIs to ensure it stays in sync with actual DSP core state.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210128093850.1041387-4-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
init_core_mask should be the available cores mask after fw boot. So we
should keep not core 0 but init cores alive.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210128093850.1041387-3-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
To implement common logic in SOF core, core power up/down flows should
use common SOF API and not directly use low-level platform specific
helper functions.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210128093850.1041387-2-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Cancel the D0i3 work during runtime suspend as no streams are
active at this point anyway.
Fixes: 63e51fd33fef ("ASoC: SOF: Intel: cnl: Implement feature to support DSP D0i3 in S0")
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210128092345.1033085-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
No need of BCLK state maintenance from driver side as
clock_enable and clk_disable API's maintaing state counter.
One of the major issue was spotted when Headset jack inserted
while playback continues, due to same PCM device node opens twice
for playaback/capture and closes once for capture and playback continues.
It can resolve the errors in such scenarios.
Fixes: b1824968221c ("ASoC: qcom: Fix enabling BCLK and LRCLK in LPAIF invalid state")
Signed-off-by: Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20210127151824.8929-1-srivasam@codeaurora.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The double negative makes it hard to read "if (!ACPI_FAILURE(status))".
Replace it with "if (ACPI_SUCCESS(status))".
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ADL will use sof-adl-s.ri if it is ADL-S platform. So let's use
the default_fw_filename in pdata->desc for the ADL FW filename.
Signed-off-by: Libin Yang <libin.yang@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20210125070500.807474-3-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The snd_soc_put_volsw in max98373_feedback_get is a typo, change it
to snd_soc_get_volsw.
Fixes: 349dd23931d1 ("ASoC: max98373: don't access volatile registers in bias level off")
Signed-off-by: Judy Hsiao <judyhsiao@google.com>
Link: https://lore.kernel.org/r/20210127135620.1143942-1-judyhsiao@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
It's often the case that we would write or read a particular field
in register. With the current soc_component apis, reading a particular
field in register would involve first read the register and then
perform shift operations.
Ex:
to read from a field mask of 0xf0
val = snd_soc_component_read(component, reg);
field = ((val & 0xf0) >> 0x4);
This is sometimes prone to errors and code become less readable!
With this new api we could just do
field = snd_soc_component_read_field(component, reg, 0xf0);
this makes it bit simple, easy to write and less error prone!
This also applies to writing!
There are various places in kernel which provides such field interfaces
however soc_component seems to be missing this.
This patch is inspired by FIELD_GET/FIELD_PREP macros in include/linux/bitfield.h
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20210126171749.1863-1-srinivas.kandagatla@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Enabling DMI L1 for capture streams could result in xruns during
pause/release. As pause/release is not a valid scenario for trace,
we can safely enable DMI L1 for it.
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20210127020737.1088960-3-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
DMI L1 entry is currently disabled whenever any capture stream is
opened to prevent xruns during pause/release. But, in
order to maximise power savings for the wake-on-voice usecase,
DMI L1 entry should be enabled for D0i3-compatible capture streams.
Introduce a new field, flags in struct sof_intel_hda_stream
that stores whether a stream is dmi_l1_compatible. All playback streams,
and D0i3-compatible capture streams are DMI L1 compatible.
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Link: https://lore.kernel.org/r/20210127020737.1088960-2-ranjani.sridharan@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The SOF firmware and topology files are not distributed via
linux-firmware. To help debugging cases where correct firmware is
not installed, print a pointer to the official upstream repository
for Sound Open Firmware releases.
BugLink: https://github.com/thesofproject/sof/issues/3665
Reported-by: Bruce Perens <bruce@perens.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Marc Herbert <marc.herbert@intel.com>
Reviewed-by: Liam Girdwood <liam.r.girdwood@intel.com>
Link: https://lore.kernel.org/r/20210127122358.1014458-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
tgl_3_in_1_default link topology may be used by both TGL-LP and TGL-H.
Let's remove the sof_fw_filename setting in struct snd_soc_acpi_mach
and use the default_fw_filename setting in struct sof_dev_desc.
Signed-off-by: Libin Yang <libin.yang@intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Tested-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210125070500.807474-2-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The old code always uses sof_fw_filename in struct snd_soc_acpi_mach
as the firmware name. However, firmware name should depend on the platform
instead of the machine. For example, different machines may use the same
soundwire link topology, but they are using the different firmware. In this
case, it's hard to determine in struct snd_soc_acpi_mach which firmware it
should use.
Signed-off-by: Libin Yang <libin.yang@intel.com>
Reviewed-by: Bard Liao <bard.liao@intel.com>
Reviewed-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Tested-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20210125070500.807474-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
A const prefix was put wrongly in the middle at the code refactoring
commit 932eaf7c7904 ("ASoC: sh: siu_pcm: remove snd_pcm_ops"), which
leads to a build error as:
sound/soc/sh/siu_pcm.c:546:8: error: expected '{' before 'const'
Also, another inconsistency is that the declaration of siu_component
misses the const prefix.
This patch corrects both failures.
Fixes: 932eaf7c7904 ("ASoC: sh: siu_pcm: remove snd_pcm_ops")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20210126154702.3974-1-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
More fixes for v5.11, almost all driver specific issues including new
device IDs - there's one error handling fix for the topology stuff too.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmAQCxMACgkQJNaLcl1U
h9CmOwf8DWMyWBjrGyWQj6x428W+3abz/rIdyjA09H6cZoriZ9nLqerDQLmFrh/u
jFvCSdla0FDE8uw33nWp9KC5KBH99JdKE9uGTMhwn/kQuOackrw6tRw7SUOwykGr
MfT7Dlge8P3lwjV7/s/VrXpy0I/RTUbw1fELMn8ArqcQxO5qV32JFOWOAYIcwH+l
vAPFP8ZR/aJJ42nT5TZdQTc2gEchE2KJGhmgWNu6hWLHxznW36lYIf+76DWoEcI7
pdD8MmRVyutsauaOdJj3y7LJrmUyE/f6vS9opSfiskKAvd8fq5TMP+wzMvYVwpsP
5MJVW1uVIOYzsb1DRMridM43SRon+g==
=L8rT
-----END PGP SIGNATURE-----
Merge tag 'asoc-fix-v5.11-rc5' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v5.11
More fixes for v5.11, almost all driver specific issues including new
device IDs - there's one error handling fix for the topology stuff too.
The driver core ignores the return value of the remove callback, so
don't give isa drivers the chance to provide a value.
Adapt all isa_drivers with a remove callbacks accordingly; they all
return 0 unconditionally anyhow.
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> # for drivers/net/can/sja1000/tscan1.c
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Acked-by: Wolfram Sang <wsa@kernel.org> # for drivers/i2c/
Reviewed-by: Takashi Iway <tiwai@suse.de> # for sound/
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> # for drivers/media/
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Link: https://lore.kernel.org/r/20210122092449.426097-4-uwe@kleine-koenig.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The "chip" can't be NULL in hda_tegra_runtime_resume() because code would
crash otherwise. Let's remove the unnecessary check in order to clean up
code a tad.
Tested-by: Peter Geis <pgwipeout@gmail.com> # Ouya T30 audio works
Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30 boot-tested
Suggested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20210120003154.26749-4-digetx@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
