- 28 Nov, 2019 1 commit
-
-
Daniel Vetter authored
0 means 1 as the default, but it's mighty confusing if the block size for the first plane is spelled out explicitly, but not for the 2nd plane. No cc: stable because this is just confusion, but 0 functional issue. Acked-by:
Liviu Dudau <liviu.dudau@arm.com> Fixes: 05f8bc82 ("drm/fourcc: Add new P010, P016 video format") Cc: Daniel Stone <daniel@fooishbar.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Randy Li <ayaka@soulik.info> Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Ayan Kumar Halder <ayan.halder@arm.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191126091414.226070-1-daniel.vetter@ffwll.ch
-
- 27 Nov, 2019 3 commits
-
-
Mihail Atanassov authored
Caused by file removal without adjusting the Makefile. Fixes: d268f42e ("drm/mediatek: don't open-code drm_gem_fb_create") Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Signed-off-by:
Mihail Atanassov <mihail.atanassov@arm.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191127170513.42251-1-mihail.atanassov@arm.com
-
Andrey Grodzovsky authored
Problem: Due to a race between drm_sched_cleanup_jobs in sched thread and drm_sched_job_timedout in timeout work there is a possiblity that bad job was already freed while still being accessed from the timeout thread. Fix: Instead of just peeking at the bad job in the mirror list remove it from the list under lock and then put it back later when we are garanteed no race with main sched thread is possible which is after the thread is parked. v2: Lock around processing ring_mirror_list in drm_sched_cleanup_jobs. v3: Rebase on top of drm-misc-next. v2 is not needed anymore as drm_sched_get_cleanup_job already has a lock there. v4: Fix comments to relfect latest code in drm-misc. Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Emily Deng <Emily.Deng@amd.com> Tested-by:
-
Gurchetan Singh authored
Commit b0e40e08 ("vram: Have VRAM MM call GEM VRAM functions directly") removed this. Signed-off-by:
Gurchetan Singh <gurchetansingh@chromium.org> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
- 26 Nov, 2019 8 commits
-
-
Maarten Lankhorst authored
Commit 7f0de8d8 ("dma-buf: Drop dma_buf_k(un)map") removed map/unmap handlers, but they still existed in udmabuf. Remove them there as well Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: 7f0de8d8 ("dma-buf: Drop dma_buf_k(un)map") Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
Thomas Zimmermann authored
The udl driver's struct udl_framebuffer stores a DRM framebuffer with an associated GEM object. This functionality is also provided by generic code. Switch udl over. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191114141025.32198-6-tzimmermann@suse.de
-
Thomas Zimmermann authored
Simplifying the udl code before replacing struct udl_framebuffer. Signed-off-by:
-
Thomas Zimmermann authored
The framebuffer's 'active_16' flag signals which framebuffer to flush to device memory. Moving the 'active_16' state from struct udl_framebuffer into struct udl_device prepares for using the generic GEM framebuffer. Signed-off-by:
-
Thomas Zimmermann authored
Udl's custom implementation for struct drm_gem_object_funcs.free_object unmaps perma-mapped memory buffer before freeing the buffer object. After switching to generic fbdev emulation and fixing the damage handler, no perma-mapped buffers have to be released. Switch to SHMEM's implementation of free_object. Signed-off-by:
-
Thomas Zimmermann authored
Udl keeps a BO mapped for its entire lifetime if it has been used in a damage update at least once. The BO's free callback release the mapping before it frees the BO. Change this behaviour to unmap immediately after the damage update, so SHMEM's implementation of free can be used. Signed-off-by:
-
Daniel Vetter authored
All implementations are gone now. Acked-by:
Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by:
-
Daniel Vetter authored
It's a dummy anyway. Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
- 25 Nov, 2019 22 commits
-
-
Daniel Vetter authored
No in-tree users left. Acked-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Daniel Vetter authored
There's no in-kernel users for the k(un)map stuff. And the mmap one is actively harmful - return 0 and then _not_ actually mmaping can't end well. Acked-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Reviewed-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
-
Daniel Vetter authored
There's no in-tree users anymore. Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by:
Jens Wiklander <jens.wiklander@linaro.org> Acked-by:
-
Daniel Vetter authored
No in-tree users left. Acked-by:
Marek Szyprowski <m.szyprowski@samsung.com> Acked-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Acked-by:
-
Daniel Vetter authored
No need for stubs, dma-buf.c takes care of that. Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Acked-by:
-
Daniel Vetter authored
It's unused. 10 years ago, back when 32bit was still fairly common and trying to not exhaust vmalloc space sounded like a worthwhile goal, adding these to dma_buf made sense. Reality is that they simply never caught on, and nowadays everyone who needs plenty of buffers will run in 64bit mode anyway. Also update the docs in this area to adjust them to reality. The actual hooks in dma_buf_ops will be removed once all the implementations are gone. Acked-by:
-
Daniel Vetter authored
No in-tree users left. Reviewed-by:
Thierry Reding <treding@nvidia.com> Tested-by:
-
Daniel Vetter authored
No in-tree users left. Note that this is one of the few (if only) implementations of dma-buf that provided a kmap, but not a vmap implemenation. Given that the only real user (in-tree at least) of kmap was tegra, and it's impossible to buy a chip with tegra host1x and ompadrm on the same SoC, there's no problem here. Acked-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by:
-
Daniel Vetter authored
No in-tree users left. Aside, I think mock_dmabuf would be a nice addition to drm mock/selftest helpers (we have some already), with an EXPORT_SYMBOL_FOR_TESTS_ONLY. Acked-by:
Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
-
Daniel Vetter authored
There's no callers in-tree anymore. For merging probably best to stuff this into drm-misc, since that's where the dma-buf heaps will land too. And the resulting conflict hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap implemenation. Acked-by:
Laura Abbott <labbott@redhat.com> Acked-by:
-
Daniel Vetter authored
It's the only user left in the entire kernel for dma_buf_kmap/_kunmap. Delete it, before we start garbage-collecting the various implementations. Reviewed-by:
-
Daniel Vetter authored
It doesn't have any callers anymore. Aside: The ->mmap/munmap hooks have a bit a confusing name, they don't do userspace mmaps, but a kernel vmap. I think most places use vmap for this, except ttm, which uses kmap for vmap for added confusion. mmap seems entirely for userspace mappings set up through mmap(2) syscall. Reviewed-by:
-
Daniel Vetter authored
A few reasons to drop kmap: - For native objects all we do is look at obj->vaddr anyway, so might as well not call functions for every page. - Reloc-processing on dma-buf is ... questionable. - Plus most dma-buf that bother kernel cpu mmaps give you at least vmap, much less kmaps. And all the ones relevant for arm-soc are again doing a obj->vaddr game anyway, there's no real kmap going on on arm it seems. Plus this seems to be the only real in-tree user of dma_buf_kmap, and I'd like to get rid of that. Reviewed-by:
-
Uma Shankar authored
This reverts commit f25c7a00 ("drm/fbdev: Fallback to non tiled mode if all tiles not present"). The commit causes flip done timeouts in CI. Below are the sample errors thrown in logs: [IGT] core_getversion: executing [IGT] core_getversion: exiting, ret=0 Setting dangerous option reset - tainting kernel drm:drm_atomic_helper_wait_for_dependencies] ERROR [CRTC:152:pipe B] flip_done timed out drm:drm_atomic_helper_wait_for_dependencies] ERROR [CONNECTOR:299:DP-2] flip_done timed out drm:drm_atomic_helper_wait_for_dependencies] ERROR [PLANE:92:plane 1B] flip_done timed out [drm:drm_atomic_helper_wait_for_flip_done] ERROR [CRTC:152:pipe B] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] ERROR [CRTC:152:pipe B] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] ERROR [CONNECTOR:299:DP-2] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] ERROR [PLANE:92:plane 1B] flip_done timed out [drm:drm_atomic_helper_wait_for_flip_done] ERROR [CRTC:152:pipe B] flip_done timed out Console: switching to colour frame buffer device 480x135 [drm:drm_atomic_helper_wait_for_dependencies] ERROR [CRTC:152:pipe B] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] ERROR [CONNECTOR:299:DP-2] flip_done timed out Reverting the change for now to unblock CI execution. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Fixes: f25c7a00 ("drm/fbdev: Fallback to non tiled mode if all tiles not present") Closes: https://gitlab.freedesktop.org/drm/intel/issues/6Acked-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191123091840.32382-1-uma.shankar@intel.com
-
Thomas Zimmermann authored
Gma500's struct psb_fbdev is an, otherwise empty, wrapper around struct drm_fb_helper. Remove it. Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191122100545.16812-7-tzimmermann@suse.de
-
Thomas Zimmermann authored
The gma500 driver stores the console framebuffer in struct psb_fbdev. Moving it into struct drm_fb_helper will allow for removal of struct psb_fbdev. Signed-off-by:
-
Thomas Zimmermann authored
Several framebuffer functions take a pointer to an object of type struct gtt_range when they actually need the GEM base object. Passing the GEM object removes some type casting and clutter. Signed-off-by:
-
Thomas Zimmermann authored
After removing all unnecessary fields, struct psb_framebuffer is just a wrapper around struct drm_framebuffer. So we can replace the former with the latter. Signed-off-by:
-
Thomas Zimmermann authored
The field 'fbdev' in struct psb_framebuffer serves no purpose. Remove it. Signed-off-by:
-
Thomas Zimmermann authored
The field 'addr_space' in struct psb_framebuffer serves no purpose. Remove it. Signed-off-by:
-
Krzysztof Kozlowski authored
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Krzysztof Kozlowski authored
Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by:
-
- 24 Nov, 2019 2 commits
-
-
Linus Walleij authored
The i index i always 0..3 in these statements so there is no need to tag "& 3" to clamp it to 3 here. Make the operator precedence explicit even if it's correct as it is, the paranthesis creates less cognitive stress for humans. Reviewed-by:
Stephan Gerhold <stephan@gerhold.net> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191122072508.25677-1-linus.walleij@linaro.org
-
Linus Walleij authored
The MCDE DSI include file redefines some commands that already exist in the common <video/mipi_display.h> header. Reviewed-by:
-
- 22 Nov, 2019 1 commit
-
-
Daniel Vetter authored
Aside: There's a few other fb_create implementations which simply check for valid buffer format (or an approximation thereof), and then call drm_gem_fb_create. For atomic drivers at least we could walk all planes and make sure the format/modifier combo is valid, and remove even more code. For non-atomic drivers that's not possible, since the format list for the primary buffer might be garbage (and most likely it is). Also delete mtk_drm_fb.[hc] since it would now only contain one function. Acked-by:
CK Hu <ck.hu@mediatek.com> Cc: CK Hu <ck.hu@mediatek.com> Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Matthias Brugger <matthias.bgg@gmail.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Signed-off-by:
-
- 21 Nov, 2019 3 commits
-
-
Daniel Vetter authored
For locking semantics it really doesn't matter when we grab the ticket. But for lockdep validation it does: the acquire ctx is a fake lockdep. Since other drivers might want to do a full multi-lock dance in their fault-handler, not just lock a single dma_resv. Therefore we must init the acquire_ctx only after we've done all the copy_*_user or anything else that might trigger a pagefault. For msm this means we need to move it past submit_lookup_objects. Aside: Why is msm still using struct_mutex, it seems to be using dma_resv_lock for general buffer state protection? v2: - Add comment to explain why the ww ticket setup is separate (Rob) - Fix up error handling, we need to make sure we don't call ww_acquire_fini without _init. Reviewed-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
Daniel Vetter authored
Semnatically it really doesn't matter where we grab the ticket. But since the ticket is a fake lockdep lock, it matters for lockdep validation purposes. This means stuff like grabbing a ticket and then doing copy_from/to_user isn't allowed anymore. This is a changed compared to the current ttm fault handler, which doesn't bother with having a full reservation. Since I'm looking into fixing the TODO entry in ttm_mem_evict_wait_busy() I think that'll have to change sooner or later anyway, better get started. A bit more context on why I'm looking into this: For backwards compat with existing i915 gem code I think we'll have to do full slowpath locking in the i915 equivalent of the eviction code. And with dynamic dma-buf that will leak across drivers, so another thing we need to standardize and make sure it's done the same way everyway. Unfortunately this means another full audit of all drivers: - gem helpers: acquire_init is done right before taking locks, so no problem. Same for acquire_fini and unlocking, which means nothing that's not already covered by the dma_resv_lock rules will be caught with this extension here to the acquire_ctx. - etnaviv: An absolute massive amount of code is run between the acquire_init and the first lock acquisition in submit_lock_objects. But nothing that would touch user memory and could cause a fault. Furthermore nothing that uses the ticket, so even if I missed something, it would be easy to fix by pushing the acquire_init right before the first use. Similar on the unlock/acquire_fini side. - i915: Right now (and this will likely change a lot rsn) the acquire ctx and actual locks are right next to each another. No problem. - msm has a problem: submit_create calls acquire_init, but then submit_lookup_objects() has a bunch of copy_from_user to do the object lookups. That's the only thing before submit_lock_objects call dma_resv_lock(). Despite all the copypasta to etnaviv, etnaviv does not have this issue since it copies all the userspace structs earlier. submit_cleanup does not have any such issues. With the prep patch to pull out the acquire_ctx and reorder it msm is going to be safe too. - nouveau: acquire_init is right next to ttm_bo_reserve, so all good. Similar on the acquire_fini/ttm_bo_unreserve side. - ttm execbuf utils: acquire context and locking are even in the same functions here (one function to reserve everything, the other to unreserve), so all good. - vc4: Another case where acquire context and locking are handled in the same functions (one function to lock everything, the other to unlock). Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: linux-media@vger.kernel.org Cc: linaro-mm-sig@lists.linaro.org Cc: Huang Rui <ray.huang@amd.com> Cc: Eric Anholt <eric@anholt.net> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Rob Herring <robh@kernel.org> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Acked-by:
-
Daniel Vetter authored
It's kinda really hard to get this wrong on a driver with both display and dma_resv locking. But who ever knows, so better to make sure that really all drivers nest these the same way. For actual lock semantics the acquire context nesting doesn't matter. But to teach lockdep what's going on with ww_mutex the acquire ctx is a fake lockdep lock, hence from a lockdep pov it does matter. That's why I figured better to include it. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Christian König <christian.koenig@amd.com> Acked-by:
-
