Due to the fact that writeback connectors behave in a special way
in DRM (they always report being disconnected) we might confuse some
userspace. Add a client capability for writeback connectors that will
filter them out for clients that don't understand the capability.

Changelog:
 - only accept the capability if the client has already set the
DRM_CLIENT_CAP_ATOMIC one.

Cc: Sean Paul <seanpaul@chromium.org>
Cc: Brian Starkey <brian.starkey@arm.com>
Signed-off-by: NLiviu Dudau <liviu.dudau@arm.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NBrian Starkey <brian.starkey@arm.com>
Link: https://patchwork.freedesktop.org/patch/229038/

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 7e9081c5 ("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: NBrian Starkey <brian.starkey@arm.com>
[rebased and fixed conflicts]
Signed-off-by: NMihail Atanassov <mihail.atanassov@arm.com>
Signed-off-by: NLiviu Dudau <liviu.dudau@arm.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/229036/

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: NBrian Starkey <brian.starkey@arm.com>
[rebased and fixed conflicts]
Signed-off-by: NMihail Atanassov <mihail.atanassov@arm.com>
[rebased and added atomic_commit() vfunc for writeback jobs]
Signed-off-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NLiviu Dudau <liviu.dudau@arm.com>
Reviewed-by: NEric Anholt <eric@anholt.net>
Link: https://patchwork.freedesktop.org/patch/229037/

Neither used nor correctly implemented anywhere. Just completely remove
the interface.
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NSumit Semwal <sumit.semwal@linaro.org>
Link: https://patchwork.freedesktop.org/patch/226645/

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

v2: fix kerneldoc as well
Signed-off-by: NChristian König <christian.koenig@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/226643/

Same justification as for drm_gem_fb_prepare_fb.

Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: NEric Anholt <eric@anholt.net>
Signed-off-by: NDaniel 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

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

commit 25067bfc
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 ea2c67bb
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 cf3a7e4c
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: NEric Anholt <eric@anholt.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405154449.23038-8-daniel.vetter@ffwll.ch

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: d0b912bd ("iommu/rockchip: Request irqs in rk_iommu_probe()")
Cc: stable@vger.kernel.org
Signed-off-by: NSandy Huang <hjc@rock-chips.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NEzequiel Garcia <ezequiel@collabora.com>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180612132028.27490-3-heiko@sntech.de

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: d0b912bd ("iommu/rockchip: Request irqs in rk_iommu_probe()")
[prerequisite change for the actual fix]
Cc: stable@vger.kernel.org
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Tested-by: NEzequiel Garcia <ezequiel@collabora.com>
Reviewed-by: NTomasz Figa <tfiga@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20180612132028.27490-2-heiko@sntech.de

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: NHaneen Mohammed <hamohammed.sa@gmail.com>
Reviewed-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525012555.GA8448@haneen-vb

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: NChris Zhong <zyw@rock-chips.com>
Signed-off-by: NLin Huang <hl@rock-chips.com>
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/1526979222-32478-1-git-send-email-hl@rock-chips.com

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

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: NAlexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1527701452-1934-1-git-send-email-alexandru-cosmin.gheorghe@arm.comSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Print out the modeline when we reject a bad user mode. Avoids having to
guess why it was rejected.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180611193403.16118-2-ville.syrjala@linux.intel.comReviewed-by: NHarry Wentland <harry.wentland@amd.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180611193403.16118-1-ville.syrjala@linux.intel.comReviewed-by: NHarry Wentland <harry.wentland@amd.com>

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: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1527154379-31886-1-git-send-email-inki.dae@samsung.com

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: NHarry Wentland <harry.wentland@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-14-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>

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

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

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-12-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v1
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-11-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NInki Dae <inki.dae@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-10-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v1
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-9-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-8-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-7-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-6-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-5-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDeepak Rawat <drawat@vmware.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-4-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-3-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525185045.29689-2-ville.syrjala@linux.intel.comReviewed-by: NSinclair Yeh <syeh@vmware.com>

This adds the Vive Pro's EDID information and
sets EDID_QUIRK_NON_DESKTOP.
Signed-off-by: NLubosz Sarnecki <lubosz.sarnecki@collabora.com>
Signed-off-by: NDaniel Stone <daniels@collabora.com>
Reviewed-by: NDaniel 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

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

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

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: NDave Stevenson <dave.stevenson@raspberrypi.org>
Signed-off-by: NEric 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

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: NEric Anholt <eric@anholt.net>
Acked-by: NDaniel Stone <daniels@collabora.com>
Cc: Dave Stevenson <dave.stevenson@raspberrypi.org>
Fixes: 423ad7b3 ("drm/vc4: Advertise supported modifiers for planes")
Link: https://patchwork.freedesktop.org/patch/msgid/20180316220435.31416-2-eric@anholt.net

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: NEric 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.netReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

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.htmlSigned-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518162159.30305-1-ville.syrjala@linux.intel.comReviewed-by: NEric Anholt <eric@anholt.net>

This commit adds support for AUO's 7.0" display.
Signed-off-by: NLukasz Majewski <lukma@denx.de>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NThierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180514190849.18723-1-lukma@denx.de

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 1c8f4220 ("mm: change return type to vm_fault_t")
Signed-off-by: NSouptick Joarder <jrdr.linux@gmail.com>
Reviewed-by: NMatthew Wilcox <mawilcox@microsoft.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180510134203.GA25166@jordon-HP-15-Notebook-PC

Copypasta mistake.

Fixes: 742547b7 ("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: NNoralf Trønnes <noralf@tronnes.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180524090105.21196-1-daniel.vetter@ffwll.ch

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: 133add5b ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller support")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180525155030.3667352-1-arnd@arndb.de

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: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405151400.11326-10-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>