gt;>>> This has been tested on three arm64 servers, with and without DMI, with
>>>> and without CPPC support.
>>>>
>>>> Changes for v5:
>>>> -- Move code to cpufreq/cppc_cpufreq.c from acpi/cppc_acpi.c to keep
>>>>frequency-related code together, and keep the CPPC abstract scale
>>>>in ACPI (Prashanth Prakash)
>>>> -- Fix the scaling to remove the incorrect assumption that frequency
>>>>was always a range from zero to max; as a practical matter, it is
>>>>not (Prasanth Prakash); this also allowed us to remove an over-
>>>>engineered function to do this math.
>>>>
This addresses my previous feedback. So FWIW, Acked-by: Ashwin
Chaugule
Cheers,
Ashwin.
l exclusivity there, otherwise the OS
and platform could step on each other. Perhaps Prashanth has better
insight into this.
>
> On Tue, May 31, 2016 at 12:05 PM, Ashwin Chaugule
> wrote:
>> On 19 May 2016 at 20:32, Hoan Tran wrote:
>>> ACPI 6.1 has a PCC HW-Reduced Commu
fail" can create this issue but
> "acpi_get_psd() fail" also creates it
>
> Thanks
> Hoan
Just for future reference. :)
https://web.archive.org/web/20080722025748/http://www.zip.com.au/~akpm/linux/patches/stuff/top-posting.txt
>
> On Fri, May 27, 2016 at 9:10 AM,
Hi Hoan,
On 19 May 2016 at 20:32, Hoan Tran wrote:
> ACPI 6.1 has a PCC HW-Reduced Communication Subspace type 2 intended for
> use on HW-Reduce ACPI Platform, which requires read-modify-write sequence
> to acknowledge doorbell interrupt. This patch provides the implementation
> for the Communica
On 25 May 2016 at 15:09, Hoan Tran wrote:
> When CPPC fails to request PCC channel, the CPC data is freed
> and cpc_desc_ptr points to the invalid data. This change prevents
> this issue by moving cpc_desc_ptr assignment after PCC channel
> request.
>
> Signed-off-by: Hoan Tran
> ---
> drivers/a
On 11 May 2016 at 14:15, Hoan Tran wrote:
> On Wed, May 11, 2016 at 4:57 AM, Ashwin Chaugule
> wrote:
>> On 11 May 2016 at 00:21, Hoan Tran wrote:
>>> On Tue, May 10, 2016 at 5:00 AM, Ashwin Chaugule
>>>> On 6 May 2016 at 14:38, Hoan Tran wrote:
>>>&
On 11 May 2016 at 00:21, Hoan Tran wrote:
> Hi Ashwin,
Hi,
> On Tue, May 10, 2016 at 5:00 AM, Ashwin Chaugule
>> On 6 May 2016 at 14:38, Hoan Tran wrote:
>>> From: hotran
>>>
>>> ACPI 6.1 has a PCC HW-Reduced Communication Subspace Type 2 intended for
&g
Hello,
On 6 May 2016 at 14:38, Hoan Tran wrote:
> From: hotran
>
> ACPI 6.1 has a PCC HW-Reduced Communication Subspace Type 2 intended for
> use on HW-Reduce ACPI Platform, which requires read-modify-write sequence
> to acknowledge doorbell interrupt. This patch provides the implementation
> fo
+ Ryan
Hi Al,
On 18 April 2016 at 20:11, Al Stone wrote:
> When CPPC is being used by ACPI on arm64, user space tools such as
> cpupower report CPU frequency values from sysfs that are incorrect.
>
> What the driver was doing was reporting the values given by ACPI tables
> in whatever scale was
On 12 February 2016 at 11:15, Rafael J. Wysocki wrote:
> On Fri, Feb 12, 2016 at 5:01 PM, Rafael J. Wysocki wrote:
>> On Fri, Feb 12, 2016 at 3:10 PM, Peter Zijlstra wrote:
>>> On Thu, Feb 11, 2016 at 10:52:20AM -0800, Steve Muckle wrote:
On 02/11/2016 09:30 AM, Peter Zijlstra wrote:
>
return &pcc_mbox_channels[id];
> }
>
Strange that we didn't catch this even with a non-zero id. But the
change makes sense so..
Acked-by: Ashwin Chaugule
Thanks,
Ashwin.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi Viresh,
On 30 October 2015 at 22:36, Viresh Kumar wrote:
> Hi Ashwin,
>
> On 30-10-15, 16:46, Ashwin Chaugule wrote:
>> On 29 October 2015 at 08:27, Viresh Kumar wrote:
>> > This could be made lightweight by keeping per-cpu deferred timers with a
>> > single
Hi Viresh,
On 29 October 2015 at 08:27, Viresh Kumar wrote:
> cpufreq governors evaluate load at sampling rate and based on that they
> update frequency for a group of CPUs belonging to the same cpufreq
> policy.
>
> This is required to be done in a single thread for all policy->cpus, but
> becau
+ Prashanth (who has successfully run this patch on Qcomm hardware)
On 16 September 2015 at 09:59, Sudeep Holla wrote:
> ACPI 6.0 introduced an optional object _LPI that provides an alternate
> method to describe Low Power Idle states. It defines the local power
> states for each node in a hierar
Hi Sudeep,
On 16 September 2015 at 09:59, Sudeep Holla wrote:
> ACPI 6.0 introduced an optional object _LPI that provides an alternate
> method to describe Low Power Idle states. It defines the local power
> states for each node in a hierarchical processor topology. The OSPM can
> use _LPI object
Hi Sudeep,
On 16 September 2015 at 09:59, Sudeep Holla wrote:
> ACPI 6.0 adds a new method to specify the CPU idle states(C-states)
> called Low Power Idle(LPI) states. Since new architectures like ARM64
> use only LPIs, introduce ARCH_SUPPORTS_ACPI_PROCESSOR_CSTATE to
> encapsulate all the code
Hello,
On 9 September 2015 at 22:26, kernel test robot wrote:
> FYI, we noticed the below changes on
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> commit d3c68f218f927bd4b14b586ea2dcecee54cf09ad ("PCC: Initialize PCC Mailbox
> earlier at boot")
>
> We found the
Hello,
On 26 August 2015 at 20:35, kernel test robot wrote:
> FYI, we noticed the below changes on
>
> git://internal_merge_and_test_tree devel-catchup-201508251337
> commit 239708a3af44064366f1af0eea02dc1e8991c11b ("ACPI: Split out ACPI PSS
> from ACPI Processor driver")
>
> We found the follow
On 26 May 2015 at 11:18, Will Deacon wrote:
> On Tue, May 26, 2015 at 04:02:56PM +0100, Ashwin Chaugule wrote:
>> On 26 May 2015 at 08:28, Will Deacon wrote:
>> > On Mon, May 25, 2015 at 11:03:13AM +0100, fu@linaro.org wrote:
>> >> From: Fu Wei
>>
Hi Will,
On 26 May 2015 at 08:28, Will Deacon wrote:
> On Mon, May 25, 2015 at 11:03:13AM +0100, fu@linaro.org wrote:
>> From: Fu Wei
>>
>> Parse SBSA Generic Watchdog Structure in GTDT table of ACPI,
>> and create a platform device with that information.
>> This platform device can be used
Hello,
On 6 May 2015 at 10:31, Sudeep Holla wrote:
> Similar to the idle, thermal and throttling libraries, always compile
> the perflib if CONFIG_ACPI_PROCESSOR is enabled. This not only makes
> perflib alligned with other libraries but also helps in some sanity
> testing of these ACPI methods
On 13 March 2015 at 05:12, Julia Lawall wrote:
> Hello,
>
> The patch 86c22f8c9a3b from Wed Nov 12 19:59:38 2014 in linux-next
> introduces a file that contains two exported functions:
> pcc_mbox_request_channel and pcc_mbox_free_channel. As far as I can see,
> these functions are not used by any
On 24 February 2015 at 12:23, Ashwin Chaugule
wrote:
> On 20 February 2015 at 15:16, Stephen Boyd wrote:
>> On 02/20, Will Deacon wrote:
>>> On Fri, Feb 13, 2015 at 06:24:09PM +, Stephen Boyd wrote:
>>>
>>> > +static void scor
On 20 February 2015 at 15:16, Stephen Boyd wrote:
> On 02/20, Will Deacon wrote:
>> On Fri, Feb 13, 2015 at 06:24:09PM +, Stephen Boyd wrote:
>>
>> > +static void scorpion_evt_setup(int idx, u32 config_base)
>> > +{
>> > + u32 val;
>> > + u32 mask;
>> > + u32 vval, fval;
>> >
On 11 February 2015 at 13:27, Stephen Boyd wrote:
> On 02/10, Ashwin Chaugule wrote:
>> Hi Stephen,
>>
>> On 10 February 2015 at 20:05, Stephen Boyd wrote:
>> > Scorpion supports a set of local performance monitor event
>> > selection registers (LPM
vent number is a pure software construct that
> allows us to map the multi-dimensional number space of regions,
> groups, and event codes into a flat event number space suitable
> for use by the perf framework.
>
> This is based on code originally written by Ashwin Chaugule and
> Neil
On 16 December 2014 at 06:36, Sudeep Holla wrote:
> On Fri, Dec 12, 2014 at 05:47:26PM +0000, Ashwin Chaugule wrote:
>> On 12 December 2014 at 03:43, Sudeep Holla wrote:
>> > On Thursday 11 December 2014 01:46 AM, Ashwin Chaugule wrote:
>> >>
>> >> If a
On 12 December 2014 at 05:21, Jassi Brar wrote:
> On 11 December 2014 at 01:46, Ashwin Chaugule
> wrote:
>> If a wait_for_completion_timeout() call returns due to a timeout,
>> the mbox code can still call complete() after returning from the wait.
>> This can cause subse
On 12 December 2014 at 03:43, Sudeep Holla wrote:
> Hi Ashwin,
Hi,
> On Thursday 11 December 2014 01:46 AM, Ashwin Chaugule wrote:
>>
>> If a wait_for_completion_timeout() call returns due to a timeout,
>> the mbox code can still call complete() after returning from the
erroneous complete() call, and immediately
returns without waiting for the time as expected by the client.
Fix this by calling complete() only if the TX was successful.
Signed-off-by: Ashwin Chaugule
---
drivers/mailbox/mailbox.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
On 25 September 2014 20:57, Jassi Brar wrote:
> On 24 September 2014 09:14, Ashwin Chaugule
> wrote:
>> On 22 September 2014 14:33, Sudeep Holla wrote:
>
>>>>>> +static void poll_txdone(unsigned long data)
>>>>>> +{
>>>>>>
On 22 September 2014 14:33, Sudeep Holla wrote:
> On 22/09/14 19:15, Sudeep Holla wrote:
>> On 22/09/14 19:01, Ashwin Chaugule wrote:
>>>
>>> Hi Jassi,
>>>
>>> On 1 August 2014 08:31, Jassi Brar wrote:
>>>>
>>>> Introduce com
Hi Jassi,
On 1 August 2014 08:31, Jassi Brar wrote:
> Introduce common framework for client/protocol drivers and
> controller drivers of Inter-Processor-Communication (IPC).
>
> Client driver developers should have a look at
> include/linux/mailbox_client.h to understand the part of
> the API ex
On 10 September 2014 13:31, Dirk Brandewie wrote:
> On 09/10/2014 09:11 AM, Ashwin Chaugule wrote:
>> On 10 September 2014 11:44, Dirk Brandewie
>> With the current split I think you will still be able to maintain
>> Intel specific changes for the future in the ba
On 10 September 2014 11:44, Dirk Brandewie wrote:
> Hi Ashwin,
Hi Dirk,
>
> I think the CPPC based driver should be a separate driver.
>
> We made the conscious decision to not use any of the ACPI mechanisms
> to enumerate or control P state selection. Experience over the years
> has shown that
The Baytrail series uses additional information while
setting a target CPU performance value. To keep the PID governor
generic, move this out into the platform specific backend driver.
Signed-off-by: Ashwin Chaugule
---
drivers/cpufreq/intel_pid_ctrl.c | 57
Move X86 specific turbo detection logic into platform
specific PID backend driver.
Signed-off-by: Ashwin Chaugule
---
drivers/cpufreq/intel_pid_ctrl.c | 15 ++-
drivers/cpufreq/pid_ctrl.c | 13 +++--
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a
multiple
registers at once. In contrast, we'd have to ring the Doorbell
for every register Read.
Signed-off-by: Ashwin Chaugule
---
drivers/cpufreq/intel_pid_ctrl.c | 49 ++--
drivers/cpufreq/pid_ctrl.c | 34 ++--
drivers/cp
PID backend interfaces using CPPC semantics.
Signed-off-by: Ashwin Chaugule
---
drivers/cpufreq/Kconfig | 10 +
drivers/cpufreq/Makefile| 1 +
drivers/cpufreq/cppc_pid_ctrl.c | 406
3 files changed, 417 insertions(+)
create mode 100644
Aperf/Mperf are very X86 specific names but effectively
count Delivered and Reference Cpu performance values.
Signed-off-by: Ashwin Chaugule
---
drivers/cpufreq/intel_pid_ctrl.c | 12 ++--
drivers/cpufreq/pid_ctrl.c | 10 +-
drivers/cpufreq/pid_ctrl.h | 8
contoller.
The PID governor still has a few X86 specific things which are moved
out in the following patch.
Signed-off-by: Ashwin Chaugule
---
Documentation/cpu-freq/intel-pstate.txt | 43 --
Documentation/cpu-freq/pid_ctrl.txt | 41 ++
drivers/cpufreq/Kconfig |9
/
[2] - http://www.uefi.org/sites/default/files/resources/ACPI_5_1release.pdf
[3] - http://comments.gmane.org/gmane.linux.acpi.devel/70299
[4] -
http://git.linaro.org/people/ashwin.chaugule/leg-kernel.git/shortlog/refs/heads/cppc-pid-no_freq_domain
Ashwin Chaugule (6):
PID Controller governor
Hi Len,
On 15 August 2014 18:11, Len Brown wrote:
> The Linux team at Intel did not implement ACPI CPPC support
> because we see no benefit to it over the native hardware interface on x86.
>
Thanks for sharing Intels observations. I had looked at the SDM [1]
and found all the CPPC MSRs. I suppos
Hello,
On 15 August 2014 10:41, Peter Zijlstra wrote:
> On Fri, Aug 15, 2014 at 10:37:32AM -0400, Ashwin Chaugule wrote:
>> On 15 August 2014 10:07, Peter Zijlstra wrote:
>> > On Fri, Aug 15, 2014 at 09:08:50AM -0400, Ashwin Chaugule wrote:
>> >> If the OS
Hello,
On 15 August 2014 11:47, Arjan van de Ven wrote:
> On 8/15/2014 7:24 AM, Ashwin Chaugule wrote:
>>>> we've found that so far that there are two reasonable options
>>>> 1) Let the OS device (old style)
>>>> 2) Let the hardware decide (new style
Hi Peter,
On 15 August 2014 10:07, Peter Zijlstra wrote:
> On Fri, Aug 15, 2014 at 09:08:50AM -0400, Ashwin Chaugule wrote:
>> If the OS only looks at Highest, Lowest, Delivered registers and only
>> writes to Desired, then we're not really any different than how we do
&g
Hi Arjan,
On 15 August 2014 09:53, Arjan van de Ven wrote:
> On 8/15/2014 6:42 AM, Arjan van de Ven wrote:
>> On 8/15/2014 6:08 AM, Ashwin Chaugule wrote:
>>> (b) we come up with ways to provide the bounds around a Desired value
>>> using the information from the plat
Hi Peter,
On 15 August 2014 02:19, Peter Zijlstra wrote:
> On Thu, Aug 14, 2014 at 05:56:10PM -0400, Ashwin Chaugule wrote:
>> On 14 August 2014 16:51, Peter Zijlstra wrote:
>> > On Thu, Aug 14, 2014 at 03:57:07PM -0400, Ashwin Chaugule wrote:
>> >
Hi Peter,
On 14 August 2014 16:51, Peter Zijlstra wrote:
> On Thu, Aug 14, 2014 at 03:57:07PM -0400, Ashwin Chaugule wrote:
>>
>>
>> What is CPPC:
>> =
>>
>> CPPC is the new interface for CPU performance control between the OS and the
>>
+ Rafael [corrected email addr]
On 14 August 2014 15:57, Ashwin Chaugule wrote:
> If the firmware supports CPPC natively in the firmware
> then we can use the ACPI defined semantics to access
> the CPPC specific registers.
>
> Signed-off-by: Ashwin Chaugule
> ---
> dr
+ Rafael [corrected email addr]
On 14 August 2014 15:57, Ashwin Chaugule wrote:
> Add support for parsing the CPC tables as described in the
> ACPI 5.1+ CPPC specification. When successfully parsed along
> with low level register accessors, then enable the PID
> (proportion
+ Rafael [corrected email addr]
On 14 August 2014 15:57, Ashwin Chaugule wrote:
> The ACPI 5.0+ spec defines a generic mode of communication
> between the OS and a platform such as the BMC or external power
> controller. This medium (PCC) is typically used by CPPC
> (ACPI CPU
+ Rafael [corrected email addr]
On 14 August 2014 15:57, Ashwin Chaugule wrote:
>
> Hello,
>
> Apologies in advance for a lengthy cover letter. Hopefully it has all the
> required information so you dont need to read the ACPI spec. ;)
>
> This patchset introduces
adds initial support for PCC to be usable by the
aforementioned PCC clients.
Signed-off-by: Ashwin Chaugule
---
drivers/acpi/Kconfig | 10 +++
drivers/acpi/Makefile | 1 +
drivers/acpi/pcc.c| 192 ++
3 files changed, 203 insertions(+)
create
If the firmware supports CPPC natively in the firmware
then we can use the ACPI defined semantics to access
the CPPC specific registers.
Signed-off-by: Ashwin Chaugule
---
drivers/cpufreq/Kconfig | 9 +
drivers/cpufreq/Makefile| 1 +
drivers/cpufreq/cppc.h | 4 +--
drivers
Add support for parsing the CPC tables as described in the
ACPI 5.1+ CPPC specification. When successfully parsed along
with low level register accessors, then enable the PID
(proportional-intergral-derivative) controller based algorithm
to manage CPU performance.
Signed-off-by: Ashwin Chaugule
anvandeVen/posts/dLn9T4ehywL
[5] -
http://git.linaro.org/people/ashwin.chaugule/leg-kernel.git/blob/236d901d31fb06fda798880c9ca09d65123c5dd9:/drivers/cpufreq/cppc_x86.c
Ashwin Chaugule (3):
ACPI: Add support for Platform Communication Channel
CPPC: Add support for Collaborative Processor Perfor
Hello,
On 14 July 2014 05:17, Jassi Brar wrote:
> On 11 July 2014 17:16, Ashwin Chaugule wrote:
>> Hi Jassi,
>>
>> Other than a few nits, this looks good to me.
>>
> Thanks for the nits. I will club them together with other feedback on
> the patchset.
>
>
Hi Jassi,
Other than a few nits, this looks good to me.
On 11 July 2014 10:35, Jassi Brar wrote:
> Introduce common framework for client/protocol drivers and
> controller drivers of Inter-Processor-Communication (IPC).
>
> Client driver developers should have a look at
> include/linux/mailbox_c
Hello,
On 18 June 2014 22:55, Jassi Brar wrote:
>>
>> I sure would like to see some more Reviewed-by tags from those folks to
>> confirm that those starting to use it think it's on the right track.
>>
> The upstreaming attempts have been going on for months now, and via
> non-public interactions
60 matches
Mail list logo
