[Intel-gfx] ✗ Ro.CI.BAT: failure for Enable FBC on SKL (rev8)

== Series Details == Series: Enable FBC on SKL (rev8) URL : https://patchwork.freedesktop.org/series/4722/ State : failure == Summary == Applying: drm/i915/fbc: update busy_bits even for GTT and flip flushes Applying: drm/i915/fbc: sanitize i915.enable_fbc during FBC init fatal: sha1

[Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [1/3] drm/i915/fbdev: Perform async fbdev initialisation much later

== Series Details == Series: series starting with [1/3] drm/i915/fbdev: Perform async fbdev initialisation much later URL : https://patchwork.freedesktop.org/series/8856/ State : warning == Summary == Series 8856v1 Series without cover letter

Re: [Intel-gfx] [PATCH 3/7] drm/atmel-hlcdc: Remove redundant calls to drm_connector_register_all()

On 17 June 2016 at 09:25, Chris Wilson wrote: > Up to now, the recommendation was for drivers to call drm_dev_register() > followed by drm_connector_register_all(). Now that > drm_connector_register() is safe against multiple invocations, we can > move

Re: [Intel-gfx] [PATCH 13/16] drm: Refactor drop/set master code a bit

On 18 June 2016 at 00:00, Emil Velikov wrote: >> @@ -134,24 +152,21 @@ static int drm_new_set_master(struct drm_device *dev, >> struct drm_file *fpriv) >> >> /* take another reference for the copy in the local file priv */ >> old_master = fpriv->master;

Re: [Intel-gfx] [PATCH 16/16] drm: document drm_auth.c

On 17 June 2016 at 08:33, Daniel Vetter wrote: > Also extract drm_auth.h for nicer grouping. > > v2: Nuke the other comments since they don't really explain a lot, and > within the drm core we generally only document functions exported to > drivers: The main audience for

Re: [Intel-gfx] [PATCH 15/16] drm: Clear up master tracking booleans

On 17 June 2016 at 08:33, Daniel Vetter wrote: > @@ -315,10 +313,10 @@ struct drm_file { > /* true if client understands atomic properties */ > unsigned atomic:1; > /* > -* This client is allowed to gain master privileges for @master. > +

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote: > On Fri, 17 Jun 2016, Daniel Vetter wrote: > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote: > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote: > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel

Re: [Intel-gfx] [PATCH 13/16] drm: Refactor drop/set master code a bit

Hi Daniel, It doesn't look quite right I'm afraid. This causes a leak plus there's a small style issue. See below for details. On 17 June 2016 at 08:33, Daniel Vetter wrote: > @@ -134,24 +152,21 @@ static int drm_new_set_master(struct drm_device *dev, > struct

Re: [Intel-gfx] [drm] e28cd4d0a2: INFO: trying to register non-static key.

On Sat, Jun 18, 2016 at 12:19 AM, Chris Wilson wrote: > On Sat, Jun 18, 2016 at 05:24:30AM +0800, kernel test robot wrote: >> >> >> FYI, we noticed the following commit: >> >> git://anongit.freedesktop.org/drm-intel topic/drm-misc >> commit

Re: [Intel-gfx] [drm] e28cd4d0a2: INFO: trying to register non-static key.

On Sat, Jun 18, 2016 at 05:24:30AM +0800, kernel test robot wrote: > [1.338384] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a > 16550A > [1.340531] toshiba: not a supported Toshiba laptop > [1.341126] [drm] Initialized drm 1.1.0 20060810 > [1.342029] INFO: trying to

Re: [Intel-gfx] [PATCH 11/16] drm: Nuke SET_UNIQUE ioctl

On 17 June 2016 at 08:33, Daniel Vetter wrote: > Ever since > > commit 2e1868b560315a8b20d688e646c489a5ad93eeae > Author: Eric Anholt > Date: Wed Jun 16 09:25:21 2004 + > > DRI trunk-20040613 import > > the X server supports drm 1.1, and

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/ilk: Don't attempt to register eDP if LVDS was detected

On Sat, Jun 18, 2016 at 12:29:24AM +0300, Imre Deak wrote: > Atm on ILK we attempt to detect if eDP is present even if LVDS was > already detected and an encoder for it was registered. This involves > trying to read out the eDP EDID, which in turn needs the same power > sequencer that LVDS uses.

Re: [Intel-gfx] [PATCH 08/16] drm: Use dev->name as fallback for dev->unique

Hi Daniel, On 17 June 2016 at 08:33, Daniel Vetter wrote: > Lots of arm drivers get this wrong and for most arm boards this is the > right thing actually. And anyway with most loaders you want to chase > sysfs links anyway to figure out which dri device you want. > > This

Re: [Intel-gfx] [drm] e28cd4d0a2: INFO: trying to register non-static key.

On Sat, Jun 18, 2016 at 05:24:30AM +0800, kernel test robot wrote: > > > FYI, we noticed the following commit: > > git://anongit.freedesktop.org/drm-intel topic/drm-misc > commit e28cd4d0a223e1bcea616326e2281900e7e7e9a2 ("drm: Automatically > register/unregister all connectors") > > > on

Re: [Intel-gfx] [PATCH 0/3] Fixes for HPD

Forgot to mention, Ville: if you could get me an example of how to get vlv into an infinite loop with these patches I'd appreciate that. I haven't been able to reproduce this at all with the Valleyview machine I've got here. On Fri, 2016-06-17 at 17:58 -0400, Lyude wrote: > These are a couple of

[Intel-gfx] [PATCH RESEND 1/3] drm/i915/vlv: Make intel_crt_reset() per-encoder

This lets call intel_crt_reset() in contexts where IRQs are disabled and as such, can't hold the locks required to work with the connectors. Cc: sta...@vger.kernel.org Cc: Ville Syrjälä Cc: Daniel Vetter Signed-off-by: Lyude

[Intel-gfx] [PATCH RESEND 2/3] drm/i915/vlv: Reset the ADPA in vlv_display_power_well_init()

While VGA hotplugging worked(ish) before, it looks like that was mainly because we'd unintentionally enable it in valleyview_crt_detect_hotplug() when we did a force trigger. This doesn't work reliably enough because whenever the display powerwell on vlv gets disabled, the values set in VLV_ADPA

[Intel-gfx] [PATCH 0/3] Fixes for HPD

These are a couple of patches intended to fix one of the big problems we have with a lot of chipsets on i915 right now: in the various forms of suspend we use in the driver, many of them break HPD while active and can lead to some seriously confusing situations where they can't get their monitors

[Intel-gfx] [PATCH 3/3] drm/i915: Enable polling when we don't have hpd

Unfortunately, there's two situations where we lose hpd right now: - Runtime suspend - When we've shut off all of the power wells on Valleyview/Cherryview While it would be nice if this didn't cause issues, this has the ability to get us in some awkward states where a user won't be able to get

[Intel-gfx] [PATCH v2 2/2] drm/i915: Initialize the PPS HW before its first use

The initial EDID read for eDP detection involves using the PPS, but so far we only initialized the PPS registers after the EDID read. The reason this was done so far is to preserve a possible LVDS PPS HW setup if LVDS is detected but eDP is not. This is not an issue any more after the previous

[Intel-gfx] [PATCH v2 1/2] drm/i915/ilk: Don't attempt to register eDP if LVDS was detected

Atm on ILK we attempt to detect if eDP is present even if LVDS was already detected and an encoder for it was registered. This involves trying to read out the eDP EDID, which in turn needs the same power sequencer that LVDS uses. Poking at the VDD line at an unexpected time may or may not

[Intel-gfx] [drm] e28cd4d0a2: INFO: trying to register non-static key.

FYI, we noticed the following commit: git://anongit.freedesktop.org/drm-intel topic/drm-misc commit e28cd4d0a223e1bcea616326e2281900e7e7e9a2 ("drm: Automatically register/unregister all connectors") on test machine: vm-lkp-wsx03-yocto-i386: 1 threads qemu-system-i386 -enable-kvm with 320M

Re: [Intel-gfx] [PATCH 3/3] drm/i915/gen9: Drop invalid WARN() during data rate calculation

On Mon, Jun 13, 2016 at 11:33:50AM +0200, Maarten Lankhorst wrote: > Op 10-06-16 om 00:14 schreef Matt Roper: > > It's possible to have a non-zero plane mask and still wind up with a > > total data rate of zero. There are two cases where this can happen: > > > > * planes are active (from the KMS

Re: [Intel-gfx] [PATCH v12 4/9] drm/i915: gvt: Introduce the basic architecture of GVT-g

On Thu, Jun 16, 2016 at 08:07:00AM -0400, Zhi Wang wrote: > @@ -222,3 +223,7 @@ MODULE_PARM_DESC(inject_load_failure, > module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool, > 0600); > MODULE_PARM_DESC(enable_dpcd_backlight, > "Enable support for DPCD backlight

Re: [Intel-gfx] [PATCH 2/3] drm/i915/gen9: Compute data rates for all planes on first commit

On Mon, Jun 13, 2016 at 04:50:31PM +0200, Daniel Vetter wrote: > On Thu, Jun 09, 2016 at 03:14:54PM -0700, Matt Roper wrote: > > When we sanitize our DDB and watermark info during the first atomic > > commit, we need to calculate the total data rate. Since we haven't > > explicitly added the

Re: [Intel-gfx] [PATCH 1/3] drm/i915/gen9: Initialize intel_state->active_crtcs during WM sanitization

On Mon, Jun 13, 2016 at 04:49:49PM +0200, Daniel Vetter wrote: > On Thu, Jun 09, 2016 at 03:14:53PM -0700, Matt Roper wrote: > > intel_state->active_crtcs is usually only initialized when doing a > > modeset. During our first atomic commit after boot, we're effectively > > faking a modeset to

[Intel-gfx] [PATCH v2 3/3] drm/i915/gen9: Drop invalid WARN() during data rate calculation

It's possible to have a non-zero plane mask and still wind up with a total data rate of zero. There are two cases where this can happen: * planes are active (from the KMS point of view), but are all fully clipped (positioned offscreen) * the only active plane on a CRTC is the cursor (which

[Intel-gfx] [PATCH v2 2/3] drm/i915/gen9: Compute data rates for all planes on first commit

When we sanitize our DDB and watermark info during the first atomic commit, we need to calculate the total data rate. Since we haven't explicitly added the planes for each CRTC to our atomic state, the total data rate calculation will try to use the cached values from a previous commit (which are

[Intel-gfx] [PATCH v2 0/3] SKL watermark fixes for !fbcon

There are a handful of watermark bugs that are only triggered (or more easily triggered) when running without fbcon. Thanks Tvrtko for pointing these out. Mate Roper (3): drm/i915/gen9: Initialize intel_state->active_crtcs during WM sanitization (v2) drm/i915/gen9: Compute data rates for

[Intel-gfx] [PATCH v2 1/3] drm/i915/gen9: Initialize intel_state->active_crtcs during WM sanitization (v2)

intel_state->active_crtcs is usually only initialized when doing a modeset. During our first atomic commit after boot, we're effectively faking a modeset to sanitize the DDB/wm setup, so ensure that this field gets initialized before use. v2: - Don't clobber active_crtcs if our first commit

Re: [Intel-gfx] [PATCH] drm/i915/ilk: Don't attempt to register eDP if LVDS was detected

On Fri, Jun 17, 2016 at 06:48:45PM +0300, Imre Deak wrote: > Atm on ILK we attempt to detect if eDP is present even if LVDS was > already detected and an encoder for it was registered. This involves > trying to read out the eDP EDID, which in turn needs the same power > sequencer that LVDS uses.

Re: [Intel-gfx] [PATCH v2] Revert "sna: Refresh last detection timestamp on hotplug notifies"

On Fri, 2016-06-17 at 20:57 +0100, Chris Wilson wrote: > On Fri, Jun 17, 2016 at 03:44:34PM -0400, Lyude wrote: > > > > From: Lyude Paul > > > > DRM does not always update the status of each connector during a > > hotplug event, and it's generally expected that userspace is >

Re: [Intel-gfx] [PATCH v2] Revert "sna: Refresh last detection timestamp on hotplug notifies"

On Fri, Jun 17, 2016 at 03:44:34PM -0400, Lyude wrote: > From: Lyude Paul > > DRM does not always update the status of each connector during a > hotplug event, and it's generally expected that userspace is supposed to > handle that by reprobing. This happens in a couple

Re: [Intel-gfx] [PATCH v12 0/9] Introduce the implementation of GVT context

On Thu, Jun 16, 2016 at 08:06:56AM -0400, Zhi Wang wrote: > This patchset introduces the implementation of GVT context. GVT > context is a special GEM context used by GVT-g. GVT-g uses it as the shadow > context.It doesn't have a drm client nor a PPGTT. And it requires a larger > ring buffer with

[Intel-gfx] [PATCH v2] drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC Are Enabled "Display flickering may occur when both FBC (Frame Buffer Compression) and VT - d (Intel® Virtualization Technology for Directed I/O) are enabled and in use by the display controller." Ville found the w/a name in the

[Intel-gfx] [PATCH v2] Revert "sna: Refresh last detection timestamp on hotplug notifies"

From: Lyude Paul DRM does not always update the status of each connector during a hotplug event, and it's generally expected that userspace is supposed to handle that by reprobing. This happens in a couple situations: suspend/resume, MST hotplugs, and probably a few others. As

Re: [Intel-gfx] [PATCH] drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

On Fri, Jun 17, 2016 at 05:39:51PM +0100, Chris Wilson wrote: > Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC Are Enabled > > "Display flickering may occur when both FBC (Frame Buffer Compression) > and VT - d (Intel® Virtualization Technology for Directed I/O) are enabled >

Re: [Intel-gfx] [PATCH] drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

On Fri, Jun 17, 2016 at 07:02:57PM +, Zanoni, Paulo R wrote: > Em Sex, 2016-06-17 às 17:39 +0100, Chris Wilson escreveu: > > Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC Are > > Enabled > > > > "Display flickering may occur when both FBC (Frame Buffer > > Compression) > >

Re: [Intel-gfx] [PATCH] drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

Em Sex, 2016-06-17 às 17:39 +0100, Chris Wilson escreveu: > Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC Are > Enabled > > "Display flickering may occur when both FBC (Frame Buffer > Compression) > and VT - d (Intel® Virtualization Technology for Directed I/O) are > enabled >

Re: [Intel-gfx] [PATCH v12 1/9] drm/i915: Factor out i915_pvinfo.h

On Thu, Jun 16, 2016 at 08:06:57AM -0400, Zhi Wang wrote: > As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g > host (GVT-g kernel device model), factor it out for better code structure. > > v7: > - Split the "offsetof" modification into a dedicated patch. (Joonas) > >

Re: [Intel-gfx] [PATCH] drm/i915: Refresh cached DP port register value on resume

On Fri, 2016-05-13 at 20:53 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > During hibernation the cached DP port register value will be left with > whatever value we have there when we create the hibernation image. > Currently that means the

Re: [Intel-gfx] [PATCH 3/3] drm/i915/fbdev: Flush mode configuration before lastclose

On Fri, Jun 17, 2016 at 06:54:49PM +0100, Chris Wilson wrote: > During lastclose, we call intel_fbdev_restore_mode() to switch back to > the fbcon configuration on return to VT. However, if we have not yet > finished the asynchronous fbdev initialisation, the current mode will be > invalid and

[Intel-gfx] [PATCH 1/3] drm/i915/fbdev: Perform async fbdev initialisation much later

Setting up fbdev requires everything ready and registered (in particular the connectors). In the next patch, we defer registration of the KMS objects and unless we defer setting off fbdev, it may run before they are registered and oops. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 2/3] drm/i915/fbdev: Limit the global async-domain synchronization

During cleanup we have to synchronise with the async task we are using to initialise and register our fbdev. Currently, we are using a full synchronisation on the global domain, but we can restrict this to just synchronising up to our task if we remember our cookie. v2: async_synchronize_cookie()

[Intel-gfx] [PATCH 3/3] drm/i915/fbdev: Flush mode configuration before lastclose

During lastclose, we call intel_fbdev_restore_mode() to switch back to the fbcon configuration on return to VT. However, if we have not yet finished the asynchronous fbdev initialisation, the current mode will be invalid and trigger WARNs upon application. Serialise with the outstanding

Re: [Intel-gfx] [PATCH] drm/i915/gen9: Add WaInPlaceDecompressionHang (fwd)

x-next] [also build test WARNING on next-20160617] [cannot apply to v4.7-rc3] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Mika-Kuoppala/drm-i915-gen9-Add-WaInPlaceDecompressionHang/201

[Intel-gfx] Quick set of async fbdev fixes

Some easy to review fbdev vs async_domain fixes. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/4] drm/i915: use ORIGIN_CPU for frontbuffer invalidation on WC mmaps

From: Chris Wilson ... instead of the previous ORIGIN_GTT. This should actually invalidate FBC once something is written on the frontbuffer using WC mmaps. The problem with ORIGIN_GTT is that the automatic hardware tracking is not able to detect the WC writes as it can

[Intel-gfx] ✗ Ro.CI.BAT: failure for Enable FBC on SKL (rev6)

== Series Details == Series: Enable FBC on SKL (rev6) URL : https://patchwork.freedesktop.org/series/4722/ State : failure == Summary == Applying: drm/i915/fbc: update busy_bits even for GTT and flip flushes Applying: drm/i915/fbc: sanitize i915.enable_fbc during FBC init fatal: sha1

[Intel-gfx] [PATCH] drm/i915/fbc: FBC causes display flicker when VT-d is enabled on Skylake

Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC Are Enabled "Display flickering may occur when both FBC (Frame Buffer Compression) and VT - d (Intel® Virtualization Technology for Directed I/O) are enabled and in use by the display controller." Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH] drm/i915/guc: index host arrays by i915 engine ID, not guc_id

The ONLY places that guc_id (aka hw_id) should be used are those where the value or address is determined by and shared with the GuC firmware; specifically, when filling in the GuC-context-descriptor or the GuC addon data, or putting an entry in the GuC's work queue. It need not (and therefore

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915/ilk: Don't attempt to register eDP if LVDS was detected

== Series Details == Series: drm/i915/ilk: Don't attempt to register eDP if LVDS was detected URL : https://patchwork.freedesktop.org/series/8846/ State : success == Summary == Series 8846v1 drm/i915/ilk: Don't attempt to register eDP if LVDS was detected

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote: > On Fri, 17 Jun 2016, Daniel Vetter wrote: > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote: > > > On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote: > > > > On Thu, 2016-06-16 at 23:24 +0200, Daniel

[Intel-gfx] [PATCH 1/3] drm/i915/dp: Free the drm_dp_aux along with the encoder

The drm_dp_ax object is stored on the encoder, and freeing it from the connector causes a use-after-free error since the encoder is destroy first: [ 112.356952] == [ 112.357065] BUG: KASAN: use-after-free in

[Intel-gfx] Fixup drm-misc vs i915->unload()

In order to quieten the warning about out-of-order unload, we need to move our connector unregistrations actions from our custom callback to earlier when the core unregister the connectors. The change from earlier is that I missed a vital patch to prevent a use-after-free during DP connector

[Intel-gfx] [PATCH 3/3] drm/i915: Move backlight unregistration to connector unregistration

Currently the backlight is being unregistered in the unload phase (after the display and its objects are unregistered). Move the backlight unregistration into the analogous phase by performing it from the connector unregistration, just prior to its deletion. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 2/3] drm/i915: Move intel_connector->unregister to connector->early_unregister

We now have a connector->func that serves the same purpose as our own intel_connector->unregister vfunc allowing us to unwrap ourselves and use drm_connector_register() (and friends) as the central function. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH] drm/i915/ilk: Don't attempt to register eDP if LVDS was detected

Atm on ILK we attempt to detect if eDP is present even if LVDS was already detected and an encoder for it was registered. This involves trying to read out the eDP EDID, which in turn needs the same power sequencer that LVDS uses. Poking at the VDD line at an unexpected time may or may not

Re: [Intel-gfx] [PATCH] drm/i915/guc: make forwarding of VBlanks conditional

On Fri, Jun 17, 2016 at 04:14:48PM +0200, Daniel Vetter wrote: > On Fri, Jun 17, 2016 at 04:51:34PM +0300, Ville Syrjälä wrote: > > On Fri, Jun 17, 2016 at 02:42:39PM +0100, Dave Gordon wrote: > > > Apparently we shouldn't forward VBlanks to the GuC unconditionally, > > > as it may trigger a race

[Intel-gfx] [PATCH igt] igt: Repalce drv_missed_irq_hang script with a C-equivalent

In order to control some of the finer detail of detecting when we missed an interrupt, replace the shell script with C. This version submits a hanging batch and uses a child process to unhang it, whilst the parent sleeps. As the child process is prevented from running whilst the parent is alive

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/guc: make forwarding of VBlanks conditional

== Series Details == Series: drm/i915/guc: make forwarding of VBlanks conditional URL : https://patchwork.freedesktop.org/series/8835/ State : failure == Summary == Series 8835v1 drm/i915/guc: make forwarding of VBlanks conditional

Re: [Intel-gfx] [PATCH 01/12] drm/i915: Don't mark eDP encoders as MST capable

On Fri, Jun 17, 2016 at 06:35:33AM +1000, Dave Airlie wrote: > On 8 June 2016 at 20:41, wrote: > > From: Ville Syrjälä > > > > If we've determined that the encoder is eDP, we shouldn't try to use MST > > on it. Or at least the code

Re: [Intel-gfx] [PATCH] drm/i915: Revert DisplayPort fast link training feature

On Fri, 17 Jun 2016, Mika Kahola wrote: > It has been turned out that in some HW combination the DisplayPort "It has turned out" or "It has been found out", I think. > fast link training feature caused screen flickering. Let's revert > this feature for now until we can

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Limit i915_ring_test_irq debugfs to actual rings

== Series Details == Series: drm/i915: Limit i915_ring_test_irq debugfs to actual rings URL : https://patchwork.freedesktop.org/series/8833/ State : warning == Summary == Series 8833v1 drm/i915: Limit i915_ring_test_irq debugfs to actual rings

Re: [Intel-gfx] [PATCH] drm/i915/guc: make forwarding of VBlanks conditional

On Fri, Jun 17, 2016 at 04:51:34PM +0300, Ville Syrjälä wrote: > On Fri, Jun 17, 2016 at 02:42:39PM +0100, Dave Gordon wrote: > > Apparently we shouldn't forward VBlanks to the GuC unconditionally, > > as it may trigger a race condition in the GuC's internal dispatcher. > > > > From an internal

[Intel-gfx] [PATCH i-g-t 2/2] tests: Push igt_fork/stop_hang_detector into fixtures

It access hardware, hence why the simple igt_only_list_subtests() check from igt_fork/stop_signal_helper() isn't enough. Signed-off-by: Daniel Vetter --- lib/igt_aux.c| 6 -- tests/gem_concurrent_all.c | 6 -- tests/gem_ctx_create.c |

[Intel-gfx] [PATCH i-g-t 1/2] tests/gem_close_race: Use drm_open_driver helper

Signed-off-by: Daniel Vetter --- tests/gem_close_race.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/tests/gem_close_race.c b/tests/gem_close_race.c index 94fb905213a2..6458505d6500 100644 --- a/tests/gem_close_race.c +++

Re: [Intel-gfx] [PATCH] drm/i915/guc: make forwarding of VBlanks conditional

On Fri, Jun 17, 2016 at 02:42:39PM +0100, Dave Gordon wrote: > Apparently we shouldn't forward VBlanks to the GuC unconditionally, > as it may trigger a race condition in the GuC's internal dispatcher. > > From an internal message from Harsh Chheda > > > > If the

[Intel-gfx] [PATCH] drm/i915/guc: make forwarding of VBlanks conditional

Apparently we shouldn't forward VBlanks to the GuC unconditionally, as it may trigger a race condition in the GuC's internal dispatcher. From an internal message from Harsh Chheda > > If the context has switched out the [GuC] scheduler should know so > that it can put

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915/gen9: Add WaInPlaceDecompressionHang

== Series Details == Series: drm/i915/gen9: Add WaInPlaceDecompressionHang URL : https://patchwork.freedesktop.org/series/8832/ State : warning == Summary == Series 8832v1 drm/i915/gen9: Add WaInPlaceDecompressionHang http://patchwork.freedesktop.org/api/1.0/series/8832/revisions/1/mbox Test

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [1/7] drm: Automatically register/unregister all connectors

On Fri, Jun 17, 2016 at 11:44:48AM +0100, Chris Wilson wrote: > On Fri, Jun 17, 2016 at 10:12:00AM +0100, Chris Wilson wrote: > > On Fri, Jun 17, 2016 at 08:47:04AM -, Patchwork wrote: > > > == Series Details == > > > > > > Series: series starting with [1/7] drm: Automatically

[Intel-gfx] [PATCH] drm/i915: Limit i915_ring_test_irq debugfs to actual rings

For simplicity in testing, only report known rings in the mask. This allows userspace to try and trigger a missed irq on every ring and do a comparison between i915_ring_test_irq and i915_ring_missed_irq to see if any rings failed. Signed-off-by: Chris Wilson Cc: Mika

Re: [Intel-gfx] Bad flicker on skylake HQD due to code in the 4.7 merge window

On Fri, 17 Jun 2016, Daniel Vetter wrote: > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote: >> On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote: >> > On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote: >> > > I guess we'll need the bisect on this one

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move intel_connector->unregister to connector->early_unregister

Hi, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on v4.7-rc3 next-20160617] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Move

Re: [Intel-gfx] [PATCH 1/7] drm: Automatically register/unregister all connectors

On Fri, Jun 17, 2016 at 09:25:17AM +0100, Chris Wilson wrote: > As the drm_connector is now safe for multiple calls to > register/unregister, automatically perform a registration on all known > connectors drm drv_register (and unregister from drm_drv_unregister). > Drivers can still call

Re: [Intel-gfx] [PATCH 2/2] drm: Minimally initialise drm_dp_aux

On Fri, Jun 17, 2016 at 09:33:18AM +0100, Chris Wilson wrote: > When trying to split up the initialisation phase and the registration > phase, one immediate problem encountered is trying to use our own i2c > devices before registration with userspace (to read EDID during device > discovery).

[Intel-gfx] [PATCH] drm/i915/gen9: Add WaInPlaceDecompressionHang

Add this workaround to prevent hang when in place compression is used. References: HSD#2135774 Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/i915_reg.h | 3 +++ drivers/gpu/drm/i915/intel_ringbuffer.c |

Re: [Intel-gfx] [PATCH 37/38] drm/sti: Don't call drm_helper_disable_unused_functions

On Fri, Jun 17, 2016 at 12:04:16PM +0200, Benjamin Gaignard wrote: > Acked-by: Benjamin Gaignard Applied to drm-misc. -Daniel > > 2016-06-02 0:07 GMT+02:00 Daniel Vetter : > > Atomic drivers are supposed to do hw/sw state reset with the > >

Re: [Intel-gfx] [PATCH 19/38] drm/hisilicon: Implement some semblance of vblank event handling

On Fri, Jun 17, 2016 at 04:38:06PM +0800, Xinliang Liu wrote: > Hi, > > On 17 June 2016 at 15:23, Daniel Vetter wrote: > > On Fri, Jun 17, 2016 at 10:09:50AM +0800, Xinliang Liu wrote: > >> Hi Daniel, > >> > >> I have tested your David's drm-next branch[1] which including this

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: Revert DisplayPort fast link training feature

== Series Details == Series: drm/i915: Revert DisplayPort fast link training feature URL : https://patchwork.freedesktop.org/series/8828/ State : success == Summary == Series 8828v1 drm/i915: Revert DisplayPort fast link training feature

Re: [Intel-gfx] Minnowboard i915 driver not getting initialized properly

On 15/06/16 09:42, vinoth eswaran wrote: Hello Mr.David Gordon, I working on an embedded project with Minnowboard Turbot. The goal is to have a camera application running as fast as possible (within 2 sec). For this, I have replaced the UEFI bootloader with the U-boot (Latest git version -

[Intel-gfx] [PATCH] drm/i915: Revert DisplayPort fast link training feature

It has been turned out that in some HW combination the DisplayPort fast link training feature caused screen flickering. Let's revert this feature for now until we can ensure that the feature works for all platforms. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393 Signed-off-by: Mika

Re: [Intel-gfx] [PATCH 10/16] drm: Don't call drm_dev_set_unique from platform drivers

Hi Daniel, Thank you for the patch. On Friday 17 Jun 2016 09:33:28 Daniel Vetter wrote: > Since > > commit e112e593b215c394c0303dbf0534db0928e87967 > Author: Nicolas Iooss > Date: Fri Dec 11 11:20:28 2015 +0100 > > drm: use dev_name as default unique name in

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for Convert requests to use struct fence (rev7)

Two race conditions showed up during the CI BAT testing. I did manage to reproduce it locally as well but only after many runs of the BAT suite. Annoyingly, it was rare enough not to be noticed before letting the BAT farm run lots of tests across lots of different machines. And of course, at

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] drm/i915: Move intel_connector->unregister to connector->early_unregister

== Series Details == Series: series starting with [1/2] drm/i915: Move intel_connector->unregister to connector->early_unregister URL : https://patchwork.freedesktop.org/series/8825/ State : failure == Summary == Series 8825v1 Series without cover letter

[Intel-gfx] [PATCH v10b 5/6] drm/i915: Updated request structure tracing

From: John Harrison Added the '_complete' trace event which occurs when a fence/request is signaled as complete. Also moved the notify event from the IRQ handler code to inside the notify function itself. v3: Added the current ring seqno to the notify trace point.

[Intel-gfx] [PATCH v10b 4/6] drm/i915: Interrupt driven fences

From: John Harrison The intended usage model for struct fence is that the signalled status should be set on demand rather than polled. That is, there should not be a need for a 'signaled' function to be called everytime the status is queried. Instead, 'something'

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [1/7] drm: Automatically register/unregister all connectors

On Fri, Jun 17, 2016 at 10:12:00AM +0100, Chris Wilson wrote: > On Fri, Jun 17, 2016 at 08:47:04AM -, Patchwork wrote: > > == Series Details == > > > > Series: series starting with [1/7] drm: Automatically register/unregister > > all connectors > > URL :

[Intel-gfx] [PATCH 1/2] drm/i915: Move intel_connector->unregister to connector->early_unregister

We now have a connector->func that serves the same purpose as our own intel_connector->unregister vfunc allowing us to unwrap ourselves and use drm_connector_register() (and friends) as the central function. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 2/2] drm/i915: Move backlight unregistration to connector unregistration

Currently the backlight is being unregistered in the unload phase (after the display and its objects are unregistered). Move the backlight unregistration into the analogous phase by performing it from the connector unregistration, just prior to its deletion. Signed-off-by: Chris Wilson

[Intel-gfx] Prepare for automatic drm_connector_unregister_all()

In a planned drm-misc patchset, we make connector unregistering automatic from drm_drv_unregister(). This requires that we give up our own connector->unregister callback and use the DRM core's instead. See

Re: [Intel-gfx] Mouse cursor disappearing with SNA rendering

On Fri, Jun 17, 2016 at 06:12:16PM +0800, Daniel J Blueman wrote: > On 17 June 2016 at 17:18, Chris Wilson wrote: > > On Fri, Jun 17, 2016 at 05:08:55PM +0800, Daniel J Blueman wrote: > >> Hi all! > >> > >> When unlocking from lightdm, the mouse cursor isn't visible

[Intel-gfx] [PATCH igt] igt: Add test case for EXEC_OBJECT_ASYNC

The intention behind EXEC_OBJECT_ASYNC is to instruct the kernel to ignore implicit fences on the object but still maintain them for the GEM API. The user is expected to provide explicit fencing to maintain correct ordering of rendering. Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] Mouse cursor disappearing with SNA rendering

On 17 June 2016 at 17:18, Chris Wilson wrote: > On Fri, Jun 17, 2016 at 05:08:55PM +0800, Daniel J Blueman wrote: >> Hi all! >> >> When unlocking from lightdm, the mouse cursor isn't visible until >> switching VTs. This doesn't occur when using UXA rendering mode >>

Re: [Intel-gfx] [PATCH 37/38] drm/sti: Don't call drm_helper_disable_unused_functions

Acked-by: Benjamin Gaignard 2016-06-02 0:07 GMT+02:00 Daniel Vetter : > Atomic drivers are supposed to do hw/sw state reset with the > drm_mode_config_reset() call right above it. > > Cc: Benjamin Gaignard >

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Serialise presentation with imported dmabufs (rev3)

On Fri, Jun 17, 2016 at 09:02:24AM +0100, Chris Wilson wrote: > On Fri, Jun 17, 2016 at 07:54:17AM -, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: Serialise presentation with imported dmabufs (rev3) > > URL : https://patchwork.freedesktop.org/series/8689/ > > State :

Re: [Intel-gfx] Mouse cursor disappearing with SNA rendering

On Fri, Jun 17, 2016 at 05:08:55PM +0800, Daniel J Blueman wrote: > Hi all! > > When unlocking from lightdm, the mouse cursor isn't visible until > switching VTs. This doesn't occur when using UXA rendering mode > though, and affects a *lot* of people [1]. It occurs with a range of > kernels

Re: [Intel-gfx] [PATCH 6/7] drm/msm: Remove redundant calls to drm_connector_register_all()

On 06/17/2016 01:55 PM, Chris Wilson wrote: Up to now, the recommendation was for drivers to call drm_dev_register() followed by drm_connector_register_all(). Now that drm_connector_register() is safe against multiple invocations, we can move drm_connector_register_all() to drm_dev_register()

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [1/7] drm: Automatically register/unregister all connectors

On Fri, Jun 17, 2016 at 08:47:04AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/7] drm: Automatically register/unregister all > connectors > URL : https://patchwork.freedesktop.org/series/8814/ > State : warning > > == Summary == > > Series 8814v1 Series

[Intel-gfx] Mouse cursor disappearing with SNA rendering

Hi all! When unlocking from lightdm, the mouse cursor isn't visible until switching VTs. This doesn't occur when using UXA rendering mode though, and affects a *lot* of people [1]. It occurs with a range of kernels including 4.6.2. I'm using xserver-xorg-video-intel

  1   2   >