Signed-off-by: Steve Muckle <smuc...@linaro.org>
---
kernel/sched/fair.c | 50 ++
1 file changed, 26 insertions(+), 24 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 46d64e4ccfde..d418deb04049 100644
--- a/kernel/sched/
CPUFREQ_RELATION_L);
> +
> + mutex_unlock(_policy->work_lock);
> + }
Is the expectation that in the fast_switch_enabled case we should
re-evaluate soon enough that an explicit fixup is not required here? I'm
worried as to whether that will always be true given the possible
criticality of applying frequency limits (thermal for example).
thanks,
Steve
policy to switch the frequency for.
> + * @target_freq: New frequency to set (may be approximate).
> + *
> + * Carry out a fast frequency switch from interrupt context.
I think that should say atomic rather than interrupt as this might not
be called from interrupt context.
thanks,
Steve
On 03/17/2016 02:40 AM, Juri Lelli wrote:
>> Could the default schedtune value not serve as the out of the box margin?
>>
> I'm not sure I understand you here. For me schedtune should be disabled
> by default, so I'd say that it doesn't introduce any additional margin
> by default. But we still
() and
detach_entity_load_avg().
Suggested-by: Vincent Guittot <vincent.guit...@linaro.org>
Signed-off-by: Steve Muckle <smuc...@linaro.org>
---
Unfortunately this means that in the migration case,
enqueue_entity_load_avg() will end up calling the cpufreq hook twice -
once via update_cfs
ady busted - enqueue_task_fair() calls
update_load_avg() on the sched entities in the hierarchy which were
already enqueued.
thanks,
Steve
On 03/04/2016 05:30 AM, Rafael J. Wysocki wrote:
> +void cpufreq_update_util(u64 time, unsigned long util, unsigned long max)
> +{
> + struct freq_update_hook *hook;
> +
> +#ifdef CONFIG_LOCKDEP
> + WARN_ON(debug_locks && !rcu_read_lock_sched_held());
> +#endif
> +
> + hook =
e overall solution. But it looks like we will be moving forward using
Rafael's schedutil governor. The most recent posting of that is here:
http://thread.gmane.org/gmane.linux.kernel/2166378
thanks,
Steve
doesn't vary based on a platform's fmin value?
> Moreover, since 0 utilization gets you to run in f_min no matter what,
> if you treat f_max as an absolute, you're going to underutilize the
> P-states in the upper half of the available range.
Sorry I didn't follow. What do you mean by underutilize the upper half
of the range? I don't see how using RELATION_L with (util/max) * fmax *
(headroom) wouldn't be correct in that regard.
thanks,
Steve
On 03/02/2016 07:20 PM, Steve Muckle wrote:
> Why does the frequency value not help? It is true there may be issues of
> a workload being memory bound and not responding quite linearly to
> increasing frequency, but that would pose a problem for the current
> algorithm also. Surely
l here it seems.
The DL idea seems like a good one to me.
It would also prevent cpufreq changes from being delayed by other RT or
DL tasks.
thanks,
Steve
ot currently equipped to gather them. So more analysis is
definitely needed to capture the full story.
thanks,
Steve
ral performance using the
governor. It's called "overhead" I imagine (the metric predates my
involvement) as it is something introduced/caused by the policy of the
governor.
thanks,
Steve
il to register the driver (if the driver has a fast_switch
routine)?
Or alternatively, the fast_switch routine is not installed.
thanks,
Steve
r if it's better to just try the "no notifiers with fast
drivers" approach to start. The notifiers could always be added if
platform owners complain that they absolutely require them.
thanks,
Steve
to if they wish to use
fast transitions with their platform.
thanks,
Steve
On 03/31/2016 05:32 AM, Rafael J. Wysocki wrote:
> On Thu, Mar 31, 2016 at 2:24 PM, Peter Zijlstra <pet...@infradead.org> wrote:
>> On Mon, Mar 28, 2016 at 11:17:44AM -0700, Steve Muckle wrote:
>>> The scenario I'm contemplating is that while a CPU-intensive task is
>>
ke the CPU into account as it probably is
> + * idle now.
> + */
> + delta_ns = last_freq_update_time - j_sg_cpu->last_update;
> + if ((s64)delta_ns > TICK_NSEC)
>> Why not declare delta_ns as an s64 (also in suguv_should_update_freq)
>> and avoid the cast?
>
> I took this from __update_load_avg(), but it shouldn't matter here.
Did you mean to keep these casts?
thanks,
Steve
On 04/01/2016 12:14 PM, Rafael J. Wysocki wrote:
> On Fri, Apr 1, 2016 at 7:49 PM, Steve Muckle <steve.muc...@linaro.org> wrote:
>> On 03/29/2016 07:00 PM, Rafael J. Wysocki wrote:
>> ...
>>> +config CPU_FREQ_GOV_SCHEDUTIL
>>> + tristate "'schedutil
afad
> defconfig-build/kernel/sched/fair.o.patch
> 435951226 24 44845af2d
> defconfig-build/kernel/sched/fair.o.patch+
>
> ---
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
Cool, thanks. Shall I fold this into this patch and resend the series of
3? Or would you prefer to add this change separately?
thanks,
Steve
From: Steve Twiss <stwiss.opensou...@diasemi.com>
The structure da9063_irq_data and define EVENTS_BUF_LEN are not used, so
remove the redundant entries.
Signed-off-by: Steve Twiss <stwiss.opensou...@diasemi.com>
---
This patch applies against linux-next and next-20160405
Re
On Tue, Mar 29, 2016 at 07:51:49PM +0300, Kirill A. Shutemov wrote:
> On Tue, Mar 29, 2016 at 05:39:41PM +0100, Steve Capper wrote:
> > HugeTLB pages cannot be split, thus use the compound_mapcount to
> > track rmaps.
> >
> > Currently the page_mapped function will
On 03/31/2016 12:37 AM, Peter Zijlstra wrote:
> On Wed, Mar 30, 2016 at 06:42:20PM -0700, Steve Muckle wrote:
>> On 03/30/2016 12:35 PM, Peter Zijlstra wrote:
>>> On Mon, Mar 28, 2016 at 12:38:26PM -0700, Steve Muckle wrote:
>>>> Without covering all the paths wher
Hi Dietmar,
On 03/28/2016 05:02 AM, Dietmar Eggemann wrote:
> Hi Steve,
>
> these patches fall into the bucket of 'optimization of updating the
> value only if the root cfs_rq util has changed' as discussed in '[PATCH
> 5/8] sched/cpufreq: pass sched class into cpufreq_update_util
On 03/25/2016 06:46 PM, Rafael J. Wysocki wrote:
>>> @@ -1726,6 +1810,34 @@ EXPORT_SYMBOL(cpufreq_unregister_notifie
>>> >> * GOVERNORS*
>>> >> */
>>> >>
>>> >> +/**
>>>
duce overhead into the fast
> path. So this really is a tradeoff and the current choice is the
> right one IMO.
On the desire to avoid locking in the fast switch/one CPU per policy
case, I wondered about whether disabling interrupts in sugov_limits()
would suffice. That's a rarely called function and I was hoping that the
update hook would already have interrupts disabled due to its being
called in scheduler paths that may do raw_spin_lock_irqsave. But I'm not
sure offhand that will always be true. If it isn't though then I'm not
sure what's necessarily stopping say the sched tick calling the hook
while the hook is already in progress from some other path.
Agreed there would need to be some additional complexity somewhere to
get things running on the correct CPU.
Anyway I have nothing against deferring this for now.
thanks,
Steve
On 04/01/2016 12:49 PM, Peter Zijlstra wrote:
> On Sat, Apr 02, 2016 at 12:38:37AM +0800, Leo Yan wrote:
>> When task is migrated from CPU_A to CPU_B, scheduler will decrease
>> the task's load/util from the task's cfs_rq and also add them into
>> migrated cfs_rq. But if kernel enables
Looks good to me. Thanks!
Hi Andrew,
On Thu, Mar 31, 2016 at 04:06:50PM -0700, Andrew Morton wrote:
> On Tue, 29 Mar 2016 17:39:41 +0100 Steve Capper <steve.cap...@arm.com> wrote:
>
> > HugeTLB pages cannot be split, thus use the compound_mapcount to
> > track rmaps.
> >
> > Currently
Feature or bug?
Using shell echo to write to /sys files normally adds an implicit
newline but
write() in a C program must add it explicitly. Some but not all /sys files
require a newline or the write fails. 'Extra' new lines from echo are
silently ignored and do not cause errors.
For example:
t when a uevent gets dropped? I may
have to panic the machine if that happens depending on the configured policy.
So, we need to know when it happens. If on the otherhand it doesn't ever drop
events, then it might be usable.
-Steve
ou can replace
spaces with an underscore or dash for readability. So, manufacturer and
product would need this treatment.
-Steve
> Admittedly this is only the USB device type at the moment, but I'd like to
> break this out into other bus types at some time in the future, gotta start
> somewhere.
On Wed, Apr 13, 2016 at 03:09:08PM +0100, Steve Capper wrote:
> On Tue, Mar 08, 2016 at 11:59:46PM +, David Daney wrote:
> > From: Ganapatrao Kulkarni <gkulka...@caviumnetworks.com>
> >
> > Attempt to get the memory and CPU NUMA node via of_numa. If that
> &
gt; Tested-by: Shannon Zhao <shannon.z...@linaro.org>
> Reviewed-by: Robert Richter <rrich...@cavium.com>
> Signed-off-by: Ganapatrao Kulkarni <gkulka...@caviumnetworks.com>
> Signed-off-by: David Daney <david.da...@cavium.com>
Hi David,
I have one minor commen
}
> +
> +static inline int pmd_protnone(pmd_t pmd)
> +{
> + return pte_protnone(pmd_pte(pmd));
> +}
> +#endif
> +
Okay, this looks good to me. If we have a PROT_NONE VMA then this is
caught before going into do_numa_page or do_huge_pmd_numa_page (and
there is a BUG_ON insi
From: Steve Twiss <stwiss.opensou...@diasemi.com>
This fix alters the ordering of the IRQ and device registrations in the RTC
driver probe function. This change will apply to the RTC driver that supports
both DA9052 and DA9053 PMICs.
A problem could occur with the existing RTC
LONG_MAX);
> +
Does this change need to be applied to any other architectures given
that deletion code has been removed from libstub below?
Cheers,
--
Steve
> for_each_efi_memory_desc(, md) {
> paddr = md->phys_addr;
> npages = md->num_pages;
&
On Thu, Apr 14, 2016 at 01:10:35PM +0200, Ard Biesheuvel wrote:
> On 14 April 2016 at 13:02, Steve Capper <steve.cap...@arm.com> wrote:
> > On Fri, Apr 08, 2016 at 03:50:23PM -0700, David Daney wrote:
> >> From: Ard Biesheuvel <ard.biesheu...@linaro.org>
&g
o CPU A in that case looks like the right
> thing to do to me anyway.
Sorry I didn't follow - sending an IPI to do what exactly? Perform the
wakeup operation on the target CPU?
thanks,
Steve
frequency for you, that will defeat the whole purpose
>> here.
I was hoping to submit at some point a patch to change the context for
slow path frequency changes to RT or DL context, so this would benefit
that case as well.
thanks,
steve
ct update_util_data and set
> it from cpufreq_add_update_util_hook()?
>
> That would allow you to avoid adding the cpu field to struct sugov_cpu in the
> second patch at least.
Sure, will do.
thanks,
Steve
t; ab = audit_log_start(NULL, GFP_KERNEL, AUDIT_LOGIN);
> > if (!ab)
> >
> > return;
> >
> > audit_log_format(ab, "pid=%d uid=%u", task_pid_nr(current), uid);
> > audit_log_task_context(ab);
> >
>
Reviewed-by: Steve French <steve.fre...@primarydata.com>
Let me know if you want any of them to go in via the cifs tree or
prefer going in through your tree (other than patch 1 which could go
in the net-next tree are you indicated)
On Sat, Apr 9, 2016 at 3:43 PM, Al Viro <v...@zeniv.lin
Reviewed-by: Steve French <steve.fre...@primarydata.com>
On Sun, Apr 24, 2016 at 7:24 PM, Eric Engestrom <e...@engestrom.ch> wrote:
> Signed-off-by: Eric Engestrom <e...@engestrom.ch>
> ---
> Documentation/filesystems/autofs4.txt | 6 +++---
> Documentatio
orthogonal.
Also if it helps, I can provide a test case and/or traces to show the
need for the last two patches.
thanks,
Steve
nd tuning if the tracing was consistent.
>
> Well, fair enough.
>
> > This behavioral change is admittedly not part of the purpose of the
> > patch and could be split out if needbe.
>
> No need to split IMO, but it might be prudent to mention that change
> in behavior in the changelog.
Will do.
thanks,
Steve
n deferred and preemption has not occurred.
> >
> > This means two hook inovcations for a remote non-preempting wakeup
> > though instead of one. Perhaps this is a good middle ground on code
> > churn vs. optimization though.
>
> I would think so.
Ok, I will pursue this approach.
thanks,
Steve
org.au> wrote:
> Hi Steve,
>
> On Thu, 19 May 2016 14:01:20 +1000 Stephen Rothwell <s...@canb.auug.org.au>
> wrote:
>>
>> After merging the security tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> fs/cifs/cifs_spnego.c:
On Fri, May 20, 2016 at 02:24:19AM +0200, Rafael J. Wysocki wrote:
> On Fri, May 20, 2016 at 1:34 AM, Steve Muckle <steve.muc...@linaro.org> wrote:
> > On Thu, May 19, 2016 at 11:15:52PM +0200, Rafael J. Wysocki wrote:
> >> But anyway this change again seems to be an
On Fri, May 20, 2016 at 02:37:17AM +0200, Rafael J. Wysocki wrote:
> Also I think that it would be good to avoid walking the frequency
> table twice in case we end up wanting to update the frequency after
> all. With the [4/5] we'd do it once in get_next_freq() and then once
> more in
>
> Fixes: b955150ea784 ('RDMA/cxgb3: When a user QP is marked in error, also mark
> the CQs in error')
> Signed-off-by: Honggang Li <ho...@redhat.com>
Nice catch. Your fix looks correct.
Reviewed-by: Steve Wise <sw...@opengridcomputing.com>
= cifs_listxattr,
> - .removexattr = cifs_removexattr,
> -#endif
> + .removexattr = generic_removexattr,
> };
>
> static int cifs_clone_file_range(struct file *src_file, loff_t off,
--
Thanks,
Steve
On Sun, May 22, 2016 at 12:39:12PM +0200, Peter Zijlstra wrote:
> On Fri, May 20, 2016 at 05:53:41PM +0530, Shilpasri G Bhat wrote:
> >
> > Below are the comparisons by disabling watchdog.
> > Both schedutil and ondemand have a similar ramp-down trend. And in both the
> > cases I can see that
From: Steve Twiss <stwiss.opensou...@diasemi.com>
Dialog Semiconductor support would like to follow files by adding to the
existing MAINTAINERS search terms. The update will allow us to follow
files for PMIC documentation bindings and header files.
The full list is:
DT bindings
- Documen
Hi Peter, Ingo,
On Thu, May 19, 2016 at 04:04:19PM -0700, Steve Muckle wrote:
> On Thu, May 19, 2016 at 11:06:14PM +0200, Rafael J. Wysocki wrote:
> > > In the case of a remote update the hook has to run (or not) after it is
> > > known whether preemption will occur so we d
On Thu, May 19, 2016 at 01:24:41AM +0200, Rafael J. Wysocki wrote:
> On Mon, May 9, 2016 at 11:20 PM, Steve Muckle <steve.muc...@linaro.org> wrote:
> > In preparation for the scheduler cpufreq callback happening on remote
> > CPUs, add support for this in schedutil.
> &
On Thu, May 19, 2016 at 01:44:36AM +0200, Rafael J. Wysocki wrote:
> On Mon, May 9, 2016 at 11:20 PM, Steve Muckle <steve.muc...@linaro.org> wrote:
> > The rate limit timestamp (last_freq_update_time) is currently advanced
> > anytime schedutil re-evaluates the policy regardle
On Thu, May 19, 2016 at 02:00:54PM +0200, Rafael J. Wysocki wrote:
> On Thu, May 19, 2016 at 1:33 AM, Rafael J. Wysocki <raf...@kernel.org> wrote:
> > On Mon, May 9, 2016 at 11:20 PM, Steve Muckle <steve.muc...@linaro.org>
> > wrote:
> >> Without calling
On Thu, May 19, 2016 at 01:37:40AM +0200, Rafael J. Wysocki wrote:
> On Mon, May 9, 2016 at 11:20 PM, Steve Muckle <steve.muc...@linaro.org> wrote:
> > The mechanisms for remote CPU updates and slow-path frequency
> > transitions are relatively expensive - the former is an IPI
From: Steve Twiss <stwiss.opensou...@diasemi.com>
Dialog Semiconductor support would like to follow files by adding to the
existing MAINTAINERS search terms. The update will allow us to follow
files for PMIC documentation bindings and header files.
The full list is:
DT bindings
- Documen
Looks good to me.
Also re-tested with intel_pstate on i7-3630QM !SMP, confirmed issue
is resolved. I didn't retest with ondemand because for some reason
that wasn't showing the problem before.
On Fri, Apr 29, 2016 at 01:21:24PM +0200, Rafael J. Wysocki wrote:
> On Friday, April 29, 2016 04:08:16 PM Viresh Kumar wrote:
...
> > Any clue, why we don't have a non-SMP version of irq_work_queue_on(), Which
> > can
> > simply call irq_work_queue() ?
>
> Because nobody else needs it?
>
> But
While working on a few patches for schedutil I noticed that the CFS
cpufreq hooks depend on PELT, which depends on CONFIG_SMP.
I compiled and ran a UP kernel with intel_pstate. Running a cpu-bound
task did not result in the frequency increasing beyond fmin. For some reason
ondemand is working for
On Fri, May 06, 2016 at 02:09:07AM +0200, Rafael J. Wysocki wrote:
> In turn, schedutil should probably depend on CONFIG_SMP.
In the long term I wonder if it's worth putting PELT under its own
separate feature or just removing #ifdef CONFIG_SMP.
Aside from task migration CPU frequency updates
On Thu, May 5, 2016 at 5:54 PM, Steve French <smfre...@gmail.com> wrote:
> On Wed, May 4, 2016 at 8:46 AM, Arnd Bergmann <a...@arndb.de> wrote:
>> On Friday 29 April 2016 13:57:36 David Howells wrote:
>>> struct statx *buffer);
>>>
>>> This is an en
frequency required by the new utilization
value in schedutil. If it is the same as the previously requested
frequency then there is no need to continue with the update.
Signed-off-by: Steve Muckle <smuc...@linaro.org>
---
kernel/sched/cpufreq_schedutil.c | 14 +-
1 file chang
as the new policy_cpus
parameter to cpufreq_add_update_util_hook(). Callbacks will only be
issued in this case when the target CPU and the current CPU are the
same. Otherwise policy_cpus is used to determine what is a local
vs. remote callback.
Signed-off-by: Steve Muckle <smuc...@linaro.org>
---
d
out on the local CPU.
Signed-off-by: Steve Muckle <smuc...@linaro.org>
---
kernel/sched/cpufreq_schedutil.c | 86 ++--
1 file changed, 65 insertions(+), 21 deletions(-)
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
elapsed ( +- 0.14% )
Steve Muckle (5):
sched: cpufreq: add cpu to update_util_data
cpufreq: schedutil: support scheduler cpufreq callbacks on remote CPUs
sched: cpufreq: call cpufreq hook from remote CPUs
cpufreq: schedutil: map raw required frequency to CPU-supported
frequency
cpufreq
Upcoming support for scheduler cpufreq callbacks on remote wakeups
will require the client to know what the target CPU is that the
callback is being invoked for. Add this information into the callback
data structure.
Signed-off-by: Steve Muckle <smuc...@linaro.org>
---
include/linux/sched.
of the policy frequency.
Signed-off-by: Steve Muckle <smuc...@linaro.org>
---
kernel/sched/cpufreq_schedutil.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index e185075fcb5c..4d2907c8a142 100644
--- a/kernel
>
> > > Fix the problem by making the !CONFIG_SMP stub of update_load_avg()
> > > invoke cpufreq update hooks too.
> > >
> > > Fixes: 34e2c555f3e1 (cpufreq: Add mechanism for registering utilization
> > > update callbacks)
> > > Reported-by: Steve Muckl
In preparation for the scheduler cpufreq callback happening on remote
CPUs, add support for this in intel_pstate, which requires the
callback run on the local CPU to be able to change the CPU frequency.
Signed-off-by: Steve Muckle <smuc...@linaro.org>
---
drivers/cpufreq/intel_pstate.
In preparation for the scheduler cpufreq callback happening on remote
CPUs, add support for this in schedutil. Schedutil requires the
callback occur on the CPU being updated in order to support fast
frequency switches.
Signed-off-by: Steve Muckle <smuc...@linaro.org>
---
kernel
In preparation for the scheduler cpufreq callback happening
on remote CPUs, add support for this in the dbs governors.
The dbs governors make assumptions about the callback occurring
on the CPU being updated.
Signed-off-by: Steve Muckle <smuc...@linaro.org>
---
drivers/cpufreq/cpufreq_gove
Without calling the cpufreq hook for a remote wakeup it is possible
for such a wakeup to go unnoticed by cpufreq on the target CPU for up
to a full tick. This can occur if the target CPU is running a
CPU-bound task.
Signed-off-by: Steve Muckle <smuc...@linaro.org>
---
kernel/sched/fair.c
On Wed, Apr 13, 2016 at 09:50:19PM +0200, Rafael J. Wysocki wrote:
> On Wed, Apr 13, 2016 at 8:06 PM, Steve Muckle <steve.muc...@linaro.org> wrote:
> > On 04/13/2016 09:07 AM, Rafael J. Wysocki wrote:
> >>>>>> If you want to do remote updates, I guess that will
_update_util(struct update_util_data *data, u64
> > time,
> > +unsigned long util, unsigned long max)
> > +{
> > + struct cpudata *cpu = container_of(data, struct cpudata, update_util);
> > + s64 delta_ns = time - cpu->sample.time;
> > +
> > + if (delta_ns < pid_params.sample_rate_ns)
> > + return;
> > +
> > + _intel_pstate_update_util(cpu, time);
> > +}
> > +#endif
> > +
> > +
> > +
>
> The additional two empty lines are not necessary.
>
Sorry yeah these were unintentional, will remove these and the ones below.
Thanks for the review.
thanks,
Steve
On 07/25/2016 12:36 PM, Ian Arkver wrote:
On 25/07/16 18:55, Steve Longerbeam wrote:
On 07/25/2016 05:04 AM, Ian Arkver wrote:
On 23/07/16 18:00, Steve Longerbeam wrote:
+#define ADV7180_VSYNC_FIELD_CTL_1_NEWAVMODE 0x02
See below re this value.
Hi Ian, I double-checked the ADV7180
On 07/25/2016 03:24 PM, Ian Arkver wrote:
> On 25/07/16 23:04, Steve Longerbeam wrote:
>>
>>
>> On 07/25/2016 12:36 PM, Ian Arkver wrote:
>>> On 25/07/16 18:55, Steve Longerbeam wrote:
>>>> On 07/25/2016 05:04 AM, Ian Arkver wrote:
>&
From: Steve Twiss <stwiss.opensou...@diasemi.com>
Addition of device tree support for DA9210.
Two files are modified, the driver source file and the binding document.
Updates for the regulator source file include an .of_match_table entry, node
match checking in the probe() fu
/makedumpfile/code.
I'm surprised others aren't seeing this? All 6 of my development systems stop
being able to get vmcore dumps with 4.7-rc...
Steve.
On 22 July 2016 11:36, Steve Twiss wrote:
> The binding file for DA9052/53 exists in the kernel and was originally
> submitted by Ying-Chun Liu from Linaro way back in 2012.
[...]
> > git show 58d114b
[...]
> regulator names are added to the binding document but not used in the
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
From: Steve Twiss <stwiss.opensou...@diasemi.com>
Hi Mark,
Buck and LDO binding name changes.
The binding names for the regulators have been changed to match the current
expectation from existing device tree source files.
This fix rectifies the disparity between what currently exists i
On 07/25/2016 05:04 AM, Ian Arkver wrote:
> On 23/07/16 18:00, Steve Longerbeam wrote:
>> Parse the optional v4l2 endpoint DT node. If the bus type is
>> V4L2_MBUS_BT656 and the endpoint node specifies "newavmode",
>> configure the BT.656 bus in NEWAVMODE.
>&g
From: Steve Twiss <stwiss.opensou...@diasemi.com>
Buck and LDO binding name changes.
The binding names for the regulators have been changed to match the current
expectation from existing device tree source files.
This fix rectifies the disparity between what currently exists in some
On 27 July 2016 19:24, Mark Brown wrote:
> On Mon, Jul 25, 2016 at 11:31:27AM +0000, Steve Twiss wrote:
>
> > There are already several device tree files using a naming scheme different
> > to that found
> > in the binding text document. Since those have been used
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 =
On Fri, Jul 22, 2016 at 01:22:22AM +0200, Rafael J. Wysocki wrote:
> OK, applied.
FWIW I do have a concern on this patch, I think it adds unnecessary
overhead.
On Fri, Jul 22, 2016 at 01:53:13AM +0200, Rafael J. Wysocki wrote:
> On Fri, Jul 22, 2016 at 1:45 AM, Steve Muckle <steve.muc...@linaro.org> wrote:
> > On Fri, Jul 22, 2016 at 01:32:00AM +0200, Rafael J. Wysocki wrote:
> >> On Fri, Jul 22, 2016 at 1:22 AM, Steve Muckle
On Fri, Jul 22, 2016 at 01:32:00AM +0200, Rafael J. Wysocki wrote:
> On Fri, Jul 22, 2016 at 1:22 AM, Steve Muckle <steve.muc...@linaro.org> wrote:
> > On Fri, Jul 22, 2016 at 01:22:22AM +0200, Rafael J. Wysocki wrote:
> >> OK, applied.
> >
> > FWIW I do h
On Fri, Jul 22, 2016 at 02:18:54AM +0200, Rafael J. Wysocki wrote:
> > My thinking was that one of these two would be preferable:
> >
> > - Forcing ->target() drivers to install a ->resolve_freq callback,
> > enforcing this at cpufreq driver init time.
>
> That would have been possible, but
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()
Export cpufreq_driver_resolve_freq() since governors may be compiled as
modules.
Reported-by: Stephen Rothwell <s...@canb.auug.org.au>
Signed-off-by: Steve Muckle <smuc...@linaro.org>
---
drivers/cpufreq/cpufreq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq
ndefined!
>
> Caused by commit
>
> 5cbea46984d6 ("cpufreq: schedutil: map raw required frequency to driver
> frequency")
>
> I used the pm tree from next-20160721 for today.
Sorry - I have just sent a patch to address this.
thanks,
Steve
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 c
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 in
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
I've also found that the seams are quite noticeable when rendered to a
display overlay, but become significantly less pronounced if the images are
converted to a back buffer, and then page-flipped to front buffer when the
conversion (all tiles) completes.
Steve
I wonder how much effort it would be to remove
301 - 400 of 5727 matches
Mail list logo
