Re: [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor

On 2018-08-08 01:47, Sudeep Holla wrote: On Tue, Aug 07, 2018 at 12:37:07PM -0700, skan...@codeaurora.org wrote: On 2018-08-07 09:41, Rob Herring wrote: >On Wed, Aug 01, 2018 at 05:57:41PM -0700, Saravana Kannan wrote: >>Many CPU architectures have caches that can scale independent of the

Re: [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor

On 2018-08-08 01:47, Sudeep Holla wrote: On Tue, Aug 07, 2018 at 12:37:07PM -0700, skan...@codeaurora.org wrote: On 2018-08-07 09:41, Rob Herring wrote: >On Wed, Aug 01, 2018 at 05:57:41PM -0700, Saravana Kannan wrote: >>Many CPU architectures have caches that can scale independent of the

Re: [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor

On 2018-08-07 09:41, Rob Herring wrote: On Wed, Aug 01, 2018 at 05:57:41PM -0700, Saravana Kannan wrote: Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure the cache is not a performance bottleneck that leads to

Re: [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor

On 2018-08-07 09:41, Rob Herring wrote: On Wed, Aug 01, 2018 at 05:57:41PM -0700, Saravana Kannan wrote: Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure the cache is not a performance bottleneck that leads to

Re: [PATCH v3 2/2] PM / devfreq: Add devfreq driver for interconnect bandwidth voting

On 2018-08-07 09:51, Rob Herring wrote: On Wed, Aug 01, 2018 at 05:57:42PM -0700, Saravana Kannan wrote: This driver registers itself as a devfreq device that allows devfreq governors to make bandwidth votes for an interconnect path. This allows applying various policies for different

Re: [PATCH v3 2/2] PM / devfreq: Add devfreq driver for interconnect bandwidth voting

On 2018-08-07 09:51, Rob Herring wrote: On Wed, Aug 01, 2018 at 05:57:42PM -0700, Saravana Kannan wrote: This driver registers itself as a devfreq device that allows devfreq governors to make bandwidth votes for an interconnect path. This allows applying various policies for different

Re: [PATCH v7 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings

On 2018-08-07 04:12, Sudeep Holla wrote: On Mon, Aug 06, 2018 at 01:54:24PM -0700, skan...@codeaurora.org wrote: On 2018-08-03 16:46, Stephen Boyd wrote: >Quoting Taniya Das (2018-07-24 03:42:49) >>diff --git >>a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt

Re: [PATCH v7 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings

On 2018-08-07 04:12, Sudeep Holla wrote: On Mon, Aug 06, 2018 at 01:54:24PM -0700, skan...@codeaurora.org wrote: On 2018-08-03 16:46, Stephen Boyd wrote: >Quoting Taniya Das (2018-07-24 03:42:49) >>diff --git >>a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt

Re: [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor

On 2018-08-02 14:00, skan...@codeaurora.org wrote: On 2018-08-02 02:56, MyungJoo Ham wrote: Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure the cache is not a performance bottleneck that leads to poor

Re: [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor

On 2018-08-02 14:00, skan...@codeaurora.org wrote: On 2018-08-02 02:56, MyungJoo Ham wrote: Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure the cache is not a performance bottleneck that leads to poor

Re: [PATCH v7 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings

On 2018-08-03 16:46, Stephen Boyd wrote: Quoting Taniya Das (2018-07-24 03:42:49) diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt new file mode 100644 index 000..22d4355 --- /dev/null +++

Re: [PATCH v7 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ Firmware bindings

On 2018-08-03 16:46, Stephen Boyd wrote: Quoting Taniya Das (2018-07-24 03:42:49) diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt new file mode 100644 index 000..22d4355 --- /dev/null +++

Re: [PATCH v7 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

On 2018-08-03 15:24, Stephen Boyd wrote: Quoting skan...@codeaurora.org (2018-08-03 12:52:48) On 2018-08-03 12:40, Evan Green wrote: > Hi Taniya, > > On Tue, Jul 24, 2018 at 3:44 AM Taniya Das wrote: >> >> + if (src) >> + c->table[i].frequency = c->xo_rate *

Re: [PATCH v7 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

On 2018-08-03 15:24, Stephen Boyd wrote: Quoting skan...@codeaurora.org (2018-08-03 12:52:48) On 2018-08-03 12:40, Evan Green wrote: > Hi Taniya, > > On Tue, Jul 24, 2018 at 3:44 AM Taniya Das wrote: >> >> + if (src) >> + c->table[i].frequency = c->xo_rate *

Re: [PATCH v7 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

On 2018-08-03 12:40, Evan Green wrote: Hi Taniya, On Tue, Jul 24, 2018 at 3:44 AM Taniya Das wrote: The CPUfreq HW present in some QCOM chipsets offloads the steps necessary for changing the frequency of CPUs. The driver implements the cpufreq driver interface for this hardware engine.

Re: [PATCH v7 2/2] cpufreq: qcom-hw: Add support for QCOM cpufreq HW driver

On 2018-08-03 12:40, Evan Green wrote: Hi Taniya, On Tue, Jul 24, 2018 at 3:44 AM Taniya Das wrote: The CPUfreq HW present in some QCOM chipsets offloads the steps necessary for changing the frequency of CPUs. The driver implements the cpufreq driver interface for this hardware engine.

Re: [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor

On 2018-08-02 02:56, MyungJoo Ham wrote: Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure the cache is not a performance bottleneck that leads to poor performance and power. The same idea applies for RAM/DDR.

Re: [PATCH v3 1/2] PM / devfreq: Generic CPU frequency to device frequency mapping governor

On 2018-08-02 02:56, MyungJoo Ham wrote: Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure the cache is not a performance bottleneck that leads to poor performance and power. The same idea applies for RAM/DDR.

Re: [PATCH v7 8/8] interconnect: Allow endpoints translation via DT

On 2018-08-02 05:07, Georgi Djakov wrote: Hi Saravana, On 08/02/2018 01:57 AM, skan...@codeaurora.org wrote: On 2018-07-31 09:13, Georgi Djakov wrote: Currently we support only platform data for specifying the interconnect endpoints. As now the endpoints are hard-coded into the consumer

Re: [PATCH v7 8/8] interconnect: Allow endpoints translation via DT

On 2018-08-02 05:07, Georgi Djakov wrote: Hi Saravana, On 08/02/2018 01:57 AM, skan...@codeaurora.org wrote: On 2018-07-31 09:13, Georgi Djakov wrote: Currently we support only platform data for specifying the interconnect endpoints. As now the endpoints are hard-coded into the consumer

Re: [PATCH v3 2/2] PM / devfreq: Add devfreq driver for interconnect bandwidth voting

On 2018-08-02 03:13, MyungJoo Ham wrote: This driver registers itself as a devfreq device that allows devfreq governors to make bandwidth votes for an interconnect path. This allows applying various policies for different interconnect paths using devfreq governors. First of all, the name,

Re: [PATCH v3 2/2] PM / devfreq: Add devfreq driver for interconnect bandwidth voting

On 2018-08-02 03:13, MyungJoo Ham wrote: This driver registers itself as a devfreq device that allows devfreq governors to make bandwidth votes for an interconnect path. This allows applying various policies for different interconnect paths using devfreq governors. First of all, the name,

Re: [PATCH v7 8/8] interconnect: Allow endpoints translation via DT

On 2018-07-31 09:13, Georgi Djakov wrote: Currently we support only platform data for specifying the interconnect endpoints. As now the endpoints are hard-coded into the consumer driver this may lead to complications when a single driver is used by multiple SoCs, which may have different

Re: [PATCH v7 8/8] interconnect: Allow endpoints translation via DT

On 2018-07-31 09:13, Georgi Djakov wrote: Currently we support only platform data for specifying the interconnect endpoints. As now the endpoints are hard-coded into the consumer driver this may lead to complications when a single driver is used by multiple SoCs, which may have different

Re: [PATCH] PM / devfreq: Generic cpufreq governor

On 2018-08-01 09:03, Sudeep Holla wrote: On 28/07/18 04:56, Saravana Kannan wrote: Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure the cache is not a performance bottleneck that leads to poor performance and

Re: [PATCH] PM / devfreq: Generic cpufreq governor

On 2018-08-01 09:03, Sudeep Holla wrote: On 28/07/18 04:56, Saravana Kannan wrote: Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure the cache is not a performance bottleneck that leads to poor performance and

Re: [PATCH v5 10/14] sched/cpufreq: Refactor the utilization aggregation method

On 2018-07-31 00:59, Quentin Perret wrote: On Monday 30 Jul 2018 at 12:35:27 (-0700), skan...@codeaurora.org wrote: [...] If it's going to be a different aggregation from what's done for frequency guidance, I don't see the point of having this inside schedutil. Why not keep it inside the

Re: [PATCH v5 10/14] sched/cpufreq: Refactor the utilization aggregation method

On 2018-07-31 00:59, Quentin Perret wrote: On Monday 30 Jul 2018 at 12:35:27 (-0700), skan...@codeaurora.org wrote: [...] If it's going to be a different aggregation from what's done for frequency guidance, I don't see the point of having this inside schedutil. Why not keep it inside the

Re: [PATCH] PM / devfreq: Generic cpufreq governor

On 2018-07-27 20:56, Saravana Kannan wrote: Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure the cache is not a performance bottleneck that leads to poor performance and power. The same idea applies for

Re: [PATCH] PM / devfreq: Generic cpufreq governor

On 2018-07-27 20:56, Saravana Kannan wrote: Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure the cache is not a performance bottleneck that leads to poor performance and power. The same idea applies for

Re: [PATCH] PM / devfreq: Generic cpufreq governor

On 2018-07-31 01:00, Rafael J. Wysocki wrote: On Mon, Jul 30, 2018 at 8:58 PM, wrote: On 2018-07-29 03:52, Rafael J. Wysocki wrote: On Sat, Jul 28, 2018 at 5:56 AM, Saravana Kannan wrote: Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of

Re: [PATCH] PM / devfreq: Generic cpufreq governor

On 2018-07-31 01:00, Rafael J. Wysocki wrote: On Mon, Jul 30, 2018 at 8:58 PM, wrote: On 2018-07-29 03:52, Rafael J. Wysocki wrote: On Sat, Jul 28, 2018 at 5:56 AM, Saravana Kannan wrote: Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of

Re: [PATCH v5 10/14] sched/cpufreq: Refactor the utilization aggregation method

On 2018-07-24 05:25, Quentin Perret wrote: Schedutil aggregates the PELT signals of CFS, RT, DL and IRQ in order to decide which frequency to request. Energy Aware Scheduling (EAS) needs to be able to predict those requests to assess the energy impact of scheduling decisions. However, the PELT

Re: [PATCH v5 10/14] sched/cpufreq: Refactor the utilization aggregation method

On 2018-07-24 05:25, Quentin Perret wrote: Schedutil aggregates the PELT signals of CFS, RT, DL and IRQ in order to decide which frequency to request. Energy Aware Scheduling (EAS) needs to be able to predict those requests to assess the energy impact of scheduling decisions. However, the PELT

Re: [PATCH] PM / devfreq: Generic cpufreq governor

On 2018-07-29 03:52, Rafael J. Wysocki wrote: On Sat, Jul 28, 2018 at 5:56 AM, Saravana Kannan wrote: Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure the cache is not a performance bottleneck that leads to

Re: [PATCH] PM / devfreq: Generic cpufreq governor

On 2018-07-29 03:52, Rafael J. Wysocki wrote: On Sat, Jul 28, 2018 at 5:56 AM, Saravana Kannan wrote: Many CPU architectures have caches that can scale independent of the CPUs. Frequency scaling of the caches is necessary to make sure the cache is not a performance bottleneck that leads to

Re: [PATCH v2] PM / devfreq: Add support for QCOM devfreq firmware

On 2018-05-23 07:39, Rob Herring wrote: Reviving an old thread. Sorry about the late reply. Got busy. On Tue, May 22, 2018 at 1:30 PM, Saravana Kannan wrote: On 05/22/2018 11:08 AM, Rob Herring wrote: On Fri, May 18, 2018 at 12:52:40AM -0700, Saravana Kannan wrote: The firmware present

Re: [PATCH v2] PM / devfreq: Add support for QCOM devfreq firmware

On 2018-05-23 07:39, Rob Herring wrote: Reviving an old thread. Sorry about the late reply. Got busy. On Tue, May 22, 2018 at 1:30 PM, Saravana Kannan wrote: On 05/22/2018 11:08 AM, Rob Herring wrote: On Fri, May 18, 2018 at 12:52:40AM -0700, Saravana Kannan wrote: The firmware present

Re: [PATCH v2 2/2] cpufreq: qcom-fw: Add support for QCOM cpufreq FW driver

On 2018-05-21 02:01, Viresh Kumar wrote: On 19-05-18, 23:04, Taniya Das wrote: The CPUfreq FW present in some QCOM chipsets offloads the steps necessary for changing the frequency of CPUs. The driver implements the cpufreq driver interface for this firmware. Signed-off-by: Saravana Kannan

Re: [PATCH v2 2/2] cpufreq: qcom-fw: Add support for QCOM cpufreq FW driver

On 2018-05-21 02:01, Viresh Kumar wrote: On 19-05-18, 23:04, Taniya Das wrote: The CPUfreq FW present in some QCOM chipsets offloads the steps necessary for changing the frequency of CPUs. The driver implements the cpufreq driver interface for this firmware. Signed-off-by: Saravana Kannan

Re: [PATCH 1/2] Revert "cpufreq: Remove policy create/remove notifiers"

On 2018-05-18 01:33, Rafael J. Wysocki wrote: On Fri, May 18, 2018 at 10:31 AM, wrote: On 2018-05-18 01:29, Rafael J. Wysocki wrote: On Fri, May 18, 2018 at 10:24 AM, Saravana Kannan wrote: This reverts commit

Re: [PATCH 1/2] Revert "cpufreq: Remove policy create/remove notifiers"

On 2018-05-18 01:33, Rafael J. Wysocki wrote: On Fri, May 18, 2018 at 10:31 AM, wrote: On 2018-05-18 01:29, Rafael J. Wysocki wrote: On Fri, May 18, 2018 at 10:24 AM, Saravana Kannan wrote: This reverts commit f9f41e3ef99ac9d4e91b07634362e393fb929aad. No explanation, no cake. :-)

Re: [PATCH 1/2] Revert "cpufreq: Remove policy create/remove notifiers"

On 2018-05-18 01:29, Rafael J. Wysocki wrote: On Fri, May 18, 2018 at 10:24 AM, Saravana Kannan wrote: This reverts commit f9f41e3ef99ac9d4e91b07634362e393fb929aad. No explanation, no cake. :-) Change-Id: Iddde3ef56c9e5b14dcb14f8737899b85e56f5b43 S-o-b missing.

Re: [PATCH 1/2] Revert "cpufreq: Remove policy create/remove notifiers"

On 2018-05-18 01:29, Rafael J. Wysocki wrote: On Fri, May 18, 2018 at 10:24 AM, Saravana Kannan wrote: This reverts commit f9f41e3ef99ac9d4e91b07634362e393fb929aad. No explanation, no cake. :-) Change-Id: Iddde3ef56c9e5b14dcb14f8737899b85e56f5b43 S-o-b missing. Sorry, forgot the S-o-b.

Re: [PATCH] PM / devfreq: Add support for QCOM devfreq FW

On 2018-05-17 19:28, Chanwoo Choi wrote: Hi, On 2018년 05월 17일 15:02, Saravana Kannan wrote: The firmware present in some QCOM chipsets offloads the steps necessary for changing the frequency of some devices (Eg: L3). This driver implements the devfreq interface for this firmware so that

Re: [PATCH] PM / devfreq: Add support for QCOM devfreq FW

On 2018-05-17 19:28, Chanwoo Choi wrote: Hi, On 2018년 05월 17일 15:02, Saravana Kannan wrote: The firmware present in some QCOM chipsets offloads the steps necessary for changing the frequency of some devices (Eg: L3). This driver implements the devfreq interface for this firmware so that

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

On 2018-02-27 03:43, Mark Rutland wrote: On Mon, Feb 26, 2018 at 06:11:45PM -0800, skan...@codeaurora.org wrote: On 2018-02-25 06:38, Mark Rutland wrote: > On Fri, Feb 23, 2018 at 04:19:38PM -0800, Saravana Kannan wrote: > > Some PMUs events can be read from any CPU. So allow the PMU to mark >

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

On 2018-02-27 03:43, Mark Rutland wrote: On Mon, Feb 26, 2018 at 06:11:45PM -0800, skan...@codeaurora.org wrote: On 2018-02-25 06:38, Mark Rutland wrote: > On Fri, Feb 23, 2018 at 04:19:38PM -0800, Saravana Kannan wrote: > > Some PMUs events can be read from any CPU. So allow the PMU to mark >

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

On 2018-02-25 06:38, Mark Rutland wrote: On Fri, Feb 23, 2018 at 04:19:38PM -0800, Saravana Kannan wrote: Some PMUs events can be read from any CPU. So allow the PMU to mark events as such. For these events, we don't need to reject reads or make smp calls to the event's CPU and cause

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

On 2018-02-25 06:38, Mark Rutland wrote: On Fri, Feb 23, 2018 at 04:19:38PM -0800, Saravana Kannan wrote: Some PMUs events can be read from any CPU. So allow the PMU to mark events as such. For these events, we don't need to reject reads or make smp calls to the event's CPU and cause

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

On 2018-02-24 00:41, Peter Zijlstra wrote: On Fri, Feb 23, 2018 at 04:19:38PM -0800, Saravana Kannan wrote: Some PMUs events can be read from any CPU. So allow the PMU to mark events as such. For these events, we don't need to reject reads or make smp calls to the event's CPU and cause

Re: [PATCH v1 2/2] perf/core: Add support for PMUs that can be read from any CPU

On 2018-02-24 00:41, Peter Zijlstra wrote: On Fri, Feb 23, 2018 at 04:19:38PM -0800, Saravana Kannan wrote: Some PMUs events can be read from any CPU. So allow the PMU to mark events as such. For these events, we don't need to reject reads or make smp calls to the event's CPU and cause

Re: [PATCH] timers: Fix timer inaccuracy

On 2016-11-12 03:25, Thomas Gleixner wrote: On Fri, 11 Nov 2016, Saravana Kannan wrote: On 11/10/2016 02:07 AM, Thomas Gleixner wrote: > Deferrable timers shouldn't have been invented in the first place and yes, > they are not going to happen on hrtimers, quite the contrary, I'm working > on

Re: [PATCH] timers: Fix timer inaccuracy

On 2016-11-12 03:25, Thomas Gleixner wrote: On Fri, 11 Nov 2016, Saravana Kannan wrote: On 11/10/2016 02:07 AM, Thomas Gleixner wrote: > Deferrable timers shouldn't have been invented in the first place and yes, > they are not going to happen on hrtimers, quite the contrary, I'm working > on

Re: [PATCH v4 0/5] Simplify hotplug/suspend handling

Rafael J. Wysocki wrote: > On Thursday, July 24, 2014 06:07:23 PM Saravana Kannan wrote: >> Series of patchs to simplify policy/sysfs/kobj/locking handling across >> suspend/resume > > I need someone to review this series for me. Viresh or Srivatsa, > preferably > both. > > Thanks! This took

Re: [PATCH v4 0/5] Simplify hotplug/suspend handling

Rafael J. Wysocki wrote: On Thursday, July 24, 2014 06:07:23 PM Saravana Kannan wrote: Series of patchs to simplify policy/sysfs/kobj/locking handling across suspend/resume I need someone to review this series for me. Viresh or Srivatsa, preferably both. Thanks! This took quite a bit

Re: [PATCH] cpufreq, store_scaling_governor requires policy->rwsem to be held for duration of changing governors [v2]

Viresh Kumar wrote: > On 5 August 2014 01:46, Saravana Kannan wrote: >> The problem is when between one thread trying to cat a governor's file >> (say, >> sampling_rate) vs the governor getting a POLICY_EXIT. > > I don't see two threads racing against each other here. Simply changing > the

Re: [PATCH] cpufreq, store_scaling_governor requires policy-rwsem to be held for duration of changing governors [v2]

Viresh Kumar wrote: On 5 August 2014 01:46, Saravana Kannan skan...@codeaurora.org wrote: The problem is when between one thread trying to cat a governor's file (say, sampling_rate) vs the governor getting a POLICY_EXIT. I don't see two threads racing against each other here. Simply

Re: [PATCH v4 0/5] Simplify hotplug/suspend handling

Saravana Kannan wrote: > Series of patchs to simplify policy/sysfs/kobj/locking handling across > suspend/resume > Bump. -Saravana -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line

Re: [PATCH v4 0/5] Simplify hotplug/suspend handling

Saravana Kannan wrote: Series of patchs to simplify policy/sysfs/kobj/locking handling across suspend/resume Bump. -Saravana -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe

Re: [PATCH] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend

Viresh Kumar wrote: > On 24 July 2014 08:32, Saravana Kannan wrote: >> Ok, I think I've figured this out. But one question. Is it possible to >> physically remove one CPU in a bunch of "related cpus" without also >> unplugging the rest? Put another way, can you unplug one core from a >> cluster?

Re: [PATCH] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend

Viresh Kumar wrote: On 24 July 2014 08:32, Saravana Kannan skan...@codeaurora.org wrote: Ok, I think I've figured this out. But one question. Is it possible to physically remove one CPU in a bunch of related cpus without also unplugging the rest? Put another way, can you unplug one core from

Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend

Srivatsa S. Bhat wrote: > On 07/15/2014 11:06 AM, Saravana Kannan wrote: >> On 07/14/2014 09:35 PM, Viresh Kumar wrote: >>> On 15 July 2014 00:38, Saravana Kannan wrote: Yeah, it definitely crashes if policy->cpu if an offline cpu. Because the mutex would be uninitialized if it's

Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend

Srivatsa S. Bhat wrote: On 07/15/2014 11:06 AM, Saravana Kannan wrote: On 07/14/2014 09:35 PM, Viresh Kumar wrote: On 15 July 2014 00:38, Saravana Kannan skan...@codeaurora.org wrote: Yeah, it definitely crashes if policy-cpu if an offline cpu. Because the mutex would be uninitialized if

Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend

skan...@codeaurora.org wrote: > > Viresh Kumar wrote: >> Hi Saravana, >> >> Thanks for trying this.. >> >> On 11 July 2014 09:48, Saravana Kannan wrote: >>> The CPUfreq driver moves the cpufreq policy ownership between CPUs when >> >> s/driver/core > > Will do > S many typos. This is what

Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend

Srivatsa S. Bhat wrote: > On 07/11/2014 09:48 AM, Saravana Kannan wrote: >> The CPUfreq driver moves the cpufreq policy ownership between CPUs when >> CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When >> moving policy ownership between CPUs, it also moves the cpufreq sysfs

Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend

Viresh Kumar wrote: > Hi Saravana, > > Thanks for trying this.. > > On 11 July 2014 09:48, Saravana Kannan wrote: >> The CPUfreq driver moves the cpufreq policy ownership between CPUs when > > s/driver/core Will do > >> CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When

Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend

Viresh Kumar wrote: Hi Saravana, Thanks for trying this.. On 11 July 2014 09:48, Saravana Kannan skan...@codeaurora.org wrote: The CPUfreq driver moves the cpufreq policy ownership between CPUs when s/driver/core Will do CPUs within a cluster (CPUs sharing same policy) go

Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend

Srivatsa S. Bhat wrote: On 07/11/2014 09:48 AM, Saravana Kannan wrote: The CPUfreq driver moves the cpufreq policy ownership between CPUs when CPUs within a cluster (CPUs sharing same policy) go ONLINE/OFFLINE. When moving policy ownership between CPUs, it also moves the cpufreq sysfs

Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend

skan...@codeaurora.org wrote: Viresh Kumar wrote: Hi Saravana, Thanks for trying this.. On 11 July 2014 09:48, Saravana Kannan skan...@codeaurora.org wrote: The CPUfreq driver moves the cpufreq policy ownership between CPUs when s/driver/core Will do snip S many typos. This is

Re: [PATCH] cpufreq: Set policy to non-NULL only after all hotplug online work is done

Viresh Kumar wrote: > On 24 February 2014 14:17, wrote: >> Sorry, not sure I understand what you mean. >> >> I agree, wording in my commit text might be unclear. I'll fix it after >> we >> agree on the code fix. In the MSM case, each CPU has it's own policy. >> >> I'm assuming your original

Re: [PATCH] cpufreq: Set policy to non-NULL only after all hotplug online work is done

Viresh Kumar wrote: > On 24 February 2014 14:11, wrote: >> I just replied to the other email. I think I answered both your >> questions >> there. Sorry about mixing up CPU and policy. In my case, each CPU is >> independently scalable -- so for now take CPU == policy. I'll fix it up >> once we

Re: [PATCH] cpufreq: Set policy to non-NULL only after all hotplug online work is done

Viresh Kumar wrote: > On 24 February 2014 13:12, Srivatsa S. Bhat > wrote: >> On 02/24/2014 12:27 PM, Saravana Kannan wrote: >>> The existing code sets the per CPU policy to a non-NULL value before >>> all >>> the steps performed during the hotplug online path is done. >>> Specifically, >>> this

Re: [PATCH] cpufreq: Set policy to non-NULL only after all hotplug online work is done

Srivatsa S. Bhat wrote: > On 02/24/2014 12:27 PM, Saravana Kannan wrote: >> The existing code sets the per CPU policy to a non-NULL value before all >> the steps performed during the hotplug online path is done. >> Specifically, >> this is done before the policy min/max, governors, etc are

Re: [PATCH] cpufreq: Set policy to non-NULL only after all hotplug online work is done

Srivatsa S. Bhat wrote: On 02/24/2014 12:27 PM, Saravana Kannan wrote: The existing code sets the per CPU policy to a non-NULL value before all the steps performed during the hotplug online path is done. Specifically, this is done before the policy min/max, governors, etc are initialized

Re: [PATCH] cpufreq: Set policy to non-NULL only after all hotplug online work is done

Viresh Kumar wrote: On 24 February 2014 13:12, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: On 02/24/2014 12:27 PM, Saravana Kannan wrote: The existing code sets the per CPU policy to a non-NULL value before all the steps performed during the hotplug online path is done.

Re: [PATCH] cpufreq: Set policy to non-NULL only after all hotplug online work is done

Viresh Kumar wrote: On 24 February 2014 14:11, skan...@codeaurora.org wrote: I just replied to the other email. I think I answered both your questions there. Sorry about mixing up CPU and policy. In my case, each CPU is independently scalable -- so for now take CPU == policy. I'll fix it up

Re: [PATCH] cpufreq: Set policy to non-NULL only after all hotplug online work is done

Viresh Kumar wrote: On 24 February 2014 14:17, skan...@codeaurora.org wrote: Sorry, not sure I understand what you mean. I agree, wording in my commit text might be unclear. I'll fix it after we agree on the code fix. In the MSM case, each CPU has it's own policy. I'm assuming your

Re: [Patch 2/3] clk: skip re-parenting orphan clk

Ambresh K wrote: > From: Ambresh K > > If clk is same as orphan clk than skip the iteration, there Typo: than => then > by avoiding unnecessary look-up. > > Signed-off-by: Ambresh K > --- > drivers/clk/clk.c |4 > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git

Re: [Patch 2/3] clk: skip re-parenting orphan clk

Ambresh K wrote: From: Ambresh K ambr...@ti.com If clk is same as orphan clk than skip the iteration, there Typo: than = then by avoiding unnecessary look-up. Signed-off-by: Ambresh K ambr...@ti.com --- drivers/clk/clk.c |4 1 files changed, 4 insertions(+), 0 deletions(-)