On ti, 2015-03-17 at 15:45 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Need to do this in order to support 90/270 rotated display.
>
> v2: Pass in drm_plane instead of plane index to intel_obj_display_address.
>
> v3:
> * Renamed intel_obj_display_address to intel_plane_obj_offs
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_display_plane pins the fence.
Techinically the overlay could use a fence, the
On Thursday 19 March 2015 06:40 PM, 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_display_plane pins
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 5997
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV -2 272/272
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 the main patchset, only "page
> table generalizations" is brand new (sugge
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
> >>
> >>Unfortunately WaGsvRC0ResidencyMethod causing system freeze on some
On 03/19/2015 12:04 PM, Chris Wilson wrote:
On Thu, Mar 19, 2015 at 11:58:17AM +, Tvrtko Ursulin wrote:
How about retire all rings and then the inactive batch search with a
global pool becomes only O(num_rings) at worst? Might be worth
saving memory resource (multiple pools) vs. trivial tra
On ti, 2015-03-17 at 15:45 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> v2: Pass in rotation info to sprite plane updates as well.
>
> v3: Use helper to determine 90/270 rotation. (Michel Thierry)
>
> v4: Rebased for fb modifiers and atomic changes.
>
> For: VIZ-4546
> Signed-off-by
From: Deepak S
After feedback from the hardware team, now we set the GPU min/idel freq to RPe.
Punit is expecting us to operate GPU between Rpe & Rp0. If we drop the
frequency to RPn, punit is failing to change the input voltage to
minimum :(
v2: Change commit message
Signed-off-by: Deepak S
-
From: Deepak S
After feedback from the hardware team we are changing the RC6
promotional timer to increase the power saving without
changing performance.
Signed-off-by: Deepak S
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/
From: Deepak S
Adding few of PM fixes and Improvements for CHV/VLV.
Addressed few comments.
Deepak S (4):
drm/i915/chv: Remove Wait for a previous gfx force-off
drm/i915: Re-adjusting rc6 promotional timer for chv
drm/i915/chv: Set min freq to efficient frequency on chv
drm/i915: Setup s
From: Deepak S
Based on the spec, Setting up static BIAS for GPU to improve the
rps performace.
Signed-off-by: Deepak S
---
drivers/gpu/drm/i915/i915_reg.h | 5 +
drivers/gpu/drm/i915/intel_pm.c | 12
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_r
From: Deepak S
On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a
sticky bit and it will always be set. So ignore Check for previous
Gfx force off during suspend and allow the force clk as part S0ix
Sequence
Signed-off-by: Deepak S
---
drivers/gpu/drm/i915/i915_drv.c | 6 -
From: Ville Syrjälä
In preparation to movable/resizeable primary planes pass the clipped
plane size to .update_primary_plane().
v2: Pass src size too and use it appropriately (Sonika)
Cc: Sonika Jindal
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu
From: Ville Syrjälä
In preparation for changing the primary plane position pass the clipped
position to .update_primary_plane().
v2: Rebased
Cc: Sonika Jindal
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 20 +
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 correct sequence number
> >>while the vblank interrupt is disabled, does
From: Ville Syrjälä
v2: Rebase and update the vlv/chv code as well
Cc: Matt Roper
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 42 ++---
1 file changed, 18 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/
On Thu, Mar 19, 2015 at 02:01:37PM +, Tvrtko Ursulin wrote:
>
> On 03/19/2015 12:04 PM, Chris Wilson wrote:
> >On Thu, Mar 19, 2015 at 11:58:17AM +, Tvrtko Ursulin wrote:
> >>How about retire all rings and then the inactive batch search with a
> >>global pool becomes only O(num_rings) at w
On Thu, Mar 19, 2015 at 12:20:57PM +0200, Jani Nikula wrote:
> On Thu, 19 Mar 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > AUX addresses are 20 bits long. Send out the entire address instead of
> > just the low 16 bits.
> >
> > Signed-off-by: Ville Syrjälä
>
> Revie
On Thu, Mar 19, 2015 at 01:48:00PM +0200, Jani Nikula wrote:
> On Thu, 19 Mar 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > When doing a native or i2c aux write the sink will indicate the number
> > of bytes written even if it the nacks the transfer. When we receive a
On Thu, Mar 19, 2015 at 12:09:53PM +0200, David Weinehall wrote:
> On Thu, Mar 19, 2015 at 03:22:42AM +, Song, Ruiling wrote:
> >
> > > Yeah, MAP_FIXED sounds a bit more ambitious and though I think it would
> > > work for OCL 2.0 pointer sharing, it's a little different than we were
> > > pl
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> john.c.harri...@intel.com
> Sent: Thursday, March 19, 2015 12:30 PM
> To: Intel-GFX@Lists.FreeDesktop.Org
> Subject: [Intel-gfx] [PATCH 04/59] drm/i915: Fix for ringbuf space wait in LRC
>
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> john.c.harri...@intel.com
> Sent: Thursday, March 19, 2015 12:31 PM
> To: Intel-GFX@Lists.FreeDesktop.Org
> Subject: [Intel-gfx] [PATCH 55/59] drm/i915: Remove fallback poll for ring
> bu
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> john.c.harri...@intel.com
> Sent: Thursday, March 19, 2015 12:31 PM
> To: Intel-GFX@Lists.FreeDesktop.Org
> Subject: [Intel-gfx] [PATCH 56/59] drm/i915: Remove 'faked' request from LRC
> s
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
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
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, 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
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, 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 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
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 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
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
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ä
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ä
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
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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 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 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 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 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 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 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 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:
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 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
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
> -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
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
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 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 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 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 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 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
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
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
> -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
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
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
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 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 @
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 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:
> 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 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:
> 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/
> -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:
> 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_
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:
> 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
>
> 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
>
> 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:
> 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 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
101 - 200 of 224 matches
Mail list logo
