On ti, 2016-01-19 at 13:49 +, Patchwork wrote:
> == Summary ==
>
> Built on 00a0c7d1ae09b1259c7af8e5a088b0b225d805df drm-intel-nightly:
> 2016y-01m-18d-16h-50m-37s UTC integration manifest
>
> Test gem_ctx_basic:
> pass -> FAIL (bdw-ultra)
Couldn't reproduce it on
On 19/01/16 16:23, ville.syrj...@linux.intel.com wrote:
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 pr
Hi Rafael,
On Tue, Jan 19, 2016 at 12:59:13AM +0100, Rafael J. Wysocki wrote:
> On Tuesday, January 19, 2016 12:00:47 AM Lukas Wunner wrote:
> > Hi,
> >
> > On Mon, Jan 18, 2016 at 11:46:18PM +0100, Rafael J. Wysocki wrote:
> > > On Monday, January 18, 2016 11:39:07 PM Lukas Wunner wrote:
>
> [c
On Tue, Jan 19, 2016 at 03:04:09PM +, Arun Siluvery wrote:
> 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
On Tue, Jan 19, 2016 at 04:09:48PM +0200, Ville Syrjälä wrote:
> 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 ==
> > > >
> > > >
== 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
Test gem_sync:
Subgroup basic-render:
On 19/01/2016 16:42, Daniel Vetter wrote:
On Tue, Jan 19, 2016 at 03:04:09PM +, Arun Siluvery wrote:
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 a
On Tue, Jan 19, 2016 at 04:30:48PM +, Tvrtko Ursulin wrote:
>
> On 19/01/16 16:23, ville.syrj...@linux.intel.com wrote:
> > 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
> > pl
On 19/01/16 10:24, Tvrtko Ursulin wrote:
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_
On Tue, Jan 19, 2016 at 05:01:00PM +, Arun Siluvery wrote:
> On 19/01/2016 16:42, Daniel Vetter wrote:
> >On Tue, Jan 19, 2016 at 03:04:09PM +, Arun Siluvery wrote:
> >>On 19/01/2016 14:13, Chris Wilson wrote:
> >>>On Tue, Jan 19, 2016 at 03:04:40PM +0100, Daniel Vetter wrote:
> On Tue,
On Fri, Jan 15, 2016 at 11:51:31AM +0200, Jani Nikula wrote:
> On Thu, 14 Jan 2016, Ville Syrjälä wrote:
> > On Thu, Jan 14, 2016 at 05:12:07PM +0200, Jani Nikula wrote:
> >> Two errors in a single line. The size was read from the wrong offset,
> >> and the end index didn't take the five bytes for
On 19/01/16 17:18, Tvrtko Ursulin wrote:
On 19/01/16 10:24, Tvrtko Ursulin wrote:
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:
Em Qua, 2016-01-13 às 14:05 -0800, Rodrigo Vivi escreveu:
> 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,
On 18/01/2016 16:20, Patchwork wrote:
== Summary ==
Built on 98ee62c2326e0b6881eb0f427895aab745febf6f drm-intel-nightly:
2016y-01m-18d-14h-18m-27s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (skl-i5k-2) UNSTABLE
On Tue, 19 Jan 2016, Daniel Vetter wrote:
> On Fri, Jan 15, 2016 at 11:51:31AM +0200, Jani Nikula wrote:
>> On Thu, 14 Jan 2016, Ville Syrjälä wrote:
>> > On Thu, Jan 14, 2016 at 05:12:07PM +0200, Jani Nikula wrote:
>> >> Two errors in a single line. The size was read from the wrong offset,
>> >>
On Tue, Jan 19, 2016 at 07:55:58PM +0200, Jani Nikula wrote:
> On Tue, 19 Jan 2016, Daniel Vetter wrote:
> > On Fri, Jan 15, 2016 at 11:51:31AM +0200, Jani Nikula wrote:
> >> On Thu, 14 Jan 2016, Ville Syrjälä wrote:
> >> > On Thu, Jan 14, 2016 at 05:12:07PM +0200, Jani Nikula wrote:
> >> >> Two
Thanks for capture the typo. LGTM.
Reviewed-by: Alex Dai
On 01/18/2016 07:59 AM, Arun Siluvery wrote:
In GuC submission mode, driver has to provide a list of registers to be
save/restored during gpu reset, make the max no. of registers value consistent
with that of the value defined in FW. If
I am OK with change here. However, in i915_drv.h, please check
definition of HAS_GUC_UCODE() and HAS_GUC_SCHED(). I believe they are
disabled for KBL.
Thanks,
Alex
On 01/18/2016 06:41 AM, Peter Antoine wrote:
This patch added the loading of the GuC for Kabylake.
It loads a 2.4 firmware.
Sign
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
During startup, the driver creates a unique "intel_context" that will
provide a home for orphan requests (i.e. those generated by the driver
internally, not associated with user batchbuffers).
However, one of the infelicities of the current code is that the driver
keeps a per-engine pointer to the
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 single reference to it in the dev_priv structure rather than one
in each of the engine[] elements. This make refcountin
There are a few bits of code which the transformations implemented by
the previous patch reveal to be suboptimal, once the notion of a per-
ring default context has gone away. So this tidies up the leftovers.
It could have been squashed into the previous patch, but that would have
made that patch
Maarten Lankhorst writes:
> Op 14-01-16 om 17:52 schreef Ville Syrjälä:
>> On Thu, Jan 14, 2016 at 06:32:10PM +0200, Mika Kuoppala wrote:
>>> CI/Bat got following (shortened) trace on byt and also
>>> on bsw:
>>>
>>> [ cut here ]---
>>> Unclaimed register detected before readi
On Mon, Jan 18, 2016 at 11:23:21AM +0100, Maarten Lankhorst wrote:
> Op 14-01-16 om 17:52 schreef Ville Syrjälä:
> > On Thu, Jan 14, 2016 at 06:32:10PM +0200, Mika Kuoppala wrote:
> >> CI/Bat got following (shortened) trace on byt and also
> >> on bsw:
> >>
> >> [ cut here ]---
On Tue, Jan 19, 2016 at 10:13:43AM -0800, Yu Dai wrote:
> Thanks for capture the typo. LGTM.
>
> Reviewed-by: Alex Dai
>
> On 01/18/2016 07:59 AM, Arun Siluvery wrote:
> >In GuC submission mode, driver has to provide a list of registers to be
> >save/restored during gpu reset, make the max no. o
This reverts commit 396e33ae204f52abebec9e578f44c749305500f4.
This commit was triggering some FIFO underrun warnings on ILK-IVB
platforms (but surprisingly not on HSW/BDW that share more or less the
same codepaths). These underruns were caught by the continuous
integration (CI) system and could b
On Tue, Jan 19, 2016 at 05:18:09PM +0200, Ville Syrjälä wrote:
> 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 I
Sometimes we get dmesg warnings claiming that DC6 was already
enabled prior to our enabling. Investigations using readback of
the written dc state value indicate that sometimes when we disable
the dc6, the write doesn't stick, or it does but for a very short time.
This leads to state keeping confu
Hi,
There is not known root cause to why we end up in a situation
where the dmc doesn't anymore obey us on dc state setup.
https://bugs.freedesktop.org/show_bug.cgi?id=93698
https://bugs.freedesktop.org/show_bug.cgi?id=93697
But here are few patches to alleviate the consequences
if that happens.
If we have driver failure in our power well and/or dc
state keeping, we might try to reset without powers.
Evidence shows that resetting the chip with dc6 enabled
don't lead to desired results. The dmc kept it's enabled
dc6 state over the reset. On subsequent init the rings
just hanged right from
On Fri, Jan 15, 2016 at 11:57:49AM +, Chris Wilson wrote:
> Since the removal of UMS, we have always had sole ownership of the GTTs.
> We no longer have to track the subsection we are allowed to use (denoted
> by start + total). vGPU does restrict the range of the global GTT we can
> use (as it
We've had this since forever, and's randomly reporting issues and as
such causing piles&piles of CI noise. Mika is working on proper debug
infrastructure for this, and on fixing this properly.
Meanwhile make CI more useful for everyone else.
Cc: Mika Kuoppala
Bugzilla: https://bugs.freedesktop.o
On Tue, Jan 19, 2016 at 09:50:09PM +0200, Mika Kuoppala wrote:
> If we have driver failure in our power well and/or dc
> state keeping, we might try to reset without powers.
>
> Evidence shows that resetting the chip with dc6 enabled
> don't lead to desired results. The dmc kept it's enabled
> dc6
On Mon, Jan 18, 2016 at 09:19:48AM +0200, Jani Nikula wrote:
> Without the DOC:, kernel-doc confuses the documentation block for
> something else.
>
> Signed-off-by: Jani Nikula
Hm, we don't pull intel_pm.c into the gpu.tmpl at all, which means
kernel-CI won't test this for us. Care to throw a g
On Mon, Jan 18, 2016 at 07:49:49AM -, Patchwork wrote:
> == Summary ==
>
> Built on 9fe57aed43d1c3c9af66aae16ec511dd0357e13b drm-intel-nightly:
> 2016y-01m-18d-06h-56m-50s UTC integration manifest
>
> Test gem_storedw_loop:
> Subgroup basic-render:
> dmesg-warn -> PAS
On Mon, Jan 18, 2016 at 05:08:42PM +0100, Patrik Jakobsson wrote:
> For unknown reasons the DMC firmware overwrites our DC5/6 bits in
> the DC_STATE_EN register. This happens from time to time during the
> igt@kms_flip@basic-flip-vs-dpms test. We manually fix up the register
> when this occurs and
On Tue, Jan 19, 2016 at 09:00:40PM +0530, Kumar, Shobhit wrote:
> 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 brok
On Tue, Jan 19, 2016 at 03:25:17PM +, Tvrtko Ursulin wrote:
> 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 pat
On Tue, Jan 19, 2016 at 06:23:17PM +0200, ville.syrj...@linux.intel.com wrote:
> 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
On Tue, Jan 19, 2016 at 04:49:56PM -, Patchwork wrote:
> == 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 -> PAS
This patch added the loading of the GuC for Kabylake.
It loads a 2.4 firmware.
Signed-off-by: Peter Antoine
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_guc_loader.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/
This patchset reverts the disabling of the GuC loading for Kabylake
and then adds then specifically enables Kabylake GuC loading and
specifies the Kabylake firmware filename.
Peter Antoine (2):
Revert "FROM_UPSTREAM [VPG]: drm/i915/kbl: drm/i915: Avoid GuC loading
for now on Kabylake."
i91
This reverts commit a92d3f32eafc57cca55e654ecfd916f283100365.
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index af30148..f99a988 100644
--- a/drivers/gpu/drm/i915/i915_
Yup, I missed a patch.
Just sent a new sequence.
Peter.
-Original Message-
From: Dai, Yu
Sent: Tuesday, January 19, 2016 6:18 PM
To: Antoine, Peter; intel-gfx@lists.freedesktop.org
Cc: daniel.vet...@ffwll.ch; Gordon, Dave; Thierry, Michel
Subject: Re: [PATCH] i915/guc: Add Kabylake GuC L
On Tue, Jan 19, 2016 at 09:18:50PM +, Peter Antoine wrote:
> This reverts commit a92d3f32eafc57cca55e654ecfd916f283100365.
Shouldnt' this be patch 2/2? Enabling guc loading before it's fixed isn't
awesome.
Either way needs a proper commit message (why is it ok to enable now?)
plus s-o-b.
-Dan
This patch added the loading of the GuC for Kabylake.
It loads a 2.4 firmware.
Signed-off-by: Peter Antoine
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_guc_loader.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/
Enabling Kabylake GuC loading as fw now available.
This reverts commit a92d3f32eafc57cca55e654ecfd916f283100365.
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index af30
This patchset reverts the disabling of the GuC loading for Kabylake
and then adds then specifically enables Kabylake GuC loading and
specifies the Kabylake firmware filename.
v2: Change order of the patchset. (D.Vetter)
Peter Antoine (2):
i915/guc: Add Kabylake GuC Loading
Revert "FROM_UPSTRE
Please look at v2, had to change the order of the patches.
-Original Message-
From: Antoine, Peter
Sent: Tuesday, January 19, 2016 9:20 PM
To: Dai, Yu; intel-gfx@lists.freedesktop.org
Cc: daniel.vet...@ffwll.ch; Gordon, Dave; Thierry, Michel
Subject: RE: [PATCH] i915/guc: Add Kabylake GuC
On Tuesday, January 19, 2016 05:31:04 PM Lukas Wunner wrote:
> Hi Rafael,
>
> On Tue, Jan 19, 2016 at 12:59:13AM +0100, Rafael J. Wysocki wrote:
> > On Tuesday, January 19, 2016 12:00:47 AM Lukas Wunner wrote:
> > > Hi,
> > >
> > > On Mon, Jan 18, 2016 at 11:46:18PM +0100, Rafael J. Wysocki wrote
On Tue, 2016-01-19 at 17:46 +, Zanoni, Paulo R wrote:
> Em Qua, 2016-01-13 às 14:05 -0800, Rodrigo Vivi escreveu:
> > 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 p
On 1/12/2016 5:57 PM, Kumar, Abhay wrote:
From: Abhay Kumar
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).
v3: Addr
On 01/19/2016 01:25 PM, Daniel Vetter wrote:
On Tue, Jan 19, 2016 at 09:18:50PM +, Peter Antoine wrote:
> This reverts commit a92d3f32eafc57cca55e654ecfd916f283100365.
Shouldnt' this be patch 2/2? Enabling guc loading before it's fixed isn't
awesome.
Either way needs a proper commit messa
On 01/08/2016 07:03 AM, Peter Antoine wrote:
This patch resizes the GuC WOPCM to so that the GuC and the RC6 memory
spaces do not overlap.
Issue: https://jira01.devtools.intel.com/browse/VIZ-6638
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915/i915_guc_reg.h | 3 ++-
drivers/gpu/
Op 19-01-16 om 20:22 schreef Ville Syrjälä:
> On Mon, Jan 18, 2016 at 11:23:21AM +0100, Maarten Lankhorst wrote:
>> Op 14-01-16 om 17:52 schreef Ville Syrjälä:
>>> On Thu, Jan 14, 2016 at 06:32:10PM +0200, Mika Kuoppala wrote:
CI/Bat got following (shortened) trace on byt and also
on bsw:
== Summary ==
Built on 7d26528d30b0d8119c858115b6e5e22deb74ec71 drm-intel-nightly:
2016y-01m-19d-19h-38m-52s UTC integration manifest
Test gem_storedw_loop:
Subgroup basic-render:
pass -> DMESG-WARN (bdw-nuci7) UNSTABLE
Test kms_flip:
Subgroup basic-flip-vs-
101 - 156 of 156 matches
Mail list logo
