On Wed, Nov 26, 2014 at 01:17:22PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> At least on two MST devices I've tested with, when
> they are link training downstream, they are totally
> unable to handle aux ch msgs, so they defer like nuts.
> I tried 16, it wasn't enough, 32 seems better.
>
On Tue, Nov 25, 2014 at 06:20:17PM +0100, Egbert Eich wrote:
> Daniel Vetter writes:
>
> > Imo this approach with overwrite all the entry points won't scale since
> > besides i2c and dpcd there will be more sooner or later (oui, dp mst, some
> > debugfs userspace dp aux tools, ...).
> >
> >
On Mon, Nov 24, 2014 at 06:49:33PM +, john.c.harri...@intel.com wrote:
> 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 dere
On Mon, Nov 24, 2014 at 06:49:34PM +, john.c.harri...@intel.com wrote:
> 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
On Wed, 26 Nov 2014, Dave Airlie wrote:
> From: Dave Airlie
>
> At least on two MST devices I've tested with, when
> they are link training downstream, they are totally
> unable to handle aux ch msgs, so they defer like nuts.
> I tried 16, it wasn't enough, 32 seems better.
I think we have a bug
With refcounting it looks like you can just drop that refcount, but
that's not really the case. So make sure no one forgets.
Motivated by the unlocked call in the mmio flip code.
Cc: John Harrison
Cc: Thomas Daniel
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
1 file
On Tue, Nov 25, 2014 at 08:47:10PM +, Chris Wilson wrote:
> On Tue, Nov 25, 2014 at 02:34:02PM +0100, Daniel Vetter wrote:
> > On Tue, Nov 25, 2014 at 12:06:33PM +, Chris Wilson wrote:
> > > On Tue, Nov 25, 2014 at 01:01:39PM +0100, Daniel Vetter wrote:
> > > > On Tue, Nov 25, 2014 at 11:42
On Wed, Nov 26, 2014 at 10:28:13AM +0100, Daniel Vetter wrote:
> With refcounting it looks like you can just drop that refcount, but
> that's not really the case. So make sure no one forgets.
>
> Motivated by the unlocked call in the mmio flip code.
I had an unlocked variant for exactly this purp
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 366/366
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 366/366
On 26/11/2014 09:23, Daniel Vetter wrote:
On Mon, Nov 24, 2014 at 06:49:34PM +, john.c.harri...@intel.com wrote:
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 reques
On 26/11/2014 09:19, Daniel Vetter wrote:
On Mon, Nov 24, 2014 at 06:49:33PM +, john.c.harri...@intel.com wrote:
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
NB: The v3 update was to fold in a new patch for asynchronous shrinker
shenanigans. Unfortunately, the new patch was not actually valid at this
point in the patch series, thus this patch now breaks the build until a
later patch in the series fixes it up again! I'll post out an updated v4
set wi
On Tue, Nov 25, 2014 at 9:51 PM, Chris Wilson wrote:
> On Tue, Nov 25, 2014 at 04:42:22PM +, Daniel, Thomas wrote:
>> > -Original Message-
>> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
>> > Vetter
>> > Sent: Tuesday, November 25, 2014 4:00 PM
>> > To: Chr
On Wed, Nov 26, 2014 at 1:23 PM, John Harrison
wrote:
>> This needs locking. It might work as-is but it's definitely too tricky to
>> be worth it.
>
> The manipulation of the list is locked, only this test is unlocked. Do you
> really need to lock when testing for empty? Nothing can be removing it
On 26/11/2014 10:39, Chris Wilson wrote:
On Wed, Nov 26, 2014 at 10:28:13AM +0100, Daniel Vetter wrote:
With refcounting it looks like you can just drop that refcount, but
that's not really the case. So make sure no one forgets.
Motivated by the unlocked call in the mmio flip code.
I had an un
On Wed, Nov 26, 2014 at 11:39 AM, Chris Wilson wrote:
> On Wed, Nov 26, 2014 at 10:28:13AM +0100, Daniel Vetter wrote:
>> With refcounting it looks like you can just drop that refcount, but
>> that's not really the case. So make sure no one forgets.
>>
>> Motivated by the unlocked call in the mmio
On Wed, Nov 26, 2014 at 12:41:43PM +, John Harrison wrote:
> On 26/11/2014 10:39, Chris Wilson wrote:
> >On Wed, Nov 26, 2014 at 10:28:13AM +0100, Daniel Vetter wrote:
> >>With refcounting it looks like you can just drop that refcount, but
> >>that's not really the case. So make sure no one for
On Wed, Nov 26, 2014 at 1:46 PM, Chris Wilson wrote:
>> Daniel: Should I fold the WARN_ON patch into my patch series and repost?
Nope I'll wrestle while applying.
>> Chris: Are you saying that you want an extra patch to rename
>> 'drm_i915_gem_request' to 'drm_i915_request' throughout the entire
On Wed, Nov 26, 2014 at 1:12 PM, John Harrison
wrote:
> The unref_irq is needed for the flip_queued_req as that is still
> dereferenced from interrupt time. Possibly this one could now be downgraded
> to a mutex lock but before the recent rebase, the mmio_flip request was also
> being dereferenced
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 366/366
On Mon, Nov 24, 2014 at 06:49:37PM +, john.c.harri...@intel.com wrote:
> 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
On Wed, Nov 26, 2014 at 12:27:07PM +, John Harrison wrote:
> NB: The v3 update was to fold in a new patch for asynchronous shrinker
> shenanigans. Unfortunately, the new patch was not actually valid at this
> point in the patch series, thus this patch now breaks the build until a
> later patch
On Mon, Nov 24, 2014 at 06:49:39PM +, john.c.harri...@intel.com wrote:
> 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 r
Hardware team updated the recommended translation values for DP/eDP 1.3.
This should help with some stability and HBR2 issues.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/
Similar to the patch from John which removed obj->ring.
Cc: John Harrison
Cc: Thomas Daniel
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 9 ++---
drivers/gpu/drm/i915/intel_display.c | 11 +++
drivers/gpu/drm/i915/intel_drv.h | 1 -
3 files changed,
On Mon, Nov 24, 2014 at 06:49:42PM +, john.c.harri...@intel.com wrote:
> @@ -2767,8 +2757,7 @@ i915_gem_retire_requests_ring(struct intel_engine_cs
> *ring)
> struct drm_i915_gem_object,
> ring_list);
>
> - i
On Mon, Nov 24, 2014 at 06:49:43PM +, john.c.harri...@intel.com wrote:
> 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->
On 26/11/2014 13:24, Daniel Vetter wrote:
On Mon, Nov 24, 2014 at 06:49:39PM +, john.c.harri...@intel.com wrote:
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.
N
Otherwise, new platforms without workarounds will hit this warning for
every new context created.
Cc: Tvrtko Ursulin
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_lrc.c| 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
On Wed, Nov 26, 2014 at 02:12:53PM +, John Harrison wrote:
> On 26/11/2014 13:24, Daniel Vetter wrote:
> >On Mon, Nov 24, 2014 at 06:49:39PM +, john.c.harri...@intel.com wrote:
> >>From: John Harrison
> >>
> >>Updated the trace_irq code to use requests instead of seqnos. This includes
> >>
On Wed, Nov 26, 2014 at 3:12 PM, John Harrison
wrote:
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>>> b/drivers/gpu/drm/i915/i915_drv.h
>>> index 8bfdac6..831fae2 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>> @@ -3130,4 +3130,11 @@ wait_remaini
On 26/11/2014 14:42, Daniel Vetter wrote:
On Wed, Nov 26, 2014 at 3:12 PM, John Harrison
wrote:
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 8bfdac6..831fae2 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3130,4 +31
On Tue, 25 Nov 2014, Imre Deak wrote:
> On Tue, 2014-11-25 at 15:43 +0200, ville.syrj...@linux.intel.com wrote:
>> From: Ville Syrjälä
>>
>> Currently we just make sure vdd is off before suspending, but we don't
>> cancel the vdd off work. The work wil not touch vdd if
>> want_panel_vdd==false s
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.
v
On 26/11/2014 12:49, Daniel Vetter wrote:
On Wed, Nov 26, 2014 at 1:12 PM, John Harrison
wrote:
The unref_irq is needed for the flip_queued_req as that is still
dereferenced from interrupt time. Possibly this one could now be downgraded
to a mutex lock but before the recent rebase, the mmio_fli
Another iteration of the i915 atomic plane helper conversion. This iteration
is based on the display refactoring series I sent to the mailing list last
night, so the actual transition to atomic here should be a little bit easier to
understand. This set also fixes v1's problem with performing slee
Once we integrate our work into the atomic pipeline, plane commit
operations will need to happen with interrupts disabled, due to vblank
evasion. Create new 'pre_commit' and 'post_commit' handlers to cover
hardware programming operations that can sleep and thus must happen
outside the vblank evasi
We'll want to use this from the atomic plane helpers, so ensure it can
be called outside intel_display.c.
Reviewed-by: Bob Paauwe
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-
Add the new driver entrypoints that will be called by the atomic plane
helpers.
This patch does not actually switch over to the new plane helpers yet,
so there should be no functional change here. Also note that although
plane programming was already split into check/prepare/commit steps,
some of
Signed-off-by: Matt Roper
---
Documentation/DocBook/drm.tmpl| 5 +
drivers/gpu/drm/i915/intel_atomic_plane.c | 10 ++
2 files changed, 15 insertions(+)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 944e8ed..c758e1c 100644
--- a/Docume
The userspace-requested plane coordinates are now stored in
plane->state.base (and the i915-adjusted values are stored in
plane->state), so we no longer use the coordinate fields in intel_plane
or the orig_{src,dst} fields in intel_plane_state. Drop them.
Reviewed-by: Bob Paauwe
Signed-off-by: M
When disabling a plane, it is legal to pass crtc = NULL. Since planes
on Intel hardware are tied to a fixed CRTC, go ahead and set state->crtc
to the appropriate crtc in cases where it is passed to us as NULL.
In a future patch, we will start using the update handler for plane
disables, so this w
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
Move the vblank evasion up from the low-level, hw-specific
update_plane() handlers to the general plane commit operation.
Everything inside commit should now be non-sleeping, so this brings us
closer to how vblank evasion will behave once we move over to atomic.
Signed-off-by: Matt Roper
---
dri
Now that we have hooks to enable the atomic plane helpers, we can use
the plane helpers for our .update_plane() and .disable_plane()
entrypoints.
v2: Fix commit message typo (Bob)
v3: Rebased on top of Gustavo Padovan's patches to kill off
intel_crtc_cursor_set_obj() and intel_pipe_set_base()
A few of the sprite-related function names in i915 are very similar
(e.g., intel_enable_planes() vs intel_crtc_enable_planes()) and don't
make it clear whether they only operate on sprite planes, or whether
they also apply to all universal plane types. Rename a few functions to
be more consistent
We don't really synchronously turn them off from debugfs. We try to
avoid hitting them too badly by waiting one vblank, but apparently the
irq handler can still race through that gap.
Since this isn't really all that important for testcases, only for
debugging CRC issues let's tune it down to a de
2014-11-24 14:02 GMT-02:00 Daniel Vetter :
> 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.
D
On Tue, Nov 25, 2014 at 5:50 PM, Daniel Vetter wrote:
> So the problem with async commit (especially async modeset commit) is
> that the legacy pointers only get updated after the point of no
> return, in the async part of the modeset sequence. At least as
> implemented by the current helper funct
2014-11-24 13:54 GMT-02:00 Daniel Vetter :
> 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
Somehow (i.e. purely experimental evidence from users out there in the
wild) using CS flips seems to be implicated in hw context switch
hangs.
I have no idea why, but let's just try this out.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=78960
References: https://bugs.freedesktop.org/sho
Add the new driver entrypoints that will be called by the atomic plane
helpers.
This patch does not actually switch over to the new plane helpers yet,
so there should be no functional change here. Also note that although
plane programming was already split into check/prepare/commit steps,
some of
On Wed, Nov 26, 2014 at 05:25:32PM +0100, Daniel Vetter wrote:
> Somehow (i.e. purely experimental evidence from users out there in the
> wild) using CS flips seems to be implicated in hw context switch
> hangs.
>
> I have no idea why, but let's just try this out.
>
> Bugzilla: https://bugs.freed
On Wed, Nov 26, 2014 at 05:25:32PM +0100, Daniel Vetter wrote:
> Somehow (i.e. purely experimental evidence from users out there in the
> wild) using CS flips seems to be implicated in hw context switch
> hangs.
>
> I have no idea why, but let's just try this out.
>
> Bugzilla: https://bugs.freed
On Wed, Nov 26, 2014 at 04:45:03PM +, Chris Wilson wrote:
> On Wed, Nov 26, 2014 at 05:25:32PM +0100, Daniel Vetter wrote:
> > Somehow (i.e. purely experimental evidence from users out there in the
> > wild) using CS flips seems to be implicated in hw context switch
> > hangs.
> >
> > I have n
On Wed, Nov 26, 2014 at 01:37:07PM -0200, Paulo Zanoni wrote:
> 2014-11-24 14:02 GMT-02:00 Daniel Vetter :
> > 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
> -Original Message-
> From: Cheng, Yao
> Sent: Saturday, November 22, 2014 3:07
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; Kelley, Sean V; Chehab, John
> Cc: Jiang, Fei; dh.herrm...@gmail.com; jani.nik...@linux.intel.com;
> emil.l.veli
On Wed, Nov 19, 2014 at 05:47:07PM -0200, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Hi
>
> ---
> TL;DR summary:
> I wrote patches. Help me choose the best implementation and interface.
> ---
>
> So the i915.ko driver could use some mechanism to run functions after a given
> number of vblanks
On Wed, Nov 26, 2014 at 10:52:24AM -0500, Sean Paul wrote:
> On Tue, Nov 25, 2014 at 5:50 PM, Daniel Vetter wrote:
> > So the problem with async commit (especially async modeset commit) is
> > that the legacy pointers only get updated after the point of no
> > return, in the async part of the mode
On 11/14/2014 8:24 PM, Jani Nikula wrote:
MIPI DSI works on ports A and C, which map to pipes A and B,
respectively. Things are going to get more complicated with the
introduction of dual link DSI support, so clean up the register defines
and code to match reality.
Signed-off-by: Jani Nikula
-
On 11/24/2014 2:31 PM, Jani Nikula wrote:
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 com
This essentially reverts
commit 934ce1c23624526d9d784e0499190bb48113e6f4
Author: Rob Clark
Date: Wed Nov 19 16:41:33 2014 -0500
drm/atomic: check mode_changed *after* atomic_check
Depending upon the driver both orders (or maybe even interleaving) is
required:
- If ->atomic_check updates -
The default call sequence for these two parts won't fit for all
drivers. So export the two pieces and explain with a bit of kerneldoc
when each should be called.
Cc: Rob Clark
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 65 -
1 file
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 366/366
On 11/26/2014 7:07 PM, Damien Lespiau wrote:
Hardware team updated the recommended translation values for DP/eDP 1.3.
This should help with some stability and HBR2 issues.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 12 ++--
1 file changed, 6 insertions(+), 6
On Wed, Nov 26, 2014 at 10:50:46PM +0530, Singh, Gaurav K wrote:
> This patch has some style issues. Please address them.
Please be more specific, that's rather non-actionable review.
Also general rule of thumb is that if it doesn't look offensive and the
patch is otherwise good it still deserve
On Wed, Nov 26, 2014 at 05:07:29PM +0200, ville.syrj...@linux.intel.com wrote:
> 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 sof
On Wed, Nov 26, 2014 at 01:37:07PM -0200, Paulo Zanoni wrote:
> 2014-11-24 14:02 GMT-02:00 Daniel Vetter :
> > 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
On Wed, Nov 26, 2014 at 03:21:30PM +, John Harrison wrote:
> On 26/11/2014 12:49, Daniel Vetter wrote:
> >On Wed, Nov 26, 2014 at 1:12 PM, John Harrison
> > wrote:
> >>The unref_irq is needed for the flip_queued_req as that is still
> >>dereferenced from interrupt time. Possibly this one could
On Wed, Nov 26, 2014 at 02:58:49PM +, John Harrison wrote:
> On 26/11/2014 14:42, Daniel Vetter wrote:
> >On Wed, Nov 26, 2014 at 3:12 PM, John Harrison
> > wrote:
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 8bfdac6..831fae2 100644
> >>
On Wed, Nov 26, 2014 at 07:23:36PM +0100, Daniel Vetter wrote:
> On Wed, Nov 26, 2014 at 02:58:49PM +, John Harrison wrote:
> > On 26/11/2014 14:42, Daniel Vetter wrote:
> > >On Wed, Nov 26, 2014 at 3:12 PM, John Harrison
> > > wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > >>>
On 11/26/2014 11:38 PM, Daniel Vetter wrote:
On Wed, Nov 26, 2014 at 10:50:46PM +0530, Singh, Gaurav K wrote:
This patch has some style issues. Please address them.
Please be more specific, that's rather non-actionable review.
Also general rule of thumb is that if it doesn't look offensive a
Move the vblank evasion up from the low-level, hw-specific
update_plane() handlers to the general plane commit operation.
Everything inside commit should now be non-sleeping, so this brings us
closer to how vblank evasion will behave once we move over to atomic.
v2: Restore lost intel_crtc->active
Add the new driver entrypoints that will be called by the atomic plane
helpers.
This patch does not actually switch over to the new plane helpers yet,
so there should be no functional change here. Also note that although
plane programming was already split into check/prepare/commit steps,
some of
Now that we have hooks to enable the atomic plane helpers, we can use
the plane helpers for our .update_plane() and .disable_plane()
entrypoints.
v2: Fix commit message typo (Bob)
v3: Rebased on top of Gustavo Padovan's patches to kill off
intel_crtc_cursor_set_obj() and intel_pipe_set_base()
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 366/366
From: Brad Volkin
Previously we couldn't trust the user-supplied batch length because
it came directly from userspace (i.e. untrusted code). It would have
affected what commands software parsed without regard to what hardware
would actually execute, leaving a potential hole.
With the parser now
From: "Michael H. Nguyen"
This is v5 of the series sent here:
http://lists.freedesktop.org/archives/intel-gfx/2014-November/055141.html
This version incorporates the following feedback from v4.
- 0/7 Move 'pending_read_domains |= I915_GEM_DOMAIN_COMMAND' after the
parser (danvet)
- 1/7 Move
From: Brad Volkin
This adds a small module for managing a pool of batch buffers.
The only current use case is for the command parser, as described
in the kerneldoc in the patch. The code is simple, but separating
it out makes it easier to change the underlying algorithms and to
extend to future u
From: Brad Volkin
This patch sets up all of the tracking and copying necessary to
use batch pools with the command parser and dispatches the copied
(shadow) batch to the hardware.
After this patch, the parser is in 'enabling' mode.
Note that performance takes a hit from the copy in some cases
a
From: Brad Volkin
To better account for the potentially large memory consumption
of the batch pool.
Issue: VIZ-4719
Signed-off-by: Brad Volkin
---
drivers/gpu/drm/i915/i915_debugfs.c | 45 +
1 file changed, 36 insertions(+), 9 deletions(-)
diff --git a/driv
From: Brad Volkin
It provides some useful information about the buffers in
the global command parser batch pool.
v2: rebase on global pool instead of per-ring pools
v3: rebase
Issue: VIZ-4719
Signed-off-by: Brad Volkin
---
drivers/gpu/drm/i915/i915_debugfs.c | 41
From: Brad Volkin
By adding a new exec_entry flag, we cleanly mark the shadow objects
as purgeable after they are on the active list.
v2:
- Move 'shadow_batch_obj->madv = I915_MADV_WILLNEED' inside _get
fnc (danvet, from v4 6/7 feedback)
Issue: VIZ-4719
Signed-off-by: Brad Volkin
---
driver
From: Brad Volkin
Move it to a separate function since the main do_execbuffer function
already has so much going on.
v2:
- Move pin/unpin calls inside i915_parse_cmds() (Chris W, v4 7/7
feedback)
Issue: VIZ-4719
Signed-off-by: Brad Volkin
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 8
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 366/366
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 366/366
>> ---
>> TL;DR summary:
>> I wrote patches. Help me choose the best implementation and interface.
>> ---
>>
>> So the i915.ko driver could use some mechanism to run functions after a given
>> number of vblanks. Implementations for this mechanism were already proposed
>> in
>> the past (by Chris W
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 366/366 3
On Tue, Nov 25, 2014 at 10:25 PM, Dave Airlie wrote:
> From: Dave Airlie
>
> At least on two MST devices I've tested with, when
> they are link training downstream, they are totally
> unable to handle aux ch msgs, so they defer like nuts.
> I tried 16, it wasn't enough, 32 seems better.
>
> This
On 11/14/2014 8:24 PM, Jani Nikula wrote:
Later on this can include multiple ports (e.g. (1 << PORT_A) | (1 <<
PORT_C)) to describe dual link DSI.
Signed-off-by: Jani Nikula
Reviewed-by: Gaurav K Singh
---
drivers/gpu/drm/i915/intel_dsi.c | 7 +--
drivers/gpu/drm/i915/intel_dsi.h | 3
On 11/14/2014 8:24 PM, Jani Nikula wrote:
MIPI DSI works on ports A and C, which map to pipes A and B,
respectively. Things are going to get more complicated with the
introduction of dual link DSI support, so clean up the register defines
and code to match reality.
Signed-off-by: Jani Nikula
On Wed, Nov 26, 2014 at 01:53:34PM -0800, michael.h.ngu...@intel.com wrote:
> From: "Michael H. Nguyen"
>
> This is v5 of the series sent here:
> http://lists.freedesktop.org/archives/intel-gfx/2014-November/055141.html
>
> This version incorporates the following feedback from v4.
>
> - 0/7 Mo
On 11/24/2014 2:31 PM, Jani Nikula wrote:
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 com
94 matches
Mail list logo
