All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Wambui Karuga <wambui.karugax@gmail.com>,
	airlied@linux.ie, daniel@ffwll.ch, rodrigo.vivi@intel.com
Cc: intel-gfx@lists.freedesktop.org, seanpaul@chromium.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/5] drm/i915: convert to using the drm_dbg_kms() macro.
Date: Wed, 08 Jan 2020 10:44:57 +0000	[thread overview]
Message-ID: <157848029770.2273.9590955422248556735@skylake-alporthouse-com> (raw)
In-Reply-To: <8736cqs2uf.fsf@intel.com>

Quoting Jani Nikula (2020-01-08 09:40:40)
> On Wed, 08 Jan 2020, Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote:
> > Quoting Wambui Karuga (2020-01-07 17:13:29)
> >> Convert the use of the DRM_DEBUG_KMS() logging macro to the new struct
> >> drm_device based drm_dbg_kms() logging macro in i915/intel_pch.c.
> >> 
> >> Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
> >> ---
> >>  drivers/gpu/drm/i915/intel_pch.c | 46 +++++++++++++++++---------------
> >>  1 file changed, 24 insertions(+), 22 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/intel_pch.c b/drivers/gpu/drm/i915/intel_pch.c
> >> index 43b68b5fc562..4ed60e1f01db 100644
> >> --- a/drivers/gpu/drm/i915/intel_pch.c
> >> +++ b/drivers/gpu/drm/i915/intel_pch.c
> >> @@ -12,90 +12,91 @@ intel_pch_type(const struct drm_i915_private *dev_priv, unsigned short id)
> >>  {
> >>         switch (id) {
> >>         case INTEL_PCH_IBX_DEVICE_ID_TYPE:
> >> -               DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> >> +               drm_dbg_kms(&dev_priv->drm, "Found Ibex Peak PCH\n");
> >
> > Did we at some point consider i915_dbg_kms alias? That would just take
> > dev_priv (or i915, as it's called in newer code). It would shorten many
> > of the statements.
> >
> > i915_dbg_kms(dev_priv, ...) or i915_dbg_kms(i915, ...)
> 
> I'd rather use the common drm logging macros. I thought about adding
> i915 specific ones only if the drm device specific logging macros
> weren't going to be merged.

Why do they even exist? Why isn't it enough to do
#define drm_info(drm, fmt, ...) dev_info(&(drm)->dev, fmt, ##__VA_ARGS) ?
#define i915_info(i915, fmt, ...) drm_info(&(i915)->drm, fmt, ##__VA_ARGS)

The lea for &i915->drm.dev is the same as the mov, so we shave off an
unnecessary wrapper.
-Chris

WARNING: multiple messages have this Message-ID (diff)
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Wambui Karuga <wambui.karugax@gmail.com>,
	airlied@linux.ie, daniel@ffwll.ch, rodrigo.vivi@intel.com
Cc: intel-gfx@lists.freedesktop.org, seanpaul@chromium.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/5] drm/i915: convert to using the drm_dbg_kms() macro.
Date: Wed, 08 Jan 2020 10:44:57 +0000	[thread overview]
Message-ID: <157848029770.2273.9590955422248556735@skylake-alporthouse-com> (raw)
In-Reply-To: <8736cqs2uf.fsf@intel.com>

Quoting Jani Nikula (2020-01-08 09:40:40)
> On Wed, 08 Jan 2020, Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote:
> > Quoting Wambui Karuga (2020-01-07 17:13:29)
> >> Convert the use of the DRM_DEBUG_KMS() logging macro to the new struct
> >> drm_device based drm_dbg_kms() logging macro in i915/intel_pch.c.
> >> 
> >> Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
> >> ---
> >>  drivers/gpu/drm/i915/intel_pch.c | 46 +++++++++++++++++---------------
> >>  1 file changed, 24 insertions(+), 22 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/intel_pch.c b/drivers/gpu/drm/i915/intel_pch.c
> >> index 43b68b5fc562..4ed60e1f01db 100644
> >> --- a/drivers/gpu/drm/i915/intel_pch.c
> >> +++ b/drivers/gpu/drm/i915/intel_pch.c
> >> @@ -12,90 +12,91 @@ intel_pch_type(const struct drm_i915_private *dev_priv, unsigned short id)
> >>  {
> >>         switch (id) {
> >>         case INTEL_PCH_IBX_DEVICE_ID_TYPE:
> >> -               DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> >> +               drm_dbg_kms(&dev_priv->drm, "Found Ibex Peak PCH\n");
> >
> > Did we at some point consider i915_dbg_kms alias? That would just take
> > dev_priv (or i915, as it's called in newer code). It would shorten many
> > of the statements.
> >
> > i915_dbg_kms(dev_priv, ...) or i915_dbg_kms(i915, ...)
> 
> I'd rather use the common drm logging macros. I thought about adding
> i915 specific ones only if the drm device specific logging macros
> weren't going to be merged.

Why do they even exist? Why isn't it enough to do
#define drm_info(drm, fmt, ...) dev_info(&(drm)->dev, fmt, ##__VA_ARGS) ?
#define i915_info(i915, fmt, ...) drm_info(&(i915)->drm, fmt, ##__VA_ARGS)

The lea for &i915->drm.dev is the same as the mov, so we shave off an
unnecessary wrapper.
-Chris
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Wambui Karuga <wambui.karugax@gmail.com>,
	airlied@linux.ie, daniel@ffwll.ch, rodrigo.vivi@intel.com
Cc: intel-gfx@lists.freedesktop.org, seanpaul@chromium.org,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 1/5] drm/i915: convert to using the drm_dbg_kms() macro.
Date: Wed, 08 Jan 2020 10:44:57 +0000	[thread overview]
Message-ID: <157848029770.2273.9590955422248556735@skylake-alporthouse-com> (raw)
In-Reply-To: <8736cqs2uf.fsf@intel.com>

Quoting Jani Nikula (2020-01-08 09:40:40)
> On Wed, 08 Jan 2020, Joonas Lahtinen <joonas.lahtinen@linux.intel.com> wrote:
> > Quoting Wambui Karuga (2020-01-07 17:13:29)
> >> Convert the use of the DRM_DEBUG_KMS() logging macro to the new struct
> >> drm_device based drm_dbg_kms() logging macro in i915/intel_pch.c.
> >> 
> >> Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
> >> ---
> >>  drivers/gpu/drm/i915/intel_pch.c | 46 +++++++++++++++++---------------
> >>  1 file changed, 24 insertions(+), 22 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/i915/intel_pch.c b/drivers/gpu/drm/i915/intel_pch.c
> >> index 43b68b5fc562..4ed60e1f01db 100644
> >> --- a/drivers/gpu/drm/i915/intel_pch.c
> >> +++ b/drivers/gpu/drm/i915/intel_pch.c
> >> @@ -12,90 +12,91 @@ intel_pch_type(const struct drm_i915_private *dev_priv, unsigned short id)
> >>  {
> >>         switch (id) {
> >>         case INTEL_PCH_IBX_DEVICE_ID_TYPE:
> >> -               DRM_DEBUG_KMS("Found Ibex Peak PCH\n");
> >> +               drm_dbg_kms(&dev_priv->drm, "Found Ibex Peak PCH\n");
> >
> > Did we at some point consider i915_dbg_kms alias? That would just take
> > dev_priv (or i915, as it's called in newer code). It would shorten many
> > of the statements.
> >
> > i915_dbg_kms(dev_priv, ...) or i915_dbg_kms(i915, ...)
> 
> I'd rather use the common drm logging macros. I thought about adding
> i915 specific ones only if the drm device specific logging macros
> weren't going to be merged.

Why do they even exist? Why isn't it enough to do
#define drm_info(drm, fmt, ...) dev_info(&(drm)->dev, fmt, ##__VA_ARGS) ?
#define i915_info(i915, fmt, ...) drm_info(&(i915)->drm, fmt, ##__VA_ARGS)

The lea for &i915->drm.dev is the same as the mov, so we shave off an
unnecessary wrapper.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-01-08 10:45 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-07 15:13 [PATCH 0/5] drm/i915: conversion to new drm logging macros Wambui Karuga
2020-01-07 15:13 ` [Intel-gfx] " Wambui Karuga
2020-01-07 15:13 ` Wambui Karuga
2020-01-07 15:13 ` [PATCH 1/5] drm/i915: convert to using the drm_dbg_kms() macro Wambui Karuga
2020-01-07 15:13   ` [Intel-gfx] " Wambui Karuga
2020-01-07 15:13   ` Wambui Karuga
2020-01-08  8:26   ` Joonas Lahtinen
2020-01-08  8:26     ` [Intel-gfx] " Joonas Lahtinen
2020-01-08  8:26     ` Joonas Lahtinen
2020-01-08  9:40     ` Jani Nikula
2020-01-08  9:40       ` [Intel-gfx] " Jani Nikula
2020-01-08  9:40       ` Jani Nikula
2020-01-08 10:44       ` Chris Wilson [this message]
2020-01-08 10:44         ` [Intel-gfx] " Chris Wilson
2020-01-08 10:44         ` Chris Wilson
2020-01-08 14:44         ` Jani Nikula
2020-01-08 14:44           ` Jani Nikula
2020-01-08 14:44           ` Jani Nikula
2020-01-08 14:53           ` Chris Wilson
2020-01-08 14:53             ` Chris Wilson
2020-01-08 14:53             ` Chris Wilson
2020-01-07 15:13 ` [PATCH 2/5] drm/i915: use new struct drm_device logging macros Wambui Karuga
2020-01-07 15:13   ` [Intel-gfx] " Wambui Karuga
2020-01-07 15:13   ` Wambui Karuga
2020-01-07 15:13 ` [PATCH 3/5] drm/i915: use new struct drm_device based " Wambui Karuga
2020-01-07 15:13   ` [Intel-gfx] " Wambui Karuga
2020-01-07 15:13   ` Wambui Karuga
2020-01-07 15:13 ` [PATCH 4/5] drm/i915: convert to using new struct drm_device " Wambui Karuga
2020-01-07 15:13   ` [Intel-gfx] " Wambui Karuga
2020-01-07 15:13   ` Wambui Karuga
2020-01-07 15:13 ` [PATCH 5/5] drm/i915: use new struct drm_device based macros Wambui Karuga
2020-01-07 15:13   ` [Intel-gfx] " Wambui Karuga
2020-01-07 15:13   ` Wambui Karuga
2020-01-07 19:08 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: conversion to new drm logging macros Patchwork
2020-01-07 20:07 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-01-08  5:47 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-01-10 14:17 ` [PATCH 0/5] " Jani Nikula
2020-01-10 14:17   ` [Intel-gfx] " Jani Nikula
2020-01-10 14:17   ` Jani Nikula
2020-01-10 17:44   ` Wambui Karuga
2020-01-10 17:44     ` [Intel-gfx] " Wambui Karuga
2020-01-10 17:44     ` Wambui Karuga

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=157848029770.2273.9590955422248556735@skylake-alporthouse-com \
    --to=chris@chris-wilson.co.uk \
    --cc=airlied@linux.ie \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=seanpaul@chromium.org \
    --cc=wambui.karugax@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.