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 S
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
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 a
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 dev_pm_op
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
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 t
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 doma
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
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
>
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). The
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 performanc
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 this
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 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 wrote:
> > > This patch series is an RFC around how we can implement DVFS for d
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. G
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
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 '
17 matches
Mail list logo