* [PATCH 0/5] Radxa NIO-12L: Supplies for CPU/GPU and improvements
From: AngeloGioacchino Del Regno @ 2024-04-09 11:42 UTC (permalink / raw)
To: linux-mediatek
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
devicetree, linux-kernel, linux-arm-kernel, kernel
This series performs various improvements and enables PHYs and USB Role
Switching for proper PM support and to stop relying on the bootloader's
pre-boot configuration.
USB Role Switching doesn't include Alternate Modes yet, as this needs
some more work.
As for the regulator nodes, those were not probing correctly, producing
unability to resume after PM suspend.
AngeloGioacchino Del Regno (5):
arm64: dts: mediatek: mt8395-nio-12l: Fix MT6360 regulator nodes names
arm64: dts: medaitek: mt8395-nio-12l: Set i2c6 pins to bias-disable
arm64: dts: mediatek: mt8395-nio-12l: Define RSEL in microamperes
arm64: dts: mediatek: mt8395-nio-12l: Enable PHYs and USB role switch
arm64: dts: mediatek: mt8395-nio-12l: Add power supplies for CPU/GPU
scaling
.../dts/mediatek/mt8395-radxa-nio-12l.dts | 106 ++++++++++++++++--
1 file changed, 94 insertions(+), 12 deletions(-)
--
2.44.0
^ permalink raw reply
* [PATCH 1/5] arm64: dts: mediatek: mt8395-nio-12l: Fix MT6360 regulator nodes names
From: AngeloGioacchino Del Regno @ 2024-04-09 11:42 UTC (permalink / raw)
To: linux-mediatek
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
devicetree, linux-kernel, linux-arm-kernel, kernel
In-Reply-To: <20240409114211.310462-1-angelogioacchino.delregno@collabora.com>
The regulators' node names for mt6360-regulator are supposed to be
uppercase. Also, drop "-regulator" from the usb-otg-vbus node name
to make all vregs to probe correctly.
The alternative would've been to use regulator-compatible, but that's
a deprecated property.
Now all regulators are probing fine.
Fixes: 96564b1e2ea4 ("arm64: dts: mediatek: Introduce the MT8395 Radxa NIO 12L board")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
index e5d9b671a405..18182cf073fb 100644
--- a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
@@ -216,7 +216,7 @@ charger {
compatible = "mediatek,mt6360-chg";
richtek,vinovp-microvolt = <14500000>;
- otg_vbus_regulator: usb-otg-vbus-regulator {
+ otg_vbus_regulator: usb-otg-vbus {
regulator-name = "usb-otg-vbus";
regulator-min-microvolt = <4425000>;
regulator-max-microvolt = <5825000>;
@@ -228,7 +228,7 @@ regulator {
LDO_VIN1-supply = <&vsys_buck>;
LDO_VIN3-supply = <&mt6360_buck2>;
- mt6360_buck1: buck1 {
+ mt6360_buck1: BUCK1 {
regulator-name = "emi_vdd2";
regulator-min-microvolt = <300000>;
regulator-max-microvolt = <1300000>;
@@ -238,7 +238,7 @@ MT6360_OPMODE_LP
regulator-always-on;
};
- mt6360_buck2: buck2 {
+ mt6360_buck2: BUCK2 {
regulator-name = "emi_vddq";
regulator-min-microvolt = <300000>;
regulator-max-microvolt = <1300000>;
@@ -248,7 +248,7 @@ MT6360_OPMODE_LP
regulator-always-on;
};
- mt6360_ldo1: ldo1 {
+ mt6360_ldo1: LDO1 {
regulator-name = "ext_lcd_3v3";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
@@ -257,7 +257,7 @@ mt6360_ldo1: ldo1 {
regulator-always-on;
};
- mt6360_ldo2: ldo2 {
+ mt6360_ldo2: LDO2 {
regulator-name = "panel1_p1v8";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
@@ -265,7 +265,7 @@ mt6360_ldo2: ldo2 {
MT6360_OPMODE_LP>;
};
- mt6360_ldo3: ldo3 {
+ mt6360_ldo3: LDO3 {
regulator-name = "vmc_pmu";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <3600000>;
@@ -273,7 +273,7 @@ mt6360_ldo3: ldo3 {
MT6360_OPMODE_LP>;
};
- mt6360_ldo5: ldo5 {
+ mt6360_ldo5: LDO5 {
regulator-name = "vmch_pmu";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
@@ -282,7 +282,7 @@ mt6360_ldo5: ldo5 {
regulator-always-on;
};
- mt6360_ldo6: ldo6 {
+ mt6360_ldo6: LDO6 {
regulator-name = "mt6360_ldo6"; /* Test point */
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <2100000>;
@@ -290,7 +290,7 @@ mt6360_ldo6: ldo6 {
MT6360_OPMODE_LP>;
};
- mt6360_ldo7: ldo7 {
+ mt6360_ldo7: LDO7 {
regulator-name = "emi_vmddr_en";
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <2100000>;
--
2.44.0
^ permalink raw reply related
* [PATCH 2/5] arm64: dts: medaitek: mt8395-nio-12l: Set i2c6 pins to bias-disable
From: AngeloGioacchino Del Regno @ 2024-04-09 11:42 UTC (permalink / raw)
To: linux-mediatek
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
devicetree, linux-kernel, linux-arm-kernel, kernel
In-Reply-To: <20240409114211.310462-1-angelogioacchino.delregno@collabora.com>
GPIOs 25 and 26 do not support pull-up/pull-down when those are muxed
as I2C6's SDA6/SCL6 lines: set those to bias-disable to avoid warning
messages from the pinctrl driver.
Fixes: 96564b1e2ea4 ("arm64: dts: mediatek: Introduce the MT8395 Radxa NIO 12L board")
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
index 18182cf073fb..86f7d4dd5eae 100644
--- a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
@@ -528,7 +528,7 @@ i2c6_pins: i2c6-pins {
pins {
pinmux = <PINMUX_GPIO25__FUNC_SDA6>,
<PINMUX_GPIO26__FUNC_SCL6>;
- bias-pull-up = <MTK_PULL_SET_RSEL_111>;
+ bias-disable;
};
};
--
2.44.0
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: mediatek: mt8395-nio-12l: Define RSEL in microamperes
From: AngeloGioacchino Del Regno @ 2024-04-09 11:42 UTC (permalink / raw)
To: linux-mediatek
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
devicetree, linux-kernel, linux-arm-kernel, kernel
In-Reply-To: <20240409114211.310462-1-angelogioacchino.delregno@collabora.com>
The paris pinctrl driver supports specifying the RSEL drive strength
in microamperes as well as internal bits definitions: choose to specify
those in uA to avoid using hardware specific values in device trees.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
index 86f7d4dd5eae..f699633659b6 100644
--- a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
@@ -434,6 +434,8 @@ &mt6359_vsram_others_ldo_reg {
};
&pio {
+ mediatek,rsel-resistance-in-si-unit;
+
eth_default_pins: eth-default-pins {
pins-cc {
pinmux = <PINMUX_GPIO85__FUNC_GBE_TXC>,
@@ -509,7 +511,7 @@ i2c2_pins: i2c2-pins {
pins-bus {
pinmux = <PINMUX_GPIO12__FUNC_SDA2>,
<PINMUX_GPIO13__FUNC_SCL2>;
- bias-pull-up = <MTK_PULL_SET_RSEL_111>;
+ bias-pull-up = <1000>;
drive-strength = <6>;
drive-strength-microamp = <1000>;
};
@@ -519,7 +521,7 @@ i2c4_pins: i2c4-pins {
pins-bus {
pinmux = <PINMUX_GPIO16__FUNC_SDA4>,
<PINMUX_GPIO17__FUNC_SCL4>;
- bias-pull-up = <MTK_PULL_SET_RSEL_111>;
+ bias-pull-up = <1000>;
drive-strength-microamp = <1000>;
};
};
--
2.44.0
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: mediatek: mt8395-nio-12l: Enable PHYs and USB role switch
From: AngeloGioacchino Del Regno @ 2024-04-09 11:42 UTC (permalink / raw)
To: linux-mediatek
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
devicetree, linux-kernel, linux-arm-kernel, kernel
In-Reply-To: <20240409114211.310462-1-angelogioacchino.delregno@collabora.com>
Enable the PCIe0 PHY to be able to set calibrations read from eFuses,
improving the stability and performance of the PCIe link.
While at it, also enable the T-PHYs for both PCIe1 and for USB, allowing
the USB ports to finally switch to gadget mode if needed, and configure
the VBUS/ID pins of both USB ports for the same.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../dts/mediatek/mt8395-radxa-nio-12l.dts | 40 +++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
index f699633659b6..5cbe969da425 100644
--- a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
@@ -685,6 +685,26 @@ pins-bus {
};
};
+ usb3_port0_pins: usb3p0-default-pins {
+ pins-vbus {
+ pinmux = <PINMUX_GPIO63__FUNC_VBUSVALID>;
+ input-enable;
+ };
+ };
+
+ usb2_port0_pins: usb2p0-default-pins {
+ pins-iddig {
+ pinmux = <PINMUX_GPIO130__FUNC_IDDIG_1P>;
+ input-enable;
+ bias-pull-up;
+ };
+
+ pins-vbus {
+ pinmux = <PINMUX_GPIO131__FUNC_USB_DRVVBUS_1P>;
+ output-low;
+ };
+ };
+
wifi_vreg_pins: wifi-vreg-pins {
pins-wifi-pmu-en {
pinmux = <PINMUX_GPIO65__FUNC_GPIO65>;
@@ -709,6 +729,10 @@ &pcie1 {
status = "okay";
};
+&pciephy {
+ status = "okay";
+};
+
&pmic {
interrupts-extended = <&pio 222 IRQ_TYPE_LEVEL_HIGH>;
};
@@ -776,6 +800,18 @@ mt6315_7_vbuck1: vbuck1 {
};
};
+&u3phy0 {
+ status = "okay";
+};
+
+&u3phy1 {
+ status = "okay";
+};
+
+&u3phy2 {
+ status = "okay";
+};
+
&uart0 {
/* Exposed at 40 pin connector */
pinctrl-0 = <&uart0_pins>;
@@ -791,6 +827,8 @@ &uart1 {
};
&ssusb0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb3_port0_pins>;
role-switch-default-mode = "host";
usb-role-switch;
vusb33-supply = <&mt6359_vusb_ldo_reg>;
@@ -804,6 +842,8 @@ mtu3_hs0_role_sw: endpoint {
};
&ssusb2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb2_port0_pins>;
vusb33-supply = <&mt6359_vusb_ldo_reg>;
status = "okay";
};
--
2.44.0
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: mediatek: mt8395-nio-12l: Add power supplies for CPU/GPU scaling
From: AngeloGioacchino Del Regno @ 2024-04-09 11:42 UTC (permalink / raw)
To: linux-mediatek
Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
devicetree, linux-kernel, linux-arm-kernel, kernel
In-Reply-To: <20240409114211.310462-1-angelogioacchino.delregno@collabora.com>
Add the necessary power supplies to safely enable CPU and GPU frequency
scaling.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../dts/mediatek/mt8395-radxa-nio-12l.dts | 40 +++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
index 5cbe969da425..bf6b539e6c06 100644
--- a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
@@ -140,6 +140,38 @@ apu_mem: memory@62000000 {
};
};
+&cpu0 {
+ cpu-supply = <&mt6359_vcore_buck_reg>;
+};
+
+&cpu1 {
+ cpu-supply = <&mt6359_vcore_buck_reg>;
+};
+
+&cpu2 {
+ cpu-supply = <&mt6359_vcore_buck_reg>;
+};
+
+&cpu3 {
+ cpu-supply = <&mt6359_vcore_buck_reg>;
+};
+
+&cpu4 {
+ cpu-supply = <&mt6315_6_vbuck1>;
+};
+
+&cpu5 {
+ cpu-supply = <&mt6315_6_vbuck1>;
+};
+
+&cpu6 {
+ cpu-supply = <&mt6315_6_vbuck1>;
+};
+
+&cpu7 {
+ cpu-supply = <&mt6315_6_vbuck1>;
+};
+
ð {
phy-mode = "rgmii-rxid";
phy-handle = <&rgmii_phy>;
@@ -343,6 +375,14 @@ typec_con_mux: endpoint {
};
};
+&mfg0 {
+ domain-supply = <&mt6315_7_vbuck1>;
+};
+
+&mfg1 {
+ domain-supply = <&mt6359_vsram_others_ldo_reg>;
+};
+
/* MMC0 Controller: eMMC (HS400). Power lines are shared with UFS! */
&mmc0 {
pinctrl-names = "default", "state_uhs";
--
2.44.0
^ permalink raw reply related
* Re: [PATCH 0/4] DONOTMERGE: ep93xx-clk from ep93xx device tree conversion
From: Nikita Shubin @ 2024-04-09 11:48 UTC (permalink / raw)
To: Conor Dooley, Arnd Bergmann, Alexander Sverdlin
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-kernel, linux-clk, devicetree, Arnd Bergmann,
Linus Walleij, Krzysztof Kozlowski
In-Reply-To: <20240408-friction-mosaic-ba48bc27788d@spud>
Hello Conor!
On Mon, 2024-04-08 at 18:03 +0100, Conor Dooley wrote:
> 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?
drivers/soc/cirrus got it's ACK from ep93xx MAINTAINER - Alexander
Sverdlin.
Arnd, Alexander - should we add it now ?
But i still require ACK for "clk: ep93xx: add DT support for Cirrus
EP93xx" which is clk subsystems.
>
> 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>
> >
> >
^ permalink raw reply
* Re: [PATCH 5/9] dt-bindings: rtc: rtc-aspeed: move to trivial-rtc
From: Andrew Jeffery @ 2024-04-09 11:53 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32
In-Reply-To: <20240408-rtc_dtschema-v1-5-c447542fc362@gmail.com>
On Mon, 2024-04-08 at 17:53 +0200, Javier Carrasco wrote:
> The RTCs documented in this binding require a compatible, a reg
> and a single interrupt, which make them suitable for a direct
> conversion into trivial-rtc.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Thanks,
Andrew
^ permalink raw reply
* [v2 1/1] arm64: dts: rockchip: enable onboard spi flash for rock-3a
From: Chukun Pan @ 2024-04-09 12:00 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Conor Dooley, Krzysztof Kozlowski, Rob Herring, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree, Chukun Pan
In-Reply-To: <20240409120003.309358-1-amadeus@jmu.edu.cn>
There is a mx25u12835f spi flash on this board, enable it.
[ 2.525805] spi-nor spi4.0: mx25u12835f (16384 Kbytes)
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
index a5e974ea659e..c62230308457 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
@@ -757,6 +757,20 @@ &sdmmc2 {
status = "okay";
};
+&sfc {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-max-frequency = <104000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <1>;
+ };
+};
+
&tsadc {
rockchip,hw-tshut-mode = <1>;
rockchip,hw-tshut-polarity = <0>;
--
2.25.1
^ permalink raw reply related
* [v2 0/1] arm64: dts: rockchip: enable onboard spi flash for rock-3a
From: Chukun Pan @ 2024-04-09 12:00 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Conor Dooley, Krzysztof Kozlowski, Rob Herring, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree, Chukun Pan
Changes in v2:
Add missing cells count.
Increase spi max frequency to 104MHz.
^ permalink raw reply
* Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set additionalProperties to true
From: Cristian Marussi @ 2024-04-09 12:01 UTC (permalink / raw)
To: Peng Fan
Cc: Krzysztof Kozlowski, Peng Fan (OSS), Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Sudeep Holla,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <AS1PR04MB9431BE4B2BFE05507A2D93F288072@AS1PR04MB9431.eurprd04.prod.outlook.com>
On Tue, Apr 09, 2024 at 09:25:10AM +0000, Peng Fan wrote:
> Hi Krzysztof,
>
> > Subject: RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > additionalProperties to true
> >
> > > Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > additionalProperties to true
> > >
> > > On 08/04/2024 08:08, Peng Fan wrote:
> > > >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > >> additionalProperties to true
> > > >>
> > > >> On 08/04/2024 01:50, Peng Fan wrote:
> > > >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > >>>> additionalProperties to true
> > > >>>>
> > > >>>> On 07/04/2024 12:04, Peng Fan wrote:
> > > >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > >>>>>> set additionalProperties to true
> > > >>>>>>
> > > >>>>>> On 07/04/2024 02:37, Peng Fan wrote:
> > > >>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > >>>>>>>> set additionalProperties to true
> > > >>>>>>>>
> > > >>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> > > >>>>>>>>> From: Peng Fan <peng.fan@nxp.com>
> > > >>>>>>>>>
> > > >>>>>>>>> When adding vendor extension protocols, there is dt-schema
> > > >> warning:
> > > >>>>>>>>> "
> > > >>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do
> > > >>>>>>>>> not match any of the regexes: 'pinctrl-[0-9]+'
> > > >>>>>>>>> "
> > > >>>>>>>>>
> > > >>>>>>>>> Set additionalProperties to true to address the issue.
> > > >>>>>>>>
> > > >>>>>>>> I do not see anything addressed here, except making the
> > > >>>>>>>> binding accepting anything anywhere...
> > > >>>>>>>
> > > >>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> > > >>>>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI
> > > >>>>>>> protocol
> > > >> extension.
> > > >>>>>>>
> > > >>>>>>> With additionalProperties set to false, I not know how, please
> > > suggest.
> > > >>>>>>
> > > >>>>>> First of all, you cannot affect negatively existing devices
> > > >>>>>> (their
> > > >>>>>> bindings) and your patch does exactly that. This should make
> > > >>>>>> you thing what is the correct approach...
> > > >>>>>>
> > > >>>>>> Rob gave you the comment about missing compatible - you still
> > > >>>>>> did not address that.
> > > >>>>>
> > > >>>>> I added the compatible in patch 2/6 in the examples "compatible
> > > >>>>> =
> > > >>>> "arm,scmi";"
> > > >>>>
> > > >>>> So you claim that your vendor extensions are the same or fully
> > > >>>> compatible with arm,scmi and you add nothing... Are your
> > > >>>> extensions/protocol valid for arm,scmi?
> > > >>>
> > > >>> Yes. They are valid for arm,scmi.
> > > >>>
> > > >>> If yes, why is this in separate binding. If no, why you use
> > > >>> someone
> > > >>>> else's compatible?
> > > >>>
> > > >>> Per SCMI Spec
> > > >>> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> > > >>> this interface
> > > >>>
> > > >>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use
> > > >>> the id for their own protocol.
> > > >>
> > > >> So how are they valid for arm,scmi? I don't understand.
> > > >
> > > > arm,scmi is a firmware compatible string. The protocol node is a sub-node.
> > > > I think the arm,scmi is that saying the firmware following SCMI spec
> > > > to implement the protocols.
> > > >
> > > > For vendor reserved ID, firmware also follow the SCMI spec to
> > > > implement their own usage, so from firmware level, it is ARM SCMI
> > > > spec
> > > compatible.
> > >
> > > That's not the point. It is obvious that your firmware is compatible
> > > with arm,scmi, but what you try to say in this and revised patch is
> > > that every arm,scmi is compatible with your implementation. What you
> > > are saying is that 0x84 is MISC protocol for every firmware, Qualcomm,
> > > NXP, Samsung, TI, Mediatek etc.
> > >
> > > I claim it is not true. 0x84 is not MISC for Qualcomm, for example.
> >
> > You are right. I am lost now on how to add vendor ID support, using
> > arm,scmi.yaml or adding a new imx,scmi.yaml or else.
>
Hi Peng,
I dont think in the following you will find the solution to the problem,
it is just to recap the situation and constraints around vendor protocol
bindings.
Describing SCMI vendors protocols is tricky because while on one side
the protocol node has to be rooted under the main scmi fw DT node (like
all the standard protocols) and be 'derived' from the arm,scmi.yaml
protocol-node definition, the optional additional properties of the a specific
vendor protocol nodes can be customized by each single vendor, and since,
as you said, you can have multiple protocols from different vendors sharing the
same protocol number, you could have multiple disjoint sets of valid properties
allowed under that same protocol node number; so on one side you have to stick
to some basic protocol-node defs and be rooted under the SCMI node, while on
the other side you will have multiple possibly allowed sets of additional
properties to check against, so IOW you cannot anyway just set
additionalProperties to false since that will result in no checks at all.
As a consequence, at runtime, in the final DTB shipped with a specific
platform you should have only one of the possible vendor nodes for each
of these overlapping protocols, and the SCMI core at probe time will
pick the proper protocol implementation based on the vendor/sub_vendor
IDs gathered from the running SCMI fw platform at init: this way you
can just build the usual "all-inclusive" defconfig without worrying
about vendor protocol clashes since the SCMI core can pick the right
protocol implementation, you should just had taken care to provide the
proper DTB for your protocol; BUT this also means that it is not possible
to add multiple DT bindings based on a 'if vendor' condition since the
vendor itself is NOT defined and not needed in the bindings since it is
discoverable at runtime.
So, after all of this blabbing of mine about this, I am wondering if it
is not possible that the solution is to handle each and every vendor
protocol node that appears with a block of addtional properties that
are picked via a oneOf statement from some external vendor specific
yaml.
(...in a similar way to how pinctrl additional properties are added...)
NOTE THAT the following is just an example of what I mean, it is certainly
wrong, incomplete annd maybe just not acceptable (and could cause DT
maintainers eyes to bleed :P)...
...so it is just fr the sake of explaining what I mean...
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index e9d3f043c4ed..3c38a1e3ffed 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -278,6 +278,22 @@ properties:
required:
- reg
+ protocol@81:
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ const: 0x81
+
+ patternProperties:
+ '$':
+ type: object
+ oneOf:
+ - $ref: /schemas/vendor-A/scmi-protos.yaml#
+ - $ref: /schemas/vendor-B/protos.yaml#
+ unevaluatedProperties: false
+
additionalProperties: false
...with each new Vendor coming to the party adding a line under
oneOf...which would mean probably also having a protocol@NN for each new
protocol that appears...
Thanks,
Cristian
^ permalink raw reply related
* [PATCH v2 0/3] drm/mediatek: Add support for OF graphs
From: AngeloGioacchino Del Regno @ 2024-04-09 12:02 UTC (permalink / raw)
To: chunkuang.hu
Cc: robh, krzysztof.kozlowski+dt, conor+dt, p.zabel, airlied, daniel,
maarten.lankhorst, mripard, tzimmermann, matthias.bgg,
angelogioacchino.delregno, shawn.sung, yu-chang.lee, ck.hu,
jitao.shi, devicetree, linux-kernel, dri-devel, linux-mediatek,
linux-arm-kernel, wenst, kernel
Changes in v2:
- Fixed wrong `required` block indentation in commit [2/3]
The display IPs in MediaTek SoCs are *VERY* flexible and those support
being interconnected with different instances of DDP IPs (for example,
merge0 or merge1) and/or with different DDP IPs (for example, rdma can
be connected with either color, dpi, dsi, merge, etc), forming a full
Display Data Path that ends with an actual display.
This series was born because of an issue that I've found while enabling
support for MT8195/MT8395 boards with DSI output as main display: the
current mtk_drm_route variations would not work as currently, the driver
hardcodes a display path for Chromebooks, which have a DisplayPort panel
with DSC support, instead of a DSI panel without DSC support.
There are other reasons for which I wrote this series, and I find that
hardcoding those paths - when a HW path is clearly board-specific - is
highly suboptimal. Also, let's not forget about keeping this driver from
becoming a huge list of paths for each combination of SoC->board->disp
and... this and that.
For more information, please look at the commit description for each of
the commits included in this series.
Please don't mind about the missing OVL_ADAPTOR support for OF graphs
in this series: that needs a bit more thinking and a bit more work, and
will come in a second series that will go on top of this a bit later,
as the OF graph support for *at least* the primary display is essential
*right now* to enable support for the MT8195/8395 EVK, Kontron SoM,
Radxa NIO-12L and all of the other non-Chromebook boards to co-exist
with Chromebooks.
Besides, this is also a valid option for MT8188 Chromebooks which might
have different DSI-or-eDP displays depending on the model (as far as I
can see from the mtk_drm_route attempt for this SoC that is already
present in this driver).
This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
NIO-12L with both hardcoded paths, OF graph support and partially
hardcoded paths (meaning main display through OF graph and external
display hardcoded, because of OVL_ADAPTOR).
AngeloGioacchino Del Regno (3):
dt-bindings: display: mediatek: Add OF graph support for board path
dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
drm/mediatek: Implement OF graphs support for display paths
.../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 ++
.../display/mediatek/mediatek,aal.yaml | 40 +++
.../display/mediatek/mediatek,ccorr.yaml | 21 ++
.../display/mediatek/mediatek,color.yaml | 22 ++
.../display/mediatek/mediatek,dither.yaml | 22 ++
.../display/mediatek/mediatek,dpi.yaml | 25 +-
.../display/mediatek/mediatek,dsc.yaml | 24 ++
.../display/mediatek/mediatek,dsi.yaml | 27 +-
.../display/mediatek/mediatek,ethdr.yaml | 22 ++
.../display/mediatek/mediatek,gamma.yaml | 19 ++
.../display/mediatek/mediatek,merge.yaml | 23 ++
.../display/mediatek/mediatek,od.yaml | 22 ++
.../display/mediatek/mediatek,ovl-2l.yaml | 22 ++
.../display/mediatek/mediatek,ovl.yaml | 22 ++
.../display/mediatek/mediatek,postmask.yaml | 21 ++
.../display/mediatek/mediatek,rdma.yaml | 22 ++
.../display/mediatek/mediatek,ufoe.yaml | 21 ++
drivers/gpu/drm/mediatek/mtk_dpi.c | 16 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 255 ++++++++++++++++--
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
21 files changed, 645 insertions(+), 36 deletions(-)
--
2.44.0
^ permalink raw reply
* [PATCH v2 1/3] dt-bindings: display: mediatek: Add OF graph support for board path
From: AngeloGioacchino Del Regno @ 2024-04-09 12:02 UTC (permalink / raw)
To: chunkuang.hu
Cc: robh, krzysztof.kozlowski+dt, conor+dt, p.zabel, airlied, daniel,
maarten.lankhorst, mripard, tzimmermann, matthias.bgg,
angelogioacchino.delregno, shawn.sung, yu-chang.lee, ck.hu,
jitao.shi, devicetree, linux-kernel, dri-devel, linux-mediatek,
linux-arm-kernel, wenst, kernel
In-Reply-To: <20240409120211.321153-1-angelogioacchino.delregno@collabora.com>
The display IPs in MediaTek SoCs support being interconnected with
different instances of DDP IPs (for example, merge0 or merge1) and/or
with different DDP IPs (for example, rdma can be connected with either
color, dpi, dsi, merge, etc), forming a full Display Data Path that
ends with an actual display.
The final display pipeline is effectively board specific, as it does
depend on the display that is attached to it, and eventually on the
sensors supported by the board (for example, Adaptive Ambient Light
would need an Ambient Light Sensor, otherwise it's pointless!), other
than the output type.
Add support for OF graphs to most of the MediaTek DDP (display) bindings
to add flexibility to build custom hardware paths, hence enabling board
specific configuration of the display pipeline and allowing to finally
migrate away from using hardcoded paths.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../display/mediatek/mediatek,aal.yaml | 40 +++++++++++++++++++
.../display/mediatek/mediatek,ccorr.yaml | 21 ++++++++++
.../display/mediatek/mediatek,color.yaml | 22 ++++++++++
.../display/mediatek/mediatek,dither.yaml | 22 ++++++++++
.../display/mediatek/mediatek,dpi.yaml | 25 +++++++++++-
.../display/mediatek/mediatek,dsc.yaml | 24 +++++++++++
.../display/mediatek/mediatek,dsi.yaml | 27 ++++++++++++-
.../display/mediatek/mediatek,ethdr.yaml | 22 ++++++++++
.../display/mediatek/mediatek,gamma.yaml | 19 +++++++++
.../display/mediatek/mediatek,merge.yaml | 23 +++++++++++
.../display/mediatek/mediatek,od.yaml | 22 ++++++++++
.../display/mediatek/mediatek,ovl-2l.yaml | 22 ++++++++++
.../display/mediatek/mediatek,ovl.yaml | 22 ++++++++++
.../display/mediatek/mediatek,postmask.yaml | 21 ++++++++++
.../display/mediatek/mediatek,rdma.yaml | 22 ++++++++++
.../display/mediatek/mediatek,ufoe.yaml | 21 ++++++++++
16 files changed, 372 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
index b4c28e96dd55..623cf7e37fe3 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
@@ -61,6 +61,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: AAL input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ AAL output to the next component's input, for example could be one
+ of many gamma, overdrive or other blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
@@ -88,5 +109,24 @@ examples:
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_AAL>;
mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x5000 0x1000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ aal0_in: endpoint {
+ remote-endpoint = <&ccorr0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ aal0_out: endpoint {
+ remote-endpoint = <&gamma0_in>;
+ };
+ };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
index 8c2a737237f2..71ea277a5d8e 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
@@ -54,6 +54,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: CCORR input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ CCORR output to the input of the next desired component in the
+ display pipeline, usually only one of the available AAL blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
index b886ca0d89ea..61d040a10c08 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
@@ -64,6 +64,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: COLOR input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ COLOR output to the input of the next desired component in the
+ display pipeline, for example one of the available CCORR or AAL
+ blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
index 1588b3f7cec7..3d4ab3f86294 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
@@ -55,6 +55,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DITHER input, usually from a POSTMASK or GAMMA block.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ DITHER output to the input of the next desired component in the
+ display pipeline, for example one of the available DSC compressors,
+ DP_INTF, DSI, LVDS or others.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
index 803c00f26206..6607cb1c6e0a 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -64,13 +64,34 @@ properties:
Output port node. This port should be connected to the input port of an
attached HDMI, LVDS or DisplayPort encoder chip.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DPI input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DPI output to an HDMI, LVDS or DisplayPort encoder input
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- - port
+
+oneOf:
+ - required:
+ - port
+ - required:
+ - ports
additionalProperties: false
@@ -79,7 +100,7 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/mt8173-clk.h>
- dpi0: dpi@1401d000 {
+ dpi: dpi@1401d000 {
compatible = "mediatek,mt8173-dpi";
reg = <0x1401d000 0x1000>;
interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>;
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml
index 2cbdd9ee449d..846de6c17d93 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml
@@ -49,6 +49,30 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Display Stream Compression input, usually from one of the DITHER
+ or MERGE blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Display Stream Compression output to the input of the next desired
+ component in the display pipeline, for example to MERGE, DP_INTF,
+ DPI or DSI.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
index 8611319bed2e..2e9d3d23cbc1 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
@@ -76,6 +76,26 @@ properties:
Output port node. This port should be connected to the input
port of an attached DSI panel or DSI-to-eDP encoder chip.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input ports can have multiple endpoints, each of those connects
+ to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DSI input port, usually from DITHER, DSC or MERGE
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ DSI output to an attached DSI panel, or a DSI-to-X encoder chip
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
@@ -85,7 +105,12 @@ required:
- clock-names
- phys
- phy-names
- - port
+
+oneOf:
+ - required:
+ - port
+ - required:
+ - ports
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
index 677882348ede..98db47894eeb 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
@@ -110,6 +110,28 @@ properties:
include/dt-bindings/gce/<chip>-gce.h, mapping to the register of display
function block.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: ETHDR input, usually from one of the MERGE blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ ETHDR output to the input of the next desired component in the
+ display pipeline, for example one of the available MERGE blocks,
+ or others.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
index c6641acd75d6..e24287ec364e 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
@@ -59,6 +59,25 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GAMMA input, usually from one of the AAL blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ GAMMA output to the input of the next desired component in the
+ display pipeline, for example one of the available DITHER or
+ POSTMASK blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
index dae839279950..0de9f64f3f84 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
@@ -77,6 +77,29 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ MERGE input port, usually from DITHER, DPI, DSC, DSI, MDP_RDMA,
+ ETHDR or even from a different MERGE block
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ MERGE output to a DSC, DPI, DP_INTF, DSI, ETHDR, Write DMA, or
+ a different MERGE block, or others.
+
+ required:
+ - port@0
+ - port@1
+
resets:
description: reset controller
See Documentation/devicetree/bindings/reset/reset.txt for details.
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
index 831c653caffd..71534febd49c 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
@@ -38,6 +38,28 @@ properties:
items:
- description: OD Clock
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OD input port, usually from an AAL block
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ OD output to the input of the next desired component in the
+ display pipeline, for example one of the available RDMA or
+ other blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
index c7dd0ef02dcf..bacdfe7d08a6 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
@@ -57,6 +57,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OVL input port from MMSYS, VDOSYS or other OVLs
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ OVL output to the input of the next desired component in the
+ display pipeline, for example one of the available COLOR, RDMA
+ or WDMA blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
index c471a181d125..e93f0247bdcc 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
@@ -74,6 +74,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OVL input port from MMSYS or one of multiple VDOSYS
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ OVL output to the input of the next desired component in the
+ display pipeline, for example one of the available COLOR, RDMA
+ or WDMA blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
index 11fe32e50a59..fb6fe4742624 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
@@ -52,6 +52,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: POSTMASK input port, usually from GAMMA
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ POSTMASK output to the input of the next desired component in the
+ display pipeline, for example one of the available DITHER blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
index 39dbb5c8bcf8..edb8d3b67025 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
@@ -86,6 +86,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: RDMA input port, usually from MMSYS, OD or OVL
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ RDMA output to the input of the next desired component in the
+ display pipeline, for example one of the available COLOR, DPI,
+ DSI, MERGE or UFOE blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
index 39e3e2d4a0db..61a5e22effbf 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
@@ -43,6 +43,27 @@ properties:
items:
- description: UFOe Clock
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: UFOE input, usually from one of the RDMA blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ UFOE output to the input of the next desired component in the
+ display pipeline, usually one of the available DSI blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
--
2.44.0
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
From: AngeloGioacchino Del Regno @ 2024-04-09 12:02 UTC (permalink / raw)
To: chunkuang.hu
Cc: robh, krzysztof.kozlowski+dt, conor+dt, p.zabel, airlied, daniel,
maarten.lankhorst, mripard, tzimmermann, matthias.bgg,
angelogioacchino.delregno, shawn.sung, yu-chang.lee, ck.hu,
jitao.shi, devicetree, linux-kernel, dri-devel, linux-mediatek,
linux-arm-kernel, wenst, kernel
In-Reply-To: <20240409120211.321153-1-angelogioacchino.delregno@collabora.com>
Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
per HW instance (so potentially up to six displays for multi-vdo SoCs).
The MMSYS or VDOSYS is always the first component in the DDP pipeline,
so it only supports an output port with multiple endpoints - where each
endpoint defines the starting point for one of the (currently three)
possible hardware paths.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
index b3c6888c1457..4e9acd966aa5 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
@@ -93,6 +93,29 @@ properties:
'#reset-cells':
const: 1
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output port node. This port connects the MMSYS/VDOSYS output to
+ the first component of one display pipeline, for example one of
+ the available OVL or RDMA blocks.
+ Some MediaTek SoCs support up to three display outputs per MMSYS.
+ properties:
+ endpoint@0:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: Output to the primary display pipeline
+
+ endpoint@1:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: Output to the secondary display pipeline
+
+ endpoint@2:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: Output to the tertiary display pipeline
+
+ required:
+ - endpoint@0
+
required:
- compatible
- reg
--
2.44.0
^ permalink raw reply related
* [PATCH v2 3/3] drm/mediatek: Implement OF graphs support for display paths
From: AngeloGioacchino Del Regno @ 2024-04-09 12:02 UTC (permalink / raw)
To: chunkuang.hu
Cc: robh, krzysztof.kozlowski+dt, conor+dt, p.zabel, airlied, daniel,
maarten.lankhorst, mripard, tzimmermann, matthias.bgg,
angelogioacchino.delregno, shawn.sung, yu-chang.lee, ck.hu,
jitao.shi, devicetree, linux-kernel, dri-devel, linux-mediatek,
linux-arm-kernel, wenst, kernel
In-Reply-To: <20240409120211.321153-1-angelogioacchino.delregno@collabora.com>
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configuration for 10 SoCs and this is going to
grow larger and larger, and with new hacks like the introduction of
mtk_drm_route which is anyway not enough for all final routes as the
DSI cannot be connected to MERGE if it's not a dual-DSI, or enabling
DSC preventively doesn't work if the display doesn't support it, or
others.
Since practically all display IPs in MediaTek SoCs support being
interconnected with different instances of other, or the same, IPs
or with different IPs and in different combinations, the final DDP
pipeline is effectively a board specific configuration.
Implement OF graphs support to the mediatek-drm drivers, allowing to
stop hardcoding the paths, and preventing this driver to get a huge
amount of arrays for each board and SoC combination, also paving the
way to share the same mtk_mmsys_driver_data between multiple SoCs,
making it more straightforward to add support for new chips.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 16 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 255 ++++++++++++++++++++++---
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
4 files changed, 250 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index beb7d9d08e97..c47648d244fe 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -705,6 +705,15 @@ static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
{
struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+ dpi->next_bridge = devm_drm_of_get_bridge(dpi->dev, dpi->dev->of_node, 1, -1);
+ if (IS_ERR(dpi->next_bridge)) {
+ /* Old devicetree has only one endpoint */
+ dpi->next_bridge = devm_drm_of_get_bridge(dpi->dev, dpi->dev->of_node, 0, 0);
+ if (IS_ERR(dpi->next_bridge))
+ return dev_err_probe(dpi->dev, PTR_ERR(dpi->next_bridge),
+ "Failed to get bridge\n");
+ }
+
return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
&dpi->bridge, flags);
}
@@ -1055,13 +1064,6 @@ static int mtk_dpi_probe(struct platform_device *pdev)
if (dpi->irq < 0)
return dpi->irq;
- dpi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, 0);
- if (IS_ERR(dpi->next_bridge))
- return dev_err_probe(dev, PTR_ERR(dpi->next_bridge),
- "Failed to get bridge\n");
-
- dev_info(dev, "Found bridge node: %pOF\n", dpi->next_bridge->of_node);
-
platform_set_drvdata(pdev, dpi);
dpi->bridge.funcs = &mtk_dpi_bridge_funcs;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 74832c213092..2baefa06ad16 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -796,12 +796,200 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
{ }
};
+static int mtk_drm_of_get_ddp_comp_type(struct device_node *node, enum mtk_ddp_comp_type *ctype)
+{
+ const struct of_device_id *of_id = of_match_node(mtk_ddp_comp_dt_ids, node);
+
+ if (!of_id)
+ return -EINVAL;
+
+ *ctype = (enum mtk_ddp_comp_type)((uintptr_t)of_id->data);
+
+ return 0;
+}
+
+static int mtk_drm_of_get_ddp_ep_cid(struct device_node *node,
+ int output_port, enum mtk_drm_crtc_path crtc_path,
+ struct device_node **next, unsigned int *cid)
+{
+ struct device_node *ep_dev_node, *ep_out;
+ enum mtk_ddp_comp_type comp_type;
+ int ret;
+
+ ep_out = of_graph_get_endpoint_by_regs(node, output_port, crtc_path);
+ if (!ep_out)
+ return -ENOENT;
+
+ ep_dev_node = of_graph_get_remote_port_parent(ep_out);
+ if (!ep_dev_node)
+ return -EINVAL;
+
+ /*
+ * Pass the next node pointer regardless of failures in the later code
+ * so that if this function is called in a loop it will walk through all
+ * of the subsequent endpoints anyway.
+ */
+ *next = ep_dev_node;
+
+ if (!of_device_is_available(ep_dev_node))
+ return -ENODEV;
+
+ ret = mtk_drm_of_get_ddp_comp_type(ep_dev_node, &comp_type);
+ if (ret)
+ return ret;
+
+ ret = mtk_ddp_comp_get_id(ep_dev_node, comp_type);
+ if (ret < 0)
+ return ret;
+
+ /* All ok! Pass the Component ID to the caller. */
+ *cid = (unsigned int)ret;
+
+ return 0;
+}
+
+/**
+ * mtk_drm_of_ddp_path_build_one - Build a Display HW Pipeline for a CRTC Path
+ * @dev: The mediatek-drm device
+ * @cpath: CRTC Path relative to a VDO or MMSYS
+ * @out_path: Pointer to an array that will contain the new pipeline
+ * @out_path_len: Number of entries in the pipeline array
+ *
+ * MediaTek SoCs can use different DDP hardware pipelines (or paths) depending
+ * on the board-specific desired display configuration; this function walks
+ * through all of the output endpoints starting from a VDO or MMSYS hardware
+ * instance and builds the right pipeline as specified in device trees.
+ *
+ * Return:
+ * * %0 - Display HW Pipeline successfully built and validated
+ * * %-ENOENT - Display pipeline was not specified in device tree
+ * * %-EINVAL - Display pipeline built but validation failed
+ * * %-ENOMEM - Failure to allocate pipeline array to pass to the caller
+ */
+static int mtk_drm_of_ddp_path_build_one(struct device *dev, enum mtk_drm_crtc_path cpath,
+ const unsigned int **out_path,
+ unsigned int *out_path_len)
+{
+ struct device_node *next, *prev, *vdo = dev->parent->of_node;
+ unsigned int temp_path[DDP_COMPONENT_DRM_ID_MAX] = { 0 };
+ unsigned int *final_ddp_path;
+ unsigned short int idx = 0;
+ int ret;
+
+ /* Get the first entry for the temp_path array */
+ ret = mtk_drm_of_get_ddp_ep_cid(vdo, 0, cpath, &next, &temp_path[idx++]);
+ if (ret) {
+ if (next)
+ dev_err(dev, "Invalid component %pOF\n", next);
+ else
+ dev_err(dev, "Cannot find first endpoint for path %d\n", cpath);
+
+ return ret;
+ }
+
+ /*
+ * Walk through port outputs until we reach the last valid mediatek-drm component.
+ * To be valid, this must end with an "invalid" component that is a display node.
+ */
+ do {
+ prev = next;
+ ret = mtk_drm_of_get_ddp_ep_cid(next, 1, cpath, &next, &temp_path[idx]);
+ of_node_put(prev);
+ if (ret) {
+ of_node_put(next);
+ break;
+ }
+ } while (++idx < DDP_COMPONENT_DRM_ID_MAX);
+
+ /* If the last entry is not a final display output, the configuration is wrong */
+ switch (temp_path[idx - 1]) {
+ case DDP_COMPONENT_DP_INTF0:
+ case DDP_COMPONENT_DP_INTF1:
+ case DDP_COMPONENT_DPI0:
+ case DDP_COMPONENT_DPI1:
+ case DDP_COMPONENT_DSI0:
+ case DDP_COMPONENT_DSI1:
+ case DDP_COMPONENT_DSI2:
+ case DDP_COMPONENT_DSI3:
+ break;
+ default:
+ dev_err(dev, "Invalid display hw pipeline. Last component: %d (ret=%d)\n",
+ temp_path[idx - 1], ret);
+ return -EINVAL;
+ }
+
+ final_ddp_path = devm_kmemdup(dev, temp_path, idx * sizeof(temp_path[0]), GFP_KERNEL);
+ if (!final_ddp_path)
+ return -ENOMEM;
+
+ dev_dbg(dev, "Display HW Pipeline built with %d components.\n", idx);
+
+ /* Pipeline built! */
+ *out_path = final_ddp_path;
+ *out_path_len = idx;
+
+ return 0;
+}
+
+static int mtk_drm_of_ddp_path_build(struct device *dev, struct device_node *node,
+ struct mtk_mmsys_driver_data *data)
+{
+ struct device_node *ep_node;
+ struct of_endpoint of_ep;
+ bool output_present[MAX_CRTC] = { false };
+ int ret;
+
+ for_each_endpoint_of_node(node, ep_node) {
+ ret = of_graph_parse_endpoint(ep_node, &of_ep);
+ of_node_put(ep_node);
+ if (ret) {
+ dev_err_probe(dev, ret, "Cannot parse endpoint\n");
+ break;
+ }
+
+ if (of_ep.port >= MAX_CRTC) {
+ ret = dev_err_probe(dev, -EINVAL,
+ "Invalid endpoint%u number\n", of_ep.port);
+ break;
+ }
+
+ output_present[of_ep.port] = true;
+ }
+
+ if (ret)
+ return ret;
+
+ if (output_present[CRTC_MAIN]) {
+ ret = mtk_drm_of_ddp_path_build_one(dev, CRTC_MAIN,
+ &data->main_path, &data->main_len);
+ if (ret)
+ return ret;
+ }
+
+ if (output_present[CRTC_EXT]) {
+ ret = mtk_drm_of_ddp_path_build_one(dev, CRTC_EXT,
+ &data->ext_path, &data->ext_len);
+ if (ret)
+ return ret;
+ }
+
+ if (output_present[CRTC_THIRD]) {
+ ret = mtk_drm_of_ddp_path_build_one(dev, CRTC_THIRD,
+ &data->third_path, &data->third_len);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
static int mtk_drm_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *phandle = dev->parent->of_node;
const struct of_device_id *of_id;
struct mtk_drm_private *private;
+ struct mtk_mmsys_driver_data *mtk_drm_data;
struct device_node *node;
struct component_match *match = NULL;
struct platform_device *ovl_adaptor;
@@ -822,7 +1010,31 @@ static int mtk_drm_probe(struct platform_device *pdev)
if (!of_id)
return -ENODEV;
- private->data = of_id->data;
+ mtk_drm_data = (struct mtk_mmsys_driver_data *)of_id->data;
+ if (!mtk_drm_data)
+ return -EINVAL;
+
+ private->data = kmemdup(mtk_drm_data, sizeof(*mtk_drm_data), GFP_KERNEL);
+ if (!private->data)
+ return -ENOMEM;
+
+ /* Try to build the display pipeline from devicetree graphs */
+ if (of_graph_is_present(phandle)) {
+ dev_dbg(dev, "Building display pipeline for MMSYS %u\n",
+ mtk_drm_data->mmsys_id);
+ private->data = devm_kmemdup(dev, mtk_drm_data,
+ sizeof(*mtk_drm_data), GFP_KERNEL);
+ if (!private->data)
+ return -ENOMEM;
+
+ ret = mtk_drm_of_ddp_path_build(dev, phandle, private->data);
+ if (ret)
+ return ret;
+ } else {
+ /* No devicetree graphs support: go with hardcoded paths if present */
+ dev_dbg(dev, "Using hardcoded paths for MMSYS %u\n", mtk_drm_data->mmsys_id);
+ private->data = mtk_drm_data;
+ };
private->all_drm_private = devm_kmalloc_array(dev, private->data->mmsys_dev_num,
sizeof(*private->all_drm_private),
@@ -844,12 +1056,11 @@ static int mtk_drm_probe(struct platform_device *pdev)
/* Iterate over sibling DISP function blocks */
for_each_child_of_node(phandle->parent, node) {
- const struct of_device_id *of_id;
enum mtk_ddp_comp_type comp_type;
int comp_id;
- of_id = of_match_node(mtk_ddp_comp_dt_ids, node);
- if (!of_id)
+ ret = mtk_drm_of_get_ddp_comp_type(node, &comp_type);
+ if (ret)
continue;
if (!of_device_is_available(node)) {
@@ -858,8 +1069,6 @@ static int mtk_drm_probe(struct platform_device *pdev)
continue;
}
- comp_type = (enum mtk_ddp_comp_type)(uintptr_t)of_id->data;
-
if (comp_type == MTK_DISP_MUTEX) {
int id;
@@ -888,22 +1097,24 @@ static int mtk_drm_probe(struct platform_device *pdev)
* blocks have separate component platform drivers and initialize their own
* DDP component structure. The others are initialized here.
*/
- if (comp_type == MTK_DISP_AAL ||
- comp_type == MTK_DISP_CCORR ||
- comp_type == MTK_DISP_COLOR ||
- comp_type == MTK_DISP_GAMMA ||
- comp_type == MTK_DISP_MERGE ||
- comp_type == MTK_DISP_OVL ||
- comp_type == MTK_DISP_OVL_2L ||
- comp_type == MTK_DISP_OVL_ADAPTOR ||
- comp_type == MTK_DISP_RDMA ||
- comp_type == MTK_DP_INTF ||
- comp_type == MTK_DPI ||
- comp_type == MTK_DSI) {
- dev_info(dev, "Adding component match for %pOF\n",
- node);
- drm_of_component_match_add(dev, &match, component_compare_of,
- node);
+ switch (comp_type) {
+ default:
+ break;
+ case MTK_DISP_AAL:
+ case MTK_DISP_CCORR:
+ case MTK_DISP_COLOR:
+ case MTK_DISP_GAMMA:
+ case MTK_DISP_MERGE:
+ case MTK_DISP_OVL:
+ case MTK_DISP_OVL_2L:
+ case MTK_DISP_OVL_ADAPTOR:
+ case MTK_DISP_RDMA:
+ case MTK_DP_INTF:
+ case MTK_DPI:
+ case MTK_DSI:
+ dev_info(dev, "Adding component match for %pOF\n", node);
+ drm_of_component_match_add(dev, &match, component_compare_of, node);
+ break;
}
ret = mtk_ddp_comp_init(node, &private->ddp_comp[comp_id], comp_id);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index 33fadb08dc1c..9b2a7045e69d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -59,7 +59,7 @@ struct mtk_drm_private {
struct device *mmsys_dev;
struct device_node *comp_node[DDP_COMPONENT_DRM_ID_MAX];
struct mtk_ddp_comp ddp_comp[DDP_COMPONENT_DRM_ID_MAX];
- const struct mtk_mmsys_driver_data *data;
+ struct mtk_mmsys_driver_data *data;
struct drm_atomic_state *suspend_state;
unsigned int mbox_index;
struct mtk_drm_private **all_drm_private;
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 9501f4019199..1bdbe43e3888 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -903,9 +903,13 @@ static int mtk_dsi_host_attach(struct mipi_dsi_host *host,
dsi->lanes = device->lanes;
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
- dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, 0);
- if (IS_ERR(dsi->next_bridge))
- return PTR_ERR(dsi->next_bridge);
+ dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
+ if (IS_ERR(dsi->next_bridge)) {
+ /* Old devicetree has only one endpoint */
+ dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, 0);
+ if (IS_ERR(dsi->next_bridge))
+ return PTR_ERR(dsi->next_bridge);
+ }
drm_bridge_add(&dsi->bridge);
--
2.44.0
^ permalink raw reply related
* Re: [PATCH 0/9] rtc: convert multiple bindings into dtschema
From: Javier Carrasco @ 2024-04-09 12:02 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue, linux-rtc, devicetree, linux-kernel,
linux-arm-kernel, linux-aspeed, linux-stm32
In-Reply-To: <20240409102658d86fb2bd@mail.local>
On 4/9/24 12:26, Alexandre Belloni wrote:
> On 08/04/2024 17:53:00+0200, Javier Carrasco wrote:
>> This series converts the following bindings into dtschema, moving them
>> to trivial-rtc whenever possible:
>>
>> - orion-rtc: trival-rtc, referenced in arm arch.
>> - google,goldfish-rtc: trivial-rtc, referenced in mips arch.
>> - lpc32xx-rtc: trival-rtc, referenced in arm arch.
>> - maxim,ds1742: trivial-rtc, not referenced in arch, cheap conversion.
>> - rtc-aspeed: 3 devices to trivial-rtc, all referenced in arm arch.
>> - pxa-rtc: add missing properties and convert. Referenced in arm arch.
>> - st,spear600-rtc: trivial-rtc, referenced in arm arch.
>> - stmp3xxx-rtc: convert, referenced in arm arch.
>> - via,vt8500-rtc: trivial-rtc, referenced in arm arch.
>
> Probably all the moves to trivial-rtc can be squashed.
>
Sure, I will squash them for v2.
Best regards,
Javier Carrasco
^ 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-09 12: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: <20240408-numerator-escargot-a642507a598e@spud>
[-- Attachment #1: Type: text/plain, Size: 8826 bytes --]
On Mon, Apr 08, 2024 at 06:05:51PM +0100, Conor Dooley wrote:
> > > 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 :)
Something like the below?
-- >8 --
From a12f281d2cb869bcd9a6ffc45d0c6a0d3aa2e9e2 Mon Sep 17 00:00:00 2001
From: Conor Dooley <conor.dooley@microchip.com>
Date: Tue, 9 Apr 2024 11:54:34 +0100
Subject: [PATCH] clock, reset: microchip: move all mpfs reset code to the
reset subsystem
<insert something here>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
drivers/clk/microchip/clk-mpfs.c | 90 +-------------------------------
drivers/reset/reset-mpfs.c | 74 +++++++++++++++++++++++---
include/soc/microchip/mpfs.h | 10 ++--
3 files changed, 73 insertions(+), 101 deletions(-)
diff --git a/drivers/clk/microchip/clk-mpfs.c b/drivers/clk/microchip/clk-mpfs.c
index 22eab91a6712..432080c35cec 100644
--- a/drivers/clk/microchip/clk-mpfs.c
+++ b/drivers/clk/microchip/clk-mpfs.c
@@ -4,7 +4,6 @@
*
* Copyright (C) 2020-2022 Microchip Technology Inc. All rights reserved.
*/
-#include <linux/auxiliary_bus.h>
#include <linux/clk-provider.h>
#include <linux/io.h>
#include <linux/module.h>
@@ -361,93 +360,6 @@ static int mpfs_clk_register_periphs(struct device *dev, struct mpfs_periph_hw_c
return 0;
}
-/*
- * Peripheral clock resets
- */
-
-#if IS_ENABLED(CONFIG_RESET_CONTROLLER)
-
-u32 mpfs_reset_read(struct device *dev)
-{
- struct mpfs_clock_data *clock_data = dev_get_drvdata(dev->parent);
-
- return readl_relaxed(clock_data->base + REG_SUBBLK_RESET_CR);
-}
-EXPORT_SYMBOL_NS_GPL(mpfs_reset_read, MCHP_CLK_MPFS);
-
-void mpfs_reset_write(struct device *dev, u32 val)
-{
- struct mpfs_clock_data *clock_data = dev_get_drvdata(dev->parent);
-
- writel_relaxed(val, clock_data->base + REG_SUBBLK_RESET_CR);
-}
-EXPORT_SYMBOL_NS_GPL(mpfs_reset_write, MCHP_CLK_MPFS);
-
-static void mpfs_reset_unregister_adev(void *_adev)
-{
- struct auxiliary_device *adev = _adev;
-
- auxiliary_device_delete(adev);
- auxiliary_device_uninit(adev);
-}
-
-static void mpfs_reset_adev_release(struct device *dev)
-{
- struct auxiliary_device *adev = to_auxiliary_dev(dev);
-
- kfree(adev);
-}
-
-static struct auxiliary_device *mpfs_reset_adev_alloc(struct mpfs_clock_data *clk_data)
-{
- struct auxiliary_device *adev;
- int ret;
-
- adev = kzalloc(sizeof(*adev), GFP_KERNEL);
- if (!adev)
- return ERR_PTR(-ENOMEM);
-
- adev->name = "reset-mpfs";
- adev->dev.parent = clk_data->dev;
- adev->dev.release = mpfs_reset_adev_release;
- adev->id = 666u;
-
- ret = auxiliary_device_init(adev);
- if (ret) {
- kfree(adev);
- return ERR_PTR(ret);
- }
-
- return adev;
-}
-
-static int mpfs_reset_controller_register(struct mpfs_clock_data *clk_data)
-{
- struct auxiliary_device *adev;
- int ret;
-
- adev = mpfs_reset_adev_alloc(clk_data);
- if (IS_ERR(adev))
- return PTR_ERR(adev);
-
- ret = auxiliary_device_add(adev);
- if (ret) {
- auxiliary_device_uninit(adev);
- return ret;
- }
-
- return devm_add_action_or_reset(clk_data->dev, mpfs_reset_unregister_adev, adev);
-}
-
-#else /* !CONFIG_RESET_CONTROLLER */
-
-static int mpfs_reset_controller_register(struct mpfs_clock_data *clk_data)
-{
- return 0;
-}
-
-#endif /* !CONFIG_RESET_CONTROLLER */
-
static int mpfs_clk_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -499,7 +411,7 @@ static int mpfs_clk_probe(struct platform_device *pdev)
if (ret)
return ret;
- return mpfs_reset_controller_register(clk_data);
+ return mpfs_reset_controller_register(dev, clk_data->base + REG_SUBBLK_RESET_CR);
}
static const struct of_device_id mpfs_clk_of_match_table[] = {
diff --git a/drivers/reset/reset-mpfs.c b/drivers/reset/reset-mpfs.c
index 7f3fb2d472f4..27cd68b4ee81 100644
--- a/drivers/reset/reset-mpfs.c
+++ b/drivers/reset/reset-mpfs.c
@@ -8,6 +8,7 @@
*/
#include <linux/auxiliary_bus.h>
#include <linux/delay.h>
+#include <linux/io.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
@@ -28,10 +29,11 @@
/* block concurrent access to the soft reset register */
static DEFINE_SPINLOCK(mpfs_reset_lock);
+static void __iomem *mpfs_reset_addr;
+
/*
* Peripheral clock resets
*/
-
static int mpfs_assert(struct reset_controller_dev *rcdev, unsigned long id)
{
unsigned long flags;
@@ -39,9 +41,9 @@ static int mpfs_assert(struct reset_controller_dev *rcdev, unsigned long id)
spin_lock_irqsave(&mpfs_reset_lock, flags);
- reg = mpfs_reset_read(rcdev->dev);
+ reg = readl(mpfs_reset_addr);
reg |= BIT(id);
- mpfs_reset_write(rcdev->dev, reg);
+ writel(reg, mpfs_reset_addr);
spin_unlock_irqrestore(&mpfs_reset_lock, flags);
@@ -55,9 +57,9 @@ static int mpfs_deassert(struct reset_controller_dev *rcdev, unsigned long id)
spin_lock_irqsave(&mpfs_reset_lock, flags);
- reg = mpfs_reset_read(rcdev->dev);
+ reg = readl(mpfs_reset_addr);
reg &= ~BIT(id);
- mpfs_reset_write(rcdev->dev, reg);
+ writel(reg, mpfs_reset_addr);
spin_unlock_irqrestore(&mpfs_reset_lock, flags);
@@ -66,7 +68,7 @@ static int mpfs_deassert(struct reset_controller_dev *rcdev, unsigned long id)
static int mpfs_status(struct reset_controller_dev *rcdev, unsigned long id)
{
- u32 reg = mpfs_reset_read(rcdev->dev);
+ u32 reg = readl(mpfs_reset_addr);
/*
* It is safe to return here as MPFS_NUM_RESETS makes sure the sign bit
@@ -137,9 +139,67 @@ static int mpfs_reset_probe(struct auxiliary_device *adev,
return devm_reset_controller_register(dev, rcdev);
}
+static void mpfs_reset_unregister_adev(void *_adev)
+{
+ struct auxiliary_device *adev = _adev;
+
+ auxiliary_device_delete(adev);
+ auxiliary_device_uninit(adev);
+}
+
+static void mpfs_reset_adev_release(struct device *dev)
+{
+ struct auxiliary_device *adev = to_auxiliary_dev(dev);
+
+ kfree(adev);
+}
+
+static struct auxiliary_device *mpfs_reset_adev_alloc(struct device *clk_dev)
+{
+ struct auxiliary_device *adev;
+ int ret;
+
+ adev = kzalloc(sizeof(*adev), GFP_KERNEL);
+ if (!adev)
+ return ERR_PTR(-ENOMEM);
+
+ adev->name = "reset-mpfs";
+ adev->dev.parent = clk_dev;
+ adev->dev.release = mpfs_reset_adev_release;
+ adev->id = 666u;
+
+ ret = auxiliary_device_init(adev);
+ if (ret) {
+ kfree(adev);
+ return ERR_PTR(ret);
+ }
+
+ return adev;
+}
+
+int mpfs_reset_controller_register(struct device *clk_dev, void __iomem *base)
+{
+ struct auxiliary_device *adev;
+ int ret;
+
+ mpfs_reset_addr = base;
+
+ adev = mpfs_reset_adev_alloc(clk_dev);
+ if (IS_ERR(adev))
+ return PTR_ERR(adev);
+
+ ret = auxiliary_device_add(adev);
+ if (ret) {
+ auxiliary_device_uninit(adev);
+ return ret;
+ }
+
+ return devm_add_action_or_reset(clk_dev, mpfs_reset_unregister_adev, adev);
+}
+
static const struct auxiliary_device_id mpfs_reset_ids[] = {
{
- .name = "clk_mpfs.reset-mpfs",
+ .name = "reset_mpfs.reset-mpfs",
},
{ }
};
diff --git a/include/soc/microchip/mpfs.h b/include/soc/microchip/mpfs.h
index 09722f83b0ca..0b756bf5e9bd 100644
--- a/include/soc/microchip/mpfs.h
+++ b/include/soc/microchip/mpfs.h
@@ -43,11 +43,11 @@ struct mtd_info *mpfs_sys_controller_get_flash(struct mpfs_sys_controller *mpfs_
#endif /* if IS_ENABLED(CONFIG_POLARFIRE_SOC_SYS_CTRL) */
#if IS_ENABLED(CONFIG_MCHP_CLK_MPFS)
-
-u32 mpfs_reset_read(struct device *dev);
-
-void mpfs_reset_write(struct device *dev, u32 val);
-
+#if IS_ENABLED(CONFIG_RESET_CONTROLLER)
+int mpfs_reset_controller_register(struct device *clk_dev, void __iomem *base);
+#else
+int mpfs_reset_controller_register(struct device *clk_dev, void* __iomem base) { return 0;}
+#endif /* if IS_ENABLED(CONFIG_RESET_CONTROLLER) */
#endif /* if IS_ENABLED(CONFIG_MCHP_CLK_MPFS) */
#endif /* __SOC_MPFS_H__ */
--
2.43.0
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply related
* Re: [PATCH v2 03/18] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC
From: Rob Herring @ 2024-04-09 12:10 UTC (permalink / raw)
To: Alexandre Mergnat
Cc: dri-devel, linux-sound, linaro-mm-sig, Rob Herring, Conor Dooley,
Catalin Marinas, Krzysztof Kozlowski, linux-media,
Christian König, Flora Fu, Mark Brown, Lee Jones,
Takashi Iwai, Will Deacon, Sumit Semwal, linux-mediatek,
Liam Girdwood, AngeloGioacchino Del Regno, devicetree,
linux-arm-kernel, linux-kernel, Matthias Brugger, Jaroslav Kysela
In-Reply-To: <20240226-audio-i350-v2-3-3043d483de0d@baylibre.com>
On Tue, 09 Apr 2024 12:13:24 +0200, Alexandre Mergnat wrote:
> Add the audio codec sub-device. This sub-device is used to set required
> and optional voltage properties between the codec and the board.
>
> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
> ---
> Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml:
Error in referenced schema matching $id: http://devicetree.org/schemas/sound/mt6357.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240226-audio-i350-v2-3-3043d483de0d@baylibre.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v2 04/18] ASoC: dt-bindings: mt6357: Add audio codec document
From: Rob Herring @ 2024-04-09 12:10 UTC (permalink / raw)
To: Alexandre Mergnat
Cc: Rob Herring, Sumit Semwal, Flora Fu, AngeloGioacchino Del Regno,
dri-devel, Mark Brown, devicetree, Krzysztof Kozlowski,
Catalin Marinas, linux-media, Jaroslav Kysela,
Christian König, Takashi Iwai, Conor Dooley, linux-mediatek,
Lee Jones, linux-kernel, Will Deacon, linaro-mm-sig,
Matthias Brugger, linux-sound, linux-arm-kernel, Liam Girdwood
In-Reply-To: <20240226-audio-i350-v2-4-3043d483de0d@baylibre.com>
On Tue, 09 Apr 2024 12:13:25 +0200, Alexandre Mergnat wrote:
> Add MT8365 audio codec bindings to set required
> and optional voltage properties between the codec and the board.
> The properties are:
> - phandle of the requiered power supply.
> - Setup of microphone bias voltage.
> - Setup of the speaker pin pull-down.
>
> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
> ---
> .../devicetree/bindings/sound/mt6357.yaml | 54 ++++++++++++++++++++++
> 1 file changed, 54 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/sound/mt6357.yaml: properties:vaud28-supply: '$ref' is not one of ['description', 'deprecated']
from schema $id: http://devicetree.org/meta-schemas/core.yaml#
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240226-audio-i350-v2-4-3043d483de0d@baylibre.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: qcom: msm8974: Use proper compatible for APCS syscon
From: AngeloGioacchino Del Regno @ 2024-04-09 12:11 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel, Jassi Brar,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Matthias Brugger, Jacky Huang, Shan-Chun Hung
Cc: linux-arm-msm, linux-kernel, devicetree, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20240408-msm8974-apcs-v1-2-90cb7368836e@z3ntu.xyz>
Il 08/04/24 21:32, Luca Weiss ha scritto:
> Use the apcs-kpss-global compatible for the APCS global mailbox block
> found on this SoC.
>
> This also resolves a dt-binding checker warning:
>
> arch/arm/boot/dts/qcom/qcom-msm8974pro-fairphone-fp2.dtb: syscon@f9011000: compatible: 'anyOf' conditional failed, one must be fixed:
> ['syscon'] is too short
> 'syscon' is not one of ['allwinner,sun8i-a83t-system-controller', 'allwinner,sun8i-h3-system-controller', 'allwinner,sun8i-v3s-system-controller', 'allwinner,sun50i-a64-system-controller', 'amd,pensando-elba-syscon', 'brcm,cru-clkset', 'freecom,fsg-cs2-system-controller', 'fsl,imx93-aonmix-ns-syscfg', 'fsl,imx93-wakeupmix-syscfg', 'hisilicon,dsa-subctrl', 'hisilicon,hi6220-sramctrl', 'hisilicon,pcie-sas-subctrl', 'hisilicon,peri-subctrl', 'hpe,gxp-sysreg', 'intel,lgm-syscon', 'loongson,ls1b-syscon', 'loongson,ls1c-syscon', 'marvell,armada-3700-usb2-host-misc', 'mediatek,mt8135-pctl-a-syscfg', 'mediatek,mt8135-pctl-b-syscfg', 'mediatek,mt8365-syscfg', 'microchip,lan966x-cpu-syscon', 'microchip,sparx5-cpu-syscon', 'mstar,msc313-pmsleep', 'nuvoton,ma35d1-sys', 'nuvoton,wpcm450-shm', 'rockchip,px30-qos', 'rockchip,rk3036-qos', 'rockchip,rk3066-qos', 'rockchip,rk3128-qos', 'rockchip,rk3228-qos', 'rockchip,rk3288-qos', 'rockchip,rk3368-qos', 'rockchip,rk3399-qos', 'rockchip,rk356
> 8-qos', 'rockchip,rk3588-qos', 'rockchip,rv1126-qos', 'starfive,jh7100-sysmain', 'ti,am62-usb-phy-ctrl', 'ti,am654-dss-oldi-io-ctrl', 'ti,am654-serdes-ctrl', 'ti,j784s4-pcie-ctrl']
> from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: mailbox: qcom: Add MSM8974 APCS compatible
From: AngeloGioacchino Del Regno @ 2024-04-09 12:11 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel, Jassi Brar,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Matthias Brugger, Jacky Huang, Shan-Chun Hung
Cc: linux-arm-msm, linux-kernel, devicetree, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20240408-msm8974-apcs-v1-1-90cb7368836e@z3ntu.xyz>
Il 08/04/24 21:32, Luca Weiss ha scritto:
> Add compatible for the Qualcomm MSM8974 APCS block.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
^ permalink raw reply
* Re: [PATCH 3/9] dt-bindings: rtc: lpc32xx-rtc: move to trivial-rtc
From: Alexandre Belloni @ 2024-04-09 12:11 UTC (permalink / raw)
To: Javier Carrasco
Cc: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jiaxun Yang, Vladimir Zapolskiy, Joel Stanley,
Andrew Jeffery, Maxime Coquelin, Alexandre Torgue, linux-rtc,
devicetree, linux-kernel, linux-arm-kernel, linux-aspeed,
linux-stm32
In-Reply-To: <6dc808bf-682f-4e91-aac7-7ce6f05a0ab4@gmail.com>
On 09/04/2024 10:52:54+0200, Javier Carrasco wrote:
> On 4/9/24 09:34, Krzysztof Kozlowski wrote:
> > On 08/04/2024 17:53, Javier Carrasco wrote:
> >> This RTC 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/lpc32xx-rtc.txt | 15 ---------------
> >> Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
> >> 2 files changed, 2 insertions(+), 15 deletions(-)
> >
> > This one no... and if you tested DTS you would see errors, although you
> > need to test specific lpc config, not multi_v7.
> >
> > It does not look like you tested the DTS against bindings. Please run
> > `make dtbs_check W=1` (see
> > Documentation/devicetree/bindings/writing-schema.rst or
> > https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> > for instructions).
> >
> > Anyway, you *must* check all DTS before moving anything to trivial.
> >
> > Does it mean all other bindings were not checked against DTS at all?
> >
> > Best regards,
> > Krzysztof
> >
> Hi,
>
> I did check the conversion against nxp/lpc/lpc3250-phy3250.dts, which
> throws a message about the 'clocks' property.
>
> That property is not documented in the original binding, and even though
> it could be missing, I could not find any function to get a clock (i.e.
> any form of clk_get()) in rtc-lpc32xx.c, which is the only file where
> the compatible can be found.
>
> Is therefore the property not useless in the dts? My apologies if I am
> missing something here.
The bindings doesn't document the driver but the hardware. In this case,
the only input clock seems to be a 32kHz crystal.
>
> Thanks and best regards,
> Javier Carrasco
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] riscv: dts: sophgo: add initial Milk-V Duo S board device tree
From: Conor Dooley @ 2024-04-09 12:13 UTC (permalink / raw)
To: Inochi Amaoto
Cc: michael.opdenacker, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen Wang, Paul Walmsley, Palmer Dabbelt, Albert Ou,
devicetree, linux-riscv, linux-kernel
In-Reply-To: <IA1PR20MB49532A8D4294ADCE0C33A654BB072@IA1PR20MB4953.namprd20.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]
On Tue, Apr 09, 2024 at 03:17:35PM +0800, Inochi Amaoto wrote:
> On Tue, Apr 09, 2024 at 08:45:04AM +0200, michael.opdenacker@bootlin.com wrote:
> > From: Michael Opdenacker <michael.opdenacker@bootlin.com>
> >
> > This adds initial support for the Milk-V Duo S board
> > (https://milkv.io/duo-s), enabling the serial port and
> > read-only SD card support, allowing to boot Linux to the
> > command line.
> >
>
> Hi Michael,
>
> I think your patch losts the board binding and have wrong compatiable.
> Also, the SD can have rw support with proper property. See link [1]
> (need 'disable-wp').
[1] doesn't go anywhere useful.
> I suggest you resubmitting this patch after applying clk patchs.
> This could reduce some unnecessary change. For now, you can just
> use the dts for huashan-pi (with changed memory size).
Why would using patched huashan-pi dts be more suitable than carrying
a local patch for duo-s devicetree? What am I missing?
Cheers,
Conor.
>
> [1]: https://lore.kernel.org/linux-riscv/IA1PR20MB4953B158F6F575840F3D4267BB7D2@IA1PR20MB4953.namprd20.prod.outlook.com/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v7 1/5] dt-bindings: interconnect: Add Qualcomm IPQ9574 support
From: Krzysztof Kozlowski @ 2024-04-09 12:20 UTC (permalink / raw)
To: Varadarajan Narayanan
Cc: andersson, konrad.dybcio, mturquette, sboyd, robh, krzk+dt,
conor+dt, djakov, dmitry.baryshkov, quic_anusha, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-pm
In-Reply-To: <ZhUghsa5Do5m7wrX@hu-varada-blr.qualcomm.com>
On 09/04/2024 13:03, Varadarajan Narayanan wrote:
> On Tue, Apr 09, 2024 at 11:45:51AM +0200, Krzysztof Kozlowski wrote:
>> On 09/04/2024 09:41, Varadarajan Narayanan wrote:
>>> On Thu, Apr 04, 2024 at 02:25:06PM +0530, Varadarajan Narayanan wrote:
>>>> On Wed, Apr 03, 2024 at 04:59:40PM +0200, Krzysztof Kozlowski wrote:
>>>>> On 03/04/2024 12:42, Varadarajan Narayanan wrote:
>>>>>> Add interconnect-cells to clock provider so that it can be
>>>>>> used as icc provider.
>>>>>>
>>>>>> Add master/slave ids for Qualcomm IPQ9574 Network-On-Chip
>>>>>> interfaces. This will be used by the gcc-ipq9574 driver
>>>>>> that will for providing interconnect services using the
>>>>>> icc-clk framework.
>>>>>>
>>>>>> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
>>>>>> ---
>>>>>> v7:
>>>>>> Fix macro names to be consistent with other bindings
>>>>>> v6:
>>>>>> Removed Reviewed-by: Krzysztof Kozlowski
>>>>>> Redefine the bindings such that driver and DT can share them
>>>>>>
>>>>>> v3:
>>>>>> Squash Documentation/ and include/ changes into same patch
>>>>>>
>>>>>> qcom,ipq9574.h
>>>>>> Move 'first id' to clock driver
>>>>>>
>>>>>> ---
>>>>>> .../bindings/clock/qcom,ipq9574-gcc.yaml | 3 +
>>>>>> .../dt-bindings/interconnect/qcom,ipq9574.h | 87 +++++++++++++++++++
>>>>>> 2 files changed, 90 insertions(+)
>>>>>> create mode 100644 include/dt-bindings/interconnect/qcom,ipq9574.h
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
>>>>>> index 944a0ea79cd6..824781cbdf34 100644
>>>>>> --- a/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/clock/qcom,ipq9574-gcc.yaml
>>>>>> @@ -33,6 +33,9 @@ properties:
>>>>>> - description: PCIE30 PHY3 pipe clock source
>>>>>> - description: USB3 PHY pipe clock source
>>>>>>
>>>>>> + '#interconnect-cells':
>>>>>> + const: 1
>>>>>> +
>>>>>> required:
>>>>>> - compatible
>>>>>> - clocks
>>>>>> diff --git a/include/dt-bindings/interconnect/qcom,ipq9574.h b/include/dt-bindings/interconnect/qcom,ipq9574.h
>>>>>> new file mode 100644
>>>>>> index 000000000000..0b076b0cf880
>>>>>> --- /dev/null
>>>>>> +++ b/include/dt-bindings/interconnect/qcom,ipq9574.h
>>>>>> @@ -0,0 +1,87 @@
>>>>>> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
>>>>>> +#ifndef INTERCONNECT_QCOM_IPQ9574_H
>>>>>> +#define INTERCONNECT_QCOM_IPQ9574_H
>>>>>> +
>>>>>> +#define ICC_ANOC_PCIE0 0
>>>>>> +#define ICC_SNOC_PCIE0 1
>>>>>> +#define ICC_ANOC_PCIE1 2
>>>>>> +#define ICC_SNOC_PCIE1 3
>>>>>> +#define ICC_ANOC_PCIE2 4
>>>>>> +#define ICC_SNOC_PCIE2 5
>>>>>> +#define ICC_ANOC_PCIE3 6
>>>>>> +#define ICC_SNOC_PCIE3 7
>>>>>> +#define ICC_SNOC_USB 8
>>>>>> +#define ICC_ANOC_USB_AXI 9
>>>>>> +#define ICC_NSSNOC_NSSCC 10
>>>>>> +#define ICC_NSSNOC_SNOC_0 11
>>>>>> +#define ICC_NSSNOC_SNOC_1 12
>>>>>> +#define ICC_NSSNOC_PCNOC_1 13
>>>>>> +#define ICC_NSSNOC_QOSGEN_REF 14
>>>>>> +#define ICC_NSSNOC_TIMEOUT_REF 15
>>>>>> +#define ICC_NSSNOC_XO_DCD 16
>>>>>> +#define ICC_NSSNOC_ATB 17
>>>>>> +#define ICC_MEM_NOC_NSSNOC 18
>>>>>> +#define ICC_NSSNOC_MEMNOC 19
>>>>>> +#define ICC_NSSNOC_MEM_NOC_1 20
>>>>>> +
>>>>>> +#define ICC_NSSNOC_PPE 0
>>>>>> +#define ICC_NSSNOC_PPE_CFG 1
>>>>>> +#define ICC_NSSNOC_NSS_CSR 2
>>>>>> +#define ICC_NSSNOC_IMEM_QSB 3
>>>>>> +#define ICC_NSSNOC_IMEM_AHB 4
>>>>>> +
>>>>>> +#define MASTER_ANOC_PCIE0 (ICC_ANOC_PCIE0 * 2)
>>>>>> +#define SLAVE_ANOC_PCIE0 ((ICC_ANOC_PCIE0 * 2) + 1)
>>>>>
>>>>> Which existing Qualcomm platform has such code?
>>>>
>>>> Existing Qualcomm platforms don't use icc-clk. They use icc-rpm
>>>> or icc-rpmh. clk-cbf-msm8996.c is the only driver that uses icc-clk.
>>>>
>>>> The icc_clk_register automatically creates master & slave nodes
>>>> for each clk entry provided as input with the node-ids 'n' and
>>>> 'n+1'. Since clk-cbf-msm8996.c has only one entry, it could just
>>>> define MASTER_CBF_M4M and SLAVE_CBF_M4M with 0 and 1 and avoid these
>>>> calculations.
>>>>
>>>> However, ipq9574 gives an array of clock entries as input to
>>>> icc_clk_register. To tie the order/sequence of these clock
>>>> entries correctly with the node-ids, this calculation is needed.
>>>>
>>>>> This is the third time I am asking for consistent headers. Open
>>>>> existing, recently added headers and look how it is done there. Why?
>>>>> Because I am against such calculations and see no reason for them.
>>>>
>>>> Apologies. Regret that I have to trouble you.
>>>>
>>>> In this ipq9574 case, have to reconcile between the following
>>>> feedbacks.
>>>>
>>>> 1. https://lore.kernel.org/linux-arm-msm/fe40b307-26d0-4b2a-869b-5d093415b9d1@linaro.org/
>>>> We could probably use indexed identifiers here to avoid confusion:
>>>> [ICC_BINDING_NAME] = CLK_BINDING_NAME
>>>>
>>>> 2. https://lore.kernel.org/linux-arm-msm/95f4e99a60cc97770fc3cee850b62faf.sboyd@kernel.org/
>>>> Are these supposed to be in a dt-binding header?
>>>>
>>>> 3. https://lore.kernel.org/linux-arm-msm/031d0a35-b192-4161-beef-97b89d5d1da6@linaro.org/
>>>> Do you use them as well in the DTS?
>>>>
>>>> Having the defines (with the calculations) seemed to to comply
>>>> with the above three feedbacks.
>>>>
>>>> Please let me know if this can be handled in a different way that
>>>> would be consistent with other Qualcomm platforms.
>>>
>>> Krzysztof,
>>>
>>> Is this ok? Can I post a new version addressing other review comments?
>>
>> I don't understand and you did not answered before, why you have to do
>> it differently than all other Qualcomm interconnect providers. Maybe the
>> code here needs it, maybe not, but I don't see any argument proving this.
>
> Other Qualcomm interconnect providers use the icc-rpm.
>
> 1. The SoC specific interconnect providers have control
> over the master/slave id-numbers and is hard coded.
>
> 2. These id-numbers are used by the RPM firmware.
>
> IPQ9574 uses icc-clk.
>
> 1. The ipq9574 specific interconnect provider doesn't
> have control over the master/slave id-numbers. The
> icc-clk framework auto generates it in the order of
> the clock entries given as input.
Okay, so what happens if icc-clk way of generating them changes a bit?
It can change, why not, driver implementation is not an ABI.
>
> 2. These auto-generated id-numbers have to be correctly
> tied to the DT nodes. Else, the relevant clocks may
> not get enabled.
Sorry, I don't get, how auto generated ID number is tied to DT node.
What DT node?
>
> Since ICC-CLK creates two ids per clock entry (one MASTER_xxx and
> one SLAVE_xxx), using those MASTER/SLAVE_xxx macros as indices in
> the below array would create holes.
>
> static int icc_ipq9574_hws[] = {
> [MASTER_ANOC_PCIE0] = GCC_ANOC_PCIE0_1LANE_M_CLK,
> [MASTER_SNOC_PCIE0] = GCC_SNOC_PCIE0_1LANE_S_CLK,
> [MASTER_ANOC_PCIE1] = GCC_ANOC_PCIE1_1LANE_M_CLK,
> [MASTER_SNOC_PCIE1] = GCC_SNOC_PCIE1_1LANE_S_CLK,
> . . .
> };
>
> Other Qualcomm drivers don't have this issue and they can
> directly use the MASTER/SLAVE_xxx macros.
I understand, thanks, yet your last patch keeps adding fake IDs, means
IDs which are not part of ABI.
>
> As the MASTER_xxx macros cannot be used, have to define a new set
> of macros that can be used for indices in the above array. This
> is the reason for the ICC_BINDING_NAME macros.
Then maybe fix the driver, instead of adding something which is not an
ABI to bindings and completely skipping the actual ABI.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: qcom: msm8974: Use proper compatible for APCS syscon
From: Krzysztof Kozlowski @ 2024-04-09 12:21 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel, Jassi Brar,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Matthias Brugger, AngeloGioacchino Del Regno,
Jacky Huang, Shan-Chun Hung
Cc: linux-arm-msm, linux-kernel, devicetree, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20240408-msm8974-apcs-v1-2-90cb7368836e@z3ntu.xyz>
On 08/04/2024 21:32, Luca Weiss wrote:
> Use the apcs-kpss-global compatible for the APCS global mailbox block
> found on this SoC.
>
> This also resolves a dt-binding checker warning:
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ 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