On Mon, Jan 18, 2016 at 04:21:40PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 15, 2016 at 03:15:00PM -0800, Matt Roper wrote:
> > On Fri, Jan 15, 2016 at 08:48:26PM +0200, Ville Syrjälä wrote:
> > > On Thu, Oct 15, 2015 at 05:01:58PM +0300, ville.syrj...@linux.intel.com
> > > wrote:
> > > > From: V
On Monday 18 January 2016 06:30 PM, Ander Conselvan De Oliveira wrote:
On Mon, 2016-01-18 at 18:14 +0530, Shubhangi Shrivastava wrote:
On Thursday 14 January 2016 06:34 PM, Ander Conselvan De Oliveira wrote:
On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote:
This patch reads sin
On Thursday 14 January 2016 07:20 PM, Ander Conselvan De Oliveira wrote:
On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote:
This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change.
This will allow both detection of hotplu
On Mon, 2016-01-18 at 19:26 +0100, Lukas Wunner wrote:
Hi,
> Hi,
>
> On Mon, Jan 18, 2016 at 03:57:29PM +0100, Rafael J. Wysocki wrote:
> > On Monday, January 18, 2016 02:31:00 PM Ankitprasad Sharma wrote:
> > > On Fri, 2016-01-15 at 15:51 +0100, Rafael J. Wysocki wrote:
> > > > On Thursday, Janua
On Tue, Jan 19, 2016 at 10:14:30AM +0530, Thulasimani, Sivakumar wrote:
>
>
> On 1/19/2016 2:35 AM, Lukas Wunner wrote:
> >Hi,
> >
> >On Mon, Jan 18, 2016 at 04:22:19PM +0530, Shubhangi Shrivastava wrote:
> >>When created originally intel_dp_check_link_status()
> >>was supposed to handle only lin
On Friday 15 January 2016 03:37 PM, Ander Conselvan De Oliveira wrote:
On Thu, 2016-01-14 at 19:20 +0530, Shubhangi Shrivastava wrote:
On Wednesday 13 January 2016 07:03 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2016-01-13 at 13:20 +0200, Ander Conselvan De Oliveira wrote:
On Tue, 2016-
On Mon, Jan 18, 2016 at 10:01:24AM +, Tvrtko Ursulin wrote:
>
> On 13/01/16 19:11, Dave Gordon wrote:
> >On 13/01/16 19:01, yu@intel.com wrote:
> >>From: Alex Dai
> >>
> >>During driver unloading, the guc_client created for command submission
> >>needs to be released to avoid memory leak.
On Wednesday 13 January 2016 08:34 PM, Ander Conselvan De Oliveira wrote:
On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote:
When created originally intel_dp_check_link_status()
was supposed to handle only link training for short
pulse but has grown into handler for short pulse it
On Thursday 14 January 2016 06:30 PM, Ander Conselvan De Oliveira wrote:
On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote:
Sink count can change between short pulse hpd hence this patch
adds a member variable to intel_dp so we can track any changes
between short pulse interrupts.
On Mon, Jan 18, 2016 at 04:16:39PM +, Nick Hoath wrote:
> On 07/01/2016 10:20, Dave Gordon wrote:
> >Now that we've eliminated a lot of uses of ring->default_context,
> >we can eliminate the pointer itself.
> >
> >All the engines share the same default intel_context, so we can just
> >keep a si
On 1/19/2016 2:14 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2016 at 10:14:30AM +0530, Thulasimani, Sivakumar wrote:
On 1/19/2016 2:35 AM, Lukas Wunner wrote:
Hi,
On Mon, Jan 18, 2016 at 04:22:19PM +0530, Shubhangi Shrivastava wrote:
When created originally intel_dp_check_link_status()
was s
On Thu, Jan 14, 2016 at 03:27:35PM +, Arun Siluvery wrote:
> Some of the HW registers are privileged and cannot be written to from
> non-privileged batch buffers coming from userspace unless they are added to
> the HW whitelist. This whitelist is maintained by HW and it is different from
> SW w
On Tue, Jan 19, 2016 at 02:29:22PM +0530, Thulasimani, Sivakumar wrote:
>
>
> On 1/19/2016 2:14 PM, Daniel Vetter wrote:
> >On Tue, Jan 19, 2016 at 10:14:30AM +0530, Thulasimani, Sivakumar wrote:
> >>
> >>On 1/19/2016 2:35 AM, Lukas Wunner wrote:
> >>>Hi,
> >>>
> >>>On Mon, Jan 18, 2016 at 04:22:
On Thu, Jan 14, 2016 at 11:31:07AM +, Nick Hoath wrote:
> On 14/01/2016 07:20, Patchwork wrote:
> >== Summary ==
Our BKM is to link to bugzilla entries to make sure these are all real
failures which are tracked already. Otherwise stuff falls through the
cracks.
> >
> >Built on 058740f8fced685
On Wed, Jan 13, 2016 at 06:33:10PM +0200, Mika Kuoppala wrote:
> It is beneficial to know the exact sw states of power wells
> at the moment when unclaimed register access is detect.
>
> When the backtrace has been printed to dmesg, it is
> followed by a power well states, for example:
>
>
> --[
On 1/19/2016 2:35 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2016 at 02:29:22PM +0530, Thulasimani, Sivakumar wrote:
On 1/19/2016 2:14 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2016 at 10:14:30AM +0530, Thulasimani, Sivakumar wrote:
On 1/19/2016 2:35 AM, Lukas Wunner wrote:
Hi,
On Mon, Jan 1
Hi Shubhangi,
On Mon, 2016-01-18 at 13:01 +, Patchwork wrote:
> == Summary ==
>
> HEAD is now at 2dd73be drm-intel-nightly: 2016y-01m-18d-09h-59m-27s UTC
> integration manifest
> Applying: drm/i915: Splitting intel_dp_detect
> Applying: drm/i915: Cleaning up intel_dp_hpd_pulse
> Applying: drm
When created originally intel_dp_check_link_status()
was supposed to handle only link training for short
pulse but has grown into handler for short pulse itself.
This patch cleans up this function by splitting it into
two halves. First intel_dp_short_pulse() is called,
which will be entry point and
On 01/15/2016 12:37 AM, Matt Roper wrote:
On Thu, Jan 14, 2016 at 05:32:42PM +0530, Shobhit Kumar wrote:
From: "Kumar, Mahesh"
Don't always use bytes_per_pixel using y_plane=0, instead use it
according to pixel format. If NV12 use y_plane eqal to 1
Signed-off-by: Kumar, Mahesh
The second p
== Summary ==
HEAD is now at 00a0c7d drm-intel-nightly: 2016y-01m-18d-16h-50m-37s UTC
integration manifest
Applying: drm/i915: Splitting intel_dp_detect
Applying: drm/i915: Cleaning up intel_dp_hpd_pulse
Applying: drm/i915: Reorganizing intel_dp_check_link_status
Applying: drm/i915: Save sink_cou
On 14/01/16 09:49, Patchwork wrote:
== Summary ==
Built on 058740f8fced6851aeda34f366f5330322cd585f drm-intel-nightly:
2016y-01m-13d-17h-07m-44s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS (bdw-nuci7)
Test kms_force
On Wed, Jan 13, 2016 at 05:41:44PM +, Damien Lespiau wrote:
> On Wed, Jan 13, 2016 at 05:38:15PM +, Chris Wilson wrote:
> > This is an expected error given the lack of the firmware so emit it at
> > KERN_NOTICE and not KERN_ERROR. Also include the firmware URL in the
> > user facing message
On Wed, Jan 13, 2016 at 02:05:04PM -0800, Rodrigo Vivi wrote:
> When we stop the sink CRC calculation we wait a while until the counter
> is reset to zero and return -ETIMEDOUT. However the sink crc was
> calculated already by this point so we just ignore this return at
> the main function.
>
> So
intel_dp_detect() is called for not just detection but
during modes enumeration as well. Repeating the whole
sequence during each of these calls is wasteful and
time consuming.
This patch moves probing for panel, DPCD read etc done in
intel_dp_detect() to a new function intel_dp_long_pulse().
Note
On 19/01/2016 09:00, Daniel Vetter wrote:
On Thu, Jan 14, 2016 at 03:27:35PM +, Arun Siluvery wrote:
Some of the HW registers are privileged and cannot be written to from
non-privileged batch buffers coming from userspace unless they are added to
the HW whitelist. This whitelist is maintaine
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 dpcd operations. So this patch tries
to solve both these by bringing all DPCD
Sink count can change between short pulse hpd hence this patch
adds a member variable to intel_dp so we can track any changes
between short pulse interrupts.
This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd.
SINK_COUNT dpcd is not depe
This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change.
This will allow both detection of hotplug and unplug of panels
through dongles that give only short pulse for such events.
v2: changed variable type from u8 to bool (Jani)
retur
When created originally intel_dp_check_link_status()
was supposed to handle only link training for short
pulse but has grown into handler for short pulse itself.
This patch cleans up this function by splitting it into
two halves. First intel_dp_short_pulse() is called,
which will be entry point and
Sure Ander.. Have resent this series of patches.. Will ensure to resend the
series for multiple patch changes.. :)
Thanks and Regards,
Shubhangi Shrivastava.
-Original Message-
From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
Sent: Tuesday, January 19, 2016 3:09 PM
To: Pa
On 18/01/16 20:47, Chris Wilson wrote:
On Mon, Jan 18, 2016 at 05:14:26PM +, Tvrtko Ursulin wrote:
On 18/01/16 16:53, Chris Wilson wrote:
On Mon, Jan 18, 2016 at 03:02:25PM +, Tvrtko Ursulin wrote:
- while (!list_empty(&ring->request_list)) {
- struct drm_i915_ge
Hi,
On 10 September 2015 at 16:02, Daniel Vetter wrote:
> On Wed, Sep 09, 2015 at 10:04:23AM -0700, Jesse Barnes wrote:
>> On 09/09/2015 09:36 AM, Smith, Gary K wrote:
>> > I don't understand why this is an issue. Surely the fb is to describe
>> > static state about the buffer, not dynamic state.
intel_dp_detect() is called for not just detection but
during modes enumeration as well. Repeating the whole
sequence during each of these calls is wasteful and
time consuming.
This patch moves probing for panel, DPCD read etc done in
intel_dp_detect() to a new function intel_dp_long_pulse().
Note
Sink count can change between short pulse hpd hence this patch
adds a member variable to intel_dp so we can track any changes
between short pulse interrupts.
This patch reads sink_count dpcd always and removes its
read operation based on values in downstream port dpcd.
SINK_COUNT dpcd is not depe
When created originally intel_dp_check_link_status()
was supposed to handle only link training for short
pulse but has grown into handler for short pulse itself.
This patch cleans up this function by splitting it into
two halves. First intel_dp_short_pulse() is called,
which will be entry point and
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 dpcd operations. So this patch tries
to solve both these by bringing all DPCD
This patch checks for changes in sink count between short pulse
hpds and forces full detect when there is a change.
This will allow both detection of hotplug and unplug of panels
through dongles that give only short pulse for such events.
v2: changed variable type from u8 to bool (Jani)
retur
== Summary ==
Built on 00a0c7d1ae09b1259c7af8e5a088b0b225d805df drm-intel-nightly:
2016y-01m-18d-16h-50m-37s UTC integration manifest
Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS (skl-i5k-2)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b
== Summary ==
Built on 00a0c7d1ae09b1259c7af8e5a088b0b225d805df drm-intel-nightly:
2016y-01m-18d-16h-50m-37s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (skl-i5k-2) UNSTABLE
pass -> DMESG-WARN (bdw-
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 written back to by the GPU.
Now that the context is pinned until later in the request/context
lifecycle, it no longer needs to be pinned from context_queue to
re
== Summary ==
HEAD is now at 00a0c7d drm-intel-nightly: 2016y-01m-18d-16h-50m-37s UTC
integration manifest
Applying: drm/i915: Extend LRC pinning to cover GPU context writeback
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i915/i915_drv.h
M drivers/gpu/drm/i915/i915
On Tue, Jan 19, 2016 at 10:16:52AM +, Arun Siluvery wrote:
> On 19/01/2016 09:00, Daniel Vetter wrote:
> >On Thu, Jan 14, 2016 at 03:27:35PM +, Arun Siluvery wrote:
> >>Some of the HW registers are privileged and cannot be written to from
> >>non-privileged batch buffers coming from userspa
On Thu, Jan 14, 2016 at 10:49:45AM +, Arun Siluvery wrote:
> Pending reset requests are cleared before suspending, they should be picked up
> after resume when new work is submitted.
>
> This is originally added as part of TDR patches for Gen8 from Tomas Elf which
> are under review, as sugges
On Tue, Jan 19, 2016 at 09:03:13AM +0100, Daniel Vetter wrote:
> On Mon, Jan 18, 2016 at 04:21:40PM +0200, Ville Syrjälä wrote:
> > On Fri, Jan 15, 2016 at 03:15:00PM -0800, Matt Roper wrote:
> > > On Fri, Jan 15, 2016 at 08:48:26PM +0200, Ville Syrjälä wrote:
> > > > On Thu, Oct 15, 2015 at 05:01:
Workqueue initalization doesn't depend on any other device specific
resource, so move it close to the beginning, so we don't need to
consider them when thinking about dependencies for other resources.
Also factor out things to separate init/cleanup functions to make
i915_driver_load()/unload() cle
Clarify the name of the label on the error path, making it clear what's
being cleaned up. The kmem_cache_destroy() calls are NOPs on the
corresponding error path.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_dma.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a
For Sagar's BXT RC6 setup sanitization patch [1], we'll need the details
about the GTT/stolen memory reservation early during driver loading, so
this patchset moves the required init calls earlier accordingly. It also
sanitizes a few MMIO/GEM init/clean-up steps on the way.
[1]
http://lists.freede
Factor out the common GEM shrinker clean-up code and call the shrinker
init function from the same function from where the corresponding
shrinker clean-up function is called. Also add sanity checking to the
shrinker and OOM registration calls.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i9
Factor out common clean-up code for the GEM load time init function.
Also rename i915_gem_load() to i915_gem_load_init() to have a better
match with its new clean-up function.
No functional change.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_dma.c | 10 +++---
drivers/gpu/drm/i91
The only device specific dependency of the stolen memory setup is the
MMIO mapping and the stolen memory size. Both are already available in
i915_gtt_init(), so move the stolen initialization to there. The
clean-up code for i915_gtt_init() is in i915_global_gtt_cleanup(), so
move the stolen memory
commit ebae38d061df3deffa7c17b030ea14a5216ee55f
Author: Animesh Manna
Date: Wed Oct 28 23:58:55 2015 +0200
drm/i915/gen9: csr_init after runtime pm enable
moved the DMC/CSR initialization later during driver loading, but didn't
move the cleanup earlier correspondingly during unloading. Fix
Move the MCHBAR setup right after the MMIO setup, since the two things
are logically related and the MCHBAR setup code doesn't depend on any
other device specific resource. We'll also need MCHBAR to be ready
earlier in an upcoming patch, so this is also a preparation for that.
Factor out the init/
Hi
Here's yet another patch series randomly modifying the FBC code. We
start by refactoring things in order to fix the locking problems, then
fix a few other smaller problems and apply some polishing.
Just to keep the tradition of the past 10 cover letters, I guess I
should say that this series i
The early return inside __intel_fbc_update does not completely check
all the parameters that affect the FBC register values. For example,
we currently lack looking at crtc->adjusted_y (for the fence Y offset)
and all the parameters that affect the CFB size (for i8xx).
Instead of just adding the mi
We say "dev_priv->fbc.something" way too many times in our code while
we could be saying just "fbc->something" with a previous declaration
of fbc. This has been bothering me for a while but I didn't want to
patch it since I wanted to fix the real problems first. But as I add
more code I keep thinki
Extract all the code that checks if the FBC configuration is valid to
its own function, making __intel_fbc_update() much simpler.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 92 ++--
1 file changed, 50 insertions(+), 42 deletions(-)
dif
Instead of waiting for 50ms, just wait until the next vblank, since
it's the minimum requirement. The whole infrastructure of FBC is based
on vblanks, so waiting for X vblanks instead of X milliseconds sounds
like the correct way to go. Besides, 50ms may be less than a vblank on
super slow modes th
If frontbuffer_bits doesn't match the current frontbuffer, there's no
reason to recompress or update FBC.
There was a plan to make the FBC test suite catch this type of
problem, but it never got implemented due to being low priority.
While at it, also implement Ville's suggestion and use
plane->f
We unconditionally disable/update FBC even during the page flip
IOCTLs, and an unconditional disable/update at every atomic commit
touching the primary plane shouldn't impact PC state residency
noticeably. Besides, the code that checks for rotation is a good hint
that we may be forgetting something
With the addition and usage of intel_fbc_pre_update,
intel_fbc_deactivate is not used anymore outside intel_fbc.c, so kill
the exported function and rename __intel_fbc_deactivate.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_fbc.c | 28 -
We'll now call intel_fbc_pre_update instead of intel_fbc_deactivate
during atomic commits. This will continue to guarantee that we
deactivate FBC and it will also update the state checking structures
at the correct time. Then, later, at the point where we were calling
intel_fbc_update, we'll only n
We already have a dev variable, there's no need to access state->dev.
Also, I plan to add another dev_priv user here, so declare one for the
current user.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
Just to be sure nothing will survive a module unload. We need to do
this after the unlock in order to make sure the function won't get
stuck trying to grab the lock we already own while we wait for it to
finish.
Reported-by: Reported-by: Daniel Vetter
Signed-off-by: Paulo Zanoni
---
drivers/gpu
Instead of:
- intel_fbc_disable_crtc(crtc)
- intel_fbc_disable(dev_priv)
we now have:
- intel_fbc_disable(crtc)
- intel_fbc_global_disable(dev_priv)
This is because all the other functions that take a CRTC are called
- intel_fbc_something(crtc)
Instead of:
- intel_fbc_something_crtc(crtc)
A
During FBC invalidation, don't call intel_fbc_deactivate if it's not
enabled. This doesn't fix any bug, but helps making the interface
saner.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/
The FBC fixes we've been doing in the last months required a lot of
refactor, so functions that were once big and called from different
spots are now small and called only once. IMHO now it's better to just
move the contents of these functions to their only callers since this
reduces the number of
Make sure we do the pre_update - which also deactivates FBC - before
we actually schedule the page flip, just to make sure we don't
flip to the new FB with FBC still activated for the previous FB.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 inse
This opens the possibility of implementing nicer schemes to choose the
CRTC, such as checking the amount of stolen memory available, or
choosing the best pipe on platforms that don't die FBC to pipe or
plane A.
This code was written for another refactor that I ended up discarding,
so I don't actua
Per the new atomic locking rules, we need to cache the CRTC, plane and
FB state structures we use so we can access them later without needing
more locks. So do this.
Notice that there are some pieces of the FBC code that look at things
that are only computed during the modeset, so we can't just ca
Instead of duplicating the calls for every platform, let's just put
them in the correct places inside intel_atomic_commit. This will also
make it easier for us to move the enable call in order to support
fasbtoot.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 15 +++-
We already make sure we run intel_fbc_update_update during modesets
and page flips, and this function takes care of deactivating FBC, so
it shouldn't be possible for us to reach the condition we check at
intel_fbc_work_fn. So instead of grabbing framebuffer references and
adding a lot of code to tr
We don't actually use fb_id anywhere. We already compare all
parameters that matter to the hardware: pixel format, stride,
fence_reg and ggtt_offset. The ID shouldn't make a difference.
Besides, we already update the FBC data at every modeset/flip, so this
can't change behind our backs.
Signed-of
So now pre_update will be responsible for unconditionally deactivating
FBC and updating the state cache, while post_update will be
responsible for checking if it can be enabled, then enabling it.
This is one more step into proper locking.
Notice that intel_fbc_flush now calls post_update directly
Our dmesg messages started being misleading after we converted to the
enable+activate model: we always print "Disabling FBC", even when
we're just deactivating it. So, for example, when I boot my machine
and do "dmesg | grep -i fbc", I see:
[drm:intel_fbc_enable] Enabling FBC on pipe A
[drm:set
Older FBC platforms have this restriction where FBC can't be enabled
if multiple pipes are enabled. In the current code, we disable FBC
before the second pipe becomes visible.
One of the problems with this code is that the current
multiple_pipes_ok() implementation just iterates through all CRTCs
Before this patch, page flips would call intel_frontbuffer_flip() and
intel_frontbuffer_flip_complete(), which would call intel_fbc_flush(),
which would call intel_fbc_update(). The problem is that drawing
operations also trigger intel_fbc_flush() calls, so it's not
guaranteed that we have the CRTC
Move intel_fbc_enable to a place where it is called regardless of the
"modeset" variable, and make sure intel_fbc_enable can be called
multiple times without intel_fbc_disable being called.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 4 +++-
drivers/gpu/drm/i915/intel
Make our enable/activate checking model more explicit, especially
since we now have intel_fbc_can_activate().
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 46
1 file changed, 28 insertions(+), 18 deletions(-)
diff --git a/drivers/gp
This will force test the load_detect_test parameter in i915,
to make sure load detection works as intended.
Signed-off-by: Maarten Lankhorst
Acked-by: Daniel Vetter
---
diff --git a/tests/kms_force_connector_basic.c
b/tests/kms_force_connector_basic.c
index bd80caeffd82..f827d0008f7b 100644
---
On Tue, Jan 19, 2016 at 01:09:28PM +0100, Daniel Vetter wrote:
> On Thu, Jan 14, 2016 at 10:49:45AM +, Arun Siluvery wrote:
> > Pending reset requests are cleared before suspending, they should be picked
> > up
> > after resume when new work is submitted.
> >
> > This is originally added as p
== Summary ==
Built on 00a0c7d1ae09b1259c7af8e5a088b0b225d805df drm-intel-nightly:
2016y-01m-18d-16h-50m-37s UTC integration manifest
Test gem_ctx_basic:
pass -> FAIL (bdw-ultra)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS
On Thu, Jan 14, 2016 at 04:29:14PM +0200, Ville Syrjälä wrote:
> On Thu, Jan 14, 2016 at 02:20:40PM -, Patchwork wrote:
> > == Summary ==
> >
> > Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly:
> > 2016y-01m-14d-13h-06m-44s UTC integration manifest
> >
> > Test gem_basic
On Tue, Jan 19, 2016 at 03:18:25PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 19, 2016 at 09:03:13AM +0100, Daniel Vetter wrote:
> > On Mon, Jan 18, 2016 at 04:21:40PM +0200, Ville Syrjälä wrote:
> > > On Fri, Jan 15, 2016 at 03:15:00PM -0800, Matt Roper wrote:
> > > > On Fri, Jan 15, 2016 at 08:48:
On Tue, Jan 19, 2016 at 01:48:05PM +, Chris Wilson wrote:
> On Tue, Jan 19, 2016 at 01:09:28PM +0100, Daniel Vetter wrote:
> > On Thu, Jan 14, 2016 at 10:49:45AM +, Arun Siluvery wrote:
> > > Pending reset requests are cleared before suspending, they should be
> > > picked up
> > > after r
On Tue, Jan 19, 2016 at 02:58:14PM +0100, Daniel Vetter wrote:
> On Thu, Jan 14, 2016 at 04:29:14PM +0200, Ville Syrjälä wrote:
> > On Thu, Jan 14, 2016 at 02:20:40PM -, Patchwork wrote:
> > > == Summary ==
> > >
> > > Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly:
> > >
Hi Paulo,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20160119]
[cannot apply to v4.4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Paulo-Zanoni
On Tue, Jan 19, 2016 at 03:04:40PM +0100, Daniel Vetter wrote:
> On Tue, Jan 19, 2016 at 01:48:05PM +, Chris Wilson wrote:
> > On Tue, Jan 19, 2016 at 01:09:28PM +0100, Daniel Vetter wrote:
> > > On Thu, Jan 14, 2016 at 10:49:45AM +, Arun Siluvery wrote:
> > > > Pending reset requests are c
== Summary ==
Built on 20c388faff9d8c41ab27e825c685526561b892a2 drm-intel-nightly:
2016y-01m-19d-13h-31m-46s UTC integration manifest
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass -> DMESG-WARN (skl-i5k-2)
bdw-nuci7total:140 pass:131 dwarn:0 dfail
On Fri, Jan 15, 2016 at 02:46:45PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 15, 2016 at 11:06:42AM +0200, Marius Vlad wrote:
> > lib/igt_kms: Briefly describe Intel-to-DRM mapping between pipes, encoders
> > and
> > connectors.
> >
> > Signed-off-by: Marius Vlad
> > ---
> > lib/igt_kms.c | 82
On 19/01/2016 14:13, Chris Wilson wrote:
On Tue, Jan 19, 2016 at 03:04:40PM +0100, Daniel Vetter wrote:
On Tue, Jan 19, 2016 at 01:48:05PM +, Chris Wilson wrote:
On Tue, Jan 19, 2016 at 01:09:28PM +0100, Daniel Vetter wrote:
On Thu, Jan 14, 2016 at 10:49:45AM +, Arun Siluvery wrote:
P
INTEL_SOC_PMIC is loading later than I915 failing the gpiod_get and
pwm_get calls in i915. Add a retry to give time for the INTEL_SOC_PMIC
to load. This was fine till now but broke in latest kernel. Maybe load
time for the INTEL_SOC_PMIC has increased.
Since the lookup tables for GPIO (panel enabl
On Tue, Jan 19, 2016 at 05:04:33PM +0200, Marius Vlad wrote:
> On Fri, Jan 15, 2016 at 02:46:45PM +0200, Ville Syrjälä wrote:
> > On Fri, Jan 15, 2016 at 11:06:42AM +0200, Marius Vlad wrote:
> > > lib/igt_kms: Briefly describe Intel-to-DRM mapping between pipes,
> > > encoders and
> > > connectors
From: Tvrtko Ursulin
Having this on stack triggers the -Wframe-larger-than=1024 and
is not nice to put such big things on the kernel stack anyway.
This required a little bit of refactoring to handle the new
failure path from vlv_force_pll_on.
Signed-off-by: Tvrtko Ursulin
Cc: Daniel Vetter
Cc
On 01/19/2016 08:45 PM, Shobhit Kumar wrote:
INTEL_SOC_PMIC is loading later than I915 failing the gpiod_get and
pwm_get calls in i915. Add a retry to give time for the INTEL_SOC_PMIC
to load. This was fine till now but broke in latest kernel. Maybe load
time for the INTEL_SOC_PMIC has increased.
== Summary ==
Built on 20c388faff9d8c41ab27e825c685526561b892a2 drm-intel-nightly:
2016y-01m-19d-13h-31m-46s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS (skl-i5k-2) UNSTABLE
bdw-nuci7total:140 pass:131 dwarn:0
From: John Harrison
Note, this is a work in progress. It is being posted now as there is
work going on to change the debugging interface used by this test. So
it would be useful to get some comments on whether the proposed
changes will cause a problem for this test or whether the test itself
shou
On Wed, Jan 13, 2016 at 06:02:52PM +0200, Gabriel Feceoru wrote:
> Some Gen7/8 production parts may have the Display Pipe C fused off.
> In this case, the display hardware will prevent the Pipe C register bit
> from being set to 1.
Please elaborate on what pipe c register bit is prevented from bei
On Mon, Jan 18, 2016 at 06:01:27PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 18, 2016 at 03:11:57PM +0100, Patrik Jakobsson wrote:
> > On SKL and KBL we can have pipe A/B/C disabled by fuse settings. The
> > pipes must be fused in descending order (e.g. C, B+C, A+B+C). There are
> > several registe
From: Ville Syrjälä
In this atomic age, we can't trust the plane->fb pointer anymore.
It might get update too late. Instead we are supposed to use the
plane_state->fb pointer instead. Let's do that in
intel_plane_obj_offset() and avoid problems from dereferencing the
potentially stale plane->fb p
== Summary ==
Built on 20c388faff9d8c41ab27e825c685526561b892a2 drm-intel-nightly:
2016y-01m-19d-13h-31m-46s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (bdw-nuci7) UNSTABLE
Test kms_pipe_crc_basic:
Subgroup nonb
1 - 100 of 156 matches
Mail list logo
