[Intel-gfx] [PATCH] drm: use drm_dev_has_vblank more

For historical reasons it's called dev->num_crtcs, which is rather confusing ever since kms was added. But now we have a nice helper, so let's use it for better readability! Only code change is in atomic helpers: vblank support means that dev->irq_enabled must be set too. Another one of these

Re: [Intel-gfx] [PATCH] drm/atomic-helper: reset vblank on crtc reset

On Wed, May 27, 2020 at 2:08 PM Liviu Dudau wrote: > > On Wed, May 27, 2020 at 01:07:05PM +0200, Daniel Vetter wrote: > > On Wed, May 27, 2020 at 12:57 PM Liviu Dudau wrote: > > > > > > Hi Daniel, > > > > > > On Wed, May 27, 2020 at 11:53:32AM +0200, Daniel Vetter wrote: > > > > Only when

Re: [Intel-gfx] [PATCH] drm/i915/display: Fix the encoder type check

> -Original Message- > From: Intel-gfx On Behalf Of Vandita > Kulkarni > Sent: Monday, May 4, 2020 1:19 PM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH] drm/i915/display: Fix the encoder type check > > For all ddi, encoder->type holds output type as ddi,

[Intel-gfx] ✓ Fi.CI.BAT: success for i915: Add debugfs for requesting HDCP version

== Series Details == Series: i915: Add debugfs for requesting HDCP version URL : https://patchwork.freedesktop.org/series/77693/ State : success == Summary == CI Bug Log - changes from CI_DRM_8542 -> Patchwork_17785 Summary ---

Re: [Intel-gfx] [PATCH] drm/atomic-helper: reset vblank on crtc reset

On Wed, May 27, 2020 at 01:07:05PM +0200, Daniel Vetter wrote: > On Wed, May 27, 2020 at 12:57 PM Liviu Dudau wrote: > > > > Hi Daniel, > > > > On Wed, May 27, 2020 at 11:53:32AM +0200, Daniel Vetter wrote: > > > Only when vblanks are supported ofc. > > > > > > Some drivers do this already, but

[Intel-gfx] [PATCH 3/3] drm/edid: Clean up some curly braces

From: Ville Syrjälä Drop some pointless curly braces, and add some across the else when the if has them too. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c

[Intel-gfx] [PATCH 1/3] drm/edid: Allow looking for ext blocks starting from a specified index

From: Ville Syrjälä Apparently EDIDs with multiple DispID ext blocks is a thing, so prepare for iterating through multiple ext blocks of the same type by passing the starting ext block index to drm_find_edid_extension(). Well also have drm_find_edid_extension() update the index to point to the

[Intel-gfx] [PATCH 2/3] drm/edid: Iterate through all DispID ext blocks

From: Ville Syrjälä Apparently there are EDIDs in the wild with multiple DispID extension blocks. Iterate through them all. In one particular case the tile information is specicied in the second DispID ext block, and since the current parser only looks at the first DispID ext block we don't

[Intel-gfx] [RFC 2/2] drm/i915: Add a new debugfs to request HDCP version

As per the current HDCP design, the driver selects the highest version of HDCP that can be used to satisfy the content-protection requirements of the user. Due to this, the content-protection tests cannot test a lower version of HDCP, if the platform and the display panel, both support higher HDCP

[Intel-gfx] [RFC 1/2] drm/i915: Add support for considering HDCP ver requested via debugfs

For testing and debugging each HDCP version separately, a debugfs entry for requesting a specific version is required. The vesion requested via debugfs needs to be stored in hdcp structure. This can then be considered while enabling HDCP, provided the platform and the display supports the

Re: [Intel-gfx] [PATCH] drm/atomic-helper: reset vblank on crtc reset

On Wed, May 27, 2020 at 12:57 PM Liviu Dudau wrote: > > Hi Daniel, > > On Wed, May 27, 2020 at 11:53:32AM +0200, Daniel Vetter wrote: > > Only when vblanks are supported ofc. > > > > Some drivers do this already, but most unfortunately missed it. This > > opens up bugs after driver load, before

[Intel-gfx] [RFC 0/2] i915: Add debugfs for requesting HDCP version

Currently, for a given content-protection request, the kernel selects the highest version of HDCP supported by the panel and the platform. This makes the testing/debugging difficult for lower versions of HDCP. E.g. In case both the lower and the higher HDCP versions are supported then the higher

[Intel-gfx] [PATCH] drm/i915/gt: Prevent timeslicing into unpreemptible requests

We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent the HW from preempting during the course of this request. We need to honour this flag and protect the HW even if we have a heartbeat request, or other maximum priority barrier, pending. As such, restrict the timeslicing check

Re: [Intel-gfx] [RFC 1/2] drm/i915: Add support for considering HDCP ver requested via debugfs

On Wed, 27 May 2020, Ankit Nautiyal wrote: > For testing and debugging each HDCP version separately, a debugfs > entry for requesting a specific version is required. The vesion > requested via debugfs needs to be stored in hdcp structure. This can > then be considered while enabling HDCP,

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off

== Series Details == Series: series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off URL : https://patchwork.freedesktop.org/series/77689/ State : success == Summary == CI Bug Log - changes from CI_DRM_8541 -> Patchwork_17783

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Special handling for bonded requests

== Series Details == Series: drm/i915: Special handling for bonded requests URL : https://patchwork.freedesktop.org/series/77688/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8541_full -> Patchwork_17782_full Summary

[Intel-gfx] [PATCH] drm/i915/gt: Prevent timeslicing into unpreemptible requests

We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent the HW from preempting during the course of this request. We need to honour this flag and protect the HW even if we have a heartbeat request, or other maximum priority barrier, pending. As such, restrict the timeslicing check

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off (rev2)

== Series Details == Series: series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off (rev2) URL : https://patchwork.freedesktop.org/series/77689/ State : warning == Summary == $ dim checkpatch origin/drm-tip 854716133023 drm/mxsfb: Call drm_crtc_vblank_on/off -:47:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: Add debugfs for requesting HDCP version

== Series Details == Series: i915: Add debugfs for requesting HDCP version URL : https://patchwork.freedesktop.org/series/77693/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.0 Fast mode used, each commit won't be checked separately. -

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915: Add debugfs for requesting HDCP version

== Series Details == Series: i915: Add debugfs for requesting HDCP version URL : https://patchwork.freedesktop.org/series/77693/ State : warning == Summary == $ dim checkpatch origin/drm-tip ee34d42eee76 drm/i915: Add support for considering HDCP ver requested via debugfs a44896d4d874

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev2)

== Series Details == Series: drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev2) URL : https://patchwork.freedesktop.org/series/77697/ State : success == Summary == CI Bug Log - changes from CI_DRM_8543 -> Patchwork_17788

[Intel-gfx] [PATCH 1/3] drm/i915/pmu: avoid an maybe-uninitialized warning

Conditional spinlocks make it hard for gcc and for lockdep to follow the code flow. This one causes a warning with at least gcc-9 and higher: In file included from include/linux/irq.h:14, from drivers/gpu/drm/i915/i915_pmu.c:7: drivers/gpu/drm/i915/i915_pmu.c: In function

[Intel-gfx] [PATCH 2/3] drm/i915: work around false-positive maybe-uninitialized warning

gcc-9 gets confused by the code flow in check_dirty_whitelist: drivers/gpu/drm/i915/gt/selftest_workarounds.c: In function 'check_dirty_whitelist': drivers/gpu/drm/i915/gt/selftest_workarounds.c:492:17: error: 'rsvd' may be used uninitialized in this function [-Werror=maybe-uninitialized] I

[Intel-gfx] [PATCH 3/3] drm/i915/selftests: avoid bogus maybe-uninitialized warning

gcc has a problem following values through IS_ERR/PTR_ERR macros, leading to a false-positive warning in allmodconfig, with any compiler version: In file included from drivers/gpu/drm/i915/gt/intel_lrc.c:5892: drivers/gpu/drm/i915/gt/selftest_lrc.c: In function 'create_gpr_client.isra.0':

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off (rev2)

== Series Details == Series: series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off (rev2) URL : https://patchwork.freedesktop.org/series/77689/ State : success == Summary == CI Bug Log - changes from CI_DRM_8542 -> Patchwork_17784

[Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Randomise bonded submission

Randomly submit a paired spinner and its cancellation as a bonded (submit fence) pair. Apply congestion to the engine with more bonded pairs to see if the execution order fails. If we prevent a cancellation from running, then the spinner will remain spinning forever. Signed-off-by: Chris Wilson

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm: use drm_dev_has_vblank more

== Series Details == Series: drm: use drm_dev_has_vblank more URL : https://patchwork.freedesktop.org/series/77695/ State : failure == Summary == Applying: drm: use drm_dev_has_vblank more error: sha1 information is lacking or useless (drivers/gpu/drm/drm_atomic_helper.c). error: could not

Re: [Intel-gfx] [RFC PATCH 1/4] drm/i915: Drop user contexts on driver remove

Quoting Janusz Krzysztofik (2020-05-18 20:17:17) > Contexts associated with open device file descriptors together with > their assigned address spaces are now closed on device file close. On > address space closure its associated DMA mappings are revoked. If the > device is removed while being

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/edid: Allow looking for ext blocks starting from a specified index

== Series Details == Series: series starting with [1/3] drm/edid: Allow looking for ext blocks starting from a specified index URL : https://patchwork.freedesktop.org/series/77699/ State : success == Summary == CI Bug Log - changes from CI_DRM_8543 -> Patchwork_17789

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off (rev2)

== Series Details == Series: series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off (rev2) URL : https://patchwork.freedesktop.org/series/77689/ State : success == Summary == CI Bug Log - changes from CI_DRM_8542_full -> Patchwork_17784_full

Re: [Intel-gfx] [PATCH] drm/i915/gt: Prevent timeslicing into unpreemptible requests

Quoting Chris Wilson (2020-05-27 14:02:14) > We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent > the HW from preempting during the course of this request. We need to > honour this flag and protect the HW even if we have a heartbeat request, > or other maximum priority barrier,

Re: [Intel-gfx] [RFC 2/2] drm/i915: Add a new debugfs to request HDCP version

On Wed, 27 May 2020, Ankit Nautiyal wrote: > As per the current HDCP design, the driver selects the highest > version of HDCP that can be used to satisfy the content-protection > requirements of the user. Due to this, the content-protection > tests cannot test a lower version of HDCP, if the

Re: [Intel-gfx] [PATCH] drm/atomic-helper: reset vblank on crtc reset

Hi Daniel, On Wed, May 27, 2020 at 11:53:32AM +0200, Daniel Vetter wrote: > Only when vblanks are supported ofc. > > Some drivers do this already, but most unfortunately missed it. This > opens up bugs after driver load, before the crtc is enabled for the > first time. syzbot spotted this when

[Intel-gfx] [PATCH] drm/i915/gt: Prevent timeslicing into unpreemptible requests

We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent the HW from preempting during the course of this request. We need to honour this flag and protect the HW even if we have a heartbeat request, or other maximum priority barrier, pending. As such, restrict the timeslicing check

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gt: Prevent timeslicing into unpreemptible requests

== Series Details == Series: drm/i915/gt: Prevent timeslicing into unpreemptible requests URL : https://patchwork.freedesktop.org/series/77697/ State : failure == Summary == Applying: drm/i915/gt: Prevent timeslicing into unpreemptible requests error: sha1 information is lacking or useless

[Intel-gfx] [PATCH] drm/i915/pmu: avoid an maybe-uninitialized warning

From: Arnd Bergmann Conditional spinlocks make it hard for gcc and for lockdep to follow the code flow. This one causes a warning with at least gcc-9 and higher: In file included from include/linux/irq.h:14, from drivers/gpu/drm/i915/i915_pmu.c:7:

[Intel-gfx] [PATCH v2] drm/i915/gt: Prevent timeslicing into unpreemptable requests

We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent the HW from preempting during the course of this request. We need to honour this flag and protect the HW even if we have a heartbeat request, or other maximum priority barrier, pending. As such, restrict the timeslicing check

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/edid: Allow looking for ext blocks starting from a specified index

== Series Details == Series: series starting with [1/3] drm/edid: Allow looking for ext blocks starting from a specified index URL : https://patchwork.freedesktop.org/series/77699/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8543_full -> Patchwork_17789_full

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Remove local entries from GGTT on suspend

== Series Details == Series: drm/i915/gt: Remove local entries from GGTT on suspend URL : https://patchwork.freedesktop.org/series/77708/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8543 -> Patchwork_17792 Summary

Re: [Intel-gfx] [PATCH 2/3] drm/i915: work around false-positive maybe-uninitialized warning

Quoting Arnd Bergmann (2020-05-27 15:05:09) > gcc-9 gets confused by the code flow in check_dirty_whitelist: > > drivers/gpu/drm/i915/gt/selftest_workarounds.c: In function > 'check_dirty_whitelist': > drivers/gpu/drm/i915/gt/selftest_workarounds.c:492:17: error: 'rsvd' may be > used

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Randomise bonded submission

Quoting Tvrtko Ursulin (2020-05-27 16:51:50) > > On 27/05/2020 14:14, Chris Wilson wrote: > > Randomly submit a paired spinner and its cancellation as a bonded > > (submit fence) pair. Apply congestion to the engine with more bonded > > pairs to see if the execution order fails. If we prevent a

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/pmu: avoid an maybe-uninitialized warning

== Series Details == Series: series starting with [1/3] drm/i915/pmu: avoid an maybe-uninitialized warning URL : https://patchwork.freedesktop.org/series/77706/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8543_full -> Patchwork_17791_full

Re: [Intel-gfx] [PATCH] drm/atomic-helper: reset vblank on crtc reset

On Wed, May 27, 2020 at 11:53:32AM +0200, Daniel Vetter wrote: > Only when vblanks are supported ofc. > > Some drivers do this already, but most unfortunately missed it. This > opens up bugs after driver load, before the crtc is enabled for the > first time. syzbot spotted this when loading vkms

Re: [Intel-gfx] [PATCH] drm: use drm_dev_has_vblank more

Am 27.05.20 um 13:11 schrieb Daniel Vetter: > For historical reasons it's called dev->num_crtcs, which is rather > confusing ever since kms was added. But now we have a nice helper, so > let's use it for better readability! > > Only code change is in atomic helpers: vblank support means that >

[Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Randomise bonded submission

Randomly submit a paired spinner and its cancellation as a bonded (submit fence) pair. Apply congestion to the engine with more bonded pairs to see if the execution order fails. If we prevent a cancellation from running, then the spinner will remain spinning forever. Signed-off-by: Chris Wilson

[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: Add debugfs for requesting HDCP version

== Series Details == Series: i915: Add debugfs for requesting HDCP version URL : https://patchwork.freedesktop.org/series/77693/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8542_full -> Patchwork_17785_full Summary

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev3)

== Series Details == Series: drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev3) URL : https://patchwork.freedesktop.org/series/77697/ State : success == Summary == CI Bug Log - changes from CI_DRM_8543 -> Patchwork_17790

Re: [Intel-gfx] [PATCH] drm/i915/gt: Prevent timeslicing into unpreemptible requests

On 27/05/2020 15:07, Chris Wilson wrote: We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent the HW from preempting during the course of this request. We need to honour this flag and protect the HW even if we have a heartbeat request, or other maximum priority barrier,

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gt: Remove local entries from GGTT on suspend (rev2)

== Series Details == Series: drm/i915/gt: Remove local entries from GGTT on suspend (rev2) URL : https://patchwork.freedesktop.org/series/77708/ State : failure == Summary == Applying: drm/i915/pmu: avoid an maybe-uninitialized warning Using index info to reconstruct a base tree... M

[Intel-gfx] [PATCH] drm/i915/gt: Remove local entries from GGTT on suspend

Across suspend/resume, we clear the entire GGTT and rebuild from scratch. In particular, we only preserve the global entries for use by the HW, and delay reinstating the local binds until required by the user. This means that we can evict and recover any local binds in the global GTT, saving any

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Remove local entries from GGTT on suspend (rev3)

== Series Details == Series: drm/i915/gt: Remove local entries from GGTT on suspend (rev3) URL : https://patchwork.freedesktop.org/series/77708/ State : success == Summary == CI Bug Log - changes from CI_DRM_8544 -> Patchwork_17795 Summary

Re: [Intel-gfx] [PATCH] drm: use drm_dev_has_vblank more

On Wed, May 27, 2020 at 01:11:34PM +0200, Daniel Vetter wrote: > For historical reasons it's called dev->num_crtcs, which is rather > confusing ever since kms was added. But now we have a nice helper, so > let's use it for better readability! > > Only code change is in atomic helpers: vblank

[Intel-gfx] [PATCH] drm/i915/gt: Remove local entries from GGTT on suspend

Across suspend/resume, we clear the entire GGTT and rebuild from scratch. In particular, we only preserve the global entries for use by the HW, and delay reinstating the local binds until required by the user. This means that we can evict and recover any local binds in the global GTT, saving any

Re: [Intel-gfx] [PATCH 3/3] drm/i915/selftests: avoid bogus maybe-uninitialized warning

Quoting Arnd Bergmann (2020-05-27 15:05:10) > gcc has a problem following values through IS_ERR/PTR_ERR macros, > leading to a false-positive warning in allmodconfig, with any > compiler version: > > In file included from drivers/gpu/drm/i915/gt/intel_lrc.c:5892: >

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Randomise bonded submission

On 27/05/2020 14:14, Chris Wilson wrote: Randomly submit a paired spinner and its cancellation as a bonded (submit fence) pair. Apply congestion to the engine with more bonded pairs to see if the execution order fails. If we prevent a cancellation from running, then the spinner will remain

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev3)

== Series Details == Series: drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev3) URL : https://patchwork.freedesktop.org/series/77697/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8543_full -> Patchwork_17790_full

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/pmu: avoid an maybe-uninitialized warning

== Series Details == Series: series starting with [1/3] drm/i915/pmu: avoid an maybe-uninitialized warning URL : https://patchwork.freedesktop.org/series/77706/ State : success == Summary == CI Bug Log - changes from CI_DRM_8543 -> Patchwork_17791

Re: [Intel-gfx] [PATCH v4.19.x] make 'user_access_begin()' do 'access_ok()'

On Wed, May 13, 2020 at 05:08:19PM +, Ashwin H wrote: > > Ok, but what does that mean for us? > > > > You need to say why you are sending a patch, otherwise we will guess wrong. > > In drivers/gpu/drm/i915/i915_gem_execbuffer.c, ioctl functions does > user_access_begin() without doing

Re: [Intel-gfx] [PATCH 2/2] drm/atomic-helper: reset vblank on crtc reset

On Wed, May 27, 2020 at 11:48 AM Daniel Vetter wrote: > > Only when vblanks are supported ofc. > > Some drivers do this already, but most unfortunately missed it. This > opens up bugs after driver load, before the crtc is enabled for the > first time. syzbot spotted this when loading vkms as a

Re: [Intel-gfx] [PATCH 1/3] drm/i915/pmu: avoid an maybe-uninitialized warning

Quoting Arnd Bergmann (2020-05-27 15:05:08) > Conditional spinlocks make it hard for gcc and for lockdep to > follow the code flow. This one causes a warning with at least > gcc-9 and higher: > > In file included from include/linux/irq.h:14, > from

Re: [Intel-gfx] [PATCH] drm/i915/gt: Prevent timeslicing into unpreemptible requests

Quoting Tvrtko Ursulin (2020-05-27 17:13:50) > > On 27/05/2020 15:07, Chris Wilson wrote: > > We have a I915_REQUEST_NOPREEMPT flag that we set when we must prevent > > the HW from preempting during the course of this request. We need to > > honour this flag and protect the HW even if we have a

Re: [Intel-gfx] [PATCH i-g-t] i915/gem_exec_balancer: Randomise bonded submission

Quoting Chris Wilson (2020-05-27 17:00:55) > Quoting Tvrtko Ursulin (2020-05-27 16:51:50) > > > > On 27/05/2020 14:14, Chris Wilson wrote: > > > + > > > + if (rand() % 1) > > > + igt_swap(a, b); > > > + > > > + batch.handle =

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev4)

== Series Details == Series: drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev4) URL : https://patchwork.freedesktop.org/series/77697/ State : success == Summary == CI Bug Log - changes from CI_DRM_8544 -> Patchwork_17794

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Minor link training logic fixes for dp_mst

== Series Details == Series: drm/i915: Minor link training logic fixes for dp_mst URL : https://patchwork.freedesktop.org/series/77716/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17797_full

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix global state use-after-frees with a refcount

== Series Details == Series: drm/i915: Fix global state use-after-frees with a refcount URL : https://patchwork.freedesktop.org/series/77715/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17796_full

[Intel-gfx] [PATCH] drm/i915: Fix global state use-after-frees with a refcount

From: Ville Syrjälä While the current locking/serialization of the global state suffices for protecting the obj->state access and the actual hardware reprogramming, we do have a problem with accessing the old/new states during nonblocking commits. The state computation and swap will be

[Intel-gfx] [PATCH v1] drm/i915: Minor link training logic fixes for dp_mst

First of all *_needs_link_retraining function should return false is link_train is set to true but not false. Also if we detect channel eq problem when checking mst status we simply bail out, without setting link_train to false again, which might end up in a situation that we don't do link

Re: [Intel-gfx] [PATCH v1] drm/i915: Minor link training logic fixes for dp_mst

On Wed, May 27, 2020 at 11:00:22PM +0300, Stanislav Lisovskiy wrote: > First of all *_needs_link_retraining function should return > false is link_train is set to true but not false. > > Also if we detect channel eq problem when checking mst status > we simply bail out, without setting link_train

Re: [Intel-gfx] [RFC PATCH 4/4] drm/i915: Move UC firmware cleanup from driver_release to _remove

Quoting Janusz Krzysztofik (2020-05-18 20:17:20) > UC firmware is stored in a GEM object. Clean it up on driver remove to ^ double whitespace > avoid intel-iommu triggered kernel panic on late DMA unmapping or even > an RPM related warning on object late

Re: [Intel-gfx] [PATCH 7/9] drm/shmem-helpers: Redirect mmap for imported dma-buf

Hi Daniel, what's your plan for this patch set? I'd need this patch for the udl shmem cleanup. Best regards Thomas Am 11.05.20 um 11:35 schrieb Daniel Vetter: > Currently this seems to work by converting the sgt into a pages array, > and then treating it like a native object. Do the right thing

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix global state use-after-frees with a refcount

== Series Details == Series: drm/i915: Fix global state use-after-frees with a refcount URL : https://patchwork.freedesktop.org/series/77715/ State : success == Summary == CI Bug Log - changes from CI_DRM_8544 -> Patchwork_17796 Summary

Re: [Intel-gfx] [PATCH v1] drm/i915: Minor link training logic fixes for dp_mst

On Wed, May 27, 2020 at 11:26:49PM +0300, Imre Deak wrote: > On Wed, May 27, 2020 at 11:00:22PM +0300, Stanislav Lisovskiy wrote: > > First of all *_needs_link_retraining function should return > > false is link_train is set to true but not false. > > > > Also if we detect channel eq problem when

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Minor link training logic fixes for dp_mst

== Series Details == Series: drm/i915: Minor link training logic fixes for dp_mst URL : https://patchwork.freedesktop.org/series/77716/ State : success == Summary == CI Bug Log - changes from CI_DRM_8544 -> Patchwork_17797 Summary ---

Re: [Intel-gfx] [RFC PATCH 3/4] drm/i915: Move GGTT cleanup from driver_release to _remove

Quoting Janusz Krzysztofik (2020-05-18 20:17:19) > GGTT including its scratch page is not cleaned up until driver release. > Since DMA mappings still exist before scratch page cleanup, unmapping > them on last device close after the driver has been already removed may > be judged by intel-iommu

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev4)

== Series Details == Series: drm/i915/gt: Prevent timeslicing into unpreemptible requests (rev4) URL : https://patchwork.freedesktop.org/series/77697/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17794_full

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Remove local entries from GGTT on suspend (rev3)

== Series Details == Series: drm/i915/gt: Remove local entries from GGTT on suspend (rev3) URL : https://patchwork.freedesktop.org/series/77708/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8544_full -> Patchwork_17795_full

Re: [Intel-gfx] [PATCH v1] drm/i915: Minor link training logic fixes for dp_mst

On Wed, May 27, 2020 at 11:00:22PM +0300, Stanislav Lisovskiy wrote: > First of all *_needs_link_retraining function should return > false is link_train is set to true but not false. > > Also if we detect channel eq problem when checking mst status > we simply bail out, without setting link_train

Re: [Intel-gfx] [PATCH v1] drm/i915: Minor link training logic fixes for dp_mst

On Wed, May 27, 2020 at 11:49:55PM +0300, Imre Deak wrote: > On Wed, May 27, 2020 at 11:26:49PM +0300, Imre Deak wrote: > > On Wed, May 27, 2020 at 11:00:22PM +0300, Stanislav Lisovskiy wrote: > > > First of all *_needs_link_retraining function should return > > > false is link_train is set to

Re: [Intel-gfx] [RFC PATCH 2/4] drm/i915: Release GT resources on driver remove

Quoting Janusz Krzysztofik (2020-05-18 20:17:18) > GT scratch page is now released and its DMA mappings revoked on driver > release. If a device is removed while its file descriptor is still > open, the driver is not released until last device file descriptor > closure. In that case intel-iommu

Re: [Intel-gfx] [PATCH 7/9] drm/shmem-helpers: Redirect mmap for imported dma-buf

On Wed, May 27, 2020 at 8:32 PM Thomas Zimmermann wrote: > > Hi Daniel, > > what's your plan for this patch set? I'd need this patch for the udl > shmem cleanup. I was pinging some people for a tested-by, I kinda don't want to push this entirely untested. I think at least one of the rendering

[Intel-gfx] [PULL] gvt-next-fixes

Hi, Here's two queued warning fixes for gvt-next. One is for clang warning on debug only function and another one from coccicheck to use ARRAY_SIZE. Thanks -- The following changes since commit 3a36aa237e4ed04553c0998cf5f47eda3e206e4f: drm/i915: Update DRIVER_DATE to 20200515 (2020-05-15

[Intel-gfx] [PATCH] drm: use drm_dev_has_vblank more

For historical reasons it's called dev->num_crtcs, which is rather confusing ever since kms was added. But now we have a nice helper, so let's use it for better readability! Only code change is in atomic helpers: vblank support means that dev->irq_enabled must be set too. Another one of these

Re: [Intel-gfx] [PATCH 1/2] drm/mxsfb: Call drm_crtc_vblank_on/off

On Wed, May 27, 2020 at 11:47:56AM +0200, Daniel Vetter wrote: > mxsfb has vblank support, is atomic, but doesn't call > drm_crtc_vblank_on/off as it should. Not good. > > With my next patch to add the drm_crtc_vblank_reset to helpers this > means not even the very first crtc enabling will

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Fix early deref of 'dsb'

== Series Details == Series: drm/i915/display: Fix early deref of 'dsb' URL : https://patchwork.freedesktop.org/series/77617/ State : success == Summary == CI Bug Log - changes from CI_DRM_8529_full -> Patchwork_17766_full Summary ---

[Intel-gfx] [PATCH] drm/i915: Special handling for bonded requests

From: Tvrtko Ursulin Our generic mechanism for specifying aligned request start, I915_EXEC_FENCE_SUBMIT, has a bit too relaxed rules when it comes to the actual use case of media scalability on Tigerlake. While the submit fence can provide the aligned start, the actual media pipeline expects

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Do not schedule normal requests immediately along virtual

On 27/05/2020 08:03, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-05-27 07:51:44) On 26/05/2020 10:07, Chris Wilson wrote: When we push a virtual request onto the HW, we update the rq->engine to point to the physical engine. A request that is then submitted by the user that waits upon

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Reorder await_execution before await_request

On 26/05/2020 10:07, Chris Wilson wrote: Reorder the code so that we can reuse the await_execution from a special case in await_request in the next patch. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 264 ++-- 1 file changed, 132

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Do not schedule normal requests immediately along virtual

Quoting Tvrtko Ursulin (2020-05-27 08:32:05) > > On 27/05/2020 08:03, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2020-05-27 07:51:44) > >> > >> On 26/05/2020 10:07, Chris Wilson wrote: > >>> When we push a virtual request onto the HW, we update the rq->engine to > >>> point to the physical

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Do not schedule normal requests immediately along virtual

On 27/05/2020 08:47, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-05-27 08:32:05) On 27/05/2020 08:03, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-05-27 07:51:44) On 26/05/2020 10:07, Chris Wilson wrote: When we push a virtual request onto the HW, we update the rq->engine to

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

Hi Dave and Daniel, here's the pull request for the current drm-misc-next-fixes. Best regards Thomas drm-misc-next-fixes-2020-05-27: Short summary of fixes pull (less than what git shortlog provides): There's a fix for panel brighness on Lenovo X13 Yoga devices and a fix for -Wformat warnings

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Do not schedule normal requests immediately along virtual

On 26/05/2020 10:07, Chris Wilson wrote: When we push a virtual request onto the HW, we update the rq->engine to point to the physical engine. A request that is then submitted by the user that waits upon the virtual engine, but along the physical engine in use, will then see that it is due to

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gt: Do not schedule normal requests immediately along virtual

Quoting Tvrtko Ursulin (2020-05-27 07:51:44) > > On 26/05/2020 10:07, Chris Wilson wrote: > > When we push a virtual request onto the HW, we update the rq->engine to > > point to the physical engine. A request that is then submitted by the > > user that waits upon the virtual engine, but along

Re: [Intel-gfx] [PATCH] drm/i915: Special handling for bonded requests

Quoting Tvrtko Ursulin (2020-05-27 09:53:22) > From: Tvrtko Ursulin > > Our generic mechanism for specifying aligned request start, > I915_EXEC_FENCE_SUBMIT, has a bit too relaxed rules when it comes to the > actual use case of media scalability on Tigerlake. > > While the submit fence can

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Special handling for bonded requests

== Series Details == Series: drm/i915: Special handling for bonded requests URL : https://patchwork.freedesktop.org/series/77688/ State : warning == Summary == $ dim checkpatch origin/drm-tip 10e39c0f7a03 drm/i915: Special handling for bonded requests -:20: WARNING:TYPO_SPELLING:

Re: [Intel-gfx] [PATCH] drm/i915: Special handling for bonded requests

On 27/05/2020 10:20, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-05-27 09:53:22) From: Tvrtko Ursulin Our generic mechanism for specifying aligned request start, I915_EXEC_FENCE_SUBMIT, has a bit too relaxed rules when it comes to the actual use case of media scalability on Tigerlake.

Re: [Intel-gfx] [PATCH] drm/i915/gt: Clear LOCAL_BIND from shared GGTT on resume

On Tue, 26 May 2020 at 16:07, Chris Wilson wrote: > > We only restore GLOBAL binds upon resume as we expect these to be pinned > for use by HW, whereas the LOCAL binds can be recreated on demand once > userspace is resumed. For the LOCAL bind to be recreated in the global > GTT, we need to clear

[Intel-gfx] [PATCH 1/2] drm/mxsfb: Call drm_crtc_vblank_on/off

mxsfb has vblank support, is atomic, but doesn't call drm_crtc_vblank_on/off as it should. Not good. With my next patch to add the drm_crtc_vblank_reset to helpers this means not even the very first crtc enabling will vblanks work anymore, since they'll just stay off forever. Since mxsfb doesn't

[Intel-gfx] [PATCH 2/2] drm/atomic-helper: reset vblank on crtc reset

Only when vblanks are supported ofc. Some drivers do this already, but most unfortunately missed it. This opens up bugs after driver load, before the crtc is enabled for the first time. syzbot spotted this when loading vkms as a secondary output. Given how many drivers are buggy it's best to

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Special handling for bonded requests

== Series Details == Series: drm/i915: Special handling for bonded requests URL : https://patchwork.freedesktop.org/series/77688/ State : success == Summary == CI Bug Log - changes from CI_DRM_8541 -> Patchwork_17782 Summary ---

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off

== Series Details == Series: series starting with [1/2] drm/mxsfb: Call drm_crtc_vblank_on/off URL : https://patchwork.freedesktop.org/series/77689/ State : warning == Summary == $ dim checkpatch origin/drm-tip 01d3621e8e27 drm/mxsfb: Call drm_crtc_vblank_on/off -:47:

  1   2   >