All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lucas De Marchi <lucas.demarchi@intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2 1/8] drm/i915: Add _PICK_EVEN_2RANGES()
Date: Mon, 23 Jan 2023 23:45:25 -0800	[thread overview]
Message-ID: <20230124074525.xqprvxdtvkodcgdj@ldmartin-desk2.lan> (raw)
In-Reply-To: <87lelt8riz.fsf@intel.com>

(I missed this review you did before I had sent a v2.1, I will incorporate
what is missing in the next version)

On Mon, Jan 23, 2023 at 12:38:28PM +0200, Jani Nikula wrote:
>On Fri, 20 Jan 2023, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
>> It's a constant pattern in the driver to need to use 2 ranges of MMIOs
>> based on port, phy, pll, etc. When that happens, instead of using
>> _PICK_EVEN(), _PICK() needs to be used.  Using _PICK() is discouraged
>> due to some reasons like:
>>
>> 1) It increases the code size since the array is declared
>>    in each call site
>
>Would be interesting to see what this does, and whether the compiler has
>the smarts to combine these within each file:
>
>-#define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
>+#define _PICK(__index, ...) (((static const u32 []){ __VA_ARGS__ })[__index])

if the compiler is smart, it would be at least 1 per compilation unit.
gcc doesn't seem smart enough to even compile it though:

../drivers/gpu/drm/i915/i915_reg_defs.h:155:52: error: expected ‘)’ before ‘{’ token                                                                                                                               
   155 | #define _PICK(__index, ...) (((static const u32 []){ __VA_ARGS__ })[__index])                                                                                                                              
       |                              ~                     ^    

What I'm thinking for the remaining uses of _PICK() is to be explicit
and statically define them in a good .c depending on the use.
Then use that in the macro.

>
>> 2) Developers need to be careful not to incur an
>>    out-of-bounds array access
>> 3) Developers need to be careful that the indexes match the
>>    table. For that it may be that the table needs to contain
>>    holes, making (1) even worse.
>>
>> Add a variant of _PICK_EVEN() that works with 2 ranges and selects which
>> one to use depending on the index value.
>>
>> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
>> ---
>>  drivers/gpu/drm/i915/i915_reg_defs.h | 28 ++++++++++++++++++++++++++++
>>  1 file changed, 28 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h b/drivers/gpu/drm/i915/i915_reg_defs.h
>> index be43580a6979..b7ec87464d69 100644
>> --- a/drivers/gpu/drm/i915/i915_reg_defs.h
>> +++ b/drivers/gpu/drm/i915/i915_reg_defs.h
>> @@ -119,6 +119,34 @@
>>   */
>>  #define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - (__a)))
>>
>> +/*
>> + * Like _PICK_EVEN(), but supports 2 ranges of evenly spaced address offsets.
>> + * The first range is used for indexes below @__c_index, and the second
>> + * range is used for anything above it. Example::
>
>I'd like this to be clear about which range is used for index ==
>__c_index, instead of saying "below" and "above".
>
>No need for the double colon :: because this isn't a kernel-doc comment.

ok, what about this?

  * Like _PICK_EVEN(), but supports 2 ranges of evenly spaced address offsets.
  * @__c_index corresponds to the index in which the second range starts
  * to be used. Using math interval notation, the first range is used
  * for indexes [ 0, @__c_index), while the second range is used for
  * [ @__c_index, ... ). Example:


>
>> + *
>> + * #define _FOO_A			0xf000
>> + * #define _FOO_B			0xf004
>> + * #define _FOO_C			0xf008
>> + * #define _SUPER_FOO_A			0xa000
>> + * #define _SUPER_FOO_B			0xa100
>> + * #define FOO(x)			_MMIO(_PICK_EVEN_RANGES(x, 3,		\
>
>The example uses a different name for the macro.

yeah, that was the previous name I was using... good catch, will fix.

>
>> + *					      _FOO_A, _FOO_B,			\
>> + *					      _SUPER_FOO_A, _SUPER_FOO_B))
>> + *
>> + * This expands to:
>> + *	0: 0xf000,
>> + *	1: 0xf004,
>> + *	2: 0xf008,
>> + *	3: 0xa100,
>
>With the above definitions, this would be 3: 0xa000.

fixed


thanks
Lucas De Marchi

>
>> + *	4: 0xa200,
>> + *	5: 0xa300,
>> + *	...
>> + */
>> +#define _PICK_EVEN_2RANGES(__index, __c_index, __a, __b, __c, __d)		\
>> +	(BUILD_BUG_ON_ZERO(!__is_constexpr(__c_index)) +			\
>> +	 ((__index) < (__c_index) ? _PICK_EVEN(__index, __a, __b) :		\
>> +				   _PICK_EVEN((__index) - (__c_index), __c, __d)))
>> +
>>  /*
>>   * Given the arbitrary numbers in varargs, pick the 0-based __index'th number.
>>   *
>
>-- 
>Jani Nikula, Intel Open Source Graphics Center

WARNING: multiple messages have this Message-ID (diff)
From: Lucas De Marchi <lucas.demarchi@intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2 1/8] drm/i915: Add _PICK_EVEN_2RANGES()
Date: Mon, 23 Jan 2023 23:45:25 -0800	[thread overview]
Message-ID: <20230124074525.xqprvxdtvkodcgdj@ldmartin-desk2.lan> (raw)
In-Reply-To: <87lelt8riz.fsf@intel.com>

(I missed this review you did before I had sent a v2.1, I will incorporate
what is missing in the next version)

On Mon, Jan 23, 2023 at 12:38:28PM +0200, Jani Nikula wrote:
>On Fri, 20 Jan 2023, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
>> It's a constant pattern in the driver to need to use 2 ranges of MMIOs
>> based on port, phy, pll, etc. When that happens, instead of using
>> _PICK_EVEN(), _PICK() needs to be used.  Using _PICK() is discouraged
>> due to some reasons like:
>>
>> 1) It increases the code size since the array is declared
>>    in each call site
>
>Would be interesting to see what this does, and whether the compiler has
>the smarts to combine these within each file:
>
>-#define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
>+#define _PICK(__index, ...) (((static const u32 []){ __VA_ARGS__ })[__index])

if the compiler is smart, it would be at least 1 per compilation unit.
gcc doesn't seem smart enough to even compile it though:

../drivers/gpu/drm/i915/i915_reg_defs.h:155:52: error: expected ‘)’ before ‘{’ token                                                                                                                               
   155 | #define _PICK(__index, ...) (((static const u32 []){ __VA_ARGS__ })[__index])                                                                                                                              
       |                              ~                     ^    

What I'm thinking for the remaining uses of _PICK() is to be explicit
and statically define them in a good .c depending on the use.
Then use that in the macro.

>
>> 2) Developers need to be careful not to incur an
>>    out-of-bounds array access
>> 3) Developers need to be careful that the indexes match the
>>    table. For that it may be that the table needs to contain
>>    holes, making (1) even worse.
>>
>> Add a variant of _PICK_EVEN() that works with 2 ranges and selects which
>> one to use depending on the index value.
>>
>> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
>> ---
>>  drivers/gpu/drm/i915/i915_reg_defs.h | 28 ++++++++++++++++++++++++++++
>>  1 file changed, 28 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg_defs.h b/drivers/gpu/drm/i915/i915_reg_defs.h
>> index be43580a6979..b7ec87464d69 100644
>> --- a/drivers/gpu/drm/i915/i915_reg_defs.h
>> +++ b/drivers/gpu/drm/i915/i915_reg_defs.h
>> @@ -119,6 +119,34 @@
>>   */
>>  #define _PICK_EVEN(__index, __a, __b) ((__a) + (__index) * ((__b) - (__a)))
>>
>> +/*
>> + * Like _PICK_EVEN(), but supports 2 ranges of evenly spaced address offsets.
>> + * The first range is used for indexes below @__c_index, and the second
>> + * range is used for anything above it. Example::
>
>I'd like this to be clear about which range is used for index ==
>__c_index, instead of saying "below" and "above".
>
>No need for the double colon :: because this isn't a kernel-doc comment.

ok, what about this?

  * Like _PICK_EVEN(), but supports 2 ranges of evenly spaced address offsets.
  * @__c_index corresponds to the index in which the second range starts
  * to be used. Using math interval notation, the first range is used
  * for indexes [ 0, @__c_index), while the second range is used for
  * [ @__c_index, ... ). Example:


>
>> + *
>> + * #define _FOO_A			0xf000
>> + * #define _FOO_B			0xf004
>> + * #define _FOO_C			0xf008
>> + * #define _SUPER_FOO_A			0xa000
>> + * #define _SUPER_FOO_B			0xa100
>> + * #define FOO(x)			_MMIO(_PICK_EVEN_RANGES(x, 3,		\
>
>The example uses a different name for the macro.

yeah, that was the previous name I was using... good catch, will fix.

>
>> + *					      _FOO_A, _FOO_B,			\
>> + *					      _SUPER_FOO_A, _SUPER_FOO_B))
>> + *
>> + * This expands to:
>> + *	0: 0xf000,
>> + *	1: 0xf004,
>> + *	2: 0xf008,
>> + *	3: 0xa100,
>
>With the above definitions, this would be 3: 0xa000.

fixed


thanks
Lucas De Marchi

>
>> + *	4: 0xa200,
>> + *	5: 0xa300,
>> + *	...
>> + */
>> +#define _PICK_EVEN_2RANGES(__index, __c_index, __a, __b, __c, __d)		\
>> +	(BUILD_BUG_ON_ZERO(!__is_constexpr(__c_index)) +			\
>> +	 ((__index) < (__c_index) ? _PICK_EVEN(__index, __a, __b) :		\
>> +				   _PICK_EVEN((__index) - (__c_index), __c, __d)))
>> +
>>  /*
>>   * Given the arbitrary numbers in varargs, pick the 0-based __index'th number.
>>   *
>
>-- 
>Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2023-01-24  7:45 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-20 19:34 [PATCH v2 0/8] Add _PICK_EVEN_2RANGES Lucas De Marchi
2023-01-20 19:34 ` [Intel-gfx] " Lucas De Marchi
2023-01-20 19:34 ` [PATCH v2 1/8] drm/i915: Add _PICK_EVEN_2RANGES() Lucas De Marchi
2023-01-20 19:34   ` [Intel-gfx] " Lucas De Marchi
2023-01-21  6:14   ` Srivatsa, Anusha
2023-01-21  6:14     ` Srivatsa, Anusha
2023-01-22  1:28     ` Lucas De Marchi
2023-01-23 11:00       ` Jani Nikula
2023-01-23 16:15         ` Srivatsa, Anusha
2023-01-23 16:15           ` Srivatsa, Anusha
2023-01-23 16:53           ` Lucas De Marchi
2023-01-23 10:38   ` Jani Nikula
2023-01-23 10:38     ` [Intel-gfx] " Jani Nikula
2023-01-24  7:45     ` Lucas De Marchi [this message]
2023-01-24  7:45       ` Lucas De Marchi
2023-01-25 18:24       ` [PATCH v2.2] " Lucas De Marchi
2023-01-25 18:24         ` [Intel-gfx] " Lucas De Marchi
2023-01-23 17:15   ` [PATCH v2.1] " Lucas De Marchi
2023-01-23 17:15     ` [Intel-gfx] " Lucas De Marchi
2023-01-23 17:49     ` Srivatsa, Anusha
2023-01-23 17:49       ` [Intel-gfx] " Srivatsa, Anusha
2023-01-20 19:34 ` [PATCH v2 2/8] drm/i915: Fix coding style on DPLL*_ENABLE defines Lucas De Marchi
2023-01-20 19:34   ` [Intel-gfx] " Lucas De Marchi
2023-01-20 20:14   ` Srivatsa, Anusha
2023-01-20 20:14     ` Srivatsa, Anusha
2023-01-20 19:34 ` [PATCH v2 3/8] drm/i915: Convert pll macros to _PICK_EVEN_2RANGES Lucas De Marchi
2023-01-20 19:34   ` [Intel-gfx] " Lucas De Marchi
2023-01-23 19:12   ` Srivatsa, Anusha
2023-01-23 19:12     ` Srivatsa, Anusha
2023-01-20 19:34 ` [PATCH v2 4/8] drm/i915: Replace _MMIO_PHY3() with _PICK_EVEN_2RANGES() Lucas De Marchi
2023-01-20 19:34   ` [Intel-gfx] " Lucas De Marchi
2023-01-21  5:58   ` Srivatsa, Anusha
2023-01-21  5:58     ` Srivatsa, Anusha
2023-01-20 19:34 ` [PATCH v2 5/8] drm/i915: Convert PIPE3/PORT3 to _PICK_EVEN_2RANGES() Lucas De Marchi
2023-01-20 19:34   ` [Intel-gfx] " Lucas De Marchi
2023-01-21  6:00   ` Srivatsa, Anusha
2023-01-21  6:00     ` Srivatsa, Anusha
2023-01-20 19:34 ` [PATCH v2 6/8] drm/i915: Convert _FIA() " Lucas De Marchi
2023-01-20 19:34   ` [Intel-gfx] " Lucas De Marchi
2023-01-21  6:01   ` Srivatsa, Anusha
2023-01-21  6:01     ` Srivatsa, Anusha
2023-01-20 19:34 ` [Intel-gfx] [PATCH v2 7/8] drm/i915: Convert MBUS_ABOX_CTL() " Lucas De Marchi
2023-01-20 19:34   ` Lucas De Marchi
2023-01-21  6:04   ` [Intel-gfx] " Srivatsa, Anusha
2023-01-21  6:04     ` Srivatsa, Anusha
2023-01-20 19:34 ` [PATCH v2 8/8] drm/i915: Convert PALETTE() " Lucas De Marchi
2023-01-20 19:34   ` [Intel-gfx] " Lucas De Marchi
2023-01-21  6:06   ` Srivatsa, Anusha
2023-01-21  6:06     ` Srivatsa, Anusha
2023-01-20 21:04 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add _PICK_EVEN_2RANGES Patchwork
2023-01-20 21:17 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-01-21 20:55 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-01-23 10:39 ` [PATCH v2 0/8] " Jani Nikula
2023-01-23 10:39   ` [Intel-gfx] " Jani Nikula
2023-01-23 19:27 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add _PICK_EVEN_2RANGES (rev2) Patchwork
2023-01-23 19:44 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-01-24  4:48 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
2023-01-26  1:33 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add _PICK_EVEN_2RANGES (rev3) Patchwork
2023-01-26  1:52 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-01-26 12:13 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=20230124074525.xqprvxdtvkodcgdj@ldmartin-desk2.lan \
    --to=lucas.demarchi@intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@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.