drm: writeback: Add out-fences for writeback connectors

Add the WRITEBACK_OUT_FENCE_PTR property to writeback connectors, to
enable userspace to get a fence which will signal once the writeback is
complete. It is not allowed to request an out-fence without a
framebuffer attached to the connector.

A timeline is added to drm_writeback_connector for use by the writeback
out-fences.

In the case of a commit failure or DRM_MODE_ATOMIC_TEST_ONLY, the fence
is set to -1.

Changes from v2:
 - Rebase onto Gustavo Padovan's v9 explicit sync series
 - Change out_fence_ptr type to s32 __user *
 - Set *out_fence_ptr to -1 in drm_atomic_connector_set_property
 - Store fence in drm_writeback_job
 Gustavo Padovan:
 - Move out_fence_ptr out of connector_state
 - Signal fence from drm_writeback_signal_completion instead of
   in driver directly

Changes from v3:
 - Rebase onto commit 7e9081c5aac7 ("drm/fence: fix memory overwrite
   when setting out_fence fd") (change out_fence_ptr to s32 __user *,
   for real this time.)
 - Update documentation around WRITEBACK_OUT_FENCE_PTR

Signed-off-by: Brian Starkey <brian.starkey@arm.com>
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/229036/

drm: Add writeback connector type

Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer. Add a writeback connector type and
related support functions.

Drivers should initialize a writeback connector with
drm_writeback_connector_init() which takes care of setting up all the
writeback-specific details on top of the normal functionality of
drm_connector_init().

Writeback connectors have a WRITEBACK_FB_ID property, used to set the
output framebuffer, and a WRITEBACK_PIXEL_FORMATS blob used to expose the
supported writeback formats to userspace.

When a framebuffer is attached to a writeback connector with the
WRITEBACK_FB_ID property, it is used only once (for the commit in which
it was included), and userspace can never read back the value of
WRITEBACK_FB_ID. WRITEBACK_FB_ID can only be set if the connector is
attached to a CRTC.

Changes since v1:
 - Added drm_writeback.c + documentation
 - Added helper to initialize writeback connector in one go
 - Added core checks
 - Squashed into a single commit
 - Dropped the client cap
 - Writeback framebuffers are no longer persistent

Changes since v2:
 Daniel Vetter:
 - Subclass drm_connector to drm_writeback_connector
 - Relax check to allow CRTC to be set without an FB
 - Add some writeback_ prefixes
 - Drop PIXEL_FORMATS_SIZE property, as it was unnecessary
 Gustavo Padovan:
 - Add drm_writeback_job to handle writeback signalling centrally

Changes since v3:
 - Rebased
 - Rename PIXEL_FORMATS -> WRITEBACK_PIXEL_FORMATS

Chances since v4:
 - Embed a drm_encoder inside the drm_writeback_connector to
   reduce the amount of boilerplate code required from the drivers
   that are using it.

Changes since v5:
 - Added Rob Clark's atomic_commit() vfunc to connector helper
   funcs, so that writeback jobs are committed from atomic helpers
 - Updated create_writeback_properties() signature to return an
   error code rather than a boolean false for failure.
 - Free writeback job with the connector state rather than when
   doing the cleanup_work()

Changes since v7:
 - fix extraneous use of out_fence that is only introduced in a
   subsequent patch.

Changes since v8:
 - whitespace changes pull from subsequent patch

Changes since v9:
 - Revert the v6 changes that free the writeback job in the connector
   state cleanup and return to doing it in the cleanup_work() function

Signed-off-by: Brian Starkey <brian.starkey@arm.com>
[rebased and fixed conflicts]
Signed-off-by: Mihail Atanassov <mihail.atanassov@arm.com>
[rebased and added atomic_commit() vfunc for writeback jobs]
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/229037/

dma-buf: remove kmap_atomic interface

Neither used nor correctly implemented anywhere. Just completely remove
the interface.

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: https://patchwork.freedesktop.org/patch/226645/

dma_buf: remove device parameter from attach callback v2

The device parameter is completely unused because it is available in the
attachment structure as well.

v2: fix kerneldoc as well

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/226643/

drm/vc4: Always obey implicit sync

Same justification as for drm_gem_fb_prepare_fb.

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/20180405154449.23038-9-daniel.vetter@ffwll.ch
Link: https://patchwork.freedesktop.org/patch/msgid/20180409085134.27321-1-daniel.vetter@ffwll.ch

drm/gem-fb-helper: Always do implicit sync

I've done a lot of history digging. The first signs of this
optimization was introduced in i915:

commit 25067bfc060d1a481584dcb51ef4b5680176ecb6
Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Date:   Wed Sep 10 12:03:17 2014 -0300

    drm/i915: pin sprite fb only if it changed

without much justification. Pinning already pinned stuff is real cheap
(it's just obj->pin_count++ really), and the missing implicit sync was
entirely forgotten about it seems. It's at least not mentioned
anywhere it the commit message.

It was also promptly removed shortly afterwards in

commit ea2c67bb4affa84080c616920f3899f123786e56
Author: Matt Roper <matthew.d.roper@intel.com>
Date:   Tue Dec 23 10:41:52 2014 -0800

    drm/i915: Move to atomic plane helpers (v9)

again without really mentioning the side-effect that plane updates
with the same fb now again obey implicit syncing.

Note that this only ever applied to the plane_update hook, all other
legacy entry points (set_base, page_flip) always obeyed implicit sync
in the drm/i915 driver.

The real source of this code here seems to be msm, copied to vc4, then
copied to tinydrm. I've also tried to dig around in all available msm
sources, but the corresponding check for fb != old_fb is present ever
since the initial merge in

commit cf3a7e4ce08e6876cdcb80390876647f28a7cf8f
Author: Rob Clark <robdclark@gmail.com>
Date:   Sat Nov 8 13:21:06 2014 -0500

    drm/msm: atomic core bits

The only older version I've found of msm atomic code predates the
atomic helpers, and so didn't even use any of this. It also does not
have a corresponding check (because it simply did no implicit sync at
all).

I've chatted with Rob on irc, and he didn't remember the reason for
this either.

Note we had epic amounts of fun with too much syncing against
_vblank_, especially around cursor updates. But I don't ever
discussing a need for less syncing against implicit fences.

Also note that explicit fencing allows you to sidetrack all of this,
at least for all the drivers correctly implemented using
drm_atomic_set_fence_for_plane().

Given that it seems to be an accident of history, and that big drivers
like i915 (and also nouveau it seems, I didn't follow the
amdgpu/radeon sync code to figure this out properly there) never have
done it, let's remove this.

Cc: Rob Clark <robdclark@gmail.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: "Noralf Trønnes" <noralf@tronnes.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405154449.23038-8-daniel.vetter@ffwll.ch

drm/rockchip: vop: fix irq disabled after vop driver probed

The vop irq is shared between vop and iommu and irq probing in the
iommu driver moved to the probe function recently. This can in some
cases lead to a stall if the irq is triggered while the vop driver
still has it disabled, but the vop irq handler gets called.

But there is no real need to disable the irq, as the vop can simply
also track its enabled state and ignore irqs in that case.
For this we can simply check the power-domain state of the vop,
similar to how the iommu driver does it.

So remove the enable/disable handling and add appropriate condition
to the irq handler.

changes in v2:
- move to just check the power-domain state
- add clock handling
changes in v3:
- clarify comment to speak of runtime-pm not power-domain
changes in v4:
- address Marc's comments (clk-enable WARN_ON and style improvement)

Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()")
Cc: stable@vger.kernel.org
Signed-off-by: Sandy Huang <hjc@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180612132028.27490-3-heiko@sntech.de

drm/rockchip: vop: split out core clock enablement into separate functions

Judging from the iommu code, both the hclk and aclk are necessary for
register access. Split them off into separate functions from the regular
vop enablement, so that we can use them elsewhere as well.

Fixes: d0b912bd4c23 ("iommu/rockchip: Request irqs in rk_iommu_probe()")
[prerequisite change for the actual fix]
Cc: stable@vger.kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180612132028.27490-2-heiko@sntech.de

drm: Add checks for atomic_[duplicate/destroy]_state with atomic drivers

This patch add checks for atomic_[duplicate/destroy]_state of
drm_[connector/crtc/plane]_funcs for atomic drivers in the relevant
drm_*_init functions since these callback are mandatory for atomic drivers.

Update the kerneldoc comments for those callbacks.

Signed-off-by: Haneen Mohammed <hamohammed.sa@gmail.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525012555.GA8448@haneen-vb

drm/rockchip: cnd-dp: adjust spdif register setting

We use jitter bypass mode for spdif, so do not need to set jitter mode
related bit in SPDIF_CTRL_ADDR register. But of course we need to keep
the SPDIF_ENABLE bit.

Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1526979222-32478-1-git-send-email-hl@rock-chips.com

drm/rockchip: lvds: add missing of_node_put

The device node iterators perform an of_node_get on each iteration, so a
jump out of the loop requires an of_node_put.

The semantic patch that fixes this problem is as follows
(http://coccinelle.lip6.fr):

// <smpl>
@@
expression root,e;
local idexpression child;
iterator name for_each_child_of_node;
@@

 for_each_child_of_node(root, child) {
   ... when != of_node_put(child)
       when != e = child
+  of_node_put(child);
?  break;
   ...
}
... when != child
// </smpl>

Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS")
Cc: stable@vger.kernel.org
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1527102436-13447-6-git-send-email-Julia.Lawall@lip6.fr

drm/atomic: Set current atomic state in drm_private_state

drm_private_state has a back pointer to the drm_atomic_state,
however that was not initialized in drm_atomic_get_private_obj_state
after duplication, as it is the case for other drm atomic getters

Signed-off-by: Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1527701452-1934-1-git-send-email-alexandru-cosmin.gheorghe@arm.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm: Print bad user modes

Print out the modeline when we reject a bad user mode. Avoids having to
guess why it was rejected.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180611193403.16118-2-ville.syrjala@linux.intel.com
Reviewed-by: Harry Wentland <harry.wentland@amd.com>

drm/atomic: Improve debug messages

Print the id/name of the object we're dealing with. Makes it easier to
figure out what's going on. Also toss in a few extra debug prints that
might be useful.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180611193403.16118-1-ville.syrjala@linux.intel.com
Reviewed-by: Harry Wentland <harry.wentland@amd.com>

drm/bridge: sil_sii8620: do not have a dependency of RC_CORE

This patch makes RC_CORE to be selected with this driver.

sil_sii8620 driver calls remote controller interfaces directly
so RC_CORE should be enabled mandatorily.

And some boards not using remote controller device don't really
need to know that RC_CORE config should be enabled to use sil_sii8620
driver only for HDMI.

Changelog v2:
- select INPUT because compiling will fail without INPUT.

Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1527154379-31886-1-git-send-email-inki.dae@samsung.com

drm: Stop updating plane->crtc/fb/old_fb on atomic drivers

Stop playing around with plane->crtc/fb/old_fb with atomic
drivers. Make life a lot simpler when we don't have to do the
magic old_fb vs. fb dance around plane updates. That way we
can't risk plane->fb getting out of sync with plane->state->fb
and we're less likely to leak any refcounts as well.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-14-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

drm/vc4: Stop updating plane->fb/crtc

We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.

Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-13-ville.syrjala@linux.intel.com
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

drm/virtio: Stop updating plane->crtc

We want to get rid of plane->crtc on atomic drivers. Stop setting it.

v2: s/fb/crtc/ in the commit message (Gerd)

Cc: David Airlie <airlied@linux.ie>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-12-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

drm/msm: Stop updating plane->fb/crtc

We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.

v2: Catch a few more cases

Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v1
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-11-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

drm/exynos: Stop updating plane->crtc

We want to get rid of plane->crtc on atomic drivers. Stop setting it.

Cc: Inki Dae <inki.dae@samsung.com>
Cc: Joonyoung Shim <jy0922.shim@samsung.com>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Inki Dae <inki.dae@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-10-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

drm/i915: Stop updating plane->fb/crtc

We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.

v2: Fix up the comment in intel_crtc_active() and
    nuke the rest of the stale comments (Daniel)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v1
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-9-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

drm/amdgpu/dc: Stop updating plane->fb

We want to get rid of plane->fb on atomic drivers. Stop setting it.

Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: "David (ChunMing) Zhou" <David1.Zhou@amd.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: amd-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-8-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

drm/vmwgfx: Stop messing about with plane->fb/old_fb/crtc

plane->fb/old_fb/crtc should no longer be used by atomic
drivers. Stop messing about with them.

Cc: Deepak Rawat <drawat@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-7-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

drm/vmwgfx: Stop using plane->fb in atomic_enable()

Instead of looking at the (soon to be deprecated) plane->fb we'll
examing plane->state->fb instead. We can do this because
vmw_du_crtc_atomic_check() prevents us from enabling a crtc
without the primary plane also being enabled.

Due to that same reason, I'm actually not sure what the checks here are
for NULL fb. If we can't enable the crtc without an enabled plane
we should always have an fb. But I'll leave that for someone else
to figure out.

Cc: Deepak Rawat <drawat@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-6-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

drm/vmwgfx: Stop updating plane->fb

We want to get rid of plane->fb on atomic drivers. Stop setting it.

Cc: Deepak Rawat <drawat@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-5-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

drm/vmwgfx: Stop using plane->fb in vmw_kms_update_implicit_fb()

The only caller of vmw_kms_update_implicit_fb() is the page_flip
hook which itself gets called with the plane mutex already held.
Hence we can look at plane->state safely.

v2: Drop the bogus lockdep assert

Cc: Deepak Rawat <drawat@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak Rawat <drawat@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-4-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()

Instead of plane->fb (which we're going to deprecate for atomic drivers)
we need to look at plane->state->fb. The maze of code leading to
vmw_kms_helper_dirty() wasn't particularly clear, but my analysis
concluded that the calls originating from vmw_*_primary_plane_atomic_update()
all pass in the crtc which means we'll never end up in this branch
of the function. All other callers use drm_modeset_lock_all() somewhere
higher up, which means accessing plane->state is safe.

v2: Drop the comment and make the code do what it did before (Thomas)
v3: Drop the bogus lockdep assert

Cc: Deepak Rawat <drawat@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-3-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset()

Instead of looking at plane->fb let's look at the proper new
plane state.

Not that the code makes a ton of sense. It's only going through the
crtcs in the atomic state, so assuming not all of them are included
we're not even calculating the total bandwidth here. Also we're
not considering whether each crtc is actually enabled or not.

Cc: Deepak Rawat <drawat@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-2-ville.syrjala@linux.intel.com
Reviewed-by: Sinclair Yeh <syeh@vmware.com>

drm/edid: Quirk Vive Pro VR headset non-desktop.

This adds the Vive Pro's EDID information and
sets EDID_QUIRK_NON_DESKTOP.

Signed-off-by: Lubosz Sarnecki <lubosz.sarnecki@collabora.com>
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Cc: <stable@vger.kernel.org> # v4.15+
Link: https://patchwork.freedesktop.org/patch/msgid/20180529115215.4526-1-lubosz.sarnecki@collabora.com

dma-buf: make map_atomic and map function pointers optional

So drivers don't need dummy functions just returning NULL.

Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20180529135918.19729-1-kraxel@redhat.com

drm/vc4: Add support for SAND modifier.

This is the format generated by VC4's H.264 engine, and preferred by
the ISP as well.  By displaying SAND buffers directly, we can avoid
needing to use the ISP to rewrite the SAND H.264 output to linear
before display.

This is a joint effort by Dave Stevenson (who wrote the initial patch
and DRM demo) and Eric Anholt (drm_fourcc.h generalization, safety
checks, RGBA support).

v2: Make the parameter macro give all of the middle 48 bits (suggested
    by Daniels).  Fix fourcc_mod_broadcom_mod()'s bits/shift being
    swapped.  Mark NV12/21 as supported, not YUV420.

Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Cc: Daniel Vetter <daniel@ffwll.ch>
Acked-by: Daniel Stone <daniels@collabora.com> (v1)
Cc: Boris Brezillon <boris.brezillon@bootlin.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180316220435.31416-3-eric@anholt.net

drm/vc4: Add missing formats to vc4_format_mod_supported().

Daniel's format_mod_supported() patch predated Dave's for NV21/61, and
I didn't catch that when rebasing.  This is a problem since the
formats are now getting validated before being passed to the driver's
atomic hooks.

Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Daniel Stone <daniels@collabora.com>
Cc: Dave Stevenson <dave.stevenson@raspberrypi.org>
Fixes: 423ad7b3cbd1 ("drm/vc4: Advertise supported modifiers for planes")
Link: https://patchwork.freedesktop.org/patch/msgid/20180316220435.31416-2-eric@anholt.net

drm: Trust format_mod_supported() when it OKs a plane modifier.

For parameterized modifiers (Broadcom's SAND and UIF), we need to
allow the parameter fields to be filled in, while exposing only the
variant of the modifier with the parameter unfilled in the internal
arrays and the format blob.

Signed-off-by: Eric Anholt <eric@anholt.net>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180316220435.31416-1-eric@anholt.net
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/i915: Promote .format_mod_supported() to the lead role

Up to now we've used the plane's modifier list as the primary
source of information for which modifiers are supported by a
given plane. In order to allow auxiliary metadata to be embedded
within the bits of the modifier we need to stop doing that.

Thus we have to make .format_mod_supported() aware of the plane's
capabilities and gracefully deal with any modifier being passed
in directly from userspace.

v2: Rebase after NV12
    Simplify

Cc: Eric Anholt <eric@anholt.net>
References: https://lists.freedesktop.org/archives/dri-devel/2018-March/169782.html
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518162159.30305-1-ville.syrjala@linux.intel.com
Reviewed-by: Eric Anholt <eric@anholt.net>

display: panel: Add AUO g070vvn01 display support (800x480)

This commit adds support for AUO's 7.0" display.

Signed-off-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180514190849.18723-1-lukma@denx.de

gpu: drm: drm_vm: Adding new typedef vm_fault_t

Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.

commit 1c8f422059ae ("mm: change return type to vm_fault_t")

Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180510134203.GA25166@jordon-HP-15-Notebook-PC

drm/fb-helper: Fix typo on kerneldoc

Copypasta mistake.

Fixes: 742547b73d27 ("drm/fb_helper: Create wrappers for blit, copyarea and fillrect funcs")
Cc: Archit Taneja <architt@codeaurora.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Acked-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180524090105.21196-1-daniel.vetter@ffwll.ch

drm/sun4i: mark PM functions as __maybe_unused

Disabling CONFIG_PM produces a compile time warning when these
functions are not referenced:

drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1072:12: error: 'sun6i_dsi_runtime_suspend' defined but not used [-Werror=unused-function]
 static int sun6i_dsi_runtime_suspend(struct device *dev)
            ^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c:1043:12: error: 'sun6i_dsi_runtime_resume' defined but not used [-Werror=unused-function]
 static int sun6i_dsi_runtime_resume(struct device *dev)
            ^~~~~~~~~~~~~~~~~~~~~~~~

Fixes: 133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525155030.3667352-1-arnd@arndb.de

drm/atmel-hlcdc: Stop using plane->fb

We want to get rid of plane->fb on atomic drivers. Stop looking at it.

Daniel pointed out that the drm_framebuffer_put() in the plane cleanup
indicates that the driver doesn't shut things down cleanly. To do
that we should be able to just call drm_atomic_helper_shutdown(). Not
really sure the current cleanup sequence is actually sane, but whatever.

v2: Replace the drm_framebuffer_put() with
    drm_atomic_helper_shutdown() (Daniel)

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-10-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/omapdrm: Nuke omap_framebuffer_get_next_connector()

omap_framebuffer_get_next_connector() uses plane->fb which we want to
deprecate for atomic drivers. As omap_framebuffer_get_next_connector()
is unused just nuke the entire function.

Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-11-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>

drm: Add local 'plane' variable for tmp->primary

Clean up the ugly tmp->primary-> stuff in
__drm_mode_set_config_internal() with a local plane variable.

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-13-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/atmel-hlcdc: Stop consulting plane->crtc

We want to get rid of plane->crtc on atomic drivers. Stop looking at it.

Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-3-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/sti: Stop consulting plane->crtc

We want to get rid of plane->crtc on atomic drivers. Stop looking at it.

Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-2-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/msm: Stop consulting plane->fb/crtc

We want to get rid of plane->fb/crtc on atomic drivers. Stop
looking at them.

v2: Catch the plane->crtc case too

Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-1-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/arc: Stop consulting plane->fb

We want to stop using plane->fb with atomic driver, so stop looking at
it.

I have no idea what this code is trying to achieve. There is no
corresponding check in the enable path. Also since
arc_pgu_set_pxl_fmt() will anyway oops if there is no fb I'm going
to assuming that I can just remove the check entirely. There seems
to be a general shortage of .atomic_check() in this driver...

Cc: Alexey Brodkin <abrodkin@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405195035.24722-1-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Alexey Brodkin <abrodkin@synopys.com>

drm/edid: Fix up edid_cea_modes[] formatting

Fix up a bunch of bad indentation and insconsistent comments
in edid_cea_modes[].

v2: Instead of stripping the aspect ratio comments let's
    add them to all modes

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180524192035.9776-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>

drm/xen-front: fix pointer casts

Building for a 32-bit target results in warnings from casting
between a 32-bit pointer and a 64-bit integer. Fix the warnings
by casting those pointers to uintptr_t first.

Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180523113630.29811-1-andr2000@gmail.com

drm/i915: Pin the ring high

If we can use an unmappable ring, try to pin it out of the mappable
aperture. This simple layout preference is to try and keep the mappable
aperture reserved and available to handle GGTT mmapping requests from
userspace without causing evictions and GPU stalls.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180521082131.13744-4-chris@chris-wilson.co.uk

drm/i915: Limit searching for PIN_HIGH

To no surprise (since we've flip-flopped over the use of PIN_HIGH a few
times), doing a search by address over a pathologically fragmented
address space is exceeding slow. To protect ourselves from nearly
unbounded latency (think searching a million holes while under
struct_mutex), limit the search for the highest available hole and
fallback to best-fit if it fails.

In the pathologically fragmented case, such as igt/gem_ctx_thrash, the
effect is dramatic, bringing the runtime down from hours to seconds
(depending on how many other slow searches you hit, e.g. alloc_iova()
and alloc_vmap_area() both degrade to a slow rbtree walk after their
small cache is exhausted). For the real world, the number of search
steps is unlikely to be significant as we should only need to search
once per new context.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180521082131.13744-3-chris@chris-wilson.co.uk

drm/mm: Add a search-by-address variant to only inspect a single hole

Searching for an available hole by address is slow, as there no
guarantee that a hole will be available and so we must walk over all
nodes in the rbtree before we determine the search was futile. In many
cases, the caller doesn't strictly care for the highest available hole
and was just opportunistically laying out the address space in a
preferred order. In such cases, the caller can accept any address and
would rather do so then do a slow walk.

To be able to mix search strategies, the caller wants to tell the drm_mm
how long to spend on the search. Without a good guide for what should be
the best split, start with a request to try once at most. That is return
the top-most (or lowest) hole if it fulfils the alignment and size
requirements.

v2: Documentation, by why of example (selftests) and kerneldoc.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180521082131.13744-2-chris@chris-wilson.co.uk

drm/mm: Reject over-sized allocation requests early

As we keep an rbtree of available holes sorted by their size, we can
very easily determine if there is any hole large enough that might
satisfy the allocation request. This helps when dealing with a highly
fragmented address space and a request for a search by address.

To cache the largest size, we convert into the cached rbtree variant
which tracks the leftmost node for us. However, currently we sorted into
ascending size order so the leftmost node is the smallest, and so to
make it the largest hole we need to invert our sorting.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180521082131.13744-1-chris@chris-wilson.co.uk

gpu: drm: vgem: Change return type to vm_fault_t

Use new return type vm_fault_t for fault handler.

Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180416150232.GA26745@jordon-HP-15-Notebook-PC

gpu: drm: udl: Adding new typedef vm_fault_t

Use new return type vm_fault_t for fault and huge_fault
handler. For now, this is just documenting that the
function returns a VM_FAULT value rather than an errno.
Once all instances are converted, vm_fault_t will become
a distinct type.

Commit 1c8f422059ae ("mm: change return type to vm_fault_t")

Previously vm_insert_page() returns err which driver
mapped into VM_FAULT_* type. The new function vmf_
insert_page() will replace this inefficiency by
returning VM_FAULT_* type.

Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: Matthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180425045922.GA21590@jordon-HP-15-Notebook-PC

drm/i2c: tda998x: Remove VLA usage

There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The vla in reg_write_range is based on the length of data
passed. The one use of a non-constant size for this range is bounded by
the size buffer passed to hdmi_infoframe_pack which is a fixed size.
Switch to this upper bound.

[1] https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Laura Abbott <labbott@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411010330.17866-1-labbott@redhat.com

drm/gma500: Remove VLA

There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. Switch to a reasonable upper bound for the VLAs in
the gma500 driver.

[1] https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Laura Abbott <labbott@redhat.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180409210647.3718-1-labbott@redhat.com

drm/gma500: Fix Medfield for drm_framebuffer move

Commit bc61c97502e2 ("drm/gma500: Move GEM BO to drm_framebuffer") moved
the gtt_range structure, from being in psb_framebuffer and embedding the
GEM object, to being placed in the drm_framebuffer with the gtt_range
being derived from the GEM object.

The conversion missed out the Medfield subdriver, which was not being
built in the default drm-misc config. Do the trivial fixup here.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reported-by: kbuild test robot <lkp@intel.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Fixes: bc61c97502e2 ("drm/gma500: Move GEM BO to drm_framebuffer")
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180521142449.20800-1-daniels@collabora.com

drm/omap: Move buffer pitch/offset to drm_framebuffer

drm_framebuffer already holds per-plane pitch and offsets, which is
filled out for us when we create the framebuffer. Nuke our local copy in
the plane struct.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-7-daniels@collabora.com

drm/omap: Move GEM BO to drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-6-daniels@collabora.com

drm/v3d: Checking for NULL vs IS_ERR()

The v3d_fence_create() only returns error pointers on error.  It never
returns NULL.

Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D V3.x+")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518081041.GC28335@mwanda

drm/rockchip: lvds: avoid duplicating drm_bridge_attach

drm_bridge_attach takes care of these assignments, so there is no need
to open-code them a second time.

Signed-off-by: Peter Rosin <peda@axentia.se>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180502074025.12421-3-peda@axentia.se

drm/rockchip: rockchip_drm_fb -> drm_framebuffer

Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
can remove it.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Heiko Stübner <heiko@sntech.de>
Tested-by: Heiko Stübner <heiko@sntech.de>
Cc: Sandy Huang <hjc@rock-chips.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-5-daniels@collabora.com

drm/rockchip: Place GEM BOs in drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Acked-by: Heiko Stübner <heiko@sntech.de>
Tested-by: Heiko Stübner <heiko@sntech.de>
Cc: Sandy Huang <hjc@rock-chips.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-4-daniels@collabora.com

drm/mtk: mtk_drm_fb -> drm_framebuffer

Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can
just delete it.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518134705.12533-3-daniels@collabora.com

drm/mtk: Move GEM BO to drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518134705.12533-2-daniels@collabora.com

drm/mtk: Remove impossible internal error

We cannot create a framebuffer with no objects, so there's no point
testing for it.

v2: Remove the error entirely. (Sean, CK, Thierry)

Signed-off-by: Daniel Stone <daniels@collabora.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: CK Hu <ck.hu@mediatek.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518134705.12533-1-daniels@collabora.com

drm/msm: Move GEM BOs to drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle function the same as the GEM framebuffer helper, we
can reuse that.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: linux-arm-msm@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-21-daniels@collabora.com

drm/gma500: Move GEM BO to drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-20-daniels@collabora.com

drm/armada: Move GEM BO to drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Reviewed-by: Russell King <linux@armlinux.org.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-19-daniels@collabora.com

drm/virtio: Place GEM BOs in drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-3-daniels@collabora.com

drm/cirrus: cirrus_framebuffer -> drm_framebuffer

Now cirrus_framebuffer is just an empty wrapper around drm_framebuffer,
we can drop it.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-2-daniels@collabora.com

drm/cirrus: Place GEM BOs in drm_framebuffer

Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass. As this makes the framebuffer
create_handle and destroy functions the same as the GEM framebuffer
helper, we can reuse those.

Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtualization@lists.linux-foundation.org
Link: https://patchwork.freedesktop.org/patch/msgid/20180330141138.28987-1-daniels@collabora.com

drm/panel: simple: Fix data type in KEO TX31D200VM0BAA timings

All values in a struct struct timing_entry (every entry in
struct display_timing) require an integer. Choose the closest
safe integer of 32.

This avoids a warning seen with clang:
  drivers/gpu/drm/panel/panel-simple.c:1250:27: warning: implicit
       conversion from 'double' to 'u32' (aka 'unsigned int')
       changes value from 33.5 to 33 [-Wliteral-conversion]
         .vfront_porch = { 6, 21, 33.5 },
                         ~        ^~~~
  drivers/gpu/drm/panel/panel-simple.c:1251:26: warning: implicit
        conversion from 'double' to 'u32' (aka 'unsigned int')
        changes value from 33.5 to 33 [-Wliteral-conversion]
          .vback_porch = { 6, 21, 33.5 },
                         ~        ^~~~

Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180419212003.8155-1-stefan@agner.ch

drm/panel: simple: AUO P320HVN03 uses SPWG data ordering

The patch adding support for the AUO P320HVN03 panel was written against a
preliminary datasheet, which specified JEIDA data ordering. Testing with
real hardware has shown that the actually used data ordering is SPWG.

Fixes: 70c0d5b783f5 (drm/panel: simple: add support for AUO P320HVN03)
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411152741.22483-1-l.stach@pengutronix.de

drm/panel: simple: Add Innolux TV123WAM panel driver support

Add support for Innolux TV123WAM, which is a 12.3" eDP display panel
with 2160x1440 resolution.

Changes in v1:
 - Add the compatibility string, display_mode and panel_desc
   structures in alphabetical order (Sean Paul).

Signed-off-by: Sandeep Panda <spanda@codeaurora.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526363564-13823-4-git-send-email-spanda@codeaurora.org

dt-bindings: drm/panel: Document Innolux TV123WAM panel bindings

Innolux TV123WAM is a 12.3" eDP display panel with
2160x1440 resolution, which can be supported by simple
panel driver.

Changes in v1:
 - Make use of simple panel driver instead of creating
   a new driver for this panel (Sean Paul).
 - Combine dt-binding and driver changes into one patch
   as done by other existing panel support changes.

Changes in v2:
 - Separate driver change from dt-binding documentation (Rob Herring).
 - Add the properties from simple-panel binding that are applicable to
   this panel (Rob Herring).

Signed-off-by: Sandeep Panda <spanda@codeaurora.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526363564-13823-5-git-send-email-spanda@codeaurora.org

drm/bridge: cdns: Mark runtime PM operations as maybe unused

Building the driver in a configuration with !PM currently causes a
warning about these operations being unused. Mark them as such to shut
up the compiler.

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180426135853.30895-1-thierry.reding@gmail.com

drm/panel: otm8009a: Use new backlight API

The backlight API provides new functions to enable and disable the
backlight and which hide the intricacies of achieving the correct
result.

Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180423141054.13128-5-philippe.cornu@st.com

drm/panel: otm8009a: No message if probe success

Remove the message in case of probe success. This comes from a
suggestion followed in the recent integration of the raydium rm68200
panel.

Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180423141054.13128-4-philippe.cornu@st.com

drm/panel: otm8009a: Fix glitches by moving backlight enable to otm8009a_enable()

The backlight 1st update was in the otm8009a_prepare() function for a
bad reason: backlight was not working in video mode and the
otm8009a_prepare() is in command mode for the init sequence. As the
backlight is now fixed (no low-power mode), it is good to put it back
in the otm8009a_enable() function, avoiding also image glitches visible
on some "slow" devices.

Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180423141054.13128-3-philippe.cornu@st.com

drm/panel: otm8009a: Fix backlight updates

Backlight updates was not working anymore since the good implementation
of the DSI low-power mode in the DSI host driver. After a longer
analysis, the backlight updates in DSI video mode require the DSI high-
speed mode.

Note: it is important to keep the DSI low-power mode for the rest of the
driver as init sequence, sleep in/out... DSI commands work in low-power
mode.

Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180423141054.13128-2-philippe.cornu@st.com

drm/panel: Add device_link from panel device to DRM device

Add device_link from panel device (supplier) to DRM device (consumer)
when drm_panel_attach() is called. This patch should protect the master
DRM driver if an attached panel driver unbinds while it is in use. The
device_link should make sure the DRM device is unbound before the panel
driver becomes unavailable.

The device_link is removed when drm_panel_detach() is called. The
drm_panel_detach() should be called by the consumer DRM driver, not the
panel driver, otherwise both drivers are racing to delete the same link.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b53584fd988d045c13de22d81825395b0ae0aad7.1524727888.git.jsarha@ti.com

drm/panel: Remove drm_panel_detach() calls from all panel drivers

Remove all drm_panel_detach() calls from all panel drivers and update
the kerneldoc for drm_panel_detach().

Setting the connector and drm to NULL when the DRM panel device is going
away hardly serves any purpose. Usually the whole memory structure is
freed right after the remove call. However, calling the detach function
from the master DRM device, and setting the connector pointer to NULL,
has the logic of marking the panel again as available for another DRM
master to attach. The usual situation would be the same DRM master
device binding again.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/464b8d330d6b4c94cfb5aad2ca9ea7eb2c52d934.1524727888.git.jsarha@ti.com

i915: content-type property for HDMI connector

Added encoding of drm content_type property from drm_connector_state
within AVI infoframe in order to properly handle external HDMI TV
content-type setting.

This requires also manipulationg ITC bit, as stated in
HDMI spec.

v2:
 * Moved helper function which attaches content type property
   to the drm core, as was suggested.
   Removed redundant connector state initialization.

v3:
 * Removed caps in drm_content_type_enum_list.
   After some discussion it turned out that HDMI Spec 1.4
   was wrongly assuming that IT Content(itc) bit doesn't affect
   Content type states, however itc bit needs to be manupulated
   as well. In order to not expose additional property for itc,
   for sake of simplicity it was decided to bind those together
   in same "content type" property.

v4:
 * Added it_content checking in intel_digital_connector_atomic_check.
   Fixed documentation for new content type enum.

v5:
 * Moved patch revision's description to commit messages.

v6:
 * Minor naming fix for the content type enumeration string.

v7:
 * Fix parameter name for documentation and parameter alignment
   in order not to get warning. Added Content Type description to
   new HDMI connector properties section.

v8:
 * Thrown away unneeded numbers from HDMI content-type property
   description. Switch to strings desription instead of plain
   definitions.

v9:
 * Moved away hdmi specific content-type enum from
   drm_connector_state. Content type property should probably not
   be bound to any specific connector interface in
   drm_connector_state.
   Same probably should be done to hdmi_picture_aspect_ration enum
   which is also contained in drm_connector_state. Added special
   helper function to get derive hdmi specific relevant infoframe
   fields.

v10:
 * Added usage description to HDMI properties kernel doc.

v11:
 * Created centralized function for filling HDMI AVI infoframe, based
   on correspondent DRM property value.

Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-3-stanislav.lisovskiy@intel.com
[vsyrjala: clean up checkpatch multiple blank lines warnings]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm: content-type property for HDMI connector

Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.

v2:
 * Moved helper function which attaches content type property
   to the drm core, as was suggested.
   Removed redundant connector state initialization.

v3:
 * Removed caps in drm_content_type_enum_list.
   After some discussion it turned out that HDMI Spec 1.4
   was wrongly assuming that IT Content(itc) bit doesn't affect
   Content type states, however itc bit needs to be manupulated
   as well. In order to not expose additional property for itc,
   for sake of simplicity it was decided to bind those together
   in same "content type" property.

v4:
 * Added it_content checking in intel_digital_connector_atomic_check.
   Fixed documentation for new content type enum.

v5:
 * Moved patch revision's description to commit messages.

v6:
 * Minor naming fix for the content type enumeration string.

v7:
 * Fix parameter name for documentation and parameter alignment
   in order not to get warning. Added Content Type description to
   new HDMI connector properties section.

v8:
 * Thrown away unneeded numbers from HDMI content-type property
   description. Switch to strings desription instead of plain
   definitions.

v9:
 * Moved away hdmi specific content-type enum from
   drm_connector_state. Content type property should probably not
   be bound to any specific connector interface in
   drm_connector_state.
   Same probably should be done to hdmi_picture_aspect_ration enum
   which is also contained in drm_connector_state. Added special
   helper function to get derive hdmi specific relevant infoframe
   fields.

v10:
 * Added usage description to HDMI properties kernel doc.

v11:
 * Created centralized function for filling HDMI AVI infoframe, based
   on correspondent DRM property value.

Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-2-stanislav.lisovskiy@intel.com
[vsyrjala: clean up checkpatch multiple blank lines warnings]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

drm/bridge: spelling and coding style minor fixes

Minor fixes detected with "scripts/checkpatch.pl --strict"

Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180515203736.9224-1-philippe.cornu@st.com

drm/vc4: plane: Expand the lower bits by repeating the higher bits

The vc4 HVS uses an internal RGB888 representation of the frames, and will
by default expand formats using a lower depth using zeros.

This causes an issue when we try to use other compositing software such as
pixman that fill the missing bits by repeating the higher significant bits.
As such, we can't check the display output in a reliable way by doing a
software composition and an hardware one and compare both.

To prevent this, force the same behaviour so that we can do such things.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517133759.25626-1-maxime.ripard@bootlin.com

drm: clarify adjusted_mode documentation for bridges

This patch clarifies the adjusted_mode documentation
for bridges.

Signed-off-by: Philippe Cornu <philippe.cornu@st.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180409152427.12449-1-philippe.cornu@st.com

drm/xen-front: fix spelling mistake: "conector" -> "connector"

Trivial fix to spelling mistake in DRM_INFO message.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180515085433.8245-1-colin.king@canonical.com

gpu: drm: qxl: Adding new typedef vm_fault_t

Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.

Reference id -> 1c8f422059ae ("mm: change return type to
vm_fault_t")

Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20180417133844.GA30256@jordon-HP-15-Notebook-PC
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

drm/virtio: add define for second capset to the virgl code.

Although the kernel doesn't use this, qemu imports these headers
and it's best to keep them consistent.

This define is also something userspace may want to use.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20180503021021.10694-1-airlied@gmail.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>

drm: Fix render node numbering regression from control node removal.

drm_minor_alloc() does multiplication on this enum, so the removal
ended up moving render nodes down from 128 base to 64.  This caused
Mesa's surfaceless backend to be unable to open the render nodes,
since it was still looking up at 128.

v2: Add a comment warning the next person.

Signed-off-by: Eric Anholt <eric@anholt.net>
Fixes: 0d49f303e8a7 ("drm: remove all control node code")
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180509001425.12574-1-eric@anholt.net

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

drm-misc-next is still based on v4.16-rc7, and was getting a bit stale.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

drm: Add and handle new aspect ratios in DRM layer

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch:
-  Adds new DRM flags for to represent these new aspect ratios.
-  Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.

This patch was once reviewed and merged, and later reverted due
to lack of DRM client protection, while adding aspect ratio bits
in user modes. This is a re-spin of the series, with DRM client
cap protection.

The previous series can be found here:
https://pw-emeril.freedesktop.org/series/10850/

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org> (V2)
Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> (V2)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: rebase
V4: rebase
V5: corrected the macro name for an aspect ratio, in a switch case.
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: rebase
V12: rebase
V13: rebase
V14: rebase

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-11-git-send-email-ankit.k.nautiyal@intel.com

drm: Add aspect ratio parsing in DRM layer

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Background:
This patch was once reviewed and merged, and later reverted due to
lack of DRM cap protection. This is a re-spin of this patch, this
time with DRM cap protection, to avoid aspect ratio information, when
the client doesn't request for it.

link: https://pw-emeril.freedesktop.org/patch/104068/
Background discussion: https://patchwork.kernel.org/patch/9379057/

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Lin, Jia <lin.a.jia@intel.com>
Signed-off-by: Akashdeep Sharma <akashdeep.sharma@intel.com>
Reviewed-by: Jim Bride <jim.bride@linux.intel.com> (V2)
Reviewed-by: Jose Abreu <Jose.Abreu@synopsys.com> (V4)
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: modified the aspect-ratio check in drm_mode_equal as per new flags
    provided by Ville. https://patchwork.freedesktop.org/patch/188043/
V4: rebase
V5: rebase
V6: As recommended by Ville, avoided matching of aspect-ratio in
    drm_fb_helper, while trying to find a common mode among connectors
    for the target clone mode.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: rebase
V12: rebase
V13: rebase
V14: rebase

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-10-git-send-email-ankit.k.nautiyal@intel.com

drm: Expose modes with aspect ratio, only if requested

We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regardless of
whether user space requested this information or not.

This patch:
-prunes the modes with aspect-ratio information, from the
 drm_mode_get_connector modelist supplied to the user, if the
 user-space has not set the aspect ratio DRM client cap. However if
 such a mode is unique in the list, it is kept in the list, with
 aspect-ratio flags reset.
-prepares a list of exposed modes, which is used to find unique modes
 if aspect-ratio is not allowed.
-adds a new list_head 'exposed_head' in drm_mode_display, to traverse
 the list of exposed modes.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Jose Abreu <jose.abreu@synopsys.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: As suggested by Ville, modified the mechanism of pruning of modes
    with aspect-ratio, if the aspect-ratio is not supported. Instead
    of straight away pruning such a mode, the mode is retained with
    aspect ratio bits set to zero, provided it is unique.
V4: rebase
V5: Addressed review comments from Ville:
    -used a pointer to store last valid mode.
    -avoided, modifying of picture_aspect_ratio in kernel mode,
     instead only flags bits of user mode are reset (if aspect-ratio
     is not supported).
V6: As suggested by Ville, corrected the mode pruning logic and
    elaborated the mode pruning logic and the assumptions taken.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: Fixed the issue caused in kms_3d test, and enhanced the pruning
     logic to correctly identify and prune modes with aspect-ratio,
     if aspect-ratio cap is not set.
V12: As suggested by Ville, added another list_head in
     drm_mode_display to traverse the list of exposed modes and
     avoided duplication of modes.
V13: Minor modifications, as suggested by Ville.
v14: As suggested by Daniel Vetter and Ville Syrjala, corrected the
     pruning logic to avoid any dependency in the order of mode with
     aspect-ratio.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-9-git-send-email-ankit.k.nautiyal@intel.com

drm: Handle aspect ratio info in legacy modeset path

If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not be given, if aspect-ratio
is not supported by the user.

This patch:
1. rejects the modes with aspect-ratio info, during modeset, if the
   user does not support aspect ratio.
2. does not load the aspect-ratio info in user-mode structure, if
   aspect ratio is not supported.
3. adds helper functions for determining if aspect-ratio is expected
   in user-mode and for allowing/disallowing the aspect-ratio, if its
   not expected.

Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: Addressed review comments from Ville:
    Do not corrupt the current crtc state by updating aspect-ratio on
    the fly.
V4: rebase
V5: As suggested by Ville, rejected the modeset calls for modes with
    aspect ratio, if the user does not set aspect-ratio cap.
V6: Used the helper functions for determining if aspect-ratio is
    expected in the user-mode.
V7: rebase
V8: rebase
V9: rebase
V10: Modified the commit-message
V11: rebase
V12: Merged the patch for adding aspect-ratio helper functions
     with this patch.
V13: Minor modifications as suggested by Ville.
V14: Removed helper functions, as they were used only once in legacy
     modeset path, as suggested by Daniel Vetter.

Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-8-git-send-email-ankit.k.nautiyal@intel.com

drm: Add DRM client cap for aspect-ratio

To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
non-atomic user-spaces which have no intention or support to use this
aspect ratio information.

To avoid this, a new drm client cap is required to enable a non-atomic
user-space to advertise if it supports modes with aspect-ratio. Based
on this cap value, the kernel will take a call on exposing the aspect
ratio info in modes or not.

This patch adds the client cap for aspect-ratio.

Since no atomic-userspaces blow up on receiving aspect-ratio
information, the client cap for aspect-ratio is always enabled
for atomic clients.

Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
V3: rebase
V4: As suggested by Marteen Lankhorst modified the commit message
    explaining the need to use the DRM cap for aspect-ratio. Also,
    tweaked the comment lines in the code for better understanding and
    clarity, as recommended by Shashank Sharma.
V5: rebase
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: rebase
V12: As suggested by Daniel Vetter and Ville Syrjala,
     always enable aspect-ratio client cap for atomic userspaces,
     if no atomic userspace breaks on aspect-ratio bits.
V13: rebase
V14: rebase

Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-7-git-send-email-ankit.k.nautiyal@intel.com

video/hdmi: Reject illegal picture aspect ratios

AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: "Lin, Jia" <lin.a.jia@intel.com>
Cc: Akashdeep Sharma <akashdeep.sharma@intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Hans Verkuil <hans.verkuil@cisco.com>
Cc: linux-media@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jose Abreu <joabreu@synopsys.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-6-git-send-email-ankit.k.nautiyal@intel.com

drm/edid: Don't send bogus aspect ratios in AVI infoframes

If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.

Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of signalling none,
4:3, and 16:9. Currently we're sending these bogus infoframes
whenever the cea mode specifies some other aspect ratio.

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-5-git-send-email-ankit.k.nautiyal@intel.com

drm/edid: Fix cea mode aspect ratio handling

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: "Lin, Jia" <lin.a.jia@intel.com>
Cc: Akashdeep Sharma <akashdeep.sharma@intel.com>
Cc: Jim Bride <jim.bride@linux.intel.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525777785-9740-4-git-send-email-ankit.k.nautiyal@intel.com