On Tue, Jun 29, 2021 at 12:35:09PM -0700, Matthew Brost wrote:
> Subject and patches say it all.
>
> v2: Address comments, patches have details of changes
> v3: Address comments, patches have details of changes
> v4: Address comments, patches have details of changes
> v5: Fix checkpatch and docs w
On Wed, Jun 30, 2021 at 9:18 AM Desmond Cheong Zhi Xi
wrote:
>
> On 30/6/21 12:07 am, Daniel Vetter wrote:
> > On Tue, Jun 29, 2021 at 11:37:06AM +0800, Desmond Cheong Zhi Xi wrote:
> >> Currently, direct copies of drm_file->master pointers should be
> >> protected by drm_device.master_mutex when
On 29/06/2021 22:35, Matthew Brost wrote:
Add entry for i915 GuC submission / DRM scheduler integration plan.
Follow up patch with details of new parallel submission uAPI to come.
v2:
(Daniel Vetter)
- Expand explaination of why bonding isn't supported for GuC
submission
- CC some o
> -Original Message-
> From: Intel-gfx On Behalf Of
> Shankar,
> Uma
> Sent: Thursday, June 24, 2021 2:19 PM
> To: Modem, Bhanuprakash ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [V3] drm/i915/display: Fix state mismatch in drm
> infoframe
>
>
>
> > -Origina
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 general drm property "active bpc" which can be used by graphic
> >> drivers to report the applied bit depth per pixel back to u
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
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 1 +
drivers/g
(was: drm/i915: Drop all references to DRM IRQ midlayer)
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.
Thomas Zimmermann (2):
drm/i915: Use the correct IRQ during resume
drm/i915: Drop all refere
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.
v2:
* wrap irq code in intel_synchronize_hardirq() (Ville)
Signed-off-by: Thomas Zimmermann
Fixes: 536f77b1ca
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
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:
> >
> >> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen
> >> wrote:
> >>
> >>> yes, I think this makes sense, even if it
On 29/06/2021 22:35, Matthew Brost wrote:
Add entry for i915 new parallel submission uAPI plan.
v2:
(Daniel Vetter):
- Expand logical order explaination
- Add dummy header
- Only allow N BBs in execbuf IOCTL
- Configure parallel submission per slot not per gem context
v3:
(Marcin
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:
On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen
wrote:
yes, I think this make
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 the swiotlb_force into io_tlb_default_mem->force_bounce and
> > use it to determine whether to bounce the data or not. This will be
> > useful later to allow for
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 general drm property "active bpc" which can be used by graphic
drivers to report the app
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.
v3:
* also use intel_synchronize_hardirq() from other callsite
v2:
* split patch
* also fix comment
* add intel_synchroniz
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
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.
v3:
* also use intel_synchronize_hardirq() at another callsite
v2:
* wrap irq code in intel_synchronize
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 integrated parts
> which lack was breaking ADL-P with media stack.
> Besides that a small selftest fix and a theoretical over
On Wed, Jun 30, 2021 at 11:52:28AM +0200, Thomas Zimmermann wrote:
> 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)
>
> S
On Wed, Jun 30, 2021 at 11:52:27AM +0200, Thomas Zimmermann wrote:
> 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.
>
> v3:
> * also use intel_synchronize_h
> dispcnlunit1_cp_xosc_clkreq clock observed to be active on TGL-H platform
> despite Wa_14010685332 original sequence, thus blocks entry to deeper s0ix
> state.
>
> The Tweaked Wa_14010685332 sequence fixes this issue, therefore use tweaked
> Wa_14010685332 sequence for every PCH since PCH_CNP.
>
> -Original Message-
> From: dri-devel On Behalf Of Harry
> Wentland
> Sent: Monday, June 28, 2021 8:45 PM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org;
> dri-
> de...@lists.freedesktop.org
> Cc: Modem, Bhanuprakash
> Subject: Re: [PATCH 04/21] drm/i915/xelpd: Define Degamma L
> -Original Message-
> From: Deak, Imre
> Sent: Monday, June 28, 2021 11:12 PM
> To: Gupta, Anshuman
> Cc: intel-gfx@lists.freedesktop.org; Ville Syrjälä
> ;
> Kai Vehmanen ; Shankar, Uma
>
> Subject: Re: [RFC v3 1/2] drm/i915/dg1: Adjust the AUDIO power domain
>
> On Tue, Jun 01, 2
> -Original Message-
> From: AceLan Kao On Behalf Of
> acelan@canonical.com
> Sent: Wednesday, June 30, 2021 4:49 PM
> To: Gupta, Anshuman ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [v2] drm/i915: Tweaked Wa_14010685332 for all PCHs
>
> > dispcnlunit1_cp_xosc_clkreq clock
Hi
Am 30.06.21 um 12:06 schrieb Greg KH:
On Wed, Jun 30, 2021 at 11:52:28AM +0200, Thomas Zimmermann wrote:
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
Having different alignment requirement by different drivers,
256B aligned should work for all drm drivers.
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/
On 2021-06-30 at 19:19:04 +0800, acelan@canonical.com wrote:
> > dispcnlunit1_cp_xosc_clkreq clock observed to be active on TGL-H platform
> > despite Wa_14010685332 original sequence, thus blocks entry to deeper s0ix
> > state.
> >
> > The Tweaked Wa_14010685332 sequence fixes this issue, the
On Wed, Jun 30, 2021 at 05:32:15PM +0530, Tejas Upadhyay wrote:
> Having different alignment requirement by different drivers,
> 256B aligned should work for all drm drivers.
What.
Like yes vgem abuses dumb_create, but it's not a kms driver. Pitch is
meaningless, and that's why we align it minima
On 30/6/21 8:16 am, Emil Velikov wrote:
Hi Desmond,
Couple of small suggestions, with those the series is:
Reviewed-by: Emil Velikov
On Tue, 29 Jun 2021 at 04:38, Desmond Cheong Zhi Xi
wrote:
@@ -128,13 +137,20 @@ bool drm_lease_held(struct drm_file *file_priv, int id)
struct drm_m
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 the swiotlb_force into io_tlb_default_mem->force_bounce and
> > > use it to determine wheth
On 30/6/21 4:02 pm, Daniel Vetter wrote:
On Wed, Jun 30, 2021 at 9:18 AM Desmond Cheong Zhi Xi
wrote:
On 30/6/21 12:07 am, Daniel Vetter wrote:
On Tue, Jun 29, 2021 at 11:37:06AM +0800, Desmond Cheong Zhi Xi wrote:
Currently, direct copies of drm_file->master pointers should be
protected by
On 30/6/21 12:07 am, Daniel Vetter wrote:
On Tue, Jun 29, 2021 at 11:37:06AM +0800, Desmond Cheong Zhi Xi wrote:
Currently, direct copies of 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
> -Original Message-
> From: Daniel Vetter
> Sent: 30 June 2021 17:52
> To: Surendrakumar Upadhyay, TejaskumarX
>
> Cc: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org;
> ch...@chris-wilson.co.uk
> Subject: Re: [Intel-gfx] [PATCH] drm/vgem: Use 256B aligned pitch
>
>
Our dma-buf code is currently completely broken unless the importer is
dynamic in which case the sg_list caching saves the day. In particular,
the case where another instance of our driver tries to import a dma-buf
exported by our driver ends up in a recursive lock.
Since the recent TTM migration
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf map 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() callback.
Signed-off-by: Tho
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 recursive locking.
Add a li
> -Original Message-
> From: Patnana, Venkata Sai
> Sent: Wednesday, June 30, 2021 11:59 AM
> To: Jani Nikula ;
> intel-gfx@lists.freedesktop.org;
> Navare, Manasi D ; Kulkarni, Vandita
>
> Subject: RE: [Intel-gfx] [PATCH v2 1/2] drm/i915/display/dsc: Add Per
> connector
> debugfs nod
On Wed, Jun 30, 2021 at 03:07:00PM +0200, Thomas Hellström wrote:
> 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
On Wed, Jun 30, 2021 at 12:46:27PM +, Surendrakumar Upadhyay, TejaskumarX
wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter
> > Sent: 30 June 2021 17:52
> > To: Surendrakumar Upadhyay, TejaskumarX
> >
> > Cc: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org;
>-Original Message-
>From: Daniel Vetter
>Sent: Wednesday, June 30, 2021 10:02 AM
>To: Thomas Hellström ; Christian König
>
>Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Auld,
>Matthew ; maarten.lankho...@linux.intel.com;
>dan...@ffwll.ch; Ruhl, Michael J
>Subject
Hi
Am 30.06.21 um 12:49 schrieb Daniel Vetter:
On Wed, Jun 30, 2021 at 11:52:27AM +0200, Thomas Zimmermann wrote:
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.
v
On Thu, 24 Jun 2021 at 20:31, Thomas Hellström
wrote:
>
> In order to make the code a bit more readable and to facilitate
> async memcpy moves, reorganize the move code a little. Determine
> at an early stage whether to copy or to clear.
>
> Signed-off-by: Thomas Hellström
> ---
> drivers/gpu/dr
On Thu, 24 Jun 2021 at 20:31, Thomas Hellström
wrote:
>
> The buffer object argument to ttm_move_memcpy was only used to
> determine whether the destination memory should be cleared only
> or whether we should copy data. Replace it with a "clear" bool, and
> update the callers.
>
> The intention h
Currently, direct copies of 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 dr
In a future patch, _drm_lease_held will dereference drm_file->master
only after making a call to drm_file_get_master which increments the
reference count of drm_file->master while holding a lock on
drm_device.master_mutex.
In preparation for this, the call to _drm_lease_held should be moved
out fr
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
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
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
convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to
an integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11
missing.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4
1 file changed, 4 insertions(+)
diff --git a/dri
Implementation of https://lkml.org/lkml/2021/5/12/764 now feature complete
albeit not fully tested.
I have now corrected the DSC behavior, but still no wait to test it.
Exact dithering behavior remains a mistery so in case dithering is active it's
not 100% clear what "active bpc" means, or where
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.
Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI,
there is no reason to use RGB when the display
reports d
Add a new general drm property "active bpc" which can be used by graphic
drivers to report the applied bit depth per pixel color back to userspace.
While "max bpc" can be used to change the color depth, there was no way to
check which one actually got used. While in theory the driver chooses the
b
This commit implements the "active bpc" drm property for the Intel GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 19 +++
drivers/gpu/drm/i915/display/intel_dp.c | 7 +--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +++
This commit implements the "active color format" drm property for the AMD
GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +--
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 31 insertions(+), 2 deletions(-
This commit implements the "active color range" drm property for the AMD
GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 37 insertions(+)
diff --git a/d
Add a new general drm property "active color range" which can be used by
graphic drivers to report the used color range back to userspace.
There was no way to check which color range got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monitor a
This commit implements the "active color format" drm property for the Intel
GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 22 +++-
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c |
This commit implements the "preferred color format" drm property for the
Intel GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_dp.c | 7 ++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 6 ++
3 f
Add a new general drm property "active color format" which can be used by
graphic drivers to report the used color format back to userspace.
There was no way to check which color format got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monito
This commit implements the "active bpc" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 ++-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4
2 files changed, 27 insertions(+), 1 deletion(-)
diff -
This commit implements the "Broadcast RGB" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++---
.../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 4
2 files changed, 15 insertions(+), 3 deletions(-
Add a new general drm property "preferred color format" which can be used
by userspace to tell the graphic drivers to which color format to use.
Possible options are:
- auto (default/current behaviour)
- rgb
- ycbcr444
- ycbcr422 (not supported by both amdgpu and i915)
- ycbcr4
This commit implements the "preferred color format" drm property for the
AMD GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 28 insertions(+), 6 deletion
Change from the i915 specific "Broadcast RGB" drm property implementation
to the general one.
This commit delete all traces of the former "Broadcast RGB" implementation
and add a new one using the new driver agnoistic functions an variables.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i91
This commit implements the "active color range" drm property for the Intel
GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +++
drivers/gpu/drm/i915/display/intel_dp.c | 1 +
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
drivers/g
Add "Broadcast RGB" to general drm context so that more drivers besides
i915 and gma500 can implement it without duplicating code.
Userspace can use this property to tell the graphic driver to use full or
limited color range for a given connector, overwriting the default
behaviour/automatic detect
On Wed, 2021-06-30 at 15:19 +0100, Matthew Auld wrote:
> On Thu, 24 Jun 2021 at 20:31, Thomas Hellström
> wrote:
> >
> > In order to make the code a bit more readable and to facilitate
> > async memcpy moves, reorganize the move code a little. Determine
> > at an early stage whether to copy or to
== Series Details ==
Series: drm/i915: IRQ fixes (rev2)
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/display/intel_d
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 the operation due to a deadlock. So now when the
fence co
On Wed, 30 Jun 2021 at 16:27, Thomas Hellström
wrote:
>
> On Wed, 2021-06-30 at 15:19 +0100, Matthew Auld wrote:
> > On Thu, 24 Jun 2021 at 20:31, Thomas Hellström
> > wrote:
> > >
> > > In order to make the code a bit more readable and to facilitate
> > > async memcpy moves, reorganize the move
On Wed, Jun 30, 2021 at 6:54 PM Matthew Auld
wrote:
>
> On Wed, 30 Jun 2021 at 16:27, Thomas Hellström
> wrote:
> >
> > On Wed, 2021-06-30 at 15:19 +0100, Matthew Auld wrote:
> > > On Thu, 24 Jun 2021 at 20:31, Thomas Hellström
> > > wrote:
> > > >
> > > > In order to make the code a bit more re
On Wed, Jun 30, 2021 at 4:18 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 30.06.21 um 12:49 schrieb Daniel Vetter:
> > On Wed, Jun 30, 2021 at 11:52:27AM +0200, Thomas Zimmermann wrote:
> >> The code in xcs_resume() probably didn't work as intended. It uses
> >> struct drm_device.irq, which is alloca
== Series Details ==
Series: drm/i915: IRQ fixes (rev2)
URL : https://patchwork.freedesktop.org/series/92053/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20491
Summary
---
**SUCCESS**
No regre
On Wed, Jun 30, 2021 at 4:01 PM Daniel Vetter wrote:
> On Wed, Jun 30, 2021 at 03:07:00PM +0200, Thomas Hellström wrote:
> > 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
== Series Details ==
Series: drm: address potential UAF bugs with drm_master ptrs (rev3)
URL : https://patchwork.freedesktop.org/series/91969/
State : failure
== Summary ==
Applying: drm: avoid circular locks in drm_mode_getconnector
Applying: drm: add a locked version of drm_is_current_master
== Series Details ==
Series: drm/vgem: Use 256B aligned pitch
URL : https://patchwork.freedesktop.org/series/92067/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20492
Summary
---
**SUCCESS**
No
== Series Details ==
Series: drm/i915/gem: dma-buf fixes for migration
URL : https://patchwork.freedesktop.org/series/92070/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
3b50433924c8 drm/i915/gem: Make our dma-buf exporter dynamic
-:16: WARNING:COMMIT_LOG_LONG_LINE: Possible u
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
> > Signed-off-
== Series Details ==
Series: drm/i915/gem: dma-buf fixes for migration
URL : https://patchwork.freedesktop.org/series/92070/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20494
Summary
---
**FAILUR
== Series Details ==
Series: drm: address potential UAF bugs with drm_master ptrs
URL : https://patchwork.freedesktop.org/series/92076/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
13940bd0a105 drm: avoid circular locks in drm_mode_getconnector
dbd6d7ef5160 drm: avoid circular
== Series Details ==
Series: drm: address potential UAF bugs with drm_master ptrs
URL : https://patchwork.freedesktop.org/series/92076/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20495
Summary
---
== Series Details ==
Series: New uAPI drm properties for color management (rev3)
URL : https://patchwork.freedesktop.org/series/91523/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
de5b09605b88 drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
-:32: CHECK:LOGICA
== Series Details ==
Series: New uAPI drm properties for color management (rev3)
URL : https://patchwork.freedesktop.org/series/91523/
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
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: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/int
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 integrated parts
> > which lack was breaking ADL-P w
== Series Details ==
Series: New uAPI drm properties for color management (rev3)
URL : https://patchwork.freedesktop.org/series/91523/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20496
Summary
---
== Series Details ==
Series: drm/i915/gt: Fix -EDEADLK handling regression
URL : https://patchwork.freedesktop.org/series/92082/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20497
Summary
---
**SU
== Series Details ==
Series: Update to new HuC for TGL+ and enable GuC/HuC on ADL-P (rev2)
URL : https://patchwork.freedesktop.org/series/91932/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20498
Summary
_DG1_DPCLKA0_CFGCR0 maps between DPLL 0 and 1 with one bit for phy A
and B while _DG1_DPCLKA1_CFGCR0 maps between DPLL 2 and 3 with one
bit for phy C and D.
Reusing _cnl_ddi_get_pll() don't take that into cosideration returing
DPLL 0 and 1 for phy C and D.
That is a regression introduced in the r
== Series Details ==
Series: drm/i915/display/dg1: Correctly map DPLLs during state readout
URL : https://patchwork.freedesktop.org/series/92086/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5fce8912a42d drm/i915/display/dg1: Correctly map DPLLs during state readout
-:23: WARN
== Series Details ==
Series: drm/i915/display/dg1: Correctly map DPLLs during state readout
URL : https://patchwork.freedesktop.org/series/92086/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20499
Summar
On Wed, Jun 30, 2021 at 02:05:22PM -0700, Jose Souza wrote:
_DG1_DPCLKA0_CFGCR0 maps between DPLL 0 and 1 with one bit for phy A
and B while _DG1_DPCLKA1_CFGCR0 maps between DPLL 2 and 3 with one
bit for phy C and D.
Reusing _cnl_ddi_get_pll() don't take that into cosideration returing
DPLL 0 an
On 28.06.2021 01:14, Matthew Brost wrote:
> 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
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
Adding the helper intel_get_display_step().
Cc: Lucas De Marchi
Signed-off-by: Anu
== Series Details ==
Series: drm/i915/dmc: Use RUNTIME_INFO->stp for DMC
URL : https://patchwork.freedesktop.org/series/92088/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
dc34e57ce634 drm/i915/dmc: Use RUNTIME_INFO->stp for DMC
-:29: CHECK:BRACES: Blank lines aren't necessary
== Series Details ==
Series: drm/i915/dmc: Use RUNTIME_INFO->stp for DMC
URL : https://patchwork.freedesktop.org/series/92088/
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/i91
On 28.06.2021 01:14, Matthew Brost wrote:
> 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
> - Retur
== Series Details ==
Series: drm/i915/dmc: Use RUNTIME_INFO->stp for DMC
URL : https://patchwork.freedesktop.org/series/92088/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20500
Summary
---
**SUCC
Typo: RUNTIME_INFO->stp
On Wed, Jun 30, 2021 at 04:06:24PM -0700, Anusha Srivatsa wrote:
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
== Series Details ==
Series: drm/i915: IRQ fixes (rev2)
URL : https://patchwork.freedesktop.org/series/92053/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20491_full
Summary
---
**FAILURE**
1 - 100 of 115 matches
Mail list logo
