arm64: rockchip: add MIPI CSI camera pipeline support for RK3576 by hz2 · Pull Request #10 · flipperdevices/flipper-linux-kernel

hz2 · 2026-05-22T16:27:04Z

Adds initial MIPI CSI-2 camera capture support for the RK3576 SoC, porting the existing RK3588 pipeline to the RK3576. The two SoCs share the same IP blocks (Innosilicon CSI DPHY, Synopsys DW CSI-2 Host, Rockchip VICAP) with minor differences in instance count and register base addresses.

RK3576 has 2 Inno CSI DPHY instances, 5 CSI Host controllers, and a VICAP unit with 5 MIPI input ports (vs 6 on RK3588).

Register addresses and layouts were verified against the RK3576 TRM V1.2 Part 2 and the Rockchip BSP kernel (develop-6.1 branch).

Changes:

phy: rockchip: inno-csidphy: add rockchip,rk3576-csi-dphy compatible
media: synopsys: dw-mipi-csi2rx: add rockchip,rk3576-mipi-csi2 compatible
media: rockchip: rkcif: add rockchip,rk3576-vicap with 5-port MIPI support
arm64: dts: rockchip: add VICAP, CSI Host, CSIDPHY, and GRF nodes to rk3576.dtsi

This is still missing DT binding YAML updates and board-level DTS wiring (sensor not yet identified for Flipper One). Compile-tested with the flipperone-linux-build-scripts config, RK3576 DTBs builds.

Closes #6

alchark · 2026-05-22T17:07:29Z

Thanks for your contribution!

As we are targeting mainline Linux kernel, we'll need to follow the mainline Linux contribution rules - in particular the part about the Developer Certificate of Origin there (i.e. please include your real name and email address in both the patch author information and the Signed-off-by: trailer to assert the DCO).

Are you certain that there is no register-level difference vs. RK3588? Rockchip's downstream driver has some GRF registers used by RK3588 but not RK3576

Please also check if https://docs.kernel.org/process/coding-assistants.html applies and also if Rockchip authorship/sign-off needs to be preserved in any of the patches (depending on how much of this was copied from the downstream develop-6.1 kernel)

hz2 · 2026-05-22T17:36:11Z

Thanks for getting back so quickly!

As we are targeting mainline Linux kernel, we'll need to follow the mainline Linux contribution rules - in particular the part about the Developer Certificate of Origin there (i.e. please include your real name and email address in both the patch author information and the Signed-off-by: trailer to assert the DCO).

added DCO, somewhat familiar with the process

Are you certain that there is no register-level difference vs. RK3588? Rockchip's downstream driver has some GRF registers used by RK3588 but not RK3576

RK3576 uses sys_grf for lane select at 0x14 (GRF_SOC_CON5), where RK3588 uses 0x308 (GRF_SOC_CON2). Mainline doesn't have sys_grf at all currently, only writes GRF for lane and clock enable i believe. the register layout is identical between RK3576 and RK3588 when looking at BSP source and TRM, however, sys_grf is missing from this series and will be added. for the flipper-one use case, per-PHY GRF writes should be sufficient? i'll add sys_grf support in a follow-up or fold it into this series before submitting to the lists, open to your thoughts here as well.

Please also check if https://docs.kernel.org/process/coding-assistants.html applies

ack, will review and comply

also if Rockchip authorship/sign-off needs to be preserved in any of the patches (depending on how much of this was copied from the downstream develop-6.1 kernel)

no code was copied from the BSP driver, the driver changes follow mainline patterns (RK3588 entries already in-tree) and register addresses come from TRM and BSP DTS so no Rockchip sign-off should be needed here but please keep me honest.

plan would be to address the sys_grf gap i mentioned and add DT binding YAML updates then submit a proper patch series to:

accordingly. happy to hear if you think anything else needs to change before that.

ps: wouldn't hurt to get a dev flipper one to test with 👀

alchark · 2026-05-22T19:31:41Z

FWIW, our builds didn't enable the CSI2 driver and its siblings up to now - I've just changed that. It builds fine with your patches, thank you!

Do you have any RK3576 based board to test it on? It would be great to also add the necessary board DTS nodes along with sensor-specific DTSO

hz2 · 2026-05-22T20:26:54Z

FWIW, our builds didn't enable the CSI2 driver and its siblings up to now - I've just changed that. It builds fine with your patches, thank you!

great! i tried it in a nix-shell (probably should have mentioned that) previously when building locally

Do you have any RK3576 based board to test it on?

i do not atm (why i asked about a dev board)

It would be great to also add the necessary board DTS nodes along with sensor-specific DTSO

agree that the sensor wiring should go in a DTSO, assuming sensor choice isn't finalized, right? happy to work on the overlay once ik what module to target

hz2 · 2026-05-30T05:09:51Z

will be sending a RFC to mailing list to denote i haven't tested on hardware and get feedback

alchark · 2026-06-01T08:55:39Z

+			resets = <&cru SRST_P_CSIPHY>, <&cru SRST_SCAN_CSIPHY>;
+			reset-names = "apb", "phy";
+			rockchip,grf = <&mipidphy0_grf>;
+			rockchip,sys-grf = <&sys_grf>;


Is this part of the binding?

Please make sure all your DT changes are tested against schema with W=1

alchark · 2026-06-01T09:05:22Z

+		struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+
+		priv->sys_grf_lane_sel_bit = (res && res->start == 0x2b070000) ? 2 : 1;


Ouch, this looks ugly. Firstly, you are not guarding this block by a particular SoC compatible but use a SoC specific MMIO address. Secondly, this should probably be encoded as a data attribute somewhere instead of hardcoding register addresses.

Ouch, this looks ugly.

Thanks! lol

Fair enough, one thing I can't verify without hardware: does rk3576 full mode actually need the SYS_GRF_SOC_CON5 write, or is the reset default already full mode? That decides whether I drop it cleanly or rework it in place.

When it comes back I'd carry the lane select bit as a phandle arg, rockchip,sys-grf = <&sys_grf 1>, read with syscon_regmap_lookup_by_phandle_args, rather than sniffing the MMIO address

alchark · 2026-06-01T09:06:31Z

+	priv->sys_grf = syscon_regmap_lookup_by_phandle(dev->of_node,
+							"rockchip,sys-grf");
+	if (IS_ERR(priv->sys_grf))
+		priv->sys_grf = NULL;


Will it work on RK3576 if a sys-grf is not provided? If not, this should be an explicit error path instead of covering it up with a NULL.

alchark · 2026-06-01T09:13:10Z

+				csi4_in: port@0 {
+					reg = <0>;
+				};


Are these supposed to be empty?

Yes, those are intentional, they are attach points, not omissions. Each csiN port@0 is the sensor side input, left as a bare labeled node in the SoC dtsi so a board file or overlay can attach the sensor endpoint through &csiN_in.

Happy to add a comment there if it reads better.

hz2 · 2026-06-03T17:28:17Z

I'd like to drop the sys_grf lane select from this series and bring it back as a proper follow-up. The precedent is your own upstream RK3588 CSI DPHY support: the BSP has the lane select (rk3588_grf_dphy_regs, GRF_SOC_CON2 bit 6) but the mainline rk3588 variant left it out, and the upstream rk3588 csi_dphy nodes carry only rockchip,grf, never a sys_grf. RK3576 is the same IP and the target boards all use a single 2 lane PHY in full mode, so the core port should stand on its own the same way.

The one thing I cannot verify: does RK3576 full mode actually work without writing SYS_GRF_SOC_CON5? TRM Part 2 only gives the bit meaning (bit 1 = DPHY0, bit 2 = DPHY1, 0 = full, 1 = split), not the reset value, and the BSP writes it explicitly even for full mode. If POR is full mode, dropping is safe. If not, I should rework it in-series instead. If you'd rather keep it in-series, the plan is to carry the lane select bit as a DT phandle arg, rockchip,sys-grf = <&sys_grf 1>, read with syscon_regmap_lookup_by_phandle_args, so there's no MMIO address sniffing and no offset sentinel.

Open to a different representation.

Also log to normal dmesg to assist debugging hard reset issues. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Add a new DIV_ROUND_UP helper, which cannot overflow when big numbers are being used. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

The clock framework handles clock rates as "unsigned long", so u32 on 32-bit architectures and u64 on 64-bit architectures. The current code casts the dividend to u64 on 32-bit to avoid a potential overflow. For example DIV_ROUND_UP(3000000000, 1500000000) = (3.0G + 1.5G - 1) / 1.5G = = OVERFLOW / 1.5G, which has been introduced in commit 9556f9d ("clk: divider: handle integer overflow when dividing large clock rates"). On 64 bit platforms this masks the divisor, so that only the lower 32 bit are used. Thus requesting a frequency >= 4.3GHz results in incorrect values. For example requesting 4300000000 (4.3 GHz) will effectively request ca. 5 MHz. Requesting clk_round_rate(clk, ULONG_MAX) is a bit of a special case, since that still returns correct values as long as the parent clock is below 8.5 GHz. Fix this by switching to DIV_ROUND_UP_NO_OVERFLOW, which cannot overflow. This avoids any requirements on the arguments (except that divisor should not be 0 obviously). Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Replace the open coded abs_diff() with the existing helper function. Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Add rfkill support for bluetooth. Bluetooth support itself is still missing, but this ensures bluetooth can be powered off properly. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Also describe wake signal PCIe pinmux for the onboard LAN card. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

This drops to hs200 mode and 150Mhz as this is actually stable across eMMC modules. There exist some that are incompatible at higher rates with the rk3588 and to avoid your filesystem corrupting due to IO errors, be more conservative and reduce the max. speed. Signed-off-by: Carsten Haitzler <raster@rasterman.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

When I converted rk808 to device managed resources I converted the rk808 specific pm_power_off handler to devm_register_sys_off_handler() using SYS_OFF_MODE_POWER_OFF_PREPARE, which is allowed to sleep. I did this because the driver's poweroff function makes use of regmap and the backend of that might sleep. But the PMIC poweroff function will kill off the board power and the kernel does some extra steps after the prepare handler. Thus the prepare handler should not be used for the PMIC's poweroff routine. Instead the normal SYS_OFF_MODE_POWER_OFF phase should be used. The old pm_power_off method is also being called from there, so this would have been a cleaner conversion anyways. But it still makes sense to investigate the sleep handling and check if there are any issues. Apparently the Rockchip and Meson I2C drivers (the only platforms using the PMICs handled by this driver) both have support for atomic transfers and thus may be called from the atomic poweroff context. Things are different on the SPI side. That is so far only used by rk806 and that one is only used by Rockchip RK3588. Unfortunately the Rockchip SPI driver does not support atomic transfers. That means this change will introduce an error splash directly before doing the final power off on all upstream supported RK3588 boards: [ 13.761353] ------------[ cut here ]------------ [ 13.761764] Voluntary context switch within RCU read-side critical section! [ 13.761776] WARNING: CPU: 0 PID: 1 at kernel/rcu/tree_plugin.h:330 rcu_note_context_switch+0x3ac/0x404 [ 13.763219] Modules linked in: [ 13.763498] CPU: 0 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.10.0-12284-g2818a9a19514 #1499 [ 13.764297] Hardware name: Rockchip RK3588 EVB1 V10 Board (DT) [ 13.764812] pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 13.765427] pc : rcu_note_context_switch+0x3ac/0x404 [ 13.765871] lr : rcu_note_context_switch+0x3ac/0x404 [ 13.766314] sp : ffff800084f4b5b0 [ 13.766609] x29: ffff800084f4b5b0 x28: ffff00040139b800 x27: 00007dfb4439ae80 [ 13.767245] x26: ffff00040139bc80 x25: 0000000000000000 x24: ffff800082118470 [ 13.767880] x23: 0000000000000000 x22: ffff000400300000 x21: ffff000400300000 [ 13.768515] x20: ffff800083a9d600 x19: ffff0004fee48600 x18: fffffffffffed448 [ 13.769151] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000048 [ 13.769787] x14: fffffffffffed490 x13: ffff80008473b3c0 x12: 0000000000000900 [ 13.770421] x11: 0000000000000300 x10: ffff800084797bc0 x9 : ffff80008473b3c0 [ 13.771057] x8 : 00000000ffffefff x7 : ffff8000847933c0 x6 : 0000000000000300 [ 13.771692] x5 : 0000000000000301 x4 : 40000000fffff300 x3 : 0000000000000000 [ 13.772328] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000400300000 [ 13.772964] Call trace: [ 13.773184] rcu_note_context_switch+0x3ac/0x404 [ 13.773598] __schedule+0x94/0xb0c [ 13.773907] schedule+0x34/0x104 [ 13.774198] schedule_timeout+0x84/0xfc [ 13.774544] wait_for_completion_timeout+0x78/0x14c [ 13.774980] spi_transfer_one_message+0x588/0x690 [ 13.775403] __spi_pump_transfer_message+0x19c/0x4ec [ 13.775846] __spi_sync+0x2a8/0x3c4 [ 13.776161] spi_write_then_read+0x120/0x208 [ 13.776543] rk806_spi_bus_read+0x54/0x88 [ 13.776905] _regmap_raw_read+0xec/0x16c [ 13.777257] _regmap_bus_read+0x44/0x7c [ 13.777601] _regmap_read+0x60/0xd8 [ 13.777915] _regmap_update_bits+0xf4/0x13c [ 13.778289] regmap_update_bits_base+0x64/0x98 [ 13.778686] rk808_power_off+0x70/0xfc [ 13.779024] sys_off_notify+0x40/0x6c [ 13.779356] atomic_notifier_call_chain+0x60/0x90 [ 13.779776] do_kernel_power_off+0x54/0x6c [ 13.780146] machine_power_off+0x18/0x24 [ 13.780499] kernel_power_off+0x70/0x7c [ 13.780845] __do_sys_reboot+0x210/0x270 [ 13.781198] __arm64_sys_reboot+0x24/0x30 [ 13.781558] invoke_syscall+0x48/0x10c [ 13.781897] el0_svc_common+0x3c/0xe8 [ 13.782228] do_el0_svc+0x20/0x2c [ 13.782528] el0_svc+0x34/0xd8 [ 13.782806] el0t_64_sync_handler+0x120/0x12c [ 13.783197] el0t_64_sync+0x190/0x194 [ 13.783527] ---[ end trace 0000000000000000 ]--- The board will shutdown nevertheless, since this also re-enables interrupts. A proper fix for this requires changes to the core SPI subsystem and will be done as a follow-up series. Note, that this patch also fixes a problem for the Asus C201. Without the function being registered as a proper shutdown handler the syscall for poweroff exits early and does not even call the shutdown prepare handler. This in turn means the system can no longer poweroff properly since my original change. Fixes: 4fec8a5 ("mfd: rk808: Convert to device managed resources") Cc: stable@vger.kernel.org Reported-by: Urja <urja@urja.dev> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Add the documentation for VOP2 video ports reset clocks. One reset can be set per video port. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>

At the end of initialization, each VP clock needs to be reset before they can be used. Failing to do so can put the VOP in an undefined state where the generated HDMI signal is either lost or not matching the selected mode. This issue can be reproduced by switching modes multiple times. Depending on the setup, after about 10 mode switches, the signal will be lost and the value in register 0x890 (VSYNCWIDTH + VFRONT) will take the value `0x0000018c`. That makes VSYNCWIDTH=0, which is wrong. Adding the clock resets after the VOP configuration fixes the issue. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>

This adds the needed clock resets for all rk3588(s) based SOCs. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>

The RK3588 EVB1 comes with a W552793DBA-V10 Touchscreen/Display combination. It contains a Wanchanglong W552793BAA panel and a Goodix GT1158 touchscreen. This adds the DT description of it. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

A previous from Detlev Casanova adds reset handling for the video ports. This also resets the AHB and AXI interface when the system binds the VOP2 controller. This fixes issues when the bootloader (or a previously running kernel when using kexec) left the VOP2 initialized to some degree. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Fix the USB-C connector description, so that it follows the binding: port@0 is the high-speed lanes port@1 is the super-speed lanes port@2 is the SBU lanes Right now the high-speed and super-speed links are swapped and for the high-speed lanes the link points to the controller instead of the PHY. I'm still investigating if this should be changed. This also updates the port naming, so that it describes the hardware instead of how the drivers are using the information. These are effectively the same, but the DT should describe hardware and not software. Fixes: b37146b ("arm64: dts: rockchip: add USB3 to rk3588-evb1") Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Any camera related IP of the RK3588 is not yet supported and the cameras must be handled via overlays anyways, but it is sensible to expose the related I2C interfaces by default. This allows using i2cdetect to investigate anything connected to the CSI connectors right now. Since the Rockchip I2C driver implements proper power management there are no disadvantages, if nothing is connected to the port. Note, that the second CSI port's I2C in the Rock 5B+ and Rock 5T reuse I2C4, which is already used by fusb302 and thus already enabled. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

With USB type C connectors, the vbus detect pin of the OTG controller attached to it is pulled high by a USB Type C controller chip such as the fusb302. This means USB enumeration on Type-C ports never works, as the vbus is always seen as high. Rockchip added some GRF register flags to deal with this situation. The RK3576 TRM calls these "soft_vbusvalid_bvalid" (con0 bit index 15) and "soft_vbusvalid_bvalid_sel" (con0 bit index 14). Downstream introduces a new vendor property which tells the USB 2 PHY that it's connected to a type C port, but we can do better. Since in such an arrangement, we'll have an OF graph connection from the USB controller to the USB connector anyway, we can walk said OF graph and check the connector's compatible to determine this without adding any further vendor properties. Do keep in mind that the usbdp PHY driver seemingly fiddles with these register fields as well, but what it does doesn't appear to be enough for us to get working USB enumeration, presumably because the whole vbus_attach logic needs to be adjusted as well either way. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250610-rk3576-sige5-usb-v4-1-7e7f779619c1@collabora.com Signed-off-by: Sebastian Reichel <sre@kernel.org>

adc-keys, unlike gpio-keys, does not allow linux,input-type as a valid property. This makes it impossible to model devices that have ADC inputs that should generate switch events. Add the property to the binding with the same default as gpio-keys. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250630-rock4d-audio-v1-1-0b3c8e8fda9c@collabora.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

Instead of doing something like what gpio-keys is doing, adc-keys hardcodes that all keycodes must be of type EV_KEY. This limits the usefulness of adc-keys, and overcomplicates the code with manual bit-setting logic. Instead, refactor the code to read the linux,input-type fwnode property, and get rid of the custom bit setting logic, replacing it with input_set_capability instead. input_report_key is replaced with input_event, which allows us to explicitly pass the type. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250630-rock4d-audio-v1-2-0b3c8e8fda9c@collabora.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

The RADXA ROCK 4D, like many other Rockchip-based boards, uses an ES8388 analog audio codec. On the production version of the board, the codec's LOUT1 and ROUT1 pins are tied to the headphone jack, whereas pins LOUT2 and ROUT2 lead to a non-populated speaker amplifier that itself leads to a non-populated speaker jack. The schematic is still haunted by the ghosts of those symbols, but it clearly marks them as "NC". The 3.5mm TRRS jack has its microphone ring (and ground ring) wired to the codec's LINPUT1 and RINPUT1 pins for differential signalling. Furthermore, it uses the SoCs ADC to detect whether the inserted cable is of headphones (i.e., no microphone), or a headset (i.e., with microphone). The way this is done is that the ADC input taps the output of a 100K/100K resistor divider that divides the microphone ring pin that's pulled up to 3.3V. There is no ADC level difference between a completely empty jack and one with a set of headphones (i.e., ones that don't have a microphone) connected. Consequently headphone insertion detection isn't something that can be done. Add the necessary codec and audio card nodes. The non-populated parts, i.e. LOUT2 and ROUT2, are not modeled at all, as they are not present on the hardware. Also, add an adc-keys node for the headset detection, which uses an input type of EV_SW with the SW_MICROPHONE_INSERT keycode. Below the 220mV pressed voltage level of our SW_MICROPHONE_INSERT switch, we also define a button that emits a KEY_RESERVED code, which is there to model this part of the voltage range as not just being extra legroom for the button above it, but actually a state that is encountered in the real world, and should be recognised as a valid state for the ADC range to be in so that no "closer" ADC button is chosen. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Link: https://lore.kernel.org/r/20250630-rock4d-audio-v1-3-0b3c8e8fda9c@collabora.com Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

The Flipper One networking multitool has a number of RGB LEDs on its front panel, four of which (the "link" LEDs) can be controlled by the user. They are driven by the Flipper One MCU, which exposes them as registers over the I2C interconnect bus (single RGB565 value per LED). Add a driver to expose them to the user. Signed-off-by: Alexey Charkov <alchark@flipper.net>

NAU8822 has 4 power supply pins: VDDA, VDDB, VDDC and VDDSPK, which need to be online and stable before communication with the device is attempted. List them (as optional) so that device tree users can ensure correct power sequencing. Signed-off-by: Alexey Charkov <alchark@flipper.net>

NAU8822 has four power supply pins: VDDA, VDDB, VDDC, and VDDSPK, which need to be online and stable before communication with the device is attempted. Request and enable these regulators at init time, if provided. Also wait for 100 us after powering up the supply regulators before attempting to access the device registers, as recommended by the datasheet. This helps avoid -ENXIO errors when the codec is probed before the regulators are ready. Signed-off-by: Alexey Charkov <alchark@flipper.net>

Reparent dclk_vp{0,1}_src from GPLL to VPLL on Rockchip RK3576. VPLL is a programmable PLL with no other consumers, allowing the CCF to synthesize accurate pixel clocks for the two display outputs with arbitrary modes, as long as only one of them is active at a time (or using the HDMI PHY as the clock source, which works for HDMI modes up to 4K@60Hz). This gives much greater flexibility for display modes as compared to the boot-time default of using GPLL, which is effectively fixed at 1188 MHz due to a large number of system components depending on it and making runtime rate changes unrealistic. Signed-off-by: Alexey Charkov <alchark@flipper.net>

RK3588/RK3576 have several fractional PLLs using a delta-sigma adjustment factor (k) for the fractional component of the PLL output frequency. According to the TRM, the k is a two's complement 16-bit value, not an unsiged integer (see for example the TRM description of CRU_GPLL_CON2, and also a related U-boot fix at [1]). Adjust the code to properly handle negative k values. While at it, also fix the denominator to use the correct value of 65536, not 65535 for the full range of PLL ratios. Cc: stable@vger.kernel.org Fixes: 8f65944 ("clk: rockchip: add pll type for RK3588") Link: https://lore.kernel.org/all/20231012101828.27195-1-zhangqing@rock-chips.com/ [1] Signed-off-by: Alexey Charkov <alchark@flipper.net>

Add precomputed PLL parameters for the display clocks found out in the wild which can't be cleanly derived from the existing PLL rates. These have been computed in a semi-bruteforce way to solve for low overall error while preferring smaller integer dividers and multipliers, and avoiding the fractional delta-sigma K component where possible. Signed-off-by: Alexey Charkov <alchark@flipper.net>

…rent PLL dclk_vp{0,1}_src muxes feed the display clock for Video Ports 0 and 1. With CLK_SET_RATE_NO_REPARENT the mux is locked to its current parent, but without CLK_SET_RATE_PARENT rate requests stop at the integer divider and never reach the parent PLL, making it impossible to achieve certain pixel clock frequencies. Add CLK_SET_RATE_PARENT so that when dclk_vp{0,1}_src is reparented to a programmable PLL (e.g. VPLL via assigned-clock-parents), the CCF divider can ask the PLL to retune, utilizing its fractional capabilities to obtain the exact pixel clock. This flag relies on reparenting the VP0-1 source clock to VPLL at DT level to ensure no consumer calls clk_set_rate on dclk_vp{0,1} while its parent is set to the boot-time default of GPLL, which may skew clocks for other consumers. Signed-off-by: Alexey Charkov <alchark@flipper.net>

Signed-off-by: Alexey Charkov <alchark@flipper.net>

MT7921U and possibly other related chips expose a different configuration on USB 3.0 vs. USB 2.0. Current driver logic only works with the USB 2.0 configuration, while connecting the module to a USB 3.0-only bus results in enumeration and scanning succeeding but connections silently failing. Add a special case for Mediatek modules on SuperSpeed busses to select the right bulk OUT endpoint (second not first) to make them work. Signed-off-by: Alexey Charkov <alchark@flipper.net>

…pensation Replace the hard-coded percent values with pixel margins carried in struct rockchip_crtc_state, sourced from the standard DRM "left/right/top/bottom margin" connector properties (struct drm_connector_tv_margins) to pave way for HDMI overscan compensation support. Signed-off-by: Alexey Charkov <alchark@flipper.net>

Expose the "overscan" connector property as recognized by KWin and the likes to compensate for TV overscan cropping. The CRTC will use the margin values derived from this overscan percentage in its post-composition scaler to add appropriate blank margins on all sides of the output image so that the TV doesn't eat up visible content. Signed-off-by: Alexey Charkov <alchark@flipper.net>

The speaker amplifier can be supplied by a higher voltage than the rest of the codec, namely up to 5V. When the speaker supply voltage is above 3.6V, the speaker gain boost setting should be enabled to prevent distortion on speaker and AUX pins. Enable gain boost setting based on the reading of the VDDSPK supply regulator's voltage. Signed-off-by: Alexey Charkov <alchark@flipper.net>

…per One Signed-off-by: Alexey Charkov <alchark@flipper.net>

FUSB302 only provides the data layer, and the PD protocol layer is handled by Linux TCPM code. As the data layer didn't change from PD 2.0 to PD 3.1, switch to PD 3.1 to match the actual capability of the device. Signed-off-by: Alexey Charkov <alchark@flipper.net>

The RK3576 has two Innosilicon MIPI CSI D-PHY instances that use the same register layout as the RK3588 variant (THS-settle at offset 0x160, calibration at 0x168, GRF at offset 0x0). Add the compatible string and driver data for these PHY instances. Signed-off-by: Jason Devers <dev.json2@gmail.com>

The RK3576 uses the same Synopsys DesignWare MIPI CSI-2 Host controller IP as the RK3568. Add the compatible string using the existing RK3568 driver data. Signed-off-by: Jason Devers <dev.json2@gmail.com>

The RK3576 Video Capture (VICAP) unit features five MIPI CSI-2 capture interfaces (compared to six on RK3588). The register layout is identical to the RK3588 variant. Add the compatible string and match data with mipi_num set to 5. Signed-off-by: Jason Devers <dev.json2@gmail.com>

Add device tree nodes for the RK3576 camera capture pipeline: - Two Innosilicon CSI D-PHY instances (csi_dphy0, csi_dphy1) - Two MIPI D-PHY GRF syscon nodes (mipidphy0_grf, mipidphy1_grf) - Five MIPI CSI-2 receiver nodes (csi0 through csi4) - Video Capture (VICAP) unit with five MIPI input ports - VICAP IOMMU The CSI hosts are connected to the VICAP ports and wired to the Innosilicon D-PHY instances. All nodes are disabled by default and must be enabled by board device trees that have camera connectors. Signed-off-by: Jason Devers <dev.json2@gmail.com>

Add rockchip,rk3576-csi-dphy to the compatible enum. The RK3576 has two Innosilicon CSI D-PHY instances and follows the same two-reset pattern (apb, phy) as the existing rk3588-csi-dphy entry. Signed-off-by: Jason Devers <dev.json2@gmail.com>

Add rockchip,rk3576-mipi-csi2 as a compatible that falls back to rockchip,rk3568-mipi-csi2, following the same pattern as the existing rk3588-mipi-csi2 entry. Signed-off-by: Jason Devers <dev.json2@gmail.com>

The RK3576 VICAP uses the same register layout and clock setup as the RK3588 one, with two differences: it has five MIPI CSI-2 input ports instead of six and no DVP parallel port. Extend the existing RK3588 binding rather than adding a separate file: add the rockchip,rk3576-vicap compatible and an allOf/if-then block that drops the DVP port@0 and the sixth MIPI port@6, and caps resets at eight, when that compatible is used. Signed-off-by: Jason Devers <dev.json2@gmail.com>

The RK3576 has two GRF blocks for its Innosilicon CSI D-PHY instances, analogous to the rk3588-csidphy-grf. Document the compatible so the rk3576 camera pipeline nodes validate. Signed-off-by: Jason Devers <dev.json2@gmail.com>

alchark · 2026-06-17T16:53:08Z

Thanks for the update!

I've recently rebased our development branch, so had to reapply these manually. Haven't yet had chance to runtime test it, but there is a bunch of warnings during the DT schema validation - can you please address?

/home/alchark/linux/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dtb: syscon@2603a000 (rockchip,rk3576-csidphy-grf): False schema does not allow [[23, 492]]
        from schema $id: http://devicetree.org/schemas/soc/rockchip/grf.yaml
/home/alchark/linux/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dtb: video-capture@27c10000 (rockchip,rk3576-vicap): resets: [[23, 321], [23, 322], [23, 320], [23, 332], [23, 333], [23, 334], [23, 335], [23, 336]] is too short
        from schema $id: http://devicetree.org/schemas/media/rockchip,rk3588-vicap.yaml
/home/alchark/linux/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dtb: csi@27c80000 (rockchip,rk3576-mipi-csi2): clock-names: ['pclk', 'iclk'] is too long
        from schema $id: http://devicetree.org/schemas/media/rockchip,rk3568-mipi-csi2.yaml
/home/alchark/linux/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dtb: csi@27c80000 (rockchip,rk3576-mipi-csi2): clocks: [[23, 369], [23, 375]] is too long
        from schema $id: http://devicetree.org/schemas/media/rockchip,rk3568-mipi-csi2.yaml
/home/alchark/linux/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dtb: csi@27c80000 (rockchip,rk3576-mipi-csi2): clock-names:0: 'per' was expected
        from schema $id: http://devicetree.org/schemas/media/rockchip,rk3568-mipi-csi2.yaml
/home/alchark/linux/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dtb: csi@27c80000 (rockchip,rk3576-mipi-csi2): clock-names:1: 'pixel' was expected
        from schema $id: http://devicetree.org/schemas/media/rockchip,rk3568-mipi-csi2.yaml
/home/alchark/linux/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dtb: csi@27c90000 (rockchip,rk3576-mipi-csi2): clock-names:0: 'per' was expected
        from schema $id: http://devicetree.org/schemas/media/rockchip,rk3568-mipi-csi2.yaml
/home/alchark/linux/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dtb: csi@27ca0000 (rockchip,rk3576-mipi-csi2): clock-names:0: 'per' was expected
        from schema $id: http://devicetree.org/schemas/media/rockchip,rk3568-mipi-csi2.yaml
/home/alchark/linux/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dtb: csi@27cb0000 (rockchip,rk3576-mipi-csi2): clock-names:0: 'per' was expected
        from schema $id: http://devicetree.org/schemas/media/rockchip,rk3568-mipi-csi2.yaml
/home/alchark/linux/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dtb: csi@27cc0000 (rockchip,rk3576-mipi-csi2): clock-names:0: 'per' was expected
        from schema $id: http://devicetree.org/schemas/media/rockchip,rk3568-mipi-csi2.yaml

alchark · 2026-06-18T08:34:44Z

Apparently something's also off with the power domains handling, as the boot stalls with the following messages once a camera module is enabled (it gets unstuck after a while, but this doesn't seem right):

[   13.536766] rockchip-pm-domain 27380000.power-management:power-controller: sync_state() pending due to 27b00100.video-codec
[   13.537787] rockchip-pm-domain 27380000.power-management:power-controller: sync_state() pending due to 27c10000.video-capture
[   13.538795] rockchip-pm-domain 27380000.power-management:power-controller: sync_state() pending due to 27cb0000.csi
[   13.539724] rockchip-pm-domain 27380000.power-management:power-controller: sync_state() pending due to 27d50000.sai
[   13.540675] rockchip-pm-domain 27380000.power-management:power-controller: sync_state() pending due to 27ea0000.spdif-tx
[   13.541649] rockchip-pm-domain 27380000.power-management:power-controller: sync_state() pending due to 2a600000.sai
[   13.542577] rockchip-pm-domain 27380000.power-management:power-controller: sync_state() pending due to 2a620000.sai

Could you please check @hz2?

Thanks a lot!

hz2 force-pushed the hz2/rk3576-csi-camera branch from 5befd87 to 82192bf Compare May 22, 2026 17:21

hz2 marked this pull request as ready for review May 30, 2026 05:09

hz2 requested a review from a team May 30, 2026 05:09

alchark requested changes Jun 1, 2026

View reviewed changes

sre and others added 20 commits June 5, 2026 19:33

[DEBUG] usb: typec: tcpm: also log to dmesg

bae242f

Also log to normal dmesg to assist debugging hard reset issues. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

[DEBUG] usb: typec: fusb302: also log to dmesg

4daa2ed

Also log to normal dmesg to assist debugging hard reset issues. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

math.h: add DIV_ROUND_UP_NO_OVERFLOW

39da597

Add a new DIV_ROUND_UP helper, which cannot overflow when big numbers are being used. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

clk: composite: replace open-coded abs_diff()

a0541ce

Replace the open coded abs_diff() with the existing helper function. Suggested-by: Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

arm64: dts: rockchip: rk3588-evb1: add bluetooth rfkill

8e8a84a

Add rfkill support for bluetooth. Bluetooth support itself is still missing, but this ensures bluetooth can be powered off properly. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

arm64: dts: rockchip: rk3588-evb1: improve PCIe ethernet pin muxing

a12ac66

Also describe wake signal PCIe pinmux for the onboard LAN card. Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>

dt-bindings: display: vop2: Add VP clock resets

4cbbae3

Add the documentation for VOP2 video ports reset clocks. One reset can be set per video port. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>

arm64: dts: rockchip: Add VOP clock resets for rk3588s

270f0aa

This adds the needed clock resets for all rk3588(s) based SOCs. Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com>

alchark added 2 commits June 5, 2026 21:06

alchark force-pushed the flipper-devel branch from 9d5b874 to 2ac16f5 Compare June 5, 2026 17:08

alchark added 10 commits June 5, 2026 21:22

arm64: dts: rockchip: Add overlay for 4K DP and 2.5K HDMI on RK3576

cd8a1cb

Signed-off-by: Alexey Charkov <alchark@flipper.net>

alchark force-pushed the flipper-devel branch from 2ac16f5 to c32805c Compare June 5, 2026 17:42

alchark and others added 10 commits June 10, 2026 14:13

arm64: dts: rockchip: Revert SD PWREN to SoC default function on Flip…

9e19452

…per One Signed-off-by: Alexey Charkov <alchark@flipper.net>

media: synopsys: dw-mipi-csi2rx: add support for RK3576

a9de343

The RK3576 uses the same Synopsys DesignWare MIPI CSI-2 Host controller IP as the RK3568. Add the compatible string using the existing RK3568 driver data. Signed-off-by: Jason Devers <dev.json2@gmail.com>

dt-bindings: media: rockchip,rk3568-mipi-csi2: add rk3576 support

7a72cdf

Add rockchip,rk3576-mipi-csi2 as a compatible that falls back to rockchip,rk3568-mipi-csi2, following the same pattern as the existing rk3588-mipi-csi2 entry. Signed-off-by: Jason Devers <dev.json2@gmail.com>

dt-bindings: soc: rockchip: grf: add rk3576 CSI D-PHY GRF

56c5e08

The RK3576 has two GRF blocks for its Innosilicon CSI D-PHY instances, analogous to the rk3588-csidphy-grf. Document the compatible so the rk3576 camera pipeline nodes validate. Signed-off-by: Jason Devers <dev.json2@gmail.com>

hz2 force-pushed the hz2/rk3576-csi-camera branch from c233671 to 56c5e08 Compare June 12, 2026 16:41

hz2 requested a review from alchark June 12, 2026 18:31

alchark force-pushed the flipper-devel branch from e66c0af to 7fd2501 Compare June 17, 2026 14:56

alchark force-pushed the flipper-devel branch from d2446f3 to 5f8b212 Compare June 22, 2026 13:26

		struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);

		priv->sys_grf_lane_sel_bit = (res && res->start == 0x2b070000) ? 2 : 1;

Conversation

hz2 commented May 22, 2026

Uh oh!

alchark commented May 22, 2026

Uh oh!

hz2 commented May 22, 2026

Uh oh!

alchark commented May 22, 2026

Uh oh!

hz2 commented May 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

hz2 commented May 30, 2026

Uh oh!

Uh oh!

alchark Jun 1, 2026

Choose a reason for hiding this comment

Uh oh!

alchark Jun 1, 2026

Choose a reason for hiding this comment

Uh oh!

hz2 Jun 3, 2026

Choose a reason for hiding this comment

Uh oh!

alchark Jun 1, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

alchark Jun 1, 2026

Choose a reason for hiding this comment

Uh oh!

hz2 Jun 3, 2026

Choose a reason for hiding this comment

Uh oh!

hz2 commented Jun 3, 2026

Uh oh!

alchark commented Jun 17, 2026

Uh oh!

alchark commented Jun 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

12 participants

hz2 commented May 22, 2026 •

edited

Loading