Message ID | 20240405092907.2334007-1-jani.nikula@intel.com (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
Series | drm/msm: convert all pixel format logging to use %p4cc | expand |
On Fri, Apr 05, 2024 at 12:29:07PM +0300, Jani Nikula wrote: > Logging u32 pixel formats using %4.4s format string with a pointer to > the u32 is somewhat questionable, as well as dependent on byte > order. There's a kernel extension format specifier %p4cc to format 4cc > codes. Use it across the board in msm for pixel format logging. > > This should also fix the reported build warning: > > include/drm/drm_print.h:536:35: warning: '%4.4s' directive argument is > null [-Wformat-overflow=] > > Reported-by: Aishwarya TCV <aishwarya.tcv@arm.com> > Closes: https://lore.kernel.org/r/2ac758ce-a196-4e89-a397-488ba31014c4@arm.com > Signed-off-by: Jani Nikula <jani.nikula@intel.com> > > --- > > Tip: 'git show --color-words -w' might be the easiest way to review. > --- > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 +++---- > .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 2 +- > drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 4 ++-- > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 24 +++++++++---------- > drivers/gpu/drm/msm/msm_fb.c | 10 ++++---- > 5 files changed, 24 insertions(+), 24 deletions(-) Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
On Fri, 05 Apr 2024, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > On Fri, Apr 05, 2024 at 12:29:07PM +0300, Jani Nikula wrote: >> Logging u32 pixel formats using %4.4s format string with a pointer to >> the u32 is somewhat questionable, as well as dependent on byte >> order. There's a kernel extension format specifier %p4cc to format 4cc >> codes. Use it across the board in msm for pixel format logging. >> >> This should also fix the reported build warning: >> >> include/drm/drm_print.h:536:35: warning: '%4.4s' directive argument is >> null [-Wformat-overflow=] >> >> Reported-by: Aishwarya TCV <aishwarya.tcv@arm.com> >> Closes: https://lore.kernel.org/r/2ac758ce-a196-4e89-a397-488ba31014c4@arm.com >> Signed-off-by: Jani Nikula <jani.nikula@intel.com> >> >> --- >> >> Tip: 'git show --color-words -w' might be the easiest way to review. >> --- >> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 +++---- >> .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 2 +- >> drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 4 ++-- >> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 24 +++++++++---------- >> drivers/gpu/drm/msm/msm_fb.c | 10 ++++---- >> 5 files changed, 24 insertions(+), 24 deletions(-) > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Thanks! Do you take this via the msm tree? BR, Jani.
On Mon, 8 Apr 2024 at 11:09, Jani Nikula <jani.nikula@intel.com> wrote: > > On Fri, 05 Apr 2024, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > > On Fri, Apr 05, 2024 at 12:29:07PM +0300, Jani Nikula wrote: > >> Logging u32 pixel formats using %4.4s format string with a pointer to > >> the u32 is somewhat questionable, as well as dependent on byte > >> order. There's a kernel extension format specifier %p4cc to format 4cc > >> codes. Use it across the board in msm for pixel format logging. > >> > >> This should also fix the reported build warning: > >> > >> include/drm/drm_print.h:536:35: warning: '%4.4s' directive argument is > >> null [-Wformat-overflow=] > >> > >> Reported-by: Aishwarya TCV <aishwarya.tcv@arm.com> > >> Closes: https://lore.kernel.org/r/2ac758ce-a196-4e89-a397-488ba31014c4@arm.com > >> Signed-off-by: Jani Nikula <jani.nikula@intel.com> > >> > >> --- > >> > >> Tip: 'git show --color-words -w' might be the easiest way to review. > >> --- > >> drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 +++---- > >> .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 2 +- > >> drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 4 ++-- > >> drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 24 +++++++++---------- > >> drivers/gpu/drm/msm/msm_fb.c | 10 ++++---- > >> 5 files changed, 24 insertions(+), 24 deletions(-) > > > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > Thanks! Do you take this via the msm tree? Yes, I will
On Mon, 08 Apr 2024, Dmitry Baryshkov <dmitry.baryshkov@linaro.org> wrote: > On Mon, 8 Apr 2024 at 11:09, Jani Nikula <jani.nikula@intel.com> wrote: >> Thanks! Do you take this via the msm tree? > > Yes, I will Forgot to mention, there's a Tested-by at [1]. Tested-by: Aishwarya TCV <aishwarya.tcv@arm.com> [1] https://lore.kernel.org/r/157e69d4-850f-40d2-84ff-d25dd2c122b4@arm.com
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c index 9a14d2232e4a..aa1e68379d9f 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c @@ -2203,8 +2203,8 @@ void dpu_encoder_helper_phys_setup_cdm(struct dpu_encoder_phys *phys_enc, return; if (!DPU_FORMAT_IS_YUV(dpu_fmt)) { - DPU_DEBUG("[enc:%d] cdm_disable fmt:%x\n", DRMID(phys_enc->parent), - dpu_fmt->base.pixel_format); + DPU_DEBUG("[enc:%d] cdm_disable fmt:%p4cc\n", DRMID(phys_enc->parent), + &dpu_fmt->base.pixel_format); if (hw_cdm->ops.bind_pingpong_blk) hw_cdm->ops.bind_pingpong_blk(hw_cdm, PINGPONG_NONE); @@ -2244,9 +2244,9 @@ void dpu_encoder_helper_phys_setup_cdm(struct dpu_encoder_phys *phys_enc, break; } - DPU_DEBUG("[enc:%d] cdm_enable:%d,%d,%X,%d,%d,%d,%d]\n", + DPU_DEBUG("[enc:%d] cdm_enable:%d,%d,%p4cc,%d,%d,%d,%d]\n", DRMID(phys_enc->parent), cdm_cfg->output_width, - cdm_cfg->output_height, cdm_cfg->output_fmt->base.pixel_format, + cdm_cfg->output_height, &cdm_cfg->output_fmt->base.pixel_format, cdm_cfg->output_type, cdm_cfg->output_bit_depth, cdm_cfg->h_cdwn_type, cdm_cfg->v_cdwn_type); diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c index 1924a2b28e53..9dbb8ddcddec 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_wb.c @@ -580,7 +580,7 @@ static void dpu_encoder_phys_wb_prepare_wb_job(struct dpu_encoder_phys *phys_enc format->pixel_format, job->fb->modifier); if (!wb_cfg->dest.format) { /* this error should be detected during atomic_check */ - DPU_ERROR("failed to get format %x\n", format->pixel_format); + DPU_ERROR("failed to get format %p4cc\n", &format->pixel_format); return; } diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c index e366ab134249..95e6e58b1a21 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c @@ -647,8 +647,8 @@ static int _dpu_format_get_plane_sizes_ubwc( color = _dpu_format_get_media_color_ubwc(fmt); if (color < 0) { - DRM_ERROR("UBWC format not supported for fmt: %4.4s\n", - (char *)&fmt->base.pixel_format); + DRM_ERROR("UBWC format not supported for fmt: %p4cc\n", + &fmt->base.pixel_format); return -EINVAL; } diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c index ff975ad51145..ff4ac4daaeca 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c @@ -234,9 +234,9 @@ static int _dpu_plane_calc_fill_level(struct drm_plane *plane, } } - DPU_DEBUG_PLANE(pdpu, "pnum:%d fmt: %4.4s w:%u fl:%u\n", + DPU_DEBUG_PLANE(pdpu, "pnum:%d fmt: %p4cc w:%u fl:%u\n", pipe->sspp->idx - SSPP_VIG0, - (char *)&fmt->base.pixel_format, + &fmt->base.pixel_format, src_width, total_fl); return total_fl; @@ -287,9 +287,9 @@ static void _dpu_plane_set_qos_lut(struct drm_plane *plane, (fmt) ? fmt->base.pixel_format : 0, pdpu->is_rt_pipe, total_fl, cfg.creq_lut, lut_usage); - DPU_DEBUG_PLANE(pdpu, "pnum:%d fmt: %4.4s rt:%d fl:%u lut:0x%llx\n", + DPU_DEBUG_PLANE(pdpu, "pnum:%d fmt: %p4cc rt:%d fl:%u lut:0x%llx\n", pdpu->pipe - SSPP_VIG0, - fmt ? (char *)&fmt->base.pixel_format : NULL, + fmt ? &fmt->base.pixel_format : NULL, pdpu->is_rt_pipe, total_fl, cfg.creq_lut); trace_dpu_perf_set_danger_luts(pdpu->pipe - SSPP_VIG0, @@ -298,12 +298,12 @@ static void _dpu_plane_set_qos_lut(struct drm_plane *plane, cfg.danger_lut, cfg.safe_lut); - DPU_DEBUG_PLANE(pdpu, "pnum:%d fmt: %4.4s mode:%d luts[0x%x, 0x%x]\n", - pdpu->pipe - SSPP_VIG0, - fmt ? (char *)&fmt->base.pixel_format : NULL, - fmt ? fmt->fetch_mode : -1, - cfg.danger_lut, - cfg.safe_lut); + DPU_DEBUG_PLANE(pdpu, "pnum:%d fmt: %p4cc mode:%d luts[0x%x, 0x%x]\n", + pdpu->pipe - SSPP_VIG0, + fmt ? &fmt->base.pixel_format : NULL, + fmt ? fmt->fetch_mode : -1, + cfg.danger_lut, + cfg.safe_lut); pipe->sspp->ops.setup_qos_lut(pipe->sspp, &cfg); } @@ -1118,9 +1118,9 @@ static void dpu_plane_sspp_atomic_update(struct drm_plane *plane) pdpu->is_rt_pipe = is_rt_pipe; DPU_DEBUG_PLANE(pdpu, "FB[%u] " DRM_RECT_FP_FMT "->crtc%u " DRM_RECT_FMT - ", %4.4s ubwc %d\n", fb->base.id, DRM_RECT_FP_ARG(&state->src), + ", %p4cc ubwc %d\n", fb->base.id, DRM_RECT_FP_ARG(&state->src), crtc->base.id, DRM_RECT_ARG(&state->dst), - (char *)&fmt->base.pixel_format, DPU_FORMAT_IS_UBWC(fmt)); + &fmt->base.pixel_format, DPU_FORMAT_IS_UBWC(fmt)); dpu_plane_sspp_update_pipe(plane, pipe, pipe_cfg, fmt, drm_mode_vrefresh(&crtc->mode), diff --git a/drivers/gpu/drm/msm/msm_fb.c b/drivers/gpu/drm/msm/msm_fb.c index e3f61c39df69..2cccf2ece7ac 100644 --- a/drivers/gpu/drm/msm/msm_fb.c +++ b/drivers/gpu/drm/msm/msm_fb.c @@ -176,16 +176,16 @@ static struct drm_framebuffer *msm_framebuffer_init(struct drm_device *dev, const struct msm_format *format; int ret, i, n; - drm_dbg_state(dev, "create framebuffer: mode_cmd=%p (%dx%d@%4.4s)", - mode_cmd, mode_cmd->width, mode_cmd->height, - (char *)&mode_cmd->pixel_format); + drm_dbg_state(dev, "create framebuffer: mode_cmd=%p (%dx%d@%p4cc)", + mode_cmd, mode_cmd->width, mode_cmd->height, + &mode_cmd->pixel_format); n = info->num_planes; format = kms->funcs->get_format(kms, mode_cmd->pixel_format, mode_cmd->modifier[0]); if (!format) { - DRM_DEV_ERROR(dev->dev, "unsupported pixel format: %4.4s\n", - (char *)&mode_cmd->pixel_format); + DRM_DEV_ERROR(dev->dev, "unsupported pixel format: %p4cc\n", + &mode_cmd->pixel_format); ret = -EINVAL; goto fail; }
Logging u32 pixel formats using %4.4s format string with a pointer to the u32 is somewhat questionable, as well as dependent on byte order. There's a kernel extension format specifier %p4cc to format 4cc codes. Use it across the board in msm for pixel format logging. This should also fix the reported build warning: include/drm/drm_print.h:536:35: warning: '%4.4s' directive argument is null [-Wformat-overflow=] Reported-by: Aishwarya TCV <aishwarya.tcv@arm.com> Closes: https://lore.kernel.org/r/2ac758ce-a196-4e89-a397-488ba31014c4@arm.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> --- Tip: 'git show --color-words -w' might be the easiest way to review. --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 +++---- .../drm/msm/disp/dpu1/dpu_encoder_phys_wb.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 4 ++-- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 24 +++++++++---------- drivers/gpu/drm/msm/msm_fb.c | 10 ++++---- 5 files changed, 24 insertions(+), 24 deletions(-)