For the vmwgfx part:
Acked-by: Thomas Hellstrom
On 11/05/2016 08:33 AM, Eric Engestrom wrote:
> Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
>
> drm: make drm_get_format_name thread-safe
>
> Signed-off-by: Eric Engestrom
> [danvet: Clarify that the returned pointer must be freed
== Series Details ==
Series: drm: move allocation out of drm_get_format_name()
URL : https://patchwork.freedesktop.org/series/14873/
State : success
== Summary ==
Series 14873v1 drm: move allocation out of drm_get_format_name()
https://patchwork.freedesktop.org/api/1.0/series/14873/revisions/1
Fixes: 90844f00049e9f42573fd31d7c32e8fd31d3fd07
drm: make drm_get_format_name thread-safe
Signed-off-by: Eric Engestrom
[danvet: Clarify that the returned pointer must be freed with
kfree().]
Signed-off-by: Daniel Vetter
Suggested-by: Ville Syrjälä
Signed-off-by: Eric Enge
On Sat, 2016-11-05 at 00:32 +0200, Imre Deak wrote:
> On Fri, 2016-11-04 at 21:01 +, Chris Wilson wrote:
> > On Fri, Nov 04, 2016 at 10:33:24PM +0200, Imre Deak wrote:
> > > On Thu, 2016-11-03 at 21:14 +, Chris Wilson wrote:
> > > > Where is that guaranteed? I thought we only serialised wit
On Fri, 2016-11-04 at 21:01 +, Chris Wilson wrote:
> On Fri, Nov 04, 2016 at 10:33:24PM +0200, Imre Deak wrote:
> > On Thu, 2016-11-03 at 21:14 +, Chris Wilson wrote:
> > > Where is that guaranteed? I thought we only serialised with the
> > > pm
> > > interrupts. Remember this happens befor
The hope of this RFC is to gather some high-level feedback and ideas,
since I couldn't really find any in-depth discussions on the mailing
list regarding gemfs, only the odd whisper. But after talking with
Joonas and grepping around, the parts of shmem fs we would initially
need to have for a drop
== Series Details ==
Series: drm/dp: Make space for null terminator in the DP device ID char array
URL : https://patchwork.freedesktop.org/series/14865/
State : failure
== Summary ==
Series 14865v1 drm/dp: Make space for null terminator in the DP device ID char
array
https://patchwork.freedes
On Fri, Nov 04, 2016 at 11:07:26PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 04, 2016 at 08:48:21PM +, Chris Wilson wrote:
> > On Tue, Oct 25, 2016 at 06:58:02PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Due to the plane->index not getting readjust
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Make sure engines are idle
during GPU idling in LR mode (rev2)
URL : https://patchwork.freedesktop.org/series/14864/
State : warning
== Summary ==
Series 14864v2 Series without cover letter
https://patchwork.freedesktop.org/
On Fri, Nov 04, 2016 at 08:48:21PM +, Chris Wilson wrote:
> On Tue, Oct 25, 2016 at 06:58:02PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Due to the plane->index not getting readjusted in drm_plane_cleanup(),
> > we can't continue initialization of some plane/
The DP device identification string read from the DPCD registers is 6
characters long at max. and we store it in a char array of the same length
without space for the NULL terminator. Fix this by increasing the array
size to 7 and initialize it to an empty string.
Signed-off-by: Dhinakaran Pandiya
On Fri, Nov 04, 2016 at 10:58:52PM +0200, Imre Deak wrote:
> During resume we will reset the SW/HW tracking for each ring head/tail
> pointers and so are not prepared to replay any pending requests (as
> opposed to GPU reset time). Add an assert for this both to the suspend
> and the resume code.
>
On Fri, Nov 04, 2016 at 10:33:24PM +0200, Imre Deak wrote:
> On Thu, 2016-11-03 at 21:14 +, Chris Wilson wrote:
> > Where is that guaranteed? I thought we only serialised with the pm
> > interrupts. Remember this happens before rpm suspend, since
> > gem_idle_work_handler is responsible for dro
During resume we will reset the SW/HW tracking for each ring head/tail
pointers and so are not prepared to replay any pending requests (as
opposed to GPU reset time). Add an assert for this both to the suspend
and the resume code.
v2:
- Check for ELSP port idle already during suspend and check !gt
On Tue, Oct 25, 2016 at 06:58:02PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Due to the plane->index not getting readjusted in drm_plane_cleanup(),
> we can't continue initialization of some plane/crtc init fails.
> Well, we sort of could I suppose if we left all initi
During resume we will reset the SW/HW tracking for each ring head/tail
pointers and so are not prepared to replay any pending requests (as
opposed to GPU reset time). Add an assert for this both to the suspend
and the resume code.
v2:
- Check for ELSP port idle already during suspend and check !gt
We assume that the GPU is idle once receiving the seqno via the last
request's user interrupt. In execlist mode the corresponding context
completed interrupt can be delayed though and until this latter
interrupt arrives we consider the request to be pending on the ELSP
submit port. This can cause a
On Thu, 2016-11-03 at 21:14 +, Chris Wilson wrote:
> On Thu, Nov 03, 2016 at 10:57:23PM +0200, Imre Deak wrote:
> > On Thu, 2016-11-03 at 18:59 +, Chris Wilson wrote:
> > > On Thu, Nov 03, 2016 at 06:19:37PM +0200, Imre Deak wrote:
> > > > We assume that the GPU is idle once receiving the s
On Fri, Nov 04, 2016 at 08:03:57PM +, Chris Wilson wrote:
> Flushing the cachelines for an object is slow, can be as much as 100ms
> for a large framebuffer. We currently do this under the struct_mutex BKL
> on execution or on pageflip. But now with the ability to add fences to
> obj->resv for
Flushing the cachelines for an object is slow, can be as much as 100ms
for a large framebuffer. We currently do this under the struct_mutex BKL
on execution or on pageflip. But now with the ability to add fences to
obj->resv for both flips and execbuf (and we naturally wait on the fence
before CPU
Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu:
> From: Mahesh Kumar
>
> This patch implements new DDB allocation algorithm as per HW team
> recommendation. This algo takecare of scenario where we allocate less
> DDB
> for the planes with lower relative pixel rate, but they require mor
Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu:
> From: Mahesh Kumar
>
> This patch adds IPC support for platforms. This patch enables IPC
> only for BXT/KBL platform as for SKL recommendation is to keep is
> disabled.
> IPC (Isochronous Priority Control) is the hardware feature, which
Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu:
> From: Mahesh Kumar
>
> This patch changes Watermak calculation to fixed point calculation.
> Problem with current calculation is during plane_blocks_per_line
> calculation we divide intermediate blocks with min_scanlines and
> takes flo
On Fri, 2016-11-04 at 17:48 +0200, Jani Nikula wrote:
> On Wed, 26 Oct 2016, Dhinakaran Pandiyan
> wrote:
> > Enabling DP audio stall fix is necessary to play audio over DP HBR2. So,
> > let's set this bit right before enabling the audio codec. Playing audio
> > without setting this bit results i
== Series Details ==
Series: drm/i915: Remove the vma from the object list upon close
URL : https://patchwork.freedesktop.org/series/14850/
State : failure
== Summary ==
Series 14850v1 drm/i915: Remove the vma from the object list upon close
https://patchwork.freedesktop.org/api/1.0/series/148
Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu:
> From: Mahesh Kumar
>
> This patch adds variable to check for X_tiled & y_tiled planes,
> instead
> of always checking against framebuffer-modifiers.
>
> Changes:
> - Created separate patch as per Paulo's comment
> - Added x_tiled var
Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu:
> From: Mahesh Kumar
>
> Current code clears only plane ddb allocation if total ddb allocated
> to
> pipe in zero. y_plane ddb still contains old value, clear that as
> well.
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915
On Fri, Nov 04, 2016 at 03:09:04PM -0200, Paulo Zanoni wrote:
> Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu:
> > This patch implemnets Workariunds related to display arbitrated
> > memory
> > bandwidth. These WA are applicabe for all gen-9 based platforms.
> >
> > Changes since v1:
>
== Series Details ==
Series: series starting with [1/2] shmem: Support for registration of
driver/file owner specific ops
URL : https://patchwork.freedesktop.org/series/14845/
State : success
== Summary ==
Series 14845v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/se
Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu:
> This patch implemnets Workariunds related to display arbitrated
> memory
> bandwidth. These WA are applicabe for all gen-9 based platforms.
>
> Changes since v1:
> - Rebase on top of Paulo's patch series
> Changes since v2:
> - Rebase/
On Sat, Nov 05, 2016 at 03:55:03AM +1100, Stephen Rothwell wrote:
> Hi Liviu,
>
> On Fri, 4 Nov 2016 15:48:02 + Liviu Dudau wrote:
> >
> > Brian Starkey is a co-maintainer for the Mali DP tree, so his Signed-off-by
> > alone should be good. Baoyou's patch is in my tree to stop him repeatedly
Hi Liviu,
On Fri, 4 Nov 2016 15:48:02 + Liviu Dudau wrote:
>
> Brian Starkey is a co-maintainer for the Mali DP tree, so his Signed-off-by
> alone should be good. Baoyou's patch is in my tree to stop him repeatedly
> send me the same patch over and over again :) But yes, I will add my
> Signe
On Fri, Nov 04, 2016 at 04:03:55PM +, Tvrtko Ursulin wrote:
>
> On 04/11/2016 15:32, Ville Syrjälä wrote:
> > On Fri, Nov 04, 2016 at 02:42:45PM +, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin
> >>
> >> A small selection of macros which can only accept dev_priv from
> >> now on and a r
Currently, the vma is being unlink from the object lookup on destroy.
However, we are meant to be decoupling it upon close so that the user
cannot access the closed vma whilst it remains active on the GPU.
[ 34.074858] kernel BUG at drivers/gpu/drm/i915/i915_gem_gtt.c:3561!
[ 34.074875] invali
On 04/11/2016 15:32, Ville Syrjälä wrote:
On Fri, Nov 04, 2016 at 02:42:45PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
A small selection of macros which can only accept dev_priv from
now on and a resulting trickle of fixups.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i9
On Wed, 26 Oct 2016, Dhinakaran Pandiyan wrote:
> Enabling DP audio stall fix is necessary to play audio over DP HBR2. So,
> let's set this bit right before enabling the audio codec. Playing audio
> without setting this bit results in pipe FIFO underruns.
>
> This workaround is applicable only for
On Fri, Nov 04, 2016 at 04:38:54PM +1100, Stephen Rothwell wrote:
> Hi Liviu,
>
> On Thu, 3 Nov 2016 17:19:58 + Liviu Dudau wrote:
> >
> > I have revamped the mali-dp tree and rebased it on the newer
> > version of drm-next (which includes the drm-misc change) and pushed the
> > updated patch
On Wed, 02 Nov 2016, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v4,1/2] drm/i915/dp: BDW cdclk fix for DP audio
> (rev2)
> URL : https://patchwork.freedesktop.org/series/14688/
> State : warning
>
> == Summary ==
>
> Series 14688v2 Series without cover letter
> ht
== Series Details ==
Series: dev_priv cleanup continuation
URL : https://patchwork.freedesktop.org/series/14844/
State : failure
== Summary ==
Series 14844v1 dev_priv cleanup continuation
https://patchwork.freedesktop.org/api/1.0/series/14844/revisions/1/mbox/
Test kms_busy:
Subgroup
On Fri, Nov 04, 2016 at 02:42:45PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> A small selection of macros which can only accept dev_priv from
> now on and a resulting trickle of fixups.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_drv.h | 27 ++
We'll change the name at some point, add some indirection, with a
generic variable name.
Signed-off-by: Jani Nikula
---
dim | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/dim b/dim
index 8e95cd82407f..6a23c868856c 100755
--- a/dim
+++ b/dim
@@ -9
NOTE: This change depends on nightly.conf changes that have been
committed earlier to the drm-intel-rerere repo. Looking at that first
makes this change more sensible.
Use two arrays to configure the repos and branches to be merged to the
integration branch:
drm_tip_repos
An associative
On Fri, Nov 04, 2016 at 02:44:44PM +, Tvrtko Ursulin wrote:
>
> On 03/11/2016 11:55, Chris Wilson wrote:
> >On Thu, Nov 03, 2016 at 11:03:47AM +, Tvrtko Ursulin wrote:
> >>
> >>On 02/11/2016 17:50, Chris Wilson wrote:
> >>>+struct i915_dependency {
> >>>+ struct i915_priotree *signal;
> >
Recently a patch ran successfully through BAT that broke 64bit
relocations on a couple of machines. Oops. So lets add a very fast set
of tests to check basic relocation handling.
Signed-off-by: Chris Wilson
---
tests/gem_exec_reloc.c| 199 ++
tests
From: Tvrtko Ursulin
A few small patches towards the goal of getting rid of the
__I915__ polymorphism.
Series starts with three patches to convert some more IS/HAS macros to accepting
dev_priv only, and continues with a patch to make all users of INTEL_INFO pass
in dev_priv, apart from the ones
From: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 35940192e569..096c368bda0b 100644
--- a/drivers/gpu/d
From: Chris Wilson
This provides support for the drivers or shmem file owners to register
a set of callbacks, which can be invoked from the address space
operations methods implemented by shmem. This allow the file owners to
hook into the shmem address space operations to do some extra/custom
op
On 03/11/2016 11:55, Chris Wilson wrote:
On Thu, Nov 03, 2016 at 11:03:47AM +, Tvrtko Ursulin wrote:
On 02/11/2016 17:50, Chris Wilson wrote:
The scheduler needs to know the dependencies of each request for the
lifetime of the request, as it may choose to reschedule the requests at
any ti
From: Chris Wilson
On a long run of more than 2-3 days, physical memory tends to get
fragmented severely, which considerably slows down the system. In such a
scenario, the shrinker is also unable to help as lack of memory is not
the actual problem, since it has been observed that there are enough
From: Tvrtko Ursulin
After this patch only conversion of INTEL_INFO(p)->gen to
INTEL_GEN(dev_priv) remains before the __I915__ macro can
be removed.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.c | 4 ++--
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
drivers/gpu/drm/i
From: Tvrtko Ursulin
A small selection of macros which can only accept dev_priv from
now on and a resulting trickle of fixups.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 27 ---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/dr
From: Tvrtko Ursulin
A small selection of macros which can only accept dev_priv from
now on and a resulting trickle of fixups.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h| 12 ++--
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i91
From: Tvrtko Ursulin
A small selection of macros which can only accept dev_priv from
now on and a resulting trickle of fixups.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h| 31 --
drivers/gpu/drm/i915/i915_gem.c| 13 +
On Fri, 04 Nov 2016, Chris Wilson wrote:
> On Fri, Nov 04, 2016 at 12:59:08PM +, Tvrtko Ursulin wrote:
>>
>> On 04/11/2016 11:08, Chris Wilson wrote:
>> >Valleyview and Cherryview are definitely limited to only scanning out
>> >from the first 256MiB and 512MiB of the Global GTT respectively.
On 11/4/2016 7:07 PM, Chris Wilson wrote:
Best if we send these as a new series to unconfuse CI.
Okay will send as a new series.
On Fri, Nov 04, 2016 at 06:18:26PM +0530, akash.g...@intel.com wrote:
+static int do_migrate_page(struct drm_i915_gem_object *obj)
+{
+ struct drm_i915_pri
Best if we send these as a new series to unconfuse CI.
On Fri, Nov 04, 2016 at 06:18:26PM +0530, akash.g...@intel.com wrote:
> +static int do_migrate_page(struct drm_i915_gem_object *obj)
> +{
> + struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> + int ret = 0;
> +
> + if (
== Series Details ==
Series: series starting with [1/2] shmem: Support for registration of
driver/file owner specific ops (rev4)
URL : https://patchwork.freedesktop.org/series/4780/
State : failure
== Summary ==
drivers/gpu/drm/i915/i915_drv.h: At top level:
drivers/gpu/drm/i915/i915_drv.h:58
On Fri, Nov 4, 2016 at 8:59 AM, sourab gupta wrote:
> On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> > Adds base i915 perf infrastructure for Gen performance metrics.
> >
> > This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> > properties to configure a stream of
On Fri, Nov 04, 2016 at 12:59:08PM +, Tvrtko Ursulin wrote:
>
> On 04/11/2016 11:08, Chris Wilson wrote:
> >Valleyview and Cherryview are definitely limited to only scanning out
> >from the first 256MiB and 512MiB of the Global GTT respectively. Lets
> >presume that this behaviour was inherite
On 04/11/2016 11:08, Chris Wilson wrote:
Valleyview and Cherryview are definitely limited to only scanning out
from the first 256MiB and 512MiB of the Global GTT respectively. Lets
presume that this behaviour was inherited from the display block copied
from g4x (not Ironlake) and all earlier gen
From: Chris Wilson
On a long run of more than 2-3 days, physical memory tends to get
fragmented severely, which considerably slows down the system. In such a
scenario, the shrinker is also unable to help as lack of memory is not
the actual problem, since it has been observed that there are enough
From: Chris Wilson
This provides support for the drivers or shmem file owners to register
a set of callbacks, which can be invoked from the address space
operations methods implemented by shmem. This allow the file owners to
hook into the shmem address space operations to do some extra/custom
op
On Fri, Nov 04, 2016 at 01:43:34PM +0200, Joonas Lahtinen wrote:
> On pe, 2016-11-04 at 10:30 +, Chris Wilson wrote:
> > @@ -3711,6 +3711,13 @@ i915_get_ggtt_vma_pages(struct i915_vma *vma)
> > {
> > int ret = 0;
> >
> > + /* The vma->pages are only valid within the lifespan of the bor
== Series Details ==
Series: drm/i915: Limit Valleyview and earlier to only using mappable scanout
URL : https://patchwork.freedesktop.org/series/14835/
State : success
== Summary ==
Series 14835v1 drm/i915: Limit Valleyview and earlier to only using mappable
scanout
https://patchwork.freedes
On pe, 2016-11-04 at 10:30 +, Chris Wilson wrote:
> @@ -3711,6 +3711,13 @@ i915_get_ggtt_vma_pages(struct i915_vma *vma)
> {
> int ret = 0;
>
> + /* The vma->pages are only valid within the lifespan of the borrowed
> + * obj->mm.pages. When the obj->mm.pages sg_table is regene
On Fri, Nov 04, 2016 at 01:29:04PM +0200, Jani Nikula wrote:
> On Fri, 04 Nov 2016, Chris Wilson wrote:
> > Valleyview and Cherryview are definitely limited to only scanning out
> > from the first 256MiB and 512MiB of the Global GTT respectively. Lets
> > presume that this behaviour was inherited
On pe, 2016-11-04 at 10:29 +, Chris Wilson wrote:
> ---
> drivers/dma-buf/reservation.c | 58
> +++
> include/linux/reservation.h | 4 +++
> 2 files changed, 62 insertions(+)
Wrong branch.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology
On Fri, 04 Nov 2016, Chris Wilson wrote:
> Valleyview and Cherryview are definitely limited to only scanning out
> from the first 256MiB and 512MiB of the Global GTT respectively. Lets
> presume that this behaviour was inherited from the display block copied
> from g4x (not Ironlake) and all earli
== Series Details ==
Series: drm/i915: Fix pages pin counting around swizzle quirk (rev3)
URL : https://patchwork.freedesktop.org/series/14720/
State : success
== Summary ==
Series 14720v3 drm/i915: Fix pages pin counting around swizzle quirk
https://patchwork.freedesktop.org/api/1.0/series/14
Valleyview and Cherryview are definitely limited to only scanning out
from the first 256MiB and 512MiB of the Global GTT respectively. Lets
presume that this behaviour was inherited from the display block copied
from g4x (not Ironlake) and all earlier generations are similarly
affected. For simplic
commit bc0629a76726 ("drm/i915: Track pages pinned due to swizzling
quirk") fixed one problem, but revealed a whole lot more. The root cause
of the pin count mismatch for the swizzle quirk (for L-shaped memory on
gen3/4) was that we were incrementing the pages_pin_count upon getting
the backing pag
---
drivers/dma-buf/reservation.c | 58 +++
include/linux/reservation.h | 4 +++
2 files changed, 62 insertions(+)
diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index 3c9ab53be2b9..0f254d0d9bec 100644
--- a/drivers/dma-buf/re
On Fri, Nov 04, 2016 at 09:36:31AM +, Chris Wilson wrote:
> On Fri, Nov 04, 2016 at 10:50:44AM +0200, Joonas Lahtinen wrote:
> > On ke, 2016-11-02 at 09:43 +, Chris Wilson wrote:
> > > @@ -2458,17 +2459,16 @@ int __i915_gem_object_get_pages(struct
> > > drm_i915_gem_object *obj)
> > > if
> == Series Details ==
>
> Series: drm/i915/dp: Update connector status for DP MST hotplugs (rev2)
> URL : https://patchwork.freedesktop.org/series/14821/
> State : warning
>
> == Summary ==
>
> Series 14821v2 drm/i915/dp: Update connector status for DP MST hotplugs
> https://patchwork.freedes
On Fri, Nov 04, 2016 at 03:00:37PM +0530, sourab.gu...@intel.com wrote:
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index ead97b7f4..15921c7 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -832,6 +832,11 @@ struct drm_i915_gem_execb
Patchwork writes:
> == Series Details ==
>
> Series: drm/i915: Move hangcheck code out from i915_irq.c
> URL : https://patchwork.freedesktop.org/series/14685/
> State : warning
>
> == Summary ==
>
> Series 14685v1 drm/i915: Move hangcheck code out from i915_irq.c
> https://patchwork.freedesktop
On Fri, Nov 04, 2016 at 03:00:35PM +0530, sourab.gu...@intel.com wrote:
> +static u32 gen8_oa_buffer_get_ctx_id(struct i915_perf_stream *stream,
> + const u8 *report)
> +{
> + struct drm_i915_private *dev_priv = stream->dev_priv;
> +
> + /* The ctx ID present
On Fri, Nov 04, 2016 at 03:00:43PM +0530, sourab.gu...@intel.com wrote:
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 06c7b55..0dc2384 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1088,6 +1088,8 @@ static int
On Fri, Nov 04, 2016 at 10:50:44AM +0200, Joonas Lahtinen wrote:
> On ke, 2016-11-02 at 09:43 +, Chris Wilson wrote:
> > @@ -2458,17 +2459,16 @@ int __i915_gem_object_get_pages(struct
> > drm_i915_gem_object *obj)
> > if (err)
> > return err;
> >
> > - if (likely(obj->mm.pa
From: Sourab Gupta
The OA reports contain the least significant 32 bits of the gpu timestamp.
This patch enables retrieval of the timestamp field from OA reports, to
forward as 64 bit raw gpu timestamps in the perf samples.
Signed-off-by: Sourab Gupta
---
drivers/gpu/drm/i915/i915_drv.h | 1
From: Sourab Gupta
This patch adds support for opening multiple concurrent perf streams for
different gpu engines, while having the restriction to open only a single
stream open for a particular gpu engine.
This enables userspace client to open multiple streams, one per engine,
at any time to cap
From: Sourab Gupta
For the drivers to be able to use the cross timestamp framework,
they need the information of current clocksource being used by the
kernel timekeeping. This is needed since the callback given by driver
into the get_device_system_crosststamp(), in order to synchronously read
the
From: Sourab Gupta
Currently, we have the ability to only forward the GPU timestamps in the
samples (which are generated via OA reports or PIPE_CONTROL commands
inserted in the ring). This limits the ability to correlate these samples
with the system events. If we scale the GPU timestamps accordi
From: Sourab Gupta
Refloating the series rebased on Robert's latest patchset. Since Robert's
patches are being reviewed and this patch series extends his framework to
enable multiple concurrent streams to capture command stream based metrics,
it would be good to keep this work in perspective.
Loo
From: Sourab Gupta
This patch introduces flags and adds support for having pid output with
the OA reports generated through the RCS commands.
When the stream is opened with pid sample type, the pid information is also
captured through the command stream samples and forwarded along with the
OA re
From: Sourab Gupta
This patch adds support for capturing MMIO register values through
i915 perf interface.
The userspace can request upto 8 MMIO register values to be dumped.
The addresses of these registers can be passed through the corresponding
property 'value' field while opening the stream.
From: Sourab Gupta
Add a compile time option for detecting the overflow condition of command
stream buffer, and not overwriting the old entries in such a case.
Also, set a status flag to forward the overflow condition to userspace if
overflow is detected.
Signed-off-by: Sourab Gupta
---
driver
From: Sourab Gupta
Exporting clocks_calc_mult_shift is helpful for drivers to calculate
the mult/shift values for their clocks, given their frequency.
This is particularly useful when such drivers may want to associate
timecounter/cyclecounter abstraction for their clock sources, in order
to use
From: Sourab Gupta
This patch exposes a new sample source field to userspace. This field can
be populated to specify the origin of the OA report.
For e.g. for internally triggerred reports (non MI_RPC reports), the RPT_ID
field has bitfields for specifying the origin such as timer, or render ctx
From: Sourab Gupta
When there are no pending CS OA samples, flush the periodic OA samples
collected so far.
We can safely forward the periodic OA samples in the case we
have no pending CS samples, but we can't do so in the case we have
pending CS samples, since we don't know what the ordering be
From: Sourab Gupta
This patch adds a new ctx getparam ioctl parameter, which can be used to
retrieve ctx unique id by userspace.
This can be used by userspace to map the i915 perf samples with their
particular ctx's, since those would be having ctx unique id's.
Otherwise the userspace has no way
From: Sourab Gupta
This adds support for populating the ctx id for the periodic OA reports
when requested through the corresponding property.
For Gen8, the OA reports itself have the ctx ID and it is the one programmed
into HW while submitting workloads. Thus it's retrieved from reports itself.
From: Sourab Gupta
This patch extends the i915 perf framework to handle the perf sample
collection for any given gpu engine. Particularly, the support
for collecting timestamp sample type is added, which can be requested for
any engine.
With this, for RCS, timestamps and OA reports can be collec
From: Sourab Gupta
This patch enables userspace to specify tags (per workload), provided via
execbuffer ioctl, which could be added to OA reports, to help associate
reports with the corresponding workloads.
There may be multiple stages within a single context, from a userspace
perspective. An ab
From: Sourab Gupta
This patch introduces a framework to enable OA counter reports associated
with Render command stream. We can then associate the reports captured
through this mechanism with their corresponding context id's. This can be
further extended to associate any other metadata informatio
On Thu, Nov 03, 2016 at 07:47:39PM +, Chris Wilson wrote:
> On Thu, Nov 03, 2016 at 04:21:25PM +, Tvrtko Ursulin wrote:
> > >+static void update_priorities(struct i915_priotree *pt, int prio)
> > >+{
> > >+ struct drm_i915_gem_request *request =
> > >+ container_of(pt, struct drm_
On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> Being able to program OACONTROL from a non-privileged batch buffer is
> not sufficient to be able to configure the OA unit. This was originally
> allowed to help enable Mesa to expose OA counters via the
> INTEL_performance_query extension, b
On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> Consistent with the kernel.perf_event_paranoid sysctl option that can
> allow non-root users to access system wide cpu metrics, this can
> optionally allow non-root users to access system wide OA counter metrics
> from Gen graphics hardware.
On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> Each metric set is given a sysfs entry like:
>
> /sys/class/drm/card0/metrics//id
>
> This allows userspace to enumerate the specific sets that are available
> for the current system. The 'id' file contains an unsigned integer that
> can be
On Thu, 2016-10-27 at 19:14 -0700, Robert Bragg wrote:
> Adds base i915 perf infrastructure for Gen performance metrics.
>
> This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> properties to configure a stream of metrics and returns a new fd usable
> with standard VFS system
1 - 100 of 103 matches
Mail list logo
