summaryrefslogtreecommitdiff
path: root/sound/soc/codecs/max98090.c
AgeCommit message (Collapse)AuthorFilesLines
2023-06-23ASoC: codecs: max98090: Allow dsp_a modeMaxim Kochetkov1-25/+28
TDM mode for max98090 is dsp_a compatible with such limitations: 1) Up to four timeslots supported. 2) Only 16 bits timeslots supported. 3) Only 2 active timeslots (L/R) supported. We want to setup TDM mode only when dsp_a mode is selected. So move M98090_REG_TDM_FORMAT/M98090_REG_TDM_CONTROL registers setup from max98090_set_tdm_slot() to the max98090_dai_set_fmt(). Also extend max98090_set_tdm_slot() with all TDM limitations check. Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru> Link: https://lore.kernel.org/r/Message-Id: <20230622142038.63388-1-fido_max@inbox.ru> Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-23ASoC: do not include pm_runtime.h if not usedClaudiu Beznea1-1/+0
Do not include pm_runtime.h header in files where APIs exported by pm_runtime.h are not used. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Acked-by: Jarkko Nikula <jarkko.nikula@bitmer.com> # for omap-mcbsp-st.c Link: https://lore.kernel.org/r/20230517094903.2895238-2-claudiu.beznea@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-08ASoC: Switch i2c drivers back to use .probe()Uwe Kleine-König1-1/+1
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de Link: https://lore.kernel.org/r/20230425095716.331419-1-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org
2023-02-09ASoC: codecs: max98090: simplify snd_soc_dai_driverKrzysztof Kozlowski1-5/+3
The max98090 has only one DAI, so snd_soc_dai_driver does not have to be an array. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20230208160410.371609-2-krzysztof.kozlowski@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-08-16i2c: Make remove callback return voidUwe Kleine-König1-3/+1
The value returned by an i2c driver's remove function is mostly ignored. (Only an error message is printed if the value is non-zero that the error is ignored.) So change the prototype of the remove function to return no value. This way driver authors are not tempted to assume that passing an error to the upper layer is a good idea. All drivers are adapted accordingly. There is no intended change of behaviour, all callbacks were prepared to return 0 before. Reviewed-by: Peter Senna Tschudin <peter.senna@gmail.com> Reviewed-by: Jeremy Kerr <jk@codeconstruct.com.au> Reviewed-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Crt Mori <cmo@melexis.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Marek Behún <kabel@kernel.org> # for leds-turris-omnia Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Petr Machata <petrm@nvidia.com> # for mlxsw Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for surface3_power Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> # for bmc150-accel-i2c + kxcjk-1013 Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> # for media/* + staging/media/* Acked-by: Miguel Ojeda <ojeda@kernel.org> # for auxdisplay/ht16k33 + auxdisplay/lcd2s Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # for versaclock5 Reviewed-by: Ajay Gupta <ajayg@nvidia.com> # for ucsi_ccg Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for iio Acked-by: Peter Rosin <peda@axentia.se> # for i2c-mux-*, max9860 Acked-by: Adrien Grassein <adrien.grassein@gmail.com> # for lontium-lt8912b Reviewed-by: Jean Delvare <jdelvare@suse.de> # for hwmon, i2c-core and i2c/muxes Acked-by: Corey Minyard <cminyard@mvista.com> # for IPMI Reviewed-by: Vladimir Oltean <olteanv@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for drivers/power Acked-by: Krzysztof Hałasa <khalasa@piap.pl> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Wolfram Sang <wsa@kernel.org>
2022-06-27ASoC: max*: Remove now redundant non_legacy_dai_naming flagCharles Keepax1-1/+0
The ASoC core has now been changed to default to the non-legacy DAI naming, as such drivers using the new scheme no longer need to specify the non_legacy_dai_naming flag. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220623125250.2355471-53-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06ASoC: max98090: Use modern ASoC DAI format terminologyMark Brown1-7/+5
As part of moving to remove the old style defines for the bus clocks update the max98090 driver to use more modern terminology for clocking. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220602135316.3554400-3-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-05-20ASoC: max98090: Move check for invalid values before casting in ↵Alexey Khoroshilov1-2/+4
max98090_put_enab_tlv() Validation of signed input should be done before casting to unsigned int. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Suggested-by: Mark Brown <broonie@kernel.org> Fixes: 2fbe467bcbfc ("ASoC: max98090: Reject invalid values in custom control put()") Link: https://lore.kernel.org/r/1652999486-29653-1-git-send-email-khoroshilov@ispras.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2022-05-04ASoC: Pull in fixesMark Brown1-1/+6
Cleanups for the dmaengine code build on top of current fixes.
2022-05-03ASoC: max98090: Fix event generation for custom controlsMark Brown1-1/+3
The previous fix for event generation for custom controls compared the value already in the register with the value being written, missing the logic that only applies the value to the register when the control is already enabled. Fix this, compare the value cached in the driver data rather than the register. This should really be an autodisable control rather than open coded. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220428113221.15326-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-25ASoC: max980*: use i2c_match_id and simple i2c probeStephen Kitt1-11/+12
As part of the ongoing i2c transition to the simple probe ("probe_new"), this patch uses i2c_match_id to retrieve the driver_data for the probed device. The id parameter is thus no longer necessary and the simple probe can be used instead. In the context of an i2c probe, i2c_match_id with the module id table and the probed client never returns null, so removing the null check on the i2c_device_id pointer is safe. The i2c id tables are moved up before the probe function, as suggested by Wolfram Sang. Signed-off-by: Stephen Kitt <steve@sk2.org> Link: https://lore.kernel.org/r/20220415160613.148882-4-steve@sk2.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-25ASoC: max98090: Generate notifications on changes for custom controlMark Brown1-1/+1
The max98090 driver has some custom controls which share a put() function which returns 0 unconditionally, meaning that events are not generated when the value changes. Fix that. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220420193454.2647908-2-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-25ASoC: max98090: Reject invalid values in custom control put()Mark Brown1-0/+3
The max98090 driver has a custom put function for some controls which can only be updated in certain circumstances which makes no effort to validate that input is suitable for the control, allowing out of spec values to be written to the hardware and presented to userspace. Fix this by returning an error when invalid values are written. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220420193454.2647908-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-08-05ASoC: max98090: remove duplicate status reads and useless assignmmentPierre-Louis Bossart1-3/+1
The logic for the jack detection has not changed since the first commit for this driver. Remove a duplicate read and remove useless assignment sound/soc/codecs/max98090.c:2170:6: style: Variable 'reg' is reassigned a value before the old one has been used. [redundantAssignment] reg = snd_soc_component_read(component, M98090_REG_JACK_STATUS); ^ sound/soc/codecs/max98090.c:2161:7: note: reg is assigned reg = snd_soc_component_read(component, M98090_REG_JACK_STATUS); ^ sound/soc/codecs/max98090.c:2170:6: note: reg is overwritten reg = snd_soc_component_read(component, M98090_REG_JACK_STATUS); ^ sound/soc/codecs/max98090.c:2170:6: style: Variable 'reg' is reassigned a value before the old one has been used. [redundantAssignment] reg = snd_soc_component_read(component, M98090_REG_JACK_STATUS); ^ sound/soc/codecs/max98090.c:2167:7: note: reg is assigned reg = snd_soc_component_read(component, M98090_REG_JACK_STATUS); ^ sound/soc/codecs/max98090.c:2170:6: note: reg is overwritten reg = snd_soc_component_read(component, M98090_REG_JACK_STATUS); ^ Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210804192456.278702-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-18ASoC: max98090: remove useless assignmentPierre-Louis Bossart1-1/+1
cppcheck warning: sound/soc/codecs/max98090.c:1835:16: style: Variable 'test_diff' is assigned a value that is never used. [unreadVariable] int test_diff = INT_MAX; ^ Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210312182246.5153-13-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-26ASoC: max98090: skip of_device_id table when !CONFIG_OFKrzysztof Kozlowski1-0/+2
The driver can match by multiple methods. Its of_device_id table is referenced via of_match_ptr() so it will be unused for !CONFIG_OF builds: sound/soc/codecs/max98090.c:2671:34: warning: ‘max98090_of_match’ defined but not used [-Wunused-const-variable=] Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20201125164452.89239-22-krzk@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-17ASoC: codecs: max*: merge .digital_mute() into .mute_stream()Kuninori Morimoto1-2/+4
snd_soc_dai_digital_mute() is internally using both mute_stream() (1) or digital_mute() (2), but the difference between these 2 are only handling direction. We can merge digital_mute() into mute_stream int snd_soc_dai_digital_mute(xxx, int direction) { ... else if (dai->driver->ops->mute_stream) (1) return dai->driver->ops->mute_stream(xxx, direction); else if (direction == SNDRV_PCM_STREAM_PLAYBACK && dai->driver->ops->digital_mute) (2) return dai->driver->ops->digital_mute(xxx); ... } Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Link: https://lore.kernel.org/r/87y2ntwix0.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-22ASoC: codecs: max*: rename to snd_soc_component_read()Kuninori Morimoto1-10/+10
We need to use snd_soc_component_read() instead of snd_soc_component_read32() This patch renames _read32() to _read() Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://lore.kernel.org/r/87imfr4mdl.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-05-18ASoC: codecs: use snd_soc_xxx_active()Kuninori Morimoto1-3/+3
We have snd_soc_dai/dai_stream/component_active() macro This patch uses it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Link: https://lore.kernel.org/r/87wo5e58j4.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-02-14ASoC: max98090: revert invalid fix for handling SHDNTzung-Bi Shih1-311/+123
Reverts commit 62d5ae4cafb7 ("ASoC: max98090: save and restore SHDN when changing sensitive registers"). A critical side-effect was observed: when keep playing something, the recorded sound has chance to break (clipping). Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20200214105744.82258-2-tzungbi@google.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-24ASoC: max98090: silence lockdep warningMarek Szyprowski1-1/+2
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>
2020-01-21ASoC: max98090: fix deadlock in max98090_dapm_put_enum_double()Tzung-Bi Shih1-1/+1
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>
2020-01-21ASoC: max98090: revert "ASoC: max98090: fix lockdep warning"Tzung-Bi Shih1-6/+4
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>
2020-01-10ASoC: max98090: Drop incorrectly applied duplicate commitMark Brown1-1/+1
This reverts commit 4e93c1294f4b051 (ASoC: max98090: fix incorrect helper in max98090_dapm_put_enum_double()) which was misapplied. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-09ASoC: max98090: fix lockdep warningMarek Szyprowski1-4/+6
Commit 62d5ae4cafb7 ("ASoC: max98090: save and restore SHDN when changing sensitive registers") extended the code for handling many controls by adding a custom put function to them. That new custom put function properly handles relations between codec's hardware registers. However they used card->dapm_mutex to properly serialize those operations. This in turn triggers a lockdep warning about possible circular dependency. Fix this by introducing a separate mutex only for serializing the SHDN hardware register related operations. This fixes the following lockdep warning observed on Exynos4412-based Odroid U3 board: ====================================================== WARNING: possible circular locking dependency detected 5.5.0-rc5-next-20200107 #166 Not tainted ------------------------------------------------------ alsactl/1104 is trying to acquire lock: ed0d50f4 (&card->dapm_mutex){+.+.}, at: max98090_shdn_save+0x1c/0x28 but task is already holding lock: edb4b49c (&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+0x80c/0xad4 devm_snd_soc_register_card+0x34/0x6c odroid_audio_probe+0x288/0x34c platform_drv_probe+0x6c/0xa4 really_probe+0x200/0x490 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+0x22c/0x7c4 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+0x470/0xaf8 ret_fast_syscall+0x0/0x28 0xbefaa564 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/1104: #0: edb4b49c (&card->controls_rwsem){++++}, at: snd_ctl_ioctl+0xcc/0xbb8 stack backtrace: CPU: 0 PID: 1104 Comm: alsactl Not tainted 5.5.0-rc5-next-20200107 #166 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) (unwind_backtrace) from [<c010e180>] (show_stack+0x10/0x14) (show_stack) from [<c0b2a09c>] (dump_stack+0xb4/0xe0) (dump_stack) from [<c018a1c0>] (check_noncircular+0x1ec/0x208) (check_noncircular) from [<c018c5dc>] (__lock_acquire+0x1210/0x25ec) (__lock_acquire) from [<c018e2d8>] (lock_acquire+0xe8/0x270) (lock_acquire) from [<c0b49678>] (__mutex_lock+0x9c/0xb18) (__mutex_lock) from [<c0b4a110>] (mutex_lock_nested+0x1c/0x24) (mutex_lock_nested) from [<c0839b3c>] (max98090_shdn_save+0x1c/0x28) (max98090_shdn_save) from [<c083a5b8>] (max98090_put_enum_double+0x20/0x40) (max98090_put_enum_double) from [<c080d0e8>] (snd_ctl_ioctl+0x190/0xbb8) (snd_ctl_ioctl) from [<c02cafec>] (ksys_ioctl+0x470/0xaf8) (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28) ... Fixes: 62d5ae4cafb7 ("ASoC: max98090: save and restore SHDN when changing sensitive registers") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20200108115007.31095-2-m.szyprowski@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-09ASoC: max98090: fix incorrect helper in max98090_dapm_put_enum_double()Marek Szyprowski1-1/+1
Commit 62d5ae4cafb7 ("ASoC: max98090: save and restore SHDN when changing sensitive registers") extended the code for handling "LTENL Mux", "LTENR Mux", "LBENL Mux" and "LBENR Mux" controls by adding a custom max98090_dapm_put_enum_double() function to them. However that function used incorrect helper to get its component object. Fix this by using the proper snd_soc_dapm_* helper. This fixes the following NULL pointer exception observed on Exynos4412-based Odroid U3 board: 8<--- cut here --- Unable to handle kernel NULL pointer dereference at virtual address 000000b0 pgd = (ptrval) [000000b0] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 1104 Comm: alsactl Not tainted 5.5.0-rc5-next-20200107 #166 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) PC is at __mutex_lock+0x54/0xb18 LR is at ___might_sleep+0x3c/0x2e0 ... Process alsactl (pid: 1104, stack limit = 0x(ptrval)) ... [<c0b49630>] (__mutex_lock) from [<c0b4a110>] (mutex_lock_nested+0x1c/0x24) [<c0b4a110>] (mutex_lock_nested) from [<c0839b3c>] (max98090_shdn_save+0x1c/0x28) [<c0839b3c>] (max98090_shdn_save) from [<c083a4f8>] (max98090_dapm_put_enum_double+0x20/0x40) [<c083a4f8>] (max98090_dapm_put_enum_double) from [<c080d0e8>] (snd_ctl_ioctl+0x190/0xbb8) [<c080d0e8>] (snd_ctl_ioctl) from [<c02cafec>] (ksys_ioctl+0x470/0xaf8) [<c02cafec>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28) ... ---[ end trace 0e93f0580f4b9241 ]--- Fixes: 62d5ae4cafb7 ("ASoC: max98090: save and restore SHDN when changing sensitive registers") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20200108115007.31095-1-m.szyprowski@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-01-09ASoC: max98090: fix incorrect helper in max98090_dapm_put_enum_double()Marek Szyprowski1-1/+1
Commit 62d5ae4cafb7 ("ASoC: max98090: save and restore SHDN when changing sensitive registers") extended the code for handling "LTENL Mux", "LTENR Mux", "LBENL Mux" and "LBENR Mux" controls by adding a custom max98090_dapm_put_enum_double() function to them. However that function used incorrect helper to get its component object. Fix this by using the proper snd_soc_dapm_* helper. This fixes the following NULL pointer exception observed on Exynos4412-based Odroid U3 board: 8<--- cut here --- Unable to handle kernel NULL pointer dereference at virtual address 000000b0 pgd = (ptrval) [000000b0] *pgd=00000000 Internal error: Oops: 5 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 1104 Comm: alsactl Not tainted 5.5.0-rc5-next-20200107 #166 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) PC is at __mutex_lock+0x54/0xb18 LR is at ___might_sleep+0x3c/0x2e0 ... Process alsactl (pid: 1104, stack limit = 0x(ptrval)) ... [<c0b49630>] (__mutex_lock) from [<c0b4a110>] (mutex_lock_nested+0x1c/0x24) [<c0b4a110>] (mutex_lock_nested) from [<c0839b3c>] (max98090_shdn_save+0x1c/0x28) [<c0839b3c>] (max98090_shdn_save) from [<c083a4f8>] (max98090_dapm_put_enum_double+0x20/0x40) [<c083a4f8>] (max98090_dapm_put_enum_double) from [<c080d0e8>] (snd_ctl_ioctl+0x190/0xbb8) [<c080d0e8>] (snd_ctl_ioctl) from [<c02cafec>] (ksys_ioctl+0x470/0xaf8) [<c02cafec>] (ksys_ioctl) from [<c0101000>] (ret_fast_syscall+0x0/0x28) ... ---[ end trace 0e93f0580f4b9241 ]--- Fixes: 62d5ae4cafb7 ("ASoC: max98090: save and restore SHDN when changing sensitive registers") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20200108115007.31095-1-m.szyprowski@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-20ASoC: max98090: Remove empty suspend functionMark Brown1-6/+1
The suspend function is empty so can be removed. Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20191219125140.47689-1-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2019-12-10Merge branch 'for-5.5' of ↵Mark Brown1-9/+21
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into asoc-5.6
2019-12-09ASoC: max98090: save and restore SHDN when changing sensitive registersTzung-Bi Shih1-123/+310
According to the datasheet, there are some registers can only be changed when SHDN is 0. Changing these settings during SHDN = 1 can compromise device stability and performance specifications. Saves SHDN before writing to these sensitive registers and restores SHDN afterward. Here is the register list codec driver of max98090 wants to change: M98090_REG_QUICK_SYSTEM_CLOCK 0x04 M98090_REG_QUICK_SAMPLE_RATE 0x05 M98090_REG_DAI_INTERFACE 0x06 M98090_REG_DAC_PATH 0x07 M98090_REG_MIC_DIRECT_TO_ADC 0x08 M98090_REG_LINE_TO_ADC 0x09 M98090_REG_ANALOG_MIC_LOOP 0x0A M98090_REG_ANALOG_LINE_LOOP 0x0B M98090_REG_SYSTEM_CLOCK 0x1B M98090_REG_CLOCK_MODE 0x1C M98090_REG_CLOCK_RATIO_NI_MSB 0x1D M98090_REG_CLOCK_RATIO_NI_LSB 0x1E M98090_REG_CLOCK_RATIO_MI_MSB 0x1F M98090_REG_CLOCK_RATIO_MI_LSB 0x20 M98090_REG_MASTER_MODE 0x21 M98090_REG_INTERFACE_FORMAT 0x22 M98090_REG_TDM_CONTROL 0x23 M98090_REG_TDM_FORMAT 0x24 M98090_REG_IO_CONFIGURATION 0x25 M98090_REG_FILTER_CONFIG 0x26 M98090_REG_INPUT_ENABLE 0x3E M98090_REG_OUTPUT_ENABLE 0x3F M98090_REG_BIAS_CONTROL 0x42 M98090_REG_DAC_CONTROL 0x43 M98090_REG_ADC_CONTROL 0x44 M98090_REG_DRC_TIMING 0x33 M98090_REG_DRC_COMPRESSOR 0x34 M98090_REG_DRC_EXPANDER 0x35 M98090_REG_DSP_FILTER_ENABLE 0x41 M98090_REG_EQUALIZER_BASE 0x46 M98090_REG_RECORD_BIQUAD_BASE 0xAF M98090_REG_DIGITAL_MIC_ENABLE 0x13 M98090_REG_DIGITAL_MIC_CONFIG 0x14 Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20191128151908.180871-1-tzungbi@google.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-27ASoC: max98090: fix possible race conditionsTzung-Bi Shih1-6/+2
max98090_interrupt() and max98090_pll_work() run in 2 different threads. There are 2 possible races: Note: M98090_REG_DEVICE_STATUS = 0x01. Note: ULK == 0, PLL is locked; ULK == 1, PLL is unlocked. max98090_interrupt max98090_pll_work ---------------------------------------------- schedule max98090_pll_work restart max98090 codec receive ULK INT assert ULK == 0 schedule max98090_pll_work (1). In the case (1), the PLL is locked but max98090_interrupt unnecessarily schedules another max98090_pll_work. max98090_interrupt max98090_pll_work max98090 codec ---------------------------------------------------------------------- ULK = 1 receive ULK INT read 0x01 ULK = 0 (clear on read) schedule max98090_pll_work restart max98090 codec ULK = 1 receive ULK INT read 0x01 ULK = 0 (clear on read) read 0x01 assert ULK == 0 (2). In the case (2), both max98090_interrupt and max98090_pll_work read the same clear-on-read register. max98090_pll_work would falsely thought PLL is locked. Note: the case (2) race is introduced by the previous commit ("ASoC: max98090: exit workaround earlier if PLL is locked") to check the status and exit the loop earlier in max98090_pll_work. There are 2 possible solution options: A. turn off ULK interrupt before scheduling max98090_pll_work; and turn on again before exiting max98090_pll_work. B. remove the second thread of execution. Option A cannot fix the case (2) race because it still has 2 threads access the same clear-on-read register simultaneously. Although we could suppose the register is volatile and read the status via I2C could be much slower than the hardware raises the bits. Option B introduces a maximum 10~12 msec penalty delay in the interrupt handler. However, it could only punish the jack detection by extra 10~12 msec. Adopts option B which is the better solution overall. Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20191122073114.219945-4-tzungbi@google.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-27ASoC: max98090: exit workaround earlier if PLL is lockedTzung-Bi Shih1-2/+12
According to the datasheet, PLL lock time typically takes 2 msec and at most takes 7 msec. Check the lock status every 1 msec and exit the workaround if PLL is locked. Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20191122073114.219945-3-tzungbi@google.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-11-27ASoC: max98090: remove msleep in PLL unlocked workaroundTzung-Bi Shih1-1/+7
It was observed Baytrail-based chromebooks could cause continuous PLL unlocked when using playback stream and capture stream simultaneously. Specifically, starting a capture stream after started a playback stream. As a result, the audio data could corrupt or turn completely silent. As the datasheet suggested, the maximum PLL lock time should be 7 msec. The workaround resets the codec softly by toggling SHDN off and on if PLL failed to lock for 10 msec. Notably, there is no suggested hold time for SHDN off. On Baytrail-based chromebooks, it would easily happen continuous PLL unlocked if there is a 10 msec delay between SHDN off and on. Removes the msleep(). Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20191122073114.219945-2-tzungbi@google.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-06-19treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner1-4/+1
Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-04ASoC: max98090: remove 24-bit format support if RJ is 0Yu-Hsuan Hsu1-0/+16
The supported formats are S16_LE and S24_LE now. However, by datasheet of max98090, S24_LE is only supported when it is in the right justified mode. We should remove 24-bit format if it is not in that mode to avoid triggering error. Signed-off-by: Yu-Hsuan Hsu <yuhsuan@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-05-06ASoC: max98090: Fix restore of DAPM MuxesJon Hunter1-6/+6
The max98090 driver defines 3 DAPM muxes; one for the right line output (LINMOD Mux), one for the left headphone mixer source (MIXHPLSEL Mux) and one for the right headphone mixer source (MIXHPRSEL Mux). The same bit is used for the mux as well as the DAPM enable, and although the mux can be correctly configured, after playback has completed, the mux will be reset during the disable phase. This is preventing the state of these muxes from being saved and restored correctly on system reboot. Fix this by marking these muxes as SND_SOC_NOPM. Note this has been verified this on the Tegra124 Nyan Big which features the MAX98090 codec. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2019-01-07ASoC: max98090: remove unused constant variablesPierre-Louis Bossart1-15/+0
Fix warnings with W=1 If these variables are useful then this driver should be modified to expose them. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-02-12ASoC: max98090: replace codec to componentKuninori Morimoto1-159/+160
Now we can replace Codec to Component. Let's do it. Note: xxx_codec_xxx() -> xxx_component_xxx() .idle_bias_off = 0 -> .idle_bias_on = 1 .ignore_pmdown_time = 0 -> .use_pmdown_time = 1 - -> .endianness = 1 - -> .non_legacy_dai_naming = 1 Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-09-19ASoC: max98090: reduce verbosity on PLL unlockPierre-Louis Bossart1-1/+1
'commit b8a3ee820f7b ("ASoC: max98090: Add recovery for PLL lock failure")' enabled a workaround PLL unlocked issues, but generates annoying dev_info "PLL unlocked" messages at a 10ms rate, usually on startup. Move to dev_info_ratelimited. This issue doesn't seem to impact audio functionality. This trace is commented out in the GalliumOS patches, it's better to keep it to check on potential quality issues Tested on Lenovo 100s (Baytrail Chromebook) Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Acked-By: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-08-10ASoC: codecs: add const to snd_soc_codec_driver structuresBhumika Goyal1-1/+1
Declare snd_soc_codec_driver structures as const as they are only passed as an argument to the function snd_soc_register_codec. This argument is of type const, so declare the structures with this property as const. In file codecs/sn95031.c, snd_soc_codec_driver structure is also used in a copy operation along with getting passed to snd_soc_register_codec. So, it can be made const too. Done using Coccinelle: @match disable optional_qualifier@ identifier s; position p; @@ static struct snd_soc_codec_driver s@p={...}; @good1@ identifier match.s; position p; @@ snd_soc_register_codec(...,&s@p,...) @bad@ identifier match.s; position p!={match.p,good1.p}; @@ s@p @depends on !bad disable optional_qualifier@ identifier match.s; @@ static +const struct snd_soc_codec_driver s={...}; Signed-off-by: Bhumika Goyal <bhumirks@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-12-15ASoC: max98090: remove superflous check for 'micbias'Vinod Koul1-1/+1
In max98090_probe(), code checks for micbias being out of range. The 'micbias' variable in unsigned and checked against M98090_MBVSEL_2V2 which is zero, so remove this check. sound/soc/codecs/max98090.c: In function ‘max98090_probe’: sound/soc/codecs/max98090.c:2459:2: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits] } else if (micbias < M98090_MBVSEL_2V2 || micbias > M98090_MBVSEL_2V8) { Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-30Merge remote-tracking branches 'asoc/topic/tas2552', 'asoc/topic/tas5086', ↵Mark Brown1-24/+18
'asoc/topic/tegra', 'asoc/topic/tlv' and 'asoc/topic/topology' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/max98090', 'asoc/topic/max98095', ↵Mark Brown1-72/+8
'asoc/topic/max98357a', 'asoc/topic/max9877' and 'asoc/topic/max98925' into asoc-next
2015-08-30Merge remote-tracking branches 'asoc/topic/const', 'asoc/topic/cs35l32', ↵Mark Brown1-1/+1
'asoc/topic/cs4265' and 'asoc/topic/cs42l52' into asoc-next
2015-08-30Merge remote-tracking branch 'asoc/topic/ssm4567' into asoc-nextMark Brown1-1/+0
2015-08-10ASoC: max98090: Fix sequencing when starting additional routesFang, Yang A1-6/+40
Enforce correct device sequencing when configuring a new audio route when there is an existing active audio route(s). This patch fixed recording noise issue while playback is active. We have some registers which require the device to be in full shutdown or to enter full shutdown before the register settings will take effect. Currently the driver is not shutting down the device when a new audio route is created. If a new audio route is made active while there is already an active audio route, then the required register sequencing is violated. A hardware shutdown toggle when creating a new audio route corrects the sequencing error. The device must remain in hardware shutdown for 40ms to allow the internal hardware core to fully shutdown. Signed-off-by: Fang, Yang A <yang.a.fang@intel.com> Signed-off-by: Sathyanarayana Nujella <sathyanarayana.nujella@intel.com> Acked-by: Anish Kumar <anish.kumar@maximintegrated.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-08-05ASoC: max98090: Replace TLV_DB_RANGE_HEAD with DECLARE_TLV_DB_RANGELars-Peter Clausen1-24/+18
DECLARE_TLV_DB_RANGE() has the advantage over using TLV_DB_RANGE_HEAD() that it automatically calculates the number of items in the TLV and is hence less prone to manual error. Generate using the following coccinelle script // <smpl> @@ declarer name DECLARE_TLV_DB_RANGE; identifier tlv; constant x; @@ -unsigned int tlv[] = { - TLV_DB_RANGE_HEAD(x), +DECLARE_TLV_DB_RANGE(tlv, ... -}; +); // </smpl> Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-29ASoC: max98090: Simplify max98090_readable_register implementationAxel Lin1-69/+2
The readable registers are in consecutive ranges: 0x01 ~ 0x03, 0x0D ~ 0xD1, 0xFF So simplify the implementation by specifying a range of consecutive values in a single case label. Signed-off-by: Axel Lin <axel.lin@ingics.com> Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-15ASoC: drivers: Drop owner assignment from i2c_driverKrzysztof Kozlowski1-1/+0
i2c_driver does not need to set an owner because i2c_register_driver() will set it. Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2015-07-15ASoC: Constify snd_soc_dai_ops variablesAxel Lin1-1/+1
The snd_soc_dai_ops variables are not modified after initialization in these drivers, so make them const. Signed-off-by: Axel Lin <axel.lin@ingics.com> Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-14 05:31:19 +0300