> -Original Message-
> From: Patnana, Venkata Sai
> Sent: Friday, June 25, 2021 3:39 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Patnana, Venkata Sai ; Srivatsa, Anusha
> ; Kulkarni, Vandita
> ; Navare, Manasi D
>
> Subject: [PATCH 2/2] drm/i915/display/dsc: Set BPP in the kernel
>
>
== Series Details ==
Series: drm/i915/display/tgl: Implement Wa_14013120569
URL : https://patchwork.freedesktop.org/series/91987/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10285_full -> Patchwork_20481_full
Summary
== Series Details ==
Series: drm/i915/display/tgl: Implement Wa_14013120569
URL : https://patchwork.freedesktop.org/series/91987/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10285 -> Patchwork_20481
Summary
---
**S
== Series Details ==
Series: drm/i915/display/tgl: Implement Wa_14013120569
URL : https://patchwork.freedesktop.org/series/91987/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7b3735152a04 drm/i915/display/tgl: Implement Wa_14013120569
-:20: WARNING:LEADING_SPACE: please, no sp
PCH display HPD IRQ is not detected with default filter value.
So, PP_CONTROL is manually reprogrammed.
Signed-off-by: Madhumitha Tolakanahalli Pradeep
---
.../gpu/drm/i915/display/intel_display_power.c | 8
drivers/gpu/drm/i915/display/intel_hotplug.c | 16
2 f
== Series Details ==
Series: The Following Patches are to Fix the Critical KclockWork Errors in
i915_gem and gt
URL : https://patchwork.freedesktop.org/series/91978/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10285_full -> Patchwork_20480_full
=
On Mon, 2021-06-21 at 16:45 -0700, Anusha Srivatsa wrote:
> Add support to load latest DMC version.
> The Release Notes mentions that this version fixes
> timeout issues.
>
> Cc: Madhumitha Pradeep
> Signed-off-by: Anusha Srivatsa
Patch looks good.
Reviewed-by: Madhumitha Pradeep <
madhumitha.
On Mon, 2021-06-21 at 16:45 -0700, Anusha Srivatsa wrote:
> Add support to the latest DMC firmware.
>
> Cc: Madhunitha Pradeep
> Signed-off-by: Anusha Srivatsa
Patch looks good.
Reviewed-by: Madhumitha Pradeep <
madhumitha.tolakanahalli.prad...@intel.com>
> ---
> drivers/gpu/drm/i915/display
== Series Details ==
Series: drm/i915/gem: Introduce a migrate interface (rev3)
URL : https://patchwork.freedesktop.org/series/91890/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10284_full -> Patchwork_20479_full
Summary
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 3:54 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>Cc: Auld, Matthew ; lkp
>Subject: Re: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>
>
>On 6/28/21 9:50
On 6/28/21 9:50 PM, Ruhl, Michael J wrote:
-Original Message-
From: Thomas Hellström
Sent: Monday, June 28, 2021 3:03 PM
To: Ruhl, Michael J ; intel-
g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc: Auld, Matthew ; lkp
Subject: Re: [PATCH v3 1/5] drm/i915/gem: Implement
On 6/28/21 9:45 PM, Ruhl, Michael J wrote:
-Original Message-
From: dri-devel On Behalf Of
Thomas Hellström
Sent: Monday, June 28, 2021 10:46 AM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc: Thomas Hellström ; Auld, Matthew
Subject: [PATCH v3 5/5] drm/i915/ge
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 3:03 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>Cc: Auld, Matthew ; lkp
>Subject: Re: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>
>
>On 6/28/21 8:11 P
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>Cc: Thomas Hellström ; Auld, Matthew
>
>Subject: [PATCH v3 5/5] drm/i915/gem: Migrate to system at dma-buf map
>t
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>Cc: Auld, Matthew ;
>maarten.lankho...@linux.intel.com; Thomas Hellström
>; Ruhl; Ruhl, Michael J
>
>Subject: [PATCH v3 4/5] drm/i915/gem
On 6/28/21 9:27 PM, Ruhl, Michael J wrote:
-Original Message-
From: Thomas Hellström
Sent: Monday, June 28, 2021 3:15 PM
To: Ruhl, Michael J ; intel-
g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc: Auld, Matthew
Subject: Re: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Intr
>-Original Message-
>From: Thomas Hellström
>Sent: Monday, June 28, 2021 3:15 PM
>To: Ruhl, Michael J ; intel-
>g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>Cc: Auld, Matthew
>Subject: Re: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Introduce a selftest for
>the gem object mi
On 2021-06-01 6:52 a.m., Uma Shankar wrote:
> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> planes have different capabilities, implemented respective
> structure for the HDR planes.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 52 +
On Mon, 2021-06-28 at 18:53 +, Ruhl, Michael J wrote:
> > -Original Message-
> > From: Intel-gfx On Behalf
> > Of
> > Thomas Hellström
> > Sent: Monday, June 28, 2021 10:46 AM
> > To: intel-gfx@lists.freedesktop.org;
> > dri-de...@lists.freedesktop.org
> > Cc: Thomas Hellström ; Aul
== Series Details ==
Series: The Following Patches are to Fix the Critical KclockWork Errors in
i915_gem and gt
URL : https://patchwork.freedesktop.org/series/91978/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10285 -> Patchwork_20480
===
On 6/28/21 8:11 PM, Ruhl, Michael J wrote:
-Original Message-
From: dri-devel On Behalf Of
Thomas Hellström
Sent: Monday, June 28, 2021 10:46 AM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc: Thomas Hellström ; Auld, Matthew
; lkp
Subject: [PATCH v3 1/5] drm/i
>-Original Message-
>From: Intel-gfx On Behalf Of
>Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>Cc: Thomas Hellström ; Auld, Matthew
>
>Subject: [Intel-gfx] [PATCH v3 2/5] drm/i915/gem: Introduce a selftest fo
== Series Details ==
Series: The Following Patches are to Fix the Critical KclockWork Errors in
i915_gem and gt
URL : https://patchwork.freedesktop.org/series/91978/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be ch
== Series Details ==
Series: The Following Patches are to Fix the Critical KclockWork Errors in
i915_gem and gt
URL : https://patchwork.freedesktop.org/series/91978/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4b2a948b3db2 Klock work Fix for NULL dereferencing in i915_gem_tt
>-Original Message-
>From: dri-devel On Behalf Of
>Thomas Hellström
>Sent: Monday, June 28, 2021 10:46 AM
>To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
>Cc: Thomas Hellström ; Auld, Matthew
>; lkp
>Subject: [PATCH v3 1/5] drm/i915/gem: Implement object migration
>
On Tue, Jun 01, 2021 at 03:32:27PM +0530, Anshuman Gupta wrote:
> DG1 and XE_PLD platforms has Audio MMIO/VERBS lies in PG0 power
> well. Adjusting the power domain accordingly to
> POWER_DOMAIN_AUDIO_VERBS for audio detection and POWER_DOMAIN_AUDIO
> for audio playback.
>
> Cc: Ville Syrjälä
> C
On 6/28/21 6:28 PM, Matthew Auld wrote:
On 28/06/2021 15:46, Thomas Hellström wrote:
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
performance
== Series Details ==
Series: drm/i915/gem: Introduce a migrate interface (rev3)
URL : https://patchwork.freedesktop.org/series/91890/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10284 -> Patchwork_20479
Summary
---
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 userspace.
>
> While "max bpc" can be used to change the color depth, there was no way to
> check which one actually go
== Series Details ==
Series: drm/i915/gem: Introduce a migrate interface (rev3)
URL : https://patchwork.freedesktop.org/series/91890/
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/
== Series Details ==
Series: drm/i915/gem: Introduce a migrate interface (rev3)
URL : https://patchwork.freedesktop.org/series/91890/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
673d9747bd21 drm/i915/gem: Implement object migration
fb5a2bfc3766 drm/i915/gem: Introduce a selft
== Series Details ==
Series: drm/i915/display: replace boilerplate code with helper macros (rev2)
URL : https://patchwork.freedesktop.org/series/91967/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10284 -> Patchwork_20476
== Series Details ==
Series: drm: address potential UAF bugs with drm_master ptrs
URL : https://patchwork.freedesktop.org/series/91969/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile
== Series Details ==
Series: Restricted DMA (rev2)
URL : https://patchwork.freedesktop.org/series/91694/
State : failure
== Summary ==
Applying: swiotlb: Refactor swiotlb init functions
Applying: swiotlb: Refactor swiotlb_create_debugfs
Applying: swiotlb: Set dev->dma_io_tlb_mem to the swiotlb
On 28/06/2021 15:46, Thomas Hellström wrote:
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
performance-based migration.
v2:
- Verify that the m
== Series Details ==
Series: drm/i915: Reinstate the mmap ioctl for some platforms (rev3)
URL : https://patchwork.freedesktop.org/series/91865/
State : failure
== Summary ==
Applying: drm/i915: Reinstate the mmap ioctl for some platforms
Using index info to reconstruct a base tree...
M d
On 28/06/2021 15:46, Thomas Hellström wrote:
From: Matthew Auld
A selftest for the gem object migrate functionality. Slightly adapted
from the original by Matthew to the new interface and new fill blit
code.
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Signed-off-by: Mat
On 28/06/2021 15:46, Thomas Hellström wrote:
Objects intended to be used as display framebuffers must reside in
LMEM for discrete. If they happen to not do that, migrate them to
LMEM before pinning.
Signed-off-by: Thomas Hellström
Looks reasonable to me,
Reviewed-by: Matthew Auld
___
On 28/06/2021 15:38, Bommu Krishnaiah wrote:
Signed-off-by: Bommu Krishnaiah
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_e
Signed-off-by: Bommu Krishnaiah
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 23c59ce66cee5..5df7b8af6fdb9 100644
--- a/drivers/gpu/drm/
Signed-off-by: Bommu Krishnaiah
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index cdb2126a159a8..a4673900
Signed-off-by: Bommu Krishnaiah
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index a90f796e85c03..cad33cd49ba95 100644
--- a/drivers/gpu/
Signed-off-by: Bommu Krishnaiah
Cc: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index c39d982c4fa66..97093a9bfccc2 100644
--- a/drivers/gpu/drm
Klock work Fix for NULL dereferencing in i915_gem_ttm.c
original issue statement "Pointer 'sg' returned from call to function
'__i915_gem_object_get_sg' at line 592 may be NULL and will be dereferenced at
line 594."
Klock work Fix for NULL dereferencing in i915_gem_mman.c
original issue statemen
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.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/g
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to recursive locking.
Add a live selft
Objects intended to be used as display framebuffers must reside in
LMEM for discrete. If they happen to not do that, migrate them to
LMEM before pinning.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/display/intel_display.c | 5 -
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 2
From: Matthew Auld
A selftest for the gem object migrate functionality. Slightly adapted
from the original by Matthew to the new interface and new fill blit
code.
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_g
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
performance-based migration.
v2:
- Verify that the memory region given as an id really exists.
(R
We want to be able to explicitly migrate objects between gem memory
regions, initially for display and dma-buf, but there might be more
use-cases coming up.
Introduce a gem migrate interface, add a selftest and use it for
display fb pinning and dma-buf mapping.
This series should make accelerated
On Mon, Jun 28, 2021 at 12:18 PM Tvrtko Ursulin
wrote:
>
>
>
> On 14/05/2021 16:10, Christian König wrote:
> > Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin:
> >>
> >> On 14/05/2021 15:56, Christian König wrote:
> >>> Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
>
> On 14/05/2021 14:53, Ch
Hi "Thomas,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm/drm-next v5.13 next-20210628]
[If your patch is applied to the wrong git
tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Thomas-Hellstr-m/drm-i915-gem-Introduce-a-migrate-interface/20210628-171204
base: git://anongit.
On 6/24/21 9:30 PM, 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 here is to be able to
> -Original Message-
> From: Intel-gfx On Behalf Of
> Srinivas, Vidya
> Sent: 31 May 2021 20:18
> To: Ville Syrjälä
> Cc: igt-...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Lin,
> Charlton
> Subject: Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime:
> Aligne
On 6/28/21 12:59 PM, Matthew Auld wrote:
On 28/06/2021 10:21, Thomas Hellström wrote:
Reinstate the mmap ioctl for all current integrated platforms.
The intention was really to have it disabled for discrete graphics
where we enforce a single mmap mode.
This fixes media on rkl/adl.
v2:
- Added
On 28/06/2021 10:21, Thomas Hellström wrote:
Reinstate the mmap ioctl for all current integrated platforms.
The intention was really to have it disabled for discrete graphics
where we enforce a single mmap mode.
This fixes media on rkl/adl.
v2:
- Added a R-B.
- Fixed up the code comment a bit.
On 6/28/21 12:20 PM, Matthew Auld wrote:
On 28/06/2021 10:38, Thomas Hellström wrote:
Hi,
On 6/28/21 11:12 AM, Matthew Auld wrote:
On 28/06/2021 08:41, Thomas Hellström wrote:
On 6/25/21 2:27 PM, Matthew Auld wrote:
We only support single mode and this should be immutable. For smem
only
p
Quoting Pavel Machek (2021-06-24 12:53:59)
> Hi!
>
> I'm getting graphics problems with 5.13-rc:
>
> Debian 10.9, X, chromium and flightgear is in use. Things were more
> stable than this with previous kernels.
>
> Any ideas?
The error you are seeing:
> [185300.784992] i915 :00:02.0: [drm]
On 28/06/2021 10:38, Thomas Hellström wrote:
Hi,
On 6/28/21 11:12 AM, Matthew Auld wrote:
On 28/06/2021 08:41, Thomas Hellström wrote:
On 6/25/21 2:27 PM, Matthew Auld wrote:
We only support single mode and this should be immutable. For smem only
placements on DGFX this should be WB. On DG1
On 14/05/2021 16:10, Christian König wrote:
Am 14.05.21 um 17:03 schrieb Tvrtko Ursulin:
On 14/05/2021 15:56, Christian König wrote:
Am 14.05.21 um 16:47 schrieb Tvrtko Ursulin:
On 14/05/2021 14:53, Christian König wrote:
David also said that you considered sysfs but were wary of
exposi
On 6/28/21 11:09 AM, Thomas Hellström wrote:
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
performande-based migration.
v2:
- Verify that the
Hi,
On 6/28/21 11:12 AM, Matthew Auld wrote:
On 28/06/2021 08:41, Thomas Hellström wrote:
On 6/25/21 2:27 PM, Matthew Auld wrote:
We only support single mode and this should be immutable. For smem only
placements on DGFX this should be WB. On DG1 everything is snooped,
always, and so should b
On Wed, Jun 23, 2021 at 12:39:29PM -0400, Qian Cai wrote:
>
>
> On 6/18/2021 11:40 PM, 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 different pool
One week!
Don't forget to submit your proposals!
Sam
On Tue, 2021-06-08 at 12:38 +0200, Samuel Iglesias Gonsálvez wrote:
> Kind reminder. Deadline is Sunday, 4 July 2021 :-)
>
> Sam
>
> On Thu, 2021-05-20 at 10:01 +, Szwichtenberg, Radoslaw wrote:
> > Hello!
> >
> > Registration & Call f
On 24.06.21 14:57, Nicholas Piggin wrote:
Excerpts from Paolo Bonzini's message of June 24, 2021 10:41 pm:
On 24/06/21 13:42, Nicholas Piggin wrote:
Excerpts from Nicholas Piggin's message of June 24, 2021 8:34 pm:
Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
KVM support
On Thu, Jun 24, 2021 at 03:19:48PM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Jun 24, 2021 at 11:55:14PM +0800, Claire Chang wrote:
> > This series implements mitigations for lack of DMA access control on
> > systems without an IOMMU, which could result in the DMA accessing the
> > system memory
On 6/24/2021 7:48 AM, Will Deacon wrote:
> Ok, diff below which attempts to tackle the offset issue I mentioned as
> well. Qian Cai -- please can you try with these changes?
This works fine.
>
> Will
>
> --->8
>
> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> index 175b6c
Hi David,
On Thu, 24 Jun 2021 04:57:45 +0100,
David Stevens wrote:
>
> From: David Stevens
>
> Return a struct kvm_pfn_page containing both a pfn and an optional
> struct page from the gfn_to_pfn family of functions. This differentiates
> the gup and follow_fault_pfn cases, which allows caller
On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
> On 2021-06-24 07:05, Claire Chang wrote:
> > On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
> > >
> > > On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
> > > > is_swiotlb_force_bounce at
> > > > /usr/src/linux-ne
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
On 25.06.21 09:36, David Stevens wrote:
From: Nicholas Piggin
It's possible to create a region which maps valid but non-refcounted
pages (e.g., tail pages of non-compound higher order allocations). These
host pages can then be returned by gfn_to_page, gfn_to_pfn, etc., family
of APIs, which
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr/src/linux-next/./include/linux/swiotlb.h:119
is_swiotlb_force_bounce() was the new function introduced i
On Thu, 24 Jun 2021 09:58:00 +0100,
Nicholas Piggin wrote:
>
> Excerpts from David Stevens's message of June 24, 2021 1:57 pm:
> > From: David Stevens
> > out_unlock:
> > if (is_tdp_mmu_root(vcpu->kvm, vcpu->arch.mmu->root_hpa))
> > read_unlock(&vcpu->kvm->mmu_lock);
> > els
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
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
On Thu, Jun 24, 2021 at 12:34:09PM +0100, Robin Murphy wrote:
> On 2021-06-24 12:18, Will Deacon wrote:
> > On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
> > > On 2021-06-24 07:05, Claire Chang wrote:
> > > > On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
> > > > >
> > >
On 6/18/2021 11:40 PM, 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 different pools.
>
> Signed-off-by: Claire Chang
> Reviewed-by: Christoph Hellwig
As per commit 22be87401289 ("drm: TODO: Add DRM_MODESET_LOCK_ALL*
conversion to todo.rst"),
drm_modeset_lock_all()/drm_modeset_unlock_all() and boilerplate code
surrounding instances of drm_modeset_lock_all_ctx() with a local acquire
context should be replaced with the relevant helper macros.
Sign
On 2021-06-24 12:18, Will Deacon wrote:
On Thu, Jun 24, 2021 at 12:14:39PM +0100, Robin Murphy wrote:
On 2021-06-24 07:05, Claire Chang wrote:
On Thu, Jun 24, 2021 at 1:43 PM Christoph Hellwig wrote:
On Wed, Jun 23, 2021 at 02:44:34PM -0400, Qian Cai wrote:
is_swiotlb_force_bounce at /usr/s
As per commit 22be87401289 ("drm: TODO: Add DRM_MODESET_LOCK_ALL*
conversion to todo.rst"),
drm_modeset_lock_all()/drm_modeset_unlock_all() and boilerplate code
surronding instances of drm_modeset_lock_all_ctx() with a local acquire
context should be replaced with the relevant helper macros.
Signe
On 6/23/2021 2:37 PM, Will Deacon wrote:
> On Wed, Jun 23, 2021 at 12:39:29PM -0400, Qian Cai wrote:
>>
>>
>> On 6/18/2021 11:40 PM, 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
On Thu, 24 Jun 2021 04:57:47 +0100,
David Stevens wrote:
>
> From: David Stevens
>
> Avoid converting pfns returned by follow_fault_pfn to struct pages to
> transiently take a reference. The reference was originally taken to
> match the reference taken by gup. However, pfns returned by
> follow
On 23/6/21 7:37 pm, Desmond Cheong Zhi Xi wrote:
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
cou
Reinstate the mmap ioctl for all current integrated platforms.
The intention was really to have it disabled for discrete graphics
where we enforce a single mmap mode.
This fixes media on rkl/adl.
v2:
- Added a R-B.
- Fixed up the code comment a bit.
v3:
- Added an A-B.
- Point out in the commit m
On 28/06/2021 08:41, Thomas Hellström wrote:
On 6/25/21 2:27 PM, Matthew Auld wrote:
We only support single mode and this should be immutable. For smem only
placements on DGFX this should be WB. On DG1 everything is snooped,
always, and so should be coherent.
I915_GEM_DOMAIN_GTT looks like it'
Objects intended to be used as display framebuffers must reside in
LMEM for discrete. If they happen to not do that, migrate them to
LMEM before pinning.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/display/intel_display.c | 5 -
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 2
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to recursive locking.
Add a live selft
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.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/g
From: Matthew Auld
A selftest for the gem object migrate functionality. Slightly adapted
from the original by Matthew to the new interface and new fill blit
code.
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_g
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
performande-based migration.
v2:
- Verify that the memory region given as an id really exists.
(R
We want to be able to explicitly migrate objects between gem memory
regions, initially for display and dma-buf, but there might be more
use-cases coming up.
Introduce a gem migrate interface, add a selftest and use it for
display fb pinning and dma-buf mapping.
This series should make accelerated
On 6/25/21 2:27 PM, Matthew Auld wrote:
We only support single mode and this should be immutable. For smem only
placements on DGFX this should be WB. On DG1 everything is snooped,
always, and so should be coherent.
I915_GEM_DOMAIN_GTT looks like it's for the aperture which is now gone
for DGFX,
On 6/25/21 2:27 PM, Matthew Auld wrote:
This is already the case for our kernel internal mappings, and since we
now only support a single mode this should always be WC if the object
can be placed in lmem.
v2: rebase and also update set_domain
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
94 matches
Mail list logo
