From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>,
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 08:44:54 +0000 [thread overview]
Message-ID: <83eb34c4-0549-76d3-1692-cd0e4d39e810@linux.intel.com> (raw)
In-Reply-To: <87r2g6mt3c.fsf@intel.com>
On 31/10/2018 08:13, Jani Nikula wrote:
> 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?
I saw some mention somewhere on IS_GEN_RANGE, which looked clearer than
IS_GEN(dev_priv, s, e). Presumably that did not go anywhere since now
the proposal is the above? I have to say I am not sure it reads
completely intuitive when seen near in code:
IS_GEN(dev_priv, 9)
IS_GEN(dev_priv, 8, 9)
Looks like a variable arg list and the difference in semantics does not
come through. As such I am leaning towards thinking it is too much churn
for unclear benefit. Or in other words I thought IS_GEN_RANGE was a
better direction.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2018-10-31 8:44 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
2018-10-31 8:44 ` Tvrtko Ursulin [this message]
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=83eb34c4-0549-76d3-1692-cd0e4d39e810@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox