== 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-
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:
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/
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 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 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 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
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
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
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/
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
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
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_
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 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/
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
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 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 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 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 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 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 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
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 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
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
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
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
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 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
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 ]---
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
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
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
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
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
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
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 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
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 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:
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 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 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 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/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
== 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 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 ==
> > > >
> > > >
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
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 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
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
== 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
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
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
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
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
== 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
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.
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 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
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 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
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
== 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 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
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 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:
> > >
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 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 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
== 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 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
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
---
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
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
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
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
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 +++-
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
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
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
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
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
1 - 100 of 156 matches
Mail list logo
