[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZXnsFIl9i6Ix-woH@hovoldconsulting.com>
Date: Wed, 13 Dec 2023 18:38:28 +0100
From: Johan Hovold <johan@...nel.org>
To: Krishna Kurapati PSSNV <quic_kriskura@...cinc.com>
Cc: Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Andy Gross <agross@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
cros-qcom-dts-watchers@...omium.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/11] ARM/arm64: dts: qcom: fix USB wakeup interrupt
types
On Tue, Dec 12, 2023 at 03:00:07PM +0530, Krishna Kurapati PSSNV wrote:
> On 12/11/2023 10:09 PM, Johan Hovold wrote:
> > On Mon, Nov 20, 2023 at 05:43:20PM +0100, Johan Hovold wrote:
> > 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
> If it helps, I tried to dig up the PDC numbers for corresponding
> GIC_SPI vectors:
Thanks, Krisha, that helps a lot.
I've sent two series (for arm and arm64) based on yours and Konrad's
input:
https://lore.kernel.org/lkml/20231213173131.29436-1-johan+linaro@kernel.org/
https://lore.kernel.org/lkml/20231213173403.29544-1-johan+linaro@kernel.org/
> 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";
Do you have the corresponding numbers also for the second controller on
SM8150? I inferred them from SDM845, but it would good to verify that.
And can someone dig out the corresponding SS PHY interrupt for sc8180x?
Johan
Powered by blists - more mailing lists