- 20 Feb, 2023 2 commits
-
-
Simon Ser authored
v2: mention caps, note that the IOCTLs might fail, document that user-space needs a data structure to keep track of the handles (Daniel V.) Signed-off-by:
Simon Ser <contact@emersion.fr> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Pekka Paalanen <ppaalanen@gmail.com> Cc: Daniel Stone <daniel@fooishbar.org> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230217162151.59996-2-contact@emersion.fr
-
Simon Ser authored
There are two important details missing from the docs: - If the memory object backing the FB already has a GEM handle, it's not re-used, a new one is generated. - Aliased planes will return the same GEM handle. v2: document how user-space can obtain DMA-BUF FDs without leaking handles (Pekka) Signed-off-by:
-
- 17 Feb, 2023 2 commits
-
-
Thomas Weißschuh authored
Since commit ee6d3dd4 ("driver core: make kobj_type constant.") the driver core allows the usage of const struct kobj_type. Take advantage of this to constify the structure definition to prevent modification at runtime. Signed-off-by:
Thomas Weißschuh <linux@weissschuh.net> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Simon Ser authored
This is a bit tricky, because of the ref'counting considerations. See also [1] for more discussion about this topic. Since this is kernel docs, I've decided to elaborate a bit less on the user-space details. [1]: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110Signed-off-by:
-
- 16 Feb, 2023 4 commits
-
-
Maxime Ripard authored
This reverts commit ae71ab58. Commit ae71ab58 ("drm/vc4: hdmi: Enforce the minimum rate at runtime_resume") was introduced to work around an issue partly due to the clk-bcm2835 driver on the RaspberryPi0-3. Since we're not using that driver for our HDMI clocks, we can now revert it. Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20230126-rpi-display-fw-clk-cleanup-v1-4-d646ff6fb842@cerno.techSigned-off-by:
Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
This reverts commit 3bc6a37f. Commit 3bc6a37f ("drm/vc4: hdmi: Fix HSM clock too low on Pi4") was introduced to work around an issue partly due to the clk-bcm2835 driver on the RaspberryPi0-3. Since we're not using that driver for our HDMI clocks, we can now revert that inelegant solution. Reviewed-by:
-
Maxime Ripard authored
On the RaspberryPi0-3, the HSM clock was provided by the clk-bcm2835 driver, but on the Pi4 it was provided by the firmware through the clk-raspberrypi driver. The clk-bcm2835 driver registers the HSM clock using the CLK_SET_RATE_GATE flag that prevents any modification to the rate while the clock is active. This meant that we needed to call clk_set_min_rate() before our call to pm_runtime_resume_and_get() since our runtime_resume implementation needs to enable the HSM clock for the HDMI controller registers to be functional. However, the HSM clock is part of the HDMI power domain which might not be powered prior to the pm_runtime_resume_and_get() call, so we could end up changing the rate of the HSM clock while its power domain was disabled. We recently changed the backing driver for the RaspberryPi0-3 to clk-raspberrypi though, which doesn't have such restrictions. We can thus move the clk_set_min_rate() after our call to runtime_resume and avoid the access while the power domain is disabled. Reviewed-by:
-
Maxime Ripard authored
The 120MHz value hardcoded in the call to max_t to compute the HSM rate is defined in the driver as HSM_MIN_CLOCK_FREQ, let's switch to it so that it's more readable. Reviewed-by:
-
- 15 Feb, 2023 3 commits
-
-
Thomas Weißschuh authored
Instead of relying on an accidental, transitive inclusion of linux/leds.h use it directly. Also drop the forware definition of struct led_classdev that is now provided by linux/leds.h. Signed-off-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Zack Rusin authored
v3: Fix vmw_user_bo_lookup which was also dropping the gem reference before the kernel was done with buffer depending on userspace doing the right thing. Same bug, different spot. It is possible for userspace to predict the next buffer handle and to destroy the buffer while it's still used by the kernel. Delay dropping the internal reference on the buffers until kernel is done with them. Instead of immediately dropping the gem reference in vmw_user_bo_lookup and vmw_gem_object_create_with_handle let the callers decide when they're ready give the control back to userspace. Also fixes the second usage of vmw_gem_object_create_with_handle in vmwgfx_surface.c which wasn't grabbing an explicit reference to the gem object which could have been destroyed by the userspace on the owning surface at any point. Signed-off-by:
Zack Rusin <zackr@vmware.com> Fixes: 8afa13a0 ("drm/vmwgfx: Implement DRIVER_GEM") Reviewed-by:
Martin Krastev <krastevm@vmware.com> Reviewed-by:
Maaz Mombasawala <mombasawalam@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230211050514.2431155-1-zack@kde.org
-
Zack Rusin authored
ttm_bo_init_reserved on failure puts the buffer object back which causes it to be deleted, but kfree was still being called on the same buffer in vmw_bo_create leading to a double free. After the double free the vmw_gem_object_create_with_handle was setting the gem function objects before checking the return status of vmw_bo_create leading to null pointer access. Fix the entire path by relaying on ttm_bo_init_reserved to delete the buffer objects on failure and making sure the return status is checked before setting the gem function objects on the buffer object. Signed-off-by:
-
- 14 Feb, 2023 9 commits
-
-
Zack Rusin authored
In commit 18025378 ("drm/ttm: stop allocating dummy resources during BO creation") ttm stopped allocating dummy resources but vmwgfx was never ported to handle it. Make the driver treat null resources as initial creation and port code to handle null resources in general. Fixes kernel oops'es on boot with vmwgfx. Signed-off-by:
-
Zack Rusin authored
Various bits of the driver used raw ttm_buffer_object instead of the driver specific vmw_bo object. All those places used to duplicate the mapped bo caching policy of vmw_bo. Instead of duplicating all of that code and special casing various functions to work both with vmw_bo and raw ttm_buffer_object's unify the buffer object handling code. As part of that work fix the naming of bo's, e.g. insted of generic backup use 'guest_memory' because that's what it really is. All of it makes the driver easier to maintain and the code easier to read. Saves 100+ loc as well. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230131033542.953249-9-zack@kde.org
-
Zack Rusin authored
Problem with explicit placement selection in vmwgfx is that by the time the buffer object needs to be validated the information about which placement was supposed to be used is lost. To workaround this the driver had a bunch of state in various places e.g. as_mob or cpu_blit to somehow convey the information on which placement was intended. Fix it properly by allowing the buffer objects to hold their preferred placement so it can be reused whenever needed. This makes the entire validation pipeline a lot easier both to understand and maintain. Signed-off-by:
-
Zack Rusin authored
Rename dummy to is_iomem because that's what it is even if we're not activelly using it. Makes the code easier to read. Signed-off-by:
-
Zack Rusin authored
Base mapped count is useless because the ttm unmap functions handle null maps just fine so completely remove all the code related to it. Signed-off-by:
-
Zack Rusin authored
Only the legacy display unit requires pinning of the fb memory in vram. Both the screen objects and screen targets can present from any buffer. That makes the pinning abstraction pointless. Simplify all of the code and move it to the legacy display unit, the only place that needs it. Signed-off-by:
-
Zack Rusin authored
The rest of the drivers which are using ttm have mostly standardized on driver_prefix_bo as the name for subclasses of the TTM buffer object. Make vmwgfx match the rest of the drivers and follow the same naming semantics. This is especially clear given that the name of the file in which the object was defined is vmw_bo.c. Signed-off-by:
-
Zack Rusin authored
Remove the explicit bo_free parameter which was switching between vmw_bo_bo_free and vmw_gem_destroy which had exactly the same implementation. It makes no sense to keep parameter which is always the same, remove it and all code referencing it. Instead use the vmw_bo_bo_free directly. Signed-off-by:
-
Zack Rusin authored
Before vmwgfx supported gem it needed to implement the entire mmap logic explicitly. With GEM support that's not needed and the generic code can be used by simply setting the vm_ops to vmwgfx specific ones on the gem object itself. Removes a lot of code from vmwgfx without any functional difference. Signed-off-by:
-
- 10 Feb, 2023 3 commits
-
-
Asahi Lina authored
Other functions touching shmem->sgt take the pages lock, so do that here too. drm_gem_shmem_get_pages() & co take the same lock, so move to the _locked() variants to avoid recursive locking. Discovered while auditing locking to write the Rust abstractions. Fixes: 2194a63a ("drm: Add library for shmem backed GEM objects") Fixes: 4fa3d66f ("drm/shmem: Do dma_unmap_sg before purging pages") Signed-off-by:
Asahi Lina <lina@asahilina.net> Reviewed-by:
-
Maíra Canal authored
vgem_fence_open() instantiates a mutex for a particular fence instance, but never destroys it by calling mutex_destroy() in vgem_fence_close(). So, add the missing mutex_destroy() to guarantee proper resource destruction. Fixes: 40777984 ("drm/vgem: Attach sw fences to exported vGEM dma-buf (ioctl)") Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230202125517.427976-1-mcanal@igalia.com
-
Christian König authored
Not used by any driver any more. Signed-off-by:
-
- 09 Feb, 2023 1 commit
-
-
Somalapuram Amaranath authored
Use amdgpu_bo_in_cpu_visible_vram() instead. v2 (chk): fix test inversion Signed-off-by:
Somalapuram Amaranath <Amaranath.Somalapuram@amd.com> Reviewed-by:
-
- 07 Feb, 2023 1 commit
-
-
John Keeping authored
Commit 15b9ca16 ("drm: Config orientation property if panel provides it") added a helper to set the panel orientation early but only connected this for drm_bridge_connector, which constructs a panel bridge with DRM_BRIDGE_ATTACH_NO_CONNECTOR and creates the connector itself. When the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is not specified and the panel_bridge creates its own connector the orientation is not set unless the panel does it in .get_modes which is too late and leads to a warning splat from __drm_mode_object_add() because the device is already registered. Call the necessary function to set add the orientation property when the connector is created so that it is available before the device is registered. Signed-off-by:
John Keeping <john@metanate.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
- 06 Feb, 2023 10 commits
-
-
Christian König authored
We have checks for this in the individual drivers move callback, but it's probably better to generally forbid that on a higher level. Also stops exporting ttm_resource_compat() since that's not necessary any more after removing the extra checks in vmwgfx. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Signed-off-by:
-
Christian König authored
That should not be necessary any more when drivers should at least be able to handle a move without a resource. Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130120636.63765-5-matthew.auld@intel.com
-
Christian König authored
That should not be necessary any more when drivers should at least be able to handle the move without a resource. Signed-off-by:
-
Matthew Auld authored
In the next few patches, when initially creating a ttm BO, the bo->resource is NULL, and the driver is then expected to handle the initial dummy move. However, if this is created as a system resource the first ttm_tt we create will always have the clear value set to false. Previously the initial ttm_tt would be created in ttm_bo_validate() with the clear parameter always set to true. Signed-off-by:
Christian König <ckoenig.leichtzumerken@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230130101230.25347-3-matthew.auld@intel.comAcked-by:
-
Matthew Auld authored
In the near future TTM will have NULL bo->resource when the object is initially created, plus after calling into pipeline-gutting. Try to handle the remaining cases. In practice NULL bo->resource should be taken to mean swapped-out or purged object. v2 (Andrzej): - Rather make i915_ttm_cpu_maps_iomem() return false with NULL resource. References: 516198d3 ("drm/i915: audit bo->resource usage v3") Signed-off-by:Andrzej Hajda <andrzej.hajda@intel.com> Acked-by:
-
Matthew Auld authored
Sparse complains with: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1066:21: sparse: expected restricted vm_fault_t [assigned] [usertype] ret drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1066:21: sparse: got int Fixes: 516198d3 ("drm/i915: audit bo->resource usage v3") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Stanislaw Gruszka authored
Update according to new dma-buf locking scheme. Remove redundant WARN_ON()'s, dma_buf functions internally have the same warnings already. Signed-off-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by:
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230202092114.2637452-5-stanislaw.gruszka@linux.intel.com
-
Stanislaw Gruszka authored
Avoid below spurious warning: [ 264.844029] DMA-API: intel_vpu 0000:00:0b.0: mapping sg segment longer than device claims to support [len=143360] [max=65536] [ 264.844038] WARNING: CPU: 0 PID: 1254 at kernel/dma/debug.c:1160 debug_dma_map_sg+0x6ca/0xb70 Signed-off-by:
-
Andrzej Kacprowski authored
The VPU_JSM_MSG_CONTEXT_DELETE will remove any resources associated with the SSID, that included any blobs create by the user space application. The command can also remove doorbell registrations, but since this does not work in HW scheduling case, we do not depend on this capability and unregister the doorbells explicitly. Signed-off-by:
Andrzej Kacprowski <andrzej.kacprowski@linux.intel.com> Signed-off-by:
-
Andrzej Kacprowski authored
FW API structures have been updated to fix misaligned structure members. Also changed JSM message header format to account for future improvements. Added explicit check for minimum supported JSM API version. Signed-off-by:
-
- 05 Feb, 2023 5 commits
-
-
Rob Clark authored
In the error path, rockchip_drm_gem_object_mmap() is dropping an obj reference that it doesn't own. Fixes: 41315b79 ("drm/rockchip: use drm_gem_mmap helpers") Signed-off-by:
Rob Clark <robdclark@chromium.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230119231734.2884543-1-robdclark@gmail.com
-
John Keeping authored
If a buffer is allocated with alloc_kmap, then it is vmap'd on creation and there is no reason to map it again in rockchip_gem_prime_vmap() when the existing mapping can be used. Signed-off-by:
-
Brian Norris authored
The downstream code from which this was derived didn't ever run through this 'switch' block with non-AFBC formats, but the upstream code does -- we use this function to probe whether a given format is supported. Demote the warning to eliminate this sort of warning seen on every boot: [drm] unsupported AFBC format[3231564e] And make it warn more than once, because if we *actually* care to see what formats we're probing/rejecting and for what reasons, we probably care about more than just the first message. Drop the comment, because one of the two *is* commonly reachable. And lastly, drop the unreachable return; we'd do better to let the compiler complain if we start hitting this unexpectedly. Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Michael Riesch authored
The Rockchip VOP2 features an internal RGB output block, which can be attached any video port of the VOP2. Add support for this output block. Signed-off-by:
Michael Riesch <michael.riesch@wolfvision.net> Reviewed-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Michael Riesch authored
Let the function name vop2_create_crtcs reflect that the function creates multiple CRTCS. Also, use a symmetric function pair to create and destroy the CRTCs and the corresponding planes. Signed-off-by:
-
