Yeah, that's a good point.
If build_bug_on() doesn't works for some reason then we at least need to
lower this to a WARN_ON.
A BUG_ON() is only justified if we prevent strong data corruption with
it or note a NULL pointer earlier on or similar.
Regards,
Christian.
Am 10.09.21 um 06:36 schr
Hi Linus,
Just an initial bunch of fixes for the merge window, amdgpu is most of
them with a few ttm fixes and an fbdev avoid multiply overflow fix.
Dave.
drm-next-2021-09-10:
drm fixes for 5.15-rc1
ttm:
- Fix ttm_bo_move_memcpy() when ttm_resource is subclassed.
- Fix ttm deadlock if target BO
On Thu, 9 Sept 2021 at 19:30, Daniel Vetter wrote:
>
> On Thu, Sep 9, 2021 at 5:35 AM Dave Airlie wrote:
> >
> > On Thu, 9 Sept 2021 at 03:44, Thomas Zimmermann wrote:
> > >
> > > Hi Dave and Daniel,
> > >
> > > here's this week's PR for drm-misc-fixes. One patch is a potential
> > > deadlock
>
Hi Chun-Kuang,
On Fri, Sep 10, 2021 at 07:37:50AM +0800, Chun-Kuang Hu wrote:
> Hi, Markus:
>
> Markus Schneider-Pargmann 於 2021年9月7日 週二 上午3:37寫道：
> >
> > This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.
> >
> > It supports both functional units on the mt8195, the embedded
> > D
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 be
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 term
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 d
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
---
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
operation
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
[AMD Official Use Only]
looks good to me.
But maybe build_bug_on works too and more reasonable to detect such wrong usage.
From: Chen, Guchun
Sent: Friday, September 10, 2021 12:30:14 PM
To: amd-...@lists.freedesktop.org ;
dri-devel@lists.freedesktop.org ; Koenig
Vendor will define their own memory types on top of TTM_PL_PRIV,
but call ttm_set_driver_manager directly without checking mem_type
value when setting up memory manager. So add such check to aware
the case when array bounds.
Signed-off-by: Leslie Shi
Signed-off-by: Guchun Chen
---
include/drm/t
Current (and older) Simics models for the Bochs VGA used the wrong PCI
vendor ID (0x4321 instead of 0x1234). Although this can hopefully be
fixed in the future, it is a problem for users of the current version,
not the least because to update the device ID the BIOS has to be
rebuilt in order to se
Hi all,
On Thu, 2 Sep 2021 11:22:08 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the amdgpu tree got a conflict in:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_ras_eeprom.c
>
> between commit:
>
> 477f70cd2a67 ("Merge tag 'drm-next-2021-08-31-1' of
> git://anongit.freedesktop.
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
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 ju
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 differen
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: Matt
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 Bro
Hi, Markus:
Markus Schneider-Pargmann 於 2021年9月7日 週二 上午3:37寫道：
>
> This patch adds a DisplayPort driver for the Mediatek mt8195 SoC.
>
> It supports both functional units on the mt8195, the embedded
> DisplayPort as well as the external DisplayPort units. It offers
> hot-plug-detection, audio up
Hi, Nancy:
Nancy.Lin 於 2021年9月6日 週一 下午3:15寫道：
>
> Add merge new API.
> 1. Vdosys1 merge1~merge4 support HW mute function, so add unmute API.
> 2. Add merge new advance config API. The original merge API is
>mtk_ddp_comp_funcs function prototype. The API interface parameters
>cannot be mod
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 ensu
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:
(Daniel
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 wit
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
d
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 this
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
drivers/gpu
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 10:15:56A
Quoting Doug Anderson (2021-09-09 14:14:29)
> On Thu, Sep 9, 2021 at 12:09 PM Stephen Boyd wrote:
> >
> >
> > Oh does this have register pages? regmap has support for pages where you
> > write some indirection register and then access the same i2c address for
> > the next page. This looks differen
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: R
Hi,
On Thu, Sep 9, 2021 at 12:09 PM Stephen Boyd wrote:
>
> Quoting Philip Chen (2021-09-09 11:29:19)
> > Hi,
> >
> > On Wed, Sep 8, 2021 at 2:54 PM Stephen Boyd wrote:
> > >
> > > Quoting Philip Chen (2021-09-08 11:18:05)
> > > > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> > > > b/dr
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 onl
As discussed in the patch ("dt-bindings: drm/panel-simple: Introduce
generic eDP panels") we can actually support probing eDP panels at
runtime instead of hardcoding what panel is connected. Add support to
the panel-edp driver for this.
We'll implement a solution like this:
* We'll read in two del
The simple-panel driver is for panels that are not hot-pluggable at
runtime. Let's keep our cached EDID around until driver unload.
Signed-off-by: Douglas Anderson
Acked-by: Sam Ravnborg
---
Changes in v4:
- panel-simple-edp => panel-edp
Changes in v3:
- ("Don't re-read the EDID every time") m
While cleaning up the descriptions of the delay for eDP panels I
realized that we'd have a bug if any panels need the
"prepare_to_enable" but HPD handling isn't happening in the panel
driver. Let's put in a stopgap to at least make us not violate
timings. This is not perfectly optimal but trying to
Now that the delays are named / described with eDP-centric names, it
becomes clear that we should really specify the "hpd_reliable" and
"hpd_absent" separately without taking the other into account. Let's
fix it.
This should be a no-op change and just adjust how we specify
things. The actual delay
Now that the eDP panel driver only handles eDP panels we can make
better sense of the delays here. Let's describe them in terms of the
standard eDP timing diagram from the eDP spec.
As part of this, it becomes pretty clear that some eDP panels have too
long of a "hpd_reliable_delay". This used to
All of the "HPD" handling added to panel-simple recently was for eDP
panels. Remove it from panel-simple now that panel-edp handles eDP
panels. The "prepare_to_enable" delay only makes sense in the context
of HPD, so remove it too. No non-eDP panels used it anyway.
Signed-off-by: Douglas Anderson
In the case where we can read an EDID for a panel the only part of the
panel description that can't be found directly from the EDID is the
description of the delays. Let's break the delay structure out so that
we can specify just the delays for panels that are detected by EDID.
This is simple code
The panel-simple driver handles way too much. Let's start trying to
get a handle on it by splitting out the eDP panels. This patch does
this:
1. Start by copying simple-panel verbatim over to a new driver,
simple-panel-edp.
2. Rename "panel_simple" to "panel_edp" in the new driver.
3. Keep only
Not all panels in panel-simple were marked what type of panel they
were. I searched through ARM/ARM64 Chromebooks or Chromebook-related
reference boards that I was aware of and found some panels that needed
to be moved. I also skimmed for panels that had no mode and were "big"
since it's quite rare
In the patch ("drm/panel-simple-edp: Split eDP panels out of
panel-simple") we split the PANEL_SIMPLE driver in 2. Let's enable the
new config.
Signed-off-by: Douglas Anderson
Acked-by: Sam Ravnborg
---
Changes in v4:
- PANEL_SIMPLE_EDP => PANEL_EDP
- Reordered config patches to be before code
In the patch ("drm/panel-simple-edp: Split eDP panels out of
panel-simple") we will split the PANEL_SIMPLE driver in two. By
default let's give everyone who had the old driver enabled the new
driver too. If folks want to opt-out of one or the other they always
can later.
Signed-off-by: Douglas And
In the patch ("drm/edid: Allow the querying/working with the panel ID
from the EDID") we introduced a different way of working with the
panel ID stored in the EDID. Let's use this new way for the quirks
code.
Advantages of the new style:
* Smaller data structure size. Saves 4 bytes per panel.
* It
EDIDs have 32-bits worth of data which is intended to be used to
uniquely identify the make/model of a panel. This has historically
been used only internally in the EDID processing code to identify
quirks with panels.
We'd like to use this panel ID in panel drivers to identify which
panel is hooke
A future change wants to be able to read just block 0 of the EDID, so
break it out of drm_do_get_edid() into a sub-function.
This is intended to be a no-op change--just code movement.
Signed-off-by: Douglas Anderson
Acked-by: Sam Ravnborg
---
Changes in v4:
- "u8 *edid" => "void *edid" to avoi
eDP panels generally contain almost everything needed to control them
in their EDID. This comes from their DP heritage were a computer needs
to be able to properly control pretty much any DP display that's
plugged into it.
The one big issue with eDP panels and the reason that we need a panel
drive
The goal of this patch series is to move away from hardcoding exact
eDP panels in device tree files. As discussed in the various patches
in this series (I'm not repeating everything here), most eDP panels
are 99% probable and we can get that last 1% by allowing two "power
up" delays to be specified
On Thu, Sep 9, 2021 at 12:50 PM Akhil P Oommen wrote:
>
> On 9/9/2021 9:42 PM, Amit Pundir wrote:
> > On Thu, 9 Sept 2021 at 17:47, Amit Pundir wrote:
> >>
> >> On Wed, 8 Sept 2021 at 07:50, Bjorn Andersson
> >> wrote:
> >>>
> >>> On Mon 09 Aug 10:26 PDT 2021, Akhil P Oommen wrote:
> >>>
>
Hi,
On Wed, Sep 1, 2021 at 1:20 PM Douglas Anderson wrote:
>
> The "logicpd_type_28" panel data was splitting up the
> mitsubishi_aa070mc01 panel data. Reorganize it so that the panel descs
> and modes are kept together.
>
> This is a no-op code-cleanup change, found by code inspection.
>
> Signe
On Wed, Sep 08, 2021 at 02:10:48PM -0700, Doug Anderson wrote:
> Hi,
>
> On Sun, Sep 5, 2021 at 11:46 AM Sam Ravnborg wrote:
> >
> > On Wed, Sep 01, 2021 at 01:19:28PM -0700, Douglas Anderson wrote:
> > > All of the "HPD" handling added to panel-simple recently was for eDP
> > > panels. Remove it
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 06:09:55P
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 08:00:02A
On 9/9/2021 9:42 PM, Amit Pundir wrote:
On Thu, 9 Sept 2021 at 17:47, Amit Pundir wrote:
On Wed, 8 Sept 2021 at 07:50, Bjorn Andersson
wrote:
On Mon 09 Aug 10:26 PDT 2021, Akhil P Oommen wrote:
On 8/9/2021 9:48 PM, Caleb Connolly wrote:
On 09/08/2021 17:12, Rob Clark wrote:
On Mon, Au
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 thi
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 vfio_
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
implementati
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 fil
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 +-
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
+++ b/
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 op
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 f
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 th
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 b/drive
Hi,
On Sun, Sep 5, 2021 at 11:42 AM Sam Ravnborg wrote:
>
> > +++ b/drivers/gpu/drm/panel/panel-simple-edp.c
> > @@ -0,0 +1,1298 @@
> > +/*
> > + * Copyright (C) 2013, NVIDIA Corporation. All rights reserved.
> > + *
> > + * Permission is hereby granted, free of charge, to any person obtaining a
Quoting Philip Chen (2021-09-09 11:29:19)
> Hi,
>
> On Wed, Sep 8, 2021 at 2:54 PM Stephen Boyd wrote:
> >
> > Quoting Philip Chen (2021-09-08 11:18:05)
> > > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> > > b/drivers/gpu/drm/bridge/parade-ps8640.c
> > > index 685e9c38b2db..a16725dbf912
Quoting Philip Chen (2021-09-09 11:15:27)
> On Wed, Sep 8, 2021 at 3:27 PM Stephen Boyd wrote:
> >
> > Quoting Philip Chen (2021-09-08 11:18:06)
> >
> > > +
> > > + data = (len - 1) & AUX_LENGTH_MASK;
> > > + regmap_write(map, PAGE0_AUX_LENGTH, data);
> > > +
> > > + if (request
https://bugzilla.kernel.org/show_bug.cgi?id=213917
--- Comment #2 from Samuel Sieb (samuel-kb...@sieb.net) ---
I just tried with 5.14.1 and resuming works again. I still get those messages
in the log, so apparently they aren't relevant to this issue.
--
You may reply to this email to add a comm
Hi,
On Wed, Sep 8, 2021 at 2:54 PM Stephen Boyd wrote:
>
> Quoting Philip Chen (2021-09-08 11:18:05)
> > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> > b/drivers/gpu/drm/bridge/parade-ps8640.c
> > index 685e9c38b2db..a16725dbf912 100644
> > --- a/drivers/gpu/drm/bridge/parade-ps8640.c
>
Hi,
On Wed, Sep 8, 2021 at 3:27 PM Stephen Boyd wrote:
>
> Quoting Philip Chen (2021-09-08 11:18:06)
> > diff --git a/drivers/gpu/drm/bridge/parade-ps8640.c
> > b/drivers/gpu/drm/bridge/parade-ps8640.c
> > index a16725dbf912..3f0241a60357 100644
> > --- a/drivers/gpu/drm/bridge/parade-ps8640.c
>
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 05:39:26P
W dniu 08.09.2021 o 15:29, Christian König pisze:
> Clean up to start over with new and more accurate documentation.
>
> Signed-off-by: Christian König
> Reviewed-by: Matthew Auld
Thanks for fixing documentation, I hope it will be also expanded :)
For the whole series:
Reviewed-by: Andrzej
Il 09/09/21 15:46, Dmitry Baryshkov ha scritto:
On 08/09/2021 17:22, Jeffrey Hugo wrote:
On Wed, Sep 8, 2021 at 2:26 AM Dmitry Baryshkov
wrote:
Hi,
On Tue, 7 Sept 2021 at 22:13, Jeffrey Hugo wrote:
On Wed, Sep 1, 2021 at 12:11 PM AngeloGioacchino Del Regno
wrote:
Bringup functionality
On Fri, Aug 27, 2021 at 04:31:19PM +0800, Huacai Chen wrote:
> My original work is at [1].
>
> Bjorn do some rework and extension in V2. It moves the VGA arbiter to
> the PCI subsystem, fixes a few nits, and breaks a few pieces to make
> the main patch a little smaller.
>
> V3 rewrite the commit
Hi
Am 08.09.21 um 21:31 schrieb Sam Ravnborg:
Hi Thomas,
On Wed, Sep 08, 2021 at 07:50:42PM +0200, Thomas Zimmermann wrote:
Hi
Am 03.08.21 um 07:10 schrieb Sam Ravnborg:
Hi Anitha,
On Mon, Aug 02, 2021 at 08:44:26PM +, Chrisanthus, Anitha wrote:
Hi Sam,
Thanks. Where should this go, dr
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 07:29:33A
On Thu, Sep 9, 2021 at 9:42 AM Simon Ser wrote:
>
> On Thursday, September 9th, 2021 at 18:31, Rob Clark
> wrote:
>
> > Yes, I think it would.. and "dma-buf/sync_file: Add SET_DEADLINE
> > ioctl" adds such an ioctl.. just for the benefit of igt tests at this
> > point, but the thought was it wou
On Thu, 9 Sept 2021 at 17:43, Koenig, Christian
wrote:
>
> Hi Matthew,
>
> this doesn't work, I've already tried something similar.
>
> TTM uses the reverse lookup functionality when migrating BOs between system
> and device memory. And that doesn't seem to work with pages from a shmem file.
Hmm
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
---
drivers/gpu/drm/i915/gt/intel_co
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
---
drivers
Reset LRC descriptor if a context register returns -ENODEV as this means
we are mid-reset.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 6
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
To make ownership of locking clear move fields (guc_id, guc_id_ref,
guc_id_link) to sub structure guc_id in intel_context.
Reviewed-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 4 +-
drivers/gpu/drm/i915/gt/intel_context_types.h |
Don't drop ce->guc_active.lock when unwinding a context after reset.
At one point we had to drop this because of a lock inversion but that is
no longer the case. It is much safer to hold the lock so let's do that.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Rev
Before we did some clever tricks to not use the a lock when touching
guc_state.sched_state in certain cases. Don't do that, enforce the use
of the lock.
v2:
(kernel test robo )
- Add __maybe_unused to sched_state_is_init()
v3: rebase after the unused code path removal has been moved to an
earl
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 +--
drivers
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 -> guc_state
A subsequent patch will flip the locking hierarchy from
ce->guc_state.lock -> sched_engine->lock to sched_engine->lock ->
ce->guc_state.lock. As such we need to release the submit fence for a
request from an IRQ to break a lock inversion - i.e. the fence must be
release went holding ce->guc_state.l
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
When unblocking a context, do not enable scheduling if the context is
banned, guc_id invalid, or not registered.
v2:
(Daniele)
- Add helper for unblock
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
Cc:
---
When unwinding requests on a reset context, if other requests in the
context are in the priority list the requests could be resubmitted out
of seqno order. Traverse the list of active requests in reverse and
append to the head of the priority list to fix this.
Fixes: eb5e7da736f3 ("drm/i915/guc: R
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
---
.../gpu/drm/i9
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
If the context is reset as a result of the request cancellation the
context reset G2H is received after schedule disable done G2H which is
the wrong order. The schedule disable done G2H release the waiting
request cancellation code which resubmits the context. This races
with the context reset G2H
A small race that could result in incorrect accounting of the number
of outstanding G2H. Basically prior to this patch we did not increment
the number of outstanding G2H if we encoutered a GT reset while sending
a H2G. This was incorrect as the context state had already been updated
to anticipate a
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
---
drivers/gpu/
Propagating errors to dependent fences is broken and can lead to errors
from one client ending up in another. In commit 3761baae908a ("Revert
"drm/i915: Propagate errors on awaiting already signaled fences""), we
attempted to get rid of fence error propagation but missed the case
added in commit 8e
When the GuC does a media reset, it copies a golden context state back
into the corrupted context's state. The address of the golden context
and the size of the engine state restore are passed in via the GuC ADS.
The i915 had a bug where it passed in the whole size of the golden
context, not the si
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
1 - 100 of 319 matches
Mail list logo
