On Wednesday 15 May 2019 at 12:51:57 (+0200), Daniel Lezcano wrote:
> On 15/05/2019 12:46, Quentin Perret wrote:
> > On Wednesday 15 May 2019 at 11:40:44 (+0100), Quentin Perret wrote:
>
> [ ... ]
>
> >> +#ifdef CONFIG_THERMAL_GOV_POWER_ALLOCATOR
> >> if (capacitance) {
> >>
On 15/05/2019 13:01, Quentin Perret wrote:
> On Wednesday 15 May 2019 at 12:51:57 (+0200), Daniel Lezcano wrote:
>> On 15/05/2019 12:46, Quentin Perret wrote:
>>> On Wednesday 15 May 2019 at 11:40:44 (+0100), Quentin Perret wrote:
>>
>> [ ... ]
>>
+#ifdef CONFIG_THERMAL_GOV_POWER_ALLOCATOR
On Wednesday 15 May 2019 at 12:54:10 (+0200), Daniel Lezcano wrote:
> On 15/05/2019 12:40, Quentin Perret wrote:
> > On Wednesday 15 May 2019 at 15:52:00 (+0530), Viresh Kumar wrote:
> >> On 15-05-19, 12:16, Daniel Lezcano wrote:
> >>> Viresh what do you think ?
> >>
> >> I agree with your last
On 15/05/2019 12:40, Quentin Perret wrote:
> On Wednesday 15 May 2019 at 15:52:00 (+0530), Viresh Kumar wrote:
>> On 15-05-19, 12:16, Daniel Lezcano wrote:
>>> Viresh what do you think ?
>>
>> I agree with your last suggestions. They do make sense.
>
> Good :-)
>
> So, FWIW, the below compiles
On 15/05/2019 12:46, Quentin Perret wrote:
> On Wednesday 15 May 2019 at 11:40:44 (+0100), Quentin Perret wrote:
[ ... ]
>> +#ifdef CONFIG_THERMAL_GOV_POWER_ALLOCATOR
>> if (capacitance) {
>> ret = update_freq_table(cpufreq_cdev, capacitance);
>> if (ret)
On Wednesday 15 May 2019 at 11:40:44 (+0100), Quentin Perret wrote:
> On Wednesday 15 May 2019 at 15:52:00 (+0530), Viresh Kumar wrote:
> > On 15-05-19, 12:16, Daniel Lezcano wrote:
> > > Viresh what do you think ?
> >
> > I agree with your last suggestions. They do make sense.
>
> Good :-)
>
>
On Wednesday 15 May 2019 at 15:52:00 (+0530), Viresh Kumar wrote:
> On 15-05-19, 12:16, Daniel Lezcano wrote:
> > Viresh what do you think ?
>
> I agree with your last suggestions. They do make sense.
Good :-)
So, FWIW, the below compiles w/ or w/o THERMAL_GOV_POWER_ALLOCATOR. I'll
test it and
On 15-05-19, 12:16, Daniel Lezcano wrote:
> Viresh what do you think ?
I agree with your last suggestions. They do make sense.
--
viresh
On 15/05/2019 12:07, Quentin Perret wrote:
> On Wednesday 15 May 2019 at 11:56:30 (+0200), Daniel Lezcano wrote:
>> On 15/05/2019 11:17, Quentin Perret wrote:
>>> Hi Daniel,
>>>
>>> On Wednesday 15 May 2019 at 11:06:18 (+0200), Daniel Lezcano wrote:
On 15/05/2019 10:23, Quentin Perret wrote:
On Wednesday 15 May 2019 at 11:56:30 (+0200), Daniel Lezcano wrote:
> On 15/05/2019 11:17, Quentin Perret wrote:
> > Hi Daniel,
> >
> > On Wednesday 15 May 2019 at 11:06:18 (+0200), Daniel Lezcano wrote:
> >> On 15/05/2019 10:23, Quentin Perret wrote:
> >>> In the current state, the perf_domain
On 15/05/2019 11:17, Quentin Perret wrote:
> Hi Daniel,
>
> On Wednesday 15 May 2019 at 11:06:18 (+0200), Daniel Lezcano wrote:
>> On 15/05/2019 10:23, Quentin Perret wrote:
>>> In the current state, the perf_domain struct is fully defined only when
>>> CONFIG_ENERGY_MODEL=y. Since we need to
Hi Daniel,
On Wednesday 15 May 2019 at 11:06:18 (+0200), Daniel Lezcano wrote:
> On 15/05/2019 10:23, Quentin Perret wrote:
> > In the current state, the perf_domain struct is fully defined only when
> > CONFIG_ENERGY_MODEL=y. Since we need to write code that compiles both
> > with or without
On 15/05/2019 10:23, Quentin Perret wrote:
> In the current state, the perf_domain struct is fully defined only when
> CONFIG_ENERGY_MODEL=y. Since we need to write code that compiles both
> with or without that option in the thermal framework, make sure to
> actually define the struct regardless
In the current state, the perf_domain struct is fully defined only when
CONFIG_ENERGY_MODEL=y. Since we need to write code that compiles both
with or without that option in the thermal framework, make sure to
actually define the struct regardless of the config option. That allows
to avoid using
14 matches
Mail list logo
