From: Michael Riesch <michael.riesch@collabora.com>
To: 楊智成 <jason98166@gmail.com>
Cc: 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>,
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
Subject: Re: [PATCH v2 3/4] phy: rockchip-samsung-dcphy: model TX and RX as separate PHYs
Date: Sat, 8 Aug 2026 00:59:47 +0200 [thread overview]
Message-ID: <00d6ee9d-0ef1-41d4-8cd7-affb320b84f4@collabora.com> (raw)
In-Reply-To: <CAPwA33Jnp6N7a=2tcrgEzFxXRpbxEO25ktrRDiea--9Uy5upNQ@mail.gmail.com>
Hi Jason,
On 8/4/26 07:38, 楊智成 wrote:
> [...]
>> This approach with the "first" variable seems unintuitive. If you need
>> reference counting on the BIAS block, then use a state variable
>> "bias_powered", use a mutex that protects it, and call
>> samsung_mipi_dcphy_bias_block_{en,dis}able (from
>> samsung_mipi_dcphy_power{on, off}) unconditionally. Those methods shall
>> acquire the mutex, check the state variable, {en,dis}able the BIAS
>> block, set the state variable accordingly, release the mutex.
>>
>> [...]
>>
>> Not sure whether you actually need to track the power status of the
>> individual PHYs (maybe you actually need to track the BIAS block status
>> alone) but anyway I would appreciate if
>> "samsung_mipi_dphy_tx_power_{on,off}" would set the "pd->powered"
>> variable.
>
> Both of these lead to the same change. You are right to be unsure
> about the per-PHY flag - I checked, and its only readers are the two
> "first" computations, which only decide about the shared block. So the
> two flags become one count in the parent, taken and dropped inside
> samsung_mipi_dphy_{tx,rx}_power_{on,off}, and the "first" computations
> go away. I went for a count rather than a single flag because the
> release side has to distinguish "the other direction is still using
> it" from "nobody is left".
>
> The shared-block helper will use lockdep_assert_held() rather than
> take the mutex itself, since samsung_mipi_dcphy_power_{on,off} already
> hold it, as you noted.
>
> One thing I am unsure about is the enable/disable pairing. I could not
> find an enable for this block - the four BIAS registers only select
> bias currents, reference voltages, the HS output level and the BGR
> chopper divider, while PLL_CON0 in the same common block does have a
> PLL_EN. If that reading is right, there is nothing to turn off and the
> release side would only drop the count - in which case maybe the
> "enable" name is worth revisiting as well. Does that match your
> understanding of this block?
My understanding of this block comes from the TRM and the downstream
driver. TRM states that the BIAS block is common (= shared between RX
and TX), but Downstream driver does not care and just writes the
settings for RX and TX unconditionally.
There is also something weird: the register description in the GRF
indicates that RX could be in CPHY and TX in DPHY mode. But CPHY and
DPHY require different values for the DCPHY_M0_BIAS_CON4. I'll try to
ask Rockchip people about this.
BTW no objections to renaming this to e.g. "*_configure()" and use a
flag "bool configured;" if required.
> Separately, I noticed "first" also guards the APB reset, and only in
> the transmitter path - once 4/4 enables the receiver, a receiver-first
> power-on does not get one. I plan to move it into the same shared-block
> path so both directions behave the same, and check both power-on
> orders on the board before sending v3.
>
> I would like to fold all of this into v3 together with whatever comes
> out of the PHY_TYPE_CSI/PHY_TYPE_DSI discussion in patch 1/4, since
> that decides how the two PHYs are told apart.
OK, makes sense. Looking forward to v3!
Thanks and best regards,
Michael
> [...]
next prev parent reply other threads:[~2026-08-07 23:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-26 14:55 [PATCH v2 0/4] phy: rockchip-samsung-dcphy: support the D-PHY receiver direction Jason Yang via B4 Relay
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-08-03 11:17 ` Michael Riesch
2026-08-06 15:56 ` Vinod Koul
2026-08-07 21:33 ` Michael Riesch
2026-08-06 16:14 ` Bryan O'Donoghue
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-08-06 16:17 ` Bryan O'Donoghue
2026-08-06 19:31 ` Sebastian Reichel
2026-08-07 9:09 ` Bryan O'Donoghue
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-08-03 12:05 ` Michael Riesch
2026-08-04 5:38 ` 楊智成
2026-08-07 22:59 ` Michael Riesch [this message]
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
2026-07-27 2:01 ` 楊智成
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=00d6ee9d-0ef1-41d4-8cd7-affb320b84f4@collabora.com \
--to=michael.riesch@collabora.com \
--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