[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dkjpudmzuuxvaotz4mx46yx7iacof7q6ck746j3rrqvlgbq3hk@6vtvy3gy3kff>
Date: Sat, 1 Mar 2025 22:19:28 +0100
From: Sebastian Reichel <sebastian.reichel@...labora.com>
To: Quentin Schulz <quentin.schulz@...rry.de>
Cc: Heiko Stuebner <heiko@...ech.de>, vkoul@...nel.org, kishon@...nel.org,
linux-phy@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org,
linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org, christophe.jaillet@...adoo.fr,
Heiko Stuebner <heiko.stuebner@...rry.de>
Subject: Re: [PATCH v2 2/2] phy: rockchip: usbdp: re-init the phy on
orientation-change
Hello Quentin,
On Wed, Feb 26, 2025 at 01:38:10PM +0100, Quentin Schulz wrote:
> Unrelated to this patch (but may be triggered by this patch?), I'm wondering
> how flip is really handled.
>
> It seems like we have flip store the orientation of the cable, but also if
> rockchip,dp-lane-mux is set to <0 1>. But wouldn't that break if we ignore
> that initial flipped lane-mux whenever a USB-C cable is inserted in reverse?
> Basically, shouldn't a reserve orientation of the cable when
> rockchip,dp-lane-mux is set to <0 1> mean "normal mux"?
If a USB-C connector is involved, the TypeC controller is supposed to
setup the lane muxing based on the connector orientation. This
happens via the typec API and in this hardware setup the PHY should
not have the rockchip,dp-lane-mux DT property set.
The rockchip,dp-lane-mux property is required if no USB-C connector
is involved. For example if the lanes are routed to a Displayport
connector. In that case the lane setup is fixed in hardware and
there is no TypeC controller involved, which could do any setup ;)
-- Sebastian
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists