| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <42b0034f-0be1-2951-d6a6-bf0a51cf0fc2@linaro.org>
Date: Wed, 18 May 2022 20:52:59 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Kuogee Hsieh <quic_khsieh@...cinc.com>
Cc: dri-devel@...ts.freedesktop.org, robdclark@...il.com,
sean@...rly.run, swboyd@...omium.org, dianders@...omium.org,
vkoul@...nel.org, daniel@...ll.ch, airlied@...ux.ie,
agross@...nel.org, bjorn.andersson@...aro.org,
quic_abhinavk@...cinc.com, quic_aravindh@...cinc.com,
quic_sbillaka@...cinc.com, freedreno@...ts.freedesktop.org,
linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/2] phy/qcom: add regulator_set_load to edp/dp phy
On 18/05/2022 20:36, Kuogee Hsieh wrote:
>
> On 5/18/2022 10:12 AM, Dmitry Baryshkov wrote:
>> On Wed, 18 May 2022 at 19:43, Kuogee Hsieh <quic_khsieh@...cinc.com>
>> wrote:
>>> This patch add regulator_set_load() to both eDP and DP phy driver
>>> to have totally control regulators.
>>>
>>> Changes in v2:
>>> -- no regulator_set_laod() before disable regulator
>>>
>>> Signed-off-by: Kuogee Hsieh <quic_khsieh@...cinc.com>
>>> ---
>>> drivers/phy/qualcomm/phy-qcom-edp.c | 25 +++++++++++++++++++++----
>>> drivers/phy/qualcomm/phy-qcom-qmp.c | 13 +++++++++++++
>> Split into -edp and -qmp part.
>>
>>> 2 files changed, 34 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c
>>> b/drivers/phy/qualcomm/phy-qcom-edp.c
>>> index cacd32f..9b55095 100644
>>> --- a/drivers/phy/qualcomm/phy-qcom-edp.c
>>> +++ b/drivers/phy/qualcomm/phy-qcom-edp.c
>>> @@ -87,17 +87,24 @@ struct qcom_edp {
>>>
>>> struct clk_bulk_data clks[2];
>>> struct regulator_bulk_data supplies[2];
>>> + int enable_load[2];
>>> + int disable_load[2];
>> As noticed in the review of the previous patch, disable_load is
>> unnecessary.
>>
>>> };
>>>
>>> static int qcom_edp_phy_init(struct phy *phy)
>>> {
>>> struct qcom_edp *edp = phy_get_drvdata(phy);
>>> int ret;
>>> + int num_consumers = ARRAY_SIZE(edp->supplies);
>>> + int i;
>>>
>>> - ret = regulator_bulk_enable(ARRAY_SIZE(edp->supplies),
>>> edp->supplies);
>>> + ret = regulator_bulk_enable(num_consumers, edp->supplies);
>>> if (ret)
>>> return ret;
>>>
>>> + for (i = num_consumers - 1; i >= 0; --i)
>>> + regulator_set_load(edp->supplies[i].consumer,
>>> edp->enable_load[i]);
>>> +
>>> ret = clk_bulk_prepare_enable(ARRAY_SIZE(edp->clks),
>>> edp->clks);
>>> if (ret)
>>> goto out_disable_supplies;
>>> @@ -425,9 +432,15 @@ static int qcom_edp_phy_power_off(struct phy *phy)
>>> static int qcom_edp_phy_exit(struct phy *phy)
>>> {
>>> struct qcom_edp *edp = phy_get_drvdata(phy);
>>> + int num_consumers = ARRAY_SIZE(edp->supplies);
>>> + int i;
>>>
>>> clk_bulk_disable_unprepare(ARRAY_SIZE(edp->clks), edp->clks);
>>> - regulator_bulk_disable(ARRAY_SIZE(edp->supplies),
>>> edp->supplies);
>>> +
>>> + for (i = num_consumers - 1; i >= 0; --i)
>>> + regulator_set_load(edp->supplies[i].consumer,
>>> edp->disable_load[i]);
>>> +
>>> + regulator_bulk_disable(num_consumers, edp->supplies);
>>>
>>> return 0;
>>> }
>>> @@ -633,8 +646,12 @@ static int qcom_edp_phy_probe(struct
>>> platform_device *pdev)
>>> if (ret)
>>> return ret;
>>>
>>> - edp->supplies[0].supply = "vdda-phy";
>>> - edp->supplies[1].supply = "vdda-pll";
>>> + edp->supplies[0].supply = "vdda-1p2";
>>> + edp->supplies[1].supply = "vdda-0p9";
>> NAK, You can not randomly change supply names.
>
> if you do no change here, then we have to change dtsi.
>
> They are not match.
Where is no match? I don't see any in-kernel dtsi using them.
>>> + edp->enable_load[0] = 21800; /* 1.2 V */
>>> + edp->enable_load[1] = 36000; /* 1.2 V */
>>> + edp->disable_load[0] = 4; /* 0.9 V */
>>> + edp->disable_load[1] = 4; /* 10.9V */
>> Again, 10.9V here. Kuogee. Have you read the review points?
> I have read it. but forget to make change at edp file.
>>
>>> ret = devm_regulator_bulk_get(dev,
>>> ARRAY_SIZE(edp->supplies), edp->supplies);
>>> if (ret)
>>> return ret;
>>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
>>> b/drivers/phy/qualcomm/phy-qcom-qmp.c
>>> index b144ae1..0a4c8a8 100644
>>> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
>>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
>>> @@ -3130,6 +3130,7 @@ struct qmp_phy_cfg {
>>> int num_resets;
>>> /* regulators to be requested */
>>> const char * const *vreg_list;
>>> + const unsigned int *vreg_enable_load;
>>> int num_vregs;
>>>
>>> /* array of registers with different offsets */
>>> @@ -3346,6 +3347,10 @@ static const char * const qmp_phy_vreg_l[] = {
>>> "vdda-phy", "vdda-pll",
>>> };
>>>
>>> +static const unsigned int qmp_phy_vreg_enable_load[] = {
>>> + 21800, 36000
>>> +};
>>> +
>>> static const struct qmp_phy_cfg ipq8074_usb3phy_cfg = {
>>> .type = PHY_TYPE_USB3,
>>> .nlanes = 1,
>>> @@ -4072,6 +4077,7 @@ static const struct qmp_phy_cfg
>>> sm8250_usb3phy_cfg = {
>>> .reset_list = msm8996_usb3phy_reset_l,
>>> .num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
>>> .vreg_list = qmp_phy_vreg_l,
>>> + .vreg_enable_load = qmp_phy_vreg_enable_load,
>>> .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
>>> .regs = qmp_v4_usb3phy_regs_layout,
>>>
>>> @@ -4139,6 +4145,7 @@ static const struct qmp_phy_cfg
>>> sm8250_dpphy_cfg = {
>>> .reset_list = msm8996_usb3phy_reset_l,
>>> .num_resets = ARRAY_SIZE(msm8996_usb3phy_reset_l),
>>> .vreg_list = qmp_phy_vreg_l,
>>> + .vreg_enable_load = qmp_phy_vreg_enable_load,
So, you apply this change only to the sm8250 (sc7280) config. Are you
sure that both of them have the same requirement?
Also there are other DP phy instances (sc8180x, sc7180). Do they have to
be extended too?
>>> .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
>>> .regs = qmp_v4_usb3phy_regs_layout,
>>>
>>> @@ -5008,6 +5015,11 @@ static int qcom_qmp_phy_com_init(struct
>>> qmp_phy *qphy)
>>> return 0;
>>> }
>>>
>>> + if (cfg->vreg_enable_load) {
>>> + for (i = cfg->num_vregs - 1; i >= 0; --i)
>> What's the point of iterating the list backwards?
>
> do no know,
>
> I just follow the order from regulator_bulk_enable()
regulator_bulk_enable() iterates the list in the ascending order.
>
>>
>>> + regulator_set_load(qmp->vregs[i].consumer,
>>> cfg->vreg_enable_load[i]);
>>> + }
>>> +
>>> /* turn on regulator supplies */
>>> ret = regulator_bulk_enable(cfg->num_vregs, qmp->vregs);
>>> if (ret) {
>>> @@ -5116,6 +5128,7 @@ static int qcom_qmp_phy_com_exit(struct qmp_phy
>>> *qphy)
>>>
>>> clk_bulk_disable_unprepare(cfg->num_clks, qmp->clks);
>>>
>>> + /* no minimum load set required before disable regulator */
>> No otneed for the comment.
>>
>>> regulator_bulk_disable(cfg->num_vregs, qmp->vregs);
>>>
>>> mutex_unlock(&qmp->phy_mutex);
>>> --
>>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
>>> Forum,
>>> a Linux Foundation Collaborative Project
>>>
>>
--
With best wishes
Dmitry
Powered by blists - more mailing lists