From: Swapnil Kashinath Jakhade <sjakhade@cadence.com>
To: Kishon Vijay Abraham I <kishon@ti.com>, Vinod Koul <vkoul@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"maxime@cerno.tech" <maxime@cerno.tech>,
Milind Parab <mparab@cadence.com>,
Yuti Suresh Amonkar <yamonkar@cadence.com>,
"nsekhar@ti.com" <nsekhar@ti.com>,
"tomi.valkeinen@ti.com" <tomi.valkeinen@ti.com>,
"jsarha@ti.com" <jsarha@ti.com>,
"praneeth@ti.com" <praneeth@ti.com>
Subject: RE: [PATCH v3 1/2] phy: Add new PHY attribute max_link_rate and APIs to get/set PHY attributes
Date: Tue, 14 Jul 2020 07:44:26 +0000 [thread overview]
Message-ID: <DM6PR07MB6154EB848939DBC2DFB40D7BC5610@DM6PR07MB6154.namprd07.prod.outlook.com> (raw)
In-Reply-To: <67fcecf5-7be3-518f-ce3e-095dcddd5bc9@ti.com>
Hi,
Thanks for your comments.
> -----Original Message-----
> From: Kishon Vijay Abraham I <kishon@ti.com>
> Sent: Monday, July 13, 2020 5:28 PM
> To: Vinod Koul <vkoul@kernel.org>; Swapnil Kashinath Jakhade
> <sjakhade@cadence.com>
> Cc: linux-kernel@vger.kernel.org; maxime@cerno.tech; Milind Parab
> <mparab@cadence.com>; Yuti Suresh Amonkar <yamonkar@cadence.com>;
> nsekhar@ti.com; tomi.valkeinen@ti.com; jsarha@ti.com; praneeth@ti.com
> Subject: Re: [PATCH v3 1/2] phy: Add new PHY attribute max_link_rate and
> APIs to get/set PHY attributes
>
> EXTERNAL MAIL
>
>
>
>
> On 7/13/2020 4:41 PM, Vinod Koul wrote:
> > On 13-07-20, 11:38, Swapnil Jakhade wrote:
> >> Add new PHY attribute max_link_rate to struct phy_attrs.
> >> Add a pair of PHY APIs to get/set all the PHY attributes.
> >> Use phy_set_attrs() to set attribute values in the PHY provider driver.
> >> Use phy_get_attrs() to get attribute values in the controller driver.
> >>
> >> Signed-off-by: Yuti Amonkar <yamonkar@cadence.com>
> >> Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com>
> >> ---
> >> include/linux/phy/phy.h | 22 ++++++++++++++++++++++
> >> 1 file changed, 22 insertions(+)
> >>
> >> diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h index
> >> bcee8eba62b3..7fb59359ab7b 100644
> >> --- a/include/linux/phy/phy.h
> >> +++ b/include/linux/phy/phy.h
> >> @@ -115,10 +115,12 @@ struct phy_ops {
> >> /**
> >> * struct phy_attrs - represents phy attributes
> >> * @bus_width: Data path width implemented by PHY
> >> + * @max_link_rate: Maximum link rate supported by PHY (in Mbps)
> >> * @mode: PHY mode
> >> */
> >> struct phy_attrs {
> >> u32 bus_width;
> >> + u32 max_link_rate;
> >> enum phy_mode mode;
> >> };
> >>
> >> @@ -231,6 +233,16 @@ static inline void phy_set_bus_width(struct phy
> >> *phy, int bus_width) {
> >> phy->attrs.bus_width = bus_width;
> >> }
> >> +
> >> +static inline void phy_get_attrs(struct phy *phy, struct phy_attrs
> >> +*attrs) {
> >> + memcpy(attrs, &phy->attrs, sizeof(struct phy_attrs)); }
> >> +
> >> +static inline void phy_set_attrs(struct phy *phy, struct phy_attrs
> >> +attrs) {
> >> + memcpy(&phy->attrs, &attrs, sizeof(struct phy_attrs)); }
> >
> > we already have APIs for mode and bus_width so why not add one for
> > link_rate and call them?
First version of this patch series [1] was based on this approach. But as per the further discussion in the same thread [2], phy_get_attrs/phy_set_attrs are implemented.
[1] https://lkml.org/lkml/2020/4/28/139
[2] https://lkml.org/lkml/2020/5/18/472
> >
> > Also I see you are using phy_set_attrs() in second patch, why add
> > phy_get_attrs() when we have no user?
As mentioned in cover letter, phy_get_attrs() is planned to be used in Cadence MHDP DRM bridge driver for DisplayPort. Next version of this driver patch series [3] will use this API.
[3] https://lkml.org/lkml/2020/2/26/263
>
> One of the factors to consider is who will set the attributes; it could either be
> phy provider (like 2/2 of this series) or phy consumer (factors like PCIe speed,
> lane are usually negotiated with the phy consumer).
>
> Now if phy provider is setting/getting the attributes, then
> phy_set_attrs/phy_get_attrs should be protected by mutex. We don't want
> to be updating attributes when phy consumer is doing some phy ops.
>
> If phy_consumer is updating attributes, it could directly access the phy
> attributes if it's updating within one of those phy ops. Don't really see a need
> for using an API to update the attributes then.
>
> However if it's updating outside the phy_ops, then it would still make sense
> to use the APIs to update attributes with all those mutex protection.
Ok. Please check if following implementation is correct in phy_get_attrs/phy_set_attrs APIs for the above case.
mutex_lock(&phy->mutex);
memcpy(....);
mutex_unlock(&phy->mutex);
Thanks & regards,
Swapnil
>
> Regards
> Kishon
> >
> >> struct phy *phy_get(struct device *dev, const char *string); struct
> >> phy *phy_optional_get(struct device *dev, const char *string);
> >> struct phy *devm_phy_get(struct device *dev, const char *string); @@
> >> -389,6 +401,16 @@ static inline void phy_set_bus_width(struct phy *phy,
> int bus_width)
> >> return;
> >> }
> >>
> >> +static inline void phy_get_attrs(struct phy *phy, struct phy_attrs
> >> +*attrs) {
> >> + return;
> >> +}
> >> +
> >> +static inline void phy_set_attrs(struct phy *phy, struct phy_attrs
> >> +attrs) {
> >> + return;
> >> +}
> >> +
> >> static inline struct phy *phy_get(struct device *dev, const char
> >> *string) {
> >> return ERR_PTR(-ENOSYS);
> >> --
> >> 2.26.1
> >
next prev parent reply other threads:[~2020-07-14 7:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-13 9:38 [PATCH v3 0/2] Add new PHY APIs to framework " Swapnil Jakhade
2020-07-13 9:38 ` [PATCH v3 1/2] phy: Add new PHY attribute max_link_rate and APIs " Swapnil Jakhade
2020-07-13 11:11 ` Vinod Koul
2020-07-13 11:58 ` Kishon Vijay Abraham I
2020-07-14 7:44 ` Swapnil Kashinath Jakhade [this message]
2020-07-13 9:38 ` [PATCH v3 2/2] phy: cadence-torrent: Use kernel PHY API to set " Swapnil Jakhade
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=DM6PR07MB6154EB848939DBC2DFB40D7BC5610@DM6PR07MB6154.namprd07.prod.outlook.com \
--to=sjakhade@cadence.com \
--cc=jsarha@ti.com \
--cc=kishon@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime@cerno.tech \
--cc=mparab@cadence.com \
--cc=nsekhar@ti.com \
--cc=praneeth@ti.com \
--cc=tomi.valkeinen@ti.com \
--cc=vkoul@kernel.org \
--cc=yamonkar@cadence.com \
/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
all inboxes | Powered by JetHome®