== Series Details ==
Series: drm/i915/dmc: Use RUNTIME_INFO->stp for DMC
URL : https://patchwork.freedesktop.org/series/92088/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20500_full
Summary
== Series Details ==
Series: drm/i915/dg1: Compute MEM Bandwidth using MCHBAR
URL : https://patchwork.freedesktop.org/series/92094/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10295 -> Patchwork_20501
Summary
---
== Series Details ==
Series: drm/i915/display/dg1: Correctly map DPLLs during state readout
URL : https://patchwork.freedesktop.org/series/92086/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20499_full
From: Clint Taylor
The PUNIT FW is currently returning 0 for all memory bandwidth
parameters. Read the values directly from MCHBAR offsets 0x5918 and
0x4000(4).
v2 (Lucas): tidy up checking for ret slightly
v3 (Lucas):
- Squash change to double the memory bandwidth based on
MCHBAR
Replacement for https://patchwork.freedesktop.org/series/91848/
Those 2 commits are now squashed and received a round of cleanup. My
changes were mostly cosmetic, so I'm leaving my r-b there. It would be
good to get an ack though.
Clint Taylor (1):
drm/i915/dg1: Compute MEM Bandwidth using
== 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 : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20498_full
== Series Details ==
Series: drm/i915/gt: Fix -EDEADLK handling regression
URL : https://patchwork.freedesktop.org/series/92082/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20497_full
Summary
== Series Details ==
Series: New uAPI drm properties for color management (rev3)
URL : https://patchwork.freedesktop.org/series/91523/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20496_full
== Series Details ==
Series: drm: address potential UAF bugs with drm_master ptrs
URL : https://patchwork.freedesktop.org/series/92076/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20495_full
== Series Details ==
Series: drm/vgem: Use 256B aligned pitch
URL : https://patchwork.freedesktop.org/series/92067/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10295_full -> Patchwork_20492_full
Summary
---
On Thu, Jul 01, 2021 at 01:23:36AM +0200, Michal Wajdeczko wrote:
>
>
> 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
On Thu, Jul 01, 2021 at 12:52:58AM +0200, Michal Wajdeczko wrote:
>
>
> 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
On Wed, Jun 30, 2021 at 05:15:00PM -0700, Jose Souza wrote:
On Wed, 2021-06-30 at 17:01 -0700, Lucas De Marchi wrote:
Typo: RUNTIME_INFO->stp
On Wed, Jun 30, 2021 at 04:06:24PM -0700, Anusha Srivatsa wrote:
> On the dmc side,we maintain a lookup table with different display
>
On Wed, 2021-06-30 at 17:01 -0700, Lucas De Marchi wrote:
> Typo: RUNTIME_INFO->stp
>
> On Wed, Jun 30, 2021 at 04:06:24PM -0700, Anusha Srivatsa wrote:
> > On the dmc side,we maintain a lookup table with different display
> > stepping-substepping combinations.
> >
> > Instead of adding new
== 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**
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
== 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
---
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
> -
== 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.
-
== 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
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:
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
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
== 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
== 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:
_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
== 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
== 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
---
== 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
---
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
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
---
== 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.
== 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:
== 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: 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
== 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
---
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
> >
== 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
== 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**
== 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
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
> >
== 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
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
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
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
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
== 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.
-
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
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
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 +
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
---
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)
-
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
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
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
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 "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
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
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
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
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
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
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
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
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
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 >mode_config.mutex. This avoids creating a
circular lock dependency.
Failing to
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
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
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
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
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
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
> ---
>
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.
>-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
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;
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
> -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
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
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:
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
> -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
>
>
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
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
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
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
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,
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
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
> -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
> -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,
> -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
> 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.
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
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)
>
>
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
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
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
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
1 - 100 of 115 matches
Mail list logo
