[0/6] Enable HS-G5 support on SM8550

Message ID	1694411968-14413-1-git-send-email-quic_cang@quicinc.com
Headers	show Return-Path: <linux-scsi-owner@vger.kernel.org> From: Can Guo <quic_cang@quicinc.com> To: quic_cang@quicinc.com, mani@kernel.org, quic_nguyenb@quicinc.com, quic_nitirawa@quicinc.com, martin.petersen@oracle.com Cc: linux-scsi@vger.kernel.org Subject: [PATCH 0/6] Enable HS-G5 support on SM8550 Date: Sun, 10 Sep 2023 22:59:21 -0700 Message-Id: <1694411968-14413-1-git-send-email-quic_cang@quicinc.com> Precedence: bulk
Series	Enable HS-G5 support on SM8550 \| expand [0/6] Enable HS-G5 support on SM8550 [4/6] phy: qualcomm: phy-qcom-qmp-ufs: Move data structs and setting tables to header [6/6] scsi: ufs: ufs-sysfs: Introduce UFS power info sysfs nodes

Can Guo Sept. 11, 2023, 5:59 a.m. UTC

This series enables HS-G5 support on SM8550.

This series is rebased on below changes from Mani -
https://patchwork.kernel.org/project/linux-scsi/patch/20230908145329.154024-1-manivannan.sadhasivam@linaro.org/
https://patchwork.kernel.org/project/linux-scsi/patch/20230908145329.154024-2-manivannan.sadhasivam@linaro.org/

This series is tested on below HW combinations -
SM8550 MTP + UFS4.0
SM8550 QRD + UFS3.1
SM8450 MTP + UFS3.1 (for regression test) 


Bao D. Nguyen (1):
  scsi: ufs: ufs-qcom: Add support for UFS device version detection

Can Guo (5):
  scsi: ufs: ufs-qcom: Setup host power mode during init
  phy: qualcomm: phy-qcom-qmp-ufs: Add High Speed Gear 5 support for
    SM8550
  phy: qualcomm: phy-qcom-qmp-ufs: Move data structs and setting tables
    to header
  scsi: ufs: ufs-sysfs: Expose UFS power info
  scsi: ufs: ufs-sysfs: Introduce UFS power info sysfs nodes

 Documentation/ABI/testing/sysfs-driver-ufs         |  48 +-
 drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h     |   2 +
 drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h |   2 +
 .../qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h    |  12 +
 drivers/phy/qualcomm/phy-qcom-qmp-ufs.c            | 782 +-------------------
 drivers/phy/qualcomm/phy-qcom-qmp-ufs.h            | 805 +++++++++++++++++++++
 drivers/ufs/core/ufs-sysfs.c                       |  71 ++
 drivers/ufs/host/ufs-qcom.c                        |  57 +-
 drivers/ufs/host/ufs-qcom.h                        |   3 +
 9 files changed, 1013 insertions(+), 769 deletions(-)
 create mode 100644 drivers/phy/qualcomm/phy-qcom-qmp-ufs.h

Nitin Rawat Sept. 14, 2023, 11:33 a.m. UTC | #1

On 9/11/2023 11:29 AM, Can Guo wrote:
> Having UFS power info available in sysfs makes it easier to tell the state
> of the link during runtime considering we have a bounch of power saving
> features and various combinations for backward compatiblity.

Please fix spelling mistake - *bounch -> bunch


> 
> Signed-off-by: Can Guo <quic_cang@quicinc.com>
> ---
>   drivers/ufs/core/ufs-sysfs.c | 71 ++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 71 insertions(+)
> 
> diff --git a/drivers/ufs/core/ufs-sysfs.c b/drivers/ufs/core/ufs-sysfs.c
> index c959064..53af490 100644
> --- a/drivers/ufs/core/ufs-sysfs.c
> +++ b/drivers/ufs/core/ufs-sysfs.c
> @@ -628,6 +628,76 @@ static const struct attribute_group ufs_sysfs_monitor_group = {
>   	.attrs = ufs_sysfs_monitor_attrs,
>   };
>   
> +static ssize_t gear_show(struct device *dev, struct device_attribute *attr,
> +			 char *buf)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	return sysfs_emit(buf, "%u\n", hba->pwr_info.gear_rx);
> +}
> +
> +static ssize_t lane_show(struct device *dev, struct device_attribute *attr,
> +			 char *buf)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	return sysfs_emit(buf, "%u\n", hba->pwr_info.lane_rx);
> +}
> +
> +static ssize_t mode_show(struct device *dev, struct device_attribute *attr,
> +			 char *buf)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	return sysfs_emit(buf, "%u\n", hba->pwr_info.pwr_rx);
> +}
> +
> +static ssize_t rate_show(struct device *dev, struct device_attribute *attr,
> +			 char *buf)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	return sysfs_emit(buf, "%u\n", hba->pwr_info.hs_rate);
> +}
> +
> +static ssize_t dev_pm_show(struct device *dev, struct device_attribute *attr,
> +			   char *buf)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	return sysfs_emit(buf, "%d\n", hba->curr_dev_pwr_mode);
> +}
> +
> +static ssize_t link_state_show(struct device *dev,
> +			       struct device_attribute *attr, char *buf)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	return sysfs_emit(buf, "%d\n", hba->uic_link_state);
> +}
> +
> +static DEVICE_ATTR_RO(gear);
> +static DEVICE_ATTR_RO(lane);
> +static DEVICE_ATTR_RO(mode);
> +static DEVICE_ATTR_RO(rate);
> +static DEVICE_ATTR_RO(dev_pm);
> +static DEVICE_ATTR_RO(link_state);
> +
> +static struct attribute *ufs_power_info_attrs[] = {
> +	&dev_attr_gear.attr,
> +	&dev_attr_lane.attr,
> +	&dev_attr_mode.attr,
> +	&dev_attr_rate.attr,
> +	&dev_attr_dev_pm.attr,
> +	&dev_attr_link_state.attr,
> +	NULL
> +};
> +
> +static const struct attribute_group ufs_sysfs_power_info_group = {
> +	.name = "power_info",
> +	.attrs = ufs_power_info_attrs,
> +};
> +
>   static ssize_t ufs_sysfs_read_desc_param(struct ufs_hba *hba,
>   				  enum desc_idn desc_id,
>   				  u8 desc_index,
> @@ -1233,6 +1303,7 @@ static const struct attribute_group *ufs_sysfs_groups[] = {
>   	&ufs_sysfs_default_group,
>   	&ufs_sysfs_capabilities_group,
>   	&ufs_sysfs_monitor_group,
> +	&ufs_sysfs_power_info_group,
>   	&ufs_sysfs_device_descriptor_group,
>   	&ufs_sysfs_interconnect_descriptor_group,
>   	&ufs_sysfs_geometry_descriptor_group,


How about having one power mode attribute displaying all useful info 
(lane, gear, mode, rate).

Regards,
Nitin Rawat

Nitin Rawat Sept. 14, 2023, 12:26 p.m. UTC | #2

On 9/11/2023 11:29 AM, Can Guo wrote:
> Split High Speed Gear 4 PHY settings from common tables, and add PHY
> settings to support High Speed Gear 5.
> 

Hi Can,

Can you please add more details explaining the change. We can mention 
that are we spliting serdes setting for g3 and g4.

Also how about having 2 patches, one for splitting serdes configuration 
b/w gear3 and gear4 and other patch about new g5 setting.

-Nitin

> Signed-off-by: Can Guo <quic_cang@quicinc.com>
> ---
>   drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h     |   2 +
>   drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h |   2 +
>   .../qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h    |  12 +++
>   drivers/phy/qualcomm/phy-qcom-qmp-ufs.c            | 112 ++++++++++++++++++---
>   4 files changed, 115 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h
> index c23d5e4..e563af5 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h
> @@ -18,6 +18,7 @@
>   #define QPHY_V6_PCS_UFS_BIST_FIXED_PAT_CTRL		0x060
>   #define QPHY_V6_PCS_UFS_TX_HSGEAR_CAPABILITY		0x074
>   #define QPHY_V6_PCS_UFS_RX_HSGEAR_CAPABILITY		0x0bc
> +#define QPHY_V6_PCS_UFS_RX_HS_G5_SYNC_LENGTH_CAPABILITY	0x12c
>   #define QPHY_V6_PCS_UFS_DEBUG_BUS_CLKSEL		0x158
>   #define QPHY_V6_PCS_UFS_LINECFG_DISABLE			0x17c
>   #define QPHY_V6_PCS_UFS_RX_MIN_HIBERN8_TIME		0x184
> @@ -27,5 +28,6 @@
>   #define QPHY_V6_PCS_UFS_READY_STATUS			0x1a8
>   #define QPHY_V6_PCS_UFS_TX_MID_TERM_CTRL1		0x1f4
>   #define QPHY_V6_PCS_UFS_MULTI_LANE_CTRL1		0x1fc
> +#define QPHY_V6_PCS_UFS_RX_HSG5_SYNC_WAIT_TIME		0x220
>   
>   #endif
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h
> index f420f8f..ef392ce 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h
> @@ -56,6 +56,8 @@
>   #define QSERDES_V6_COM_SYS_CLK_CTRL				0xe4
>   #define QSERDES_V6_COM_SYSCLK_BUF_ENABLE			0xe8
>   #define QSERDES_V6_COM_PLL_IVCO					0xf4
> +#define QSERDES_V6_COM_CMN_IETRIM				0xfc
> +#define QSERDES_V6_COM_CMN_IPTRIM				0x100
>   #define QSERDES_V6_COM_SYSCLK_EN_SEL				0x110
>   #define QSERDES_V6_COM_RESETSM_CNTRL				0x118
>   #define QSERDES_V6_COM_LOCK_CMP_EN				0x120
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h
> index 15bcb4b..48f31c8 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h
> @@ -10,10 +10,20 @@
>   #define QSERDES_UFS_V6_TX_RES_CODE_LANE_RX			0x2c
>   #define QSERDES_UFS_V6_TX_RES_CODE_LANE_OFFSET_TX		0x30
>   #define QSERDES_UFS_V6_TX_RES_CODE_LANE_OFFSET_RX		0x34
> +#define QSERDES_UFS_V6_TX_LANE_MODE_1				0x7c
> +#define QSERDES_UFS_V6_TX_FR_DCC_CTRL				0x108
>   
>   #define QSERDES_UFS_V6_RX_UCDR_FASTLOCK_FO_GAIN_RATE2		0x08
>   #define QSERDES_UFS_V6_RX_UCDR_FASTLOCK_FO_GAIN_RATE4		0x10
> +#define QSERDES_UFS_V6_RX_UCDR_FASTLOCK_SO_GAIN_RATE4		0x24
> +#define QSERDES_UFS_V6_RX_UCDR_FASTLOCK_COUNT_HIGH_RATE4	0x54
> +#define QSERDES_UFS_V6_RX_UCDR_FO_GAIN_RATE2			0xd4
> +#define QSERDES_UFS_V6_RX_UCDR_FO_GAIN_RATE4			0xdc
> +#define QSERDES_UFS_V6_RX_UCDR_SO_GAIN_RATE4			0xf0
> +#define QSERDES_UFS_V6_RX_UCDR_PI_CONTROLS			0xf4
>   #define QSERDES_UFS_V6_RX_VGA_CAL_MAN_VAL			0x178
> +#define QSERDES_UFS_V6_RX_EQ_OFFSET_ADAPTOR_CNTRL1		0x1bc
> +#define QSERDES_UFS_V6_RX_OFFSET_ADAPTOR_CNTRL3			0x1c4
>   #define QSERDES_UFS_V6_RX_MODE_RATE_0_1_B0			0x208
>   #define QSERDES_UFS_V6_RX_MODE_RATE_0_1_B1			0x20c
>   #define QSERDES_UFS_V6_RX_MODE_RATE_0_1_B3			0x214
> @@ -25,6 +35,8 @@
>   #define QSERDES_UFS_V6_RX_MODE_RATE3_B5				0x264
>   #define QSERDES_UFS_V6_RX_MODE_RATE3_B8				0x270
>   #define QSERDES_UFS_V6_RX_MODE_RATE4_B3				0x280
> +#define QSERDES_UFS_V6_RX_MODE_RATE4_B4				0x284
>   #define QSERDES_UFS_V6_RX_MODE_RATE4_B6				0x28c
> +#define QSERDES_UFS_V6_RX_DLL0_FTUNE_CTRL			0x2f8
>   
>   #endif
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> index 8c877b6..d0ecacf 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> @@ -650,32 +650,51 @@ static const struct qmp_phy_init_tbl sm8550_ufsphy_serdes[] = {
>   	QMP_PHY_INIT_CFG(QSERDES_V6_COM_HSCLK_SEL_1, 0x11),
>   	QMP_PHY_INIT_CFG(QSERDES_V6_COM_HSCLK_HS_SWITCH_SEL_1, 0x00),
>   	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP_EN, 0x01),
> -	QMP_PHY_INIT_CFG(QSERDES_V6_COM_VCO_TUNE_MAP, 0x04),
> -	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_IVCO, 0x0f),
> +
>   	QMP_PHY_INIT_CFG(QSERDES_V6_COM_VCO_TUNE_INITVAL2, 0x00),
>   	QMP_PHY_INIT_CFG(QSERDES_V6_COM_DEC_START_MODE0, 0x41),
> -	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE0, 0x0a),
>   	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_RCTRL_MODE0, 0x18),
>   	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_CCTRL_MODE0, 0x14),
>   	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP1_MODE0, 0x7f),
>   	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP2_MODE0, 0x06),
> -	QMP_PHY_INIT_CFG(QSERDES_V6_COM_DEC_START_MODE0, 0x4c),
> +};
> +
> +static const struct qmp_phy_init_tbl sm8550_ufsphy_hs_b_serdes[] = {
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_VCO_TUNE_MAP, 0x44),
> +};
> +
> +static const struct qmp_phy_init_tbl sm8550_ufsphy_g4_serdes[] = {
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_VCO_TUNE_MAP, 0x04),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_IVCO, 0x0f),
>   	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE0, 0x0a),
> -	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_RCTRL_MODE0, 0x18),
> -	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_CCTRL_MODE0, 0x14),
> -	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP1_MODE0, 0x99),
> -	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP2_MODE0, 0x07),
> +
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_DEC_START_MODE1, 0x4c),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE1, 0x0a),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_RCTRL_MODE1, 0x18),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_CCTRL_MODE1, 0x14),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP1_MODE1, 0x99),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP2_MODE1, 0x07),
> +};
> +
> +static const struct qmp_phy_init_tbl sm8550_ufsphy_g5_serdes[] = {
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_IVCO, 0x1f),
> +
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CMN_IETRIM, 0x1b),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CMN_IPTRIM, 0x1c),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE0, 0x06),
>   };
>   
>   static const struct qmp_phy_init_tbl sm8550_ufsphy_tx[] = {
> -	QMP_PHY_INIT_CFG(QSERDES_V6_TX_LANE_MODE_1, 0x05),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_TX_LANE_MODE_1, 0x05),
>   	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_TX_RES_CODE_LANE_OFFSET_TX, 0x07),
>   };
>   
> +static const struct qmp_phy_init_tbl sm8550_ufsphy_g4_tx[] = {
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_TX_FR_DCC_CTRL, 0x4c),
> +};
> +
>   static const struct qmp_phy_init_tbl sm8550_ufsphy_rx[] = {
> -	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_FASTLOCK_FO_GAIN_RATE2, 0x0c),
> -	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_FASTLOCK_FO_GAIN_RATE4, 0x0f),
> -	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_VGA_CAL_MAN_VAL, 0x0e),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_FO_GAIN_RATE2, 0x0c),
>   
>   	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_MODE_RATE_0_1_B0, 0xc2),
>   	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_MODE_RATE_0_1_B1, 0xc2),
> @@ -691,14 +710,46 @@ static const struct qmp_phy_init_tbl sm8550_ufsphy_rx[] = {
>   	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_MODE_RATE3_B8, 0x02),
>   };
>   
> +static const struct qmp_phy_init_tbl sm8550_ufsphy_g4_rx[] = {
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_VGA_CAL_MAN_VAL, 0x0e),
> +};
> +
> +static const struct qmp_phy_init_tbl sm8550_ufsphy_g5_rx[] = {
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_FO_GAIN_RATE4, 0x0c),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_SO_GAIN_RATE4, 0x04),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_EQ_OFFSET_ADAPTOR_CNTRL1, 0x14),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_PI_CONTROLS, 0x07),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_OFFSET_ADAPTOR_CNTRL3, 0x0e),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_FASTLOCK_COUNT_HIGH_RATE4, 0x02),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_FASTLOCK_FO_GAIN_RATE4, 0x1c),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_FASTLOCK_SO_GAIN_RATE4, 0x06),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_VGA_CAL_MAN_VAL, 0x08),
> +
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_MODE_RATE4_B3, 0xb9),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_MODE_RATE4_B4, 0x4f),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_MODE_RATE4_B6, 0xff),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_DLL0_FTUNE_CTRL, 0x30),
> +};
> +
>   static const struct qmp_phy_init_tbl sm8550_ufsphy_pcs[] = {
>   	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_RX_SIGDET_CTRL2, 0x69),
>   	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_TX_LARGE_AMP_DRV_LVL, 0x0f),
>   	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_TX_MID_TERM_CTRL1, 0x43),
> -	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_PLL_CNTL, 0x2b),
>   	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_MULTI_LANE_CTRL1, 0x02),
>   };
>   
> +static const struct qmp_phy_init_tbl sm8550_ufsphy_g4_pcs[] = {
> +	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_PLL_CNTL, 0x2b),
> +	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_TX_HSGEAR_CAPABILITY, 0x04),
> +	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_RX_HSGEAR_CAPABILITY, 0x04),
> +};
> +
> +static const struct qmp_phy_init_tbl sm8550_ufsphy_g5_pcs[] = {
> +	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_PLL_CNTL, 0x33),
> +	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_RX_HS_G5_SYNC_LENGTH_CAPABILITY, 0x4f),
> +	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_RX_HSG5_SYNC_WAIT_TIME, 0x9e),
> +};
> +
>   struct qmp_ufs_offsets {
>   	u16 serdes;
>   	u16 pcs;
> @@ -732,6 +783,8 @@ struct qmp_phy_cfg {
>   	const struct qmp_phy_cfg_tbls tbls_hs_b;
>   	/* Additional sequence for HS G4 */
>   	const struct qmp_phy_cfg_tbls tbls_hs_g4;
> +	/* Additional sequence for HS G4 */
> +	const struct qmp_phy_cfg_tbls tbls_hs_g5;
>   
>   	/* clock ids to be requested */
>   	const char * const *clk_list;
> @@ -1146,6 +1199,28 @@ static const struct qmp_phy_cfg sm8550_ufsphy_cfg = {
>   		.pcs		= sm8550_ufsphy_pcs,
>   		.pcs_num	= ARRAY_SIZE(sm8550_ufsphy_pcs),
>   	},
> +	.tbls_hs_b = {
> +		.serdes		= sm8550_ufsphy_hs_b_serdes,
> +		.serdes_num	= ARRAY_SIZE(sm8550_ufsphy_hs_b_serdes),
> +	},
> +	.tbls_hs_g4 = {
> +		.serdes		= sm8550_ufsphy_g4_serdes,
> +		.serdes_num	= ARRAY_SIZE(sm8550_ufsphy_g4_serdes),
> +		.tx		= sm8550_ufsphy_g4_tx,
> +		.tx_num		= ARRAY_SIZE(sm8550_ufsphy_g4_tx),
> +		.rx		= sm8550_ufsphy_g4_rx,
> +		.rx_num		= ARRAY_SIZE(sm8550_ufsphy_g4_rx),
> +		.pcs		= sm8550_ufsphy_g4_pcs,
> +		.pcs_num	= ARRAY_SIZE(sm8550_ufsphy_g4_pcs),
> +	},
> +	.tbls_hs_g5 = {
> +		.serdes		= sm8550_ufsphy_g5_serdes,
> +		.serdes_num	= ARRAY_SIZE(sm8550_ufsphy_g5_serdes),
> +		.rx		= sm8550_ufsphy_g5_rx,
> +		.rx_num		= ARRAY_SIZE(sm8550_ufsphy_g5_rx),
> +		.pcs		= sm8550_ufsphy_g5_pcs,
> +		.pcs_num	= ARRAY_SIZE(sm8550_ufsphy_g5_pcs),
> +	},
>   	.clk_list		= sdm845_ufs_phy_clk_l,
>   	.num_clks		= ARRAY_SIZE(sdm845_ufs_phy_clk_l),
>   	.vreg_list		= qmp_phy_vreg_l,
> @@ -1211,14 +1286,25 @@ static void qmp_ufs_pcs_init(struct qmp_ufs *qmp, const struct qmp_phy_cfg_tbls
>   static void qmp_ufs_init_registers(struct qmp_ufs *qmp, const struct qmp_phy_cfg *cfg)
>   {
>   	qmp_ufs_serdes_init(qmp, &cfg->tbls);
> +	if (qmp->submode == UFS_HS_G4)
> +		qmp_ufs_serdes_init(qmp, &cfg->tbls_hs_g4);
> +	else if (qmp->submode == UFS_HS_G5)
> +		qmp_ufs_serdes_init(qmp, &cfg->tbls_hs_g5);
> +
>   	if (qmp->mode == PHY_MODE_UFS_HS_B)
>   		qmp_ufs_serdes_init(qmp, &cfg->tbls_hs_b);
> +
>   	qmp_ufs_lanes_init(qmp, &cfg->tbls);
>   	if (qmp->submode == UFS_HS_G4)
>   		qmp_ufs_lanes_init(qmp, &cfg->tbls_hs_g4);
> +	else if (qmp->submode == UFS_HS_G5)
> +		qmp_ufs_lanes_init(qmp, &cfg->tbls_hs_g5);
> +
>   	qmp_ufs_pcs_init(qmp, &cfg->tbls);
>   	if (qmp->submode == UFS_HS_G4)
>   		qmp_ufs_pcs_init(qmp, &cfg->tbls_hs_g4);
> +	else if (qmp->submode == UFS_HS_G5)
> +		qmp_ufs_pcs_init(qmp, &cfg->tbls_hs_g5);
>   }
>   
>   static int qmp_ufs_com_init(struct qmp_ufs *qmp)

Nitin Rawat Sept. 14, 2023, 12:40 p.m. UTC | #3

On 9/11/2023 11:29 AM, Can Guo wrote:
> Setup host power mode and its limitations during UFS host driver init to
> avoid repetitive work during every power mode change.
> 
> Co-developed-by: Bao D. Nguyen <quic_nguyenb@quicinc.com>
> Signed-off-by: Can Guo <quic_cang@quicinc.com>
> Signed-off-by: Bao D. Nguyen <quic_nguyenb@quicinc.com>

Hi Can,

Patch looks good. Please can you just change the order of Signed-off-by.
I think it should be like below:

Co-developed-by: Bao D. Nguyen <quic_nguyenb@quicinc.com>
Signed-off-by: Bao D. Nguyen <quic_nguyenb@quicinc.com>
Signed-off-by: Can Guo <quic_cang@quicinc.com>

--Nitin

> ---
>   drivers/ufs/host/ufs-qcom.c | 27 ++++++++++++++++++---------
>   drivers/ufs/host/ufs-qcom.h |  1 +
>   2 files changed, 19 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> index c3215d3..710f079 100644
> --- a/drivers/ufs/host/ufs-qcom.c
> +++ b/drivers/ufs/host/ufs-qcom.c
> @@ -443,7 +443,11 @@ static u32 ufs_qcom_get_hs_gear(struct ufs_hba *hba)
>   static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
>   {
>   	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
> +	struct ufs_dev_params *host_pwr_cap = &host->host_pwr_cap;
>   	struct phy *phy = host->generic_phy;
> +	enum phy_mode mode = host_pwr_cap->hs_rate == PA_HS_MODE_B ?
> +							PHY_MODE_UFS_HS_B :
> +							PHY_MODE_UFS_HS_A;
>   	int ret;
>   
>   	/* Reset UFS Host Controller and PHY */
> @@ -460,7 +464,7 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
>   		return ret;
>   	}
>   
> -	phy_set_mode_ext(phy, PHY_MODE_UFS_HS_B, host->phy_gear);
> +	phy_set_mode_ext(phy, mode, host->phy_gear);
>   
>   	/* power on phy - start serdes and phy's power and clocks */
>   	ret = phy_power_on(phy);
> @@ -884,7 +888,6 @@ static int ufs_qcom_pwr_change_notify(struct ufs_hba *hba,
>   				struct ufs_pa_layer_attr *dev_req_params)
>   {
>   	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
> -	struct ufs_dev_params ufs_qcom_cap;
>   	int ret = 0;
>   
>   	if (!dev_req_params) {
> @@ -894,13 +897,7 @@ static int ufs_qcom_pwr_change_notify(struct ufs_hba *hba,
>   
>   	switch (status) {
>   	case PRE_CHANGE:
> -		ufshcd_init_pwr_dev_param(&ufs_qcom_cap);
> -		ufs_qcom_cap.hs_rate = UFS_QCOM_LIMIT_HS_RATE;
> -
> -		/* This driver only supports symmetic gear setting i.e., hs_tx_gear == hs_rx_gear */
> -		ufs_qcom_cap.hs_tx_gear = ufs_qcom_cap.hs_rx_gear = ufs_qcom_get_hs_gear(hba);
> -
> -		ret = ufshcd_get_pwr_dev_param(&ufs_qcom_cap,
> +		ret = ufshcd_get_pwr_dev_param(&host->host_pwr_cap,
>   					       dev_max_params,
>   					       dev_req_params);
>   		if (ret) {
> @@ -1037,6 +1034,17 @@ static void ufs_qcom_advertise_quirks(struct ufs_hba *hba)
>   		hba->quirks |= UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH;
>   }
>   
> +static void ufs_qcom_set_pwr_mode_limits(struct ufs_hba *hba)
> +{
> +	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
> +	struct ufs_dev_params *host_pwr_cap = &host->host_pwr_cap;
> +
> +	ufshcd_init_pwr_dev_param(host_pwr_cap);
> +
> +	/* This driver only supports symmetic gear setting i.e., hs_tx_gear == hs_rx_gear */
> +	host_pwr_cap->hs_tx_gear = host_pwr_cap->hs_rx_gear = ufs_qcom_get_hs_gear(hba);
> +}
> +
>   static void ufs_qcom_set_caps(struct ufs_hba *hba)
>   {
>   	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
> @@ -1259,6 +1267,7 @@ static int ufs_qcom_init(struct ufs_hba *hba)
>   	if (err)
>   		goto out_variant_clear;
>   
> +	ufs_qcom_set_pwr_mode_limits(hba);
>   	ufs_qcom_set_caps(hba);
>   	ufs_qcom_advertise_quirks(hba);
>   
> diff --git a/drivers/ufs/host/ufs-qcom.h b/drivers/ufs/host/ufs-qcom.h
> index fa54248..4db64d9 100644
> --- a/drivers/ufs/host/ufs-qcom.h
> +++ b/drivers/ufs/host/ufs-qcom.h
> @@ -227,6 +227,7 @@ struct ufs_qcom_host {
>   
>   	struct gpio_desc *device_reset;
>   
> +	struct ufs_dev_params host_pwr_cap;
>   	u32 phy_gear;
>   
>   	bool esi_enabled;

Can Guo Sept. 15, 2023, 1:59 a.m. UTC | #4

Hi Nitin,

On 9/14/2023 7:33 PM, Nitin Rawat wrote:
>
>
> On 9/11/2023 11:29 AM, Can Guo wrote:
>> Having UFS power info available in sysfs makes it easier to tell the 
>> state
>> of the link during runtime considering we have a bounch of power saving
>> features and various combinations for backward compatiblity.
>
> Please fix spelling mistake - *bounch -> bunch
done
>
>
>>
>> Signed-off-by: Can Guo <quic_cang@quicinc.com>
>> ---
>>   drivers/ufs/core/ufs-sysfs.c | 71 
>> ++++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 71 insertions(+)
>>
>> diff --git a/drivers/ufs/core/ufs-sysfs.c b/drivers/ufs/core/ufs-sysfs.c
>> index c959064..53af490 100644
>> --- a/drivers/ufs/core/ufs-sysfs.c
>> +++ b/drivers/ufs/core/ufs-sysfs.c
>> @@ -628,6 +628,76 @@ static const struct attribute_group 
>> ufs_sysfs_monitor_group = {
>>       .attrs = ufs_sysfs_monitor_attrs,
>>   };
>>   +static ssize_t gear_show(struct device *dev, struct 
>> device_attribute *attr,
>> +             char *buf)
>> +{
>> +    struct ufs_hba *hba = dev_get_drvdata(dev);
>> +
>> +    return sysfs_emit(buf, "%u\n", hba->pwr_info.gear_rx);
>> +}
>> +
>> +static ssize_t lane_show(struct device *dev, struct device_attribute 
>> *attr,
>> +             char *buf)
>> +{
>> +    struct ufs_hba *hba = dev_get_drvdata(dev);
>> +
>> +    return sysfs_emit(buf, "%u\n", hba->pwr_info.lane_rx);
>> +}
>> +
>> +static ssize_t mode_show(struct device *dev, struct device_attribute 
>> *attr,
>> +             char *buf)
>> +{
>> +    struct ufs_hba *hba = dev_get_drvdata(dev);
>> +
>> +    return sysfs_emit(buf, "%u\n", hba->pwr_info.pwr_rx);
>> +}
>> +
>> +static ssize_t rate_show(struct device *dev, struct device_attribute 
>> *attr,
>> +             char *buf)
>> +{
>> +    struct ufs_hba *hba = dev_get_drvdata(dev);
>> +
>> +    return sysfs_emit(buf, "%u\n", hba->pwr_info.hs_rate);
>> +}
>> +
>> +static ssize_t dev_pm_show(struct device *dev, struct 
>> device_attribute *attr,
>> +               char *buf)
>> +{
>> +    struct ufs_hba *hba = dev_get_drvdata(dev);
>> +
>> +    return sysfs_emit(buf, "%d\n", hba->curr_dev_pwr_mode);
>> +}
>> +
>> +static ssize_t link_state_show(struct device *dev,
>> +                   struct device_attribute *attr, char *buf)
>> +{
>> +    struct ufs_hba *hba = dev_get_drvdata(dev);
>> +
>> +    return sysfs_emit(buf, "%d\n", hba->uic_link_state);
>> +}
>> +
>> +static DEVICE_ATTR_RO(gear);
>> +static DEVICE_ATTR_RO(lane);
>> +static DEVICE_ATTR_RO(mode);
>> +static DEVICE_ATTR_RO(rate);
>> +static DEVICE_ATTR_RO(dev_pm);
>> +static DEVICE_ATTR_RO(link_state);
>> +
>> +static struct attribute *ufs_power_info_attrs[] = {
>> +    &dev_attr_gear.attr,
>> +    &dev_attr_lane.attr,
>> +    &dev_attr_mode.attr,
>> +    &dev_attr_rate.attr,
>> +    &dev_attr_dev_pm.attr,
>> +    &dev_attr_link_state.attr,
>> +    NULL
>> +};
>> +
>> +static const struct attribute_group ufs_sysfs_power_info_group = {
>> +    .name = "power_info",
>> +    .attrs = ufs_power_info_attrs,
>> +};
>> +
>>   static ssize_t ufs_sysfs_read_desc_param(struct ufs_hba *hba,
>>                     enum desc_idn desc_id,
>>                     u8 desc_index,
>> @@ -1233,6 +1303,7 @@ static const struct attribute_group 
>> *ufs_sysfs_groups[] = {
>>       &ufs_sysfs_default_group,
>>       &ufs_sysfs_capabilities_group,
>>       &ufs_sysfs_monitor_group,
>> +    &ufs_sysfs_power_info_group,
>>       &ufs_sysfs_device_descriptor_group,
>>       &ufs_sysfs_interconnect_descriptor_group,
>>       &ufs_sysfs_geometry_descriptor_group,
>
>
> How about having one power mode attribute displaying all useful info 
> (lane, gear, mode, rate).

sysfs entry is meant for printing a single value instead of a line of 
strings.

>
> Regards,
> Nitin Rawat


Thanks,

Can Guo.

Can Guo Sept. 15, 2023, 2:07 a.m. UTC | #5

Hi Nitin,

On 9/14/2023 8:26 PM, Nitin Rawat wrote:
>
>
> On 9/11/2023 11:29 AM, Can Guo wrote:
>> Split High Speed Gear 4 PHY settings from common tables, and add PHY
>> settings to support High Speed Gear 5.
>>
>
> Hi Can,
>
> Can you please add more details explaining the change. We can mention 
> that are we spliting serdes setting for g3 and g4.
Sure.
>
> Also how about having 2 patches, one for splitting serdes 
> configuration b/w gear3 and gear4 and other patch about new g5 setting.
No, we should have them in one patch, because after splitting, just 
writing the common settings won't work for G5 mode.
>
> -Nitin
>

Thanks,

Can Guo

Dmitry Baryshkov Sept. 15, 2023, 2:31 a.m. UTC | #6

On 11 September 2023 13:02:50 GMT+03:00, Can Guo <quic_cang@quicinc.com> wrote:
>
>On 9/11/2023 5:46 PM, Konrad Dybcio wrote:
>> On 11.09.2023 11:42, Can Guo wrote:
>>> Hi Konrad,
>>> 
>>> On 9/11/2023 5:17 PM, Konrad Dybcio wrote:
>>>> On 11.09.2023 07:59, Can Guo wrote:
>>>>> From: "Bao D. Nguyen" <quic_nguyenb@quicinc.com>
>>>>> 
>>>>> Retrieve UFS device version from UFS host controller's spare register
>>>>> which is populated by bootloader, and use the UFS device version together
>>>>> with host controller's HW version to decide the proper power modes which
>>>>> should be used to configure the UFS PHY.
>>>> That sounds a bit fishy.. is there no bootloader-independent
>>>> solution to that? Can't we bring in the code that the bootloader
>>>> uses to determine these values?
>>>> 
>>>> Konrad
>>> 
>>> Agree, it is.
>>> 
>>> 
>>> All these complexities come from one request from PHY design team - power saving.
>>> 
>>> And to achieve power saving, Qualcomm UFS developers are requested to use the
>>> 
>>> lowest hanging PHY settings which can sustain the Max agreed HS Gear (btw host
>>> 
>>> and UFS device) during UFS's lifecycle in High Level OS,  whereas the power saving
>>> 
>>> request does not apply to bootloader, which works for only a few seconds during
>>> 
>>> bootup. Hence, there is no such version detect code in bootloader -  it just uses the
>>> 
>>> highest PHY settings to configure PHY, boot up UFS and put UFS device version in this
>>> 
>>> register.
>> First of all, your email client seems to be inserting 2 newlines
>> instead of 1. If you're using thunderbird, you may want to edit:
>> 
>> mail.identity.(default or your mail identity idx).default.compose_html
>> 
>> to `false`
>> 
>> and add that to your internal wiki page, as I see many @quic folks having
>> this issue.
>> 
>> 
>> Going back to the main topic, I don't think we understood each other.
>> The commit message states:
>> 
>> 
>> "Retrieve UFS device version from UFS host controller's spare register
>> which is populated by bootloader"
>> 
>> 
>> Which means the bootloader is able to somehow determine the value
>> that's in the spare register and write it there.
>> 
>> I'm asking whether we can take the logic behind this value and
>> move it to Linux so that we don't depend on the bootloader to
>> guarantee it (e.g. Chrome or some other devices with more exotic
>> fw may not work this way).
>> 
>> 
>> Konrad
>
>
>There is no logic behind this value at all in bootloader, as I explained, after bootloader
>
>initializes UFS, bootloader simply reads UFS's device version (the value you are referring)
>
>and write it to the register. But in Linux kernel, we need (or want to know) this value
>
>BEFORE we initialize UFS host controller (and UFS device).

Depending on the bootloader behaviour is not an option. For example the kernel might be started via kexec. Or via u-boot. Or grub. Or any other bootloader. So please duplicate the logic to read the UFS version instead.


P.S. you have been asked to fix your email client. Please do so. Or, if you are inserting these linebreaks manually, please stop.

>Thanks,
>
>Can Guo.
>

Konrad Dybcio Sept. 15, 2023, 12:48 p.m. UTC | #7

On 11.09.2023 12:02, Can Guo wrote:
> 
> On 9/11/2023 5:46 PM, Konrad Dybcio wrote:
>> On 11.09.2023 11:42, Can Guo wrote:
>>> Hi Konrad,
>>>
>>> On 9/11/2023 5:17 PM, Konrad Dybcio wrote:
>>>> On 11.09.2023 07:59, Can Guo wrote:
>>>>> From: "Bao D. Nguyen" <quic_nguyenb@quicinc.com>
>>>>>
>>>>> Retrieve UFS device version from UFS host controller's spare register
>>>>> which is populated by bootloader, and use the UFS device version together
>>>>> with host controller's HW version to decide the proper power modes which
>>>>> should be used to configure the UFS PHY.
>>>> That sounds a bit fishy.. is there no bootloader-independent
>>>> solution to that? Can't we bring in the code that the bootloader
>>>> uses to determine these values?
>>>>
>>>> Konrad
>>>
>>> Agree, it is.
>>>
>>>
>>> All these complexities come from one request from PHY design team - power saving.
>>>
>>> And to achieve power saving, Qualcomm UFS developers are requested to use the
>>>
>>> lowest hanging PHY settings which can sustain the Max agreed HS Gear (btw host
>>>
>>> and UFS device) during UFS's lifecycle in High Level OS,  whereas the power saving
>>>
>>> request does not apply to bootloader, which works for only a few seconds during
>>>
>>> bootup. Hence, there is no such version detect code in bootloader -  it just uses the
>>>
>>> highest PHY settings to configure PHY, boot up UFS and put UFS device version in this
>>>
>>> register.
>> First of all, your email client seems to be inserting 2 newlines
>> instead of 1. If you're using thunderbird, you may want to edit:
>>
>> mail.identity.(default or your mail identity idx).default.compose_html
>>
>> to `false`
>>
>> and add that to your internal wiki page, as I see many @quic folks having
>> this issue.
>>
>>
>> Going back to the main topic, I don't think we understood each other.
>> The commit message states:
>>
>>
>> "Retrieve UFS device version from UFS host controller's spare register
>> which is populated by bootloader"
>>
>>
>> Which means the bootloader is able to somehow determine the value
>> that's in the spare register and write it there.
>>
>> I'm asking whether we can take the logic behind this value and
>> move it to Linux so that we don't depend on the bootloader to
>> guarantee it (e.g. Chrome or some other devices with more exotic
>> fw may not work this way).
>>
>>
>> Konrad
> 
> 
> There is no logic behind this value at all in bootloader, as I explained, after bootloader
> 
> initializes UFS, bootloader simply reads UFS's device version (the value you are referring)
> 
> and write it to the register. But in Linux kernel, we need (or want to know) this value
> 
> BEFORE we initialize UFS host controller (and UFS device).
Can't you just initialize the PHY at G4 or G5 unconditionally,
read back the required info and then decide based on that?

Konrad

Manivannan Sadhasivam Sept. 19, 2023, 10:36 a.m. UTC | #8

On Sun, Sep 10, 2023 at 10:59:22PM -0700, Can Guo wrote:
> Setup host power mode and its limitations during UFS host driver init to
> avoid repetitive work during every power mode change.
> 
> Co-developed-by: Bao D. Nguyen <quic_nguyenb@quicinc.com>
> Signed-off-by: Can Guo <quic_cang@quicinc.com>
> Signed-off-by: Bao D. Nguyen <quic_nguyenb@quicinc.com>
> ---
>  drivers/ufs/host/ufs-qcom.c | 27 ++++++++++++++++++---------
>  drivers/ufs/host/ufs-qcom.h |  1 +
>  2 files changed, 19 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> index c3215d3..710f079 100644
> --- a/drivers/ufs/host/ufs-qcom.c
> +++ b/drivers/ufs/host/ufs-qcom.c
> @@ -443,7 +443,11 @@ static u32 ufs_qcom_get_hs_gear(struct ufs_hba *hba)
>  static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
>  {
>  	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
> +	struct ufs_dev_params *host_pwr_cap = &host->host_pwr_cap;
>  	struct phy *phy = host->generic_phy;
> +	enum phy_mode mode = host_pwr_cap->hs_rate == PA_HS_MODE_B ?
> +							PHY_MODE_UFS_HS_B :
> +							PHY_MODE_UFS_HS_A;

I do not see anyone passing PA_HS_MODE_A in this patch, so this change is not
required now. If you are doing this as a preparatory work, please do it in a
separate patch.

>  	int ret;
>  
>  	/* Reset UFS Host Controller and PHY */
> @@ -460,7 +464,7 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
>  		return ret;
>  	}
>  
> -	phy_set_mode_ext(phy, PHY_MODE_UFS_HS_B, host->phy_gear);
> +	phy_set_mode_ext(phy, mode, host->phy_gear);

Same as above.

>  
>  	/* power on phy - start serdes and phy's power and clocks */
>  	ret = phy_power_on(phy);
> @@ -884,7 +888,6 @@ static int ufs_qcom_pwr_change_notify(struct ufs_hba *hba,
>  				struct ufs_pa_layer_attr *dev_req_params)
>  {
>  	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
> -	struct ufs_dev_params ufs_qcom_cap;
>  	int ret = 0;
>  
>  	if (!dev_req_params) {
> @@ -894,13 +897,7 @@ static int ufs_qcom_pwr_change_notify(struct ufs_hba *hba,
>  
>  	switch (status) {
>  	case PRE_CHANGE:
> -		ufshcd_init_pwr_dev_param(&ufs_qcom_cap);
> -		ufs_qcom_cap.hs_rate = UFS_QCOM_LIMIT_HS_RATE;
> -
> -		/* This driver only supports symmetic gear setting i.e., hs_tx_gear == hs_rx_gear */
> -		ufs_qcom_cap.hs_tx_gear = ufs_qcom_cap.hs_rx_gear = ufs_qcom_get_hs_gear(hba);
> -
> -		ret = ufshcd_get_pwr_dev_param(&ufs_qcom_cap,
> +		ret = ufshcd_get_pwr_dev_param(&host->host_pwr_cap,
>  					       dev_max_params,
>  					       dev_req_params);
>  		if (ret) {
> @@ -1037,6 +1034,17 @@ static void ufs_qcom_advertise_quirks(struct ufs_hba *hba)
>  		hba->quirks |= UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH;
>  }
>  
> +static void ufs_qcom_set_pwr_mode_limits(struct ufs_hba *hba)

It's good that you are moving the setting to init() as they are static, but I'm
worried about the different naming conventions used all over the place.

The intention here is to set host parameters and then get the agreed one between
host and the device. But different names are being used. The structure itself is
named as "ufs_dev_params" even though it targets host and the vendor drivers are
naming it as "ufs_<vendor>_cap" or "host_cap". And now you've given a new name,
"host_pwr_cap", which makes things even worse.

So we should rename the struct itself as "ufs_host_params" and all the vendor
drivers should stick to "host_params".

If you do not want to do it in this series, please use existing "host_cap",
since you are embedding it within "ufs_qcom_host" struct.

Also, it'd be good to make this change for other vendor drivers as well (moving
to init()).

- Mani

> +{
> +	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
> +	struct ufs_dev_params *host_pwr_cap = &host->host_pwr_cap;
> +
> +	ufshcd_init_pwr_dev_param(host_pwr_cap);
> +
> +	/* This driver only supports symmetic gear setting i.e., hs_tx_gear == hs_rx_gear */
> +	host_pwr_cap->hs_tx_gear = host_pwr_cap->hs_rx_gear = ufs_qcom_get_hs_gear(hba);
> +}
> +
>  static void ufs_qcom_set_caps(struct ufs_hba *hba)
>  {
>  	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
> @@ -1259,6 +1267,7 @@ static int ufs_qcom_init(struct ufs_hba *hba)
>  	if (err)
>  		goto out_variant_clear;
>  
> +	ufs_qcom_set_pwr_mode_limits(hba);
>  	ufs_qcom_set_caps(hba);
>  	ufs_qcom_advertise_quirks(hba);
>  
> diff --git a/drivers/ufs/host/ufs-qcom.h b/drivers/ufs/host/ufs-qcom.h
> index fa54248..4db64d9 100644
> --- a/drivers/ufs/host/ufs-qcom.h
> +++ b/drivers/ufs/host/ufs-qcom.h
> @@ -227,6 +227,7 @@ struct ufs_qcom_host {
>  
>  	struct gpio_desc *device_reset;
>  
> +	struct ufs_dev_params host_pwr_cap;
>  	u32 phy_gear;
>  
>  	bool esi_enabled;
> -- 
> 2.7.4
>

Manivannan Sadhasivam Sept. 19, 2023, 12:08 p.m. UTC | #9

On Fri, Sep 15, 2023 at 05:31:45AM +0300, Dmitry Baryshkov wrote:
> On 11 September 2023 13:02:50 GMT+03:00, Can Guo <quic_cang@quicinc.com> wrote:
> >
> >On 9/11/2023 5:46 PM, Konrad Dybcio wrote:
> >> On 11.09.2023 11:42, Can Guo wrote:
> >>> Hi Konrad,
> >>> 
> >>> On 9/11/2023 5:17 PM, Konrad Dybcio wrote:
> >>>> On 11.09.2023 07:59, Can Guo wrote:
> >>>>> From: "Bao D. Nguyen" <quic_nguyenb@quicinc.com>
> >>>>> 
> >>>>> Retrieve UFS device version from UFS host controller's spare register
> >>>>> which is populated by bootloader, and use the UFS device version together
> >>>>> with host controller's HW version to decide the proper power modes which
> >>>>> should be used to configure the UFS PHY.
> >>>> That sounds a bit fishy.. is there no bootloader-independent
> >>>> solution to that? Can't we bring in the code that the bootloader
> >>>> uses to determine these values?
> >>>> 
> >>>> Konrad
> >>> 
> >>> Agree, it is.
> >>> 
> >>> 
> >>> All these complexities come from one request from PHY design team - power saving.
> >>> 
> >>> And to achieve power saving, Qualcomm UFS developers are requested to use the
> >>> 
> >>> lowest hanging PHY settings which can sustain the Max agreed HS Gear (btw host
> >>> 
> >>> and UFS device) during UFS's lifecycle in High Level OS,  whereas the power saving
> >>> 
> >>> request does not apply to bootloader, which works for only a few seconds during
> >>> 
> >>> bootup. Hence, there is no such version detect code in bootloader -  it just uses the
> >>> 
> >>> highest PHY settings to configure PHY, boot up UFS and put UFS device version in this
> >>> 
> >>> register.
> >> First of all, your email client seems to be inserting 2 newlines
> >> instead of 1. If you're using thunderbird, you may want to edit:
> >> 
> >> mail.identity.(default or your mail identity idx).default.compose_html
> >> 
> >> to `false`
> >> 
> >> and add that to your internal wiki page, as I see many @quic folks having
> >> this issue.
> >> 
> >> 
> >> Going back to the main topic, I don't think we understood each other.
> >> The commit message states:
> >> 
> >> 
> >> "Retrieve UFS device version from UFS host controller's spare register
> >> which is populated by bootloader"
> >> 
> >> 
> >> Which means the bootloader is able to somehow determine the value
> >> that's in the spare register and write it there.
> >> 
> >> I'm asking whether we can take the logic behind this value and
> >> move it to Linux so that we don't depend on the bootloader to
> >> guarantee it (e.g. Chrome or some other devices with more exotic
> >> fw may not work this way).
> >> 
> >> 
> >> Konrad
> >
> >
> >There is no logic behind this value at all in bootloader, as I explained, after bootloader
> >
> >initializes UFS, bootloader simply reads UFS's device version (the value you are referring)
> >
> >and write it to the register. But in Linux kernel, we need (or want to know) this value
> >
> >BEFORE we initialize UFS host controller (and UFS device).
> 
> Depending on the bootloader behaviour is not an option. For example the kernel might be started via kexec. Or via u-boot. Or grub. Or any other bootloader. So please duplicate the logic to read the UFS version instead.
> 

As Can said, there is no logic in the bootloader. What it does it, after doing
the UFS initialization, it writes the agreed gear (between host and the device)
to this register. And in linux, we use that value to initialize the device
(i.e., not doing init based on the min gear).

But the important factor here is that, we use this gear value to program the PHY
init sequence. So if there is no hint from the bootloader, linux will program
the min phy sequence (G3/G4) and then once the gear scaling happens, it will
program the max phy sequence (G4/G5).

Now on recent platforms, the init sequences are not compatible with each other
i.e., once the min seq. is programmed, then before programming max seq. the
registers not common to both seq. should be programmed to default value. In
other words, min seq. specific registers should be reset to the default value.
Otherwise, there will be stability issues in the PHY.

So to avoid that, if we get the hint from bootloader (always the max supported
gear between host and device), then only one seq. will be programmed.

Other way to solve this issue is to reset the non common registers in the init
seq. to default value. But that will be an additional overhead.

But... if the bootloader doesn't populate this register (if the boot device is
not UFS, like in compute platforms), then this whole logic won't work. This
should also be taken into consideration.

- Mani

> 
> P.S. you have been asked to fix your email client. Please do so. Or, if you are inserting these linebreaks manually, please stop.
> 
> >Thanks,
> >
> >Can Guo.
> >
>

Manivannan Sadhasivam Sept. 19, 2023, 12:10 p.m. UTC | #10

On Sun, Sep 10, 2023 at 10:59:24PM -0700, Can Guo wrote:
> Split High Speed Gear 4 PHY settings from common tables, and add PHY
> settings to support High Speed Gear 5.
> 

Please add more information on why this change is needed.

- Mani

> Signed-off-by: Can Guo <quic_cang@quicinc.com>
> ---
>  drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h     |   2 +
>  drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h |   2 +
>  .../qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h    |  12 +++
>  drivers/phy/qualcomm/phy-qcom-qmp-ufs.c            | 112 ++++++++++++++++++---
>  4 files changed, 115 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h
> index c23d5e4..e563af5 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcs-ufs-v6.h
> @@ -18,6 +18,7 @@
>  #define QPHY_V6_PCS_UFS_BIST_FIXED_PAT_CTRL		0x060
>  #define QPHY_V6_PCS_UFS_TX_HSGEAR_CAPABILITY		0x074
>  #define QPHY_V6_PCS_UFS_RX_HSGEAR_CAPABILITY		0x0bc
> +#define QPHY_V6_PCS_UFS_RX_HS_G5_SYNC_LENGTH_CAPABILITY	0x12c
>  #define QPHY_V6_PCS_UFS_DEBUG_BUS_CLKSEL		0x158
>  #define QPHY_V6_PCS_UFS_LINECFG_DISABLE			0x17c
>  #define QPHY_V6_PCS_UFS_RX_MIN_HIBERN8_TIME		0x184
> @@ -27,5 +28,6 @@
>  #define QPHY_V6_PCS_UFS_READY_STATUS			0x1a8
>  #define QPHY_V6_PCS_UFS_TX_MID_TERM_CTRL1		0x1f4
>  #define QPHY_V6_PCS_UFS_MULTI_LANE_CTRL1		0x1fc
> +#define QPHY_V6_PCS_UFS_RX_HSG5_SYNC_WAIT_TIME		0x220
>  
>  #endif
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h
> index f420f8f..ef392ce 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-com-v6.h
> @@ -56,6 +56,8 @@
>  #define QSERDES_V6_COM_SYS_CLK_CTRL				0xe4
>  #define QSERDES_V6_COM_SYSCLK_BUF_ENABLE			0xe8
>  #define QSERDES_V6_COM_PLL_IVCO					0xf4
> +#define QSERDES_V6_COM_CMN_IETRIM				0xfc
> +#define QSERDES_V6_COM_CMN_IPTRIM				0x100
>  #define QSERDES_V6_COM_SYSCLK_EN_SEL				0x110
>  #define QSERDES_V6_COM_RESETSM_CNTRL				0x118
>  #define QSERDES_V6_COM_LOCK_CMP_EN				0x120
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h
> index 15bcb4b..48f31c8 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-qserdes-txrx-ufs-v6.h
> @@ -10,10 +10,20 @@
>  #define QSERDES_UFS_V6_TX_RES_CODE_LANE_RX			0x2c
>  #define QSERDES_UFS_V6_TX_RES_CODE_LANE_OFFSET_TX		0x30
>  #define QSERDES_UFS_V6_TX_RES_CODE_LANE_OFFSET_RX		0x34
> +#define QSERDES_UFS_V6_TX_LANE_MODE_1				0x7c
> +#define QSERDES_UFS_V6_TX_FR_DCC_CTRL				0x108
>  
>  #define QSERDES_UFS_V6_RX_UCDR_FASTLOCK_FO_GAIN_RATE2		0x08
>  #define QSERDES_UFS_V6_RX_UCDR_FASTLOCK_FO_GAIN_RATE4		0x10
> +#define QSERDES_UFS_V6_RX_UCDR_FASTLOCK_SO_GAIN_RATE4		0x24
> +#define QSERDES_UFS_V6_RX_UCDR_FASTLOCK_COUNT_HIGH_RATE4	0x54
> +#define QSERDES_UFS_V6_RX_UCDR_FO_GAIN_RATE2			0xd4
> +#define QSERDES_UFS_V6_RX_UCDR_FO_GAIN_RATE4			0xdc
> +#define QSERDES_UFS_V6_RX_UCDR_SO_GAIN_RATE4			0xf0
> +#define QSERDES_UFS_V6_RX_UCDR_PI_CONTROLS			0xf4
>  #define QSERDES_UFS_V6_RX_VGA_CAL_MAN_VAL			0x178
> +#define QSERDES_UFS_V6_RX_EQ_OFFSET_ADAPTOR_CNTRL1		0x1bc
> +#define QSERDES_UFS_V6_RX_OFFSET_ADAPTOR_CNTRL3			0x1c4
>  #define QSERDES_UFS_V6_RX_MODE_RATE_0_1_B0			0x208
>  #define QSERDES_UFS_V6_RX_MODE_RATE_0_1_B1			0x20c
>  #define QSERDES_UFS_V6_RX_MODE_RATE_0_1_B3			0x214
> @@ -25,6 +35,8 @@
>  #define QSERDES_UFS_V6_RX_MODE_RATE3_B5				0x264
>  #define QSERDES_UFS_V6_RX_MODE_RATE3_B8				0x270
>  #define QSERDES_UFS_V6_RX_MODE_RATE4_B3				0x280
> +#define QSERDES_UFS_V6_RX_MODE_RATE4_B4				0x284
>  #define QSERDES_UFS_V6_RX_MODE_RATE4_B6				0x28c
> +#define QSERDES_UFS_V6_RX_DLL0_FTUNE_CTRL			0x2f8
>  
>  #endif
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> index 8c877b6..d0ecacf 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
> @@ -650,32 +650,51 @@ static const struct qmp_phy_init_tbl sm8550_ufsphy_serdes[] = {
>  	QMP_PHY_INIT_CFG(QSERDES_V6_COM_HSCLK_SEL_1, 0x11),
>  	QMP_PHY_INIT_CFG(QSERDES_V6_COM_HSCLK_HS_SWITCH_SEL_1, 0x00),
>  	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP_EN, 0x01),
> -	QMP_PHY_INIT_CFG(QSERDES_V6_COM_VCO_TUNE_MAP, 0x04),
> -	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_IVCO, 0x0f),
> +
>  	QMP_PHY_INIT_CFG(QSERDES_V6_COM_VCO_TUNE_INITVAL2, 0x00),
>  	QMP_PHY_INIT_CFG(QSERDES_V6_COM_DEC_START_MODE0, 0x41),
> -	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE0, 0x0a),
>  	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_RCTRL_MODE0, 0x18),
>  	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_CCTRL_MODE0, 0x14),
>  	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP1_MODE0, 0x7f),
>  	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP2_MODE0, 0x06),
> -	QMP_PHY_INIT_CFG(QSERDES_V6_COM_DEC_START_MODE0, 0x4c),
> +};
> +
> +static const struct qmp_phy_init_tbl sm8550_ufsphy_hs_b_serdes[] = {
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_VCO_TUNE_MAP, 0x44),
> +};
> +
> +static const struct qmp_phy_init_tbl sm8550_ufsphy_g4_serdes[] = {
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_VCO_TUNE_MAP, 0x04),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_IVCO, 0x0f),
>  	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE0, 0x0a),
> -	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_RCTRL_MODE0, 0x18),
> -	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_CCTRL_MODE0, 0x14),
> -	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP1_MODE0, 0x99),
> -	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP2_MODE0, 0x07),
> +
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_DEC_START_MODE1, 0x4c),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE1, 0x0a),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_RCTRL_MODE1, 0x18),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_CCTRL_MODE1, 0x14),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP1_MODE1, 0x99),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP2_MODE1, 0x07),
> +};
> +
> +static const struct qmp_phy_init_tbl sm8550_ufsphy_g5_serdes[] = {
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_IVCO, 0x1f),
> +
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CMN_IETRIM, 0x1b),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CMN_IPTRIM, 0x1c),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE0, 0x06),
>  };
>  
>  static const struct qmp_phy_init_tbl sm8550_ufsphy_tx[] = {
> -	QMP_PHY_INIT_CFG(QSERDES_V6_TX_LANE_MODE_1, 0x05),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_TX_LANE_MODE_1, 0x05),
>  	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_TX_RES_CODE_LANE_OFFSET_TX, 0x07),
>  };
>  
> +static const struct qmp_phy_init_tbl sm8550_ufsphy_g4_tx[] = {
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_TX_FR_DCC_CTRL, 0x4c),
> +};
> +
>  static const struct qmp_phy_init_tbl sm8550_ufsphy_rx[] = {
> -	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_FASTLOCK_FO_GAIN_RATE2, 0x0c),
> -	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_FASTLOCK_FO_GAIN_RATE4, 0x0f),
> -	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_VGA_CAL_MAN_VAL, 0x0e),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_FO_GAIN_RATE2, 0x0c),
>  
>  	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_MODE_RATE_0_1_B0, 0xc2),
>  	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_MODE_RATE_0_1_B1, 0xc2),
> @@ -691,14 +710,46 @@ static const struct qmp_phy_init_tbl sm8550_ufsphy_rx[] = {
>  	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_MODE_RATE3_B8, 0x02),
>  };
>  
> +static const struct qmp_phy_init_tbl sm8550_ufsphy_g4_rx[] = {
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_VGA_CAL_MAN_VAL, 0x0e),
> +};
> +
> +static const struct qmp_phy_init_tbl sm8550_ufsphy_g5_rx[] = {
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_FO_GAIN_RATE4, 0x0c),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_SO_GAIN_RATE4, 0x04),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_EQ_OFFSET_ADAPTOR_CNTRL1, 0x14),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_PI_CONTROLS, 0x07),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_OFFSET_ADAPTOR_CNTRL3, 0x0e),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_FASTLOCK_COUNT_HIGH_RATE4, 0x02),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_FASTLOCK_FO_GAIN_RATE4, 0x1c),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_UCDR_FASTLOCK_SO_GAIN_RATE4, 0x06),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_VGA_CAL_MAN_VAL, 0x08),
> +
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_MODE_RATE4_B3, 0xb9),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_MODE_RATE4_B4, 0x4f),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_MODE_RATE4_B6, 0xff),
> +	QMP_PHY_INIT_CFG(QSERDES_UFS_V6_RX_DLL0_FTUNE_CTRL, 0x30),
> +};
> +
>  static const struct qmp_phy_init_tbl sm8550_ufsphy_pcs[] = {
>  	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_RX_SIGDET_CTRL2, 0x69),
>  	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_TX_LARGE_AMP_DRV_LVL, 0x0f),
>  	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_TX_MID_TERM_CTRL1, 0x43),
> -	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_PLL_CNTL, 0x2b),
>  	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_MULTI_LANE_CTRL1, 0x02),
>  };
>  
> +static const struct qmp_phy_init_tbl sm8550_ufsphy_g4_pcs[] = {
> +	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_PLL_CNTL, 0x2b),
> +	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_TX_HSGEAR_CAPABILITY, 0x04),
> +	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_RX_HSGEAR_CAPABILITY, 0x04),
> +};
> +
> +static const struct qmp_phy_init_tbl sm8550_ufsphy_g5_pcs[] = {
> +	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_PLL_CNTL, 0x33),
> +	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_RX_HS_G5_SYNC_LENGTH_CAPABILITY, 0x4f),
> +	QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_RX_HSG5_SYNC_WAIT_TIME, 0x9e),
> +};
> +
>  struct qmp_ufs_offsets {
>  	u16 serdes;
>  	u16 pcs;
> @@ -732,6 +783,8 @@ struct qmp_phy_cfg {
>  	const struct qmp_phy_cfg_tbls tbls_hs_b;
>  	/* Additional sequence for HS G4 */
>  	const struct qmp_phy_cfg_tbls tbls_hs_g4;
> +	/* Additional sequence for HS G4 */
> +	const struct qmp_phy_cfg_tbls tbls_hs_g5;
>  
>  	/* clock ids to be requested */
>  	const char * const *clk_list;
> @@ -1146,6 +1199,28 @@ static const struct qmp_phy_cfg sm8550_ufsphy_cfg = {
>  		.pcs		= sm8550_ufsphy_pcs,
>  		.pcs_num	= ARRAY_SIZE(sm8550_ufsphy_pcs),
>  	},
> +	.tbls_hs_b = {
> +		.serdes		= sm8550_ufsphy_hs_b_serdes,
> +		.serdes_num	= ARRAY_SIZE(sm8550_ufsphy_hs_b_serdes),
> +	},
> +	.tbls_hs_g4 = {
> +		.serdes		= sm8550_ufsphy_g4_serdes,
> +		.serdes_num	= ARRAY_SIZE(sm8550_ufsphy_g4_serdes),
> +		.tx		= sm8550_ufsphy_g4_tx,
> +		.tx_num		= ARRAY_SIZE(sm8550_ufsphy_g4_tx),
> +		.rx		= sm8550_ufsphy_g4_rx,
> +		.rx_num		= ARRAY_SIZE(sm8550_ufsphy_g4_rx),
> +		.pcs		= sm8550_ufsphy_g4_pcs,
> +		.pcs_num	= ARRAY_SIZE(sm8550_ufsphy_g4_pcs),
> +	},
> +	.tbls_hs_g5 = {
> +		.serdes		= sm8550_ufsphy_g5_serdes,
> +		.serdes_num	= ARRAY_SIZE(sm8550_ufsphy_g5_serdes),
> +		.rx		= sm8550_ufsphy_g5_rx,
> +		.rx_num		= ARRAY_SIZE(sm8550_ufsphy_g5_rx),
> +		.pcs		= sm8550_ufsphy_g5_pcs,
> +		.pcs_num	= ARRAY_SIZE(sm8550_ufsphy_g5_pcs),
> +	},
>  	.clk_list		= sdm845_ufs_phy_clk_l,
>  	.num_clks		= ARRAY_SIZE(sdm845_ufs_phy_clk_l),
>  	.vreg_list		= qmp_phy_vreg_l,
> @@ -1211,14 +1286,25 @@ static void qmp_ufs_pcs_init(struct qmp_ufs *qmp, const struct qmp_phy_cfg_tbls
>  static void qmp_ufs_init_registers(struct qmp_ufs *qmp, const struct qmp_phy_cfg *cfg)
>  {
>  	qmp_ufs_serdes_init(qmp, &cfg->tbls);
> +	if (qmp->submode == UFS_HS_G4)
> +		qmp_ufs_serdes_init(qmp, &cfg->tbls_hs_g4);
> +	else if (qmp->submode == UFS_HS_G5)
> +		qmp_ufs_serdes_init(qmp, &cfg->tbls_hs_g5);
> +
>  	if (qmp->mode == PHY_MODE_UFS_HS_B)
>  		qmp_ufs_serdes_init(qmp, &cfg->tbls_hs_b);
> +
>  	qmp_ufs_lanes_init(qmp, &cfg->tbls);
>  	if (qmp->submode == UFS_HS_G4)
>  		qmp_ufs_lanes_init(qmp, &cfg->tbls_hs_g4);
> +	else if (qmp->submode == UFS_HS_G5)
> +		qmp_ufs_lanes_init(qmp, &cfg->tbls_hs_g5);
> +
>  	qmp_ufs_pcs_init(qmp, &cfg->tbls);
>  	if (qmp->submode == UFS_HS_G4)
>  		qmp_ufs_pcs_init(qmp, &cfg->tbls_hs_g4);
> +	else if (qmp->submode == UFS_HS_G5)
> +		qmp_ufs_pcs_init(qmp, &cfg->tbls_hs_g5);
>  }
>  
>  static int qmp_ufs_com_init(struct qmp_ufs *qmp)
> -- 
> 2.7.4
>

Manivannan Sadhasivam Sept. 19, 2023, 12:16 p.m. UTC | #11

On Sun, Sep 10, 2023 at 10:59:26PM -0700, Can Guo wrote:
> Having UFS power info available in sysfs makes it easier to tell the state
> of the link during runtime considering we have a bounch of power saving
> features and various combinations for backward compatiblity.
> 

Please move the sysfs patches to a separate series.

- Mani

> Signed-off-by: Can Guo <quic_cang@quicinc.com>
> ---
>  drivers/ufs/core/ufs-sysfs.c | 71 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 71 insertions(+)
> 
> diff --git a/drivers/ufs/core/ufs-sysfs.c b/drivers/ufs/core/ufs-sysfs.c
> index c959064..53af490 100644
> --- a/drivers/ufs/core/ufs-sysfs.c
> +++ b/drivers/ufs/core/ufs-sysfs.c
> @@ -628,6 +628,76 @@ static const struct attribute_group ufs_sysfs_monitor_group = {
>  	.attrs = ufs_sysfs_monitor_attrs,
>  };
>  
> +static ssize_t gear_show(struct device *dev, struct device_attribute *attr,
> +			 char *buf)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	return sysfs_emit(buf, "%u\n", hba->pwr_info.gear_rx);
> +}
> +
> +static ssize_t lane_show(struct device *dev, struct device_attribute *attr,
> +			 char *buf)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	return sysfs_emit(buf, "%u\n", hba->pwr_info.lane_rx);
> +}
> +
> +static ssize_t mode_show(struct device *dev, struct device_attribute *attr,
> +			 char *buf)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	return sysfs_emit(buf, "%u\n", hba->pwr_info.pwr_rx);
> +}
> +
> +static ssize_t rate_show(struct device *dev, struct device_attribute *attr,
> +			 char *buf)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	return sysfs_emit(buf, "%u\n", hba->pwr_info.hs_rate);
> +}
> +
> +static ssize_t dev_pm_show(struct device *dev, struct device_attribute *attr,
> +			   char *buf)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	return sysfs_emit(buf, "%d\n", hba->curr_dev_pwr_mode);
> +}
> +
> +static ssize_t link_state_show(struct device *dev,
> +			       struct device_attribute *attr, char *buf)
> +{
> +	struct ufs_hba *hba = dev_get_drvdata(dev);
> +
> +	return sysfs_emit(buf, "%d\n", hba->uic_link_state);
> +}
> +
> +static DEVICE_ATTR_RO(gear);
> +static DEVICE_ATTR_RO(lane);
> +static DEVICE_ATTR_RO(mode);
> +static DEVICE_ATTR_RO(rate);
> +static DEVICE_ATTR_RO(dev_pm);
> +static DEVICE_ATTR_RO(link_state);
> +
> +static struct attribute *ufs_power_info_attrs[] = {
> +	&dev_attr_gear.attr,
> +	&dev_attr_lane.attr,
> +	&dev_attr_mode.attr,
> +	&dev_attr_rate.attr,
> +	&dev_attr_dev_pm.attr,
> +	&dev_attr_link_state.attr,
> +	NULL
> +};
> +
> +static const struct attribute_group ufs_sysfs_power_info_group = {
> +	.name = "power_info",
> +	.attrs = ufs_power_info_attrs,
> +};
> +
>  static ssize_t ufs_sysfs_read_desc_param(struct ufs_hba *hba,
>  				  enum desc_idn desc_id,
>  				  u8 desc_index,
> @@ -1233,6 +1303,7 @@ static const struct attribute_group *ufs_sysfs_groups[] = {
>  	&ufs_sysfs_default_group,
>  	&ufs_sysfs_capabilities_group,
>  	&ufs_sysfs_monitor_group,
> +	&ufs_sysfs_power_info_group,
>  	&ufs_sysfs_device_descriptor_group,
>  	&ufs_sysfs_interconnect_descriptor_group,
>  	&ufs_sysfs_geometry_descriptor_group,
> -- 
> 2.7.4
>

Dmitry Baryshkov Sept. 19, 2023, 10:27 p.m. UTC | #12

On Tue, 19 Sept 2023 at 15:08, Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Fri, Sep 15, 2023 at 05:31:45AM +0300, Dmitry Baryshkov wrote:
> > On 11 September 2023 13:02:50 GMT+03:00, Can Guo <quic_cang@quicinc.com> wrote:
> > >
> > >On 9/11/2023 5:46 PM, Konrad Dybcio wrote:
> > >> On 11.09.2023 11:42, Can Guo wrote:
> > >>> Hi Konrad,
> > >>>
> > >>> On 9/11/2023 5:17 PM, Konrad Dybcio wrote:
> > >>>> On 11.09.2023 07:59, Can Guo wrote:
> > >>>>> From: "Bao D. Nguyen" <quic_nguyenb@quicinc.com>
> > >>>>>
> > >>>>> Retrieve UFS device version from UFS host controller's spare register
> > >>>>> which is populated by bootloader, and use the UFS device version together
> > >>>>> with host controller's HW version to decide the proper power modes which
> > >>>>> should be used to configure the UFS PHY.
> > >>>> That sounds a bit fishy.. is there no bootloader-independent
> > >>>> solution to that? Can't we bring in the code that the bootloader
> > >>>> uses to determine these values?
> > >>>>
> > >>>> Konrad
> > >>>
> > >>> Agree, it is.
> > >>>
> > >>>
> > >>> All these complexities come from one request from PHY design team - power saving.
> > >>>
> > >>> And to achieve power saving, Qualcomm UFS developers are requested to use the
> > >>>
> > >>> lowest hanging PHY settings which can sustain the Max agreed HS Gear (btw host
> > >>>
> > >>> and UFS device) during UFS's lifecycle in High Level OS,  whereas the power saving
> > >>>
> > >>> request does not apply to bootloader, which works for only a few seconds during
> > >>>
> > >>> bootup. Hence, there is no such version detect code in bootloader -  it just uses the
> > >>>
> > >>> highest PHY settings to configure PHY, boot up UFS and put UFS device version in this
> > >>>
> > >>> register.
> > >> First of all, your email client seems to be inserting 2 newlines
> > >> instead of 1. If you're using thunderbird, you may want to edit:
> > >>
> > >> mail.identity.(default or your mail identity idx).default.compose_html
> > >>
> > >> to `false`
> > >>
> > >> and add that to your internal wiki page, as I see many @quic folks having
> > >> this issue.
> > >>
> > >>
> > >> Going back to the main topic, I don't think we understood each other.
> > >> The commit message states:
> > >>
> > >>
> > >> "Retrieve UFS device version from UFS host controller's spare register
> > >> which is populated by bootloader"
> > >>
> > >>
> > >> Which means the bootloader is able to somehow determine the value
> > >> that's in the spare register and write it there.
> > >>
> > >> I'm asking whether we can take the logic behind this value and
> > >> move it to Linux so that we don't depend on the bootloader to
> > >> guarantee it (e.g. Chrome or some other devices with more exotic
> > >> fw may not work this way).
> > >>
> > >>
> > >> Konrad
> > >
> > >
> > >There is no logic behind this value at all in bootloader, as I explained, after bootloader
> > >
> > >initializes UFS, bootloader simply reads UFS's device version (the value you are referring)
> > >
> > >and write it to the register. But in Linux kernel, we need (or want to know) this value
> > >
> > >BEFORE we initialize UFS host controller (and UFS device).
> >
> > Depending on the bootloader behaviour is not an option. For example the kernel might be started via kexec. Or via u-boot. Or grub. Or any other bootloader. So please duplicate the logic to read the UFS version instead.
> >
>
> As Can said, there is no logic in the bootloader. What it does it, after doing
> the UFS initialization, it writes the agreed gear (between host and the device)
> to this register. And in linux, we use that value to initialize the device
> (i.e., not doing init based on the min gear).
>
> But the important factor here is that, we use this gear value to program the PHY
> init sequence. So if there is no hint from the bootloader, linux will program
> the min phy sequence (G3/G4) and then once the gear scaling happens, it will
> program the max phy sequence (G4/G5).
>
> Now on recent platforms, the init sequences are not compatible with each other
> i.e., once the min seq. is programmed, then before programming max seq. the
> registers not common to both seq. should be programmed to default value. In
> other words, min seq. specific registers should be reset to the default value.
> Otherwise, there will be stability issues in the PHY.

I see nothing wrong with adding 'default' register programming to the
gear tables. If we have to reset them to the default values to switch
the PHY settings, these writes must be a part of the corresponding
tables.

>
> So to avoid that, if we get the hint from bootloader (always the max supported
> gear between host and device), then only one seq. will be programmed.
>
> Other way to solve this issue is to reset the non common registers in the init
> seq. to default value. But that will be an additional overhead.
>
> But... if the bootloader doesn't populate this register (if the boot device is
> not UFS, like in compute platforms), then this whole logic won't work. This
> should also be taken into consideration.

Yep, that's the dependency on the bootloader. Which we should avoid.

>
> - Mani
>
> >
> > P.S. you have been asked to fix your email client. Please do so. Or, if you are inserting these linebreaks manually, please stop.
> >
> > >Thanks,
> > >
> > >Can Guo.
> > >
> >
>
> --
> மணிவண்ணன் சதாசிவம்

Manivannan Sadhasivam Sept. 20, 2023, 10:23 a.m. UTC | #13

On Wed, Sep 20, 2023 at 01:27:59AM +0300, Dmitry Baryshkov wrote:
> On Tue, 19 Sept 2023 at 15:08, Manivannan Sadhasivam <mani@kernel.org> wrote:
> >
> > On Fri, Sep 15, 2023 at 05:31:45AM +0300, Dmitry Baryshkov wrote:
> > > On 11 September 2023 13:02:50 GMT+03:00, Can Guo <quic_cang@quicinc.com> wrote:
> > > >
> > > >On 9/11/2023 5:46 PM, Konrad Dybcio wrote:
> > > >> On 11.09.2023 11:42, Can Guo wrote:
> > > >>> Hi Konrad,
> > > >>>
> > > >>> On 9/11/2023 5:17 PM, Konrad Dybcio wrote:
> > > >>>> On 11.09.2023 07:59, Can Guo wrote:
> > > >>>>> From: "Bao D. Nguyen" <quic_nguyenb@quicinc.com>
> > > >>>>>
> > > >>>>> Retrieve UFS device version from UFS host controller's spare register
> > > >>>>> which is populated by bootloader, and use the UFS device version together
> > > >>>>> with host controller's HW version to decide the proper power modes which
> > > >>>>> should be used to configure the UFS PHY.
> > > >>>> That sounds a bit fishy.. is there no bootloader-independent
> > > >>>> solution to that? Can't we bring in the code that the bootloader
> > > >>>> uses to determine these values?
> > > >>>>
> > > >>>> Konrad
> > > >>>
> > > >>> Agree, it is.
> > > >>>
> > > >>>
> > > >>> All these complexities come from one request from PHY design team - power saving.
> > > >>>
> > > >>> And to achieve power saving, Qualcomm UFS developers are requested to use the
> > > >>>
> > > >>> lowest hanging PHY settings which can sustain the Max agreed HS Gear (btw host
> > > >>>
> > > >>> and UFS device) during UFS's lifecycle in High Level OS,  whereas the power saving
> > > >>>
> > > >>> request does not apply to bootloader, which works for only a few seconds during
> > > >>>
> > > >>> bootup. Hence, there is no such version detect code in bootloader -  it just uses the
> > > >>>
> > > >>> highest PHY settings to configure PHY, boot up UFS and put UFS device version in this
> > > >>>
> > > >>> register.
> > > >> First of all, your email client seems to be inserting 2 newlines
> > > >> instead of 1. If you're using thunderbird, you may want to edit:
> > > >>
> > > >> mail.identity.(default or your mail identity idx).default.compose_html
> > > >>
> > > >> to `false`
> > > >>
> > > >> and add that to your internal wiki page, as I see many @quic folks having
> > > >> this issue.
> > > >>
> > > >>
> > > >> Going back to the main topic, I don't think we understood each other.
> > > >> The commit message states:
> > > >>
> > > >>
> > > >> "Retrieve UFS device version from UFS host controller's spare register
> > > >> which is populated by bootloader"
> > > >>
> > > >>
> > > >> Which means the bootloader is able to somehow determine the value
> > > >> that's in the spare register and write it there.
> > > >>
> > > >> I'm asking whether we can take the logic behind this value and
> > > >> move it to Linux so that we don't depend on the bootloader to
> > > >> guarantee it (e.g. Chrome or some other devices with more exotic
> > > >> fw may not work this way).
> > > >>
> > > >>
> > > >> Konrad
> > > >
> > > >
> > > >There is no logic behind this value at all in bootloader, as I explained, after bootloader
> > > >
> > > >initializes UFS, bootloader simply reads UFS's device version (the value you are referring)
> > > >
> > > >and write it to the register. But in Linux kernel, we need (or want to know) this value
> > > >
> > > >BEFORE we initialize UFS host controller (and UFS device).
> > >
> > > Depending on the bootloader behaviour is not an option. For example the kernel might be started via kexec. Or via u-boot. Or grub. Or any other bootloader. So please duplicate the logic to read the UFS version instead.
> > >
> >
> > As Can said, there is no logic in the bootloader. What it does it, after doing
> > the UFS initialization, it writes the agreed gear (between host and the device)
> > to this register. And in linux, we use that value to initialize the device
> > (i.e., not doing init based on the min gear).
> >
> > But the important factor here is that, we use this gear value to program the PHY
> > init sequence. So if there is no hint from the bootloader, linux will program
> > the min phy sequence (G3/G4) and then once the gear scaling happens, it will
> > program the max phy sequence (G4/G5).
> >
> > Now on recent platforms, the init sequences are not compatible with each other
> > i.e., once the min seq. is programmed, then before programming max seq. the
> > registers not common to both seq. should be programmed to default value. In
> > other words, min seq. specific registers should be reset to the default value.
> > Otherwise, there will be stability issues in the PHY.
> 
> I see nothing wrong with adding 'default' register programming to the
> gear tables. If we have to reset them to the default values to switch
> the PHY settings, these writes must be a part of the corresponding
> tables.
> 

Yep, that's what I initially proposed. But Qcom wanted to avoid the cost of
programming the reset tables in the PHY driver.

Can, could you please check if programming the additional sequence doesn't cause
any power/performance effect?

- Mani

> >
> > So to avoid that, if we get the hint from bootloader (always the max supported
> > gear between host and device), then only one seq. will be programmed.
> >
> > Other way to solve this issue is to reset the non common registers in the init
> > seq. to default value. But that will be an additional overhead.
> >
> > But... if the bootloader doesn't populate this register (if the boot device is
> > not UFS, like in compute platforms), then this whole logic won't work. This
> > should also be taken into consideration.
> 
> Yep, that's the dependency on the bootloader. Which we should avoid.
> 
> >
> > - Mani
> >
> > >
> > > P.S. you have been asked to fix your email client. Please do so. Or, if you are inserting these linebreaks manually, please stop.
> > >
> > > >Thanks,
> > > >
> > > >Can Guo.
> > > >
> > >
> >
> > --
> > மணிவண்ணன் சதாசிவம்
> 
> 
> 
> -- 
> With best wishes
> Dmitry

Dmitry Baryshkov Sept. 20, 2023, 11:13 a.m. UTC | #14

On Wed, 20 Sept 2023 at 13:23, Manivannan Sadhasivam <mani@kernel.org> wrote:
>
> On Wed, Sep 20, 2023 at 01:27:59AM +0300, Dmitry Baryshkov wrote:
> > On Tue, 19 Sept 2023 at 15:08, Manivannan Sadhasivam <mani@kernel.org> wrote:
> > >
> > > On Fri, Sep 15, 2023 at 05:31:45AM +0300, Dmitry Baryshkov wrote:
> > > > On 11 September 2023 13:02:50 GMT+03:00, Can Guo <quic_cang@quicinc.com> wrote:
> > > > >
> > > > >On 9/11/2023 5:46 PM, Konrad Dybcio wrote:
> > > > >> On 11.09.2023 11:42, Can Guo wrote:
> > > > >>> Hi Konrad,
> > > > >>>
> > > > >>> On 9/11/2023 5:17 PM, Konrad Dybcio wrote:
> > > > >>>> On 11.09.2023 07:59, Can Guo wrote:
> > > > >>>>> From: "Bao D. Nguyen" <quic_nguyenb@quicinc.com>
> > > > >>>>>
> > > > >>>>> Retrieve UFS device version from UFS host controller's spare register
> > > > >>>>> which is populated by bootloader, and use the UFS device version together
> > > > >>>>> with host controller's HW version to decide the proper power modes which
> > > > >>>>> should be used to configure the UFS PHY.
> > > > >>>> That sounds a bit fishy.. is there no bootloader-independent
> > > > >>>> solution to that? Can't we bring in the code that the bootloader
> > > > >>>> uses to determine these values?
> > > > >>>>
> > > > >>>> Konrad
> > > > >>>
> > > > >>> Agree, it is.
> > > > >>>
> > > > >>>
> > > > >>> All these complexities come from one request from PHY design team - power saving.
> > > > >>>
> > > > >>> And to achieve power saving, Qualcomm UFS developers are requested to use the
> > > > >>>
> > > > >>> lowest hanging PHY settings which can sustain the Max agreed HS Gear (btw host
> > > > >>>
> > > > >>> and UFS device) during UFS's lifecycle in High Level OS,  whereas the power saving
> > > > >>>
> > > > >>> request does not apply to bootloader, which works for only a few seconds during
> > > > >>>
> > > > >>> bootup. Hence, there is no such version detect code in bootloader -  it just uses the
> > > > >>>
> > > > >>> highest PHY settings to configure PHY, boot up UFS and put UFS device version in this
> > > > >>>
> > > > >>> register.
> > > > >> First of all, your email client seems to be inserting 2 newlines
> > > > >> instead of 1. If you're using thunderbird, you may want to edit:
> > > > >>
> > > > >> mail.identity.(default or your mail identity idx).default.compose_html
> > > > >>
> > > > >> to `false`
> > > > >>
> > > > >> and add that to your internal wiki page, as I see many @quic folks having
> > > > >> this issue.
> > > > >>
> > > > >>
> > > > >> Going back to the main topic, I don't think we understood each other.
> > > > >> The commit message states:
> > > > >>
> > > > >>
> > > > >> "Retrieve UFS device version from UFS host controller's spare register
> > > > >> which is populated by bootloader"
> > > > >>
> > > > >>
> > > > >> Which means the bootloader is able to somehow determine the value
> > > > >> that's in the spare register and write it there.
> > > > >>
> > > > >> I'm asking whether we can take the logic behind this value and
> > > > >> move it to Linux so that we don't depend on the bootloader to
> > > > >> guarantee it (e.g. Chrome or some other devices with more exotic
> > > > >> fw may not work this way).
> > > > >>
> > > > >>
> > > > >> Konrad
> > > > >
> > > > >
> > > > >There is no logic behind this value at all in bootloader, as I explained, after bootloader
> > > > >
> > > > >initializes UFS, bootloader simply reads UFS's device version (the value you are referring)
> > > > >
> > > > >and write it to the register. But in Linux kernel, we need (or want to know) this value
> > > > >
> > > > >BEFORE we initialize UFS host controller (and UFS device).
> > > >
> > > > Depending on the bootloader behaviour is not an option. For example the kernel might be started via kexec. Or via u-boot. Or grub. Or any other bootloader. So please duplicate the logic to read the UFS version instead.
> > > >
> > >
> > > As Can said, there is no logic in the bootloader. What it does it, after doing
> > > the UFS initialization, it writes the agreed gear (between host and the device)
> > > to this register. And in linux, we use that value to initialize the device
> > > (i.e., not doing init based on the min gear).
> > >
> > > But the important factor here is that, we use this gear value to program the PHY
> > > init sequence. So if there is no hint from the bootloader, linux will program
> > > the min phy sequence (G3/G4) and then once the gear scaling happens, it will
> > > program the max phy sequence (G4/G5).
> > >
> > > Now on recent platforms, the init sequences are not compatible with each other
> > > i.e., once the min seq. is programmed, then before programming max seq. the
> > > registers not common to both seq. should be programmed to default value. In
> > > other words, min seq. specific registers should be reset to the default value.
> > > Otherwise, there will be stability issues in the PHY.
> >
> > I see nothing wrong with adding 'default' register programming to the
> > gear tables. If we have to reset them to the default values to switch
> > the PHY settings, these writes must be a part of the corresponding
> > tables.
> >
>
> Yep, that's what I initially proposed. But Qcom wanted to avoid the cost of
> programming the reset tables in the PHY driver.

We should not be programming the whole reset table. Only those several
registers that are changed in the lowest settings.

>
> Can, could you please check if programming the additional sequence doesn't cause
> any power/performance effect?
>
> - Mani
>
> > >
> > > So to avoid that, if we get the hint from bootloader (always the max supported
> > > gear between host and device), then only one seq. will be programmed.
> > >
> > > Other way to solve this issue is to reset the non common registers in the init
> > > seq. to default value. But that will be an additional overhead.
> > >
> > > But... if the bootloader doesn't populate this register (if the boot device is
> > > not UFS, like in compute platforms), then this whole logic won't work. This
> > > should also be taken into consideration.
> >
> > Yep, that's the dependency on the bootloader. Which we should avoid.
> >
> > >
> > > - Mani
> > >
> > > >
> > > > P.S. you have been asked to fix your email client. Please do so. Or, if you are inserting these linebreaks manually, please stop.
> > > >
> > > > >Thanks,
> > > > >
> > > > >Can Guo.
> > > > >
> > > >
> > >
> > > --
> > > மணிவண்ணன் சதாசிவம்
> >
> >
> >
> > --
> > With best wishes
> > Dmitry
>
> --
> மணிவண்ணன் சதாசிவம்

Manivannan Sadhasivam Sept. 20, 2023, 11:51 a.m. UTC | #15

On Wed, Sep 20, 2023 at 02:13:13PM +0300, Dmitry Baryshkov wrote:
> On Wed, 20 Sept 2023 at 13:23, Manivannan Sadhasivam <mani@kernel.org> wrote:
> >
> > On Wed, Sep 20, 2023 at 01:27:59AM +0300, Dmitry Baryshkov wrote:
> > > On Tue, 19 Sept 2023 at 15:08, Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > >
> > > > On Fri, Sep 15, 2023 at 05:31:45AM +0300, Dmitry Baryshkov wrote:
> > > > > On 11 September 2023 13:02:50 GMT+03:00, Can Guo <quic_cang@quicinc.com> wrote:
> > > > > >
> > > > > >On 9/11/2023 5:46 PM, Konrad Dybcio wrote:
> > > > > >> On 11.09.2023 11:42, Can Guo wrote:
> > > > > >>> Hi Konrad,
> > > > > >>>
> > > > > >>> On 9/11/2023 5:17 PM, Konrad Dybcio wrote:
> > > > > >>>> On 11.09.2023 07:59, Can Guo wrote:
> > > > > >>>>> From: "Bao D. Nguyen" <quic_nguyenb@quicinc.com>
> > > > > >>>>>
> > > > > >>>>> Retrieve UFS device version from UFS host controller's spare register
> > > > > >>>>> which is populated by bootloader, and use the UFS device version together
> > > > > >>>>> with host controller's HW version to decide the proper power modes which
> > > > > >>>>> should be used to configure the UFS PHY.
> > > > > >>>> That sounds a bit fishy.. is there no bootloader-independent
> > > > > >>>> solution to that? Can't we bring in the code that the bootloader
> > > > > >>>> uses to determine these values?
> > > > > >>>>
> > > > > >>>> Konrad
> > > > > >>>
> > > > > >>> Agree, it is.
> > > > > >>>
> > > > > >>>
> > > > > >>> All these complexities come from one request from PHY design team - power saving.
> > > > > >>>
> > > > > >>> And to achieve power saving, Qualcomm UFS developers are requested to use the
> > > > > >>>
> > > > > >>> lowest hanging PHY settings which can sustain the Max agreed HS Gear (btw host
> > > > > >>>
> > > > > >>> and UFS device) during UFS's lifecycle in High Level OS,  whereas the power saving
> > > > > >>>
> > > > > >>> request does not apply to bootloader, which works for only a few seconds during
> > > > > >>>
> > > > > >>> bootup. Hence, there is no such version detect code in bootloader -  it just uses the
> > > > > >>>
> > > > > >>> highest PHY settings to configure PHY, boot up UFS and put UFS device version in this
> > > > > >>>
> > > > > >>> register.
> > > > > >> First of all, your email client seems to be inserting 2 newlines
> > > > > >> instead of 1. If you're using thunderbird, you may want to edit:
> > > > > >>
> > > > > >> mail.identity.(default or your mail identity idx).default.compose_html
> > > > > >>
> > > > > >> to `false`
> > > > > >>
> > > > > >> and add that to your internal wiki page, as I see many @quic folks having
> > > > > >> this issue.
> > > > > >>
> > > > > >>
> > > > > >> Going back to the main topic, I don't think we understood each other.
> > > > > >> The commit message states:
> > > > > >>
> > > > > >>
> > > > > >> "Retrieve UFS device version from UFS host controller's spare register
> > > > > >> which is populated by bootloader"
> > > > > >>
> > > > > >>
> > > > > >> Which means the bootloader is able to somehow determine the value
> > > > > >> that's in the spare register and write it there.
> > > > > >>
> > > > > >> I'm asking whether we can take the logic behind this value and
> > > > > >> move it to Linux so that we don't depend on the bootloader to
> > > > > >> guarantee it (e.g. Chrome or some other devices with more exotic
> > > > > >> fw may not work this way).
> > > > > >>
> > > > > >>
> > > > > >> Konrad
> > > > > >
> > > > > >
> > > > > >There is no logic behind this value at all in bootloader, as I explained, after bootloader
> > > > > >
> > > > > >initializes UFS, bootloader simply reads UFS's device version (the value you are referring)
> > > > > >
> > > > > >and write it to the register. But in Linux kernel, we need (or want to know) this value
> > > > > >
> > > > > >BEFORE we initialize UFS host controller (and UFS device).
> > > > >
> > > > > Depending on the bootloader behaviour is not an option. For example the kernel might be started via kexec. Or via u-boot. Or grub. Or any other bootloader. So please duplicate the logic to read the UFS version instead.
> > > > >
> > > >
> > > > As Can said, there is no logic in the bootloader. What it does it, after doing
> > > > the UFS initialization, it writes the agreed gear (between host and the device)
> > > > to this register. And in linux, we use that value to initialize the device
> > > > (i.e., not doing init based on the min gear).
> > > >
> > > > But the important factor here is that, we use this gear value to program the PHY
> > > > init sequence. So if there is no hint from the bootloader, linux will program
> > > > the min phy sequence (G3/G4) and then once the gear scaling happens, it will
> > > > program the max phy sequence (G4/G5).
> > > >
> > > > Now on recent platforms, the init sequences are not compatible with each other
> > > > i.e., once the min seq. is programmed, then before programming max seq. the
> > > > registers not common to both seq. should be programmed to default value. In
> > > > other words, min seq. specific registers should be reset to the default value.
> > > > Otherwise, there will be stability issues in the PHY.
> > >
> > > I see nothing wrong with adding 'default' register programming to the
> > > gear tables. If we have to reset them to the default values to switch
> > > the PHY settings, these writes must be a part of the corresponding
> > > tables.
> > >
> >
> > Yep, that's what I initially proposed. But Qcom wanted to avoid the cost of
> > programming the reset tables in the PHY driver.
> 
> We should not be programming the whole reset table. Only those several
> registers that are changed in the lowest settings.
> 

I was referring to "several registers" as the reset table. I should've been more
clear.

- Mani

> >
> > Can, could you please check if programming the additional sequence doesn't cause
> > any power/performance effect?
> >
> > - Mani
> >
> > > >
> > > > So to avoid that, if we get the hint from bootloader (always the max supported
> > > > gear between host and device), then only one seq. will be programmed.
> > > >
> > > > Other way to solve this issue is to reset the non common registers in the init
> > > > seq. to default value. But that will be an additional overhead.
> > > >
> > > > But... if the bootloader doesn't populate this register (if the boot device is
> > > > not UFS, like in compute platforms), then this whole logic won't work. This
> > > > should also be taken into consideration.
> > >
> > > Yep, that's the dependency on the bootloader. Which we should avoid.
> > >
> > > >
> > > > - Mani
> > > >
> > > > >
> > > > > P.S. you have been asked to fix your email client. Please do so. Or, if you are inserting these linebreaks manually, please stop.
> > > > >
> > > > > >Thanks,
> > > > > >
> > > > > >Can Guo.
> > > > > >
> > > > >
> > > >
> > > > --
> > > > மணிவண்ணன் சதாசிவம்
> > >
> > >
> > >
> > > --
> > > With best wishes
> > > Dmitry
> >
> > --
> > மணிவண்ணன் சதாசிவம்
> 
> 
> 
> -- 
> With best wishes
> Dmitry

Manivannan Sadhasivam Oct. 18, 2023, 12:47 p.m. UTC | #16

On Wed, Sep 20, 2023 at 12:23:27PM +0200, Manivannan Sadhasivam wrote:
> On Wed, Sep 20, 2023 at 01:27:59AM +0300, Dmitry Baryshkov wrote:
> > On Tue, 19 Sept 2023 at 15:08, Manivannan Sadhasivam <mani@kernel.org> wrote:
> > >
> > > On Fri, Sep 15, 2023 at 05:31:45AM +0300, Dmitry Baryshkov wrote:
> > > > On 11 September 2023 13:02:50 GMT+03:00, Can Guo <quic_cang@quicinc.com> wrote:
> > > > >
> > > > >On 9/11/2023 5:46 PM, Konrad Dybcio wrote:
> > > > >> On 11.09.2023 11:42, Can Guo wrote:
> > > > >>> Hi Konrad,
> > > > >>>
> > > > >>> On 9/11/2023 5:17 PM, Konrad Dybcio wrote:
> > > > >>>> On 11.09.2023 07:59, Can Guo wrote:
> > > > >>>>> From: "Bao D. Nguyen" <quic_nguyenb@quicinc.com>
> > > > >>>>>
> > > > >>>>> Retrieve UFS device version from UFS host controller's spare register
> > > > >>>>> which is populated by bootloader, and use the UFS device version together
> > > > >>>>> with host controller's HW version to decide the proper power modes which
> > > > >>>>> should be used to configure the UFS PHY.
> > > > >>>> That sounds a bit fishy.. is there no bootloader-independent
> > > > >>>> solution to that? Can't we bring in the code that the bootloader
> > > > >>>> uses to determine these values?
> > > > >>>>
> > > > >>>> Konrad
> > > > >>>
> > > > >>> Agree, it is.
> > > > >>>
> > > > >>>
> > > > >>> All these complexities come from one request from PHY design team - power saving.
> > > > >>>
> > > > >>> And to achieve power saving, Qualcomm UFS developers are requested to use the
> > > > >>>
> > > > >>> lowest hanging PHY settings which can sustain the Max agreed HS Gear (btw host
> > > > >>>
> > > > >>> and UFS device) during UFS's lifecycle in High Level OS,  whereas the power saving
> > > > >>>
> > > > >>> request does not apply to bootloader, which works for only a few seconds during
> > > > >>>
> > > > >>> bootup. Hence, there is no such version detect code in bootloader -  it just uses the
> > > > >>>
> > > > >>> highest PHY settings to configure PHY, boot up UFS and put UFS device version in this
> > > > >>>
> > > > >>> register.
> > > > >> First of all, your email client seems to be inserting 2 newlines
> > > > >> instead of 1. If you're using thunderbird, you may want to edit:
> > > > >>
> > > > >> mail.identity.(default or your mail identity idx).default.compose_html
> > > > >>
> > > > >> to `false`
> > > > >>
> > > > >> and add that to your internal wiki page, as I see many @quic folks having
> > > > >> this issue.
> > > > >>
> > > > >>
> > > > >> Going back to the main topic, I don't think we understood each other.
> > > > >> The commit message states:
> > > > >>
> > > > >>
> > > > >> "Retrieve UFS device version from UFS host controller's spare register
> > > > >> which is populated by bootloader"
> > > > >>
> > > > >>
> > > > >> Which means the bootloader is able to somehow determine the value
> > > > >> that's in the spare register and write it there.
> > > > >>
> > > > >> I'm asking whether we can take the logic behind this value and
> > > > >> move it to Linux so that we don't depend on the bootloader to
> > > > >> guarantee it (e.g. Chrome or some other devices with more exotic
> > > > >> fw may not work this way).
> > > > >>
> > > > >>
> > > > >> Konrad
> > > > >
> > > > >
> > > > >There is no logic behind this value at all in bootloader, as I explained, after bootloader
> > > > >
> > > > >initializes UFS, bootloader simply reads UFS's device version (the value you are referring)
> > > > >
> > > > >and write it to the register. But in Linux kernel, we need (or want to know) this value
> > > > >
> > > > >BEFORE we initialize UFS host controller (and UFS device).
> > > >
> > > > Depending on the bootloader behaviour is not an option. For example the kernel might be started via kexec. Or via u-boot. Or grub. Or any other bootloader. So please duplicate the logic to read the UFS version instead.
> > > >
> > >
> > > As Can said, there is no logic in the bootloader. What it does it, after doing
> > > the UFS initialization, it writes the agreed gear (between host and the device)
> > > to this register. And in linux, we use that value to initialize the device
> > > (i.e., not doing init based on the min gear).
> > >
> > > But the important factor here is that, we use this gear value to program the PHY
> > > init sequence. So if there is no hint from the bootloader, linux will program
> > > the min phy sequence (G3/G4) and then once the gear scaling happens, it will
> > > program the max phy sequence (G4/G5).
> > >
> > > Now on recent platforms, the init sequences are not compatible with each other
> > > i.e., once the min seq. is programmed, then before programming max seq. the
> > > registers not common to both seq. should be programmed to default value. In
> > > other words, min seq. specific registers should be reset to the default value.
> > > Otherwise, there will be stability issues in the PHY.
> > 
> > I see nothing wrong with adding 'default' register programming to the
> > gear tables. If we have to reset them to the default values to switch
> > the PHY settings, these writes must be a part of the corresponding
> > tables.
> > 
> 
> Yep, that's what I initially proposed. But Qcom wanted to avoid the cost of
> programming the reset tables in the PHY driver.
> 
> Can, could you please check if programming the additional sequence doesn't cause
> any power/performance effect?
> 

I'd like to simplify this conversion as there has been some misunderstanding.

First of all in linux, while probing the UFS device by the host controller, it
needs to use _some_ gear. So far we were using HS_G2 as that gear and using the
PHY init sequence of G3/G4 depending on the SoC. We do not need to use G2 init
sequence because, there are only 2 init sequences available for any SoC and
since the init sequences are backwards compatible, we mostly use the min init
sequence, G3/G4. Even though this incurs slight power consumption during boot,
the ufs host controller after probing the device will switch to max gear
supported by both entities. If that max is G4/G5, then the respective init
sequence will be programmed again.

Now the issue is, for the automotive usecases, switching the gears 2 times
during boot is affecting the boot KPI (Key Performance Inidicator). So the UFS
team came with the idea of populating a spare register in the bootloader with
the max gear info that the bootloader has already found out and using the same
in the linux for first time itself. This helps linux in using a single gear
during probe time.

This is what this patch is doing. If for some reason, that register is not
populated, then we default to the existing G2 gear and do init twice as the
driver is doing currently.

I hope this clarifies the intention of this patch.

- Mani

> - Mani
> 
> > >
> > > So to avoid that, if we get the hint from bootloader (always the max supported
> > > gear between host and device), then only one seq. will be programmed.
> > >
> > > Other way to solve this issue is to reset the non common registers in the init
> > > seq. to default value. But that will be an additional overhead.
> > >
> > > But... if the bootloader doesn't populate this register (if the boot device is
> > > not UFS, like in compute platforms), then this whole logic won't work. This
> > > should also be taken into consideration.
> > 
> > Yep, that's the dependency on the bootloader. Which we should avoid.
> > 
> > >
> > > - Mani
> > >
> > > >
> > > > P.S. you have been asked to fix your email client. Please do so. Or, if you are inserting these linebreaks manually, please stop.
> > > >
> > > > >Thanks,
> > > > >
> > > > >Can Guo.
> > > > >
> > > >
> > >
> > > --
> > > மணிவண்ணன் சதாசிவம்
> > 
> > 
> > 
> > -- 
> > With best wishes
> > Dmitry
> 
> -- 
> மணிவண்ணன் சதாசிவம்

Neil Armstrong Oct. 18, 2023, 2:02 p.m. UTC | #17

On 11/09/2023 07:59, Can Guo wrote:
> From: "Bao D. Nguyen" <quic_nguyenb@quicinc.com>
> 
> Retrieve UFS device version from UFS host controller's spare register
> which is populated by bootloader, and use the UFS device version together
> with host controller's HW version to decide the proper power modes which
> should be used to configure the UFS PHY.
> 
> Signed-off-by: Bao D. Nguyen <quic_nguyenb@quicinc.com>
> Signed-off-by: Can Guo <quic_cang@quicinc.com>
> ---
>   drivers/ufs/host/ufs-qcom.c | 30 +++++++++++++++++++++++-------
>   drivers/ufs/host/ufs-qcom.h |  2 ++
>   2 files changed, 25 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
> index 710f079..8a9d54f 100644
> --- a/drivers/ufs/host/ufs-qcom.c
> +++ b/drivers/ufs/host/ufs-qcom.c
> @@ -1030,7 +1030,7 @@ static void ufs_qcom_advertise_quirks(struct ufs_hba *hba)
>   				| UFSHCD_QUIRK_BROKEN_PA_RXHSUNTERMCAP);
>   	}
>   
> -	if (host->hw_ver.major > 0x3)
> +	if (host->hw_ver.major > 0x3 && host->hw_ver.major < 0x5)
>   		hba->quirks |= UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH;
>   }
>   
> @@ -1038,11 +1038,33 @@ static void ufs_qcom_set_pwr_mode_limits(struct ufs_hba *hba)
>   {
>   	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
>   	struct ufs_dev_params *host_pwr_cap = &host->host_pwr_cap;
> +	u32 val, dev_major = 0;
>   
>   	ufshcd_init_pwr_dev_param(host_pwr_cap);
>   
>   	/* This driver only supports symmetic gear setting i.e., hs_tx_gear == hs_rx_gear */
>   	host_pwr_cap->hs_tx_gear = host_pwr_cap->hs_rx_gear = ufs_qcom_get_hs_gear(hba);
> +	host->phy_gear = host_pwr_cap->hs_rx_gear;
> +
> +	if (host->hw_ver.major < 0x5) {

Here you set G2 for < 0x5

> +		/*
> +		 * Power up the PHY using the minimum supported gear (UFS_HS_G2).
> +		 * Switching to max gear will be performed during reinit if supported.
> +		 */
> +		host->phy_gear = UFS_HS_G2;
> +	} else {

So here is for >= 0x5

> +		val = ufshcd_readl(host->hba, REG_UFS_DEBUG_SPARE_CFG);
> +		dev_major = FIELD_GET(GENMASK(7, 4), val);
> +
> +		if (host->hw_ver.major == 0x5 && (dev_major >= 0x4 ||
> +						  dev_major == 0)) {
> +			/* For UFS 4.0 and newer, or dev version is not populated */
> +			host_pwr_cap->hs_rate = PA_HS_MODE_A;
> +		} else if (dev_major < 0x4 && dev_major > 0) {
> +			/* For UFS 3.1 and older, apply HS-G4 PHY settings to save power */
> +			host->phy_gear = UFS_HS_G4;
> +		}

But behavior of > 0x5 is not clear here, could you clarify it in v2 ?

Thanks,
Neil

> +	}
>   }
>   
>   static void ufs_qcom_set_caps(struct ufs_hba *hba)
> @@ -1287,12 +1309,6 @@ static int ufs_qcom_init(struct ufs_hba *hba)
>   		dev_warn(dev, "%s: failed to configure the testbus %d\n",
>   				__func__, err);
>   
> -	/*
> -	 * Power up the PHY using the minimum supported gear (UFS_HS_G2).
> -	 * Switching to max gear will be performed during reinit if supported.
> -	 */
> -	host->phy_gear = UFS_HS_G2;
> -
>   	return 0;
>   
>   out_variant_clear:
> diff --git a/drivers/ufs/host/ufs-qcom.h b/drivers/ufs/host/ufs-qcom.h
> index 4db64d9..e10889f 100644
> --- a/drivers/ufs/host/ufs-qcom.h
> +++ b/drivers/ufs/host/ufs-qcom.h
> @@ -56,6 +56,8 @@ enum {
>   	UFS_AH8_CFG				= 0xFC,
>   
>   	REG_UFS_CFG3				= 0x271C,
> +
> +	REG_UFS_DEBUG_SPARE_CFG			= 0x284C,
>   };
>   
>   /* QCOM UFS host controller vendor specific debug registers */

Konrad Dybcio Oct. 26, 2023, 7:31 p.m. UTC | #18

On 10/18/23 14:47, Manivannan Sadhasivam wrote:
> On Wed, Sep 20, 2023 at 12:23:27PM +0200, Manivannan Sadhasivam wrote:
>> On Wed, Sep 20, 2023 at 01:27:59AM +0300, Dmitry Baryshkov wrote:
>>> On Tue, 19 Sept 2023 at 15:08, Manivannan Sadhasivam <mani@kernel.org> wrote:
>>>>
>>>> On Fri, Sep 15, 2023 at 05:31:45AM +0300, Dmitry Baryshkov wrote:
>>>>> On 11 September 2023 13:02:50 GMT+03:00, Can Guo <quic_cang@quicinc.com> wrote:
>>>>>>
>>>>>> On 9/11/2023 5:46 PM, Konrad Dybcio wrote:
>>>>>>> On 11.09.2023 11:42, Can Guo wrote:
>>>>>>>> Hi Konrad,
>>>>>>>>
>>>>>>>> On 9/11/2023 5:17 PM, Konrad Dybcio wrote:
>>>>>>>>> On 11.09.2023 07:59, Can Guo wrote:
>>>>>>>>>> From: "Bao D. Nguyen" <quic_nguyenb@quicinc.com>
>>>>>>>>>>
>>>>>>>>>> Retrieve UFS device version from UFS host controller's spare register
>>>>>>>>>> which is populated by bootloader, and use the UFS device version together
>>>>>>>>>> with host controller's HW version to decide the proper power modes which
>>>>>>>>>> should be used to configure the UFS PHY.
>>>>>>>>> That sounds a bit fishy.. is there no bootloader-independent
>>>>>>>>> solution to that? Can't we bring in the code that the bootloader
>>>>>>>>> uses to determine these values?
>>>>>>>>>
>>>>>>>>> Konrad
>>>>>>>>
>>>>>>>> Agree, it is.
>>>>>>>>
>>>>>>>>
>>>>>>>> All these complexities come from one request from PHY design team - power saving.
>>>>>>>>
>>>>>>>> And to achieve power saving, Qualcomm UFS developers are requested to use the
>>>>>>>>
>>>>>>>> lowest hanging PHY settings which can sustain the Max agreed HS Gear (btw host
>>>>>>>>
>>>>>>>> and UFS device) during UFS's lifecycle in High Level OS,  whereas the power saving
>>>>>>>>
>>>>>>>> request does not apply to bootloader, which works for only a few seconds during
>>>>>>>>
>>>>>>>> bootup. Hence, there is no such version detect code in bootloader -  it just uses the
>>>>>>>>
>>>>>>>> highest PHY settings to configure PHY, boot up UFS and put UFS device version in this
>>>>>>>>
>>>>>>>> register.
>>>>>>> First of all, your email client seems to be inserting 2 newlines
>>>>>>> instead of 1. If you're using thunderbird, you may want to edit:
>>>>>>>
>>>>>>> mail.identity.(default or your mail identity idx).default.compose_html
>>>>>>>
>>>>>>> to `false`
>>>>>>>
>>>>>>> and add that to your internal wiki page, as I see many @quic folks having
>>>>>>> this issue.
>>>>>>>
>>>>>>>
>>>>>>> Going back to the main topic, I don't think we understood each other.
>>>>>>> The commit message states:
>>>>>>>
>>>>>>>
>>>>>>> "Retrieve UFS device version from UFS host controller's spare register
>>>>>>> which is populated by bootloader"
>>>>>>>
>>>>>>>
>>>>>>> Which means the bootloader is able to somehow determine the value
>>>>>>> that's in the spare register and write it there.
>>>>>>>
>>>>>>> I'm asking whether we can take the logic behind this value and
>>>>>>> move it to Linux so that we don't depend on the bootloader to
>>>>>>> guarantee it (e.g. Chrome or some other devices with more exotic
>>>>>>> fw may not work this way).
>>>>>>>
>>>>>>>
>>>>>>> Konrad
>>>>>>
>>>>>>
>>>>>> There is no logic behind this value at all in bootloader, as I explained, after bootloader
>>>>>>
>>>>>> initializes UFS, bootloader simply reads UFS's device version (the value you are referring)
>>>>>>
>>>>>> and write it to the register. But in Linux kernel, we need (or want to know) this value
>>>>>>
>>>>>> BEFORE we initialize UFS host controller (and UFS device).
>>>>>
>>>>> Depending on the bootloader behaviour is not an option. For example the kernel might be started via kexec. Or via u-boot. Or grub. Or any other bootloader. So please duplicate the logic to read the UFS version instead.
>>>>>
>>>>
>>>> As Can said, there is no logic in the bootloader. What it does it, after doing
>>>> the UFS initialization, it writes the agreed gear (between host and the device)
>>>> to this register. And in linux, we use that value to initialize the device
>>>> (i.e., not doing init based on the min gear).
>>>>
>>>> But the important factor here is that, we use this gear value to program the PHY
>>>> init sequence. So if there is no hint from the bootloader, linux will program
>>>> the min phy sequence (G3/G4) and then once the gear scaling happens, it will
>>>> program the max phy sequence (G4/G5).
>>>>
>>>> Now on recent platforms, the init sequences are not compatible with each other
>>>> i.e., once the min seq. is programmed, then before programming max seq. the
>>>> registers not common to both seq. should be programmed to default value. In
>>>> other words, min seq. specific registers should be reset to the default value.
>>>> Otherwise, there will be stability issues in the PHY.
>>>
>>> I see nothing wrong with adding 'default' register programming to the
>>> gear tables. If we have to reset them to the default values to switch
>>> the PHY settings, these writes must be a part of the corresponding
>>> tables.
>>>
>>
>> Yep, that's what I initially proposed. But Qcom wanted to avoid the cost of
>> programming the reset tables in the PHY driver.
>>
>> Can, could you please check if programming the additional sequence doesn't cause
>> any power/performance effect?
>>
> 
> I'd like to simplify this conversion as there has been some misunderstanding.
> 
> First of all in linux, while probing the UFS device by the host controller, it
> needs to use _some_ gear. So far we were using HS_G2 as that gear and using the
> PHY init sequence of G3/G4 depending on the SoC. We do not need to use G2 init
> sequence because, there are only 2 init sequences available for any SoC and
> since the init sequences are backwards compatible, we mostly use the min init
> sequence, G3/G4. Even though this incurs slight power consumption during boot,
> the ufs host controller after probing the device will switch to max gear
> supported by both entities. If that max is G4/G5, then the respective init
> sequence will be programmed again.
> 
> Now the issue is, for the automotive usecases, switching the gears 2 times
> during boot is affecting the boot KPI (Key Performance Inidicator). So the UFS
> team came with the idea of populating a spare register in the bootloader with
> the max gear info that the bootloader has already found out and using the same
> in the linux for first time itself. This helps linux in using a single gear
> during probe time.
> 
> This is what this patch is doing. If for some reason, that register is not
> populated, then we default to the existing G2 gear and do init twice as the
> driver is doing currently.
> 
> I hope this clarifies the intention of this patch.
Yes I understand this, but I am not sure if such tricks should make
it upstream.. They depend on specific firmware (unrelated to the hw
block itself) and only exist to improve boot times. If the firmware
requirement was not at play, I would have no issues with this.

Konrad

Bart Van Assche Oct. 26, 2023, 7:53 p.m. UTC | #19

On 9/10/23 22:59, Can Guo wrote:
> Having UFS power info available in sysfs makes it easier to tell the state
> of the link during runtime considering we have a bounch of power saving
> features and various combinations for backward compatiblity.

Since this patch introduces new sysfs attributes, it should include an
update for Documentation/ABI/testing/sysfs-driver-ufs.

Bart.

Manivannan Sadhasivam Oct. 27, 2023, 12:22 p.m. UTC | #20

On Thu, Oct 26, 2023 at 09:31:31PM +0200, Konrad Dybcio wrote:
> 
> 
> On 10/18/23 14:47, Manivannan Sadhasivam wrote:
> > On Wed, Sep 20, 2023 at 12:23:27PM +0200, Manivannan Sadhasivam wrote:
> > > On Wed, Sep 20, 2023 at 01:27:59AM +0300, Dmitry Baryshkov wrote:
> > > > On Tue, 19 Sept 2023 at 15:08, Manivannan Sadhasivam <mani@kernel.org> wrote:
> > > > > 
> > > > > On Fri, Sep 15, 2023 at 05:31:45AM +0300, Dmitry Baryshkov wrote:
> > > > > > On 11 September 2023 13:02:50 GMT+03:00, Can Guo <quic_cang@quicinc.com> wrote:
> > > > > > > 
> > > > > > > On 9/11/2023 5:46 PM, Konrad Dybcio wrote:
> > > > > > > > On 11.09.2023 11:42, Can Guo wrote:
> > > > > > > > > Hi Konrad,
> > > > > > > > > 
> > > > > > > > > On 9/11/2023 5:17 PM, Konrad Dybcio wrote:
> > > > > > > > > > On 11.09.2023 07:59, Can Guo wrote:
> > > > > > > > > > > From: "Bao D. Nguyen" <quic_nguyenb@quicinc.com>
> > > > > > > > > > > 
> > > > > > > > > > > Retrieve UFS device version from UFS host controller's spare register
> > > > > > > > > > > which is populated by bootloader, and use the UFS device version together
> > > > > > > > > > > with host controller's HW version to decide the proper power modes which
> > > > > > > > > > > should be used to configure the UFS PHY.
> > > > > > > > > > That sounds a bit fishy.. is there no bootloader-independent
> > > > > > > > > > solution to that? Can't we bring in the code that the bootloader
> > > > > > > > > > uses to determine these values?
> > > > > > > > > > 
> > > > > > > > > > Konrad
> > > > > > > > > 
> > > > > > > > > Agree, it is.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > All these complexities come from one request from PHY design team - power saving.
> > > > > > > > > 
> > > > > > > > > And to achieve power saving, Qualcomm UFS developers are requested to use the
> > > > > > > > > 
> > > > > > > > > lowest hanging PHY settings which can sustain the Max agreed HS Gear (btw host
> > > > > > > > > 
> > > > > > > > > and UFS device) during UFS's lifecycle in High Level OS,  whereas the power saving
> > > > > > > > > 
> > > > > > > > > request does not apply to bootloader, which works for only a few seconds during
> > > > > > > > > 
> > > > > > > > > bootup. Hence, there is no such version detect code in bootloader -  it just uses the
> > > > > > > > > 
> > > > > > > > > highest PHY settings to configure PHY, boot up UFS and put UFS device version in this
> > > > > > > > > 
> > > > > > > > > register.
> > > > > > > > First of all, your email client seems to be inserting 2 newlines
> > > > > > > > instead of 1. If you're using thunderbird, you may want to edit:
> > > > > > > > 
> > > > > > > > mail.identity.(default or your mail identity idx).default.compose_html
> > > > > > > > 
> > > > > > > > to `false`
> > > > > > > > 
> > > > > > > > and add that to your internal wiki page, as I see many @quic folks having
> > > > > > > > this issue.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Going back to the main topic, I don't think we understood each other.
> > > > > > > > The commit message states:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > "Retrieve UFS device version from UFS host controller's spare register
> > > > > > > > which is populated by bootloader"
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Which means the bootloader is able to somehow determine the value
> > > > > > > > that's in the spare register and write it there.
> > > > > > > > 
> > > > > > > > I'm asking whether we can take the logic behind this value and
> > > > > > > > move it to Linux so that we don't depend on the bootloader to
> > > > > > > > guarantee it (e.g. Chrome or some other devices with more exotic
> > > > > > > > fw may not work this way).
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Konrad
> > > > > > > 
> > > > > > > 
> > > > > > > There is no logic behind this value at all in bootloader, as I explained, after bootloader
> > > > > > > 
> > > > > > > initializes UFS, bootloader simply reads UFS's device version (the value you are referring)
> > > > > > > 
> > > > > > > and write it to the register. But in Linux kernel, we need (or want to know) this value
> > > > > > > 
> > > > > > > BEFORE we initialize UFS host controller (and UFS device).
> > > > > > 
> > > > > > Depending on the bootloader behaviour is not an option. For example the kernel might be started via kexec. Or via u-boot. Or grub. Or any other bootloader. So please duplicate the logic to read the UFS version instead.
> > > > > > 
> > > > > 
> > > > > As Can said, there is no logic in the bootloader. What it does it, after doing
> > > > > the UFS initialization, it writes the agreed gear (between host and the device)
> > > > > to this register. And in linux, we use that value to initialize the device
> > > > > (i.e., not doing init based on the min gear).
> > > > > 
> > > > > But the important factor here is that, we use this gear value to program the PHY
> > > > > init sequence. So if there is no hint from the bootloader, linux will program
> > > > > the min phy sequence (G3/G4) and then once the gear scaling happens, it will
> > > > > program the max phy sequence (G4/G5).
> > > > > 
> > > > > Now on recent platforms, the init sequences are not compatible with each other
> > > > > i.e., once the min seq. is programmed, then before programming max seq. the
> > > > > registers not common to both seq. should be programmed to default value. In
> > > > > other words, min seq. specific registers should be reset to the default value.
> > > > > Otherwise, there will be stability issues in the PHY.
> > > > 
> > > > I see nothing wrong with adding 'default' register programming to the
> > > > gear tables. If we have to reset them to the default values to switch
> > > > the PHY settings, these writes must be a part of the corresponding
> > > > tables.
> > > > 
> > > 
> > > Yep, that's what I initially proposed. But Qcom wanted to avoid the cost of
> > > programming the reset tables in the PHY driver.
> > > 
> > > Can, could you please check if programming the additional sequence doesn't cause
> > > any power/performance effect?
> > > 
> > 
> > I'd like to simplify this conversion as there has been some misunderstanding.
> > 
> > First of all in linux, while probing the UFS device by the host controller, it
> > needs to use _some_ gear. So far we were using HS_G2 as that gear and using the
> > PHY init sequence of G3/G4 depending on the SoC. We do not need to use G2 init
> > sequence because, there are only 2 init sequences available for any SoC and
> > since the init sequences are backwards compatible, we mostly use the min init
> > sequence, G3/G4. Even though this incurs slight power consumption during boot,
> > the ufs host controller after probing the device will switch to max gear
> > supported by both entities. If that max is G4/G5, then the respective init
> > sequence will be programmed again.
> > 
> > Now the issue is, for the automotive usecases, switching the gears 2 times
> > during boot is affecting the boot KPI (Key Performance Inidicator). So the UFS
> > team came with the idea of populating a spare register in the bootloader with
> > the max gear info that the bootloader has already found out and using the same
> > in the linux for first time itself. This helps linux in using a single gear
> > during probe time.
> > 
> > This is what this patch is doing. If for some reason, that register is not
> > populated, then we default to the existing G2 gear and do init twice as the
> > driver is doing currently.
> > 
> > I hope this clarifies the intention of this patch.
> Yes I understand this, but I am not sure if such tricks should make
> it upstream.. They depend on specific firmware (unrelated to the hw
> block itself) and only exist to improve boot times. If the firmware
> requirement was not at play, I would have no issues with this.
> 

I do not see any issue with depending on firmware writes to spare registers. As
I said, if that is not available, the patch will use the existing semantics.

There is no rule that says that the driver should _only_ depend on register
values populated by the hw. There are drivers in kernel that rely on firmware
configuration of registers.

For instance, BIOS may write to any PCIe config space registers and PCI core
will happily honor them. I do not see any difference between that and what this
patch does.

- Mani

> Konrad

Can Guo Oct. 31, 2023, 4:46 a.m. UTC | #21

Hi Bart,

On 10/27/2023 3:53 AM, Bart Van Assche wrote:
> On 9/10/23 22:59, Can Guo wrote:
>> Having UFS power info available in sysfs makes it easier to tell the 
>> state
>> of the link during runtime considering we have a bounch of power saving
>> features and various combinations for backward compatiblity.
>
> Since this patch introduces new sysfs attributes, it should include an
> update for Documentation/ABI/testing/sysfs-driver-ufs.
>
> Bart.

Yes, changes to Documentation/ABI/testing/sysfs-driver-ufs. is in below 
patch.

https://patchwork.kernel.org/project/linux-scsi/patch/1694411968-14413-7-git-send-email-quic_cang@quicinc.com/

I will address your comments and combine them two in one change and 
re-submit.

Thanks for your review.


Best Regards,

Can Guo.

Can Guo Oct. 31, 2023, 5:06 a.m. UTC | #22

Hi Neil,

On 10/27/2023 8:51 PM, Neil Armstrong wrote:
> On 18/10/2023 16:02, Neil Armstrong wrote:
>> On 11/09/2023 07:59, Can Guo wrote:
>>> From: "Bao D. Nguyen" <quic_nguyenb@quicinc.com>
>>>
>>> Retrieve UFS device version from UFS host controller's spare register
>>> which is populated by bootloader, and use the UFS device version 
>>> together
>>> with host controller's HW version to decide the proper power modes 
>>> which
>>> should be used to configure the UFS PHY.
>>>
>>> Signed-off-by: Bao D. Nguyen <quic_nguyenb@quicinc.com>
>>> Signed-off-by: Can Guo <quic_cang@quicinc.com>
>>> ---
>>>   drivers/ufs/host/ufs-qcom.c | 30 +++++++++++++++++++++++-------
>>>   drivers/ufs/host/ufs-qcom.h |  2 ++
>>>   2 files changed, 25 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
>>> index 710f079..8a9d54f 100644
>>> --- a/drivers/ufs/host/ufs-qcom.c
>>> +++ b/drivers/ufs/host/ufs-qcom.c
>>> @@ -1030,7 +1030,7 @@ static void ufs_qcom_advertise_quirks(struct 
>>> ufs_hba *hba)
>>>                   | UFSHCD_QUIRK_BROKEN_PA_RXHSUNTERMCAP);
>>>       }
>>> -    if (host->hw_ver.major > 0x3)
>>> +    if (host->hw_ver.major > 0x3 && host->hw_ver.major < 0x5)
>>>           hba->quirks |= UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH;
>>>   }
>>> @@ -1038,11 +1038,33 @@ static void 
>>> ufs_qcom_set_pwr_mode_limits(struct ufs_hba *hba)
>>>   {
>>>       struct ufs_qcom_host *host = ufshcd_get_variant(hba);
>>>       struct ufs_dev_params *host_pwr_cap = &host->host_pwr_cap;
>>> +    u32 val, dev_major = 0;
>>>       ufshcd_init_pwr_dev_param(host_pwr_cap);
>>>       /* This driver only supports symmetic gear setting i.e., 
>>> hs_tx_gear == hs_rx_gear */
>>>       host_pwr_cap->hs_tx_gear = host_pwr_cap->hs_rx_gear = 
>>> ufs_qcom_get_hs_gear(hba);
>>> +    host->phy_gear = host_pwr_cap->hs_rx_gear;
>>> +
>>> +    if (host->hw_ver.major < 0x5) {
>>
>> Here you set G2 for < 0x5
>>
>>> +        /*
>>> +         * Power up the PHY using the minimum supported gear 
>>> (UFS_HS_G2).
>>> +         * Switching to max gear will be performed during reinit if 
>>> supported.
>>> +         */
>>> +        host->phy_gear = UFS_HS_G2;
>>> +    } else {
>>
>> So here is for >= 0x5
>>
>>> +        val = ufshcd_readl(host->hba, REG_UFS_DEBUG_SPARE_CFG);
>>> +        dev_major = FIELD_GET(GENMASK(7, 4), val);
>>> +
>>> +        if (host->hw_ver.major == 0x5 && (dev_major >= 0x4 ||
>>> +                          dev_major == 0)) {
>>> +            /* For UFS 4.0 and newer, or dev version is not 
>>> populated */
>>> +            host_pwr_cap->hs_rate = PA_HS_MODE_A;
>>> +        } else if (dev_major < 0x4 && dev_major > 0) {
>>> +            /* For UFS 3.1 and older, apply HS-G4 PHY settings to 
>>> save power */
>>> +            host->phy_gear = UFS_HS_G4;
>>> +        }
>>
>> But behavior of > 0x5 is not clear here, could you clarify it in v2 ?
>
> Now SM8650 is public, could you update it for v2 ?

For HWs whose hw_ver.major is > 0x5, say SM8650, initially phy_gear == 
host_pwr_cap->hs_rx_gear, which is HS_G5.

If a UFS3.x or older UFS device is connected, we overwrite phy_gear as 
HS_G4. I don't see an impact to SM8650.

Please let me know if I misunderstand anything here.


Thanks,

Can Guo.

>
> Thanks,
> Neil
>
>>
>> Thanks,
>> Neil
>

Can Guo Oct. 31, 2023, 8:08 a.m. UTC | #23

Hi Mani,

On 9/19/2023 8:16 PM, Manivannan Sadhasivam wrote:
> On Sun, Sep 10, 2023 at 10:59:26PM -0700, Can Guo wrote:
>> Having UFS power info available in sysfs makes it easier to tell the state
>> of the link during runtime considering we have a bounch of power saving
>> features and various combinations for backward compatiblity.
>>
> Please move the sysfs patches to a separate series.
>
> - Mani

Sure.


Thanks,

Can Guo.

Neil Armstrong Oct. 31, 2023, 9:30 a.m. UTC | #24

Hi,

On 31/10/2023 06:06, Can Guo wrote:
> Hi Neil,
> 
> On 10/27/2023 8:51 PM, Neil Armstrong wrote:
>> On 18/10/2023 16:02, Neil Armstrong wrote:
>>> On 11/09/2023 07:59, Can Guo wrote:
>>>> From: "Bao D. Nguyen" <quic_nguyenb@quicinc.com>
>>>>
>>>> Retrieve UFS device version from UFS host controller's spare register
>>>> which is populated by bootloader, and use the UFS device version together
>>>> with host controller's HW version to decide the proper power modes which
>>>> should be used to configure the UFS PHY.
>>>>
>>>> Signed-off-by: Bao D. Nguyen <quic_nguyenb@quicinc.com>
>>>> Signed-off-by: Can Guo <quic_cang@quicinc.com>
>>>> ---
>>>>   drivers/ufs/host/ufs-qcom.c | 30 +++++++++++++++++++++++-------
>>>>   drivers/ufs/host/ufs-qcom.h |  2 ++
>>>>   2 files changed, 25 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
>>>> index 710f079..8a9d54f 100644
>>>> --- a/drivers/ufs/host/ufs-qcom.c
>>>> +++ b/drivers/ufs/host/ufs-qcom.c
>>>> @@ -1030,7 +1030,7 @@ static void ufs_qcom_advertise_quirks(struct ufs_hba *hba)
>>>>                   | UFSHCD_QUIRK_BROKEN_PA_RXHSUNTERMCAP);
>>>>       }
>>>> -    if (host->hw_ver.major > 0x3)
>>>> +    if (host->hw_ver.major > 0x3 && host->hw_ver.major < 0x5)
>>>>           hba->quirks |= UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH;
>>>>   }
>>>> @@ -1038,11 +1038,33 @@ static void ufs_qcom_set_pwr_mode_limits(struct ufs_hba *hba)
>>>>   {
>>>>       struct ufs_qcom_host *host = ufshcd_get_variant(hba);
>>>>       struct ufs_dev_params *host_pwr_cap = &host->host_pwr_cap;
>>>> +    u32 val, dev_major = 0;
>>>>       ufshcd_init_pwr_dev_param(host_pwr_cap);
>>>>       /* This driver only supports symmetic gear setting i.e., hs_tx_gear == hs_rx_gear */
>>>>       host_pwr_cap->hs_tx_gear = host_pwr_cap->hs_rx_gear = ufs_qcom_get_hs_gear(hba);
>>>> +    host->phy_gear = host_pwr_cap->hs_rx_gear;
>>>> +
>>>> +    if (host->hw_ver.major < 0x5) {
>>>
>>> Here you set G2 for < 0x5
>>>
>>>> +        /*
>>>> +         * Power up the PHY using the minimum supported gear (UFS_HS_G2).
>>>> +         * Switching to max gear will be performed during reinit if supported.
>>>> +         */
>>>> +        host->phy_gear = UFS_HS_G2;
>>>> +    } else {
>>>
>>> So here is for >= 0x5
>>>
>>>> +        val = ufshcd_readl(host->hba, REG_UFS_DEBUG_SPARE_CFG);
>>>> +        dev_major = FIELD_GET(GENMASK(7, 4), val);
>>>> +
>>>> +        if (host->hw_ver.major == 0x5 && (dev_major >= 0x4 ||
>>>> +                          dev_major == 0)) {
>>>> +            /* For UFS 4.0 and newer, or dev version is not populated */
>>>> +            host_pwr_cap->hs_rate = PA_HS_MODE_A;
>>>> +        } else if (dev_major < 0x4 && dev_major > 0) {
>>>> +            /* For UFS 3.1 and older, apply HS-G4 PHY settings to save power */
>>>> +            host->phy_gear = UFS_HS_G4;
>>>> +        }
>>>
>>> But behavior of > 0x5 is not clear here, could you clarify it in v2 ?
>>
>> Now SM8650 is public, could you update it for v2 ?
> 
> For HWs whose hw_ver.major is > 0x5, say SM8650, initially phy_gear == host_pwr_cap->hs_rx_gear, which is HS_G5.
> 
> If a UFS3.x or older UFS device is connected, we overwrite phy_gear as HS_G4. I don't see an impact to SM8650.
> 
> Please let me know if I misunderstand anything here.

It's clear now, please add this in a comment when you send a v2,

Thanks,
Neil

> 
> 
> Thanks,
> 
> Can Guo.
> 
>>
>> Thanks,
>> Neil
>>
>>>
>>> Thanks,
>>> Neil
>>

Can Guo Oct. 31, 2023, 1:09 p.m. UTC | #25

Hi Mani,

On 9/19/2023 6:36 PM, Manivannan Sadhasivam wrote:
> On Sun, Sep 10, 2023 at 10:59:22PM -0700, Can Guo wrote:
>> Setup host power mode and its limitations during UFS host driver init to
>> avoid repetitive work during every power mode change.
>>
>> Co-developed-by: Bao D. Nguyen <quic_nguyenb@quicinc.com>
>> Signed-off-by: Can Guo <quic_cang@quicinc.com>
>> Signed-off-by: Bao D. Nguyen <quic_nguyenb@quicinc.com>
>> ---
>>   drivers/ufs/host/ufs-qcom.c | 27 ++++++++++++++++++---------
>>   drivers/ufs/host/ufs-qcom.h |  1 +
>>   2 files changed, 19 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/ufs/host/ufs-qcom.c b/drivers/ufs/host/ufs-qcom.c
>> index c3215d3..710f079 100644
>> --- a/drivers/ufs/host/ufs-qcom.c
>> +++ b/drivers/ufs/host/ufs-qcom.c
>> @@ -443,7 +443,11 @@ static u32 ufs_qcom_get_hs_gear(struct ufs_hba *hba)
>>   static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
>>   {
>>   	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
>> +	struct ufs_dev_params *host_pwr_cap = &host->host_pwr_cap;
>>   	struct phy *phy = host->generic_phy;
>> +	enum phy_mode mode = host_pwr_cap->hs_rate == PA_HS_MODE_B ?
>> +							PHY_MODE_UFS_HS_B :
>> +							PHY_MODE_UFS_HS_A;
> I do not see anyone passing PA_HS_MODE_A in this patch, so this change is not
> required now. If you are doing this as a preparatory work, please do it in a
> separate patch.
Sure.
>
>>   	int ret;
>>   
>>   	/* Reset UFS Host Controller and PHY */
>> @@ -460,7 +464,7 @@ static int ufs_qcom_power_up_sequence(struct ufs_hba *hba)
>>   		return ret;
>>   	}
>>   
>> -	phy_set_mode_ext(phy, PHY_MODE_UFS_HS_B, host->phy_gear);
>> +	phy_set_mode_ext(phy, mode, host->phy_gear);
> Same as above.
Sure.
>
>>   
>>   	/* power on phy - start serdes and phy's power and clocks */
>>   	ret = phy_power_on(phy);
>> @@ -884,7 +888,6 @@ static int ufs_qcom_pwr_change_notify(struct ufs_hba *hba,
>>   				struct ufs_pa_layer_attr *dev_req_params)
>>   {
>>   	struct ufs_qcom_host *host = ufshcd_get_variant(hba);
>> -	struct ufs_dev_params ufs_qcom_cap;
>>   	int ret = 0;
>>   
>>   	if (!dev_req_params) {
>> @@ -894,13 +897,7 @@ static int ufs_qcom_pwr_change_notify(struct ufs_hba *hba,
>>   
>>   	switch (status) {
>>   	case PRE_CHANGE:
>> -		ufshcd_init_pwr_dev_param(&ufs_qcom_cap);
>> -		ufs_qcom_cap.hs_rate = UFS_QCOM_LIMIT_HS_RATE;
>> -
>> -		/* This driver only supports symmetic gear setting i.e., hs_tx_gear == hs_rx_gear */
>> -		ufs_qcom_cap.hs_tx_gear = ufs_qcom_cap.hs_rx_gear = ufs_qcom_get_hs_gear(hba);
>> -
>> -		ret = ufshcd_get_pwr_dev_param(&ufs_qcom_cap,
>> +		ret = ufshcd_get_pwr_dev_param(&host->host_pwr_cap,
>>   					       dev_max_params,
>>   					       dev_req_params);
>>   		if (ret) {
>> @@ -1037,6 +1034,17 @@ static void ufs_qcom_advertise_quirks(struct ufs_hba *hba)
>>   		hba->quirks |= UFSHCD_QUIRK_REINIT_AFTER_MAX_GEAR_SWITCH;
>>   }
>>   
>> +static void ufs_qcom_set_pwr_mode_limits(struct ufs_hba *hba)
> It's good that you are moving the setting to init() as they are static, but I'm
> worried about the different naming conventions used all over the place.
>
> The intention here is to set host parameters and then get the agreed one between
> host and the device. But different names are being used. The structure itself is
> named as "ufs_dev_params" even though it targets host and the vendor drivers are
> naming it as "ufs_<vendor>_cap" or "host_cap". And now you've given a new name,
> "host_pwr_cap", which makes things even worse.
>
> So we should rename the struct itself as "ufs_host_params" and all the vendor
> drivers should stick to "host_params".

I like the name 'ufs_host_params', will unify the declaration of it in 
all vendor drivers in next version.


Thanks,

Can Guo.

[0/6] Enable HS-G5 support on SM8550

Message

Comments