On Mon, Mar 06, 2023 at 12:49:52PM -0800, Lucas De Marchi wrote:
> dg1_gt_workarounds_init() is only ever called for DG1, so there is no
> point checking it again.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 12 +++-
> 1 file changed, 3 insert
On Tue, Sep 06, 2022 at 09:48:06AM +0530, Arun R Murthy wrote:
> Starting from Gen12 Async Flip is supported on linear buffers.
> This patch enables support for async on linear buffer.
>
> UseCase: In Hybrid graphics, for hardware unsupported pixel formats it
> will be converted to linear memory a
From: Ville Syrjälä
Remove the unused i915 variable to fix the build with WERROR=y.
Cc: Lucas De Marchi
Fixes: d1b3657fb5b6 ("drm/i915: Remove redundant check for DG1")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 --
1 file changed, 2 deletions(-)
diff --
On Friday, 10 March 2023 17:48:10 CET Das, Nirmoy wrote:
> Hi Janusz,
>
> On 3/10/2023 4:19 PM, Janusz Krzysztofik wrote:
> > Hi Nirmoy,
> >
> > On Friday, 10 March 2023 15:11:38 CET Nirmoy Das wrote:
> >> debug_active_activate() expected ref->count to be zero
> >> which is not true anymore as __i
On Mon, 13 Mar 2023 at 09:39, Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Remove the unused i915 variable to fix the build with WERROR=y.
>
> Cc: Lucas De Marchi
> Fixes: d1b3657fb5b6 ("drm/i915: Remove redundant check for DG1")
> Signed-off-by: Ville Syrjälä
Reviewed-by: Matthew Auld
On Fri, Mar 10, 2023 at 04:22:31PM -0800, Sean Christopherson wrote:
> Fix a variety of found-by-inspection bugs in KVMGT, and overhaul KVM's
> page-track APIs to provide a leaner and cleaner interface. The motivation
> for this series is to (significantly) reduce the number of KVM APIs that
> KVM
debug_active_activate() expected ref->count to be zero
which is not true anymore as __i915_active_activate() calls
debug_active_activate() after incrementing the count.
v2: No need to check for "ref->count == 1" as __i915_active_activate()
already make sure of that.
Fixes: 04240e30ed06 ("drm/i915
On 3/13/2023 10:55 AM, Janusz Krzysztofik wrote:
On Friday, 10 March 2023 17:48:10 CET Das, Nirmoy wrote:
Hi Janusz,
On 3/10/2023 4:19 PM, Janusz Krzysztofik wrote:
Hi Nirmoy,
On Friday, 10 March 2023 15:11:38 CET Nirmoy Das wrote:
debug_active_activate() expected ref->count to be zero
whi
On Monday, 13 March 2023 11:30:45 CET Nirmoy Das wrote:
> debug_active_activate() expected ref->count to be zero
> which is not true anymore as __i915_active_activate() calls
> debug_active_activate() after incrementing the count.
>
> v2: No need to check for "ref->count == 1" as __i915_active_act
On Mon, Mar 13, 2023 at 11:39:13AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove the unused i915 variable to fix the build with WERROR=y.
Argh. Turns out this is actually caused by
commit 69ea87e1591a ("drm/i915/dg1: Drop support for pre-production steppings")
being merged through
On Mon, Mar 13, 2023 at 12:44:52PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 13, 2023 at 11:39:13AM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Remove the unused i915 variable to fix the build with WERROR=y.
>
> Argh. Turns out this is actually caused by
> commit 69ea87e1591a ("d
== Series Details ==
Series: drm/i915: Fix build with WERROR=y
URL : https://patchwork.freedesktop.org/series/115046/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
INSTALL libsubcmd_headers
CC [M] drivers/gpu/drm/i915/gt/intel_workar
On Mon, Mar 13, 2023 at 11:02:17AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Fix build with WERROR=y
> URL : https://patchwork.freedesktop.org/series/115046/
> State : failure
>
> == Summary ==
>
> Error: make failed
> CALLscripts/checksyscalls.sh
> DESCEND o
@SCG SCSS CI - please take a look
-Original Message-
From: Ville Syrjälä
Sent: poniedziałek, 13 marca 2023 12:09
To: intel-gfx@lists.freedesktop.org
Cc: Musial, Ewelina
Subject: Re: ✗ Fi.CI.BUILD: failure for drm/i915: Fix build with WERROR=y
On Mon, Mar 13, 2023 at 11:02:17AM -, P
debug_active_activate() expected ref->count to be zero
which is not true anymore as __i915_active_activate() calls
debug_active_activate() after incrementing the count.
v2: No need to check for "ref->count == 1" as __i915_active_activate()
already make sure of that.
References: https://gitlab.fre
== Series Details ==
Series: drm/i915/active: Fix missing debug object activation
URL : https://patchwork.freedesktop.org/series/114981/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12839_full -> Patchwork_114981v1_full
Su
On 3/10/2023 10:23 AM, Andrzej Hajda wrote:
The callback will be responsible for setting scratch page PTEs for
specified range. In contrast to clear_range it cannot be optimized to nop.
It will be used by code adding guard pages.
Signed-off-by: Andrzej Hajda
Reviewed-by: Nirmoy Das
---
d
On 3/10/2023 10:23 AM, Andrzej Hajda wrote:
Write-combining memory allows speculative reads by CPU.
ggtt->error_capture is WC mapped to CPU, so CPU/MMU can try
to prefetch memory beyond the error_capture, ie it tries
to read memory pointed by next PTE in GGTT.
If this PTE points to invalid addr
== Series Details ==
Series: drm/i915/active: Fix missing debug object activation (rev3)
URL : https://patchwork.freedesktop.org/series/114981/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12851 -> Patchwork_114981v3
Summa
On Mon, Mar 13, 2023 at 11:10:26AM +0200, Ville Syrjälä wrote:
On Mon, Mar 06, 2023 at 12:49:52PM -0800, Lucas De Marchi wrote:
dg1_gt_workarounds_init() is only ever called for DG1, so there is no
point checking it again.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_worka
On Mon, Mar 13, 2023 at 06:23:59AM -0700, Lucas De Marchi wrote:
> On Mon, Mar 13, 2023 at 11:10:26AM +0200, Ville Syrjälä wrote:
> >On Mon, Mar 06, 2023 at 12:49:52PM -0800, Lucas De Marchi wrote:
> >> dg1_gt_workarounds_init() is only ever called for DG1, so there is no
> >> point checking it aga
> -Original Message-
> From: Intel-gfx On Behalf Of
> Rodrigo Vivi
> Sent: Friday, March 10, 2023 4:43 PM
> To: Nilawar, Badal
> Cc: Germano, Gregory F ; intel-
> g...@lists.freedesktop.org; Nandamuri, Srikanth
> ; Chilmakuru, Hima B
>
> Subject: Re: [Intel-gfx] [PATCH v2 1/1] drm/i91
This is a reminder that the deadline for new memberships and renewals
finishes in a couple of weeks. Original email follows.
Thanks for your attention.
On Wed, 2023-02-15 at 16:58 +0100, Ricardo Garcia wrote:
> The 2023 X.Org Foundation elections are rapidly approaching. We will be
> forwarding t
This is a reminder that the nomination period for the X.Org Board of
Director elections finishes in a week, on March 19th.
If you would like to nominate yourself please send email to the election
committee electi...@x.org, giving your
name
current professional affiliation
a statement
On Saturday, March 11, 2023 8:23 AM, Sean Christopherson wrote:
> Extract the memslot-related logic of kvm_mmu_max_mapping_level() into a
> new helper so that KVMGT can determine whether or not mapping a 2MiB
> page into the guest is (dis)allowed per KVM's memslots.
>
> No functional change intend
On Saturday, March 11, 2023 8:23 AM, Sean Christopherson wrote:
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> index 4ec85308379a..58b9b316ae46 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.c
> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> @@ -1183,6 +1183,10 @@ static int
-Original Message-
From: Auld, Matthew
Sent: Thursday, March 2, 2023 2:36 AM
To: Cavitt, Jonathan ;
intel-gfx@lists.freedesktop.org
Cc: Dutt, Sudeep ; thomas.hellst...@linux.intel.com;
maarten.lankho...@linux.intel.com; Vetter, Daniel ; De
Marchi, Lucas ; chris.p.wil...@linux.intel.com
From: Ville Syrjälä
Add a new immutable plane property by which a plane can advertise
a handful of recommended plane sizes. This would be mostly exposed
by cursor planes as a slightly more capable replacement for
the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare
a one size fits all lim
While perfroming root cause analyses of fence callback list corruptions,
a couple of other potential though less likely root causes have been
identified in addition to barrier tasks list deletion results ignored.
This series tries to fix those potential issues, also in longterm stable
releases star
When we collect barriers for preallocating them, we reuse either idle or
non-idle ones, whichever we find. In case of non-idle barriers, we
depend on their successful deletion from their barrier tasks lists as an
indication of them not being claimed by another thread. However, in case
of idle bar
When adding a request to a composite tracker, we try to use an existing
fence tracker already registered with that composite. The tracker we
obtain can already track another fence, can be an idle barrier, or an
active barrier.
When we acquire an idle barrier, we don't claim it in any way until
__
Inside active_del_barrier(), while searching for a node to be deleted,
we now rebuild barrier_tasks llist content in reverse order.
Theoretically neutral, that method was observed to provide an undocumented
workaround for unexpected loops of llist nodes appearing now and again due
to races, sil
On 13/03/2023 15:57, Cavitt, Jonathan wrote:
-Original Message-
From: Auld, Matthew
Sent: Thursday, March 2, 2023 2:36 AM
To: Cavitt, Jonathan ;
intel-gfx@lists.freedesktop.org
Cc: Dutt, Sudeep ; thomas.hellst...@linux.intel.com;
maarten.lankho...@linux.intel.com; Vetter, Daniel ; De M
== Series Details ==
Series: drm: Add plane SIZE_HINTS property (rev3)
URL : https://patchwork.freedesktop.org/series/113758/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12853 -> Patchwork_113758v3
Summary
---
**SU
On 13.03.2023 11:30, Nirmoy Das wrote:
debug_active_activate() expected ref->count to be zero
which is not true anymore as __i915_active_activate() calls
debug_active_activate() after incrementing the count.
v2: No need to check for "ref->count == 1" as __i915_active_activate()
already make sure
The struct bus_type pointers in the functions
intel_huc_register_gsc_notifier() and
intel_huc_unregister_gsc_notifier() should be a const pointer, as the
structure is not modified anywhere in the functions, and the pointer
they are passed will be a const * in the near future.
Cc: Jani Nikula
Cc:
Hi Nirmoy,
[...]
> +int i915_gem_fb_mmap(struct drm_i915_gem_object *obj, struct vm_area_struct
> *vma)
> +{
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + struct drm_device *dev = &i915->drm;
> + struct i915_mmap_offset *mmo = NULL;
> + enum i915_mmap_type mmap_
Hi Nirmoy,
On Tue, Mar 07, 2023 at 03:46:52PM +0100, Nirmoy Das wrote:
> If stolen memory allocation fails for fbdev, the driver will
> fallback to system memory. Calculation of smem_start is wrong
> for such framebuffer objs if the platform comes with no gmadr or
> no aperture. Solve this by addi
On Wed, Mar 8, 2023 at 3:15 PM Lukas Bulwahn wrote:
>
> The 01.org links in MAINTAINERS now forward to different other pages or do
> not resolve.
>
> The link https://01.org/linuxgraphics/ resolves to the Intel Graphics for
> Linux - Programmer's Reference Manuals. Update this webpage entry.
>
> T
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Don't switch to TPS1 when
disabling DP_TP_CTL (rev2)
URL : https://patchwork.freedesktop.org/series/114873/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12841_full -> Patchwork_114873v2_full
===
On Wed, 08 Mar 2023, Lukas Bulwahn wrote:
> The 01.org links in MAINTAINERS now forward to different other pages or do
> not resolve.
>
> The link https://01.org/linuxgraphics/ resolves to the Intel Graphics for
> Linux - Programmer's Reference Manuals. Update this webpage entry.
>
> The link
> ht
In the rare case where we do a full GT reset after starting the HuC
load and before it completes (which basically boils down to i915 hanging
during init), we need to cancel the delayed load fence, as it will be
re-initialized in the post-reset recovery.
Fixes: 27536e03271d ("drm/i915/huc: track de
== Series Details ==
Series: drm/i915/huc: Cancel HuC delayed load timer on reset.
URL : https://patchwork.freedesktop.org/series/115080/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915/huc: Cancel HuC delayed load timer on reset.
URL : https://patchwork.freedesktop.org/series/115080/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12853 -> Patchwork_115080v1
Summary
---
On dGfx, the PL1 power limit being enabled and set to a low value results
in a low GPU operating freq. It also negates the freq raise operation which
is done before GuC firmware load. As a result GuC firmware load can time
out. Such timeouts were seen in the GL #8062 bug below (where the PL1 power
On Fri, 10 Mar 2023 17:01:42 -0800, John Harrison wrote:
>
> >> + for (count = 0; count < 20; count++) {
> >> + ret = wait_for(guc_load_done(uncore, &status, &success), 1000);
> >
> > Isn't 20 secs a bit too long for an in-place wait? I get that if the GuC
> > doesn't load (or fail to) wi
== Series Details ==
Series: More error capture improvements (rev3)
URL : https://patchwork.freedesktop.org/series/113628/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12842_full -> Patchwork_113628v3_full
Summary
---
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/tiny/cirrus.c
between commit:
7245e629dcaa ("drm/cirrus: NULL-check pipe->plane.state->fb in
cirrus_pipe_update()")
from Linus' tree and commits:
d99c028941b3 ("drm/cirrus: Convert to regular atomi
From: John Harrison
Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.
Signed-off-by: John Harrison
Fixes: 9d80841ea4c9 ("drm/i915: A
== Series Details ==
Series: drm/i915: Don't use BAR mappings for ring buffers with LLC
URL : https://patchwork.freedesktop.org/series/115090/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/115090/revisions/1/mbox/ not
applied
Applying: drm/i915:
From: John Harrison
Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.
Signed-off-by: John Harrison
Fixes: 9d80841ea4c9 ("drm/i915: A
From: John Harrison
Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.
Signed-off-by: John Harrison
Fixes: 9d80841ea4c9 ("drm/i915: A
This series:
1. Adds common drm-shmem memory shrinker
2. Enables shrinker for VirtIO-GPU driver
3. Switches Panfrost driver to the common shrinker
Changelog:
v13:- Updated virtio-gpu shrinker patch to use drm_gem_shmem_object_pin()
directly instead of drm_gem_pin() and dropped patch
Factor out pages allocation from drm_gem_shmem_get_pages() into
drm_gem_shmem_acquire_pages() function and similar for the put_pages()
in a preparation for addition of shrinker support to drm-shmem.
Once shrinker will be added, the pages_use_count>0 will no longer determine
whether pages are pinne
Replace all drm-shmem locks with a GEM reservation lock. This makes locks
consistent with dma-buf locking convention where importers are responsible
for holding reservation lock for all operations performed over dma-bufs,
preventing deadlock between dma-buf importers and exporters.
Suggested-by: D
And new pages_pin_count field to struct drm_gem_shmem_object that will
determine whether pages are evictable by memory shrinker. The pages will
be evictable only when pages_pin_count=0. This patch prepares code for
addition of the memory shrinker that will utilize the new field.
Signed-off-by: Dmi
Factor out pages unpinning code from drm_gem_shmem_purge() into new
drm_gem_shmem_unpin_pages(). This prepares code for addition of memory
shrinker support. The new common function will be used by shrinker for
eviction of shmem pages.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_sh
The vmapped pages shall be pinned in memory. Previously get/put pages were
implicitly pinning/unpinning the pages. This will no longer be the case
with addition of memory shrinker because pages_use_count>0 won't determine
whether pages are pinned anymore, while the new pages_pin_count will do
that.
Everything that uses the mapped buffer should by agnostic to is_iomem.
The only reason for the is_iomem test is is that we're setting shmem->vaddr
to the returned map->vaddr. Now that the shmem->vaddr code is gone, remove
the obsoleted is_iomem test to clean up the code.
Suggested-by: Thomas Zimme
Introduce common drm-shmem shrinker for DRM drivers.
To start using drm-shmem shrinker drivers should do the following:
1. Implement evict() callback of GEM object where driver should check
whether object is purgeable or evictable using drm-shmem helpers and
perform the shrinking action
2.
Export drm_gem_shmem_get_pages_sgt_locked() that will be used by virtio-gpu
shrinker during GEM swap-in operation done under the held reservation lock.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 3 ++-
include/drm/drm_gem_shmem_helper.h | 1 +
2 files changed
Support generic drm-shmem memory shrinker and add new madvise IOCTL to
the VirtIO-GPU driver. BO cache manager of Mesa driver will mark BOs as
"don't need" using the new IOCTL to let shrinker purge the marked BOs on
OOM, the shrinker will also evict unpurgeable shmem BOs from memory if
guest suppor
Replace Panfrost's custom memory shrinker with a common drm-shmem
memory shrinker.
Tested-by: Steven Price # Firefly-RK3288
Reviewed-by: Steven Price
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/panfrost/Makefile | 1 -
drivers/gpu/drm/panfrost/panfrost_device.h| 4 -
== Series Details ==
Series: drm/i915: Don't use BAR mappings for ring buffers with LLC (rev2)
URL : https://patchwork.freedesktop.org/series/115090/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/115090/revisions/2/mbox/ not
applied
Applying: drm
== Series Details ==
Series: drm/i915: Don't use BAR mappings for ring buffers with LLC (rev3)
URL : https://patchwork.freedesktop.org/series/115090/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/115090/revisions/3/mbox/ not
applied
Applying: drm
== Series Details ==
Series: Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers
(rev2)
URL : https://patchwork.freedesktop.org/series/114671/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
C firmware
config: x86_64-randconfig-a016-20230313
(https://download.01.org/0day-ci/archive/20230314/202303141032.gnwwcyad-...@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project
f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
w
== Series Details ==
Series: Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers
(rev2)
URL : https://patchwork.freedesktop.org/series/114671/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12853 -> Patchwork_114671v2
Hi all,
After merging the drm-misc tree, today's linux-next build (htmldocs)
produced these warnings:
drivers/gpu/drm/scheduler/sched_main.c:738: warning: Excess function parameter
'file_private' description in 'drm_sched_job_add_syncobj_dependency'
drivers/gpu/drm/scheduler/sched_main.c:738: wa
On Fri, Mar 10, 2023 at 04:22:35PM -0800, Sean Christopherson wrote:
> Honor KVM's max allowed page size when determining whether or not a 2MiB
> GTT shadow page can be created for the guest. Querying KVM's max allowed
> size is somewhat odd as there's no strict requirement that KVM's memslots
> a
> -Original Message-
> From: Lisovskiy, Stanislav
> Sent: Monday, March 13, 2023 3:01 PM
> To: Murthy, Arun R
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCHv3] drm/i915: Support Async Flip on Linear
> buffers
>
> On Tue, Sep 06, 2022 at 09:48:06AM +0530, Arun R M
>
> From: Sean Paul
>
> Now that all of the HDCP 1.x logic has been migrated to the central HDCP
> helpers, use it in the i915 driver.
>
> The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
> however there are a few helper hooks which are connector-specific and
> need to be
72 matches
Mail list logo
