Re: [PATCH v3 1/5] dt-bindings: phy: Add PHY_TYPE_DSI and PHY_TYPE_CSI definitions

Hi,

On Wed, Aug 12, 2026 at 08:24:11PM +0800, 楊智成 wrote:
> Thanks for the review.
> 
> > I read above, but still do not get why TYPE_DPHY/CPHY is not enough.
> > Isn't DPHY implying it is DSI?
> 
> I see your point, and I did not explain this clearly enough in the previous
> version.
> 
> D-PHY only describes the electrical layer, and both MIPI DSI and MIPI CSI-2
> can run on top of it. A CSI-2 receiver's PHY is a D-PHY just as much as a
> DSI transmitter's is, so PHY_TYPE_DPHY alone does not tell us which one the
> consumer is asking for.
> 
> That is the problem here. The RK3588 DC-PHY exposes both a transmitter and
> a receiver from a single PHY block, which can be used by two independent
> consumers at the same time. This is not a theoretical concern: on this
> board a DSI panel is scanning out while the same PHY receives CSI-2 frames
> from a camera. With only the electrical layer to identify the PHY, both
> consumers would end up with the same phandle cell:
> 
> dsi@fde20000 {
> phys = <&mipidcphy0 PHY_TYPE_DPHY>; /* wants the TX */
> };
> 
> csi2@fdd10000 {
> phys = <&mipidcphy0 PHY_TYPE_DPHY>; /* wants the RX */
> };
> 
> There is then nothing in .of_xlate() to distinguish the two requests.
> 
> I will make this clearer in the v4 commit message and include the example
> above so that the reasoning is easier to follow.
> 
> For context, v2 described the direction with a Rockchip-private
> RK_DCPHY_DIR_* enum. Michael Riesch suggested using generic constants
> instead [1], and Vinod agreed [2].
> 
> [1] https://lore.kernel.org/r/[email protected]
> [2] https://lore.kernel.org/r/anSuxfeitSqmSHNr@vaman

Your new binding is lacking too. If you select <&mipidcphy0 PHY_TYPE_CSI>
you defined the direction of the PHY, but will it operate in C-PHY or in
D-PHY mode?

Greetings,

-- Sebastian

> > Your tag goes the last.
> 
> Sure, I will fix this in v4. The Signed-off-by tag will come last, and I
> will check the whole series again.
> 
> > Two simple defines needed Claude.
> 
> Yes, I agree that these two defines themselves are simple and do not really
> need AI assistance.
> 
> I added the Assisted-by tag because I used AI during the development of the
> series as a whole, including cross-checking the code, writing additional
> test cases, and looking up the relevant sections of the TRM. (I checked the
> corresponding sections in the TRM myself, reviewed the test cases, and
> re-ran them on the hardware before sending the series.)
> 
> I also checked the current mainline guidance in
> Documentation/process/submitting-patches.rst and
> Documentation/process/coding-assistants.rst. Since I was not sure how much
> AI involvement should warrant tagging individual patches, I chose to mark
> the whole series consistently.
> 
> That said, I am happy to drop the tag from this patch in v4 if you prefer -
> I wrote these two lines myself.
> 
> Thanks,
> Jason
> 
> 
> Krzysztof Kozlowski <[email protected]> 於 2026年8月12日週三 下午6:51寫道：
> >
> > On Mon, Aug 10, 2026 at 08:10:09PM +0800, Jason Yang wrote:
> > > MIPI D-PHY and C-PHY blocks are increasingly direction-agnostic: the
> > > same PHY IP can drive a MIPI DSI display or receive from a MIPI CSI-2
> > > camera, and combo blocks like the Samsung IP on RK3588 expose both
> > > directions to independent consumers at the same time. A binding that
> > > needs to tell the two consumers apart has nothing generic to reach
> > > for: most constants in this header name a protocol (PHY_TYPE_USB3,
> > > PHY_TYPE_DP, ...), while the MIPI entries name only the electrical
> > > layer.
> > >
> > > Add PHY_TYPE_DSI and PHY_TYPE_CSI to select a PHY by the MIPI
> > > protocol it speaks, which also implies the direction. They do not
> > > replace PHY_TYPE_DPHY/PHY_TYPE_CPHY, which remain the right choice
> > > where the cell selects the electrical layer. First user is the
> > > Rockchip RK3588 MIPI DC-PHY binding.
> >
> > I read above, but still do not get why TYPE_DPHY/CPHY is not enough.
> > Isn't DPHY implying it is DSI?
> >
> > >
> > > Suggested-by: Michael Riesch <[email protected]>
> > > Signed-off-by: Jason Yang <[email protected]>
> >
> > Your tag goes the last.
> >
> > > Assisted-by: Claude:claude-fable-5
> >
> > Two simple defines needed Claude. Great, that probably makes AI
> > conglomerates very happy that we do not type even two lines anymore and
> > need their resource-hungry data centers to do that for us.
> >
> > Best regards,
> > Krzysztof
> >
>

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE72YNB0Y/i3JqeVQT2O7X88g7+poFAmp9CZsACgkQ2O7X88g7
+poMdA/+ICtBJCzEX7PKeAy7Yv55VjRVuT2TXm2zXEzL51T3bDJexKUirtRbfMe8
MVsbhgPXfK0DqnsEqb3nRuKmW7ZFM73jfdVwkBHNHbbT9B8X6EjTqxWWKhJ1I7Rq
wRx0Ibvgibz+Cua/l19VI15cVzD2/qSiOQVGgQ1ZJMB7bFRhUR5mFycUFnDpqeSZ
Z6zPjsLlr9akUUFD0DM9uhLWPEdGbcfbOFDZMDmiby8QMuaL8Tiu/EEwIU/8CZyr
2LUUB7m9bZlIU+sWiSs8O8Lt3sRApYLcHOhEL6fVbeK14hjtKCTUDRu/aQVRMftM
p5pUwddJbbaoOYo8JAj1bj1M9HtAB0RhClp6zZ8hNsj9JWNaszbwi9K9T7TXW29E
gAxx6+S5K4fQW/G74cRGdPfu76njGl38OMYd5zzKmq612AL2r0fDDQL6Be8FCCb3
+amOu/h5bmtgq70/RtQvHC+gqvFU34KnOqkK1hZdOJR4cNZbdId4ZmdQvERrYozu
CCCs9odN81VkRfdoWGEt5/eOyBSIdmY//4fjQlnwS9xaTnUdc2nXNTpMvtksbdAO
G7rjixC0wzTL9nm+0ApIRPyOf9eE1B4uQU1a7HRhO5uK+IbXqpIbFe73ffGPL28b
bga6qoBymYm693W+bXUAyLRQuNNIYNp4/FMCx6z3hKHDrv5lLa8=
=EA91
-----END PGP SIGNATURE-----