Message ID | 20231120164331.8116-1-johan+linaro@kernel.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2b07:b0:403:3b70:6f57 with SMTP id io7csp61729vqb; Mon, 20 Nov 2023 08:43:58 -0800 (PST) X-Google-Smtp-Source: AGHT+IG2OF5SiH56S67M9cfGqKzw1npSV27N6lgJIYRtHQko5pLxhUE9iFjzTYZySDbK+SHS/nFj X-Received: by 2002:a17:902:d4c4:b0:1cc:5920:1d2a with SMTP id o4-20020a170902d4c400b001cc59201d2amr7492878plg.13.1700498638285; Mon, 20 Nov 2023 08:43:58 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700498638; cv=none; d=google.com; s=arc-20160816; b=Nk2YF3bo8Gfrx7g9If1cKAydnuMOGsUBjnrkXXyAJ9yTCa5T/lq/CvTBv1Aj1kKRTj ezXhp4/svf4y0CdH3ldv1R2ZvA+/9JIZ3T3Mhbu87O4zrEVz5dfq6jAwXuGrly9scMwl 1G1YGHfDbd4sb34nuGjlDw3iSaT+ccc6DKW5HBIT87Vb4EUk9GKR4dMNLx0qbaoJT3O7 tT/SQ5xp1e+MqJkUI2cl2PZeZcyOU217/e3EEb22FenrAsC78nr88WBpGAq9BuNIXEPE TYhXhI86kIdyGMkX5lt36EeIAc05MFH77p8g2foRtF5vCZ8Z416ZDfhsyJ9FfJ5GvJyb FDOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=f983EDZ6YFF2IlCZhCiIRXzYk8iVu82/Q4oXdXs31Jg=; fh=yzxOebouBN6sudmuFYzmJ2dR3UYSeGVDo6mqqRVtKCk=; b=A6faaXGkJ5rrvKOTDmAuKfOJTNlp7YrfhGzBvh2thbBq8VTERMSu2Fooonn8m/hnyy apKGXtlK/QMd7NKoHpX03l+xc0jguDueZOqB2wXzTxyQb9BEMB2PwUXH5Y0Vsp77jWAy ASHmKu+uN7ySRtOHtitgZcysf8jYSTOJsiP+MKqPMfd9zPYF13W3z4EagQS/pjtf9ZIg QVCr0+4pj0QBIqmNhKd/PBnvxUILT6+rJpSPEFYrj2ShnehLU30gXnCFKg8yLq0K23bH 59ujDUe4dWtnuc+FT83upwK/hiQBiiukc1hLV9YDNRdbWpj3+GF5VP/XPsCtJbvMh4z7 JRyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=n+qXcFJd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id p7-20020a170902a40700b001ca30930778si7904674plq.71.2023.11.20.08.43.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Nov 2023 08:43:58 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=n+qXcFJd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id A6FDF80E068D; Mon, 20 Nov 2023 08:43:53 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233609AbjKTQns (ORCPT <rfc822;heyuhang3455@gmail.com> + 27 others); Mon, 20 Nov 2023 11:43:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43788 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232493AbjKTQnm (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 20 Nov 2023 11:43:42 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DBFDB114 for <linux-kernel@vger.kernel.org>; Mon, 20 Nov 2023 08:43:38 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54C1EC433C7; Mon, 20 Nov 2023 16:43:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1700498618; bh=hylOU4j/LA+CLsIR16LNKqzRwGIrrPV+YZyr1iajJBY=; h=From:To:Cc:Subject:Date:From; b=n+qXcFJd2DRLploMiyooJ5oVX7TPOGLYbAbTd173+vLchJWbj1evNfLjOjyY8EXNk 2onyQDcWbGLZ9VJObcAJ5yPcvCdns+yDeqyyQlICiQ9N1Icj/rnEwB+mILWBrhVYrH /mM7ouhp/A4mP72KmSTmsgz4ako55fQfCo+lShuT/8ZKnChGKeB2Jsp8W4ilQD5OGA KtCUPTa/oNHHiPzCLHygH1ukR+I1qTmhJOcTdw4YMrcZQECYcC261KXhMJP8Sdw3Q2 yyAAn5ibbFj1E/ykekiaFdnBY7G8EVB8D4pfO3g8y3XfaJ0I8tFV0lvM6bUO8tfGxK vRjBcI7tci+Pw== Received: from johan by xi.lan with local (Exim 4.96.2) (envelope-from <johan+linaro@kernel.org>) id 1r57ND-00027R-0b; Mon, 20 Nov 2023 17:43:47 +0100 From: Johan Hovold <johan+linaro@kernel.org> To: Bjorn Andersson <andersson@kernel.org> Cc: Andy Gross <agross@kernel.org>, Konrad Dybcio <konrad.dybcio@linaro.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org>, cros-qcom-dts-watchers@chromium.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Johan Hovold <johan+linaro@kernel.org> Subject: [PATCH 00/11] ARM/arm64: dts: qcom: fix USB wakeup interrupt types Date: Mon, 20 Nov 2023 17:43:20 +0100 Message-ID: <20231120164331.8116-1-johan+linaro@kernel.org> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Mon, 20 Nov 2023 08:43:53 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1783102059863230209 X-GMAIL-MSGID: 1783102059863230209 |
Series |
ARM/arm64: dts: qcom: fix USB wakeup interrupt types
|
|
Message
Johan Hovold
Nov. 20, 2023, 4:43 p.m. UTC
When testing a recent series that addresses resource leaks in the Qualcomm dwc3 glue driver [1], I realised that probe deferral can break wakeup from suspend due to how the wakeup interrupts are currently requested. The following series fixes this by no longer overriding the firmware defined trigger types for the wakeup interrupts: https://lore.kernel.org/lkml/20231120161607.7405-1-johan+linaro@kernel.org/ 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. The only exception may be sc7280 where a recent cleanup patch inadvertently switched the SS and DP trigger types, but that one should just be backported anyway. Note that the binding example is updated in the USB driver series mentioned above. Johan [1] https://lore.kernel.org/lkml/20231117173650.21161-1-johan+linaro@kernel.org/ Johan Hovold (11): ARM: dts: qcom: sdx55: fix USB wakeup interrupt types arm64: dts: qcom: sa8775p: fix USB wakeup interrupt types arm64: dts: qcom: sc7180: fix USB wakeup interrupt types arm64: dts: qcom: sc7280: fix usb_1 wakeup interrupt types arm64: dts: qcom: sc7280: fix usb_2 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 arm64: dts: qcom: sm8550: fix USB wakeup interrupt types arch/arm/boot/dts/qcom/qcom-sdx55.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sa8775p.dtsi | 12 ++++++------ arch/arm64/boot/dts/qcom/sc7180.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sc7280.dtsi | 8 ++++---- arch/arm64/boot/dts/qcom/sc8180x.dtsi | 8 ++++---- arch/arm64/boot/dts/qcom/sdm670.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sdm845.dtsi | 8 ++++---- arch/arm64/boot/dts/qcom/sm6375.dtsi | 4 ++-- arch/arm64/boot/dts/qcom/sm8150.dtsi | 8 ++++---- arch/arm64/boot/dts/qcom/sm8550.dtsi | 4 ++-- 10 files changed, 32 insertions(+), 32 deletions(-)
Comments
On Mon, 20 Nov 2023 17:43:20 +0100, Johan Hovold wrote: > When testing a recent series that addresses resource leaks in the > Qualcomm dwc3 glue driver [1], I realised that probe deferral can break > wakeup from suspend due to how the wakeup interrupts are currently > requested. > > The following series fixes this by no longer overriding the firmware > defined trigger types for the wakeup interrupts: > > [...] Applied, thanks! [01/11] ARM: dts: qcom: sdx55: fix USB wakeup interrupt types commit: d0ec3c4c11c3b30e1f2d344973b2a7bf0f986734 Best regards,
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 Sorry about not noticing this. Johan
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,
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
On 12/12/23 10:30, Krishna Kurapati PSSNV wrote:
[...]
> SM6375, I think GIC_SPI is fine but I will try to get back on this.
interrupts-extended = <&intc GIC_SPI 302 IRQ_TYPE_LEVEL_HIGH>,
<&mpm 12 IRQ_TYPE_LEVEL_HIGH>,
<&mpm 93 IRQ_TYPE_EDGE_BOTH>,
<&mpm 94 IRQ_TYPE_EDGE_BOTH>;
interrupt-names = "hs_phy_irq",
"ss_phy_irq",
"dm_hs_phy_irq",
"dp_hs_phy_irq";
the mpm node is not yet upstream (I only managed to untangle the
related mess recently), I'll submit this soon.
Thanks Krishna and Johan for looking into this!
Konrad
On Wed, Dec 13, 2023 at 07:39:59PM +0100, Konrad Dybcio wrote: > On 12/12/23 10:30, Krishna Kurapati PSSNV wrote: > > [...] > > > SM6375, I think GIC_SPI is fine but I will try to get back on this. > interrupts-extended = <&intc GIC_SPI 302 IRQ_TYPE_LEVEL_HIGH>, > <&mpm 12 IRQ_TYPE_LEVEL_HIGH>, > <&mpm 93 IRQ_TYPE_EDGE_BOTH>, > <&mpm 94 IRQ_TYPE_EDGE_BOTH>; > interrupt-names = "hs_phy_irq", > "ss_phy_irq", > "dm_hs_phy_irq", > "dp_hs_phy_irq"; > > the mpm node is not yet upstream (I only managed to untangle the > related mess recently), I'll submit this soon. Perfect, thanks! Johan