From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 95C32C282DD for ; Wed, 8 Jan 2020 14:44:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 70F2B20705 for ; Wed, 8 Jan 2020 14:44:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728483AbgAHOoo (ORCPT ); Wed, 8 Jan 2020 09:44:44 -0500 Received: from mga14.intel.com ([192.55.52.115]:10951 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726697AbgAHOoo (ORCPT ); Wed, 8 Jan 2020 09:44:44 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2020 06:44:44 -0800 X-IronPort-AV: E=Sophos;i="5.69,410,1571727600"; d="scan'208";a="215970151" Received: from jnikula-mobl3.fi.intel.com (HELO localhost) ([10.237.66.161]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2020 06:44:41 -0800 From: Jani Nikula To: Chris Wilson , Joonas Lahtinen , Wambui Karuga , 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. In-Reply-To: <157848029770.2273.9590955422248556735@skylake-alporthouse-com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <157847199686.4725.87481257304852182@jlahtine-desk.ger.corp.intel.com> <8736cqs2uf.fsf@intel.com> <157848029770.2273.9590955422248556735@skylake-alporthouse-com> Date: Wed, 08 Jan 2020 16:44:38 +0200 Message-ID: <87v9pmovmx.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 08 Jan 2020, Chris Wilson wrote: > Quoting Jani Nikula (2020-01-08 09:40:40) >> On Wed, 08 Jan 2020, Joonas Lahtinen 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 >> >> --- >> >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7397DC33CA2 for ; Wed, 8 Jan 2020 14:44:46 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4E3ED20705 for ; Wed, 8 Jan 2020 14:44:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4E3ED20705 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 961306E313; Wed, 8 Jan 2020 14:44:45 +0000 (UTC) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id 83CF06E313; Wed, 8 Jan 2020 14:44:44 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2020 06:44:44 -0800 X-IronPort-AV: E=Sophos;i="5.69,410,1571727600"; d="scan'208";a="215970151" Received: from jnikula-mobl3.fi.intel.com (HELO localhost) ([10.237.66.161]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2020 06:44:41 -0800 From: Jani Nikula To: Chris Wilson , Joonas Lahtinen , Wambui Karuga , airlied@linux.ie, daniel@ffwll.ch, rodrigo.vivi@intel.com Subject: Re: [Intel-gfx] [PATCH 1/5] drm/i915: convert to using the drm_dbg_kms() macro. In-Reply-To: <157848029770.2273.9590955422248556735@skylake-alporthouse-com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <157847199686.4725.87481257304852182@jlahtine-desk.ger.corp.intel.com> <8736cqs2uf.fsf@intel.com> <157848029770.2273.9590955422248556735@skylake-alporthouse-com> Date: Wed, 08 Jan 2020 16:44:38 +0200 Message-ID: <87v9pmovmx.fsf@intel.com> MIME-Version: 1.0 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx@lists.freedesktop.org, seanpaul@chromium.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, 08 Jan 2020, Chris Wilson wrote: > Quoting Jani Nikula (2020-01-08 09:40:40) >> On Wed, 08 Jan 2020, Joonas Lahtinen 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 >> >> --- >> >> 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C50EC282DD for ; Wed, 8 Jan 2020 14:44:51 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 064A42070E for ; Wed, 8 Jan 2020 14:44:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 064A42070E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C9B326E314; Wed, 8 Jan 2020 14:44:45 +0000 (UTC) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTPS id 83CF06E313; Wed, 8 Jan 2020 14:44:44 +0000 (UTC) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2020 06:44:44 -0800 X-IronPort-AV: E=Sophos;i="5.69,410,1571727600"; d="scan'208";a="215970151" Received: from jnikula-mobl3.fi.intel.com (HELO localhost) ([10.237.66.161]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2020 06:44:41 -0800 From: Jani Nikula To: Chris Wilson , Joonas Lahtinen , Wambui Karuga , airlied@linux.ie, daniel@ffwll.ch, rodrigo.vivi@intel.com In-Reply-To: <157848029770.2273.9590955422248556735@skylake-alporthouse-com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <157847199686.4725.87481257304852182@jlahtine-desk.ger.corp.intel.com> <8736cqs2uf.fsf@intel.com> <157848029770.2273.9590955422248556735@skylake-alporthouse-com> Date: Wed, 08 Jan 2020 16:44:38 +0200 Message-ID: <87v9pmovmx.fsf@intel.com> MIME-Version: 1.0 Subject: Re: [Intel-gfx] [PATCH 1/5] drm/i915: convert to using the drm_dbg_kms() macro. X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx@lists.freedesktop.org, seanpaul@chromium.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, 08 Jan 2020, Chris Wilson wrote: > Quoting Jani Nikula (2020-01-08 09:40:40) >> On Wed, 08 Jan 2020, Joonas Lahtinen 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 >> >> --- >> >> 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