linux-kernel - Re: [PATCH 1/3] PM / OPP: Add support for descending order for cpufreq table

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]

Date:	Mon, 12 May 2014 11:48:33 +0530
From:	Viresh Kumar <viresh.kumar@...aro.org>
To:	jonghwan Choi <jhbird.choi@...il.com>
Cc:	Nishanth Menon <nm@...com>,
	Jonghwan Choi <jhbird.choi@...sung.com>,
	Linux PM list <linux-pm@...r.kernel.org>,
	open list <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <len.brown@...el.com>,
	Amit Daniel Kachhap <amit.daniel@...sung.com>
Subject: Re: [PATCH 1/3] PM / OPP: Add support for descending order for
 cpufreq table

On 11 May 2014 17:08, jonghwan Choi <jhbird.choi@...il.com> wrote:
> I already considered it.
> (But it only passes on  what cpufreq driver has to do to clock framework.
> For changing clock rate, if changing operation just divides a rate of
> parent it can be solved easily
> But exycpufreq driver is  more complicated.
>
> Previously, to change frequency, pll value and clk divider value were
> changed in cpufreq driver.
> Later someone moved the code which changes pll value to clock framework.
> In there, pll values are maintained as table per frequency. And if
> frequency is added/removed, values of
> pll table should be changed.
> when we change the pll value through clk_set_rate, internally  to find
> proper pll value,  pll table is searched.
> If proper pll value is found, that value is written into the register)
>
> My suggestion is that all these change details should be removed
> according to adding/removing frequency.
> I believe that cpufreq driver just writes a specific value per
> frequency  into the register for dvfs(Maybe other work is also needed)
>
> If we just describe the specific value per frequency in dts file, the
> driver will get that information through DT, and use it for DVFS.)
> Then when a new chip is  released(if the chip has the same h/w
> interface - register map), we only have to do as above.

We also want to make your life simple, but adding this field to OPP
table isn't the right approach for sure.

Can't you calculate the divider values at run time based on a frequency?
I think it should work. That way you can just code these calculations
in clock driver and things would work smoothly..

If there are problems, tell us what they are and we will try to find some
solution for you. .
--
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/