From: vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org
To: Bjorn Andersson
<bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
kishon-l0cyMroinI0@public.gmane.org,
sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
mark.rutland-5wv7dgnIgG8@public.gmane.org,
srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-msm-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets
Date: Sun, 08 Jan 2017 00:11:14 +0530 [thread overview]
Message-ID: <2e93e810adbc252cd630d89bb753ec81@codeaurora.org> (raw)
In-Reply-To: <20170106211722.GT10531@minitux>
On 2017-01-07 02:47, Bjorn Andersson wrote:
> On Fri 06 Jan 01:47 PST 2017, Vivek Gautam wrote:
>
>> > > +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.
>>
>
> You're right!
>
> Unfortunately it took me several minutes to wrap my head around the phy
> vs multi-lane and I have a really hard time keeping "qcom_qmp_phy" and
> "qmp_phy_desc" apart throughout the driver.
>
> If I understand correctly the qcom_qmp_phy is the context representing
> a
> "QMP block", while this is a PHY block it's not actually the phy in
> Linux eyes. The qcom_phy_desc represents a "QMP lane", which in Linux
> eyes is the phys, but as we think of QMP as the PHY this confused me.
That's correct. The qcom_qmp_phy structure represents the QMP phy block
as a whole and not the individual phy lane instances. These phy lanes
are represented by qcom_phy_desc, and are the actual PHYs in Linux eyes.
>
> How about naming them "struct qmp" and "struct qmp_lane" (or possibly
> qmp_phy) instead? That way we remove the confusion of QMP PHY vs Linux
> PHY and we make the lane part explicit.
Sure, this sounds good to me - "struct qmp" and "struct qmp_phy" (will
call the respective variables as qblk for qmp block (struct qmp) and
qphy for struct qmp_phy).
Thanks for pointing out. Will change them.
Regards
Vivek
>
> Regards,
> Bjorn
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-arm-msm" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: 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,
linux-arm-msm-owner@vger.kernel.org
Subject: Re: [PATCH v3 4/4] phy: qcom-qmp: new qmp phy driver for qcom-chipsets
Date: Sun, 08 Jan 2017 00:11:14 +0530 [thread overview]
Message-ID: <2e93e810adbc252cd630d89bb753ec81@codeaurora.org> (raw)
In-Reply-To: <20170106211722.GT10531@minitux>
On 2017-01-07 02:47, Bjorn Andersson wrote:
> On Fri 06 Jan 01:47 PST 2017, Vivek Gautam wrote:
>
>> > > +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.
>>
>
> You're right!
>
> Unfortunately it took me several minutes to wrap my head around the phy
> vs multi-lane and I have a really hard time keeping "qcom_qmp_phy" and
> "qmp_phy_desc" apart throughout the driver.
>
> If I understand correctly the qcom_qmp_phy is the context representing
> a
> "QMP block", while this is a PHY block it's not actually the phy in
> Linux eyes. The qcom_phy_desc represents a "QMP lane", which in Linux
> eyes is the phys, but as we think of QMP as the PHY this confused me.
That's correct. The qcom_qmp_phy structure represents the QMP phy block
as a whole and not the individual phy lane instances. These phy lanes
are represented by qcom_phy_desc, and are the actual PHYs in Linux eyes.
>
> How about naming them "struct qmp" and "struct qmp_lane" (or possibly
> qmp_phy) instead? That way we remove the confusion of QMP PHY vs Linux
> PHY and we make the lane part explicit.
Sure, this sounds good to me - "struct qmp" and "struct qmp_phy" (will
call the respective variables as qblk for qmp block (struct qmp) and
qphy for struct qmp_phy).
Thanks for pointing out. Will change them.
Regards
Vivek
>
> 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
next prev parent reply other threads:[~2017-01-07 18:41 UTC|newest]
Thread overview: 30+ 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 ` 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-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-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
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-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-03 19:24 ` Bjorn Andersson
2017-01-05 9:13 ` Vivek Gautam
2017-01-05 9:13 ` Vivek Gautam
2017-01-06 7:18 ` Bjorn Andersson
2017-01-06 9:47 ` Vivek Gautam
2017-01-06 21:17 ` Bjorn Andersson
2017-01-07 18:41 ` vivek.gautam-sgV2jX0FEOL9JmXXK+q4OQ [this message]
2017-01-07 18:41 ` vivek.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=2e93e810adbc252cd630d89bb753ec81@codeaurora.org \
--to=vivek.gautam-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
--cc=bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=kishon-l0cyMroinI0@public.gmane.org \
--cc=linux-arm-msm-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-arm-msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.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.