[Intel-gfx] [PATCH] drm/i915: increase the tries for HDMI hotplug live status checking

2015-12-23 Thread Gary Wang
The total delay of HDMI hotplug detecting with 30ms is sometimes not enoughtfor HDMI live status up with specific HDMI monitors in BSW platform. After doing experiments for following monitors, it needs 80ms at least for those worst cases. Lenovo L246 1xwA (4 failed, necessary hot-plug delay: 58/4

Re: [Intel-gfx] [PATCH] drm/i915: increase the tries for HDMI hotplug live status checking

2015-12-23 Thread Wang, Gary C
For my test on this issue, it only got high fail-rate with some specific HDMI monitors. It’s also not easy to reproduce it by modern HDMI monitors (with 1080p/2K/4K resolutions…etc.) or will get low fail-rat (e.g. 1/50 failed test) with that ones. So Linux BSW Gfx validation team could also su

[Intel-gfx] ✗ failure: Fi.CI.BAT

2015-12-23 Thread Patchwork
== Summary == Built on 7e671e69deffb88d60687dacffe6e34a5d046500 drm-intel-nightly: 2015y-12m-22d-13h-28m-34s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) Test kms_flip: Subgroup basic-flip-vs-dpms:

[Intel-gfx] [PATCH] tests/kms_rotation_crc : Added Support for 90/270 roation tests for RGB565 Formats

2015-12-23 Thread Mayuresh Gharpure
Signed-off-by: Mayuresh Gharpure --- tests/kms_rotation_crc.c | 30 +- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c index c3241cf..8732eac 100644 --- a/tests/kms_rotation_crc.c +++ b/tests/kms_rotatio

[Intel-gfx] [PATCH] tests/kms_rotation_crc : Added Support for 90/270 roation tests for RGB565 Formats

2015-12-23 Thread Mayuresh Gharpure
Signed-off-by: Mayuresh Gharpure --- tests/kms_rotation_crc.c | 30 +- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c index c3241cf..8732eac 100644 --- a/tests/kms_rotation_crc.c +++ b/tests/kms_rotatio

Re: [Intel-gfx] [RFC 2/2] drm/i915: Render decompression support for Gen9

2015-12-23 Thread Daniel Stone
Hi Vandana, On 23 December 2015 at 03:20, Kannan, Vandana wrote: > How does VT switch work in case of rotation, setting different pixel format, > etc? Pixel format is a property of the framebuffer, not a per-plane property, so is unaffected. Rotation is generic, so there is specific code to hand

Re: [Intel-gfx] [PATCH 1/6] drm: Create Color Management DRM properties

2015-12-23 Thread Daniel Stone
Hi, On 21 December 2015 at 12:38, Daniel Vetter wrote: > On Fri, Dec 18, 2015 at 04:53:28PM +, Daniel Stone wrote: >> > +struct drm_r32g32b32 { >> > + /* >> > +* Data is in U8.24 fixed point format. >> > +* All platforms support values within [0, 1.0] range, >> > +

Re: [Intel-gfx] [PATCH v5 2/2] drm/i915: Check DP no aux transaction bit on link training

2015-12-23 Thread Jani Nikula
On Tue, 22 Dec 2015, Lukas Wunner wrote: > Hi Mika, > > On Mon, Dec 21, 2015 at 01:39:15PM +0200, Mika Kahola wrote: >> Check if no AUX transactions are required on DP link training. >> If this bit is set, we can reuse the known good drive current >> and pre-emphasis level from the last "full" lin

Re: [Intel-gfx] [PULL] drm-intel-next

2015-12-23 Thread Chris Wilson
On Tue, Dec 22, 2015 at 04:31:22PM +, Tvrtko Ursulin wrote: > > On 22/12/15 14:31, Chris Wilson wrote: > >On Tue, Dec 22, 2015 at 03:05:14PM +0100, Daniel Vetter wrote: > >>On Tue, Dec 22, 2015 at 11:37:18AM +0100, Daniel Vetter wrote: > >>>Hi Dave, > >>> > >>>Final 4.5 feature pull for drm/i9

[Intel-gfx] [PULL] drm-intel-fixes

2015-12-23 Thread Jani Nikula
Hi Dave (and/or Linus, depending on the new arrival and eggnog schedules) - Here's a batch of i915 fixes all around. It may be slightly bigger than one would hope for at this stage, but they've all been through testing in our -next before being picked up for v4.4. Also, I missed Dave's fixes pull

[Intel-gfx] [RFC] drm/i915/bxt: Add pipe_src size property

2015-12-23 Thread Nabendu Maiti
This patch is adding pipesource size as property as intel property.User application is allowed to change the pipe source size in runtime on BXT/SKL. Added the property as inteli crtc property. Comments and suggestions are requested for whether we can keep the property as intel crtc property or mov

Re: [Intel-gfx] [PATCH v5] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

2015-12-23 Thread Jani Nikula
On Thu, 17 Dec 2015, Daniel Vetter wrote: > On Thu, Dec 10, 2015 at 05:41:30PM +0100, Takashi Iwai wrote: >> On Thu, 10 Dec 2015 17:36:04 +0100, >> Ville Syrjälä wrote: >> > >> > On Fri, Dec 04, 2015 at 04:05:26PM +, Chris Wilson wrote: >> > > A long time ago (before 3.14) we relied on a perm

[Intel-gfx] [PATCH] RFC drm/i915: Remove (struct_mutex) locking for wait-ioctl

2015-12-23 Thread Chris Wilson
With a bit of care (and leniency) we can iterate over the object and wait for previous rendering to complete with judicial use of atomic reference counting. The ABI requires us to ensure that an active object is eventually flushed (like the busy-ioctl) which is guaranteed by our management of reque

Re: [Intel-gfx] [PATCH] RFC drm/i915: Remove (struct_mutex) locking for wait-ioctl

2015-12-23 Thread Chris Wilson
On Wed, Dec 23, 2015 at 11:19:23AM +, Chris Wilson wrote: > With a bit of care (and leniency) we can iterate over the object and > wait for previous rendering to complete with judicial use of atomic > reference counting. The ABI requires us to ensure that an active object > is eventually flushe

Re: [Intel-gfx] [PATCH] drm/i915: increase the tries for HDMI hotplug live status checking

2015-12-23 Thread Kumar, Shobhit
On 12/23/2015 01:41 PM, Gary Wang wrote: The total delay of HDMI hotplug detecting with 30ms is sometimes not enoughtfor HDMI live status up with specific HDMI monitors in BSW platform. After doing experiments for following monitors, it needs 80ms at least for those worst cases. Lenovo L246 1xw

Re: [Intel-gfx] vsync + vaapi question

2015-12-23 Thread Chris Wilson
On Tue, Dec 22, 2015 at 11:25:53PM +0100, Lukas Hejtmanek wrote: > On Tue, Dec 22, 2015 at 08:54:08PM +, Chris Wilson wrote: > > Not really. The Primary output will be used as the vsync so long as a > > single pixel of the Window is upon it. Fundamentally, we need to use the > > output that the

Re: [Intel-gfx] [PATCH] RFC drm/i915: Remove (struct_mutex) locking for wait-ioctl

2015-12-23 Thread Chris Wilson
On Wed, Dec 23, 2015 at 11:32:23AM +, Chris Wilson wrote: > On Wed, Dec 23, 2015 at 11:19:23AM +, Chris Wilson wrote: > > With a bit of care (and leniency) we can iterate over the object and > > wait for previous rendering to complete with judicial use of atomic > > reference counting. The

[Intel-gfx] [PATCH] dim: Add helper command to generate Fixes: lines

2015-12-23 Thread Daniel Vetter
Unfortunately a simple git alias doesn't work since the linux kernel wants a sha1 shortened to 12 characters, and the git commit prettifying can't do that with e.g. %12h. sed to the rescue. I'm using this when editing commit messages after applying (:read !dim fixes sha1 in vim). Signed-off-by: D

Re: [Intel-gfx] [PATCH] RFC drm/i915: Remove (struct_mutex) locking for wait-ioctl

2015-12-23 Thread Chris Wilson
On Wed, Dec 23, 2015 at 12:05:00PM +, Chris Wilson wrote: > On Wed, Dec 23, 2015 at 11:32:23AM +, Chris Wilson wrote: > > On Wed, Dec 23, 2015 at 11:19:23AM +, Chris Wilson wrote: > > > With a bit of care (and leniency) we can iterate over the object and > > > wait for previous renderin

Re: [Intel-gfx] vsync + vaapi question

2015-12-23 Thread Lukas Hejtmanek
On Wed, Dec 23, 2015 at 12:01:44PM +, Chris Wilson wrote: > The clipped extents of the va-api Window is used to determine which CRTC > to use as the vblank source. Hmm, the Primary Output is used as the > preference (i.e. if any part of that Window is on the Primary, it is > used as the CRTC -

Re: [Intel-gfx] [PATCH] RFC drm/i915: Remove (struct_mutex) locking for wait-ioctl

2015-12-23 Thread Chris Wilson
On Wed, Dec 23, 2015 at 12:13:15PM +, Chris Wilson wrote: > On Wed, Dec 23, 2015 at 12:05:00PM +, Chris Wilson wrote: > > On Wed, Dec 23, 2015 at 11:32:23AM +, Chris Wilson wrote: > > > On Wed, Dec 23, 2015 at 11:19:23AM +, Chris Wilson wrote: > > > > With a bit of care (and lenienc

Re: [Intel-gfx] [PATCH v5 2/2] drm/i915: Check DP no aux transaction bit on link training

2015-12-23 Thread Mika Kahola
On Tue, 2015-12-22 at 16:53 +0100, Lukas Wunner wrote: > Hi Mika, > > On Mon, Dec 21, 2015 at 01:39:15PM +0200, Mika Kahola wrote: > > Check if no AUX transactions are required on DP link training. > > If this bit is set, we can reuse the known good drive current > > and pre-emphasis level from th

[Intel-gfx] [PULL] topic/drm-misc

2015-12-23 Thread Daniel Vetter
Hi Dave, Just one more patch in drm-misc before I disappear into the swiss alps. I was a bit on the fence whether this should go into -fixes, but then figured meh. If it blows up in reality (the linked bug is just our QA) we can always cherry-pick afterwards. Cheers, Daniel The following change

[Intel-gfx] [maintainer-tools PATCH 2/2] drm-intel: document new fixes flow

2015-12-23 Thread Jani Nikula
Signed-off-by: Jani Nikula --- drm-intel-flow.dot | 9 +++--- drm-intel.rst | 81 ++ 2 files changed, 79 insertions(+), 11 deletions(-) diff --git a/drm-intel-flow.dot b/drm-intel-flow.dot index 0a16a915a49c..cfee83872c37 100644 --- a/drm

[Intel-gfx] [maintainer-tools PATCH 1/2] drm-intel: add committer guidelines

2015-12-23 Thread Jani Nikula
Add guidelines to help our committers make the right calls when pushing patches. Signed-off-by: Jani Nikula --- drm-intel.rst | 115 +- 1 file changed, 114 insertions(+), 1 deletion(-) diff --git a/drm-intel.rst b/drm-intel.rst index c6b08

Re: [Intel-gfx] [maintainer-tools PATCH 1/2] drm-intel: add committer guidelines

2015-12-23 Thread Jani Nikula
On Wed, 23 Dec 2015, Jani Nikula wrote: > Add guidelines to help our committers make the right calls when pushing > patches. Actually just pushed these two anyway; posted the patches for transparency and for a place for discussion. We can update the docs as we go. BR, Jani. > > Signed-off-by:

[Intel-gfx] [PATCH v2 2/3] drm/i915: Remove (struct_mutex) locking for wait-ioctl

2015-12-23 Thread Chris Wilson
With a bit of care (and leniency) we can iterate over the object and wait for previous rendering to complete with judicial use of atomic reference counting. The ABI requires us to ensure that an active object is eventually flushed (like the busy-ioctl) which is guaranteed by our management of reque

[Intel-gfx] [PATCH v2 3/3] drm/i915: Remove (struct_mutex) locking for busy-ioctl

2015-12-23 Thread Chris Wilson
By applying the same logic as for wait-ioctl, we can query whether a request has completed without holding struct_mutex. The biggest impact system-wide is removing the flush_active and the contention that causes. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem.c | 53 ++

[Intel-gfx] [PATCH v2 1/3] drm/i915: Enable lockless lookup of request tracking via RCU

2015-12-23 Thread Chris Wilson
If we enable RCU for the requests (providing a grace period where we can inspect a "dead" request before it is freed), we can allow callers to carefully perform lockless lookup of an active request. However, by enabling deferred freeing of requests, we can potentially hog a lot of memory when deal

Re: [Intel-gfx] vsync + vaapi question

2015-12-23 Thread Chris Wilson
On Wed, Dec 23, 2015 at 01:13:46PM +0100, Lukas Hejtmanek wrote: > On Wed, Dec 23, 2015 at 12:01:44PM +, Chris Wilson wrote: > > The clipped extents of the va-api Window is used to determine which CRTC > > to use as the vblank source. Hmm, the Primary Output is used as the > > preference (i.e.

[Intel-gfx] [PATCH] dim: Add helper command to generate Fixes: lines

2015-12-23 Thread Daniel Vetter
Unfortunately a simple git alias doesn't work since the linux kernel wants a sha1 shortened to 12 characters, and the git commit prettifying can't do that with e.g. %12h. sed to the rescue. I'm using this when editing commit messages after applying (:read !dim fixes sha1 in vim). v2: Also update

Re: [Intel-gfx] [PATCH] dim: Add helper command to generate Fixes: lines

2015-12-23 Thread Daniel Vetter
On Wed, Dec 23, 2015 at 02:50:41PM +0100, Daniel Vetter wrote: > Unfortunately a simple git alias doesn't work since the linux kernel > wants a sha1 shortened to 12 characters, and the git commit > prettifying can't do that with e.g. %12h. sed to the rescue. > > I'm using this when editing commit

[Intel-gfx] [PATCH i-g-t] igt_core: Fix logging to display extended line

2015-12-23 Thread Derek Morton
line[strlen(line)] will always evaluate to NULL so line_continuation was always true. That prevented the program name, pid and log level ever being printed. Changed to [strlen(line) - 1] so the last character before the null terminator is compared with '\n' to determine line_continuation. Signed-o

Re: [Intel-gfx] [PATCH v4] drm/i915/guc: Move GuC wq_check_space to alloc_request_extras

2015-12-23 Thread Dave Gordon
On 16/12/15 19:45, yu@intel.com wrote: From: Alex Dai Split GuC work queue space checking from submission and move it to ring_alloc_request_extras. The reason is that failure in later i915_add_request() won't be handled. In the case timeout happens, driver can return early in order to handl

Re: [Intel-gfx] [PULL] drm-intel-fixes

2015-12-23 Thread Linus Torvalds
On Wed, Dec 23, 2015 at 2:40 AM, Jani Nikula wrote: > > Hi Dave (and/or Linus, depending on the new arrival and eggnog > schedules) - I'll pull it directly. Dave just sent me his pending drm fixes, he may or may not be around any more, it's already christmas eve down under. Linus ___

[Intel-gfx] Suspend To RAM failure in >= 4.1 - bissected to "drm/i915: Track GEN6 page table usage"

2015-12-23 Thread Sylvain Munaut
Hi, When trying to upgrade my kernel yesterday to the latest 4.3.3 I noticed that the suspend to ram was not working. Basically it goes to sleep but never wakes up. It seems to power up but no screen, not available through ssh either and afaict nothing runs afterwards. I first tried a couple off

Re: [Intel-gfx] [PULL] drm-intel-fixes

2015-12-23 Thread Linus Torvalds
On Wed, Dec 23, 2015 at 2:40 AM, Jani Nikula wrote: > > > git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-12-23 Btw, since you're already using tags, mind using *signed* tags instead? It's just good housekeeping.. Linus _

[Intel-gfx] [PATCH v2, 3/4] drm/i915: simplify allocation of driver-internal requests

2015-12-23 Thread Dave Gordon
There are a number of places where the driver needs a request, but isn't working on behalf of any specific user or in a specific context. At present, we associate them with the per-engine default context. A future patch will abolish those per-engine context pointers; but we can already eliminate a

[Intel-gfx] [PATCH v2, 1/4] drm/i915: remove intel_context::file_priv, add flag for default context

2015-12-23 Thread Dave Gordon
The file_priv member was used in only one place, where we already had the file_priv and therefore didn't need to derive it from the context (in fact, we just found the context by reference to the file_priv). So by fixing up that one use, we can drop file_priv entirely. OTOH sometimes we need to id

[Intel-gfx] [PATCH v2, 2/4] drm/i915: simplify testing for the global default context

2015-12-23 Thread Dave Gordon
There are quite a number of places where the driver tests whether a given context is or is not the global default context, usually by checking whether an engine's default_pointer points to the context. Now that we have a 'is_global_default' flag in the context itself, all these tests these can be r

[Intel-gfx] [PATCH v2, 0/4] improve handling of the driver's default context

2015-12-23 Thread Dave Gordon
A reworking of the previous patchset, incorporating Daniel Vetter's point that we don't need intel_context::file_priv and Chris Wilson's wish to abolish engine::default_context. Patch 1/4 starts the process by eliminating file_priv, which was only used in one place. Patch 2/4 removes lots of refer

[Intel-gfx] [PATCH v2, 4/4] drm/i915: abolish separate per-engine default_context pointers

2015-12-23 Thread Dave Gordon
Now that we've eliminated a lot of uses of engine::default_context, we can eliminate the pointer itself. All the engines share the same default intel_context, so we can just keep a single reference to it in the dev_priv structure rather than one in each of the engine[] elements. This make refcount

Re: [Intel-gfx] [PATCH v2, 2/4] drm/i915: simplify testing for the global default context

2015-12-23 Thread Chris Wilson
On Wed, Dec 23, 2015 at 07:33:53PM +, Dave Gordon wrote: > There are quite a number of places where the driver tests whether > a given context is or is not the global default context, usually by > checking whether an engine's default_pointer points to the context. > Now that we have a 'is_globa

Re: [Intel-gfx] [PATCH v2 1/2] mm: Export nr_swap_pages

2015-12-23 Thread Johannes Weiner
On Thu, Dec 10, 2015 at 10:32:42AM +0100, Daniel Vetter wrote: > On Fri, Dec 04, 2015 at 11:09:52AM -0500, Johannes Weiner wrote: > > On Fri, Dec 04, 2015 at 03:58:53PM +, Chris Wilson wrote: > > > Some modules, like i915.ko, use swappable objects and may try to swap > > > them out under memory

Re: [Intel-gfx] [PATCH v2 1/2] mm: Export nr_swap_pages

2015-12-23 Thread Andrew Morton
On Wed, 23 Dec 2015 17:04:27 -0500 Johannes Weiner wrote: > On Thu, Dec 10, 2015 at 10:32:42AM +0100, Daniel Vetter wrote: > > On Fri, Dec 04, 2015 at 11:09:52AM -0500, Johannes Weiner wrote: > > > On Fri, Dec 04, 2015 at 03:58:53PM +, Chris Wilson wrote: > > > > Some modules, like i915.ko, u

[Intel-gfx] ✗ warning: Fi.CI.BAT

2015-12-23 Thread Patchwork
== Summary == Built on ec0382c73cb1adc972bebdd94afad3f0ea117114 drm-intel-nightly: 2015y-12m-23d-22h-28m-25s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (skl-i5k-2) dmesg-warn -> PASS (bdw-nuci7)