* [PATCH 6/9] dt-bindings: rtc: pxa-rtc: convert to dtschema
From: Javier Carrasco @ 2024-04-08 15:53 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jiaxun Yang, Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery,
Maxime Coquelin, Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32, Javier Carrasco
In-Reply-To: <20240408-rtc_dtschema-v1-0-c447542fc362@gmail.com>
Convert existing binding to dtschema to support validation.
The missing 'reg' and 'interrupts' properties have been added, taking
the 2 supported interrupts into account to fix the example.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
.../devicetree/bindings/rtc/marvell,pxa-rtc.yaml | 40 ++++++++++++++++++++++
Documentation/devicetree/bindings/rtc/pxa-rtc.txt | 14 --------
2 files changed, 40 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/marvell,pxa-rtc.yaml b/Documentation/devicetree/bindings/rtc/marvell,pxa-rtc.yaml
new file mode 100644
index 000000000000..43d68681a1bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/marvell,pxa-rtc.yaml
@@ -0,0 +1,40 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/marvell,pxa-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: PXA Real Time Clock
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ const: marvell,pxa-rtc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: 1 Hz
+ - description: Alarm
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ rtc@40900000 {
+ compatible = "marvell,pxa-rtc";
+ reg = <0x40900000 0x3c>;
+ interrupts = <30>, <31>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/pxa-rtc.txt b/Documentation/devicetree/bindings/rtc/pxa-rtc.txt
deleted file mode 100644
index 8c6672a1b7d7..000000000000
--- a/Documentation/devicetree/bindings/rtc/pxa-rtc.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-* PXA RTC
-
-PXA specific RTC driver.
-
-Required properties:
-- compatible : Should be "marvell,pxa-rtc"
-
-Examples:
-
-rtc@40900000 {
- compatible = "marvell,pxa-rtc";
- reg = <0x40900000 0x3c>;
- interrupts = <30 31>;
-};
--
2.40.1
^ permalink raw reply related
* [PATCH 7/9] dt-bindings: rtc: spear-rtc: move to trivial-rtc
From: Javier Carrasco @ 2024-04-08 15:53 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jiaxun Yang, Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery,
Maxime Coquelin, Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32, Javier Carrasco
In-Reply-To: <20240408-rtc_dtschema-v1-0-c447542fc362@gmail.com>
The RTC documented in this binding requires a compatible, a reg
and a single interrupt, which makes it suitable for a direct
conversion into trivial-rtc.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
Documentation/devicetree/bindings/rtc/spear-rtc.txt | 15 ---------------
Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
2 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/spear-rtc.txt b/Documentation/devicetree/bindings/rtc/spear-rtc.txt
deleted file mode 100644
index fecf8e4ad4b4..000000000000
--- a/Documentation/devicetree/bindings/rtc/spear-rtc.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-* SPEAr RTC
-
-Required properties:
-- compatible : "st,spear600-rtc"
-- reg : Address range of the rtc registers
-- interrupt: Should contain the rtc interrupt number
-
-Example:
-
- rtc@fc000000 {
- compatible = "st,spear600-rtc";
- reg = <0xfc000000 0x1000>;
- interrupt-parent = <&vic1>;
- interrupts = <12>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
index 0f773167d32a..d75c93ad2e92 100644
--- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
@@ -81,6 +81,8 @@ properties:
- ricoh,rv5c387a
# 2-wire CMOS real-time clock
- sii,s35390a
+ # ST SPEAr Real-time Clock
+ - st,spear600-rtc
# I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
- whwave,sd3078
# Xircom X1205 I2C RTC
--
2.40.1
^ permalink raw reply related
* [PATCH 8/9] dt-bindings: rtc: stmp3xxx-rtc: convert to dtschema
From: Javier Carrasco @ 2024-04-08 15:53 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jiaxun Yang, Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery,
Maxime Coquelin, Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32, Javier Carrasco
In-Reply-To: <20240408-rtc_dtschema-v1-0-c447542fc362@gmail.com>
Convert existing binding to dtschema to support validation.
The 'fsl,imx28-rtc' compatible is currently not supported, and it is
only referenced in this binding and in nxp/mxs/imx28.dtsi. Therefore,
that compatible has been dropped, which triggers a warning when testing
the DT against the new binding.
There is another reference to fsl,stmp3xxx-rtc in nxp/mxs/imx23.dtsi,
where another unsupported compatible 'fsl,imx23-rtc' is used, and the
same problem would arise when testing the file against the new binding.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
.../devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml | 45 ++++++++++++++++++++++
.../devicetree/bindings/rtc/stmp3xxx-rtc.txt | 21 ----------
2 files changed, 45 insertions(+), 21 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml b/Documentation/devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml
new file mode 100644
index 000000000000..bf70cce2701f
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/fsl,stmp3xxx-rtc.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/fsl,stmp3xxx-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMP3xxx/i.MX28 Time Clock Controller
+
+maintainers:
+ - Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ const: fsl,stmp3xxx-rtc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ stmp,crystal-freq:
+ description:
+ Override crystal frequency as determined from fuse bits.
+ Use <0> for "no crystal".
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 32000, 32768]
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ rtc@80056000 {
+ compatible = "fsl,stmp3xxx-rtc";
+ reg = <0x80056000 2000>;
+ interrupts = <29>;
+ };
diff --git a/Documentation/devicetree/bindings/rtc/stmp3xxx-rtc.txt b/Documentation/devicetree/bindings/rtc/stmp3xxx-rtc.txt
deleted file mode 100644
index fa6a94226669..000000000000
--- a/Documentation/devicetree/bindings/rtc/stmp3xxx-rtc.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-* STMP3xxx/i.MX28 Time Clock controller
-
-Required properties:
-- compatible: should be one of the following.
- * "fsl,stmp3xxx-rtc"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: rtc alarm interrupt
-
-Optional properties:
-- stmp,crystal-freq: override crystal frequency as determined from fuse bits.
- Only <32000> and <32768> are possible for the hardware. Use <0> for
- "no crystal".
-
-Example:
-
-rtc@80056000 {
- compatible = "fsl,imx28-rtc", "fsl,stmp3xxx-rtc";
- reg = <0x80056000 2000>;
- interrupts = <29>;
-};
--
2.40.1
^ permalink raw reply related
* [PATCH 9/9] dt-bindings: rtc: via,vt8500-rtc: move to trivial-rtc
From: Javier Carrasco @ 2024-04-08 15:53 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jiaxun Yang, Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery,
Maxime Coquelin, Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32, Javier Carrasco
In-Reply-To: <20240408-rtc_dtschema-v1-0-c447542fc362@gmail.com>
The RTC documented in this binding requires a compatible, a reg
and a single interrupt, which makes it suitable for a direct
conversion into trivial-rtc.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
---
Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
Documentation/devicetree/bindings/rtc/via,vt8500-rtc.txt | 15 ---------------
2 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
index d75c93ad2e92..c48d0dfa28b2 100644
--- a/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/trivial-rtc.yaml
@@ -83,6 +83,8 @@ properties:
- sii,s35390a
# ST SPEAr Real-time Clock
- st,spear600-rtc
+ # VIA/Wondermedia VT8500 Real-time Clock
+ - via,vt8500-rtc
# I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
- whwave,sd3078
# Xircom X1205 I2C RTC
diff --git a/Documentation/devicetree/bindings/rtc/via,vt8500-rtc.txt b/Documentation/devicetree/bindings/rtc/via,vt8500-rtc.txt
deleted file mode 100644
index 3c0484c49582..000000000000
--- a/Documentation/devicetree/bindings/rtc/via,vt8500-rtc.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-VIA/Wondermedia VT8500 Realtime Clock Controller
------------------------------------------------------
-
-Required properties:
-- compatible : "via,vt8500-rtc"
-- reg : Should contain 1 register ranges(address and length)
-- interrupts : alarm interrupt
-
-Example:
-
- rtc@d8100000 {
- compatible = "via,vt8500-rtc";
- reg = <0xd8100000 0x10000>;
- interrupts = <48>;
- };
--
2.40.1
^ permalink raw reply related
* Re: [PATCH v2 01/10] arm64: dts: microchip: sparx5: fix mdio reg
From: Conor Dooley @ 2024-04-08 16:00 UTC (permalink / raw)
To: Conor Dooley, Nicolas Ferre, Claudiu Beznea, Rob Herring,
Krzysztof Kozlowski, Lars Povlsen, Steen Hegelund, Daniel Machon,
UNGLinuxDriver, Bjarni Jonasson, David S. Miller,
linux-arm-kernel, devicetree, linux-kernel, Krzysztof Kozlowski
Cc: Conor Dooley, horatiu.vultur, steen.hegelund
In-Reply-To: <20240405190419.74162-1-krzk@kernel.org>
From: Conor Dooley <conor.dooley@microchip.com>
On Fri, 05 Apr 2024 21:04:10 +0200, Krzysztof Kozlowski wrote:
> Correct the reg address of mdio node to match unit address. Assume the
> reg is not correct and unit address was correct, because there is
> already node using the existing reg 0x110102d4.
>
> sparx5.dtsi:443.25-451.5: Warning (simple_bus_reg): /axi@600000000/mdio@6110102f8: simple-bus unit address format error, expected "6110102d4"
>
>
> [...]
Applied to microchip-dt64, thanks! I'll re-direct it to fixes either if
some wider cleanup needs some of these warnings gone before v6.10-rc1.
[01/10] arm64: dts: microchip: sparx5: fix mdio reg
https://git.kernel.org/at91/c/5d83b9cbe7cf
[02/10] arm64: dts: microchip: sparx5: correct serdes unit address
https://git.kernel.org/at91/c/013627825bbe
[03/10] arm64: dts: microchip: sparx5_pcb134: add missing I2C mux unit addresses
https://git.kernel.org/at91/c/9dcf4ec57700
[04/10] arm64: dts: microchip: sparx5_pcb135: add missing I2C mux unit addresses
https://git.kernel.org/at91/c/5150c3df4c2e
[05/10] arm64: dts: microchip: sparx5_pcb134: align I2C mux node name with bindings
https://git.kernel.org/at91/c/d3dd7bed4210
[06/10] arm64: dts: microchip: sparx5_pcb135: align I2C mux node name with bindings
https://git.kernel.org/at91/c/b0d5a3ce782a
[07/10] arm64: dts: microchip: sparx5_pcb134: drop LED unit addresses
https://git.kernel.org/at91/c/55fb5a97ebe0
[08/10] arm64: dts: microchip: sparx5_pcb135: drop LED unit addresses
https://git.kernel.org/at91/c/5945df4de0e2
[09/10] arm64: dts: microchip: sparx5_pcb134: drop duplicated NOR flash
https://git.kernel.org/at91/c/f1595d501ea4
[10/10] arm64: dts: microchip: sparx5_pcb135: drop duplicated NOR flash
https://git.kernel.org/at91/c/6c7c4b91aa43
Thanks,
Conor.
^ permalink raw reply
* [PATCH] dt-bindings: iio: imu: mpu6050: Improve i2c-gate disallow list
From: Luca Weiss @ 2024-04-08 16:34 UTC (permalink / raw)
To: ~postmarketos/upstreaming, phone-devel, Jonathan Cameron,
Lars-Peter Clausen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jean-Baptiste Maneyrol
Cc: linux-iio, devicetree, linux-kernel, Luca Weiss
Before all supported sensors except for MPU{9150,9250,9255} were not
allowed to use i2c-gate in the bindings which excluded quite a few
supported sensors where this functionality is supported.
Switch the list of sensors to ones where the Linux driver explicitly
disallows support for the auxiliary bus ("inv_mpu_i2c_aux_bus"). Since
the driver is also based on "default: return true" this should scale
better into the future.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
This fixes dt validation error on qcom-msm8974-lge-nexus5-hammerhead
which uses mpu6515
arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dtb: mpu6515@68: i2c-gate: False schema does not allow {'#address-cells': [[1]], '#size-cells': [[0]], 'ak8963@f': {'compatible': ['asahi-kasei,ak8963'], 'reg': [[15]], 'gpios': [[40, 67, 0]], 'vid-supply': [[50]], 'vdd-supply': [[49]]}, 'bmp280@76': {'compatible': ['bosch,bmp280'], 'reg': [[118]], 'vdda-supply': [[50]], 'vddd-supply': [[49]]}}
from schema $id: http://devicetree.org/schemas/iio/imu/invensense,mpu6050.yaml#
---
.../devicetree/bindings/iio/imu/invensense,mpu6050.yaml | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml b/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml
index 297b8a1a7ffb..587ff2bced2d 100644
--- a/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml
+++ b/Documentation/devicetree/bindings/iio/imu/invensense,mpu6050.yaml
@@ -62,14 +62,15 @@ properties:
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#
- if:
- not:
- properties:
- compatible:
- contains:
- enum:
- - invensense,mpu9150
- - invensense,mpu9250
- - invensense,mpu9255
+ properties:
+ compatible:
+ contains:
+ enum:
+ - invensense,iam20680
+ - invensense,icm20602
+ - invensense,icm20608
+ - invensense,icm20609
+ - invensense,icm20689
then:
properties:
i2c-gate: false
---
base-commit: 8568bb2ccc278f344e6ac44af6ed010a90aa88dc
change-id: 20240408-mpu6050-i2c-gate-4ea473e492f4
Best regards,
--
Luca Weiss <luca@z3ntu.xyz>
^ permalink raw reply related
* [PATCH 0/2] Allow gpio-hog nodes in qcom,pmic-gpio bindings (& dt fixup)
From: Luca Weiss @ 2024-04-08 16:39 UTC (permalink / raw)
To: ~postmarketos/upstreaming, phone-devel, Bjorn Andersson,
Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio
Cc: linux-arm-msm, linux-gpio, devicetree, linux-kernel, Luca Weiss
Resolve the dt validation failure on Nexus 5.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
Luca Weiss (2):
dt-bindings: pinctrl: qcom,pmic-gpio: Allow gpio-hog nodes
ARM: dts: qcom: msm8974-hammerhead: Update gpio hog node name
.../devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml | 12 ++++++++++++
.../arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts | 2 +-
2 files changed, 13 insertions(+), 1 deletion(-)
---
base-commit: 8568bb2ccc278f344e6ac44af6ed010a90aa88dc
change-id: 20240408-qcom-pmic-gpio-hog-2b4c5f103126
Best regards,
--
Luca Weiss <luca@z3ntu.xyz>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: pinctrl: qcom,pmic-gpio: Allow gpio-hog nodes
From: Luca Weiss @ 2024-04-08 16:39 UTC (permalink / raw)
To: ~postmarketos/upstreaming, phone-devel, Bjorn Andersson,
Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio
Cc: linux-arm-msm, linux-gpio, devicetree, linux-kernel, Luca Weiss
In-Reply-To: <20240408-qcom-pmic-gpio-hog-v1-0-f61fc5323110@z3ntu.xyz>
Allow specifying a GPIO hog, as already used on
qcom-msm8974-lge-nexus5-hammerhead.dts.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
.../devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
index a786357ed1af..510a05369dbb 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
@@ -424,6 +424,10 @@ patternProperties:
$ref: "#/$defs/qcom-pmic-gpio-state"
additionalProperties: false
+ "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$":
+ required:
+ - gpio-hog
+
$defs:
qcom-pmic-gpio-state:
type: object
@@ -571,6 +575,7 @@ $defs:
examples:
- |
+ #include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
pm8921_gpio: gpio@150 {
@@ -594,5 +599,12 @@ examples:
power-source = <PM8921_GPIO_S4>;
};
};
+
+ otg-hog {
+ gpio-hog;
+ gpios = <35 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "otg-gpio";
+ };
};
...
--
2.44.0
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: qcom: msm8974-hammerhead: Update gpio hog node name
From: Luca Weiss @ 2024-04-08 16:39 UTC (permalink / raw)
To: ~postmarketos/upstreaming, phone-devel, Bjorn Andersson,
Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio
Cc: linux-arm-msm, linux-gpio, devicetree, linux-kernel, Luca Weiss
In-Reply-To: <20240408-qcom-pmic-gpio-hog-v1-0-f61fc5323110@z3ntu.xyz>
Follow the gpio-hog bindings and use otg-hog as node name.
Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
---
arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
index 4aaae8537a3f..06549051be50 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts
@@ -328,7 +328,7 @@ wlan_regulator_pin: wl-reg-active-state {
power-source = <PM8941_GPIO_S3>;
};
- otg {
+ otg-hog {
gpio-hog;
gpios = <35 GPIO_ACTIVE_HIGH>;
output-high;
--
2.44.0
^ permalink raw reply related
* Re: [PATCH 2/6] iio: adc: ad7173: fix buffers enablement for ad7176-2
From: Ceclan, Dumitru @ 2024-04-08 16:40 UTC (permalink / raw)
To: Jonathan Cameron, Dumitru Ceclan via B4 Relay
Cc: dumitru.ceclan, Lars-Peter Clausen, Michael Hennerich,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, David Lechner,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20240406155646.694f710b@jic23-huawei>
On 06/04/2024 17:56, Jonathan Cameron wrote:
> On Mon, 01 Apr 2024 18:32:20 +0300
> Dumitru Ceclan via B4 Relay <devnull+dumitru.ceclan.analog.com@kernel.org> wrote:
>
>> From: Dumitru Ceclan <dumitru.ceclan@analog.com>
>>
>> AD7176-2 does not feature input buffers, enable buffers only on
>> supported models.
>>
>> Fixes: cff259bf7274 ("iio: adc: ad7173: fix buffers enablement for ad7176-2")
>> Signed-off-by: Dumitru Ceclan <dumitru.ceclan@analog.com>
> How bad is this? If you can find out if writing those bits does anything
> harmful (they are reserved and datasheet says should be written 0 I think)
> That will help people decide whether to backport the fix?
The bits are marked as read-only and there does not seem to be any effect on the ADC.
So drop this one?
^ permalink raw reply
* Re: [PATCH v2 08/11] spi: cadence-qspi: add early busywait to cqspi_wait_for_bit()
From: Mark Brown @ 2024-04-08 16:40 UTC (permalink / raw)
To: Théo Lebrun
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vaishnav Achath,
Thomas Bogendoerfer, Rob Herring, linux-spi, devicetree,
linux-kernel, linux-mips, Vladimir Kondratiev, Gregory CLEMENT,
Thomas Petazzoni, Tawfik Bayouk
In-Reply-To: <D0ETJXNHOUKQ.C368FEZVM9DD@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 859 bytes --]
On Mon, Apr 08, 2024 at 04:42:43PM +0200, Théo Lebrun wrote:
> On Mon Apr 8, 2024 at 4:16 PM CEST, Mark Brown wrote:
> > On Fri, Apr 05, 2024 at 05:02:18PM +0200, Théo Lebrun wrote:
> > > The reason is to avoid hrtimer interrupts on the system. All read
> > > operations take less than 100µs.
> > Why would this be platform specific, this seems like a very standard
> > optimisation technique?
> It does not make sense if you know that all read operations take more
> than 100µs. I preferred being conservative. If you confirm it makes
> sense I'll remove the quirk.
It does seem plausible at least, and the time could be made a tuneable
with quirks or otherwise if that's needed. I think I'd expect the MIPS
platform you're working with to be towards the lower end of performance
for systems that are new enough to have this hardware.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v1 0/2] ASoC: meson: implement link-name optional property in meson audio card
From: Dmitry Rokosov @ 2024-04-08 16:49 UTC (permalink / raw)
To: neil.armstrong, lgirdwood, jbrunet, broonie, conor+dt, robh+dt,
krzysztof.kozlowski+dt, perex, tiwai, khilman,
martin.blumenstingl
Cc: kernel, rockosov, linux-amlogic, alsa-devel, linux-sound,
devicetree, linux-kernel, linux-arm-kernel, Dmitry Rokosov
The 'link-name' is optional feature in the Device Tree that allows users
to customize the name associated with the DAI link and PCM stream. This
feature provides enhanced flexibility in DAI naming conventions, leading
to improved system integration and a better user experience.
Dmitry Rokosov (2):
ASoC: dt-bindings: meson: introduce link-name optional property
ASoC: meson: implement link-name optional property in meson card utils
.../bindings/sound/amlogic,axg-sound-card.yaml | 6 ++++++
.../bindings/sound/amlogic,gx-sound-card.yaml | 6 ++++++
sound/soc/meson/meson-card-utils.c | 12 ++++++++----
3 files changed, 20 insertions(+), 4 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v1 1/2] ASoC: dt-bindings: meson: introduce link-name optional property
From: Dmitry Rokosov @ 2024-04-08 16:49 UTC (permalink / raw)
To: neil.armstrong, lgirdwood, jbrunet, broonie, conor+dt, robh+dt,
krzysztof.kozlowski+dt, perex, tiwai, khilman,
martin.blumenstingl
Cc: kernel, rockosov, linux-amlogic, alsa-devel, linux-sound,
devicetree, linux-kernel, linux-arm-kernel, Dmitry Rokosov
In-Reply-To: <20240408164947.30717-1-ddrokosov@salutedevices.com>
The 'link-name' property is an optional DT property that allows for the
customization of the name associated with the DAI link and PCM stream.
This functionality mirrors the approach commonly utilized in Qualcomm
audio cards, providing flexibility in DAI naming conventions for
improved system integration and userspace experience.
It allows userspace program to easy determine PCM stream purpose, e.g.:
~ # cat /proc/asound/pcm
00-00: speaker (*) : : playback 1
00-01: mics (*) : : capture 1
00-02: loopback (*) : : capture 1
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
---
.../devicetree/bindings/sound/amlogic,axg-sound-card.yaml | 6 ++++++
.../devicetree/bindings/sound/amlogic,gx-sound-card.yaml | 6 ++++++
2 files changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml b/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml
index 492b41cc8ccd..46774a3e4b1d 100644
--- a/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml
+++ b/Documentation/devicetree/bindings/sound/amlogic,axg-sound-card.yaml
@@ -66,6 +66,11 @@ patternProperties:
maxItems: 1
description: phandle of the CPU DAI
+ link-name:
+ description: Indicates dai-link name and PCM stream name.
+ $ref: /schemas/types.yaml#/definitions/string
+ maxItems: 1
+
patternProperties:
"^dai-tdm-slot-(t|r)x-mask-[0-3]$":
$ref: /schemas/types.yaml#/definitions/uint32-array
@@ -137,6 +142,7 @@ examples:
dai-link-0 {
sound-dai = <&frddr_a>;
+ link-name = "speaker";
};
dai-link-1 {
diff --git a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml
index d4277d342e69..975c148f9712 100644
--- a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml
+++ b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml
@@ -52,6 +52,11 @@ patternProperties:
maxItems: 1
description: phandle of the CPU DAI
+ link-name:
+ description: Indicates dai-link name and PCM stream name.
+ $ref: /schemas/types.yaml#/definitions/string
+ maxItems: 1
+
patternProperties:
"^codec(-[0-9]+)?$":
type: object
@@ -89,6 +94,7 @@ examples:
dai-link-0 {
sound-dai = <&i2s_fifo>;
+ link-name = "speaker";
};
dai-link-1 {
--
2.43.0
^ permalink raw reply related
* [PATCH v1 2/2] ASoC: meson: implement link-name optional property in meson card utils
From: Dmitry Rokosov @ 2024-04-08 16:49 UTC (permalink / raw)
To: neil.armstrong, lgirdwood, jbrunet, broonie, conor+dt, robh+dt,
krzysztof.kozlowski+dt, perex, tiwai, khilman,
martin.blumenstingl
Cc: kernel, rockosov, linux-amlogic, alsa-devel, linux-sound,
devicetree, linux-kernel, linux-arm-kernel, Dmitry Rokosov
In-Reply-To: <20240408164947.30717-1-ddrokosov@salutedevices.com>
The 'link-name' property presents an optional DT feature that empowers
users to customize the name associated with the DAI link and PCM stream.
This functionality reflects the approach often employed in Qualcomm
audio cards, providing enhanced flexibility in DAI naming conventions
for improved system integration and userspace experience.
It allows userspace program to easy determine PCM stream purpose, e.g.:
~ # cat /proc/asound/pcm
00-00: speaker (*) : : playback 1
00-01: mics (*) : : capture 1
00-02: loopback (*) : : capture 1
The previous naming approach using auto-generated fe or be strings
continues to be utilized as a fallback.
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
---
sound/soc/meson/meson-card-utils.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/sound/soc/meson/meson-card-utils.c b/sound/soc/meson/meson-card-utils.c
index ed6c7e2f609c..7bae72905a9b 100644
--- a/sound/soc/meson/meson-card-utils.c
+++ b/sound/soc/meson/meson-card-utils.c
@@ -94,10 +94,14 @@ static int meson_card_set_link_name(struct snd_soc_card *card,
struct device_node *node,
const char *prefix)
{
- char *name = devm_kasprintf(card->dev, GFP_KERNEL, "%s.%s",
- prefix, node->full_name);
- if (!name)
- return -ENOMEM;
+ const char *name;
+
+ if (of_property_read_string(node, "link-name", &name)) {
+ name = devm_kasprintf(card->dev, GFP_KERNEL, "%s.%s",
+ prefix, node->full_name);
+ if (!name)
+ return -ENOMEM;
+ }
link->name = name;
link->stream_name = name;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 3/3] dt-bindings: pinctrl: mediatek: mt7622: add "base" reg
From: Conor Dooley @ 2024-04-08 16:59 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Sean Wang, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Hsin-Yi Wang, linux-mediatek, linux-gpio, devicetree,
linux-arm-kernel, Rafał Miłecki
In-Reply-To: <20240408090506.21596-3-zajec5@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
On Mon, Apr 08, 2024 at 11:05:06AM +0200, Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> Both: MT7622 and MT7629 use two reg spaces: "base" and "eint". It wasn't
> covered by the binding and also example didn't match incomplete binding.
> Fix it.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> ---
> .../bindings/pinctrl/mediatek,mt7622-pinctrl.yaml | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
> index a9ab623b2697..eaa65512161a 100644
> --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt7622-pinctrl.yaml
> @@ -19,10 +19,12 @@ properties:
> - mediatek,mt7629-pinctrl
>
> reg:
> - maxItems: 1
> + minItems: 2
> + maxItems: 2
This should become an items list with descriptions IMO.
> reg-names:
> items:
> + - const: base
> - const: eint
Why isnt the new region appended to the list?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] DONOTMERGE: ep93xx-clk from ep93xx device tree conversion
From: Conor Dooley @ 2024-04-08 17:03 UTC (permalink / raw)
To: nikita.shubin
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexander Sverdlin, linux-kernel, linux-clk,
devicetree, Arnd Bergmann, Linus Walleij, Krzysztof Kozlowski
In-Reply-To: <20240408-ep93xx-clk-v1-0-1d0f4c324647@maquefel.me>
[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]
On Mon, Apr 08, 2024 at 11:09:52AM +0300, Nikita Shubin via B4 Relay wrote:
> The goal is to recieve ACKs.
I dont see a maintainers entry in -rc1 for the drivers/soc/cirrus
portion. Who is gonna give you an Ack for that portion? If you intended
maintaining that driver, should you not add a MAINTAINERS entry for it?
Thanks,
Conor.
>
> This is a fraction of v9 "ep93xx device tree conversion" series:
>
> https://lore.kernel.org/all/20240326-ep93xx-v9-0-156e2ae5dfc8@maquefel.me/
>
> The clk driver for ep93xx was converted to AUX device, as suggested
> originally by Stephen Boyd.
>
> Signed-off-by: Nikita Shubin <nikita.shubin@maquefel.me>
> ---
> Nikita Shubin (4):
> ARM: ep93xx: add regmap aux_dev
> clk: ep93xx: add DT support for Cirrus EP93xx
> dt-bindings: soc: Add Cirrus EP93xx
> soc: Add SoC driver for Cirrus ep93xx
>
> .../bindings/arm/cirrus/cirrus,ep9301.yaml | 38 +
> .../bindings/soc/cirrus/cirrus,ep9301-syscon.yaml | 94 +++
> drivers/clk/Kconfig | 8 +
> drivers/clk/Makefile | 1 +
> drivers/clk/clk-ep93xx.c | 840 +++++++++++++++++++++
> drivers/soc/Kconfig | 1 +
> drivers/soc/Makefile | 1 +
> drivers/soc/cirrus/Kconfig | 13 +
> drivers/soc/cirrus/Makefile | 2 +
> drivers/soc/cirrus/soc-ep93xx.c | 240 ++++++
> include/dt-bindings/clock/cirrus,ep9301-syscon.h | 46 ++
> include/linux/soc/cirrus/ep93xx.h | 26 +
> 12 files changed, 1310 insertions(+)
> ---
> base-commit: fec50db7033ea478773b159e0e2efb135270e3b7
> change-id: 20240408-ep93xx-clk-657a1357de67
>
> Best regards,
> --
> Nikita Shubin <nikita.shubin@maquefel.me>
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: net: rockchip-dwmac: use rgmii-id in example
From: Conor Dooley @ 2024-04-08 17:04 UTC (permalink / raw)
To: Sascha Hauer
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
David Wu, netdev, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Andrew Lunn
In-Reply-To: <20240408-rockchip-dwmac-rgmii-id-binding-v1-1-3886d1a8bd54@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
On Mon, Apr 08, 2024 at 08:44:10AM +0200, Sascha Hauer wrote:
> 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>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] clk: meson: axg: move reset controller's code to separate module
From: Conor Dooley @ 2024-04-08 17:05 UTC (permalink / raw)
To: Stephen Boyd
Cc: Jan Dakinevich, Jerome Brunet, Philipp Zabel, Neil Armstrong,
Michael Turquette, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kevin Hilman, Martin Blumenstingl, linux-amlogic, linux-clk,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <13617b7a892424d2b024c725505a6f4f.sboyd@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2255 bytes --]
On Mon, Apr 08, 2024 at 02:52:37AM -0700, Stephen Boyd wrote:
> Quoting Philipp Zabel (2024-04-08 01:21:47)
> > On So, 2024-04-07 at 19:39 -0700, Stephen Boyd wrote:
> > > Quoting Jerome Brunet (2024-04-02 07:52:38)
> > > >
> > > > On Thu 28 Mar 2024 at 04:08, Jan Dakinevich <jan.dakinevich@salutedevices.com> wrote:
> > > >
> > > > > This code will by reused by A1 SoC.
> > > >
> > > > Could expand a bit please ?
> > > >
> > > > >
> > > > > Signed-off-by: Jan Dakinevich <jan.dakinevich@salutedevices.com>
> > > >
> > > > In general, I like the idea.
> > > >
> > > > We do have a couple a reset registers lost in middle of clocks and this
> > > > change makes it possible to re-use the code instead duplicating it.
> > > >
> > > > The exported function would be used by audio clock controllers, but the
> > > > module created would be purely about reset.
> > > >
> > > > One may wonder how it ended up in the clock tree, especially since the
> > > > kernel as a reset tree too.
> > > >
> > > > I'm not sure if this should move to the reset framework or if it would
> > > > be an unnecessary churn. Stephen, Philipp, do you have an opinion on
> > > > this ?
> > > >
> > >
> > > I'd prefer it be made into an auxiliary device and the driver put in
> > > drivers/reset/ so we can keep reset code in the reset directory.
> >
> > Seconded, the clk-mpfs/reset-mpfs and clk-starfive-jh7110-sys/reset-
> > starfive-jh7110 drivers are examples of this.
> >
> > > The auxiliary device creation function can also be in the
> > > drivers/reset/ directory so that the clk driver calls some function
> > > to create and register the device.
> >
> > I'm undecided about this, do you think mpfs_reset_controller_register()
> > and jh7110_reset_controller_register() should rather live with the
> > reset aux drivers in drivers/reset/ ?
>
> Yes, and also mpfs_reset_read() and friends. We should pass the base
> iomem pointer and parent device to mpfs_reset_adev_alloc() instead and
> then move all that code into drivers/reset with some header file
> exported function to call. That way the clk driver hands over the data
> without having to implement half the implementation.
I'll todo list that :)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: ti,pcm1681: Convert to dtschema
From: Mark Brown @ 2024-04-08 17:11 UTC (permalink / raw)
To: Animesh Agarwal
Cc: Shenghao Ding, Kevin Lu, Baojun Xu, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, alsa-devel, devicetree,
linux-kernel
In-Reply-To: <20240406141454.45529-1-animeshagarwal28@gmail.com>
On Sat, 06 Apr 2024 19:44:49 +0530, Animesh Agarwal wrote:
> Convert the Texas Instruments PCM1681 bindings to DT schema.
> Make bindings complete by adding #sound-dai-cells.
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] dt-bindings: ti,pcm1681: Convert to dtschema
commit: 8167bd1c8a45c289316417cf938bcd8ceec24fd5
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pinctrl: qcom,pmic-gpio: Allow gpio-hog nodes
From: Konrad Dybcio @ 2024-04-08 17:26 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel,
Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20240408-qcom-pmic-gpio-hog-v1-1-f61fc5323110@z3ntu.xyz>
On 4/8/24 18:39, Luca Weiss wrote:
> Allow specifying a GPIO hog, as already used on
> qcom-msm8974-lge-nexus5-hammerhead.dts.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> ---
> .../devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
> index a786357ed1af..510a05369dbb 100644
> --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
> @@ -424,6 +424,10 @@ patternProperties:
> $ref: "#/$defs/qcom-pmic-gpio-state"
> additionalProperties: false
>
> + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$":
I see a couple bindings do this, but I'm not sure if we want two
allow two styles for no reason.. Rob?
Konrad
^ permalink raw reply
* Re: [PATCH] arm64: dts: meson: fix S4 power-controller node
From: Martin Blumenstingl @ 2024-04-08 17:27 UTC (permalink / raw)
To: xianwei.zhao
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, devicetree, linux-arm-kernel,
linux-amlogic, linux-kernel
In-Reply-To: <20240408-fix-secpwr-s4-v1-1-01aa7ee72c52@amlogic.com>
On Mon, Apr 8, 2024 at 5:26 AM Xianwei Zhao via B4 Relay
<devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>
> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>
> The power-controller module works well by adding its parent
> node secure-monitor.
>
Please add a Fixes tag here with the original commit where the
incorrectly placed node was added.
> 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>;
> + };
In Documentation/devicetree/bindings/firmware/amlogic,meson-gxbb-sm.yaml
the hierarchy is:
firmware {
secure-monitor {
power-controller {
...
}
}
}
Is this patch correct (and the documentation needs to be adapted) or
is the documentation correct (and this patch has to be adapted)?
^ permalink raw reply
* Re: [PATCH v3 3/5] dt-bindings: serial: amlogic,meson-uart: Add compatible string for A4
From: Martin Blumenstingl @ 2024-04-08 17:28 UTC (permalink / raw)
To: xianwei.zhao
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Jerome Brunet, Kevin Hilman, Greg Kroah-Hartman, Jiri Slaby,
devicetree, linux-kernel, linux-arm-kernel, linux-amlogic,
linux-serial
In-Reply-To: <20240401-basic_dt-v3-3-cb29ae1c16da@amlogic.com>
On Mon, Apr 1, 2024 at 12:10 PM Xianwei Zhao via B4 Relay
<devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>
> From: Xianwei Zhao <xianwei.zhao@amlogic.com>
>
> Amlogic A4 SoCs uses the same UART controller as S4 SoCs and G12A.
> There is no need for an extra compatible line in the driver, but
> add A4 compatible line for documentation.
>
> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
^ permalink raw reply
* Re: (subset) [PATCH v2 00/11] spi: cadence-qspi: add Mobileye EyeQ5 support
From: Mark Brown @ 2024-04-08 17:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vaishnav Achath,
Thomas Bogendoerfer, Rob Herring, Théo Lebrun
Cc: linux-spi, devicetree, linux-kernel, linux-mips,
Vladimir Kondratiev, Gregory CLEMENT, Thomas Petazzoni,
Tawfik Bayouk, Krzysztof Kozlowski
In-Reply-To: <20240405-cdns-qspi-mbly-v2-0-956679866d6d@bootlin.com>
On Fri, 05 Apr 2024 17:02:10 +0200, Théo Lebrun wrote:
> V2 of this series adding octal SPI-NOR support to Mobileye EyeQ5
> platform. It has been tested on EyeQ5 hardware successfully.
> V1 cover letter [5] contains a brief summary of what gets added.
>
> There is no dependency except if you want zero errors in devicetree:
> system-controller series [3] for <&clocks> phandle.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next
Thanks!
[03/11] spi: cadence-qspi: allow building for MIPS
commit: 708eafeba9eec51c5bde8efef2a7c22d7113b771
[04/11] spi: cadence-qspi: store device data pointer in private struct
commit: dcc594aef1bf3a6a49b77ad2c0348d894b7cd956
[06/11] spi: cadence-qspi: minimise register accesses on each op if !DTR
commit: 563f8598cbc246a81d256e0e888dc085504caa90
[07/11] spi: cadence-qspi: add no-IRQ mode to indirect reads
(no commit info)
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [RESEND v3 0/2] Add support for QCM6490 and QCS6490
From: Mark Brown @ 2024-04-08 17:59 UTC (permalink / raw)
To: Srinivas Kandagatla, Banajit Goswami, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
Mohammad Rafi Shaik
Cc: linux-arm-msm, alsa-devel, linux-sound, devicetree, linux-kernel,
quic_rohkumar
In-Reply-To: <20240408042331.403103-1-quic_mohs@quicinc.com>
On Mon, 08 Apr 2024 09:53:29 +0530, 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.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: dt-bindings: qcom,sm8250: Add QCM6490 snd QCS6490 sound card
commit: c64c4e3f789123e82ffae3404d108cf826c9599a
[2/2] ASoC: qcom: sc8280xp: Add support for QCM6490 and QCS6490
commit: 5485c3fa96f78314207a30e81dbe270424d70ede
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v2 3/6] firmware: arm_scmi: add initial support for i.MX BBM protocol
From: Cristian Marussi @ 2024-04-08 18:04 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Sudeep Holla, Peng Fan, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240405-imx95-bbm-misc-v2-v2-3-9fc9186856c2@nxp.com>
On Fri, Apr 05, 2024 at 08:39:25PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> The i.MX BBM protocol is for managing i.MX BBM module which provides
> RTC and BUTTON feature.
>
Hi,
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/firmware/arm_scmi/Kconfig | 10 +
> drivers/firmware/arm_scmi/Makefile | 1 +
> drivers/firmware/arm_scmi/imx-sm-bbm.c | 378 +++++++++++++++++++++++++++++++++
> include/linux/scmi_imx_protocol.h | 45 ++++
> 4 files changed, 434 insertions(+)
>
> diff --git a/drivers/firmware/arm_scmi/Kconfig b/drivers/firmware/arm_scmi/Kconfig
> index aa5842be19b2..56d11c9d9f47 100644
> --- a/drivers/firmware/arm_scmi/Kconfig
> +++ b/drivers/firmware/arm_scmi/Kconfig
> @@ -181,3 +181,13 @@ config ARM_SCMI_POWER_CONTROL
> early shutdown/reboot SCMI requests.
>
> endmenu
> +
> +config IMX_SCMI_BBM_EXT
> + tristate "i.MX SCMI BBM EXTENSION"
> + depends on ARM_SCMI_PROTOCOL || (COMPILE_TEST && OF)
> + default y if ARCH_MXC
> + help
> + This enables i.MX System BBM control logic which supports RTC
> + and BUTTON.
> +
> + This driver can also be built as a module.
> diff --git a/drivers/firmware/arm_scmi/Makefile b/drivers/firmware/arm_scmi/Makefile
> index a7bc4796519c..327687acf857 100644
> --- a/drivers/firmware/arm_scmi/Makefile
> +++ b/drivers/firmware/arm_scmi/Makefile
> @@ -11,6 +11,7 @@ scmi-transport-$(CONFIG_ARM_SCMI_HAVE_MSG) += msg.o
> scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_VIRTIO) += virtio.o
> scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_OPTEE) += optee.o
> scmi-protocols-y = base.o clock.o perf.o power.o reset.o sensors.o system.o voltage.o powercap.o
> +scmi-protocols-$(CONFIG_IMX_SCMI_BBM_EXT) += imx-sm-bbm.o
> scmi-module-objs := $(scmi-driver-y) $(scmi-protocols-y) $(scmi-transport-y)
>
> obj-$(CONFIG_ARM_SCMI_PROTOCOL) += scmi-core.o
> diff --git a/drivers/firmware/arm_scmi/imx-sm-bbm.c b/drivers/firmware/arm_scmi/imx-sm-bbm.c
> new file mode 100644
> index 000000000000..92c0aedf65cc
> --- /dev/null
> +++ b/drivers/firmware/arm_scmi/imx-sm-bbm.c
> @@ -0,0 +1,378 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * System Control and Management Interface (SCMI) NXP BBM Protocol
> + *
> + * Copyright 2024 NXP
> + */
> +
> +#define pr_fmt(fmt) "SCMI Notifications BBM - " fmt
> +
> +#include <linux/bits.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/scmi_protocol.h>
> +#include <linux/scmi_imx_protocol.h>
> +
> +#include "protocols.h"
> +#include "notify.h"
> +
> +#define SCMI_PROTOCOL_SUPPORTED_VERSION 0x10000
> +
I appreciate that you added versioning but I think a bit of documentation
about what the protocol and its comamnds purpose is still lacking, as asked
by Sudeep previously
https://lore.kernel.org/linux-arm-kernel/ZeGtoJ7ztSe8Kg8R@bogus/#t
> +enum scmi_imx_bbm_protocol_cmd {
> + IMX_BBM_GPR_SET = 0x3,
> + IMX_BBM_GPR_GET = 0x4,
> + IMX_BBM_RTC_ATTRIBUTES = 0x5,
> + IMX_BBM_RTC_TIME_SET = 0x6,
> + IMX_BBM_RTC_TIME_GET = 0x7,
> + IMX_BBM_RTC_ALARM_SET = 0x8,
> + IMX_BBM_BUTTON_GET = 0x9,
> + IMX_BBM_RTC_NOTIFY = 0xA,
> + IMX_BBM_BUTTON_NOTIFY = 0xB,
> +};
> +
> +#define GET_RTCS_NR(x) le32_get_bits((x), GENMASK(23, 16))
> +#define GET_GPRS_NR(x) le32_get_bits((x), GENMASK(15, 0))
> +
> +#define SCMI_IMX_BBM_NOTIFY_RTC_UPDATED BIT(2)
> +#define SCMI_IMX_BBM_NOTIFY_RTC_ROLLOVER BIT(1)
> +#define SCMI_IMX_BBM_NOTIFY_RTC_ALARM BIT(0)
> +
> +#define SCMI_IMX_BBM_RTC_ALARM_ENABLE_FLAG BIT(0)
> +
> +#define SCMI_IMX_BBM_NOTIFY_RTC_FLAG \
> + (SCMI_IMX_BBM_NOTIFY_RTC_UPDATED | SCMI_IMX_BBM_NOTIFY_RTC_ROLLOVER | \
> + SCMI_IMX_BBM_NOTIFY_RTC_ALARM)
> +
> +#define SCMI_IMX_BBM_EVENT_RTC_MASK GENMASK(31, 24)
> +
> +struct scmi_imx_bbm_info {
> + u32 version;
> + int nr_rtc;
> + int nr_gpr;
> +};
> +
> +struct scmi_msg_imx_bbm_protocol_attributes {
> + __le32 attributes;
> +};
> +
> +struct scmi_imx_bbm_set_time {
> + __le32 id;
> + __le32 flags;
> + __le32 value_low;
> + __le32 value_high;
> +};
> +
> +struct scmi_imx_bbm_get_time {
> + __le32 id;
> + __le32 flags;
> +};
> +
> +struct scmi_imx_bbm_alarm_time {
> + __le32 id;
> + __le32 flags;
> + __le32 value_low;
> + __le32 value_high;
> +};
> +
> +struct scmi_msg_imx_bbm_rtc_notify {
> + __le32 rtc_id;
> + __le32 flags;
> +};
> +
> +struct scmi_msg_imx_bbm_button_notify {
> + __le32 flags;
> +};
> +
> +struct scmi_imx_bbm_notify_payld {
> + __le32 flags;
> +};
> +
> +static int scmi_imx_bbm_attributes_get(const struct scmi_protocol_handle *ph,
> + struct scmi_imx_bbm_info *pi)
> +{
> + int ret;
> + struct scmi_xfer *t;
> + struct scmi_msg_imx_bbm_protocol_attributes *attr;
> +
> + ret = ph->xops->xfer_get_init(ph, PROTOCOL_ATTRIBUTES, 0, sizeof(*attr), &t);
> + if (ret)
> + return ret;
> +
> + attr = t->rx.buf;
> +
> + ret = ph->xops->do_xfer(ph, t);
> + if (!ret) {
> + pi->nr_rtc = GET_RTCS_NR(attr->attributes);
> + pi->nr_gpr = GET_GPRS_NR(attr->attributes);
> + }
> +
> + ph->xops->xfer_put(ph, t);
> +
> + return ret;
> +}
> +
> +static int scmi_imx_bbm_notify(const struct scmi_protocol_handle *ph,
> + u32 src_id, int message_id, bool enable)
> +{
> + int ret;
> + struct scmi_xfer *t;
> +
> + if (message_id == IMX_BBM_RTC_NOTIFY) {
> + struct scmi_msg_imx_bbm_rtc_notify *rtc_notify;
> +
> + ret = ph->xops->xfer_get_init(ph, message_id,
> + sizeof(*rtc_notify), 0, &t);
> + if (ret)
> + return ret;
> +
> + rtc_notify = t->tx.buf;
> + rtc_notify->rtc_id = cpu_to_le32(0);
> + rtc_notify->flags =
> + cpu_to_le32(enable ? SCMI_IMX_BBM_NOTIFY_RTC_FLAG : 0);
> + } else if (message_id == IMX_BBM_BUTTON_NOTIFY) {
> + struct scmi_msg_imx_bbm_button_notify *button_notify;
> +
> + ret = ph->xops->xfer_get_init(ph, message_id,
> + sizeof(*button_notify), 0, &t);
> + if (ret)
> + return ret;
> +
> + button_notify = t->tx.buf;
> + button_notify->flags = cpu_to_le32(enable ? 1 : 0);
> + } else {
> + return -EINVAL;
> + }
> +
> + ret = ph->xops->do_xfer(ph, t);
> +
> + ph->xops->xfer_put(ph, t);
> + return ret;
> +}
> +
> +static enum scmi_imx_bbm_protocol_cmd evt_2_cmd[] = {
> + IMX_BBM_RTC_NOTIFY,
> + IMX_BBM_BUTTON_NOTIFY
> +};
> +
> +static int scmi_imx_bbm_set_notify_enabled(const struct scmi_protocol_handle *ph,
> + u8 evt_id, u32 src_id, bool enable)
> +{
> + int ret, cmd_id;
> +
> + if (evt_id >= ARRAY_SIZE(evt_2_cmd))
> + return -EINVAL;
> +
> + cmd_id = evt_2_cmd[evt_id];
> + ret = scmi_imx_bbm_notify(ph, src_id, cmd_id, enable);
> + if (ret)
> + pr_debug("FAIL_ENABLED - evt[%X] dom[%d] - ret:%d\n",
> + evt_id, src_id, ret);
> +
> + return ret;
> +}
> +
> +static void *scmi_imx_bbm_fill_custom_report(const struct scmi_protocol_handle *ph,
> + u8 evt_id, ktime_t timestamp,
> + const void *payld, size_t payld_sz,
> + void *report, u32 *src_id)
> +{
> + const struct scmi_imx_bbm_notify_payld *p = payld;
> + struct scmi_imx_bbm_notif_report *r = report;
> +
> + if (sizeof(*p) != payld_sz)
> + return NULL;
> +
> + if (evt_id == SCMI_EVENT_IMX_BBM_RTC) {
> + r->is_rtc = true;
> + r->is_button = false;
> + r->timestamp = timestamp;
> + r->rtc_id = le32_get_bits(p->flags, SCMI_IMX_BBM_EVENT_RTC_MASK);
> + r->rtc_evt = le32_get_bits(p->flags, SCMI_IMX_BBM_NOTIFY_RTC_FLAG);
> + dev_dbg(ph->dev, "RTC: %d evt: %x\n", r->rtc_id, r->rtc_evt);
> + *src_id = r->rtc_evt;
> + } else if (evt_id == SCMI_EVENT_IMX_BBM_BUTTON) {
> + r->is_rtc = false;
> + r->is_button = true;
> + r->timestamp = timestamp;
> + dev_dbg(ph->dev, "BBM Button\n");
> + *src_id = 0;
> + } else {
> + WARN_ON_ONCE(1);
> + return NULL;
> + }
> +
> + return r;
> +}
> +
> +static const struct scmi_event scmi_imx_bbm_events[] = {
> + {
> + .id = SCMI_EVENT_IMX_BBM_RTC,
> + .max_payld_sz = sizeof(struct scmi_imx_bbm_notify_payld),
> + .max_report_sz = sizeof(struct scmi_imx_bbm_notif_report),
> + },
> + {
> + .id = SCMI_EVENT_IMX_BBM_BUTTON,
> + .max_payld_sz = sizeof(struct scmi_imx_bbm_notify_payld),
> + .max_report_sz = sizeof(struct scmi_imx_bbm_notif_report),
> + },
> +};
> +
> +static const struct scmi_event_ops scmi_imx_bbm_event_ops = {
> + .set_notify_enabled = scmi_imx_bbm_set_notify_enabled,
> + .fill_custom_report = scmi_imx_bbm_fill_custom_report,
> +};
> +
> +static const struct scmi_protocol_events scmi_imx_bbm_protocol_events = {
> + .queue_sz = SCMI_PROTO_QUEUE_SZ,
> + .ops = &scmi_imx_bbm_event_ops,
> + .evts = scmi_imx_bbm_events,
> + .num_events = ARRAY_SIZE(scmi_imx_bbm_events),
> + .num_sources = 1,
> +};
> +
> +static int scmi_imx_bbm_protocol_init(const struct scmi_protocol_handle *ph)
> +{
> + u32 version;
> + int ret;
> + struct scmi_imx_bbm_info *binfo;
> +
> + ret = ph->xops->version_get(ph, &version);
> + if (ret)
> + return ret;
> +
> + dev_info(ph->dev, "NXP SM BBM Version %d.%d\n",
> + PROTOCOL_REV_MAJOR(version), PROTOCOL_REV_MINOR(version));
> +
> + binfo = devm_kzalloc(ph->dev, sizeof(*binfo), GFP_KERNEL);
> + if (!binfo)
> + return -ENOMEM;
> +
> + ret = scmi_imx_bbm_attributes_get(ph, binfo);
> + if (ret)
> + return ret;
> +
> + return ph->set_priv(ph, binfo, version);
> +}
> +
> +static int scmi_imx_bbm_rtc_time_set(const struct scmi_protocol_handle *ph,
> + u32 rtc_id, u64 sec)
> +{
> + struct scmi_imx_bbm_info *pi = ph->get_priv(ph);
> + struct scmi_imx_bbm_set_time *cfg;
> + struct scmi_xfer *t;
> + int ret;
> +
> + if (rtc_id >= pi->nr_rtc)
> + return -EINVAL;
> +
> + ret = ph->xops->xfer_get_init(ph, IMX_BBM_RTC_TIME_SET, sizeof(*cfg), 0, &t);
> + if (ret)
> + return ret;
> +
> + cfg = t->tx.buf;
> + cfg->id = cpu_to_le32(rtc_id);
> + cfg->flags = 0;
> + cfg->value_low = lower_32_bits(sec);
> + cfg->value_high = upper_32_bits(sec);
Sorry I may have not been clear on this, but when I mentioned lower/upper
helpers I did not mean that they solved ALSO the endianity problem, so I
suppose that after having chunked your 64bits value in 2, you still want
to transmit it as 2 LE quantity....this is generally the expectation for
SCMI payloads...in this case any available documentation about the
expected command layout would have helped...
> +
> + ret = ph->xops->do_xfer(ph, t);
> +
> + ph->xops->xfer_put(ph, t);
> +
> + return ret;
> +}
> +
> +static int scmi_imx_bbm_rtc_time_get(const struct scmi_protocol_handle *ph,
> + u32 rtc_id, u64 *value)
> +{
> + struct scmi_imx_bbm_info *pi = ph->get_priv(ph);
> + struct scmi_imx_bbm_get_time *cfg;
> + struct scmi_xfer *t;
> + int ret;
> +
> + if (rtc_id >= pi->nr_rtc)
> + return -EINVAL;
> +
> + ret = ph->xops->xfer_get_init(ph, IMX_BBM_RTC_TIME_GET, sizeof(*cfg),
> + sizeof(u64), &t);
> + if (ret)
> + return ret;
> +
> + cfg = t->tx.buf;
> + cfg->id = cpu_to_le32(rtc_id);
> + cfg->flags = 0;
> +
> + ret = ph->xops->do_xfer(ph, t);
> + if (!ret)
> + *value = get_unaligned_le64(t->rx.buf);
> +
> + ph->xops->xfer_put(ph, t);
> +
> + return ret;
> +}
> +
> +static int scmi_imx_bbm_rtc_alarm_set(const struct scmi_protocol_handle *ph,
> + u32 rtc_id, u64 sec)
> +{
> + struct scmi_imx_bbm_info *pi = ph->get_priv(ph);
> + struct scmi_imx_bbm_alarm_time *cfg;
> + struct scmi_xfer *t;
> + int ret;
> +
> + if (rtc_id >= pi->nr_rtc)
> + return -EINVAL;
> +
> + ret = ph->xops->xfer_get_init(ph, IMX_BBM_RTC_ALARM_SET, sizeof(*cfg), 0, &t);
> + if (ret)
> + return ret;
> +
> + cfg = t->tx.buf;
> + cfg->id = cpu_to_le32(rtc_id);
> + cfg->flags = SCMI_IMX_BBM_RTC_ALARM_ENABLE_FLAG;
> + cfg->value_low = lower_32_bits(sec);
> + cfg->value_high = upper_32_bits(sec);
Same.
Thanks,
Cristian
^ 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