From: Shawn Guo <shawn.guo@linaro.org>
To: mgautam@codeaurora.org
Cc: Kishon Vijay Abraham I <kishon@ti.com>,
Rob Herring <robh+dt@kernel.org>,
Sriharsha Allenki <sallenki@codeaurora.org>,
Anu Ramanathan <anur@codeaurora.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Vinod Koul <vkoul@kernel.org>, Jack Pham <jackp@codeaurora.org>,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-msm-owner@vger.kernel.org
Subject: Re: [PATCH v6 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver
Date: Thu, 20 Dec 2018 19:09:58 +0800 [thread overview]
Message-ID: <20181220110956.GA17416@dragon> (raw)
In-Reply-To: <f106782b6d8e26ebf851f00563c68948@codeaurora.org>
Hi Manu,
On Thu, Dec 20, 2018 at 09:33:43AM +0530, mgautam@codeaurora.org wrote:
> Hi Shawn,
>
> On 2018-12-20 06:31, Shawn Guo wrote:
> >It adds Synopsys 28nm Femto High-Speed USB PHY driver support, which
> >is usually paired with Synopsys DWC3 USB controllers on Qualcomm SoCs.
> >
> >Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> >---
> ....
>
> >+
> >+/* PHY register and bit definitions */
> >+#define PHY_CTRL_COMMON0 0x078
> >+#define SIDDQ BIT(2)
> >+#define PHY_IRQ_CMD 0x0d0
> >+#define PHY_INTR_MASK0 0x0d4
> >+#define PHY_INTR_CLEAR0 0x0dc
> >+#define DPDM_MASK 0x1e
> >+#define DP_1_0 BIT(4)
> >+#define DP_0_1 BIT(3)
> >+#define DM_1_0 BIT(2)
> >+#define DM_0_1 BIT(1)
>
> Can we rename these to something more readable? e.g.:
> #define DP_FALL_INT_EN BIT(4)
> #define DP_RISE_INT_EN BIT(3)
> ...
Good suggestion. Will do.
>
> >+
> >+enum hsphy_voltage {
> >+ VOL_NONE,
> >+ VOL_MIN,
> >+ VOL_MAX,
> >+ VOL_NUM,
> >+};
> >+
> >+enum hsphy_vreg {
> >+ VDD,
> >+ VDDA_1P8,
> >+ VDDA_3P3,
> >+ VREG_NUM,
> >+};
> >+
> >+struct hsphy_init_seq {
> >+ int offset;
> >+ int val;
> >+ int delay;
> >+};
> >+
> >+struct hsphy_data {
> >+ const struct hsphy_init_seq *init_seq;
> >+ unsigned int init_seq_num;
> >+};
> >+
> >+struct hsphy_priv {
> nit-pick - indentation for following structure members?
Hmm, my personal taste says no, because I found that it's hard to keep
the indentation when adding new members later.
>
> >+ void __iomem *base;
> >+ struct clk_bulk_data *clks;
> >+ int num_clks;
> >+ struct reset_control *phy_reset;
> >+ struct reset_control *por_reset;
> >+ struct regulator_bulk_data vregs[VREG_NUM];
> >+ unsigned int voltages[VREG_NUM][VOL_NUM];
> >+ const struct hsphy_data *data;
> >+ bool cable_connected;
>
> You can get cable-connected state from "enum phy_mode mode" which
> is present in this driver.
> E.g. cable_connected is false if mode is neither HOST nor DEVICE.
>
>
> >+ struct extcon_dev *vbus_edev;
> >+ struct notifier_block vbus_notify;
>
> extcons not needed if you use "mode" for the same purpose.
The extcon is there for indicating cable connection status. I'm not
sure that phy_mode can be used for that purpose. For example, what
value would phy core set phy_mode to, if we disconnect the cable from
phy_mode being HOST or DEVICE?
>
>
> >+ enum phy_mode mode;
> >+};
> >+
>
>
> >+
> >+static int qcom_snps_hsphy_vbus_notifier(struct notifier_block *nb,
> >+ unsigned long event, void *ptr)
> >+{
> >+ struct hsphy_priv *priv = container_of(nb, struct hsphy_priv,
> >+ vbus_notify);
> >+ priv->cable_connected = !!event;
> >+ return 0;
> >+}
> >+
> >+static int qcom_snps_hsphy_power_on(struct phy *phy)
>
> Can you instead merge this power_on function with phy_init?
I can do that, but what's the gain/advantage from doing that?
>
> >+{
> >+ struct hsphy_priv *priv = phy_get_drvdata(phy);
> >+ int ret;
> >+
> >+ if (priv->cable_connected) {
>
> Why distinguish between cable connected vs not-connected?
This is based on the vendor driver implementation. It does a more
aggressive low power management in case that cable is not connected,
i.e. turning off regulator and entering retention mode.
>
> >+ ret = clk_bulk_prepare_enable(priv->num_clks, priv->clks);
> >+ if (ret)
> >+ return ret;
> >+ qcom_snps_hsphy_disable_hv_interrupts(priv);
> >+ } else {
> >+ ret = qcom_snps_hsphy_enable_regulators(priv);
> >+ if (ret)
> >+ return ret;
> >+ ret = clk_bulk_prepare_enable(priv->num_clks, priv->clks);
> >+ if (ret)
> >+ return ret;
> >+ qcom_snps_hsphy_exit_retention(priv);
> >+ }
> >+
> >+ return 0;
> >+}
> >+
> >+static int qcom_snps_hsphy_power_off(struct phy *phy)
> >+{
> >+ struct hsphy_priv *priv = phy_get_drvdata(phy);
> >+
> >+ if (priv->cable_connected) {
> >+ qcom_snps_hsphy_enable_hv_interrupts(priv);
> >+ clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
> >+ } else {
> >+ qcom_snps_hsphy_enter_retention(priv);
> >+ clk_bulk_disable_unprepare(priv->num_clks, priv->clks);
> >+ qcom_snps_hsphy_disable_regulators(priv);
> >+ }
> >+
> >+ return 0;
> >+}
> >+
>
>
>
> ..
> >+static const struct phy_ops qcom_snps_hsphy_ops = {
> >+ .init = qcom_snps_hsphy_init,
> >+ .power_on = qcom_snps_hsphy_power_on,
> >+ .power_off = qcom_snps_hsphy_power_off,
> >+ .set_mode = qcom_snps_hsphy_set_mode,
>
> .phy_exit()?
> I believe that is needed as dwc3 core driver performs
> phy_exit/phy_init across pm_suspend/resume.
I just do not see anything that we should be doing in .exit hook right
now.
Shawn
>
>
> >+ .owner = THIS_MODULE,
> >+};
> >+
>
next prev parent reply other threads:[~2018-12-20 11:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-20 1:01 [PATCH v6 0/2] Add Synopsys High-Speed USB PHY driver for Qualcomm SoCs Shawn Guo
2018-12-20 1:01 ` [PATCH v6 1/2] dt-bindings: phy: Add Qualcomm Synopsys High-Speed USB PHY binding Shawn Guo
2018-12-20 1:01 ` [PATCH v6 2/2] phy: qualcomm: Add Synopsys High-Speed USB PHY driver Shawn Guo
2018-12-20 4:03 ` mgautam
2018-12-20 11:09 ` Shawn Guo [this message]
2018-12-21 8:13 ` Manu Gautam
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=20181220110956.GA17416@dragon \
--to=shawn.guo@linaro.org \
--cc=anur@codeaurora.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=jackp@codeaurora.org \
--cc=kishon@ti.com \
--cc=linux-arm-msm-owner@vger.kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgautam@codeaurora.org \
--cc=robh+dt@kernel.org \
--cc=sallenki@codeaurora.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.