From: Leonard Crestez <leonard.crestez@nxp.com>
To: Alexandre Bailon <abailon@baylibre.com>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"georgi.djakov@linaro.org" <georgi.djakov@linaro.org>,
Viresh Kumar <viresh.kumar@linaro.org>
Cc: Aisheng Dong <aisheng.dong@nxp.com>,
"mturquette@baylibre.com" <mturquette@baylibre.com>,
"ptitiano@baylibre.com" <ptitiano@baylibre.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Zening Wang <zening.wang@nxp.com>,
"khilman@baylibre.com" <khilman@baylibre.com>,
"ccaione@baylibre.com" <ccaione@baylibre.com>,
Jacky Bai <ping.bai@nxp.com>, dl-linux-imx <linux-imx@nxp.com>,
Ranjani Vaidyanathan <ranjani.vaidyanathan@nxp.com>,
Ulf Hansson <ulf.hansson@linaro.org>
Subject: Re: [RFC PATCH 0/3] Add support of busfreq
Date: Fri, 15 Mar 2019 17:17:53 +0000 [thread overview]
Message-ID: <VI1PR04MB55334013173D78F365CA5E19EE440@VI1PR04MB5533.eurprd04.prod.outlook.com> (raw)
In-Reply-To: 56e96a3a-4901-c79c-e91d-6b6a0690e5b7@baylibre.com
On 3/15/19 11:31 AM, Alexandre Bailon wrote:
>>> This series is sent as RFC mostly because the current support of i.MX SoC won't
>>> benefit of busfreq framework, because the clocks' driver don't support
>>> interconnect / dram frequency scaling.
>>> As exemple, this series implements busfreq for i.MX8MM whose upstreaming
>>> is in progress. Because this relies on ATF to do the frequency scaling, it won't
>>> be hard make it work.
>> How can I test this patch series?
>> Any additional patches you can share with us?
>> Or what else we need to do to test it? We can help with it.
> Many other patches will be required to test the series.
> There are a couple of patches that updates i.MX device drivers to
> request for bandwidth (does similar thing as bus_freq_request and
> bus_freq_release).
The interconnect framework asks for bandwidth in bytes/second but in NXP
tree most requests are of the form "request_bus_freq(BUS_FREQ_HIGH);".
In many cases (ethernet) it doesn't seem you can calculate a specific
bandwidth usefully.
Instead of asking for "infinite bandwidth zero latency" to force
everything to "high" it would be nicer to "request an opp".
Power-domain bindings mentioned that consumer-devices can specify a
"required-opps" property but I've found zero users in tree. Maybe some
helpers could be written to parse that property and automatically
request ICC opp on device suspend/resume via device-links?
I know that stuff was written for genpd but it looks like a very good
fit to me.
> In addition, a patch to that allow to scale the DRAM
> frequency using CCF is required. I'm still working on this patch.
I'm not sure what you mean here, do you want a clk set_rate to change
the DRAM freq? It makes sense for DDRC to be a node in the interconnect
framework and switch OPP inside icc implementation via an ATF call.
--
Regards,
Leonard
next prev parent reply other threads:[~2019-03-15 17:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-13 19:34 [RFC PATCH 0/3] Add support of busfreq Alexandre Bailon
2019-03-13 19:34 ` [RFC PATCH 1/3] drivers: interconnect: Add a driver for i.MX SoC Alexandre Bailon
2019-06-10 22:10 ` Leonard Crestez
2019-03-13 19:34 ` [RFC PATCH 2/3] drivers: interconnect: imx: Add support of i.MX8MM Alexandre Bailon
2019-03-13 19:34 ` [RFC PATCH 3/3] dt-bindings: interconnect: Document fsl,busfreq-imx8mm bindings Alexandre Bailon
2019-03-15 2:39 ` [RFC PATCH 0/3] Add support of busfreq Aisheng Dong
2019-03-15 9:31 ` Alexandre Bailon
2019-03-15 17:17 ` Leonard Crestez [this message]
2019-04-10 5:29 ` Viresh Kumar
2019-03-15 16:17 ` Michael Turquette
2019-03-15 16:55 ` Alexandre Bailon
2019-05-14 19:34 ` Leonard Crestez
2019-06-04 8:44 ` Anson Huang
2019-06-04 20:13 ` Leonard Crestez
2019-05-03 11:19 ` Krzysztof Kozlowski
2019-05-14 6:33 ` 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=VI1PR04MB55334013173D78F365CA5E19EE440@VI1PR04MB5533.eurprd04.prod.outlook.com \
--to=leonard.crestez@nxp.com \
--cc=abailon@baylibre.com \
--cc=aisheng.dong@nxp.com \
--cc=ccaione@baylibre.com \
--cc=georgi.djakov@linaro.org \
--cc=khilman@baylibre.com \
--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=mturquette@baylibre.com \
--cc=ping.bai@nxp.com \
--cc=ptitiano@baylibre.com \
--cc=ranjani.vaidyanathan@nxp.com \
--cc=ulf.hansson@linaro.org \
--cc=viresh.kumar@linaro.org \
--cc=zening.wang@nxp.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;
as well as URLs for NNTP newsgroup(s).