Devicetree
 help / color / mirror / Atom feed
From: Jason Yang via B4 Relay <devnull+jason98166.gmail.com@kernel.org>
To: Vinod Koul <vkoul@kernel.org>,
	 Neil Armstrong <neil.armstrong@linaro.org>,
	Rob Herring <robh@kernel.org>,
	 Krzysztof Kozlowski <krzk+dt@kernel.org>,
	 Conor Dooley <conor+dt@kernel.org>,
	Heiko Stuebner <heiko@sntech.de>,
	 Guochun Huang <hero.huang@rock-chips.com>,
	 Philipp Zabel <p.zabel@pengutronix.de>
Cc: linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
	 linux-arm-kernel@lists.infradead.org,
	linux-rockchip@lists.infradead.org,
	 linux-kernel@vger.kernel.org, Jason Yang <jason98166@gmail.com>
Subject: [PATCH v2 0/4] phy: rockchip-samsung-dcphy: support the D-PHY receiver direction
Date: Sun, 26 Jul 2026 22:55:43 +0800	[thread overview]
Message-ID: <20260726-dcphy-rx-v1-v2-0-cf9cc34a412a@gmail.com> (raw)

The Samsung DC-PHY on RK3588 contains both a MIPI transmitter (DSI)
and a MIPI receiver (CSI) with separate register banks and resets.
Mainline currently models only the transmitter. This series adds the
receiver so a CSI camera can use the PHY, including running both
directions concurrently (a DSI panel and a CSI camera on the same PHY
instance).

Design notes, to answer the obvious questions up front:

- Direction as a phy-cell rather than a phy_set_mode() submode:
  The PHY core reference-counts power_on() per struct phy. Bringing TX
  and RX up and down independently requires one struct phy per
  direction; a submode on a single phy cannot express two concurrent
  owners. The extra cell selects which of the two phys a consumer
  gets, following how phy-exynos-mipi-video exposes multiple phys
  from one register block. The existing single-cell binding still
  resolves to the transmitter, ensuring shipped device trees remain
  unaffected.

- BIAS block coordination:
  The BIAS block is part of the PHY's common block and exists once for
  both directions (RK3588 TRM section 22.2), so it must be programmed
  only once. Whichever direction powers on first enables it, and it
  stays enabled until runtime PM suspends the PHY, matching the
  existing transmitter-only driver.

- RX tuning:
  RX tuning uses fixed RK3588 defaults. Boards that need finer
  receiver tuning should extend phy_configure_opts_mipi_dphy rather
  than add private device-tree properties.

Patch summary:
  patch 1: dt-bindings: optional second #phy-cells cell for direction
  patch 2: prep: symmetric TX power on/off helpers, no functional change
  patch 3: register one struct phy per direction
  patch 4: implement the receiver

Testing:
The series was tested on an IEI WAFER-RK3588 board across the following
configurations:
- Concurrent TX/RX: IMX219 CSI camera capture (RAW10, multiple
  resolutions up to 3280x2464) and OV5640 capture (1920x1080) through
  the DC-PHY RX, running concurrently with a MIPI DSI panel (ILI9881C,
  720x1280) driven through the TX half of the same PHY instance.
- DSI-only and CSI-only configurations, and a shipped single-cell DSI
  device tree resolving unchanged to the transmitter.
- The board wires two data lanes in each direction. 1-lane receive was
  additionally exercised end-to-end concurrently with the 2-lane
  transmitter (with a locally patched ov5640 sensor driver, as the
  mainline driver hard-codes the sensor's 2-lane mode), which also
  exercises the per-direction lane bookkeeping introduced in v2. The
  3- and 4-lane paths share the same table-driven programming but are
  untested here.
The DSI half of the concurrent tests additionally required a local
dw-mipi-dsi2 HS-video fix that is not part of this submission; the
receiver support added here is exercised independently by the CSI-only
capture.

---
Changes in v2:
- Rename the dt-bindings header to rockchip,rk3588-mipi-dcphy.h
  (Krzysztof)
- Move the lane count and the receiver link rate into per-direction
  state. A receiver configure() could previously overwrite the
  transmitter's lane count; observed on hardware as the transmitter
  leaving its second data lane enabled on power-off after the receiver
  had been configured for one lane.
- Reject the unsupported direction in configure() before touching any
  state, and drop the provider lock from configure() (per-direction
  state no longer needs it).
- Track each direction's powered state under the provider mutex instead
  of reading the peer phy's power_count.
- Switch already-enabled lanes back off when the receiver bring-up
  fails.
- Link to v1: https://lore.kernel.org/r/20260721-dcphy-rx-v1-v1-0-4fc83c0ccac9@gmail.com

---
Jason Yang (4):
      dt-bindings: phy: rockchip,rk3588-mipi-dcphy: support per-direction phys
      phy: rockchip-samsung-dcphy: factor MIPI D-PHY power on/off into helpers
      phy: rockchip-samsung-dcphy: model TX and RX as separate PHYs
      phy: rockchip-samsung-dcphy: add MIPI D-PHY receiver support

 .../bindings/phy/rockchip,rk3588-mipi-dcphy.yaml   |  22 +-
 drivers/phy/rockchip/phy-rockchip-samsung-dcphy.c  | 478 +++++++++++++++++++--
 .../dt-bindings/phy/rockchip,rk3588-mipi-dcphy.h   |  13 +
 3 files changed, 460 insertions(+), 53 deletions(-)
---
base-commit: 1590cf0329716306e948a8fc29f1d3ee87d3989f
change-id: 20260721-dcphy-rx-v1-9af57f3edfd9

Best regards,
-- 
Jason Yang <jason98166@gmail.com>



             reply	other threads:[~2026-07-26 14:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-26 14:55 Jason Yang via B4 Relay [this message]
2026-07-26 14:55 ` [PATCH v2 1/4] dt-bindings: phy: rockchip,rk3588-mipi-dcphy: support per-direction phys Jason Yang via B4 Relay
2026-07-26 15:02   ` sashiko-bot
2026-07-26 14:55 ` [PATCH v2 2/4] phy: rockchip-samsung-dcphy: factor MIPI D-PHY power on/off into helpers Jason Yang via B4 Relay
2026-07-26 14:55 ` [PATCH v2 3/4] phy: rockchip-samsung-dcphy: model TX and RX as separate PHYs Jason Yang via B4 Relay
2026-07-26 14:55 ` [PATCH v2 4/4] phy: rockchip-samsung-dcphy: add MIPI D-PHY receiver support Jason Yang via B4 Relay
2026-07-26 15:07   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260726-dcphy-rx-v1-v2-0-cf9cc34a412a@gmail.com \
    --to=devnull+jason98166.gmail.com@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=hero.huang@rock-chips.com \
    --cc=jason98166@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox