>How can we handle it, if we do not even know that it failed?
>How should the user recognize something is broken?
We probably shouldn't have used the word "fail" here.
I expect the IO and MSR accesses will always "succeed",
but they may not always have the exact effect the OS requested.
I think
Hi,
On Mon, Aug 29, 2005 at 11:03:57AM -0700, Venkatesh Pallipadi wrote:
> Yes. ACPI spec says transitions can fail. But, it doesn't fail often in
> practise. And even if it fails, I think, we should handle it without this
> read os STATUS register.
How can we handle it, if we do not even know
Hi,
On Mon, Aug 29, 2005 at 11:03:57AM -0700, Venkatesh Pallipadi wrote:
Yes. ACPI spec says transitions can fail. But, it doesn't fail often in
practise. And even if it fails, I think, we should handle it without this
read os STATUS register.
How can we handle it, if we do not even know
How can we handle it, if we do not even know that it failed?
How should the user recognize something is broken?
We probably shouldn't have used the word fail here.
I expect the IO and MSR accesses will always succeed,
but they may not always have the exact effect the OS requested.
I think we
On Sun, Aug 28, 2005 at 08:09:41PM +0200, Dominik Brodowski wrote:
> Hi,
>
> On Fri, Aug 26, 2005 at 05:10:52PM -0700, Venkatesh Pallipadi wrote:
> > /*
> > -* Then we read the 'status_register' and compare the value with the
> > -* target state's 'status' to make sure the transition
On Sun, Aug 28, 2005 at 08:09:41PM +0200, Dominik Brodowski wrote:
Hi,
On Fri, Aug 26, 2005 at 05:10:52PM -0700, Venkatesh Pallipadi wrote:
/*
-* Then we read the 'status_register' and compare the value with the
-* target state's 'status' to make sure the transition was
Hi,
On Fri, Aug 26, 2005 at 05:10:52PM -0700, Venkatesh Pallipadi wrote:
> /*
> - * Then we read the 'status_register' and compare the value with the
> - * target state's 'status' to make sure the transition was successful.
> - * Note that we'll poll for up to 1ms (100 cycles
Hi,
On Fri, Aug 26, 2005 at 05:10:52PM -0700, Venkatesh Pallipadi wrote:
/*
- * Then we read the 'status_register' and compare the value with the
- * target state's 'status' to make sure the transition was successful.
- * Note that we'll poll for up to 1ms (100 cycles of
applied to acpi test tree.
thanks,
-Len
>-Original Message-
>From: Venkatesh Pallipadi [mailto:[EMAIL PROTECTED]
>Sent: Friday, August 26, 2005 8:11 PM
>To: Andrew Morton
>Cc: linux-kernel; Brown, Len
>Subject: [PATCH] acpi-cpufreq: Remove P-state read after a
>P-
Remove P-state read status after a P-state write in normal case. As
that operation is expensive. There are no known failures of a set and we can
assume success in the common case. acpi_pstate_strict parameter can be used
to force it back on any systems that is known to have errors.
Remove P-state read status after a P-state write in normal case. As
that operation is expensive. There are no known failures of a set and we can
assume success in the common case. acpi_pstate_strict parameter can be used
to force it back on any systems that is known to have errors.
applied to acpi test tree.
thanks,
-Len
-Original Message-
From: Venkatesh Pallipadi [mailto:[EMAIL PROTECTED]
Sent: Friday, August 26, 2005 8:11 PM
To: Andrew Morton
Cc: linux-kernel; Brown, Len
Subject: [PATCH] acpi-cpufreq: Remove P-state read after a
P-state write in normal path
12 matches
Mail list logo
