On Saturday, December 12, 2015 12:41:06 AM Rafael J. Wysocki wrote:
> On Saturday, December 12, 2015 12:21:43 AM Rafael J. Wysocki wrote:
> > On Friday, December 11, 2015 05:47:08 PM Imre Deak wrote:
> > > On pe, 2015-12-11 at 16:40 +0100, Rafael J. Wysocki wrote:
> > > > On Friday, December 11, 20
With a reliable frontbuffer tracking and all instability corner cases
solved let's re-enabled PSR by default on all supported platforms.
In case a new issue is found and PSR is the main suspect, please check
if i915.enable_psr=0 really makes your problem go away. If this is the case
PSR is the cul
Link standby support has been deprecated with 'commit 89251b177
("drm/i915: PSR: deprecate link_standby support for core platforms.")'
The reason for that is that main link in full off offers more power
savings and on HSW and BDW implementations on source side had known
bugs with link standby.
Ho
Unfortunately we don't know all panels and platforms out there and we
found internal prototypes without VBT proper set but where only
link in standby worked well.
So, before enable PSR by default let's instrument the PSR parameter
in a way that we can identify different panels out there that might
Current platforms that support PSR on other port than A only support link
standby mode.
The logic here was wrong since 'commit 89251b177b ("drm/i915: PSR:
deprecate link_standby support for core platforms.")
Cc: Paulo Zanoni
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_psr.c | 6
On Thu, Dec 10, 2015 at 04:43:29PM +, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 10/12/15 14:58, Mika Kuoppala wrote:
> >We get build error as we try to cast from ptr to integer
> >of different size on 32 bit platforms. Use unsigned long
> >as the cast, it will work with both 32 and 64 bit
> >syste
On Saturday, December 12, 2015 12:21:43 AM Rafael J. Wysocki wrote:
> On Friday, December 11, 2015 05:47:08 PM Imre Deak wrote:
> > On pe, 2015-12-11 at 16:40 +0100, Rafael J. Wysocki wrote:
> > > On Friday, December 11, 2015 02:54:45 PM Imre Deak wrote:
> > > > On to, 2015-12-10 at 23:14 +0100, Ra
On Friday, December 11, 2015 04:59:45 PM Ulf Hansson wrote:
> On 11 December 2015 at 16:13, Rafael J. Wysocki wrote:
> > On Friday, December 11, 2015 01:03:50 PM Ulf Hansson wrote:
> >> [...]
> >>
> >> >> >
> >> >> > Which basically means you can call pm_runtime_resume() just fine,
> >> >> > becau
WW50 Regression report.
Last week regressions
+---+---+++
| BugId | Summary | Created on | Bisect |
+---+---+++
| 93263 | 94
igt likes to inject GPU hangs into its command streams. However, as we
expect these hangs, we don't actually want them recorded in the dmesg
output or stored in the i915_error_state (usually). To accomodate this
allow userspace to set a flag on the context that any hang emanating
from that context
Remove some redundant kernel messages as we deduce a hung GPU and
capture the error state.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/
The request tells us where to read the ringbuf from, so use that
information to simplify the error capture. If no request was active at
the time of the hang, the ring is idle and there is no information
inside the ring pertaining to the hang.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/
On Friday, December 11, 2015 05:47:08 PM Imre Deak wrote:
> On pe, 2015-12-11 at 16:40 +0100, Rafael J. Wysocki wrote:
> > On Friday, December 11, 2015 02:54:45 PM Imre Deak wrote:
> > > On to, 2015-12-10 at 23:14 +0100, Rafael J. Wysocki wrote:
> > > > On Thursday, December 10, 2015 11:20:40 PM Im
igt likes to inject GPU hangs into its command streams. However, as we
expect these hangs, we don't actually want them recorded in the dmesg
output or stored in the i915_error_state (usually). To accomodate this
allow userspace to set a flag on the context that any hang emanating
from that context
On Wed, 25 Nov 2015 18:07:59 +0100
Daniel Vetter wrote:
> Unfortunately the entire improved docbook project died at KS in a
> massive bikeshed. So we need to carry this around in drm private trees
> forever :(
I don't think that's an entirely helpful way to look at things, honestly.
Changing how
Pick up context flags, softpin, etc.
Signed-off-by: Jesse Barnes
---
include/drm/i915_drm.h | 57 ++
1 file changed, 48 insertions(+), 9 deletions(-)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index ded43b1..4ce1fe9 100644
--- a/
On Fri, 2015-12-11 at 17:55 -0200, Paulo Zanoni wrote:
> 2015-12-11 6:49 GMT-02:00 Rodrigo Vivi :
> > Link standby support has been deprecated with 'commit 89251b177
> > ("drm/i915: PSR: deprecate link_standby support for core
> > platforms.")'
> >
> > The reason for that is that main link in ful
On Fri, Dec 11, 2015 at 07:24:29PM +0100, Daniel Vetter wrote:
> On Thu, Dec 10, 2015 at 10:37:36AM +, Chris Wilson wrote:
> > Describe the intent of boosting the GPU frequency to maximum before
> > waiting on the GPU.
> >
> > RPS waitboosting was introduced with
> >
> > commit b29c19b645287f
On Fri, Dec 11, 2015 at 07:44:15PM +0100, Daniel Vetter wrote:
> I missed this myself when reviewing
>
> commit 237ed86c693d8a8e4db476976aeb30df4deac74b
> Author: Sonika Jindal
> Date: Tue Sep 15 09:44:20 2015 +0530
>
> drm/i915: Check live status before reading edid
>
> Long sleeps like
2015-12-11 6:49 GMT-02:00 Rodrigo Vivi :
> Link standby support has been deprecated with 'commit 89251b177
> ("drm/i915: PSR: deprecate link_standby support for core platforms.")'
>
> The reason for that is that main link in full off offers more power
> savings and some platforms implementations on
On Fri, 2015-12-11 at 17:09 -0200, Paulo Zanoni wrote:
> 2015-12-10 14:28 GMT-02:00 Rodrigo Vivi :
> > This bit is also reserved on Skylake. Actually the only
> > platform that supports this is Haswell, so let's fix
> > this logic and apply this link entry time only for the
> > platform that suppor
2015-12-10 14:28 GMT-02:00 Rodrigo Vivi :
> This bit is also reserved on Skylake. Actually the only
> platform that supports this is Haswell, so let's fix
> this logic and apply this link entry time only for the
> platform that supports it, i.e. Haswell.
>
> This also changes the style to let more
On Fri, Dec 11, 2015 at 03:18:30PM +, Derek Morton wrote:
> gem_flink_race and prime_self_import have subtests which read the
> number of open gem objects from debugfs to determine if objects have
> leaked during the test. However the test can fail sporadically if
> the number of gem objects ch
On Fri, Dec 11, 2015 at 05:26:19PM +0100, Daniel Vetter wrote:
> On Fri, Dec 11, 2015 at 02:59:09PM +, Nick Hoath wrote:
> > Swap the order of context & engine cleanup, so that it is now
> > contexts, then engines.
> > This allows the context clean up code to do things like confirm
> > that rin
On Fri, Dec 11, 2015 at 02:49:52PM +, Chris Wilson wrote:
> On Fri, Dec 11, 2015 at 02:34:13PM +, Michel Thierry wrote:
> > We detected if objects should be moved to the lower parts when 48-bit
> > support flag was not set, but not the other way around.
> >
> > This handles the case in whi
On Fri, Dec 11, 2015 at 03:35:36PM +, Rob Bradford wrote:
> On Fri, 2015-12-11 at 16:01 +0530, Dhanya Pillai wrote:
> > + /*Enable red planes and apply unit gamma*/
> > + fb_color.red = 1;
> > + fb_color.green =0;
> > + fb_color.blue = 0;
> > + unit_gamma = 0; /*0 -> white 1->black*/
On Fri, Dec 11, 2015 at 03:12:05PM +0800, Gary Wang wrote:
> The total delay of HDMI hotplug detecting with 30ms should have
> been split into a resolution of 3 retries of 10ms each, for the worst
> cases. But it still suffered from only waiting 10ms at most in
> intel_hdmi_detect(). This patch cor
I missed this myself when reviewing
commit 237ed86c693d8a8e4db476976aeb30df4deac74b
Author: Sonika Jindal
Date: Tue Sep 15 09:44:20 2015 +0530
drm/i915: Check live status before reading edid
Long sleeps like this really shouldn't waste cpy cycles spinning.
Cc: Sonika Jindal
Cc: "Wang, G
On Fri, Dec 11, 2015 at 07:10:35AM +, Wang, Gary C wrote:
> I will upload new version of patch for review. Thanks!
>
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Wang, Gary C
> Sent: Friday, December 11, 2015 2:23 PM
> To: Jind
Hi Dave,
drm-intel-next-2015-12-04-1:
This is the "fix igt basic test set issues" edition.
- more PSR fixes from Rodrigo, getting closer
- tons of fifo underrun fixes from Ville
- runtime pm fixes from Imre, Daniel Stone
- fix SDE interrupt handling properly (Jani Nikula)
- hsw/bdw fdi modeset seq
On Thu, Dec 10, 2015 at 10:37:36AM +, Chris Wilson wrote:
> Describe the intent of boosting the GPU frequency to maximum before
> waiting on the GPU.
>
> RPS waitboosting was introduced with
>
> commit b29c19b645287f7062e17d70fa4e9781a01a5d88
> Author: Chris Wilson
> Date: Wed Sep 25 17:34
On Fri, Dec 11, 2015 at 12:49:37PM +, Dave Gordon wrote:
> On 11/12/15 12:19, Tvrtko Ursulin wrote:
> >
> >On 11/12/15 11:22, Ankitprasad Sharma wrote:
> >>On Wed, 2015-12-09 at 14:06 +, Tvrtko Ursulin wrote:
> >>>Hi,
> >>>
> >>>On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote:
> >>>
On Wed, Dec 09, 2015 at 07:39:56PM +, Dave Gordon wrote:
> On 09/12/15 16:15, Tvrtko Ursulin wrote:
> >
> >Hi,
> >
> >On 09/12/15 12:46, ankitprasad.r.sha...@intel.com wrote:
> >>From: Ankitprasad Sharma
> >>
> >>This patch adds support for extending the pread/pwrite functionality
> >>for obje
On Thu, Dec 10, 2015 at 05:57:57PM -0800, Matt Roper wrote:
> On Thu, Dec 10, 2015 at 03:14:38PM +0100, Daniel Vetter wrote:
> > On Tue, Dec 08, 2015 at 02:48:51PM -0800, Matt Roper wrote:
> > > In all of our various SDVO setup functions, we allocate an SDVO
> > > connector (along with an associate
With a reliable frontbuffer tracking and all instability corner cases
solved let's re-enabled PSR by default on all supported platforms.
In case a new issue is found and PSR is the main suspect, please check
if i915.enable_psr=0 really makes your problem go away. If this is the case
PSR is the cul
On Fri, Dec 11, 2015 at 06:08:10PM +0100, Daniel Vetter wrote:
> Hm, I think if you force a fault on relocs and then shrink everything
> really hard before actually managing to submit the batch you could provoke
> this into a proper bug. one-in-a-billion perhaps ;-)
Hmm, you would need to force th
On Thu, Dec 10, 2015 at 04:41:54PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 10, 2015 at 02:48:48PM +0100, Daniel Vetter wrote:
> > On Tue, Dec 08, 2015 at 07:59:46PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > When the DDI port is in HDMI/DVI mode, it a
On Thu, Dec 10, 2015 at 09:06:25PM +, Chris Wilson wrote:
> On Thu, Dec 10, 2015 at 06:51:24PM +, Dave Gordon wrote:
> > When creating a new (pageable) GEM object and filling it with data, we
> > must mark it as 'dirty', i.e. backing store is out-of-date w.r.t. the
> > newly-written content
On Thu, Dec 10, 2015 at 09:04:23PM +, Chris Wilson wrote:
> On Thu, Dec 10, 2015 at 05:24:42PM +, Dave Gordon wrote:
> > On 10/12/15 13:29, Chris Wilson wrote:
> > >On Wed, Dec 09, 2015 at 03:52:51PM +, Dave Gordon wrote:
> > >>In various places, a single page of a (regular) GEM object
On Thu, Dec 10, 2015 at 02:52:57PM +, Chris Wilson wrote:
> On Thu, Dec 10, 2015 at 03:06:55PM +0100, Daniel Vetter wrote:
> > On Wed, Dec 09, 2015 at 03:52:52PM +, Dave Gordon wrote:
> > > In a few places, we fill a GEM object with data, or overwrite some
> > > portion of its contents othe
On Fri, Dec 11, 2015 at 10:33:46AM +, Morton, Derek J wrote:
> >
> >
> >-Original Message-
> >From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> >Vetter
> >Sent: Thursday, December 10, 2015 12:53 PM
> >To: Morton, Derek J
> >Cc: Daniel Vetter; intel-gfx@lists.fre
On Thu, Dec 10, 2015 at 06:01:28PM +0200, David Weinehall wrote:
> On Tue, Dec 08, 2015 at 03:42:27PM +0200, Ville Syrjälä wrote:
> > On Tue, Dec 08, 2015 at 10:50:39AM +0200, David Weinehall wrote:
> > > Since the defaults for some external power management related settings
> > > prevents us from
On Fri, Dec 11, 2015 at 05:11:23PM +0530, Kumar, Shobhit wrote:
> On 12/11/2015 04:55 PM, Thulasimani, Sivakumar wrote:
> >
> >
> >On 12/10/2015 8:32 PM, Ville Syrjälä wrote:
> >>On Thu, Dec 10, 2015 at 08:09:01PM +0530, Thulasimani, Sivakumar wrote:
> >>>
> >>>On 12/10/2015 7:08 PM, Ville Syrjälä
Link standby support has been deprecated with 'commit 89251b177
("drm/i915: PSR: deprecate link_standby support for core platforms.")'
The reason for that is that main link in full off offers more power
savings and some platforms implementations on source side had known
bugs with link standby.
Ho
On Fri, Dec 11, 2015 at 12:29:40PM +, Chris Wilson wrote:
> On Fri, Dec 11, 2015 at 12:19:09PM +, Dave Gordon wrote:
> > On 10/12/15 08:58, Daniel Vetter wrote:
> > >On Mon, Dec 07, 2015 at 12:51:49PM +, Dave Gordon wrote:
> > >>I think I missed i915_gem_phys_pwrite().
> > >>
> > >>i915
On Fri, Dec 11, 2015 at 09:02:18AM +, Chris Wilson wrote:
> On Thu, Dec 03, 2015 at 10:14:54AM +0100, Daniel Vetter wrote:
> > On Tue, Dec 01, 2015 at 11:05:35AM +, Chris Wilson wrote:
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> >
On Fri, Dec 11, 2015 at 02:14:00PM +, Dave Gordon wrote:
> On 01/12/15 11:46, Tvrtko Ursulin wrote:
> >
> >On 23/10/15 18:02, Tomas Elf wrote:
> >>When clearing an execlist queue, instead of traversing it and
> >>unreferencing all
> >>requests while holding the spinlock (which might lead to thr
[...]
>> >
>> > Which basically means you can call pm_runtime_resume() just fine,
>> > because it will do nothing if the status is RPM_ACTIVE already.
>> >
>> > So really, why don't you use pm_runtime_get_sync()?
>>
>> The difference would be that if the status is not RPM_ACTIVE already we
>> woul
On 11 December 2015 at 16:13, Rafael J. Wysocki wrote:
> On Friday, December 11, 2015 01:03:50 PM Ulf Hansson wrote:
>> [...]
>>
>> >> >
>> >> > Which basically means you can call pm_runtime_resume() just fine,
>> >> > because it will do nothing if the status is RPM_ACTIVE already.
>> >> >
>> >> >
On Fri, Dec 11, 2015 at 02:59:09PM +, Nick Hoath wrote:
> Swap the order of context & engine cleanup, so that it is now
> contexts, then engines.
> This allows the context clean up code to do things like confirm
> that ring->dev->struct_mutex is locked without a NULL pointer
> dereference.
> Th
On Thu, Dec 10, 2015 at 08:28:23AM -0800, Rodrigo Vivi wrote:
> Link standby support has been deprecated with 'commit 89251b177
> ("drm/i915: PSR: deprecate link_standby support for core platforms.")'
>
> The reason for that is that main link in full off offers more power
> savings and some platfo
On 11/12/15 15:30, John Harrison wrote:
Reply moved from earlier patch set which has now been superceeded by
this set...
On 11/12/2015 12:17, Tvrtko Ursulin wrote:
Hi,
Some random comments, mostly from the point of view of solving the
thundering herd problem.
On 23/11/15 11:34, john.c.harr
On Fri, Dec 11, 2015 at 03:35:54PM +, John Harrison wrote:
> On 11/12/2015 14:55, Chris Wilson wrote:
> >On Fri, Dec 11, 2015 at 01:12:01PM +, john.c.harri...@intel.com wrote:
> >>From: John Harrison
> >>
> >>The notify function can be called many times without the seqno
> >>changing. A la
On 11/12/15 13:11, john.c.harri...@intel.com wrote:
From: Peter Lawthers
In the 3.14 kernel, a signaled fence was indicated by the status field
== 1. In 4.x, a status == 0 indicates signaled, status < 0 indicates error,
and status > 0 indicates active.
This patch wraps the check for a signale
On pe, 2015-12-11 at 16:40 +0100, Rafael J. Wysocki wrote:
> On Friday, December 11, 2015 02:54:45 PM Imre Deak wrote:
> > On to, 2015-12-10 at 23:14 +0100, Rafael J. Wysocki wrote:
> > > On Thursday, December 10, 2015 11:20:40 PM Imre Deak wrote:
> > > > On Thu, 2015-12-10 at 22:42 +0100, Rafael J
On 11/12/2015 14:55, Chris Wilson wrote:
On Fri, Dec 11, 2015 at 01:12:01PM +, john.c.harri...@intel.com wrote:
From: John Harrison
The notify function can be called many times without the seqno
changing. A large number of duplicates are to prevent races due to the
requirement of not enabl
On Fri, 2015-12-11 at 16:01 +0530, Dhanya Pillai wrote:
> From: Dhanya
>
> This patch will verify color correction capability of a display
> driver.
> Gamma/CSC/De-gamma for SKL/BXT supported.
>
> Signed-off-by: Dhanya
> ---
> tests/.gitignore | 1 +
> tests/Makefile.sources | 1 +
>
Reply moved from earlier patch set which has now been superceeded by
this set...
On 11/12/2015 12:17, Tvrtko Ursulin wrote:
Hi,
Some random comments, mostly from the point of view of solving the
thundering herd problem.
On 23/11/15 11:34, john.c.harri...@intel.com wrote:
From: John Harris
On 11/12/15 13:12, john.c.harri...@intel.com wrote:
From: John Harrison
Various projects desire a mechanism for managing dependencies between
work items asynchronously. This can also include work items across
complete different and independent systems. For example, an
application wants to ret
gem_flink_race and prime_self_import have subtests which read the
number of open gem objects from debugfs to determine if objects have
leaked during the test. However the test can fail sporadically if
the number of gem objects changes due to other process activity.
This patch introduces a change to
On Friday, December 11, 2015 02:54:45 PM Imre Deak wrote:
> On to, 2015-12-10 at 23:14 +0100, Rafael J. Wysocki wrote:
> > On Thursday, December 10, 2015 11:20:40 PM Imre Deak wrote:
> > > On Thu, 2015-12-10 at 22:42 +0100, Rafael J. Wysocki wrote:
> > > > On Thursday, December 10, 2015 10:36:37 PM
Swap the order of context & engine cleanup, so that it is now
contexts, then engines.
This allows the context clean up code to do things like confirm
that ring->dev->struct_mutex is locked without a NULL pointer
dereference.
This came about as a result of the 'intel_ring_initialized() must
be simpl
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
Batch buffers which have been pre-emption mid-way through execution
must be handled seperately. Rather than simply re-submitting the batch
as a brand new piece of work, the driver only needs to requeue the
context. The hardware will take care of picking up where it left off.
v2
On Fri, Dec 11, 2015 at 01:12:01PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The notify function can be called many times without the seqno
> changing. A large number of duplicates are to prevent races due to the
> requirement of not enabling interrupts until requested. Ho
From: John Harrison
v2: Fixed a typo (and improved the names in general). Updated for
changes to notify() code.
For: VIZ-2021
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c | 5 +++--
drivers/gpu/drm/i915/i915_scheduler.c | 2 +-
drivers/gpu/drm/i915/i915_trace.h |
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
On Fri, Dec 11, 2015 at 02:34:13PM +, Michel Thierry wrote:
> We detected if objects should be moved to the lower parts when 48-bit
> support flag was not set, but not the other way around.
>
> This handles the case in which an object was allocated in the 32-bit
> address range, but it has bee
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
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
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).
v2: Updated to u
On Fri, Dec 11, 2015 at 02:36:36PM +, Nick Hoath wrote:
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index 84e2b20..a2857b0 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -449,7 +449,7 @@ static int i915_load_mod
On Friday, December 11, 2015 01:03:50 PM Ulf Hansson wrote:
> [...]
>
> >> >
> >> > Which basically means you can call pm_runtime_resume() just fine,
> >> > because it will do nothing if the status is RPM_ACTIVE already.
> >> >
> >> > So really, why don't you use pm_runtime_get_sync()?
> >>
> >> T
On 12/11/2015 2:13 PM, Michał Winiarski wrote:
According to bspec, some parts of HW require the addresses to be in
a canonical form, where bits [63:48] == [47]. Let's convert addresses to
canonical form prior to relocating and return converted offsets to
userspace. We also need to make sure that
Swap the order of context & engine cleanup, so that it is now
contexts, then engines.
This allows the context clean up code to do things like confirm
that ring->dev->struct_mutex is locked without a NULL pointer
dereference.
This came about as a result of the 'intel_ring_initialized() must
be simpl
We detected if objects should be moved to the lower parts when 48-bit
support flag was not set, but not the other way around.
This handles the case in which an object was allocated in the 32-bit
address range, but it has been marked as safe to move above it, which
theoretically would help to keep
On 11/12/15 13:12, john.c.harri...@intel.com wrote:
From: John Harrison
The notify function can be called many times without the seqno
changing. A large number of duplicates are to prevent races due to the
requirement of not enabling interrupts until requested. However, when
interrupts are en
According to bspec, some parts of HW require the addresses to be in
a canonical form, where bits [63:48] == [47]. Let's convert addresses to
canonical form prior to relocating and return converted offsets to
userspace. We also need to make sure that userspace is using addresses
in canonical form in
i915 validates that requested offset is in canonical form, so tests need
to convert the offsets as required.
Also add test to verify non-canonical 48-bit address will be rejected.
Signed-off-by: Michel Thierry
---
tests/gem_softpin.c | 66 +
1
On 01/12/15 11:46, Tvrtko Ursulin wrote:
On 23/10/15 18:02, Tomas Elf wrote:
When clearing an execlist queue, instead of traversing it and
unreferencing all
requests while holding the spinlock (which might lead to thread
sleeping with
IRQs are turned off - bad news!), just move all requests to
On Fri, 11 Dec 2015 07:07:53 +0100,
Libin Yang wrote:
>
> Add Takashi and ALSA mail list.
>
> On 12/10/2015 05:02 PM, Daniel Vetter wrote:
> > On Tue, Dec 08, 2015 at 04:01:20PM +0800, Libin Yang wrote:
> >> Hi all,
> >>
> >> Any comments on the patches?
> >
> > Sorry, simply fell through the cra
On Fri, 11 Dec 2015 11:43:51 +0100,
Takashi Iwai wrote:
>
> On Fri, 11 Dec 2015 07:07:53 +0100,
> Libin Yang wrote:
> >
> > >>> diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > >>> b/drivers/gpu/drm/i915/intel_audio.c
> > >>> index 9aa83e7..5ad2e66 100644
> > >>> --- a/drivers/gpu/drm/i915/in
From: John Harrison
Implemented a batch buffer submission scheduler for the i915 DRM driver.
The general theory of operation is that when batch buffers are
submitted to the driver, the execbuffer() code assigns a unique seqno
value and then packages up all the information required to execute the
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
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
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
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.
v3: Updated a debug message with the new state_str() function.
Cha
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
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.
v3: Updated for changes to node kill code.
Change-Id: I9886390cfc7897bc1faf50
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
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
When requesting that all GPU work is completed, it is now necessary to
get the scheduler involved in order to flush out work that queued and
not yet submitted.
v2: Updated to add support for flushing the scheduler queue by time
stamp rather than just doing a blanket flush.
v
From: John Harrison
Ring space is reserved when constructing a request to ensure that the
subsequent 'add_request()' call cannot fail due to waiting for space
on a busy or broken GPU. However, the scheduler jumps in to the middle
of the execbuffer process between request creation and request
subm
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
The scheduler decouples the submission of batch buffers to the driver
with submission of batch buffers to the hardware. Thus it is possible
for an application to close its DRM file handle while there is still
work outstanding. That means the scheduler needs to know about file
From: John Harrison
Initial creation of scheduler source files. Note that this patch
implements most of the scheduler functionality but does not hook it in
to the driver yet. It also leaves the scheduler code in 'pass through'
mode so that even when it is hooked in, it will not actually do very
m
From: Dave Gordon
Keep a local copy of the request pointer in the _final() functions
rather than dereferencing the params block repeatedly.
v3: New patch in series.
For: VIZ-1587
Signed-off-by: Dave Gordon
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +
From: John Harrison
Split the execbuffer() function in half. The first half collects and
validates all the information requried to process the batch buffer. It
also does all the object pinning, relocations, active list management,
etc - basically anything that must be done upfront before the IOCT
From: John Harrison
The notify function can be called many times without the seqno
changing. A large number of duplicates are to prevent races due to the
requirement of not enabling interrupts until requested. However, when
interrupts are enabled the IRQ handle can be called multiple times
withou
From: John Harrison
The sync framework is now used by the i915 driver. Therefore it can be
moved out of staging and into the regular tree. Also, the public
interfaces can actually be made public and exported.
v3: New patch for series.
Signed-off-by: John Harrison
Signed-off-by: Geoff Miller
-
1 - 100 of 179 matches
Mail list logo
