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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The code inherited from the Skylake driver does not seem to follow any
known hardware recommendations.
The only two recommended options are
a) use DPIB registers if VC1 traffic is not allowed
b) use DPIB DDR update if VC1 traffic is used
In all of SOF-based updated, VC1 is not supported so we can 'safely'
move to using DPIB registers only.
This patch keeps the legacy code, in case there was an undocumented
issue lost to history, and adds the DPIB DDR update for additional
debug.
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>
Link: https://lore.kernel.org/r/20211207193947.71080-6-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Smatch complains that we might hit the continue path on every iteration
through the loop.
sound/soc/mediatek/mt8195/mt8195-mt6359-rt1019-rt5682.c:831
mt8195_mt6359_rt1019_rt5682_card_late_probe()
error: uninitialized symbol 'sof_comp'.
Initialize "sof_comp" to NULL to silence this warning.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211208151145.GA29257@kili
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Ariel D'Alessandro <ariel.dalessandro@collabora.com>:
This is a follow up of patchsets:
[RFC patch 0/5] Support BCLK input clock in tlv320aic31xx
[PATCH 0/4] fsl-asoc-card: Add optional dt property for setting mclk-id
Patch "ASoC: fsl-asoc-card: Support fsl,imx-audio-tlv320aic31xx codec"
in "[RFC patch 0/5] Support BCLK input clock in tlv320aic31xx" missed a
Kconfig option. Sending incremental patch fix.
Regards,
Ariel
Ariel D'Alessandro (1):
ASoC: fsl-asoc-card: Add missing Kconfig option for tlv320aic31xx
sound/soc/fsl/Kconfig | 1 +
1 file changed, 1 insertion(+)
--
2.30.2
Merge series from Trevor Wu <trevor.wu@mediatek.com>:
This series of patches adds support for memory-region assignment, so the
access region of DMA engine could be restricted.
Patches are based on broonie tree "for-next" branch.
Trevor Wu (2):
ASoC: mediatek: mt8195: support reserved memory assignment
dt-bindings: mediatek: mt8195: add memory-region property
.../devicetree/bindings/sound/mt8195-afe-pcm.yaml | 8 ++++++++
sound/soc/mediatek/mt8195/mt8195-afe-pcm.c | 7 +++++++
2 files changed, 15 insertions(+)
--
2.18.0
Merge series from Trevor Wu <trevor.wu@mediatek.com>:
This series of patches adds support for RT5682s headset codec in mt8195
machine drivers, and SOF support on card mt8195-mt6359-rt1019-rt5682 is
also included.
Patches are based on broonie tree "for-next" branch.
Changes since v1:
- remove patch3 and patch4 in v1
- add SOF support on card mt8195-mt6359-rt1012-rt5682
- add new propertes to dt-bindings for mt8195-mt6359-rt1019-rt5682
Trevor Wu (4):
ASoC: mediatek: mt8195: add headset codec rt5682s support
dt-bindings: mediatek: mt8195: add model property
ASoC: mediatek: mt8195: add sof support on mt8195-mt6359-rt1019-rt5682
dt-bindings: mediatek: mt8195: add adsp and dai-link property
.../sound/mt8195-mt6359-rt1011-rt5682.yaml | 4 +
.../sound/mt8195-mt6359-rt1019-rt5682.yaml | 14 +
sound/soc/mediatek/Kconfig | 2 +
.../mt8195/mt8195-mt6359-rt1011-rt5682.c | 29 +-
.../mt8195/mt8195-mt6359-rt1019-rt5682.c | 347 +++++++++++++++++-
5 files changed, 370 insertions(+), 26 deletions(-)
--
2.18.0
In the patch, widgets, routes and dai-link requrird by SOF are included,
and late_probe is introduced for SOF route connection.
Only when adsp phandle could be retrieved from DTS, the SOF related part
of machine driver is executed.
Additionally, supported dai-links could be specified from DTS, so that
we can disable AP side hardware controls when DSP SOF controls the same
audio FE.
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
Signed-off-by: YC Hung <yc.hung@mediatek.com>
Link: https://lore.kernel.org/r/20211129141057.12422-4-trevor.wu@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The MVC module has a per channel control bit, based on which it decides
to apply channel specific volume/mute settings. When per channel control
bit is enabled (which is the default HW configuration), all MVC channel
volume/mute can be independently controlled. If the control is disabled,
channel-0 volume/mute setting is applied by HW to all remaining channels.
Thus add support to leverage this HW feature by exposing master controls
for volume/mute.
With this, now there are per channel and master volume/mute controls.
Users need to just use controls which are suitable for their applications.
The per channel control enable/disable is mananged in driver and hidden
from users, so that they need to just worry about respective volume/mute
controls.
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1638278605-28225-1-git-send-email-spujar@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On my T14s Gen2 I saw the following:
[ 16.057258] skl_hda_dsp_generic skl_hda_dsp_generic: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 3
[ 16.057261] skl_hda_dsp_generic skl_hda_dsp_generic: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 4
[ 16.057263] skl_hda_dsp_generic skl_hda_dsp_generic: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 5
[...and so on.]
It looks like the double newline is a mistake, so remove one.
Signed-off-by: Chris Down <chris@chrisdown.name>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/YaOS0sBueAfApwOx@chrisdown.name
Signed-off-by: Mark Brown <broonie@kernel.org>
On the latest Lenovo Thinkstation laptops, we often experience the
speaker failure after rebooting, check the dmesg, we could see:
sof-audio-pci-intel-tgl 0000:00:1f.3: codec #0 probe error, ret: -5
The analogue codec on the machine is ALC287, then we designed a
testcase to reboot and check the codec probing result repeatedly, we
found the analogue codec probing always failed at least once within
several minutes to several hours (roughly 1 reboot per min). This
issue happens on all laptops of this Thinkstation model, but with
legacy HDA driver, we couldn't reproduce this issue on those laptops.
And so far, this issue is not reproduced on machines which don't
belong to this model.
We tried to make the hda_dsp_ctrl_init_chip() same as
hda_intel_init_chip() which is the controller init routine in the
legacy HDA driver, but it didn't help.
We found when issue happens, the resp is -1, and if we let driver
re-run send_cmd() and get_response(), it will get the correct response
10ec0287, then driver continues the rest work, finally boot to the
desktop and all audio function work well.
Here adding codec probing retries to 3 times, it could fix the issue
on this Thinkstation model, and it doesn't bring impact to other
machines.
Reviewed-by: Bard Liao <bard.liao@intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Link: https://lore.kernel.org/r/20211130090606.529348-1-kai.vehmanen@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Previously, the DAI template was used directly, which lead to
fun bugs such as "why is my channels_max changing?" when one
instantiated more than one i2s_tdm IP block in a device tree.
This change makes it so that we instead duplicate the template
struct, and then use that.
Fixes: 081068fd64 ("ASoC: rockchip: add support for i2s-tdm controller")
Signed-off-by: Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
Link: https://lore.kernel.org/r/20211125084900.417102-1-frattaroli.nicolas@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>:
Current soc_pcm_pointer() is checking runtime->delay,
but it might be updated silently by component's .point callback.
It is strange and difficult to find/know the issue. This patch
adds .delay callback for component, and solve the issue.
