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? Otherwis
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 up
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 its
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. Mo
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 handling
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 for
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 from
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 case,
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 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 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 s
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 driver
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 mo
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 provide
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 i
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 cpu
18 matches
Mail list logo
