Am 27.05.21 um 17:51 schrieb Thomas Hellström:
On Thu, 2021-05-27 at 17:32 +0200, Christian König wrote:
Am 27.05.21 um 17:05 schrieb Thomas Hellström:
On Thu, 2021-05-27 at 17:01 +0200, Thomas Hellström wrote:
On Thu, 2021-05-27 at 16:54 +0200, Christian König wrote:
Am 27.05.21 um 16:19 sch
Hi Dave & Daniel,
Here's drm-intel-gt-next pull request.
Most notably it has the reworked DG1 uAPI (behind CONFIG_BROKEN)
as requested. Important fix for Gitlab issues #3293 and #3450 and
one another kernel crash. Adds missing workarounds for Gen11 and
Gen12. Hiding of modparams for compiled-out
Quoting Joonas Lahtinen (2021-05-28 10:25:57)
> Hi Dave & Daniel,
>
> Here's drm-intel-gt-next pull request.
>
> Most notably it has the reworked DG1 uAPI (behind CONFIG_BROKEN)
> as requested. Important fix for Gitlab issues #3293 and #3450 and
> one another kernel crash. Adds missing workaround
On Fri, 2021-05-28 at 09:16 +0200, Christian König wrote:
> Am 27.05.21 um 17:51 schrieb Thomas Hellström:
> > On Thu, 2021-05-27 at 17:32 +0200, Christian König wrote:
> > > Am 27.05.21 um 17:05 schrieb Thomas Hellström:
> > > > On Thu, 2021-05-27 at 17:01 +0200, Thomas Hellström wrote:
> > > > >
== Series Details ==
Series: drm/i915/adl_p: Same slices mask is not same Dbuf state
URL : https://patchwork.freedesktop.org/series/90660/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10142_full -> Patchwork_20222_full
Sum
On 5/21/21 11:09 AM, Daniel Vetter wrote:
No need to set it explicitly.
Signed-off-by: Daniel Vetter
Cc: Laurentiu Palcu
Cc: Lucas Stach
Cc: Shawn Guo
Cc: Sascha Hauer
Cc: Pengutronix Kernel Team
Cc: Fabio Estevam
Cc: NXP Linux Team
Cc: Philipp Zabel
Cc: Paul Cercueil
Cc: Chun-Kuang
Use DEVICE_ATTR_RO() helper instead of plain DEVICE_ATTR(),
which makes the code a bit shorter and easier to read.
Signed-off-by: YueHaibing
---
drivers/gpu/drm/i915/i915_pmu.c | 8 +++-
drivers/gpu/drm/i915/i915_sysfs.c | 30 +++---
2 files changed, 18 insertions(
This is an initial patch series to move discrete memory management over to
TTM. It will be followed up shortly with adding more functionality.
The buddy allocator is temporarily removed along with its selftests and
It is replaced with the TTM range manager and some selftests are adjusted
to accoun
Any sleeping dma_resv lock taken while the vma pages_mutex is held
will cause a lockdep splat.
Move the i915_gem_object_pin_pages() call out of the pages_mutex
critical section.
Signed-off-by: Thomas Hellström
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_vma.c | 29 +
We are currently sharing the VM reservation locks across a number of
gem objects with page-table memory. Since TTM will individiualize the
reservation locks when freeing objects, including accessing the shared
locks, make sure that the shared locks are not freed until that is done.
For PPGTT we add
All users of this function actually want the dma segment sizes, but that's
not what's calculated. Fix that and rename the function to
i915_sg_dma_sizes to reflect what's calculated.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
Temporarily remove the buddy allocator and related selftests
and hook up the TTM range manager for i915 regions.
Also modify the mock region selftests somewhat to account for a
fragmenting manager.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld #v2
---
v2:
- Fix an error unwind in lm
Embed a struct ttm_buffer_object into the i915 gem object, making sure
we alias the gem object part. It's a bit unfortunate that the
struct ttm_buffer_ojbect embeds a gem object since we otherwise could
make the TTM part private to the TTM backend, and use the usual
i915 gem object for the other ba
Reading out of write-combining mapped memory is typically very slow
since the CPU doesn't prefetch. However some archs have special
instructions to do this.
So add a best-effort memcpy_from_wc taking dma-buf-map pointer
arguments that attempts to use a fast prefetching memcpy and
otherwise falls b
If the bo is idle when calling ttm_bo_pipeline_gutting(), we unnecessarily
create a ghost object and push it out to delayed destroy.
Fix this by adding a path for idle, and document the function.
Also avoid having the bo end up in a bad state vulnerable to user-space
triggered kernel BUGs if the c
Use fast wc memcpy for reading out of wc memory for TTM bo moves.
Cc: Dave Airlie
Cc: Christian König
Cc: Daniel Vetter
Signed-off-by: Thomas Hellström
Reviewed-by: Christian König #v4
--
v4:
- Clarify when we try drm_memcpy_from_wc_dbm (Reported by Matthew Auld)
- Be paranoid about when drm_
We are calling the eviction_valuable driver callback at eviction time to
determine whether we actually can evict a buffer object.
The upcoming i915 TTM backend needs the same functionality for swapout,
and that might actually be beneficial to other drivers as well.
Add an eviction_valuable call al
The internal ttm_bo_util memcpy uses ioremap functionality, and while it
probably might be possible to use it for copying in- and out of
sglist represented io memory, using io_mem_reserve() / io_mem_free()
callbacks, that would cause problems with fault().
Instead, implement a method mapping page-b
Most logical place to introduce TTM buffer objects is as an i915
gem object backend. We need to add some ops to account for added
functionality like delayed delete and LRU list manipulation.
Initially we support only LMEM and SYSTEM memory, but SYSTEM
(which in this case means evicted LMEM objects
From: Maarten Lankhorst
The platform should exclusively use mmap_offset, one less path to worry
about for discrete.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gp
Since objects can be migrated or evicted when not pinned or locked,
update the checks for lmem residency or future residency so that
the value returned is not immediately stale.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
v2: Simplify i915_gem_object_migratable() (Reported by M
From: Maarten Lankhorst
This allows drivers to distinguish between different types of vma_node's.
The readonly flag was unused and is thus removed.
This is a temporary solution, until i915 is converted completely to
use ttm for bo's.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Thomas Hellstr
From: Maarten Lankhorst
Use the ttm handlers for servicing page faults, and vm_access.
We do our own validation of read-only access, otherwise use the
ttm handlers as much as possible.
Because the ttm handlers expect the vma_node at vma->base, we slightly
need to massage the mmap handlers to lo
Am 28.05.21 um 09:33 schrieb Thomas Hellström:
On Fri, 2021-05-28 at 09:16 +0200, Christian König wrote:
Am 27.05.21 um 17:51 schrieb Thomas Hellström:
On Thu, 2021-05-27 at 17:32 +0200, Christian König wrote:
Am 27.05.21 um 17:05 schrieb Thomas Hellström:
On Thu, 2021-05-27 at 17:01 +0200, T
On 5/28/21 4:10 PM, Christian König wrote:
Am 28.05.21 um 09:33 schrieb Thomas Hellström:
On Fri, 2021-05-28 at 09:16 +0200, Christian König wrote:
Am 27.05.21 um 17:51 schrieb Thomas Hellström:
On Thu, 2021-05-27 at 17:32 +0200, Christian König wrote:
Am 27.05.21 um 17:05 schrieb Thomas Hel
Am 27.05.21 um 16:47 schrieb Thomas Hellström:
Reading out of write-combining mapped memory is typically very slow
since the CPU doesn't prefetch. However some archs have special
instructions to do this.
So add a best-effort memcpy_from_wc taking dma-buf-map pointer
arguments that attempts to us
Am 28.05.21 um 16:17 schrieb Thomas Hellström:
On 5/28/21 4:10 PM, Christian König wrote:
Am 28.05.21 um 09:33 schrieb Thomas Hellström:
On Fri, 2021-05-28 at 09:16 +0200, Christian König wrote:
Am 27.05.21 um 17:51 schrieb Thomas Hellström:
On Thu, 2021-05-27 at 17:32 +0200, Christian Kön
On 5/28/21 4:19 PM, Christian König wrote:
Am 27.05.21 um 16:47 schrieb Thomas Hellström:
Reading out of write-combining mapped memory is typically very slow
since the CPU doesn't prefetch. However some archs have special
instructions to do this.
So add a best-effort memcpy_from_wc taking dma-
Am 28.05.21 um 17:10 schrieb Thomas Hellström:
On 5/28/21 4:19 PM, Christian König wrote:
Am 27.05.21 um 16:47 schrieb Thomas Hellström:
Reading out of write-combining mapped memory is typically very slow
since the CPU doesn't prefetch. However some archs have special
instructions to do this.
== Series Details ==
Series: drm/i915/dg1: Add HWMON power sensor support (rev5)
URL : https://patchwork.freedesktop.org/series/88459/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b8dd5867dbe1 drm/i915/dg1: Add HWMON power sensor support
-:22: WARNING:FILE_PATH_CHANGES: added,
== Series Details ==
Series: drm/i915/dg1: Add HWMON power sensor support (rev5)
URL : https://patchwork.freedesktop.org/series/88459/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10147 -> Patchwork_20230
Summary
---
== Series Details ==
Series: drm/i915: use DEVICE_ATTR_RO macro
URL : https://patchwork.freedesktop.org/series/90730/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10147 -> Patchwork_20231
Summary
---
**SUCCESS**
== Series Details ==
Series: Move LMEM (VRAM) management over to TTM (rev2)
URL : https://patchwork.freedesktop.org/series/90681/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b97007c879b9 drm/i915: Untangle the vma pages_mutex
b5c847f763fa drm/i915: Don't free shared locks whi
== Series Details ==
Series: Move LMEM (VRAM) management over to TTM (rev2)
URL : https://patchwork.freedesktop.org/series/90681/
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/
Would it be possible to apply
58586680ffad "drm/i915: Disable atomics in L3 for gen9"
to stable kernels?
I'm finding it quite easy to crash my Thinkpad X1 Carbon 6th gen with
Blender on Fedora 34 (which is using the 5.11.y kernels). It applies
cleanly, and I've been running 5.11.16 with
== Series Details ==
Series: Move LMEM (VRAM) management over to TTM (rev2)
URL : https://patchwork.freedesktop.org/series/90681/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10147 -> Patchwork_20232
Summary
---
**S
== Series Details ==
Series: Finish conversion to GRAPHICS_VER
URL : https://patchwork.freedesktop.org/series/90693/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10145_full -> Patchwork_20228_full
Summary
---
**FAIL
== Series Details ==
Series: Revert "i915: use io_mapping_map_user"
URL : https://patchwork.freedesktop.org/series/90696/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10145_full -> Patchwork_20229_full
Summary
---
*
Any further advice on tracing what is triggering what appears to be the
limitation of the clock? My guess is it is imposing a DVI Single-Link speed
(165000) limitation on the dual-link DVI adapter.
> TMDS clock 25000-165000
I am able to override in xorg with xrandr to 268500
Per Ville's reques
== Series Details ==
Series: drm/i915: use DEVICE_ATTR_RO macro
URL : https://patchwork.freedesktop.org/series/90730/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10147_full -> Patchwork_20231_full
Summary
---
**FAI
In some cases, the MAX_LANE_COUNT in the register at DCPD Address 0002h
may be updated by LTTPR in non-transparent mode while reading DPRX Caps
registers, e.g., the lane count is changed from 2 to 4. This may cause
Link Training failure because of the updated lane count, which might not
be supporte
== Series Details ==
Series: drm/i915: Reading DPRX caps in LTTPR transparent mode after LTTPR
detection
URL : https://patchwork.freedesktop.org/series/90752/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
648bed0f9086 drm/i915: Reading DPRX caps in LTTPR transparent mode after
In some cases, the MAX_LANE_COUNT in the register at DCPD Address 0002h
may be updated by LTTPR in non-transparent mode while reading DPRX Caps
registers, e.g., the lane count is changed from 2 to 4. This may cause
Link Training failure because of the updated lane count, which might not
be supporte
On Fri, May 28, 2021 at 01:25:43PM -0400, J. Bruce Fields wrote:
> Would it be possible to apply
>
> 58586680ffad "drm/i915: Disable atomics in L3 for gen9"
>
> to stable kernels?
>
> I'm finding it quite easy to crash my Thinkpad X1 Carbon 6th gen with
> Blender on Fedora 34 (which is usi
== Series Details ==
Series: drm/i915: Reading DPRX caps in LTTPR transparent mode after LTTPR
detection
URL : https://patchwork.freedesktop.org/series/90752/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10149 -> Patchwork_20233
==
== Series Details ==
Series: drm/i915: Reading DPRX caps in LTTPR transparent mode after LTTPR
detection (rev2)
URL : https://patchwork.freedesktop.org/series/90752/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4716d8575853 drm/i915: Reading DPRX caps in LTTPR transparent mod
== Series Details ==
Series: Move LMEM (VRAM) management over to TTM (rev2)
URL : https://patchwork.freedesktop.org/series/90681/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10147_full -> Patchwork_20232_full
Summary
== Series Details ==
Series: drm/i915: Reading DPRX caps in LTTPR transparent mode after LTTPR
detection (rev2)
URL : https://patchwork.freedesktop.org/series/90752/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10149 -> Patchwork_20234
===
On Sat, 2021-05-29 at 13:17 +0800, William Tseng wrote:
> In some cases, the MAX_LANE_COUNT in the register at DCPD Address
> 0002h
> may be updated by LTTPR in non-transparent mode while reading DPRX
> Caps
> registers, e.g., the lane count is changed from 2 to 4. This may
> cause
> Link Training
49 matches
Mail list logo
