* [PATCH 0/2] drm/msm/dpu: two fixes targeting 6.11
@ 2024-07-09 13:48 Dmitry Baryshkov
2024-07-09 13:48 ` [PATCH 1/2] drm/msm/dpu1: don't choke on disabling the writeback connector Dmitry Baryshkov
2024-07-09 13:48 ` [PATCH 2/2] drm/msm/dpu: don't play tricks with debug macros Dmitry Baryshkov
0 siblings, 2 replies; 8+ messages in thread
From: Dmitry Baryshkov @ 2024-07-09 13:48 UTC (permalink / raw)
To: Rob Clark, Abhinav Kumar, Sean Paul, Marijn Suijten,
David Airlie, Daniel Vetter, Jordan Crouse, Chandan Uddaraju,
Rajesh Yadav, Sravanthi Kollukuduru, Archit Taneja
Cc: linux-arm-msm, dri-devel, freedreno, linux-kernel,
Jeykumar Sankaran, stable, Leonard Lausen
Leonard Lausen reported an issue with suspend/resume of the sc7180
devices. Fix the WB atomic check, which caused the issue. Also make sure
that DPU debugging logs are always directed to the drm_debug / DRIVER so
that usual drm.debug masks work in an expected way.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
Dmitry Baryshkov (2):
drm/msm/dpu1: don't choke on disabling the writeback connector
drm/msm/dpu: don't play tricks with debug macros
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 14 ++------------
drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 14 +++++++-------
2 files changed, 9 insertions(+), 19 deletions(-)
---
base-commit: 0b58e108042b0ed28a71cd7edf5175999955b233
change-id: 20240709-dpu-fix-wb-6cd57e3eb182
Best regards,
--
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
^ permalink raw reply [flat|nested] 8+ messages in thread* [PATCH 1/2] drm/msm/dpu1: don't choke on disabling the writeback connector 2024-07-09 13:48 [PATCH 0/2] drm/msm/dpu: two fixes targeting 6.11 Dmitry Baryshkov @ 2024-07-09 13:48 ` Dmitry Baryshkov 2024-07-09 18:42 ` Abhinav Kumar 2024-07-09 13:48 ` [PATCH 2/2] drm/msm/dpu: don't play tricks with debug macros Dmitry Baryshkov 1 sibling, 1 reply; 8+ messages in thread From: Dmitry Baryshkov @ 2024-07-09 13:48 UTC (permalink / raw) To: Rob Clark, Abhinav Kumar, Sean Paul, Marijn Suijten, David Airlie, Daniel Vetter, Jordan Crouse, Chandan Uddaraju, Rajesh Yadav, Sravanthi Kollukuduru, Archit Taneja Cc: linux-arm-msm, dri-devel, freedreno, linux-kernel, Jeykumar Sankaran, stable, Leonard Lausen In order to prevent any errors on connector being disabled, move the state->crtc check upfront. This should fix the issues during suspend when the writeback connector gets forcebly disabled. Fixes: 71174f362d67 ("drm/msm/dpu: move writeback's atomic_check to dpu_writeback.c") Cc: stable@vger.kernel.org Reported-by: Leonard Lausen <leonard@lausen.nl> Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/57 Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c index 16f144cbc0c9..5c172bcf3419 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c @@ -39,6 +39,13 @@ static int dpu_wb_conn_atomic_check(struct drm_connector *connector, DPU_DEBUG("[atomic_check:%d]\n", connector->base.id); + crtc = conn_state->crtc; + if (!crtc) + return 0; + + if (!conn_state->writeback_job || !conn_state->writeback_job->fb) + return 0; + if (!conn_state || !conn_state->connector) { DPU_ERROR("invalid connector state\n"); return -EINVAL; @@ -47,13 +54,6 @@ static int dpu_wb_conn_atomic_check(struct drm_connector *connector, return -EINVAL; } - crtc = conn_state->crtc; - if (!crtc) - return 0; - - if (!conn_state->writeback_job || !conn_state->writeback_job->fb) - return 0; - crtc_state = drm_atomic_get_crtc_state(state, crtc); if (IS_ERR(crtc_state)) return PTR_ERR(crtc_state); -- 2.39.2 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] drm/msm/dpu1: don't choke on disabling the writeback connector 2024-07-09 13:48 ` [PATCH 1/2] drm/msm/dpu1: don't choke on disabling the writeback connector Dmitry Baryshkov @ 2024-07-09 18:42 ` Abhinav Kumar 0 siblings, 0 replies; 8+ messages in thread From: Abhinav Kumar @ 2024-07-09 18:42 UTC (permalink / raw) To: Dmitry Baryshkov, Rob Clark, Sean Paul, Marijn Suijten, David Airlie, Daniel Vetter, Jordan Crouse, Chandan Uddaraju, Rajesh Yadav, Sravanthi Kollukuduru, Archit Taneja Cc: linux-arm-msm, dri-devel, freedreno, linux-kernel, Jeykumar Sankaran, stable, Leonard Lausen On 7/9/2024 6:48 AM, Dmitry Baryshkov wrote: > In order to prevent any errors on connector being disabled, move the > state->crtc check upfront. This should fix the issues during suspend > when the writeback connector gets forcebly disabled. > > Fixes: 71174f362d67 ("drm/msm/dpu: move writeback's atomic_check to dpu_writeback.c") > Cc: stable@vger.kernel.org > Reported-by: Leonard Lausen <leonard@lausen.nl> > Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/57 > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c | 14 +++++++------- > 1 file changed, 7 insertions(+), 7 deletions(-) > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c > index 16f144cbc0c9..5c172bcf3419 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_writeback.c > @@ -39,6 +39,13 @@ static int dpu_wb_conn_atomic_check(struct drm_connector *connector, > > DPU_DEBUG("[atomic_check:%d]\n", connector->base.id); > > + crtc = conn_state->crtc; We are checking for !conn_state a few lines below but we are dereferencing conn_state here. This is bound to hit a smatch error and also does not look right. If conn_state will always be valid, we should drop that check too rather than checking it later. Coming to the issue itself, I tried checking the logs but it was not clear. During force disable, were we hitting below check and hence the connector was not getting disabled? else if (conn_state->connector->status != connector_status_connected) { DPU_ERROR("connector not connected %d\n", conn_state->connector->status); return -EINVAL; } I did not see this error log there, so can you pls explain where we were bailing out? The check seems valid to me. > + if (!crtc) > + return 0; > + > + if (!conn_state->writeback_job || !conn_state->writeback_job->fb) > + return 0; > + > if (!conn_state || !conn_state->connector) { > DPU_ERROR("invalid connector state\n"); > return -EINVAL; > @@ -47,13 +54,6 @@ static int dpu_wb_conn_atomic_check(struct drm_connector *connector, > return -EINVAL; > } > > - crtc = conn_state->crtc; > - if (!crtc) > - return 0; > - > - if (!conn_state->writeback_job || !conn_state->writeback_job->fb) > - return 0; > - > crtc_state = drm_atomic_get_crtc_state(state, crtc); > if (IS_ERR(crtc_state)) > return PTR_ERR(crtc_state); > ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 2/2] drm/msm/dpu: don't play tricks with debug macros 2024-07-09 13:48 [PATCH 0/2] drm/msm/dpu: two fixes targeting 6.11 Dmitry Baryshkov 2024-07-09 13:48 ` [PATCH 1/2] drm/msm/dpu1: don't choke on disabling the writeback connector Dmitry Baryshkov @ 2024-07-09 13:48 ` Dmitry Baryshkov 2024-07-09 19:38 ` Abhinav Kumar 1 sibling, 1 reply; 8+ messages in thread From: Dmitry Baryshkov @ 2024-07-09 13:48 UTC (permalink / raw) To: Rob Clark, Abhinav Kumar, Sean Paul, Marijn Suijten, David Airlie, Daniel Vetter, Jordan Crouse, Chandan Uddaraju, Rajesh Yadav, Sravanthi Kollukuduru, Archit Taneja Cc: linux-arm-msm, dri-devel, freedreno, linux-kernel, Jeykumar Sankaran DPU debugging macros need to be converted to a proper drm_debug_* macros, however this is a going an intrusive patch, not suitable for a fix. Wire DPU_DEBUG and DPU_DEBUG_DRIVER to always use DRM_DEBUG_DRIVER to make sure that DPU debugging messages always end up in the drm debug messages and are controlled via the usual drm.debug mask. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> --- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h index e2adc937ea63..935ff6fd172c 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h @@ -31,24 +31,14 @@ * @fmt: Pointer to format string */ #define DPU_DEBUG(fmt, ...) \ - do { \ - if (drm_debug_enabled(DRM_UT_KMS)) \ - DRM_DEBUG(fmt, ##__VA_ARGS__); \ - else \ - pr_debug(fmt, ##__VA_ARGS__); \ - } while (0) + DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__) /** * DPU_DEBUG_DRIVER - macro for hardware driver logging * @fmt: Pointer to format string */ #define DPU_DEBUG_DRIVER(fmt, ...) \ - do { \ - if (drm_debug_enabled(DRM_UT_DRIVER)) \ - DRM_ERROR(fmt, ##__VA_ARGS__); \ - else \ - pr_debug(fmt, ##__VA_ARGS__); \ - } while (0) + DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__) #define DPU_ERROR(fmt, ...) pr_err("[dpu error]" fmt, ##__VA_ARGS__) #define DPU_ERROR_RATELIMITED(fmt, ...) pr_err_ratelimited("[dpu error]" fmt, ##__VA_ARGS__) -- 2.39.2 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] drm/msm/dpu: don't play tricks with debug macros 2024-07-09 13:48 ` [PATCH 2/2] drm/msm/dpu: don't play tricks with debug macros Dmitry Baryshkov @ 2024-07-09 19:38 ` Abhinav Kumar 2024-07-10 7:40 ` Dmitry Baryshkov 0 siblings, 1 reply; 8+ messages in thread From: Abhinav Kumar @ 2024-07-09 19:38 UTC (permalink / raw) To: Dmitry Baryshkov, Rob Clark, Sean Paul, Marijn Suijten, David Airlie, Daniel Vetter, Jordan Crouse, Chandan Uddaraju, Rajesh Yadav, Sravanthi Kollukuduru, Archit Taneja Cc: linux-arm-msm, dri-devel, freedreno, linux-kernel, Jeykumar Sankaran On 7/9/2024 6:48 AM, Dmitry Baryshkov wrote: > DPU debugging macros need to be converted to a proper drm_debug_* > macros, however this is a going an intrusive patch, not suitable for a > fix. Wire DPU_DEBUG and DPU_DEBUG_DRIVER to always use DRM_DEBUG_DRIVER > to make sure that DPU debugging messages always end up in the drm debug > messages and are controlled via the usual drm.debug mask. > These macros have been deprecated, is this waht you meant by the conversion to proper drm_debug_*? /* NOTE: this is deprecated in favor of drm_dbg(NULL, ...). */ #define DRM_DEBUG_DRIVER(fmt, ...) \ __drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__) I think all that this macro was doing was to have appropriate DRM_UT_* macros enabled before calling the corresponding DRM_DEBUG_* macros. But I think what was incorrect here is for DPU_DEBUG, we could have used DRM_UT_CORE instead of DRM_UT_KMS. And DRM_DEBUG_DRIVER should have been used instead of DRM_ERROR. Was this causing the issue of the prints not getting enabled? > Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 14 ++------------ > 1 file changed, 2 insertions(+), 12 deletions(-) > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h > index e2adc937ea63..935ff6fd172c 100644 > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h > @@ -31,24 +31,14 @@ > * @fmt: Pointer to format string > */ > #define DPU_DEBUG(fmt, ...) \ > - do { \ > - if (drm_debug_enabled(DRM_UT_KMS)) \ > - DRM_DEBUG(fmt, ##__VA_ARGS__); \ > - else \ > - pr_debug(fmt, ##__VA_ARGS__); \ > - } while (0) > + DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__) > > /** > * DPU_DEBUG_DRIVER - macro for hardware driver logging > * @fmt: Pointer to format string > */ > #define DPU_DEBUG_DRIVER(fmt, ...) \ > - do { \ > - if (drm_debug_enabled(DRM_UT_DRIVER)) \ > - DRM_ERROR(fmt, ##__VA_ARGS__); \ > - else \ > - pr_debug(fmt, ##__VA_ARGS__); \ > - } while (0) > + DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__) > > #define DPU_ERROR(fmt, ...) pr_err("[dpu error]" fmt, ##__VA_ARGS__) > #define DPU_ERROR_RATELIMITED(fmt, ...) pr_err_ratelimited("[dpu error]" fmt, ##__VA_ARGS__) > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] drm/msm/dpu: don't play tricks with debug macros 2024-07-09 19:38 ` Abhinav Kumar @ 2024-07-10 7:40 ` Dmitry Baryshkov 2024-07-11 18:03 ` Abhinav Kumar 0 siblings, 1 reply; 8+ messages in thread From: Dmitry Baryshkov @ 2024-07-10 7:40 UTC (permalink / raw) To: Abhinav Kumar Cc: Rob Clark, Sean Paul, Marijn Suijten, David Airlie, Daniel Vetter, Jordan Crouse, Chandan Uddaraju, Rajesh Yadav, Sravanthi Kollukuduru, Archit Taneja, linux-arm-msm, dri-devel, freedreno, linux-kernel, Jeykumar Sankaran On Tue, 9 Jul 2024 at 22:39, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > > > On 7/9/2024 6:48 AM, Dmitry Baryshkov wrote: > > DPU debugging macros need to be converted to a proper drm_debug_* > > macros, however this is a going an intrusive patch, not suitable for a > > fix. Wire DPU_DEBUG and DPU_DEBUG_DRIVER to always use DRM_DEBUG_DRIVER > > to make sure that DPU debugging messages always end up in the drm debug > > messages and are controlled via the usual drm.debug mask. > > > > These macros have been deprecated, is this waht you meant by the > conversion to proper drm_debug_*? Yes. Drop the driver-specific wrappers where they don't make sense. Use sensible format strings in the cases where it actually does (like VIDENC or _PLANE) > > /* NOTE: this is deprecated in favor of drm_dbg(NULL, ...). */ > #define DRM_DEBUG_DRIVER(fmt, ...) \ > __drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__) > > I think all that this macro was doing was to have appropriate DRM_UT_* > macros enabled before calling the corresponding DRM_DEBUG_* macros. But > I think what was incorrect here is for DPU_DEBUG, we could have used > DRM_UT_CORE instead of DRM_UT_KMS. It pretty much tries to overplay the existing drm debugging mechanism by either sending the messages to the DRM channel or just using pr_debug. With DYNAMIC_DEBUG being disabled pr_debug is just an empty macro, so all the messages can end up in /dev/null. We should not be trying to be too smart, using standard DRM_DEBUG_DRIVER should be enough. This way all driver-related messages are controlled by drm.debug including or excluding the 0x02 bit. > > And DRM_DEBUG_DRIVER should have been used instead of DRM_ERROR. > > Was this causing the issue of the prints not getting enabled? I pretty much think so. > > > Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") > > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > --- > > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 14 ++------------ > > 1 file changed, 2 insertions(+), 12 deletions(-) > > > > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h > > index e2adc937ea63..935ff6fd172c 100644 > > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h > > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h > > @@ -31,24 +31,14 @@ > > * @fmt: Pointer to format string > > */ > > #define DPU_DEBUG(fmt, ...) \ > > - do { \ > > - if (drm_debug_enabled(DRM_UT_KMS)) \ > > - DRM_DEBUG(fmt, ##__VA_ARGS__); \ > > - else \ > > - pr_debug(fmt, ##__VA_ARGS__); \ > > - } while (0) > > + DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__) > > > > /** > > * DPU_DEBUG_DRIVER - macro for hardware driver logging > > * @fmt: Pointer to format string > > */ > > #define DPU_DEBUG_DRIVER(fmt, ...) \ > > - do { \ > > - if (drm_debug_enabled(DRM_UT_DRIVER)) \ > > - DRM_ERROR(fmt, ##__VA_ARGS__); \ > > - else \ > > - pr_debug(fmt, ##__VA_ARGS__); \ > > - } while (0) > > + DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__) > > > > #define DPU_ERROR(fmt, ...) pr_err("[dpu error]" fmt, ##__VA_ARGS__) > > #define DPU_ERROR_RATELIMITED(fmt, ...) pr_err_ratelimited("[dpu error]" fmt, ##__VA_ARGS__) > > -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] drm/msm/dpu: don't play tricks with debug macros 2024-07-10 7:40 ` Dmitry Baryshkov @ 2024-07-11 18:03 ` Abhinav Kumar 2024-07-13 15:38 ` Dmitry Baryshkov 0 siblings, 1 reply; 8+ messages in thread From: Abhinav Kumar @ 2024-07-11 18:03 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Rob Clark, Sean Paul, Marijn Suijten, David Airlie, Daniel Vetter, Jordan Crouse, Chandan Uddaraju, Rajesh Yadav, Sravanthi Kollukuduru, Archit Taneja, linux-arm-msm, dri-devel, freedreno, linux-kernel, Jeykumar Sankaran On 7/10/2024 12:40 AM, Dmitry Baryshkov wrote: > On Tue, 9 Jul 2024 at 22:39, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: >> >> >> >> On 7/9/2024 6:48 AM, Dmitry Baryshkov wrote: >>> DPU debugging macros need to be converted to a proper drm_debug_* >>> macros, however this is a going an intrusive patch, not suitable for a >>> fix. Wire DPU_DEBUG and DPU_DEBUG_DRIVER to always use DRM_DEBUG_DRIVER >>> to make sure that DPU debugging messages always end up in the drm debug >>> messages and are controlled via the usual drm.debug mask. >>> >> >> These macros have been deprecated, is this waht you meant by the >> conversion to proper drm_debug_*? > > Yes. Drop the driver-specific wrappers where they don't make sense. > Use sensible format strings in the cases where it actually does (like > VIDENC or _PLANE) > Ack but we need to not just drop the wrappers but drop the usage of these macros as well because it is documented that they are deprecated. So I assume you want to get this in and do that as a follow up change? >> >> /* NOTE: this is deprecated in favor of drm_dbg(NULL, ...). */ >> #define DRM_DEBUG_DRIVER(fmt, ...) \ >> __drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__) >> >> I think all that this macro was doing was to have appropriate DRM_UT_* >> macros enabled before calling the corresponding DRM_DEBUG_* macros. But >> I think what was incorrect here is for DPU_DEBUG, we could have used >> DRM_UT_CORE instead of DRM_UT_KMS. > > It pretty much tries to overplay the existing drm debugging mechanism > by either sending the messages to the DRM channel or just using > pr_debug. With DYNAMIC_DEBUG being disabled pr_debug is just an empty > macro, so all the messages can end up in /dev/null. We should not be > trying to be too smart, using standard DRM_DEBUG_DRIVER should be > enough. This way all driver-related messages are controlled by > drm.debug including or excluding the 0x02 bit. > > >> >> And DRM_DEBUG_DRIVER should have been used instead of DRM_ERROR. >> >> Was this causing the issue of the prints not getting enabled? > > I pretty much think so. > Alright, I am okay with the approach, just one minor suggestion, to keep the behavior intact, previously the code wanted DPU_DEBUG to be controlled by DRM_UT_KMS and DPU_DEBUG_DRIVER controlled by DRM_UT_DRIVER. Keeping that intact, we need to use DRM_DEBUG_KMS for DPU_DEBUG? >> >>> Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") >>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> >>> --- >>> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 14 ++------------ >>> 1 file changed, 2 insertions(+), 12 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h >>> index e2adc937ea63..935ff6fd172c 100644 >>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h >>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h >>> @@ -31,24 +31,14 @@ >>> * @fmt: Pointer to format string >>> */ >>> #define DPU_DEBUG(fmt, ...) \ >>> - do { \ >>> - if (drm_debug_enabled(DRM_UT_KMS)) \ >>> - DRM_DEBUG(fmt, ##__VA_ARGS__); \ >>> - else \ >>> - pr_debug(fmt, ##__VA_ARGS__); \ >>> - } while (0) >>> + DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__) >>> >>> /** >>> * DPU_DEBUG_DRIVER - macro for hardware driver logging >>> * @fmt: Pointer to format string >>> */ >>> #define DPU_DEBUG_DRIVER(fmt, ...) \ >>> - do { \ >>> - if (drm_debug_enabled(DRM_UT_DRIVER)) \ >>> - DRM_ERROR(fmt, ##__VA_ARGS__); \ >>> - else \ >>> - pr_debug(fmt, ##__VA_ARGS__); \ >>> - } while (0) >>> + DRM_DEBUG_DRIVER(fmt, ##__VA_ARGS__) >>> >>> #define DPU_ERROR(fmt, ...) pr_err("[dpu error]" fmt, ##__VA_ARGS__) >>> #define DPU_ERROR_RATELIMITED(fmt, ...) pr_err_ratelimited("[dpu error]" fmt, ##__VA_ARGS__) >>> > > > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] drm/msm/dpu: don't play tricks with debug macros 2024-07-11 18:03 ` Abhinav Kumar @ 2024-07-13 15:38 ` Dmitry Baryshkov 0 siblings, 0 replies; 8+ messages in thread From: Dmitry Baryshkov @ 2024-07-13 15:38 UTC (permalink / raw) To: Abhinav Kumar Cc: Rob Clark, Sean Paul, Marijn Suijten, David Airlie, Daniel Vetter, Jordan Crouse, Chandan Uddaraju, Rajesh Yadav, Sravanthi Kollukuduru, Archit Taneja, linux-arm-msm, dri-devel, freedreno, linux-kernel, Jeykumar Sankaran On Thu, Jul 11, 2024 at 11:03:15AM GMT, Abhinav Kumar wrote: > > > On 7/10/2024 12:40 AM, Dmitry Baryshkov wrote: > > On Tue, 9 Jul 2024 at 22:39, Abhinav Kumar <quic_abhinavk@quicinc.com> wrote: > > > > > > > > > > > > On 7/9/2024 6:48 AM, Dmitry Baryshkov wrote: > > > > DPU debugging macros need to be converted to a proper drm_debug_* > > > > macros, however this is a going an intrusive patch, not suitable for a > > > > fix. Wire DPU_DEBUG and DPU_DEBUG_DRIVER to always use DRM_DEBUG_DRIVER > > > > to make sure that DPU debugging messages always end up in the drm debug > > > > messages and are controlled via the usual drm.debug mask. > > > > > > > > > > These macros have been deprecated, is this waht you meant by the > > > conversion to proper drm_debug_*? > > > > Yes. Drop the driver-specific wrappers where they don't make sense. > > Use sensible format strings in the cases where it actually does (like > > VIDENC or _PLANE) > > > > Ack but we need to not just drop the wrappers but drop the usage of these > macros as well because it is documented that they are deprecated. > > So I assume you want to get this in and do that as a follow up change? Yes, somewhere in the long list of cleanups. I have a similar item against DP driver, which uses correct macros, > > > /* NOTE: this is deprecated in favor of drm_dbg(NULL, ...). */ > > > #define DRM_DEBUG_DRIVER(fmt, ...) \ > > > __drm_dbg(DRM_UT_DRIVER, fmt, ##__VA_ARGS__) > > > > > > I think all that this macro was doing was to have appropriate DRM_UT_* > > > macros enabled before calling the corresponding DRM_DEBUG_* macros. But > > > I think what was incorrect here is for DPU_DEBUG, we could have used > > > DRM_UT_CORE instead of DRM_UT_KMS. > > > > It pretty much tries to overplay the existing drm debugging mechanism > > by either sending the messages to the DRM channel or just using > > pr_debug. With DYNAMIC_DEBUG being disabled pr_debug is just an empty > > macro, so all the messages can end up in /dev/null. We should not be > > trying to be too smart, using standard DRM_DEBUG_DRIVER should be > > enough. This way all driver-related messages are controlled by > > drm.debug including or excluding the 0x02 bit. > > > > > > > > > > And DRM_DEBUG_DRIVER should have been used instead of DRM_ERROR. > > > > > > Was this causing the issue of the prints not getting enabled? > > > > I pretty much think so. > > > > Alright, I am okay with the approach, just one minor suggestion, to keep the > behavior intact, previously the code wanted DPU_DEBUG to be controlled by > DRM_UT_KMS and DPU_DEBUG_DRIVER controlled by DRM_UT_DRIVER. > > Keeping that intact, we need to use DRM_DEBUG_KMS for DPU_DEBUG? I might make that more explicit: I don't think that it is a good idea for a generic DPU_DEBUG macro to be tied to DRM_UT_KMS. We are reporting a debug message from driver, so by default it should go to the DRM_UT_DRIVER channel. While refactoring things we might end up with messages going to ATOMIC or KMS, but DRIVER should be the default. -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2024-07-13 15:38 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-07-09 13:48 [PATCH 0/2] drm/msm/dpu: two fixes targeting 6.11 Dmitry Baryshkov 2024-07-09 13:48 ` [PATCH 1/2] drm/msm/dpu1: don't choke on disabling the writeback connector Dmitry Baryshkov 2024-07-09 18:42 ` Abhinav Kumar 2024-07-09 13:48 ` [PATCH 2/2] drm/msm/dpu: don't play tricks with debug macros Dmitry Baryshkov 2024-07-09 19:38 ` Abhinav Kumar 2024-07-10 7:40 ` Dmitry Baryshkov 2024-07-11 18:03 ` Abhinav Kumar 2024-07-13 15:38 ` Dmitry Baryshkov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®