| Message ID | 20250226103810.3746018-3-heiko@sntech.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | phy: rockchip: usbdp: improve typec orientation handling | expand |
Hi Heiko, On 2/26/25 11:38 AM, Heiko Stuebner wrote: > From: Heiko Stuebner <heiko.stuebner@cherry.de> > > Until now the usbdp in the orientation-handler set the new lane setup in > its internal state variables and adapted the sbu gpios as needed. > It never actually updated the phy itself though, but relied on the > controlling usb-controller to disable and re-enable the phy. > > And while on the vendor-kernel, I could see that on every unplug the dwc3 > did go to its suspend and woke up on the next device plug-in event, > thus toggling the phy as needed, this does not happen in all cases and we > should not rely on that behaviour. > > This results in the usb2 always working, as it's not affected by the > orientation, but usb3 only working in one direction right now. > > So similar to how the update works in the power-on callback, just re-init > the phy if it's already running when the orientation-event happens. > > Both the power-on/-off functions as well as the orientation-set callback > work with the usbdp-mutex held, so can't conflict. > > The behaviour is similar to how the qcom qmp phys handle the orientaton > re-init - by re-initting the phy. > > Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # RK3588 Jaguar > --- > drivers/phy/rockchip/phy-rockchip-usbdp.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c > index 960cad5b01a9..c07b79da5b6b 100644 > --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c > +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c > @@ -1277,6 +1277,7 @@ static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw, > enum typec_orientation orien) > { > struct rk_udphy *udphy = typec_switch_get_drvdata(sw); > + int ret = 0; > > mutex_lock(&udphy->mutex); > > @@ -1292,9 +1293,13 @@ static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw, 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"? Cheers, Quentin
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
Hi Sebastian, On 3/1/25 10:19 PM, Sebastian Reichel wrote: > 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. > I could see some HW routing "mistake" where the USB-C connector in normal orientation has DP lanes routed to RX1/TX1? Or is this expected to just be faulty HW we shouldn't attempt at supporting? > 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 ;) > Yup I've seen that for the Rock 5 ITX and the evaluation board(s) do this. Quite interesting :) Cheers, Quentin
Hi, On Mon, Mar 03, 2025 at 10:27:31AM +0100, Quentin Schulz wrote: > On 3/1/25 10:19 PM, Sebastian Reichel wrote: > > 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. > > > > I could see some HW routing "mistake" where the USB-C connector in normal > orientation has DP lanes routed to RX1/TX1? Or is this expected to just be > faulty HW we shouldn't attempt at supporting? You mean somebody routing the RK3588 SSTX1 and SSRX1 pins to SSTX2 and SSRX2 of the TypeC connector and vice versa and thus effectively inverting the orientation on their board? I would say let's worry about that once somebody comes up with such a cursed hardware design. Note, that rockchip,dp-lane-mux wouldn't be a good property for this setup either. With USB-C you don't necessarily have 2 lanes USB3 and 2 lanes DP. You can also have 4 lanes USB3 (not supported by RK3588) or 4 lanes DP (should be supported by RK3588 hardware). So hardwiring the mux is a bad idea. Probably would require some flag for the TypeC orientation switch to handle the orientation information inverted. > > 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 ;) > > > > Yup I've seen that for the Rock 5 ITX and the evaluation board(s) do this. > Quite interesting :) > > Cheers, > Quentin Greetings, -- Sebastian
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c index 960cad5b01a9..c07b79da5b6b 100644 --- a/drivers/phy/rockchip/phy-rockchip-usbdp.c +++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c @@ -1277,6 +1277,7 @@ static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw, enum typec_orientation orien) { struct rk_udphy *udphy = typec_switch_get_drvdata(sw); + int ret = 0; mutex_lock(&udphy->mutex); @@ -1292,9 +1293,13 @@ static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw, rk_udphy_set_typec_default_mapping(udphy); rk_udphy_usb_bvalid_enable(udphy, true); + /* re-init the phy if already on */ + if (udphy->status != UDPHY_MODE_NONE) + ret = rk_udphy_init(udphy); + unlock_ret: mutex_unlock(&udphy->mutex); - return 0; + return ret; } static void rk_udphy_orien_switch_unregister(void *data)