[Intel-gfx] [PATCH 28/71] drm/i915/chv: Added CHV specific register read and write
Ben Widawsky
ben at bwidawsk.net
Fri Apr 18 02:28:33 CEST 2014
On Wed, Apr 09, 2014 at 01:28:26PM +0300, ville.syrjala at linux.intel.com wrote:
> From: Deepak S <deepak.s at intel.com>
>
> Support to individually control Media/Render well based on the register access.
> Add CHV specific write function to habdle difference between registers
> that are sadowed vs those that need forcewake even for writes.
>
> v2: Drop write FIFO for CHV and add comman well forcewake (Ville)
>
> Signed-off-by: Deepak S <deepak.s at intel.com>
> [vsyrjala: Move the register range macros into intel_uncore.c]
> Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 139 +++++++++++++++++++++++++++++++++---
> 1 file changed, 131 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> index 823d699..8e3c686 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -495,6 +495,31 @@ void assert_force_wake_inactive(struct drm_i915_private *dev_priv)
> ((reg) >= 0x22000 && (reg) < 0x24000) ||\
> ((reg) >= 0x30000 && (reg) < 0x40000))
>
> +#define FORCEWAKE_CHV_RENDER_RANGE_OFFSET(reg) \
> + (((reg) >= 0x2000 && (reg) < 0x4000) ||\
> + ((reg) >= 0x5000 && (reg) < 0x8000) ||\
> + ((reg) >= 0x8300 && (reg) < 0x8500) ||\
> + ((reg) >= 0xB000 && (reg) < 0xC000) ||\
> + ((reg) >= 0xE000 && (reg) < 0xE800))
> +
> +#define FORCEWAKE_CHV_MEDIA_RANGE_OFFSET(reg)\
> + (((reg) >= 0x8800 && (reg) < 0x8900) ||\
> + ((reg) >= 0xD000 && (reg) < 0xD800) ||\
> + ((reg) >= 0x12000 && (reg) < 0x14000) ||\
> + ((reg) >= 0x1A000 && (reg) < 0x1C000) ||\
> + ((reg) >= 0x1E800 && (reg) < 0x1EA00) ||\
> + ((reg) >= 0x30000 && (reg) < 0x40000))
> +
> +#define FORCEWAKE_CHV_COMMON_RANGE_OFFSET(reg)\
> + (((reg) >= 0x4000 && (reg) < 0x5000) ||\
> + ((reg) >= 0x8000 && (reg) < 0x8300) ||\
> + ((reg) >= 0x8500 && (reg) < 0x8600) ||\
> + ((reg) >= 0x9000 && (reg) < 0xB000) ||\
> + ((reg) >= 0xC000 && (reg) < 0xc800) ||\
> + ((reg) >= 0xF000 && (reg) < 0x10000) ||\
> + ((reg) >= 0x14000 && (reg) < 0x14400) ||\
> + ((reg) >= 0x22000 && (reg) < 0x24000))
> +
To satisfy both Chris, and Ville, how about:
#define REG_RANGE(reg, start, end) ((reg) >= (start) && (reg) < 0x5000)
REG_RANGE(reg, 0x4000, 0x5000) || \
REG_RANGE(reg, 0x8000, 0x8300) || \
...
By the way, I spent my due diligence trying to find where these ranges
come from, and have been unable. Doc name? I should have all the docs
from Ville.
I can't speak for the code generated, either.
> static void
> ilk_dummy_write(struct drm_i915_private *dev_priv)
> {
> @@ -587,7 +612,48 @@ vlv_read##x(struct drm_i915_private *dev_priv, off_t reg, bool trace) { \
> REG_READ_FOOTER; \
> }
>
> +#define __chv_read(x) \
> +static u##x \
> +chv_read##x(struct drm_i915_private *dev_priv, off_t reg, bool trace) { \
> + unsigned fwengine = 0; \
> + REG_READ_HEADER(x); \
> + if (FORCEWAKE_CHV_RENDER_RANGE_OFFSET(reg)) { \
> + fwengine = FORCEWAKE_RENDER; \
> + } \
> + else if (FORCEWAKE_CHV_MEDIA_RANGE_OFFSET(reg)) { \
> + fwengine = FORCEWAKE_MEDIA; \
> + } \
> + else if (FORCEWAKE_CHV_COMMON_RANGE_OFFSET(reg)) { \
> + fwengine = FORCEWAKE_ALL; \
> + } \
> + if (FORCEWAKE_RENDER & fwengine) { \
> + if (dev_priv->uncore.fw_rendercount++ == 0) \
> + (dev_priv)->uncore.funcs.force_wake_get(dev_priv, \
> + fwengine); \
> + } \
> + if (FORCEWAKE_MEDIA & fwengine) { \
> + if (dev_priv->uncore.fw_mediacount++ == 0) \
> + (dev_priv)->uncore.funcs.force_wake_get(dev_priv, \
> + fwengine); \
> + } \
> + val = __raw_i915_read##x(dev_priv, reg); \
> + if (FORCEWAKE_RENDER & fwengine) { \
> + if (dev_priv->uncore.fw_rendercount++ == 0) \
> + (dev_priv)->uncore.funcs.force_wake_put(dev_priv, \
> + fwengine); \
> + } \
> + if (FORCEWAKE_MEDIA & fwengine) { \
> + if (dev_priv->uncore.fw_mediacount++ == 0) \
> + (dev_priv)->uncore.funcs.force_wake_put(dev_priv, \
> + fwengine); \
> + } \
> + REG_READ_FOOTER; \
> +}
>
> +__chv_read(8)
> +__chv_read(16)
> +__chv_read(32)
> +__chv_read(64)
> __vlv_read(8)
> __vlv_read(16)
> __vlv_read(32)
> @@ -605,6 +671,7 @@ __gen4_read(16)
> __gen4_read(32)
> __gen4_read(64)
>
> +#undef __chv_read
> #undef __vlv_read
> #undef __gen6_read
> #undef __gen5_read
> @@ -709,6 +776,49 @@ gen8_write##x(struct drm_i915_private *dev_priv, off_t reg, u##x val, bool trace
> REG_WRITE_FOOTER; \
> }
>
> +#define __chv_write(x) \
> +static void \
> +chv_write##x(struct drm_i915_private *dev_priv, off_t reg, u##x val, bool trace) { \
> + unsigned fwengine = 0; \
> + bool __needs_put = !is_gen8_shadowed(dev_priv, reg); \
> + REG_WRITE_HEADER; \
> + if (FORCEWAKE_CHV_RENDER_RANGE_OFFSET(reg)) { \
> + fwengine = FORCEWAKE_RENDER; \
> + } \
> + else if (FORCEWAKE_CHV_MEDIA_RANGE_OFFSET(reg)) { \
> + fwengine = FORCEWAKE_MEDIA; \
> + } \
> + else if (FORCEWAKE_CHV_COMMON_RANGE_OFFSET(reg)) { \
> + fwengine = FORCEWAKE_ALL; \
> + } \
> + if (__needs_put && (FORCEWAKE_RENDER & fwengine)) { \
> + if (dev_priv->uncore.fw_rendercount++ == 0) \
> + (dev_priv)->uncore.funcs.force_wake_get(dev_priv, \
> + fwengine); \
> + } \
> + if (__needs_put && (FORCEWAKE_MEDIA & fwengine)) { \
> + if (dev_priv->uncore.fw_mediacount++ == 0) \
> + (dev_priv)->uncore.funcs.force_wake_get(dev_priv, \
> + fwengine); \
> + } \
> + __raw_i915_write##x(dev_priv, reg, val); \
> + if (__needs_put && (FORCEWAKE_RENDER & fwengine)) { \
> + if (dev_priv->uncore.fw_rendercount++ == 0) \
> + (dev_priv)->uncore.funcs.force_wake_put(dev_priv, \
> + fwengine); \
> + } \
> + if (__needs_put && (FORCEWAKE_MEDIA & fwengine)) { \
> + if (dev_priv->uncore.fw_mediacount++ == 0) \
> + (dev_priv)->uncore.funcs.force_wake_put(dev_priv, \
> + fwengine); \
> + } \
> + REG_WRITE_FOOTER; \
> +}
Feels like this would be a lot neater if you let force_wake_put() handle
this complexity. I guess our force_wake_funcs can't handle count. In
that case we could even share the gen8_write family of functions. Was
there some reason this can't work? (Again, forgive laziness)
> +
> +__chv_write(8)
> +__chv_write(16)
> +__chv_write(32)
> +__chv_write(64)
Similar to broadwell (my bad, I know), we probably only actually want to
do this for read/write32. So we potentially could reduce the obj size by
only doing it for that.
> __gen8_write(8)
> __gen8_write(16)
> __gen8_write(32)
> @@ -730,6 +840,7 @@ __gen4_write(16)
> __gen4_write(32)
> __gen4_write(64)
>
> +#undef __chv_write
> #undef __gen8_write
> #undef __hsw_write
> #undef __gen6_write
> @@ -793,14 +904,26 @@ void intel_uncore_init(struct drm_device *dev)
>
> switch (INTEL_INFO(dev)->gen) {
> default:
> - dev_priv->uncore.funcs.mmio_writeb = gen8_write8;
> - dev_priv->uncore.funcs.mmio_writew = gen8_write16;
> - dev_priv->uncore.funcs.mmio_writel = gen8_write32;
> - dev_priv->uncore.funcs.mmio_writeq = gen8_write64;
> - dev_priv->uncore.funcs.mmio_readb = gen6_read8;
> - dev_priv->uncore.funcs.mmio_readw = gen6_read16;
> - dev_priv->uncore.funcs.mmio_readl = gen6_read32;
> - dev_priv->uncore.funcs.mmio_readq = gen6_read64;
> + if (IS_CHERRYVIEW(dev)) {
> + dev_priv->uncore.funcs.mmio_writeb = chv_write8;
> + dev_priv->uncore.funcs.mmio_writew = chv_write16;
> + dev_priv->uncore.funcs.mmio_writel = chv_write32;
> + dev_priv->uncore.funcs.mmio_writeq = chv_write64;
> + dev_priv->uncore.funcs.mmio_readb = chv_read8;
> + dev_priv->uncore.funcs.mmio_readw = chv_read16;
> + dev_priv->uncore.funcs.mmio_readl = chv_read32;
> + dev_priv->uncore.funcs.mmio_readq = chv_read64;
> +
> + } else {
> + dev_priv->uncore.funcs.mmio_writeb = gen8_write8;
> + dev_priv->uncore.funcs.mmio_writew = gen8_write16;
> + dev_priv->uncore.funcs.mmio_writel = gen8_write32;
> + dev_priv->uncore.funcs.mmio_writeq = gen8_write64;
> + dev_priv->uncore.funcs.mmio_readb = gen6_read8;
> + dev_priv->uncore.funcs.mmio_readw = gen6_read16;
> + dev_priv->uncore.funcs.mmio_readl = gen6_read32;
> + dev_priv->uncore.funcs.mmio_readq = gen6_read64;
> + }
> break;
> case 7:
> case 6:
> --
> 1.8.3.2
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
More information about the Intel-gfx
mailing list