linux.git/drivers/ufs/host, branch master

scsi: ufs: ufs-qcom: Fix spelling mistake "retore" -> "restore"

2026-04-03T01:15:21+00:00

There is a spelling mistake in a dev_err() message. Fix it.

Signed-off-by: Colin Ian King 
Reviewed-by: Manivannan Sadhasivam 
Link: https://patch.msgid.link/20260331153049.1344957-1-colin.i.king@gmail.com
Signed-off-by: Martin K. Petersen

Merge patch series "scsi: ufs: Add TX Equalization support for UFS 5.0"

2026-03-27T21:21:28+00:00

Can Guo  says:

Hi,

The UFS v5.0 and UFSHCI v5.0 standards have published, introducing support
for HS-G6 (46.6 Gbps per lane) through the new UniPro V3.0 interconnect
layer and M-PHY V6.0 physical layer specifications. To achieve reliable
operation at these higher speeds, UniPro V3.0 introduces TX Equalization
and Pre-Coding mechanisms that are essential for signal integrity.

This patch series implements TX Equalization support in the UFS core
driver as specified in UFSHCI v5.0, along with the necessary vendor
operations and a reference implementation for Qualcomm UFS host
controllers.

Background
==========

TX Equalization is a signal conditioning technique that compensates for
channel impairments at high data rates (HS-G4 through HS-G6). It works
by adjusting two key parameters:

- PreShoot: Pre-emphasis applied before the main signal transition
- DeEmphasis: De-emphasis applied after the main signal transition

UniPro V3.0 defines TX Equalization Training (EQTR) procedure to
automatically discover optimal TX Equalization settings. The EQTR
procedure:

1. Starts from the most reliable link state (HS-G1)
2. Iterates through all possible PreShoot and DeEmphasis combinations
3. Evaluates signal quality using Figure of Merit (FOM) measurements
4. Selects the best settings for both host and device TX lanes

For HS-G6, Pre-Coding is also introduced to further improve signal
quality. Pre-Coding must be enabled on both transmitter and receiver
when the RX_FOM indicates it is required.

Implementation Overview
=======================

The implementation follows the UFSHCI v5.0 specification and consists of:

Core Infrastructure (Patches 1-6):
- New vops callback negotiate_pwr_mode() to allow vendors to negotiate
  power mode parameters before applying TX Equalization settings
- Support for HS-G6 gear enumeration
- Complete TX EQTR procedure implementation in ufs-txeq.c
- Debugfs interface for TX Equalization parameter inspection and manual
  retraining
- Module parameters for adaptive TX Equalization control

Qualcomm Implementation (Patches 7-11):
- PHY-specific configurations for TX EQTR procedure
- Vendor-specific FOM measurement support
- TX Equalization settings application
- Enable TX Equalization for HW version 0x7 and onwards

The implementation is designed to be vendor-agnostic, with platform-
specific details handled through the vops callbacks. Other vendors can
add support by implementing the three new vops:

- tx_eqtr_notify(): Called before/after TX EQTR for vendor setup
- apply_tx_eqtr_settings(): Apply vendor-specific PHY configurations
- get_rx_fom(): Retrieve vendor-specific FOM measurements if needed

Module Parameters
=================

The implementation provides several module parameters for flexibility:

- use_adaptive_txeq: Enable/disable adaptive TX Equalization (default: false)
- adaptive_txeq_gear: Minimum gear for adaptive TX EQ (default: HS-G6)
- use_txeq_presets: Use only the 8 standaird presets (default: false)
- txeq_presets_selected[]: Select specific presets for EQTR

Testing
=======

This patch series has been tested on Qualcomm platforms with UFS 5.0
devices, validating:

- Successful TX EQTR completion for HS-G6
- Proper FOM evaluation and optimal settings selection
- Pre-Coding enablement for HS-G6
- Power mode changes with TX Equalization settings applied
- Report of TX Equalization settings via debugfs entries
- Report of TX EQTR histories via debug entries (see next section)
- Re-training TX Equalization via debugfs entry

Example of TX EQTR history
==========================

Device TX EQTR record summary -
Target Power Mode: HS-G6, Rate-B
Most recent record index: 2
Most recent record timestamp: 219573378 us

TX Lane 0 FOM - PreShoot\DeEmphasis
\       0        1        2        3        4        5        6        7
0      50       70       65        -        -        -        -        x
1       x        x        x        x        x        x        x        x
2     100       90       70        -        -        -        -        x
3       x        x        x        x        x        x        x        x
4      95       90        -        -        -        -        -        x
5       -        -        -        -        -        -        -        x
6       x        x        x        x        x        x        x        x
7       x        x        x        x        x        x        x        x

TX Lane 1 FOM - PreShoot\DeEmphasis
\       0        1        2        3        4        5        6        7
0      50       70       60        -        -        -        -        x
1       x        x        x        x        x        x        x        x
2     100       80       65        -        -        -        -        x
3       x        x        x        x        x        x        x        x
4      95       85        -        -        -        -        -        x
5       -        -        -        -        -        -        -        x
6       x        x        x        x        x        x        x        x
7       x        x        x        x        x        x        x        x

Patch Structure
===============

Patches 1-3: Preparatory changes for power mode negotiation and HS-G6
Patch 4: Core TX Equalization and EQTR implementation
Patches 5-7: Debugfs support for TX Equalization
Patches 8-12: Qualcomm vendor implementation

Next
====

One more series has been developed to enhance TX Equalization support,
which will be submitted for review after this series is accepted:

- Provide board specific (static) TX Equalization settings from DTS
- Parse static TX Equalization settings from DTS if provided
- Apply static TX Equalization settings if use_adaptive_txeq is disabled
- Add support for UFS v5.0 attributes qTxEQGnSettings & wTxEQGnSettingsExt
- Enable persistent storage and retrieval of optimal TX Equalization settings

Link: https://patch.msgid.link/20260325152154.1604082-1-can.guo@oss.qualcomm.com
Signed-off-by: Martin K. Petersen

scsi: ufs: ufs-qcom: Enable TX Equalization

2026-03-27T21:20:30+00:00

Enable TX Equalization for hosts with HW version 0x7 and onwards.

Reviewed-by: Bean Huo 
Reviewed-by: Bart Van Assche 
Signed-off-by: Can Guo 
Reviewed-by: Peter Wang 
Link: https://patch.msgid.link/20260325152154.1604082-13-can.guo@oss.qualcomm.com
Signed-off-by: Martin K. Petersen

scsi: ufs: ufs-qcom: Implement vops apply_tx_eqtr_settings()

2026-03-27T21:20:30+00:00

On some platforms, when Host Software triggers TX Equalization Training, HW
does not take TX EQTR settings programmed in PA_TxEQTRSetting, instead HW
takes TX EQTR settings from PA_TxEQG1Setting. Implement vops
apply_tx_eqtr_setting() to work around it by programming TX EQTR settings
to PA_TxEQG1Setting during TX EQTR procedure.

Reviewed-by: Bean Huo 
Reviewed-by: Bart Van Assche 
Signed-off-by: Can Guo 
Reviewed-by: Peter Wang 
Link: https://patch.msgid.link/20260325152154.1604082-12-can.guo@oss.qualcomm.com
Signed-off-by: Martin K. Petersen

scsi: ufs: ufs-qcom: Implement vops get_rx_fom()

2026-03-27T21:20:30+00:00

On some platforms, host's M-PHY RX_FOM Attribute always reads 0, meaning SW
cannot rely on Figure of Merit (FOM) to identify the optimal TX
Equalization settings for device's TX Lanes. Implement the vops
ufs_qcom_get_rx_fom() such that SW can utilize the UFS Eye Opening Monitor
(EOM) to evaluate the TX Equalization settings for device's TX Lanes.

Reviewed-by: Bean Huo 
Reviewed-by: Bart Van Assche 
Signed-off-by: Can Guo 
Reviewed-by: Peter Wang 
Link: https://patch.msgid.link/20260325152154.1604082-11-can.guo@oss.qualcomm.com
Signed-off-by: Martin K. Petersen

scsi: ufs: ufs-qcom: Implement vops tx_eqtr_notify()

2026-03-27T21:20:30+00:00

On some platforms, HW does not support triggering TX EQTR from the most
reliable High-Speed (HS) Gear (HS Gear1), but only allows to trigger TX
EQTR for the target HS Gear from the same HS Gear. To work around the HW
limitation, implement vops tx_eqtr_notify() to change Power Mode to the
target TX EQTR HS Gear prior to TX EQTR procedure and change Power Mode
back to HS Gear1 (the most reliable gear) post TX EQTR procedure.

Reviewed-by: Bean Huo 
Reviewed-by: Bart Van Assche 
Signed-off-by: Can Guo 
Reviewed-by: Peter Wang 
Link: https://patch.msgid.link/20260325152154.1604082-10-can.guo@oss.qualcomm.com
Signed-off-by: Martin K. Petersen

scsi: ufs: ufs-qcom: Fixup PAM-4 TX L0_L1_L2_L3 adaptation pattern length

2026-03-27T21:20:30+00:00

If HS-G6 Power Mode change handshake is successful and outbound data Lanes
are expected to transmit ADAPT, M-TX Lanes shall be configured as

  if (Adapt Type == REFRESH)
    TX_HS_ADAPT_LENGTH_L0_L1_L2_L3 = PA_PeerRxHsG6AdaptRefreshL0L1L2L3.
  else if (Adapt Type == INITIAL)
    TX_HS_ADAPT_LENGTH_L0_L1_L2_L3 = PA_PeerRxHsG6AdaptInitialL0L1L2L3.

On some platforms, the ADAPT_L0_L1_L2_L3 duration on Host TX Lanes is only
a half of theoretical ADAPT_L0_L1_L2_L3 duration TADAPT_L0_L1_L2_L3 (in
PAM-4 UI) calculated from TX_HS_ADAPT_LENGTH_L0_L1_L2_L3.

For such platforms, the workaround is to double the ADAPT_L0_L1_L2_L3
duration by uplifting TX_HS_ADAPT_LENGTH_L0_L1_L2_L3. UniPro initializes
TX_HS_ADAPT_LENGTH_L0_L1_L2_L3 during HS-G6 Power Mode change handshake, it
would be too late for SW to update TX_HS_ADAPT_LENGTH_L0_L1_L2_L3 post
HS-G6 Power Mode change. Update PA_PeerRxHsG6AdaptRefreshL0L1L2L3 and
PA_PeerRxHsG6AdaptInitialL0L1L2L3 post Link Startup and before HS-G6 Power
Mode change, so that the UniPro would use the updated value during HS-G6
Power Mode change handshake.

Reviewed-by: Bean Huo 
Reviewed-by: Bart Van Assche 
Signed-off-by: Can Guo 
Reviewed-by: Peter Wang 
Link: https://patch.msgid.link/20260325152154.1604082-9-can.guo@oss.qualcomm.com
Signed-off-by: Martin K. Petersen

scsi: ufs: core: Pass force_pmc to ufshcd_config_pwr_mode() as a parameter

2026-03-27T21:20:29+00:00

Currently, callers must manually toggle hba->force_pmc before and after
calling ufshcd_config_pwr_mode() to force a Power Mode change. Introduce
enum ufshcd_pmc_policy and refactor ufshcd_config_pwr_mode() to accept
pmc_policy as a parameter to force a Power Mode change.

Reviewed-by: Bart Van Assche 
Reviewed-by: Bean Huo 
Signed-off-by: Can Guo 
Reviewed-by: Peter Wang 
Link: https://patch.msgid.link/20260325152154.1604082-3-can.guo@oss.qualcomm.com
Signed-off-by: Martin K. Petersen

scsi: ufs: core: Introduce a new ufshcd vops negotiate_pwr_mode()

2026-03-27T21:20:29+00:00

Most vendor specific implemenations of vops pwr_change_notify(PRE_CHANGE)
are fulfilling two things at once:

 - Vendor specific target power mode negotiation

 - Vendor specific power mode change preparation

When TX Equalization is added into consideration, before power mode change
to a target power mode, TX Equalization Training (EQTR) needs be done for
that target power mode. In addition, UFSHCI spec requires to start TX EQTR
from HS-G1 (the most reliable High Speed Gear).

Adding TX EQTR before pwr_change_notify(PRE_CHANGE) is not applicable
because we don't know the negotiated power mode yet.

Adding TX EQTR post pwr_change_notify(PRE_CHANGE) is inappropriate because
pwr_change_notify(PRE_CHANGE) has finished preparation for a power mode
change to negotiated power mode, yet we are changing power mode to HS-G1
for TX EQTR.

Add a new vops negotiate_pwr_mode() so that vendor specific power mode
negotiation can be fulfilled in its vendor specific implementations.  Later
on, TX EQTR can be added post vops negotiate_pwr_mode() and before vops
pwr_change_notify(PRE_CHANGE).

Reviewed-by: Bean Huo 
Reviewed-by: Bart Van Assche 
Signed-off-by: Can Guo 
Reviewed-by: Peter Wang 
Link: https://patch.msgid.link/20260325152154.1604082-2-can.guo@oss.qualcomm.com
Signed-off-by: Martin K. Petersen

scsi: ufs: rockchip: Drop unused include

2026-03-27T20:26:57+00:00

This driver includes the legacy header  but does not use
any symbols from it. Drop the inclusion.

Signed-off-by: Andy Shevchenko 
Reviewed-by: Bart Van Assche 
Reviewed-by: Shawn Lin 
Link: https://patch.msgid.link/20260320215606.3236516-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Martin K. Petersen