* [PATCH v15 02/28] drm/display: hdmi-state-helper: Use default case for unsupported formats
From: Nicolas Frattaroli @ 2026-05-22 12:31 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, 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, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Cristian Ciocaltea
In-Reply-To: <20260522-color-format-v15-0-21fb136c9df2@collabora.com>
Switch statements that do not handle all possible values of an
enumeration will generate a warning during compilation. In preparation
for adding a COUNT value to the end of the enum, this needs to be dealt
with.
Add a default case to sink_supports_format_bpc's DRM_OUTPUT_COLOR_FORMAT
switch statement, and move the log-and-return unknown pixel format
handling into it.
No functional change.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
index 4867edbf2622..3ba47564caad 100644
--- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
@@ -541,10 +541,11 @@ sink_supports_format_bpc(const struct drm_connector *connector,
drm_dbg_kms(dev, "YUV444 format supported in that configuration.\n");
return true;
- }
- drm_dbg_kms(dev, "Unsupported pixel format.\n");
- return false;
+ default:
+ drm_dbg_kms(dev, "Unsupported pixel format.\n");
+ return false;
+ }
}
static enum drm_mode_status
--
2.54.0
^ permalink raw reply related
* [PATCH v15 01/28] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
From: Nicolas Frattaroli @ 2026-05-22 12:31 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, 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, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel,
Nicolas Frattaroli, Werner Sembach, Andri Yngvason
In-Reply-To: <20260522-color-format-v15-0-21fb136c9df2@collabora.com>
From: Werner Sembach <wse@tuxedocomputers.com>
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.
Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI,
there is no reason to use RGB when the display
reports drm_mode_is_420_only() even on a non HDMI connection.
This patch also moves both checks in the same if-case. This eliminates an
extra else-if-case.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Andri Yngvason <andri@yngvason.is>
Tested-by: Andri Yngvason <andri@yngvason.is>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index ba7f98a87808..dfe97897127c 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6917,12 +6917,9 @@ static void fill_stream_properties_from_drm_display_mode(
timing_out->v_border_top = 0;
timing_out->v_border_bottom = 0;
/* TODO: un-hardcode */
- if (drm_mode_is_420_only(info, mode_in)
- && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
- timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
- else if (drm_mode_is_420_also(info, mode_in)
- && aconnector
- && aconnector->force_yuv420_output)
+ if (drm_mode_is_420_only(info, mode_in) ||
+ (aconnector && aconnector->force_yuv420_output &&
+ drm_mode_is_420_also(info, mode_in)))
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
else if ((connector->display_info.color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422))
&& aconnector
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] crypto: atmel - use min3 to simplify atmel_sha_append_sg
From: Herbert Xu @ 2026-05-22 12:28 UTC (permalink / raw)
To: Thorsten Blum
Cc: David S. Miller, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
linux-crypto, linux-arm-kernel, linux-kernel
In-Reply-To: <20260512145123.303311-3-thorsten.blum@linux.dev>
On Tue, May 12, 2026 at 04:51:24PM +0200, Thorsten Blum wrote:
> Replace two consecutive min() calls with min3() to simplify the code.
>
> And since count is unsigned and cannot be less than zero, adjust the if
> check and update the comment accordingly.
>
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> ---
> drivers/crypto/atmel-sha.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2] net: stmmac: mmc: Remove duplicate mmc_rx crc
From: Andrew Lunn @ 2026-05-22 12:14 UTC (permalink / raw)
To: Abid Ali
Cc: alexandre.torgue, andrew+netdev, davem, edumazet, kuba,
linux-arm-kernel, linux-kernel, linux-stm32, mcoquelin.stm32,
netdev, pabeni
In-Reply-To: <20260522065434.6231-1-dev.taqnialabs@gmail.com>
On Fri, May 22, 2026 at 06:54:34AM +0000, Abid Ali wrote:
> On Thu, May 21, 2026 at 20:44:53 +0200, Andrew Lunn wrote:
> > Thanks for the updated commit message.
> >
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
>
> Much appreciated.
>
> Should I send a v3 with the Reviewed-by trailer added ?
No need. patchworks will pick it up when the Maintainer applies the
patch. You only need to append it if you need to send a new version of
the patch.
Andrew
^ permalink raw reply
* [PATCH] stm: p_sys-t: Fix su_mutex held across wrong region in interval stores
From: Yingchao Deng @ 2026-05-22 12:08 UTC (permalink / raw)
To: Alexander Shishkin, Maxime Coquelin, Alexandre Torgue,
Greg Kroah-Hartman
Cc: linux-arm-kernel, linux-kernel, quic_yingdeng, jie.gan,
jinlong.mao, tingwei.zhang, Yingchao Deng
subsys->su_mutex is used here to serialize attribute stores against
pdrv->output_open(), which copies the policy node under that mutex:
stp_policy_node_lookup() /* acquires su_mutex, returns holding it */
stm_output_assign()
pdrv->output_open() /* memcpy(&op->node, pn, ...) */
stp_policy_node_put() /* releases su_mutex */
The comment in stm_assign_first_policy() (core.c) makes the intent
explicit: "This allows the pdrv->output_open() in stm_output_assign()
to serialize against the attribute accessors."
sys_t_policy_ts_interval_store() and
sys_t_policy_clocksync_interval_store() however acquired su_mutex
only around the kstrtouint() parse step, a pure local-variable
operation with no shared state. The actual writes to pn->ts_interval
and pn->clocksync_interval were left outside the critical section,
defeating the serialization entirely.
Move the mutex_lock/unlock to bracket the pn field assignment instead.
Fixes: d69d5e83110f ("stm class: Add MIPI SyS-T protocol support")
Fixes: 39f10239df75 ("stm class: p_sys-t: Add support for CLOCKSYNC packets")
Signed-off-by: Yingchao Deng <yingchao.deng@oss.qualcomm.com>
---
drivers/hwtracing/stm/p_sys-t.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/hwtracing/stm/p_sys-t.c b/drivers/hwtracing/stm/p_sys-t.c
index bcbbc4d92325..077b62ca3f46 100644
--- a/drivers/hwtracing/stm/p_sys-t.c
+++ b/drivers/hwtracing/stm/p_sys-t.c
@@ -210,12 +210,11 @@ sys_t_policy_ts_interval_store(struct config_item *item, const char *page,
unsigned int ms;
int ret;
- mutex_lock(mutexp);
ret = kstrtouint(page, 10, &ms);
- mutex_unlock(mutexp);
-
if (!ret) {
+ mutex_lock(mutexp);
pn->ts_interval = msecs_to_jiffies(ms);
+ mutex_unlock(mutexp);
return count;
}
@@ -241,12 +240,12 @@ sys_t_policy_clocksync_interval_store(struct config_item *item,
unsigned int ms;
int ret;
- mutex_lock(mutexp);
ret = kstrtouint(page, 10, &ms);
- mutex_unlock(mutexp);
if (!ret) {
+ mutex_lock(mutexp);
pn->clocksync_interval = msecs_to_jiffies(ms);
+ mutex_unlock(mutexp);
return count;
}
---
base-commit: 80dd246accce631c328ea43294e53b2b2dd2aa32
change-id: 20260521-stm-bd597d74ee6d
Best regards,
--
Yingchao Deng <yingdeng@qti.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH 5/5] arm64: dts: freescale: add DT overlay for MX95-15x15-FRDM RPMSG usage
From: Daniel Baluta @ 2026-05-22 12:11 UTC (permalink / raw)
To: Laurentiu Mihalcea, Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-6-laurentiumihalcea111@gmail.com>
On 5/22/26 14:18, Laurentiu Mihalcea wrote:
> From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
>
> Add RPMSG DT overlay for the MX95-15x15-FRDM board. This overlay is meant
> to be used with the mx95evkrpmsg system manager configuration for
> remoteproc and audio over rpmsg-usecases.
>
> Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/Makefile | 3 +
> .../dts/freescale/imx95-15x15-frdm-rpmsg.dtso | 65 +++++++++++++++++++
> 2 files changed, 68 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
>
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 513f61eb27b8..a30a99e42426 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -521,6 +521,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx943-evk-pcie0-ep.dtb imx943-evk-pcie1-ep.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-ab2.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm-rpmsg.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
> @@ -539,6 +540,8 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-mallow.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-yavia.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-zinnia.dtb
>
> +imx95-15x15-frdm-rpmsg-dtbs = imx95-15x15-frdm.dtb imx95-15x15-frdm-rpmsg.dtbo
> +
> imx95-15x15-evk-pcie-dtbs += imx95-15x15-evk.dtb imx-m2-pcie.dtbo
> dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk-pcie.dtb
>
> diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
> new file mode 100644
> index 000000000000..b39444dde66e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
> @@ -0,0 +1,65 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright 2026 NXP
> + *
> + * This DT overlay is meant to be used alongside the mx95evkrpmsg SM
> + * configuration for remoteproc and audio over rpmsg.
> + */
> +
> +/dts-v1/;
> +/plugin/;
> +
> +&{/} {
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + vdev0vring0: memory@88000000 {
> + reg = <0 0x88000000 0 0x8000>;
> + no-map;
> + };
> +
> + vdev0vring1: memory@88008000 {
> + reg = <0 0x88008000 0 0x8000>;
> + no-map;
> + };
> +
> + vdev0buffer: memory@88020000 {
> + compatible = "shared-dma-pool";
> + reg = <0 0x88020000 0 0x100000>;
> + no-map;
> + };
> +
> + rsc_table: memory@88220000 {
> + reg = <0 0x88220000 0 0x1000>;
> + no-map;
> + };
> + };
> +
> + sound-micfil {
> + status = "disabled";
> + };
> +};
> +
> +&cm7 {
> + memory-region = <&vdev0buffer>, <&vdev0vring0>,
> + <&vdev0vring1>, <&rsc_table>;
> + memory-region-names = "vdev0buffer", "vdev0vring0",
> + "vdev0vring1", "rsc-table";
> + status = "okay";
> +};
> +
> +&edma1 {
> + /* reserved for M7 */
> + dma-channel-mask = <0x40>;
> +};
> +
> +&edma2 {
> + /* reserved for M7 and V2X */
> + dma-channel-mask = <0xf>;
> +};
> +
> +&micfil {
> + /* reserved for M7 */
> + status = "disabled";
> +};
For this usecase usually status needs to be set to "reserved".
Otherwise,
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: aspeed: Enable networking for Asus Kommando IPMI Card
From: Andrew Lunn @ 2026-05-22 12:05 UTC (permalink / raw)
To: Anirudh Srinivasan
Cc: Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Joel Stanley
In-Reply-To: <CAJ13v3RtV+_P_ShfrM5vH+neT0cB6t5yAbqGiiw7S7Y8qpVY=Q@mail.gmail.com>
On Thu, May 21, 2026 at 10:49:24PM -0500, Anirudh Srinivasan wrote:
> Hi Andrew,
>
> On Tue, Mar 31, 2026 at 9:18 AM Anirudh Srinivasan
> <anirudhsriniv@gmail.com> wrote:
> >
> > Adds the DT nodes needed for ethernet support for Asus Kommando, with
> > phy mode set to rgmii-id.
> >
> > When this DT was originally added, the phy mode was set to rgmii (which
> > was incorrect). It was suggested to remove networking support from the
> > DT till the Aspeed networking driver was patched so that the correct phy
> > mode could be used.
> >
> > The discussion in [1] mentions that u-boot was inserting clk delays that
> > weren't needed, which resulted in needing to set the phy mode in linux
> > to rgmii incorrectly. The solution suggested there was to patch u-boot to
> > no longer insert these clk delays and use rgmii-id as the phy mode for
> > any future DTs added to linux.
> >
> > This DT was tested (on the OpenBMC u-boot fork [2]) with a u-boot DT
> > modified to insert clk delays of 0 (instead of patching u-boot itself).
> > [3] adds a u-boot DT for this device (without networking) and describes
> > how to patch it to add networking support. If this patched DT is used,
> > then networking works with rgmii-id phy mode in both u-boot and linux.
> >
> > [1] https://lore.kernel.org/linux-aspeed/ef88bb50-9f2c-458d-a7e5-dc5ecb9c777a@lunn.ch/
> > [2] https://github.com/openbmc/u-boot/tree/v2019.04-aspeed-openbmc
> > [3] https://lore.kernel.org/openbmc/20260328-asus-kommando-v2-1-2a656f8cd314@gmail.com/
> >
> > Signed-off-by: Anirudh Srinivasan <anirudhsriniv@gmail.com>
> > ---
> > This patch is based off aspeed/arm/dt from bmc tree
> > ---
> > Changes in v2:
> > - Commit message now mentions that the u-boot tested against is the
> > openbmc u-boot fork
> > - Link to v1: https://lore.kernel.org/r/20260328-asus-kommando-networking-v1-1-66d308b88536@gmail.com
> > ---
> > .../dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
> > index ab7ad320067c1ddc0fea9ac386fd488c8ef28184..e0f7d92efa18ccbad2c336236c3b9d01b7de1bba 100644
> > --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
> > +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
> > @@ -107,6 +107,24 @@ &gpio1 {
> > /*18E0 32*/ "","","","","","","","";
> > };
> >
> > +&mac2 {
> > + status = "okay";
> > +
> > + phy-mode = "rgmii-id";
> > + phy-handle = <ðphy2>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_rgmii3_default>;
> > +};
> > +
> > +&mdio2 {
> > + status = "okay";
> > +
> > + ethphy2: ethernet-phy@0 {
> > + compatible = "ethernet-phy-ieee802.3-c22";
> > + reg = <0>;
> > + };
> > +};
> > +
> > &vhub {
> > status = "okay";
> > };
> >
> > ---
> > base-commit: 76b4ec8efdc3887cdbf730da2e55881fc1a18770
> > change-id: 20260328-asus-kommando-networking-5c0612aa6b8c
> >
> > Best regards,
> > --
> > Anirudh Srinivasan <anirudhsriniv@gmail.com>
> >
>
> While we're figuring out what to do with u-boot, what are your
> thoughts on getting this patch in so that the kernel DTS changes
> needed for networking land in this cycle?
>
> The current commit message might become somewhat outdated if the
> u-boot patch changes though, so not sure if that's okay.
The commit message explains "Why?", which is what is important. So it
should not matter if it becomes outdated. And the DT is correct, no
matter how the issue is solved.
So i'm O.K. with this.
Andrew
^ permalink raw reply
* Re: [PATCH v4 4/6] media: synopsys: Add PHY stopstate wait for i.MX93
From: Alexander Stein @ 2026-05-22 12:02 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil, G.N. Zhou (OSS), G.N. Zhou (OSS),
G.N. Zhou (OSS)
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, G.N. Zhou (OSS)
In-Reply-To: <AS8PR04MB9080844E610F8E8012647B39FA0F2@AS8PR04MB9080.eurprd04.prod.outlook.com>
Hi,
Am Freitag, 22. Mai 2026, 03:58:56 CEST schrieb G.N. Zhou (OSS):
> > > Thanks for testing. Regarding the lane stop state error on i.MX93 with
> > imx327:
> > >
> > > This error indicates the CSI-2 lanes are not in LP-11 (stop) state
> > > when expected. Please check:
> > >
> > > 1) Verify the sensor PHY is in LP-11 state before returning from the sensor's
> > > s_stream(1) call. The CSI-2 receiver expects lanes to be in stop state
> > > initially.
> >
> > Well, this might be tricky as I don't have D-PHY capable scopes.
> > I can successfully use this sensor on a imx8mp, so I am expecting this to be
> > okay.
> >
> > > 2) Check if the imx327 driver has a delay between starting the stream and
> > > returning from s_stream(). If the sensor transitions PHY out of LP-11
> > > state during this delay, the CSI driver's lane state check will fail
> > > when it runs later. The sensor should remain in LP-11 until the CSI
> > > controller completes its initialization.
> >
> > In imx290_set_stream() and subsequently imx290_start_streaming() setting
> > IMX290_XMSTA starts the stream. I expect this is the point when the sensors
> > switches from LP-11 to HS. But again, I can't verify.
>
> As mentioned in #2, I reviewed drivers/media/i2c/imx290.c and identified a 30ms
> delay that appears to be the root cause of this issue.
>
> The problem occurs because:
>
> The sensor exits LP-11 state and transitions to HS mode after IMX290_XMSTA is written
> The 30ms delay in s_stream() causes the function to return late
> By the time the CSI controller performs its lane state check, the sensor has already switched
> from LP-11 to HS mode, causing the check to fail。
This sounds wrong, see below.
>
> Proposed fix:
>
> diff --git a/drivers/media/i2c/imx290.c b/drivers/media/i2c/imx290.c
> index 21cbc81cb2ed..519aa336249a 100644
> --- a/drivers/media/i2c/imx290.c
> +++ b/drivers/media/i2c/imx290.c
> @@ -1059,7 +1059,6 @@ static int imx290_start_streaming(struct imx290 *imx290,
>
> cci_write(imx290->regmap, IMX290_STANDBY, 0x00, &ret);
>
> - msleep(30);
>
> /* Start streaming */
> return cci_write(imx290->regmap, IMX290_XMSTA, 0x00, &ret);
>
> Removing this delay allows s_stream() to return immediately, giving the CSI controller
> time to complete its initialization before the sensor transitions PHY state.
>
> Could you test this patch and confirm if it resolves the lane state check failure?
Removing these 30ms does not fix the problem. Actually the delay change is
hardly measurable, as the i2c transfer take much more time. I added a message
for start/exit of imx290_enable_streams(). Just the transfers take >600ms.
--8<--
[ 40.507273] plane 0: bytesperline=3840 sizeimage=4147200
[ 40.512628] mxc-isi 4ae40000.isi: validating link "crossbar":2 -> "mxc_isi.0":0
[ 40.519945] mxc-isi 4ae40000.isi: validating stream "crossbar":2:0 -> "mxc_isi.0":0:0
[ 40.527789] mxc-isi 4ae40000.isi: validating link "dw-mipi-csi2rx 4ae00000.mipi-csi":1 -> "crossbar":0
[ 40.537105] mxc-isi 4ae40000.isi: validating stream "dw-mipi-csi2rx 4ae00000.mipi-csi":1:0 -> "crossbar":0:0
[ 40.546940] mxc-isi 4ae40000.isi: validating link "imx327 4-001a":0 -> "dw-mipi-csi2rx 4ae00000.mipi-csi":0
[ 40.556680] mxc-isi 4ae40000.isi: validating stream "imx327 4-001a":0:0 -> "dw-mipi-csi2rx 4ae00000.mipi-csi":0:0
[ 40.573332] mxc-isi 4ae40000.isi: enable streams "crossbar":2/0x1
[ 40.579446] mxc-isi 4ae40000.isi: collect_streams: "crossbar":2: found 0x1 enabled 0x0
[ 40.587373] imx290 4-001a: Frame descriptor on pad 0, type CSI-2
[ 40.593390] imx290 4-001a: stream 0, code 0x300f, length 0, flags 0x0000, vc 0, dt 0x2b
[ 40.601489] dw-mipi-csi2rx 4ae00000.mipi-csi: Frame descriptor on pad 1, type CSI-2
[ 40.609147] dw-mipi-csi2rx 4ae00000.mipi-csi: stream 0, code 0x300f, length 0, flags 0x0000, vc 0, dt 0x2b
[ 40.618894] mxc-isi 4ae40000.isi: enable streams "dw-mipi-csi2rx 4ae00000.mipi-csi":1/0x1
[ 40.627082] dw-mipi-csi2rx 4ae00000.mipi-csi: collect_streams: "dw-mipi-csi2rx 4ae00000.mipi-csi":1: found 0x1 enabled 0x0
[ 40.638184] mxc-isi 4ae40000.isi: enable streams "imx327 4-001a":0/0x1
[ 40.644728] imx290 4-001a: collect_streams: sub-device "imx327 4-001a" does not support streams
[ 40.653431] imx290 4-001a: imx290_enable_streams start
[ 41.294967] imx290 4-001a: imx290_enable_streams exit
[ 41.301064] dw-mipi-csi2rx 4ae00000.mipi-csi: lanes are not in stop state: 0x0, expected 0x10003
[ 41.309884] mxc-isi 4ae40000.isi: disable streams "imx327 4-001a":0/0x1
[ 41.316534] imx290 4-001a: collect_streams: sub-device "imx327 4-001a" does not support streams
[ 41.361401] mxc-isi 4ae40000.isi: enable streams 1:0x1 failed: -110
[ 41.367690] mxc-isi 4ae40000.isi: failed to enable streams 0x1 on 'dw-mipi-csi2rx 4ae00000.mipi-csi':1: -110
[ 41.379854] mxc-isi 4ae40000.isi: enable streams 2:0x1 failed: -110
[ 41.387325] mxc-isi 4ae40000.isi: Failed to enable pipe 0
[ 41.399231] video0: VIDIOC_STREAMON: error -110: type=vid-cap-mplane
[ 41.408340] videodev: v4l2_release: video0: release
--8<--
Given this I would ague the CSI host initialization order is wrong. The
documentation for enable_streams states:
> The struct v4l2_subdev_pad_ops->enable_streams() and struct
> v4l2_subdev_pad_ops->disable_streams() callbacks are used by the receiver driver
> to control the transmitter driver's streaming state.
So IMHO calling enable_streams it is expected the sensors switched to
HS mode. Unfortunately even checking PHY stopstate before enabling the subdev
streams does not fix this error message.
There is still
> dw-mipi-csi2rx 4ae00000.mipi-csi: lanes are not in stop state: 0x0, expected 0x10003
I also noticed that before the s_stream call (imx290_set_stream) call the
device is powered down. That might explaing that reversing the order will
not help.
Best regards,
Alexander
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply
* Re: [PATCH 02/10] dt-bindings: clock: Add Amlogic A9 PLL clock controller
From: Jian Hu @ 2026-05-22 11:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Jerome Brunet, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-kernel, linux-clk,
devicetree, linux-amlogic, linux-arm-kernel
In-Reply-To: <7c458070-a56a-4d49-89fc-efeb388beffc@kernel.org>
On 5/22/2026 5:16 PM, Krzysztof Kozlowski wrote:
> [ EXTERNAL EMAIL ]
>
> On 22/05/2026 08:20, Jian Hu wrote:
>> Hi Krzysztof,
>>
>> Thanks for your review.
>>
>> On 5/15/2026 4:09 PM, Krzysztof Kozlowski wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>> On Mon, May 11, 2026 at 08:47:24PM +0800, Jian Hu wrote:
>>>> Add the PLL clock controller dt-bindings for the Amlogic A9 SoC family.
>>>>
>>>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>>>> ---
>>>> .../bindings/clock/amlogic,a9-pll-clkc.yaml | 110 +++++++++++++++++++++
>>>> include/dt-bindings/clock/amlogic,a9-pll-clkc.h | 55 +++++++++++
>>>> 2 files changed, 165 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml b/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml
>>>> new file mode 100644
>>>> index 000000000000..4ee6013ba1a1
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/clock/amlogic,a9-pll-clkc.yaml
>>>> @@ -0,0 +1,110 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +# Copyright (C) 2026 Amlogic, Inc. All rights reserved
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/clock/amlogic,a9-pll-clkc.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Amlogic A9 Series PLL Clock Controller
>>>> +
>>>> +maintainers:
>>>> + - Neil Armstrong <neil.armstrong@linaro.org>
>>>> + - Jerome Brunet <jbrunet@baylibre.com>
>>>> + - Jian Hu <jian.hu@amlogic.com>
>>>> + - Xianwei Zhao <xianwei.zhao@amlogic.com>
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + enum:
>>>> + - amlogic,a9-gp0-pll
>>>> + - amlogic,a9-hifi0-pll
>>>> + - amlogic,a9-hifi1-pll
>>>> + - amlogic,a9-mclk0-pll
>>>> + - amlogic,a9-mclk1-pll
>>>> +
>>>> + reg:
>>>> + maxItems: 1
>>>> +
>>>> + '#clock-cells':
>>>> + const: 1
>>>> +
>>>> + clocks:
>>>> + items:
>>>> + - description: pll input oscillator gate
>>>> + - description: fixed input clock source for mclk_sel_0
>>>> + - description: u3p2pll input clock source for mclk_sel_0 (optional)
>>> Second clock is also optional. Drop "(optional)" comment, just
>>> confusing.
>>
>> GP0 has only one parent clock, while MCLK has three.
>>
>> The second and third parent entries of GP0 are vacant,
>>
>> so they need to be marked optional.
>>
>> I will add the optional property for the second clock in the next revision.
> How? Read the previous feedback...
>
> Best regards,
> Krzysztof
My apologies, I misunderstood your previous comment.
I will drop "(optional)" from the clock descriptions.
It will be updated as:
clocks:
items:
- description: pll input oscillator gate
- description: fixed input clock source for mclk_sel_0
- description: u3p2pll input clock source for mclk_sel_0
Best regards,
Jian
^ permalink raw reply
* Re: [PATCH v6 04/22] drm/display: scdc_helper: Add HDMI 2.0 scrambling management helpers
From: Cristian Ciocaltea @ 2026-05-22 11:42 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Sandy Huang,
Heiko Stübner, Andy Yan, Luca Ceresoli, Daniel Stone, kernel,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260521-chestnut-harrier-of-enhancement-2bcfa2@penduick>
On 5/21/26 11:10 AM, Maxime Ripard wrote:
> On Wed, May 20, 2026 at 09:38:15PM +0300, Cristian Ciocaltea wrote:
>> Add drm_scdc_start_scrambling(), drm_scdc_stop_scrambling() and
>> drm_scdc_sync_status() helpers to manage the full lifecycle of HDMI 2.0
>> SCDC scrambling on both source and sink sides.
>>
>> drm_scdc_start_scrambling() configures SCDC scrambling and high TMDS
>> clock ratio and starts a periodic work item that monitors the sink's
>> SCDC scrambling status, retrying setup when the sink loses state.
>>
>> drm_scdc_stop_scrambling() tears down scrambling on both sides and
>> cancels the monitoring work.
>>
>> drm_scdc_sync_status() triggers a CRTC reset on reconnection to restore
>> SCDC state lost during sink disconnects within an active display
>> pipeline.
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>> drivers/gpu/drm/display/drm_scdc_helper.c | 235 +++++++++++++++++++++++++++++-
>> include/drm/display/drm_scdc_helper.h | 6 +-
>> 2 files changed, 236 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/display/drm_scdc_helper.c b/drivers/gpu/drm/display/drm_scdc_helper.c
>> index cb6632346aad..5bacb886d373 100644
>> --- a/drivers/gpu/drm/display/drm_scdc_helper.c
>> +++ b/drivers/gpu/drm/display/drm_scdc_helper.c
>> @@ -21,16 +21,22 @@
>> * DEALINGS IN THE SOFTWARE.
>> */
>>
>> +#include <linux/delay.h>
>> #include <linux/export.h>
>> #include <linux/i2c.h>
>> +#include <linux/minmax.h>
>> #include <linux/slab.h>
>> -#include <linux/delay.h>
>>
>> -#include <drm/display/drm_scdc_helper.h>
>> +#include <drm/drm_atomic.h>
>> +#include <drm/drm_atomic_helper.h>
>> +#include <drm/drm_bridge_helper.h>
>> #include <drm/drm_connector.h>
>> +#include <drm/drm_crtc.h>
>> #include <drm/drm_device.h>
>> #include <drm/drm_print.h>
>>
>> +#include <drm/display/drm_scdc_helper.h>
>> +
>> /**
>> * DOC: scdc helpers
>> *
>> @@ -50,10 +56,14 @@
>> * has to track the connector status changes using interrupts and
>> * restore the SCDC status. The typical solution for this is to trigger an
>> * empty modeset in drm_connector_helper_funcs.detect_ctx(), like what vc4 does
>> - * in vc4_hdmi_reset_link().
>> + * in vc4_hdmi_reset_link(). Alternatively, use the HDMI connector framework
>> + * which ensures drm_scdc_sync_status() is called in the context of
>> + * drm_atomic_helper_connector_hdmi_hotplug_ctx().
>> */
>>
>> -#define SCDC_I2C_SLAVE_ADDRESS 0x54
>> +#define SCDC_I2C_SLAVE_ADDRESS 0x54
>> +#define SCDC_MAX_SOURCE_VERSION 0x1
>> +#define SCDC_STATUS_POLL_DELAY_MS 3000
>>
>> #define drm_scdc_dbg(connector, fmt, ...) \
>> drm_dbg_kms((connector)->dev, "[CONNECTOR:%d:%s] " fmt, \
>> @@ -270,3 +280,220 @@ bool drm_scdc_set_high_tmds_clock_ratio(struct drm_connector *connector,
>> return true;
>> }
>> EXPORT_SYMBOL(drm_scdc_set_high_tmds_clock_ratio);
>> +
>> +static int drm_scdc_setup_scrambler(struct drm_connector *connector)
>> +{
>> + bool done;
>> +
>> + done = drm_scdc_set_high_tmds_clock_ratio(connector, true);
>> + if (!done)
>> + return -EIO;
>> +
>> + done = drm_scdc_set_scrambling(connector, true);
>> + if (!done)
>> + return -EIO;
>> +
>> + schedule_delayed_work(&connector->hdmi.scdc_work,
>> + msecs_to_jiffies(SCDC_STATUS_POLL_DELAY_MS));
>> + return 0;
>> +}
>
> There's a very tight deadline in the spec to enable the scrambler
> relative to the video. Debouncing (I assume?) for three seconds break
> it. Drivers might not be able to do better, but it's really not
> something we should entertain at the framework level and we should call
> the callback straight-away.
In drm_scdc_start_scrambling() we call this function directly, the callback is
only meant to retry the call if the sink didn't set the scrambling for whatever
reason.
Or do you mean we shouldn't wait that long before retrying? vc4 uses 1s, I got
some mixed results in a few occasions and experimented with increased values,
but I'll revert or we can adjust to whatever you think it'd be more sensible.
>> +static void drm_scdc_monitor_scrambler(struct drm_connector *connector)
>> +{
>> + if (READ_ONCE(connector->hdmi.scrambler_enabled) &&
>> + !drm_scdc_get_scrambling_status(connector))
>> + drm_scdc_setup_scrambler(connector);
>> +}
>> +
>> +static int drm_scdc_reset_crtc(struct drm_connector *connector,
>> + struct drm_modeset_acquire_ctx *ctx)
>> +{
>> + struct drm_crtc *crtc;
>> + u8 config;
>> + int ret;
>> +
>> + if (!ctx || !connector->state)
>> + return 0;
>> +
>> + crtc = connector->state->crtc;
>> + if (!crtc || !crtc->state || !crtc->state->active)
>> + return 0;
>> +
>> + ret = drm_scdc_readb(connector->ddc, SCDC_TMDS_CONFIG, &config);
>> + if (ret) {
>> + drm_scdc_dbg(connector, "Failed to read TMDS config: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + if ((config & SCDC_SCRAMBLING_ENABLE) &&
>> + (config & SCDC_TMDS_BIT_CLOCK_RATIO_BY_40))
>> + return 0;
>> +
>> + /*
>> + * Reset the CRTC to suspend TMDS transmission, conforming to HDMI 2.0
>> + * spec which requires scrambled data not to be sent before the sink is
>> + * configured, and TMDS clock to be suspended while changing the clock
>> + * ratio. The disable/re-enable cycle triggered by the reset should
>> + * call drm_scdc_start_scrambling() during re-enable, properly
>> + * configuring the sink before data transmission resumes.
>> + */
>> +
>> + drm_scdc_dbg(connector, "Resetting CRTC to restore SCDC status\n");
>> +
>> + ret = drm_atomic_helper_reset_crtc(crtc, ctx);
>> + if (ret && ret != -EDEADLOCK)
>> + drm_scdc_dbg(connector, "Failed to reset CRTC: %d\n", ret);
>> +
>> + return ret;
>> +}
>
> locking is a bit more involved than that, I'd suggest to take
> vc4_hdmi_reset_link() and turn it into a helper.
The current non-NULL ctx call chain goes through drm_helper_probe_detect_ctx()
-> .detect_ctx -> ... -> drm_scdc_sync_status() -> drm_scdc_reset_crtc(), and
the connection mutex is already held by drm_helper_probe_detect() in that path.
I'll make the helper safe under any caller by taking the connection_mutex via
the supplied ctx, since re-acquiring it with the same context when it is already
held should be a no-op. Moreover, the racy crtc->state->active early out could
be dropped: when the CRTC is inactive, drm_atomic_helper_reset_crtc() should
result in a no-op commit anyway, so the check is at best an optimisation.
This mirrors what drm_bridge_helper_reset_crtc() does.
>> +/**
>> + * drm_scdc_start_scrambling - activate scrambling and monitor SCDC status
>> + * @connector: connector
>> + *
>> + * Enables scrambling and high TMDS clock ratio on both source and sink sides.
>> + * Additionally, use a delayed work item to monitor the scrambling status on
>> + * the sink side and retry the operation, as some displays refuse to set the
>> + * scrambling bit right away.
>> + *
>> + * Returns:
>> + * Zero if scrambling is set successfully, an error code otherwise.
>> + */
>> +int drm_scdc_start_scrambling(struct drm_connector *connector)
>> +{
>> + struct drm_display_info *info = &connector->display_info;
>> + struct drm_connector_hdmi *hdmi = &connector->hdmi;
>> + int ret;
>> + u8 ver;
>> +
>> + if (!hdmi->funcs ||
>> + !hdmi->funcs->scrambler_src_enable ||
>> + !hdmi->funcs->scrambler_src_disable) {
>> + drm_scdc_dbg(connector, "Function not implemented, bailing.\n");
>> + return -EINVAL;
>> + }
>
> This case shouldn't be a thing. The driver must not probe if it's not set.
When advertising DRM_BRIDGE_OP_HDMI_SCRAMBLER, drm_bridge_connector_init() will
fail if the scrambler hooks are not provided. However, the check would be still
useful if one missed to set DRM_BRIDGE_OP_HDMI_SCRAMBLER before adding the
bridge. I'll try to also handle non-bridge usecases - pls see the proposal
below.
>> + if (!info->is_hdmi ||
>> + !info->hdmi.scdc.supported ||
>> + !info->hdmi.scdc.scrambling.supported) {
>> + drm_scdc_dbg(connector, "Sink doesn't support scrambling.\n");
>> + return -EINVAL;
>> + }
>
> You should also compute whether we actually need to enable the scrambler
> here, based on the mode, format and bpc.
I'm thinking to mirror the existing supported_formats / ycbcr_420_allowed
plumbing:
- Add a 'scrambling_supported' flag to struct drm_connector_hdmi and let
drm_bridge_connector_init() to propagates it from the HDMI bridge before
calling drmm_connector_hdmi_init().
- drmm_connector_hdmi_init() validates that the capability is consistent with
the provided callbacks: when scrambling_supported is true, both
scrambler_src_enable() and scrambler_src_disable() must be provided.
- Add a 'scrambling_needed' flag to struct drm_connector_hdmi_state to be set by
hdmi_compute_clock() based on the TMDS character rate and the source/sink
scrambling capabilities.
- Ensure hdmi_clock_valid() rejects modes having TMDS character rate exceeding
340 MHz when either the source or the sink lacks the required SCDC scrambling
capability.
> I'd also like to see what a !bridge user of this would look like. The
> vc4 driver has all the infrastructure you need already, so converting it
> to it would be great.
Sure, will do. I've just ordered a RPI5 board, so I should be able to properly
validate this.
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH] media: rp1-cfe: Use IS_ERR() check for media_entity_remote_source_pad_unique()
From: Dave Stevenson @ 2026-05-22 10:14 UTC (permalink / raw)
To: Ingyu Jang
Cc: Tomi Valkeinen, Raspberry Pi Kernel Maintenance,
Mauro Carvalho Chehab, Florian Fainelli,
Broadcom internal kernel review list, linux-media,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260514193148.2357371-1-ingyujang25@korea.ac.kr>
On Thu, 14 May 2026 at 20:32, Ingyu Jang <ingyujang25@korea.ac.kr> wrote:
>
> * Spam *
> media_entity_remote_source_pad_unique() returns either a valid struct
> media_pad pointer or an error pointer (ERR_PTR(-ENOTUNIQ) or
> ERR_PTR(-ENOLINK)); it never returns NULL. The current NULL check
> therefore never triggers, and the "pad not connected" error path is
> unreachable.
>
> Replace the NULL check with an IS_ERR() check so the validation
> actually detects malformed media graphs.
>
> Signed-off-by: Ingyu Jang <ingyujang25@korea.ac.kr>
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
> ---
> drivers/media/platform/raspberrypi/rp1-cfe/cfe.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/raspberrypi/rp1-cfe/cfe.c b/drivers/media/platform/raspberrypi/rp1-cfe/cfe.c
> index 8375ed3e97b9f..91e9fa0341e06 100644
> --- a/drivers/media/platform/raspberrypi/rp1-cfe/cfe.c
> +++ b/drivers/media/platform/raspberrypi/rp1-cfe/cfe.c
> @@ -1779,7 +1779,7 @@ static int cfe_video_link_validate(struct media_link *link)
> link->source->entity->name, link->source->index,
> link->sink->entity->name, link->sink->index);
>
> - if (!media_entity_remote_source_pad_unique(link->sink->entity)) {
> + if (IS_ERR(media_entity_remote_source_pad_unique(link->sink->entity))) {
> cfe_err(cfe, "video node %s pad not connected\n", vd->name);
> return -ENOTCONN;
> }
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH 14/14] arm64: dts: imx8mp: add VC8000E encoder node
From: Fabio Estevam @ 2026-05-22 11:28 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, linux-media,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Nicolas Dufresne,
Benjamin Gaignard, Philipp Zabel, Mauro Carvalho Chehab,
Hans Verkuil, Marco Felsch, Michael Tretter
In-Reply-To: <20260522101653.2565125-15-paulk@sys-base.io>
Hi Paul,
Thanks for working on this.
On Fri, May 22, 2026 at 7:49 AM Paul Kocialkowski <paulk@sys-base.io> wrote:
>
> From: Marco Felsch <m.felsch@pengutronix.de>
>
> Add support for the Versilicon VC8000E multi-codec stateless encoder.
Typo: Verisilicon
> The IP integrated on the i.MX8MP supports H.264 and H.265 encoding.
>
> Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
You need to add your Signed-off-by tag as well.
> ---
> arch/arm64/boot/dts/freescale/imx8mp.dtsi | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> index a3de6604e29f..4e63c2b16c1a 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> @@ -2290,6 +2290,17 @@ vpu_g2: video-codec@38310000 {
> power-domains = <&vpumix_blk_ctrl IMX8MP_VPUBLK_PD_G2>;
> };
>
> + vpu_vc8000e: video-codec@38320000 {
> + compatible = "nxp,imx8mp-vpu-vc8000e";
This compatible must be documented in a dt-bindings yaml file.
^ permalink raw reply
* [PATCH 1/1] arm64: dts: tqma8mpql-mba8mpxl: configure sai clock in sound card as well
From: Alexander Stein @ 2026-05-22 11:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Alexander Stein, Shawn Guo
Cc: linux, devicetree, imx, linux-arm-kernel, linux-kernel
With deferrable card binding the sound card driver tries to
get the mclk configuration before it is setup in sai3 node.
Fix this by setting the mclk config for the sound card as well.
Fixes: d8f9d8126582 ("arm64: dts: imx8mp: Add analog audio output on i.MX8MP TQMa8MPxL/MBa8MPxL")
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
index 890d1e525a489..1ea1da735762f 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
@@ -246,6 +246,9 @@ sound {
"IN1_R", "Line In Jack",
"Line Out Jack", "LOL",
"Line Out Jack", "LOR";
+ assigned-clocks = <&clk IMX8MP_CLK_SAI3>;
+ assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <12288000>;
};
sound-hdmi {
--
2.43.0
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: freescale: add DT overlay for MX95-15x15-FRDM RPMSG usage
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Add RPMSG DT overlay for the MX95-15x15-FRDM board. This overlay is meant
to be used with the mx95evkrpmsg system manager configuration for
remoteproc and audio over rpmsg-usecases.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
arch/arm64/boot/dts/freescale/Makefile | 3 +
.../dts/freescale/imx95-15x15-frdm-rpmsg.dtso | 65 +++++++++++++++++++
2 files changed, 68 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 513f61eb27b8..a30a99e42426 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -521,6 +521,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx943-evk-pcie0-ep.dtb imx943-evk-pcie1-ep.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-ab2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-frdm-rpmsg.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-19x19-evk-sof.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-toradex-smarc-dev.dtb
@@ -539,6 +540,8 @@ dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-mallow.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-yavia.dtb
dtb-$(CONFIG_ARCH_MXC) += imx95-verdin-wifi-zinnia.dtb
+imx95-15x15-frdm-rpmsg-dtbs = imx95-15x15-frdm.dtb imx95-15x15-frdm-rpmsg.dtbo
+
imx95-15x15-evk-pcie-dtbs += imx95-15x15-evk.dtb imx-m2-pcie.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx95-15x15-evk-pcie.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
new file mode 100644
index 000000000000..b39444dde66e
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
@@ -0,0 +1,65 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2026 NXP
+ *
+ * This DT overlay is meant to be used alongside the mx95evkrpmsg SM
+ * configuration for remoteproc and audio over rpmsg.
+ */
+
+/dts-v1/;
+/plugin/;
+
+&{/} {
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ vdev0vring0: memory@88000000 {
+ reg = <0 0x88000000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0vring1: memory@88008000 {
+ reg = <0 0x88008000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0buffer: memory@88020000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x88020000 0 0x100000>;
+ no-map;
+ };
+
+ rsc_table: memory@88220000 {
+ reg = <0 0x88220000 0 0x1000>;
+ no-map;
+ };
+ };
+
+ sound-micfil {
+ status = "disabled";
+ };
+};
+
+&cm7 {
+ memory-region = <&vdev0buffer>, <&vdev0vring0>,
+ <&vdev0vring1>, <&rsc_table>;
+ memory-region-names = "vdev0buffer", "vdev0vring0",
+ "vdev0vring1", "rsc-table";
+ status = "okay";
+};
+
+&edma1 {
+ /* reserved for M7 */
+ dma-channel-mask = <0x40>;
+};
+
+&edma2 {
+ /* reserved for M7 and V2X */
+ dma-channel-mask = <0xf>;
+};
+
+&micfil {
+ /* reserved for M7 */
+ status = "disabled";
+};
--
2.43.0
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: freescale: imx95-toradex-smarc: move CM7 node to SoC DTSI
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
The CM7 remoteproc configuration is common to multiple MX95-based
platforms (e.g. MX95-19x19-EVK, MX95-15x15-FRDM, SMARC-IMX95, etc.).
Therefore, move the node to the MX95 SoC DTSI. While at it, split the mbox
channels using <>.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
.../boot/dts/freescale/imx95-toradex-smarc.dtsi | 14 ++++++--------
arch/arm64/boot/dts/freescale/imx95.dtsi | 7 +++++++
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
index 7d760470201f..c94a63a3bf8f 100644
--- a/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95-toradex-smarc.dtsi
@@ -145,14 +145,6 @@ reg_wifi_en: regulator-wifi-en {
startup-delay-us = <2000>;
};
- remoteproc-cm7 {
- compatible = "fsl,imx95-cm7";
- mboxes = <&mu7 0 1 &mu7 1 1 &mu7 3 1>;
- mbox-names = "tx", "rx", "rxdb";
- memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
- <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>, <&m7_reserved>;
- };
-
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
@@ -204,6 +196,12 @@ vdevbuffer: vdevbuffer@88020000 {
};
};
+&cm7 {
+ memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
+ <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>, <&m7_reserved>;
+ status = "okay";
+};
+
/* SMARC GBE0 */
&enetc_port0 {
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index 3e35c956a4d7..f8760ac067fa 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -272,6 +272,13 @@ opp-1000000000 {
};
};
+ cm7: remoteproc-cm7 {
+ compatible = "fsl,imx95-cm7";
+ mboxes = <&mu7 0 1>, <&mu7 1 1>, <&mu7 3 1>;
+ mbox-names = "tx", "rx", "rxdb";
+ status = "disabled";
+ };
+
clk_ext1: clock-ext1 {
compatible = "fixed-clock";
#clock-cells = <0>;
--
2.43.0
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: freescale: imx95-15x15-frdm: remove common rmem regions
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Remove the reserved memory regions that are common to the MX95-19x19-EVK,
MX95-15x15-FRDM, and MX95-15x15-EVK platforms and are used for remoteproc.
At the moment, these regions are not used for anything and can be included
in an RPMSG-specific DTS.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
.../boot/dts/freescale/imx95-15x15-frdm.dts | 21 -------------------
1 file changed, 21 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts
index 0f43e3be7058..f9b0e266754d 100644
--- a/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-15x15-frdm.dts
@@ -188,16 +188,6 @@ linux_cma: linux,cma {
linux,cma-default;
};
- vdev0vring0: memory@88000000 {
- reg = <0 0x88000000 0 0x8000>;
- no-map;
- };
-
- vdev0vring1: memory@88008000 {
- reg = <0 0x88008000 0 0x8000>;
- no-map;
- };
-
vdev1vring0: memory@88010000 {
reg = <0 0x88010000 0 0x8000>;
no-map;
@@ -208,17 +198,6 @@ vdev1vring1: memory@88018000 {
no-map;
};
- vdevbuffer: memory@88020000 {
- compatible = "shared-dma-pool";
- reg = <0 0x88020000 0 0x100000>;
- no-map;
- };
-
- rsc_table: memory@88220000 {
- reg = <0 0x88220000 0 0x1000>;
- no-map;
- };
-
vpu_boot: memory@a0000000 {
reg = <0 0xa0000000 0 0x100000>;
no-map;
--
2.43.0
^ permalink raw reply related
* [PATCH 1/5] dt-bindings: remoteproc: imx_rproc: document optional "memory-region-names"
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Document the optional "memory-region-names" property.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
.../devicetree/bindings/remoteproc/fsl,imx-rproc.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
index c18f71b64889..6679b10f9da5 100644
--- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml
@@ -62,6 +62,14 @@ properties:
minItems: 1
maxItems: 32
+ memory-region-names:
+ minItems: 1
+ maxItems: 32
+ items:
+ oneOf:
+ - const: rsc-table
+ - pattern: '^vdev[0-9](buffer|vring[0-9])$'
+
power-domains:
minItems: 2
maxItems: 8
--
2.43.0
^ permalink raw reply related
* [PATCH 2/5] remoteproc: imx_rpoc: fix carveout name parsing
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260522111849.783-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
The imx remoteproc driver assumes that the names of the reserved memory
regions reflect their usage (e.g. "vdevbuffer", "vdev0vring0", etc.). This
conflicts with the devicetree specification's recommendation, which states
that the names of the devicetree nodes should be generic.
Therefore, instead of relying on the node names, use the names passed via
the "memory-region-names" property if present. Otherwise, keep the old
behavior.
The definition of imx_rproc_rmem_to_resource() is added to a common place
as imx_dsp_rproc.c can also use it given that it suffers from the same
aforementioned problem.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
drivers/remoteproc/imx_rproc.c | 7 +++++--
drivers/remoteproc/imx_rproc.h | 19 +++++++++++++++++++
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 7f54322244ac..1ee1c658dcc1 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -672,7 +672,7 @@ static int imx_rproc_prepare(struct rproc *rproc)
int err;
struct resource res;
- err = of_reserved_mem_region_to_resource(np, i++, &res);
+ err = imx_rproc_rmem_to_resource(np, i++, &res);
if (err)
break;
@@ -850,11 +850,14 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
if (nph <= 0)
return 0;
+ if (!of_property_present(np, "memory-region-names"))
+ dev_warn(dev, "using node names for carveouts should be avoided\n");
+
/* remap optional addresses */
for (a = 0; a < nph; a++) {
struct resource res;
- err = of_reserved_mem_region_to_resource(np, a, &res);
+ err = imx_rproc_rmem_to_resource(np, a, &res);
if (err) {
dev_err(dev, "unable to resolve memory region\n");
return err;
diff --git a/drivers/remoteproc/imx_rproc.h b/drivers/remoteproc/imx_rproc.h
index 0d7d48352a10..58e9daa41afe 100644
--- a/drivers/remoteproc/imx_rproc.h
+++ b/drivers/remoteproc/imx_rproc.h
@@ -45,4 +45,23 @@ struct imx_rproc_dcfg {
u32 reset_vector_mask;
};
+static inline int imx_rproc_rmem_to_resource(struct device_node *np,
+ int index,
+ struct resource *res)
+{
+ int ret;
+
+ ret = of_reserved_mem_region_to_resource(np, index, res);
+ if (ret)
+ return ret;
+
+ /* "memory-region-names" is optional */
+ ret = of_property_read_string_index(np, "memory-region-names",
+ index, &res->name);
+ if (ret == -EINVAL)
+ return 0;
+
+ return ret;
+}
+
#endif /* _IMX_RPROC_H */
--
2.43.0
^ permalink raw reply related
* [PATCH 0/5] Add RPROC support for the MX95-15x15-FRDM board
From: Laurentiu Mihalcea @ 2026-05-22 11:18 UTC (permalink / raw)
To: Bjorn Andersson, Mathieu Poirier, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Peng Fan, Fabio Estevam
Cc: Pengutronix Kernel Team, linux-remoteproc, devicetree, imx,
linux-arm-kernel, linux-kernel
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Hi folks,
As you can see from the title, this series attempts to introduce/enable
RPROC support for the MX95-15x15-FRDM board.
For a while now, the imx_rproc driver has been using the reserved memory
DT nodes as the carveout names, which would force DT writers to go against
the DT specification's recommendation and use non-generic names (e.g.
"vdev0vring0", "vdev0vring1", etc...). This series also tries to fix this
issue by introducing the "memory-region-names" property and using it in
the imx_rproc driver to figure out the carveout names. The driver will
still allow the old way of doing things (i.e. no "memory-region-names"
property) but a warning will now be printed since this should be
discouraged.
Laurentiu Mihalcea (5):
dt-bindings: remoteproc: imx_rproc: document optional
"memory-region-names"
remoteproc: imx_rpoc: fix carveout name parsing
arm64: dts: freescale: imx95-toradex-smarc: move CM7 node to SoC DTSI
arm64: dts: freescale: imx95-15x15-frdm: remove common rmem regions
arm64: dts: freescale: add DT overlay for MX95-15x15-FRDM RPMSG usage
.../bindings/remoteproc/fsl,imx-rproc.yaml | 8 +++
arch/arm64/boot/dts/freescale/Makefile | 3 +
.../dts/freescale/imx95-15x15-frdm-rpmsg.dtso | 65 +++++++++++++++++++
.../boot/dts/freescale/imx95-15x15-frdm.dts | 21 ------
.../dts/freescale/imx95-toradex-smarc.dtsi | 14 ++--
arch/arm64/boot/dts/freescale/imx95.dtsi | 7 ++
drivers/remoteproc/imx_rproc.c | 7 +-
drivers/remoteproc/imx_rproc.h | 19 ++++++
8 files changed, 113 insertions(+), 31 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/imx95-15x15-frdm-rpmsg.dtso
--
2.43.0
^ permalink raw reply
* Re: [PATCH 14/16] media: sun6i-isp: Use V4L2 subdev active state
From: Paul Kocialkowski @ 2026-05-22 11:15 UTC (permalink / raw)
To: arash golgol
Cc: linux-media, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-staging, Mauro Carvalho Chehab, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Greg Kroah-Hartman,
Laurent Pinchart, Nicolas Dufresne
In-Reply-To: <CAMxPZkg9MgZrsM2L0vKzzUOA_tnSLKHdHkzDsfH5_WRqSQgvZg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1152 bytes --]
Hi Arash,
Le Thu 21 May 26, 12:53, arash golgol a écrit :
> I used LicheePi Zero Dock (V3s) with the following pipeline as test setup.
>
> ov5647 -> sun6i-mipi-csi2 -> sun6i-csi-bridge -> sun6i-isp-proc ->
> sun6i-isp-capture
>
> I verified TRY and ACTIVE state handling, including changing TRY
> formats without affecting ACTIVE state. Format propagation from the
> sink (csi) pad to the source pad was also tested.
>
> I also tested streaming with the sensor test pattern enabled and
> verified the captured output was correct.
>
> Tested-by: Arash Golgol <arash.golgol@gmail.com>
Thanks a lot for testing this! Did you test just this patch or the other
ones (especially sun6i-csi format enumeration) as well?
Also if you have an opinion on the code itself feel free to drop a
Reviewed-by tag, a lot of this work is very similar to what you did for
sun6i-csi and other drivers.
All the best,
Paul
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v6 02/22] drm/connector: Add HDMI 2.0 scrambler infrastructure
From: Cristian Ciocaltea @ 2026-05-22 10:57 UTC (permalink / raw)
To: Maxime Ripard
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst,
Thomas Zimmermann, David Airlie, Simona Vetter, Sandy Huang,
Heiko Stübner, Andy Yan, Luca Ceresoli, Daniel Stone, kernel,
dri-devel, linux-kernel, linux-arm-kernel, linux-rockchip
In-Reply-To: <20260521-sweet-devout-panther-44d73c@penduick>
Hi Maxime,
On 5/21/26 10:52 AM, Maxime Ripard wrote:
> Hi,
>
> Thanks for working on this!
Thanks for your quick review! :-)
>
> On Wed, May 20, 2026 at 09:38:13PM +0300, Cristian Ciocaltea wrote:
>> Add the connector-level infrastructure to support HDMI 2.0 scrambling:
>>
>> - .scrambler_src_{enable|disable}() callbacks in
>> drm_connector_hdmi_funcs for source-side scrambling control
>> - A delayed work item (scdc_work) with an associated callback (scdc_cb)
>> for periodic monitoring of sink-side scrambling status
>> - A scrambler_enabled flag to track whether scrambling is currently
>> active
>>
>> These are intended to be used by SCDC scrambling helpers to coordinate
>> scrambling setup and teardown between the source driver and the DRM
>> core.
>>
>> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
>> ---
>> drivers/gpu/drm/drm_connector.c | 14 +++++++++++
>> include/drm/drm_connector.h | 52 +++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 66 insertions(+)
>
> So we would need kunit tests for this.
Ack.
>
>> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
>> index 3fa4d2082cd7..91e58362fbc0 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -220,6 +220,19 @@ void drm_connector_free_work_fn(struct work_struct *work)
>> }
>> }
[...]
>> + /**
>> + * @scdc_work: Work item currently used to monitor sink-side scrambling
>> + * status and retry setup if the sink resets it.
>> + */
>> + struct delayed_work scdc_work;
>> +
>> + /** @scdc_cb: Callback to be invoked as part of @scdc_work.
>> + *
>> + * Currently used to monitor sink-side scrambling status and retry
>> + * setup if the sink resets it.
>> + *
>> + * This is assigned by the framework when making use of
>> + * drm_scdc_start_scrambling() helper.
>> + */
>> + void (*scdc_cb)(struct drm_connector *connector);
>> +
>
> I'm really not sure what the monitor thing is about. If we have setup
> the scrambler at enable time, and we set it again on hotplugging, why
> would we need to monitor anything?
This is similar to 257d36d493e9 ("drm/vc4: hdmi: Add a workqueue to set
scrambling") in order to deal with some displays needing a retry on scrambling
setup.
> Also, scrambling is only relevant for HDMI 2.0. We need a way to expose
> that somehow and make sure that HDMI 2.0 drivers actually have
> scrambling setup.
I assumed drivers that do not reject the HDMI 2.0 rates in their
.tmds_char_rate_valid() are implicitly expected to support scrambling.
Thinking again we could extend the framework to provide some additional checks,
but let's discuss the topic on the SCDC patch.
Regards,
Cristian
^ permalink raw reply
* Re: [PATCH] arm64: tlb: Flush walk cache when unsharing PMD tables
From: Catalin Marinas @ 2026-05-22 10:42 UTC (permalink / raw)
To: will, akpm, npiggin, aneesh.kumar, peterz, Zeng Heng
Cc: linux-kernel, wangkefeng.wang, linux-arm-kernel, linux-mm,
linux-arch
In-Reply-To: <20260521073011.4121277-1-zengheng@huaweicloud.com>
On Thu, 21 May 2026 15:30:11 +0800, Zeng Heng wrote:
> When huge_pmd_unshare() is called to unshare a PMD table, the
> tlb_unshare_pmd_ptdesc() function sets tlb->unshared_tables=true
> but the aarch64 tlb_flush() only checked tlb->freed_tables to
> determine whether to use TLBF_NONE (vae1is, invalidates walk
> cache) or TLBF_NOWALKCACHE (vale1is, leaf-only).
>
> This caused the stale PMD page table entry to remain in the walk cache
> after unshare, potentially leading to incorrect page table walks.
>
> [...]
Applied to arm64 (for-next/fixes), thanks!
[1/1] arm64: tlb: Flush walk cache when unsharing PMD tables
https://git.kernel.org/arm64/c/c2ff4764e03e
^ permalink raw reply
* Re: [PATCH] arm64: tlb: Flush walk cache when unsharing PMD tables
From: Catalin Marinas @ 2026-05-22 10:38 UTC (permalink / raw)
To: Zeng Heng
Cc: yezhenyu2, zhurui3, will, akpm, npiggin, aneesh.kumar, peterz,
linux-kernel, wangkefeng.wang, linux-arm-kernel, linux-mm,
linux-arch, David Hildenbrand, zengheng4
In-Reply-To: <ahAsPU00ZTTJV3Ye@arm.com>
On Fri, May 22, 2026 at 11:13:17AM +0100, Catalin Marinas wrote:
> On Fri, May 22, 2026 at 01:32:07PM +0800, Zeng Heng wrote:
> > On 2026/5/21 23:15, Catalin Marinas wrote:
> > > On Thu, May 21, 2026 at 04:05:07PM +0100, Catalin Marinas wrote:
> > > > On Thu, May 21, 2026 at 03:30:11PM +0800, Zeng Heng wrote:
> > > > > From: Zeng Heng <zengheng4@huawei.com>
> > > > >
> > > > > When huge_pmd_unshare() is called to unshare a PMD table, the
> > > > > tlb_unshare_pmd_ptdesc() function sets tlb->unshared_tables=true
> > > > > but the aarch64 tlb_flush() only checked tlb->freed_tables to
> > > > > determine whether to use TLBF_NONE (vae1is, invalidates walk
> > > > > cache) or TLBF_NOWALKCACHE (vale1is, leaf-only).
> > > > >
> > > > > This caused the stale PMD page table entry to remain in the walk cache
> > > > > after unshare, potentially leading to incorrect page table walks.
> > > > >
> > > > > Fix by including unshared_tables in the check, so that when
> > > > > unsharing tables, TLBF_NONE is used and the walk cache is properly
> > > > > invalidated.
> > > > >
> > > > > Here is the detailed distinction between vae1is and vale1is:
> > > > >
> > > > > | Instruction Combination | Actual Invalidation Scope |
> > > > > | ------------------------ | --------------------------------------------------|
> > > > > | `VAE1IS` + TTL=`0` | All entries at all levels (full invalidation) |
> > > > > | `VAE1IS` + TTL=`2` (L2) | Non-leaf at Level 0/1 + leaf at Level 2 |
> > > > > | `VALE1IS` + TTL=`0` | Leaf entries at all levels (non-leaf not cleared) |
> > > > > | `VALE1IS` + TTL=`2` (L2) | Leaf entry at Level 2 only |
[...]
> > Per the ARM Architecture Reference Manual, whether only the last-level
> > page table entry is invalidated is determined by the instruction used
> > (vale1is for leaf entry only, vae1is for walk cache including leaf entry and
> > non-leaf entry), rather than the TTL field. The TTL field merely specifies
> > which level the leaf entry belongs to.
>
> Ah, yes, you are right. The TTL is still 2 in this case for a huge pmd,
> we just want the walk cache leading to it to be invalidated. So no need
> for the additional tlb_get_level().
The Arm ARM is still unclear. The RVAE1IS has this wording:
The TTL hint is only guaranteed to invalidate:
- Non-leaf-level entries in the range up to but not including the
level described by the TTL hint.
- Leaf-level entries in the range that match the level described by
the TTL hint.
But we don't have such wording around non-leaf-level entries for VAE1IS.
I presume it would be the same but I'll ask internally next week. In the
meantime, I'll take this patch.
--
Catalin
^ permalink raw reply
* Re: [PATCH] media: bcm2835-unicam: Fix log status runtime access
From: Sakari Ailus @ 2026-05-22 10:28 UTC (permalink / raw)
To: Jean-Michel Hautbois
Cc: Eugen Hristev, Raspberry Pi Kernel Maintenance,
Mauro Carvalho Chehab, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Dave Stevenson, Hans Verkuil, Laurent Pinchart, Naushir Patuck,
linux-media, linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <4d7deb19-d384-497e-8139-c977a9f3679d@yoseli.org>
Hi Eugen, Jean-Michel,
On Fri, May 22, 2026 at 10:31:51AM +0200, Jean-Michel Hautbois wrote:
> Hi Eugen,
>
> Thanks for the fix, the issue is real, but I think the patch leaks a runtime
> PM reference.
>
> Le 21/05/2026 à 20:09, Eugen Hristev a écrit :
> > When requesting log status, the block might be powered
> > off, but registers are being read.
> > Avoid reading the registers if the device is not
> > resumed, thus also avoid powering up the device just
> > for log status.
Please rewrap this, most editors can do that automatically.
> >
> > Fixes: 392cd78d495f ("media: bcm2835-unicam: Add support for CCP2/CSI2 camera interface")
> > Signed-off-by: Eugen Hristev <ehristev@kernel.org>
> > ---
> > drivers/media/platform/broadcom/bcm2835-unicam.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/media/platform/broadcom/bcm2835-unicam.c b/drivers/media/platform/broadcom/bcm2835-unicam.c
> > index 8d28ba0b59a3..818694f007e2 100644
> > --- a/drivers/media/platform/broadcom/bcm2835-unicam.c
> > +++ b/drivers/media/platform/broadcom/bcm2835-unicam.c
> > @@ -2052,6 +2052,10 @@ static int unicam_log_status(struct file *file, void *fh)
> > node->fmt.fmt.pix.width, node->fmt.fmt.pix.height);
> > dev_info(unicam->dev, "V4L2 format: %08x\n",
> > node->fmt.fmt.pix.pixelformat);
> > +
> > + if (!pm_runtime_get_if_in_use(unicam->dev))
> > + return 0;
> > +
>
> pm_runtime_get_if_in_use() returns 1 and increments the usage counter is
> active and in use.
Also, should this be pm_runtime_get_if_active() instead?
>
> I think we need to add:
> pm_runtime_put(unicam->dev);
>
> Just before the return 0;
>
> BTW, we may miss a dev_info explaining why the live data is skipped when the
> device is suspended ?
--
Regards,
Sakari Ailus
^ permalink raw reply
* Re: [PATCH 0/4] ASoC: meson: aiu: align I2S design to the AXG one
From: Mark Brown @ 2026-05-21 11:36 UTC (permalink / raw)
To: Jerome Brunet, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Neil Armstrong, Kevin Hilman, Martin Blumenstingl, Valerio Setti
Cc: linux-kernel, linux-sound, linux-arm-kernel, linux-amlogic
In-Reply-To: <20260515-reshape-aiu-as-axg-v1-0-53b457784ff3@baylibre.com>
On Fri, 15 May 2026 17:10:36 +0200, Valerio Setti wrote:
> ASoC: meson: aiu: align I2S design to the AXG one
>
> This is the first follow-up patch series based on RFC [1]. The goal here
> is simply to reshape Amlogic GX's AIU implementation for I2S to follow
> the same design as in AXG's TDM. Keeping the same design allows for
> unifying the two platform implementations in the future.
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
Thanks!
[1/4] ASoC: meson: gx: add gx-formatter and gx-interface
https://git.kernel.org/broonie/sound/c/4efe33e7a2f0
[2/4] ASoC: meson: aiu-encoder-i2s: use gx_iface and gx_stream structures
https://git.kernel.org/broonie/sound/c/3383866c1b77
[3/4] ASoC: meson: aiu: introduce I2S output formatter
https://git.kernel.org/broonie/sound/c/df6057a25c52
[4/4] ASoC: meson: aiu: use aiu-formatter-i2s to format I2S output data
https://git.kernel.org/broonie/sound/c/ca3543cf247b
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ 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