[RESEND PATCH v6 01/14] drm/mipi_dbi: Convert pr_debug calls to DRM_DEBUG_DRIVER

[jim.cromie at gmail.com]

On Wed, Jul 21, 2021 at 1:55 PM Sean Paul <sean at poorly.run> wrote:
>
> From: Sean Paul <seanpaul at chromium.org>
>
> Use the drm logging helpers to output these messages to ensure they'll
> be included by the drm tracefs instance.
>
> Signed-off-by: Sean Paul <seanpaul at chromium.org>
> Link: https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-2-sean@poorly.run #v5
>
> Changes in v5:
> -Added to the set
> Changes in v6:
> -None
> ---
>  drivers/gpu/drm/drm_mipi_dbi.c | 8 ++------
>  1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dbi.c b/drivers/gpu/drm/drm_mipi_dbi.c
> index 10b4e59384ae..2f661d7ff774 100644
> --- a/drivers/gpu/drm/drm_mipi_dbi.c
> +++ b/drivers/gpu/drm/drm_mipi_dbi.c
> @@ -763,9 +763,7 @@ static int mipi_dbi_spi1e_transfer(struct mipi_dbi *dbi, int dc,
>         int i, ret;
>         u8 *dst;
>
> -       if (drm_debug_enabled(DRM_UT_DRIVER))
> -               pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
> -                        __func__, dc, max_chunk);
> +       DRM_DEBUG_DRIVER("dc=%d, max_chunk=%zu, transfers:\n", dc, max_chunk);
>
>         tr.speed_hz = mipi_dbi_spi_cmd_max_speed(spi, len);
>         spi_message_init_with_transfers(&m, &tr, 1);
> @@ -887,9 +885,7 @@ static int mipi_dbi_spi1_transfer(struct mipi_dbi *dbi, int dc,
>         max_chunk = dbi->tx_buf9_len;
>         dst16 = dbi->tx_buf9;
>
> -       if (drm_debug_enabled(DRM_UT_DRIVER))
> -               pr_debug("[drm:%s] dc=%d, max_chunk=%zu, transfers:\n",
> -                        __func__, dc, max_chunk);
> +       DRM_DEBUG_DRIVER("dc=%d, max_chunk=%zu, transfers:\n", dc, max_chunk);
>

This makes sense generically.

I note you have dropped the "[drm:__func__]" prefix.

dyndbg can provide that if user wants (+pf), so dropping from msg-body
is brevity.

but this means that dyndbg cannot select on it using
   echo "format ^[drm:funcname] +p" > control

thats ok, since "function funcname" would work,
but theres an element of moving target.

obviously, w/o dyndbg, all this is different, putting more balls in the air.