* [PATCH RESEND v8 1/6] dt-bindings: riscv: Add T-HEAD C908 compatible
From: Yangyu Chen @ 2024-04-07 16:28 UTC (permalink / raw)
To: linux-riscv
Cc: Conor Dooley, Damien Le Moal, Rob Herring, Krzysztof Kozlowski,
Dan Carpenter, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
devicetree, linux-kernel, Yangyu Chen, Conor Dooley
In-Reply-To: <tencent_22BA0425B4DF1CA1713B62E4423C1BFBF809@qq.com>
The thead,c908 is a RISC-V CPU core from T-HEAD Semiconductor which used
in Canaan Kendryte K230 SoC.
Signed-off-by: Yangyu Chen <cyy@cyyself.name>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Guo Ren <guoren@kernel.org>
---
Documentation/devicetree/bindings/riscv/cpus.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
index d87dd50f1a4b..d067f2a468ee 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -47,6 +47,7 @@ properties:
- sifive,u74
- sifive,u74-mc
- thead,c906
+ - thead,c908
- thead,c910
- thead,c920
- const: riscv
--
2.43.0
^ permalink raw reply related
* [PATCH RESEND v8 3/6] dt-bindings: timer: Add Canaan K230 CLINT
From: Yangyu Chen @ 2024-04-07 16:28 UTC (permalink / raw)
To: linux-riscv
Cc: Conor Dooley, Damien Le Moal, Rob Herring, Krzysztof Kozlowski,
Dan Carpenter, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
devicetree, linux-kernel, Yangyu Chen, Rob Herring
In-Reply-To: <tencent_22BA0425B4DF1CA1713B62E4423C1BFBF809@qq.com>
Add compatible string for Canaan K230 CLINT.
Signed-off-by: Yangyu Chen <cyy@cyyself.name>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Guo Ren <guoren@kernel.org>
---
Documentation/devicetree/bindings/timer/sifive,clint.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
index fced6f2d8ecb..06c67f20ad3c 100644
--- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml
+++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml
@@ -38,6 +38,7 @@ properties:
- items:
- enum:
- allwinner,sun20i-d1-clint
+ - canaan,k230-clint
- sophgo,cv1800b-clint
- sophgo,cv1812h-clint
- thead,th1520-clint
--
2.43.0
^ permalink raw reply related
* [PATCH RESEND v8 5/6] riscv: dts: add initial canmv-k230 and k230-evb dts
From: Yangyu Chen @ 2024-04-07 16:28 UTC (permalink / raw)
To: linux-riscv
Cc: Conor Dooley, Damien Le Moal, Rob Herring, Krzysztof Kozlowski,
Dan Carpenter, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
devicetree, linux-kernel, Yangyu Chen
In-Reply-To: <tencent_22BA0425B4DF1CA1713B62E4423C1BFBF809@qq.com>
Add initial dts for CanMV-K230 and K230-EVB powered by Canaan Kendryte
K230 SoC [1].
Some key consideration:
- Only place BigCore which is 1.6GHz RV64GCBV
The existence of cache coherence between the two cores remains unknown
since they have dedicated L2 caches. And the factory SDK uses it for
other OS by default. I don't know whether the two CPUs on K230 SoC
can be used in one system. So only place BigCore here.
Meanwhile, although docs from Canaan said 1.6GHz Core with Vector is
CPU1, the CSR.MHARTID of this core is 0.
- Support for "zba" "zbb" "zbc" "zbs" are tested by hand
The user manual of C908 from T-Head does not document it specifically.
It just said it supports B extension V1.0. [2]
I have tested it by using this [3] which attempts to execute "add.uw",
"andn", "clmulr", "bclr" and they doesn't traps on K230. But on JH7110,
"clmulr" and "bclr" will trap.
- Support for "zicbom" is tested by hand
Have tested with some out-of-tree drivers from [4] that need DMA and they
do not come to the dts currently.
- Support for "zicboz" is tested by hand
Have tested with my own bare mental M-Mode program [5] which tries to use
zicboz to clear a 64B aligned block and got output[6] shows it supports
zicboz.
- Cache parameters are inferred from T-Head docs [2] and Canaan docs [1]
L1i: 32KB, VIPT 4-Way set-associative, 64B Cacheline
L1d: 32KB, VIPT 4-Way set-associative, 64B Cacheline
L2: 256KB, PIPT 16-way set-associative, 64B Cacheline
The numbers of cache sets are calculated from these parameters.
- MMU only supports Sv39
The T-Head docs [2] say the C908 core can be configured to support Sv48 and
Sv39 or only Sv39. On K230, I tried to write "riscv,sv48" on mmu-type in
dts and boot the mainline kernel. However, it failed during the kernel
probe and fell back to Sv39. I also tested it on M-Mode software, writing
Sv48 to satp.mode will not trap but will leave the CSR unchanged. While
writing Sv39, it will take effect. It shows that this CPU does not support
Sv48.
- Svpbmt and T-Head MAEE both supported
T-Head C908 does support both Svpbmt and T-Head MAEE for page-based memory
attributes and is controlled by BIT(21) on CSR.MXSTATUS. The Svpbmt is used
here for mainline kernel support for K230. If the kernel wants to use
Svpbmt, the M-Mode software should unset BIT(21) of CSR.MXSTATUS before
entering the S-Mode kernel. Otherwise, the kernel will not boot, as 0 on
T-Head MAEE is NonCachable Memory. Once the kernel switches from bare metal
to Sv39, It will lose dirty cache line modifications that haven't been
written back to the memory.
[1] https://developer.canaan-creative.com/k230/dev/zh/00_hardware/K230_datasheet.html#chapter-1-introduction
[2] https://occ-intl-prod.oss-ap-southeast-1.aliyuncs.com/resource//1699268369347/XuanTie-C908-UserManual.pdf
[3] https://github.com/cyyself/rvb_test
[4] https://github.com/cyyself/linux/tree/k230-mainline
[5] https://github.com/cyyself/simple-sw-workbench/commit/32657d807d64217323a80cb04ce114671e51ed60
[6] https://gist.github.com/cyyself/aa98b07b8c77bb1d53b5a4c5e67a37cf
Signed-off-by: Yangyu Chen <cyy@cyyself.name>
---
arch/riscv/boot/dts/canaan/Makefile | 2 +
arch/riscv/boot/dts/canaan/k230-canmv.dts | 24 ++++
arch/riscv/boot/dts/canaan/k230-evb.dts | 24 ++++
arch/riscv/boot/dts/canaan/k230.dtsi | 142 ++++++++++++++++++++++
4 files changed, 192 insertions(+)
create mode 100644 arch/riscv/boot/dts/canaan/k230-canmv.dts
create mode 100644 arch/riscv/boot/dts/canaan/k230-evb.dts
create mode 100644 arch/riscv/boot/dts/canaan/k230.dtsi
diff --git a/arch/riscv/boot/dts/canaan/Makefile b/arch/riscv/boot/dts/canaan/Makefile
index 987d1f0c41f0..7d54ea5c6f3d 100644
--- a/arch/riscv/boot/dts/canaan/Makefile
+++ b/arch/riscv/boot/dts/canaan/Makefile
@@ -1,6 +1,8 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_CANAAN) += canaan_kd233.dtb
dtb-$(CONFIG_ARCH_CANAAN) += k210_generic.dtb
+dtb-$(CONFIG_ARCH_CANAAN) += k230-canmv.dtb
+dtb-$(CONFIG_ARCH_CANAAN) += k230-evb.dtb
dtb-$(CONFIG_ARCH_CANAAN) += sipeed_maix_bit.dtb
dtb-$(CONFIG_ARCH_CANAAN) += sipeed_maix_dock.dtb
dtb-$(CONFIG_ARCH_CANAAN) += sipeed_maix_go.dtb
diff --git a/arch/riscv/boot/dts/canaan/k230-canmv.dts b/arch/riscv/boot/dts/canaan/k230-canmv.dts
new file mode 100644
index 000000000000..9565915cead6
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/k230-canmv.dts
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
+ */
+
+#include "k230.dtsi"
+
+/ {
+ model = "Canaan CanMV-K230";
+ compatible = "canaan,canmv-k230", "canaan,kendryte-k230";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ ddr: memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x20000000>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
diff --git a/arch/riscv/boot/dts/canaan/k230-evb.dts b/arch/riscv/boot/dts/canaan/k230-evb.dts
new file mode 100644
index 000000000000..f898b8e62368
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/k230-evb.dts
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
+ */
+
+#include "k230.dtsi"
+
+/ {
+ model = "Kendryte K230 EVB";
+ compatible = "canaan,k230-usip-lp3-evb", "canaan,kendryte-k230";
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ ddr: memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x20000000>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
diff --git a/arch/riscv/boot/dts/canaan/k230.dtsi b/arch/riscv/boot/dts/canaan/k230.dtsi
new file mode 100644
index 000000000000..95c1a3d8fb11
--- /dev/null
+++ b/arch/riscv/boot/dts/canaan/k230.dtsi
@@ -0,0 +1,142 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Copyright (C) 2024 Yangyu Chen <cyy@cyyself.name>
+ */
+
+#include <dt-bindings/interrupt-controller/irq.h>
+
+/dts-v1/;
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "canaan,kendryte-k230";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ timebase-frequency = <27000000>;
+
+ cpu@0 {
+ compatible = "thead,c908", "riscv";
+ device_type = "cpu";
+ reg = <0>;
+ riscv,isa = "rv64imafdcv_zba_zbb_zbc_zbs_zicbom_zicbop_zicboz_svpbmt";
+ riscv,isa-base = "rv64i";
+ riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "v", "zba", "zbb",
+ "zbc", "zbs", "zicbom", "zicbop", "zicboz",
+ "zicntr", "zicsr", "zifencei", "zihpm", "svpbmt";
+ riscv,cbom-block-size = <64>;
+ riscv,cbop-block-size = <64>;
+ riscv,cboz-block-size = <64>;
+ d-cache-block-size = <64>;
+ d-cache-sets = <128>;
+ d-cache-size = <32768>;
+ i-cache-block-size = <64>;
+ i-cache-sets = <128>;
+ i-cache-size = <32768>;
+ next-level-cache = <&l2_cache>;
+ mmu-type = "riscv,sv39";
+
+ cpu0_intc: interrupt-controller {
+ compatible = "riscv,cpu-intc";
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+ };
+
+ l2_cache: l2-cache {
+ compatible = "cache";
+ cache-block-size = <64>;
+ cache-level = <2>;
+ cache-size = <262144>;
+ cache-sets = <256>;
+ cache-unified;
+ };
+ };
+
+ apb_clk: apb-clk-clock {
+ compatible = "fixed-clock";
+ clock-frequency = <50000000>;
+ clock-output-names = "apb_clk";
+ #clock-cells = <0>;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ interrupt-parent = <&plic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ dma-noncoherent;
+ ranges;
+
+ plic: interrupt-controller@f00000000 {
+ compatible = "canaan,k230-plic" ,"thead,c900-plic";
+ reg = <0xf 0x00000000 0x0 0x04000000>;
+ interrupts-extended = <&cpu0_intc 11>, <&cpu0_intc 9>;
+ interrupt-controller;
+ #address-cells = <0>;
+ #interrupt-cells = <2>;
+ riscv,ndev = <208>;
+ };
+
+ clint: timer@f04000000 {
+ compatible = "canaan,k230-clint", "thead,c900-clint";
+ reg = <0xf 0x04000000 0x0 0x00010000>;
+ interrupts-extended = <&cpu0_intc 3>, <&cpu0_intc 7>;
+ };
+
+ uart0: serial@91400000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0 0x91400000 0x0 0x1000>;
+ clocks = <&apb_clk>;
+ interrupts = <16 IRQ_TYPE_LEVEL_HIGH>;
+ reg-io-width = <4>;
+ reg-shift = <2>;
+ status = "disabled";
+ };
+
+ uart1: serial@91401000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0 0x91401000 0x0 0x1000>;
+ clocks = <&apb_clk>;
+ interrupts = <17 IRQ_TYPE_LEVEL_HIGH>;
+ reg-io-width = <4>;
+ reg-shift = <2>;
+ status = "disabled";
+ };
+
+ uart2: serial@91402000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0 0x91402000 0x0 0x1000>;
+ clocks = <&apb_clk>;
+ interrupts = <18 IRQ_TYPE_LEVEL_HIGH>;
+ reg-io-width = <4>;
+ reg-shift = <2>;
+ status = "disabled";
+ };
+
+ uart3: serial@91403000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0 0x91403000 0x0 0x1000>;
+ clocks = <&apb_clk>;
+ interrupts = <19 IRQ_TYPE_LEVEL_HIGH>;
+ reg-io-width = <4>;
+ reg-shift = <2>;
+ status = "disabled";
+ };
+
+ uart4: serial@91404000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x0 0x91404000 0x0 0x1000>;
+ clocks = <&apb_clk>;
+ interrupts = <20 IRQ_TYPE_LEVEL_HIGH>;
+ reg-io-width = <4>;
+ reg-shift = <2>;
+ status = "disabled";
+ };
+ };
+};
--
2.43.0
^ permalink raw reply related
* [PATCH RESEND v8 6/6] riscv: config: enable ARCH_CANAAN in defconfig
From: Yangyu Chen @ 2024-04-07 16:28 UTC (permalink / raw)
To: linux-riscv
Cc: Conor Dooley, Damien Le Moal, Rob Herring, Krzysztof Kozlowski,
Dan Carpenter, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
devicetree, linux-kernel, Yangyu Chen, Conor Dooley
In-Reply-To: <tencent_22BA0425B4DF1CA1713B62E4423C1BFBF809@qq.com>
Since K230 has been supported, allow ARCH_CANAAN to be selected to build dt
and drivers for it in defconfig.
Signed-off-by: Yangyu Chen <cyy@cyyself.name>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Guo Ren <guoren@kernel.org>
---
arch/riscv/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index fc0ec2ee13bc..27bea8296b9d 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -33,6 +33,7 @@ CONFIG_SOC_STARFIVE=y
CONFIG_ARCH_SUNXI=y
CONFIG_ARCH_THEAD=y
CONFIG_SOC_VIRT=y
+CONFIG_ARCH_CANAAN=y
CONFIG_SMP=y
CONFIG_HOTPLUG_CPU=y
CONFIG_PM=y
--
2.43.0
^ permalink raw reply related
* [PATCH RESEND v8 2/6] dt-bindings: add Canaan K230 boards compatible strings
From: Yangyu Chen @ 2024-04-07 16:28 UTC (permalink / raw)
To: linux-riscv
Cc: Conor Dooley, Damien Le Moal, Rob Herring, Krzysztof Kozlowski,
Dan Carpenter, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
devicetree, linux-kernel, Yangyu Chen, Krzysztof Kozlowski
In-Reply-To: <tencent_22BA0425B4DF1CA1713B62E4423C1BFBF809@qq.com>
Since K230 was released, K210 is no longer the only SoC in the Kendryte
series, so remove the K210 string from the description. Also, add two
boards based on k230 to compatible strings to allow them to be used in the
dt.
Signed-off-by: Yangyu Chen <cyy@cyyself.name>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
---
Documentation/devicetree/bindings/riscv/canaan.yaml | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/riscv/canaan.yaml b/Documentation/devicetree/bindings/riscv/canaan.yaml
index 41fd11f70a49..f9854ff43ac6 100644
--- a/Documentation/devicetree/bindings/riscv/canaan.yaml
+++ b/Documentation/devicetree/bindings/riscv/canaan.yaml
@@ -10,7 +10,7 @@ maintainers:
- Damien Le Moal <dlemoal@kernel.org>
description:
- Canaan Kendryte K210 SoC-based boards
+ Canaan Kendryte SoC-based boards
properties:
$nodename:
@@ -42,6 +42,12 @@ properties:
- items:
- const: canaan,kendryte-k210
+ - items:
+ - enum:
+ - canaan,canmv-k230
+ - canaan,k230-usip-lp3-evb
+ - const: canaan,kendryte-k230
+
additionalProperties: true
...
--
2.43.0
^ permalink raw reply related
* [PATCH RESEND v8 4/6] dt-bindings: interrupt-controller: Add Canaan K230 PLIC
From: Yangyu Chen @ 2024-04-07 16:28 UTC (permalink / raw)
To: linux-riscv
Cc: Conor Dooley, Damien Le Moal, Rob Herring, Krzysztof Kozlowski,
Dan Carpenter, Paul Walmsley, Palmer Dabbelt, Albert Ou, Guo Ren,
devicetree, linux-kernel, Yangyu Chen, Rob Herring
In-Reply-To: <tencent_22BA0425B4DF1CA1713B62E4423C1BFBF809@qq.com>
Add compatible string for Canaan K230 PLIC.
Signed-off-by: Yangyu Chen <cyy@cyyself.name>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Guo Ren <guoren@kernel.org>
---
.../bindings/interrupt-controller/sifive,plic-1.0.0.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
index 709b2211276b..122f9b7b3f52 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml
@@ -65,6 +65,7 @@ properties:
- items:
- enum:
- allwinner,sun20i-d1-plic
+ - canaan,k230-plic
- sophgo,cv1800b-plic
- sophgo,cv1812h-plic
- sophgo,sg2042-plic
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] dt-bindings: dma: snps,dma-spear1340: Fix data{-,_}width schema
From: Vinod Koul @ 2024-04-07 16:38 UTC (permalink / raw)
To: Viresh Kumar, Andy Shevchenko, Krzysztof Kozlowski, Conor Dooley,
Rob Herring
Cc: Viresh Kumar, Serge Semin, dmaengine, devicetree, linux-kernel
In-Reply-To: <20240401204354.1691845-1-robh@kernel.org>
On Mon, 01 Apr 2024 15:43:53 -0500, Rob Herring wrote:
> 'data-width' and 'data_width' properties are defined as arrays, but the
> schema is defined as a matrix. That works currently since everything gets
> decoded in to matrices, but that is internal to dtschema and could change.
>
>
Applied, thanks!
[1/1] dt-bindings: dma: snps,dma-spear1340: Fix data{-,_}width schema
commit: 7eccb5a5b224be42431c8087c9c9e016636ff3b5
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v4 0/5] dmaengine: fsl-sdma: Some improvement for fsl-sdma
From: Vinod Koul @ 2024-04-07 16:39 UTC (permalink / raw)
To: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joy Zou, Frank Li
Cc: dmaengine, linux-arm-kernel, linux-kernel, devicetree, imx,
Nicolin Chen, Shengjiu Wang, Daniel Baluta, Vipul Kumar,
Srikanth Krishnakar, Robin Gong, Iuliana Prodan, Clark Wang
In-Reply-To: <20240329-sdma_upstream-v4-0-daeb3067dea7@nxp.com>
On Fri, 29 Mar 2024 10:34:40 -0400, Frank Li wrote:
> To: Vinod Koul <vkoul@kernel.org>
> To: Shawn Guo <shawnguo@kernel.org>
> To: Sascha Hauer <s.hauer@pengutronix.de>
> To: Pengutronix Kernel Team <kernel@pengutronix.de>
> To: Fabio Estevam <festevam@gmail.com>
> To: NXP Linux Team <linux-imx@nxp.com>
> To: Rob Herring <robh@kernel.org>
> To: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> To: Conor Dooley <conor+dt@kernel.org>
> To: Joy Zou <joy.zou@nxp.com>
> Cc: dmaengine@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: imx@lists.linux.dev
>
> [...]
Applied, thanks!
[1/5] dmaengine: imx-sdma: Support allocate memory from internal SRAM (iram)
commit: 802ef223101fec83d92e045f89000b228904a580
[2/5] dmaengine: imx-sdma: Support 24bit/3bytes for sg mode
commit: 288109387becd8abadca5c063c70a07ae0dd7716
[3/5] dmaengine: imx-sdma: support dual fifo for DEV_TO_DEV
commit: a20f10d6accb9f5096fa7a7296e5ae34f4562440
[4/5] dt-bindings: fsl-imx-sdma: Add I2C peripheral types ID
(no commit info)
[5/5] dmaengine: imx-sdma: Add i2c dma support
(no commit info)
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 0/2] Add JH8100 support for snps,dw-axi-dmac
From: Vinod Koul @ 2024-04-07 16:39 UTC (permalink / raw)
To: Eugeniy Paltsev, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Tan Chun Hau
Cc: Ley Foon Tan, Jee Heng Sia, dmaengine, devicetree, linux-kernel
In-Reply-To: <20240327025126.229475-1-chunhau.tan@starfivetech.com>
On Tue, 26 Mar 2024 19:51:24 -0700, Tan Chun Hau wrote:
> Add StarFive JH8100 DMA support.
>
> Changes in v2:
> - Amended commit message according to feedback.
>
> Tan Chun Hau (2):
> dt-bindings: dma: snps,dw-axi-dmac: Add JH8100 support
> dmaengine: dw-axi-dmac: Add support for StarFive JH8100 DMA
>
> [...]
Applied, thanks!
[1/2] dt-bindings: dma: snps,dw-axi-dmac: Add JH8100 support
commit: 9bcf929ba1879887e0464d06cbf9b33839572af7
[2/2] dmaengine: dw-axi-dmac: Add support for StarFive JH8100 DMA
commit: 559a6690187ee0ab7875f7c560d3d19e35423fb3
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v3 0/5] dmaengine: fsl-edma: add 8ulp support
From: Vinod Koul @ 2024-04-07 16:39 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Peng Fan,
Frank Li
Cc: imx, dmaengine, linux-kernel, devicetree, Joy Zou
In-Reply-To: <20240323-8ulp_edma-v3-0-c0e981027c05@nxp.com>
On Sat, 23 Mar 2024 11:34:49 -0400, Frank Li wrote:
> Do some small clean up.
>
> 0c562876972ee dmaengine: fsl-edma: remove 'slave_id' from fsl_edma_chan
> d9b66cb5fdf62 dmaengine: fsl-edma: add safety check for 'srcid'
> aae21b7528311 dmaengine: fsl-edma: clean up chclk and FSL_EDMA_DRV_HAS_CHCLK
>
> Update binding doc.
> 23a1d1a6609fa dt-bindings: fsl-dma: fsl-edma: add fsl,imx8ulp-edma compatible string
>
> [...]
Applied, thanks!
[1/5] dmaengine: fsl-edma: remove 'slave_id' from fsl_edma_chan
commit: cee8cbfc7be8ff9f3ccf258134f9ab2c273abb75
[2/5] dmaengine: fsl-edma: add safety check for 'srcid'
commit: 6aa60f79e6794bbbc571ea4e0501b9fcc26026e2
[3/5] dmaengine: fsl-edma: clean up chclk and FSL_EDMA_DRV_HAS_CHCLK
commit: 9a5000cf70bcfcb5dd4e5b4bae0a01fb9bdf9fa1
[4/5] dt-bindings: dma: fsl-edma: add fsl,imx8ulp-edma compatible string
commit: b14f56beb289ff67fe484d720bf09092163f90c8
[5/5] dmaengine: fsl-edma: add i.MX8ULP edma support
commit: d8d4355861d874cbd1395ec0edcbe4e0f6940738
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH] dt-bindings: dma: snps,dma-spear1340: Fix data{-,_}width schema
From: Vinod Koul @ 2024-04-07 16:39 UTC (permalink / raw)
To: Viresh Kumar, Andy Shevchenko, Krzysztof Kozlowski, Conor Dooley,
Rob Herring
Cc: dmaengine, devicetree, linux-kernel
In-Reply-To: <20240311222522.1939951-1-robh@kernel.org>
On Mon, 11 Mar 2024 16:25:22 -0600, Rob Herring wrote:
> 'data-width' and 'data_width' properties are defined as arrays, but the
> schema is defined as a matrix. That works currently since everything gets
> decoded in to matrices, but that is internal to dtschema and could change.
>
>
Applied, thanks!
[1/1] dt-bindings: dma: snps,dma-spear1340: Fix data{-,_}width schema
commit: 7eccb5a5b224be42431c8087c9c9e016636ff3b5
Best regards,
--
~Vinod
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: mark system power controller and fix typo on orangepi-5-plus
From: efectn @ 2024-04-07 17:32 UTC (permalink / raw)
To: heiko, linux-rockchip
Cc: devicetree, linux-arm-kernel, linux-kernel, robh+dt,
krzysztof.kozlowski+dt, conor+dt, sebastian.reichel,
Muhammed Efe Cetin
From: Muhammed Efe Cetin <efectn@protonmail.com>
Mark the PMIC as system power controller, so the board will shut-down
properly and fix the typo on rk806_dvs1_null pins property.
Fixes: 236d225e1ee7 ("arm64: dts: rockchip: Add board device tree for rk3588-orangepi-5-plus")
Signed-off-by: Muhammed Efe Cetin <efectn@protonmail.com>
---
arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
index 1b606ea5b6cf..1a604429fb26 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
@@ -485,6 +485,7 @@ pmic@0 {
pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
<&rk806_dvs2_null>, <&rk806_dvs3_null>;
spi-max-frequency = <1000000>;
+ system-power-controller;
vcc1-supply = <&vcc5v0_sys>;
vcc2-supply = <&vcc5v0_sys>;
@@ -506,7 +507,7 @@ pmic@0 {
#gpio-cells = <2>;
rk806_dvs1_null: dvs1-null-pins {
- pins = "gpio_pwrctrl2";
+ pins = "gpio_pwrctrl1";
function = "pin_fun0";
};
--
2.44.0
^ permalink raw reply related
* Re: [PATCH] arm64: dts: rockchip: mark system power controller and fix typo on orangepi-5-plus
From: Dragan Simic @ 2024-04-07 17:46 UTC (permalink / raw)
To: efectn
Cc: heiko, linux-rockchip, devicetree, linux-arm-kernel, linux-kernel,
robh+dt, krzysztof.kozlowski+dt, conor+dt, sebastian.reichel,
Muhammed Efe Cetin
In-Reply-To: <20240407173210.372585-1-efectn@6tel.net>
On 2024-04-07 19:32, efectn@6tel.net wrote:
> From: Muhammed Efe Cetin <efectn@protonmail.com>
>
> Mark the PMIC as system power controller, so the board will shut-down
> properly and fix the typo on rk806_dvs1_null pins property.
>
> Fixes: 236d225e1ee7 ("arm64: dts: rockchip: Add board device tree for
> rk3588-orangepi-5-plus")
> Signed-off-by: Muhammed Efe Cetin <efectn@protonmail.com>
Looking good to me.
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
> ---
> arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
> b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
> index 1b606ea5b6cf..1a604429fb26 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
> @@ -485,6 +485,7 @@ pmic@0 {
> pinctrl-0 = <&pmic_pins>, <&rk806_dvs1_null>,
> <&rk806_dvs2_null>, <&rk806_dvs3_null>;
> spi-max-frequency = <1000000>;
> + system-power-controller;
>
> vcc1-supply = <&vcc5v0_sys>;
> vcc2-supply = <&vcc5v0_sys>;
> @@ -506,7 +507,7 @@ pmic@0 {
> #gpio-cells = <2>;
>
> rk806_dvs1_null: dvs1-null-pins {
> - pins = "gpio_pwrctrl2";
> + pins = "gpio_pwrctrl1";
> function = "pin_fun0";
> };
^ permalink raw reply
* Re: [PATCH v4 3/5] spi: spi-qpic: Add qpic spi nand driver support
From: Alex G. @ 2024-04-07 17:48 UTC (permalink / raw)
To: Md Sadre Alam, andersson, konrad.dybcio, broonie, robh,
krzysztof.kozlowski+dt, conor+dt, miquel.raynal, richard,
vigneshr, manivannan.sadhasivam, neil.armstrong, daniel, arnd,
chris.packham, christophe.kerello, linux-arm-msm, linux-spi,
devicetree, linux-kernel, linux-mtd
Cc: quic_srichara, quic_varada
In-Reply-To: <20240308091752.16136-4-quic_mdalam@quicinc.com>
On 3/8/24 03:17, Md Sadre Alam wrote:
> Add qpic spi nand driver support. The spi nand
> driver currently supported the below commands.
>
> -- RESET
> -- READ ID
> -- SET FEATURE
> -- GET FEATURE
> -- READ PAGE
> -- WRITE PAGE
> -- ERASE PAGE
>
> Co-developed-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
> Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
> Co-developed-by: Varadarajan Narayanan <quic_varada@quicinc.com>
> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
> Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com>
> ---
For the entire series:
Tested-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index bc7021da2fe9..63764e943d82 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -882,6 +882,14 @@ config SPI_QCOM_QSPI
> help
> QSPI(Quad SPI) driver for Qualcomm QSPI controller.
>
> +config SPI_QPIC_SNAND
> + tristate "QPIC SNAND controller"
> + depends on ARCH_QCOM || COMPILE_TEST
Here, it needs to 'select QPIC_COMMON`. Otherwise it can run into
unresolved symbols:
: drivers/spi/spi-qpic-snand.o: in function `snandc_set_reg':
drivers/spi/spi-qpic-snand.c:56:(.text+0x484): undefined reference to
`qcom_offset_to_nandc_reg'
...
> + help
> + QPIC_SNAND (QPIC SPI NAND) driver for Qualcomm QPIC controller.
> + QPIC controller supports both parallel nand and serial nand.
> + This config will enable serial nand driver for QPIC controller.
> +
> config SPI_QUP
> tristate "Qualcomm SPI controller with QUP interface"
> depends on ARCH_QCOM || COMPILE_TEST
Alex
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: Designate the system power controller on QuartzPro64
From: Dragan Simic @ 2024-04-07 17:56 UTC (permalink / raw)
To: linux-rockchip
Cc: heiko, linux-arm-kernel, devicetree, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Designate the primary RK806 PMIC on the Pine64 QuartzPro64 as the system
power controller, so the board shuts down properly on poweroff(8).
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
---
arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts b/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
index 67414d72e2b6..22bbfbe729c1 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts
@@ -456,6 +456,7 @@ pmic@0 {
<&rk806_dvs2_null>, <&rk806_dvs3_null>;
pinctrl-names = "default";
spi-max-frequency = <1000000>;
+ system-power-controller;
vcc1-supply = <&vcc4v0_sys>;
vcc2-supply = <&vcc4v0_sys>;
^ permalink raw reply related
* Re: [PATCH v4 3/5] spi: spi-qpic: Add qpic spi nand driver support
From: Alex G. @ 2024-04-07 18:40 UTC (permalink / raw)
To: Md Sadre Alam, andersson, konrad.dybcio, broonie, robh,
krzysztof.kozlowski+dt, conor+dt, miquel.raynal, richard,
vigneshr, manivannan.sadhasivam, neil.armstrong, daniel, arnd,
chris.packham, christophe.kerello, linux-arm-msm, linux-spi,
devicetree, linux-kernel, linux-mtd
Cc: quic_srichara, quic_varada
In-Reply-To: <1c803d8c-80b2-47a9-bc8c-8b13cbfc6841@gmail.com>
On 4/7/24 12:48, Alex G. wrote:
> On 3/8/24 03:17, Md Sadre Alam wrote:
>> Add qpic spi nand driver support. The spi nand
>> driver currently supported the below commands.
>>
>> -- RESET
>> -- READ ID
>> -- SET FEATURE
>> -- GET FEATURE
>> -- READ PAGE
>> -- WRITE PAGE
>> -- ERASE PAGE
>>
>> Co-developed-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
>> Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
>> Co-developed-by: Varadarajan Narayanan <quic_varada@quicinc.com>
>> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
>> Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com>
>> ---
>
> For the entire series:
>
> Tested-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
>
>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>> index bc7021da2fe9..63764e943d82 100644
>> --- a/drivers/spi/Kconfig
>> +++ b/drivers/spi/Kconfig
>> @@ -882,6 +882,14 @@ config SPI_QCOM_QSPI
>> help
>> QSPI(Quad SPI) driver for Qualcomm QSPI controller.
>> +config SPI_QPIC_SNAND
>> + tristate "QPIC SNAND controller"
Also, don't tristate this. It can be set as CONFIG_QPIC_COMMON=m, which
will cause the build to fail because you don't have a MODULE_LICENSE().
>> + depends on ARCH_QCOM || COMPILE_TEST
>
> Here, it needs to 'select QPIC_COMMON`. Otherwise it can run into
> unresolved symbols:
>
> : drivers/spi/spi-qpic-snand.o: in function `snandc_set_reg':
> drivers/spi/spi-qpic-snand.c:56:(.text+0x484): undefined reference to
> `qcom_offset_to_nandc_reg'
> ...
>
>> + help
>> + QPIC_SNAND (QPIC SPI NAND) driver for Qualcomm QPIC controller.
>> + QPIC controller supports both parallel nand and serial nand.
>> + This config will enable serial nand driver for QPIC controller.
>> +
>> config SPI_QUP
>> tristate "Qualcomm SPI controller with QUP interface"
>> depends on ARCH_QCOM || COMPILE_TEST
>
> Alex
Alex
^ permalink raw reply
* Re: [PATCH v4 3/5] spi: spi-qpic: Add qpic spi nand driver support
From: Alex G. @ 2024-04-07 18:45 UTC (permalink / raw)
To: Md Sadre Alam, andersson, konrad.dybcio, broonie, robh,
krzysztof.kozlowski+dt, conor+dt, miquel.raynal, richard,
vigneshr, manivannan.sadhasivam, neil.armstrong, daniel, arnd,
chris.packham, christophe.kerello, linux-arm-msm, linux-spi,
devicetree, linux-kernel, linux-mtd
Cc: quic_srichara, quic_varada
In-Reply-To: <4f72048a-a764-43de-846c-3b4edc1232e3@gmail.com>
On 4/7/24 13:40, Alex G. wrote:
>
>
> On 4/7/24 12:48, Alex G. wrote:
>> On 3/8/24 03:17, Md Sadre Alam wrote:
>>> Add qpic spi nand driver support. The spi nand
>>> driver currently supported the below commands.
>>>
>>> -- RESET
>>> -- READ ID
>>> -- SET FEATURE
>>> -- GET FEATURE
>>> -- READ PAGE
>>> -- WRITE PAGE
>>> -- ERASE PAGE
>>>
>>> Co-developed-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
>>> Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
>>> Co-developed-by: Varadarajan Narayanan <quic_varada@quicinc.com>
>>> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
>>> Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com>
>>> ---
>>
>> For the entire series:
>>
>> Tested-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
>>
>>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>>> index bc7021da2fe9..63764e943d82 100644
>>> --- a/drivers/spi/Kconfig
>>> +++ b/drivers/spi/Kconfig
>>> @@ -882,6 +882,14 @@ config SPI_QCOM_QSPI
>>> help
>>> QSPI(Quad SPI) driver for Qualcomm QSPI controller.
>>> +config SPI_QPIC_SNAND
>>> + tristate "QPIC SNAND controller"
>
> Also, don't tristate this. It can be set as CONFIG_QPIC_COMMON=m, which
> will cause the build to fail because you don't have a MODULE_LICENSE().
Please disregard my idiotic suggestion here. I meant to make this
comment on the previous patch.
>>> + depends on ARCH_QCOM || COMPILE_TEST
>>
>> Here, it needs to 'select QPIC_COMMON`. Otherwise it can run into
>> unresolved symbols:
>>
>> : drivers/spi/spi-qpic-snand.o: in function `snandc_set_reg':
>> drivers/spi/spi-qpic-snand.c:56:(.text+0x484): undefined reference
>> to `qcom_offset_to_nandc_reg'
>> ...
>>
>>> + help
>>> + QPIC_SNAND (QPIC SPI NAND) driver for Qualcomm QPIC controller.
>>> + QPIC controller supports both parallel nand and serial nand.
>>> + This config will enable serial nand driver for QPIC controller.
>>> +
>>> config SPI_QUP
>>> tristate "Qualcomm SPI controller with QUP interface"
>>> depends on ARCH_QCOM || COMPILE_TEST
>>
>> Alex
> Alex
^ permalink raw reply
* Re: [PATCH v4 3/5] spi: spi-qpic: Add qpic spi nand driver support
From: Krzysztof Kozlowski @ 2024-04-07 18:54 UTC (permalink / raw)
To: Alex G., Md Sadre Alam, andersson, konrad.dybcio, broonie, robh,
krzysztof.kozlowski+dt, conor+dt, miquel.raynal, richard,
vigneshr, manivannan.sadhasivam, neil.armstrong, daniel, arnd,
chris.packham, christophe.kerello, linux-arm-msm, linux-spi,
devicetree, linux-kernel, linux-mtd
Cc: quic_srichara, quic_varada
In-Reply-To: <1c803d8c-80b2-47a9-bc8c-8b13cbfc6841@gmail.com>
On 07/04/2024 19:48, Alex G. wrote:
> On 3/8/24 03:17, Md Sadre Alam wrote:
>> Add qpic spi nand driver support. The spi nand
>> driver currently supported the below commands.
>>
>> -- RESET
>> -- READ ID
>> -- SET FEATURE
>> -- GET FEATURE
>> -- READ PAGE
>> -- WRITE PAGE
>> -- ERASE PAGE
>>
>> Co-developed-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
>> Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
>> Co-developed-by: Varadarajan Narayanan <quic_varada@quicinc.com>
>> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
>> Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com>
>> ---
>
> For the entire series:
>
> Tested-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
>
>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>> index bc7021da2fe9..63764e943d82 100644
>> --- a/drivers/spi/Kconfig
>> +++ b/drivers/spi/Kconfig
>> @@ -882,6 +882,14 @@ config SPI_QCOM_QSPI
>> help
>> QSPI(Quad SPI) driver for Qualcomm QSPI controller.
>>
>> +config SPI_QPIC_SNAND
>> + tristate "QPIC SNAND controller"
>> + depends on ARCH_QCOM || COMPILE_TEST
>
> Here, it needs to 'select QPIC_COMMON`. Otherwise it can run into
> unresolved symbols:
>
> : drivers/spi/spi-qpic-snand.o: in function `snandc_set_reg':
> drivers/spi/spi-qpic-snand.c:56:(.text+0x484): undefined reference to
> `qcom_offset_to_nandc_reg'
No, do not select user-visible symbols. If you observe such issues then
either stubs are missing or depends on.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 3/5] spi: spi-qpic: Add qpic spi nand driver support
From: Krzysztof Kozlowski @ 2024-04-07 18:55 UTC (permalink / raw)
To: Alex G., Md Sadre Alam, andersson, konrad.dybcio, broonie, robh,
krzysztof.kozlowski+dt, conor+dt, miquel.raynal, richard,
vigneshr, manivannan.sadhasivam, neil.armstrong, daniel, arnd,
chris.packham, christophe.kerello, linux-arm-msm, linux-spi,
devicetree, linux-kernel, linux-mtd
Cc: quic_srichara, quic_varada
In-Reply-To: <0c0487cb-c73d-42dd-94f8-499c29009730@gmail.com>
On 07/04/2024 20:45, Alex G. wrote:
>
>
> On 4/7/24 13:40, Alex G. wrote:
>>
>>
>> On 4/7/24 12:48, Alex G. wrote:
>>> On 3/8/24 03:17, Md Sadre Alam wrote:
>>>> Add qpic spi nand driver support. The spi nand
>>>> driver currently supported the below commands.
>>>>
>>>> -- RESET
>>>> -- READ ID
>>>> -- SET FEATURE
>>>> -- GET FEATURE
>>>> -- READ PAGE
>>>> -- WRITE PAGE
>>>> -- ERASE PAGE
>>>>
>>>> Co-developed-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
>>>> Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
>>>> Co-developed-by: Varadarajan Narayanan <quic_varada@quicinc.com>
>>>> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
>>>> Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com>
>>>> ---
>>>
>>> For the entire series:
>>>
>>> Tested-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
>>>
>>>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>>>> index bc7021da2fe9..63764e943d82 100644
>>>> --- a/drivers/spi/Kconfig
>>>> +++ b/drivers/spi/Kconfig
>>>> @@ -882,6 +882,14 @@ config SPI_QCOM_QSPI
>>>> help
>>>> QSPI(Quad SPI) driver for Qualcomm QSPI controller.
>>>> +config SPI_QPIC_SNAND
>>>> + tristate "QPIC SNAND controller"
>>
>> Also, don't tristate this. It can be set as CONFIG_QPIC_COMMON=m, which
>> will cause the build to fail because you don't have a MODULE_LICENSE().
>
> Please disregard my idiotic suggestion here. I meant to make this
> comment on the previous patch.
>
Also not. All of these must be allowed to be a module. If you need
dependency between modules, then use documented syntax in the kernel
(foo || !foo).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 3/5] spi: spi-qpic: Add qpic spi nand driver support
From: Alex G. @ 2024-04-07 18:58 UTC (permalink / raw)
To: Krzysztof Kozlowski, Md Sadre Alam, andersson, konrad.dybcio,
broonie, robh, krzysztof.kozlowski+dt, conor+dt, miquel.raynal,
richard, vigneshr, manivannan.sadhasivam, neil.armstrong, daniel,
arnd, chris.packham, christophe.kerello, linux-arm-msm, linux-spi,
devicetree, linux-kernel, linux-mtd
Cc: quic_srichara, quic_varada
In-Reply-To: <5fe5396e-c628-49e1-bec3-770847f061e5@linaro.org>
On 4/7/24 13:54, Krzysztof Kozlowski wrote:
> On 07/04/2024 19:48, Alex G. wrote:
>> On 3/8/24 03:17, Md Sadre Alam wrote:
>>> Add qpic spi nand driver support. The spi nand
>>> driver currently supported the below commands.
>>>
>>> -- RESET
>>> -- READ ID
>>> -- SET FEATURE
>>> -- GET FEATURE
>>> -- READ PAGE
>>> -- WRITE PAGE
>>> -- ERASE PAGE
>>>
>>> Co-developed-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
>>> Signed-off-by: Sricharan Ramabadhran <quic_srichara@quicinc.com>
>>> Co-developed-by: Varadarajan Narayanan <quic_varada@quicinc.com>
>>> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com>
>>> Signed-off-by: Md Sadre Alam <quic_mdalam@quicinc.com>
>>> ---
>>
>> For the entire series:
>>
>> Tested-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
>>
>>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>>> index bc7021da2fe9..63764e943d82 100644
>>> --- a/drivers/spi/Kconfig
>>> +++ b/drivers/spi/Kconfig
>>> @@ -882,6 +882,14 @@ config SPI_QCOM_QSPI
>>> help
>>> QSPI(Quad SPI) driver for Qualcomm QSPI controller.
>>>
>>> +config SPI_QPIC_SNAND
>>> + tristate "QPIC SNAND controller"
>>> + depends on ARCH_QCOM || COMPILE_TEST
>>
>> Here, it needs to 'select QPIC_COMMON`. Otherwise it can run into
>> unresolved symbols:
>>
>> : drivers/spi/spi-qpic-snand.o: in function `snandc_set_reg':
>> drivers/spi/spi-qpic-snand.c:56:(.text+0x484): undefined reference to
>> `qcom_offset_to_nandc_reg'
>
> No, do not select user-visible symbols. If you observe such issues then
> either stubs are missing or depends on.
I apologize for making a bad suggestion. Thank you for pointing it out.
Alex
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: display: bridge: lt8912b: document 'lontium, pn-swap' property
From: Dmitry Baryshkov @ 2024-04-07 20:31 UTC (permalink / raw)
To: Alexandru Ardelean
Cc: linux-kernel, dri-devel, devicetree, adrien.grassein,
andrzej.hajda, neil.armstrong, rfoss, Laurent.pinchart, jonas,
jernej.skrabec, airlied, daniel, maarten.lankhorst, mripard,
tzimmermann, robh, krzysztof.kozlowski+dt, conor+dt,
stefan.eichenberger, francesco.dolcini, marius.muresan,
irina.muresan
In-Reply-To: <20240402105925.905144-2-alex@shruggie.ro>
On Tue, Apr 02, 2024 at 01:59:25PM +0300, Alexandru Ardelean wrote:
> On some HW designs, it's easier for the layout if the P/N pins are swapped.
> The driver currently has a DT property to do that.
>
> This change documents the 'lontium,pn-swap' property.
>
> Signed-off-by: Alexandru Ardelean <alex@shruggie.ro>
> ---
> .../devicetree/bindings/display/bridge/lontium,lt8912b.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
> index 2cef252157985..3a804926b288a 100644
> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
> @@ -24,6 +24,12 @@ properties:
> maxItems: 1
> description: GPIO connected to active high RESET pin.
>
> + lontium,pn-swap:
> + description: Swap the polarities of the P/N pins in software.
> + On some HW designs, the layout is simplified if the P/N pins
> + are inverted.
> + type: boolean
> +
I'd like to point out the standard `lane-polarities` property defined at
Documentation/devicetree/bindings/media/video-interfaces.yaml. You can
define and use it for the corresponding endpoint in the lt8912b schema.
> ports:
> $ref: /schemas/graph.yaml#/properties/ports
>
> --
> 2.44.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: mailbox: arm,mhuv3: Add bindings
From: Jassi Brar @ 2024-04-07 23:38 UTC (permalink / raw)
To: Cristian Marussi
Cc: linux-kernel, linux-arm-kernel, devicetree, sudeep.holla, robh+dt,
krzysztof.kozlowski+dt, conor+dt
In-Reply-To: <20240404062347.3219795-2-cristian.marussi@arm.com>
On Thu, Apr 4, 2024 at 1:25 AM Cristian Marussi
<cristian.marussi@arm.com> wrote:
>
> Add bindings for the ARM MHUv3 Mailbox controller.
>
> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
> ---
> v2 -> v3
> - fixed spurious tabs in dt_binding_check
> v1 -> v2
> - clarified extension descriptions around configurability and discoverability
> - removed unused labels from the example
> - using pattern properties to define interrupt-names
> - bumped interrupt maxItems to 74 (allowing uo to 8 channels per extension)
> ---
> .../bindings/mailbox/arm,mhuv3.yaml | 217 ++++++++++++++++++
> 1 file changed, 217 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml
>
> diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml
> new file mode 100644
> index 000000000000..32a8bb711464
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv3.yaml
> @@ -0,0 +1,217 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mailbox/arm,mhuv3.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ARM MHUv3 Mailbox Controller
> +
> +maintainers:
> + - Sudeep Holla <sudeep.holla@arm.com>
> + - Cristian Marussi <cristian.marussi@arm.com>
> +
> +description: |
> + The Arm Message Handling Unit (MHU) Version 3 is a mailbox controller that
> + enables unidirectional communications with remote processors through various
> + possible transport protocols.
> + The controller can optionally support a varying number of extensions that, in
> + turn, enable different kinds of transport to be used for communication.
> + Number, type and characteristics of each supported extension can be discovered
> + dynamically at runtime.
> +
> + Given the unidirectional nature of the controller, an MHUv3 mailbox controller
> + is composed of a MHU Sender (MHUS) containing a PostBox (PBX) block and a MHU
> + Receiver (MHUR) containing a MailBox (MBX) block, where
> +
> + PBX is used to
> + - Configure the MHU
> + - Send Transfers to the Receiver
> + - Optionally receive acknowledgment of a Transfer from the Receiver
> +
> + MBX is used to
> + - Configure the MHU
> + - Receive Transfers from the Sender
> + - Optionally acknowledge Transfers sent by the Sender
> +
> + Both PBX and MBX need to be present and defined in the DT description if you
> + need to establish a bidirectional communication, since you will have to
> + acquire two distinct unidirectional channels, one for each block.
> +
> + As a consequence both blocks needs to be represented separately and specified
> + as distinct DT nodes in order to properly describe their resources.
> +
> + Note that, though, thanks to the runtime discoverability, there is no need to
> + identify the type of blocks with distinct compatibles.
> +
> + Following are the MHUv3 possible extensions.
> +
> + - Doorbell Extension (DBE): DBE defines a type of channel called a Doorbell
> + Channel (DBCH). DBCH enables a single bit Transfer to be sent from the
> + Sender to Receiver. The Transfer indicates that an event has occurred.
> + When DBE is implemented, the number of DBCHs that an implementation of the
> + MHU can support is between 1 and 128, numbered starting from 0 in ascending
> + order and discoverable at run-time.
> + Each DBCH contains 32 individual fields, referred to as flags, each of which
> + can be used independently. It is possible for the Sender to send multiple
> + Transfers at once using a single DBCH, so long as each Transfer uses
> + a different flag in the DBCH.
> + Optionally, data may be transmitted through an out-of-band shared memory
> + region, wherein the MHU Doorbell is used strictly as an interrupt generation
> + mechanism, but this is out of the scope of these bindings.
> +
> + - FastChannel Extension (FCE): FCE defines a type of channel called a Fast
> + Channel (FCH). FCH is intended for lower overhead communication between
> + Sender and Receiver at the expense of determinism. An FCH allows the Sender
> + to update the channel value at any time, regardless of whether the previous
> + value has been seen by the Receiver. When the Receiver reads the channel's
> + content it gets the last value written to the channel.
> + FCH is considered lossy in nature, and means that the Sender has no way of
> + knowing if, or when, the Receiver will act on the Transfer.
> + FCHs are expected to behave as RAM which generates interrupts when writes
> + occur to the locations within the RAM.
> + When FCE is implemented, the number of FCHs that an implementation of the
> + MHU can support is between 1-1024, if the FastChannel word-size is 32-bits,
> + or between 1-512, when the FastChannel word-size is 64-bits.
> + FCHs are numbered from 0 in ascending order.
> + Note that the number of FCHs and the word-size are implementation defined,
> + not configurable but discoverable at run-time.
> + Optionally, data may be transmitted through an out-of-band shared memory
> + region, wherein the MHU FastChannel is used as an interrupt generation
> + mechanism which carries also a pointer to such out-of-band data, but this
> + is out of the scope of these bindings.
> +
> + - FIFO Extension (FE): FE defines a Channel type called a FIFO Channel (FFCH).
> + FFCH allows a Sender to send
> + - Multiple Transfers to the Receiver without having to wait for the
> + previous Transfer to be acknowledged by the Receiver, as long as the
> + FIFO has room for the Transfer.
> + - Transfers which require the Receiver to provide acknowledgment.
> + - Transfers which have in-band payload.
> + In all cases, the data is guaranteed to be observed by the Receiver in the
> + same order which the Sender sent it.
> + When FE is implemented, the number of FFCHs that an implementation of the
> + MHU can support is between 1 and 64, numbered starting from 0 in ascending
> + order. The number of FFCHs, their depth (same for all implemented FFCHs) and
> + the access-granularity are implementation defined, not configurable but
> + discoverable at run-time.
> + Optionally, additional data may be transmitted through an out-of-band shared
> + memory region, wherein the MHU FIFO is used to transmit, in order, a small
> + part of the payload (like a header) and a reference to the shared memory
> + area holding the remaining, bigger, chunk of the payload, but this is out of
> + the scope of these bindings.
> +
> +properties:
> + compatible:
> + const: arm,mhuv3
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + minItems: 1
> + maxItems: 74
> +
> + interrupt-names:
> + description: |
> + The MHUv3 controller generates a number of events some of which are used
> + to generate interrupts; as a consequence it can expose a varying number of
> + optional PBX/MBX interrupts, representing the events generated during the
> + operation of the various transport protocols associated with different
> + extensions. All interrupts of the MHU are level-sensitive.
> + Some of these optional interrupts are defined per-channel, where the
> + number of channels effectively available is implementation defined and
> + run-time discoverable.
> + In the following names are enumerated using patterns, with per-channel
> + interrupts implicitly capped at the maximum channels allowed by the
> + specification for each extension type.
> + For the sake of simplicity maxItems is anyway capped to a most plausible
> + number, assuming way less channels would be implemented than actually
> + possible.
> +
> + The only mandatory interrupts on the MHU are:
> + - combined
> + - mbx-fch-xfer-<N> but only if mbx-fcgrp-xfer-<N> is not implemented.
> +
> + minItems: 1
> + maxItems: 74
> + items:
> + oneOf:
> + - const: combined
> + description: PBX/MBX Combined interrupt
> + - const: combined-ffch
> + description: PBX/MBX FIFO Combined interrupt
> + - pattern: '^ffch-low-tide-[0-9]+$'
> + description: PBX/MBX FIFO Channel <N> Low Tide interrupt
> + - pattern: '^ffch-high-tide-[0-9]+$'
> + description: PBX/MBX FIFO Channel <N> High Tide interrupt
> + - pattern: '^ffch-flush-[0-9]+$'
> + description: PBX/MBX FIFO Channel <N> Flush interrupt
> + - pattern: '^mbx-dbch-xfer-[0-9]+$'
> + description: MBX Doorbell Channel <N> Transfer interrupt
> + - pattern: '^mbx-fch-xfer-[0-9]+$'
> + description: MBX FastChannel <N> Transfer interrupt
> + - pattern: '^mbx-fchgrp-xfer-[0-9]+$'
> + description: MBX FastChannel <N> Group Transfer interrupt
> + - pattern: '^mbx-ffch-xfer-[0-9]+$'
> + description: MBX FIFO Channel <N> Transfer interrupt
> + - pattern: '^pbx-dbch-xfer-ack-[0-9]+$'
> + description: PBX Doorbell Channel <N> Transfer Ack interrupt
> + - pattern: '^pbx-ffch-xfer-ack-[0-9]+$'
> + description: PBX FIFO Channel <N> Transfer Ack interrupt
> +
Can we have optional subnodes (with different properties as required)
for each extension type ?
> + '#mbox-cells':
> + description: |
> + The first argument in the consumers 'mboxes' property represents the
> + extension type, the second is for the channel number while the third
> + depends on extension type.
> +
> + Extension type for DBE is 0 and the third parameter represents the
> + doorbell flag number to use.
> + Extension type for FCE is 1, third parameter unused.
> + Extension type for FE is 2, third parameter unused.
> +
> + mboxes = <&mhu 0 0 5>; // DBE, Doorbell Channel Window 0, doorbell flag 5.
> + mboxes = <&mhu 0 1 7>; // DBE, Doorbell Channel Window 1, doorbell flag 7.
> + mboxes = <&mhu 1 0 0>; // FCE, FastChannel Window 0.
> + mboxes = <&mhu 1 3 0>; // FCE, FastChannel Window 3.
> + mboxes = <&mhu 2 1 0>; // FE, FIFO Channel Window 1.
> + mboxes = <&mhu 2 7 0>; // FE, FIFO Channel Window 7.
>
Please define the extension types, instead of 0, 1 and 2.
Cheers!
Jassi
^ permalink raw reply
* Re: [PATCH AUTOSEL 6.8 36/98] arm64: dts: sc8280xp: correct DMIC2 and DMIC3 pin config node names
From: Sasha Levin @ 2024-04-07 23:46 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Johan Hovold, linux-kernel, stable, Bjorn Andersson,
konrad.dybcio, robh, krzysztof.kozlowski+dt, conor+dt,
linux-arm-msm, devicetree
In-Reply-To: <730ac728-a333-46cc-aa0c-5e922b3c871e@linaro.org>
On Tue, Apr 02, 2024 at 12:17:08PM +0200, Krzysztof Kozlowski wrote:
>On 02/04/2024 09:23, Johan Hovold wrote:
>> On Fri, Mar 29, 2024 at 08:37:07AM -0400, Sasha Levin wrote:
>>> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>
>>> [ Upstream commit 61474b18e762671a69b2df9665f3cec5c87a38af ]
>>>
>>> Correct the TLMM pin configuration and muxing node names used for DMIC2
>>> and DMIC3 (dmic01 -> dmic23). This has no functional impact, but
>>> improves code readability and avoids any confusion when reading the DTS.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>> Link: https://lore.kernel.org/r/20240212172335.124845-1-krzysztof.kozlowski@linaro.org
>>> Signed-off-by: Bjorn Andersson <andersson@kernel.org>
>>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>>
>> This is not a bug fix. Please drop from all stable queues (e.g. 6.8 and
>> 6.6).
>
>I should just avoid names "fix" and "correct" :)
I'll drop it, thanks!
--
Thanks,
Sasha
^ permalink raw reply
* RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set additionalProperties to true
From: Peng Fan @ 2024-04-07 23:50 UTC (permalink / raw)
To: Krzysztof Kozlowski, Peng Fan (OSS), Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Sudeep Holla,
Cristian Marussi
Cc: devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <5b9e0e44-0b9c-44fc-9d18-21c47b46dc63@kernel.org>
> 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.
I use a separate binding here is to avoid add more vendor stuff
in arm,scmi.yaml. Otherwise we will have to add a list as:
if nxp
xxx
else if qcom
xxx
else if xx
yyy.
I could add back i.mx extension to arm,scmi.yaml if people
agree.
Thanks
Peng.
>
> Maybe your binding is correct, feel free to convince me (and read first writing
> bindings).
>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH v5 0/4] drm/panel: add support for LG SW43408 panel
From: Dmitry Baryshkov @ 2024-04-07 23:53 UTC (permalink / raw)
To: Sumit Semwal, Caleb Connolly, Neil Armstrong, Jessica Zhang,
Sam Ravnborg, David Airlie, Daniel Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: dri-devel, devicetree, linux-kernel, linux-arm-msm, Vinod Koul,
Caleb Connolly, Krzysztof Kozlowski, Marijn Suijten
The LG SW43408 panel is used on Google Pixel3 devices. For a long time
we could not submit the driver, as the panel was not coming up from the
reset. The panel seems to be picky about some of the delays during init
and it also uses non-standard payload for MIPI_DSI_COMPRESSION_MODE.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
Changes in v5:
- Mention 60 Hz in the commit message (Marijn)
- Fix the comment regarding the panel being DSC-only (Marijn)
- Link to v4: https://lore.kernel.org/r/20240403-lg-sw43408-panel-v4-0-a386d5d3b0c6@linaro.org
Changes in v4:
- Fix order of mipi_dsi_compression_mode_ext() args (Marijn)
- Expanded kerneldoc coments for this function (Marijn)
- And added arguments validation (Marijn)
- In the panel driver send the COMPRESSION_MODE in LPM mode like it was
done originally
- Expanded the .clock maths to show the reason behind the value (Marijn)
- Moved the mode out of the match data (Marijn)
- Link to v3: https://lore.kernel.org/r/20240402-lg-sw43408-panel-v3-0-144f17a11a56@linaro.org
Changes in v3:
- Fixed return type of MIPI DSC functions
- Replaced mipi_dsi_compression_mode_raw() with
mipi_dsi_compression_mode_ext() (Marijn)
- Link to v2: https://lore.kernel.org/r/20240330-lg-sw43408-panel-v2-0-293a58717b38@linaro.org
Changes in v2:
- Removed formatting char from schema (Krzysztof)
- Moved additionalProperties after required (Krzysztof)
- Added example to the schema (Krzysztof)
- Removed obsolete comment in the commit message (Marijn)
- Moved DSC params to the panel struct (Marijn)
- Changed dsc_en to be an array (Marijn)
- Added comment regiarding slice_width and slice_count (Marijn)
- Link to v1: https://lore.kernel.org/r/20240330-lg-sw43408-panel-v1-0-f5580fc9f2da@linaro.org
---
Dmitry Baryshkov (2):
drm/mipi-dsi: use correct return type for the DSC functions
drm/mipi-dsi: add mipi_dsi_compression_mode_ext()
Sumit Semwal (2):
dt-bindings: panel: Add LG SW43408 MIPI-DSI panel
drm: panel: Add LG sw43408 panel driver
.../bindings/display/panel/lg,sw43408.yaml | 62 ++++
MAINTAINERS | 8 +
drivers/gpu/drm/drm_mipi_dsi.c | 45 ++-
drivers/gpu/drm/panel/Kconfig | 11 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-lg-sw43408.c | 323 +++++++++++++++++++++
include/drm/drm_mipi_dsi.h | 15 +-
7 files changed, 453 insertions(+), 12 deletions(-)
---
base-commit: a6bd6c9333397f5a0e2667d4d82fef8c970108f2
change-id: 20240330-lg-sw43408-panel-b552f411c53e
Best regards,
--
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
^ 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