in addition,
resolve all the conflicts;
rename all the configs and macros that have a same name in midgard/;
fix a compiling error.
Change-Id: I5abc8c925049e087c59b66da57c82aac3092be71
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
Opp rate is used to calc power in thermal framework, so we record
this rate instead of real clock rate.
Devfreq is not ready in target() when use performance governor, so
we need record opp rate in probe().
Change-Id: Iec1918ad5d12124b9f112964f247339e0d50645f
Signed-off-by: Liang Chen <cl@rock-chips.com>
Otherwise, clk_gpu won't be disabled actually in the runtime.
Change-Id: I92787a5e23bfb92f5a79efda92c130832751cc3b
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
If the regulator is shared between several devices then the lowest
request voltage that meets the system constraints will be used.
Change-Id: Icb6afcb571bddd6709d352dfad8fc2da80567bc0
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
If there is only one opp whose frequency is equal to the initial value
in opp table list, the GPU voltage domain will keep the initial voltage,
it may be too large.
Change-Id: If2ae1c876de185d810e05296b1b9e98855c3ef48
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
including :
modifications for changing patch from drivers/gpu/arm/midgard
to drivers/gpu/arm/bifrost;
rename output mali_kbase.ko to bifrost_kbase.ko;
rename configs, which have duplicated names in midgard, in Kconfig,
Kbuild and source files.
Change-Id: I127d8c8043db9010398946b3f4a90640ab1f13fe
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
When CONFIG_NEED_SG_DMA_LENGTH is enabled,
sg_dma_len is defined as follow :
"#define sg_dma_len(sg) ((sg)->dma_length)"
But, dma_length is not used by the framework indeed.
Change-Id: I93b4ceed28882236dc252fcabb7c7710153804a0
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
Some optimizations on files of KBuild in addition.
Change-Id: I1db012e116b8b69897a2791ae610da35365a1a61
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
When the devfreq cooling device was designed, it was an oversight not to
pass a pointer to the struct devfreq as the first parameters of the
callbacks. The design patterns of the kernel suggest it for a good
reason.
By passing a pointer to struct devfreq, the driver can register one
function that works with multiple devices. With the current
implementation, a driver that can work with multiple devices has to
create multiple copies of the same function with different parameters so
that each devfreq_cooling_device can use the appropriate one. By
passing a pointer to struct devfreq, the driver can identify which
device it's referring to.
Change-Id: I384bf9aafd2391eccab2ca6a76e4e57f2740aa6b
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Reviewed-by: Punit Agrawal <punit.agrawal@arm.com>
Reviewed-by: Ørjan Eide <orjan.eide@arm.com>
Reviewed-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
Signed-off-by: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
(cherry picked from commit 3aa5374376)
Some chips need adjust opp level by different chip-process, add
common functions to select opp level from device-tree, so modules
can select opp level easy.
Change-Id: Ifbd5f720e6a52a68f13697bbb37ac01ff4a87e3e
Signed-off-by: Liang Chen <cl@rock-chips.com>
Including:
not to call pm_runtime_suspend() in mali_runtime_idle();
make it more strict to power off the GPU.
Change-Id: I8c49dd13f57826f28606fd7a4e451707978b2906
Signed-off-by: Zhen Chen <chenzhen@rock-chips.com>
As the gpu driver used the devfreq thermal, The mali will be failure to
load the driver since the rk platform hadn't the driver requested
deferred probing.
as the following is failure log:
[ 7.126149] Mali: ERR: drivers/gpu/arm/mali400/mali/linux/mali_kernel_linux.c
[ 7.126157] mali_probe() 550
mali_probe(): Failed to initialize platform device.
[ 7.126191] mali-utgard: probe of 10091000.gpu failed with error -14
..
Add the SoCs judge if we will use the devfreq-thermal for mali driver.
If the other SoCs has the similar issue, we can do this way.
Change-Id: I9faf6530119adb99efeac491e665641ee8b1143d
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
If the regulator is shared between several devices then the lowest
request voltage that meets the system constraints will be used.
Change-Id: I68536a8e9cc5a78c21b55564a2ed540b9c184cb8
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
If there is only one opp whose frequency is equal to the initial value
in opp table list, the GPU voltage domain will keep the initial voltage,
it may be too large.
Change-Id: I3dd97fe252a15b789f218f44b8fbc7d4143f7085
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
The greater leakage, the lower the OPP's voltage. In order to reduce
power consumption, it is necessary to adjust OPP's voltage according
to leakage.
Change-Id: I2bba04ac941cc6a0703b5208cb4e757ec2813bab
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
At same voltage and frequency, the greater the PVTM value, the lower
the OPP's voltage. In order to reduce power consumption, it is necessary
to adjust OPP's voltage according to PVTM value.
Change-Id: Ifcac57fc965e3ea45523db2d9df19435479f6cee
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
The original setting of "max_job_runtime" is too small
that jobs are too easy to timeout and be killed.
Change-Id: I5316c2b594d94dd0b844ef9a297baa7b226c4665
Signed-off-by: chenzhen <chenzhen@rock-chips.com>
This is the content of
Case693349_the_spinlock_fix_patch_2_for_kernel_4.4.patch
from support_mali, with slight modifications for building
with rockchip_linux_defconfig,
in which CONFIG_SYNC is not set.
Change-Id: Icedff21f7941fd1aefceb6be4fda638378fe4ca8
Signed-off-by: chenzhen <chenzhen@rock-chips.com>
If the temperature(sbs-battery) reaches the switch_on_temp, it would try
to calculate requested power of all thermal instances. Then hit the
crash[0] caused by the gpu thermal sensor, since the thermal driver had not
registered in time.
[0]
[ 0.827943] Call trace:
[ 0.827953] [< (null)>] (null)
[ 0.827969] [<ffffffc00070af1c>] get_static_power+0xd8/0xe8
[ 0.827981] [<ffffffc00070b190>] devfreq_cooling_get_requested_power+0x94/0x170
[ 0.827997] [<ffffffc0007094c8>] power_allocator_throttle+0x270/0x804
..
Change-Id: I63f66e54d69115165a7b3ec798b9009c360daa62
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
DDK integrate_guide says
"not to use core_scaling on r5p0-01rel0 and later."
Change-Id: Ibb3eddac75548bb9f6763dc4dc9bad540746191f
Signed-off-by: chenzhen <chenzhen@rock-chips.com>
Some dependences of mali device driver should be initialized first.
Change-Id: I76f1d8b029345801bf0a68266889ec1c5a28b524
Signed-off-by: chenzhen <chenzhen@rock-chips.com>
To ensure that the work is executed before system being suspended.
Change-Id: Iec1bd114dfff53e2464540f09ced66cf6be81d1a
Signed-off-by: chenzhen <chenzhen@rock-chips.com>
Along with a slight modification in mali_kbase_core_linux.c,
for building in rk Linux 4.4:
-#if KERNEL_VERSION(4, 6, 0) > LINUX_VERSION_CODE
+#if KERNEL_VERSION(4, 4, 0) > LINUX_VERSION_CODE
Change-Id: I34565cb975866b46c5e3a4d8e2ac5e350dcceb80
Signed-off-by: chenzhen <chenzhen@rock-chips.com>
