when vp0 and vp1 indenpendent config layer_sel register, this register take effect
time is prone to error, so we add the following measures to workaround this issue:
1. Add commit_lock to make sure vp0 and vp1 config register is mutually exclusive;
2. Make sure layer sel register is take effect when it's update.
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Change-Id: Ief832e2bf7e18567f4ea663843c77f0afbd21cf7
RGA need to access CMA buffer at kernel space, so add this flag to keep kernel
line mapping for RGA.
Change-Id: Ia59acee3c904a495792229a80c42f74ae34200e3
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
use drm_gem_dumb_map_offset() to instead of rockchip_gem_dumb_map_offset()
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Change-Id: I992da13480991cf48206868f77f86c3965661b8f
This make cpu can dump fb data allocated by ION.
Change-Id: I639e7cbbe6957d2bb02e4577805343cdbf5f5bf7
Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
for some scene we need to alloc continue buffer from dma buffer,
but vop iommu is still enable, so we add iommu map for dma buffer.
Change-Id: I4749eac53609f865d0d4230364b1cbaf39ee095a
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
we need to store some private data for logo display, so we extend the
rockchip_drm_logo_fb from drm_framebuffer.
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Change-Id: Ic6ba63b33b07b8dca9aa59b9bdb4137f4af0cda0
We support page flip through the drm atomic helper function.
But if we don't enable it the userspace won't know this
driver has such a capability.
Change-Id: If3689a526ea95235d191c0bbeba89745ae70d9c7
Signed-off-by: Randy Li <randy.li@rock-chips.com>
implement rockchip_drm_atomic_helper_commit_tail_rpm() to instead of
drm_atomic_helper_commit_tail_rpm(), this is prepare to add some rockchip
private implement, just like calculate bandwidth and make sure commit
planes is mutually-exclusive.
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Change-Id: I2ac87f672a3ef06611b5047781f7cf53aa4b3700
In future it will be modified to support more rockchip platforms.
Change-Id: I5cd7ce555eefe08b12fbfcda8ef445c4b169e8c6
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
drivers/video/rockchip/rga/rga_drv.c: In function 'rga_get_rotate_mode_str':
drivers/video/rockchip/rga/rga_drv.c:199:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
199 | else if (req_rga->sina == -65536 && req_rga->cosa == 0)
| ^
drivers/video/rockchip/rga/rga_drv.c:202:2: note: here
202 | case 0x2:
| ^~~~
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I2416a20f4acb5345ee130e6e93ea923205b4e395
Add rockchip_ddr_set_rate to support ddr frequency switching.
This function wraps the SMC call and frequency switching is
implemented in ATF. Afterwards it will call clk_get_rate to
update the rate in clock framework.
Set dmcfreq->is_set_rate_in_dmc=true to enable this process.
Change-Id: I9349a2e8413751360bf105a70e46d1453791194c
Signed-off-by: YouMin Chen <cym@rock-chips.com>
"system-status-level" property define only frequency level, not the
actual frequency. In dmc driver, it will switch from frequency level
to actual frequency base on available frequencies table which get
from ATF.
Change-Id: I489b671da5e56912d4f970d32174bdc8b1f86a08
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Add the function of rockchip_get_freq_info to get available ddr
frequencies info via SMC call. The frequency info include available
frequencies count and frequencies table(sort by rate from low to high).
Afterwards it will update the dmc_opp_table base on frequencies info.
If have "system-status-level" property in dmc, the function of
rockchip_get_system_status_level will get the frequency for
system-status base on frequency level and available frequencies table.
Change-Id: I73d0f999e718ba9426ad75e48ac2a4ec3fe5f496
Signed-off-by: YouMin Chen <cym@rock-chips.com>
When setting the 16550 serial port baud rate, you need
to configure the UART to loopback mode. After setting
the DLL and DLH, you need to reset the LSR first,
and then configure the MCR to make the UART return
to the normal mode. If you do not reset the LSR
first, an error will occur when the UART RX is still
receiving data.
Signed-off-by: Steven Liu <steven.liu@rock-chips.com>
Change-Id: Ia940b278554ef1d4e7a6c4550fe4a4600407a57e
Enable programmable transmit interrupt mode in order to increase
system performance.
Change-Id: Ic1ef9ecae0c6feb00170ad97ee3c6245ca3bf068
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>
Some old code has too many conflicts with the upstream code,
so recombine and commit these changes.
Including these changes:
1.Support yuv420.
2.Limit rk3229/rk3328 max output resolution.
3.Support dynamically get input/out color info.
4.Introduce mpll_cfg_420.
5.use drm_mode_is_420 instead of DRM_MODE_FLAG_420_MASK.
Change-Id: I42462284b16f26b7adef0e9455903ee5fc71e432
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
VOP output mode and bus_format must be ROCKCHIP_OUT_MODE_YUV420
and MEDIA_BUS_FMT_YUV8_1X24 when display mode has a YCbCr420
flag.
Change-Id: Ib2d51c119f5a8f1b8a9285c47ab228b22a293d56
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
If sink max TMDS clock < 340MHz, we think the mode pixel clock
greater than 340MHz should support YCbCr420, or it is a bad mode.
Change-Id: I3930e943f5bdf7ca86b3e719c55e6aa57e8eff53
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Clock slop is a solution for rk3288, not suitable for rk3399,
after use crtc mode_valid, we can remove the clock slop.
Change-Id: I68121505dfb7e65bf09c26d51c23edc909bdb517
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Algea Cao <algea.cao@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>
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
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>
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/)
4.4 kernel inno hdmi phy name is "hdmi_phy".
4.19 kernel inno hdmi phy name is "hdmi".
Change-Id: Ie87aa205c89154b417887a84703ce7bd9ffb2c7f
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
Tao Huang