ight to ever be turned off after boot up.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c| 39 +++
drivers/of/platform.c | 9 +
include/linux/device.h | 19 +++
3 files changed, 67 insertions(+)
diff --git a/drivers/base/c
efault we just add device-links to track "driver presence" (probe
succeeded) of the supplier device. If any other functionality provided
by device-links are needed, it is left to the consumer/supplier
devices to change the link when they probe.
Signed-off-by: Saravana Kannan
---
drivers/
. Device-S probes.
13. Device-S sync_state() isn't called because Device-C hasn't probed yet.
14. Device-C probes.
15. Device-S's sync_state() callback is called.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c| 24 ++--
drivers/base/dd.c | 29
obe will add the
children before its probe is completed and that will prevent the
supplier's sync_state from being executed before the children are
probed.
But I'll write that part once I see how this series is received.
-Saravana
Saravana Kannan (4):
driver core: Add support f
new devices get added.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c| 83 ++
include/linux/device.h | 8
2 files changed, 91 insertions(+)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index fd7511e04e62..0705926d362f 100644
On Fri, Jun 28, 2019 at 5:55 PM David Collins wrote:
>
> Hello Saravana,
>
> On 6/27/19 7:22 PM, Saravana Kannan wrote:
> > diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> > index 04ad312fd85b..8d690fa0f47c 100644
> > --- a/drivers/of/platform.c
&
On Thu, Jun 27, 2019 at 11:49 PM Viresh Kumar wrote:
>
> On 26-06-19, 11:10, Saravana Kannan wrote:
> > On Tue, Jun 25, 2019 at 11:32 PM Viresh Kumar
> > wrote:
>
> > > So, when a CPU changes frequency, we must change the performance state
> > > of PM doma
On Wed, Jun 26, 2019 at 2:31 PM Rob Herring wrote:
>
> On Mon, Jun 24, 2019 at 9:54 PM Greg Kroah-Hartman
> wrote:
> >
> > On Mon, Jun 24, 2019 at 03:37:07PM -0700, Sandeep Patil wrote:
> > > We are trying to make sure that all (most) drivers in an Aarch64 system
> > > can
> > > be kernel module
ight to ever be turned off after boot up.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c| 39 +++
drivers/of/platform.c | 9 +
include/linux/device.h | 19 +++
3 files changed, 67 insertions(+)
diff --git a/drivers/base/c
ssumptions about the number of consumers.
By default we just add device-links to track "driver presence" (probe
succeeded) of the supplier device. If any other functionality provided
by device-links are needed, it is left to the consumer/supplier
devices to change the link when they prob
t making assumptions about the number of consumers.
By default we just add device-links to track "driver presence" (probe
succeeded) of the supplier device. If any other functionality provided
by device-links are needed, it is left to the consumer/supplier
devices to change the lin
as waiting for suppliers is
generally expected to be done by the entity that's creating the
device.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c| 67 ++
include/linux/device.h | 5
2 files changed, 72 insertions(+)
diff --git a/dr
On Tue, Jun 25, 2019 at 11:32 PM Viresh Kumar wrote:
>
> On 24-06-19, 22:29, Saravana Kannan wrote:
> > No, the CPUs will be the "parent" and the cache will be the "child".
> > CPU is a special case when it comes to the actual software (not DT) as
> >
,
instead of limiting required-opps to point to only PM-domain devices,
allow it to point to any device.
Signed-off-by: Saravana Kannan
---
drivers/opp/core.c | 2 +-
drivers/opp/of.c | 14 --
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp
noc2_200: opp-2 {
opp-hz = /bits/ 64 <2>;
};
noc2_134: opp-13400 {
opp-hz = /bits/ 64 <13400>;
};
noc2_100: opp-1 {
opp-h
The OPP table can be used often in devfreq. Trying to get it each time can
be expensive, so cache it in the devfreq struct.
Signed-off-by: Saravana Kannan
---
drivers/devfreq/devfreq.c | 6 ++
include/linux/devfreq.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/devfreq
Look at the required OPPs of the "parent" device to determine the OPP that
is required from the slave device managed by the passive governor. This
allows having mappings between a parent device and a slave device even when
they don't have the same number of OPPs.
Signed-off-by:
Add a function that allows looking up required OPPs given a source OPP
table, destination OPP table and the source OPP.
Signed-off-by: Saravana Kannan
---
drivers/opp/core.c | 54 ++
include/linux/pm_opp.h | 11 +
2 files changed, 65
On Mon, Jun 24, 2019 at 10:22 PM Viresh Kumar wrote:
>
> On 24-06-19, 22:00, Saravana Kannan wrote:
> > All of the cases above are some real world scenarios I've come across.
> > CPU and L2/L3 on ARM systems are a good example of (2) but the passive
> > governor does
On Mon, Jun 24, 2019 at 9:11 PM Viresh Kumar wrote:
>
> On 24-06-19, 15:17, Saravana Kannan wrote:
> > Here's an example. This can't be done today, but can be done with this
> > change.
> >
> > In arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi you have so
On Mon, Jun 24, 2019 at 2:43 AM Viresh Kumar wrote:
>
> On 21-06-19, 17:34, Saravana Kannan wrote:
> > The devfreq passive governor scales the frequency of a "child" device
> > based on the current frequency of a "parent" device (not parent/child in
> >
On Sat, Jun 22, 2019 at 9:28 PM Chanwoo Choi wrote:
>
> Hi,
>
> 2019년 6월 23일 (일) 오전 6:42, Saravana Kannan 님이 작성:
> >
> > On Sat, Jun 22, 2019 at 4:50 AM Chanwoo Choi wrote:
> > >
> > > Hi,
> > >
> > > Absolutely, I like this approac
On Sat, Jun 22, 2019 at 5:01 AM Chanwoo Choi wrote:
>
> Hi,
>
> Absolutely, I agree this approach.
Thanks!
> But, I add some comments on below. please check them.
>
> 2019년 6월 22일 (토) 오전 9:36, Saravana Kannan 님이 작성:
> >
> > Look at the required OPPs of the &qu
On Sat, Jun 22, 2019 at 4:50 AM Chanwoo Choi wrote:
>
> Hi,
>
> Absolutely, I like this approach. I think that it is necessary to make
> the connection
> between frequencies of devices.
Happy to hear that.
> But, I have a question on below.
>
> 2019년 6월 22일 (토) 오전
Look at the required OPPs of the "parent" device to determine the OPP that
is required from the slave device managed by the passive governor. This
allows having mappings between a parent device and a slave device even when
they don't have the same number of OPPs.
Signed-off-by:
ency to
child's frequency.
Since OPPs already support pointing to other "required-opps", add
support for using that to map from parent device frequency to child
device frequency. That way, every child device driver doesn't have to
implement a separate mapping function anytime (
Add a function that allows looking up required OPPs given a source OPP
table, destination OPP table and the source OPP.
Signed-off-by: Saravana Kannan
---
drivers/opp/core.c | 54 ++
include/linux/pm_opp.h | 11 +
2 files changed, 65
,
instead of limiting required-opps to point to only PM-domain devices,
allow it to point to any device.
Signed-off-by: Saravana Kannan
---
drivers/opp/core.c | 2 +-
drivers/opp/of.c | 14 --
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp
On Wed, Jun 19, 2019 at 1:09 PM 'Joel Fernandes' via kernel-team
wrote:
>
> On Wed, Jun 19, 2019 at 3:59 PM 'Saravana Kannan' via kernel-team
> wrote:
> >
> >
> >
> > On Wed, Jun 19, 2019, 11:55 AM 'Joel Fernandes' via kernel-team
&
On Tue, Jun 18, 2019 at 1:47 PM Sandeep Patil wrote:
>
> On Wed, Jun 12, 2019 at 12:29:18PM -0700, 'Saravana Kannan' via kernel-team
> wrote:
> > On Wed, Jun 12, 2019 at 11:19 AM Rob Herring wrote:
> > >
> > > On Wed, Jun 12, 2019 at 11:08 AM Greg Kro
On Mon, Jun 17, 2019 at 8:44 AM Georgi Djakov wrote:
>
> Hi Saravana,
>
> On 6/14/19 07:17, Saravana Kannan wrote:
> > Add a icc_create_devfreq() and icc_remove_devfreq() to create and remove
> > devfreq devices for interconnect paths. A driver can create/remove dev
-by: Saravana Kannan
---
drivers/opp/core.c | 8
include/linux/pm_opp.h | 7 +++
2 files changed, 15 insertions(+)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index c9914afd508a..668a377f59a5 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -943,6 +943,14
an interconnect path by calling icc_get_opp_table().
Signed-off-by: Saravana Kannan
---
drivers/interconnect/core.c | 27 ++-
include/linux/interconnect.h | 7 +++
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/interconnect/core.c b/drivers
This allows finding a device's OPP table (when it has multiple) from a
phandle to the OPP table in DT.
Signed-off-by: Saravana Kannan
---
drivers/opp/of.c | 42 ++
include/linux/pm_opp.h | 7 +++
2 files changed, 41 insertions(+), 8 dele
peak and average
bandwidth for a given (or suspend) OPP entry.
Signed-off-by: Saravana Kannan
---
drivers/opp/core.c | 51 ++
include/linux/pm_opp.h | 19
2 files changed, 70 insertions(+)
diff --git a/drivers/opp/core.c b/drivers/opp
Add a function that allows looking up required OPPs given a source OPP
table, destination OPP table and the source OPP.
Signed-off-by: Saravana Kannan
---
drivers/opp/core.c | 54 ++
include/linux/pm_opp.h | 11 +
2 files changed, 65
oc MASTER_GPU_1 &bimc SLAVE_DDR>;
interconnect-names = "gpu-cache", "gpu-mem";
interconnect-opp-table = <&gpu_cache_opp_table>, <&gpu_ddr_opp_table>
};
Cheers,
Saravana
[1] - https://lore.kernel.org/lkml/20190601021228.210574-1-sarava...@goog
Not all devices quantify their performance points in terms of frequency.
Devices like interconnects quantify their performance points in terms of
bandwidth. We need a way to represent these bandwidth levels in OPP. So,
add support for parsing bandwidth OPPs from DT.
Signed-off-by: Saravana Kannan
property that can be used in Bandwidth OPP
tables.
Signed-off-by: Saravana Kannan
---
Documentation/devicetree/bindings/opp/opp.txt | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree
Look at the required OPPs of the "parent" device to determine the OPP that
is required from the slave device managed by the passive governor. This
allows having mappings between a parent device and a slave device even when
they don't have the same number of OPPs.
Signed-off-by:
and the device driver itself doesn't have to actively manage the bandwidth
votes for the interconnects.
Signed-off-by: Saravana Kannan
---
drivers/interconnect/Makefile | 2 +-
drivers/interconnect/icc-devfreq.c | 156 +
include/linux/interconnect.h
Add support for listing bandwidth OPP tables for each interconnect path
listed using the interconnects property.
Signed-off-by: Saravana Kannan
---
.../devicetree/bindings/interconnect/interconnect.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree
,
instead of limiting required-opps to point to only PM-domain devices,
allow it to point to any device.
Signed-off-by: Saravana Kannan
---
drivers/opp/core.c | 2 +-
drivers/opp/of.c | 14 --
2 files changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/opp/core.c b/drivers/opp
On Wed, Jun 12, 2019 at 2:12 PM Rob Herring wrote:
>
> On Wed, Jun 12, 2019 at 1:29 PM Saravana Kannan wrote:
> >
> > On Wed, Jun 12, 2019 at 11:19 AM Rob Herring wrote:
> > >
> > > On Wed, Jun 12, 2019 at 11:08 AM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > On Wed, Jun 12, 2019 at 07:53:39AM -0600, Rob Herring wrote:
> > > > > On Tue, Jun 11, 2019 at 3:52 PM Sandeep Patil
> > > > > wrote:
> > > > > >
> > > > > > On Tue, Jun 11, 2019 at 0
uot; DT node to tell the OS that the implicit
dependencies are valid real dependencies too. Then if they need
overrides, depends-on can be used. So old DT blobs would effectively
have this feature disabled.
- Handles all cases
- Only (c) above could be argued as OS configuration. But I'd argue
On Tue, Jun 11, 2019 at 7:56 AM Frank Rowand wrote:
>
> Hi Saravana,
>
> On 5/24/19 9:04 PM, Saravana Kannan wrote:
> > On Fri, May 24, 2019 at 7:40 PM Frank Rowand wrote:
> >>
> >> Hi Saranova,
> >>
> >> I'll try to address the other
>
> On 5/24/19 5:12 PM, Frank Rowand wrote:
> > On 5/24/19 11:21 AM, Saravana Kannan wrote:
> >> On Fri, May 24, 2019 at 10:56 AM Frank Rowand
> >> wrote:
> >>>
> >>> Hi Sarvana,
> >>>
> >>> I'm not reviewing
devfreq.
-Saravana
Signed-off-by: Saravana Kannan
---
drivers/crypto/qcom-rng.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/crypto/qcom-rng.c b/drivers/crypto/qcom-rng.c
index e54249ccc009..7a92238061ca 100644
--- a/drivers/crypto/qcom-rng.c
+++ b/drivers/crypto/qco
On Fri, Jun 7, 2019 at 10:46 PM Bjorn Andersson
wrote:
>
> On Fri 07 Jun 21:43 PDT 2019, Saravana Kannan wrote:
>
> > I replied[1] to this patch series[2] and described how I think interconnect
> > bandwidth voting should be captured in DT and how it should work.
> >
an interconnect path by calling icc_get_opp_table().
Signed-off-by: Saravana Kannan
---
drivers/interconnect/core.c | 27 ++-
include/linux/interconnect.h | 7 +++
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/interconnect/core.c b/drivers
peak and average
bandwidth for a given (or suspend) OPP entry.
Signed-off-by: Saravana Kannan
---
drivers/opp/core.c | 51 ++
include/linux/pm_opp.h | 19
2 files changed, 70 insertions(+)
diff --git a/drivers/opp/core.c b/drivers/opp
Add support for listing bandwidth OPP tables for each interconnect path
listed using the interconnects property.
Signed-off-by: Saravana Kannan
---
.../devicetree/bindings/interconnect/interconnect.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree
-by: Saravana Kannan
---
drivers/opp/core.c | 8
include/linux/pm_opp.h | 7 +++
2 files changed, 15 insertions(+)
diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index d96d5746eb47..9d49aee2c3ef 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -943,6 +943,14
Not all devices quantify their performance points in terms of frequency.
Devices like interconnects quantify their performance points in terms of
bandwidth. We need a way to represent these bandwidth levels in OPP. So,
add support for parsing bandwidth OPPs from DT.
Signed-off-by: Saravana Kannan
and the device driver itself doesn't have to actively manage the bandwidth
votes for the interconnects.
Signed-off-by: Saravana Kannan
---
drivers/interconnect/Makefile | 2 +-
drivers/interconnect/icc-devfreq.c | 145 +
include/linux/interconnect.h
Add a function that allows looking up required OPPs given a source OPP
table, destination OPP table and the source OPP.
Signed-off-by: Saravana Kannan
---
drivers/opp/core.c | 50 ++
include/linux/pm_opp.h | 11 ++
2 files changed, 61
ot;gpu-mem";
interconnect-opp-table = <&gpu_cache_opp_table>, <&gpu_ddr_opp_table>
};
Cheers,
Saravana
[1] - https://lore.kernel.org/lkml/20190601021228.210574-1-sarava...@google.com/
[2] -
https://lore.kernel.org/lkml/20190423132823.7915-1-georgi.dja...@linaro.org/
Sa
property that can be used in Bandwidth OPP
tables.
Signed-off-by: Saravana Kannan
---
Documentation/devicetree/bindings/opp/opp.txt | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/opp/opp.txt
b/Documentation/devicetree
This allows finding a device's OPP table (when it has multiple) from a
phandle to the OPP table in DT.
Signed-off-by: Saravana Kannan
---
drivers/opp/of.c | 42 ++
include/linux/pm_opp.h | 7 +++
2 files changed, 41 insertions(+), 8 dele
as waiting for suppliers is
generally expected to be done by the entity that's creating the
device.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c| 67 ++
include/linux/device.h | 5
2 files changed, 72 insertions(+)
diff --git a/dr
ight to ever be turned off after boot up.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c| 39 +++
drivers/of/platform.c | 9 +
include/linux/device.h | 19 +++
3 files changed, 67 insertions(+)
diff --git a/drivers/base/c
The depends-on property is used to list the mandatory functional
dependencies of a consumer device on zero or more supplier devices.
Signed-off-by: Saravana Kannan
---
.../devicetree/bindings/depends-on.txt| 26 +++
1 file changed, 26 insertions(+)
create mode 100644
number of consumers.
By default we just add device-links to track "driver presence" (probe
succeeded) of the supplier device. If any other functionality provided
by device-links are needed, it is left to the consumer/supplier devices
to change the link when they p
es without making assumptions about the number of consumers.
By default we just add device-links to track "driver presence" (probe
succeeded) of the supplier device. If any other functionality provided
by device-links are needed, it is left to the consumer/supplier
device
own of_node.
Signed-off-by: Saravana Kannan
---
drivers/of/platform.c | 20 +++-
include/linux/of.h| 3 +++
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 04ad312fd85b..1115a8d80a33 100644
--- a/drivers/of
On Mon, Jun 3, 2019 at 8:56 AM Jordan Crouse wrote:
>
> On Fri, May 31, 2019 at 07:12:28PM -0700, Saravana Kannan wrote:
> > I'll have to Nack this series because it's making a couple of wrong
> > assumptions
> > about bandwidth voting.
> >
> > Fi
I'll have to Nack this series because it's making a couple of wrong assumptions
about bandwidth voting.
Firstly, it's mixing up OPP to bandwidth mapping (Eg: CPU freq to CPU<->DDR
bandwidth mapping) with the bandwidth levels that are actually supported by an
interconnect path (Eg: CPU<->DDR bandwi
ay 29, 2019 at 1:00 PM Saravana Kannan wrote:
>
> Frank, Rob, Mark,
>
> Gentle reminder. I've replied to your emails spread across the different
> patches in the series. Hoping they address your questions and concerns.
> Please let me know what you think.
>
> Thanks,
>
On Fri, May 24, 2019 at 7:40 PM Frank Rowand wrote:
>
> Hi Saranova,
>
> I'll try to address the other portions of this email that I
> in my previous replies.
>
>
> On 5/24/19 2:53 PM, Saravana Kannan wrote:
> > On Fri, May 24, 2019 at 10:49 AM Frank Rowand
&
On Thu, May 23, 2019 at 10:52 PM Greg Kroah-Hartman
wrote:
>
> On Thu, May 23, 2019 at 06:01:11PM -0700, Saravana Kannan wrote:
> > Add a generic "depends-on" property that allows specifying mandatory
> > functional dependencies between devices. Add device-links after
Ugh... mobile app is sending HTML emails. Replying again.
On Fri, May 24, 2019 at 5:25 PM Frank Rowand wrote:
>
> On 5/24/19 5:22 PM, Frank Rowand wrote:
> > On 5/24/19 2:53 PM, Saravana Kannan wrote:
> >> On Fri, May 24, 2019 at 10:49 AM Frank Rowand
> >> wrote:
On Fri, May 24, 2019 at 8:01 AM Mark Rutland wrote:
>
> On Thu, May 23, 2019 at 06:01:14PM -0700, Saravana Kannan wrote:
> > The depends-on property is used to list the mandatory functional
> > dependencies of a consumer device on zero or more supplier devices.
> >
>
On Fri, May 24, 2019 at 10:49 AM Frank Rowand wrote:
>
> On 5/23/19 6:01 PM, Saravana Kannan wrote:
> > Add a generic "depends-on" property that allows specifying mandatory
> > functional dependencies between devices. Add device-links after the
> > devices are c
Before I address all the comments, a friendly reminder: Whatever
solution we come up with needs to work on a system with loadable
modules and shouldn't depend on userspace for correctness.
On Fri, May 24, 2019 at 6:04 AM Rob Herring wrote:
>
> On Thu, May 23, 2019 at 8:01 PM Sara
ment below,
> to give some feedback as you continue thinking through possible
> implementations to solve the underlying problems.
Appreciate the feedback Frank!
>
>
> On 5/23/19 6:01 PM, Saravana Kannan wrote:
> > Add a pointer from device tree node to the device created
own of_node.
Signed-off-by: Saravana Kannan
---
drivers/of/platform.c | 20 +++-
include/linux/of.h| 3 +++
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 04ad312fd85b..1115a8d80a33 100644
--- a/drivers/of
number of consumers.
By default we just add device-links to track "driver presence" (probe
succeeded) of the supplier device. If any other functionality provided
by device-links are needed, it is left to the consumer/supplier devices
to change the link when they p
as waiting for suppliers is
generally expected to be done by the entity that's creating the
device.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c| 67 ++
include/linux/device.h | 5
2 files changed, 72 insertions(+)
diff --git a/dr
es without making assumptions about the number of consumers.
By default we just add device-links to track "driver presence" (probe
succeeded) of the supplier device. If any other functionality provided
by device-links are needed, it is left to the consumer/supplier
device
The depends-on property is used to list the mandatory functional
dependencies of a consumer device on zero or more supplier devices.
Signed-off-by: Saravana Kannan
---
.../devicetree/bindings/depends-on.txt| 26 +++
1 file changed, 26 insertions(+)
create mode 100644
ight to ever be turned off after boot up.
Signed-off-by: Saravana Kannan
---
drivers/base/core.c| 39 +++
drivers/of/platform.c | 9 +
include/linux/device.h | 19 +++
3 files changed, 67 insertions(+)
diff --git a/drivers/base/c
On 11/9/16 4:10 PM, Chanwoo Choi wrote:
Hi,
On 2016년 11월 10일 05:34, Saravana Kannan wrote:
On 11/08/2016 06:38 PM, Chanwoo Choi wrote:
On 2016년 11월 09일 11:36, Chanwoo Choi wrote:
Hi,
On 2016년 11월 09일 10:33, Chanwoo Choi wrote:
On 2016년 11월 09일 05:52, Saravana Kannan wrote:
On 11/08/2016
On 10/03/2018 02:33 AM, Sudeep Holla wrote:
On Tue, Oct 02, 2018 at 11:56:56AM -0700, Saravana Kannan wrote:
On 10/02/2018 04:17 AM, Sudeep Holla wrote:
[...]
Yes, I do understand I have made the same point multiple time and it's
intentional. We need to get the fragmented f/w su
On 10/02/2018 04:17 AM, Sudeep Holla wrote:
On Mon, Oct 01, 2018 at 04:49:32PM -0700, Saravana Kannan wrote:
On 09/26/2018 07:48 AM, Sudeep Holla wrote:
On Wed, Sep 26, 2018 at 05:42:15PM +0300, Georgi Djakov wrote:
Hi Rob,
Thanks for the comments!
On 09/25/2018 09:02 PM, Rob Herring
On 09/26/2018 07:48 AM, Sudeep Holla wrote:
On Wed, Sep 26, 2018 at 05:42:15PM +0300, Georgi Djakov wrote:
Hi Rob,
Thanks for the comments!
On 09/25/2018 09:02 PM, Rob Herring wrote:
On Fri, Aug 31, 2018 at 05:01:45PM +0300, Georgi Djakov wrote:
This binding is intended to represent the rela
On 10/01/2018 02:26 PM, Jordan Crouse wrote:
On Mon, Oct 01, 2018 at 01:56:32PM -0700, Saravana Kannan wrote:
On 09/26/2018 07:34 AM, Jordan Crouse wrote:
On Tue, Sep 25, 2018 at 01:02:15PM -0500, Rob Herring wrote:
On Fri, Aug 31, 2018 at 05:01:45PM +0300, Georgi Djakov wrote:
This
On 09/26/2018 07:34 AM, Jordan Crouse wrote:
On Tue, Sep 25, 2018 at 01:02:15PM -0500, Rob Herring wrote:
On Fri, Aug 31, 2018 at 05:01:45PM +0300, Georgi Djakov wrote:
This binding is intended to represent the relations between the interconnect
controllers (providers) and consumer device no
uency.
Signed-off-by: Saravana Kannan
---
Documentation/devicetree/bindings/devfreq/icbw.txt | 21
drivers/devfreq/Kconfig| 13 +++
drivers/devfreq/Makefile | 1 +
drivers/devfreq/devfreq_icbw.c | 116 +++
frequency, the device
runs at its min frequency. And interpolated for frequencies in between.
Signed-off-by: Saravana Kannan
---
.../bindings/devfreq/devfreq-cpufreq-map.txt | 53 ++
drivers/devfreq/Kconfig| 8 +
drivers/devfreq/Makefile
.
Signed-off-by: Saravana Kannan
---
.../bindings/devfreq/devfreq-cpufreq.txt | 53 ++
drivers/devfreq/Kconfig| 8 +
drivers/devfreq/Makefile | 1 +
drivers/devfreq/governor_cpufreq.c | 583
On 05/27/2018 11:00 PM, 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 06/05/2018 01:46 PM, Joel Fernandes wrote:
On Tue, Jun 05, 2018 at 05:54:31PM +0100, Patrick Bellasi wrote:
On 05-Jun 17:31, Juri Lelli wrote:
On 05/06/18 16:11, Patrick Bellasi wrote:
[...]
If I run an experiment with your example above, while using the
performance governor to rule out a
Chanwoo,
Friendly reminder for a review. I've addressed your comments on v1 of
this patch.
-Saravana
On 05/18/2018 01:24 AM, Saravana Kannan wrote:
This devfreq governor is a generic implementation that can scale any
devfreq device based on the current CPU frequency of all ONLINE CPU
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 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
On 05/18/2018 11:55 AM, Joel Fernandes (Google.) wrote:
From: "Joel Fernandes (Google)"
Currently there is a chance of a schedutil cpufreq update request to be
dropped if there is a pending update request. This pending request can
be delayed if there is a scheduling delay of the irq_work and th
This reverts commit f9f41e3ef99ac9d4e91b07634362e393fb929aad.
Change-Id: Iddde3ef56c9e5b14dcb14f8737899b85e56f5b43
---
drivers/cpufreq/cpufreq.c | 16 +++-
include/linux/cpufreq.h | 3 +++
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/d
proportion to the CPU frequency.
Change-Id: I7f786b9059435afe85b9ec8c504a4655731ee20e
Signed-off-by: Saravana Kannan
---
.../bindings/devfreq/devfreq-cpufreq.txt | 53 ++
drivers/devfreq/Kconfig| 8 +
drivers/devfreq/Makefile | 1
between.
Since CPUs/clusters can be hotplugged and their policies disables, this
devfreq governor also has to listen to CPU freq policy notifiers for these
events. So, this patch brings back the policy CREATE/REMOVE notifiers.
Saravana Kannan (2):
Revert "cpufreq: Remove policy create/r
and cluster 1) that wants to vote for a
particular device's frequency (say, L3 frequency) is represented as a
separate voter device (qcom,devfreq-fw-voter) that's a child of the
firmware device (qcom,devfreq-fw).
Signed-off-by: Saravana Kannan
---
.../bindings/devfreq/devfreq-q
701 - 800 of 1001 matches
Mail list logo