Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot

On Sun, May 09, 2021 at 03:33:29AM +0800, youling257 wrote: > This patch cause "x86/PAT : surfaceflinger:1440 map pfn RAM range req > write-combining for [mem 0x064a2000-0x064a2fff], got write-back" problem. > my 2GB ram Bay trail z3735f tablet runing on android-x86, "i915: fix > remap_io_sg to v

Re: [Intel-gfx] [PATCH] drm/i915/gt: Do release kernel context if breadcrumb measure fails

On 07/05/2021 15:42, Janusz Krzysztofik wrote: Commit fb5970da1b42 ("drm/i915/gt: Use the kernel_context to measure the breadcrumb size") reordered some operations inside engine_init_common() and added an error unwind path to that function. In that path, a reference to a kernel context candida

Re: [Intel-gfx] [PATCH] drm/i915/gt: Do release kernel context if breadcrumb measure fails

Hi Tvrtko, On poniedziałek, 10 maja 2021 11:14:46 CEST Tvrtko Ursulin wrote: > > On 07/05/2021 15:42, Janusz Krzysztofik wrote: > > Commit fb5970da1b42 ("drm/i915/gt: Use the kernel_context to measure the > > breadcrumb size") reordered some operations inside engine_init_common() > > and added an

Re: [Intel-gfx] [PATCH] drm/i915/stolen: shuffle around init_memory_region

On 07/05/2021 10:59, Matthew Auld wrote: We generally want to first call i915_gem_object_init_memory_region() before calling into get_pages(), since this sets up various bits of state which might be needed there. Currently for stolen this doesn't matter much, but it might in the future, and at t

Re: [Intel-gfx] [PATCH] drm/i915/gt: Do release kernel context if breadcrumb measure fails

On 10/05/2021 10:15, Janusz Krzysztofik wrote: Hi Tvrtko, On poniedziałek, 10 maja 2021 11:14:46 CEST Tvrtko Ursulin wrote: On 07/05/2021 15:42, Janusz Krzysztofik wrote: Commit fb5970da1b42 ("drm/i915/gt: Use the kernel_context to measure the breadcrumb size") reordered some operations insi

Re: [Intel-gfx] [PATCH v3 1/5] drm/connector: Create a helper to attach the hdr_output_metadata property

Hi, On Fri, Apr 30, 2021 at 11:44:47AM +0200, Maxime Ripard wrote: > All the drivers that implement HDR output call pretty much the same > function to initialise the hdr_output_metadata property, and while the > creation of that property is in a helper, every driver uses the same > code to attach

Re: [Intel-gfx] [PATCH] drm/i915/display: relax 2big checking around initial fb

On Fri, 7 May 2021, Auld, Matthew wrote: > >From: Chris Wilson > >The kernel prefers enabling fbc over the initial fb, since this leads to >actual runtime power savings, so if the initial fb is deemed too big >using some heuristic, then we simply skip allocating stolen for it. >However if the k

[Intel-gfx] [PATCH RFC] Revert "drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure"

This reverts commit 2bbd6dba84d44219387df051a1c799b7bac46099. Since 5.12-rc2, my Dell XPS-15 laptop has had a blank screen on boot. The system seems to run fine other than having no display, I am able to ssh into the machine. I don't see anything interesting in the dmesg log. I bisected the proble

Re: [Intel-gfx] REGRESSION with 5.12: Suspend not working on Toshiba notebook - NOT FIXED

On Sat, May 08, 2021 at 01:52:54AM +0200, Andreas Friedrich wrote: Hello Joonas, ... > Fixed with 5.12.2 > drm/i915: Disable runtime power management during shutdown, > commit 7962893ecb853aa7c8925ce237ab6c4274cfc1c7 upstream. I was wrong. One of 10 suspend still hangs. Best regards Andreas

Re: [Intel-gfx] [PATCH RFC] Revert "drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure"

On Sat, May 8, 2021 at 9:44 PM Paul Zimmerman wrote: > > This reverts commit 2bbd6dba84d44219387df051a1c799b7bac46099. > > Since 5.12-rc2, my Dell XPS-15 laptop has had a blank screen on boot. > The system seems to run fine other than having no display, I am able > to ssh into the machine. I don't

Re: [Intel-gfx] REGRESSION with 5.12: Suspend not working on Toshiba notebook - FIXED

On Mon, May 03, 2021 at 02:00:50PM +0200, Andreas Friedrich wrote: Hello Joonas, > ... > > It's very possible that it can be i915 bug. What you can try is to > > blacklist i915 module and operate the system with SSH and see if the > > latest kernel still freezes? > This is a good idea. I have disa

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure

Hi, on my Dell XPS 15 9570 laptop I might have a regression with Arch Linux (kernel 5.12.2-arch1-1: during boot the laptop monitor goes black while external monitors still works... Panich Il giorno lun 11 gen 2021 alle ore 19:28 Ville Syrjälä < ville.syrj...@linux.intel.com> ha scritto: > On

Re: [Intel-gfx] [PATCH 4/4] i915: fix remap_io_sg to verify the pgprot

This patch cause "x86/PAT : surfaceflinger:1440 map pfn RAM range req write-combining for [mem 0x064a2000-0x064a2fff], got write-back" problem. my 2GB ram Bay trail z3735f tablet runing on android-x86, "i915: fix remap_io_sg to verify the pgprot" cause this problem. 05-09 02:59:25.099 0

[Intel-gfx] [PATCH v6 00/15] Restricted DMA

From: Claire Chang 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 at unexpected times and/or unexpected addresses, possibly leading to data leakage or corruption. For example, we plan to use

[Intel-gfx] [PATCH v6 01/15] swiotlb: Refactor swiotlb init functions

Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct initialization to make the code reusable. Note that we now also call set_memory_decrypted in swiotlb_init_with_tbl. Signed-off-by: Claire Chang --- kernel/dma/swiotlb.c | 51 ++-- 1 fi

[Intel-gfx] [PATCH v6 02/15] swiotlb: Refactor swiotlb_create_debugfs

Split the debugfs creation to make the code reusable for supporting different bounce buffer pools, e.g. restricted DMA pool. Signed-off-by: Claire Chang --- kernel/dma/swiotlb.c | 22 -- 1 file changed, 16 insertions(+), 6 deletions(-) diff --git a/kernel/dma/swiotlb.c b/ker

[Intel-gfx] [PATCH v6 03/15] swiotlb: Add DMA_RESTRICTED_POOL

Add a new kconfig symbol, DMA_RESTRICTED_POOL, for restricted DMA pool. Signed-off-by: Claire Chang --- kernel/dma/Kconfig | 14 ++ 1 file changed, 14 insertions(+) diff --git a/kernel/dma/Kconfig b/kernel/dma/Kconfig index 77b405508743..3e961dc39634 100644 --- a/kernel/dma/Kconfig

[Intel-gfx] [PATCH v6 04/15] swiotlb: Add restricted DMA pool initialization

Add the initialization function to create restricted DMA pools from matching reserved-memory nodes. Signed-off-by: Claire Chang --- include/linux/device.h | 4 +++ include/linux/swiotlb.h | 3 +- kernel/dma/swiotlb.c| 79 + 3 files changed, 85 inser

[Intel-gfx] [PATCH v6 05/15] swiotlb: Add a new get_io_tlb_mem getter

Add a new getter, get_io_tlb_mem, to help select the io_tlb_mem struct. The restricted DMA pool is preferred if available. Signed-off-by: Claire Chang --- include/linux/swiotlb.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h in

[Intel-gfx] [PATCH v6 06/15] swiotlb: Update is_swiotlb_buffer to add a struct device argument

Update is_swiotlb_buffer to add a struct device argument. This will be useful later to allow for restricted DMA pool. Signed-off-by: Claire Chang --- drivers/iommu/dma-iommu.c | 12 ++-- drivers/xen/swiotlb-xen.c | 2 +- include/linux/swiotlb.h | 6 +++--- kernel/dma/direct.c |

[Intel-gfx] [PATCH v6 07/15] swiotlb: Update is_swiotlb_active to add a struct device argument

Update is_swiotlb_active to add a struct device argument. This will be useful later to allow for restricted DMA pool. Signed-off-by: Claire Chang --- drivers/gpu/drm/i915/gem/i915_gem_internal.c | 2 +- drivers/gpu/drm/nouveau/nouveau_ttm.c| 2 +- drivers/pci/xen-pcifront.c

[Intel-gfx] [PATCH v6 08/15] swiotlb: Bounce data from/to restricted DMA pool if available

Regardless of swiotlb setting, the restricted DMA pool is preferred if available. The restricted DMA pools provide a basic level of protection against the DMA overwriting buffer contents at unexpected times. However, to protect against general data leakage and system memory corruption, the system

[Intel-gfx] [PATCH v6 09/15] swiotlb: Move alloc_size to find_slots

Move the maintenance of alloc_size to find_slots for better code reusability later. Signed-off-by: Claire Chang --- kernel/dma/swiotlb.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index 3f1ad080a4bc..ef04d8f7708f 100

[Intel-gfx] [PATCH v6 11/15] dma-direct: Add a new wrapper __dma_direct_free_pages()

Add a new wrapper __dma_direct_free_pages() that will be useful later for swiotlb_free(). Signed-off-by: Claire Chang --- kernel/dma/direct.c | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 078f7087e466..eb409832

[Intel-gfx] [PATCH v6 10/15] swiotlb: Refactor swiotlb_tbl_unmap_single

Add a new function, release_slots, to make the code reusable for supporting different bounce buffer pools, e.g. restricted DMA pool. Signed-off-by: Claire Chang --- kernel/dma/swiotlb.c | 35 --- 1 file changed, 20 insertions(+), 15 deletions(-) diff --git a/kern

[Intel-gfx] [PATCH v6 12/15] swiotlb: Add restricted DMA alloc/free support.

Add the functions, swiotlb_{alloc,free} to support the memory allocation from restricted DMA pool. Signed-off-by: Claire Chang --- include/linux/swiotlb.h | 4 kernel/dma/swiotlb.c| 35 +-- 2 files changed, 37 insertions(+), 2 deletions(-) diff --git a/

[Intel-gfx] [PATCH v6 13/15] dma-direct: Allocate memory from restricted DMA pool if available

The restricted DMA pool is preferred if available. The restricted DMA pools provide a basic level of protection against the DMA overwriting buffer contents at unexpected times. However, to protect against general data leakage and system memory corruption, the system needs to provide a way to lock

[Intel-gfx] [PATCH v6 14/15] dt-bindings: of: Add restricted DMA pool

Introduce the new compatible string, restricted-dma-pool, for restricted DMA. One can specify the address and length of the restricted DMA memory region by restricted-dma-pool in the reserved-memory node. Signed-off-by: Claire Chang --- .../reserved-memory/reserved-memory.txt | 27

[Intel-gfx] [PATCH v6 15/15] of: Add plumbing for restricted DMA pool

If a device is not behind an IOMMU, we look up the device node and set up the restricted DMA when the restricted-dma-pool is presented. Signed-off-by: Claire Chang --- drivers/of/address.c| 25 + drivers/of/device.c | 3 +++ drivers/of/of_private.h | 5 + 3

Re: [Intel-gfx] [PATCH v5 00/16] Restricted DMA

v6: https://lore.kernel.org/patchwork/cover/1423201/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Revert "drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure"

== Series Details == Series: Revert "drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure" URL : https://patchwork.freedesktop.org/series/89941/ State : failure == Summary == Applying: Revert "drm/i915: Try to use fast+narrow link on eDP again an

[Intel-gfx] [PATCH 44/53] docs: gpu: avoid using UTF-8 chars

While UTF-8 characters can be used at the Linux documentation, the best is to use them only when ASCII doesn't offer a good replacement. So, replace the occurences of the following UTF-8 characters: - U+2019 ('’'): RIGHT SINGLE QUOTATION MARK Signed-off-by: Mauro Carvalho Chehab --- Doc

[Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII

There are several UTF-8 characters at the Kernel's documentation. Several of them were due to the process of converting files from DocBook, LaTeX, HTML and Markdown. They were probably introduced by the conversion tools used on that time. Other UTF-8 characters were added along the time, but they

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Restricted DMA (rev2)

== Series Details == Series: Restricted DMA (rev2) URL : https://patchwork.freedesktop.org/series/89341/ State : failure == Summary == Applying: swiotlb: Refactor swiotlb init functions error: sha1 information is lacking or useless (kernel/dma/swiotlb.c). error: could not build fake ancestor h

Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII

On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote: > There are several UTF-8 characters at the Kernel's documentation. > > Several of them were due to the process of converting files from > DocBook, LaTeX, HTML and Markdown. They were probably introduced > by the conversion tools used

Re: [Intel-gfx] [PATCH 44/53] docs: gpu: avoid using UTF-8 chars

On Mon, 10 May 2021, Mauro Carvalho Chehab wrote: > While UTF-8 characters can be used at the Linux documentation, > the best is to use them only when ASCII doesn't offer a good replacement. > So, replace the occurences of the following UTF-8 characters: > > - U+2019 ('’'): RIGHT SINGLE QUOT

Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII

On 10.05.21 12:26, Mauro Carvalho Chehab wrote: > > As Linux developers are all around the globe, and not everybody has UTF-8 > as their default charset, better to use UTF-8 only on cases where it is really > needed. > […] > The remaining patches on series address such cases on *.rst files and >

Re: [Intel-gfx] [PATCH 44/53] docs: gpu: avoid using UTF-8 chars

On Mon, May 10, 2021 at 12:26:56PM +0200, Mauro Carvalho Chehab wrote: > While UTF-8 characters can be used at the Linux documentation, > the best is to use them only when ASCII doesn't offer a good replacement. > So, replace the occurences of the following UTF-8 characters: > > - U+2019 ('’

[Intel-gfx] [PATCH v7 3/3] drm/i915/display: Use YCbCr420 as fallback when RGB fails

When encoder validation of a display mode fails, retry with less bandwidth heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups to support 4k60Hz output, which previously failed silently. AMDGPU had nearly the exact same issue. This problem description is therefore copied fro

[Intel-gfx] [PATCH v7 2/3] drm/i915/display: Restructure output format computation for better expandability

Couples the decission between RGB and YCbCr420 mode and the check if the port clock can archive the required frequency. Other checks and configuration steps that where previously done in between can also be done before or after. This allows for are cleaner implementation of retrying different colo

[Intel-gfx] [PATCH v7 0/3] drm/i915/display: Try YCbCr420 color when RGB fails

When encoder validation of a display mode fails, retry with less bandwidth heavy YCbCr420 color mode, if available. This enables some HDMI 1.4 setups to support 4k60Hz output, which previously failed silently. AMDGPU had nearly the exact same issue. This problem description is therefore copied fro

[Intel-gfx] [PATCH v7 1/3] drm/i915/display: New function to avoid duplicate code in upcomming commits

Moves some checks that later will be performed 2 times to an own function. This avoids duplicate code later on. Signed-off-by: Werner Sembach --- drivers/gpu/drm/i915/display/intel_hdmi.c | 42 +++ 1 file changed, 27 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/dr

[Intel-gfx] [PATCH] drm/i915: Only set bind_async_flags when concurrent access wa is not active.

Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 4 +++- drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c index 1aee5e6b1b23..de3aa7

Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII

On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote: > This patch series is doing conversion only when using ASCII makes > more sense than using UTF-8. > > See, a number of converted documents ended with weird characters > like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specifi

Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915

On 10/05/2021 02:11, Jason Ekstrand wrote: On May 9, 2021 12:12:36 Martin Peres wrote: Hi, On 06/05/2021 22:13, Matthew Brost wrote: Basic GuC submission support. This is the first bullet point in the upstreaming plan covered in the following RFC [1]. At a very high level the GuC is a piece

Re: [Intel-gfx] [PATCH RFC] Revert "drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure"

On 9.5.2021 7.43, Paul Zimmerman wrote: This reverts commit 2bbd6dba84d44219387df051a1c799b7bac46099. Since 5.12-rc2, my Dell XPS-15 laptop has had a blank screen on boot. The system seems to run fine other than having no display, I am able to ssh into the machine. I don't see anything interesti

Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII

On Mon, May 10, 2021 at 02:16:16PM +0100, Edward Cree wrote: > On 10/05/2021 12:55, Mauro Carvalho Chehab wrote: > > The main point on this series is to replace just the occurrences > > where ASCII represents the symbol equally well > > > - U+2014 ('—'): EM DASH > Em dash is not the same thing

Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII

On 10/05/2021 12:55, Mauro Carvalho Chehab wrote: > The main point on this series is to replace just the occurrences > where ASCII represents the symbol equally well > - U+2014 ('—'): EM DASH Em dash is not the same thing as hyphen-minus, and the latter does not serve 'equally well'. Peopl

Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII

Em Mon, 10 May 2021 14:16:16 +0100 Edward Cree escreveu: > On 10/05/2021 12:55, Mauro Carvalho Chehab wrote: > > The main point on this series is to replace just the occurrences > > where ASCII represents the symbol equally well > > > - U+2014 ('—'): EM DASH > Em dash is not the same thi

Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII

Em Mon, 10 May 2021 12:52:44 +0200 Thorsten Leemhuis escreveu: > On 10.05.21 12:26, Mauro Carvalho Chehab wrote: > > > > As Linux developers are all around the globe, and not everybody has UTF-8 > > as their default charset, better to use UTF-8 only on cases where it is > > really > > needed. >

Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII

On 10/05/2021 14:38, Mauro Carvalho Chehab wrote: > Em Mon, 10 May 2021 14:16:16 +0100 > Edward Cree escreveu: >> But what kinds of things with × or — in are going to be grept for? > > Actually, on almost all places, those aren't used inside math formulae, but > instead, they describe video some

Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII

Hi David, Em Mon, 10 May 2021 11:54:02 +0100 David Woodhouse escreveu: > On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote: > > There are several UTF-8 characters at the Kernel's documentation. > > > > Several of them were due to the process of converting files from > > DocBook, La

Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII

Em Mon, 10 May 2021 13:19:50 +0200 Mauro Carvalho Chehab escreveu: > Em Mon, 10 May 2021 12:52:44 +0200 > Thorsten Leemhuis escreveu: > > > On 10.05.21 12:26, Mauro Carvalho Chehab wrote: > > > > > > As Linux developers are all around the globe, and not everybody has UTF-8 > > > as their defa

Re: [Intel-gfx] [PATCH v6 01/15] swiotlb: Refactor swiotlb init functions

Looks good, Reviewed-by: Christoph Hellwig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 02/15] swiotlb: Refactor swiotlb_create_debugfs

Looks good, Reviewed-by: Christoph Hellwig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v6 04/15] swiotlb: Add restricted DMA pool initialization

> +#ifdef CONFIG_DMA_RESTRICTED_POOL > +#include > +#include > +#include > +#include > +#include > +#endif I don't think any of this belongs into swiotlb.c. Marking swiotlb_init_io_tlb_mem non-static and having all this code in a separate file is probably a better idea. > +#ifdef CONFIG_DMA

Re: [Intel-gfx] [PATCH v6 05/15] swiotlb: Add a new get_io_tlb_mem getter

> +static inline struct io_tlb_mem *get_io_tlb_mem(struct device *dev) > +{ > +#ifdef CONFIG_DMA_RESTRICTED_POOL > + if (dev && dev->dma_io_tlb_mem) > + return dev->dma_io_tlb_mem; > +#endif /* CONFIG_DMA_RESTRICTED_POOL */ > + > + return io_tlb_default_mem; Given that we're al

Re: [Intel-gfx] [PATCH v6 08/15] swiotlb: Bounce data from/to restricted DMA pool if available

> +static inline bool is_dev_swiotlb_force(struct device *dev) > +{ > +#ifdef CONFIG_DMA_RESTRICTED_POOL > + if (dev->dma_io_tlb_mem) > + return true; > +#endif /* CONFIG_DMA_RESTRICTED_POOL */ > + return false; > +} > + > /* If SWIOTLB is active, use its maximum mapping

[Intel-gfx] i915 and swiotlb_max_segment

Hi all, swiotlb_max_segment is a rather strange "API" export by swiotlb.c, and i915 is the only (remaining) user. swiotlb_max_segment returns 0 if swiotlb is not in use, 1 if SWIOTLB_FORCE is set or swiotlb-zen is set, and the swiotlb segment size when swiotlb is otherwise enabled. i915 then use

Re: [Intel-gfx] [RFC PATCH 8/9] drm/gem: Associate GEM objects with drm cgroup

The other thread about how to manage gpu compute resources reminded me of this one about gpu memory splitting. On Thu, Mar 18, 2021 at 8:20 PM Brian Welty wrote: > > > On 3/18/2021 3:16 AM, Daniel Vetter wrote: > > On Sat, Mar 6, 2021 at 1:44 AM Brian Welty wrote: > >> > >> > >> On 2/11/2021 7:3

Re: [Intel-gfx] [PATCH] drm/i915: Stop propagating fence errors by default

On Fri, May 07, 2021 at 09:35:21AM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > This is an alternative proposed fix for the below references bug report > where dma fence error propagation is causing undesirable change in > behaviour post GPU hang/reset. > > Approach in this patch is t

Re: [Intel-gfx] [RFC PATCH 8/9] drm/gem: Associate GEM objects with drm cgroup

Hi, Mon, 2021-05-10 at 17:36 +0200, Daniel Vetter wrote: > ... > > If DRM allows user-space to exhaust all of system memory, this seems > > to be a gap in enforcement of MEMCG limits for system memory. > > I tried to look into it when this was discussed in the past > > My guess is that shmem_

[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Only set bind_async_flags when concurrent access wa is not active.

== Series Details == Series: drm/i915: Only set bind_async_flags when concurrent access wa is not active. URL : https://patchwork.freedesktop.org/series/89961/ State : failure == Summary == Applying: drm/i915: Only set bind_async_flags when concurrent access wa is not active. error: sha1 inf

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Try YCbCr420 color when RGB fails (rev2)

== Series Details == Series: drm/i915/display: Try YCbCr420 color when RGB fails (rev2) URL : https://patchwork.freedesktop.org/series/89842/ State : success == Summary == CI Bug Log - changes from CI_DRM_10063 -> Patchwork_20094 Summary --

Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915

On May 10, 2021 08:55:55 Martin Peres wrote: On 10/05/2021 02:11, Jason Ekstrand wrote: On May 9, 2021 12:12:36 Martin Peres wrote: Hi, On 06/05/2021 22:13, Matthew Brost wrote: Basic GuC submission support. This is the first bullet point in the upstreaming plan covered in the following R

Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915

On Mon, May 10, 2021 at 3:55 PM Martin Peres wrote: > > On 10/05/2021 02:11, Jason Ekstrand wrote: > > On May 9, 2021 12:12:36 Martin Peres wrote: > > > >> Hi, > >> > >> On 06/05/2021 22:13, Matthew Brost wrote: > >>> Basic GuC submission support. This is the first bullet point in the > >>> upstr

Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915

Daniel Vetter writes: > On Mon, May 10, 2021 at 3:55 PM Martin Peres wrote: >> >> On 10/05/2021 02:11, Jason Ekstrand wrote: >> > On May 9, 2021 12:12:36 Martin Peres wrote: >> > >> >> Hi, >> >> >> >> On 06/05/2021 22:13, Matthew Brost wrote: >> >>> Basic GuC submission support. This is the fir

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Try YCbCr420 color when RGB fails (rev2)

== Series Details == Series: drm/i915/display: Try YCbCr420 color when RGB fails (rev2) URL : https://patchwork.freedesktop.org/series/89842/ State : success == Summary == CI Bug Log - changes from CI_DRM_10063_full -> Patchwork_20094_full

Re: [Intel-gfx] [PATCH 00/53] Get rid of UTF-8 chars that can be mapped as ASCII

On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote: > On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote: > > This patch series is doing conversion only when using ASCII makes > > more sense than using UTF-8. > > > > See, a number of converted documents ended with weird c

Re: [Intel-gfx] [PATCH 1/5] drm/i915/display: Fill PSR state during hardware configuration read out

On Sat, Apr 17, 2021 at 05:21:22PM -0700, José Roberto de Souza wrote: > So far if we had a mismatch between the state asked and what was > programmed in hardware for PSR, this mismatch would go unnoticed. > > So here adding the PSR to the hardware configuration readout, > EDP_PSR_CTL and EDP_PSR2

Re: [Intel-gfx] [PATCH 2/5] drm/i915/display: Replace intel_psr_enabled() calls by intel_crtc_state check

On Sat, Apr 17, 2021 at 05:21:23PM -0700, José Roberto de Souza wrote: > All of this places don't need to intel_psr_enabled() that will lock > psr mutex, check state and unlock. > > Instead it can directly check PSR state in intel_crtc_state, the only > place that was not possible was intel_read_d

Re: [Intel-gfx] [PATCH 3/5] drm/i915/display: Drop duplicated code in intel_dp_set_infoframes()

On Sat, Apr 17, 2021 at 05:21:24PM -0700, José Roberto de Souza wrote: > No functional changes in here. > > Cc: Matt Atwood Reviewed-by: Radhakrishna Sripada > Signed-off-by: José Roberto de Souza > --- > drivers/gpu/drm/i915/display/intel_dp.c | 17 ++--- > 1 file changed, 6 inser

Re: [Intel-gfx] [PATCH 4/5] drm/i915/display: Drop dead code from hsw_read_infoframe()

On Sat, Apr 17, 2021 at 05:21:25PM -0700, José Roberto de Souza wrote: > HSW_TVIDEO_DIP_CTL is read but not used. > Reviewed-by: Radhakrishna Sripada > Signed-off-by: José Roberto de Souza > --- > drivers/gpu/drm/i915/display/intel_hdmi.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(

Re: [Intel-gfx] [PATCH 5/5] drm/i915/display/xelpd: Implement Wa_14013475917

On Sat, Apr 17, 2021 at 05:21:26PM -0700, José Roberto de Souza wrote: > This workaround requires that VIDEO_DIP_ENABLE_VSC_HSW is never set > with PSR. > > BSpec: 54369 > BSpec: 54077 Reviewed-by: Radhakrishna Sripada > Cc: Matt Atwood > Cc: Gwan-gyeong Mun > Signed-off-by: José Roberto de Sou

Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915

On Sun, 09 May 2021 16:11:43 -0700, Jason Ekstrand wrote: > > Yes, landing GuC support may be the first step in removing execlist > support. The inevitable reality is that GPU scheduling is coming and > likely to be there only path in the not-too-distant future. (See also > the ongoing thread with

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure

On Tue, May 11, 2021 at 2:06 AM Albert Astals Cid wrote: > > Yes, I also have the same. > > I git bisected that and found this to be the cause, i started a new email > thread because i couldn't find this email ^_^ Should be fixed by https://cgit.freedesktop.org/drm-tip/commit/?id=acca7762eb71bc0

Re: [Intel-gfx] [PATCH v3] drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops

On Mon, Apr 26, 2021 at 11:24 PM Kai-Heng Feng wrote: > > On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX > to discrete GFX after S3. This is not desirable, because userspace will > treat connected display as a new one, losing display settings. > > The expected behavior is

[Intel-gfx] [PATCH] drm/i915/selftests: Memory mapping with IOMMU

From: hardikdx When IOMMU is enabled, comparing CPU value with page failes as *CPU does not match with page value. These values are comparible only when IOMMU is disabled. Hence, remove comparision to run live selftest without an issue. Signed-off-by: hardikdx Cc: Matthew Auld --- .../drm/i91

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Memory mapping with IOMMU

== Series Details == Series: drm/i915/selftests: Memory mapping with IOMMU URL : https://patchwork.freedesktop.org/series/89987/ State : success == Summary == CI Bug Log - changes from CI_DRM_10064 -> Patchwork_20096 Summary --- **SU

Re: [Intel-gfx] [PATCH 7/8] usb: typec: altmodes/displayport: Make dp_altmode_notify() more generic

On Wed, May 05, 2021 at 06:24:14PM +0200, Hans de Goede wrote: > Make dp_altmode_notify() handle the dp->data.conf == 0 case too, > rather then having separate code-paths for this in various places > which call it. > > Signed-off-by: Hans de Goede Reviewed-by: Heikki Krogerus > --- > drivers/

Re: [Intel-gfx] [PATCH 8/8] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events

On Wed, May 05, 2021 at 06:24:15PM +0200, Hans de Goede wrote: > Use the new drm_connector_oob_hotplug_event() functions to let drm/kms > drivers know about DisplayPort over Type-C hotplug events. > > Signed-off-by: Hans de Goede Reviewed-by: Heikki Krogerus > --- > Changes in v3: > - Only cal