- 01 Dec, 2023 23 commits
-
-
Maíra Canal authored
Create tracepoints to track the three major events of a CPU job lifetime: 1. Submission of a `v3d_submit_cpu` IOCTL 2. Beginning of the execution of a CPU job 3. Ending of the execution of a CPU job Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Iago Toral Quiroga <itoral@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231130164420.932823-11-mcanal@igalia.com
-
Maíra Canal authored
Currently, v3d_get_extensions() only parses multisync data and assigns it to the `struct v3d_submit_ext`. But, to implement the CPU job with user extensions, we want v3d_get_extensions() to be able to parse CPU job data and assign it to the `struct v3d_cpu_job`. Therefore, allow the function v3d_get_extensions() to use `struct v3d_cpu_job *` as a parameter. If the `struct v3d_cpu_job *` is assigned to NULL, it means that the job is a GPU job and CPU job extensions should be rejected. Signed-off-by:
-
Melissa Wen authored
Create a new type of job, a CPU job. A CPU job is a type of job that performs operations that requires CPU intervention. The overall idea is to use user extensions to enable different types of CPU job, allowing the CPU job to perform different operations according to the type of user extension. The user extension ID identify the type of CPU job that must be dealt. Having a CPU job is interesting for synchronization purposes as a CPU job has a queue like any other V3D job and can be synchoronized by the multisync extension. Signed-off-by:
Melissa Wen <mwen@igalia.com> Co-developed-by:
-
Maíra Canal authored
We want to allow the IOCTLs to allocate the job without initiating it. This will be useful for the CPU job submission IOCTL, as the CPU job has the need to use information from the user extensions. Currently, the user extensions are parsed before the job allocation, making it impossible to fill the CPU job when parsing the user extensions. Therefore, decouple the job allocation from the job initiation. Signed-off-by:
-
Maíra Canal authored
Currently, two multisync extensions can be added to the same job and only the last multisync extension will be used. To avoid this vulnerability, don't allow two multisync extensions in the same job. Signed-off-by:
-
Melissa Wen authored
Instead of checking if the job is NULL every time we call the function, check it inside the function. Signed-off-by:
-
Melissa Wen authored
We will include a new job submission type, the CPU job submission. For readability and maintability, separate the job submission IOCTLs and related operations from v3d_gem.c. Minor fix in the CSD submission kernel doc: CSD (texture formatting) -> CSD (compute shader). Signed-off-by:
-
Melissa Wen authored
IOCTLs related to BO operations reside on the file v3d_bo.c. The wait BO ioctl is the only IOCTL regarding BOs that is placed in a different file. So, move it to the v3d_bo.c file. Signed-off-by:
-
Melissa Wen authored
v3d_mmu_get_offset header was added but the function was never defined. Just remove it. Signed-off-by:
-
Tomi Valkeinen authored
At the moment the driver does not use DRM_PLANE_COMMIT_ACTIVE_ONLY, but still checks for crtc->state->active in tidss_crtc_atomic_flush(), and skips the flush if the crtc is not active. The exact reason why DRM_PLANE_COMMIT_ACTIVE_ONLY is not used has been lost in history. DRM_PLANE_COMMIT_ACTIVE_ONLY does also affect the plane updates, and I think the issue was related to multi-display systems and moving planes between the displays. However, it is possible the issue was only present on the older DSS hardware, handled by the omapdrm driver (on which the tidss driver is loosely based). Reviewing the code related to DRM_PLANE_COMMIT_ACTIVE_ONLY does not show any issues, and testing on J7 EVM with two displays works fine. Change the driver to use DRM_PLANE_COMMIT_ACTIVE_ONLY. Reviewed-by:
Aradhya Bhatia <a-bhatia1@ti.com> Link: https://lore.kernel.org/r/20231109-tidss-probe-v2-11-ac91b5ea35c0@ideasonboard.comSigned-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
-
Tomi Valkeinen authored
tidss_crtc_atomic_flush() checks if the crtc is enabled, and if not, returns immediately as there's no reason to do any register changes. However, the code checks for 'crtc->state->enable', which does not reflect the actual HW state. We should instead look at the 'crtc->state->active' flag. This causes the tidss_crtc_atomic_flush() to proceed with the flush even if the active state is false, which then causes us to hit the WARN_ON(!crtc->state->event) check. Fix this by checking the active flag, and while at it, fix the related debug print which had "active" and "needs modeset" wrong way. Cc: <stable@vger.kernel.org> Fixes: 32a1795f ("drm/tidss: New driver for TI Keystone platform Display SubSystem") Reviewed-by:
-
Tomi Valkeinen authored
The IRQ setup code is overly complex. All we really need to do is initialize the related fields in struct tidss_device, and request the IRQ. We can drop all the HW accesses, as they are pointless: the driver will set the IRQs correctly when it needs any of the IRQs, and at probe time we have done a reset, so we know that all the IRQs are masked by default in the hardware. Thus we can combine the tidss_irq_preinstall() and tidss_irq_postinstall() into the tidss_irq_install() function, drop the HW accesses, and drop the use of spinlock, as this is done at init time and there can be no races. We can also drop the HW access from the tidss_irq_uninstall(), as the driver will anyway disable and suspend the hardware at remove time. Reviewed-by:
-
Tomi Valkeinen authored
The probe function calls dispc_softreset() before runtime PM is enabled and without enabling any of the DSS clocks. This happens to work by luck, and we need to make sure the DSS HW is active and the fclk is enabled. To fix the above, add a new function, dispc_init_hw(), which does: - pm_runtime_set_active() - clk_prepare_enable(fclk) - dispc_softreset(). This ensures that the reset can be successfully accomplished. Note that we use pm_runtime_set_active(), not the normal pm_runtime_get(). The reason for this is that at this point we haven't enabled the runtime PM yet and also we don't want the normal resume callback to be called: the dispc resume callback does some initial HW setup, and it expects that the HW was off (no video ports are streaming). If the bootloader has enabled the DSS and has set up a boot time splash-screen, the DSS would be enabled and streaming which might lead to issues with the normal resume callback. Fixes: c9b2d923 ("drm/tidss: Soft Reset DISPC on startup") Reviewed-by:
-
Tomi Valkeinen authored
K2G display controller does not support soft reset, but we can do the most important steps manually: mask the IRQs and disable the VPs. Reviewed-by:
-
Tomi Valkeinen authored
K2G doesn't have softreset feature. Instead of having every caller of dispc_softreset() check for K2G, move the check into dispc_softreset(), and make dispc_softreset() return 0 in case of K2G. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Tomi Valkeinen authored
Return an error value from dispc_softreset() so that the caller can handle the errors. Reviewed-by:
-
Tomi Valkeinen authored
We do a DSS reset in the middle of the dispc_init(). While that happens to work now, we should really make sure that e..g the fclk, which is acquired only later in the function, is enabled when doing a reset. This will be handled in a later patch, but for now, let's move the dispc_softreset() call to the end of dispc_init(), which is a sensible place for it anyway. Reviewed-by:
-
Tomi Valkeinen authored
No need to initialize the ret to 0 in dispc_softreset(). Reviewed-by:
-
Tomi Valkeinen authored
Use runtime PM autosuspend feature, with 1s timeout, to avoid unnecessary suspend-resume cycles when, e.g. the userspace temporarily turns off the crtcs when configuring the outputs. Reviewed-by:
-
Tomi Valkeinen authored
Use pm_runtime_resume_and_get() instead of pm_runtime_get_sync(), which will handle error situations better. Also fix the return, as there should be no reason for the current complex return. Reviewed-by:
-
Aradhya Bhatia authored
Add support for the DSS controller on TI's AM62A7 SoC in the tidss driver. This controller has 2 video pipelines that can render 2 video planes on over a screen, using the overlay managers. The output of the DSS comes from video port 2 (VP2) in the form of RGB88 DPI signals, while the VP1 is tied off inside the SoC. Also add and use a new type of VP, DISPC_VP_TIED_OFF, for the tied-off VP1 of AM62A DSS. Signed-off-by:
-
Aradhya Bhatia authored
The DSS controller on TI's AM62A7 SoC is an update from that on TI's AM625 SoC. Like the DSS in AM625, the DSS in this SoC has 2 video pipelines, but unlike the former, the latter only has one output port on VP2 to service DPI display sinks. Add the new controller's compatible. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by:
-
Andrew Davis authored
While a scatter-gather table having only 1 entry does imply it is contiguous, it is a logic error to assume the inverse. Tables can have more than 1 entry and still be contiguous. Use a proper check here. Signed-off-by:
Andrew Davis <afd@ti.com> Signed-off-by:
-
- 30 Nov, 2023 5 commits
-
-
Ramesh Errabolu authored
Fix the documentation of struct dma_buf members name and exp_name as to how these members are to be used and accessed. Signed-off-by:
Ramesh Errabolu <Ramesh.Errabolu@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231122160556.24948-1-Ramesh.Errabolu@amd.comSigned-off-by:
-
Dan Carpenter authored
If the call to vmap() fails the "page_nr" is one element beyond the end of the mips_data->pt_dma_addr[] and mips_data->pt_pages[] arrays. The way that this is traditionally written is that we clean up the partial loop iteration before the goto and then we can say while (--i >= 0). At that point we know that all the elements thus far are initialized so we don't need to have NULL checks. Fixes: 927f3e02 ("drm/imagination: Implement MIPS firmware processor and MMU support") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
Frank Binns <frank.binns@imgtec.com> Signed-off-by:
Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/a2d3210b-290f-4397-9c3e-efdcca94d8ac@moroto.mountain
-
Dan Carpenter authored
The pvr_build_firmware_filename() function returns NULL on error. It doesn't return error pointers. Fixes: f99f5f3e ("drm/imagination: Add GPU ID parsing and firmware loading") Signed-off-by:
-
Dan Carpenter authored
There is a cut and paste error so this code returns the wrong variable. Fixes: 1f88f017 ("drm/imagination: Get GPU resources") Signed-off-by:
-
Yuran Pereira authored
Checking `args` after calling `op_map_prepare` is unnecessary since if `op_map_prepare` was to be called with NULL args, it would lead to a NULL pointer dereference, thus never hitting that check. Hence remove the check and add a note to remind users of this function to ensure that args != NULL when calling this function for a map operation as it was suggested by Danilo [1]. [1] https://lore.kernel.org/lkml/6a1ebcef-bade-45a0-9bd9-c05f0226eb88@redhat.comSuggested-by:
Danilo Krummrich <dakr@redhat.com> Signed-off-by:
Yuran Pereira <yuran.pereira@hotmail.com> Signed-off-by:
-
- 29 Nov, 2023 12 commits
-
-
Thomas Hellström authored
Add the first version of the VM_BIND locking document which is intended to be part of the xe driver upstreaming agreement. The document describes and discuss the locking used during exec- functions, evicton and for userptr gpu-vmas. Intention is to be using the same nomenclature as the drm-vm-bind-async.rst. v2: - s/gvm/gpu_vm/g (Rodrigo Vivi) - Clarify the userptr seqlock with a pointer to mm/mmu_notifier.c (Rodrigo Vivi) - Adjust commit message accordingly. - Add SPDX license header. v3: - Large update to align with the drm_gpuvm manager locking - Add "Efficient userptr gpu_vma exec function iteration" section - Add "Locking at bind- and unbind time" section. v4: - Fix tabs vs space errors by untabifying (Rodrigo Vivi) - Minor style fixes and typos (Rodrigo Vivi) - Clarify situations where stale GPU mappings are occurring and how access through these mappings are blocked. (Rodrigo Vivi) - Insert into the toctree in implementation_guidelines.rst v5: - Add a section about recoverable page-faults. - Use local references to other documentation where possible (Bagas Sanjaya) - General documentation fixes and typos (Danilo Krummrich and Boris Brezillon) - Improve the documentation around locks that need to be grabbed from the dm-fence critical section (Boris Brezillon) - Add more references to the DRM GPUVM helpers (Danilo Krummrich and Boriz Brezillon) - Update the rfc/xe.rst document. v6: - Rework wording to improve readability (Boris Brezillon, Rodrigo Vivi, Bagas Sanjaya) - Various minor fixes across the document (Boris Brezillon) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Thomas Zimmermann authored
Drop the default implementations for file read, write and mmap operations. Each fbdev driver must now provide an implementation and select any necessary helpers. If no implementation has been set, fbdev returns an errno code to user space. The code is the same as if the operation had not been set in the file_operations struct. This change makes the fbdev helpers for I/O memory optional. Most systems only use system-memory framebuffers via DRM's fbdev emulation. v2: * warn once if I/O callbacks are missing (Javier) Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231127131655.4020-33-tzimmermann@suse.de
-
Thomas Zimmermann authored
Test in framebuffer read, write and drawing helpers if FBINFO_VIRTFB has been set correctly. Framebuffers in I/O memory should only be accessed with the architecture's respective helpers. Framebuffers in system memory should be accessed with the regular load and store operations. Presumably not all drivers get this right, so we now warn about it. Signed-off-by:
-
Thomas Zimmermann authored
Move the default fb_mmap code for I/O address spaces into the helper function fb_io_mmap(). The helper can either be called via struct fb_ops.fb_mmap or as the default if no fb_mmap has been set. Also set the new helper in __FB_DEFAULT_IOMEM_OPS_MMAP. In the mid-term, fb_io_mmap() is supposed to become optional. Fbdev drivers will initialize their struct fb_ops.fb_mmap to the helper and select a corresponding Kconfig token. The helper can then be made optional at compile time. Signed-off-by:
-
Thomas Zimmermann authored
If a driver sets struct fb_ops.fb_mmap, the fbdev core automatically calls pgprot_decrypted(). But the default fb_mmap code doesn't handle pgprot_decrypted(). Move the call to pgprot_decrypted() into each drivers' fb_mmap function. This only concerns fb_mmap functions for system and DMA memory. For I/O memory, which is the default case, nothing changes. The fb_mmap for I/O-memory can later be moved into a helper as well. DRM's fbdev emulation handles pgprot_decrypted() internally via the Prime helpers. Fbdev doesn't have to do anything in this case. In cases where DRM uses deferred I/O, this patch updates fb_mmap correctly. Signed-off-by:
-
Thomas Zimmermann authored
Fix coding style. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Rename the token to harmonize naming among various helpers. For example, I/O-memory helpers use FB_IOMEM_FOPS. Signed-off-by:
-
Thomas Zimmermann authored
Initialize all instances of struct fb_ops with fbdev initializer macros for framebuffers in I/O address space. Set the read/write, draw and mmap callbacks to the correct implementation and avoid implicit defaults. Also select the necessary helpers in Kconfig. Fbdev drivers sometimes rely on the callbacks being NULL for a default I/O-memory-based implementation to be invoked; hence requiring the I/O helpers to be built in any case. Setting all callbacks in all drivers explicitly will allow to make the I/O helpers optional. This benefits systems that do not use these functions. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231127131655.4020-27-tzimmermann@suse.de
-
Thomas Zimmermann authored
Split up lynxfb_ops and declare each as constant. The fb_ops instance used to be modified while initializing the driver. It is now constant and the driver picks the correct instance, depending on the settings for acceleration and cursor support. Signed-off-by:
-
Thomas Zimmermann authored
Initialize the instance of struct fb_ops with fbdev initializer macros for framebuffers in I/O address space. Set the read/write, draw and mmap callbacks to the correct implementation and avoid implicit defaults. Also select the necessary helpers in Kconfig. Fbdev drivers sometimes rely on the callbacks being NULL for a default I/O-memory-based implementation to be invoked; hence requiring the I/O helpers to be built in any case. Setting all callbacks in all drivers explicitly will allow to make the I/O helpers optional. This benefits systems that do not use these functions. Signed-off-by:
-
Thomas Zimmermann authored
Initialize the instance of struct fb_ops with fbdev initializer macros for framebuffers in DMA-able address space. This explictily sets the read/write, draw and mmap callbacks to the correct default implementation. Also select the necessary helpers in Kconfig. Fbdev drivers sometimes rely on the callbacks being NULL for a default implementation to be invoked; hence requireing the I/O helpers to be built in any case. Setting all callbacks in all drivers explicitly will allow to make the I/O helpers optional. This benefits systems that do not use these functions. Set the callbacks via macros. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Initialize the instance of struct fb_ops with fbdev initializer macros for framebuffers in DMA-able virtual address space. Set the read/write, draw and mmap callbacks to the correct implementation and avoid implicit defaults. Also select the necessary helpers in Kconfig. Fbdev drivers sometimes rely on the callbacks being NULL for a default I/O-memory-based implementation to be invoked; hence requiring the I/O helpers to be built in any case. Setting all callbacks in all drivers explicitly will allow to make the I/O helpers optional. This benefits systems that do not use these functions. Signed-off-by:
-
