All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Lucas De Marchi <lucas.de.marchi@gmail.com>
Cc: intel-gfx@lists.freedesktop.org,
	Lucas De Marchi <lucas.demarchi@intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [RFC 1/4] drm/i915: Add Display Gen info.
Date: Wed, 31 Oct 2018 10:13:43 +0200	[thread overview]
Message-ID: <87r2g6mt3c.fsf@intel.com> (raw)
In-Reply-To: <20181030182514.GA5740@ldmartin-desk.jf.intel.com>

On Tue, 30 Oct 2018, Lucas De Marchi <lucas.de.marchi@gmail.com> wrote:
> On Tue, Oct 30, 2018 at 11:52:30AM +0200, Jani Nikula wrote:
>> On Mon, 29 Oct 2018, Rodrigo Vivi <rodrigo.vivi@intel.com> wrote:
>> > +#define IS_DISPLAY_GEN2(dev_priv)	(!!((dev_priv)->info.display_gen_mask \
>> > +					    & BIT(2)))
>> > +#define IS_DISPLAY_GEN3(dev_priv)	(!!((dev_priv)->info.display_gen_mask \
>> > +					    & BIT(3)))
>> > +#define IS_DISPLAY_GEN4(dev_priv)	(!!((dev_priv)->info.display_gen_mask \
>> > +					    & BIT(4)))
>> > +#define IS_DISPLAY_GEN5(dev_priv)	(!!((dev_priv)->info.display_gen_mask \
>> > +					    & BIT(5)))
>> > +#define IS_DISPLAY_GEN6(dev_priv)	(!!((dev_priv)->info.display_gen_mask \
>> > +					    & BIT(6)))
>> > +#define IS_DISPLAY_GEN7(dev_priv)	(!!((dev_priv)->info.display_gen_mask \
>> > +					    & BIT(7)))
>> > +#define IS_DISPLAY_GEN8(dev_priv)	(!!((dev_priv)->info.display_gen_mask \
>> > +					    & BIT(8)))
>> > +#define IS_DISPLAY_GEN9(dev_priv)	(!!((dev_priv)->info.display_gen_mask \
>> > +					    & BIT(9)))
>> > +#define IS_DISPLAY_GEN10(dev_priv)	(!!((dev_priv)->info.display_gen_mask \
>> > +					    & BIT(10)))
>> > +#define IS_DISPLAY_GEN11(dev_priv)	(!!((dev_priv)->info.display_gen_mask \
>> > +					    & BIT(11)))
>> 
>> I know this is the same pattern as in IS_GEN<N> above, but shouldn't the
>> compiler end up with the same result if these were simply:
>> 
>> #define IS_DISPLAY_GEN2(dev_priv) IS_DISPLAY_GEN(dev_priv, 2, 2)
>
>
> humn... maybe this is too magic, but it works for me and I didn't add any additional
> macro to the kernel to implement it :)
>
> [CI, DON'T TEST THIS] diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> [CI, DON'T TEST THIS] index 554627dc623c..02a8b51fd733 100644
> [CI, DON'T TEST THIS] --- a/drivers/gpu/drm/i915/i915_drv.h
> [CI, DON'T TEST THIS] +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2385,9 +2385,15 @@ intel_info(const struct drm_i915_private *dev_priv)
>  	GENMASK((e) - 1, (s) - 1))
>  
>  /* Returns true if Gen is in inclusive range [Start, End] */
> -#define IS_GEN(dev_priv, s, e) \
> +#define _IS_GEN_ARG2(dev_priv, s, e) \
>  	(!!((dev_priv)->info.gen_mask & INTEL_GEN_MASK((s), (e))))
>  
> +#define _IS_GEN_ARG1(dev_priv, g) \
> +	(!!((dev_priv)->info.gen_mask & BIT((g) - 1)))
> +
> +#define IS_GEN(dev_priv, ...) \
> +	CONCATENATE(_IS_GEN_ARG, COUNT_ARGS(__VA_ARGS__))((dev_priv), ##__VA_ARGS__)
> +
>  /*
>   * Return true if revision is in range [since,until] inclusive.
>   *
>
>
> So we could use IS_GEN(dev_priv, 2) as well as IS_GEN(dev_priv, 2, 4), which IMO is very clear.
> The same would apply for IS_DISPLAY_GEN() version. And if they generate the same code, we could
> just change the expansion to repeat the argument.

I like this stuff. 

So I'd prefer IS_GEN(dev_priv, 2) in favor of IS_GEN2(dev_priv)
throughout.

As long as it doesn't increase the code size too much, but this being
macro magic I don't think it should.

Care to cook up a patch against current tip to make IS_GEN() take 1 or 2
args? If I read the above right, you'll get a build error for using
IS_GEN(dev_priv, 1, 2, 3), is that correct?

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-10-31  8:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-30  0:34 [RFC 1/4] drm/i915: Add Display Gen info Rodrigo Vivi
2018-10-30  0:34 ` [RFC 2/4] drm/i915: Finally recognize Geminilake as Gen10 Display Rodrigo Vivi
2018-10-30  0:34 ` [RFC 3/4] drm/i915: Use Display gen9 for gen9_bc || bxt Rodrigo Vivi
2018-10-30  0:34 ` [RFC 4/4] drm/i915: Expand DISPLAY_GEN macro usage to display related files Rodrigo Vivi
2018-10-30  1:19 ` ✗ Fi.CI.CHECKPATCH: warning for series starting with [RFC,1/4] drm/i915: Add Display Gen info Patchwork
2018-10-30  1:21 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-10-30  1:39 ` ✗ Fi.CI.BAT: failure " Patchwork
2018-10-30  9:52 ` [RFC 1/4] " Jani Nikula
2018-10-30 17:47   ` Rodrigo Vivi
2018-10-30 18:25   ` Lucas De Marchi
2018-10-31  8:13     ` Jani Nikula [this message]
2018-10-31  8:44       ` Tvrtko Ursulin
2018-10-31  9:00         ` Jani Nikula
2018-10-31 15:53           ` Rodrigo Vivi
2018-10-31 17:55             ` Jani Nikula
2018-10-31 18:13       ` Lucas De Marchi

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=87r2g6mt3c.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lucas.de.marchi@gmail.com \
    --cc=lucas.demarchi@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.