linux-kernel - Re: [PATCH] cpufreq: imx: Add cpufreq driver for imx7D/Solo SOC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5654451D.4000004@freescale.com>
Date:	Tue, 24 Nov 2015 19:08:13 +0800
From:	Bai Ping <b51503@...escale.com>
To:	Lucas Stach <l.stach@...gutronix.de>
CC:	<rjw@...ysocki.net>, <viresh.kumar@...aro.org>,
	<linux-kernel@...r.kernel.org>, <linux-pm@...r.kernel.org>
Subject: Re: [PATCH] cpufreq: imx: Add cpufreq driver for imx7D/Solo SOC



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
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/