On Wednesday 19 November 2014 01:37 AM, Dave Gordon wrote:
The logical ring code was updating the software ring 'head' value
by reading the hardware 'HEAD' register. In LRC mode, this is not
valid as the hardware is not necessarily executing the same context
that is being processed by the
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.
The warning was first introduced in
commit
On Wednesday 19 November 2014 01:37 AM, Dave Gordon wrote:
There are numerous places in the code where the driver's idea of
how much space is left in a ring is updated using the driver's
latest notions of the positions of 'head' and 'tail' for the ring.
Among them are some that update one or
Hi Jani,
Thanks for the review comments.
Regarding the first 2 patches, I was doing almost the same thing in my
3rd and 4th patch. But your patches are more generic.
Regarding the 3rd patch, I have a comment:
Since in case of dual link panels, few panels may require sequence to be
sent
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. Convert
the i915.mmio_debug option to a counter for how many WARNs to fire
before shutting up. Even when i915.mmio_debug was disabled it would
continue to shout an
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
On Mon, 24 Nov 2014, Singh, Gaurav K gaurav.k.si...@intel.com wrote:
Hi Jani,
Thanks for the review comments.
Regarding the first 2 patches, I was doing almost the same thing in my
3rd and 4th patch. But your patches are more generic.
Regarding the 3rd patch, I have a comment:
Since in
On Fri, Nov 21, 2014 at 05:28:11PM -0800, Michael H. Nguyen wrote:
Hi Daniel, Chris
On 11/12/2014 08:38 AM, Chris Wilson wrote:
On Wed, Nov 12, 2014 at 05:33:08PM +0100, Daniel Vetter wrote:
On Wed, Nov 12, 2014 at 10:46 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, Nov 12,
On Fri, Nov 21, 2014 at 05:17:50PM -0800, Michael H. Nguyen wrote:
Hi Chris,
+static struct drm_i915_gem_object*
+i915_gem_execbuffer_parse(struct intel_engine_cs *ring,
+ struct drm_i915_gem_exec_object2 *shadow_exec_entry,
+ struct eb_vmas *eb,
+
On Fri, Nov 21, 2014 at 10:00:53PM +, Vivi, Rodrigo wrote:
Yeah, I'm glad you skipped this one. It was something old I was just carrying
for too long...
Just tested on -nightly and everything is working fine. Even after
suspend-resume! :)
Still said that I cannot use sink_crc when
Hi He Shuang,
I've just noticed that PRTS occasionally drops the end of the subject when
replying on intel-gfx, like here. Unfortunately this breaks threading in
some mail clients like gmail. Do we already have a JIRA for this or should
I make one?
Thanks, Daniel
On Sat, Nov 22, 2014 at
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:
+
+ /*
+ * Flips in the rings will be nuked by the reset,
+ * so complete
On Tue, Nov 18, 2014 at 9:02 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Nov 03, 2014 at 01:29:04PM +, Dave Gordon wrote:
Fixes to both the LRC and the legacy ringbuffer code to correctly
calculate and update the available space in a ring.
The logical ring code was updating the
On Mon, Nov 24, 2014 at 08:03:12AM +, Chris Wilson wrote:
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
On Mon, Nov 24, 2014 at 08:12:57AM +, 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. Convert
the i915.mmio_debug option to a counter for how many WARNs to fire
before shutting up.
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, it need be manually unloaded before
i915, otherwise user might run into
On Mon, 24 Nov 2014, Daniel Vetter dan...@ffwll.ch wrote:
I've just noticed that PRTS occasionally drops the end of the subject when
replying on intel-gfx, like here. Unfortunately this breaks threading in
some mail clients like gmail. Do we already have a JIRA for this or should
I make one?
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/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -52,16
On Mon, Nov 24, 2014 at 10:45:38AM +0100, Daniel Vetter wrote:
On Mon, Nov 24, 2014 at 08:12:57AM +, 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. Convert
the i915.mmio_debug
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 367/367
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. Convert
the i915.mmio_debug option to a counter for how many WARNs to fire
before shutting up. Even when i915.mmio_debug was disabled it would
continue to shout an
Now unused.
Signed-off-by: Daniel Vetter daniel.vet...@intel.com
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 +-
drivers/gpu/drm/i915/i915_dma.c | 11 +++-
drivers/gpu/drm/i915/i915_drv.h | 8 ---
drivers/gpu/drm/i915/i915_gem.c | 106 +-
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 since a long time already). The problem is
that the pin ioctl wasn't added in
commit d23db88c3ab233daed18709e3a24d6c95344117f
Author:
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 since a long time already).
Hmm, we only finally fixed it in the
On Mon, 24 Nov 2014, Chris Wilson ch...@chris-wilson.co.uk 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. Convert
the i915.mmio_debug option to a counter for how many WARNs to fire
before shutting up.
On Mon, Nov 24, 2014 at 12:52:23PM +0200, Jani Nikula wrote:
On Mon, 24 Nov 2014, Chris Wilson ch...@chris-wilson.co.uk 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. Convert
the i915.mmio_debug
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 tvrtko.ursu...@intel.com
Things like reliable GGTT mmaps and mirrored 2d-on-3d display will need
to map objects into the same address space multiple times.
This
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't clean
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 need to
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, it need
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:
+
+ /*
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 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 tvrtko.ursu...@intel.com
Things like reliable GGTT mmaps and mirrored 2d-on-3d display will need
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 since
2014-11-24 6:03 GMT-02:00 Chris Wilson ch...@chris-wilson.co.uk:
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
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 started
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
On Mon, Nov 24, 2014 at 12:11:45PM -0200, Paulo Zanoni wrote:
2014-11-24 6:03 GMT-02:00 Chris Wilson ch...@chris-wilson.co.uk:
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
On Thu, Nov 13, 2014 at 10:28:10AM +, Thomas Daniel wrote:
From: Oscar Mateo oscar.ma...@intel.com
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,
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
+++
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
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
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 this
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
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
2014-11-24 9:07 GMT-02:00 Chris Wilson ch...@chris-wilson.co.uk:
On Mon, Nov 24, 2014 at 12:52:23PM +0200, Jani Nikula wrote:
On Mon, 24 Nov 2014, Chris Wilson ch...@chris-wilson.co.uk wrote:
If we have a single unclaimed register, we will have lots. A WARN for
each one makes the machine
From: Ville Syrjälä ville.syrj...@linux.intel.com
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
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ä ville.syrj...@linux.intel.com
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
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 e...@suse.de
---
drivers/gpu/drm/i915/intel_dp.c | 1 +
1
-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 objects to
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 e...@suse.de
---
drivers/gpu/drm/drm_dp_helper.c | 3 ++-
include/drm/drm_dp_helper.h
This way a driver can replace this function with its own version.
Signed-off-by: Egbert Eich e...@suse.de
---
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
From: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
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
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
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 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-by:
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, 24 Nov 2014, Egbert Eich e...@suse.de wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 48
-
1 file changed, 28 insertions(+), 20
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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
From: John Harrison john.c.harri...@intel.com
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:
From: John Harrison john.c.harri...@intel.com
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
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 we expect
From: John Harrison john.c.harri...@intel.com
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
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
On Mon, Nov 24, 2014 at 5:56 PM, Egbert Eich e...@suse.de 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:
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 matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 57
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
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
Reviewed-by: Bob Paauwe bob.j.paa...@intel.com
Signed-off-by: Matt Roper matthew.d.ro...@intel.com
---
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
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
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
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:
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
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 matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 113
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
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
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
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)
On Mon, Nov 24, 2014 at 4:36 PM, Damien Lespiau
damien.lesp...@intel.com 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
1 - 100 of 121 matches
Mail list logo
