drm/tiny: Kconfig: Remove always-y THERMAL dep. from TINYDRM_REPAPER
Commit 554b3529fe01 ("thermal/drivers/core: Remove the module Kconfig's
option") changed the type of THERMAL from tristate to bool, so
THERMAL || !THERMAL is now always y. Remove the redundant dependency.
Discovered through Kconfiglib detecting a dependency loop. The C tools
simplify the expression to y before running dependency loop detection,
and so don't see it. Changing the type of THERMAL back to tristate makes
the C tools detect the same loop.
Not sure if running dep. loop detection after simplification can be
called a bug. Fixing this nit unbreaks Kconfiglib on the kernel at
least.
Ville Syrjälä [Wed, 25 Sep 2019 14:14:41 +0000 (17:14 +0300)]
drm/dp/mst: Handle arbitrary DP_LINK_BW values
Make drm_dp_get_vc_payload() tolerate arbitrary DP_LINK_BW_*
values, just like drm_dp_bw_code_to_link_rate() does since commit 57a1b0893782 ("drm: Make the bw/link rate calculations more forgiving").
Ville Syrjälä [Wed, 10 Jul 2019 12:51:40 +0000 (15:51 +0300)]
drm/dsc: Fix bogus cpu_to_be16() usage
__be16 = cpu_to_be16(__be16) is nonsense. Do it right.
../drivers/gpu/drm/drm_dsc.c:218:53: warning: incorrect type in assignment (different base types)
../drivers/gpu/drm/drm_dsc.c:218:53: expected restricted __be16
../drivers/gpu/drm/drm_dsc.c:218:53: got int
../drivers/gpu/drm/drm_dsc.c:225:25: warning: cast from restricted __be16
../drivers/gpu/drm/drm_dsc.c:225:25: warning: incorrect type in argument 1 (different base types)
../drivers/gpu/drm/drm_dsc.c:225:25: expected unsigned short [usertype] val
../drivers/gpu/drm/drm_dsc.c:225:25: got restricted __be16
../drivers/gpu/drm/drm_dsc.c:225:25: warning: cast from restricted __be16
../drivers/gpu/drm/drm_dsc.c:225:25: warning: cast from restricted __be16
drm/komeda: SW workaround for D71 doesn't flush shadow registers
This is a SW workaround for shadow un-flushed when together with the
DOU Timing-disable.
D71 HW doesn't update shadow registers when display output is turned
off. So when we disable all pipeline components together with display
output disabling by one flush or one operation, the disable operation
updated registers will not be flushed or valid in HW, which may lead
problem. To workaround this problem, introduce a two phase disable for
pipeline disable.
Phase1: Disable components with display is on and flush it, this phase
for flushing or validating the shadow registers.
Phase2: Turn-off display output.
Pinning lots of small buffer objects, such as cursors or sprites, to video
memory can lead to fragmentation, which is a problem for devices with only
a small amount of memory. As a result, framebuffer images might not get
pinned, even though there's enough space available overall.
The flag DRM_GEM_VRAM_PL_FLAG_TOPDOWN marks buffer objects to be pinned at
the high end of video memory. This leaves contiguous space available at
the memory's low end.
Adds system power management support in KMS kernel driver.
Depends on:
https://patchwork.freedesktop.org/series/62377/
Changes since v1:
Since we have unified mclk/pclk/pipeline->aclk to one mclk, which will
be turned on/off when crtc atomic enable/disable, removed runtime power
management.
Removes run time get/put related flow.
Adds to disable the aclk when register access finished.
Changes since v2:
Rebases to the drm-misc-next branch.
Matt Roper [Wed, 25 Sep 2019 22:46:17 +0000 (15:46 -0700)]
drm: Destroy the correct mutex name in drm_dp_mst_topology_mgr_destroy
It looks like one of the topology manager mutexes may have been renamed
during a rebase, but the destruction function wasn't updated with the
new name:
error: ‘struct drm_dp_mst_topology_mgr’ has no member named
‘delayed_destroy_lock’
Lyude Paul [Tue, 3 Sep 2019 20:45:56 +0000 (16:45 -0400)]
drm/dp_mst: Remove lies in {up, down}_rep_recv documentation
These are most certainly accessed from far more than the mgr work. In
fact, up_req_recv is -only- ever accessed from outside the mgr work.
Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20190903204645.25487-19-lyude@redhat.com
Lyude Paul [Tue, 3 Sep 2019 20:45:55 +0000 (16:45 -0400)]
drm/dp_mst: Rename drm_dp_add_port and drm_dp_update_port
The names for these functions are rather confusing. drm_dp_add_port()
sounds like a function that would simply create a port and add it to a
topology, and do nothing more. Similarly, drm_dp_update_port() would be
assumed to be the function that should be used to update port
information after initial creation.
While those assumptions are currently correct in how these functions are
used, a quick glance at drm_dp_add_port() reveals that drm_dp_add_port()
can also update the information on a port, and seems explicitly designed
to do so. This can be explained pretty simply by the fact that there's
more situations that would involve updating the port information based
on a link address response as opposed to a connection status
notification than the driver's initial topology probe. Case in point:
reprobing link addresses after suspend/resume.
Since we're about to start using drm_dp_add_port() differently for
suspend/resume reprobing, let's rename both functions to clarify what
they actually do.
Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20190903204645.25487-18-lyude@redhat.com
Lyude Paul [Tue, 3 Sep 2019 20:45:52 +0000 (16:45 -0400)]
drm/dp_mst: Destroy topology_mgr mutexes
Turns out we've been forgetting for a while now to actually destroy any
of the mutexes that we create in drm_dp_mst_topology_mgr. So, let's do
that.
Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20190903204645.25487-15-lyude@redhat.com
Maxime Ripard [Thu, 19 Sep 2019 17:30:20 +0000 (19:30 +0200)]
MAINTAINERS: Add Jernej Škrabec as a reviewer for DE2
The newer Allwinner SoCs have a different layers controller than the older
ones. Jernej wrote that support and has been reviewing patches for a while
now, so let's make him a formal reviewer.
Maxime Ripard [Thu, 19 Sep 2019 17:30:19 +0000 (19:30 +0200)]
MAINTAINERS: Update Allwinner DRM drivers entry
The DRM drivers are more than about the A10 now, so let's make the entry
name a bit more generic.
Also, Chen-Yu has been a de-facto maintainer for the DRM driver for a
while, is a maintainer of the Allwinner platform for an even longer time,
and has drm-misc commit access. Let's make it formal and add him as a
maintainer.
This causes kernel crash when testing lima driver.
Cc: Christian König <christian.koenig@amd.com> Fixes: b8c036dfc66f ("dma-buf: simplify reservation_object_get_fences_rcu a bit") Signed-off-by: Qiang Yu <yuq825@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190922074900.853-1-yuq825@gmail.com
Dan Carpenter [Wed, 11 Sep 2019 10:49:28 +0000 (13:49 +0300)]
drm: panel-lvds: Potential Oops in probe error handling
The "lvds->backlight" pointer could be NULL in situations where
of_parse_phandle() returns NULL. This code is cleaner if we use the
managed devm_of_find_backlight() so the clean up is automatic.
Gwan-gyeong Mun [Thu, 19 Sep 2019 19:53:07 +0000 (22:53 +0300)]
drm: Add DisplayPort colorspace property creation function
Because between HDMI and DP have different colorspaces, it adds
drm_mode_create_dp_colorspace_property() function for creating of DP
colorspace property.
v3: Addressed review comments from Ville
- Add new colorimetry options for DP 1.4a spec.
- Separate set of colorimetry enum values for DP.
v4: Add additional comments to struct drm_prop_enum_list.
Polishing an enum string of struct drm_prop_enum_list
v5: Change definitions of DRM_MODE_COLORIMETRYs to follow HDMI prefix and
DP abbreviations.
Add missed variables on dp_colorspaces.
Fix typo. [Uma]
v6: Addressed review comments from Ilia and Ville
- Split drm_mode_create_colorspace_property() to DP and HDMI connector.
v7: Fix typo [Jani Saarinen]
Fix white space.
v8: Addressed review comments from Ville
- Drop colorimetries which have another way to distinguish or which
would not be used.
v9: Addressed review comments from Ville
- Split hunk into renaming and adding of code.
Gwan-gyeong Mun [Thu, 19 Sep 2019 19:53:06 +0000 (22:53 +0300)]
drm: Rename HDMI colorspace property creation function
As between HDMI and DP have different colorspaces, in order to distinguish
colorspace of DP and HDMI, it renames drm_mode_create_colorspace_property()
function to drm_mode_create_hdmi_colorspace_property() function for HDMI
connector.
In order to apply changed drm api, i915 driver has channged.
It addresses review comments from Ville.
- Split hunk into renaming and adding of code.
drm/v3d: clean caches at the end of render jobs on request from user space
Extends the user space ioctl for CL submissions so it can include a request
to flush the cache once the CL execution has completed. Fixes memory
write violation messages reported by the kernel in workloads involving
shader memory writes (SSBOs, shader images, scratch, etc) which sometimes
also lead to GPU resets during Piglit and CTS workloads.
v2: if v3d_job_init() fails we need to kfree() the job instead of
v3d_job_put() it (Eric Anholt).
v3 (Eric Anholt):
- Drop _FLAG suffix from the new flag name.
- Add a new param so userspace can tell whether cache flushing is
implemented in the kernel.
Ville Syrjälä [Thu, 11 Jul 2019 10:32:30 +0000 (13:32 +0300)]
drm/edid: Add CTA-861-G modes with VIC < 128
Fill out our list of cea modes with the new stuff from CTA-861-G.
We only do the modes with VIC < 128 here. Adding the higher
numbered VICs will need some slight code refactoring first.
Lyude Paul [Fri, 13 Sep 2019 22:27:02 +0000 (18:27 -0400)]
drm/encoder: Fix possible_crtcs documentation
Similar to possible_clones, we don't actually use possible_crtcs until
the driver is registered with userspace. So, fix the documentation to
indicate this.
Lyude Paul [Fri, 13 Sep 2019 22:27:01 +0000 (18:27 -0400)]
drm/encoder: Fix possible_clones documentation
We say that all of the bits in possible_clones must be set before
calling drm_encoder_init(). This isn't true though, since:
* The driver may not even have all of the encoder objects that could be
used as clones initialized at that point
* possible_crtcs isn't used at all outside of userspace, so it's not
actually needed to initialize it until drm_dev_register()
drm/vram: Provide vmap and vunmap operations for GEM VRAM objects
The implementation of vmap and vunmap for GEM VRAM helpers is
already in PRIME helpers. The patch moves the operations to separate
functions and exports them for general use.
v3:
* remove v2's obsolete note on ref-counting
v2:
* fix documentation
* add cross references to function documentation
* document (the lack of) ref-counting for GEM VRAM BO mappings
Adds to print the event message when error happens and the same event
will not be printed until next vsync.
Changes since v2:
1. Refine komeda_sprintf();
2. Not using STR_SZ macro for the string size in komeda_print_events().
Changes since v1:
1. Handling the event print by CONFIG_KOMEDA_ERROR_PRINT;
2. Changing the max string size to 256.
Signed-off-by: Lowry Li (Arm Technology China) <lowry.li@arm.com> Reviewed-by: Mihail Atanassov <mihail.atanassov@arm.com> Reviewed-by: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Signed-off-by: james qian wang (Arm Technology China) <james.qian.wang@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/1564738954-6101-1-git-send-email-lowry.li@arm.com
drm/connector: Allow max possible encoders to attach to a connector
Currently we restrict the number of encoders that can be linked to
a connector to 3, increase it to match the maximum number of encoders
that can be initialized(32).
To more effiently do that lets switch from an array of encoder ids to
bitmask.
v2: Fixing missed return on amdgpu_dm_connector_to_encoder()
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: dri-devel@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190913232857.389834-2-jose.souza@intel.com
drm/connector: Share with non-atomic drivers the function to get the single encoder
This 3 non-atomic drivers all have the same function getting the
only encoder available in the connector, also atomic drivers have
this fallback. So moving it a common place and sharing between atomic
and non-atomic drivers.
While at it I also removed the mention of
drm_atomic_helper_best_encoder() that was renamed in
commit 297e30b5d9b6 ("drm/atomic-helper: Unexport
drm_atomic_helper_best_encoder").
v3: moving drm_connector_get_single_encoder to drm_kms_helper module
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: dri-devel@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190913232857.389834-1-jose.souza@intel.com
Brian Masney [Thu, 15 Aug 2019 00:48:47 +0000 (20:48 -0400)]
drm/bridge: analogix-anx78xx: convert to i2c_new_dummy_device
The i2c_new_dummy() function is deprecated since it returns NULL on
error. Change this to use the recommended replacement
i2c_new_dummy_device() that returns an error code that can be read with
PTR_ERR() and friends.
Laurent Pinchart [Wed, 21 Aug 2019 23:55:02 +0000 (02:55 +0300)]
drm/bridge: Fix references to drm_bridge_funcs in documentation
The documentation for most of the bridge atomic operations incorrectly
reference the non-atomic version when stating the operations are
optional. Fix them, and make sure that all references to bridge
operations are correctly marked with @.
Yakir Yang [Wed, 11 Sep 2019 08:26:46 +0000 (16:26 +0800)]
drm: bridge/dw_hdmi: add audio sample channel status setting
When transmitting IEC60985 linear PCM audio, we configure the
Aduio Sample Channel Status information in the IEC60958 frame.
The status bit is already available in iec.status of hdmi_codec_params.
This fix the issue that audio does not come out on some monitors
(e.g. LG 22CV241)
Note that these registers are only for interfaces:
I2S audio interface, General Purpose Audio (GPA), or AHB audio DMA
(AHBAUDDMA).
For S/PDIF interface this information comes from the stream.
Currently this function dw_hdmi_set_channel_status is only called
from dw-hdmi-i2s-audio in I2S setup.
drm/vram: Have VRAM MM call GEM VRAM functions directly
VRAM MM and GEM VRAM buffer objects are only used with each other;
connected via 3 function pointers. Simplify this code by making the
memory manager call the rsp. functions of the BOs directly; and
remove the functions from the BO's public interface.
drm/vram: Move VRAM memory manager to GEM VRAM implementation
The separation between GEM VRAM objects and the memory manager is
artificial, as they are only used with each other. Copying both
implementations into the same file is a first step to simplifying
the code.
This patch only moves code without functional changes.
v3:
* update to use dev->vma_offset_manager
v2:
* update for debugfs support
* typos in commit message
David Riley [Wed, 11 Sep 2019 18:14:03 +0000 (11:14 -0700)]
drm/virtio: Use vmalloc for command buffer allocations.
Userspace requested command buffer allocations could be too large
to make as a contiguous allocation. Use vmalloc if necessary to
satisfy those allocations.
Pass gem vma_offset_manager to ttm_bo_device_init(), so ttm uses it
instead of its own embedded struct. This makes some gem functions
(specifically drm_gem_object_lookup) work on ttm objects.
Pass gem vma_offset_manager to ttm_bo_device_init(), so ttm uses it
instead of its own embedded struct. This makes some gem functions
(specifically drm_gem_object_lookup) work on ttm objects.
Pass gem vma_offset_manager to ttm_bo_device_init(), so ttm uses it
instead of its own embedded struct. This makes some gem functions
(specifically drm_gem_object_lookup) work on ttm objects.
Pass gem vma_offset_manager to ttm_bo_device_init(), so ttm uses it
instead of its own embedded struct. This makes some gem functions
(specifically drm_gem_object_lookup) work on ttm objects.
Pass gem vma_offset_manager to ttm_bo_device_init(), so ttm uses it
instead of its own embedded struct. This makes some gem functions
(specifically drm_gem_object_lookup) work on ttm objects.
drm/ttm: turn ttm_bo_device.vma_manager into a pointer
Rename the embedded struct vma_offset_manager, new name is _vma_manager.
ttm_bo_device.vma_manager changed to a pointer.
The ttm_bo_device_init() function gets an additional vma_manager
argument which allows to initialize ttm with a different vma manager.
When passing NULL the embedded _vma_manager is used.
All callers are updated to pass NULL, so the behavior doesn't change.
Wire up drm_mm_print() for vram helpers, using a new
debugfs file, so one can see how vram is used:
# cat /sys/kernel/debug/dri/0/vram-mm
0x0000000000000000-0x0000000000000300: 768: used
0x0000000000000300-0x0000000000000600: 768: used
0x0000000000000600-0x0000000000000900: 768: used
0x0000000000000900-0x0000000000000c00: 768: used
0x0000000000000c00-0x0000000000004000: 13312: free
total: 16384, used 3072 free 13312
drm/ttm: add drm gem ttm helpers, starting with drm_gem_ttm_print_info()
Now with ttm_buffer_object being a subclass of drm_gem_object we can
easily lookup ttm_buffer_object for a given drm_gem_object, which in
turn allows to create common helper functions.
This patch starts off with a drm_gem_ttm_print_info() helper function
which adds some ttm specific lines to the debug output.
drm/vram: Implement lazy unmapping for GEM VRAM buffers
Frequent mapping and unmapping a buffer object adds overhead for
modifying the page table and creates debug output. Unmapping a buffer
is only required when the memory manager evicts the buffer from its
current location.
v4:
* WARN_ON if buffer is still mapped during BO cleanup
drm/vram: Acquire lock only once per call to vmap()/vunmap()
The implementation of vmap() is a combined pin() and kmap(). As both
functions share the same lock, we can make vmap() slightly faster by
acquiring the lock only once for both operations. Same for the inverse,
vunmap().
drm/vram: Add kmap ref-counting to GEM VRAM objects
The kmap and kunmap operations of GEM VRAM buffers can now be called
in interleaving pairs. The first call to drm_gem_vram_kmap() maps the
buffer's memory to kernel address space and the final call to
drm_gem_vram_kunmap() unmaps the memory. Intermediate calls to these
functions increment or decrement a reference counter.
This change allows for keeping buffer memory mapped for longer and
minimizes the amount of changes to TLB, page tables, etc.
v4:
* lock in kmap()/kunmap() with ttm_bo_reserve()
drm: exynos: exynos_hdmi: use cec_notifier_conn_(un)register
Use the new cec_notifier_conn_(un)register() functions to
(un)register the notifier for the HDMI connector, and fill in
the cec_connector_info.
Changes since v7:
- err_runtime_disable -> err_rpm_disable
Changes since v2:
- removed unnecessary call to invalidate phys address before
deregistering the notifier,
- use cec_notifier_phys_addr_invalidate instead of setting
invalid address on a notifier.
The implementation of functions encoder_enable and encoder_disable
make possible to control the pinctrl according to the encoder type.
The pinctrl must be activated only if the encoder type is DPI.
This helps to move the DPI-related pinctrl configuration from
all the panel or bridge to the LTDC dt node.
drm/bridge: panel: Infer connector type from panel by default
The drm panel bridge creates a connector using a connector type
explicitly passed by the display controller or bridge driver that
instantiates the panel bridge. Now that drm_panel reports its connector
type, we can use it to avoid passing an explicit (and often incorrect)
connector type to drm_panel_bridge_add() and
devm_drm_panel_bridge_add().
Several drivers report incorrect or unknown connector types to
userspace. Reporting a different type may result in a breakage. For that
reason, rename (devm_)drm_panel_bridge_add() to
(devm_)drm_panel_bridge_add_typed(), and add new
(devm_)drm_panel_bridge_add() functions that use the panel connector
type. Update all callers of (devm_)drm_panel_bridge_add() to the _typed
function, they will be converted one by one after testing.
The panel drivers have been updated with the following Coccinelle
semantic patch, with manual inspection and fixes to indentation.
Add a type field to the drm_panel structure to report the panel type,
using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS,
eDP, DSI and DPI). This will be used to initialise the corresponding
connector type.
Update all panel drivers accordingly. The panel-simple driver only
specifies the type for the known to be LVDS panels, while all other
panels are left as unknown and will be converted on a case-by-case
basis as they all need to be carefully reviewed.
While at it also document that we have immutable zpos properties in
some cases.
Reported-by: Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Acked-by: Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190906144459.16025-1-daniel.vetter@ffwll.ch
- include/linux/errno.h makes it fairly clear that these are for nfsv3
(plus they also have error codes above 512, which is the block with
some special behaviour ...)
/* Defined for the NFSv3 protocol */
If the above isn't reflecting current practice, then I guess we should
at least update the docs.
Noralf commented:
Ben Hutchings made this comment[1] in a thread about use of ENOTSUPP in
drivers:
glibc's strerror() returns these strings for ENOTSUPP and EOPNOTSUPP
respectively:
"Unknown error 524"
"Operation not supported"
So at least for errors returned to userspace EOPNOTSUPP makes sense.
José asked:
> Hopefully this will not break any userspace
None of the functions in drm_edid.c affected by this reach userspace,
it's all driver internal.
Same for the mipi function, that error code should be handled by
drivers. Drivers are supposed to remap "the hw is on fire" to EIO when
reporting up to userspace, but I think if a driver sees this it would
be a driver bug.
v2: Augment commit message with comments from Noralf and José
Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Acked-by: Noralf Trønnes <noralf@tronnes.org> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Sean Paul <sean@poorly.run> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Andres Rodriguez <andresx7@gmail.com> Cc: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190904143942.31756-1-daniel.vetter@ffwll.ch
Gerd Hoffmann [Fri, 30 Aug 2019 06:01:16 +0000 (08:01 +0200)]
drm/virtio: add worker for object release
Move object release into a separate worker. Releasing objects requires
sending commands to the host. Doing that in the dequeue worker will
cause deadlocks in case the command queue gets filled up, because the
dequeue worker is also the one which will free up slots in the command
queue.