All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Luca Coelho <luciano.coelho@intel.com>, intel-gfx@lists.freedesktop.org
Cc: lucas.demarchi@intel.com, rodrigo.vivi@intel.com
Subject: Re: [Intel-gfx] [RFC] drm/i915: make dev_priv usage explitic in some macros
Date: Wed, 01 Feb 2023 19:09:12 +0200	[thread overview]
Message-ID: <87zg9x1fev.fsf@intel.com> (raw)
In-Reply-To: <20230201135329.514677-1-luciano.coelho@intel.com>

On Wed, 01 Feb 2023, Luca Coelho <luciano.coelho@intel.com> wrote:
> There are a few macros (e.g. DPLL()) that implicitly use dev_priv, by
> using other macros that implcitily use dev_priv.
>
> In an effort to align all definitions of struct drm_i915_private to be
> declared as i915 instead of arbitrarily using either i915 or dev_priv,
> we need to make these macros explicitly use dev_priv, so that we can
> change them later to be defined as i915.

Lucas posted a slightly related patch [1], and I think based on the
discussion we should probably add AUX and DPLL registers that are
VLV/CHV specific, and include the MMIO offset directly without dev_priv,
and non-VLV/CHV macros that will have MMIO offset 0. This would reduce
the implicit dev_priv considerably, and avoid the need to pass i915
pointer to those register macros altogether.

> diff --git a/drivers/gpu/drm/i915/display/vlv_dsi_regs.h b/drivers/gpu/drm/i915/display/vlv_dsi_regs.h
> index abbe427e462e..d00e9321064a 100644
> --- a/drivers/gpu/drm/i915/display/vlv_dsi_regs.h
> +++ b/drivers/gpu/drm/i915/display/vlv_dsi_regs.h
> @@ -100,7 +100,7 @@
>  
>  #define _MIPIA_DEVICE_READY		(_MIPI_MMIO_BASE(dev_priv) + 0xb000)
>  #define _MIPIC_DEVICE_READY		(_MIPI_MMIO_BASE(dev_priv) + 0xb800)
> -#define MIPI_DEVICE_READY(port)		_MMIO_MIPI(port, _MIPIA_DEVICE_READY, _MIPIC_DEVICE_READY)
> +#define MIPI_DEVICE_READY(dev_priv, port) _MMIO_MIPI(port, _MIPIA_DEVICE_READY, _MIPIC_DEVICE_READY)

While this kind of passes dev_priv as parameter, the dev_priv in
_MIPIA_DEVICE_READY and _MIPIC_DEVICE_READY is still implicit. I think
these could use a similar treatment as in [1], moving the
_MIPI_MMIO_BASE() part one level up.


BR,
Jani.


[1] https://patchwork.freedesktop.org/patch/msgid/20230131191542.1695398-2-lucas.demarchi@intel.com

-- 
Jani Nikula, Intel Open Source Graphics Center

  parent reply	other threads:[~2023-02-01 17:15 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-01 13:53 [Intel-gfx] [RFC] drm/i915: make dev_priv usage explitic in some macros Luca Coelho
2023-02-01 13:58 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for " Patchwork
2023-02-01 14:00 ` [Intel-gfx] [RFC] " Luca Coelho
2023-02-01 16:10 ` Andrzej Hajda
2023-02-01 16:52   ` Coelho, Luciano
2023-02-01 17:09 ` Jani Nikula [this message]
2023-02-01 17:17   ` Lucas De Marchi
2023-02-01 17:20   ` Coelho, Luciano
2023-02-01 18:07     ` Lucas De Marchi
2023-02-01 18:48       ` Coelho, Luciano

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=87zg9x1fev.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lucas.demarchi@intel.com \
    --cc=luciano.coelho@intel.com \
    --cc=rodrigo.vivi@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.