Re: [RFC/PATCH 0/5] DVFS in the OPP core

2019-02-08 Thread Viresh Kumar
On 08-02-19, 11:31, Ulf Hansson wrote: > On Fri, 8 Feb 2019 at 11:05, Viresh Kumar wrote: > > > > On 08-02-19, 10:45, Ulf Hansson wrote: > > > On Fri, 8 Feb 2019 at 08:17, Viresh Kumar wrote: > > > > > > > > On 07-02-19, 14:37, Ulf Hansson wrote: > > > > > I think we also need to consider cross

Re: [RFC/PATCH 0/5] DVFS in the OPP core

2019-02-08 Thread Ulf Hansson
On Fri, 8 Feb 2019 at 11:05, Viresh Kumar wrote: > > On 08-02-19, 10:45, Ulf Hansson wrote: > > On Fri, 8 Feb 2019 at 08:17, Viresh Kumar wrote: > > > > > > On 07-02-19, 14:37, Ulf Hansson wrote: > > > > I think we also need to consider cross SoC drivers. One SoC may have > > > > both clocks and

Re: [RFC/PATCH 0/5] DVFS in the OPP core

2019-02-08 Thread Viresh Kumar
On 08-02-19, 10:45, Ulf Hansson wrote: > On Fri, 8 Feb 2019 at 08:17, Viresh Kumar wrote: > > > > On 07-02-19, 14:37, Ulf Hansson wrote: > > > I think we also need to consider cross SoC drivers. One SoC may have > > > both clocks and OPPs to manage, while another may have only clocks. > > > > We

Re: [RFC/PATCH 0/5] DVFS in the OPP core

2019-02-08 Thread Ulf Hansson
On Fri, 8 Feb 2019 at 08:17, Viresh Kumar wrote: > > On 07-02-19, 14:37, Ulf Hansson wrote: > > I think we also need to consider cross SoC drivers. One SoC may have > > both clocks and OPPs to manage, while another may have only clocks. > > We already have that case with CPUs as well and

Re: [RFC/PATCH 0/5] DVFS in the OPP core

2019-02-07 Thread Viresh Kumar
On 07-02-19, 14:37, Ulf Hansson wrote: > I think we also need to consider cross SoC drivers. One SoC may have > both clocks and OPPs to manage, while another may have only clocks. We already have that case with CPUs as well and dev_pm_opp_set_rate() takes care of it. > Even it this may be fairly

Re: [RFC/PATCH 0/5] DVFS in the OPP core

2019-02-07 Thread Viresh Kumar
On 06-02-19, 23:58, Stephen Boyd wrote: > Quoting Viresh Kumar (2019-01-31 01:23:49) > > FWIW, I suggested exactly this solution sometime back [1] > > > > - Drivers need to use two API sets to change clock rate (OPP helpers) > > and enable/disable them (CLK framework helpers) and this leads us

Re: [RFC/PATCH 0/5] DVFS in the OPP core

2019-02-07 Thread Rajendra Nayak
On 2/8/2019 1:17 AM, Stephen Boyd wrote: Quoting Rajendra Nayak (2019-02-06 22:57:12) 3) How do we handle devices that already have power-domains specified in DT? The opp binding for required-opps doesn't let us specify the power domain to target, instead it assumes that whatever power

Re: [RFC/PATCH 0/5] DVFS in the OPP core

2019-02-07 Thread Stephen Boyd
Quoting Rajendra Nayak (2019-02-06 22:57:12) > > > 3) How do we handle devices that already have power-domains specified in > > DT? The opp binding for required-opps doesn't let us specify the power > > domain to target, instead it assumes that whatever power domain is > > attached to a device is

Re: [RFC/PATCH 0/5] DVFS in the OPP core

2019-02-07 Thread Ulf Hansson
On Thu, 7 Feb 2019 at 08:58, Stephen Boyd wrote: > > Quoting Viresh Kumar (2019-01-31 01:23:49) > > Adding few folks to the thread who might be interested in this stuff. > > > > On 28-01-19, 17:55, Stephen Boyd wrote: > > > This patch series is an RFC around how we can implement DVFS for devices

Re: [RFC/PATCH 0/5] DVFS in the OPP core

2019-02-06 Thread Stephen Boyd
Quoting Viresh Kumar (2019-01-31 01:23:49) > Adding few folks to the thread who might be interested in this stuff. > > On 28-01-19, 17:55, Stephen Boyd wrote: > > This patch series is an RFC around how we can implement DVFS for devices > > that aren't your typical OPPish device (i.e. GPU/CPU).

Re: [RFC/PATCH 0/5] DVFS in the OPP core

2019-02-06 Thread Rajendra Nayak
3) How do we handle devices that already have power-domains specified in DT? The opp binding for required-opps doesn't let us specify the power domain to target, instead it assumes that whatever power domain is attached to a device is the one that OPP needs to use to change the genpd

Re: [RFC/PATCH 0/5] DVFS in the OPP core

2019-01-31 Thread Viresh Kumar
On 31-01-19, 11:36, Rafael J. Wysocki wrote: > On Thu, Jan 31, 2019 at 11:06 AM Viresh Kumar wrote: > > > > On 31-01-19, 10:58, Rafael J. Wysocki wrote: > > > On Thu, Jan 31, 2019 at 10:23 AM Viresh Kumar > > > wrote: > > > > > > > > Adding few folks to the thread who might be interested in

Re: [RFC/PATCH 0/5] DVFS in the OPP core

2019-01-31 Thread Rafael J. Wysocki
On Thu, Jan 31, 2019 at 11:06 AM Viresh Kumar wrote: > > On 31-01-19, 10:58, Rafael J. Wysocki wrote: > > On Thu, Jan 31, 2019 at 10:23 AM Viresh Kumar > > wrote: > > > > > > Adding few folks to the thread who might be interested in this stuff. > > > > > > On 28-01-19, 17:55, Stephen Boyd

Re: [RFC/PATCH 0/5] DVFS in the OPP core

2019-01-31 Thread Viresh Kumar
On 31-01-19, 10:58, Rafael J. Wysocki wrote: > On Thu, Jan 31, 2019 at 10:23 AM Viresh Kumar wrote: > > > > Adding few folks to the thread who might be interested in this stuff. > > > > On 28-01-19, 17:55, Stephen Boyd wrote: > > > This patch series is an RFC around how we can implement DVFS for

Re: [RFC/PATCH 0/5] DVFS in the OPP core

2019-01-31 Thread Rafael J. Wysocki
On Thu, Jan 31, 2019 at 10:23 AM Viresh Kumar wrote: > > Adding few folks to the thread who might be interested in this stuff. > > On 28-01-19, 17:55, Stephen Boyd wrote: > > This patch series is an RFC around how we can implement DVFS for devices > > that aren't your typical OPPish device (i.e.

Re: [RFC/PATCH 0/5] DVFS in the OPP core

2019-01-31 Thread Viresh Kumar
Adding few folks to the thread who might be interested in this stuff. On 28-01-19, 17:55, Stephen Boyd wrote: > This patch series is an RFC around how we can implement DVFS for devices > that aren't your typical OPPish device (i.e. GPU/CPU). They don't have a > strict set of frequencies that they

[RFC/PATCH 0/5] DVFS in the OPP core

2019-01-28 Thread Stephen Boyd
This patch series is an RFC around how we can implement DVFS for devices that aren't your typical OPPish device (i.e. GPU/CPU). They don't have a strict set of frequencies that they have been tested at to derive some operating performance point. Instead they have a coarser set of frequency max or