lkml.org 
[lkml]   [2023]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 00/11] ARM/arm64: dts: qcom: fix USB wakeup interrupt types
From


On 12/11/2023 10:09 PM, Johan Hovold wrote:
> On Mon, Nov 20, 2023 at 05:43:20PM +0100, Johan Hovold wrote:
>
>> It turns out a number Qualcomm devicetrees have also gotten the trigger
>> types wrong, something which this series addresses.
>>
>> Specifically, the HS/SS PHY wakeup interrupts are level triggered while
>> the DP/DM HS PHY interrupts are edge triggered, and which edge to
>> trigger on depends both on the use-case and on whether a Low speed or
>> Full/High speed device is connected.
>>
>> Fortunately, there should be no dependency between this series and USB
>> one as all devicetree use the correct trigger type for the HS/SS PHY
>> interrupts and the HS one has never been armed by Linux anyway. The
>> DP/DM interrupt trigger types are also updated on suspend currently.
>
> Konrad reported off-list that the sc8180x patch in this series breaks
> probe of the dwc3 driver.
>
> Turns out a number of these SoCs were using GIC interrupts for the
> DP/DM_HS_PHY interrupts despite the fact that the driver tries to
> reconfigure these as IRQ_TYPE_EDGE_FALLING (which the GIC does not
> support) to detect disconnect events during suspend.
>
> This is obviously broken and the proper fix is to replace the GIC
> interrupts with the corresponding PDC interrupts. I believe Konrad is
> digging out the magic numbers at this moment.
>
> The following patches will need a follow-up fix:
>
>> ARM: dts: qcom: sdx55: fix USB wakeup interrupt types
>
>> arm64: dts: qcom: sc8180x: fix USB wakeup interrupt types
>> arm64: dts: qcom: sdm670: fix USB wakeup interrupt types
>> arm64: dts: qcom: sdm845: fix USB wakeup interrupt types
>> arm64: dts: qcom: sm6375: fix USB wakeup interrupt types
>> arm64: dts: qcom: sm8150: fix USB wakeup interrupt types
>
Hi Johan,

If it helps, I tried to dig up the PDC numbers for corresponding
GIC_SPI vectors:


SM8150:

eud_p0_dpse_int_mx apps_pdc_irq_out[9] SYS_apcsQgicSPI[489]
eud_p0_dmse_int_mx  apps_pdc_irq_out[8] SYS_apcsQgicSPI[488]
qmp_usb3_lfps_rxterm_irq apps_pdc_irq_out[6] SYS_apcsQgicSPI[486]
usb31_power_event_irq SYS_apcsQgicSPI[130]
usb31_hs_phy_irq SYS_apcsQgicSPI[131]

interrupts-extended = <&pdc 9 IRQ_TYPE_EDGE_RISING>,
<&intc GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH>,
<&pdc 6 IRQ_TYPE_LEVEL_HIGH>,
<&pdc 8 IRQ_TYPE_EDGE_RISING>;

interrupt-names = "dp_hs_phy_irq", "pwr_event_irq",
"ss_phy_irq", "dm_hs_phy_irq";

--

sdm845-670-usb-common.dtsi

interrupts = <0 489 0>, <0 130 0>, <0 486 0>, <0 488 0>;
interrupt-names = "dp_hs_phy_irq", "pwr_event_irq",
"ss_phy_irq", "dm_hs_phy_irq";

interrupts = <0 491 0>, <0 135 0>, <0 487 0>, <0 490 0>;
interrupt-names = "dp_hs_phy_irq", "pwr_event_irq",
"ss_phy_irq", "dm_hs_phy_irq";

eud_p0_dpse_int_mx apps_pdc_irq_out[9] SYS_apssQgicSPI[489]
eud_p0_dmse_int_mx apps_pdc_irq_out[8] SYS_apssQgicSPI[488]
eud_p1_dmse_int_mx apps_pdc_irq_out[10] SYS_apssQgicSPI[490]
eud_p1_dpse_int_mx apps_pdc_irq_out[11] SYS_apssQgicSPI[491]
qmp_usb3_lfps_rxterm_irq apps_pdc_irq_out[7] SYS_apssQgicSPI[487]
qmp_usb3_lfps_rxterm_irq apps_pdc_irq_out[6] SYS_apssQgicSPI[486]

--

SDX55:

interrupts = <0 157 0>, <0 130 0>, <0 158 0>, <0 198 0>;
interrupt-names = "dp_hs_phy_irq", "pwr_event_irq",
"dm_hs_phy_irq", "ss_phy_irq";

eud_p1_dpse_int_mx apps_pdc_irq_out[10] SYS_apcsQgicSPI[157]
eud_p1_dmse_int_mx apps_pdc_irq_out[11] SYS_apcsQgicSPI[158]
apps_pdc.gp_irq_mux[31] apps_pdc_irq_out[51] SYS_apcsQgicSPI[198]

--

SM6375, I think GIC_SPI is fine but I will try to get back on this.

Sorry for bad formatting.

Regards,
Krishna,

\
 
 \ /
  Last update: 2023-12-12 10:30    [W:1.041 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site