Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] CRTC atomic callbacks call sleeping functions in atomic context.
--
--- Patch [11]: [PATCH 11/70] drm/imx: dc: Switch to drm_atomic_helper_crtc_create_state ---
commit 81ac70d774e55256bc7f69e9538e45aed1e198c8
Author: Maxime Ripard <[email protected]>
drm/imx: dc: Switch to drm_atomic_helper_crtc_create_state
The imx dc crtc implementation uses the deprecated
drm_atomic_helper_crtc_reset() as its reset hook. Switch to
drm_atomic_helper_crtc_create_state() instead.
> diff --git a/drivers/gpu/drm/imx/dc/dc-crtc.c b/drivers/gpu/drm/imx/dc/dc-crtc.c
> index 764510ff90a4a..0d64186a99018 100644
> --- a/drivers/gpu/drm/imx/dc/dc-crtc.c
> +++ b/drivers/gpu/drm/imx/dc/dc-crtc.c
> @@ -98,7 +98,7 @@ static void dc_crtc_disable_vblank(struct drm_crtc *crtc)
> }
>
> static const struct drm_crtc_funcs dc_crtc_funcs = {
> - .reset = drm_atomic_helper_crtc_reset,
> + .atomic_create_state = drm_atomic_helper_crtc_create_state,
[Severity: High]
This isn't a bug introduced by this patch, but while reviewing the CRTC
implementation in this file, I noticed that several atomic callbacks might be
calling sleeping functions.
For example, does dc_crtc_atomic_enable() call pm_runtime_resume_and_get(),
which can sleep?
Additionally, it looks like dc_crtc_atomic_enable(), dc_crtc_atomic_flush(),
and dc_crtc_atomic_disable() all use DC_CRTC_WAIT_FOR_COMPLETION_TIMEOUT(),
which waits for a completion and puts the task to sleep.
According to DRM subsystem guidelines, CRTC atomic enable, disable, and update
callbacks run in an atomic context where sleeping is forbidden. Could this
cause scheduling while atomic panics or warnings during non-blocking commits
and page flips?
> .destroy = drm_crtc_cleanup,
> .set_config = drm_atomic_helper_set_config,
> .page_flip = drm_atomic_helper_page_flip,
--
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=11
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.