From: Borun Fu
On VLV, after i915_pm_suspend display power wells are staying
power ungated. So, after initiating mem sleep "echo mem > /sys/power/state"
Display is staing D0 State. There might be better way/place to power gate
these wells. Also, we need to make sure that if wells are power gated
From: Daniel Vetter
Make sure we track the sw side (psr.active) correctly and WARN
everywhere it might get out of sync with the hw.
v2: Fixup WARN_ON logic inversion, reported by Rodrigo.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Daniel Vetter
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/
From: Daniel Vetter
I've tried to split this up, but all the changes are so tightly
related that I didn't find a good way to do this without breaking
bisecting. Essentially this completely changes how psr is glued into
the overall driver, and there's not much you can do to soften such a
paradigm
From: Daniel Vetter
It's not really optional to have locking ...
The ugly part is how much locking the psr work needs since it has to
recheck everything. Which is way too much. But we need to ditch the
psr work in it's current form anyway and implement proper frontbuffer
tracking.
The other nas
From: Daniel Vetter
Due to runtime pm and system s/r we need to restore hw state every
time we enable a pipe again. Hence trying to avoid that is just
pointless book-keeping which Rodrigo then tried to work around by
manually adding psr_setup calls to our resume code.
Much simpler to just remove
From: Daniel Vetter
We need to make sure that no one else is using this in the
enable function and also that the work item hasn't raced
with the disabled function.
v2: Improve bisectability by moving one hunk to an earlier patch.
v3: added missing dev_priv declaration (Rodrigo)
Reviewed-by: Ro
From: Daniel Vetter
We only need to check for this in psr_enable, everything else is
already protect by the dev_priv->psr.enabled checks. Those need the
psr locking, but these functions are called infrequent enough that the
locking overhead is negligible.
Suggested by Chris Wilson.
Reviewed-by:
From: Daniel Vetter
It's disabled already except when we've raced.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Daniel Vetter
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/d
From: Daniel Vetter
Trying to fish that one out through looping is a bit a locking
nightmare. So just set it and use it in the work struct.
v2:
- Don't Oops in psr_work, spotted by Rodrigo.
- Fix compile warning.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Daniel Vetter
Signed-off-by: Rodrigo Vi
From: Daniel Vetter
Can't review this right now due to lack of DRRS code.
Reviewed-by: Rodrigo Vivi
Cc: Vandana Kannan
Signed-off-by: Daniel Vetter
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i
From: Daniel Vetter
Add busy_frontbuffer_bits and locking.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Daniel Vetter
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/d
Panel Self Refresh is an eDP power saving feature specified by VESA's eDP v1.3,
that allows some panel componets to shutdown while you still see static images
on
the screen. Besides being supported on the platform it must be supported by the
eDP panel itself.
Now that we have the propper frontbuf
On Fri, 11 Jul 2014, Pavel Machek wrote:
> > > > Ok, so I have set up machines for ktest / autobisect, and found out
> > > > that
> > > > 3.16-rc1 no longer has that problem. Oh well, bisect would not be fun,
> > > > anyway...
> > >
> > > I am still seeing the problem with 3.16-rc2.
> >
> > I
commit c675949ec58ca50d5a3ae3c757892f1560f6e896
drm/i915: do not setup backlight if not available according to VBT
caused a regression on the HP Chromebook 14 (with Celeron 2955U CPU),
which has a misconfigured VBT. Apply quirk to ignore the VBT backlight
presence check during backlight setup.
On Tue, Jul 08, 2014 at 10:31:59AM +0530, sonika.jin...@intel.com wrote:
> From: Ville Syrjälä
>
> Sprite planes support 180 degree rotation. The lower layers are now in
> place, so hook in the standard rotation property to expose the feature
> to the users.
>
> v2: Moving rotation_property to d
On Tue, Jul 08, 2014 at 10:31:59AM +0530, sonika.jin...@intel.com wrote:
> From: Ville Syrjälä
>
> Sprite planes support 180 degree rotation. The lower layers are now in
> place, so hook in the standard rotation property to expose the feature
> to the users.
>
> v2: Moving rotation_property to d
On Tue, Jul 08, 2014 at 10:31:59AM +0530, sonika.jin...@intel.com wrote:
> From: Ville Syrjälä
>
> Sprite planes support 180 degree rotation. The lower layers are now in
> place, so hook in the standard rotation property to expose the feature
> to the users.
>
> v2: Moving rotation_property to d
> From: Konrad Rzeszutek Wilk [mailto:konrad.w...@oracle.com]
> Sent: Friday, July 11, 2014 12:42 PM
>
> On Fri, Jul 11, 2014 at 08:29:56AM +0200, Daniel Vetter wrote:
> > On Thu, Jul 10, 2014 at 09:08:24PM +, Tian, Kevin wrote:
> > > actually I'm curious whether it's still necessary to __dete
On Fri, Jul 11, 2014 at 08:29:56AM +0200, Daniel Vetter wrote:
> On Thu, Jul 10, 2014 at 09:08:24PM +, Tian, Kevin wrote:
> > actually I'm curious whether it's still necessary to __detect__ PCH. Could
> > we assume a 1:1 mapping between GPU and PCH, e.g. BDW already hard
> > code the knowledge:
On Mon 2014-07-07 10:39:08, Daniel Vetter wrote:
> On Fri, Jun 27, 2014 at 03:37:16PM +0200, Jiri Kosina wrote:
> > On Thu, 26 Jun 2014, Pavel Machek wrote:
> >
> > > Ok, so I have set up machines for ktest / autobisect, and found out that
> > > 3.16-rc1 no longer has that problem. Oh well, bisec
On Fri, Jul 11, 2014 at 06:34:12PM +0100, Damien Lespiau wrote:
> If the approach convinces, I'll do more.
That sounds presumptuous, I more likely need to do more to convince.
I meant, I still need to have a look at the harder problem, providing a
static device_info structure and hardcoding vario
OK, sounds like it's best to ignore this patch then.
- Armin
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Friday, July 11, 2014 10:49 AM
To: Reese, Armin C
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Optimize the
i915_ge
Which of the I-G-Ts would be the best to house the set-cache subtest? Is
gem_partial_pwrite_pread a good candidate?
- Armin
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Friday, June 13, 2014 12:14 AM
To: Reese, Armin C
Cc: intel-
On Fri, Jul 11, 2014 at 05:46:01PM +, Reese, Armin C wrote:
> So the code should stay the way it is originally and assume GPU idling is
> always needed?
Yes, it also cover dmabuf imports as well. Definitely likely that we
need to keep the wa for those.
-Chris
--
Chris Wilson, Intel Open Sou
So the code should stay the way it is originally and assume GPU idling is
always needed?
- Armin
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Friday, July 11, 2014 10:37 AM
To: Reese, Armin C
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [P
On Fri, Jul 11, 2014 at 05:29:48PM +, Reese, Armin C wrote:
> Originally, the function always executes do_idling() followed by
> undo_idling() regardless of whether obj->has_dma_mapping is TRUE or not.
> This change idles the GPU only if needed.
>
> However, if the intention of the function
Being able to target a single platform to reduce the driver size has been
voiced a few times. These patches provide a Kconfig option to provide the
opportunity.
Let's start small, and, along side the generic "Multi-platform" option, only
present Haswell and Broadwell in the list of platforms to ch
It'd be nice to be able to target a single platform to reduce the size
for the i915 driver.
Start low-fi and coarse grained: it's easy to split the (S)DVO code out,
the API surface is reduced to two init functions.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/Kconfig | 25
We don't need MIPI DSI support on those platforms, so only select
DRM_I915_MIPI when compiling the driver with multi-plaform support.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/Kconfig | 4
drivers/gpu/drm/i915/Makefile| 8
drivers/gpu/drm/i915/intel_drv.h | 4 +
On Fri, Jul 11, 2014 at 05:29:48PM +, Reese, Armin C wrote:
> Originally, the function always executes do_idling() followed by
> undo_idling() regardless of whether obj->has_dma_mapping is TRUE or not.
> This change idles the GPU only if needed.
But those functions will be inlined by the co
Originally, the function always executes do_idling() followed by undo_idling()
regardless of whether obj->has_dma_mapping is TRUE or not. This change idles
the GPU only if needed.
However, if the intention of the function is to ALWAYS idle the GPU, then my
change is a mistake.
- Armin
-Or
On Fri, Jul 11, 2014 at 08:48:52AM -0700, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> For a description of this patchset, please check the previous cover letters:
> [1], [2] and [3].
>
> The main changes introduced in this v4 are:
>
> - Do not abstract __i915_add_request away.
> - Squ
No bugs have been reported so far ...
Daniel caught this by inspection of the Full PPGTT patch set and wanted me to
fix it.
- Armin
-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Friday, July 11, 2014 10:21 AM
To: Reese, Armin C
Cc: intel-gfx@lists.freedesk
On Fri, Jul 11, 2014 at 10:15:35AM -0700, armin.c.re...@intel.com wrote:
> From: Armin Reese
If you can a description of how to trigger the bug and the user impact
would be great. And Daniel is about to ask for a test case in 3
seconds...
-Chris
--
Chris Wilson, Intel Open Source Technology Cen
From: Armin Reese
Signed-off-by: Armin Reese
---
drivers/gpu/drm/i915/i915_gem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 87d0aac..676e5f4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/
From: Armin Reese
Signed-off-by: Armin Reese
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index afd4eef..7e2190e 100644
--- a/drivers/gpu/drm/i
On Fri, Jul 11, 2014 at 10:15:36AM -0700, armin.c.re...@intel.com wrote:
> From: Armin Reese
>
> Signed-off-by: Armin Reese
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
>
From: Armin Reese
Signed-off-by: Armin Reese
---
drivers/gpu/drm/i915/i915_gem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 87d0aac..676e5f4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/
From: Armin Reese
Signed-off-by: Armin Reese
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index afd4eef..7e2190e 100644
--- a/drivers/gpu/drm/i
On Fri, Jul 11, 2014 at 07:07:33PM +0300, Mika Kuoppala wrote:
> deepa...@linux.intel.com writes:
>
> > From: Deepak S
> >
> > This is useful for userspace utilities to verify and micromanaging
> > the increase/decrease frequncy.
> >
> > v2: Use vlv_gpu_freq to get freq (Deepak)
> >
> > Signed-of
On Fri, Jul 11, 2014 at 06:03:16PM +0200, Daniel Vetter wrote:
> They match now.
>
> Cc: Deepak S
> Cc: Mika Kuoppala
> Signed-off-by: Daniel Vetter
Scrap that ...
> ---
> drivers/gpu/drm/i915/i915_sysfs.c | 20 ++--
> 1 file changed, 2 insertions(+), 18 deletions(-)
>
> dif
On Fri, Jul 11, 2014 at 08:48:43PM +0530, sagar.a.kam...@intel.com wrote:
> From: Borun Fu
>
> On VLV, after i915_pm_suspend display power wells are staying
> power ungated. So, after initiating mem sleep "echo mem > /sys/power/state"
> Display is staing D0 State. There might be better way/place
deepa...@linux.intel.com writes:
> From: Deepak S
>
> This is useful for userspace utilities to verify and micromanaging
> the increase/decrease frequncy.
>
> v2: Use vlv_gpu_freq to get freq (Deepak)
>
> Signed-off-by: Deepak S
> ---
> drivers/gpu/drm/i915/intel_pm.c | 15 +++
> 1
On Fri, Jul 11, 2014 at 03:31:39PM +0100, tim.g...@intel.com wrote:
> From: Tim Gore
>
> kms_force_connector is a new test that requires cairo.
> I have added it to the list of tests not to build on
> Android unless ANDROID_HAS_CAIRO is set.
>
> Signed-off-by: Tim Gore
Applied.
-Daniel
> ---
From: Oscar Mateo
Since the ringbuffer does not belong per engine anymore, we have to
make sure that we are always recording the correct ringbuffer.
TODO: This is only a small fix to keep basic error capture working, but
we need to add more information for it to be useful (e.g. dump the
context
From: Oscar Mateo
Well, new-ish: if all this code looks familiar, that's because it's
a clone of the existing submission mechanism (with some modifications
here and there to adapt it to LRCs and Execlists).
And why did we do this instead of reusing code, one might wonder?
Well, there are some fe
From: Oscar Mateo
Same as the legacy-style ring->flush.
v2: The BSD invalidate bit still exists in GEN8! Add it for the VCS
rings (but still consolidate the blt and bsd ring flushes into one).
This was noticed by Brad Volkin.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c
From: Michel Thierry
Context switch (and execlist submission) should happen only when
other contexts are not active, otherwise pre-emption occurs.
To assure this, we place context switch requests in a queue and those
request are later consumed when the right context switch interrupt is
received
From: Oscar Mateo
A context backing object only makes sense for a given engine (because
it holds state data specific to that engine).
In legacy ringbuffer sumission mode, the only MI_SET_CONTEXT we really
perform is for the render engine, so one backing object is all we nee.
With Execlists, how
From: Oscar Mateo
Same as with the context, pinning to GGTT regardless is harmful (it
badly fragments the GGTT and can even exhaust it).
Unfortunately, this case is also more complex than the previous one
because we need to map and access the ringbuffer in several places
along the execbuffer pat
From: Oscar Mateo
v2: Warn and return if LRCs are not enabled.
v3: Grab the Execlists spinlock (noticed by Daniel Vetter).
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_debugfs.c | 73 +
drivers/gpu/drm/i915/intel_lrc.c| 6 ---
drivers/gpu/d
They match now.
Cc: Deepak S
Cc: Mika Kuoppala
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_sysfs.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index b15c8cee103b.
On Thu, Jul 10, 2014 at 01:16:22PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> This is useful for userspace utilities to verify and micromanaging the
> increase/decrease frequncy.
>
> Signed-off-by: Deepak S
> ---
> drivers/gpu/drm/i915/i915_sysfs.c | 18 +++---
> 1
On Sat, Jul 12, 2014 at 02:54:33PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> Adding chv specific fre/encode conversion.
>
> v2: Remove generic function and platform check (Daniel)
>
> Signed-off-by: Deepak S
When resubmitting patches into an existing patchbomb thread please
On Fri, Jul 11, 2014 at 05:42:48PM +0300, Mika Kuoppala wrote:
> deepa...@linux.intel.com writes:
>
> > From: Deepak S
> >
> > Reading RP1 for valleyview to help us enable "pm_rps" i-g-t testcase
> > execution.
> >
> > Signed-off-by: Deepak S
>
> Reviewed-by: Mika Kuoppala
>
> > ---
> > driv
From: Oscar Mateo
Execlists are indeed a brave new world with respect to workload
submission to the GPU.
In previous version of these series, I have tried to impact the
legacy ringbuffer submission path as little as possible (mostly,
passing the context around and using the correct ringbuffer wh
From: Oscar Mateo
Up until now, we have pinned every logical ring context backing object
during creation, and left it pinned until destruction. This made my life
easier, but it's a harmful thing to do, because we cause fragmentation
of the GGTT (and, eventually, we would run out of space).
This
From: Oscar Mateo
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 +++--
1 file changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 66e9244..4c62900 100644
--- a/driv
From: Oscar Mateo
The time has come, the Walrus said, to talk of many things.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9e3e38e..426e
From: Oscar Mateo
The batchbuffer that sets the render context state is submitted
in a different way, and from different places.
We needed to make both the render state preparation and free functions
outside accesible, and namespace accordingly. This mess is so that all
LR, LRC and Execlists fun
From: Oscar Mateo
This is what i915_gem_do_execbuffer calls when it wants to execute some
worload in an Execlists world.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.h| 6 ++
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +-
drivers/gpu/drm/i915/intel_lrc.c
From: Oscar Mateo
The backing objects and ringbuffers for contexts created via open
fd are actually empty until the user starts sending execbuffers to
them. At that point, we allocate & populate them. We do this because,
at create time, we really don't know which engine is going to be used
with t
From: Oscar Mateo
As we have said a couple of times by now, logical ring contexts have
their own ringbuffers: not only the backing pages, but the whole
management struct.
In a previous version of the series, this was achieved with two separate
patches:
drm/i915/bdw: Allocate ringbuffer backing o
From: Oscar Mateo
Each logical ring context has the tail pointer in the context object,
so update it before submission.
v2: New namespace.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i
From: Oscar Mateo
This is mostly for correctness so that we know we are running the LR
context correctly (this is, the PDPs are contained inside the context
object).
v2: Move the check to inside the enable PPGTT function. The switch
happens in two places: the legacy context switch (that we won't
From: Oscar Mateo
Now that we have the ability to allocate our own context backing objects
and we have multiplexed one of them per engine inside the context structs,
we can finally allocate and free them correctly.
Regarding the context size, reading the register to calculate the sizes
can work,
From: Oscar Mateo
Add theory of operation notes to intel_lrc.c and comments to externally
visible functions.
v2: Add notes on logical ring context creation.
v3: Use kerneldoc.
v4: Integrate it in the DocBook template.
Signed-off-by: Thomas Daniel (v1)
Signed-off-by: Oscar Mateo (v2, v3)
---
From: Oscar Mateo
If we reset a ring after a hang, we have to make sure that we clear
out all queued Execlists requests.
v2: The ring is, at this point, already being correctly re-programmed
for Execlists, and the hangcheck counters cleared.
v3: Daniel suggests to drop the "if (execlists)" beca
From: Oscar Mateo
We need to attend context switch interrupts from all rings. Also, fixed writing
IMR/IER and added HWSTAM at ring init time.
Notice that, if added to irq_enable_mask, the context switch interrupts would
be incorrectly masked out when the user interrupts are due to no users waiti
From: Oscar Mateo
In the current Execlists feeding mechanism, full preemption is not
supported yet: only lite-restores are allowed (this is: the GPU
simply samples a new tail pointer for the context currently in
execution).
But we have identified an scenario in which a full preemption occurs:
1)
From: Oscar Mateo
Dispatch_execbuffer's evil twin.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c| 28
drivers/gpu/drm/i915/intel_ringbuffer.h | 2 ++
2 files changed, 30 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drive
From: Oscar Mateo
For the most part, logical ring context objects are similar to hardware
contexts in that the backing object is meant to be opaque. There are
some exceptions where we need to poke certain offsets of the object for
initialization, updating the tail pointer or updating the PDPs.
F
From: Oscar Mateo
Very similar to the legacy add_request, only modified to account for
logical ringbuffer.
v2: Use MI_GLOBAL_GTT, as suggested by Brad Volkin.
v3: Unify render and non-render in the same function, as noticed by
Brad Volkin.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/
From: Oscar Mateo
These two functions make no sense in an Logical Ring Context & Execlists
world.
v2: We got rid of lrc_enabled and centralized everything in the sanitized
i915.enbale_execlists instead.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_gem_context.c | 9 +
1 fi
From: Oscar Mateo
As suggested by Daniel Vetter. The idea, in subsequent patches, is to
provide an alternative to these vfuncs for the Execlists submission
mechanism.
v2: Splitted into two and reordered to illustrate our intentions, instead
of showing it off. Also, remove the add_request vfunc a
From: Oscar Mateo
This is a hard one, since there is no direct hardware ring to
control when in Execlists.
We reuse intel_ring_idle here, but it should be fine as long
as i915_add_request does the ring thing.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c | 24 +++
From: Oscar Mateo
Up until recently, semaphores weren't enabled in BDW so we didn't care
about them. But then Rodrigo came and enabled them:
commit 521e62e49a42661a4ee0102644517dbe2f100a23
Author: Rodrigo Vivi
drm/i915: Enable semaphores on BDW
So now we have to explicitly disable
From: Ben Widawsky
This has turned out to be really handy in debug so far.
Update:
Since writing this patch, I've gotten similar code upstream for error
state. I've used it quite a bit in debugfs however, and I'd like to keep
it here at least until preemption is working.
Signed-off-by: Ben Wida
From: Oscar Mateo
Allocate and populate the default LRC for every ring, call
gen-specific init/cleanup, init/fini the command parser and
set the status page (now inside the LRC object). These are
things all engines/rings have in common.
Stopping the ring before cleanup and initializing the seqno
From: Oscar Mateo
No mistery here: the seqno is still retrieved from the engine's
HW status page (the one in the default context. For the moment,
I see no reason to worry about other context's HWS page).
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_lrc.c | 20
From: Oscar Mateo
Logical rings do not need most of the initialization their
legacy ringbuffer counterparts do: we just need the pipe
control object for the render ring, enable Execlists on the
hardware and a few workarounds.
v2: Squash with: "drm/i915: Extract pipe control fini & make
init outs
From: Oscar Mateo
The normal flip function places things in the ring in the legacy
way, so we either fix that or force MMIO flips always as we do in
this patch.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
drivers/gpu/drm/i915/intel_lrc.c | 3 ++-
2 files cha
From: Oscar Mateo
If we receive a storm of requests for the same context (see gem_storedw_loop_*)
we might end up iterating over too many elements in interrupt time, looking for
contexts to squash together. Instead, share the burden by giving more
intelligence to the queue function. At most, the
From: Oscar Mateo
On a previous iteration of this patch, I created an Execlists
version of __i915_add_request and asbtracted it away as a
vfunc. Daniel Vetter wondered then why that was needed:
"with the clean split in command submission I expect every
function to know wether it'll submit to an
From: Ben Widawsky
A context switch occurs by submitting a context descriptor to the
ExecList Submission Port. Given that we can now initialize a context,
it's possible to begin implementing the context switch by creating the
descriptor and submitting it to ELSP (actually two, since the ELSP
has
From: Thomas Daniel
Handle all context status events in the context status buffer on every
context switch interrupt. We only remove work from the execlist queue
after a context status buffer reports that it has completed and we only
attempt to schedule new contexts on interrupt when a previously
From: Oscar Mateo
Any given ringbuffer is unequivocally tied to one context and one engine.
By setting the appropriate pointers to them, the ringbuffer struct holds
all the infromation you might need to submit a workload for processing,
Execlists style.
Signed-off-by: Oscar Mateo
---
drivers/g
From: Oscar Mateo
For a description of this patchset, please check the previous cover letters:
[1], [2] and [3].
The main changes introduced in this v4 are:
- Do not abstract __i915_add_request away.
- Squash together the two emit request functions.
- Always pass the ringbuffer along, as the s
From: Oscar Mateo
GEN8 brings an expansion of the HW contexts: "Logical Ring Contexts".
These expanded contexts enable a number of new abilities, especially
"Execlists".
The macro is defined to off until we have things in place to hope to
work.
v2: Rename "advanced contexts" to the more correct
From: Oscar Mateo
Some legacy HW context code assumptions don't make sense for this new
submission method, so we will place this stuff in a separate file.
Note for reviewers: I've carefully considered the best name for this file
and this was my best option (other possibilities were intel_lr_cont
From: Oscar Mateo
For the moment this is just a placeholder, but it shows one of the
main differences between the good ol' HW contexts and the shiny
new Logical Ring Contexts: LR contexts allocate and free their
own backing objects. Another difference is that the allocation is
deferred (as the c
deepa...@linux.intel.com writes:
> From: Deepak S
>
> Adding chv specific fre/encode conversion.
>
> v2: Remove generic function and platform check (Daniel)
>
> Signed-off-by: Deepak S
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_pm.c | 78
> +
On Thu, Jul 10, 2014 at 10:15:11PM +0200, Daniel Vetter wrote:
> On Tue, Jul 01, 2014 at 06:33:50PM -0300, Paulo Zanoni wrote:
> > 2014-06-25 16:01 GMT-03:00 Imre Deak :
> > > This is a respin of the unmerged part of Daniel's runtime PM for DPMS
> > > patchset [1]. The original one also included a
Damien dodged this ...
Also run the script while at it.
v2: Don't just capture identifiers for pipe, but also expressions.
Signed-off-by: Daniel Vetter
---
lib/igt.cocci | 10 ++
tests/kms_cursor_crc.c | 2 +-
tests/kms_fbc_crc.c| 2 +-
tests/kms_fence_pin_le
From: Borun Fu
On VLV, after i915_pm_suspend display power wells are staying
power ungated. So, after initiating mem sleep "echo mem > /sys/power/state"
Display is staing D0 State. There might be better way/place to power gate
these wells. Also, we need to make sure that if wells are power gated
On Fri, 11 Jul 2014 14:32:57 +0530
Vandana Kannan wrote:
> For Gen < 8, set M2_N2 registers on every mode set. This is required to make
> sure M2_N2 registers are set during boot, resume from sleep for cross-
> checking the state. The register is set only if DRRS is supported.
>
> v2: Patch reba
deepa...@linux.intel.com writes:
> From: Deepak S
>
> Enabled PM interrupt programming for CHV. Re-using gen8 code and extending
> same for CHV.
>
> Signed-off-by: Deepak S
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_irq.c | 2 +-
> drivers/gpu/drm/i915/intel_pm.c | 4
>
deepa...@linux.intel.com writes:
> From: Deepak S
>
> We need mem_freq or cz clock for freq/opcode conversion
>
> Signed-off-by: Deepak S
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_reg.h | 6 ++
> drivers/gpu/drm/i915/intel_pm.c | 29 +++
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of ville.syrj...@linux.intel.com
> Sent: Saturday, June 28, 2014 12:04 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 10/40] drm/i915: Call encoder->post_disable() i
deepa...@linux.intel.com writes:
> From: Deepak S
>
> This is useful for userspace utilities to verify and micromanaging the
> increase/decrease frequncy.
>
> Signed-off-by: Deepak S
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_sysfs.c | 18 +++---
> 1 file changed
1 - 100 of 145 matches
Mail list logo
