- 01 Jul, 2021 8 commits
-
-
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:
Boris Brezillon <boris.brezillon@collabora.com> Acked-by:
Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210630062751.2832545-9-boris.brezillon@collabora.com
-
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:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-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 27 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:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-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
-
Thomas Zimmermann authored
The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in armada. Signed-off-by:
-
Thomas Zimmermann authored
For KMS drivers, replace the IRQ check in VBLANK ioctls with a check for vblank support. IRQs might be enabled wthout vblanking being supported. This change also removes the DRM framework's only dependency on IRQ state for non-legacy drivers. For legacy drivers with userspace modesetting, the original test remains in drm_wait_vblank_ioctl(). v4: * avoid preprocessor ifdef in drm_wait_vblank_ioctl() (Jani, Thierry) v3: * optimize test in drm_wait_vblank_ioctl() for KMS case (Liviu) * update docs for drm_irq_uninstall() v2: * keep the old test for legacy drivers in drm_wait_vblank_ioctl() (Daniel) Signed-off-by:
-
Thomas Zimmermann authored
Replace usage of struct drm_device.irq_enabled with the driver's own state field struct radeon_device.irq.installed. The field in the DRM device structure is considered legacy and should not be used by KMS drivers. Signed-off-by:
-
Thomas Zimmermann authored
Remove the check around drm_irq_uninstall(). The same test is done by the function internally. The tested state in irq_enabled is considered obsolete and should not be used by KMS drivers. Signed-off-by:
Tian Tao <tiantao6@hisilicon.com> Acked-by:
-
Thomas Zimmermann authored
Replace usage of struct drm_device.irq_enabled with the driver's own state field struct amdgpu_device.irq.installed. The field in the DRM device structure is considered legacy and should not be used by KMS drivers. Signed-off-by:
-
- 28 Jun, 2021 1 commit
-
-
Boris Brezillon authored
The panfrost driver tries to kill in-flight jobs on FD close after destroying the FD scheduler entities. For this to work properly, we need to make sure the jobs popped from the scheduler entities have been queued at the HW level before declaring the entity idle, otherwise we might iterate over a list that doesn't contain those jobs. Suggested-by:
-
- 24 Jun, 2021 3 commits
-
-
Daniel Vetter authored
Goes through all the drivers and deletes the default hook since it's the default now. Acked-by:
David Lechner <david@lechnology.com> Acked-by:
Noralf Trønnes <noralf@tronnes.org> Acked-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Joel Stanley <joel@jms.id.au> Cc: Andrew Jeffery <andrew@aj.id.au> Cc: "Noralf Trønnes" <noralf@tronnes.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Emma Anholt <emma@anholt.net> Cc: David Lechner <david@lechnology.com> Cc: Kamlesh Gurudasani <kamlesh.gurudasani@gmail.com> Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: linux-aspeed@lists.ozlabs.org Cc: linux-arm-kernel@lists.infradead.org Cc: xen-devel@lists.xenproject.org Link: https://patchwork.freedesktop.org/patch/msgid/20210622165511.3169559-14-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
It's tedious to review this all the time, and my audit showed that arcpgu actually forgot to set this. Make this the default and stop worrying. Again I sprinkled WARN_ON_ONCE on top to make sure we don't have strange combinations of hooks: cleanup_fb without prepare_fb doesn't make sense, and since simpler drivers are all new they better be GEM based drivers. v2: Warn and bail when it's _not_ a GEM driver (Noralf) v3: It's neither ... nor, not not (Sam) Acked-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Noralf Trønnes <noralf@tronnes.org> Acked-by:
-
Daniel Vetter authored
I guess no one ever tried running omap together with lima or panfrost, not even sure that's possible. Anyway for consistency, fix this. Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by:
-
