Re: [RESEND PATCH v2 2/3] powerpc/powernv: Introduce Self save support

2020-01-13 Thread Pratik Sampat
I made a mistake while arranging the patches in the series. I'll re-arrange it correctly now. Sorry about that. On 13/01/20 1:21 pm, Ram Pai wrote: On Mon, Jan 13, 2020 at 09:15:08AM +0530, Pratik Rajesh Sampat wrote: This commit introduces and leverages the Self save API which OPAL now

Re: [RESEND PATCH v2 1/3] powerpc/powernv: Interface to define support and preference for a SPR

2020-01-13 Thread Pratik Sampat
Thanks for the review. The support just signifies what is default. Self restore is known to be supported by legacy systems. I'll mention a comment saying that this can change when the system is initialized. On 13/01/20 1:14 pm, Ram Pai wrote: On Mon, Jan 13, 2020 at 09:15:07AM +0530, Pratik

Re: [RFC 1/3] powerpc/powernv: Interface to define support and preference for a SPR

2020-01-06 Thread Pratik Sampat
Hello Ram, Thank you for your reviewing the patches. +/* Interface for the stop state supported and preference */ +#define SELF_RESTORE_TYPE0 +#define SELF_SAVE_TYPE 1 + +#define NR_PREFERENCES2 +#define PREFERENCE_SHIFT 8 +#define PREFERENCE_MASK 0xff + +#define UNSUPPORTED

Re: [RFC 0/3] Integrate Support for self-save and determine

2020-01-06 Thread Pratik Sampat
Thanks for your comments Ram, A list of preferred SPRs are maintained in the kernel which contains two properties: 1. supported_mode: Helps in identifying if it strictly supports self save or restore or both. Will be good to capture the information that, 'supported_mode'

Re: [RFC] Support stop state version quirk and firmware enabled stop

2020-04-12 Thread Pratik Sampat
Hello Gautham, On 08/04/20 3:20 pm, Gautham R Shenoy wrote: Hi Pratik, On Wed, Mar 04, 2020 at 09:26:48PM +0530, Pratik Rajesh Sampat wrote: A concept patch in Skiboot to illustrate the case wherein handling of stop states for different DD versions of a CPU can be achieved by a simple

Re: [RFC 1/3] Interface for an idle-stop dependency structure

2020-04-12 Thread Pratik Sampat
Hello Gautham On 08/04/20 4:21 pm, Gautham R Shenoy wrote: Hi Pratik, On Wed, Mar 04, 2020 at 09:31:21PM +0530, Pratik Rajesh Sampat wrote: Design patch to introduce the idea of having a dependency structure for idle-stop. The structure encapsulates the following: 1. Bitmask for version of

Re: [PATCH] Fixes: 227942809b52 ("cpufreq: powernv: Restore cpu frequency to policy->cur on unthrottling")

2020-03-16 Thread Pratik Sampat
Hi Daniel, Sure thing I'll re-send them. Rookie mistake, my bad. Thanks for pointing it out! Regards, Pratik On 16/03/20 6:35 pm, Daniel Axtens wrote: Hi Pratik, Please could you resend this with a more meaningful subject line and move the Fixes: line to immediately above your signed-off-by?

Re: [PATCH v6 2/3] powerpc/powernv: Introduce support and parsing for self-save API

2020-04-14 Thread Pratik Sampat
Hello Gautham, [..snip..] + + if (curr_spr.supported_mode & FIRMWARE_SELF_SAVE) { + rc = opal_slw_self_save_reg(pir, + curr_spr.spr); + if (rc != 0) +

Re: [PATCH v6 0/3] powerpc/powernv: Introduce interface for self-restore support

2020-04-14 Thread Pratik Sampat
Hello Gautham On 14/04/20 12:41 pm, Gautham R Shenoy wrote: Hello Pratik, On Thu, Mar 26, 2020 at 12:40:31PM +0530, Pratik Rajesh Sampat wrote: v5: https://lkml.org/lkml/2020/3/17/944 Changelog v5-->v6 1. Updated background, motivation and illuminated potential design choices 2.

Re: [PATCH v4 3/3] powerpc/powernv: Parse device tree, population of SPR support

2020-03-17 Thread Pratik Sampat
Thank you Michael for the review. On 17/03/20 8:43 am, Michael Ellerman wrote: Pratik Rajesh Sampat writes: Parse the device tree for nodes self-save, self-restore and populate support for the preferred SPRs based what was advertised by the device tree. These should be documented in:

Re: [PATCH] Revert "powerpc/powernv/idle: Replace CPU feature check with PVR check"

2020-08-26 Thread Pratik Sampat
On 26/08/20 2:07 pm, Christophe Leroy wrote: Le 26/08/2020 à 10:29, Pratik Rajesh Sampat a écrit : Cpuidle stop state implementation has minor optimizations for P10 where hardware preserves more SPR registers compared to P9. The current P9 driver works for P10, although does few extra

Re: [PATCH] powerpc/powernv/idle: add a basic stop 0-3 driver for POWER10

2020-08-19 Thread Pratik Sampat
On 19/08/20 3:17 pm, Nicholas Piggin wrote: This driver does not restore stop > 3 state, so it limits itself to states which do not lose full state or TB. The POWER10 SPRs are sufficiently different from P9 that it seems easier to split out the P10 code. The POWER10 deep sleep code (e.g.,

Re: [PATCH] powerpc/powernv/idle: add a basic stop 0-3 driver for POWER10

2020-08-19 Thread Pratik Sampat
On 19/08/20 3:17 pm, Nicholas Piggin wrote: This driver does not restore stop > 3 state, so it limits itself to states which do not lose full state or TB. The POWER10 SPRs are sufficiently different from P9 that it seems easier to split out the P10 code. The POWER10 deep sleep code (e.g., the

Re: [PATCH 2/2] powerpc/powernv/idle: save-restore DAWR0,DAWRX0 for P10

2020-07-09 Thread Pratik Sampat
On 09/07/20 2:39 pm, Gautham R Shenoy wrote: On Fri, Jul 03, 2020 at 06:16:40PM +0530, Pratik Rajesh Sampat wrote: Additional registers DAWR0, DAWRX0 may be lost on Power 10 for stop levels < 4. Adding Ravi Bangoria to the cc. Therefore save the values of these SPRs before entering a

Re: [PATCH 2/2] selftest/cpuidle: Add support for cpuidle latency measurement

2020-07-07 Thread Pratik Sampat
[..snip..] + +ins_mod() +{ +    if [ ! -f "$MODULE" ]; then +    printf "$MODULE module does not exist. Exitting\n" +    exit 2 Please use ksft_skip code to indicate the test is being skipped. Sure thing I'll use ksft_skip exit code instead. +    fi +    printf "Inserting $MODULE

Re: [PATCH v2 0/3] Power10 basic energy management

2020-07-13 Thread Pratik Sampat
Thank you for your comments, On 13/07/20 10:53 am, Nicholas Piggin wrote: Excerpts from Pratik Rajesh Sampat's message of July 10, 2020 3:22 pm: Changelog v1 --> v2: 1. Save-restore DAWR and DAWRX unconditionally as they are lost in shallow idle states too 2. Rename pnv_first_spr_loss_level to

Re: [PATCH v2 0/3] Power10 basic energy management

2020-07-13 Thread Pratik Sampat
On 13/07/20 10:20 pm, Nicholas Piggin wrote: Excerpts from Pratik Sampat's message of July 13, 2020 8:02 pm: Thank you for your comments, On 13/07/20 10:53 am, Nicholas Piggin wrote: Excerpts from Pratik Rajesh Sampat's message of July 10, 2020 3:22 pm: Changelog v1 --> v2: 1.

Re: [PATCH v3 1/2] cpuidle: Trace IPI based and timer based wakeup latency from idle states

2020-07-28 Thread Pratik Sampat
Hello Rafael, On 27/07/20 7:12 pm, Rafael J. Wysocki wrote: On Tue, Jul 21, 2020 at 2:43 PM Pratik Rajesh Sampat wrote: Fire directed smp_call_function_single IPIs from a specified source CPU to the specified target CPU to reduce the noise we have to wade through in the trace log. And

Re: [PATCH v2 2/2] selftest/cpuidle: Add support for cpuidle latency measurement

2020-07-21 Thread Pratik Sampat
Hi Gautham, Thanks for the review. On 20/07/20 11:22 am, Gautham R Shenoy wrote: Hi Pratik, On Fri, Jul 17, 2020 at 02:48:01PM +0530, Pratik Rajesh Sampat wrote: This patch adds support to trace IPI based and timer based wakeup latency from idle states Latches onto the test-cpuidle_latency

Re: [PATCH v3 1/3] powerpc/powernv/idle: Replace CPU features checks with PVR checks

2020-07-21 Thread Pratik Sampat
On 20/07/20 5:30 am, Nicholas Piggin wrote: Excerpts from Pratik Rajesh Sampat's message of July 18, 2020 4:53 am: As the idle framework's architecture is incomplete, hence instead of checking for just the processor type advertised in the device tree CPU features; check for the Processor

Re: [PATCH v3 2/3] powerpc/powernv/idle: Rename pnv_first_spr_loss_level variable

2020-07-21 Thread Pratik Sampat
On 20/07/20 5:27 am, Nicholas Piggin wrote: Excerpts from Pratik Rajesh Sampat's message of July 18, 2020 4:53 am: Replace the variable name from using "pnv_first_spr_loss_level" to "pnv_first_fullstate_loss_level". As pnv_first_spr_loss_level is supposed to be the earliest state that has

Re: [PATCH v3 0/2] Selftest for cpuidle latency measurement

2020-07-22 Thread Pratik Sampat
Hello Daniel, On 21/07/20 8:27 pm, Daniel Lezcano wrote: On 21/07/2020 14:42, Pratik Rajesh Sampat wrote: v2: https://lkml.org/lkml/2020/7/17/369 Changelog v2-->v3 Based on comments from Gautham R. Shenoy adding the following in the selftest, 1. Grepping modules to determine if already loaded

Re: [PATCH v2 2/3] powerpc/powernv/idle: save-restore DAWR0,DAWRX0 for P10

2020-07-24 Thread Pratik Sampat
On 24/07/20 6:55 am, Michael Neuling wrote: On Fri, 2020-07-10 at 10:52 +0530, Pratik Rajesh Sampat wrote: Additional registers DAWR0, DAWRX0 may be lost on Power 10 for stop levels < 4. Therefore save the values of these SPRs before entering a "stop" state and restore their values on

Re: [RFC] powerpc/pseries: Interface to represent PAPR firmware attributes

2021-06-08 Thread Pratik Sampat
I've implemented a POC using this interface for the powerpc-utils' ppc64_cpu --frequency command-line tool to utilize this information in userspace. The POC has been hosted here: https://github.com/pratiksampat/powerpc-utils/tree/H_GET_ENERGY_SCALE_INFO and based on comments I suggestions I can

Re: [RFC] powerpc/pseries: Interface to represent PAPR firmware attributes

2021-06-09 Thread Pratik Sampat
Hello, Thank you for your comments on the design. On 09/06/21 3:43 am, Fabiano Rosas wrote: "Pratik R. Sampat" writes: Hi, I have some general comments and questions, mostly trying to understand design of the hcall and use cases of the sysfs data: Adds a generic interface to represent the

Re: [RFC] powerpc/pseries: Interface to represent PAPR firmware attributes

2021-06-10 Thread Pratik Sampat
On 10/06/21 5:33 am, Fabiano Rosas wrote: Pratik Sampat writes: 3. version info - 1 byte 4. A data array of size num attributes, which contains the following: a. attribute ID - 8 bytes b. attribute value in number - 8 bytes c. attribute name

Re: [PATCH 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes

2021-06-21 Thread Pratik Sampat
Hello Fabiano, Thank you for your review. On 19/06/21 2:28 am, Fabiano Rosas wrote: "Pratik R. Sampat" writes: Adds a generic interface to represent the energy and frequency related PAPR attributes on the system using the new H_CALL "H_GET_ENERGY_SCALE_INFO". H_GET_EM_PARMS H_CALL was

Re: [PATCH v2 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes

2021-07-12 Thread Pratik Sampat
On 08/07/21 4:05 pm, Gautham R Shenoy wrote: Hello Pratik, On Tue, Jul 06, 2021 at 01:54:00PM +0530, Pratik R. Sampat wrote: Adds a generic interface to represent the energy and frequency related PAPR attributes on the system using the new H_CALL "H_GET_ENERGY_SCALE_INFO". H_GET_EM_PARMS

Re: [PATCH v3 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes

2021-07-15 Thread Pratik Sampat
Hello, On 12/07/21 9:13 pm, Fabiano Rosas wrote: "Pratik R. Sampat" writes: Hi, have you seen Documentation/core-api/kobject.rst, particularly the part that says: "When you see a sysfs directory full of other directories, generally each of those directories corresponds to a kobject in

Re: [PATCH v8 1/2] powerpc/pseries: Interface to represent PAPR firmware attributes

2021-09-28 Thread Pratik Sampat
Hello Greg, Thank you for your review. On 28/09/21 5:38 pm, Greg KH wrote: On Tue, Sep 28, 2021 at 05:21:01PM +0530, Pratik R. Sampat wrote: Adds a generic interface to represent the energy and frequency related PAPR attributes on the system using the new H_CALL "H_GET_ENERGY_SCALE_INFO".

Re: [PATCH v8 1/2] powerpc/pseries: Interface to represent PAPR firmware attributes

2021-09-28 Thread Pratik Sampat
On 28/09/21 7:28 pm, Greg KH wrote: On Tue, Sep 28, 2021 at 06:13:18PM +0530, Pratik Sampat wrote: Hello Greg, Thank you for your review. On 28/09/21 5:38 pm, Greg KH wrote: On Tue, Sep 28, 2021 at 05:21:01PM +0530, Pratik R. Sampat wrote: Adds a generic interface to represent the energy

Re: [PATCH v6 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes

2021-07-20 Thread Pratik Sampat
On 20/07/21 7:02 pm, kajoljain wrote: On 7/20/21 11:04 AM, Pratik R. Sampat wrote: Adds a generic interface to represent the energy and frequency related PAPR attributes on the system using the new H_CALL "H_GET_ENERGY_SCALE_INFO". H_GET_EM_PARMS H_CALL was previously responsible for

Re: [PATCH v5 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes

2021-07-19 Thread Pratik Sampat
On 20/07/21 12:39 am, Fabiano Rosas wrote: "Pratik R. Sampat" writes: + pgs = kcalloc(num_attrs, sizeof(*pgs), GFP_KERNEL); + if (!pgs) + goto out; + + papr_kobj = kobject_create_and_add("papr", firmware_kobj); + if (!papr_kobj) { +

Re: [PATCH v3 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes

2021-07-16 Thread Pratik Sampat
On 16/07/21 1:16 am, Fabiano Rosas wrote: Pratik Sampat writes: Hello, On 12/07/21 9:13 pm, Fabiano Rosas wrote: "Pratik R. Sampat" writes: Hi, have you seen Documentation/core-api/kobject.rst, particularly the part that says: "When you see a sysfs directory full of ot

Re: [PATCH v4 1/1] powerpc/pseries: Interface to represent PAPR firmware attributes

2021-07-17 Thread Pratik Sampat
On 17/07/21 12:35 am, Fabiano Rosas wrote: "Pratik R. Sampat" writes: +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include Do you need all of

Re: [PATCH] cpufreq:powernv: Fix init_chip_info initialization in numa=off

2021-07-27 Thread Pratik Sampat
On 27/07/21 11:46 am, Gautham R Shenoy wrote: On Mon, Jul 26, 2021 at 10:37:57PM +0530, Pratik R. Sampat wrote: In the numa=off kernel command-line configuration init_chip_info() loops around the number of chips and attempts to copy the cpumask of that node which is NULL for all iterations