From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: <intel-gfx@lists.freedesktop.org>,
<intel-xe@lists.freedesktop.org>, <lucas.demarchi@intel.com>,
<ville.syrjala@linux.intel.com>
Subject: Re: [RFC v2 2/4] drm/i915/display: add generic to_intel_display() macro
Date: Wed, 6 Mar 2024 13:16:39 -0500 [thread overview]
Message-ID: <ZeizBzI-yv_fwdmx@intel.com> (raw)
In-Reply-To: <0b9459da6c8cba0f74bf2781d69182fa6801cd97.1709727127.git.jani.nikula@intel.com>
On Wed, Mar 06, 2024 at 02:24:36PM +0200, Jani Nikula wrote:
> Convert various pointers to struct intel_display * using _Generic().
>
> Add some macro magic to make adding new conversions easier, and somewhat
> abstract the need to cast each generic association. The cast is required
> because all associations needs to compile, regardless of the type and
> the generic selection.
>
> The use of *p in the generic selection assignment expression removes the
> need to add separate associations for const pointers.
>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
> .../drm/i915/display/intel_display_types.h | 46 +++++++++++++++++++
> 1 file changed, 46 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h b/drivers/gpu/drm/i915/display/intel_display_types.h
> index e67cd5b02e84..3f63a5a74d77 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -2183,4 +2183,50 @@ static inline int to_bpp_x16(int bpp)
> return bpp << 4;
> }
>
> +/*
> + * Conversion functions/macros from various pointer types to struct
> + * intel_display pointer.
> + */
> +static inline struct intel_display *__drm_device_to_intel_display(const struct drm_device *drm)
> +{
> + /*
> + * Assume there's a pointer to struct intel_display in memory right
> + * after struct drm_device.
> + */
> + struct intel_display **p = (struct intel_display **)(drm + 1);
at least this patch and the first one should be together to help the
'magic' to be understood and confirmed safe.
> +
> + return *p;
> +}
> +
> +#define __intel_connector_to_intel_display(p) \
> + __drm_device_to_intel_display((p)->base.dev)
> +#define __intel_crtc_to_intel_display(p) \
> + __drm_device_to_intel_display((p)->base.dev)
> +#define __intel_crtc_state_to_intel_display(p) \
> + __drm_device_to_intel_display((p)->uapi.crtc->dev)
> +#define __intel_digital_port_to_intel_display(p) \
> + __drm_device_to_intel_display((p)->base.base.dev)
> +#define __intel_encoder_to_intel_display(p) \
> + __drm_device_to_intel_display((p)->base.dev)
> +#define __intel_hdmi_to_intel_display(p) \
> + __drm_device_to_intel_display(hdmi_to_dig_port(p)->base.base.dev)
> +#define __intel_dp_to_intel_display(p) \
> + __drm_device_to_intel_display(dp_to_dig_port(p)->base.base.dev)
> +
> +/* Helper for generic association. Map types to conversion functions/macros. */
> +#define __assoc(type, p) \
> + struct type: __##type##_to_intel_display((struct type *)(p))
> +
> +/* Convert various pointer types to struct intel_display pointer. */
> +#define to_intel_display(p) \
For a moment I almost complained of this because of the generic magic,
but mostly because I had guc related code in mind where you can never
find the definition, but here it is different. the used 'to_intel_display'
can easily be searched by cscope/ctags and then you are able to see
below what are the accepted cases, so I ended up liking it.
> + _Generic(*p, \
> + __assoc(intel_connector, p), \
> + __assoc(intel_crtc, p), \
> + __assoc(intel_crtc_state, p), \
> + __assoc(intel_digital_port, p), \
> + __assoc(intel_encoder, p), \
> + __assoc(intel_hdmi, p), \
> + __assoc(intel_dp, p), \
> + __assoc(drm_device, p))
> +
> #endif /* __INTEL_DISPLAY_TYPES_H__ */
> --
> 2.39.2
>
next prev parent reply other threads:[~2024-03-06 18:16 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-06 12:24 [RFC v2 0/4] drm/i915: better high level abstraction for display Jani Nikula
2024-03-06 12:24 ` [RFC v2 1/4] drm/i915/display: ideas for further separating display code from the rest Jani Nikula
2024-03-06 12:42 ` Jani Nikula
2024-03-06 12:24 ` [RFC v2 2/4] drm/i915/display: add generic to_intel_display() macro Jani Nikula
2024-03-06 18:16 ` Rodrigo Vivi [this message]
2024-03-07 11:28 ` Jani Nikula
2024-03-07 13:43 ` Rodrigo Vivi
2024-03-06 12:24 ` [RFC v2 3/4] drm/i915/display: accept either i915 or display for feature tests Jani Nikula
2024-03-06 12:24 ` [RFC v2 4/4] drm/i915/display: test various to_intel_display() scenarios Jani Nikula
2024-03-06 12:29 ` ✓ CI.Patch_applied: success for drm/i915: better high level abstraction for display Patchwork
2024-03-06 12:29 ` ✗ CI.checkpatch: warning " Patchwork
2024-03-06 12:30 ` ✓ CI.KUnit: success " Patchwork
2024-03-06 12:41 ` ✓ CI.Build: " Patchwork
2024-03-06 12:41 ` ✗ CI.Hooks: failure " Patchwork
2024-03-06 12:43 ` ✗ CI.checksparse: warning " Patchwork
2024-03-06 13:11 ` ✓ CI.BAT: success " Patchwork
2024-03-06 18:23 ` [RFC v2 0/4] " Rodrigo Vivi
2024-03-06 21:13 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2024-03-06 21:14 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-03-06 21:27 ` ✓ Fi.CI.BAT: success " Patchwork
2024-03-07 15:25 ` ✗ 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=ZeizBzI-yv_fwdmx@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=lucas.demarchi@intel.com \
--cc=ville.syrjala@linux.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.