Commit 2804afc606f8 ("kms_frontbuffer_tracking: fix compression
checking") removes the check whether the kernel supports reporting the
compression status before asserting on it. This breaks the test for no
good reason on old CPUs (SNB and earlier) where the kernel can't report
the compression
Daniel Vetter writes:
> freedesktop.org has adopted a formal code of conduct:
>
> https://www.fooishbar.org/blog/fdo-contributor-covenant/
> https://www.freedesktop.org/wiki/CodeOfConduct/
>
> Besides formalizing things a bit more I don't think this changes
> anything for
On 13/04/17 17:16, Daniele Ceraolo Spurio wrote:
On 24/03/17 18:30, Michel Thierry wrote:
From: Arun Siluvery
GuC expects a list of registers from the driver which are saved/restored
during engine reset. The type of value to be saved is controlled by
flags.
On 24/03/17 18:30, Michel Thierry wrote:
From: Arun Siluvery
GuC expects a list of registers from the driver which are saved/restored
during engine reset. The type of value to be saved is controlled by
flags. We provide a minimal set of registers that we want
On Fri, 2017-04-07 at 17:48 +0300, Ville Syrjälä wrote:
> On Thu, Apr 06, 2017 at 12:15:02PM -0700, Rodrigo Vivi wrote:
> > As for BXT, PP_DIVISOR was removed from CNP PCH and power
> > cycle delay has been moved to PP_CONTROL.
> >
> > Cc: Jani Nikula
> > Signed-off-by:
On Thu, Apr 13, 2017 at 05:25:56PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Move the BUILD_BUG_ONs for busy-wait duration outside the
> _wait_for_atomic macro as discussed on the mailing list.
>
> Signed-off-by: Tvrtko Ursulin
On Thu, Apr 13, 2017 at 09:02:15PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: checking for NULL instead of IS_ERR() in mock selftests
> URL : https://patchwork.freedesktop.org/series/23040/
> State : success
>
> == Summary ==
>
> Series 23040v1 drm/i915: checking for
True. I'll resend.
regards,
dan carpenter
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, Apr 13, 2017 at 02:14:17PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Check that no-op execution speed is the same in headless mode
> and with the display active.
>
> Signed-off-by: Tvrtko Ursulin
> Bugzilla:
== Series Details ==
Series: drm/i915: checking for NULL instead of IS_ERR() in mock selftests
URL : https://patchwork.freedesktop.org/series/23040/
State : success
== Summary ==
Series 23040v1 drm/i915: checking for NULL instead of IS_ERR() in mock selftests
== Series Details ==
Series: drm/i915: uninitialized value on error path
URL : https://patchwork.freedesktop.org/series/23038/
State : success
== Summary ==
Series 23038v1 drm/i915: uninitialized value on error path
https://patchwork.freedesktop.org/api/1.0/series/23038/revisions/1/mbox/
On Thu, Apr 13, 2017 at 10:53:11PM +0300, Dan Carpenter wrote:
> "ret" isn't initialized on this error path. It doesn't really cause
> any problems unless it's randomly set to -EDEADLK which is not likely.
>
> Signed-off-by: Dan Carpenter
>
> diff --git
On Thu, Apr 13, 2017 at 10:52:17PM +0300, Dan Carpenter wrote:
> i915_gem_request_alloc() uses error pointers. It never returns NULLs.
>
> Fixes: 0daf0113cff6 ("drm/i915: Mock infrastructure for request emission")
> Signed-off-by: Dan Carpenter
Reviewed-by: Chris
== Series Details ==
Series: drm/i915/gvt: fix a bounds check in ring_id_to_context_switch_event()
URL : https://patchwork.freedesktop.org/series/23036/
State : success
== Summary ==
Series 23036v1 drm/i915/gvt: fix a bounds check in
ring_id_to_context_switch_event()
On Thu, Apr 13, 2017 at 04:03:16PM -0400, Alex Deucher wrote:
> On Mon, Apr 3, 2017 at 4:32 AM, Daniel Vetter wrote:
> > Properties, i.e. the struct drm_property specifying the type and value
> > range of a property, not the instantiation on a given object, are
> >
On Mon, Apr 3, 2017 at 4:32 AM, Daniel Vetter wrote:
> Properties, i.e. the struct drm_property specifying the type and value
> range of a property, not the instantiation on a given object, are
> invariant over the lifetime of a driver.
>
> Hence no locking at all is
i915_gem_request_alloc() uses error pointers. It never returns NULLs.
Fixes: 0daf0113cff6 ("drm/i915: Mock infrastructure for request emission")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/selftests/mock_request.c
"ret" isn't initialized on this error path. It doesn't really cause
any problems unless it's randomly set to -EDEADLK which is not likely.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
There are two bugs here. The && should be || and the > is off by one so
it should be >= ARRAY_SIZE().
Fixes: 8453d674ae7e ("drm/i915/gvt: vGPU execlist virtualization")
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/i915/gvt/execlist.c
I have this Acer Aspire One ZG5 with 1 GB of RAM running 32-bit Fedora 25 with the latest updates (as of 2017/04/12) with kernel-PAE-core-4.10.8-200.fc25.i686 . This laptop has the integrated flat panel display plus a VGA output (normally unused).
According to lspci, the graphics chipsets are:
On Thu, 13 Apr 2017, Manasi Navare wrote:
> Hi Jani,
>
> This patch has the necessary ACKs and R-bs, anything else
> blocking this from getting merged?
Pushed, finally, sorry for the delay.
BR,
Jani.
>
> Regards
> Manasi
>
> On Thu, Apr 06, 2017 at 04:44:19PM +0300,
On Thu, 13 Apr 2017, kbuild test robot wrote:
> tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
> head: f1faf571d9530365a34fe33a3efa3fb224661692
> commit: 15b670ebb1bb7309b60c23b3fa1479d31cd79122 [1/7] Merge remote-tracking
> branch
I have a tiny suggestion down there. Regardless this is :
Reviewed-by: Lionel Landwerlin
On 12/04/17 08:20, Daniel Vetter wrote:
Motivated by a request from Eric.
Cc: Eric Anholt
Cc: Lionel Landwerlin
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Rodrigo Vivi
>Sent: Thursday, April 6, 2017 12:15 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Vivi, Rodrigo
>Subject: [Intel-gfx] [PATCH 01/67] drm/i915/cnp:
Hi Jani,
This patch has the necessary ACKs and R-bs, anything else
blocking this from getting merged?
Regards
Manasi
On Thu, Apr 06, 2017 at 04:44:19PM +0300, Jani Nikula wrote:
> From: Manasi Navare
>
> If link training at a link rate optimal for a particular
>
== Series Details ==
Series: drm/i915: Fix GCC 4.4 build issue with __intel_wait_for_register_fw
URL : https://patchwork.freedesktop.org/series/23020/
State : success
== Summary ==
Series 23020v1 drm/i915: Fix GCC 4.4 build issue with
__intel_wait_for_register_fw
From: Tvrtko Ursulin
Move the BUILD_BUG_ONs for busy-wait duration outside the
_wait_for_atomic macro as discussed on the mailing list.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Michal Wajdeczko
Fixes:
From: Ville Syrjälä
Implement the CNL display init/uninit sequence as outlined in Bspec.
Quite similar to SKL/BXT. The main complicaiton is probably the extra
procmon setup we must do based on the process/voltage information we
can read out from some register.
On Thu, 2017-04-13 at 17:44 +0300, Imre Deak wrote:
> On Thu, Apr 06, 2017 at 12:15:23PM -0700, Rodrigo Vivi wrote:
> > The workaround added in
> > commit c6782b76d31a ("drm/i915/gen9: Reset secondary power well
> > equests left on by DMC/KVMR")
> > needs to be applied on Cannonlake as well.
> >
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: f1faf571d9530365a34fe33a3efa3fb224661692
commit: 15b670ebb1bb7309b60c23b3fa1479d31cd79122 [1/7] Merge remote-tracking
branch 'drm-intel/drm-intel-next-queued' into drm-tip
config: x86_64-randconfig-i0-201715 (attached as .config)
On Thu, 13 Apr 2017, Peter Zijlstra wrote:
> On Thu, Apr 13, 2017 at 03:30:25PM +0300, Martin Peres wrote:
> > On 13/04/17 14:48, Peter Zijlstra wrote:
> > > On Wed, Apr 12, 2017 at 05:49:53PM +0300, Martin Peres wrote:
> > >
> > > > Good to know. Is there a way to disable this behaviour, as a
On Thu, Apr 13, 2017 at 02:14:17PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Check that no-op execution speed is the same in headless mode
> and with the display active.
>
> Signed-off-by: Tvrtko Ursulin
> Bugzilla:
On Thu, 13 Apr 2017 05:44:18 +
"Zhang, Xiong Y" wrote:
> > On Wed, 12 Apr 2017 20:20:00 +0800
> > Xiong Zhang wrote:
> >
> > > Stolen memory isn't a standard pci resource and exists in RMRR which has
> > > identity mapping in iommu table,
On Thu, Apr 06, 2017 at 12:15:23PM -0700, Rodrigo Vivi wrote:
> The workaround added in
> commit c6782b76d31a ("drm/i915/gen9: Reset secondary power well
> equests left on by DMC/KVMR")
> needs to be applied on Cannonlake as well.
>
> So let's assume any platform using this power well setup
>
== Series Details ==
Series: series starting with [1/2] drm/i915: Stop touching hangcheck.seqno from
intel_engine_init_global_seqno()
URL : https://patchwork.freedesktop.org/series/23003/
State : failure
== Summary ==
Series 23003v1 Series without cover letter
On Thu, Apr 13, 2017 at 03:30:25PM +0300, Martin Peres wrote:
> On 13/04/17 14:48, Peter Zijlstra wrote:
> > On Wed, Apr 12, 2017 at 05:49:53PM +0300, Martin Peres wrote:
> >
> > > Good to know. Is there a way to disable this behaviour, as a workaround
> > > for
> > > our CI system until a
From: Tvrtko Ursulin
Check that no-op execution speed is the same in headless mode
and with the display active.
Signed-off-by: Tvrtko Ursulin
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100572
Cc: Imre Deak
If we have a long period of idleness, we turn off the hangcheck timer
and stop polling the hardware. Before we restart the hangcheck, we
should clear the previous timestamps to prevent us thinking that the
engine was stalled for a long time, if the seqno were manipulated
carefully (such as the
The hangcheck runs independently to the main flow of seqno through the
driver. However, we have an odd coupling of the seqno reset that is
unwelcome, and if poked at just the right rate can cause spurious hangs
(e.g. gem_exec_whisper) on an apparently idle engine.
Signed-off-by: Chris Wilson
On Thu, Apr 13, 2017 at 01:02:37PM +0300, Mika Kuoppala wrote:
> Parallel spin on all engines.
>
> Signed-off-by: Mika Kuoppala
> ---
> tests/gem_spin_batch.c | 31 +--
> 1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git
On 13/04/17 14:48, Peter Zijlstra wrote:
On Wed, Apr 12, 2017 at 05:49:53PM +0300, Martin Peres wrote:
Good to know. Is there a way to disable this behaviour, as a workaround for
our CI system until a proper fix lands? We already pushed locally the revert
for this patch, but that may affect
On Wed, Apr 12, 2017 at 10:30:17PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Apparently some DP sinks are a little nuts and cause HPD to drop
> intermittently during modesets. This happens eg. on an ASUS PB287Q.
> In oder to recover from
Chris Wilson writes:
> On Thu, Apr 13, 2017 at 02:15:27PM +0300, Mika Kuoppala wrote:
>> Previously with commit a9c1f90c8e17
>> ("drm/i915: Don't mask EI UP interrupt on IVB|SNB") certain,
>> seemingly unrelated bit (GEN6_PM_RP_UP_EI_EXPIRED) was needed
>> to be
On Thu, Apr 13, 2017 at 11:39:40AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Fix system hang with EI UP masked on Haswell
> URL : https://patchwork.freedesktop.org/series/22991/
> State : failure
>
> == Summary ==
>
> Series 22991v1 drm/i915: Fix system hang with EI
On Wed, Apr 12, 2017 at 05:49:53PM +0300, Martin Peres wrote:
> Good to know. Is there a way to disable this behaviour, as a workaround for
> our CI system until a proper fix lands? We already pushed locally the revert
> for this patch, but that may affect other platforms which do not exhibit the
== Series Details ==
Series: drm/i915: Fix system hang with EI UP masked on Haswell
URL : https://patchwork.freedesktop.org/series/22991/
State : failure
== Summary ==
Series 22991v1 drm/i915: Fix system hang with EI UP masked on Haswell
On Thu, Apr 13, 2017 at 02:15:27PM +0300, Mika Kuoppala wrote:
> Previously with commit a9c1f90c8e17
> ("drm/i915: Don't mask EI UP interrupt on IVB|SNB") certain,
> seemingly unrelated bit (GEN6_PM_RP_UP_EI_EXPIRED) was needed
> to be unmasked for IVB and SNB in order to prevent system hang
>
Previously with commit a9c1f90c8e17
("drm/i915: Don't mask EI UP interrupt on IVB|SNB") certain,
seemingly unrelated bit (GEN6_PM_RP_UP_EI_EXPIRED) was needed
to be unmasked for IVB and SNB in order to prevent system hang
with chained batchbuffers.
Our CI was seeing incomplete results with tests
On Thu, Apr 13, 2017 at 12:10:49PM +0300, Imre Deak wrote:
> On Thu, Apr 13, 2017 at 04:29:41AM +0200, Rafael J. Wysocki wrote:
> > Hi,
> >
> > First off, sorry for introducing the problem and thanks for taking care of
> > it!
> >
> > On 4/11/2017 7:09 PM, Imre Deak wrote:
> > >On Tue, Apr 11,
On to, 2017-04-13 at 14:02 +0300, Joonas Lahtinen wrote:
> On pe, 2017-04-07 at 00:39 +, Patchwork wrote:
> >
> > == Series Details ==
> >
> > Series: drm/i915/guc: write wopcm related register once during uc init
> > URL : https://patchwork.freedesktop.org/series/22625/
> > State :
> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Dong, Chuanxiao
> Sent: Wednesday, April 12, 2017 5:12 PM
> To: Chris Wilson
> Cc: Tian, Kevin ;
On pe, 2017-04-07 at 00:39 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/guc: write wopcm related register once during uc init
> URL : https://patchwork.freedesktop.org/series/22625/
> State : success
Pushed the patch.
Regards, Joonas
--
Joonas Lahtinen
Open Source
On to, 2017-04-06 at 17:18 -0700, Daniele Ceraolo Spurio wrote:
> The wopcm registers are write-once, so any write after the first one
> will just be ignored. The registers survive a GPU reset but not
> always a suspend/resume cycle, so to keep things simple keep the
> writes in the
On ke, 2017-04-12 at 13:48 +0100, Chris Wilson wrote:
> With the addition of the inter-context intel_time.sync map, having a
intel_timeline.sync?
> very similar sync_seqno[] is confusing. Aide the reader by denoting that
> this a pre-allocated array for storing semaphore sync points wrt to the
>
On ke, 2017-04-12 at 13:48 +0100, Chris Wilson wrote:
> Although we do check the completion-status of the request before
> actually adding a wait on it (either to its submit fence or its
> completion dma-fence), we currently do not check before adding it to the
> dependency lists.
>
>
On to, 2017-04-13 at 01:01 +, Li, Weinan Z wrote:
> >
> > -Original Message-
> > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> > Sent: Wednesday, April 12, 2017 6:19 PM
> > To: Chris Wilson ; Li, Weinan Z
> >
> > Cc:
Parallel spin on all engines.
Signed-off-by: Mika Kuoppala
---
tests/gem_spin_batch.c | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/tests/gem_spin_batch.c b/tests/gem_spin_batch.c
index baf796a..a22da32 100644
---
Daniel has posted empty feat_profile.json as template to be used.
This is my understanding about the features and what tests are covering those.
Usage: piglit summary feature json-filename output-directory results-directory
Signed-off-by: Jari Tahvanainen
---
This
== Series Details ==
Series: drm/i915: Convert connector properties to atomic. (rev5)
URL : https://patchwork.freedesktop.org/series/22634/
State : success
== Summary ==
Series 22634v5 drm/i915: Convert connector properties to atomic.
This is required to for i915 to convert connector properties to atomic.
Changes since v1:
- Add docbook info. (danvet)
- Change picture_aspect_ratio to enum hdmi_picture_aspect.
Signed-off-by: Maarten Lankhorst
Cc: dri-de...@lists.freedesktop.org
Acked-by:
On Thu, Apr 13, 2017 at 04:29:41AM +0200, Rafael J. Wysocki wrote:
> Hi,
>
> First off, sorry for introducing the problem and thanks for taking care of
> it!
>
> On 4/11/2017 7:09 PM, Imre Deak wrote:
> >On Tue, Apr 11, 2017 at 05:54:07PM +0100, Chris Wilson wrote:
> >>On Tue, Apr 11, 2017 at
On 30.03.2017 11:09, Abdiel Janulgue wrote:
> Sanity check the edid block generation capabilities.
>
> Cc: Petri Latvala
Ping!
> Signed-off-by: Abdiel Janulgue
> ---
> lib/tests/Makefile.sources | 1 +
>
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Wednesday, April 12, 2017 9:22 PM
>
[...]
> By my limited understanding of VT-d details: The stolen memory is never
> directly accessed by i915 driver (because CPU access doesn't work even
> in DOM0). It is only used through
63 matches
Mail list logo