Add function drm_fb_cma_get_gem_addr() which return the physical address
of framebuffer (1st pixel). This function will usually be called by plane
callback (atomic_update).
Signed-off-by: Yannick Fertre <yannick.fertre@st.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Link: http://patchwork.freedesktop.org/patch/msgid/1492164819-10513-3-git-send-email-yannick.fertre@st.com
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This is needed for proper synchronization with display on another DRM
device (pl111 or tinydrm) with buffers produced by vc4 V3D. Fixes the
new igt vc4_dmabuf_poll testcase, and rendering of one of the glmark2
desktop tests on pl111+vc4.
This doesn't yet introduce waits on another device's fences before
vc4's rendering/display, because I don't have testcases for them.
v2: Reuse dma_fence_free(), retitle commit message to clarify that
it's not a full dma-buf fencing implementation yet.
Signed-off-by: Eric Anholt <eric@anholt.net>
Link: http://patchwork.freedesktop.org/patch/msgid/20170412191202.22740-6-eric@anholt.net
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add Laurent as a reviewer and Andrzej as a maintainer for DRM bridge chip
drivers. They actively review and contribute to bridge drivers and the
bridge API.
Acked-by: Andrzej Hajda <a.hajda@samsung.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170410063641.17704-1-architt@codeaurora.org
This reverts
commit b8dfa821c2
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Apr 7 12:17:12 2017 +0100
drm: Don't allow interruptions when opening debugfs/crc
It reportedly breaks things, so let's revert now and try again later.
Fixes: b8dfa821c2 ("drm: Don't allow interruptions when opening debugfs/crc")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
I thought I've fixed this, but maybe not. Anyway, clearly broken, and
easy fix.
Cc: Tony Lindgren <tony@atomide.com>
Reported-by: Tony Lindgren <tony@atomide.com>
Fixes: b95ff0319a ("drm: Remove drm_modeset_(un)lock_crtc")
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170407164817.28272-1-daniel.vetter@ffwll.ch
I've broken this by removing the backoff handling from the
set_config2atomic helper in
commit 38b6441e4e
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Mar 22 22:50:58 2017 +0100
drm/atomic-helper: Remove the backoff hack from set_config
Fixing this properly would mean we get to wire the acquire_ctx all the
way through vmwgfx fbdev code, and doing the same was tricky for the
shared fbdev layer. Probably much better to look into refactoring the
entire code to use the helpers, but since that's not a viable
long-term solution fix the issue by open-coding a vmwgfx version of
set_config, that does the legacy backoff dance internally.
Note: Just compile-tested. The idea is to take
drm_mode_set_config_internal(), remove the "is this a legacy driver"
check, and whack the drm_atomic_legacy_backoff trickery at the end.
Since drm_atomic_legacy_backoff is for atomic commits only we need to
open-code it.
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/20170406200256.26040-1-daniel.vetter@ffwll.ch
Current drm bind/unbind sequence would cause some memory issues.
For example we should not cleanup iommu before cleanup mode config.
Reorder bind/unbind sequence, follow exynos drm.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
[seanpaul fixed spelling typo in commit subject]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1491481885-13775-11-git-send-email-jeffy.chen@rock-chips.com
We're trying to access vop registers here, so need to make sure
the pm domain is on.
Normally it should be enabled by the bootloader, but there's no
guarantee of it. And if we wanna do unbind/bind, it would also
cause the device to hang.
And this patch also does these:
1/ move vop_initial to the end of vop_bind for eaiser error handling.
2/ correct the err_put_pm_runtime of vop_enable.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1491481885-13775-8-git-send-email-jeffy.chen@rock-chips.com
After snd_soc_unregister_codec, the dai link would remain bound to
the invalid codec. That would cause crashes after unbind dp driver.
Let's unregister audio codec when removing dp driver to prevent that.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1491481885-13775-7-git-send-email-jeffy.chen@rock-chips.com
Normally we do this in drm_mode_config_cleanup. But:
1/ analogix dp's connector is allocated in bind, and freed after unbind.
So we need to destroy it in unbind to avoid further access.
2/ the drm bridge is attached in bind, and detached in encoder cleanup.
So we need to destroy encoder in unbind.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1491481885-13775-5-git-send-email-jeffy.chen@rock-chips.com
The plat_data->input_bus_format and plat_data->input_bus_encoding
are unsigned long and are always >=0, but the value 0 was still
considered as RGB888 for input_bus_format and default color space
for input_bus_encoding in the reworked code.
This patch changes the if statement check for a non-zero value to
either use the default input bus_format and/or bus_encoding for a zero
value and the provided bus_format and/or bus_encoding for a
non zero value.
Thanks to Dan Carpenter for his bug report at [1].
Tested on Amlogic P230 (with CSC enabled for YUV444 to RGB) and Rockchip
RK3288 ACT8846 EVB Board (no CSC involved, direct RGB passthrough).
[1] http://lkml.kernel.org/r/20170406052120.GA26578@mwanda
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: def23aa7e9 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Archit Taneja <architt@codeaurora.org>
[narmstrong@baylibre.com: reworded commit message and added Fixes tag]
Link: http://patchwork.freedesktop.org/patch/msgid/1491471244-24989-1-git-send-email-narmstrong@baylibre.com
The OMAP driver has its own OF graph helpers that are similar to the
common helpers. This commit replaces most of the calls with the common
helpers. There's still a couple of custom helpers left, but the driver
needs more extensive changes to get rid of them.
In dss_init_ports, we invert the loop, looping through the known ports
and matching them to DT nodes rather than looping thru DT nodes and
matching them to the ports.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Similar to the previous commit, convert drivers open coding OF graph
parsing to use drm_of_find_panel_or_bridge instead.
This changes some error messages to debug messages (in the graph core).
Graph connections are often "no connects" depending on the particular
board, so we want to avoid spurious messages. Plus the kernel is not a
DT validator.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Archit Taneja <architt@codeaurora.org>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
[seanpaul dropped rockchip changes since they're now obsolete]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Convert drivers to use the new of_graph_get_remote_node() helper
instead of parsing the endpoint node and then getting the remote device
node. Now drivers can just specify the device node and which
port/endpoint and get back the connected remote device node. The details
of the graph binding are nicely abstracted into the core OF graph code.
This changes some error messages to debug messages (in the graph core).
Graph connections are often "no connects" depending on the particular
board, so we want to avoid spurious messages. Plus the kernel is not a
DT validator.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Tested-by: Liviu Dudau <liviu.dudau@arm.com>
Tested-by: Eric Anholt <eric@anholt.net>
Tested-by: Jyri Sarha <jsarha@ti.com>
Tested by: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Many drivers have a common pattern of searching the OF graph for either an
attached panel or bridge and then finding the DRM struct for the panel
or bridge. Also, most drivers need to handle deferred probing when the
DRM device is not yet instantiated. Create a common function,
drm_of_find_panel_or_bridge, to find the connected node and the
associated DRM panel or bridge device.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
[seanpaul dropped extern from drm_of.h]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
For drm_of_find_panel_or_bridge() added in the next commit, an empty
version of of_drm_find_panel is needed for !CONFIG_DRM_PANEL.
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
The atomic_check function is useful for implementing properties, but
it can be used for other connector modeset related checks as well.
Similar to plane check functions, on a modeset atomic_check() is always
called.
Changes since v1:
- Make sure atomic_check() is called on any modeset.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1491477543-31257-5-git-send-email-maarten.lankhorst@linux.intel.com
Now that handle_conflicting_encoders no longer touches active state,
so there's no need to do the check quite that late any more.
Doing it with all the other checks makes it a lot more clear what the
below block tries to accomplish, and this feels like a better place to
put the check.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1491477543-31257-4-git-send-email-maarten.lankhorst@linux.intel.com
Now that handle_conflicting_encoders cannot disable crtc's any more
it makes sense to set all the changed flags in 1 place.
This makes the code slightly less magical.
The (now removed) comment is out of date. The only reason the
active_changed was set late was because handle_conflicting_encoders
could disable connectors. This is no longer the case,
and we can put everything in 1 place.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1491477543-31257-3-git-send-email-maarten.lankhorst@linux.intel.com
Currently we use a flag to change behavior in atomic commit
whether a conflicting encoder should be enabled or disabled.
This is used for the legacy set_config helper, which disables
connectors that have a conflicting encoder but not part of the
active crtc list.
There's no need for this to be handled in atomic commit, it
could be done in the set_config helper instead. This will
let the atomic check function reject any conflicting encoders,
while set_config can disable conflicting crtc's. This makes it
possible to recalculate the changed flags in 1 loop.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1491477543-31257-2-git-send-email-maarten.lankhorst@linux.intel.com
Legacy drivers insist that we really take all the locks in this path,
and the harm in doing so is minimal.
v2: Like git add, it exists :(
Fixes: 2ceb585a95 ("drm: Add explicit acquire ctx handling around ->set_config")
Cc: Harry Wentland <harry.wentland@amd.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: Alex Deucher <alexdeucher@gmail.com>
Reported-by: Alex Deucher <alexdeucher@gmail.com>
Acked-and-tested-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170406190654.6733-1-daniel.vetter@ffwll.ch
mode_valid() called from drm_helper_probe_single_connector_modes()
may need to look at connector->state because what a valid mode is may
depend on connector properties being set. For example some HDMI modes
might be rejected when a connector property forces the connector
into DVI mode.
Some implementations of detect() already lock all state,
so we have to pass an acquire_ctx to them to prevent a deadlock.
This means changing the function signature of detect() slightly,
and passing the acquire_ctx for locking multiple crtc's.
For the callbacks, it will always be non-zero. To allow callers
not to worry about this, drm_helper_probe_detect_ctx is added
which might handle -EDEADLK for you.
Changes since v1:
- Always set ctx parameter.
Changes since v2:
- Always take connection_mutex when probing.
Changes since v3:
- Remove the ctx from intel_dp_long_pulse, and add
WARN_ON(!connection_mutex) (danvet)
- Update docs to clarify the locking situation. (danvet)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1491504920-4017-1-git-send-email-maarten.lankhorst@linux.intel.com
When we use virtio-vga with a big-endian guest,
the mouse pointer disappears.
To fix that, on big-endian use DRM_FORMAT_BGRA8888
instead of DRM_FORMAT_ARGB8888.
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170405080915.823-1-lvivier@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
There was supposed to be a break before the next case statement.
Fixes: def23aa7e9 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170406052132.GA26605@mwanda
The goal is to push all the kms locking down into these separate
_atomic and _legacy functions, so that we can correctly pass the
acquire ctx into all atomic drivers. Instead of playing games with
hidden ctx in mode_config.acquire_ctx. All the fbdev state will be
protected by a new fbdev private lock that Thierry is working on.
This here is just prep by creating a clean split between atomic and
legacy paths, which also simplifies the control flow a bit.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-16-daniel.vetter@ffwll.ch
I got confused every time I audited what that lock_all is doing in
there until realizing it's for legacy kms only. Make that a notch more
obvious by having 2 entirely different paths.
While at it also move the atomic version of this into
drm_framebuffer.c, there's no reason it needs to be in drm_atomic.c.
That way it becomes a simple static function.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-15-daniel.vetter@ffwll.ch
Another one knocked down.
With this we can also remove the temporary hack in the gamma_set
ioctl.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-14-daniel.vetter@ffwll.ch
Atomic helpers really want this instead of the hacked-up legacy
backoff trick, which unfortunately prevents drivers from using their
own private drm_modeset_locks.
Aside: There's a few atomic drivers (nv50, vc4, soon vmwgfx) which
don't yet use the new atomic color mgmt/gamma table stuff. Would be
nice if they could switch over and just hook up
drm_atomic_helper_legacy_gamma_set() instead.
Cc: Dave Airlie <airlied@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Sinclair Yeh <syeh@vmware.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Eric Anholt <eric@anholt.net>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-13-daniel.vetter@ffwll.ch
Just the groundwork to prepare for adding the acquire cxt parameter to
the ->gamma_set hook. Again we need a temporary hack to fill out
mode_config.acquire_ctx until the atomic helpers are switched over.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-12-daniel.vetter@ffwll.ch
It just doesn't work. It probably stopped working way, way before that
(e.g. i915 grabbed random mutexes all over in modeset code at least
since gen6), but with atomic and all the ww_mutex stuff it's indeed
hopeless.
Remove ->mode_set_base_atomic from the 2 atomic drivers (i915 and
nouveau) that still had one (both had dummy implementations already
anyway), and shunt atomic drivers in the helpers debug_enter/leave
functions.
I'll leave the code in for radeon and amdgpu, but I think as soon as
amdgpu is atomic we should think about just ripping it out. Only
having it around for radeon and pre-nv50 is rather pointless. This
would also allow us to nuke all that code from fbdev.
Funny part is that _all_ kms drivers set this hook, despite that no
one else provides the required ->mode_set_base_atomic implementation.
The reason I'm jumping on this is that I want to wire up a full
acquire ctx for the benefit of atomic drivers, everywhere. And the
debug_enter/leave implementations call ->gamma_set. And there's just
no way ever we can create an acquire_ctx in the nmi context of kgdb.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-11-daniel.vetter@ffwll.ch
We do set DRIVER_ATOMIC now.
Note that the comment is outdated, the property paths switched over to
checking drm_drv_uses_atomic_modeset() a while ago. Which means this
can't even break if we revert DRIVER_ATOMIC again.
v2: Add note that this is even safer (Maarten).
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-9-daniel.vetter@ffwll.ch
We don't call into drivers at all here, this is enough. Also, we can
reduce the critical section a bit to simplify the code.
crtc->gamma_size is set up once at driver load and then invariant, so
also doesn't need any protection.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-8-daniel.vetter@ffwll.ch
Properties, i.e. the struct drm_property specifying the type and value
range of a property, not the instantiation on a given object, are
invariant over the lifetime of a driver.
Hence no locking at all is needed, we can just remove it.
While at it give the function some love and simplify it, to get it
under the 80 char limit:
- Straighten the loops to reduce the nesting.
- use u64_to_user_ptr casting helper
- use put_user for fixed u64 copies.
Note there's a small behavioural change in that we now copy parts of
the values to userspace if the arrays are a bit too small. Since
userspace will immediately retry anyway, this doesn't matter.
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-7-daniel.vetter@ffwll.ch
If we push the locks down we don't have to take them all at the same
time.
Aside: Making dump_info fully safe should be fairly simple, if we
protect the ->state pointers with rcu. Simply putting a
synchronize_rcu() into the drm_atomic_state free function should be
all that's roughly needed. Well except we shouldn't block in there, so
better to put that into a work_struct. But I've not set out to fix
that little issue.
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170403083304.9083-6-daniel.vetter@ffwll.ch
