== Series Details ==
Series: drm/i915/guc: Do not complain about stale reset notifications (rev2)
URL : https://patchwork.freedesktop.org/series/2/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11223_full -> Patchwork_22258_full
== Series Details ==
Series: drm/i915/guc: Do not complain about stale reset notifications (rev2)
URL : https://patchwork.freedesktop.org/series/2/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11223 -> Patchwork_22258
On Tue, Feb 1, 2022 at 2:42 AM Ramalingam C wrote:
>
> From: Mika Kahola
>
> DG2 clear color render compression uses Tile4 layout. Therefore, we need
> to define a new format modifier for uAPI to support clear color rendering.
>
> v2:
> Display version is fixed. [Imre]
> KDoc is enhanced for
On Tue, Feb 1, 2022 at 2:42 AM Ramalingam C wrote:
>
> From: Matt Roper
>
> DG2 unifies render compression and media compression into a single
> format for the first time. The programming and buffer layout is
> supposed to match compression on older gen12 platforms, but the actual
> compression
From: John Harrison
It is possible for reset notifications to arrive for a context that is
in the process of being banned. So don't flag these as an error, just
report it as informational (because it is still useful to know that
resets are happening even if they are being ignored).
v2: Better wo
On Thu, 2022-02-10 at 18:11 -0800, Umesh Nerlige Ramappa wrote:
> On Wed, Jan 26, 2022 at 02:48:20AM -0800, Alan Previn wrote:
> > Add a flags parameter through all of the coredump creation
> > functions. Add a bitmask flag to indicate if the top
> > level gpu_coredump event is triggered in respon
Thanks Umesh for reviewing this for me and for the R-v-b.
Responding on one comment below
On Thu, 2022-02-10 at 18:11 -0800, Umesh Nerlige Ramappa wrote:
> On Wed, Jan 26, 2022 at 02:48:20AM -0800, Alan Previn wrote:
> > Add a flags parameter through all of the coredump creation
> > functions. Ad
== Series Details ==
Series: drm/i915: Plane/wm cleanups (rev2)
URL : https://patchwork.freedesktop.org/series/100020/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11220_full -> Patchwork_22257_full
Summary
---
**SU
On Thu, Dec 16, 2021 at 09:52:26AM +, Tvrtko Ursulin wrote:
>
>
> On 09/12/2021 12:01, Tejas Upadhyay wrote:
> > Most code paths does full reset with preparing all
> > engines for reset except below two :
> >
> > 1. Single engine reset needs to prepare engines for
> > reset based on its rese
== Series Details ==
Series: drm/i915: Futher optimize plane updates (rev5)
URL : https://patchwork.freedesktop.org/series/99149/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11220_full -> Patchwork_22255_full
Summary
On this specific question.
On Fri, 2022-02-04 at 17:28 -0800, Umesh Nerlige Ramappa wrote:
> On Wed, Jan 26, 2022 at 02:48:15AM -0800, Alan Previn wrote:
> > Add additional DG2 registers for GuC error state capture.
> >
> > + num_steer_regs = ARRAY_SIZE(xelpd_extregs);
> > + if (ipver >= IP_V
== Series Details ==
Series: drm/i915: Plane/wm cleanups (rev2)
URL : https://patchwork.freedesktop.org/series/100020/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11220 -> Patchwork_22257
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915: Plane/wm cleanups (rev2)
URL : https://patchwork.freedesktop.org/series/100020/
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: Plane/wm cleanups (rev2)
URL : https://patchwork.freedesktop.org/series/100020/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cfff3831dee5 drm/i915: Move intel_plane_atomic_calc_changes() & co. out
3260cfa17939 drm/i915: Introduce intel_ar
== Series Details ==
Series: drm/i915: Futher optimize plane updates (rev5)
URL : https://patchwork.freedesktop.org/series/99149/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11220 -> Patchwork_22255
Summary
---
**S
== Series Details ==
Series: Initial support for small BAR recovery (rev4)
URL : https://patchwork.freedesktop.org/series/99370/
State : failure
== Summary ==
Applying: drm/i915: add io_size plumbing
Applying: drm/i915/ttm: require mappable by default
Applying: drm/i915: add I915_BO_ALLOC_GPU_
From: Ville Syrjälä
We treat SSKPD as a 64 bit register. Add the support macros
to define/extract bits in such registers.
v2: Fix 32bit builds
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg_defs.h | 27 +++
1 file changed, 27 insertions(+)
diff --git a
Hi Ville,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip next-20220211]
[cannot apply to v5.17-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
Hi Ville,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip next-20220211]
[cannot apply to v5.17-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
Hi Ville,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip next-20220211]
[cannot apply to v5.17-rc3]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch
== Series Details ==
Series: drm/i915: Plane/wm cleanups
URL : https://patchwork.freedesktop.org/series/100020/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
CC [M] drivers/gpu/drm/i915/intel_pm
== Series Details ==
Series: drm/i915: Plane/wm cleanups
URL : https://patchwork.freedesktop.org/series/100020/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11219 -> Patchwork_22254
Summary
---
**SUCCESS**
No reg
== Series Details ==
Series: drm/i915: Plane/wm cleanups
URL : https://patchwork.freedesktop.org/series/100020/
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: Plane/wm cleanups
URL : https://patchwork.freedesktop.org/series/100020/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b7734111702f drm/i915: Move intel_plane_atomic_calc_changes() & co. out
7bcf657c95c4 drm/i915: Introduce intel_arm_plane
On 11/02/2022 13:33, Jani Nikula wrote:
On Thu, 10 Feb 2022, Michael Cheng wrote:
Move wbvind_on_all_cpus to intel_gt.h. This will allow other wbind_on_all_cpus
calls to benefit from the #define logic, and prevent compiler errors
when building for non-x86 architectures.
Signed-off-by: Michae
Thanks for the feedback! Another idea I had that kind of align to what you are
suggesting is adding a wrapper for wbinvd_on_all_cpus within drm_cache.h, then
having it be included in the three files that calls this function. Thoughts on
that?
From: Jani Nikula
On Thu, 2022-02-10 at 18:30 -0800, Qing Wang wrote:
> From: Wang Qing
>
> It is better to use time_xxx() directly instead of jiffies judgment
> for understanding.
>
> Signed-off-by: Wang Qing
Acked-by: Srinivas Pandruvada
> ---
> drivers/hid/intel-ish-hid/ipc/ipc.c | 2 +-
> 1 file changed,
On Fri, Feb 11, 2022 at 04:26:27PM +0200, Hogander, Jouni wrote:
> On Tue, 2022-02-08 at 13:36 +0200, Imre Deak wrote:
> > Add functions to get a power well's actual- and cached-enabled state,
> > name, domain mask and refcount, as a step towards making the low-
> > level
> > power well internals (
On Tue, 2022-02-08 at 13:36 +0200, Imre Deak wrote:
> Add functions to get a power well's actual- and cached-enabled state,
> name, domain mask and refcount, as a step towards making the low-
> level
> power well internals (i915_power_well_ops/desc structs) hidden.
It's not really in scope of this
On 11/02/2022 11:55, Jani Nikula wrote:
On Thu, 10 Feb 2022, Casey Bowman wrote:
In this RFC I would like to ask the community their thoughts
on how we can best handle splitting architecture-specific
calls.
I would like to address the following:
1. How do we want to split architecture calls
On 2022-02-07 at 11:52:48 +, Matthew Auld wrote:
> On 07/02/2022 11:48, Matthew Auld wrote:
> > On Fri, 28 Jan 2022 at 18:52, Ramalingam C wrote:
> > >
> > > An indirect ctx wabb is implemented as per Wa_22011450934 to avoid rcs
> > > restore hang during context restore of a preempted context
On Thu, 10 Feb 2022, Michael Cheng wrote:
> Move wbvind_on_all_cpus to intel_gt.h. This will allow other wbind_on_all_cpus
> calls to benefit from the #define logic, and prevent compiler errors
> when building for non-x86 architectures.
>
> Signed-off-by: Michael Cheng
> ---
> drivers/gpu/drm/i9
On 2022-02-07 at 08:55:20 -0800, Daniele Ceraolo Spurio wrote:
>
>
> On 1/28/2022 10:52 AM, Ramalingam C wrote:
> > From: Stuart Summers
> >
> > The driver is set currently to fail modprobe when GuC is disabled
> > (enable_guc=0) after GuC has been loaded on a previous modprobe.
> > For GuC dep
On 2/11/22 12:34, Matthew Auld wrote:
On platforms where there might be non-mappable LMEM, force userspace to
mark the buffers with the correct hint. When dumping the BO contents
during capture we need CPU access. Note this only applies to buffers
that can be placed in LMEM, and also doesn't im
On 2/11/22 12:34, Matthew Auld wrote:
Starting from DG2+, when dealing with LMEM, we assume that by default
all userspace allocations should be placed in the non-mappable portion
of LMEM. Note that dumb buffers are not included here, since these are
not "GPU accelerated" and likely need CPU ac
On Thu, 10 Feb 2022, Casey Bowman wrote:
> In this RFC I would like to ask the community their thoughts
> on how we can best handle splitting architecture-specific
> calls.
>
> I would like to address the following:
>
> 1. How do we want to split architecture calls? Different object files
> per pl
On platforms where there might be non-mappable LMEM, force userspace to
mark the buffers with the correct hint. When dumping the BO contents
during capture we need CPU access. Note this only applies to buffers
that can be placed in LMEM, and also doesn't impact DG1.
v2(Reported-by: kernel test rob
Starting from DG2+, when dealing with LMEM, we assume that by default
all userspace allocations should be placed in the non-mappable portion
of LMEM. Note that dumb buffers are not included here, since these are
not "GPU accelerated" and likely need CPU access. We choose to just
always set GPU_ONL
If set, force the allocation to be placed in the mappable portion of
LMEM. One big restriction here is that system memory must be given as a
potential placement for the object, that way we can always spill the
object into system memory if we can't make space.
XXX: Still needs IGTs. Including now j
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some of it is non-mappable.
It does leave open with what to do with stolen local-memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/
If we have to contend with non-mappable LMEM, then we need to ensure the
object fits within the mappable portion, like in the selftests, where we
later try to CPU access the pages. However if it can't then we need to
gracefully handle this, without throwing an error.
Also it looks like TTM will re
Exercise each of the migration scenarios, verifying that the final
placement and buffer contents match our expectations.
v2(Thomas): Replace for_i915_gem_ww() block with simpler object_lock()
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
.../drm/i915/gem/s
Track the total amount of available visible memory, and also track
per-resource the amount of used visible memory. For now this is useful
for our debug output, and deciding if it is even worth calling into the
buddy allocator. In the future tracking the per-resource visible usage
will be useful for
The end goal is to have userspace tell the kernel what buffers will
require CPU access, however if we ever reach the CPU fault handler, and
the current resource is not mappable, then we should attempt to migrate
the buffer to the mappable portion of LMEM, or even system memory, if the
allowable pla
Check that mappable vs non-mappable matches our expectations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hellström
---
.../drm/i915/selftests/intel_memory_region.c | 143 ++
1 file changed, 143 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftest
If we need to make room for some mappable object, then we should
only victimize objects that have one or pages that occupy the visible
portion of LMEM. Let's also create a new priority hint for objects that
are placed in mappable memory, where we know that CPU access was
requested, that way we hope
Otherwise we get -EINVAL, instead of the more useful -E2BIG if the
allocation doesn't fit within the pfn range, like with mappable lmem.
The hugepages selftest, for example, needs this to know if a smaller
size is needed.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-by: Thomas Hells
Differentiate between mappable vs non-mappable resources, also if this
is an actual range allocation ensure we set res->start as the starting
pfn. Later when we need to do non-mappable -> mappable moves then we
want TTM to see that the current placement is not compatible, which
should result in an
On devices with non-mappable LMEM ensure we always allocate the pages
within the mappable portion. For now we assume that all LMEM buffers
will require CPU access, which is also inline with pretty much all
current kernel internal users. In the next patch we will introduce a new
flag to override thi
If the user doesn't require CPU access for the buffer, then
ALLOC_GPU_ONLY should be used, in order to prioritise allocating in the
non-mappable portion of LMEM, on devices with small BAR.
v2(Thomas):
- The BO_ALLOC_TOPDOWN naming here is poor, since this is pure lies on
systems that don't e
With small LMEM-BAR we need to be able to differentiate between the
total size of LMEM, and how much of it is CPU mappable. The end goal is
to be able to utilize the entire range, even if part of is it not CPU
accessible.
v2: also update intelfb_create
Signed-off-by: Matthew Auld
Cc: Thomas Hell
Starting from DG2 we will have resizable BAR support for device local-memory,
but in some cases the final BAR size might still be smaller than the total
local-memory size. In such cases only part of local-memory will be CPU
accessible, while the remainder is only accessible via the GPU. This series
On Thu, Feb 10, 2022 at 09:55:27PM -0800, Namhyung Kim wrote:
> So you are ok with adding two new tracepoints, even if they are
> similar to what we already have in lockdep/lock_stat, right?
Yeah, I don't think adding tracepoints to the slowpaths of the various
locks should be a problem.
On 2/11/22 11:00, Matthew Auld wrote:
On Fri, 11 Feb 2022 at 09:56, Thomas Hellström
wrote:
On 2/11/22 10:52, Matthew Auld wrote:
On Fri, 11 Feb 2022 at 09:49, Thomas Hellström
wrote:
On 2/10/22 13:13, Matthew Auld wrote:
Starting from DG2+, when dealing with LMEM, we assume that by defa
On Wed, 09 Feb 2022, Ville Syrjälä wrote:
> On Wed, Feb 09, 2022 at 11:09:41AM +0200, Jani Nikula wrote:
>> On Tue, 08 Feb 2022, Ville Syrjälä wrote:
>> > On Thu, Feb 03, 2022 at 11:03:55AM +0200, Jani Nikula wrote:
>> >> Abstract link status check to a function that takes 128b/132b and 8b/10b
>>
On 2/10/22 13:13, Matthew Auld wrote:
Just pass along the probed io_size. The backend should be able to
utilize the entire range here, even if some of it is non-mappable.
It does leave open with what to do with stolen local-memory.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed
On 2/10/22 13:13, Matthew Auld wrote:
On platforms where there might be non-mappable LMEM, force userspace to
mark the buffers with the correct hint. When dumping the BO contents
during capture we need CPU access. Note this only applies to buffers
that can be placed in LMEM, and also doesn't im
On Fri, 11 Feb 2022 at 09:56, Thomas Hellström
wrote:
>
>
> On 2/11/22 10:52, Matthew Auld wrote:
> > On Fri, 11 Feb 2022 at 09:49, Thomas Hellström
> > wrote:
> >>
> >> On 2/10/22 13:13, Matthew Auld wrote:
> >>> Starting from DG2+, when dealing with LMEM, we assume that by default
> >>> all use
On 2/10/22 13:13, Matthew Auld wrote:
If set, force the allocation to be placed in the mappable portion of
LMEM. One big restriction here is that system memory must be given as a
potential placement for the object, that way we can always spill the
object into system memory if we can't make spac
On 2/11/22 10:52, Matthew Auld wrote:
On Fri, 11 Feb 2022 at 09:49, Thomas Hellström
wrote:
On 2/10/22 13:13, Matthew Auld wrote:
Starting from DG2+, when dealing with LMEM, we assume that by default
all userspace allocations should be placed in the non-mappable portion
of LMEM. Note that
On Fri, 11 Feb 2022 at 09:49, Thomas Hellström
wrote:
>
>
> On 2/10/22 13:13, Matthew Auld wrote:
> > Starting from DG2+, when dealing with LMEM, we assume that by default
> > all userspace allocations should be placed in the non-mappable portion
> > of LMEM. Note that dumb buffers are not includ
On 2/10/22 13:13, Matthew Auld wrote:
Starting from DG2+, when dealing with LMEM, we assume that by default
all userspace allocations should be placed in the non-mappable portion
of LMEM. Note that dumb buffers are not included here, since these are
not "GPU accelerated" and likely need CPU ac
On 2/10/22 13:13, Matthew Auld wrote:
If we have to contend with non-mappable LMEM, then we need to ensure the
object fits within the mappable portion, like in the selftests, where we
later try to CPU access the pages. However if it can't then we need to
gracefully handle this, without throwing
On 2/10/22 13:13, Matthew Auld wrote:
Exercise each of the migration scenarios, verifying that the final
placement and buffer contents match our expectations.
v2(Thomas): Replace for_i915_gem_ww() block with simpler object_lock()
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Reviewed-b
From: Ville Syrjälä
Drop the locks around cursor plane register writes. The
lock isn't needed since each plane's register are neatly
contained on their own cachelines.
The locking did have a secondary effect of disabling
interrupts around the cursor registers writes though.
If we drop that then
On 2/10/22 13:13, Matthew Auld wrote:
Track the total amount of available visible memory, and also track
per-resource the amount of used visible memory. For now this is useful
for our debug output, and deciding if it is even worth calling into the
buddy allocator. In the future tracking the per
On 2/10/22 13:13, Matthew Auld wrote:
If the user doesn't require CPU access for the buffer, then
ALLOC_GPU_ONLY should be used, in order to prioritise allocating in the
non-mappable portion of LMEM, on devices with small BAR.
v2(Thomas):
- The BO_ALLOC_TOPDOWN naming here is poor, since th
On 2/10/22 13:13, Matthew Auld wrote:
On devices with non-mappable LMEM ensure we always allocate the pages
within the mappable portion. For now we assume that all LMEM buffers
will require CPU access, which is also inline with pretty much all
current kernel internal users. In the next patch we
From: Ville Syrjälä
We treat SSKPD as a 64 bit register. Add the support macros
to define/extract bits in such registers.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg_defs.h | 57 +---
1 file changed, 43 insertions(+), 14 deletions(-)
diff --git a/dri
From: Ville Syrjälä
Use REG_GENMASK() & co. for ilk+ watermarm registers.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_reg.h | 41 +++--
drivers/gpu/drm/i915/intel_pm.c | 57 +--
From: Ville Syrjälä
Give names to the SSKPD/MLTR fields, and use the
REG_GENMASK* and REG_FIELD_GET*.
Also drop the bogus non-mirrored SSKP register define.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 27 ---
drivers/gpu/drm/i915/intel_pm.c | 24
From: Ville Syrjälä
Use the {active,scaled}_planes bitmasks from the crtc state
rather than poking at the plane state directly. One step
towards eliminating the last use of the somewhat questionble
intel_atomic_crtc_state_for_each_plane_state() macro which
peeks into the plane state without actua
From: Ville Syrjälä
snb_wm_latency_quirk() already boosts up the latency values
so the extra warning about the SSKPD value being insufficient
is now redundant. Drop it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 15 ---
1 file changed, 15 deletions(-)
diff
From: Ville Syrjälä
Exfiltrate intel_plane_atomic_calc_changes() and its friends from
intel_display.c to intel_atomic_plane.c since that is a much better
fit.
While at it also nuke the official looking kernel docs for
intel_wm_need_update() and flag it for eventual destruction so
that people don
From: Ville Syrjälä
Add another plane bitmask, this time tracking which planes are
scaled. This is going to be useful in ILK watermark computations,
and skl+ pipe scaler assignments.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic_plane.c | 5 +
drivers/gpu/drm/
From: Ville Syrjälä
No reason the high level intel_update_crtc() needs to know
that there is something magical about the commit order of
planes between different platforms. So let's hide that
detail even better.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 1
From: Ville Syrjälä
Move some plane stuff out from intel_display.c, introduce
a scaled_planes bitmask, and using that as an excuse clean
up a bunch of watermark registers.
Ville Syrjälä (8):
drm/i915: Move intel_plane_atomic_calc_changes() & co. out
drm/i915: Introduce intel_arm_planes_on_cr
On 10/02/2022 21:47, john.c.harri...@intel.com wrote:
From: John Harrison
It is possible for reset notifications to arrive for a context that is
in the process of being banned. So don't flag these as an error, just
report it as informational (because it is still useful to know that
resets are
On 2022-01-27 00:29:37 [+0100], Mario Kleiner wrote:
> Hi, first thank you for implementing these preempt disables according to
Hi Mario,
> the markers i left long ago. And sorry for the rather late reply.
>
> I had a look at the code, as of Linux 5.16, and did also a little test run
> (of a stan
On Thu, Feb 10, 2022 at 03:12:17PM -0800, Matt Roper wrote:
> Registers that exist within the MCH BAR and are mirrored into the GPU's
> MMIO space are a good candidate to separate out into their own header.
>
> For reference, the mirror of the MCH BAR lives at the following
> locations in the grap
On Fri, Feb 11, 2022 at 11:19:03AM +0530, Ramalingam C wrote:
> From: Matt Roper
>
> DG2 is the first platform, that supports TC but not TBT.
> interrupt code is updated to avoid trying to process
> TBT-specific bits and registers.
Is that a real concern?
>
> Cc: Swathi Dhanavanthri
> Signed-
81 matches
Mail list logo
