| Message ID | 20230828133033.11988-14-quic_kriskura@quicinc.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Add multiport support for DWC3 controllers | expand |
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
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,
On 7.09.2023 05:36, Krishna Kurapati PSSNV wrote: > > > 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. And does that have any major effect on power use? Do these PHYs not have some dormant/low power mode? Konrad
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,
On 9/14/23 17:45, Krishna Kurapati PSSNV wrote: > > > 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. Okay let's not waste power.. Konrad
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; + }; };