== Series Details ==
Series: Asynchronous flip implementation for i915 (rev3)
URL : https://patchwork.freedesktop.org/series/74386/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8544 -> Patchwork_17799
Summary
---
**
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev3)
URL : https://patchwork.freedesktop.org/series/74386/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
+drivers/gpu/drm/
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev3)
URL : https://patchwork.freedesktop.org/series/74386/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
239c9f562cbf drm/i915: Add enable/disable flip done and flip done handler
-:28: WARNING:TYPO_SPELLIN
== Series Details ==
Series: drm: use drm_dev_has_vblank more (rev2)
URL : https://patchwork.freedesktop.org/series/77695/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8544 -> Patchwork_17798
Summary
---
**SUCCESS**
== Series Details ==
Series: drm: use drm_dev_has_vblank more (rev2)
URL : https://patchwork.freedesktop.org/series/77695/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cf9dbc246d30 drm: use drm_dev_has_vblank more
-:113: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line
Without async flip support in the kernel, fullscreen apps where game
resolution is equal to the screen resolution, must perform an extra blit
per frame prior to flipping.
Asynchronous page flips will also boost the FPS of Mesa benchmarks.
v2: Few patches have been squashed and patches have been s
Enable asynchronous flips in i915 for gen9+ platforms.
v2: -Async flip enablement should be a stand alone patch (Paulo)
v3: -Move the patch to the end of the serires (Paulo)
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +++
1 file changed, 3 insertions(+)
di
Add enable/disable flip done functions and the flip done handler
function which handles the flip done interrupt.
Enable the flip done interrupt in IER.
Enable flip done function is called before writing the
surface address register as the write to this register triggers
the flip done interrupt
F
Since the flip done event will be sent in the flip_done_handler,
no need to add the event to the list and delay it for later.
v2: -Moved the async check above vblank_get as it
was causing issues for PSR.
v3: -No need to wait for vblank to pass, as this wait was causing a
16ms delay once
Set the Async Address Update Enable bit in plane ctl
when async flip is requested.
v2: -Move the Async flip enablement to individual patch (Paulo)
v3: -Rebased.
Signed-off-by: Karthik B S
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +++
drivers/gpu/drm/i915/i915_reg.h | 1
Support added only for async flips on primary plane.
If flip is requested on any other plane, reject it.
Make sure there is no change in fbc, offset and framebuffer modifiers
when async flip is requested.
If any of these are modified, reject async flip.
v2: -Replace DRM_ERROR (Paulo)
-Add ch
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 vblanks
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 quir
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 14:4
== 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
Summary
== 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
S
== 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
== 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
---
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 true
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
== 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
---
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
== 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
==
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
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 retrain
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 protected
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 dri
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
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 cod
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 c
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
== 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
===
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 suppo
== 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
== 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
==
== 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
Su
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 ti
== 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 dri
== 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
===
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 = create_semaphore_to_spinner(
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 to
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 he
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, pendin
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:
drivers/gpu/drm/i915/i915_pmu.c
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 ca
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 spin
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:
> drivers/gpu/drm/i915/gt/selftest
== 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
---
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 uninitializ
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 sec
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 drivers/gpu/drm/i915/i915_pmu.c:
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 access
== 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
=
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 ti
== 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
Su
== 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
--
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 op
== 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
=
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 vblanks
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, provided
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 platf
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 'i915_sa
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 cou
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':
drivers/
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 to
== 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
Su
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
C
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,
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
ne
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 b/drivers/gpu/drm/drm
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 noti
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 to
== 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
(d
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 to
== 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
=
== 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 bu
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
-
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 mo
== 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
---
**SUC
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
> de
== 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.
-
+drivers/gpu/drm/i
== 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 drm/i91
> -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, assignin
== 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
===
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 quir
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 th
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 requested
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
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
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 lo
== 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: WARNING:NO_AUTHOR_
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 a
== 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
-
== 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
Summ
Quoting Tvrtko Ursulin (2020-05-27 10:36:31)
>
> 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
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 solve
== 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: WARNING:NO_AUTHOR_SIGN_OF
== 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
---
**SU
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
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 solve
1 - 100 of 112 matches
Mail list logo
