Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
Message-ID: <73168f4b-0dc2-4060-99f2-c5e9973dbf52@quicinc.com>
Date:   Mon, 23 Oct 2023 22:52:38 +0530
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v13 07/10] usb: dwc3: qcom: Add multiport suspend/resume
 support for wrapper
Content-Language: en-US
To:     Johan Hovold <johan@kernel.org>
CC:     Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Philipp Zabel <p.zabel@pengutronix.de>,
        "Andy Gross" <agross@kernel.org>,
        Bjorn Andersson <andersson@kernel.org>,
        "Konrad Dybcio" <konrad.dybcio@linaro.org>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Felipe Balbi <balbi@kernel.org>,
        Wesley Cheng <quic_wcheng@quicinc.com>,
        <linux-usb@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>,
        <quic_pkondeti@quicinc.com>, <quic_ppratap@quicinc.com>,
        <quic_jackp@quicinc.com>, <ahalaney@redhat.com>,
        <quic_shazhuss@quicinc.com>
References: <20231007154806.605-1-quic_kriskura@quicinc.com>
 <20231007154806.605-8-quic_kriskura@quicinc.com>
 <ZTaYNjRyT1Fn4QWX@hovoldconsulting.com>
From:   Krishna Kurapati PSSNV <quic_kriskura@quicinc.com>
In-Reply-To: <ZTaYNjRyT1Fn4QWX@hovoldconsulting.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 10/23/2023 9:28 PM, Johan Hovold wrote:
> On Sat, Oct 07, 2023 at 09:18:03PM +0530, Krishna Kurapati wrote:
>> QCOM SoC SA8295P's tertiary quad port controller supports 2 HS+SS
>> ports and 2 HS only ports. Add support for configuring PWR_EVENT_IRQ's
>> for all the ports during suspend/resume.
> 
> No need to mention SA8295P as this is needed for all multiport
> controllers.
>  > Say something about adding support for multiport controllers generally
> instead and mention what the power event irqs are used for.
>

ACK.

>> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
>> ---
>>   drivers/usb/dwc3/dwc3-qcom.c | 35 ++++++++++++++++++++++++++++-------
>>   1 file changed, 28 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
>> index 651b9775a0c2..dbd4239e61c9 100644
>> --- a/drivers/usb/dwc3/dwc3-qcom.c
>> +++ b/drivers/usb/dwc3/dwc3-qcom.c
>> @@ -37,7 +37,11 @@
>>   #define PIPE3_PHYSTATUS_SW			BIT(3)
>>   #define PIPE_UTMI_CLK_DIS			BIT(8)
>>   
>> -#define PWR_EVNT_IRQ_STAT_REG			0x58
>> +#define PWR_EVNT_IRQ1_STAT_REG			0x58
>> +#define PWR_EVNT_IRQ2_STAT_REG			0x1dc
>> +#define PWR_EVNT_IRQ3_STAT_REG			0x228
>> +#define PWR_EVNT_IRQ4_STAT_REG			0x238
> 
> Not sure these defines makes sense on their own. You now only use them
> via the array below.
> 
> I think I already asked you whether these offsets depend on SoC and you
> said no, right?
> 
There are only 3 QC SoC's today that support multiport.
The offsets mentioned here are for SC8280 based platforms.

For Sc8180 based platforms, these are the offsets:
USB3_MP_PWR_EVNT_IRQ_STAT	0xA4F8858
USB3_MP_PWR_EVNT_IRQ_1_STAT	0xA4F89DC

These would translate to 0x58 and 0x1DC

And for SX8380 the values are as follows:

USB3_MP_PWR_EVNT_IRQ_STAT	0xA4F8858
USB3_MP_PWR_EVNT_IRQ_1_STAT	0xA4F89DC

So here also, the offsets are same. 0x58 and 0x1DC.
So these are not SoC specific (atleast looking at the controllers 
present). But there is no mathematical pattern to denote this as in the 
following form (x + (port_num) * y). So made an array like this.

>> +
>>   #define PWR_EVNT_LPM_IN_L2_MASK			BIT(4)
>>   #define PWR_EVNT_LPM_OUT_L2_MASK		BIT(5)
>>   
>> @@ -107,6 +111,19 @@ struct dwc3_qcom {
>>   	int			num_ports;
>>   };
>>   
>> +/*
>> + * Currently non-multiport controller have only one PWR_EVENT_IRQ register,
>> + * but multiport controllers like SA8295 contain upto 4 of them.
>> + */
> 
> Please try not talk about "currently" and as things are likely to
> change or, in fact, even *are* changing with your very patch series.
> 
> Again, this is not SA8295 specific.
> 
>> +#define NUM_PWR_EVENT_STAT_REGS	4
> 
> You already have MAX_PORTS, why are you defining a new define that will
> always have to be equal to MAX_PORTS?
> 

Do you recommend using the same max_ports ? If so, I can remove this 
macro altogether.

>> +
>> +static u32 pwr_evnt_irq_stat_reg_offset[NUM_PWR_EVENT_STAT_REGS] = {
> 
> missing const
> 
>> +	PWR_EVNT_IRQ1_STAT_REG,
>> +	PWR_EVNT_IRQ2_STAT_REG,
>> +	PWR_EVNT_IRQ3_STAT_REG,
>> +	PWR_EVNT_IRQ4_STAT_REG,
>> +};
>> +
>>   static inline void dwc3_qcom_setbits(void __iomem *base, u32 offset, u32 val)
>>   {
>>   	u32 reg;
>> @@ -446,9 +463,11 @@ static int dwc3_qcom_suspend(struct dwc3_qcom *qcom, bool wakeup)
>>   	if (qcom->is_suspended)
>>   		return 0;
>>   
>> -	val = readl(qcom->qscratch_base + PWR_EVNT_IRQ_STAT_REG);
>> -	if (!(val & PWR_EVNT_LPM_IN_L2_MASK))
>> -		dev_err(qcom->dev, "HS-PHY not in L2\n");
>> +	for (i = 0; i < qcom->num_ports; i++) {
>> +		val = readl(qcom->qscratch_base + pwr_evnt_irq_stat_reg_offset[i]);
>> +		if (!(val & PWR_EVNT_LPM_IN_L2_MASK))
>> +			dev_err(qcom->dev, "HS-PHY not in L2\n");
> 
> Error message should contain the port number.
> 

ACK

>> +	}
>>   
>>   	for (i = qcom->num_clocks - 1; i >= 0; i--)
>>   		clk_disable_unprepare(qcom->clks[i]);
>> @@ -494,9 +513,11 @@ static int dwc3_qcom_resume(struct dwc3_qcom *qcom, bool wakeup)
>>   		dev_warn(qcom->dev, "failed to enable interconnect: %d\n", ret);
>>   
>>   	/* Clear existing events from PHY related to L2 in/out */
>> -	dwc3_qcom_setbits(qcom->qscratch_base, PWR_EVNT_IRQ_STAT_REG,
>> -			  PWR_EVNT_LPM_IN_L2_MASK | PWR_EVNT_LPM_OUT_L2_MASK);
>> -
>> +	for (i = 0; i < qcom->num_ports; i++) {
>> +		dwc3_qcom_setbits(qcom->qscratch_base,
>> +			pwr_evnt_irq_stat_reg_offset[i],
>> +			PWR_EVNT_LPM_IN_L2_MASK | PWR_EVNT_LPM_OUT_L2_MASK);
> 
> Again, continuation lines should be indented at least two tabs further.
> 

ACK.

Thanks for the review.

Regards,
Krishna,