[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tv: avoid possible division by zero (rev3)

== Series Details == Series: drm/i915/tv: avoid possible division by zero (rev3) URL : https://patchwork.freedesktop.org/series/120851/ State : warning == Summary == Error: dim checkpatch failed 4816f1e2f7dc drm/i915/tv: avoid possible division by zero -:40: ERROR:MISSING_SIGN_OFF: Missing Sig

[Intel-gfx] Regression in linux-next

Hello Alistair, Hope you are doing well. I am Chaitanya from the linux graphics team in Intel. This mail is regarding a regression we are seeing in our CI runs[1] on linux-next repository. On next-20230720 [2], we are seeing the following error <4>[ 76.189375] Hardware name: Intel Corporat

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Use full allocated minor range for DRM (rev3)

== Series Details == Series: drm: Use full allocated minor range for DRM (rev3) URL : https://patchwork.freedesktop.org/series/108206/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13417_full -> Patchwork_108206v3_full Summ

Re: [Intel-gfx] [PATCH 07/19] drm/i915/intel_cdclk: Add vdsc with bigjoiner constraints on min_cdlck

On 7/20/2023 2:54 PM, Lisovskiy, Stanislav wrote: On Thu, Jul 13, 2023 at 04:03:34PM +0530, Ankit Nautiyal wrote: As per Bsepc:49259, Bigjoiner BW check puts restriction on the compressed bpp for a given CDCLK, pixelclock in cases where Bigjoiner + DSC are used. Currently compressed bpp is co

Re: [Intel-gfx] [PATCH 06/19] drm/i915/display: Account for DSC not split case while computing cdclk

On 7/20/2023 2:46 PM, Lisovskiy, Stanislav wrote: On Thu, Jul 13, 2023 at 04:03:33PM +0530, Ankit Nautiyal wrote: Currently we assume 2 Pixels Per Clock (PPC) while computing plane cdclk and min_cdlck. In cases where DSC single engine is used the throughput is 1 PPC. So account for the above

Re: [Intel-gfx] [PATCH v2] drm/i915/tv: avoid possible division by zero

The reason why the first five attempts had bugs is because we are trying to write it in the most complicated way possible, shifting by logical not what? regards, dan carpenter diff --git a/drivers/gpu/drm/i915/display/intel_tv.c b/drivers/gpu/drm/i915/display/intel_tv.c index 36b479b46b60..6997b

Re: [Intel-gfx] [PATCH v9 00/10] Enhance vfio PCI hot reset for vfio cdev device

> > VFIO_DEVICE_PCI_HOT_RESET requires user to pass an array of group fds to > prove that it owns all devices affected by resetting the calling device. > While for > cdev devices, user can use an iommufd-based ownership checking model and > invoke VFIO_DEVICE_PCI_HOT_RESET with a zero-length fd a

Re: [Intel-gfx] [PATCH v14 00/26] Add vfio_device cdev for iommufd support

> Subject: [PATCH v14 00/26] Add vfio_device cdev for iommufd support > > Existing VFIO provides group-centric user APIs for userspace. Userspace opens > the /dev/vfio/$group_id first before getting device fd and hence getting > access > to device. This is not the desired model for iommufd. Per t

Re: [Intel-gfx] [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are really allowing.

> -Original Message- > From: Vivi, Rodrigo > Sent: Saturday, July 22, 2023 12:30 AM > To: Gupta, Anshuman > Cc: intel-gfx@lists.freedesktop.org > Subject: Re: [PATCH 1/4] drm/xe: Only set PCI d3cold_allowed when we are > really allowing. > > On Fri, Jul 21, 2023 at 03:39:35AM -0400, G

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Tidy for_each_set_bit usage with abox_regs (rev2)

== Series Details == Series: drm/i915: Tidy for_each_set_bit usage with abox_regs (rev2) URL : https://patchwork.freedesktop.org/series/121233/ State : success == Summary == CI Bug Log - changes from CI_DRM_13417_full -> Patchwork_121233v2_full =

Re: [Intel-gfx] [PATCH 3/3] drm/i915/uncore: optimize CONFIG_DRM_I915_DEBUG_MMIO=n more

>On 06/07/2023 13:06, Jani Nikula wrote: >> On Thu, 06 Jul 2023, Tvrtko Ursulin wrote: >>> On 04/07/2023 10:48, Jani Nikula wrote: While the default for the mmio_debug parameter depends on CONFIG_DRM_I915_DEBUG_MMIO, we look it up and include all the code for unclaimed reg debuggi

[Intel-gfx] ✓ Fi.CI.BAT: success for Update AUX invalidation sequence (rev10)

== Series Details == Series: Update AUX invalidation sequence (rev10) URL : https://patchwork.freedesktop.org/series/119798/ State : success == Summary == CI Bug Log - changes from CI_DRM_13418 -> Patchwork_119798v10 Summary --- **SU

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Update AUX invalidation sequence (rev10)

== Series Details == Series: Update AUX invalidation sequence (rev10) URL : https://patchwork.freedesktop.org/series/119798/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:1

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Update AUX invalidation sequence (rev10)

== Series Details == Series: Update AUX invalidation sequence (rev10) URL : https://patchwork.freedesktop.org/series/119798/ State : warning == Summary == Error: dim checkpatch failed 59590392342a drm/i915/gt: Cleanup aux invalidation registers 0baf93afa6f5 drm/i915: Add the gen12_needs_ccs_au

[Intel-gfx] ✓ Fi.CI.BAT: success for Reduce MTL-specific platform checks (rev2)

== Series Details == Series: Reduce MTL-specific platform checks (rev2) URL : https://patchwork.freedesktop.org/series/120943/ State : success == Summary == CI Bug Log - changes from CI_DRM_13418 -> Patchwork_120943v2 Summary --- **S

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Reduce MTL-specific platform checks (rev2)

== Series Details == Series: Reduce MTL-specific platform checks (rev2) URL : https://patchwork.freedesktop.org/series/120943/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Reduce MTL-specific platform checks (rev2)

== Series Details == Series: Reduce MTL-specific platform checks (rev2) URL : https://patchwork.freedesktop.org/series/120943/ State : warning == Summary == Error: dim checkpatch failed 270297a58c66 drm/i915: Consolidate condition for Wa_22011802037 e464ca89ccdb drm/i915/xelpmp: Don't assume w

[Intel-gfx] [PATCH v9 7/7] drm/i915/gt: Support aux invalidation on all engines

Perform some refactoring with the purpose of keeping in one single place all the operations around the aux table invalidation. With this refactoring add more engines where the invalidation should be performed. Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines") Signed

[Intel-gfx] [PATCH v9 6/7] drm/i915/gt: Poll aux invalidation register bit on invalidation

From: Jonathan Cavitt For platforms that use Aux CCS, wait for aux invalidation to complete by checking the aux invalidation register bit is cleared. Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines") Signed-off-by: Jonathan Cavitt Signed-off-by: Andi Shyti Cc: #

[Intel-gfx] [PATCH v9 5/7] drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control and in the CS

Enable the CCS_FLUSH bit 13 in the control pipe for render and compute engines in platforms starting from Meteor Lake (BSPEC 43904 and 47112). For the copy engine add MI_FLUSH_DW_CCS (bit 16) in the command streamer. Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines")

[Intel-gfx] [PATCH v9 4/7] drm/i915/gt: Rename flags with bit_group_X according to the datasheet

In preparation of the next patch align with the datasheet (BSPEC 47112) with the naming of the pipe control set of flag values. The variable "flags" in gen12_emit_flush_rcs() is applied as a set of flags called Bit Group 1. Define also the Bit Group 0 as bit_group_0 where currently only PIPE_CONTR

[Intel-gfx] [PATCH v9 3/7] drm/i915/gt: Ensure memory quiesced before invalidation

From: Jonathan Cavitt All memory traffic must be quiesced before requesting an aux invalidation on platforms that use Aux CCS. Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines") Requires: a2a4aa0eef3b ("drm/i915: Add the gen12_needs_ccs_aux_inv helper") Signed-off-b

[Intel-gfx] [PATCH v9 2/7] drm/i915: Add the gen12_needs_ccs_aux_inv helper

We always assumed that a device might either have AUX or FLAT CCS, but this is an approximation that is not always true, e.g. PVC represents an exception. Set the basis for future finer selection by implementing a boolean gen12_needs_ccs_aux_inv() function that tells whether aux invalidation is ne

[Intel-gfx] [PATCH v9 1/7] drm/i915/gt: Cleanup aux invalidation registers

Fix the 'NV' definition postfix that is supposed to be INV. Take the chance to also order properly the registers based on their address and call the GEN12_GFX_CCS_AUX_INV address as GEN12_CCS_AUX_INV like all the other similar registers. Remove also VD1, VD3 and VE1 registers that don't exist and

[Intel-gfx] [PATCH v9 0/7] Update AUX invalidation sequence

Hi, as there are new hardware directives, we need a little adaptation for the AUX invalidation sequence. In this version we support all the engines affected by this change. The stable backport has some challenges because the original patch that this series fixes has had more changes in between.

[Intel-gfx] [PATCH v2 8/9] drm/i915/display: Eliminate IS_METEORLAKE checks

Most of the IS_METEORLAKE checks in the display code shouldn't actually be tied to MTL as a platform, but rather to the Xe_LPD+ display IP (which is used in MTL, but may show up again in future platforms). In cases where we're trying to match that specific IP, use a version check against IP_VER(14

[Intel-gfx] [PATCH v2 2/9] drm/i915/xelpmp: Don't assume workarounds extend to future platforms

The currently implemented Xe_LPM+ workarounds are specific to media version 13.00. When new IP versions show up in the future, they'll need their own workaround lists. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletion

[Intel-gfx] [PATCH v2 9/9] drm/i915: Replace several IS_METEORLAKE with proper IP version checks

Many of the IS_METEORLAKE conditions throughout the driver are supposed to be checks for Xe_LPG and/or Xe_LPM+ IP, not for the MTL platform specifically. Update those checks to ensure that the code will still operate properly if/when these IP versions show up on future platforms. v2: - Add comme

[Intel-gfx] [PATCH v2 1/9] drm/i915: Consolidate condition for Wa_22011802037

The workaround bounds for Wa_22011802037 are somewhat complex and are replicated in several places throughout the code. Pull the condition out to a helper function to prevent mistakes if this condition needs to change again in the future. Signed-off-by: Matt Roper Reviewed-by: Gustavo Sousa ---

[Intel-gfx] [PATCH v2 5/9] drm/i915: Eliminate IS_MTL_MEDIA_STEP

Stepping-specific media behavior shouldn't be tied to MTL as a platform, but rather specifically to the Xe_LPM+ IP. Future non-MTL platforms may re-use this IP and will need to follow the exact same logic and apply the same workarounds. IS_MTL_MEDIA_STEP() is dropped in favor of IS_GT_IP_STEP, wh

[Intel-gfx] [PATCH v2 3/9] drm/i915/xelpg: Call Xe_LPG workaround functions based on IP version

Although some of our Xe_LPG workarounds were already being applied based on IP version correctly, others were matching on MTL as a base platform, which is incorrect. Although MTL is the only platform right now that uses Xe_LPG IP, this may not always be the case. If a future platform re-uses this

[Intel-gfx] [PATCH v2 4/9] drm/i915: Eliminate IS_MTL_GRAPHICS_STEP

Several workarounds are guarded by IS_MTL_GRAPHICS_STEP. However none of these workarounds are actually tied to MTL as a platform; they only relate to the Xe_LPG graphics IP, regardless of what platform it appears in. At the moment MTL is the only platform that uses Xe_LPG with IP versions 12.70

[Intel-gfx] [PATCH v2 7/9] drm/i915/mtl: Eliminate subplatforms

Now that we properly match the Xe_LPG IP versions associated with various workarounds, there's no longer any need to define separate MTL subplatform in the driver. Nothing in the code is conditional on MTL-M or MTL-P base platforms. Furthermore, I'm not sure the "M" and "P" designations are even

[Intel-gfx] [PATCH v2 6/9] drm/i915: Eliminate IS_MTL_DISPLAY_STEP

Stepping-specific display behavior shouldn't be tied to MTL as a platform, but rather specifically to the Xe_LPD+ IP. Future non-MTL platforms may re-use this IP and will need to follow the exact same logic and apply the same workarounds. IS_MTL_DISPLAY_STEP() is dropped in favor of a new macro I

[Intel-gfx] [PATCH v2 0/9] Reduce MTL-specific platform checks

Starting with MTL, the hardware moved to a disaggregated IP design where graphics, media, and display are supposed to be treated independently of the base platform that they're incorporated into. For driver logic that is conditional on these IPs, the code should be checking the IP versions (as rea

Re: [Intel-gfx] [PATCH 3/8] drm/i915: Eliminate IS_MTL_GRAPHICS_STEP

On Thu, Jul 20, 2023 at 03:10:21PM +0200, Andrzej Hajda wrote: > On 20.07.2023 11:36, Tvrtko Ursulin wrote: > > > > On 19/07/2023 23:54, Matt Roper wrote: > > > On Wed, Jul 19, 2023 at 08:28:12AM -0700, Matt Roper wrote: > > > > On Wed, Jul 19, 2023 at 09:01:58AM +0100, Tvrtko Ursulin wrote: > > >

Re: [Intel-gfx] [PATCH] drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap

Hi Tvrtko, The changes makes sense and based on the description looks good. I am bit skeptical about the exec buffer failure reported by ci hence, withholding the r-b for now. If you believe the CI failure is unrelated please feel free to add my r-b. On a side note on platforms with non-coherent

Re: [Intel-gfx] [PATCH v3] drm/i915: Avoid circular locking dependency when flush delayed work on gt reset

On 6/15/2023 14:15, Zhanjun Dong wrote: This attempts to avoid circular locking dependency between flush delayed work and intel_gt_reset. Switched from cancel_delayed_work_sync to cancel_delayed_work, the non-sync version for reset path, it is safe as the worker has the trylock code to handle

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Use full allocated minor range for DRM (rev3)

== Series Details == Series: drm: Use full allocated minor range for DRM (rev3) URL : https://patchwork.freedesktop.org/series/108206/ State : success == Summary == CI Bug Log - changes from CI_DRM_13417 -> Patchwork_108206v3 Summary --

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Use full allocated minor range for DRM (rev3)

== Series Details == Series: drm: Use full allocated minor range for DRM (rev3) URL : https://patchwork.freedesktop.org/series/108206/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] [PATCH v6 4/4] drm: Introduce force_extended_minors modparam

While there is support for >64 DRM devices on kernel side, existing userspace may still have some hardcoded assumptions and it's possible that it will require changes to be able to use more than 64 devices. Add a modparam to simplify testing and development of >64 devices support on userspace side

[Intel-gfx] [PATCH v6 3/4] drm: Expand max DRM device number to full MINORBITS

Having a limit of 64 DRM devices is not good enough for modern world where we have multi-GPU servers, SR-IOV virtual functions and virtual devices used for testing. Let's utilize full minor range for DRM devices. To avoid regressing the existing userspace, we're still maintaining the numbering sche

[Intel-gfx] [PATCH v6 2/4] accel: Use XArray instead of IDR for minors

Accel minor management is based on DRM (and is also using struct drm_minor internally), since DRM is using XArray for minors, it makes sense to also convert accel. As the two implementations are identical (only difference being the underlying xarray), move the accel_minor_* functionality to DRM. S

[Intel-gfx] [PATCH v6 1/4] drm: Use XArray instead of IDR for minors

IDR is deprecated, and since XArray manages its own state with internal locking, it simplifies the locking on DRM side. Additionally, don't use the IRQ-safe variant, since operating on drm minor is not done in IRQ context. Signed-off-by: Michał Winiarski Suggested-by: Matthew Wilcox --- drivers

[Intel-gfx] [PATCH v6 0/4] drm: Use full allocated minor range for DRM

64 DRM device nodes is not enough for everyone. Upgrade it to ~512K (which definitely is more than enough). To allow testing userspace support for >64 devices, add additional DRM modparam (force_extended_minors) which causes DRM to skip allocating minors in 0-192 range. Additionally - convert mino

Re: [Intel-gfx] [PATCH] drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap

Hi Tvrtko, On Mon, Jul 24, 2023 at 01:56:33PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Commit 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is available") > added a code path which does not map via GGTT, but was still setting the > ggtt write bit, and so triggering the G

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap

== Series Details == Series: drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap URL : https://patchwork.freedesktop.org/series/121236/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13413_full -> Patchwork_121236v1_full ===

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: update request engine before removing virtual GuC engine

On 7/19/2023 05:43, Tvrtko Ursulin wrote: On 19/07/2023 11:41, Andrzej Hajda wrote: On 18.07.2023 17:48, Tvrtko Ursulin wrote: On 17/07/2023 19:03, John Harrison wrote: On 7/13/2023 05:11, Tvrtko Ursulin wrote: On 13/07/2023 12:09, Andrzej Hajda wrote: Hi, On 13.07.2023 09:39, Tvrtko Ursuli

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Tidy for_each_set_bit usage with abox_regs (rev2)

== Series Details == Series: drm/i915: Tidy for_each_set_bit usage with abox_regs (rev2) URL : https://patchwork.freedesktop.org/series/121233/ State : success == Summary == CI Bug Log - changes from CI_DRM_13417 -> Patchwork_121233v2 Summa

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Use the i915_vma_flush_writes helper (rev2)

== Series Details == Series: drm/i915: Use the i915_vma_flush_writes helper (rev2) URL : https://patchwork.freedesktop.org/series/121122/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13413_full -> Patchwork_121122v2_full S

Re: [Intel-gfx] [PATCH v15 00/26] Add vfio_device cdev for iommufd support

On Tue, 18 Jul 2023 13:57:46 -0300 Jason Gunthorpe wrote: > On Tue, Jul 18, 2023 at 06:55:25AM -0700, Yi Liu wrote: > > Existing VFIO provides group-centric user APIs for userspace. Userspace > > opens the /dev/vfio/$group_id first before getting device fd and hence > > getting access to device.

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v3,1/1] drm/i915: Move abs_diff() to math.h

== Series Details == Series: series starting with [v3,1/1] drm/i915: Move abs_diff() to math.h URL : https://patchwork.freedesktop.org/series/121218/ State : success == Summary == CI Bug Log - changes from CI_DRM_13413_full -> Patchwork_121218v1_full ===

Re: [Intel-gfx] [PATCH v2] drm/i915/tv: avoid possible division by zero

On Tue, Jul 18, 2023 at 09:32:17AM +0800, Su Hui wrote: > Clang warning: drivers/gpu/drm/i915/display/intel_tv.c: > line 991, column 22 Division by zero. > Assuming tv_mode->oversample=1 and (!tv_mode->progressive)=1, > then division by zero will happen. > > Fixes: 1bba5543e4fe ("drm/i915: Fix TV

Re: [Intel-gfx] [PATCH] drm/i915: Fix an error handling path in igt_write_huge()

Hi Christophe, > All error handling paths go to 'out', except this one. Be consistent and > also branch to 'out' here. > > Fixes: c10a652e239e ("drm/i915/selftests: Rework context handling in > hugepages selftests") > Signed-off-by: Christophe JAILLET Pushed to drm-intel-gt-next. Thanks, Andi

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix an error handling path in igt_write_huge()

Hi, > Possible new issues > > Here are the unknown changes that may have been introduced in > Patchwork_120867v1_full: > > IGT changes > > Possible regressions > > • igt@gem_mmap_wc@write-gtt-read-wc: > □ shard-snb: PASS -> ABORT This failure looks unrelated. Andi

Re: [Intel-gfx] [PATCH] drm/i915: Fix an error handling path in igt_write_huge()

Hi Christophe, On Mon, Jul 17, 2023 at 08:49:31PM +0200, Christophe JAILLET wrote: > All error handling paths go to 'out', except this one. Be consistent and > also branch to 'out' here. > > Fixes: c10a652e239e ("drm/i915/selftests: Rework context handling in > hugepages selftests") > Signed-off

Re: [Intel-gfx] [PATCH v2] drm/i915: use direct alias for i915 in requests

On 20.07.2023 13:30, Andrzej Hajda wrote: i915_request contains direct alias to i915, there is no point to go via rq->engine->i915. v2: added missing rq.i915 initialization in measure_breadcrumb_dw. Signed-off-by: Andrzej Hajda Reviewed-by: Tvrtko Ursulin Acked-by: Nirmoy Das Pushed to

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap

== Series Details == Series: drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap URL : https://patchwork.freedesktop.org/series/121236/ State : success == Summary == CI Bug Log - changes from CI_DRM_13413 -> Patchwork_121236v1 =

Re: [Intel-gfx] [PATCH v8 9/9] drm/i915/gt: Support aux invalidation on all engines

Hi Andrzej, On Mon, Jul 24, 2023 at 11:42:16AM +0200, Andrzej Hajda wrote: > On 21.07.2023 18:15, Andi Shyti wrote: > > Perform some refactoring with the purpose of keeping in one > > single place all the operations around the aux table > > invalidation. > > > > With this refactoring add more eng

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap

== Series Details == Series: drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap URL : https://patchwork.freedesktop.org/series/121236/ State : warning == Summary == Error: dim checkpatch failed a0f6a851fb14 drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iom

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Tidy for_each_set_bit usage with abox_regs

== Series Details == Series: drm/i915: Tidy for_each_set_bit usage with abox_regs URL : https://patchwork.freedesktop.org/series/121233/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13413 -> Patchwork_121233v1 Summary

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use the i915_vma_flush_writes helper (rev2)

== Series Details == Series: drm/i915: Use the i915_vma_flush_writes helper (rev2) URL : https://patchwork.freedesktop.org/series/121122/ State : success == Summary == CI Bug Log - changes from CI_DRM_13413 -> Patchwork_121122v2 Summary ---

Re: [Intel-gfx] [PATCH v2] drm/i915/dpt: Use shmem for dpt objects

On 22/07/2023 00:54, Sripada, Radhakrishna wrote: Hi Tvrtko, -Original Message- From: Tvrtko Ursulin Sent: Friday, July 21, 2023 1:17 AM To: Sripada, Radhakrishna ; Yang, Fei ; intel-gfx@lists.freedesktop.org Cc: sta...@vger.kernel.org; Ville Syrjälä ; Wilson, Chris P Subject: Re:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/1] drm/i915: Move abs_diff() to math.h

== Series Details == Series: series starting with [v3,1/1] drm/i915: Move abs_diff() to math.h URL : https://patchwork.freedesktop.org/series/121218/ State : success == Summary == CI Bug Log - changes from CI_DRM_13413 -> Patchwork_121218v1

[Intel-gfx] [PATCH] drm/i915: Avoid GGTT flushing on non-GGTT paths of i915_vma_pin_iomap

From: Tvrtko Ursulin Commit 4bc91dbde0da ("drm/i915/lmem: Bypass aperture when lmem is available") added a code path which does not map via GGTT, but was still setting the ggtt write bit, and so triggering the GGTT flushing. Fix it by not setting that bit unless the GGTT mapping path was used, a

Re: [Intel-gfx] [PATCH v3 0/9] PCI/VGA: Improve the default VGA device selection

Hi, On 2023/7/20 03:32, Bjorn Helgaas wrote: "drm/loongson: Add an implement for ..." also solves a problem, but it lacks a commit log, so I don't know what the problem is. I have already telling you one yeas ago. I want remove the pci_fixup_vgadev() function in arch/loongarch/pci/pci.c I

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v3,1/1] drm/i915: Move abs_diff() to math.h

== Series Details == Series: series starting with [v3,1/1] drm/i915: Move abs_diff() to math.h URL : https://patchwork.freedesktop.org/series/121218/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

Re: [Intel-gfx] [PR] GuC 70.8 for MTL and DG2 + HuC 8.5.1 for MTL

Pulled and pushed out. josh On Thu, Jul 20, 2023 at 1:35 PM Daniele Ceraolo Spurio wrote: > > The following changes since commit d3f66064cf43bd7338a79174bd0ff60c4ecbdf6d: > > Partially revert "amdgpu: DMCUB updates for DCN 3.1.4 and 3.1.5" > (2023-07-07 15:24:32 -0400) > > are available in th

Re: [Intel-gfx] [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection

Hi, Thanks for you noticed my change. On 2023/7/20 03:32, Bjorn Helgaas wrote: @@ -1509,13 +1543,24 @@ static int pci_notify(struct notifier_block *nb, unsigned long action, * cases of hotplugable vga cards. */ - if (action == BUS_NOTIFY_ADD_DEVICE) + switch (acti

Re: [Intel-gfx] [PATCH 05/19] drm/i915/dp: Update Bigjoiner interface bits for computing compressed bpp

Hi Stan, Thanks for the reviews ans suggestions. Please my response inline: On 7/20/2023 2:59 PM, Lisovskiy, Stanislav wrote: On Thu, Jul 13, 2023 at 04:03:32PM +0530, Ankit Nautiyal wrote: In Bigjoiner check for DSC, bigjoiner interface bits for DP for DISPLAY > 13 is 36 (Bspec: 49259). v2:

Re: [Intel-gfx] [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection

Hi, On 2023/7/20 03:32, Bjorn Helgaas wrote: 2) It does not take the PCI Bar may get relocated into consideration. 3) It is not effective for the PCI device without a dedicated VRAM Bar. 4) It is device-agnostic, thus it has to waste the effort to iterate all of the PCI Bar to find the VRAM

Re: [Intel-gfx] [PATCH v3 4/9] PCI/VGA: Improve the default VGA device selection

Hi, I was too hurry reply to you. I'm may miss the point for part of your reviews, Sorry. On 2023/7/20 03:32, Bjorn Helgaas wrote: CONFIG_DRM_AST is a tristate. We're talking about identifying the boot-time console device. Yes, my patch will only works *after* the module gets loaded succ

[Intel-gfx] [PATCH] drm/i915: Tidy for_each_set_bit usage with abox_regs

From: Tvrtko Ursulin For_each_set_bit wants the max number of bits to walk and not the byte storage size of the source field. In this case there is no bug since abox_mask can mostly contain bits 0-2. Another funny thing is that both sizeof(abox_mask), where abox_mask is unsigned long, and BITS_

Re: [Intel-gfx] [PATCH dii-client 1/2] drm/i915: Make i915_coherent_map_type GT-centric

On 21/07/2023 15:05, Jonathan Cavitt wrote: Refactor i915_coherent_map_type to be GT-centric rather than device-centric. Each GT may require different coherency handling due to hardware workarounds. Suggested-by: Matt Roper Signed-off-by: Jonathan Cavitt --- drivers/gpu/drm/i915/display/i

Re: [Intel-gfx] [PATCH dii-client 2/2] drm/i915/gt: Apply workaround 22016122933 correctly

On 21/07/2023 15:05, Jonathan Cavitt wrote: WA_22016122933 was recently applied to all MeteorLake engines, which is simultaneously too broad (should only apply to Media engines) and too specific (should apply to all platforms that use the same media engine as MeteorLake). Correct this in cases

Re: [Intel-gfx] [PATCH v8 9/9] drm/i915/gt: Support aux invalidation on all engines

On 21.07.2023 18:15, Andi Shyti wrote: Perform some refactoring with the purpose of keeping in one single place all the operations around the aux table invalidation. With this refactoring add more engines where the invalidation should be performed. Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux

Re: [Intel-gfx] [PATCH v8 6/9] drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single function

Hi Andi On 7/24/2023 11:16 AM, Andi Shyti wrote: Hi Nirmoy, static int mtl_dummy_pipe_control(struct i915_request *rq) { /* Wa_14016712196 */ if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) || - IS_MTL_GRAPHICS_STEP(rq->engin

Re: [Intel-gfx] [PATCH v8 7/9] drm/i915/gt: Ensure memory quiesced before invalidation for all engines

On 24.07.2023 11:14, Andi Shyti wrote: Hi Andrzej, intel_engine_mask_t aux_inv = 0; - u32 cmd, *cs; + u32 cmd_flush = 0; + u32 cmd = 4; + u32 *cs; - cmd = 4; - if (mode & EMIT_INVALIDATE) { + if (mode & EMIT_INVALIDATE) cmd +=

Re: [Intel-gfx] [PATCH v8 6/9] drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single function

Hi Nirmoy, > static int mtl_dummy_pipe_control(struct i915_request *rq) > { > /* Wa_14016712196 */ > if (IS_MTL_GRAPHICS_STEP(rq->engine->i915, M, STEP_A0, STEP_B0) || > - IS_MTL_GRAPHICS_STEP(rq->engine->i915, P, STEP_A0, STEP_B0)) { > -

Re: [Intel-gfx] [PATCH v8 7/9] drm/i915/gt: Ensure memory quiesced before invalidation for all engines

Hi Andrzej, > > intel_engine_mask_t aux_inv = 0; > > - u32 cmd, *cs; > > + u32 cmd_flush = 0; > > + u32 cmd = 4; > > + u32 *cs; > > - cmd = 4; > > - if (mode & EMIT_INVALIDATE) { > > + if (mode & EMIT_INVALIDATE) > > cmd += 2; > > - if (gen12_needs_ccs_aux_i

Re: [Intel-gfx] [PATCH v8 6/9] drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single function

Hi  Andi, On 7/21/2023 6:15 PM, Andi Shyti wrote: Just a trivial refactoring for reducing the number of code duplicate. This will come at handy in the next commits. Meantime, propagate the error to the above layers if we fail to emit the pipe control. Signed-off-by: Andi Shyti Cc: # v5.8+ ---

Re: [Intel-gfx] [PATCH v8 5/9] drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control

On 7/21/2023 6:15 PM, Andi Shyti wrote: Enable the CCS_FLUSH bit 13 in the control pipe for render and compute engines in platforms starting from Meteor Lake (BSPEC 43904 and 47112). Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines") Signed-off-by: Andi Shyti Cc: J

Re: [Intel-gfx] [PATCH v8 2/9] drm/i915: Add the gen12_needs_ccs_aux_inv helper

On 7/21/2023 6:15 PM, Andi Shyti wrote: We always assumed that a device might either have AUX or FLAT CCS, but this is an approximation that is not always true, e.g. PVC represents an exception. Set the basis for future finer selection by implementing a boolean gen12_needs_ccs_aux_inv() functio

Re: [Intel-gfx] [PATCH v3 1/1] drm/i915: Move abs_diff() to math.h

On Mo, 2023-07-24 at 11:25 +0300, Andy Shevchenko wrote: > abs_diff() belongs to math.h. Move it there. > This will allow others to use it. > > Signed-off-by: Andy Shevchenko > Reviewed-by: Jiri Slaby # tty/serial Reviewed-by: Philipp Zabel # gpu/ipu-v3 regards Philipp

[Intel-gfx] [PATCH v3 1/1] drm/i915: Move abs_diff() to math.h

abs_diff() belongs to math.h. Move it there. This will allow others to use it. Signed-off-by: Andy Shevchenko Reviewed-by: Jiri Slaby # tty/serial --- v3: added tag (Jiri), removed space after a cast (fdo CI) drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 1 + drivers/gpu/drm/i915/display/int

Re: [Intel-gfx] [PATCH v8 7/9] drm/i915/gt: Ensure memory quiesced before invalidation for all engines

On 21.07.2023 18:15, Andi Shyti wrote: Commit af9e423a8aae ("drm/i915/gt: Ensure memory quiesced before invalidation") has made sure that the memory is quiesced before invalidating the AUX CCS table. Do it for all the other engines and not just RCS. Signed-off-by: Andi Shyti Cc: Jonathan Cav

Re: [Intel-gfx] [PATCH v8 6/9] drm/i915/gt: Refactor intel_emit_pipe_control_cs() in a single function

On 21.07.2023 18:15, Andi Shyti wrote: Just a trivial refactoring for reducing the number of code duplicate. This will come at handy in the next commits. Meantime, propagate the error to the above layers if we fail to emit the pipe control. Signed-off-by: Andi Shyti Cc: # v5.8+ Reviewed-

Re: [Intel-gfx] [PATCH v8 5/9] drm/i915/gt: Enable the CCS_FLUSH bit in the pipe control

On 21.07.2023 18:15, Andi Shyti wrote: Enable the CCS_FLUSH bit 13 in the control pipe for render and compute engines in platforms starting from Meteor Lake (BSPEC 43904 and 47112). Fixes: 972282c4cf24 ("drm/i915/gen12: Add aux table invalidate for all engines") Signed-off-by: Andi Shyti Cc:

Re: [Intel-gfx] [PATCH v8 2/9] drm/i915: Add the gen12_needs_ccs_aux_inv helper

On 21.07.2023 18:15, Andi Shyti wrote: We always assumed that a device might either have AUX or FLAT CCS, but this is an approximation that is not always true, e.g. PVC represents an exception. Set the basis for future finer selection by implementing a boolean gen12_needs_ccs_aux_inv() functi

intel-gfx@lists.freedesktop.org

Hello, On Sat, Jul 22, 2023 at 03:22:35AM -, Patchwork wrote: > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_121164v1_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positiv