by Johan Hovold

[permalink] [raw]

Subject: Re: [PATCH v9 06/10] usb: dwc3: qcom: Add support to read IRQ's related to multiport

On Mon, Jul 03, 2023 at 12:29:41AM +0530, Krishna Kurapati PSSNV wrote:
> On 6/27/2023 8:01 PM, Johan Hovold wrote:
> > On Wed, Jun 21, 2023 at 10:06:24AM +0530, Krishna Kurapati wrote:

> >> +static int dwc3_qcom_setup_mp_irq(struct platform_device *pdev)
> >> +{
> >> + struct dwc3_qcom *qcom = platform_get_drvdata(pdev);
> >> + char irq_name[15];
> >> + int irq;
> >> + int ret;
> >> + int i;
> >> +
> >> + for (i = 0; i < 4; i++) {
> >
> > DWC3_MAX_PORTS here too and similar below.
> >
> >> + if (qcom->dp_hs_phy_irq[i])
> >> + continue;
> >
> > This is not very nice. You should try to integrate the current lookup
> > code as I told you to do with the PHY lookups. That is, use a single
> > loop for all HS/SS IRQs, and pick the legacy name if the number of ports
> > is 1.
> >
> > Of course, you added the xhci capability parsing to the core driver so
> > that information is not yet available, but you need it in the glue
> > driver also...
> >
> > As I mentioned earlier, you can infer the number of ports from the
> > interrupt names. Alternatively, you can infer it from the compatible
> > string. In any case, you should not need to ways to determine the same
> > information in the glue driver, then in the core part, and then yet
> > again in the xhci driver...

> The reason why I didn't integrate this with the original function was
> the ACPI stuff. The MP devices have no ACPI variant. And I think for
> clarity sake its best to keep these two functions separated.

No. The ACPI stuff may make this a little harder to implement, but
that's not a sufficient reason to not try to refactor things properly.

> >> +
> >> + sprintf(irq_name, "dp%d_hs_phy_irq", i+1);
> >
> > Spaces around binary operators. Does not checkpatch warn about that?
> >
> >> + irq = dwc3_qcom_get_irq(pdev, irq_name, -1);
> >> + if (irq > 0) {
> >> + irq_set_status_flags(irq, IRQ_NOAUTOEN);
> >> + ret = devm_request_threaded_irq(qcom->dev, irq, NULL,
> >> + qcom_dwc3_resume_irq,
> >> + IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> >> + irq_name, qcom);
> >> + if (ret) {
> >> + dev_err(qcom->dev, "%s failed: %d\n", irq_name, ret);
> >> + return ret;
> >> + }
> >> + }
> >> +
> >> + qcom->dp_hs_phy_irq[i] = irq;
> >> + }
> >> +
> >> + for (i = 0; i < 4; i++) {
> >> + if (qcom->dm_hs_phy_irq[i])
> >> + continue;
> >> +
> >> + sprintf(irq_name, "dm%d_hs_phy_irq", i+1);
> >> + irq = dwc3_qcom_get_irq(pdev, irq_name, -1);
> >> + if (irq > 0) {
> >> + irq_set_status_flags(irq, IRQ_NOAUTOEN);
> >> + ret = devm_request_threaded_irq(qcom->dev, irq, NULL,
> >> + qcom_dwc3_resume_irq,
> >> + IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> >> + irq_name, qcom);
> >> + if (ret) {
> >> + dev_err(qcom->dev, "%s failed: %d\n", irq_name, ret);
> >> + return ret;
> >> + }
> >> + }
> >> +
> >> + qcom->dm_hs_phy_irq[i] = irq;
> >> + }
> >> +
> >> + for (i = 0; i < 2; i++) {
> >> + if (qcom->ss_phy_irq[i])
> >> + continue;
> >> +
> >> + sprintf(irq_name, "ss%d_phy_irq", i+1);
> >> + irq = dwc3_qcom_get_irq(pdev, irq_name, -1);
> >> + if (irq > 0) {
> >> + irq_set_status_flags(irq, IRQ_NOAUTOEN);
> >> + ret = devm_request_threaded_irq(qcom->dev, irq, NULL,
> >> + qcom_dwc3_resume_irq,
> >> + IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
> >> + irq_name, qcom);
> >> + if (ret) {
> >> + dev_err(qcom->dev, "%s failed: %d\n", irq_name, ret);
> >> + return ret;
> >> + }
> >> + }
> >> +
> >> + qcom->ss_phy_irq[i] = irq;
> >> + }
> >
> > So the above should all be merged in either a single helper looking up
> > all the interrupts for a port and resused for the non-MP case.
> >
> I agree, Will merge all under some common helper function.

Good.

Johan

2023-07-21 08:47:48

On Fri, Jul 21, 2023 at 03:05:36PM +0530, Krishna Kurapati PSSNV wrote:
> On 7/21/2023 2:51 PM, Johan Hovold wrote:

> > As I wrote above, I think you should instead add a common helper for
> > setting up all the interrupts for a port. For example, along the lines
> > of:
> >
> > dwc3_setup_port_irq(int index)
> > {
> > if (index == 0)
> > try non-mp name
> > else
> > generate mp name
> >
> > lookup and request hs irqs
> > lookup and request ss irq
> > lookup and request power irq
> > }
> >
> > dwc3_setup_irq()
> > {
> > determine if MP (num_ports)
> >
> > for each port
> > dwc3_setup_port_irq(port index)
> > }
> > The port irq helper can either be told using a second argument that this
> > is a non-mp controller, or you can first try looking up one of the
> > non-mp names.

> I think I did something similar. I prepared a helper to request IRQ in
> the patch and the main logic would reside in setup_irq where i would try
> and get IRQ's.

No, you only added a wrapper around request_irq() but no helper to
setup all irqs for a port, so that's not really similar.

> Irrespective of whether we are MP capable or not, how about we read all
> IRQ's like in the patch attached previously. And the implementation
> facilitates addition of ACPI to multiport also if required. I am just
> trying to cover all cases like this by declaring IRQ info in global section.
>
> static int dwc3_qcom_prep_irq(struct dwc3_qcom *qcom, char *irq_name,
> char *disp_name, int irq)
> {
> int ret;
>
> /* Keep wakeup interrupts disabled until suspend */
> irq_set_status_flags(irq, IRQ_NOAUTOEN);
> ret = devm_request_threaded_irq(/* Give inouts here*/);
> if (ret)
> dev_err(qcom->dev, "%s failed: %d\n", irq_name, ret);
>
> return ret;
> }
>
>
> static int dwc3_qcom_setup_irq(struct platform_device *pdev)
> {
> for (DP_IRQ[ i = 0-3] {
> try getting dp_irq_i using MP_IRQ strings
> if ((ret < 0) and (i == 0))
> try getting dp_irq_i using NON_MP_IRQ strings
>
> call prep_irq accordingly.
> }
>
> //Run same loop for DM and SS
> }

So again, the above is not setting up all irqs for a port in one place
which seems like the natural way to add support for multiport.

It should be possible to reuse a per-port setup function also for ACPI.

> The second patch was just enabling IRQ's for all ports to support wakeup.
>
> > My mailer discarded your second patch, but you cannot assume that the
> > devices connected to each port are of the same type (e.g. HS or SS)
> > based on what is connected to the first port.
> >
> Are you referring to enabling IRQ's for different ports before going to
> suspend ? Meaning get the speed of enum on each port and accordingly
> enable IRQ's ?

Exactly. That will be needed.

Johan