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] [thread-next>] [day] [month] [year] [list]

Message-ID: <536CD6BD.9000804@ti.com>
Date:	Fri, 9 May 2014 08:23:09 -0500
From:	Nishanth Menon <nm@...com>
To:	jonghwan Choi <jhbird.choi@...il.com>,
	Viresh Kumar <viresh.kumar@...aro.org>
CC:	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 05/09/2014 06:59 AM, jonghwan Choi wrote:
> On Thu, May 8, 2014 at 11:00 PM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> 
>> Why? So, as far as I got it your dividers are nothing but 0,1,2...
>> i.e.
>> Freqs: 400  500  600  700  800
>> div:      4      3      2      1      0
>>
>> right? That's what you are doing in exynos5440. So just add this in your
>> probe after doing: dev_pm_opp_init_cpufreq_table
>>
>> for(i = 0; all-available-freqs; i++)
>>     dvfs_info->freq_table[i].driver_data = dvfs_info->freq_count - i;
>>
>> And this will work with changes in dts files.
> 
> I am sorry
> I couldn’t provide detailed information about this suggestion.
> This suggestion is not for exynos5440. This is for exynos4210,
> exynos4x12 and exynos5250.
> (But this can be applied to exynos5440 also)
> I want to make exynos cpufreq driver simple.
> There are exynos-cpufreq.c, exynos4210-cpufreq.c exynos4x12-cpufreq.
> exynos5250-cpufreq.c for exynos soc.
> And exynos4210-cpufreq.c, exynos4x12 and exynos5250-cpufreq. c has a
> clk divider table for each frequency.
> 
> example) exynos4210-cpufreq.c
> static struct apll_freq apll_freq_4210[] = {
>         /*
>          * values:
>          * freq
>          * clock divider for CORE, COREM0, COREM1, PERIPH, ATB,
> PCLK_DBG, APLL, RESERVED
>          * clock divider for COPY, HPM, RESERVED
>          * PLL M, P, S
>          */
>         APLL_FREQ(1200, 0, 3, 7, 3, 4, 1, 7, 0, 5, 0, 0, 150, 3, 1),
>         APLL_FREQ(1000, 0, 3, 7, 3, 4, 1, 7, 0, 4, 0, 0, 250, 6, 1),
>         APLL_FREQ(800,  0, 3, 7, 3, 3, 1, 7, 0, 3, 0, 0, 200, 6, 1),
>         APLL_FREQ(500,  0, 3, 7, 3, 3, 1, 7, 0, 3, 0, 0, 250, 6, 2),
>         APLL_FREQ(200,  0, 1, 3, 1, 3, 1, 0, 0, 3, 0, 0, 200, 6, 3),
> };
> 
> If we can pass this clk divider value to exynos cpufreq driver through
> DT, we can remove most of exynosxxxx-cpufreq.c files/codes. And when
> new frequency is added/removed or new soc is released, for supporting
> dvfs we have only to describe frequency, voltage and divider value in
> dts file.

Have you considered the option of having a clock driver which can
decide the divider (based on dts OR index or whatever)?

example: you could do clk_set_rate(apll, rate);
and instead of implementing clock divider programmation inside cpufreq
driver, you let corresponding clock driver do it for you. that allows
you to reuse clock driver with various parameters needed for your SoC
variations. IMHO, we are trying to solve a problem meant to be solved
in clock framework instead of within cpufreq.

-- 
Regards,
Nishanth Menon
--
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/