- 10 Jun, 2020 25 commits
-
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200605073247.4057-26-tzimmermann@suse.de
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver to their defaults. No functional changes are made. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200605073247.4057-25-tzimmermann@suse.de
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE sets the functions in struct drm_driver to their defaults. No functional changes are made. v2: * update for DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200605073247.4057-23-tzimmermann@suse.de
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE sets the functions in struct drm_driver to their defaults. No functional changes are made. v2: * update for DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE Signed-off-by:
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver to their defaults. No functional changes are made. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver to their defaults. No functional changes are made. Signed-off-by:
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver to their defaults. No functional changes are made. v2: * use DRM_GEM_CMA_DRIVER_OPS Signed-off-by:
John Stultz <john.stultz@linaro.org> Reviewed-by:
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
The kirin drivers uses drm_gem_cma_dumb_create_internal() for its .dumb_create implementation. The function is meant for internal use only by drivers that require additional buffer setup. Kirin does not do an additional setup, so convert it over to drm_gem_cma_dumb_create(). Signed-off-by:
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver to their defaults. No functional changes are made. Signed-off-by:
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver to their defaults. No functional changes are made. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver to their defaults. No functional changes are made. Signed-off-by:
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
DRM_GEM_CMA_DRIVER_OPS sets the functions in struct drm_driver to their defaults. No functional changes are made. Signed-off-by:
-
Thomas Zimmermann authored
Create GEM objects with drm_gem_cma_create_object_default_funcs(), which allocates the object and sets CMA's default object functions. Corresponding callbacks in struct drm_driver are cleared. No functional changes are made. Driver and object-function instances use the same callback functions, with the exception of vunmap. The implementation of vunmap is empty and left out in CMA's default object functions. v3: * convert to DRIVER_OPS macro in a separate patch Signed-off-by:
-
Thomas Zimmermann authored
The macro to DRM_GEM_CMA_DRIVER_OPS sets GEM callbacks in struct drm_driver to their defaults for CMA. A variant of the macro is provided for drivers that override the default .dumb_create callback. Adapt drivers to the changes. v4: * remove parenthesis around dumb_create_func * fix grammar in commit message Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Thomas Zimmermann authored
Rename the macro to DRM_GEM_CMA_DRIVER_OPS_VMAP to align naming with SHMEM helpers and drm_gem_cma_prime_import_sg_table_vmap(). An variant of the macro is provided for drivers that override the default .dumb_create callback. Adapt drivers to the changes. v3: * rename macro to signal implicit vmap on imported buffers v2: * provide DRM_GEM_CMA_DRIVER_OPS_WITH_DUMB_CREATE Signed-off-by:
-
Thomas Zimmermann authored
This fixes the naming of several symbols within CMA helpers. No functional changes are made. Signed-off-by:
-
- 08 Jun, 2020 4 commits
-
-
Daniel Vetter authored
- Ditch the ->pages array - Make it a private gem bo, which means no shmem object, which means fireworks if anyone calls drm_gem_object_get_pages. But we've just made sure that's all covered. v2: Rebase v3: I forgot to remove the page_count mangling from the free path too. Noticed by Boris while testing. Cc: Boris Brezillon <boris.brezillon@collabora.com> Tested-by:
Boris Brezillon <boris.brezillon@collabora.com> Acked-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200529140542.2103713-1-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Just a bit of light paranoia. Also sprinkle this check over drm_gem_shmem_get_sg_table, which should only be called when exporting, same for the pin/unpin functions, on which it relies to work correctly. Acked-by:
-
Nirmoy Das authored
This patch introduces fragmentation in the address range and measures time taken by 10k and 20k insertions. ig_frag() will fail if the time taken by 20k insertions takes more than 4 times of 10k insertions as we know that insertions should at most scale quadratically. v2: introduce fragmentation by freeing every other node. only test bottom-up and top-down for now. v3: fix incorrect mode check Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Simon Ser authored
Describe what a "BAD" link-status means for user-space and how it should handle it. The logic described has been implemented in igt [1]. v2: - Change wording to avoid "enabled" (Daniel) - Add paragraph about multiple connectors sharing the same CRTC (Pekka) - Add paragraph about performing an atomic commit on a connector without updating the link-status property (Daniel) v3: - Fix description of what happens when link-status isn't reset to "GOOD", and when link-status is reset without ALLOW_MODESET (Daniel, Ville) - Changing link-status to "BAD" is a no-op - Clearly state that "BAD" means black screen (Manasi) [1]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/-/commit/fbe61f529737191d0920521946a575bd55f00fbeSigned-off-by:
Simon Ser <contact@emersion.fr> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Pekka Paalanen <ppaalanen@gmail.com> Reviewed-by:
Daniel Vetter <daniel@ffwll.ch> Acked-by:
Pekka Paalanen <ppaalanen@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/kFylMmeRMGJk-oi8f-Td8A7GNa1C-GsK23-vjKg77VhWfwpkLJg7QxFlQ_g9KdVxZiyWl9eJWpUGa5PYasR9YcyvIbuBmHVfKeHb4rH0yTM=@emersion.fr
-
- 05 Jun, 2020 2 commits
-
-
Liu Ying authored
This patch adds support for Kaohsiung Opto-Electronics Inc. 10.1" TX26D202VM0BWA WUXGA(1920x1200) TFT LCD panel with LVDS interface. The panel has dual LVDS channels. My panel is manufactured by US Micro Products(USMP). There is a tag at the back of the panel, which indicates the panel type is 'TX26D202VM0BWA' and it's made by KOE in Taiwan. The panel spec from USMP can be found at: https://www.usmicroproducts.com/sites/default/files/datasheets/USMP-T101-192120NDU-A0.pdf The below panel spec from KOE is basically the same to the one from USMP. However, the panel type 'TX26D202VM0BAA' is a little bit different. It looks that the two types of panel are compatible with each other. http://www.koe.j-display.com/upload/product/TX26D202VM0BAA.pdf Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Liu Ying <victor.liu@nxp.com> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Liu Ying authored
Add compatible to panel-simple for Kaohsiung Opto-Electronics Inc. 10.1" WUXGA(1920x1200) TX26D202VM0BWA TFT LCD panel with LVDS interface. Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Rob Herring <robh+dt@kernel.org> Signed-off-by:
-
- 04 Jun, 2020 2 commits
-
-
Laurent Pinchart authored
None of the DSI panels set the connector_type in their panel_desc descriptor. As they are all guaranteed to be DSI panels, that's an easy fix, set the connector type to DRM_MODE_CONNECTOR_DSI. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Nirmoy Das authored
Fixes: 0cdea445 ("drm/mm: optimize rb_hole_addr rbtree search") Signed-off-by:
-
- 03 Jun, 2020 7 commits
-
-
Daniel Vetter authored
This is already taken care of by drm_atomic_helper_shutdown(), and in that case only for the CRTC which are actually on. Only tricky bit here is that we kill the interrupt handling before we shut down crtc, so need to reorder that. Acked-by:
-
Daniel Vetter authored
This is already done as part of the drm_atomic_helper_shutdown(), and in that case only for the crtc which are actually on. v2: I overlooked that malidp also needs to have it's interrupt shut down reordered. Acked-by:
-
Daniel Vetter authored
Currently this seems to work by converting the sgt into a pages array, and then treating it like a native object. Do the right thing and redirect mmap to the exporter. With this nothing is calling get_pages anymore on imported dma-buf, and we can start to remove the use of the ->pages array for that case. v2: Rebase Tested-by:
-
Daniel Vetter authored
There's no direct harm, because for the shmem helpers these are noops on imported buffers. The trouble is in the locks these take - I want to change dma_buf_vmap locking, and so need to make sure that we only ever take certain locks on one side of the dma-buf interface: Either for exporters, or for importers. v2: Change the control flow less compared to what's there (Thomas) Tested-by:
-
Daniel Vetter authored
There's no direct harm, because for the shmem helpers these are noops on imported buffers. The trouble is in the locks these take - I want to change dma_buf_vmap locking, and so need to make sure that we only ever take certain locks on one side of the dma-buf interface: Either for exporters, or for importers. Acked-by:
-
Daniel Vetter authored
drm_gem_shmem_get_sg_table is meant to implement obj->funcs->get_sg_table, for prime exporting. The one we want is drm_gem_shmem_get_pages_sgt, which also handles imported dma-buf, not just native objects. v2: Rebase, this stuff moved around in commit 2f2aa137 Author: Gerd Hoffmann <kraxel@redhat.com> Date: Fri Feb 7 08:46:38 2020 +0100 drm/virtio: move virtio_gpu_mem_entry initialization to new function Acked-by:
-
Daniel Vetter authored
- Move the shmem helper section to the drm-mm.rst file, next to the vram helpers. Makes a lot more sense there with the now wider scope. Also, that's where the all the other backing storage stuff resides. It's just the framebuffer helpers that should be in the kms helper section. - Try to clarify which functiosn are for implementing drm_gem_object_funcs, and which for drivers to call directly. At least one driver screwed that up a bit. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Rob Herring <robh@kernel.org> Cc: Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
-
