Best Regards,
Libin
On 11/23/2015 11:01 PM, Ander Conselvan De Oliveira wrote:
On Mon, 2015-11-23 at 14:04 +, Zanoni, Paulo R wrote:
Em Qui, 2015-11-19 às 13:07 +0200, Ander Conselvan De Oliveira
escreveu:
(Cc'ing Paulo for the audio power domain question)
On Wed, 2015-11-11 at 13:33 +0
On Fri, Sep 11, 2015 at 12:57:06PM +0200, Patrik Jakobsson wrote:
> On Tue, Sep 08, 2015 at 03:36:25AM +0300, Dmitry V. Levin wrote:
> > On Mon, Aug 24, 2015 at 02:42:48PM +0200, Patrik Jakobsson wrote:
[...]
> > > +static char *drm_get_driver_name(struct tcb *tcp)
> > > +{
> > > + char path[PATH_M
On Mon, Sep 07, 2015 at 08:23:57PM +0200, Patrik Jakobsson wrote:
> On Mon, Sep 7, 2015 at 6:51 PM, Dmitry V. Levin wrote:
> > On Mon, Aug 31, 2015 at 02:37:07PM +0200, Patrik Jakobsson wrote:
> > [...]
> >> Here's my take on it (I assume it needs some discussion):
> >>
> >> int
> >> set_tcb_priv_d
Reviewed-by: Sonika Jindal
-Original Message-
From: Vivi, Rodrigo
Sent: Tuesday, November 24, 2015 3:50 AM
To: intel-gfx@lists.freedesktop.org
Cc: Vivi, Rodrigo; Jindal, Sonika
Subject: [PATCH] drm/i915: Also disable PSR on Sink when disabling it on Source.
It is not a bad idea to disab
On Mon, Nov 23, 2015 at 04:53:55PM +, Chris Wilson wrote:
> On Mon, Nov 23, 2015 at 08:48:32AM -0800, Matt Roper wrote:
> > If we fail to reconstruct the BIOS fb (e.g., because the FB is too
> > large), we'll be left with plane state that indicates the primary plane
> > is visible yet has a NUL
On Thu, 2015-11-19 at 22:28 +0100, Kenneth Johansson wrote:
> On 2015-11-10 21:15, Jesse Barnes wrote:
> > On 08/17/2015 08:46 AM, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > Set up the DDI->PLL mapping on SKL also for MST links. Might help
> > > make
> > > MST oper
On Mon, 2015-11-23 at 14:58 -0800, Matt Roper wrote:
> On Mon, Nov 16, 2015 at 04:20:01PM +0100, Patrik Jakobsson wrote:
> > Handle DC off as a power well where enabling the power well will
> > prevent
> > the DMC to enter selected DC states (required around modesets and
> > Aux
> > A). Disabling t
From: Alex Dai
When GuC Work Queue is full, driver will wait GuC for avaliable
space by delaying 1ms. The wait needs to be out of spinlockirq /
unlock. Otherwise, lockup happens because jiffies won't be updated
dur to irq is disabled.
Issue is found in igt/gem_close_race.
Signed-off-by: Alex Da
On Mon, Nov 16, 2015 at 04:20:01PM +0100, Patrik Jakobsson wrote:
> Handle DC off as a power well where enabling the power well will prevent
> the DMC to enter selected DC states (required around modesets and Aux
> A). Disabling the power well will allow DC states again. For now the
> highest DC st
On 11/23/2015 02:34 AM, Tvrtko Ursulin wrote:
On 20/11/15 08:31, Daniel Vetter wrote:
> On Thu, Nov 19, 2015 at 04:10:26PM -0800, yu@intel.com wrote:
>> From: Alex Dai
>>
>> There is a memory leak warning message from i915_gem_context_clean
>> when GuC submission is enabled. The reason is
It is not a bad idea to disable the PSR feature on Sink
when we are disabling on the Source.
v2: Move dpcd write inside mutex protected area as suggested by Sonika.
Cc: Sonika Jindal
Suggested-by: Sonika Jindal
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_psr.c | 4
1 file
Whenever DMC firmware put the HW into DC State a bunch
of registers including this perf counter is reset to 0.
Even with PSR active and working we could still read
"Performance_Counter: 0" what will misslead people to believe
PSR is broken. For instance on SKL we can only see PC10
residency with s
Hi Daniel
Would you please consider merging patches 2,3 and 4 from this series
that are ready to get merged?
They don't depend on patch 1 that is under review yet.
Thanks,
On Wed, Nov 18, 2015 at 1:49 PM, Rodrigo Vivi wrote:
> When we introduced PSR we let LPSP masked allowing us to get PSR
> i
Hi Ville,
Is it better now?
Could you please review this patch?
Thanks,
Rodrigo.
On Wed, Nov 18, 2015 at 11:19 AM, Rodrigo Vivi wrote:
> According to VESA spec: "If a Source device receives and IRQ_HPD
> while in a PSR active state, and cannot identify what caused the
> IRQ_HPD to be generated,
On Mon, Nov 23, 2015 at 6:40 PM, Russell King - ARM Linux
wrote:
> On Mon, Nov 23, 2015 at 10:32:46AM +0100, Daniel Vetter wrote:
>> diff --git a/drivers/gpu/drm/armada/armada_gem.c
>> b/drivers/gpu/drm/armada/armada_gem.c
>> index e3a86b96af2a..a43690ab18b9 100644
>> --- a/drivers/gpu/drm/armada
On Mon, Nov 23, 2015 at 10:32:46AM +0100, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/armada/armada_gem.c
> b/drivers/gpu/drm/armada/armada_gem.c
> index e3a86b96af2a..a43690ab18b9 100644
> --- a/drivers/gpu/drm/armada/armada_gem.c
> +++ b/drivers/gpu/drm/armada/armada_gem.c
> @@ -46,7 +46
On Mon, Nov 23, 2015 at 08:48:32AM -0800, Matt Roper wrote:
> If we fail to reconstruct the BIOS fb (e.g., because the FB is too
> large), we'll be left with plane state that indicates the primary plane
> is visible yet has a NULL fb. This mismatch causes problems later on
> (e.g., for the waterma
If we fail to reconstruct the BIOS fb (e.g., because the FB is too
large), we'll be left with plane state that indicates the primary plane
is visible yet has a NULL fb. This mismatch causes problems later on
(e.g., for the watermark code). Since we've failed to reconstruct the
BIOS FB, the best s
From: Ville Syrjälä
I spotted that we're duplicating the BDW+ pipe IMR frobbing a few
places, so I figured I'd consolidate that. And while doing that I
also cleaned up the ibx/ilk stuff a bit as well.
Ville Syrjälä (3):
drm/i915: Make ibx_{enable,disable}_display_interrupt() static inlines
d
From: Ville Syrjälä
Pull the BDW+ DE pipe interrupt mask frobbing into a central place,
like we have for other platforms.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h| 14 ++
drivers/gpu/drm/i915/i915_irq.c| 41 +-
From: Ville Syrjälä
ironlake_{enable,disable}_display_irq() each just call
ilk_update_display_irq() so let's make them static inlines.
While at it s/ironlake/ilk/ to make things shorter, and a bit more
consistent with the ibx functions.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i9
From: Ville Syrjälä
No reason why ibx_{enable,disable}_display_interrupt() couldn't be
static inlines instead of cpp macros.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i91
On ma, 2015-11-23 at 12:31 +0200, Jani Nikula wrote:
> On Fri, 20 Nov 2015, Ville Syrjälä
> wrote:
> > On Fri, Nov 20, 2015 at 03:55:34PM +, Daniel Stone wrote:
> > > If we experience a refcounting failure in a power domain/well
> > > (unref'ing at
> > > least one too many times), log the name
From: Tvrtko Ursulin
Current code moves _any_ VMA to the inactive list only when
_all_ rendering on an object (so from any context or VM) has
been completed.
This creates an un-natural situation where the context (and
VM) destructors can run with VMAs still on the respective
active list.
Change
On Sat, Nov 21, 2015 at 10:44:12AM +, Chris Wilson wrote:
> On Fri, Nov 20, 2015 at 10:35:41PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > On some machines the CRT connector may be fused off. The weird thing
> > about this setup is that the ADPA register works
On to, 2015-11-19 at 19:06 +0100, Patrik Jakobsson wrote:
> On Wed, Nov 18, 2015 at 07:53:50PM +0200, Imre Deak wrote:
> > Now that the known DMC/DC issues are fixed, let's try again and
> > re-enable the power well support.
> >
> > Signed-off-by: Imre Deak
>
> Together with the PC9/10 fix this
On Mon, 2015-11-23 at 14:04 +, Zanoni, Paulo R wrote:
> Em Qui, 2015-11-19 às 13:07 +0200, Ander Conselvan De Oliveira
> escreveu:
> > (Cc'ing Paulo for the audio power domain question)
> >
> > On Wed, 2015-11-11 at 13:33 +0800, libin.y...@linux.intel.com wrote:
> > > From: Libin Yang
> > >
On Mon, Nov 23, 2015 at 02:28:29PM +, Chris Wilson wrote:
> On Mon, Nov 23, 2015 at 04:22:08PM +0200, Ville Syrjälä wrote:
> > On Sat, Nov 21, 2015 at 10:51:50AM +, Chris Wilson wrote:
> > > On Fri, Nov 20, 2015 at 10:09:18PM +0200, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From:
On Mon, Nov 23, 2015 at 04:10:32PM +0200, Ville Syrjälä wrote:
> On Sat, Nov 21, 2015 at 10:49:04AM +, Chris Wilson wrote:
> > On Fri, Nov 20, 2015 at 10:09:20PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > To get a better idea if underruns occurred d
On Mon, Nov 23, 2015 at 04:22:08PM +0200, Ville Syrjälä wrote:
> On Sat, Nov 21, 2015 at 10:51:50AM +, Chris Wilson wrote:
> > On Fri, Nov 20, 2015 at 10:09:18PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > We still get spurious pipe underruns on ILK/
On Sat, Nov 21, 2015 at 10:51:50AM +, Chris Wilson wrote:
> On Fri, Nov 20, 2015 at 10:09:18PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We still get spurious pipe underruns on ILK/SNB/IVB under two
> > circumstances when dealing with PCH ports:
> > * When th
On Sat, Nov 21, 2015 at 10:49:04AM +, Chris Wilson wrote:
> On Fri, Nov 20, 2015 at 10:09:20PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > To get a better idea if underruns occurred during crtc disabling,
> > let's check for them explicitly. This helps in cases
Em Qui, 2015-11-19 às 13:07 +0200, Ander Conselvan De Oliveira
escreveu:
> (Cc'ing Paulo for the audio power domain question)
>
> On Wed, 2015-11-11 at 13:33 +0800, libin.y...@linux.intel.com wrote:
> > From: Libin Yang
> >
> > This patch adds support for DP MST audio in i915.
> >
> > Enable au
On Fri, 2015-11-20 at 18:56 -0800, Vivek Kasireddy wrote:
> In some cases, we just need one valid (connected) output to perform
> a test. This macro can help in these situations by not having to
> put the test code inside a for loop that iterates over all the outputs.
>
> v2: Added a brief documen
Op 23-11-15 om 14:44 schreef Tvrtko Ursulin:
>
> On 23/11/15 13:38, John Harrison wrote:
>> On 23/11/2015 13:27, Maarten Lankhorst wrote:
>>> Op 23-11-15 om 12:34 schreef john.c.harri...@intel.com:
From: Maarten Lankhorst
This allows users of dma fences to create a android fence.
>>
On 23/11/15 13:38, John Harrison wrote:
On 23/11/2015 13:27, Maarten Lankhorst wrote:
Op 23-11-15 om 12:34 schreef john.c.harri...@intel.com:
From: Maarten Lankhorst
This allows users of dma fences to create a android fence.
v2: Added kerneldoc. (Tvrtko Ursulin).
Signed-off-by: Maarten Lan
On 23/11/2015 13:27, Maarten Lankhorst wrote:
Op 23-11-15 om 12:34 schreef john.c.harri...@intel.com:
From: Maarten Lankhorst
This allows users of dma fences to create a android fence.
v2: Added kerneldoc. (Tvrtko Ursulin).
Signed-off-by: Maarten Lankhorst
Signed-off-by: Tvrtko Ursulin
Cc:
Hi,
On 23/11/15 11:34, john.c.harri...@intel.com wrote:
From: Tvrtko Ursulin
This is actually Maarten's patch, I guess authorship got lost over time
moving through different trees.
Tvrtko
Debug output assumes all sync points are built on top of Android sync points
and when we start crea
Op 23-11-15 om 12:34 schreef john.c.harri...@intel.com:
> From: Tvrtko Ursulin
>
> Debug output assumes all sync points are built on top of Android sync points
> and when we start creating them from dma-fences will NULL ptr deref unless
> taught about this.
>
> Signed-off-by: Tvrtko Ursulin
> Cc:
Op 23-11-15 om 12:34 schreef john.c.harri...@intel.com:
> From: Maarten Lankhorst
>
> This allows users of dma fences to create a android fence.
>
> v2: Added kerneldoc. (Tvrtko Ursulin).
>
> Signed-off-by: Maarten Lankhorst
> Signed-off-by: Tvrtko Ursulin
> Cc: Maarten Lankhorst
> Cc: Daniel V
This could be merged?
On pe, 2015-11-20 at 13:57 +0200, Joonas Lahtinen wrote:
> CLOCK_MONOTONIC_RAW is not affected by NTP, so it should be THE clock
> used for timing execution of tests.
>
> When fetching either the starting or ending time of a test, show the
> time as -1.000s.
>
> v6:
> - Whi
From: Dave Gordon
The current setting of request 'head' in add_request() isn't useful
and has been replaced for purposes of knowing how full the ring is
by 'postfix'. So we can instead use 'head' to define and locate the
entire range spanned by a request.
Pictorially,
headpos
From: Dave Gordon
Per-context initialisation GPU instructions (which are injected directly
into the ringbuffer rather than being submitted as a batch) should not
be allowed to mix with user-generated batches in the same submission; it
will cause confusion for the GuC (which might merge a subseque
From: Dave Gordon
Author: John Harrison
Date: Thu Apr 10 10:41:06 2014 +0100
The scheduler needs to know what each seqno that pops out of the ring is
referring to. This change adds a hook into the the 'submit some random
work that got forgotten about' clean up code to inform the scheduler
tha
From: Dave Gordon
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_params.c| 4 ++--
drivers/gpu/drm/i915/i915_scheduler.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
in
From: Dave Gordon
If the scheduler is busy (e.g. processing a preemption) it will need to
be able to acquire the struct_mutex, so we can't allow untracked
requests to bypass the scheduler and go directly to the hardware (much
confusion will result). Since untracked requests are used only for
init
From: Dave Gordon
This is the very first stage of the scheduler's preemption logic, where
it determines whether a request should be marked as potentially
preemptive, at the point where it is added to the scheduler's queue.
Subsequent logic will determine how to handle the request on the basis
of
From: Dave Gordon
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9bece1e..06dff5a 10
From: Dave Gordon
Record a few more things about the requests outstanding at the time of
capture ...
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 20 +++-
2 files changed, 20 insertions(+
From: Dave Gordon
After preemption, we need to empty out the ringbuffers associated
with preempted requests, so that the scheduler has a clean ring
into which to (re-)insert requests (not necessarily in the same
order as before they were preempted).
So this patch refactors the existing routine i
From: Dave Gordon
This patch refactors the rinbuffer-level code (in execlists/GuC mode
only) and enhances it so that it can emit the proper sequence of opcode
for preemption requests.
A preemption request is similar to an batch submission, but doesn't
actually invoke a batchbuffer, the purpose b
From: Dave Gordon
With the scheduler, request allocation can happen long before
the ring is filled in, and in a different order. So for that case,
we update the request head at the start of _final (the initialisation
on allocation is stull useful for the direct-submission mode).
For: VIZ-2021
Si
From: Dave Gordon
Once a preemptive request has been dispatched to the hardware-layer
submission mechanism, the scheduler must not send any further requests
to the same ring until the preemption completes. Here we add the logic
that ensure that only one preemption per ring can be in progress at o
From: Dave Gordon
Context capture hasn't worked for a while now, probably since the
introduction of execlists; this patch makes it work again by using
a different way of identifying the context of interest.
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gpu_error.c | 7
From: John Harrison
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c | 8 +---
drivers/gpu/drm/i915/i915_scheduler.c | 2 +-
drivers/gpu/drm/i915/i915_trace.h | 31 +++
3 files changed, 25 insertions(+), 16 deletions(-)
di
From: Dave Gordon
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 11 +--
drivers/gpu/drm/i915/i915_gpu_error.c | 9 +
drivers/gpu/drm/i915/intel_ringbuffer.h | 14 ++
4 files
From: Dave Gordon
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 49 --
drivers/gpu/drm/i915/intel_guc.h | 16 +-
3 files changed, 28 insertions(+), 39 de
From: Dave Gordon
To reinitialise a ringbuffer after a hang (or preemption), we need to not
only to not only set both h/w and s/w HEAD and TAIL to 0, but also clear
last_retired_head and recalculate the available space.
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_lr
From: Dave Gordon
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 19 ++-
drivers/gpu/drm/i915/intel_guc_fwif.h | 7 ++-
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
From: Dave Gordon
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 36 +--
2 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/driver
From: Dave Gordon
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++
drivers/gpu/drm/i915/i915_gpu_error.c | 110 ++
2 files changed, 114 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/
From: Dave Gordon
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c| 20 +--
drivers/gpu/drm/i915/i915_guc_submission.c | 32 --
drivers/gpu/drm/i915/intel_guc.h | 12 +--
3 files changed, 45 in
From: Dave Gordon
This patch adds the scheduler logic for managing potentially preemptive
requests, including validating dependencies and working out when a
request can be downgraded to non-preemptive (e.g. when there's nothing
ahead for it to preempt).
Actually-preemptive requests are still dis
From: Dave Gordon
If a batch is submitted via the preemptive (KMD_HIGH-priority) client
then instead of ringing the doorbell we dispatch it using the GuC
"REQUEST_PREEMPTION" action. Also, we specify "clear work queue" and
"clear submit queue" in that request, so the scheduler can reconsider
what
From: Dave Gordon
'relative_constants_mode' has always been tracked per-device, but this
is wrong in execlists (or GuC) mode, as INSTPM is saved and restored
with the logical context, and the per-context value could therefore get
out of sync with the tracked value. This patch moves the tracking
e
From: Dave Gordon
The GuC code needs to know the size of a logical context, so we
expose get_lr_context_size(), renaming it intel_lr_context__size()
to fit the naming conventions for nonstatic functions.
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_lrc.c | 4 ++--
dr
From: Dave Gordon
This patch adds the scheduler logic for postprocessing of completed
preemption requests. It cleans out both the fence_signal list (dropping
references as it goes) and the primary request_list. Requests that
didn't complete are put into the 'preempted' state for resubmission by
t
From: Dave Gordon
Also decode and output CSB entries, in time order
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_gpu_error.c | 37 +++
2 files changed, 30 insertions(+), 8 deletions(-)
diff
From: Dave Gordon
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c | 18
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_scheduler.h | 40 +--
3 files changed, 57 insertions(+), 2 deletion
From: Dave Gordon
This patch adds the GEM & scheduler logic for detection and first-stage
processing of completed preemption requests. Similar to regular batches,
they deposit their sequence number in the hardware status page when
starting and again when finished, but using different locations so
From: Dave Gordon
The GuC firmware uses this for various purposes; it seems to be
required for preemption to work.
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_reg.h| 1 +
drivers/gpu/drm/i915/i915_guc_submission.c | 57 ++-
drivers/gp
From: Dave Gordon
This second client is created with priority KMD_HIGH, and marked
as preemptive.
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c| 9 +
drivers/gpu/drm/i915/i915_guc_submission.c | 15 ++-
drivers/gpu/drm/i915/intel_
From: Dave Gordon
At present, execlist status/ctx_id and CSBs, not the submission queue
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 9 +
drivers/gpu/drm/i915/i915_gpu_error.c | 38 +--
2 files changed, 45 inserti
From: John Harrison
Added pre-emption support to the i915 GPU scheduler.
Note that this patch series was written by David Gordon. I have simply
ported it onto a more recent set of scheduler patches and am uploading
it as part of that work so that everything can be viewed at once. Also
because Da
From: Dave Gordon
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 11 +++
drivers/gpu/drm/i915/intel_guc_fwif.h | 6 ++
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/
From: Dave Gordon
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_lrc.c| 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index
From: Dave Gordon
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_irq.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d280e05..eb55a41 100644
--- a/driv
From: Dave Gordon
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gpu_error.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 52def4e..bafaadd
From: Dave Gordon
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 88 ---
2 files changed, 64 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/driver
From: John Harrison
There are various parameters within the scheduler which can be tuned
to improve performance, reduce memory footprint, etc. This change adds
support for altering these via debugfs.
v2: Updated for priorities now being signed values.
Change-Id: I6c26765269ae7173ff4d3a5c20921ea
From: John Harrison
If a high priority task was to continuously submit batch buffers to
the driver, it could starve out any lower priority task from getting
any GPU time at all. To prevent this, the priority of a queued batch
buffer is bumped each time it does not get submitted to the hardware.
From: John Harrison
The scheduler keeps its own lock on various DRM objects in order to guarantee
safe access long after the original execbuff IOCTL has completed. This is
especially important when pre-emption is enabled as the batch buffer might need
to be submitted to the hardware multiple time
From: John Harrison
There is a sync framework to allow work for multiple independent
systems to be synchronised with each other but without stalling
the CPU whether in the application or the driver. This patch adds
support for this framework to the GPU scheduler.
Batch buffers can now have sync
From: John Harrison
Added a facility for triggering the scheduler state dump via a debugfs
entry.
v2: New patch in series.
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_debugfs.c | 33 +
drivers/gpu/drm/i915/i915_scheduler.c | 9 ++
From: John Harrison
When the seqno wraps around zero, the entire GPU is forced to be idle
for some reason (possibly only to work around issues with hardware
semaphores but no-one seems too sure!). This causes a problem if the
force idle occurs at an inopportune moment such as in the middle of
sub
From: John Harrison
The scheduler has always tracked batch buffer dependencies based on
DRM object usage. This means that it will not submit a batch on one
ring that has outstanding dependencies still executing on other rings.
This is exactly the same synchronisation performed by
i915_gem_object_
From: John Harrison
GPU page faults can now require scheduler operation in order to complete. For
example, in order to free up sufficient memory to handle the fault the handler
must wait for a batch buffer to complete that has not even been sent to the
hardware yet. Thus EAGAIN no longer means a
From: John Harrison
The scheduler decouples the submission of batch buffers to the driver from their
subsequent submission to the hardware. This means that an application which is
continuously submitting buffers as fast as it can could potentialy flood the
driver. To prevent this, the driver now
From: John Harrison
The scheduler needs to track interdependencies between batch buffers. These are
calculated by analysing the object lists of the buffers and looking for
commonality. The scheduler also needs to keep those buffers locked long after
the initial IOCTL call has returned to user lan
From: John Harrison
Now that all the scheduler patches have been applied, it is safe to enable.
Change-Id: I128042e85a30fca765ce1eb46c837c62dee66089
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
From: John Harrison
The scheduler can cause batch buffers, and hence requests, to be
submitted to the ring out of order and asynchronously to their
submission to the driver. Thus at the point of waiting for the
completion of a given request, it is not even guaranteed that the
request has actually
From: John Harrison
It is useful to be able to see what seqnos have actually popped out of the
hardware when viewing the scheduler status.
Change-Id: Ie93e51c64328be2606b8b43440f6344d5f225426
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_scheduler.c | 10 ++
From: Dave Gordon
Added an interface for user land applications/libraries/services to
set their GPU scheduler priority. This extends the existing context
parameter IOCTL interface to add a scheduler priority parameter. The
range is +/-1023 with +ve numbers meaning higher priority. Only
system pro
From: John Harrison
It is useful for know what the scheduler is doing for both debugging
and performance analysis purposes. This change adds a bunch of
counters and such that keep track of various scheduler operations
(batches submitted, completed, flush requests, etc.). The data can
then be read
From: John Harrison
One of the major purposes of the GPU scheduler is to avoid stalling the CPU when
the GPU is busy and unable to accept more work. This change adds support to the
ring submission code to allow a ring space check to be performed before
attempting to submit a batch buffer to the h
From: John Harrison
The seqno value is now only used for the final test for completion of a request.
It is no longer used to track the request through the software stack. Thus it is
no longer necessary to allocate the seqno immediately with the request. Instead,
it can be done lazily and left unt
From: John Harrison
The scheduler now supports sync framework fences being associated with
batch buffers. The execbuff IOCTL allows such fences to be passed in
from user land. This patch wires the two together so that the IOCTL no
longer needs to stall on the fence immediately. Instead the stall
From: John Harrison
When debugging batch buffer submission issues, it is useful to be able to see
what the current state of the scheduler is. This change adds functions for
decoding the internal scheduler state and reporting it.
Change-Id: I0634168e3f3465ff023f5a673165c90b07e535b6
For: VIZ-1587
From: John Harrison
Change-Id: I720463f01c4edd3579ce52e315a85e4d7874d7e5
For: VIZ-1587
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_scheduler.c | 31 +++
drivers/gpu/drm/i915/i915_scheduler.h | 1 +
2 files changed, 32 insertions(+)
diff --git a/drive
From: John Harrison
Added trace points to the scheduler to track all the various events,
node state transitions and other interesting things that occur.
v2: Updated for new request completion tracking implementation.
Change-Id: I9886390cfc7897bc1faf50a104bc651d8baed8a5
For: VIZ-1587
Signed-off-
1 - 100 of 195 matches
Mail list logo
