Re: [Intel-gfx] [PATCH] drm/i915/gt: Fix -EDEADLK handling regression

Op 30-06-2021 om 18:44 schreef Ville Syrjala: > From: Ville Syrjälä > > The conversion to ww mutexes failed to address the fence code which > already returns -EDEADLK when we run out of fences. Ww mutexes on > the other hand treat -EDEADLK as an internal errno value indicating > a need to restart

Re: [Intel-gfx] [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

On Wed, 30 Jun 2021 11:42:10 +0200 Werner Sembach wrote: > Am 30.06.21 um 10:21 schrieb Pekka Paalanen: > > On Tue, 29 Jun 2021 13:02:05 +0200 > > Werner Sembach wrote: > > > >> Am 28.06.21 um 19:03 schrieb Werner Sembach: > >>> Am 18.06.21 um 11:11 schrieb Werner Sembach: > Add a new

Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

On Wed, 30 Jun 2021 11:20:18 +0200 Werner Sembach wrote: > Am 30.06.21 um 10:41 schrieb Pekka Paalanen: > > > On Tue, 29 Jun 2021 13:39:18 +0200 > > Werner Sembach wrote: > > > >> Am 29.06.21 um 13:17 schrieb Pekka Paalanen: > >>> On Tue, 29 Jun 2021 08:12:54 + > >>> Simon Ser wrote: >

Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+

On Wed, 30 Jun 2021 11:58:25 -0700 John Harrison wrote: > On 6/30/2021 01:22, Martin Peres wrote: > > On 24/06/2021 10:05, Matthew Brost wrote: > >> From: Daniele Ceraolo Spurio > >> > >> Unblock GuC submission on Gen11+ platforms. > >> > >> Signed-off-by: Michal Wajdeczko > >> Signed-off-by:

Re: [Intel-gfx] [PULL] drm-intel-next-fixes

On Wed, 30 Jun 2021, Rodrigo Vivi wrote: > On Wed, Jun 30, 2021 at 01:05:35PM +0300, Jani Nikula wrote: >> On Tue, 29 Jun 2021, Rodrigo Vivi wrote: >> > Hi Dave and Daniel, >> > >> > Here goes drm-intel-next-fixes-2021-06-29: >> > >> > The biggest fix is the restoration of mmap ioctl for gen12 in

[Intel-gfx] [PATCH v4 1/2] drm/i915: Use the correct IRQ during resume

The code in xcs_resume() probably didn't work as intended. It uses struct drm_device.irq, which is allocated to 0, but never initialized by i915 to the device's interrupt number. Change all calls to synchronize_hardirq() to intel_synchronize_irq(), which uses the correct interrupt. _hardirq() func

[Intel-gfx] [PATCH v4 0/2] drm/i915: IRQ fixes

Fix a bug in the usage of IRQs and cleanup references to the DRM IRQ midlayer. Preferably this patchset would be merged through drm-misc-next. v4: * switch IRQ code to intel_synchronize_irq() (Daniel) v3: * also use intel_synchronize_hardirq() from other callsite v2: * spl

[Intel-gfx] [PATCH v4 2/2] drm/i915: Drop all references to DRM IRQ midlayer

Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt functions directly. v2: * also remove an outdated comment * move IRQ fix into separate patch * update Fixes tag (Daniel) Signed-off-by: Thomas Zimmermann Fixes: b318b82455bd ("drm/i915: Nuke drm_drive

[Intel-gfx] [PATCH] drm/i915/display: check if compressed_llb was allocated

If we hit the error path here we unconditionally call i915_gem_stolen_remove_node, even though we only allocate the compressed_llb on older platforms. Therefore we should first check that we actually allocated the node before trying to remove it. References: https://gitlab.freedesktop.org/drm/inte

[Intel-gfx] [PULL] drm-misc-next-fixes

Hi Dave and Daniel, this week's PR for drm-misc-next-fixes contains a number of BO-related fixes in amdgpu, gma500 and radeon, and a documentation fix for dma-buf. Best regards Thomas drm-misc-next-fixes-2021-07-01: Short summary of fixes pull: * amdgpu: TTM fixes * dma-buf: Doc fixes * gma5

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: IRQ fixes (rev3)

== Series Details == Series: drm/i915: IRQ fixes (rev3) URL : https://patchwork.freedesktop.org/series/92053/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_ring_s

[Intel-gfx] [v3 1/2] drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable

From: Patnana Venkata Sai [What]: This patch creates a per connector debugfs node to expose the Input and Compressed BPP. The same node can be used from userspace to force DSC to a certain BPP(all accepted values). [Why]: Useful to verify all supported/requested compression bpp's through IGT C

[Intel-gfx] [v3 2/2] drm/i915/display/dsc: Set BPP in the kernel

From: Anusha Srivatsa Set compress BPP in kernel while connector DP or eDP Cc: Vandita Kulkarni Cc: Navare Manasi D Signed-off-by: Anusha Srivatsa Signed-off-by: Patnana Venkata Sai --- drivers/gpu/drm/i915/display/intel_dp.c | 23 ++- 1 file changed, 18 insertions(+), 5

[Intel-gfx] [v3 1/2] drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable

From: Patnana Venkata Sai [What]: This patch creates a per connector debugfs node to expose the Input and Compressed BPP. The same node can be used from userspace to force DSC to a certain BPP(all accepted values). [Why]: Useful to verify all supported/requested compression bpp's through IGT C

Re: [Intel-gfx] [PATCH 1/4] Klock work Fix for NULL dereferencing in i915_gem_ttm.c

On Mon, 28 Jun 2021 at 15:49, Bommu Krishnaiah wrote: > > Signed-off-by: Bommu Krishnaiah > Cc: Maarten Lankhorst > --- > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > b/drivers/gpu/drm/i915/gem/i915_g

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: IRQ fixes (rev3)

== Series Details == Series: drm/i915: IRQ fixes (rev3) URL : https://patchwork.freedesktop.org/series/92053/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10296 -> Patchwork_20502 Summary --- **FAILURE** Serious

Re: [Intel-gfx] [PATCH 1/4] Klock work Fix for NULL dereferencing in i915_gem_ttm.c

On Thu, 1 Jul 2021 at 10:39, Matthew Auld wrote: > > On Mon, 28 Jun 2021 at 15:49, Bommu Krishnaiah > wrote: > > > > Signed-off-by: Bommu Krishnaiah > > Cc: Maarten Lankhorst > > --- > > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/driv

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: IRQ fixes (rev3)

Am 01.07.21 um 11:43 schrieb Patchwork: *Patch Details* *Series:* drm/i915: IRQ fixes (rev3) *URL:* https://patchwork.freedesktop.org/series/92053/ *State:*failure *Details:* https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20

[Intel-gfx] [v4 0/2] drm/i915/display/dsc: Set BPP in the kernel

From: Patnana Venkata Sai DSC can be supported per DP connector. This patch creates a per connector debugfs node to expose the Input and Compressed BPP. The same node can be used from userspace to force DSC to a certain BPP. force_dsc_bpp is written through this debugfs node to force DSC BPP to

[Intel-gfx] [v4 1/2] drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable

From: Patnana Venkata Sai [What]: This patch creates a per connector debugfs node to expose the Input and Compressed BPP. The same node can be used from userspace to force DSC to a certain BPP(all accepted values). [Why]: Useful to verify all supported/requested compression bpp's through IGT v

[Intel-gfx] [v4 2/2] drm/i915/display/dsc: Set BPP in the kernel

From: Anusha Srivatsa Set compress BPP in kernel while connector DP or eDP Cc: Vandita Kulkarni Cc: Navare Manasi D Signed-off-by: Anusha Srivatsa Signed-off-by: Patnana Venkata Sai --- drivers/gpu/drm/i915/display/intel_dp.c | 23 ++- 1 file changed, 18 insertions(+), 5

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: check if compressed_llb was allocated

== Series Details == Series: drm/i915/display: check if compressed_llb was allocated URL : https://patchwork.freedesktop.org/series/92100/ State : success == Summary == CI Bug Log - changes from CI_DRM_10296 -> Patchwork_20503 Summary -

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display/dsc: Set BPP in the kernel (rev4)

== Series Details == Series: drm/i915/display/dsc: Set BPP in the kernel (rev4) URL : https://patchwork.freedesktop.org/series/91917/ State : warning == Summary == $ dim checkpatch origin/drm-tip e4fb01832beb drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable -:48: CHECK:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display/dsc: Set BPP in the kernel (rev4)

== Series Details == Series: drm/i915/display/dsc: Set BPP in the kernel (rev4) URL : https://patchwork.freedesktop.org/series/91917/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display: check if compressed_llb was allocated

== Series Details == Series: drm/i915/display: check if compressed_llb was allocated URL : https://patchwork.freedesktop.org/series/92100/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10296_full -> Patchwork_20503_full Sum

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display/dsc: Set BPP in the kernel (rev4)

== Series Details == Series: drm/i915/display/dsc: Set BPP in the kernel (rev4) URL : https://patchwork.freedesktop.org/series/91917/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10297 -> Patchwork_20504 Summary ---

Re: [Intel-gfx] [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property

Am 01.07.21 um 09:42 schrieb Pekka Paalanen: > On Wed, 30 Jun 2021 11:42:10 +0200 > Werner Sembach wrote: > >> Am 30.06.21 um 10:21 schrieb Pekka Paalanen: >>> On Tue, 29 Jun 2021 13:02:05 +0200 >>> Werner Sembach wrote: >>> Am 28.06.21 um 19:03 schrieb Werner Sembach: > Am 18.06.2

[Intel-gfx] [PATCH] drm/i915: Add TTM offset argument to mmap.

This is only used for ttm, and tells userspace that the mapping type is ignored. This disables the other type of mmap offsets when discrete memory is used, so fix the selftests as well. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 17 +++- .../gpu/

Re: [Intel-gfx] [PATCH] drm/i915: Add TTM offset argument to mmap.

Op 01-07-2021 om 13:42 schreef Maarten Lankhorst: > This is only used for ttm, and tells userspace that the mapping type is > ignored. This disables the other type of mmap offsets when discrete > memory is used, so fix the selftests as well. > > Signed-off-by: Maarten Lankhorst > --- > drivers/gp

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add TTM offset argument to mmap.

== Series Details == Series: drm/i915: Add TTM offset argument to mmap. URL : https://patchwork.freedesktop.org/series/92103/ State : warning == Summary == $ dim checkpatch origin/drm-tip 182e2988c2da drm/i915: Add TTM offset argument to mmap. -:61: WARNING:PREFER_FALLTHROUGH: Prefer 'fallthro

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Add TTM offset argument to mmap.

== Series Details == Series: drm/i915: Add TTM offset argument to mmap. URL : https://patchwork.freedesktop.org/series/92103/ State : success == Summary == CI Bug Log - changes from CI_DRM_10297 -> Patchwork_20505 Summary --- **SUCCE

Re: [Intel-gfx] [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing

Hi Will and Claire, On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote: > On Wed, Jun 30, 2021 at 05:17:27PM +0800, Claire Chang wrote: > > On Wed, Jun 30, 2021 at 9:43 AM Nathan Chancellor wrote: > > > > > > On Thu, Jun 24, 2021 at 11:55:20PM +0800, Claire Chang wrote: > > > > Propagate

Re: [Intel-gfx] [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing

On Wed, Jun 30, 2021 at 08:56:51AM -0700, Nathan Chancellor wrote: > On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote: > > On Wed, Jun 30, 2021 at 05:17:27PM +0800, Claire Chang wrote: > > > `BUG: unable to handle page fault for address: 003a8290` and > > > the fact it crashed at

Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

Am 01.07.21 um 10:07 schrieb Pekka Paalanen: > On Wed, 30 Jun 2021 11:20:18 +0200 > Werner Sembach wrote: > >> Am 30.06.21 um 10:41 schrieb Pekka Paalanen: >> >>> On Tue, 29 Jun 2021 13:39:18 +0200 >>> Werner Sembach wrote: >>> Am 29.06.21 um 13:17 schrieb Pekka Paalanen: > On Tue,

[Intel-gfx] [PATCH 0/3] lpsp with hdmi/dp outputs

This revision has fixed review comment from Imre on RFC patch. https://patchwork.freedesktop.org/series/90827/ Anshuman Gupta (3): drm/i915/dg1: Adjust the AUDIO power domain drm/i915/display: Use AUDIO_MMIO for crtc power domain mask drm/i915/audio: Use AUDIO_PLAYBACK power domain drivers

[Intel-gfx] [PATCH 0/3] lpsp with hdmi/dp outputs

This revision has fixed review comment from Imre on RFC patch. https://patchwork.freedesktop.org/series/90827/ Anshuman Gupta (3): drm/i915/dg1: Adjust the AUDIO power domain drm/i915/display: Use AUDIO_MMIO for crtc power domain mask drm/i915/audio: Use AUDIO_PLAYBACK power domain drivers

[Intel-gfx] [PATCH 2/3] drm/i915/display: Use AUDIO_MMIO for crtc power domain mask

Use POWER_DOMAIN_AUDIO_MMIO power domain instead of POWER_DOMAIN_AUDIO in crtc power domain mask. It will save the power in use cases when DP/HDMI connectors configured with PIPE_A without any audio playback. v1: Changes since RFC - changed power domain names. [Imre] Cc: Ville Syrjälä Cc: Kai V

[Intel-gfx] [PATCH 3/3] drm/i915/audio: Use AUDIO_PLAYBACK power domain

Use POWER_DOMAIN_AUDIO_PLAYBACK to enable/disable display audio codec power in intel_display_power_{get, put} v1: Changes since RFC - changed power domain names. [Imre] Cc: Kai Vehmanen Cc: Uma Shankar Signed-off-by: Anshuman Gupta --- drivers/gpu/drm/i915/display/intel_audio.c | 4 ++-- 1 fi

[Intel-gfx] [PATCH 1/3] drm/i915/dg1: Adjust the AUDIO power domain

DG1 and XE_PLD platforms has Audio MMIO/VERBS lies in PG0 power well. Adjusting the power domain accordingly to POWER_DOMAIN_AUDIO_VERBS for audio detection and POWER_DOMAIN_AUDIO for audio playback. v1: Changes since RFC - changed power domain names. [Imre] - Removed TC{3,6}, AUX_USBC{3,6} and TB

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for lpsp with hdmi/dp outputs

== Series Details == Series: lpsp with hdmi/dp outputs URL : https://patchwork.freedesktop.org/series/92108/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_di

Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace

On Thu, 1 Jul 2021 14:50:13 +0200 Werner Sembach wrote: > Am 01.07.21 um 10:07 schrieb Pekka Paalanen: > > > On Wed, 30 Jun 2021 11:20:18 +0200 > > Werner Sembach wrote: > > > >> Am 30.06.21 um 10:41 schrieb Pekka Paalanen: > >> > >>> On Tue, 29 Jun 2021 13:39:18 +0200 > >>> Werner Sembach

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add TTM offset argument to mmap.

== Series Details == Series: drm/i915: Add TTM offset argument to mmap. URL : https://patchwork.freedesktop.org/series/92103/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10297_full -> Patchwork_20505_full Summary ---

[Intel-gfx] ✓ Fi.CI.BAT: success for lpsp with hdmi/dp outputs

== Series Details == Series: lpsp with hdmi/dp outputs URL : https://patchwork.freedesktop.org/series/92108/ State : success == Summary == CI Bug Log - changes from CI_DRM_10297 -> Patchwork_20506 Summary --- **SUCCESS** No regres

[Intel-gfx] [PATCH 2/2] drm/i915/gem: Migrate to system at dma-buf attach time

From: Thomas Hellström Until we support p2p dma or as a complement to that, migrate data to system memory at dma-buf attach time if possible. v2: - Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver selftest to migrate if we are LMEM capable. v3: - Migrate also in the pin() c

[Intel-gfx] [PATCH 1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf

From: Thomas Hellström If our exported dma-bufs are imported by another instance of our driver, that instance will typically have the imported dma-bufs locked during dma_buf_map_attachment(). But the exporter also locks the same reservation object in the map_dma_buf() callback, which leads to rec

[Intel-gfx] [PATCH 1/3] drm/i915: use consistent CPU mappings for pin_map users

For discrete, users of pin_map() needs to obey the same rules at the TTM backend, where we map system only objects as WB, and everything else as WC. The simplest for now is to just force the correct mapping type as per the new rules for discrete. Suggested-by: Thomas Hellström Signed-off-by: Matt

[Intel-gfx] [PATCH 2/3] drm/i915/uapi: reject caching ioctls for discrete

It's a noop on DG1, and in the future when need to support other devices which let us control the coherency, then it should be an immutable creation time property for the BO. Suggested-by: Daniel Vetter Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Maarten Lankhorst Cc: Kenneth Graunke

[Intel-gfx] [PATCH 3/3] drm/i915/uapi: reject set_domain for discrete

The CPU domain should be static for discrete, and on DG1 we don't need any flushing since everything is already coherent, so really all this does is an object wait, for which we have an ioctl. Longer term the desired caching should be an immutable creation time property for the BO. One other user

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf

== Series Details == Series: series starting with [1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf URL : https://patchwork.freedesktop.org/series/92109/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtoo

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915: use consistent CPU mappings for pin_map users

== Series Details == Series: series starting with [1/3] drm/i915: use consistent CPU mappings for pin_map users URL : https://patchwork.freedesktop.org/series/92113/ State : warning == Summary == $ dim checkpatch origin/drm-tip 4a7bd95f84c8 drm/i915: use consistent CPU mappings for pin_map us

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915: use consistent CPU mappings for pin_map users

== Series Details == Series: series starting with [1/3] drm/i915: use consistent CPU mappings for pin_map users URL : https://patchwork.freedesktop.org/series/92113/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be ch

[Intel-gfx] [PATCH v2 1/3] drm/i915: use consistent CPU mappings for pin_map users

For discrete, users of pin_map() needs to obey the same rules at the TTM backend, where we map system only objects as WB, and everything else as WC. The simplest for now is to just force the correct mapping type as per the new rules for discrete. Suggested-by: Thomas Hellström Signed-off-by: Matt

[Intel-gfx] [PATCH v2 2/3] drm/i915/uapi: reject caching ioctls for discrete

It's a noop on DG1, and in the future when need to support other devices which let us control the coherency, then it should be an immutable creation time property for the BO. This will likely be controlled through a new gem_create_ext extension. Suggested-by: Daniel Vetter Signed-off-by: Matthew

[Intel-gfx] [PATCH v2 3/3] drm/i915/uapi: reject set_domain for discrete

The CPU domain should be static for discrete, and on DG1 we don't need any flushing since everything is already coherent, so really all this does is an object wait, for which we have an ioctl. Longer term the desired caching should be an immutable creation time property for the BO, which can be set

[Intel-gfx] ✗ Fi.CI.IGT: failure for lpsp with hdmi/dp outputs

== Series Details == Series: lpsp with hdmi/dp outputs URL : https://patchwork.freedesktop.org/series/92108/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10297_full -> Patchwork_20506_full Summary --- **FAILURE**

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: use consistent CPU mappings for pin_map users

== Series Details == Series: series starting with [1/3] drm/i915: use consistent CPU mappings for pin_map users URL : https://patchwork.freedesktop.org/series/92113/ State : success == Summary == CI Bug Log - changes from CI_DRM_10297 -> Patchwork_20508 ===

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/3] drm/i915: use consistent CPU mappings for pin_map users

== Series Details == Series: series starting with [v2,1/3] drm/i915: use consistent CPU mappings for pin_map users URL : https://patchwork.freedesktop.org/series/92114/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be

[Intel-gfx] [PATCH 1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf

From: Thomas Hellström If our exported dma-bufs are imported by another instance of our driver, that instance will typically have the imported dma-bufs locked during dma_buf_map_attachment(). But the exporter also locks the same reservation object in the map_dma_buf() callback, which leads to rec

[Intel-gfx] [PATCH 2/2] drm/i915/gem: Migrate to system at dma-buf attach time

From: Thomas Hellström Until we support p2p dma or as a complement to that, migrate data to system memory at dma-buf attach time if possible. v2: - Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver selftest to migrate if we are LMEM capable. v3: - Migrate also in the pin() c

[Intel-gfx] [PATCH 2/4] drm/i915/guc: Print error name on CTB (de)registration failure

Instead of plain error value (%d) print more user friendly error name (%pe). Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915

[Intel-gfx] [PATCH 1/4] drm/i915/guc: Verify result from CTB (de)register action

In commit b839a869dfc9 ("drm/i915/guc: Add support for data reporting in GuC responses") we missed the hypothetical case that GuC might return positive non-zero value as success data. While that would be lucky treated as error case, and at the end will result in reporting valid -EIO, in the meanti

[Intel-gfx] [PATCH 3/4] drm/i915/guc: Print error name on CTB send failure

Instead of plain error value (%d) print more user friendly error name (%pe). Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c b/drivers/gpu/drm/i915/gt/

[Intel-gfx] [PATCH 0/4] drm/i915/guc: Improve CTB error handling

There was a gap in handling MMIO result from CTB (de)registration and while fixing it improve some other error reports. Signed-off-by: Michal Wajdeczko Michal Wajdeczko (4): drm/i915/guc: Verify result from CTB (de)register action drm/i915/guc: Print error name on CTB (de)registration failur

[Intel-gfx] [PATCH 4/4] drm/i915/guc: Move and improve error message for missed CTB reply

If we timeout waiting for a CT reply we print very simple error message. Improve that and by moving error reporting to the caller we can use CT_ERROR instead of DRM_ERROR and report just fence as error code will be reported later anyway. Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/g

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915: use consistent CPU mappings for pin_map users

== Series Details == Series: series starting with [v2,1/3] drm/i915: use consistent CPU mappings for pin_map users URL : https://patchwork.freedesktop.org/series/92114/ State : success == Summary == CI Bug Log - changes from CI_DRM_10297 -> Patchwork_20509

[Intel-gfx] [PATCH] drm/i915/guc: Improve GuC CTB ABI

Make CTB Header explicit and separate from CTB Message. Signed-off-by: Michal Wajdeczko Cc: Matthew Brost --- .../gt/uc/abi/guc_communication_ctb_abi.h | 51 +++ drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 24 - 2 files changed, 43 insertions(+), 32 deletions(-)

[Intel-gfx] [PATCH 2/7] drm/i915/guc: Improve error message for unsolicited CT response

Improve the error message when a unsolicited CT response is received by printing fence that couldn't be found, the last fence, and all requests with a response outstanding. Signed-off-by: Matthew Brost Reviewed-by: Michal Wajdeczko --- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 10 +++---

[Intel-gfx] [PATCH 1/7] drm/i915/guc: Relax CTB response timeout

In upcoming patch we will allow more CTB requests to be sent in parallel to the GuC for processing, so we shouldn't assume any more that GuC will always reply without 10ms. Use bigger value hardcoded value of 1s instead. v2: Add CONFIG_DRM_I915_GUC_CTB_TIMEOUT config option v3: (Daniel Vetter)

[Intel-gfx] [PATCH 0/7] CT changes required for GuC submission

As part of enabling GuC submission discussed in [1], [2], and [3] we need optimize and update the CT code as this is now in the critical path of submission. This series includes the patches to do that which is the first 7 patches from [3]. The patches should have addressed all the feedback in [3] a

[Intel-gfx] [PATCH 4/7] drm/i915/guc: Add non blocking CTB send function

Add non blocking CTB send function, intel_guc_send_nb. GuC submission will send CTBs in the critical path and does not need to wait for these CTBs to complete before moving on, hence the need for this new function. The non-blocking CTB now must have a flow control mechanism to ensure the buffer is

[Intel-gfx] [PATCH 3/7] drm/i915/guc: Increase size of CTB buffers

With the introduction of non-blocking CTBs more than one CTB can be in flight at a time. Increasing the size of the CTBs should reduce how often software hits the case where no space is available in the CTB buffer. Cc: John Harrison Signed-off-by: Matthew Brost Reviewed-by: Michal Wajdeczko ---

[Intel-gfx] [PATCH 7/7] drm/i915/guc: Module load failure test for CT buffer creation

From: John Harrison Add several module failure load inject points in the CT buffer creation code path. Signed-off-by: John Harrison Signed-off-by: Matthew Brost Reviewed-by: Michal Wajdeczko --- drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8 1 file changed, 8 insertions(+) diff --g

[Intel-gfx] [PATCH 6/7] drm/i915/guc: Optimize CTB writes and reads

CTB writes are now in the path of command submission and should be optimized for performance. Rather than reading CTB descriptor values (e.g. head, tail) which could result in accesses across the PCIe bus, store shadow local copies and only read/write the descriptor values when absolutely necessary

[Intel-gfx] [PATCH 5/7] drm/i915/guc: Add stall timer to non blocking CTB send function

Implement a stall timer which fails H2G CTBs once a period of time with no forward progress is reached to prevent deadlock. v2: (Michal) - Improve error message in ct_deadlock() - Set broken when ct_deadlock() returns true - Return -EPIPE on ct_deadlock() v3: (Michal) - Add ms to stall t

Re: [Intel-gfx] [PATCH] drm/i915/gt: Fix -EDEADLK handling regression

On Thu, Jul 01, 2021 at 09:07:27AM +0200, Maarten Lankhorst wrote: > Op 30-06-2021 om 18:44 schreef Ville Syrjala: > > From: Ville Syrjälä > > > > The conversion to ww mutexes failed to address the fence code which > > already returns -EDEADLK when we run out of fences. Ww mutexes on > > the other

Re: [Intel-gfx] [PATCH] drm/i915/display: check if compressed_llb was allocated

On Thu, 2021-07-01 at 10:03 +0100, Matthew Auld wrote: > If we hit the error path here we unconditionally call > i915_gem_stolen_remove_node, even though we only allocate the > compressed_llb on older platforms. Therefore we should first check that > we actually allocated the node before trying to

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display/dg1: Correctly map DPLLs during state readout

On Thu, 2021-07-01 at 05:21 +, Patchwork wrote: Patch Details Series: drm/i915/display/dg1: Correctly map DPLLs during state readout URL:https://patchwork.freedesktop.org/series/92086/ State: failure Details: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20499/index.html CI Bu

[Intel-gfx] [PATCH v5 0/2] drm/i915: IRQ fixes

Fix a bug in the usage of IRQs and cleanup references to the DRM IRQ midlayer. Preferably this patchset would be merged through drm-misc-next. v5: * go back to _hardirq() after CI tests reported atomic context in PCI probe; add rsp comment v4: * switch IRQ code to intel_

[Intel-gfx] [PATCH v5 1/2] drm/i915: Use the correct IRQ during resume

The code in xcs_resume() probably didn't work as intended. It uses struct drm_device.irq, which is allocated to 0, but never initialized by i915 to the device's interrupt number. Change all calls to synchronize_hardirq() to intel_synchronize_irq(), which uses the correct interrupt. _hardirq() func

[Intel-gfx] [PATCH v5 2/2] drm/i915: Drop all references to DRM IRQ midlayer

Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt functions directly. v2: * also remove an outdated comment * move IRQ fix into separate patch * update Fixes tag (Daniel) Signed-off-by: Thomas Zimmermann Fixes: b318b82455bd ("drm/i915: Nuke drm_drive

Re: [Intel-gfx] [PATCH] drm/i915/display: check if compressed_llb was allocated

On Thu, Jul 01, 2021 at 10:03:26AM +0100, Matthew Auld wrote: > If we hit the error path here we unconditionally call > i915_gem_stolen_remove_node, even though we only allocate the > compressed_llb on older platforms. Therefore we should first check that > we actually allocated the node before try

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Use RUNTIME_INFO->stp for DMC

On Wed, Jun 30, 2021 at 05:17:52PM -0700, Lucas De Marchi wrote: On Wed, Jun 30, 2021 at 05:15:00PM -0700, Jose Souza wrote: On Wed, 2021-06-30 at 17:01 -0700, Lucas De Marchi wrote: Typo: RUNTIME_INFO->stp On Wed, Jun 30, 2021 at 04:06:24PM -0700, Anusha Srivatsa wrote: On the dmc side,we ma

[Intel-gfx] [PATCH v7 0/5] drm: address potential UAF bugs with drm_master ptrs

This patch series addresses potential use-after-free errors when dereferencing pointers to struct drm_master. These were identified after one such bug was caught by Syzbot in drm_getunique(): https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803 The series is broken up in

[Intel-gfx] [PATCH v7 1/5] drm: avoid circular locks in drm_mode_getconnector

In preparation for a future patch to take a lock on drm_device.master_mutex inside drm_is_current_master(), we first move the call to drm_is_current_master() in drm_mode_getconnector out from the section locked by &dev->mode_config.mutex. This avoids creating a circular lock dependency. Failing to

[Intel-gfx] [PATCH v7 5/5] drm: protect drm_master pointers in drm_lease.c

drm_file->master pointers should be protected by drm_device.master_mutex or drm_file.master_lock when being dereferenced. However, in drm_lease.c, there are multiple instances where drm_file->master is accessed and dereferenced while neither lock is held. This makes drm_lease.c vulnerable to use-a

[Intel-gfx] [PATCH v7 4/5] drm: serialize drm_file.master with a master lock

Currently, drm_file.master pointers should be protected by drm_device.master_mutex when being dereferenced. This is because drm_file.master is not invariant for the lifetime of drm_file. If drm_file is not the creator of master, then drm_file.is_master is false, and a call to drm_setmaster_ioctl wi

[Intel-gfx] [PATCH v7 2/5] drm: separate locks in __drm_mode_object_find

In a future patch, _drm_lease_held will dereference drm_file->master only after making a call to drm_file_get_master. This will increment the reference count of drm_file->master while holding onto a new drm_file.master_lock. In preparation for this, the call to _drm_lease_held should be moved out

Re: [Intel-gfx] [Mesa-dev] Requests For Proposals for hosting XDC 2022 are now open

This is a reminder that the call for proposals for hosting XDC 2022 period finishes in two months. Be sure to prepare your submission before you leave on holiday! Sam On Thu, 2021-05-20 at 12:15 +0200, Samuel Iglesias Gonsálvez wrote: > Hello everyone! > > The X.org board is soliciting proposal

[Intel-gfx] [PATCH v7 3/5] drm: add a locked version of drm_is_current_master

While checking the master status of the DRM file in drm_is_current_master(), the device's master mutex should be held. Without the mutex, the pointer fpriv->master may be freed concurrently by another process calling drm_setmaster_ioctl(). This could lead to use-after-free errors when the pointer i

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915: use consistent CPU mappings for pin_map users

== Series Details == Series: series starting with [1/3] drm/i915: use consistent CPU mappings for pin_map users URL : https://patchwork.freedesktop.org/series/92113/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10297_full -> Patchwork_20508_full =

Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+

On 30/06/2021 21:00, Matthew Brost wrote: On Wed, Jun 30, 2021 at 11:22:38AM +0300, Martin Peres wrote: On 24/06/2021 10:05, Matthew Brost wrote: From: Daniele Ceraolo Spurio Unblock GuC submission on Gen11+ platforms. Signed-off-by: Michal Wajdeczko Signed-off-by: Daniele Ceraolo Spurio

Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+

On 01/07/2021 11:14, Pekka Paalanen wrote: On Wed, 30 Jun 2021 11:58:25 -0700 John Harrison wrote: On 6/30/2021 01:22, Martin Peres wrote: On 24/06/2021 10:05, Matthew Brost wrote: From: Daniele Ceraolo Spurio Unblock GuC submission on Gen11+ platforms. Signed-off-by: Michal Wajdeczko Si

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v2,1/3] drm/i915: use consistent CPU mappings for pin_map users

== Series Details == Series: series starting with [v2,1/3] drm/i915: use consistent CPU mappings for pin_map users URL : https://patchwork.freedesktop.org/series/92114/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10297_full -> Patchwork_20509_full ==

Re: [Intel-gfx] [PATCH 1/1] drm/i915/dg1: Compute MEM Bandwidth using MCHBAR

On Wed, 2021-06-30 at 21:06 -0700, Lucas De Marchi wrote: > From: Clint Taylor > > The PUNIT FW is currently returning 0 for all memory bandwidth > parameters. Read the values directly from MCHBAR offsets 0x5918 and > 0x4000(4). > > v2 (Lucas): tidy up checking for ret slightly > v3 (Lucas): >

Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+

On Thu, Jul 1, 2021 at 8:27 PM Martin Peres wrote: > > On 01/07/2021 11:14, Pekka Paalanen wrote: > > On Wed, 30 Jun 2021 11:58:25 -0700 > > John Harrison wrote: > > > >> On 6/30/2021 01:22, Martin Peres wrote: > >>> On 24/06/2021 10:05, Matthew Brost wrote: > From: Daniele Ceraolo Spurio >

Re: [Intel-gfx] [PULL] drm-intel-next-fixes

On Thu, Jul 01, 2021 at 11:57:53AM +0300, Jani Nikula wrote: > On Wed, 30 Jun 2021, Rodrigo Vivi wrote: > > On Wed, Jun 30, 2021 at 01:05:35PM +0300, Jani Nikula wrote: > >> On Tue, 29 Jun 2021, Rodrigo Vivi wrote: > >> > Hi Dave and Daniel, > >> > > >> > Here goes drm-intel-next-fixes-2021-06-29

[Intel-gfx] [PATCH 0/2] Stepping/substepping reorg for DMC

This series addresses the following: 1. Add missing stepping/substepping info for all platforms. 2. Use RUNTIME_INFO->step to grab the actual stepping info for a platform instead of having separate lookup tables for each platform on DMC side. Anusha Srivatsa (2): drm/i915/dmc: Use RUNTIME_INFO->

[Intel-gfx] [PATCH 2/2] drm/i915/dmc: Add steping info table for remaining platforms

intel_step.c has stepping_info for most platforms. With DMC using display_step from here, lets add the info for all older platforms as well Cc: Lucas De Marchi Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/intel_step.c | 28 1 file changed, 28 insertions(

[Intel-gfx] [PATCH 1/2] drm/i915/dmc: Use RUNTIME_INFO->step for DMC

On the dmc side,we maintain a lookup table with different display stepping-substepping combinations. Instead of adding new table for every new platform, lets ues the stepping info from RUNTIME_INFO(dev_priv)->step v2: Add stepping table for older platforms in intel_step.c (Lucas) Cc: Lucas De Ma

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf

== Series Details == Series: series starting with [1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf URL : https://patchwork.freedesktop.org/series/92117/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10299 -> Patchwork_20510 =

  1   2   >