There are, I can dig through and find out. Atleast in downstream I don't
see any use of them.
Yes, please do post how these are wired as well for completeness.
Did you find these two interrupts as well?
Please answer.
Yes.
Controller-1:
u_usb31_prim_mvs_wrapper_usb31_hs_phy_irq SYS_apcsQgicSPI[806]
Controller-2:
u_usb31_prim_mvs_wrapper_usb31_hs_phy_irq SYS_apcsQgicSPI[791]
As an experiment, I tried to test wakeup by pressing buttons on
connected keyboard when in suspend state or connecting/disconnecting
keyboard in suspended state on different ports and only see dp/dm IRQ's
getting fired although we register for hs_phy_irq as well:
/ # cat /proc/interrupts |grep phy_
171: 1 0 0 0 0 0 0 0 PDC 127 Edge dp_hs_phy_1
172: 2 0 0 0 0 0 0 0 PDC 126 Edge dm_hs_phy_1
173: 3 0 0 0 0 0 0 0 PDC 129 Edge dp_hs_phy_2
174: 4 0 0 0 0 0 0 0 PDC 128 Edge dm_hs_phy_2
175: 0 0 0 0 0 0 0 0 PDC 131 Edge dp_hs_phy_3
176: 2 0 0 0 0 0 0 0 PDC 130 Edge dm_hs_phy_3
177: 2 0 0 0 0 0 0 0 PDC 133 Edge dp_hs_phy_4
178: 5 0 0 0 0 0 0 0 PDC 132 Edge dm_hs_phy_4
179: 0 0 0 0 0 0 0 0 PDC 16 Level ss_phy_1
180: 0 0 0 0 0 0 0 0 PDC 17 Level ss_phy_2
181: 0 0 0 0 0 0 0 0 GICv3 163 Level hs_phy_1
182: 0 0 0 0 0 0 0 0 GICv3 168 Level hs_phy_2
183: 0 0 0 0 0 0 0 0 GICv3 892 Level hs_phy_3
184: 0 0 0 0 0 0 0 0 GICv3 891 Level hs_phy_4
Yes, but that doesn't really say much since you never enable the hs_phy
interrupt in the PHY on suspend.
I did register to and enabled the hs_phy_irq interrupt when I tested and
posted the above table.
Yes, but, again, you never enabled them in the PHY (cf. QUSB2) so it's
hardly surprising that they do not fire.
There is no register in femto phy address space of sc8280 (which I am
currently testing) where we can configure these registers like qusb2 phy's.
Still good to know that requesting them doesn't trigger spurious
interrupts either since these are apparently enabled on most Qualcomm
SoCs even though they are not used. We should fix that too.
Since the hs_phy_irq is applicable only for qusb2 targets, do we still
need to add it to DT.
Are you sure there's no support for hs_phy_irq also in the "femto" PHYs
and that it's just that there is currently no driver support for using
them?
And why is it defined if there is truly no use for it?
Femto phy's have nothing to be configured for interrupts like we do for
qusb2 phy's. I confirmed from hw validation team that they never used
hs_phy_irq for validating wakeup. They only used dp/dm IRQ's for wakeup.
Ok.
Is there some other (non-wakeup) functionality which may potentially use
this interrupt?
The only info I (and hw validation team) got from design team is:
1. Common IRQ for power and special events
2. Assert in case of remote wakeup, or resume when in Host or device
respectively
3. Also upon disconnect while in suspend state.
Same as what we understand as remote wakeup functionality.
Also, if hs_phy_irq and dp/dm_phy_irq were mutually exclusive, why does
the following Qualcomm SoCs define all three?
Similar to BAM IRQ's these might have been just ported over targets I
believe. I say so because HW Validation team confirmed they don't use this
interrupt at all on femto phy targets.
So then including the hs_phy_irq for most of these SoCs was a mistake
and we should drop it from the bindings?
What about the QUSB2 SoCs that also define DP/DM, are both useable
there?
And if so, is there any reason to prefer one mechanism over the other?
No. I didn't ask this question to hw team whether dp/dm are used in
qusb2 phy targets. Let me ask them.
While I do so, since there are no qusb2 targets present on femto phy's,
do you suggest we still add them to port structure in dwc3-qcom ? I am
inclined to add it because it would make implementation look cleaner
w.r.t code and also spurious interrupts are not getting triggered (which
was my primary concern as it was never tested).
I know that if hs_phy_irq is for qusb2 and dp/dm are for femto, the
cleanup would be big.
Regards,
Krishna,
