On Wednesday, December 09, 2015 08:04:20 AM Viresh Kumar wrote:
> On 09-12-15, 02:15, Rafael J. Wysocki wrote:
> > If there are only the two patches, why don't you ask Lee to include them
> > into the series he's working on? The dependency would be clear then too.
>
> His series was already out,
On 09-12-15, 02:15, Rafael J. Wysocki wrote:
> If there are only the two patches, why don't you ask Lee to include them
> into the series he's working on? The dependency would be clear then too.
His series was already out, and it was really about STi's cpufreq
driver and so I have resent my two p
On Tuesday, December 08, 2015 10:01:26 PM Viresh Kumar wrote:
> On 08-12-15, 17:50, Rafael J. Wysocki wrote:
> > I don't remember that code clearly and it would take some time for me to
> > recall it and then figure out the details about the changes. Not
> > impossible,
> > but quite honestly I h
On 08-12-15, 17:50, Rafael J. Wysocki wrote:
> I don't remember that code clearly and it would take some time for me to
> recall it and then figure out the details about the changes. Not impossible,
> but quite honestly I have other things to spend that time on.
>
> Also, are the patches so urgen
On Tuesday, December 08, 2015 08:31:05 PM Viresh Kumar wrote:
> On 04-12-15, 13:53, Viresh Kumar wrote:
> > On 01-12-15, 12:22, Viresh Kumar wrote:
> > > Since these functions are *only* going to be called before any OPPs
> > > are added for the device, and hence ruling out any concurrent readers,
On 04-12-15, 13:53, Viresh Kumar wrote:
> On 01-12-15, 12:22, Viresh Kumar wrote:
> > Since these functions are *only* going to be called before any OPPs
> > are added for the device, and hence ruling out any concurrent readers,
> > maybe we can guarantee that with this:
>
> @Rafael: Stephen has g
On 01-12-15, 12:22, Viresh Kumar wrote:
> Since these functions are *only* going to be called before any OPPs
> are added for the device, and hence ruling out any concurrent readers,
> maybe we can guarantee that with this:
@Rafael: Stephen has gone for vacations until end of year :(, can you
plea
On 27-11-15, 10:15, Viresh Kumar wrote:
> > > + dev_opp->supported_hw = kmemdup(versions, count * sizeof(*versions),
> > > + GFP_KERNEL);
> >
> > And then we're going to modify said opp here under the mutex
> > lock.
>
> opp-dev ..
>
> > > + if (!dev_opp->supporte
On 25-11-15, 12:51, Stephen Boyd wrote:
> > +int dev_pm_opp_set_supported_hw(struct device *dev, const u32 *versions,
> > + unsigned int count)
> > +{
> > + struct device_opp *dev_opp;
> > + int ret = 0;
> > +
> > + /* Hold our list modification lock here */
> > +
On 11/19, Viresh Kumar wrote:
> OPP bindings allow a platform to enable OPPs based on the version of the
> hardware they are used for.
>
> Add support to the OPP-core to parse these bindings, by introducing
> dev_pm_opp_{set|put}_supported_hw() APIs.
>
> Signed-off-by: Viresh Kumar
> ---
> driv
10 matches
Mail list logo
