* [PATCH v2 04/10] arm64: dts: microchip: sparx5_pcb135: add missing I2C mux unit addresses
From: Krzysztof Kozlowski @ 2024-04-05 19:04 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
Cc: horatiu.vultur, steen.hegelund, Krzysztof Kozlowski
In-Reply-To: <20240405190419.74162-1-krzk@kernel.org>
The children of I2C mux should be named "i2c", according to DT schema
and bindings, and they should have unit address.
This fixes dtbs_check warnings like:
sparx5_pcb135.dtb: i2c0-imux@0: Unevaluated properties are not allowed ('#address-cells', '#size-cells', 'i2c_sfp1', 'i2c_sfp2', 'i2c_sfp3', 'i2c_sfp4' were unexpected)
and dtc W=1 warnings:
sparx5_pcb135_board.dtsi:172.23-180.4: Warning (simple_bus_reg): /axi@600000000/sfp-eth60: missing or empty reg/ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes in v2:
1. None
---
arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
index 82ce007d9959..bf51a6e11cf1 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
@@ -146,22 +146,22 @@ &i2c0_imux {
pinctrl-2 = <&i2cmux_s31>;
pinctrl-3 = <&i2cmux_s32>;
pinctrl-4 = <&i2cmux_pins_i>;
- i2c_sfp1: i2c_sfp1 {
+ i2c_sfp1: i2c@0 {
reg = <0x0>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp2: i2c_sfp2 {
+ i2c_sfp2: i2c@1 {
reg = <0x1>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp3: i2c_sfp3 {
+ i2c_sfp3: i2c@2 {
reg = <0x2>;
#address-cells = <1>;
#size-cells = <0>;
};
- i2c_sfp4: i2c_sfp4 {
+ i2c_sfp4: i2c@3 {
reg = <0x3>;
#address-cells = <1>;
#size-cells = <0>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 05/10] arm64: dts: microchip: sparx5_pcb134: align I2C mux node name with bindings
From: Krzysztof Kozlowski @ 2024-04-05 19:04 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
Cc: horatiu.vultur, steen.hegelund, Krzysztof Kozlowski
In-Reply-To: <20240405190419.74162-1-krzk@kernel.org>
DT schema expects node names to match certain. This fixes dtbs_check
warnings like:
sparx5_pcb134_emmc.dtb: i2c0-emux@0: $nodename:0: 'i2c0-emux@0' does not match '^(i2c-?)?mux'
and dtc W=1 warnings:
sparx5_pcb134_board.dtsi:398.25-403.4: Warning (unique_unit_address_if_enabled): /axi@600000000/i2c0-imux@0: duplicate unit-address (also used in node /axi@600000000/i2c0-emux@0)
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes in v2:
1. None
---
arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
index e816e6e9d62d..cafec6ef0d0f 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
@@ -395,13 +395,13 @@ i2cmux_11: i2cmux-11-pins {
};
&axi {
- i2c0_imux: i2c0-imux@0 {
+ i2c0_imux: i2c-mux-0 {
compatible = "i2c-mux-pinctrl";
#address-cells = <1>;
#size-cells = <0>;
i2c-parent = <&i2c0>;
};
- i2c0_emux: i2c0-emux@0 {
+ i2c0_emux: i2c-mux-1 {
compatible = "i2c-mux-gpio";
#address-cells = <1>;
#size-cells = <0>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 06/10] arm64: dts: microchip: sparx5_pcb135: align I2C mux node name with bindings
From: Krzysztof Kozlowski @ 2024-04-05 19:04 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
Cc: horatiu.vultur, steen.hegelund, Krzysztof Kozlowski
In-Reply-To: <20240405190419.74162-1-krzk@kernel.org>
DT schema expects node names to match certain. This fixes dtbs_check
warnings like:
sparx5_pcb135_emmc.dtb: i2c0-imux@0: $nodename:0: 'i2c0-imux@0' does not match '^(i2c-?)?mux'
and dtc W=1 warnings:
sparx5_pcb135_board.dtsi:132.25-137.4: Warning (simple_bus_reg): /axi@600000000/i2c0-imux@0: missing or empty reg/ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes in v2:
1. None
---
arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
index bf51a6e11cf1..860975ffe0a1 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
@@ -129,7 +129,7 @@ &sgpio2 {
};
&axi {
- i2c0_imux: i2c0-imux@0 {
+ i2c0_imux: i2c-mux {
compatible = "i2c-mux-pinctrl";
#address-cells = <1>;
#size-cells = <0>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 08/10] arm64: dts: microchip: sparx5_pcb135: drop LED unit addresses
From: Krzysztof Kozlowski @ 2024-04-05 19:04 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
Cc: horatiu.vultur, steen.hegelund, Krzysztof Kozlowski
In-Reply-To: <20240405190419.74162-1-krzk@kernel.org>
GPIO leds should not have unit addresses (no "reg" property), as
reported by dtc W=1 warnings:
sparx5_pcb135_board.dtsi:18.9-22.5: Warning (unit_address_vs_reg): /leds/led@0: node has a unit name, but no reg or ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes in v2:
1. None
---
.../boot/dts/microchip/sparx5_pcb135_board.dtsi | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
index 860975ffe0a1..20016efb3656 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
@@ -15,42 +15,42 @@ gpio-restart {
leds {
compatible = "gpio-leds";
- led@0 {
+ led-0 {
label = "eth60:yellow";
gpios = <&sgpio_out1 28 0 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@1 {
+ led-1 {
label = "eth60:green";
gpios = <&sgpio_out1 28 1 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@2 {
+ led-2 {
label = "eth61:yellow";
gpios = <&sgpio_out1 29 0 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@3 {
+ led-3 {
label = "eth61:green";
gpios = <&sgpio_out1 29 1 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@4 {
+ led-4 {
label = "eth62:yellow";
gpios = <&sgpio_out1 30 0 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@5 {
+ led-5 {
label = "eth62:green";
gpios = <&sgpio_out1 30 1 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@6 {
+ led-6 {
label = "eth63:yellow";
gpios = <&sgpio_out1 31 0 GPIO_ACTIVE_LOW>;
default-state = "off";
};
- led@7 {
+ led-7 {
label = "eth63:green";
gpios = <&sgpio_out1 31 1 GPIO_ACTIVE_LOW>;
default-state = "off";
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 07/10] arm64: dts: microchip: sparx5_pcb134: drop LED unit addresses
From: Krzysztof Kozlowski @ 2024-04-05 19:04 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
Cc: horatiu.vultur, steen.hegelund, Krzysztof Kozlowski
In-Reply-To: <20240405190419.74162-1-krzk@kernel.org>
GPIO leds should not have unit addresses (no "reg" property), as
reported by dtc W=1 warnings:
sparx5_pcb134_board.dtsi:18.9-21.5: Warning (unit_address_vs_reg): /leds/led@0: node has a unit name, but no reg or ranges property
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes in v2:
1. None
---
.../dts/microchip/sparx5_pcb134_board.dtsi | 96 +++++++++----------
1 file changed, 48 insertions(+), 48 deletions(-)
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
index cafec6ef0d0f..f165a409bc1d 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
@@ -15,234 +15,234 @@ gpio-restart {
leds {
compatible = "gpio-leds";
- led@0 {
+ led-0 {
label = "twr0:green";
gpios = <&sgpio_out0 8 0 GPIO_ACTIVE_LOW>;
};
- led@1 {
+ led-1 {
label = "twr0:yellow";
gpios = <&sgpio_out0 8 1 GPIO_ACTIVE_LOW>;
};
- led@2 {
+ led-2 {
label = "twr1:green";
gpios = <&sgpio_out0 9 0 GPIO_ACTIVE_LOW>;
};
- led@3 {
+ led-3 {
label = "twr1:yellow";
gpios = <&sgpio_out0 9 1 GPIO_ACTIVE_LOW>;
};
- led@4 {
+ led-4 {
label = "twr2:green";
gpios = <&sgpio_out0 10 0 GPIO_ACTIVE_LOW>;
};
- led@5 {
+ led-5 {
label = "twr2:yellow";
gpios = <&sgpio_out0 10 1 GPIO_ACTIVE_LOW>;
};
- led@6 {
+ led-6 {
label = "twr3:green";
gpios = <&sgpio_out0 11 0 GPIO_ACTIVE_LOW>;
};
- led@7 {
+ led-7 {
label = "twr3:yellow";
gpios = <&sgpio_out0 11 1 GPIO_ACTIVE_LOW>;
};
- led@8 {
+ led-8 {
label = "eth12:green";
gpios = <&sgpio_out0 12 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@9 {
+ led-9 {
label = "eth12:yellow";
gpios = <&sgpio_out0 12 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@10 {
+ led-10 {
label = "eth13:green";
gpios = <&sgpio_out0 13 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@11 {
+ led-11 {
label = "eth13:yellow";
gpios = <&sgpio_out0 13 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@12 {
+ led-12 {
label = "eth14:green";
gpios = <&sgpio_out0 14 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@13 {
+ led-13 {
label = "eth14:yellow";
gpios = <&sgpio_out0 14 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@14 {
+ led-14 {
label = "eth15:green";
gpios = <&sgpio_out0 15 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@15 {
+ led-15 {
label = "eth15:yellow";
gpios = <&sgpio_out0 15 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@16 {
+ led-16 {
label = "eth48:green";
gpios = <&sgpio_out1 16 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@17 {
+ led-17 {
label = "eth48:yellow";
gpios = <&sgpio_out1 16 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@18 {
+ led-18 {
label = "eth49:green";
gpios = <&sgpio_out1 17 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@19 {
+ led-19 {
label = "eth49:yellow";
gpios = <&sgpio_out1 17 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@20 {
+ led-20 {
label = "eth50:green";
gpios = <&sgpio_out1 18 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@21 {
+ led-21 {
label = "eth50:yellow";
gpios = <&sgpio_out1 18 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@22 {
+ led-22 {
label = "eth51:green";
gpios = <&sgpio_out1 19 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@23 {
+ led-23 {
label = "eth51:yellow";
gpios = <&sgpio_out1 19 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@24 {
+ led-24 {
label = "eth52:green";
gpios = <&sgpio_out1 20 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@25 {
+ led-25 {
label = "eth52:yellow";
gpios = <&sgpio_out1 20 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@26 {
+ led-26 {
label = "eth53:green";
gpios = <&sgpio_out1 21 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@27 {
+ led-27 {
label = "eth53:yellow";
gpios = <&sgpio_out1 21 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@28 {
+ led-28 {
label = "eth54:green";
gpios = <&sgpio_out1 22 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@29 {
+ led-29 {
label = "eth54:yellow";
gpios = <&sgpio_out1 22 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@30 {
+ led-30 {
label = "eth55:green";
gpios = <&sgpio_out1 23 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@31 {
+ led-31 {
label = "eth55:yellow";
gpios = <&sgpio_out1 23 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@32 {
+ led-32 {
label = "eth56:green";
gpios = <&sgpio_out1 24 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@33 {
+ led-33 {
label = "eth56:yellow";
gpios = <&sgpio_out1 24 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@34 {
+ led-34 {
label = "eth57:green";
gpios = <&sgpio_out1 25 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@35 {
+ led-35 {
label = "eth57:yellow";
gpios = <&sgpio_out1 25 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@36 {
+ led-36 {
label = "eth58:green";
gpios = <&sgpio_out1 26 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@37 {
+ led-37 {
label = "eth58:yellow";
gpios = <&sgpio_out1 26 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@38 {
+ led-38 {
label = "eth59:green";
gpios = <&sgpio_out1 27 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@39 {
+ led-39 {
label = "eth59:yellow";
gpios = <&sgpio_out1 27 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@40 {
+ led-40 {
label = "eth60:green";
gpios = <&sgpio_out1 28 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@41 {
+ led-41 {
label = "eth60:yellow";
gpios = <&sgpio_out1 28 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@42 {
+ led-42 {
label = "eth61:green";
gpios = <&sgpio_out1 29 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@43 {
+ led-43 {
label = "eth61:yellow";
gpios = <&sgpio_out1 29 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@44 {
+ led-44 {
label = "eth62:green";
gpios = <&sgpio_out1 30 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@45 {
+ led-45 {
label = "eth62:yellow";
gpios = <&sgpio_out1 30 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@46 {
+ led-46 {
label = "eth63:green";
gpios = <&sgpio_out1 31 0 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
- led@47 {
+ led-47 {
label = "eth63:yellow";
gpios = <&sgpio_out1 31 1 GPIO_ACTIVE_HIGH>;
default-state = "off";
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [RFT PATCH v2 10/10] arm64: dts: microchip: sparx5_pcb135: drop duplicated NOR flash
From: Krzysztof Kozlowski @ 2024-04-05 19:04 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
Cc: horatiu.vultur, steen.hegelund, Krzysztof Kozlowski
In-Reply-To: <20240405190419.74162-1-krzk@kernel.org>
Since beginning the DTS extended the SPI0 in two places adding two SPI
muxes, each with same SPI NOR flash. Both used exactly the same
chip-selects, so this was clearly buggy code. Then in commit
d0f482bb06f9 ("arm64: dts: sparx5: Add the Sparx5 switch node") one SPI
mux was removed, while keeping the SPI NOR flash node.
This still leaves duplicated SPI nodes under same chip select 0,
reported by dtc W=1 warnings:
sparx5_pcb135_board.dtsi:92.10-96.4: Warning (unique_unit_address_if_enabled): /axi@600000000/spi@600104000/flash@0: duplicate unit-address (also used in node /axi@600000000/spi@600104000/spi@0)
Steen Hegelund confirmed that in fact there is a SPI mux, thus remove
the duplicated node without the mux.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Not tested on hardware
Changes in v2:
1. Remove SPI node without mux.
---
arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
index 20016efb3656..af2f1831f07f 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb135_board.dtsi
@@ -87,15 +87,6 @@ i2cmux_s32: i2cmux-3-pins {
};
};
-&spi0 {
- status = "okay";
- flash@0 {
- compatible = "jedec,spi-nor";
- spi-max-frequency = <8000000>;
- reg = <0>;
- };
-};
-
&spi0 {
status = "okay";
spi@0 {
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 1/2] serial: imx: Introduce timeout when waiting on transmitter empty
From: Sergey Organov @ 2024-04-05 19:05 UTC (permalink / raw)
To: Fabio Estevam
Cc: Esben Haabendal, Greg Kroah-Hartman, Jiri Slaby, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Marc Kleine-Budde,
linux-kernel, linux-serial, imx, linux-arm-kernel
In-Reply-To: <CAOMZO5Axz7un+9H2uEoQtE0=pYNC0hEyZiNobrSi2m0ajj8N+g@mail.gmail.com>
Fabio Estevam <festevam@gmail.com> writes:
> On Fri, Apr 5, 2024 at 6:25 AM Esben Haabendal <esben@geanix.com> wrote:
>>
>> By waiting at most 1 second for USR2_TXDC to be set, we avoid a potentital
>
> s/potentital/potential
>
> Could you elaborate on this deadlock? Have you seen it in practice?
I've stumped upon this piece of code a long time ago, and it's indeed
broken. However, to actually see a "deadlock", I believe one needs to
enable hardware RTS/CTS handshake on the port, then, say, not connect
RS232 cable, and then printk(), if enabled to this port, will soon
result in the loop to be executed forever, that in turn will hang
single-CPU machine entirely (provided this code is still executed with
interrupts disabled, as it was at the time I investigated severe
printk()-induced ISR delays).
-- Sergey Organov
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net] net: sparx5: fix reconfiguration of PCS on link mode change
From: Daniel Machon @ 2024-04-05 19:45 UTC (permalink / raw)
To: Russell King (Oracle)
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Lars Povlsen, Steen Hegelund, UNGLinuxDriver, Bjarni Jonasson,
netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <Zg/Qf4P5gAzRUYuK@shell.armlinux.org.uk>
Hi Russel,
> > It was observed that the PCS would be misconfigured on link mode change,
> > if the negotiated link mode went from no-inband capabilities to in-band
> > capabilities. This bug appeared after the neg_mode change of phylink [1],
> > but is really due to the wrong config being used when reconfiguring the PCS.
>
> I don't see how the change you point to could have changed the
> behaviour. Old code:
>
> conf.inband = phylink_autoneg_inband(mode);
> conf.autoneg = phylink_test(advertising, Autoneg);
>
> New code:
>
> conf.inband = neg_mode == PHYLINK_PCS_NEG_INBAND_DISABLED ||
> neg_mode == PHYLINK_PCS_NEG_INBAND_ENABLED;
> conf.autoneg = neg_mode == PHYLINK_PCS_NEG_INBAND_ENABLED;
>
> where, for SGMII or 802.3z modes, neg_mode will be one of
> PHYLINK_PCS_NEG_INBAND_DISABLED or PHYLINK_PCS_NEG_INBAND_ENABLED if
> phylink_autoneg_inband(mode) is true, or PHYLINK_PCS_NEG_OUTBAND if
> not.
For inband/10GBase-R, conf.inband would be true, prior to the
phylink change. This is fine since conf.inband is only used when
configuring low speed devices.
After the change, conf.inband will be false when opting in through
phylink_pcs.net_mode = true. This causes the SGMII to be misconfigured,
since the inband parameter from the old config is used, and that
parameter is actually used for configuring SGMII..
TBH the commit description is inadequate at best. I will revise it in a
v2.
>
> It does change conf.autoneg slightly in that this will always be true
> for SGMII, but will only be true for Autoneg + 802.3z modes.
>
> As far as your code change goes, it looks correct to me, but I think
> it's fixing a bug that goes back long before the commit you have
> identified.
Just to be clear - by commit do you mean the phylink change or the commit
referenced in the fixes tag?
>
> However, I think there's another issue here which is more relevant to
> the problem you describe in your commit message. If you look at
> port_conf_has_changed(), you will notice that it fails to compare
> conf.inband, and thus fails to notice any change in the setting of
> that configuration item. This will result in sparx5_port_pcs_set()
> not even being called if only conf.inband changes state.
>
> Thus, changing from in-band to out-of-band or vice versa won't have
> any effect if this is the only change that occurs, and this also
> exists prior to my change.
Yes. I agree this is an issue that deserves a fix - separate from this
one I would think.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net] net: sparx5: fix reconfiguration of PCS on link mode change
From: Russell King (Oracle) @ 2024-04-05 20:05 UTC (permalink / raw)
To: Daniel Machon
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Lars Povlsen, Steen Hegelund, UNGLinuxDriver, Bjarni Jonasson,
netdev, linux-arm-kernel, linux-kernel
In-Reply-To: <20240405194556.ngto6ddgf5r2br33@DEN-DL-M70577>
On Fri, Apr 05, 2024 at 07:45:56PM +0000, Daniel Machon wrote:
> Hi Russel,
>
> > It does change conf.autoneg slightly in that this will always be true
> > for SGMII, but will only be true for Autoneg + 802.3z modes.
> >
> > As far as your code change goes, it looks correct to me, but I think
> > it's fixing a bug that goes back long before the commit you have
> > identified.
>
> Just to be clear - by commit do you mean the phylink change or the commit
> referenced in the fixes tag?
I think the bug technically exists prior to the phylink change if
there is any possibility that the link may switch between inband
and a non-inband mode. (e.g. as a result of inserting a SFP module.)
> > However, I think there's another issue here which is more relevant to
> > the problem you describe in your commit message. If you look at
> > port_conf_has_changed(), you will notice that it fails to compare
> > conf.inband, and thus fails to notice any change in the setting of
> > that configuration item. This will result in sparx5_port_pcs_set()
> > not even being called if only conf.inband changes state.
> >
> > Thus, changing from in-band to out-of-band or vice versa won't have
> > any effect if this is the only change that occurs, and this also
> > exists prior to my change.
>
> Yes. I agree this is an issue that deserves a fix - separate from this
> one I would think.
Agreed, thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [RFT PATCH v2 09/10] arm64: dts: microchip: sparx5_pcb134: drop duplicated NOR flash
From: Krzysztof Kozlowski @ 2024-04-05 19:04 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
Cc: horatiu.vultur, steen.hegelund, Krzysztof Kozlowski
In-Reply-To: <20240405190419.74162-1-krzk@kernel.org>
Since beginning the DTS extended the SPI0 in two places adding two SPI
muxes, each with same SPI NOR flash. Both used exactly the same
chip-selects, so this was clearly buggy code. Then in commit
d0f482bb06f9 ("arm64: dts: sparx5: Add the Sparx5 switch node") one SPI
mux was removed, while keeping the SPI NOR flash node.
This still leaves duplicated SPI nodes under same chip select 0,
reported by dtc W=1 warnings:
sparx5_pcb134_board.dtsi:277.10-281.4: Warning (unique_unit_address_if_enabled): /axi@600000000/spi@600104000/flash@0: duplicate unit-address (also used in node /axi@600000000/spi@600104000/spi@0)
Steen Hegelund confirmed that in fact there is a SPI mux, thus remove
the duplicated node without the mux.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Not tested on hardware
Changes in v2:
1. Remove SPI node without mux.
---
arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
index f165a409bc1d..2c5574734c9e 100644
--- a/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5_pcb134_board.dtsi
@@ -272,15 +272,6 @@ gpio@1 {
};
};
-&spi0 {
- status = "okay";
- flash@0 {
- compatible = "jedec,spi-nor";
- spi-max-frequency = <8000000>;
- reg = <0>;
- };
-};
-
&spi0 {
status = "okay";
spi@0 {
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] arm64: dts: imx8mp: Fix assigned-clocks for second CSI2
From: Marek Vasut @ 2024-04-05 20:21 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Alexander Stein, Conor Dooley, Fabio Estevam,
Krzysztof Kozlowski, Pengutronix Kernel Team, Rob Herring,
Sascha Hauer, Shawn Guo, devicetree, imx
The first CSI2 pixel clock are supplied from IMX8MP_CLK_MEDIA_CAM1_PIX_ROOT,
the second CSI2 pixel clock are supplied from IMX8MP_CLK_MEDIA_CAM2_PIX_ROOT,
both clock are supplied from SYS_PLL2 and configured using assigned-clock DT
properties. Each CSI2 DT node configures its IMX8MP_CLK_MEDIA_CAMn_PIX_ROOT
clock. This used to be the case until likely a copy-paste error in commit
f78835d1e616 ("arm64: dts: imx8mp: reparent MEDIA_MIPI_PHY1_REF to CLK_24M")
which changed the second CSI2 node to configure IMX8MP_CLK_MEDIA_CAM1_PIX_ROOT
using its assigned-clocks property.
Fix the second CSI2 assigned-clock property back to the original correct
IMX8MP_CLK_MEDIA_CAM2_PIX_ROOT .
Fixes: f78835d1e616 ("arm64: dts: imx8mp: reparent MEDIA_MIPI_PHY1_REF to CLK_24M")
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Alexander Stein <alexander.stein@ew.tq-group.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
---
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 9f3e7c23b2efb..1bb96e96639f2 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -1699,7 +1699,7 @@ mipi_csi_1: csi@32e50000 {
<&clk IMX8MP_CLK_MEDIA_MIPI_PHY1_REF_ROOT>,
<&clk IMX8MP_CLK_MEDIA_AXI_ROOT>;
clock-names = "pclk", "wrap", "phy", "axi";
- assigned-clocks = <&clk IMX8MP_CLK_MEDIA_CAM1_PIX>,
+ assigned-clocks = <&clk IMX8MP_CLK_MEDIA_CAM2_PIX>,
<&clk IMX8MP_CLK_MEDIA_MIPI_PHY1_REF>;
assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_1000M>,
<&clk IMX8MP_CLK_24M>;
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] arm64: dts: imx8mp: Align both CSI2 pixel clock
From: Marek Vasut @ 2024-04-05 20:22 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Marek Vasut, Conor Dooley, Fabio Estevam, Krzysztof Kozlowski,
Laurent Pinchart, Paul Elder, Pengutronix Kernel Team,
Rob Herring, Sascha Hauer, Shawn Guo, devicetree, imx
Configure both CSI2 assigned-clock-rates the same way.
There does not seem to be any reason for keeping the
two CSI2 pixel clock set to different frequencies.
Signed-off-by: Marek Vasut <marex@denx.de>
---
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Paul Elder <paul.elder@ideasonboard.com>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: imx@lists.linux.dev
Cc: linux-arm-kernel@lists.infradead.org
---
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
index 1bb96e96639f2..2e9ce0c3a9815 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
@@ -1703,7 +1703,7 @@ mipi_csi_1: csi@32e50000 {
<&clk IMX8MP_CLK_MEDIA_MIPI_PHY1_REF>;
assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_1000M>,
<&clk IMX8MP_CLK_24M>;
- assigned-clock-rates = <266000000>;
+ assigned-clock-rates = <500000000>;
power-domains = <&media_blk_ctrl IMX8MP_MEDIABLK_PD_MIPI_CSI2_2>;
status = "disabled";
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] arm64: dts: imx8mp: Align both CSI2 pixel clock
From: Laurent Pinchart @ 2024-04-05 20:42 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Fabio Estevam,
Krzysztof Kozlowski, Paul Elder, Pengutronix Kernel Team,
Rob Herring, Sascha Hauer, Shawn Guo, devicetree, imx, Adam Ford
In-Reply-To: <20240405202243.46278-1-marex@denx.de>
Hi Marek,
(CC'ing Adam)
Thank you for the patch.
On Fri, Apr 05, 2024 at 10:22:26PM +0200, Marek Vasut wrote:
> Configure both CSI2 assigned-clock-rates the same way.
> There does not seem to be any reason for keeping the
> two CSI2 pixel clock set to different frequencies.
There's an issue when using two cameras concurrently. This has been
discussed some time ago on the linux-media mailing list, see [1]. Adam
knows more than I do on this topic.
[1] https://lore.kernel.org/linux-media/CAHCN7x+kymRGO2kxvN2=zLiqRjfTc3hdf3VdNVkWjsW3La0bnA@mail.gmail.com/
> Signed-off-by: Marek Vasut <marex@denx.de>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Paul Elder <paul.elder@ideasonboard.com>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: imx@lists.linux.dev
> Cc: linux-arm-kernel@lists.infradead.org
> ---
> arch/arm64/boot/dts/freescale/imx8mp.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> index 1bb96e96639f2..2e9ce0c3a9815 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> @@ -1703,7 +1703,7 @@ mipi_csi_1: csi@32e50000 {
> <&clk IMX8MP_CLK_MEDIA_MIPI_PHY1_REF>;
> assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_1000M>,
> <&clk IMX8MP_CLK_24M>;
> - assigned-clock-rates = <266000000>;
> + assigned-clock-rates = <500000000>;
> power-domains = <&media_blk_ctrl IMX8MP_MEDIABLK_PD_MIPI_CSI2_2>;
> status = "disabled";
>
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8mp: Align both CSI2 pixel clock
From: Adam Ford @ 2024-04-05 21:04 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Marek Vasut, linux-arm-kernel, Conor Dooley, Fabio Estevam,
Krzysztof Kozlowski, Paul Elder, Pengutronix Kernel Team,
Rob Herring, Sascha Hauer, Shawn Guo, devicetree, imx
In-Reply-To: <20240405204251.GE12507@pendragon.ideasonboard.com>
On Fri, Apr 5, 2024 at 3:43 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> Hi Marek,
>
> (CC'ing Adam)
>
> Thank you for the patch.
>
> On Fri, Apr 05, 2024 at 10:22:26PM +0200, Marek Vasut wrote:
> > Configure both CSI2 assigned-clock-rates the same way.
> > There does not seem to be any reason for keeping the
> > two CSI2 pixel clock set to different frequencies.
>
> There's an issue when using two cameras concurrently. This has been
> discussed some time ago on the linux-media mailing list, see [1]. Adam
> knows more than I do on this topic.
>
> [1] https://lore.kernel.org/linux-media/CAHCN7x+kymRGO2kxvN2=zLiqRjfTc3hdf3VdNVkWjsW3La0bnA@mail.gmail.com/
>
> > Signed-off-by: Marek Vasut <marex@denx.de>
> > ---
> > Cc: Conor Dooley <conor+dt@kernel.org>
> > Cc: Fabio Estevam <festevam@gmail.com>
> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > Cc: Paul Elder <paul.elder@ideasonboard.com>
> > Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> > Cc: Rob Herring <robh@kernel.org>
> > Cc: Sascha Hauer <s.hauer@pengutronix.de>
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: devicetree@vger.kernel.org
> > Cc: imx@lists.linux.dev
> > Cc: linux-arm-kernel@lists.infradead.org
> > ---
> > arch/arm64/boot/dts/freescale/imx8mp.dtsi | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > index 1bb96e96639f2..2e9ce0c3a9815 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > @@ -1703,7 +1703,7 @@ mipi_csi_1: csi@32e50000 {
> > <&clk IMX8MP_CLK_MEDIA_MIPI_PHY1_REF>;
> > assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_1000M>,
> > <&clk IMX8MP_CLK_24M>;
> > - assigned-clock-rates = <266000000>;
> > + assigned-clock-rates = <500000000>;
I am traveling, so I don't have the technical documents in front of
me, but I beleive this is an over-drive speed, and 400MHz would be the
single clock, standard rate. I created an imx8mm-overdrive and
imx8mn-overdrive dtsi file to let users who operate in overdrive mode
to update their clocks in one place.
I also think this goes down if the user is running two cameras instead
of one. I re-read the old thread, and it's coming back to me, but
until I can get settled into my hotel in Germany, I won't have time to
review. I think the original idea was to use the lowest, conservative
value with the idea that people can tweak their clock settings if
they're only running one and if they are running in over-drive mode.
adam
> > power-domains = <&media_blk_ctrl IMX8MP_MEDIABLK_PD_MIPI_CSI2_2>;
> > status = "disabled";
> >
>
> --
> Regards,
>
> Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] arm64 fix for 6.9-rc3
From: pr-tracker-bot @ 2024-04-05 21:06 UTC (permalink / raw)
To: Catalin Marinas
Cc: Linus Torvalds, Will Deacon, linux-arm-kernel, linux-kernel
In-Reply-To: <ZhA9tWAmdQ0LGg8t@arm.com>
The pull request you sent on Fri, 5 Apr 2024 19:06:45 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c7830236d58e9e982f3e180f054cfbc14788beca
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 00/12] mm/gup: Unify hugetlb, part 2
From: Peter Xu @ 2024-04-05 21:42 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: linux-mm, linux-kernel, linuxppc-dev, Michael Ellerman,
Christophe Leroy, Matthew Wilcox, Rik van Riel, Lorenzo Stoakes,
Axel Rasmussen, Yang Shi, John Hubbard, linux-arm-kernel,
Kirill A . Shutemov, Andrew Jones, Vlastimil Babka, Mike Rapoport,
Andrew Morton, Muchun Song, Christoph Hellwig, linux-riscv,
James Houghton, David Hildenbrand, Andrea Arcangeli,
Aneesh Kumar K . V, Mike Kravetz
In-Reply-To: <20240405181633.GH5383@nvidia.com>
On Fri, Apr 05, 2024 at 03:16:33PM -0300, Jason Gunthorpe wrote:
> On Thu, Apr 04, 2024 at 05:48:03PM -0400, Peter Xu wrote:
> > On Tue, Mar 26, 2024 at 11:02:52AM -0300, Jason Gunthorpe wrote:
> > > The more I look at this the more I think we need to get to Matthew's
> > > idea of having some kind of generic page table API that is not tightly
> > > tied to level. Replacing the hugetlb trick of 'everything is a PTE'
> > > with 5 special cases in every place seems just horrible.
> > >
> > > struct mm_walk_ops {
> > > int (*leaf_entry)(struct mm_walk_state *state, struct mm_walk *walk);
> > > }
> > >
> > > And many cases really want something like:
> > > struct mm_walk_state state;
> > >
> > > if (!mm_walk_seek_leaf(state, mm, address))
> > > goto no_present
> > > if (mm_walk_is_write(state)) ..
> > >
> > > And detailed walking:
> > > for_each_pt_leaf(state, mm, address) {
> > > if (mm_walk_is_write(state)) ..
> > > }
> > >
> > > Replacing it with a mm_walk_state that retains the level or otherwise
> > > to allow decoding any entry composes a lot better. Forced Loop
> > > unrolling can get back to the current code gen in alot of places.
> > >
> > > It also makes the power stuff a bit nicer as the mm_walk_state could
> > > automatically retain back pointers to the higher levels in the state
> > > struct too...
> > >
> > > The puzzle is how to do it and still get reasonable efficient codegen,
> > > many operations are going to end up switching on some state->level to
> > > know how to decode the entry.
> >
> > These discussions are definitely constructive, thanks Jason. Very helpful.
> >
> > I thought about this last week but got interrupted. It does make sense to
> > me; it looks pretty generic and it is flexible enough as a top design. At
> > least that's what I thought.
>
> Yeah, exactly..
>
> > However now when I rethink about it, and look more into the code when I got
> > the chance, it turns out this will be a major rewrite of mostly every
> > walkers..
>
> Indeed, it is why it may not be reasonable.
>
> > Consider that what we (or.. I) want to teach the pXd layers are two things
> > right now: (1) hugetlb mappings (2) MMIO (PFN) mappings. That mostly
> > shares the generic concept when working on the mm walkers no matter which
> > way to go, just different treatment on different type of mem. (2) is on
> > top of current code and new stuff, while (1) is a refactoring to drop
> > hugetlb_entry() hook point as the goal.
>
> Right, I view this as a two pronged attack
>
> One one front you teach the generic pXX_* macros to process huge pages
> and push that around to the performance walkers like GUP
>
> On another front you want to replace use of the hugepte with the new
> walkers.
>
> The challenge with the hugepte code is that it is all structured to
> assume one API that works at all levels and that may be a hard fit to
> replace with pXX_* functions.
That's the core of problem, or otherwise I feel like I might be doing
something else already. I had a feeling even if it's currently efficient
for hugetlb, we'll drop that sooner or later.
The issue is at least hugetlb pgtable format is exactly the same as the
rest, as large folio grows it will reach the point that we complain more
than before on having hugetlb does its smart things on its own.
>
> The places that are easy to switch from hugetlb to pXX_* may as well
> do so.
>
> Other places maybe need a hugetlb replacement that has a similar
> abstraction level of pointing to any page table level.
IMHO this depends.
Per my current knowledge, hugetlb is only special in three forms:
- huge mapping (well, this isn't that special..)
- cont pte/pmd/...
- hugepd
The most fancy one is actually hugepd.. but I plan to put that temporarily
aside - I haven't look at Christophe's series yet, however I think we're
going to solve orthogonal issues but his work will definitely help me on
reaching mine, and I want to think through first on my end of things to
know a plan. If hugepd has its chance to be generalized, the worst case is
I'll leverage CONFIG_ARCH_HAS_HUGEPD and only keep hugetlb_entry() for them
until hugepd became some cont-pxx variance. Then when I put HAS_HUGEPD
aside, I don't think it's very complicated, perhaps?
In short, hugetlb mappings shouldn't be special comparing to other huge pXd
and large folio (cont-pXd) mappings for most of the walkers in my mind, if
not all. I need to look at all the walkers and there can be some tricky
ones, but I believe that applies in general. It's actually similar to what
I did with slow gup here.
Like this series, for cont-pXd we'll need multiple walks comparing to
before (when with hugetlb_entry()), but for that part I'll provide some
performance tests too, and we also have a fallback plan, which is to detect
cont-pXd existance, which will also work for large folios.
>
> I think if you do the easy places for pXX conversion you will have a
> good idea about what is needed for the hard places.
Here IMHO we don't need to understand "what is the size of this hugetlb
vma", or "which level of pgtable does this hugetlb vma pages locate",
because we may not need that, e.g., when we only want to collect some smaps
statistics. "whether it's hugetlb" may matter, though. E.g. in the mm
walker we see a huge pmd, it can be a thp, it can be a hugetlb (when
hugetlb_entry removed), we may need extra check later to put things into
the right bucket, but for the walker itself it doesn't necessarily need
hugetlb_entry().
>
> > Now the important question I'm asking myself is: do we really need huge p4d
> > or even bigger?
>
> Do we need huge p4d support with folios? Probably not..
>
> huge p4d support for pfnmap, eg in VFIO. Yes I think that is possibly
> interesting - but I wouldn't ask anyone to do the work :)
Considering it does not yet exist, and we don't have plan to work it out
(so far), maybe I can see this as a very implicit ack that I can put that
aside at least of now. :)
>
> But then again we come back to power and its big list of page sizes
> and variety :( Looks like some there have huge sizes at the pgd level
> at least.
Yeah this is something I want to be super clear, because I may miss
something: we don't have real pgd pages, right? Powerpc doesn't even
define p4d_leaf(), AFAICT.
$ git grep p4d_leaf
arch/powerpc/mm/book3s64/radix_pgtable.c: if (p4d_leaf(*p4d)) {
arch/powerpc/mm/pgtable.c: if (p4d_leaf(p4d)) {
arch/powerpc/mm/pgtable_64.c: if (p4d_leaf(p4d)) {
arch/powerpc/mm/pgtable_64.c: VM_WARN_ON(!p4d_leaf(p4d));
arch/powerpc/xmon/xmon.c: if (p4d_leaf(*p4dp)) {
They all constantly return false (which is the fallback)?
>
> > So, can we over-engineer too much if we go the generic route now?
>
> Yes we can, and it will probably be slow as well. The pXX macros are
> the most efficient if code can be adapted to use them.
>
> > Considering that we already have most of pmd/pud entries around in the mm
> > walker ops.
>
> Yeah, so you add pgd and maybe p4d and then we can don't need any
> generic thing. If it is easy it would be nice.
I want to double check on above on PowerPC first, otherwise I'd consider
leaving p4d+ alone, if that looks ok. It could be that I missed something
important, Christophe may want to chim in if he has any thoughts or just to
clarify my mistakes.
Thanks,
--
Peter Xu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 04/49] ARM: dts: imx53-kp: Drop redundant settings in pwm nodes
From: Uwe Kleine-König @ 2024-04-05 21:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer
Cc: Pengutronix Kernel Team, Fabio Estevam, devicetree, imx,
linux-arm-kernel, linux-kernel, Alexander Stein
In-Reply-To: <cover.1712352665.git.u.kleine-koenig@pengutronix.de>
imx53-kp.dtsi includes imx53-tqma53.dtsi which already sets #pwm-cells
to 2. So the two nodes can be dropped without resulting in any changes
in the compiled device tree blobs.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
arch/arm/boot/dts/nxp/imx/imx53-kp.dtsi | 8 --------
1 file changed, 8 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-kp.dtsi b/arch/arm/boot/dts/nxp/imx/imx53-kp.dtsi
index 4508f34139a0..8b25416a5303 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-kp.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx53-kp.dtsi
@@ -162,14 +162,6 @@ MX53_PAD_EIM_D20__GPIO3_20 0x1e4
>;
};
-&pwm1 {
- #pwm-cells = <2>;
-};
-
-&pwm2 {
- #pwm-cells = <2>;
-};
-
&uart1 {
status = "okay";
};
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 12/49] ARM: dts: imx6qdl-aristainetos2: Use #pwm-cells = <3> for imx27-pwm device
From: Uwe Kleine-König @ 2024-04-05 21:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer
Cc: Pengutronix Kernel Team, Fabio Estevam, devicetree, imx,
linux-arm-kernel, linux-kernel, Alexander Stein
In-Reply-To: <cover.1712352665.git.u.kleine-koenig@pengutronix.de>
The binding dictates using 3 pwm-cells. Adhere to that.
This fixes the following dtbs_check warnings:
arch/arm/boot/dts/nxp/imx/imx6dl-aristainetos2_4.dtb: pwm@2080000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
arch/arm/boot/dts/nxp/imx/imx6dl-aristainetos2_7.dtb: pwm@2080000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
arch/arm/boot/dts/nxp/imx/imx6qdl-aristainetos2.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-aristainetos2.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-aristainetos2.dtsi
index db1bc511e71f..758eaf9d93d2 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-aristainetos2.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-aristainetos2.dtsi
@@ -46,7 +46,7 @@
/ {
backlight: backlight {
compatible = "pwm-backlight";
- pwms = <&pwm1 0 5000000>;
+ pwms = <&pwm1 0 5000000 0>;
brightness-levels = <0 4 8 16 32 64 128 255>;
default-brightness-level = <7>;
enable-gpios = <&gpio6 31 GPIO_ACTIVE_HIGH>;
@@ -346,7 +346,6 @@ &pcie {
};
&pwm1 {
- #pwm-cells = <2>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm1>;
status = "okay";
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 02/49] ARM: dts: imx53-m53evk: Use #pwm-cells = <3> for imx27-pwm device
From: Uwe Kleine-König @ 2024-04-05 21:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer
Cc: Pengutronix Kernel Team, Fabio Estevam, devicetree, imx,
linux-arm-kernel, linux-kernel, Alexander Stein
In-Reply-To: <cover.1712352665.git.u.kleine-koenig@pengutronix.de>
The binding dictates using 3 pwm-cells. Adhere to that.
This fixes the following dtbs_check warning:
arch/arm/boot/dts/nxp/imx/imx53-m53evk.dtb: pwm@53fb4000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
arch/arm/boot/dts/nxp/imx/imx53-m53evk.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx53-m53evk.dts b/arch/arm/boot/dts/nxp/imx/imx53-m53evk.dts
index c323b4dbe9f0..1353d985969c 100644
--- a/arch/arm/boot/dts/nxp/imx/imx53-m53evk.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx53-m53evk.dts
@@ -41,7 +41,7 @@ display1_in: endpoint {
backlight {
compatible = "pwm-backlight";
- pwms = <&pwm1 0 3000>;
+ pwms = <&pwm1 0 3000 0>;
brightness-levels = <0 4 8 16 32 64 128 255>;
default-brightness-level = <6>;
power-supply = <®_backlight>;
@@ -313,7 +313,6 @@ &ipu_di1_disp1 {
};
&pwm1 {
- #pwm-cells = <2>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm1>;
status = "okay";
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 01/49] ARM: dts: imx51-ts4800: Use #pwm-cells = <3> for imx27-pwm device
From: Uwe Kleine-König @ 2024-04-05 21:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer
Cc: Pengutronix Kernel Team, Fabio Estevam, devicetree, imx,
linux-arm-kernel, linux-kernel, Alexander Stein
In-Reply-To: <cover.1712352665.git.u.kleine-koenig@pengutronix.de>
The binding dictates using 3 pwm-cells. Adhere to that.
This fixes the following dtbs_check warning:
arch/arm/boot/dts/nxp/imx/imx51-ts4800.dtb: pwm@73fb4000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
arch/arm/boot/dts/nxp/imx/imx51-ts4800.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx51-ts4800.dts b/arch/arm/boot/dts/nxp/imx/imx51-ts4800.dts
index f7408722d68a..2bd0761c7e90 100644
--- a/arch/arm/boot/dts/nxp/imx/imx51-ts4800.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx51-ts4800.dts
@@ -45,7 +45,7 @@ backlight_reg: regulator-backlight {
backlight: backlight {
compatible = "pwm-backlight";
- pwms = <&pwm1 0 78770>;
+ pwms = <&pwm1 0 78770 0>;
brightness-levels = <0 150 200 255>;
default-brightness-level = <1>;
power-supply = <&backlight_reg>;
@@ -113,7 +113,6 @@ &ipu_di0_disp1 {
};
&pwm1 {
- #pwm-cells = <2>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm_backlight>;
status = "okay";
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 06/49] ARM: dts: imx6dl-aristainetos_4: Use #pwm-cells = <3> for imx27-pwm device
From: Uwe Kleine-König @ 2024-04-05 21:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer
Cc: Pengutronix Kernel Team, Fabio Estevam, devicetree, imx,
linux-arm-kernel, linux-kernel, Alexander Stein
In-Reply-To: <cover.1712352665.git.u.kleine-koenig@pengutronix.de>
The binding dictates using 3 pwm-cells. Adhere to that.
This fixes the following dtbs_check warning:
arch/arm/boot/dts/nxp/imx/imx6dl-aristainetos_4.dtb: pwm@2080000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
arch/arm/boot/dts/nxp/imx/imx6dl-aristainetos_4.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6dl-aristainetos_4.dts b/arch/arm/boot/dts/nxp/imx/imx6dl-aristainetos_4.dts
index cc861a43eb58..a5ac79346854 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6dl-aristainetos_4.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6dl-aristainetos_4.dts
@@ -14,7 +14,7 @@ / {
backlight {
compatible = "pwm-backlight";
- pwms = <&pwm1 0 5000000>;
+ pwms = <&pwm1 0 5000000 0>;
brightness-levels = <0 4 8 16 32 64 128 255>;
default-brightness-level = <7>;
enable-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
@@ -79,6 +79,5 @@ &ipu1_di0_disp0 {
};
&pwm1 {
- #pwm-cells = <2>;
status = "okay";
};
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 09/49] ARM: dts: imx6q-ba16: Use #pwm-cells = <3> for imx27-pwm device
From: Uwe Kleine-König @ 2024-04-05 21:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer
Cc: Pengutronix Kernel Team, Fabio Estevam, devicetree, imx,
linux-arm-kernel, linux-kernel, Alexander Stein
In-Reply-To: <cover.1712352665.git.u.kleine-koenig@pengutronix.de>
The binding dictates using 3 pwm-cells. Adhere to that.
This fixes the following dtbs_check warnings:
arch/arm/boot/dts/nxp/imx/imx6q-b450v3.dtb: pwm@2080000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
arch/arm/boot/dts/nxp/imx/imx6q-b650v3.dtb: pwm@2080000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
arch/arm/boot/dts/nxp/imx/imx6q-b850v3.dtb: pwm@2080000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
arch/arm/boot/dts/nxp/imx/imx6q-dms-ba16.dtb: pwm@2080000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
arch/arm/boot/dts/nxp/imx/imx6q-ba16.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6q-ba16.dtsi b/arch/arm/boot/dts/nxp/imx/imx6q-ba16.dtsi
index f266f1b7e0cf..09d9ca0cb332 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6q-ba16.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6q-ba16.dtsi
@@ -55,7 +55,7 @@ backlight_lvds: backlight {
compatible = "pwm-backlight";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_display>;
- pwms = <&pwm1 0 5000000>;
+ pwms = <&pwm1 0 5000000 0>;
brightness-levels = < 0 1 2 3 4 5 6 7 8 9
10 11 12 13 14 15 16 17 18 19
20 21 22 23 24 25 26 27 28 29
@@ -349,7 +349,6 @@ &pcie {
};
&pwm1 {
- #pwm-cells = <2>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm1>;
status = "okay";
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 14/49] ARM: dts: imx6qdl-emcon: Use #pwm-cells = <3> for imx27-pwm device
From: Uwe Kleine-König @ 2024-04-05 21:42 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer
Cc: Pengutronix Kernel Team, Fabio Estevam, devicetree, imx,
linux-arm-kernel, linux-kernel, Alexander Stein
In-Reply-To: <cover.1712352665.git.u.kleine-koenig@pengutronix.de>
The binding dictates using 3 pwm-cells. Adhere to that.
This fixes the following dtbs_check warnings:
arch/arm/boot/dts/nxp/imx/imx6dl-emcon-avari.dtb: pwm@2080000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
arch/arm/boot/dts/nxp/imx/imx6dl-emcon-avari.dtb: pwm@2088000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
arch/arm/boot/dts/nxp/imx/imx6dl-emcon-avari.dtb: pwm@208c000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
arch/arm/boot/dts/nxp/imx/imx6q-emcon-avari.dtb: pwm@2080000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
arch/arm/boot/dts/nxp/imx/imx6q-emcon-avari.dtb: pwm@2088000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
arch/arm/boot/dts/nxp/imx/imx6q-emcon-avari.dtb: pwm@208c000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
arch/arm/boot/dts/nxp/imx/imx6qdl-emcon.dtsi | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-emcon.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-emcon.dtsi
index 42b2ba23aefc..a308a3584b62 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6qdl-emcon.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-emcon.dtsi
@@ -66,7 +66,7 @@ lvds_backlight: lvds-backlight {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lvds_bl>;
enable-gpios = <&gpio6 9 GPIO_ACTIVE_HIGH>;
- pwms = <&pwm1 0 50000>;
+ pwms = <&pwm1 0 50000 0>;
brightness-levels = <
0 4 8 16 32 64 80 96 112
128 144 160 176 250
@@ -78,7 +78,7 @@ lvds_backlight: lvds-backlight {
pwm_fan: pwm-fan {
compatible = "pwm-fan";
#cooling-cells = <2>;
- pwms = <&pwm4 0 50000>;
+ pwms = <&pwm4 0 50000 0>;
cooling-levels = <0 64 127 191 255>;
status = "disabled";
};
@@ -145,7 +145,7 @@ rgb_backlight: rgb-backlight {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_rgb_bl>;
enable-gpios = <&gpio6 8 GPIO_ACTIVE_HIGH>;
- pwms = <&pwm3 0 5000000>;
+ pwms = <&pwm3 0 5000000 0>;
brightness-levels = <
250 176 160 144 128 112
96 80 64 48 32 16 8 1
@@ -736,17 +736,14 @@ &pcie {
};
&pwm1 {
- #pwm-cells = <2>;
status = "okay";
};
&pwm3 {
- #pwm-cells = <2>;
status = "okay";
};
&pwm4 {
- #pwm-cells = <2>;
status = "okay";
};
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 08/49] ARM: dts: imx6dl-mamoj: Use #pwm-cells = <3> for imx27-pwm device
From: Uwe Kleine-König @ 2024-04-05 21:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer
Cc: Pengutronix Kernel Team, Fabio Estevam, devicetree, imx,
linux-arm-kernel, linux-kernel, Alexander Stein
In-Reply-To: <cover.1712352665.git.u.kleine-koenig@pengutronix.de>
The binding dictates using 3 pwm-cells. Adhere to that.
This fixes the following dtbs_check warning:
arch/arm/boot/dts/nxp/imx/imx6dl-mamoj.dtb: pwm@2088000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
arch/arm/boot/dts/nxp/imx/imx6dl-mamoj.dts | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6dl-mamoj.dts b/arch/arm/boot/dts/nxp/imx/imx6dl-mamoj.dts
index 028951955bde..72ee236d2f5e 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6dl-mamoj.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx6dl-mamoj.dts
@@ -21,7 +21,7 @@ memory@10000000 {
backlight_lcd: backlight-lcd {
compatible = "pwm-backlight";
- pwms = <&pwm3 0 25000>; /* 25000ns -> 40kHz */
+ pwms = <&pwm3 0 25000 0>; /* 25000ns -> 40kHz */
brightness-levels = <0 4 8 16 32 64 128 160 192 224 255>;
default-brightness-level = <7>;
};
@@ -303,7 +303,6 @@ &ipu1_di0_disp0 {
};
&pwm3 {
- #pwm-cells = <2>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm3>;
status = "okay";
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v1 42/49] ARM: dts: imx6ul-14x14-evk: Use #pwm-cells = <3> for imx27-pwm device
From: Uwe Kleine-König @ 2024-04-05 21:42 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer
Cc: Pengutronix Kernel Team, Fabio Estevam, devicetree, imx,
linux-arm-kernel, linux-kernel, Alexander Stein
In-Reply-To: <cover.1712352665.git.u.kleine-koenig@pengutronix.de>
The binding dictates using 3 pwm-cells. Adhere to that.
This fixes the following dtbs_check warnings:
arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtb: pwm@2080000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
arch/arm/boot/dts/nxp/imx/imx6ull-14x14-evk.dtb: pwm@2080000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
arch/arm/boot/dts/nxp/imx/imx6ulz-14x14-evk.dtb: pwm@2080000: #pwm-cells:0:0: 3 was expected
from schema : http://devicetree.org/schemas/pwm/imx-pwm.yaml#
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi
index f10f0525490b..9cfb99ac9e9d 100644
--- a/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi
+++ b/arch/arm/boot/dts/nxp/imx/imx6ul-14x14-evk.dtsi
@@ -16,7 +16,7 @@ memory@80000000 {
backlight_display: backlight-display {
compatible = "pwm-backlight";
- pwms = <&pwm1 0 5000000>;
+ pwms = <&pwm1 0 5000000 0>;
brightness-levels = <0 4 8 16 32 64 128 255>;
default-brightness-level = <6>;
status = "okay";
@@ -277,7 +277,6 @@ display_out: endpoint {
};
&pwm1 {
- #pwm-cells = <2>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm1>;
status = "okay";
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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