On 2020/11/26 6:57, Balbir Singh wrote:
> On Wed, Nov 25, 2020 at 11:12:53AM +0800, Li, Aubrey wrote:
>> On 2020/11/24 23:42, Peter Zijlstra wrote:
>>> On Mon, Nov 23, 2020 at 12:36:10PM +0800, Li, Aubrey wrote:
>>>&g
On 2020/11/26 16:32, Balbir Singh wrote:
> On Thu, Nov 26, 2020 at 11:20:41AM +0800, Li, Aubrey wrote:
>> On 2020/11/26 6:57, Balbir Singh wrote:
>>> On Wed, Nov 25, 2020 at 11:12:53AM +0800, Li, Aubrey wrote:
>>>> On 2020/11/24 23:42, Peter Zijlstra wrote:
>>&g
On 2020/11/26 16:14, Vincent Guittot wrote:
> On Wed, 25 Nov 2020 at 14:37, Li, Aubrey wrote:
>>
>> On 2020/11/25 16:31, Vincent Guittot wrote:
>>> On Wed, 25 Nov 2020 at 03:03, Li, Aubrey wrote:
>>>>
>>>> On 2020/11/25 1:01, Vincent Guittot wro
Hi Balbir,
I still placed the patch embedded in this thread, welcome any comments.
Thanks,
-Aubrey
==
>From d64455dcaf47329673903a68a9df1151400cdd7a Mon Sep 17 00:00:00 2001
From: Aubrey Li
Date: Wed, 2 Dec 2020 13:53:30 +
Hi Mel,
On 2020/11/26 20:13, Mel Gorman wrote:
> On Thu, Nov 26, 2020 at 02:57:07PM +0800, Li, Aubrey wrote:
>> Hi Robot,
>>
>> On 2020/11/25 17:09, kernel test robot wrote:
>>> Greeting,
>>>
>>> FYI, we noticed a -29.5% regression of netperf.
On 2020/12/2 22:09, Li, Aubrey wrote:
> Hi Balbir,
>
> I still placed the patch embedded in this thread, welcome any comments.
Sorry, this version needs more work, refined as below, and I realized
I should place a version number to the patch, start from v2 now.
Thanks
On 2021/3/8 19:30, Vincent Guittot wrote:
> Hi Aubrey,
>
> On Thu, 4 Mar 2021 at 14:51, Li, Aubrey wrote:
>>
>> Hi Peter,
>>
>> On 2020/12/11 23:07, Vincent Guittot wrote:
>>> On Thu, 10 Dec 2020 at 02:44, Aubrey Li wrote:
>>>>
>>&
On 2021/1/25 17:04, Mel Gorman wrote:
> On Mon, Jan 25, 2021 at 12:29:47PM +0800, Li, Aubrey wrote:
>>>>> hackbench -l 2560 -g 1 on 8 cores arm64
>>>>> v5.11-rc4 : 1.355 (+/- 7.96)
>>>>> + sis improvement : 1.923 (+/- 25%)
>>>>> + the
On 2021/1/25 18:56, Vincent Guittot wrote:
> On Mon, 25 Jan 2021 at 06:50, Aubrey Li wrote:
>>
>> A long-tail load balance cost is observed on the newly idle path,
>> this is caused by a race window between the first nr_running check
>> of the busiest runqueue and its nr_running recheck in detach_
On 2021/1/25 22:51, Vincent Guittot wrote:
> On Mon, 25 Jan 2021 at 15:00, Li, Aubrey wrote:
>>
>> On 2021/1/25 18:56, Vincent Guittot wrote:
>>> On Mon, 25 Jan 2021 at 06:50, Aubrey Li wrote:
>>>>
>>>> A long-tail load balance cost is observed
On 2021/1/15 18:08, Mel Gorman wrote:
> From: Peter Zijlstra (Intel)
>
> Instead of calculating how many (logical) CPUs to scan, compute how
> many cores to scan.
>
> This changes behaviour for anything !SMT2.
>
> Signed-off-by: Peter Zijlstra (Intel)
> Signed-off-by: Mel Gorman
> ---
> kern
On 2021/1/22 21:22, Vincent Guittot wrote:
> On Fri, 22 Jan 2021 at 11:14, Mel Gorman wrote:
>>
>> On Fri, Jan 22, 2021 at 10:30:52AM +0100, Vincent Guittot wrote:
>>> Hi Mel,
>>>
>>> On Tue, 19 Jan 2021 at 13:02, Mel Gorman
>>> wrote:
On Tue, Jan 19, 2021 at 12:33:04PM +0100, Vincent
On 2021/1/25 17:06, Mel Gorman wrote:
> On Mon, Jan 25, 2021 at 02:02:58PM +0800, Aubrey Li wrote:
>> A long-tail load balance cost is observed on the newly idle path,
>> this is caused by a race window between the first nr_running check
>> of the busiest runqueue and its nr_running recheck in deta
Hi Peter,
On 2020/12/15 0:48, Peter Zijlstra wrote:
> Hai, here them patches Mel asked for. They've not (yet) been through the
> robots, so there might be some build fail for configs I've not used.
>
> Benchmark time :-)
>
Here is the data on my side, benchmarks were tested on a x86 4 sockets s
On 2020/12/10 19:34, Mel Gorman wrote:
> On Thu, Dec 10, 2020 at 04:23:47PM +0800, Li, Aubrey wrote:
>>> I ran this patch with tbench on top of of the schedstat patches that
>>> track SIS efficiency. The tracking adds overhead so it's not a perfect
>>> perform
On 2020/12/15 0:48, Peter Zijlstra wrote:
> We compute the average cost of the total scan, but then use it as a
> per-cpu scan cost when computing the scan proportion. Fix this by
> properly computing a per-cpu scan cost.
>
> This also fixes a bug where we would terminate early (!--nr, case) and
>
On 2020/12/15 15:59, Peter Zijlstra wrote:
> On Tue, Dec 15, 2020 at 11:36:35AM +0800, Li, Aubrey wrote:
>> On 2020/12/15 0:48, Peter Zijlstra wrote:
>>> We compute the average cost of the total scan, but then use it as a
>>> per-cpu scan cost when computing the s
Hi Bao Hua,
Sorry I almost missed this message, :(
On 2020/12/14 7:29, Song Bao Hua (Barry Song) wrote:
>
> Hi Aubrey,
>
> The patch looks great. But I didn't find any hackbench improvement
> on kunpeng 920 which has 24 cores for each llc span. Llc span is also
> one numa node. The topology is
On 2020/11/23 7:54, Balbir Singh wrote:
> On Tue, Nov 17, 2020 at 06:19:44PM -0500, Joel Fernandes (Google) wrote:
>> From: Aubrey Li
>>
>> - Don't migrate if there is a cookie mismatch
>> Load balance tries to move task from busiest CPU to the
>> destination CPU. When core scheduling i
Sleep control and status registers need santity check before ACPI
install acpi_power_off to pm_power_off hook. The checking code in
acpi_enter_sleep_state() is too late, we should not allow a not-working
pm_power_off function hooked.
Signed-off-by: Aubrey Li
---
drivers/acpi/sleep.c |7 +
The Power Management Controller (PMC) controls many of the power
management features present in the SoC. This driver provides
interface to configure the Power Management Controller (PMC).
This driver exposes PMC device state and sleep state residency
via debugfs for observation:
/sys/kerne
On 2014/3/6 11:49, H. Peter Anvin wrote:
> On 03/05/2014 07:31 PM, Li, Aubrey wrote:
>> The Power Management Controller (PMC) controls many of the power
>> management features present in the SoC. This driver provides
>> interface to configure the Power Management Control
On 2014/3/6 13:28, H. Peter Anvin wrote:
> On 03/05/2014 09:21 PM, Li, Aubrey wrote:
>>>
>>> What is the reason for putting this in debugfs?
>>
>> S0ix support on Atom SoC needs all of the devices under south complex to
>> be quiesced, as well as the devi
On 2014/3/6 13:52, H. Peter Anvin wrote:
> On 03/05/2014 09:33 PM, Li, Aubrey wrote:
>>
>> These interfaces are uncommitted and don't have consumers now, I'd like
>> to keep them unstable in debugfs.
>>
>> We can change it if we received a requirement to
On 2014/3/7 0:30, H. Peter Anvin wrote:
> On 03/05/2014 09:58 PM, Li, Aubrey wrote:
>>>
>>> What we absolutely don't want to happen is someone starting to use these
>>> unstable interfaces for something other than debugging. If debugfs ever
>>&
This patch is to introduce BOOT_EFI and BOOT_CF9 in the reboot sequence
loop, to fix the reboot problem on the known Intel Bay Trail-T based
platform, for example, ASUS-T100 and Dell Venue 8/11 Pro. These
platforms don't support ACPI reboot, we expect to call EFI runtime
service to handle this case
On 2014/2/28 12:56, Matthew Garrett wrote:
> On Fri, Feb 28, 2014 at 12:11:57PM +0800, Li, Aubrey wrote:
>> This patch is to introduce BOOT_EFI and BOOT_CF9 in the reboot sequence
>> loop, to fix the reboot problem on the known Intel Bay Trail-T based
>> platform, for exampl
On 2014/2/27 7:50, Rafael J. Wysocki wrote:
> On Wednesday, February 26, 2014 10:46:37 AM Li, Aubrey wrote:
>> Sleep control and status registers need santity check before ACPI
>> install acpi_power_off to pm_power_off hook. The checking code in
>> acpi_enter_sleep_state() i
On 2014/2/28 13:56, Matthew Garrett wrote:
> On Fri, Feb 28, 2014 at 01:22:37PM +0800, Li, Aubrey wrote:
>> On 2014/2/28 12:56, Matthew Garrett wrote:
>>> EFI reboot is still somewhat unreliable - it may be safe after the
>>> recent patches to provide a 1:1 mapping.
On 2014/2/28 14:12, Matthew Garrett wrote:
> On Fri, Feb 28, 2014 at 02:07:58PM +0800, Li, Aubrey wrote:
>> On 2014/2/28 13:56, Matthew Garrett wrote:
>>> Probably, once we've got those patches landed (I've lost track of
>>> whether they're in 3.13 o
On 2014/2/28 14:23, Matthew Garrett wrote:
> On Fri, Feb 28, 2014 at 02:20:41PM +0800, Li, Aubrey wrote:
>
>> Well, I already figured that out. Reset Register Supported flag is ZERO
>> in FACP table. I attached this table for your interesting.
>
> Ok, in that case we n
On 2014/2/28 14:44, Matthew Garrett wrote:
> On Fri, Feb 28, 2014 at 02:39:56PM +0800, Li, Aubrey wrote:
>
>> Just let you know, Windows8.1 calls EFI on these boxes for reboot/shutdown.
>
> Ok, in that case we should add EFI reboot to the list once Matt's 1:1
> mappi
On 2014/3/1 1:47, H. Peter Anvin wrote:
> On 02/27/2014 10:54 PM, Li, Aubrey wrote:
>> On 2014/2/28 14:44, Matthew Garrett wrote:
>>> On Fri, Feb 28, 2014 at 02:39:56PM +0800, Li, Aubrey wrote:
>>>
>>>> Just let you know, Windows8.1 calls EFI on these boxes f
On 2014/2/28 13:33, Li, Aubrey wrote:
> On 2014/2/27 7:50, Rafael J. Wysocki wrote:
>> On Wednesday, February 26, 2014 10:46:37 AM Li, Aubrey wrote:
>>> Sleep control and status registers need santity check before ACPI
>>> install acpi_power_off to pm_power_off
On 2014/3/1 6:11, Li, Aubrey wrote:
> On 2014/3/1 1:47, H. Peter Anvin wrote:
>> On 02/27/2014 10:54 PM, Li, Aubrey wrote:
>>> On 2014/2/28 14:44, Matthew Garrett wrote:
>>>> On Fri, Feb 28, 2014 at 02:39:56PM +0800, Li, Aubrey wrote:
>>>>
>>>
On 2014/3/2 1:22, Matthew Garrett wrote:
> On Sun, Mar 02, 2014 at 01:10:46AM +0800, Li, Aubrey wrote:
>
>> Peter - Can you please clarify writing to cf9 caused some system hang.
>> If CF9 is the last way to try, that means ACPI, KBD takes no effect,
>> then if no CF9, t
On 2014/3/2 3:01, Matthew Garrett wrote:
> In fact, this is already merged
> (d2f7cbe7b26a74dbbbf8f325b2a6fd01bc34032c), so adding EFI by default
> should be fine. It'd be nice to instrument Windows on OVMF/qemu in order
> to verify the ordering used in different situations.
>
So EFI is finaliz
>
> On March 1, 2014 12:21:39 PM PST, Matthew Garrett wrote:
>> if we've hit the keyboard controller and ACPI twice, and the system is still
>> alive, and
>> if we have standard PCI ports,
>> it doesn't seem like poking them is likely to make anything actively
worse.
>
This is exactly what I
On 2014/3/2 8:39, Rafael J. Wysocki wrote:
> On Saturday, March 01, 2014 06:24:23 AM Li, Aubrey wrote:
>>>> Do we still want to set this if the check below fails? If so, then why?
>>>
>>> We know \_S5_ is valid. The fault is sleep registers, not S5 ACPI object
&
On 2014/3/2 8:33, H. Peter Anvin wrote:
> On 03/01/2014 04:26 PM, Li, Aubrey wrote:
>>>
>>> On March 1, 2014 12:21:39 PM PST, Matthew Garrett
>>> wrote:
>>>> if we've hit the keyboard controller and ACPI twice, and the system is
>>&g
On 2014/3/2 10:07, H. Peter Anvin wrote:
> On 03/01/2014 05:47 PM, Li, Aubrey wrote:
>>
>> Since we are not able to make things worse, let's make it better. So
>> Let's dig into this. For the machine hangs by CF9, it's known to work by
>> KBD, right?
Patch refined as below, welcome any comments.
Thanks,
-Aubrey
[PATCH] x86/reboot: Introduce all of the known reboot methods into the
default list
Reboot is the last service linux OS provides to the end user. We are
supposed to make this function more robust than today. This patch adds
all of the
r system reboot, so BIOS should make it
work.
If you have a system can't be rebooted by all of the known methods, we
have to figure out how to make reboot work and add the new methods.
Does this make sense?
Thanks,
-Aubrey
>
> On March 2, 2014 2:39:02 AM PST, "Li, Aubrey"
On 2014/3/3 6:26, Matthew Garrett wrote:
> On Mon, Mar 03, 2014 at 06:13:47AM +0800, Li, Aubrey wrote:
>
>> If you have a system can't be rebooted by all of the known methods, we
>> have to figure out how to make reboot work and add the new methods.
>
> The only me
On 2014/3/3 7:11, Matthew Garrett wrote:
>> So, if you are still suggesting we add EFI only, please let me know your
>> plan about adding dmidecode table and if it's acceptable to add new
>> tables, I have three waiting: ASUS-T100, Dell Venue 8 Pro, and Dell
>> Venue 11 Pro.
>
> I don't think it'
On 2014/3/3 8:18, H. Peter Anvin wrote:
> On 03/02/2014 04:07 PM, Matthew Garrett wrote:
>> On Mon, Mar 03, 2014 at 07:23:06AM +0800, Li, Aubrey wrote:
>>
>>> Windows doesn't do because there is no 32/64 mixed windows and EFI on
>>> the planet. Since the silic
On 2014/3/3 9:47, H. Peter Anvin wrote:
> We are not removing BOOT_BIOS... whether or not we have it on buy default is
> another matter.
Right, I meant I remove BOOT_BIOS from my second patch if needed.
Thanks,
-Aubrey
>
> On March 2, 2014 5:36:02 PM PST, "Li, Aubrey"
Hi David,
I'm probably too late to catch this thread. Just one question, what's
the relationship between
arch/x86/kernel/iosf_mbi.c
and
drivers/platform/x86/intel_baytrail.c
Thanks,
-Aubrey
On 2014/3/1 10:40, David E. Box wrote:
> From: "David E. Box"
>
> This patch series adds
On 2014/3/1 10:40, David E. Box wrote:
> From: "David E. Box"
>
> Make the IOSF Mailbox driver built in as it provides core functionality needed
> for new Intel SOC platforms to access the device registers on the SOC.
>
> Signed-off-by: David E. Box
> ---
> arch/x86/Kconfig |7 ++-
> 1
On 2014/3/1 10:40, David E. Box wrote:
> From: "David E. Box"
>
> Some loadable modules only need IOSF access on the platforms where it exists.
> Provide dummy functions to allow these modules to compile and load on the
> platforms where it doesn't exist.
This is not the right way, I think.
We
Do we have a conclusion here now?
Thanks,
-Aubrey
On 2014/3/3 9:49, Li, Aubrey wrote:
> On 2014/3/3 9:47, H. Peter Anvin wrote:
>> We are not removing BOOT_BIOS... whether or not we have it on buy default is
>> another matter.
>
> Right, I meant I remove BOOT_BIOS fr
On 2014/3/3 23:58, David E. Box wrote:
> On Mon, Mar 03, 2014 at 03:01:45PM +0800, Li, Aubrey wrote:
>> Hi David,
>>
>> I'm probably too late to catch this thread. Just one question, what's
>> the relationship between
>> arch/x86/kernel/ios
On 2014/2/13 2:01, dirk.brande...@gmail.com wrote:
> From: Dirk Brandewie
>
> Remove unneeded sample buffers, intel_pstate operates on the most
> recent sample only. This save some memory and make the code more
> readable.
>
> Signed-off-by: Dirk Brandewie
> ---
> drivers/cpufreq/intel_pstate
> From: Steven Rostedt [mailto:rost...@goodmis.org]
> Sent: Thursday, April 03, 2014 2:14 PM
> To: Linus Torvalds; LKML
> Cc: Ingo Molnar; H. Peter Anvin; Thomas Gleixner; Li, Aubrey; Matthew Garrett
> Subject: [BUG] x86: reboot doesn't reboot
>
> I noticed that one of my
On 2014/4/3 14:36, Du, ChangbinX wrote:
> Hi, All,
> I have a question for ftrace usage. It is that if I have a function A, then I
> want to
> know how function A is ivoked?
> I know ftrace can show me what sub-functions that A called by below steps:
> # echo function_graph > current_tracer
On 2014/4/4 0:13, Steven Rostedt wrote:
> On Thu, 03 Apr 2014 08:58:14 -0700
> "H. Peter Anvin" wrote:
>
>> On 04/03/2014 08:39 AM, Steven Rostedt wrote:
>>>
>>> Hmm, I didn't see this email. Note, this box is an old development box
>>> that Intel sent me years ago.
>>>
>>
>> Preproduction system
On 2014/4/4 7:40, Steven Rostedt wrote:
> On Fri, 04 Apr 2014 07:23:32 +0800
> "Li, Aubrey" wrote:
>
>> Can you please send the dmi table out?
>
> I already did as a gz attachment to H. Peter. You were on the Cc, did
> you not receive it?
>
Oh, I got it.
On 2014/4/4 8:12, H. Peter Anvin wrote:
> On 04/03/2014 04:52 PM, Li, Aubrey wrote:
>> On 2014/4/4 7:40, Steven Rostedt wrote:
>>> On Fri, 04 Apr 2014 07:23:32 +0800
>>> "Li, Aubrey" wrote:
>>>
>>>> Can you please send the dmi table out?
On 2014/4/4 10:16, Steven Rostedt wrote:
> On Fri, 04 Apr 2014 07:52:53 +0800
> "Li, Aubrey" wrote:
>
>> On 2014/4/4 7:40, Steven Rostedt wrote:
>>> On Fri, 04 Apr 2014 07:23:32 +0800
>>> "Li, Aubrey" wrote:
>>>
>>>
On 2014/4/4 16:00, Ingo Molnar wrote:
>
>>
>> [PATCH] x86: Try the BIOS reboot method before the PCI reboot method
>
> So, JFYI, I have put this into x86/reboot to get it tested, but it's
> not queued up for upstream yet until there's concensus.
>
> (Steve testing it wouldn't hurt either.)
>
On 2014/4/7 2:40, H. Peter Anvin wrote:
>
> No question. The question at hand is if we should do it after all other
> non-terminal (BIOS, triple) methods have been tried.
>
The reboot sequence before the change is:
(1) ACPI
(2) KEYBOARD
(3) ACPI
(4) KEYBOARD
(5) TRIPLE
The reboot sequence after
On 2014/9/17 22:17, Martin Kelly wrote:
> When compiling with CONFIG_DEBUG_FS=n, gcc emits an unused variable
> warning for pmc_atom.c because "ret" is used only within the
> CONFIG_DEBUG_FS block. This patch adds a dummy #ifdef for
> pmc_dbgfs_register when CONFIG_DEBUG_FS=n to simplify the code a
On 2014/9/25 4:32, Rafael J. Wysocki wrote:
> On Wednesday, September 24, 2014 11:19:22 PM Fu, Zhonghui wrote:
>> This is a multi-part message in MIME format.
>> --040808000309050202010005
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 7bit
>>
>>
>> On 2014/9/2
On 2014/9/26 4:08, Rafael J. Wysocki wrote:
> On Thursday, September 25, 2014 10:07:44 AM Li, Aubrey wrote:
>> On 2014/9/25 4:32, Rafael J. Wysocki wrote:
>>> On Wednesday, September 24, 2014 11:19:22 PM Fu, Zhonghui wrote:
>>>> This is a mul
On 2014/9/17 8:49, Martin Kelly wrote:
> When compiling with CONFIG_DEBUG_FS=n, gcc emits an unused variable
> warning for pmc_atom.c because "ret" is used only within the
> CONFIG_DEBUG_FS block. This patch adds a dummy #ifdef for
> pmc_dbgfs_register when CONFIG_DEBUG_FS=n to simplify the code an
On 2014/9/17 11:20, Martin Kelly wrote:
> On 09/16/2014 07:09 PM, Li, Aubrey wrote:
>>
>> Thanks to take care of this warning. How about this version?
>>
>> diff --git a/arch/x86/kernel/pmc_atom.c b/arch/x86/kernel/pmc_atom.c
>> index 0c424a6..cd91b57 100644
&g
On 2014/9/16 17:44, Mika Westerberg wrote:
> On Fri, Sep 12, 2014 at 10:36:07AM -0700, David E. Box wrote:
>> This patch implements an I2C bus sharing mechanism between the host and
>> platform
>> hardware on select Intel BayTrail SoC platforms using the XPower AXP288 PMIC.
>>
>> On these platform
On 2014/3/7 8:41, Joe Perches wrote:
> On Fri, 2014-03-07 at 08:26 +0800, Li, Aubrey wrote:
>
>> my patch is word wrapped while I was not aware, hope this one work.
>
> trivial notes:
>
Thanks for your comments, Joe. Patch refined as below:
-Aubrey
[PATCH] X86 platfor
On 2014/3/7 10:21, Joe Perches wrote:
> On Fri, 2014-03-07 at 10:08 +0800, Li, Aubrey wrote:
>
>> The Power Management Controller (PMC) controls many of the power
>> management features present in the SoC. This driver provides
>> interface to configure the Power Ma
On 2014/5/16 0:11, Mika Westerberg wrote:
> On Thu, May 15, 2014 at 11:59:46PM +0800, Li, Aubrey wrote:
>> On 2014/5/15 22:53, Andy Shevchenko wrote:
>>> On Thu, 2014-05-15 at 22:35 +0800, Li, Aubrey wrote:
>>>> On 2014/5/15 21:40, Heikki Krogerus wrote:
>>>
On 2014/5/16 15:04, Andy Shevchenko wrote:
> On Fri, 2014-05-16 at 07:29 +0800, Li, Aubrey wrote:
>> On 2014/5/16 0:11, Mika Westerberg wrote:
>>> On Thu, May 15, 2014 at 11:59:46PM +0800, Li, Aubrey wrote:
>>>> On 2014/5/15 22:53, Andy Shevchenko wrote:
>>>&
On 2014/5/16 22:45, Andy Shevchenko wrote:
> On Fri, 2014-05-16 at 21:37 +0800, Li, Aubrey wrote:
>> On 2014/5/16 15:04, Andy Shevchenko wrote:
>>> On Fri, 2014-05-16 at 07:29 +0800, Li, Aubrey wrote:
>>>> On 2014/5/16 0:11, Mika Westerberg wrote:
>>>>>
On 2014/5/15 21:40, Heikki Krogerus wrote:
> Changes since v1:
> - now using do_div() in clk_fd_recalc_rate() as suggested by Andy
> - NULL checks for clk_name allocation in acpi_lpss.c
>
> This combines two patch sets for LPSS that I had already send for
> review separately. They conflicted with
On 2014/5/15 22:53, Andy Shevchenko wrote:
> On Thu, 2014-05-15 at 22:35 +0800, Li, Aubrey wrote:
>> On 2014/5/15 21:40, Heikki Krogerus wrote:
>>> Changes since v1:
>>> - now using do_div() in clk_fd_recalc_rate() as suggested by Andy
>>> - NULL checks fo
On 2014/5/12 22:08, Daniel Lezcano wrote:
> On 05/05/2014 12:51 AM, Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki
>>
>> If freeze_enter() is called, we want to bypass the current cpuidle
>> governor and always use the deepest available (that is, not disabled)
>> C-state, because we want to s
When the wakeup attribute is set, GPIO button is supposed to set
irqflag - IRQF_NO_SUSPEND to request irq. So when the system enters
the suspend sleep mode, the GPIO irq keeps enabled and is able to
wake the system up.
The affected/tested machines include Dell Venue 11 Pro and Asus T100TA.
Signed
On 2014/4/12 21:58, Chew Chiau Ee wrote:
> From: Alan Cox
>
> Not all systems enumerate the PWM devices via ACPI. They can also be exposed
> via the PCI interface.
>
> Signed-off-by: Alan Cox
> Signed-off-by: Chew, Chiau Ee
> ---
> drivers/pwm/pwm-lpss.c | 160 +++
When the wakeup attribute is set, the GPIO button is capable of
waking up the system from sleep states, including the "freeze"
sleep state. For that to work, its driver needs to pass the
IRQF_NO_SUSPEND flag to devm_request_any_context_irq(), or the
interrupt will be disabled by suspend_device_irq
ping..
On 2014/6/30 14:07, Li, Aubrey wrote:
> From: Aubrey Li
>
> The Power Management Controller (PMC) controls many of the power
> management features present in the SoC. This driver provides the power
> off functionality and s0ix residency control, also provides the SOC
From: Aubrey Li
The Power Management Controller (PMC) controls many of the power
management features present in the SoC. This driver provides the power
off functionality and s0ix residency control, also provides the SOC
device state and platform sleep state observation via debugfs.
v3:
- split t
Disable PMC S0IX_WAKE_EN events coming from LPC block(unused) and
also from GPIO_SUS ored dedicated IRQs (must be disabled as per PMC
programming rule), GPIOSCORE ored dedicated IRQs (must be disabled
as per PMC programming rule), GPIO_SUS shared IRQ (not necessary
since the IOAPIC_DS wake event wi
The Power Management Controller (PMC) controls many of the power
management features present in the Atom SoC. This driver provides
a native power off function via PMC PCI IO port.
On some ACPI hardware-reduced platforms(e.g. ASUS-T100), ACPI sleep
registers are not valid so that (*pm_power_off)()
Add the following interfaces to exposes PMC device state and sleep
state residency via debugfs:
/sys/kernel/debugfs/pmc_atom/dev_state
/sys/kernel/debugfs/pmc_atom/sleep_state
Signed-off-by: Aubrey Li
Signed-off-by: Kasagar, Srinidhi
Reviewed-by: Rudramuni, Vishwesh M
Reviewed-b
From: Aubrey Li
The Power Management Controller (PMC) controls many of the power
management features present in the SoC. This driver provides the power
off functionality and s0ix residency control, also provides the SOC
device state and platform sleep state observation via debugfs.
v3:
- split t
The Power Management Controller (PMC) controls many of the power
management features present in the Atom SoC. This driver provides
a native power off function via PMC PCI IO port.
On some ACPI hardware-reduced platforms(e.g. ASUS-T100), ACPI sleep
registers are not valid so that (*pm_power_off)()
Disable PMC S0IX_WAKE_EN events coming from LPC block(unused) and
also from GPIO_SUS ored dedicated IRQs (must be disabled as per PMC
programming rule), GPIOSCORE ored dedicated IRQs (must be disabled
as per PMC programming rule), GPIO_SUS shared IRQ (not necessary
since the IOAPIC_DS wake event wi
Add the following interfaces to exposes PMC device state and sleep
state residency via debugfs:
/sys/kernel/debugfs/pmc_atom/dev_state
/sys/kernel/debugfs/pmc_atom/sleep_state
Signed-off-by: Aubrey Li
Signed-off-by: Kasagar, Srinidhi
Reviewed-by: Rudramuni, Vishwesh M
Reviewed-b
On 2014/7/9 20:45, Rafael J. Wysocki wrote:
> On Tuesday, July 08, 2014 05:54:35 PM Dmitry Torokhov wrote:
>> On Wed, Jul 09, 2014 at 02:59:33AM +0200, Rafael J. Wysocki wrote:
>>> On Tuesday, July 08, 2014 05:15:06 PM Dmitry Torokhov wrote:
On Wed, Jul 09, 2014 at 01:06:07AM +0200, Rafael J.
On 2014/5/5 6:51, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> If freeze_enter() is called, we want to bypass the current cpuidle
> governor and always use the deepest available (that is, not disabled)
> C-state, because we want to save as much energy as reasonably possible
> then and r
The Power Management Controller (PMC) controls many of the power
management features present in the SoC. This driver provides
interface to configure the Power Management Controller (PMC).
This driver exposes PMC device state and sleep state residency
via debugfs:
/sys/kernel/debugfs/pmc_at
ping...
On 2014/6/19 18:40, One Thousand Gnomes wrote:
> On Thu, 19 Jun 2014 08:51:25 +0800
> "Li, Aubrey" wrote:
>
>> When the wakeup attribute is set, the GPIO button is capable of
>> waking up the system from sleep states, including the "freeze"
>
ping...
On 2014/6/17 10:18, Li, Aubrey wrote:
> The Power Management Controller (PMC) controls many of the power
> management features present in the SoC. This driver provides
> interface to configure the Power Management Controller (PMC).
>
> This driver exposes PMC device state
On 2014/8/22 19:39, Mika Westerberg wrote:
> From: Mahesh Kumar P
>
> Cherrytrail/Braswell is a successor of Intel Baytrail but has slighly
> different CPU idle values and latencies.
>
> Signed-off-by: Kumar P Mahesh
> Signed-off-by: Alan Cox
> Signed-off-by: Mika Westerberg
> ---
> I learned
On 2014/8/25 18:12, Mika Westerberg wrote:
> On Fri, Aug 22, 2014 at 10:06:21PM +0800, Li, Aubrey wrote:
>> On 2014/8/22 19:39, Mika Westerberg wrote:
>>> From: Mahesh Kumar P
>>>
>>> Cherrytrail/Braswell is a successor of Intel Baytrail but has slighly
>>
On 2014/8/26 17:00, Mika Westerberg wrote:
> On Tue, Aug 26, 2014 at 10:38:32AM +0800, Li, Aubrey wrote:
>> On 2014/8/25 18:12, Mika Westerberg wrote:
>>> On Fri, Aug 22, 2014 at 10:06:21PM +0800, Li, Aubrey wrote:
>>>> On 2014/8/22 19:39, Mika Westerberg wro
The patch is based on v3.17, merged with Rafael's pm+acpi-3.18-rc1 tag from
linux-pm.git tree.
The patch is based on the patch PeterZ initially wrote.
---
Freeze is a general power saving state that processes are frozen, devices
are suspended and CPUs are in idle state. However, when the system en
The patch is based on v3.17, merged with Rafael's pm+acpi-3.18-rc1 tag from
linux-pm.git tree.
The patch is based on the patch PeterZ initially wrote.
---
Freeze is a general power saving state that processes are frozen, devices
are suspended and CPUs are in idle state. However, when the system en
On 2014/10/27 15:28, Peter Zijlstra wrote:
> On Mon, Oct 27, 2014 at 02:27:27PM +0800, Li, Aubrey wrote:
>>> Now I suppose the problem is with cpu_pause() which needs IPIs to
>>> complete? Do we really need cpuidle_pause() there?
>>> cpuidle_uninstall_handlers() s
On 2014/10/24 23:36, Peter Zijlstra wrote:
>> +
>> +static void freezer_idle(int cpu)
>> +{
>> +struct cpuidle_device *dev = __this_cpu_read(cpuidle_devices);
>> +struct cpuidle_driver *drv = cpuidle_get_cpu_driver(dev);
>> +
>> +stop_critical_timings();
>> +
>> +while (suspend_free
On 2014/10/27 15:44, Peter Zijlstra wrote:
> On Mon, Oct 27, 2014 at 02:27:27PM +0800, Li, Aubrey wrote:
>>>> +static void freezer_suspend_tk(int cpu)
>>>> {
>>>> + if (tick_do_timer_cpu != cpu)
>>>> + return;
>>>> +
>
101 - 200 of 327 matches
Mail list logo
