kernel/linux.git/include/ufs, branch master

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: 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: core: Add support to retrain TX Equalization via debugfs

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

Drastic environmental changes, such as significant temperature shifts, can impact link signal integrity. In such cases, retraining TX Equalization is necessary to compensate for these environmental changes. Add a debugfs entry, 'tx_eq_ctrl', to allow userspace to manually trigger the TX Equalization training (EQTR) procedure and apply the identified optimal settings on the fly. These entries are created on a per-gear basis for High Speed Gear 4 (HS-G4) and above, as TX EQTR is not supported for lower gears. The 'tx_eq_ctrl' entry currently accepts the 'retrain' command to initiate the procedure. The interface is designed to be scalable to support additional commands in the future. Reading the 'tx_eq_ctrl' entry provides a usage hint to the user, ensuring the interface is self-documenting. The ufshcd's debugfs folder structure will look like below: /sys/kernel/debug/ufshcd/*ufs*/ |--tx_eq_hs_gear1/ | |--device_tx_eq_params | |--host_tx_eq_params |--tx_eq_hs_gear2/ |--tx_eq_hs_gear3/ |--tx_eq_hs_gear4/ |--tx_eq_hs_gear5/ |--tx_eq_hs_gear6/ |--device_tx_eq_params |--device_tx_eqtr_record |--host_tx_eq_params |--host_tx_eqtr_record |--tx_eq_ctrl 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-8-can.guo@oss.qualcomm.com Signed-off-by: Martin K. Petersen

scsi: ufs: core: Add support for TX Equalization

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

MIPI Unipro3.0 introduced PA_TxEQGnSetting and PA_PreCodeEn attributes for TX Equalization and Pre-Coding. It is Host Software's responsibility to configure these attributes for both host and device before initiating Power Mode Change to High-Speed Gears. MIPI Unipro3.0 also introduced TX Equalization Training (EQTR) to identify optimal TX Equalization settings for use by both Host's and Device's UniPro. TX EQTR shall be initiated from the most reliable High-Speed Gear (HS-G1) targeting High-Speed Gears (HS-G4 to HS-G6). Implement TX Equalization configuration and TX EQTR procedure as defined in UFSHCI v5.0 specification. The TX EQTR procedure determines the optimal TX Equalization settings by iterating through all possible PreShoot and DeEmphasis combinations and selecting the best combinations for both Host and Device based on Figure of Merit (FOM) evaluation. 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-5-can.guo@oss.qualcomm.com Signed-off-by: Martin K. Petersen

scsi: ufs: core: Add UFS_HS_G6 and UFS_HS_GEAR_MAX to enum ufs_hs_gear_tag

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

Add UFS_HS_G6 to enum ufs_hs_gear_tag. In addition, add UFS_HS_GEAR_MAX to enum ufs_hs_gear_tag to facilitate iteration over valid High Speed Gears. 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-4-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: core: Handle MCQ IAG events

2026-03-20T01:37:09+00:00

Add support for handling aggregation-based interrupts when operating in MCQ mode. In legacy interrupt mode, an IE.IAGES is triggered when the counter or timer threshold is reached. To manage this, the handler now resets the aggregation counter and timer by writing to the MCQIACRy.CTR register. Since the register layout of MCQIACRy is identical to the existing UTRIACR register, this implementation reuses the previously defined bitfield masks to maintain consistency and reduce code duplication. Extend ufshcd_handle_mcq_cq_events() with a boolean iag parameter. If set, the handler resets the MCQ IAG counter and timer. Define MCQ_IAG_EVENT_STATUS (0x200000) and include it in UFSHCD_ENABLE_MCQ_INTRS to ensure the interrupt is unmasked during initialization. Signed-off-by: Vamshi Gajjela Reviewed-by: Bart Van Assche Link: https://patch.msgid.link/20260310190308.2474956-1-vamshigajjela@google.com Signed-off-by: Martin K. Petersen

scsi: ufs: core: Add quirks for VCC ramp-up delay

2026-03-11T01:34:59+00:00

On some platforms, the VCC regulator has a slow ramp-up time. Add a delay after enabling VCC to ensure voltage has fully stabilized before we enable the clocks. Reviewed-by: Bart Van Assche Signed-off-by: Ed Tsai Link: https://patch.msgid.link/20260310005230.4001904-4-ed.tsai@mediatek.com Signed-off-by: Martin K. Petersen

scsi: ufs: core: Add support to notify userspace of UniPro QoS events

2026-03-07T16:04:35+00:00

The UniPro stack manages to repair many potential Link problems without the need to notify the Application Layer. Repair mechanisms of the stack include L2 re-transmission and successful handling of PA_INIT.req. Nevertheless, any successful repair sequence requires Link bandwidth that is no longer vailable for the Application. Therefore, it may be useful for an Application to understand how often such repair attempts are made. The DME implements Quality of Service monitoring using a simple counting scheme, counting error events and comparing them against the number of correctly received or transmitted bytes. When the error counter exceeds a programmed threshold before the byte counter overflows, a DME_QoS.ind is issued to the Application and both counters are reset. When the byte counter overflows before the error counter has reached the programmed threshold, both counters are reset without triggering a DME_QoS.ind. The DME provides Link quality monitoring for the following purposes: 1. Detection of re-occurring repaired fatal error conditions on the Link (PA_INIT loop). This kind of detection is useful if capabilities exchanged between local and peer permit a potential operation at a higher M-PHY Gear, but the physical interconnect between local and peer Device does not, or, after Line quality degradation, no longer satisfies channel characteristics. 2. Detection of degraded inbound or outbound Link quality, to allow an Application to issue an ADAPT sequence for a Link running in HS-G4 or higher HS Gears. This kind of detection is used to monitor a slowly degrading Link quality, e.g., one being affected by temperature and voltage variations, against the expected M-PHY bit error rate. Userspace can configure and enable UniPro QoS via UniPro QoS Attributes (via UFS BSG) and get notified by dme_qos_notification without polling UniPro QoS Status attribute. The dme_qos_notification attribute is a bitfield with the following bit assignments: Bit Description === ====================================== 0 DME QoS Monitor has been reset by host 1 QoS from TX is detected 2 QoS from RX is detected 3 QoS from PA_INIT is detected Signed-off-by: Can Guo Reviewed-by: Bart Van Assche Reviewed-by: Peter Wang Link: https://patch.msgid.link/20260305110856.959211-2-can.guo@oss.qualcomm.com Signed-off-by: Martin K. Petersen