On Fri, Jul 22, 2016 at 08:16:42AM -0700, Viresh Kumar wrote:
> > Long term as I was mentioning in the other thread I think it'd be good
> > if the current target() drivers were modified to supply resolve_freq(),
> > and that cpufreq_register_driver() were again changed to require it for
> > those
On 21-07-16, 17:44, Steve Muckle wrote:
> Going back and checking I see I was thinking of your suggestion that
> cpufreq_register_driver() check that only target() drivers offer a
> resolve_freq() callback. I put a comment for this in cpufreq.h but not a
> check - I could add a check in another pat
On Thu, Jul 21, 2016 at 04:36:48PM -0700, Steve Muckle wrote:
> As another alternative, this could be caught in cpufreq driver
> initialization? I believe you suggested that originally, but I avoided
> it as I didn't want to have to implement resolve_freq() for every
> target() style driver. It sou
On Thu, Jul 21, 2016 at 04:36:48PM -0700, Steve Muckle wrote:
> On Thu, Jul 21, 2016 at 04:30:03PM -0700, Viresh Kumar wrote:
> > On 21-07-16, 16:21, Steve Muckle wrote:
> > > On Thu, Jul 21, 2016 at 01:30:41PM -0700, Viresh Kumar wrote:
> > > > Okay, but in that case shouldn't we do something like
On Thu, Jul 21, 2016 at 04:30:03PM -0700, Viresh Kumar wrote:
> On 21-07-16, 16:21, Steve Muckle wrote:
> > On Thu, Jul 21, 2016 at 01:30:41PM -0700, Viresh Kumar wrote:
> > > Okay, but in that case shouldn't we do something like this:
> > >
> > > unsigned int cpufreq_driver_resolve_freq(struct cp
On 21-07-16, 16:29, Steve Muckle wrote:
> On Thu, Jul 21, 2016 at 04:21:31PM -0700, Steve Muckle wrote:
> > On Thu, Jul 21, 2016 at 01:30:41PM -0700, Viresh Kumar wrote:
> > > Okay, but in that case shouldn't we do something like this:
> > >
> > > unsigned int cpufreq_driver_resolve_freq(struct cp
On 21-07-16, 16:21, Steve Muckle wrote:
> On Thu, Jul 21, 2016 at 01:30:41PM -0700, Viresh Kumar wrote:
> > Okay, but in that case shouldn't we do something like this:
> >
> > unsigned int cpufreq_driver_resolve_freq(struct cpufreq_policy *policy,
> > unsign
On Thu, Jul 21, 2016 at 04:21:31PM -0700, Steve Muckle wrote:
> On Thu, Jul 21, 2016 at 01:30:41PM -0700, Viresh Kumar wrote:
> > Okay, but in that case shouldn't we do something like this:
> >
> > unsigned int cpufreq_driver_resolve_freq(struct cpufreq_policy *policy,
> >
On Thu, Jul 21, 2016 at 01:30:41PM -0700, Viresh Kumar wrote:
> Okay, but in that case shouldn't we do something like this:
>
> unsigned int cpufreq_driver_resolve_freq(struct cpufreq_policy *policy,
> unsigned int target_freq)
> {
>target_freq = cla
On Thursday, July 21, 2016 01:52:45 PM Viresh Kumar wrote:
> On 21-07-16, 22:52, Rafael J. Wysocki wrote:
> > That'd be fine by me.
> >
> > Please send a patch on top of the Steve's series and I can apply it too
> > (unless Steve sees some major problems in it, which seems unlikely to me).
>
> Su
On 21-07-16, 23:19, Rafael J. Wysocki wrote:
> On Thursday, July 21, 2016 01:52:45 PM Viresh Kumar wrote:
> > On 21-07-16, 22:52, Rafael J. Wysocki wrote:
> > > That'd be fine by me.
> > >
> > > Please send a patch on top of the Steve's series and I can apply it too
> > > (unless Steve sees some m
On 13-07-16, 13:25, Steve Muckle wrote:
> +unsigned int cpufreq_driver_resolve_freq(struct cpufreq_policy *policy,
> + unsigned int target_freq)
> +{
> + target_freq = clamp_val(target_freq, policy->min, policy->max);
> + policy->cached_target_freq = tar
On 21-07-16, 22:52, Rafael J. Wysocki wrote:
> That'd be fine by me.
>
> Please send a patch on top of the Steve's series and I can apply it too
> (unless Steve sees some major problems in it, which seems unlikely to me).
Sure, thanks :)
--
viresh
On Thursday, July 21, 2016 01:30:41 PM Viresh Kumar wrote:
> On 21-07-16, 22:31, Rafael J. Wysocki wrote:
> > On Thursday, July 21, 2016 12:59:26 PM Viresh Kumar wrote:
> > > On 13-07-16, 13:25, Steve Muckle wrote:
> > > > Cpufreq governors may need to know what a particular target frequency
> > >
On 21-07-16, 22:31, Rafael J. Wysocki wrote:
> On Thursday, July 21, 2016 12:59:26 PM Viresh Kumar wrote:
> > On 13-07-16, 13:25, Steve Muckle wrote:
> > > Cpufreq governors may need to know what a particular target frequency
> > > maps to in the driver without necessarily wanting to set the freque
On Thursday, July 21, 2016 12:59:26 PM Viresh Kumar wrote:
> On 13-07-16, 13:25, Steve Muckle wrote:
> > Cpufreq governors may need to know what a particular target frequency
> > maps to in the driver without necessarily wanting to set the frequency.
> > Support this operation via a new cpufreq API
On 13-07-16, 13:25, Steve Muckle wrote:
> Cpufreq governors may need to know what a particular target frequency
> maps to in the driver without necessarily wanting to set the frequency.
> Support this operation via a new cpufreq API,
> cpufreq_driver_resolve_freq(). This API returns the lowest driv
Cpufreq governors may need to know what a particular target frequency
maps to in the driver without necessarily wanting to set the frequency.
Support this operation via a new cpufreq API,
cpufreq_driver_resolve_freq(). This API returns the lowest driver
frequency equal or greater than the target fr
18 matches
Mail list logo
