According to the dw-hdmi spec, colorspace in bits 0,1,7,
scan_mode in bits 4,5.
Change-Id: I45233316ea7d5ce75d3844c183654f161cbf505e
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
HDMI 2.0 introduces a new sampling mode called YCbCr 4:2:0.
According to the spec the EDID may contain two blocks that
signal this sampling mode:
- YCbCr 4:2:0 Video Data Block
- YCbCr 4:2:0 Video Capability Map Data Block
The video data block contains the list of vic's were
only YCbCr 4:2:0 sampling mode shall be used while the
video capability map data block contains a mask were
YCbCr 4:2:0 sampling mode may be used.
This RFC patch adds support for parsing these two new blocks
and introduces new flags to signal the drivers if the
mode is 4:2:0'only or 4:2:0'able.
The reason this is still a RFC is because there is no
reference in kernel for this new sampling mode (specially in
AVI infoframe part), so, I was hoping to hear some feedback
first.
Tested in a HDMI 2.0 compliance scenario.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Cc: Carlos Palminha <palminha@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
(am from https://patchwork.kernel.org/patch/9495175)
Change-Id: I7c9e331b5bf5f1fbcefd4368bc4b82ff180eb91e
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
CEA-861-F specs defines new 4k video modes to be used with
HDMI 2.0 EDIDs. These modes start at VIC=93 and go all the
way till VIC=107.
Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now
to be able to parse 4k modes using the existing techniques, we have
to complete the modedb (VIC=65 onwards).
This patch adds:
- Timings for existing CEA video modes (from VIC=65 till VIC=92)
- Newly added 4k modes (from VIC=93 to VIC=107).
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
V2: Addressed review comments from Jose:
- fix the timings for VIC 83, 90 and 91
- fix formatting for VIC 93-107
V3: Rebase on drm-tip
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
(am from https://patchwork.kernel.org/patch/9543865/)
Change-Id: I3708db9a06a1d57c4714aed67fb7ef3711ea0d1e
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
Add a dummy entry to CEA/HDMI mode tables so they can be indexed
directly using the VIC, avoiding a +1/-1 dance here and there. This adds
clarity to the error checking for various functions that return the VIC
on success and zero on failure; we can now explicitly check for 0
instead of just subtracting one from an unsigned type.
Also add drm_valid_cea_vic() and drm_valid_hdmi_vic() helpers for
checking valid VICs.
v2: add drm_valid_cea_vic and drm_valid_hdmi_vic helpers (Ville)
use { } instead of { 0 } for initializing the dummy modes
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452252111-6439-1-git-send-email-jani.nikula@intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Change-Id: Id47deb7a806b896c047317ca8924ef73abb01095
(cherry picked from commit d9278b4c2c)
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
Rather than using drm_match_cea_mode() to see if the EDID detailed
timings are supposed to represent one of the CEA/HDMI modes, add a
special version of that function that takes in an explicit clock
tolerance value (in kHz). When looking at the detailed timings specify
the tolerance as 5kHz due to the 10kHz clock resolution limit inherent
in detailed timings.
drm_match_cea_mode() uses the normal KHZ2PICOS() matching of clocks,
which only allows smaller errors for lower clocks (eg. for 25200 it
won't allow any error) and a bigger error for higher clocks (eg. for
297000 it actually matches 296913-297000). So it doesn't really match
what we want for the fixup. Using the explicit +-5kHz is much better
for this use case.
Not sure if we should change the normal mode matching to also use
something else besides KHZ2PICOS() since it allows a different
proportion of error depending on the clock. I believe VESA CVT
allows a maximum deviation of .5%, so using that for normal mode
matching might be a good idea?
Change-Id: I824ec50368ddf152c9daa747ba92aaba1ef50f4b
Cc: Adam Jackson <ajax@redhat.com>
Tested-by: nathan.d.ciobanu@linux.intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92217
Fixes: fa3a7340ea ("drm/edid: Fix up clock for CEA/HDMI modes specified via detailed timings")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 4c6bcf4454)
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
This patch do the following operation with scdc:
1、TMDS Configuration
set TMDS_Bit_Clock_Ratio bit when supports TMDS Bit Rates
above 3.4 Gbps
(details see HDMI2.0 Specification Section 6.1.3.2)
2、Scrambling Control
set Scrambling_Enable bit when it needs.
(details see HDMI2.0 Specification Section 6.1.3.1)
Change-Id: Ibd4428bdf752d767caf9dd4e03f3c8d240f18f6b
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
Adds parsing for HDMI 2.0 'HDMI Forum Vendor
Specific Data Block'. This block is present in
some HDMI 2.0 EDID's and gives information about
scrambling support, SCDC, 3D Views, and others.
Parsed parameters are stored in drm_connector
structure.
(am from: https://patchwork.kernel.org/patch/9273645)
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Change-Id: I5a1485b79a407fd27ac4754827de318175bb8f6a
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.
This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.
(am from: https://patchwork.kernel.org/patch/7258251/)
Change-Id: I378bc2b465a720ccfede35a93bce0d9371e78f78
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Nickey Yang <nickey.yang@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>
If DP and HDMI are enabled at the same board, they will be
register switchdev with the same name in the same directory.
This would cause register switchdev fail.
Resulting in the following error:
[ 0.882415] [<ffffff8008212044>] sysfs_warn_dup+0x60/0x7c
[ 0.882424] [<ffffff800821212c>] sysfs_create_dir_ns+0x74/0x94
[ 0.882436] [<ffffff8008359fc0>] kobject_add_internal+0xc8/0x290
[ 0.882446] [<ffffff800835a428>] kobject_add+0xe0/0x10c
[ 0.882454] [<ffffff80084c2874>] device_add+0xec/0x508
[ 0.882462] [<ffffff80084c2e3c>] device_create_groups_vargs+0xb4/0xf8
[ 0.882471] [<ffffff80084c2eac>] device_create_vargs+0x2c/0x34
[ 0.882479] [<ffffff80084c2f14>] device_create+0x60/0x80
[ 0.882491] [<ffffff80087248bc>] switch_dev_register+0x8c/0x120
[ 0.882502] [<ffffff80084709ec>] cdn_dp_bind+0x4c4/0x644
[ 0.882511] [<ffffff80084c091c>] component_bind_all+0x94/0x1c0
[ 0.882523] [<ffffff8008478550>] rockchip_drm_bind+0x1c4/0xb54
[ 0.882533] [<ffffff80084c0554>] try_to_bring_up_master.part.3+0xac/0x114
[ 0.882542] [<ffffff80084c0780>] component_add+0x88/0xf8
[ 0.882550] [<ffffff8008470504>] cdn_dp_probe+0x140/0x164
[ 0.882559] [<ffffff80084c71f8>] platform_drv_probe+0x58/0xa4
[ 0.882568] [<ffffff80084c5498>] driver_probe_device+0x118/0x2ac
[ 0.882576] [<ffffff80084c5778>] __device_attach_driver+0x88/0x98
[ 0.882584] [<ffffff80084c38a0>] bus_for_each_drv+0x7c/0xac
[ 0.882592] [<ffffff80084c52cc>] __device_attach+0xa4/0x124
[ 0.882600] [<ffffff80084c58e4>] device_initial_probe+0x10/0x18
[ 0.882609] [<ffffff80084c4924>] bus_probe_device+0x2c/0x8c
[ 0.882617] [<ffffff80084c4da0>] deferred_probe_work_func+0x74/0xa0
[ 0.882628] [<ffffff80080b2b38>] process_one_work+0x218/0x3e0
[ 0.882636] [<ffffff80080b3538>] worker_thread+0x2e8/0x404
[ 0.882644] [<ffffff80080b7e70>] kthread+0xe8/0xf0
[ 0.882653] [<ffffff8008082690>] ret_from_fork+0x10/0x40
[ 0.882675] kobject_add_internal failed for hdmi with -EEXIST, don't try to
register things with the same name in the same directory.
Change-Id: I0c1b175a2483d5524d9cc0e5261d332c5ad286c8
Signed-off-by: Bin Yang <yangbin@rock-chips.com>
Along with a slight modification in mali_kbase_core_linux.c,
for building in rk Linux 4.4:
-#if KERNEL_VERSION(4, 6, 0) > LINUX_VERSION_CODE
+#if KERNEL_VERSION(4, 4, 0) > LINUX_VERSION_CODE
Change-Id: I34565cb975866b46c5e3a4d8e2ac5e350dcceb80
Signed-off-by: chenzhen <chenzhen@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>
