On Mon, 3 Aug 2015 08:43:25 +0530
Viresh Kumar wrote:
> On 01-08-15, 17:04, Viresh Kumar wrote:
> > On 31-07-15, 08:30, Radivoje Jovanovic wrote:
>
> > > I agree with you that this patch is trivial for the current
> > > implementation since the notifier, as it is currently, will
> > > enforce cp
On 01-08-15, 17:04, Viresh Kumar wrote:
> On 31-07-15, 08:30, Radivoje Jovanovic wrote:
> > I agree with you that this patch is trivial for the current
> > implementation since the notifier, as it is currently, will enforce
> > cpu_cooling policy change at every CPUFREQ_ADJUST which would cause
>
On 31-07-15, 08:30, Radivoje Jovanovic wrote:
> I just looked over the notifier in the current upstream (my patch was
> made on our production kernel which is 3.14 and has old notifier
> implementation with notifier_device in place) and I see your point.
That's disappointing. You were expected to
On Fri, 31 Jul 2015 08:48:41 +0530
Viresh Kumar wrote:
> Thanks.
>
> I will try to add more layman terms here to map cooling state with
> frequencies. So, the cooling state 0 maps to the highest frequency the
> cpufreq table supports, and the highest cooling state n maps to the
> lowest frequenc
Thanks.
I will try to add more layman terms here to map cooling state with
frequencies. So, the cooling state 0 maps to the highest frequency the
cpufreq table supports, and the highest cooling state n maps to the
lowest frequency. Right ?
On 30-07-15, 13:21, Radivoje Jovanovic wrote:
> In this c
On Thu, 30 Jul 2015 13:35:41 +0530
Viresh Kumar wrote:
Hi Viresh,
> Cc'ing Rafael as well..
>
> On 29-07-15, 17:46, Punit Agrawal wrote:
> > [ adding Viresh ]
>
> Thanks. That earned me few more patches ;)
>
> > Radivoje Jovanovic writes:
> >
> > > Hi Agarwal,
> > >
> > > On Fri, 24 Jul 201
Cc'ing Rafael as well..
On 29-07-15, 17:46, Punit Agrawal wrote:
> [ adding Viresh ]
Thanks. That earned me few more patches ;)
> Radivoje Jovanovic writes:
>
> > Hi Agarwal,
> >
> > On Fri, 24 Jul 2015 16:26:12 +0100
> > Punit Agrawal wrote:
> >
> >> Radivoje Jovanovic writes:
> >>
> >> >
On Wed, 29 Jul 2015 17:46:37 +0100
Punit Agrawal wrote:
Hi Agarwal,
> [ adding Viresh ]
>
> Radivoje Jovanovic writes:
>
> > Hi Agarwal,
> >
> > On Fri, 24 Jul 2015 16:26:12 +0100
> > Punit Agrawal wrote:
> >
> >> Radivoje Jovanovic writes:
> >>
> >> > From: Radivoje Jovanovic
> >> >
> >>
[ adding Viresh ]
Radivoje Jovanovic writes:
> Hi Agarwal,
>
> On Fri, 24 Jul 2015 16:26:12 +0100
> Punit Agrawal wrote:
>
>> Radivoje Jovanovic writes:
>>
>> > From: Radivoje Jovanovic
>> >
>> > there is no need to keep local state variable. if another driver
>> > changes the policy under o
Hi Agarwal,
On Fri, 24 Jul 2015 16:26:12 +0100
Punit Agrawal wrote:
> Radivoje Jovanovic writes:
>
> > From: Radivoje Jovanovic
> >
> > there is no need to keep local state variable. if another driver
> > changes the policy under our feet the cpu_cooling driver will
> > have the wrong state.
Radivoje Jovanovic writes:
> From: Radivoje Jovanovic
>
> there is no need to keep local state variable. if another driver
> changes the policy under our feet the cpu_cooling driver will
> have the wrong state. Get current state from the policy directly instead
>
Although the patch below looks
From: Radivoje Jovanovic
there is no need to keep local state variable. if another driver
changes the policy under our feet the cpu_cooling driver will
have the wrong state. Get current state from the policy directly instead
Signed-off-by: Radivoje Jovanovic
---
drivers/thermal/cpu_cooling.c |
12 matches
Mail list logo
