The TZ governor start can be invoked through the sysfs governor store()
operation. This opens up a possible race when user space tries to set
the same governor operation twice leading to calling the TZ governors
tz_handler() in succession. While the first one goes through
successfully and queues the work for starting the bandwidth governor,
before the work gets to run, the second invocation of the tz_handler
reinitializes the work. This causes the internal state of the work item
to be reset causing a crash in the kernel workqueue handler.
This patch tries to address this problem by not allowing the
tz_handler() to run the next time, if the first invocation was already
successful and potentially in progress.
Change-Id: Id2d6b9f680c873937a64eeb483ce8359306cd7b0
Signed-off-by: Sharat Masetty <smasetty@codeaurora.org>
These governors should fail if being set for any device
other than the gpu device. Do this by checking that the
devfreq device for which this governor is being set for
has the gpu device as it's parent device.
The vbif_bw governor immutable attribute is used
to restrict it being set for only gpu devfreq devices.
Because we don't intend to change the governor for
the devfreq devices which have this governor set as
default.
Change-Id: I391557c0d52a1f4ffba70e010401a0769587dea0
Signed-off-by: Harshdeep Dhatt <hdhatt@codeaurora.org>
This fixes below compilation error for 32bit kernel
build. Compiler reference __aeabi_uldivmod if there
is a 64bit divide or module. Change is to use do_div
to fix this.
governor_msm_adreno_tz.c: undefined reference to `__aeabi_uldivmod'.
Change-Id: I4de7ada2274698d20d304d8ffe1a92d3bcb7653d
Signed-off-by: Deepak Kumar <dkumar@codeaurora.org>
Current acc_relative_busy calculation is causing integer overflow
in 32 bit system. "stats->busy_time * stats->current_frequency"
results in a value which is beyond the 32 bit range.
Typecasting the value to u64 to avoid overflow.
Change-Id: Id97da02bef608787ceb7c9751bbfc203af56deb1
Signed-off-by: Harshitha Sai Neelati <hsaine@codeaurora.org>
This is the recommended way of using the devfreq api from
within governors. The devfreq_update_stats() will utilize the
devfreq.last_status to get the target device status so we no
longer need to declare a local variable to get the target
status.
Change-Id: I5d80e39468e3eb90e55dcb0a813cb846a65ee8a5
Signed-off-by: Harshdeep Dhatt <hdhatt@codeaurora.org>
Instead of directly allocating memory and registering the
buffers to TZ, use SHM bridge to allocate buffers and
register those buffers to TZ.
Change-Id: Ibdc5a66af432f1fb2c8813b0b3578503f404eefc
Signed-off-by: Urvashi Agrawal <urvaagra@codeaurora.org>
Signed-off-by: Raghu Ananya Arabolu <rarabolu@codeaurora.org>
Adding a snapshot of the devfreq files on 4.14 as of
commit 9ac69cf (clk: qcom: gcc: Support code for clock
controller for sdxprairie).
Change-Id: Ib9491280c14f0ec0ff1c3b34aba5ce1e4f510b54
Signed-off-by: Urvashi Agrawal <urvaagra@codeaurora.org>
