On 17 July 2013 20:29, Lukasz Majewski wrote:
> To be 100% sure - we export boost only when supported (as proposed at v5).
Yes.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kern
On Wed, 17 Jul 2013 18:31:19 +0530 Viresh Kumar viresh.ku...@linaro.org
wrote,
> On 17 July 2013 17:01, Rafael J. Wysocki wrote:
> > First off, I'm not sure how many applications actually use it and I
> > think, if any, they should be able cope with the attribute not
> > being present.
> >
> > Of
On 17 July 2013 17:01, Rafael J. Wysocki wrote:
> First off, I'm not sure how many applications actually use it and I think,
> if any, they should be able cope with the attribute not being present.
>
> Of course, if it turns out that yes, there are applications using it and no,
> they cannot cope
On Wednesday, July 17, 2013 01:28:29 PM Viresh Kumar wrote:
> On 20 June 2013 03:55, Rafael J. Wysocki wrote:
> > On Wednesday, June 19, 2013 10:31:02 PM Lukasz Majewski wrote:
> >> On Wed, 19 Jun 2013 10:48:53 -0700
> >> Dirk Brandewie wrote:
> >>
> >> > On 06/19/2013 10:12 AM, Lukasz Majewski w
On 20 June 2013 03:55, Rafael J. Wysocki wrote:
> On Wednesday, June 19, 2013 10:31:02 PM Lukasz Majewski wrote:
>> On Wed, 19 Jun 2013 10:48:53 -0700
>> Dirk Brandewie wrote:
>>
>> > On 06/19/2013 10:12 AM, Lukasz Majewski wrote:
>> > > @@ -1936,6 +2019,16 @@ int cpufreq_register_driver(struct
On Fri, 28 Jun 2013 12:21:21 +0530, Viresh Kumar wrote:
> On 28 June 2013 12:19, Lukasz Majewski wrote:
> > No, I will use:
> >
> > if (boost_enabled != state) {
> > write_lock_irqsave(&cpufreq_driver_lock, flags);
> > boost_enabled = state;
> >
> > ret = cpufreq_driver->e
On 28 June 2013 12:19, Lukasz Majewski wrote:
> No, I will use:
>
> if (boost_enabled != state) {
> write_lock_irqsave(&cpufreq_driver_lock, flags);
> boost_enabled = state;
>
> ret = cpufreq_driver->enable_boost(state);
> only one callback call
On Fri, 28 Jun 2013 09:10:53 +0530, Viresh Kumar wrote:
> On 27 June 2013 21:25, Lukasz Majewski wrote:
> > On Wed, 26 Jun 2013 16:24:32 +0530, Viresh Kumar wrote:
> >> > + if (boost_enabled != state) {
> >> > + write_lock_irqsave(&cpufreq_driver_lock, flags);
> >> > +
On 27 June 2013 21:25, Lukasz Majewski wrote:
> On Wed, 26 Jun 2013 16:24:32 +0530, Viresh Kumar wrote:
>> > + if (boost_enabled != state) {
>> > + write_lock_irqsave(&cpufreq_driver_lock, flags);
>> > + boost_enabled = state;
>> > + if (cpufreq_driv
On Wed, 26 Jun 2013 16:24:32 +0530, Viresh Kumar wrote:
> > +int cpufreq_boost_trigger_state(int state)
> > +{
> > + unsigned long flags;
> > + int ret = 0;
> > +
> > + if (boost_enabled != state) {
> > + write_lock_irqsave(&cpufreq_driver_lock, flags);
> > +
On Thu, 27 Jun 2013 15:55:26 +0530, Viresh Kumar wrote:
> On 27 June 2013 15:18, Lukasz Majewski wrote:
> > On Thu, 27 Jun 2013 14:32:57 +0530, Viresh Kumar wrote:
>
> > I thought about this idea, but at cpufreq_boost_trigger_state_sw()
> > I iterate through all available policies and call
> > cp
On 27 June 2013 15:18, Lukasz Majewski wrote:
> On Thu, 27 Jun 2013 14:32:57 +0530, Viresh Kumar wrote:
> I thought about this idea, but at cpufreq_boost_trigger_state_sw()
> I iterate through all available policies and call
> cpufreq_frequency_table_cpuinfo()[*] on them. In this routine [*] I us
On Thu, 27 Jun 2013 14:32:57 +0530, Viresh Kumar wrote:
> On 26 June 2013 18:24, Lukasz Majewski wrote:
> > On Wed, 26 Jun 2013 16:24:32 +0530, Viresh Kumar wrote:
> >> On 19 June 2013 22:42, Lukasz Majewski
> >> wrote:
>
> >> > +static ssize_t store_boost(struct kobject *kobj, struct
> >> > att
On 26 June 2013 18:24, Lukasz Majewski wrote:
> On Wed, 26 Jun 2013 16:24:32 +0530, Viresh Kumar wrote:
>> On 19 June 2013 22:42, Lukasz Majewski wrote:
>> > +static ssize_t store_boost(struct kobject *kobj, struct attribute
>> > *attr,
>> > + const char *buf, siz
On Wed, 26 Jun 2013 14:54:12 +0200, Lukasz Majewski wrote:
> > >
> > > +int cpufreq_boost_trigger_state(int state);
> >
> > Why is this present here?
>
> We had agreed to talk only about cpufreq :-).
>
> This declaration will be removed.
Correction:
This declaration is needed for allowing
On Wed, 26 Jun 2013 16:24:32 +0530, Viresh Kumar wrote:
> On 19 June 2013 22:42, Lukasz Majewski wrote:
> > Boost sysfs attribute is always exported (to support legacy API). By
> > default boost is exported as read only. One global attribute is
> > available at: /sys/devices/system/cpu/cpufreq/boo
On 19 June 2013 22:42, Lukasz Majewski wrote:
> Boost sysfs attribute is always exported (to support legacy API). By
> default boost is exported as read only. One global attribute is available at:
> /sys/devices/system/cpu/cpufreq/boost.
I assume you are going to fix this as discussed in other th
On Thu, 20 Jun 2013 22:03:45 +0200, Rafael J. Wysocki wrote:
Hi Rafael,
> On Thursday, June 20, 2013 10:43:08 AM Viresh Kumar wrote:
> > On 19 June 2013 22:42, Lukasz Majewski
> > wrote:
> >
> > > Boost sysfs attribute is always exported (to support legacy API).
> > > By default boost is export
On Thursday, June 20, 2013 10:43:08 AM Viresh Kumar wrote:
> On 19 June 2013 22:42, Lukasz Majewski wrote:
>
> > Boost sysfs attribute is always exported (to support legacy API). By
> > default boost is exported as read only. One global attribute is available
> > at:
> > /sys/devices/system/cpu/
On 19 June 2013 22:42, Lukasz Majewski wrote:
> Boost sysfs attribute is always exported (to support legacy API). By
> default boost is exported as read only. One global attribute is available at:
> /sys/devices/system/cpu/cpufreq/boost.
You asked me and Rafael a question and posted your next ve
On Wednesday, June 19, 2013 10:31:02 PM Lukasz Majewski wrote:
> On Wed, 19 Jun 2013 10:48:53 -0700
> Dirk Brandewie wrote:
>
> > On 06/19/2013 10:12 AM, Lukasz Majewski wrote:
> > > This commit adds boost frequency support in cpufreq core (Hardware &
> >
> > > +/
On Wed, 19 Jun 2013 10:48:53 -0700
Dirk Brandewie wrote:
> On 06/19/2013 10:12 AM, Lukasz Majewski wrote:
> > This commit adds boost frequency support in cpufreq core (Hardware &
>
> > +/*
> >* REGISTER / UNREG
On 06/19/2013 10:12 AM, Lukasz Majewski wrote:
This commit adds boost frequency support in cpufreq core (Hardware &
+/*
* REGISTER / UNREGISTER CPUFREQ DRIVER*
**
This commit adds boost frequency support in cpufreq core (Hardware &
Software).
Some SoC (like Exynos4 - e.g. 4x12) allow setting frequency above
its normal operation limits. Such a mode shall be only used for a short
time.
Overclocking (boost) support is essentially provided by platform
dependent
24 matches
Mail list logo
