* Re: [PATCH v2 1/5] arm64: dts: lx2160a: transition to device-specific SerDes compatible strings
From: Ioana Ciornei @ 2026-07-02 7:35 UTC (permalink / raw)
To: Frank Li
Cc: Frank.Li, robh, krzk+dt, conor+dt, devicetree, vladimir.oltean,
linux-arm-kernel, linux-kernel, imx
In-Reply-To: <akUjt5OPiO5cJ1D9@SMW015318>
On Wed, Jul 01, 2026 at 09:27:03AM -0500, Frank Li wrote:
> On Wed, Jul 01, 2026 at 04:11:33PM +0300, Ioana Ciornei wrote:
> > From: Vladimir Oltean <vladimir.oltean@nxp.com>
> >
> > Align to the modern fsl,lynx-28g.yaml binding, where the SoC and SerDes
> > instance is present in the compatible string, to allow reliable per-lane
> > capability detection and per-lane customization of electrical properties.
> >
> > The modern bindings are backward-incompatible with old kernels, due
> > to the consumer phandles being either in one form or in another, as
> > explained here:
> > https://lore.kernel.org/lkml/20250930140735.mvo3jii7wgmzh2bs@skbuf/
> >
> > One of the major differences between the LX2160A and LX2162A is the
> > SerDes. So far, LX2162A has used fsl-lx2160a-rev2.dtsi, but we need to
> > split that up even further, and derive a fsl-lx2162a.dtsi which
> > overrides the SerDes properties.
> >
> > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
> > ---
> > Changes in v2:
> > - Enable serdes_1 on all board DTs that has consumers for it.
> > - Use the proper name for serdes_3 in fsl-lx2162a.dtsi.
> > - Remove paragraph from commit message which mentioned some consumer
> > changes that are no longer needed nor part of the commit.
> > ---
> > .../freescale/fsl-lx2160a-clearfog-itx.dtsi | 4 +
> > .../dts/freescale/fsl-lx2160a-half-twins.dts | 4 +
> > .../boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 +
> > .../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 150 +++++++++++++++++-
> > .../dts/freescale/fsl-lx2162a-clearfog.dts | 6 +-
> > .../boot/dts/freescale/fsl-lx2162a-qds.dts | 2 +-
> > .../arm64/boot/dts/freescale/fsl-lx2162a.dtsi | 24 +++
> > 7 files changed, 190 insertions(+), 4 deletions(-)
> > create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
> >
> ...
> >
> > +&serdes_1 {
> > + status = "okay";
> > +};
> > +
>
> Can you try keep alphabet order? may old file is not ordersed, but try
> best, at least should before &uart0
Sure, will move it.
>
> > &uart1 {
> > status = "okay";
> > };
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > index 1d73abffa6b7..a687eb3e3190 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
>
> Please split chips dtsi and boards dts to two patch.
Ok, I will split the serdes_1 explicit enable into a prep patch.
>
> > @@ -621,17 +621,163 @@ soc: soc {
> > ranges;
> > dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
> >
> > + /* Note on the interpretation of SerDes lane numbering from
> > + * LX2160ARM lane mappings for RCW[SRDS_PRTCL_S1]:
> > + * The letters (A-H) correspond to logical lane numbers in the
> > + * SerDes register map (lane A's registers start with LNAGCR0),
> > + * while the numbers (0-7) correspond to physical lanes as
> > + * routed to pins. SerDes block #1 is flipped in the LX2160A
> > + * floorplan (logical lane A goes to physical lane 7's pins),
> > + * while SerDes blocks #2 and #3 are not. The lanes below are
> > + * listed right to left when looking at that table.
> > + * Both the numbers and the letters are according to the logical
> > + * numbering scheme, and do not account for the flipping.
> > + */
> ...
> > + compatible = "fsl,lx2160a-serdes3";
> > + reg = <0x0 0x1ec0000 0x0 0x1e30>;
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + status = "disabled";
>
> status should be last property
Ok, will move it.
>
> > + #phy-cells = <1>;
> > +
> > + serdes_3_lane_a: phy@0 {
> > + reg = <0>;
> > + #phy-cells = <0>;
> > + };
> > +
> ...
> > +
> > +#include "fsl-lx2160a-rev2.dtsi"
> > +
> > +&serdes_1 {
> > + compatible = "fsl,lx2162a-serdes1", "fsl,lynx-28g";
> > +
> > + /delete-node/ phy@0;
> > + /delete-node/ phy@1;
> > + /delete-node/ phy@2;
> > + /delete-node/ phy@3;
>
> Now, do not perfer delete-node. if ver2 is not include phy@0, ...
>
> create ver2 files, let ver2 include it. Now most people like A + B, not
> A - B.
>
I am not sure I follow what you say about the ver2 files - are you
referring to -rev2 or LX2162A?
The LX2162A is a version of the LX2160A SoC, also known as "LX2-Lite".
And the main difference is that the LX2162A does not have the 3rd SerDes
block and only 4 SerDes lanes on the first block.
The delete-node is reflecting exactly how the SoCs came about, the
LX2162A is a smaller version of the LX2160A (which came first) and not
the other way around.
I feel like it's unnecessary churn but let me know if you feel strongly
about this.
Thanks,
Ioana
^ permalink raw reply
* Re: [PATCH 01/42] drm/mediatek: Rename OVL format naming
From: CK Hu (胡俊光) @ 2026-07-02 7:30 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, chunkuang.hu@kernel.org
Cc: robh@kernel.org, tzimmermann@suse.de, simona@ffwll.ch,
mripard@kernel.org, kernel@collabora.com,
linux-mediatek@lists.infradead.org,
maarten.lankhorst@linux.intel.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
conor+dt@kernel.org, devicetree@vger.kernel.org,
krzk+dt@kernel.org, Paul-pl Chen (陳柏霖),
p.zabel@pengutronix.de, airlied@gmail.com,
Justin Yeh (葉英茂), matthias.bgg@gmail.com,
linux-arm-kernel@lists.infradead.org,
Jason-JH Lin (林睿祥)
In-Reply-To: <20260701122057.19648-2-angelogioacchino.delregno@collabora.com>
On Wed, 2026-07-01 at 14:20 +0200, AngeloGioacchino Del Regno wrote:
> From: Paul-pl Chen <paul-pl.chen@mediatek.com>
>
> Rename format arrays from mt8173_formats[] to mt8173_ovl_formats[]
> to explicitly indicate that these format definitions are specific
> to OVL (Overlay) components.
>
> This naming improvement is necessary because MT8196 introduces new
> display components (EXDMA, BLENDER, OUTPROC) that support different
> format capabilities than OVL. Without clear naming, it becomes
> ambiguous which formats apply to which component type.
>
> Examples of format differences between components:
> - EXDMA supports 10-bit RGB formats that some OVL variants don't
> - BLENDER has different YUV handling requirements
> - Component-specific format conversion capabilities vary
>
> The explicit naming:
> - Prevents confusion when debugging format-related issues
> - Makes it immediately clear which component a format array belongs to
> - Improves code searchability (grep for "ovl_formats")
> - Follows consistent naming convention for component-specific definitions
> - Prepares for adding exdma_formats[], blender_formats[] arrays
>
> This is a preparatory patch for MT8196 component support, which
> requires clear distinction between OVL formats and EXDMA/BLENDER
> formats to avoid applying incorrect format configurations.
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Paul-pl Chen <paul-pl.chen@mediatek.com>
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 36 ++++++++++++-------------
> 1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index c4b5a262fa8a..87c2b5e6d6b0 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -101,7 +101,7 @@ static inline bool is_10bit_rgb(u32 fmt)
> return false;
> }
>
> -static const u32 mt8173_formats[] = {
> +static const u32 mt8173_ovl_formats[] = {
> DRM_FORMAT_XRGB8888,
> DRM_FORMAT_ARGB8888,
> DRM_FORMAT_BGRX8888,
> @@ -115,7 +115,7 @@ static const u32 mt8173_formats[] = {
> DRM_FORMAT_YUYV,
> };
>
> -static const u32 mt8195_formats[] = {
> +static const u32 mt8195_ovl_formats[] = {
> DRM_FORMAT_XRGB8888,
> DRM_FORMAT_ARGB8888,
> DRM_FORMAT_XRGB2101010,
> @@ -673,8 +673,8 @@ static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
> .gmc_bits = 8,
> .layer_nr = 4,
> .fmt_rgb565_is_0 = false,
> - .formats = mt8173_formats,
> - .num_formats = ARRAY_SIZE(mt8173_formats),
> + .formats = mt8173_ovl_formats,
> + .num_formats = ARRAY_SIZE(mt8173_ovl_formats),
> };
>
> static const struct mtk_disp_ovl_data mt8167_ovl_driver_data = {
> @@ -683,8 +683,8 @@ static const struct mtk_disp_ovl_data mt8167_ovl_driver_data = {
> .layer_nr = 4,
> .fmt_rgb565_is_0 = true,
> .smi_id_en = true,
> - .formats = mt8173_formats,
> - .num_formats = ARRAY_SIZE(mt8173_formats),
> + .formats = mt8173_ovl_formats,
> + .num_formats = ARRAY_SIZE(mt8173_ovl_formats),
> };
>
> static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
> @@ -692,8 +692,8 @@ static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
> .gmc_bits = 8,
> .layer_nr = 4,
> .fmt_rgb565_is_0 = true,
> - .formats = mt8173_formats,
> - .num_formats = ARRAY_SIZE(mt8173_formats),
> + .formats = mt8173_ovl_formats,
> + .num_formats = ARRAY_SIZE(mt8173_ovl_formats),
> };
>
> static const struct mtk_disp_ovl_data mt8183_ovl_driver_data = {
> @@ -701,8 +701,8 @@ static const struct mtk_disp_ovl_data mt8183_ovl_driver_data = {
> .gmc_bits = 10,
> .layer_nr = 4,
> .fmt_rgb565_is_0 = true,
> - .formats = mt8173_formats,
> - .num_formats = ARRAY_SIZE(mt8173_formats),
> + .formats = mt8173_ovl_formats,
> + .num_formats = ARRAY_SIZE(mt8173_ovl_formats),
> };
>
> static const struct mtk_disp_ovl_data mt8183_ovl_2l_driver_data = {
> @@ -710,8 +710,8 @@ static const struct mtk_disp_ovl_data mt8183_ovl_2l_driver_data = {
> .gmc_bits = 10,
> .layer_nr = 2,
> .fmt_rgb565_is_0 = true,
> - .formats = mt8173_formats,
> - .num_formats = ARRAY_SIZE(mt8173_formats),
> + .formats = mt8173_ovl_formats,
> + .num_formats = ARRAY_SIZE(mt8173_ovl_formats),
> };
>
> static const struct mtk_disp_ovl_data mt8192_ovl_driver_data = {
> @@ -723,8 +723,8 @@ static const struct mtk_disp_ovl_data mt8192_ovl_driver_data = {
> .blend_modes = BIT(DRM_MODE_BLEND_PREMULTI) |
> BIT(DRM_MODE_BLEND_COVERAGE) |
> BIT(DRM_MODE_BLEND_PIXEL_NONE),
> - .formats = mt8173_formats,
> - .num_formats = ARRAY_SIZE(mt8173_formats),
> + .formats = mt8173_ovl_formats,
> + .num_formats = ARRAY_SIZE(mt8173_ovl_formats),
> };
>
> static const struct mtk_disp_ovl_data mt8192_ovl_2l_driver_data = {
> @@ -736,8 +736,8 @@ static const struct mtk_disp_ovl_data mt8192_ovl_2l_driver_data = {
> .blend_modes = BIT(DRM_MODE_BLEND_PREMULTI) |
> BIT(DRM_MODE_BLEND_COVERAGE) |
> BIT(DRM_MODE_BLEND_PIXEL_NONE),
> - .formats = mt8173_formats,
> - .num_formats = ARRAY_SIZE(mt8173_formats),
> + .formats = mt8173_ovl_formats,
> + .num_formats = ARRAY_SIZE(mt8173_ovl_formats),
> };
>
> static const struct mtk_disp_ovl_data mt8195_ovl_driver_data = {
> @@ -750,8 +750,8 @@ static const struct mtk_disp_ovl_data mt8195_ovl_driver_data = {
> .blend_modes = BIT(DRM_MODE_BLEND_PREMULTI) |
> BIT(DRM_MODE_BLEND_COVERAGE) |
> BIT(DRM_MODE_BLEND_PIXEL_NONE),
> - .formats = mt8195_formats,
> - .num_formats = ARRAY_SIZE(mt8195_formats),
> + .formats = mt8195_ovl_formats,
> + .num_formats = ARRAY_SIZE(mt8195_ovl_formats),
> .supports_clrfmt_ext = true,
> };
>
^ permalink raw reply
* [PATCH v15 10/12] media: dt-bindings: mediatek,jpeg: Add mediatek, mt8196-jpgenc compatible
From: Kyrie Wu @ 2026-07-02 7:26 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
Cc: Krzysztof Kozlowski
In-Reply-To: <20260702072614.10373-1-kyrie.wu@mediatek.com>
Compared to the previous generation IC, the MT8196 uses SMMU
instead of IOMMU and supports features such as dynamic voltage
and frequency scaling. Therefore, add "mediatek,mt8196-jpgenc"
compatible to the binding document.
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
.../bindings/media/mediatek,mt8195-jpegenc.yaml | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegenc.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegenc.yaml
index 596186497b68..e2d772ea0fb0 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegenc.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegenc.yaml
@@ -14,7 +14,9 @@ description:
properties:
compatible:
- const: mediatek,mt8195-jpgenc
+ enum:
+ - mediatek,mt8195-jpgenc
+ - mediatek,mt8196-jpgenc
power-domains:
maxItems: 1
@@ -44,7 +46,9 @@ patternProperties:
properties:
compatible:
- const: mediatek,mt8195-jpgenc-hw
+ enum:
+ - mediatek,mt8195-jpgenc-hw
+ - mediatek,mt8196-jpgenc-hw
reg:
maxItems: 1
--
2.45.2
^ permalink raw reply related
* [PATCH v15 07/12] media: mediatek: jpeg: fix resolution change event handling in decoder
From: Kyrie Wu @ 2026-07-02 7:26 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260702072614.10373-1-kyrie.wu@mediatek.com>
This patch refines the handling of resolution change events within
JPEG decoder worker. The `mtk_jpeg_set_queue_data` function is now
called to set up queue data before signaling a source change through
`mtk_jpeg_queue_src_chg_event`. By reorganizing these calls, the
patch ensures that necessary queue information is updated prior to
transitioning the context state to `MTK_JPEG_SOURCE_CHANGE`.
A condition is added to exit early if the context is already in the
`MTK_JPEG_SOURCE_CHANGE` state, preventing redundant operations and
improving processing efficiency.
Fixes: dedc21500334 ("media: mtk-jpegdec: add jpeg decode worker interface")
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
---
drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 4dc574e03bd5..02efaed198b8 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1737,11 +1737,15 @@ static void mtk_jpegdec_worker(struct work_struct *work)
if (mtk_jpeg_check_resolution_change(ctx,
&jpeg_src_buf->dec_param)) {
- mtk_jpeg_queue_src_chg_event(ctx);
+ mtk_jpeg_set_queue_data(ctx, &jpeg_src_buf->dec_param);
ctx->state = MTK_JPEG_SOURCE_CHANGE;
+ mtk_jpeg_queue_src_chg_event(ctx);
goto getbuf_fail;
}
+ if (ctx->state == MTK_JPEG_SOURCE_CHANGE)
+ goto getbuf_fail;
+
mtk_jpegdec_set_hw_param(ctx, hw_id, src_buf, dst_buf);
ret = pm_runtime_resume_and_get(comp_jpeg[hw_id]->dev);
if (ret < 0) {
--
2.45.2
^ permalink raw reply related
* [PATCH v15 11/12] media: mediatek: jpeg: add jpeg compatible
From: Kyrie Wu @ 2026-07-02 7:26 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260702072614.10373-1-kyrie.wu@mediatek.com>
Add jpeg dec and enc compatible for mt8196
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 36 +++++++++++++++++++
.../platform/mediatek/jpeg/mtk_jpeg_dec_hw.c | 3 ++
.../platform/mediatek/jpeg/mtk_jpeg_enc_hw.c | 3 ++
3 files changed, 42 insertions(+)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 0b9a3b66895a..da7e723fd1f3 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1918,6 +1918,20 @@ static struct mtk_jpeg_variant mtk8195_jpegenc_drvdata = {
.jpeg_worker = mtk_jpegenc_worker,
};
+static struct mtk_jpeg_variant mtk8196_jpegenc_drvdata = {
+ .formats = mtk_jpeg_enc_formats,
+ .num_formats = MTK_JPEG_ENC_NUM_FORMATS,
+ .qops = &mtk_jpeg_enc_qops,
+ .m2m_ops = &mtk_jpeg_multicore_enc_m2m_ops,
+ .dev_name = "mtk-jpeg-enc",
+ .ioctl_ops = &mtk_jpeg_enc_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_YUYV,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .multi_core = true,
+ .jpeg_worker = mtk_jpegenc_worker,
+ .support_34bit = true,
+};
+
static const struct mtk_jpeg_variant mtk8195_jpegdec_drvdata = {
.formats = mtk_jpeg_dec_formats,
.num_formats = MTK_JPEG_DEC_NUM_FORMATS,
@@ -1931,6 +1945,20 @@ static const struct mtk_jpeg_variant mtk8195_jpegdec_drvdata = {
.jpeg_worker = mtk_jpegdec_worker,
};
+static const struct mtk_jpeg_variant mtk8196_jpegdec_drvdata = {
+ .formats = mtk_jpeg_dec_formats,
+ .num_formats = MTK_JPEG_DEC_NUM_FORMATS,
+ .qops = &mtk_jpeg_dec_qops,
+ .m2m_ops = &mtk_jpeg_multicore_dec_m2m_ops,
+ .dev_name = "mtk-jpeg-dec",
+ .ioctl_ops = &mtk_jpeg_dec_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_YUV420M,
+ .multi_core = true,
+ .jpeg_worker = mtk_jpegdec_worker,
+ .support_34bit = true,
+};
+
static const struct of_device_id mtk_jpeg_match[] = {
{
.compatible = "mediatek,mt8173-jpgdec",
@@ -1952,6 +1980,14 @@ static const struct of_device_id mtk_jpeg_match[] = {
.compatible = "mediatek,mt8195-jpgdec",
.data = &mtk8195_jpegdec_drvdata,
},
+ {
+ .compatible = "mediatek,mt8196-jpgenc",
+ .data = &mtk8196_jpegenc_drvdata,
+ },
+ {
+ .compatible = "mediatek,mt8196-jpgdec",
+ .data = &mtk8196_jpegdec_drvdata,
+ },
{},
};
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
index e4d2c5d4ec73..5a485e905787 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
@@ -45,6 +45,9 @@ static const struct of_device_id mtk_jpegdec_hw_ids[] = {
{
.compatible = "mediatek,mt8195-jpgdec-hw",
},
+ {
+ .compatible = "mediatek,mt8196-jpgdec-hw",
+ },
{},
};
MODULE_DEVICE_TABLE(of, mtk_jpegdec_hw_ids);
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
index 2adea3aca50b..1cfdfac98829 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
@@ -52,6 +52,9 @@ static const struct of_device_id mtk_jpegenc_drv_ids[] = {
{
.compatible = "mediatek,mt8195-jpgenc-hw",
},
+ {
+ .compatible = "mediatek,mt8196-jpgenc-hw",
+ },
{},
};
MODULE_DEVICE_TABLE(of, mtk_jpegenc_drv_ids);
--
2.45.2
^ permalink raw reply related
* [PATCH v15 06/12] media: mediatek: jpeg: fix decoding buffer number setting timing issue
From: Kyrie Wu @ 2026-07-02 7:26 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260702072614.10373-1-kyrie.wu@mediatek.com>
The src buffer doesn't need set information and dst buf parameters
only need to set when the power set succussed and protect the
setting by spinlock ensuring that any later operations acting
on this buffer reflect accurate state and frame data.
Fixes: dedc21500334 ("media: mtk-jpegdec: add jpeg decode worker interface")
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
---
drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 9 +++------
drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c | 1 +
drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c | 1 +
3 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 89048aba8dca..4dc574e03bd5 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1734,7 +1734,6 @@ static void mtk_jpegdec_worker(struct work_struct *work)
v4l2_m2m_buf_copy_metadata(src_buf, dst_buf);
jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(&src_buf->vb2_buf);
- jpeg_dst_buf = mtk_jpeg_vb2_to_srcbuf(&dst_buf->vb2_buf);
if (mtk_jpeg_check_resolution_change(ctx,
&jpeg_src_buf->dec_param)) {
@@ -1743,11 +1742,6 @@ static void mtk_jpegdec_worker(struct work_struct *work)
goto getbuf_fail;
}
- jpeg_src_buf->curr_ctx = ctx;
- jpeg_src_buf->frame_num = ctx->total_frame_num;
- jpeg_dst_buf->curr_ctx = ctx;
- jpeg_dst_buf->frame_num = ctx->total_frame_num;
-
mtk_jpegdec_set_hw_param(ctx, hw_id, src_buf, dst_buf);
ret = pm_runtime_resume_and_get(comp_jpeg[hw_id]->dev);
if (ret < 0) {
@@ -1772,6 +1766,9 @@ static void mtk_jpegdec_worker(struct work_struct *work)
msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC));
spin_lock_irqsave(&comp_jpeg[hw_id]->hw_lock, flags);
+ jpeg_dst_buf = mtk_jpeg_vb2_to_srcbuf(&dst_buf->vb2_buf);
+ jpeg_dst_buf->curr_ctx = ctx;
+ jpeg_dst_buf->frame_num = ctx->total_frame_num;
ctx->total_frame_num++;
mtk_jpeg_dec_reset(comp_jpeg[hw_id]->reg_base);
mtk_jpeg_dec_set_config(comp_jpeg[hw_id]->reg_base,
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
index 9a8dbca6af00..e4d2c5d4ec73 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
@@ -513,6 +513,7 @@ static void mtk_jpegdec_put_buf(struct mtk_jpegdec_comp_dev *jpeg)
v4l2_m2m_buf_done(&tmp_dst_done_buf->b,
VB2_BUF_STATE_DONE);
ctx->last_done_frame_num++;
+ break;
}
}
}
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
index 5d1c217fea0f..2adea3aca50b 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
@@ -242,6 +242,7 @@ static void mtk_jpegenc_put_buf(struct mtk_jpegenc_comp_dev *jpeg)
v4l2_m2m_buf_done(&tmp_dst_done_buf->b,
VB2_BUF_STATE_DONE);
ctx->last_done_frame_num++;
+ break;
}
}
}
--
2.45.2
^ permalink raw reply related
* [PATCH v15 04/12] media: mediatek: jpeg: Fix buffer completion on multi-core streaming stop
From: Kyrie Wu @ 2026-07-02 7:26 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260702072614.10373-1-kyrie.wu@mediatek.com>
Enhances the Mediatek JPEG driver's stability and reliability by ensuring
that all queued buffers are processed before stopping the streaming in
multi-core environments. It introduces a call to
`vb2_wait_for_all_buffers()` in the `mtk_jpeg_enc_stop_streaming()` and
`mtk_jpeg_dec_stop_streaming()` functions when the `multi_core` variant
is enabled. This change ensures that no buffers are left unprocessed,
preventing potential data loss or corruption during multi-core flow.
Fixes: 0fa49df4222f ("media: mtk-jpegdec: support jpegdec multi-hardware")
Fixes: dedc21500334 ("media: mtk-jpegdec: add jpeg decode worker interface")
Fixes: 934e8bccac95 ("mtk-jpegenc: support jpegenc multi-hardware")
Fixes: 5fb1c2361e56 ("mtk-jpegenc: add jpeg encode worker interface")
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
---
drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 6d6a999a22fc..76a5b49b7f43 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -850,8 +850,12 @@ static struct vb2_v4l2_buffer *mtk_jpeg_buf_remove(struct mtk_jpeg_ctx *ctx,
static void mtk_jpeg_enc_stop_streaming(struct vb2_queue *q)
{
struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
+ struct mtk_jpeg_dev *jpeg = ctx->jpeg;
struct vb2_v4l2_buffer *vb;
+ if (jpeg->variant->multi_core)
+ vb2_wait_for_all_buffers(q);
+
while ((vb = mtk_jpeg_buf_remove(ctx, q->type)))
v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
}
@@ -859,6 +863,7 @@ static void mtk_jpeg_enc_stop_streaming(struct vb2_queue *q)
static void mtk_jpeg_dec_stop_streaming(struct vb2_queue *q)
{
struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
+ struct mtk_jpeg_dev *jpeg = ctx->jpeg;
struct vb2_v4l2_buffer *vb;
/*
@@ -866,6 +871,9 @@ static void mtk_jpeg_dec_stop_streaming(struct vb2_queue *q)
* Before STREAMOFF, we still have to return the old resolution and
* subsampling. Update capture queue when the stream is off.
*/
+ if (jpeg->variant->multi_core)
+ vb2_wait_for_all_buffers(q);
+
if (ctx->state == MTK_JPEG_SOURCE_CHANGE &&
V4L2_TYPE_IS_CAPTURE(q->type)) {
struct mtk_jpeg_src_buf *src_buf;
--
2.45.2
^ permalink raw reply related
* [PATCH v15 05/12] media: mediatek: jpeg: Fix multi-core clk suspend and resume setting
From: Kyrie Wu @ 2026-07-02 7:26 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260702072614.10373-1-kyrie.wu@mediatek.com>
The suspend/resume callback function is defined in the dev_pm_ops
structure, which is defined in platform_driver. For multiple-core
architecture, each hardware driver will register a platform_driver
structure, so it is necessary to add a suspend/resume callback
function for each hardware to support this operation.
Fixes: 934e8bccac95 ("mtk-jpegenc: support jpegenc multi-hardware")
Fixes: 0fa49df4222f ("media: mtk-jpegdec: support jpegdec multi-hardware")
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 28 +++------
.../platform/mediatek/jpeg/mtk_jpeg_dec_hw.c | 62 +++++++++++++++++--
.../platform/mediatek/jpeg/mtk_jpeg_enc_hw.c | 60 ++++++++++++++++--
3 files changed, 121 insertions(+), 29 deletions(-)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 76a5b49b7f43..89048aba8dca 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1115,6 +1115,9 @@ static void mtk_jpeg_clk_on(struct mtk_jpeg_dev *jpeg)
{
int ret;
+ if (jpeg->variant->multi_core)
+ return;
+
ret = clk_bulk_prepare_enable(jpeg->variant->num_clks,
jpeg->variant->clks);
if (ret)
@@ -1123,6 +1126,9 @@ static void mtk_jpeg_clk_on(struct mtk_jpeg_dev *jpeg)
static void mtk_jpeg_clk_off(struct mtk_jpeg_dev *jpeg)
{
+ if (jpeg->variant->multi_core)
+ return;
+
clk_bulk_disable_unprepare(jpeg->variant->num_clks,
jpeg->variant->clks);
}
@@ -1647,13 +1653,6 @@ static void mtk_jpegenc_worker(struct work_struct *work)
goto enc_end;
}
- ret = clk_prepare_enable(comp_jpeg[hw_id]->venc_clk.clks->clk);
- if (ret) {
- dev_err(jpeg->dev, "%s : %d, jpegenc clk_prepare_enable fail\n",
- __func__, __LINE__);
- goto enc_end;
- }
-
v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
@@ -1750,20 +1749,13 @@ static void mtk_jpegdec_worker(struct work_struct *work)
jpeg_dst_buf->frame_num = ctx->total_frame_num;
mtk_jpegdec_set_hw_param(ctx, hw_id, src_buf, dst_buf);
- ret = pm_runtime_get_sync(comp_jpeg[hw_id]->dev);
+ ret = pm_runtime_resume_and_get(comp_jpeg[hw_id]->dev);
if (ret < 0) {
dev_err(jpeg->dev, "%s : %d, pm_runtime_get_sync fail !!!\n",
__func__, __LINE__);
goto dec_end;
}
- ret = clk_prepare_enable(comp_jpeg[hw_id]->jdec_clk.clks->clk);
- if (ret) {
- dev_err(jpeg->dev, "%s : %d, jpegdec clk_prepare_enable fail\n",
- __func__, __LINE__);
- goto clk_end;
- }
-
v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
@@ -1773,7 +1765,7 @@ static void mtk_jpegdec_worker(struct work_struct *work)
&dst_buf->vb2_buf, &fb)) {
dev_err(jpeg->dev, "%s : %d, mtk_jpeg_set_dec_dst fail\n",
__func__, __LINE__);
- goto setdst_end;
+ goto set_dst_fail;
}
schedule_delayed_work(&comp_jpeg[hw_id]->job_timeout_work,
@@ -1794,9 +1786,7 @@ static void mtk_jpegdec_worker(struct work_struct *work)
return;
-setdst_end:
- clk_disable_unprepare(comp_jpeg[hw_id]->jdec_clk.clks->clk);
-clk_end:
+set_dst_fail:
pm_runtime_put(comp_jpeg[hw_id]->dev);
dec_end:
v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
index 4534caeb104f..9a8dbca6af00 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
@@ -533,13 +533,12 @@ static void mtk_jpegdec_timeout_work(struct work_struct *work)
v4l2_m2m_buf_copy_metadata(src_buf, dst_buf);
mtk_jpeg_dec_reset(cjpeg->reg_base);
- clk_disable_unprepare(cjpeg->jdec_clk.clks->clk);
- pm_runtime_put(cjpeg->dev);
cjpeg->hw_state = MTK_JPEG_HW_IDLE;
atomic_inc(&master_jpeg->hw_rdy);
wake_up(&master_jpeg->hw_wq);
v4l2_m2m_buf_done(src_buf, buf_state);
mtk_jpegdec_put_buf(cjpeg);
+ pm_runtime_put(cjpeg->dev);
}
static irqreturn_t mtk_jpegdec_hw_irq_handler(int irq, void *priv)
@@ -547,7 +546,6 @@ static irqreturn_t mtk_jpegdec_hw_irq_handler(int irq, void *priv)
struct vb2_v4l2_buffer *src_buf, *dst_buf;
struct mtk_jpeg_src_buf *jpeg_src_buf;
enum vb2_buffer_state buf_state;
- struct mtk_jpeg_ctx *ctx;
u32 dec_irq_ret;
u32 irq_status;
int i;
@@ -557,7 +555,6 @@ static irqreturn_t mtk_jpegdec_hw_irq_handler(int irq, void *priv)
cancel_delayed_work(&jpeg->job_timeout_work);
- ctx = jpeg->hw_param.curr_ctx;
src_buf = jpeg->hw_param.src_buffer;
dst_buf = jpeg->hw_param.dst_buffer;
v4l2_m2m_buf_copy_metadata(src_buf, dst_buf);
@@ -580,12 +577,11 @@ static irqreturn_t mtk_jpegdec_hw_irq_handler(int irq, void *priv)
buf_state = VB2_BUF_STATE_DONE;
v4l2_m2m_buf_done(src_buf, buf_state);
mtk_jpegdec_put_buf(jpeg);
- pm_runtime_put(ctx->jpeg->dev);
- clk_disable_unprepare(jpeg->jdec_clk.clks->clk);
jpeg->hw_state = MTK_JPEG_HW_IDLE;
wake_up(&master_jpeg->hw_wq);
atomic_inc(&master_jpeg->hw_rdy);
+ pm_runtime_put(jpeg->dev);
return IRQ_HANDLED;
}
@@ -668,15 +664,69 @@ static int mtk_jpegdec_hw_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dev);
pm_runtime_enable(&pdev->dev);
+ ret = devm_clk_bulk_get(dev->dev,
+ jpegdec_clk->clk_num,
+ jpegdec_clk->clks);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to init clk\n");
+ return ret;
+ }
return 0;
}
+static int mtk_jpegdec_pm_suspend(struct device *dev)
+{
+ struct mtk_jpegdec_comp_dev *jpeg = dev_get_drvdata(dev);
+
+ clk_bulk_disable_unprepare(jpeg->jdec_clk.clk_num,
+ jpeg->jdec_clk.clks);
+
+ return 0;
+}
+
+static int mtk_jpegdec_pm_resume(struct device *dev)
+{
+ struct mtk_jpegdec_comp_dev *jpeg = dev_get_drvdata(dev);
+
+ return clk_bulk_prepare_enable(jpeg->jdec_clk.clk_num,
+ jpeg->jdec_clk.clks);
+}
+
+static int mtk_jpegdec_suspend(struct device *dev)
+{
+ struct mtk_jpegdec_comp_dev *jpeg = dev_get_drvdata(dev);
+
+ v4l2_m2m_suspend(jpeg->master_dev->m2m_dev);
+
+ return pm_runtime_force_suspend(dev);
+}
+
+static int mtk_jpegdec_resume(struct device *dev)
+{
+ struct mtk_jpegdec_comp_dev *jpeg = dev_get_drvdata(dev);
+ int ret;
+
+ ret = pm_runtime_force_resume(dev);
+ if (ret < 0)
+ return ret;
+
+ v4l2_m2m_resume(jpeg->master_dev->m2m_dev);
+
+ return 0;
+}
+
+static const struct dev_pm_ops mtk_jpegdec_pm_ops = {
+ SYSTEM_SLEEP_PM_OPS(mtk_jpegdec_suspend, mtk_jpegdec_resume)
+ RUNTIME_PM_OPS(mtk_jpegdec_pm_suspend, mtk_jpegdec_pm_resume, NULL)
+};
+
static struct platform_driver mtk_jpegdec_hw_driver = {
.probe = mtk_jpegdec_hw_probe,
.driver = {
.name = "mtk-jpegdec-hw",
.of_match_table = mtk_jpegdec_hw_ids,
+ .pm = &mtk_jpegdec_pm_ops,
},
};
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
index 2765dafab4ad..5d1c217fea0f 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
@@ -264,13 +264,12 @@ static void mtk_jpegenc_timeout_work(struct work_struct *work)
v4l2_m2m_buf_copy_metadata(src_buf, dst_buf);
mtk_jpeg_enc_reset(cjpeg->reg_base);
- clk_disable_unprepare(cjpeg->venc_clk.clks->clk);
- pm_runtime_put(cjpeg->dev);
cjpeg->hw_state = MTK_JPEG_HW_IDLE;
atomic_inc(&master_jpeg->hw_rdy);
wake_up(&master_jpeg->hw_wq);
v4l2_m2m_buf_done(src_buf, buf_state);
mtk_jpegenc_put_buf(cjpeg);
+ pm_runtime_put(cjpeg->dev);
}
static irqreturn_t mtk_jpegenc_hw_irq_handler(int irq, void *priv)
@@ -304,12 +303,11 @@ static irqreturn_t mtk_jpegenc_hw_irq_handler(int irq, void *priv)
buf_state = VB2_BUF_STATE_DONE;
v4l2_m2m_buf_done(src_buf, buf_state);
mtk_jpegenc_put_buf(jpeg);
- pm_runtime_put(ctx->jpeg->dev);
- clk_disable_unprepare(jpeg->venc_clk.clks->clk);
jpeg->hw_state = MTK_JPEG_HW_IDLE;
wake_up(&master_jpeg->hw_wq);
atomic_inc(&master_jpeg->hw_rdy);
+ pm_runtime_put(jpeg->dev);
return IRQ_HANDLED;
}
@@ -390,15 +388,69 @@ static int mtk_jpegenc_hw_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, dev);
pm_runtime_enable(&pdev->dev);
+ ret = devm_clk_bulk_get(dev->dev,
+ jpegenc_clk->clk_num,
+ jpegenc_clk->clks);
+ if (ret) {
+ dev_err(&pdev->dev, "Failed to init clk\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int mtk_jpegenc_pm_suspend(struct device *dev)
+{
+ struct mtk_jpegenc_comp_dev *jpeg = dev_get_drvdata(dev);
+
+ clk_bulk_disable_unprepare(jpeg->venc_clk.clk_num,
+ jpeg->venc_clk.clks);
return 0;
}
+static int mtk_jpegenc_pm_resume(struct device *dev)
+{
+ struct mtk_jpegenc_comp_dev *jpeg = dev_get_drvdata(dev);
+
+ return clk_bulk_prepare_enable(jpeg->venc_clk.clk_num,
+ jpeg->venc_clk.clks);
+}
+
+static int mtk_jpegenc_suspend(struct device *dev)
+{
+ struct mtk_jpegenc_comp_dev *jpeg = dev_get_drvdata(dev);
+
+ v4l2_m2m_suspend(jpeg->master_dev->m2m_dev);
+
+ return pm_runtime_force_suspend(dev);
+}
+
+static int mtk_jpegenc_resume(struct device *dev)
+{
+ struct mtk_jpegenc_comp_dev *jpeg = dev_get_drvdata(dev);
+ int ret;
+
+ ret = pm_runtime_force_resume(dev);
+ if (ret < 0)
+ return ret;
+
+ v4l2_m2m_resume(jpeg->master_dev->m2m_dev);
+
+ return 0;
+}
+
+static const struct dev_pm_ops mtk_jpegenc_pm_ops = {
+ SYSTEM_SLEEP_PM_OPS(mtk_jpegenc_suspend, mtk_jpegenc_resume)
+ RUNTIME_PM_OPS(mtk_jpegenc_pm_suspend, mtk_jpegenc_pm_resume, NULL)
+};
+
static struct platform_driver mtk_jpegenc_hw_driver = {
.probe = mtk_jpegenc_hw_probe,
.driver = {
.name = "mtk-jpegenc-hw",
.of_match_table = mtk_jpegenc_drv_ids,
+ .pm = &mtk_jpegenc_pm_ops,
},
};
--
2.45.2
^ permalink raw reply related
* [PATCH v15 01/12] media: mediatek: jpeg: fix jpeg cores' amounts setting
From: Kyrie Wu @ 2026-07-02 7:26 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260702072614.10373-1-kyrie.wu@mediatek.com>
Different ICs have different amounts of cores,
use a variable to set the cores' amounts.
Fixes: 934e8bccac95 ("mtk-jpegenc: support jpegenc multi-hardware")
Fixes: 0fa49df4222f ("media: mtk-jpegdec: support jpegdec multi-hardware")
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 8 ++++----
drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h | 2 ++
drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c | 1 +
drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c | 1 +
4 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index d147ec483081..1e014fd698ae 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1462,7 +1462,7 @@ static int mtk_jpegenc_get_hw(struct mtk_jpeg_ctx *ctx)
int i;
spin_lock_irqsave(&jpeg->hw_lock, flags);
- for (i = 0; i < MTK_JPEGENC_HW_MAX; i++) {
+ for (i = 0; i < jpeg->max_hw_count; i++) {
comp_jpeg = jpeg->enc_hw_dev[i];
if (comp_jpeg->hw_state == MTK_JPEG_HW_IDLE) {
hw_id = i;
@@ -1509,7 +1509,7 @@ static int mtk_jpegdec_get_hw(struct mtk_jpeg_ctx *ctx)
int i;
spin_lock_irqsave(&jpeg->hw_lock, flags);
- for (i = 0; i < MTK_JPEGDEC_HW_MAX; i++) {
+ for (i = 0; i < jpeg->max_hw_count; i++) {
comp_jpeg = jpeg->dec_hw_dev[i];
if (comp_jpeg->hw_state == MTK_JPEG_HW_IDLE) {
hw_id = i;
@@ -1592,7 +1592,7 @@ static void mtk_jpegenc_worker(struct work_struct *work)
jpeg_work);
struct mtk_jpeg_dev *jpeg = ctx->jpeg;
- for (i = 0; i < MTK_JPEGENC_HW_MAX; i++)
+ for (i = 0; i < jpeg->max_hw_count; i++)
comp_jpeg[i] = jpeg->enc_hw_dev[i];
i = 0;
@@ -1687,7 +1687,7 @@ static void mtk_jpegdec_worker(struct work_struct *work)
struct mtk_jpeg_fb fb;
unsigned long flags;
- for (i = 0; i < MTK_JPEGDEC_HW_MAX; i++)
+ for (i = 0; i < jpeg->max_hw_count; i++)
comp_jpeg[i] = jpeg->dec_hw_dev[i];
i = 0;
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h
index 02ed0ed5b736..6be5cf30dea1 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h
@@ -212,6 +212,7 @@ struct mtk_jpegdec_comp_dev {
* @reg_decbase: jpg decode register base addr
* @dec_hw_dev: jpg decode hardware device
* @hw_index: jpg hw index
+ * @max_hw_count: jpeg hw-core count
*/
struct mtk_jpeg_dev {
struct mutex lock;
@@ -234,6 +235,7 @@ struct mtk_jpeg_dev {
void __iomem *reg_decbase[MTK_JPEGDEC_HW_MAX];
struct mtk_jpegdec_comp_dev *dec_hw_dev[MTK_JPEGDEC_HW_MAX];
atomic_t hw_index;
+ u32 max_hw_count;
};
/**
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
index 32372781daf5..4534caeb104f 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
@@ -664,6 +664,7 @@ static int mtk_jpegdec_hw_probe(struct platform_device *pdev)
master_dev->dec_hw_dev[i] = dev;
master_dev->reg_decbase[i] = dev->reg_base;
dev->master_dev = master_dev;
+ master_dev->max_hw_count++;
platform_set_drvdata(pdev, dev);
pm_runtime_enable(&pdev->dev);
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
index b6f5b2249f1f..2765dafab4ad 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c
@@ -386,6 +386,7 @@ static int mtk_jpegenc_hw_probe(struct platform_device *pdev)
master_dev->enc_hw_dev[i] = dev;
master_dev->reg_encbase[i] = dev->reg_base;
dev->master_dev = master_dev;
+ master_dev->max_hw_count++;
platform_set_drvdata(pdev, dev);
pm_runtime_enable(&pdev->dev);
--
2.45.2
^ permalink raw reply related
* [PATCH v15 03/12] media: mediatek: jpeg: fix buffer structure size and layout
From: Kyrie Wu @ 2026-07-02 7:26 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260702072614.10373-1-kyrie.wu@mediatek.com>
Updates the `buf_struct_size` in the JPEG driver to use the correct
structure `mtk_jpeg_src_buf` instead of `v4l2_m2m_buffer`, ensuring
proper handling of source buffers. The previous buffer size led to
mismatches and potential issues during video buffer handling.
Moves `frame_num` in the `mtk_jpeg_src_buf` structure to align with
other members appropriately. The first field of the driver-specific
buffer structure must be the subsystem-specificstruct
(vb2_v4l2_buffer in the case of V4L2).
Fixes: 5fb1c2361e56 ("mtk-jpegenc: add jpeg encode worker interface")
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
---
drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 2 +-
drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 3960ad21d7f0..6d6a999a22fc 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1092,7 +1092,7 @@ static int mtk_jpeg_queue_init(void *priv, struct vb2_queue *src_vq,
dst_vq->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
dst_vq->io_modes = VB2_DMABUF | VB2_MMAP;
dst_vq->drv_priv = ctx;
- dst_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
+ dst_vq->buf_struct_size = sizeof(struct mtk_jpeg_src_buf);
dst_vq->ops = jpeg->variant->qops;
dst_vq->mem_ops = &vb2_dma_contig_memops;
dst_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h
index 6be5cf30dea1..148fd41759b7 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.h
@@ -85,10 +85,10 @@ struct mtk_jpeg_variant {
};
struct mtk_jpeg_src_buf {
- u32 frame_num;
struct vb2_v4l2_buffer b;
struct list_head list;
u32 bs_size;
+ u32 frame_num;
struct mtk_jpeg_dec_param dec_param;
struct mtk_jpeg_ctx *curr_ctx;
--
2.45.2
^ permalink raw reply related
* [PATCH v15 00/12] Enable jpeg enc & dec multi-hardwares for MT8196
From: Kyrie Wu @ 2026-07-02 7:26 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
This series have the follow changing:
Firstly fix some bugs, including resolution change handleing, stop
streaming sw flow, fix buffer layout and clock setting to support multi-hw
jpeg working and others.
Secondly add mt8196 jpegdec and jpegenc compatible to support MT8196
kernel driver.
Lastly, Add smmu setting to support smmu and iommu at the same time.
This series has been tested with MT8196 tast test.
Encoding and decoding worked for this chip.
Patches 1 fix jpeg hw count setting to support different chips.
Patches 2 fix jpeg buffer payload setting to handle buffer
size bug while resolution changed.
Patches 3 fix jpeg dst buffer layout.
Patches 4 fix multi-core stop streaming flow
Patches 5 fix multi-core clk suspend/resume setting
Patches 6 fix decoding buffer number setting timing issue
Patches 7 fix decoding resolution change operation
Patches 8 fix remove buffer operation
Patches 9-11 Adds jpeg encoder and decoder compatible.
Patches 12 add jpeg smmu sid setting.
---
Changes compared with v14:
--Rebased on top of the latest media tree
Changes compared with v13:
--Rebased on top of the latest media tree
Changes compared with v12:
--Rebased on top of the latest media tree
--fix kernel rebot build warnings in patch 5
Changes compared with v11:
--Rebased on top of the latest media tree
--Some modifications for patch v11's review comments.
--add reviewer to commit messages
Changes compared with v10:
--Rebased on top of the latest media tree
--add reviewer to commit messages
Changes compared with v9:
--Rebased on top of the latest media tree
Changes compared with v8:
--Rebased on top of the latest media tree
Changes compared with v7:
--Rebased on top of the latest media tree
Changes compared with v6:
--Rebased on top of the latest media tree
Changes compared with v5:
--reorder the patches set.
--fix commit message of patch 1-8.
Changes compared with v4:
--fix kernel robot build errors for patch 4.
--add reviewer for patch 1 and patch 2.
Changes compared with v3:
--change patch subject of jpeg encoder and decoder compatible.
Changes compared with v2:
--refactor smmu sid setting function interface
--Some modifications for patch v2's review comments.
Changes compared with v1:
--refine jpeg dt-bindings for MT8196
--optimize software code to manage jpeg HW count
--refactor smmu sid setting function interface
--Some modifications for patch v1's review comments.
Kyrie Wu (12):
media: mediatek: jpeg: fix jpeg cores' amounts setting
media: mediatek: jpeg: fix jpeg buffer payload size setting
media: mediatek: jpeg: fix buffer structure size and layout
media: mediatek: jpeg: Fix buffer completion on multi-core streaming
stop
media: mediatek: jpeg: Fix multi-core clk suspend and resume setting
media: mediatek: jpeg: fix decoding buffer number setting timing issue
media: mediatek: jpeg: fix resolution change event handling in decoder
media: mediatek: jpeg: fix remove buffer removal timing for multi-core
media: dt-bindings: mediatek,jpeg: Add mediatek, mt8196-jpgdec
compatible
media: dt-bindings: mediatek,jpeg: Add mediatek, mt8196-jpgenc
compatible
media: mediatek: jpeg: add jpeg compatible
media: mediatek: jpeg: add jpeg smmu sid setting
.../media/mediatek,mt8195-jpegdec.yaml | 8 +-
.../media/mediatek,mt8195-jpegenc.yaml | 8 +-
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 153 +++++++++++++-----
.../platform/mediatek/jpeg/mtk_jpeg_core.h | 19 ++-
.../platform/mediatek/jpeg/mtk_jpeg_dec_hw.c | 90 ++++++++++-
.../platform/mediatek/jpeg/mtk_jpeg_enc_hw.c | 88 +++++++++-
6 files changed, 310 insertions(+), 56 deletions(-)
--
2.45.2
^ permalink raw reply
* [PATCH v15 02/12] media: mediatek: jpeg: fix jpeg buffer payload size setting
From: Kyrie Wu @ 2026-07-02 7:26 UTC (permalink / raw)
To: Hans Verkuil, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Nicolas Dufresne, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Kyrie Wu,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260702072614.10373-1-kyrie.wu@mediatek.com>
For multi-core jpegdec, if one core gets resolution change event,
the payload size, representing the size of Y/C data, needs to change.
But others are decoding at the same time and it can not be changed
immediately, which results in the payload size to not match the real
buffer length.
The payload size must less than the real buffer length to remove
the warnning logs.
Fixes: 0fa49df4222f ("media: mtk-jpegdec: support jpegdec multi-hardware")
Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 19 ++++++++++++++-----
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 1e014fd698ae..3960ad21d7f0 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -702,6 +702,7 @@ static int mtk_jpeg_buf_prepare(struct vb2_buffer *vb)
struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(vb->vb2_queue);
struct mtk_jpeg_q_data *q_data = NULL;
struct v4l2_plane_pix_format plane_fmt = {};
+ size_t max_size;
int i;
q_data = mtk_jpeg_get_q_data(ctx, vb->vb2_queue->type);
@@ -710,12 +711,20 @@ static int mtk_jpeg_buf_prepare(struct vb2_buffer *vb)
for (i = 0; i < q_data->fmt->colplanes; i++) {
plane_fmt = q_data->pix_mp.plane_fmt[i];
+ max_size = plane_fmt.sizeimage;
+
if (ctx->enable_exif &&
- q_data->fmt->fourcc == V4L2_PIX_FMT_JPEG)
- vb2_set_plane_payload(vb, i, plane_fmt.sizeimage +
- MTK_JPEG_MAX_EXIF_SIZE);
- else
- vb2_set_plane_payload(vb, i, plane_fmt.sizeimage);
+ q_data->fmt->fourcc == V4L2_PIX_FMT_JPEG) {
+ max_size += MTK_JPEG_MAX_EXIF_SIZE;
+
+ vb2_set_plane_payload(vb, i,
+ MIN(vb->planes[i].length,
+ max_size));
+ } else {
+ vb2_set_plane_payload(vb, i,
+ MIN(plane_fmt.sizeimage,
+ vb->planes[i].length));
+ }
}
return 0;
--
2.45.2
^ permalink raw reply related
* Re: [PATCH 2/3] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board
From: Krzysztof Kozlowski @ 2026-07-02 7:17 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade
Cc: dinguyen, maxime.chevallier, rmk+kernel, krzk+dt, conor+dt, robh,
davem, edumazet, kuba, pabeni, andrew+netdev, devicetree,
linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <20260630133108.27244-3-muhammad.nazim.amirul.nazle.asmade@altera.com>
On Tue, Jun 30, 2026 at 06:31:07AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Add device tree for the Intel SoCFPGA Agilex5 SoCDK TSN Config2 board
> variant. This configuration enables gmac1 as a TSN port alongside
> the standard gmac2 Ethernet port.
>
> The TSN port (gmac1) uses GMII internally in the MAC but connects to an
> RGMII PHY. The mac-mode property is set to "gmii" to reflect the
> MAC-side interface, while phy-mode is set to "rgmii" for the PHY-side
> interface.
>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> ---
> arch/arm64/boot/dts/intel/Makefile | 3 +-
> .../intel/socfpga_agilex5_socdk_tsn_cfg2.dts | 133 ++++++++++++++++++
> 2 files changed, 135 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_tsn_cfg2.dts
>
> diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
> index 270c70fdf084..fc7ba2c6384b 100644
> --- a/arch/arm64/boot/dts/intel/Makefile
> +++ b/arch/arm64/boot/dts/intel/Makefile
> @@ -4,10 +4,11 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
> socfpga_agilex_socdk_emmc.dtb \
> socfpga_agilex_socdk_nand.dtb \
> socfpga_agilex3_socdk.dtb \
> - socfpga_agilex5_socdk.dtb \
> + socfpga_agilex5_socdk.dtb \
Why are you making this change?
> socfpga_agilex5_socdk_013b.dtb \
> socfpga_agilex5_socdk_modular.dtb \
> socfpga_agilex5_socdk_nand.dtb \
> + socfpga_agilex5_socdk_tsn_cfg2.dtb \
> socfpga_agilex72_socdk.dtb \
> socfpga_agilex7m_socdk.dtb \
> socfpga_n5x_socdk.dtb
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/6] KVM: arm64: ptdump: Shadow ptdump fixes
From: Itaru Kitayama @ 2026-07-02 6:55 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: linux-arm-kernel, kvmarm, linux-kernel, Marc Zyngier,
Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Sebastian Ene
In-Reply-To: <20260630121005.1130996-1-weilin.chang@arm.com>
Hi Wei-Lin,
On Tue, Jun 30, 2026 at 01:09:59PM +0100, Wei-Lin Chang wrote:
> Hi,
>
> This is v2 of fixing shadow ptdump debugfs files. Unfortunately I couldn't make
> per mmu ptdump files work after all, mainly because there isn't a clean way to
> locate the specific nested mmu for each ptdump file as the nested mmus could be
> freed when the file gets opened. Therefore in this series a single file
> "shadow_page_tables" is created that dumps all valid mmus' page table
> information.
>
> An advantage of this is that this new ptdump file have a lifetime identical to
> other ptdump files i.e. stage2_page_tables, ipa_range, etc., hence avoiding the
> dentry UAF found last time [1].
>
> With this all ptdump files are only removed when the last kvm reference gets
> dropped and kvm_destroy_vm_debugfs() is called, in their open(), show()
> functions the nested mmu array and mmu->pgt are checked with mmu_lock held to
> prevent UAF.
>
> Patch 1-2: Undo previous shadow ptdump implementation.
> Patch 3: Fix a mmu->pgt UAF that happens when ptdump files are read after
> mmu->pgt is freed.
> Patch 4-5: Preparation for the shadow page table dump file.
> Patch 6: Implementation of the shadow page table dump file.
>
> The fixes are tested with CONFIG_PROVE_LOCKING,
> CONFIG_DEBUG_ATOMIC_SLEEP, and CONFIG_KASAN.
>
> Thanks!
Running your shadow stage 2 kselftest with bpftrace shows me that __kvm_pgtable_stage2_init()
for shadow stage 2 translation tables are built with ia_bits = 52 and
start_level = 0, but the debugfs entry for the active shadow stage 2 tables prints
out that's 3 levels. Is this fully expected?
Thanks,
Itaru.
>
> * Changes from v1 ([2]):
>
> - Move from per mmu ptdump files to one file that will dump all shadow page
> tables.
>
> [1]: https://lore.kernel.org/kvmarm/ajty6I7ZqodP4ous@sm-arm-grace07/
> [2]: https://lore.kernel.org/kvmarm/20260623142443.648972-1-weilin.chang@arm.com/
>
> Wei-Lin Chang (6):
> KVM: arm64: ptdump: Remove shadow ptdump files
> KVM: arm64: ptdump: Undo making the ptdump code mmu aware
> KVM: arm64: ptdump: Fix UAF when mmu->pgt is freed
> KVM: arm64: ptdump: Factor out initialization of
> kvm_ptdump_guest_state
> KVM: arm64: ptdump: Extract kvm_ptdump_guest_open() from canonical
> ptdump path
> KVM: arm64: ptdump: Introduce the shadow ptdump file
>
> arch/arm64/include/asm/kvm_host.h | 5 +-
> arch/arm64/include/asm/kvm_mmu.h | 4 -
> arch/arm64/kvm/nested.c | 18 +--
> arch/arm64/kvm/ptdump.c | 185 ++++++++++++++++++++----------
> 4 files changed, 135 insertions(+), 77 deletions(-)
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v4 1/7] dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via NVMEM
From: Manikandan.M @ 2026-07-02 6:55 UTC (permalink / raw)
To: krzk
Cc: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, Nicolas.Ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
In-Reply-To: <20260702-utopian-termite-of-perfection-f1f3ec@quoll>
Hi Krzysztof,
On 7/2/26 11:46 AM, Krzysztof Kozlowski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Tue, Jun 30, 2026 at 02:54:00PM +0530, Manikandan Muralidharan wrote:
>> Add an optional "sfdp" child node (compatible "jedec,sfdp") that
>> describes the SFDP as a read-only NVMEM provider via nvmem.yaml, so its
>
> What is SFDP?
>
SFDP is the Serial Flash Discoverable Parameters -- a JEDEC-standardised
(JESD216) read-only parameter table present in most SPI NOR flashes, the
table contents provide basic information about the flash. There are
standard tables which are specified by the JEDEC standard and there are
vendor tables.
>> contents (e.g. a vendor EUI-48/EUI-64) can be read through NVMEM cells.
>>
>> Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
>> ---
>> .../devicetree/bindings/mtd/jedec,spi-nor.yaml | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
>> index 587af4968255..98fd954598ab 100644
>> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
>> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
>> @@ -103,6 +103,20 @@ properties:
>> spi-cpol: true
>> spi-cpha: true
>>
>> + sfdp:
>> + $ref: /schemas/nvmem/nvmem.yaml#
>> + unevaluatedProperties: false
>> + description:
>> + The Serial Flash Discoverable Parameters (SFDP) tables exposed as a
>> + read-only NVMEM device. This allows standard or vendor-specific SFDP
>> + data (for example a factory-programmed EUI-48/EUI-64 identifier) to be
>> + consumed through NVMEM cells.
>> + properties:
>> + compatible:
>> + const: jedec,sfdp
>> + required:
>> + - compatible
>
> Where are any resources? What sort of sub-device is represented here by
> an empty device node?
The sub-device describes the flash's SFDP region exposed as a read-only
NVMEM provider:the SPI NOR core reads the SFDP and registers it as an
NVMEM device rooted at this node.Its contents are then consumed through
NVMEM cells -- a "fixed-layout" for data at a known offset, or an
"nvmem-layout" parser for data whose location must be discovered at
runtime (the Microchip EUI layout driver in patch 4/7 does the latter).
It is not a bus-addressed hardware sub-device, so it has no reg.
This models the SFDP-as-NVMEM approach suggested during the v3 review,
instead of special-casing the vendor table in the SPI NOR core:
https://lore.kernel.org/linux-arm-kernel/20250521070336.402202-1-manikandan.m@microchip.com/
>
> Best regards,
> Krzysztof
>
--
Thanks and Regards,
Manikandan M.
^ permalink raw reply
* Re: [PATCH v4 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Wen Jiang @ 2026-07-02 6:35 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, urezki, baohua,
Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang
In-Reply-To: <20260624195704.5c29c0353163babb721585ca@linux-foundation.org>
On Thu, 25 Jun 2026 at 10:57, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 18 Jun 2026 16:47:20 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
>
> > This patchset accelerates ioremap, vmalloc, and vmap when the memory
> > is physically fully or partially contiguous. Two techniques are used:
>
> Thanks.
>
> > 1. Avoid page table rewalk when setting PTEs/PMDs for multiple memory
> > segments
> > 2. Use batched mappings wherever possible in both vmalloc and ARM64
> > layers
> >
> > Besides accelerating the mapping path, this also enables large
> > mappings (PMD and cont-PTE) for vmap, which are currently not
> > supported.
> >
> > Patches 1-2 extend ARM64 vmalloc CONT-PTE mapping to support multiple
> > CONT-PTE regions instead of just one.
> >
> > Patch 3 extracts a common helper vmap_set_ptes() that consolidates PTE
> > mapping logic between the ioremap and vmalloc/vmap paths, handling both
> > CONT_PTE and regular PTE mappings. This prepares for the next patch.
> >
> > Patch 4 extends the page table walk path to support page shifts other
> > than PAGE_SHIFT and eliminates the page table rewalk for huge vmalloc
> > mappings. The function is renamed from vmap_small_pages_range_noflush()
> > to vmap_pages_range_noflush_walk().
> >
> > Patches 5-6 add huge vmap support for contiguous pages, including
> > support for non-compound pages with pfn alignment verification.
> >
> > On the RK3588 8-core ARM64 SoC, with tasks pinned to a little core and
> > the performance CPUfreq policy enabled, benchmark results:
> >
> > * ioremap(1 MB): 1.35x faster (3407 ns -> 2526 ns)
> > * vmalloc(1 MB) mapping time (excluding allocation) with
> > VM_ALLOW_HUGE_VMAP: 1.42x faster (5.00 us -> 3.53us)
> > * vmap(100MB) with order-8 pages: 8.3x faster (1235 us -> 149 us)
>
> Nice.
>
> > Many thanks to Xueyuan Chen for his testing efforts on RK3588 boards.
>
> Indeed.
>
> I see Dev had a good look at v3 - hopefully he (and Ulad) (and more ARM
> folks) have time to go through this.
>
> Is there any effect on anything other than arm64? I'm wondering how
> much testing these changes will really get in mm.git and linux-next.
>
> How is our selftests coverage of these changes? Is there some existing
> selftest which will exercise these new features?
>
Hi Andrew,
I ran all test_vmalloc subtests (run_test_mask=0xff) on both ARM64 and
x86_64, comparing base (v7.0.10) against the patched kernel.
All test_vmalloc subtests passed on both platforms. I do not see any
functional or performance regression. The small differences below look
like measurement noise.
ARM64 (Radxa ROCK 5B+, RK3588, pinned to CPU 0, performance governor,
5 runs averaged):
+------------------------------+------------+------------+--------+
| Test | Base(usec) |Patch(usec) | Change |
+------------------------------+------------+------------+--------+
| fix_size_alloc_test | 935371 | 913368 | -2.4% |
| full_fit_alloc_test | 1208295 | 1244718 | +3.0% |
| long_busy_list_alloc_test | 35669866 | 35854584 | +0.5% |
| random_size_alloc_test | 20122611 | 20200013 | +0.4% |
| fix_align_alloc_test | 3240373 | 3288431 | +1.5% |
| random_size_align_alloc_test | 4822107 | 4792305 | -0.6% |
| pcpu_alloc_test | 87641 | 89429 | +2.0% |
| Total cycles | 1586173575 | 1593193228 | +0.4% |
+------------------------------+------------+------------+--------+
x86_64 (Intel i7-8700, bare metal, pinned to CPU 0, performance governor,
5 runs averaged):
+------------------------------+-------------+-------------+--------+
| Test | Base(usec) | Patch(usec) | Change |
+------------------------------+-------------+-------------+--------+
| fix_size_alloc_test | 447739 | 439655 | -1.8% |
| full_fit_alloc_test | 572719 | 575582 | +0.5% |
| long_busy_list_alloc_test | 8544326 | 8635052 | +1.1% |
| random_size_alloc_test | 4475421 | 4490037 | +0.3% |
| fix_align_alloc_test | 1725389 | 1712483 | -0.7% |
| random_size_align_alloc_test | 2192646 | 2215064 | +1.0% |
| pcpu_alloc_test | 50354 | 51911 | +3.1% |
| Total cycles | 57494755150 | 57703906913 | +0.4% |
+------------------------------+-------------+-------------+--------+
> You diligently went through the Sashiko report against v3 (thanks).
> Please pass an eye across its v4 report, see if something new popped
> up?
> https://sashiko.dev/#/patchset/20260618084726.1070022-1-jiangwen6@xiaomi.com
>
I've gone through the Sashiko findings:
- Patch 5 (CONFIG_HAVE_ARCH_HUGE_VMAP): Over-interpretation.
CONFIG_HAVE_ARCH_HUGE_VMAP is correct — it gates
arch_vmap_pmd_supported() and arch_vmap_pte_supported_shift() which
this code calls.
- Patch 5 (__ffs(page_to_pfn())): Over-interpretation. Never appears.
- Patch 6 (GFP_KERNEL triggering reclaim on alignment failure):
Over-interpretation. The same GFP_KERNEL is used by the
existing get_vm_area_caller() — no behavioral change.
Best Regards,
Wen
^ permalink raw reply
* Re: [PATCH v3 2/2] i2c: cadence: Add support for Axiado AX3000
From: Michal Simek @ 2026-07-02 6:35 UTC (permalink / raw)
To: Swark Yang, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-i2c, devicetree, linux-kernel, openbmc
In-Reply-To: <20260630-axiado-ax3000-cadence-i2c-support-v3-2-4e217cfe5904@axiado.com>
On 7/1/26 06:48, Swark Yang wrote:
> The Axiado AX3000 SoC integrates a Cadence I2C controller
> that supports SMBus Quick commands.
>
> Introduce the "axiado,ax3000-i2c" compatible string and
> add a new quirk CDNS_I2C_ENABLE_SMBUS_QUICK to enable
> this functionality. This allows the controller to support
> I2C_FUNC_SMBUS_QUICK, enabling features such as bus scanning
> via quick write commands.
>
> Additionally, enabling SMBus Quick emulation in the I2C core exposes
> the controller to potential 0-length reads. Because the Cadence IP
> does not natively support 0-length reads (writing 0 to the transfer
> size register leaves the hardware in an unsupported state), this patch
> also populates the adapter quirks with I2C_AQ_NO_ZERO_LEN_READ.
nit: Avoid "this patch". Just use ", populate ..."
> This ensures 0-length reads are safely rejected by the core, preventing
> potential bus hangs.
>
> Signed-off-by: Swark Yang <syang@axiado.com>
> ---
> drivers/i2c/busses/i2c-cadence.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
> index 0fb728ade92e..1964ea1650c5 100644
> --- a/drivers/i2c/busses/i2c-cadence.c
> +++ b/drivers/i2c/busses/i2c-cadence.c
> @@ -128,6 +128,7 @@
> #define CDNS_I2C_TIMEOUT_MAX 0xFF
>
> #define CDNS_I2C_BROKEN_HOLD_BIT BIT(0)
> +#define CDNS_I2C_ENABLE_SMBUS_QUICK BIT(1)
> #define CDNS_I2C_POLL_US 100000
> #define CDNS_I2C_POLL_US_ATOMIC 10
> #define CDNS_I2C_TIMEOUT_US 500000
> @@ -1175,10 +1176,14 @@ static int cdns_i2c_master_xfer_atomic(struct i2c_adapter *adap, struct i2c_msg
> */
> static u32 cdns_i2c_func(struct i2c_adapter *adap)
> {
> + struct cdns_i2c *id = adap->algo_data;
> u32 func = I2C_FUNC_I2C | I2C_FUNC_10BIT_ADDR |
> (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK) |
> I2C_FUNC_SMBUS_BLOCK_DATA;
>
> + if (id->quirks & CDNS_I2C_ENABLE_SMBUS_QUICK)
> + func |= I2C_FUNC_SMBUS_QUICK;
> +
> #if IS_ENABLED(CONFIG_I2C_SLAVE)
> func |= I2C_FUNC_SLAVE;
> #endif
> @@ -1442,9 +1447,24 @@ static const struct cdns_platform_data r1p10_i2c_def = {
> .quirks = CDNS_I2C_BROKEN_HOLD_BIT,
> };
>
> +static const struct cdns_platform_data ax3000_i2c_def = {
> + .quirks = CDNS_I2C_ENABLE_SMBUS_QUICK,
> +};
> +
> +/*
> + * The controller does not support zero-length reads. Enabling SMBus Quick
> + * commands would otherwise let the core emulate a Quick read as a zero-length
> + * read message, which writes 0 to the transfer size register and leaves the
> + * hardware in an unsupported state. Reject such transfers in the core.
> + */
> +static const struct i2c_adapter_quirks cdns_i2c_quirks = {
> + .flags = I2C_AQ_NO_ZERO_LEN_READ,
> +};
> +
> static const struct of_device_id cdns_i2c_of_match[] = {
> { .compatible = "cdns,i2c-r1p10", .data = &r1p10_i2c_def },
> { .compatible = "cdns,i2c-r1p14",},
> + { .compatible = "axiado,ax3000-i2c", .data = &ax3000_i2c_def },
> { /* end of table */ }
> };
> MODULE_DEVICE_TABLE(of, cdns_i2c_of_match);
> @@ -1510,6 +1530,9 @@ static int cdns_i2c_probe(struct platform_device *pdev)
> id->quirks = data->quirks;
> }
>
> + if (id->quirks & CDNS_I2C_ENABLE_SMBUS_QUICK)
> + id->adap.quirks = &cdns_i2c_quirks;
> +
> id->rinfo.pinctrl = devm_pinctrl_get(&pdev->dev);
> if (IS_ERR(id->rinfo.pinctrl)) {
> int err = PTR_ERR(id->rinfo.pinctrl);
>
Wiring looks good to me.
Acked-by: Michal Simek <michal.simek@amd.com>
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: arm: rockchip: Add Graperain G3568 series
From: Krzysztof Kozlowski @ 2026-07-02 6:33 UTC (permalink / raw)
To: Coia Prant
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Dragan Simic, Jonas Karlman, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260701164543.3967388-7-coiaprant@gmail.com>
On Thu, Jul 02, 2026 at 12:45:45AM +0800, Coia Prant wrote:
> Document the Graperain G3568 v2, which is a development board based on
> the Rockchip RK3568 SoC.
>
> Graperain G3568 series also have an SBC series with the suffix "box".
>
> Graperain G3568 v2 belongs to development board series, not SBC series.
>
> Link: https://www.graperain.cn/RK3568/RK3568-Development/ (China)
> Link: https://www.graperain.com/ARM-Embedded-RK3568-Development-Board/ (Global)
> Link: https://image.chukouplus.com/upload/C_153/product_file/20211022/6daddec9e400458816dd4c57ba807fc3.pdf
>
> Signed-off-by: Coia Prant <coiaprant@gmail.com>
> ---
> Documentation/devicetree/bindings/arm/rockchip.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 05/19] ARM: turn CONFIG_ATAGS off by default
From: Arnd Bergmann @ 2026-07-02 6:31 UTC (permalink / raw)
To: Ethan Nelson-Moore, Arnd Bergmann
Cc: linux-arm-kernel, soc, linux-kernel, Aaro Koskinen, A. Sverdlin,
Alexandre Belloni, Alexandre Torgue, Andrew Lunn, Ard Biesheuvel,
Claudiu Beznea, Daniel Mack, Frank Li, Gregory Clement,
Haojian Zhuang, Jeremy J. Peper, Kristoffer Ericson,
Krzysztof Kozlowski, Linus Walleij, Mark Brown, Marc Zyngier,
Mike Rapoport, Nicolas Ferre, Patrice Chotard, Ralph Siemsen,
Robert Jarzmik, Russell King, Sascha Hauer, Sebastian Hesselbarth,
Stefan Agner, Stefan Wiehler, Tony Lindgren, Vladimir Zapolskiy,
Will Deacon, Linus Walleij
In-Reply-To: <CADkSEUhif4s5sSHe-bMapxEiM4bksaNkS+R5EtWOV2kgsk-29w@mail.gmail.com>
On Thu, Jul 2, 2026, at 00:22, Ethan Nelson-Moore wrote:
>> --- a/arch/arm/configs/stm32_defconfig
>> +++ b/arch/arm/configs/stm32_defconfig
>> @@ -20,7 +20,8 @@ CONFIG_ARCH_STM32=y
>> CONFIG_CPU_V7M_NUM_IRQ=240
>> CONFIG_SET_MEM_PARAM=y
>> CONFIG_DRAM_BASE=0x90000000
>> -# CONFIG_ATAGS is not set
>> +CONFIG_FLASH_MEM_BASE=0x08000000
>> +CONFIG_FLASH_SIZE=0x00200000
>
> ^ These shouldn't be here - they depend on CPU_ARM740T || CPU_ARM946E
> || CPU_ARM940T, and they were manually removed previously. If they got
> added when you did make savedefconfig, I'm not sure why, given that
> dependency.
This likely happened during a rebase
> Reviewed-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> (assuming
> these issues are fixed)
Thanks, fixed all now for v3
Arnd
^ permalink raw reply
* Re: [PATCH v4 1/7] dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via NVMEM
From: Krzysztof Kozlowski @ 2026-07-02 6:16 UTC (permalink / raw)
To: Manikandan Muralidharan
Cc: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, nicolas.ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, linusw,
arnd, michael, linux-mtd, devicetree, linux-kernel,
linux-arm-kernel, netdev
In-Reply-To: <20260630092406.150587-2-manikandan.m@microchip.com>
On Tue, Jun 30, 2026 at 02:54:00PM +0530, Manikandan Muralidharan wrote:
> Add an optional "sfdp" child node (compatible "jedec,sfdp") that
> describes the SFDP as a read-only NVMEM provider via nvmem.yaml, so its
What is SFDP?
> contents (e.g. a vendor EUI-48/EUI-64) can be read through NVMEM cells.
>
> Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
> ---
> .../devicetree/bindings/mtd/jedec,spi-nor.yaml | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> index 587af4968255..98fd954598ab 100644
> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
> @@ -103,6 +103,20 @@ properties:
> spi-cpol: true
> spi-cpha: true
>
> + sfdp:
> + $ref: /schemas/nvmem/nvmem.yaml#
> + unevaluatedProperties: false
> + description:
> + The Serial Flash Discoverable Parameters (SFDP) tables exposed as a
> + read-only NVMEM device. This allows standard or vendor-specific SFDP
> + data (for example a factory-programmed EUI-48/EUI-64 identifier) to be
> + consumed through NVMEM cells.
> + properties:
> + compatible:
> + const: jedec,sfdp
> + required:
> + - compatible
Where are any resources? What sort of sub-device is represented here by
an empty device node?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 net-next 1/2] dt-bindings: phy: cadence-torrent: Update property values to support 3 clocks
From: Krzysztof Kozlowski @ 2026-07-02 6:23 UTC (permalink / raw)
To: Gokul Praveen
Cc: conor+dt, devicetree, krzk+dt, linux-arm-kernel, linux-kernel,
linux-phy, neil.armstrong, nm, robh, sjakhade, kristo, vigneshr,
vkoul, yamonkar
In-Reply-To: <20260701142457.81874-2-g-praveen@ti.com>
On Wed, Jul 01, 2026 at 07:54:56PM +0530, Gokul Praveen wrote:
> Update maxItems value of "clocks" property to 3 as description of
> this parameter already indicates 3 clocks(refclk,pll1_refclk(optional)
> and phy_en_refclk(optional)).
But what if description is wrong? You need to provide rationale why you
are doing it and you cannot use existing code alone as that rationale,
because as you pointed out - existing code is not fully correct.
>
> Update the maxItems and items value of "clock-names" property with multiple
> combination of clock-names possible since pll1_refclk and phy_en_refclk are
> optional clocks.
Why? You need to describe why you are doing this, not what you are
doing.
>
> Signed-off-by: Gokul Praveen <g-praveen@ti.com>
> ---
> .../bindings/phy/phy-cadence-torrent.yaml | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> index 9af39b33646a..96c664d50629 100644
> --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> @@ -34,7 +34,7 @@ properties:
>
> clocks:
> minItems: 1
> - maxItems: 2
> + maxItems: 3
> description:
> PHY input reference clocks - refclk (for PLL0) & pll1_refclk (for PLL1).
> pll1_refclk is optional and used for multi-protocol configurations requiring
> @@ -45,9 +45,17 @@ properties:
>
> clock-names:
> minItems: 1
> - items:
> - - const: refclk
> - - enum: [ pll1_refclk, phy_en_refclk ]
> + maxItems: 3
Drop
> + oneOf:
> + - items:
> + - const: refclk
> + - items:
> + - const: refclk
> + - enum: [ pll1_refclk, phy_en_refclk ]
Drop these, pointless. You were supposed to grow existing syntax.
> + - items:
> + - const: refclk
> + - const: pll1_refclk
So here is the enum.
> + - const: phy_en_refclk
And this stays.
You make changes which do not make the binding better and are not
explained in commit msg. Focus on WHY you are doing things and also
explain WHY you did such complicated syntax (if you insist on rewriting
correct code into something odd we do not expect).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net v2] net: airoha: fix MIB stats collection to be lossless
From: Aniket Negi @ 2026-07-02 6:21 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev,
linux-kernel, aniket.negi
In-Reply-To: <akWYEf5wusTq9_ol@lore-desk>
> > Signed-off-by: Aniket Negi <aniket.negi03@gmail.com>
>
> Hi Aniket,
>
> just few nits inline. Fixing them:
>
> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
Ok sure. I'll update.
> > + dev->stats.mib_prev.tx_runt_cnt = val;
> > +
> > + /* tx_len[0]: RUNT (32-bit, delta) + E64 (64-bit, absolute) → {0, 64} bucket.
> > + * Accumulate RUNT delta in tx_runt_accum64, then assign tx_len[0] as
> > + * accum + E64_abs so each call gives the correct combined total.
> > + */
>
> no new-line here.
>
> > +
> > + dev->stats.tx_len[i] = dev->stats.mib_prev.tx_runt_accum64;
>
Sure, You are reffering to both the spaces above and below comment section?. Same for rx_runt and rx_long/tx_long.
I'll update as following:
+ dev->stats.mib_prev.tx_runt_cnt = val;
+ /* tx_len[0]: RUNT (32-bit, delta) + E64 (64-bit, absolute) → {0, 64} bucket.
+ * Accumulate RUNT delta in tx_runt_accum64, then assign tx_len[0] as
+ * accum + E64_abs so each call gives the correct combined total.
+ */
+ dev->stats.tx_len[i] = dev->stats.mib_prev.tx_runt_accum64;
> > + u32 tx_drops;
> > + u32 tx_broadcast;
> > + u32 tx_multicast;
> > + u32 tx_runt_cnt;
>
> u32 tx_runt;
>
> > + u32 tx_long_cnt;
>
> u32 tx_long;
>
> > + u64 tx_runt_accum64;
>
> 64 tx_runt64;
>
> > + u32 rx_drops;
> > + u32 rx_broadcast;
> > + u32 rx_multicast;
> > + u32 rx_errors;
> > + u32 rx_crc_error;
> > + u32 rx_over_errors;
> > + u32 rx_fragment;
> > + u32 rx_jabber;
> > + u32 rx_runt_cnt;
>
> u32 rx_runt;
>
> > + u32 rx_long_cnt;
>
> u32 rx_long;
>
> > + u64 rx_runt_accum64;
>
> u64 rx_runt64;
>
> > + } mib_prev;
> > };
Acked the change name from tx_runt_cnt to tx_run, tx_long_cnt to tx_long, tx_runt_accum64 to tx_runt64. Same for rx counters.
Best Regards,
Aniket Negi
^ permalink raw reply
* Re: [PATCH 0/5] Backport ARM64 VHE boot fixes to 6.6.y
From: Greg KH @ 2026-07-02 6:16 UTC (permalink / raw)
To: Colton Lewis
Cc: stable, Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
James Morse, Suzuki K Poulose, Zenghui Yu, Mingwei Zhang,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <20260701204342.2654385-1-coltonlewis@google.com>
On Wed, Jul 01, 2026 at 08:43:37PM +0000, Colton Lewis wrote:
> This series backports VHE CPU boot fixes to the 6.6.y stable branch.
>
> These fixes are already present in the 6.12.y stable branch (and
> newer), but are missing in 6.6.y. They are required to enable booting
> L1 guests with nested virtualization enabled (kvm-arm.mode=nested).
>
> Without these patches, a 6.6.y guest boots with HCR_EL2.E2H
> incorrectly configured (because it misses VHE-only detection or early
> initialization), causing early boot hangs/trap loops.
Why is this needed for 6.6.y? Why not just use 6.12.y and newer for
systems that require this new feature? What is preventing that from
happening?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 1/7] dt-bindings: mtd: jedec,spi-nor: allow the SFDP to be exposed via NVMEM
From: Manikandan.M @ 2026-07-02 6:13 UTC (permalink / raw)
To: linusw, michael
Cc: pratyush, mwalle, takahiro.kuwano, miquel.raynal, richard,
vigneshr, robh, krzk+dt, conor+dt, srini, Nicolas.Ferre,
alexandre.belloni, claudiu.beznea, linux, richardcochran, arnd,
linux-mtd, devicetree, linux-kernel, linux-arm-kernel, netdev
In-Reply-To: <CAD++jLntmnwU3gAQfDn2nd4CQ_7HY6S_kBguVtZvVT1PktFCPw@mail.gmail.com>
On 7/1/26 4:23 PM, Linus Walleij wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> On Wed, Jul 1, 2026 at 10:34 AM Michael Walle <michael@walle.cc> wrote:
>
>> If I'm correct, this is the old style, see commit bd912c991d2e
>> ("dt-bindings: nvmem: layouts: add fixed-layout"). So it should
>> eventually look like:
>>
>> sfdp {
>> compatible = "jedec,sfdp";
> (...)
>> Also I'm not sure if we really need to add the "nvmem-cells" here.
>> IIRC in MTD it was there to tell a driver to add an nvmem device to
>> an already existing compatible/node.
>>
>> Apart from the MTD case, I've just found qcom,smem-part,yaml which
>> has compatible = "nvmem-cells".
>
> You're right, I was using old information, discard my comments...
> Reviewed-by: Linus Walleij <linusw@kernel.org>
>
> I think my comment in the driver to check for the compatible
> instead of the node name is still valid though.
Thank you Linus Wallejj and Michael.
I will address the driver changes in the next version.
>
> Yours,
> Linus Walleij
--
Thanks and Regards,
Manikandan M.
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
From: Krzysztof Kozlowski @ 2026-07-02 6:09 UTC (permalink / raw)
To: Markus Probst, Alexandre Belloni
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, linux-arm-kernel, linux-rtc, devicetree,
linux-kernel
In-Reply-To: <74b32ed0a700e3900c0f34d730b2b5b69eb2ca19.camel@posteo.de>
On 01/07/2026 19:08, Markus Probst wrote:
> On Wed, 2026-07-01 at 18:48 +0200, Alexandre Belloni wrote:
>> On 01/07/2026 16:43:07+0000, Markus Probst wrote:
>>> On Wed, 2026-07-01 at 17:14 +0200, Krzysztof Kozlowski wrote:
>>>> On 01/07/2026 15:25, Markus Probst wrote:
>>>>>>> +
>>>>>>> +maintainers:
>>>>>>> + - Alexandre Belloni <alexandre.belloni@bootlin.com>
>>>>>>
>>>>>> This should be someone caring about this hardware.
>>>>> He does have the majority of commits on this driver (excluding merge
>>>>> commits and commits not exclusive to this driver), although most of
>>>>> them are pretty tiny.
>>>>>
>>>>> Who would you suggest instead?
>>>>
>>>> Someone adding features for this driver, maybe driver maintainers. But
>>>> if Alexandre is fine, you can leave him.
>>>>
>>>>>>
>>>>>>> +
>>>>>>> +description:
>>>>>>> + The S-35390A is a CMOS 2-wire real-time clock IC which operates with the
>>>>>>> + very low current consumption in the wide range of operation voltage.
>>>>>>> +
>>>>>>> +allOf:
>>>>>>> + - $ref: rtc.yaml#
>>>>>>> +
>>>>>>> +properties:
>>>>>>> + compatible:
>>>>>>> + const: sii,s35390a
>>>>>>> +
>>>>>>> + reg:
>>>>>>> + maxItems: 1
>>>>>>> +
>>>>>>> + sii,wakealarm-output-pin:
>>>>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>>>>> + enum: [1, 2]
>>>>>>> + description: |
>>>>>>> + The output pin to wake up the system.
>>>>>>> + Default will use the output pin for interrupt signal 2.
>>>>>>> + <S35390A_OUTPUT_PIN_INT1> : Output pin for interrupt signal 1
>>>>>>> + <S35390A_OUTPUT_PIN_INT2> : Output pin for interrupt signal 2
>>>>>>
>>>>>> Does that mean device generates the interrupts?
>>>>> Yes.
>>>>>
>>>>
>>>>
>>>> Then I think you miss interrupts property.
>>> From what I can tell the line is used to generate a system wakeup
>>> event.
>>>
>>> There would be no obvious benefit of connecting it to an interrupt
>>> controller, so this property would be obsolete?
>>>
>>
>> Then you need proper wakeup-source support
> Wouldn't that break existing devicetrees?
How?
>
> The current driver allows to wake up the system, even without
> having wakeup-source set.
Anyway, wakeup-source is already there in rtc, so this would be done. I
don't get though, why there is no benefit of routing it to interrupt
controller (interrupt controllers do wake up the system). Additionally,
if you do not connect it to any interrupt, then how does it wake up the
system?
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