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
next prev parent 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: linkBe 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.