Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 367/367 3
From: Akash Goel
Updates in forcewake range for Render/Media/Common
power wells for Gen9.
Signed-off-by: Akash Goel
Signed-off-by: Zhe Wang
---
drivers/gpu/drm/i915/intel_uncore.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncor
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 367/367
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 367/367
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 367/367
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 367/367
From: Chris Wilson
Sometimes we wish to tweak how an individual context behaves. Since we
always create a context for every filp, this means that individual
processes can fine tune their behaviour even if they do not explicitly
create a context.
The first example parameter here is to enable mult
From: Zhipeng Gong
This will let userland only try to use the new ring
when the appropriate kernel is present
Signed-off-by: Zhipeng Gong
Signed-off-by: Rodrigo Vivi
Reviewed--by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
include/uapi/drm/i915_drm.h | 1 +
2 files changed
From: Chris Wilson
Previously, this was restricted to only operate on bound objects - to
make pointer access through the GTT to the object coherent with writes
to and from the GPU. A second usecase is drm_intel_bo_wait_rendering()
which at present does not function unless the object also happens
Similar to:
commit 02c9f7e3cfe76a7f54ef03438c36aade86cc1c8b
Author: Kenneth Graunke
Date: Mon Jan 27 14:20:16 2014 -0800
drm/i915: Add the WaCsStallBeforeStateCacheInvalidate:bdw workaround.
On Broadwell, any PIPE_CONTROL with the "State Cache Invalidate" bit set
must be preceded
From: Chris Wilson
This will allow us to set per-file, or even per-context, periods in the
future.
Signed-off-by: Chris Wilson
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
drivers/gpu/drm/i915/i915_gem.c | 3 ++-
drivers/gpu/drm/i915/i915_gem_cont
To be used for a Workaroud. Similar to:
commit 884ceacee308f0e4616d0c933518af2639f7b1d8
Author: Kenneth Graunke
Date: Sat Jun 28 02:04:20 2014 +0300
drm/i915: Refactor Broadwell PIPE_CONTROL emission into a helper.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_lrc.c | 35 ++
This is another drm-intel-collector updated notice:
http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector
Here goes the update list in order for better reviewers assignment:
Patch drm/i915: Specify bsd rings through exec flag - Reviewed
Patch drm/i915: add I915_PARAM_H
From: Zhipeng Gong
On Broadwell GT3 we have 2 Video Command Streamers (VCS), but userspace
has no control when using VCS1 or VCS2. This patch introduces a mechanism
to avoid the default ping-pong mode and use one specific ring through
execution flag.
v2: fix whitespace (Rodrigo)
v3: remove incor
both deflate and inflate was listed to -collector but got a hard conflict.
If it is still needed please rebase it over -nightly
On Fri, Oct 31, 2014 at 4:33 AM, Chris Wilson wrote:
> Recent kernels compress the active objects using zlib + ascii85
> encoding. This adapts the tool to decompress tho
On Mon, Nov 24, 2014 at 09:57:32PM +0100, Daniel Vetter wrote:
> I looked at this and it gets ugly fast. Given that we seem to have a quite
> substantial false-positive (found one more by just reading recent bug
> spam) rate and haven't enabled this on gen5+ I've decided to just merge
> this one he
This still crashes for me:
kernel: [ cut here ]
kernel: WARNING: at drivers/gpu/drm/drm_modeset_lock.c:219
drm_modeset_legacy_acquire_ctx+0x38/0x40()
kernel: Modules linked in:
kernel: CPU: 0 PID: 586 Comm: Xorg Not tainted 3.10.33-02454-g1c4eeb3-dirty
#196
kernel: [] (unwi
With the oops fix:
Reviewed-by: Jasper St. Pierre
Tested-by: Jasper St. Pierre
On Mon, Nov 24, 2014 at 12:42 PM, Daniel Vetter
wrote:
> Especially with legacy cursor ioctls existing userspace assumes that
> you can pile up lots of updates in one go. The super-proper way to
> support this woul
On Wed, Nov 05, 2014 at 10:56:06AM +0100, Daniel Vetter wrote:
> On Wed, Nov 05, 2014 at 08:35:01AM +, Chris Wilson wrote:
> > On Tue, Nov 04, 2014 at 03:52:22PM +0100, Daniel Vetter wrote:
> > > There's quite a few bug reports with error states where the error
> > > reasons makes just about no
The crc code doesn't handle anything really that could drop the
register state (by design so that we have less complexity). Which
means userspace may only start crc capture once the pipe is fully set
up.
With an i-g-t patch this will be the case, but there's still the
problem that this results in
Especially with legacy cursor ioctls existing userspace assumes that
you can pile up lots of updates in one go. The super-proper way to
support this would be a special commit mode which overwrites the last
update. But getting there will be quite a bit of work.
Meanwhile do what pretty much all the
On Mon, Nov 24, 2014 at 6:14 PM, Daniel, Thomas wrote:
>> This patch here scored a regression (leak in the module unload path), please
>> address it asap. Deadline for regressions should be 1 week, then I'll just
>> drop
>> the patch or apply the revert. That includes review and everything.
>>
>>
On Mon, Nov 24, 2014 at 4:36 PM, Damien Lespiau
wrote:
> On Mon, Nov 24, 2014 at 04:23:36PM +0100, Daniel Vetter wrote:
>> The crc code doesn't handle anything really that could drop the
>> register state (by design so that we have less complexity). Which
>> means userspace may only start crc capt
From: Gustavo Padovan
We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.
v2 (by Matt): Use new stereo doubling function (suggested by Ville)
v3 (by Matt):
- Add missing kerneldoc (Daniel)
- Use drm_mode_copy() (Jani)
v4 (by Matt):
- Drop stereo d
From: Gustavo Padovan
Merge it into the plane update_plane() callback and make other
users use the update_plane() functions instead.
The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj()
so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane()
and merge both
The 'prepare' step for all types of planes are pretty similar;
consolidate the three 'prepare' functions into a single function. This
paves the way for future integration with the atomic plane handlers.
Note that we pull the 'wait for pending flips' functionality out of the
primary plane's prepar
Our .update_plane() handlers do the same check/prepare/commit/cleanup
steps regardless of plane type. Consolidate them all into a single
function that calls check/commit through a vtable.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 113 ++
Primary and sprite planes have already been refactored to include a
'prepare' step which handles all the commit-time operations that could
fail (i.e., pinning buffers and such). Refactor the cursor commit in a
similar manner.
For simplicity and consistency with other plane types, we also switch t
Another iteration of the i915 display refactoring work, with a few additional
patches added to the end which should help simplify the transition to the
atomic plane helpers.
The previous version of this patch series was posted here:
http://lists.freedesktop.org/archives/intel-gfx/2014-November/0
From: Gustavo Padovan
After some refactor intel_primary_plane_setplane() does the same
as intel_pipe_set_base() so we can get rid of it and replace the calls
with intel_primary_plane_setplane().
v2: take Ville's comments:
- get the right arguments for update_plane()
- use drm_crt
If we extend the commit_plane handlers for each plane type to be able to
handle fb=0, then we can easily implement plane disable via the
update_plane handler. The cursor plane already works this way, and this
is the direction we need to go to integrate with the atomic plane
handler. We can now ki
Reviewed-by: Bob Paauwe
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 34 +-
drivers/gpu/drm/i915/intel_drv.h | 3 +--
drivers/gpu/drm/i915/intel_sprite.c | 16
3 files changed, 26 insertions(+), 27 deletions(-)
diff
All plane update functions need to unpin the old framebuffer when
flipping to a new one. Pull this logic into a separate function to ease
the integration with atomic plane helpers.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 57 ++--
driv
On Mon, Nov 24, 2014 at 5:56 PM, Egbert Eich wrote:
> Before testing if the panel VDD is enabled on eDP cancel any pending
> disable worker. This makes sure the worker doesn't fire when we expect
> VDD to be enabled.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=86201
>
> Signed-off-by: Egbert
Especially with legacy cursor ioctls existing userspace assumes that
you can pile up lots of updates in one go. The super-proper way to
support this would be a special commit mode which overwrites the last
update. But getting there will be quite a bit of work.
Meanwhile do what pretty much all the
From: John Harrison
The aim is to replace seqno values with request structures. A step along the way
is to switch to using the PLR in preference to the OLS. That requires the PLR to
only be valid when and only when the OLS is also valid. I.e., the two must be
kept in lock step. Then, code which w
Ville Syrjälä writes:
> On Mon, Nov 24, 2014 at 07:32:49PM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 24, 2014 at 05:56:20PM +0100, Egbert Eich wrote:
> > > Before testing if the panel VDD is enabled on eDP cancel any pending
> > > disable worker. This makes sure the worker doesn't fire when w
From: John Harrison
Convert the throttle code to use the request structure rather than extracting a
ring/seqno pair from it and using those. This is in preparation for
__wait_seqno() becoming __wait_request().
For: VIZ-4377
Signed-off-by: John Harrison
Reviewed-by: Thomas Daniel
---
drivers/
From: John Harrison
The OLS value is now obsolete. Exactly the same value is guarateed to be always
available as PLR->seqno. Thus it is safe to remove the OLS completely. And also
to rename the PLR to OLR to keep the 'outstanding lazy ...' naming convention
valid.
For: VIZ-4377
Signed-off-by: Jo
From: John Harrison
Added a hook to the ring noftification code to process request completion. This
means that there is no longer a need to explicitly process request completions
every time a request object is tested. Instead, the test code simply becomes
'return req->completed'. Obviously, this
From: John Harrison
Updated the trace_irq code to use requests instead of seqnos. This includes
reference counting the request object to ensure it sticks around when required.
Note that getting access to the reference counting functions means moving the
inline i915_trace_irq_get() function from i
From: John Harrison
For debugging purposes, it is useful to be able to uniquely identify a given
request structure as it works its way through the system. This becomes
especially tricky once the seqno value is lazily allocated as then the request
has nothing but its pointer to identify it for muc
From: John Harrison
Updated the _check_olr() function to actually take a request object and compare
it to the OLR rather than extracting seqnos and comparing those.
Note that there is one use case where the request object being processed is no
longer available at that point in the call stack. He
From: John Harrison
The ring member of the object structure was always updated with the
last_read_seqno member. Thus with the conversion to last_read_req, obj->ring is
now a direct copy of obj->last_read_req->ring. This makes it somewhat redundant
and potentially misleading (especially as there w
From: John Harrison
Added reference counting of the request structure around __wait_seqno() calls.
This is a precursor to updating the wait code itself to take the request rather
than a seqno. At that point, it would be a Bad Idea for a request object to be
retired and freed while the wait code i
From: John Harrison
All the code above is now using requests not seqnos so it is possible to convert
the trace functions across. Note that rather than get into problematic reference
counting issues, the trace code only saves the seqno and ring values from the
request structure not the structure p
From: John Harrison
The next patches in the series convert some display related seqno usage to
request structure usage. However, the request dereference introduced must be
done from interrupt context. As the dereference potentially involves freeing the
request structure and thus calling lots of n
From: John Harrison
It makes a lot more sense (and makes future seqno -> request conversion patches
simpler) to fill in the 'ring' field of the request structure at the point of
creation rather than submission. Given that the request structure is assigned by
ring specific code and thus is locked
From: John Harrison
The plan is to use request structures everywhere that seqno values were
previously used. This means saving pointers to structures in places that used to
be simple integers. In turn, that means that the target structure now needs much
more stringent lifetime tracking. That is,
From: John Harrison
More seqno value to request structure conversions. Note, this change temporarily
moves the 'get_seqno()' call inside ring_idle() but this will disappear again in
a later patch when i915_seqno_passed() itself is converted.
For: VIZ-4377
Signed-off-by: John Harrison
Reviewed-b
From: John Harrison
There is no longer any need to retrieve a seqno value from an i915_add_request()
call. The calling code already knows which request structure is being processed
(it can only be ring->OLR). And as the request itself is now used in preference
to the basic seqno value, the latter
From: John Harrison
Now that all code above is using request structures instead of seqno values, it
is possible to convert __wait_seqno() itself. Internally, it is still calling
i915_seqno_passed(), this will be updated later in the series. This step is just
changing the parameter list and funct
From: John Harrison
The request completion test no longer chains on to the request completion
processing code. Thus it no longer needs to pass a 'lazy coherency' flag through
to the seqno query call. Hence that parameter can be removed.
For: VIZ-4377
Signed-off-by: John Harrison
Reviewed-by: Th
From: John Harrison
Almost everywhere that caled i915_seqno_passed() was really asking 'has the
given seqno popped out of the hardware yet?'. Thus it had to query the current
hardware seqno and then do a signed delta comparison (which copes with wrapping
around zero but not with seqno values more
From: John Harrison
Converted 'last_flip_req' to be an actual request rather than a seqno value as
part of the on going seqno to request changes. This includes reference counting
the request being saved away to ensure it can not be retired and freed while the
overlay code is still waiting on it.
From: John Harrison
Continuing the removal of seqno based operations - updated the request
completion query to not simply chain on to i915_seqno_passed(). Instead, it now
returns a pre-cached completion flag in the fast case. In the slow case it reads
the hardware seqno and, only if it has moved
From: John Harrison
Converted the flip_queued_seqno value to be a request structure as part of the
on going seqno to request changes. This includes reference counting the request
being saved away to ensure it can not be retired and freed while the flip code
is still waiting on it.
For: VIZ-4377
From: John Harrison
Converted the mmio_flip 'seqno' value to be a request structure as part of the
on going seqno to request changes. This includes reference counting the request
being saved away to ensure it can not be retired and freed while the flip code
is still waiting on it.
v2: Used the I
From: John Harrison
There is a general theory that kzmalloc is better/safer than kmalloc, especially
for interesting data structures. This change updates the request structure
allocation to be zero filled. That also means it is no longer necessary to
explicitly clear the 'complete' field.
For: V
From: John Harrison
Updated i915_wait_seqno() to take a request structure instead of a seqno value
and renamed it accordingly. Internally, it just pulls the seqno out of the
request and calls on to __wait_seqno() as before. However, all the code further
up the stack is now simplified as it can ju
From: John Harrison
The completion status for all entries in the request list is updated on demand.
This occurs whenever the code queries the completion status of a given request
and a new seqno value has popped out of the hardware. Unfortuntately, not all
such queries are done with the driver mu
From: John Harrison
Added the request structure's 'uniq' identifier to the trace information. Also
renamed the '_complete' trace event to '_notify' as it actually happens in the
IRQ 'notify_ring()' function. Additionally there is now a new '_complete' trace
event which occurs when a request struc
From: John Harrison
The object structure contains the last read, write and fenced seqno values for
use in syncrhonisation operations. These have now been replaced with their
request structure counterparts.
Note that to ensure that objects do not end up with dangling pointers, the
assignments of
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -2 367/367 3
From: John Harrison
There is a general feeling that it is better to move away from using a simple
integer 'seqno' value to track batch buffer completion. Instead, the request
structure should be used. That provides for much more flexibility going
forwards. Especially which things like a GPU sched
From: John Harrison
Added helper functions for retrieving the ring and seqno entries from a request
structure. This allows the internal workings of the request structure to be
hidden from code that is using these. It also allows for useful
workarounds/debug code to be added as or when necessary.
On Mon, 24 Nov 2014, Egbert Eich wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dp.c | 48
> -
> 1 file changed, 28 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/driver
On Mon, Nov 24, 2014 at 07:32:49PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 24, 2014 at 05:56:20PM +0100, Egbert Eich wrote:
> > Before testing if the panel VDD is enabled on eDP cancel any pending
> > disable worker. This makes sure the worker doesn't fire when we expect
> > VDD to be enabled.
>
On Mon, Nov 24, 2014 at 05:56:20PM +0100, Egbert Eich wrote:
> Before testing if the panel VDD is enabled on eDP cancel any pending
> disable worker. This makes sure the worker doesn't fire when we expect
> VDD to be enabled.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=86201
>
> Signed-off-b
For eDP in the Intel driver pps_lock()/unlock() need to be called before
initiating an I2C/AUX channel transfer. These operations can be quite
expensive - especially on values for HZ lower than 1000.
It is therefore better to perfrom this locking/unlocking only
On eDP each low level transfer is wrapped by pps_lock()/unlock()
and edp_panel_vdd_on()/off(). Since PPS locking can be quite expensive
and each call to master_xfer() or dpcd_access() may call these low level
transfer functions many times it may introduce a considerable delay.
Move locking/VDD enab
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 48 -
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 81f959d..a24c8cc7 100644
-
It may be required to wrap the generic DP DPCD transfer function to
perfrom certain operations before of after this function is called.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
include/drm/drm_dp_helper.h | 4
2 files changed, 6 insertions(+), 1 deletion(-
This way a driver can replace this function with its own version.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/drm_dp_helper.c | 5 +++--
include/drm/drm_dp_helper.h | 8
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/
It may be required to wrap the generic DP I2C transfer function to
perfrom certain operations before of after this function is called.
Make this function available to the driver.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
include/drm/drm_dp_helper.h | 2 ++
2 fil
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, November 24, 2014 2:25 PM
> To: Daniel, Thomas
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v5 3/4] drm/i915/bdw: Pin the context
> backing obje
Before testing if the panel VDD is enabled on eDP cancel any pending
disable worker. This makes sure the worker doesn't fire when we expect
VDD to be enabled.
https://bugs.freedesktop.org/show_bug.cgi?id=86201
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/i915/intel_dp.c | 1 +
1 file changed,
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 367/367
From: Ville Syrjälä
On gen4 and earlier the GPU reset also resets the display, so we should
protect against concurrent modeset operations. Grab all the modeset locks
around the entire GPU reset dance, remebering first ti dislogde any
pending page flip to make sure we don't deadlock. Any pageflip
From: Ville Syrjälä
Clear the video overlay state on GPU reset. Any pending overlay request
in the ring has been nuked, and the display itself gets reset. So we
pretty much lose all state here. Adjust the software state to match so
that the next "putimage" will restore things to working order.
S
2014-11-24 9:07 GMT-02:00 Chris Wilson :
> On Mon, Nov 24, 2014 at 12:52:23PM +0200, Jani Nikula wrote:
>> On Mon, 24 Nov 2014, Chris Wilson wrote:
>> > If we have a single unclaimed register, we will have lots. A WARN for
>> > each one makes the machine unusable and does not aid debugging. Conver
Apparently PCH fifo underruns are tricky, we have plenty reports that
we see the occasional underrun (especially at boot-up).
So for a change let's see what happens when we don't re-enable pch
fifo underrun reporting when the pipe is disabled. This means that the
kernel can't catch pch fifo underr
Nothing in Bspec seems to indicate that we actually needs this, and it
looks like can't work since by this point the pipe is off and so
vblanks won't really happen any more.
Note that Bspec mentions that it takes a vblank for this bit to
change, but _only_ when enabling.
Dropping this code quench
On Mon, Nov 24, 2014 at 04:23:36PM +0100, Daniel Vetter wrote:
> The crc code doesn't handle anything really that could drop the
> register state (by design so that we have less complexity). Which
> means userspace may only start crc capture once the pipe is fully set
> up.
>
> With an i-g-t patch
The crc code doesn't handle anything really that could drop the
register state (by design so that we have less complexity). Which
means userspace may only start crc capture once the pipe is fully set
up.
With an i-g-t patch this will be the case, but there's still the
problem that this results in
The problem is that this causes writes to registers, and if the pipe
is off they might go nowhere (e.g. when runtime pm is enabled).
Furthermore we can only really check once the modeset setup is done,
but again most tests set up the CRC structure before calling
igt_commit and friends. We could add
On 24/11/14 10:04, Daniel Vetter wrote:
> On Tue, Nov 18, 2014 at 08:07:22PM +, Dave Gordon wrote:
>> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> b/drivers/gpu/drm/i915/intel_ringbuffer.c
>> index ae09258..a08ae65 100644
>> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
>> +++ b/dri
On Thu, Nov 13, 2014 at 10:28:10AM +, Thomas Daniel wrote:
> 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 fragm
On Mon, Nov 24, 2014 at 12:11:45PM -0200, Paulo Zanoni wrote:
> 2014-11-24 6:03 GMT-02:00 Chris Wilson :
> > In all likelihood we will do a few hundred errnoneous register
> > operations if we do a single invalid register access whilst the device
> > is suspended. As each instance causes a WARN, th
Use igt_debugfs_open to open the connector file, since the
forced_connectors array now only stores the connector path relative to
the debugfs path. Also add some extra error checking to ensure a test
failure if the reset fails.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85829
Signed-of
On Mon, Nov 24, 2014 at 03:10:05PM +0100, Daniel Vetter wrote:
> On Mon, Nov 24, 2014 at 10:35:29AM +, Chris Wilson wrote:
> > On Mon, Nov 24, 2014 at 11:30:24AM +0100, Daniel Vetter wrote:
> > > The problem here is that SNA pins batchbuffers to etch out a bit more
> > > performance. Iirc it st
2014-11-24 6:03 GMT-02:00 Chris Wilson :
> In all likelihood we will do a few hundred errnoneous register
> operations if we do a single invalid register access whilst the device
> is suspended. As each instance causes a WARN, this floods the system
> logs and can make the system unresponsive.
>
>
On Mon, Nov 24, 2014 at 10:35:29AM +, Chris Wilson wrote:
> On Mon, Nov 24, 2014 at 11:30:24AM +0100, Daniel Vetter wrote:
> > The problem here is that SNA pins batchbuffers to etch out a bit more
> > performance. Iirc it started out as a w/a for i830M (which we've
> > implemented in the kernel
On Mon, Nov 24, 2014 at 12:32:12PM +, Tvrtko Ursulin wrote:
>
> On 11/12/2014 05:02 PM, Daniel Vetter wrote:
> >On Thu, Nov 06, 2014 at 02:39:25PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>Things like reliable GGTT mmaps and mirrored 2d-on-3d display will need
> >>to map
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 367/367
On Mon, Nov 24, 2014 at 10:34:42AM +0100, Daniel Vetter wrote:
> On Fri, Nov 21, 2014 at 11:10:31PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 21, 2014 at 09:49:21PM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 21, 2014 at 09:54:29PM +0200, ville.syrj...@linux.intel.com
> > > wrote:
> > > > +
>
On Mon, Nov 24, 2014 at 10:55:46AM +0100, Thierry Reding wrote:
> On Fri, Nov 21, 2014 at 09:36:33PM +0100, Daniel Vetter wrote:
> > On Fri, Nov 21, 2014 at 09:27:04PM +0100, Thierry Reding wrote:
> > > On Sat, Nov 22, 2014 at 03:10:01AM +0800, Yao Cheng wrote:
> > > > on vlv, if ipvr is installed,
On Sat, Nov 22, 2014 at 11:05:15AM +, Chris Wilson wrote:
> On Fri, Nov 21, 2014 at 09:54:25PM +0200, ville.syrj...@linux.intel.com wrote:
> > + /* assert reset for at least 20 usec */
> > + pci_write_config_byte(dev->pdev, I965_GDRST, GRDOM_RESET_ENABLE);
>
> Is this an UC write or do we
On Mon, Nov 24, 2014 at 12:32:12PM +, Tvrtko Ursulin wrote:
>
> On 11/12/2014 05:02 PM, Daniel Vetter wrote:
> >The change around finish_gtt is actually a leak since if the last view
> >around is the rotate one (which can happen if userspace drops the buffer
> >but leaves it displayed) we won'
On 11/12/2014 05:02 PM, Daniel Vetter wrote:
On Thu, Nov 06, 2014 at 02:39:25PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Things like reliable GGTT mmaps and mirrored 2d-on-3d display will need
to map objects into the same address space multiple times.
This also means that objects no
1 - 100 of 126 matches
Mail list logo