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 softwa
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 b2ec142cb
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 bot
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 only
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 3
On Mon, 24 Nov 2014, "Singh, Gaurav K" 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 case of dual
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
> >>wrote:
> >>>On Wed, Nov 12, 2014 at 09:44
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
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
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 06:13:26
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,
> > >
On Tue, Nov 18, 2014 at 9:02 AM, Daniel Vetter 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 software rin
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 syst
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 ru
On Mon, 24 Nov 2014, Daniel Vetter 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?
Seems like P
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,1
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_debu
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
---
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 +-
drivers/gpu/drm/i915/i91
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: Chr
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 ker
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. Convert
> the i915.mmio_debug option to a counter for how many WARNs to fire
> before shutting up. Even when i915.mmio_
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. Convert
> > the i915.mmio_debug option to a counter
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
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 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 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 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
> >>
> >>Things like reliable GGTT mmaps and mirrored 2d-on-3d display will need
> >>to map
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
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 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
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 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
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 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
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
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
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
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
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
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
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
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,
> -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
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
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 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(-
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
-
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
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-b
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 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
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.
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
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
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 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
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
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 '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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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/
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
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
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 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
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
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
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
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
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
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
1 - 100 of 126 matches
Mail list logo
