Skip to contentSkip to conversation

ASoC: rt5640: Allow configuration of LOUT to mono differential mode

PATCH In review Jarrah Gosbell 3 participants 4 messages Dec 9, 2022 – Dec 27, 2022

Subsystems (4)
lore
Share & tools
lore
#1 lore raw

PATCH 2/2 dt-bindings: sound: rt5640: Allow to describe how LOUT is wired

In reply to Jarrah Gosbell

From: Ondrej Jirman <[email protected]>

Depending on HW design, som boards may expect mono differential output on LOUT. Describe a property that enables it.

---
 Documentation/devicetree/bindings/sound/rt5640.txt | 3 +++
 1 file changed, 3 insertions(+)
Documentation/devicetree/bindings/sound/rt5640.txt +3 -0
index ff1228713f7e..0c398581d52b 100644
@@ -20,6 +20,9 @@ Optional properties:
 - realtek,in3-differential
   Boolean. Indicate MIC1/2/3 input are differential, rather than single-ended.
 
+- realtek,lout-differential
+  Boolean. Indicate LOUT output is differential, rather than stereo.
+
 - realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin.
 
 - realtek,dmic1-data-pin
Signature · 1 line
2.35.1
#0 lore raw

PATCH 1/2 ASoC: rt5640: Allow configuration of LOUT to mono differential mode

From: Ondrej Jirman <[email protected]>

LOUT output can produce either single-ended stereo signals, or mono differential signal. Some applications are wired to use LOUT in mono differential mode. Allow to configure it via device property.

---
 sound/soc/codecs/rt5640.c | 4 ++++
 sound/soc/codecs/rt5640.h | 2 ++
 2 files changed, 6 insertions(+)
sound/soc/codecs/rt5640.c +4 -0
index 0f8e6dd214b0..18e01949f20e 100644
@@ -2717,6 +2717,10 @@ static int rt5640_probe(struct snd_soc_component *component)
 		snd_soc_component_update_bits(component, RT5640_IN1_IN2,
 					      RT5640_IN_DF2, RT5640_IN_DF2);
 
+	if (device_property_read_bool(component->dev, "realtek,lout-differential"))
+		snd_soc_component_update_bits(component, RT5640_DUMMY1,
+					      RT5640_EN_LOUT_DF, RT5640_EN_LOUT_DF);
+
 	if (device_property_read_u32(component->dev, "realtek,dmic1-data-pin",
 				     &val) == 0 && val) {
 		dmic1_data_pin = val - 1;
sound/soc/codecs/rt5640.h +2 -0
index f58b88e3325b..9847a1ae01f4 100644
@@ -1978,6 +1978,8 @@
 #define RT5640_ZCD_HP_EN			(0x1 << 15)
 
 /* General Control 1 (0xfa) */
+#define RT5640_EN_LOUT_DF			(0x1 << 14)
+#define RT5640_EN_LOUT_DF_SFT			14
 #define RT5640_M_MONO_ADC_L			(0x1 << 13)
 #define RT5640_M_MONO_ADC_L_SFT			13
 #define RT5640_M_MONO_ADC_R			(0x1 << 12)
Signature · 1 line
2.35.1
Acked-by on v1 2/2
#2 lore raw

Re: [PATCH 2/2] dt-bindings: sound: rt5640: Allow to describe how LOUT is wired

In reply to Jarrah Gosbell
Quoted 10 lines · Jarrah Gosbell

From: Ondrej Jirman <[email protected]>

Depending on HW design, som boards may expect mono differential output on LOUT. Describe a property that enables it.

---
 Documentation/devicetree/bindings/sound/rt5640.txt | 3 +++
 1 file changed, 3 insertions(+)

Best regards,
Krzysztof

maintainer
#3 lore raw
In reply to Jarrah Gosbell
Quoted 5 lines · Jarrah Gosbell

LOUT output can produce either single-ended stereo signals, or mono differential signal. Some applications are wired to use LOUT in mono differential mode. Allow to configure it via device property.

Applied to

https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/2] ASoC: rt5640: Allow configuration of LOUT to mono differential mode

      commit: 44b54f54b41d36e8a2302a2c18a65268751c9067
[2/2] dt-bindings: sound: rt5640: Allow to describe how LOUT is wired
      commit: d8510532ccf3bc12e2b1c0c285d4b61d4b713e1a

All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying to this mail.

Thanks,
Mark