* [PATCH] arm64: dts: meson: fix S4 power-controller node
From: Xianwei Zhao via B4 Relay @ 2024-04-08 3:26 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Xianwei Zhao
From: Xianwei Zhao <xianwei.zhao@amlogic.com>
The power-controller module works well by adding its parent
node secure-monitor.
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
---
arch/arm64/boot/dts/amlogic/meson-s4.dtsi | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
index ce90b35686a2..24d00dce4969 100644
--- a/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-s4.dtsi
@@ -65,10 +65,13 @@ xtal: xtal-clk {
#clock-cells = <0>;
};
- pwrc: power-controller {
- compatible = "amlogic,meson-s4-pwrc";
- #power-domain-cells = <1>;
- status = "okay";
+ sm: secure-monitor {
+ compatible = "amlogic,meson-gxbb-sm";
+
+ pwrc: power-controller {
+ compatible = "amlogic,meson-s4-pwrc";
+ #power-domain-cells = <1>;
+ };
};
soc {
---
base-commit: 4cece764965020c22cff7665b18a012006359095
change-id: 20240408-fix-secpwr-s4-a99ff960d0ae
Best regards,
--
Xianwei Zhao <xianwei.zhao@amlogic.com>
^ permalink raw reply related
* [PATCH v3 0/2] Add support for QCM6490 and QCS6490
From: Mohammad Rafi Shaik @ 2024-04-08 4:08 UTC (permalink / raw)
To: Srinivas Kandagatla, Banajit Goswami, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai
Cc: linux-arm-msm, alsa-devel, linux-sound, devicetree, linux-kernel,
quic_rohkumar, Mohammad Rafi Shaik
This patchset adds support for sound card on Qualcomm QCM6490 IDP and
QCS6490 RB3Gen2 boards.
Changes since v2:
- Modify qcm6490 compatible name as qcs6490-idp. Suggested by Dmitry
Changes since v1:
- Use existing sc8280xp machine driver instead of separate driver.
- Modify qcs6490 compatible name as qcs6490-rb3gen2.
Mohammad Rafi Shaik (2):
ASoC: dt-bindings: qcom,sm8250: Add QCM6490 snd QCS6490 sound card
ASoC: qcom: sc8280xp: Add support for QCM6490 and QCS6490
Documentation/devicetree/bindings/sound/qcom,sm8250.yaml | 2 ++
sound/soc/qcom/sc8280xp.c | 2 ++
2 files changed, 4 insertions(+)
--
2.25.1
^ permalink raw reply
* [PATCH v3 1/2] ASoC: dt-bindings: qcom,sm8250: Add QCM6490 snd QCS6490 sound card
From: Mohammad Rafi Shaik @ 2024-04-08 4:08 UTC (permalink / raw)
To: Srinivas Kandagatla, Banajit Goswami, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai
Cc: linux-arm-msm, alsa-devel, linux-sound, devicetree, linux-kernel,
quic_rohkumar, Mohammad Rafi Shaik
In-Reply-To: <20240408040816.400530-1-quic_mohs@quicinc.com>
Document the bindings for the Qualcomm QCM6490 IDP and QCS6490 RB3Gen2
board specific sound card.
The bindings are the same as for other newer Qualcomm ADSP sound cards,
thus keep them in existing qcom,sm8250.yaml file, even though Linux driver
is separate.
Signed-off-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com>
---
Documentation/devicetree/bindings/sound/qcom,sm8250.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
index 2ab6871e89e5..b2e15ebbd1bc 100644
--- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
@@ -29,6 +29,8 @@ properties:
- enum:
- qcom,apq8016-sbc-sndcard
- qcom,msm8916-qdsp6-sndcard
+ - qcom,qcm6490-idp-sndcard
+ - qcom,qcs6490-rb3gen2-sndcard
- qcom,qrb5165-rb5-sndcard
- qcom,sc7180-qdsp6-sndcard
- qcom,sc8280xp-sndcard
--
2.25.1
^ permalink raw reply related
* [PATCH v3 2/2] ASoC: qcom: sc8280xp: Add support for QCM6490 and QCS6490
From: Mohammad Rafi Shaik @ 2024-04-08 4:08 UTC (permalink / raw)
To: Srinivas Kandagatla, Banajit Goswami, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai
Cc: linux-arm-msm, alsa-devel, linux-sound, devicetree, linux-kernel,
quic_rohkumar, Mohammad Rafi Shaik
In-Reply-To: <20240408040816.400530-1-quic_mohs@quicinc.com>
Add compatibles for sound card on Qualcomm QCM6490 IDP and
QCS6490 RB3Gen2 boards.
Signed-off-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com>
---
sound/soc/qcom/sc8280xp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/qcom/sc8280xp.c b/sound/soc/qcom/sc8280xp.c
index b7fd503a1666..878bd50ad4a7 100644
--- a/sound/soc/qcom/sc8280xp.c
+++ b/sound/soc/qcom/sc8280xp.c
@@ -169,6 +169,8 @@ static int sc8280xp_platform_probe(struct platform_device *pdev)
}
static const struct of_device_id snd_sc8280xp_dt_match[] = {
+ {.compatible = "qcom,qcm6490-idp-sndcard", "qcm6490"},
+ {.compatible = "qcom,qcs6490-rb3gen2-sndcard", "qcs6490"},
{.compatible = "qcom,sc8280xp-sndcard", "sc8280xp"},
{.compatible = "qcom,sm8450-sndcard", "sm8450"},
{.compatible = "qcom,sm8550-sndcard", "sm8550"},
--
2.25.1
^ permalink raw reply related
* [RESEND v3 0/2] Add support for QCM6490 and QCS6490
From: Mohammad Rafi Shaik @ 2024-04-08 4:23 UTC (permalink / raw)
To: Srinivas Kandagatla, Banajit Goswami, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai
Cc: linux-arm-msm, alsa-devel, linux-sound, devicetree, linux-kernel,
quic_rohkumar, Mohammad Rafi Shaik
This patchset adds support for sound card on Qualcomm QCM6490 IDP and
QCS6490 RB3Gen2 boards.
Changes since v2:
- Modify qcm6490 compatible name as qcm6490-idp. Suggested by Dmitry
Changes since v1:
- Use existing sc8280xp machine driver instead of separate driver.
- Modify qcs6490 compatible name as qcs6490-rb3gen2.
Mohammad Rafi Shaik (2):
ASoC: dt-bindings: qcom,sm8250: Add QCM6490 snd QCS6490 sound card
ASoC: qcom: sc8280xp: Add support for QCM6490 and QCS6490
Documentation/devicetree/bindings/sound/qcom,sm8250.yaml | 2 ++
sound/soc/qcom/sc8280xp.c | 2 ++
2 files changed, 4 insertions(+)
--
2.25.1
^ permalink raw reply
* [RESEND v3 1/2] ASoC: dt-bindings: qcom,sm8250: Add QCM6490 snd QCS6490 sound card
From: Mohammad Rafi Shaik @ 2024-04-08 4:23 UTC (permalink / raw)
To: Srinivas Kandagatla, Banajit Goswami, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai
Cc: linux-arm-msm, alsa-devel, linux-sound, devicetree, linux-kernel,
quic_rohkumar, Mohammad Rafi Shaik
In-Reply-To: <20240408042331.403103-1-quic_mohs@quicinc.com>
Document the bindings for the Qualcomm QCM6490 IDP and QCS6490 RB3Gen2
board specific sound card.
The bindings are the same as for other newer Qualcomm ADSP sound cards,
thus keep them in existing qcom,sm8250.yaml file, even though Linux driver
is separate.
Signed-off-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com>
---
Documentation/devicetree/bindings/sound/qcom,sm8250.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
index 2ab6871e89e5..b2e15ebbd1bc 100644
--- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml
@@ -29,6 +29,8 @@ properties:
- enum:
- qcom,apq8016-sbc-sndcard
- qcom,msm8916-qdsp6-sndcard
+ - qcom,qcm6490-idp-sndcard
+ - qcom,qcs6490-rb3gen2-sndcard
- qcom,qrb5165-rb5-sndcard
- qcom,sc7180-qdsp6-sndcard
- qcom,sc8280xp-sndcard
--
2.25.1
^ permalink raw reply related
* [RESEND v3 2/2] ASoC: qcom: sc8280xp: Add support for QCM6490 and QCS6490
From: Mohammad Rafi Shaik @ 2024-04-08 4:23 UTC (permalink / raw)
To: Srinivas Kandagatla, Banajit Goswami, Liam Girdwood, Mark Brown,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela,
Takashi Iwai
Cc: linux-arm-msm, alsa-devel, linux-sound, devicetree, linux-kernel,
quic_rohkumar, Mohammad Rafi Shaik
In-Reply-To: <20240408042331.403103-1-quic_mohs@quicinc.com>
Add compatibles for sound card on Qualcomm QCM6490 IDP and
QCS6490 RB3Gen2 boards.
Signed-off-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com>
---
sound/soc/qcom/sc8280xp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/soc/qcom/sc8280xp.c b/sound/soc/qcom/sc8280xp.c
index b7fd503a1666..878bd50ad4a7 100644
--- a/sound/soc/qcom/sc8280xp.c
+++ b/sound/soc/qcom/sc8280xp.c
@@ -169,6 +169,8 @@ static int sc8280xp_platform_probe(struct platform_device *pdev)
}
static const struct of_device_id snd_sc8280xp_dt_match[] = {
+ {.compatible = "qcom,qcm6490-idp-sndcard", "qcm6490"},
+ {.compatible = "qcom,qcs6490-rb3gen2-sndcard", "qcs6490"},
{.compatible = "qcom,sc8280xp-sndcard", "sc8280xp"},
{.compatible = "qcom,sm8450-sndcard", "sm8450"},
{.compatible = "qcom,sm8550-sndcard", "sm8550"},
--
2.25.1
^ permalink raw reply related
* [PATCH] ASoC: dt-bindings: imx-audio-spdif: convert to YAML
From: Shengjiu Wang @ 2024-04-08 4:55 UTC (permalink / raw)
To: lgirdwood, broonie, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shengjiu.wang, linux-sound, devicetree, linux-kernel, shawnguo,
s.hauer, kernel, festevam, imx, linux-arm-kernel
Convert the imx-audio-spdif binding to YAML.
When testing dtbs_check, found below compatible strings
are not listed in document:
fsl,imx-sabreauto-spdif
fsl,imx6sx-sdb-spdif
So add them in yaml file to pass the test.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
.../bindings/sound/imx-audio-spdif.txt | 36 -----------
.../bindings/sound/imx-audio-spdif.yaml | 62 +++++++++++++++++++
2 files changed, 62 insertions(+), 36 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.yaml
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt b/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
deleted file mode 100644
index da84a442ccea..000000000000
--- a/Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-Freescale i.MX audio complex with S/PDIF transceiver
-
-Required properties:
-
- - compatible : "fsl,imx-audio-spdif"
-
- - model : The user-visible name of this sound complex
-
- - spdif-controller : The phandle of the i.MX S/PDIF controller
-
-
-Optional properties:
-
- - spdif-out : This is a boolean property. If present, the
- transmitting function of S/PDIF will be enabled,
- indicating there's a physical S/PDIF out connector
- or jack on the board or it's connecting to some
- other IP block, such as an HDMI encoder or
- display-controller.
-
- - spdif-in : This is a boolean property. If present, the receiving
- function of S/PDIF will be enabled, indicating there
- is a physical S/PDIF in connector/jack on the board.
-
-* Note: At least one of these two properties should be set in the DT binding.
-
-
-Example:
-
-sound-spdif {
- compatible = "fsl,imx-audio-spdif";
- model = "imx-spdif";
- spdif-controller = <&spdif>;
- spdif-out;
- spdif-in;
-};
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-spdif.yaml b/Documentation/devicetree/bindings/sound/imx-audio-spdif.yaml
new file mode 100644
index 000000000000..b29e024f553f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/imx-audio-spdif.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/imx-audio-spdif.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale i.MX audio complex with S/PDIF transceiver
+
+maintainers:
+ - Shengjiu Wang <shengjiu.wang@nxp.com>
+
+properties:
+ compatible:
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx-audio-spdif
+ - enum:
+ - fsl,imx-sabreauto-spdif
+ - fsl,imx6sx-sdb-spdif
+ - items:
+ - enum:
+ - fsl,imx-audio-spdif
+
+ model:
+ $ref: /schemas/types.yaml#/definitions/string
+ description: User specified audio sound card name
+
+ spdif-controller:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the i.MX S/PDIF controller
+
+ spdif-out:
+ type: boolean
+ description: |
+ If present, the transmitting function of S/PDIF will be enabled,
+ indicating there's a physical S/PDIF out connector or jack on the
+ board or it's connecting to some other IP block, such as an HDMI
+ encoder or display-controller.
+
+ spdif-in:
+ type: boolean
+ description: |
+ If present, the receiving function of S/PDIF will be enabled,
+ indicating there is a physical S/PDIF in connector/jack on the board.
+
+required:
+ - compatible
+ - model
+ - spdif-controller
+
+additionalProperties: false
+
+examples:
+ - |
+ sound-spdif {
+ compatible = "fsl,imx-audio-spdif";
+ model = "imx-spdif";
+ spdif-controller = <&spdif>;
+ spdif-out;
+ spdif-in;
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] ASoC: dt-bindings: imx-audio-spdif: convert to YAML
From: Krzysztof Kozlowski @ 2024-04-08 5:48 UTC (permalink / raw)
To: Shengjiu Wang, lgirdwood, broonie, robh+dt,
krzysztof.kozlowski+dt, conor+dt, shengjiu.wang, linux-sound,
devicetree, linux-kernel, shawnguo, s.hauer, kernel, festevam,
imx, linux-arm-kernel
In-Reply-To: <1712552142-27055-1-git-send-email-shengjiu.wang@nxp.com>
On 08/04/2024 06:55, Shengjiu Wang wrote:
> Convert the imx-audio-spdif binding to YAML.
>
> When testing dtbs_check, found below compatible strings
> are not listed in document:
>
> fsl,imx-sabreauto-spdif
> fsl,imx6sx-sdb-spdif
>
> So add them in yaml file to pass the test.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> .../bindings/sound/imx-audio-spdif.txt | 36 -----------
> .../bindings/sound/imx-audio-spdif.yaml | 62 +++++++++++++++++++
Filename like compatible.
> 2 files changed, 62 insertions(+), 36 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.txt
> create mode 100644 Documentation/devicetree/bindings/sound/imx-audio-spdif.yaml
>
...
> +$id: http://devicetree.org/schemas/sound/imx-audio-spdif.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale i.MX audio complex with S/PDIF transceiver
> +
> +maintainers:
> + - Shengjiu Wang <shengjiu.wang@nxp.com>
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - fsl,imx-audio-spdif
> + - enum:
> + - fsl,imx-sabreauto-spdif
> + - fsl,imx6sx-sdb-spdif
> + - items:
No need for items here.
> + - enum:
> + - fsl,imx-audio-spdif
> +
> + model:
> + $ref: /schemas/types.yaml#/definitions/string
> + description: User specified audio sound card name
> +
> + spdif-controller:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: The phandle of the i.MX S/PDIF controller
> +
> + spdif-out:
> + type: boolean
> + description: |
Do not need '|' unless you need to preserve formatting.
> + If present, the transmitting function of S/PDIF will be enabled,
> + indicating there's a physical S/PDIF out connector or jack on the
> + board or it's connecting to some other IP block, such as an HDMI
> + encoder or display-controller.
> +
> + spdif-in:
> + type: boolean
> + description: |
Do not need '|' unless you need to preserve formatting.
> + If present, the receiving function of S/PDIF will be enabled,
> + indicating there is a physical S/PDIF in connector/jack on the board.
> +
> +required:
> + - compatible
> + - model
> + - spdif-controller
> +
spdif-out and/or spdif-in are required. You either miss oneOf: required:
or anyOf:
https://elixir.bootlin.com/linux/v6.8-rc4/source/Documentation/devicetree/bindings/connector/usb-connector.yaml#L305
https://elixir.bootlin.com/linux/v5.17-rc2/source/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml#L91
Judging by example, the first one.
> +additionalProperties: false
> +
> +examples:
> + - |
> + sound-spdif {
spdif {
> + compatible = "fsl,imx-audio-spdif";
> + model = "imx-spdif";
> + spdif-controller = <&spdif>;
> + spdif-out;
> + spdif-in;
> + };
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v1] rtc: pcf2127: configurable power management function
From: Markus Burri @ 2024-04-08 5:49 UTC (permalink / raw)
To: linux-kernel
Cc: Markus Burri, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-rtc, devicetree
In the PCF2131 power management the battery switch-over function is
disabled by default.
After a power cycle the rtc clock is wrong because of that.
Add a device-tree property to configure the power management function
and enable battery switch-over.
Signed-off-by: Markus Burri <markus.burri@mt.com>
---
.../devicetree/bindings/rtc/nxp,pcf2127.yaml | 3 +++
drivers/rtc/rtc-pcf2127.c | 22 +++++++++++++++++++
2 files changed, 25 insertions(+)
diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
index 2d9fe5a75b06..5ce0ca6dcedc 100644
--- a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
+++ b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
@@ -30,6 +30,9 @@ properties:
reset-source: true
+ pwrmng-function:
+ description: Set power management function for PCF2131
+
required:
- compatible
- reg
diff --git a/drivers/rtc/rtc-pcf2127.c b/drivers/rtc/rtc-pcf2127.c
index 9c04c4e1a49c..30d56538c11e 100644
--- a/drivers/rtc/rtc-pcf2127.c
+++ b/drivers/rtc/rtc-pcf2127.c
@@ -48,6 +48,7 @@
#define PCF2127_BIT_CTRL3_BLF BIT(2)
#define PCF2127_BIT_CTRL3_BF BIT(3)
#define PCF2127_BIT_CTRL3_BTSE BIT(4)
+#define PCF2131_BIT_CTRL3_PWRMNG_MASK GENMASK(7, 5)
/* Time and date registers */
#define PCF2127_REG_TIME_BASE 0x03
#define PCF2127_BIT_SC_OSF BIT(7)
@@ -187,6 +188,7 @@ struct pcf21xx_config {
unsigned int has_bit_wd_ctl_cd0:1;
unsigned int wd_val_reg_readable:1; /* If watchdog value register can be read. */
unsigned int has_int_a_b:1; /* PCF2131 supports two interrupt outputs. */
+ unsigned int has_pwrmng:1; /* PCF2131 supports power management. */
u8 reg_time_base; /* Time/date base register. */
u8 regs_alarm_base; /* Alarm function base registers. */
u8 reg_wd_ctl; /* Watchdog control register. */
@@ -926,6 +928,7 @@ static struct pcf21xx_config pcf21xx_cfg[] = {
.has_bit_wd_ctl_cd0 = 1,
.wd_val_reg_readable = 1,
.has_int_a_b = 0,
+ .has_pwrmng = 0,
.reg_time_base = PCF2127_REG_TIME_BASE,
.regs_alarm_base = PCF2127_REG_ALARM_BASE,
.reg_wd_ctl = PCF2127_REG_WD_CTL,
@@ -954,6 +957,7 @@ static struct pcf21xx_config pcf21xx_cfg[] = {
.has_bit_wd_ctl_cd0 = 0,
.wd_val_reg_readable = 1,
.has_int_a_b = 0,
+ .has_pwrmng = 0,
.reg_time_base = PCF2127_REG_TIME_BASE,
.regs_alarm_base = PCF2127_REG_ALARM_BASE,
.reg_wd_ctl = PCF2127_REG_WD_CTL,
@@ -982,6 +986,7 @@ static struct pcf21xx_config pcf21xx_cfg[] = {
.has_bit_wd_ctl_cd0 = 0,
.wd_val_reg_readable = 0,
.has_int_a_b = 1,
+ .has_pwrmng = 1,
.reg_time_base = PCF2131_REG_TIME_BASE,
.regs_alarm_base = PCF2131_REG_ALARM_BASE,
.reg_wd_ctl = PCF2131_REG_WD_CTL,
@@ -1241,6 +1246,23 @@ static int pcf2127_probe(struct device *dev, struct regmap *regmap,
return ret;
}
+ if (pcf2127->cfg->has_pwrmng) {
+ uint32_t pwrmng;
+ if (!device_property_read_u32(dev, "pwrmng-function", &pwrmng)) {
+ if (!FIELD_FIT(PCF2131_BIT_CTRL3_PWRMNG_MASK, pwrmng)) {
+ dev_err(dev, "invalid power management function\n");
+ return ret;
+ }
+ ret = regmap_update_bits(pcf2127->regmap, PCF2127_REG_CTRL3,
+ PCF2131_BIT_CTRL3_PWRMNG_MASK,
+ FIELD_PREP(PCF2131_BIT_CTRL3_PWRMNG_MASK, pwrmng));
+ if (ret) {
+ dev_err(dev, "%s: pwrmng (ctrl3) failed\n", __func__);
+ return ret;
+ }
+ }
+ }
+
/*
* Enable timestamp functions 1 to 4.
*/
--
2.39.2
^ permalink raw reply related
* Re: [PATCH v1] rtc: pcf2127: configurable power management function
From: Krzysztof Kozlowski @ 2024-04-08 5:55 UTC (permalink / raw)
To: Markus Burri, linux-kernel
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-rtc, devicetree
In-Reply-To: <20240408054926.3994-1-markus.burri@mt.com>
On 08/04/2024 07:49, Markus Burri wrote:
> In the PCF2131 power management the battery switch-over function is
> disabled by default.
> After a power cycle the rtc clock is wrong because of that.
> Add a device-tree property to configure the power management function
> and enable battery switch-over.
>
> Signed-off-by: Markus Burri <markus.burri@mt.com>
> ---
> .../devicetree/bindings/rtc/nxp,pcf2127.yaml | 3 +++
> drivers/rtc/rtc-pcf2127.c | 22 +++++++++++++++++++
Please run scripts/checkpatch.pl and fix reported warnings. Then please
run `scripts/checkpatch.pl --strict` and (probably) fix more warnings.
Some warnings can be ignored, especially from --strict run, but the code
here looks like it needs a fix. Feel free to get in touch if the warning
is not clear.
> 2 files changed, 25 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
> index 2d9fe5a75b06..5ce0ca6dcedc 100644
> --- a/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
> +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf2127.yaml
> @@ -30,6 +30,9 @@ properties:
>
> reset-source: true
>
> + pwrmng-function:
> + description: Set power management function for PCF2131
It does not look like you tested the bindings, at least after quick
look. Please run `make dt_binding_check` (see
Documentation/devicetree/bindings/writing-schema.rst for instructions).
Maybe you need to update your dtschema and yamllint.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RESEND v3 0/2] Add support for QCM6490 and QCS6490
From: Krzysztof Kozlowski @ 2024-04-08 5:56 UTC (permalink / raw)
To: Mohammad Rafi Shaik, Srinivas Kandagatla, Banajit Goswami,
Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jaroslav Kysela, Takashi Iwai
Cc: linux-arm-msm, alsa-devel, linux-sound, devicetree, linux-kernel,
quic_rohkumar
In-Reply-To: <20240408042331.403103-1-quic_mohs@quicinc.com>
On 08/04/2024 06:23, Mohammad Rafi Shaik wrote:
> This patchset adds support for sound card on Qualcomm QCM6490 IDP and
> QCS6490 RB3Gen2 boards.
>
> Changes since v2:
> - Modify qcm6490 compatible name as qcm6490-idp. Suggested by Dmitry
>
> Changes since v1:
> - Use existing sc8280xp machine driver instead of separate driver.
> - Modify qcs6490 compatible name as qcs6490-rb3gen2.
>
Why are you resending 15 minutes after previous round?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RESEND v3 1/2] ASoC: dt-bindings: qcom,sm8250: Add QCM6490 snd QCS6490 sound card
From: Krzysztof Kozlowski @ 2024-04-08 5:56 UTC (permalink / raw)
To: Mohammad Rafi Shaik, Srinivas Kandagatla, Banajit Goswami,
Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jaroslav Kysela, Takashi Iwai
Cc: linux-arm-msm, alsa-devel, linux-sound, devicetree, linux-kernel,
quic_rohkumar
In-Reply-To: <20240408042331.403103-2-quic_mohs@quicinc.com>
On 08/04/2024 06:23, Mohammad Rafi Shaik wrote:
> Document the bindings for the Qualcomm QCM6490 IDP and QCS6490 RB3Gen2
> board specific sound card.
>
> The bindings are the same as for other newer Qualcomm ADSP sound cards,
> thus keep them in existing qcom,sm8250.yaml file, even though Linux driver
> is separate.
>
> Signed-off-by: Mohammad Rafi Shaik <quic_mohs@quicinc.com>
> ---
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set additionalProperties to true
From: Krzysztof Kozlowski @ 2024-04-08 5:57 UTC (permalink / raw)
To: Peng Fan, Peng Fan (OSS), Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Sudeep Holla, Cristian Marussi
Cc: devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DU0PR04MB9417839C42681F57366003EF88012@DU0PR04MB9417.eurprd04.prod.outlook.com>
On 08/04/2024 01:50, Peng Fan wrote:
>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>> additionalProperties to true
>>
>> On 07/04/2024 12:04, Peng Fan wrote:
>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>>>> additionalProperties to true
>>>>
>>>> On 07/04/2024 02:37, Peng Fan wrote:
>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>>>>>> additionalProperties to true
>>>>>>
>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
>>>>>>> From: Peng Fan <peng.fan@nxp.com>
>>>>>>>
>>>>>>> When adding vendor extension protocols, there is dt-schema warning:
>>>>>>> "
>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do not
>>>>>>> match any of the regexes: 'pinctrl-[0-9]+'
>>>>>>> "
>>>>>>>
>>>>>>> Set additionalProperties to true to address the issue.
>>>>>>
>>>>>> I do not see anything addressed here, except making the binding
>>>>>> accepting anything anywhere...
>>>>>
>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will introduce
>>>>> a new yaml imx.scmi.yaml which add i.MX SCMI protocol extension.
>>>>>
>>>>> With additionalProperties set to false, I not know how, please suggest.
>>>>
>>>> First of all, you cannot affect negatively existing devices (their
>>>> bindings) and your patch does exactly that. This should make you
>>>> thing what is the correct approach...
>>>>
>>>> Rob gave you the comment about missing compatible - you still did not
>>>> address that.
>>>
>>> I added the compatible in patch 2/6 in the examples "compatible =
>> "arm,scmi";"
>>
>> So you claim that your vendor extensions are the same or fully compatible
>> with arm,scmi and you add nothing... Are your extensions/protocol valid for
>> arm,scmi?
>
> Yes. They are valid for arm,scmi.
>
> If yes, why is this in separate binding. If no, why you use someone
>> else's compatible?
>
> Per SCMI Spec
> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> this interface
>
> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use
> the id for their own protocol.
So how are they valid for arm,scmi? I don't understand.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: remoteproc: qcom,qcs404-cdsp-pil: Fix qcom,halt-regs definition
From: Krzysztof Kozlowski @ 2024-04-08 5:58 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel,
Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20240407-qcom-halt-regs-fixup-v1-1-a0ea4e2c178e@z3ntu.xyz>
On 07/04/2024 11:58, Luca Weiss wrote:
> Set the 'items' correctly for the qcom,halt-regs property and update the
> description to match what it should be.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> ---
> .../devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: remoteproc: qcom,sc7280-wpss-pil: Fix qcom,halt-regs definition
From: Krzysztof Kozlowski @ 2024-04-08 5:59 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel,
Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20240407-qcom-halt-regs-fixup-v1-2-a0ea4e2c178e@z3ntu.xyz>
On 07/04/2024 11:58, Luca Weiss wrote:
> Set the 'items' correctly for the qcom,halt-regs property and update the
> description to match what it should be.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> ---
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: remoteproc: qcom,sdm845-adsp-pil: Fix qcom,halt-regs definition
From: Krzysztof Kozlowski @ 2024-04-08 6:00 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel,
Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-remoteproc, devicetree, linux-kernel
In-Reply-To: <20240407-qcom-halt-regs-fixup-v1-3-a0ea4e2c178e@z3ntu.xyz>
On 07/04/2024 11:58, Luca Weiss wrote:
> Set the 'items' correctly for the qcom,halt-regs property and update the
> description to match what it should be.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> ---
> .../devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v9 1/7] dt-bindings: spmi: Add X1E80100 SPMI PMIC ARB schema
From: Abel Vesa @ 2024-04-08 6:04 UTC (permalink / raw)
To: Bjorn Andersson, Krzysztof Kozlowski
Cc: Stephen Boyd, Matthias Brugger, Konrad Dybcio, Dmitry Baryshkov,
Neil Armstrong, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Srini Kandagatla, Johan Hovold,
David Collins, linux-kernel, linux-arm-kernel, linux-arm-msm,
linux-mediatek, devicetree, Krzysztof Kozlowski
In-Reply-To: <fkwugrnak3fhkg5ig47kmy3edm45ut4dprkabntnwemjt3w2mb@7cak5zxwzw4p>
On 24-04-07 19:07:03, Bjorn Andersson wrote:
> On Sun, Apr 07, 2024 at 07:23:21PM +0300, Abel Vesa wrote:
> > Add dedicated schema for X1E80100 PMIC ARB (v7) as it allows multiple
> > buses by declaring them as child nodes.
> >
>
> But is this really a "dedicated schema for X1E80100"? Isn't it "the
> schema for all multi-bus controllers"?
>
> I.e. isn't this a "dedicated schema for all platforms starting with
> SM8450"?
Suggestion was from Krzysztof to add platform specific comaptible (and
therefore schema). Since the first platform that will support in
upstream proper multi bus is the x1e80100, the schema needs to bear the
same name as the compatible. When support for multi bus will be added to
the other platforms (including the SM8450), they will use the fallback
compatible of the x1e80100 and will be documented in this newly added
schema. We did the same thing with some PHYs drivers, IIRC.
>
> Can you please use the commit message to document the actual reason why
> you choose to create a dedicated schema for this? Is it simply to avoid
> having to schema with either pmics or multiple buses as children?
I can re-send the patchset with such a phrase in commit message.
One of the early versions of this patchset was actually submitting a
generic compatible for multi bus, but I remember that there was a
request for following the platform dedicated approach.
Krzysztof, can you please provide here the argument for why that is
preferred?
>
> Regards,
> Bjorn
^ permalink raw reply
* RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set additionalProperties to true
From: Peng Fan @ 2024-04-08 6:08 UTC (permalink / raw)
To: Krzysztof Kozlowski, Peng Fan (OSS), Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Sudeep Holla,
Cristian Marussi
Cc: devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <ba4c9f20-0391-4ac2-a236-d6930285cd7e@kernel.org>
> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> additionalProperties to true
>
> On 08/04/2024 01:50, Peng Fan wrote:
> >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >> additionalProperties to true
> >>
> >> On 07/04/2024 12:04, Peng Fan wrote:
> >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >>>> additionalProperties to true
> >>>>
> >>>> On 07/04/2024 02:37, Peng Fan wrote:
> >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> >>>>>> additionalProperties to true
> >>>>>>
> >>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> >>>>>>> From: Peng Fan <peng.fan@nxp.com>
> >>>>>>>
> >>>>>>> When adding vendor extension protocols, there is dt-schema
> warning:
> >>>>>>> "
> >>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do not
> >>>>>>> match any of the regexes: 'pinctrl-[0-9]+'
> >>>>>>> "
> >>>>>>>
> >>>>>>> Set additionalProperties to true to address the issue.
> >>>>>>
> >>>>>> I do not see anything addressed here, except making the binding
> >>>>>> accepting anything anywhere...
> >>>>>
> >>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> >>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI protocol
> extension.
> >>>>>
> >>>>> With additionalProperties set to false, I not know how, please suggest.
> >>>>
> >>>> First of all, you cannot affect negatively existing devices (their
> >>>> bindings) and your patch does exactly that. This should make you
> >>>> thing what is the correct approach...
> >>>>
> >>>> Rob gave you the comment about missing compatible - you still did
> >>>> not address that.
> >>>
> >>> I added the compatible in patch 2/6 in the examples "compatible =
> >> "arm,scmi";"
> >>
> >> So you claim that your vendor extensions are the same or fully
> >> compatible with arm,scmi and you add nothing... Are your
> >> extensions/protocol valid for arm,scmi?
> >
> > Yes. They are valid for arm,scmi.
> >
> > If yes, why is this in separate binding. If no, why you use someone
> >> else's compatible?
> >
> > Per SCMI Spec
> > 0x80-0xFF: Reserved for vendor or platform-specific extensions to this
> > interface
> >
> > i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use the
> > id for their own protocol.
>
> So how are they valid for arm,scmi? I don't understand.
arm,scmi is a firmware compatible string. The protocol node is a sub-node.
I think the arm,scmi is that saying the firmware following
SCMI spec to implement the protocols.
For vendor reserved ID, firmware also follow the SCMI spec to implement
their own usage, so from firmware level, it is ARM SCMI spec compatible.
firmware {
scmi {
compatible = "arm,scmi";
#address-cells = <1>;
#size-cells = <0>;
scmi_devpd: protocol@11 {
reg = <0x11>;
#power-domain-cells = <1>;
};
scmi_sys_power: protocol@12 {
reg = <0x12>;
};
scmi_perf: protocol@13 {
reg = <0x13>;
#clock-cells = <1>;
#power-domain-cells = <1>;
};
Scmi_bbm: protocol@81 {
reg = <0x81>; ->vendor id
vendor,xyz; ---> vendor properties.
}
Thanks,
Peng.
>
>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v9 1/7] dt-bindings: spmi: Add X1E80100 SPMI PMIC ARB schema
From: Krzysztof Kozlowski @ 2024-04-08 6:30 UTC (permalink / raw)
To: Abel Vesa, Bjorn Andersson, Krzysztof Kozlowski
Cc: Stephen Boyd, Matthias Brugger, Konrad Dybcio, Dmitry Baryshkov,
Neil Armstrong, AngeloGioacchino Del Regno, Rob Herring,
Conor Dooley, Srini Kandagatla, Johan Hovold, David Collins,
linux-kernel, linux-arm-kernel, linux-arm-msm, linux-mediatek,
devicetree
In-Reply-To: <ZhOJB8o9cRr7oQU8@linaro.org>
On 08/04/2024 08:04, Abel Vesa wrote:
> On 24-04-07 19:07:03, Bjorn Andersson wrote:
>> On Sun, Apr 07, 2024 at 07:23:21PM +0300, Abel Vesa wrote:
>>> Add dedicated schema for X1E80100 PMIC ARB (v7) as it allows multiple
>>> buses by declaring them as child nodes.
>>>
>>
>> But is this really a "dedicated schema for X1E80100"? Isn't it "the
>> schema for all multi-bus controllers"?
>>
>> I.e. isn't this a "dedicated schema for all platforms starting with
>> SM8450"?
>
> Suggestion was from Krzysztof to add platform specific comaptible (and
> therefore schema). Since the first platform that will support in
> upstream proper multi bus is the x1e80100, the schema needs to bear the
> same name as the compatible. When support for multi bus will be added to
> the other platforms (including the SM8450), they will use the fallback
> compatible of the x1e80100 and will be documented in this newly added
> schema. We did the same thing with some PHYs drivers, IIRC.
>
>>
>> Can you please use the commit message to document the actual reason why
>> you choose to create a dedicated schema for this? Is it simply to avoid
>> having to schema with either pmics or multiple buses as children?
>
> I can re-send the patchset with such a phrase in commit message.
>
> One of the early versions of this patchset was actually submitting a
> generic compatible for multi bus, but I remember that there was a
> request for following the platform dedicated approach.
>
> Krzysztof, can you please provide here the argument for why that is
> preferred?
I could not find such suggestions from my side in the archives, except:
https://lore.kernel.org/all/dd86117e-0196-499b-b8b3-efe4013cbc07@linaro.org/
where I want SoC specific compatibles to be used, not versions.
Now about this binding, it is not a schema for all platforms starting
with sm8450, but only for x1e. I do not understand why this would be a
problem?
If you ask why this is not a schema for all platforms, then because:
1. maybe no one tested other SoCs?
2. maybe no one cares?
3. maybe other boards need some quirks, so this would be applicable but
not fully?
I don't know... since when do we add "generic schemas"?
However maybe the question is different: why other devices are not
described here, while they should? Then probably Abel can answer what he
wants and what he does not want to describe. There is no requirement to
model all possible hardware in a binding, but instead describe one
hardware, so x1e, fully.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: media: imx8-jpeg: Add clocks entries
From: Krzysztof Kozlowski @ 2024-04-08 6:38 UTC (permalink / raw)
To: Mirela Rabulea, shawnguo, robh+dt, krzysztof.kozlowski+dt,
festevam, festevam, alexander.stein, Frank.li, ming.qian
Cc: conor+dt, devicetree, linux-arm-kernel, s.hauer, kernel, mchehab,
hverkuil, linux-media, imx, linux-kernel
In-Reply-To: <20240408030734.1191069-1-mirela.rabulea@nxp.com>
On 08/04/2024 05:07, Mirela Rabulea wrote:
> From: Fabio Estevam <festevam@gmail.com>
>
> The JPEG decoder/encoder present in iMX8QXP and iMX8QM SoCs need
> the PER and IPG clocks to be functional, so add the clock entries.
>
> This also fixes the following schema warning:
>
> imx8qm-apalis-eval.dtb: jpegdec@58400000: 'assigned-clock-rates', 'assigned-clocks', 'clock-names', 'clocks' do not match any of the regexes: 'pinctrl-[0-9]+'
> from schema $id: http://devicetree.org/schemas/media/nxp,imx8-jpeg.yaml#
>
> Signed-off-by: Fabio Estevam <festevam@denx.de>
> Signed-off-by: Mirela Rabulea <mirela.rabulea@nxp.com>
> ---
>
Please correct subject. You already got comments on this.
https://lore.kernel.org/linux-devicetree/2fb8c43c-c079-e04e-f727-3bc1dc29996e@linaro.org/
> Changes since v3:
> - Add items for clocks (per Krzysztof's feddback)
> - Add description for clocks (per Conor's feddback to the other similar patch from Alexander)
> - Add "media:" to the subject
Where? It was there before, so what did you change?
> - Add Mirela's signed-off
> - For the similar patches that were sent for this issue, should Co-developed-by/Signed-off-by be added? Alexander Stein? Frank Li?
>
> Changes since v2:
> - Remove clock-names. (Mirela)
>
> .../devicetree/bindings/media/nxp,imx8-jpeg.yaml | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml b/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
> index 3d9d1db37040..cc040feb77d7 100644
> --- a/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
> +++ b/Documentation/devicetree/bindings/media/nxp,imx8-jpeg.yaml
> @@ -31,6 +31,14 @@ properties:
> reg:
> maxItems: 1
>
> + clocks:
> + description:
> + The JPEG decoder/encoder requires two clocks for it's wrapper (AXI and APB),
> + and one clock for it's core engine (AXI, same source as for the wrapper)
Description is now redundant, drop it.
> + items:
> + - description: AXI DMA engine clock for fetching JPEG bitstream from memory (per)
> + - description: IP bus clock for register access (ipg)
> +
> interrupts:
> description: |
> There are 4 slots available in the IP, which the driver may use
> @@ -49,6 +57,7 @@ properties:
> required:
> - compatible
> - reg
> + - clocks
> - interrupts
> - power-domains
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] dt-bindings: net: rockchip-dwmac: use rgmii-id in example
From: Sascha Hauer @ 2024-04-08 6:44 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
David Wu
Cc: netdev, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Andrew Lunn, Sascha Hauer
The dwmac supports specifying the RGMII clock delays, but it is
recommended to use rgmii-id and to specify the delays in the phy node
instead [1].
Change the example accordingly to no longer promote this undesired
setting.
[1] https://lore.kernel.org/all/1a0de7b4-f0f7-4080-ae48-f5ffa9e76be3@lunn.ch/
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
Documentation/devicetree/bindings/net/rockchip-dwmac.yaml | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
index 70bbc4220e2ac..6bbe96e352509 100644
--- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml
@@ -137,8 +137,6 @@ examples:
assigned-clock-parents = <&ext_gmac>;
rockchip,grf = <&grf>;
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
clock_in_out = "input";
- tx_delay = <0x30>;
- rx_delay = <0x10>;
};
---
base-commit: 39cd87c4eb2b893354f3b850f916353f2658ae6f
change-id: 20240408-rockchip-dwmac-rgmii-id-binding-6166af659845
Best regards,
--
Sascha Hauer <s.hauer@pengutronix.de>
^ permalink raw reply related
* Re: [PATCH v4 0/5] Pinephone video out fixes (flipping between two frames)
From: Stephen Boyd @ 2024-04-08 6:48 UTC (permalink / raw)
To: Chen-Yu Tsai, Frank Oltmanns, Jernej Skrabec, Maxime Ripard,
Michael Turquette, Samuel Holland
Cc: Guido Günther, Purism Kernel Team, Ondrej Jirman,
Neil Armstrong, Jessica Zhang, Sam Ravnborg, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Daniel Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-clk, linux-arm-kernel,
linux-sunxi, linux-kernel, dri-devel, devicetree, stable,
Diego Roversi, Erico Nunes
In-Reply-To: <87frw2a2e4.fsf@oltmanns.dev>
Quoting Frank Oltmanns (2024-04-03 08:31:47)
> Dear clk and sunxi-ng maintainers,
>
> Patches 1-4 have been reviewed and there are no pending issues. If there
> is something else you need me to do to get this applied, please let me
> know.
>
I'm assuming sunxi maintainers will pick up the clk patches and send
them to clk tree in a PR.
^ permalink raw reply
* [PATCH 1/2] dt-bindings: power: supply: ltc3350-charger: Add bindings
From: Mike Looijmans @ 2024-04-08 6:49 UTC (permalink / raw)
To: linux-pm
Cc: Mike Looijmans, Conor Dooley, Krzysztof Kozlowski, Rob Herring,
Sebastian Reichel, devicetree, linux-kernel
In-Reply-To: <1b153bce-a66a-45ee-a5c6-963ea6fb1c82.949ef384-8293-46b8-903f-40a477c056ae.3bc97c8f-843d-4e46-84f9-469b7ba2489d@emailsignatures365.codetwo.com>
The LTC3350 is a backup power controller that can charge and monitor
a series stack of one to four supercapacitors.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
---
.../bindings/power/supply/ltc3350.yaml | 55 +++++++++++++++++++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power/supply/ltc3350.yaml
diff --git a/Documentation/devicetree/bindings/power/supply/ltc3350.yaml b/Documentation/devicetree/bindings/power/supply/ltc3350.yaml
new file mode 100644
index 000000000000..607a62fd25ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/supply/ltc3350.yaml
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (C) 2024 Topic Embedded Products
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/power/supply/ltc3350.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Linear Technology (Analog Devices) LTC3350 Supercap Charger
+
+maintainers:
+ - Mike Looijmans <mike.looijmans@topic.nl>
+
+description: |
+ The LTC3350 is a High Current Supercapacitor Backup Controller and System
+ Monitor.
+ Specifications about the charger can be found at:
+ https://www.analog.com/en/products/ltc3350.html
+
+properties:
+ compatible:
+ enum:
+ - lltc,ltc3350
+
+ reg:
+ maxItems: 1
+ description: I2C address of the charger.
+
+ lltc,rsnsc-micro-ohms:
+ description: Capacitor charger sense resistor in microohm.
+ minimum: 1000
+
+ lltc,rsnsi-micro-ohms:
+ description: Input current sense resistor in microohm.
+ minimum: 1000
+
+required:
+ - compatible
+ - reg
+ - lltc,rsnsc-micro-ohms
+ - lltc,rsnsi-micro-ohms
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ charger: battery-charger@9 {
+ compatible = "lltc,ltc3350";
+ reg = <0x9>;
+ lltc,rsnsc-micro-ohms = <10000>;
+ lltc,rsnsi-micro-ohms = <10000>;
+ };
+ };
--
2.34.1
Met vriendelijke groet / kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: mike.looijmans@topic.nl
W: www.topic.nl
Please consider the environment before printing this e-mail
^ permalink raw reply related
* Re: [PATCH 0/4] arm64: dts: qcom: add USB-C orientation GPIOs
From: Luca Weiss @ 2024-04-08 7:02 UTC (permalink / raw)
To: Dmitry Baryshkov, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240408-hdk-orientation-gpios-v1-0-8064ba43e52a@linaro.org>
On Mon Apr 8, 2024 at 4:33 AM CEST, Dmitry Baryshkov wrote:
> Populate orientation GPIOs for some of the PMIC-GLINK-based devices.
> This leaves only FairPhone5, RB3Gen2, SC8180X Primus and SC8280XP CRD
> without the orientation GPIOs declared.
Hi Dmitry,
How would I find this GPIO on the schematics, or downstream devicetree?
I scanned over some relevant areas but nothing jumped out at me except
for the USB_PHY_PS signal coming from PM7250B CC_OUT and going into
GPIO_140 of the QCM6490 - but I'm guessing this is something else?
Regards
Luca
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> Dmitry Baryshkov (4):
> arm64: dts: qcom: sm8350-hdk: add USB-C orientation GPIO
> arm64: dts: qcom: sm8450-hdk: add USB-C orientation GPIO
> arm64: dts: qcom: sc8280xp-lenovo-thinkpad-x13s: add USB-C orientation GPIOs
> arm64: dts: qcom: sc8180x-lenovo-flex-5g: add USB-C orientation GPIOs
>
> arch/arm64/boot/dts/qcom/sc8180x-lenovo-flex-5g.dts | 2 ++
> arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 2 ++
> arch/arm64/boot/dts/qcom/sm8350-hdk.dts | 1 +
> arch/arm64/boot/dts/qcom/sm8450-hdk.dts | 1 +
> 4 files changed, 6 insertions(+)
> ---
> base-commit: 8568bb2ccc278f344e6ac44af6ed010a90aa88dc
> change-id: 20240408-hdk-orientation-gpios-141bc7fd247d
>
> Best regards,
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox