From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 2/4] drm/i915/cdclk: un-inline intel_cdclk_state functions
Date: Thu, 9 Dec 2021 19:54:49 +0200 [thread overview]
Message-ID: <YbJC6UHlcyt9s7tt@intel.com> (raw)
In-Reply-To: <66f687db7321846049a6aa524dfafd45cf0cb77f.1639068649.git.jani.nikula@intel.com>
On Thu, Dec 09, 2021 at 06:51:23PM +0200, Jani Nikula wrote:
> Hide the details better.
>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 18 ++++++++++++++++++
> drivers/gpu/drm/i915/display/intel_cdclk.h | 13 ++++++++-----
> 2 files changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index a216a350006d..84674a4f7226 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2630,6 +2630,24 @@ intel_atomic_get_cdclk_state(struct intel_atomic_state *state)
> return to_intel_cdclk_state(cdclk_state);
> }
>
> +struct intel_cdclk_state *
> +to_intel_cdclk_state(struct intel_global_state *cdclk_state)
> +{
> + return container_of(cdclk_state, struct intel_cdclk_state, base);
> +}
> +
> +struct intel_cdclk_state *
> +intel_atomic_get_old_cdclk_state(struct intel_atomic_state *state)
> +{
> + return to_intel_cdclk_state(intel_atomic_get_old_global_obj_state(state, &to_i915(state->base.dev)->cdclk.obj));
> +}
> +
> +struct intel_cdclk_state *
> +intel_atomic_get_new_cdclk_state(struct intel_atomic_state *state)
> +{
> + return to_intel_cdclk_state(intel_atomic_get_new_global_obj_state(state, &to_i915(state->base.dev)->cdclk.obj));
> +}
> +
Not really sure about this one. We don't do this for any other similar
cases, and I think the macro versions are needed if we have any kind of
const vs. non-const funny business going on. I guess in this particular
case we don't, but pretty sure that was a real thing for some other
atomic states when I was pondering about using functions rather than
macros for those.
So I'm tempted to say we should stick to a common pattern across the
board if possible.
> int intel_cdclk_atomic_check(struct intel_atomic_state *state,
> bool *need_cdclk_calc)
> {
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h b/drivers/gpu/drm/i915/display/intel_cdclk.h
> index bb3a778c506b..77e8c8e1708f 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.h
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
> @@ -76,11 +76,14 @@ int intel_cdclk_atomic_check(struct intel_atomic_state *state,
> struct intel_cdclk_state *
> intel_atomic_get_cdclk_state(struct intel_atomic_state *state);
>
> -#define to_intel_cdclk_state(x) container_of((x), struct intel_cdclk_state, base)
> -#define intel_atomic_get_old_cdclk_state(state) \
> - to_intel_cdclk_state(intel_atomic_get_old_global_obj_state(state, &to_i915(state->base.dev)->cdclk.obj))
> -#define intel_atomic_get_new_cdclk_state(state) \
> - to_intel_cdclk_state(intel_atomic_get_new_global_obj_state(state, &to_i915(state->base.dev)->cdclk.obj))
> +struct intel_cdclk_state *
> +to_intel_cdclk_state(struct intel_global_state *cdclk_state);
> +
> +struct intel_cdclk_state *
> +intel_atomic_get_old_cdclk_state(struct intel_atomic_state *state);
> +
> +struct intel_cdclk_state *
> +intel_atomic_get_new_cdclk_state(struct intel_atomic_state *state);
>
> int intel_cdclk_init(struct drm_i915_private *dev_priv);
>
> --
> 2.30.2
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2021-12-09 17:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-09 16:51 [Intel-gfx] [PATCH 0/4] drm/i915/cdclk: improve abstractions Jani Nikula
2021-12-09 16:51 ` [Intel-gfx] [PATCH 1/4] drm/i915/cdclk: move intel_atomic_check_cdclk() to intel_cdclk.c Jani Nikula
2021-12-09 17:45 ` Ville Syrjälä
2021-12-09 16:51 ` [Intel-gfx] [PATCH 2/4] drm/i915/cdclk: un-inline intel_cdclk_state functions Jani Nikula
2021-12-09 17:54 ` Ville Syrjälä [this message]
2021-12-09 18:38 ` Jani Nikula
2021-12-09 16:51 ` [Intel-gfx] [PATCH 3/4] drm/i915/cdclk: hide struct intel_cdclk_vals Jani Nikula
2021-12-09 17:46 ` Ville Syrjälä
2021-12-09 16:51 ` [Intel-gfx] [PATCH 4/4] drm/i915/cdclk: turn around i915_drv.h and intel_cdclk.h dependency Jani Nikula
2021-12-09 17:55 ` Ville Syrjälä
2021-12-09 17:57 ` [Intel-gfx] [PATCH 0/4] drm/i915/cdclk: improve abstractions Ville Syrjälä
2021-12-10 4:00 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2021-12-10 4:01 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-12-10 4:30 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-12-10 15:03 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
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=YbJC6UHlcyt9s7tt@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@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.