- 08 Oct, 2020 4 commits
-
-
Boris Brezillon authored
If more than two jobs end up timeout-ing concurrently, only one of them (the one attached to the scheduler acquiring the lock) is fully handled. The other one remains in a dangling state where it's no longer part of the scheduling queue, but still blocks something in scheduler, leading to repetitive timeouts when new jobs are queued. Let's make sure all bad jobs are properly handled by the thread acquiring the lock. v3: - Add Steven's R-b - Don't take the sched_lock when stopping the schedulers v2: - Fix the subject prefix - Stop the scheduler before returning from panfrost_job_timedout() - Call cancel_delayed_work_sync() after drm_sched_stop() to make sure no timeout handlers are in flight when we reset the GPU (Steven Price) - Make sure we release the reset lock before restarting the schedulers (Steven Price) Fixes: f3ba9122 ("drm/panfrost: Add initial panfrost driver") Cc: <stable@vger.kernel.org> Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Signed-off-by:
-
Daniel Vetter authored
Hopefully we'll have the drm crash recorder RSN, but meanwhile compositors would like to know a bit better why they get an EBUSY. v2: Move misplaced hunk to the right patch (Pekka) Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by:
Daniel Stone <daniels@collabora.com> Cc: Sean Paul <seanpaul@chromium.org> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Cc: Simon Ser <contact@emersion.fr> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200925084651.3250104-2-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to pull in arbitrary other resources, including CRTCs (e.g. when reconfiguring global resources). But in nonblocking mode userspace has then no idea this happened, which can lead to spurious EBUSY calls, both: - when that other CRTC is currently busy doing a page_flip the ALLOW_MODESET commit can fail with an EBUSY - on the other CRTC a normal atomic flip can fail with EBUSY because of the additional commit inserted by the kernel without userspace's knowledge For blocking commits this isn't a problem, because everyone else will just block until all the CRTC are reconfigured. Only thing userspace can notice is the dropped frames without any reason for why frames got dropped. Consensus is that we need new uapi to handle this properly, but no one has any idea what exactly the new uapi should look like. Since this has been shipping for years already compositors need to deal no matter what, so as a first step just try to enforce this across drivers better with some checks. v2: Add comments and a WARN_ON to enforce this only when allowed - we don't want to silently convert page flips into blocking plane updates just because the driver is buggy. v3: Fix inverted WARN_ON (Pekka). v4: Drop the uapi changes, only add a WARN_ON for now to enforce some rules for drivers. v5: Make the WARNING more informative (Daniel) v6: Add unconditional debug output for compositor hackers to figure out what's going on when they get an EBUSY (Daniel) v7: Fix up old/new_crtc_state confusion for real (Pekka/Ville) Acked-by:
-
Daniel Vetter authored
We didn't take the kernel_fb_helper_lock mutex, which protects that code. While at it, simplify the code - inline the function (originally shared with kgdb I think) - drop the error tracking and all the complications - drop the pointless early out, it served nothing Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
-
- 07 Oct, 2020 13 commits
-
-
Melissa Wen authored
Drop issues already resolved in vkms: - CRC API Improvements to [1] add igt test to check extreme alpha values and [2] alpha blending; - [3] prime buffer sharing; - [4] writeback support; On the other hand, we also found or thought about other improvements since the last update of this document: - better support for IGT tests - improvements to writeback support - syzbot report Finally, we reorder items by the assumed complexity. [1] https://patchwork.freedesktop.org/series/55944/ [2] https://patchwork.freedesktop.org/series/80823/ [3] https://patchwork.freedesktop.org/series/63212/ [4] https://patchwork.freedesktop.org/series/81177/ v2: - Link to syzbot dashboard Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Haneen Mohammed <hamohammed.sa@gmail.com> Signed-off-by:
Melissa Wen <melissa.srw@gmail.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201006223006.gu55pjtuaigkh6il@smtp.gmail.com
-
Christian König authored
This is not something drivers should use. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Link: https://patchwork.freedesktop.org/patch/393430/
-
Christian König authored
That was missed during the cleanup. v2: fix comment in vmwgfx as well Signed-off-by:
-
Christian König authored
It is the sole user of this. Signed-off-by:
-
Christian König authored
We can always access the global state. Signed-off-by:
-
Christian König authored
Make it more clear what the resource manager function does and nuke the wrapper function. v2: nuke the wrapper v3: fix typo in radeon, rebased Signed-off-by:
-
Christian König authored
Remove unused parameters, shorten the function name. Signed-off-by:
-
Christian König authored
Not used any more. Signed-off-by:
-
Dave Airlie authored
All drivers should have a move callback now so make it compulsory. Reviewed-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201006000644.1005758-6-airlied@gmail.com
-
Dave Airlie authored
This will always do memcpy moves. Acked-by:
-
Dave Airlie authored
This just copies the fallback to vmwgfx, I'm going to iterate on this a bit until it's not the same as the fallback path. Acked-by:
-
Dave Airlie authored
Both fns checked mem == NULL, just move the check outside. Acked-by:
-
Dave Airlie authored
v2: drop the wrapper struct Acked-by:
-
- 06 Oct, 2020 1 commit
-
-
Dave Airlie authored
no need for driver to wait here. Signed-off-by:
-
- 05 Oct, 2020 8 commits
-
-
Dave Airlie authored
The idea is to flip the core over to calling the driver always, so add support for moves here. Signed-off-by:
-
Marek Szyprowski authored
This patch restores DRM connector registration in the TC358764 bridge driver and restores usage of the old drm_panel_* API, thus allows dynamic panel registration. This fixes panel operation on Exynos5250-based Arndale board. This is equivalent to the revert of the following commits: 1644127f "drm/bridge: tc358764: add drm_panel_bridge support" 385ca38d "drm/bridge: tc358764: drop drm_connector_(un)register" and removal of the calls to drm_panel_attach()/drm_panel_detach(), which were no-ops and has been removed in meanwhile. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
-
Rikard Falkeborn authored
The only usage of dw_hdmi_i2s_ops is to assign its address to the ops field in the hdmi_codec_pdata struct, which is a const pointer. Make it const to allow the compiler to put it in read-only memory. Signed-off-by:
Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by:
-
Tom Rix authored
clang static analysis reports this problem: cdv_intel_dp.c:2101:2: warning: Attempt to free released memory kfree(gma_connector); ^~~~~~~~~~~~~~~~~~~~ In cdv_intel_dp_init() when the call to cdv_intel_edp_panel_vdd_off() fails, the handler calls cdv_intel_dp_destroy(connector) which does the first free of gma_connector. So adjust the goto label and skip the second free. Fixes: d112a816 ("gma500/cdv: Add eDP support") Signed-off-by:Tom Rix <trix@redhat.com> Signed-off-by:
-
Boris Brezillon authored
If we don't initialize the entity to idle and the entity is never scheduled before being destroyed we end up with an infinite wait in the destroy path. v2: - Add Steven's R-b Signed-off-by:
-
Gowtham Tammana authored
drm_gem_fb_prepare_fb() extracts fence and attaches to plane state. The fence info is needed if implicit fencing is used. Add this as prepare_fb function pointer to plane helper funcs. Signed-off-by:
Gowtham Tammana <g-tammana@ti.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200826134409.473554-1-tomi.valkeinen@ti.com
-
Tomi Valkeinen authored
Add assigned-clocks, assigned-clock-parents and dma-coherent optional properties. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200916131009.221252-3-tomi.valkeinen@ti.com
-
Tomi Valkeinen authored
Add assigned-clocks, assigned-clock-parents and dma-coherent optional properties. Signed-off-by:
-
- 04 Oct, 2020 1 commit
-
-
Paul Cercueil authored
This reverts commit 37054fc8 ("gpu/drm: ingenic: Add option to mmap GEM buffers cached") At the very moment this commit was created, the DMA API it relied on was modified in the DMA tree, which caused the driver to break in linux-next. Revert it for now, and it will be resubmitted later to work with the new DMA API. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201004141758.1013317-1-paul@crapouillou.net
-
- 02 Oct, 2020 1 commit
-
-
Daniel Vetter authored
Crank up the warning a notch and point at the right set of locking functions for atomic drivers. Acked-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
-
- 01 Oct, 2020 2 commits
-
-
Qinglang Miao authored
Simplify the return expression. Signed-off-by:
Qinglang Miao <miaoqinglang@huawei.com> Reviewed-by:
-
Qinglang Miao authored
Simplify the return expression. Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by:
-
- 30 Sep, 2020 4 commits
-
-
Bartlomiej Zolnierkiewicz authored
It has been a fun ride since 2017 but unfortunately I don't have enough time to look after it properly anymore. Reviewed-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/7b709254-9412-8473-250c-0c4e006259b3@samsung.com
-
Alistair Delva authored
We encountered this issue when booting blob with a 32-bit kernel. The implementation doesn't match v6 of the virtio-spec change, so fix this. Fixes: ff886cbd ("virtio-gpu api: blob resources") Signed-off-by:
Alistair Delva <adelva@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200929215333.1241-1-gurchetansingh@chromium.orgSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Tian Tao authored
The macro PADDING is no longer used. Delete it. Signed-off-by:
Tian Tao <tiantao6@hisilicon.com> Reviewed-by:
-
Tian Tao authored
Using the to_hibmc_drm_private to convert over all uses of dev_private, and fix a little formatting issue. v2: fixed the commit message. Signed-off-by:
-
- 29 Sep, 2020 6 commits
-
-
Daniel Vetter authored
- debugfs cleanup has moved forward thanks to the cleanup Wambui has done Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Wambui Karuga <wambui.karugax@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Melissa Wen <melissa.srw@gmail.com> Signed-off-by:
-
Christian König authored
We need to use ttm_bo_init_reserved here to make sure that the BO is pinned before it becomes visible on the LRU. Signed-off-by:
-
Thomas Zimmermann authored
This patch adds struct dma_buf_map and its helpers to the documentation. A short tutorial is included. v3: * update documentation in a separate patch * expand docs (Daniel) * carry-over acks from patch 1 Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200925115601.23955-5-tzimmermann@suse.de
-
Thomas Zimmermann authored
This patch updates dma_buf_vunmap() and dma-buf's vunmap callback to use struct dma_buf_map. The interfaces used to receive a buffer address. This address is now given in an instance of the structure. Users of the functions are updated accordingly. This is only an interface change. It is currently expected that dma-buf memory can be accessed with system memory load/store operations. v2: * include dma-buf-heaps and i915 selftests (kernel test robot) * initialize cma_obj before using it in drm_gem_cma_free_object() (kernel test robot) Signed-off-by:
Tomasz Figa <tfiga@chromium.org> Acked-by:
-
Thomas Zimmermann authored
This patch updates dma_buf_vmap() and dma-buf's vmap callback to use struct dma_buf_map. The interfaces used to return a buffer address. This address now gets stored in an instance of the structure that is given as an additional argument. The functions return an errno code on errors. Users of the functions are updated accordingly. This is only an interface change. It is currently expected that dma-buf memory can be accessed with system memory load/store operations. v3: * update fastrpc driver (kernel test robot) v2: * always clear map parameter in dma_buf_vmap() (Daniel) * include dma-buf-heaps and i915 selftests (kernel test robot) Signed-off-by:
-
Thomas Zimmermann authored
The new type struct dma_buf_map represents a mapping of dma-buf memory into kernel space. It contains a flag, is_iomem, that signals users to access the mapped memory with I/O operations instead of regular loads and stores. It was assumed that DMA buffer memory can be accessed with regular load and store operations. Some architectures, such as sparc64, require the use of I/O operations to access dma-map buffers that are located in I/O memory. Providing struct dma_buf_map allows drivers to implement this. This was specifically a problem when refreshing the graphics framebuffer on such systems. [1] As the first step, struct dma_buf stores an instance of struct dma_buf_map internally. Afterwards, dma-buf's vmap and vunmap interfaces are be converted. Finally, affected drivers can be fixed. v3: * moved documentation into separate patch * test for NULL pointers with !<ptr> [1] https://lore.kernel.org/dri-devel/20200725191012.GA434957@ravnborg.org/Signed-off-by:
-
