On 2019-11-15 00:11, Bart Van Assche wrote:
On 11/13/19 8:03 AM, Bean Huo (beanhuo) wrote:
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.
Hi Can,
Do you agree with this patch series if patch 4 is replaced by the
patch attached to my previous e-mail? The entire (revised) series is
available at https://github.com/bvanassche/linux/tree/ufs-for-next.
Thanks,
Bart.
Hi Bart,
After ufshcd_clock_scaling_prepare() returns(no error), all request
queues are frozen. If failure
happens(say power mode change command fails) after this point and error
handler kicks off,
we need to send dev commands(in ufshcd_probe_hba()) to bring UFS back to
functionality.
However, as the hba->cmd_queue is frozen, dev commands cannot be sent,
the error handler shall fail.
Thanks,
Can Guo.
