On 12/5/2024 1:46 PM, Johan Hovold wrote:
On Thu, Dec 05, 2024 at 01:32:29PM +0530, Krishna Kurapati wrote:
On 12/3/2024 6:45 PM, Krishna Kurapati wrote:
On 12/3/2024 3:50 PM, Johan Hovold wrote:
On Mon, Nov 18, 2024 at 11:34:29AM +0100, Stephan Gerhold wrote:
+&usb_mp_dwc3 {
+ /* Limit to USB 2.0 and single port */
+ maximum-speed = "high-speed";
+ phys = <&usb_mp_hsphy1>;
+ phy-names = "usb2-1";
+};
The dwc3 driver determines (and acts on) the number of ports based on
the port interrupts in DT and controller capabilities.
I'm not sure we can (should) just drop the other HS PHY and the SS PHYs
that would still be there in the SoC (possibly initialised by the boot
firmware).
The DWC3 core driver identifies number of ports based on xHCI registers.
The QC Wrapper reads this number via interrupts. But these two values
are independent of each other. The core driver uses these values to
identify and manipulate phys. Even if only one HS is given in multiport
it would be sufficient if the name is "usb2-1". If the others are
missing, those phys would be read by driver as NULL and any ops to phys
would be NOP.
No, the core driver still acts on these ports (to some extent) even if
there is no PHY specified (e.g. updates DWC3_GUSB2PHYCFG on suspend).
Yes, since the port count is obtained from xHCI registers, the
GUSB2PHYCFG/ GUSB3PIPECTL regs are modified regardless we use the PHYs
or not but this is still fine. It can be considered a NOP AFAIK.
And IIRC I even had to specify more than just the fingerprint reader PHY
on the X13s to get it to enumerate. I never had time to fully determine
why this was the case though.
This might need to be checked. Did you attempt adding each phy
individually ? Just incase the first PHY is not the one corresponding to
the fingerprint reader.
Regards,
Krishna,
However do we need to reduce the number of interrupts used in DTS ?
We don't need to give all interrupts as there is only one port present.
We don't want to enable all interrupts when ports are not exposed.
No, the interrupts are still there, wired up in the SoC, so we should
not change that.
With runtime PM eventually enabled and working as it should, the OS
should be able to power down any unused ports. And we could also
consider marking some ports as not physically accessible and not
connected as a further hint to the OS that they can be disabled even
sooner.
Johan
