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>

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 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>

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>

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

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

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

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

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

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

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

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

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

drm/crc: Only open CRC on atomic drivers when the CRTC is active.

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>

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]

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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

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

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

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

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

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

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

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>

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

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

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: 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>

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>

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>

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>

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>

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>

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>

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)]

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>

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>

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>

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>

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

drm/bridge: ti-tfp410: clean up drm_bridge_add call

This patch removes unnecessary checking of return value.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1499071350-25168-12-git-send-email-inki.dae@samsung.com

drm/bridge: tc358767: clean up drm_bridge_add call

This patch removes unnecessary checking of return value.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1499071350-25168-11-git-send-email-inki.dae@samsung.com

drm/bridge: synopsys: dw-hdmi: clean up drm_bridge_add call

This patch removes unnecessary checking of return value.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1499071350-25168-10-git-send-email-inki.dae@samsung.com

drm/bridge: sii902x: clean up drm_bridge_add call

This patch removes unnecessary checking of return value.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1499071350-25168-9-git-send-email-inki.dae@samsung.com

drm/bridge: ps8622: clean up drm_bridge_add call

This patch removes unnecessary checking of return value.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1499071350-25168-8-git-send-email-inki.dae@samsung.com

drm/bridge: panel: clean up drm_bridge_add call

This patch removes unnecessary checking of return value.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1499071350-25168-7-git-send-email-inki.dae@samsung.com

drm/bridge: nxp-ptn3460: clean up drm_bridge_add call

This patch removes unnecessary checking of return value.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1499071350-25168-6-git-send-email-inki.dae@samsung.com

drm/bridge: vga-dac: clean up drm_bridge_add call

This patch removes unnecessary checking of return value.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1499071350-25168-5-git-send-email-inki.dae@samsung.com

drm/bridge: analogix-anx78xx: clean up drm_bridge_add call

This patch removes unnecessary checking of return value.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1499071350-25168-4-git-send-email-inki.dae@samsung.com

drm/bridge: adv7511: clean up drm_bridge_add call

This patch removes unnecessary checking of return value.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1499071350-25168-3-git-send-email-inki.dae@samsung.com

drm/fb-helper: remove drm_fb_helper_save_lut_atomic

drm_fb_helper_save_lut_atomic is redundant since the .gamma_store is
now always kept up to date by drm_fb_helper_setcmap.

Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1499164632-5582-4-git-send-email-peda@axentia.se

drm/fb-helper: keep the .gamma_store updated in drm_fb_helper_setcmap

I think the gamma_store can end up invalid on error. But the way I read
it, that can happen in drm_mode_gamma_set_ioctl as well, so why should
this pesky legacy fbdev stuff be any better?

Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1499164632-5582-3-git-send-email-peda@axentia.se

drm/fb-helper: factor out pseudo-palette

The pseudo-palette has nothing to do with the crtc, so move it
out of the crtc loop and update the palette once, then break out
early.

Signed-off-by: Peter Rosin <peda@axenita.se>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1499164632-5582-2-git-send-email-peda@axentia.se

drm/fb-helper: Split dpms handling into legacy and atomic paths

Like with panning and modesetting, and like with those, stick with
simple drm_modeset_locking_all for the legacy path, and the full
atomic dance for atomic drivers.

This means a bit more boilerplate since setting up the atomic state
machinery is rather verbose, but then this is shared code for 30+
drivers or so, so meh.

After this patch there's only the LUT/cmap path which is still using
drm_modeset_lock_all for an atomic driver. But Peter is already
locking into reworking that, so I'll leave that code as-is for now.

v2: Squash in patches from Maarten to unify all the various atomic
paths into just one atomic update function for fbdev overall. On top
do one s/restore_fbdev_mode/restore_fbdev_mode_atomic/ so that we have
all-atomic callchains after the first check.

Cc: Peter Rosin <peda@axentia.se>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-10-daniel.vetter@ffwll.ch

drm/fb-helper: Stop using mode_config.mutex for internals

Those are now all protected using fb_helper->lock.

v2: We still need to hold mode_config.mutex right around calling
connector->fill_modes.

v3: I forgot to hold mode_config.mutex while looking at
connector->status and the mode list. Also, we need to patch up the
i915 ->initial_config callback to grab the locks it needs to inspect
the modeset state recovered from the fw.

v4: Don't reorder the probe too much (Ville).

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170705045629.31265-1-daniel.vetter@ffwll.ch

drm/fb-helper: Push locking into restore_fbdev_mode_atomic|legacy

Same game as with the panning function, use drm_modeset_lock_all for
legacy paths, and a proper acquire ctx w/w mutex dance for atomic.

Cc: John Stultz <john.stultz@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-8-daniel.vetter@ffwll.ch

drm/fb-helper: Push locking into pan_display_atomic|legacy

For the legacy path we'll keep drm_modeset_lock_all, for the atomic
one we drop the use of the magic implicit context and wire it up
properly.

Cc: John Stultz <john.stultz@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-7-daniel.vetter@ffwll.ch

drm/fb-helper: Drop locking from the vsync wait ioctl code

Like with the drm-native vblank wait ioctl we can entirely rely on the
spinlocks in drm_vblank.c, no need at all to take expensive mutexes.
The only reason we had to take mode_config.mutex was to protect the
fbdev helper's data-structures, but that's now done by
fb_helper->lock.

Cc: John Stultz <john.stultz@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-6-daniel.vetter@ffwll.ch

drm/fb-helper: Push locking in fb_is_bound

That function only needs to take the individual crtc locks, not all
the kms locks. Push down the locking and then minimize it.

Cc: John Stultz <john.stultz@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-5-daniel.vetter@ffwll.ch

drm/fb-helper: Add top-level lock

Introduce a new top-level lock for the FB helper code. This will allow
better locking granularity and avoid the need to abuse modeset locking
for this purpose instead.

This patch just adds the new lock everywhere we currently grab
mode_config->mutex (explicitly, or through drm_modeset_lock_all).
Follow-up patches will push the kms locking down into only the places
that need it.

v2:
- use lockdep_assert_held
- use drm_fb_helper_for_each_connector where possible
- use the new top-level lock consistently, i.e. in all the places
  we're currently acquiring mode_config.mutex.
- small polish to the kerneldoc

Tested-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com> (v1)
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-4-daniel.vetter@ffwll.ch

drm/i915: Drop FBDEV #ifdev in mst code

Since

commit a03fdcb1863297481a4b817c2a759cafcbdfa0ae
Author: Archit Taneja <architt@codeaurora.org>
Date:   Wed Aug 5 12:28:57 2015 +0530

    drm: Add top level Kconfig option for DRM fbdev emulation

this is properly handled using dummy functions. This essentially
undoes

commit 7296c849bf2eca2bd7d34a4686a53e3089150ac1
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jul 22 20:10:28 2014 +1000

    drm/i915: fix build without fbde

v2: We also need to drop the #ifdef from headers. Seems like a small
price to pay for slightly cleaner code.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-3-daniel.vetter@ffwll.ch

drm/fb-helper: Push down modeset lock into FB helpers

Move the modeset locking from drivers into FB helpers.

v2: Also handle intel_connector_add_to_fbdev.

v3: Prevent race in intel_dp_mst with ->detect (Maarten)

Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Tested-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com> (v1)
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170704151833.17304-2-daniel.vetter@ffwll.ch

drm: Remove pending_read_domains and pending_write_domain

The last user of these (i915.ko) no longer does. We can slim down the
core GEM object by removing the unused 8 bytes.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170705154900.28697-1-chris@chris-wilson.co.uk

drm/atomic-helper: Realign function parameters

Too jarring.

Fixes: f869a6ecf254 ("drm/atomic: Add target_vblank support in atomic helpers (v2)")
Cc: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170627145936.18983-14-daniel.vetter@ffwll.ch

drm/fb-helper: Remove drm_mode_config_fb.

Remove drm_mode_config_fb, I don't see the point of it.
To make it clear that it's ok to use plane->fb directly,
move up drm_drv_uses_atomic_modeset so the code is skipped for atomic
drivers that require plane_state->fb.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170703115106.18783-1-maarten.lankhorst@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/bochs: switch fb_ops over to use drm_fb_helper_cfb helpers

The current drm_fb_helper_sys helpers referenced in fb_ops assume that the
video memory is in system RAM. This is not the case for sparc which uses direct
physical memory accesses for IO memory and causes the bochs_drm module to panic
immediately upon startup as it tries to initialise the framebuffer.

Switching fb_ops over to use the drm_fb_helper_cfb helpers ensures that the
correct accesses are used on sparc, fixing the panic and allowing the
bochs_drm module to function under qemu-system-sparc64.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1499032363-8290-1-git-send-email-mark.cave-ayland@ilande.co.uk
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

drm: qxl: constify ttm_place structures.

ttm_place are not supposed to change at runtime. All functions
working with ttm_place provided by <drm/ttm/ttm_placement.h> work
with const ttm_place. So mark the non-const structs as const.

File size before:
   text    data     bss     dec     hex filename
   3485     184     264    3933     f5d drivers/gpu/drm/qxl/qxl_ttm.o

File size After adding 'const':
   text    data     bss     dec     hex filename
   3501     152     264    3917     f4d drivers/gpu/drm/qxl/qxl_ttm.o

Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/a4f21d3bd2497129f084b8055ecf27f0d3ff1bba.1499013516.git.arvind.yadav.cs@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

drm: ttm: virtio-gpu: dma-buf: Constify ttm_place structures.

ttm_place are not supposed to change at runtime. All functions
working with ttm_place provided by <drm/ttm/ttm_placement.h> work
with const ttm_place. So mark the non-const structs as const.

File size before:
   text    data     bss     dec     hex filename
   2315     184       0    2499     9c3 drivers/gpu/drm/virtio/virtgpu_ttm.o

File size After adding 'const':
   text    data     bss     dec     hex filename
   2347     152       0    2499     9c3 drivers/gpu/drm/virtio/virtgpu_ttm.o

Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/25a189402a516a0142d9a4412da0a597c660a96a.1498981093.git.arvind.yadav.cs@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

drm/udl: dma-buf: Constify dma_buf_ops structures.

dma_buf_ops are not supposed to change at runtime. All functions
working with dma_buf_ops provided by <linux/dma-buf.h> work with
const dma_buf_ops. So mark the non-const structs as const.

File size before:
   text    data     bss     dec     hex filename
   2002     112       0    2114     842 drivers/gpu/drm/udl/udl_dmabuf.o

File size After adding 'const':
   text    data     bss     dec     hex filename
   2114       0       0    2114     842 drivers/gpu/drm/udl/udl_dmabuf.o

Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/cb4dfac90e85e2270779331f8cb10b635042bad7.1498912415.git.arvind.yadav.cs@gmail.com

drm: armada: Constify drm_prop_enum_list structures.

drm_prop_enum_lists are not supposed to change at runtime. All functions
working with drm_prop_enum_list provided by <drm/drm_property.h> work
with
const drm_prop_enum_list. So mark the non-const structs as const.

File size before:
   text    data     bss     dec     hex filename
   3594     176       0    3770     eba drivers/gpu/drm/armada/armada_overlay.o

File size After adding 'const':
   text    data     bss     dec     hex filename
   3722      48       0    3770     eba drivers/gpu/drm/armada/armada_overlay.o

Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/dbeb176765bda8eaa9efdaa2dcd14c7bbae39cfa.1498905467.git.arvind.yadav.cs@gmail.com

drm: armada: constify drm_prop_enum_list structures.

drm_prop_enum_lists are not supposed to change at runtime. All functions
working with drm_prop_enum_list provided by <drm/drm_property.h> work
with
const drm_prop_enum_list. So mark the non-const structs as const.

File size before:
   text    data     bss     dec     hex filename
   9629     744       0   10373    2885 drivers/gpu/drm/armada/armada_crtc.o

File size After adding 'const':
   text    data     bss     dec     hex filename
   9757     616       0   10373    2885 drivers/gpu/drm/armada/armada_crtc.o

Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/d2344c4dc40238cfe48fa6d917767df0f053150a.1498902844.git.arvind.yadav.cs@gmail.com

drm/atomic: initial support for asynchronous plane update

In some cases, like cursor updates, it is interesting to update the
plane in an asynchronous fashion to avoid big delays. The current queued
update could be still waiting for a fence to signal and thus block any
subsequent update until its scan out. In cases like this if we update the
cursor synchronously through the atomic API it will cause significant
delays that would even be noticed by the final user.

This patch creates a fast path to jump ahead the current queued state and
do single planes updates without going through all atomic steps in
drm_atomic_helper_commit(). We take this path for legacy cursor updates.

For now only single plane updates are supported, but we plan to support
multiple planes updates and async PageFlips through this interface as well
in the near future.

v6: - move check code to drm_atomic_helper.c (Daniel Vetter)

v5:
- improve comments (Eric Anholt)

v4:
- fix state->crtc NULL check (Archit Taneja)

v3:
- fix iteration on the wrong crtc state
- put back code to forbid updates if there is a queued update for
the same plane (Ville Syrjälä)
- move size checks back to drivers (Ville Syrjälä)
- move ASYNC_UPDATE flag addition to its own patch (Ville Syrjälä)

v2:
- allow updates even if there is a queued update for the same
plane.
        - fixes on the documentation (Emil Velikov)
        - unconditionally call ->atomic_async_update (Emil Velikov)
        - check for ->atomic_async_update earlier (Daniel Vetter)
        - make ->atomic_async_check() the last step (Daniel Vetter)
        - add ASYNC_UPDATE flag (Eric Anholt)
        - update state in core after ->atomic_async_update (Eric Anholt)
- update docs (Eric Anholt)

Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org> (v5)
Acked-by: Eric Anholt <eric@anholt.net> (v5)
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170630180322.29007-2-gustavo@padovan.org

drm/atomic: Drop helper include from drm_atomic.c

Core code should never have to look at helper stuff, to make sure that
all helper code is 100% optional and can be overriden.

Cc: Gustavo Padovan <gustavo@padovan.org>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170630073921.2345-1-daniel.vetter@ffwll.ch

drm: Convert atomic drivers from CRTC .disable() to .atomic_disable()

The CRTC .disable() helper operation is deprecated for atomic drivers,
the new .atomic_disable() helper operation being preferred. Convert all
atomic drivers to .atomic_disable() to avoid cargo-cult use of
.disable() in new drivers.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> # for sun4i
Acked-by: Philipp Zabel <p.zabel@pengutronix.de> # for mediatek
Acked-by: Alexey Brodkin <abrodkin@synopsys.com> # for arcpgu
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> # for atmel-hlcdc
Tested-by: Philippe Cornu <philippe.cornu@st.com> # for stm
Acked-by: Philippe Cornu <philippe.cornu@st.com> # for stm
Acked-by: Vincent Abriou <vincent.abriou@st.com> # for sti
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> # for vmwgfx
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170630093646.7928-3-laurent.pinchart+renesas@ideasonboard.com

drm: Add old state pointer to CRTC .enable() helper function

The old state is useful for drivers that need to perform operations at
enable time that depend on the transition between the old and new
states.

While at it, rename the operation to .atomic_enable() to be consistent
with .atomic_disable(), as the .enable() operation is used by atomic
helpers only.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> # for sun4i
Acked-by: Philipp Zabel <p.zabel@pengutronix.de> # for imx-drm and mediatek
Acked-by: Alexey Brodkin <abrodkin@synopsys.com> # for arcpgu
Acked-by: Boris Brezillon <boris.brezillon@free-electrons.com> # for atmel-hlcdc
Acked-by: Liviu Dudau <Liviu.Dudau@arm.com> # for hdlcd and mali-dp
Acked-by: Stefan Agner <stefan@agner.ch> # for fsl-dcu
Tested-by: Philippe Cornu <philippe.cornu@st.com> # for stm
Acked-by: Philippe Cornu <philippe.cornu@st.com> # for stm
Acked-by: Vincent Abriou <vincent.abriou@st.com> # for sti
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> # for vmwgfx
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170630093646.7928-2-laurent.pinchart+renesas@ideasonboard.com

dma-buf/sw-sync: Use an rbtree to sort fences in the timeline

Reduce the list iteration when incrementing the timeline by storing the
fences in increasing order.

v2: Prevent spinlock recursion on free during create
v3: Fixup rebase conflict inside comments that escaped the compiler.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170629211253.22766-1-chris@chris-wilson.co.uk

dma-buf/sw-sync: Fix locking around sync_timeline lists

The sync_pt were not adding themselves atomically to the timeline lists,
corruption imminent.  Only a single list is required to track the
unsignaled sync_pt, so reduce it and rename the lock more appropriately
along with using idiomatic names to distinguish a list from links along
it.

v2: Prevent spinlock recursion on free during create (next patch) and
fixup crossref in kerneldoc

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170629210532.5617-1-chris@chris-wilson.co.uk

dma-buf/sw-sync: sync_pt is private and of fixed size

Since sync_pt is only allocated from a single location and is no longer
the base class for fences (that is struct dma_fence) it no longer needs
a generic unsized allocator.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170629125930.821-5-chris@chris-wilson.co.uk

dma-buf/sw-sync: Reduce irqsave/irqrestore from known context

If we know the context under which we are called, then we can use the
simpler form of spin_lock_irq (saving the save/restore).

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170629125930.821-4-chris@chris-wilson.co.uk

dma-buf/sw-sync: Prevent user overflow on timeline advance

The timeline is u32, which limits any single advance to INT_MAX so that
we can detect all fences that need signaling.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170629125930.821-3-chris@chris-wilson.co.uk

dma-buf/sw-sync: Fix the is-signaled test to handle u32 wraparound

Use the canonical __dma_fence_is_later() to compare the fence seqno
against the timeline seqno to check if the fence is signaled.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170629125930.821-2-chris@chris-wilson.co.uk

dma-buf/dma-fence: Extract __dma_fence_is_later()

Often we have the task of comparing two seqno known to be on the same
context, so provide a common __dma_fence_is_later().

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170629125930.821-1-chris@chris-wilson.co.uk

drm/gma500: remove an unneeded NULL check

"connector" is the list iterator and it can't be NULL.  It causes a
static checker warning because we dereference the iterator to get the
next item in the list.  Let's remove this check.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170628124100.3pw2gyitsfopaib5@mwanda

drm: vmwgfx: Replace CRTC .commit() helper operation with .enable()

The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. Replace the .commit() helper operation
with .enable() in the driver.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170627211621.27767-6-laurent.pinchart+renesas@ideasonboard.com

drm: vmwgfx: Remove unneeded CRTC .prepare() helper operation

The CRTC .prepare() helper operation is part of the legacy helpers and
is deprecated in favour of the .disable() helper operation. As the
vmwgfx driver provides a .disable() helper operation, and as the
.prepare() helper operation implementation is empty, we can remove it.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170627211621.27767-5-laurent.pinchart+renesas@ideasonboard.com

drm: qxl: Replace CRTC .commit() helper operation with .enable()

The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. Replace the .commit() helper operation
with .enable() in the driver.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170627211621.27767-4-laurent.pinchart+renesas@ideasonboard.com

drm: qxl: Remove unused CRTC .dpms() helper operation

The CRTC .dpms() helper operation is called by the atomic helpers only
when no .prepare(), .atomic_disable() or .disable() operation is
provided. As the qxl driver provides a .disable() operation, the .dpms()
operation is unused and can be removed.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170627211621.27767-3-laurent.pinchart+renesas@ideasonboard.com

drm: arcpgu: Remove CRTC .prepare() helper operation

The CRTC helper .prepare() operation is legacy code, the atomic helpers
prefer the .disable() operation. As the arcpgu driver implements the
.disable() and .prepare() operations identicallly, .prepare() can be
removed.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170627211621.27767-2-laurent.pinchart+renesas@ideasonboard.com

drm: arcpgu: Remove CRTC .commit() helper operation

The CRTC helper .commit() operation is legacy code, the atomic helpers
prefer the .enable() operation. As the arcpgu driver implements the
.enable() operation, .commit() is never used and can be removed.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170627211621.27767-1-laurent.pinchart+renesas@ideasonboard.com

drm/vblank: Unexport drm_vblank_cleanup

There's no reason for drivers to call this, and all the ones I've
removed looked very fishy:
- Proper quiescenting of the vblank machinery should be done by
  calling drm_crtc_vblank_off(), which is best done by shutting down
  the entire display engine with drm_atomic_helper_shutdown.

- Releasing of allocated memory is done by the core already, it calls
  drm_vblank_cleanup as a fallback.

- drm_vblank_cleanup also has checks for drivers which forget to clean
  up vblank interrupts.

This essentially reverts

commit e77cef9c2d87db835ad9d70cde4a9b00b0ca2262
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Thu Jan 7 15:39:13 2010 +0100

    drm: Avoid calling vblank function is vblank wasn't initialized

which was done to fix a bug in radeon code with msi interrupts:

commit 003e69f9862bcda89a75c27750efdbc17ac02945
Author: Jerome Glisse <jglisse@redhat.com>
Date:   Thu Jan 7 15:39:14 2010 +0100

    drm/radeon/kms: Don't try to enable IRQ if we have no handler installed

Afaict from digging around in old code, this was needed to avoid
blowing up in the ums fallback, and has stopped serving it's purpose
long ago - if irq init fails, the driver fails to load, and there's
really no way to blow up anymore.

Long story short, this was most likely a small ums compat/fallback
hack that became a thing of it's own and got cargo-cult duplicated all
over the drm codebase for essentially no gain at all.

v2: Mention that for drivers with a ->release callback cleanup is
handled by drm_dev_fini() (Thierry).

Cc: Thierry Reding <treding@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170626161949.25629-2-daniel.vetter@ffwll.ch

drm/hdlcd: remove drm_vblank_cleanup, rise of the zoombies edition

This was accidentally restored in

commit de5cc8155cd250a31da67dea49aff7637ce98887
Author: Liviu Dudau <Liviu.Dudau@arm.com>
Date:   Tue Jun 6 15:05:21 2017 +0100

    drm/arm: hdlcd: Set the CRTC's port before binding the encoder

Fixes: de5cc8155cd2 ("drm/arm: hdlcd: Set the CRTC's port before binding the encoder.")
Cc: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Brian Starkey <brian.starkey@arm.com>
Cc: Mali DP Maintainers <malidp@foss.arm.com>
Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170628091141.14539-1-daniel.vetter@ffwll.ch

drm/core: Fail atomic IOCTL with no CRTC state but with signaling.

Problem : While running IGT kms_atomic_transition test suite i encountered
a hang in drmHandleEvent immediately following  an atomic_commit.
After dumping the atomic state I relized that in this case there was
not even one CRTC attached to the state and only disabled
planes. This probably due to a commit which hadn't changed any property
which would require attaching crtc state. This means drmHandleEvent
will never wake up from read since without CRTC in atomic state
the event fd will not be signaled.

Fix: Protect against this issue by failing atomic_commit early in
drm_mode_atomic_commit where such probelm can be identified.

v2:
Fix typos and extra newlines.

Change-Id: I3ee28ffae35fd1e8bfe553146c44da53da02e6f8
Signed-off-by: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497981426-27203-1-git-send-email-Andrey.Grodzovsky@amd.com

Merge remote-tracking branch 'airlied/drm-next' into drm-misc-next

Required for Daniel's drm_vblank_cleanup cleanup