* Re: [PATCH v5 phy-next 10/27] scsi: ufs: qcom: keep parallel track of PHY power state
From: Manivannan Sadhasivam @ 2026-03-25 11:51 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, James E.J. Bottomley, Martin K. Petersen,
Nitin Rawat
In-Reply-To: <20260325114309.3k7xkfrffpxp5xq4@skbuf>
On Wed, Mar 25, 2026 at 01:43:09PM +0200, Vladimir Oltean wrote:
> On Tue, Mar 24, 2026 at 11:00:10AM +0530, Manivannan Sadhasivam wrote:
> > On Fri, Mar 20, 2026 at 12:32:24AM +0200, Vladimir Oltean wrote:
> > > As explained in the similar ufs-exynos.c change, PHY consumer drivers
> > > should not look at the phy->power_count, because in the general case
> > > there might also be other consumers who have called phy_power_on() too,
> > > so the fact that the power_count is non-zero does not mean that we did.
> > >
> > > Moreover, struct phy will become opaque soon, so the qcom UFS driver
> > > will not be able to apply this pattern. Keep parallel track of the PHY
> > > power state, instead of looking at a field which will become unavailable
> > > (phy->power_count).
> > >
> > > About treating the phy_power_off() return code: from an API perspective,
> > > this should have probably returned void, otherwise consumers would be
> > > stuck in a state they can't escape. The provider, phy-qcom-qmp-ufs.c,
> > > does return 0 in its power_off() implementation. I consider it safe to
> > > discard potential errors from phy_power_off() instead of complicating
> > > the phy_powered_on logic.
> > >
> >
> > You could even simplify the code by getting rid of the 'phy_powered_on' check
> > altogether. There is no real need to track the PHY power state in this driver.
> > It is safe to call phy_power_off() without any checks.
> >
> > - Mani
>
> Ok.. as the author of commit 7bac65687510 ("scsi: ufs: qcom: Power off
> the PHY if it was already powered on in ufs_qcom_power_up_sequence()"),
> I assume you have hardware to test. Would you mind writing a patch that
> I could pick up to replace this one with?
>
Sure, will do.
> I suppose that the power_count test is somehow no longer necessary after
> commit 77d2fa54a945 ("scsi: ufs: qcom : Refactor phy_power_on/off
> calls"), but frankly I don't see it - the ufshcd state machine is a bit
> too complicated for me to just statically analyze.
I believe I added the power_count check for phy_exit(). But since that got
moved, the check becomes no longer necessary.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* [PATCH v3 9/9] arm64: defconfig: enable designware mipi csi-2 receiver
From: Michael Riesch via B4 Relay @ 2026-03-25 11:51 UTC (permalink / raw)
To: Mehdi Djait, Laurent Pinchart, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Jagan Teki,
Кузнецов Михаил,
Charalampos Mitrodimas, Sebastian Reichel, Nicolas Dufresne,
Collabora Kernel Team, Sakari Ailus
Cc: linux-media, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Michael Riesch
In-Reply-To: <20250430-rk3588-vicap-v3-0-e38e428868cc@collabora.com>
From: Michael Riesch <michael.riesch@collabora.com>
The Synopsys DesignWare MIPI CSI-2 Receiver is integrated into
recent Rockchip SoCs, such as the RK3568 and the RK3588.
As a consequence, they are used on a lot of Rockchip-based
single board computers and/or corresponding camera modules, such
as the Radxa Camera 4K.
Enable the driver for it in the default configuration.
Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com>
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b67d5b1fc45b..a93ff73ae52c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -907,6 +907,7 @@ CONFIG_SDR_PLATFORM_DRIVERS=y
CONFIG_V4L_MEM2MEM_DRIVERS=y
CONFIG_VIDEO_AMPHION_VPU=m
CONFIG_VIDEO_CADENCE_CSI2RX=m
+CONFIG_VIDEO_DW_MIPI_CSI2RX=m
CONFIG_VIDEO_MEDIATEK_JPEG=m
CONFIG_VIDEO_MEDIATEK_VCODEC=m
CONFIG_VIDEO_WAVE_VPU=m
--
2.39.5
^ permalink raw reply related
* [PATCH v3 8/9] arm64: dts: rockchip: add radxa camera 4k on rock 5b+ cam1
From: Michael Riesch via B4 Relay @ 2026-03-25 11:51 UTC (permalink / raw)
To: Mehdi Djait, Laurent Pinchart, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Jagan Teki,
Кузнецов Михаил,
Charalampos Mitrodimas, Sebastian Reichel, Nicolas Dufresne,
Collabora Kernel Team, Sakari Ailus
Cc: linux-media, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Michael Riesch
In-Reply-To: <20250430-rk3588-vicap-v3-0-e38e428868cc@collabora.com>
From: Michael Riesch <michael.riesch@collabora.com>
Add device tree overlay for the Radxa Camera 4K (featuring the
Sony IMX415 image sensor) to applied on the Radxa ROCK 5B+
CAM1 port.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
---
arch/arm64/boot/dts/rockchip/Makefile | 4 +-
.../rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso | 99 ++++++++++++++++++++++
2 files changed, 102 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 77c587f43dda..191666821a80 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -200,6 +200,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b-pcie-ep.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b-pcie-srns.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b-plus.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b-plus-radxa-cam4k-cam0.dtbo
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b-plus-radxa-cam4k-cam1.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5t.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-tiger-haikou.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-tiger-haikou-video-demo.dtbo
@@ -301,7 +302,8 @@ rk3588-rock-5b-pcie-srns-dtbs := rk3588-rock-5b.dtb \
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b-plus-radxa-4k-cam.dtb
rk3588-rock-5b-plus-radxa-4k-cam-dtbs := rk3588-rock-5b-plus.dtb \
- rk3588-rock-5b-plus-radxa-cam4k-cam0.dtbo
+ rk3588-rock-5b-plus-radxa-cam4k-cam0.dtbo \
+ rk3588-rock-5b-plus-radxa-cam4k-cam1.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-tiger-haikou-haikou-video-demo.dtb
rk3588-tiger-haikou-haikou-video-demo-dtbs := rk3588-tiger-haikou.dtb \
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso
new file mode 100644
index 000000000000..96b8df4ed354
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device tree overlay for the Radxa Camera 4K attached to the CAM1 port of
+ * the Radxa ROCK 5B+.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/clock/rockchip,rk3588-cru.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+
+&{/} {
+ savdd_cam1: regulator-savdd-cam1 {
+ compatible = "regulator-fixed";
+ regulator-min-microvolt = <2900000>;
+ regulator-max-microvolt = <2900000>;
+ regulator-name = "savdd_cam1";
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ sdvdd_cam1: regulator-sdvdd-cam1 {
+ compatible = "regulator-fixed";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-name = "sdvdd_cam1";
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ siovdd_cam1: regulator-siovdd-cam1 {
+ compatible = "regulator-fixed";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "siovdd_cam1";
+ vin-supply = <&vcc_3v3_s3>;
+ };
+};
+
+&i2c4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ cam1_imx415: camera-sensor@1a {
+ compatible = "sony,imx415";
+ reg = <0x1a>;
+ assigned-clocks = <&cru CLK_MIPI_CAMARAOUT_M4>;
+ assigned-clock-rates = <37125000>;
+ avdd-supply = <&savdd_cam1>;
+ clocks = <&cru CLK_MIPI_CAMARAOUT_M4>;
+ dvdd-supply = <&sdvdd_cam1>;
+ orientation = <2>; /* External */
+ ovdd-supply = <&savdd_cam1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam1_rstn &mipim0_camera4_clk>;
+ reset-gpios = <&gpio2 RK_PB0 GPIO_ACTIVE_LOW>;
+
+ port {
+ cam1_imx415_output: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <445500000>;
+ remote-endpoint = <&csi4_input>;
+ };
+ };
+ };
+};
+
+&pinctrl {
+ cam1 {
+ cam1_rstn: cam1-rstn-pinctrl {
+ rockchip,pins = <2 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&csi4 {
+ status = "okay";
+};
+
+&csi4_in {
+ csi4_input: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <445500000>;
+ remote-endpoint = <&cam1_imx415_output>;
+ };
+};
+
+&csi_dphy1 {
+ status = "okay";
+};
+
+&vicap {
+ status = "okay";
+};
+
+&vicap_mmu {
+ status = "okay";
+};
--
2.39.5
^ permalink raw reply related
* [PATCH v3 3/9] media: rockchip: rkcif: add support for rk3588 vicap mipi capture
From: Michael Riesch via B4 Relay @ 2026-03-25 11:51 UTC (permalink / raw)
To: Mehdi Djait, Laurent Pinchart, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Jagan Teki,
Кузнецов Михаил,
Charalampos Mitrodimas, Sebastian Reichel, Nicolas Dufresne,
Collabora Kernel Team, Sakari Ailus
Cc: linux-media, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Michael Riesch
In-Reply-To: <20250430-rk3588-vicap-v3-0-e38e428868cc@collabora.com>
From: Michael Riesch <michael.riesch@collabora.com>
The RK3588 Video Capture (VICAP) unit features a Digital Video Port
(DVP) and six MIPI CSI-2 capture interfaces. Add initial support
for this variant to the rkcif driver and enable the MIPI CSI-2
capture interfaces.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
---
.../platform/rockchip/rkcif/rkcif-capture-mipi.c | 141 +++++++++++++++++++++
.../platform/rockchip/rkcif/rkcif-capture-mipi.h | 1 +
.../media/platform/rockchip/rkcif/rkcif-common.h | 2 +-
drivers/media/platform/rockchip/rkcif/rkcif-dev.c | 18 +++
4 files changed, 161 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/rockchip/rkcif/rkcif-capture-mipi.c b/drivers/media/platform/rockchip/rkcif/rkcif-capture-mipi.c
index 9e67160a16e4..ad083dc9f5ad 100644
--- a/drivers/media/platform/rockchip/rkcif/rkcif-capture-mipi.c
+++ b/drivers/media/platform/rockchip/rkcif/rkcif-capture-mipi.c
@@ -30,6 +30,14 @@
#define RK3568_MIPI_CTRL0_CROP_EN BIT(5)
#define RK3568_MIPI_CTRL0_WRDDR(type) ((type) << 1)
+#define RK3588_MIPI_CTRL0_DMA_EN BIT(28)
+#define RK3588_MIPI_CTRL0_HIGH_ALIGN BIT(27)
+#define RK3588_MIPI_CTRL0_WRDDR(type) ((type) << 5)
+#define RK3588_MIPI_CTRL0_CROP_EN BIT(4)
+#define RK3588_MIPI_CTRL0_PARSE(type) ((type) << 1)
+
+#define RK3588_MIPI_CTRL_CAP_EN BIT(0)
+
#define RKCIF_MIPI_CTRL0_DT_ID(id) ((id) << 10)
#define RKCIF_MIPI_CTRL0_VC_ID(id) ((id) << 8)
#define RKCIF_MIPI_CTRL0_CAP_EN BIT(0)
@@ -481,6 +489,132 @@ const struct rkcif_mipi_match_data rkcif_rk3568_vicap_mipi_match_data = {
},
};
+static u32
+rkcif_rk3588_mipi_ctrl0(struct rkcif_stream *stream,
+ const struct rkcif_output_fmt *active_out_fmt)
+{
+ u32 ctrl0 = 0;
+
+ ctrl0 |= RK3588_MIPI_CTRL0_DMA_EN;
+ ctrl0 |= RKCIF_MIPI_CTRL0_DT_ID(active_out_fmt->mipi.dt);
+ ctrl0 |= RK3588_MIPI_CTRL0_CROP_EN;
+ ctrl0 |= RKCIF_MIPI_CTRL0_CAP_EN;
+
+ switch (active_out_fmt->mipi.type) {
+ case RKCIF_MIPI_TYPE_RAW8:
+ break;
+ case RKCIF_MIPI_TYPE_RAW10:
+ ctrl0 |= RK3588_MIPI_CTRL0_PARSE(0x1);
+ if (!active_out_fmt->mipi.compact)
+ ctrl0 |= RK3588_MIPI_CTRL0_WRDDR(0x1);
+ break;
+ case RKCIF_MIPI_TYPE_RAW12:
+ ctrl0 |= RK3588_MIPI_CTRL0_PARSE(0x2);
+ if (!active_out_fmt->mipi.compact)
+ ctrl0 |= RK3588_MIPI_CTRL0_WRDDR(0x1);
+ break;
+ case RKCIF_MIPI_TYPE_RGB888:
+ break;
+ case RKCIF_MIPI_TYPE_YUV422SP:
+ ctrl0 |= RK3588_MIPI_CTRL0_WRDDR(0x4);
+ break;
+ case RKCIF_MIPI_TYPE_YUV420SP:
+ ctrl0 |= RK3588_MIPI_CTRL0_WRDDR(0x5);
+ break;
+ case RKCIF_MIPI_TYPE_YUV400:
+ ctrl0 |= RK3588_MIPI_CTRL0_WRDDR(0x3);
+ break;
+ default:
+ break;
+ }
+
+ return ctrl0;
+}
+
+const struct rkcif_mipi_match_data rkcif_rk3588_vicap_mipi_match_data = {
+ .mipi_num = 6,
+ .mipi_ctrl0 = rkcif_rk3588_mipi_ctrl0,
+ .regs = {
+ [RKCIF_MIPI_CTRL] = 0x20,
+ [RKCIF_MIPI_INTEN] = 0x74,
+ [RKCIF_MIPI_INTSTAT] = 0x78,
+ },
+ .regs_id = {
+ [RKCIF_ID0] = {
+ [RKCIF_MIPI_CTRL0] = 0x00,
+ [RKCIF_MIPI_CTRL1] = 0x04,
+ [RKCIF_MIPI_FRAME0_ADDR_Y] = 0x24,
+ [RKCIF_MIPI_FRAME0_ADDR_UV] = 0x2c,
+ [RKCIF_MIPI_FRAME0_VLW_Y] = 0x34,
+ [RKCIF_MIPI_FRAME0_VLW_UV] = RKCIF_REGISTER_NOTSUPPORTED,
+ [RKCIF_MIPI_FRAME1_ADDR_Y] = 0x28,
+ [RKCIF_MIPI_FRAME1_ADDR_UV] = 0x30,
+ [RKCIF_MIPI_FRAME1_VLW_Y] = RKCIF_REGISTER_NOTSUPPORTED,
+ [RKCIF_MIPI_FRAME1_VLW_UV] = RKCIF_REGISTER_NOTSUPPORTED,
+ [RKCIF_MIPI_CROP_START] = 0x8c,
+ },
+ [RKCIF_ID1] = {
+ [RKCIF_MIPI_CTRL0] = 0x08,
+ [RKCIF_MIPI_CTRL1] = 0x0c,
+ [RKCIF_MIPI_FRAME0_ADDR_Y] = 0x38,
+ [RKCIF_MIPI_FRAME0_ADDR_UV] = 0x40,
+ [RKCIF_MIPI_FRAME0_VLW_Y] = 0x48,
+ [RKCIF_MIPI_FRAME0_VLW_UV] = RKCIF_REGISTER_NOTSUPPORTED,
+ [RKCIF_MIPI_FRAME1_ADDR_Y] = 0x3c,
+ [RKCIF_MIPI_FRAME1_ADDR_UV] = 0x44,
+ [RKCIF_MIPI_FRAME1_VLW_Y] = RKCIF_REGISTER_NOTSUPPORTED,
+ [RKCIF_MIPI_FRAME1_VLW_UV] = RKCIF_REGISTER_NOTSUPPORTED,
+ [RKCIF_MIPI_CROP_START] = 0x90,
+ },
+ [RKCIF_ID2] = {
+ [RKCIF_MIPI_CTRL0] = 0x10,
+ [RKCIF_MIPI_CTRL1] = 0x14,
+ [RKCIF_MIPI_FRAME0_ADDR_Y] = 0x4c,
+ [RKCIF_MIPI_FRAME0_ADDR_UV] = 0x54,
+ [RKCIF_MIPI_FRAME0_VLW_Y] = 0x5c,
+ [RKCIF_MIPI_FRAME0_VLW_UV] = RKCIF_REGISTER_NOTSUPPORTED,
+ [RKCIF_MIPI_FRAME1_ADDR_Y] = 0x50,
+ [RKCIF_MIPI_FRAME1_ADDR_UV] = 0x58,
+ [RKCIF_MIPI_FRAME1_VLW_Y] = RKCIF_REGISTER_NOTSUPPORTED,
+ [RKCIF_MIPI_FRAME1_VLW_UV] = RKCIF_REGISTER_NOTSUPPORTED,
+ [RKCIF_MIPI_CROP_START] = 0x94,
+ },
+ [RKCIF_ID3] = {
+ [RKCIF_MIPI_CTRL0] = 0x18,
+ [RKCIF_MIPI_CTRL1] = 0x1c,
+ [RKCIF_MIPI_FRAME0_ADDR_Y] = 0x60,
+ [RKCIF_MIPI_FRAME0_ADDR_UV] = 0x68,
+ [RKCIF_MIPI_FRAME0_VLW_Y] = 0x70,
+ [RKCIF_MIPI_FRAME0_VLW_UV] = RKCIF_REGISTER_NOTSUPPORTED,
+ [RKCIF_MIPI_FRAME1_ADDR_Y] = 0x64,
+ [RKCIF_MIPI_FRAME1_ADDR_UV] = 0x6c,
+ [RKCIF_MIPI_FRAME1_VLW_Y] = RKCIF_REGISTER_NOTSUPPORTED,
+ [RKCIF_MIPI_FRAME1_VLW_UV] = RKCIF_REGISTER_NOTSUPPORTED,
+ [RKCIF_MIPI_CROP_START] = 0x98,
+ },
+ },
+ .blocks = {
+ {
+ .offset = 0x100,
+ },
+ {
+ .offset = 0x200,
+ },
+ {
+ .offset = 0x300,
+ },
+ {
+ .offset = 0x400,
+ },
+ {
+ .offset = 0x500,
+ },
+ {
+ .offset = 0x600,
+ },
+ },
+};
+
static inline unsigned int rkcif_mipi_get_reg(struct rkcif_interface *interface,
unsigned int index)
{
@@ -631,6 +765,13 @@ static int rkcif_mipi_start_streaming(struct rkcif_stream *stream)
rkcif_mipi_stream_write(stream, RKCIF_MIPI_CTRL1, ctrl1);
rkcif_mipi_stream_write(stream, RKCIF_MIPI_CTRL0, ctrl0);
+ /*
+ * TODO: This bit has a different meaning on the RK3568, but it is
+ * set there by default anyway. While correct, this is not exactly
+ * nice and shall be reworked during the next refactoring.
+ */
+ rkcif_mipi_write(interface, RKCIF_MIPI_CTRL, RK3588_MIPI_CTRL_CAP_EN);
+
ret = 0;
out:
diff --git a/drivers/media/platform/rockchip/rkcif/rkcif-capture-mipi.h b/drivers/media/platform/rockchip/rkcif/rkcif-capture-mipi.h
index 7f16eadc474c..7edaca44f653 100644
--- a/drivers/media/platform/rockchip/rkcif/rkcif-capture-mipi.h
+++ b/drivers/media/platform/rockchip/rkcif/rkcif-capture-mipi.h
@@ -13,6 +13,7 @@
#include "rkcif-common.h"
extern const struct rkcif_mipi_match_data rkcif_rk3568_vicap_mipi_match_data;
+extern const struct rkcif_mipi_match_data rkcif_rk3588_vicap_mipi_match_data;
int rkcif_mipi_register(struct rkcif_device *rkcif);
diff --git a/drivers/media/platform/rockchip/rkcif/rkcif-common.h b/drivers/media/platform/rockchip/rkcif/rkcif-common.h
index dd92cfbc879f..4d9211ba9bda 100644
--- a/drivers/media/platform/rockchip/rkcif/rkcif-common.h
+++ b/drivers/media/platform/rockchip/rkcif/rkcif-common.h
@@ -27,7 +27,7 @@
#include "rkcif-regs.h"
#define RKCIF_DRIVER_NAME "rockchip-cif"
-#define RKCIF_CLK_MAX 4
+#define RKCIF_CLK_MAX 5
enum rkcif_format_type {
RKCIF_FMT_TYPE_INVALID,
diff --git a/drivers/media/platform/rockchip/rkcif/rkcif-dev.c b/drivers/media/platform/rockchip/rkcif/rkcif-dev.c
index b4cf1146f131..c8542398b7f0 100644
--- a/drivers/media/platform/rockchip/rkcif/rkcif-dev.c
+++ b/drivers/media/platform/rockchip/rkcif/rkcif-dev.c
@@ -53,6 +53,20 @@ static const struct rkcif_match_data rk3568_vicap_match_data = {
.mipi = &rkcif_rk3568_vicap_mipi_match_data,
};
+static const char *const rk3588_vicap_clks[] = {
+ "aclk",
+ "hclk",
+ "dclk",
+ "iclk0",
+ "iclk1",
+};
+
+static const struct rkcif_match_data rk3588_vicap_match_data = {
+ .clks = rk3588_vicap_clks,
+ .clks_num = ARRAY_SIZE(rk3588_vicap_clks),
+ .mipi = &rkcif_rk3588_vicap_mipi_match_data,
+};
+
static const struct of_device_id rkcif_plat_of_match[] = {
{
.compatible = "rockchip,px30-vip",
@@ -62,6 +76,10 @@ static const struct of_device_id rkcif_plat_of_match[] = {
.compatible = "rockchip,rk3568-vicap",
.data = &rk3568_vicap_match_data,
},
+ {
+ .compatible = "rockchip,rk3588-vicap",
+ .data = &rk3588_vicap_match_data,
+ },
{}
};
MODULE_DEVICE_TABLE(of, rkcif_plat_of_match);
--
2.39.5
^ permalink raw reply related
* [PATCH DONOTMERGE v3 5/9] arm64: dts: rockchip: add mipi csi-2 receiver nodes to rk3588
From: Michael Riesch via B4 Relay @ 2026-03-25 11:51 UTC (permalink / raw)
To: Mehdi Djait, Laurent Pinchart, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Jagan Teki,
Кузнецов Михаил,
Charalampos Mitrodimas, Sebastian Reichel, Nicolas Dufresne,
Collabora Kernel Team, Sakari Ailus
Cc: linux-media, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Michael Riesch
In-Reply-To: <20250430-rk3588-vicap-v3-0-e38e428868cc@collabora.com>
From: Michael Riesch <michael.riesch@collabora.com>
This patch is discussed over at
https://lore.kernel.org/all/20260305-rk3588-csi2rx-v2-0-79d01b615486@collabora.com
included here for testing purposes only.
The Rockchip RK3588 features six MIPI CSI-2 receiver units:
- MIPI0: connected to MIPI DCPHY0 (not supported)
- MIPI1: connected to MIPI DCPHY1 (not supported)
- MIPI2: connected to MIPI DPHY0
- MIPI3: connected to MIPI DPHY0-1 (not supported)
- MIPI4: connected to MIPI DPHY1
- MIPI5: connected to MIPI DPHY1-1 (not supported)
As the MIPI DCPHYs as well as the split DPHY mode of the DPHYs
are not yet supported, add only the device tree nodes for the
MIPI2 and MIPI4 units.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 52 +++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
index 7fe9593d8c19..6c593b0255c3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
@@ -1430,6 +1430,58 @@ av1d: video-codec@fdc70000 {
resets = <&cru SRST_A_AV1>, <&cru SRST_P_AV1>, <&cru SRST_A_AV1_BIU>, <&cru SRST_P_AV1_BIU>;
};
+ csi2: csi@fdd30000 {
+ compatible = "rockchip,rk3588-mipi-csi2", "rockchip,rk3568-mipi-csi2";
+ reg = <0x0 0xfdd30000 0x0 0x10000>;
+ interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "err1", "err2";
+ clocks = <&cru PCLK_CSI_HOST_2>;
+ phys = <&csi_dphy0>;
+ power-domains = <&power RK3588_PD_VI>;
+ resets = <&cru SRST_P_CSI_HOST_2>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi2_in: port@0 {
+ reg = <0>;
+ };
+
+ csi2_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ csi4: csi@fdd50000 {
+ compatible = "rockchip,rk3588-mipi-csi2", "rockchip,rk3568-mipi-csi2";
+ reg = <0x0 0xfdd50000 0x0 0x10000>;
+ interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "err1", "err2";
+ clocks = <&cru PCLK_CSI_HOST_4>;
+ phys = <&csi_dphy1>;
+ power-domains = <&power RK3588_PD_VI>;
+ resets = <&cru SRST_P_CSI_HOST_4>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi4_in: port@0 {
+ reg = <0>;
+ };
+
+ csi4_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
vop: vop@fdd90000 {
compatible = "rockchip,rk3588-vop";
reg = <0x0 0xfdd90000 0x0 0x4200>, <0x0 0xfdd95000 0x0 0x1000>;
--
2.39.5
^ permalink raw reply related
* [PATCH v3 7/9] arm64: dts: rockchip: add radxa camera 4k on rock 5b+ cam0
From: Michael Riesch via B4 Relay @ 2026-03-25 11:51 UTC (permalink / raw)
To: Mehdi Djait, Laurent Pinchart, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Jagan Teki,
Кузнецов Михаил,
Charalampos Mitrodimas, Sebastian Reichel, Nicolas Dufresne,
Collabora Kernel Team, Sakari Ailus
Cc: linux-media, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Michael Riesch
In-Reply-To: <20250430-rk3588-vicap-v3-0-e38e428868cc@collabora.com>
From: Michael Riesch <michael.riesch@collabora.com>
Add device tree overlay for the Radxa Camera 4K (featuring the
Sony IMX415 image sensor) to applied on the Radxa ROCK 5B+
CAM0 port.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
---
arch/arm64/boot/dts/rockchip/Makefile | 5 ++
.../rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso | 99 ++++++++++++++++++++++
2 files changed, 104 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 4d384f153c13..77c587f43dda 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -199,6 +199,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b-pcie-ep.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b-pcie-srns.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b-plus.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b-plus-radxa-cam4k-cam0.dtbo
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5t.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-tiger-haikou.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-tiger-haikou-video-demo.dtbo
@@ -298,6 +299,10 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b-pcie-srns.dtb
rk3588-rock-5b-pcie-srns-dtbs := rk3588-rock-5b.dtb \
rk3588-rock-5b-pcie-srns.dtbo
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-rock-5b-plus-radxa-4k-cam.dtb
+rk3588-rock-5b-plus-radxa-4k-cam-dtbs := rk3588-rock-5b-plus.dtb \
+ rk3588-rock-5b-plus-radxa-cam4k-cam0.dtbo
+
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588-tiger-haikou-haikou-video-demo.dtb
rk3588-tiger-haikou-haikou-video-demo-dtbs := rk3588-tiger-haikou.dtb \
rk3588-tiger-haikou-video-demo.dtbo
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso
new file mode 100644
index 000000000000..ee9ecf68a886
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device tree overlay for the Radxa Camera 4K attached to the CAM0 port of
+ * the Radxa ROCK 5B+.
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/clock/rockchip,rk3588-cru.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/pinctrl/rockchip.h>
+
+&{/} {
+ savdd_cam0: regulator-savdd-cam0 {
+ compatible = "regulator-fixed";
+ regulator-min-microvolt = <2900000>;
+ regulator-max-microvolt = <2900000>;
+ regulator-name = "savdd_cam0";
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ sdvdd_cam0: regulator-sdvdd-cam0 {
+ compatible = "regulator-fixed";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-name = "sdvdd_cam0";
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ siovdd_cam0: regulator-siovdd-cam0 {
+ compatible = "regulator-fixed";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-name = "siovdd_cam0";
+ vin-supply = <&vcc_3v3_s3>;
+ };
+};
+
+&i2c3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ imx415: camera-sensor@1a {
+ compatible = "sony,imx415";
+ reg = <0x1a>;
+ assigned-clocks = <&cru CLK_MIPI_CAMARAOUT_M3>;
+ assigned-clock-rates = <37125000>;
+ avdd-supply = <&savdd_cam0>;
+ clocks = <&cru CLK_MIPI_CAMARAOUT_M3>;
+ dvdd-supply = <&sdvdd_cam0>;
+ orientation = <2>; /* External */
+ ovdd-supply = <&siovdd_cam0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam0_rstn &mipim0_camera3_clk>;
+ reset-gpios = <&gpio4 RK_PA0 GPIO_ACTIVE_LOW>;
+
+ port {
+ imx415_output: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <445500000>;
+ remote-endpoint = <&csi2_input>;
+ };
+ };
+ };
+};
+
+&pinctrl {
+ cam0 {
+ cam0_rstn: cam0-rstn-pinctrl {
+ rockchip,pins = <4 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&csi2 {
+ status = "okay";
+};
+
+&csi2_in {
+ csi2_input: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <445500000>;
+ remote-endpoint = <&imx415_output>;
+ };
+};
+
+&csi_dphy0 {
+ status = "okay";
+};
+
+&vicap {
+ status = "okay";
+};
+
+&vicap_mmu {
+ status = "okay";
+};
--
2.39.5
^ permalink raw reply related
* [PATCH v3 6/9] arm64: dts: rockchip: add vicap node to rk3588
From: Michael Riesch via B4 Relay @ 2026-03-25 11:51 UTC (permalink / raw)
To: Mehdi Djait, Laurent Pinchart, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Jagan Teki,
Кузнецов Михаил,
Charalampos Mitrodimas, Sebastian Reichel, Nicolas Dufresne,
Collabora Kernel Team, Sakari Ailus
Cc: linux-media, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Michael Riesch
In-Reply-To: <20250430-rk3588-vicap-v3-0-e38e428868cc@collabora.com>
From: Michael Riesch <michael.riesch@collabora.com>
Add the device tree node for the RK3588 Video Capture (VICAP) unit.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 91 +++++++++++++++++++++++++++
1 file changed, 91 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
index 6c593b0255c3..8b98e5c3cc8b 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
@@ -1430,6 +1430,89 @@ av1d: video-codec@fdc70000 {
resets = <&cru SRST_A_AV1>, <&cru SRST_P_AV1>, <&cru SRST_A_AV1_BIU>, <&cru SRST_P_AV1_BIU>;
};
+ vicap: video-capture@fdce0000 {
+ compatible = "rockchip,rk3588-vicap";
+ reg = <0x0 0xfdce0000 0x0 0x800>;
+ interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru ACLK_VICAP>, <&cru HCLK_VICAP>,
+ <&cru DCLK_VICAP>, <&cru ICLK_CSIHOST0>,
+ <&cru ICLK_CSIHOST1>;
+ clock-names = "aclk", "hclk", "dclk", "iclk0", "iclk1";
+ iommus = <&vicap_mmu>;
+ power-domains = <&power RK3588_PD_VI>;
+ resets = <&cru SRST_A_VICAP>, <&cru SRST_H_VICAP>,
+ <&cru SRST_D_VICAP>, <&cru SRST_CSIHOST0_VICAP>,
+ <&cru SRST_CSIHOST1_VICAP>,
+ <&cru SRST_CSIHOST2_VICAP>,
+ <&cru SRST_CSIHOST3_VICAP>,
+ <&cru SRST_CSIHOST4_VICAP>,
+ <&cru SRST_CSIHOST5_VICAP>;
+ reset-names = "arst", "hrst", "drst", "irst0", "irst1",
+ "irst2", "irst3", "irst4", "irst5";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ vicap_dvp: port@0 {
+ reg = <0>;
+ };
+
+ vicap_mipi0: port@1 {
+ reg = <1>;
+ };
+
+ vicap_mipi1: port@2 {
+ reg = <2>;
+ };
+
+ vicap_mipi2: port@3 {
+ reg = <3>;
+
+ vicap_mipi2_input: endpoint {
+ remote-endpoint = <&csi2_output>;
+ };
+ };
+
+ vicap_mipi3: port@4 {
+ reg = <4>;
+ };
+
+ vicap_mipi4: port@5 {
+ reg = <5>;
+
+ vicap_mipi4_input: endpoint {
+ remote-endpoint = <&csi4_output>;
+ };
+ };
+
+ vicap_mipi5: port@6 {
+ reg = <6>;
+ };
+
+ vicap_toisp0: port@10 {
+ reg = <16>;
+ };
+
+ vicap_toisp1: port@11 {
+ reg = <17>;
+ };
+ };
+ };
+
+ vicap_mmu: iommu@fdce0800 {
+ compatible = "rockchip,rk3588-iommu", "rockchip,rk3568-iommu";
+ reg = <0x0 0xfdce0800 0x0 0x40>, <0x0 0xfdce0900 0x0 0x40>;
+ interrupts = <GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&cru ACLK_VICAP>, <&cru HCLK_VICAP>;
+ clock-names = "aclk", "iface";
+ #iommu-cells = <0>;
+ power-domains = <&power RK3588_PD_VI>;
+ rockchip,disable-mmu-reset;
+ status = "disabled";
+ };
+
csi2: csi@fdd30000 {
compatible = "rockchip,rk3588-mipi-csi2", "rockchip,rk3568-mipi-csi2";
reg = <0x0 0xfdd30000 0x0 0x10000>;
@@ -1452,6 +1535,10 @@ csi2_in: port@0 {
csi2_out: port@1 {
reg = <1>;
+
+ csi2_output: endpoint {
+ remote-endpoint = <&vicap_mipi2_input>;
+ };
};
};
};
@@ -1478,6 +1565,10 @@ csi4_in: port@0 {
csi4_out: port@1 {
reg = <1>;
+
+ csi4_output: endpoint {
+ remote-endpoint = <&vicap_mipi4_input>;
+ };
};
};
};
--
2.39.5
^ permalink raw reply related
* [PATCH v3 0/9] media: rockchip: rkcif: add support for rk3588 vicap
From: Michael Riesch via B4 Relay @ 2026-03-25 11:51 UTC (permalink / raw)
To: Mehdi Djait, Laurent Pinchart, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Jagan Teki,
Кузнецов Михаил,
Charalampos Mitrodimas, Sebastian Reichel, Nicolas Dufresne,
Collabora Kernel Team, Sakari Ailus
Cc: linux-media, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Michael Riesch
Habidere,
The RK3588 Video Capture (VICAP) constitutes an essential piece of the
RK3588 camera interface with one DVP, six MIPI CSI-2 receivers,
scale/crop units, and a data path multiplexer (to scaler units, to ISP,
...). This series introduces basic support for the RK3588 VICAP unit
to the rkcif driver, thus paving the way for video capture in general
and for camera sensor image processing in particular.
The changes have been tested successfully on a Radxa ROCK 5B+ with two
Radxa 4K cameras attached to it. The raw images from the sensors can
be streamed after configuring the hardware pipeline with
media-ctl -d 0 --set-v4l2 '"dw-mipi-csi2rx fdd30000.csi":0 \
[fmt:SGBRG10_1X10/3864x2192 field:none colorspace:raw xfer:none]'
media-ctl -d 0 --set-v4l2 '"rkcif-mipi2":0 \
[fmt:SGBRG10_1X10/3864x2192 field:none colorspace:raw xfer:none]'
media-ctl -d 0 --set-v4l2 '"dw-mipi-csi2rx fdd50000.csi":0 \
[fmt:SGBRG10_1X10/3864x2192 field:none colorspace:raw xfer:none]'
media-ctl -d 0 --set-v4l2 '"rkcif-mipi4":0 \
[fmt:SGBRG10_1X10/3864x2192 field:none colorspace:raw xfer:none]'
and using e.g., GStreamer
gst-launch-1.0 v4l2src \
device=/dev/v4l/by-path/platform-fdce0000.video-capture-video-index0 \
! video/x-bayer,format=gbrg10le,width=3864,height=2192 ! bayer2rgb \
! ...
(or -index4 for the other camera sensor).
Note that this series requires the RK3588 MIPI CSI-2 receiver patches
[0]. I included them here to provide the possibility to test the changes
without any nasty merge conflicts.
Looking forward to your comments!
[0] https://lore.kernel.org/all/20260305-rk3588-csi2rx-v2-0-79d01b615486@collabora.com
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
---
Changes in v3:
- fixed copy-paste mistake "RK3568" -> "RK3588" in docs (Charalampos)
- fixed reg properties of ports in dtsi (port@10 <=> <16>, ...)
- added comment w.r.t. RKCIF_MIPI_CTRL_CAP_EN bit (Mehdi)
- removed redundant minItems and maxItems from dt-binding (Conor)
- revised device tree overlays for the Radxa CAMs according to the
schematics that I recently received
- Link to v2: https://lore.kernel.org/r/20250430-rk3588-vicap-v2-0-77de5ee9048e@collabora.com
Changes in v2:
- modified rockchip,rk3568-vicap binding instead of creating a new one
(Conor)
- aligned clock names and reset names with rockchip,rk3568-vicap
- Link to v1: https://lore.kernel.org/r/20250430-rk3588-vicap-v1-0-b3bddf749914@collabora.com
---
Michael Riesch (9):
Documentation: admin-guide: media: add rk3588 vicap
media: dt-bindings: add rockchip rk3588 vicap
media: rockchip: rkcif: add support for rk3588 vicap mipi capture
[DONOTMERGE] media: dt-bindings: rockchip,rk3568-mipi-csi2: add rk3588 compatible
[DONOTMERGE] arm64: dts: rockchip: add mipi csi-2 receiver nodes to rk3588
arm64: dts: rockchip: add vicap node to rk3588
arm64: dts: rockchip: add radxa camera 4k on rock 5b+ cam0
arm64: dts: rockchip: add radxa camera 4k on rock 5b+ cam1
arm64: defconfig: enable designware mipi csi-2 receiver
.../admin-guide/media/rkcif-rk3588-vicap.dot | 29 ++++
Documentation/admin-guide/media/rkcif.rst | 32 ++++
.../bindings/media/rockchip,rk3568-mipi-csi2.yaml | 8 +-
.../bindings/media/rockchip,rk3568-vicap.yaml | 187 ++++++++++++++++++---
arch/arm64/boot/dts/rockchip/Makefile | 7 +
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 143 ++++++++++++++++
.../rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso | 99 +++++++++++
.../rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso | 99 +++++++++++
arch/arm64/configs/defconfig | 1 +
.../platform/rockchip/rkcif/rkcif-capture-mipi.c | 141 ++++++++++++++++
.../platform/rockchip/rkcif/rkcif-capture-mipi.h | 1 +
.../media/platform/rockchip/rkcif/rkcif-common.h | 2 +-
drivers/media/platform/rockchip/rkcif/rkcif-dev.c | 18 ++
13 files changed, 740 insertions(+), 27 deletions(-)
---
base-commit: 882ac913e67d2462a18bdc2958b496c0f51d1647
change-id: 20250430-rk3588-vicap-9d164c8528a7
Best regards,
--
Michael Riesch <michael.riesch@collabora.com>
^ permalink raw reply
* [PATCH v3 1/9] Documentation: admin-guide: media: add rk3588 vicap
From: Michael Riesch via B4 Relay @ 2026-03-25 11:51 UTC (permalink / raw)
To: Mehdi Djait, Laurent Pinchart, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Jagan Teki,
Кузнецов Михаил,
Charalampos Mitrodimas, Sebastian Reichel, Nicolas Dufresne,
Collabora Kernel Team, Sakari Ailus
Cc: linux-media, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Michael Riesch
In-Reply-To: <20250430-rk3588-vicap-v3-0-e38e428868cc@collabora.com>
From: Michael Riesch <michael.riesch@collabora.com>
Add a section that describes the Rockchip RK3588 VICAP.
Reviewed-by: Mehdi Djait <mehdi.djait@linux.intel.com>
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
---
.../admin-guide/media/rkcif-rk3588-vicap.dot | 29 ++++++++++++++++++++
Documentation/admin-guide/media/rkcif.rst | 32 ++++++++++++++++++++++
2 files changed, 61 insertions(+)
diff --git a/Documentation/admin-guide/media/rkcif-rk3588-vicap.dot b/Documentation/admin-guide/media/rkcif-rk3588-vicap.dot
new file mode 100644
index 000000000000..f6d3404920b5
--- /dev/null
+++ b/Documentation/admin-guide/media/rkcif-rk3588-vicap.dot
@@ -0,0 +1,29 @@
+digraph board {
+ rankdir=TB
+ n00000007 [label="{{<port0> 0} | rkcif-mipi2\n/dev/v4l-subdev0 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000007:port1 -> n0000000a
+ n00000007:port1 -> n00000010 [style=dashed]
+ n00000007:port1 -> n00000016 [style=dashed]
+ n00000007:port1 -> n0000001c [style=dashed]
+ n0000000a [label="rkcif-mipi2-id0\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
+ n00000010 [label="rkcif-mipi2-id1\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
+ n00000016 [label="rkcif-mipi2-id2\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
+ n0000001c [label="rkcif-mipi2-id3\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
+ n00000025 [label="{{<port0> 0} | rkcif-mipi4\n/dev/v4l-subdev1 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000025:port1 -> n00000028
+ n00000025:port1 -> n0000002e [style=dashed]
+ n00000025:port1 -> n00000034 [style=dashed]
+ n00000025:port1 -> n0000003a [style=dashed]
+ n00000028 [label="rkcif-mipi4-id0\n/dev/video4", shape=box, style=filled, fillcolor=yellow]
+ n0000002e [label="rkcif-mipi4-id1\n/dev/video5", shape=box, style=filled, fillcolor=yellow]
+ n00000034 [label="rkcif-mipi4-id2\n/dev/video6", shape=box, style=filled, fillcolor=yellow]
+ n0000003a [label="rkcif-mipi4-id3\n/dev/video7", shape=box, style=filled, fillcolor=yellow]
+ n00000043 [label="{{<port0> 0} | dw-mipi-csi2rx fdd30000.csi\n/dev/v4l-subdev2 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000043:port1 -> n00000007:port0
+ n00000048 [label="{{<port0> 0} | dw-mipi-csi2rx fdd50000.csi\n/dev/v4l-subdev3 | {<port1> 1}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000048:port1 -> n00000025:port0
+ n0000004d [label="{{} | imx415 3-001a\n/dev/v4l-subdev4 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
+ n0000004d:port0 -> n00000043:port0
+ n00000051 [label="{{} | imx415 4-001a\n/dev/v4l-subdev5 | {<port0> 0}}", shape=Mrecord, style=filled, fillcolor=green]
+ n00000051:port0 -> n00000048:port0
+}
diff --git a/Documentation/admin-guide/media/rkcif.rst b/Documentation/admin-guide/media/rkcif.rst
index 2558c121abc4..313a0ea45d16 100644
--- a/Documentation/admin-guide/media/rkcif.rst
+++ b/Documentation/admin-guide/media/rkcif.rst
@@ -77,3 +77,35 @@ and the following video devices:
.. kernel-figure:: rkcif-rk3568-vicap.dot
:alt: Topology of the RK3568 Video Capture (VICAP) unit
:align: center
+
+Rockchip RK3588 Video Capture (VICAP)
+-------------------------------------
+
+The RK3588 Video Capture (VICAP) unit features a digital video port and six
+MIPI CSI-2 capture interfaces that can receive video data independently.
+The DVP accepts parallel video data, BT.656 and BT.1120.
+Since the BT.1120 protocol may feature more than one stream, the RK3588 VICAP
+DVP features four DMA engines that can capture different streams.
+Similarly, the RK3588 VICAP MIPI CSI-2 receivers feature four DMA engines each
+to handle different Virtual Channels (VCs).
+
+The rkcif driver represents this hardware variant by exposing the following
+V4L2 subdevices:
+
+* dw-mipi-csi2rx fdd30000.csi: MIPI CSI-2 receiver connected to MIPI DPHY0
+* dw-mipi-csi2rx fdd50000.csi: MIPI CSI-2 receiver connected to MIPI DPHY1
+* rkcif-mipi2: INTERFACE/CROP block for the MIPI CSI-2 receiver connected to
+ MIPI DPHY0
+* rkcif-mipi4: INTERFACE/CROP block for the MIPI CSI-2 receiver connected to
+ MIPI DPHY1
+
+and the following video devices:
+
+* rkcif-mipi2-id{0,1,2,3}: The DMA engines connected to the rkcif-mipi2
+ INTERFACE/CROP block.
+* rkcif-mipi4-id{0,1,2,3}: The DMA engines connected to the rkcif-mipi4
+ INTERFACE/CROP block.
+
+.. kernel-figure:: rkcif-rk3588-vicap.dot
+ :alt: Topology of the RK3588 Video Capture (VICAP) unit
+ :align: center
--
2.39.5
^ permalink raw reply related
* [PATCH DONOTMERGE v3 4/9] media: dt-bindings: rockchip,rk3568-mipi-csi2: add rk3588 compatible
From: Michael Riesch via B4 Relay @ 2026-03-25 11:51 UTC (permalink / raw)
To: Mehdi Djait, Laurent Pinchart, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Jagan Teki,
Кузнецов Михаил,
Charalampos Mitrodimas, Sebastian Reichel, Nicolas Dufresne,
Collabora Kernel Team, Sakari Ailus
Cc: linux-media, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Michael Riesch
In-Reply-To: <20250430-rk3588-vicap-v3-0-e38e428868cc@collabora.com>
From: Michael Riesch <michael.riesch@collabora.com>
This patch is discussed over at
https://lore.kernel.org/all/20260305-rk3588-csi2rx-v2-0-79d01b615486@collabora.com
included here for testing purposes only.
The RK3588 MIPI CSI-2 receivers are compatible to the ones found in
the RK3568.
Introduce a list of compatible variants and add the RK3588 variant to
it.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
---
.../devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
index 2c2bd87582eb..5e864e92f8a8 100644
--- a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
@@ -16,8 +16,12 @@ description:
properties:
compatible:
- enum:
- - rockchip,rk3568-mipi-csi2
+ oneOf:
+ - const: rockchip,rk3568-mipi-csi2
+ - items:
+ - enum:
+ - rockchip,rk3588-mipi-csi2
+ - const: rockchip,rk3568-mipi-csi2
reg:
maxItems: 1
--
2.39.5
^ permalink raw reply related
* [PATCH v3 2/9] media: dt-bindings: add rockchip rk3588 vicap
From: Michael Riesch via B4 Relay @ 2026-03-25 11:51 UTC (permalink / raw)
To: Mehdi Djait, Laurent Pinchart, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Jagan Teki,
Кузнецов Михаил,
Charalampos Mitrodimas, Sebastian Reichel, Nicolas Dufresne,
Collabora Kernel Team, Sakari Ailus
Cc: linux-media, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Michael Riesch
In-Reply-To: <20250430-rk3588-vicap-v3-0-e38e428868cc@collabora.com>
From: Michael Riesch <michael.riesch@collabora.com>
Add documentation for the Rockchip RK3588 Video Capture (VICAP) unit.
To that end, make the existing rockchip,rk3568-vicap documentation
more general and introduce variant specific constraints.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
---
.../bindings/media/rockchip,rk3568-vicap.yaml | 187 ++++++++++++++++++---
1 file changed, 163 insertions(+), 24 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml
index 18cd0a5a5318..897ed00c239b 100644
--- a/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml
+++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml
@@ -15,9 +15,15 @@ description:
the data from camera sensors, video decoders, or other companion ICs and
transfers it into system main memory by AXI bus.
+ The Rockchip RK3588 Video Capture (VICAP) is similar to its RK3568
+ counterpart, but features six MIPI CSI-2 ports and additional connections
+ to the image signal processor (ISP) blocks.
+
properties:
compatible:
- const: rockchip,rk3568-vicap
+ enum:
+ - rockchip,rk3568-vicap
+ - rockchip,rk3588-vicap
reg:
maxItems: 1
@@ -26,37 +32,23 @@ properties:
maxItems: 1
clocks:
- items:
- - description: ACLK
- - description: HCLK
- - description: DCLK
- - description: ICLK
+ minItems: 4
+ maxItems: 5
clock-names:
- items:
- - const: aclk
- - const: hclk
- - const: dclk
- - const: iclk
+ minItems: 4
+ maxItems: 5
iommus:
maxItems: 1
resets:
- items:
- - description: ARST
- - description: HRST
- - description: DRST
- - description: PRST
- - description: IRST
+ minItems: 5
+ maxItems: 9
reset-names:
- items:
- - const: arst
- - const: hrst
- - const: drst
- - const: prst
- - const: irst
+ minItems: 5
+ maxItems: 9
rockchip,grf:
$ref: /schemas/types.yaml#/definitions/phandle
@@ -67,8 +59,15 @@ properties:
ports:
$ref: /schemas/graph.yaml#/properties/ports
+ additionalProperties: false
properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
port@0:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
@@ -100,13 +99,75 @@ properties:
port@1:
$ref: /schemas/graph.yaml#/properties/port
- description: Port connected to the MIPI CSI-2 receiver output.
+ description: Port connected to the MIPI CSI-2 receiver 0 output.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Port connected to the MIPI CSI-2 receiver 1 output.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Port connected to the MIPI CSI-2 receiver 2 output.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ port@4:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Port connected to the MIPI CSI-2 receiver 3 output.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ port@5:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Port connected to the MIPI CSI-2 receiver 4 output.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ port@6:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Port connected to the MIPI CSI-2 receiver 5 output.
properties:
endpoint:
$ref: video-interfaces.yaml#
unevaluatedProperties: false
+ port@10:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Port connected to the ISP0 input.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ port@11:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Port connected to the ISP1 input.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
required:
- compatible
- reg
@@ -114,6 +175,84 @@ required:
- clocks
- ports
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3568-vicap
+ then:
+ properties:
+ clocks:
+ maxItems: 4
+
+ clock-names:
+ items:
+ - const: aclk
+ - const: hclk
+ - const: dclk
+ - const: iclk
+
+ resets:
+ maxItems: 5
+
+ reset-names:
+ items:
+ - const: arst
+ - const: hrst
+ - const: drst
+ - const: prst
+ - const: irst
+
+ ports:
+ properties:
+ port@2: false
+
+ port@3: false
+
+ port@4: false
+
+ port@5: false
+
+ port@6: false
+
+ port@10: false
+
+ port@11: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3588-vicap
+ then:
+ properties:
+ clocks:
+ minItems: 5
+
+ clock-names:
+ items:
+ - const: aclk
+ - const: hclk
+ - const: dclk
+ - const: iclk0
+ - const: iclk1
+
+ resets:
+ minItems: 9
+
+ reset-names:
+ items:
+ - const: arst
+ - const: hrst
+ - const: drst
+ - const: irst0
+ - const: irst1
+ - const: irst2
+ - const: irst3
+ - const: irst4
+ - const: irst5
+
additionalProperties: false
examples:
--
2.39.5
^ permalink raw reply related
* Re: [PATCH 2/2] spi: spi-mtk-nor: add new clock support
From: Krzysztof Kozlowski @ 2026-03-25 11:47 UTC (permalink / raw)
To: Meiker Gao
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Bayi Cheng,
Project_Global_Chrome_Upstream_Group, sirius.wang, vince-wl.liu,
jh.hsu, linux-spi, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260325031900.2099969-3-ot_meiker.gao@mediatek.com>
On Wed, Mar 25, 2026 at 11:18:55AM +0800, Meiker Gao wrote:
> one more clock gate need to be added.
Your patch removes clock, not adds. Write useful commit msgs, because
this is completely useless one.
...
> @@ -828,13 +839,17 @@ static int mtk_nor_probe(struct platform_device *pdev)
> if (IS_ERR(ctlr_clk))
> return PTR_ERR(ctlr_clk);
>
> - axi_clk = devm_clk_get_optional(&pdev->dev, "axi");
NAK, ABI break. Read guides about writing bindings.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: mte: Skip TFSR_EL1 checks and barriers in synchronous tag check mode
From: David Hildenbrand (Arm) @ 2026-03-25 11:46 UTC (permalink / raw)
To: Muhammad Usama Anjum, Catalin Marinas, Will Deacon,
Matthew Wilcox (Oracle), Thomas Huth, Andrew Morton, Lance Yang,
Yeoreum Yun
Cc: linux-arm-kernel, linux-kernel
In-Reply-To: <20260311175054.3889093-1-usama.anjum@arm.com>
On 3/11/26 18:50, Muhammad Usama Anjum wrote:
> In MTE synchronous mode, tag check faults are reported as immediate
> Data Abort exceptions. The TFSR_EL1.TF1 bit is never set, since faults
> never go through the asynchronous path. Therefore, reading TFSR_EL1
> and executing data and instruction barriers on kernel entry, exit,
> context switch, and suspend is unnecessary overhead in sync mode.
>
> The exit path (mte_check_tfsr_exit) and the assembly paths
> (check_mte_async_tcf / clear_mte_async_tcf in entry.S) already had this
> check.
Right, that's for user space (TFSR_EL1.TF0 IIUC). What you are adding is
for KASAN. Maybe make that clearer.
> Extend the same optimization on kernel entry/exit, context
> switch and suspend.
>
> All mte kselftests pass. The kunit before and after the patch show same
> results.
>
> A selection of test_vmalloc benchmarks running on a arm64 machine.
> v6.19 is the baseline. (>0 is faster, <0 is slower, (R)/(I) =
> statistically significant Regression/Improvement). Based on significance
> and ignoring the noise, the benchmarks improved.
>
> * 77 result classes were considered, with 9 wins, 0 losses and 68 ties
>
> Results of fastpath [1] on v6.19 vs this patch:
>
> +----------------------------+----------------------------------------------------------+------------+
> | Benchmark | Result Class | barriers |
> +============================+==========================================================+============+
> | micromm/fork | fork: p:1, d:10 (seconds) | (I) 2.75% |
> | | fork: p:512, d:10 (seconds) | 0.96% |
> +----------------------------+----------------------------------------------------------+------------+
> | micromm/munmap | munmap: p:1, d:10 (seconds) | -1.78% |
> | | munmap: p:512, d:10 (seconds) | 5.02% |
> +----------------------------+----------------------------------------------------------+------------+
> | micromm/vmalloc | fix_align_alloc_test: p:1, h:0, l:500000 (usec) | -0.56% |
> | | fix_size_alloc_test: p:1, h:0, l:500000 (usec) | 0.70% |
> | | fix_size_alloc_test: p:4, h:0, l:500000 (usec) | 1.18% |
> | | fix_size_alloc_test: p:16, h:0, l:500000 (usec) | -5.01% |
> | | fix_size_alloc_test: p:16, h:1, l:500000 (usec) | 13.81% |
> | | fix_size_alloc_test: p:64, h:0, l:100000 (usec) | 6.51% |
> | | fix_size_alloc_test: p:64, h:1, l:100000 (usec) | 32.87% |
> | | fix_size_alloc_test: p:256, h:0, l:100000 (usec) | 4.17% |
> | | fix_size_alloc_test: p:256, h:1, l:100000 (usec) | 8.40% |
> | | fix_size_alloc_test: p:512, h:0, l:100000 (usec) | -0.48% |
> | | fix_size_alloc_test: p:512, h:1, l:100000 (usec) | -0.74% |
> | | full_fit_alloc_test: p:1, h:0, l:500000 (usec) | 0.53% |
> | | kvfree_rcu_1_arg_vmalloc_test: p:1, h:0, l:500000 (usec) | -2.81% |
> | | kvfree_rcu_2_arg_vmalloc_test: p:1, h:0, l:500000 (usec) | -2.06% |
> | | long_busy_list_alloc_test: p:1, h:0, l:500000 (usec) | -0.56% |
> | | pcpu_alloc_test: p:1, h:0, l:500000 (usec) | -0.41% |
> | | random_size_align_alloc_test: p:1, h:0, l:500000 (usec) | 0.89% |
> | | random_size_alloc_test: p:1, h:0, l:500000 (usec) | 1.71% |
> | | vm_map_ram_test: p:1, h:0, l:500000 (usec) | 0.83% |
> +----------------------------+----------------------------------------------------------+------------+
> | schbench/thread-contention | -m 16 -t 1 -r 10 -s 1000, avg_rps (req/sec) | 0.05% |
> | | -m 16 -t 1 -r 10 -s 1000, req_latency_p99 (usec) | 0.60% |
> | | -m 16 -t 1 -r 10 -s 1000, wakeup_latency_p99 (usec) | 0.00% |
> | | -m 16 -t 4 -r 10 -s 1000, avg_rps (req/sec) | -0.34% |
> | | -m 16 -t 4 -r 10 -s 1000, req_latency_p99 (usec) | -0.58% |
> | | -m 16 -t 4 -r 10 -s 1000, wakeup_latency_p99 (usec) | 9.09% |
> | | -m 16 -t 16 -r 10 -s 1000, avg_rps (req/sec) | -0.74% |
> | | -m 16 -t 16 -r 10 -s 1000, req_latency_p99 (usec) | -1.40% |
> | | -m 16 -t 16 -r 10 -s 1000, wakeup_latency_p99 (usec) | 0.00% |
> | | -m 16 -t 64 -r 10 -s 1000, avg_rps (req/sec) | -0.78% |
> | | -m 16 -t 64 -r 10 -s 1000, req_latency_p99 (usec) | -0.11% |
> | | -m 16 -t 64 -r 10 -s 1000, wakeup_latency_p99 (usec) | 0.11% |
> | | -m 16 -t 256 -r 10 -s 1000, avg_rps (req/sec) | 2.64% |
> | | -m 16 -t 256 -r 10 -s 1000, req_latency_p99 (usec) | 3.15% |
> | | -m 16 -t 256 -r 10 -s 1000, wakeup_latency_p99 (usec) | 17.54% |
> | | -m 32 -t 1 -r 10 -s 1000, avg_rps (req/sec) | -1.22% |
> | | -m 32 -t 1 -r 10 -s 1000, req_latency_p99 (usec) | 0.85% |
> | | -m 32 -t 1 -r 10 -s 1000, wakeup_latency_p99 (usec) | 0.00% |
> | | -m 32 -t 4 -r 10 -s 1000, avg_rps (req/sec) | -0.34% |
> | | -m 32 -t 4 -r 10 -s 1000, req_latency_p99 (usec) | 1.05% |
> | | -m 32 -t 4 -r 10 -s 1000, wakeup_latency_p99 (usec) | 0.00% |
> | | -m 32 -t 16 -r 10 -s 1000, avg_rps (req/sec) | -0.41% |
> | | -m 32 -t 16 -r 10 -s 1000, req_latency_p99 (usec) | 0.58% |
> | | -m 32 -t 16 -r 10 -s 1000, wakeup_latency_p99 (usec) | 2.13% |
> | | -m 32 -t 64 -r 10 -s 1000, avg_rps (req/sec) | 0.67% |
> | | -m 32 -t 64 -r 10 -s 1000, req_latency_p99 (usec) | 2.07% |
> | | -m 32 -t 64 -r 10 -s 1000, wakeup_latency_p99 (usec) | -1.28% |
> | | -m 32 -t 256 -r 10 -s 1000, avg_rps (req/sec) | 1.01% |
> | | -m 32 -t 256 -r 10 -s 1000, req_latency_p99 (usec) | 0.69% |
> | | -m 32 -t 256 -r 10 -s 1000, wakeup_latency_p99 (usec) | 13.12% |
> | | -m 64 -t 1 -r 10 -s 1000, avg_rps (req/sec) | -0.25% |
> | | -m 64 -t 1 -r 10 -s 1000, req_latency_p99 (usec) | -0.48% |
> | | -m 64 -t 1 -r 10 -s 1000, wakeup_latency_p99 (usec) | 10.53% |
> | | -m 64 -t 4 -r 10 -s 1000, avg_rps (req/sec) | -0.06% |
> | | -m 64 -t 4 -r 10 -s 1000, req_latency_p99 (usec) | 0.00% |
> | | -m 64 -t 4 -r 10 -s 1000, wakeup_latency_p99 (usec) | 0.00% |
> | | -m 64 -t 16 -r 10 -s 1000, avg_rps (req/sec) | -0.36% |
> | | -m 64 -t 16 -r 10 -s 1000, req_latency_p99 (usec) | 0.52% |
> | | -m 64 -t 16 -r 10 -s 1000, wakeup_latency_p99 (usec) | 0.11% |
> | | -m 64 -t 64 -r 10 -s 1000, avg_rps (req/sec) | 0.52% |
> | | -m 64 -t 64 -r 10 -s 1000, req_latency_p99 (usec) | 3.53% |
> | | -m 64 -t 64 -r 10 -s 1000, wakeup_latency_p99 (usec) | -0.10% |
> | | -m 64 -t 256 -r 10 -s 1000, avg_rps (req/sec) | 2.53% |
> | | -m 64 -t 256 -r 10 -s 1000, req_latency_p99 (usec) | 1.82% |
> | | -m 64 -t 256 -r 10 -s 1000, wakeup_latency_p99 (usec) | -5.80% |
> +----------------------------+----------------------------------------------------------+------------+
> | syscall/getpid | mean (ns) | (I) 15.98% |
> | | p99 (ns) | (I) 11.11% |
> | | p99.9 (ns) | (I) 16.13% |
> +----------------------------+----------------------------------------------------------+------------+
> | syscall/getppid | mean (ns) | (I) 14.82% |
> | | p99 (ns) | (I) 17.86% |
> | | p99.9 (ns) | (I) 9.09% |
> +----------------------------+----------------------------------------------------------+------------+
> | syscall/invalid | mean (ns) | (I) 17.78% |
> | | p99 (ns) | (I) 11.11% |
> | | p99.9 (ns) | 13.33% |
> +----------------------------+----------------------------------------------------------+------------+
>
> [1] https://gitlab.arm.com/tooling/fastpath
>
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@arm.com>
> ---
> The patch applies on v6.19 and next-20260309.
> ---
> arch/arm64/include/asm/mte.h | 6 +++++-
> arch/arm64/kernel/mte.c | 5 +++++
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
> index 6d4a78b9dc3e6..0e05d20cf2583 100644
> --- a/arch/arm64/include/asm/mte.h
> +++ b/arch/arm64/include/asm/mte.h
> @@ -252,7 +252,8 @@ static inline void mte_check_tfsr_entry(void)
> if (!kasan_hw_tags_enabled())
> return;
>
> - mte_check_tfsr_el1();
> + if (system_uses_mte_async_or_asymm_mode())
> + mte_check_tfsr_el1();
For symmetry, I would also write this as
if (!system_uses_mte_async_or_asymm_mode())
return;
mte_check_tfsr_el1();
Nothing jumped at me, but I am still new to this code + spec :)
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: Prevent the host from using an smc with imm16 != 0
From: Marc Zyngier @ 2026-03-25 11:46 UTC (permalink / raw)
To: Sebastian Ene, Vincent Donnefort
Cc: kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
catalin.marinas, joey.gouly, mark.rutland, oupton, suzuki.poulose,
tabba, will, yuzenghui
In-Reply-To: <acPIdoA8oc7T8wKX@google.com>
On Wed, 25 Mar 2026 11:35:18 +0000,
Vincent Donnefort <vdonnefort@google.com> wrote:
>
> On Wed, Mar 25, 2026 at 11:31:38AM +0000, Sebastian Ene wrote:
> > The ARM Service Calling Convention (SMCCC) specifies that the function
> > identifier and parameters should be passed in registers, leaving the
> > 16-bit immediate field of the SMC instruction un-handled.
> > Currently, our pKVM handler ignores the immediate value, which could lead
> > to non-compliant software relying on implementation-defined behavior.
> > Enforce the host kernel running under pKVM to use an immediate value
> > of 0 by decoding the ISS from the ESR_EL2 and return a not supported
> > error code back to the caller.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > v1 -> v2:
> >
> > - Dropped injecting an UNDEF and return an error instead
> > (SMCCC_RET_NOT_SUPPORTED)
> > - Used the mask ESR_ELx_xVC_IMM_MASK instead of masking with U16_MAX
> > - Updated the title of the commit message from:
> > "[PATCH] KVM: arm64: Inject UNDEF when host is executing an
> > smc with imm16 != 0
>
> > ---
> > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > index e7790097db93..4ffe30fd8707 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > @@ -762,6 +762,12 @@ void handle_trap(struct kvm_cpu_context *host_ctxt)
> > handle_host_hcall(host_ctxt);
> > break;
> > case ESR_ELx_EC_SMC64:
> > + if (ESR_ELx_xVC_IMM_MASK & esr) {
> > + cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
> > + kvm_skip_host_instr();
> > + break;
> > + }
> > +
>
> I wonder if it isn't better to move that into handle_host_smc() as this is part
> of how we handle the SMC after all? (and it calls that kvm_skip_host_instr()
> already)
Yes, that'd be vastly better.
It also begs the question: if you don't want to handle SMCs with a
non-zero immediate, why is it OK to do it for HVCs?
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: spi: Fix clock-names definition
From: Krzysztof Kozlowski @ 2026-03-25 11:45 UTC (permalink / raw)
To: Meiker Gao
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Bayi Cheng,
Project_Global_Chrome_Upstream_Group, sirius.wang, vince-wl.liu,
jh.hsu, linux-spi, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20260325031900.2099969-2-ot_meiker.gao@mediatek.com>
On Wed, Mar 25, 2026 at 11:18:54AM +0800, Meiker Gao wrote:
> Update the device tree binding for the Mediatek.
That's too vague. Everything is update. Say WHY.
Anyway, you ignored multiple feedbacks, was spamming us with multiple
same postings and still did not improve. There is no versioning here, no
changelog, even subject is using incorrect prefixes.
Read submitting patches and other guidelines before you post, because
you are way past the point of making innocent mistakes and this looks
like wasting our time.
NAK
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 phy-next 10/27] scsi: ufs: qcom: keep parallel track of PHY power state
From: Vladimir Oltean @ 2026-03-25 11:43 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, James E.J. Bottomley, Martin K. Petersen,
Nitin Rawat
In-Reply-To: <ezrcjjwtg5n76w4m65l27szu5mywx66ti3xuprkfcp3x6quvbf@2rew4zrnnbt2>
On Tue, Mar 24, 2026 at 11:00:10AM +0530, Manivannan Sadhasivam wrote:
> On Fri, Mar 20, 2026 at 12:32:24AM +0200, Vladimir Oltean wrote:
> > As explained in the similar ufs-exynos.c change, PHY consumer drivers
> > should not look at the phy->power_count, because in the general case
> > there might also be other consumers who have called phy_power_on() too,
> > so the fact that the power_count is non-zero does not mean that we did.
> >
> > Moreover, struct phy will become opaque soon, so the qcom UFS driver
> > will not be able to apply this pattern. Keep parallel track of the PHY
> > power state, instead of looking at a field which will become unavailable
> > (phy->power_count).
> >
> > About treating the phy_power_off() return code: from an API perspective,
> > this should have probably returned void, otherwise consumers would be
> > stuck in a state they can't escape. The provider, phy-qcom-qmp-ufs.c,
> > does return 0 in its power_off() implementation. I consider it safe to
> > discard potential errors from phy_power_off() instead of complicating
> > the phy_powered_on logic.
> >
>
> You could even simplify the code by getting rid of the 'phy_powered_on' check
> altogether. There is no real need to track the PHY power state in this driver.
> It is safe to call phy_power_off() without any checks.
>
> - Mani
Ok.. as the author of commit 7bac65687510 ("scsi: ufs: qcom: Power off
the PHY if it was already powered on in ufs_qcom_power_up_sequence()"),
I assume you have hardware to test. Would you mind writing a patch that
I could pick up to replace this one with?
I suppose that the power_count test is somehow no longer necessary after
commit 77d2fa54a945 ("scsi: ufs: qcom : Refactor phy_power_on/off
calls"), but frankly I don't see it - the ufshcd state machine is a bit
too complicated for me to just statically analyze.
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: Prevent the host from using an smc with imm16 != 0
From: Sebastian Ene @ 2026-03-25 11:41 UTC (permalink / raw)
To: Vincent Donnefort
Cc: kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
catalin.marinas, joey.gouly, mark.rutland, maz, oupton,
suzuki.poulose, tabba, will, yuzenghui
In-Reply-To: <acPIdoA8oc7T8wKX@google.com>
On Wed, Mar 25, 2026 at 11:35:18AM +0000, Vincent Donnefort wrote:
> On Wed, Mar 25, 2026 at 11:31:38AM +0000, Sebastian Ene wrote:
> > The ARM Service Calling Convention (SMCCC) specifies that the function
> > identifier and parameters should be passed in registers, leaving the
> > 16-bit immediate field of the SMC instruction un-handled.
> > Currently, our pKVM handler ignores the immediate value, which could lead
> > to non-compliant software relying on implementation-defined behavior.
> > Enforce the host kernel running under pKVM to use an immediate value
> > of 0 by decoding the ISS from the ESR_EL2 and return a not supported
> > error code back to the caller.
> >
> > Signed-off-by: Sebastian Ene <sebastianene@google.com>
> > ---
> > v1 -> v2:
> >
> > - Dropped injecting an UNDEF and return an error instead
> > (SMCCC_RET_NOT_SUPPORTED)
> > - Used the mask ESR_ELx_xVC_IMM_MASK instead of masking with U16_MAX
> > - Updated the title of the commit message from:
> > "[PATCH] KVM: arm64: Inject UNDEF when host is executing an
> > smc with imm16 != 0
>
> > ---
> > arch/arm64/kvm/hyp/nvhe/hyp-main.c | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > index e7790097db93..4ffe30fd8707 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > @@ -762,6 +762,12 @@ void handle_trap(struct kvm_cpu_context *host_ctxt)
> > handle_host_hcall(host_ctxt);
> > break;
> > case ESR_ELx_EC_SMC64:
> > + if (ESR_ELx_xVC_IMM_MASK & esr) {
> > + cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
> > + kvm_skip_host_instr();
> > + break;
> > + }
> > +
>
> I wonder if it isn't better to move that into handle_host_smc() as this is part
> of how we handle the SMC after all? (and it calls that kvm_skip_host_instr()
> already)
>
I was thinking of doing that as well but I prefer this since we don't
have to look again at the esr in the callee.
> > handle_host_smc(host_ctxt);
> > break;
> > case ESR_ELx_EC_IABT_LOW:
> > --
> > 2.53.0.1018.g2bb0e51243-goog
> >
^ permalink raw reply
* Re: [PATCH] ASoC: dt-bindings: rockchip: Convert rockchip-max98090.txt to yaml
From: Krzysztof Kozlowski @ 2026-03-25 11:36 UTC (permalink / raw)
To: Fabio Estevam
Cc: broonie, heiko, robh, krzk+dt, conor+dt, linux-sound, devicetree,
linux-rockchip, linux-kernel, linux-arm-kernel
In-Reply-To: <20260324135508.839142-1-festevam@gmail.com>
On Tue, Mar 24, 2026 at 10:55:08AM -0300, Fabio Estevam wrote:
> +
> +properties:
> + compatible:
> + const: rockchip,rockchip-audio-max98090
Not the best compatible ever :)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: Prevent the host from using an smc with imm16 != 0
From: Vincent Donnefort @ 2026-03-25 11:35 UTC (permalink / raw)
To: Sebastian Ene
Cc: kvmarm, linux-arm-kernel, linux-kernel, android-kvm,
catalin.marinas, joey.gouly, mark.rutland, maz, oupton,
suzuki.poulose, tabba, will, yuzenghui
In-Reply-To: <20260325113138.4171430-1-sebastianene@google.com>
On Wed, Mar 25, 2026 at 11:31:38AM +0000, Sebastian Ene wrote:
> The ARM Service Calling Convention (SMCCC) specifies that the function
> identifier and parameters should be passed in registers, leaving the
> 16-bit immediate field of the SMC instruction un-handled.
> Currently, our pKVM handler ignores the immediate value, which could lead
> to non-compliant software relying on implementation-defined behavior.
> Enforce the host kernel running under pKVM to use an immediate value
> of 0 by decoding the ISS from the ESR_EL2 and return a not supported
> error code back to the caller.
>
> Signed-off-by: Sebastian Ene <sebastianene@google.com>
> ---
> v1 -> v2:
>
> - Dropped injecting an UNDEF and return an error instead
> (SMCCC_RET_NOT_SUPPORTED)
> - Used the mask ESR_ELx_xVC_IMM_MASK instead of masking with U16_MAX
> - Updated the title of the commit message from:
> "[PATCH] KVM: arm64: Inject UNDEF when host is executing an
> smc with imm16 != 0
> ---
> arch/arm64/kvm/hyp/nvhe/hyp-main.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index e7790097db93..4ffe30fd8707 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -762,6 +762,12 @@ void handle_trap(struct kvm_cpu_context *host_ctxt)
> handle_host_hcall(host_ctxt);
> break;
> case ESR_ELx_EC_SMC64:
> + if (ESR_ELx_xVC_IMM_MASK & esr) {
> + cpu_reg(host_ctxt, 0) = SMCCC_RET_NOT_SUPPORTED;
> + kvm_skip_host_instr();
> + break;
> + }
> +
I wonder if it isn't better to move that into handle_host_smc() as this is part
of how we handle the SMC after all? (and it calls that kvm_skip_host_instr()
already)
> handle_host_smc(host_ctxt);
> break;
> case ESR_ELx_EC_IABT_LOW:
> --
> 2.53.0.1018.g2bb0e51243-goog
>
^ permalink raw reply
* [PATCH 4/4] arm64: dts: imx8mp-skov: support new 7inch panel board
From: Steffen Trumtrar @ 2026-03-25 11:32 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Shawn Guo, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Steffen Trumtrar
In-Reply-To: <20260325-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v1-0-10255d236439@pengutronix.de>
This board is similar to the already upstream
imx8mp-skov-revc-tian-g07017.dts but uses a different 7" panel with a
different touch controller.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../imx8mp-skov-revc-jutouch-jt070tm041.dts | 79 ++++++++++++++++++++++
2 files changed, 80 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 700bab4d3e600..bdb07cbc001e9 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -289,6 +289,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revb-mi1010ait-1cp1.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-bd500.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-hdmi.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-tian-g07017.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-jutouch-jt070tm041.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-jutouch-jt101tm023.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-toradex-smarc-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mpxl.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-jutouch-jt070tm041.dts b/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-jutouch-jt070tm041.dts
new file mode 100644
index 0000000000000..56374f1e67663
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-skov-revc-jutouch-jt070tm041.dts
@@ -0,0 +1,79 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+
+/dts-v1/;
+
+#include "imx8mp-skov-reva.dtsi"
+
+/ {
+ model = "SKOV IMX8MP CPU revC - JuTouch JT070TM041";
+ compatible = "skov,imx8mp-skov-revc-jutouch-jt070tm041", "fsl,imx8mp";
+
+ panel {
+ compatible = "jutouch,jt070tm041";
+ backlight = <&backlight>;
+ power-supply = <®_tft_vcom>;
+
+ port {
+ in_lvds0: endpoint {
+ remote-endpoint = <&ldb_lvds_ch0>;
+ };
+ };
+ };
+};
+
+&backlight {
+ status = "okay";
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ status = "okay";
+
+ touchscreen@2a {
+ compatible = "eeti,exc81w32";
+ reg = <0x2a>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_touchscreen>;
+ interrupts-extended = <&gpio4 28 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio4 29 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <1024>;
+ touchscreen-size-y = <600>;
+ vdd-supply = <®_vdd_3v3>;
+ };
+};
+
+&lcdif2 {
+ status = "okay";
+};
+
+&lvds_bridge {
+ assigned-clocks = <&clk IMX8MP_CLK_MEDIA_LDB>,
+ <&clk IMX8MP_VIDEO_PLL1>;
+ assigned-clock-parents = <&clk IMX8MP_VIDEO_PLL1_OUT>;
+ /* IMX8MP_VIDEO_PLL1 = IMX8MP_CLK_MEDIA_DISP2_PIX * 2 * 7 */
+ assigned-clock-rates = <0>, <358400000>;
+ status = "okay";
+
+ ports {
+ port@1 {
+ ldb_lvds_ch0: endpoint {
+ remote-endpoint = <&in_lvds0>;
+ };
+ };
+ };
+};
+
+&pwm4 {
+ status = "okay";
+};
+
+&pwm1 {
+ status = "okay";
+};
+
+®_tft_vcom {
+ regulator-min-microvolt = <3160000>;
+ regulator-max-microvolt = <3160000>;
+ voltage-table = <3160000 73>;
+ status = "okay";
+};
--
2.51.0
^ permalink raw reply related
* [PATCH 3/4] dt-bindings: arm: fsl: add compatible for new Skov I.MX8MP variant
From: Steffen Trumtrar @ 2026-03-25 11:32 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Shawn Guo, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Steffen Trumtrar
In-Reply-To: <20260325-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v1-0-10255d236439@pengutronix.de>
In preparation for adding a new device tree variant with a different 7"
panel, describe the DT compatible in the binding.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 5716d701292cf..84ebc8c28b70a 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1122,6 +1122,7 @@ properties:
- skov,imx8mp-skov-revb-mi1010ait-1cp1 # SKOV i.MX8MP climate control with 10.1" panel
- skov,imx8mp-skov-revc-hdmi # SKOV i.MX8MP climate control without panel
- skov,imx8mp-skov-revc-bd500 # SKOV i.MX8MP climate control with LED frontplate
+ - skov,imx8mp-skov-revc-jutouch-jt070tm041 # SKOV i.MX8MP climate control with 7" JuTouch panel
- skov,imx8mp-skov-revc-jutouch-jt101tm023 # SKOV i.MX8MP climate control with 10" JuTouch panel
- skov,imx8mp-skov-revc-tian-g07017 # SKOV i.MX8MP climate control with 7" panel
- ultratronik,imx8mp-ultra-mach-sbc # Ultratronik SBC i.MX8MP based board
--
2.51.0
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: display: simple: Add JuTouch JT070TM041 panel
From: Steffen Trumtrar @ 2026-03-25 11:31 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Shawn Guo, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Steffen Trumtrar
In-Reply-To: <20260325-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v1-0-10255d236439@pengutronix.de>
Add the JuTouch Technology Co. 7" JT070TM041 LVDS panel.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
index 868edb04989a5..7a6a4e0db90d6 100644
--- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
+++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml
@@ -188,6 +188,8 @@ properties:
- innolux,n156bge-l21
# Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel
- innolux,zj070na-01p
+ # JuTouch Technology Co.. 7" JT070TM041 WSVGA (1024 x 600) LVDS panel
+ - jutouch,jt070tm041
# JuTouch Technology Co.. 10" JT101TM023 WXGA (1280 x 800) LVDS panel
- jutouch,jt101tm023
# Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel
--
2.51.0
^ permalink raw reply related
* [PATCH 2/4] drm/panel: simple: add JuTouch JT070TM041
From: Steffen Trumtrar @ 2026-03-25 11:32 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Shawn Guo, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Steffen Trumtrar
In-Reply-To: <20260325-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v1-0-10255d236439@pengutronix.de>
Add JuTouch Technology JT070TM041 7" 1024x600 LVDS panel support.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
drivers/gpu/drm/panel/panel-simple.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 91ab280869bac..6ac263f83793b 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2940,6 +2940,35 @@ static const struct panel_desc innolux_zj070na_01p = {
},
};
+static const struct display_timing jutouch_jt070tm041_timing = {
+ .pixelclock = { 40800000, 51200000, 67200000 },
+ .hactive = { 1024, 1024, 1024 },
+ .hfront_porch = { 16, 160, 216 },
+ .hback_porch = { 160, 160, 160 },
+ .hsync_len = { 1, 1, 140 },
+ .vactive = { 600, 600, 600 },
+ .vfront_porch = { 1, 12, 127 },
+ .vback_porch = { 23, 23, 23 },
+ .vsync_len = { 1, 1, 20 },
+};
+
+static const struct panel_desc jutouch_jt070tm041 = {
+ .timings = &jutouch_jt070tm041_timing,
+ .num_timings = 1,
+ .bpc = 8,
+ .size = {
+ .width = 154,
+ .height = 86,
+ },
+ .delay = {
+ .enable = 50,
+ .disable = 50,
+ },
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct display_timing jutouch_jt101tm023_timing = {
.pixelclock = { 66300000, 72400000, 78900000 },
.hactive = { 1280, 1280, 1280 },
@@ -5352,6 +5381,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "innolux,zj070na-01p",
.data = &innolux_zj070na_01p,
+ }, {
+ .compatible = "jutouch,jt070tm041",
+ .data = &jutouch_jt070tm041,
}, {
.compatible = "jutouch,jt101tm023",
.data = &jutouch_jt101tm023,
--
2.51.0
^ permalink raw reply related
* [PATCH 0/4] arm64: dts: imx8mp-skov: add new 7" variant
From: Steffen Trumtrar @ 2026-03-25 11:31 UTC (permalink / raw)
To: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Shawn Guo, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Steffen Trumtrar
Add a new board variant for the Skov i.MX8MP based family of boards.
This variant uses a different 7" panel than the existing ones.
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
Steffen Trumtrar (4):
dt-bindings: display: simple: Add JuTouch JT070TM041 panel
drm/panel: simple: add JuTouch JT070TM041
dt-bindings: arm: fsl: add compatible for new Skov I.MX8MP variant
arm64: dts: imx8mp-skov: support new 7inch panel board
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
.../bindings/display/panel/panel-simple.yaml | 2 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../imx8mp-skov-revc-jutouch-jt070tm041.dts | 79 ++++++++++++++++++++++
drivers/gpu/drm/panel/panel-simple.c | 32 +++++++++
5 files changed, 115 insertions(+)
---
base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
change-id: 20260325-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-3dbcb450a39c
Best regards,
--
Steffen Trumtrar <s.trumtrar@pengutronix.de>
^ permalink raw reply
* Re: [PATCH v13 00/48] arm64: Support for Arm CCA in KVM
From: Suzuki K Poulose @ 2026-03-25 11:32 UTC (permalink / raw)
To: Gavin Shan, Steven Price, Mathieu Poirier
Cc: kvm, kvmarm, Catalin Marinas, Marc Zyngier, Will Deacon,
James Morse, Oliver Upton, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve
In-Reply-To: <9247d9ea-64b4-4e8e-81f8-3c8e00750acf@arm.com>
On 25/03/2026 10:16, Suzuki K Poulose wrote:
> Hi Gavin
>
> Steven is on holidays, so I am jumping in here.
>
> On 25/03/2026 06:37, Gavin Shan wrote:
>> Hi Steven,
>>
>> On 3/21/26 2:45 AM, Steven Price wrote:
>>> On 19/03/2026 23:02, Mathieu Poirier wrote:
>>
>> [...]
>>
>>>>>
>>>>> The TF-RMM has not yet merged the RMMv2.0 support, so you will need to
>>>>> use the following branch:
>>>>>
>>>>> https://git.trustedfirmware.org/TF-RMM/tf-rmm.git topics/rmm-v2.0-poc
>>>>
>>>> This RMM version is expecting a RMM EL3 interface version of at
>>>> least 2.0. Do
>>>> you have a TF-A to use with it?
>>>
>>> You should be able to use the 'master' branch of the TF-A repository.
>>> For now you need to set RMM_V1_COMPAT=0 to enable 2.0 support.
>>>
>>
>> In upstream TF-A repository [1], I don't see the config option
>> 'RMM_V1_COMPAT'.
>> would it be something else?
>>
>> [1] git@github.com:ARM-software/arm-trusted-firmware.git (branch:
>> master)
>>
>
> suzuki@ewhatever:trusted-firmware-a$ git grep RMM_V1_COMPAT
> Makefile: RMM_V1_COMPAT \
> Makefile: RMM_V1_COMPAT \
> docs/getting_started/build-options.rst:- ``RMM_V1_COMPAT``: Boolean
> flag to enable support for RMM v1.x compatibility
> include/services/rmmd_svc.h:#if RMM_V1_COMPAT
> include/services/rmmd_svc.h:#endif /* RMM_V1_COMPAT */
> make_helpers/defaults.mk:RMM_V1_COMPAT := 1
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if !RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_main.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
> services/std_svc/rmmd/rmmd_rmm_lfa.c:#if RMM_V1_COMPAT
> suzuki@ewhatever:trusted-firmware-a$ git log --oneline -1
> 8dae0862c (HEAD, origin/master, origin/integration, origin/HEAD) Merge
> changes from topic "qti_lemans_evk" into integration
> suzuki@ewhatever:trusted-firmware-a$ git remote get-url origin
> https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
>
>
>
>> I use the following command to build TF-A image. The RMM-EL3
>> compatible issue is
>> still seen.
>>
>> TFA_PATH=$PWD
>> EDK2_IMAGE=${TFA_PATH}/../edk2/Build/ArmVirtQemuKernel-AARCH64/
>> RELEASE_GCC5/FV/QEMU_EFI.fd
>> RMM_IMAGE=${TFA_PATH}/../tf-rmm/build-qemu/Debug/rmm.img
>> make CROSS_COMPILE=aarch64-none-elf- \
>> PLAT=qemu ENABLE_RME=1 RMM_V1_COMPAT=0 DEBUG=1 LOG_LEVEL=40 \
>> QEMU_USE_GIC_DRIVER=QEMU_GICV3 \
>> BL33=${EDK2_IMAGE} RMM=${RMM_IMAGE} \
>> -j 8 all fip
>>
>
>
>
>
>> Booting messages
>> ================
>> INFO: BL31: Initializing runtime services
>> INFO: RMM setup done.
>> INFO: BL31: Initializing RMM
>> INFO: RMM init start.
>> ERROR: RMM init failed: -2
>> WARNING: BL31: RMM initialization failed
>
> This is definitely the TF-A RMM incompatibility.
>
> Btw, the shrinkwrap overlay configs in tf-RMM repository should work.
> But unfortunately the Linux/kvmtool repositories are pointing to
> internal repositories. The following patch should fix it and get
> it all working. I am working with the tf-rmm team to fix this.
This is now fixed in the branch :
https://git.trustedfirmware.org/plugins/gitiles/TF-RMM/tf-rmm/+/refs/heads/topics/rmm-v2.0-poc/tools/shrinkwrap/configs/cca.yaml
Cheers
Suzuki
^ 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