2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-25 05:34:00 +08:00
Commit Graph

680716 Commits

Author SHA1 Message Date
Maarten Lankhorst
8572636e45 drm/nouveau: Handle drm_atomic_helper_swap_state failure
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-26 13:22:41 +02:00
Maarten Lankhorst
c066d2310a drm/atomic: Change drm_atomic_helper_swap_state to return an error.
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-26 13:22:40 +02:00
Maarten Lankhorst
813a7e1604 drm/nouveau: Fix error handling in nv50_disp_atomic_commit
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: 839ca903f1 ("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-26 13:22:40 +02:00
Daniel Vetter
e1923ab3d0 drm/<drivers>: Drop fbdev info flags
- 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-26 13:22:40 +02:00
Daniel Vetter
060f33b717 drm/qxl: Drop fbdev hwaccel flags
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 c0fe07aa50
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-26 13:22:39 +02:00
Daniel Vetter
47f3980067 drm: Update docs around gem_free_object
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-26 13:22:39 +02:00
Daniel Vetter
3379c04cfa drm: Don't complain too much about struct_mutex.
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-18 09:17:22 +02:00
Daniel Vetter
98755a51fb drm/zte: Use gem_free_object_unlocked
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-18 08:40:54 +02:00
Daniel Vetter
8125b84e32 drm/pl111: Use gem_free_object_unlocked
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-18 08:40:54 +02:00
Daniel Vetter
572b7bc06b drm/mxsfb: Use gem_free_object_unlocked
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-18 08:40:54 +02:00
Philippe CORNU
46fc51546d drm/bridge/synopsys: Add MIPI DSI host controller bridge
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-18 12:06:42 +05:30
Philippe CORNU
88dd1e6f9a dt-bindings: display: Add Synopsys DW MIPI DSI host controller
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-18 12:06:42 +05:30
Philippe CORNU
bdf31bcf3d drm/stm: ltdc: Add panel-bridge support
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-18 12:06:42 +05:30
Philippe CORNU
cea3a330ee drm/stm: ltdc: Fix leak of px clk enable in some error paths
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-18 12:06:41 +05:30
Brian Norris
ad364f447e drm/vgem: add compat_ioctl support
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-17 21:08:31 +02:00
Maarten Lankhorst
8038e09be5 drm/crc: Only open CRC on atomic drivers when the CRTC is active.
Commit e8fa567118 ("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: e8fa567118 ("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-17 16:34:51 +02:00
Maarten Lankhorst
eb42ea6d0b drm/crc: Handle opening and closing crc better
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-17 16:32:43 +02:00
Eric Anholt
ec878c0756 drm/vc4: Fix misleading name of the continuous flag.
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-14 14:09:55 -07:00
Eric Anholt
e65d51126f drm/vc4: Fix DSI T_INIT timing.
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-14 14:09:43 -07:00
Shashank Sharma
2570fe2586 drm: add helper functions for YCBCR420 handling
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-14 21:23:54 +03:00
Shashank Sharma
e6a9a2c3dc drm/edid: parse ycbcr 420 deep color information
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-14 21:23:54 +03:00
Shashank Sharma
832d4f2f41 drm/edid: parse YCBCR420 videomodes from EDID
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-14 21:23:54 +03:00
Shashank Sharma
d85231530b drm: add helper to validate YCBCR420 modes
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-14 21:23:54 +03:00
Shashank Sharma
87563fc030 drm/edid: cleanup patch for CEA extended-tag macro
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-14 21:23:54 +03:00
Shashank Sharma
0f0f870830 drm/edid: parse sink information before CEA blocks
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-14 21:23:54 +03:00
Shashank Sharma
8ec6e07555 drm/edid: complete CEA modedb(VIC 1-107)
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-14 21:23:54 +03:00
Shashank Sharma
0c1f528cb1 drm: handle HDMI 2.0 VICs in AVI info-frames
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-14 21:23:54 +03:00
Noralf Trønnes
3589211e9b drm/tinydrm: Add RePaper e-ink driver
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-14 19:30:08 +02:00
Noralf Trønnes
379ea9a1a5 drm/tinydrm: Add tinydrm_xrgb8888_to_gray8() helper
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-14 19:29:59 +02:00
Noralf Trønnes
7f0dc77772 dt-bindings: Add Pervasive Displays RePaper bindings
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-14 19:29:33 +02:00
Noralf Trønnes
d432d6922b of: Add vendor prefix for Pervasive Displays
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-14 19:14:47 +02:00
Peter Rosin
964c60063b drm/fb-helper: separate the fb_setcmap helper into atomic and legacy paths
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-14 15:53:06 +02:00
Peter Rosin
e2b9dd304a drm/atomic-helper: update lut props directly in ..._legacy_gamma_set
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-14 15:53:06 +02:00
Peter Rosin
5f057ffd6d drm: rename, adjust and export drm_atomic_replace_property_blob
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-14 15:53:06 +02:00
Ville Syrjälä
e38e128950 drm/dp/mst: Use memchr_inv() instead of memcmp() against a zeroed array
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-13 19:28:43 +03:00
Ville Syrjälä
a4370c7774 drm/atomic: Make private objs proper objects
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-13 19:28:43 +03:00
Ville Syrjälä
178e32c224 drm/atomic: Remove pointless private object NULL state check
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-13 19:28:43 +03:00
Ville Syrjälä
56a91c4932 drm/dp/mst: Handle errors from drm_atomic_get_private_obj_state() correctly
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: edb1ed1ab7 ("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-13 19:28:43 +03:00
Maarten Lankhorst
e27986853a drm/mediatek: Convert to new iterator macros
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-13 09:56:00 +02:00
Maarten Lankhorst
30ea752146 drm/imx: Use atomic iterator macros
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-13 09:54:48 +02:00
Maarten Lankhorst
a8e3fb5508 drm/mali: Use new atomic iterator macros
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-13 09:54:12 +02:00
Maarten Lankhorst
e741f2b182 drm/rockchip: Use for_each_oldnew_plane_in_state in vop_crtc_atomic_flush
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-13 09:53:43 +02:00
Maarten Lankhorst
d57da16f57 drm/atmel-hlcdec: Use for_each_new_connector_in_state
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-13 09:52:09 +02:00
Maarten Lankhorst
fe5f6b1fa0 drm/i915: Use correct iterator macro
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>
2017-07-13 09:51:01 +02:00
Maarten Lankhorst
bdc362f631 drm/vmwgfx: Make check_modeset() use the new atomic iterator macros.
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: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170712081344.25495-6-maarten.lankhorst@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[mlankhorst: Make function static (danvet)]
2017-07-13 09:50:39 +02:00
Maarten Lankhorst
2d705c0b36 drm/atomic: Use new iterator macros in drm_atomic_helper_wait_for_flip_done
for_each_obj_in_state is about to be removed, so use the correct new
iterator macro.

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: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Link: http://patchwork.freedesktop.org/patch/msgid/20170712081344.25495-5-maarten.lankhorst@linux.intel.com
[mlankhorst: Based on danvet's feedback, only apply first hunk and rename crtc_state variable to unused]
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-13 09:46:37 +02:00
Maarten Lankhorst
dfb8bb3bd4 drm/atomic: Use the new helpers in drm_atomic_helper_disable_all()
for_each_obj_in_state will be removed, so don't use it 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: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Link: http://patchwork.freedesktop.org/patch/msgid/20170712081344.25495-4-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-13 09:44:59 +02:00
Maarten Lankhorst
0c3eb12324 drm/atomic: Use the correct iterator macro in atomic_remove_fb
for_each_obj_in_state will be removed, so use the new 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: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Link: http://patchwork.freedesktop.org/patch/msgid/20170712081344.25495-3-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-13 09:44:58 +02:00
Maarten Lankhorst
765831dc27 drm/simple-kms-helper: Fix the check for the mismatch between plane and CRTC enabled.
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: Maarten Lankhorst <maarten.lankhorst@linux.intel.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>
Link: http://patchwork.freedesktop.org/patch/msgid/20170712081344.25495-2-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-07-13 09:44:51 +02:00
Alexandru Moise
371c2279aa drm: inhibit drm drivers register to uninitialized drm core
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: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170708214352.GA27205@gmail.com
2017-07-11 12:03:11 +02:00