On 2017/10/14 8:51, Rafael J. Wysocki wrote:
> On Saturday, September 30, 2017 9:20:30 AM CEST Aubrey Li wrote:
>> If the next idle is expected to be a fast idle, we should keep tick
>> on before going into idle
>>
>> Signed-off-by: Aubrey Li <aubrey...@linux
On 2017/10/14 8:51, Rafael J. Wysocki wrote:
> On Saturday, September 30, 2017 9:20:30 AM CEST Aubrey Li wrote:
>> If the next idle is expected to be a fast idle, we should keep tick
>> on before going into idle
>>
>> Signed-off-by: Aubrey Li
>
> This also can be merged with the previous patch
On 2017/10/14 8:35, Rafael J. Wysocki wrote:
> On Saturday, September 30, 2017 9:20:28 AM CEST Aubrey Li wrote:
>> Record the overhead of idle entry in micro-second
>>
>
> What is this needed for?
We need to figure out how long of a idle is a short idle and recording
the overhead is for this
On 2017/10/14 8:35, Rafael J. Wysocki wrote:
> On Saturday, September 30, 2017 9:20:28 AM CEST Aubrey Li wrote:
>> Record the overhead of idle entry in micro-second
>>
>
> What is this needed for?
We need to figure out how long of a idle is a short idle and recording
the overhead is for this
e corrected idle interval pattern
>> These factors are common enough to be extracted to be one function.
>>
>> Signed-off-by: Aubrey Li <aubrey...@linux.intel.com>
>
> This patch alone would break things AFAICS, because it removes code from
> menu_select() wi
On 2017/10/14 8:26, Rafael J. Wysocki wrote:
> On Saturday, September 30, 2017 9:20:27 AM CEST Aubrey Li wrote:
>> There are several factors in the menu governor to predict the next
>> idle interval:
>> - the next timer
>> - the recent idle interval history
>> - the corrected idle interval pattern
On 2017/7/19 15:55, Thomas Gleixner wrote:
> On Wed, 19 Jul 2017, Li, Aubrey wrote:
>> On 2017/7/18 15:19, Thomas Gleixner wrote:
>>> You can very well avoid it by taking the irq timings or whatever other
>>> information into account for the NOHZ decision.
>>&g
On 2017/7/19 15:55, Thomas Gleixner wrote:
> On Wed, 19 Jul 2017, Li, Aubrey wrote:
>> On 2017/7/18 15:19, Thomas Gleixner wrote:
>>> You can very well avoid it by taking the irq timings or whatever other
>>> information into account for the NOHZ decision.
>>&g
On 2017/7/19 22:48, Paul E. McKenney wrote:
> On Wed, Jul 19, 2017 at 01:44:06PM +0800, Li, Aubrey wrote:
>> On 2017/7/18 23:20, Paul E. McKenney wrote:
>>
>>>> 2) for rcu idle enter/exit, I measured the details which Paul provided, and
>>>> the result m
On 2017/7/19 22:48, Paul E. McKenney wrote:
> On Wed, Jul 19, 2017 at 01:44:06PM +0800, Li, Aubrey wrote:
>> On 2017/7/18 23:20, Paul E. McKenney wrote:
>>
>>>> 2) for rcu idle enter/exit, I measured the details which Paul provided, and
>>>> the result m
On 2017/7/18 15:19, Thomas Gleixner wrote:
> On Mon, 17 Jul 2017, Andi Kleen wrote:
>> On Tue, Jul 18, 2017 at 08:43:53AM +0200, Thomas Gleixner wrote:
>>> On Mon, 17 Jul 2017, Andi Kleen wrote:
>>>
> We need a tradeoff here IMHO. I'll check Daniel's work to understand
> how/if
> it's
On 2017/7/18 15:19, Thomas Gleixner wrote:
> On Mon, 17 Jul 2017, Andi Kleen wrote:
>> On Tue, Jul 18, 2017 at 08:43:53AM +0200, Thomas Gleixner wrote:
>>> On Mon, 17 Jul 2017, Andi Kleen wrote:
>>>
> We need a tradeoff here IMHO. I'll check Daniel's work to understand
> how/if
> it's
On 2017/7/18 23:20, Paul E. McKenney wrote:
>> 2) for rcu idle enter/exit, I measured the details which Paul provided, and
>> the result matches with what I have measured before, nothing notable found.
>> But it still makes more sense if we can make rcu idle enter/exit hooked with
>> tick off.
On 2017/7/18 23:20, Paul E. McKenney wrote:
>> 2) for rcu idle enter/exit, I measured the details which Paul provided, and
>> the result matches with what I have measured before, nothing notable found.
>> But it still makes more sense if we can make rcu idle enter/exit hooked with
>> tick off.
On 2017/7/18 14:43, Thomas Gleixner wrote:
> On Mon, 17 Jul 2017, Andi Kleen wrote:
>
>>> We need a tradeoff here IMHO. I'll check Daniel's work to understand how/if
>>> it's better than menu governor.
>>
>> I still would like to see how the fast path without the C1 heuristic works.
>>
>> Fast
On 2017/7/18 14:43, Thomas Gleixner wrote:
> On Mon, 17 Jul 2017, Andi Kleen wrote:
>
>>> We need a tradeoff here IMHO. I'll check Daniel's work to understand how/if
>>> it's better than menu governor.
>>
>> I still would like to see how the fast path without the C1 heuristic works.
>>
>> Fast
On 2017/7/18 3:48, Arjan van de Ven wrote:
> On 7/17/2017 12:23 PM, Peter Zijlstra wrote:
>> Of course, this all assumes a Gaussian distribution to begin with, if we
>> get bimodal (or worse) distributions we can still get it wrong. To fix
>> that, we'd need to do something better than what we
On 2017/7/18 3:48, Arjan van de Ven wrote:
> On 7/17/2017 12:23 PM, Peter Zijlstra wrote:
>> Of course, this all assumes a Gaussian distribution to begin with, if we
>> get bimodal (or worse) distributions we can still get it wrong. To fix
>> that, we'd need to do something better than what we
On 2017/7/18 3:23, Peter Zijlstra wrote:
> On Fri, Jul 14, 2017 at 09:26:19AM -0700, Andi Kleen wrote:
>>> And as said; Daniel has been working on a better predictor -- now he's
>>> probably not used it on the network workload you're looking at, so that
>>> might be something to consider.
>>
>>
On 2017/7/18 3:23, Peter Zijlstra wrote:
> On Fri, Jul 14, 2017 at 09:26:19AM -0700, Andi Kleen wrote:
>>> And as said; Daniel has been working on a better predictor -- now he's
>>> probably not used it on the network workload you're looking at, so that
>>> might be something to consider.
>>
>>
On 2017/7/17 21:58, Peter Zijlstra wrote:
> On Mon, Jul 17, 2017 at 09:24:51PM +0800, Li, Aubrey wrote:
>> On 2017/7/14 12:05, Paul E. McKenney wrote:
>>>
>>> More specifically: rcu_needs_cpu(), rcu_prepare_for_idle(),
>>> rcu_cleanup_after_idle(), r
On 2017/7/17 21:58, Peter Zijlstra wrote:
> On Mon, Jul 17, 2017 at 09:24:51PM +0800, Li, Aubrey wrote:
>> On 2017/7/14 12:05, Paul E. McKenney wrote:
>>>
>>> More specifically: rcu_needs_cpu(), rcu_prepare_for_idle(),
>>> rcu_cleanup_after_idle(), r
On 2017/7/17 17:21, Peter Zijlstra wrote:
> On Fri, Jul 14, 2017 at 09:03:14AM -0700, Andi Kleen wrote:
>> fast idle doesn't have an upper bound.
>>
>> If the prediction exceeds the fast idle threshold any C state can be used.
>>
>> It's just another state (fast C1), but right now it has an own
On 2017/7/17 17:21, Peter Zijlstra wrote:
> On Fri, Jul 14, 2017 at 09:03:14AM -0700, Andi Kleen wrote:
>> fast idle doesn't have an upper bound.
>>
>> If the prediction exceeds the fast idle threshold any C state can be used.
>>
>> It's just another state (fast C1), but right now it has an own
On 2017/7/14 12:05, Paul E. McKenney wrote:
>
> More specifically: rcu_needs_cpu(), rcu_prepare_for_idle(),
> rcu_cleanup_after_idle(), rcu_eqs_enter(), rcu_eqs_enter_common(),
> rcu_dynticks_eqs_enter(), do_nocb_deferred_wakeup(),
> rcu_dynticks_task_enter(), rcu_eqs_exit(),
On 2017/7/14 12:05, Paul E. McKenney wrote:
>
> More specifically: rcu_needs_cpu(), rcu_prepare_for_idle(),
> rcu_cleanup_after_idle(), rcu_eqs_enter(), rcu_eqs_enter_common(),
> rcu_dynticks_eqs_enter(), do_nocb_deferred_wakeup(),
> rcu_dynticks_task_enter(), rcu_eqs_exit(),
On 2017/7/14 2:28, Peter Zijlstra wrote:
> On Thu, Jul 13, 2017 at 11:13:28PM +0800, Li, Aubrey wrote:
>> On 2017/7/13 22:53, Peter Zijlstra wrote:
>
>>> Fixing C-state selection by creating an alternative idle path sounds so
>>> very wrong.
>>
>> This o
On 2017/7/14 2:28, Peter Zijlstra wrote:
> On Thu, Jul 13, 2017 at 11:13:28PM +0800, Li, Aubrey wrote:
>> On 2017/7/13 22:53, Peter Zijlstra wrote:
>
>>> Fixing C-state selection by creating an alternative idle path sounds so
>>> very wrong.
>>
>> This o
On 2017/7/13 23:20, Paul E. McKenney wrote:
> On Thu, Jul 13, 2017 at 04:53:11PM +0200, Peter Zijlstra wrote:
>> On Thu, Jul 13, 2017 at 10:48:55PM +0800, Li, Aubrey wrote:
>>
>>> - totally from arch_cpu_idle_enter entry to arch_cpu_idle_exit return cost
On 2017/7/13 23:20, Paul E. McKenney wrote:
> On Thu, Jul 13, 2017 at 04:53:11PM +0200, Peter Zijlstra wrote:
>> On Thu, Jul 13, 2017 at 10:48:55PM +0800, Li, Aubrey wrote:
>>
>>> - totally from arch_cpu_idle_enter entry to arch_cpu_idle_exit return cost
On 2017/7/13 22:53, Peter Zijlstra wrote:
> On Thu, Jul 13, 2017 at 10:48:55PM +0800, Li, Aubrey wrote:
>
>> - totally from arch_cpu_idle_enter entry to arch_cpu_idle_exit return costs
>> 9122ns - 15318ns.
>> In this period(arch idle), rcu_idle_ent
On 2017/7/13 22:53, Peter Zijlstra wrote:
> On Thu, Jul 13, 2017 at 10:48:55PM +0800, Li, Aubrey wrote:
>
>> - totally from arch_cpu_idle_enter entry to arch_cpu_idle_exit return costs
>> 9122ns - 15318ns.
>> In this period(arch idle), rcu_idle_ent
On 2017/7/13 16:36, Peter Zijlstra wrote:
> On Wed, Jul 12, 2017 at 02:32:40PM -0700, Andi Kleen wrote:
>
>>> It uses the normal idle path, it just makes the NOHZ enter fail.
>>
>> Which is only a small part of the problem.
>
> Given the data so far provided it was by far the biggest problem. If
On 2017/7/13 16:36, Peter Zijlstra wrote:
> On Wed, Jul 12, 2017 at 02:32:40PM -0700, Andi Kleen wrote:
>
>>> It uses the normal idle path, it just makes the NOHZ enter fail.
>>
>> Which is only a small part of the problem.
>
> Given the data so far provided it was by far the biggest problem. If
On 2017/7/12 13:03, Paul E. McKenney wrote:
> On Wed, Jul 12, 2017 at 11:19:59AM +0800, Li, Aubrey wrote:
>> On 2017/7/12 2:11, Paul E. McKenney wrote:
>>> On Tue, Jul 11, 2017 at 06:33:55PM +0200, Frederic Weisbecker wrote:
>>>> On Tue, Jul 11, 2017 at 05:58:47AM
On 2017/7/12 13:03, Paul E. McKenney wrote:
> On Wed, Jul 12, 2017 at 11:19:59AM +0800, Li, Aubrey wrote:
>> On 2017/7/12 2:11, Paul E. McKenney wrote:
>>> On Tue, Jul 11, 2017 at 06:33:55PM +0200, Frederic Weisbecker wrote:
>>>> On Tue, Jul 11, 2017 at 05:58:47AM
On 2017/7/12 0:34, Peter Zijlstra wrote:
> On Tue, Jul 11, 2017 at 06:09:27PM +0200, Frederic Weisbecker wrote:
>
- tick_nohz_idle_enter costs 7058ns - 10726ns
- tick_nohz_idle_exit costs 8372ns - 20850ns
>>>
>>> Right, those are horrible expensive, but skipping them isn't 'hard', the
On 2017/7/12 0:34, Peter Zijlstra wrote:
> On Tue, Jul 11, 2017 at 06:09:27PM +0200, Frederic Weisbecker wrote:
>
- tick_nohz_idle_enter costs 7058ns - 10726ns
- tick_nohz_idle_exit costs 8372ns - 20850ns
>>>
>>> Right, those are horrible expensive, but skipping them isn't 'hard', the
On 2017/7/12 2:11, Paul E. McKenney wrote:
> On Tue, Jul 11, 2017 at 06:33:55PM +0200, Frederic Weisbecker wrote:
>> On Tue, Jul 11, 2017 at 05:58:47AM -0700, Paul E. McKenney wrote:
>>> On Mon, Jul 10, 2017 at 09:38:34AM +0800, Aubrey Li wrote:
>>>> From: Aubrey
On 2017/7/12 2:11, Paul E. McKenney wrote:
> On Tue, Jul 11, 2017 at 06:33:55PM +0200, Frederic Weisbecker wrote:
>> On Tue, Jul 11, 2017 at 05:58:47AM -0700, Paul E. McKenney wrote:
>>> On Mon, Jul 10, 2017 at 09:38:34AM +0800, Aubrey Li wrote:
From: Aubrey Li
The system will
On 2017/7/12 0:09, Frederic Weisbecker wrote:
> On Tue, Jul 11, 2017 at 11:41:57AM +0200, Peter Zijlstra wrote:
>>
>>> - totally from arch_cpu_idle_enter entry to arch_cpu_idle_exit return costs
>>> 9122ns - 15318ns.
>>> --In this period, rcu_idle_enter costs 1985ns - 2262ns, rcu_idle_exit
On 2017/7/12 0:09, Frederic Weisbecker wrote:
> On Tue, Jul 11, 2017 at 11:41:57AM +0200, Peter Zijlstra wrote:
>>
>>> - totally from arch_cpu_idle_enter entry to arch_cpu_idle_exit return costs
>>> 9122ns - 15318ns.
>>> --In this period, rcu_idle_enter costs 1985ns - 2262ns, rcu_idle_exit
On 2017/7/12 1:58, Christoph Lameter wrote:
> On Tue, 11 Jul 2017, Frederic Weisbecker wrote:
>
>>> --- a/kernel/time/tick-sched.c
>>> +++ b/kernel/time/tick-sched.c
>>> @@ -787,6 +787,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct
>>> tick_sched *ts,
>>> if (!ts->tick_stopped) {
>>>
On 2017/7/12 1:58, Christoph Lameter wrote:
> On Tue, 11 Jul 2017, Frederic Weisbecker wrote:
>
>>> --- a/kernel/time/tick-sched.c
>>> +++ b/kernel/time/tick-sched.c
>>> @@ -787,6 +787,7 @@ static ktime_t tick_nohz_stop_sched_tick(struct
>>> tick_sched *ts,
>>> if (!ts->tick_stopped) {
>>>
On 2017/7/11 1:27, Andi Kleen wrote:
> On Mon, Jul 10, 2017 at 06:42:06PM +0200, Peter Zijlstra wrote:
>> On Mon, Jul 10, 2017 at 07:46:09AM -0700, Andi Kleen wrote:
So how much of the gain is simply due to skipping NOHZ? Mike used to
carry a patch that would throttle NOHZ. And that is a
On 2017/7/11 1:27, Andi Kleen wrote:
> On Mon, Jul 10, 2017 at 06:42:06PM +0200, Peter Zijlstra wrote:
>> On Mon, Jul 10, 2017 at 07:46:09AM -0700, Andi Kleen wrote:
So how much of the gain is simply due to skipping NOHZ? Mike used to
carry a patch that would throttle NOHZ. And that is a
On 2017/7/10 16:46, Peter Zijlstra wrote:
> On Mon, Jul 10, 2017 at 09:38:30AM +0800, Aubrey Li wrote:
>> We measured 3%~5% improvemnt in disk IO workload, and 8%~20% improvement in
>> network workload.
>
> Argh, what a mess :/
>
> So how much of the gain is simply due to skipping NOHZ?
On 2017/7/10 16:46, Peter Zijlstra wrote:
> On Mon, Jul 10, 2017 at 09:38:30AM +0800, Aubrey Li wrote:
>> We measured 3%~5% improvemnt in disk IO workload, and 8%~20% improvement in
>> network workload.
>
> Argh, what a mess :/
>
> So how much of the gain is simply due to skipping NOHZ?
On 2016/4/15 8:32, Darren Hart wrote:
> On Sun, Apr 10, 2016 at 09:46:48PM +0800, Li, Aubrey wrote:
>> On 2016/4/10 21:17, Andy Shevchenko wrote:
>>> On Thu, Mar 31, 2016 at 10:28 PM, Aubrey Li <aubrey...@linux.intel.com>
>>> wrote:
>>>> Currently
On 2016/4/15 8:32, Darren Hart wrote:
> On Sun, Apr 10, 2016 at 09:46:48PM +0800, Li, Aubrey wrote:
>> On 2016/4/10 21:17, Andy Shevchenko wrote:
>>> On Thu, Mar 31, 2016 at 10:28 PM, Aubrey Li
>>> wrote:
>>>> Currently the optional IPC resources pre
On 2016/4/11 14:48, Darren Hart wrote:
> On Mon, Apr 11, 2016 at 04:04:55AM +, Chakravarty, Souvik K wrote:
>>
>>
>>> -Original Message-
>>> From: Zha, Qipeng
>>> Sent: Monday, April 11, 2016 7:34 AM
>>> To: Darren Hart <dvh...@in
On 2016/4/11 14:48, Darren Hart wrote:
> On Mon, Apr 11, 2016 at 04:04:55AM +, Chakravarty, Souvik K wrote:
>>
>>
>>> -Original Message-
>>> From: Zha, Qipeng
>>> Sent: Monday, April 11, 2016 7:34 AM
>>> To: Darren Hart ; Aubrey Li
>>> ; Chakravarty, Souvik K
>>>
>>> Cc:
On 2016/4/10 21:17, Andy Shevchenko wrote:
> On Thu, Mar 31, 2016 at 10:28 PM, Aubrey Li <aubrey...@linux.intel.com> wrote:
>> Currently the optional IPC resources prevent telemetry driver from
>> probing if these resources are not in ACPI table. This patch decouples
>
On 2016/4/10 21:17, Andy Shevchenko wrote:
> On Thu, Mar 31, 2016 at 10:28 PM, Aubrey Li wrote:
>> Currently the optional IPC resources prevent telemetry driver from
>> probing if these resources are not in ACPI table. This patch decouples
>> telemetry driver from these optional resources, so
mismatch irq 8. 0080 (mmc0) vs. (rtc0)
So we want to statically assign IRQ numbers in ACPI hardware reduced mode to
fix this error, this also matches with the original IRQ assignment policy.
Signed-off-by: Li Aubrey
Cc: Alan Cox
Cc: Len Brown
Cc: Rafael J. Wysocki
Cc: Arjan van de
mismatch irq 8. 0080 (mmc0) vs. (rtc0)
So we want to statically assign IRQ numbers in ACPI hardware reduced mode to
fix this error, this also matches with the original IRQ assignment policy.
Signed-off-by: Li Aubrey aubrey...@linux.intel.com
Cc: Alan Cox a...@linux.intel.com
Cc: Len
On 2015/3/30 16:37, Jiang Liu wrote:
> On 2015/3/30 16:28, Li, Aubrey wrote:
>> Ying,
>>
>> can you please try this patch to see if the problem is gone on your side?
> Hi Aubrey,
> I would be better if we could change RTC driver instead.
Hey Gerry,
IRQ8 for RTC i
Ying,
can you please try this patch to see if the problem is gone on your side?
Thanks,
-Aubrey
On 2015/3/26 20:13, Li, Aubrey wrote:
> On 2015/3/25 15:22, Huang Ying wrote:
>> [ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs.
>> (rtc0)
>
&g
Ying,
can you please try this patch to see if the problem is gone on your side?
Thanks,
-Aubrey
On 2015/3/26 20:13, Li, Aubrey wrote:
On 2015/3/25 15:22, Huang Ying wrote:
[ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs.
(rtc0)
okay, I replicated this on my side
On 2015/3/30 16:37, Jiang Liu wrote:
On 2015/3/30 16:28, Li, Aubrey wrote:
Ying,
can you please try this patch to see if the problem is gone on your side?
Hi Aubrey,
I would be better if we could change RTC driver instead.
Hey Gerry,
IRQ8 for RTC is for history reason. If we
On 2015/3/25 15:22, Huang Ying wrote:
> [ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs.
> (rtc0)
okay, I replicated this on my side now.
Firstly, I don't think the patch did anything wrong. However, the patch
exposes a few issues FWICT currently:
- Should we enable
On 2015/3/25 15:22, Huang Ying wrote:
[ 28.745155] genirq: Flags mismatch irq 8. 0080 (mmc0) vs.
(rtc0)
okay, I replicated this on my side now.
Firstly, I don't think the patch did anything wrong. However, the patch
exposes a few issues FWICT currently:
- Should we enable RTC
On 2015/3/24 8:53, Huang Ying wrote:
> On Mon, 2015-03-23 at 14:18 +0800, Li, Aubrey wrote:
>> On 2015/3/20 16:38, Huang Ying wrote:
>>> FYI, we noticed the below changes on
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/
On 2015/3/20 16:38, Huang Ying wrote:
> FYI, we noticed the below changes on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> commit 7486341a98f26857f383aec88ffa10950087c3a1 ("x86/platform, acpi: Bypass
> legacy PIC and PIT in ACPI hardware reduced mode")
>
>
>
On 2015/3/20 16:38, Huang Ying wrote:
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 7486341a98f26857f383aec88ffa10950087c3a1 (x86/platform, acpi: Bypass
legacy PIC and PIT in ACPI hardware reduced mode)
On 2015/3/24 8:53, Huang Ying wrote:
On Mon, 2015-03-23 at 14:18 +0800, Li, Aubrey wrote:
On 2015/3/20 16:38, Huang Ying wrote:
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
commit 7486341a98f26857f383aec88ffa10950087c3a1 (x86
Commit-ID: 7486341a98f26857f383aec88ffa10950087c3a1
Gitweb: http://git.kernel.org/tip/7486341a98f26857f383aec88ffa10950087c3a1
Author: Li, Aubrey
AuthorDate: Wed, 11 Mar 2015 16:09:00 +0800
Committer: Ingo Molnar
CommitDate: Thu, 12 Mar 2015 12:07:13 +0100
x86/platform, acpi: Bypass
Commit-ID: 7486341a98f26857f383aec88ffa10950087c3a1
Gitweb: http://git.kernel.org/tip/7486341a98f26857f383aec88ffa10950087c3a1
Author: Li, Aubrey aubrey...@linux.intel.com
AuthorDate: Wed, 11 Mar 2015 16:09:00 +0800
Committer: Ingo Molnar mi...@kernel.org
CommitDate: Thu, 12 Mar 2015 12
hardware low idle power state(S0ix) during system
suspend. So we should bypass them in ACPI hardware reduced mode.
Suggested-by: Arjan van de Ven
Signed-off-by: Li Aubrey
Cc: Len Brown
Cc: Rafael J. Wysocki
Cc: Alan Cox
---
arch/x86/kernel/acpi/boot.c | 25 +
1 file
On 2015/3/11 14:23, Ingo Molnar wrote:
>
> * Li, Aubrey wrote:
>
>> On a platform in ACPI Hardware-reduced mode, the legacy PIC and PIT
>> may not be initialized even though they may be present in silicon.
>> Touching these legacy components causes unexpected resu
On 2015/3/11 14:23, Ingo Molnar wrote:
* Li, Aubrey aubrey...@linux.intel.com wrote:
On a platform in ACPI Hardware-reduced mode, the legacy PIC and PIT
may not be initialized even though they may be present in silicon.
Touching these legacy components causes unexpected result on system
hardware low idle power state(S0ix) during system
suspend. So we should bypass them in ACPI hardware reduced mode.
Suggested-by: Arjan van de Ven ar...@linux.intel.com
Signed-off-by: Li Aubrey aubrey...@linux.intel.com
Cc: Len Brown len.br...@intel.com
Cc: Rafael J. Wysocki rafael.j.wyso
low idle power state(S0ix) during system
suspend. So we should bypass them in ACPI hardware reduced mode.
Suggested-by: Arjan van de Ven
Signed-off-by: Li Aubrey
Cc: Len Brown
Cc: Rafael J. Wysocki
Cc: Alan Cox
---
arch/x86/kernel/acpi/boot.c | 21 +
1 file changed, 21
On 2015/3/10 16:06, Ingo Molnar wrote:
>
> * Li, Aubrey wrote:
>
>>>> - in x86_reduced_hw_init() set 'legacy_pic' to 'null_legacy_pic'
>>>>
>>>> - clean up 'global_clock_event' handling: instead of a global
>>>>variable,
low idle power state(S0ix) during system
suspend. So we should bypass them in ACPI hardware reduced mode.
Suggested-by: Arjan van de Ven ar...@linux.intel.com
Signed-off-by: Li Aubrey aubrey...@linux.intel.com
Cc: Len Brown len.br...@intel.com
Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com
Cc
On 2015/3/10 16:06, Ingo Molnar wrote:
* Li, Aubrey aubrey...@linux.intel.com wrote:
- in x86_reduced_hw_init() set 'legacy_pic' to 'null_legacy_pic'
- clean up 'global_clock_event' handling: instead of a global
variable, move its management into x86_platform_ops::get_clockevent
On 2015/3/5 20:42, Li, Aubrey wrote:
> On 2015/3/5 19:36, Ingo Molnar wrote:
>>
>> * Li, Aubrey wrote:
>>
>>> On 2015/3/5 4:11, Ingo Molnar wrote:
>>>>
>>>> * Arjan van de Ven wrote:
>>>>
>>>>> On 3/4/2015 1:50 AM,
On 2015/3/5 20:42, Li, Aubrey wrote:
On 2015/3/5 19:36, Ingo Molnar wrote:
* Li, Aubrey aubrey...@linux.intel.com wrote:
On 2015/3/5 4:11, Ingo Molnar wrote:
* Arjan van de Ven ar...@linux.intel.com wrote:
On 3/4/2015 1:50 AM, Borislav Petkov wrote:
On Wed, Mar 04, 2015 at 12:43:08AM
On 2015/3/5 19:36, Ingo Molnar wrote:
>
> * Li, Aubrey wrote:
>
>> On 2015/3/5 4:11, Ingo Molnar wrote:
>>>
>>> * Arjan van de Ven wrote:
>>>
>>>> On 3/4/2015 1:50 AM, Borislav Petkov wrote:
>>>>> On Wed, Mar 04, 20
On 2015/3/5 5:52, Rafael J. Wysocki wrote:
> On Wednesday, March 04, 2015 08:21:01 PM Alan Cox wrote:
>> On Wed, 2015-03-04 at 15:05 +0100, Borislav Petkov wrote:
>>> On Wed, Mar 04, 2015 at 03:16:07PM +0100, Rafael J. Wysocki wrote:
Sort of. What we need is a "do not touch PIC/PIT" bit for
On 2015/3/5 4:11, Ingo Molnar wrote:
>
> * Arjan van de Ven wrote:
>
>> On 3/4/2015 1:50 AM, Borislav Petkov wrote:
>>> On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van de Ven wrote:
>
> Using 'acpi_gbl_reduced_hardware' flag outside the ACPI code
> is a mistake.
On 2015/3/5 19:36, Ingo Molnar wrote:
* Li, Aubrey aubrey...@linux.intel.com wrote:
On 2015/3/5 4:11, Ingo Molnar wrote:
* Arjan van de Ven ar...@linux.intel.com wrote:
On 3/4/2015 1:50 AM, Borislav Petkov wrote:
On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van de Ven wrote:
Using
On 2015/3/5 4:11, Ingo Molnar wrote:
* Arjan van de Ven ar...@linux.intel.com wrote:
On 3/4/2015 1:50 AM, Borislav Petkov wrote:
On Wed, Mar 04, 2015 at 12:43:08AM -0800, Arjan van de Ven wrote:
Using 'acpi_gbl_reduced_hardware' flag outside the ACPI code
is a mistake.
ideally, the
On 2015/3/5 5:52, Rafael J. Wysocki wrote:
On Wednesday, March 04, 2015 08:21:01 PM Alan Cox wrote:
On Wed, 2015-03-04 at 15:05 +0100, Borislav Petkov wrote:
On Wed, Mar 04, 2015 at 03:16:07PM +0100, Rafael J. Wysocki wrote:
Sort of. What we need is a do not touch PIC/PIT bit for the code
On 2015/3/5 8:18, Rafael J. Wysocki wrote:
> On Thursday, March 05, 2015 07:50:26 AM Li, Aubrey wrote:
>> On 2015/2/13 0:24, Rafael J. Wysocki wrote:
>>> On Thursday, February 12, 2015 02:26:43 PM Peter Zijlstra wrote:
>>>>
>>>> Why bother with enter_
On 2015/2/13 0:24, Rafael J. Wysocki wrote:
> On Thursday, February 12, 2015 02:26:43 PM Peter Zijlstra wrote:
>>
>> Why bother with enter_freeze() for any but the deepest state (C6 in this
>> case)?
>
> User space may disable the deepest one (and any of them in general) via sysfs
> and there's
On 2015/3/5 8:18, Rafael J. Wysocki wrote:
On Thursday, March 05, 2015 07:50:26 AM Li, Aubrey wrote:
On 2015/2/13 0:24, Rafael J. Wysocki wrote:
On Thursday, February 12, 2015 02:26:43 PM Peter Zijlstra wrote:
Why bother with enter_freeze() for any but the deepest state (C6 in this
case
On 2015/2/13 0:24, Rafael J. Wysocki wrote:
On Thursday, February 12, 2015 02:26:43 PM Peter Zijlstra wrote:
Why bother with enter_freeze() for any but the deepest state (C6 in this
case)?
User space may disable the deepest one (and any of them in general) via sysfs
and there's no good
On 2015/3/4 13:31, Ingo Molnar wrote:
>
> * Li, Aubrey wrote:
>
>> On 2015/3/4 13:08, Ingo Molnar wrote:
>>>
>>> * Li, Aubrey wrote:
>>>
>>>> On ACPI hardware reduced platform, the legacy PIC and PIT may not be
>>>>
On 2015/3/4 13:08, Ingo Molnar wrote:
>
> * Li, Aubrey wrote:
>
>> On ACPI hardware reduced platform, the legacy PIC and PIT may not be
>> initialized even though they may be present in silicon. Touching
>> these legacy components causes unexpected result on system
power state(S0ix) during system suspend.
So we should bypass them on ACPI hardware reduced platform.
Suggested-by: Arjan van de Ven
Signed-off-by: Li Aubrey
Cc: Len Brown
Cc: Rafael J. Wysocki
---
arch/x86/kernel/irqinit.c | 6 +-
arch/x86/kernel/time.c| 3 ++-
2 files changed, 7
On 2015/3/4 13:31, Ingo Molnar wrote:
* Li, Aubrey aubrey...@linux.intel.com wrote:
On 2015/3/4 13:08, Ingo Molnar wrote:
* Li, Aubrey aubrey...@linux.intel.com wrote:
On ACPI hardware reduced platform, the legacy PIC and PIT may not be
initialized even though they may be present
On 2015/3/4 13:08, Ingo Molnar wrote:
* Li, Aubrey aubrey...@linux.intel.com wrote:
On ACPI hardware reduced platform, the legacy PIC and PIT may not be
initialized even though they may be present in silicon. Touching
these legacy components causes unexpected result on system.
On Bay
power state(S0ix) during system suspend.
So we should bypass them on ACPI hardware reduced platform.
Suggested-by: Arjan van de Ven ar...@linux.intel.com
Signed-off-by: Li Aubrey aubrey...@linux.intel.com
Cc: Len Brown len.br...@intel.com
Cc: Rafael J. Wysocki rafael.j.wyso...@intel.com
---
arch
On 2015/2/23 20:45, Andy Shevchenko wrote:
> On Tue, 2015-01-20 at 23:49 +0200, Andy Shevchenko wrote:
>> This is the reworked patch series which had been sent earlier [1] to support
>> Intel CherryTrail SoC.
>>
>> The patches were tested on both BayTrail and CherryTrail SoCs.
>>
>> [1]
On 2015/2/23 20:45, Andy Shevchenko wrote:
On Tue, 2015-01-20 at 23:49 +0200, Andy Shevchenko wrote:
This is the reworked patch series which had been sent earlier [1] to support
Intel CherryTrail SoC.
The patches were tested on both BayTrail and CherryTrail SoCs.
[1]
On 2015/2/23 20:45, Andy Shevchenko wrote:
> On Tue, 2015-01-20 at 23:49 +0200, Andy Shevchenko wrote:
>> This is the reworked patch series which had been sent earlier [1] to support
>> Intel CherryTrail SoC.
>>
>> The patches were tested on both BayTrail and CherryTrail SoCs.
>>
>> [1]
On 2015/2/23 20:45, Andy Shevchenko wrote:
On Tue, 2015-01-20 at 23:49 +0200, Andy Shevchenko wrote:
This is the reworked patch series which had been sent earlier [1] to support
Intel CherryTrail SoC.
The patches were tested on both BayTrail and CherryTrail SoCs.
[1]
On 2015/1/27 23:10, Rafael J. Wysocki wrote:
> On Tuesday, January 27, 2015 04:03:29 PM Li, Aubrey wrote:
>> On 2015/1/26 22:41, Rafael J. Wysocki wrote:
>>> On Monday, January 26, 2015 10:40:24 AM Thomas Gleixner wrote:
>>>> On Mon, 26 Jan 2015, Li, Aubrey wrote:
&g
On 2015/1/26 22:41, Rafael J. Wysocki wrote:
> On Monday, January 26, 2015 10:40:24 AM Thomas Gleixner wrote:
>> On Mon, 26 Jan 2015, Li, Aubrey wrote:
>>> On 2015/1/22 18:15, Thomas Gleixner wrote:
>
> [...]
>
>>>>> + /*
>>>>&
201 - 300 of 512 matches
Mail list logo
