summaryrefslogtreecommitdiff
path: root/sound/soc/codecs/tas6424.c
AgeCommit message (Collapse)AuthorFilesLines
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: tas*: 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-61-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-06-06ASoC: tas6424: Use modern ASoC DAI format terminologyMark Brown1-3/+3
As part of moving to remove the old style defines for the bus clocks update the tas6424 driver to use more modern terminology for clocking. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20220602135316.3554400-12-broonie@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2022-05-11ASoC: tas6424: Fix the error handling of tas6424_i2c_probe()Zheyu Ma1-2/+6
After enabling the regulator, The driver should disable the regulator when failing at probing. Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Link: https://lore.kernel.org/r/20220510153251.1741210-6-zheyuma97@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-26ASoC: tas6424: Return zero in remove callbackUwe Kleine-König1-3/+1
The only effect of returning an error code in an i2c remove callback (compared to returning zero) is that the i2c core emits a generic warning. The device is still removed. So even if disabling the regulators fails it's sensible to return zero to suppress the additional generic and little helpful error message. This patch is a preparation for making i2c remove callbacks return void. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20220425193206.61710-1-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-11ASoC: tas*: use simple i2c probe functionStephen Kitt1-3/+2
The i2c probe functions here don't use the id information provided in their second argument, so the single-parameter i2c probe function ("probe_new") can be used instead. This avoids scanning the identifier tables during probes. Signed-off-by: Stephen Kitt <steve@sk2.org> Link: https://lore.kernel.org/r/20220405165836.2165310-11-steve@sk2.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-22ASoC: Replace HTTP links with HTTPS onesAlexander A. Klimov1-1/+1
Rationale: Reduces attack surface on kernel devs opening the links for MITM as HTTPS traffic is much harder to manipulate. Deterministic algorithm: For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS. Signed-off-by: Alexander A. Klimov <grandmaster@al2klimov.de> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200719153822.59788-1-grandmaster@al2klimov.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-07-17ASoC: codecs: tas*: merge .digital_mute() into .mute_stream()Kuninori Morimoto1-2/+3
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/873661xxhu.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2018-11-05ASoC: codecs: constify snd_soc_dai_ops structuresJulia Lawall1-1/+1
The snd_soc_dai_ops structures are only stored in the ops field of a snd_soc_dai_driver structure, so make the snd_soc_dai_ops structures const as well. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-08-31ASoC: tas6424: Add channel fault reportingAndrew F. Davis1-6/+46
The TAS6426 has a register that reports channel faults such as overcurrent and continuous DC output. Add reporting of this here. Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-08-31Merge branch 'asoc-4.19' into asoc-4.20 tas dependencyMark Brown1-3/+9
2018-08-31ASoC: tas6424: Save last fault register even when clearAndrew F. Davis1-3/+9
When there is no fault bit set in a fault register we skip the fault reporting section for that register. This also skips over saving that registers value. We save the value so we will not double report an error, but if an error clears then returns we will also not report it as we did not save the all cleared register value. Fix this by saving the fault register value in the all clear path. Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
2018-08-31ASoC: tas6424: Print full register name in error messageAndrew F. Davis1-3/+3
The current short version of the register name may be ambiguous when another fault register detection is added. Use the full name. While here fix comment about clearing faults, the CLEAR_FAULT register actually only clears sticky bits, which are only warnings, fault bits can only cleared by resolving the fault. Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-05-04ASoC: tas6424: Allow disabling auto diagnostics for faster power-onJean-Jacques Hiblot1-2/+11
The TAS6424 incorporates both DC-load and AC-load diagnostics which are used to determine the status of the load. The DC diagnostics runs when any channel is directed to leave the Hi-Z state and enter the MUTE or PLAY state. The DC diagnostics are turned on by default but, if a fast startup without diagnostics is required, the diagnostics can be disabled using a dedicated ALSA control. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-04-27ASoC: tas6424: Add support for the mute pinJean-Jacques Hiblot1-1/+36
mute can be connected to GPIO. In that case we have to drive it to the correct value Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-04-27ASoC: tas6424: Add support for the standby pinJean-Jacques Hiblot1-0/+22
The standby pin can be connected to a GPIO. In that case we have to drive it to the correct values for the TAS6424 to operate properly. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-02-12ASoC: tas6424: replace codec to componentKuninori Morimoto1-51/+48
Now we can replace Codec to Component. Let's do it. Note: xxx_codec_xxx() -> xxx_component_xxx() .idle_bias_off = 1 -> .idle_bias_on = 0 .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-12-06ASoC: tas6424: Add support for TAS6424 digital amplifierAndreas Dannenberg1-0/+707
The Texas Instruments TAS6424 device is a high-efficiency quad-channel Class-D audio power amplifier. Its digital time division multiplexed (TDM) interface enables up to 2 devices to share the same bus, supporting a total of eight channels from one audio serial port. Signed-off-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Michael Stecklein <m-stecklein@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Mark Brown <broonie@kernel.org>