The VGA arbitration is entirely based on pci_dev structures, so just pass
that back to the set_vga_decode callback.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9
drivers/gpu/drm/i915/display/intel_vga.c | 7 ---
drivers/gpu/drm/nouveau/nouv
All callers pass NULL as the irq_set_state argument, so remove it and
the ->irq_set_state member in struct vga_device.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/i915/display/intel_vga.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_vga.
Add a trivial wrapper for the unregister case that sets all fields to
NULL.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/drm_irq.c | 4 ++--
drivers/gpu/drm/i915/display/intel_vga.c | 2 +-
drivers/gpu/drm/nouveau/nouv
Merge the different CONFIG_VGA_ARB ifdef blocks, remove superflous
externs, and regularize the stubs for !CONFIG_VGA_ARB.
Signed-off-by: Christoph Hellwig
---
include/linux/vgaarb.h | 90 --
1 file changed, 42 insertions(+), 48 deletions(-)
diff --git a/i
Kerneldoc comments should be at the implementation side, not in the
header just declaring the prototype.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/vga/vgaarb.c | 11 +++
include/linux/vgaarb.h | 13 -
2 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/d
vga_conflicts only has a single caller and none of the arch overrides
mentioned in the comment. Just remove it and the thus dead check in the
caller.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/vga/vgaarb.c | 6 --
include/linux/vgaarb.h | 12
2 files changed, 18 deleti
The define is entirely unused.
Signed-off-by: Christoph Hellwig
---
include/linux/vgaarb.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
index dc6ddce92066..26ec8a057d2a 100644
--- a/include/linux/vgaarb.h
+++ b/include/linux/vgaarb.h
@@
Hi all,
this series cleans up a bunch of lose ends in the vgaarb code.
Diffstat:
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 11 +-
drivers/gpu/drm/drm_irq.c |4
drivers/gpu/drm/i915/display/intel_vga.c |9 +-
drivers/gpu/drm/nouveau/nouveau_vga.c |8 -
dr
On Thu, Jul 15, 2021 at 03:00:55PM -0600, Alex Williamson wrote:
> On Wed, 14 Jul 2021 21:20:38 -0300
> Jason Gunthorpe wrote:
> > +/*
> > + * We need to get memory_lock for each device, but devices can share
> > mmap_lock,
> > + * therefore we need to zap and hold the vma_lock for each device, a
__i915_gem_ttm_object_init() was ignoring the placement requests coming
from the client and always placing all BOs in SMEM upon creation.
Instead, compute the requested placement set from the object and pass
that into ttm_bo_init_reserved().
Signed-off-by: Jason Ekstrand
Cc: Thomas Hellström
Cc:
From: Thomas Hellström
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf attach time if possible.
v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
selftest to migrate if we are LMEM capable.
v3:
- Migrate also in the pin() c
From: Thomas Hellström
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to rec
Whenever we had a user object (n_placements > 0), we were ignoring
obj->mm.region and always putting obj->placements[0] as the requested
region. For LMEM+SMEM objects, this was causing them to get shoved into
LMEM on every i915_ttm_get_pages() even when SMEM was requested by, say,
i915_gem_object_
Instead of hand-rolling the same three calls in each function, pull them
into an i915_gem_object_create_user helper. Apart from re-ordering of
the placements array ENOMEM check, the only functional change here
should be that i915_gem_dumb_create now calls i915_gem_flush_free_objects
which it proba
We don't roll them together entirely because there are still a couple
cases where we want a separate can_migrate check. For instance, the
display code checks that you can migrate a buffer to LMEM before it
accepts it in fb_create. The dma-buf import code also uses it to do an
early check and retu
Since we don't allow changing the set of regions after creation, we can
make ext_set_placements() build up the region set directly in the
create_ext and assign it to the object later. This is similar to what
we did for contexts with the proto-context only simpler because there's
no funny object sh
This patch series fixes an issue with discrete graphics on Intel where we
allowed dma-buf import while leaving the object in local memory. This
breaks down pretty badly if the import happened on a different physical
device.
Jason Ekstrand (5):
drm/i915/gem: Check object_can_migrate from object_
On Thu, 15 Jul 2021 19:11:49 -0300
Jason Gunthorpe wrote:
> On Thu, Jul 15, 2021 at 03:00:55PM -0600, Alex Williamson wrote:
> > On Wed, 14 Jul 2021 21:20:38 -0300
> > Jason Gunthorpe wrote:
> > > +/*
> > > + * We need to get memory_lock for each device, but devices can share
> > > mmap_lock,
On 6/16/2021 03:25, Daniel Vetter wrote:
On Thu, Jun 10, 2021 at 10:46 PM wrote:
From: John Harrison
Various UMDs need to know the L3 bank count. So add a query API for it.
Please link to both the igt test submission for this (there's not even
a Test-with: on the cover letter)
Is there a wik
On Wed, 14 Jul 2021 21:20:38 -0300
Jason Gunthorpe wrote:
> +/*
> + * We need to get memory_lock for each device, but devices can share
> mmap_lock,
> + * therefore we need to zap and hold the vma_lock for each device, and only
> then
> + * get each memory_lock.
> + */
> +static int vfio_hot_res
On Thu, Jul 15, 2021 at 1:21 PM Kenneth Graunke wrote:
>
> On Thursday, July 15, 2021 4:27:44 AM PDT Tvrtko Ursulin wrote:
> >
> > On 15/07/2021 12:07, Daniel Vetter wrote:
> > > On Thu, Jul 15, 2021 at 11:33:10AM +0100, Tvrtko Ursulin wrote:
> > >>
> > >> On 15/07/2021 11:15, Matthew Auld wrote:
On Thu, Jul 15, 2021 at 06:58:31PM +0530, Kirti Wankhede wrote:
> > Review of all the drivers show that they are either already open coding
> > the first/last semantic or are buggy and missing it. All drivers are
> > migrated/fixed to the new open/close_device ops and the unused per-FD
> > open()/
From: Ville Syrjälä
We have the modeset lock dance hand rolled in quite a few places.
Use drm_modeset_lock_ctx_retry() and drm_modeset_lock_all_ctx_retry()
to simplify our lives.
Cc: Sean Paul
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c |
From: Ville Syrjälä
Extract intel_crtc_initial_commit() from intel_initial_commit().
Should make subsequent changes a bit less convoluted.
Cc: Sean Paul
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 96 +++-
1 file changed,
From: Ville Syrjälä
Layer drm_modeset_lock_all_ctx_retry() on top of
drm_modeset_lock_ctx_retry() to make the fairly common
"let's lock everything" pattern nicer.
Currently we have DRM_MODESET_LOCK_ALL_{BEGIN,END}() for this
but I don't really like it due to the magic gotos within,
which makes i
From: Ville Syrjälä
Quite a few places are hand rolling the modeset lock backoff dance.
Let's suck that into a helper macro that is easier to use without
forgetting some steps.
The main downside is probably that the implementation of
drm_with_modeset_lock_ctx() is a bit harder to read than a han
From: Ville Syrjälä
While staring at some DRM_MODESET_LOCK_ALL_{BEGIN,END}() conversions
I decided I don't really like what those macros do.
The main problems that I see:
- the magic goto inside limits their usefulness to baically
a single statement, unless you're willing to look inside and
On Thursday, July 15, 2021 4:27:44 AM PDT Tvrtko Ursulin wrote:
>
> On 15/07/2021 12:07, Daniel Vetter wrote:
> > On Thu, Jul 15, 2021 at 11:33:10AM +0100, Tvrtko Ursulin wrote:
> >>
> >> On 15/07/2021 11:15, Matthew Auld wrote:
> >>> From: Chris Wilson
> >>>
> >>> Jason Ekstrand requested a more
On 7/15/2021 5:50 AM, Jason Gunthorpe wrote:
Prologue:
This is the first series of three to send the "mlx5_vfio_pci" driver that has
been discussed on the list for a while now.
- Reorganize reflck to support splitting vfio_pci
- Split vfio_pci into vfio_pci/vfio_pci_core and provide infra
Replaced the boilerplate code for intel_display.c with
DRM_MODESET_LOCK_ALL macros per the TODO in gpu
(I apologize if I did something wrong, this is my first contribution of
hopefully many, so excited!!!)
Signed-off-by: Marco Kurzynski
---
drivers/gpu/drm/i915/display/intel_display.c | 14 ++--
On Wed, Jul 14, 2021 at 09:20:31PM -0300, Jason Gunthorpe wrote:
> From: Max Gurtovoy
>
> This pairs with vfio_init_group_dev() and allows undoing any state that is
> stored in the vfio_device unrelated to registration. Add appropriately
> placed calls to all the drivers.
>
> The following patch
> -Original Message-
> From: Roper, Matthew D
> Sent: Tuesday, July 13, 2021 8:15 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Roper, Matthew D ; Srivatsa, Anusha
>
> Subject: [PATCH v2 39/50] drm/i915/dg2: Don't read DRAM info
>
> DG2 does not use system DRAM information for BW_BUD
On Thu, Jul 15, 2021 at 06:49:05AM +0300, Leon Romanovsky wrote:
> On Wed, Jul 14, 2021 at 09:20:31PM -0300, Jason Gunthorpe wrote:
> > From: Max Gurtovoy
> >
> > This pairs with vfio_init_group_dev() and allows undoing any state that is
> > stored in the vfio_device unrelated to registration. Ad
tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next
head: ca06f93638362bf83584cdf33897822bf1578cf9
commit: 0eee9977f9d3d8f1e40175dada55b3d00121ac79 [29/30] drm/i915/gem: Roll all
of context creation together
config: x86_64-randconfig-s022-20210715 (attached as .config)
compiler
On Wed, 14 Jul 2021 at 13:28, Maarten Lankhorst
wrote:
>
> The FIXED mapping is only used for ttm, and tells userspace that the
> mapping type is pre-defined. This disables the other type of mmap
> offsets when discrete memory is used, so fix the selftests as well.
>
> Document the struct as well,
Am 13.07.21 um 15:59 schrieb Daniel Vetter:
Some vague evidences suggests this can go wrong. Try to prevent it by
holding the right mutex and clearing ->deferred_setup to make sure we
later on don't accidentally try to re-register the fbdev when the
driver thought it had it all cleaned up alrea
On Thu, Jul 15, 2021 at 10:22:37AM +0800, Zhenyu Wang wrote:
>
> Hi,
>
> Here's one fix of shadow ppgtt invalidation with proper vGPU D3 state
> tracking.
>
> Thanks
I only noticed this after sending this week's pull request.
I'm sorry about that.
It is now pulled and queued for next week.
S
Hi Dave and Daniel,
I was unsure about the -EDEADLK one based on Daniel's
comment on dri-devel, but Ville's response and the patch
looks reasonable to me. Also they are in sync with the
test cases. So if anything needs to still change on that
area I believe it can be a follow-up work.
Here goes d
On Wed, 14 Jul 2021 at 21:45, Jason Ekstrand wrote:
>
> We don't roll them together entirely because there are still a couple
> cases where we want a separate can_migrate check. For instance, the
> display code checks that you can migrate a buffer to LMEM before it
> accepts it in fb_create. The
On Thu, 15 Jul 2021 at 13:08, Maarten Lankhorst
wrote:
>
> I noticed when grepping for DOC: that those were defined
> in the header, but not actually used. Fix it by removing
> all chapters and the internal annotation, so the docbook
> generated chapters are used.
>
> Changes since v1:
> - Just re
Op 15-07-2021 om 12:15 schreef Matthew Auld:
> Add the missing kernel-doc.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> Cc: Maarten Lankhorst
> Cc: Tvrtko Ursulin
> Cc: Jordan Justen
> Cc: Kenneth Graunke
> Cc: Jason Ekstrand
> Cc: Daniel Vetter
> Cc: Ramalingam C
> ---
> incl
I noticed when grepping for DOC: that those were defined
in the header, but not actually used. Fix it by removing
all chapters and the internal annotation, so the docbook
generated chapters are used.
Changes since v1:
- Just remove the chapters, no need for those.
Signed-off-by: Maarten Lankhorst
On 15/07/2021 12:09, Matthew Auld wrote:
On Thu, 15 Jul 2021 at 11:33, Tvrtko Ursulin
wrote:
On 15/07/2021 11:15, Matthew Auld wrote:
From: Chris Wilson
Jason Ekstrand requested a more efficient method than userptr+set-domain
to determine if the userptr object was backed by a complete set
On 15/07/2021 12:07, Daniel Vetter wrote:
On Thu, Jul 15, 2021 at 11:33:10AM +0100, Tvrtko Ursulin wrote:
On 15/07/2021 11:15, Matthew Auld wrote:
From: Chris Wilson
Jason Ekstrand requested a more efficient method than userptr+set-domain
to determine if the userptr object was backed by a c
Hi Hsin-Yi,
Thank you for the patch.
Missatge de Hsin-Yi Wang del dia dj., 27 de maig
2021 a les 9:42:
>
> krane, kakadu, and kodama boards have a default panel rotation.
>
> Signed-off-by: Hsin-Yi Wang
It looks good to me, so
Reviewed-by: Enric Balletbo i Serra
and, on a Lenovo IdeaPad Due
On Thu, 15 Jul 2021 at 11:33, Tvrtko Ursulin
wrote:
>
>
> On 15/07/2021 11:15, Matthew Auld wrote:
> > From: Chris Wilson
> >
> > Jason Ekstrand requested a more efficient method than userptr+set-domain
> > to determine if the userptr object was backed by a complete set of pages
> > upon creation
Hi Hsin-Yi,
Thank you for your patch.
Missatge de Hsin-Yi Wang del dia dj., 24 de juny
2021 a les 12:55:
>
> Init panel orientation property after connector is initialized. Let the
> panel driver decides the orientation value later.
>
> Signed-off-by: Hsin-Yi Wang
> Acked-by: Chun-Kuang Hu
Te
On Thu, Jul 15, 2021 at 11:33:10AM +0100, Tvrtko Ursulin wrote:
>
> On 15/07/2021 11:15, Matthew Auld wrote:
> > From: Chris Wilson
> >
> > Jason Ekstrand requested a more efficient method than userptr+set-domain
> > to determine if the userptr object was backed by a complete set of pages
> > up
On 15/07/2021 11:15, Matthew Auld wrote:
From: Chris Wilson
Jason Ekstrand requested a more efficient method than userptr+set-domain
to determine if the userptr object was backed by a complete set of pages
upon creation. To be more efficient than simply populating the userptr
using get_user_pa
On Wed, Jul 14, 2021 at 06:12:54PM -0400, Andrey Grodzovsky wrote:
>
> On 2021-07-13 12:45 p.m., Daniel Vetter wrote:
> > On Tue, Jul 13, 2021 at 6:11 PM Andrey Grodzovsky
> > wrote:
> > > On 2021-07-13 5:10 a.m., Daniel Vetter wrote:
> > > > On Tue, Jul 13, 2021 at 9:25 AM Christian König
> > >
The CPU domain should be static for discrete, and on DG1 we don't need
any flushing since everything is already coherent, so really all this
does is an object wait, for which we have an ioctl. Longer term the
desired caching should be an immutable creation time property for the
BO, which can be set
From: Chris Wilson
Jason Ekstrand requested a more efficient method than userptr+set-domain
to determine if the userptr object was backed by a complete set of pages
upon creation. To be more efficient than simply populating the userptr
using get_user_pages() (as done by the call to set-domain or
Add the missing kernel-doc.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Maarten Lankhorst
Cc: Tvrtko Ursulin
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Daniel Vetter
Cc: Ramalingam C
---
include/uapi/drm/i915_drm.h | 40 -
1
It's a noop on DG1, and in the future when need to support other devices
which let us control the coherency, then it should be an immutable
creation time property for the BO. This will likely be controlled
through a new gem_create_ext extension.
v2: add some kernel doc for the discrete changes, an
Test-with: 20210715100932.2605648-1-matthew.a...@intel.com
Chris Wilson (1):
drm/i915/userptr: Probe existence of backing struct pages upon
creation
Matthew Auld (3):
drm/i915/uapi: reject caching ioctls for discrete
drm/i915/uapi: convert drm_i915_gem_userptr to kernel doc
drm/i915/u
From: Chris Wilson
Exercise new API to probe that the userptr range is valid (backed by
struct pages and not pfn).
v2: remove POPULATE for now
Signed-off-by: Chris Wilson
Signed-off-by: Matthew Auld
Cc: Maarten Lankhorst
Cc: Daniel Vetter
---
tests/i915/gem_userptr_blits.c | 86 +++
Hi Hsin-Yi,
Thank you for your patch.
Missatge de Hsin-Yi Wang del dia dj., 24 de juny
2021 a les 12:55:
>
> drm_dev_register() sets connector->registration_state to
> DRM_CONNECTOR_REGISTERED and dev->registered to true. If
> drm_connector_set_panel_orientation() is first called after
> drm_dev
On 24/06/2021 08:05, Matthew Brost wrote:
Reset implementation for new GuC interface. This is the legacy reset
implementation which is called when the i915 owns the engine hang check.
Future patches will offload the engine hang check to GuC but we will
continue to maintain this legacy path as a
From: Ville Syrjälä
intel_prepare_shared_dpll() is now useless, so get rid of it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 3 --
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 28 ---
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 11 -
From: Ville Syrjälä
Move the FP divider programming into ibx_pch_dpll_enable(). No reason
that I can see why these would have to be programmed this early.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 13 +++--
1 file changed, 3 insertions(+), 10 dele
From: Ville Syrjälä
Can't think of a good reason why we'd need to program the FP
dividers so early. Let's just do it when programming the rest
of the DPLL.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 13 -
drivers/gpu/drm/i915/display/intel_dpll.
From: Ville Syrjälä
Use ilk_needs_fb_cb_tune() for reduced_clock instead of hand rolling
it. Also ilk_needs_fb_cb_tune() can just use the precomputed M value
instead of calculating it again.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpll.c | 4 ++--
1 file changed, 2
From: Ville Syrjälä
We always call the vlv/chv prepare_pll() just before enable_pll().
Move the calls into the enable_pll() funcs. We can also
consolidate the DPLL_VCO_ENABLE checks while at it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +-
drivers/gpu
From: Ville Syrjälä
On g4x and pch the DPLL has two P1 dividers (for refresh rate
switching). Program the FPx1 P1 divider consistently to the reduced
clock P1 divider if available, otherwise just program it to the
same value as the FPx0 P1 divider.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/
From: Ville Syrjälä
Get rid of the local 'reg' variable for the DPLL control register
in i9xx_enable_pll(). We have other registers in there too so this
is just making things more confusing.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpll.c | 18 +-
1 f
From: Ville Syrjälä
s/pipe_config/crtc_state/ in the DPLL code.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpll.c | 151 +++---
1 file changed, 76 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll.c
b/drivers/gpu/drm/
From: Ville Syrjälä
The current gen2 DPLL readout code:
* assumes i845/i865 have LVDS which is not true
* assumes only pipe B can drive LVDS (true, but makes
the code appear a bit magical)
* hard to parse in general
Clean it up by checking for i85x (the only gen2 platform
with LVDS) and reusin
From: Ville Syrjälä
Stop passing both the crtc and its state to the DPLL functions.
The state alone is enough.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 12 +-
drivers/gpu/drm/i915/display/intel_dpll.c| 142 +--
drivers/gpu/drm/i915/di
From: Ville Syrjälä
Lots of places don't need to modify the DPLL params, so make
them const.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 5 --
drivers/gpu/drm/i915/display/intel_dpll.c | 58 +++
drivers/gpu/drm/i915/display/intel_dpll.h
From: Ville Syrjälä
Make the PCH dpll code match the gmch code by splitting
the FP register handling out from ilk_compute_dpll().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpll.c | 25 +++
1 file changed, 17 insertions(+), 8 deletions(-)
diff --gi
From: Ville Syrjälä
When we enable the DPLL for the PPS kick, let's tell the DPLL code
we're dealing with an eDP output. This shouldn't really matter, but
it's more consistent with the way the DPLL is configured when we're
actually enabling the eDP port for real.
Signed-off-by: Ville Syrjälä
--
From: Ville Syrjälä
A bunch of cleanups to the DPLL code.
Ville Syrjälä (13):
drm/i915: Set output_types to EDP for vlv/chv DPLL forcing
drm/i915: Clean up gen2 DPLL readout
drm/i915: Extract ilk_update_pll_dividers()
drm/i915: Constify struct dpll all over
drm/i915: Clean dpll calling
From: Tvrtko Ursulin
Convert fdinfo format to one documented in drm-usage-stats.rst.
Opens:
* Does it work for AMD?
* What are the semantics of AMD engine utilisation reported in percents?
Can it align with what i915 does or needs to document the alternative
in the specification document
From: Tvrtko Ursulin
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.
Example of the output:
pos:0
flags: 012
mnt_id: 21
drm-driver:
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
From: Tvrtko Ursulin
Proposal to standardise the fdinfo text format as optionally output by DRM
drivers.
Idea is that a simple but, well defined, spec will enable generic
userspace tools to be written while at the same time avoiding a more heavy
handed approach of adding a mid-layer to DRM.
i91
From: Tvrtko Ursulin
Track context active (on hardware) status together with the start
timestamp.
This will be used to provide better granularity of context
runtime reporting in conjunction with already tracked pphwsp accumulated
runtime.
The latter is only updated on context save so does not g
From: Tvrtko Ursulin
Make GEM contexts keep a reference to i915_drm_client for the whole of
of their lifetime which will come handy in following patches.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish constructing ctx before adding it to the list
v4 (Ram)
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/
consolidating between multi
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamse
From: Tvrtko Ursulin
Same old work but now rebased and series ending with some DRM docs proposing
the common specification which should enable nice common userspace tools to be
written.
For the moment I only have intel_gpu_top converted to use this and that seems to
work okay.
v2:
* Added prot
On Wed, 14 Jul 2021 20:18:57 +0200
Werner Sembach wrote:
> Am 01.07.21 um 13:30 schrieb Werner Sembach:
> > Am 01.07.21 um 09:42 schrieb Pekka Paalanen:
> >> On Wed, 30 Jun 2021 11:42:10 +0200
> >> Werner Sembach wrote:
> >>
> >>> Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
> On Tue,
Hi Dave and Daniel,
here's the PR for drm-misc-fixes. I merged drm-misc-next-fixes into
it to pick up patches that were left over from the previous release
cycle. The vmwgfx change comes from that. The other patches fix
current errors.
Best regards
Thomas
drm-misc-fixes-2021-07-15:
Short summary
83 matches
Mail list logo
