Add a function to lock memory into RAM and use it in the
gem_tiled_swapping test to reduce the amount of allocated memory
required to force swapping. This also reduces the amount of time
required for the test to complete, since the data set is smaller.
Signed-off-by: Thomas Wood
---
lib/igt_aux.
I was playing with clang and oh surprise! a warning trigerred by
-Wshift-overflow (gcc doesn't have this one):
WA_SET_BIT_MASKED(GEN7_GT_MODE,
GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4);
drivers/gpu/drm/i915/intel_ringbuffer.c:786:2: warning: signed shift result
We may be hidding bugs by doing that, so let remove it and have the
actual mask value shine through, for better or worse.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_r
While trying to unify the order of those arguments throughout the
driver, Daniel noticed what we were inverting them in this part of the
code.
Suggested-by: Daniel Vetter
Cc: Daniel Vetter
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 18 +-
1 file
On Mon, Dec 08, 2014 at 05:22:12PM +, Thomas Wood wrote:
> Add a function to lock memory into RAM and use it in the
> gem_tiled_swapping test to reduce the amount of allocated memory
> required to force swapping. This also reduces the amount of time
> required for the test to complete, since th
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of michael.h.ngu...@intel.com
> Sent: Friday, November 21, 2014 5:36 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Vetter, Daniel; Barnes, Jesse
> Subject: [Intel-gfx] [PATCH] drm/i915: Add
On Mon, Dec 08, 2014 at 05:58:45PM +, Bloomfield, Jon wrote:
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of michael.h.ngu...@intel.com
> > Sent: Friday, November 21, 2014 5:36 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc
Forcewake domain code uses unsigned int as a type for 'domains mask'.
Bring the hw accessors inline with this.
Suggested-by: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/intel_uncore.c | 8
2 files changed, 6 insertion
These two were using a fw dance logic where posting read was done
after both domain bit were set. When in other gens, the posting
read is done immediately after setting the forcewake bit for each
domain.
Now bring these in line with other gens.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i
From: Chris Wilson
With gen < 6 we don't need to take uncore lock as we
don't have anything to protect from concurrent access.
v2: rebase and account for gen9 changes
Signed-off-by: Chris Wilson (v1)
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_uncore.c | 158 +
We have multiple forcewake domains now on recent gens. Change the
function naming to reflect this.
v2: More verbose names (Chris)
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 8
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_dr
From: Chris Wilson
Calling intel_runtime_pm_put() is illegal from a soft-irq context, so
revert the crude hack
commit aa0b3b5bb8768c1a6a6788869d9c7015eae7e80c
Author: Paulo Zanoni
Date: Tue Apr 1 14:55:07 2014 -0300
drm/i915: don't schedule force_wake_timer at gen6_read
and apply the si
From: Chris Wilson
On user forcewake access, assert that runtime pm reference is held.
Fix and cleanup the callsites accordingly.
Signed-off-by: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +
drivers/gpu/drm/i915/intel_display.c | 19 +
driv
From: Chris Wilson
Introduce a structure to track the individual forcewake domains and use
that to eliminate duplicate logic.
v2: - Rebase on latest dinq (Mika)
- for_each_fw_domain macro (Mika)
- Handle reset atomically, keeping the timer running (Mika)
- for_each_fw_domain paramete
As we now have forcewake domains, take advantage of it
by putting the differences in gen fw handling in data rather
than in code.
In past we have opencoded this quite extensively as the fw handling
is in the fast path. There has also been a lot of cargo-culted
copy'n'pasting from older gens to new
On 12/08/2014 07:19 AM, Bloomfield, Jon wrote:
-Original Message-
From: Nguyen, Michael H
Sent: Wednesday, November 26, 2014 9:54 PM
To: intel-gfx@lists.freedesktop.org
Cc: Bloomfield, Jon; Volkin, Bradley D
Subject: [PATCH v5 1/7] drm/i915: Implement a framework for batch buffer
pools
On Mon, 08 Dec 2014, Imre Deak wrote:
> This will be needed by later patches, so factor it out.
>
> No functional change.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_drv.c | 15 ++-
> drivers/gpu/drm/i915/intel_drv.h | 8
> 2 files changed, 14 insertions
On Mon, 08 Dec 2014, Imre Deak wrote:
> After switching to using the component interface this API isn't needed
> any more.
\o/
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 56
> -
> include/drm/i915_powerwell.h| 37
On Mon, 08 Dec 2014, Imre Deak wrote:
> Register a component master to be used to interface with the
> snd_hda_intel driver. This is meant to replace the same interface that
> is currently based on module symbol lookup.
I think I'd add a whole new intel_component.c file for this.
>
> Signed-off-
On Mon, 2014-12-08 at 20:36 +0200, Jani Nikula wrote:
> On Mon, 08 Dec 2014, Imre Deak wrote:
> > This will be needed by later patches, so factor it out.
> >
> > No functional change.
> >
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 15 ++-
> > drivers/
On Mon, Dec 08, 2014 at 06:42:04PM +0200, Imre Deak wrote:
> The current hda/i915 interface to enable/disable power wells and query
> the CD clock rate is based on looking up the relevant i915 module
> symbols from the hda driver. By using the component framework we can get
> rid of some global sta
On Mon, 2014-12-08 at 20:44 +0200, Jani Nikula wrote:
> On Mon, 08 Dec 2014, Imre Deak wrote:
> > Register a component master to be used to interface with the
> > snd_hda_intel driver. This is meant to replace the same interface that
> > is currently based on module symbol lookup.
>
> I think I'd
On Mon, Dec 08, 2014 at 06:42:05PM +0200, Imre Deak wrote:
> This will be needed by later patches, so factor it out.
>
> No functional change.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_drv.c | 15 ++-
> drivers/gpu/drm/i915/intel_drv.h | 8
> 2 files
On Mon, Dec 08, 2014 at 06:42:05PM +0200, Imre Deak wrote:
> This will be needed by later patches, so factor it out.
The similiar function (for drm_device) is known as to_i915(), so just
call this dev_to_i915().
>
> No functional change.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i91
On Mon, 2014-12-08 at 20:40 +, Chris Wilson wrote:
> On Mon, Dec 08, 2014 at 06:42:05PM +0200, Imre Deak wrote:
> > This will be needed by later patches, so factor it out.
>
> The similiar function (for drm_device) is known as to_i915(), so just
> call this dev_to_i915().
> >
> > No functiona
No functional changes.
v2 (Paulo): Rebase.
v3: Accept Daniel's suggestions:
* remove unclear and duplicated explanation.
* remove marketing like doc and replace by a simple one.
* remove bdw_fbc_sw_flush documentation.
Signed-off-by: Rodrigo Vivi
Signed-off-by: Paulo Zanoni
---
Doc
On Mon, Dec 8, 2014 at 8:49 AM, Daniel Vetter wrote:
> On Mon, Dec 08, 2014 at 02:09:11PM -0200, Paulo Zanoni wrote:
>> From: Rodrigo Vivi
>>
>> No functional changes.
>>
>> v2 (Paulo): Rebase.
>>
>> Signed-off-by: Rodrigo Vivi
>> Signed-off-by: Paulo Zanoni
>
> Some suggestions to polish the d
When we unplug a dp mst branch we unreference the entire tree from
the root towards the leaves. Which is ok, since that's the way the
pointers and so also the refcounts go.
But when we drop the reference we must make sure that we remove the
branches/ports from the lists/pointers before dropping th
On Tue, Nov 25, 2014 at 5:04 AM, Daniel Vetter wrote:
> On Mon, Nov 24, 2014 at 08:29:40AM -0800, Rodrigo Vivi wrote:
>> From: Zhipeng Gong
>>
>> On Broadwell GT3 we have 2 Video Command Streamers (VCS), but userspace
>> has no control when using VCS1 or VCS2. This patch introduces a mechanism
>>
From: Brad Volkin
Move it to a separate function since the main do_execbuffer function
already has so much going on.
v2:
- Move pin/unpin calls inside i915_parse_cmds() (Chris W, v4 7/7
feedback)
Issue: VIZ-4719
Signed-off-by: Brad Volkin
Conflicts:
drivers/gpu/drm/i915/i915_gem_exe
From: Brad Volkin
This patch sets up all of the tracking and copying necessary to
use batch pools with the command parser and dispatches the copied
(shadow) batch to the hardware.
After this patch, the parser is in 'enabling' mode.
Note that performance takes a hit from the copy in some cases
a
From: Brad Volkin
Previously we couldn't trust the user-supplied batch length because
it came directly from userspace (i.e. untrusted code). It would have
affected what commands software parsed without regard to what hardware
would actually execute, leaving a potential hole.
With the parser now
From: Brad Volkin
By adding a new exec_entry flag, we cleanly mark the shadow objects
as purgeable after they are on the active list.
v2:
- Move 'shadow_batch_obj->madv = I915_MADV_WILLNEED' inside _get
fnc (danvet, from v4 6/7 feedback)
Issue: VIZ-4719
Signed-off-by: Brad Volkin
---
driver
From: Brad Volkin
This adds a small module for managing a pool of batch buffers.
The only current use case is for the command parser, as described
in the kerneldoc in the patch. The code is simple, but separating
it out makes it easier to change the underlying algorithms and to
extend to future u
From: "Michael H. Nguyen"
This is v6 in response to
http://lists.freedesktop.org/archives/intel-gfx/2014-November/056314.html
- Simplified pool_get() code
Use single cache list to manage pool
s/active_list/cache_list
Use single loop instead of an inner & outer
- Squashed debugfs pa
> Missed this version, see my reply to v1:
> http://mid.gmane.org/87k32iqppg@intel.com
>
> Also, what if you avoid sink dpms off with:
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 70bb8d0b9695..768b1bfaea78 100644
> --- a/drivers/gpu/drm/i915/intel_
On 26 November 2014 at 19:24, Jani Nikula wrote:
> On Wed, 26 Nov 2014, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> At least on two MST devices I've tested with, when
>> they are link training downstream, they are totally
>> unable to handle aux ch msgs, so they defer like nuts.
>> I tried 16,
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV 364/364
Here is some background of this KVMGT release:
- the major purpose is for early experiment of this technique in KVM, and
throw out issues about adding in-kernel device model (or mediated pass-through
framework) in KVM.
- KVMGT shares 90% code as XenGT, regarding to vGPU device model. The
only d
> From: Daniel Vetter
> Sent: Monday, December 08, 2014 6:21 PM
>
> On Mon, Dec 08, 2014 at 10:55:01AM +0100, Gerd Hoffmann wrote:
> > On Sa, 2014-12-06 at 12:17 +0800, Jike Song wrote:
> > > I don't know that is exactly needed, we also need to have Windows
> > > driver considered. However, I'm q
do you know how to make the intel-drm-nightly kernel mentioned in this
bugfix id like to use that until 3.19 lands
On Mon, Dec 8, 2014 at 2:26 AM, Chris Wilson wrote:
> On Fri, Dec 05, 2014 at 11:29:09PM -0600, Fennec Fox wrote:
>> well on my arch machine with an intel gma 4 graphics card using
by the way im using archlinux on x64
On Mon, Dec 8, 2014 at 9:52 PM, Fennec Fox wrote:
> do you know how to make the intel-drm-nightly kernel mentioned in this
> bugfix id like to use that until 3.19 lands
>
> On Mon, Dec 8, 2014 at 2:26 AM, Chris Wilson wrote:
>> On Fri, Dec 05, 2014 at 11:29
DSI Pll1 is used for enabling DSI on Port C.
v2: Addressed review comments of Jani
- Used & operator instead of == for intel_dsi->ports
Signed-off-by: Gaurav K Singh
---
drivers/gpu/drm/i915/intel_dsi_pll.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/
Due to hardware limitations on BYT, MIPI Port C DPI Enable bit
does not get set. To check whether DSI Port C was enabled in BIOS,
check the Pipe B enable bit for DSI Port C. In hardware, DSI Port C
is linked with Pipe B.
v2: Addressed review comments of Jani, Nikula
- Used platform checks for
From: Sonika Jindal
The pipe wm parameters is not correctly updated with sprite parameters
because it copies them for each plane from plane_list to the sprite
offset in pipe wm parameters. Since plane_list also contains primary and
cursor planes, we end up updating wrong params for sprites.
Sign
On 12/8/2014 5:03 PM, Jani Nikula wrote:
On Sun, 07 Dec 2014, Gaurav K Singh wrote:
DSI Pll1 is used for enabling DSI on Port C.
Signed-off-by: Gaurav K Singh
---
drivers/gpu/drm/i915/intel_dsi_pll.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu
101 - 149 of 149 matches
Mail list logo
