- 11 Sep, 2019 1 commit
-
-
Gerd Hoffmann authored
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. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190905070509.22407-2-kraxel@redhat.com
-
- 10 Sep, 2019 7 commits
-
-
Gerd Hoffmann authored
select isn't recursive, so we can't turn on DRM_TTM + DRM_TTM_HELPER in config DRM_VRAM_HELPER, we have to select them on the vram users instead. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: http://patchwork.freedesktop.org/patch/msgid/20190904054740.20817-8-kraxel@redhat.com
-
Gerd Hoffmann authored
Signed-off-by:
-
Gerd Hoffmann authored
Switch qxl to use drm_gem_object_funcs callbacks instead of drm_driver callbacks. Signed-off-by:
-
Gerd Hoffmann authored
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 Signed-off-by:
-
Gerd Hoffmann authored
Signed-off-by:
-
Gerd Hoffmann authored
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. Signed-off-by:
-
Gerd Hoffmann authored
New helper to print named bits of some value (think flags fields). Signed-off-by:
-
- 09 Sep, 2019 8 commits
-
-
Thomas Zimmermann authored
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 Signed-off-by:
Davidlohr Bueso <dbueso@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190906122056.32018-5-tzimmermann@suse.de
-
Thomas Zimmermann authored
This patch prepares VRAM helpers for lazy unmapping of buffer objects. Signed-off-by:
-
Thomas Zimmermann authored
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(). Signed-off-by:
-
Thomas Zimmermann authored
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() Signed-off-by:
-
Dariusz Marcinkiewicz authored
Use the new cec_notifier_cec_adap_(un)register() functions to (un)register the notifier for the CEC adapter. Signed-off-by:
Dariusz Marcinkiewicz <darekm@google.com> Tested-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
Dariusz Marcinkiewicz authored
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. Signed-off-by:
-
Hans Verkuil authored
Set the connector info for the CEC adapter. This helps userspace to associate the CEC device with the HDMI connector. Tested on a Cubieboard. Signed-off-by:
Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190823112427.42394-3-hverkuil-cisco@xs4all.nl
-
Yannick Fertré authored
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. Reviewed-by:
Philippe Cornu <philippe.cornu@st.com> Signed-off-by:
Yannick Fertré <yannick.fertre@st.com> Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/1567761708-31777-1-git-send-email-yannick.fertre@st.com
-
- 08 Sep, 2019 3 commits
-
-
Laurent Pinchart authored
The OSD070T1718 is a DPI panel, set its type accordingly. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190904133723.30418-1-laurent.pinchart@ideasonboard.com
-
Laurent Pinchart authored
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. @@ expression bridge; expression dev; expression panel; identifier type; @@ ( -bridge = drm_panel_bridge_add(panel, type); +bridge = drm_panel_bridge_add_typed(panel, type); | -bridge = devm_drm_panel_bridge_add(dev, panel, type); +bridge = devm_drm_panel_bridge_add_typed(dev, panel, type); ) Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
-
Laurent Pinchart authored
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. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
- 06 Sep, 2019 4 commits
-
-
Arnd Bergmann authored
This function lost its only call site as part of earlier dead code removal, so remove it as well: drivers/video/fbdev/sa1100fb.c:975:21: error: unused function 'sa1100fb_min_dma_period' [-Werror,-Wunused-function] Fixes: 390e5de1 ("fbdev/sa1100fb: Remove dead code") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Daniel Vetter authored
We forgot that. Proof is the one igt testcase we have: https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/tests/kms_atomic.c#L280 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:
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
-
Daniel Vetter authored
- it's what we recommend in our docs: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values - it's the overwhelmingly used error code for "operation not supported", at least in drm core (slightly less so in drivers): $ git grep EOPNOTSUPP -- drivers/gpu/drm/*c | wc -l 83 $ git grep ENOTSUPP -- drivers/gpu/drm/*c | wc -l 5 - 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:
-
Gerd Hoffmann authored
Only call virtio_gpu_array_add_fence if we actually have a fence. Fixes: da758d51 ("drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing") Signed-off-by:
Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190904074828.32502-1-kraxel@redhat.com
-
- 04 Sep, 2019 17 commits
-
-
Gerd Hoffmann authored
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. Reported-by:
-
Gerd Hoffmann authored
Make sure we don't leak half-initialized fences outside the driver. Signed-off-by:
-
Gerd Hoffmann authored
No users left. Signed-off-by:
-
Gerd Hoffmann authored
No users left. Signed-off-by:
-
Gerd Hoffmann authored
Thin wrapper around virtio_gpu_object_create(), but calling that directly works equally well. Signed-off-by:
-
Gerd Hoffmann authored
virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4: fix drm_gem_object_funcs name. Signed-off-by:
-
Gerd Hoffmann authored
No users left. Signed-off-by:
-
Gerd Hoffmann authored
Switch to the virtio_gpu_array_* helper workflow. Signed-off-by:
-
Gerd Hoffmann authored
Switch to the virtio_gpu_array_* helper workflow. Signed-off-by:
-
Gerd Hoffmann authored
Switch to the virtio_gpu_array_* helper workflow. Signed-off-by:
-
Gerd Hoffmann authored
Rework fencing workflow. Stop using ttm helpers, use the virtio_gpu_array_* helpers instead. Due to using the gem reservation object it is initialized and ready for use before calling ttm_bo_init. So we can simply use the standard fencing workflow and drop the tricky logic which checks whenever the command is in flight still. v6: rewrite most of the patch. Signed-off-by:
-
Gerd Hoffmann authored
Rework fencing workflow, starting with virtio_gpu_execbuffer_ioctl. Stop using ttm helpers, use the virtio_gpu_array_* helpers (which work on the reservation objects directly) instead. Also store the object array in struct virtio_gpu_vbuffer, so we explicitly keep a reference of all buffers used instead of depending on ttm_bo_put() checking whenever the object is actually idle before releasing it. New workflow: (1) All gem objects needed by a command are added to a virtio_gpu_object_array. (2) All reservation objects will be locked (virtio_gpu_array_lock_resv). (3) virtio_gpu_fence_emit() completes fence initialization. (4) fence gets added to the objects, reservation objects are unlocked (virtio_gpu_array_add_fence, virtio_gpu_array_unlock_resv). (5) virtio command is submitted to the host. (6) The completion callback (virtio_gpu_dequeue_ctrl_func) will drop object references and free virtio_gpu_object_array. v6: rewrite most of the patch. Signed-off-by: -
Gerd Hoffmann authored
Some helper functions to manage an array of gem objects. v9: use dma_resv_lock_interruptible. v6: - add ticket to struct virtio_gpu_object_array. - add virtio_gpu_array_{lock,unlock}_resv helpers. - add virtio_gpu_array_add_fence helper. v5: some small optimizations (Chia-I Wu). v4: make them virtio-private instead of generic helpers. Signed-off-by: -
Gerd Hoffmann authored
Call reservation_object_* directly instead of using ttm_bo_{reserve,unreserve}. v4: check for EINTR only. v3: check for EINTR too. Signed-off-by: -
Gerd Hoffmann authored
All callers pass no_wait = false. Signed-off-by:
-
Gerd Hoffmann authored
No users left. Signed-off-by:
-
Gerd Hoffmann authored
No need to do the reservation dance, we can just wait on the fence directly. Signed-off-by:
-
