9649fbfce05b0b4f90f764c571a4 Mon Sep 17 00:00:00 2001
> From: Alex Shi
> Date: Tue, 16 Aug 2016 15:29:01 +0800
> Subject: [PATCH 2/4] cpu: expose pm_qos_resume_latency for each cpu
>
> Adding /sys/devices/system/cpu/cpux/power/pm_qos_resume_latency_us for
> each of cpus. The pm_q
On 13 September 2016 at 03:04, Alex Shi wrote:
> Cc Rafael.
>
> On 09/01/2016 05:26 PM, Ulf Hansson wrote:
>> In general I think the change makes sense, although it's this last
>> piece here that I wonder about.
>>
>> Is it okay that we expose sysfs attributes to userspace that don't
>> have any e
Cc Rafael.
On 09/01/2016 05:26 PM, Ulf Hansson wrote:
> In general I think the change makes sense, although it's this last
> piece here that I wonder about.
>
> Is it okay that we expose sysfs attributes to userspace that don't
> have any effect if they change the values? Perhaps it should be the
29:01 +0800
> Subject: [PATCH 2/4] cpu: expose pm_qos_resume_latency for each cpu
>
> Adding /sys/devices/system/cpu/cpux/power/pm_qos_resume_latency_us for
> each of cpus. The pm_qos_resume_latency usage defined in
> Documentation/ABI/testing/sysfs-devices-power
>
> The c
Few commits and patch changed according to Greg's comments.
Regards
Alex
>From 186c534b0b8b9649fbfce05b0b4f90f764c571a4 Mon Sep 17 00:00:00 2001
From: Alex Shi
Date: Tue, 16 Aug 2016 15:29:01 +0800
Subject: [PATCH 2/4] cpu: expose pm_qos_resume_latency for each cpu
Adding /sys
On 09/01/2016 11:39 AM, Alex Shi wrote:
> User can set values on each of cpu, like limit 100ms on cpu0, that means
> the cpu0 response time should be in 100ms in possible idle. It similar
> with DMA_LATENCY, but that request is for all cpu. This is just for
> particular cpu, like a interrupt pine
>> @@ -376,6 +377,8 @@ int register_cpu(struct cpu *cpu, int num)
>>
>> per_cpu(cpu_sys_devices, num) = &cpu->dev;
>> register_cpu_under_node(num, cpu_to_node(num));
>> +if (dev_pm_qos_expose_latency_limit(&cpu->dev, 0))
>> +pr_debug("CPU%d: add resume latency failed\n"
On Thu, Aug 25, 2016 at 04:42:40PM +0800, Alex Shi wrote:
> The cpu-dma PM QoS constraint impacts all the cpus in the system. There
> is no way to let the user to choose a PM QoS constraint per cpu.
>
> The following patch exposes to the userspace a per cpu based sysfs file
> in order to let the u
Hi,
Is there any concern on this patch?
Regards
Alex
On 08/25/2016 04:42 PM, Alex Shi wrote:
> The cpu-dma PM QoS constraint impacts all the cpus in the system. There
> is no way to let the user to choose a PM QoS constraint per cpu.
>
> The following patch exposes to the userspace a per cpu b
The cpu-dma PM QoS constraint impacts all the cpus in the system. There
is no way to let the user to choose a PM QoS constraint per cpu.
The following patch exposes to the userspace a per cpu based sysfs file
in order to let the userspace to change the value of the PM QoS latency
constraint.
This
Add a pr_debug for failure output.
>From dc5111ed3974f994a9f1d88fdd8dc813359a3b6c Mon Sep 17 00:00:00 2001
From: Alex Shi
Date: Tue, 16 Aug 2016 15:29:01 +0800
Subject: [PATCH 2/4] cpu: expose pm_qos_resume_latency for each cpu
The cpu-dma PM QoS constraint impacts all the cpus in the sys
The cpu-dma PM QoS constraint impacts all the cpus in the system. There
is no way to let the user to choose a PM QoS constraint per cpu.
The following patch exposes to the userspace a per cpu based sysfs file
in order to let the userspace to change the value of the PM QoS latency
constraint.
This
12 matches
Mail list logo
