- 12 Feb, 2024 9 commits
-
-
Michał Winiarski authored
Fix one of the tests in drm_mm that was not converted prior to drm_debug_printer removal, causing tests build failure. Fixes: e154c4fc ("drm: remove drm_debug_printer in favor of drm_dbg_printer") Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Erico Nunes authored
Some debug messages carried the ip name, or included "lima", or included both the ip name and then the numbered ip name again. Make the messages more consistent by always looking up and showing the ip name first. Signed-off-by:
Erico Nunes <nunes.erico@gmail.com> Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240124025947.2110659-9-nunes.erico@gmail.com
-
Erico Nunes authored
The previous 500ms default timeout was fairly optimistic and could be hit by real world applications. Many distributions targeting devices with a Mali-4xx already bumped this timeout to a higher limit. We can be generous here with a high value as 10s since this should mostly catch buggy jobs like infinite loop shaders, and these don't seem to happen very often in real applications. Signed-off-by:
-
Erico Nunes authored
Marking the context as guilty currently only makes the application which hits a single timeout problem to stop its rendering context entirely. All jobs submitted later are dropped from the guilty context. Lima runs on fairly underpowered hardware for modern standards and it is not entirely unreasonable that a rendering job may time out occasionally due to high system load or too demanding application stack. In this case it would be generally preferred to report the error but try to keep the application going. Other similar embedded GPU drivers don't make use of the guilty context flag. Now that there are reliability improvements to the lima timeout recovery handling, drop the guilty contexts to let the application keep running in this case. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Vasily Khoruzhick <anarsoul@gmail.com> Signed-off-by:
-
Erico Nunes authored
There are several unexplained and unreproduced cases of rendering timeouts with lima, for which one theory is high IRQ latency coming from somewhere else in the system. This kind of occurrence may cause applications to trigger unnecessary resets of the GPU or even applications to hang if it hits an issue in the recovery path. Panfrost already does some special handling to account for such "spurious timeouts", it makes sense to have this in lima too to reduce the chance that it hit users. Signed-off-by:
-
Erico Nunes authored
This is required for reliable hard resets. Otherwise, doing a hard reset while a task is still running (such as a task which is being stopped by the drm_sched timeout handler) may result in random mmu write timeouts or lockups which cause the entire gpu to hang. Signed-off-by:
-
Erico Nunes authored
This is required for reliable hard resets. Otherwise, doing a hard reset while a task is still running (such as a task which is being stopped by the drm_sched timeout handler) may result in random mmu write timeouts or lockups which cause the entire gpu to hang. Signed-off-by:
-
Erico Nunes authored
Lima gp jobs use an async reset to avoid having to wait for the soft reset right after a job. The soft reset is done at the end of a job and a reset_complete flag is expected to be set at the next job. However, in case the user runs into a job timeout from any application, a hard reset is issued to the hardware. This hard reset clears the reset_complete flag, which causes an error message to show up before the next job. This is probably harmless for the execution but can be very confusing to debug, as it blames a reset timeout on the next application to submit a job. Reset the async_reset flag when doing the hard reset so that we don't get that message. Signed-off-by:
-
Erico Nunes authored
Lima pp jobs use an async reset to avoid having to wait for the soft reset right after a job. The soft reset is done at the end of a job and a reset_complete flag is expected to be set at the next job. However, in case the user runs into a job timeout from any application, a hard reset is issued to the hardware. This hard reset clears the reset_complete flag, which causes an error message to show up before the next job. This is probably harmless for the execution but can be very confusing to debug, as it blames a reset timeout on the next application to submit a job. Reset the async_reset flag when doing the hard reset so that we don't get that message. Signed-off-by:
-
- 09 Feb, 2024 31 commits
-
-
Randy Dunlap authored
When VIDEO is not set, there is a build error. Fix that by selecting VIDEO for PS3_PS3AV. ERROR: modpost: ".video_get_options" [drivers/ps3/ps3av_mod.ko] undefined! Fixes: dae7fbf4 ("driver/ps3: Include <video/cmdline.h> for mode parsing") Fixes: a3b6792e ("video/cmdline: Introduce CONFIG_VIDEO for video= parameter") Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Aneesh Kumar K.V <aneesh.kumar@kernel.org> Cc: Naveen N. Rao <naveen.n.rao@linux.ibm.com> Cc: linuxppc-dev@lists.ozlabs.org Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Geoff Levand <geoff@infradead.org> Acked-by:
Geoff Levand <geoff@infradead.org> Cc: linux-fbdev@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Jani Nikula authored
Convert the remaining drm_debug_printer users over to drm_dbg_printer, as it can handle the cases without struct drm_device pointer, and also provides drm debug category and prefix support. Remove drm_debug_printer altogether. Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/18b5b91e62d071675a651f6f91c58f05ad74134a.1705410327.git.jani.nikula@intel.com
-
Jani Nikula authored
Prefer the device specific debug printer. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/35929b030f7ba67cd32808d42e916aa9cfb5709d.1705410327.git.jani.nikula@intel.com
-
Jani Nikula authored
There's already a related drm_printer. Use it to preserve the context instead of a separate pr_err(). Signed-off-by:
-
Jani Nikula authored
Prefer the device specific debug printer. Signed-off-by:
-
Jani Nikula authored
Use the existing drm printer infrastructure instead of local macros. Signed-off-by:
-
Jani Nikula authored
Prefer the device specific debug printer. Signed-off-by:
-
Jani Nikula authored
Prefer the device specific debug printer. Signed-off-by:
-
Jani Nikula authored
We've lacked a device specific debug printer. Add one. Take category into account too. __builtin_return_address(0) is inaccurate here, so don't use it. If necessary, we can later pass __func__ to drm_dbg_printer() by wrapping it inside a macro. Signed-off-by:
-
Jani Nikula authored
Avoid forward declarations in subsequent changes, but separate this movement to an independent change. Signed-off-by:
-
Jani Nikula authored
With few users for drm_err_printer(), it's still feasible to convert it to be device specific. Use drm_err() under the hood. While at it, make the prefix optional. Signed-off-by:
-
Jani Nikula authored
There are no more users of the ->get_edid callback left. They've all been converted to ->edid_read. Remove the callback, and the fallback in drm_bridge_edid_read(). Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/34407a355ec6848fc44f8c30d245fcbc5687195e.1706038510.git.jani.nikula@intel.com
-
Jani Nikula authored
Prefer using the struct drm_edid based callback and functions. Signed-off-by:
-
Jani Nikula authored
Prefer using the struct drm_edid based callback and functions. Signed-off-by:
-
Jani Nikula authored
The EDID property should be updated between reading the EDID and adding the modes. Signed-off-by:
-
Jani Nikula authored
If EDID read fails, clear the EDID property and CEC address. Signed-off-by:
-
Jani Nikula authored
Prefer using the struct drm_edid based callback and functions. v2: Fix -Wuninitialized (kernel test robot) Signed-off-by:
-
Jani Nikula authored
Prefer using the struct drm_edid based callback and functions. Signed-off-by:
-
Jani Nikula authored
Prefer using the struct drm_edid based callback and functions. Signed-off-by:
-
Jani Nikula authored
Prefer using the struct drm_edid based callback and functions. Signed-off-by:
-
Jani Nikula authored
Prefer using the struct drm_edid based callback and functions. Signed-off-by:
-
Jani Nikula authored
Prefer using the struct drm_edid based callback and functions. Signed-off-by:
-
Jani Nikula authored
Remove the excess leading tabs. Signed-off-by:
-
Jani Nikula authored
Prefer using the struct drm_edid based callback and functions. Signed-off-by:
-
Jani Nikula authored
Prefer using the struct drm_edid based callback and functions. Signed-off-by:
-
Jani Nikula authored
Prefer using the struct drm_edid based callback and functions. Signed-off-by:
-
Jani Nikula authored
Use the pre-parsed information instead of parsing EDID again. Signed-off-by:
-
Jani Nikula authored
Prefer using the struct drm_edid based callback and functions. v2: Fix -Wsometimes-uninitialized (kernel test robot) Signed-off-by:
-
Jani Nikula authored
Prefer using the struct drm_edid based callback and functions. Signed-off-by:
-
Jani Nikula authored
Prefer using the struct drm_edid based callback and functions. Signed-off-by:
-
Jani Nikula authored
Prefer using the struct drm_edid based callback and functions. Signed-off-by:
-
