- 08 Dec, 2021 9 commits
-
-
Benoit Parrot authored
Now that we added specific item to our subclassed drm_plane_state we can add omap_plane_atomic_print_state() helper to dump out our own driver specific plane state. Signed-off-by:
Benoit Parrot <bparrot@ti.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by:
-
Benoit Parrot authored
(re)assign the hw overlays to planes based on required caps, and to handle situations where we could not modify an in-use plane. This means all planes advertise the superset of formats and properties. Userspace must (as always) use atomic TEST_ONLY step for atomic updates, as not all planes may be available for use on every frame. The mapping of hwoverlays to plane is stored in omap_global_state, so that state updates are atomically committed in the same way that plane/etc state updates are managed. This is needed because the omap_plane_state keeps a pointer to the hwoverlay, and we don't want global state to become out of sync with the plane state if an atomic update fails, we hit deadlock/ backoff scenario, etc. The use of global_state_lock keeps multiple parallel updates which both re-assign hwoverlays properly serialized. Signed-off-by:
-
Benoit Parrot authored
Global shared resources (like hw overlays) for omapdrm are implemented as a part of atomic state using the drm_private_obj infrastructure available in the atomic core. omap_global_state is introduced as a drm atomic private object. The two funcs omap_get_global_state() and omap_get_existing_global_state() are the two variants that will be used to access omap_global_state. drm_mode_config_init() needs to be called earlier because it creates/initializes the private_obj link list maintained by the atomic framework. The private_obj link list has to exist prior to calling drm_atomic_private_obj_init(). Similarly the cleanup handler are reordered appropriately. Signed-off-by:
-
Benoit Parrot authored
In preparation to add omap plane state specific extensions we need to subclass drm_plane_state and add the relevant helpers. The addition of specific extension will be done separately. Signed-off-by:
-
Benoit Parrot authored
Split out the hardware overlay specifics from omap_plane. To start, the hw overlays are statically assigned to planes. The goal is to eventually assign hw overlays dynamically to planes during plane->atomic_check() based on requested caps (scaling, YUV, etc). And then perform hw overlay re-assignment if required. Signed-off-by:
-
Benoit Parrot authored
In order to be able to dynamically assign overlays to planes we need to be able to asses the overlay capabilities. Add a helper function to be able to retrieve the supported capabilities of an overlay. And export the function to check if a fourcc is supported on a given overlay. Signed-off-by:
-
Benoit Parrot authored
We currently assume that an overlay has the same maximum width and maximum height as the overlay manager. This assumption is incorrect. On some variants the overlay manager maximum width is twice the maximum width that the overlay can handle. We need to add the appropriate data per variant as well as export a helper function to retrieve the data so check can be made dynamically in omap_plane_atomic_check(). Signed-off-by:
-
Neil Armstrong authored
Call drm_atomic_helper_check_plane_state() from the plane atomic_check() callback in order to add plane state sanity checking. It will permit filtering out totally bad scaling factors, even if the real check are done later in the atomic commit. Calling drm_atomic_helper_check_plane_state() also sets plane_state->visible which will be useful when dynamically assigning hw overlays to planes. Signed-off-by:
-
Ivaylo Dimitrov authored
Memory of BOs backed by TILER is not contiguous, but omap_gem_map_dma_buf() exports it like it is. This leads to (possibly) invalid memory accesses if another device imports such a BO. Fix that by providing sg that correctly describes TILER memory layout. Align TILER allocations to page, so importer to be able to correctly set its MMU if have one. Set export size accounting for the alignment. Also, make sure to destroy sg on unpin, as it is no longer valid. Tested on Motorola Droid4 by using GPU (sgx540) to render. Suggested-by:
Matthijs van Duin <matthijsvanduin@gmail.com> Signed-off-by:
Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Reviewed-by:
-
- 07 Dec, 2021 4 commits
-
-
Douglas Anderson authored
When we added the support for the AUX channel in commit 13afcdd7 ("drm/bridge: parade-ps8640: Add support for AUX channel") we forgot to set "drm_dev" to avoid the warning splat at the beginning of drm_dp_aux_register(). Since everything was working I guess I never noticed the splat when testing against mainline. In any case, it's easy to fix. This is basically just like commit 6cba3fe4 ("drm/dp: Add backpointer to drm_device in drm_dp_aux") but just for the parade-ps8640. Fixes: 13afcdd7 ("drm/bridge: parade-ps8640: Add support for AUX channel") Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Philip Chen <philipchen@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211206162907.1.I1f5d1eba741e4663050ec1b8e39a753f6e42e38b@changeid
-
yangcong authored
At present, we have enough panel to confirm the effect, update the initial code to achieve the best effect. Such as gamma, Gop timing. They are all minor modifications and doesn't affect the lighting of the panel. a)Boe-tv110c9m panel Optimized touch horizontal grain. b)Inx-hj110iz panel Optimized GOP timing and gamma. Signed-off-by:
yangcong <yangcong5@huaqin.corp-partner.google.com> Reviewed-by:
-
John Keeping authored
Allow drm_fbdev_generic_setup() to pick the default bpp value for the framebuffer. This has no functional impact because the default is 32, given that mode_config.preferred_depth is not set for Rockchip. Suggested-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
John Keeping <john@metanate.com> Signed-off-by:
-
John Keeping authored
The Rockchip fbdev code does not add anything compared to drm_fbdev_generic_setup(); the one custom function for .fb_mmap does the same thing as gem_prime_mmap which is called by the helper. Signed-off-by:
-
- 06 Dec, 2021 2 commits
-
-
Arnd Bergmann authored
The aspeed driver uses the gem_cma_helper code, but does noto enforce enabling this through Kconfig: x86_64-linux-ld: drivers/gpu/drm/aspeed/aspeed_gfx_drv.o:(.rodata+0x2c8): undefined reference to `drm_gem_cma_prime_import_sg_table' x86_64-linux-ld: drivers/gpu/drm/aspeed/aspeed_gfx_drv.o:(.rodata+0x2d8): undefined reference to `drm_gem_cma_dumb_create' x86_64-linux-ld: drivers/gpu/drm/aspeed/aspeed_gfx_crtc.o: in function `aspeed_gfx_pipe_update': aspeed_gfx_crtc.c:(.text+0xe5): undefined reference to `drm_fb_cma_get_gem_obj' Add the same 'select' that is used in other such drivers. Fixes: 09717af7 ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
The fsl-dcu driver uses the gem_cma_helper code, but does noto enforce enabling this through Kconfig: arm-linux-gnueabi-ld: drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.o:(.rodata+0x32c): undefined reference to `drm_gem_cma_prime_import_sg_table' arm-linux-gnueabi-ld: drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.o:(.rodata+0x334): undefined reference to `drm_gem_cma_dumb_create' arm-linux-gnueabi-ld: drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.o: in function `fsl_dcu_drm_plane_atomic_update': fsl_dcu_drm_plane.c:(.text+0x144): undefined reference to `drm_fb_cma_get_gem_obj' Add the same 'select' that is used in other such drivers. Fixes: 09717af7 ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option") Signed-off-by:
-
- 02 Dec, 2021 1 commit
-
-
Thomas Zimmermann authored
GEM helper libraries use struct drm_driver.gem_create_object to let drivers override GEM object allocation. On failure, the call returns NULL. Change the semantics to make the calls return a pointer-encoded error. This aligns the callback with its callers. Fixes the ingenic driver, which already returns an error pointer. Also update the callers to handle the involved types more strictly. Signed-off-by:
Steven Price <steven.price@arm.com> Acked-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20211130095255.26710-1-tzimmermann@suse.de
-
- 01 Dec, 2021 6 commits
-
-
Zack Rusin authored
TTM takes full control over TTM_PL_SYSTEM placed buffers. This makes driver internal usage of TTM_PL_SYSTEM prone to errors because it requires the drivers to manually handle all interactions between TTM which can swap out those buffers whenever it thinks it's the right thing to do and driver. CPU buffers which need to be fenced and shared with accelerators should be placed in driver specific placements that can explicitly handle CPU/accelerator buffer fencing. Currently, apart, from things silently failing nothing is enforcing that requirement which means that it's easy for drivers and new developers to get this wrong. To avoid the confusion we can document this requirement and clarify the solution. This came up during a discussion on dri-devel: https://lore.kernel.org/dri-devel/232f45e9-8748-1243-09bf-56763e6668b3@amd.comSigned-off-by:
Zack Rusin <zackr@vmware.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211110145034.487512-1-zackr@vmware.com
-
Zack Rusin authored
There's never a need to access our internal kernel bo's from user-space. Those objects are used exclusively for internal support to guest backed surfaces (in otable setup and mob page tables) and there's no need to have them be of device type, i.e. mmappable from user-space. Signed-off-by:
Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211105193845.258816-6-zackr@vmware.com
-
Zack Rusin authored
For larger (bigger than a page) and noncontiguous mobs we have to create page tables that allow the host to find the memory. Those page tables just used regular system memory. Unfortunately in TTM those BO's are not allowed to be busy thus can't be fenced and we have to fence those bo's because we don't want to destroy the page tables while the host is still executing the command buffers which might be accessing them. To solve it we introduce a new placement VMW_PL_SYSTEM which is very similar to TTM_PL_SYSTEM except that it allows fencing. This fixes kernel oops'es during unloading of the driver (and pci hot remove/add) which were caused by busy BO's in TTM_PL_SYSTEM being present in the delayed deletion list in TTM (TTM_PL_SYSTEM manager is destroyed before the delayed deletions are executed) Signed-off-by:
-
Zack Rusin authored
Some of our hosts have a bug where rescaning a pci bus results in stale fifo memory being mapped on the host. This makes any fifo communication impossible resulting in various kernel crashes. Instead of unexpectedly crashing, predictably fail to load the driver which will preserve the system. Fixes: fb1d9738 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU") Signed-off-by:
-
Zack Rusin authored
The ttm mem global state was leaking if the vmwgfx driver load failed. In case of a driver load failure we have to make sure we also release the ttm mem global state. Signed-off-by:
-
Zack Rusin authored
TTM during the transition to the new page allocator lost the ability to constrain the allocations via the lower_mem_limit. The code has been unused since the change: 256dd44b ("drm/ttm: nuke old page allocator") and there's no reason to keep it. Fixes: 256dd44b ("drm/ttm: nuke old page allocator") Signed-off-by:
-
- 30 Nov, 2021 13 commits
-
-
Christian König authored
Calling dma_resv_add_excl_fence() with the fence as NULL and expecting that that this frees up the fences is simply abuse of the internals of the dma_resv object. v2: drop the fence pruning completely. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211129120659.1815-4-christian.koenig@amd.com
-
Christian König authored
This is just abusing internals of the dma_resv object. Signed-off-by:
-
Maarten Lankhorst authored
The signaled bit is already used for quick testing if a fence is signaled. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by:
-
Christian König authored
I'm not sure why it is useful to know the number of fences in the reservation object, but we try to avoid exposing the dma_resv_shared_list() function. So use the iterator instead. If more information is desired we could use dma_resv_describe() as well. Signed-off-by:
-
Peter Collingbourne authored
It has been observed that with certain monitors such as the HP Z27n, the register 0x825e reads a value of 0x79 when the HDMI cable is connected and 0x78 when it is disconnected, i.e. bit 0 appears to correspond to the HDMI connection status and bit 2 is never set. Therefore, change the driver to check bit 0 instead of bit 2. Signed-off-by:
Peter Collingbourne <pcc@google.com> Link: https://linux-review.googlesource.com/id/I7e76411127e1ce4988a3f6d0c8ba5f1c3d880c23Reviewed-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211117020724.2647769-1-pcc@google.com
-
Thomas Zimmermann authored
Link drm_fb_cma_helper.o into drm_cma_helper.ko if CONFIG_DRM_KMS_HELPER has been set. Remove CONFIG_DRM_KMS_CMA_HELPER config option. Selecting KMS helpers and CMA will now automatically enable CMA KMS helpers. Some drivers' Kconfig files did not correctly select KMS or CMA helpers. Fix this as part of the change. Signed-off-by:
-
Thomas Zimmermann authored
The MIPI DBI helpers access struct drm_gem_cma_object.vaddr in a few places. Replace all instances with the correct generic GEM functions. Use drm_gem_fb_vmap() for mapping a framebuffer's GEM objects and drm_gem_fb_vunmap() for unmapping them. This removes the dependency on CMA helpers within MIPI DBI. Signed-off-by:
-
Thomas Zimmermann authored
Change all GEM CMA object functions that receive a GEM object of type struct drm_gem_object to expect an object of type struct drm_gem_cma_object instead. This change reduces the number of upcasts from struct drm_gem_object by moving them into callers. The C compiler can now verify that the GEM CMA functions are called with the correct type. For consistency, the patch also renames drm_gem_cma_free_object to drm_gem_cma_free. It further updates documentation for a number of functions. Signed-off-by:
-
Thomas Zimmermann authored
Wrap GEM CMA functions for struct drm_gem_object_funcs and update all callers. This will allow for an update of the public interfaces of the GEM CMA helper library. Signed-off-by:
-
Thomas Zimmermann authored
Restructure the header file for CMA helpers by moving declarations for driver and file operations to the end of the file. No functional changes. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211115120148.21766-2-tzimmermann@suse.de
-
Thomas Zimmermann authored
The DRM hashtable code is only used by internal functions for legacy UMS drivers. Move the implementation behind CONFIG_DRM_LEGACY and the declarations into legacy header files. Unexport the symbols. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211129094841.22499-4-tzimmermann@suse.de
-
Thomas Zimmermann authored
Besides some legacy code, vmwgfx is the only user of DRM's hash- table implementation. Copy the code into the driver, so that the core code can be retired. No functional changes. However, the real solution for vmwgfx is to use Linux' generic hash-table functions. v2: * add TODO item for updating vmwgfx (Sam) Signed-off-by:
-
Thomas Zimmermann authored
Remove the include statement for drm_hashtab.h. It's not required by TTM. Signed-off-by:
-
- 29 Nov, 2021 1 commit
-
-
Cai Huoqing authored
Mark 'tidss_pm_ops' as __maybe_unused to avoid the warning: unused variable 'tidss_pm_ops' Fixes: 6e120594 ("drm/tidss: Make use of the helper macro SET_RUNTIME_PM_OPS()") Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Reviewed-by:
-
- 27 Nov, 2021 4 commits
-
-
Javier Martinez Canillas authored
The patch for commit 6a2d2ddf ("drm: Move nomodeset kernel parameter to the DRM subsystem") was generated with config 'diff.noprefix true'. But later was applied using 'cat nomodeset.mbox | dim apply-branch' on a machine with 'diff.noprefix false'. And command 'git am --scissors -3' as used by the dim tool doesn't handle that case well, since the 3-way merge wrongly resolves the path for new file drivers/gpu/drm/drm_nomodeset.c as gpu/drm/drm_nomodeset.c instead. It led to the following build error as reported by the kernel test robot: make[4]: *** No rule to make target 'drivers/gpu/drm/drm_nomodeset.o', needed by 'drivers/gpu/drm/built-in.a'. Fixes: 6a2d2ddf ("drm: Move nomodeset kernel parameter to the DRM subsystem") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
-
Javier Martinez Canillas authored
The message printed when nomodeset is present in the kernel command line makes it look as if the parameter must never be used and it's a bad idea. But there are valid reasons to use this parameter and the message should not imply otherwise. Change the text to be more accurate and restrained. Suggested-by:
Jani Nikula <jani.nikula@intel.com> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211112133230.1595307-7-javierm@redhat.com
-
Javier Martinez Canillas authored
The nomodeset kernel command line parameter is not documented. Its name is quite vague and is not intuitive what's the behaviour when it is set. Document in kernel-parameters.txt what actually happens when nomodeset is used. That way, users could know if they want to enable this option. Signed-off-by:
-
Javier Martinez Canillas authored
This relationship was only for historical reasons and the nomodeset option should be available even on platforms that don't enable CONFIG_VGA_CONSOLE. Suggested-by:
-
