Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
To: Jani Nikula <jani.nikula@intel.com>, intel-gfx@lists.freedesktop.org
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Subject: Re: [RFC 1/2] drm/i915: add display uncore helpers
Date: Tue, 29 Oct 2019 14:20:49 -0700	[thread overview]
Message-ID: <9bbc3ef0-ecb3-eb97-ccf8-7dbeedaff259@intel.com> (raw)
In-Reply-To: <20191029105156.21658-1-jani.nikula@intel.com>



On 10/29/19 3:51 AM, Jani Nikula wrote:
> Add convenience helpers for the most common uncore operations with
> struct drm_i915_private * as context rather than struct intel_uncore *.
> 
> The goal is to replace all instances of I915_READ(),
> I915_POSTING_READ(), and I915_WRITE() in display/ with these, to finally
> be able to get rid of the implicit dev_priv local parameter use.
> 
> The idea is that any non-u32 reads or writes are special enough that
> they can use the intel_uncore_* functions directly.
> 
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> 
> ---
> 
> Let the name bikeshedding commence! Some options are:
> 
> - intel_de_read, intel_de_write (this patch, de for display engine)

+1 for this. it also matches the intel_de_wait_for_register/set/clear 
macros, which we could probably move in this file as well.

Daniele

> - intel_display_read, intel_display_write (too long I think)
> - intel_read, intel_write
> - i915_read, i915_write
> - display_read, display_write
> - ?
> 
> Here's a draft cocci patch that could be used on display/ subdir, en
> masse:
> 
> @@
> expression REG, OFFSET;
> @@
> - I915_READ(REG)
> + intel_de_read(dev_priv, REG)
> 
> @@
> expression REG, OFFSET;
> @@
> - I915_POSTING_READ(REG)
> + intel_de_posting_read(dev_priv, REG)
> 
> @@
> expression REG, OFFSET;
> @@
> - I915_WRITE(REG, OFFSET)
> + intel_de_write(dev_priv, REG, OFFSET)
> 
> Conveniently, we *know* dev_priv is everywhere the change is needed.
> 
> This enables us to make the s/dev_priv/i915/ rename on top. We also need
> to discuss whether it's better to separate the steps to two (even if in
> the same patch series) or if it's better to add the dev_priv parameter
> as i915 directly.
> ---
>   .../drm/i915/display/intel_display_uncore.h   | 36 +++++++++++++++++++
>   1 file changed, 36 insertions(+)
>   create mode 100644 drivers/gpu/drm/i915/display/intel_display_uncore.h
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_uncore.h b/drivers/gpu/drm/i915/display/intel_display_uncore.h
> new file mode 100644
> index 000000000000..e6c8c56fb0f9
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_display_uncore.h
> @@ -0,0 +1,36 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2019 Intel Corporation
> + */
> +
> +#ifndef __INTEL_DISPLAY_UNCORE_H__
> +#define __INTEL_DISPLAY_UNCORE_H__
> +
> +#include "i915_drv.h"
> +#include "i915_reg.h"
> +#include "intel_uncore.h"
> +
> +static inline u32 intel_de_read(struct drm_i915_private *i915, i915_reg_t reg)
> +{
> +	return intel_uncore_read(&i915->uncore, reg);
> +}
> +
> +static inline void intel_de_posting_read(struct drm_i915_private *i915,
> +					 i915_reg_t reg)
> +{
> +	intel_uncore_posting_read(&i915->uncore, reg);
> +}
> +
> +static inline void intel_de_write(struct drm_i915_private *i915, i915_reg_t reg,
> +				  u32 val)
> +{
> +	intel_uncore_write(&i915->uncore, reg, val);
> +}
> +
> +static inline void intel_de_rmw(struct drm_i915_private *i915, i915_reg_t reg,
> +				u32 clear, u32 set)
> +{
> +	intel_uncore_rmw(&i915->uncore, reg, clear, set);
> +}
> +
> +#endif /* __INTEL_DISPLAY_UNCORE_H__ */
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

WARNING: multiple messages have this Message-ID (diff)
From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
To: Jani Nikula <jani.nikula@intel.com>, intel-gfx@lists.freedesktop.org
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Subject: Re: [Intel-gfx] [RFC 1/2] drm/i915: add display uncore helpers
Date: Tue, 29 Oct 2019 14:20:49 -0700	[thread overview]
Message-ID: <9bbc3ef0-ecb3-eb97-ccf8-7dbeedaff259@intel.com> (raw)
Message-ID: <20191029212049.0wih_F2flSBA6yGcFYjr9ULE_uk7YYzYGLzgyLzTgLI@z> (raw)
In-Reply-To: <20191029105156.21658-1-jani.nikula@intel.com>



On 10/29/19 3:51 AM, Jani Nikula wrote:
> Add convenience helpers for the most common uncore operations with
> struct drm_i915_private * as context rather than struct intel_uncore *.
> 
> The goal is to replace all instances of I915_READ(),
> I915_POSTING_READ(), and I915_WRITE() in display/ with these, to finally
> be able to get rid of the implicit dev_priv local parameter use.
> 
> The idea is that any non-u32 reads or writes are special enough that
> they can use the intel_uncore_* functions directly.
> 
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Lucas De Marchi <lucas.demarchi@intel.com>
> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> 
> ---
> 
> Let the name bikeshedding commence! Some options are:
> 
> - intel_de_read, intel_de_write (this patch, de for display engine)

+1 for this. it also matches the intel_de_wait_for_register/set/clear 
macros, which we could probably move in this file as well.

Daniele

> - intel_display_read, intel_display_write (too long I think)
> - intel_read, intel_write
> - i915_read, i915_write
> - display_read, display_write
> - ?
> 
> Here's a draft cocci patch that could be used on display/ subdir, en
> masse:
> 
> @@
> expression REG, OFFSET;
> @@
> - I915_READ(REG)
> + intel_de_read(dev_priv, REG)
> 
> @@
> expression REG, OFFSET;
> @@
> - I915_POSTING_READ(REG)
> + intel_de_posting_read(dev_priv, REG)
> 
> @@
> expression REG, OFFSET;
> @@
> - I915_WRITE(REG, OFFSET)
> + intel_de_write(dev_priv, REG, OFFSET)
> 
> Conveniently, we *know* dev_priv is everywhere the change is needed.
> 
> This enables us to make the s/dev_priv/i915/ rename on top. We also need
> to discuss whether it's better to separate the steps to two (even if in
> the same patch series) or if it's better to add the dev_priv parameter
> as i915 directly.
> ---
>   .../drm/i915/display/intel_display_uncore.h   | 36 +++++++++++++++++++
>   1 file changed, 36 insertions(+)
>   create mode 100644 drivers/gpu/drm/i915/display/intel_display_uncore.h
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_uncore.h b/drivers/gpu/drm/i915/display/intel_display_uncore.h
> new file mode 100644
> index 000000000000..e6c8c56fb0f9
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_display_uncore.h
> @@ -0,0 +1,36 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2019 Intel Corporation
> + */
> +
> +#ifndef __INTEL_DISPLAY_UNCORE_H__
> +#define __INTEL_DISPLAY_UNCORE_H__
> +
> +#include "i915_drv.h"
> +#include "i915_reg.h"
> +#include "intel_uncore.h"
> +
> +static inline u32 intel_de_read(struct drm_i915_private *i915, i915_reg_t reg)
> +{
> +	return intel_uncore_read(&i915->uncore, reg);
> +}
> +
> +static inline void intel_de_posting_read(struct drm_i915_private *i915,
> +					 i915_reg_t reg)
> +{
> +	intel_uncore_posting_read(&i915->uncore, reg);
> +}
> +
> +static inline void intel_de_write(struct drm_i915_private *i915, i915_reg_t reg,
> +				  u32 val)
> +{
> +	intel_uncore_write(&i915->uncore, reg, val);
> +}
> +
> +static inline void intel_de_rmw(struct drm_i915_private *i915, i915_reg_t reg,
> +				u32 clear, u32 set)
> +{
> +	intel_uncore_rmw(&i915->uncore, reg, clear, set);
> +}
> +
> +#endif /* __INTEL_DISPLAY_UNCORE_H__ */
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2019-10-29 21:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-29 10:51 [RFC 1/2] drm/i915: add display uncore helpers Jani Nikula
2019-10-29 10:51 ` [Intel-gfx] " Jani Nikula
2019-10-29 10:51 ` [RFC 2/2] drm/i915/audio: replace I915_*() calls with the new intel_de_*() calls Jani Nikula
2019-10-29 10:51   ` [Intel-gfx] " Jani Nikula
2019-10-29 14:26 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [RFC,1/2] drm/i915: add display uncore helpers Patchwork
2019-10-29 14:26   ` [Intel-gfx] " Patchwork
2019-10-29 16:02 ` ✓ Fi.CI.BAT: success " Patchwork
2019-10-29 16:02   ` [Intel-gfx] " Patchwork
2019-10-29 21:20 ` Daniele Ceraolo Spurio [this message]
2019-10-29 21:20   ` [Intel-gfx] [RFC 1/2] " Daniele Ceraolo Spurio
2019-10-30  5:09 ` ✓ Fi.CI.IGT: success for series starting with [RFC,1/2] " Patchwork
2019-10-30  5:09   ` [Intel-gfx] " Patchwork
2019-11-05 12:41 ` [RFC 1/2] " Joonas Lahtinen
2019-11-05 12:41   ` [Intel-gfx] " Joonas Lahtinen
2019-11-05 13:33   ` Jani Nikula
2019-11-05 13:33     ` [Intel-gfx] " 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=9bbc3ef0-ecb3-eb97-ccf8-7dbeedaff259@intel.com \
    --to=daniele.ceraolospurio@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@intel.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox