Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1251666 > unrolled thread

[PATCHv2 0/4] arm-cci500: Workaround pmu_event_set_period

Back to article view | Back to linux.kernel

Contents

  [PATCHv2 0/4] arm-cci500: Workaround pmu_event_set_period "Suzuki K. Poulose" <suzuki.poulose@arm.com> - 2015-10-20 15:10 +0200
    Re: [PATCHv2 0/4] arm-cci500: Workaround pmu_event_set_period Olof Johansson <olof@lixom.net> - 2015-10-22 19:30 +0200
      Re: [PATCHv2 0/4] arm-cci500: Workaround pmu_event_set_period "Suzuki K. Poulose" <Suzuki.Poulose@arm.com> - 2015-10-22 23:50 +0200

#1251666 — [PATCHv2 0/4] arm-cci500: Workaround pmu_event_set_period

The CCI PMU driver sets the event counter to the half of the maximum
value(2^31) it can count before we start the counters via
pmu_event_set_period(). This is done to give us the best chance to
handle the overflow interrupt, taking care of extreme interrupt latencies.

However, CCI-500 comes with advanced power saving schemes, which disables
the clock to the event counters unless the counters are enabled to count
(PMCR.CEN). This prevents the driver from writing the period to the
counters before starting them.  Also, there is no way we can reset the
individual event counter to 0 (PMCR.RST resets all the counters, losing
their current readings). However the value of the counter is preserved and
could be read back, when the counters are not enabled.

So we cannot reliably use the counters and compute the number of events
generated during the sampling period since we don't have the value of the
counter at start.

Here are the possible solutions:

 1) Disable clock gating on CCI-500 by setting Control_Override_Reg[bit3].
    - The Control_Override_Reg is secure (and hence not programmable from
      Linux), and also has an impact on power consumption.

 2) Change the order of operations
	i.e,
	a) Program and enable individual counters
	b) Enable counting on all the counters by setting PMCR.CEN
	c) Write the period to the individual counters
	d) Disable the counters
    - This could cause in unnecessary noise in the other counters and is
      costly (we should repeat this for all enabled counters).

 3) Don't set the counter value, instead use the current count as the
    starting count and compute the delta at the end of sampling.

 4) Modified version of 2, which disables all the other counters, except
    the target counter, with the target counter programmed with an invalid
    event code(which guarantees that the counter won't change during the
    operation).

This patch implements option 4 for CCI-500. CCI-400 behavior remains
unchanged. The problem didn't surface on a fast model, but was revealed
on an FPGA model. Without this patch profiling on CCI-500 is broken and
should be fixed for 4.3.

Changes since V1:
 - Choose 4 instead of 3 above, suggested by Mark Rutland

Suzuki K. Poulose (4):
  arm-cci: Refactor CCI PMU code
  arm-cci: Get the status of a counter
  arm-cci: Add routines to enable/disable all counters
  arm-cci500: Work around PMU counter writes

 drivers/bus/arm-cci.c |  184 +++++++++++++++++++++++++++++++++++++++----------
 1 file changed, 147 insertions(+), 37 deletions(-)

-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1254001

On Tue, Oct 20, 2015 at 02:05:22PM +0100, Suzuki K. Poulose wrote:
> The CCI PMU driver sets the event counter to the half of the maximum
> value(2^31) it can count before we start the counters via
> pmu_event_set_period(). This is done to give us the best chance to
> handle the overflow interrupt, taking care of extreme interrupt latencies.
> 
> However, CCI-500 comes with advanced power saving schemes, which disables
> the clock to the event counters unless the counters are enabled to count
> (PMCR.CEN). This prevents the driver from writing the period to the
> counters before starting them.  Also, there is no way we can reset the
> individual event counter to 0 (PMCR.RST resets all the counters, losing
> their current readings). However the value of the counter is preserved and
> could be read back, when the counters are not enabled.
> 
> So we cannot reliably use the counters and compute the number of events
> generated during the sampling period since we don't have the value of the
> counter at start.
> 
> Here are the possible solutions:
> 
>  1) Disable clock gating on CCI-500 by setting Control_Override_Reg[bit3].
>     - The Control_Override_Reg is secure (and hence not programmable from
>       Linux), and also has an impact on power consumption.
> 
>  2) Change the order of operations
> 	i.e,
> 	a) Program and enable individual counters
> 	b) Enable counting on all the counters by setting PMCR.CEN
> 	c) Write the period to the individual counters
> 	d) Disable the counters
>     - This could cause in unnecessary noise in the other counters and is
>       costly (we should repeat this for all enabled counters).
> 
>  3) Don't set the counter value, instead use the current count as the
>     starting count and compute the delta at the end of sampling.
> 
>  4) Modified version of 2, which disables all the other counters, except
>     the target counter, with the target counter programmed with an invalid
>     event code(which guarantees that the counter won't change during the
>     operation).
> 
> This patch implements option 4 for CCI-500. CCI-400 behavior remains
> unchanged. The problem didn't surface on a fast model, but was revealed
> on an FPGA model. Without this patch profiling on CCI-500 is broken and
> should be fixed for 4.3.

Hi,

Given that CCI-500 is only now showing up in FPGA models, and is new hardware
support and not a regression, combined with the late time in the release cycle
means this is really 4.4 material by now.

Mark, can you review given that you've been involved already, please? Happy to
apply for 4.4 if it's ready for it soon.


-Olof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1254191

On Thu, Oct 22, 2015 at 10:00:25AM -0700, Olof Johansson wrote:
> On Tue, Oct 20, 2015 at 02:05:22PM +0100, Suzuki K. Poulose wrote:
> Hi,
> 
> Given that CCI-500 is only now showing up in FPGA models, and is new hardware
> support and not a regression, combined with the late time in the release cycle
> means this is really 4.4 material by now.

Yes, this can wait till 4.4. I missed updating that part from v1.

Thanks
Suzuki

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web