Re: [PATCH v5 1/7] bits: split the definition of the asm and non-asm GENMASK()

On Fri, 7 Mar 2025 18:58:08 +0900 Vincent Mailhol wrote: > On 07/03/2025 at 04:23, David Laight wrote: > > On Thu, 06 Mar 2025 20:29:52 +0900 > > Vincent Mailhol via B4 Relay > > wrote: > > > >> From: Vincent Mailhol > >> > >> In an upcoming change, GENMASK() and its friends will indirectly

✗ Fi.CI.CHECKPATCH: warning for drm/i915: Increase I915_PARAM_MMAP_GTT_VERSION version to indicate support for partial mmaps (rev5)

== Series Details == Series: drm/i915: Increase I915_PARAM_MMAP_GTT_VERSION version to indicate support for partial mmaps (rev5) URL : https://patchwork.freedesktop.org/series/145945/ State : warning == Summary == Error: dim checkpatch failed 2a031b020fc6 drm/i915: Increase I915_PARAM_MMAP_GT

✓ i915.CI.BAT: success for drm/i915: Increase I915_PARAM_MMAP_GTT_VERSION version to indicate support for partial mmaps (rev5)

== Series Details == Series: drm/i915: Increase I915_PARAM_MMAP_GTT_VERSION version to indicate support for partial mmaps (rev5) URL : https://patchwork.freedesktop.org/series/145945/ State : success == Summary == CI Bug Log - changes from CI_DRM_16247 -> Patchwork_145945v5 ==

Re: [PATCH v6 1/7] bits: split the definition of the asm and non-asm GENMASK()

On 08/03/2025 at 02:42, Andy Shevchenko wrote: > On Sat, Mar 08, 2025 at 01:48:48AM +0900, Vincent Mailhol via B4 Relay wrote: >> From: Vincent Mailhol >> >> In an upcoming change, GENMASK() and its friends will indirectly >> depend on sizeof() which is not available in asm. >> >> Instead of addin

[PATCH v2 17/18] drm/i915: Move dbuf_state->active_piepes into skl_wm_get_hw_state()

From: Ville Syrjälä Move the dbuf_state readout parts into skl_wm_get_hw_state() so that the details are better hidden from sight. This will stop updating this on pre-skl, but that's what we want since the dbuf state is only used on skl+. Reviewed-by: Vinod Govindapillai Signed-off-by: Ville S

Re: [PATCH v6 4/7] drm/i915: Convert REG_GENMASK*() to fixed-width GENMASK_U*()

On 08/03/2025 at 02:54, Andy Shevchenko wrote: > On Sat, Mar 08, 2025 at 01:48:51AM +0900, Vincent Mailhol via B4 Relay wrote: >> From: Lucas De Marchi >> >> Now that include/linux/bits.h implements fixed-width GENMASK_U*(), use >> them to implement the i915/xe specific macros. Converting each dri

[PATCH 05/21] drm/i915/vrr: Track vrr.enable only for variable timing

Since CMRR is now disabled, use the flag vrr.enable to tracks if vrr timing generator is used with variable timings. Avoid setting vrr.enable for CMRR and adjust readout to not set vrr.enable when vmax == vmin == flipline (fixed refresh rate timing). v2: Use intel_vrr_vmin_flipline() to account f

Re: [PATCH v5 0/7] bits: Fixed-type GENMASK()/BIT()

On Thu, Mar 06, 2025 at 08:29:51PM +0900, Vincent Mailhol via B4 Relay wrote: > Introduce some fixed width variant of the GENMASK() and the BIT() > macros in bits.h. Note that the main goal is not to get the correct > type, but rather to enforce more checks at compile time. For example: > > GENM

Re: [PATCH 2/2] drm: ensure drm headers are self-contained and pass kernel-doc

On Wed, Mar 5, 2025 at 10:59 PM Maxime Ripard wrote: > > On Wed, Mar 05, 2025 at 03:05:25AM +0900, Masahiro Yamada wrote: > > > IMO headers should almost invariably be self-contained, instead of > > > putting the burden on their users to include other headers to make it > > > work. It's a PITA in

Re: [PATCH v6 3/7] bits: introduce fixed-type BIT_U*()

On 08/03/2025 at 02:49, Andy Shevchenko wrote: > On Fri, Mar 07, 2025 at 07:48:01PM +0200, Andy Shevchenko wrote: >> On Sat, Mar 08, 2025 at 01:48:50AM +0900, Vincent Mailhol via B4 Relay wrote: > > ... > >>> /* >>> * Missing asm support >>> * >>> - * GENMASK_U*() depends on BITS_PER_TYPE()

Re: [PATCH v6 0/7] bits: Fixed-type GENMASK_U*() and BIT_U*()

On 08/03/2025 at 02:50, Andy Shevchenko wrote: > On Fri, Mar 07, 2025 at 12:48:36PM -0500, Yury Norov wrote: >> On Fri, Mar 07, 2025 at 07:43:57PM +0200, Andy Shevchenko wrote: >>> On Fri, Mar 07, 2025 at 12:18:02PM -0500, Yury Norov wrote: No rush, please allow your reviewers a week or two be