Hi Can, On Wed, 2020-02-19 at 10:35 +0800, Can Guo wrote: > Since we all need this delay here, how about put the delay in the > entrence of ufshcd_setup_clocks(), before vops_setup_clocks()? > If so, we can remove all the delays we added in our vops since the > delay anyways delays everything inside ufshcd_setup_clocks(). > Always putting the delay in the entrance of ufshcd_setup_clocks() may add unwanted delay for vendors, just like your current implementation, or some other vendors who do not want to disable the reference clock. I think current patch is more reasonable because the delay is applied to clock only named as "ref_clk" specifically. If you needs to keep "ref_clk" in DT, would you consider to remove the delay in your ufs_qcom_dev_ref_clk_ctrl() and let the delay happens via common ufshcd_setup_clocks() only? However you may still need delay if call path comes from ufs_qcom_pwr_change_notify(). What do you think? > Meanwhile, if you want to modify the delay > (hba->dev_info.clk_gating_wait_us) for some reasons, say for specific > UFS devices, you still can do it in vops_apply_dev_quirks(). > > What do you say? > > Thanks, > Can Guo. Thanks, Stanley Chu
