All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH 4/5] fixup! drm/xe/display: Implement display support
Date: Wed, 28 Jun 2023 02:36:45 +0300	[thread overview]
Message-ID: <87y1k4scj6.fsf@intel.com> (raw)
In-Reply-To: <mrvl5amrsemu2nqk3btjxskligvhk5hdpm7c3uzqww23pyo6w6@d5riz6lr2w4r>

On Tue, 27 Jun 2023, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
> On Tue, Jun 27, 2023 at 01:22:22PM +0300, Jani Nikula wrote:
>>Add raw_reg_* accessors and use them.
>>
>>Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>>---
>> .../drm/xe/compat-i915-headers/intel_uncore.h | 24 +++++++++++++++++++
>> drivers/gpu/drm/xe/display/ext/i915_irq.c     | 15 ++----------
>> 2 files changed, 26 insertions(+), 13 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h b/drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h
>>index 652654b5481d..a46dca558366 100644
>>--- a/drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h
>>+++ b/drivers/gpu/drm/xe/compat-i915-headers/intel_uncore.h
>>@@ -140,4 +140,28 @@ static inline void intel_uncore_write_notrace(struct intel_uncore *uncore,
>> 	xe_mmio_write32(__compat_uncore_to_gt(uncore), reg, val);
>> }
>>
>>+static inline void __iomem *intel_uncore_regs(struct intel_uncore *uncore)
>>+{
>>+	struct xe_device *xe = container_of(uncore, struct xe_device, uncore);
>>+
>>+	return xe_device_get_root_tile(xe)->mmio.regs;
>>+}
>>+
>>+/*
>>+ * The raw_reg_{read,write} macros are intended as a micro-optimization for
>>+ * interrupt handlers so that the pointer indirection on uncore->regs can
>>+ * be computed once (and presumably cached in a register) instead of generating
>>+ * extra load instructions for each MMIO access.
>>+ *
>>+ * Given that these macros are only intended for non-GSI interrupt registers
>>+ * (and the goal is to avoid extra instructions generated by the compiler),
>>+ * these macros do not account for uncore->gsi_offset.  Any caller that needs
>>+ * to use these macros on a GSI register is responsible for adding the
>>+ * appropriate GSI offset to the 'base' parameter.
>>+ */
>>+#define raw_reg_read(base, reg) \
>
> it's more a "map" rather than a "base". Currently it bypasses any
> forcewake, gsi and it's also hidden from tracing.
>
> As a micro-optimization I wonder if there are numbers anywhere to
> justify them.  As for the *move* being done here from
> xe/display/ext/i915_irq.c to xe/compat-i915-headers/intel_uncore.h, I'm
> ok with it. But why are we converting it to a macro rather than the
> inline function?  That would mean it also silently ignores any steering
> needed, adding to the list above of things ignored, since there is no
> type check anymore.

100% copy-paste from i915.

BR,
Jani.


>
> Lucas De Marchi
>
>>+	readl(base + i915_mmio_reg_offset(reg))
>>+#define raw_reg_write(base, reg, value) \
>>+	writel(value, base + i915_mmio_reg_offset(reg))
>>+
>> #endif /* __INTEL_UNCORE_H__ */
>>diff --git a/drivers/gpu/drm/xe/display/ext/i915_irq.c b/drivers/gpu/drm/xe/display/ext/i915_irq.c
>>index 6235ff9dec36..157403d1d8fe 100644
>>--- a/drivers/gpu/drm/xe/display/ext/i915_irq.c
>>+++ b/drivers/gpu/drm/xe/display/ext/i915_irq.c
>>@@ -35,8 +35,10 @@
>> #include <drm/drm_drv.h>
>>
>> #include "i915_drv.h"
>>+#include "i915_irq.h"
>> #include "i915_reg.h"
>> #include "icl_dsi_regs.h"
>>+#include "intel_clock_gating.h"
>> #include "intel_display_trace.h"
>> #include "intel_display_types.h"
>> #include "intel_dp_aux.h"
>>@@ -48,19 +50,6 @@
>> #include "intel_psr_regs.h"
>> #include "intel_uncore.h"
>>
>>-static u32 raw_reg_read(void __iomem *base, i915_reg_t reg)
>>-{
>>-	return readl(base + reg.reg);
>>-}
>>-
>>-static void raw_reg_write(void __iomem *base, i915_reg_t reg, u32 value)
>>-{
>>-	writel(value, base + reg.reg);
>>-}
>>-
>>-#include "i915_irq.h"
>>-#include "intel_clock_gating.h"
>>-
>> static void gen3_irq_reset(struct xe_device *dev_priv, i915_reg_t imr,
>> 		    i915_reg_t iir, i915_reg_t ier)
>> {
>>-- 
>>2.39.2
>>

-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2023-06-27 23:37 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-27 10:22 [Intel-xe] [PATCH 0/5] xe & i915 display integration, display irqs Jani Nikula
2023-06-27 10:22 ` [Intel-xe] [PATCH 1/5] drm/i915/uncore: add intel_uncore_regs() helper Jani Nikula
2023-06-27 10:22 ` [Intel-xe] [PATCH 2/5] fixup! drm/xe/display: Implement display support Jani Nikula
2023-06-27 10:22 ` [Intel-xe] [PATCH 3/5] " Jani Nikula
2023-06-27 10:22 ` [Intel-xe] [PATCH 4/5] " Jani Nikula
2023-06-27 16:03   ` Lucas De Marchi
2023-06-27 23:36     ` Jani Nikula [this message]
2023-06-28 14:40       ` Lucas De Marchi
2023-06-27 10:22 ` [Intel-xe] [PATCH 5/5] " Jani Nikula
2023-06-27 11:17 ` [Intel-xe] ✓ CI.Patch_applied: success for xe & i915 display integration, display irqs Patchwork
2023-06-27 11:17 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-06-27 11:18 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-06-27 11:22 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-06-27 11:22 ` [Intel-xe] ✓ CI.Hooks: " Patchwork
2023-06-27 11:24 ` [Intel-xe] ✗ CI.checksparse: warning " Patchwork
2023-06-27 15:51   ` Lucas De Marchi
2023-06-28 11:05     ` Knop, Ryszard
2023-06-29  8:07       ` Jani Nikula

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=87y1k4scj6.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.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.