From: Jorge Ramirez <jorge.ramirez-ortiz@linaro.org>
To: Stephen Boyd <sboyd@kernel.org>,
gregkh@linuxfoundation.org, kishon@ti.com, mark.rutland@arm.com,
robh+dt@kernel.org
Cc: linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, shawn.guo@linaro.org,
vkoul@kernel.org
Subject: Re: [PATCH 2/2] phy: qualcomm: usb: Add Super-Speed PHY driver
Date: Wed, 26 Dec 2018 18:53:08 +0100 [thread overview]
Message-ID: <2f38642e-27a0-0fd7-928e-8e782d0bc7c6@linaro.org> (raw)
In-Reply-To: <154533779333.79149.17234544366247143930@swboyd.mtv.corp.google.com>
On 12/20/18 21:29, Stephen Boyd wrote:
> Quoting Jorge Ramirez-Ortiz (2018-12-07 01:55:58)
>> From: Shawn Guo <shawn.guo@linaro.org>
>>
>> Driver to control the Synopsys SS PHY 1.0.0 implemeneted in QCS404
>>
>> Based on Sriharsha Allenki's <sallenki@codeaurora.org> original code.
>>
>> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
>> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
>
> chain should be swapped?
ok.
Shawn asked me to remove him from the authors list so will remove.
>
>> Reviewed-by: Vinod Koul <vkoul@kernel.org>
will remove the reviewed-by line as well.
>> ---
>> diff --git a/drivers/phy/qualcomm/phy-qcom-usb-ss.c b/drivers/phy/qualcomm/phy-qcom-usb-ss.c
>> new file mode 100644
>> index 0000000..7b6a55e
>> --- /dev/null
>> +++ b/drivers/phy/qualcomm/phy-qcom-usb-ss.c
>> +
>> +struct ssphy_priv {
>> + void __iomem *base;
>> + struct device *dev;
>> + struct reset_control *reset_com;
>> + struct reset_control *reset_phy;
>> + struct clk *clk_ref;
>> + struct clk *clk_phy;
>> + struct clk *clk_pipe;
>
> Use bulk clk APIs? And just get and enable all the clks?
yes.
>
>> + struct regulator *vdda1p8;
>> + struct regulator *vbus;
>> + struct regulator *vdd;
>> + unsigned int vdd_levels[LEVEL_NUM];
>> +};
>> +
>> +static inline void qcom_ssphy_updatel(void __iomem *addr, u32 mask, u32 val)
>> +{
>> + writel((readl(addr) & ~mask) | val, addr);
>> +}
>> +
>> +static int qcom_ssphy_config_vdd(struct ssphy_priv *priv,
>> + enum phy_vdd_level level)
>> +{
>> + return regulator_set_voltage(priv->vdd,
>> + priv->vdd_levels[level],
>> + priv->vdd_levels[LEVEL_MAX]);
>
> regulator_set_voltage(reg, 0, max) is very suspicious. It's voltage
> corners where the voltages are known?
sorry I dont understand the question
this regulator on the ss phy wold be
vreg_l3_1p05: l3 {
regulator-min-microvolt = <976000>;
regulator-max-microvolt = <1160000>;
};
>
>> +}
>> +
>> +static int qcom_ssphy_ldo_enable(struct ssphy_priv *priv)
>> +{
>> + int ret;
>> +
>> + ret = regulator_set_load(priv->vdda1p8, 23000);
>
> Do you need to do this? Why can't the regulator be in high power mode
> all the time and then go low power when it's disabled?
this regulator is shared with the usb hs phy and each (ss/hs) have
different load requirements. why would it be wrong for the ss phy to
announce its needs (which will differ from those of the hs phy)?
>
>> + if (ret < 0) {
>> + dev_err(priv->dev, "Failed to set regulator1p8 load\n");
>> + return ret;
>> + }
>> +
>> + ret = regulator_set_voltage(priv->vdda1p8, 1800000, 1800000);
>
> This looks unnecessary. The 1.8V regulator sounds like it better be 1.8V
> so board constraints should enforce that. All that should be here is
> enabling the regulator.
ok
>
>> + if (ret) {
>> + dev_err(priv->dev, "Failed to set regulator1p8 voltage\n");
>> + goto put_vdda1p8_lpm;
>> + }
>> +
>> + ret = regulator_enable(priv->vdda1p8);
>> + if (ret) {
>> + dev_err(priv->dev, "Failed to enable regulator1p8\n");
>> + goto unset_vdda1p8;
>> + }
>> +
>> + return ret;
>> +
>> + /* rollback regulator changes */
>> +
>> +unset_vdda1p8:
>> + regulator_set_voltage(priv->vdda1p8, 0, 1800000);
>> +
>> +put_vdda1p8_lpm:
>> + regulator_set_load(priv->vdda1p8, 0);
>> +
>> + return ret;
>> +}
>> +
>> +static void qcom_ssphy_ldo_disable(struct ssphy_priv *priv)
>> +{
>> + regulator_disable(priv->vdda1p8);
>> + regulator_set_voltage(priv->vdda1p8, 0, 1800000);
>
> Urgh why?
since it is being shared with the hs phy I understand this is required
to vote the transition to the lowest voltage state.
>
>> + regulator_set_load(priv->vdda1p8, 0);
>> +}
>
next prev parent reply other threads:[~2018-12-26 17:53 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-07 9:55 [PATCH 0/2] USB SS PHY for Qualcomm's QCS404 Jorge Ramirez-Ortiz
2018-12-07 9:55 ` [PATCH 1/2] dt-bindings: Add Qualcomm USB Super-Speed PHY bindings Jorge Ramirez-Ortiz
2018-12-20 9:52 ` Jorge Ramirez-Ortiz
2018-12-20 17:07 ` Rob Herring
2018-12-21 7:42 ` Jorge Ramirez
2018-12-20 17:05 ` Rob Herring
2018-12-20 17:37 ` Jack Pham
2018-12-21 7:40 ` Jorge Ramirez
2018-12-28 12:38 ` Jorge Ramirez
2019-01-07 20:26 ` Jack Pham
2019-01-07 20:33 ` Andy Gross
2018-12-20 20:25 ` Stephen Boyd
2018-12-21 7:37 ` Jorge Ramirez
2018-12-26 17:55 ` Jorge Ramirez
2018-12-07 9:55 ` [PATCH 2/2] phy: qualcomm: usb: Add Super-Speed PHY driver Jorge Ramirez-Ortiz
2018-12-20 20:29 ` Stephen Boyd
2018-12-26 17:53 ` Jorge Ramirez [this message]
2019-01-03 23:30 ` Stephen Boyd
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=2f38642e-27a0-0fd7-928e-8e782d0bc7c6@linaro.org \
--to=jorge.ramirez-ortiz@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=kishon@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=shawn.guo@linaro.org \
--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;
as well as URLs for NNTP newsgroup(s).