Re: [PATCH v5] Force cppc_cpufreq to report values in KHz to fix user space reporting

>>> >>>> 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 <ashwi...@google.com> Cheers, Ashwin.

Re: [PATCH v5] Force cppc_cpufreq to report values in KHz to fix user space reporting

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.

Re: [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

need some mutual 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 > <ashwin.chaug...@linaro.org> wrote: >> On 19 May 2016 at 20:32, Hoan Tran <hot...

Re: [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

ity 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 Communicati

Re: [PATCH] acpi: cppc: Prevent cpc_desc_ptr points to the invalid data

channel request 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 2

Re: [PATCH] acpi: cppc: Prevent cpc_desc_ptr points to the invalid data

ail" 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, Ashw

Re: [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

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 >

Re: [PATCH v3] mailbox: pcc: Support HW-Reduced Communication Subspace type 2

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

Re: [PATCH] acpi: cppc: Prevent cpc_desc_ptr points to the invalid data

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

Re: [PATCH] acpi: cppc: Prevent cpc_desc_ptr points to the invalid data

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 > --- >

Re: [PATCH v2] mailbox: pcc: Support HW-Reduced Communication Subspace Type 2

On 11 May 2016 at 14:15, Hoan Tran <hot...@apm.com> wrote: > On Wed, May 11, 2016 at 4:57 AM, Ashwin Chaugule > <ashwin.chaug...@linaro.org> wrote: >> On 11 May 2016 at 00:21, Hoan Tran <hot...@apm.com> wrote: >>> On Tue, May 10, 2016 at 5:00 AM, Ashwin Cha

Re: [PATCH v2] mailbox: pcc: Support HW-Reduced Communication Subspace Type 2

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: >>>

Re: [PATCH v2] mailbox: pcc: Support HW-Reduced Communication Subspace Type 2

On 11 May 2016 at 00:21, Hoan Tran <hot...@apm.com> wrote: > Hi Ashwin, Hi, > On Tue, May 10, 2016 at 5:00 AM, Ashwin Chaugule >> On 6 May 2016 at 14:38, Hoan Tran <hot...@apm.com> wrote: >>> From: hotran <hot...@apm.com> >>> >>> AC

Re: [PATCH v2] mailbox: pcc: Support HW-Reduced Communication Subspace Type 2

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

Re: [PATCH v2] mailbox: pcc: Support HW-Reduced Communication Subspace Type 2

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

Re: [PATCH v2] mailbox: pcc: Support HW-Reduced Communication Subspace Type 2

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 >

Re: [PATCH v2] Force cppc_cpufreq to report values in KHz to fix user space reporting

+ 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

Re: [PATCH v2] Force cppc_cpufreq to report values in KHz to fix user space reporting

+ 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

Re: [PATCH 0/3] cpufreq: Replace timers with utilization update callbacks

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:

Re: [PATCH 0/3] cpufreq: Replace timers with utilization update callbacks

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

Re: [PATCH] mailbox: pcc: fix channel calculation in get_pcc_channel()

rn _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/

Re: [PATCH] mailbox: pcc: fix channel calculation in get_pcc_channel()

(id * sizeof(*pcc_chan)); > - > - return pcc_chan; > + return _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 <ashwin.chaug...@linaro.org> Thanks, Ashwin

Re: [PATCH 5/6] cpufreq: governor: replace per-cpu delayed work with timers

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 >> > sin

Re: [PATCH 5/6] cpufreq: governor: replace per-cpu delayed work with timers

Hi Viresh, On 30 October 2015 at 22:36, Viresh Kumar <viresh.ku...@linaro.org> wrote: > Hi Ashwin, > > On 30-10-15, 16:46, Ashwin Chaugule wrote: >> On 29 October 2015 at 08:27, Viresh Kumar <viresh.ku...@linaro.org> wrote: >> > This could be made lightweigh

Re: [PATCH 5/6] cpufreq: governor: replace per-cpu delayed work with timers

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 >

Re: [PATCH 5/6] cpufreq: governor: replace per-cpu delayed work with timers

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

Re: [PATCH v2 5/5] ACPI / processor_idle: Add support for Low Power Idle(LPI) states

+ 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

Re: [PATCH v2 5/5] ACPI / processor_idle: Add support for Low Power Idle(LPI) states

+ 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

Re: [PATCH v2 5/5] ACPI / processor_idle: Add support for Low Power Idle(LPI) states

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

Re: [PATCH v2 5/5] ACPI / processor_idle: Add support for Low Power Idle(LPI) states

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

Re: [PATCH v2 4/5] ACPI / processor_idle : introduce ARCH_SUPPORTS_ACPI_PROCESSOR_CSTATE

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

Re: [PATCH v2 4/5] ACPI / processor_idle : introduce ARCH_SUPPORTS_ACPI_PROCESSOR_CSTATE

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 >

Re: [lkp] [PCC] d3c68f218f: PCCT header not found.

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

Re: [lkp] [PCC] d3c68f218f: PCCT header not found.

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

Re: [lkp] [ACPI] 239708a3af: Warning: Processor Platform Limit event detected, but not handled.

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

Re: [lkp] [ACPI] 239708a3af: Warning: Processor Platform Limit event detected, but not handled.

Hello, On 26 August 2015 at 20:35, kernel test robot ying.hu...@intel.com 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

Re: [PATCH v3 6/6] ACPI: import watchdog info of GTDT into platform device

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 >>

Re: [PATCH v3 6/6] ACPI: import watchdog info of GTDT into platform device

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

Re: [PATCH v3 6/6] ACPI: import watchdog info of GTDT into platform device

On 26 May 2015 at 11:18, Will Deacon will.dea...@arm.com wrote: On Tue, May 26, 2015 at 04:02:56PM +0100, Ashwin Chaugule wrote: On 26 May 2015 at 08:28, Will Deacon will.dea...@arm.com wrote: On Mon, May 25, 2015 at 11:03:13AM +0100, fu@linaro.org wrote: From: Fu Wei fu@linaro.org

Re: [PATCH v3 6/6] ACPI: import watchdog info of GTDT into platform device

Hi Will, On 26 May 2015 at 08:28, Will Deacon will.dea...@arm.com wrote: On Mon, May 25, 2015 at 11:03:13AM +0100, fu@linaro.org wrote: From: Fu Wei fu@linaro.org Parse SBSA Generic Watchdog Structure in GTDT table of ACPI, and create a platform device with that information. This

Re: [PATCH RFC 2/5] ACPI / processor: always compile perflib if CONFIG_ACPI_PROCESSOR

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

Re: [PATCH RFC 2/5] ACPI / processor: always compile perflib if CONFIG_ACPI_PROCESSOR

Hello, On 6 May 2015 at 10:31, Sudeep Holla sudeep.ho...@arm.com 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

Re: question about drivers/mailbox/pcc.c

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

Re: question about drivers/mailbox/pcc.c

On 13 March 2015 at 05:12, Julia Lawall julia.law...@lip6.fr 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

Re: [PATCH v2 2/2] ARM: perf: Add support for Scorpion PMUs

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

Re: [PATCH v2 2/2] ARM: perf: Add support for Scorpion PMUs

On 24 February 2015 at 12:23, Ashwin Chaugule ashwin.chaug...@linaro.org wrote: On 20 February 2015 at 15:16, Stephen Boyd sb...@codeaurora.org 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

Re: [PATCH v2 2/2] ARM: perf: Add support for Scorpion PMUs

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; >>

Re: [PATCH v2 2/2] ARM: perf: Add support for Scorpion PMUs

On 20 February 2015 at 15:16, Stephen Boyd sb...@codeaurora.org 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; +

Re: [PATCH 2/2] ARM: perf: Add support for Scorpion PMUs

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

Re: [PATCH 2/2] ARM: perf: Add support for Scorpion PMUs

On 11 February 2015 at 13:27, Stephen Boyd sb...@codeaurora.org wrote: On 02/10, Ashwin Chaugule wrote: Hi Stephen, On 10 February 2015 at 20:05, Stephen Boyd sb...@codeaurora.org wrote: Scorpion supports a set of local performance monitor event selection registers (LPM) sitting behind

Re: [PATCH 2/2] ARM: perf: Add support for Scorpion PMUs

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

Re: [PATCH 2/2] ARM: perf: Add support for Scorpion PMUs

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 Leeder [1] massed to become similar

Re: [Linaro-acpi] [PATCH] Mailbox: Complete wait event only if Tx was successful

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

Re: [Linaro-acpi] [PATCH] Mailbox: Complete wait event only if Tx was successful

On 16 December 2014 at 06:36, Sudeep Holla sudeep.ho...@arm.com wrote: On Fri, Dec 12, 2014 at 05:47:26PM +, Ashwin Chaugule wrote: On 12 December 2014 at 03:43, Sudeep Holla sudeep.ho...@arm.com wrote: On Thursday 11 December 2014 01:46 AM, Ashwin Chaugule wrote

Re: [PATCH] Mailbox: Complete wait event only if Tx was successful

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

Re: [Linaro-acpi] [PATCH] Mailbox: Complete wait event only if Tx was successful

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

Re: [Linaro-acpi] [PATCH] Mailbox: Complete wait event only if Tx was successful

On 12 December 2014 at 03:43, Sudeep Holla sudeep.ho...@arm.com 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 wait

Re: [PATCH] Mailbox: Complete wait event only if Tx was successful

On 12 December 2014 at 05:21, Jassi Brar jaswinder.si...@linaro.org wrote: On 11 December 2014 at 01:46, Ashwin Chaugule ashwin.chaug...@linaro.org 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

[PATCH] Mailbox: Complete wait event only if Tx was successful

by 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

[PATCH] Mailbox: Complete wait event only if Tx was successful

by 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 ashwin.chaug...@linaro.org --- drivers/mailbox/mailbox.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCHv10 2/4] mailbox: Introduce framework for mailbox

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) >>>>>> +{ >>>>>>

Re: [PATCHv10 2/4] mailbox: Introduce framework for mailbox

On 25 September 2014 20:57, Jassi Brar jaswinder.si...@linaro.org wrote: On 24 September 2014 09:14, Ashwin Chaugule ashwin.chaug...@linaro.org wrote: On 22 September 2014 14:33, Sudeep Holla sudeep.ho...@arm.com wrote: +static void poll_txdone(unsigned long data) +{ + struct

Re: [PATCHv10 2/4] mailbox: Introduce framework for mailbox

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

Re: [PATCHv10 2/4] mailbox: Introduce framework for mailbox

On 22 September 2014 14:33, Sudeep Holla sudeep.ho...@arm.com 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 jaswinder.si...@linaro.org wrote: Introduce common framework for client/protocol drivers

Re: [PATCHv10 2/4] mailbox: Introduce framework for mailbox

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

Re: [PATCHv10 2/4] mailbox: Introduce framework for mailbox

Hi Jassi, On 1 August 2014 08:31, Jassi Brar jaswinder.si...@linaro.org 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

Re: [RFC v1 0/6] CPPC as a PID backend

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

Re: [RFC v1 0/6] CPPC as a PID backend

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

Re: [RFC v1 0/6] CPPC as a PID backend

On 10 September 2014 11:44, Dirk Brandewie dirk.brande...@gmail.com 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

Re: [RFC v1 0/6] CPPC as a PID backend

On 10 September 2014 13:31, Dirk Brandewie dirk.brande...@gmail.com wrote: On 09/10/2014 09:11 AM, Ashwin Chaugule wrote: On 10 September 2014 11:44, Dirk Brandewie dirk.brande...@gmail.com With the current split I think you will still be able to maintain Intel specific changes for the future

[PATCH 3/6] PID: Move Baytrail specific accessors into backend driver

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

[PATCH 2/6] PID: Move Turbo detection into backend driver

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

[PATCH 4/6] PID: Add new function pointers to read multiple registers

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/cpufreq

[PATCH 6/6] PID: Add CPPC (Collaborative Processor Performance) backend driver

the 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

[PATCH 5/6] PID: Rename counters to make them more generic

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

[PATCH 1/6] PID Controller governor

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

[RFC v1 0/6] CPPC as a PID backend

/ [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

[PATCH 1/6] PID Controller governor

contoller. The PID governor still has a few X86 specific things which are moved out in the following patch. Signed-off-by: Ashwin Chaugule ashwin.chaug...@linaro.org --- Documentation/cpu-freq/intel-pstate.txt | 43 -- Documentation/cpu-freq/pid_ctrl.txt | 41 ++ drivers/cpufreq/Kconfig

[RFC v1 0/6] CPPC as a PID backend

/ [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

[PATCH 5/6] PID: Rename counters to make them more generic

Aperf/Mperf are very X86 specific names but effectively count Delivered and Reference Cpu performance values. Signed-off-by: Ashwin Chaugule ashwin.chaug...@linaro.org --- drivers/cpufreq/intel_pid_ctrl.c | 12 ++-- drivers/cpufreq/pid_ctrl.c | 10 +- drivers/cpufreq

[PATCH 4/6] PID: Add new function pointers to read multiple registers

multiple registers at once. In contrast, we'd have to ring the Doorbell for every register Read. Signed-off-by: Ashwin Chaugule ashwin.chaug...@linaro.org --- drivers/cpufreq/intel_pid_ctrl.c | 49 ++-- drivers/cpufreq/pid_ctrl.c | 34

[PATCH 6/6] PID: Add CPPC (Collaborative Processor Performance) backend driver

the PID backend interfaces using CPPC semantics. Signed-off-by: Ashwin Chaugule ashwin.chaug...@linaro.org --- drivers/cpufreq/Kconfig | 10 + drivers/cpufreq/Makefile| 1 + drivers/cpufreq/cppc_pid_ctrl.c | 406 3 files changed, 417

[PATCH 3/6] PID: Move Baytrail specific accessors into backend driver

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 ashwin.chaug...@linaro.org --- drivers/cpufreq/intel_pid_ctrl.c | 57

[PATCH 2/6] PID: Move Turbo detection into backend driver

Move X86 specific turbo detection logic into platform specific PID backend driver. Signed-off-by: Ashwin Chaugule ashwin.chaug...@linaro.org --- drivers/cpufreq/intel_pid_ctrl.c | 15 ++- drivers/cpufreq/pid_ctrl.c | 13 +++-- 2 files changed, 21 insertions(+), 7

Re: [RFC 0/3] Experimental patchset for CPPC

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

Re: [RFC 0/3] Experimental patchset for CPPC

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

Re: [RFC 0/3] Experimental patchset for CPPC

Hello, On 15 August 2014 10:41, Peter Zijlstra pet...@infradead.org wrote: On Fri, Aug 15, 2014 at 10:37:32AM -0400, Ashwin Chaugule wrote: On 15 August 2014 10:07, Peter Zijlstra pet...@infradead.org wrote: On Fri, Aug 15, 2014 at 09:08:50AM -0400, Ashwin Chaugule wrote: If the OS only

Re: [RFC 0/3] Experimental patchset for CPPC

Hi Len, On 15 August 2014 18:11, Len Brown l...@kernel.org 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

Re: [RFC 0/3] Experimental patchset for CPPC

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)

Re: [RFC 0/3] Experimental patchset for CPPC

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

Re: [RFC 0/3] Experimental patchset for CPPC

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

Re: [RFC 0/3] Experimental patchset for CPPC

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: >> >

Re: [RFC 0/3] Experimental patchset for CPPC

Hi Peter, On 15 August 2014 02:19, Peter Zijlstra pet...@infradead.org wrote: On Thu, Aug 14, 2014 at 05:56:10PM -0400, Ashwin Chaugule wrote: On 14 August 2014 16:51, Peter Zijlstra pet...@infradead.org wrote: On Thu, Aug 14, 2014 at 03:57:07PM -0400, Ashwin Chaugule wrote: What

Re: [RFC 0/3] Experimental patchset for CPPC

Hi Arjan, On 15 August 2014 09:53, Arjan van de Ven ar...@linux.intel.com 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 platform. (long term

Re: [RFC 0/3] Experimental patchset for CPPC

Hi Peter, On 15 August 2014 10:07, Peter Zijlstra pet...@infradead.org 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 things

Re: [RFC 0/3] Experimental patchset for CPPC

Hello, On 15 August 2014 11:47, Arjan van de Ven ar...@linux.intel.com 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) 2) is there in practice today

Re: [RFC 0/3] Experimental patchset for CPPC

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 >>

Re: [RFC 3/3] CPPC: Add ACPI accessors to CPC registers

+ 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

Re: [RFC 2/3] CPPC: Add support for Collaborative Processor Performance Control

+ 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

Re: [RFC 1/3] ACPI: Add support for Platform Communication Channel

+ 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

  1   2   >