This is *not* bisected, but the likely regression is
commit c35614380d5c956bfda20eab2755b2f5a7d6f1e7
Author: Zhao Yakui
Date: Tue Nov 24 09:48:48 2009 +0800
drm/i915: Don't set up the TV port if it isn't in the BIOS table.
The commit does not check for all TV device types that might be pr
On Fri, 28 Mar 2014, Christoph Jaeger wrote:
> __FUNCTION__ is gcc specific; use __func__ instead.
I acknowledge the patch is correct and functionally the same as
before. However the correct fix would be to drop __FUNCTION__ and the
corresponding "%s: " altogether as DRM_DEBUG_KMS includes printi
On Thu, Mar 27, 2014 at 11:39:36AM -0300, Paulo Zanoni wrote:
> 2014-03-18 17:29 GMT-03:00 Ben Widawsky :
> > On Fri, Mar 07, 2014 at 08:10:30PM -0300, Paulo Zanoni wrote:
> >> From: Paulo Zanoni
> >>
> >> On the preinstall stage we should just disable all the interrupts, but
> >> we currently ena
From: Pradeep Bhat
This patch computes and stored 2nd M/N/TU for switching to different
refresh rate dynamically. PIPECONF_EDP_RR_MODE_SWITCH bit helps toggle
between alternate refresh rates programmed in 2nd M/N/TU registers.
v2: Daniel's review comments
Computing M2/N2 in compute_config and st
For Broadwell, there is one instance of Transcoder MN values per transcoder.
For dynamic switching between multiple refreshr rates, M/N values may be
reprogrammed on the fly. Link N programming triggers update of all data and
link M & N registers and the new M/N values will be used in the next fram
Dynamic Refresh Rate Switching (DRRS) is a power conservation feature which
enables swtiching between low and high refresh rates based on the usage
scenario. This feature is applciable for internal eDP panel. Indication that
the panel supports DRRS is given by the panel EDID, whic
Adding support to detect display idleness by tracking page flip from
user space. Switch to low refresh rate is triggered after 2 seconds of
idleness. The delay is configurable. If there is a page flip or call to
update the plane, then high refresh rate is applied.
The feature is not used in dual-di
From: Pradeep Bhat
This patch and finds out the lowest refresh rate supported for the resolution
same as the fixed_mode.
It also checks the VBT fields to see if panel supports seamless DRRS or not.
Based on above data it marks whether eDP panel supports seamless DRRS or not.
This information is n
From: Pradeep Bhat
This patch reads the DRRS support and Mode type from VBT fields.
The read information will be stored in VBT struct during BIOS
parsing. The above functionality is needed for decision making
whether DRRS feature is supported in i915 driver for eDP panels.
This information helps
Definition of VLV RR switch bit and corresponding toggling in
set_drrs function.
Signed-off-by: Vandana Kannan
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dp.c | 10 --
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git
Previous series revisions & explanation at [1], [2], and [3]
This version of the patch series focuses on isolating the DRM core changes from
individual driver changes to (hopefully) make this a bit easier to merge. New
plane and crtc initialization functions have been added to allow drivers to
mi
Ensure that existing driver loops over all planes do not change behavior
when we begin adding new types of planes (primary and cursor) to the DRM
plane list in future patches.
v2: Switch to using drm_for_each_legacy_plane()
Cc: Intel Graphics Development
Signed-off-by: Matt Roper
---
drivers/g
On Thu, Mar 27, 2014 at 02:58:01PM -0700, Kenneth Graunke wrote:
> On 03/27/2014 11:43 AM, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > There is some thought that the data from the performance counters enabled
> > via OACONTROL should only be available to the process that enabl
On Thu, Mar 27, 2014 at 02:47:03PM -0700, Kenneth Graunke wrote:
> Does any code actually rely on the tables being sorted?
Not today. The idea was to make it easier to move to an algorithm that does
in the future. For example, I thought binary search might be an easy win.
>
> I didn't see any ea
On Thu, Mar 27, 2014 at 01:16:26PM -0700, Daniel Vetter wrote:
> On Thu, Mar 27, 2014 at 4:57 PM, Volkin, Bradley D
> wrote:
> > On Thu, Mar 27, 2014 at 12:57:21AM -0700, Daniel Vetter wrote:
> >> Another one that blows is igt/gen7_forcewake_mt. Not sure yet whether it's
> >> an issue with the tes
On 03/27/2014 03:44 PM, Daniel Vetter wrote:
> On Thu, Mar 27, 2014 at 10:34 PM, Kenneth Graunke
> wrote:
>> Why are we parsing batches with I915_EXEC_SECURE at all? Secure batches
>> are only issued from trusted code which is guaranteed to be running as
>> root. I don't see any benefit to scan
On Thu, Mar 27, 2014 at 10:34 PM, Kenneth Graunke wrote:
> Why are we parsing batches with I915_EXEC_SECURE at all? Secure batches
> are only issued from trusted code which is guaranteed to be running as
> root. I don't see any benefit to scanning those batches, and there's
> definitely overhead
On Thu, Mar 27, 2014 at 03:28:26PM +, arun.siluv...@linux.intel.com wrote:
> From: "Siluvery, Arun"
>
> This patch series adds a new ioctl to resize a gem object.
I'm tired, but off the top of my head, I think you can do away with the
magic extension to create_ioctl. If we allow any one to f
On 03/27/2014 11:43 AM, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> There is some thought that the data from the performance counters enabled
> via OACONTROL should only be available to the process that enabled counting.
> To limit snooping, require that any batch buffer which sets
On 03/27/2014 11:43 AM, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> This brings the code a little more in line with kernel coding style.
>
> Signed-off-by: Brad Volkin
> ---
> drivers/gpu/drm/i915/i915_cmd_parser.c | 136
> +
> 1 file changed, 71
On 03/27/2014 11:43 AM, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> As suggested during review, this makes it much more obvious
> when the tables are not sorted.
>
> Cc: Jani Nikula
> Signed-off-by: Brad Volkin
> ---
> drivers/gpu/drm/i915/i915_cmd_parser.c | 31
On 03/27/2014 01:16 PM, Daniel Vetter wrote:
> On Thu, Mar 27, 2014 at 4:57 PM, Volkin, Bradley D
> wrote:
>> On Thu, Mar 27, 2014 at 12:57:21AM -0700, Daniel Vetter wrote:
>>> Another one that blows is igt/gen7_forcewake_mt. Not sure yet whether it's
>>> an issue with the test or the checker:
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Salutations,
I've been trying to get zaphod mode to work on an Intel Ironlake laptop
w/ Arch Linux 64 bit; I'm a bit confused. Below is my xorg configuration:
- -
Section "Device"
Identifier "intel0"
Driver "intel"
BusID "PCI:
On Thu, Mar 27, 2014 at 4:57 PM, Volkin, Bradley D
wrote:
> On Thu, Mar 27, 2014 at 12:57:21AM -0700, Daniel Vetter wrote:
>> Another one that blows is igt/gen7_forcewake_mt. Not sure yet whether it's
>> an issue with the test or the checker:
>>
>> https://bugs.freedesktop.org/show_bug.cgi?id=7667
This makes HDMI testers happier on VLV platforms. It may be that we
need it for any non-SVO platform, but I don't have any tests to back
that up, so I'm leaving other pre-ILK platforms alone for now.
Tested-by: "Clint Taylor "
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c
From: Brad Volkin
Signed-off-by: Brad Volkin
---
tests/gem_exec_parse.c | 48
1 file changed, 48 insertions(+)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 34d097d..853eb57 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/ge
From: Brad Volkin
As suggested during review, this makes it much more obvious
when the tables are not sorted.
Cc: Jani Nikula
Signed-off-by: Brad Volkin
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff --g
From: Brad Volkin
Patches 1 and 2 do some cleanups suggested as part of the review process.
Patch 3 continues the OACONTROL handling fixes from the other day.
I think patches 1 and 2 are valuable on their own. I think the need/benefit
for the tracking provided by patch 3 is somewhat unclear. Per
From: Brad Volkin
There is some thought that the data from the performance counters enabled
via OACONTROL should only be available to the process that enabled counting.
To limit snooping, require that any batch buffer which sets OACONTROL to a
non-zero value also sets it back to 0 before the end
From: Brad Volkin
This brings the code a little more in line with kernel coding style.
Signed-off-by: Brad Volkin
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 136 +
1 file changed, 71 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_pa
From: Sagar Kamble
v2: Added description for "src-color" and "constant-alpha" property.
[Review by Laurent Pinchart]
v3: Fixed typos. [Review by David Herrmann]
v4: Additional formatting and modified description. [Review by David Herrmann]
Cc: r...@landley.net
Cc: airl...@redhat.com
Cc: da
I already got a fair review comment from Brad Volkin on this: he proposes to do
this instead
struct i915_hw_context {
struct i915_address_space *vm;
struct {
struct drm_i915_gem_object *ctx_obj;
struct intel_r
From: Oscar Mateo
Writing the tail pointer for the context ringbuffer is quite similar to
the legacy ringbuffers. The primary difference is that each context has
the ringbuffer pointers in the context object.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_lrc.c | 15 +++
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 5164f84..bf03
From: Oscar Mateo
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_debugfs.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 226b630..c52108d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
I already got a review from Brad Volkin on this that I agree with: change the
"write_tail" vfunc name to something different, like "submit". If no one
disagrees, I´ll change it in the next submission.
> -Original Message-
> From: Mateo Lozano, Oscar
> Sent: Thursday, March 27, 2014 6:00
From: Ben Widawsky
Logical ring contexts do not need most of the ring init: we just need
the pipe control object for the render ring and a few other things
(some of which will be added later).
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 42 +
From: Oscar Mateo
Each logical ring context has the PDPs in the context object, so update
them before submission. This should work both for Aliasing PPGTT
(nothing will be changed) and Full PPGTT.
Also, don't write PDP in the legacy way when using logical ring contexts
(this is mostly for correc
From: Thomas Daniel
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 wai
From: Thomas Daniel
BSPEC says: SW must set Force Wakeup bit to prevent GT from
entering C6 while ELSP writes are in progress.
Signed-off-by: Thomas Daniel
Acked-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_lrc.c | 15 +++
2 files changed,
From: Oscar Mateo
Consisting on 12 bits with the filepriv ID, 5 bits with the context
ID and 3 bits with the ring ID.
Note: this changes the ABI (only 4096 file descriptors are now allowed,
with 8 contexts per-fd) and will break some IGT tests (those that open
a big number of fds). If required,
From: Oscar Mateo
Since context IDs are not globally unique anymore (they are only unique
for a given file descriptor), we can use the new file_priv ID in
combination with the context ID to unequivocally refer to a context.
The ID 0 remains to be used internally by i915 (meaning no file_priv).
From: Oscar Mateo
Following the logic behind the previous patch, the ringbuffers and the rings
belong in different structs. We keep the relationship between the two via the
default_ringbuf living inside each ring/engine.
This commit should not introduce functional changes (unless I made an error
From: Oscar Mateo
This patch should have no functional changes.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_gem_context.c | 37 +++--
1 file changed, 12 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/
From: Oscar Mateo
The write tail function is a very special place for execlists: since
all access to the ring is mediated through requests (thanks to
Chris Wilson's "Write RING_TAIL once per-request" for that) and all
requests end up with a write tail, this is the place we are going to
use to sub
From: Oscar Mateo
Continue the refactoring: do not init or clean a "ringbuffer" when you
actually mean a "ring".
Again, no functional changes.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_dma.c | 6 +++---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i
From: Oscar Mateo
We are going to reuse it during logical ring context creation.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem_context.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i91
From: Ben Widawsky
for_each_ring() iterates over all rings supported by the hardware, not
just those which have been initialized as in for_each_active_ring()
Signed-off-by: Ben Widawsky
Acked-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.h | 11 +++
1 file changed, 11 insertions(+
From: Ben Widawsky
There should be no functional changes.
Signed-off-by: Ben Widawsky
v2: Multiple rebases.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 73 +
1 file changed, 46 insertions(+), 27 deletions(-)
diff --git a/drivers/
From: Ben Widawsky
It's beneficial to be able to get a name, base, and id before we've
actually initialized the rings. This ability was effectively destroyed
in the ringbuffer fire which Daniel started.
With the simple early init function, that ability is restored.
Signed-off-by: Ben Widawsky
From: Oscar Mateo
Some legacy HW context and ringbuffer 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 wer
From: Ben Widawsky
This modifies the init code to try to start logical ring contexts when
possible, and fall back to legacy ringbuffers when not.
Most importantly, things make things easy if we do the context creation
before ringbuffer initialization. Upcoming patches will make it clearer
why th
From: Ben Widawsky
The name "active" was recommended by Chris.
With the ordering change of how we initialize things, it is desirable to
be able to address each ring, whether initialized or not.
Cc: Chris Wilson
Signed-off-by: Ben Widawsky
v2: Several rebases.
Signed-off-by: Oscar Mateo
---
From: Oscar Mateo
Hi all,
This patch series implement execlists for GEN8+. Before continuing, it is
important to mention that I might have taken upon myself to assemble the series
and rewrite it for upstreaming, but many people have worked on this series
before me. Namely:
Ben Widawsky (benj
From: Ben Widawsky
GEN8 brings an expansion of the HW contexts: "Logical Ring Contexts".
These expanded contexts enable a number of new abilities, especially
"Execlists".
In dev_priv, lrc_enabled will reflect the state of whether or not we've
actually properly initialized these new contexts. Thi
From: Oscar Mateo
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_debugfs.c | 65 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_lrc.c | 8 +
drivers/gpu/drm/i915/i915_reg.h | 7
4 files changed, 74 inserti
From: Oscar Mateo
We need it (at least) to properly update the last retired head.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_gem.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e3c
From: Oscar Mateo
Plumb ring->write_tail with a context argument, which in turn
means plumbing ring->add_request, which in turn, etc The
idea is that, by the time we would usually update the tail
register, we know which context we are working with and,
therefore, we can send it to the execlis
From: Ben Widawsky
Signed-off-by: Ben Widawsky
v2: Set Replay Mode to 0 per BSpec
Michel Thierry
v3: Several rebases.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_lrc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_lr
From: Oscar Mateo
As a separate function, we can decide wether we want a context with real
information about which engine it uses, or a "blank" context for which to
make a deferred decision.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_lrc.c | 175 ++
From: Oscar Mateo
This commit changes the ABI, so it is provided separately so that it can be
dropped by the maintainer is so he wishes.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_lrc.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_lrc.c b/dri
From: Oscar Mateo
Thanks to the previous functions and intel_ringbuffer_get(), every function
that needs to be context-aware gets the ringbuffer from the appropriate place
(be it the context or the engine itself). Others (either pre-GEN8 or that
clearly manipulate the rings's default ringbuffer)
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
On execbuffer, either...:
A) there is not standalone context (and we error: user provided ctx id is
invalid).
B) the standalone context is the one we are looking for (and we return it).
C) the standalone context is blank (and we populate and return it).
D) one of the dependent
From: Oscar Mateo
For the moment, this is simple and works allright. When we start
having a lot of contexts, this is going to become problematic.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_lrc.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --
From: Oscar Mateo
Since the ringbuffer can live in the ring (pre-GEN8) or in the context (GEN8+)
we need functions that are aware of this. After this commit and some of the
previous, this new ringbuffer functions finally are:
intel_ringbuffer_get
intel_ringbuffer_begin
intel_ringbuffer_cacheline
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
Users can create contexts either implicitly by opening an fd, or
explicitly by the context create ioctl. In either case, this context
needs to be corectly populated with "advanced" stuff. For the moment
we consider all the user contexts to be of the render type (probably
true fo
From: Ben Widawsky
For the most part, logical rinf 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.
From: Oscar Mateo
The "__" name is too confusing, specially given the refactoring patch
that comes soon with new ringbuffer management functions.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/intel_display.c| 10 +-
drivers/gpu
From: Ben Widawsky
There are a few big differences between context init and fini with the
previous implementation of hardware contexts. One of them is
demonstrated in this patch: we must do a context initialization for
every ring.
The patch will still fail at context setup, and therefore won't b
From: Ben Widawsky
With our setup in previous patches, we've allocated one default context
per ring. Now, each of those contexts holds a pointer to the default
ringbuffers and makes its own allocation of the backing objects.
To reiterate the TODO in the patch: the ringbuffer objects are in the
C
From: Ben Widawsky
The status page with logical ring contexts is included already in the
context object. Update the init and cleanup functions to reflect that. The
status page is offset 0 from the context object when using logical ring
contexts.
Signed-off-by: Ben Widawsky
v2: Several rebases.
From: Ben Widawsky
Semaphores have changed, so let's not submit useless commands to the
ring.
Signed-off-by: Ben Widawsky
v2: Several rebases.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
From: Oscar Mateo
Explain i915_lrc.c with some execlists notes
Signed-off-by: Thomas Daniel
v2: Add notes on logical ring context creation.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_lrc.c | 78 +
1 file changed, 78 insertions(+)
diff -
From: Oscar Mateo
Even though we have one Hardware Status Page per context, we are still
managing the seqnos per engine. Therefore, the sequence number must be
written to a consistent place for all contexts: one of the global
default contexts.
Signed-off-by: Thomas Daniel
v2: Since get_seqno a
From: Oscar Mateo
Finally, start queueing request on write_tail. Also, remove remaining
legacy context switches.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_gem.c| 9 ++---
drivers/gpu/drm/i915/i915_gem_context.c| 10 ++
drivers/gpu/drm/i915/i915_gem_e
From: Oscar Mateo
Since we cannot tell apart which specific context the user refers too,
get stats from all the per-engine cotexts with the same ID.
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/intel_uncore.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/g
From: Oscar Mateo
>From here on, we define a stand-alone context as the first context with
a given ID to be created for a new fd or a new context create ioctl. This
is the one we can easily find using integer ID management. On the other
hand, dependent contexts are subsequently created with the s
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: Oscar Mateo
Now that our global default contexts are correctly created and we have
finished the refactoring, it's time to allow other kind of contexts.
As we said earlier, logical ring contexts created by the user have their
own ringbuffer: not only the backing pages, but the whole managem
[snip]
On Thu, Mar 27, 2014 at 12:57:21AM -0700, Daniel Vetter wrote:
> Another one that blows is igt/gen7_forcewake_mt. Not sure yet whether it's
> an issue with the test or the checker:
>
> https://bugs.freedesktop.org/show_bug.cgi?id=76670
For this one, the parser rejects an MI_STORE_REGISTER
Besides D0 device state we need the proper power wells to be on on
some platforms, so get the port power domain reference instead of an RPM
reference.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_dp.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --
Instead of reading out the CD clock rate from the HW at each modeset, do
this only during driver init and resume and use the cached value during
modeset. This moves things towards a state where the sw and hw side
setup is separated. It's also needed for VLV RPM, where we don't put
device into D0 st
These are dependency patches for enabling RPM on VLV. I'm sending them
in advance because they could be applied independently and the second
one might fix some eDP issues.
Imre Deak (2):
drm/i915: vlv: cache current CD clock rate
drm/i915: vlv: get power domain for eDP vdd
drivers/gpu/drm/i9
From: "Siluvery, Arun"
This patch adds data structure to handle gem object resize.
One such usecase where it is required is mipmaps; you cannot know
whether higher level mipmaps are required at the time of creating them,
so it is best to defer memory allocation for higher levels if possible.
GEM
From: "Siluvery, Arun"
GEM object size is fixed and it is tightly coupled in i915.
To make it resizeable a lazy allocation approach is used.
Out of the total size of object, backing store is allocated partially.
The scatter/gather entries for the remaining pages point to scratch page.
A stop mar
From: "Siluvery, Arun"
This patch adds a new ioctl to resize gem object. If the object is created
as resizeable scatter/gather table contains dummy entries that point to a
scratch page. A marker denotes end of real pages.
This ioctl creates new pages and updates the dummy entries in the sg table
From: "Siluvery, Arun"
Add new case to test gem object resize implementation.
The current test creates two objects, one of them is resizeable.
Before resize it is filled with data from source object using GPU blt.
Object is resized and then filled the new space with different set of data.
The con
From: "Siluvery, Arun"
This patch series adds a new ioctl to resize a gem object.
This is required in cases where the actual size of the object is not known
at the time of creation and there is chance that we may need more space later.
A typical use case is memory allocation for mipmaps where y
On Thu, Mar 27, 2014 at 08:21:29PM +0530, Deepak S wrote:
>On VLV, gen6_enable_rps_interrupts is used to enable turbo interrutpts.
>I think we need to extend gen6_rps_pm_mask to valleyview also?
Check patch 4/3.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
On Thursday 27 March 2014 02:36 PM, Chris Wilson wrote:
When trying to determine whether RPS is working as intended, more
information is better. In particular, what interrupts are being
generated and the various thresholds for generating them.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/
On Thursday 27 March 2014 01:54 PM, Chris Wilson wrote:
The speculation is that we can conserve more power by masking off the
interrupts at source (PMINTRMSK) rather than filtering them by the
up/down thresholds (RPINTLIM).
Signed-off-by: Chris Wilson
Cc: Deepak S
Cc: Ville Syrjälä
---
dri
2014-03-18 17:43 GMT-03:00 Ben Widawsky :
> On Fri, Mar 07, 2014 at 08:10:34PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> So we can merge all the common code from postinstall and uninstall.
>>
>> Signed-off-by: Paulo Zanoni
>> ---
>> drivers/gpu/drm/i915/i915_irq.c | 26 +++--
2014-03-18 17:29 GMT-03:00 Ben Widawsky :
> On Fri, Mar 07, 2014 at 08:10:30PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> On the preinstall stage we should just disable all the interrupts, but
>> we currently enable all the south display interrupts due to the way we
>> touch SDEIER at
On Thu, Mar 27, 2014 at 12:01:11PM +, Chris Wilson wrote:
> If we hit a vblank and see that have a pageflip queue but not yet
> processed, ensure that the GPU is running at maximum in order to clear
> the backlog. Pageflips are only queued for the following vblank, if we
> miss it, there will b
On Thu, Mar 27, 2014 at 01:03:31PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 27, 2014 at 09:37:36AM +, Chris Wilson wrote:
> > On Thu, Mar 27, 2014 at 11:08:45AM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > So relax the checks a bit, and apply the single-link DVI dotclock limit
> > >
On Thu, Mar 27, 2014 at 09:06:14AM +, Chris Wilson wrote:
> When trying to determine whether RPS is working as intended, more
> information is better. In particular, what interrupts are being
> generated and the various thresholds for generating them.
>
> Signed-off-by: Chris Wilson
Queued f
2014-03-19 14:50 GMT-03:00 Ben Widawsky :
> On Wed, Mar 19, 2014 at 09:28:32AM +0100, Daniel Vetter wrote:
>> On Tue, Mar 18, 2014 at 11:20:09AM -0700, Ben Widawsky wrote:
>> > On Fri, Mar 07, 2014 at 08:10:24PM -0300, Paulo Zanoni wrote:
>> > > From: Paulo Zanoni
>> > >
>> > > Instead of trying t
At Thu, 27 Mar 2014 07:41:41 +0100,
Takashi Iwai wrote:
>
> At Wed, 26 Mar 2014 20:10:09 +0100,
> Daniel Vetter wrote:
> >
> > It apparently blows up on some machines. This functionally reverts
> >
> > commit 828c79087cec61eaf4c76bb32c222fbe35ac3930
> > Author: Ben Widawsky
> > Date: Wed Oct
1 - 100 of 129 matches
Mail list logo
