Since msleep is based on jiffies the panel could take longer
than expected. So use msleep for values greater than 20 msec
otherwise usleep_range.
Change-Id: Ib03c6e381b44a31dd57aeaaa3a88a459578de313
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
This patch adds a new RGB media bus formats that describe
18-bit samples transferred over an LVDS bus with three
differential data pairs, serialized into 7 time slots,
using standard JEIDA data ordering.
Change-Id: Ia0bedd53e57aa34829a0d61b144aa99a1c98cffd
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
When enable display on loader, init gpio would change
gpio status, that would make screen flash.
Change-Id: I4b69a8d3d83c5bef09014c2134abaee6522a7046
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
Signed-off-by: Sandy Huang <hjc@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>
iommu driver probe will register vop pd to power domain control, this pd
will be closed before display driver enable and lead to display black.
so we move vop pd to display driver control.
Change-Id: Ie25c20e79c57c4e1bc678774ad09b60fc4a135da
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
I found if eDP_AVDD_1V0 and eDP_AVDD_1V8 are not been power at
RK3288, once trying to enable the pclk clock, the kernel would dead.
This patch would try to enable them first.
The eDP_AVDD_1V8 is used for eDP phy, and the eDP_AVDD_1V0 are used
both for eDP phy and controller.
Change-Id: I4e8a34609d5b292d7da77385ff15bebbf258090c
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Randy Li <randy.li@rock-chips.com>
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Add the ability to parse panel-desc data from the devicetree if it's
not hard-coded data.
Change-Id: I474940282657c9aa03568b9f98916125784d9fcf
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
The video BIST function of the DP_TX generates arbitrary video formats
internally according to the specified format configuration and selection.
These BIST video formats simplify DP_TX debugging.
Change-Id: Ia019c8f40fdd4ebea3e5250be8e2c15540481a6c
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Sometimes, we would abort suspend work before it finished.
In this case, suspend work would try to resume the part suspended
by correspond resume functions.
But the suspend/resume functions are not matched in rockchip.
When the suspend work is aborted, it would ignored resuming this
part due to can't find correspond resume functions.
So, let's use suspend_late instead of suspend.
Change-Id: I7304f7963704de7e870fbd4e76ebe1e0066f18c1
Signed-off-by: zain wang <wzz@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>
The current EDID might not support advanced HDMI 2.0 features.
Leaving old hdmi info in the drm_display_info will make display
work not okay, when switching display from HDMI 2.0 device to
HDMI 1.4 device.
Change-Id: Ifaf11a115580a93ec00160d54f0d453842d7b484
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
close pd when suspend, no when plug out because hotplug detect need it.
make hdmi probe before dp otherwise the shared power domain will be
close after dp probe and cause splash screen when starting kernel if
hdmi uboot logo display
Change-Id: I82ba1abdaf7567173df9ad900d57eca0e6be3932
Signed-off-by: xuhuicong <xhc@rock-chips.com>
HDMI PD is power off when system suspend, so ih_mute register
bit0 mute_all_interrupt will be reset to 1 when system resume.
HPD interrupt will be mask, that would cause hdmi plugin could
not be detected.
Change-Id: I3bf2e6116e902cd516a7ac69fbe8569ca943e853
Signed-off-by: Bin Yang <yangbin@rock-chips.com>
adjusted_mode.crtc_clock is the real pixel clock rate.
Change-Id: Iac242b89e3144bc53c40170c2cec0c0913ef6ee0
Signed-off-by: Zheng Yang <zhengyang@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>
The pixel clock of 4K@60Hz is 594MHz, let's enable it for HDMI.
Change-Id: I6097c8a452ba8259c1d8d01fb793cd7cc55cafb3
Signed-off-by: Yakir Yang <ykk@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>
