On Monday 09 March 2015 02:16 PM, Daniel Vetter wrote:
On Mon, Mar 09, 2015 at 08:33:27AM +0530, sonika wrote:
On Thursday 05 March 2015 06:24 PM, Daniel Vetter wrote:
On Thu, Mar 05, 2015 at 02:51:26PM +0530, Sonika Jindal wrote:
Signed-off-by: Sonika Jindal
Imo this needs a little more co
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Monday, March 09, 2015 8:02 PM
> To: Zou, Nanhai
> Cc: Daniel Vetter; Song, Ruiling; Vetter, Daniel;
> intel-gfx@lists.freedesktop.org;
> Yang, Rong R; beig...@lists.freedesktop.org; Weinehall, David
> Subj
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 we also inv
On 19/02/2015 17:18, john.c.harri...@intel.com wrote:
From: John Harrison
In _i915_add_request(), the request is associated with a userland client.
Specifically it is linked to the 'file' structure and the current user process
is recorded. One problem here is that the current user process is no
On 19/02/2015 17:18, john.c.harri...@intel.com wrote:
From: John Harrison
The outstanding_lazy_request is no longer used anywhere in the driver.
Everything that was looking at it now has a request explicitly passed in from on
high. Everything that was relying upon behind the scenes is now expli
On 19/02/2015 17:18, john.c.harri...@intel.com wrote:
From: John Harrison
Much of the driver has now been converted to passing requests around instead of
rings/ringbufs/contexts. Thus the function for retreiving the request from a
ring (i.e. the OLR) is no longer used and can be removed.
For:
On 19/02/2015 17:18, john.c.harri...@intel.com wrote:
From: John Harrison
Now that everything above has been converted to use requests,
intel_logical_ring_begin() can be updated to take a request instead of a
ringbuf/context pair. This also means that it no longer needs to lazily allocate
a req
On 19/02/2015 17:18, john.c.harri...@intel.com wrote:
From: John Harrison
The only usage of intel_logical_ring_begin() is within intel_lrc.c so it can be
made static. To avoid a forward declaration at the top of the file, it and bunch
of other functions have been shuffled upwards.
For: VIZ-511
From: Jeff McGee
tests/core_getparams needs the new libdrm interfaces for
querying subslice and EU counts.
For: VIZ-4636
Signed-off-by: Jeff McGee
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 16d6a2e..88a1c3d 100644
---
On Wed, Mar 04, 2015 at 04:33:17PM +0100, Daniel Vetter wrote:
> On Tue, Mar 03, 2015 at 03:21:59PM +0200, Ander Conselvan de Oliveira wrote:
> > For the atomic conversion, the mode set paths need to be changed to rely
> > on an atomic state instead of using the staged config. By using an
> > atomi
From: Jeff McGee
Values of device max compute units and max subslice obtained
directly from the driver should be more accurate than our own
ID-based lookup values. This is particularly important when a
single device ID may encompass more than one configuration. If
the driver cannot provide a vali
From: Jeff McGee
tests/core_getparams needs the new libdrm interfaces for
querying subslice and EU counts.
For: VIZ-4636
Signed-off-by: Jeff McGee
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 16d6a2e..88a1c3d 100644
---
From: Jeff McGee
tests/core_getparams needs the new libdrm interfaces for
querying subslice and EU counts.
For: VIZ-4636
Signed-off-by: Jeff McGee
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 16d6a2e..88a1c3d 100644
---
From: Jeff McGee
New test core_getparams consists of 2 subtests, each one testing
the ability of userspace to query the correct value of a GT config
attribute: subslice total or EU total. drm/i915 implementation of
these queries is required for Cherryview and Gen9+ devices (non-
simulated).
For:
From: Jeff McGee
Signed-off-by: Jeff McGee
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 8afee83..278f29b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -20,7 +20,7 @@
AC_PREREQ([2.63])
AC_INIT([libdrm],
-[2.4
From: Jeff McGee
Update kernel interface with new I915_GETPARAM ioctl entries for
subslice total and EU total. Add a wrapping function for each
parameter. Userspace drivers need these values when constructing
GPGPU commands. This kernel query method is intended to replace
the PCI ID-based tables
From: Jeff McGee
Setup new I915_GETPARAM ioctl entries for subslice total and
EU total. Userspace drivers need these values when constructing
GPGPU commands. This kernel query method is intended to replace
the PCI ID-based tables that userspace drivers currently maintain.
The kernel driver can em
On 19/02/2015 17:18, john.c.harri...@intel.com wrote:
From: John Harrison
Now that everything above has been converted to use requests, intel_ring_begin()
can be updated to take a request instead of a ring. This also means that it no
longer needs to lazily allocate a request if no-one happens t
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5919
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 282/282
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated intel_ring_cacheline_align() to take a request instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/intel_display.c|2 +-
drivers/gpu/drm/i915/intel_ringbuffer.c |
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated the various ring->signal() implementations to take a request instead of
a ring. This removes their reliance on the OLR to obtain the seqno value that
should be used for the signal.
For: VIZ-5115
Signed-off-by: Jo
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated the ring->sync_to() implementations to take a request instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem.c |2 +-
drivers/gpu/drm/i915/intel_ringbuffer
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated the ring->emit_bb_start() implementation to take a request instead of a
ringbuf/context pair.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/intel_lrc.c| 12 +---
driver
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated the various ring->dispatch_execbuffer() implementations to take a
request instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 ++--
drivers/gp
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated the ring->emit_request() implementation to take a request instead of a
ringbuf/request pair. Also removed it's use of the OLR for obtaining the
request's seqno.
For: VIZ-5115
Signed-off-by: John Harrison
---
d
On Mon, Mar 09, 2015 at 12:07:31PM -0700, Jesse Barnes wrote:
> On 03/09/2015 10:29 AM, Daniel Vetter wrote:
> > On Mon, Mar 09, 2015 at 08:34:49AM -0700, Jesse Barnes wrote:
> >> On 03/06/2015 08:34 AM, Daniel Vetter wrote:
> >>> On Thu, Mar 05, 2015 at 11:22:19AM -0700, Todd Previte wrote:
>
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated the various ring->add_request() implementations to take a request
instead of a ring. This removes their reliance on the OLR to obtain the seqno
value that the request should be tagged with.
For: VIZ-5115
Signed-o
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated the various ring->emit_flush() implementations to take a request instead
of a ringbuf/context pair.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/intel_lrc.c| 17 ---
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated intel_emit_post_sync_nonzero_flush(), gen7_render_ring_cs_stall_wa(),
gen7_ring_fbc_flush() and gen8_emit_pipe_control() to take requests instead of
rings.
For: VIZ-5115
Signed-off-by: John Harrison
---
driver
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Udpated the various ring->flush() functions to take a request instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_context.c |2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated the switch_mm() code paths to take a request instead of a ring.
This commit message could be slightly clearer by saying specifically
what you changed rather than using the blanket expression "paths". You
coul
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated the *_ring_flush_all_caches() functions to take requests instead of
rings or ringbuf/context pairs.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem.c |4 ++--
drivers/
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated the *_ring_workarounds_emit() functions to take requests instead of
ring/context pairs.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/intel_lrc.c| 14 +++---
drivers/gp
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5918
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 282/282
From: Ville Syrjälä
commit a8c6ecb3be7029881f7c95e5e201a629094a4e1a
Merge: 8dd0eb35 9eccca0
Author: Dave Airlie
Date: Mon Mar 9 19:58:30 2015 +1000
Merge tag 'v4.0-rc3' into drm-next
managed to pick the wrong code to resolve the conflict and left us with
a mutex_lock(struct_mutex) withou
On 03/09/2015 10:29 AM, Daniel Vetter wrote:
> On Mon, Mar 09, 2015 at 08:34:49AM -0700, Jesse Barnes wrote:
>> On 03/06/2015 08:34 AM, Daniel Vetter wrote:
>>> On Thu, Mar 05, 2015 at 11:22:19AM -0700, Todd Previte wrote:
+ } else {
+ /* SST mode - handle short/long pulses here
Current ILK-style watermark code assumes the primary plane and cursor
plane are always enabled. This assumption, along with the combination
of two independent commits that got merged at the same time, results in
a NULL dereference. The offending commits are:
commit fd2d61341bf39d1054256c
On Mon, Mar 09, 2015 at 10:48:08AM -0700, Matt Roper wrote:
> On Mon, Mar 09, 2015 at 07:44:00PM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 09, 2015 at 10:19:25AM -0700, Matt Roper wrote:
> > > Current ILK-style watermark code assumes the primary plane and cursor
> > > plane are always enabled. T
On Thu, 19 Feb 2015, Todd Previte wrote:
> This patch is the amalgamation of 7 patches from the V2 series. These
> patches all involve the implementation of the debugfs mechanism for
> handling Displayport compliance testing. The following are the commit
> messages from those 7 patches (included h
On Mon, Mar 09, 2015 at 07:44:00PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 09, 2015 at 10:19:25AM -0700, Matt Roper wrote:
> > Current ILK-style watermark code assumes the primary plane and cursor
> > plane are always enabled. This assumption, along with the combination
> > of two independent co
On Mon, Mar 09, 2015 at 10:19:25AM -0700, Matt Roper wrote:
> Current ILK-style watermark code assumes the primary plane and cursor
> plane are always enabled. This assumption, along with the combination
> of two independent commits that got merged at the same time, results in
> a NULL dereference
On Mon, Mar 09, 2015 at 10:19:24AM -0700, Matt Roper wrote:
> Existing watermark code calls intel_crtc_active() to determine whether a CRTC
> is active for the purpose of watermark calculations (and bails out early if it
> determines the CRTC is not active). However intel_crtc_active() only return
On Mon, Mar 09, 2015 at 08:34:49AM -0700, Jesse Barnes wrote:
> On 03/06/2015 08:34 AM, Daniel Vetter wrote:
> > On Thu, Mar 05, 2015 at 11:22:19AM -0700, Todd Previte wrote:
> >> Update the hot plug function to handle the SST case. Instead of placing
> >> the SST case within the long/short pulse b
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5917
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 282/282
Existing watermark code calls intel_crtc_active() to determine whether a CRTC
is active for the purpose of watermark calculations (and bails out early if it
determines the CRTC is not active). However intel_crtc_active() only returns
true if crtc->primary->fb is non-NULL, which isn't appropriate i
With the switch to atomic plumbing for planes, some of our commit-time
work (e.g., watermarks) is done after the new atomic state is swapped
into the relevant DRM object, but before the DRM core has a chance to
update its legacy state values. Switch intel_crtc_active() to look at
the state objects
Current ILK-style watermark code assumes the primary plane and cursor
plane are always enabled. This assumption, along with the combination
of two independent commits that got merged at the same time, results in
a NULL dereference. The offending commits are:
commit fd2d61341bf39d1054256c
Simplified the series of fixes; we leave intel_crtc->active alone for now
(since it's tightly tied to our current legacy modeset pipeline) and use it in
place of intel_crtc_active() in the watermark code. As Ander's work on atomic
CRTC state progresses, some of the places we use intel_crtc->active
On Mon, Mar 09, 2015 at 05:29:44PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 09, 2015 at 11:44:05AM +, Chris Wilson wrote:
> > On a noisy link, we may retry the EDID reads multiple times per block
> > and still succeed. In such cases, we don't want to flood the kernel logs
> > with *ERROR* mess
On Sun, Mar 08, 2015 at 02:00:43PM -0700, Matt Roper wrote:
> With the switch to atomic plumbing for planes, some of our commit-time
> work (e.g., watermarks) is done after the new atomic state is swapped
> into the relevant DRM object, but before the DRM core has a chance to
> update its legacy st
On Mon, Mar 09, 2015 at 02:17:58PM +, Damien Lespiau wrote:
> Static analysis was complaining that a path existed where we could use
> stat[] uninitialized. Fix this by simplifying the logic to exit early if
> PSR isn't supported.
>
> Signed-off-by: Damien Lespiau
Queued for -next, thanks fo
On Sun, Mar 08, 2015 at 02:00:42PM -0700, Matt Roper wrote:
> Replace all uses of intel_crtc->active with crtc->state->active. At the
> moment we don't have atomic state handling wired up for CRTC's so this
> means we just directly set the state active field at various points in
> our (legacy) mod
On Mon, Mar 09, 2015 at 06:04:46PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 09, 2015 at 03:39:01PM +, Chris Wilson wrote:
> > On Mon, Mar 09, 2015 at 05:29:44PM +0200, Ville Syrjälä wrote:
> > > On Mon, Mar 09, 2015 at 11:44:05AM +, Chris Wilson wrote:
> > > > On a noisy link, we may retry
On Sun, Mar 08, 2015 at 02:00:41PM -0700, Matt Roper wrote:
> From: Matt Roper
>
> Since our legacy modeset paths directly kzalloc CRTC state objects at
> the moment rather than calling intel_crtc_duplicate_state(), we need to
> manually ensure the ->crtc backpointer is always initialized.
>
> S
On Mon, Mar 09, 2015 at 09:40:50AM +0100, Daniel Vetter wrote:
> On Fri, Mar 06, 2015 at 05:38:33PM -0800, Jeff McGee wrote:
> > On Fri, Feb 27, 2015 at 10:22:30AM -0800, jeff.mc...@intel.com wrote:
> > > From: Jeff McGee
> > >
> > > These two patches add detection of available and enabled
> > >
On Mon, Mar 09, 2015 at 11:33:57AM +0200, Ander Conselvan De Oliveira wrote:
> On Mon, 2015-03-09 at 11:24 +0200, Jani Nikula wrote:
> > On Mon, 09 Mar 2015, Ander Conselvan de Oliveira
> > wrote:
> > > When enabling pipe C, the check for the number of lanes pipe B uses was
> > > ignored in case
On Mon, Mar 09, 2015 at 03:39:01PM +, Chris Wilson wrote:
> On Mon, Mar 09, 2015 at 05:29:44PM +0200, Ville Syrjälä wrote:
> > On Mon, Mar 09, 2015 at 11:44:05AM +, Chris Wilson wrote:
> > > On a noisy link, we may retry the EDID reads multiple times per block
> > > and still succeed. In su
On Sun, Mar 08, 2015 at 02:00:44PM -0700, Matt Roper wrote:
> Existing watermark code calls intel_crtc_active() to determine whether a CRTC
> is active for the purpose of watermark calculations (and bails out early if it
> determines the CRTC is not active). However intel_crtc_active() only return
On Mon, Mar 09, 2015 at 08:18:05AM -0700, Jesse Barnes wrote:
> On 03/09/2015 02:03 AM, Daniel Vetter wrote:
> > On Sat, Mar 07, 2015 at 12:09:08AM +, Damien Lespiau wrote:
> >> On Fri, Mar 06, 2015 at 03:53:32PM -0800, Jesse Barnes wrote:
> >>> So try to enumerate eDP unconditionally in those
On Sun, Mar 08, 2015 at 02:00:43PM -0700, Matt Roper wrote:
> With the switch to atomic plumbing for planes, some of our commit-time
> work (e.g., watermarks) is done after the new atomic state is swapped
> into the relevant DRM object, but before the DRM core has a chance to
> update its legacy st
On 03/09/2015 08:46 AM, Jesse Barnes wrote:
> On 03/05/2015 01:07 PM, Chris Wilson wrote:
>> On Thu, Mar 05, 2015 at 04:27:59PM +0100, Daniel Vetter wrote:
>>> I recommended exposing the PIN_BIAS since that will work without full
>>> ppgtt too. And yeah for full ppgtt we could just use svm where us
On 03/05/2015 01:07 PM, Chris Wilson wrote:
> On Thu, Mar 05, 2015 at 04:27:59PM +0100, Daniel Vetter wrote:
>> I recommended exposing the PIN_BIAS since that will work without full
>> ppgtt too. And yeah for full ppgtt we could just use svm where userspace
>> controls the address, but since that's
On Sun, Mar 08, 2015 at 02:00:42PM -0700, Matt Roper wrote:
> Replace all uses of intel_crtc->active with crtc->state->active. At the
> moment we don't have atomic state handling wired up for CRTC's so this
> means we just directly set the state active field at various points in
> our (legacy) mod
On 03/06/2015 08:34 AM, Daniel Vetter wrote:
> On Thu, Mar 05, 2015 at 11:22:19AM -0700, Todd Previte wrote:
>> Update the hot plug function to handle the SST case. Instead of placing
>> the SST case within the long/short pulse block, it is now handled after
>> determining that MST mode is not in u
On Mon, Mar 09, 2015 at 05:29:44PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 09, 2015 at 11:44:05AM +, Chris Wilson wrote:
> > On a noisy link, we may retry the EDID reads multiple times per block
> > and still succeed. In such cases, we don't want to flood the kernel logs
> > with *ERROR* mess
On Mon, Mar 09, 2015 at 02:54:56PM +0530, Mohan Marimuthu, Yogesh wrote:
> Reviewed-by: Yogesh Mohan Marimuthu
>
> Thank you,
> Yogesh
>
> On 3/9/2015 2:29 PM, Purushothaman, Vijay A wrote:
> >On 3/2/2015 11:37 PM, ville.syrj...@linux.intel.com wrote:
> >>From: Ville Syrjälä
> >>
> >>The specs
On 03/06/2015 07:06 AM, Chris Wilson wrote:
> When we idle, we set the GPU frequency to the hardware minimum (not user
> minimum). We introduce a new variable to distinguish between the
> different roles, and to allow easy tuning of the idle frequency without
> impacting over aspects of RPS. Settin
On Mon, Mar 09, 2015 at 05:00:09PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 09, 2015 at 10:14:05AM +0530, Arun R Murthy wrote:
> >
> > On Friday 06 March 2015 12:49 AM, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > DDR DVFS introduces massive memory latencies which c
On Mon, Mar 09, 2015 at 11:44:05AM +, Chris Wilson wrote:
> On a noisy link, we may retry the EDID reads multiple times per block
> and still succeed. In such cases, we don't want to flood the kernel logs
> with *ERROR* messages as we then succeed. Refactor the EDID dumping and
> push it into t
On Mon, Mar 09, 2015 at 05:20:39PM +0200, Ville Syrjälä wrote:
> On Mon, Mar 09, 2015 at 09:46:27AM +0100, Daniel Vetter wrote:
> > On Mon, Mar 09, 2015 at 08:33:27AM +0530, sonika wrote:
> > >
> > > On Thursday 05 March 2015 06:24 PM, Daniel Vetter wrote:
> > > >On Thu, Mar 05, 2015 at 02:51:26PM
On Mon, Mar 09, 2015 at 09:46:27AM +0100, Daniel Vetter wrote:
> On Mon, Mar 09, 2015 at 08:33:27AM +0530, sonika wrote:
> >
> > On Thursday 05 March 2015 06:24 PM, Daniel Vetter wrote:
> > >On Thu, Mar 05, 2015 at 02:51:26PM +0530, Sonika Jindal wrote:
> > >>Signed-off-by: Sonika Jindal
> > >Imo
On 03/09/2015 02:03 AM, Daniel Vetter wrote:
> On Sat, Mar 07, 2015 at 12:09:08AM +, Damien Lespiau wrote:
>> On Fri, Mar 06, 2015 at 03:53:32PM -0800, Jesse Barnes wrote:
>>> So try to enumerate eDP unconditionally in those cases.
>>>
>>> Signed-off-by: Jesse Barnes
>>
>> That's WaIgnoreDDIAS
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5916
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -2 282/282
On Mon, Mar 09, 2015 at 10:14:05AM +0530, Arun R Murthy wrote:
>
> On Friday 06 March 2015 12:49 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > DDR DVFS introduces massive memory latencies which can't be handled by
> > the PND deadline stuff. Instead the watermarks will
On Mon, Mar 09, 2015 at 09:18:37AM +0530, Arun R Murthy wrote:
>
> On Friday 06 March 2015 12:49 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Kill the silly DRAIN_LATENCY_PRECISION_* defines and just use the raw
> > number instead.
> >
> > v2: Move the sprite 32/16 ->
GGTT views are only applicable when dealing with GGTT. Change the code to
reject ggtt_view where it should not be used and require it when it should
be.
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 91
drivers/gpu/drm/i915/i915_gem.c | 13
Static analysis was complaining that a path existed where we could use
stat[] uninitialized. Fix this by simplifying the logic to exit early if
PSR isn't supported.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_debugfs.c | 27 +++
1 file changed, 15 insertio
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5915
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 282/282
On Sun, Mar 08, 2015 at 05:17:05PM -0700, shuang...@intel.com wrote:
> Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang...@intel.com)
> Task id: 5912
> -Summary-
> Platform Delta drm-int
On Mon, Mar 09, 2015 at 02:34:46AM +, Zou, Nanhai wrote:
> We don't need MAP_FIXED, we just want to avoid address 0 to be allocated.
>
> Though I think using MAP_FIXED is overkill, will bring much unnecessary
> complexity on both kernel and beignet side.
> I don't mind if people can provide s
On a noisy link, we may retry the EDID reads multiple times per block
and still succeed. In such cases, we don't want to flood the kernel logs
with *ERROR* messages as we then succeed. Refactor the EDID dumping and
push it into the caller rather than the validator so we can suppress the
warnings fr
On Fri, Mar 06, 2015 at 05:48:26PM +0100, Daniel Vetter wrote:
> On Fri, Mar 06, 2015 at 08:54:35AM +, Chris Wilson wrote:
> > On Thu, Mar 05, 2015 at 01:27:43PM +0100, Daniel Vetter wrote:
> > > On Wed, Mar 04, 2015 at 06:09:26PM +, Chris Wilson wrote:
> > > > This fixes a regression from
I woke up one morning and found 50k objects sitting in the batch pool
and every search seemed to iterate the entire list... Painting the
screen in oils would provide a more fluid display.
One issue with the current design is that we only check for retirements
on the current ring when preparing to
Move the madvise logic out of the execbuffer main path into the
relatively rare allocation path, making the execbuffer manipulation less
fragile.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 12 +++--
drivers/gpu/drm/i915/i915_gem_batch_pool.c | 39 +++
Now with the trimmed memcpy before the command parser, we try to
allocate many different sizes of batches, predominantly one or two
pages. We can therefore speed up searching for a good sized batch by
keeping the objects of buckets of roughly the same size.
Signed-off-by: Chris Wilson
---
driver
At runtime, this helps ensure that the batch pools are kept trim and
fast. Then at suspend, this releases memory that we do not need to
restore. It also ties into the oom-notifier to ensure that we recover as
much kernel memory as possible during OOM.
Signed-off-by: Chris Wilson
---
drivers/gpu/
Since we use obj->active as a hint in many places throughout the code,
knowing its state in debugfs is extremely useful.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
In the next patch, I want to use the structure elsewhere and so require
it defined earlier. Rather than move the definition to an earlier location
where it feels very odd, place it in its own header file.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 13 +
On Mon, 2015-03-09 at 11:24 +0200, Jani Nikula wrote:
> On Mon, 09 Mar 2015, Ander Conselvan de Oliveira
> wrote:
> > When enabling pipe C, the check for the number of lanes pipe B uses was
> > ignored in case pipe B wasn't active. This would allow pipe C to be
> > configured while pipe B is in D
Reviewed-by: Yogesh Mohan Marimuthu
Thank you,
Yogesh
On 3/9/2015 2:29 PM, Purushothaman, Vijay A wrote:
On 3/2/2015 11:37 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
The specs seem to be full of misinformation wrt. the Punit register
0x36. Some versions still show the old
Reviewed-by: Yogesh Mohan Marimuthu
Thank you,
Yogesh
On 3/9/2015 2:28 PM, Purushothaman, Vijay A wrote:
On 3/2/2015 11:37 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Supposedly CHV can sustain a pixel clock of up to 95% of
cdclk, as opposed to the 90% limit that was used
On Mon, 09 Mar 2015, Ander Conselvan de Oliveira
wrote:
> When enabling pipe C, the check for the number of lanes pipe B uses was
> ignored in case pipe B wasn't active. This would allow pipe C to be
> configured while pipe B is in DPMS off state even if it used more than 2
> lanes. Making pipe B
On Sat, Mar 07, 2015 at 12:09:08AM +, Damien Lespiau wrote:
> On Fri, Mar 06, 2015 at 03:53:32PM -0800, Jesse Barnes wrote:
> > So try to enumerate eDP unconditionally in those cases.
> >
> > Signed-off-by: Jesse Barnes
>
> That's WaIgnoreDDIAStrap, I assumed it actually worked since my eDP
On 3/2/2015 11:37 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
The specs seem to be full of misinformation wrt. the Punit register
0x36. Some versions still show the old VLV bit layout, some the new
layout, and all of them seem to tell us nonsense about the cdclk
value encoding.
When enabling pipe C, the check for the number of lanes pipe B uses was
ignored in case pipe B wasn't active. This would allow pipe C to be
configured while pipe B is in DPMS off state even if it used more than 2
lanes. Making pipe B active again while pipe C was also active would
then fail.
Teste
On 3/2/2015 11:37 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Supposedly CHV can sustain a pixel clock of up to 95% of
cdclk, as opposed to the 90% limit that was used old older
platforms. Update the cdclk selection code to allow for this.
This will allow eg. HDMI 4k modes wit
On Fri, Mar 06, 2015 at 04:28:16PM -0300, Paulo Zanoni wrote:
> 2015-03-06 15:50 GMT-03:00 Damien Lespiau :
> > Here's a new spin of the series, restoring interrupt registers and DDI
> > translation tables when re-enabling power-wells.
> >
> > v2:
> > - Don't run the post-enable hook when the pow
On Fri, Mar 06, 2015 at 06:50:48PM +, Damien Lespiau wrote:
> While we only need to restore pipe B/C interrupt registers on BDW when
> enabling the power well, skylake a bit more flexible and we'll also need
> to restore the pipe A registers as it has its own power well that can be
> toggled.
>
On Mon, Mar 09, 2015 at 08:33:27AM +0530, sonika wrote:
>
> On Thursday 05 March 2015 06:24 PM, Daniel Vetter wrote:
> >On Thu, Mar 05, 2015 at 02:51:26PM +0530, Sonika Jindal wrote:
> >>Signed-off-by: Sonika Jindal
> >Imo this needs a little more commit message, and more important it needs
> >ig
On Fri, Mar 06, 2015 at 05:38:33PM -0800, Jeff McGee wrote:
> On Fri, Feb 27, 2015 at 10:22:30AM -0800, jeff.mc...@intel.com wrote:
> > From: Jeff McGee
> >
> > These two patches add detection of available and enabled
> > slice/subslice/EU on CHV following the implementation recently
> > merged f
1 - 100 of 101 matches
Mail list logo