Re: [PATCH v1 1/2] scsi: ufs: set device as default active power mode during initialization only

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2020-01-03 09:51, Can Guo wrote:
On 2020-01-02 14:38, Stanley Chu wrote:
Hi Can,

On Tue, 2019-12-31 at 16:35 +0800, Can Guo wrote:

Hi Stanley,

I missed this mail before I hit send. In current code, as per my
understanding,
UFS device's power state should be Active after ufshcd_link_startup()
returns.
If I am wrong, please feel free to correct me.


Yes, this assumption of ufshcd_probe_hba() is true so I will drop this
patch.
Thanks for remind.

Due to you are almost trying to revert commit 7caf489b99a42a, I am just
wondering
if you encounter failure/error caused by it.

Yes, we actually have some doubts from the commit message of "scsi: ufs:
issue link startup 2 times if device isn't active"

If we configured system suspend as device=PowerDown/Link=LinkDown mode,
during resume, the 1st link startup will be successful, and after that
device could be accessed normally so it shall be already in Active power
mode. We did not find devices which need twice linkup for normal work.

And because the 1st linkup is OK, the forced 2nd linkup by commit "scsi:
ufs: issue link startup 2 times if device isn't active" leads to link
lost and finally the 3rd linkup is made again by retry mechanism in
ufshcd_link_startup() and be successful. So a linkup performance issue
is introduced here: We actually need one-time linkup only but finally
got 3 linkup operations.

According to the UFS spec, all reset types (including POR and Host
UniPro Warm Reset which both may happen in above configurations) other
than LU reset, UFS device power mode shall return to Sleep mode or
Active mode depending on bInitPowerMode, by default, it's Active mode.

So we are curious that why enforcing twice linkup is necessary here?
Could you kindly help us clarify this?

If anything wrong in above description, please feel free to correct me.


Hi Stanley,

Above description is correct. The reason why the UFS device becomes
Active after the 1st link startup in your experiment is due to you
set spm_lvl to 5, during system suspend, UFS device is powered down.
When resume kicks start, the UFS device is power cycled once.

Moreover, if you set rpm_lvl to 5, during runtime suspend, if bkops is
enabled, the UFS device will not be powered off, meaning when runtime
resume kicks start, the UFS device is not power cycled, in this case,
we need 3 times of link startup.

Does above explain?

Thanks,

Can Guo.


Hi Stanley,

Sorry, typo before. I meant if set rpm_lvl/spm_lvl to 5, during suspend,
if is_lu_power_on_wp is set, the UFS device will not be fully powered off (only VCC is down), meaning when resume kicks start, the UFS device is not
power cycled, in this case, we need 3 times of link startup.

Regards,

Can Guo.


Happy new year to you too!

Thanks,

Can Guo

Thanks,

Stanley


_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-mediatek



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux