summaryrefslogtreecommitdiff
path: root/sound/soc/codecs/rt5651.c
AgeCommit message (Collapse)Author
2024-05-03ASoC: codecs: Drop explicit initialization of struct ↵Uwe Kleine-König
i2c_device_id::driver_data to 0 These drivers don't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20240502074722.1103986-2-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2024-02-12ASoC: codecs: fix TYPO 'reguest' to 'request' in error logYinchuan Guo
This patch corrects a common misspelling of "request" as "reguest" found in error log across multiple files within sound/soc/codecs. Signed-off-by: Yinchuan Guo <guoych37@mail2.sysu.edu.cn> Link: https://msgid.link/r/20240212144247.43744-1-guoych37@mail2.sysu.edu.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2023-06-19ASoC: rt5651: Use maple tree register cacheMark Brown
The rt5651 can only support single register read and write operations so does not benefit from block writes. This means it gets no benefit from using the rbtree register cache over the maple tree register cache so convert it to use maple trees instead, it is more modern. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20230609-asoc-rt-maple-v1-10-729c6553cdcf@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
2023-05-08ASoC: Switch i2c drivers back to use .probe()Uwe Kleine-König
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
2022-06-27ASoC: rt*: Remove now redundant non_legacy_dai_naming flagCharles Keepax
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-57-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2022-04-06ASoC: rt*: use simple i2c probe functionStephen Kitt
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/20220405130326.2107293-1-steve@sk2.org Signed-off-by: Mark Brown <broonie@kernel.org>
2021-10-04ASoC: rt5651: Use IRQF_NO_AUTOEN when requesting the IRQHans de Goede
Use the new IRQF_NO_AUTOEN flag when requesting the IRQ, rather then disabling it immediately after requesting it. This fixes a possible race where the IRQ might trigger between requesting and disabling it; and this also leads to a small code cleanup. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211003132255.31743-2-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-09-27ASoC: codecs: Fix spelling mistake "Unsupport" -> "Unsupported"Colin Ian King
There are spelling mistakes in dev_err error messages. Fix them. Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210924231003.144502-1-colin.king@canonical.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10ASoC: rt5651: remove useless assignmentPierre-Louis Bossart
cppcheck warning: sound/soc/codecs/rt5651.c:1786:13: style: Variable 'report' is assigned a value that is never used. [unreadVariable] int report = 0; ^ Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210302212527.55158-13-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10ASoC: rt5651: clarify expressionPierre-Louis Bossart
cppcheck warning: sound/soc/codecs/rt5659.c:3515:61: style: Boolean result is used in bitwise operation. Clarify expression with parentheses. [clarifyCondition] (pll_code.m_bp ? 0 : pll_code.m_code) << RT5659_PLL_M_SFT | ^ Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20210302212527.55158-12-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-03-10ASoC: rt5651: Fix dac- and adc- vol-tlv values being off by a factor of 10Hans de Goede
The adc_vol_tlv volume-control has a range from -17.625 dB to +30 dB, not -176.25 dB to + 300 dB. This wrong scale is esp. a problem in userspace apps which translate the dB scale to a linear scale. With the logarithmic dB scale being of by a factor of 10 we loose all precision in the lower area of the range when apps translate things to a linear scale. E.g. the 0 dB default, which corresponds with a value of 47 of the 0 - 127 range for the control, would be shown as 0/100 in alsa-mixer. Since the centi-dB values used in the TLV struct cannot represent the 0.375 dB step size used by these controls, change the TLV definition for them to specify a min and max value instead of min + stepsize. Note this mirrors commit 3f31f7d9b540 ("ASoC: rt5670: Fix dac- and adc- vol-tlv values being off by a factor of 10") which made the exact same change to the rt5670 codec driver. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210226143817.84287-3-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-06-22ASoC: codecs: rt*: rename to snd_soc_component_read()Kuninori Morimoto
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/87d05z4mce.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-10-01ASoC: intel: bytcr_rt5651: add null check to support_button_pressJaska Uimonen
When removing sof module the support_button_press function will oops because hp_jack pointer is not checked for NULL. So add a check to fix this. Signed-off-by: Jaska Uimonen <jaska.uimonen@intel.com> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20190927201408.925-2-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 Gleixner
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-03-18ASoC: rt5651: Add support for active-high jack detectHans de Goede
Some boards use a jack-receptacle with a switch which reports the jack-inserted status as active-high, rather then the standard active-low reporting most jacks use. This commit adds support for it. This is activated by a boolean "realtek,jack-detect-not-inverted" device-property. The not-inverted in the device-property name, rather then active-high, was chosen to keep the device-property naming consistent with the rt5640 codec driver. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-28ASoC: rt5651: Variable "ret" in function rt5651_i2c_probe() could be ↵Yizhuo
uninitialized In function rt5651_i2c_probe(), local variable "ret" could be uninitialized if function regmap_read() returns -EINVAL. However, this value is used in if statement. This is potentially unsafe. Signed-off-by: Yizhuo <yzhai003@ucr.edu> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-07ASoC: rt5651: Add support for jack detect using an external GPIOHans de Goede
Some board designs hook the jack-detect up to an external GPIO, rather then to one of the codec pins, add support for this. Figuring out which GPIO to use is pretty much board specific so I've chosen to let the machine driver pass the gpio_desc as data argument to snd_soc_component_set_jack() rather then add support for getting the GPIO to the codec driver. This keeps the codec code nice and clean. Note that using an external GPIO for this conflicts with button-press support, so this commit disables button-press support when an external GPIO is used. Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-07ASoC: rt5651: Add ACPI ID 10EC5640Hans de Goede
Some BYT platforms have a RT5651 codec while using an ACPI node with a HID of 10EC5640 to describe the coded. Add the 10EC5640 HID to the acpi_device_id list, so that the rt5651 will bind to the codec on these devices. Like the rt5645 and rt5670 drivers which also have the 10EC5640 ACPI HID in their acpi_device_id list for similar reasons, the rt5651 driver checks the codecs device-id register so that it will only bind if the codec actually is a rt5651 and it will ignore actual rt5640 codecs. Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2019-01-07ASoC: rt5651: fix boolean assignmentsPierre-Louis Bossart
Reported by Coccinelle: sound/soc/codecs/rt5651.c:750:2-17: WARNING: Assignment of bool to 0/1 sound/soc/codecs/rt5651.c:754:2-17: WARNING: Assignment of bool to 0/1 sound/soc/codecs/rt5651.c:2192:1-16: WARNING: Assignment of bool to 0/1 Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-10-25Merge tag 'sound-4.20-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Pull sound updates from Takashi Iwai: "There have been little changes in ALSA core stuff, but ASoC core still kept rolling for the continued restructuring. The rest are lots of small driver-specific changes and some minor API updates. Here are highlights: General: - Appropriate fall-through annotations everywhere - Some code cleanup in memalloc code, handling non-cacahed pages more commonly in the helper - Deployment of SNDRV_PCM_INFO_SYNC_APPLPTR flag consistently Drivers: - More HD-audio CA0132 codec improvement for supporting other Creative boards - Plumbing legacy HD-audio codecs as ASoC BE on Intel SST; this will give move support of existing HD-audio devices with DSP - A few device-specific HD-audio quirks as usual - New quirk for RME CC devices and correction for B&W PX for USB-audio - FireWire: code refactoring including devres usages ASoC Core: - Continued componentization works; it's almost done! - A bunch of new for_each_foo macros - Cleanups and fixes in DAPM code ASoC Drivers: - MCLK support for several different devices, including CS42L51, STM32 SAI, and MAX98373 - Support for Allwinner A64 CODEC analog, Intel boards with DA7219 and MAX98927, Meson AXG PDM inputs, Nuvoton NAU8822, Renesas R8A7744 and TI PCM3060" * tag 'sound-4.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (299 commits) ASoC: stm32: sai: fix master clock naming ASoC: stm32: add clock dependency for sai ALSA: hda/ca0132 - Actually fix microphone issue ASoC: sun4i-i2s: move code from startup/shutdown hooks into pm_runtime hooks ASoC: wm2000: Remove wm2000_read helper function ASoC: cs42l51: fix mclk support ASoC: wm_adsp: Log addresses as 8 digits in wm_adsp_buffer_populate ASoC: wm_adsp: Rename memory fields in wm_adsp_buffer ASoC: cs42l51: add mclk support ASoC: stm32: sai: set sai as mclk clock provider ASoC: dt-bindings: add mclk support to cs42l51 ASoC: dt-bindings: add mclk provider support to stm32 sai ASoC: soc-core: fix trivial checkpatch issues ASoC: dapm: Add support for hw_free on CODEC to CODEC links ASoC: Intel: kbl_da7219_max98927: minor white space clean up ALSA: i2c/cs8427: Fix int to char conversion ALSA: doc: Brush up the old writing-an-alsa-driver ASoC: rsnd: tidyup SSICR::SWSP for TDM ASoC: rsnd: enable TDM settings for SSI parent ASoC: pcm3168a: add hw constraint for capture channel ...
2018-09-18ASoC: remove redundant includezhong jiang
module.h already contained moduleparam.h, so it is safe to remove the redundant include. The issue is detected with the help of Coccinelle. Signed-off-by: zhong jiang <zhongjiang@huawei.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-09-07regmap: split up regmap_config.use_single_rwDavid Frey
Split regmap_config.use_single_rw into use_single_read and use_single_write. This change enables drivers of devices which only support bulk operations in one direction to use the regmap_bulk_*() functions for both directions and have their bulk operation split into single operations only when necessary. Update all struct regmap_config instances where use_single_rw==true to instead set both use_single_read and use_single_write. No attempt was made to evaluate whether it is possible to set only one of use_single_read or use_single_write. Signed-off-by: David Frey <dpfrey@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-07-19ASoC: rt5651: Add IN3 Boost volume controlHans de Goede
Add a mixer control for the IN3 Boost volume, IN3 is used for the headset mic on most devices, so this is necessary to control the headset mic volume. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-07-10ASoC: rt5651: Add button press supportHans de Goede
Enable button press detection for headsets by using the ovcd IRQ to get notified of button presses. This is modelled after (almost exactly copied from) the button press code for the rt5640 which has identical ovcd hardware. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-07-10ASoC: rt5651: Allow disabling jack-detect by calling set_jack(NULL)Hans de Goede
Allow the machine driver to disable jack-detect over a suspend/resume by calling snd_soc_component_set_jack(NULL). Note this renames rt5651_set_jack, where all the jack-enable work was done to rt5651_enable_jack_detect. This function can now no longer fail as it does not request the IRQ anymore. It can still be passed an invalid jack source, but that should never happen, so this is now logged and treated as no jack source. Cc: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-07-10ASoC: rt5651: Fix workqueue cancel vs irq free race on removeHans de Goede
On removal we must free the IRQ *before* cancelling the jack-detect work, so that the jack-detect work cannot be rescheduled by the IRQ. Before this commit we were cancelling the jack-detect work from the driver remove callback, while relying on devm to free the IRQ, which happens after the remove callback. This is the wrong order. This commit uses a devm-action to register a devm callback which cancels the work, before requesting the IRQ (devm tears things down in reverse order). This also allows us to remove the now empty remove driver callback. Cc: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-28Merge remote-tracking branch 'asoc/topic/intel' into asoc-nextMark Brown
2018-03-07ASoC: rt5651: Rewrite jack-type detectionHans de Goede
We get the insertion event before the jack is fully inserted at which point the second ring on a TRRS connector may short the 2nd ring and sleeve contacts. Testing has shown that this short-circuit may happen as late as 500ms after the insertion event, but it never lasts longer then 300ms. This commit changes the detection algorithm to require 5 identical OVCD values in a row at 100 ms intervals to fix the jack-type sometimes getting mis-detected. Tested-by: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-07ASoC: rt5651: Add rt5651_jack_inserted() helperHans de Goede
Add rt5651_jack_inserted() helper to get the jack-detect switch status, This is a preparation patch for rewriting the jack type-detection to make it more reliable. Tested-by: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-07ASoC: rt5651: Enable Platform Clock during jack-type detectHans de Goede
When using RCCLK instead of MCLK / PLL1 the OVCD status often gets stuck at its last value, which breaks jack-type detection. This commit fixes this by force-enabling the platform clock when doing jack-type detection. Tested-by: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-07ASoC: rt5651: Enable sticky mode for OVCDHans de Goede
When the mic-gnd contacts are short-circuited by a headphones plug, the hardware periodically retries if it can apply the bias-current leading to the OVCD status flip-flopping 1-0-1 with it being 0 about 10% of the time. This commit enables the sticky bit for the OVCD status to deal with this. This commit also introduces 2 helper functions to deal with the OVCD status bit, this may seem a bit overkill now, but these will also be used in future patches. Tested-by: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-07ASoC: rt5651: Allow specifying the OVCD scale-factor through a device-propertyHans de Goede
OVer-Current-Detection (OVCD) for the micbias current is used to detect if an inserted jack is a headset or headphones (mic shorted to ground). The threshold for at which current the OVCD triggers on the rt5651 is not only controlled by setting the absolute current limit, but also by setting a scale factor which applies to the limit. Testing has shown that we need to set both (depending on the board). This commit adds support for the sofar unused OVCD scale-factor register and adds support for specifying non-default values for it through the "realtek,over-current-scale-factor" device-property. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-07ASoC: rt5651: Allow specifying over-current threshold through a device-propertyHans de Goede
OVer-Current-Detection (OVCD) for the micbias current is used to detect if an inserted jack is a headset or headphones (mic shorted to ground). Some boards may need different values for the OVCD current threshold because of a resistor on the board in serial with or parallel to the jack mic contact. This commit adds support for configuring the OCVD current threshold through the "realtek,over-current-threshold-microamp" device-property. Note this commit changes the default value from 600uA to 2000uA, because testing has shown 600uA to be a poor default. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-07ASoC: rt5651: Configure jack-detect source through a device-propertyHans de Goede
Configure the jack-detect source through a device-property which can be set by code outside of the codec driver. Rather then putting platform specific DMI quirks inside the generic codec driver. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-07ASoC: rt5651: Make rt5651_apply_properties() privateHans de Goede
The idea behind exporting rt5651_apply_properties(), was for it to be used on platforms where the platform code may need to add device-properties, rather then relying only on properties set by the firmware. The platform code could then call rt5651_apply_properties() after adding properties to make sure that the codec driver was aware of the new properties. But this is not necessary, as long as we do all property parsing from the codec component-driver's probe function (or later) then the machine driver can attach properties before calling snd_soc_register_card and calling rt5651_apply_properties() for ordering reasons is not necessary. This commit makes rt5651_apply_properties() private and adds 2 comments documenting that all property parsing must be done from the codec component-driver's probe function. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-01ASoC: rt5651: Always keep OVCD enabledHans de Goede
OVCD is not only useful for jack-type detection, but is also useful to protect against over-current faults in general, so always keep OVCD enabled, instead of only enabling it for jack-type detection. Tested-by: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-01ASoC: rt5651: Only configure OVCD once at set_jack timeHans de Goede
Only configure OVCD once at set_jack time, rather then configuring it on every jack-insertion event and switch to using bit field defines instead of hardcoding a magic value. Tested-by: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-01ASoC: rt5651: Enable LDO and micbias1 supplies for jack-type detectionHans de Goede
To determine if a plugged in jack is a headset (speakers + mic) or headphones (mic contact shorted to ground) we use the micbias1 OVer Current Detect (OVCD) functionality. For this to work we need to have a micbias current to actually cause an overcurrent condition when headphones are plugged in, so jack-type detection requires both the LDO and micbias1 supplies to be on. Before this commit there were 2 issues with the handling of this: 1) The LDO supply was force-enabled twice and never disabled again even though it only needs to be forced on when doing jack-type detection 2) micbias1 was not force-enabled, and thus may be off when doing jack-type detection This commit fixes both by force-enabling the LDO and micbias1 supplies before checking for an overcurrent condition and disabling them afterwards. Note that both supplies will still get turned on normally (and OVCD will protect against overcurrent) when the micbias1 is enabled normally because the user has activated a sound stream recording from the mic. Tested-by: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-01ASoC: rt5651: Remove "JD Power" dapm supplyHans de Goede
Remove the "JD power" dapm supply which gets force-enabled once when using jack-detect and never gets disabled again. Since the PWR_JD_M bit simply needs to be always on when using jack-detect there is no need to have it tracked by dapm, instead we can simply set it to 1 once when initializing the jack-detection. Tested-by: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-01ASoC: rt5651: Only configure LDO voltage once at bootHans de Goede
Now that rt5651_set_bias_level(BIAS_OFF) no longer modifies the LDO voltage selection bits, there is no need to set them each time we move to standby. Instead configure them once at component-probe() time. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-01ASoC: rt5651: Remove programming of PWR regs before force_bias_level() callHans de Goede
Remove the setup of the PWR_ANLG1 reg which was done directly before calling snd_soc_component_force_bias_level(SND_SOC_BIAS_OFF), as the latter will override any settings done to PWR_ANLG1 immediately anyways. Tested-by: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-01ASoC: rt5651: Do not modify jd and PLL power bits from set_bias_level()Hans de Goede
rt5651_set_bias_level(BIAS_OFF) used to unconditionally clear the entire register, including the jack-detect and PLL power bits. When jack-detection support was introduced a special case for jack-detect was added which hard-codes a register value to keep both on. This commit removes the jack-detect special case, instead simply leaving these bits as is on BIAS_OFF. Tested-by: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-01ASoC: rt5651: Do not modify the LDO voltage control bits from set_bias_level()Hans de Goede
The PWR_ANLG1 reg not only contains various power on/off bits, it also contains 2 bits which select if the LDO generates 1.0, 1.1 or 1.2V. Note there is a separate on/off bit for the LDO. rt5651_set_bias_level(BIAS_OFF) used to unconditionally clear the entire register, when jack-detection support was introduced a special case for jack-detect was added which hard-codes a register value to keep the LDO voltage at 1.2 volt. This commit removes the jack-detect special case, instead simply always leaving the LDO voltage control bits as is on BIAS_OFF. Tested-by: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-01ASoC: rt5651: Fix bias_level confusionHans de Goede
The rt5651_set_bias_level() function was turning everything off at SND_SOC_BIAS_STANDBY, rather then at SND_SOC_BIAS_OFF, requiring the bias- level to be raised to SND_SOC_BIAS_PREPARE before turning anything on. This is not how the bias-levels are supposed to work, this commit fixes this by turning everything off at the SND_SOC_BIAS_OFF level and enabling the pwr-bits needed for minimum functionality at SND_SOC_BIAS_STANDBY. This fixes the minimum set of pwr-bits not getting enabled when force-enabling some dapm-supplies (e.g. for jack type detection), which raises the bias-level to standby. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-01ASoC: rt5651: Remove is_sys_clk_from_pll()Hans de Goede
is_sys_clk_from_pll() is used as a snd_soc_dapm_route.connected callback, checking RT5651_GBL_CLK to determine if the sys-clk is PLL1 and thus the PWR_PLL bit in reg PWR_ANLG2 must be set. RT5651_GBL_CLK is changed by rt5651_set_dai_sysclk(), which gets called by the pre_pmu / post_pmd functions of the "Platform Clock" dapm-supply. This creates an ordering issue, during a dapm transition first all connected() callbacks are called to build a list of supplies to enable and then the complete list is walked to enable the supplies. Since the connected() check happens before enabling any supplies, is_sys_clk_from_pll() ends up deciding if the PWR_PLL bit should be set based on the state the "Platform Clock" supply had *before* the transition. This sometimes results in PWR_PLL being off, even though *after* the transition PLL1 is configured as sys-clk. This commit removes is_sys_clk_from_pll() instead simply setting / clearing PWR_PLL in rt5651_set_dai_sysclk() based on the selected sys-clk, which fixes this and as a bonus results in a nice cleanup. Tested-by: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-01ASoC: rt5651: Add rt5651_apply_properties() helper functionHans de Goede
Move the applying of the differential input and dmic properties to a new rt5651_apply_properties() helper function. This new function can be called by platform code which attaches properties after probe() has run to apply these new properties. Note this also moves the time when we apply these properties for DT platforms from i2c-probe to snd-component-probe time, this should not result in any functional difference. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-01ASoC: rt5651: Use standard component set_jack callbackHans de Goede
Use the standard component set_jack callback instead of defining a codec private API for this. Tested-by: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-01ASoC: rt5651: Move 2 functions higher up in rt5651.cHans de Goede
Move 2 functions higher up in rt5651.c, this is a preparation patch to avoid needing forward declarations when moving over from a codec private function to the standard snd_soc_component_set_jack(). This commit purely moves these 2 functions up, not a single line is changed. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-01ASoC: rt5651: Move all jack-detect initialization to rt5651_set_jack_detectHans de Goede
Move all jack-detect initialization to rt5651_set_jack_detect. The main reason to do this is so that platform code can setup jack-detect properties after the device has been probed, which unfortunately is necessary on some platforms. This has 2 additional advantages: 1) Grouping all jack-detect init together makes it easier to follow what is happening and results in a small reduction in the number of loc. 2) Before we would register the irq handler before rt5651->hp_jack was assigned, leading to a potential NULL deref if the jack_detect work runs before the machine driver has called set_jack. Tested-by: Carlo Caione <carlo@endlessm.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2018-03-01ASoC: rt5651: Remove unused rt5651_platform_dataHans de Goede
There are no in tree users of platform-data for the rt5651 codec driver, so lets remove support for it. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mark Brown <broonie@kernel.org>