== Summary ==
Built on 79686f613b3955a4ed09cee936e7f70ec4e61b67 drm-intel-nightly:
2015y-12m-30d-11h-59m-54s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS (skl-i5k-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
On Fri, 01 Jan 2016, "C. B." wrote:
> Hello All,
>
> Re: http://lists.freedesktop.org/archives/intel-gfx/2015-April/065313.html
>
>>Recently I noticed another device Dell Venue 8 Pro (BYT-CR) which
>>should be using LPSS backlight control. There is already a LPSS PWM
>>chip driver in upstream kern
Unlike the handle, the name table uses a sleeping mutex rather than a
spinlock. The allocation is in a normal context, and we can use the
simpler sleeping gfp_t, rather than have to take from the atomic
reserves.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_gem.c | 4 +---
1 file changed,
The current error path for failure when establishing a handle for a GEM
object is unbalance, e.g. we call object_close() without calling first
object_open(). Use the typical onion structure to only undo what has
been set up prior to the error.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_
We only need a single reference count for all handles (i.e. non-zero
obj->handle_count) and so can trim a few atomic operations by only
taking the reference on the first handle and dropping it after the last.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_gem.c | 17 -
1 fil
Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
it would be beneficial if the compiler threw an error rather than a
warning when it found a piece of suspect code. (I use this to
compile-check patch series and want to break on the first compiler error
in order to fix the pa
Hey,
Op 23-12-15 om 12:05 schreef 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 whe
On Mon, Jan 04, 2016 at 10:10:59AM +, Chris Wilson wrote:
> The current error path for failure when establishing a handle for a GEM
> object is unbalance, e.g. we call object_close() without calling first
> object_open(). Use the typical onion structure to only undo what has
> been set up prior
== Summary ==
Built on c1e9dc2dcb577438a6350c7f1cb36ba8ad0e1dfd drm-intel-nightly:
2016y-01m-04d-09h-35m-16s UTC integration manifest
Test gem_basic:
Subgroup create-close:
pass -> DMESG-WARN (skl-i7k-2)
Test gem_cpu_reloc:
Subgroup basic:
pa
== Summary ==
HEAD is now at c1e9dc2 drm-intel-nightly: 2016y-01m-04d-09h-35m-16s UTC
integration manifest
Applying: drm/i915: Force clean compilation with -Werror
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 drm/i915: For
On 14/12/15 15:11, Chris Wilson wrote:
On Mon, Dec 14, 2015 at 02:59:30PM +, Tvrtko Ursulin wrote:
Hi,
On 11/12/15 11:33, Chris Wilson wrote:
Now that we have split out the seqno-barrier from the
engine->get_seqno() callback itself, we can move the users of the
seqno-barrier to the requir
Don't use DP link training optimization if channel EQ is not ok. It has
been reported that in case of failure in channel EQ check the link training
optimization can be enabled and therefore may not be able to reuse the
previously computed drive current and pre-emphasis levels.
Bugzilla: https://bu
These three patches are fixes for DP link trainging failures and flickering
issues
reported by
Mika Kahola (3):
drm/i915: Disable fast link training if DP config changes
drm/i915: Check DP no aux transaction bit on link training
drm/i915: DP channel EQ check for use of DP link training opt
Disable DP link training optimization if DP link configuration
changes. If one of the DP link parameters i.e. link rate or
lane count changes the link training does no longer apply the
previously computed drive current and pre-emphasis level.
Instead, the link training is started with zero values.
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" link training.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915
On Mon, Jan 04, 2016 at 11:16:04AM +, Dave Gordon wrote:
> On 14/12/15 15:11, Chris Wilson wrote:
> >On Mon, Dec 14, 2015 at 02:59:30PM +, Tvrtko Ursulin wrote:
> >>
> >>Hi,
> >>
> >>On 11/12/15 11:33, Chris Wilson wrote:
> >>>Now that we have split out the seqno-barrier from the
> >>>engin
== Summary ==
Built on c1e9dc2dcb577438a6350c7f1cb36ba8ad0e1dfd drm-intel-nightly:
2016y-01m-04d-09h-35m-16s UTC integration manifest
Test kms_flip:
Subgroup basic-flip-vs-dpms:
dmesg-warn -> PASS (ilk-hp8440p)
Subgroup basic-flip-vs-modeset:
On 01/04/2016 03:12 PM, Jani Nikula wrote:
On Fri, 01 Jan 2016, "C. B." wrote:
Hello All,
Re: http://lists.freedesktop.org/archives/intel-gfx/2015-April/065313.html
Recently I noticed another device Dell Venue 8 Pro (BYT-CR) which
should be using LPSS backlight control. There is already a LP
The atomic helper sets connector_state->connector, which the i915
code didn't. This will become a problem when we start using it.
Signed-off-by: Maarten Lankhorst
Acked-by: Thierry Reding
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff
Changes since v1:
- Do not reset if state allocation fails.
Signed-off-by: Maarten Lankhorst
Acked-by: Thierry Reding #irc
---
drivers/gpu/drm/tegra/dsi.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
Now that connector_mask is reliable there's no need for this
function any more.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c| 30 --
drivers/gpu/drm/drm_atomic_helper.c | 10 --
drivers/gpu/drm/vc4/vc4_crtc.c | 2 +-
include/
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1e42309ec40a..b76778d76035 100644
--- a/drivers/gpu/drm/i915
It can be useful to iterate over connectors without grabbing
connection_mutex. It can also be used to see how many connectors
are on a crtc without iterating over the list.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c | 11 +++
include/drm/drm_crtc.h | 3 +++
This is useful for drivers that subclass connector_state, like tegra.
Changes since v1:
- Docbook updates.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 30 ++
include/drm/drm_atomic_helper.h | 2 ++
2 files changed, 28 insertions(+)
Op 04-01-16 om 12:21 schreef Mika Kahola:
> These three patches are fixes for DP link trainging failures and flickering
> issues
> reported by
Did your message get accidentally truncated here?
> Mika Kahola (3):
> drm/i915: Disable fast link training if DP config changes
> drm/i915: Check DP
On Mon, 2016-01-04 at 13:11 +0100, Maarten Lankhorst wrote:
> Op 04-01-16 om 12:21 schreef Mika Kahola:
> > These three patches are fixes for DP link trainging failures and flickering
> > issues
> > reported by
> Did your message get accidentally truncated here?
It seems. The story should continu
On 12/12/15 15:34, Chris Wilson wrote:
dma-buf provides a generic fence class for interoperation between
drivers. Internally we use the request structure as a fence, and so with
only a little bit of interfacing we can rebase those requests on top of
dma-buf fences. This will allow us, in the futu
On Mon, Jan 04, 2016 at 12:17:47PM +, Dave Gordon wrote:
> On 12/12/15 15:34, Chris Wilson wrote:
> >dma-buf provides a generic fence class for interoperation between
> >drivers. Internally we use the request structure as a fence, and so with
> >only a little bit of interfacing we can rebase th
== Summary ==
Built on c1e9dc2dcb577438a6350c7f1cb36ba8ad0e1dfd drm-intel-nightly:
2016y-01m-04d-09h-35m-16s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (skl-i5k-2)
Test kms_flip:
Subgroup basic-flip-vs-dpms:
Hi,
I'm still seeing these warning(s) with both this patch and
the one for i915_driver_unload()
(http://patchwork.freedesktop.org/patch/69227/),
in more than two cases:
$ tests/kms_flip --run-subtest basic-flip-vs-wf_vblank
[ 226.580012] [ cut
On 04/01/16 11:26, Chris Wilson wrote:
On Mon, Jan 04, 2016 at 11:16:04AM +, Dave Gordon wrote:
On 14/12/15 15:11, Chris Wilson wrote:
On Mon, Dec 14, 2015 at 02:59:30PM +, Tvrtko Ursulin wrote:
Hi,
On 11/12/15 11:33, Chris Wilson wrote:
Now that we have split out the seqno-barrier
On Mon, Jan 04, 2016 at 01:02:25PM +, Dave Gordon wrote:
> On 04/01/16 11:26, Chris Wilson wrote:
> >On Mon, Jan 04, 2016 at 11:16:04AM +, Dave Gordon wrote:
> >>On 14/12/15 15:11, Chris Wilson wrote:
> >>>On Mon, Dec 14, 2015 at 02:59:30PM +, Tvrtko Ursulin wrote:
>
> Hi,
> >>
On 12/23/2015 08:22 AM, Kumar, Shobhit wrote:
On 12/21/2015 05:39 PM, Daniel Vetter wrote:
On Fri, Dec 18, 2015 at 07:24:19AM -0800, Matt Roper wrote:
On Fri, Dec 18, 2015 at 07:14:17AM -0800, Matt Roper wrote:
On Fri, Dec 18, 2015 at 05:10:12PM +0200, Ville Syrjälä wrote:
On Fri, Dec 18, 201
On Wed, 30 Dec 2015, Insu Yun wrote:
> Since devm_kzalloc can be failed, it needs to be checked
> if not, NULL dereference could be happened.
>
> Signed-off-by: Insu Yun
Pushed to drm-intel-next-queued, thanks for the patch.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++
On 04/01/16 13:02, Dave Gordon wrote:
On 04/01/16 11:26, Chris Wilson wrote:
On Mon, Jan 04, 2016 at 11:16:04AM +, Dave Gordon wrote:
On 14/12/15 15:11, Chris Wilson wrote:
On Mon, Dec 14, 2015 at 02:59:30PM +, Tvrtko Ursulin wrote:
Hi,
On 11/12/15 11:33, Chris Wilson wrote:
Now th
Hey,
Op 31-12-15 om 16:52 schreef Gabriel Feceoru:
> This gets rid of errors like:
>
> [ 906.286213] [ cut here ]
> [ 906.286233] WARNING: CPU: 0 PID: 12252 at
> drivers/gpu/drm/i915/intel_drv.h:1457 gen6_read32+0x1ca/0x1e0 [i915]()
> [ 906.286234] RPM wakelock ref not
On Mon, Jan 04, 2016 at 02:09:53PM +, Dave Gordon wrote:
> On 04/01/16 13:02, Dave Gordon wrote:
> >On 04/01/16 11:26, Chris Wilson wrote:
> >>On Mon, Jan 04, 2016 at 11:16:04AM +, Dave Gordon wrote:
> >>>On 14/12/15 15:11, Chris Wilson wrote:
> On Mon, Dec 14, 2015 at 02:59:30PM +,
On Thu, Dec 31, 2015 at 05:52:07PM +0200, Gabriel Feceoru wrote:
> This gets rid of errors like:
>
> [ 906.286213] [ cut here ]
> [ 906.286233] WARNING: CPU: 0 PID: 12252 at
> drivers/gpu/drm/i915/intel_drv.h:1457 gen6_read32+0x1ca/0x1e0 [i915]()
> [ 906.286234] RPM wak
On Mon, Jan 04, 2016 at 10:10:59AM +, Chris Wilson wrote:
> The current error path for failure when establishing a handle for a GEM
> object is unbalance, e.g. we call object_close() without calling first
> object_open(). Use the typical onion structure to only undo what has
> been set up prior
On Mon, Jan 04, 2016 at 10:11:00AM +, Chris Wilson wrote:
> We only need a single reference count for all handles (i.e. non-zero
> obj->handle_count) and so can trim a few atomic operations by only
> taking the reference on the first handle and dropping it after the last.
>
> Signed-off-by: Ch
On Mon, Jan 04, 2016 at 10:11:01AM +, Chris Wilson wrote:
> Unlike the handle, the name table uses a sleeping mutex rather than a
> spinlock. The allocation is in a normal context, and we can use the
> simpler sleeping gfp_t, rather than have to take from the atomic
> reserves.
>
> Signed-off-
On Mon, Jan 04, 2016 at 10:18:50AM +, Chris Wilson wrote:
> On Mon, Jan 04, 2016 at 10:10:59AM +, Chris Wilson wrote:
> > The current error path for failure when establishing a handle for a GEM
> > object is unbalance, e.g. we call object_close() without calling first
> > object_open(). Use
On Mon, Jan 04, 2016 at 05:24:11PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 04, 2016 at 10:10:59AM +, Chris Wilson wrote:
> > The current error path for failure when establishing a handle for a GEM
> > object is unbalance, e.g. we call object_close() without calling first
> > object_open(). Us
On Mon, Jan 04, 2016 at 05:33:45PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 04, 2016 at 10:18:50AM +, Chris Wilson wrote:
> > On Mon, Jan 04, 2016 at 10:10:59AM +, Chris Wilson wrote:
> > > The current error path for failure when establishing a handle for a GEM
> > > object is unbalance, e
On 29/12/15 19:18, Chris Wilson wrote:
On Tue, Dec 29, 2015 at 06:59:57PM +, Dave Gordon wrote:
In the discussions around commit 373701b1 (Jani Nikula)
drm: fix potential dangling else problems in for_each_ macros
Daniel Vetter mooted the idea of a for_each_engine(ring, dev_priv)
macro
On 16/12/15 10:19, Chris Wilson wrote:
On Wed, Dec 16, 2015 at 10:44:19AM +0100, Daniel Vetter wrote:
On Fri, Dec 11, 2015 at 11:33:03AM +, Chris Wilson wrote:
As the request is only valid during the same global reset epoch, we can
record the current reset_counter when constructing the requ
On Mon, Dec 21, 2015 at 10:42:53AM +, Thomas Wood wrote:
> On 18 December 2015 at 17:25, wrote:
> > From: Ville Syrjälä
> >
> > The test tries to anger CHV pipe C cursor by walking the edges of the
> > screen while moving the cursor across the screen edge.
> >
> > The actual hw issue only oc
On Wed, Dec 23, 2015 at 02:50:47PM +0800, libin.y...@linux.intel.com wrote:
> From: Libin Yang
>
> hsw platforms supports DP MST while ilk doesn't.
> This patch fixes the bug.
>
> Signed-off-by: Libin Yang
> ---
> drivers/gpu/drm/i915/intel_audio.c | 16 +---
> 1 file changed, 9 in
On Mon, Jan 04, 2016 at 03:58:21PM +, Dave Gordon wrote:
> On 16/12/15 10:19, Chris Wilson wrote:
> >On Wed, Dec 16, 2015 at 10:44:19AM +0100, Daniel Vetter wrote:
> >>On Fri, Dec 11, 2015 at 11:33:03AM +, Chris Wilson wrote:
> >>>@@ -1288,7 +1286,7 @@ int __i915_wait_request(struct drm_i91
On Mon, Dec 21, 2015 at 10:42:46AM +, Thomas Wood wrote:
> On 18 December 2015 at 17:25, wrote:
> > From: Ville Syrjälä
> >
> > Several tests do one or more of the followin:
> > * igt_create_fb() + igt_paint_test_pattern()
> > * igt_create_color_fb() + igt_paint_test_pattern()
> > * igt_crea
On Mon, Jan 04, 2016 at 01:21:22PM +0200, Mika Kahola wrote:
> Disable DP link training optimization if DP link configuration
> changes. If one of the DP link parameters i.e. link rate or
> lane count changes the link training does no longer apply the
> previously computed drive current and pre-emp
On Mon, Jan 04, 2016 at 01:21:24PM +0200, Mika Kahola wrote:
> Don't use DP link training optimization if channel EQ is not ok. It has
> been reported that in case of failure in channel EQ check the link training
> optimization can be enabled and therefore may not be able to reuse the
> previously
On Mon, Dec 21, 2015 at 04:53:34PM +0100, Daniel Vetter wrote:
> On Fri, Dec 18, 2015 at 07:25:48PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Add support for reading the CRC in non-blocking mode. Useful for tests
> > that want to start the CRC capture, then do a
On Mon, Jan 04, 2016 at 06:44:09PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 04, 2016 at 01:21:24PM +0200, Mika Kahola wrote:
> > Don't use DP link training optimization if channel EQ is not ok. It has
> > been reported that in case of failure in channel EQ check the link training
> > optimization
On Mon, Jan 04, 2016 at 11:16:39AM +0100, Maarten Lankhorst wrote:
> Hey,
>
> Op 23-12-15 om 12:05 schreef 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 prope
On 12/17/2015 09:43 AM, Jesse Barnes wrote:
> On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote:
>> From: John Harrison
>>
>> There is a construct in the linux kernel called 'struct fence' that is
>> intended to keep track of work that is executed on hardware. I.e. it
>> solves the basic pro
On Tue, Dec 22, 2015 at 04:53:41PM +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
On 04/01/16 14:20, Chris Wilson wrote:
On Mon, Jan 04, 2016 at 02:09:53PM +, Dave Gordon wrote:
On 04/01/16 13:02, Dave Gordon wrote:
On 04/01/16 11:26, Chris Wilson wrote:
On Mon, Jan 04, 2016 at 11:16:04AM +, Dave Gordon wrote:
On 14/12/15 15:11, Chris Wilson wrote:
On Mon, Dec 14,
On 23/12/15 21:02, Chris Wilson wrote:
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 con
On 04/01/16 16:10, Chris Wilson wrote:
On Mon, Jan 04, 2016 at 03:58:21PM +, Dave Gordon wrote:
On 16/12/15 10:19, Chris Wilson wrote:
On Wed, Dec 16, 2015 at 10:44:19AM +0100, Daniel Vetter wrote:
On Fri, Dec 11, 2015 at 11:33:03AM +, Chris Wilson wrote:
@@ -1288,7 +1286,7 @@ int __i
On 11/12/15 11:33, Chris Wilson wrote:
By using the same address for storing the HWS on every platform, we can
remove the platform specific vfuncs and reduce the get-seqno routine to
a single read of a cached memory location.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c
On Wed, Dec 30, 2015 at 09:48:43AM +1000, Dave Airlie wrote:
> On 11 Dec 2015 7:09 PM, "Durgadoss R" wrote:
> >
> > To support USB type C alternate DP mode, the display driver needs to
> > know the number of lanes required by the DP panel as well as number
> > of lanes that can be supported by the
On 18/12/15 20:00, yu@intel.com wrote:
From: Alex Dai
The GuC firmware uses this for various purposes. The ADS itself is a chunk of
memory created by driver to share with GuC. This series creates the GuC ADS
object and setup some basic settings for it.
This version addresses some comments
On Mon, Jan 04, 2016 at 06:11:56PM +, Dave Gordon wrote:
> So previously, we wrote the seqno and other dummy data into the
> SCRATCH page, whereas now it's going to the HWSP. Does that make the
> scratch page redundant? Or are there other bits of code that write
> other stuff into it?
The scra
On Mon, Jan 04, 2016 at 05:43:10PM +, Dave Gordon wrote:
> On 23/12/15 21:02, Chris Wilson wrote:
> >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, us
Hi!
> > I then ran a git bissect between v4.0 and v4.1 from Linus's tree and
> > found the "guilty" commit was
> >
> > commit 317b4e903636305cfe702ab3e5b3d68547a69e72
> > Author: Ben Widawsky
> > Date: Mon Mar 16 16:00:55 2015 +
> >
> > drm/i915: Extract context switch skip and add pd l
On Mon, Jan 04, 2016 at 09:12:11PM +0100, Pavel Machek wrote:
> Hi!
>
> > > I then ran a git bissect between v4.0 and v4.1 from Linus's tree and
> > > found the "guilty" commit was
> > >
> > > commit 317b4e903636305cfe702ab3e5b3d68547a69e72
> > > Author: Ben Widawsky
> > > Date: Mon Mar 16 16:0
On Mon, Jan 04, 2016 at 09:20:44AM -0800, Jesse Barnes wrote:
> So this one has my ack.
This series makes a number of fundamental mistakes in seqno-interrupt
handling, so no.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mai
On 01/04/2016 12:57 PM, Chris Wilson wrote:
> On Mon, Jan 04, 2016 at 09:20:44AM -0800, Jesse Barnes wrote:
>> So this one has my ack.
>
> This series makes a number of fundamental mistakes in seqno-interrupt
> handling, so no.
Well unless you can enumerate the issues in enough detail for us to a
On 12/11/2015 03:33 AM, Chris Wilson wrote:
> + * Note that this effectively effectively stalls the read by the time
> + * it takes to do a memory transaction, which more or less ensures
> + * that the write from the GPU has sufficient time to invalidate
> + * the CPU cacheline.
On 01/04/2016 11:39 AM, Chris Wilson wrote:
> On Mon, Jan 04, 2016 at 05:43:10PM +, Dave Gordon wrote:
>> On 23/12/15 21:02, Chris Wilson wrote:
>>> 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 c
Without watermark the power consumption will blow up, but
when enabling platforms and dealing with different kinds of
crashes, screen corruptions, pipe underuns, etc we need to be
able to easily disable watermark to see if we are on the right
investigation track.
Another possibility was to skip at
No functional changes with this patch. The idea is just to organize
the platform features in a standard place making new platform aditions
easily and possible to see all the present features of the platform on
the intel info dumped information at dmesg.
Signed-off-by: Rodrigo Vivi
---
drivers/gp
No functional changes with this patch. The idea is just to organize
the platform features in a standard place making new platform aditions
easily and possible to see all the present features of the platform on
the intel info dumped information at dmesg.
(I just wonder why Ivy Bridge doesn't have r
No functional changes with this patch. The idea is just to organize
the platform features in a standard place making new platform aditions
easily and possible to see all the present features of the platform on
the intel info dumped information at dmesg.
Also for this one it is better to put the on
Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12) if
this time is already spent in suspend/poweron time.
v2: Use CLOCK_BOOTTIME and remove jiffies for panel power cycle
delay calculation(Ville).
Cc: Ville Syrjälä
Signed-off-by: Abhay Kumar
---
drivers/gpu/drm/i915/i
This patch fix some spelling typos found in Documentation/Docbook
gpu/ch04s03.html. This file was generated from comments within
source, so I have to fix typos in i915_gem_fence.c.
Signed-off-by: Masanari Iida
---
drivers/gpu/drm/i915/i915_gem_fence.c | 10 +-
1 file changed, 5 insertio
Hi,
>> Can you verify that reverting this patch (on top of 4.4?) fixes it?
>>
>> If so, is it time to revert it?
>>
>> Thanks,
>> Pavel
>
> It's highly unlikely you'll be able to revert this on top of 4.4.
> Unfortunately,
> th
== Summary ==
Built on 0417da5e6f56078d87d366d5f959f8290ae9d16d drm-intel-nightly:
2016y-01m-04d-14h-05m-39s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS (skl-i5k-2)
pass -> DMESG-WARN (skl-i7k-2)
Te
== Summary ==
Built on 0417da5e6f56078d87d366d5f959f8290ae9d16d drm-intel-nightly:
2016y-01m-04d-14h-05m-39s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
dmesg-warn -> PASS (skl-i5k-2)
pass -> DMESG-WARN (skl-i7k-2)
Te
80 matches
Mail list logo
