Re: 52a518019c causes issue with Qualcomm UFSHC

Re: 52a518019c causes issue with Qualcomm UFSHC

[Asutosh Das]

On Sat, Nov 19 2022 at 20:16 -0800, Powen Kao (高伯文) wrote:
>Hi Asutosh,
>
>
>
>Reverting the patch doesn't sound feasible on MTK platform ☹
>
>
>
>>>I don't think invoking a clock scaling notification during
>
>>>ufshcd_host_reset_and_restore() sounds right to me.
>
>But the point is that driver has the right to know that the clk is scaled no matter where ufshcd_scale_clks() is invoked, no?
>
>
>
>Do you mind applying this patch on qcom driver to check on host status before further operation?

+ Mani, linux-scsi

Hello Powen
Thanks for the change. I will think of something to work-around the issue.
However, I would like to point out that a change that breaks an existing driver
must be fixed or reverted, not the other way around.

-asd

RE: 52a518019c causes issue with Qualcomm UFSHC

[Powen Kao (高伯文)]

Hi Asutosh,

Sorry for the inconvenience, we will discuss internally to see if there's a better fix that meets both our needs.

-----Original Message-----
From: Asutosh Das <quic_asutoshd@quicinc.com> 
Sent: Tuesday, November 22, 2022 6:57 AM
To: Powen Kao (高伯文) <Powen.Kao@mediatek.com>
Cc: Bart Van Assche <bvanassche@acm.org>; Stanley Chu (朱原陞) <stanley.chu@mediatek.com>; martin.petersen@oracle.com; Peter Wang (王信友) <peter.wang@mediatek.com>; Naomi Chu (朱詠田) <Naomi.Chu@mediatek.com>; Alice Chao (趙珮均) <Alice.Chao@mediatek.com>; linux-scsi@vger.kernel.org; mani@kernel.org; quic_cang@quicinc.com
Subject: Re: 52a518019c causes issue with Qualcomm UFSHC

On Sat, Nov 19 2022 at 20:16 -0800, Powen Kao (高伯文) wrote:
>Hi Asutosh,
>
>
>
>Reverting the patch doesn't sound feasible on MTK platform ☹
>
>
>
>>>I don't think invoking a clock scaling notification during
>
>>>ufshcd_host_reset_and_restore() sounds right to me.
>
>But the point is that driver has the right to know that the clk is scaled no matter where ufshcd_scale_clks() is invoked, no?
>
>
>
>Do you mind applying this patch on qcom driver to check on host status before further operation?

+ Mani, linux-scsi

Hello Powen
Thanks for the change. I will think of something to work-around the issue.
However, I would like to point out that a change that breaks an existing driver must be fixed or reverted, not the other way around.

-asd

Re: 52a518019c causes issue with Qualcomm UFSHC

[Manivannan Sadhasivam]

On Mon, Nov 21, 2022 at 02:56:34PM -0800, Asutosh Das wrote:
> On Sat, Nov 19 2022 at 20:16 -0800, Powen Kao (高伯文) wrote:
> > Hi Asutosh,
> > 
> > 
> > 
> > Reverting the patch doesn't sound feasible on MTK platform ☹
> > 
> > 
> > 
> > > > I don't think invoking a clock scaling notification during
> > 
> > > > ufshcd_host_reset_and_restore() sounds right to me.
> > 
> > But the point is that driver has the right to know that the clk is scaled no matter where ufshcd_scale_clks() is invoked, no?
> > 
> > 
> > 
> > Do you mind applying this patch on qcom driver to check on host status before further operation?
> 
> + Mani, linux-scsi
> 
> Hello Powen
> Thanks for the change. I will think of something to work-around the issue.
> However, I would like to point out that a change that breaks an existing driver
> must be fixed or reverted, not the other way around.
> 

May I know what the actual issue is? I've tested v6.1-rc1 that has this change
and didn't see any issues on SM8250, SDM845 and SM8450.

Thanks,
mani

> -asd
> 

-- 
மணிவண்ணன் சதாசிவம்

Re: 52a518019c causes issue with Qualcomm UFSHC

[Asutosh Das]

On Thu, Nov 24 2022 at 21:36 -0800, Manivannan Sadhasivam wrote:
>On Mon, Nov 21, 2022 at 02:56:34PM -0800, Asutosh Das wrote:
>> On Sat, Nov 19 2022 at 20:16 -0800, Powen Kao (高伯文) wrote:
>> > Hi Asutosh,
>> >
>> >
>> >
>> > Reverting the patch doesn't sound feasible on MTK platform ☹
>> >
>> >
>> >
>> > > > I don't think invoking a clock scaling notification during
>> >
>> > > > ufshcd_host_reset_and_restore() sounds right to me.
>> >
>> > But the point is that driver has the right to know that the clk is scaled no matter where ufshcd_scale_clks() is invoked, no?
>> >
>> >
>> >
>> > Do you mind applying this patch on qcom driver to check on host status before further operation?
>>
>> + Mani, linux-scsi
>>
>> Hello Powen
>> Thanks for the change. I will think of something to work-around the issue.
>> However, I would like to point out that a change that breaks an existing driver
>> must be fixed or reverted, not the other way around.
>>
>
>May I know what the actual issue is? I've tested v6.1-rc1 that has this change
>and didn't see any issues on SM8250, SDM845 and SM8450.
>
>Thanks,
>mani
>
Set rpm-lvl=5, enable scaling and let it enter runtime-suspend and then resume.
You should see the CMD17 timeout.

-asd
>>
>
>-- 
>மணிவண்ணன் சதாசிவம்