lkml.org 
[lkml]   [2022]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [v3 2/3] phy: qcom-snps: Add support for overriding phy tuning parameters
From

On 5/9/2022 8:48 AM, Pavan Kondeti wrote:
> Hi Krishna,
>
> On Sun, May 08, 2022 at 05:42:26PM +0530, Krishna Kurapati wrote:
>> Add support for overriding electrical signal tuning parameters for
>> SNPS HS Phy.
>>
>> Signed-off-by: Krishna Kurapati <quic_kriskura@quicinc.com>
>> ---
>> drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c | 252 +++++++++++++++++++++++++-
>> 1 file changed, 250 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
>> index 5d20378..bed2c90 100644
>> --- a/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
>> +++ b/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.c
>> @@ -52,6 +52,12 @@
>> #define USB2_SUSPEND_N BIT(2)
>> #define USB2_SUSPEND_N_SEL BIT(3)
>>
>> +#define USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X0 (0x6c)
>> +#define USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X1 (0x70)
>> +#define USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X2 (0x74)
>> +#define USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X3 (0x78)
>> +#define PARAM_OVRD_MASK 0xFF
>> +
>> #define USB2_PHY_USB_PHY_CFG0 (0x94)
>> #define UTMI_PHY_DATAPATH_CTRL_OVERRIDE_EN BIT(0)
>> #define UTMI_PHY_CMN_CTRL_OVERRIDE_EN BIT(1)
>> @@ -60,6 +66,16 @@
>> #define REFCLK_SEL_MASK GENMASK(1, 0)
>> #define REFCLK_SEL_DEFAULT (0x2 << 0)
>>
>> +#define HS_DISCONNECT_MASK GENMASK(2, 0)
>> +#define SQUELCH_DETECTOR_MASK GENMASK(7, 5)
>> +#define HS_AMPLITUDE_MASK GENMASK(3, 0)
>> +#define PREEMPHASIS_DURATION_MASK BIT(5)
>> +#define PREEMPHASIS_AMPLITUDE_MASK GENMASK(7, 6)
>> +#define HS_RISE_FALL_MASK GENMASK(1, 0)
>> +#define HS_CROSSOVER_VOLTAGE_MASK GENMASK(3, 2)
>> +#define HS_OUTPUT_IMPEDANCE_MASK GENMASK(5, 4)
>> +#define LS_FS_OUTPUT_IMPEDANCE_MASK GENMASK(3, 0)
>> +
> LGTM. All these definitions are matching with the databook.
>
>> static const char * const qcom_snps_hsphy_vreg_names[] = {
>> "vdda-pll", "vdda33", "vdda18",
>> };
>> @@ -173,10 +189,195 @@ static int qcom_snps_hsphy_set_mode(struct phy *phy, enum phy_mode mode,
>> return 0;
>> }
>>
>> +struct override_param {
>> + s32 value;
>> + u8 reg;
>> +};
>> +
>> +#define OVERRIDE_PARAM(bps, val)\
>> +{ \
>> + .value = bps, \
>> + .reg = val, \
>> +}
>> +
>> +struct override_param_map {
>> + struct override_param *param_table;
>> + u8 table_size;
>> + u8 reg_offset;
>> + u8 param_mask;
>> +};
>> +
>> +#define OVERRIDE_PARAM_MAP(table, numElements, offset, mask) \
> No camelcase please.
>
>> +{ \
>> + .param_table = table, \
>> + .table_size = numElements, \
>> + .reg_offset = offset, \
>> + .param_mask = mask, \
>> +}
>> +
>> +static const char *phy_seq_props[] =
>> +{
>> + "qcom,hs-rise-fall-time-bps",
>> + "qcom,squelch-detector-bps",
>> + "qcom,preemphasis-duration",
>> + "qcom,preemphasis-amplitude",
> What are the units for pre-emphasis duration and amplitude? Can you add the
> units as suffix?
My bad, its bps. Will add it in next patchset.
>> + "qcom,hs-disconnect-bps",
>> + "qcom,hs-amplitude-bps",
>> + "qcom,hs-crossover-voltage",
>> + "qcom,hs-output-impedance",
> What are the units for these above two parameters?
mV and mohm, Will add them as suffix.
>> + "qcom,ls-fs-output-impedance-bps",
>> +};
>> +
>> +static struct override_param hs_rise_fall_time_sc7280[] = {
>> + OVERRIDE_PARAM(-4100, 3),
>> + OVERRIDE_PARAM(0, 2),
>> + OVERRIDE_PARAM(2810, 1),
>> + OVERRIDE_PARAM(5430, 0),
>> +};
>> +
>> +static struct override_param squelch_det_threshold_sc7280[] = {
>> + OVERRIDE_PARAM(-2090, 7),
>> + OVERRIDE_PARAM(-1560, 6),
>> + OVERRIDE_PARAM(-1030, 5),
>> + OVERRIDE_PARAM(-530, 4),
>> + OVERRIDE_PARAM(0, 3),
>> + OVERRIDE_PARAM(530, 2),
>> + OVERRIDE_PARAM(1060, 1),
>> + OVERRIDE_PARAM(1590, 0),
>> +};
>> +
>> +static struct override_param hs_disconnect_sc7280[] = {
>> + OVERRIDE_PARAM(-272, 0),
>> + OVERRIDE_PARAM(0, 1),
>> + OVERRIDE_PARAM(317, 2),
>> + OVERRIDE_PARAM(630, 3),
>> + OVERRIDE_PARAM(973, 4),
>> + OVERRIDE_PARAM(1332, 5),
>> + OVERRIDE_PARAM(1743, 6),
>> + OVERRIDE_PARAM(2156, 7),
>> +};
>> +
>> +static struct override_param hs_amplitude_sc7280[] = {
>> + OVERRIDE_PARAM(-660, 0),
>> + OVERRIDE_PARAM(-440, 1),
>> + OVERRIDE_PARAM(-220, 2),
>> + OVERRIDE_PARAM(0, 3),
>> + OVERRIDE_PARAM(230, 4),
>> + OVERRIDE_PARAM(440, 5),
>> + OVERRIDE_PARAM(650, 6),
>> + OVERRIDE_PARAM(890, 7),
>> + OVERRIDE_PARAM(1110, 8),
>> + OVERRIDE_PARAM(1330, 9),
>> + OVERRIDE_PARAM(1560, 10),
>> + OVERRIDE_PARAM(1780, 11),
>> + OVERRIDE_PARAM(2000, 12),
>> + OVERRIDE_PARAM(2220, 13),
>> + OVERRIDE_PARAM(2430, 14),
>> + OVERRIDE_PARAM(2670, 15),
>> +};
>> +
>> +static struct override_param preemphasis_duration_sc7280[] = {
>> + OVERRIDE_PARAM(100, 1),
>> + OVERRIDE_PARAM(200, 0),
>> +};
>> +
>> +static struct override_param preemphasis_amplitude_sc7280[] = {
>> + OVERRIDE_PARAM(100, 1),
>> + OVERRIDE_PARAM(200, 2),
>> + OVERRIDE_PARAM(300, 3),
>> + OVERRIDE_PARAM(400, 0),
>> +};
>> +
>> +static struct override_param hs_crossover_voltage_sc7280[] = {
>> + OVERRIDE_PARAM(-31, 1),
>> + OVERRIDE_PARAM(28, 2),
>> + OVERRIDE_PARAM(0, 3),
>> +};
>> +
>> +static struct override_param hs_output_impedance_sc7280[] = {
>> + OVERRIDE_PARAM(-2300, 3),
>> + OVERRIDE_PARAM(0, 2),
>> + OVERRIDE_PARAM(2600, 1),
>> + OVERRIDE_PARAM(6100, 0),
>> +};
>> +
>> +static struct override_param ls_fs_output_impedance_sc7280[] = {
>> + OVERRIDE_PARAM(-1053, 15),
>> + OVERRIDE_PARAM(-557, 7),
>> + OVERRIDE_PARAM(0, 3),
>> + OVERRIDE_PARAM(612, 1),
>> + OVERRIDE_PARAM(1310, 0),
>> +};
>> +
> LGTM. I have cross checked with the data book.
>
>> +struct override_param_map sc7280_idp[] = {
>> + OVERRIDE_PARAM_MAP(
>> + hs_rise_fall_time_sc7280,
>> + ARRAY_SIZE(hs_rise_fall_time_sc7280),
>> + USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X2,
>> + HS_RISE_FALL_MASK),
>> +
> The bitmask definitions like HS_DISCONNECT_MASK are defined as they appear
> in the databook. However, this struct is defined out of order. Can you
> defined X0, X1, X2 and X3 registers in an order. Easier to check/compare
> against data book.
Sure, Will make this change.
>> + OVERRIDE_PARAM_MAP(
>> + squelch_det_threshold_sc7280,
>> + ARRAY_SIZE(squelch_det_threshold_sc7280),
>> + USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X0,
>> + SQUELCH_DETECTOR_MASK),
>> +
>> + OVERRIDE_PARAM_MAP(
>> + preemphasis_duration_sc7280,
>> + ARRAY_SIZE(preemphasis_duration_sc7280),
>> + USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X1,
>> + PREEMPHASIS_DURATION_MASK),
>> +
>> + OVERRIDE_PARAM_MAP(
>> + preemphasis_amplitude_sc7280,
>> + ARRAY_SIZE(preemphasis_amplitude_sc7280),
>> + USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X1,
>> + PREEMPHASIS_AMPLITUDE_MASK),
>> +
>> + OVERRIDE_PARAM_MAP(
>> + hs_disconnect_sc7280,
>> + ARRAY_SIZE(hs_disconnect_sc7280),
>> + USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X0,
>> + HS_DISCONNECT_MASK),
>> +
>> + OVERRIDE_PARAM_MAP(
>> + hs_amplitude_sc7280,
>> + ARRAY_SIZE(hs_amplitude_sc7280),
>> + USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X1,
>> + HS_AMPLITUDE_MASK),
>> +
>> + OVERRIDE_PARAM_MAP(
>> + hs_crossover_voltage_sc7280,
>> + ARRAY_SIZE(hs_crossover_voltage_sc7280),
>> + USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X2,
>> + HS_CROSSOVER_VOLTAGE_MASK),
>> +
>> + OVERRIDE_PARAM_MAP(
>> + hs_output_impedance_sc7280,
>> + ARRAY_SIZE(hs_output_impedance_sc7280),
>> + USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X2,
>> + HS_OUTPUT_IMPEDANCE_MASK),
>> +
>> + OVERRIDE_PARAM_MAP(
>> + ls_fs_output_impedance_sc7280,
>> + ARRAY_SIZE(ls_fs_output_impedance_sc7280),
>> + USB2_PHY_USB_PHY_HS_PHY_OVERRIDE_X3,
>> + LS_FS_OUTPUT_IMPEDANCE_MASK),
>> +};
>> +
>> +struct phy_override_seq {
>> + bool need_update;
>> + u8 offset;
>> + u8 value;
>> + u8 mask;
>> +};
>> +
>> +struct phy_override_seq update_seq_cfg[ARRAY_SIZE(phy_seq_props)];
> This needs to be wrapped up in qcom_snps_hsphy structure so that we can
> support override sequence per phy instance. The electrical complaince tuning
> is heavily influenced by the board design and where the ports are located etc.
> So it is possible that two instances of the phy can use different tunning
> parameters.
Makes sense. Thanks for the correction.
>> +
>> static int qcom_snps_hsphy_init(struct phy *phy)
>> {
>> struct qcom_snps_hsphy *hsphy = phy_get_drvdata(phy);
>> - int ret;
>> + int ret, i;
>>
>> dev_vdbg(&phy->dev, "%s(): Initializing SNPS HS phy\n", __func__);
>>
>> @@ -223,6 +424,12 @@ static int qcom_snps_hsphy_init(struct phy *phy)
>> qcom_snps_hsphy_write_mask(hsphy->base, USB2_PHY_USB_PHY_HS_PHY_CTRL1,
>> VBUSVLDEXT0, VBUSVLDEXT0);
>>
>> + for(i = 0; i < ARRAY_SIZE(update_seq_cfg); i++) {
>> + if (update_seq_cfg[i].need_update)
>> + qcom_snps_hsphy_write_mask(hsphy->base, update_seq_cfg[i].offset,
>> + update_seq_cfg[i].mask, update_seq_cfg[i].value);
>> + }
>> +
>> qcom_snps_hsphy_write_mask(hsphy->base,
>> USB2_PHY_USB_PHY_HS_PHY_CTRL_COMMON2,
>> VREGBYPASS, VREGBYPASS);
>> @@ -280,7 +487,10 @@ static const struct phy_ops qcom_snps_hsphy_gen_ops = {
>> static const struct of_device_id qcom_snps_hsphy_of_match_table[] = {
>> { .compatible = "qcom,sm8150-usb-hs-phy", },
>> { .compatible = "qcom,usb-snps-hs-5nm-phy", },
>> - { .compatible = "qcom,usb-snps-hs-7nm-phy", },
>> + {
>> + .compatible = "qcom,usb-snps-hs-7nm-phy",
>> + .data = &sc7280_idp
>> + },
> can you check the indentation please?
>
>> { .compatible = "qcom,usb-snps-femto-v2-phy", },
>> { }
>> };
>> @@ -291,6 +501,43 @@ static const struct dev_pm_ops qcom_snps_hsphy_pm_ops = {
>> qcom_snps_hsphy_runtime_resume, NULL)
>> };
>>
>> +static void hsphy_override_param_update_val(const struct override_param_map map,
>> + s32 dt_val, struct phy_override_seq *seq_entry)
>> +{
>> + int i;
>> +
>> + /*
>> + * We prepare the param table for each param in increasing order
>> + * of dt values. So we need to iterate over the list once to get
>> + * the required register value.
>> + */
>> + for (i = 0 ; i < map.table_size-1; i++) {
>> + if (map.param_table[i].value >= dt_val)
>> + break;
>> + }
> The comment is confusing. param_table[] already has values in the increasing
> order. we have to find *closet* match here. To keep it simple, we select the
> entry that has equal or the next highest (round up) value. clarify the
> comment.
Sure.
>> +
>> + seq_entry->need_update = true;
>> + seq_entry->offset = map.reg_offset;
>> + seq_entry->mask = map.param_mask;
>> + seq_entry->value = map.param_table[i].reg << __ffs(map.param_mask);
>> +}
>> +
>> +static void phy_read_param_override_seq(struct device *dev)
>> +{
>> + struct device_node *node = dev->of_node;
>> + s32 val;
>> + int ret, i;
>> + struct qcom_snps_hsphy *hsphy;
>> + struct override_param_map *cfg = (struct override_param_map* ) of_device_get_match_data(dev);
> nit pick. No explicit type case is needed here. of_device_get_match_data()
> returns a void pointer. so it can be written as
>
> struct override_param_map *cfg = of_device_get_match_data(dev);
>
>> + hsphy = dev_get_drvdata(dev);
>> +
>> + for (i = 0; i < ARRAY_SIZE(phy_seq_props); i++) {
>> + ret = of_property_read_s32(node, phy_seq_props[i], &val);
>> + if (!ret)
>> + hsphy_override_param_update_val(cfg[i], val, &update_seq_cfg[i]);
>> + }
>> +}
>> +
> Can we add a dev_dbg here to aid the debugging?
>
> All the functions defined in this driver has qcom_snps_hsphy_xxxx convention.
> Lets follow the same.
Sure, Will rename the function accordingly.
>> static int qcom_snps_hsphy_probe(struct platform_device *pdev)
>> {
>> struct device *dev = &pdev->dev;
>> @@ -352,6 +599,7 @@ static int qcom_snps_hsphy_probe(struct platform_device *pdev)
>>
>> dev_set_drvdata(dev, hsphy);
>> phy_set_drvdata(generic_phy, hsphy);
>> + phy_read_param_override_seq(dev);
>>
>> phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
>> if (!IS_ERR(phy_provider))
>> --
>> 2.7.4
>>
> Bjorn/Vinod,
>
> I have reviewed this patch on our internal review system. The basic design
> looks good to me. Can you please review the patch and provide your inputs.
>
> Thanks,
> Pavan

\
 
 \ /
  Last update: 2022-05-10 19:37    [W:0.052 / U:0.824 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site