On Thu, 2015-03-19 at 20:58 +, Konduru, Chandra wrote:
>
> > -Original Message-
> > From: Conselvan De Oliveira, Ander
> > Sent: Friday, March 13, 2015 2:49 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
> > Subject: [PATCH 16/19] drm/
On Thu, 2015-03-19 at 20:55 +, Konduru, Chandra wrote:
>
> > -Original Message-
> > From: Conselvan De Oliveira, Ander
> > Sent: Friday, March 13, 2015 2:49 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
> > Subject: [PATCH 05/19] drm/
On Thu, 2015-03-19 at 19:24 +, Konduru, Chandra wrote:
>
> > -Original Message-
> > From: Conselvan De Oliveira, Ander
> > Sent: Friday, March 13, 2015 2:49 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
> > Subject: [PATCH 17/19] drm/
We make use of HW tracking for Selective update region and enable frame sync on
sink. We use hardware's hardcoded data values for frame sync and GTC.
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/i915_reg.h | 14 ++
drivers/gpu/drm/i915/intel_dp.c | 16
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6011
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -2 274/274
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6010
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -2 274/274
> Yeah my big concern was with not making this opt-in like the old patch or
> adding an interface which does a lot more than what we need right now
> (Chris' patch). Just a bitflag to ask for this seems best and is fine with me.
>
> And for the implementation I think we should reuse the PIN_BIAS
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6009
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 272/272
Actually, I sent to piglit ML before intel-gfx ML.
Why It's here is because many internal guys don't subscribe to piglit ML.
Best Regards
Ethan, Gao
-Original Message-
From: Lespiau, Damien
Sent: Friday, March 20, 2015 1:16 AM
To: Gao, Ethan
Cc: intel-gfx@lists.freedesktop.org
Subject: R
This will allow manual tests when crc isn't available.
v2: Remove unused and non-sense buf->size and decrease buf->stride a bit as
suggested by Daniel.
Signed-off-by: Rodrigo Vivi
---
tests/kms_psr_sink_crc.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/tests/kms_ps
This is an extention of igt_debug_wait_for_keypress that also can have
customized message and return key pressed.
v2: This is actualy a v2. V1 was an extension of original
igt_debug_wait_for_keypress but it was nacked.
v3: Make [Y/n] check inside aux function as suggested by Daniel.
Also
> -Original Message-
> From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
> Sent: Thursday, March 19, 2015 12:52 AM
> To: Konduru, Chandra
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 04/19] drm/i915: Allocate a crtc_state also when the crtc
> is
> being disab
On Thu, Mar 19, 2015 at 06:37:28PM +0100, Daniel Vetter wrote:
> On Wed, Mar 18, 2015 at 06:19:22PM +, Chris Wilson wrote:
> > WARNING: CPU: 0 PID: 1383 at drivers/gpu/drm/i915/i915_gem_evict.c:279
> > i915_gem_evict_vm+0x10c/0x140()
> > WARN_ON(!list_empty(&vm->active_list))
>
> How
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6006
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 272/272
On 03/19/2015 01:57 PM, Imre Deak wrote:
> On Thu, 2015-03-19 at 13:53 -0700, Jesse Barnes wrote:
>> On 03/17/2015 02:40 AM, Imre Deak wrote:
>>> The checks for PLL enabled state on CPU ports are valid only on GMCH
>>> platforms but atm we'd also call them on non-PCH-split/non-GMCH
>>> platforms li
On Thu, Mar 19, 2015 at 05:35:35PM +, Tvrtko Ursulin wrote:
> >-list_for_each_entry_safe(tmp, next,
> >- &pool->cache_list, batch_pool_list) {
> >+n = fls(size >> PAGE_SHIFT) - 1;
>
> Is this better in some way that size / PAGE_SIZE - 1? Or I went from
> tru
> -Original Message-
> From: Conselvan De Oliveira, Ander
> Sent: Friday, March 13, 2015 2:49 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
> Subject: [PATCH 03/19] drm/i915: Allocate a drm_atomic_state for the legacy
> modeset code
>
> For
On Thu, Mar 19, 2015 at 05:37:30PM +, Tvrtko Ursulin wrote:
> >diff --git a/drivers/gpu/drm/i915/i915_gem_batch_pool.h
> >b/drivers/gpu/drm/i915/i915_gem_batch_pool.h
> >new file mode 100644
> >index ..5ed70ef6a887
> >--- /dev/null
> >+++ b/drivers/gpu/drm/i915/i915_gem_batch_pool.
On Thu, Mar 19, 2015 at 05:41:26PM +, Tvrtko Ursulin wrote:
>
> On 03/09/2015 09:55 AM, Chris Wilson wrote:
> >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
On Thu, Mar 19, 2015 at 05:49:44PM +, Michel Thierry wrote:
> On 3/19/2015 5:18 PM, Chris Wilson wrote:
> >On Thu, Mar 19, 2015 at 05:11:17PM +, Michel Thierry wrote:
> >>diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> >>b/drivers/gpu/drm/i915/i915_gpu_error.c
> >>index bbf25d0..18f7a
> -Original Message-
> From: Conselvan De Oliveira, Ander
> Sent: Friday, March 13, 2015 2:49 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
> Subject: [PATCH 16/19] drm/i915: Check lane sharing between pipes B & C using
> atomic state
>
> M
On Thu, 2015-03-19 at 13:53 -0700, Jesse Barnes wrote:
> On 03/17/2015 02:40 AM, Imre Deak wrote:
> > The checks for PLL enabled state on CPU ports are valid only on GMCH
> > platforms but atm we'd also call them on non-PCH-split/non-GMCH
> > platforms like BXT, triggering false warnings. Until the
On 03/19/2015 01:55 PM, Imre Deak wrote:
> On Thu, 2015-03-19 at 13:34 -0700, Jesse Barnes wrote:
>> On 03/17/2015 02:40 AM, Imre Deak wrote:
>>> Prepare chv_find_best_dpll to be used for BXT too, where we want to
>>> consider the error between target and calculated frequency too when
>>> choosing
> -Original Message-
> From: Conselvan De Oliveira, Ander
> Sent: Friday, March 13, 2015 2:49 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
> Subject: [PATCH 05/19] drm/i915: Update dummy connector atomic state with
> current config
>
> Kee
On Thu, 2015-03-19 at 13:34 -0700, Jesse Barnes wrote:
> On 03/17/2015 02:40 AM, Imre Deak wrote:
> > Prepare chv_find_best_dpll to be used for BXT too, where we want to
> > consider the error between target and calculated frequency too when
> > choosing a better PLL configuration.
> >
> > No func
On 03/17/2015 02:40 AM, Imre Deak wrote:
> The checks for PLL enabled state on CPU ports are valid only on GMCH
> platforms but atm we'd also call them on non-PCH-split/non-GMCH
> platforms like BXT, triggering false warnings. Until the proper check is
> implented for these platforms simply disable
On 03/17/2015 02:40 AM, Imre Deak wrote:
> From: Satheeshakrishna M
>
> Add placeholder function for calculating programmed pixel clock.
> Note: Formula to back calculate link clock from dividers not
> available currently.
>
> v2:
> - rebased on upstream s/crtc_config/crtc_state/ change (imre)
>
On 03/17/2015 02:40 AM, Imre Deak wrote:
> From: Satheeshakrishna M
>
> Determine PLL attached to pipe (which is same as DDI PLL)
>
> v2:
> - rebased on upstream s/crtc_config/crtc_state/ (imre)
>
> Signed-off-by: Satheeshakrishna M (v1)
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i91
On 03/17/2015 02:40 AM, Imre Deak wrote:
> From: Satheeshakrishna M
>
> Assign PLL for pipe (dependent on port attached to the pipe)
>
> v2:
> - fix incorrect encoder vs. new_encoder check for crtc (imre)
>
> v3:
> - warn and return error if no encoder is attached (imre)
>
> Signed-off-by: Sat
On 03/17/2015 02:40 AM, Imre Deak wrote:
> From: Satheeshakrishna M
>
> Calculate and cache clock parameters. Follow bspec algorithm for HDMI.
> Use precalculated values for DisplayPort linkrates.
>
> v2: (imre)
> - rebase against upstream crtc_state change
> - use the existing CHV based helper
On 03/17/2015 02:40 AM, Imre Deak wrote:
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_display.c | 32
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> 2 files changed, 30 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_
> -Original Message-
> From: Conselvan De Oliveira, Ander
> Sent: Friday, March 13, 2015 2:49 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
> Subject: [PATCH 19/19] drm/i915: Remove usage of encoder->new_crtc from
> clock computations
>
> S
On 03/17/2015 02:40 AM, Imre Deak wrote:
> Prepare chv_find_best_dpll to be used for BXT too, where we want to
> consider the error between target and calculated frequency too when
> choosing a better PLL configuration.
>
> No functional change.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/
On Thu, 2015-03-19 at 13:27 -0700, Jesse Barnes wrote:
> On 03/17/2015 02:40 AM, Imre Deak wrote:
> > + /*
> > +* FIXME: program PORT_PLL_9/i_lockthresh according to the latest
> > +* specification update.
> > +*/
> > +
>
> Current spec says "write 5 to i_lockthresh", but I guess tha
On 03/17/2015 02:40 AM, Imre Deak wrote:
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_display.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 7feb047..5874512 100644
> --- a/driv
On 03/17/2015 02:40 AM, Imre Deak wrote:
> Factor out the logic to decide whether the newly calculated dividers are
> better than the best found so far. Do this for clarity and to prepare
> for the upcoming BXT helper needing the same.
>
> No functional change.
>
> Signed-off-by: Imre Deak
> ---
On 03/17/2015 02:40 AM, Imre Deak wrote:
> + /*
> + * FIXME: program PORT_PLL_9/i_lockthresh according to the latest
> + * specification update.
> + */
> +
Current spec says "write 5 to i_lockthresh", but I guess that's not
needed for functionality so it can be added later.
Rev
On Tue, Mar 17, 2015 at 11:39:56AM +0200, Imre Deak wrote:
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b91862e..ba2d1ae 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8284,6 +8284,75 @
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6004
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 272/272
On Thu, Mar 19, 2015 at 04:16:41PM -0300, Paulo Zanoni wrote:
> 2015-03-18 19:04 GMT-03:00 Matt Roper :
> > Determining whether we'll need to wait for vblanks is something we
> > should determine during the atomic 'check' phase, not the 'commit'
> > phase. Note that we only set these bits in the b
On Thu, Mar 19, 2015 at 12:13:24PM -0700, Jesse Barnes wrote:
> On 03/19/2015 11:53 AM, Ville Syrjälä wrote:
> > On Thu, Mar 19, 2015 at 11:40:15AM -0700, Jesse Barnes wrote:
> >> On 03/19/2015 11:00 AM, Jesse Barnes wrote:
> >>> On 03/19/2015 10:42 AM, Daniel Vetter wrote:
> On Wed, Mar 18, 2
> -Original Message-
> From: Conselvan De Oliveira, Ander
> Sent: Friday, March 13, 2015 2:49 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
> Subject: [PATCH 17/19] drm/i915: Convert intel_pipe_will_have_type() to using
> atomic state
>
> P
From: Ville Syrjälä
Store the colorkey in intel_plane and kill off all the RMW stuff
handling it.
This is just an intermediate step and eventually the colorkey needs to
be converted into some properties.
v2: Actually update the hardware state in the set_colorkey ioctl (Daniel)
Signed-off-by: V
2015-03-18 19:04 GMT-03:00 Matt Roper :
> Determining whether we'll need to wait for vblanks is something we
> should determine during the atomic 'check' phase, not the 'commit'
> phase. Note that we only set these bits in the branch of 'check' where
> intel_crtc->active is true so that we don't t
On 03/19/2015 11:53 AM, Ville Syrjälä wrote:
> On Thu, Mar 19, 2015 at 11:40:15AM -0700, Jesse Barnes wrote:
>> On 03/19/2015 11:00 AM, Jesse Barnes wrote:
>>> On 03/19/2015 10:42 AM, Daniel Vetter wrote:
On Wed, Mar 18, 2015 at 11:41:48AM -0700, Jesse Barnes wrote:
> This updates my old p
On Thu, Mar 19, 2015 at 05:46:13PM +0100, Daniel Vetter wrote:
> On Thu, Mar 19, 2015 at 05:57:12PM +0200, ville.syrj...@linux.intel.com wrote:
> > @@ -1332,7 +1167,7 @@ int intel_sprite_set_colorkey(struct drm_device *dev,
> > void *data,
> > }
> >
> > intel_plane = to_intel_plane(plane
On Thu, Mar 19, 2015 at 11:40:15AM -0700, Jesse Barnes wrote:
> On 03/19/2015 11:00 AM, Jesse Barnes wrote:
> > On 03/19/2015 10:42 AM, Daniel Vetter wrote:
> >> On Wed, Mar 18, 2015 at 11:41:48AM -0700, Jesse Barnes wrote:
> >>> This updates my old patch for this, but w/o fixing the locking issue
On 03/19/2015 11:00 AM, Jesse Barnes wrote:
> On 03/19/2015 10:42 AM, Daniel Vetter wrote:
>> On Wed, Mar 18, 2015 at 11:41:48AM -0700, Jesse Barnes wrote:
>>> This updates my old patch for this, but w/o fixing the locking issue
>>> Ville mentioned. In looking at it, it seems like the sync point s
On 03/19/2015 10:44 AM, Daniel Vetter wrote:
> On Wed, Mar 18, 2015 at 11:41:48AM -0700, Jesse Barnes wrote:
>> This updates my old patch for this, but w/o fixing the locking issue
>> Ville mentioned. In looking at it, it seems like the sync point should
>> be at a higher level, maybe at the level
On 03/19/2015 10:42 AM, Daniel Vetter wrote:
> On Wed, Mar 18, 2015 at 11:41:48AM -0700, Jesse Barnes wrote:
>> This updates my old patch for this, but w/o fixing the locking issue
>> Ville mentioned. In looking at it, it seems like the sync point should
>> be at a higher level, maybe at the level
On 3/19/2015 5:18 PM, Chris Wilson wrote:
On Thu, Mar 19, 2015 at 05:11:17PM +, Michel Thierry wrote:
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index bbf25d0..18f7a2a 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i9
> -Original Message-
> From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of
> Daniel Vetter
> Sent: Wednesday, March 18, 2015 1:16 AM
> To: Konduru, Chandra
> Cc: intel-gfx; Conselvan De Oliveira, Ander; Vetter, Daniel
> Subject: Re: [Intel-gfx] [PATCH 08/21] drm/i915
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6003
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -2 272/272
On Wed, Mar 18, 2015 at 11:41:48AM -0700, Jesse Barnes wrote:
> This updates my old patch for this, but w/o fixing the locking issue
> Ville mentioned. In looking at it, it seems like the sync point should
> be at a higher level, maybe at the level of the atomic mode setting async
> serialization
On 03/09/2015 09:55 AM, Chris Wilson wrote:
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(-)
d
On Wed, Mar 18, 2015 at 11:41:48AM -0700, Jesse Barnes wrote:
> This updates my old patch for this, but w/o fixing the locking issue
> Ville mentioned. In looking at it, it seems like the sync point should
> be at a higher level, maybe at the level of the atomic mode setting async
> serialization
On 03/09/2015 09:55 AM, Chris Wilson wrote:
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
On Wed, Mar 18, 2015 at 06:19:22PM +, Chris Wilson wrote:
> If we retire requests last, we may use a later seqno and so clear
> the requests lists without clearing the active list, leading to
> confusion. Hence we should retire requests first for consistency with
> the early return. The order u
On 03/09/2015 09:55 AM, Chris Wilson wrote:
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
On Tue, Mar 17, 2015 at 11:39:57AM +0200, Imre Deak wrote:
> Extend the VLV/CHV DPIO (PHY) documentation with the BXT specifics.
>
> Signed-off-by: Imre Deak
> ---
> Documentation/DocBook/drm.tmpl | 4 ++--
> drivers/gpu/drm/i915/i915_reg.h | 10 +++---
> 2 files changed, 9 insertions(+),
On Thu, Mar 19, 2015 at 04:33:12PM +, John Harrison wrote:
> On 19/03/2015 15:16, Jani Nikula wrote:
> >On Thu, 19 Mar 2015, "Daniel, Thomas" wrote:
> >>>- if (&request->list == &ring->request_list)
> >>>+ /* It should always be possible to find a suitable request! */
> >>>+ if (&request->l
On 03/19/2015 05:14 PM, Chris Wilson wrote:
On Thu, Mar 19, 2015 at 05:03:56PM +, Tvrtko Ursulin wrote:
On 03/09/2015 09:55 AM, Chris Wilson wrote:
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
resto
On Thu, Mar 19, 2015 at 05:11:17PM +, Michel Thierry wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index bbf25d0..18f7a2a 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -545,7 +54
On 3/19/2015 4:13 PM, Daniel Vetter wrote:
On Mon, Mar 16, 2015 at 04:00:56PM +, Michel Thierry wrote:
+static inline uint32_t i915_pte_count(uint64_t addr, size_t length,
+ uint32_t pde_shift)
+{
+ const uint64_t mask = ~((1 << pde_shift) - 1);
+
On Thu, Mar 19, 2015 at 10:36:51AM +0800, ethan gao wrote:
> tests/igt.py: add igt env to enable or disable dmesg triage
> framework/test/base.py: trigger dmesg triage depending on dmesg log occurrence
> framework/dmesg.py: employ dmesg triage simply for Linux dmesg
> dmesg_triage/*: deal with kmsg
On Thu, Mar 19, 2015 at 05:03:56PM +, Tvrtko Ursulin wrote:
>
> On 03/09/2015 09:55 AM, Chris Wilson wrote:
> >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-notifi
While running kmemleak chasing a different memleak, I saw that the
capture_error_state function was leaking some objects, for example:
unreferenced object 0x8800a9b72148 (size 8192):
comm "kworker/u16:0", pid 1499, jiffies 4295201243 (age 990.096s)
hex dump (first 32 bytes):
00 00 04 0
On Tue, Mar 17, 2015 at 11:39:54AM +0200, Imre Deak wrote:
> From: Satheeshakrishna M
>
> Add BXT power domains
>
> v2: Use DOMAIN_PLLS instead of a new CDCLK one, whitespace fixes
> (Damien)
> v3: add VGA, TRANSCODER_A power domains (imre)
>
> Signed-off-by: Satheeshakrishna M (v1)
> Sign
On 03/09/2015 09:55 AM, Chris Wilson wrote:
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.
On Thu, Mar 19, 2015 at 04:39:06PM +, Damien Lespiau wrote:
> On Thu, Mar 19, 2015 at 11:29:40AM +, Chris Wilson wrote:
> > The existing ABI says that scanouts are pinned into the mappable region
> > so that legacy clients (e.g. old Xorg or plymouthd) can write directly
> > into the scanout
On Thu, Mar 19, 2015 at 05:34:09PM +0100, Daniel Vetter wrote:
> On Thu, Mar 19, 2015 at 01:10:13PM +, Chris Wilson wrote:
> > On Thu, Mar 19, 2015 at 06:31:04PM +0530, Deepak S wrote:
> > > should we skip put_fence in overlay_do_put_image ?
> >
> > Ah interesting point you raise there. That i
On Thu, Mar 19, 2015 at 05:35:17PM +0100, Daniel Vetter wrote:
> On Thu, Mar 19, 2015 at 11:29:40AM +, Chris Wilson wrote:
> > The existing ABI says that scanouts are pinned into the mappable region
> > so that legacy clients (e.g. old Xorg or plymouthd) can write directly
> > into the scanout
On 17/03/2015 09:39, Imre Deak wrote:
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_pm.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b89ab4d..3d4a7c3 100644
--- a/drivers/gpu
On 17/03/2015 09:39, Imre Deak wrote:
From: Nick Hoath
Adds framework for Broxton HW WAs
Signed-off-by: Nick Hoath
Signed-off-by: Imre Deak
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --
On Thu, Mar 19, 2015 at 05:57:11PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> intel_plane->obj is not used anymore so kill it. Also don't pass both
> the fb and obj to the sprite .update_plane() hook, as just passing the fb
> is enough.
>
> Signed-off-by: Ville Syrjälä
On Thu, Mar 19, 2015 at 05:57:12PM +0200, ville.syrj...@linux.intel.com wrote:
> @@ -1332,7 +1167,7 @@ int intel_sprite_set_colorkey(struct drm_device *dev,
> void *data,
> }
>
> intel_plane = to_intel_plane(plane);
> - ret = intel_plane->update_colorkey(plane, set);
> + inte
On 03/19/2015 04:04 PM, Ville Syrjälä wrote:
On Thu, Mar 19, 2015 at 03:33:11PM +0100, Daniel Vetter wrote:
On Wed, Mar 18, 2015 at 03:52:56PM +0100, Mario Kleiner wrote:
On 03/18/2015 10:30 AM, Chris Wilson wrote:
On Wed, Mar 18, 2015 at 11:53:16AM +0900, Michel Dänzer wrote:
drm_vblank_coun
On Thu, Mar 19, 2015 at 11:29:40AM +, Chris Wilson wrote:
> The existing ABI says that scanouts are pinned into the mappable region
> so that legacy clients (e.g. old Xorg or plymouthd) can write directly
> into the scanout through a GTT mapping. However if the surface does not
> fit into the m
On Thu, Mar 19, 2015 at 03:38:19PM +0200, David Weinehall wrote:
> On Thu, Mar 19, 2015 at 06:17:00PM +0530, Deepak S wrote:
> >
> >
> > On Thursday 19 March 2015 05:14 PM, David Weinehall wrote:
> > >On Thu, Mar 19, 2015 at 04:09:44PM +0530, deepa...@linux.intel.com wrote:
> > >>From: Deepak S
On 19/03/2015 15:16, Jani Nikula wrote:
On Thu, 19 Mar 2015, "Daniel, Thomas" wrote:
- if (&request->list == &ring->request_list)
+ /* It should always be possible to find a suitable request! */
+ if (&request->list == &ring->request_list) {
+ WARN_ON(true);
On Thu, Mar 19, 2015 at 11:29:40AM +, Chris Wilson wrote:
> The existing ABI says that scanouts are pinned into the mappable region
> so that legacy clients (e.g. old Xorg or plymouthd) can write directly
> into the scanout through a GTT mapping. However if the surface does not
> fit into the m
On Thu, Mar 19, 2015 at 01:10:13PM +, Chris Wilson wrote:
> On Thu, Mar 19, 2015 at 06:31:04PM +0530, Deepak S wrote:
> > should we skip put_fence in overlay_do_put_image ?
>
> Ah interesting point you raise there. That is buggy code fullstop.
> We should not be call put_fence if pin_to_displa
On Wed, Mar 18, 2015 at 03:01:22PM -0700, Matt Roper wrote:
> On Wed, Mar 18, 2015 at 04:15:07PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Otherwise we'll get a WARN from drm_wait_one_vblank() saying that
> > vblanks are not available (since they were already disabled in
> > crtc_
On Wed, Mar 18, 2015 at 04:57:53PM +, Nick Hoath wrote:
> Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset hardware
> workarounds require that GeneralStateOffset & InstructionBaseOffset
> are restricted to a 32 bit address space.
>
> This is a preparatory patch prior to supporting 64bi
On Thu, Mar 19, 2015 at 03:32:06PM +0200, Mika Kuoppala wrote:
> Michel Thierry writes:
>
> > Splitting this prep work should ease the code review and help identify
> > problems (and also shrink the Gen8 patch series, which is of more interest).
> >
> > 4 patches have already been sent as part of
On Mon, Mar 16, 2015 at 04:00:56PM +, Michel Thierry wrote:
> +static inline uint32_t i915_pte_count(uint64_t addr, size_t length,
> + uint32_t pde_shift)
> +{
> + const uint64_t mask = ~((1 << pde_shift) - 1);
> + uint64_t end;
> +
> + BUG_ON(len
On Mon, Mar 16, 2015 at 04:00:56PM +, Michel Thierry wrote:
> + BUG_ON(length == 0);
> + BUG_ON(offset_in_page(addr|length));
Broken record: I'm not a fan of BUG_ON at all, it's a massive pain if you
hit that in driver load in the initial modeset. Since these are just
consistency check
From: Ville Syrjälä
Store the colorkey in intel_plane and kill off all the RMW stuff
handling it.
This is just an intermediate step and eventually the colorkey needs to
be converted into some properties.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h| 7 +-
drivers/gp
From: Ville Syrjälä
Write the PLANE_SURF register instead of PLANE_CTL to arm the double
buffer regisrter update.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/
From: Ville Syrjälä
Replace the RMW access with explicit initialization of the entire plane
control register, as was done for primary planes in:
commit f45651bae2ee73ae551699d481f76aa6ad92138f
Author: Ville Syrjälä
Date: Fri Aug 8 21:51:10 2014 +0300
drm/i915: Eliminate rmw from .upda
From: Ville Syrjälä
intel_plane->obj is not used anymore so kill it. Also don't pass both
the fb and obj to the sprite .update_plane() hook, as just passing the fb
is enough.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 7 ---
drivers/gpu/drm/i915/intel_drv.h
On Thu, Mar 19, 2015 at 03:13:15PM +, Chris Wilson wrote:
> Pretty much an igt that compared the speed of just querying the hw
> counter vs querying with a regular vblank interrupt would be ideal for
> measuring the impact here.
ickle@crystalwell:/usr/src/intel-gpu-tools$ sudo ./tests/kms_vbla
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6000
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -1 272/272
On Wed, Mar 18, 2015 at 11:57:19PM +, Konduru, Chandra wrote:
>
>
> > -Original Message-
> > From: Conselvan De Oliveira, Ander
> > Sent: Friday, March 13, 2015 2:49 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Konduru, Chandra; Conselvan De Oliveira, Ander
> > Subject: [PATCH v
On Thu, Mar 12, 2015 at 11:11:17AM +, Chris Wilson wrote:
> This provides a nice boost to mesa in swap bound scenarios (as mesa
> throttles itself to the previous frame and given the scenario that will
> complete shortly). It will also provide a good boost to systems running
> with semaphores d
On Thu, Mar 19, 2015 at 09:52:08AM +0200, Ander Conselvan De Oliveira wrote:
> On Thu, 2015-03-19 at 00:38 +, Konduru, Chandra wrote:
> > Learning while reviewing connector/encoder side of handling.
> > But I think someone also should look at the encoder/connector side or
> > atomic handling.
On Thu, 19 Mar 2015, "Daniel, Thomas" wrote:
>> -if (&request->list == &ring->request_list)
>> +/* It should always be possible to find a suitable request! */
>> +if (&request->list == &ring->request_list) {
>> +WARN_ON(true);
>> return -ENOSPC;
>> +}
> Don
Hi,
On 03/19/2015 01:02 PM, Joonas Lahtinen wrote:
static inline
int i915_get_ggtt_vma_pages(struct i915_vma *vma)
Same rant about function signatures as on earlier patch, put all on the
same line like most of new the code has it.
Ok.
struct i915_ggtt_view {
enum i915_ggtt_v
On Thu, Mar 19, 2015 at 05:04:19PM +0200, Ville Syrjälä wrote:
> Is enabling the interrupts the expensive part, or is it the actual
> double timestamp read + scanout pos read? Or is it due to the several
> spinlocks we have in this code?
Chiefly it was the read during disable, then the spinlocked
On Thu, Mar 19, 2015 at 03:33:11PM +0100, Daniel Vetter wrote:
> On Wed, Mar 18, 2015 at 03:52:56PM +0100, Mario Kleiner wrote:
> > On 03/18/2015 10:30 AM, Chris Wilson wrote:
> > >On Wed, Mar 18, 2015 at 11:53:16AM +0900, Michel Dänzer wrote:
> > >>drm_vblank_count_and_time() doesn't return the co
1 - 100 of 224 matches
Mail list logo
