* Re: [PATCH v4 0/4] Introduce Allwinner H616 PWM controller
From: Uwe Kleine-König @ 2026-03-25 7:14 UTC (permalink / raw)
To: Richard GENOUD
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Philipp Zabel, Paul Kocialkowski,
Thomas Petazzoni, John Stultz, Joao Schim, linux-pwm, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel
In-Reply-To: <b47801f9-3828-4c68-992c-e85373576f3d@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 360 bytes --]
Hello Richard,
On Mon, Mar 23, 2026 at 05:27:07PM +0100, Richard GENOUD wrote:
> Hi Uwe, do you plan to grab this series or does it needs some further
> reviews?
I didn't find the time to look into your patches yet, but I have them on
my list. Unfortunately there is quite some more on that list, so I'll
have to ask you for some patience.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] fpga: m10bmc-sec: switch show_canceled_csk() to using sysfs_emit()
From: Xu Yilun @ 2026-03-25 7:25 UTC (permalink / raw)
To: Yury Norov
Cc: linux-kernel, Christophe Leroy (CS GROUP), Peter Zijlstra (Intel),
Rafael J. Wysocki, Alexander Shishkin, Daniel Lezcano,
Ingo Molnar, James Clark, Kees Cook, Lukasz Luba,
Madhavan Srinivasan, Michael Ellerman, Mike Leach, Moritz Fischer,
Nicholas Piggin, Russ Weight, Shrikanth Hegde, Suki K Poulose,
Tom Rix, Thomas Weißschuh, Xu Yilun, Yury Norov, Zhang Rui,
coresight, linux-arm-kernel, linux-fpga, linux-pm, linuxppc-dev,
Jakub Kicinski
In-Reply-To: <acLaDFuCzt0d33Q_@yury>
On Tue, Mar 24, 2026 at 02:38:04PM -0400, Yury Norov wrote:
> On Tue, Mar 24, 2026 at 05:15:33PM +0800, Xu Yilun wrote:
> > On Tue, Mar 03, 2026 at 03:08:41PM -0500, Yury Norov wrote:
> > > Switch show_canceled_csk() to use the proper sysfs_emit("%*pbl").
> > >
> > > Reviewed-by: Russ Weight <russ.weight@linux.dev>
> > > Suggested-by: Thomas Weißschuh <linux@weissschuh.net>
> > > Signed-off-by: Yury Norov <ynorov@nvidia.com>
> > > ---
> > > drivers/fpga/intel-m10-bmc-sec-update.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/fpga/intel-m10-bmc-sec-update.c b/drivers/fpga/intel-m10-bmc-sec-update.c
> > > index 10f678b9ed36..ae364c6636eb 100644
> > > --- a/drivers/fpga/intel-m10-bmc-sec-update.c
> > > +++ b/drivers/fpga/intel-m10-bmc-sec-update.c
> > > @@ -10,6 +10,7 @@
> > > #include <linux/firmware.h>
> > > #include <linux/mfd/intel-m10-bmc.h>
> > > #include <linux/mod_devicetable.h>
> > > +#include <linux/mm.h>
> >
> > Why add this header file?
>
> When I was preparing the series, I had build issues without this. But
> now I checked it against -rc5, and it's clean. Would you like me to
> resend?
No need. Given that I'll pick this patch alone to fpga for-next with the
fix.
Reviewed-by: Xu Yilun <yilun.xu@intel.com>
>
> > > #include <linux/module.h>
> > > #include <linux/platform_device.h>
> > > #include <linux/slab.h>
> > > @@ -183,7 +184,7 @@ show_canceled_csk(struct device *dev, u32 addr, char *buf)
> > >
> > > bitmap_from_arr32(csk_map, csk32, CSK_BIT_LEN);
> > > bitmap_complement(csk_map, csk_map, CSK_BIT_LEN);
> > > - return bitmap_print_to_pagebuf(1, buf, csk_map, CSK_BIT_LEN);
> > > + return sysfs_emit(buf, "%*pbl\n", CSK_BIT_LEN, csk_map);
> > > }
> > >
> > > #define DEVICE_ATTR_SEC_CSK_RO(_name) \
> > > --
> > > 2.43.0
> > >
> > >
^ permalink raw reply
* Re: [PATCH bpf-next v10 1/5] bpf: Move constants blinding out of arch-specific JITs
From: Xu Kuohai @ 2026-03-25 7:47 UTC (permalink / raw)
To: bot+bpf-ci, bpf, linux-kernel, linux-arm-kernel
Cc: ast, daniel, andrii, martin.lau, eddyz87, yonghong.song, puranjay,
a.s.protopopov, alexis.lothore, list+bpf, linux, yangtiezhu,
hengqi.chen, johan.almbladh, paulburton, hbathini, chleroy,
naveen, luke.r.nels, xi.wang, bjorn, pulehui, iii, hca, gor,
davem, udknight, martin.lau, clm, ihor.solodrai
In-Reply-To: <edfa617891aa2e2980ecfb8037a7a4ed069e518bbce1777e331c737024feb1da@mail.kernel.org>
On 3/24/2026 8:46 PM, bot+bpf-ci@kernel.org wrote:
>> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
>> index 67eb12b637a5..8f52f4b6c3af 100644
>> --- a/kernel/bpf/core.c
>> +++ b/kernel/bpf/core.c
>
> [ ... ]
>
>> @@ -1507,13 +1507,16 @@ static void adjust_insn_arrays(struct bpf_prog *prog, u32 off, u32 len)
>> #endif
>> }
>>
>> -struct bpf_prog *bpf_jit_blind_constants(struct bpf_prog *prog)
>> +struct bpf_prog *bpf_jit_blind_constants(struct bpf_verifier_env *env, struct bpf_prog *prog)
>> {
>
> [ ... ]
>
>> - tmp = bpf_patch_insn_single(clone, i, insn_buff, rewritten);
>> - if (IS_ERR(tmp)) {
>> + if (env)
>> + tmp = bpf_patch_insn_data(env, subprog_start + i, insn_buff, rewritten);
>> + else
>> + tmp = bpf_patch_insn_single(clone, i, insn_buff, rewritten);
>
> When env is non-NULL, bpf_patch_insn_data() adjusts env->insn_aux_data
> via adjust_insn_aux_data() and env->subprog_info via
> adjust_subprog_starts(). This shifts subprogram start positions to
> account for the expanded instructions.
>
Right, but only the subsequent subprogs are shifted, the current subprog
is not. Since we are patching the main prog when env is non-NULL, and
subprog_start is always 0 for a main prog, subprog_start is not needed
here and can be removed.
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index cd008b146ee5..1b2b99f2d859 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>
[ ... ]
>> }
>> bpf_prog_jit_attempt_done(prog);
>> return err;
>
> When blinded is true, the rollback restores env->prog to orig_prog, but
> env->subprog_info still holds the shifted start positions from blinding
> (adjusted by adjust_subprog_starts() in bpf_patch_insn_data()). The
> commit message states "env->insn_aux_data and env->subprog_info are no
> longer used after JIT failure." However, on configurations without
> CONFIG_BPF_JIT_ALWAYS_ON, fixup_call_args() falls through to the
> interpreter fixup loop after jit_subprogs() fails:
>
> fixup_call_args() {
> err = jit_subprogs(env); /* fails, e.g. -ENOTSUPP */
> ...
> for (i = 0; i < prog->len; ...) {
> ...
> depth = get_callee_stack_depth(env, insn, i);
> }
> }
>
> get_callee_stack_depth() computes a target address from orig_prog's
> original instruction offsets and calls find_subprog(env, start). Since
> env->subprog_info start positions were shifted by blinding but the
> instruction addresses are from the unblinded orig_prog, find_subprog()
> fails to find a matching entry and returns -ENOENT, triggering a
> spurious "verifier bug" warning and rejecting the program.
>
> Could env->subprog_info be restored alongside the prog rollback, or
> could jit_subprogs() return -EFAULT when blinding was active to skip
> the interpreter fallback path?
>
We can save and restore env->subprog_info. Since only the subprog start
values in the subprog_info array are adjusted by the patching function,
I will just back up the original values and restore them on failure,
without duplicating the full subprog_info array.
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23488858455
^ permalink raw reply
* RE: [PATCH v2] ASoC: dt-bindings: imx-card: Add dsp_a DAI format
From: Chancel Liu @ 2026-03-25 7:52 UTC (permalink / raw)
To: Frank Li
Cc: lgirdwood@gmail.com, broonie@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, shengjiu.wang@gmail.com,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-sound@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <abA0W82MyPtB2iVj@lizhi-Precision-Tower-5810>
> > The imx-card machine driver originally supported only codecs operating
> > in i2s or dsp_b formats. This machine driver can support CS42448 codec
> > and this codec typically uses dsp_a for its TDM interface. Therefore,
> > dsp_a format support is required for describing such sound cards in DT.
>
> binding is descript hardware not driver. s/driver/device.
>
> Frank
Yes. I realize the commit message is incorrect. The intention is to
describe the codec hardware requirement. I will fix it.
Regards,
Chancel Liu
> >
> > Update DT bindings to include "dsp_a" in the list of supported DAI
> > formats.
> >
> > Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> > ---
> > Documentation/devicetree/bindings/sound/imx-audio-card.yaml | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
> > b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
> > index 3c75c8c78987..5c08289346c0 100644
> > --- a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
> > +++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml
> > @@ -36,6 +36,7 @@ patternProperties:
> > items:
> > enum:
> > - i2s
> > + - dsp_a
> > - dsp_b
> >
> > dai-tdm-slot-num:
> > --
> > 2.50.1
> >
^ permalink raw reply
* RE: Re: [PATCH v2] ASoC: dt-bindings: imx-card: Add dsp_a DAI format
From: Chancel Liu @ 2026-03-25 7:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: lgirdwood@gmail.com, broonie@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, Frank Li,
shengjiu.wang@gmail.com, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-sound@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260311-brave-acoustic-mongrel-b3978d@quoll>
> > The imx-card machine driver originally supported only codecs operating
> > in i2s or dsp_b formats. This machine driver can support CS42448 codec
> > and this codec typically uses dsp_a for its TDM interface. Therefore,
>
> And what about other formats, which was asked last time?
>
The imx-card machine driver currently implements support only for
codecs with i2s and dsp_b format. The newly added CS42448 codec
requires dsp_a and that is why this patch adds dsp_a only. No other
formats are used or supported by the existing hardware covered by this
binding, so they are not included.
> > dsp_a format support is required for describing such sound cards in DT.
> >
> > Update DT bindings to include "dsp_a" in the list of supported DAI
> > formats.
> >
> > Signed-off-by: Chancel Liu <chancel.liu@nxp.com>
> > ---
> > Documentation/devicetree/bindings/sound/imx-audio-card.yaml | 1 +
> > 1 file changed, 1 insertion(+)
>
> Where is changelog?
>
Sorry for this oversight.
I will add v2 change log(as well as for v3 and future versions)
for example:
changes in v2:
- Updated commit message to explain current support for i2s and dsp_b
formats and new support for dsp_a. No code changes.
> Where is any explanation how you handled or not handled previous review?
>
> Best regards,
> Krzysztof
My intention in v2 was to directly fix the issues raised by you and
other reviewers and maintainers, but I mistakenly assumed that applying
the changes in the new version was sufficient. I understand now that it
is required to explicitly describe how each review comment was handled,
even if the changes are already included in the updated patch. I will
add a clear changelog and detailed explanation in v3.
Regards,
Chancel Liu
^ permalink raw reply
* [PATCH v2 0/5] powervr: MT8173 GPU support
From: Chen-Yu Tsai @ 2026-03-25 7:19 UTC (permalink / raw)
To: Stephen Boyd, Matthias Brugger, AngeloGioacchino Del Regno,
Frank Binns, Matt Coster, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann
Cc: Icenowy Zheng, Icenowy Zheng, Chen-Yu Tsai, David Airlie,
Simona Vetter, linux-clk, devicetree, linux-mediatek, dri-devel,
linux-arm-kernel, linux-kernel
Hi everyone,
This is v2 of my MT8173 PowerVR GPU support series.
Changes since v1:
- Adapted to changed DT bindings
- Dropped driver change
- Use same power domain for "a" and "b" GPU power domains
This update was requested by Icenowy.
This series enables the PowerVR GPU found in the MT8173 SoC, found in
some Chromebooks.
This version is different from the initial powervr driver submission [1]
in that it splits out the GPU glue layer support out of the powervr
driver and into a separate clock and power domain driver. The glue code
is otherwise the same, and also the same as found in the ChromeOS
kernels, with some extra comments and macro names added where possible.
Patch 1 adds a binding for the glue layer, called mfgtop. The glue layer
contains clock and power controls for the GPU.
Patch 2 adds a driver for the glue layer.
Patch 3 adds an entry for the MT8173 GPU and 6XT series to the PowerVR
binding.
Patch 4 adds an entry for the PowerVR 6XT series GPU to the driver.
Patch 5 corrects the clock for the GPU (called MFG) power domain.
Patch 6 adds device nodes for the GPU and glue layer to the MT8173 dtsi
file.
Patch 2 and 6 depend on patch 1 to build. I suppose some common
immutable tree would be needed from the MediaTek maintainers.
The kernel driver successfully probes the hardware and loads the
"rogue_4.40.2.51_v1.fw" firmware provided by Imagination Technologies [2].
Userspace was tested with Mesa 24.0.8 from Debian Trixie rebuilt with
the powervr vulkan driver enabled. `vulkaninfo` gives some information
about the GPU (attached at the end), but running the `triangle` example
from the Sascha Willems demos [3] with -DUSE_D2D_WSI=ON as recommended [4]
failed with:
Can't find a display and a display mode!
Same program worked correctly on a BeaglePlay and displayed a color
gradient triangle. Not sure what went wrong here.
Anyway, please have a look and test.
Thanks
ChenYu
[1] https://lore.kernel.org/dri-devel/20220815165156.118212-2-sarah.walker@imgtec.com/
[2] https://gitlab.freedesktop.org/imagination/linux-firmware/-/tree/powervr
[3] https://github.com/SaschaWillems/Vulkan
[4] https://lore.kernel.org/dri-devel/f2b2671e-5acc-4dec-9c2e-3c9cd2e1f19e@imgtec.com/
Chen-Yu Tsai (5):
dt-bindings: clock: mediatek: Add mt8173 mfgtop
clk: mediatek: Add mt8173-mfgtop driver
dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPU
arm64: dts: mediatek: mt8173: Fix MFG_ASYNC power domain clock
arm64: dts: mediatek: mt8173: Add GPU device nodes
.../clock/mediatek,mt8173-mfgtop.yaml | 70 +++++
.../bindings/gpu/img,powervr-rogue.yaml | 1 +
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 33 ++-
drivers/clk/mediatek/Kconfig | 9 +
drivers/clk/mediatek/Makefile | 1 +
drivers/clk/mediatek/clk-mt8173-mfgtop.c | 243 ++++++++++++++++++
include/dt-bindings/clock/mt8173-clk.h | 7 +
7 files changed, 363 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt8173-mfgtop.yaml
create mode 100644 drivers/clk/mediatek/clk-mt8173-mfgtop.c
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply
* [PATCH v2 1/5] dt-bindings: clock: mediatek: Add mt8173 mfgtop
From: Chen-Yu Tsai @ 2026-03-25 7:19 UTC (permalink / raw)
To: Stephen Boyd, Matthias Brugger, AngeloGioacchino Del Regno,
Frank Binns, Matt Coster, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann
Cc: Icenowy Zheng, Icenowy Zheng, Chen-Yu Tsai, David Airlie,
Simona Vetter, linux-clk, devicetree, linux-mediatek, dri-devel,
linux-arm-kernel, linux-kernel, Conor Dooley
In-Reply-To: <20260325071951.544031-1-wenst@chromium.org>
The MFG (GPU) block on the MT8173 has a small glue layer, named MFG_TOP
in the datasheet, that contains clock gates, some power sequence signal
delays, and other unknown registers that get toggled when the GPU is
powered on.
The clock gates are exposed as clocks provided by a clock controller,
while the power sequencing bits are exposed as one singular power domain.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes since v1:
- Dropped minItems for clocks
- Dropped label in example
---
.../clock/mediatek,mt8173-mfgtop.yaml | 70 +++++++++++++++++++
include/dt-bindings/clock/mt8173-clk.h | 7 ++
2 files changed, 77 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/mediatek,mt8173-mfgtop.yaml
diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt8173-mfgtop.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt8173-mfgtop.yaml
new file mode 100644
index 000000000000..03db1ee9e594
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mediatek,mt8173-mfgtop.yaml
@@ -0,0 +1,70 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/clock/mediatek,mt8173-mfgtop.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT8173 MFG TOP controller
+
+maintainers:
+ - AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
+
+description:
+ The MFG TOP glue layer controls various signals going to the MFG (GPU)
+ block on the MT8173.
+
+properties:
+ compatible:
+ const: mediatek,mt8173-mfgtop
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: sys
+ - const: mem
+ - const: core
+ - const: clk26m
+
+ power-domains:
+ maxItems: 1
+
+ '#clock-cells':
+ const: 1
+
+ '#power-domain-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - power-domains
+ - '#clock-cells'
+ - '#power-domain-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/mt8173-clk.h>
+ #include <dt-bindings/power/mt8173-power.h>
+
+ clock-controller@13fff000 {
+ compatible = "mediatek,mt8173-mfgtop";
+ reg = <0x13fff000 0x1000>;
+ clocks = <&topckgen CLK_TOP_AXI_MFG_IN_SEL>,
+ <&topckgen CLK_TOP_MEM_MFG_IN_SEL>,
+ <&topckgen CLK_TOP_MFG_SEL>,
+ <&clk26m>;
+ clock-names = "sys", "mem", "core", "clk26m";
+ power-domains = <&spm MT8173_POWER_DOMAIN_MFG>;
+ #clock-cells = <1>;
+ #power-domain-cells = <0>;
+ };
diff --git a/include/dt-bindings/clock/mt8173-clk.h b/include/dt-bindings/clock/mt8173-clk.h
index 3d00c98b9654..89e982f771db 100644
--- a/include/dt-bindings/clock/mt8173-clk.h
+++ b/include/dt-bindings/clock/mt8173-clk.h
@@ -243,6 +243,13 @@
#define CLK_IMG_FD 7
#define CLK_IMG_NR_CLK 8
+/* MFG_SYS */
+
+#define CLK_MFG_AXI 0
+#define CLK_MFG_MEM 1
+#define CLK_MFG_G3D 2
+#define CLK_MFG_26M 3
+
/* MM_SYS */
#define CLK_MM_SMI_COMMON 1
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH v2 2/5] clk: mediatek: Add mt8173-mfgtop driver
From: Chen-Yu Tsai @ 2026-03-25 7:19 UTC (permalink / raw)
To: Stephen Boyd, Matthias Brugger, AngeloGioacchino Del Regno,
Frank Binns, Matt Coster, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann
Cc: Icenowy Zheng, Icenowy Zheng, Chen-Yu Tsai, David Airlie,
Simona Vetter, linux-clk, devicetree, linux-mediatek, dri-devel,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260325071951.544031-1-wenst@chromium.org>
The MFG (GPU) block on the MT8173 has a small glue layer, named MFG_TOP
in the datasheet, that contains clock gates, some power sequence signal
delays, and other unknown registers that get toggled when the GPU is
powered on.
The clock gates are exposed as clocks provided by a clock controller,
while the power sequencing bits are exposed as one singular power domain.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v1:
- Reduce tab after GATE_MFG() by one tab
- Move of_match_clk_mt8173_mfgtop to just before clk_mt8173_mfgtop_drv
- Rename power domain to "mfg-top"
- Add FORCE_ABORT and ACTIVE_PWRCTL_EN bits and explicitly clear
ACTIVE_PWRCTL_EN bit
---
drivers/clk/mediatek/Kconfig | 9 +
drivers/clk/mediatek/Makefile | 1 +
drivers/clk/mediatek/clk-mt8173-mfgtop.c | 243 +++++++++++++++++++++++
3 files changed, 253 insertions(+)
create mode 100644 drivers/clk/mediatek/clk-mt8173-mfgtop.c
diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 2c09fd729bab..8dbd9f14be62 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -537,6 +537,15 @@ config COMMON_CLK_MT8173_IMGSYS
help
This driver supports MediaTek MT8173 imgsys clocks.
+config COMMON_CLK_MT8173_MFGTOP
+ tristate "Clock and power driver for MediaTek MT8173 mfgtop"
+ depends on COMMON_CLK_MT8173
+ default COMMON_CLK_MT8173
+ select PM_GENERIC_DOMAINS
+ select PM_GENERIC_DOMAINS_OF
+ help
+ This driver supports MediaTek MT8173 mfgtop clocks and power domain.
+
config COMMON_CLK_MT8173_MMSYS
tristate "Clock driver for MediaTek MT8173 mmsys"
depends on COMMON_CLK_MT8173
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index d8736a060dbd..892a54eeb281 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_COMMON_CLK_MT8167_VDECSYS) += clk-mt8167-vdec.o
obj-$(CONFIG_COMMON_CLK_MT8173) += clk-mt8173-apmixedsys.o clk-mt8173-infracfg.o \
clk-mt8173-pericfg.o clk-mt8173-topckgen.o
obj-$(CONFIG_COMMON_CLK_MT8173_IMGSYS) += clk-mt8173-img.o
+obj-$(CONFIG_COMMON_CLK_MT8173_MFGTOP) += clk-mt8173-mfgtop.o
obj-$(CONFIG_COMMON_CLK_MT8173_MMSYS) += clk-mt8173-mm.o
obj-$(CONFIG_COMMON_CLK_MT8173_VDECSYS) += clk-mt8173-vdecsys.o
obj-$(CONFIG_COMMON_CLK_MT8173_VENCSYS) += clk-mt8173-vencsys.o
diff --git a/drivers/clk/mediatek/clk-mt8173-mfgtop.c b/drivers/clk/mediatek/clk-mt8173-mfgtop.c
new file mode 100644
index 000000000000..9e18f34166ae
--- /dev/null
+++ b/drivers/clk/mediatek/clk-mt8173-mfgtop.c
@@ -0,0 +1,243 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2024 Google LLC
+ * Author: Chen-Yu Tsai <wenst@chromium.org>
+ *
+ * Based on driver in downstream ChromeOS v5.15 kernel.
+ *
+ * Copyright (c) 2014 MediaTek Inc.
+ * Author: Chiawen Lee <chiawen.lee@mediatek.com>
+ */
+
+#include <dt-bindings/clock/mt8173-clk.h>
+
+#include <linux/bitfield.h>
+#include <linux/clk.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+
+#include "clk-gate.h"
+#include "clk-mtk.h"
+
+static const struct mtk_gate_regs mfg_cg_regs = {
+ .sta_ofs = 0x0000,
+ .clr_ofs = 0x0008,
+ .set_ofs = 0x0004,
+};
+
+#define GATE_MFG(_id, _name, _parent, _shift, _flags) \
+ GATE_MTK_FLAGS(_id, _name, _parent, &mfg_cg_regs, _shift, &mtk_clk_gate_ops_setclr, _flags)
+
+/* TODO: The block actually has dividers for the core and mem clocks. */
+static const struct mtk_gate mfg_clks[] = {
+ GATE_MFG(CLK_MFG_AXI, "mfg_axi", "axi_mfg_in_sel", 0, CLK_SET_RATE_PARENT),
+ GATE_MFG(CLK_MFG_MEM, "mfg_mem", "mem_mfg_in_sel", 1, CLK_SET_RATE_PARENT),
+ GATE_MFG(CLK_MFG_G3D, "mfg_g3d", "mfg_sel", 2, CLK_SET_RATE_PARENT),
+ GATE_MFG(CLK_MFG_26M, "mfg_26m", "clk26m", 3, 0),
+};
+
+static const struct mtk_clk_desc mfg_desc = {
+ .clks = mfg_clks,
+ .num_clks = ARRAY_SIZE(mfg_clks),
+};
+
+struct mt8173_mfgtop_data {
+ struct clk_hw_onecell_data *clk_data;
+ struct regmap *regmap;
+ struct generic_pm_domain genpd;
+ struct of_phandle_args parent_pd, child_pd;
+ struct clk *clk_26m;
+};
+
+/* Delay count in clock cycles */
+#define MFG_ACTIVE_POWER_CON0 0x24
+ #define RST_B_DELAY_CNT GENMASK(7, 0) /* pwr_rst_b de-assert delay during power-up */
+ #define CLK_EN_DELAY_CNT GENMASK(15, 8) /* CLK_DIS deassert delay during power-up */
+ #define CLK_DIS_DELAY_CNT GENMASK(23, 16) /* CLK_DIS assert delay during power-down */
+ #define FORCE_ABORT BIT(30) /* write 1 to force abort a power event */
+ #define ACTIVE_PWRCTL_EN BIT(31) /* enable ACTIVE_POWER */
+
+#define MFG_ACTIVE_POWER_CON1 0x28
+ #define PWR_ON_S_DELAY_CNT GENMASK(7, 0) /* pwr_on_s assert delay during power-up */
+ #define ISO_DELAY_CNT GENMASK(15, 8) /* ISO assert delay during power-down */
+ #define ISOOFF_DELAY_CNT GENMASK(23, 16) /* ISO de-assert delay during power-up */
+ #define RST__DELAY_CNT GENMASK(31, 24) /* pwr_rsb_b assert delay during power-down */
+
+static int clk_mt8173_mfgtop_power_on(struct generic_pm_domain *domain)
+{
+ struct mt8173_mfgtop_data *data = container_of(domain, struct mt8173_mfgtop_data, genpd);
+
+ /* drives internal power management */
+ clk_prepare_enable(data->clk_26m);
+
+ /* Power on/off delays for various signals */
+ regmap_write(data->regmap, MFG_ACTIVE_POWER_CON0,
+ FIELD_PREP(RST_B_DELAY_CNT, 77) |
+ FIELD_PREP(CLK_EN_DELAY_CNT, 61) |
+ FIELD_PREP(CLK_DIS_DELAY_CNT, 60) |
+ FIELD_PREP(ACTIVE_PWRCTL_EN, 0));
+ regmap_write(data->regmap, MFG_ACTIVE_POWER_CON1,
+ FIELD_PREP(PWR_ON_S_DELAY_CNT, 11) |
+ FIELD_PREP(ISO_DELAY_CNT, 68) |
+ FIELD_PREP(ISOOFF_DELAY_CNT, 69) |
+ FIELD_PREP(RST__DELAY_CNT, 77));
+
+ /* Magic numbers related to core switch sequence and delays */
+ regmap_write(data->regmap, 0xe0, 0x7a710184);
+ regmap_write(data->regmap, 0xe4, 0x835f6856);
+ regmap_write(data->regmap, 0xe8, 0x002b0234);
+ regmap_write(data->regmap, 0xec, 0x80000000);
+ regmap_write(data->regmap, 0xa0, 0x08000000);
+
+ return 0;
+}
+
+static int clk_mt8173_mfgtop_power_off(struct generic_pm_domain *domain)
+{
+ struct mt8173_mfgtop_data *data = container_of(domain, struct mt8173_mfgtop_data, genpd);
+
+ /* Magic numbers related to core switch sequence and delays */
+ regmap_write(data->regmap, 0xec, 0);
+
+ /* drives internal power management */
+ clk_disable_unprepare(data->clk_26m);
+
+ return 0;
+}
+
+static int clk_mt8173_mfgtop_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *node = dev->of_node;
+ struct mt8173_mfgtop_data *data;
+ int ret;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, data);
+
+ data->clk_data = mtk_devm_alloc_clk_data(dev, ARRAY_SIZE(mfg_clks));
+ if (!data->clk_data)
+ return -ENOMEM;
+
+ /* MTK clock gates also uses regmap */
+ data->regmap = device_node_to_regmap(node);
+ if (IS_ERR(data->regmap))
+ return dev_err_probe(dev, PTR_ERR(data->regmap), "Failed to get regmap\n");
+
+ data->child_pd.np = node;
+ data->child_pd.args_count = 0;
+ ret = of_parse_phandle_with_args(node, "power-domains", "#power-domain-cells", 0,
+ &data->parent_pd);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to parse power domain\n");
+
+ devm_pm_runtime_enable(dev);
+ /*
+ * Do a pm_runtime_resume_and_get() to workaround a possible
+ * deadlock between clk_register() and the genpd framework.
+ */
+ ret = pm_runtime_resume_and_get(dev);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to runtime resume device\n");
+ goto put_of_node;
+ }
+
+ ret = mtk_clk_register_gates(dev, node, mfg_clks, ARRAY_SIZE(mfg_clks),
+ data->clk_data);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to register clock gates\n");
+ goto put_pm_runtime;
+ }
+
+ data->clk_26m = clk_hw_get_clk(data->clk_data->hws[CLK_MFG_26M], "26m");
+ if (IS_ERR(data->clk_26m)) {
+ dev_err_probe(dev, PTR_ERR(data->clk_26m), "Failed to get 26 MHz clock\n");
+ goto unregister_clks;
+ }
+
+ ret = of_clk_add_hw_provider(node, of_clk_hw_onecell_get, data->clk_data);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to add clk OF provider\n");
+ goto put_26m_clk;
+ }
+
+ data->genpd.name = "mfg-top";
+ data->genpd.power_on = clk_mt8173_mfgtop_power_on;
+ data->genpd.power_off = clk_mt8173_mfgtop_power_off;
+ ret = pm_genpd_init(&data->genpd, NULL, true);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to add power domain\n");
+ goto del_clk_provider;
+ }
+
+ ret = of_genpd_add_provider_simple(node, &data->genpd);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to add power domain OF provider\n");
+ goto remove_pd;
+ }
+
+ ret = of_genpd_add_subdomain(&data->parent_pd, &data->child_pd);
+ if (ret) {
+ dev_err_probe(dev, ret, "Failed to link PM domains\n");
+ goto del_pd_provider;
+ }
+
+ pm_runtime_put(dev);
+ return 0;
+
+del_pd_provider:
+ of_genpd_del_provider(node);
+remove_pd:
+ pm_genpd_remove(&data->genpd);
+del_clk_provider:
+ of_clk_del_provider(node);
+put_26m_clk:
+ clk_put(data->clk_26m);
+unregister_clks:
+ mtk_clk_unregister_gates(mfg_clks, ARRAY_SIZE(mfg_clks), data->clk_data);
+put_pm_runtime:
+ pm_runtime_put(dev);
+put_of_node:
+ of_node_put(data->parent_pd.np);
+ return ret;
+}
+
+static void clk_mt8173_mfgtop_remove(struct platform_device *pdev)
+{
+ struct mt8173_mfgtop_data *data = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+
+ of_genpd_remove_subdomain(&data->parent_pd, &data->child_pd);
+ of_genpd_del_provider(node);
+ pm_genpd_remove(&data->genpd);
+ of_clk_del_provider(node);
+ clk_put(data->clk_26m);
+ mtk_clk_unregister_gates(mfg_clks, ARRAY_SIZE(mfg_clks), data->clk_data);
+}
+
+static const struct of_device_id of_match_clk_mt8173_mfgtop[] = {
+ { .compatible = "mediatek,mt8173-mfgtop", .data = &mfg_desc },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, of_match_clk_mt8173_mfgtop);
+
+static struct platform_driver clk_mt8173_mfgtop_drv = {
+ .probe = clk_mt8173_mfgtop_probe,
+ .remove = clk_mt8173_mfgtop_remove,
+ .driver = {
+ .name = "clk-mt8173-mfgtop",
+ .of_match_table = of_match_clk_mt8173_mfgtop,
+ },
+};
+module_platform_driver(clk_mt8173_mfgtop_drv);
+
+MODULE_DESCRIPTION("MediaTek MT8173 mfgtop clock driver");
+MODULE_LICENSE("GPL");
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH v2 3/5] dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPU
From: Chen-Yu Tsai @ 2026-03-25 7:19 UTC (permalink / raw)
To: Stephen Boyd, Matthias Brugger, AngeloGioacchino Del Regno,
Frank Binns, Matt Coster, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann
Cc: Icenowy Zheng, Icenowy Zheng, Chen-Yu Tsai, David Airlie,
Simona Vetter, linux-clk, devicetree, linux-mediatek, dri-devel,
linux-arm-kernel, linux-kernel, Conor Dooley
In-Reply-To: <20260325071951.544031-1-wenst@chromium.org>
The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is one
of the Series6XT GPUs, another sub-family of the Rogue family.
This was part of the very first few versions of the PowerVR submission,
but was later dropped.
[1] https://lore.kernel.org/dri-devel/6eeccb26e09aad67fb30ffcd523c793a43c79c2a.camel@imgtec.com/
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes since v1:
- Adapted to recent changes, now only adds SoC-specific compatible string
---
Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
index a1f54dbae3f3..53131cd4cc2a 100644
--- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
+++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
@@ -15,6 +15,7 @@ properties:
oneOf:
- items:
- enum:
+ - mediatek,mt8173-gpu
- renesas,r8a7796-gpu
- renesas,r8a77961-gpu
- const: img,img-gx6250
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH v2 4/5] arm64: dts: mediatek: mt8173: Fix MFG_ASYNC power domain clock
From: Chen-Yu Tsai @ 2026-03-25 7:19 UTC (permalink / raw)
To: Stephen Boyd, Matthias Brugger, AngeloGioacchino Del Regno,
Frank Binns, Matt Coster, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann
Cc: Icenowy Zheng, Icenowy Zheng, Chen-Yu Tsai, David Airlie,
Simona Vetter, linux-clk, devicetree, linux-mediatek, dri-devel,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260325071951.544031-1-wenst@chromium.org>
The MFG_ASYNC domain, which is likely associated to the whole MFG block,
currently specifies clk26m as its domain clock. This is bogus, since the
clock is an external crystal with no controls. Also, the MFG block has
a independent CLK_TOP_AXI_MFG_IN_SEL clock, which according to the block
diagram, gates access to the hardware registers. Having this one as the
domain clock makes much more sense. This also fixes access to the MFGTOP
registers.
Change the MFG_ASYNC domain clock to CLK_TOP_AXI_MFG_IN_SEL.
Fixes: 8b6562644df9 ("arm64: dts: mediatek: Add mt8173 power domain controller")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 78c2ccd5be13..556e806b7787 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -505,7 +505,7 @@ power-domain@MT8173_POWER_DOMAIN_USB {
};
mfg_async: power-domain@MT8173_POWER_DOMAIN_MFG_ASYNC {
reg = <MT8173_POWER_DOMAIN_MFG_ASYNC>;
- clocks = <&clk26m>;
+ clocks = <&topckgen CLK_TOP_AXI_MFG_IN_SEL>;
clock-names = "mfg";
#address-cells = <1>;
#size-cells = <0>;
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* [PATCH v2 5/5] arm64: dts: mediatek: mt8173: Add GPU device nodes
From: Chen-Yu Tsai @ 2026-03-25 7:19 UTC (permalink / raw)
To: Stephen Boyd, Matthias Brugger, AngeloGioacchino Del Regno,
Frank Binns, Matt Coster, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann
Cc: Icenowy Zheng, Icenowy Zheng, Chen-Yu Tsai, David Airlie,
Simona Vetter, linux-clk, devicetree, linux-mediatek, dri-devel,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260325071951.544031-1-wenst@chromium.org>
The MediaTek MT8173 comes with a PowerVR Rogue GX6250, which is part
of the Series6XT, another variation of the Rogue family of GPUs.
On top of the GPU is a glue layer that handles some clock and power
signals.
Add device nodes for both. While there is supposed to be two different
power domains to the GPU, MediaTek does not have any information on how
this is integrated internally. Assign the same GPU power domain to both.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 31 ++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 556e806b7787..169ba4fd183e 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -1002,6 +1002,37 @@ u2port1: usb-phy@11291000 {
};
};
+ gpu: gpu@13000000 {
+ compatible = "mediatek,mt8173-gpu", "img,img-gx6250",
+ "img,img-rogue";
+ reg = <0 0x13000000 0 0x10000>;
+ interrupts = <GIC_SPI 217 IRQ_TYPE_LEVEL_LOW>;
+ clocks = <&mfgtop CLK_MFG_G3D>,
+ <&mfgtop CLK_MFG_MEM>,
+ <&mfgtop CLK_MFG_AXI>;
+ clock-names = "core", "mem", "sys";
+ /*
+ * Binding and GPU core HW have two power domain
+ * inputs, but MediaTek does not have information
+ * on how this is done internally.
+ */
+ power-domains = <&mfgtop>, <&mfgtop>;
+ power-domain-names = "a", "b";
+ };
+
+ mfgtop: clock-controller@13fff000 {
+ compatible = "mediatek,mt8173-mfgtop";
+ reg = <0 0x13fff000 0 0x1000>;
+ clocks = <&topckgen CLK_TOP_AXI_MFG_IN_SEL>,
+ <&topckgen CLK_TOP_MEM_MFG_IN_SEL>,
+ <&topckgen CLK_TOP_MFG_SEL>,
+ <&clk26m>;
+ clock-names = "sys", "mem", "core", "clk26m";
+ power-domains = <&spm MT8173_POWER_DOMAIN_MFG>;
+ #clock-cells = <1>;
+ #power-domain-cells = <0>;
+ };
+
mmsys: syscon@14000000 {
compatible = "mediatek,mt8173-mmsys", "syscon";
reg = <0 0x14000000 0 0x1000>;
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
* Re: [PATCH 0/3] KVM: arm64: selftests: Basic nested guest support
From: Itaru Kitayama @ 2026-03-25 8:00 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: kvm, linux-kselftest, linux-arm-kernel, kvmarm, linux-kernel,
Paolo Bonzini, Shuah Khan, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <20260325003620.2214766-1-weilin.chang@arm.com>
Hi Wei Lin,
On Wed, Mar 25, 2026 at 12:36:17AM +0000, Wei-Lin Chang wrote:
> Hi,
>
> This series adds basic support for running nested guests (L2) in
> kselftest. The first patch adds library functions. While designing the
> APIs for userspace, I referenced Joey's approach for kvm-unit-tests [1].
> In summary, four preparatory functions are provided for userspace to
> set up state to run an L2 in EL1:
>
> - prepare_l2_stack() <- sets up stack for L2
> - prepare_hyp_state() <- sets up vEL2 registers
> - prepare_eret_destination() <- userspace passes a function pointer
> for L2 to run
> - prepare_nested_sync_handler() <- sets up hvc handler in order to
> regain control after L2's hvc
>
> After calling those functions, userspace can vcpu_run(), and when
> run_l2() is called within the guest, the supplied function will be run
> in L2, with the control flow managed by the library code in nested.c and
> nested_asm.S. After running the L2 function, run_l2() will automatically
> return. Note that the L2 function supplied by the user does not have to
> call hvc.
>
> Patch 2 demonstrates usage of the APIs introduced above, with a simple
> L1 -> L2 -> L1 sequence, with an empty L2 function.
>
> Patch 3 enhances the library functions by setting up L2 -> L1 stage-2
> translation. Currently the translation is simple, with start level 0, 4
> levels, 4KB granules, normal cachable, 48-bit IA, 40-bit OA.
>
> [1]: https://lore.kernel.org/kvmarm/20260306142656.2775185-1-joey.gouly@arm.com/
Look like this selftest assumes nested guest's MMU is disabled (L2 IPA
to L1 IPA to PA), but I couldn's find the explicit SCTLR.M bit operation in this
series, how do you make sure it is always off?
Thanks,
Itaru.
>
> Wei-Lin Chang (3):
> KVM: arm64: selftests: Add library functions for NV
> KVM: arm64: sefltests: Add basic NV selftest
> KVM: arm64: selftests: Enable stage-2 in NV preparation functions
>
> tools/testing/selftests/kvm/Makefile.kvm | 3 +
> .../selftests/kvm/arm64/hello_nested.c | 65 ++++++++
> .../selftests/kvm/include/arm64/nested.h | 25 +++
> .../selftests/kvm/include/arm64/processor.h | 9 +
> .../testing/selftests/kvm/lib/arm64/nested.c | 154 ++++++++++++++++++
> .../selftests/kvm/lib/arm64/nested_asm.S | 35 ++++
> 6 files changed, 291 insertions(+)
> create mode 100644 tools/testing/selftests/kvm/arm64/hello_nested.c
> create mode 100644 tools/testing/selftests/kvm/include/arm64/nested.h
> create mode 100644 tools/testing/selftests/kvm/lib/arm64/nested.c
> create mode 100644 tools/testing/selftests/kvm/lib/arm64/nested_asm.S
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2] iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux
From: Christofer Jonason @ 2026-03-25 8:04 UTC (permalink / raw)
To: Michal Simek, Jonathan Cameron, Salih Erim, O'Griofa, Conall
Cc: lars@metafoo.de, dlechner@baylibre.com, nuno.sa@analog.com,
andy@kernel.org, Victor Jonsson, linux-iio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <1166aeef-0c93-408d-b265-9037f2840074@amd.com>
Gentle ping on this.
The fix aligns postdisable with preenable, which already uses
xadc_get_seq_mode() to select simultaneous mode for dual external
mux configurations.
Happy to answer any questions.
Thanks,
Christofer
________________________________________
From: Michal Simek <michal.simek@amd.com>
Sent: Tuesday, March 10, 2026 8:42 AM
To: Jonathan Cameron <jic23@kernel.org>; Christofer Jonason <christofer.jonason@guidelinegeo.com>; Salih Erim <salih.erim@amd.com>; O'Griofa, Conall <conall.ogriofa@amd.com>
Cc: lars@metafoo.de <lars@metafoo.de>; dlechner@baylibre.com <dlechner@baylibre.com>; nuno.sa@analog.com <nuno.sa@analog.com>; andy@kernel.org <andy@kernel.org>; Victor Jonsson <victor.jonsson@guidelinegeo.com>; linux-iio@vger.kernel.org <linux-iio@vger.kernel.org>; linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>; linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; stable@vger.kernel.org <stable@vger.kernel.org>
Subject: Re: [PATCH v2] iio: adc: xilinx-xadc: Fix sequencer mode in postdisable for dual mux
+Salih, Conall,
On 3/7/26 13:41, Jonathan Cameron wrote:
> On Wed, 4 Mar 2026 10:07:27 +0100
> Christofer Jonason <christofer.jonason@guidelinegeo.com> wrote:
>
>> xadc_postdisable() unconditionally sets the sequencer to continuous
>> mode. For dual external multiplexer configurations this is incorrect:
>> simultaneous sampling mode is required so that ADC-A samples through
>> the mux on VAUX[0-7] while ADC-B simultaneously samples through the
>> mux on VAUX[8-15]. In continuous mode only ADC-A is active, so
>> VAUX[8-15] channels return incorrect data.
>>
>> Since postdisable is also called from xadc_probe() to set the initial
>> idle state, the wrong sequencer mode is active from the moment the
>> driver loads.
>>
>> The preenable path already uses xadc_get_seq_mode() which returns
>> SIMULTANEOUS for dual mux. Fix postdisable to do the same.
>>
>> Fixes: bdc8cda1d010 ("iio:adc: Add Xilinx XADC driver")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Christofer Jonason <christofer.jonason@guidelinegeo.com>
>
> I'll leave this on list for a little longer as I'd really like a confirmation
> of this one from the AMD Xilinx folk.
Salih/Conall: Please look at this patch and provide your comment or tag.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v2 0/5] powervr: MT8173 GPU support
From: Icenowy Zheng @ 2026-03-25 8:03 UTC (permalink / raw)
To: Chen-Yu Tsai, Stephen Boyd, Matthias Brugger,
AngeloGioacchino Del Regno, Frank Binns, Matt Coster,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann
Cc: David Airlie, Simona Vetter, linux-clk, devicetree,
linux-mediatek, dri-devel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260325071951.544031-1-wenst@chromium.org>
在 2026-03-25三的 15:19 +0800，Chen-Yu Tsai写道：
> Hi everyone,
>
> This is v2 of my MT8173 PowerVR GPU support series.
>
> Changes since v1:
> - Adapted to changed DT bindings
> - Dropped driver change
> - Use same power domain for "a" and "b" GPU power domains
>
> This update was requested by Icenowy.
>
>
> This series enables the PowerVR GPU found in the MT8173 SoC, found in
> some Chromebooks.
>
> This version is different from the initial powervr driver submission
> [1]
> in that it splits out the GPU glue layer support out of the powervr
> driver and into a separate clock and power domain driver. The glue
> code
> is otherwise the same, and also the same as found in the ChromeOS
> kernels, with some extra comments and macro names added where
> possible.
>
> Patch 1 adds a binding for the glue layer, called mfgtop. The glue
> layer
> contains clock and power controls for the GPU.
>
> Patch 2 adds a driver for the glue layer.
>
> Patch 3 adds an entry for the MT8173 GPU and 6XT series to the
> PowerVR
> binding.
>
> Patch 4 adds an entry for the PowerVR 6XT series GPU to the driver.
>
> Patch 5 corrects the clock for the GPU (called MFG) power domain.
>
> Patch 6 adds device nodes for the GPU and glue layer to the MT8173
> dtsi
> file.
>
> Patch 2 and 6 depend on patch 1 to build. I suppose some common
> immutable tree would be needed from the MediaTek maintainers.
>
> The kernel driver successfully probes the hardware and loads the
> "rogue_4.40.2.51_v1.fw" firmware provided by Imagination Technologies
> [2].
> Userspace was tested with Mesa 24.0.8 from Debian Trixie rebuilt with
> the powervr vulkan driver enabled. `vulkaninfo` gives some
> information
> about the GPU (attached at the end), but running the `triangle`
> example
> from the Sascha Willems demos [3] with -DUSE_D2D_WSI=ON as
> recommended [4]
> failed with:
>
> Can't find a display and a display mode!
I think when using D2D the demos want width and height to be explicitly
specified, otherwise it seems to hardcode 1280x720.
If you're using an elm, could you try to add `-w 1920 -h 1080` or for
hana `-w 1366 -h 768` ?
Thanks
Icenowy
>
> Same program worked correctly on a BeaglePlay and displayed a color
> gradient triangle. Not sure what went wrong here.
>
> Anyway, please have a look and test.
>
>
> Thanks
> ChenYu
>
> [1]
> https://lore.kernel.org/dri-devel/20220815165156.118212-2-sarah.walker@imgtec.com/
> [2]
> https://gitlab.freedesktop.org/imagination/linux-firmware/-/tree/powervr
> [3] https://github.com/SaschaWillems/Vulkan
> [4]
> https://lore.kernel.org/dri-devel/f2b2671e-5acc-4dec-9c2e-3c9cd2e1f19e@imgtec.com/
>
> Chen-Yu Tsai (5):
> dt-bindings: clock: mediatek: Add mt8173 mfgtop
> clk: mediatek: Add mt8173-mfgtop driver
> dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPU
> arm64: dts: mediatek: mt8173: Fix MFG_ASYNC power domain clock
> arm64: dts: mediatek: mt8173: Add GPU device nodes
>
> .../clock/mediatek,mt8173-mfgtop.yaml | 70 +++++
> .../bindings/gpu/img,powervr-rogue.yaml | 1 +
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 33 ++-
> drivers/clk/mediatek/Kconfig | 9 +
> drivers/clk/mediatek/Makefile | 1 +
> drivers/clk/mediatek/clk-mt8173-mfgtop.c | 243
> ++++++++++++++++++
> include/dt-bindings/clock/mt8173-clk.h | 7 +
> 7 files changed, 363 insertions(+), 1 deletion(-)
> create mode 100644
> Documentation/devicetree/bindings/clock/mediatek,mt8173-mfgtop.yaml
> create mode 100644 drivers/clk/mediatek/clk-mt8173-mfgtop.c
^ permalink raw reply
* Re: [PATCH v2 3/9] media: rockchip: rkcif: add support for rk3588 vicap mipi capture
From: Michael Riesch @ 2026-03-25 8:04 UTC (permalink / raw)
To: Mehdi Djait
Cc: Laurent Pinchart, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Jagan Teki,
Кузнецов Михаил,
Sebastian Reichel, Nicolas Dufresne, Collabora Kernel Team,
Sakari Ailus, linux-media, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <ablWdjlrPLGhDJi4@mdjait-mobl>
Hi Mehdi,
On 3/17/26 14:28, Mehdi Djait wrote:
> Hi Michael,
>
> On Tue, Mar 17, 2026 at 02:21:20PM +0100, Michael Riesch wrote:
>> Hi Mehdi,
>>
>> On 3/17/26 14:08, Mehdi Djait wrote:
>>> Hi Michael,
>>>
>>> Thank you for this nice patch!
>>>
>>> On Tue, Mar 17, 2026 at 10:32:21AM +0100, Michael Riesch via B4 Relay wrote:
>>>> From: Michael Riesch <michael.riesch@collabora.com>
>>>>
>>>> The RK3588 Video Capture (VICAP) unit features a Digital Video Port
>>>> (DVP) and six MIPI CSI-2 capture interfaces. Add initial support
>>>> for this variant to the rkcif driver and enable the MIPI CSI-2
>>>> capture interfaces.
>>>>
>>>> Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
>>>
>>> [...]
>>>
>>>> static inline unsigned int rkcif_mipi_get_reg(struct rkcif_interface *interface,
>>>> unsigned int index)
>>>> {
>>>> @@ -631,6 +765,8 @@ static int rkcif_mipi_start_streaming(struct rkcif_stream *stream)
>>>> rkcif_mipi_stream_write(stream, RKCIF_MIPI_CTRL1, ctrl1);
>>>> rkcif_mipi_stream_write(stream, RKCIF_MIPI_CTRL0, ctrl0);
>>>>
>>>> + rkcif_mipi_write(interface, RKCIF_MIPI_CTRL, RKCIF_MIPI_CTRL_CAP_EN);
>>>> +
>>>
>>> while this is the correct solution for rk3588, for the rk3568 vicap this
>>> will write 0x1 to the VICAP_MIPI_CTRL : 0x00A0 which will enable the water line.
>>
>> nice catch ;-) However, the TRM (at least my version) claims that this
>> bit has a reset value of 0x1, so the bit in question should be already
>> set in the first place. Thus I decided to *not* make variant specific
>> code paths.
>
> Yes, the reset value is indeed 0x1
>
>>
>> Do you see problems in your setup?
>>
>
> No problems, it works as expected, I was just confused to see the
> mipi capture enable added with this rk3588 patch and not before.
>
> I just find it a bit confusing but if a nicer solution is too much
> hassle we can leave it like this.
I agree that this is (while correct) not the nicest way. I am still
bringing up the remaining features of the RK3588 VICAP (MUX + TOISP +
SCALER) and it looks like I need to do some refactoring anyway to
support them. When I do that, I shall rewrite this part. For the time
being it would be great to have this merged in order to provide initial
mainline support for this unit.
Best regards,
Michael
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: imx-card: Add dsp_a DAI format
From: Krzysztof Kozlowski @ 2026-03-25 8:06 UTC (permalink / raw)
To: Chancel Liu
Cc: lgirdwood@gmail.com, broonie@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, Frank Li,
shengjiu.wang@gmail.com, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-sound@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <AM9PR04MB83531E00C21A5A2314A38F9AE349A@AM9PR04MB8353.eurprd04.prod.outlook.com>
On 25/03/2026 08:54, Chancel Liu wrote:
>>> The imx-card machine driver originally supported only codecs operating
>>> in i2s or dsp_b formats. This machine driver can support CS42448 codec
>>> and this codec typically uses dsp_a for its TDM interface. Therefore,
>>
>> And what about other formats, which was asked last time?
>>
>
> The imx-card machine driver currently implements support only for
> codecs with i2s and dsp_b format. The newly added CS42448 codec
> requires dsp_a and that is why this patch adds dsp_a only. No other
> formats are used or supported by the existing hardware covered by this
First sentence says about driver, here you speak about hardware, so
feels like you are mixing these.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 2/5] drm/meson: use default case for unsupported DSI pixel formats
From: Neil Armstrong @ 2026-03-25 8:08 UTC (permalink / raw)
To: Alexander Koskovich, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Jeffrey Hugo, Martin Blumenstingl
Cc: dri-devel, linux-kernel, linux-arm-msm, freedreno, linux-amlogic,
linux-arm-kernel
In-Reply-To: <20260324-dsi-rgb101010-support-v5-2-ff6afc904115@pm.me>
On 3/24/26 12:48, Alexander Koskovich wrote:
> Use default instead of listing unsupported formats explicitly, so the
> switch statements don't need updating each time a new pixel format is
> added.
>
> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
> index 66c73c512b0e..4412bd678108 100644
> --- a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
> @@ -119,8 +119,7 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
> dpi_data_format = DPI_COLOR_18BIT_CFG_2;
> venc_data_width = VENC_IN_COLOR_18B;
> break;
> - case MIPI_DSI_FMT_RGB666_PACKED:
> - case MIPI_DSI_FMT_RGB565:
> + default:
> return -EINVAL;
> }
>
> @@ -232,8 +231,7 @@ static int meson_dw_mipi_dsi_host_attach(void *priv_data,
> break;
> case MIPI_DSI_FMT_RGB666:
> break;
> - case MIPI_DSI_FMT_RGB666_PACKED:
> - case MIPI_DSI_FMT_RGB565:
> + default:
> dev_err(mipi_dsi->dev, "invalid pixel format %d\n", device->format);
> return -EINVAL;
> }
>
Feel free to merge it in msm-next or other drm branch:
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Thanks,
Neil
^ permalink raw reply
* Re: [PATCH v2 0/5] powervr: MT8173 GPU support
From: Chen-Yu Tsai @ 2026-03-25 8:08 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Stephen Boyd, Matthias Brugger, AngeloGioacchino Del Regno,
Frank Binns, Matt Coster, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, linux-clk,
devicetree, linux-mediatek, dri-devel, linux-arm-kernel,
linux-kernel
In-Reply-To: <93c1d325461cc0ffad890d64870de680506338c4.camel@icenowy.me>
On Wed, Mar 25, 2026 at 4:04 PM Icenowy Zheng <uwu@icenowy.me> wrote:
>
> 在 2026-03-25三的 15:19 +0800，Chen-Yu Tsai写道：
> > Hi everyone,
> >
> > This is v2 of my MT8173 PowerVR GPU support series.
> >
> > Changes since v1:
> > - Adapted to changed DT bindings
> > - Dropped driver change
> > - Use same power domain for "a" and "b" GPU power domains
> >
> > This update was requested by Icenowy.
> >
> >
> > This series enables the PowerVR GPU found in the MT8173 SoC, found in
> > some Chromebooks.
> >
> > This version is different from the initial powervr driver submission
> > [1]
> > in that it splits out the GPU glue layer support out of the powervr
> > driver and into a separate clock and power domain driver. The glue
> > code
> > is otherwise the same, and also the same as found in the ChromeOS
> > kernels, with some extra comments and macro names added where
> > possible.
> >
> > Patch 1 adds a binding for the glue layer, called mfgtop. The glue
> > layer
> > contains clock and power controls for the GPU.
> >
> > Patch 2 adds a driver for the glue layer.
> >
> > Patch 3 adds an entry for the MT8173 GPU and 6XT series to the
> > PowerVR
> > binding.
> >
> > Patch 4 adds an entry for the PowerVR 6XT series GPU to the driver.
> >
> > Patch 5 corrects the clock for the GPU (called MFG) power domain.
> >
> > Patch 6 adds device nodes for the GPU and glue layer to the MT8173
> > dtsi
> > file.
> >
> > Patch 2 and 6 depend on patch 1 to build. I suppose some common
> > immutable tree would be needed from the MediaTek maintainers.
> >
> > The kernel driver successfully probes the hardware and loads the
> > "rogue_4.40.2.51_v1.fw" firmware provided by Imagination Technologies
> > [2].
> > Userspace was tested with Mesa 24.0.8 from Debian Trixie rebuilt with
> > the powervr vulkan driver enabled. `vulkaninfo` gives some
> > information
> > about the GPU (attached at the end), but running the `triangle`
> > example
> > from the Sascha Willems demos [3] with -DUSE_D2D_WSI=ON as
> > recommended [4]
> > failed with:
> >
> > Can't find a display and a display mode!
>
> I think when using D2D the demos want width and height to be explicitly
> specified, otherwise it seems to hardcode 1280x720.
>
> If you're using an elm, could you try to add `-w 1920 -h 1080` or for
> hana `-w 1366 -h 768` ?
I only did the basic `vulkaninfo` test this time around. To do anything
interesting probably requires the Mesa 26.1 release.
PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 \
vkmark --winsys kms -D b81f54f8568deb0fb70a6a1ed845b65d
just reports "Error: Device specified by uuid is not available"
This is with Mesa 26.0.2 packages from Debian testing. At least now
have the powervr vulkan driver enabled by default, so I don't have
to rebuild the packages again.
ChenYu
> Thanks
> Icenowy
>
> >
> > Same program worked correctly on a BeaglePlay and displayed a color
> > gradient triangle. Not sure what went wrong here.
> >
> > Anyway, please have a look and test.
> >
> >
> > Thanks
> > ChenYu
> >
> > [1]
> > https://lore.kernel.org/dri-devel/20220815165156.118212-2-sarah.walker@imgtec.com/
> > [2]
> > https://gitlab.freedesktop.org/imagination/linux-firmware/-/tree/powervr
> > [3] https://github.com/SaschaWillems/Vulkan
> > [4]
> > https://lore.kernel.org/dri-devel/f2b2671e-5acc-4dec-9c2e-3c9cd2e1f19e@imgtec.com/
> >
> > Chen-Yu Tsai (5):
> > dt-bindings: clock: mediatek: Add mt8173 mfgtop
> > clk: mediatek: Add mt8173-mfgtop driver
> > dt-bindings: gpu: powervr-rogue: Add MediaTek MT8173 GPU
> > arm64: dts: mediatek: mt8173: Fix MFG_ASYNC power domain clock
> > arm64: dts: mediatek: mt8173: Add GPU device nodes
> >
> > .../clock/mediatek,mt8173-mfgtop.yaml | 70 +++++
> > .../bindings/gpu/img,powervr-rogue.yaml | 1 +
> > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 33 ++-
> > drivers/clk/mediatek/Kconfig | 9 +
> > drivers/clk/mediatek/Makefile | 1 +
> > drivers/clk/mediatek/clk-mt8173-mfgtop.c | 243
> > ++++++++++++++++++
> > include/dt-bindings/clock/mt8173-clk.h | 7 +
> > 7 files changed, 363 insertions(+), 1 deletion(-)
> > create mode 100644
> > Documentation/devicetree/bindings/clock/mediatek,mt8173-mfgtop.yaml
> > create mode 100644 drivers/clk/mediatek/clk-mt8173-mfgtop.c
^ permalink raw reply
* RE: [PATCH v27 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and transfer-mode properties
From: Ryan Chen @ 2026-03-25 8:11 UTC (permalink / raw)
To: Jeremy Kerr, andriy.shevchenko@linux.intel.com, Andi Shyti,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Benjamin Herrenschmidt, Rayn Chen, Philipp Zabel
Cc: 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: <405f6b1b4081ffb379a21bcdb5d2a8e81d2e2e3e.camel@codeconstruct.com.au>
Hello Jeremy,
Thanks the review.
> Subject: Re: [PATCH v27 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
> and transfer-mode properties
>
> Hi Ryan,
>
> > The AST2600 I2C controller supports three transfer modes (byte,
> > buffer, DMA). Add "aspeed,transfer-mode" so DT can select the
> > preferred transfer method per controller instance.
>
> This patch does not add an aspeed,transfer-mode property.
Will update use aspeed,enable-dma
>
> > Also add the "aspeed,global-regs"
> > phandle to reference the AST2600 global registers syscon/regmap used
> > by the controller.
> >
> > These properties apply only to the AST2600 binding and are not part of
> > the legacy binding, which uses a mixed controller/target register
> > layout and does not have the split register blocks or these new
> > configuration registers. Legacy DTs remain unchanged.
> >
> > Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
> > ---
> > Changes in v27:
> > - change aspeed,transfer-mode to aspeed,enable-dma.
>
> What about all the previous changes?
Will update
Remove aspeed,transfer-mode instead aspeed,enable-dma
>
> > ---
> > .../devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml | 17
> > +++++++++++++++++
> > 1 file changed, 17 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> > b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> > index de2c359037da..38da6fc6424f 100644
> > --- a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> > +++ b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> > @@ -37,6 +37,21 @@ properties:
> > resets:
> > maxItems: 1
> >
> > + aspeed,enable-dma:
> > + type: boolean
> > + description: |
> > + I2C bus enable dma mode transfer.
> > +
> > + ASPEED ast2600 platform equipped with 16 I2C controllers that
> > +share a
> > + single DMA engine. DTS files can specify the data transfer mode
> > +to/from
> > + the device, either DMA or programmed I/O.
>
> As we had discussed: this does not define the transfer mode, only whether
> DMA is available to the peripheral.
>
> Why mention the 16 i2c controllers here?
>
> Please keep this description simple and relevant to the specific purpose of the
> property.
Will update with following.
description: Enable DMA for transfers on this I2C bus.
>
> > +
> > + aspeed,global-regs:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description:
> > + Phandle reference to the i2c global syscon node, containing the
> > + SoC-common i2c register set.
> > +
> > required:
> > - reg
> > - compatible
> > @@ -59,4 +74,6 @@ examples:
> > resets = <&syscon ASPEED_RESET_I2C>;
> > clock-frequency = <100000>;
> > interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
> > + aspeed,global-regs = <&i2c_global>;
> > + aspeed,transfer-mode = "buffer";
>
> This example does not match the binding.
Will remove aspeed,transfer-mode = "buffer";
Add with aspeed,enable-dma
>
> Cheers,
>
>
> Jeremy
^ permalink raw reply
* Re: [PATCH v4 0/6] porting pq compnent for MT8196
From: Krzysztof Kozlowski @ 2026-03-25 8:17 UTC (permalink / raw)
To: Jay Liu
Cc: Chun-Kuang Hu, Philipp Zabel, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, dri-devel, linux-mediatek, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260324125315.4715-1-jay.liu@mediatek.com>
On Tue, Mar 24, 2026 at 08:51:57PM +0800, Jay Liu wrote:
> Change in v4:
> - Address coding style comments for disp-tdshp binding.
Coding style? Why so vague? So does that mean you ignored all important
changes but did the "style" things?
> - Rebase ccorr driver patch on top of latest linux-next to fix conficts.
Where is the rest of the changeglog?
Why aren't you using b4 to provide also lore links and solve above
problem?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 4/6] dt-bindings: display: mediatek: disp-tdshp: Add support for MT8196
From: Krzysztof Kozlowski @ 2026-03-25 8:18 UTC (permalink / raw)
To: Jay Liu
Cc: Chun-Kuang Hu, Philipp Zabel, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, dri-devel, linux-mediatek, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260324125315.4715-5-jay.liu@mediatek.com>
On Tue, Mar 24, 2026 at 08:52:01PM +0800, Jay Liu wrote:
> Add disp-tdshp hardware description for MediaTek MT8196 SoC
>
> Signed-off-by: Jay Liu <jay.liu@mediatek.com>
> ---
> .../display/mediatek/mediatek,disp-tdshp.yaml | 46 +++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,disp-tdshp.yaml
I don't see improvements.
Considering how vague your changelog is and you only implemented coding
style, not review comments, then NAK.
Implement everything I asked for.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Maxime Ripard @ 2026-03-25 8:24 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Nicolas Frattaroli, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acLrv5hLyNss-Px5@intel.com>
[-- Attachment #1: Type: text/plain, Size: 3633 bytes --]
On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > +enum drm_connector_color_format {
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > + * helpers should pick a suitable color format. All implementations of a
> > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > + * semantics.
> > > > + *
> > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > + * YCbCr 4:2:0.
> > > > + *
> > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > + * format selection picks the first chain of bridge formats that works,
> > > > + * as has already been the case before the introduction of the "color
> > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > + * bus output formats by preference, or agree on a unified auto format
> > > > + * selection logic that's implemented in a common state helper (like
> > > > + * how HDMI does it).
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > +
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > +
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > + * not subsampled)
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > +
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > + * with horizontal subsampling)
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > +
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > + * with horizontal and vertical subsampling)
> > > > + */
> > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > >
> > > Seems like this should document what the quantization range
> > > should be for each format.
> > >
> >
> > I don't think so? If you want per-component bit depth values,
> > DRM_FORMAT_* defines would be the appropriate values to use. This
> > enum is more abstract than that, and is there to communicate
> > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > by other properties.
> >
> > If you mean the factor used for subsampling, then that'd only be
> > relevant if YCBCR410 was supported where one chroma plane isn't
> > halved but quartered in resolution. I suspect 4:1:0 will never
> > be added; no digital display protocol standard supports it to my
> > knowledge, and hopefully none ever will.
>
> No, I mean the quantization range (16-235 vs. 0-255 etc).
>
> The i915 behaviour is that YCbCr is always limited range,
> RGB can either be full or limited range depending on the
> "Broadcast RGB" property and other related factors.
So far the HDMI state has both the format and quantization range as
different fields. I'm not sure we need to document the range in the
format field, maybe only mention it's not part of the format but has a
field of its own?
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: arm: mediatek: add mt8173-hana rev2
From: Icenowy Zheng @ 2026-03-25 8:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Mateusz Koza, Frank Wunderlich, Chen-Yu Tsai, Gary Bisson,
Cristian Cozzolino, Jianeng Ceng, Max Shevchenko, Sean Wang,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
Icenowy Zheng, Icenowy Zheng, Conor Dooley
My Lenovo Flex 11 Chromebook contains a board with revision ID 2.
Add rev2 to the compatible list of base hana DTB to allow depthcharge to
match the DTB.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes in v2:
- Added Conor's A-b.
- Changed mailbox to ISCAS one.
Documentation/devicetree/bindings/arm/mediatek.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
index 382d0eb4d0af6..2894c8a16c78c 100644
--- a/Documentation/devicetree/bindings/arm/mediatek.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
@@ -148,6 +148,7 @@ properties:
- const: google,hana-rev5
- const: google,hana-rev4
- const: google,hana-rev3
+ - const: google,hana-rev2
- const: google,hana
- const: mediatek,mt8173
- description: Google Hana rev7 (Poin2 Chromebook 11C)
--
2.52.0
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: mediatek: mt8173: add hana revision 2
From: Icenowy Zheng @ 2026-03-25 8:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Mateusz Koza, Frank Wunderlich, Chen-Yu Tsai, Gary Bisson,
Cristian Cozzolino, Jianeng Ceng, Max Shevchenko, Sean Wang,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
Icenowy Zheng, Icenowy Zheng
In-Reply-To: <20260325082546.1572405-1-zhengxingda@iscas.ac.cn>
The current mt8173-elm-hana.dts file only contains compatible strings
for revision 3~6, makes boards with revision 0~2 to fail to match a
revision-specific DTS and may fall back to the rev7 one (which lacks
some gpio-keys).
As I've got a Lenovo Flex 11 Chromebook with board revision 2, add it to
the base hana DTB file.
Signed-off-by: Icenowy Zheng <uwu@icenowy.me>
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
---
Changes in v2:
- Changed mailbox to ISCAS one.
arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dts b/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dts
index fcf0cb76a87c3..84638a07587f3 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-elm-hana.dts
@@ -11,5 +11,5 @@ / {
chassis-type = "laptop";
compatible = "google,hana-rev6", "google,hana-rev5",
"google,hana-rev4", "google,hana-rev3",
- "google,hana", "mediatek,mt8173";
+ "google,hana-rev2", "google,hana", "mediatek,mt8173";
};
--
2.52.0
^ permalink raw reply related
* [PATCH V3 0/3] arm64: dts: imx: Disable PCIe by default and add overlay support for M.2 connector
From: Sherry Sun @ 2026-03-25 8:31 UTC (permalink / raw)
To: Frank.Li, s.hauer, kernel, festevam, robh, krzk+dt, conor+dt,
hongxing.zhu
Cc: imx, linux-arm-kernel, devicetree, linux-kernel
On both i.MX8MP EVK and i.MX95-15x15 EVK boards, the M.2 connector
shares a common regulator between USDHC (for SDIO WiFi) and PCIe
controllers. The non-deterministic probe order between these two
buses can break the PCIe initialization sequence, causing PCIe
devices to fail detection intermittently.
The out-of-box module on i.MX8MP EVK and i.MX95-15x15 EVK are SDIO
WiFi (IW612), this series changes the default configuration to
match the out-of-box hardware (SDIO WiFi) and provides a device
tree overlay for users who need PCIe functionality:
1. Disable PCIe in the default device tree
2. Keep USDHC enabled for SDIO WiFi
3. Add 'm2_usdhc' label to support overlay
4. Provide a common overlay (imx-m2-pcie.dtso) to enable PCIe and
disable USDHC when needed
---
Changes in V3:
1. Add a common overlay imx-m2-pcie.dtso for both i.MX8MP EVK and
i.MX95-15x15 EVK.
2. Add 'm2_usdhc' label to support overlay.
Changes in V2:
1. Improve the commit message to clarify SDIO WiFi is the out-of-box
module on i.MX8MP EVK and i.MX95-15x15 EVK.
---
Sherry Sun (3):
arm64: dts: imx8mp-evk: Disable PCIe bus in the default dts
arm64: dts: imx95-15x15-evk: Disable PCIe bus in the default dts
arm64: dts: imx: Add common imx-m2-pcie.dtso to enable PCIe on M.2
connector
arch/arm64/boot/dts/freescale/Makefile | 9 +++++++--
arch/arm64/boot/dts/freescale/imx-m2-pcie.dtso | 15 +++++++++++++++
arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 4 ++--
arch/arm64/boot/dts/freescale/imx95-15x15-evk.dts | 4 ++--
4 files changed, 26 insertions(+), 6 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/imx-m2-pcie.dtso
--
2.37.1
^ 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