- 14 Jul, 2017 11 commits
-
-
Shashank Sharma authored
CEA-861-F introduces extended tag codes for EDID extension blocks, which indicates the actual type of the data block. The code for using exteded tag is 0x7, whereas in the existing code, the corresponding macro is named as "VIDEO_CAPABILITY_BLOCK" This patch renames the macro and usages from "VIDEO_CAPABILITY_BLOCK" to "USE_EXTENDED_TAG" V2: Add extended tag code check for video capabilitiy block (ville) V3: Ville: - Use suggested names for macros - Check the block length first, before checking the extended tag V4: Fix commit message (David) V5: Introduced this patch into HDMI-YCBCR-output series V6: Rebase V7: Rebase Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-5-git-send-email-shashank.sharma@intel.comSigned-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Shashank Sharma authored
CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks. This block contains a map of indexes of CEA modes, which can support YCBCR 420 output also. To avoid multiple parsing of same CEA block, let's parse the sink information and get this map, before parsing CEA modes. This patch moves the call to drm_add_display_info function, before the mode parsing block. V4: Introduced new patch in the series V5: Move this patch before 4:2:0 parsing patch (ville) Added r-b from Ville V6: Rebase V7: Rebase Reviewed-by: -
Shashank Sharma authored
CEA-861-F specs defines new video modes to be used with HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to 1-107. Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now to be able to parse new CEA modes using the existing methods, 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). The patch was originaly discussed and reviewed here: https://patchwork.freedesktop.org/patch/135810/ Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> V2: Rebase V3: Rebase V4: Added native bit handling as per CEA-861-F spec (Ville) V5: Fix timings for VIC 77:1920x1080 and 104:3840x2160p (Ville) Remove unnecessary paranthesis from function svd_to_vic (Ville) Added r-b (Neil) V6: Rebase V7: Fix indentation for modes from VIC 80 Reviewed-by:
Jose Abreu <Jose.Abreu@synopsys.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Neil Armstrong <narmstrong@baylibre.com> Acked-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
-
Shashank Sharma authored
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is extended to (VIC 1-107). This patch adds a bool input variable, which indicates if the connected sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a HDMI 2.0 VIC to a HDMI 1.4 sink. This patch touches all drm drivers, who are callers of this function drm_hdmi_avi_infoframe_from_display_mode but to make sure there is no change in current behavior, is_hdmi2 is kept as false. In case of I915 driver, this patch: - checks if the connected display is HDMI 2.0. - HDMI infoframes carry one of this two type of information: - VIC for 4K modes for HDMI 1.4 sinks - S3D information for S3D modes As CEA-861-F has already defined VICs for 4K videomodes, this patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks, until the mode is 3D. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jose Abreu <jose.abreu@synopsys.com> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Daniel Vetter <daniel.vetter@intel.com> PS: This patch touches a few lines in few files, which were already above 80 char, so checkpatch gives 80 char warning again. - gpu/drm/omapdrm/omap_encoder.c - gpu/drm/i915/intel_sdvo.c V2: Rebase, Added r-b from Andrzej V3: Addressed review comment from Ville: - Do not send VICs in both AVI-IF and HDMI-IF send only one of it. V4: Rebase V5: Added r-b from Neil. Addressed review comments from Ville - Do not block HDMI vendor IF, instead check for VIC while handling AVI infoframes V6: Rebase V7: Rebase Reviewed-by:Andrzej Hajda <a.hajda@samsung.com> Reviewed-by:
-
Noralf Trønnes authored
This adds support for the Pervasive Displays RePaper branded displays. The controller code is taken from the userspace driver available through repaper.org. Only the V231 film is supported since the others are EOL. Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/1496934875-51984-5-git-send-email-noralf@tronnes.org
-
Noralf Trønnes authored
Drm has no monochrome or greyscale support so add a conversion from the common format XR24. Also reorder includes into the common order. Acked-by:
-
Noralf Trønnes authored
Add device-tree binding documentation for the 1.44", 1.9", 2.0" and 2.7" display panels. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Noralf Trønnes authored
Pervasive Displays Inc. designs, develops, and manufactures low-power electrophoretic (e-ink) display modules and supporting electronics for commercial and industrial display applications. Acked-by:
-
Peter Rosin authored
The legacy path implements setcmap in terms of crtc .gamma_set. The atomic path implements setcmap by directly updating the crtc gamma_lut property. This has a couple of benefits: - it makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get completely obsolete. They are now unused and subject for removal. - atomic drivers that support clut modes get fbdev support for those from the drm core. This includes atmel-hlcdc, but perhaps others as well? Signed-off-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
-
Peter Rosin authored
Do not waste cycles looking up the property id when we have the actual property already. Signed-off-by:
-
Peter Rosin authored
The function has little to do with atomic, it's just where it has so far been needed. So, rename it to drm_property_replace_blob, move it to drm_property.c and export it. Change the semantics to return whether the blob was replaced instead of using an extra argument for that. Signed-off-by:
-
- 13 Jul, 2017 15 commits
-
-
Ville Syrjälä authored
We have memch_inv(), so no need to memcmp() against a zeroed temp array. Signed-off-by:
-
Ville Syrjälä authored
Make the atomic private object stuff less special by introducing proper base classes for the object and its state. Drivers can embed these in their own appropriate objects, after which these things will work exactly like the plane/crtc/connector states during atomic operations. v2: Reorder to not depend on drm_dynarray (Daniel) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> #v1 Signed-off-by:
-
Ville Syrjälä authored
We will never add private objects with a NULL state into the atomic state, hence checking for that is pointless. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
Ville Syrjälä authored
On failure drm_atomic_get_private_obj_state() returns and error pointer instead of NULL. Adjust the checks in the callers to match. Cc: stable@vger.kernel.org Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: edb1ed1a ("drm/dp: Add DP MST helpers to atomically find and release vcpi slots") Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
-
Maarten Lankhorst authored
for_each_obj_in_state is about to be removed, so use the new atomic iterator macros. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Link: http://patchwork.freedesktop.org/patch/msgid/20170712081344.25495-14-maarten.lankhorst@linux.intel.comReviewed-by:
Philipp Zabel <p.zabel@pengutronix.de>
-
Maarten Lankhorst authored
for_each_obj_in_state is about to be removed, so use the new atomic iterator macros. Signed-off-by:
-
Maarten Lankhorst authored
for_each_obj_in_state is about to be removed, so use the new iterator macros. Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com>
-
Maarten Lankhorst authored
for_each_obj_in_state is about to be removed, so use the new atomic iterator macros. Signed-off-by:
Mark Yao <mark.yao@rock-chips.com>
-
Maarten Lankhorst authored
for_each_obj_in_state is about to be removed, so use the new iterator macros. Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com>
-
Maarten Lankhorst authored
for_each_connector_in_state will be removed, so use the right state here. Signed-off-by:
-
Maarten Lankhorst authored
I don't think the checking of resources in this function is very atomic-like, but it should definitely not use a macro that's about to be removed. Signed-off-by:
Sinclair Yeh <syeh@vmware.com> Reviewed-by:
-
Maarten Lankhorst authored
for_each_obj_in_state is about to be removed, so use the correct new iterator macro. Signed-off-by:
-
Maarten Lankhorst authored
for_each_obj_in_state will be removed, so don't use it here. Signed-off-by:
-
Maarten Lankhorst authored
for_each_obj_in_state will be removed, so use the new state here. Signed-off-by:
-
Maarten Lankhorst authored
You can enable the CRTC and without adding the plane to the state and it will succeed. This should be prevented in the crtc check instead of the plane check, because the plane check may never run for atomic enable, but the crtc check always will. This is based on a similar check in vmwgfx. Signed-off-by:
-
- 11 Jul, 2017 1 commit
-
-
Alexandru Moise authored
If the DRM core fails to init for whatever reason, ensure that no driver ever calls drm_dev_register(). This is best done at drm_dev_init() as it covers drivers that call drm_dev_alloc() as well as drivers that prefer to embed struct drm_device into their own device struct and call drm_dev_init() themselves. In my case I had so many dynamic device majors used that the major number for DRM (226) was stolen, causing DRM core init to fail after failing to register a chrdev, and ultimately calling debugfs_remove() on drm_debugfs_root in drm_core_exit(). After drm core failed to init, VGEM was still calling drm_dev_register(), ultimately leading to drm_debugfs_init(), with drm_debugfs_root passed as the root for the new debugfs dir at debugfs_create_dir(). This led to a kernel panic once we were either derefencing root->d_inode while it was NULL or calling root->d_inode->i_op->lookup() while it was NULL in debugfs at inode_lock() or lookup_*(). Signed-off-by:
Alexandru Moise <00moses.alexander00@gmail.com> Signed-off-by:
-
- 06 Jul, 2017 13 commits
-
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
Inki Dae <inki.dae@samsung.com> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1499071350-25168-12-git-send-email-inki.dae@samsung.com
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Inki Dae authored
This patch removes unnecessary checking of return value. Signed-off-by:
-
Peter Rosin authored
drm_fb_helper_save_lut_atomic is redundant since the .gamma_store is now always kept up to date by drm_fb_helper_setcmap. Signed-off-by:
-
Peter Rosin authored
I think the gamma_store can end up invalid on error. But the way I read it, that can happen in drm_mode_gamma_set_ioctl as well, so why should this pesky legacy fbdev stuff be any better? Signed-off-by:
-
Peter Rosin authored
The pseudo-palette has nothing to do with the crtc, so move it out of the crtc loop and update the palette once, then break out early. Signed-off-by:
Peter Rosin <peda@axenita.se> Signed-off-by:
-
