summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2017-07-26drm/tilcdc: Handle drm_atomic_helper_swap_state failureMaarten Lankhorst1-1/+5
drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Jyri Sarha <jsarha@ti.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-10-maarten.lankhorst@linux.intel.com Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm/tegra: Handle drm_atomic_helper_swap_state failureMaarten Lankhorst1-1/+6
drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Jonathan Hunter <jonathanh@nvidia.com> Cc: linux-tegra@vger.kernel.org Link: http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-9-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm/msm: Handle drm_atomic_helper_swap_state failureMaarten Lankhorst1-8/+8
drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. MSM has its own busy tracking, which means the swap_state call can be done with stall = false, in which case it should never return an error. Handle failure with BUG_ON for this reason. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Link: http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-8-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Sean Paul <seanpaul@chromium.org> Tested-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm/mediatek: Handle drm_atomic_helper_swap_state failureMaarten Lankhorst1-1/+6
drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. 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: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Link: http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-7-maarten.lankhorst@linux.intel.com Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm/i915: Handle drm_atomic_helper_swap_state failureMaarten Lankhorst1-1/+9
drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-6-maarten.lankhorst@linux.intel.com Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm/atmel-hlcdc: Handle drm_atomic_helper_swap_state failureMaarten Lankhorst1-6/+7
drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Atmel tracks pending commits through dc->commit.pending, so it can ignore the changes by setting stall = false. We never return failure in this case, so make failure a BUG_ON. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-5-maarten.lankhorst@linux.intel.com Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm/nouveau: Handle drm_atomic_helper_swap_state failureMaarten Lankhorst1-1/+4
drm_atomic_helper_swap_state() will be changed to interruptible waiting in the next few commits, so all drivers have to be changed to handling failure. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Link: http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-4-maarten.lankhorst@linux.intel.com Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm/atomic: Change drm_atomic_helper_swap_state to return an error.Maarten Lankhorst2-10/+19
We want to change swap_state to wait indefinitely, but to do this swap_state should wait interruptibly. This requires propagating the error to each driver. Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-3-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> [mlankhorst: Fix typos in swap_state documentation (seanpaul)] Reviewed-by: Sean Paul <seanpaul@chromium.org>] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm/nouveau: Fix error handling in nv50_disp_atomic_commitMaarten Lankhorst1-2/+5
Make it more clear that post commit return ret is really return 0, and add a missing drm_atomic_helper_cleanup_planes when drm_atomic_helper_wait_for_fences fails. Fixes: 839ca903f12e ("drm/nouveau/kms/nv50: transition to atomic interfaces internally") Cc: Ben Skeggs <bskeggs@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.10+ Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170711143314.2148-2-maarten.lankhorst@linux.intel.com Reviewed-by: Sean Paul <seanpaul@chromium.org> [mlankhorst: Use if (ret) to remove the goto in success case.] Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm/<drivers>: Drop fbdev info flagsDaniel Vetter15-15/+0
- FBINFO_CAN_FORCE_OUTPUT has been a lie ever since we nerfed&removed the entire panic handling code in our fbdev emulation. We might restore kms panic output, but not through the bazillion of legacy code layers called fbdev/fbcon, there's just no way to make that work safely. - With the module check change FBINFO_DEFAULT is always 0, so can be removed too. That removes another change to cargo-cult stuff in kms drivers, yay! Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170706125735.28299-5-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm/qxl: Drop fbdev hwaccel flagsDaniel Vetter1-1/+1
It's not accelarated, just system memory. Note we don't even need to set the default flag since that's now always 0. Note that originally qxl had acceleration support, but that was all ripped out in commit c0fe07aa50befe2e6e6525181e2080377a1c1494 Author: Gerd Hoffmann <kraxel@redhat.com> Date: Tue May 5 13:52:49 2015 +0200 drm/qxl: rewrite framebuffer support v2: Amend commit message a bit after irc chat with Dave. Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: virtualization@lists.linux-foundation.org Acked-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170706125735.28299-4-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-26drm: Update docs around gem_free_objectDaniel Vetter2-2/+2
Not all places correctly stated that gem_free_object_unlocked is the one to use. Reported-by: Eric Anholt <eric@anholt.net Cc: Eric Anholt <eric@anholt.net Reviewed-by: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170718063337.31942-1-daniel.vetter@ffwll.ch Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-18drm: Don't complain too much about struct_mutex.Daniel Vetter1-4/+6
For modern drivers the DRM core doesn't use struct_mutex at all, which means it's defacto a driver-private lock. But since we still need it for legacy drivers we can't initialize it in drivers, which means all the different instances share one lockdep key. Despite that they might be placed in totally different places in the locking hierarchy. This results in a lot of bogus lockdep splats when running stuff on systems with multiple gpus. Partially remedy the situation by only doing might_lock checks on drivers that do use struct_mutex still for gem locking. A more complete solution would be to do the mutex_init in the drm core only for legacy drivers, plus add it to each modern driver that still needs it, which would also give each its own lockdep key. Trying to do that dynamically doesn't work, because lockdep requires it's keys to be statically allocated. v2: {} everywhere (Chris) Cc: Hans de Goede <hdegoede@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Jiri Slaby <jirislaby@gmail.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Ingo Molnar <mingo@redhat.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170715095328.25671-1-daniel.vetter@ffwll.ch
2017-07-18drm/zte: Use gem_free_object_unlockedDaniel Vetter1-1/+1
CMA helpers are struct_mutex free, and so is the zte itself. And that's the only valid reason for using gem_free_object. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Shawn Guo <shawnguo@kernel.org> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20170717151045.4188-3-daniel.vetter@ffwll.ch
2017-07-18drm/pl111: Use gem_free_object_unlockedDaniel Vetter1-1/+1
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
2017-07-18drm/mxsfb: Use gem_free_object_unlockedDaniel Vetter1-1/+1
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: Eric Anholt <eric@anholt.net> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Marek Vasut <marex@denx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20170717151045.4188-1-daniel.vetter@ffwll.ch
2017-07-18drm/bridge/synopsys: Add MIPI DSI host controller bridgePhilippe CORNU4-0/+1028
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
2017-07-18dt-bindings: display: Add Synopsys DW MIPI DSI host controllerPhilippe CORNU1-0/+32
This patch adds documentation of device tree bindings for the Synopsys DesignWare MIPI DSI host controller. Signed-off-by: Philippe CORNU <philippe.cornu@st.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/1500277223-29553-4-git-send-email-philippe.cornu@st.com
2017-07-18drm/stm: ltdc: Add panel-bridge supportPhilippe CORNU3-177/+38
Add the panel-bridge support for both panels & bridges (used by DSI host & HDMI/LVDS bridges). Signed-off-by: Philippe CORNU <philippe.cornu@st.com> Reviewed-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/1500277223-29553-3-git-send-email-philippe.cornu@st.com
2017-07-18drm/stm: ltdc: Fix leak of px clk enable in some error pathsPhilippe CORNU1-4/+6
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: Eric Anholt <eric@anholt.net> Acked-by: Philippe Cornu <philippe.cornu@st.com> Signed-off-by: Archit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/1500277223-29553-2-git-send-email-philippe.cornu@st.com
2017-07-17drm/vgem: add compat_ioctl supportBrian Norris1-0/+1
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
2017-07-17drm/crc: Only open CRC on atomic drivers when the CRTC is active.Maarten Lankhorst1-0/+13
Commit e8fa5671183c ("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: e8fa5671183c ("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.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-17drm/crc: Handle opening and closing crc betterMaarten Lankhorst1-15/+31
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: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170621110007.11674-1-maarten.lankhorst@linux.intel.com Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> [mlankhorst: Add description that this patch has been tested with IGT, based on tomeu's feedback]
2017-07-14drm/vc4: Fix misleading name of the continuous flag.Eric Anholt1-4/+4
The logic was all right in the end, the name was just backwards. Signed-off-by: Eric Anholt <eric@anholt.net> Link: http://patchwork.freedesktop.org/patch/msgid/20170627195839.3338-3-eric@anholt.net Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
2017-07-14drm/vc4: Fix DSI T_INIT timing.Eric Anholt1-1/+11
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: Eric Anholt <eric@anholt.net> Link: http://patchwork.freedesktop.org/patch/msgid/20170627195839.3338-2-eric@anholt.net Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
2017-07-14drm: add helper functions for YCBCR420 handlingShashank Sharma2-0/+64
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>
2017-07-14drm/edid: parse ycbcr 420 deep color informationShashank Sharma3-0/+23
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 <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-8-git-send-email-shashank.sharma@intel.com [vsyrjala: Fix sparse indentation warn] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-07-14drm/edid: parse YCBCR420 videomodes from EDIDShashank Sharma2-2/+162
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 <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1500028426-14883-1-git-send-email-shashank.sharma@intel.com [vsyrjala: Fix checkpatch complaints and indentation] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-07-14drm: add helper to validate YCBCR420 modesShashank Sharma4-0/+55
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 <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-6-git-send-email-shashank.sharma@intel.com [vsyrjala: Drop the now bogus EXPORT_SYMBOL(drm_valid_cea_vic)] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-07-14drm/edid: cleanup patch for CEA extended-tag macroShashank Sharma1-3/+12
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.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-07-14drm/edid: parse sink information before CEA blocksShashank Sharma1-2/+7
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-4-git-send-email-shashank.sharma@intel.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-07-14drm/edid: complete CEA modedb(VIC 1-107)Shashank Sharma1-1/+225
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 <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-3-git-send-email-shashank.sharma@intel.com [vsyrjala: Fix up remaining formatting/indentation issues] Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-07-14drm: handle HDMI 2.0 VICs in AVI info-framesShashank Sharma25-25/+57
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: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-2-git-send-email-shashank.sharma@intel.com Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-07-14drm/tinydrm: Add RePaper e-ink driverNoralf Trønnes4-0/+1114
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
2017-07-14drm/tinydrm: Add tinydrm_xrgb8888_to_gray8() helperNoralf Trønnes2-2/+73
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: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/1496934875-51984-4-git-send-email-noralf@tronnes.org
2017-07-14dt-bindings: Add Pervasive Displays RePaper bindingsNoralf Trønnes1-0/+52
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 <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/1496934875-51984-3-git-send-email-noralf@tronnes.org
2017-07-14of: Add vendor prefix for Pervasive DisplaysNoralf Trønnes1-0/+1
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: Rob Herring <robh@kernel.org> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: http://patchwork.freedesktop.org/patch/msgid/1496934875-51984-2-git-send-email-noralf@tronnes.org
2017-07-14drm/fb-helper: separate the fb_setcmap helper into atomic and legacy pathsPeter Rosin1-71/+160
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170713162538.22788-4-peda@axentia.se
2017-07-14drm/atomic-helper: update lut props directly in ..._legacy_gamma_setPeter Rosin1-15/+5
Do not waste cycles looking up the property id when we have the actual property already. Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170713162538.22788-3-peda@axentia.se
2017-07-14drm: rename, adjust and export drm_atomic_replace_property_blobPeter Rosin3-29/+26
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: Peter Rosin <peda@axentia.se> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170713162538.22788-2-peda@axentia.se
2017-07-13drm/dp/mst: Use memchr_inv() instead of memcmp() against a zeroed arrayVille Syrjälä1-8/+10
We have memch_inv(), so no need to memcmp() against a zeroed temp array. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170712155254.26455-1-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-13drm/atomic: Make private objs proper objectsVille Syrjälä6-102/+203
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ä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170712155102.26276-3-ville.syrjala@linux.intel.com
2017-07-13drm/atomic: Remove pointless private object NULL state checkVille Syrjälä1-2/+1
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: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170712155102.26276-2-ville.syrjala@linux.intel.com
2017-07-13drm/dp/mst: Handle errors from drm_atomic_get_private_obj_state() correctlyVille Syrjälä1-4/+4
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: edb1ed1ab7d3 ("drm/dp: Add DP MST helpers to atomically find and release vcpi slots") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170712155102.26276-1-ville.syrjala@linux.intel.com Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
2017-07-13drm/mediatek: Convert to new iterator macrosMaarten Lankhorst1-3/+3
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.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-07-13drm/imx: Use atomic iterator macrosMaarten Lankhorst2-5/+5
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: Philipp Zabel <p.zabel@pengutronix.de> Link: http://patchwork.freedesktop.org/patch/msgid/20170712081344.25495-13-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
2017-07-13drm/mali: Use new atomic iterator macrosMaarten Lankhorst1-1/+1
for_each_obj_in_state is about to be removed, so use the new iterator macros. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Brian Starkey <brian.starkey@arm.com> Cc: Mali DP Maintainers <malidp@foss.arm.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170712081344.25495-12-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Liviu Dudau <liviu.dudau@arm.com>
2017-07-13drm/rockchip: Use for_each_oldnew_plane_in_state in vop_crtc_atomic_flushMaarten Lankhorst1-3/+4
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: Mark Yao <mark.yao@rock-chips.com> Cc: Heiko Stuebner <heiko@sntech.de> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-rockchip@lists.infradead.org Link: http://patchwork.freedesktop.org/patch/msgid/20170712081344.25495-10-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Mark Yao <mark.yao@rock-chips.com>
2017-07-13drm/atmel-hlcdec: Use for_each_new_connector_in_stateMaarten Lankhorst1-1/+1
for_each_obj_in_state is about to be removed, so use the new iterator macros. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Boris Brezillon <boris.brezillon@free-electrons.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170712081344.25495-9-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com>
2017-07-13drm/i915: Use correct iterator macroMaarten Lankhorst1-1/+1
for_each_connector_in_state will be removed, so use the right state here. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Link: http://patchwork.freedesktop.org/patch/msgid/20170712081344.25495-7-maarten.lankhorst@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-18 10:36:44 +0000