Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Can Guo <quic_cang@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Manivannan Sadhasivam <mani@kernel.org>,
	Can Guo <cang@qti.qualcomm.com>, <bvanassche@acm.org>,
	<stanley.chu@mediatek.com>, <adrian.hunter@intel.com>,
	<beanhuo@micron.com>, <avri.altman@wdc.com>,
	<junwoo80.lee@samsung.com>, <martin.petersen@oracle.com>,
	<linux-scsi@vger.kernel.org>, Andy Gross <agross@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Vinod Koul <vkoul@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"open list:ARM/QUALCOMM SUPPORT" <linux-arm-msm@vger.kernel.org>,
	"open list:GENERIC PHY FRAMEWORK" <linux-phy@lists.infradead.org>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 6/7] phy: qualcomm: phy-qcom-qmp-ufs: Add High Speed Gear 5 support for SM8550
Date: Wed, 15 Nov 2023 15:51:37 +0800	[thread overview]
Message-ID: <21ab3a8e-fb94-4628-b24c-bd7b28666dd8@quicinc.com> (raw)
In-Reply-To: <CAA8EJppXg1S_L2dkts5UWLW2z2q9i8vf3bpK9Fdk9_W_BprWzQ@mail.gmail.com>



On 11/14/2023 5:15 PM, Dmitry Baryshkov wrote:
> On Sun, 12 Nov 2023 at 07:13, Can Guo <quic_cang@quicinc.com> wrote:
>>
>> Hi Mani,
>>
>> On 11/11/2023 12:12 PM, Manivannan Sadhasivam wrote:
>>> On Fri, Nov 10, 2023 at 10:40:53PM +0800, Can Guo wrote:
>>>>
>>>>
>>>> On 11/10/2023 9:18 PM, Manivannan Sadhasivam wrote:
>>>>> On Fri, Nov 10, 2023 at 12:11:46AM +0200, Dmitry Baryshkov wrote:
>>>>>> On Thu, 9 Nov 2023 at 18:04, Manivannan Sadhasivam <mani@kernel.org> wrote:
>>>>>>>
>>>>>>> On Thu, Nov 09, 2023 at 01:00:51PM +0200, Dmitry Baryshkov wrote:
>>>>>>>> On Thu, 9 Nov 2023 at 12:43, Manivannan Sadhasivam <mani@kernel.org> wrote:
>>>>>>>>>
>>>>>>>>> On Thu, Nov 09, 2023 at 11:40:51AM +0200, Dmitry Baryshkov wrote:
>>>>>>>>>> On Thu, 9 Nov 2023 at 05:24, Manivannan Sadhasivam <mani@kernel.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Nov 08, 2023 at 08:56:16AM +0200, Dmitry Baryshkov wrote:
>>>>>>>>>>>> On Wed, 8 Nov 2023 at 07:49, Manivannan Sadhasivam <mani@kernel.org> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Nov 07, 2023 at 03:18:09PM +0200, Dmitry Baryshkov wrote:
>>>>>>>>>>>>>> On Tue, 7 Nov 2023 at 06:47, Can Guo <cang@qti.qualcomm.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> From: Can Guo <quic_cang@quicinc.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On SM8550, two sets of UFS PHY settings are provided, one set is to support
>>>>>>>>>>>>>>> HS-G5, another set is to support HS-G4 and lower gears. The two sets of PHY
>>>>>>>>>>>>>>> settings are programming different values to different registers, mixing
>>>>>>>>>>>>>>> the two sets and/or overwriting one set with another set is definitely not
>>>>>>>>>>>>>>> blessed by UFS PHY designers. In order to add HS-G5 support for SM8550, we
>>>>>>>>>>>>>>> need to split the two sets into their dedicated tables, and leave only the
>>>>>>>>>>>>>>> common settings in the .tlbs. To have the PHY programmed with the correct
>>>>>>>>>>>>>>> set of PHY settings, the submode passed to PHY driver must be either HS-G4
>>>>>>>>>>>>>>> or HS-G5.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You should also mention that this issue is also present in G4 supported targets.
>>>>>>>>>>>>> And a note that it will get fixed later.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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 3927eba..e0a01497 100644
>>>>>>>>>>>>>>> --- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
>>>>>>>>>>>>>>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
>>>>>>>>>>>>>>> @@ -649,32 +649,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),
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Aside from moving these registers to the HS_G4 table, you are also
>>>>>>>>>>>>>> changing these registers. It makes me think that there was an error in
>>>>>>>>>>>>>> the original programming sequence.
>>>>>>>>>>>>>> If that is correct, could you please split the patch into two pieces:
>>>>>>>>>>>>>> - Fix programming sequence (add proper Fixes tags)
>>>>>>>>>>>>>> - Split G4 and G5 tables.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ack
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>> +       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),
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I see all the MODE1 registers being only present in G4 and G5 tables.
>>>>>>>>>>>>>> Should they be programmed for the modes lower than G4?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> We use G4 table for all the modes <= G4.
>>>>>>>>>>>>
>>>>>>>>>>>> Could you please point me how it's handled?
>>>>>>>>>>>> In the patch I see just:
>>>>>>>>>>>>
>>>>>>>>>>>>           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);
>>>>>>>>>>>>
>>>>>>>>>>>> Which looks like two special cases (HS_G4 and HS_G5) and nothing for
>>>>>>>>>>>> anything else.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes, and the UFS driver passes only G4/G5. For all the gears <=G4, G4 init
>>>>>>>>>>> sequence will be used and for G5, G5 sequence will be used.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That's what I could not find in the UFS driver. I see a call to
>>>>>>>>>> `phy_set_mode_ext(phy, PHY_MODE_UFS_HS_B, host->phy_gear);` and
>>>>>>>>>> host->phy_gear is initialised to UFS_HS_G2.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You need to check the UFS driver changes in this series to get the complete
>>>>>>>>> picture as the logic is getting changed.
>>>>>>>>>
>>>>>>>>> It is common to get confused because of the way the UFS driver (qcom mostly)
>>>>>>>>> handles the PHY init sequence programming. We used to have only one init
>>>>>>>>> sequence for older targets and life was easy. But when I wanted to add G4
>>>>>>>>> support for SM8250, I learned that there are 2 separate init sequences. One for
>>>>>>>>> non-G4 and other for G4. So I used the phy_sub_mode property to pass the
>>>>>>>>> relevant mode from the UFS driver to the PHY driver and programmed the sequence
>>>>>>>>> accordingly. This got extended to non-G5 and G5 now.
>>>>>>>>>
>>>>>>>>> Now, the UFS driver will start probing from a low gear for older targets (G2)
>>>>>>>>> and G4/G5 for newer ones then scale up based on the device and host capability.
>>>>>>>>> For older targets, the common table (tbls) will be used if the submode doesn't
>>>>>>>>> match G4/G5. But for newer targets, the UFS driver will _only_ pass G4 or G5 as
>>>>>>>>> the phy_gear, so those specific sequence will only be used.
>>>>>>>>>
>>>>>>>>> Hope I'm clear.
>>>>>>>>
>>>>>>>> Yes, it is now clear, thank you!
>>>>>>>>
>>>>>>>> Would it be possible / feasible / logical to maintain this idea even
>>>>>>>> for newer platforms (leaving the HS_A  / HS_B aside)?
>>>>>>>>
>>>>>>>> tbls - works for HS_G2
>>>>>>>> tbls + tbls_g4 - works for HS_G4
>>>>>>>> tbls + tbls_g5 - works for HS_G5
>>>>>>>>
>>>>>>>
>>>>>>> No. The PHY team only gives 2 init sequences for any SoC now.
>>>>>>
>>>>>> Ack. Then the code should become
>>>>>> if (HS_G5)
>>>>>>       program(tbls_hs_g5)
>>>>>> else
>>>>>>       program(tbls_hs_g4);
>>>>>>
>>>>>
>>>>> This should work. Even if we have to accomodate G6 in the future, we can use
>>>>> "else if" for that and keep G4 as the "else" condition. This logic can also be
>>>>> optimized in the future.
>>>>
>>>> That would make dual init meaningless for old targets. Say on SM8450, the
>>>> initial PHY gear is G2, with the "else" condition, during the first init, G4
>>>> table would be programmed, then gear negotiation happens btw host and device
>>>> and the negotiated gear is G3 (assume a UFS2.x is connected). During the 2nd
>>>> init, the "else" condition would __again__ program the G4 table - it is not
>>>> programming the non-G4 table for power saving. The dual init is supposed to
>>>> find the optimal PHY settings, but the "else" condition is programming G4
>>>> table unconditinally.
>>>>
>>>> With the original code change in this patch, the dual init works as it is
>>>> for old targets. say SM8450, the initial PHY gear is G2, during the 2nd
>>>> init, it is programming the non-G4 table (assume a UFS2.x is connected), but
>>>> not the G4 table.
>>>>
>>>
>>> You are right. I completely overlooked the compatibility for old targets. But
>>> still we can move the common table to the "else" condition. This makes it clear
>>> that one of the 3 will be programmed at a time. But with the current logic, I
>>> get the impression that common table is overridden by G4/G5 tables.
>>>
>>> So this is what I'm suggesting:
>>>
>>> if (HS_G5)
>>>        program(tbls_hs_g5)
>>> else if (HS_G4)
>>>        program(tbls_hs_g4);
>>> else
>>>        program(tbls_hs_common);
>>>
>>
>> Common table is needed regardlessly, we cannot put it in "else",
>> otherwise it would break all targets -
>>
>> On old targets (no G5 supported):
>> Common table            - supports non-G4 (G3 and lower)
>> Common table + G4 table - supports G4
>>
>> On new targets (G5 supported):
>> Common table            - supports nothing, as it is just common parts of G4
>> table and G5 table.
>> Common table + G4 table - support non-G5 (G4 and lower)
>> Common table + G5 table - support G5
> 
> There is one issue with this approach, which you might be able to fix.
> For the older PHYs we have two cases: pre-G4 and G4. The host driver
> can set any mode of its choice.
> For the newer targets we only support G4 and G5 modes, don't we?
> However the knowledge that there will be no modes lower than G4 is
> hidden inside the host driver.
> Could you please add a flag / condition to the PHY driver to error out
> if the host tries to set e.g. G2 for the newer PHYs?
> 

I will propose a fix for this once for all in next version.

Thanks,
Can Guo.

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

  reply	other threads:[~2023-11-15  7:52 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1699332374-9324-1-git-send-email-cang@qti.qualcomm.com>
2023-11-07  4:46 ` [PATCH v2 6/7] phy: qualcomm: phy-qcom-qmp-ufs: Add High Speed Gear 5 support for SM8550 Can Guo
2023-11-07 13:18   ` Dmitry Baryshkov
2023-11-08  5:49     ` Manivannan Sadhasivam
2023-11-08  6:56       ` Dmitry Baryshkov
2023-11-09  3:24         ` Manivannan Sadhasivam
2023-11-09  9:40           ` Dmitry Baryshkov
2023-11-09 10:42             ` Manivannan Sadhasivam
2023-11-09 11:00               ` Dmitry Baryshkov
2023-11-09 16:04                 ` Manivannan Sadhasivam
2023-11-09 22:11                   ` Dmitry Baryshkov
2023-11-10 13:18                     ` Manivannan Sadhasivam
2023-11-10 14:40                       ` Can Guo
2023-11-11  4:12                         ` Manivannan Sadhasivam
2023-11-12  5:13                           ` Can Guo
2023-11-14  6:12                             ` Manivannan Sadhasivam
2023-11-14  9:15                             ` Dmitry Baryshkov
2023-11-15  7:51                               ` Can Guo [this message]
2023-11-08  9:19       ` Can Guo
2023-11-09  3:26         ` Manivannan Sadhasivam
2023-11-08  9:02     ` Can Guo
2023-11-10  8:47   ` neil.armstrong
2023-11-10  9:03     ` Can Guo
2023-11-10  9:17       ` neil.armstrong
2023-11-10  9:32         ` Can Guo
2023-11-10  9:35           ` neil.armstrong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21ab3a8e-fb94-4628-b24c-bd7b28666dd8@quicinc.com \
    --to=quic_cang@quicinc.com \
    --cc=adrian.hunter@intel.com \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=avri.altman@wdc.com \
    --cc=beanhuo@micron.com \
    --cc=bvanassche@acm.org \
    --cc=cang@qti.qualcomm.com \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=junwoo80.lee@samsung.com \
    --cc=kishon@kernel.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=stanley.chu@mediatek.com \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox