The tgids are tracked along side the saved_cmdlines tracking, and can be
included in trace output by enabling the 'print-tgid' trace option. This is
useful when doing post-processing of the trace data, as it allows events to be
grouped by tgid.
Change-Id: I52ed04c3a8ca7fddbb868b792ce5d21ceb76250e
Signed-off-by: Jamie Gennis <jgennis@google.com>
Using fence->status to determine whether or not there are callbacks
remaining on the sync_fence is racy since fence->status may have been
decremented to 0 on another CPU before fence_check_cb_func() has
completed. By unconditionally calling fence_remove_callback() for each
fence in the sync_fence, we guarantee that each callback has either
completed (since fence_remove_callback() grabs the fence lock) or been
removed.
BUG=chrome-os-partner:46382
TEST=Reboot cycle test on Smaug; no crashes seen.
Change-Id: I837180ef633aed3c5ae1e52e0d6ded838342b8fa
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/305331
Reviewed-by: Puneet Kumar <puneetster@chromium.org>
Userspace can close the sync device while there are still active fence
points, in which case kernel produces the following warning:
[ 43.853176] ------------[ cut here ]------------
[ 43.857834] WARNING: CPU: 0 PID: 892 at /mnt/host/source/src/third_party/kernel/v3.18/drivers/staging/android/sync.c:439 android_fence_release+0x88/0x104()
[ 43.871741] CPU: 0 PID: 892 Comm: Binder_5 Tainted: G U 3.18.0-07661-g0550ce9 #1
[ 43.880176] Hardware name: Google Tegra210 Smaug Rev 1+ (DT)
[ 43.885834] Call trace:
[ 43.888294] [<ffffffc000207464>] dump_backtrace+0x0/0x10c
[ 43.893697] [<ffffffc000207580>] show_stack+0x10/0x1c
[ 43.898756] [<ffffffc000ab1258>] dump_stack+0x74/0xb8
[ 43.903814] [<ffffffc00021d414>] warn_slowpath_common+0x84/0xb0
[ 43.909736] [<ffffffc00021d530>] warn_slowpath_null+0x14/0x20
[ 43.915482] [<ffffffc00088aefc>] android_fence_release+0x84/0x104
[ 43.921582] [<ffffffc000671cc4>] fence_release+0x104/0x134
[ 43.927066] [<ffffffc00088b0cc>] sync_fence_free+0x74/0x9c
[ 43.932552] [<ffffffc00088b128>] sync_fence_release+0x34/0x48
[ 43.938304] [<ffffffc000317bbc>] __fput+0x100/0x1b8
[ 43.943185] [<ffffffc000317cc8>] ____fput+0x8/0x14
[ 43.947982] [<ffffffc000237f38>] task_work_run+0xb0/0xe4
[ 43.953297] [<ffffffc000207074>] do_notify_resume+0x44/0x5c
[ 43.958867] ---[ end trace 5a2aa4027cc5d171 ]---
Let's fix it by introducing a new optional callback (disable_signaling)
to fence operations so that drivers can do proper clean ups when we
remove last callback for given fence.
BUG=chrome-os-partner:40303
TEST=Boot Smaug and observe that warning is gone.
Change-Id: I05c34dcf74438c28405438c7ead0706b1f810fff
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/303409
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Couple of ADF build fixes for v4.1
adf/adf_fops.c fix:
get_unused_fd() is obsolete, use get_unused_fd_flags(O_CLOEXEC)
instead to allocate a default file descriptor. This fix is a
followup of upstream commit f938612dd9 "include/linux/file.h:
remove get_unused_fd() macro".
adf/adf_memblock.c fix:
Fix dma_buf_export() call. Based on mainline commit d8fbe341be
"dma-buf: cleanup dma_buf_export() to make it easily extensible".
Otherwise we run into following build failures:
----------
CC drivers/video/adf/adf_fops.o
CC drivers/video/adf/adf_memblock.o
drivers/video/adf/adf_memblock.c: In function ‘adf_memblock_export’:
drivers/video/adf/adf_memblock.c:154:2: warning: passing argument 1 of ‘dma_buf_export’ from incompatible pointer type [enabled by default]
In file included from drivers/video/adf/adf_memblock.c:15:0:
include/linux/dma-buf.h:211:17: note: expected ‘const struct dma_buf_export_info *’ but argument is of type ‘struct adf_memblock_pdata *’
drivers/video/adf/adf_memblock.c:154:2: error: too many arguments to function ‘dma_buf_export’
In file included from drivers/video/adf/adf_memblock.c:15:0:
include/linux/dma-buf.h:211:17: note: declared here
make[3]: *** [drivers/video/adf/adf_memblock.o] Error 1
make[3]: *** Waiting for unfinished jobs....
drivers/video/adf/adf_fops.c: In function ‘adf_device_post_config’:
drivers/video/adf/adf_fops.c:228:2: error: implicit declaration of function ‘get_unused_fd’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[3]: *** [drivers/video/adf/adf_fops.o] Error 1
make[2]: *** [drivers/video/adf] Error 2
make[2]: *** Waiting for unfinished jobs....
----------
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Pass 'NULL' as the 5th argument to dma_buf_export() to fix
the following build failure:
----------
CC drivers/video/adf/adf_memblock.o
drivers/video/adf/adf_memblock.c: In function ‘adf_memblock_export’:
drivers/video/adf/adf_memblock.c:154:60: error: macro "dma_buf_export" requires 5 arguments, but only 4 given
drivers/video/adf/adf_memblock.c:154:8: error: ‘dma_buf_export’ undeclared (first use in this function)
drivers/video/adf/adf_memblock.c:154:8: note: each undeclared identifier is reported only once for each function it appears in
make[3]: *** [drivers/video/adf/adf_memblock.o] Error 1
make[2]: *** [drivers/video/adf] Error 2
----------
5th argument to dma_buf_export() is a pointer to 'reservation-object'
and a new 'reservation-object' is allocated in case 'NULL' is passed.
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
If a sw_sync timeline was created by ADF (for drivers that do not implement
ops->complete_fence) we should clean it up when the ADF device is
destroyed.
Change-Id: Idd90180fcae56a87111f7d12bdd80190756a6b80
Signed-off-by: Jonathan Hamilton <jonathan.hamilton@imgtec.com>
Not calling rb_erase() can cause slab corruption, as the rb_first() call
after kfree() in adf_obj_destroy() can return the same node twice unless
it is erased.
This problem was reproduced by unloading a kernel module that used the
adf framework *after* a vsync event was registered. A crash would occur
in rb_first(). (Just loading and immediately unloading the module without
the vsync event worked correctly.)
Change-Id: I9fa7cb5d7519691e38a281439844aa193da13d1b
Signed-off-by: Alistair Strachan <alistair.strachan@imgtec.com>
Cc: Jonathan Hamilton <jonathan.hamilton@imgtec.com>
Cc: Greg Hackmann <ghackmann@google.com>
Quirks specify common behaviors that vary slightly among devices, and
which ADF must account for.
The buffer padding quirk captures the way different devices fetch the
last scanline in a buffer: some devices fetch an entire line (including
padding to the pitch) while others only fetch up to the visible width.
ADF's buffer size validation now takes this quirk into account.
Change-Id: I828b13316e27621d8a9efd9d5fffa6ce12a525ff
Signed-off-by: Greg Hackmann <ghackmann@google.com>
64-bit types in structs create alignment problems when a 32-bit x86
userspace talks to an x86_64 kernel. In most cases the 64-bit types can
be replaced with 32-bit ones, since they're being used for fds and
should have been __s32 in the first place. For adf_vsync_event,
alignment can be enforced by making the timestamp an __aligned_u64.
Change-Id: I87cf73d8f57730bd7bb43ffce6b7b411eb0ff198
Signed-off-by: Greg Hackmann <ghackmann@google.com>
A device's fb_info is shared between clients. fb_release() is called
when each client is released, not just the last one. Since the fbdev
helper needs to release its dma-buf when the last client goes away, it
must keep its own reference count.
fbmem and fbcon hold different locks while calling fb_release(), so
explicit locking is needed.
Change-Id: I42cd659f7633adba7c11f407d4b594bd43305d6a
Signed-off-by: Greg Hackmann <ghackmann@google.com>
There are no in-tree users of adf_attachment_allow, but out-of-tree
modules want to use it. It looks like this function should be
EXPORT_SYMBOL.
Change-Id: Iad522dc5d32ac09fec6483bbc317db8ecae12e97
Signed-off-by: Alistair Strachan <alistair.strachan@imgtec.com>
Device-custom ADF ioctls can use type ADF_IOCTL_TYPE and
nr >= ADF_IOCTL_NR_CUSTOM
Change-Id: Ia8270973df5100e996ca0e021ede60e54b9af72a
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Userspace-facing ADF_MAX_ATTACHMENTS must be in terms of
userspace-facing struct adf_attachment_config
Change-Id: Iaaddcd6366f13b3e52eb3911efcfff8a61e0b225
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Systems may define PAGE_SIZE in userspace limits.h but don't have to.
PAGE_SIZE was picked as an arbitrary "reasonable" limit so just use 4096
instead.
Change-Id: I9555e39aba64a3a70f61eb6ded2a4129ab236ce0
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Interfaces default to unplugged, so they should also default to off
Change-Id: I36500a54b11f354a0d7dd2c9924a79e0d9c6f855
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Many custom formats look a lot like the standard ones, but with
different subsampling, bpp, etc. Expose and document
adf_buffer_validate()'s main body, so drivers can reuse its logic when
validating these formats.
Change-Id: I1d06981c9e5aab26f3ab2956c08c679f2c823bcc
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Informational flags don't affect ADF directly but may be useful to
clients. Currently used to indicate primary and external displays.
Change-Id: I343c7f0148da0869244c8e818350e9855525df85
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Simple buffers are linear RGB buffers analogous to KMS's dumb buffers.
Simple buffers can be allocated and posted to a display interface
without any driver-private data.
Internally, ADF drivers provide the driver-private data needed (if any)
to post a simple buffer to the display.
Change-Id: Ib0b737622eaf343111310f6623f99d69cf3807d2
Signed-off-by: Greg Hackmann <ghackmann@google.com>
Provides a dma-buf exporter for memblocks, mainly useful for ADF devices
to wrap their bootloader logos
Change-Id: I936a9b5df099ab6084d433fcaf50f3bc29f93289
Signed-off-by: Greg Hackmann <ghackmann@google.com>
In timer, cpu_load is calcuated on target_freq.
cpu_load = loadadjfreq / pcpu->target_freq;
But cpu is actually running on current freq i.e. pcpu->policy->cur. So cpu_load
should be calculated on current frequency.
cpu_load = loadadjfreq / pcpu->policy->cur;
Change-Id: I89db6b68e9f82aa52077f6bf7d819dab74265790
Signed-off-by: rahul.khandelwal <rahul.khandelwal@spreadtrum.com>
Bring back cpufreq_{get,put}_global_kobject() definitions
removed by upstream commit 8eec1020f0 "cpufreq: create
cpu/cpufreq at boot time" to fix build failures.
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
strict_strtoul() is obsolete. Use kstrtoul() instead.
Otherwise we run into following build error:
CC drivers/cpufreq/cpufreq_interactive.o
drivers/cpufreq/cpufreq_interactive.c: In function ‘store_hispeed_freq’:
drivers/cpufreq/cpufreq_interactive.c:784:2: error: implicit declaration of function ‘strict_strtoul’ [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[2]: *** [drivers/cpufreq/cpufreq_interactive.o] Error 1
Change-Id: Ib91b9df3af5fe2a244861c2f598bd20ec8115e6c
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Interactive governor doesn't rearm per-cpu timer if target_freq is
equal to policy->max. However, this does not have clear performance
benefits. Profiling doesn't show any difference in benchmarks, games
or other workloads, if timers are always rearmed.
At same time, there are a few issues caused by not rearming timer
at policy->max.
1) min_sample_time enforcement is inconsistent
For target frequency that is lower than policy->max, it will not
drop until min_sample_time has passed since last frequency evaluation
selected current frequency. However, for policy->max, it will
always drop immediately as long as CPU has been run for longer than
min_sample_time. This is because timer is not running and thus
floor_freq and floor_validate_time is not updated.
Example: assume min_sample_time is 59ms and timer_rate is 20ms.
Frequency X < Y. Let's say CPU would pick the following frequencies
before accounting for min_sample_time in each 20ms sampling window.
Y, Y, Y, Y, X, X, X, X, X
If Y is not policy->max, the final target_freq after considering
min_sample_time will be Y, Y, Y, Y, *Y, *Y, X, X, X
* marks the windows where frequency is prevented from dropping.
If Y is policy->max, the final target_freq will be
Y, Y, Y, Y, X, X, X, X, X
2) Rearm timer in IDLE_START does not work as intended
IDLE_START/END is sent in arch_cpu_idle_enter/exit(). However, next
wake up is decided in tick_nohz_idle_enter(), which traverses the
timer list before idle notification is sent out. Therefore, rearming
timer in idle notification won't take effect until CPU wakes up at
least once. In rare scenarios when a CPU goes to idle and sleeps for a
long time immediately after a heavy load stops, it may not wake up
to drop its frequency vote for a long time, defeating the purpose of
having a slack_timer.
3) Need to rearm timer for policy->max change
commit 535a553fc1c4b4c3627c73214ade6326615a7463
(cpufreq: interactive: restructure CPUFREQ_GOV_LIMITS) mentions the
problem of timer getting indefinitely pushed back due to frequency
changes in policy->min/max. However, it still cancels and rearms timer
if policy->max is increased, and same problem could still happen if
policy->max is frequently changing after the fix. The best solution is
to always rearm timer for each CPU even if it's running at
policy->max.
Rearming timers even if target_freq is policy->max solves these
problems cleanly. It also simplifies the design and code of interactive
governor.
Change-Id: I973853d2375ea6f697fa4cee04a89efe6b8bf735
Reviewed-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
min_sample_time needs to be cluster-based to match
above_hispeed_delay. If each CPU keeps making local decisions, it's
possible min_sample_time is not correctly enforced at cluster level,
which results in undesired frequency drops.
Change-Id: Ia2ec2ad9b7a8d715d4408c924d6762b7e532e4b4
Reviewed-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
If a heavy task migrates between otherwise idle CPUs in a policy during
every sample window, the above hispeed delay window for the CPUs would get
restarted for every sample window. Due to the continuous restart of above
hispeed delay window, none of the CPUs would ever pick a target frequency
higher than hispeed frequency. This causes the policy's frequency to be
stuck at hispeed freq even if the load justifies a higher frequency.
To fix this, the above high speed delay window is restarted only when the
policy frequency changes. This ensures that tasks migrating between CPUs in
a policy are handled correctly.
Also, the hispeed load/frequency heuristic is only necessary when the
information is insufficient to determine if the load on the CPU needs at
least hispeed frequency. When the policy frequency is already at or above
hispeed frequency, if the CPU load% based on policy frequency is not above
hispeed load, then the information is clearly sufficient to determine that
the load on the CPU does not need hispeed frequency.
Therefore, compute CPU load% (which is used only to compare against hispeed
load) based on policy frequency instead of CPU target frequency.
Change-Id: I8b5dfe6c50bee567a6719f0980e3f7757876ce4b
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Timers are scheduled in unit of jiffies. Round up timer_rate so that
it matches the actual sampling period.
Change-Id: I88386a5a448e40333f9a9b9f0cf72af58cb54656
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
Frequency selection algorithm guarantees its chosen frequency
is not lower than hispeed_freq as long as boost is enabled.
Setting floor_freq and floor_validate_time during boost could block
CPU frequency from going below hispeed_freq even after
boostpulse_duration expires, if min_sample_time is higher than
boostpulse_duration. This conflicts with the intention of commit
de091367ead15b6e95dd1d0743a18f0da5a07ee5
(cpufreq: interactive: specify duration of CPU speed boost pulse)
to allow CPU to ramp down immediately after boost expires. It also
makes boost behavior inconsistent since it depends on min_sample_time.
Avoid setting floor_freq and floor_validate_time when boost starts.
Change-Id: I12852998af46cfbfaf8661eb5e8d5301b6f631e7
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
It is not correct to boost all the cpus when tunable boost
parameters are changed. It also does not need to boost the
cpus which is already boosted.
Signed-off-by: Lianwei Wang <a22439@motorola.com>
When __cpufreq_driver_target() in speedchange_task failed for some reason, the
policy->cur could be lower than the target_freq. The governor misses to change
the target_freq if the target_freq is equal to the next_freq at the next sample
time.
Added a check to prevent the CPU to stay at the speed that is lower than the
target_freq for long duration.
Change-Id: Ibfdcd193b8280390b8f8374a63218aa31267f310
Signed-off-by: Minsung Kim <ms925.kim@samsung.com>
When the load was below go_hispeed_load, there is a possibility that
choose_freq() would return a frequency which would be higher than the
hispeed_freq. According to the policy we should first jump to the
hispeed_freq, stay there for above_hispeed_delay and then be allowed to
raise higher than that.
Added a check to prevent the frequency to be directly raised to
something higher than the hispeed_freq.
Change-Id: Icda5d848dd9beadcc18835082ddf269732c75bd0
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
