- 14 Nov, 2023 8 commits
-
-
Thomas Zimmermann authored
Contain struct drm_flip_task and its helper functions drm_flip_work_allocate_task() and drm_flip_work_queue_task() within drm_flip_work.c There are no callers outside of the flip-work code. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20231101103618.23806-2-tzimmermann@suse.de
-
Thomas Zimmermann authored
Preallocate the format-conversion state's storage in the plane's atomic_check function if a format conversion is necessary. Allows the update to fail if no memory is available. Avoids the same allocation within atomic_update, which may not fail. v6: * update patch for ssd132x support Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Tested-by:
-
Thomas Zimmermann authored
Preallocate the format-conversion state's storage in the plane's atomic_check function if a format conversion is necessary. Allows the update to fail if no memory is available. Avoids the same allocation within atomic_update, which may not fail. Also inline drm_plane_helper_atomic_check() into the driver and thus return early for invisible planes. Avoids memory allocation entirely in this case. Signed-off-by:
-
Thomas Zimmermann authored
Preallocate the format-conversion state's storage in the plane's atomic_check function if a format conversion is necessary. Allows the update to fail if no memory is available. Avoids the same allocation within atomic_update, which may not fail. Signed-off-by:
-
Thomas Zimmermann authored
Pass an instance of struct drm_format_conv_state to DRM's format conversion helpers. Update all callers. Most drivers can use the format-conversion state from their shadow- plane state. The shadow plane's destroy function releases the allocated buffer. Drivers will later be able to allocate a buffer of appropriate size in their plane's atomic_check code. The gud driver uses a separate thread for committing updates. For now, the update worker contains its own format-conversion state. Images in the format-helper tests are small. The tests preallocate a static page for the temporary buffer. Unloading the module releases the memory. v6: * update patch for ssd132x support v5: * avoid using unusupported shadow-plane state in repaper (Noralf) * fix documentation (Noralf, kernel test robot) v3: * store buffer in shadow-plane state (Javier, Maxime) * replace ARRAY_SIZE() with sizeof() (Jani) Signed-off-by:
-
Thomas Zimmermann authored
Store an instance of struct drm_format_conv_state in the shadow-plane state struct drm_shadow_plane_state. Many drivers with shadow planes use DRM's format helpers to copy or convert the framebuffer data to backing storage in the scanout buffer. The shadow plane provides the necessary state and manages the conversion's intermediate buffer memory. Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Tested-by:
-
Thomas Zimmermann authored
Hold temporary memory for format conversion in an instance of struct drm_format_conv_state. Update internal helpers of DRM's format-conversion code accordingly. Drivers will later be able to maintain this cache by themselves. Besides caching, struct drm_format_conv_state will be useful to hold additional information for format conversion, such as palette data or foreground/background colors. This will enable conversion from indexed color formats to component-based formats. v5: * improve documentation (Javier, Noralf) v3: * rename struct drm_xfrm_buf to struct drm_format_conv_state (Javier) * remove managed cleanup * add drm_format_conv_state_copy() for shadow-plane support Signed-off-by:
-
Luben Tuikov authored
From Jani: The drm_print.[ch] facilities use very few pr_*() calls directly. The users of pr_*() calls do not necessarily include <drm/drm_print.h> at all, and really don't have to. Even the ones that do include it, usually have <linux/...> includes first, and <drm/...> includes next. Notably, <linux/kernel.h> includes <linux/printk.h>. And, of course, <linux/printk.h> defines pr_fmt() itself if not already defined. No, it's encouraged not to use pr_*() at all, and prefer drm device based logging, or device based logging. This reverts commit 36245bd0. Signed-off-by:
Luben Tuikov <ltuikov89@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/878r75wzm9.fsf@intel.comAcked-by:
Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231111024130.11464-2-ltuikov89@gmail.com
-
- 13 Nov, 2023 11 commits
-
-
Danilo Krummrich authored
Currently the DRM GPUVM offers common infrastructure to track GPU VA allocations and mappings, generically connect GPU VA mappings to their backing buffers and perform more complex mapping operations on the GPU VA space. However, there are more design patterns commonly used by drivers, which can potentially be generalized in order to make the DRM GPUVM represent a basis for GPU-VM implementations. In this context, this patch aims at generalizing the following elements. 1) Provide a common dma-resv for GEM objects not being used outside of this GPU-VM. 2) Provide tracking of external GEM objects (GEM objects which are shared with other GPU-VMs). 3) Provide functions to efficiently lock all GEM objects dma-resv the GPU-VM contains mappings of. 4) Provide tracking of evicted GEM objects the GPU-VM contains mappings of, such that validation of evicted GEM objects is accelerated. 5) Provide some convinience functions for common patterns. Big thanks to Boris Brezillon for his help to figure out locking for drivers updating the GPU VA space within the fence signalling path. Acked-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Suggested-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231108001259.15123-12-dakr@redhat.com
-
Danilo Krummrich authored
Add an abstraction layer between the drm_gpuva mappings of a particular drm_gem_object and this GEM object itself. The abstraction represents a combination of a drm_gem_object and drm_gpuvm. The drm_gem_object holds a list of drm_gpuvm_bo structures (the structure representing this abstraction), while each drm_gpuvm_bo contains list of mappings of this GEM object. This has multiple advantages: 1) We can use the drm_gpuvm_bo structure to attach it to various lists of the drm_gpuvm. This is useful for tracking external and evicted objects per VM, which is introduced in subsequent patches. 2) Finding mappings of a certain drm_gem_object mapped in a certain drm_gpuvm becomes much cheaper. 3) Drivers can derive and extend the structure to easily represent driver specific states of a BO for a certain GPUVM. The idea of this abstraction was taken from amdgpu, hence the credit for this idea goes to the developers of amdgpu. Cc: Christian König <christian.koenig@amd.com> Acked-by:
-
Danilo Krummrich authored
Implement reference counting for struct drm_gpuvm. Acked-by:
-
Danilo Krummrich authored
Allocate struct nouveau_uvmm separately in preparation for subsequent commits introducing reference counting for struct drm_gpuvm. While at it, get rid of nouveau_uvmm_init() as indirection of nouveau_uvmm_ioctl_vm_init() and perform some minor cleanups. Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Danilo Krummrich authored
Introduce flags for struct drm_gpuvm, this required by subsequent commits. Acked-by:
-
Danilo Krummrich authored
DRM GEM objects private to a single GPUVM can use a shared dma-resv. Make use of the shared dma-resv of GPUVM rather than a driver specific one. The shared dma-resv originates from a "root" GEM object serving as container for the dma-resv to make it compatible with drm_exec. In order to make sure the object proving the shared dma-resv can't be freed up before the objects making use of it, let every such GEM object take a reference on it. Reviewed-by:
-
Danilo Krummrich authored
Provide a common dma-resv for GEM objects not being used outside of this GPU-VM. This is used in a subsequent patch to generalize dma-resv, external and evicted object handling and GEM validation. Acked-by:
-
Danilo Krummrich authored
Use drm_gpuvm_range_valid() in order to validate userspace requests. Reviewed-by:
-
Danilo Krummrich authored
Drivers may use this function to validate userspace requests in advance, hence export it. Acked-by:
-
Danilo Krummrich authored
Don't always WARN in drm_gpuvm_check_overflow() and separate it into a drm_gpuvm_check_overflow() and a dedicated drm_gpuvm_warn_check_overflow() variant. This avoids printing warnings due to invalid userspace requests. Acked-by:
-
Danilo Krummrich authored
Use drm_WARN() and drm_WARN_ON() variants to indicate drivers the context the failing VM resides in. Acked-by:
-
- 11 Nov, 2023 2 commits
-
-
Gurchetan Singh authored
There are two problems with the current method of determining the virtio-gpu debug name. 1) TASK_COMM_LEN is defined to be 16 bytes only, and this is a Linux kernel idiom (see PR_SET_NAME + PR_GET_NAME). Though, Android/FreeBSD get around this via setprogname(..)/getprogname(..) in libc. On Android, names longer than 16 bytes are common. For example, one often encounters a program like "com.android.systemui". The virtio-gpu spec allows the debug name to be up to 64 bytes, so ideally userspace should be able to set debug names up to 64 bytes. 2) The current implementation determines the debug name using whatever task initiated virtgpu. This is could be a "RenderThread" of a larger program, when we actually want to propagate the debug name of the program. To fix these issues, add a new CONTEXT_INIT param that allows userspace to set the debug name when creating a context. It takes a null-terminated C-string as the param value. The length of the string (excluding the terminator) **should** be <= 64 bytes. Otherwise, the debug_name will be truncated to 64 bytes. Link to open-source userspace: https://android-review.googlesource.com/c/platform/hardware/google/gfxstream/+/2787176Signed-off-by:
Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by:
Josh Simonot <josh.simonot@gmail.com> Reviewed-by:
Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by:
-
Gurchetan Singh authored
drm_virtgpu_context_set_param defines both param and value to be u64s. Signed-off-by:
-
- 10 Nov, 2023 13 commits
-
-
AngeloGioacchino Del Regno authored
All of the MediaTek SoCs supported by Panfrost can completely cut power to the GPU during full system sleep without any user-noticeable delay in the resume operation, as shown by measurements taken on multiple MediaTek SoCs (MT8183/86/92/95). As an example, for MT8195 - a "before" with only runtime PM operations (so, without turning on/off regulators), and an "after" executing both the system sleep .resume() handler and .runtime_resume() (so the time refers to T_Resume + T_Runtime_Resume): Average Panfrost-only system sleep resume time, before: ~33500ns Average Panfrost-only system sleep resume time, after: ~336200ns Keep in mind that this additional ~308200 nanoseconds delay happens only in resume from a full system suspend, and not in runtime PM operations, hence it is acceptable. Measurements were also taken on MT8186, showing a delay of ~312000 ns. Testing of this happened on all of the aforementioned MediaTek SoCs, but: MT8183 got tested only by KernelCI with <=10 suspend/resume cycles MT8186, MT8192, MT8195 were tested manually with over 100 suspend/resume cycles with GNOME DE (Mutter + Wayland). Signed-off-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Signed-off-by:
-
AngeloGioacchino Del Regno authored
Some platforms/SoCs can power off the GPU entirely by completely cutting off power, greatly enhancing battery time during system suspend: add a new pm_feature GPU_PM_VREG_OFF to allow turning off the GPU regulators during full suspend only on selected platforms. Signed-off-by:
-
AngeloGioacchino Del Regno authored
All of the MediaTek SoCs supported by Panfrost can switch the clocks off and on during system sleep to save some power without any user experience penalty. Measurements taken on multiple MediaTek SoCs (MT8183/8186/8192/8195) show that adding this will not prolong the time that is required to resume the system in any meaningful way. As an example, for MT8195 - a "before" with only runtime PM operations (so, without turning on/off GPU clocks), and an "after" executing both the system sleep .resume() handler and .runtime_resume() (so the time refers to T_Resume + T_Runtime_Resume): Average Panfrost-only system sleep resume time, before: ~28000ns Average Panfrost-only system sleep resume time, after: ~33500ns Signed-off-by:
-
AngeloGioacchino Del Regno authored
Currently, the GPU is being internally powered off for runtime suspend and turned back on for runtime resume through commands sent to it, but note that the GPU doesn't need to be clocked during the poweroff state, hence it is possible to save some power on selected platforms. Add suspend and resume handlers for full system sleep and then add a new panfrost_gpu_pm enumeration and a pm_features variable in the panfrost_compatible structure: BIT(GPU_PM_CLK_DIS) will be used to enable this power saving technique only on SoCs that are able to safely use it. Note that this was implemented only for the system sleep case and not for runtime PM because testing on one of my MediaTek platforms showed issues when turning on and off clocks aggressively (in PM runtime) resulting in a full system lockup. Doing this only for full system sleep never showed issues during my testing by suspending and resuming the system continuously for more than 100 cycles. Signed-off-by:
-
AngeloGioacchino Del Regno authored
In many cases, soft reset takes more than 1 microsecond, but definitely less than 10; moreover in the poweron flow, tilers, shaders and l2 will become ready (each) in less than 10 microseconds as well. Even in the cases (at least on my platforms, rarely) in which those take more than 10 microseconds, it's very unlikely to see both soft reset and poweron to take more than 70 microseconds. Shorten the polling delay to 10 microseconds to consistently reduce the runtime resume time of the GPU. As an indicative example, measurements taken on a MediaTek MT8195 SoC Average runtime resume time in nanoseconds before this commit: GDM, user selection up/down: 88435ns GDM, Text Entry (typing user/password): 91489ns GNOME Desktop, idling, GKRELLM running: 73200ns After this commit: GDM: user selection up/down: 26690ns GDM: Text Entry (typing user/password): 27917ns GNOME Desktop, idling, GKRELLM running: 25304ns Signed-off-by:
-
AngeloGioacchino Del Regno authored
Even though soft reset should ideally never fail, during development of some power management features I managed to get some bits wrong: this resulted in GPU soft reset failures, where the GPU was never able to recover, not even after suspend/resume cycles, meaning that the only way to get functionality back was to reboot the machine. Perform a hard reset after a soft reset failure to be able to recover the GPU during runtime (so, without any machine reboot). Signed-off-by:
-
AngeloGioacchino Del Regno authored
The layout of the registers {TILER,SHADER,L2}_PWROFF_LO, used to request powering off cores, is the same as the {TILER,SHADER,L2}_PWRON_LO ones: this means that in order to request poweroff of cores, we are supposed to write a bitmask of cores that should be powered off! This means that the panfrost_gpu_power_off() function has always been doing nothing. Fix powering off the GPU by writing a bitmask of the cores to poweroff to the relevant PWROFF_LO registers and then check that the transition (from ON to OFF) has finished by polling the relevant PWRTRANS_LO registers. While at it, in order to avoid code duplication, move the core mask logic from panfrost_gpu_power_on() to a new panfrost_get_core_mask() function, used in both poweron and poweroff. Fixes: f3ba9122 ("drm/panfrost: Add initial panfrost driver") Signed-off-by: -
Danilo Krummrich authored
Currently, job flow control is implemented simply by limiting the number of jobs in flight. Therefore, a scheduler is initialized with a credit limit that corresponds to the number of jobs which can be sent to the hardware. This implies that for each job, drivers need to account for the maximum job size possible in order to not overflow the ring buffer. However, there are drivers, such as Nouveau, where the job size has a rather large range. For such drivers it can easily happen that job submissions not even filling the ring by 1% can block subsequent submissions, which, in the worst case, can lead to the ring run dry. In order to overcome this issue, allow for tracking the actual job size instead of the number of jobs. Therefore, add a field to track a job's credit count, which represents the number of credits a job contributes to the scheduler's credit limit. Signed-off-by:
-
Luben Tuikov authored
Define pr_fmt() as "[drm] " for DRM code using pr_*() facilities, especially when no devices are available. This makes it easier to browse kernel logs. Signed-off-by:
-
Hsin-Yi Wang authored
Add a few generic edp panels used by mt8186 chromebooks. Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Acked-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
-
Hsin-Yi Wang authored
Rename AUO 0x235c B116XTN02 to B116XTN02.3 according to decoding edid. Fixes: 3db24204 ("drm/panel-edp: Add AUO B116XTN02, BOE NT116WHM-N21,836X2, NV116WHM-N49 V8.0") Cc: stable@vger.kernel.org Signed-off-by:
-
Hsin-Yi Wang authored
Rename AUO 0x405c B116XAK01 to B116XAK01.0 and adjust the timing of auo_b116xak01: T3=200, T12=500, T7_max = 50 according to decoding edid and datasheet. Fixes: da458286 ("drm/panel: Add support for AUO B116XAK01 panel") Cc: stable@vger.kernel.org Signed-off-by:
-
Luben Tuikov authored
Don't "wake up" the GPU scheduler unless the entity is ready, as well as we can queue to the scheduler, i.e. there is no point in waking up the scheduler for the entity unless the entity is ready. Signed-off-by:
-
- 09 Nov, 2023 6 commits
-
-
Jani Nikula authored
Occasionally it's necessary for drivers to modify the SADs of an ELD, but it's not so cool to have drivers poke at the ELD buffer directly. Using the helpers to translate between 3-byte SAD and struct cea_sad, add ELD helpers to get/set the SADs from/to an ELD. v2: s/i/sad_index/ (Mitul) Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8e9a05f2b1e0dd184132d636e1e778e8917ec25d.1698747331.git.jani.nikula@intel.com
-
Jani Nikula authored
Add helpers to pack/unpack SADs. Both ways and non-static, as follow-up work needs them. v2: Add include to get the declarations Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by:
-
Jani Nikula authored
Use a temporary variable struct cea_sad *, instead of using struct cea_sad ** directly with the double dereferences. It's arguably easier on the eyes, and drops a set of parenthesis too. Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by:
-
Jani Nikula authored
Reduce the dependencies on drm_eld.h. Some files might be able to drop the dependency on drm_edid.h too with the direct inclusion of drm_eld.h. Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by:
-
Jani Nikula authored
Unify on kernel types. Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Reviewed-by:
-
Jani Nikula authored
The drm_edid.[ch] files are starting to be a bit crowded, and with plans to add more ELD related functionality, it's perhaps cleanest to split the ELD code out to a header of its own. Include drm_eld.h from drm_edid.h for starters, and leave it to follow-up work to only include drm_eld.h where needed. Cc: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com> Reviewed-by:
-
