lp8752 static power is too high when in foce pwm mode,
change it's mode to auto.
Change-Id: I6b1342cc8b63d240d90194b52f5926501ea7babf
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
For rk3366 and rk3399, the usb-phy IP block is different than
previous chips, so we should use a new driver to handle them.
Change-Id: I44ebe883664e9fb2fce8707bab2d9159c546e51f
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
due to a merge mistake in I3b80a31681765836a134812ebc56686324ca5194.
Change-Id: Iad2914518997b664704f2c2933c8327fc4252bbb
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Add cru and pmucru regs dump when system panic.
It's just for debug.
Change-Id: I3f837f2941054129d20c2355d86f575d6ee84665
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
This patch add otg-port support. For now, however,
it only support BC1.2 charger detect, power management,
and hold a wakelock when work as SDP(e.g. connect to PC),
and it need to implement otg device/host switch in future.
Change-Id: Ib58aef748211f947da439ebe59fa5cf8dc1fa010
Signed-off-by: Wu Liang feng <wulf@rock-chips.com>
We want add display support on loader, share the same timing
with kernel side, but the timing is hide into kernel code,
can't be share, avoid config twice display timing, add device-tree
display timing support would be good idea.
With this patch, loader and kernel can share same timing from
device node.
Cc: Thierry Reding <thierry.reding@gmail.com>
Change-Id: I6c1ee6ad0194e242035e2f11589d86fdb363b80a
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
(am from https://patchwork.kernel.org/patch/9238727)
Current dw-hdmi is supporting sound via AHB bus, but it has
I2S audio feature too. This patch adds I2S audio support to dw-hdmi.
This HDMI I2S is supported by using ALSA SoC common HDMI encoder
driver.
Change-Id: I32e95f66838883ac44a45f95c55583184a0a1b46
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
(am form https://patchwork.kernel.org/patch/9196453/)
Commit b360d3748e ("ASoC: hdmi-codec: callback function will be called
with private data") have introduced an external parameter in struct
hdmi_codec_ops, so need to fix the old interfaces.
Change-Id: Iaebd49ba7eb7fc0d857ff8aa8f9af39ea4678143
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Due to the voltage ripple, the sensing data of the tsadc is not accurate.
And in this patch, the bandgap feature is enhanced to remove the voltage
ripple, and then the tsadc can sense the temperature more precisely.
Obsolete codes are removed as well.
Change-Id: Ifdd98def63212bc13306e7d5befee5eb32dbbc2f
Signed-off-by: Rocky Hao <rocky.hao@rock-chips.com>
There are some rates that would be ranged for better clock jitter at
Chrome OS tree, like 25.175Mhz would range to 25.170732Mhz.
But due to the clock is aglined to KHz in struct drm_display_mode,
this would bring some inaccurate error if we still run the compute_n
math, so let's just code an const table for it until we can actually
get the right clock rate.
Change-Id: Ief14b7c9bffa95ff3b173925f3e1bd795625320d
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/316280
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
The original math would bring some inaccurate to N/CTS that would
caused those magic number won't fit the HDMI 1.4 Spec request:
128 * SampleRate = Tmds * N / CTS;
So this time we try to improved to math of N that would find the
minimal inaccurate with the HDMI 1.4 Spec.
Change-Id: Ied3cde3c352d955ae6f15d5e7fb172e92316c2a5
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/315424
Reviewed-by: Douglas Anderson <dianders@chromium.org>
We allow some amount of slop in dw_hdmi_rockchip_mode_valid(). That's
a good thing since allowing a little bit of slop lets us support a
bunch of extra resolutions.
Originally, we also made a change to the VOP code to add the concept
of slop in there. That was reasonable, but there was a problem: it
would tend to request clock rates that weren't _exactly_ clock rates
that we thought about. It's possible that the common clock framework
would map these to PLL rates that we haven't thought about and we
haven't tested for jitter.
Instead of changing VOP, we should probably adjust the clock ourselves
in the mode_fixup function. That way we'll request the exact clock we
tested and we'll know how the common clock framework will map it.
Change-Id: I56c2b046f76d554aab5eaed7a6b171ea074d6a62
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/284376
Reviewed-by: Alexandru Stan <amstan@chromium.org>
Add a check just to make sure that someone doesn't try to give us a
pixel clock that is > 2GHz. If they did that, some of our math might
overflow, so it's good to make sure we don't do it.
Change-Id: I451602f0d771bb16b399b43e376e1054b7ee060f
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/284642
Reviewed-by: Alexandru Stan <amstan@chromium.org>
This cleanup will allow the following patch to implement slop easier.
25175000-40000000 and a few other ranges use the same settings.
And the rest of the driver already snaps to the next highest
frequency when it gets the settings. So this patch removes
a lot of the duplicates. It should be a noop change.
And frequencies within 0.1% should be close enough, let's redo
rockchip hdmi to allow slop.
Change-Id: Ic4865b2825de9b6c3b3e8d029066a8964e8ede6b
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
rockchip_vpu_hw.c:251:5: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
Change-Id: Ia5564c2da345c5922341b818961b18d2b1419013
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
We enable it by default as we could see the usage of PCB layout
will not stuff this registor. For currently boards which soldered
it already, there should be no harmful.
Change-Id: Idc05c244dbaeebb1028e4828aa7a7d655899beb8
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Reference the power domain incase dw-mipi power down when
in use.
Change-Id: I54a0f418f20299a744f87c1337f06ff3341dfac5
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
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>
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/)
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)
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>
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>
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/)
This adds support for Rockchip soc lvds found on rk3288
Change-Id: Iaab32c8c02fb17bf55db97a7952a346ce45c7d09
Signed-off-by: Mark Yao <yzq@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Yakir Yang <ykk@rock-chips.com>
