From: Vivek Gautam <vivek.gautam@codeaurora.org>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: robh+dt@kernel.org, kishon@ti.com, sboyd@codeaurora.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
mark.rutland@arm.com, srinivas.kandagatla@linaro.org,
linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets
Date: Fri, 6 Jan 2017 15:17:01 +0530 [thread overview]
Message-ID: <e83564d4-d731-44dd-40d1-e36fa56f4920@codeaurora.org> (raw)
In-Reply-To: <20170106071834.GP10531@minitux>
Hi,
On 01/06/2017 12:48 PM, Bjorn Andersson wrote:
> On Tue 20 Dec 09:03 PST 2016, Vivek Gautam wrote:
>
>> diff --git a/drivers/phy/phy-qcom-qmp.c b/drivers/phy/phy-qcom-qmp.c
> [..]
>> +static int qcom_qmp_phy_poweron(struct phy *phy)
> [..]
>> +
>> +err3:
> Rather than naming your labels errX, it's idiomatic to give them
> descriptive names, e.g. "disable_ref_clk" here.
Sure will change these labels and any such occurrence further in the code.
>
>> + clk_disable_unprepare(qphy->ref_clk);
>> +err2:
>> + regulator_disable(qphy->vddp_ref_clk);
>> +err1:
>> + regulator_disable(qphy->vdda_pll);
>> +err:
>> + regulator_disable(qphy->vdda_phy);
>> + return ret;
>> +}
> [..]
>> +static int qcom_qmp_phy_com_init(struct qcom_qmp_phy *qphy)
>> +{
>> + const struct qmp_phy_cfg *cfg = qphy->cfg;
>> + void __iomem *serdes = qphy->serdes;
>> + int ret;
>> +
>> + mutex_lock(&qphy->phy_mutex);
>> + if (qphy->init_count++) {
>> + mutex_unlock(&qphy->phy_mutex);
>> + return 0;
>> + }
> As far as I can see phy_init() and phy_exit() already keep reference
> count on the initialization and you only call this function from
> phy_ops->init, so you should be able to drop this.
This is an intermediary function that does the common block initialization.
PHYs like PCIe have a separate common block (apart from SerDes)
for all phy channels. We shouldn't program this common block
multiple times for each channel. That's why this init_count.
>
> [..]
>> +
>> +/* PHY Initialization */
>> +static int qcom_qmp_phy_init(struct phy *phy)
>> +{
> [..]
>> + /* phy power down delay; given in PCIE phy programming guide only */
>> + if (qphy->cfg->type == PHY_TYPE_PCIE)
> Rather than basing this off "is this pcie" it's preferred if you have a
> bool power_down_delay; (or optionally carrying the timeout value) to
> control this.
Sure, will modify this.
>
>> + usleep_range(POWER_DOWN_DELAY_US_MIN, POWER_DOWN_DELAY_US_MAX);
>> +
>> + /* start SerDes and Phy-Coding-Sublayer */
>> + qphy_setbits(pcs + QPHY_START_CTRL, cfg->start_ctrl);
>> +
>> + /* Pull PHY out of reset state */
>> + qphy_clrbits(pcs + QPHY_SW_RESET, SW_RESET);
>> +
>> + status = pcs + cfg->regs[QPHY_PCS_READY_STATUS];
>> + mask = cfg->mask_pcs_ready;
>> +
>> + ret = !mask ? 0 : readl_poll_timeout(status, val, !(val & mask), 1,
>> + PHY_INIT_COMPLETE_TIMEOUT);
> I presume it's not okay to read the status register even once for pcie?
> If it is you can skip the conditional as !(val & 0) will break the poll
> after the first read.
Yea, it is okay to read the status register for pcie.
Will leave just readl_poll_timeout() that exits on !(val & mask).
We anyways don't set mask_pcs_ready for pcie.
> [..]
>> +static int qcom_qmp_phy_exit(struct phy *phy)
>> +{
> [..]
>> +}
>> +
>> +
> Extra blank line
Will remove it.
>
>> +static int qcom_qmp_phy_regulator_init(struct device *dev)
> [..]
>> +static
>> +struct qmp_phy_desc *qcom_qmp_phy_create(struct platform_device *pdev, int id)
>> +{
> [..]
>> + phy_desc->pipe_clk = devm_clk_get(dev, prop_name);
>> + if (IS_ERR(phy_desc->pipe_clk)) {
>> + if (qphy->cfg->type == PHY_TYPE_PCIE ||
>> + qphy->cfg->type == PHY_TYPE_USB3) {
> Is this check adding any value?
The USB3 and PCIe phys are PIPE based phys, and hence the pipe
clock is mandatory for them. Other phys don't care about pipe clock.
>
>> + ret = PTR_ERR(phy_desc->pipe_clk);
>> + if (ret != -EPROBE_DEFER)
>> + dev_err(dev,
>> + "failed to get lane%d pipe_clk, %d\n",
>> + id, ret);
>> + return ERR_PTR(ret);
>> + }
>> + phy_desc->pipe_clk = NULL;
> Regards,
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Regards
Vivek
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2017-01-06 9:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-20 17:03 [PATCH v3 0/4] phy: USB and PCIe phy drivers for Qcom chipsets Vivek Gautam
2016-12-20 17:03 ` [PATCH v3 1/4] dt-bindings: phy: Add support for QUSB2 phy Vivek Gautam
[not found] ` <1482253431-23160-2-git-send-email-vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-12-22 21:16 ` Rob Herring
2016-12-23 4:52 ` Vivek Gautam
2016-12-28 1:13 ` Stephen Boyd
2016-12-28 5:40 ` Vivek Gautam
2016-12-20 17:03 ` [PATCH v3 2/4] phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips Vivek Gautam
[not found] ` <1482253431-23160-3-git-send-email-vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-12-28 23:01 ` Stephen Boyd
2016-12-29 6:57 ` Vivek Gautam
2016-12-29 7:00 ` Vivek Gautam
2016-12-20 17:03 ` [PATCH v3 3/4] dt-bindings: phy: Add support for QMP phy Vivek Gautam
[not found] ` <1482253431-23160-4-git-send-email-vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-12-28 23:04 ` Stephen Boyd
[not found] ` <20161228230412.GC17126-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2016-12-29 5:05 ` Vivek Gautam
2016-12-20 17:03 ` [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets Vivek Gautam
2016-12-28 23:16 ` Stephen Boyd
2016-12-29 7:39 ` Vivek Gautam
[not found] ` <CAFp+6iF0FQjt3bt1d_HjYmpMb8cTkg+BudoNR7yzThd+EgZfQg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-01-03 19:24 ` Bjorn Andersson
2017-01-05 9:13 ` Vivek Gautam
2017-01-06 7:18 ` Bjorn Andersson
2017-01-06 9:47 ` Vivek Gautam [this message]
2017-01-06 21:17 ` Bjorn Andersson
2017-01-07 18:41 ` vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ
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=e83564d4-d731-44dd-40d1-e36fa56f4920@codeaurora.org \
--to=vivek.gautam@codeaurora.org \
--cc=bjorn.andersson@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=kishon@ti.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@codeaurora.org \
--cc=srinivas.kandagatla@linaro.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).