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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Commit 08df0d9a00f7 ("ASoC: max98090: revert "ASoC: max98090: fix lockdep
warning"") provided a good rationale for removing separate lock for the
SHDN register access. However it restored the lockdep warning during the
system boot. To silence the lockdep warning, mark the mutex taken in the
max98090_shdn_save() function with the lockdep class dedicated for the
runtime DAPM operations: SND_SOC_DAPM_CLASS_RUNTIME. This finally fixes
the following lockdep warning observed on Exynos4412-based Odroid U3
board:
======================================================
WARNING: possible circular locking dependency detected
5.5.0-rc7-next-20200123 #7329 Not tainted
------------------------------------------------------
alsactl/1105 is trying to acquire lock:
ed4f7cf4 (&card->dapm_mutex){+.+.}, at: max98090_shdn_save+0x1c/0x28
but task is already holding lock:
edb8d49c (&card->controls_rwsem){++++}, at: snd_ctl_ioctl+0xcc/0xbb8
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&card->controls_rwsem){++++}:
snd_ctl_add_replace+0x3c/0x84
dapm_create_or_share_kcontrol+0x24c/0x2e0
snd_soc_dapm_new_widgets+0x308/0x594
snd_soc_bind_card+0x834/0xa94
devm_snd_soc_register_card+0x34/0x6c
odroid_audio_probe+0x288/0x34c
platform_drv_probe+0x6c/0xa4
really_probe+0x200/0x48c
driver_probe_device+0x78/0x1f8
bus_for_each_drv+0x74/0xb8
__device_attach+0xd4/0x16c
bus_probe_device+0x88/0x90
deferred_probe_work_func+0x3c/0xd0
process_one_work+0x230/0x7bc
worker_thread+0x44/0x524
kthread+0x130/0x164
ret_from_fork+0x14/0x20
0x0
-> #0 (&card->dapm_mutex){+.+.}:
lock_acquire+0xe8/0x270
__mutex_lock+0x9c/0xb18
mutex_lock_nested+0x1c/0x24
max98090_shdn_save+0x1c/0x28
max98090_put_enum_double+0x20/0x40
snd_ctl_ioctl+0x190/0xbb8
ksys_ioctl+0x484/0xb10
ret_fast_syscall+0x0/0x28
0xbede0564
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&card->controls_rwsem);
lock(&card->dapm_mutex);
lock(&card->controls_rwsem);
lock(&card->dapm_mutex);
*** DEADLOCK ***
1 lock held by alsactl/1105:
#0: edb8d49c (&card->controls_rwsem){++++}, at: snd_ctl_ioctl+0xcc/0xbb8
stack backtrace:
CPU: 2 PID: 1105 Comm: alsactl Not tainted 5.5.0-rc7-next-20200123 #7329
Hardware name: Samsung Exynos (Flattened Device Tree)
[<c01126f0>] (unwind_backtrace) from [<c010e1e8>] (show_stack+0x10/0x14)
[<c010e1e8>] (show_stack) from [<c0b5234c>] (dump_stack+0xb4/0xe0)
[<c0b5234c>] (dump_stack) from [<c018a610>] (check_noncircular+0x1ec/0x208)
[<c018a610>] (check_noncircular) from [<c018ca2c>] (__lock_acquire+0x1210/0x25ec)
[<c018ca2c>] (__lock_acquire) from [<c018e728>] (lock_acquire+0xe8/0x270)
[<c018e728>] (lock_acquire) from [<c0b71928>] (__mutex_lock+0x9c/0xb18)
[<c0b71928>] (__mutex_lock) from [<c0b723c0>] (mutex_lock_nested+0x1c/0x24)
[<c0b723c0>] (mutex_lock_nested) from [<c086097c>] (max98090_shdn_save+0x1c/0x28)
[<c086097c>] (max98090_shdn_save) from [<c08613f8>] (max98090_put_enum_double+0x20/0x40)
[<c08613f8>] (max98090_put_enum_double) from [<c0833f20>] (snd_ctl_ioctl+0x190/0xbb8)
[<c0833f20>] (snd_ctl_ioctl) from [<c02cae14>] (ksys_ioctl+0x484/0xb10)
[<c02cae14>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
Exception stack(0xed331fa8 to 0xed331ff0)
...
Fixes: 08df0d9a00f7 ("ASoC: max98090: revert "ASoC: max98090: fix lockdep warning"")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200123134046.9769-1-m.szyprowski@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
All rtd->dai_link callback functions are controlled by soc_rtd_xxxx(),
and checking rtd->dai_link->ops.
We don't need to have null_snd_soc_ops anymore.
This patch removes it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87zhegl3oz.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add soc_rtd_trigger() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/871rrsmi9j.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add soc_rtd_hw_free() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/8736c8mi9n.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add soc_rtd_hw_params() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/874kwomi9r.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add soc_rtd_prepare() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/875zh4mi9v.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add soc_rtd_shutdown() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/877e1kmi9z.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add soc_rtd_startup() to make the code easier to read
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/878sm0mia4.wl-kuninori.morimoto.gx@renesas.com
Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The code which checks the return value for snd_soc_add_dai_link() call
in soc_tplg_fe_link_create() moved the snd_soc_add_dai_link() call before
link->dobj members initialization.
While it does not affect the latest kernels, the old soc-core.c code
in the stable kernels is affected. The snd_soc_add_dai_link() function uses
the link->dobj.type member to check, if the link structure is valid.
Reorder the link->dobj initialization to make things work again.
It's harmless for the recent code (and the structure should be properly
initialized before other calls anyway).
The problem is in stable linux-5.4.y since version 5.4.11 when the
upstream commit 76d270364932 was applied.
Fixes: 76d270364932 ("ASoC: topology: Check return value for snd_soc_add_dai_link()")
Cc: Dragos Tarcatu <dragos_tarcatu@mentor.com>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20200122190752.3081016-1-perex@perex.cz
Signed-off-by: Mark Brown <broonie@kernel.org>
Both the data and clock should be connected to both the left and right
inputs for DMIC only inputs, add the missing routes.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200122104143.16725-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Lenovo Thinkpad T420s uses the same codec as T420, so apply the
same quirk to enable audio output on a docking station.
Signed-off-by: Peter Große <pegro@friiks.de>
Link: https://lore.kernel.org/r/20200122180106.9351-1-pegro@friiks.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The MT6660 is a boosted BTL class-D amplifier with V/I sensing.
A built-in DC-DC step-up converter is used to provide efficient
power for class-D amplifier with multi-level class-G operation.
The digital audio interface supports I2S, left-justified,
right-justified, TDM and DSP A/B format for audio in with a data
out used for chip information like voltage sense and current
sense, which are able to be monitored via DATAO through proper
Signed-off-by: Jeff Chang <jeff_chang@richtek.com>
Link: https://lore.kernel.org/r/1579153597-23286-1-git-send-email-richtek.jeff.chang@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 62d5ae4cafb7 ("ASoC: max98090: save and restore SHDN when
changing sensitive registers SHDN bit") uses dapm_mutex to protect SHDN
bit. However, snd_soc_dapm_put_enum_double() in
max98090_dapm_put_enum_double() acquires the dapm_mutex again which
cause a deadlock.
Use snd_soc_dapm_put_enum_double_locked() instead to fix the deadlock.
Fixes: 62d5ae4cafb7 ("ASoC: max98090: save and restore SHDN when changing sensitive registers SHDN bit")
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200117073814.82441-4-tzungbi@google.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Commit 2dc98af62c32 ("ASoC: max98090: fix lockdep warning") introduced
a helpful-less small lock: shdn_lock. Reverts the commit.
Reasons:
1. Lockdep should not be happy by either the original or current code.
From lockdep's point of view, there is a lock inversion anyway.
Let d = dapm_mutex, c = controls_rwsem, s = shdn_lock,
From the reported calling stack: lock acquisition order of
snd_soc_register_card() is: d -> c.
> snd_ctl_add_replace+0x3c/0x84
> dapm_create_or_share_kcontrol+0x24c/0x2e0
> snd_soc_dapm_new_widgets+0x308/0x594
> snd_soc_bind_card+0x80c/0xad4
> devm_snd_soc_register_card+0x34/0x6c
If calling snd_soc_dapm_put_enum_double() in kcontrol's put (e.g.
SOC_DAPM_ENUM_EXT), lock acquisition order is: c -> d. Note that,
snd_soc_dapm_put_enum_double() acquires d.
The possible lock inversion is always there if registering sound card
and putting mixer control happen at the same time. In fact, it never
happens because the control device don't show up to the userspace until
the sound card build success.
Commit 2dc98af62c32 ("ASoC: max98090: fix lockdep warning") changes the
order to: c -> s -> d. The lock inversion is still there.
2. Commit 62d5ae4cafb7 ("ASoC: max98090: save and restore SHDN when
changing sensitive registers SHDN bit") designed to use dapm_mutex to
protect SHDN bit. Use a separate lock breaks the protection.
DAPM changes SHDN bit automatically when it finds the path. Thus, any
code wants to change the SHDN bit, need to acquire the dapm_mutex first.
> SND_SOC_DAPM_SUPPLY("SHDN", M98090_REG_DEVICE_SHUTDOWN,
> M98090_SHDNN_SHIFT, 0, NULL, 0),
Fixes: 2dc98af62c32 ("ASoC: max98090: fix lockdep warning")
Signed-off-by: Tzung-Bi Shih <tzungbi@google.com>
Link: https://lore.kernel.org/r/20200117073814.82441-2-tzungbi@google.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Now, snd_soc_dai_driver::bus_control is used for how to resume.
But, no driver which has bus_control has DAI driver suspend/resume
support.
This patch removes pointless bus_control from ALSA SoC.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87pnffx7i4.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Historically, CPU and Codec were implemented different, but now it is
merged as Component.
ALSA SoC is supporting suspend/resume at DAI and Component level.
The method is like below.
1) Suspend/Resume all CPU DAI if bus-control was 0
2) Suspend/Resume all Component
3) Suspend/Resume all CPU DAI if bus-control was 1
Historically 2) was Codec special operation.
Because CPU and Codec were merged into Component,
CPU suspend/resume has 3 chance to suspend(= 1/2/3), but
Codec suspend/resume has 1 chance (= 2).
Here, DAI side suspend/resume is caring bus-control, but no driver
which is supporting suspend/resume is setting bus-control.
This means 3) was never used.
Here, used parameter for suspend/resume component->dev and dai->dev are
same pointer.
For that reason, we can merge DAI and Component suspend/resume.
One note is that we should use 2), because it is caring BIAS level.
This patch removes 1) and 3).
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87r1zvx7i8.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87sgkbx7ic.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can swtcih all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87tv4rx7ij.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87wo9nx7it.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87y2u3x7iy.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87zhejx7j4.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/871rrvym3p.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/8736cbym3x.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/874kwrym42.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/875zh7ym48.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/877e1nym4e.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/878sm3ym4j.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87a76jym4p.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87d0bfym53.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There is no big difference at implementation for .suspend/.resume
between DAI driver and Component driver.
But because some driver is using DAI version, thus ALSA SoC needs
to keep supporting it, hence, framework becoming verbose.
If we can switch all DAI driver .suspend/.resume to Component driver,
we can remove verbose code from ALSA SoC.
Driver is getting its private data via dai->dev.
But dai->dev and component->dev are same dev, thus, we can convert
these. For same reason, we can convert dai->active to
component->active if necessary.
This patch moves DAI driver .suspend/.resume to Component driver
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87blqzym4w.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Remove the return value checking, that is to align with the code
before adding snd_dmaengine_pcm_refine_runtime_hwparams function.
Otherwise it causes a regression on the HiKey board:
[ 17.721424] hi6210_i2s f7118000.i2s: ASoC: can't open component f7118000.i2s: -6
Fixes: e957204e732b ("ASoC: pcm_dmaengine: Extract snd_dmaengine_pcm_refine_runtime_hwparams")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reported-by: John Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/r/1579505286-32085-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Crash happens in snd_soc_dapm_new_dai() when substream->private_data
access is made and substream is NULL here. This is seen for DAIs where
only playback or capture stream is defined. This seems to be happening
for codec2codec DAI link.
Both playback and capture are 0 during soc_new_pcm(). This is probably
happening because cpu_dai and codec_dai are both validated either for
SNDRV_PCM_STREAM_PLAYBACK or SNDRV_PCM_STREAM_CAPTURE.
Shouldn't be playback = 1 when,
- playback stream is available for codec_dai AND
- capture stream is available for cpu_dai
and vice-versa for capture = 1?
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Link: https://lore.kernel.org/r/1579443563-12287-1-git-send-email-spujar@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The initial snd_hda_get_sub_node() can fail on certain
devices (e.g. some Chromebook models using Intel GLK).
The failure rate is very low, but as this is is part of
the probe process, end-user impact is high.
In observed cases, related hardware status registers have
expected values, but the node query still fails. Retrying
the node query does seem to help, so fix the problem by
adding retry logic to the query. This does not impact
non-Intel platforms.
BugLink: https://github.com/thesofproject/linux/issues/1642
Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200120160117.29130-4-kai.vehmanen@linux.intel.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Like many other drivers, HD-audio drivers also do PCM buffer
preallocation to assure the buffer pages allocated at the early boot
stage. This step is useful for platforms that may fail to allocate
the PCM hardware buffers -- which is mostly for either large
continuous pages or with the specific DMA mask (like emu10k1).
OTOH, when a buffer is allocated as SG-buffer and the DMA mask is
either 32 or 64 bits, the allocation almost never fails unless it hits
the real OOM situation. In such a case, we don't need the
preallocation inevitably unlike the cases above.
That said, we may drop the preallocation for HD-audio that does
allocate via SG-buffers, and the patch achieves it.
However, there is one caveat: the buffer allocation behavior depends
on CONFIG_SND_DMA_SGBUF, and it falls back to the continuous pages
when it's not set. And, currently this SG buffer allocation is
enabled only on x86 platforms. So, covering those fall-outs, the
patch adjusts CONFIG_SND_HDA_PREALLOC_SIZE depending on the condition,
and keeps the old behavior as-is for non-x86 platforms.
On x86, the kconfig item is no longer adjustable but always set to
zero for disabling the preallocation. You can still enable the
preallocation via procfs interface at any time later, too.
Link: https://lore.kernel.org/r/20200120124423.11862-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Currently, the available buffer allocation size for a PCM stream
depends on the preallocated size; when a buffer has been preallocated,
the max buffer size is set to that size, so that application won't
re-allocate too much memory. OTOH, when no preallocation is done,
each substream may allocate arbitrary size of buffers as long as
snd_pcm_hardware.buffer_bytes_max allows -- which can be quite high,
HD-audio sets 1GB there.
It means that the system may consume a high amount of pages for PCM
buffers, and they are pinned and never swapped out. This can lead to
OOM easily.
For avoiding such a situation, this patch adds the upper limit per
card. Each snd_pcm_lib_malloc_pages() and _free_pages() calls are
tracked and it will return an error if the total amount of buffers
goes over the defined upper limit. The default value is set to 32MB,
which should be really large enough for usual operations.
If larger buffers are needed for any specific usage, it can be
adjusted (also dynamically) via snd_pcm.max_alloc_per_card option.
Setting zero there means no chceck is performed, and again, unlimited
amount of buffers are allowed.
Link: https://lore.kernel.org/r/20200120124423.11862-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
It turned out that the recent simplification of HD-audio bus access
helpers caused a regression on the virtual HD-audio device on QEMU
with ARM platforms. The driver got a CORB/RIRB timeout and couldn't
probe any codecs.
The essential difference that caused a problem was the enforced
aligned MMIO accesses by simplification. Since snd-hda-tegra driver
is enabled on ARM, it enables CONFIG_SND_HDA_ALIGNED_MMIO, which makes
the all HD-audio drivers using the aligned MMIO accesses. While this
is mandatory for snd-hda-tegra, it seems that snd-hda-intel on ARM
gets broken by this access pattern.
For addressing the regression, this patch introduces a new flag,
aligned_mmio, to hdac_bus object, and applies the aligned MMIO only
when this flag is set. This change affects only platforms with
CONFIG_SND_HDA_ALIGNED_MMIO set, i.e. mostly only for ARM platforms.
Unfortunately the patch became a big bigger than it should be, just
because the former calls didn't take hdac_bus object in the argument,
hence we had to extend the call patterns.
Fixes: 19abfefd4c76 ("ALSA: hda: Direct MMIO accesses")
BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1161152
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200120104127.28985-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This became bigger than I have hoped for rc7. But, the only large LOC
is for stm32 fixes that are simple rewriting of register access
helpers, while the rest are all nice and small fixes:
- A few ASoC fixes for the remaining probe error handling bugs
- ALSA sequencer core fix for racy proc file accesses
- Revert the option rename of snd-hda-intel to make compatible again
- Various device-specific fixes
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl4gjbEOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE8Pow/+KXlxZDprRwaW5jX23k7OOOdZOjyrM+XNNH1J
ubCV5jHfZqT6FK2Ewo6ytxDOE7liiAZCs1r5D7of8sRHPVeMfgyRNdL4MbirR03n
eGzREtynfPXymcnaKZuuantFNl4rq3ovwCUOTiqNgTdONZzakm3bISMf5RLF0SBU
wuImY3PHepcjah3BXBTJHj8V9KpmDasd15DcrK0j/W+oS4eNnxSCoH4gzAwjAuDO
v2bEsF/yXGDhriyl/squJjVBnNOkzn/fyRAQl7RGe8pNa4PWIvbAaqd5qaIch4EH
perJfnvhB5SoB/s7mJ3jwnjA/vx0VKkCOw7Wufr/3+i1gKsuDbkvh8eaoN0/rnNk
gn56hLux7nnbOW5uzVG12PekIf3T7uJMM7mMZGAMOeQpWK6xCpDHHlC/1rZd+idy
SUgkqHEhQl9Qu5d7c7KkTy408FOzhaL4HZX5wqSghPUj2mFrWZGxpQvLlD1FYCE2
NuFKzPNYaeLbUyhJJ2HBmjEov0R3ASZzVYx/fRarc+JET7jI/hyWfBJ+oe1qy1Ff
X7gDrLpbXd61lgtCALlv9K1v5Ap7FSkAEXiHI4jtj/9m0yN/XTp5pqjd4itW7ZR9
2EuQrsysh1JimFBauNdLVRCPooPkAqiEeWscMjqgBth2l7BhinYoXIMcA+fchUgC
up9VJeQ=
=M4pi
-----END PGP SIGNATURE-----
Merge tag 'sound-5.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"This became bigger than I have hoped for rc7. But, the only large LOC
is for stm32 fixes that are simple rewriting of register access
helpers, while the rest are all nice and small fixes:
- A few ASoC fixes for the remaining probe error handling bugs
- ALSA sequencer core fix for racy proc file accesses
- Revert the option rename of snd-hda-intel to make compatible again
- Various device-specific fixes"
* tag 'sound-5.5-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: seq: Fix racy access for queue timer in proc read
ALSA: usb-audio: fix sync-ep altsetting sanity check
ASoC: msm8916-wcd-digital: Reset RX interpolation path after use
ASoC: msm8916-wcd-analog: Fix MIC BIAS Internal1
ASoC: cros_ec_codec: Make the device acpi compatible
ASoC: sti: fix possible sleep-in-atomic
ASoC: msm8916-wcd-analog: Fix selected events for MIC BIAS External1
ASoC: hdac_hda: Fix error in driver removal after failed probe
ASoC: SOF: Intel: fix HDA codec driver probe with multiple controllers
ASoC: SOF: Intel: lower print level to dbg if we will reinit DSP
ALSA: dice: fix fallback from protocol extension into limited functionality
ALSA: firewire-tascam: fix corruption due to spin lock without restoration in SoftIRQ context
ALSA: hda: Rename back to dmic_detect option
ASoC: stm32: dfsdm: fix 16 bits record
ASoC: stm32: sai: fix possible circular locking
ASoC: Fix NULL dereference at freeing
ASoC: Intel: bytcht_es8316: Fix Irbis NB41 netbook quirk
ASoC: rt5640: Fix NULL dereference on module unload
The snprintf calls filling cht_rt5645_cpu_dai_name /
cht_rt5645_codec_aif_name always fill them with the same string
("ssp0-port" resp "rt5645-aif2") so instead of keeping these buffers
around and making cpus->dai_name / codecs->dai_name point to this,
simply update the *->dai_name pointers to directly point to a string
constant containing the desired string.
Signed-off-by: Damian van Soelen <dj.vsoelen@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200115164619.101705-5-hdegoede@redhat.com
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The snprintf calls filling byt_rt56*_codec_aif_name/byt_rt56*_cpu_dai_name
always fill them with the same string ("rt56*-aif2" resp. ssp0-port").
So instead of keeping these buffers around and making codecs->dai_name /
cpus->dai_name point to them, simply update the *->dai_name pointers to
directly point to a string constant containing the desired string.
Signed-off-by: Jordy Ubink <jordyubink@hotmail.nl>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200115164619.101705-4-hdegoede@redhat.com
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The snprintf calls filling byt_rt56*_codec_aif_name/byt_rt56*_cpu_dai_name
always fill them with the same string ("rt56*-aif2" resp. ssp0-port").
So instead of keeping these buffers around and making codecs->dai_name /
cpus->dai_name point to them, simply update the *->dai_name pointers to
directly point to a string constant containing the desired string.
Signed-off-by: Nariman Etemadi <narimantos@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200115164619.101705-3-hdegoede@redhat.com
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
