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
>>CPUs
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 p
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 interconn
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
>>b/Documentation/dev
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 performan
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
+++ b/Documenta
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 *
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.
Sig
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.
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
drive
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, "
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 intercon
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 po
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 sche
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 RAM/DDR
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 the
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 si
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 poo
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 in
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
Sig
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. :-)
Cha
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.
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 variou
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
> >
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 unnecessary
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 unnecessa
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 eli
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 qui
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 govern
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 "unsubscr
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?
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 s
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
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
>
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
>>
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 comp
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 ag
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
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 initial
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 a/driv
40 matches
Mail list logo
