When a plane gets disabled, that commit has to complete before an
atomic commit on that disabled plane only. Else for the old commit,
new_plane_state may have been freed.
Signed-off-by: Maarten Lankhorst
---
tests/kms_atomic_transition.c | 31 +++
1 file changed, 31 i
All other atomic properties are reset in display_commit_changed,
which is the right place because TEST_ONLY commits don't need to
be reset.
Signed-off-by: Maarten Lankhorst
---
lib/igt_kms.c | 38 --
1 file changed, 16 insertions(+), 22 deletions(-)
diff --gi
Trying to set a fence on disabled pipes will be rejected by the kernel:
[ 1275.865029] [drm:drm_atomic_check_only [drm]] [CRTC:39:pipe B] requesting
event but off
Signed-off-by: Maarten Lankhorst
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99911
---
tests/kms_atomic_transition.c | 6
This is already done in igt_display_commit* functions.
Signed-off-by: Maarten Lankhorst
---
tests/kms_atomic_transition.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/tests/kms_atomic_transition.c b/tests/kms_atomic_transition.c
index a2470c0c3571..6e2b25da75db 100644
--- a/te
Quoting Michel Thierry (2017-07-06 02:24:26)
> On 04/07/17 09:09, Chris Wilson wrote:
> > Triggering a GPU reset for one engine affects another, notably
> > corrupting the context status buffer (CSB) effectively losing track of
> > inflight requests.
> >
> > Adding a few printks:
> > diff --git a/d
I wanted to make kms_atomic_transition pass, but the nonblocking modeset
fencing tests were bogus.
This series changes the semantics for fencing slightly. It only keeps the out
fences
in pipe_obj->out_fence_fd, it's up to the test to decide what to do with it,
which
is probably just waiting on t
This will make the IGT tests that use fences more useful, since they can
perform the waiting themselves when required.
To celebrate, also add plane-use-after-nonblocking-unbind-fencing,
the fence version of plane-use-after-nonblocking-unbind.
Signed-off-by: Maarten Lankhorst
---
lib/igt_kms.c
On 05/07/17 23:53, Lyude Paul wrote:
NAK. You're right that these don't actually give us any advantage over
just using CRCs and are just slower, however I left these tests in here
moreso just so we had something to actually test the frame dumping
functions so that we could avoid regressing them b
On 06/07/17 00:44, Lyude Paul wrote:
On Wed, 2017-07-05 at 11:04 +0300, Paul Kocialkowski wrote:
When a CRC comparison error occurs, it is quite useful to get a dump
of both the frame obtained from the chamelium and the reference in
order
to compare them.
This implements the frame dump, with a
On 06.07.2017 09:05, Maarten Lankhorst wrote:
> Hey,
>
> Op 03-07-17 om 12:19 schreef Abdiel Janulgue:
>> When descending thru debugfs directory. Doing this tends to
>> takes forever. CRC pipe read tests for this are already
>> covered under kms_pipe_crc_basic.
>>
>> v2: Be more verbose that the
Hi,
On Wed, 2017-07-05 at 16:34 -0400, Lyude Paul wrote:
> So a couple of notes here that will make it a lot easier for me to
> review these in the future
>
> * When you're doing a new revision of a patch series, it's helpful to
>keep it in the same email thread as the original v1 so it's ea
On Wed, Jul 05, 2017 at 02:30:43PM +0100, Tvrtko Ursulin wrote:
>
> On 27/06/2017 09:02, Tvrtko Ursulin wrote:
> > On 26/06/2017 17:09, Daniel Vetter wrote:
> > > On Fri, Jun 23, 2017 at 12:31:39PM +0100, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin
> > > >
> > > > Small series which saves
On Thu, Jun 15, 2017 at 11:11:45AM +0800, Xiong Zhang wrote:
> In a IGD passthrough environment, the real ISA bridge may doesn't exist.
> then pch_id couldn't be correctly gotten from ISA bridge, but pch_id is
> used to identify LPT_H and LPT_LP. Currently i915 treat all LPT pch as
> LPT_H,then err
From: Ville Syrjälä
We don't need any active planes during load detection, so just disable
them all. This saves us from having to come up with a suitable
framebuffer. And we also avoid leaving sprite/cursor planes on and
potentially presenting them at a peculiar location during the load
detection
== Series Details ==
Series: drm/i915: Disable all planes for load detection
URL : https://patchwork.freedesktop.org/series/26900/
State : warning
== Summary ==
Series 26900v1 drm/i915: Disable all planes for load detection
https://patchwork.freedesktop.org/api/1.0/series/26900/revisions/1/mbo
Quoting Tvrtko Ursulin (2017-07-05 16:18:23)
>
> On 05/07/2017 15:26, Chris Wilson wrote:
> > Currently, we move all unreferenced contexts to an RCU free list and
> > then onto a worker for eventual reaping. To compensate against this
> > growing into a long list with frequent allocations starving
On Tue, Jul 04, 2017 at 04:43:08PM +0200, Michał Winiarski wrote:
> Testing LNCFCMOCS values on non-render engines is tricky. The values in
> those registers are lost on RC6, which means that if users of non-render
> engines want to see the proper values, they need to obtain a forcewake
> and execu
On 3 July 2017 at 15:48, Chris Wilson wrote:
> Quoting Matthew Auld (2017-07-03 15:14:58)
>> +static struct i915_vma *
>> +gpu_write_dw(struct i915_vma *vma, u64 offset, u32 value)
>> +{
>> + struct drm_i915_private *i915 = to_i915(vma->obj->base.dev);
>> + struct drm_i915_gem_object *
Looks good to me:
Reviewed-by: Tomeu Vizoso
I guess you have tested this with IGT? In any case, I think it would
be good to mention how a patch has been tested in the changelog. That
can be very useful to others if things go wrong at some point.
Thanks,
Tomeu
On 21 June 2017 at 13:00, Maar
On Tue, Jun 20, 2017 at 11:25:02AM -0700, Michel Thierry wrote:
> Platforms with per-engine reset enabled (i915.reset=2) are unlikely to
> perform a full chip reset, keeping the reset_count unmodified. In order
> to keep the expectations of this test, enforce that full GPU reset is
> enabled (i915.
On 06/07/2017 10:28, Daniel Vetter wrote:
On Wed, Jul 05, 2017 at 02:30:43PM +0100, Tvrtko Ursulin wrote:
On 27/06/2017 09:02, Tvrtko Ursulin wrote:
On 26/06/2017 17:09, Daniel Vetter wrote:
On Fri, Jun 23, 2017 at 12:31:39PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Small series
Hi,
On Wed, 2017-07-05 at 17:44 -0400, Lyude Paul wrote:
> On Wed, 2017-07-05 at 11:04 +0300, Paul Kocialkowski wrote:
> > When a CRC comparison error occurs, it is quite useful to get a dump
> > of both the frame obtained from the chamelium and the reference in
> > order
> > to compare them.
> >
Quoting Tvrtko Ursulin (2017-07-05 11:19:43)
>
> On 03/07/2017 11:14, Chris Wilson wrote:
> > Many years ago, long before requests, we tried doing this. We never
> > quite got it right, but now with requests we have the tracking to do the
> > job properly!
>
> Add a few words on the benefits in c
On Thu, 2017-07-06 at 10:41 +0300, Martin Peres wrote:
> On 06/07/17 00:44, Lyude Paul wrote:
> > On Wed, 2017-07-05 at 11:04 +0300, Paul Kocialkowski wrote:
> > > When a CRC comparison error occurs, it is quite useful to get a dump
> > > of both the frame obtained from the chamelium and the refere
On 05/07/2017 18:21, Chris Wilson wrote:
Inspired by Tvrtko's critique of the reaping of the stale contexts
before allocating a new one, also limit the freed object reaping to the
oldest stale object before allocating a fresh object. Unlike contexts,
objects may have radically different sizes of
Quoting Tvrtko Ursulin (2017-07-06 12:40:56)
>
> On 05/07/2017 18:21, Chris Wilson wrote:
> > Inspired by Tvrtko's critique of the reaping of the stale contexts
> > before allocating a new one, also limit the freed object reaping to the
> > oldest stale object before allocating a fresh object. Unl
On 06/07/2017 12:44, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-06 12:40:56)
On 05/07/2017 18:21, Chris Wilson wrote:
Inspired by Tvrtko's critique of the reaping of the stale contexts
before allocating a new one, also limit the freed object reaping to the
oldest stale object before
Hi!
While trying to get CLUT support for the atmel_hlcdc driver, and
specifically for the emulated fbdev interface, I received some
push-back that my feeble in-driver attempts should be solved
by the core. This is my attempt to do it right.
I have obviously not tested all of this with more than a
The driver stores lut values from the fbdev interface, and is able
to give them back, but does not appear to do anything with these
lut values. The generic fb helpers have replaced this function,
and may even have made the driver work for the C8 mode from the
fbdev interface. But that is untested.
On 4 July 2017 at 12:12, Chris Wilson wrote:
>
> Quoting Mattias Nyman (2017-07-04 10:50:00)
> > Hey!
> > I am unable to rotate my screen to left or right using Skylake Integrated
> > Graphics with the
> > Option TearFree true
> > in the /usr/share/X11/xorg.conf.d/20-intel.conf
> >
> > The screen
There's a bunch of folks who're trying to make printk less
contended and faster, but there's a problem: printk uses the
console_lock, and the console lock has become the BKL for all things
fbdev/fbcon, which in turn pulled in half the drm subsystem under that
lock. That's awkward.
There reasons fo
Instead check info->ops->owner, which amounts to the same.
Spotted because I want to remove the pile of broken and cargo-culted
fb_info->flags assignments in drm drivers.
Cc: Bartlomiej Zolnierkiewicz
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/video/fbdev/core/fbc
It's not accelarated, just system memory. Note we don't even need to
set the default flag since that's now always 0.
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/qxl/qxl_fb.c | 2 +-
1 file changed, 1 insertion
Hi all,
So the original simple hack failed and we need to do a bit more. This time
tested including depmod for all combos. And since I had the pleasure to read
more fbdev code, 3 simple patches on top to clean up some more.
Cheers, Daniel
Daniel Vetter (4):
fbcon: Make fbcon a built-time depen
- FBINFO_CAN_FORCE_OUTPUT has been a lie ever since we nerfed&removed
the entire panic handling code in our fbdev emulation. We might
restore kms panic output, but not through the bazillion of legacy
code layers called fbdev/fbcon, there's just no way to make that
work safely.
- With the m
On 06/07/17 13:46, Mattias Nyman wrote:
On 4 July 2017 at 12:12, Chris Wilson wrote:
Quoting Mattias Nyman (2017-07-04 10:50:00)
Hey!
I am unable to rotate my screen to left or right using Skylake Integrated
Graphics with the
Option TearFree true
in the /usr/share/X11/xorg.conf.d/20-intel.co
With deferred fbdev setup we always need to forward hotplug events,
even if fbdev isn't fully set up yet. Otherwise the deferred setup
will neer happen.
Originally this check was added in
commit c45eb4fed12d278d3619f1904885bd0d7bcbf036 (tag:
drm-intel-next-fixes-2016-08-05)
Author: Chris Wilson
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
v2: Drop NULL check, drm_fb_helper_hotplug_event handles that already.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Thierry Reding
We could probably hit this already with our current async fbdev init,
but it's much easier to hit this with the new deferred fbdev setup
that I'm working on polishing.
Cc: Maarten Lankhorst
Reported-by: Maarten Lankhorst
Reviewed-by: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
drivers/
FB helper code falls back to a 1024x768 mode if no outputs are connected
or don't report back any modes upon initialization. This can be annoying
because outputs that are added to FB helper later on can't be used with
FB helper if they don't support a matching mode.
The fallback is in place becaus
From: Thierry Reding
The FB helper core now supports deferred setup, so the driver's custom
implementation can be removed.
v2: Dont' resurrect drm_vblank_cleanup.
Cc: Xinliang Liu
Cc: Rongrong Zou
Cc: Xinwei Kong
Cc: Chen Feng
Signed-off-by: Thierry Reding (v1)
Signed-off-by: Daniel Vetter
Op 06-07-17 om 13:09 schreef Tomeu Vizoso:
> Looks good to me:
>
> Reviewed-by: Tomeu Vizoso
>
> I guess you have tested this with IGT? In any case, I think it would
> be good to mention how a patch has been tested in the changelog. That
> can be very useful to others if things go wrong at some po
Op 06-07-17 om 15:00 schreef Daniel Vetter:
> With deferred fbdev setup we always need to forward hotplug events,
> even if fbdev isn't fully set up yet. Otherwise the deferred setup
> will neer happen.
>
> Originally this check was added in
>
> commit c45eb4fed12d278d3619f1904885bd0d7bcbf036 (tag:
On Wed, 2017-07-05 at 16:34 -0400, Lyude Paul wrote:
> So a couple of notes here that will make it a lot easier for me to
> review these in the future
>
> * When you're doing a new revision of a patch series, it's helpful to
>keep it in the same email thread as the original v1 so it's easier
I am only sending this for comments at this point, since this will need
to be reworked according to the changes made on previous series still
under review. Especially, it will benefit from making the frame save
mechanism common.
___
Intel-gfx mailing
This adds support for VGA frame comparison check. Since VGA uses a
DAC-ADC chain, its data cannot be expected to be pixel perfect. Thus, it
is impossible to uses a CRC check and full frames have to be analyzed
instead. Such an analysis is implemented, based on both an absolute
error threshold and a
This patch applies on top of: chamelium: Add support for VGA frame
comparison testing.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Nowadays, many VGA connectors are not actually native VGA but use a
discrete bridge to a digital connector. These bridges usually enforce
their own EDID instead of the one supplied by the chamelium.
Thus, the EDID read test for VGA is not relevant in that case and
should be skipped. Reported modes
On Wed, 2017-07-05 at 16:53 -0400, Lyude Paul wrote:
> NAK. You're right that these don't actually give us any advantage over
> just using CRCs and are just slower, however I left these tests in
> here
> moreso just so we had something to actually test the frame dumping
> functions so that we could
From: Tvrtko Ursulin
Default is not an engine but an ABI alias for RCS. Remove it
from the engine list to eliminate redundant subtests and test
passes.
v2: Fix basic test timeout.
Signed-off-by: Tvrtko Ursulin
Acked-by: Daniel Vetter
---
lib/igt_gt.c | 1 -
lib/igt_
On Thu, 2017-07-06 at 14:31 +0300, Paul Kocialkowski wrote:
> Hi,
>
> On Wed, 2017-07-05 at 17:44 -0400, Lyude Paul wrote:
> > On Wed, 2017-07-05 at 11:04 +0300, Paul Kocialkowski wrote:
> > > When a CRC comparison error occurs, it is quite useful to get a
> > > dump
> > > of both the frame obtain
Quoting Tvrtko Ursulin (2017-07-06 14:33:06)
> From: Tvrtko Ursulin
>
> Default is not an engine but an ABI alias for RCS. Remove it
> from the engine list to eliminate redundant subtests and test
> passes.
>
> v2: Fix basic test timeout.
>
> Signed-off-by: Tvrtko Ursulin
> Acked-by: Daniel Ve
On Wed, Jul 05, 2017 at 05:40:19PM +0300, David Weinehall wrote:
> On Wed, Jul 05, 2017 at 01:03:46PM +0300, Jani Nikula wrote:
> > On Tue, 04 Jul 2017, David Weinehall
> > wrote:
> > > This reverts commit ae25eceab616d16a07bcaa434b84463d58a3bdc3.
> > >
> > > The introduction of dynamic backlight
On 7/6/2017 3:59 AM, Tina Zhang wrote:
> Add VFIO_DEVICE_QUERY_GFX_PLANE ioctl command to let user mode query and
> get the plan and its related information.
>
> The dma-buf's life cycle is handled by user mode and tracked by kernel.
> The returned fd in struct vfio_device_query_gfx_plane can be
On Thu, Jun 29, 2017 at 04:22:51PM +, Patchwork wrote:
> == Series Details ==
>
> Series: gen9+: Sanitize power well disabling during display uninit
> URL : https://patchwork.freedesktop.org/series/26566/
> State : success
Thanks for the review, I pushed the series to -dinq.
>
> == Summar
Follow-up patches will add new fields to the i915_power_well struct that
are specific to the hsw_power_well_ops helpers. Prepare for this by
changing the generic 'data' field to a union of platform specific
structs.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.h | 6 +-
Atm we enable/disable a power well only if it wasn't already
enabled/disabled respectively. The only reason for this I can think of
is to save the extra MMIO writes. Since the HW state matches the power
well's usage counter most of the time the overhead due to these MMIOs is
insignificant. Let's si
We check already for power wells that are unexpectedly on (or forced on)
during power well disabling. Those checks also account for other
power well requesters like KVMR or DEBUG. As such this check is
redundant, let's remove it to simplify things.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i9
Atm, the power well IDs are defined in separate platform specific enums,
which isn't ideal for the following reasons:
- the IDs are used by helpers like lookup_power_well() in a platform
independent way
- the always-on power well is used by multiple platforms and so needs
now separate IDs, alth
Check that all the power well IDs are unique on the given platform.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 27c69
Make the GEN2 power well ID assignment explicit for consistency.
Cc: Ville Syrjälä
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_runtime_pm.c | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/dri
Power well IDs are used for lookup so they must be unique. To ensure
this assign the always-on power well ID everywhere where it's missing.
This didn't cause a problem so far, since we didn't need to look up
power wells that happened to share their IDs.
Signed-off-by: Imre Deak
---
drivers/gpu/d
Similarly to the GEN9 power well toggling, saving an occasional extra
MMIO write is not worth the code complexity, let's simplify things.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 36 -
1 file changed, 13 insertions(+), 23 deletions(-)
The pattern of a power well backing a set of pipe IRQ or VGA
functionality applies to all HSW+ platforms. Using power well attributes
instead of platform checks to decide whether to init/reset pipe IRQs and
VGA correspondingly is cleaner and it allows us to unify the HSW/BDW and
GEN9+ power well co
The power well IDs are used for lookup, so they must be unique on a
given platform; ensure this on CHV. This didn't cause an actual problem
since we didn't need to look up power wells which happened to share an
ID.
Mark this new power well as custom, since its programming pattern
doesn't follow th
The programming of display power wells starting from HSW is pretty
similar on all platforms, but we have separate code for HSW/BDW and
GEN9+ platforms. This patchset unifies the two for clarity and to make
it easier to add power well support for future platforms. In essence
this means adding 3 attr
Add an ID for the HSW/BDW global display power well for consistency. The
ID is selected so that it can be used to get at the HW request and
status flags with the corresponding GEN9+ macros. Unifying the HSW/BDW
and GEN9+ versions of these macros and the power well ops using them
will be done in fol
We can reduce the code indentation by splitting the set helper to
separate enable/disable helpers. This also allows us to unify the
HSW/BDW and GEN9+ power well ops in follow-up patches, which introduces
some differences between the enable and disable helpers.
While at it also remove the redundant
Although on HSW/BDW there is only a single display global power well,
it's programmed the same way as other GEN9+ power wells. This also
means we can get at the HSW/BDW request and status flags the same way
it's done on GEN9+ by assigning the corresponding HSW/BDW power well ID.
This ID was assigne
Move the helper next to the rest of HSW specific code.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_run
Shuffle the power well->domain mapping macros around so they are at one
place in old->new GEN order.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 408
1 file changed, 204 insertions(+), 204 deletions(-)
diff --git a/drivers/gpu/drm/i915
Similarly to GEN9+ waiting for the power well disabled state is a safer
option and also provides diagnostic info if the disabling didn't succeed
or the power well was forced on by an external requester. While at it
also use the existing GEN9+ helper to wait for the enabled state.
Signed-off-by: Im
The pattern of a power well backing a set of fuses whose initialization
we need to wait for during power well enabling is common to all GEN9+
platforms. Adding support for this to the HSW power well enable helper
allows us to use the HSW/BDW power well code for GEN9+ as well in a
follow-up patch.
After the previous refactorings the HSW/BDW and GEN9+ power well helpers
are practically identical, so use the HSW power well helpers for GEN9+
too. This means using the HSW power well ops instead of the SKL one and
setting the irq_pipe_mask, has_vga and has_fuses attributes as needed.
Signed-off-
Mahesh Kumar schreef op wo 05-07-2017 om 20:01 [+0530]:
> From: "Kumar, Mahesh"
>
> This patch adds IPC support for platforms. This patch enables IPC
> only for BXT/KBL platform as for SKL recommendation is to keep it
> disabled.
CFL/CNL missing. ;-)
> IPC (Isochronous Priority Control) is the ha
== Series Details ==
Series: Make fbcon a built-time depency for fbdev, take 2
URL : https://patchwork.freedesktop.org/series/26909/
State : success
== Summary ==
Series 26909v1 Make fbcon a built-time depency for fbdev, take 2
https://patchwork.freedesktop.org/api/1.0/series/26909/revisions/1
== Series Details ==
Series: series starting with [1/5] drm/i915/fbdev: Always forward hotplug events
URL : https://patchwork.freedesktop.org/series/26912/
State : success
== Summary ==
Series 26912v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/26912/revisions/
RB'd and pushed
On Tue, 2017-07-04 at 16:33 +0300, Paul Kocialkowski wrote:
> Since most tests are already doing a reset, there is no need to
> duplicate it at init time. This removes that duplicate reset and adds
> a call to reset_state where in-test resets where not done previously.
>
> Signed-
== Series Details ==
Series: drm/i915: Unify the HSW/BDW and GEN9+ power well code
URL : https://patchwork.freedesktop.org/series/26922/
State : success
== Summary ==
Series 26922v1 drm/i915: Unify the HSW/BDW and GEN9+ power well code
https://patchwork.freedesktop.org/api/1.0/series/26922/rev
RB'd and pushed, thanks!
On Tue, 2017-07-04 at 16:33 +0300, Paul Kocialkowski wrote:
> This adds support for configurable suspend/resume delay and takes the
> occasion to move igtrc configuation from igt_chamelium to igt_core.
> This way, suspend/resume delay configuration can be used for all
> te
On Tue, 2017-07-04 at 16:33 +0300, Paul Kocialkowski wrote:
> This renames the reprobe_connector function to update_connector and
> ensures that full reprobe of the connector is only done when really
> necessary (e.g. when changing the EDID).
>
> A full reprobe takes time and is not required for u
On gen8+ we're currently using the PPHWSP of the kernel ctx as the
global HWSP. However, when the kernel ctx gets submitted (e.g. from
__intel_autoenable_gt_powersave) the HW will use that page as both
HWSP and PPHWSP. Currently we're not seeing any problem because the
conflict happens at offsets b
From: Brian Starkey
An output can be added as a clone of any other output(s) attached to a
pipe using igt_output_clone_pipe()
Signed-off-by: Brian Starkey
Signed-off-by: Liviu Dudau
---
lib/igt_kms.c | 90 +--
lib/igt_kms.h | 3 ++
2 f
From: Brian Starkey
Update the connector search to also optionally attempt to find a
non-writeback connector to clone to.
Add a subtest which is the same as writeback-check-output, but also
clones to the second connector.
Signed-off-by: Brian Starkey
Signed-off-by: Liviu Dudau
---
tests/kms
From: Brian Starkey
To use writeback buffers as a CRC source, we need to be able to hash
them. Implement a simple FVA-1a hashing routine for this purpose.
Doing a bytewise hash on the framebuffer directly can be very slow if
the memory is noncached. By making a copy of each line in the FB first
From: Brian Starkey
Separate out the CRC code for better compartmentalisation. Should ease
the addition of more/different CRC sources in the future.
Signed-off-by: Brian Starkey
Signed-off-by: Liviu Dudau
---
lib/Makefile.sources | 2 +
lib/igt_chamelium.h | 1
From: Brian Starkey
Add a test which makes commits using the writeback connector, and
checks the output buffer hash to make sure it is/isn't written as
appropriate.
Signed-off-by: Brian Starkey
Signed-off-by: Liviu Dudau
---
tests/kms_writeback.c | 123 +++
From: Brian Starkey
Add support in igt_kms for Writeback connectors, with the ability to
attach framebuffers and retrieve fences.
Signed-off-by: Brian Starkey
Signed-off-by: Liviu Dudau
---
lib/igt_aux.c | 1 +
lib/igt_kms.c | 76 ++-
From: Brian Starkey
Add tests for the WRITEBACK_PIXEL_FORMATS, WRITEBACK_OUT_FENCE_PTR and
WRITEBACK_FB_ID properties on writeback connectors, ensuring their
behaviour is correct.
Signed-off-by: Brian Starkey
Signed-off-by: Liviu Dudau
---
lib/igt_kms.c | 6 +-
lib/igt_kms.h
We're trying to introduce support for writeback connectors, a way to
expose in DRM the hardware functionality from display engines that
allows to write back into memory the result of the DE's composition
of supported planes.
Generic DRM support is available here [1] and will be merged once
this pa
== Series Details ==
Series: drm/i915/lrc: allocate separate page for HWSP
URL : https://patchwork.freedesktop.org/series/26927/
State : success
== Summary ==
Series 26927v1 drm/i915/lrc: allocate separate page for HWSP
https://patchwork.freedesktop.org/api/1.0/series/26927/revisions/1/mbox/
On Thu, Jul 6, 2017 at 12:11 AM, Chris Wilson
wrote:
Quoting Michel Thierry (2017-07-06 02:24:26)
On 04/07/17 09:09, Chris Wilson wrote:
> Triggering a GPU reset for one engine affects another, notably
> corrupting the context status buffer (CSB) effectively losing
track of
> inflight req
On 05/07/17 04:48, Chris Wilson wrote:
If all goes well, resetting one engine should not affect the operation of
any others. So to test this, we setup a continuous stream of requests
onto to each of the "innocent" engines whilst constantly resetting our
target engine.
Signed-off-by: Chris Wilson
On 06/07/17 04:12, Arkadiusz Hiler wrote:
On Tue, Jun 20, 2017 at 11:25:02AM -0700, Michel Thierry wrote:
Platforms with per-engine reset enabled (i915.reset=2) are unlikely to
perform a full chip reset, keeping the reset_count unmodified. In order
to keep the expectations of this test, enforce
Quoting Daniele Ceraolo Spurio (2017-07-06 17:10:40)
> On gen8+ we're currently using the PPHWSP of the kernel ctx as the
> global HWSP. However, when the kernel ctx gets submitted (e.g. from
> __intel_autoenable_gt_powersave) the HW will use that page as both
> HWSP and PPHWSP. Currently we're not
On 7/6/2017 10:59 AM, Chris Wilson wrote:
> If there are no conflicts, then just skip the patch, and really there
> shouldn't be since the writes we care about are ordered and the writes
> we don't, we don't. We will need to move to per-context hwsp in the near
> future which should alleviate thes
intel_uncore_forcewake_reset() does forcewake puts and gets as such
we need to make sure that no-one tries to access the PUNIT->PMIC bus
(on systems where this bus is shared) while it runs, otherwise bad
things happen.
Normally this is taken care of by the i915_pmic_bus_access_notifier()
which doe
assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
even though it gets unregistered on (runtime) suspend, this is caused
by a race happening under the following circumstances:
intel_runtime_pm_put does:
atomic_dec(&dev_priv->pm.wakeref_count);
pm_runtime_mark_last_bus
intel_uncore_suspend() unregisters the uncore code's PMIC bus access
notifier and gets called on both normal and runtime suspend.
intel_uncore_resume_early() re-registers the notifier, but only on
normal resume. Add a new intel_uncore_runtime_resume() function which
only re-registers the notifier
Quoting Ville: "the forcewake timer might still be active until the uncore
suspend, and having active forcewakes while we've already told the GT wake
stuff to stop acting normally doesn't seem quite right to me."
Reported-by: Ville Syrjälä
Suggested-by: Imre Deak
Signed-off-by: Hans de Goede
--
1 - 100 of 186 matches
Mail list logo
