Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5835
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 282/282
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5835
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 282/282
This wrong logic and useless define came from first versions and
came along with all rework. Just now I notice how ugly, wrong and
useless this is.
val is already defined as 0 anyway and logic is completelly wrong
and useless. So let's starting the link_standby fix with this
cleaning.
Signed-off-
There are some cases like suspend/resume or dpms off/on sequences
that can flush frontbuffer bits. In these cases features that relies
on frontbuffer tracking can start working and user can stop getting
screen updates on fbcon having impression the system is frozen.
So, let's make sure on fbcon wr
With a reliable frontbuffer tracking and all instability corner cases solved
let's re-enabled PSR by default on all supported platforms.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915
From: chandra konduru
Adding i-g-t test case to test display crtc background color.
v2:
- Added IGT_TEST_DESCRIPTION() (Thomas Wood)
- Added to .gitignore (Thomas Wood)
- Added additional details to function header (Thomas Wood)
- Simplified igt_main (Thomas Wood)
Signed-off-by: chandra konduru
Since active function on VLV immediately activate PSR let's give more
time for idleness.
v2: Rebase over intel_psr.c and fix typo.
v3: Revival: Manual tests indicated that this is needed. With a short delay
there is a huge risk of getting blank screens when planes are being enabled.
v4: Reviva
According to spec: "In PSR HW or SW mode, SW set this bit before writing
registers for a flip. It will be self-clear when it gets to the PSR
active state."
Some versions of spec mention that this is needed when in
"Persistent mode" but define it as same as "SW mode". Since this
fix the page flip c
Since the begining there is a missunderstanding on the meaning of this
dpcd bit.
This bit should'n indicate wheter to use link standby or not, but just
be used to configure TP1, TP2 and TP3 times and tell hw aux should be skiped
since HW is the responsible one.
Even with help of frontbuffer tracki
On Haswell and Broadwell with link in standby when exit event happens
between vblank and VSC packet, PSR exit on panel but DPA transmitter
still sends black pixel. hen this condition hits, panel will intermittently
display black frame.
The known W/A for this case involve the of single_frame update
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5834
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 282/282
cool, thanks for the detailed explanation.
Reviewed-by: Rodrigo Vivi
On Fri, Feb 27, 2015 at 6:04 AM, Daniel Vetter wrote:
> On Thu, Feb 26, 2015 at 05:11:16PM -0800, Rodrigo Vivi wrote:
>> I believe this patch is on the wrong series, right?
>
> It's in here since I've spotted the FIXME while re
On Fri, Feb 27, 2015 at 12:38:44PM -0800, Jesse Barnes wrote:
> On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Poke at the CBR1_VLV register during init_clock_gating to make sure the
> > PND deadline scheme is used.
> >
> > The hardware has two modes
On 02/27/2015 10:09 AM, Ville Syrjälä wrote:
> On Fri, Feb 27, 2015 at 09:57:20AM -0800, Jesse Barnes wrote:
>> On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
>>> From: Ville Syrjälä
>>>
>>> Now that we have drm_planes for the cursor and primary we can move the
>>> pixel_size handlin
On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Poke at the CBR1_VLV register during init_clock_gating to make sure the
> PND deadline scheme is used.
>
> The hardware has two modes of operation wrt. watermarks:
>
> 1) PND deadline mode:
> - memory reques
On Fri, Feb 27, 2015 at 12:12:28PM -0800, jeff.mc...@intel.com wrote:
> From: Jeff McGee
>
> Total EU was already being detected on CHV, so we just add the
> additional info parameters. The detection method is changed to
> be more robust in the case of subslice fusing - we don't want
> to trust t
From: Jeff McGee
Total EU was already being detected on CHV, so we just add the
additional info parameters. The detection method is changed to
be more robust in the case of subslice fusing - we don't want
to trust the EU fuse bits corresponding to subslices which are
fused-off.
v2: Fixed subslic
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5825
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 282/282
igt_kms extensively uses line continuation when dumping state updates
at the debug level. They got badly mangled with the recent changes to
for the log handling functions. Two separate fixes:
- Don't prepend domain and other metainformation when it's just a
continuation line.
- Dont add newlines
On Fri, Feb 27, 2015 at 10:11:58AM -0800, Matt Roper wrote:
> I'm in the process of reworking watermarks to play more nicely with atomic
> driver design. It sounds like a few people are already running into
> watermark-related problems caused by the atomic changes, so I've extracted a
> few early
On Fri, Feb 27, 2015 at 07:47:46PM +0100, Daniel Vetter wrote:
> On Fri, Feb 27, 2015 at 08:21:07PM +0200, Ville Syrjälä wrote:
> > On Fri, Feb 27, 2015 at 08:54:19AM -0800, Matt Roper wrote:
> > > Move watermark handling from intel_pm.c to intel_wm.c and add a little
> > > bit of kerneldoc to expo
On Fri, Feb 27, 2015 at 08:21:07PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 27, 2015 at 08:54:19AM -0800, Matt Roper wrote:
> > Move watermark handling from intel_pm.c to intel_wm.c and add a little
> > bit of kerneldoc to exported functions. We also add a new
> > intel_init_wm() function to setu
On Fri, Feb 27, 2015 at 06:22:43PM +, John Harrison wrote:
> On 27/02/2015 13:35, Daniel Vetter wrote:
> >On Fri, Feb 27, 2015 at 12:22:42PM +, John Harrison wrote:
> >>On 25/02/2015 21:52, Daniel Vetter wrote:
> >>>On Fri, Feb 13, 2015 at 11:48:13AM +, john.c.harri...@intel.com wrote:
On Fri, Feb 27, 2015 at 10:22:32AM -0800, jeff.mc...@intel.com wrote:
> From: Jeff McGee
>
> Collect the currently enabled counts of slice, subslice, and
> execution units using the power gate control ack message
> registers specific to Cherryview.
>
> Slice/subslice/EU info and hardware status
On Fri, 27 Feb 2015 18:59:07 +0100, Daniel Vetter wrote:
> Smells like something is wrong in bdw-land.
>
> Can you please retest with latest drm-intel-nightly from
> http://cgit.freedesktop.org/drm-intel or alternatively 4.0-rc kernels?
> Starting with 4.0 we're using the execlist cmd submission s
On Fri, Feb 27, 2015 at 10:22:31AM -0800, jeff.mc...@intel.com wrote:
> From: Jeff McGee
>
> Total EU was already being detected on CHV, so we just add the
> additional info parameters. The detection method is changed to
> be more robust in the case of subslice fusing - we don't want
> to trust t
On Fri, 2015-02-27 at 14:15 +0200, David Weinehall wrote:
> On Thu, Feb 26, 2015 at 09:01:27PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 26, 2015 at 08:50:48PM +0200, Imre Deak wrote:
>
> [snip]
> > >
> > > The problem seems to be that after the kernel puts the device into D3
> > > the BIOS sti
On 27/02/2015 13:35, Daniel Vetter wrote:
On Fri, Feb 27, 2015 at 12:22:42PM +, John Harrison wrote:
On 25/02/2015 21:52, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 11:48:13AM +, john.c.harri...@intel.com wrote:
From: John Harrison
The do_execbuf() function takes quite a few parame
On Fri, Feb 27, 2015 at 08:54:19AM -0800, Matt Roper wrote:
> Move watermark handling from intel_pm.c to intel_wm.c and add a little
> bit of kerneldoc to exported functions. We also add a new
> intel_init_wm() function to setup memory timing information and
> initialize the relevant watermark vfu
Hi all,
New -testing cycle with cool stuff:
- Y tiling support for scanout from Tvrtko&Damien
- Remove more UMS support
- some small prep patches for OLR removal from John Harrison
- first few patches for dynamic pagetable allocation from Ben Widawsky, rebased
by tons of other people
- DRRS supp
I'm in the process of reworking watermarks to play more nicely with atomic
driver design. It sounds like a few people are already running into
watermark-related problems caused by the atomic changes, so I've extracted a
few early patches here that might solve those immediate issues.
Note that the
plane->fb is a legacy pointer that not always be up-to-date (or updated
early enough). Make sure the watermark code uses plane->state->fb so
that we're always doing our calculations based on the correct
framebuffers.
This patch was generated by Coccinelle with the following semantic
patch:
The cursor size fields in intel_crtc just duplicate the data from
cursor->state.crtc_{w,h} so we don't need them any more. Worse, their
use in the watermark code actually introduces a subtle bug since they
don't get updated to mirror the state values until the plane commit
stage, which is *after*
On Fri, Feb 27, 2015 at 09:57:20AM -0800, Jesse Barnes wrote:
> On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Now that we have drm_planes for the cursor and primary we can move the
> > pixel_size handling into vlv_compute_drain_latency() and just pas
On Fri, Feb 27, 2015 at 09:38:10AM -0800, Jesse Barnes wrote:
> On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> > @@ -957,8 +954,7 @@ static void valleyview_update_sprite_wm(struct
> drm_plane *plane,
> > int plane_prec;
> > int sprite_dl;
> > int prec_mult;
> > - const
On 02/12/2015 10:59 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> VLV/CHV have similar DSPARB registers as older platforms, just more of
> them due to more planes. Add a bit of code to read out the current FIFO
> split from the registers. Will be useful later when we improve
From: Jeff McGee
These two patches add detection of available and enabled
slice/subslice/EU on CHV following the implementation recently
merged for SKL. They have been requested to help CHV users
determine their configuration through the debugfs interface.
Jeff McGee (2):
drm/i915/chv: Determi
On 27/02/15 17:32, Michel Thierry wrote:
On 25/02/15 17:54, Arun Siluvery wrote:
From: Namrta
This can be used to enable WA BB infrastructure for features like
RC6, SSEU and in between context save/restore etc.
The patch which would need WA BB will have to declare the wa_bb obj
utilizing t
From: Jeff McGee
Collect the currently enabled counts of slice, subslice, and
execution units using the power gate control ack message
registers specific to Cherryview.
Slice/subslice/EU info and hardware status can now be
determined for CHV, so allow the debugfs SSEU status dump
to proceed for
From: Jeff McGee
Total EU was already being detected on CHV, so we just add the
additional info parameters. The detection method is changed to
be more robust in the case of subslice fusing - we don't want
to trust the EU fuse bits corresponding to subslices which are
fused-off.
Signed-off-by: Je
On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Now that we have drm_planes for the cursor and primary we can move the
> pixel_size handling into vlv_compute_drain_latency() and just pass the
> appropriate plane to it.
>
> Signed-off-by: Ville Syrjälä
> --
On Fri, Feb 27, 2015 at 09:36:58AM -0800, Jesse Barnes wrote:
> On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Apparently we must yet halve the DDL drain latency from what we're
> > using currently. This little nugget is not in any spec, but came
> >
Hi Dave,
-rc1 is out, time for the first i915 pull request ;-)
drm-intel-next-2015-02-14:
- use the atomic helpers for plane_upate/disable hooks (Matt Roper)
- refactor the initial plane config code (Damien)
- ppgtt prep patches for dynamic pagetable alloc (Ben Widawsky, reworked and
rebased by
On Fri, Feb 27, 2015 at 04:37:29PM +, Chris Wilson wrote:
> On Fri, Feb 27, 2015 at 04:32:26PM +0100, Daniel Vetter wrote:
> > On Fri, Feb 27, 2015 at 01:58:43PM +, Chris Wilson wrote:
> > > For an object right on the boundary of mappable space, as the fenceable
> > > size is stricly greate
Smells like something is wrong in bdw-land.
Can you please retest with latest drm-intel-nightly from
http://cgit.freedesktop.org/drm-intel or alternatively 4.0-rc kernels?
Starting with 4.0 we're using the execlist cmd submission support,
which might help.
Thanks, Daniel
On Fri, Feb 27, 2015 at
On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Introduce struct vlv_wm_values to house VLV watermark/drain latency
> values. We start by using it when computing the drain latency values.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_
On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Move the DDL precision handling into vlv_compute_drain_latency() so the
> callers don't have to duplicate the same code to deal with it.
A little painful due to the addition of the #define changes, but I think
On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The current drain lantency computation relies on hardcoded limits to
> determine when the to use the low vs. high precision multiplier.
> Rewrite the code to use a more straightforward approach.
>
> Signed-off
On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> @@ -957,8 +954,7 @@ static void valleyview_update_sprite_wm(struct
drm_plane *plane,
> int plane_prec;
> int sprite_dl;
> int prec_mult;
> - const int high_precision = IS_CHERRYVIEW(dev) ?
> - DRAIN_LAT
On 02/10/2015 05:28 AM, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Apparently we must yet halve the DDL drain latency from what we're
> using currently. This little nugget is not in any spec, but came
> down through the grapevine.
>
> This makes the displays a bit more stable
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5831
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 282/282
On 25/02/15 17:54, Arun Siluvery wrote:
From: Namrta
This can be used to enable WA BB infrastructure for features like
RC6, SSEU and in between context save/restore etc.
The patch which would need WA BB will have to declare the wa_bb obj
utilizing the function here. Update the WA BB with requ
On Fri, 27 Feb 2015 00:07:41 +0100, pho...@quasiparticle.net wrote:
> Hi,
>
> I'm having a few problems with i915 on my Broadwell Thinkpad
> (T450s, i7-5600U) with kernel 3.19, apparently suspend/resume related.
[…]
> Also, it seems that running or having run a GL application has some
> impact on
plane->fb is a legacy pointer that not always be up-to-date (or updated
early enough). Make sure the watermark code uses plane->state->fb so
that we're always doing our calculations based on the correct
framebuffers.
This patch was generated by Coccinelle with the following semantic
patch:
The cursor size fields in intel_crtc just duplicate the data from
cursor->state.crtc_{w,h} so we don't need them any more. Worse, their
use in the watermark code actually introduces a subtle bug since they
don't get updated to mirror the state values until the plane commit
stage, which is *after*
I'm in the process of reworking watermarks to play more nicely with atomic
driver design. It sounds like a few people are already running into
watermark-related problems caused by the atomic changes, so I've extracted a
few early patches here that might solve those immediate issues.
Note that the
On Fri, Feb 27, 2015 at 06:11:09PM +0200, Mika Kuoppala wrote:
> commit 05a2fb157e44 ("drm/i915: Consolidate forcewake code")
> failed to take into account that we have used to reset both
> the gen6 style and the multithreaded style forcewake registers.
> This is due to fact that ivb can use either
On Fri, Feb 27, 2015 at 04:32:26PM +0100, Daniel Vetter wrote:
> On Fri, Feb 27, 2015 at 01:58:43PM +, Chris Wilson wrote:
> > For an object right on the boundary of mappable space, as the fenceable
> > size is stricly greater than the actual size, its fence region may extend
> > out of mappabl
On Fri, Feb 27, 2015 at 08:21:34AM -0800, Joe Konno wrote:
> On 02/27/2015 06:53 AM, Daniel Vetter wrote:
> > On Thu, Feb 26, 2015 at 05:47:35PM -0800, Matt Roper wrote:
> >> So your patch below could result in sleeps happening while vblanks are
> >> disabled, which is bad (IIRC, most of those slee
On 02/27/2015 06:53 AM, Daniel Vetter wrote:
> On Thu, Feb 26, 2015 at 05:47:35PM -0800, Matt Roper wrote:
>> So your patch below could result in sleeps happening while vblanks are
>> disabled, which is bad (IIRC, most of those sleeps are in the SKL
>> codepath right now, but I think there's a work
commit 05a2fb157e44 ("drm/i915: Consolidate forcewake code")
failed to take into account that we have used to reset both
the gen6 style and the multithreaded style forcewake registers.
This is due to fact that ivb can use either, depending on how the
bios has set up the machine.
Mimic the old sema
On Fri, Feb 27, 2015 at 07:59:43PM +0530, Ramalingam C wrote:
>
> On Tuesday 24 February 2015 06:21 AM, Daniel Vetter wrote:
> >On Fri, Feb 13, 2015 at 03:32:58PM +0530, Ramalingam C wrote:
> >>This series includes a preparation patch for drrs support across differnt
> >>platforms in intel_dp_set_
On Fri, Feb 27, 2015 at 01:58:43PM +, Chris Wilson wrote:
> For an object right on the boundary of mappable space, as the fenceable
> size is stricly greater than the actual size, its fence region may extend
> out of mappable space.
>
> Signed-off-by: Chris Wilson
Do you have a scenario wher
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5824
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 282/282
On Fri, Feb 27, 2015 at 11:15:16AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Starting with Skylake the display engine can scan out Y tiled objects. (Both
> legacy Y tiled, and the new Yf format.)
>
> This series takes the original work by Damien Lespiau and converts it to use
> th
Found one user in gem_wait.c
Signed-off-by: Daniel Vetter
---
lib/igt_core.h | 13 +
tests/gem_wait.c | 2 +-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/lib/igt_core.h b/lib/igt_core.h
index cc73a712bb7b..c2c820d14c9f 100644
--- a/lib/igt_core.h
+++ b/lib/igt_c
On Thu, Feb 26, 2015 at 07:00:19PM -0800, Matt Roper wrote:
> We've been leaking the framebuffers that get created inside the
> legacy -> universal cursor compatibility layer and nobody noticed. Add
> an i-g-t test to check debugfs and ensure we end up the same number of
> framebuffers we started
This way the debug output in case of failures is nicer since we dump
the entire test condition.
Also replace one open-coded igt_assert_eq.
Signed-off-by: Daniel Vetter
---
tests/kms_universal_plane.c | 112
1 file changed, 50 insertions(+), 62 deleti
From: Tvrtko Ursulin
Display watermarks need different programming for different tiling
modes.
Set the relevant flag so this happens during the plane commit and
add relevant data into a structure made available to the watermark
computation code.
v2: Pass in tiling info to sprite plane updates a
On Fri, Feb 27, 2015 at 01:03:37PM +0100, Daniel Vetter wrote:
> Originally it was impossible to be dropping the last refcount in this
> function since there was always one around still from the idr. But in
>
> commit 83f45fc360c8e16a330474860ebda872d1384c8c
> Author: Daniel Vetter
> Date: Wed
On Thu, Feb 26, 2015 at 06:43:43PM -0800, Marc Herbert wrote:
> The bare "Test requirement: modes" message is too cryptic, I had to go and
> read the source code to understand the missing requirement.
>
> Signed-off-by: Marc Herbert
Nice one, applied.
Thanks, Daniel
> ---
>
> If there is a dif
On Thu, Feb 26, 2015 at 05:47:35PM -0800, Matt Roper wrote:
> On Thu, Feb 26, 2015 at 02:48:44PM -0800, Joe Konno wrote:
> > From: Joe Konno
> >
> > In instances where cursor sizes change, as in Chromium Ozone/Freon,
> > watermarks should be recomputed. There should be no hard-coded
> > assumptio
On Tuesday 24 February 2015 06:21 AM, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 03:32:58PM +0530, Ramalingam C wrote:
This series includes a preparation patch for drrs support across differnt
platforms in intel_dp_set_m_n along with last 5 pending patches of V3 eDP
DRRS patch series.
New se
On Fri, Feb 27, 2015 at 09:39:47AM +, Tvrtko Ursulin wrote:
> >Hum, does this compile? I'm seeing an extra argument to skl_wm_method2()
> >but no update at the calling site?
>
> Not only that, but it even works! :) (Extra argument is there, you must have
> missed it!)
Ooops, I see it now:
Re
On Fri, Feb 27, 2015 at 09:27:04AM +, Chris Wilson wrote:
> On Fri, Feb 27, 2015 at 10:20:05AM +0200, Jani Nikula wrote:
> > On Fri, 27 Feb 2015, Jani Nikula wrote:
> > > On Thu, 26 Feb 2015, Chris Wilson wrote:
> > >> When we takeover from the BIOS and install our interrupt handler, the
> >
On Fri, Feb 27, 2015 at 09:45:27AM +, Tvrtko Ursulin wrote:
>
> On 02/26/2015 04:44 PM, Daniel Vetter wrote:
> >On Wed, Feb 25, 2015 at 04:47:24PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>By this patch all underlying bits have been implemented and this
> >>patch actually
On Thu, Feb 26, 2015 at 05:17:36PM -0800, Rodrigo Vivi wrote:
> Reviewed-by: Rodrigo Vivi
All merged to dinq, thanks for your review.
-Daniel
>
> On Mon, Feb 23, 2015 at 3:03 AM, Daniel Vetter wrote:
> > Mostly just checks in i915-private modeset ioctls.
> >
> > Signed-off-by: Daniel Vetter
>
On Tuesday 24 February 2015 06:09 AM, Daniel Vetter wrote:
On Mon, Feb 23, 2015 at 05:35:54PM +0530, Ramalingam C wrote:
From: Vandana Kannan
Adding a debugfs entry to determine if DRRS is supported or not
V2: [By Ram]: Following details about the active crtc will be filled
in seq-fi
On Thu, Feb 26, 2015 at 05:11:16PM -0800, Rodrigo Vivi wrote:
> I believe this patch is on the wrong series, right?
It's in here since I've spotted the FIXME while removing ums crap.
> I'm afraid I don't know what was this race neither the two-step reset
> to be able to review this comment remove
For an object right on the boundary of mappable space, as the fenceable
size is stricly greater than the actual size, its fence region may extend
out of mappable space.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
On Fri, Feb 27, 2015 at 12:49:11PM +, John Harrison wrote:
> On 25/02/2015 21:31, Daniel Vetter wrote:
> >On Wed, Feb 18, 2015 at 02:28:16PM +, John Harrison wrote:
> >>On 13/02/2015 17:03, Chris Wilson wrote:
> >>>On Fri, Feb 13, 2015 at 04:58:24PM +, John Harrison wrote:
> On 13/0
On Fri, Feb 27, 2015 at 03:03:22PM +0200, Ville Syrjälä wrote:
> On Wed, Feb 25, 2015 at 10:31:13PM +0100, Daniel Vetter wrote:
> > On Wed, Feb 18, 2015 at 02:28:16PM +, John Harrison wrote:
> > > On 13/02/2015 17:03, Chris Wilson wrote:
> > > >On Fri, Feb 13, 2015 at 04:58:24PM +, John Har
On Fri, Feb 27, 2015 at 12:45:19PM +, John Harrison wrote:
> On 25/02/2015 21:15, Daniel Vetter wrote:
> >On Wed, Feb 18, 2015 at 03:27:38PM +, John Harrison wrote:
> >>On 13/02/2015 12:15, Chris Wilson wrote:
> >>>On Fri, Feb 13, 2015 at 11:48:33AM +, john.c.harri...@intel.com wrote:
>
Reviewed-by: Sonika Jindal
On 2/27/2015 4:41 PM, Jani Nikula wrote:
Add a number of DPCD definitions from eDP 1.4.
v2: s/DP_ALPM_LOCK_TIMEOUT_ERROR_STATUS/DP_ALPM_LOCK_TIMEOUT_ERROR/
(Sonika)
Signed-off-by: Jani Nikula
---
include/drm/drm_dp_helper.h | 37 +
On Fri, Feb 27, 2015 at 12:34:29PM +, John Harrison wrote:
> On 25/02/2015 21:08, Daniel Vetter wrote:
> >On Fri, Feb 13, 2015 at 12:21:29PM +, Chris Wilson wrote:
> >>On Fri, Feb 13, 2015 at 11:48:17AM +, john.c.harri...@intel.com wrote:
> >>>From: John Harrison
> >>>
> >>>The alloc_r
From: Ben Widawsky
The problem is we're going to switch to a new context, which could be
the default context. The plan was to use restore inhibit, which would be
fine, except if we are using dynamic page tables (which we will). If we
use dynamic page tables and we don't load new page tables, the
On Fri, Feb 27, 2015 at 12:27:15PM +, John Harrison wrote:
> On 25/02/2015 22:22, Daniel Vetter wrote:
> >On Fri, Feb 13, 2015 at 11:48:16AM +, john.c.harri...@intel.com wrote:
> >>From: John Harrison
> >>
> >>Start of explicit request management in the execbuffer code path. This patch
> >
From: Ben Widawsky
This patch just breaks out the logic of context switch skip.
It also adds pd load pre, and pd load post logic (for GEN8).
v2: Use new functions to replace the logic right away (Daniel)
v3: Add missing pd load logic.
Cc: Daniel Vetter
Signed-off-by: Ben Widawsky
Signed-off-
On Fri, Feb 27, 2015 at 12:22:42PM +, John Harrison wrote:
> On 25/02/2015 21:52, Daniel Vetter wrote:
> >On Fri, Feb 13, 2015 at 11:48:13AM +, john.c.harri...@intel.com wrote:
> >>From: John Harrison
> >>
> >>The do_execbuf() function takes quite a few parameters. The actual set of
> >>pa
On Fri, Feb 27, 2015 at 12:14:06PM +, John Harrison wrote:
> On 25/02/2015 21:34, Daniel Vetter wrote:
> >On Fri, Feb 13, 2015 at 11:48:10AM +, john.c.harri...@intel.com wrote:
> >>From: John Harrison
> >>
> >>There is a flags word that is passed through the execbuffer code path all
> >>t
On Fri, Feb 27, 2015 at 01:12:46PM +0200, Jani Nikula wrote:
>
> Apologies, this was supposed to be in reply to
> http://mid.gmane.org/54eeecc9.4010...@intel.com
>
>
> On Fri, 27 Feb 2015, Jani Nikula wrote:
> > Add a number of DPCD definitions from DP 1.1 and 1.2a.
> >
> > v2: drop wrong DP ve
On Wed, Feb 25, 2015 at 10:31:13PM +0100, Daniel Vetter wrote:
> On Wed, Feb 18, 2015 at 02:28:16PM +, John Harrison wrote:
> > On 13/02/2015 17:03, Chris Wilson wrote:
> > >On Fri, Feb 13, 2015 at 04:58:24PM +, John Harrison wrote:
> > >>On 13/02/2015 12:19, Chris Wilson wrote:
> > >>>On F
On 25/02/2015 21:31, Daniel Vetter wrote:
On Wed, Feb 18, 2015 at 02:28:16PM +, John Harrison wrote:
On 13/02/2015 17:03, Chris Wilson wrote:
On Fri, Feb 13, 2015 at 04:58:24PM +, John Harrison wrote:
On 13/02/2015 12:19, Chris Wilson wrote:
On Fri, Feb 13, 2015 at 11:48:56AM +, j
On 25/02/2015 21:15, Daniel Vetter wrote:
On Wed, Feb 18, 2015 at 03:27:38PM +, John Harrison wrote:
On 13/02/2015 12:15, Chris Wilson wrote:
On Fri, Feb 13, 2015 at 11:48:33AM +, john.c.harri...@intel.com wrote:
From: John Harrison
In execlist mode, context initialisation is deferre
On 25/02/2015 21:08, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 12:21:29PM +, Chris Wilson wrote:
On Fri, Feb 13, 2015 at 11:48:17AM +, john.c.harri...@intel.com wrote:
From: John Harrison
The alloc_request() function does not actually return the newly allocated
request. Instead, it
On 25/02/2015 22:22, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 11:48:16AM +, john.c.harri...@intel.com wrote:
From: John Harrison
Start of explicit request management in the execbuffer code path. This patch
adds a call to allocate a request structure before all the actual hardware work
On 25/02/2015 21:52, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 11:48:13AM +, john.c.harri...@intel.com wrote:
From: John Harrison
The do_execbuf() function takes quite a few parameters. The actual set of
parameters is going to change with the conversion to passing requests around.
Furth
On Thu, Feb 26, 2015 at 09:01:27PM +0100, Daniel Vetter wrote:
> On Thu, Feb 26, 2015 at 08:50:48PM +0200, Imre Deak wrote:
[snip]
> >
> > The problem seems to be that after the kernel puts the device into D3
> > the BIOS still tries to access it, or otherwise assumes that it's in D0.
> > This is
On 25/02/2015 21:34, Daniel Vetter wrote:
On Fri, Feb 13, 2015 at 11:48:10AM +, john.c.harri...@intel.com wrote:
From: John Harrison
There is a flags word that is passed through the execbuffer code path all the
way from initial decoding of the user parameters down to the very final dispatc
Originally it was impossible to be dropping the last refcount in this
function since there was always one around still from the idr. But in
commit 83f45fc360c8e16a330474860ebda872d1384c8c
Author: Daniel Vetter
Date: Wed Aug 6 09:10:18 2014 +0200
drm: Don't grab an fb reference for the idr
1 - 100 of 124 matches
Mail list logo
