diff mbox series

[v11,13/13] arm64: dts: qcom: sa8540-ride: Enable first port of tertiary usb controller

Message ID 20230828133033.11988-14-quic_kriskura@quicinc.com
State Superseded
Headers show
Series Add multiport support for DWC3 controllers | expand

Commit Message

Krishna Kurapati Aug. 28, 2023, 1:30 p.m. UTC
From: Andrew Halaney <ahalaney@redhat.com>

There is now support for the multiport USB controller this uses so
enable it.

The board only has a single port hooked up (despite it being wired up to
the multiport IP on the SoC). There's also a USB 2.0 mux hooked up,
which by default on boot is selected to mux properly. Grab the gpio
controlling that and ensure it stays in the right position so USB 2.0
continues to be routed from the external port to the SoC.

Co-developed-by: Andrew Halaney <ahalaney@redhat.com>
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
[Krishna: Rebased on top of usb-next]
Co-developed-by: Krishna Kurapati <quic_kriskura@quicinc.com>
Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
---
 arch/arm64/boot/dts/qcom/sa8540p-ride.dts | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

Comments

Konrad Dybcio Sept. 6, 2023, 4:58 p.m. UTC | #1
On 28.08.2023 15:30, Krishna Kurapati wrote:
> From: Andrew Halaney <ahalaney@redhat.com>
> 
> There is now support for the multiport USB controller this uses so
> enable it.
> 
> The board only has a single port hooked up (despite it being wired up to
> the multiport IP on the SoC). There's also a USB 2.0 mux hooked up,
> which by default on boot is selected to mux properly. Grab the gpio
> controlling that and ensure it stays in the right position so USB 2.0
> continues to be routed from the external port to the SoC.
> 
> Co-developed-by: Andrew Halaney <ahalaney@redhat.com>
> Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
> [Krishna: Rebased on top of usb-next]
> Co-developed-by: Krishna Kurapati <quic_kriskura@quicinc.com>
> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
> ---
Is there any benefit to removing the other ports?

i.e. are ports 1-3 not parked properly by the dwc3 driver if
they're never connected to anything?

Konrad
Krishna Kurapati Sept. 7, 2023, 3:36 a.m. UTC | #2
On 9/6/2023 10:28 PM, Konrad Dybcio wrote:
> On 28.08.2023 15:30, Krishna Kurapati wrote:
>> From: Andrew Halaney <ahalaney@redhat.com>
>>
>> There is now support for the multiport USB controller this uses so
>> enable it.
>>
>> The board only has a single port hooked up (despite it being wired up to
>> the multiport IP on the SoC). There's also a USB 2.0 mux hooked up,
>> which by default on boot is selected to mux properly. Grab the gpio
>> controlling that and ensure it stays in the right position so USB 2.0
>> continues to be routed from the external port to the SoC.
>>
>> Co-developed-by: Andrew Halaney <ahalaney@redhat.com>
>> Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
>> [Krishna: Rebased on top of usb-next]
>> Co-developed-by: Krishna Kurapati <quic_kriskura@quicinc.com>
>> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
>> ---
> Is there any benefit to removing the other ports?
> 
> i.e. are ports 1-3 not parked properly by the dwc3 driver if
> they're never connected to anything?
> 
Hi Konrad,

  Whether or not the phy is connected to a port, the controller would 
modify the GUSB2PHYCFG/GUSB3PIPECTL registers. But if we don't specify 
only one phy and let phys from base DTSI take effect (4 HS / 2 SS), we 
would end up initializing and powering on phy's which are never 
connected to a port. To avoid that we need to specify only one phy for 
this platform.

Regards,
Krishna,
Krishna Kurapati Sept. 14, 2023, 3:45 p.m. UTC | #3
On 9/13/2023 5:40 PM, Konrad Dybcio wrote:
> On 7.09.2023 05:36, Krishna Kurapati PSSNV wrote:
>>
>>
>>> Is there any benefit to removing the other ports?
>>>
>>> i.e. are ports 1-3 not parked properly by the dwc3 driver if
>>> they're never connected to anything?
>>>
>> Hi Konrad,
>>
>>   Whether or not the phy is connected to a port, the controller would modify the GUSB2PHYCFG/GUSB3PIPECTL registers. But if we don't specify only one phy and let phys from base DTSI take effect (4 HS / 2 SS), we would end up initializing and powering on phy's which are never connected to a port. To avoid that we need to specify only one phy for this platform.
> And does that have any major effect on power use?
> 
> Do these PHYs not have some dormant/low power mode?
> 
Hi Konrad,

  I believe there will be some minimal power use. IMO its best to keep 
only one phy enabled for this variant instead of giving all and 
initializing/powering-on all 4 of them.

Regards,
Krishna,
diff mbox series

Patch

diff --git a/arch/arm64/boot/dts/qcom/sa8540p-ride.dts b/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
index 5a26974dcf8f..69f6b13e6197 100644
--- a/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
+++ b/arch/arm64/boot/dts/qcom/sa8540p-ride.dts
@@ -488,6 +488,19 @@  &usb_2_qmpphy0 {
 	status = "okay";
 };
 
+&usb_2 {
+	pinctrl-0 = <&usb2_en_state>;
+	pinctrl-names = "default";
+
+	status = "okay";
+};
+
+&usb_2_dwc3 {
+	dr_mode = "host";
+	phy-names = "usb2-port0", "usb3-port0";
+	phys = <&usb_2_hsphy0>, <&usb_2_qmpphy0>;
+};
+
 &xo_board_clk {
 	clock-frequency = <38400000>;
 };
@@ -640,4 +653,13 @@  wake-pins {
 			bias-pull-up;
 		};
 	};
+
+	usb2_en_state: usb2-en-state {
+		/* TS3USB221A USB2.0 mux select */
+		pins = "gpio24";
+		function = "gpio";
+		drive-strength = <2>;
+		bias-disable;
+		output-low;
+	};
 };