== Series Details ==
Series: i915: Simplify mmio handling & add new DG2 shadow table
URL : https://patchwork.freedesktop.org/series/94534/
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: i915: Simplify mmio handling & add new DG2 shadow table
URL : https://patchwork.freedesktop.org/series/94534/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9184ecd8873a drm/i915/uncore: Convert gen6/gen7 read operations to fwtable
2d9ea1a952fa
Now that we have both a standard forcewake table (albeit a single-entry
table) and the shadow table stored in the uncore, we can drop the
gen8-specific write handlers in favor of the general fwtable version.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_uncore.c | 13 +
1
Now that the reference to the shadow table is stored within the uncore,
we don't need to generate separate fwtable, gen11_fwtable, and
gen12_fwtable variants of the register write functions; a single
'fwtable' implementation will work for all of those platforms now.
Note that while consolidating
Consolidate down to just a single 'fwtable' implementation. For reads
we don't need to worry about shadow tables. Also, the
NEEDS_FORCE_WAKE() check we previously had in the fwtable implementation
can be dropped --- if a register is outside that range on one of the old
platforms, then it won't
Store a reference to a platform's shadow table inside the uncore, the
same as we do with the forcewake table. This will allow us to use a
single set of functions that operate on the shadow table reference
rather than generating lots of nearly-identical functions via macros
that differ only in
We thought the DG2 table of shadowed registers would be the same as the
gen12/xehp table, but it turns out that there are a few minor
differences that require us to define a new DG2-specific table:
* One register is removed (0xC4D4)
* One register is added (0xC4E0)
Signed-off-by: Matt Roper
On gen6-gen8 (except vlv/chv) we don't use a forcewake lookup table; we
simply check whether the register offset is < 0x4, and return
FORCEWAKE_RENDER if it is. To prepare for upcoming refactoring, let's
define a single-entry forcewake table from [0x0, 0x3] and switch
these platforms over
Our uncore MMIO functions for reading/writing registers have become very
complicated over time. There's significant macro magic used to generate
several nearly-identical functions that only really differ in terms of
which platform-specific shadow register table they should check on write
== Series Details ==
Series: series starting with [01/25] drm/i915/uncore: split the fw get function
into separate vfunc
URL : https://patchwork.freedesktop.org/series/94529/
State : failure
== Summary ==
Applying: drm/i915/uncore: split the fw get function into separate vfunc
Applying:
From: Dave Airlie
Use a nop table for the cases where CxSR doesn't init properly.
v2: use a nop table (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_display.c | 34 -
drivers/gpu/drm/i915/i915_drv.h | 2 +-
From: Dave Airlie
I used a macro to avoid making any really silly mistakes here.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 78 +++--
2 files changed, 55 insertions(+), 25
From: Dave Airlie
Make nice clear tables instead of having things in two places.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_display.c | 81
drivers/gpu/drm/i915/i915_drv.h | 2 +-
2 files changed, 52
From: Dave Airlie
This is a bit of a twisty one since each platform is slightly
different, so might take some more review care.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 300 ++---
drivers/gpu/drm/i915/i915_drv.h
From: Dave Airlie
There was some excess comments and an unused vtbl ptr.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_drv.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index
From: Dave Airlie
Most the dpll vtable into read-only memory.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +--
drivers/gpu/drm/i915/display/intel_dpll.c| 48
drivers/gpu/drm/i915/i915_drv.h |
From: Dave Airlie
Move the functions into read-only tables.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_audio.c | 43 ++
drivers/gpu/drm/i915/i915_drv.h| 2 +-
2 files changed, 28 insertions(+), 17 deletions(-)
From: Dave Airlie
This clarifies quite well what functions get used on what platforms
instead of having to decipher the old tree.
v2: fixed IVB mistake (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_color.c | 138 ++---
From: Dave Airlie
Put the vtable into ro memory.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_fdi.c | 20
drivers/gpu/drm/i915/i915_drv.h | 2 +-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git
From: Dave Airlie
Use a macro to avoid mistakes, this type of macro is only used
in a couple of places.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 4 +--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
From: Dave Airlie
this single function might be possible to merge later, but
for now it's simple to just split it out.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
drivers/gpu/drm/i915/display/intel_dpll.c| 16
From: Dave Airlie
It may make sense to merge this with display again later,
however the fdi use of the vtable is limited to only a
few generations.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_fdi.c | 8
drivers/gpu/drm/i915/i915_drv.h
From: Dave Airlie
This provide a service from irq to display, so make it separate
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 9 -
drivers/gpu/drm/i915/i915_irq.c
From: Dave Airlie
This moves all the cdclk related functions into their own vtable.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 142 ++---
drivers/gpu/drm/i915/i915_drv.h| 8 +-
2 files changed, 78
From: Dave Airlie
These are only used internally in the audio code
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_audio.c | 24 +++---
drivers/gpu/drm/i915/i915_drv.h| 19 +++--
2 files changed, 25
From: Dave Airlie
These are only used internally in the color module
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_color.c | 64 +++---
drivers/gpu/drm/i915/i915_drv.h| 39 +++--
2 files changed, 54
From: Dave Airlie
These are the watermark api between display and pm.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_display.c | 35 -
drivers/gpu/drm/i915/i915_drv.h | 24
drivers/gpu/drm/i915/intel_pm.c | 40
From: Dave Airlie
This function is only used inside intel_pm.c
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_drv.h | 9 ++-
drivers/gpu/drm/i915/intel_pm.c | 48 -
2 files changed, 32 insertions(+), 25 deletions(-)
From: Dave Airlie
This wraps the fdi link training vfunc to make it clearer.
Suggested by Jani.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
drivers/gpu/drm/i915/display/intel_fdi.c | 8
drivers/gpu/drm/i915/display/intel_fdi.h | 2 ++
From: Dave Airlie
This adds wrappers around all the vtable callers so they are in
one place.
Suggested by Jani.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_cdclk.c| 47 +++
drivers/gpu/drm/i915/display/intel_cdclk.h| 4 +-
From: Dave Airlie
This moves one wrapper from the pm->display side, and creates
wrappers for all the others, this should simplify things later.
One thing to note is that the code checks the existance of some
of these ptrs, so the wrappers are a bit complicated by that.
Suggested by Jani.
v2:
From: Dave Airlie
The crtc was never being used here.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/display/intel_display.c | 10 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 20
From: Dave Airlie
The i845_update_wm code was always calling the i845 variant,
and the i9xx_update_wm had only a choice between i830 and i9xx
paths, hardly worth the vfunc overhead.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/i915_drv.h | 2 --
From: Dave Airlie
This reworks the uncore function vtable so that it's constant.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/intel_uncore.c | 139 +---
drivers/gpu/drm/i915/intel_uncore.h | 8 +-
2 files changed, 89 insertions(+), 58
From: Dave Airlie
constify it while here. drop the put function since it was never
overloaded and always has done the same thing, no point in
indirecting it for show.
Reviewed-by: Jani Nikula
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/intel_uncore.c | 70
v4: I know I could have resent one patch but there was a bit of
rebase fallout from it, and it had another subtle bug, I also
fixed the kerneldoc.
(v3 just adds some missing ,)
Details below, I've taken all the review feedback (thanks Jani).
I added 3 patches moving to wrappers before
== Series Details ==
Series: series starting with [1/5] drm/i915/display/adlp: Fix
PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR calculation
URL : https://patchwork.freedesktop.org/series/94526/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10566_full -> Patchwork_21008_full
On Thu, Sep 09, 2021 at 03:46:43PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > Taking a PM reference to prevent intel_gt_wait_for_idle from short
> > circuiting while a scheduling of user context could be enabled.
> As with earlier PM patch, needs more explanation of
== Series Details ==
Series: series starting with [1/5] drm/i915/display/adlp: Fix
PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR calculation
URL : https://patchwork.freedesktop.org/series/94526/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10566 -> Patchwork_21008
On Thu, Sep 09, 2021 at 03:36:44PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > Sometimes it is desirable to queue work up for later if the GT PM isn't
> > held and run that work on next GT PM unpark.
> What is the reason for doing this? Why is it important? Why not
On Thu, Sep 09, 2021 at 03:28:51PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > Taking a PM reference to prevent intel_gt_wait_for_idle from short
> > circuiting while a deregister context H2G is in flight.
> >
> > FIXME: Move locking / structure changes into
On Thu, Sep 09, 2021 at 03:16:22PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > For testing purposes it may make sense to reduce the number of guc_ids
> > available to be allocated. Add debugfs support for setting the number of
> > guc_ids.
> >
> > Signed-off-by:
On Thu, Sep 09, 2021 at 03:13:29PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > Number of available GuC contexts ids might be limited.
> > Stop referring in code to macro and use variable instead.
> >
> > Signed-off-by: Michal Wajdeczko
> > Signed-off-by: Matthew
== Series Details ==
Series: series starting with [1/5] drm/i915/display/adlp: Fix
PSR2_MAN_TRK_CTL_SU_REGION_END_ADDR calculation
URL : https://patchwork.freedesktop.org/series/94526/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used,
This addresses Cornelia's remark on the earlier patch that ccw has a
confusing lifecycle. While it doesn't seem like the original attempt was
functionally wrong, the result can be made better with a lot of further
work.
Reorganize the driver so that the mdev owns the private memory and
controls
vfio_ccw will need it.
Signed-off-by: Jason Gunthorpe
---
drivers/vfio/vfio.c | 3 ++-
include/linux/vfio.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
index c3ca33e513c8e9..e78278a0b98a96 100644
--- a/drivers/vfio/vfio.c
+++
mdev_device should only be used in functions assigned to ops callbacks,
interior functions should use the struct vfio_ccw_private instead of
repeatedly trying to get it from the mdev.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_ops.c | 37 +
1
This is a more complicated conversion because vfio_ccw is sharing the
vfio_device between both the mdev_device, its vfio_device and the
css_driver.
The mdev is a singleton, and the reason for this sharing is so the extra
css_driver function callbacks to be delivered to the vfio_device
Many of the mdev drivers use a simple counter for keeping track of the
available instances. Move this code to the core code and store the counter
in the mdev_type. Implement it using correct locking, fixing mdpy.
Drivers provide a get_available() callback to set the number of available
instances
Makes the code easier to understand what is memory lifecycle and what is
other stuff.
Signed-off-by: Jason Gunthorpe
---
drivers/s390/cio/vfio_ccw_drv.c | 137 ++--
1 file changed, 78 insertions(+), 59 deletions(-)
diff --git a/drivers/s390/cio/vfio_ccw_drv.c
The subchannel should be left in a quiescent state unless the VFIO device
FD is opened. When the FD is opened bring the chanel to active and allow
the VFIO device to operate. When the device FD is closed then quiesce the
channel.
To make this work the FSM needs to handle the transitions to/from
The css_driver's main purpose is to create/destroy the mdev and relay the
shutdown, irq, sch_event, and chp_event css_driver ops to the single
created vfio_device, if it exists.
Reframe the boundary where the css_driver domain switches to the vfio
domain by using rcu to read and refcount the
Every driver just emits a static string, simply feed it through the ops
and provide a standard sysfs show function.
Signed-off-by: Jason Gunthorpe
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 9 +
drivers/s390/cio/vfio_ccw_ops.c | 9 +
drivers/s390/crypto/vfio_ap_ops.c | 9
Having a mdev pointer floating about in addition to a struct vfio_device
is confusing. It is only used for three things:
- Getting the mdev 'struct device *' - this is the same as
private->vdev.dev
- Printing the uuid of the mdev in logging. The uuid is also the dev_name
of the mdev so
Not sure why but when moving the cursor fast it causes some artifacts
of the cursor to be left in the cursor path, adding some pixels above
the cursor to the damaged area fixes the issue, so leaving this as a
workaround until proper fix is found.
This is reproducile on TGL and ADL-P.
Cc:
drm_atomic_helper_damage_iter_init() + drm_atomic_for_each_plane_damage()
returns the full plane area in case no damaged area was set by
userspace or it was discarted by driver.
This is important to fix the rendering of userspace applications that
does frontbuffer rendering and notify driver
BSpec states that the minimum number of frames before selective update
is 2, so making sure this minimum limit is fulfilled.
BSpec: 50422
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
As the SU_REGION_START begins at 0, the SU_REGION_END should be number
of lines - 1.
BSpec: 50424
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Wa_16014451276 fixes the starting coordinate for PSR2 selective
updates. CHICKEN_TRANS definition of the workaround bit has a wrong
name based on workaround definition and HSD.
Wa_14014971508 allows the screen to continue to be updated when
coming back from DC5/DC6 and SF_SINGLE_FULL_FRAME bit is
On 8/20/2021 15:44, Matthew Brost wrote:
Calling switch_to_kernel_context isn't needed if the engine PM reference
is taken while all contexts are pinned. By not calling
switch_to_kernel_context we save on issuing a request to the engine.
I thought the intention of the switch_to_kernel was to
On 8/20/2021 15:44, Matthew Brost wrote:
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a scheduling of user context could be enabled.
As with earlier PM patch, needs more explanation of what the problem is
and why it is only now a problem.
v2:
On 8/20/2021 15:44, Matthew Brost wrote:
Sometimes it is desirable to queue work up for later if the GT PM isn't
held and run that work on next GT PM unpark.
What is the reason for doing this? Why is it important? Why not just
take the GT PM at the time the work is requested?
Implemented
On 8/20/2021 15:44, Matthew Brost wrote:
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a deregister context H2G is in flight.
FIXME: Move locking / structure changes into different patch
This split needs to be done. It would also be helpful to have a more
On 8/20/2021 15:44, Matthew Brost wrote:
For testing purposes it may make sense to reduce the number of guc_ids
available to be allocated. Add debugfs support for setting the number of
guc_ids.
Signed-off-by: Matthew Brost
It 'may make sense'? Is there an actual IGT/selftest test that uses
On 8/20/2021 15:44, Matthew Brost wrote:
Number of available GuC contexts ids might be limited.
Stop referring in code to macro and use variable instead.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 4
On Thu, Sep 09, 2021 at 01:33:23PM -0700, Matt Roper wrote:
> On Thu, Sep 09, 2021 at 10:59:36PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 09, 2021 at 11:14:15AM -0700, Matt Roper wrote:
> > > On Thu, Sep 09, 2021 at 08:42:15PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Sep 09, 2021 at
On Thu, Sep 09, 2021 at 05:29:14AM -0700, Daniele Ceraolo Spurio wrote:
> Now that all the pieces are in place we can add a description of how the
> feature works. Also modify the comments in struct intel_pxp into
> kerneldoc.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Daniel Vetter
> Cc:
== Series Details ==
Series: series starting with [1/1] drm/i915: Add support for sbr and flr as a
fallback
URL : https://patchwork.freedesktop.org/series/94518/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10565_full -> Patchwork_21005_full
On Thu, Sep 09, 2021 at 05:29:08AM -0700, Daniele Ceraolo Spurio wrote:
> This api allow user mode to create protected buffers and to mark
> contexts as making use of such objects. Only when using contexts
> marked in such a way is the execution guaranteed to work as expected.
>
> Contexts can
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/display/skl+: Drop frontbuffer
rendering support
URL : https://patchwork.freedesktop.org/series/94522/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10565 -> Patchwork_21007
On Thu, Sep 09, 2021 at 10:59:36PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 09, 2021 at 11:14:15AM -0700, Matt Roper wrote:
> > On Thu, Sep 09, 2021 at 08:42:15PM +0300, Ville Syrjälä wrote:
> > > On Thu, Sep 09, 2021 at 10:15:56AM -0700, Matt Roper wrote:
> > > > On Thu, Sep 09, 2021 at
On Thu, Sep 09, 2021 at 08:23:20PM +, Souza, Jose wrote:
> On Thu, 2021-09-09 at 23:20 +0300, Ville Syrjälä wrote:
> > On Thu, Sep 09, 2021 at 12:49:16PM -0700, José Roberto de Souza wrote:
> > > By now all the userspace applications should have migrated to atomic
> > > or at least be calling
On Thu, 2021-09-09 at 23:20 +0300, Ville Syrjälä wrote:
> On Thu, Sep 09, 2021 at 12:49:16PM -0700, José Roberto de Souza wrote:
> > By now all the userspace applications should have migrated to atomic
> > or at least be calling DRM_IOCTL_MODE_DIRTYFB.
> >
> > With that we can kill frontbuffer
On Thu, Sep 09, 2021 at 12:49:16PM -0700, José Roberto de Souza wrote:
> By now all the userspace applications should have migrated to atomic
> or at least be calling DRM_IOCTL_MODE_DIRTYFB.
>
> With that we can kill frontbuffer rendering support in i915 for
> modern platforms.
>
> So here
== Series Details ==
Series: series starting with [CI,1/2] drm/i915/display/skl+: Drop frontbuffer
rendering support
URL : https://patchwork.freedesktop.org/series/94522/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8ed17fa41e37 drm/i915/display/skl+: Drop frontbuffer
On Thu, Sep 09, 2021 at 11:14:15AM -0700, Matt Roper wrote:
> On Thu, Sep 09, 2021 at 08:42:15PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 09, 2021 at 10:15:56AM -0700, Matt Roper wrote:
> > > On Thu, Sep 09, 2021 at 06:09:55PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Sep 09, 2021 at
== Series Details ==
Series: series starting with [1/1] drm/i915: Add support for sbr and flr as a
fallback
URL : https://patchwork.freedesktop.org/series/94518/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10565 -> Patchwork_21005
== Series Details ==
Series: Move vfio_ccw to the new mdev API
URL : https://patchwork.freedesktop.org/series/94520/
State : failure
== Summary ==
Applying: vfio/ccw: Use functions for alloc/free of the vfio_ccw_private
Using index info to reconstruct a base tree...
M
By now all the userspace applications should have migrated to atomic
or at least be calling DRM_IOCTL_MODE_DIRTYFB.
With that we can kill frontbuffer rendering support in i915 for
modern platforms.
So here converting legacy APIs into atomic commits so it can be
properly handled by driver i915.
After commit "drm/i915/display/skl+: Drop frontbuffer rendering
support" frontbuffer rendering is not supported for display 9 and
newer and as PSR is only supported by default in display 9 and newer
we can now drop all frontbuffer rendering support for PSR code.
Some DC3CO code was commented with
== Series Details ==
Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev11)
URL : https://patchwork.freedesktop.org/series/93704/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10565_full -> Patchwork_21004_full
In the event engine or GT reset fails, fall back to function
level reset and then secondary bus reset. If nothing works,
wedge the device.
Cc: Joonas Lahtinen
Cc: Aravind Iddamsetty
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/gt/intel_reset.c | 52 +++
1
== Series Details ==
Series: Enable GuC submission by default on DG1 (rev4)
URL : https://patchwork.freedesktop.org/series/93325/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10565_full -> Patchwork_21003_full
Summary
On Thu, Sep 09, 2021 at 08:42:15PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 09, 2021 at 10:15:56AM -0700, Matt Roper wrote:
> > On Thu, Sep 09, 2021 at 06:09:55PM +0300, Ville Syrjälä wrote:
> > > On Thu, Sep 09, 2021 at 08:00:02AM -0700, Matt Roper wrote:
> > > > On Thu, Sep 09, 2021 at
== Series Details ==
Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev11)
URL : https://patchwork.freedesktop.org/series/93704/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10565 -> Patchwork_21004
On Thu, Sep 09, 2021 at 10:15:56AM -0700, Matt Roper wrote:
> On Thu, Sep 09, 2021 at 06:09:55PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 09, 2021 at 08:00:02AM -0700, Matt Roper wrote:
> > > On Thu, Sep 09, 2021 at 05:39:26PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Sep 09, 2021 at
== Series Details ==
Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev11)
URL : https://patchwork.freedesktop.org/series/93704/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked
== Series Details ==
Series: Clean up GuC CI failures, simplify locking, and kernel DOC (rev11)
URL : https://patchwork.freedesktop.org/series/93704/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
deb17f151cef drm/i915/guc: Fix blocked context accounting
7b4cd4d6bb36
+Cc a couple more people.
On Thu, Sep 09, 2021 at 10:15:57AM -0700, Matt Roper wrote:
> On Thu, Sep 09, 2021 at 06:09:55PM +0300, Ville Syrjälä wrote:
> > On Thu, Sep 09, 2021 at 08:00:02AM -0700, Matt Roper wrote:
> > > On Thu, Sep 09, 2021 at 05:39:26PM +0300, Ville Syrjälä wrote:
> > > > On
On Thu, Sep 09, 2021 at 06:09:55PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 09, 2021 at 08:00:02AM -0700, Matt Roper wrote:
> > On Thu, Sep 09, 2021 at 05:39:26PM +0300, Ville Syrjälä wrote:
> > > On Thu, Sep 09, 2021 at 07:29:33AM -0700, Matt Roper wrote:
> > > > On Thu, Sep 09, 2021 at
Rework and simplify the locking with GuC subission. Drop
sched_state_no_lock and move all fields under the guc_state.sched_state
and protect all these fields with guc_state.lock . This requires
changing the locking hierarchy from guc_state.lock -> sched_engine.lock
to sched_engine.lock ->
While debugging an issue with full GT resets I went down a rabbit hole
thinking the scrubbing of lost G2H wasn't working correctly. This proved
to be incorrect as this was working just fine but this chase inspired me
to write a selftest to prove that this works. This simple selftest
injects errors
Kick tasklet after queuing a request so it submitted in a timely manner.
Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for new
inteface")
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
1 file
A context can get destroyed after cancelling a request, if a context or
GT reset occurs, so take a reference to context when cancelling a
request.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
Add GuC kernel doc for all structures added thus far for GuC submission
and update the main GuC submission section with the new interface
details.
v2:
- Drop guc_active.lock DOC
v3:
- Fixup a few kernel doc comments (Daniele)
v4 (Daniele):
- Implement doc suggestions from John
- Add kerneldoc
Move GuC management fields in context under guc_active struct as this is
where the lock that protects theses fields lives. Also only set guc_prio
field once during context init.
v2:
(Daniele)
- set CONTEXT_SET_INIT
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
Now that we have locking hierarchy of sched_engine->lock ->
ce->guc_state everything from guc_active can be moved into guc_state and
protected the guc_state.lock.
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_context.c | 10 +--
Drop pin count check trick between a sched_disable and re-pin, now rely
on the lock and counter of the number of committed requests to determine
if scheduling should be disabled on the context.
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
Move guc_blocked fence to struct guc_state as the lock which protects
the fence lives there.
s/ce->guc_blocked/ce->guc_state.blocked/g
v2:
(Daniele)
- s/blocked_fence/blocked/g
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c
Lock the xarray and take ref to the context if needed.
v2:
(Checkpatch)
- Add new line after declaration
(Daniel Vetter)
- Correct put / get accounting in xa_for_loops
v3:
(Checkpatch)
- Extra new line
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
1 - 100 of 190 matches
Mail list logo
