lkml.org 
[lkml]   [2017]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/4] cpu_cooling: Drop static-power related stuff
On 21/11/17 19:13, Eduardo Valentin wrote:
> On Tue, Nov 21, 2017 at 07:05:46PM +0100, Daniel Lezcano wrote:
>> On 21/11/2017 19:00, Javi Merino wrote:
>>> Hi,
>>>
>>> On Tue, Nov 21, 2017 at 08:57:06AM -0800, Eduardo Valentin wrote:
>>>
>>> [snip]
>>>
>>>> As I said before, the minimal you guys (ARM and Linaro) can do is to at
>>>> least upstream the Juno code! as a reference. Come on guys? what is
>>>> preventing you to upstream Juno model?
>>>
>>> As Ionela pointed out earlier in the thread, the cpufreq driver for Juno
>>> was not acceptable for mainline because it used platform specific code.
>>> When it was converted to cpufreq-dt, the static power was left behind
>>> because it can't be represented in device tree. This is because there
>>> isn't a function that works for every SoC, different process nodes
>>> (among other things) will need different functions. So it can't be just
>>> a bunch of coefficients in DT, we need a function. Hence the callback.
>>
>> The DT could contain the coef and a compatible string for a specific
>> polynomial computation callback. I imagine we should not have a lot of
>> different equations, no ?
>>
>
> Yeah, that would be another way of doing it. If there is no equation
> that correlates all processes, then we need a vendor specific entry, or
> a compatible string, as Daniel said.
>
So we have ~8 weeks (before it will vanish from mainline) to come up
with ideas
or to show that it is needed and used by some platform.
Let's see...

Regards,
Lukasz

\
 
 \ /
  Last update: 2017-11-22 00:33    [W:0.074 / U:0.144 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site