In some cases, the only connected connector might not occupy the
first slot and hence output[0] might be empty. Therefore, use
the get_first_connected_output macro to find the output object
associated with the connected connector.
Signed-off-by: Vivek Kasireddy
---
tests/kms_rotation_crc.c | 10
In some cases, we just need one valid (connected) output to perform
a test. This macro can help in these situations by not having to
put the test code inside a for loop that iterates over all the outputs.
v2: Added a brief documentation for this macro.
Suggested-by: Matt Roper
Cc: Thomas Wood
S
This read wake with retries were initially added by 2 commits:
commit 61da5fab ("drm/i915/dp: retry link status read 3 times on failure")
commit 899526d9 ("drm/i915/dp: try to read receiver capabilities 3 times when
detecting")
Both mentioning section 9.1 of the 1.1a DisplayPort spec, that actua
Mainly aux communications on sink_crc
were failing a lot randomly on recent platforms.
The first solution was to try to use intel_dp_dpcd_read_wake, but then
it was suggested to move retries to drm level.
Since drm level was already taking care of retries and didn't want
to through random retries
Current EBUSY meaning is immediately retry, but this is
about to change. DRM aux transfer is about to change and
make EAGAIN the immediately retry and use EBUSY to wait
a bit for aux channels to recover for any error or wake up.
This has no functional change if the EAGAIN support is in
place alrea
DP Specs isn't really clear about the amount of retries,
but for cases it mentions retries it also mention times that
vary from 300us to 1ms.
For many cases hardware can handled the timeouts before retry
is possible and allowed, but for many other cases it is better
to wait and give time so the au
The goal here is to offload aux retries handling from the
drivers to drm.
However there are 2 differents cases for retry:
1. Immediately retry - Hardware already took care of needed timeouts
before answering that a retry is possible.
2. Busy - Wait some time and retry.
This
drm level already takes care of the needed retries so instead of
duplicate the effort here.
If the retry is possible immediately we return EAGAIN. Otherwise,
if we have no idea what caused the error let's assume something
was busy and let drm level handle the wait and retries.
Signed-off-by: Rodr
EBUSY retries are already in place at drm level.
We don't need to replicate the job here.
v2: rebase on top of EAGAIN x EBUSY retries change at drm.
EBUSY retry at DRM is now handling the msleep(1).
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_dp.c | 22 +++---
Current EBUSY meaning is immediately retry, but this is
about to change. DRM aux transfer is about to change and
make EAGAIN the immediately retry and use EBUSY to wait
a bit for aux channels to recover for any error or wake up.
This has no functional change if the EAGAIN support is in
place alrea
The goal of this series is to remove many different retries we have
for aux communication and offload them to drm.
However on first attempt I was only returning EBUSY to use drm retries
but there was no waiting there. So this series also introduce a new
approach on drm level to retry on aux commun
From: Ville Syrjälä
On some machines the CRT connector may be fused off. The weird thing
about this setup is that the ADPA register works otherwise normally,
except the enable bit is hardwired to 0. No one knows of any fuse
register that would tell us if this is the case, so the only thing we
can
From: Ville Syrjälä
To get a better idea if underruns occurred during crtc disabling,
let's check for them explicitly. This helps in cases where the
error interrupt isn't active, or there is no underrun interrupt
support at all.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_displ
From: Ville Syrjälä
We still get spurious pipe underruns on ILK/SNB/IVB under two
circumstances when dealing with PCH ports:
* When the pipe has been disabled, but FDI RX/TX is still enabled
* During FDI link training
Both cases seem to happen at least when we do VGA+HDMI cloning
from the same p
From: Ville Syrjälä
We sometimes get a spurious CPU pipe underrun somewhere between
enabling port A and enabling vdd for the panel. Observed on both
ILK and IVB with port A eDP. Suppress FIFO underrun reporting
around the port and vdd enable to avoid the dmesg errors.
Not sure if port D eDP woul
On Fri, 2015-11-20 at 06:01 +, Jindal, Sonika wrote:
> Hmm, please help me understand more about it.
Well, PSR is working because we are seeing PC10 with screen on. But the
registers are zeroed. Regarding it is restored properly or not.
I can send a v2 with a much better commit message and ex
On Fri, Nov 20, 2015 at 07:03:28PM +, Daniel Stone wrote:
> On 20 November 2015 at 13:55, Ville Syrjälä
> wrote:
> > On Thu, Nov 19, 2015 at 09:20:16AM -0800, clinton.a.tay...@intel.com wrote:
> >> +static int skl_modeset_calc_cdclk(struct drm_atomic_state *state)
> >> +{
> >> + struct drm
On 20 November 2015 at 13:55, Ville Syrjälä
wrote:
> On Thu, Nov 19, 2015 at 09:20:16AM -0800, clinton.a.tay...@intel.com wrote:
>> +static int skl_modeset_calc_cdclk(struct drm_atomic_state *state)
>> +{
>> + struct drm_i915_private *dev_priv = to_i915(state->dev);
>> + int max_pixclk = i
On Fri, Nov 20, 2015 at 10:10:43AM -0800, Clint Taylor wrote:
> On 11/20/2015 05:55 AM, Ville Syrjälä wrote:
> > On Thu, Nov 19, 2015 at 09:20:16AM -0800, clinton.a.tay...@intel.com wrote:
> >> From: Clint Taylor
> >>
> >> Add SKL and KBL cdclk changes during modeset. Taking into account new
> >>
On 11/20/2015 12:31 AM, Daniel Vetter wrote:
On Thu, Nov 19, 2015 at 04:10:26PM -0800, yu@intel.com wrote:
> From: Alex Dai
>
> There is a memory leak warning message from i915_gem_context_clean
> when GuC submission is enabled. The reason is that when LRC is
> released, its ppgtt could be
On 11/20/2015 05:55 AM, Ville Syrjälä wrote:
On Thu, Nov 19, 2015 at 09:20:16AM -0800, clinton.a.tay...@intel.com wrote:
From: Clint Taylor
Add SKL and KBL cdclk changes during modeset. Taking into account new
linkrates available using 8640 VCO.
Signed-off-by: Clint Taylor
---
drivers/gpu/
Hi Chris,
[auto build test WARNING on drm-intel/for-linux-next]
[cannot apply to v4.4-rc1 next-20151120]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Pin-the-ifbdev-for-the-info-system_base-GGTT-mmapping/20151121-003300
base: git://anongit.freedesktop.org/drm-intel
Hi,
On 13 November 2015 at 21:13, Paulo Zanoni wrote:
> 2015-11-13 18:56 GMT-02:00 Chris Wilson :
>> This is confusing me. I think of FBC in terms of the CRTC/pipe, and the
>> fb just describes the plane currently bound to the primary. You've
>> pushed everywhere else to also work on the CRTC, I
On Fri, 2015-11-20 at 08:10 +, Tian, Kevin wrote:
> > From: Tian, Kevin
> > Sent: Friday, November 20, 2015 3:10 PM
>
> > > > >
> > > > > The proposal is therefore that GPU vendors can expose vGPUs to
> > > > > userspace, and thus to QEMU, using the VFIO API. For instance, vfio
> > > > > supp
On Fri, 2015-11-20 at 07:09 +, Tian, Kevin wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Friday, November 20, 2015 4:03 AM
> >
> > > >
> > > > The proposal is therefore that GPU vendors can expose vGPUs to
> > > > userspace, and thus to QEMU, using the VFIO API
Hi Chris,
[auto build test ERROR on drm-intel/for-linux-next]
[cannot apply to v4.4-rc1 next-20151120]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Pin-the-ifbdev-for-the-info-system_base-GGTT-mmapping/20151121-003300
base: git://anongit.freedesktop.org/drm-intel for
On Fri, 2015-11-20 at 13:51 +0800, Jike Song wrote:
> On 11/20/2015 12:22 PM, Alex Williamson wrote:
> > On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
> >> On 11/19/2015 11:52 PM, Alex Williamson wrote:
> >>> On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> On Thu, 19 Nov 2
On 11/20/2015 08:29 AM, Chris Wilson wrote:
> A long time ago (before 3.14) we relied on a permanent pinning of the
> ifbdev to lock the fb in place inside the GGTT. However, the
> introduction of stealing the BIOS framebuffer and reusing its address in
> the GGTT for the fbdev has muddied waters a
A long time ago (before 3.14) we relied on a permanent pinning of the
ifbdev to lock the fb in place inside the GGTT. However, the
introduction of stealing the BIOS framebuffer and reusing its address in
the GGTT for the fbdev has muddied waters and we use an inherited fb.
However, the inherited fb
Hi,
On 19/11/15 22:29, 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 p
On 11/20/2015 06:34 AM, Chris Wilson wrote:
> A long time ago (before 3.14) we relied on a permanent pinning of the
> ifbdev to lock the fb in place inside the GGTT. However, the
> introduction of stealing the BIOS framebuffer and reusing its address in
> the GGTT for the fbdev has muddied waters a
Hi all,
New -testing cycle with cool stuff:
4 weeks because of my vacation, so a bit more:
- final bits of the typesafe register mmio functions (Ville)
- power domain fix for hdmi detection (Imre)
- tons of fixes and improvements to the psr code (Rodrigo)
- refactoring of the dp detection code (An
On 11/20/2015 06:16 AM, Chris Wilson wrote:
> As we mark the preallocated objects as bound, we should also flag them
> correctly as being map-and-fenceable (if appropriate!) so that later
> users do not get confused and try and rebind the pinned vma in order to
> get a map-and-fenceable binding.
>
On Fri, Nov 20, 2015 at 03:55:34PM +, Daniel Stone wrote:
> If we experience a refcounting failure in a power domain/well (unref'ing at
> least one too many times), log the name of the offending domain or well.
>
> Signed-off-by: Daniel Stone
Both patches look OK to me
Reviewed-by: Ville Syr
On 20 November 2015 at 08:21, Jani Nikula wrote:
> On Thu, 19 Nov 2015, Ville Syrjälä wrote:
>> On Thu, Nov 19, 2015 at 06:26:23PM +, Daniel Stone wrote:
>>> Surely gcc's DCE pass will trivially eliminate this?
>>
>> Dunno. But I rather dislike having code in headers anyway.
>
> Agreed, parti
If we experience a refcounting failure in a power domain/well (unref'ing at
least one too many times), log the name of the offending domain or well.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a
Let us print human-parseable values from the power domain code; upcoming
display code also wants to use it.
This requires moving it out of i915_debugfs.c, as that is only conditionally
compiled.
v2: Move it out of the header.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/i915/i915_debugfs.c
On Fri, Nov 20, 2015 at 05:08:06PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 20, 2015 at 10:55:57AM +, Chris Wilson wrote:
> > + desc = find_cmd_in_table(ring, *cmd);
> > + if (desc) {
> > + if (unlikely(desc-
On Fri, Nov 20, 2015 at 03:34:22PM +, Chris Wilson wrote:
> On Fri, Nov 20, 2015 at 05:27:43PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 20, 2015 at 10:56:00AM +, Chris Wilson wrote:
> > > Signed-off-by: Chris Wilson
> > > ---
> > > drivers/gpu/drm/i915/i915_cmd_parser.c | 51
> > > +++
On Fri, Nov 20, 2015 at 03:11:04PM +, Chris Wilson wrote:
> The offset within and the length of the command sequence to execute are
> supplied by the user with respect to the batch buffer. We should be
> validating that region is wholly contained within the batch buffer;
> make it so.
>
> Repo
On Fri, Nov 20, 2015 at 05:27:43PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 20, 2015 at 10:56:00AM +, Chris Wilson wrote:
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_cmd_parser.c | 51
> > --
> > drivers/gpu/drm/i915/i915_drv.h
On Fri, Nov 20, 2015 at 10:56:00AM +, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_cmd_parser.c | 51
> --
> drivers/gpu/drm/i915/i915_drv.h| 4 ++-
> 2 files changed, 14 insertions(+), 41 deletions(-)
>
> diff
With a little complexity to handle cmds straddling page boundaries, we
can completely avoiding having to vmap the batch and the shadow batch
objects whilst running the command parser.
On ivb i7-3720MQ:
x11perf -dot before 54.3M, after 53.2M (max 203M)
glxgears before 7110 fps, after 7300 fps (max
On Fri, Nov 20, 2015 at 05:05:05PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 20, 2015 at 10:55:58AM +, Chris Wilson wrote:
> > Since we blow the TLB caches by using kmap/kunmap, we may as well go the
> > whole hog and see if declaring our destination page as WC is faster than
> > keeping it as
On Fri, Nov 20, 2015 at 10:56:01AM +, Chris Wilson wrote:
> The existing code's hashfunction is very suboptimal (most 3D commands
> use the same bucket degrading the hash to a long list). The code even
> acknowledge that the issue was known and the fix simple:
Do we have any statistics/some ea
The offset within and the length of the command sequence to execute are
supplied by the user with respect to the batch buffer. We should be
validating that region is wholly contained within the batch buffer;
make it so.
Reported-by: Ville Syrjälä
Signed-off-by: Chris Wilson
Cc: sta...@vger.kerne
On Fri, Nov 20, 2015 at 10:55:57AM +, Chris Wilson wrote:
> The cmd parser has the biggest impact on the BLT ring, because it is
> relatively verbose composed to the other engines as the vertex data is
> inline. It also typically has runs of repeating commands (again since
> the vertex data is
On Fri, Nov 20, 2015 at 10:55:58AM +, Chris Wilson wrote:
> Since we blow the TLB caches by using kmap/kunmap, we may as well go the
> whole hog and see if declaring our destination page as WC is faster than
> keeping it as WB and using clflush. It should be!
Is this description for another pa
On Fri, Nov 20, 2015 at 10:55:59AM +, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_cmd_parser.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
> b/drivers/gpu/drm/i915/i915_cmd_parser
On Mon, 16 Nov 2015, Yetunde Adebisi wrote:
> This patch adds support for eDP backlight control using DPCD registers to
> backlight hooks in intel_panel.
>
> It checks for backlight control over AUX channel capability and sets up
> function pointers to get and set the backlight brightness level if
On Fri, Nov 20, 2015 at 04:41:53PM +0200, Ville Syrjälä wrote:
> > + if (batch_len > shadow_batch_obj->base.size ||
>
> AFAIK that can't actaully happen since we allocate the shadow batch
> based on batch_len. But I see it was already like this in the old code.
>
> > + batch_len + batch_s
On Fri, Nov 20, 2015 at 10:55:56AM +, Chris Wilson wrote:
> With a little complexity to handle cmds straddling page boundaries, we
> can completely avoiding having to vmap the batch and the shadow batch
> objects whilst running the command parser.
>
> On ivb i7-3720MQ:
>
> x11perf -dot before
A long time ago (before 3.14) we relied on a permanent pinning of the
ifbdev to lock the fb in place inside the GGTT. However, the
introduction of stealing the BIOS framebuffer and reusing its address in
the GGTT for the fbdev has muddied waters and we use an inherited fb.
However, the inherited fb
On Tue, 2015-11-17 at 11:56 +0530, Shubhangi Shrivastava wrote:
> This patch moves probing for panel, DPCD read etc to another
> function intel_dp_long_pulse, while intel_dp_detect returns
> the status as connected or disconnected depending on
> whether the edid is available or not.
May i suggest
A long time ago (before 3.14) we relied on a permanent pinning of the
ifbdev to lock the fb in place inside the GGTT. However, the
introduction of stealing the BIOS framebuffer and reusing its address in
the GGTT for the fbdev has muddied waters and we use an inherited fb.
However, the inherited fb
As we mark the preallocated objects as bound, we should also flag them
correctly as being map-and-fenceable (if appropriate!) so that later
users do not get confused and try and rebind the pinned vma in order to
get a map-and-fenceable binding.
Signed-off-by: Chris Wilson
Cc: "Goel, Akash"
Cc: D
On Fri, 20 Nov 2015, "Kahola, Mika" wrote:
>> -Original Message-
>> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>> Sent: Friday, November 20, 2015 3:47 PM
>> To: Kahola, Mika; intel-gfx@lists.freedesktop.org
>> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Make DP fast link trainin
On Tue, 2015-11-17 at 12:17 +0530, Shubhangi Shrivastava wrote:
> Current DP detection has DPCD operations split across
> intel_dp_hpd_pulse and intel_dp_detect which contains
> duplicates as well. Also intel_dp_detect is called
> during modes enumeration as well which will result
> in multiple dpc
On Thu, Nov 19, 2015 at 09:20:16AM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Add SKL and KBL cdclk changes during modeset. Taking into account new
> linkrates available using 8640 VCO.
>
> Signed-off-by: Clint Taylor
> ---
> drivers/gpu/drm/i915/intel_display.c | 68
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Friday, November 20, 2015 3:47 PM
> To: Kahola, Mika; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Make DP fast link training a
> module parameter
>
> On Fri, 20 Nov 2015,
On Fri, 20 Nov 2015, Mika Kahola wrote:
> There is a bug report
>
> https://bugs.freedesktop.org/show_bug.cgi?id=91393
>
> indicating that there are panels that do not support
> link training starting with non-zero voltage swing and
> pre-emphasis values.
>
> This patch proposes to make this fast
There is a bug report
https://bugs.freedesktop.org/show_bug.cgi?id=91393
indicating that there are panels that do not support
link training starting with non-zero voltage swing and
pre-emphasis values.
This patch proposes to make this fast link training
feature as one module parameter. To take m
From: Tvrtko Ursulin
Commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae
Author: Tvrtko Ursulin
Date: Mon Oct 5 13:26:36 2015 +0100
drm/i915: Clean up associated VMAs on context destruction
Added a warning based on an incorrect assumption that all VMAs
in a VM will be on the inactive list at
On Thu, Nov 19, 2015 at 08:01:41PM -0800, Matt Roper wrote:
> On Thu, Nov 05, 2015 at 02:55:20PM +0200, Jani Nikula wrote:
> > On Thu, 05 Nov 2015, Matt Roper wrote:
> > > On Wed, Nov 04, 2015 at 04:12:33PM +0200, Jani Nikula wrote:
> > >> On Tue, 03 Nov 2015, Matt Roper wrote:
> > >> > Although
On Thu, Nov 19, 2015 at 03:40:45PM -0800, Ben Widawsky wrote:
> On Wed, Oct 21, 2015 at 06:40:34PM +0300, Imre Deak wrote:
> > In an upcoming patch we'll need the actual mask of slices in addition to
> > their count, so replace the count field with a mask.
> >
> > Signed-off-by: Imre Deak
> > ---
This reimplements the denial-of-service protection against igt from
commit 227f782e4667fc622810bce8be8ccdeee45f89c2
Author: Chris Wilson
Date: Thu May 15 10:41:42 2014 +0100
drm/i915: Retire requests before creating a new one
and transfers the stall from before each batch into a new close
Instead of querying the reset counter before every access to the ring,
query it the first time we touch the ring, and do a final compare when
submitting the request. For correctness, we need to then sanitize how
the reset_counter is incremented to prevent broken submission and
waiting across resets
The multiple levels of indirect do nothing but hinder the compiler and
the pointer chasing turns to be quite painful but painless to fix.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 14 ++---
drivers/gpu/drm/i915/i915_drv.h| 9 +
driv
Combine the near identical implementations of intel_logical_ring_begin()
and intel_ring_begin() - the only difference is that the logical wait
has to check for a matching ring (which is assumed by legacy).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c| 149 ++--
In a few frequent cases, having a direct pointer to the drm_i915_private
from the request is very useful.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c| 22 +++---
drivers/gpu/drm/i915/i915_gem_context.c| 23 +--
drivers/gpu/drm/i915/
Having ringbuf->ring point to an engine is confusing, so rename it once
again to ring->engine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c| 46 -
drivers/gpu/drm/i915/intel_ringbuffer.c | 36 +-
drivers/gpu/drm/
In order to disambiguate between the pointer to the intel_engine_cs
(called ring) and the intel_ringbuffer (called ringbuf), rename
s/ring/engine/.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 11 ++-
drivers/gpu/drm/i915/i915_drv.h | 12 +--
driv
Now that we have disambuigated ring and engine, we can use the clearer
and more consistent name for the intel_ringbuffer pointer in the
request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h| 2 +-
drivers/gpu/drm/i915/i915_gem.c| 28 +++---
drivers/g
Both perform the same actions with more or less indirection, so just
unify the code.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c| 2 +-
drivers/gpu/drm/i915/i915_gem_context.c| 8 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 34 -
drivers/gpu/d
We only need our private device struct for checking semapahore status,
and to reduce churn later convert the parameter over now.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c
Now that we share intel_ring_begin(), reserving space for the tail of
the request is identical between legacy/execlists and so the tautology
can be removed.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 7 +++
drivers/gpu/drm/i915/intel_lrc.c| 15
Perform s/ringbuf/ring/ on the context struct for consistency with the
ring/engine split.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 4 +-
drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
drivers/gpu/drm/i915/intel_
CLOCK_MONOTONIC_RAW is not affected by NTP, so it should be THE clock
used for timing execution of tests.
When fetching either the starting or ending time of a test, show the
time as -1.000s.
v6:
- Whitespace corrections (Chris)
v5:
- Do not use C99 style comments (Chris)
v4:
- Introduce time_v
On to, 2015-11-19 at 11:32 +, Chris Wilson wrote:
> On Thu, Nov 19, 2015 at 12:35:23PM +0200, Joonas Lahtinen wrote:
> > +static void _igt_kmsg_capture_reset(void)
> > +{
> > + if (igt_kmsg_capture_fd != -1)
> > + close(igt_kmsg_capture_fd);
> > +
> > + igt_kmsg_capture_fd = open(
From: Tvrtko Ursulin
Test designed to trigger the
WARN_ON(!list_empty(&ppgtt->base.active_list))
in i915_gem_context_clean.
v2:
Simplify execbuf building and the test itself. Cleanup code. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Daniel Vetter
---
tests/.gitignore
On Fri, Nov 20, 2015 at 01:26:23PM +0200, Joonas Lahtinen wrote:
> +static double
> +time_elapsed(struct timespec *then,
> + struct timespec* now) {
I can't stop myself... ^
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
On Fri, Nov 20, 2015 at 01:22:51PM +0200, Joonas Lahtinen wrote:
> On to, 2015-11-19 at 10:41 +0100, Daniel Vetter wrote:
> > On Thu, Nov 19, 2015 at 10:38 AM, Daniel Vetter
> > wrote:
> > > On Wed, Nov 18, 2015 at 05:32:59PM +, Chris Wilson wrote:
> > > > On Wed, Nov 18, 2015 at 04:44:20PM +0
CLOCK_MONOTONIC_RAW is not affected by NTP, so it should be THE clock
used for timing execution of tests.
When fetching either the starting or ending time of a test, show the
time as -1.000s.
v5:
- Do not use C99 style comments (Chris)
v4:
- Introduce time_valid macro (Chris)
- Reduce amount of
Now that we have better ioctl wrappers, let's make us of them. The
advantage should be in improved error reporting in case
gem_quiescent_gpu() ever fails.
Signed-off-by: Chris Wilson
---
lib/drmtest.c | 40
1 file changed, 12 insertions(+), 28 deletions(-
On to, 2015-11-19 at 10:41 +0100, Daniel Vetter wrote:
> On Thu, Nov 19, 2015 at 10:38 AM, Daniel Vetter
> wrote:
> > On Wed, Nov 18, 2015 at 05:32:59PM +, Chris Wilson wrote:
> > > On Wed, Nov 18, 2015 at 04:44:20PM +0100, Daniel Vetter wrote:
> > > > On Mon, Nov 16, 2015 at 03:22:23PM +0200,
On Thu, 19 Nov 2015 17:04:20 +0100,
Takashi Iwai wrote:
>
> On Thu, 19 Nov 2015 16:51:05 +0100,
> Daniel Vetter wrote:
> >
> > On Thu, Nov 19, 2015 at 12:09:56PM +0100, Takashi Iwai wrote:
> > > Currently a DDI port may register the DP hotplug handler even though
> > > it's used with HDMI, and th
On Fri, 20 Nov 2015, Imre Deak wrote:
> On Fri, 2015-11-20 at 11:54 +0200, Imre Deak wrote:
>> On Thu, 2015-11-19 at 21:17 +0200, Ville Syrjälä wrote:
>> > On Thu, Nov 19, 2015 at 09:13:04PM +0200, Imre Deak wrote:
>> > > On Thu, 2015-11-19 at 21:08 +0200, Ville Syrjälä wrote:
>> > > > On Thu, Nov
Since we blow the TLB caches by using kmap/kunmap, we may as well go the
whole hog and see if declaring our destination page as WC is faster than
keeping it as WB and using clflush. It should be!
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 19 +++
1 f
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 4a3e90b042c5..cfd07bfe6e75 100644
--- a/drivers/gpu/drm/i915/i915_c
The existing code's hashfunction is very suboptimal (most 3D commands
use the same bucket degrading the hash to a long list). The code even
acknowledge that the issue was known and the fix simple:
/*
* If we attempt to generate a perfect hash, we should be able to look at bits
* 31:29 of a comma
With a little complexity to handle cmds straddling page boundaries, we
can completely avoiding having to vmap the batch and the shadow batch
objects whilst running the command parser.
On ivb i7-3720MQ:
x11perf -dot before 54.3M, after 53.2M (max 203M)
glxgears before 7110 fps, after 7300 fps (max
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 51 --
drivers/gpu/drm/i915/i915_drv.h| 4 ++-
2 files changed, 14 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd
I spent yonks trying to define tests that produce reliable results for
demonstrating the impact of the cmdparser, that don't require inspection
of a perf profile. So far, with any reliability (because gen7 thermal
throttling makes life difficult) I can demonstrate the impact of using
vmap + WC. Imp
The cmd parser has the biggest impact on the BLT ring, because it is
relatively verbose composed to the other engines as the vertex data is
inline. It also typically has runs of repeating commands (again since
the vertex data is inline, it typically has sequences of XY_SETUP_BLT,
XY_SCANLINE_BLT..)
As paranoia, we want to ensure that the CPU's PTEs have been revoked for
the object before we return from i915_gem_release_mmap(). This allows us
to rely on there being no outstanding memory accesses and guarantees
serialisation of the code against concurrent access just by calling
i915_gem_release
In commit 0a878716265e9af9f697264dc2e858fcc060d833
Author: Daniel Vetter
Date: Thu Oct 15 14:23:01 2015 +0200
drm/i915: restore ggtt double-bind avoidance
we wrote the ggtt_bind_vma() observing a number of cleanups we could do
over the template of aliasing_gtt_bind_vma(). Now let's apply t
From: Dhanya
This patch will verify color correction capability of a display driver.
Gamma/CSC/De-gamma verifications are supported.
Signed-off-by: Dhanya
---
tests/Makefile.sources |1 +
tests/kms_color.c | 1070
2 files changed, 1071
On Fri, 2015-11-20 at 11:54 +0200, Imre Deak wrote:
> On Thu, 2015-11-19 at 21:17 +0200, Ville Syrjälä wrote:
> > On Thu, Nov 19, 2015 at 09:13:04PM +0200, Imre Deak wrote:
> > > On Thu, 2015-11-19 at 21:08 +0200, Ville Syrjälä wrote:
> > > > On Thu, Nov 19, 2015 at 08:55:01PM +0200, Imre Deak wrot
On Fri, Nov 20, 2015 at 03:07:58PM +0530, Ankitprasad Sharma wrote:
> On Wed, 2015-11-18 at 10:59 +0100, Daniel Vetter wrote:
> > On Thu, Nov 05, 2015 at 05:15:59PM +0530, ankitprasad.r.sha...@intel.com
> > wrote:
> > > From: Ankitprasad Sharma
> > >
> > > In pwrite_fast, map an object page by p
On Wed, 2015-11-18 at 10:59 +0100, Daniel Vetter wrote:
> On Thu, Nov 05, 2015 at 05:15:59PM +0530, ankitprasad.r.sha...@intel.com
> wrote:
> > From: Ankitprasad Sharma
> >
> > In pwrite_fast, map an object page by page if obj_ggtt_pin fails. First,
> > we try a nonblocking pin for the whole obj
1 - 100 of 115 matches
Mail list logo
