On Thursday, November 28, 2013 07:44:02 PM Viresh Kumar wrote:
> On 28 November 2013 19:42, Rafael J. Wysocki wrote:
> > On Thursday, November 28, 2013 07:11:17 PM Viresh Kumar wrote:
> >> Okay.. So wouldn't it be better that we add this special flag only when we
> >> face a real problem?
On 28 November 2013 19:42, Rafael J. Wysocki wrote:
> On Thursday, November 28, 2013 07:11:17 PM Viresh Kumar wrote:
>> Okay.. So wouldn't it be better that we add this special flag only when we
>> face a real problem? Otherwise this flag might stay unused for long time
>> and then we might end
On Thursday, November 28, 2013 07:11:17 PM Viresh Kumar wrote:
> On 28 November 2013 18:39, Rafael J. Wysocki wrote:
> > acpi-cpufreq is one at least.
> >
> > Anyway, this isn't about ACPI or anything like that, but hardware.
> > Generally
> > speaking, on modern Intel hardware the processor
On 28 November 2013 18:39, Rafael J. Wysocki wrote:
> acpi-cpufreq is one at least.
>
> Anyway, this isn't about ACPI or anything like that, but hardware. Generally
> speaking, on modern Intel hardware the processor itself chooses the frequency
> to run at and it may do that behind your back.
On Thursday, November 28, 2013 08:50:20 AM Viresh Kumar wrote:
> On 28 November 2013 01:51, Rafael J. Wysocki wrote:
> > I have a concern that on some systems you can't really say what frequency
> > you're running at the moment, however.
>
> Which ones? I know ACPI tries to play smart by
On Thursday, November 28, 2013 08:50:20 AM Viresh Kumar wrote:
On 28 November 2013 01:51, Rafael J. Wysocki r...@rjwysocki.net wrote:
I have a concern that on some systems you can't really say what frequency
you're running at the moment, however.
Which ones? I know ACPI tries to play smart
On 28 November 2013 18:39, Rafael J. Wysocki r...@rjwysocki.net wrote:
acpi-cpufreq is one at least.
Anyway, this isn't about ACPI or anything like that, but hardware. Generally
speaking, on modern Intel hardware the processor itself chooses the frequency
to run at and it may do that behind
On Thursday, November 28, 2013 07:11:17 PM Viresh Kumar wrote:
On 28 November 2013 18:39, Rafael J. Wysocki r...@rjwysocki.net wrote:
acpi-cpufreq is one at least.
Anyway, this isn't about ACPI or anything like that, but hardware.
Generally
speaking, on modern Intel hardware the
On 28 November 2013 19:42, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Thursday, November 28, 2013 07:11:17 PM Viresh Kumar wrote:
Okay.. So wouldn't it be better that we add this special flag only when we
face a real problem? Otherwise this flag might stay unused for long time
and then we
On Thursday, November 28, 2013 07:44:02 PM Viresh Kumar wrote:
On 28 November 2013 19:42, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Thursday, November 28, 2013 07:11:17 PM Viresh Kumar wrote:
Okay.. So wouldn't it be better that we add this special flag only when we
face a real
On 28 November 2013 01:51, Rafael J. Wysocki wrote:
> I have a concern that on some systems you can't really say what frequency
> you're running at the moment, however.
Which ones? I know ACPI tries to play smart by handling the frequency stuff
itself by marking CPUs not-related to each other
On Wednesday, November 27, 2013 09:22:01 PM Viresh Kumar wrote:
> On 27 November 2013 19:52, Rafael J. Wysocki wrote:
> > And here my question was: Is it safe to continue at all in that case?
>
> Hmm.. Honestly speaking I haven't thought about it earlier. And from
> the kind of inputs we got
On 27 November 2013 19:52, Rafael J. Wysocki wrote:
> And here my question was: Is it safe to continue at all in that case?
Hmm.. Honestly speaking I haven't thought about it earlier. And from
the kind of inputs we got from Nishanth its not safe at all and so we
really need a BUG_ON in this
On Wednesday, November 27, 2013 08:31:02 AM Viresh Kumar wrote:
> On 27 November 2013 01:51, Rafael J. Wysocki wrote:
> > I was talking about the case when your
> >
> > __cpufreq_driver_target(policy, policy->cur - 1, CPUFREQ_RELATION_L);
> >
> > fails. The other case is not really interesting.
On Wednesday, November 27, 2013 08:31:02 AM Viresh Kumar wrote:
On 27 November 2013 01:51, Rafael J. Wysocki r...@rjwysocki.net wrote:
I was talking about the case when your
__cpufreq_driver_target(policy, policy-cur - 1, CPUFREQ_RELATION_L);
fails. The other case is not really
On 27 November 2013 19:52, Rafael J. Wysocki r...@rjwysocki.net wrote:
And here my question was: Is it safe to continue at all in that case?
Hmm.. Honestly speaking I haven't thought about it earlier. And from
the kind of inputs we got from Nishanth its not safe at all and so we
really need a
On Wednesday, November 27, 2013 09:22:01 PM Viresh Kumar wrote:
On 27 November 2013 19:52, Rafael J. Wysocki r...@rjwysocki.net wrote:
And here my question was: Is it safe to continue at all in that case?
Hmm.. Honestly speaking I haven't thought about it earlier. And from
the kind of
On 28 November 2013 01:51, Rafael J. Wysocki r...@rjwysocki.net wrote:
I have a concern that on some systems you can't really say what frequency
you're running at the moment, however.
Which ones? I know ACPI tries to play smart by handling the frequency stuff
itself by marking CPUs not-related
On 27 November 2013 01:51, Rafael J. Wysocki wrote:
> I was talking about the case when your
>
> __cpufreq_driver_target(policy, policy->cur - 1, CPUFREQ_RELATION_L);
>
> fails. The other case is not really interesting.
Okay.. I actually thought the context of this chat is about "not fixing the
On Tuesday, November 26, 2013 07:31:50 AM Viresh Kumar wrote:
> On 26 November 2013 02:43, Rafael J. Wysocki wrote:
> > On Monday, November 25, 2013 09:43:59 AM Dirk Brandewie wrote:
> >> This is a platform specific bug fix AFAICT and belongs in a platform
> >> specific piece of code
>
> In case
On Tuesday, November 26, 2013 07:31:50 AM Viresh Kumar wrote:
On 26 November 2013 02:43, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, November 25, 2013 09:43:59 AM Dirk Brandewie wrote:
This is a platform specific bug fix AFAICT and belongs in a platform
specific piece of code
On 27 November 2013 01:51, Rafael J. Wysocki r...@rjwysocki.net wrote:
I was talking about the case when your
__cpufreq_driver_target(policy, policy-cur - 1, CPUFREQ_RELATION_L);
fails. The other case is not really interesting.
Okay.. I actually thought the context of this chat is about not
On Tuesday 26 November 2013 07:31 AM, Viresh Kumar wrote:
> Probably just throw an print message that CPU found to be running on
> out of table frequency, and that got fixed..
And here is the patch to test:
From: Viresh Kumar
Date: Mon, 18 Nov 2013 10:15:50 +0530
Subject: [PATCH] cpufreq: Make
On 26 November 2013 02:43, Rafael J. Wysocki wrote:
> On Monday, November 25, 2013 09:43:59 AM Dirk Brandewie wrote:
>> This is a platform specific bug fix AFAICT and belongs in a platform
>> specific piece of code
In case we end up doing that, we will do lots of code redundancy in
cpufreq
On Monday, November 25, 2013 09:43:59 AM Dirk Brandewie wrote:
> On 11/25/2013 09:01 AM, Viresh Kumar wrote:
> > On 25 November 2013 22:08, Dirk Brandewie wrote:
> >> IMHO this issue should be fixed in the scaling driver for the platform.
> >>
> >> The scaling driver sets policy->cur and fills in
On 11/25/2013 09:01 AM, Viresh Kumar wrote:
On 25 November 2013 22:08, Dirk Brandewie wrote:
IMHO this issue should be fixed in the scaling driver for the platform.
The scaling driver sets policy->cur and fills in the frequency table and has
Not anymore, policy->cur is set in the core for
On 25 November 2013 22:08, Dirk Brandewie wrote:
> IMHO this issue should be fixed in the scaling driver for the platform.
>
> The scaling driver sets policy->cur and fills in the frequency table and has
Not anymore, policy->cur is set in the core for most of the drivers now.
Drivers just
On 11/24/2013 08:23 PM, Viresh Kumar wrote:
Sometimes boot loaders set CPU frequency to a value outside of frequency table
present with cpufreq core. In such cases CPU might be unstable if it has to run
on that frequency for long duration of time and so its better to set it to a
frequency which
On 11/24/2013 08:23 PM, Viresh Kumar wrote:
Sometimes boot loaders set CPU frequency to a value outside of frequency table
present with cpufreq core. In such cases CPU might be unstable if it has to run
on that frequency for long duration of time and so its better to set it to a
frequency which
On 25 November 2013 22:08, Dirk Brandewie dirk.brande...@gmail.com wrote:
IMHO this issue should be fixed in the scaling driver for the platform.
The scaling driver sets policy-cur and fills in the frequency table and has
Not anymore, policy-cur is set in the core for most of the drivers now.
On 11/25/2013 09:01 AM, Viresh Kumar wrote:
On 25 November 2013 22:08, Dirk Brandewie dirk.brande...@gmail.com wrote:
IMHO this issue should be fixed in the scaling driver for the platform.
The scaling driver sets policy-cur and fills in the frequency table and has
Not anymore, policy-cur is
On Monday, November 25, 2013 09:43:59 AM Dirk Brandewie wrote:
On 11/25/2013 09:01 AM, Viresh Kumar wrote:
On 25 November 2013 22:08, Dirk Brandewie dirk.brande...@gmail.com wrote:
IMHO this issue should be fixed in the scaling driver for the platform.
The scaling driver sets policy-cur
On 26 November 2013 02:43, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Monday, November 25, 2013 09:43:59 AM Dirk Brandewie wrote:
This is a platform specific bug fix AFAICT and belongs in a platform
specific piece of code
In case we end up doing that, we will do lots of code redundancy in
On Tuesday 26 November 2013 07:31 AM, Viresh Kumar wrote:
Probably just throw an print message that CPU found to be running on
out of table frequency, and that got fixed..
And here is the patch to test:
From: Viresh Kumar viresh.ku...@linaro.org
Date: Mon, 18 Nov 2013 10:15:50 +0530
Subject:
Sometimes boot loaders set CPU frequency to a value outside of frequency table
present with cpufreq core. In such cases CPU might be unstable if it has to run
on that frequency for long duration of time and so its better to set it to a
frequency which is specified in freq-table. This also makes
Sometimes boot loaders set CPU frequency to a value outside of frequency table
present with cpufreq core. In such cases CPU might be unstable if it has to run
on that frequency for long duration of time and so its better to set it to a
frequency which is specified in freq-table. This also makes
36 matches
Mail list logo
