| 2a25cbaa | 13-Feb-2025 |
Can Guo <[email protected]> |
scsi: ufs: core: Toggle Write Booster during clock scaling base on gear speed
During clock scaling, Write Booster is toggled on or off based on whether
the clock is scaled up or down. However, with
scsi: ufs: core: Toggle Write Booster during clock scaling base on gear speed
During clock scaling, Write Booster is toggled on or off based on whether
the clock is scaled up or down. However, with OPP V2 powered multi-level
gear scaling, the gear can be scaled amongst multiple gear speeds, e.g., it
may scale down from G5 to G4, or from G4 to G2. To provide flexibilities,
add a new field for clock scaling such that during clock scaling Write
Booster can be enabled or disabled based on gear speeds but not based on
scaling up or down.
Signed-off-by: Can Guo <[email protected]>
Co-developed-by: Ziqi Chen <[email protected]>
Signed-off-by: Ziqi Chen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Bean Huo <[email protected]>
Tested-by: Neil Armstrong <[email protected]>
Reviewed-by: Peter Wang <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
show more ...
|
| d7bead60 | 13-Feb-2025 |
Can Guo <[email protected]> |
scsi: ufs: core: Add a vop to map clock frequency to gear speed
Add a vop to map UFS host controller clock frequencies to the corresponding
maximum supported UFS high speed gear speeds. During clock
scsi: ufs: core: Add a vop to map clock frequency to gear speed
Add a vop to map UFS host controller clock frequencies to the corresponding
maximum supported UFS high speed gear speeds. During clock scaling, we can
map the target clock frequency, demanded by devfreq, to the maximum
supported gear speed, so that devfreq can scale the gear to the highest
gear speed supported at the target clock frequency, instead of just scaling
up/down the gear between the min and max gear speeds.
Co-developed-by: Ziqi Chen <[email protected]>
Signed-off-by: Ziqi Chen <[email protected]>
Signed-off-by: Can Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Bean Huo <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Tested-by: Neil Armstrong <[email protected]>
Reviewed-by: Peter Wang <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
show more ...
|
| 815940bb | 03-Jan-2025 |
Avri Altman <[email protected]> |
scsi: Revert "scsi: ufs: core: Probe for EXT_IID support"
This reverts commit 6e1d850acff9477ae4c18a73c19ef52841ac2010.
Although added a while ago, to date no one make use of ext_iid,
specifically
scsi: Revert "scsi: ufs: core: Probe for EXT_IID support"
This reverts commit 6e1d850acff9477ae4c18a73c19ef52841ac2010.
Although added a while ago, to date no one make use of ext_iid,
specifically incorporates it in the upiu header. Therefore, remove it as
it is currently unused and not serving any purpose.
Signed-off-by: Avri Altman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: Can Guo <[email protected]>
Cc: Asutosh Das <[email protected]>
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
show more ...
|
| 409f2101 | 13-Dec-2024 |
Eric Biggers <[email protected]> |
scsi: ufs: crypto: Remove ufs_hba_variant_ops::program_key
There are no longer any implementations of
ufs_hba_variant_ops::program_key, so remove it.
As a result, ufshcd_program_key() no longer can
scsi: ufs: crypto: Remove ufs_hba_variant_ops::program_key
There are no longer any implementations of
ufs_hba_variant_ops::program_key, so remove it.
As a result, ufshcd_program_key() no longer can return an error, so also
clean it up to return void.
Signed-off-by: Eric Biggers <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
show more ...
|
| 7bac6568 | 19-Dec-2024 |
Manivannan Sadhasivam <[email protected]> |
scsi: ufs: qcom: Power off the PHY if it was already powered on in ufs_qcom_power_up_sequence()
PHY might already be powered on during ufs_qcom_power_up_sequence() in a
couple of cases:
1. During
scsi: ufs: qcom: Power off the PHY if it was already powered on in ufs_qcom_power_up_sequence()
PHY might already be powered on during ufs_qcom_power_up_sequence() in a
couple of cases:
1. During UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH quirk
2. Resuming from spm_lvl = 5 suspend
In those cases, it is necessary to call phy_power_off() and phy_exit() in
ufs_qcom_power_up_sequence() function to power off the PHY before calling
phy_init() and phy_power_on().
Case (1) is doing it via ufs_qcom_reinit_notify() callback, but case (2) is
not handled. So to satisfy both cases, call phy_power_off() and phy_exit()
if the phy_count is non-zero. And with this change, the reinit_notify()
callback is no longer needed.
This fixes the below UFS resume failure with spm_lvl = 5:
ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
ufshcd-qcom 1d84000.ufshc: ufshcd_host_reset_and_restore: Host init failed -5
ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
ufshcd-qcom 1d84000.ufshc: ufshcd_host_reset_and_restore: Host init failed -5
ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
ufshcd-qcom 1d84000.ufshc: ufshcd_host_reset_and_restore: Host init failed -5
ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
ufshcd-qcom 1d84000.ufshc: ufshcd_host_reset_and_restore: Host init failed -5
ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
ufshcd-qcom 1d84000.ufshc: Enabling the controller failed
ufshcd-qcom 1d84000.ufshc: ufshcd_host_reset_and_restore: Host init failed -5
ufs_device_wlun 0:0:0:49488: ufshcd_wl_resume failed: -5
ufs_device_wlun 0:0:0:49488: PM: dpm_run_callback(): scsi_bus_resume returns -5
ufs_device_wlun 0:0:0:49488: PM: failed to resume async: error -5
Cc: [email protected] # 6.3
Fixes: baf5ddac90dc ("scsi: ufs: ufs-qcom: Add support for reinitializing the UFS device")
Reported-by: Ram Kumar Dwivedi <[email protected]>
Tested-by: Amit Pundir <[email protected]> # on SM8550-HDK
Reviewed-by: Bart Van Assche <[email protected]>
Tested-by: Neil Armstrong <[email protected]> # on SM8550-QRD
Signed-off-by: Manivannan Sadhasivam <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
show more ...
|
| be769e5c | 24-Nov-2024 |
Avri Altman <[email protected]> |
scsi: ufs: core: Introduce a new clock_scaling lock
Introduce a new clock scaling lock to serialize access to some of the clock
scaling members instead of the host_lock. here also, simplify the code
scsi: ufs: core: Introduce a new clock_scaling lock
Introduce a new clock scaling lock to serialize access to some of the clock
scaling members instead of the host_lock. here also, simplify the code with
the guard() macro and co.
Reviewed-by: Bart Van Assche <[email protected]>
Signed-off-by: Avri Altman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
show more ...
|
| 2a366460 | 22-Oct-2024 |
Bart Van Assche <[email protected]> |
scsi: ufs: core: Simplify ufshcd_err_handling_prepare()
Use blk_mq_quiesce_tagset() instead of ufshcd_scsi_block_requests() and
blk_mq_wait_quiesce_done(). Since this patch removes the last callers
scsi: ufs: core: Simplify ufshcd_err_handling_prepare()
Use blk_mq_quiesce_tagset() instead of ufshcd_scsi_block_requests() and
blk_mq_wait_quiesce_done(). Since this patch removes the last callers of
ufshcd_scsi_block_requests() and ufshcd_scsi_unblock_requests(), remove
these functions.
Reviewed-by: Avri Altman <[email protected]>
Signed-off-by: Bart Van Assche <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin K. Petersen <[email protected]>
show more ...
|