- 10 Jun, 2020 11 commits
-
-
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 <tzimmermann@suse.de> Reviewed-by:
Emil Velikov <emil.velikov@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200605073247.4057-12-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 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:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200605073247.4057-8-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 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 9 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:
-
Daniel Vetter authored
No real functional change, since this just converts an annoying Oops into a more harmless WARNING backtrace. It's still a driver bug. Acked-by:
-
Daniel Vetter authored
I honestly don't exactly understand what's going on here, but the current code is wrong for sure: It calls dma_buf_vunmap without ever calling dma_buf_vmap. What I'm not sure about is whether the WARN_ON is correct: - msm imports dma-buf using drm_prime_sg_to_page_addr_arrays. Which is a pretty neat layering violation of how you shouldn't peek behind the curtain of the dma-buf exporter, but par for course. Note that all the nice new helpers don't (and we should probably have a bit a warning about this in the kerneldoc). - but then in the get_vaddr() in msm_gem.c, we seems to happily wrap a vmap() around any object with ->pages set (so including imported dma-buf). - I'm not seeing any guarantees that userspace can't use an imported dma-buf for e.g. MSM_SUBMIT_CMD_BUF in a5xx_submit_in_rb, so no guarantees that an imported dma-buf won't end up with a ->vaddr set. But even if that WARN_ON is wrong, cleaning up a vmap() done by msm by calling dma_buf_vunmap is the wrong thing to do. v2: Rob said in review that we do indeed have a gap in get_vaddr() that needs to be plugged. But the users I've found aren't legit users on imported dma-buf, so we can just reject that. Reviewed-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
- 01 Jun, 2020 9 commits
-
-
Simon Ser authored
This patch adds docs for the ACTIVE and MODE_ID CRTC properties. Signed-off-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by:
-
Joe Perches authored
IS_BUILTIN can be use to replace various initializations like #if CONFIG_<FOO> int val = 1; #else int val = 0; #endif so do so. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/b1cf967015c5beafa475aaa30d8e21a58caff870.camel@perches.com
-
Tiezhu Yang authored
When call function devm_platform_ioremap_resource(), we should use IS_ERR() to check the return value and return PTR_ERR() if failed. Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Cc: Xuefeng Li <lixuefeng@loongson.cn> Signed-off-by:
-
Christophe JAILLET authored
'dma_alloc_coherent()' must be balanced by a call to 'dma_free_coherent()' not 'dma_free_wc()'. The correct dma_free_ function is already used in the error handling path of the probe function. Fixes: 77e19675 ("[ARM] pxafb: allow video memory size to be configurable") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: Jani Nikula <jani.nikula@intel.com> cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Cc: Eric Miao <eric.miao@marvell.com> Signed-off-by:
-
Bernard Zhao authored
Eliminate the magic numbers, add vendor infoframe size macro like other hdmi modules. Signed-off-by:
Bernard Zhao <bernard@vivo.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: opensource.kernel@vivo.com [b.zolnierkie: add "hdmi" to the patch summary] [b.zolnierkie: fix "vender" -> vendor" typo in the patch description] Signed-off-by:
-
Dejin Zheng authored
A call of the function do_take_over_console() can fail here. The corresponding system resources were not released then. Thus add a call of iounmap() and release_mem_region() together with the check of a failure predicate. and also add release_mem_region() on device removal. Fixes: e86bb8ac ("[PATCH] VT binding: Make newport_con support binding") Suggested-by:
Dejin Zheng <zhengdejin5@gmail.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> cc: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Dejin Zheng authored
the sfb->fb->screen_base is not save the value get by iounmap() when the chip id is 0x720. so iounmap() for address sfb->fb->screen_base is not right. Fixes: 1461d667 ("staging: sm7xxfb: merge sm712fb with fbdev") Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Cc: Teddy Wang <teddy.wang@siliconmotion.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Jason Yan authored
Fix the following coccicheck warning: drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c:461:15-32: WARNING: Comparison to bool drivers/video/fbdev/omap2/omapfb/dss/dispc.c:891:5-35: WARNING: Comparison of 0/1 to bool variable Signed-off-by:
Jason Yan <yanaijie@huawei.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Andrew F. Davis <afd@ti.com> Signed-off-by:
-
Simon Ser authored
There are a bunch of other writable connector properties now. Signed-off-by:
-
- 31 May, 2020 3 commits
-
-
John Hubbard authored
This code was using get_user_pages*(), in a "Case 2" scenario (DMA/RDMA), using the categorization from [1]. That means that it's time to convert the get_user_pages*() + put_page() calls to pin_user_pages*() + unpin_user_pages() calls. There is some helpful background in [2]: basically, this is a small part of fixing a long-standing disconnect between pinning pages, and file systems' use of those pages. [1] Documentation/core-api/pin_user_pages.rst [2] "Explicit pinning of user-space pages": https://lwn.net/Articles/807108/ Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Gustavo A. R. Silva <gustavo@embeddedor.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Signed-off-by:John Hubbard <jhubbard@nvidia.com> Signed-off-by:
-
John Hubbard authored
Dealing with the return value of get_user_pages*() variants has a few classic pitfalls, and this driver found one of them: the return value might be zero, positive, or -errno. And if positive, it might be fewer pages than were requested. And if fewer pages than requested, then the caller should return (via put_page()) the pages that *were* pinned. This driver was doing that *except* that it had a problem with the -errno case, which was being stored in an unsigned int, and which would case an interesting mess if it ever happened: nr_pages would be interpreted as a spectacularly huge unsigned value, rather than a small negative value. Also, it was unnecessarily overriding a potentially informative -errno, with -EINVAL, in some cases. Instead: clamp the nr_pages to zero or positive, so that the error handling works. And return the -errno value from get_user_pages*(), unchanged, if we get one. And explain this with comments, seeing as how it is error-prone. Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Gustavo A. R. Silva <gustavo@embeddedor.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-fbdev@vger.kernel.org Signed-off-by:
-
Sam Ravnborg authored
Replace all the WARN_* variants with their drm_WARN counterparts. Signed-off-by:
-
