* Re: [PATCH v2 0/2] Add DeepComputing FML13V05 board dts
From: Troy Mitchell @ 2026-03-31 7:15 UTC (permalink / raw)
To: Sandie Cao, Conor Dooley
Cc: Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski, Yixun Lan,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Heinrich Schuchardt,
Troy Mitchell, Michael Opdenacker, Guodong Xu, Hendrik Hamerlinck,
Yangyu Chen, spacemit, linux-riscv, devicetree, linux-kernel
In-Reply-To: <20260331071110.68321-1-sandie.cao@deepcomputing.io>
Hi Sandie,
On Tue Mar 31, 2026 at 3:11 PM CST, Sandie Cao wrote:
> This series updates Device Tree related files to introduce the
> FML13V05 board from DeepComputing, which incorporates a Spacemit
> K3 SoC. This board is designed for use on the Framework Laptop 13
> Chassis, which has (Framework) SKU FRANHQ0001.
>
> The series is based on riscv-dt-for-next.
>
> v2:
> - Patch 1:
> Use formal format user name.
> - Patch 2:
> Use formal format user name.
> Add Reviewed-by from Troy Mitchell.
>
> Link to v1: https://lore.kernel.org/all/20260331034423.67142-1-sandie.cao@deepcomputing.io/
Please slow down a bit. Sending a v2 immediately after a single review doesn't
give others (especially those in different time zones) a chance to look at v1.
It's better to wait a day or two to collect more feedback before sending a new iteration
- Troy
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: soc: renesas: Document MFIS IP core
From: Krzysztof Kozlowski @ 2026-03-31 7:15 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-renesas-soc, Marek Vasut, devicetree, Geert Uytterhoeven,
Magnus Damm, Rob Herring, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <acZtECu-1kuIuNrx@shikoro>
On 27/03/2026 12:42, Wolfram Sang wrote:
>>> +#define MFIS_CHANNEL_TX (0 << 0)
>>> +#define MFIS_CHANNEL_RX (1 << 0)
>>
>> No improvements and no answers to comments. Same review, drop, not a
>> binding. If disagree, respond to v1 comments.
>
> I think I did. I explained above in "changes since v1" that I decided to
> keep it because of the existing users in upstream that Geert mentioned.
Same review as in v1. Not a binding. I asked what Linux ABI are you here
binding. Point me to Linux code using these. This is the ABI.
You replied something about device, so how does it matter? It is not the
answer to the question.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: soc: renesas: add MFIS binding documentation
From: Krzysztof Kozlowski @ 2026-03-31 7:14 UTC (permalink / raw)
To: Wolfram Sang
Cc: Geert Uytterhoeven, linux-renesas-soc, linux-kernel, Jassi Brar,
Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, devicetree
In-Reply-To: <actzUSIKKzcDmBCT@shikoro>
On 31/03/2026 09:10, Wolfram Sang wrote:
>
>> I did not get the driver so I cannot verify that. What sort of Linux ABI
>> does this bind?
>
> In case you mean this as unanswered questions to v1: This describes the
> device specific second mbox cell. Like Tegra does it here (even with
I asked Linux ABI. Device specific numbers is not Linux ABI, because
Linux is not device.
> shifts instead of plain numbers):
>
> include/dt-bindings/mailbox/tegra186-hsp.h
>
> But all this has been said before and you got the driver as well in v2.
What do you mean by v2? This is v1, there cannot have been a v2. No
changelog in cover letter, no references.
> I really have no idea what is still missing?
It's not a binding, drop the header from the bindings.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 2/2] riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
From: Sandie Cao @ 2026-03-31 7:13 UTC (permalink / raw)
To: Conor Dooley
Cc: Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski, Yixun Lan,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Heinrich Schuchardt,
Troy Mitchell, Michael Opdenacker, Guodong Xu, Hendrik Hamerlinck,
Yangyu Chen, spacemit, linux-riscv, devicetree, linux-kernel,
Sandie Cao
In-Reply-To: <20260331071110.68321-1-sandie.cao@deepcomputing.io>
The FML13V05 board from DeepComputing incorporates a SpacemiT K3 RISC-V
SoC.It is a mainboard designed for the Framework Laptop 13 Chassis,
which has (Framework) SKU FRANHQ0001.
The FML13V05 board features:
- SpacemiT K3 RISC-V SoC
- LPDDR5 16GB or 32GB
- eMMC 32GB ~128GB (Optional)
- UFS 3.1 256G (Optional)
- QSPI Flash
- MicroSD Slot
- PCIe-based Wi-Fi
- 4 USB-C Ports
- Port 1: PD 3.0 (65W Max), USB 3.2 Gen 1
- Port 2: PD 3.0 (65W Max), USB 3.2 Gen 1, DP 1.4 (4K@60Hz)
- Port 3 & 4: USB 3.2 Gen 1
This minimal device tree enables booting into a serial console with UART
output.
Signed-off-by: Sandie Cao <sandie.cao@deepcomputing.io>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
---
v2:
Use formal format user name.
Add Reviewed-by from Troy Mitchell.
---
arch/riscv/boot/dts/spacemit/Makefile | 1 +
.../spacemit/k3-deepcomputing-fml13v05.dts | 28 +++++++++++++++++++
2 files changed, 29 insertions(+)
create mode 100644 arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
index 7e2b87702571..acb993c452ba 100644
--- a/arch/riscv/boot/dts/spacemit/Makefile
+++ b/arch/riscv/boot/dts/spacemit/Makefile
@@ -4,4 +4,5 @@ dtb-$(CONFIG_ARCH_SPACEMIT) += k1-milkv-jupiter.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k1-musepi-pro.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-r2s.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-rv2.dtb
+dtb-$(CONFIG_ARCH_SPACEMIT) += k3-deepcomputing-fml13v05.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k3-pico-itx.dtb
diff --git a/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts b/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
new file mode 100644
index 000000000000..2343ae3acc2d
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2024 DeepComputing (HK) Limited
+ */
+
+#include "k3.dtsi"
+
+/ {
+ model = "DeepComputing FML13V05";
+ compatible = "deepcomputing,fml13v05", "spacemit,k3";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0";
+ };
+
+ memory@100000000 {
+ device_type = "memory";
+ reg = <0x1 0x00000000 0x4 0x00000000>;
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 2/3] crash: Align the declaration of crash_load_dm_crypt_keys with CONFIG_CRASH_DM_CRYPT
From: Baoquan He @ 2026-03-31 7:12 UTC (permalink / raw)
To: Coiby Xu
Cc: kexec, linux-arm-kernel, linuxppc-dev, devicetree,
kernel test robot, Andrew Morton, Vivek Goyal, Dave Young,
open list
In-Reply-To: <20260225060347.718905-3-coxu@redhat.com>
On 02/25/26 at 02:03pm, Coiby Xu wrote:
> This will prevent a compiling failure when CONFIG_CRASH_DUMP is enabled
> but CONFIG_CRASH_DM_CRYPT is disabled,
>
> arch/powerpc/kexec/elf_64.c: In function 'elf64_load':
> >> arch/powerpc/kexec/elf_64.c:82:23: error: implicit declaration of function 'crash_load_dm_crypt_keys' [-Werror=implicit-function-declaration]
> 82 | ret = crash_load_dm_crypt_keys(image);
> | ^~~~~~~~~~~~~~~~~~~~~~~~
> cc1: some warnings being treated as errors
>
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202602120648.RgQALnnI-lkp@intel.com/
> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
> include/linux/crash_core.h | 14 +++++++-------
> 1 file changed, 7 insertions(+), 7 deletions(-)
Acked-by: Baoquan He <bhe@redhat.com>
>
> diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> index d35726d6a415..c1dee3f971a9 100644
> --- a/include/linux/crash_core.h
> +++ b/include/linux/crash_core.h
> @@ -34,13 +34,6 @@ static inline void arch_kexec_protect_crashkres(void) { }
> static inline void arch_kexec_unprotect_crashkres(void) { }
> #endif
>
> -#ifdef CONFIG_CRASH_DM_CRYPT
> -int crash_load_dm_crypt_keys(struct kimage *image);
> -ssize_t dm_crypt_keys_read(char *buf, size_t count, u64 *ppos);
> -#else
> -static inline int crash_load_dm_crypt_keys(struct kimage *image) {return 0; }
> -#endif
> -
> #ifndef arch_crash_handle_hotplug_event
> static inline void arch_crash_handle_hotplug_event(struct kimage *image, void *arg) { }
> #endif
> @@ -96,4 +89,11 @@ static inline void crash_save_cpu(struct pt_regs *regs, int cpu) {};
> static inline int kimage_crash_copy_vmcoreinfo(struct kimage *image) { return 0; };
> #endif /* CONFIG_CRASH_DUMP*/
>
> +#ifdef CONFIG_CRASH_DM_CRYPT
> +int crash_load_dm_crypt_keys(struct kimage *image);
> +ssize_t dm_crypt_keys_read(char *buf, size_t count, u64 *ppos);
> +#else
> +static inline int crash_load_dm_crypt_keys(struct kimage *image) {return 0; }
> +#endif
> +
> #endif /* LINUX_CRASH_CORE_H */
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v5 1/3] crash_dump/dm-crypt: Don't print in arch-specific code
From: Baoquan He @ 2026-03-31 7:12 UTC (permalink / raw)
To: Coiby Xu
Cc: kexec, linux-arm-kernel, linuxppc-dev, devicetree, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT), H. Peter Anvin,
Andrew Morton, Vivek Goyal, Dave Young,
open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)
In-Reply-To: <20260225060347.718905-2-coxu@redhat.com>
On 02/25/26 at 02:03pm, Coiby Xu wrote:
> When the vmcore dumping target is not a LUKS-encrypted target, it's
> expected that there is no dm-crypt key thus no need to return -ENOENT.
> Also print more logs in crash_load_dm_crypt_keys. The benefit is
> arch-specific code can be more succinct.
>
> Suggested-by: Will Deacon <will@kernel.org>
> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
> arch/x86/kernel/kexec-bzimage64.c | 6 +-----
> kernel/crash_dump_dm_crypt.c | 7 +++++--
> 2 files changed, 6 insertions(+), 7 deletions(-)
Acked-by: Baoquan He <bhe@redhat.com>
>
> diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
> index 5630c7dca1f3..7e980ea49d8d 100644
> --- a/arch/x86/kernel/kexec-bzimage64.c
> +++ b/arch/x86/kernel/kexec-bzimage64.c
> @@ -525,12 +525,8 @@ static void *bzImage64_load(struct kimage *image, char *kernel,
> if (ret)
> return ERR_PTR(ret);
> ret = crash_load_dm_crypt_keys(image);
> - if (ret == -ENOENT) {
> - kexec_dprintk("No dm crypt key to load\n");
> - } else if (ret) {
> - pr_err("Failed to load dm crypt keys\n");
> + if (ret)
> return ERR_PTR(ret);
> - }
> if (image->dm_crypt_keys_addr &&
> cmdline_len + MAX_ELFCOREHDR_STR_LEN + MAX_DMCRYPTKEYS_STR_LEN >
> header->cmdline_size) {
> diff --git a/kernel/crash_dump_dm_crypt.c b/kernel/crash_dump_dm_crypt.c
> index 1f4067fbdb94..2f7b42b09673 100644
> --- a/kernel/crash_dump_dm_crypt.c
> +++ b/kernel/crash_dump_dm_crypt.c
> @@ -414,14 +414,16 @@ int crash_load_dm_crypt_keys(struct kimage *image)
>
> if (key_count <= 0) {
> kexec_dprintk("No dm-crypt keys\n");
> - return -ENOENT;
> + return 0;
> }
>
> if (!is_dm_key_reused) {
> image->dm_crypt_keys_addr = 0;
> r = build_keys_header();
> - if (r)
> + if (r) {
> + pr_err("Failed to build dm-crypt keys header, ret=%d\n", r);
> return r;
> + }
> }
>
> kbuf.buffer = keys_header;
> @@ -432,6 +434,7 @@ int crash_load_dm_crypt_keys(struct kimage *image)
> kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
> r = kexec_add_buffer(&kbuf);
> if (r) {
> + pr_err("Failed to call kexec_add_buffer, ret=%d\n", r);
> kvfree((void *)kbuf.buffer);
> return r;
> }
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: clock: qcom,sm6125-dispcc: reference qcom,gcc.yaml
From: Krzysztof Kozlowski @ 2026-03-31 7:12 UTC (permalink / raw)
To: Biswapriyo Nath
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Pavel Machek, Sean Young,
Michael Turquette, Stephen Boyd, Martin Botka, linux-arm-msm,
devicetree, linux-kernel, linux-leds, linux-clk,
~postmarketos/upstreaming, phone-devel, kernel test robot
In-Reply-To: <20260330-ginkgo-add-usb-ir-vib-v3-2-c4b778b0d7f8@gmail.com>
On Mon, Mar 30, 2026 at 10:13:49AM +0000, Biswapriyo Nath wrote:
> Just like most of Qualcomm clock controllers, we can reference common
> qcom,gcc.yaml schema to unify the common parts of the binding. This
> also adds the '#reset-cells' property which is permitted for the
> SM6125 SoC clock controllers, but not listed as a valid property.
>
> Fixes: bb4d28e377cf ("arm64: dts: qcom: sm6125: Add missing MDSS core reset")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202603150629.GYoouFwZ-lkp@intel.com/
> Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
> ---
> .../devicetree/bindings/clock/qcom,dispcc-sm6125.yaml | 17 +++++------------
> 1 file changed, 5 insertions(+), 12 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Hongliang Wang @ 2026-03-31 7:11 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <2388acbc-a927-4727-a23c-5ecd7c33a926@kernel.org>
On 2026/3/30 下午3:23, Krzysztof Kozlowski wrote:
> On 30/03/2026 09:18, Hongliang Wang wrote:
>> On 2026/3/27 下午2:39, Krzysztof Kozlowski wrote:
>>> On 27/03/2026 04:09, Hongliang Wang wrote:
>>>> The initial idea was that this patch could be used for both ACPI and DTS.
>>>>>>> The i2c-ls2x driver is compatible with both Loongson 2K and 3A+7A
>>>>>>> platform, parse
>>>>>>> the same parameters regardless of dts or acpi parameter passing, So
>>>>>>> clock-input
>>>>>>> and clock-div attributes are defined to describe input clock of i2c
>>>>>>> controller and
>>>>>>> divisor of input clock. It can be used on both 2K and 3A+7A platform.
>>>>>> And you cannot use them in DTS.
>>>> OK
>>>>> I need to keep guessing what you want to achieve, because neither your
>>>>> message nor commit text was explicit
>>>> What I want to achieve is to describe the input clock and divisor of I2C
>>>> controller
>>> Input clocks are defined as clock inputs obviously in DT, not as
>>> integers. Bindings need to describe the hardware, so start with that.
>> I can describe the hardware in loongson,ls2x-i2c.yaml, and I would like to
>> confirm with you what final implementation plan you agree to? clock
>> framework
>> or custom clock-input an clock-div attributes? if clock framework, how
>> can it
>> also be used for ACPI?
> And you ask DT maintainer for that? It's not relevant. You sent DT
> bindings patch, so this patch must be correct and we discuss this patch
> here.
I don't. My idea is that if the clock input attribute can't be used for both
dts and acpi, then clock framework will be used for dts and new define
attribute
will be used for acpi. I will first implement the hardware description
and clock
framework in Bindings.
> Best regards,
> Krzysztof
Best regards,
Hongliang Wang
^ permalink raw reply
* [PATCH v2 0/2] Add DeepComputing FML13V05 board dts
From: Sandie Cao @ 2026-03-31 7:11 UTC (permalink / raw)
To: Conor Dooley
Cc: Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski, Yixun Lan,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Heinrich Schuchardt,
Troy Mitchell, Michael Opdenacker, Guodong Xu, Hendrik Hamerlinck,
Yangyu Chen, spacemit, linux-riscv, devicetree, linux-kernel,
Sandie Cao
This series updates Device Tree related files to introduce the
FML13V05 board from DeepComputing, which incorporates a Spacemit
K3 SoC. This board is designed for use on the Framework Laptop 13
Chassis, which has (Framework) SKU FRANHQ0001.
The series is based on riscv-dt-for-next.
v2:
- Patch 1:
Use formal format user name.
- Patch 2:
Use formal format user name.
Add Reviewed-by from Troy Mitchell.
Link to v1: https://lore.kernel.org/all/20260331034423.67142-1-sandie.cao@deepcomputing.io/
Sandie Cao (2):
dt-bindings: riscv: spacemit: add deepcomputing,fml13v05
riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
.../devicetree/bindings/riscv/spacemit.yaml | 1 +
arch/riscv/boot/dts/spacemit/Makefile | 1 +
.../spacemit/k3-deepcomputing-fml13v05.dts | 28 +++++++++++++++++++
3 files changed, 30 insertions(+)
create mode 100644 arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
base-commit: 4a1739c30fc66a59450c1f78923f94607e786882
--
2.43.0
^ permalink raw reply
* Re: [PATCH v3 2/2] arm64: dts: ti: Add audio overlay for k3-j721s2-evm
From: Krzysztof Kozlowski @ 2026-03-31 7:11 UTC (permalink / raw)
To: Moteen Shah
Cc: krzk+dt, robh, conor+dt, nm, vigneshr, kristo, devicetree,
linux-arm-kernel, linux-kernel, u-kumar1, gehariprasath,
y-abhilashchandra
In-Reply-To: <20260330094459.128648-3-m-shah@ti.com>
On Mon, Mar 30, 2026 at 03:14:59PM +0530, Moteen Shah wrote:
> + p10-hog {
> + /* P10 - MCASP/TRACE_MUX_S1 */
> + gpio-hog;
> + gpios = <10 GPIO_ACTIVE_HIGH>;
> + output-high;
> + line-name = "MCASP/TRACE_MUX_S1";
> + };
> +};
> +
> +&mux0 {
> + idle-state = <0>;
> +};
> +
> +&mux1 {
> + idle-state = <0>;
> +};
> +
> +&scm_conf {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + audio_refclk1: clock-controller@42e4 {
> + compatible = "ti,am62-audio-refclk";
there is no am62 compatible or DTSI include in the parent SoC file, so
am62n seems to be completely different device than j721s2.
Why does am62b appear here in this context?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: can: mcp251xfd: add microchip,xstbyen property
From: Marc Kleine-Budde @ 2026-03-31 7:10 UTC (permalink / raw)
To: Viken Dadhaniya
Cc: mani, thomas.kopp, mailhol, robh, krzk+dt, conor+dt, andersson,
konradybcio, linusw, brgl, linux-can, devicetree, linux-kernel,
linux-arm-msm, linux-gpio, mukesh.savaliya, anup.kulkarni,
Conor Dooley
In-Reply-To: <d4e092d6-5d9e-49a4-88d0-c02e2f17f36b@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 551 bytes --]
On 31.03.2026 12:15:26, Viken Dadhaniya wrote:
> Could you please let me know if the driver change looks acceptable to be merged?
> Once merged, I will proceed with posting the device-tree change.
Applied to linux-can-next. It will be included in my next PR.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v2 0/2] Add DeepComputing FML13V05 board dts
From: Sandie Cao @ 2026-03-31 7:10 UTC (permalink / raw)
To: Conor Dooley
Cc: Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski, Yixun Lan,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Heinrich Schuchardt,
Troy Mitchell, Michael Opdenacker, Guodong Xu, Hendrik Hamerlinck,
Yangyu Chen, spacemit, linux-riscv, devicetree, linux-kernel,
Sandie Cao
In-Reply-To: <20260331034423.67142-1-sandie.cao@deepcomputing.io>
This series updates Device Tree related files to introduce the
FML13V05 board from DeepComputing, which incorporates a Spacemit
K3 SoC. This board is designed for use on the Framework Laptop 13
Chassis, which has (Framework) SKU FRANHQ0001.
The series is based on riscv-dt-for-next.
v2:
- Patch 1:
Use formal format user name.
- Patch 2:
Use formal format user name.
Add Reviewed-by from Troy Mitchell.
Link to v1: https://lore.kernel.org/all/20260331034423.67142-1-sandie.cao@deepcomputing.io/
Sandie Cao (2):
dt-bindings: riscv: spacemit: add deepcomputing,fml13v05
riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
.../devicetree/bindings/riscv/spacemit.yaml | 1 +
arch/riscv/boot/dts/spacemit/Makefile | 1 +
.../spacemit/k3-deepcomputing-fml13v05.dts | 28 +++++++++++++++++++
3 files changed, 30 insertions(+)
create mode 100644 arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
base-commit: 4a1739c30fc66a59450c1f78923f94607e786882
--
2.43.0
^ permalink raw reply
* Re: [PATCH 0/2] Add PWM support Amlogic S7 S7D S6
From: Xianwei Zhao @ 2026-03-31 7:10 UTC (permalink / raw)
To: Martin Blumenstingl
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Neil Armstrong, Kevin Hilman,
Jerome Brunet, linux-pwm, devicetree, linux-kernel,
linux-arm-kernel, linux-amlogic, Junyi Zhao
In-Reply-To: <CAFBinCD1GPP82MEBDHg3BwCJg6JY5k2HksEt+kCB=YjnYTO7Tw@mail.gmail.com>
Hi Martin,
I confirmed with Junyi Zhao that the current implementation counts
from zero, so this submission is correct.
We agree this should be fixed and will address it in a follow-up patch.
Thanks for pointing it out.
On 2026/3/31 05:54, Martin Blumenstingl wrote:
> Hi Xianwei Zhao,
>
> thanks for your contribution!
>
> On Thu, Mar 26, 2026 at 7:35 AM Xianwei Zhao via B4 Relay
> <devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>> Add bindings and driver support Amlogic S7/S7D/S6 SoCs.
> There is an old report that got lost, stating that the current
> pwm-meson driver has an off-by-one error with the hi and lo fields:
> [0]
> Since you are working on bringing up a new platform: is this something
> you can verify in your lab?
> To be clear: I'm not expecting you to work on this ad-hoc or bring a
> patch into this series. However, it would be great if you could verify
> if the findings from [0] are correct and send an updated patch in
> future.
>
> Thank you and best regards
> Martin
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: soc: renesas: add MFIS binding documentation
From: Wolfram Sang @ 2026-03-31 7:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Geert Uytterhoeven, linux-renesas-soc, linux-kernel, Jassi Brar,
Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, devicetree
In-Reply-To: <c46357c9-8cf4-45ec-8b48-8cf979de2e98@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 433 bytes --]
> I did not get the driver so I cannot verify that. What sort of Linux ABI
> does this bind?
In case you mean this as unanswered questions to v1: This describes the
device specific second mbox cell. Like Tegra does it here (even with
shifts instead of plain numbers):
include/dt-bindings/mailbox/tegra186-hsp.h
But all this has been said before and you got the driver as well in v2.
I really have no idea what is still missing?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Ryan Chen @ 2026-03-31 7:09 UTC (permalink / raw)
To: Jeremy Kerr, Krzysztof Kozlowski
Cc: andriy.shevchenko@linux.intel.com, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Philipp Zabel, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <09cbc12bea5707f794e139ea1bfafac82c2d2c12.camel@codeconstruct.com.au>
> Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
> and enable-dma properties
>
> Hi Ryan,
>
> > All AST2600 I2C controller instances have DMA hardware.
> > I will remove the aspeed,enable-dma property and instead expose sysfs
> > attribute in driver to allow users to enable dma/buffer/byte.
>
> Sounds reasonable, but before you do so, how are you planning to manage the
> allocation of DMA channels across multiple i2c peripherals?
>
The AST2600 I2C hardware has only one can use DMA at a time.
To avoid the complexity of managing DMA channel contention,
I plan to use buffer mode by default for all controllers, which still provides
better performance than byte mode without requiring DMA channel allocation.
^ permalink raw reply
* Re: [PATCH v3 1/2] ti,j721e-system-controller.yaml: Allow audio-refclk as clock-controller child
From: Krzysztof Kozlowski @ 2026-03-31 7:09 UTC (permalink / raw)
To: Moteen Shah
Cc: krzk+dt, robh, conor+dt, nm, vigneshr, kristo, devicetree,
linux-arm-kernel, linux-kernel, u-kumar1, gehariprasath,
y-abhilashchandra
In-Reply-To: <20260330094459.128648-2-m-shah@ti.com>
On Mon, Mar 30, 2026 at 03:14:58PM +0530, Moteen Shah wrote:
> The ti,j721e-system-controller binding currently only allows
> clock-controller@ child nodes to reference the ti,am654-ehrpwm-tbclk
> schema. However, the system controller on J721S2 also contains audio
J721S2 or AM62?
> reference clock controllers (ti,am62-audio-refclk) that use the same
> clock-controller@XXXX naming pattern.
>
> Hence, extend the clock-controller pattern to accept either ehrpwm-tbclk
> or audio-refclk schemas using a oneOf constraint.
>
> Signed-off-by: Moteen Shah <m-shah@ti.com>
> ---
> .../bindings/soc/ti/ti,j721e-system-controller.yaml | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
> index f3bd0be3b279..d5d84a8f1257 100644
> --- a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
> +++ b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
> @@ -53,9 +53,11 @@ patternProperties:
>
> "^clock-controller@[0-9a-f]+$":
> type: object
> - $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
> + oneOf:
> + - $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
> + - $ref: /schemas/clock/ti,am62-audio-refclk.yaml#
Alphanumerical order.
There is no ti,am62 in the top level compatibles, so why am62 is here?
Top level has j721s2 but this ti,am62-audio-refclk.yaml only am62.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: i2c: intel,ixp4xx-i2c: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-03-31 7:07 UTC (permalink / raw)
To: Shi Hao
Cc: andi.shyti, conor+dt, devicetree, krzk+dt, linux-i2c,
linux-kernel, robh
In-Reply-To: <20260330054439.9545-1-i.shihao.999@gmail.com>
On Mon, Mar 30, 2026 at 11:14:39AM +0530, Shi Hao wrote:
> Convert the IOP3xx and IXP4xx XScale bindings to DT schema. This
> conversion also adds the interrupts property, as it is used by the driver
> and existing DTS files but was not documented in the original binding.
>
> Signed-off-by: Shi Hao <i.shihao.999@gmail.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4] ASoC: dt-bindings: imx-card: Complete the full list of supported DAI formats
From: Krzysztof Kozlowski @ 2026-03-31 7:05 UTC (permalink / raw)
To: Chancel Liu
Cc: lgirdwood, broonie, robh, krzk+dt, conor+dt, Frank.Li,
shengjiu.wang, s.hauer, kernel, festevam, linux-sound, devicetree,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260331012450.1298115-1-chancel.liu@nxp.com>
On Tue, Mar 31, 2026 at 10:24:50AM +0900, Chancel Liu wrote:
> Currently this binding only lists i2s and dsp_b formats that are used
> by existing sound cards. However, DT bindings should describe the full
> hardware capabilities rather than only the formats of current usage.
>
> The SAI audio controller of i.MX audio sound card supports multiple DAI
> formats, including:
> - i2s
> - left_j
> - right_j
> - dsp_a
> - dsp_b
> - pdm
> - msb
> - lsb
>
> Complete the full list of formats supported by i.MX audio sound card to
> ensure the binding correctly describes hardware.
>
> Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> ---
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 3/9] regulator: dt-bindings: Add MediaTek MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-03-31 7:04 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Linus Walleij,
Liam Girdwood, Mark Brown, Julien Massot, Gary Bisson,
Louis-Alexis Eyraud, Val Packett, Fabien Parent, Chen Zhong,
linux-input, devicetree, linux-kernel, linux-pm, linux-arm-kernel,
linux-gpio
In-Reply-To: <20260330083429.359819-4-l.scorcia@gmail.com>
On Mon, Mar 30, 2026 at 09:29:37AM +0100, Luca Leonardo Scorcia wrote:
> Add bindings for the regulators found in the MediaTek MT6392 PMIC,
> usually found in board designs using the MediaTek MT8516/MT8167 SoCs.
>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> ---
> .../regulator/mediatek,mt6392-regulator.yaml | 74 +++++++++++++++++++
> .../regulator/mediatek,mt6392-regulator.h | 24 ++++++
> 2 files changed, 98 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> create mode 100644 include/dt-bindings/regulator/mediatek,mt6392-regulator.h
>
> diff --git a/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> new file mode 100644
> index 000000000000..24fbaef0e717
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/mediatek,mt6392-regulator.yaml
> @@ -0,0 +1,74 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/regulator/mediatek,mt6392-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: MediaTek MT6392 regulator
> +
> +description:
> + Regulator node of the PMIC. This node should under the PMIC's device node.
> + MT6392 is a power management system chip containing three buck converters and
> + 23 LDOs. All voltage regulators provided by the PMIC are described as
> + sub-nodes of this node.
> +
So that's a dead code / schema.
Try yourself if it works.
Your parent schema must reference this one for the regulators node.
Best regards,
Krzysztof
^ permalink raw reply
* Re: New default binding for PWM devices? [Was: Re: [PATCH] dt-bindings: timer: xlnx,xps-timer: Make PWM in example usable]
From: Uwe Kleine-König @ 2026-03-31 7:03 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Daniel Lezcano,
Thomas Gleixner, Krzysztof Kozlowski, Sean Anderson, linux-kernel,
linux-pwm, devicetree, Chris Packham, Marek Vasut
In-Reply-To: <CAMuHMdXDZD6QAbKgny1utfYhagUEZ5pcgiDCTTfJKNVVZLOUYg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]
Hello Geert,
On Mon, Mar 30, 2026 at 02:12:47PM +0200, Geert Uytterhoeven wrote:
> On Sat, 7 Jun 2025 at 09:23, Uwe Kleine-König
> <u.kleine-koenig@baylibre.com> wrote:
> > On Fri, Jun 06, 2025 at 09:13:24AM -0500, Rob Herring wrote:
> > > reg:
> > > > maxItems: 1
> > > >
> > > > - '#pwm-cells': true
> > > > + '#pwm-cells':
> > > > + const: 3
> > > >
> > > > xlnx,count-width:
> > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > @@ -82,7 +83,7 @@ examples:
> > > > };
> > > >
> > > > timer@800f0000 {
> > > > - #pwm-cells = <0>;
> > > > + #pwm-cells = <3>;
> > > > clock-names = "s_axi_aclk";
> > > > clocks = <&zynqmp_clk 71>;
> > > > compatible = "xlnx,xps-timer-1.00.a";
> > > >
> > > > There is however one concern that I want to get resolved first to
> > > > prevent churn:
> > > >
> > > > In principle I think it's bad that a phandle to a PWM must contain a
> > > > period and flags specifying the polarity. For some use cases the period
> > > > might not matter or is implicitly given or more than one period length
> > > > is relevant.
> > >
> > > Why can't the period be 0 and no flags set if they aren't needed?
> >
> > I don't say they cannot, and probably that's the most sane option if
> > there is no fixed default period and flags and we're sticking to 3
> > cells.
>
> So zero should have been used for drivers/pwm/pwm-argon-fan-hat.c?
Do you mean #pwm-cells = <0>? Or period = flags = 0?
If the phandle wouldn't contain period and flags and so it would only be
used to identify the PWM to use and say nothing about how it is used,
then using #pwm-cells = <0> for PWM chips that only have a single PWM
would work fine.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v9 7/7] arm64: dts: qcom: sdm670-google-sargo: add imx355 front camera
From: Sakari Ailus @ 2026-03-31 7:02 UTC (permalink / raw)
To: Richard Acayan
Cc: David Heidelberg, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Robert Foss, Todor Tomov,
Bryan O'Donoghue, Vladimir Zapolskiy, Bjorn Andersson,
Konrad Dybcio, Tianshu Qiu, Robert Mader, phone-devel,
linux-arm-msm, devicetree, linux-media
In-Reply-To: <acsjH0tZ-jj7N7c5@rdacayan>
On Mon, Mar 30, 2026 at 09:27:59PM -0400, Richard Acayan wrote:
> On Tue, Mar 24, 2026 at 12:57:59PM +0200, Sakari Ailus wrote:
> > Hi David, Richard,
> >
> > On Tue, Mar 24, 2026 at 10:35:24AM +0100, David Heidelberg wrote:
> > >
> > >
> > > On 24/03/2026 03:05, Richard Acayan wrote:
> > > > On Fri, Mar 13, 2026 at 07:26:47PM +0100, David Heidelberg wrote:
> > > > > On 17/02/2026 01:27, Richard Acayan wrote:
> > > > > [...]
> > > > >
> > > > > > +&cci_i2c1 {
> > > > > > + camera@1a {
> > > > > > + compatible = "sony,imx355";
> > > > > > + reg = <0x1a>;
> > > > > > +
> > > > > > + clocks = <&camcc CAM_CC_MCLK2_CLK>;
> > > > > > +
> > > > > > + assigned-clocks = <&camcc CAM_CC_MCLK2_CLK>;
> > > > > > + assigned-clock-rates = <19200000>;
> > > > >
> > > > > Extract from #sdm670-mainline:erebion.eu discussion:
> > > > > The imx355 can operate on 24 MHz (on both Pixel 3 and 3a), but Linux kernel
> > > > > driver can operate only with 19.2 MHz.
> > > > >
> > > > > I assume it would be worth it mention at least by comment here.
> > > >
> > > > This might set the series back because the devicetree isn't meant to be
> > > > written for specific software, but it's included in v11 because you
> > > > already asked twice.
> > > >
> > >
> > > I would say node with lower clock frequency is still much better than
> > > nothing or placeholder saying "i2c camera here". Instead we'll have small
> > > placeholder that value can be bumped to 24 MHz. Important is this can be
> > > easily improved when at least one consumer of the device-tree gains support.
> > >
> > > We have very scarce support of cameras on mobile phones in mainline, thus
> > > leaving a comment that HW can do 24 MHz is reasonable compromise IMHO.
> >
> > The bindings could document the supported frequency range.
> >
> > In DTS it may make sense to set the frequency the vendor uses as it may
> > affect the link frequencies (albeit I guess they're the same in this
> > case?).
>
> Is this review relevant to v11?
I'd think so: it doesn't mention the frequency should be 24 MHz.
--
Sakari Ailus
^ permalink raw reply
* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Krzysztof Kozlowski @ 2026-03-31 7:01 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett, Dmitry Torokhov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sen Chu,
Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Louis-Alexis Eyraud, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <20260330083429.359819-2-l.scorcia@gmail.com>
On Mon, Mar 30, 2026 at 09:29:35AM +0100, Luca Leonardo Scorcia wrote:
> - items:
> - enum:
> - mediatek,mt6366-rtc
> @@ -99,9 +107,6 @@ properties:
> - mediatek,mt6366-regulator
> - const: mediatek,mt6358-regulator
>
> - required:
> - - compatible
Not really, this affects existing ABI and might make the child schema
being applied. Basically regulators node can be anything now.
This is definitely not a binding we want. The syntax for parent schema
when listing only compatibles is requiring this compatible. You cannot
have here whatever empty node.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Jeremy Kerr @ 2026-03-31 7:00 UTC (permalink / raw)
To: Ryan Chen, Krzysztof Kozlowski
Cc: andriy.shevchenko@linux.intel.com, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Philipp Zabel, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <TY2PPF5CB9A1BE6F267C60EEC34B6A75400F253A@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
Hi Ryan,
> All AST2600 I2C controller instances have DMA hardware.
> I will remove the aspeed,enable-dma property and instead expose sysfs
> attribute in driver to allow users to enable dma/buffer/byte.
Sounds reasonable, but before you do so, how are you planning to manage
the allocation of DMA channels across multiple i2c peripherals?
Cheers,
Jeremy
^ permalink raw reply
* RE: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Ryan Chen @ 2026-03-31 6:58 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: jk@codeconstruct.com.au, andriy.shevchenko@linux.intel.com,
Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Benjamin Herrenschmidt,
Philipp Zabel, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <20260331-fanatic-certain-bustard-fb13bc@quoll>
> Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
> and enable-dma properties
>
> On Mon, Mar 30, 2026 at 04:21:47PM +0800, Ryan Chen wrote:
> > Add aspeed,enable-dma boolean property to indicate that DMA is
> > available for transfers on this I2C bus.
> >
> > Also add the aspeed,global-regs phandle to reference the AST2600
> > global registers syscon node, containing the SoC-common I2C register
> > set.
> >
> > These properties apply only to the AST2600 binding. Legacy DTs remain
> > unchanged.
> >
> > Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> > ---
> > Changes in v28:
> > - update commit message correspond with aspeed,enable-dma.
> > - remove aspeed,transfer-mode and add aspeed,enable-dma property and
> > description.
> > - Fix aspeed,enable-dma description to reflect hardware capability rather
> > than software behavior
> > Changes in v27:
> > - change aspeed,transfer-mode to aspeed,enable-dma.
> > ---
> > .../devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml | 12
> ++++++++++++
> > 1 file changed, 12 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> > b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> > index de2c359037da..67b23d1a4cec 100644
> > --- a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> > +++ b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> > @@ -37,6 +37,16 @@ properties:
> > resets:
> > maxItems: 1
> >
> > + aspeed,enable-dma:
> > + type: boolean
> > + description: Indicates this I2C controller instance has DMA capability.
>
> Compatible implies that "I2C controller instance has DMA capability", no?
>
> How two same devices, with exactly the same or compatible programming
> model can have difference in the programming model for DMA (one lacks it)?
>
> Best regards,
> Krzysztof
Thanks your review.
All AST2600 I2C controller instances have DMA hardware.
I will remove the aspeed,enable-dma property and instead expose sysfs
attribute in driver to allow users to enable dma/buffer/byte.
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Krzysztof Kozlowski @ 2026-03-31 6:58 UTC (permalink / raw)
To: Jianhua Lin
Cc: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, devicetree, linux-kernel, linux-media,
linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group, sirius.wang, vince-wl.liu,
jh.hsu
In-Reply-To: <20260331005458.24010-2-jianhua.lin@mediatek.com>
On Tue, Mar 31, 2026 at 08:54:56AM +0800, Jianhua Lin wrote:
> Add the compatible string for the JPEG decoder block found in the
> MediaTek MT8189 SoC.
>
> Compared to previous generation ICs, the MT8189 JPEG decoder requires
> 34-bit IOVA address space support and only needs a single clock
> ("jpgdec") instead of two. Therefore, it is added as a standalone
> compatible string without falling back to older SoCs.
>
> Update the binding schema to include the new compatible string and add
> an `allOf` block with conditional checks. This enforces the single clock
> requirement for MT8189 while preserving the two-clock requirement
> ("jpgdec-smi", "jpgdec") for older SoCs.
>
> Suggested-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
> ---
> .../bindings/media/mediatek-jpeg-decoder.yaml | 44 +++++++++++++++----
> 1 file changed, 36 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> index a4aacd3eb189..601fe05b73e7 100644
> --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
> @@ -15,10 +15,10 @@ description: |-
> properties:
> compatible:
> oneOf:
> - - items:
> - - enum:
> - - mediatek,mt8173-jpgdec
> - - mediatek,mt2701-jpgdec
> + - enum:
> + - mediatek,mt2701-jpgdec
> + - mediatek,mt8173-jpgdec
> + - mediatek,mt8189-jpgdec
> - items:
> - enum:
> - mediatek,mt7623-jpgdec
> @@ -32,13 +32,22 @@ properties:
> maxItems: 1
>
> clocks:
> + minItems: 1
> maxItems: 2
> - minItems: 2
>
> clock-names:
> - items:
> - - const: jpgdec-smi
> - - const: jpgdec
> + minItems: 1
> + maxItems: 2
Why jpgdec-smi alone is now valid? Drop these two.
> + oneOf:
> + - items:
> + - const: jpgdec
> + - items:
> + - const: jpgdec-smi
> + - const: jpgdec
> +
> + mediatek,larb:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: a phandle to the smi_larb node.
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