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: Michael Riesch <michael.riesch@collabora.com>,
Sebastian Reichel <sebastian.reichel@collabora.com>,
Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
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 v4 0/7] phy: rockchip-samsung-dcphy: Add the MIPI D-PHY receiver
Date: Fri, 21 Aug 2026 20:02:28 +0800 [thread overview]
Message-ID: <20260821-dcphy-rx-v1-v4-0-f1797634233d@gmail.com> (raw)
The Samsung MIPI D-/C-PHY block on RK3588 and RK3576 has a transmitter
(DSI) and a receiver (CSI) on the same PHY, and two drivers can use them
at the same time.
Mainline models the block as a single struct phy. The PHY core refcounts
power_on() per struct phy, so the two cannot be powered independently,
and the single devicetree cell selects the mode, so it cannot tell
whether a consumer wants the transmitter or the receiver.
This series registers a struct phy for each of them, adds generic
PHY_TYPE_DSI and PHY_TYPE_CSI constants so that the devicetree can
select between them, and implements the receiver.
1/7 adds PHY_TYPE_DSI and PHY_TYPE_CSI to the generic header
2/7 allows a second cell in this binding to select the transmitter
or the receiver
3/7 moves the block-level setup to runtime resume
4/7 names the transmitter helpers and ops (no functional change)
5/7 factors the transmitter teardown into a helper (no functional
change)
6/7 registers the receiver's struct phy and takes the second cell
in of_xlate()
7/7 implements the receiver bring-up
First, my apologies for the quality of v3. I sent it too hastily,
and much of it had not been thought through before it went to
the list.
I have removed the Assisted-by tags from 1/7, 2/7, 3/7 and 5/7. Writing this
code and the commit messages of those patches don't need AI; I only
used an AI to catch typos and to smooth my words(same as this letter).
On the points Krzysztof and Sebastian raised, I have rewritten the
commit messages of 1/7 and 2/7 and the binding text, and the binding
now lists all four combinations, so that it is clear how the mode and
the choice of transmitter or receiver go together. A single cell still
means the transmitter, so existing device trees are unaffected.
On the D-PHY / C-PHY mixing Michael asked about earlier: at the end of
TRM section 22.1 I found the sentence "The TX and RX only support
operate in the same PHY mode." So DSI and CSI can run at the same
time, but both have to be in the same mode. 2/7 says so in the binding
text and in its commit message, and 6/7 rejects one D-PHY consumer
next to one C-PHY consumer in of_xlate().
Because of that, and because the list pointed out that this is a combo
PHY, I treat the block as one transmitter PHY and one receiver PHY,
each of which can run in D-PHY or C-PHY mode. The transmitter and the
receiver therefore register their own phy_ops, and power_on() only has
to work out which mode the block is in, rather than working out both
the mode and which of the two it is being called for. C-PHY still
returns -EOPNOTSUPP throughout.
I have also moved the block-level setup into runtime resume, so that
the runtime PM usage count does the counting and I do not have to add
a refcount and a lock to protect that count. That needs the point at which
probe enables runtime PM to be fixed first, which I do not think
belongs in this series, so it is sent separately for review: [1]
[1] https://lore.kernel.org/r/20260821-dcphy-rpm-v1-v1-1-a7db728b2539@gmail.com
My apologies again to everyone who spent time on the earlier versions.
I will look over my own code more carefully before sending from now on, and
take responsibility for it. Thank you.
Testing
=======
Tested on an RK3588 board with two devicetree configurations, one boot
each.
With #phy-cells = <2>, DCPHY0 drives a DSI panel from its transmitter
while an IMX219 camera feeds its receiver; DCPHY1 drives a second DSI
panel through an unchanged single PHY_TYPE_DPHY cell.
- both panels light from boot; the camera then joins and streams
with GStreamer, so the transmitter and the receiver run at the
same time on DCPHY0
- the transmitter then leaves and rejoins mid-stream: the panel goes
off and comes back while the capture keeps running
- no WARNING, underflow, "Internal error" or Oops in dmesg
With dsi0 disabled, DCPHY0 has no transmitter consumer at all for the
whole boot, and the camera still brings the block up and streams. That
path only works because 3/7 moved the block-level setup to runtime
resume.
Not covered: RK3576, which this driver and binding also describe, and
the 3- and 4-lane receiver paths.
The DSI panels only light with the U-Boot SPLL fix [2] applied:
without it the bootloader leaves the SPLL at its 351 MHz bootrom
default while the devicetree describes it as a 702 MHz fixed clock,
halving the rate of both DSI hosts. The receiver path is unaffected;
the camera captures exercise it independently.
[2] https://lore.kernel.org/u-boot/20260804002643.2308515-3-jonas@kwiboo.se/
---
Changes in v4:
- Put the second cell back: the first cell selects the mode, the
second the transmitter or the receiver.
- Drop the private use count and mutex; the runtime PM usage count
does the same job.
- New patch 3/7: move the block-level setup to runtime resume.
- Split v3's 3/5 into 4/7 and 5/7.
- of_xlate() rejects a mix of D-PHY and C-PHY consumers.
- The runtime PM probe-order fix is now a separate patch [1] that this
series applies on top of.
- Bryan O'Donoghue's Reviewed-by from v2 is not carried over; that
patch was rewritten.
- Link to v3: https://lore.kernel.org/r/20260810-dcphy-rx-v1-v3-0-a2d25c29adfc@gmail.com
---
Jason Yang (7):
dt-bindings: phy: Add PHY_TYPE_DSI and PHY_TYPE_CSI definitions
dt-bindings: phy: rockchip,rk3588-mipi-dcphy: Allow DSI and CSI consumers
phy: rockchip-samsung-dcphy: Move block-level setup to runtime resume
phy: rockchip-samsung-dcphy: Name the transmitter helpers and ops
phy: rockchip-samsung-dcphy: Factor the transmitter teardown into a helper
phy: rockchip-samsung-dcphy: Add a second PHY for the receiver
phy: rockchip-samsung-dcphy: Add MIPI D-PHY receiver support
.../bindings/phy/rockchip,rk3588-mipi-dcphy.yaml | 20 +-
drivers/phy/rockchip/phy-rockchip-samsung-dcphy.c | 552 ++++++++++++++++++---
include/dt-bindings/phy/phy.h | 2 +
3 files changed, 515 insertions(+), 59 deletions(-)
---
base-commit: b828e5a7fb47aa434b8b20636de5d47356314322
change-id: 20260721-dcphy-rx-v1-9af57f3edfd9
Best regards,
--
Jason Yang <jason98166@gmail.com>
next reply other threads:[~2026-08-21 12:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-21 12:02 Jason Yang via B4 Relay [this message]
2026-08-21 12:02 ` [PATCH v4 1/7] dt-bindings: phy: Add PHY_TYPE_DSI and PHY_TYPE_CSI definitions Jason Yang via B4 Relay
2026-08-27 11:45 ` Krzysztof Kozlowski
2026-08-21 12:02 ` [PATCH v4 2/7] dt-bindings: phy: rockchip,rk3588-mipi-dcphy: Allow DSI and CSI consumers Jason Yang via B4 Relay
2026-08-27 11:47 ` Krzysztof Kozlowski
2026-08-21 12:02 ` [PATCH v4 3/7] phy: rockchip-samsung-dcphy: Move block-level setup to runtime resume Jason Yang via B4 Relay
2026-08-21 12:02 ` [PATCH v4 4/7] phy: rockchip-samsung-dcphy: Name the transmitter helpers and ops Jason Yang via B4 Relay
2026-08-21 12:02 ` [PATCH v4 5/7] phy: rockchip-samsung-dcphy: Factor the transmitter teardown into a helper Jason Yang via B4 Relay
2026-08-21 12:02 ` [PATCH v4 6/7] phy: rockchip-samsung-dcphy: Add a second PHY for the receiver Jason Yang via B4 Relay
2026-08-21 12:02 ` [PATCH v4 7/7] phy: rockchip-samsung-dcphy: Add MIPI D-PHY receiver support Jason Yang via B4 Relay
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=20260821-dcphy-rx-v1-v4-0-f1797634233d@gmail.com \
--to=devnull+jason98166.gmail.com@kernel.org \
--cc=bryan.odonoghue@linaro.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=michael.riesch@collabora.com \
--cc=neil.armstrong@linaro.org \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=sebastian.reichel@collabora.com \
--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