From: Bai Ping <b51503@freescale.com>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: rjw@rjwysocki.net, viresh.kumar@linaro.org,
linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: [PATCH] cpufreq: imx: Add cpufreq driver for imx7D/Solo SOC
Date: Tue, 24 Nov 2015 19:08:13 +0800 [thread overview]
Message-ID: <5654451D.4000004@freescale.com> (raw)
In-Reply-To: <1448356097.3689.19.camel@pengutronix.de>
On 2015/11/24 17:08, Lucas Stach wrote:
> Am Dienstag, den 24.11.2015, 15:35 +0800 schrieb Bai Ping:
>> On 2015/11/23 17:40, Lucas Stach wrote:
>>> Am Montag, den 23.11.2015, 22:07 +0800 schrieb Bai Ping:
>>>> The i.MX7Dual/Solo is a new series of the i.MX SOC family.
>>>> The existing cpufreq driver for 'i.MX6' or 'cpufreq-dt' can
>>>> NOT match the requirement of this new SOC. This patch adds the
>>>> cpufreq driver for i.MX7Dual/Solo.
>>>>
>>> So, what are those requirements, which could not be matched with
>>> cpufreq-dt? We should really try to not add another cpufreq driver.
>> the requirement is the PLL1 used to source the CPU core clock can NOT
>> change frequency on the fly,
>> during the PLL1 frequency change, not clock output from this PLL1 in a
>> short time. this will lead to glitch
>> to the core clock. so before we change the PLL1's frequency, we must
>> switch the CPU core clock to another
>> clock source, after the PLL1 frequency has been changed, we switch back
>> core clock to PLL1.
>>> I don't see anything special in here. A single regulator and some clocks
>>> needing to be controlled in the right way. That's already handled for
>>> i.MX5 with cpufreq-dt. Please look up how it is done there and try to do
>>> it the same way for MX7, or provide substantial information why it
>>> couldn't be done.
>> I have checked the i.MX5 cpufreq, As on i.MX5, no need to take care of
>> the PLL's frequency change flow,
>> so the cpufreq-dt is the best one to support cpufreq. But on i.MX7, the
>> PLL design is not the same as on i.MX5,
>> additional steps needed in CPU frequency changing flow. the issue that
>> can NOT be tackled by cpufreq-dt is
>> additional step used by PLL frequency change.
> This is wrong, we have the step clock requirement on MX5 as well, that's
> why I asked you to look into this. The MX5 clock controller provides a
> virtual ARM clock, that implements the proper clock switch flow. This
> allows to reuse cpufreq-dt, thus reducing code duplication in the
> cpufreq drivers greatly.
Thanks for your reminder. It is my fault, I missed the imx_clk_cpu
function. I will try using cpufreq-dt
on i.MX7 just like i.MX5.
BR
Jacky Bai
>
> Regards,
> Lucas
>
WARNING: multiple messages have this Message-ID (diff)
From: Bai Ping <b51503@freescale.com>
To: Lucas Stach <l.stach@pengutronix.de>
Cc: <rjw@rjwysocki.net>, <viresh.kumar@linaro.org>,
<linux-kernel@vger.kernel.org>, <linux-pm@vger.kernel.org>
Subject: Re: [PATCH] cpufreq: imx: Add cpufreq driver for imx7D/Solo SOC
Date: Tue, 24 Nov 2015 19:08:13 +0800 [thread overview]
Message-ID: <5654451D.4000004@freescale.com> (raw)
In-Reply-To: <1448356097.3689.19.camel@pengutronix.de>
On 2015/11/24 17:08, Lucas Stach wrote:
> Am Dienstag, den 24.11.2015, 15:35 +0800 schrieb Bai Ping:
>> On 2015/11/23 17:40, Lucas Stach wrote:
>>> Am Montag, den 23.11.2015, 22:07 +0800 schrieb Bai Ping:
>>>> The i.MX7Dual/Solo is a new series of the i.MX SOC family.
>>>> The existing cpufreq driver for 'i.MX6' or 'cpufreq-dt' can
>>>> NOT match the requirement of this new SOC. This patch adds the
>>>> cpufreq driver for i.MX7Dual/Solo.
>>>>
>>> So, what are those requirements, which could not be matched with
>>> cpufreq-dt? We should really try to not add another cpufreq driver.
>> the requirement is the PLL1 used to source the CPU core clock can NOT
>> change frequency on the fly,
>> during the PLL1 frequency change, not clock output from this PLL1 in a
>> short time. this will lead to glitch
>> to the core clock. so before we change the PLL1's frequency, we must
>> switch the CPU core clock to another
>> clock source, after the PLL1 frequency has been changed, we switch back
>> core clock to PLL1.
>>> I don't see anything special in here. A single regulator and some clocks
>>> needing to be controlled in the right way. That's already handled for
>>> i.MX5 with cpufreq-dt. Please look up how it is done there and try to do
>>> it the same way for MX7, or provide substantial information why it
>>> couldn't be done.
>> I have checked the i.MX5 cpufreq, As on i.MX5, no need to take care of
>> the PLL's frequency change flow,
>> so the cpufreq-dt is the best one to support cpufreq. But on i.MX7, the
>> PLL design is not the same as on i.MX5,
>> additional steps needed in CPU frequency changing flow. the issue that
>> can NOT be tackled by cpufreq-dt is
>> additional step used by PLL frequency change.
> This is wrong, we have the step clock requirement on MX5 as well, that's
> why I asked you to look into this. The MX5 clock controller provides a
> virtual ARM clock, that implements the proper clock switch flow. This
> allows to reuse cpufreq-dt, thus reducing code duplication in the
> cpufreq drivers greatly.
Thanks for your reminder. It is my fault, I missed the imx_clk_cpu
function. I will try using cpufreq-dt
on i.MX7 just like i.MX5.
BR
Jacky Bai
>
> Regards,
> Lucas
>
next prev parent reply other threads:[~2015-11-24 11:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-23 14:07 [PATCH] cpufreq: imx: Add cpufreq driver for imx7D/Solo SOC Bai Ping
2015-11-23 14:07 ` Bai Ping
2015-11-23 9:40 ` Lucas Stach
2015-11-24 7:35 ` Bai Ping
2015-11-24 7:35 ` Bai Ping
2015-11-24 9:08 ` Lucas Stach
2015-11-24 11:08 ` Bai Ping [this message]
2015-11-24 11:08 ` Bai Ping
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=5654451D.4000004@freescale.com \
--to=b51503@freescale.com \
--cc=l.stach@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=viresh.kumar@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 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.