- 18 Jul, 2017 6 commits
-
-
Daniel Vetter authored
CMA helpers are struct_mutex free, and so is the pl111 itself. And that's the only valid reason for using gem_free_object. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Eric Anholt <eric@anholt.net> Reviewed-by:
Eric Anholt <eric@anholt.net> Link: https://patchwork.freedesktop.org/patch/msgid/20170717151045.4188-2-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
CMA helpers are struct_mutex free, and so is the mxsfb itself. And that's the only valid reason for using gem_free_object. Reviewed-by:
-
Philippe CORNU authored
Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs. Signed-off-by:
Philippe CORNU <philippe.cornu@st.com> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/1500277223-29553-5-git-send-email-philippe.cornu@st.com
-
Philippe CORNU authored
This patch adds documentation of device tree bindings for the Synopsys DesignWare MIPI DSI host controller. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Philippe CORNU authored
Add the panel-bridge support for both panels & bridges (used by DSI host & HDMI/LVDS bridges). Signed-off-by:
-
Philippe CORNU authored
The pixel clock gets enabled early during init, since it's required in order to read registers. This pixel clock must be disabled if errors during this init phase. Signed-off-by:
-
- 17 Jul, 2017 3 commits
-
-
Brian Norris authored
DRM drivers should supply a compat version if they're going to provide an ioctl implementation at all. This can confuse 32-bit user space on a 64-bit system. Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170715031212.108695-1-briannorris@chromium.org
-
Maarten Lankhorst authored
Commit e8fa5671 ("drm: crc: Wait for a frame before returning from open()") adds a wait for CRC frame, but with the CRTC off this will never be generated. For atomic drivers we know if a CRTC is active through crtc_state->active, so when inactive reject the open with -EIO. Just like with the previous patch changing debugfs opening semantics, this patch has been tested against igt. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: e8fa5671 ("drm: crc: Wait for a frame before returning from open()") Testcase: debugfs_test.read_all_entries Link: http://patchwork.freedesktop.org/patch/msgid/15f9d300-65d3-63aa-00e3-e83f5e4d5a7a@linux.intel.comReviewed-by:
-
Maarten Lankhorst authored
When I was doing a grep . -r /sys/kernel/debug/dri/0 I noticed a WARN appearing when I aborted the grep with ^C. After investigating I've also noticed that the error handling was lacking and there are race conditions involving multiple calls to open/close simultaneously. Fix this by setting the opened flag first and using crc->entries to decide when crc can be collected. Also call unset crc source before cleaning up, this way there is no race with a future open(). This patch has been tested with all the tests in igt with CRC in their name. Signed-off-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> [mlankhorst: Add description that this patch has been tested with IGT, based on tomeu's feedback]
-
- 14 Jul, 2017 17 commits
-
-
Eric Anholt authored
The logic was all right in the end, the name was just backwards. Signed-off-by:
Andrzej Hajda <a.hajda@samsung.com>
-
Eric Anholt authored
The DPHY spec requires a much larger T_INIT than I was specifying before. In the absence of clear specs from the slave of what their timing is, just use the value that the firmware was using. Signed-off-by:
-
Shashank Sharma authored
This patch adds helper functions for YCBCR 420 handling. These functions do: - check if a given video mode is YCBCR 420 only mode. - check if a given video mode is YCBCR 420 also mode. V2: Added YCBCR functions as helpers in DRM layer, instead of keeping it in I915 layer. V3: Added handling for YCBCR-420 only modes too. V4: EXPORT_SYMBOL(drm_find_hdmi_output_type) V5: Addressed review comments from Danvet: - %s/drm_find_hdmi_output_type/drm_display_info_hdmi_output_type - %s/drm_can_support_ycbcr_output/drm_display_supports_ycbcr_output - %s/drm_can_support_this_ycbcr_output/ drm_display_supports_this_ycbcr_output - pass drm_display_info instead of drm_connector for consistency - For drm_get_highest_quality_ycbcr_supported doc, move the variable description above, and then the function description. V6: Add only YCBCR420 helpers (Ville) V7: Addressed review comments from Ville - Remove cea_vic_valid() check. - Fix indentation. - Make input parameters to helpers, const. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jose Abreu <Jose.Abreu@synopsys.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:Shashank Sharma <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-9-git-send-email-shashank.sharma@intel.com [vsyrjala: Fix sparse indentation warn] Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Shashank Sharma authored
CEA-861-F spec adds ycbcr420 deep color support information in hf-vsdb block. This patch extends the existing hf-vsdb parsing function by adding parsing of ycbcr420 deep color support from the EDID and adding it into display information stored. V2: Rebase V3: Rebase V4: Moved definition of y420_dc_modes into this patch, where its used (Ville) V5: Optimize function, if(conditions) not reqd (Ville) V6: Rebase V7: Rebase Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jose Abreu <joabreu@synopsys.com> Signed-off-by: -
Shashank Sharma authored
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output. CEA-861-F adds two new blocks in EDID's CEA extension blocks, to provide information about sink's YCBCR420 output capabilities. These blocks are: - YCBCR420vdb(YCBCR 420 video data block): This block contains VICs of video modes, which can be sopported only in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal SVD block, valid for YCBCR420 modes only. - YCBCR420cmdb(YCBCR 420 capability map data block): This block gives information about video modes which can support YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This block contains a bitmap index of normal svd videomodes, which can support YCBCR420 output too. So if bit 0 from first vcb byte is set, first video mode in the svd list can support YCBCR420 output too. Bit 1 means second video mode from svd list can support YCBCR420 output too, and so on. This patch adds two bitmaps in display's hdmi_info structure, one each for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch adds: - VDB modes (YCBCR 420 only modes) in connector's mode list, also makes an entry in the vdb_bitmap per vic. - VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jose Abreu <joabreu@synopsys.com> Cc: Emil Velikov <emil.l.velikov@gmail.com> V2: Addressed Review comments from Emil: - Use 1ULL<<i instead of 1<<i to make sure the output is 64bit. - Use the suggested method for updating dbmap. - Add documentation for YCBCR420_vcb_map to fix kbuild warning. Review comments from Ville: - Do not expose the YCBCR420 flags in uabi layer, keep it internal. - Save a map of YCBCR420 modes for future reference. - Check db length before trying to parse extended tag. - Add a warning if there are > 64 modes in capability map block. - Use y420cmdb in function names and macros while dealing with vcb to be aligned with spec. - Move the display information parsing block ahead of mode parsing blocks. V3: Addressed design/review comments from Ville - Do not add flags in video modes, else we have to expose them to user - There should not be a UABI change, and kernel should detect the choice of the output based on type of mode, and the bitmaps. - Use standard bitops from kernel bitmap header, instead of calculating bit positions manually. V4: Addressed review comments from Ville: - s/ycbcr_420_vdb/y420vdb - s/ycbcr_420_vcb/y420cmdb - Be less verbose on description of do_y420vdb_modes - Move newmode variable in the loop scope. - Use svd_to_vic() to get a VIC, instead of 0x7f - Remove bitmap description for CMDB modes & VDB modes - Dont add connector->ycbcr_420_allowed check for cmdb modes - Remove 'len' variable, in is_y420cmdb function, which is used only once - Add length check in is_y420vdb function - Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap - Do not add print about YCBCR 420 modes - Fix indentation in few places - Move ycbcr420_dc_modes in next patch, where its used - Add a separate patch for movement of drm_add_display_info() V5: Addressed review comments from Ville: - Add the patch which cleans up the current EXTENDED_TAG usage - Make y420_cmdb_map u64 - Do not block ycbcr420 modes while parsing the EDID, rather add a separate helper function to prune ycbcr420-only modes from connector's probed modes. V6: Rebase V7: Move this patch after the 420_only validation patch (Ville) V8: Addressed review comments from Ville - use cea_vic_valid check before adding cmdb/vdb modes - add check for i < 64 while adding cmdb modes - use 1ULL while checking bitmap Signed-off-by: -
Shashank Sharma authored
YCBCR420 modes are supported only on HDMI 2.0 capable sources. This patch adds: - A drm helper to validate YCBCR420-only mode on a particular connector. This function will help pruning the YCBCR420-only modes from the connector's modelist. - A bool variable (ycbcr_420_allowed) in the drm connector structure. While handling the EDID from HDMI 2.0 sinks, its important to know if the source is capable of handling YCBCR420 output, so that no YCBCR 420 modes will be listed for sources which can't handle it. A driver should set this variable if it wants to see YCBCR420 modes in the modedb. V5: Introduced the patch in series. V6: Squashed two patches (validate YCBCR420 and add YCBCR420 identifier) V7: Addressed review comments from Vile: - Move this patch before we add 420 modes from EDID. - No need for drm_valid_cea_vic() check, function back to non-static. - Update MODE_STATUS with NO_420 condition. - Introduce y420_vdb_modes variable in this patch Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: -
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 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: -
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:
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:
-
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 14 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:
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:
-
