From: Abel Vesa <abel.vesa@nxp.com>
To: Georgi Djakov <djakov@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
NXP Linux Team <linux-imx@nxp.com>,
linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/3] interconnect: imx: Add imx_icc_get_bw and imx_icc_aggregate functions
Date: Mon, 3 Jan 2022 17:01:56 +0200 [thread overview]
Message-ID: <YdMP5P7Lwwkf6uRn@abelvesa> (raw)
In-Reply-To: <048650ad-e015-3733-bdf2-72b7a0ed61e4@kernel.org>
On 22-01-01 20:26:05, Georgi Djakov wrote:
> Hi Abel,
>
> On 1.01.22 18:39, Abel Vesa wrote:
> > The aggregate function will return whatever is the highest
> > rate for that specific node. The imx_icc_get_bw sets the
>
> Adding some more details about why we switch from
> icc_std_aggregate to imx_icc_aggregate would be nice.
>
On a second look, I think I can drop the imx_icc_aggregate and use the
icc_std_aggregate instead, as long as I use the peak_bw and forget about
the agg_bw.
> > initial avg and peak to 0 in order to avoid setting them to
> > INT_MAX by the interconnect core.
>
> Do we need a Fixes tag for this?
>
Neah, the imx interconnect is not used by any platform yet.
> I would recommend to split imx_icc_get_bw and imx_icc_aggregate
> changes into separate patches. These also seem to be unrelated to
> the imx_icc_node_adj_desc patchset.
>
Since I can use icc_std_aggregate, the imx_icc_aggregate change will be
dropped.
> Thanks,
> Georgi
>
> > Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
> > ---
> >
> > No changes since v1.
> >
> > drivers/interconnect/imx/imx.c | 20 +++++++++++++++++++-
> > 1 file changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/interconnect/imx/imx.c b/drivers/interconnect/imx/imx.c
> > index 34bfc7936387..4d8a2a2d2608 100644
> > --- a/drivers/interconnect/imx/imx.c
> > +++ b/drivers/interconnect/imx/imx.c
> > @@ -25,6 +25,23 @@ struct imx_icc_node {
> > struct dev_pm_qos_request qos_req;
> > };
> > +static int imx_icc_get_bw(struct icc_node *node, u32 *avg, u32 *peak)
> > +{
> > + *avg = 0;
> > + *peak = 0;
> > +
> > + return 0;
> > +}
> > +
> > +static int imx_icc_aggregate(struct icc_node *node, u32 tag, u32 avg_bw,
> > + u32 peak_bw, u32 *agg_avg, u32 *agg_peak)
> > +{
> > + *agg_avg = max(*agg_avg, avg_bw);
> > + *agg_peak = max(*agg_peak, peak_bw);
> > +
> > + return 0;
> > +}
> > +
> > static int imx_icc_node_set(struct icc_node *node)
> > {
> > struct device *dev = node->provider->dev;
> > @@ -233,7 +250,8 @@ int imx_icc_register(struct platform_device *pdev,
> > if (!provider)
> > return -ENOMEM;
> > provider->set = imx_icc_set;
> > - provider->aggregate = icc_std_aggregate;
> > + provider->get_bw = imx_icc_get_bw;
> > + provider->aggregate = imx_icc_aggregate;
> > provider->xlate = of_icc_xlate_onecell;
> > provider->data = data;
> > provider->dev = dev;
>
WARNING: multiple messages have this Message-ID (diff)
From: Abel Vesa <abel.vesa@nxp.com>
To: Georgi Djakov <djakov@kernel.org>
Cc: Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Fabio Estevam <festevam@gmail.com>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
NXP Linux Team <linux-imx@nxp.com>,
linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/3] interconnect: imx: Add imx_icc_get_bw and imx_icc_aggregate functions
Date: Mon, 3 Jan 2022 17:01:56 +0200 [thread overview]
Message-ID: <YdMP5P7Lwwkf6uRn@abelvesa> (raw)
In-Reply-To: <048650ad-e015-3733-bdf2-72b7a0ed61e4@kernel.org>
On 22-01-01 20:26:05, Georgi Djakov wrote:
> Hi Abel,
>
> On 1.01.22 18:39, Abel Vesa wrote:
> > The aggregate function will return whatever is the highest
> > rate for that specific node. The imx_icc_get_bw sets the
>
> Adding some more details about why we switch from
> icc_std_aggregate to imx_icc_aggregate would be nice.
>
On a second look, I think I can drop the imx_icc_aggregate and use the
icc_std_aggregate instead, as long as I use the peak_bw and forget about
the agg_bw.
> > initial avg and peak to 0 in order to avoid setting them to
> > INT_MAX by the interconnect core.
>
> Do we need a Fixes tag for this?
>
Neah, the imx interconnect is not used by any platform yet.
> I would recommend to split imx_icc_get_bw and imx_icc_aggregate
> changes into separate patches. These also seem to be unrelated to
> the imx_icc_node_adj_desc patchset.
>
Since I can use icc_std_aggregate, the imx_icc_aggregate change will be
dropped.
> Thanks,
> Georgi
>
> > Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
> > ---
> >
> > No changes since v1.
> >
> > drivers/interconnect/imx/imx.c | 20 +++++++++++++++++++-
> > 1 file changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/interconnect/imx/imx.c b/drivers/interconnect/imx/imx.c
> > index 34bfc7936387..4d8a2a2d2608 100644
> > --- a/drivers/interconnect/imx/imx.c
> > +++ b/drivers/interconnect/imx/imx.c
> > @@ -25,6 +25,23 @@ struct imx_icc_node {
> > struct dev_pm_qos_request qos_req;
> > };
> > +static int imx_icc_get_bw(struct icc_node *node, u32 *avg, u32 *peak)
> > +{
> > + *avg = 0;
> > + *peak = 0;
> > +
> > + return 0;
> > +}
> > +
> > +static int imx_icc_aggregate(struct icc_node *node, u32 tag, u32 avg_bw,
> > + u32 peak_bw, u32 *agg_avg, u32 *agg_peak)
> > +{
> > + *agg_avg = max(*agg_avg, avg_bw);
> > + *agg_peak = max(*agg_peak, peak_bw);
> > +
> > + return 0;
> > +}
> > +
> > static int imx_icc_node_set(struct icc_node *node)
> > {
> > struct device *dev = node->provider->dev;
> > @@ -233,7 +250,8 @@ int imx_icc_register(struct platform_device *pdev,
> > if (!provider)
> > return -ENOMEM;
> > provider->set = imx_icc_set;
> > - provider->aggregate = icc_std_aggregate;
> > + provider->get_bw = imx_icc_get_bw;
> > + provider->aggregate = imx_icc_aggregate;
> > provider->xlate = of_icc_xlate_onecell;
> > provider->data = data;
> > provider->dev = dev;
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-01-03 15:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-01 16:39 [PATCH v2 1/3] interconnect: imx: Switch from imx_icc_node_adj_desc to fsl,icc-id node assignment Abel Vesa
2022-01-01 16:39 ` [PATCH v2 1/3] interconnect: imx: Switch from imx_icc_node_adj_desc to fsl, icc-id " Abel Vesa
2022-01-01 16:39 ` [PATCH v2 2/3] interconnect: imx: Add imx_icc_get_bw and imx_icc_aggregate functions Abel Vesa
2022-01-01 16:39 ` Abel Vesa
2022-01-01 18:26 ` Georgi Djakov
2022-01-01 18:26 ` Georgi Djakov
2022-01-03 15:01 ` Abel Vesa [this message]
2022-01-03 15:01 ` Abel Vesa
2022-01-01 16:39 ` [PATCH v2 3/3] interconnect: imx8: Remove the imx_icc_node_adj_desc Abel Vesa
2022-01-01 16:39 ` Abel Vesa
2022-01-01 17:25 ` [PATCH v2 1/3] interconnect: imx: Switch from imx_icc_node_adj_desc to fsl,icc-id node assignment Georgi Djakov
2022-01-01 17:25 ` Georgi Djakov
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=YdMP5P7Lwwkf6uRn@abelvesa \
--to=abel.vesa@nxp.com \
--cc=djakov@kernel.org \
--cc=festevam@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@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.