public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Krishna Kurapati <quic_kriskura@quicinc.com>
Cc: Andy Gross <agross@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	quic_wcheng@quicinc.com, linux-arm-msm@vger.kernel.org,
	linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, quic_ppratap@quicinc.com,
	quic_jackp@quicinc.com
Subject: Re: [PATCH 1/6] dt-bindings: usb: dwc3: Clean up hs_phy_irq in bindings
Date: Thu, 23 Nov 2023 15:10:42 +0100	[thread overview]
Message-ID: <ZV9dYpTYRXn63tXe@hovoldconsulting.com> (raw)
In-Reply-To: <20231122191335.3058-1-quic_kriskura@quicinc.com>

On Thu, Nov 23, 2023 at 12:43:35AM +0530, Krishna Kurapati wrote:
> The high speed related interrupts present on QC targets are as follows:
> 
> dp/dm Irq's
> These IRQ's directly reflect changes on the DP/DM pads of the SoC. These
> are used as wakeup interrupts only on SoCs with non-QUSBb2 targets with
> exception of SDM670/SDM845/SM6350.
> 
> qusb2_phy irq
> SoCs with QUSB2 PHY do not have separate DP/DM IRQs and expose only a
> single IRQ whose behavior can be modified by the QUSB2PHY_INTR_CTRL
> register. The required DPSE/DMSE configuration is done in
> QUSB2PHY_INTR_CTRL register of phy address space.
> 
> hs_phy_irq
> This is completely different from the above two and is present on all
> targets with exception of a few IPQ ones. The interrupt is not enabled by
> default and its functionality is mutually exclusive of qusb2_phy on QUSB
> targets and DP/DM on femto phy targets.
> 
> The DTs of several QUSB2 PHY based SoCs incorrectly define "hs_phy_irq"
> when they should have been "qusb2_phy_irq". On Femto phy targets, the
> "hs_phy_irq" mentioned is either the actual "hs_phy_irq" or "pwr_event",
> neither of which would never be triggered directly are non-functional
> currently. The implementation tries to clean up this issue by addressing
> the discrepencies involved and fixing the hs_phy_irq's in respective DT's.

Thanks for sorting this out.

It seems like we have a few combinations of these interrupts and we
should probably try to define the order for these once and for all and
update the current devicetrees to match (even if it means adding new
interrupts in the middle).

Instead of adding separate compatibles for the controllers without SS
support, I suggest keeping that interrupt last as an optional one.

But IIUC we essentially have something like:

qusb2-:

	- const: qusb2_phy
	- const: pwr_event
	- const: ss_phy_irq	(optional)

qusb2:

	- const: hs_phy_irq
	- const: qusb2_phy
	- const: pwr_event
	- const: ss_phy_irq	(optional)

qusb2+:

	- const: hs_phy_irq
	- const: qusb2_phy
	- const: dp_hs_phy_irq
	- const: dm_hs_phy_irq
	- const: pwr_event
	- const: ss_phy_irq	(optional)

femto-:
	- const: dp_hs_phy_irq
	- const: dm_hs_phy_irq
	- const: pwr_event
	- const: ss_phy_irq	(optional)

femto:
	- const: hs_phy_irq
	- const: dp_hs_phy_irq
	- const: dm_hs_phy_irq
	- const: pwr_event
	- const: ss_phy_irq	(optional)

Does this look like it would cover all of our currents SoCs?

Do all of them have the pwr_event interrupt?

Note that DP comes before DM above as that seems like the natural order
of these (plus before minus).

Now if the HS interrupt is truly unusable, I guess we can consider
dropping it throughout and the above becomes just three permutations
instead, which can even be expressed along the lines of:

	- anyOf:
	  - items:
	    - const: qusb2_phy
	  - items:
	    - const: dp_hs_phy_irq
	    - const: dm_hs_phy_irq
	- const: pwr_event
	- const: ss_phy_irq	(optional)

Johan

  parent reply	other threads:[~2023-11-23 14:10 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-22 19:13 [PATCH 1/6] dt-bindings: usb: dwc3: Clean up hs_phy_irq in bindings Krishna Kurapati
2023-11-22 20:25 ` Marijn Suijten
2023-11-23  7:41 ` Krzysztof Kozlowski
2023-11-23  7:44   ` Krishna Kurapati PSSNV
2023-11-23  7:50     ` Krzysztof Kozlowski
2023-11-23  7:57       ` Krishna Kurapati PSSNV
2023-11-23 14:10 ` Johan Hovold [this message]
2023-11-24 12:02   ` Krishna Kurapati PSSNV
2023-11-24 13:46     ` Johan Hovold
2023-11-24 17:39       ` Krishna Kurapati PSSNV
2023-11-28 10:21         ` Johan Hovold
2023-11-28 10:32           ` Krishna Kurapati PSSNV
2023-11-28 10:57             ` Johan Hovold
2023-11-28 11:32               ` Krishna Kurapati PSSNV
2023-11-29  9:28                 ` Krzysztof Kozlowski
2023-11-29 10:16                   ` Johan Hovold
2023-11-29 10:50                     ` Krishna Kurapati PSSNV
2023-11-30  8:08                       ` Krzysztof Kozlowski
2023-11-30  8:16                     ` Krzysztof Kozlowski
2023-11-30  8:34                       ` Johan Hovold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZV9dYpTYRXn63tXe@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=quic_jackp@quicinc.com \
    --cc=quic_kriskura@quicinc.com \
    --cc=quic_ppratap@quicinc.com \
    --cc=quic_wcheng@quicinc.com \
    --cc=robh+dt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox