All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	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 16:44:38 +0200	[thread overview]
Message-ID: <87v9pmovmx.fsf@intel.com> (raw)
In-Reply-To: <157848029770.2273.9590955422248556735@skylake-alporthouse-com>

On Wed, 08 Jan 2020, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> 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) ?

It *is* enough to do that, and that's essentially what the new macros
do, just with an extra helper macro in between.

> #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.

I was hoping to avoid having our own aliases and abstractions of
everything, and instead making the drm macros do what we want. I mean I
could've just ignored drm completely, add our own hacks and convert the
driver...

Sure, there's the boilerplate of dereferencing &i915->drm, but in many
places we already have struct drm_device * available too.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center

WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	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 16:44:38 +0200	[thread overview]
Message-ID: <87v9pmovmx.fsf@intel.com> (raw)
In-Reply-To: <157848029770.2273.9590955422248556735@skylake-alporthouse-com>

On Wed, 08 Jan 2020, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> 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) ?

It *is* enough to do that, and that's essentially what the new macros
do, just with an extra helper macro in between.

> #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.

I was hoping to avoid having our own aliases and abstractions of
everything, and instead making the drm macros do what we want. I mean I
could've just ignored drm completely, add our own hacks and convert the
driver...

Sure, there's the boilerplate of dereferencing &i915->drm, but in many
places we already have struct drm_device * available too.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
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: Jani Nikula <jani.nikula@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>,
	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 16:44:38 +0200	[thread overview]
Message-ID: <87v9pmovmx.fsf@intel.com> (raw)
In-Reply-To: <157848029770.2273.9590955422248556735@skylake-alporthouse-com>

On Wed, 08 Jan 2020, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> 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) ?

It *is* enough to do that, and that's essentially what the new macros
do, just with an extra helper macro in between.

> #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.

I was hoping to avoid having our own aliases and abstractions of
everything, and instead making the drm macros do what we want. I mean I
could've just ignored drm completely, add our own hacks and convert the
driver...

Sure, there's the boilerplate of dereferencing &i915->drm, but in many
places we already have struct drm_device * available too.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2020-01-08 14:44 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       ` [Intel-gfx] " Chris Wilson
2020-01-08 10:44         ` Chris Wilson
2020-01-08 10:44         ` Chris Wilson
2020-01-08 14:44         ` Jani Nikula [this message]
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=87v9pmovmx.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=airlied@linux.ie \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --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.