Re: [PATCH v2 1/3] dt-bindings: power: rpmpd: Add MSM8974 power domains
On Sat, Feb 10, 2024 at 05:38:56PM +0100, Luca Weiss wrote: > Add the compatibles and indexes for the rpmpd in MSM8974, both with the > standard PM8841+PM8941 PMICs but also devices found with PMA8084. > > Signed-off-by: Luca Weiss > --- > Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 2 ++ > include/dt-bindings/power/qcom-rpmpd.h | 7 +++ > 2 files changed, 9 insertions(+) > > diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml > b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml > index 2ff246cf8b81..929b7ef9c1bc 100644 > --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml > +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml > @@ -24,6 +24,8 @@ properties: >- qcom,msm8917-rpmpd >- qcom,msm8939-rpmpd >- qcom,msm8953-rpmpd > + - qcom,msm8974-rpmpd > + - qcom,msm8974pro-pma8084-rpmpd >- qcom,msm8976-rpmpd >- qcom,msm8994-rpmpd >- qcom,msm8996-rpmpd This is maybe more something for the DT reviewers to decide but I wonder if it is a bit confusing/misleading to describe one particular PMIC with a generic compatible, and the other with a more specific one. Perhaps it would be clearer to include the PMIC name in both compatibles, i.e. "qcom,msm8974-pm8941-rpmpd" instead of "qcom,msm8974-rpmpd". The "qcom,msm8974-rpmpd" compatible could be maybe added as fallback. While it wouldn't be used for matching in the (Linux) driver the DT binding itself *is* "compatible" between the two PMICs because they both have the same power domain indexes. i.e. compatible = "qcom,msm8974-pm8941-rpmpd", "qcom,msm8974-rpmpd"; compatible = "qcom,msm8974pro-pma8084-rpmpd", "qcom,msm8974-rpmpd"; Thanks, Stephan
Re: [PATCH 1/4] dt-bindings: remoteproc: qcom: wcnss: Add WCN3680B compatible
On Sat, Nov 25, 2023 at 01:25:22PM +0100, Luca Weiss wrote: > On Montag, 16. Oktober 2023 16:44:28 CET Stephan Gerhold wrote: > > On Mon, Oct 16, 2023 at 03:16:14PM +0200, Loic Poulain wrote: > > > On Mon, 16 Oct 2023 at 07:35, Krzysztof Kozlowski > > > > > > wrote: > > > > On 15/10/2023 22:03, Luca Weiss wrote: > > > > > Add a compatible for the iris subnode in the WCNSS PIL. > > > > > > > > > > Signed-off-by: Luca Weiss > > > > > --- > > > > > > > > > > Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml | 1 > > > > > + > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > diff --git > > > > > a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml > > > > > b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml > > > > > index 45eb42bd3c2c..0e5e0b7a0610 100644 > > > > > --- a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml > > > > > +++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml > > > > > > > > > > @@ -111,6 +111,7 @@ properties: > > > > >- qcom,wcn3660 > > > > >- qcom,wcn3660b > > > > >- qcom,wcn3680 > > > > > > > > > > + - qcom,wcn3680b > > > > > > > > Looks like this should be made as compatible with qcom,wcn3680 (so with > > > > fallback). > > > > > > Yes, agree, let's do a regular fallback as there is nothing 'b' > > > specific in the driver: > > > `compatible = "qcom,wcn3680b", "qcom,wcn3680";` > > > > > > And yes, we should also have done that for qcom,wcn3660b... > > > > I don't think this would have worked properly for qcom,wcn3660b: > > > > - It's not compatible with "qcom,wcn3660", because they have different > >regulator voltage requirements. wcn3660(a?) needs vddpa with > >2.9-3.0V, but wcn3660b needs 3.3V. That's why wcn3660b uses the > >wcn3680_data in qcom_wcnss.iris.c. Otherwise if you would run an > >older kernel that knows "qcom,wcn3660" but not "qcom,wcn3660b" it > >would apply the wrong voltage. > > > > - It's not compatible with "qcom,wcn3680" either because that is used > >as indication if 802.11ac is supported (wcn3660b doesn't). > > > > The main question here is: What does the current "qcom,wcn3680" > > compatible actually represent? It's defined with vddpa = 3.3V in the > > driver, which would suggest that: > > > > 1. It's actually meant to represent WCN3680B, which needs 3.3V vddpa > > like WCN3660B, or > > > > 2. WCN3680(A?) has different requirements than WCN3660(A?) and also > > needs 3.3V vddpa. But then what is the difference between > > WCN3680(A?) and WCN3680B? Is there even a variant without ...B? > > > > There is public documentation for WCN3660B and WCN3680B but the non-B > > variants are shrouded in mystery. > > Hi Stephan (and everyone), > > Do you have a suggestion how to move this patchset forward? Is the fallback > compatible that was suggested okay for the wcn3680b situation? > > compatible = "qcom,wcn3680b", "qcom,wcn3680"; > > If so, I'll make v2 with that implemented. > Personally, I would just go with what exists already and use the existing "qcom,wcn3680" compatible as-is. No one has provided evidence that there is actually something like a WCN3680(A), without a 'B' at the end. Also, all existing users of the "qcom,wcn3680" compatible upstream actually seem to refer to WCN3680B (I'm quite sure apq8039-t2 has WCN3680B, MSM8974 isn't entirely clear but iirc you mentioned there was some schematic of a MSM8974 device which says WCN3680B as well). It would be nice to have the compatible perfectly correct and complete, but I see no point to extend it with additional information that we can't properly verify. Or do you actually need a different compatible to customize something in the driver? Thanks, Stephan
[PATCH v2 08/14] arm64: dts: qcom: msm8916-alcatel-idol347: Add sound and modem
From: Vincent Knecht
Enable sound and modem for the Alcatel Idol 3 (4.7"). The setup is
similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Microphones via digital/analog codec in MSM8916/PM8916
- WWAN Internet via BAM-DMUX
except:
- Stereo NXP TFA9890 codecs for speakers on Quaternary MI2S
- These are also used as earpieces at the top/bottom.
- Asahi Kasei AK4375 headphone codec on Secondary MI2S
-> Primary MI2S is not used for playback
Signed-off-by: Vincent Knecht
[Stephan: Minor refactoring, add consistent commit message]
Signed-off-by: Stephan Gerhold
---
There are some trivial conflicts unless
https://lore.kernel.org/linux-arm-msm/20230921-msm8916-rmem-fixups-v1-3-34d2b6e72...@gerhold.net/
is applied first. But given that there are important fixups for the
dynamic reserved memory changes in that series it should preferably
get applied before this one anyway.
---
.../boot/dts/qcom/msm8916-alcatel-idol347.dts | 171 +
1 file changed, 171 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
b/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
index fade93c55299..3459145516a1 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
@@ -3,6 +3,8 @@
/dts-v1/;
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
@@ -22,6 +24,19 @@ chosen {
stdout-path = "serial0";
};
+ reserved-memory {
+ /delete-node/ reserved@8668;
+ /delete-node/ rmtfs@8670;
+
+ rmtfs: rmtfs@8668 {
+ compatible = "qcom,rmtfs-mem";
+ reg = <0x0 0x8668 0x0 0x16>;
+ no-map;
+
+ qcom,client-id = <1>;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -50,6 +65,17 @@ led-0 {
};
};
+ reg_headphones_avdd: regulator-headphones-avdd {
+ compatible = "regulator-fixed";
+ regulator-name = "headphones_avdd";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ gpio = < 121 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ pinctrl-0 = <_avdd_default>;
+ pinctrl-names = "default";
+ };
+
usb_id: usb-id {
compatible = "linux,extcon-usb-gpio";
id-gpios = < 69 GPIO_ACTIVE_HIGH>;
@@ -58,6 +84,43 @@ usb_id: usb-id {
};
};
+_i2c3 {
+ status = "okay";
+
+ headphones: audio-codec@10 {
+ compatible = "asahi-kasei,ak4375";
+ reg = <0x10>;
+ avdd-supply = <_headphones_avdd>;
+ tvdd-supply = <_l6>;
+ pdn-gpios = < 114 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <_pdn_default>;
+ pinctrl-names = "default";
+ #sound-dai-cells = <0>;
+ };
+
+ speaker_codec_top: audio-codec@34 {
+ compatible = "nxp,tfa9897";
+ reg = <0x34>;
+ vddd-supply = <_l6>;
+ rcv-gpios = < 50 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <_top_default>;
+ pinctrl-names = "default";
+ sound-name-prefix = "Speaker Top";
+ #sound-dai-cells = <0>;
+ };
+
+ speaker_codec_bottom: audio-codec@36 {
+ compatible = "nxp,tfa9897";
+ reg = <0x36>;
+ vddd-supply = <_l6>;
+ rcv-gpios = < 111 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <_bottom_default>;
+ pinctrl-names = "default";
+ sound-name-prefix = "Speaker Bottom";
+ #sound-dai-cells = <0>;
+ };
+};
+
_i2c4 {
status = "okay";
@@ -153,6 +216,18 @@ _uart2 {
status = "okay";
};
+_mem {
+ reg = <0x0 0x8680 0x0 0x500>;
+};
+
+_codec {
+ qcom,micbias1-ext-cap;
+ qcom,micbias-lvl = <2800>;
+ qcom,mbhc-vthreshold-low = <75 100 120 180 500>;
+ qcom,mbhc-vthreshold-high = <75 100 120 180 500>;
+ qcom,hphl-jack-type-normally-open;
+};
+
_resin {
status = "okay";
linux,code = ;
@@ -169,6 +244,17 @@ _vib {
status = "okay";
};
+ {
+ dai@18 {
+ reg = ;
+ qcom,sd-lines = <0>;
+ };
+ dai@22 {
+ reg = ;
+ qcom,sd-lines = <0>;
[PATCH v2 10/14] arm64: dts: qcom: msm8916-longcheer-l8150: Add sound and modem
From: Nikita Travkin
Enable sound and modem for the Longcheer L8150 (e.g. Wileyfox Swift).
The setup is similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Speaker/earpiece/headphones/microphones via digital/analog codec
in MSM8916/PM8916
- Audio jack detection via analog codec in PM8916
- WWAN Internet via BAM-DMUX
except:
- The mpss firmware region must be relocated to a different address.
This is because the wcnss firmware is not relocatable for some
reason. The mpss firmware is too large to avoid overlap with wcnss
when placed at the default address (0x8680).
Surprisingly the vendor kernel does not handle this. The firmware
regions end up overlapping there and somehow this does not explode.
We try to handle this more safely by relocating the mpss region to
the first higher address that is working correctly: 0x8e80.
Signed-off-by: Nikita Travkin
Co-developed-by: Stephan Gerhold
Signed-off-by: Stephan Gerhold
---
.../boot/dts/qcom/msm8916-longcheer-l8150.dts | 31 +++---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
index 47d1c5cb13f4..37fa55166918 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
@@ -3,6 +3,8 @@
/dts-v1/;
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
@@ -25,17 +27,26 @@ chosen {
/*
* For some reason, the signed wcnss firmware is not relocatable.
-* It must be loaded at 0x8b60. All other firmware is relocatable,
-* so place wcnss at the fixed address and then all other firmware
-* regions will be automatically allocated at a fitting place.
+* It must be loaded at 0x8b60. Unfortunately, this also means that
+* mpss_mem does not fit when loaded to the typical address at
0x8680.
+*
+* Load wcnss_mem to the fixed address and relocate mpss_mem to the next
+* working higher address. For some reason the modem firmware does not
+* boot when placed at 0x8a80 to 0x8e80.
*/
reserved-memory {
+ /delete-node/ mpss@8680;
/delete-node/ wcnss;
wcnss_mem: wcnss@8b60 {
reg = <0x0 0x8b60 0x0 0x60>;
no-map;
};
+
+ mpss_mem: mpss@8e80 {
+ reg = <0x0 0x8e80 0x0 0x500>;
+ no-map;
+ };
};
gpio-keys {
@@ -225,6 +236,13 @@ _uart2 {
status = "okay";
};
+_codec {
+ qcom,micbias-lvl = <2800>;
+ qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
+ qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
+ qcom,hphl-jack-type-normally-open;
+};
+
_resin {
status = "okay";
linux,code = ;
@@ -254,6 +272,13 @@ _2 {
non-removable;
};
+ {
+ audio-routing =
+ "AMIC1", "MIC BIAS Internal1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS Internal3";
+};
+
{
status = "okay";
dr_mode = "peripheral";
--
2.42.0
[PATCH v2 09/14] arm64: dts: qcom: msm8916-asus-z00l: Add sound and modem
From: "J.R. Divya Antony"
Enable sound and modem for the ASUS Zenfone 2 Laser. The setup is
similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Speakear/earpiece/headphones/microphones via digital/analog codec
in MSM8916/PM8916
- Audio jack detection via analog codec in PM8916
- WWAN Internet via BAM-DMUX
Signed-off-by: "J.R. Divya Antony"
[Stephan: rebase and simplify, add consistent commit message]
Reviewed-by: Konrad Dybcio
Signed-off-by: Stephan Gerhold
---
arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts
b/arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts
index a8be6ff66893..77618c7374df 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts
@@ -3,6 +3,8 @@
/dts-v1/;
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
@@ -130,6 +132,18 @@ _uart2 {
status = "okay";
};
+_mem {
+ reg = <0x0 0x8680 0x0 0x550>;
+};
+
+_codec {
+ qcom,micbias-lvl = <2800>;
+ qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
+ qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
+ qcom,micbias1-ext-cap;
+ qcom,hphl-jack-type-normally-open;
+};
+
_rpm_regulators {
pm8916_l17: l17 {
regulator-min-microvolt = <285>;
@@ -151,6 +165,13 @@ _2 {
cd-gpios = < 38 GPIO_ACTIVE_LOW>;
};
+ {
+ audio-routing =
+ "AMIC1", "MIC BIAS External1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS External1";
+};
+
{
status = "okay";
extcon = <_id>, <_id>;
--
2.42.0
[PATCH v2 11/14] arm64: dts: qcom: msm8916-longcheer-l8910: Add sound and modem
From: Jonathan Albrieux
Enable sound and modem for the Longcheer L8910 (BQ Aquaris X5).
The setup is similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Earpiece/headphones/microphones via digital/analog codec in
MSM8916/PM8916
- Audio jack detection via analog codec in PM8916
- WWAN Internet via BAM-DMUX
except:
- Awinic AW8738 connected to HPH_R (headphones) output of the analog
codec. Note that unlike for wingtech-wt88047 there is no analog
switch that would allow disabling output via the headphone jack
when the speaker is enabled.
Signed-off-by: Jonathan Albrieux
Co-developed-by: Stephan Gerhold
Reviewed-by: Konrad Dybcio
Signed-off-by: Stephan Gerhold
---
.../boot/dts/qcom/msm8916-longcheer-l8910.dts | 52 ++
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
index 41cadb906b98..e64bf687ca7d 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
@@ -3,6 +3,8 @@
/dts-v1/;
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
@@ -22,6 +24,16 @@ chosen {
stdout-path = "serial0";
};
+ speaker_amp: audio-amplifier {
+ compatible = "awinic,aw8738";
+ mode-gpios = < 114 GPIO_ACTIVE_HIGH>;
+ awinic,mode = <5>;
+ sound-name-prefix = "Speaker Amp";
+
+ pinctrl-0 = <_ext_pa_default>;
+ pinctrl-names = "default";
+ };
+
flash-led-controller {
compatible = "ocs,ocp8110";
enable-gpios = < 49 GPIO_ACTIVE_HIGH>;
@@ -107,6 +119,17 @@ _uart2 {
status = "okay";
};
+_mem {
+ reg = <0x0 0x8680 0x0 0x500>;
+};
+
+_codec {
+ qcom,micbias-lvl = <2800>;
+ qcom,mbhc-vthreshold-low = <75 100 120 180 500>;
+ qcom,mbhc-vthreshold-high = <75 100 120 180 500>;
+ qcom,hphl-jack-type-normally-open;
+};
+
_resin {
status = "okay";
linux,code = ;
@@ -137,6 +160,28 @@ _2 {
cd-gpios = < 38 GPIO_ACTIVE_LOW>;
};
+ {
+ /*
+* Provide widgets/pin-switches to allow enabling speaker separately.
+* The hardware does not provide a way to disable the output via the
+* headphone jack when the speaker is enabled.
+*/
+ model = "bq-paella";
+ widgets =
+ "Speaker", "Speaker",
+ "Headphone", "Headphones";
+ pin-switches = "Speaker";
+ audio-routing =
+ "Speaker", "Speaker Amp OUT",
+ "Speaker Amp IN", "HPH_R",
+ "Headphones", "HPH_L",
+ "Headphones", "HPH_R",
+ "AMIC1", "MIC BIAS External1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS External1";
+ aux-devs = <_amp>;
+};
+
{
status = "okay";
extcon = <_id>, <_id>;
@@ -205,6 +250,13 @@ sdc2_cd_default: sdc2-cd-default-state {
bias-disable;
};
+ spk_ext_pa_default: spk-ext-pa-default-state {
+ pins = "gpio114";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
usb_id_default: usb-id-default-state {
pins = "gpio110";
function = "gpio";
--
2.42.0
[PATCH v2 13/14] arm64: dts: qcom: msm8916-samsung-j5: Add sound and modem
From: "Lin, Meng-Bo"
Enable sound and modem for the Samsung J5 smartphones. The setup is
similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Speaker/earpiece/headphones/microphones via digital/analog codec
in MSM8916/PM8916
- WWAN Internet via BAM-DMUX
except:
- There is no secondary microphone, so a different "model" is used to
differentiate that in the UCM configuration.
- Samsung-specific audio jack detection (not supported yet)
Co-developed-by: Markuss Broks
Signed-off-by: Markuss Broks
Signed-off-by: "Lin, Meng-Bo"
[Stephan: Add consistent commit message]
Signed-off-by: Stephan Gerhold
---
arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi | 14 ++
arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts | 4
2 files changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi
b/arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi
index fe59be3505fe..5ca2ada266f4 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi
@@ -1,6 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
@@ -135,6 +137,10 @@ _uart2 {
status = "okay";
};
+_mem {
+ reg = <0x0 0x8680 0x0 0x580>;
+};
+
_resin {
status = "okay";
linux,code = ;
@@ -154,6 +160,14 @@ _2 {
cd-gpios = < 38 GPIO_ACTIVE_LOW>;
};
+ {
+ model = "msm8916-1mic";
+ audio-routing =
+ "AMIC1", "MIC BIAS External1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS External1";
+};
+
{
extcon = <>, <>;
status = "okay";
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts
b/arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts
index 58c2f5a70e78..ba8650971d6a 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts
@@ -19,6 +19,10 @@ _i2c5 {
status = "disabled";
};
+_codec {
+ qcom,micbias1-ext-cap;
+};
+
{
/* FIXME: Missing sm5703-mfd driver to power up vdd-supply */
};
--
2.42.0
[PATCH v2 14/14] arm64: dts: qcom: msm8939-samsung-a7: Add sound and modem
From: "Lin, Meng-Bo"
Enable sound and modem for the Samsung A7. The setup is similar to most
MSM8916 devices, i.e.:
- QDSP6 audio
- Earpiece/headphones/microphones via digital/analog codec in
MSM8916/PM8916
- WWAN Internet via BAM-DMUX
except for the same differences as the MSM8916-based Samsung A2015
devices:
- NXP TFA9895 codec for speaker on Quaternary MI2S
- Samsung-specific audio jack detection (not supported yet)
Signed-off-by: "Lin, Meng-Bo"
[Stephan: Add consistent commit message, minor refactoring]
Signed-off-by: Stephan Gerhold
---
arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts | 70 +
1 file changed, 70 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts
b/arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts
index fccd8fec8b8f..aa6c39482a2f 100644
--- a/arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts
+++ b/arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts
@@ -3,10 +3,12 @@
/dts-v1/;
#include "msm8939-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
#include
#include
#include
+#include
/ {
model = "Samsung Galaxy A7 (2015)";
@@ -287,6 +289,18 @@ muic: extcon@25 {
};
};
+_i2c2 {
+ status = "okay";
+
+ speaker_codec: audio-codec@34 {
+ compatible = "nxp,tfa9895";
+ reg = <0x34>;
+ vddd-supply = <_l5>;
+ sound-name-prefix = "Speaker";
+ #sound-dai-cells = <0>;
+ };
+};
+
_i2c5 {
status = "okay";
@@ -309,6 +323,29 @@ _uart2 {
status = "okay";
};
+/*
+ * For some reason the speaker amplifier is connected to the second SD line
+ * (MI2S_2_D1) instead of the first (MI2S_2_D0). This must be configured in the
+ * device tree, otherwise audio will seemingly play fine on the wrong SD line
+ * but the speaker stays silent.
+ *
+ * When routing audio via QDSP6 (the default) the node is reserved and
+ * the definitions from are used. When the modem is disabled audio
can
+ * be alternatively routed directly to the LPASS hardware with reduced latency.
+ * The definitions for are here for completeness to simplify changing
the
+ * setup with minor changes to the DT (either manually or with DT overlays).
+ */
+ {
+ dai-link@3 {
+ reg = ;
+ qcom,playback-sd-lines = <1>;
+ };
+};
+
+_mem {
+ reg = <0x0 0x8680 0x0 0x580>;
+};
+
_resin {
linux,code = ;
status = "okay";
@@ -321,6 +358,13 @@ pm8916_l17: l17 {
};
};
+ {
+ dai@22 {
+ reg = ;
+ qcom,sd-lines = <1>;
+ };
+};
+
_1 {
status = "okay";
};
@@ -335,6 +379,32 @@ _2 {
status = "okay";
};
+ {
+ model = "samsung-a2015";
+ audio-routing =
+ "AMIC1", "MIC BIAS External1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS External1";
+
+ pinctrl-0 = <_pdm_default _mi2s_default>;
+ pinctrl-1 = <_pdm_sleep _mi2s_sleep>;
+ pinctrl-names = "default", "sleep";
+
+ sound_link_backend2: backend2-dai-link {
+ link-name = "Quaternary MI2S";
+
+ cpu {
+ sound-dai = < QUATERNARY_MI2S_RX>;
+ };
+ platform {
+ sound-dai = <>;
+ };
+ codec {
+ sound-dai = <_codec>;
+ };
+ };
+};
+
{
extcon = <>, <>;
status = "okay";
--
2.42.0
[PATCH v2 12/14] arm64: dts: qcom: msm8916-samsung-gt5: Add sound and modem
From: Jasper Korten
Enable sound and modem for the Samsung Galaxy Tab A 2015 tablets.
The setup is similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Headphones/microphones via digital/analog codec in
MSM8916/PM8916. Earpiece exists on samsung-gt58 only.
- WWAN Internet via BAM-DMUX
except:
- gt510: Stereo Maxim MAX98357A codecs for speaker on Quaternary MI2S
- gt58: Mono NXP TFA9895 codec for speaker on Quaternary MI2S
- For some reason connected to GPIOs where no hardware I2C
controller is available -> need to use i2c-gpio
- Samsung-specific audio jack detection (not supported yet)
Signed-off-by: Jasper Korten
Co-developed-by: Siddharth Manthan
Signed-off-by: Siddharth Manthan
Co-developed-by: Nikita Travkin
Signed-off-by: Nikita Travkin
[Stephan: Add consistent commit message, minor refactoring]
Signed-off-by: Stephan Gerhold
---
.../boot/dts/qcom/msm8916-samsung-gt5-common.dtsi | 54 ++
arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts | 22 +
arch/arm64/boot/dts/qcom/msm8916-samsung-gt58.dts | 42 +
3 files changed, 118 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi
b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi
index 6a16eb5ce07b..fbd2caf405d5 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi
@@ -3,9 +3,12 @@
/dts-v1/;
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
+#include
/ {
aliases {
@@ -116,6 +119,29 @@ _uart2 {
status = "okay";
};
+/*
+ * For some reason the speaker amplifier is connected to the second SD line
+ * (MI2S_2_D1) instead of the first (MI2S_2_D0). This must be configured in the
+ * device tree, otherwise audio will seemingly play fine on the wrong SD line
+ * but the speaker stays silent.
+ *
+ * When routing audio via QDSP6 (the default) the node is reserved and
+ * the definitions from are used. When the modem is disabled audio
can
+ * be alternatively routed directly to the LPASS hardware with reduced latency.
+ * The definitions for are here for completeness to simplify changing
the
+ * setup with minor changes to the DT (either manually or with DT overlays).
+ */
+ {
+ dai-link@3 {
+ reg = ;
+ qcom,playback-sd-lines = <1>;
+ };
+};
+
+_mem {
+ reg = <0x0 0x8680 0x0 0x540>;
+};
+
_resin {
linux,code = ;
status = "okay";
@@ -133,6 +159,13 @@ _usbin {
status = "okay";
};
+ {
+ dai@22 {
+ reg = ;
+ qcom,sd-lines = <1>;
+ };
+};
+
_1 {
status = "okay";
};
@@ -147,6 +180,27 @@ _2 {
status = "okay";
};
+ {
+ audio-routing =
+ "AMIC1", "MIC BIAS External1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS External1";
+
+ sound_link_backend2: backend2-dai-link {
+ link-name = "Quaternary MI2S";
+
+ cpu {
+ sound-dai = < QUATERNARY_MI2S_RX>;
+ };
+ platform {
+ sound-dai = <>;
+ };
+ codec {
+ sound-dai = <_codec>;
+ };
+ };
+};
+
{
dr_mode = "peripheral";
extcon = <_usbin>;
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts
b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts
index c3f1acc55078..5b34529b816c 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts
@@ -9,6 +9,14 @@ / {
compatible = "samsung,gt510", "qcom,msm8916";
chassis-type = "tablet";
+ speaker_codec: audio-codec {
+ compatible = "maxim,max98357a";
+ sdmode-gpios = < 55 GPIO_ACTIVE_HIGH>;
+ #sound-dai-cells = <0>;
+ pinctrl-0 = <_sdmode_default>;
+ pinctrl-names = "default";
+ };
+
clk_pwm: pwm {
compatible = "clk-pwm";
#pwm-cells = <2>;
@@ -146,7 +154,21 @@ _dsi0_out {
remote-endpoint = <_in>;
};
+ {
+ model = "samsung-gt510";
+ pinctrl-0 = <_pdm_default _mi2s_default>;
+ pinctrl-1 = <_pdm_sleep _mi2s_sleep>;
+ pinctrl-names = "default", "sleep";
+};
+
{
+ audio_sdmode_default: audio-sdmode-default-state {
+ pins = "gpio55";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-di
[PATCH v2 07/14] arm64: dts: qcom: msm8916-wingtech-wt88047: Add sound and modem
Enable sound and modem for the Xiaomi Redmi 2. The setup
is similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Earpiece/headphones/microphones via digital/analog codec in
MSM8916/PM8916
- Audio jack detection via analog codec in PM8916
- WWAN Internet via BAM-DMUX
except:
- Speaker amplifier is connected to HPH_R (headphones) output of the
analog codec. There is a separate analog switch that allows disabling
playback via the headphone jack.
Reviewed-by: Konrad Dybcio
Signed-off-by: Stephan Gerhold
---
.../boot/dts/qcom/msm8916-wingtech-wt88047.dts | 74 ++
1 file changed, 74 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dts
b/arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dts
index 419f35c1fc92..d4b88c787e59 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dts
@@ -6,6 +6,8 @@
/dts-v1/;
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
@@ -25,6 +27,28 @@ chosen {
stdout-path = "serial0";
};
+ speaker_amp: audio-amplifier {
+ compatible = "simple-audio-amplifier";
+ enable-gpios = < 117 GPIO_ACTIVE_HIGH>;
+ sound-name-prefix = "Speaker Amp";
+ pinctrl-0 = <_amp_default>;
+ pinctrl-names = "default";
+ };
+
+ /*
+* This seems to be actually an analog switch that either routes audio
+* to the headphone jack or nowhere. Given that we need to enable a GPIO
+* to get sound on headphones, modelling it as simple-audio-amplifier
+* works just fine.
+*/
+ headphones_switch: audio-switch {
+ compatible = "simple-audio-amplifier";
+ enable-gpios = < 8 GPIO_ACTIVE_HIGH>;
+ sound-name-prefix = "Headphones Switch";
+ pinctrl-0 = <_switch_default>;
+ pinctrl-names = "default";
+ };
+
flash-led-controller {
compatible = "ocs,ocp8110";
enable-gpios = < 31 GPIO_ACTIVE_HIGH>;
@@ -146,6 +170,18 @@ _uart2 {
status = "okay";
};
+_mem {
+ reg = <0x0 0x8680 0x0 0x510>;
+};
+
+_codec {
+ qcom,micbias1-ext-cap;
+ qcom,micbias-lvl = <2800>;
+ qcom,mbhc-vthreshold-low = <75 100 120 180 500>;
+ qcom,mbhc-vthreshold-high = <75 100 120 180 500>;
+ qcom,hphl-jack-type-normally-open;
+};
+
_resin {
status = "okay";
linux,code = ;
@@ -180,6 +216,30 @@ _2 {
non-removable;
};
+ {
+ /*
+* Provide widgets/pin-switches to allow enabling speaker and headphones
+* separately. Both are routed via the HPH_L/HPH_R pins of the codec.
+*/
+ model = "wt88047";
+ widgets =
+ "Speaker", "Speaker",
+ "Headphone", "Headphones";
+ pin-switches = "Speaker", "Headphones";
+ audio-routing =
+ "Speaker", "Speaker Amp OUTL",
+ "Speaker", "Speaker Amp OUTR",
+ "Speaker Amp INL", "HPH_R",
+ "Speaker Amp INR", "HPH_R",
+ "Headphones", "Headphones Switch OUTL",
+ "Headphones", "Headphones Switch OUTR",
+ "Headphones Switch INL", "HPH_L",
+ "Headphones Switch INR", "HPH_R",
+ "AMIC1", "MIC BIAS External1",
+ "AMIC2", "MIC BIAS Internal2";
+ aux-devs = <_amp>, <_switch>;
+};
+
{
status = "okay";
extcon = <_id>, <_id>;
@@ -226,6 +286,13 @@ gpio_keys_default: gpio-keys-default-state {
bias-pull-up;
};
+ headphones_switch_default: headphones-switch-default-state {
+ pins = "gpio8";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
imu_default: imu-default-state {
pins = "gpio115";
function = "gpio";
@@ -234,6 +301,13 @@ imu_default: imu-default-state {
bias-disable;
};
+ speaker_amp_default: speaker-amp-default-state {
+ pins = "gpio117";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
touchscreen_default: touchscreen-default-state {
touchscreen-pins {
pins = "gpio13";
--
2.42.0
[PATCH v2 03/14] arm64: dts: qcom: msm8939: Add QDSP6
MSM8939 does not have a dedicated ADSP. Instead, the audio services via
APR are also implemented by the modem DSP. Audio can be either routed
via the modem DSP (necessary for voice call audio etc) or directly sent
to the LPASS hardware (currently used by DB410c). Bypassing QDSP6 audio
is only possible with special firmware (on DB410c) or when the modem
DSP is completely disabled.
Add the typical nodes for QDSP6 audio to msm8939.dtsi. The apr node is
disabled by default to avoid changing behavior for devices like
apq8039-t2 that use the bypassed audio path.
Signed-off-by: Stephan Gerhold
---
arch/arm64/boot/dts/qcom/msm8939.dtsi | 49 +++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi
b/arch/arm64/boot/dts/qcom/msm8939.dtsi
index 65c68e0e88d5..95610a32750a 100644
--- a/arch/arm64/boot/dts/qcom/msm8939.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
/ {
@@ -1615,6 +1616,54 @@ smd-edge {
qcom,remote-pid = <1>;
label = "hexagon";
+
+ apr: apr {
+ compatible = "qcom,apr-v2";
+ qcom,smd-channels = "apr_audio_svc";
+ qcom,domain = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ q6core: service@3 {
+ compatible = "qcom,q6core";
+ reg = ;
+ };
+
+ q6afe: service@4 {
+ compatible = "qcom,q6afe";
+ reg = ;
+
+ q6afedai: dais {
+ compatible =
"qcom,q6afe-dais";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+ };
+ };
+
+ q6asm: service@7 {
+ compatible = "qcom,q6asm";
+ reg = ;
+
+ q6asmdai: dais {
+ compatible =
"qcom,q6asm-dais";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+ };
+ };
+
+ q6adm: service@8 {
+ compatible = "qcom,q6adm";
+ reg = ;
+
+ q6routing: routing {
+ compatible =
"qcom,q6adm-routing";
+ #sound-dai-cells = <0>;
+ };
+ };
+ };
};
};
--
2.42.0
[PATCH v2 06/14] arm64: dts: qcom: msm8916-samsung-serranove: Add sound and modem
Enable sound and modem for the Samsung S4 Mini Value Edition. The setup
is similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Speaker/earpiece/headphones/microphones via digital/analog codec in
MSM8916/PM8916
- WWAN Internet via BAM-DMUX
except:
- Samsung-specific audio jack detection (not supported yet)
Signed-off-by: Stephan Gerhold
---
arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts
b/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts
index 68da2a2d3077..5ce8f1350abc 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts
@@ -6,6 +6,8 @@
/dts-v1/;
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
@@ -319,6 +321,10 @@ _uart2 {
status = "okay";
};
+_mem {
+ reg = <0x0 0x8680 0x0 0x5a0>;
+};
+
_resin {
status = "okay";
linux,code = ;
@@ -350,6 +356,13 @@ _2 {
no-1-8-v;
};
+ {
+ audio-routing =
+ "AMIC1", "MIC BIAS External1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS External1";
+};
+
{
status = "okay";
extcon = <>, <>;
--
2.42.0
[PATCH v2 04/14] arm64: dts: qcom: msm8916: Add common msm8916-modem-qdsp6.dtsi
Most MSM8916/MSM8939 devices use very similar setups for the modem,
because most of the device-specific details are abstracted by the modem
firmware. There are several definitions (status switches, DAI links
etc) that will be exactly the same for every board.
Introduce a common msm8916-modem-qdsp6.dtsi include that can be used to
simplify enabling the modem for such devices. By default the
digital/analog codec in the SoC/PMIC is used, but boards can define
additional codecs by adding additional backend DAI links.
Signed-off-by: Stephan Gerhold
---
arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi | 148 ++
1 file changed, 148 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi
b/arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi
new file mode 100644
index ..039961622633
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause)
+/*
+ * msm8916-modem-qdsp6.dtsi describes the typical modem setup on MSM8916
devices
+ * (or similar SoCs) with audio routed via the QDSP6 services provided by the
+ * modem firmware. The digital/analog codec in the SoC/PMIC is used by default,
+ * but boards can define additional codecs by adding additional backend DAI
links.
+ */
+
+#include
+#include
+
+ {
+ status = "okay";
+};
+
+_dmux {
+ status = "okay";
+};
+
+_dmux_dma {
+ status = "okay";
+};
+
+ {
+ status = "reserved"; /* Controlled by QDSP6 */
+};
+
+_codec {
+ status = "okay";
+};
+
+_mem {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_mem {
+ status = "okay";
+};
+
+_codec {
+ status = "okay";
+};
+
+ {
+ dai@16 {
+ reg = ;
+ qcom,sd-lines = <0 1>;
+ };
+ dai@20 {
+ reg = ;
+ qcom,sd-lines = <0 1>;
+ };
+};
+
+ {
+ dai@0 {
+ reg = <0>;
+ direction = ;
+ };
+ dai@1 {
+ reg = <1>;
+ direction = ;
+ };
+ dai@2 {
+ reg = <2>;
+ direction = ;
+ };
+ dai@3 {
+ reg = <3>;
+ direction = ;
+ is-compress-dai;
+ };
+};
+
+ {
+ compatible = "qcom,msm8916-qdsp6-sndcard";
+ model = "msm8916";
+
+ pinctrl-0 = <_pdm_default>;
+ pinctrl-1 = <_pdm_sleep>;
+ pinctrl-names = "default", "sleep";
+
+ status = "okay";
+
+ frontend0-dai-link {
+ link-name = "MultiMedia1";
+
+ cpu {
+ sound-dai = < MSM_FRONTEND_DAI_MULTIMEDIA1>;
+ };
+ };
+
+ frontend1-dai-link {
+ link-name = "MultiMedia2";
+
+ cpu {
+ sound-dai = < MSM_FRONTEND_DAI_MULTIMEDIA2>;
+ };
+ };
+
+ frontend2-dai-link {
+ link-name = "MultiMedia3";
+
+ cpu {
+ sound-dai = < MSM_FRONTEND_DAI_MULTIMEDIA3>;
+ };
+ };
+
+ frontend3-dai-link {
+ link-name = "MultiMedia4";
+
+ cpu {
+ sound-dai = < MSM_FRONTEND_DAI_MULTIMEDIA4>;
+ };
+ };
+
+ sound_link_backend0: backend0-dai-link {
+ link-name = "Primary MI2S";
+
+ cpu {
+ sound-dai = < PRIMARY_MI2S_RX>;
+ };
+ platform {
+ sound-dai = <>;
+ };
+ codec {
+ sound-dai = <_codec 0>, <_codec 0>;
+ };
+ };
+
+ sound_link_backend1: backend1-dai-link {
+ link-name = "Tertiary MI2S";
+
+ cpu {
+ sound-dai = < TERTIARY_MI2S_TX>;
+ };
+ platform {
+ sound-dai = <>;
+ };
+ codec {
+ sound-dai = <_codec 1>, <_codec 1>;
+ };
+ };
+};
--
2.42.0
[PATCH v2 05/14] arm64: dts: qcom: msm8916-samsung-a2015: Add sound and modem
Enable sound and modem for the Samsung A2015 based devices (A3, A5, E5,
E7, Grand Max). The setup is similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Earpiece/headphones/microphones via digital/analog codec in
MSM8916/PM8916
- WWAN Internet via BAM-DMUX
except:
- NXP TFA9895 codec for speaker on Quaternary MI2S
- Samsung-specific audio jack detection (not supported yet)
[Lin: Add e2015 and grandmax]
Co-developed-by: "Lin, Meng-Bo"
Signed-off-by: "Lin, Meng-Bo"
Signed-off-by: Stephan Gerhold
---
.../dts/qcom/msm8916-samsung-a2015-common.dtsi | 71 ++
.../dts/qcom/msm8916-samsung-e2015-common.dtsi | 4 ++
.../boot/dts/qcom/msm8916-samsung-grandmax.dts | 4 ++
3 files changed, 79 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
index 0b29132b74e1..2937495940ea 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
@@ -1,10 +1,13 @@
// SPDX-License-Identifier: GPL-2.0-only
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
#include
+#include
/ {
aliases {
@@ -196,6 +199,18 @@ vibrator: vibrator {
};
};
+_i2c1 {
+ status = "okay";
+
+ speaker_codec: audio-codec@34 {
+ compatible = "nxp,tfa9895";
+ reg = <0x34>;
+ vddd-supply = <_l5>;
+ sound-name-prefix = "Speaker";
+ #sound-dai-cells = <0>;
+ };
+};
+
_i2c2 {
status = "okay";
@@ -243,6 +258,25 @@ {
status = "okay";
};
+/*
+ * For some reason the speaker amplifier is connected to the second SD line
+ * (MI2S_2_D1) instead of the first (MI2S_2_D0). This must be configured in the
+ * device tree, otherwise audio will seemingly play fine on the wrong SD line
+ * but the speaker stays silent.
+ *
+ * When routing audio via QDSP6 (the default) the node is reserved and
+ * the definitions from are used. When the modem is disabled audio
can
+ * be alternatively routed directly to the LPASS hardware with reduced latency.
+ * The definitions for are here for completeness to simplify changing
the
+ * setup with minor changes to the DT (either manually or with DT overlays).
+ */
+ {
+ dai-link@3 {
+ reg = ;
+ qcom,playback-sd-lines = <1>;
+ };
+};
+
{
status = "okay";
};
@@ -253,6 +287,10 @@ _dsi0 {
pinctrl-1 = <_sleep>;
};
+_mem {
+ reg = <0x0 0x8680 0x0 0x540>;
+};
+
_resin {
status = "okay";
linux,code = ;
@@ -265,6 +303,13 @@ pm8916_l17: l17 {
};
};
+ {
+ dai@22 {
+ reg = ;
+ qcom,sd-lines = <1>;
+ };
+};
+
_1 {
status = "okay";
};
@@ -279,6 +324,32 @@ _2 {
cd-gpios = < 38 GPIO_ACTIVE_LOW>;
};
+ {
+ model = "samsung-a2015";
+ audio-routing =
+ "AMIC1", "MIC BIAS External1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS External1";
+
+ pinctrl-0 = <_pdm_default _mi2s_default>;
+ pinctrl-1 = <_pdm_sleep _mi2s_sleep>;
+ pinctrl-names = "default", "sleep";
+
+ sound_link_backend2: backend2-dai-link {
+ link-name = "Quaternary MI2S";
+
+ cpu {
+ sound-dai = < QUATERNARY_MI2S_RX>;
+ };
+ platform {
+ sound-dai = <>;
+ };
+ codec {
+ sound-dai = <_codec>;
+ };
+ };
+};
+
{
status = "okay";
extcon = <>, <>;
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-e2015-common.dtsi
b/arch/arm64/boot/dts/qcom/msm8916-samsung-e2015-common.dtsi
index 0824ab041d80..3c49dac92d2d 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-e2015-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-e2015-common.dtsi
@@ -65,6 +65,10 @@ accelerometer@1d {
};
};
+_mem {
+ reg = <0x0 0x8680 0x0 0x5a0>;
+};
+
_motor_vdd {
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-grandmax.dts
b/arch/arm64/boot/dts/qcom/msm8916-samsung-grandmax.dts
index 3f145dde4059..5882b3a593b8 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-grandmax.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-grandmax.dts
@@ -49,6 +49,10 @@ _touch_key {
status = "disabled";
};
+ {
+ model = "samsung-gmax"; /* No secondary microphone */
+};
+
{
gpio_leds_default: gpio-led-default-state {
pins = "gpio60";
--
2.42.0
[PATCH v2 02/14] arm64: dts: qcom: msm8916: Add QDSP6
MSM8916 does not have a dedicated ADSP. Instead, the audio services via
APR are also implemented by the modem DSP. Audio can be either routed
via the modem DSP (necessary for voice call audio etc) or directly sent
to the LPASS hardware (currently used by DB410c). Bypassing QDSP6 audio
is only possible with special firmware (on DB410c) or when the modem
DSP is completely disabled.
Add the typical nodes for QDSP6 audio to msm8916.dtsi. The apr node is
disabled by default to avoid changing behavior for devices like DB410c
that use the bypassed audio path.
Signed-off-by: Stephan Gerhold
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 49 +++
1 file changed, 49 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 4f799b536a92..e8a14dd7e7c2 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
/ {
@@ -1989,6 +1990,54 @@ smd-edge {
label = "hexagon";
+ apr: apr {
+ compatible = "qcom,apr-v2";
+ qcom,smd-channels = "apr_audio_svc";
+ qcom,domain = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ q6core: service@3 {
+ compatible = "qcom,q6core";
+ reg = ;
+ };
+
+ q6afe: service@4 {
+ compatible = "qcom,q6afe";
+ reg = ;
+
+ q6afedai: dais {
+ compatible =
"qcom,q6afe-dais";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+ };
+ };
+
+ q6asm: service@7 {
+ compatible = "qcom,q6asm";
+ reg = ;
+
+ q6asmdai: dais {
+ compatible =
"qcom,q6asm-dais";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+ };
+ };
+
+ q6adm: service@8 {
+ compatible = "qcom,q6adm";
+ reg = ;
+
+ q6routing: routing {
+ compatible =
"qcom,q6adm-routing";
+ #sound-dai-cells = <0>;
+ };
+ };
+ };
+
fastrpc {
compatible = "qcom,fastrpc";
qcom,smd-channels =
"fastrpcsmd-apps-dsp";
--
2.42.0
[PATCH v2 00/14] arm64: dts: qcom: msm8916/39: Enable sound and modem with QDSP6
Enable sound and modem on most of the MSM8916/MSM8939 smartphones/tablets supported upstream by: - Adding the BAM-DMUX DT nodes to msm8939.dtsi for WWAN Internet - Adding the QDSP6 DT nodes to both msm8916.dtsi and msm8939.dtsi. This is needed because audio must be routed through the QDSP6 services provided by the modem firmware when the modem is active. - Setting up the sound/codec related nodes for all the devices. Most of the sound/modem setup is very similar on all MSM8916/MSM8939 devices because the device-specific details are abstracted by the modem firmware. Reduce duplication by adding "msm8916-modem-qdsp6.dtsi" which contains most of the common definitions. The board-specific DT part is limited to extra codecs or board-specific sound setup. With this patch set, the following functionality works on most MSM8916/MSM8939 devices supported upstream: - Sound: Speaker/earpiece/headphones/microphones - Modem: Calls, SMS, WWAN Internet (e.g. with ModemManager) And with extra pending patches also: - Voice call audio - GPS These patches have been contributed by different people and have been used/tested in postmarketOS for several years. Until now they had to wait for other changes to be upstreamed (QDSP6 audio support for MSM8916, dynamic reserved memory, ...). Signed-off-by: Stephan Gerhold --- Changes in v2: - msm8916-modem-qdsp6.dtsi: Add some missing new lines (Konrad) - msm8916-modem-qdsp6.dtsi: Avoid unused template nodes (Konrad) - Refactored/cleaned up dai-link nodes a bit to fix this - Split up msm8916.dtsi and msm8939.dtsi QDSP6 patch (Konrad) - Clarify purpose of node with a comment (Konrad) - Move around status properties a bit for more clarity (Konrad) - Link to v1: https://lore.kernel.org/r/20230926-msm8916-modem-v1-0-398eec74b...@gerhold.net --- J.R. Divya Antony (1): arm64: dts: qcom: msm8916-asus-z00l: Add sound and modem Jasper Korten (1): arm64: dts: qcom: msm8916-samsung-gt5: Add sound and modem Jonathan Albrieux (1): arm64: dts: qcom: msm8916-longcheer-l8910: Add sound and modem Lin, Meng-Bo (2): arm64: dts: qcom: msm8916-samsung-j5: Add sound and modem arm64: dts: qcom: msm8939-samsung-a7: Add sound and modem Nikita Travkin (1): arm64: dts: qcom: msm8916-longcheer-l8150: Add sound and modem Stephan Gerhold (6): arm64: dts: qcom: msm8916: Add QDSP6 arm64: dts: qcom: msm8939: Add QDSP6 arm64: dts: qcom: msm8916: Add common msm8916-modem-qdsp6.dtsi arm64: dts: qcom: msm8916-samsung-a2015: Add sound and modem arm64: dts: qcom: msm8916-samsung-serranove: Add sound and modem arm64: dts: qcom: msm8916-wingtech-wt88047: Add sound and modem Vincent Knecht (2): arm64: dts: qcom: msm8939: Add BAM-DMUX WWAN arm64: dts: qcom: msm8916-alcatel-idol347: Add sound and modem .../boot/dts/qcom/msm8916-alcatel-idol347.dts | 171 + arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts | 21 +++ .../boot/dts/qcom/msm8916-longcheer-l8150.dts | 31 +++- .../boot/dts/qcom/msm8916-longcheer-l8910.dts | 52 +++ arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi | 148 ++ .../dts/qcom/msm8916-samsung-a2015-common.dtsi | 71 + .../dts/qcom/msm8916-samsung-e2015-common.dtsi | 4 + .../boot/dts/qcom/msm8916-samsung-grandmax.dts | 4 + .../boot/dts/qcom/msm8916-samsung-gt5-common.dtsi | 54 +++ arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts | 22 +++ arch/arm64/boot/dts/qcom/msm8916-samsung-gt58.dts | 42 + .../boot/dts/qcom/msm8916-samsung-j5-common.dtsi | 14 ++ arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts| 4 + .../boot/dts/qcom/msm8916-samsung-serranove.dts| 13 ++ .../boot/dts/qcom/msm8916-wingtech-wt88047.dts | 74 + arch/arm64/boot/dts/qcom/msm8916.dtsi | 49 ++ arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts| 70 + arch/arm64/boot/dts/qcom/msm8939.dtsi | 79 ++ 18 files changed, 920 insertions(+), 3 deletions(-) --- change-id: 20230922-msm8916-modem-0d8b6c8abf76 Best regards, -- Stephan Gerhold
[PATCH v2 01/14] arm64: dts: qcom: msm8939: Add BAM-DMUX WWAN
From: Vincent Knecht
BAM DMUX is used as the network interface to the modem. This is copied
as-is from msm8916.dtsi.
Signed-off-by: Vincent Knecht
Reviewed-by: Konrad Dybcio
Signed-off-by: Stephan Gerhold
---
arch/arm64/boot/dts/qcom/msm8939.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi
b/arch/arm64/boot/dts/qcom/msm8939.dtsi
index 324b5d26db40..65c68e0e88d5 100644
--- a/arch/arm64/boot/dts/qcom/msm8939.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi
@@ -1537,6 +1537,20 @@ spmi_bus: spmi@200f000 {
#interrupt-cells = <4>;
};
+ bam_dmux_dma: dma-controller@4044000 {
+ compatible = "qcom,bam-v1.7.0";
+ reg = <0x04044000 0x19000>;
+ interrupts = ;
+ #dma-cells = <1>;
+ qcom,ee = <0>;
+
+ num-channels = <6>;
+ qcom,num-ees = <1>;
+ qcom,powered-remotely;
+
+ status = "disabled";
+ };
+
mpss: remoteproc@408 {
compatible = "qcom,msm8916-mss-pil";
reg = <0x0408 0x100>, <0x0402 0x040>;
@@ -1569,6 +1583,22 @@ mpss: remoteproc@408 {
qcom,halt-regs = < 0x18000 0x19000 0x1a000>;
status = "disabled";
+ bam_dmux: bam-dmux {
+ compatible = "qcom,bam-dmux";
+
+ interrupt-parent = <_smsm>;
+ interrupts = <1 IRQ_TYPE_EDGE_BOTH>, <11
IRQ_TYPE_EDGE_BOTH>;
+ interrupt-names = "pc", "pc-ack";
+
+ qcom,smem-states = <_smsm 1>, <_smsm
11>;
+ qcom,smem-state-names = "pc", "pc-ack";
+
+ dmas = <_dmux_dma 4>, <_dmux_dma 5>;
+ dma-names = "tx", "rx";
+
+ status = "disabled";
+ };
+
mba {
memory-region = <_mem>;
};
--
2.42.0
Re: [PATCH 03/13] arm64: dts: qcom: msm8916: Add common msm8916-modem-qdsp6.dtsi
On Mon, Oct 02, 2023 at 11:59:21AM +0200, Konrad Dybcio wrote:
>
>
> On 9/26/23 22:17, Stephan Gerhold wrote:
> > On Tue, Sep 26, 2023 at 10:01:21PM +0200, Konrad Dybcio wrote:
> > > On 26.09.2023 21:06, Stephan Gerhold wrote:
> > > > On Tue, Sep 26, 2023 at 08:49:24PM +0200, Konrad Dybcio wrote:
> > > > > On 26.09.2023 18:51, Stephan Gerhold wrote:
> > > > > > Most MSM8916/MSM8939 devices use very similar setups for the modem,
> > > > > > because most of the device-specific details are abstracted by the
> > > > > > modem
> > > > > > firmware. There are several definitions (status switches, DAI links
> > > > > > etc) that will be exactly the same for every board.
> > > > > >
> > > > > > Introduce a common msm8916-modem-qdsp6.dtsi include that can be
> > > > > > used to
> > > > > > simplify enabling the modem for such devices. By default the
> > > > > > digital/analog codec in the SoC/PMIC is used, but boards can define
> > > > > > additional codecs using the templates for Secondary and Quaternary
> > > > > > MI2S.
> > > > > >
> > > > > > Signed-off-by: Stephan Gerhold
> > > > > > ---
> > > > > I'd rather see at least one usage so that you aren't introducing
> > > > > effectively non-compiled code..
> > > > >
> > > >
> > > > There are 10 usages in the rest of the patch series.
> > > > Is that enough? :D
> > > >
> > > > IMHO it doesn't make sense to squash this with one of the device
> > > > patches, especially considering several of them are primarily authored
> > > > by others.
> > > I see..
> > >
> > > Well, I guess I don't have better counter-arguments, but please
> > > consider this the next time around.
> > >
> >
> > Will do!
> >
> > > [...]
> > >
> > > > > > +_codec {
> > > > > > + status = "okay";
> > > > > > +};
> > > > > Any reason for it to stay disabled?
> > > > >
> > > >
> > > > You mean in msm8916.dtsi?
> > > Yes
> > >
> > > > For the SoC dtsi we don't make assumptions
> > > > what devices use or not. There could be devices that ignore the internal
> > > > codec entirely. If there is nothing connected to the codec lpass_codec
> > > > should not be enabled (e.g. the msm8916-ufi.dtsi devices).
> > > See my reply to patch 5
> > >
> > > [...]
> > >
> >
> > Let's continue discussing that there I guess. :D
> >
> > > > > > + sound_dai_secondary: mi2s-secondary-dai-link {
> > > > > > + link-name = "Secondary MI2S";
> > > > > > + status = "disabled"; /* Needs extra codec configuration
> > > > > > */
> > > > > Hmm.. Potential good user of /omit-if-no-ref/?
> > > > >
> > > >
> > > > AFAICT /omit-if-no-ref/ is for phandle references only. Basically it
> > > > would only work if you would somewhere reference the phandle:
> > > >
> > > > list-of-sound-dais = <_dai_primary _dai_secondary>;
> > > >
> > > > But this doesn't exist so /omit-if-no-ref/ cannot be used here.
> > > Ahh right, this is the one we don't reference.. Too bad,
> > > would be a nice fit :/
> > >
> > > I only see one usage of it though (patch 7), perhaps it could
> > > be kept local to that one?
> > >
> >
> > This patch series just contains the initial set of
> > msm8916-modem-qdsp6.dtsi users (for devices which are already upstream).
> > We probably have like 20 more that still need to be upstreamed. :D
> >
> > sound_dai_secondary is fairly rare, but there is at least one more user
> > that will probably end up upstream soon.
> 2 users don't sound particularly great in a devicetree included by 20 other
> non-users
>
> > I think the overhead of these template notes is absolutely negligible
> > compared to all the (potentially) unused SoC nodes we have. :D
> Yes, however the unused SoC nodes are mostly standardized and could be used
> as-they-are on a vast majority of devices
>
To be fair we're talking about 152 bytes difference here, in a DTB that
is like 60,000 bytes total. But I can't think of enough compelling
arguments for my "template node" approach, so I will try to rework this
in v2. Let's see if I can get rid of the unused nodes without too much
mess. :)
Thanks,
Stephan
Re: [PATCH 09/13] arm64: dts: qcom: msm8916-longcheer-l8150: Add sound and modem
On Tue, Sep 26, 2023 at 08:59:52PM +0200, Konrad Dybcio wrote: > On 26.09.2023 18:51, Stephan Gerhold wrote: > > From: Nikita Travkin > > > > Enable sound and modem for the Longcheer L8150 (e.g. Wileyfox Swift). > e.g. -> i.e., or is that thing sold under many labels? > Yes, "e.g." is indeed correct here. AFAIK the MSM8916-based Android One devices (aka "google-seed") are also based on the Longcheer L8150. They are available under names like "Cherry Mobile One G1", "i-mobile IQ II", and "General Mobile 4G". They are also covered by this device tree. Thanks, Stephan
Re: [PATCH 04/13] arm64: dts: qcom: msm8916-samsung-a2015: Add sound and modem
On Tue, Sep 26, 2023 at 10:29:29PM +0200, Konrad Dybcio wrote:
> On 26.09.2023 22:27, Stephan Gerhold wrote:
> > On Tue, Sep 26, 2023 at 10:18:22PM +0200, Konrad Dybcio wrote:
> >> On 26.09.2023 22:09, Stephan Gerhold wrote:
> >>> On Tue, Sep 26, 2023 at 09:56:12PM +0200, Konrad Dybcio wrote:
> >>>> [...]
> >>>>
> >>>>>>> +
> >>>>>>> _i2c2 {
> >>>>>>> status = "okay";
> >>>>>>>
> >>>>>>> @@ -243,6 +258,13 @@ {
> >>>>>>> status = "okay";
> >>>>>>> };
> >>>>>>>
> >>>>>>> + {
> >>>>>>> + dai-link@3 {
> >>>>>>> + reg = ;
> >>>>>>> + qcom,playback-sd-lines = <1>;
> >>>>>>> + };
> >>>>>>> +};
> >>>>>> Is that not status = reserved?
> >>>>>>
> >>>>>
> >>>>> Correct. This is here to simplify switching to the modem-bypass audio
> >>>>> routing if someone does not need (or want) the modem. The direct audio
> >>>>> path with the LPASS drivers tends to be more reliable and configurable
> >>>>> (especially wrt bit formats, sampling rates, latency, channels etc).
> >>>>> I know that at some point this helped someone who tried to use an old
> >>>>> phone as some kind of portable musical instrument / synthesizer.
> >>>>>
> >>>>> It's not too obvious that these definitions would be needed when making
> >>>>> those changes (because devices using the standard SD lines (i.e <0>) do
> >>>>> not need it). If you forget about this you get non-functional audio with
> >>>>> no error or any hint what could be wrong.
> >>>>>
> >>>>> To simplify switching between the different audio routing options, the
> >>>>> lk2nd bootloader actually has an option to do this transformation in the
> >>>>> DTB automagically during boot. It's sort of like a DTB overlay that
> >>>>> disables the QDSP6 audio path and enables this node instead. The DAI
> >>>>> links are also adjusted where necessary.
> >>>>>
> >>>>> Do you think a comment would help here?
> >>>> I'd say a comment would be necessary here :D
> >>>>
> >>>
> >>> No problem, I will try to add something simple.
> >>>
> >>>> While I understand this use-case, I believe this is better suited
> >>>> for an actual DTBO or something entirely kept inside lk2nd.
> >>>> Otherwise this looks very confusing to an outside reader.
> >>>>
> >>>
> >>> Translating from the QDSP6 audio setup to the LPASS one is mostly simple
> >>> but not entirely trivial (especially the patching needed for the DAI
> >>> links). Main blocker for DTBOs is that you can only add or change, but
> >>> AFAIK there is no mechanism to _delete_ or fully recreate nodes.
> >> Correct.
> >>
> >>>
> >>> I guess I could maybe derive this from the QDSP6 definitions using
> >>> custom magic code, but the code complexity for that is much higher than
> >>> adding these nodes here for completeness.
> >> I hate to be the bearer of bad news, but this is probably more
> >> of a "do we reasonably want this upstream" type question, as
> >> you'll probably get some grumpy emails about upstream not caring
> >> about what's outside the mainline tree..
> >>
> >
> > IMHO this is hardly a "downstream" type of situation. The whole point of
> > the magic in lk2nd is to make the life for the mainline code base easier
> > and simpler, while still allowing the "bypass modem audio" feature with
> > an unmodified kernel.
> >
> > Before implementing it like this I used to have this directly in the
> > kernel tree, by duplicating each device into a normal XYZ.dts and
> > "XYZ-no-modem.dts". If you apply this to the total of ~45 different
> > MSM8916/MSM8939 DTBs I would like to get upstream this options gets
> > extremely ugly. :'D
> Maybe a kernel module parameter could be somehow useful here?
>
Maybe, but ultimately this affecs multiple modules that do not
necessarily know about each other. You need to enable the node
but also adjust the DAI links in the node to refer to the lpass
DAIs instead of q6afe/q6routing. Implementing this in the kernel would
be complexity everyone would have to carry, while in lk2nd it's local to
the devices that can actually make use of it.
With the device tree we have the flexibility to adjust it based on
device-specifics (RAM size, display panels, broken CPU cores, ...).
I think it's perfectly fine if the bootloader makes good use of this
capability to keep Linux code simple and focused.
Thanks,
Stephan
Re: [PATCH 04/13] arm64: dts: qcom: msm8916-samsung-a2015: Add sound and modem
On Tue, Sep 26, 2023 at 10:18:22PM +0200, Konrad Dybcio wrote:
> On 26.09.2023 22:09, Stephan Gerhold wrote:
> > On Tue, Sep 26, 2023 at 09:56:12PM +0200, Konrad Dybcio wrote:
> >> [...]
> >>
> >>>>> +
> >>>>> _i2c2 {
> >>>>> status = "okay";
> >>>>>
> >>>>> @@ -243,6 +258,13 @@ {
> >>>>> status = "okay";
> >>>>> };
> >>>>>
> >>>>> + {
> >>>>> + dai-link@3 {
> >>>>> + reg = ;
> >>>>> + qcom,playback-sd-lines = <1>;
> >>>>> + };
> >>>>> +};
> >>>> Is that not status = reserved?
> >>>>
> >>>
> >>> Correct. This is here to simplify switching to the modem-bypass audio
> >>> routing if someone does not need (or want) the modem. The direct audio
> >>> path with the LPASS drivers tends to be more reliable and configurable
> >>> (especially wrt bit formats, sampling rates, latency, channels etc).
> >>> I know that at some point this helped someone who tried to use an old
> >>> phone as some kind of portable musical instrument / synthesizer.
> >>>
> >>> It's not too obvious that these definitions would be needed when making
> >>> those changes (because devices using the standard SD lines (i.e <0>) do
> >>> not need it). If you forget about this you get non-functional audio with
> >>> no error or any hint what could be wrong.
> >>>
> >>> To simplify switching between the different audio routing options, the
> >>> lk2nd bootloader actually has an option to do this transformation in the
> >>> DTB automagically during boot. It's sort of like a DTB overlay that
> >>> disables the QDSP6 audio path and enables this node instead. The DAI
> >>> links are also adjusted where necessary.
> >>>
> >>> Do you think a comment would help here?
> >> I'd say a comment would be necessary here :D
> >>
> >
> > No problem, I will try to add something simple.
> >
> >> While I understand this use-case, I believe this is better suited
> >> for an actual DTBO or something entirely kept inside lk2nd.
> >> Otherwise this looks very confusing to an outside reader.
> >>
> >
> > Translating from the QDSP6 audio setup to the LPASS one is mostly simple
> > but not entirely trivial (especially the patching needed for the DAI
> > links). Main blocker for DTBOs is that you can only add or change, but
> > AFAIK there is no mechanism to _delete_ or fully recreate nodes.
> Correct.
>
> >
> > I guess I could maybe derive this from the QDSP6 definitions using
> > custom magic code, but the code complexity for that is much higher than
> > adding these nodes here for completeness.
> I hate to be the bearer of bad news, but this is probably more
> of a "do we reasonably want this upstream" type question, as
> you'll probably get some grumpy emails about upstream not caring
> about what's outside the mainline tree..
>
IMHO this is hardly a "downstream" type of situation. The whole point of
the magic in lk2nd is to make the life for the mainline code base easier
and simpler, while still allowing the "bypass modem audio" feature with
an unmodified kernel.
Before implementing it like this I used to have this directly in the
kernel tree, by duplicating each device into a normal XYZ.dts and
"XYZ-no-modem.dts". If you apply this to the total of ~45 different
MSM8916/MSM8939 DTBs I would like to get upstream this options gets
extremely ugly. :'D
Thanks,
Stephan
Re: [PATCH 03/13] arm64: dts: qcom: msm8916: Add common msm8916-modem-qdsp6.dtsi
On Tue, Sep 26, 2023 at 10:01:21PM +0200, Konrad Dybcio wrote:
> On 26.09.2023 21:06, Stephan Gerhold wrote:
> > On Tue, Sep 26, 2023 at 08:49:24PM +0200, Konrad Dybcio wrote:
> >> On 26.09.2023 18:51, Stephan Gerhold wrote:
> >>> Most MSM8916/MSM8939 devices use very similar setups for the modem,
> >>> because most of the device-specific details are abstracted by the modem
> >>> firmware. There are several definitions (status switches, DAI links
> >>> etc) that will be exactly the same for every board.
> >>>
> >>> Introduce a common msm8916-modem-qdsp6.dtsi include that can be used to
> >>> simplify enabling the modem for such devices. By default the
> >>> digital/analog codec in the SoC/PMIC is used, but boards can define
> >>> additional codecs using the templates for Secondary and Quaternary
> >>> MI2S.
> >>>
> >>> Signed-off-by: Stephan Gerhold
> >>> ---
> >> I'd rather see at least one usage so that you aren't introducing
> >> effectively non-compiled code..
> >>
> >
> > There are 10 usages in the rest of the patch series.
> > Is that enough? :D
> >
> > IMHO it doesn't make sense to squash this with one of the device
> > patches, especially considering several of them are primarily authored
> > by others.
> I see..
>
> Well, I guess I don't have better counter-arguments, but please
> consider this the next time around.
>
Will do!
> [...]
>
> >>> +_codec {
> >>> + status = "okay";
> >>> +};
> >> Any reason for it to stay disabled?
> >>
> >
> > You mean in msm8916.dtsi?
> Yes
>
> > For the SoC dtsi we don't make assumptions
> > what devices use or not. There could be devices that ignore the internal
> > codec entirely. If there is nothing connected to the codec lpass_codec
> > should not be enabled (e.g. the msm8916-ufi.dtsi devices).
> See my reply to patch 5
>
> [...]
>
Let's continue discussing that there I guess. :D
> >>> + sound_dai_secondary: mi2s-secondary-dai-link {
> >>> + link-name = "Secondary MI2S";
> >>> + status = "disabled"; /* Needs extra codec configuration */
> >> Hmm.. Potential good user of /omit-if-no-ref/?
> >>
> >
> > AFAICT /omit-if-no-ref/ is for phandle references only. Basically it
> > would only work if you would somewhere reference the phandle:
> >
> > list-of-sound-dais = <_dai_primary _dai_secondary>;
> >
> > But this doesn't exist so /omit-if-no-ref/ cannot be used here.
> Ahh right, this is the one we don't reference.. Too bad,
> would be a nice fit :/
>
> I only see one usage of it though (patch 7), perhaps it could
> be kept local to that one?
>
This patch series just contains the initial set of
msm8916-modem-qdsp6.dtsi users (for devices which are already upstream).
We probably have like 20 more that still need to be upstreamed. :D
sound_dai_secondary is fairly rare, but there is at least one more user
that will probably end up upstream soon.
I think the overhead of these template notes is absolutely negligible
compared to all the (potentially) unused SoC nodes we have. :D
Thanks,
Stephan
Re: [PATCH 04/13] arm64: dts: qcom: msm8916-samsung-a2015: Add sound and modem
On Tue, Sep 26, 2023 at 09:56:12PM +0200, Konrad Dybcio wrote:
> [...]
>
> >>> +
> >>> _i2c2 {
> >>> status = "okay";
> >>>
> >>> @@ -243,6 +258,13 @@ {
> >>> status = "okay";
> >>> };
> >>>
> >>> + {
> >>> + dai-link@3 {
> >>> + reg = ;
> >>> + qcom,playback-sd-lines = <1>;
> >>> + };
> >>> +};
> >> Is that not status = reserved?
> >>
> >
> > Correct. This is here to simplify switching to the modem-bypass audio
> > routing if someone does not need (or want) the modem. The direct audio
> > path with the LPASS drivers tends to be more reliable and configurable
> > (especially wrt bit formats, sampling rates, latency, channels etc).
> > I know that at some point this helped someone who tried to use an old
> > phone as some kind of portable musical instrument / synthesizer.
> >
> > It's not too obvious that these definitions would be needed when making
> > those changes (because devices using the standard SD lines (i.e <0>) do
> > not need it). If you forget about this you get non-functional audio with
> > no error or any hint what could be wrong.
> >
> > To simplify switching between the different audio routing options, the
> > lk2nd bootloader actually has an option to do this transformation in the
> > DTB automagically during boot. It's sort of like a DTB overlay that
> > disables the QDSP6 audio path and enables this node instead. The DAI
> > links are also adjusted where necessary.
> >
> > Do you think a comment would help here?
> I'd say a comment would be necessary here :D
>
No problem, I will try to add something simple.
> While I understand this use-case, I believe this is better suited
> for an actual DTBO or something entirely kept inside lk2nd.
> Otherwise this looks very confusing to an outside reader.
>
Translating from the QDSP6 audio setup to the LPASS one is mostly simple
but not entirely trivial (especially the patching needed for the DAI
links). Main blocker for DTBOs is that you can only add or change, but
AFAIK there is no mechanism to _delete_ or fully recreate nodes.
I guess I could maybe derive this from the QDSP6 definitions using
custom magic code, but the code complexity for that is much higher than
adding these nodes here for completeness.
Let me try to add some comment first.
Thanks,
Stephan
Re: [PATCH 05/13] arm64: dts: qcom: msm8916-samsung-serranove: Add sound and modem
On Tue, Sep 26, 2023 at 09:57:51PM +0200, Konrad Dybcio wrote:
> [...]
>
> >>>
> >>> + {
> >>> + status = "okay";
> >>> + audio-routing =
> >>> + "AMIC1", "MIC BIAS External1",
> >>> + "AMIC2", "MIC BIAS Internal2",
> >>> + "AMIC3", "MIC BIAS External1";
> >>> +};
> >> I *think* we should be able to harmlessly enable globally?
> >>
> >
> > What about boards that do not have/use audio at all? (see
> > msm8916-ufi.dtsi). We don't even want to load the kernel modules on
> > those.
> Is it really an issue other than losing a few kb of memory?
>
Well, the msm8916-ufi.dtsi boards (basically USB modem/WiFi sticks)
have 512 MiB of RAM, with 85 MiB reserved for modem firmware, plus more
for TZ, HYP etc etc. That's not too much :D
> >
> > IMO the SoC dtsi should always be minimal by default. This also
> > guarantees that you don't run into trouble because of half- or
> > incorrectly configured components during early bring-up, especially if
> > you don't have serial and are hoping to get the device booting far
> > enough to debug it.
> Generally I'd agree, but if the audio machine driver cannot NOP
> successfully without a topology configuration, that's a problem.
>
I think it will effectively fail to probe because there are no DAI links
and no "model". I guess you could consider this to be a NOP but it's
confusing and takes away the attention from the actual errors in dmesg.
I would say it's disabled by default for the same reason that WiFi,
SDHCI, UFS etc etc are disabled by default. They simply don't do
anything useful without additional configuration & hardware support.
Thanks,
Stephan
Re: [PATCH 13/13] arm64: dts: qcom: msm8939-samsung-a7: Add sound and modem
On Tue, Sep 26, 2023 at 09:04:47PM +0200, Konrad Dybcio wrote:
> On 26.09.2023 18:51, Stephan Gerhold wrote:
> > From: "Lin, Meng-Bo"
> >
> > Enable sound and modem for the Samsung A7. The setup is similar to most
> > MSM8916 devices, i.e.:
> >
> > - QDSP6 audio
> > - Earpiece/headphones/microphones via digital/analog codec in
> >MSM8916/PM8916
> > - WWAN Internet via BAM-DMUX
> >
> > except for the same differences as the MSM8916-based Samsung A2015
> > devices:
> >
> > - NXP TFA9895 codec for speaker on Quaternary MI2S
> > - Samsung-specific audio jack detection (not supported yet)
> >
> > Signed-off-by: "Lin, Meng-Bo"
> > [Stephan: Add consistent commit message]
> > Signed-off-by: Stephan Gerhold
> > ---
> [...]
>
> >
> > + {
> > + dai-link@3 {
> > + reg = ;
> > + qcom,playback-sd-lines = <1>;
> > + };
> > +};
> reserved hw?
>
My previous reply for reference:
https://lore.kernel.org/linux-arm-msm/zrmwdro9ham4b...@gerhold.net/
Thanks,
Stephan
Re: [PATCH 12/13] arm64: dts: qcom: msm8916-samsung-j5: Add sound and modem
On Tue, Sep 26, 2023 at 09:04:22PM +0200, Konrad Dybcio wrote:
> On 26.09.2023 18:51, Stephan Gerhold wrote:
> > From: "Lin, Meng-Bo"
> >
> > Enable sound and modem for the Samsung J5 smartphones. The setup is
> > similar to most MSM8916 devices, i.e.:
> >
> > - QDSP6 audio
> > - Speaker/earpiece/headphones/microphones via digital/analog codec
> >in MSM8916/PM8916
> > - WWAN Internet via BAM-DMUX
> >
> > except:
> >
> > - There is no secondary microphone, so a different "model" is used to
> >differentiate that in the UCM configuration.
> > - Samsung-specific audio jack detection (not supported yet)
> >
> > Co-developed-by: Markuss Broks
> > Signed-off-by: Markuss Broks
> > Signed-off-by: "Lin, Meng-Bo"
> > [Stephan: Add consistent commit message]
> > Signed-off-by: Stephan Gerhold
> > ---
> > arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi | 15
> > +++
> > arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts | 4
> > 2 files changed, 19 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi
> > b/arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi
> > index fe59be3505fe..2caa820b0c26 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi
> > @@ -1,6 +1,8 @@
> > // SPDX-License-Identifier: GPL-2.0-only
> >
> > #include "msm8916-pm8916.dtsi"
> > +#include "msm8916-modem-qdsp6.dtsi"
> > +
> > #include
> > #include
> > #include
> > @@ -135,6 +137,10 @@ _uart2 {
> > status = "okay";
> > };
> >
> > +_mem {
> > + reg = <0x0 0x8680 0x0 0x580>;
> > +};
> > +
> > _resin {
> > status = "okay";
> > linux,code = ;
> > @@ -154,6 +160,15 @@ _2 {
> > cd-gpios = < 38 GPIO_ACTIVE_LOW>;
> > };
> >
> > + {
> > + model = "msm8916-1mic";
> That's.. vague.. Is that intended?
>
msm8916-modem-qdsp6.dtsi defines model = "msm8916" by default since we
have a standard UCM configuration that configures the typical audio
mixer setup when all outputs/inputs are connected to the digital/analog
codec of the SoC/PMIC. "msm8916-1mic" is exactly the same just with the
SecondaryMic disabled.
Unfortunately these names are effectively limited to 15 chars
(everything after will be cut off), so there is extremely limited
potential for more expressive names. :(
> I also noticed only now that random patches have status
> at random places in the property tree.. Removing the disablement
> would aid that as well (wink wink)!
>
Hm, I think I could do the status = "okay" in msm8916-modem-qdsp6.dtsi.
I don't think it should be enabled by default in the SoC dtsi but there
it would probably be fine. :)
Thanks,
Stephan
Re: [PATCH 09/13] arm64: dts: qcom: msm8916-longcheer-l8150: Add sound and modem
On Tue, Sep 26, 2023 at 08:59:52PM +0200, Konrad Dybcio wrote:
> On 26.09.2023 18:51, Stephan Gerhold wrote:
> > From: Nikita Travkin
> >
> > Enable sound and modem for the Longcheer L8150 (e.g. Wileyfox Swift).
> e.g. -> i.e., or is that thing sold under many labels?
>
> [...]
>
> > reserved-memory {
> > + /delete-node/ mpss@8680;
> > /delete-node/ wcnss;
> delete by label, please
>
I would say the same as on PATCH 07/13 here:
https://lore.kernel.org/linux-arm-msm/zrmye1heiuno5...@gerhold.net/
Thanks,
Stephan
Re: [PATCH 11/13] arm64: dts: qcom: msm8916-samsung-gt5: Add sound and modem
On Tue, Sep 26, 2023 at 09:03:14PM +0200, Konrad Dybcio wrote:
> On 26.09.2023 18:51, Stephan Gerhold wrote:
> > From: Jasper Korten
> >
> > Enable sound and modem for the Samsung Galaxy Tab A 2015 tablets.
> > The setup is similar to most MSM8916 devices, i.e.:
> >
> > - QDSP6 audio
> > - Headphones/microphones via digital/analog codec in
> >MSM8916/PM8916. Earpiece exists on samsung-gt58 only.
> > - WWAN Internet via BAM-DMUX
> >
> > except:
> >
> > - gt510: Stereo Maxim MAX98357A codecs for speaker on Quaternary MI2S
> > - gt58: Mono NXP TFA9895 codec for speaker on Quaternary MI2S
> >- For some reason connected to GPIOs where no hardware I2C
> > controller is available -> need to use i2c-gpio
> > - Samsung-specific audio jack detection (not supported yet)
> >
> > Signed-off-by: Jasper Korten
> > Co-developed-by: Siddharth Manthan
> > Signed-off-by: Siddharth Manthan
> > Co-developed-by: Nikita Travkin
> > Signed-off-by: Nikita Travkin
> > [Stephan: Add consistent commit message]
> > Signed-off-by: Stephan Gerhold
> > ---
> > .../boot/dts/qcom/msm8916-samsung-gt5-common.dtsi | 36 ++
> > arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts | 23
> > arch/arm64/boot/dts/qcom/msm8916-samsung-gt58.dts | 43
> > ++
> > 3 files changed, 102 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi
> > b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi
> > index 6a16eb5ce07b..396853fcece5 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi
> > @@ -3,9 +3,12 @@
> > /dts-v1/;
> >
> > #include "msm8916-pm8916.dtsi"
> > +#include "msm8916-modem-qdsp6.dtsi"
> > +
> > #include
> > #include
> > #include
> > +#include
> >
> > / {
> > aliases {
> > @@ -116,6 +119,17 @@ _uart2 {
> > status = "okay";
> > };
> >
> > + {
> > + dai-link@3 {
> > + reg = ;
> > + qcom,playback-sd-lines = <1>;
> > + };
> > +};
> status = reserved?
>
For reference:
https://lore.kernel.org/linux-arm-msm/zrmwdro9ham4b...@gerhold.net/
> [...]
> >
> > + i2c-amplifier {
> > + compatible = "i2c-gpio";
> > + sda-gpios = < 55 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
> > + scl-gpios = < 56 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
> non-msm8916 files have a space around the OR operator, hm
>
Hm I can add a space if you think it looks better. :D
Thanks,
Stephan
Re: [PATCH 07/13] arm64: dts: qcom: msm8916-alcatel-idol347: Add sound and modem
On Tue, Sep 26, 2023 at 08:58:12PM +0200, Konrad Dybcio wrote:
> On 26.09.2023 18:51, Stephan Gerhold wrote:
> > From: Vincent Knecht
> >
> > Enable sound and modem for the Alcatel Idol 3 (4.7"). The setup is
> > similar to most MSM8916 devices, i.e.:
> >
> > - QDSP6 audio
> > - Microphones via digital/analog codec in MSM8916/PM8916
> > - WWAN Internet via BAM-DMUX
> >
> > except:
> >
> > - Stereo NXP TFA9890 codecs for speakers on Quaternary MI2S
> >- These are also used as earpieces at the top/bottom.
> > - Asahi Kasei AK4375 headphone codec on Secondary MI2S
> > -> Primary MI2S is not used for playback
> >
> > Signed-off-by: Vincent Knecht
> > [Stephan: minor cleanup, add consistent commit message]
> > Signed-off-by: Stephan Gerhold
> > ---
> > There are some trivial conflicts unless
> > https://lore.kernel.org/linux-arm-msm/20230921-msm8916-rmem-fixups-v1-3-34d2b6e72...@gerhold.net/
> > is applied first. But given that there are important fixups for the
> > dynamic reserved memory changes in that series it should preferably
> > get applied before this one anyway.
> > ---
> > .../boot/dts/qcom/msm8916-alcatel-idol347.dts | 164
> > +
> > 1 file changed, 164 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
> > b/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
> > index fade93c55299..ef5fc9289754 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
> > +++ b/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
> > @@ -3,6 +3,8 @@
> > /dts-v1/;
> >
> > #include "msm8916-pm8916.dtsi"
> > +#include "msm8916-modem-qdsp6.dtsi"
> > +
> > #include
> > #include
> > #include
> > @@ -22,6 +24,19 @@ chosen {
> > stdout-path = "serial0";
> > };
> >
> > + reserved-memory {
> > + /delete-node/ reserved@8668;
> > + /delete-node/ rmtfs@8670;
> Deleting with a label reference is strongly preferred to avoid
> mistakes.
>
I would say the opposite applies here. The deletions are based on the
assumption that the nodes are at the address that are listed here. If
you would move rmtfs somewhere else the adjustments made here must be
re-evaulated.
/delete-node/ throws an error if the referenced name does not exist,
so it's exactly the indication we need if someone makes changes to the
original node in the SoC dtsi.
Note that this is different from property assignments, i.e.
/ {
reserved-memory {
rmtfs@8670 {
status = "disabled";
};
};
};
instead of
{
status = "disabled";
};
because here there would not be an error if the node is renamed.
> [...]
>
> >
> > + {
> > + dai@18 {
> > + reg = ;
> > + qcom,sd-lines = <0>;
> > + };
> > + dai@22 {
> Missing newline above
>
Thanks, will fix this!
>
> > +
> > +_dai_primary {
> > + status = "disabled";
> > +};
> > +
> Hm, gives me an idea to sprinkle a bit more /omit-if-no-ref/ in
> patch 3..
>
(See reply in patch 3, /omit-if-no-ref/ sadly only works for phandle
references...)
Thanks,
Stephan
Re: [PATCH 05/13] arm64: dts: qcom: msm8916-samsung-serranove: Add sound and modem
On Tue, Sep 26, 2023 at 08:55:14PM +0200, Konrad Dybcio wrote:
> On 26.09.2023 18:51, Stephan Gerhold wrote:
> > Enable sound and modem for the Samsung S4 Mini Value Edition. The setup
> > is similar to most MSM8916 devices, i.e.:
> >
> > - QDSP6 audio
> > - Speaker/earpiece/headphones/microphones via digital/analog codec in
> >MSM8916/PM8916
> > - WWAN Internet via BAM-DMUX
> >
> > except:
> >
> > - Samsung-specific audio jack detection (not supported yet)
> >
> > Signed-off-by: Stephan Gerhold
> > ---
> > arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts | 14 ++
> > 1 file changed, 14 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts
> > b/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts
> > index 68da2a2d3077..5f33aa0ad7b5 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts
> > +++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts
> > @@ -6,6 +6,8 @@
> > /dts-v1/;
> >
> > #include "msm8916-pm8916.dtsi"
> > +#include "msm8916-modem-qdsp6.dtsi"
> > +
> > #include
> > #include
> > #include
> > @@ -319,6 +321,10 @@ _uart2 {
> > status = "okay";
> > };
> >
> > +_mem {
> > + reg = <0x0 0x8680 0x0 0x5a0>;
> > +};
> > +
> > _resin {
> > status = "okay";
> > linux,code = ;
> > @@ -350,6 +356,14 @@ _2 {
> > no-1-8-v;
> > };
> >
> > + {
> > + status = "okay";
> > + audio-routing =
> > + "AMIC1", "MIC BIAS External1",
> > + "AMIC2", "MIC BIAS Internal2",
> > + "AMIC3", "MIC BIAS External1";
> > +};
> I *think* we should be able to harmlessly enable globally?
>
What about boards that do not have/use audio at all? (see
msm8916-ufi.dtsi). We don't even want to load the kernel modules on
those.
IMO the SoC dtsi should always be minimal by default. This also
guarantees that you don't run into trouble because of half- or
incorrectly configured components during early bring-up, especially if
you don't have serial and are hoping to get the device booting far
enough to debug it.
Thanks,
Stephan
Re: [PATCH 04/13] arm64: dts: qcom: msm8916-samsung-a2015: Add sound and modem
On Tue, Sep 26, 2023 at 08:54:29PM +0200, Konrad Dybcio wrote:
> On 26.09.2023 18:51, Stephan Gerhold wrote:
> > Enable sound and modem for the Samsung A2015 based devices (A3, A5, E5,
> > E7, Grand Max). The setup is similar to most MSM8916 devices, i.e.:
> >
> > - QDSP6 audio
> > - Earpiece/headphones/microphones via digital/analog codec in
> >MSM8916/PM8916
> > - WWAN Internet via BAM-DMUX
> >
> > except:
> >
> > - NXP TFA9895 codec for speaker on Quaternary MI2S
> > - Samsung-specific audio jack detection (not supported yet)
> >
> > [Lin: Add e2015 and grandmax]
> > Co-developed-by: "Lin, Meng-Bo"
> > Signed-off-by: "Lin, Meng-Bo"
> > Signed-off-by: Stephan Gerhold
> > ---
> > .../dts/qcom/msm8916-samsung-a2015-common.dtsi | 55
> > ++
> > .../dts/qcom/msm8916-samsung-e2015-common.dtsi | 4 ++
> > .../boot/dts/qcom/msm8916-samsung-grandmax.dts | 4 ++
> > 3 files changed, 63 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
> > b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
> > index 0b29132b74e1..f71b18d89bf9 100644
> > --- a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
> > @@ -1,10 +1,13 @@
> > // SPDX-License-Identifier: GPL-2.0-only
> >
> > #include "msm8916-pm8916.dtsi"
> > +#include "msm8916-modem-qdsp6.dtsi"
> > +
> > #include
> > #include
> > #include
> > #include
> > +#include
> >
> > / {
> > aliases {
> > @@ -196,6 +199,18 @@ vibrator: vibrator {
> > };
> > };
> >
> > +_i2c1 {
> > + status = "okay";
> > +
> > + speaker_codec: audio-codec@34 {
> > + compatible = "nxp,tfa9895";
> > + reg = <0x34>;
> > + vddd-supply = <_l5>;
> > + sound-name-prefix = "Speaker";
> > + #sound-dai-cells = <0>;
> > + };
> > +};
> > +
> > _i2c2 {
> > status = "okay";
> >
> > @@ -243,6 +258,13 @@ {
> > status = "okay";
> > };
> >
> > + {
> > + dai-link@3 {
> > + reg = ;
> > + qcom,playback-sd-lines = <1>;
> > + };
> > +};
> Is that not status = reserved?
>
Correct. This is here to simplify switching to the modem-bypass audio
routing if someone does not need (or want) the modem. The direct audio
path with the LPASS drivers tends to be more reliable and configurable
(especially wrt bit formats, sampling rates, latency, channels etc).
I know that at some point this helped someone who tried to use an old
phone as some kind of portable musical instrument / synthesizer.
It's not too obvious that these definitions would be needed when making
those changes (because devices using the standard SD lines (i.e <0>) do
not need it). If you forget about this you get non-functional audio with
no error or any hint what could be wrong.
To simplify switching between the different audio routing options, the
lk2nd bootloader actually has an option to do this transformation in the
DTB automagically during boot. It's sort of like a DTB overlay that
disables the QDSP6 audio path and enables this node instead. The DAI
links are also adjusted where necessary.
Do you think a comment would help here?
Thanks,
Stephan
Re: [PATCH 02/13] arm64: dts: qcom: msm8916/39: Add QDSP6
On Tue, Sep 26, 2023 at 09:05:24PM +0200, Konrad Dybcio wrote: > On 26.09.2023 20:54, Stephan Gerhold wrote: > > On Tue, Sep 26, 2023 at 08:46:36PM +0200, Konrad Dybcio wrote: > >> On 26.09.2023 18:51, Stephan Gerhold wrote: > >>> MSM8916 and MSM8939 do not have a dedicated ADSP. Instead, the audio > >>> services via APR are also implemented by the modem DSP. Audio can be > >>> either routed via the modem DSP (necessary for voice call audio etc) > >>> or directly sent to the LPASS hardware (currently used by DB410c). > >>> Bypassing QDSP6 audio is only possible with special firmware > >>> (on DB410c) or when the modem DSP is completely disabled. > >>> > >>> Add the typical nodes for QDSP6 audio to msm8916.dtsi and msm8939.dtsi. > >>> The apr node is disabled by default to avoid changing behavior for > >>> devices like DB410c that use the bypassed audio path. > >>> > >>> Signed-off-by: Stephan Gerhold > >>> --- > >> I'm generally grumpy with regards to multi-soc changes that > >> have no need to be multi-soc.. > >> > > > > Well it's 100% the same diff so reviewing it separately doesn't really > > make sense IMHO. When I do "msm8916/39" patches these are generally the > > changes where strictly speaking there is no need to duplicate at all. > > It could go into a common include between both. We just haven't found > > a good solution/agreement yet how sharing SoC components could work. > My bottom line is that, somebody trying to track down an issue on > one may need to unnecessarily resolve 2 merge conflicts when reverting :/ > I mean you could easily discard the changes in the other .dtsi. Probably a single shell command if one knows enough "Git-fu". Stephan
Re: [PATCH 03/13] arm64: dts: qcom: msm8916: Add common msm8916-modem-qdsp6.dtsi
On Tue, Sep 26, 2023 at 08:49:24PM +0200, Konrad Dybcio wrote:
> On 26.09.2023 18:51, Stephan Gerhold wrote:
> > Most MSM8916/MSM8939 devices use very similar setups for the modem,
> > because most of the device-specific details are abstracted by the modem
> > firmware. There are several definitions (status switches, DAI links
> > etc) that will be exactly the same for every board.
> >
> > Introduce a common msm8916-modem-qdsp6.dtsi include that can be used to
> > simplify enabling the modem for such devices. By default the
> > digital/analog codec in the SoC/PMIC is used, but boards can define
> > additional codecs using the templates for Secondary and Quaternary
> > MI2S.
> >
> > Signed-off-by: Stephan Gerhold
> > ---
> I'd rather see at least one usage so that you aren't introducing
> effectively non-compiled code..
>
There are 10 usages in the rest of the patch series.
Is that enough? :D
IMHO it doesn't make sense to squash this with one of the device
patches, especially considering several of them are primarily authored
by others.
> > arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi | 163
> > ++
> > 1 file changed, 163 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi
> > b/arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi
> > new file mode 100644
> > index ..ddd74d428406
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi
> > @@ -0,0 +1,163 @@
> > +// SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause)
> > +/*
> > + * msm8916-modem-qdsp6.dtsi describes the typical modem setup on MSM8916
> > devices
> > + * (or similar SoCs) with audio routed via the QDSP6 services provided by
> > the
> > + * modem firmware. The digital/analog codec in the SoC/PMIC is used by
> > default,
> > + * but boards can define additional codecs using the templates for
> > Secondary and
> > + * Quaternary MI2S.
> > + */
> > +
> > +#include
> > +#include
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > +_dmux {
> > + status = "okay";
> > +};
> > +
> > +_dmux_dma {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "reserved"; /* Controlled by QDSP6 */
> > +};
> > +
> > +_codec {
> > + status = "okay";
> > +};
> Any reason for it to stay disabled?
>
You mean in msm8916.dtsi? For the SoC dtsi we don't make assumptions
what devices use or not. There could be devices that ignore the internal
codec entirely. If there is nothing connected to the codec lpass_codec
should not be enabled (e.g. the msm8916-ufi.dtsi devices).
This include is a bit more "opinionated", to reduce duplication for
the most common setup. But it's separate and optional to use. The SoC
dtsi is included by everyone.
> > +
> > +_mem {
> > + status = "okay";
> > +};
> > +
> > + {
> > + status = "okay";
> > +};
> > +
> > +_mem {
> > + status = "okay";
> > +};
> > +
> > +_codec {
> > + status = "okay";
> > +};
> Ditto
>
Same as above.
> > + multimedia1-dai-link {
> > + link-name = "MultiMedia1";
> Newline before last property and subnodes, please
>
Thanks, will change this!
>
> > + sound_dai_secondary: mi2s-secondary-dai-link {
> > + link-name = "Secondary MI2S";
> > + status = "disabled"; /* Needs extra codec configuration */
> Hmm.. Potential good user of /omit-if-no-ref/?
>
AFAICT /omit-if-no-ref/ is for phandle references only. Basically it
would only work if you would somewhere reference the phandle:
list-of-sound-dais = <_dai_primary _dai_secondary>;
But this doesn't exist so /omit-if-no-ref/ cannot be used here.
Thanks,
Stephan
Re: [PATCH 02/13] arm64: dts: qcom: msm8916/39: Add QDSP6
On Tue, Sep 26, 2023 at 08:46:36PM +0200, Konrad Dybcio wrote: > On 26.09.2023 18:51, Stephan Gerhold wrote: > > MSM8916 and MSM8939 do not have a dedicated ADSP. Instead, the audio > > services via APR are also implemented by the modem DSP. Audio can be > > either routed via the modem DSP (necessary for voice call audio etc) > > or directly sent to the LPASS hardware (currently used by DB410c). > > Bypassing QDSP6 audio is only possible with special firmware > > (on DB410c) or when the modem DSP is completely disabled. > > > > Add the typical nodes for QDSP6 audio to msm8916.dtsi and msm8939.dtsi. > > The apr node is disabled by default to avoid changing behavior for > > devices like DB410c that use the bypassed audio path. > > > > Signed-off-by: Stephan Gerhold > > --- > I'm generally grumpy with regards to multi-soc changes that > have no need to be multi-soc.. > Well it's 100% the same diff so reviewing it separately doesn't really make sense IMHO. When I do "msm8916/39" patches these are generally the changes where strictly speaking there is no need to duplicate at all. It could go into a common include between both. We just haven't found a good solution/agreement yet how sharing SoC components could work. Thanks, Stephan
[PATCH 02/13] arm64: dts: qcom: msm8916/39: Add QDSP6
MSM8916 and MSM8939 do not have a dedicated ADSP. Instead, the audio
services via APR are also implemented by the modem DSP. Audio can be
either routed via the modem DSP (necessary for voice call audio etc)
or directly sent to the LPASS hardware (currently used by DB410c).
Bypassing QDSP6 audio is only possible with special firmware
(on DB410c) or when the modem DSP is completely disabled.
Add the typical nodes for QDSP6 audio to msm8916.dtsi and msm8939.dtsi.
The apr node is disabled by default to avoid changing behavior for
devices like DB410c that use the bypassed audio path.
Signed-off-by: Stephan Gerhold
---
arch/arm64/boot/dts/qcom/msm8916.dtsi | 49 +++
arch/arm64/boot/dts/qcom/msm8939.dtsi | 49 +++
2 files changed, 98 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
b/arch/arm64/boot/dts/qcom/msm8916.dtsi
index 4f799b536a92..e8a14dd7e7c2 100644
--- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
/ {
@@ -1989,6 +1990,54 @@ smd-edge {
label = "hexagon";
+ apr: apr {
+ compatible = "qcom,apr-v2";
+ qcom,smd-channels = "apr_audio_svc";
+ qcom,domain = ;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ q6core: service@3 {
+ compatible = "qcom,q6core";
+ reg = ;
+ };
+
+ q6afe: service@4 {
+ compatible = "qcom,q6afe";
+ reg = ;
+
+ q6afedai: dais {
+ compatible =
"qcom,q6afe-dais";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+ };
+ };
+
+ q6asm: service@7 {
+ compatible = "qcom,q6asm";
+ reg = ;
+
+ q6asmdai: dais {
+ compatible =
"qcom,q6asm-dais";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #sound-dai-cells = <1>;
+ };
+ };
+
+ q6adm: service@8 {
+ compatible = "qcom,q6adm";
+ reg = ;
+
+ q6routing: routing {
+ compatible =
"qcom,q6adm-routing";
+ #sound-dai-cells = <0>;
+ };
+ };
+ };
+
fastrpc {
compatible = "qcom,fastrpc";
qcom,smd-channels =
"fastrpcsmd-apps-dsp";
diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi
b/arch/arm64/boot/dts/qcom/msm8939.dtsi
index 65c68e0e88d5..95610a32750a 100644
--- a/arch/arm64/boot/dts/qcom/msm8939.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
/ {
@@ -1615,6 +1616,54 @@ smd-edge {
qcom,remote-pid = <1>;
label = "hexagon";
+
+ apr: apr {
+ compatible = "qcom,apr-v2";
+ qcom,smd-channels = "apr_audio_svc";
+ qcom,domain = ;
+ #address-cells = <1>;
+
[PATCH 13/13] arm64: dts: qcom: msm8939-samsung-a7: Add sound and modem
From: "Lin, Meng-Bo"
Enable sound and modem for the Samsung A7. The setup is similar to most
MSM8916 devices, i.e.:
- QDSP6 audio
- Earpiece/headphones/microphones via digital/analog codec in
MSM8916/PM8916
- WWAN Internet via BAM-DMUX
except for the same differences as the MSM8916-based Samsung A2015
devices:
- NXP TFA9895 codec for speaker on Quaternary MI2S
- Samsung-specific audio jack detection (not supported yet)
Signed-off-by: "Lin, Meng-Bo"
[Stephan: Add consistent commit message]
Signed-off-by: Stephan Gerhold
---
arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts | 54 +
1 file changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts
b/arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts
index fccd8fec8b8f..4951b3e265d2 100644
--- a/arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts
+++ b/arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts
@@ -3,10 +3,12 @@
/dts-v1/;
#include "msm8939-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
#include
#include
#include
+#include
/ {
model = "Samsung Galaxy A7 (2015)";
@@ -287,6 +289,18 @@ muic: extcon@25 {
};
};
+_i2c2 {
+ status = "okay";
+
+ speaker_codec: audio-codec@34 {
+ compatible = "nxp,tfa9895";
+ reg = <0x34>;
+ vddd-supply = <_l5>;
+ sound-name-prefix = "Speaker";
+ #sound-dai-cells = <0>;
+ };
+};
+
_i2c5 {
status = "okay";
@@ -309,6 +323,17 @@ _uart2 {
status = "okay";
};
+ {
+ dai-link@3 {
+ reg = ;
+ qcom,playback-sd-lines = <1>;
+ };
+};
+
+_mem {
+ reg = <0x0 0x8680 0x0 0x580>;
+};
+
_resin {
linux,code = ;
status = "okay";
@@ -321,6 +346,13 @@ pm8916_l17: l17 {
};
};
+ {
+ dai@22 {
+ reg = ;
+ qcom,sd-lines = <1>;
+ };
+};
+
_1 {
status = "okay";
};
@@ -335,6 +367,28 @@ _2 {
status = "okay";
};
+ {
+ model = "samsung-a2015";
+ audio-routing =
+ "AMIC1", "MIC BIAS External1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS External1";
+
+ pinctrl-0 = <_pdm_default _mi2s_default>;
+ pinctrl-1 = <_pdm_sleep _mi2s_sleep>;
+ pinctrl-names = "default", "sleep";
+
+ status = "okay";
+};
+
+_dai_quaternary {
+ status = "okay";
+
+ codec {
+ sound-dai = <_codec>;
+ };
+};
+
{
extcon = <>, <>;
status = "okay";
--
2.42.0
[PATCH 09/13] arm64: dts: qcom: msm8916-longcheer-l8150: Add sound and modem
From: Nikita Travkin
Enable sound and modem for the Longcheer L8150 (e.g. Wileyfox Swift).
The setup is similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Speaker/earpiece/headphones/microphones via digital/analog codec
in MSM8916/PM8916
- Audio jack detection via analog codec in PM8916
- WWAN Internet via BAM-DMUX
except:
- The mpss firmware region must be relocated to a different address.
This is because the wcnss firmware is not relocatable for some
reason. The mpss firmware is too large to avoid overlap with wcnss
when placed at the default address (0x8680).
Surprisingly the vendor kernel does not handle this. The firmware
regions end up overlapping there and somehow this does not explode.
We try to handle this more safely by relocating the mpss region to
the first higher address that is working correctly: 0x8e80.
Signed-off-by: Nikita Travkin
Co-developed-by: Stephan Gerhold
Signed-off-by: Stephan Gerhold
---
.../boot/dts/qcom/msm8916-longcheer-l8150.dts | 32 --
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
index 47d1c5cb13f4..78f08254b287 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
@@ -3,6 +3,8 @@
/dts-v1/;
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
@@ -25,17 +27,26 @@ chosen {
/*
* For some reason, the signed wcnss firmware is not relocatable.
-* It must be loaded at 0x8b60. All other firmware is relocatable,
-* so place wcnss at the fixed address and then all other firmware
-* regions will be automatically allocated at a fitting place.
+* It must be loaded at 0x8b60. Unfortunately, this also means that
+* mpss_mem does not fit when loaded to the typical address at
0x8680.
+*
+* Load wcnss_mem to the fixed address and relocate mpss_mem to the next
+* working higher address. For some reason the modem firmware does not
+* boot when placed at 0x8a80 to 0x8e80.
*/
reserved-memory {
+ /delete-node/ mpss@8680;
/delete-node/ wcnss;
wcnss_mem: wcnss@8b60 {
reg = <0x0 0x8b60 0x0 0x60>;
no-map;
};
+
+ mpss_mem: mpss@8e80 {
+ reg = <0x0 0x8e80 0x0 0x500>;
+ no-map;
+ };
};
gpio-keys {
@@ -225,6 +236,13 @@ _uart2 {
status = "okay";
};
+_codec {
+ qcom,micbias-lvl = <2800>;
+ qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
+ qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
+ qcom,hphl-jack-type-normally-open;
+};
+
_resin {
status = "okay";
linux,code = ;
@@ -254,6 +272,14 @@ _2 {
non-removable;
};
+ {
+ status = "okay";
+ audio-routing =
+ "AMIC1", "MIC BIAS Internal1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS Internal3";
+};
+
{
status = "okay";
dr_mode = "peripheral";
--
2.42.0
[PATCH 04/13] arm64: dts: qcom: msm8916-samsung-a2015: Add sound and modem
Enable sound and modem for the Samsung A2015 based devices (A3, A5, E5,
E7, Grand Max). The setup is similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Earpiece/headphones/microphones via digital/analog codec in
MSM8916/PM8916
- WWAN Internet via BAM-DMUX
except:
- NXP TFA9895 codec for speaker on Quaternary MI2S
- Samsung-specific audio jack detection (not supported yet)
[Lin: Add e2015 and grandmax]
Co-developed-by: "Lin, Meng-Bo"
Signed-off-by: "Lin, Meng-Bo"
Signed-off-by: Stephan Gerhold
---
.../dts/qcom/msm8916-samsung-a2015-common.dtsi | 55 ++
.../dts/qcom/msm8916-samsung-e2015-common.dtsi | 4 ++
.../boot/dts/qcom/msm8916-samsung-grandmax.dts | 4 ++
3 files changed, 63 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
index 0b29132b74e1..f71b18d89bf9 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
@@ -1,10 +1,13 @@
// SPDX-License-Identifier: GPL-2.0-only
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
#include
+#include
/ {
aliases {
@@ -196,6 +199,18 @@ vibrator: vibrator {
};
};
+_i2c1 {
+ status = "okay";
+
+ speaker_codec: audio-codec@34 {
+ compatible = "nxp,tfa9895";
+ reg = <0x34>;
+ vddd-supply = <_l5>;
+ sound-name-prefix = "Speaker";
+ #sound-dai-cells = <0>;
+ };
+};
+
_i2c2 {
status = "okay";
@@ -243,6 +258,13 @@ {
status = "okay";
};
+ {
+ dai-link@3 {
+ reg = ;
+ qcom,playback-sd-lines = <1>;
+ };
+};
+
{
status = "okay";
};
@@ -253,6 +275,10 @@ _dsi0 {
pinctrl-1 = <_sleep>;
};
+_mem {
+ reg = <0x0 0x8680 0x0 0x540>;
+};
+
_resin {
status = "okay";
linux,code = ;
@@ -265,6 +291,13 @@ pm8916_l17: l17 {
};
};
+ {
+ dai@22 {
+ reg = ;
+ qcom,sd-lines = <1>;
+ };
+};
+
_1 {
status = "okay";
};
@@ -279,6 +312,28 @@ _2 {
cd-gpios = < 38 GPIO_ACTIVE_LOW>;
};
+ {
+ status = "okay";
+
+ model = "samsung-a2015";
+ audio-routing =
+ "AMIC1", "MIC BIAS External1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS External1";
+
+ pinctrl-0 = <_pdm_default _mi2s_default>;
+ pinctrl-1 = <_pdm_sleep _mi2s_sleep>;
+ pinctrl-names = "default", "sleep";
+};
+
+_dai_quaternary {
+ status = "okay";
+
+ codec {
+ sound-dai = <_codec>;
+ };
+};
+
{
status = "okay";
extcon = <>, <>;
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-e2015-common.dtsi
b/arch/arm64/boot/dts/qcom/msm8916-samsung-e2015-common.dtsi
index 0824ab041d80..3c49dac92d2d 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-e2015-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-e2015-common.dtsi
@@ -65,6 +65,10 @@ accelerometer@1d {
};
};
+_mem {
+ reg = <0x0 0x8680 0x0 0x5a0>;
+};
+
_motor_vdd {
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-grandmax.dts
b/arch/arm64/boot/dts/qcom/msm8916-samsung-grandmax.dts
index 3f145dde4059..5882b3a593b8 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-grandmax.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-grandmax.dts
@@ -49,6 +49,10 @@ _touch_key {
status = "disabled";
};
+ {
+ model = "samsung-gmax"; /* No secondary microphone */
+};
+
{
gpio_leds_default: gpio-led-default-state {
pins = "gpio60";
--
2.42.0
[PATCH 10/13] arm64: dts: qcom: msm8916-longcheer-l8910: Add sound and modem
From: Jonathan Albrieux
Enable sound and modem for the Longcheer L8910 (BQ Aquaris X5).
The setup is similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Earpiece/headphones/microphones via digital/analog codec in
MSM8916/PM8916
- Audio jack detection via analog codec in PM8916
- WWAN Internet via BAM-DMUX
except:
- Awinic AW8738 connected to HPH_R (headphones) output of the analog
codec. Note that unlike for wingtech-wt88047 there is no analog
switch that would allow disabling output via the headphone jack
when the speaker is enabled.
Signed-off-by: Jonathan Albrieux
Co-developed-by: Stephan Gerhold
Signed-off-by: Stephan Gerhold
---
.../boot/dts/qcom/msm8916-longcheer-l8910.dts | 54 ++
1 file changed, 54 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
index 41cadb906b98..c0dc9a3bbac4 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
@@ -3,6 +3,8 @@
/dts-v1/;
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
@@ -22,6 +24,16 @@ chosen {
stdout-path = "serial0";
};
+ speaker_amp: audio-amplifier {
+ compatible = "awinic,aw8738";
+ mode-gpios = < 114 GPIO_ACTIVE_HIGH>;
+ awinic,mode = <5>;
+ sound-name-prefix = "Speaker Amp";
+
+ pinctrl-0 = <_ext_pa_default>;
+ pinctrl-names = "default";
+ };
+
flash-led-controller {
compatible = "ocs,ocp8110";
enable-gpios = < 49 GPIO_ACTIVE_HIGH>;
@@ -107,6 +119,17 @@ _uart2 {
status = "okay";
};
+_mem {
+ reg = <0x0 0x8680 0x0 0x500>;
+};
+
+_codec {
+ qcom,micbias-lvl = <2800>;
+ qcom,mbhc-vthreshold-low = <75 100 120 180 500>;
+ qcom,mbhc-vthreshold-high = <75 100 120 180 500>;
+ qcom,hphl-jack-type-normally-open;
+};
+
_resin {
status = "okay";
linux,code = ;
@@ -137,6 +160,30 @@ _2 {
cd-gpios = < 38 GPIO_ACTIVE_LOW>;
};
+ {
+ status = "okay";
+
+ /*
+* Provide widgets/pin-switches to allow enabling speaker separately.
+* The hardware does not provide a way to disable the output via the
+* headphone jack when the speaker is enabled.
+*/
+ model = "bq-paella";
+ widgets =
+ "Speaker", "Speaker",
+ "Headphone", "Headphones";
+ pin-switches = "Speaker";
+ audio-routing =
+ "Speaker", "Speaker Amp OUT",
+ "Speaker Amp IN", "HPH_R",
+ "Headphones", "HPH_L",
+ "Headphones", "HPH_R",
+ "AMIC1", "MIC BIAS External1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS External1";
+ aux-devs = <_amp>;
+};
+
{
status = "okay";
extcon = <_id>, <_id>;
@@ -205,6 +252,13 @@ sdc2_cd_default: sdc2-cd-default-state {
bias-disable;
};
+ spk_ext_pa_default: spk-ext-pa-default-state {
+ pins = "gpio114";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
usb_id_default: usb-id-default-state {
pins = "gpio110";
function = "gpio";
--
2.42.0
[PATCH 07/13] arm64: dts: qcom: msm8916-alcatel-idol347: Add sound and modem
From: Vincent Knecht
Enable sound and modem for the Alcatel Idol 3 (4.7"). The setup is
similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Microphones via digital/analog codec in MSM8916/PM8916
- WWAN Internet via BAM-DMUX
except:
- Stereo NXP TFA9890 codecs for speakers on Quaternary MI2S
- These are also used as earpieces at the top/bottom.
- Asahi Kasei AK4375 headphone codec on Secondary MI2S
-> Primary MI2S is not used for playback
Signed-off-by: Vincent Knecht
[Stephan: minor cleanup, add consistent commit message]
Signed-off-by: Stephan Gerhold
---
There are some trivial conflicts unless
https://lore.kernel.org/linux-arm-msm/20230921-msm8916-rmem-fixups-v1-3-34d2b6e72...@gerhold.net/
is applied first. But given that there are important fixups for the
dynamic reserved memory changes in that series it should preferably
get applied before this one anyway.
---
.../boot/dts/qcom/msm8916-alcatel-idol347.dts | 164 +
1 file changed, 164 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
b/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
index fade93c55299..ef5fc9289754 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
@@ -3,6 +3,8 @@
/dts-v1/;
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
@@ -22,6 +24,19 @@ chosen {
stdout-path = "serial0";
};
+ reserved-memory {
+ /delete-node/ reserved@8668;
+ /delete-node/ rmtfs@8670;
+
+ rmtfs: rmtfs@8668 {
+ compatible = "qcom,rmtfs-mem";
+ reg = <0x0 0x8668 0x0 0x16>;
+ no-map;
+
+ qcom,client-id = <1>;
+ };
+ };
+
gpio-keys {
compatible = "gpio-keys";
@@ -50,6 +65,17 @@ led-0 {
};
};
+ reg_headphones_avdd: regulator-headphones-avdd {
+ compatible = "regulator-fixed";
+ regulator-name = "headphones_avdd";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ gpio = < 121 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ pinctrl-0 = <_avdd_default>;
+ pinctrl-names = "default";
+ };
+
usb_id: usb-id {
compatible = "linux,extcon-usb-gpio";
id-gpios = < 69 GPIO_ACTIVE_HIGH>;
@@ -58,6 +84,43 @@ usb_id: usb-id {
};
};
+_i2c3 {
+ status = "okay";
+
+ headphones: audio-codec@10 {
+ compatible = "asahi-kasei,ak4375";
+ reg = <0x10>;
+ avdd-supply = <_headphones_avdd>;
+ tvdd-supply = <_l6>;
+ pdn-gpios = < 114 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <_pdn_default>;
+ pinctrl-names = "default";
+ #sound-dai-cells = <0>;
+ };
+
+ speaker_codec_top: audio-codec@34 {
+ compatible = "nxp,tfa9897";
+ reg = <0x34>;
+ vddd-supply = <_l6>;
+ rcv-gpios = < 50 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <_top_default>;
+ pinctrl-names = "default";
+ sound-name-prefix = "Speaker Top";
+ #sound-dai-cells = <0>;
+ };
+
+ speaker_codec_bottom: audio-codec@36 {
+ compatible = "nxp,tfa9897";
+ reg = <0x36>;
+ vddd-supply = <_l6>;
+ rcv-gpios = < 111 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <_bottom_default>;
+ pinctrl-names = "default";
+ sound-name-prefix = "Speaker Bottom";
+ #sound-dai-cells = <0>;
+ };
+};
+
_i2c4 {
status = "okay";
@@ -153,6 +216,18 @@ _uart2 {
status = "okay";
};
+_mem {
+ reg = <0x0 0x8680 0x0 0x500>;
+};
+
+_codec {
+ qcom,micbias1-ext-cap;
+ qcom,micbias-lvl = <2800>;
+ qcom,mbhc-vthreshold-low = <75 100 120 180 500>;
+ qcom,mbhc-vthreshold-high = <75 100 120 180 500>;
+ qcom,hphl-jack-type-normally-open;
+};
+
_resin {
status = "okay";
linux,code = ;
@@ -169,6 +244,17 @@ _vib {
status = "okay";
};
+ {
+ dai@18 {
+ reg = ;
+ qcom,sd-lines = <0>;
+ };
+ dai@22 {
+ reg = ;
+ qcom,sd-lines = <0>;
+ }
[PATCH 03/13] arm64: dts: qcom: msm8916: Add common msm8916-modem-qdsp6.dtsi
Most MSM8916/MSM8939 devices use very similar setups for the modem,
because most of the device-specific details are abstracted by the modem
firmware. There are several definitions (status switches, DAI links
etc) that will be exactly the same for every board.
Introduce a common msm8916-modem-qdsp6.dtsi include that can be used to
simplify enabling the modem for such devices. By default the
digital/analog codec in the SoC/PMIC is used, but boards can define
additional codecs using the templates for Secondary and Quaternary
MI2S.
Signed-off-by: Stephan Gerhold
---
arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi | 163 ++
1 file changed, 163 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi
b/arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi
new file mode 100644
index ..ddd74d428406
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi
@@ -0,0 +1,163 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-3-Clause)
+/*
+ * msm8916-modem-qdsp6.dtsi describes the typical modem setup on MSM8916
devices
+ * (or similar SoCs) with audio routed via the QDSP6 services provided by the
+ * modem firmware. The digital/analog codec in the SoC/PMIC is used by default,
+ * but boards can define additional codecs using the templates for Secondary
and
+ * Quaternary MI2S.
+ */
+
+#include
+#include
+
+ {
+ status = "okay";
+};
+
+_dmux {
+ status = "okay";
+};
+
+_dmux_dma {
+ status = "okay";
+};
+
+ {
+ status = "reserved"; /* Controlled by QDSP6 */
+};
+
+_codec {
+ status = "okay";
+};
+
+_mem {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_mem {
+ status = "okay";
+};
+
+_codec {
+ status = "okay";
+};
+
+ {
+ dai@16 {
+ reg = ;
+ qcom,sd-lines = <0 1>;
+ };
+ dai@20 {
+ reg = ;
+ qcom,sd-lines = <0 1>;
+ };
+};
+
+ {
+ dai@0 {
+ reg = <0>;
+ direction = ;
+ };
+ dai@1 {
+ reg = <1>;
+ direction = ;
+ };
+ dai@2 {
+ reg = <2>;
+ direction = ;
+ };
+ dai@3 {
+ reg = <3>;
+ direction = ;
+ is-compress-dai;
+ };
+};
+
+ {
+ compatible = "qcom,msm8916-qdsp6-sndcard";
+ model = "msm8916";
+
+ pinctrl-0 = <_pdm_default>;
+ pinctrl-1 = <_pdm_sleep>;
+ pinctrl-names = "default", "sleep";
+
+ multimedia1-dai-link {
+ link-name = "MultiMedia1";
+ cpu {
+ sound-dai = < MSM_FRONTEND_DAI_MULTIMEDIA1>;
+ };
+ };
+
+ multimedia2-dai-link {
+ link-name = "MultiMedia2";
+ cpu {
+ sound-dai = < MSM_FRONTEND_DAI_MULTIMEDIA2>;
+ };
+ };
+
+ multimedia3-dai-link {
+ link-name = "MultiMedia3";
+ cpu {
+ sound-dai = < MSM_FRONTEND_DAI_MULTIMEDIA3>;
+ };
+ };
+
+ multimedia4-dai-link {
+ link-name = "MultiMedia4";
+ cpu {
+ sound-dai = < MSM_FRONTEND_DAI_MULTIMEDIA4>;
+ };
+ };
+
+ sound_dai_primary: mi2s-primary-dai-link {
+ link-name = "Primary MI2S";
+ cpu {
+ sound-dai = < PRIMARY_MI2S_RX>;
+ };
+ platform {
+ sound-dai = <>;
+ };
+ codec {
+ sound-dai = <_codec 0>, <_codec 0>;
+ };
+ };
+
+ sound_dai_secondary: mi2s-secondary-dai-link {
+ link-name = "Secondary MI2S";
+ status = "disabled"; /* Needs extra codec configuration */
+ cpu {
+ sound-dai = < SECONDARY_MI2S_RX>;
+ };
+ platform {
+ sound-dai = <>;
+ };
+ };
+
+ sound_dai_tertiary: mi2s-tertiary-dai-link {
+ link-name = "Tertiary MI2S";
+ cpu {
+ sound-dai = < TERTIARY_MI2S_TX>;
+ };
+ platform {
+ sound-dai = <>;
+ };
+ codec {
+ sound-dai = <_codec 1>, <_codec 1>;
+ };
+ };
+
+ sound_dai_quaternary: mi2s-quaternary-dai-link {
+ link-name = "Quaternary MI2S";
+ status = "disabled"; /* Needs extra codec configuration */
+ cpu {
+ sound-dai = < QUATERNARY_MI2S_RX>;
+ };
+ platform {
+ sound-dai = <>;
+ };
+ };
+};
--
2.42.0
[PATCH 05/13] arm64: dts: qcom: msm8916-samsung-serranove: Add sound and modem
Enable sound and modem for the Samsung S4 Mini Value Edition. The setup
is similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Speaker/earpiece/headphones/microphones via digital/analog codec in
MSM8916/PM8916
- WWAN Internet via BAM-DMUX
except:
- Samsung-specific audio jack detection (not supported yet)
Signed-off-by: Stephan Gerhold
---
arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts
b/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts
index 68da2a2d3077..5f33aa0ad7b5 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-serranove.dts
@@ -6,6 +6,8 @@
/dts-v1/;
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
@@ -319,6 +321,10 @@ _uart2 {
status = "okay";
};
+_mem {
+ reg = <0x0 0x8680 0x0 0x5a0>;
+};
+
_resin {
status = "okay";
linux,code = ;
@@ -350,6 +356,14 @@ _2 {
no-1-8-v;
};
+ {
+ status = "okay";
+ audio-routing =
+ "AMIC1", "MIC BIAS External1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS External1";
+};
+
{
status = "okay";
extcon = <>, <>;
--
2.42.0
[PATCH 11/13] arm64: dts: qcom: msm8916-samsung-gt5: Add sound and modem
From: Jasper Korten
Enable sound and modem for the Samsung Galaxy Tab A 2015 tablets.
The setup is similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Headphones/microphones via digital/analog codec in
MSM8916/PM8916. Earpiece exists on samsung-gt58 only.
- WWAN Internet via BAM-DMUX
except:
- gt510: Stereo Maxim MAX98357A codecs for speaker on Quaternary MI2S
- gt58: Mono NXP TFA9895 codec for speaker on Quaternary MI2S
- For some reason connected to GPIOs where no hardware I2C
controller is available -> need to use i2c-gpio
- Samsung-specific audio jack detection (not supported yet)
Signed-off-by: Jasper Korten
Co-developed-by: Siddharth Manthan
Signed-off-by: Siddharth Manthan
Co-developed-by: Nikita Travkin
Signed-off-by: Nikita Travkin
[Stephan: Add consistent commit message]
Signed-off-by: Stephan Gerhold
---
.../boot/dts/qcom/msm8916-samsung-gt5-common.dtsi | 36 ++
arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts | 23
arch/arm64/boot/dts/qcom/msm8916-samsung-gt58.dts | 43 ++
3 files changed, 102 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi
b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi
index 6a16eb5ce07b..396853fcece5 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt5-common.dtsi
@@ -3,9 +3,12 @@
/dts-v1/;
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
+#include
/ {
aliases {
@@ -116,6 +119,17 @@ _uart2 {
status = "okay";
};
+ {
+ dai-link@3 {
+ reg = ;
+ qcom,playback-sd-lines = <1>;
+ };
+};
+
+_mem {
+ reg = <0x0 0x8680 0x0 0x540>;
+};
+
_resin {
linux,code = ;
status = "okay";
@@ -133,6 +147,13 @@ _usbin {
status = "okay";
};
+ {
+ dai@22 {
+ reg = ;
+ qcom,sd-lines = <1>;
+ };
+};
+
_1 {
status = "okay";
};
@@ -147,6 +168,21 @@ _2 {
status = "okay";
};
+ {
+ audio-routing =
+ "AMIC1", "MIC BIAS External1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS External1";
+};
+
+_dai_quaternary {
+ status = "okay";
+
+ codec {
+ sound-dai = <_codec>;
+ };
+};
+
{
dr_mode = "peripheral";
extcon = <_usbin>;
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts
b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts
index c3f1acc55078..f393e9efa72c 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts
@@ -9,6 +9,14 @@ / {
compatible = "samsung,gt510", "qcom,msm8916";
chassis-type = "tablet";
+ speaker_codec: audio-codec {
+ compatible = "maxim,max98357a";
+ sdmode-gpios = < 55 GPIO_ACTIVE_HIGH>;
+ #sound-dai-cells = <0>;
+ pinctrl-0 = <_sdmode_default>;
+ pinctrl-names = "default";
+ };
+
clk_pwm: pwm {
compatible = "clk-pwm";
#pwm-cells = <2>;
@@ -146,7 +154,22 @@ _dsi0_out {
remote-endpoint = <_in>;
};
+ {
+ model = "samsung-gt510";
+ pinctrl-0 = <_pdm_default _mi2s_default>;
+ pinctrl-1 = <_pdm_sleep _mi2s_sleep>;
+ pinctrl-names = "default", "sleep";
+ status = "okay";
+};
+
{
+ audio_sdmode_default: audio-sdmode-default-state {
+ pins = "gpio55";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
buckbooster_en_default: buckbooster-en-default-state {
pins = "gpio51";
function = "gpio";
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt58.dts
b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt58.dts
index 998625abd409..3f2165556986 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-gt58.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-gt58.dts
@@ -35,6 +35,26 @@ reg_vdd_tsp: regulator-vdd-tsp {
pinctrl-names = "default";
};
+ i2c-amplifier {
+ compatible = "i2c-gpio";
+ sda-gpios = < 55 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+ scl-gpios = < 56 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
+
+ pinctrl-0 = <_i2c_default>;
+ pinctrl-names = "default";
+
+ #address-cells = <
[PATCH 12/13] arm64: dts: qcom: msm8916-samsung-j5: Add sound and modem
From: "Lin, Meng-Bo"
Enable sound and modem for the Samsung J5 smartphones. The setup is
similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Speaker/earpiece/headphones/microphones via digital/analog codec
in MSM8916/PM8916
- WWAN Internet via BAM-DMUX
except:
- There is no secondary microphone, so a different "model" is used to
differentiate that in the UCM configuration.
- Samsung-specific audio jack detection (not supported yet)
Co-developed-by: Markuss Broks
Signed-off-by: Markuss Broks
Signed-off-by: "Lin, Meng-Bo"
[Stephan: Add consistent commit message]
Signed-off-by: Stephan Gerhold
---
arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi | 15 +++
arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts | 4
2 files changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi
b/arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi
index fe59be3505fe..2caa820b0c26 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-j5-common.dtsi
@@ -1,6 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-only
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
@@ -135,6 +137,10 @@ _uart2 {
status = "okay";
};
+_mem {
+ reg = <0x0 0x8680 0x0 0x580>;
+};
+
_resin {
status = "okay";
linux,code = ;
@@ -154,6 +160,15 @@ _2 {
cd-gpios = < 38 GPIO_ACTIVE_LOW>;
};
+ {
+ model = "msm8916-1mic";
+ audio-routing =
+ "AMIC1", "MIC BIAS External1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS External1";
+ status = "okay";
+};
+
{
extcon = <>, <>;
status = "okay";
diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts
b/arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts
index 58c2f5a70e78..ba8650971d6a 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts
@@ -19,6 +19,10 @@ _i2c5 {
status = "disabled";
};
+_codec {
+ qcom,micbias1-ext-cap;
+};
+
{
/* FIXME: Missing sm5703-mfd driver to power up vdd-supply */
};
--
2.42.0
[PATCH 01/13] arm64: dts: qcom: msm8939: Add BAM-DMUX WWAN
From: Vincent Knecht
BAM DMUX is used as the network interface to the modem. This is copied
as-is from msm8916.dtsi.
Signed-off-by: Vincent Knecht
Signed-off-by: Stephan Gerhold
---
arch/arm64/boot/dts/qcom/msm8939.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8939.dtsi
b/arch/arm64/boot/dts/qcom/msm8939.dtsi
index 324b5d26db40..65c68e0e88d5 100644
--- a/arch/arm64/boot/dts/qcom/msm8939.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8939.dtsi
@@ -1537,6 +1537,20 @@ spmi_bus: spmi@200f000 {
#interrupt-cells = <4>;
};
+ bam_dmux_dma: dma-controller@4044000 {
+ compatible = "qcom,bam-v1.7.0";
+ reg = <0x04044000 0x19000>;
+ interrupts = ;
+ #dma-cells = <1>;
+ qcom,ee = <0>;
+
+ num-channels = <6>;
+ qcom,num-ees = <1>;
+ qcom,powered-remotely;
+
+ status = "disabled";
+ };
+
mpss: remoteproc@408 {
compatible = "qcom,msm8916-mss-pil";
reg = <0x0408 0x100>, <0x0402 0x040>;
@@ -1569,6 +1583,22 @@ mpss: remoteproc@408 {
qcom,halt-regs = < 0x18000 0x19000 0x1a000>;
status = "disabled";
+ bam_dmux: bam-dmux {
+ compatible = "qcom,bam-dmux";
+
+ interrupt-parent = <_smsm>;
+ interrupts = <1 IRQ_TYPE_EDGE_BOTH>, <11
IRQ_TYPE_EDGE_BOTH>;
+ interrupt-names = "pc", "pc-ack";
+
+ qcom,smem-states = <_smsm 1>, <_smsm
11>;
+ qcom,smem-state-names = "pc", "pc-ack";
+
+ dmas = <_dmux_dma 4>, <_dmux_dma 5>;
+ dma-names = "tx", "rx";
+
+ status = "disabled";
+ };
+
mba {
memory-region = <_mem>;
};
--
2.42.0
[PATCH 08/13] arm64: dts: qcom: msm8916-asus-z00l: Add sound and modem
From: "J.R. Divya Antony"
Enable sound and modem for the ASUS Zenfone 2 Laser. The setup is
similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Speakear/earpiece/headphones/microphones via digital/analog codec
in MSM8916/PM8916
- Audio jack detection via analog codec in PM8916
- WWAN Internet via BAM-DMUX
Signed-off-by: J.R. Divya Antony
[Stephan: rebase and simplify, add consistent commit message]
Signed-off-by: Stephan Gerhold
---
arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts
b/arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts
index a8be6ff66893..ff8eb0a94795 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts
@@ -3,6 +3,8 @@
/dts-v1/;
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
@@ -130,6 +132,18 @@ _uart2 {
status = "okay";
};
+_mem {
+ reg = <0x0 0x8680 0x0 0x550>;
+};
+
+_codec {
+ qcom,micbias-lvl = <2800>;
+ qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
+ qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
+ qcom,micbias1-ext-cap;
+ qcom,hphl-jack-type-normally-open;
+};
+
_rpm_regulators {
pm8916_l17: l17 {
regulator-min-microvolt = <285>;
@@ -151,6 +165,14 @@ _2 {
cd-gpios = < 38 GPIO_ACTIVE_LOW>;
};
+ {
+ status = "okay";
+ audio-routing =
+ "AMIC1", "MIC BIAS External1",
+ "AMIC2", "MIC BIAS Internal2",
+ "AMIC3", "MIC BIAS External1";
+};
+
{
status = "okay";
extcon = <_id>, <_id>;
--
2.42.0
[PATCH 06/13] arm64: dts: qcom: msm8916-wingtech-wt88047: Add sound and modem
Enable sound and modem for the Xiaomi Redmi 2. The setup
is similar to most MSM8916 devices, i.e.:
- QDSP6 audio
- Earpiece/headphones/microphones via digital/analog codec in
MSM8916/PM8916
- Audio jack detection via analog codec in PM8916
- WWAN Internet via BAM-DMUX
except:
- Speaker amplifier is connected to HPH_R (headphones) output of the
analog codec. There is a separate analog switch that allows disabling
playback via the headphone jack.
Signed-off-by: Stephan Gerhold
---
.../boot/dts/qcom/msm8916-wingtech-wt88047.dts | 76 ++
1 file changed, 76 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dts
b/arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dts
index 419f35c1fc92..600c225a2568 100644
--- a/arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dts
+++ b/arch/arm64/boot/dts/qcom/msm8916-wingtech-wt88047.dts
@@ -6,6 +6,8 @@
/dts-v1/;
#include "msm8916-pm8916.dtsi"
+#include "msm8916-modem-qdsp6.dtsi"
+
#include
#include
#include
@@ -25,6 +27,28 @@ chosen {
stdout-path = "serial0";
};
+ speaker_amp: audio-amplifier {
+ compatible = "simple-audio-amplifier";
+ enable-gpios = < 117 GPIO_ACTIVE_HIGH>;
+ sound-name-prefix = "Speaker Amp";
+ pinctrl-0 = <_amp_default>;
+ pinctrl-names = "default";
+ };
+
+ /*
+* This seems to be actually an analog switch that either routes audio
+* to the headphone jack or nowhere. Given that we need to enable a GPIO
+* to get sound on headphones, modelling it as simple-audio-amplifier
+* works just fine.
+*/
+ headphones_switch: audio-switch {
+ compatible = "simple-audio-amplifier";
+ enable-gpios = < 8 GPIO_ACTIVE_HIGH>;
+ sound-name-prefix = "Headphones Switch";
+ pinctrl-0 = <_switch_default>;
+ pinctrl-names = "default";
+ };
+
flash-led-controller {
compatible = "ocs,ocp8110";
enable-gpios = < 31 GPIO_ACTIVE_HIGH>;
@@ -146,6 +170,18 @@ _uart2 {
status = "okay";
};
+_mem {
+ reg = <0x0 0x8680 0x0 0x510>;
+};
+
+_codec {
+ qcom,micbias1-ext-cap;
+ qcom,micbias-lvl = <2800>;
+ qcom,mbhc-vthreshold-low = <75 100 120 180 500>;
+ qcom,mbhc-vthreshold-high = <75 100 120 180 500>;
+ qcom,hphl-jack-type-normally-open;
+};
+
_resin {
status = "okay";
linux,code = ;
@@ -180,6 +216,32 @@ _2 {
non-removable;
};
+ {
+ status = "okay";
+
+ /*
+* Provide widgets/pin-switches to allow enabling speaker and headphones
+* separately. Both are routed via the HPH_L/HPH_R pins of the codec.
+*/
+ model = "wt88047";
+ widgets =
+ "Speaker", "Speaker",
+ "Headphone", "Headphones";
+ pin-switches = "Speaker", "Headphones";
+ audio-routing =
+ "Speaker", "Speaker Amp OUTL",
+ "Speaker", "Speaker Amp OUTR",
+ "Speaker Amp INL", "HPH_R",
+ "Speaker Amp INR", "HPH_R",
+ "Headphones", "Headphones Switch OUTL",
+ "Headphones", "Headphones Switch OUTR",
+ "Headphones Switch INL", "HPH_L",
+ "Headphones Switch INR", "HPH_R",
+ "AMIC1", "MIC BIAS External1",
+ "AMIC2", "MIC BIAS Internal2";
+ aux-devs = <_amp>, <_switch>;
+};
+
{
status = "okay";
extcon = <_id>, <_id>;
@@ -226,6 +288,13 @@ gpio_keys_default: gpio-keys-default-state {
bias-pull-up;
};
+ headphones_switch_default: headphones-switch-default-state {
+ pins = "gpio8";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
imu_default: imu-default-state {
pins = "gpio115";
function = "gpio";
@@ -234,6 +303,13 @@ imu_default: imu-default-state {
bias-disable;
};
+ speaker_amp_default: speaker-amp-default-state {
+ pins = "gpio117";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
touchscreen_default: touchscreen-default-state {
touchscreen-pins {
pins = "gpio13";
--
2.42.0
[PATCH 00/13] arm64: dts: qcom: msm8916/39: Enable sound and modem with QDSP6
Enable sound and modem on most of the MSM8916/MSM8939 smartphones/tablets supported upstream by: - Adding the BAM-DMUX DT nodes to msm8939.dtsi for WWAN Internet - Adding the QDSP6 DT nodes to both msm8916.dtsi and msm8939.dtsi. This is needed because audio must be routed through the QDSP6 services provided by the modem firmware when the modem is active. - Setting up the sound/codec related nodes for all the devices. Most of the sound/modem setup is very similar on all MSM8916/MSM8939 devices because the device-specific details are abstracted by the modem firmware. Reduce duplication by adding "msm8916-modem-qdsp6.dtsi" which contains most of the common definitions. The board-specific DT part is limited to extra codecs or board-specific sound setup. With this patch set, the following functionality works on most MSM8916/MSM8939 devices supported upstream: - Sound: Speaker/earpiece/headphones/microphones - Modem: Calls, SMS, WWAN Internet (e.g. with ModemManager) And with extra pending patches also: - Voice call audio - GPS These patches have been contributed by different people and have been used/tested in postmarketOS for several years. Until now they had to wait for other changes to be upstreamed (QDSP6 audio support for MSM8916, dynamic reserved memory, ...). Signed-off-by: Stephan Gerhold --- J.R. Divya Antony (1): arm64: dts: qcom: msm8916-asus-z00l: Add sound and modem Jasper Korten (1): arm64: dts: qcom: msm8916-samsung-gt5: Add sound and modem Jonathan Albrieux (1): arm64: dts: qcom: msm8916-longcheer-l8910: Add sound and modem Lin, Meng-Bo (2): arm64: dts: qcom: msm8916-samsung-j5: Add sound and modem arm64: dts: qcom: msm8939-samsung-a7: Add sound and modem Nikita Travkin (1): arm64: dts: qcom: msm8916-longcheer-l8150: Add sound and modem Stephan Gerhold (5): arm64: dts: qcom: msm8916/39: Add QDSP6 arm64: dts: qcom: msm8916: Add common msm8916-modem-qdsp6.dtsi arm64: dts: qcom: msm8916-samsung-a2015: Add sound and modem arm64: dts: qcom: msm8916-samsung-serranove: Add sound and modem arm64: dts: qcom: msm8916-wingtech-wt88047: Add sound and modem Vincent Knecht (2): arm64: dts: qcom: msm8939: Add BAM-DMUX WWAN arm64: dts: qcom: msm8916-alcatel-idol347: Add sound and modem .../boot/dts/qcom/msm8916-alcatel-idol347.dts | 164 + arch/arm64/boot/dts/qcom/msm8916-asus-z00l.dts | 22 +++ .../boot/dts/qcom/msm8916-longcheer-l8150.dts | 32 +++- .../boot/dts/qcom/msm8916-longcheer-l8910.dts | 54 +++ arch/arm64/boot/dts/qcom/msm8916-modem-qdsp6.dtsi | 163 .../dts/qcom/msm8916-samsung-a2015-common.dtsi | 55 +++ .../dts/qcom/msm8916-samsung-e2015-common.dtsi | 4 + .../boot/dts/qcom/msm8916-samsung-grandmax.dts | 4 + .../boot/dts/qcom/msm8916-samsung-gt5-common.dtsi | 36 + arch/arm64/boot/dts/qcom/msm8916-samsung-gt510.dts | 23 +++ arch/arm64/boot/dts/qcom/msm8916-samsung-gt58.dts | 43 ++ .../boot/dts/qcom/msm8916-samsung-j5-common.dtsi | 15 ++ arch/arm64/boot/dts/qcom/msm8916-samsung-j5.dts| 4 + .../boot/dts/qcom/msm8916-samsung-serranove.dts| 14 ++ .../boot/dts/qcom/msm8916-wingtech-wt88047.dts | 76 ++ arch/arm64/boot/dts/qcom/msm8916.dtsi | 49 ++ arch/arm64/boot/dts/qcom/msm8939-samsung-a7.dts| 54 +++ arch/arm64/boot/dts/qcom/msm8939.dtsi | 79 ++ 18 files changed, 888 insertions(+), 3 deletions(-) --- change-id: 20230922-msm8916-modem-0d8b6c8abf76 Best regards, -- Stephan Gerhold
Re: [PATCH 1/2] pinctrl: qcom: msm8226: Add MPM pin mappings
On Sat, Sep 23, 2023 at 01:19:46PM +0200, Luca Weiss wrote:
> On Samstag, 23. September 2023 12:00:52 CEST Stephan Gerhold wrote:
> > On Sat, Sep 23, 2023 at 11:32:47AM +0200, Luca Weiss wrote:
> > > Hi Matti,
> > >
> > > On Samstag, 23. September 2023 00:40:26 CEST Matti Lehtimäki wrote:
> > > > Add pin <-> wakeirq mappings to allow for waking up the AP from sleep
> > > > through MPM-connected pins.
> > > >
> > > > Signed-off-by: Matti Lehtimäki
> > > > ---
> > > >
> > > > drivers/pinctrl/qcom/pinctrl-msm8226.c | 12
> > > > 1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/drivers/pinctrl/qcom/pinctrl-msm8226.c
> > > > b/drivers/pinctrl/qcom/pinctrl-msm8226.c index
> > > > 994619840a70..1e46a9ab382f
> > > > 100644
> > > > --- a/drivers/pinctrl/qcom/pinctrl-msm8226.c
> > > > +++ b/drivers/pinctrl/qcom/pinctrl-msm8226.c
> > > > @@ -612,6 +612,16 @@ static const struct msm_pingroup msm8226_groups[] =
> > > > {
> > > >
> > > > #define NUM_GPIO_PINGROUPS 117
> > > >
> > > > +static const struct msm_gpio_wakeirq_map msm8226_mpm_map[] = {
> > > > + { 1, 3 }, { 4, 4 }, { 5, 5 }, { 9, 6 }, { 13, 7 }, { 17, 8 },
> > >
> > > I'm not really convinced this is the correct order of values...
> > >
> > > Let's look at downstream:
> > > qcom,gpio-map = <3 1>,
> > >
> > > <4 4 >,
> > > <5 5 >,
> > > <6 9 >,
> > > [...]
> > >
> > > From Documentation/devicetree/bindings/arm/msm/mpm.txt downstream:
> > > Each tuple represents a MPM pin and which GIC interrupt is routed to it.
> > >
> > > So first is pin number, second is interrupt number.
> > >
> > > And check mainline:
> > > /**
> > >
> > >* struct msm_gpio_wakeirq_map - Map of GPIOs and their wakeup pins
> > >* @gpio: The GPIOs that are wakeup capable
> > >* @wakeirq: The interrupt at the always-on interrupt controller
> > >*/
> > >
> > > struct msm_gpio_wakeirq_map {
> > >
> > > unsigned int gpio;
> > > unsigned int wakeirq;
> > >
> > > };
> > >
> > > So here we also have the order pin-interrupt, not the reverse order.
> > >
> > > Therefore I believe the order in this patch is incorrect, and it should
> > > rather>
> > > be:
> > > { 3, 1 }, { 4, 4 }, { 5, 5 }, { 6, 9 }, { 7, 13 }, { 8, 17 },
> > > [...]
> > >
> > > Or do you think I'm missing something?
> >
> > Yes :)
> >
> > Let's look at the later entries:
> > > > + { 21, 9 }, { 27, 10 }, { 29, 11 }, { 31, 12 }, { 33, 13 }, {
> > > > 35, 14
> > >
> > > },
> > >
> > > > + { 37, 15 }, { 38, 16 }, { 39, 17 }, { 41, 18 }, { 46, 19 }, {
> > > > 48, 20
> > >
> > > },
> > >
> > > > + { 49, 21 }, { 50, 22 }, { 51, 23 }, { 52, 24 }, { 54, 25 }, {
> > > > 62, 26
> > >
> > > },
> > >
> > > > + { 63, 27 }, { 64, 28 }, { 65, 29 }, { 66, 30 }, { 67, 31 }, {
> > > > 68, 32
> > >
> > > },
> > >
> > > > + { 69, 33 }, { 71, 34 }, { 72, 35 }, { 106, 36 }, { 107, 37 },
> > > > + { 108, 38 }, { 109, 39 }, { 110, 40 }, { 111, 54 }, { 113, 55 },
> > > > +};
> > > > +
> >
> > For example: { 113, 55 }, i.e. { .gpio = 113, .wakeirq = 55 }.
> >
> > MSM8226 has GPIOs 0-116 and 64 MPM pins/interrupts. The order in this
> > patch is the only one that can be correct because the definition would
> > be invalid the other way around. 113 must be the GPIO number because it
> > is larger than the 64 available MPM interrupt pins. :)
>
> So basically you're saying downstream is wrong / buggy?
>
"Misleading" or "confusing" would be the words I would use. :-)
> From qcom,gpio-map = [...], <55 113>; it's taking the properties like this
> (drivers/soc/qcom/mpm-of.c):
>
> unsigned long pin = be32_to_cpup(list++);
> irq_hw_number_t hwirq = be32_to_cpup(list++);
>
> Your explanation does make sense I guess but somewhere the link downstream ->
> mainline must be broken, no?
>
After staring at mpm-of.c for a while I would say that there:
- downstream "pin" = MPM pin = mainline "wakeirq"
- because this is used as index to msm_mpm_irqs_m2a, which has a size
of MSM_MPM_NR_MPM_IRQS (64)
- downstream "hwirq" = GPIO / GIC IRQ = mainline "gpio"
This means for <55 113>: pin = wakeirq = 55 and hwirq = gpio = 113.
Which matches the definition in this patch:
{ .gpio = 113, .wakeirq = 55 } = { 113, 55 }
Stephan
Re: [PATCH 1/2] pinctrl: qcom: msm8226: Add MPM pin mappings
On Sat, Sep 23, 2023 at 11:32:47AM +0200, Luca Weiss wrote:
> Hi Matti,
>
> On Samstag, 23. September 2023 00:40:26 CEST Matti Lehtimäki wrote:
> > Add pin <-> wakeirq mappings to allow for waking up the AP from sleep
> > through MPM-connected pins.
> >
> > Signed-off-by: Matti Lehtimäki
> > ---
> > drivers/pinctrl/qcom/pinctrl-msm8226.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/pinctrl/qcom/pinctrl-msm8226.c
> > b/drivers/pinctrl/qcom/pinctrl-msm8226.c index 994619840a70..1e46a9ab382f
> > 100644
> > --- a/drivers/pinctrl/qcom/pinctrl-msm8226.c
> > +++ b/drivers/pinctrl/qcom/pinctrl-msm8226.c
> > @@ -612,6 +612,16 @@ static const struct msm_pingroup msm8226_groups[] = {
> >
> > #define NUM_GPIO_PINGROUPS 117
> >
> > +static const struct msm_gpio_wakeirq_map msm8226_mpm_map[] = {
> > + { 1, 3 }, { 4, 4 }, { 5, 5 }, { 9, 6 }, { 13, 7 }, { 17, 8 },
>
> I'm not really convinced this is the correct order of values...
>
> Let's look at downstream:
>
> qcom,gpio-map = <3 1>,
> <4 4 >,
> <5 5 >,
> <6 9 >,
> [...]
>
> From Documentation/devicetree/bindings/arm/msm/mpm.txt downstream:
>
> Each tuple represents a MPM pin and which GIC interrupt is routed to it.
>
> So first is pin number, second is interrupt number.
>
> And check mainline:
>
> /**
>* struct msm_gpio_wakeirq_map - Map of GPIOs and their wakeup pins
>* @gpio: The GPIOs that are wakeup capable
>* @wakeirq: The interrupt at the always-on interrupt controller
>*/
> struct msm_gpio_wakeirq_map {
> unsigned int gpio;
> unsigned int wakeirq;
> };
>
> So here we also have the order pin-interrupt, not the reverse order.
>
> Therefore I believe the order in this patch is incorrect, and it should
> rather
> be:
>
> { 3, 1 }, { 4, 4 }, { 5, 5 }, { 6, 9 }, { 7, 13 }, { 8, 17 },
> [...]
>
> Or do you think I'm missing something?
>
Yes :)
Let's look at the later entries:
> > + { 21, 9 }, { 27, 10 }, { 29, 11 }, { 31, 12 }, { 33, 13 }, { 35, 14
> },
> > + { 37, 15 }, { 38, 16 }, { 39, 17 }, { 41, 18 }, { 46, 19 }, { 48, 20
> },
> > + { 49, 21 }, { 50, 22 }, { 51, 23 }, { 52, 24 }, { 54, 25 }, { 62, 26
> },
> > + { 63, 27 }, { 64, 28 }, { 65, 29 }, { 66, 30 }, { 67, 31 }, { 68, 32
> },
> > + { 69, 33 }, { 71, 34 }, { 72, 35 }, { 106, 36 }, { 107, 37 },
> > + { 108, 38 }, { 109, 39 }, { 110, 40 }, { 111, 54 }, { 113, 55 },
> > +};
> > +
For example: { 113, 55 }, i.e. { .gpio = 113, .wakeirq = 55 }.
MSM8226 has GPIOs 0-116 and 64 MPM pins/interrupts. The order in this
patch is the only one that can be correct because the definition would
be invalid the other way around. 113 must be the GPIO number because it
is larger than the 64 available MPM interrupt pins. :)
Thanks,
Stephan
Re: [PATCH v2] firmware: qcom_scm: Only compile legacy calls on ARM
On Wed, Apr 07, 2021 at 05:12:06PM -0700, Stephen Boyd wrote: > Quoting Stephan Gerhold (2021-04-05 05:50:26) > > On Fri, Apr 02, 2021 at 10:21:58AM -0700, Stephen Boyd wrote: > > > > > > Ah right, the whole secure world running in 32-bit mode thing. Is > > > msm8916 the only SoC that's using that? Or are there more? If only > > > msm8916 is affected then we could use a combination of CONFIG_ARM64 and > > > the compatible string to differentiate and then if more SoCs use 32-bit > > > secure world then we could have a new compatible string like qcom,scm-32 > > > that tells us this fact. Maybe this was all discussed before and I > > > missed it. Either way, I'm trying to get rid of this boot call so that > > > we don't have to bounce to the firmware an extra time to figure out > > > something we can figure out from the kernel arch and scm compatible > > > string. > > > > At least MSM8994 also uses SMC32 from what I heard. Overall it's > > probably quite hard to get that right now since all boards were tested > > with the dynamic detection so far. I suppose you could do the opposite, > > add an optional qcom,scm-64 to skip the detection step and force SMC64. > > Isn't SMC64 going to be the overall majority going forward? Legacy > convention is for sure limited to CONFIG_ARM so I'll send another > follow-up patch to add a warning if we find legacy on CONFIG_ARM64. > SMC32 is hopefully no longer being produced given that it was introduced > at the time that the bootloader team wasn't supporting PSCI and didn't > want to support it. So we're making all new boards/SoCs/firmwares do > this calling convention probing to figure out something they already > know? > > Maybe we should probe the calling convention on msm8994/msm8916 and > otherwise assume SMC64 on CONFIG_ARM64 kernels. I'd expect the exception > list to be smaller that way. > Personally, I think it would be best to introduce a new, SMC64 only compatible (e.g. "qcom,scm-64" like I mentioned). Then you can skip the detection check for the boards that opt-in by adding the compatible. You can then use it on all newer boards/SoCs/firmwares where you know exactly that there is SMC64. I would just like to avoid breaking any existing boards where we don't know exactly if they have SMC32 or SMC64. > > > > Also note that this could even be firmware-specific, not necessarily > > SoC-specific. There are some ancient MSM8916 firmwares that have legacy > > instead of SMC32. I could also imagine that there is also some SoC where > > there are different firmware versions with SMC32 or SMC64. > > Sure but in theory the firmware would update the DT to indicate what > sort of firmware is there. > In a perfect world the firmware would do that, but there is certainly no such mechanism on any of the old SoCs :/ > > > > Plus, IMO the overhead for this detection is negligible. At least it > > ensures that we always use the right calling convention. The PSCI code > > probably does much more firmware calls to figure out all supported > > features. > > > > Heh, it tried to ensure we use the right calling convention but broke > things in the process, because the way of detecting the convention isn't > always there. I wouldn't be surprised if this comes up again for other > boards that use TF-A. Ah okay, this sounds like a better reason than just trying to avoid the "overhead" of the detection step. :) I still think it should work if you just start marking all newer boards/SoCs/... as "qcom,scm-64" or something like that, right? Thanks, Stephan
Re: [RESEND PATCH] arm64: dts: qcom: sdm845-xiaomi-beryllium: Add audio support
On Thu, Apr 08, 2021 at 01:37:53AM +0530, Joel Selvaraj wrote:
> This patch adds audio support for Xiaomi Poco F1 phone. Phone's primary
> Mic and 3.5mm Headphone jack are handled through the SDM845 sound card
> and WCD9340 codec.
>
> Tested-by: Amit Pundir
> Signed-off-by: Joel Selvaraj
> ---
> .../boot/dts/qcom/sdm845-xiaomi-beryllium.dts | 117 ++
> 1 file changed, 117 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> index 86cbae63eaf7..5b5786595cdb 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> +++ b/arch/arm64/boot/dts/qcom/sdm845-xiaomi-beryllium.dts
> [...]
> @@ -257,6 +281,73 @@ _2 {
> cd-gpios = < 126 GPIO_ACTIVE_HIGH>;
> };
>
> + {
> + compatible = "qcom,db845c-sndcard";
> + pinctrl-0 = <_mi2s_active
> + _mi2s_sd0_active>;
> + pinctrl-names = "default";
> + model = "Xiaomi Poco F1";
> + audio-routing =
> + "RX_BIAS", "MCLK",
> + "AMIC1", "MIC BIAS1",
> + "AMIC2", "MIC BIAS2",
> + "AMIC3", "MIC BIAS3",
> + "MM_DL1", "MultiMedia1 Playback",
> + "MM_DL2", "MultiMedia2 Playback",
> + "MultiMedia3 Capture", "MM_UL3";
> +
FYI, the MM_DL/MM_UL audio routes should not be necessary anymore since
commit 6fd8d2d275f7 ("ASoC: qcom: qdsp6: Move frontend AIFs to q6asm-dai")
(part of Linux 5.12). Can you try if everything still works without them?
Thanks,
Stephan
Re: [PATCH v2] firmware: qcom_scm: Only compile legacy calls on ARM
On Fri, Apr 02, 2021 at 10:21:58AM -0700, Stephen Boyd wrote: > Quoting Stephan Gerhold (2021-04-02 03:18:04) > > On Thu, Apr 01, 2021 at 11:58:48PM -0700, Stephen Boyd wrote: > > > [...] > > > > > > Maybe it would be better to catch that problem at the source and force > > > arm64 calling convention to be safe? I'm thinking of this patch, but it > > > could be even more fine tuned and probably the sc7180 check could be > > > removed in the process if the rest of this email makes sense. > > > > > > If I understand correctly CONFIG_ARM64=y should never use legacy > > > convention (and never the 32-bit one either?), so we can figure that out > > > pretty easily and just force it to use 64-bit if the architecture is > > > arm64. If only the 64-bit convention is supported on arm64 then we > > > really don't even need to call into the firmware to figure it out on > > > arm64. We can do this convention detection stuff on arm32 (CONFIG_ARM) > > > and always assume 64-bit convention on CONFIG_ARM64. Is that right? > > > > > > > No, the detection is also needed on ARM64. On ARM32 there can be either > > legacy or SMC32, but on ARM64 there can be either SMC32 or SMC64. > > You cannot use SMC64 on 32-bit, but you can use SMC32 on ARM64 just > > fine. SMC32 is used on MSM8916 for example. > > > > Ah right, the whole secure world running in 32-bit mode thing. Is > msm8916 the only SoC that's using that? Or are there more? If only > msm8916 is affected then we could use a combination of CONFIG_ARM64 and > the compatible string to differentiate and then if more SoCs use 32-bit > secure world then we could have a new compatible string like qcom,scm-32 > that tells us this fact. Maybe this was all discussed before and I > missed it. Either way, I'm trying to get rid of this boot call so that > we don't have to bounce to the firmware an extra time to figure out > something we can figure out from the kernel arch and scm compatible > string. At least MSM8994 also uses SMC32 from what I heard. Overall it's probably quite hard to get that right now since all boards were tested with the dynamic detection so far. I suppose you could do the opposite, add an optional qcom,scm-64 to skip the detection step and force SMC64. Also note that this could even be firmware-specific, not necessarily SoC-specific. There are some ancient MSM8916 firmwares that have legacy instead of SMC32. I could also imagine that there is also some SoC where there are different firmware versions with SMC32 or SMC64. Plus, IMO the overhead for this detection is negligible. At least it ensures that we always use the right calling convention. The PSCI code probably does much more firmware calls to figure out all supported features. Stephan
Re: [PATCH v3] arm64: dts: msm8916: Enable CoreSight STM component
On Sun, Mar 21, 2021 at 08:42:12PM +0800, Leo Yan wrote:
> From: Georgi Djakov
>
> Add DT binding for CoreSight System Trace Macrocell (STM) on msm8916,
> which can benefit the CoreSight development on DB410c.
>
> Signed-off-by: Georgi Djakov
> Signed-off-by: Leo Yan
Thanks for sending the new patch so quickly!
The changes look good to me but I cannot really say if they are fully
correct or work correctly. (Actually I have no idea how to use coresight
or how it is useful! :D)
FWIW:
Acked-by: Stephan Gerhold
> ---
>
> Changes from v2:
> * Correct for author name.
>
> Changes from v1:
> * alphabetically and address ordering for DT node; pad addresses with
> zeroes (Stephan Gerhold).
>
> arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 1 +
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 27 +++
> 2 files changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> index 3a9538e1ec97..2165b7415add 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> @@ -410,6 +410,7 @@ _codec {
> { status = "okay"; };
> { status = "okay"; };
> { status = "okay"; };
> + { status = "okay"; };
> { status = "okay"; };
>
> _rpm_regulators {
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 402e891a84ab..f02b976480d5 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -489,6 +489,26 @@ snoc: interconnect@58 {
>< RPM_SMD_SNOC_A_CLK>;
> };
>
> + stm: stm@802000 {
> + compatible = "arm,coresight-stm", "arm,primecell";
> + reg = <0x00802000 0x1000>,
> + <0x0928 0x18>;
> + reg-names = "stm-base", "stm-stimulus-base";
> +
> + clocks = < RPM_QDSS_CLK>, < RPM_QDSS_A_CLK>;
> + clock-names = "apb_pclk", "atclk";
> +
> + status = "disabled";
> +
> + out-ports {
> + port {
> + stm_out: endpoint {
> + remote-endpoint =
> <_in7>;
> + };
> + };
> + };
> + };
> +
> /* System CTIs */
> /* CTI 0 - TMC connections */
> cti0: cti@81 {
> @@ -562,6 +582,13 @@ funnel0_in4: endpoint {
> remote-endpoint =
> <_out>;
> };
> };
> +
> + port@7 {
> + reg = <7>;
> + funnel0_in7: endpoint {
> + remote-endpoint = <_out>;
> + };
> + };
> };
>
> out-ports {
> --
> 2.25.1
>
Re: [PATCH v2] firmware: qcom_scm: Only compile legacy calls on ARM
On Thu, Apr 01, 2021 at 11:58:48PM -0700, Stephen Boyd wrote:
> Quoting Elliot Berman (2021-04-01 18:12:14)
> >
> > It might be a good idea to wrap these lines from qcom_scm_call with #if
> > IS_ENABLED(CONFIG_ARM), and the corresponding ones in qcom_scm_call_atomic:
> >
> >case SMC_CONVENTION_LEGACY:
> >return scm_legacy_call(dev, desc, res);
> >
> > If something is wrong with loaded firmware and LEGACY convention is
> > incorrectly selected, you would get a better hint about the problem:
> > "Unknown current SCM calling convention." You would still get the hint
> > earlier from __get_convention, but that may not be obvious to someone
> > unfamiliar with the SCM driver.
> >
> > I'll defer to your/Bjorn's preference:
> >
> > Acked-by: Elliot Berman
> >
> > with or without modifying qcom_scm_call{_atomic}.
> >
>
> Maybe it would be better to catch that problem at the source and force
> arm64 calling convention to be safe? I'm thinking of this patch, but it
> could be even more fine tuned and probably the sc7180 check could be
> removed in the process if the rest of this email makes sense.
>
> If I understand correctly CONFIG_ARM64=y should never use legacy
> convention (and never the 32-bit one either?), so we can figure that out
> pretty easily and just force it to use 64-bit if the architecture is
> arm64. If only the 64-bit convention is supported on arm64 then we
> really don't even need to call into the firmware to figure it out on
> arm64. We can do this convention detection stuff on arm32 (CONFIG_ARM)
> and always assume 64-bit convention on CONFIG_ARM64. Is that right?
>
No, the detection is also needed on ARM64. On ARM32 there can be either
legacy or SMC32, but on ARM64 there can be either SMC32 or SMC64.
You cannot use SMC64 on 32-bit, but you can use SMC32 on ARM64 just
fine. SMC32 is used on MSM8916 for example.
Stephan
Re: [PATCH 5/5] arm64: dts: qcom: msm8916: Enable modem and WiFi
Hi Bjorn,
On Thu, Mar 11, 2021 at 04:33:18PM -0800, Bjorn Andersson wrote:
> Enable the modem and WiFi subsystems and specify msm8916 specific
> firmware path for these and the WCNSS control service.
>
> Signed-off-by: Bjorn Andersson
The changes itself look good to me, but the commit message is really
misleading. It does not mention anywhere that the change actually just
enables "modem" on apq8016-sbc instead of "msm8916". :)
Also, WCNSS was actually enabled before already (with the default
firmware path). In my opinion, it would be clearer to change the
firmware-name for it in an extra patch.
> ---
> arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 12
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 2 +-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> index 6aef0c2e4f0a..448e3561ef63 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> @@ -305,6 +305,12 @@ {
> status = "okay";
> };
>
> + {
> + status = "okay";
> +
> + firmware-name = "qcom/msm8916/mba.mbn", "qcom/msm8916/modem.mbn";
> +};
> +
> _resin {
> status = "okay";
> linux,code = ;
> @@ -312,6 +318,8 @@ _resin {
>
> {
> status = "okay";
> +
> + firmware-name = "qcom/msm8916/wcnss.mbn";
> };
>
How do I get a .mbn from the wcnss.{mdt,.b??} files provided in the
DB410c firmware package? I guess I should just run them through
https://github.com/andersson/pil-squasher?
Also, is the single file format (mbn) preferred now? Not sure if there
is any significant difference except having less files laying around.
Thanks,
Stephan
Re: [PATCH 4.14 07/15] driver core: Extend device_is_dependent()
On Fri, Feb 05, 2021 at 09:52:56AM -0800, Saravana Kannan wrote:
> On Fri, Feb 5, 2021 at 6:14 AM Greg Kroah-Hartman
> wrote:
> >
> > From: "Rafael J. Wysocki"
> >
> > commit 3d1cf435e201d1fd63e4346b141881aed086effd upstream
> >
> > If the device passed as the target (second argument) to
> > device_is_dependent() is not completely registered (that is, it has
> > been initialized, but not added yet), but the parent pointer of it
> > is set, it may be missing from the list of the parent's children
> > and device_for_each_child() called by device_is_dependent() cannot
> > be relied on to catch that dependency.
> >
> > For this reason, modify device_is_dependent() to check the ancestors
> > of the target device by following its parent pointer in addition to
> > the device_for_each_child() walk.
> >
> > Fixes: 9ed9895370ae ("driver core: Functional dependencies tracking
> > support")
> > Reported-by: Stephan Gerhold
> > Tested-by: Stephan Gerhold
> > Reviewed-by: Saravana Kannan
> > Signed-off-by: Rafael J. Wysocki
> > Link: https://lore.kernel.org/r/17705994.d592GUb2YH@kreacher
> > Cc: stable
> > Signed-off-by: Greg Kroah-Hartman
> > Signed-off-by: Sudip Mukherjee
> > Signed-off-by: Greg Kroah-Hartman
> > ---
> > drivers/base/core.c | 17 -
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > --- a/drivers/base/core.c
> > +++ b/drivers/base/core.c
> > @@ -96,6 +96,16 @@ void device_links_read_unlock(int not_us
> > }
> > #endif /* !CONFIG_SRCU */
> >
> > +static bool device_is_ancestor(struct device *dev, struct device *target)
> > +{
> > + while (target->parent) {
> > + target = target->parent;
> > + if (dev == target)
> > + return true;
> > + }
> > + return false;
> > +}
> > +
> > /**
> > * device_is_dependent - Check if one device depends on another one
> > * @dev: Device to check dependencies for.
> > @@ -109,7 +119,12 @@ static int device_is_dependent(struct de
> > struct device_link *link;
> > int ret;
> >
> > - if (dev == target)
> > + /*
> > +* The "ancestors" check is needed to catch the case when the target
> > +* device has not been completely initialized yet and it is still
> > +* missing from the list of children of its parent device.
> > +*/
> > + if (dev == target || device_is_ancestor(dev, target))
> > return 1;
> >
> > ret = device_for_each_child(dev, target, device_is_dependent);
> >
> >
>
> I think 4.14 device links API is so busted it's not worth patching
> this. It's not a memory leak or any kind of security issue.
>
> Stephan, are you seeing this issue in 4.14 or even care about it?
>
I guess I'm too late here (sorry about this), but in any case:
Actually, the issue I had only caused problems in some of the early 5.11
release candidates. The cyclic device link was also created on earlier
kernel versions, but (seemingly) did not cause any issues so far.
I try to stay on RCs/stable kernel versions so as far as
I'm concerned there is no need to backport this to 4.14.
Thanks!
Stephan
Re: [PATCH v2 3/4] arm64: dts: qcom: Disable MDSS by default for 8916/8016 devices
On Sat, Jan 30, 2021 at 11:57:12AM +0100, Vincent Knecht wrote:
> Disable MDSS (Mobile Display Subsystem) by default in msm8916.dtsi
> and only explicitly enable it in devices' DT which actually use it.
>
> This leads to faster boot and cleaner logs for other devices,
> which also won't have to explicitly disable MDSS to use framebuffer.
>
> Signed-off-by: Vincent Knecht
Thanks for the patch! I think this is a good thing because normally most
things are disabled by default in msm8916.dtsi (e.g. eMMC, SD card,
WCNSS, ). Also, there are actually some devices that don't have a
display (e.g. the 4IoT board [1]). Having to disable it specifically is
kind of weird. So:
Reviewed-by: Stephan Gerhold
[1]: https://www.96boards.org/product/4iot/
> ---
> arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi | 4
> arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi | 4
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 +
> 3 files changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> index 3a9538e1ec97..6aef0c2e4f0a 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> @@ -301,6 +301,10 @@ {
> status = "okay";
> };
>
> + {
> + status = "okay";
> +};
> +
> _resin {
> status = "okay";
> linux,code = ;
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
> b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
> index f1af798abd74..230ba3ce3277 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916-samsung-a2015-common.dtsi
> @@ -132,6 +132,10 @@ {
> pinctrl-1 = <_sleep>;
> };
>
> + {
> + status = "okay";
> +};
> +
> _resin {
> status = "okay";
> linux,code = ;
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 402e891a84ab..8f9a651d3827 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -913,6 +913,7 @@ tcsr: syscon@1937000 {
> };
>
> mdss: mdss@1a0 {
> + status = "disabled";
> compatible = "qcom,mdss";
> reg = <0x01a0 0x1000>,
> <0x01ac8000 0x3000>;
> --
> 2.29.2
>
>
>
Re: [PATCH v2 2/4] arm64: dts: qcom: Add device tree for Alcatel Idol 3 (4.7")
On Sat, Jan 30, 2021 at 11:57:11AM +0100, Vincent Knecht wrote:
> The Alcatel Idol 3 (4.7") is a smartphone based on MSM8916.
> Add a device tree with support for USB, eMMC, SD-Card, WiFi,
> BT, power/volume buttons, vibrator and the following sensors:
> magnetometer, accelerometer, gyroscope, ambient light+proximity
>
> Signed-off-by: Vincent Knecht
Reviewed-by: Stephan Gerhold
> ---
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> .../boot/dts/qcom/msm8916-alcatel-idol347.dts | 291 ++
> 2 files changed, 292 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile
> b/arch/arm64/boot/dts/qcom/Makefile
> index 59455db7b493..0feeedb712cc 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -5,6 +5,7 @@ dtb-$(CONFIG_ARCH_QCOM) += apq8096-db820c.dtb
> dtb-$(CONFIG_ARCH_QCOM) += apq8096-ifc6640.dtb
> dtb-$(CONFIG_ARCH_QCOM) += ipq6018-cp01-c1.dtb
> dtb-$(CONFIG_ARCH_QCOM) += ipq8074-hk01.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += msm8916-alcatel-idol347.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8916-asus-z00l.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8916-longcheer-l8150.dtb
> dtb-$(CONFIG_ARCH_QCOM) += msm8916-mtp.dtb
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
> b/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
> new file mode 100644
> index ..540b1fa4b260
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/msm8916-alcatel-idol347.dts
> @@ -0,0 +1,291 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +/dts-v1/;
> +
> +#include "msm8916-pm8916.dtsi"
> +#include
> +#include
> +
> +/ {
> + model = "Alcatel OneTouch Idol 3 (4.7)";
> + compatible = "alcatel,idol347", "qcom,msm8916";
> +
> + aliases {
> + serial0 = _uart2;
> + };
> +
> + chosen {
> + stdout-path = "serial0";
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_keys_default>;
> +
> + label = "GPIO Buttons";
> +
> + volume-up {
> + label = "Volume Up";
> + gpios = < 107 GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + usb_id: usb-id {
> + compatible = "linux,extcon-usb-gpio";
> + id-gpio = < 69 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_id_default>;
> + };
> +};
> +
> +_uart2 {
> + status = "okay";
> +};
> +
> +_i2c5 {
> + status = "okay";
> +
> + magnetometer@c {
> + compatible = "asahi-kasei,ak09911";
> + reg = <0x0c>;
> + vdd-supply = <_l17>;
> + vid-supply = <_l6>;
> + reset-gpios = < 8 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_reset_default>;
> + mount-matrix = "0", "1", "0",
> +"-1", "0", "0",
> +"0", "0", "1";
> + };
> +
> + accelerometer@f {
> + compatible = "kionix,kxtj21009";
> + reg = <0x0f>;
> + vdd-supply = <_l17>;
> + vddio-supply = <_l6>;
> + interrupt-parent = <>;
> + interrupts = <31 IRQ_TYPE_EDGE_RISING>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_int_default>;
> + mount-matrix = "-1", "0", "0",
> +"0", "1", "0",
> +"0", "0", "-1";
> + };
> +
> + proximity@48 {
> + compatible = "sensortek,stk3310";
> + reg = <0x48>;
> + interrupt-parent = <>;
> + interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_int_default>;
> + };
> +
> + gyroscope@68 {
> + compatible = "bosch,bmg160";
> + reg = <0x68>;
> + vd
Re: [PATCH 0/3] Add initial support for BQ Aquaris X5
On Wed, Jan 27, 2021 at 11:24:07PM +0100, Pavel Machek wrote: > > > How close are you to having useful phone calls? > > > > You can do phone calls (with audio) and you can use mobile data, if you > > have the patches for that. :) I'm trying to find time to finish up the > > drivers needed for that, but I've been a bit short on time lately. > > > Most of the functionality is packaged in postmarketOS [1] and you can > > find a list of the devices in the postmarketOS wiki [2]. Especially > > the ones in the "community" category are quite similar in terms of > > working functionality. > > I know about postmarketOS (I even contributed a bit some time ago), > and watch it from time to time. Currently I'm using old Nokia 6151 for > phone calls, but would not mind switching. Work is ongoing in Droid 4 > land -- phone calls are also "almost there". But the almost seems to > be a lot of work :-(. > It's fairly simple on Qualcomm SoCs once audio DSP and modem are working (which is not that simple). I basically just tell the audio DSP to stream voice call audio to the audio ports and then it does that without involving the kernel. It seems to work quite well, so far no one complained about quality or something like that. Not sure if anyone is actively using it already though :) The work left is mainly making the driver more generic so it can work on other Qualcomm SoCs as well (right now I have some things hardcoded). Also, I still haven't fully figured out what is the best way to integrate it into ASoC/UCM/..., so that it can be easily activated when starting a voice call. Stephan
Re: [PATCH v2 3/3] arm64: dts: qcom: msm8916-longcheer-l8910: Add imu/magnetometer
On Mon, Jan 25, 2021 at 10:44:32AM +0100, Jonathan Albrieux wrote:
> BQ Aquaris X5 (Longcheer L8910) has:
> - BMI160 accelerometer and gyroscope sensor
> - AK09911 magnetometer sensor
> Add them to the device tree.
>
> This patch depends on patch "arm64: dts: qcom: msm8916: Add blsp_i2c3".
>
> Signed-off-by: Jonathan Albrieux
Reviewed-by: Stephan Gerhold
> ---
> .../boot/dts/qcom/msm8916-longcheer-l8910.dts | 37 +++
> 1 file changed, 37 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
> b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
> index 7d5eff922f41..27845189ac2b 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
> +++ b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8910.dts
> @@ -56,6 +56,35 @@
> };
> };
>
> +_i2c3 {
> + status = "okay";
> +
> + magnetometer@d {
> + compatible = "asahi-kasei,ak09911";
> + reg = <0x0d>;
> +
> + vdd-supply = <_l17>;
> + vid-supply = <_l6>;
> +
> + reset-gpios = < 111 GPIO_ACTIVE_LOW>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_reset_default>;
> + };
> +
> + imu@68 {
> + compatible = "bosch,bmi160";
> + reg = <0x68>;
> +
> + vdd-supply = <_l17>;
> + vddio-supply = <_l6>;
> +
> + mount-matrix = "0", "1", "0",
> + "-1", "0", "0",
> +"0", "0", "1";
> + };
> +};
> +
> _uart2 {
> status = "okay";
> };
> @@ -220,6 +249,14 @@
> bias-pull-up;
> };
>
> + mag_reset_default: mag-reset-default {
> + pins = "gpio111";
> + function = "gpio";
> +
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> usb_id_default: usb-id-default {
> pins = "gpio110";
> function = "gpio";
> --
> 2.17.1
>
Re: [PATCH 0/3] Add initial support for BQ Aquaris X5
Hi Pavel, On Sun, Jan 24, 2021 at 10:01:19PM +0100, Pavel Machek wrote: > Hi! > > > Aquaris X5 (Longcheer L8910) is a smartphone released by BQ in 2015. > > > > As part of msm8916-mainline project, this series aims to bring initial > > mainline support for it. > > Good to see another phone being supported. Can I ask you to cc: > phone-de...@vger.kernel.org with phone stuff? > > > Features added: > > - SDHCI (internal and external storage) > > - USB Device Mode > > - UART > > - Regulators > > - WiFi/BT > > - Volume buttons > > - Vibrator > > - Touchkeys backlight > > - Accelerometer and gyroscope sensor > > - Magnetometer sensor > > How close are you to having useful phone calls? > You can do phone calls (with audio) and you can use mobile data, if you have the patches for that. :) I'm trying to find time to finish up the drivers needed for that, but I've been a bit short on time lately. Actually we have come pretty far with MSM8916-based smartphones. Most functionality is (somewhat) working at this point, the primary open task is optimizing suspend/power consumption. Battery/charging and camera is also tricky but works somewhat on some of the devices. Most of the functionality is packaged in postmarketOS [1] and you can find a list of the devices in the postmarketOS wiki [2]. Especially the ones in the "community" category are quite similar in terms of working functionality. Stephan [1]: https://postmarketos.org [2]: https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_410/412_(MSM8916)
Re: [PATCH 2/3] arm64: dts: qcom: msm8916: Add blsp_i2c3
On Sun, Jan 24, 2021 at 02:54:06PM +0100, Jonathan Albrieux wrote:
> MSM8916 has another I2C QUP controller that can be enabled on
> GPIO 10 and 11.
>
> Add blsp_i2c3 to msm8916.dtsi and disable it by default.
>
> Signed-off-by: Jonathan Albrieux
Reviewed-by: Stephan Gerhold
> ---
> arch/arm64/boot/dts/qcom/msm8916-pins.dtsi | 16
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 15 +++
> 2 files changed, 31 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
> b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
> index 4dc437f13fa5..7dedb91b9930 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916-pins.dtsi
> @@ -220,6 +220,22 @@
> bias-disable;
> };
>
> + i2c3_default: i2c3-default {
> + pins = "gpio10", "gpio11";
> + function = "blsp_i2c3";
> +
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + i2c3_sleep: i2c3-sleep {
> + pins = "gpio10", "gpio11";
> + function = "gpio";
> +
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> i2c4_default: i2c4-default {
> pins = "gpio14", "gpio15";
> function = "blsp_i2c4";
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 402e891a84ab..1045d7e518f3 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -1528,6 +1528,21 @@
> status = "disabled";
> };
>
> + blsp_i2c3: i2c@78b7000 {
> + compatible = "qcom,i2c-qup-v2.2.1";
> + reg = <0x078b7000 0x500>;
> + interrupts = ;
> + clocks = < GCC_BLSP1_AHB_CLK>,
> + < GCC_BLSP1_QUP3_I2C_APPS_CLK>;
> + clock-names = "iface", "core";
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <_default>;
> + pinctrl-1 = <_sleep>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "disabled";
> + };
> +
> blsp_spi3: spi@78b7000 {
> compatible = "qcom,spi-qup-v2.2.1";
> reg = <0x078b7000 0x500>;
> --
> 2.17.1
>
Re: [PATCH 3/3] arm64: dts: qcom: msm8916-longcheer-l8910: Add imu/magnetometer
On Sun, Jan 24, 2021 at 04:07:19PM +0100, Konrad Dybcio wrote:
> > +_i2c3 {
> > + status = "okay";
> > +
> > + imu@68 {
> > + compatible = "bosch,bmi160";
> > + reg = <0x68>;
> > +
> > + vdd-supply = <_l17>;
> > + vddio-supply = <_l6>;
> > +
> > + mount-matrix = "0", "1", "0",
> > + "-1", "0", "0",
> > + "0", "0", "1";
> > + };
> > +
> > + magnetometer@d {
> > + compatible = "asahi-kasei,ak09911";
> > + reg = <0x0d>;
> > +
> > + vdd-supply = <_l17>;
> > + vid-supply = <_l6>;
> > +
> > + reset-gpios = < 111 GPIO_ACTIVE_LOW>;
> > +
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_reset_default>;
> > + };
> > +};
>
> Please sort I2C devices by their address.
>
+1 :)
>
> > };
> >
> > + mag_reset_default: mag-reset-default {
> > + pins = "gpio111";
> > + function = "gpio";
> > +
> > + drive-strength = <2>;
> > + bias-disable;
> > + };
> > +
>
> Please add this after gpio110 to keep it sorted gpio-number-wise.
>
This is ordered alphabetically. I haven't seen gpio-number order
anywhere yet... :)
Thanks,
Stephan
Re: [PATCH 1/3] arm64: dts: qcom: Add device tree for BQ Aquaris X5 (Longcheer L8910)
On Sun, Jan 24, 2021 at 04:12:30PM +0100, Konrad Dybcio wrote: > The sorting on smd_rpm_regulators & msmgpio seems off.. unless it's the new > thing to put it at the end? > It's consistent like this for all MSM8916 device trees at least. Back when I converted them I thought that it's kind of annoying to have this large list of regulators and pinctrl placed right inbetween all other device definitions. And it's even worse for apq8016-sbc.dtsi which has this large list of gpio-line-names. It just makes it harder to see the actual interesting definitions (new devices etc) in my opinion. I think I mentioned this in my patch description back then and Bjorn did not complain. :-) But I understand this may be somewhat inconsistent with other qcom device trees at the moment, so I suppose I would be fine with a patch to order them entirely alphabetically. (As long as it's consistent for all MSM8916 device trees...) Thanks, Stephan
Re: [PATCH] driver core: Extend device_is_dependent()
On Fri, Jan 15, 2021 at 09:20:54AM -0800, Saravana Kannan wrote:
> On Fri, Jan 15, 2021 at 5:03 AM Rafael J. Wysocki wrote:
> > On Fri, Jan 15, 2021 at 11:03 AM Stephan Gerhold
> > wrote:
> > > On Thu, Jan 14, 2021 at 11:31:12AM -0800, Saravana Kannan wrote:
> > > > On Thu, Jan 14, 2021 at 10:41 AM Rafael J. Wysocki
> > > > wrote:
> > > > >
> > > > > From: Rafael J. Wysocki
> > > > >
> > > > > When adding a new device link, device_is_dependent() is used to
> > > > > check whether or not the prospective supplier device does not
> > > > > depend on the prospective consumer one to avoid adding loops
> > > > > to the graph of device dependencies.
> > > > >
> > > > > However, device_is_dependent() does not take the ancestors of
> > > > > the target device into account, so it may not detect an existing
> > > > > reverse dependency if, for example, the parent of the target
> > > > > device depends on the device passed as its first argument.
> > > > >
> > > > > For this reason, extend device_is_dependent() to also check if
> > > > > the device passed as its first argument is an ancestor of the
> > > > > target one and return 1 if that is the case.
> > > > >
> > > > > Signed-off-by: Rafael J. Wysocki
> > > > > Reported-by: Stephan Gerhold
> > > > > ---
> > > > > drivers/base/core.c | 12 +++-
> > > > > 1 file changed, 11 insertions(+), 1 deletion(-)
> > > > >
> > > > > Index: linux-pm/drivers/base/core.c
> > > > > ===
> > > > > --- linux-pm.orig/drivers/base/core.c
> > > > > +++ linux-pm/drivers/base/core.c
> > > > > @@ -208,6 +208,16 @@ int device_links_read_lock_held(void)
> > > > > #endif
> > > > > #endif /* !CONFIG_SRCU */
> > > > >
> > > > > +static bool device_is_ancestor(struct device *dev, struct device
> > > > > *target)
> > > > > +{
> > > > > + while (target->parent) {
> > > > > + target = target->parent;
> > > > > + if (dev == target)
> > > > > + return true;
> > > > > + }
> > > > > + return false;
> > > > > +}
> > > > > +
> > > > > /**
> > > > > * device_is_dependent - Check if one device depends on another one
> > > > > * @dev: Device to check dependencies for.
> > > > > @@ -221,7 +231,7 @@ int device_is_dependent(struct device *d
> > > > > struct device_link *link;
> > > > > int ret;
> > > > >
> > > > > - if (dev == target)
> > > > > + if (dev == target || device_is_ancestor(dev, target))
> > > > > return 1;
> > > > >
> > > > > ret = device_for_each_child(dev, target, device_is_dependent);
> > > > >
> > > >
> > > > The code works, but it's not at all obvious what it's doing. Because,
> > > > at first glance, it's easy to mistakenly think that it's trying to
> > > > catch this case:
> > > > dev <- child1 <- child2 <- target
> > > >
> > >
> > > Isn't this pretty much the case we are trying to catch? I have:
> > >
> > > 78d9000.usb <- ci_hdrc.0 <- ci_hdrc.0.ulpi <- phy-ci_hdrc.0.ulpi.0
> > >
> > > then something attempts to create a device link with
> > > consumer = 78d9000.usb, supplier = phy-ci_hdrc.0.ulpi.0, and to check if
> > > that is allowed we call device_is_dependent() with dev = 78d9000.usb,
> > > target = phy-ci_hdrc.0.ulpi.0.
> > >
> > > Note that this case would normally be covered by the
> > > device_for_each_child().
> > > It's not in this case because the klist_children of 78d9000.usb
> > > is updated too late.
> >
> > Exactly.
>
> Stephan,
>
> What device/driver is this? Is this a dwc3 device/driver? That driver
> does some weird/incorrect stuff the last time I checked.
>
I described my situation in this mail thread:
https://lore.kernel.org/lkml/x%2fycqpu7nigi9...@gerhold.net/
It's USB, but chipidea on apq8016-sbc in this case. The situation is
definitely kind of weird, but not sure if it is wrong per-se.
Thanks,
Stephan
Re: [PATCH] driver core: Extend device_is_dependent()
Hi,
On Thu, Jan 14, 2021 at 11:31:12AM -0800, Saravana Kannan wrote:
> On Thu, Jan 14, 2021 at 10:41 AM Rafael J. Wysocki wrote:
> >
> > From: Rafael J. Wysocki
> >
> > When adding a new device link, device_is_dependent() is used to
> > check whether or not the prospective supplier device does not
> > depend on the prospective consumer one to avoid adding loops
> > to the graph of device dependencies.
> >
> > However, device_is_dependent() does not take the ancestors of
> > the target device into account, so it may not detect an existing
> > reverse dependency if, for example, the parent of the target
> > device depends on the device passed as its first argument.
> >
> > For this reason, extend device_is_dependent() to also check if
> > the device passed as its first argument is an ancestor of the
> > target one and return 1 if that is the case.
> >
> > Signed-off-by: Rafael J. Wysocki
> > Reported-by: Stephan Gerhold
> > ---
> > drivers/base/core.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > Index: linux-pm/drivers/base/core.c
> > ===
> > --- linux-pm.orig/drivers/base/core.c
> > +++ linux-pm/drivers/base/core.c
> > @@ -208,6 +208,16 @@ int device_links_read_lock_held(void)
> > #endif
> > #endif /* !CONFIG_SRCU */
> >
> > +static bool device_is_ancestor(struct device *dev, struct device *target)
> > +{
> > + while (target->parent) {
> > + target = target->parent;
> > + if (dev == target)
> > + return true;
> > + }
> > + return false;
> > +}
> > +
> > /**
> > * device_is_dependent - Check if one device depends on another one
> > * @dev: Device to check dependencies for.
> > @@ -221,7 +231,7 @@ int device_is_dependent(struct device *d
> > struct device_link *link;
> > int ret;
> >
> > - if (dev == target)
> > + if (dev == target || device_is_ancestor(dev, target))
> > return 1;
> >
> > ret = device_for_each_child(dev, target, device_is_dependent);
> >
>
Thanks for the patch, Rafael! I tested it and it seems to avoid the
circular device link (and therefore also the crash). FWIW:
Tested-by: Stephan Gerhold
> The code works, but it's not at all obvious what it's doing. Because,
> at first glance, it's easy to mistakenly think that it's trying to
> catch this case:
> dev <- child1 <- child2 <- target
>
Isn't this pretty much the case we are trying to catch? I have:
78d9000.usb <- ci_hdrc.0 <- ci_hdrc.0.ulpi <- phy-ci_hdrc.0.ulpi.0
then something attempts to create a device link with
consumer = 78d9000.usb, supplier = phy-ci_hdrc.0.ulpi.0, and to check if
that is allowed we call device_is_dependent() with dev = 78d9000.usb,
target = phy-ci_hdrc.0.ulpi.0.
Note that this case would normally be covered by the device_for_each_child().
It's not in this case because the klist_children of 78d9000.usb
is updated too late.
> Maybe it's clearer if we do this check inside the loop? Something like:
>
> if (link->consumer == target ||
> device_is_ancestor(link->consumer, target))
> return 1;
>
I tried to test this with the diff below (let me know if I got it wrong).
It does not seem to make any difference though, the circular device link
is still created and without the reorder commit reverted it crashes.
Thanks!
Stephan
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 14f165816742..7af4ef5f89e7 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -208,6 +208,16 @@ int device_links_read_lock_held(void)
#endif
#endif /* !CONFIG_SRCU */
+static bool device_is_ancestor(struct device *dev, struct device *target)
+{
+ while (target->parent) {
+ target = target->parent;
+ if (dev == target)
+ return true;
+ }
+ return false;
+}
+
/**
* device_is_dependent - Check if one device depends on another one
* @dev: Device to check dependencies for.
@@ -232,7 +242,7 @@ int device_is_dependent(struct device *dev, void *target)
if (link->flags == (DL_FLAG_SYNC_STATE_ONLY | DL_FLAG_MANAGED))
continue;
- if (link->consumer == target)
+ if (link->consumer == target ||
device_is_ancestor(link->consumer, target))
return 1;
ret = device_is_dependent(link->consumer, target);
Re: Infinite recursion in device_reorder_to_tail() due to circular device links
Hi Peter,
On Thu, Jan 14, 2021 at 08:54:54AM +0800, Peter Chen wrote:
> On 21-01-13 12:18:35, Stephan Gerhold wrote:
> >
> > Also, on a completely different note I looked again at the chipidea USB
> > driver that produces this situation. To request the PHY (which ends up
> > in the circular device link) it does:
> >
> > /* Look for a generic PHY first */
> > ci->phy = devm_phy_get(dev->parent, "usb-phy");
> >
> > To me it doesn't really seem great to use the devm_* helpers on the
> > parent device either, so I will check if I can refactor this somehow.
> > Perhaps this situation can be prevented entirely.
> >
>
> You could try to get the PHY at parent driver
> (drivers/usb/chipidea/ci_hdrc_msm.c) to see the difference.
>
Unfortunately, I don't think this works in my case because I have an
ULPI PHY. It's not available until ret = ci_ulpi_init(ci); is called
from the ci_hdrc.0 platform device.
I tried the following diff yesterday. It prevents the circular device
link, therefore also the crash and even devm_* on the parent device:
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index aa40e510b806..79f556d0c93e 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -847,6 +847,8 @@ struct platform_device *ci_hdrc_add_device(struct device
*dev,
}
pdev->dev.parent = dev;
+ device_set_of_node_from_dev(>dev, dev);
+ pdev->driver_override = kstrdup("ci_hdrc", GFP_KERNEL);
ret = platform_device_add_resources(pdev, res, nres);
if (ret)
@@ -1027,7 +1029,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
ci->usb_phy = ci->platdata->usb_phy;
} else {
/* Look for a generic PHY first */
- ci->phy = devm_phy_get(dev->parent, "usb-phy");
+ ci->phy = devm_phy_get(dev, "usb-phy");
if (PTR_ERR(ci->phy) == -EPROBE_DEFER) {
ret = -EPROBE_DEFER;
Basically my idea was to share the of_node with the ci_hdrc.0 platform
device, so that it can request the PHY itself instead of going through
the parent.
It seems to work fine but I had to add pdev->driver_override to prevent
the ci_hdrc.0 device from probing using ci_hdrc_msm (since it considers
the "compatible" value on the of_node otherwise).
This is a bit weird (I think driver_override is mainly intended to be
written through sysfs, not from kernel code directly).
That is why I did not post this as a proper patch yet...
Thanks,
Stephan
Re: [PATCH v11 0/7] Qualcomm's lpass-hdmi ASoC driver to support audio over dp port
Hi, On Wed, Jan 13, 2021 at 10:24:49PM +, Srinivas Kandagatla wrote: > On 13/01/2021 20:08, Stephan Gerhold wrote: > > On Thu, Oct 08, 2020 at 06:37:40AM +0100, Srinivas Kandagatla wrote: > > > On 08/10/2020 06:16, Srinivasa Rao Mandadapu wrote: > > > > These patches are to support audio over DP port on Qualcomm's SC7180 > > > > LPASS > > > > Asoc. It includes machine driver, cpu driver, platform driver updates > > > > for > > > > HDMI path support, device tree documention, lpass variant structure > > > > optimization and configuration changes. > > > > These patches depends on the DP patch series > > > > https://patchwork.kernel.org/project/dri-devel/list/?series=332029 > > > > https://lore.kernel.org/patchwork/project/lkml/list/?series=464856 > > > > > > > > changes since V10: > > > > -- Moved hdmi regmap functions from lpass-hdmi.c to lpass-cpu.c > > > > -- Moved QCOM_REGMAP_FIELD_ALLOC macro from lpass-hdmi.c to > > > > lpass.h > > > > changes since V9: > > > > -- Removed unused structures lpass_hdmi.h > > > > changes since V8: > > > > -- Removed redundant structure wrapper for reg map field memebrs > > > > -- Updated lpass_hdmi_regmap_volatile API with appropriate > > > > registers as true > > > > and others as false. > > > > changes since V7: > > > > -- Fixed typo errors > > > > -- Created Separate patch for buffer size change > > > > changes since V6: > > > > -- Removed compile time define flag, which used for enabling > > > >HDMI code, based on corresponding config param is included. > > > > -- Updated reg map alloc API with reg map bulk API. > > > > -- Removed unnecessary line splits > > > > changes since V5: > > > > -- Removed unused struct regmap *map in > > > > lpass_platform_alloc_hdmidmactl_fields. > > > > -- DMA alloc and free API signature change in lpass-apq8016.c, > > > > lpass-ipq806x.c > > > > -- Keeping API "irqreturn_t lpass_platform_hdmiif_irq" under > > > > ifdef macro > > > > Changes Since v4: > > > > -- Updated with single compatible node for both I2S and HDMI. > > > > Changes Since v3: > > > > -- Removed id in lpass variant structure and used > > > > snd_soc_dai_driver id. > > > > Changes Since v2: > > > > -- Audio buffer size(i.e. LPASS_PLATFORM_BUFFER_SIZE) in > > > > lpass-platform.c increased. > > > > Changes Since v1: > > > > -- Commit messages are updated > > > > -- Addressed Rob Herring review comments > > > > > > > > V Sujith Kumar Reddy (7): > > > > ASoC: Add sc7180-lpass binding header hdmi define > > > > ASoC: dt-bindings: Add dt binding for lpass hdmi > > > > Asoc:qcom:lpass-cpu:Update dts property read API > > > > Asoc: qcom: lpass:Update lpaif_dmactl members order > > > > ASoC: qcom: Add support for lpass hdmi driver > > > > Asoc: qcom: lpass-platform : Increase buffer size > > > > ASoC: qcom: sc7180: Add support for audio over DP > > > > > > > >.../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 74 ++-- > > > >include/dt-bindings/sound/sc7180-lpass.h | 1 + > > > >sound/soc/qcom/Kconfig | 5 + > > > >sound/soc/qcom/Makefile| 2 + > > > >sound/soc/qcom/lpass-apq8016.c | 4 +- > > > >sound/soc/qcom/lpass-cpu.c | 249 > > > > - > > > >sound/soc/qcom/lpass-hdmi.c| 258 > > > > ++ > > > >sound/soc/qcom/lpass-hdmi.h| 102 ++ > > > >sound/soc/qcom/lpass-ipq806x.c | 4 +- > > > >sound/soc/qcom/lpass-lpaif-reg.h | 49 ++- > > > >sound/soc/qcom/lpass-platform.c| 395 > > > > + > > > >sound/soc/qcom/lpass-sc7180.c | 116 +- > > > >sound/soc/qcom/lpass.h | 124 ++- > > > >13 files changed, 1240 insertions(+), 143 deletions(-) > >
Re: [PATCH v11 0/7] Qualcomm's lpass-hdmi ASoC driver to support audio over dp port
Hi Srinivas, On Thu, Oct 08, 2020 at 06:37:40AM +0100, Srinivas Kandagatla wrote: > On 08/10/2020 06:16, Srinivasa Rao Mandadapu wrote: > > These patches are to support audio over DP port on Qualcomm's SC7180 LPASS > > Asoc. It includes machine driver, cpu driver, platform driver updates for > > HDMI path support, device tree documention, lpass variant structure > > optimization and configuration changes. > > These patches depends on the DP patch series > > https://patchwork.kernel.org/project/dri-devel/list/?series=332029 > > https://lore.kernel.org/patchwork/project/lkml/list/?series=464856 > > > > changes since V10: > > -- Moved hdmi regmap functions from lpass-hdmi.c to lpass-cpu.c > > -- Moved QCOM_REGMAP_FIELD_ALLOC macro from lpass-hdmi.c to lpass.h > > changes since V9: > > -- Removed unused structures lpass_hdmi.h > > changes since V8: > > -- Removed redundant structure wrapper for reg map field memebrs > > -- Updated lpass_hdmi_regmap_volatile API with appropriate registers > > as true > > and others as false. > > changes since V7: > > -- Fixed typo errors > > -- Created Separate patch for buffer size change > > changes since V6: > > -- Removed compile time define flag, which used for enabling > > HDMI code, based on corresponding config param is included. > > -- Updated reg map alloc API with reg map bulk API. > > -- Removed unnecessary line splits > > changes since V5: > > -- Removed unused struct regmap *map in > > lpass_platform_alloc_hdmidmactl_fields. > > -- DMA alloc and free API signature change in lpass-apq8016.c, > > lpass-ipq806x.c > > -- Keeping API "irqreturn_t lpass_platform_hdmiif_irq" under ifdef > > macro > > Changes Since v4: > > -- Updated with single compatible node for both I2S and HDMI. > > Changes Since v3: > > -- Removed id in lpass variant structure and used snd_soc_dai_driver > > id. > > Changes Since v2: > > -- Audio buffer size(i.e. LPASS_PLATFORM_BUFFER_SIZE) in > > lpass-platform.c increased. > > Changes Since v1: > > -- Commit messages are updated > > -- Addressed Rob Herring review comments > > > > V Sujith Kumar Reddy (7): > >ASoC: Add sc7180-lpass binding header hdmi define > >ASoC: dt-bindings: Add dt binding for lpass hdmi > >Asoc:qcom:lpass-cpu:Update dts property read API > >Asoc: qcom: lpass:Update lpaif_dmactl members order > >ASoC: qcom: Add support for lpass hdmi driver > >Asoc: qcom: lpass-platform : Increase buffer size > >ASoC: qcom: sc7180: Add support for audio over DP > > > > .../devicetree/bindings/sound/qcom,lpass-cpu.yaml | 74 ++-- > > include/dt-bindings/sound/sc7180-lpass.h | 1 + > > sound/soc/qcom/Kconfig | 5 + > > sound/soc/qcom/Makefile| 2 + > > sound/soc/qcom/lpass-apq8016.c | 4 +- > > sound/soc/qcom/lpass-cpu.c | 249 - > > sound/soc/qcom/lpass-hdmi.c| 258 ++ > > sound/soc/qcom/lpass-hdmi.h| 102 ++ > > sound/soc/qcom/lpass-ipq806x.c | 4 +- > > sound/soc/qcom/lpass-lpaif-reg.h | 49 ++- > > sound/soc/qcom/lpass-platform.c| 395 > > + > > sound/soc/qcom/lpass-sc7180.c | 116 +- > > sound/soc/qcom/lpass.h | 124 ++- > > 13 files changed, 1240 insertions(+), 143 deletions(-) > > create mode 100644 sound/soc/qcom/lpass-hdmi.c > > create mode 100644 sound/soc/qcom/lpass-hdmi.h > > > > Tested this series on DragonBoard 410c > > Tested-by: Srinivas Kandagatla > Reviewed-by: Srinivas Kandagatla I spent quite some time today trying to track down another regression for MSM8916/DragonBoard 410c audio in 5.10 and identified this patch series as the cause. So I'm very surprised that you successfully tested this on DB410c. Attempting to play HDMI audio results in: ADV7533: lpass_platform_pcmops_hw_params: invalid interface: 3 ADV7533: lpass_platform_pcmops_trigger: invalid 3 interface apq8016-lpass-cpu 7708000.audio-controller: ASoC: error at soc_component_trigger on 7708000.audio-controller: -22 Attempting to record analog audio results in: Unable to handle kernel NULL pointer dereference at virtual address 01e4 Internal error: Oops: 9604 [#1] PREEMPT SMP CPU: 1 PID: 1568 Comm: arecord Not tainted 5.11.0-rc3 #20 Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) pc : regmap_write+0x14/0x80 lr : lpass_platform_pcmops_open+0xd8/0x210 [snd_soc_lpass_platform] Call trace: regmap_write+0x14/0x80 lpass_platform_pcmops_open+0xd8/0x210 [snd_soc_lpass_platform] snd_soc_component_open+0x2c/0x94 ... Looking at the changes in "ASoC: qcom: Add support for lpass hdmi driver" there is a quite obvious
Re: Infinite recursion in device_reorder_to_tail() due to circular device links
On Tue, Jan 12, 2021 at 07:24:24PM +0100, Rafael J. Wysocki wrote:
> On Tue, Jan 12, 2021 at 3:32 PM Rafael J. Wysocki wrote:
> >
> > On Mon, Jan 11, 2021 at 7:46 PM Stephan Gerhold wrote:
> > >
> > > Hi,
> > >
> > > since 5.11-rc1 I get kernel crashes with infinite recursion in
> > > device_reorder_to_tail() in some situations... It's a bit complicated to
> > > explain so I want to apologize in advance for the long mail. :)
> > >
> > > Kernel panic - not syncing: kernel stack overflow
> > > CPU: 1 PID: 33 Comm: kworker/1:1 Not tainted 5.11.0-rc3 #1
> > > Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
> > > Call trace:
> > >...
> > >device_reorder_to_tail+0x4c/0xf0
> > >device_reorder_to_tail+0x98/0xf0
> > >device_reorder_to_tail+0x60/0xf0
> > >device_reorder_to_tail+0x60/0xf0
> > >device_reorder_to_tail+0x60/0xf0
> > >...
> > >
> > > The crash happens only in 5.11 with commit 5b6164d3465f ("driver core:
> > > Reorder devices on successful probe"). It stops happening when I revert
> > > this commit.
> >
> > Thanks for the report!
> >
> > Greg, please revert commit 5b6164d3465f, it clearly is not an
> > improvement, at least at this point.
> >
Thanks a lot for the quick reply and for reverting the patch!
> > > But I don't think this commit is the actual problem...
> >
> > Well, it may not be the root cause, but it is a change in behavior
> > that exposes the breakage and this is not the only problem introduced
> > by it.
> >
> > > It's easy to reproduce on any device based on the Qualcomm MSM8916 SoC
> > > by adding a random regulator to the USB node, e.g.:
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> > > b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> > > index 3a9538e1ec97..9f43fce9e6e3 100644
> > > --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> > > @@ -372,6 +372,7 @@ codec {
> > >
> > > {
> > > status = "okay";
> > > + vbus-supply = <_l5>;
> > > extcon = <_id>, <_id>;
> > >
> > > pinctrl-names = "default", "device";
> > >
> > > I searched for problems in the regulator core but the problem actually
> > > has nothing to do with regulators: The additional regulator supply just
> > > delays probing of the USB driver long enough to trigger the issue.
> > >
> > > Adding some debug output to device_reorder_to_tail() reveals that it
> > > keeps recursing over the same 4 devices:
> > >
> > > msm_hsusb 78d9000.usb: device_reorder_to_tail()
> > > ci_hdrc ci_hdrc.0: device_reorder_to_tail()
> > > qcom_usb_hs_phy ci_hdrc.0.ulpi: device_reorder_to_tail()
> > > phy phy-ci_hdrc.0.ulpi.0: device_reorder_to_tail()
> > > msm_hsusb 78d9000.usb: device_reorder_to_tail()
> > > ...
> > >
> > > The device hierarchy of these is (children devices):
> > >
> > > 78d9000.usb -> ci_hdrc.0 -> ci_hdrc.0.ulpi -> phy-ci_hdrc.0.ulpi.0
> > >
> > > ci_hdrc.0 calls phy_get(dev->parent, "usb-phy"). In phy_get(),
> > > the phy-core then attempts to add the following device link:
> > >
> > > phy-ci_hdrc.0.ulpi.0 -> 78d9000.usb
> > >
> > > The device link creation in phy-core is optional (see commit 1d7cb11e1090
> > > ("phy: core: Fix phy_get() to not return error on link creation failure"))
> > > because this device link is circular in case of ULPI PHYs (like here).
> > >
> > > And indeed, creating this device link usually fails (as it should).
> > > However, adding the "vbus-supply" changes probe order in some way that
> > > this circular device link ends up being created:
> > > /sys/class/devlink/phy-ci_hdrc.0.ulpi.0--78d9000.usb/ exists only when
> > > I add the "vbus-supply" as in the diff above.
> > >
> > > Apparently, there is a special situation where device_is_dependent()
> > > does not work properly, and therefore the driver core allows creating
> > > the circular device link.
> > >
> > > To show the problem, I enabled some debug messages and added the
> > > following log message:
> > >
> > > diff --git a/drivers/base/core.c b/drivers/base/core.c
&
Infinite recursion in device_reorder_to_tail() due to circular device links
Hi,
since 5.11-rc1 I get kernel crashes with infinite recursion in
device_reorder_to_tail() in some situations... It's a bit complicated to
explain so I want to apologize in advance for the long mail. :)
Kernel panic - not syncing: kernel stack overflow
CPU: 1 PID: 33 Comm: kworker/1:1 Not tainted 5.11.0-rc3 #1
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
Call trace:
...
device_reorder_to_tail+0x4c/0xf0
device_reorder_to_tail+0x98/0xf0
device_reorder_to_tail+0x60/0xf0
device_reorder_to_tail+0x60/0xf0
device_reorder_to_tail+0x60/0xf0
...
The crash happens only in 5.11 with commit 5b6164d3465f ("driver core:
Reorder devices on successful probe"). It stops happening when I revert
this commit. But I don't think this commit is the actual problem...
It's easy to reproduce on any device based on the Qualcomm MSM8916 SoC
by adding a random regulator to the USB node, e.g.:
diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
index 3a9538e1ec97..9f43fce9e6e3 100644
--- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
@@ -372,6 +372,7 @@ codec {
{
status = "okay";
+ vbus-supply = <_l5>;
extcon = <_id>, <_id>;
pinctrl-names = "default", "device";
I searched for problems in the regulator core but the problem actually
has nothing to do with regulators: The additional regulator supply just
delays probing of the USB driver long enough to trigger the issue.
Adding some debug output to device_reorder_to_tail() reveals that it
keeps recursing over the same 4 devices:
msm_hsusb 78d9000.usb: device_reorder_to_tail()
ci_hdrc ci_hdrc.0: device_reorder_to_tail()
qcom_usb_hs_phy ci_hdrc.0.ulpi: device_reorder_to_tail()
phy phy-ci_hdrc.0.ulpi.0: device_reorder_to_tail()
msm_hsusb 78d9000.usb: device_reorder_to_tail()
...
The device hierarchy of these is (children devices):
78d9000.usb -> ci_hdrc.0 -> ci_hdrc.0.ulpi -> phy-ci_hdrc.0.ulpi.0
ci_hdrc.0 calls phy_get(dev->parent, "usb-phy"). In phy_get(),
the phy-core then attempts to add the following device link:
phy-ci_hdrc.0.ulpi.0 -> 78d9000.usb
The device link creation in phy-core is optional (see commit 1d7cb11e1090
("phy: core: Fix phy_get() to not return error on link creation failure"))
because this device link is circular in case of ULPI PHYs (like here).
And indeed, creating this device link usually fails (as it should).
However, adding the "vbus-supply" changes probe order in some way that
this circular device link ends up being created:
/sys/class/devlink/phy-ci_hdrc.0.ulpi.0--78d9000.usb/ exists only when
I add the "vbus-supply" as in the diff above.
Apparently, there is a special situation where device_is_dependent()
does not work properly, and therefore the driver core allows creating
the circular device link.
To show the problem, I enabled some debug messages and added the
following log message:
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 25e08e5f40bd..ff1344eabb31 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3089,9 +3089,11 @@ int device_add(struct device *dev)
}
bus_probe_device(dev);
- if (parent)
+ if (parent) {
+ dev_info(dev, "add to parent %s\n", dev_name(parent));
klist_add_tail(>p->knode_parent,
>p->klist_children);
+ }
if (dev->class) {
mutex_lock(>class->p->mutex);
Running this with "vbus-supply" (where it crashes) produces:
bus: 'platform': probing driver msm_hsusb with device 78d9000.usb
bus: 'platform': probing driver msm_hsusb with device 78d9000.usb
bus: 'platform': probing driver ci_hdrc with device ci_hdrc.0
bus: 'ulpi': probing driver qcom_usb_hs_phy with device ci_hdrc.0.ulpi
phy phy-ci_hdrc.0.ulpi.0: add to parent ci_hdrc.0.ulpi
qcom_usb_hs_phy ci_hdrc.0.ulpi: add to parent ci_hdrc.0
(1) msm_hsusb 78d9000.usb: Linked as a consumer to phy-ci_hdrc.0.ulpi.0
(2) ci_hdrc ci_hdrc.0: add to parent 78d9000.usb
Kernel panic - not syncing: kernel stack overflow
...
Note how ci_hdrc is added to the children list of 78d9000.usb (2) after
the device link was already created in (1). This is why device_is_dependent()
does not realize the devices will eventually be dependent on each other.
Without "vbus-supply" (2) happens before (1) because then the PHY driver
requests probe deferral a few times while waiting for regulators.
I'm not really sure what to do here, any suggestions how to fix this properly?
(In case it helps, I have attached an example kernel module (circdl.c)
that allows reproducing the exact same crash.)
Thanks in advance!
Stephan
#include
#include
static int parent_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
struct platform_device *middle;
dev_info(dev, "probe\n");
middle =
Re: [PATCH RFC] remoteproc: qcom: wcnss: Adjust voltage requirements for Pronto v2
Hi Konrad,
On Sat, Dec 26, 2020 at 03:11:00PM +0100, Konrad Dybcio wrote:
> This is required for MSM8974 devices that cannot afford to push
> the regulators further.
>
> Signed-off-by: Konrad Dybcio
> ---
> drivers/remoteproc/qcom_wcnss.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/remoteproc/qcom_wcnss.c b/drivers/remoteproc/qcom_wcnss.c
> index e2573f79a137..71480be545e4 100644
> --- a/drivers/remoteproc/qcom_wcnss.c
> +++ b/drivers/remoteproc/qcom_wcnss.c
> @@ -124,7 +124,7 @@ static const struct wcnss_data pronto_v2_data = {
> .spare_offset = 0x1088,
>
> .vregs = (struct wcnss_vreg_info[]) {
> - { "vddmx", 1287500, 1287500, 0 },
> + { "vddmx", 95, 115, 0 },
> { "vddcx", .super_turbo = true },
> { "vddpx", 180, 180, 0 },
> },
Correct me if I'm wrong but with this change pronto_v2_data looks
exactly like pronto_v1_data (qcom,pronto-v1-pil).
Can you just change the compatible in qcom-msm8974.dtsi?
Also, if possible MSM8974 should be also moved to corner votes via rpmpd,
like in
https://lore.kernel.org/linux-arm-msm/20200916104135.25085-1-step...@gerhold.net/
Then the actual voltages don't matter anymore (all we need to do here is
to temporarily scale the power domain to maximum so WCNSS can boot up).
Thanks,
Stephan
Re: [PATCH 3/3] ARM: dts: exynos: Fix charging regulator voltage and current for i9100
On Thu, Dec 03, 2020 at 11:50:41AM +0200, Krzysztof Kozlowski wrote: > > Unfortunately it seems Samsung started to remove most of older > kernel source code from their OS compliance page. S1, S2 and S3 are > mostly gone. I was able to find just few remaining sources and I am now > updating my vendor-dump with them. I'll upload them later to > https://github.com/krzk/linux-vendor-backup . > I don't know why they keep removing older kernel sources (it's pretty stupid), but so far they added all of them back within a couple of days after I made an inquiry on https://opensource.samsung.com/requestInquiry (Note: They remove them again after a while so backups are always necessary...) Might be worth a try if you need some of them :) Stephan
Re: [PATCH 1/6] arm64: dts: qcom: msm8916-longcheer-l8150: Enable PM8916 vibrator
Hi,
Thanks for sending these!
On Fri, Nov 13, 2020 at 10:59:12PM +0500, nikitos...@gmail.com wrote:
> From: Nikita Travkin
>
> L8150 has a vibrator connected to PM8916. Add it to the device tree.
>
> Signed-off-by: Nikita Travkin
For all 6 patches in this series:
Reviewed-by: Stephan Gerhold
> ---
> arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
> b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
> index 2c204d535d66..d106bdbfda68 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
> +++ b/arch/arm64/boot/dts/qcom/msm8916-longcheer-l8150.dts
> @@ -61,6 +61,10 @@ _resin {
> linux,code = ;
> };
>
> +_vib {
> + status = "okay";
> +};
> +
> {
> status = "okay";
> };
> --
> 2.25.1
>
Re: [PATCH V2 1/2] opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER
On Fri, Oct 16, 2020 at 12:12:22PM +0100, Sudeep Holla wrote: > On Fri, Oct 16, 2020 at 07:00:21AM +0100, Sudeep Holla wrote: > > On Fri, Oct 16, 2020 at 09:54:34AM +0530, Viresh Kumar wrote: > > > On 15-10-20, 19:05, Sudeep Holla wrote: > > > > OK, this breaks with SCMI which doesn't provide clocks but manage OPPs > > > > directly. Before this change clk_get(dev..) was allowed to fail and > > > > --EPROBE_DEFER was not an error. > > > > > > I think the change in itself is fine. We should be returning from > > > there if we get EPROBE_DEFER. The question is rather why are you > > > getting EPROBE_DEFER here ? > > > > > > > Ah OK, I didn't spend too much time, saw -EPROBE_DEFER, just reverted > > this patch and it worked. I need to check it in detail yet. > > > > You confused me earlier. As I said there will be no clock provider > registered for SCMI CPU/Dev DVFS. > opp_table->clk = clk_get(dev, NULL); > will always return -EPROBE_DEFER as there is no clock provider for dev. Shouldn't it return -ENOENT if there is no clock for the SCMI case? With -EPROBE_DEFER I would expect that it shows up at some point. I tried to avoid a situation like this by ignoring all errors != -EPROBE_DEFER. So if clk_get(dev, NULL) would return -ENOENT everything should work as expected... Thanks, Stephan
Re: [PATCH v3 0/2] Add MSM8939 RPM power domains
On Wed, Sep 30, 2020 at 06:01:43PM +0800, Jun Nie wrote: > Add MSM8939 RPM power domains and associated document. This is based on > Stephan's patch set to reuse max state definition: > https://lore.kernel.org/linux-arm-msm/20200916104135.25085-1-step...@gerhold.net/ > > Changes vs v2: > - fix max power domain state value. > - trim code layout. > > Jun Nie (2): > dt-bindings: power: rpmpd: Add MSM8939 RPM power domains > soc: qcom: rpmpd: Add MSM8939 power-domains > > .../devicetree/bindings/power/qcom,rpmpd.yaml | 1 + > drivers/soc/qcom/rpmpd.c | 27 +++ > include/dt-bindings/power/qcom-rpmpd.h| 10 +++ > 3 files changed, 38 insertions(+) > > -- > 2.17.1 > Thanks for making the changes! I don't know much about MSM8939 but from what I know this looks good to me. FWIW, for both patches: Reviewed-by: Stephan Gerhold
Re: [PATCH] opp: Allow opp-level to be set to 0
On Fri, Sep 11, 2020 at 03:19:53PM +0530, Viresh Kumar wrote:
> The DT bindings don't put such a constraint, nor should the kernel. It
> is perfectly fine for opp-level to be set to 0, if we need to put the
> performance state votes for a domain for a particular OPP.
>
> Reported-by: Stephan Gerhold
> Signed-off-by: Viresh Kumar
I tried adding an opp-level = <0> and voting for it using required-opps
for some of the OPPs in the CPU OPP table and it seems to work fine now.
Tested-by: Stephan Gerhold
Just need to solve the "enable power domains" problem now :)
Thanks!
Stephan
> ---
> drivers/opp/core.c | 3 ---
> drivers/opp/of.c | 20 +++-
> 2 files changed, 7 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index 214c1619b445..2483e765318a 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -2117,9 +2117,6 @@ int dev_pm_opp_xlate_performance_state(struct opp_table
> *src_table,
> int dest_pstate = -EINVAL;
> int i;
>
> - if (!pstate)
> - return 0;
> -
> /*
>* Normally the src_table will have the "required_opps" property set to
>* point to one of the OPPs in the dst_table, but in some cases the
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> index e72753be7dc7..87f839a1899a 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -842,7 +842,7 @@ static struct dev_pm_opp *_opp_add_static_v2(struct
> opp_table *opp_table,
> static int _of_add_opp_table_v2(struct device *dev, struct opp_table
> *opp_table)
> {
> struct device_node *np;
> - int ret, count = 0, pstate_count = 0;
> + int ret, count = 0;
> struct dev_pm_opp *opp;
>
> /* OPP table is already initialized for the device */
> @@ -876,20 +876,14 @@ static int _of_add_opp_table_v2(struct device *dev,
> struct opp_table *opp_table)
> goto remove_static_opp;
> }
>
> - list_for_each_entry(opp, _table->opp_list, node)
> - pstate_count += !!opp->pstate;
> -
> - /* Either all or none of the nodes shall have performance state set */
> - if (pstate_count && pstate_count != count) {
> - dev_err(dev, "Not all nodes have performance state set (%d:
> %d)\n",
> - count, pstate_count);
> - ret = -ENOENT;
> - goto remove_static_opp;
> + list_for_each_entry(opp, _table->opp_list, node) {
> + /* Any non-zero performance state would enable the feature */
> + if (opp->pstate) {
> + opp_table->genpd_performance_state = true;
> + break;
> + }
> }
>
> - if (pstate_count)
> - opp_table->genpd_performance_state = true;
> -
> return 0;
>
> remove_static_opp:
> --
> 2.25.0.rc1.19.g042ed3e048af
>
Re: [PATCH v2] opp: Power on (virtual) power domains managed by the OPP core
On Fri, Sep 11, 2020 at 02:55:38PM +0530, Viresh Kumar wrote:
> > As mentioned in my other mail [1] it turns out I actually have such a
> > use case. I briefly explained it in [2], basically the clock that
> > provides higher CPU frequencies has some voltage requirements that
> > should be voted for using a power domain.
> >
> > The clock that provides the lower CPU frequencies has no such
> > requirement, so I need to scale (and power on) a power domain only for
> > some of the OPPs.
> >
> > [1]: https://lore.kernel.org/linux-pm/20200831154938.ga33...@gerhold.net/
> > [2]:
> > https://lore.kernel.org/linux-arm-msm/20200910162610.ga7...@gerhold.net/
> >
> > So I think it would be good to discuss this use case first before we
> > decide on this patch (how to enable power domains managed by the OPP
> > core). I think there are two problems that need to be solved:
> >
> > 1. How can we drop our performance state votes for some of the OPPs?
> >I explained that problem earlier already:
> >
> > >
> > > I was thinking about something like that, but can you actually drop
> > > your performance state vote for one of the power domains using
> > > "required-opps"?
> > >
> > > At the moment it does not seem possible. I tried adding a special OPP
> > > using opp-level = <0> to reference that from required-opps, but the OPP
> > > core does not allow this:
> > >
> > > vddcx: Not all nodes have performance state set (7: 6)
> > > vddcx: Failed to add OPP table for index 0: -2
>
> This should fix it.
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index 214c1619b445..2483e765318a 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -2117,9 +2117,6 @@ int dev_pm_opp_xlate_performance_state(struct opp_table
> *src_table,
> int dest_pstate = -EINVAL;
> int i;
>
> - if (!pstate)
> - return 0;
> -
> /*
> * Normally the src_table will have the "required_opps" property set
> to
> * point to one of the OPPs in the dst_table, but in some cases the
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> index e72753be7dc7..1a9cb96484bb 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -842,7 +842,7 @@ static struct dev_pm_opp *_opp_add_static_v2(struct
> opp_table *opp_table,
> static int _of_add_opp_table_v2(struct device *dev, struct opp_table
> *opp_table)
> {
> struct device_node *np;
> - int ret, count = 0, pstate_count = 0;
> + int ret, count = 0;
> struct dev_pm_opp *opp;
>
> /* OPP table is already initialized for the device */
> @@ -876,20 +876,13 @@ static int _of_add_opp_table_v2(struct device *dev,
> struct opp_table *opp_table)
> goto remove_static_opp;
> }
>
> - list_for_each_entry(opp, _table->opp_list, node)
> - pstate_count += !!opp->pstate;
> -
> - /* Either all or none of the nodes shall have performance state set */
> - if (pstate_count && pstate_count != count) {
> - dev_err(dev, "Not all nodes have performance state set (%d:
> %d)\n",
> - count, pstate_count);
> - ret = -ENOENT;
> - goto remove_static_opp;
> + list_for_each_entry(opp, _table->opp_list, node) {
> + if (opp->pstate) {
> + opp_table->genpd_performance_state = true;
> + break;
> + }
> }
>
> - if (pstate_count)
> - opp_table->genpd_performance_state = true;
> -
> return 0;
>
> remove_static_opp:
>
Thanks, I will test this early next week!
> > 2. Where/when to enable the power domains: I need to enable the power
> >domain whenever I have a vote for a performance state. In the example
> >above the power domain should get enabled for >= 998 MHz and disabled
> >otherwise.
>
I will answer your questions for my use case, maybe Ulf or someone else
who knows more about power domains can chime in and say more about the
general case:
> - Why do you need to enable these power domains like this ?
At the moment power domains seem to have two independent states:
they can be powered on/off and they can have a performance state.
Both seem to be managed independently, e.g. a power domain can have a
non-zero performance state set but at the same time powered off.
The OPP core only calls dev_pm_genpd_set_performance_state(). No matter
if the power domain is powered on or not this will end up in the
set_performance_state() callback of the power domain driver.
And this is where behavior varies depending on the power domain driver.
Some drivers (e.g. qcom-cpr) will set the performance state even if
powered off, others (in my case: qcom rpmpd) will ignore the performance
state until their power_on() callback is called.
In general, I would expect that a power domain should be powered on
whenever there is at least one performance state vote > 0.
This does
Re: [PATCH v9 3/3] ASoC: qcom: sc7180: Add machine driver for sound card registration
Hi,
Thanks for removing the weird use of auxilliary devices :)
On Fri, Sep 11, 2020 at 06:22:59PM +0800, Cheng-Yi Chiang wrote:
> From: Ajit Pandey
>
> Add new driver to register sound card on sc7180 trogdor board and
> do the required configuration for lpass cpu dai and external codecs
> connected over MI2S interfaces.
>
> Signed-off-by: Ajit Pandey
> Signed-off-by: Cheng-Yi Chiang
> ---
> sound/soc/qcom/Kconfig | 12 ++
> sound/soc/qcom/Makefile | 2 +
> sound/soc/qcom/sc7180.c | 267
> 3 files changed, 281 insertions(+)
> create mode 100644 sound/soc/qcom/sc7180.c
>
> diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
> index a607ace8b089..0459185ee243 100644
> --- a/sound/soc/qcom/Kconfig
> +++ b/sound/soc/qcom/Kconfig
> @@ -116,4 +116,16 @@ config SND_SOC_SDM845
> SDM845 SoC-based systems.
> Say Y if you want to use audio device on this SoCs.
>
> +config SND_SOC_SC7180
> + tristate "SoC Machine driver for SC7180 boards"
> + depends on I2C
> + select SND_SOC_QCOM_COMMON
> + select SND_SOC_LPASS_SC7180
> + select SND_SOC_MAX98357A
> + select SND_SOC_RT5682_I2C
> + help
> + To add support for audio on Qualcomm Technologies Inc.
> + SC7180 SoC-based systems.
> + Say Y if you want to use audio device on this SoCs.
> +
> endif #SND_SOC_QCOM
> diff --git a/sound/soc/qcom/Makefile b/sound/soc/qcom/Makefile
> index 7972c9479ab0..0cdcbf367ef1 100644
> --- a/sound/soc/qcom/Makefile
> +++ b/sound/soc/qcom/Makefile
> @@ -17,12 +17,14 @@ snd-soc-storm-objs := storm.o
> snd-soc-apq8016-sbc-objs := apq8016_sbc.o
> snd-soc-apq8096-objs := apq8096.o
> snd-soc-sdm845-objs := sdm845.o
> +snd-soc-sc7180-objs := sc7180.o
> snd-soc-qcom-common-objs := common.o
>
> obj-$(CONFIG_SND_SOC_STORM) += snd-soc-storm.o
> obj-$(CONFIG_SND_SOC_APQ8016_SBC) += snd-soc-apq8016-sbc.o
> obj-$(CONFIG_SND_SOC_MSM8996) += snd-soc-apq8096.o
> obj-$(CONFIG_SND_SOC_SDM845) += snd-soc-sdm845.o
> +obj-$(CONFIG_SND_SOC_SC7180) += snd-soc-sc7180.o
> obj-$(CONFIG_SND_SOC_QCOM_COMMON) += snd-soc-qcom-common.o
>
> #DSP lib
> diff --git a/sound/soc/qcom/sc7180.c b/sound/soc/qcom/sc7180.c
> new file mode 100644
> index ..40bc4fc98842
> --- /dev/null
> +++ b/sound/soc/qcom/sc7180.c
> @@ -0,0 +1,267 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +//
> +// Copyright (c) 2020, The Linux Foundation. All rights reserved.
> +//
> +// sc7180.c -- ALSA SoC Machine driver for SC7180
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "../codecs/rt5682.h"
> +#include "common.h"
> +#include "lpass.h"
> +
> +#define DEFAULT_SAMPLE_RATE_48K 48000
> +#define DEFAULT_MCLK_RATE1920
> +#define RT5682_PLL1_FREQ (48000 * 512)
> +
> +struct sc7180_snd_data {
> + u32 pri_mi2s_clk_count;
> + struct snd_soc_jack hs_jack;
> + struct snd_soc_jack hdmi_jack;
> +};
[...]
> +
> +static const struct snd_soc_ops sc7180_ops = {
> + .startup = sc7180_snd_startup,
> + .shutdown = sc7180_snd_shutdown,
> +};
> +
> +static const struct snd_soc_dapm_widget sc7180_snd_widgets[] = {
> + SND_SOC_DAPM_HP("Headphone Jack", NULL),
> + SND_SOC_DAPM_MIC("Headset Mic", NULL),
> +};
> +
> +static struct snd_soc_card sc7180_card = {
> + .owner = THIS_MODULE,
> + .dapm_widgets = sc7180_snd_widgets,
> + .num_dapm_widgets = ARRAY_SIZE(sc7180_snd_widgets),
> +};
Given that you modify this struct and already allocate some memory
dynamically (sc7810_snd_data), it might be a bit cleaner to avoid
modifying global memory and instead allocate snd_soc_card dynamically as
well. Could just add it to sc7180_snd_data for example (see e.g. apq8016_sbc)
> +
> +static void sc7180_add_ops(struct snd_soc_card *card)
> +{
> + struct snd_soc_dai_link *link;
> + int i;
> +
> + for_each_card_prelinks(card, i, link) {
> + link->ops = _ops;
> + link->init = sc7180_init;
> + }
> +}
> +
> +static int sc7180_snd_platform_probe(struct platform_device *pdev)
> +{
> + struct snd_soc_card *card = _card;
> + struct sc7180_snd_data *data;
> + struct device *dev = >dev;
> + int ret;
> +
> + /* Allocate the private data */
> + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + card->dev = dev;
> + snd_soc_card_set_drvdata(card, data);
> +
> + ret = qcom_snd_parse_of(card);
> + if (ret) {
> + dev_err(dev, "Error parsing OF data\n");
This will just add noise in case of probe deferral. qcom_snd_parse_of()
already logs a message for most errors so you can just remove this one.
> + return ret;
> + }
> +
> + sc7180_add_ops(card);
> +
> + return devm_snd_soc_register_card(dev, card);
> +}
> +
> +static const struct of_device_id
Re: [PATCH v2] opp: Power on (virtual) power domains managed by the OPP core
Hi Viresh,
On Fri, Aug 28, 2020 at 11:57:28AM +0200, Stephan Gerhold wrote:
> On Fri, Aug 28, 2020 at 12:05:11PM +0530, Viresh Kumar wrote:
> > On 27-08-20, 13:44, Stephan Gerhold wrote:
> > > Hmm. Actually I was using this parameter for initial testing, and forced
> > > on the power domains from the qcom-cpufreq-nvmem driver. For my v1 patch
> > > I wanted to enable the power domains in dev_pm_opp_set_rate(), so there
> > > using the virt_devs parameter was not possible.
> >
> > Right, as we really do not want to enable it there and leave it for
> > the real consumers to handle.
> >
> > > On the other hand, creating the device links would be possible from the
> > > platform driver by using the parameter.
> >
> > Right.
> >
> > > > And so I think again if this patch should be picked instead of letting
> > > > the platform handle this ?
> > >
> > > It seems like originally the motivation for the parameter was that
> > > cpufreq consumers do *not* need to power on the power domains:
> > >
> > > Commit 17a8f868ae3e ("opp: Return genpd virtual devices from
> > > dev_pm_opp_attach_genpd()"):
> > > "The cpufreq drivers don't need to do runtime PM operations on
> > > the virtual devices returned by dev_pm_domain_attach_by_name() and so
> > > the virtual devices weren't shared with the callers of
> > > dev_pm_opp_attach_genpd() earlier.
> > >
> > > But the IO device drivers would want to do that. This patch updates
> > > the prototype of dev_pm_opp_attach_genpd() to accept another argument
> > > to return the pointer to the array of genpd virtual devices."
> >
> > Not just that I believe. There were also arguments that only the real
> > consumer knows how to handle multiple power domains. For example for a
> > USB or Camera module which can work in multiple modes, we may want to
> > enable only one power domain in say slow mode and another power domain
> > in fast mode. And so these kind of complex behavior/choices better be
> > left for the end consumer and not try to handle this generically in
> > the OPP core.
> >
> [...]
>
> It seems to me that there is more work needed to make such a use case
> really work, but it's hard to speculate without a real example.
>
So it seems like we have a real example now. :)
As mentioned in my other mail [1] it turns out I actually have such a
use case. I briefly explained it in [2], basically the clock that
provides higher CPU frequencies has some voltage requirements that
should be voted for using a power domain.
The clock that provides the lower CPU frequencies has no such
requirement, so I need to scale (and power on) a power domain only for
some of the OPPs.
[1]: https://lore.kernel.org/linux-pm/20200831154938.ga33...@gerhold.net/
[2]: https://lore.kernel.org/linux-arm-msm/20200910162610.ga7...@gerhold.net/
So I think it would be good to discuss this use case first before we
decide on this patch (how to enable power domains managed by the OPP
core). I think there are two problems that need to be solved:
1. How can we drop our performance state votes for some of the OPPs?
I explained that problem earlier already:
>
> I was thinking about something like that, but can you actually drop
> your performance state vote for one of the power domains using
> "required-opps"?
>
> At the moment it does not seem possible. I tried adding a special OPP
> using opp-level = <0> to reference that from required-opps, but the OPP
> core does not allow this:
>
> vddcx: Not all nodes have performance state set (7: 6)
> vddcx: Failed to add OPP table for index 0: -2
>
> So the "virt_devs" parameter would allow you to disable the power
> domain, but not to drop your performance state vote (you could only vote
> for the lowest OPP, not 0...)
Not sure if it makes sense but I think somehow allowing the additional
opp-level = <0> would be a simple solution. For example:
rpmpd: power-controller {
rpmpd_opp_table: opp-table {
compatible = "operating-points-v2";
/*
* This one can be referenced to drop the performance state
* vote within required-opps.
*/
rpmpd_opp_none: opp0 {
opp-level = <0>;
};
rpmpd_opp_retention: opp1 {
opp-level = <1>;
};
/* ... */
};
};
cpu_opp_table: cpu-opp-table {
compatible = &quo
Re: [PATCH v2] opp: Power on (virtual) power domains managed by the OPP core
Hi Viresh, On Mon, Aug 31, 2020 at 05:44:57PM +0530, Viresh Kumar wrote: > On 26-08-20, 11:33, Stephan Gerhold wrote: > > dev_pm_opp_attach_genpd() allows attaching an arbitrary number of > > power domains to an OPP table. In that case, the genpd core will > > create a virtual device for each of the power domains. > > > > At the moment, the OPP core only calls > > dev_pm_genpd_set_performance_state() on these virtual devices. > > It does not attempt to power on the power domains. Therefore > > the required power domain might never get turned on. > > > > So far, dev_pm_opp_attach_genpd() is only used in qcom-cpufreq-nvmem.c > > to attach the CPR power domain to the CPU OPP table. The CPR driver > > does not check if it was actually powered on so this did not cause > > any problems. However, other drivers (e.g. rpmpd) might ignore the > > performance state until the power domain is actually powered on. > > > > Since these virtual devices are managed exclusively by the OPP core, > > I would say that it should also be responsible to ensure they are > > enabled. > > > > This commit implements this similar to the non-virtual power domains; > > we create device links for each of attached power domains so that they > > are turned on whenever the consumer device is active. > > > > Signed-off-by: Stephan Gerhold > > --- > > Applied with some changes, hope that is fine: > I appreciate it, thank you! But actually after our discussion regarding the "manage multiple power domains which might not always need to be on" use case I would like to explore that a bit further before we decide on a final solution that complicates changes later. The reason I mention this is that after our discussion I have been (again) staring at the vendor implementation of CPU frequency scaling of the platform I'm working on (qcom msm8916). Actually there seems to be yet another power domain that is scaled only for some CPU frequencies within the clock driver. (The vendor driver implies this is a requirement of the PLL clock that is used for higher CPU frequencies, but not sure...) I don't fully understand how to implement this in mainline yet. I have started some research on these "voltage requirements" for clocks, and based on previous discussions [1] and patches [2] it seems like I'm *not* supposed to add this to the clock driver, but rather as another required-opp to the CPU OPP table. If that is the case, we would pretty much have a situation like you described, a power domain that should only be scaled for some of the OPPs (the higher CPU frequencies). But first I need to do some more research, and probably discuss how to handle that power domain separately first. I think it would be easier if we postpone this patch till then. I don't think anyone else needs this patch at the moment. [1]: https://lore.kernel.org/linux-clk/9439bd29e3ccd5424a8e9b464c8c7...@codeaurora.org/ [2]: https://lore.kernel.org/linux-pm/20190320094918.20234-1-rna...@codeaurora.org/ > Signed-off-by: Stephan Gerhold > [ Viresh: Rearranged the code to remove extra loop and minor cleanup ] FWIW, the reason I put this into an extra loop is that the dev_pm_domain_attach_by_name() might return -EPROBE_DEFER (or some other error) for some of the power domains. If you create the device links before attaching all domains you might unnecessarily turn on+off some of them. Having it in a separate loop avoids that, because we only start powering on the power domains when we know that all the power domains are available. Thanks! Stephan > Signed-off-by: Viresh Kumar > --- > drivers/opp/core.c | 37 - > drivers/opp/opp.h | 1 + > 2 files changed, 37 insertions(+), 1 deletion(-) > > diff --git a/drivers/opp/core.c b/drivers/opp/core.c > index e65174725a4d..b608b0253079 100644 > --- a/drivers/opp/core.c > +++ b/drivers/opp/core.c > @@ -17,6 +17,7 @@ > #include > #include > #include > +#include > #include > > #include "opp.h" > @@ -1967,10 +1968,15 @@ static void _opp_detach_genpd(struct opp_table > *opp_table) > if (!opp_table->genpd_virt_devs[index]) > continue; > > + if (opp_table->genpd_virt_links[index]) > + device_link_del(opp_table->genpd_virt_links[index]); > + > dev_pm_domain_detach(opp_table->genpd_virt_devs[index], false); > opp_table->genpd_virt_devs[index] = NULL; > } > > + kfree(opp_table->genpd_virt_links); > + opp_table->genpd_virt_links = NULL; > kfree(opp_table->genpd_virt_devs); > opp_table->genpd_virt_devs = NULL; > } > @@ -2002,8 +
Re: [PATCH v2] opp: Power on (virtual) power domains managed by the OPP core
On Fri, Aug 28, 2020 at 12:05:11PM +0530, Viresh Kumar wrote:
> On 27-08-20, 13:44, Stephan Gerhold wrote:
> > Hmm. Actually I was using this parameter for initial testing, and forced
> > on the power domains from the qcom-cpufreq-nvmem driver. For my v1 patch
> > I wanted to enable the power domains in dev_pm_opp_set_rate(), so there
> > using the virt_devs parameter was not possible.
>
> Right, as we really do not want to enable it there and leave it for
> the real consumers to handle.
>
> > On the other hand, creating the device links would be possible from the
> > platform driver by using the parameter.
>
> Right.
>
> > > And so I think again if this patch should be picked instead of letting
> > > the platform handle this ?
> >
> > It seems like originally the motivation for the parameter was that
> > cpufreq consumers do *not* need to power on the power domains:
> >
> > Commit 17a8f868ae3e ("opp: Return genpd virtual devices from
> > dev_pm_opp_attach_genpd()"):
> > "The cpufreq drivers don't need to do runtime PM operations on
> > the virtual devices returned by dev_pm_domain_attach_by_name() and so
> > the virtual devices weren't shared with the callers of
> > dev_pm_opp_attach_genpd() earlier.
> >
> > But the IO device drivers would want to do that. This patch updates
> > the prototype of dev_pm_opp_attach_genpd() to accept another argument
> > to return the pointer to the array of genpd virtual devices."
>
> Not just that I believe. There were also arguments that only the real
> consumer knows how to handle multiple power domains. For example for a
> USB or Camera module which can work in multiple modes, we may want to
> enable only one power domain in say slow mode and another power domain
> in fast mode. And so these kind of complex behavior/choices better be
> left for the end consumer and not try to handle this generically in
> the OPP core.
>
I was thinking about something like that, but can you actually drop
your performance state vote for one of the power domains using
"required-opps"?
At the moment it does not seem possible. I tried adding a special OPP
using opp-level = <0> to reference that from required-opps, but the OPP
core does not allow this:
vddcx: Not all nodes have performance state set (7: 6)
vddcx: Failed to add OPP table for index 0: -2
So the "virt_devs" parameter would allow you to disable the power
domain, but not to drop your performance state vote (you could only vote
for the lowest OPP, not 0...)
This is why I said: "And if there is such a use case, chances are good
that this use case is so special that using the OPP API to set the
performance states would not work either."
It seems to me that there is more work needed to make such a use case
really work, but it's hard to speculate without a real example.
> > But the reason why I made this patch is that actually something *should*
> > enable the power domains even for the cpufreq case.
>
> Ulf, what do you think about this ? IIRC from our previous discussions
> someone asked me not do so.
>
> > If every user of dev_pm_opp_attach_genpd() ends up creating these device
> > links we might as well manage those directly from the OPP core.
>
> Sure, I am all in for reducing code duplication, but ...
>
> > I cannot think of any use case where you would not want to manage those
> > power domains using device links. And if there is such a use case,
> > chances are good that this use case is so special that using the OPP API
> > to set the performance states would not work either. In either case,
> > this seems like something that should be discussed once there is such a
> > use case.
>
> The example I gave earlier shows a common case where we need to handle
> this at the end users which still want to use the OPP API.
>
> > At the moment, there are only two users of dev_pm_opp_attach_genpd():
> >
> > - cpufreq (qcom-cpufreq-nvmem)
> > - I/O (venus, recently added in linux-next [1])
> >
> > [1]:
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=9a538b83612c8b5848bf840c2ddcd86dda1c8c76
> >
> > In fact, venus adds the device link exactly the same way as in my patch.
> > So we could move that to the OPP core, simplify the venus code and
> > remove the virt_devs parameter. That would be my suggestion.
> >
> > I can submit a v3 with that if you agree (or we take this patch as-is
> > and remove the parameter separately - I just checked and creating a
> > device link twice does not seem to cause any problems...)
>
&
Re: [PATCH v2] opp: Power on (virtual) power domains managed by the OPP core
On Thu, Aug 27, 2020 at 03:31:04PM +0530, Viresh Kumar wrote:
> On 26-08-20, 11:33, Stephan Gerhold wrote:
> > diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> > index 8b3c3986f589..7e53a7b94c59 100644
> > --- a/drivers/opp/core.c
> > +++ b/drivers/opp/core.c
> > @@ -17,6 +17,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > #include "opp.h"
> > @@ -1964,10 +1965,13 @@ static void _opp_detach_genpd(struct opp_table
> > *opp_table)
> > if (!opp_table->genpd_virt_devs[index])
> > continue;
> >
> > + if (opp_table->genpd_virt_links &&
> > opp_table->genpd_virt_links[index])
> > + device_link_del(opp_table->genpd_virt_links[index]);
> > dev_pm_domain_detach(opp_table->genpd_virt_devs[index], false);
> > opp_table->genpd_virt_devs[index] = NULL;
> > }
> >
> > + kfree(opp_table->genpd_virt_links);
> > kfree(opp_table->genpd_virt_devs);
> > opp_table->genpd_virt_devs = NULL;
> > }
> > @@ -1999,8 +2003,10 @@ struct opp_table *dev_pm_opp_attach_genpd(struct
> > device *dev,
> > {
> > struct opp_table *opp_table;
> > struct device *virt_dev;
> > - int index = 0, ret = -EINVAL;
> > + struct device_link *dev_link;
> > + int index = 0, ret = -EINVAL, num_devs;
> > const char **name = names;
> > + u32 flags;
> >
> > opp_table = dev_pm_opp_get_opp_table(dev);
> > if (IS_ERR(opp_table))
> > @@ -2049,6 +2055,32 @@ struct opp_table *dev_pm_opp_attach_genpd(struct
> > device *dev,
>
> I was about to apply this patch when I noticed that this routine does
> return the array of virtual devices back to the caller, like the qcom
> cpufreq driver in this case. IIRC we did it this way as a generic
> solution for this in the OPP core wasn't preferable.
>
Hmm. Actually I was using this parameter for initial testing, and forced
on the power domains from the qcom-cpufreq-nvmem driver. For my v1 patch
I wanted to enable the power domains in dev_pm_opp_set_rate(), so there
using the virt_devs parameter was not possible.
On the other hand, creating the device links would be possible from the
platform driver by using the parameter.
> And so I think again if this patch should be picked instead of letting
> the platform handle this ?
>
It seems like originally the motivation for the parameter was that
cpufreq consumers do *not* need to power on the power domains:
Commit 17a8f868ae3e ("opp: Return genpd virtual devices from
dev_pm_opp_attach_genpd()"):
"The cpufreq drivers don't need to do runtime PM operations on
the virtual devices returned by dev_pm_domain_attach_by_name() and so
the virtual devices weren't shared with the callers of
dev_pm_opp_attach_genpd() earlier.
But the IO device drivers would want to do that. This patch updates
the prototype of dev_pm_opp_attach_genpd() to accept another argument
to return the pointer to the array of genpd virtual devices."
But the reason why I made this patch is that actually something *should*
enable the power domains even for the cpufreq case.
If every user of dev_pm_opp_attach_genpd() ends up creating these device
links we might as well manage those directly from the OPP core.
I cannot think of any use case where you would not want to manage those
power domains using device links. And if there is such a use case,
chances are good that this use case is so special that using the OPP API
to set the performance states would not work either. In either case,
this seems like something that should be discussed once there is such a
use case.
At the moment, there are only two users of dev_pm_opp_attach_genpd():
- cpufreq (qcom-cpufreq-nvmem)
- I/O (venus, recently added in linux-next [1])
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=9a538b83612c8b5848bf840c2ddcd86dda1c8c76
In fact, venus adds the device link exactly the same way as in my patch.
So we could move that to the OPP core, simplify the venus code and
remove the virt_devs parameter. That would be my suggestion.
I can submit a v3 with that if you agree (or we take this patch as-is
and remove the parameter separately - I just checked and creating a
device link twice does not seem to cause any problems...)
Thanks!
Stephan
Re: [PATCH] opp: Drop unnecessary check frmo dev_pm_opp_attach_genpd()
On Thu, Aug 27, 2020 at 03:35:15PM +0530, Viresh Kumar wrote:
> Since commit c0ab9e0812da ("opp: Allocate genpd_virt_devs from
> dev_pm_opp_attach_genpd()"), the allocation of the virtual devices is
> moved to dev_pm_opp_attach_genpd() and this check isn't required anymore
> as it will always fail. Drop it.
>
Only partially related to this patch, but actually I noticed that
dev_pm_opp_attach_genpd() does not work correctly if it is called
multiple times.
For example, qcom-cpufreq-nvmem calls this for every CPU because it is
not aware that the OPP table is shared between the CPUs.
dev_pm_opp_attach_genpd() does not check if opp_table->genpd_virt_devs
is already set, so when it is called again for other CPUs we will:
- Cause a memory leak (opp_table->genpd_virt_devs is just replaced
with new memory)
- Attach the power domains multiple times
- Never detach the power domains from earlier calls
- Crash when dev_pm_opp_detach_genpd() is called the second time
Oh well. :)
I think the function should just return and do nothing if the power
domains were already attached, just like dev_pm_opp_set_supported_hw()
etc. But this is a bit complicated to implement with the "virt_devs"
parameter, since callers will probably assume that to be valid if we
return success.
Another advantage of my proposal to remove the virt_devs parameter [1] :)
Stephan
Re: [PATCH 2/3] opp: Allow opp-supported-hw to contain multiple versions
On Wed, Aug 26, 2020 at 05:20:29PM +0530, Viresh Kumar wrote:
> The bindings allow multiple versions to be passed to "opp-supported-hw"
> property, either of which can result in enabling of the OPP.
>
> Update code to allow that.
>
> Signed-off-by: Viresh Kumar
This is exactly what I was looking for!
And it works just fine in my tests:
Tested-by: Stephan Gerhold
Thank you!
Stephan
> ---
> drivers/opp/of.c | 47 +--
> 1 file changed, 33 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/opp/of.c b/drivers/opp/of.c
> index e39ddcc779af..5dac8bffd68c 100644
> --- a/drivers/opp/of.c
> +++ b/drivers/opp/of.c
> @@ -434,9 +434,9 @@ EXPORT_SYMBOL_GPL(dev_pm_opp_of_find_icc_paths);
> static bool _opp_is_supported(struct device *dev, struct opp_table
> *opp_table,
> struct device_node *np)
> {
> - unsigned int count = opp_table->supported_hw_count;
> - u32 version;
> - int ret;
> + unsigned int levels = opp_table->supported_hw_count;
> + int count, versions, ret, i, j;
> + u32 val;
>
> if (!opp_table->supported_hw) {
> /*
> @@ -451,21 +451,40 @@ static bool _opp_is_supported(struct device *dev,
> struct opp_table *opp_table,
> return true;
> }
>
> - while (count--) {
> - ret = of_property_read_u32_index(np, "opp-supported-hw", count,
> - );
> - if (ret) {
> - dev_warn(dev, "%s: failed to read opp-supported-hw
> property at index %d: %d\n",
> - __func__, count, ret);
> - return false;
> + count = of_property_count_u32_elems(np, "opp-supported-hw");
> + if (count <= 0 || count % levels) {
> + dev_err(dev, "%s: Invalid opp-supported-hw property (%d)\n",
> + __func__, count);
> + return false;
> + }
> +
> + versions = count / levels;
> +
> + /* All levels in at least one of the versions should match */
> + for (i = 0; i < versions; i++) {
> + bool supported = true;
> +
> + for (j = 0; j < levels; j++) {
> + ret = of_property_read_u32_index(np, "opp-supported-hw",
> + i * levels + j, );
> + if (ret) {
> + dev_warn(dev, "%s: failed to read
> opp-supported-hw property at index %d: %d\n",
> + __func__, i * levels + j, ret);
> + return false;
> + }
> +
> + /* Check if the level is supported */
> + if (!(val & opp_table->supported_hw[j])) {
> + supported = false;
> + break;
> + }
> }
>
> - /* Both of these are bitwise masks of the versions */
> - if (!(version & opp_table->supported_hw[count]))
> - return false;
> + if (supported)
> + return true;
> }
>
> - return true;
> + return false;
> }
>
> static int opp_parse_supplies(struct dev_pm_opp *opp, struct device *dev,
> --
> 2.25.0.rc1.19.g042ed3e048af
>
Re: [PATCH v6 2/2] ASoC: qcom: sc7180: Add machine driver for sound card registration
On Wed, Aug 26, 2020 at 07:04:54PM +0800, Cheng-Yi Chiang wrote:
> From: Ajit Pandey
>
> Add new driver to register sound card on sc7180 trogdor board and
> do the required configuration for lpass cpu dai and external codecs
> connected over MI2S interfaces.
>
> Signed-off-by: Ajit Pandey
> Signed-off-by: Cheng-Yi Chiang
> Reviewed-by: Tzung-Bi Shih
> ---
> sound/soc/qcom/Kconfig | 12 ++
> sound/soc/qcom/Makefile | 2 +
> sound/soc/qcom/sc7180.c | 244
> 3 files changed, 258 insertions(+)
> create mode 100644 sound/soc/qcom/sc7180.c
>
> diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
> index a607ace8b089..63678b746299 100644
> --- a/sound/soc/qcom/Kconfig
> +++ b/sound/soc/qcom/Kconfig
> @@ -116,4 +116,16 @@ config SND_SOC_SDM845
> SDM845 SoC-based systems.
> Say Y if you want to use audio device on this SoCs.
>
> +config SND_SOC_SC7180
> + tristate "SoC Machine driver for SC7180 boards"
> + depends on SND_SOC_QCOM
> + select SND_SOC_QCOM_COMMON
> + select SND_SOC_LPASS_SC7180
> + select SND_SOC_MAX98357A
> + select SND_SOC_RT5682
> + help
> + To add support for audio on Qualcomm Technologies Inc.
> + SC7180 SoC-based systems.
> + Say Y if you want to use audio device on this SoCs.
> +
> endif #SND_SOC_QCOM
> diff --git a/sound/soc/qcom/Makefile b/sound/soc/qcom/Makefile
> index 7972c9479ab0..0cdcbf367ef1 100644
> --- a/sound/soc/qcom/Makefile
> +++ b/sound/soc/qcom/Makefile
> @@ -17,12 +17,14 @@ snd-soc-storm-objs := storm.o
> snd-soc-apq8016-sbc-objs := apq8016_sbc.o
> snd-soc-apq8096-objs := apq8096.o
> snd-soc-sdm845-objs := sdm845.o
> +snd-soc-sc7180-objs := sc7180.o
> snd-soc-qcom-common-objs := common.o
>
> obj-$(CONFIG_SND_SOC_STORM) += snd-soc-storm.o
> obj-$(CONFIG_SND_SOC_APQ8016_SBC) += snd-soc-apq8016-sbc.o
> obj-$(CONFIG_SND_SOC_MSM8996) += snd-soc-apq8096.o
> obj-$(CONFIG_SND_SOC_SDM845) += snd-soc-sdm845.o
> +obj-$(CONFIG_SND_SOC_SC7180) += snd-soc-sc7180.o
> obj-$(CONFIG_SND_SOC_QCOM_COMMON) += snd-soc-qcom-common.o
>
> #DSP lib
> diff --git a/sound/soc/qcom/sc7180.c b/sound/soc/qcom/sc7180.c
> new file mode 100644
> index ..7849376f63ba
> --- /dev/null
> +++ b/sound/soc/qcom/sc7180.c
> @@ -0,0 +1,244 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +//
> +// Copyright (c) 2020, The Linux Foundation. All rights reserved.
> +//
> +// sc7180.c -- ALSA SoC Machine driver for SC7180
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "../codecs/rt5682.h"
> +#include "common.h"
> +#include "lpass.h"
> +
> +#define DEFAULT_SAMPLE_RATE_48K 48000
> +#define DEFAULT_MCLK_RATE1920
> +#define RT5682_PLL1_FREQ (48000 * 512)
> +
> +struct sc7180_snd_data {
> + struct snd_soc_jack jack;
> + u32 pri_mi2s_clk_count;
> +};
> +
> +static void sc7180_jack_free(struct snd_jack *jack)
> +{
> + struct snd_soc_component *component = jack->private_data;
> +
> + snd_soc_component_set_jack(component, NULL, NULL);
> +}
> +
> +static int sc7180_headset_init(struct snd_soc_component *component)
> +{
> + struct snd_soc_card *card = component->card;
> + struct sc7180_snd_data *pdata = snd_soc_card_get_drvdata(card);
> + struct snd_jack *jack;
> + int rval;
> +
> + rval = snd_soc_card_jack_new(
> + card, "Headset Jack",
> + SND_JACK_HEADSET |
> + SND_JACK_HEADPHONE |
> + SND_JACK_BTN_0 | SND_JACK_BTN_1 |
> + SND_JACK_BTN_2 | SND_JACK_BTN_3,
> + >jack, NULL, 0);
> +
> + if (rval < 0) {
> + dev_err(card->dev, "Unable to add Headset Jack\n");
> + return rval;
> + }
> +
> + jack = pdata->jack.jack;
> +
> + snd_jack_set_key(jack, SND_JACK_BTN_0, KEY_PLAYPAUSE);
> + snd_jack_set_key(jack, SND_JACK_BTN_1, KEY_VOICECOMMAND);
> + snd_jack_set_key(jack, SND_JACK_BTN_2, KEY_VOLUMEUP);
> + snd_jack_set_key(jack, SND_JACK_BTN_3, KEY_VOLUMEDOWN);
> +
> + jack->private_data = component;
> + jack->private_free = sc7180_jack_free;
> +
> + rval = snd_soc_component_set_jack(component,
> + >jack, NULL);
> + if (rval != 0 && rval != -EOPNOTSUPP) {
> + dev_warn(card->dev, "Failed to set jack: %d\n", rval);
> + return rval;
> + }
> +
> + return 0;
> +}
> +
> +static struct snd_soc_aux_dev sc7180_headset_dev = {
> + .dlc = COMP_EMPTY(),
> + .init = sc7180_headset_init,
> +};
> +
[...]
> +static struct snd_soc_card sc7180_card = {
> + .owner = THIS_MODULE,
> + .aux_dev = _headset_dev,
> + .num_aux_devs = 1,
> + .dapm_widgets = sc7180_snd_widgets,
> + .num_dapm_widgets = ARRAY_SIZE(sc7180_snd_widgets),
> +};
> +
> +static int
[PATCH v2] opp: Power on (virtual) power domains managed by the OPP core
dev_pm_opp_attach_genpd() allows attaching an arbitrary number of
power domains to an OPP table. In that case, the genpd core will
create a virtual device for each of the power domains.
At the moment, the OPP core only calls
dev_pm_genpd_set_performance_state() on these virtual devices.
It does not attempt to power on the power domains. Therefore
the required power domain might never get turned on.
So far, dev_pm_opp_attach_genpd() is only used in qcom-cpufreq-nvmem.c
to attach the CPR power domain to the CPU OPP table. The CPR driver
does not check if it was actually powered on so this did not cause
any problems. However, other drivers (e.g. rpmpd) might ignore the
performance state until the power domain is actually powered on.
Since these virtual devices are managed exclusively by the OPP core,
I would say that it should also be responsible to ensure they are
enabled.
This commit implements this similar to the non-virtual power domains;
we create device links for each of attached power domains so that they
are turned on whenever the consumer device is active.
Signed-off-by: Stephan Gerhold
---
Related discussion:
https://lore.kernel.org/linux-arm-msm/20200426123140.ga190...@gerhold.net/
v1: https://lore.kernel.org/linux-pm/20200730080146.25185-4-step...@gerhold.net/
Changes in v2:
- Use device links instead of enabling the power domains in
dev_pm_opp_set_rate()
---
drivers/opp/core.c | 34 +-
drivers/opp/opp.h | 1 +
2 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 8b3c3986f589..7e53a7b94c59 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include "opp.h"
@@ -1964,10 +1965,13 @@ static void _opp_detach_genpd(struct opp_table
*opp_table)
if (!opp_table->genpd_virt_devs[index])
continue;
+ if (opp_table->genpd_virt_links &&
opp_table->genpd_virt_links[index])
+ device_link_del(opp_table->genpd_virt_links[index]);
dev_pm_domain_detach(opp_table->genpd_virt_devs[index], false);
opp_table->genpd_virt_devs[index] = NULL;
}
+ kfree(opp_table->genpd_virt_links);
kfree(opp_table->genpd_virt_devs);
opp_table->genpd_virt_devs = NULL;
}
@@ -1999,8 +2003,10 @@ struct opp_table *dev_pm_opp_attach_genpd(struct device
*dev,
{
struct opp_table *opp_table;
struct device *virt_dev;
- int index = 0, ret = -EINVAL;
+ struct device_link *dev_link;
+ int index = 0, ret = -EINVAL, num_devs;
const char **name = names;
+ u32 flags;
opp_table = dev_pm_opp_get_opp_table(dev);
if (IS_ERR(opp_table))
@@ -2049,6 +2055,32 @@ struct opp_table *dev_pm_opp_attach_genpd(struct device
*dev,
name++;
}
+ /* Create device links to enable the power domains when necessary */
+ opp_table->genpd_virt_links = kcalloc(opp_table->required_opp_count,
+
sizeof(*opp_table->genpd_virt_links),
+ GFP_KERNEL);
+ if (!opp_table->genpd_virt_links)
+ goto err;
+
+ /* Turn on power domain initially if consumer is active */
+ pm_runtime_get_noresume(dev);
+ flags = DL_FLAG_PM_RUNTIME | DL_FLAG_STATELESS;
+ if (pm_runtime_active(dev))
+ flags |= DL_FLAG_RPM_ACTIVE;
+
+ num_devs = index;
+ for (index = 0; index < num_devs; index++) {
+ dev_link = device_link_add(dev,
opp_table->genpd_virt_devs[index],
+ flags);
+ if (!dev_link) {
+ dev_err(dev, "Failed to create device link\n");
+ pm_runtime_put(dev);
+ goto err;
+ }
+ opp_table->genpd_virt_links[index] = dev_link;
+ }
+ pm_runtime_put(dev);
+
if (virt_devs)
*virt_devs = opp_table->genpd_virt_devs;
mutex_unlock(_table->genpd_virt_dev_lock);
diff --git a/drivers/opp/opp.h b/drivers/opp/opp.h
index 78e876ec803e..be5526cdbdba 100644
--- a/drivers/opp/opp.h
+++ b/drivers/opp/opp.h
@@ -186,6 +186,7 @@ struct opp_table {
struct mutex genpd_virt_dev_lock;
struct device **genpd_virt_devs;
+ struct device_link **genpd_virt_links;
struct opp_table **required_opp_tables;
unsigned int required_opp_count;
--
2.28.0
Re: [RFC PATCH 3/3] opp: Power on (virtual) power domains managed by the OPP core
On Tue, Aug 25, 2020 at 02:42:54PM +0200, Ulf Hansson wrote: > On Tue, 25 Aug 2020 at 09:34, Stephan Gerhold wrote: > > > > On Tue, Aug 25, 2020 at 08:43:42AM +0200, Ulf Hansson wrote: > > > On Tue, 25 Aug 2020 at 06:43, Viresh Kumar > > > wrote: > > > > > > > > On 24-08-20, 17:08, Stephan Gerhold wrote: > > > > > On Mon, Aug 24, 2020 at 04:36:57PM +0200, Ulf Hansson wrote: > > > > > > That said, perhaps should rely on the consumer to deploy runtime PM > > > > > > support, but let the OPP core to set up the device links for the > > > > > > genpd > > > > > > virtual devices!? > > > > > > > > > > > > > > > > Yes, that would be the alternative option. > > > > > > > > That is the right option IMO. > > > > > > > > > I would be fine with it as long as it also works for the CPUfreq case. > > > > > > > > > > I don't think anything manages runtime PM for the CPU device, just > > > > > like no-one calls dev_pm_opp_set_rate(cpu_dev, 0). So with my patch > > > > > the > > > > > power domain is essentially kept always-on (except for system > > > > > suspend). > > > > > At least in my case this is intended. > > > > > > > > > > If device links also keep the power domains on if the consumer device > > > > > does not make use of runtime PM it should work fine for my case. > > > > > > > > With device link, you only need to do rpm enable/disable on the > > > > consumer device > > > > and it will get propagated by itself. > > > > > > Note that the default state for the genpd virtual device(s) is that > > > runtime PM has been enabled for them. This means it's left in runtime > > > suspended state, which allows its PM domain to be powered off (if all > > > other devices and child domains for it allow that too, of course). > > > > > > > > > > > > Personally, I think my original patch (without device links) fits > > > > > better > > > > > into the OPP API, for the following two reasons. > > > > > > > > > > With device links: > > > > > > > > > > 1. Unlike regulators/interconnects, attached power domains would be > > > > > controlled by runtime PM instead of dev_pm_opp_set_rate(opp_dev, > > > > > 0). > > > > > > > > > > 2. ... some driver using OPP tables might not make use of runtime > > > > > PM. > > > > > In that case, the power domains would stay on the whole time, > > > > > even if dev_pm_opp_set_rate(opp_dev, 0) was called. > > > > > > > > > > With my patch, the power domain state is directly related to the > > > > > dev_pm_opp_set_rate(opp_dev, 0) call, which is more intuitive than > > > > > relying on the runtime PM state in my opinion. > > > > > > > > So opp-set-rate isn't in the best of shape TBH, some things are left > > > > for the > > > > drivers while other are done by it. Regulator-enable/disable was moved > > > > to it > > > > some time back as people needed something like that. While on the other > > > > hand, > > > > clk_enable/disable doesn't happen there, nor does rpm enable/disable. > > > > > > > > Maybe one day we may want to do that, but lets make sure someone wants > > > > to do > > > > that first. > > > > > > > > Anyway, even in that case both of the changes would be required. We > > > > must make > > > > device links nevertheless first. And later on if required, we may want > > > > to do rpm > > > > enable/disable on the consumer device itself. > > > > > > This sounds like a reasonable step-by-step approach. > > > > > > Then, to create the device links, we should use DL_FLAG_PM_RUNTIME, > > > DL_FLAG_STATELESS. > > > > > > > OK, I will give this a try later this week. > > > > > But whether we should use DL_FLAG_RPM_ACTIVE as well, to initially > > > runtime resume the supplier (the genpd virtual device), is harder to > > > know - as that kind of depends on expectations by the consumer device > > > driver. > > > > > > > I'm not sure I understand the purpose of that flag. I thought we want to > > link the PM state of the virtual genpd device (supplier) to the PM state > > of the device of the OPP table (consumer). > > Correct, but this is about synchronizing the initial runtime PM state > of the consumer and supplier. > > > > > Shouldn't it just determine the initial state based on the state of the > > consumer device? > > We could do that. Then something along the lines of the below, should work: > > pm_runtime_get_noresume(consumer) - to prevent runtime suspend, temporarily. > > if(pm_runtime_active(consumer)) > create links with DL_FLAG_RPM_ACTIVE > else > create links without DL_FLAG_RPM_ACTIVE > > pm_runtime_put(consumer) > This seems to work as expected, thanks for the suggestion! I will submit a v2 with that shortly. Thanks! Stephan
Re: [RFC PATCH 3/3] opp: Power on (virtual) power domains managed by the OPP core
On Tue, Aug 25, 2020 at 08:43:42AM +0200, Ulf Hansson wrote: > On Tue, 25 Aug 2020 at 06:43, Viresh Kumar wrote: > > > > On 24-08-20, 17:08, Stephan Gerhold wrote: > > > On Mon, Aug 24, 2020 at 04:36:57PM +0200, Ulf Hansson wrote: > > > > That said, perhaps should rely on the consumer to deploy runtime PM > > > > support, but let the OPP core to set up the device links for the genpd > > > > virtual devices!? > > > > > > > > > > Yes, that would be the alternative option. > > > > That is the right option IMO. > > > > > I would be fine with it as long as it also works for the CPUfreq case. > > > > > > I don't think anything manages runtime PM for the CPU device, just > > > like no-one calls dev_pm_opp_set_rate(cpu_dev, 0). So with my patch the > > > power domain is essentially kept always-on (except for system suspend). > > > At least in my case this is intended. > > > > > > If device links also keep the power domains on if the consumer device > > > does not make use of runtime PM it should work fine for my case. > > > > With device link, you only need to do rpm enable/disable on the consumer > > device > > and it will get propagated by itself. > > Note that the default state for the genpd virtual device(s) is that > runtime PM has been enabled for them. This means it's left in runtime > suspended state, which allows its PM domain to be powered off (if all > other devices and child domains for it allow that too, of course). > > > > > > Personally, I think my original patch (without device links) fits better > > > into the OPP API, for the following two reasons. > > > > > > With device links: > > > > > > 1. Unlike regulators/interconnects, attached power domains would be > > > controlled by runtime PM instead of dev_pm_opp_set_rate(opp_dev, 0). > > > > > > 2. ... some driver using OPP tables might not make use of runtime PM. > > > In that case, the power domains would stay on the whole time, > > > even if dev_pm_opp_set_rate(opp_dev, 0) was called. > > > > > > With my patch, the power domain state is directly related to the > > > dev_pm_opp_set_rate(opp_dev, 0) call, which is more intuitive than > > > relying on the runtime PM state in my opinion. > > > > So opp-set-rate isn't in the best of shape TBH, some things are left for the > > drivers while other are done by it. Regulator-enable/disable was moved to it > > some time back as people needed something like that. While on the other > > hand, > > clk_enable/disable doesn't happen there, nor does rpm enable/disable. > > > > Maybe one day we may want to do that, but lets make sure someone wants to do > > that first. > > > > Anyway, even in that case both of the changes would be required. We must > > make > > device links nevertheless first. And later on if required, we may want to > > do rpm > > enable/disable on the consumer device itself. > > This sounds like a reasonable step-by-step approach. > > Then, to create the device links, we should use DL_FLAG_PM_RUNTIME, > DL_FLAG_STATELESS. > OK, I will give this a try later this week. > But whether we should use DL_FLAG_RPM_ACTIVE as well, to initially > runtime resume the supplier (the genpd virtual device), is harder to > know - as that kind of depends on expectations by the consumer device > driver. > I'm not sure I understand the purpose of that flag. I thought we want to link the PM state of the virtual genpd device (supplier) to the PM state of the device of the OPP table (consumer). Shouldn't it just determine the initial state based on the state of the consumer device? Thanks! Stephan
Re: [RFC PATCH 3/3] opp: Power on (virtual) power domains managed by the OPP core
On Mon, Aug 24, 2020 at 04:36:57PM +0200, Ulf Hansson wrote:
> On Mon, 24 Aug 2020 at 13:56, Stephan Gerhold wrote:
> >
> > On Mon, Aug 24, 2020 at 04:57:44PM +0530, Viresh Kumar wrote:
> > > On 30-07-20, 10:01, Stephan Gerhold wrote:
> > > > dev_pm_opp_attach_genpd() allows attaching an arbitrary number of
> > > > power domains to an OPP table. In that case, the genpd core will
> > > > create a virtual device for each of the power domains.
> > > >
> > > > At the moment, the OPP core only calls
> > > > dev_pm_genpd_set_performance_state() on these virtual devices.
> > > > It does not attempt to power on the power domains. Therefore
> > > > the required power domain might never get turned on.
> > > >
> > > > So far, dev_pm_opp_attach_genpd() is only used in qcom-cpufreq-nvmem.c
> > > > to attach the CPR power domain to the CPU OPP table. The CPR driver
> > > > does not check if it was actually powered on so this did not cause
> > > > any problems. However, other drivers (e.g. rpmpd) might ignore the
> > > > performance state until the power domain is actually powered on.
> > > >
> > > > Since these virtual devices are managed exclusively by the OPP core,
> > > > I would say that it should also be responsible to ensure they are
> > > > enabled. A similar approach is already used for regulators, see
> > > > commit 8d45719caaf5 ("opp: core: add regulators enable and disable").
> > > >
> > > > This commit implements similar functionality for the virtual genpd
> > > > devices managed by the OPP core. The power domains are turned on
> > > > the first time dev_pm_opp_set_rate() is called. They are turned off
> > > > again when dev_pm_opp_set_rate(dev, 0) is called.
> > > >
> > > > Signed-off-by: Stephan Gerhold
> > > > ---
> > > > Related discussion:
> > > > https://lore.kernel.org/linux-arm-msm/20200426123140.ga190...@gerhold.net/
> > > >
> > > > There would be also other ways to implement this, e.g. device links,
> > > > assuming that the device using the OPP table also makes use of runtime
> > > > PM.
> > > > My first thought was that it would be most consistent to handle this
> > > > like
> > > > regulators, bandwidth votes etc. RFC :)
> > >
> > > This stuff was done ages back and I am starting to forget almost
> > > everything now :)
> > >
> > > Ulf, why doesn't pm_runtime_get(dev) take care of enabling multiple
> > > power domain case ? RFP (request for patience) :)
> > >
> >
> > So I'm really not an expert for power domains, but here is my
> > understanding:
> >
> > We attach the power domains in dev_pm_opp_attach_genpd(opp_dev, names),
> > where opp_dev is the device the OPP table belongs to.
> >
> > To do that, the genpd core creates a set of virtual devices. These
> > virtual devices are not related to opp_dev in any way. Therefore, the
> > power domains stay off until we run pm_runtime_get(virt_dev) for each of
> > the virtual devices. (Which is what is implemented in this patch...)
>
> Just to clarify. The reason why genpd creates virtual devices isn't
> because of the opp table itself.
>
> Instead this is because we can only attach one PM domain per device.
> And since a device may have multiple PM domains, we need to create a
> virtual device and per PM domain and attach that instead. Then it's up
> to the caller to manage the virtual devices.
>
> In some cases where the PM domains can be managed together, a device
> link makes sense - while in others it doesn't.
>
> >
> > If I understand correctly, what you would like to do is to have a single
> > pm_runtime_get(opp_dev) call also enable all the virtual devices?
> >
> > As far as I understand, this can be done by adding "device links"
> > between opp_dev and the virtual devices, e.g.
> >
> > device_link_add(opp_dev, virt_dev, DL_FLAG_PM_RUNTIME);
> >
> > for each of the virtual devices.
>
> Yep.
>
> >
> > But the problem with that approach is that it assumes that someone
> > actually calls pm_runtime_get(opp_dev), i.e. we assume that opp_dev is
> > managed by runtime PM. As far as I know, this isn't the case for the CPU
> > OPP table for example.
> >
> > Maybe Ulf can correct me if I'm wrong :)
>
> If I understand correctly, the opp_dev is the actual consumer device.
> I
Re: [RFC PATCH 1/3] opp: Reduce code duplication in _set_required_opps()
On Mon, Aug 24, 2020 at 05:40:04PM +0530, Viresh Kumar wrote: > On 24-08-20, 13:30, Stephan Gerhold wrote: > > You're right. Not sure why I removed it. > > > > I suspect I had it in _set_required_opp() at some point, but I moved > > code around several times until I was happy with the result. > > > > We should just add it back. > > Should I send a v2 with it fixed or would you like to handle it? > > I have applied the first two patches to linux-next branch in my tree, > please have a look. > Looks good to me. Thank you! Stephan
Re: [RFC PATCH 3/3] opp: Power on (virtual) power domains managed by the OPP core
On Mon, Aug 24, 2020 at 04:57:44PM +0530, Viresh Kumar wrote:
> On 30-07-20, 10:01, Stephan Gerhold wrote:
> > dev_pm_opp_attach_genpd() allows attaching an arbitrary number of
> > power domains to an OPP table. In that case, the genpd core will
> > create a virtual device for each of the power domains.
> >
> > At the moment, the OPP core only calls
> > dev_pm_genpd_set_performance_state() on these virtual devices.
> > It does not attempt to power on the power domains. Therefore
> > the required power domain might never get turned on.
> >
> > So far, dev_pm_opp_attach_genpd() is only used in qcom-cpufreq-nvmem.c
> > to attach the CPR power domain to the CPU OPP table. The CPR driver
> > does not check if it was actually powered on so this did not cause
> > any problems. However, other drivers (e.g. rpmpd) might ignore the
> > performance state until the power domain is actually powered on.
> >
> > Since these virtual devices are managed exclusively by the OPP core,
> > I would say that it should also be responsible to ensure they are
> > enabled. A similar approach is already used for regulators, see
> > commit 8d45719caaf5 ("opp: core: add regulators enable and disable").
> >
> > This commit implements similar functionality for the virtual genpd
> > devices managed by the OPP core. The power domains are turned on
> > the first time dev_pm_opp_set_rate() is called. They are turned off
> > again when dev_pm_opp_set_rate(dev, 0) is called.
> >
> > Signed-off-by: Stephan Gerhold
> > ---
> > Related discussion:
> > https://lore.kernel.org/linux-arm-msm/20200426123140.ga190...@gerhold.net/
> >
> > There would be also other ways to implement this, e.g. device links,
> > assuming that the device using the OPP table also makes use of runtime PM.
> > My first thought was that it would be most consistent to handle this like
> > regulators, bandwidth votes etc. RFC :)
>
> This stuff was done ages back and I am starting to forget almost
> everything now :)
>
> Ulf, why doesn't pm_runtime_get(dev) take care of enabling multiple
> power domain case ? RFP (request for patience) :)
>
So I'm really not an expert for power domains, but here is my
understanding:
We attach the power domains in dev_pm_opp_attach_genpd(opp_dev, names),
where opp_dev is the device the OPP table belongs to.
To do that, the genpd core creates a set of virtual devices. These
virtual devices are not related to opp_dev in any way. Therefore, the
power domains stay off until we run pm_runtime_get(virt_dev) for each of
the virtual devices. (Which is what is implemented in this patch...)
If I understand correctly, what you would like to do is to have a single
pm_runtime_get(opp_dev) call also enable all the virtual devices?
As far as I understand, this can be done by adding "device links"
between opp_dev and the virtual devices, e.g.
device_link_add(opp_dev, virt_dev, DL_FLAG_PM_RUNTIME);
for each of the virtual devices.
But the problem with that approach is that it assumes that someone
actually calls pm_runtime_get(opp_dev), i.e. we assume that opp_dev is
managed by runtime PM. As far as I know, this isn't the case for the CPU
OPP table for example.
Maybe Ulf can correct me if I'm wrong :)
Thanks!
Stephan
Re: [RFC PATCH 2/3] opp: Set required OPPs in reverse order when scaling down
On Mon, Aug 24, 2020 at 05:00:27PM +0530, Viresh Kumar wrote: > On 21-08-20, 18:31, Stephan Gerhold wrote: > > This patch does not apply anymore after the cleanup you pushed to > > opp/linux-next. I would be happy to send a v2 with that fixed. > > > > On my other OPP patch set you mentioned that you might apply these > > directly with some of your own changes - would you also prefer to do it > > yourself in this case or should I send a v2? > > I will pick the first 2 myself, that's fine. Lets see where we go with > the third one :) > OK, please ignore my question in my reply to PATCH 1/3 then. I replied before I read this one. Just add back the NULL checks and it should be fine :) > > Still looking for your feedback on both patch sets by the way! :) > > Sorry about the delay, I was on vacation for over a week in between and > this and the other patchset was a bit tricky (which you may have not > realized, not sure, as I wondered if something will not work within > the OPP core for v1 binding, but it did finally I believe) :) > No problem! I guess I did indeed not realize potential problems for the v1 bindings, all this compatibility code is quite confusing. :) Thanks! Stephan
Re: [PATCH V2 1/2] opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER
On Mon, Aug 24, 2020 at 02:39:32PM +0530, Viresh Kumar wrote:
> From: Stephan Gerhold
>
> The OPP core manages various resources, e.g. clocks or interconnect paths.
> These resources are looked up when the OPP table is allocated once
> dev_pm_opp_get_opp_table() is called the first time (either directly
> or indirectly through one of the many helper functions).
>
> At this point, the resources may not be available yet, i.e. looking them
> up will result in -EPROBE_DEFER. Unfortunately, dev_pm_opp_get_opp_table()
> is currently unable to propagate this error code since it only returns
> the allocated OPP table or NULL.
>
> This means that all consumers of the OPP core are required to make sure
> that all necessary resources are available. Usually this happens by
> requesting them, checking the result and releasing them immediately after.
>
> For example, we have added "dev_pm_opp_of_find_icc_paths(dev, NULL)" to
> several drivers now just to make sure the interconnect providers are
> ready before the OPP table is allocated. If this call is missing,
> the OPP core will only warn about this and then attempt to continue
> without interconnect. This will eventually fail horribly, e.g.:
>
> cpu cpu0: _allocate_opp_table: Error finding interconnect paths: -517
> ... later ...
> of: _read_bw: Mismatch between opp-peak-kBps and paths (1 0)
> cpu cpu0: _opp_add_static_v2: opp key field not found
> cpu cpu0: _of_add_opp_table_v2: Failed to add OPP, -22
>
> This example happens when trying to use interconnects for a CPU OPP
> table together with qcom-cpufreq-nvmem.c. qcom-cpufreq-nvmem calls
> dev_pm_opp_set_supported_hw(), which ends up allocating the OPP table
> early. To fix the problem with the current approach we would need to add
> yet another call to dev_pm_opp_of_find_icc_paths(dev, NULL).
> But actually qcom-cpufreq-nvmem.c has nothing to do with interconnects...
>
> This commit attempts to make this more robust by allowing
> dev_pm_opp_get_opp_table() to return an error pointer. Fixing all
> the usages is trivial because the function is usually used indirectly
> through another helper (e.g. dev_pm_opp_set_supported_hw() above).
> These other helpers already return an error pointer.
>
> The example above then works correctly because set_supported_hw() will
> return -EPROBE_DEFER, and qcom-cpufreq-nvmem.c already propagates that
> error. It should also be possible to remove the remaining usages of
> "dev_pm_opp_of_find_icc_paths(dev, NULL)" from other drivers as well.
>
> Note that this commit currently only handles -EPROBE_DEFER for the
> clock/interconnects within _allocate_opp_table(). Other errors are just
> ignored as before. Eventually those should be propagated as well.
>
> Signed-off-by: Stephan Gerhold
> [ Viresh: skip checking return value of dev_pm_opp_get_opp_table() for
> EPROBE_DEFER in domain.c, fix NULL return value and reorder
> code a bit in core.c, and update exynos-asv.c ]
> Signed-off-by: Viresh Kumar
> ---
> Stephan, I have made some changes to the code. Please try it again and
> lemme know if it works fine.
>
I tested the problem I described in the commit message above
(qcom-cpufreq-nvmem with interconnects) and it works fine
with this patch.
I also tested probe deferal with interconnects with just cpufreq-dt
(second patch), and that works fine as well.
And the changes look good to me too. :)
Thank you!
Stephan
> drivers/base/power/domain.c | 14 +
> drivers/opp/core.c | 53 +++-
> drivers/opp/of.c | 8 ++---
> drivers/soc/samsung/exynos-asv.c | 2 +-
> 4 files changed, 44 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 2cb5e04cf86c..b92bb61550d3 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2044,8 +2044,9 @@ int of_genpd_add_provider_simple(struct device_node *np,
> if (genpd->set_performance_state) {
> ret = dev_pm_opp_of_add_table(>dev);
> if (ret) {
> - dev_err(>dev, "Failed to add OPP table: %d\n",
> - ret);
> + if (ret != -EPROBE_DEFER)
> + dev_err(>dev, "Failed to add OPP table:
> %d\n",
> + ret);
> goto unlock;
> }
>
> @@ -2054,7 +2055,7 @@ int of_genpd_add_provider_simple(struct device_node *np,
>* state.
>*/
> genpd->opp_table = dev_pm_opp_get_opp_table(>dev);
> - WAR
Re: [RFC PATCH 1/3] opp: Reduce code duplication in _set_required_opps()
On Mon, Aug 24, 2020 at 04:48:20PM +0530, Viresh Kumar wrote:
> On 30-07-20, 10:01, Stephan Gerhold wrote:
> > Move call to dev_pm_genpd_set_performance_state() to a separate
> > function so we can avoid duplicating the code for the single and
> > multiple genpd case.
> >
> > Signed-off-by: Stephan Gerhold
> > ---
> > drivers/opp/core.c | 40 +---
> > 1 file changed, 21 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> > index 9d7fb45b1786..f7a476b55069 100644
> > --- a/drivers/opp/core.c
> > +++ b/drivers/opp/core.c
> > @@ -781,6 +781,21 @@ static int _set_opp_custom(const struct opp_table
> > *opp_table,
> > return opp_table->set_opp(data);
> > }
> >
> > +static int _set_required_opp(struct device *dev, struct device *pd_dev,
> > +struct dev_pm_opp *opp, int i)
> > +{
> > + unsigned int pstate = likely(opp) ? opp->required_opps[i]->pstate : 0;
> > + int ret;
> > +
> > + ret = dev_pm_genpd_set_performance_state(pd_dev, pstate);
> > + if (ret) {
> > + dev_err(dev, "Failed to set performance rate of %s: %d (%d)\n",
> > + dev_name(pd_dev), pstate, ret);
> > + }
> > +
> > + return ret;
> > +}
> > +
> > /* This is only called for PM domain for now */
> > static int _set_required_opps(struct device *dev,
> > struct opp_table *opp_table,
> > @@ -788,22 +803,15 @@ static int _set_required_opps(struct device *dev,
> > {
> > struct opp_table **required_opp_tables = opp_table->required_opp_tables;
> > struct device **genpd_virt_devs = opp_table->genpd_virt_devs;
> > - unsigned int pstate;
> > + struct device *pd_dev;
> > int i, ret = 0;
> >
> > if (!required_opp_tables)
> > return 0;
> >
> > /* Single genpd case */
> > - if (!genpd_virt_devs) {
> > - pstate = likely(opp) ? opp->required_opps[0]->pstate : 0;
> > - ret = dev_pm_genpd_set_performance_state(dev, pstate);
> > - if (ret) {
> > - dev_err(dev, "Failed to set performance state of %s: %d
> > (%d)\n",
> > - dev_name(dev), pstate, ret);
> > - }
> > - return ret;
> > - }
> > + if (!genpd_virt_devs)
> > + return _set_required_opp(dev, dev, opp, 0);
> >
> > /* Multiple genpd case */
> >
> > @@ -814,17 +822,11 @@ static int _set_required_opps(struct device *dev,
> > mutex_lock(_table->genpd_virt_dev_lock);
> >
> > for (i = 0; i < opp_table->required_opp_count; i++) {
> > - pstate = likely(opp) ? opp->required_opps[i]->pstate : 0;
> > -
> > - if (!genpd_virt_devs[i])
> > - continue;
>
> Don't we need this check anymore ?
>
You're right. Not sure why I removed it.
I suspect I had it in _set_required_opp() at some point, but I moved
code around several times until I was happy with the result.
We should just add it back.
Should I send a v2 with it fixed or would you like to handle it?
Thanks,
Stephan
> > + pd_dev = genpd_virt_devs[i];
> >
> > - ret = dev_pm_genpd_set_performance_state(genpd_virt_devs[i],
> > pstate);
> > - if (ret) {
> > - dev_err(dev, "Failed to set performance rate of %s: %d
> > (%d)\n",
> > - dev_name(genpd_virt_devs[i]), pstate, ret);
> > + ret = _set_required_opp(dev, pd_dev, opp, i);
> > + if (ret)
> > break;
> > - }
> > }
> > mutex_unlock(_table->genpd_virt_dev_lock);
> >
> > --
> > 2.27.0
Re: [RFC PATCH 2/3] opp: Set required OPPs in reverse order when scaling down
Hi Viresh,
On Thu, Jul 30, 2020 at 10:01:45AM +0200, Stephan Gerhold wrote:
> The OPP core already has well-defined semantics to ensure required
> OPPs/regulators are set before/after the frequency change, depending
> on if we scale up or down.
>
> Similar requirements might exist for the order of required OPPs
> when multiple power domains need to be scaled for a frequency change.
>
> For example, on Qualcomm platforms using CPR (Core Power Reduction),
> we need to scale the VDDMX and CPR power domain. When scaling up,
> MX should be scaled up before CPR. When scaling down, CPR should be
> scaled down before MX.
>
> In general, if there are multiple "required-opps" in the device tree
> I would expect that the order is either irrelevant, or there is some
> dependency between the power domains. In that case, the power domains
> should be scaled down in reverse order.
>
> This commit updates _set_required_opps() to set required OPPs in
> reverse order when scaling down.
>
> Signed-off-by: Stephan Gerhold
This patch does not apply anymore after the cleanup you pushed to
opp/linux-next. I would be happy to send a v2 with that fixed.
On my other OPP patch set you mentioned that you might apply these
directly with some of your own changes - would you also prefer to do it
yourself in this case or should I send a v2?
Still looking for your feedback on both patch sets by the way! :)
Thanks!
Stephan
> ---
> Related discussion:
> https://lore.kernel.org/linux-arm-msm/20200525194443.ga11...@flawful.org/
>
> The advantage of this approach is that the CPR driver does not need
> to bother with the VDDMX power domain at all - the requirements
> can be fully described within the device tree, see e.g. [1].
> An alternative option would be to modify the CPR driver to make these votes.
>
> [1]:
> https://lore.kernel.org/linux-arm-msm/20200507104603.ga581...@gerhold.net/2-msm8916-vdd-mx.patch
> ---
> drivers/opp/core.c | 30 +-
> 1 file changed, 21 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index f7a476b55069..f93f551c911e 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -799,7 +799,7 @@ static int _set_required_opp(struct device *dev, struct
> device *pd_dev,
> /* This is only called for PM domain for now */
> static int _set_required_opps(struct device *dev,
> struct opp_table *opp_table,
> - struct dev_pm_opp *opp)
> + struct dev_pm_opp *opp, bool up)
> {
> struct opp_table **required_opp_tables = opp_table->required_opp_tables;
> struct device **genpd_virt_devs = opp_table->genpd_virt_devs;
> @@ -821,12 +821,24 @@ static int _set_required_opps(struct device *dev,
>*/
> mutex_lock(_table->genpd_virt_dev_lock);
>
> - for (i = 0; i < opp_table->required_opp_count; i++) {
> - pd_dev = genpd_virt_devs[i];
> + if (up) {
> + /* Scaling up? Set required OPPs in normal order */
> + for (i = 0; i < opp_table->required_opp_count; i++) {
> + pd_dev = genpd_virt_devs[i];
>
> - ret = _set_required_opp(dev, pd_dev, opp, i);
> - if (ret)
> - break;
> + ret = _set_required_opp(dev, pd_dev, opp, i);
> + if (ret)
> + break;
> + }
> + } else {
> + /* Scaling down? Set required OPPs in reverse order */
> + for (i = opp_table->required_opp_count - 1; i >= 0; i--) {
> + pd_dev = genpd_virt_devs[i];
> +
> + ret = _set_required_opp(dev, pd_dev, opp, i);
> + if (ret)
> + break;
> + }
> }
> mutex_unlock(_table->genpd_virt_dev_lock);
>
> @@ -914,7 +926,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
> target_freq)
> opp_table->regulator_enabled = false;
> }
>
> - ret = _set_required_opps(dev, opp_table, NULL);
> + ret = _set_required_opps(dev, opp_table, NULL, false);
> goto put_opp_table;
> }
>
> @@ -973,7 +985,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long
> target_freq)
>
> /* Scaling up? Configure required OPPs before frequency */
> if (freq >= old_freq) {
> - ret = _set_required_opps(dev, opp_table, opp);
> + ret = _set_required_opps(dev, opp_table, opp, true);
> if (ret)
>
Re: [PATCH] ASoC: msm8916-wcd-analog: fix register Interrupt offset
On Tue, Aug 11, 2020 at 11:34:52AM +0100, Srinivas Kandagatla wrote:
> For some reason interrupt set and clear register offsets are
> not set correctly.
> This patch corrects them!
>
> Fixes: 585e881e5b9e ("ASoC: codecs: Add msm8916-wcd analog codec")
> Signed-off-by: Srinivas Kandagatla
> ---
> sound/soc/codecs/msm8916-wcd-analog.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/codecs/msm8916-wcd-analog.c
> b/sound/soc/codecs/msm8916-wcd-analog.c
> index 4428c62e25cf..3ddd822240e3 100644
> --- a/sound/soc/codecs/msm8916-wcd-analog.c
> +++ b/sound/soc/codecs/msm8916-wcd-analog.c
> @@ -19,8 +19,8 @@
>
> #define CDC_D_REVISION1 (0xf000)
> #define CDC_D_PERPH_SUBTYPE (0xf005)
> -#define CDC_D_INT_EN_SET (0x015)
> -#define CDC_D_INT_EN_CLR (0x016)
> +#define CDC_D_INT_EN_SET (0xf015)
> +#define CDC_D_INT_EN_CLR (0xf016)
> #define MBHC_SWITCH_INT BIT(7)
> #define MBHC_MIC_ELECTRICAL_INS_REM_DET BIT(6)
> #define MBHC_BUTTON_PRESS_DETBIT(5)
> --
> 2.21.0
>
It's surprising that we didn't notice this before. Seems like the HW
has exactly the IRQs we want enabled by default. Everything seems to be
still working fine after this patch, so FWIW:
Tested-by: Stephan Gerhold
Reviewed-by: Stephan Gerhold
Thanks!
Stephan
Re: [RFC PATCH 1/2] opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER
Hi Viresh, On Wed, Aug 12, 2020 at 08:31:22PM +0530, Viresh Kumar wrote: > On 12-08-20, 12:53, Stephan Gerhold wrote: > > I have another small build fix reported by the kernel test robot, > > but will wait with sending that out until Viresh had a chance to give > > some feedback on the basic idea. :) > > What was the issue that was reported ? I may end up applying V1 only > with some of my changes. > It was this build error on SH (for the second patch): >> drivers/cpufreq/cpufreq-dt.c:36:29: error: conflicting types for 'cpu_data' 36 | static struct private_data *cpu_data; | ^~~~ In file included from arch/sh/include/asm/thread_info.h:27, from include/linux/thread_info.h:38, from include/asm-generic/current.h:5, from ./arch/sh/include/generated/asm/current.h:1, from include/linux/mutex.h:14, from include/linux/notifier.h:14, from include/linux/clk.h:14, from drivers/cpufreq/cpufreq-dt.c:11: arch/sh/include/asm/processor.h:90:26: note: previous declaration of 'cpu_data' was here 90 | extern struct sh_cpuinfo cpu_data[]; | ^~~~ I fixed it by renaming "cpu_data" to "cpufreq_dt_data". (I could not think of a better name so feel free to use something else...) Thanks! Stephan
Re: [RFC PATCH 1/2] opp: Allow dev_pm_opp_get_opp_table() to return -EPROBE_DEFER
On Wed, Aug 12, 2020 at 11:10:38AM +0200, Ulf Hansson wrote: > > I wasn't sure if the changes in drivers/base/power/domain.c > > should be made in a separate commit, but they need to be made together > > with the other changes. > > I would suggest to move the changes in drivers/base/power/domain.c > into a separate patch, still part of the series, but let it preceed > $subject patch. > OK, will do that in v2 - thank you! I have another small build fix reported by the kernel test robot, but will wait with sending that out until Viresh had a chance to give some feedback on the basic idea. :) Thanks! Stephan
