On Wed, Dec 02, 2015 at 04:56:29PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> For now, remove the spinlocks that protected the GuC's
> statistics block and work queue; they are only accessed
> by code that already holds the global struct_mutex, and
> so are redundant (until the big struc
On Thu, Nov 05, 2015 at 10:53:28AM -0800, Rodrigo Vivi wrote:
> Even with all sink crc re-works we still have platforms
> where after 6 vblanks it is unable to calculate the
> sink crc. But if we don't get the sink crc it isn't true
> that test failed, but that we have no ways to say test
> passed
On Tue, Dec 01, 2015 at 06:11:16PM +, Dave Gordon wrote:
> On 28/10/15 12:08, ankitprasad.r.sha...@intel.com wrote:
> >From: Ankitprasad Sharma
> >
> >A call to i915_gem_obj_ggtt_pin is being made after this, which again
> >calls the get_pages function. Hence removing the redundant call to
> >
> From: Tian, Kevin
> Sent: Friday, November 20, 2015 4:36 PM
>
> >
> > > > So, for non-opengl rendering qemu needs the guest framebuffer data so it
> > > > can feed it into the vnc server. The vfio framebuffer region is meant
> > > > to support this use case.
> > >
> > > what's the format requir
Because it opens an intel-specific drm fd. Fixes crashes when running
igt on no-intel.
Signed-off-by: Daniel Vetter
---
lib/igt_gt.c | 23 ++-
lib/igt_gt.h | 2 +-
tests/gem_evict_alignment.c | 26 +-
tests/gem_evict_e
This way we correctly auto-skip instead of falling over the
lack of i915 debugfs files first and fail the testcase due to
that.
Signed-off-by: Daniel Vetter
---
tests/drv_hangman.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/tests/drv_hangman.c b/tests/drv_hangman.c
Instead of failing. We might want to move this into i915 tests
eventually, but this is good for now.
Signed-off-by: Daniel Vetter
---
tests/drm_lib.sh | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/tests/drm_lib.sh b/tests/drm_lib.sh
index c50664c7730d..e7ec4a1cfcb5 10
I tested this with GuC submission enabled and it fixes the issue I found
during GPU reset.
Reviewed-by: Alex Dai
On 12/01/2015 06:48 AM, Nick Hoath wrote:
Use the first retired request on a new context to unpin
the old context. This ensures that the hw context remains
bound until it has been
From: Alex Dai
For now, remove the spinlocks that protected the GuC's
statistics block and work queue; they are only accessed
by code that already holds the global struct_mutex, and
so are redundant (until the big struct_mutex rewrite!).
The specific problem that the spinlocks caused was that
if
With a reliable frontbuffer tracking and all instability corner cases
solved let's re-enabled PSR by default on all supported platforms.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915
Although kms_frontbuffer_tracking already has psr-suspend testcase
this one here can complement it by testing different combination
and mainly covering 2 different cases individually:
1. wait-for-psr, suspend-resume tehn run 1 operation.
2. suspend-resume, wait-for-psr then run 1 operation.
v2:
Unfortunately Sink CRC is not 100% reliable for all platforms.
So we cannot block FBC tests nor skip them when we are getting
unreliable Sink CRC results, or not getting them at all.
Cc: Paulo Zanoni
Signed-off-by: Rodrigo Vivi
---
tests/kms_frontbuffer_tracking.c | 13 +
1 file cha
Although kms_frontbuffer_tracking already has psr-suspend testcase
this one here can complement it by testing different combination
and mainly covering 2 different cases individually:
1. wait-for-psr, suspend-resume tehn run 1 operation.
2. suspend-resume, wait-for-psr then run 1 operation.
v2:
With commit (drm/i915: Delay first PSR activation.) in kernel
PSR might take a bit longer to really activate after the modeset.
The first PSR activation after modeset is taking 5 times the panel
power cycle delay time, which is 600ms for our machines here.
So timeout here needs to be a minimum of 3
Even with all sink crc re-works we still have platforms
where after 6 vblanks it is unable to calculate the
sink crc. But if we don't get the sink crc it isn't true
that test failed, but that we have no ways to say test
passed or failed.
So let's print a message and move forward in case sink crc
c
commit 75b286e821 ("tests/kms_psr_sink_crc: test even
if PSR is disabled by default")' force PSR enabling without
respecting the no-psr (running-with-psr-disabled) option.
Signed-off-by: Rodrigo Vivi
---
tests/kms_psr_sink_crc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Beginning with gen7, newer devices repetitively redefine values
for the device info structure members. This patch simplifies the
structure definitions by grouping member value definitions into the
existing GEN7_FEATURES #define and into the new GEN7_LP_FEATURES
and HSW_FEATURES #defines.
Specific
These tests exercise the userptr ioctl to create shared buffers
between CPU and GPU. They contain error and normal usage scenarios.
They also contain a couple of stress tests which copy buffers between
CPU and GPU. These tests rely on the softpin patch in order to pin buffers
to a certain VA.
Cave
On 01/12/15 00:15, Dai, Yu wrote:
From: Alex Dai
When GuC Work Queue is full, driver will wait GuC for avaliable
space by delaying 1ms. The wait needs to be out of spinlockirq /
unlock. Otherwise, lockup happens because jiffies won't be updated
due to irq is disabled. The unnecessary locks has
On 02/12/15 14:58, Chris Wilson wrote:
On Wed, Dec 02, 2015 at 02:51:17PM +, Dave Gordon wrote:
Or, put the active ones on a linked list, or keep a bitmask of which
ones have been initialised inside the dev_priv structure, so you
don't have to even dereference the engine[] array to work out
On Wed, Dec 02, 2015 at 05:19:33PM +, Zanoni, Paulo R wrote:
> Em Qua, 2015-12-02 às 12:37 +, Chris Wilson escreveu:
> > My r-b still stand.
>
> What about patch 6? Any concerns or additional requests?
> drm/i915: alloc/free the FBC CFB during enable/disable
I thought I had spotted one
On Wed, 2015-12-02 at 11:42 +0200, Ville Syrjälä wrote:
> On Tue, Dec 01, 2015 at 07:44:00PM +, Vivi, Rodrigo wrote:
> > On Tue, 2015-12-01 at 20:56 +0200, Ville Syrjälä wrote:
> > > On Wed, Nov 18, 2015 at 11:19:06AM -0800, Rodrigo Vivi wrote:
> > > > According to VESA spec: "If a Source devic
Em Qua, 2015-12-02 às 12:37 +, Chris Wilson escreveu:
> On Wed, Dec 02, 2015 at 10:15:16AM -0200, Paulo Zanoni wrote:
> > Hi
> >
> > This series includes the implementation for the review feedback
> > given by Chris.
> > I also removed the patch that transformed our 50ms timeout into a
> > vbl
2015-12-01 11:08 GMT-02:00 :
> From: Ville Syrjälä
>
> Currently we disable some parts of FDI setup after a failed link
> training. But despite that we continue with the modeset as if everything
> is fine. This results in tons of noise from the state checker, and
> it means we're not following th
2015-12-01 11:08 GMT-02:00 :
> From: Ville Syrjälä
>
> Currently we leave the LPT-H VGA dotclock running after turning
> the pipe/fdi/port/etc. Propoerly disable the VGA dotclock as
s/Propoerly/Properly/
(DId you also notice that steps 13 and 18 are the same?)
Reviewed-by: Paulo Zanoni
> spe
2015-12-01 11:08 GMT-02:00 :
> From: Ville Syrjälä
>
> Extract the LPT-H VGA dotclock disable to a separate function in
> anticipation of further use.
>
> While at it move the sb_lock locking inwards when enabling the VGA
> dotclock, as it's only needed to protect the sideband accesses.
>
> Also
A new intel-gpu-tools quarterly release is available with the following changes:
- New test: kms_atomic tests atomic mode setting (Daniel Stone)
- New test: core_prop_blob tests blob properties (Daniel Stone)
- New test: gem_request_retire targets request retirement code paths
(Tvrtko Ursulin)
On Fri, 27 Nov 2015, Imre Deak wrote:
> This is a backport of a fix for an HDMI detection problem, which was
> introduced in v4.4-rc1, see the last patch for details. The fix for it
> with its dependencies is in drm-intel-next-queued only, the patches here
> are rebased versions of those on top of
On Wed, Dec 02, 2015 at 02:51:17PM +, Dave Gordon wrote:
> Or, put the active ones on a linked list, or keep a bitmask of which
> ones have been initialised inside the dev_priv structure, so you
> don't have to even dereference the engine[] array to work out
> whether a particular engine is ini
On 02/12/15 13:46, Chris Wilson wrote:
On Wed, Dec 02, 2015 at 01:29:21PM +, Dave Gordon wrote:
On 25/11/15 09:23, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 11:47:26PM +, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 10:26:01PM +, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 07:36
2015-12-01 11:08 GMT-02:00 :
> From: Ville Syrjälä
>
> Bspec modeset sequence tells us to disable the PCH transcoder and
> FDI after the CRT port on LPT-H, so let's do that.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 11 +--
> 1 file changed, 5 inser
2015-12-01 11:08 GMT-02:00 :
> From: Ville Syrjälä
>
> Bspec says we should round to closest when computong the LPT-H VGA
s/computong/computing/
Reviewed-by: Paulo Zanoni
> dotclock, so let's do that.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 1
On Wed, Dec 02, 2015 at 01:29:21PM +, Dave Gordon wrote:
> On 25/11/15 09:23, Daniel Vetter wrote:
> >On Tue, Nov 24, 2015 at 11:47:26PM +, Chris Wilson wrote:
> >>On Tue, Nov 24, 2015 at 10:26:01PM +, Chris Wilson wrote:
> >>>On Tue, Nov 24, 2015 at 07:36:25PM +0200, Jani Nikula wrote:
Hi,
On 06/10/15 14:57, Daniel, Thomas wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Chris Wilson
Sent: Tuesday, October 6, 2015 11:53 AM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH 2/3] drm/i915: Allow the use
2015-12-01 11:08 GMT-02:00 :
> From: Ville Syrjälä
>
> When we want to use SPLL for FDI we want SSC, which means we have to
> disable clock bending for the PCH SSC reference (bend and spread are
> mtutually exclusive). So let's turn off bending when we want spread.
> In case the BIOS enabled cloc
On 25/11/15 09:23, Daniel Vetter wrote:
On Tue, Nov 24, 2015 at 11:47:26PM +, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 10:26:01PM +, Chris Wilson wrote:
On Tue, Nov 24, 2015 at 07:36:25PM +0200, Jani Nikula wrote:
/* Iterate over initialised rings */
#define for_each_ring(ring__
On Tue, Oct 27, 2015 at 05:21:37PM +0530, akash goel wrote:
> On Tue, Oct 6, 2015 at 4:23 PM, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 19dd6b05ee1d..c35c9dc526e7 100644
> > --- a/drivers/gpu/drm/i915
On Wed, 02 Dec 2015, Vandana Kannan wrote:
> Making changes in intel_crtc_mode_get() to get correct values for crtc clock,
> vdisplay, hdisplay, vtotal.
> 1. intel_crtc_mode_get() gets clock using i9xx_crtc_clock_get() which wil not
> work for hsw, skl, bxt.
> 2. For BXT DSI, hdisplay, vdisplay, v
The big motivation behind this patch is that the current power-of-two
granularity from igt_fb is way too big. There was more than one
occasion where I had to work around this problem on
kms_frontbuffer_tracking, and during my last workaround I was
requested to just make igt_fb use more minimal buff
We want to make sure that both tiled and untiled buffers have the same
size for the same width/height/format. This will allow better control
over the failure paths exercised by our tests: when we try to flip
from tiled to untiled, we'll be sure that we won't execute the error
path that checks for b
On Wed, Dec 02, 2015 at 10:15:16AM -0200, Paulo Zanoni wrote:
> Hi
>
> This series includes the implementation for the review feedback given by
> Chris.
> I also removed the patch that transformed our 50ms timeout into a vblank-based
> timeout due to performance concerns. The only patch that stil
On Tue, 01 Dec 2015, Wayne Boyer wrote:
> Beginning with gen7, newer devices repetitively redefine values
> for the device info structure members. This patch simplifies the
> structure definitions by grouping member value definitions into the
> existing GEN7_FEATURES #define and into the new GEN7
On Wed, 02 Dec 2015, Ville Syrjälä wrote:
> On Tue, Dec 01, 2015 at 05:11:40PM -0800, Wayne Boyer wrote:
>> The cherryview device shares many characteristics with the valleyview
>> device. When support was added to the driver for cherryview, the
>> corresponding device info structure included .is
Directly call intel_fbc_calculate_cfb_size() in the only place that
actually needs it, and use the proper check before removing the stolen
node. IMHO, this change makes our code easier to understand.
v2: Use drm_mm_node_allocated() (Chris).
Reviewed-by: Chris Wilson
Signed-off-by: Paulo Zanoni
This moves the pre-gen4 check from update() to enable(). The HAS_DDI
in the original code is not needed since only gen 2/3 have the plane
swapping code.
v2: Rebase.
v3: Extract fbc_on_plane_a_only() (Chris).
Reviewed-by: Chris Wilson
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_f
When running Cinnamon I see way too many pairs of these messages: many
per second. Get rid of them as they're just telling us FBC is working
as expected. We already have the messages for enable/disable, so we
don't really need messages for activation/deactivation.
v2: Rebase after changing the pat
There's no need to stop and restart FBC, which is quite expensive as
we have to revalidate the CRTC state. After flushing a drawing
operation we know the CRTC state hasn't changed, so a nuke
(recompress) should be fine.
v2: Make it simpler (Chris).
v3: Rewrite the patch again due to patch order ch
This was already on my TODO list, and was requested both by Chris and
Ville, for different reasons. The advantages are avoiding a frequent
malloc/free pair, and the locality of having the work structure
embedded in dev_priv. The maximum used memory is also smaller since
previously we could have mul
There's no need to reevaluate the status of every single crtc when a
single crtc changes its state.
With this, we're cutting the case where due to a change in pipe B,
intel_fbc_update() is called, then intel_fbc_find_crtc() concludes FBC
should be enabled on pipe A, then it completely rechecks the
This thing where we need to get the crtc either from the work
structure or the fbc structure itself is confusing and unnecessary.
Set fbc.crtc right when scheduling the enable work so we can always
use it.
The problem is not what gets passed and how to retrieve it. The
problem is that when we're i
The long term goal is to have enable/disable as the higher level
functions and activate/deactivate as the lower level functions, just
like we do for PSR and for the CRTC. This way, we'll run enable and
disable once per modeset, while update, activate and deactivate will
be run many times. With this
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame a
The goal is to call FBC enable/disable only once per modeset, while
activate/deactivate/update will be called multiple times.
The enable() function will be responsible for deciding if a CRTC will
have FBC on it and then it will "lock" FBC on this CRTC: it won't be
possible to change FBC's CRTC unt
Hi
This series includes the implementation for the review feedback given by Chris.
I also removed the patch that transformed our 50ms timeout into a vblank-based
timeout due to performance concerns. The only patch that still needs review is
patch 6.
Thanks,
Paulo
Paulo Zanoni (11):
drm/i915: f
In function find_compression_threshold() we try to over-allocate CFB
space in order to reduce reallocations and fragmentation, and we're
not considering that at the CFB size check. Consider it.
There is also a longer-term plan to kill
dev_priv->fbc.uncompressed_size, but this will come later.
v2:
On Tue, 01 Dec 2015, Daniel Vetter wrote:
> On Tue, Dec 01, 2015 at 01:12:43PM +0200, Jani Nikula wrote:
>> On Tue, 01 Dec 2015, Daniel Vetter wrote:
>> > Somehow the kernel's mode list changed with our EDID.
>>
>> I do not undestand what you're trying to say here.
>
> The EDID we injected staye
On Wed, Dec 02, 2015 at 11:28:52AM +, Tvrtko Ursulin wrote:
> This will return ENOSPC to userspace when they have passed in an
> address outside the (PP)GTT range which is misleading.
Reviewing the wrong patch.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
On Tue, 01 Dec 2015, Ville Syrjälä wrote:
> On Tue, Dec 01, 2015 at 05:38:30PM +0200, Jani Nikula wrote:
>> On Tue, 01 Dec 2015, Ville Syrjälä wrote:
>> > On Tue, Dec 01, 2015 at 04:29:26PM +0200, Jani Nikula wrote:
>> >> Choose between i2c bit banging and gmbus in a new higher level function,
>>
On 16/10/15 11:59, Thomas Daniel wrote:
From: Chris Wilson
Userspace can pass in an offset that it presumes the object is located
at. The kernel will then do its utmost to fit the object into that
location. The assumption is that userspace is handling its own object
locations (for example alon
Signed-off-by: Thomas Wood
---
tests/core_setmaster_vs_auth.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/core_setmaster_vs_auth.c b/tests/core_setmaster_vs_auth.c
index 44ec752..97add9c 100644
--- a/tests/core_setmaster_vs_auth.c
+++ b/tests/core_setmaster_vs_auth.c
@@ -45,6 +45
This test has no subtests, so should use igt_simple_main.
Signed-off-by: Thomas Wood
---
tests/core_setmaster_vs_auth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/core_setmaster_vs_auth.c b/tests/core_setmaster_vs_auth.c
index efb27b1..44ec752 100644
--- a/tests/co
Hi,
On 02/12/15 10:24, Tvrtko Ursulin wrote:
On 01/12/15 11:20, Vinay Belgaumkar wrote:
These tests exercise the userptr ioctl to create shared buffers
between CPU and GPU. They contain error and normal usage scenarios.
They also contain a couple of stress tests which copy buffers between
CPU
On 01/12/15 11:20, Vinay Belgaumkar wrote:
These tests exercise the userptr ioctl to create shared buffers
between CPU and GPU. They contain error and normal usage scenarios.
They also contain a couple of stress tests which copy buffers between
CPU and GPU. These tests rely on the softpin patch i
On Wed, Nov 11, 2015 at 04:06:13PM +0530, ankitprasad.r.sha...@intel.com wrote:
> From: Chris Wilson
>
> Ville reminded us that stolen memory is not preserved across
> hibernation, and a result of this was that context objects now being
> allocated from stolen were being corrupted on S4 and promp
From: Ankitprasad Sharma
This patch verifies if the contents of the stolen backed object were
preserved across hibernation. This is to validate kernel changes related
to moving stolen-backed objects to shmem on hibernation.
Signed-off-by: Ankitprasad Sharma
---
tests/gem_stolen.c | 86
From: Ankitprasad Sharma
This test validates the two parameters (size and flags) GEM_CREATE ioctl.
v2: Added IGT_TEST_DESCRIPTION (Thomas Wood)
v3: Removed use of hard coded values, updated comments (Tvrtko)
v4: Removed over-use of macros, updated with multiples of PAGE_SIZE (Tvrtko)
Signed-o
From: Ankitprasad Sharma
This patch adds support to verify pread/pwrite for non-shmem backed
objects. It also shows the pread/pwrite speed.
It also tests speeds for pread with and without user side page faults
v2: Fixed Rebase conflicts (Ankit)
v3: Precalculating values to avoid redundant funct
From: Ankitprasad Sharma
This patch adds the testcases for verifying the new extended
gem_create ioctl. By means of this extended ioctl, memory
placement of the GEM object can be specified, i.e. either
shmem or stolen memory.
These testcases include functional tests and interface tests for
testin
From: Ankitprasad Sharma
This new set of tests verifies the old and the new extended GEM_CREATE ioctl
gem_stolen tries to verify the new extended GEM_CREATE ioctl, which tries to
create an object backed by stolen memory and performs basic operations on it.
It verifies the creation as well as the
On Tue, Dec 01, 2015 at 07:44:00PM +, Vivi, Rodrigo wrote:
> On Tue, 2015-12-01 at 20:56 +0200, Ville Syrjälä wrote:
> > On Wed, Nov 18, 2015 at 11:19:06AM -0800, Rodrigo Vivi wrote:
> > > According to VESA spec: "If a Source device receives and IRQ_HPD
> > > while in a PSR active state, and ca
On Tue, Dec 01, 2015 at 02:37:04PM +0200, Jani Nikula wrote:
> On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > No need to read out cdclk from the hardware, we have it already
> > cached in dev_priv.
> >
> > Signed-off-by: Ville Syrjälä
>
> Reviewed-by: J
On Tue, Dec 01, 2015 at 11:32:07PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> While not technically needed on the last case in the switch statement,
> the 'break' makes it look better IMO.
>
> v2: Fixed a typo in the commit message (Paulo)
>
> Signed-off-by: Ville Syr
In commit 2e1b873072dfe3bbcc158a9c21acde1ab0d36c55 [v4.2]
Author: Chris Wilson
Date: Mon Apr 27 13:41:22 2015 +0100
drm/i915: Convert RPS tracking to a intel_rps_client struct
we converted the __i915_wait_request() to take a new intel_rps_client
struct (rather than having to pass fake drm_
On Wed, Dec 02, 2015 at 12:13:27PM +0530, Vandana Kannan wrote:
> Making changes in intel_crtc_mode_get() to get correct values for crtc clock,
> vdisplay, hdisplay, vtotal.
Why? It's not used except potentially during for DVO/LVDS init on
old platforms.
> 1. intel_crtc_mode_get() gets clock usin
On Tue, Dec 01, 2015 at 05:11:40PM -0800, Wayne Boyer wrote:
> The cherryview device shares many characteristics with the valleyview
> device. When support was added to the driver for cherryview, the
> corresponding device info structure included .is_valleyview = 1.
> This is not correct and leads
On Tue, 01 Dec 2015, Marc MERLIN wrote:
> On Sat, Nov 28, 2015 at 09:54:50AM -0800, Marc MERLIN wrote:
>> On Tue, Nov 17, 2015 at 05:11:05PM +0200, Jani Nikula wrote:
>> > On Tue, 17 Nov 2015, Marc MERLIN wrote:
>> > > So, this is probably the 3rd time I send such a report with different
>> > > k
On Tue, 01 Dec 2015, Imre Deak wrote:
> On ti, 2015-12-01 at 10:23 +0200, Jani Nikula wrote:
>> The only missing piece is the function to convert frequency to PWM
>> register value. The PWM is based on 19.2 MHz clock, except for BXT A
>> step, which is based on CDCLK, and which we ignore.
>>
>> S
77 matches
Mail list logo
