- 01 Jul, 2021 17 commits
-
-
Thomas Zimmermann authored
Print the name of the DRM driver when taking over fbdev devices. Makes the output to dmesg more consistent. Note that the driver name is only used for printing a string to the kernel log. No UAPI is affected by this change. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Nirmoy Das <nirmoy.das@amd.com> Acked-by: Chen-Yu Tsai <wens@csie.org> # sun4i Acked-by: Neil Armstrong <narmstrong@baylibre.com> # meson Link: https://patchwork.freedesktop.org/patch/msgid/20210629135833.22679-1-tzimmermann@suse.de
-
Boris Brezillon authored
Experience has shown that 1ms is sometimes not enough, even when the GPU is running at its maximum frequency, not to mention that an MMU operation might take longer if the GPU is running at a lower frequency, which is likely to be the case if devfreq is active. Let's pick a significantly bigger timeout value (1ms -> 100ms) to be on the safe side. v5: * New patch Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210630062751.2832545-17-boris.brezillon@collabora.com
-
Steven Price authored
The hardware has a set of '_NEXT' registers that can hold a second job while the first is executing. Make use of these registers to enqueue a second job per slot. v5: * Fix a comment in panfrost_job_init() v3: * Fix the done/err job dequeuing logic to get a valid active state * Only enable the second slot on GPUs supporting jobchain disambiguation * Split interrupt handling in sub-functions Signed-off-by:
-
Boris Brezillon authored
If the process who submitted these jobs decided to close the FD before the jobs are done it probably means it doesn't care about the result. v5: * Add a panfrost_exception_is_fault() helper and the DRM_PANFROST_EXCEPTION_MAX_NON_FAULT value v4: * Don't disable/restore irqs when taking the job_lock (not needed since this lock is never taken from an interrupt context) v3: * Set fence error to ECANCELED when a TERMINATED exception is received Signed-off-by:
-
Boris Brezillon authored
If we can recover from a fault without a reset there's no reason to issue one. v3: * Drop the mention of Valhall requiring a reset on JOB_BUS_FAULT * Set the fence error to -EINVAL instead of having per-exception error codes Signed-off-by:
-
Boris Brezillon authored
Things are unlikely to resolve until we reset the GPU. Let's not wait for other faults/timeout to happen to trigger this reset. Signed-off-by:
-
Boris Brezillon authored
If we don't do that, we have to wait for the job timeout to expire before the fault jobs gets killed. v3: * Make sure the AS is re-enabled when new jobs are submitted to the context Signed-off-by:
-
Boris Brezillon authored
This is not yet needed because we let active jobs be killed during by the reset and we don't really bother making sure they can be restarted. But once we start adding soft-stop support, controlling when we deal with the remaining interrrupts and making sure those are handled before the reset is issued gets tricky if we keep job interrupts active. Let's prepare for that and mask+flush job IRQs before issuing a reset. v4: * Add a comment explaining why we WARN_ON(!job) in the irq handler * Keep taking the job_lock when evicting stalled jobs v3: * New patch Signed-off-by:
-
Boris Brezillon authored
Now that we can pass our own workqueue to drm_sched_init(), we can use an ordered workqueue on for both the scheduler timeout tdr and our own reset work (which we use when the reset is not caused by a fault/timeout on a specific job, like when we have AS_ACTIVE bit stuck). This guarantees that the timeout handlers and reset handler can't run concurrently which drastically simplifies the locking. v5: * Don't call cancel_delayed_timeout() in the reset path (those works are canceled in drm_sched_stop()) v4: * Actually pass the reset workqueue to drm_sched_init() * Don't call cancel_work_sync() in panfrost_reset(). It will deadlock since it might be called from the reset work, which is executing and cancel_work_sync() will wait for the handler to return. Checking the reset pending status should avoid spurious resets v3: * New patch Suggested-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Boris Brezillon authored
This should avoid switching to interrupt context when the GPU is under heavy use. v3: * Don't take the job_lock in panfrost_job_handle_irq() Signed-off-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by:
-
Boris Brezillon authored
Expose a helper to trigger a GPU reset so we can easily trigger reset operations outside the job timeout handler. Signed-off-by:
-
Boris Brezillon authored
Do the exception -> string translation using a table. This way we get rid of those magic numbers and can easily add new fields if we need to attach extra information to exception types. v4: * Don't expose exception type to userspace * Merge the enum definition and the enum -> string table declaration in the same patch v3: * Drop the error field Signed-off-by:
-
Boris Brezillon authored
Currently unused. We'll add it back if we need per-GPU definitions. Signed-off-by:
-
Boris Brezillon authored
Exception types will be defined as an enum. v4: * Fix typo in the commit message Signed-off-by:
-
Boris Brezillon authored
If the fence creation fail, we can return the error pointer directly. The core will update the fence error accordingly. Signed-off-by:
-
Boris Brezillon authored
Mali Midgard/Bifrost GPUs have 3 hardware queues but only a global GPU reset. This leads to extra complexity when we need to synchronize timeout works with the reset work. One solution to address that is to have an ordered workqueue at the driver level that will be used by the different schedulers to queue their timeout work. Thanks to the serialization provided by the ordered workqueue we are guaranteed that timeout handlers are executed sequentially, and can thus easily reset the GPU from the timeout handler without extra synchronization. v5: * Add a new paragraph to the timedout_job() method v3: * New patch v4: * Actually use the timeout_wq to queue the timeout work Suggested-by:
Lucas Stach <l.stach@pengutronix.de> Acked-by:
Christian König <christian.koenig@amd.com> Cc: Qiang Yu <yuq825@gmail.com> Cc: Emma Anholt <emma@anholt.net> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210630062751.2832545-3-boris.brezillon@collabora.com
-
Boris Brezillon authored
The documentation is a bit vague and doesn't really describe what the ->timedout_job() is expected to do. Let's add a few more details. v5: * New patch Suggested-by:
-
- 30 Jun, 2021 1 commit
-
-
Mikel Rychliski authored
radeon_ttm_bo_destroy() is attempting to access the resource object to update memory counters. However, the resource object is already freed when ttm calls this function via the destroy callback. This causes an oops when a bo is freed: BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:radeon_ttm_bo_destroy+0x2c/0x100 [radeon] Call Trace: radeon_bo_unref+0x1a/0x30 [radeon] radeon_gem_object_free+0x33/0x50 [radeon] drm_gem_object_release_handle+0x69/0x70 [drm] drm_gem_handle_delete+0x62/0xa0 [drm] ? drm_mode_destroy_dumb+0x40/0x40 [drm] drm_ioctl_kernel+0xb2/0xf0 [drm] drm_ioctl+0x30a/0x3c0 [drm] ? drm_mode_destroy_dumb+0x40/0x40 [drm] radeon_drm_ioctl+0x49/0x80 [radeon] __x64_sys_ioctl+0x8e/0xd0 Avoid the issue by updating the counters in the delete_mem_notify callback instead. Also, fix memory statistic updating in radeon_bo_move() to identify the source type correctly. The source type needs to be saved before the move, because the moved from object may be altered by the move. Fixes: bfa3357e ("drm/ttm: allocate resource object instead of embedding it v2") Signed-off-by:
Mikel Rychliski <mikel@mikelr.com> Reviewed-by:
-
- 29 Jun, 2021 22 commits
-
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in zte. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in xlnx. Signed-off-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in vmxgfx. All usage of the field within vmwgfx can safely be removed. Signed-off-by:
Zack Rusin <zackr@vmware.com> Reviewed-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in vkms. Signed-off-by:
Melissa Wen <melissa.srw@gmail.com> Reviewed-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in vc4. Signed-off-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't use it in tidss. Signed-off-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in tegra. Signed-off-by:
Thierry Reding <treding@nvidia.com> Acked-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in sun4i. Signed-off-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in stm. Signed-off-by:
Yannick Fertre <yannick.fertre@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210625082222.3845-20-tzimmermann@suse.de
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in sti. Signed-off-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in rockchip. Signed-off-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in rcar-du. Signed-off-by:
-
Thomas Zimmermann authored
Replace usage of struct drm_device.irq_enabled with the driver's own state field struct omap_drm_device.irq_enabled. The field in the DRM device structure is considered legacy and should not be used by KMS drivers. Signed-off-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in nouveau. Signed-off-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in mediatek. Signed-off-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in dcss. Signed-off-by:
Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Acked-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in imx. v3: * move dcss changes into separate patch (Laurentiu) Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Acked-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in kirin. Signed-off-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in exynos. Signed-off-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in malidp. Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Acked-by:
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in komeda. Signed-off-by:
-
Thomas Zimmermann authored
Replace usage of struct drm_device.irq_enabled with the driver's own state field struct drm_i915_private.irq_enabled. The field in the DRM device structure is considered legacy and should not be used by KMS drivers. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210625082222.3845-7-tzimmermann@suse.de
-
