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>
Make $(src) as absolute path if it isn't already, by prefixing $(srctree).
Fix build module with "O=dir".
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I50a809faee21afd66d8f2025d05602a8a85293df
Make $(src) as absolute path if it isn't already, by prefixing $(srctree).
Fix build module with "O=dir".
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: I4e6d1f252e51956dc264e544ebbf7cf774a39c5d
ARM32 system can run without trustos,
we should prevent arm_smccc_smc being called in such system.
Change-Id: Ic87b78107b464e3ab8dc72a3ca1fa9a64e358580
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
On rk3368, let a mcu scaling ddr clock via SCPI (System Control and
Power Interface) APIs.
Change-Id: I95342b876caad991e6d1319c5e4ec793365c7981
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Allow a user to write pwm oneshot_count value. If oneshot_count == 0,
the pwm works in continuous mode. If 0 < oneshot_count < 256, the
pwm works in oneshot mode.
Signed-off-by: Steven Liu <steven.liu@rock-chips.com>
Change-Id: Icbcea85dc1d625a4ac24fee4ab07f1e2421bde77
The oneshot_count value should be less than PWM_ONESHOT_COUNT_MAX.
If oneshot_count == 0, this pwm channel works in continuous mode.
Signed-off-by: Steven Liu <steven.liu@rock-chips.com>
Change-Id: I45857fb5762e0365cce5278502479c580638e40c
In file included from drivers/video/rockchip/mpp/mpp_iommu.c:12:
./arch/arm/include/asm/dma-iommu.h:27:33: warning: declaration of
'struct bus_type' will not be visible outside of this function [-Wvisibility]
arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, u64 size);
Signed-off-by: Tao Huang <huangtao@rock-chips.com>
Change-Id: Ieac6a2ab326a62fbb6831643519d55ab532ec3e9
This commit must be updated when using im2d api.
Signed-off-by: Yu Qiaowei <cerf.yu@rock-chips.com>
Change-Id: I0cd8e53323f45c3410703f149587ea884cdbe624
Most SOCS have only 8 or 6 channels, but have more than 16
peripherals. If those peripherals work together, some
fails to request dma channel, because there are no enough
channels. And maybe it's unnecessary to use dma for uart
tx. It is necessary for uart rx when hardware auto flow
control is not used.
&uart0 {
dma-names = "!tx", "rx"; // disable uart tx with dma
status = "okay";
};
Change-Id: Ia74477514ba57300a4d19a5c2565ae7b5b8ab521
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>
To avoid "too much work for irq" issue, cherry pick the patch.
It reads the RBR to clear the time out interrupt, but sometime the
rx fifo may be not empty while cpu reads the RBR. Which would cause
the data lost.
patch for "too much work":06451e93ab59e5b1843c29cbb468a274f4919563
By the way, current patch can't get rid of the risk entirely, so I
try a lot to solve it. Unfortunately, I only got the phenomenon that
lower pclk can reduce the probability. And I check the dw data sheet,
it has pclk and sclk, so there is synchronization problem. But it
only requires (slck < 4*pclk).
Change-Id: I01a36c689b43310294c45294abcf4982f5ddf2af
Signed-off-by: Huibin Hong <huibin.hong@rock-chips.com>
