Hi, Bart
I think, you are asking for comment from Can. As for me, attached patch is better.
Removing ufshcd_wait_for_doorbell_clr(), instead of reading doorbell register, Now
using block layer blk_mq_{un,}freeze_queue(), looks good. I tested your V5 patches,
didn't find problem yet.
Since my available platform doesn't support dynamic clk scaling, I think, now seems only
Qcom UFS controllers support this feature. So we need Can Guo to finally confirm it.
Thanks,
//Bean
> -----Original Message-----
> From: Bart Van Assche <bvanassche@xxxxxxx>
> Sent: Wednesday, November 13, 2019 1:56 AM
> To: cang@xxxxxxxxxxxxxx
> Cc: Martin K . Petersen <martin.petersen@xxxxxxxxxx>; James E . J . Bottomley
> <jejb@xxxxxxxxxxxxxxxxxx>; Bean Huo (beanhuo) <beanhuo@xxxxxxxxxx>; Avri
> Altman <avri.altman@xxxxxxx>; Asutosh Das <asutoshd@xxxxxxxxxxxxxx>;
> Vignesh Raghavendra <vigneshr@xxxxxx>; linux-scsi@xxxxxxxxxxxxxxx; Stanley
> Chu <stanley.chu@xxxxxxxxxxxx>; Tomas Winkler <tomas.winkler@xxxxxxxxx>
> Subject: [EXT] Re: [PATCH v5 4/4] ufs: Simplify the clock scaling mechanism
> implementation
>
> On 11/12/19 4:11 PM, cang@xxxxxxxxxxxxxx wrote:
> > On 2019-11-13 01:37, Bart Van Assche wrote:
> >> @@ -1528,7 +1492,7 @@ int ufshcd_hold(struct ufs_hba *hba, bool
> >> async)
> >> */
> >> /* fallthrough */
> >> case CLKS_OFF:
> >> - ufshcd_scsi_block_requests(hba);
> >> + ufshcd_block_requests(hba, ULONG_MAX);
> >
> > ufshcd_hold(async == true) is used in ufshcd_queuecommand() path
> > because
> > ufshcd_queuecommand() can be entered under atomic contexts.
> > Thus ufshcd_block_requests() here has the same risk causing scheduling
> > while atomic.
> > FYI, it is not easy to hit above scenario in small scale of test.
>
> Hi Bean,
>
> How about replacing patch 4/4 with the attached patch?
>
> Thanks,
>
> Bart.
