* Re: [PATCH] arm64: dts: qcom: qcs6490-rb3gen2: add rmtfs node
From: Bjorn Andersson @ 2026-05-23 2:19 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Baryshkov
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260520-rb3g2-rmtfs-ipa-v1-1-8b3942ded279@oss.qualcomm.com>
On Wed, 20 May 2026 12:54:37 +0300, Dmitry Baryshkov wrote:
> Downstream kernels for RB3 Gen2 don't specify the RMTFS address, instead
> the kernel is supposed to allocate rmtfs buffers dynamically. The
> upstream kernel doesn't support dynamic allocation of RMTFS buffers, so
> use the fixed allocation. The RMTFS node (and corresponding interface)
> is required for the modem DSP to work (which otherwise would crash).
>
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: qcs6490-rb3gen2: add rmtfs node
commit: f6dd5665d8e525484c2d0ebdb7004319024ee640
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sdm845-xiaomi-beryllium: Correct IPA FW path
From: Bjorn Andersson @ 2026-05-23 2:19 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Baryshkov, Robert Eckelmann, David Heidelberg
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
Joel Selvaraj
In-Reply-To: <20260429-beryllium-ipa-fix-v1-1-816326ba9047@ixit.cz>
On Wed, 29 Apr 2026 15:16:53 +0200, David Heidelberg wrote:
> The path was accidentally reverted back to old while refactoring of the
> device-tree.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: sdm845-xiaomi-beryllium: Correct IPA FW path
commit: f3cd85f60c5eb2d817af6c62465018dd941ce4f3
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/2] clk: qcom: nord: add defines for the USB2 PHY reset
From: Bjorn Andersson @ 2026-05-23 2:19 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Shawn Guo,
Bartosz Golaszewski
Cc: brgl, Krzysztof Kozlowski, linux-arm-msm, linux-clk, devicetree,
linux-kernel
In-Reply-To: <20260518-nord-clk-usb2-phy-v2-0-17a86cb307c3@oss.qualcomm.com>
On Mon, 18 May 2026 12:34:31 +0200, Bartosz Golaszewski wrote:
> Update the bindings and driver code with the definition for the USB2 PHY
> reset.
>
>
Applied, thanks!
[1/2] dt-bindings: clock: qcom: add the definition for the USB2 PHY reset
commit: d62b0e3104cfd2171281867196cb1365098a25e0
[2/2] clk: qcom: nord: negcc: add support for the USB2 PHY reset
commit: 9bee0a0a33e56122834a18e865fa83fdd2c99ebd
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: qcom: lemans-evk: Enable CAN RX via I2C GPIO expander
From: Bjorn Andersson @ 2026-05-23 2:19 UTC (permalink / raw)
To: Anup Kulkarni
Cc: konradybcio, robh, krzk+dt, conor+dt, linux-arm-msm, devicetree,
linux-kernel, mukesh.savaliya, viken.dadhaniya
In-Reply-To: <20260519064954.2759960-1-anup.kulkarni@oss.qualcomm.com>
On Tue, 19 May 2026 12:19:54 +0530, Anup Kulkarni wrote:
> The LeMans EVK board routes the RX lines of CAN controllers 2, 4, and 6
> (part of the RTSS subsystem) through a signal multiplexer controlled by
> GPIO 4 of the I2C GPIO expander at address 0x3b. The remaining CAN
> controllers, out of 8 total on RTSS, are wired directly to their
> transceivers.
>
> The multiplexer select pin defaults low on reset, disconnecting CAN 2,
> 4, and 6 RX lines from their respective transceivers, which results in
> no data being received on these interfaces.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: lemans-evk: Enable CAN RX via I2C GPIO expander
commit: 89e77275b55eac3d3b8027c9806eb32b24b05023
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] Describe IMEM on Eliza
From: Bjorn Andersson @ 2026-05-23 2:19 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Alexander Koskovich
Cc: devicetree, linux-kernel, linux-arm-msm, Krzysztof Kozlowski,
Konrad Dybcio
In-Reply-To: <20260418-eliza-imem-v3-0-bfbd499b6e77@pm.me>
On Sat, 18 Apr 2026 10:39:38 +0000, Alexander Koskovich wrote:
> Add a compatible and describe the IMEM for the Eliza SoC.
>
> Sort nodes by unit address, this can be applied separate of the other two.
>
> I kept the IPA modem tables in eliza.dtsi per Konrad's feedback about the IMEM
> containing it regardless of SKU.
>
> [...]
Applied, thanks!
[1/3] arm64: dts: qcom: eliza: Sort nodes by unit address
commit: 853a3ead458c409ffcfd7ff6a33ddc994b9a444d
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: eliza: Fix reserved memory addresses & sizes
From: Bjorn Andersson @ 2026-05-23 2:19 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Koskovich
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260412-eliza-reserved-memory-fix-v1-1-05cb3e33a9fe@pm.me>
On Sun, 12 Apr 2026 15:38:43 +0000, Alexander Koskovich wrote:
> Update cpusys_vm_mem from 256KiB to 4MiB, cpucp_mem from 2MiB to 1MiB
> and fix cpucp_scandump_mem node name to match actual reg address.
>
> This matches the downstream memmap and kera-reserved-memory.dtsi.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: eliza: Fix reserved memory addresses & sizes
commit: 2597338625b4e391d4d1aecbe2356f43cdacc057
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH 0/2] arm64: dts: qcom: milos: Add QFPROM efuse support
From: Bjorn Andersson @ 2026-05-23 2:19 UTC (permalink / raw)
To: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Alexander Koskovich
Cc: Luca Weiss, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260331-milos-qfprom-v1-0-36017cc642db@pm.me>
On Wed, 01 Apr 2026 02:24:51 +0000, Alexander Koskovich wrote:
> Add dt-bindings and dt-node for Milos QFPROM efuse. The GPU speed bin child
> node nvmem cell contains details of clk frequencies supported by the GPU,
> which can then read by the GPU driver to select the correct set of operating
> performance points (OPPs) for the device in the future once all the possible
> speedbins for Milos are known.
>
>
> [...]
Applied, thanks!
[2/2] arm64: dts: qcom: milos: Add qfprom efuse node
commit: b39a174a535841e71c59661cc92408b710e0fe6a
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 0/3] arm64: dts: qcom: eliza: Add ADSP and USB support
From: Bjorn Andersson @ 2026-05-23 2:19 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Abel Vesa
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski,
Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <20260514-eliza-adsp-usb-v5-0-a21056ffd892@oss.qualcomm.com>
On Thu, 14 May 2026 16:54:12 +0300, Abel Vesa wrote:
> This series adds the ADSP and USB related description for the Qualcomm
> Eliza platform.
>
> The SoC dtsi gains the ADSP remoteproc node and its communication
> dependencies, including IPCC, SMP2P and the AOSS QMP channel. It also
> describes the USB controller, the SNPS eUSB2 PHY and the USB3/DP QMP
> combo PHY.
>
> [...]
Applied, thanks!
[1/3] arm64: dts: qcom: eliza: Describe the ADSP and USB related nodes
commit: 88ddafb01ec05bb3cd1ffb51b740bfbc989ab955
[2/3] arm64: dts: qcom: Add Eliza-specific PM7550BA dtsi
commit: 59703108a0c00321f181d021cb83e0d7b610ed61
[3/3] arm64: dts: qcom: eliza-mtp: Enable USB and ADSP support
commit: 49dab7311f57e0ba81bdcd3bcf6d763cca13532b
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/2] soc: qcom: llcc-qcom: Add support for Eliza and document bindings
From: Bjorn Andersson @ 2026-05-23 2:19 UTC (permalink / raw)
To: Konrad Dybcio, Conor Dooley, Jonathan Cameron, Rob Herring,
Krzysztof Kozlowski, Abel Vesa
Cc: linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260513-eliza-llcc-v2-0-27381ae833d5@oss.qualcomm.com>
On Wed, 13 May 2026 14:11:01 +0300, Abel Vesa wrote:
> Add support for the Last Level Cache Controller found on the Qualcomm
> Eliza SoC.
>
> Eliza's LLCC uses a 4-region register layout, with two per-bank base
> regions plus the broadcast OR and AND windows.
>
> Describe that layout in the devicetree bindings and add the corresponding
> slice configuration and driver data in llcc-qcom.
>
> [...]
Applied, thanks!
[1/2] dt-bindings: cache: qcom,llcc: Document Eliza LLCC block
commit: 6487b12a875a5e3cc2f99ff7eba1112fe3f72483
[2/2] soc: qcom: llcc-qcom: Add support for Eliza
commit: 0a4d53ae2cb68cbfe3c69e14d8cfc0acc7c37bda
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 0/2] arm64: dts: qcom: eliza: Fix debug UART and add more support
From: Bjorn Andersson @ 2026-05-23 2:19 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dmitry Baryshkov, Abel Vesa
Cc: Krzysztof Kozlowski, Konrad Dybcio, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260515-eliza-dts-fix-debug-uart-and-more-support-v2-0-5ad3da81b9d3@oss.qualcomm.com>
On Fri, 15 May 2026 16:22:37 +0300, Abel Vesa wrote:
> Fix the Eliza MTP debug UART index and then add the missing
> QUPv3 WRAP1/WRAP2 serial engines, the matching GPI DMA controllers,
> SDHCI controllers, their pinconf state and the LLCC system cache
> controller.
>
> This series depends on the following Eliza binding updates:
> https://lore.kernel.org/all/20260513-eliza-llcc-v2-1-27381ae833d5@oss.qualcomm.com/
> https://lore.kernel.org/all/20260515-eliza-gpi-dma-v2-1-1255b43d5ca9@oss.qualcomm.com/
> https://lore.kernel.org/all/20260513-eliza-bindings-sdhci-v1-1-b2cae44163c1@oss.qualcomm.com/
> https://lore.kernel.org/all/20260318-eliza-bindings-qmp-phy-v1-1-96a0d529ad2d@oss.qualcomm.com/
> https://lore.kernel.org/all/20260504-eliza-bindings-phy-eusb2-v2-1-fa3a1fd65ab1@oss.qualcomm.com/
> https://lore.kernel.org/all/20260515-eliza-tlmm-group-qup1-se4-lanes-v2-1-ebb630de0dcf@oss.qualcomm.com/
> https://lore.kernel.org/all/20260504-eliza-bindings-aoss-v2-1-c3628ca79a25@oss.qualcomm.com/
> https://lore.kernel.org/all/20260504-eliza-bindings-pmic-glink-v2-1-d6b5397b7899@oss.qualcomm.com/
>
> [...]
Applied, thanks!
[1/2] arm64: dts: qcom: eliza-mtp: Fix the debug UART index
commit: 179d11c1c0cfaddcfc984edc3c1863ab600f679f
[2/2] arm64: dts: qcom: eliza: Add QUPv3, GPI DMA, SDHCI and LLCC nodes
commit: 844807e1f89d8852d570b4be5297a79ea674fc47
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v6 00/13] Enable I2C on SA8255p Qualcomm platforms
From: Bjorn Andersson @ 2026-05-23 2:19 UTC (permalink / raw)
To: Praveen Talari
Cc: Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Mukesh Kumar Savaliya, Viken Dadhaniya, Konrad Dybcio,
linux-arm-msm, linux-i2c, devicetree, linux-kernel,
bjorn.andersson, dmitry.baryshkov, konrad.dybcio, prasad.sodagudi,
aniket.randive, chandana.chiluveru, jyothi.seerapu,
chiluka.harish
In-Reply-To: <20260227061544.1785978-1-praveen.talari@oss.qualcomm.com>
On Fri, Feb 27, 2026 at 11:45:31AM +0530, Praveen Talari wrote:
> The Qualcomm automotive SA8255p SoC relies on firmware to configure
> platform resources, including clocks, interconnects and TLMM.
> The driver requests resources operations over SCMI using power
> and performance protocols.
>
> The SCMI power protocol enables or disables resources like clocks,
> interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
> such as resume/suspend, to control power states(on/off).
>
> The SCMI performance protocol manages I2C frequency, with each
> frequency rate represented by a performance level. The driver uses
> geni_se_set_perf_opp() API to request the desired frequency rate..
>
> As part of geni_se_set_perf_opp(), the OPP for the requested frequency
> is obtained using dev_pm_opp_find_freq_floor() and the performance
> level is set using dev_pm_opp_set_opp().
>
@Andi, I've merged the soc-patches through an immutable branch into the
qcom-tree for 7.2, please find this at:
https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git 20260227061544.1785978-1-praveen.talari@oss.qualcomm.com
Regards,
Bjorn
> Praveen Talari (13):
> soc: qcom: geni-se: Refactor geni_icc_get() and make qup-memory ICC
> path optional
> soc: qcom: geni-se: Add geni_icc_set_bw_ab() function
> soc: qcom: geni-se: Introduce helper API for resource initialization
> soc: qcom: geni-se: Handle core clk in geni_se_clks_off() and
> geni_se_clks_on()
> soc: qcom: geni-se: Add resources activation/deactivation helpers
> soc: qcom: geni-se: Introduce helper API for attaching power domains
> soc: qcom: geni-se: Introduce helper APIs for performance control
> dt-bindings: i2c: Describe SA8255p
> i2c: qcom-geni: Isolate serial engine setup
> i2c: qcom-geni: Move resource initialization to separate function
> i2c: qcom-geni: Use resources helper APIs in runtime PM functions
> i2c: qcom-geni: Store of_device_id data in driver private struct
> i2c: qcom-geni: Enable I2C on SA8255p Qualcomm platforms
> ---
> v3->v4
> - Added a new patch(4/13) to handle core clk as part of
> geni_se_clks_off/on().
>
> .../bindings/i2c/qcom,sa8255p-geni-i2c.yaml | 64 ++++
> drivers/i2c/busses/i2c-qcom-geni.c | 324 +++++++++---------
> drivers/soc/qcom/qcom-geni-se.c | 270 ++++++++++++++-
> include/linux/soc/qcom/geni-se.h | 19 +
> 4 files changed, 491 insertions(+), 186 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/i2c/qcom,sa8255p-geni-i2c.yaml
>
>
> base-commit: 7d6661873f6b54c75195780a40d66bad3d482d8f
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH net-next v5 0/9] net: dsa: add DSA support for the LAN9645x switch chip family
From: Jakub Kicinski @ 2026-05-23 2:04 UTC (permalink / raw)
To: Jens Emil Schulz Østergaard
Cc: UNGLinuxDriver, Andrew Lunn, Vladimir Oltean, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Woojung Huh, Russell King,
Steen Hegelund, Daniel Machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260518-dsa_lan9645x_switch_driver_base-v5-0-968fbf34ffa3@microchip.com>
On Mon, 18 May 2026 14:24:55 +0200 Jens Emil Schulz Østergaard wrote:
> This series provides the Microchip LAN9645X Switch driver.
Looks like this needs a rebase.
^ permalink raw reply
* [PATCH v2] dt-bindings: net: mdio: remove deprecated .txt binding stub
From: Akash Sukhavasi @ 2026-05-23 0:42 UTC (permalink / raw)
To: krzk+dt
Cc: Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Conor Dooley, netdev, devicetree, linux-kernel
Remove the deprecated plain text binding file for MDIO. The file
has been a dormant single-line redirect stub ("This file has moved
to mdio.yaml") since commit 62d77ff7ecbf ("dt-bindings: net: Add
a YAML schemas for the generic MDIO options") in 2019. No files
in the tree refer to mdio.txt, and all existing references already
point to mdio.yaml exclusively. The redirect no longer serves a
practical purpose.
Signed-off-by: Akash Sukhavasi <akash.sukhavasi@gmail.com>
---
Changes in v2:
- Add justification for removal (Krzysztof Kozlowski review).
v1: https://lore.kernel.org/all/20260521144235.3414-1-akash.sukhavasi@gmail.com/
Documentation/devicetree/bindings/net/mdio.txt | 1 -
1 file changed, 1 deletion(-)
delete mode 100644 Documentation/devicetree/bindings/net/mdio.txt
diff --git a/Documentation/devicetree/bindings/net/mdio.txt b/Documentation/devicetree/bindings/net/mdio.txt
deleted file mode 100644
index cf8a01054..000000000
--- a/Documentation/devicetree/bindings/net/mdio.txt
+++ /dev/null
@@ -1 +0,0 @@
-This file has moved to mdio.yaml.
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] dt-bindings: net: mdio: remove deprecated .txt binding stub
From: Akash Sukhavasi @ 2026-05-23 0:41 UTC (permalink / raw)
To: krzk
Cc: akash.sukhavasi, andrew, conor+dt, davem, devicetree, edumazet,
hkallweit1, krzk+dt, kuba, linux-kernel, linux, netdev, pabeni,
robh
In-Reply-To: <b3a268ff-6f69-494a-9b9c-11995f35b9c2@kernel.org>
On Thu, 21 May 2026 20:41:28 +0200, Krzysztof Kozlowski wrote:
> Why removing it? The file was left on purpose why converting, so you
> should provide reasons why now it is worth to remove it.
The file is a single line redirect, untouched since 2019. No files
in the tree refer to mdio.txt, and all existing references already
point to mdio.yaml exclusively. The redirect no longer serves a
practical purpose. Sending v2 with this justification in the commit
message.
> Don't do such patches one by one.
Noted. I'll batch any similar cleanups into a series going forward,
and make sure commit messages clearly cover the what, why, and how.
Thanks,
Akash
^ permalink raw reply
* Re: [PATCH net-next v8 10/10] net: airoha: Support multiple LAN/WAN interfaces for hw MAC address configuration
From: Jakub Kicinski @ 2026-05-22 23:58 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: sashiko-reviews, robh, devicetree, conor+dt, netdev
In-Reply-To: <ahCtsVA1VhYmhZq-@lore-desk>
On Fri, 22 May 2026 21:25:37 +0200 Lorenzo Bianconi wrote:
> - What happens when device tree does not provide MAC addresses for two or
> more same-side GDM interfaces?
> - This is the same comment reported in [0].
> Since the hw exposes just a single register (REG_FE_LAN_MAC_H or
> REG_FE_WAN_MAC_H) for the LAN/WAN mac address MSBs, we need to
> require all the interfaces configured as LAN or WAN to share the
> mac address MSBs and the user needs to select the new mac address
> observing this limitation.
> Please note this limitation is only valid if multiple net_devices
> are configured as LAN (or WAN). Since in the current codebase we
> do not support multiple interfaces configured as LAN or WAN, we are
> not introducing any regression.
> I do not think selecting a "base" for the mac address is helpful
> if the user does not provide the mac address via the DTS or NVME
> (as suggested by sashiko) since it will not help us if the mac
> addresses configured via DTS are "wrong" (if they do not respect
> the limitation described above). What do you think?
If the MACs are not provided something is obviously wrong with the
device. We should try to provide enough functionality for the user
to be able to troubleshoot. For an AP perhaps that means SSH / remote
logs? So switching/routing doesn't have to work, I'd think.
Will the user be able to log in when REG_FE_LAN_MAC_H does not match
the MAC of a port?
^ permalink raw reply
* Re: [PATCH v8 1/3] PCI: mediatek: Use actual physical address instead of virt_to_phys()
From: Bjorn Helgaas @ 2026-05-22 22:43 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Caleb James DeLisle, linux-pci, linux-mips, naseefkm, ryder.lee,
lpieralisi, kwilczynski, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, ansuelsmth, linux-mediatek, devicetree,
linux-kernel, Manivannan Sadhasivam
In-Reply-To: <7xfp5nbtd4qtonoqurfwoedsix7vondrnfeip53uwjintuvc6a@cg3ez6z3pii5>
On Thu, May 21, 2026 at 10:44:51AM +0530, Manivannan Sadhasivam wrote:
> On Wed, May 20, 2026 at 02:59:00PM -0500, Bjorn Helgaas wrote:
> > On Wed, May 20, 2026 at 09:17:35PM +0200, Caleb James DeLisle wrote:
> > >
> > > On 20/05/2026 20:55, Bjorn Helgaas wrote:
> > > > On Wed, May 20, 2026 at 06:38:25PM +0000, Caleb James DeLisle wrote:
> > > > > From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > >
> > > > > The driver previously used virt_to_phys() on the ioremapped register base
> > > > > (port->base) to compute the MSI message address. Using virt_to_phys() on an
> > > > > IO mapped address is incorrect because it expects a kernel virtual address.
> > > > >
> > > > > To fix it, store the physical start of the I/O register region in
> > > > > mtk_pcie_port->phys_base and use it to build the MSI address. This replaces
> > > > > the incorrect virt_to_phys() usage and ensures MSI addresses are generated
> > > > > correctly.
> > > > >
> > > > > Fixes: 43e6409db64d ("PCI: mediatek: Add MSI support for MT2712 and MT7622")
> > > > > Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > > > > Tested-by: Caleb James DeLisle <cjd@cjdns.fr>
> > > > > ---
> > > > > drivers/pci/controller/pcie-mediatek.c | 16 +++++++++++++---
> > > > > 1 file changed, 13 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/pci/controller/pcie-mediatek.c b/drivers/pci/controller/pcie-mediatek.c
> > > > > index 75722524fe74..c503fbd774d0 100644
> > > > > --- a/drivers/pci/controller/pcie-mediatek.c
> > > > > +++ b/drivers/pci/controller/pcie-mediatek.c
> > > > > @@ -175,6 +175,7 @@ struct mtk_pcie_soc {
> > > > > /**
> > > > > * struct mtk_pcie_port - PCIe port information
> > > > > * @base: IO mapped register base
> > > > > + * @phys_base: Physical address of the I/O register base region
> > > > > * @list: port list
> > > > > * @pcie: pointer to PCIe host info
> > > > > * @reset: pointer to port reset control
> > > > > @@ -196,6 +197,7 @@ struct mtk_pcie_soc {
> > > > > */
> > > > > struct mtk_pcie_port {
> > > > > void __iomem *base;
> > > > > + phys_addr_t phys_base;
> > > > > struct list_head list;
> > > > > struct mtk_pcie *pcie;
> > > > > struct reset_control *reset;
> > > > > @@ -405,7 +407,7 @@ static void mtk_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> > > > > phys_addr_t addr;
> > > > > /* MT2712/MT7622 only support 32-bit MSI addresses */
> > > > > - addr = virt_to_phys(port->base + PCIE_MSI_VECTOR);
> > > > > + addr = port->phys_base + PCIE_MSI_VECTOR;
> > > >
> > > > This doesn't look right because the MSI address is a PCI bus address,
> > > > and port->phys_base is a CPU physical address. Often a PCI bus
> > > > address is the same as the CPU physical address, but not always.
> > > > I think the DT 'ranges' property tells you the translation.
> >
> > Oops, sorry, I muddied the waters here.
> >
> > 'ranges' tells you the translation applied by a bridge, e.g., when
> > a CPU does a load/store, the PCI host bridge turns it into a PCI
> > read/write transaction. The bridge might add an offset to the CPU
> > load/store physical address to get the PCI read/write bus address.
> >
> > But that's not the issue here. The MSI is basically a DMA write
> > performed by the PCI device, not a store done by a CPU, so I don't
> > think 'ranges' is the right thing to look at.
>
> Yeah, it is so easy to confuse both. To summarise, 'ranges'
> describes the outbound translation and 'dma-ranges' describes the
> inbound translation from host perspective.
>
> > Based on this:
> > https://elinux.org/Device_Tree_Usage#PCI_DMA_Address_Translation I
> > think 'dma-ranges' is the relevant property. I don't think your
> > DT includes a 'dma-ranges' property, and in that case the default
> > is that the system bus (CPU) address is the same as the PCI
> > address.
> >
> > So I think this patch works because it assumes DMA addresses like
> > the MSI address are mapped to identical system bus addresses.
> >
> > It still seems to me that drivers should be prepared for the
> > presence of dma-ranges and use it when computing the MSI target
> > address. But I don't think any drivers really do that, so for now
> > I think you should pretend that I never responded about this
> > patch.
>
> Your observations are correct. This driver assumes that the
> identical mapping exists between CPU and PCI bus addresses. Usually,
> the drivers make use of phys_to_dma() to handle the translations.
What does this look like in the native host bridge drivers? I don't
see any direct calls of phys_to_dma(), but there are some higher-level
interfaces that use it.
I don't really see a consistent style of constructing MSI addresses,
e.g., in *_compose_msi_msg() implementations.
> This API internally makes use of the 'dma_range_map' which gets
> populated by the OF core based on the 'dma-ranges' property (if
> present in DT).
>
> But it makes sense to use it irrespective of whether the platform
> supports non-identical DMA/inbound translation or not. Since this
> API behaves like a no-op and returns the CPU physical address if
> there is an identical mapping, there is literally zero overhead in
> using it.
Thanks for rescuing me.
I wonder if there should be something in
Documentation/core-api/dma-api* about this. I guess that is mostly
oriented toward things like PCI device drivers, not so much PCI host
bridge drivers. But it would be nice to have a little intro to
dma-ranges and maybe even the restricted DMA usage.
Bjorn
^ permalink raw reply
* Re: [PATCH v5 3/8] media: rockchip: rkcif: add support for rk3588 vicap mipi capture
From: sashiko-bot @ 2026-05-22 22:22 UTC (permalink / raw)
To: Michael Riesch via B4 Relay; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260522-rk3588-vicap-v5-3-d1d1f5265c56@collabora.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [Critical] Missing NULL pointer check for `match_data->mipi` in `rkcif_mipi_isr()` leads to a kernel panic on devices without MIPI support.
- [High] Incorrect read-modify-write logic when clearing pending interrupts in the W1C `RKCIF_MIPI_INTSTAT` register.
- [High] The hardirq handler calls a function that acquires a mutex, leading to a sleep in atomic context BUG and potential deadlocks.
--
commit dbb001c2e64feff7a8b087afc4307525237930d8
Author: Michael Riesch <michael.riesch@collabora.com>
media: rockchip: rkcif: add support for rk3588 vicap mipi capture
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.
> diff --git a/drivers/media/platform/rockchip/rkcif/rkcif-capture-mipi.c b/drivers/media/platform/rockchip/rkcif/rkcif-capture-mipi.c
> index 9e67160a16e46..bc9518f8db507 100644
> --- a/drivers/media/platform/rockchip/rkcif/rkcif-capture-mipi.c
> +++ b/drivers/media/platform/rockchip/rkcif/rkcif-capture-mipi.c
[ ... ]
> @@ -631,6 +762,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);
> +
[Severity: High]
This isn't a bug introduced by this patch, but I noticed an issue in the
surrounding code for rkcif_mipi_start_streaming() and
rkcif_mipi_stop_streaming().
The RKCIF_MIPI_INTSTAT register is Write-1-to-Clear (W1C), which is
demonstrated by the ISR reading and writing back the exact same value to clear
interrupts. However, in rkcif_mipi_start_streaming():
int_temp = rkcif_mipi_read(interface, RKCIF_MIPI_INTSTAT);
int_temp &= ~int_mask;
rkcif_mipi_write(interface, RKCIF_MIPI_INTSTAT, int_temp);
Does this sequence incorrectly write 0 to the intended stream's interrupt bit,
failing to clear it, while writing 1 to any currently pending interrupts of
other active streams?
Could this erroneously clear interrupts for concurrent streams before the ISR
can handle them, potentially leading to timeouts or dropped frames?
[Severity: High]
This is a pre-existing issue, but I noticed a potential sleep in atomic
context BUG related to the stream stopping logic.
When stopping a stream, rkcif_stream_stop_streaming() (called from process
context) sets stream->stopping = true and waits.
The hardware interrupt handler detects this flag and directly calls
rkcif_mipi_stop_streaming():
rkcif_mipi_isr()
if (stream->stopping) {
rkcif_mipi_stop_streaming(stream);
...
rkcif_mipi_stop_streaming()
state = v4l2_subdev_lock_and_get_active_state(&interface->sd);
Since v4l2_subdev_lock_and_get_active_state() acquires a mutex, and it is
being called from the hardirq handler rkcif_mipi_isr(), will this trigger a
sleep in atomic context BUG and potentially deadlock the CPU?
> ret = 0;
>
> out:
> diff --git a/drivers/media/platform/rockchip/rkcif/rkcif-dev.c b/drivers/media/platform/rockchip/rkcif/rkcif-dev.c
> index b4cf1146f1311..be3a174b9aab0 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",
> + "iclk",
> + "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,
> +};
> +
[Severity: Critical]
This is a pre-existing issue, but I noticed a potential NULL pointer
dereference related to the mipi match data.
In the global interrupt handler rkcif_isr(), it unconditionally calls
rkcif_mipi_isr():
rkcif_isr()
...
if (rkcif_mipi_isr(irq, ctx) == IRQ_HANDLED)
ret = IRQ_HANDLED;
Inside rkcif_mipi_isr(), the code iterates up to mipi_num:
rkcif_mipi_isr()
for (unsigned int i = 0; i < rkcif->match_data->mipi->mipi_num; i++) {
...
For devices that do not support MIPI (such as rockchip,px30-vip) where
match_data->mipi is not defined (NULL), won't any hardware interrupt
triggered by the DVP interface cause a guaranteed NULL pointer dereference
and kernel panic?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-rk3588-vicap-v5-0-d1d1f5265c56@collabora.com?part=3
^ permalink raw reply
* Re: [PATCH v5 2/8] media: dt-bindings: add rockchip rk3588 vicap
From: sashiko-bot @ 2026-05-22 21:40 UTC (permalink / raw)
To: Michael Riesch via B4 Relay; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260522-rk3588-vicap-v5-2-d1d1f5265c56@collabora.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Missing `minItems` constraint for `reset-names` in the RK3588 conditional block.
--
commit 63f5bfe4a138b18bc1581d3e98d7e6a10fe7ef3e
Author: Michael Riesch <michael.riesch@collabora.com>
media: dt-bindings: add rockchip rk3588 vicap
This commit adds documentation for the Rockchip RK3588 Video Capture (VICAP)
unit. It generalizes the existing rockchip,rk3568-vicap documentation and
introduces variant-specific constraints.
> diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml
> --- a/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml
> +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-vicap.yaml
[ ... ]
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: rockchip,rk3588-vicap
> + then:
> + properties:
[ ... ]
> + resets:
> + minItems: 9
> +
> + reset-names:
> + items:
> + - const: arst
> + - const: hrst
> + - const: drst
> + - const: irst0
> + - const: irst1
> + - const: irst2
> + - const: irst3
> + - const: irst4
> + - const: irst5
[Severity: Low]
Does this schema correctly enforce the length of the reset-names array for the
rk3588-vicap variant?
Since the global reset-names definition allows a minimum of 5 items, omitting
minItems: 9 here means a device tree could provide exactly 9 resets but only
5 reset-names and still pass validation. Should this include minItems: 9 to
match the resets property?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260522-rk3588-vicap-v5-0-d1d1f5265c56@collabora.com?part=2
^ permalink raw reply
* Re: [PATCH v7 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-05-22 21:37 UTC (permalink / raw)
To: Rob Herring (Arm), Bryan O'Donoghue
Cc: linux-kernel, Kishon Vijay Abraham I, Neil Armstrong, linux-phy,
linux-media, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm,
Vinod Koul, devicetree, Vladimir Zapolskiy
In-Reply-To: <177946855028.3571140.11988520251406266072.robh@kernel.org>
On 22/05/2026 17:49, Rob Herring (Arm) wrote:
>
> On Fri, 22 May 2026 15:45:09 +0100, Bryan O'Donoghue wrote:
>> Add a base schema initially compatible with x1e80100 to describe MIPI CSI2
>> PHY devices.
>>
>> The hardware can support both CPHY, DPHY and a special split-mode DPHY.
>>
>> The schema here defines three ports:
>>
>> port@0:
>> The first input port where a sensor is always required.
>>
>> port@1:
>> A second optional input port which if present implies DPHY split-mode.
>>
>> port@2:
>> A third always required output port which connects to the controller.
>>
>> The CSIPHY devices have their own pinouts on the SoC as well as their own
>> individual voltage rails.
>>
>> The need to model voltage rails on a per-PHY basis leads us to define
>> CSIPHY devices as individual nodes.
>>
>> Two nice outcomes in terms of schema and DT arise from this change.
>>
>> 1. The ability to define on a per-PHY basis voltage rails.
>> 2. The ability to require those voltage.
>>
>> We have had a complete bodge upstream for this where a single set of
>> voltage rail for all CSIPHYs has been buried inside of CAMSS.
>>
>> Much like the I2C bus which is dedicated to Camera sensors - the CCI bus in
>> CAMSS parlance, the CSIPHY devices should be individually modelled.
>>
>> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>> ---
>> .../bindings/phy/qcom,x1e80100-csi2-phy.yaml | 208 +++++++++++++++++++++
>> 1 file changed, 208 insertions(+)
>>
>
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml: port@0: Missing additionalProperties/unevaluatedProperties constraint
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml: port@1: Missing additionalProperties/unevaluatedProperties constraint
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml: port@2: Missing additionalProperties/unevaluatedProperties constraint
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.example.dtb: csiphy@ace4000 (qcom,x1e80100-csi2-phy): ports:port@2:endpoint: Unevaluated properties are not allowed ('clock-lanes', 'data-lanes' were unexpected)
> from schema $id: http://devicetree.org/schemas/phy/qcom,x1e80100-csi2-phy.yaml
Frustratingly
dtbs_do_check2 phy/qcom,x1e80100-mipi-csi2-combo-phy.yaml
qcom/x1e80100-crd.dtb
dtbs_do_check2 () {
echo "checking " $1 " and " $2
make dtbs_check ARCH=$ARCH CROSS_COMPILE=$CROSS_COMPILE O=$BUILDDIR
DT_DOC_CHECKER=$DT_DOC_CHECKER DT_EXTRACT_EX=$DT_EXTRACT_EX
DT_MK_SCHEMA=$DT_MK_SCHEMA DT_SCHEMA_FILES=$1 CHECK_DTBS=y $2
make dt_binding_check O=$BUILDDIR DT_CHECKER_FLAGS=-m
DT_DOC_CHECKER=$DT_DOC_CHECKER DT_EXTRACT_EX=$DT_EXTRACT_EX
DT_MK_SCHEMA=$DT_MK_SCHEMA DT_SCHEMA_FILES=$1 CHECK_DTBS=y $2
}
Neither my script nor the Makefile throw an error when the yaml name
doesn't exist i.e. when it changes.
I really did run the checker - just for a file that doesn't exist.
Feels like a bug I should blame on AI enslopification but, it was me..
meh
---
bod
phy/qcom,x1e80100-mipi-csi2-combo-phy.yaml
^ permalink raw reply
* Re: [PATCH v2 4/4] arm64: dts: qcom: x1-dell-thena: bump linux,cma to 256 MiB
From: Bryan O'Donoghue @ 2026-05-22 21:33 UTC (permalink / raw)
To: Michael Scott, linux-arm-msm
Cc: vkoul, neil.armstrong, dmitry.baryshkov, wesley.cheng, abelvesa,
faisal.hassan, linux-phy, andersson, konradybcio, robh, krzk+dt,
conor+dt, devicetree, val, laurentiu.tudor1, alex.vinarskis,
linux-kernel
In-Reply-To: <581cc180-b993-4b86-81ae-17822a35a1fb@oss.qualcomm.com>
On 22/05/2026 18:16, Michael Scott wrote:
>> └─[$] <git:(0.7.0-multipass-v0*)>
>
> Good point about the libcamera version. I debugged this on Ubuntu 26.04
> (v0.7.0+patches). I tried testing v0.7.1, but it caused a crash due to
> API changes with other parts of the subsystem. I checked the diff of
> upstream between v0.7.0 and v0.7.1 for the dma allocator code and I
> didn't see any changes, but I wasn't looking at the software ISP changes.
>
> This highlights that "I'm doing this wrong". I'll move to a cleaner
> rolling distro where staying current is a lot easier.
>
> The GPUISP support looks great!
>
> Dropping this patch as I'm not understanding the full allocator story.
> Sorry for the noise.
The whole make CMA bigger thing is an error I was pushing myself.
CMA is required for some systems like say Hantro on i.MX where - the
encoder doesn't know how to deal with non PHYS contig memory so when you
are passing framebuffers around from once hw block to another, you need
to make them physically contiguous.
Not a problem for us on Qcom hw though. Like Rob said, I'm actually not
sure why we need a CMA block on Qcom hardware at all.
GPU or WiFi I think but not for Camera anymore anyway.
---
bod
^ permalink raw reply
* [PATCH v5 5/8] arm64: dts: rockchip: add vicap node to rk3588
From: Michael Riesch via B4 Relay @ 2026-05-22 21:23 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: <20260522-rk3588-vicap-v5-0-d1d1f5265c56@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 4d80e5e1f0339b6e91adf40da6cc8389ffd4ddc9..87b0ac0893a9fe404a6274067bc142d782e3366e 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", "iclk", "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.47.3
^ permalink raw reply related
* [PATCH v5 8/8] arm64: defconfig: enable designware mipi csi-2 receiver
From: Michael Riesch via B4 Relay @ 2026-05-22 21:23 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: <20260522-rk3588-vicap-v5-0-d1d1f5265c56@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 d905a0777f939c51cc39df6230591a31058b765f..9171f750337e540f0feec998c7aa33d3444b806e 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -918,6 +918,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.47.3
^ permalink raw reply related
* [PATCH v5 7/8] arm64: dts: rockchip: add radxa camera 4k on rock 5b+ cam1
From: Michael Riesch via B4 Relay @ 2026-05-22 21:23 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: <20260522-rk3588-vicap-v5-0-d1d1f5265c56@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 d4ff476fb9814b18c74c6d59d73cf5d8e6ee9ca7..761d82b4f4f2ac7f0f4ba5e1f94f495b2160a059 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -207,6 +207,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
@@ -324,7 +325,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 0000000000000000000000000000000000000000..8a4cf3fdbf8ebde8b2939c6126d169074431588a
--- /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 = <&siovdd_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.47.3
^ permalink raw reply related
* [PATCH v5 6/8] arm64: dts: rockchip: add radxa camera 4k on rock 5b+ cam0
From: Michael Riesch via B4 Relay @ 2026-05-22 21:23 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: <20260522-rk3588-vicap-v5-0-d1d1f5265c56@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 cb55c6b70d0e569abd9efc4e88ff908b6a682cf1..d4ff476fb9814b18c74c6d59d73cf5d8e6ee9ca7 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -206,6 +206,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
@@ -321,6 +322,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 0000000000000000000000000000000000000000..ee9ecf68a88663a04e1c33a718894490ef475203
--- /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.47.3
^ permalink raw reply related
* [PATCH v5 1/8] Documentation: admin-guide: media: add rk3588 vicap
From: Michael Riesch via B4 Relay @ 2026-05-22 21:23 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: <20260522-rk3588-vicap-v5-0-d1d1f5265c56@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 0000000000000000000000000000000000000000..f6d3404920b544f921987d3240f89987b340e138
--- /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 2558c121abc466393b4a132e0d9abd2d37f2d25b..313a0ea45d16fe9bbb79d0798e8f8b1dbe1cb83f 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.47.3
^ permalink raw reply related
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