Message-ID: <70b2495f-1305-05b1-2039-9573d171fe24@quicinc.com>
Date:   Mon, 7 Aug 2023 11:16:56 +0530
From:   Krishna Kurapati PSSNV <quic_kriskura@...cinc.com>
To:     Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Johan Hovold <johan@...nel.org>
CC:     Thinh Nguyen <Thinh.Nguyen@...opsys.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "Andy Gross" <agross@...nel.org>, Rob Herring <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
        Felipe Balbi <balbi@...nel.org>,
        Wesley Cheng <quic_wcheng@...cinc.com>,
        Mathias Nyman <mathias.nyman@...el.com>,
        <linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <quic_pkondeti@...cinc.com>, <quic_ppratap@...cinc.com>,
        <quic_jackp@...cinc.com>, <ahalaney@...hat.com>,
        <quic_shazhuss@...cinc.com>
Subject: Re: [PATCH v10 06/11] usb: dwc3: qcom: Refactor IRQ handling in QCOM
 Glue driver

On 8/6/2023 10:41 AM, Bjorn Andersson wrote:
> On Fri, Jul 28, 2023 at 04:03:02AM +0530, Krishna Kurapati wrote:
>> Refactor setup_irq call to facilitate reading multiport IRQ's along
>> with non mulitport ones. For SA8295, there are 4-DP/4-DM and 2-SS
>> IRQ's. Check whether device is multiport capable or not and read all
>> interrupts for DP/DM/SS on each port accordingly.
>> +/*
>> + * Driver needs to read HS/DP_HS/DM_HS/SS IRQ's. Currently, for
>> + * SA8295 which supports mutliport, thre are 4 DP/ 4 DM/ 2 SS IRQ's
>> + * and 1 HS IRQ present. So avoid trying to read HS_PHY_IRQ for 4
>> + * ports of SA8295.
>> + */
> 
> The last part here is relevant information, but it doesn't seem to
> relate to this define.
> 
> Also, does all platforms have this configuration of interrupts?
> 
Hi Bjorn,

Yes, all targets have the same IRQ's. Just that MP one's have multiple 
IRQ's of each type. But hs-phy_irq is only one in SC8280 as well.

>> +#define MAX_PHY_IRQ	4
>> +
>> +enum dwc3_qcom_phy_irq_identifier {
>> +	HS_PHY_IRQ = 0,
>> +	DP_HS_PHY_IRQ,
>> +	DM_HS_PHY_IRQ,
>> +	SS_PHY_IRQ,
>>   };
> 
> This enum is unused.
> 
>>   
> [..]
>> +static int dwc3_get_acpi_index(const struct dwc3_acpi_pdata *pdata, int irq_index)
>> +{
>> +	int acpi_index = -1;
>> +
>> +	if (!pdata)
>> +		return -1;
>> +
>> +	if (irq_index == DP_HS_PHY_IRQ)
>> +		acpi_index = pdata->dp_hs_phy_irq_index;
>> +	else if (irq_index == DM_HS_PHY_IRQ)
>> +		acpi_index = pdata->dm_hs_phy_irq_index;
>> +	else if (irq_index == SS_PHY_IRQ)
>> +		acpi_index = pdata->ss_phy_irq_index;
> 
> It looks favourable to put these in an array, instead of having to pull
> them out of 4 different variables conditionally.
> 
Sure, will move them to an array to remove this if-else stuff.
>> +
>> +	return acpi_index;
>> +		} else {
>> +			if (i == DP_HS_PHY_IRQ) {
>> +				dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL,
>> +					"dp_hs_phy_%d", port_index + 1);
>> +				disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL,
>> +					"qcom_dwc3 DP_HS%d", port_index + 1);
>> +			} else if (i == DM_HS_PHY_IRQ) {
>> +				dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL,
>> +					"dm_hs_phy_%d", port_index + 1);
>> +				disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL,
>> +					"qcom_dwc3 DM_HS%d", port_index + 1);
>> +			} else if (i == SS_PHY_IRQ) {
>> +				dt_name = devm_kasprintf(&pdev->dev, GFP_KERNEL,
>> +					"ss_phy_%d", port_index + 1);
>> +				disp_name = devm_kasprintf(&pdev->dev, GFP_KERNEL,
>> +					"qcom_dwc3 SS%d", port_index + 1);
>> +			}
> 
> There is too much repetition in this for my liking.
Will try to put dp/dm/ss too in an array in dwc3_qcom structure and 
merge these 3 loops into '1'. But that would mean I need to add a global 
structure to avoid adding if else statements to do proper kasprintf 
stuff. If its fine to add a global array with all names and use them 
here, then it would be easy to merge the loops into one for loop. But if 
we are not supposed to add global array of names, then I would keep 
these 3 repetitive code blocks as is.
> 
>>   		}
>> -		qcom->hs_phy_irq = irq;
>> -	}
>>   
>> -	irq = dwc3_qcom_get_irq(pdev, "dp_hs_phy_irq",
>> -				pdata ? pdata->dp_hs_phy_irq_index : -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,
>> -					"qcom_dwc3 DP_HS", qcom);
>> -		if (ret) {
>> -			dev_err(qcom->dev, "dp_hs_phy_irq failed: %d\n", ret);
>> -			return ret;
>> +		if (!dt_name || !disp_name)
>> +			return -ENOMEM;
>> +
>> +		acpi_index = !is_mp_supported ? dwc3_get_acpi_index(pdata, i) : -1;
>> +
>> +		irq = dwc3_qcom_get_irq(pdev, dt_name, acpi_index);
>> +		if (irq > 0) {
>> +			ret = dwc3_qcom_prep_irq(qcom, dt_name, disp_name, irq);
>> +			if (ret)
>> +				return ret;
>> +
>> +			if (i == DP_HS_PHY_IRQ)
>> +				qcom->dp_hs_phy_irq[port_index] = irq;
>> +			else if (i == DM_HS_PHY_IRQ)
>> +				qcom->dm_hs_phy_irq[port_index] = irq;
>> +			else if (i == SS_PHY_IRQ)
>> +				qcom->ss_phy_irq[port_index] = irq;
>>   		}
>> -		qcom->dp_hs_phy_irq = irq;
>>   	}
>>   
>> -	irq = dwc3_qcom_get_irq(pdev, "dm_hs_phy_irq",
>> -				pdata ? pdata->dm_hs_phy_irq_index : -1);
>> +	return 0;
>> +}
>> +
>> +static int dwc3_qcom_setup_irq(struct platform_device *pdev)
>> +{
>> +	struct dwc3_qcom *qcom = platform_get_drvdata(pdev);
>> +	const struct dwc3_acpi_pdata *pdata = qcom->acpi_pdata;
>> +	int irq;
>> +	int ret;
>> +	int i;
>> +
>> +	irq = dwc3_qcom_get_irq(pdev, "hs_phy_irq",
>> +				pdata ? pdata->hs_phy_irq_index : -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,
>> -					"qcom_dwc3 DM_HS", qcom);
>> -		if (ret) {
>> -			dev_err(qcom->dev, "dm_hs_phy_irq failed: %d\n", ret);
>> +		ret = dwc3_qcom_prep_irq(qcom, "hs_phy_irq", "qcom_dwc3 HS",irq);
>> +		if (ret)
> 
> It would be nice to have this refactored out in a separate commit.
> 
Sure, will add the prep irq in a seperate commit before we read the MP 
IRQ's.
>>   			return ret;
>> -		}
>> -		qcom->dm_hs_phy_irq = irq;
>> +		qcom->hs_phy_irq = irq;
>>   	}
>>   
>> -	irq = dwc3_qcom_get_irq(pdev, "ss_phy_irq",
>> -				pdata ? pdata->ss_phy_irq_index : -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,
>> -					"qcom_dwc3 SS", qcom);
>> -		if (ret) {
>> -			dev_err(qcom->dev, "ss_phy_irq failed: %d\n", ret);
>> +	for (i = 0; i < qcom->data->num_ports; i++) {
>> +		ret = dwc3_get_port_irq(pdev, i);
>> +		if (ret)
>>   			return ret;
>> -		}
>> -		qcom->ss_phy_irq = irq;
>>   	}
>>   
>>   	return 0;
>> @@ -811,6 +905,8 @@ static int dwc3_qcom_probe(struct platform_device *pdev)
>>   	platform_set_drvdata(pdev, qcom);
>>   	qcom->dev = &pdev->dev;
>>   
>> +	qcom->data = of_device_get_match_data(qcom->dev);
>> +
>>   	if (has_acpi_companion(dev)) {
>>   		qcom->acpi_pdata = acpi_device_get_match_data(dev);
>>   		if (!qcom->acpi_pdata) {
>> @@ -1023,8 +1119,15 @@ static const struct dev_pm_ops dwc3_qcom_dev_pm_ops = {
>>   };
>>   
>>   static const struct of_device_id dwc3_qcom_of_match[] = {
>> -	{ .compatible = "qcom,dwc3" },
>> -	{ }
>> +	{
>> +		.compatible = "qcom,dwc3",
>> +		.data = &qcom_dwc3,
>> +	},
>> +	{
>> +		.compatible = "qcom,sc8280xp-dwc3-mp",
>> +		.data = &sx8280xp_qcom_dwc3,
>> +	},
> 
> I would prefer that we don't add a separate compatible, but rather just
> try to parse the interrupts for multiport and fall back to single port.
> 
> If/when we figure out how to peak into the dwc3 core, we could
> potentially introduce a check to aid the developer.
> 

Only reason I chose this path is it is unabiguous. With this path, we 
don't need to worry about whether the user skipped any irq's in the DT 
or not. If we rely on the IRQ parsing from DT, then we might need to 
calculate effective port count while parsing the irq loop making it 
ambigous and prone to error I believe. I would like to keep this 
compatible as it and use this in the file wherever needed. And since 
peeking into dwc3-core before we call of_platform_populate is not 
possible and we need port_count, I kept a compatible here. I could move 
the setup_irq call to after completion of of_platform_populate, but 
still there is risk of dwc3 probe getting deferred or failing and we end 
up not being able to peek into dwc3.

Request you to reconsider and accept adding a compatible here.

Regards,
Krishna,

Powered by blists - more mailing lists