We want to display a buffer allocated by other driver, need import
the buffer to gem.
Change-Id: Ifd5fef3fbf2b4daea6d624ed2a250c2fe626309d
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
This adds a power supply type for special USB charger,
this kind of USB charger is similar to Dedicated Charging
Port, but not a standard DCP because of D+/D- not short.
Change-Id: I7c478da642b43465a9de65c8b5d7b8250c0da037
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
RK3399 SoC usb2 PHY comprises with one host-port and
one otg-port, we support otg-port for the time being.
Change-Id: I7d6a464372603e54c3a06d994e18d80eb84fa5a5
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
For RK3399's GRF module, if we want to operate the graphic related grf
registers, we need to enable the pclk_vio_grf which supply power for VIO
GRF IOs, so it's better to introduce an optional grf clock in driver.
Change-Id: I8f43e5c46c8559d6b6fe96a12cd026319b1d84e5
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9223317/)
For RK3399 HDMI, there is an external clock need for HDMI PHY,
and it should keep the same clock rate with VOP DCLK.
VPLL have supported the clock for HDMI PHY, but there is no
clock divider bewteen VPLL and HDMI PHY. So we need to set the
VPLL rate manually in HDMI driver.
Change-Id: I73abc382ff43bfa93d150c3449693f207029549f
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9223327/)
RK3399 and RK3288 shared the same HDMI IP controller, only some light
difference with GRF configure.
Change-Id: Ic404ff3df6004a87b709f00552d91eb546c78450
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9223315/)
The previous tables for mpll_cfg and curr_ctrl were created using the
20-pages of example settings provided by the PHY vendor. Those
example settings weren't particularly dense, so there were places
where we were guessing what the settings would be for 10-bit and
12-bit (not that we use those anyway). It was also always a lot of
extra work every time we wanted to add a new clock rate since we had
to cross-reference several tables.
In <http://crosreview.com/285855> I've gone through the work to figure
out how to generate this table automatically. Let's now use the
automatically generated table and then we'll never need to look at it
again.
We only support 8-bit mode right now and only support a small number
of clock rates and and I've verified that the only 8-bit rate that was
affected was 148.5. That mode appears to have been wrong in the old
table.
Change-Id: I42b260300880f2bab6732c5ee3b11bc78e87500c
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
(am from https://patchwork.kernel.org/patch/9223325)
Dut to the high HDMI signal voltage driver, Mickey have meet
a serious RF/EMI problem, so we decided to reduce HDMI signal
voltage to a proper value.
The default params for phy is cklvl = 20 & txlvl = 13 (RF/EMI failed)
ck: lvl = 13, term=100, vlo = 2.71, vhi=3.14, vswing = 0.43
tx: lvl = 20, term=100, vlo = 2.81, vhi=3.16, vswing = 0.35
1. We decided to reduce voltage value to lower, but VSwing still
keep high, RF/EMI have been improved but still failed.
ck: lvl = 6, term=100, vlo = 2.61, vhi=3.11, vswing = 0.50
tx: lvl = 6, term=100, vlo = 2.61, vhi=3.11, vswing = 0.50
2. We try to keep voltage value and vswing both lower, then RF/EMI
test all passed ;)
ck: lvl = 11, term= 66, vlo = 2.68, vhi=3.09, vswing = 0.40
tx: lvl = 11, term= 66, vlo = 2.68, vhi=3.09, vswing = 0.40
When we back to run HDMI different test and single-end test, we see
different test passed, but signle-end test failed. The oscilloscope
show that simgle-end clock's VL value is 1.78v (which remind LowLimit
should not lower then 2.6v).
3. That's to say there are some different between PHY document and
measure value. And according to experiment 2 results, we need to
higher clock voltage and lower data voltage, then we can keep RF/EMI
satisfied and single-end & differen test passed.
ck: lvl = 9, term=100, vlo = 2.65, vhi=3.12, vswing = 0.47
tx: lvl = 16, term=100, vlo = 2.75, vhi=3.15, vswing = 0.39
Change-Id: I766df9ad519ddddb9be76f95fbbdb36c5a2d6e51
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
(am from https://patchwork.kernel.org/patch/9223303/)
Jitter was improved by lowering the MPLL bandwidth to account for high
frequency noise in the rk3288 PLL. In each case MPLL bandwidth was
lowered only enough to get us a comfortable margin. We believe that
lowering the bandwidth like this is safe given sufficient testing.
Change-Id: Ife266747f0e6ed46f914f4868362fefc481440f9
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9223301/)
Add sdmmc dts nodes support for RK3288-Fennec boards
Change-Id: I6e62da8ef84a7c5a492f54448fc7261ff87432bf
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Add the config for rockchip SoCs with ubuntu os, the most of SoCs will be supported
for this config. (e.g: rk3036. rk3288....)
Change-Id: Ia781de208ccaad7a95b6a325fce97db5e588fafa
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
If current color mode and depth is auto, information in sysfs
node is equal to zero, is not responsed to actual mode and
depth, now fix it.
Change-Id: Ifd2888b2af5522a026be92071d98d6bc081d02db
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit c2cac5c2cff8464ab4ba2c2638a84d997aa0365e)
Because there are not the gpu and vpu dts nodes in the rk3288-dtsi
on the upstream, and we need to these feature for Rockchip Release
Platform. Let's support them.
Change-Id: I890aeb139476dca26f760db4603bf63a55aa4084
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
This adds support for RK3288-Fennec boards. Currently supported
are serial console, wired networking, hdmi output and USB.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
(cherry picked from git.kernel.org kernel/git/mmind/linux-rockchip.git
v4.8-armsoc/dts32 commit 4285b7e744ce08e92fd2231c08c34bb674d08f87)
Change-Id: I8bdd6a004c49883cb0d25761275312a6d9267879
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
It will return state++ when get the idle state, so we need fill
anothor idle power(=WFI) in the parameter of EAS, code as below:
static int group_idle_state(struct sched_group *sg)
{
int i, state = INT_MAX;
/* Find the shallowest idle state in the sched group. */
for_each_cpu(i, sched_group_cpus(sg))
state = min(state, idle_get_state_idx(cpu_rq(i)));
/* Take non-cpuidle idling into account (active idle/arch_cpu_idle()) */
state++;
return state;
}
Change-Id: I9293da1379746768823df4e75a7478aa50fc0e87
Signed-off-by: Chen Liang <cl@rock-chips.com>
All of the sched domains will be destroied and then rebuilded when a cpu
online/offline, if a softirq comes after the shced domains are destroied,
this cpu will be stucked in the infinite loop in sched_group_energy(),
because of it can not get the shced donmain in for_each_domain(cpu, sd).
Change-Id: I154cf560e4e1af4a7a2547154ad321e936196ce3
Signed-off-by: Chen Liang <cl@rock-chips.com>
Set unused plane with top zpos will cause a alpha problem.
if there are two planes use same zpos, hardware will do twice
alpha compute, that would cause display abnormal.
Change-Id: I3b5d15c5239412c670ad377edbcc66d7f6c59341
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
GMAC Power Domain(PD) will be disabled during suspend.
That will causes GRF registers reset.
So corresponding GRF registers for GMAC must be setup again.
Change-Id: I9ca541c4599299bad309b810994824d364c2a510
Signed-off-by: Roger Chen <roger.chen@rock-chips.com>
It will cause deadlock and while(1) if call printk while schedule
is in progress. The block state like as below:
cpu0(hold the console sem):
printk->console_unlock->up_sem->spin_lock(&sem->lock)->wake_up_process(cpu1)
->try_to_wake_up(cpu1)->while(p->on_cpu).
cpu1(request console sem):
console_lock->down_sem->schedule->idle_banlance->update_cpu_capacity->
printk->console_trylock->spin_lock(&sem->lock).
p->on_cpu will be 1 forever, because the task is still running on cpu1,
so cpu0 is blocked in while(p->on_cpu), but cpu1 could not get
spin_lock(&sem->lock), it is blocked too, it means the task will running
on cpu1 forever.
Change-Id: I60d02d8c957273872f97939632bdd235accdad4e
Signed-off-by: Chen Liang <cl@rock-chips.com>
This patch fix this bug:
BUG: KASAN: global-out-of-bounds in i2c_device_match+0x64/0xa4 at addr ffffff9009046800
Read of size 1 by task swapper/0/1
Address belongs to variable xz3216_i2c_id+0x20/0x2c0
CPU: 5 PID: 1 Comm: swapper/0 Not tainted 4.4.14 #21
Hardware name: Rockchip RK3399 Evaluation Board v2 (Android) (DT)
Call trace:
[<ffffff900808b2d8>] dump_backtrace+0x0/0x288
[<ffffff900808b574>] show_stack+0x14/0x1c
[<ffffff90084c16c4>] dump_stack+0xc4/0x100
[<ffffff900823fdd4>] kasan_report+0x36c/0x49c
[<ffffff900823f2e4>] __asan_load1+0x24/0x50
[<ffffff90088f7924>] i2c_device_match+0x64/0xa4
[<ffffff90086829b8>] __device_attach_driver+0x80/0xd8
[<ffffff900868064c>] bus_for_each_drv+0xf8/0x12c
[<ffffff900868232c>] __device_attach+0x114/0x1a4
[<ffffff9008682b9c>] device_initial_probe+0x10/0x18
[<ffffff9008680904>] bus_probe_device+0x50/0xe8
[<ffffff900867ee14>] device_add+0x5f8/0x774
[<ffffff900867efac>] device_register+0x1c/0x28
[<ffffff90088f7dd0>] i2c_new_device+0x258/0x2a4
[<ffffff90088f853c>] i2c_register_adapter+0x4b4/0x600
[<ffffff90088f8700>] __i2c_add_numbered_adapter+0x78/0x88
[<ffffff90088f8d9c>] i2c_add_adapter+0x50/0xcc
[<ffffff9008900c1c>] rk3x_i2c_probe+0x460/0x4fc
[<ffffff9008684fac>] platform_drv_probe+0x70/0xc8
[<ffffff9008682648>] driver_probe_device+0x16c/0x364
[<ffffff90086828d4>] __driver_attach+0x94/0xc8
[<ffffff9008680010>] bus_for_each_dev+0xe0/0x11c
[<ffffff9008682bd4>] driver_attach+0x30/0x3c
[<ffffff9008680ca8>] bus_add_driver+0x160/0x294
[<ffffff9008683edc>] driver_register+0x10c/0x168
[<ffffff9008685e34>] __platform_driver_register+0x7c/0x88
[<ffffff90095da854>] rk3x_i2c_driver_init+0x18/0x20
[<ffffff90095a4df0>] do_one_initcall+0x168/0x220
[<ffffff90095a5078>] kernel_init_freeable+0x1d0/0x274
[<ffffff9008ec5f40>] kernel_init+0x10/0x108
[<ffffff9008084cd0>] ret_from_fork+0x10/0x40
Memory state around the buggy address:
ffffff9009046700: fa fa fa fa 00 03 fa fa fa fa fa fa 00 00 00 07
ffffff9009046780: fa fa fa fa 07 fa fa fa fa fa fa fa 00 00 00 00
>ffffff9009046800: fa fa fa fa 00 01 fa fa fa fa fa fa 00 01 fa fa
^
ffffff9009046880: fa fa fa fa 04 fa fa fa fa fa fa fa 00 04 fa fa
ffffff9009046900: fa fa fa fa 00 05 fa fa fa fa fa fa 07 fa fa fa
Change-Id: I624d92b1fefdf87cfb58b9df10db85723b5ed534
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
Some vop can't support 10bit mode, if connector needs 10bit output,
force to use 8bit rgb888 mode, because the hardware would do the
format convert.
Change-Id: I8cdfbab12dd0ad63d36f3c52a4c7786a2bdbe6a1
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
policy->governor_data will be use in cpufreq_sched_thread, but it is init
after wake thread, it will cause NULL point access.
Change-Id: I320a3da34560e49f293211be92cb8310d8e395d7
Signed-off-by: Chen Liang <cl@rock-chips.com>
If we do not limit the freqency immediately when the cpu is overheat,
thermal driver will lost the control of temperature. So implement event
CPUFREQ_GOV_LIMIT for governor to limit the freqency immediately.
Change-Id: Id709edd377226417ead92ead2ae3d3d19b3eeabf
Signed-off-by: Chen Liang <cl@rock-chips.com>
The hardware-tracked trips will set the alarm interrupt value for
registers. Then when the thermal zone has no trips to be set,
That make the thermal trips callback a over range value.
The root cause is the rk_tsadcv2_temp_to_code() function to handle the
invalid temperature range is indeed incorrect, let's fix it on now.
Otherwise, the thermal alarm interrupt will be triggered all the time
on some SoCs.
Fox example:
localhost tmp # grep thermal /proc/interrupts; sleep 5;
grep thermal /proc/interrupts
23: 994830 .. GICv3 129 Level rockchip_thermal
23: 1003423 .. GICv3 129 Level rockchip_thermal
Change-Id: I0ddbd0b2dd9c03e785e588f5f339f1eeed4e1c5c
Reported-by: Rocky Hao <rocky.hao@rock-chips.com>
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: linux-pm@vger.kernel.org
(am from https://patchwork.kernel.org/patch/9192357/)
Due to there are only two vop module, that's to say we can't keep
enable eDP / LVDS / HDMI at the same time, so this time we still
keep LVDS device disabled. If you want to enable lvds device,
then you should disable the HDMI or eDP device, and enable the
LVDS device.
And one more thing that eDP panel and LVDS panel can't enable at
the same time, cause both of them have the same enable gpio. If
you still want to do this, there is an hack way that delete the
'enable-gpios' comptabile from 'lvds-panel'.
Change-Id: Iecf71adc4d307dcdb8b7317a93430e99bb12e20a
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Add the basic node for the lvds controller of rk3288 and hook it into the
display-subsystem hirarchy.
Change-Id: I150f27e5d9a626342c4fe984167f94ae717ab9ad
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Add pinctrl settings for the configurable lcdc0 signals dclk, den, hsync
and vsync. The lcdc0 data pin configuration is not software controlable.
Change-Id: I733179908fd4276e919fe44c6125d504926d751a
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
