On 11 May 2014 17:08, jonghwan Choi 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.
>
On Fri, May 9, 2014 at 6:23 AM, Nishanth Menon wrote:
> 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 c
On 05/09/2014 06:59 AM, jonghwan Choi wrote:
> On Thu, May 8, 2014 at 11:00 PM, Viresh Kumar 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 i
On Thu, May 8, 2014 at 11:00 PM, Viresh Kumar 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 do
On 9 May 2014 06:39, Jonghwan Choi wrote:
> -> In exynos cpufreq driver, if we want to support more frequency, then
Don't add "->" to your replies, it doesn't make it more readable but less.
> we have to describe frequency information in dts file and have to change
> exynos cpufreq
> driver fi
On 8 May 2014 2:56 PM, Viresh Kumar wrote:
>
> Not necessarily. People may need a multiplier as well or some other
> configuration and so this stuff was left for drivers to implement.
-> In exynos cpufreq driver, if we want to support more frequency, then
we have to describe frequency informat
On 8 May 2014 07:37, Jonghwan Choi wrote:
As asked earlier by Nishanth:
- Avoid top-posting (the practice of putting your answer above the quoted
text you are responding to). It makes your response harder to read and
makes a poor impression.
Reference: Documentation/development-process/2.P
On Thu, May 8, 2014 at 7:25 AM, Nishanth Menon wrote:
>> Is it acceptiable?
>
> Personally, I feel that filling up driver_data should be left to the
> driver(caller of dev_pm_opp_init_cpufreq_table).
Exactly, and I never advised Jonghwan to update the common routine
for this. I wanted him to hand
, 2014 10:56 AM
> To: Jonghwan Choi
> Cc: Viresh Kumar; Linux PM list; open list; Rafael J. Wysocki; Len Brown;
> Amit Daniel Kachhap
> Subject: Re: [PATCH 1/3] PM / OPP: Add support for descending order for
> cpufreq table
>
> On Wed, May 7, 2014 at 8:22 PM, Jonghwan Choi
On Wed, May 7, 2014 at 8:22 PM, Jonghwan Choi wrote:
>> @Jonghwan: Please consider doing this:
>> - Don't play with the order of frequencies in table.
>> - Instead initialize .driver_data filed with values that you need to write
>> in the registers for all frequencies. i.e. 0 for highest frequency
> @Jonghwan: Please consider doing this:
> - Don't play with the order of frequencies in table.
> - Instead initialize .driver_data filed with values that you need to write
> in the registers for all frequencies. i.e. 0 for highest frequency and
> FREQ_COUNT-1 for lowest one.
-> For that, I change
On 7 May 2014 06:30, Nishanth Menon wrote:
> So, we could do [2] as default as well, if it is determined to impact
> no one else making any form of assumptions on table ordering - but it
> might be preferable for drivers not to depend on framework ordering of
> data as things could change in the f
On Tue, May 6, 2014 at 6:43 PM, Jonghwan Choi wrote:
> Hi
Please dont top post. it is usually frowned upon.
>
> My holiday is finished.
>
> I implemented another cpufreq driver. And that driver also have to use
> exynos_sort_descend_freq_table().
> Then exynos5440 and new cpufreq have a duplica
age-
> From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
> Sent: Monday, May 05, 2014 11:39 PM
> To: Nishanth Menon
> Cc: Jonghwan Choi; Linux PM list; open list; Rafael J. Wysocki; Len Brown;
> Amit Daniel Kachhap
> Subject: Re: [PATCH 1/3] PM / OPP: Add support for descending orde
On Mon, May 5, 2014 at 3:14 PM, Viresh Kumar wrote:
> On 5 May 2014 19:08, Nishanth Menon wrote:
>> With the brief history of the patch in linux-pm, I am unable to
>> understand why not just use ceil/floor routines to pick up data the
>> way you need it. It should not matter if we use an ordered
On Mon, May 5, 2014 at 9:38 AM, Viresh Kumar wrote:
> On 5 May 2014 19:53, Nishanth Menon wrote:
>> ceil and floor allows us to walk down the opp entries the direction we
>> want it to.
>> one can convert that data any way one wants it - especially when custom
>> mapping such as this is desired.
On 5 May 2014 19:53, Nishanth Menon wrote:
> ceil and floor allows us to walk down the opp entries the direction we
> want it to.
> one can convert that data any way one wants it - especially when custom
> mapping such as this is desired.
Yeah, but doing that for every frequency transition is not
On Mon, May 5, 2014 at 9:14 AM, Viresh Kumar wrote:
>
> To be precise, for exynos they need the position of a frequency when
> it is arranged in descending order. And they will simply write this position
> in their clock controller later. For example, if frequencies are:
> 100 MHz, 200, 300, 400,
On 5 May 2014 19:08, Nishanth Menon wrote:
> With the brief history of the patch in linux-pm, I am unable to
> understand why not just use ceil/floor routines to pick up data the
> way you need it. It should not matter if we use an ordered list, or
> some other weird organization inside the storag
On 05/05/2014 12:54 AM, Viresh Kumar wrote:
> On 3 May 2014 05:46, Jonghwan Choi wrote:
>> Hi. Viresh Kumar
>> Your reply is so fast like Usain Bolt.
>
> Heh, that's not true.. See how slow I was this time :)
>
>>> So, create three flags:
>>> OPP_TABLE_ORDER_ASCENDING 0
>>> OPP_TABL
On 3 May 2014 05:46, Jonghwan Choi wrote:
> Hi. Viresh Kumar
> Your reply is so fast like Usain Bolt.
Heh, that's not true.. See how slow I was this time :)
>> So, create three flags:
>> OPP_TABLE_ORDER_ASCENDING 0
>> OPP_TABLE_ORDER_DESCENDING1
>> OPP_TABLE_ORDER_ORIGIN
h.li...@gmail.com] On Behalf Of
> Viresh Kumar
> Sent: Wednesday, April 30, 2014 5:25 PM
> To: Jonghwan Choi; Linux PM list
> Cc: open list; Rafael J. Wysocki; Len Brown; Amit Daniel Kachhap
> Subject: Re: [PATCH 1/3] PM / OPP: Add support for descending order for
> cpufreq table
>
Hi,
This isn't a very big patchset and this patch is very much required to
understand other patches and so please cc all people from other
list here as well..
On Wed, Apr 30, 2014 at 11:58 AM, Jonghwan Choi wrote:
> In the frequency table dts file, the frequencies are arranged in
Improve your l
In the frequency table dts file, the frequencies are arranged in
descending order which maps 1 to 1 with other frequency parameter to
be calculated and programmed in some registers.
But the OPP library works by generating the frequencies in ascending
order which breaks the above logic.
So added OPP
24 matches
Mail list logo
