[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: fix out-of-bounds page_table access (rev2)

== Series Details == Series: drm/i915: fix out-of-bounds page_table access (rev2) URL : https://patchwork.freedesktop.org/series/9148/ State : warning == Summary == Series 9148v2 drm/i915: fix out-of-bounds page_table access

[Intel-gfx] [drm-intel:for-linux-next 5/22] drivers/gpu/drm/i915/i915_drv.h:3612:48: error: parameter name omitted

tree: git://anongit.freedesktop.org/drm-intel for-linux-next head: 883445d43e45ddc5ef19274a169a1aa603428ab6 commit: 1dac891c1c95a8528f3558b481fbb9a45d653619 [5/22] drm/i915: Register debugfs interface last config: x86_64-randconfig-s2-06251012 (attached as .config) compiler: gcc-6 (Debian

Re: [Intel-gfx] [PATCH 1/2] intel: Add more Kabylake PCI IDs.

On Fri, 2016-06-24 at 22:42 +, Pandiyan, Dhinakaran wrote: > On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote: > > > > The spec has been updated adding new PCI IDs. > > > > Signed-off-by: Rodrigo Vivi > > --- > >  intel/intel_chipset.h | 14 ++ > >  1

Re: [Intel-gfx] [PATCH 1/2] intel: Add more Kabylake PCI IDs.

On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote: > The spec has been updated adding new PCI IDs. > > Signed-off-by: Rodrigo Vivi > --- > intel/intel_chipset.h | 14 ++ > 1 file changed, 10 insertions(+), 4 deletions(-) > > diff --git

Re: [Intel-gfx] [PATCH 1/2] pciids: Add more Kabylake PCI IDs.

On Fri, 2016-06-24 at 15:20 -0700, Dhinakaran Pandiyan wrote: > On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote: > > The spec has been updated adding new PCI IDs. > > > > Signed-off-by: Rodrigo Vivi > > --- > > src/i915_pciids.h | 3 +++ > > 1 file changed, 3

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add more Kabylake PCI IDs.

On Fri, 2016-06-24 at 22:06 +, Pandiyan, Dhinakaran wrote: > On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote: > > The spec has been updated adding new PCI IDs. > > > > Signed-off-by: Rodrigo Vivi > > --- > > include/drm/i915_pciids.h | 3 +++ > > 1 file

Re: [Intel-gfx] [PATCH 1/2] pciids: Add more Kabylake PCI IDs.

On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote: > The spec has been updated adding new PCI IDs. > > Signed-off-by: Rodrigo Vivi > --- > src/i915_pciids.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/src/i915_pciids.h b/src/i915_pciids.h > index

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add more Kabylake PCI IDs.

On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote: > The spec has been updated adding new PCI IDs. > > Signed-off-by: Rodrigo Vivi > --- > include/drm/i915_pciids.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/include/drm/i915_pciids.h

[Intel-gfx] Ignore these, sorry!

Sorry about that; I accidentally did a git send-email with some older patches leftover in my patch folder. Just ignore this thread On Fri, 2016-06-24 at 17:45 -0400, Lyude wrote: > Latest version of: > > https://lists.freedesktop.org/archives/intel-gfx/2016-June/098787.htm > l > > The only

[Intel-gfx] [PATCH v6 0/4] Fixes for HPD

Latest version of: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098787.html The only patch that's changed here is 4/4, the rest are just being sent so that they can be in one thread to make things easier for reviewers Lyude (4): drm/i915/vlv: Make intel_crt_reset() per-encoder

[Intel-gfx] [PATCH v6 2/4] 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 v6 1/4] 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ä Acked-by: Daniel Vetter Signed-off-by: Lyude

Re: [Intel-gfx] [PATCH] drm/i915/skl: Increase cursor ddb blocks in multi-pipe config

Thanks for the input Rodrigo, Arthur. I will update commit message and repost the patch. Thanks, Radhakrishna Sripada -Original Message- From: Runyan, Arthur J Sent: Thursday, June 23, 2016 1:04 PM To: Rodrigo Vivi Cc: Sripada, Radhakrishna

Re: [Intel-gfx] [PATCH 3/3] drm/i915/psr: Do not activate PSR when vblank interrupts are enabled

On Wed, 2016-06-15 at 21:44 +, Vivi, Rodrigo wrote: > On Wed, 2016-06-15 at 01:02 +, Pandiyan, Dhinakaran wrote: > > On Tue, 2016-06-14 at 00:09 +, Vivi, Rodrigo wrote: > > > On Wed, 2016-06-08 at 18:46 -0700, Dhinakaran Pandiyan wrote: > > > > PSR in CHV, unlike HSW, can get activated

[Intel-gfx] [PATCH] drm/i915: tweak gen6_for_{each_pde, all_pdes} macros

Gen8 versions of these macros were updated a few months ago (e8ebd8e drm/i915: eliminate 'temp' in gen8_for_each macros) originally because at least one iterator could generate an out of bounds access, but also because eliminating the 'temp' parameter generated smaller and faster code. Matthew

Re: [Intel-gfx] [PATCH] drm/i915: fix out-of-bounds page_table access

On 24/06/16 17:37, Chris Wilson wrote: On Fri, Jun 24, 2016 at 05:04:46PM +0100, Matthew Auld wrote: The gen6_for_all_pdes macro does the upper-bound evaluation after accessing the page_table array, hence on the final iteration we end up hitting an out-of-bounds error: [ 1023.831657] UBSAN:

Re: [Intel-gfx] [PATCH] drm/i915: fix out-of-bounds page_table access

On Fri, Jun 24, 2016 at 05:04:46PM +0100, Matthew Auld wrote: > The gen6_for_all_pdes macro does the upper-bound evaluation after > accessing the page_table array, hence on the final iteration we end up > hitting an out-of-bounds error: > > [ 1023.831657] UBSAN: Undefined behaviour in >

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: fix out-of-bounds page_table access

== Series Details == Series: drm/i915: fix out-of-bounds page_table access URL : https://patchwork.freedesktop.org/series/9148/ State : success == Summary == Series 9148v1 drm/i915: fix out-of-bounds page_table access http://patchwork.freedesktop.org/api/1.0/series/9148/revisions/1/mbox Test

[Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [1/3] drm/i915: Preserve current RPS frequency across init

== Series Details == Series: series starting with [1/3] drm/i915: Preserve current RPS frequency across init URL : https://patchwork.freedesktop.org/series/9146/ State : warning == Summary == Series 9146v1 Series without cover letter

[Intel-gfx] [PATCH] drm/i915: fix out-of-bounds page_table access

The gen6_for_all_pdes macro does the upper-bound evaluation after accessing the page_table array, hence on the final iteration we end up hitting an out-of-bounds error: [ 1023.831657] UBSAN: Undefined behaviour in drivers/gpu/drm/i915/i915_gem_gtt.c:1993:2 [ 1023.831680] index 512 is out of

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915/guc: don't ever forward VBlank to the GuC

== Series Details == Series: drm/i915/guc: don't ever forward VBlank to the GuC URL : https://patchwork.freedesktop.org/series/9145/ State : success == Summary == Series 9145v1 drm/i915/guc: don't ever forward VBlank to the GuC

[Intel-gfx] [PATCH 2/3] drm/i915: Remove superfluous powersave work flushing

Instead of flushing the outstanding enabling, remember the requested frequency to apply when the powersave work runs. Signed-off-by: Chris Wilson Cc: Ville Syrjälä --- drivers/gpu/drm/i915/i915_debugfs.c | 30 ++

[Intel-gfx] [PATCH 3/3] drm/i915: Defer enabling rc6 til after we submit the first batch/context

Some hardware requires a valid render context before it can initiate rc6 power gating of the GPU; the default state of the GPU is not sufficient and may lead to undefined behaviour. The first execution of any batch will load the "golden render state", at which point it is safe to enable rc6. As we

[Intel-gfx] [PATCH 1/3] drm/i915: Preserve current RPS frequency across init

Select idle frequency during initialisation, then reset the last known frequency when re-enabling. This allows us to preserve the user selected frequency across resets. v2: Stop CHV from overriding the user's choice in cherryview_enable_rps() Signed-off-by: Chris Wilson

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,1/7] drm/i915: Skip idling an idle engine

== Series Details == Series: series starting with [CI,1/7] drm/i915: Skip idling an idle engine URL : https://patchwork.freedesktop.org/series/9141/ State : failure == Summary == Series 9141v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/9141/revisions/1/mbox

[Intel-gfx] [PATCH v3] drm/i915/guc: don't ever forward VBlank to the GuC

If a context waiting for VBlank were switched out, switching in the next context and generating a CSB event in the process, then the GuC would have to put the context back in the queue, and then observe the subsequent VBlank interrupt so that it could resubmit the suspended context. However, we

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915: Fill unused GGTT with scratch pages for VT-d

== Series Details == Series: drm/i915: Fill unused GGTT with scratch pages for VT-d URL : https://patchwork.freedesktop.org/series/9140/ State : success == Summary == Series 9140v1 drm/i915: Fill unused GGTT with scratch pages for VT-d

[Intel-gfx] [CI 6/7] drm/i915: Split idling from forcing context switch

We only need to force a switch to the kernel context placeholder during eviction. All other uses of i915_gpu_idle() just want to wait until existing work on the GPU is idle. Rename i915_gpu_idle() to i915_gem_wait_for_idle() to avoid any implications about "parking" the context first. v2: Tweak

[Intel-gfx] [CI 7/7] drm/i915: Only switch to default context when evicting from GGTT

The contexts only pin space within the global GTT. Therefore forcing the switch to the perma-pinned kernel context only has an effect when trying to evict from and find room within the global GTT. We can then restrict the switch to only when operating on the default context. This is mostly a no-op

[Intel-gfx] [CI 4/7] drm/i915: Mark all default contexts as uninitialised after context loss

When the GPU is reset or state lost through suspend, every default legacy context needs to reload their state - both the golden render state and the L3 mapping. Only context images explicitly saved to memory (i.e. all execlists and non-default legacy contexts) will retain their state across the

[Intel-gfx] [CI 1/7] drm/i915: Skip idling an idle engine

During suspend (or module unload), if we have never accessed the engine (i.e. userspace never submitted a batch to it), the engine is idle. Then we attempt to idle the engine by forcing it to the default context, which actually means we submit a render batch to setup the golden context state and

[Intel-gfx] [CI 5/7] drm/i915: No need to wait for idle on L3 remap

As the L3 remapping is applied before the next execution, there is no need to wait until all previous uses are idle, the application will not occur any sooner. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Reviewed-by: Mika

[Intel-gfx] [CI 2/7] drm/i915: Move legacy kernel context pinning to intel_ringbuffer.c

This is so that we have symmetry with intel_lrc.c and avoid a source of if (i915.enable_execlists) layering violation within i915_gem_context.c - that is we move the specific handling of the dev_priv->kernel_context for legacy submission into the legacy submission code. This depends upon the

[Intel-gfx] [CI 3/7] drm/i915: Treat kernel context as initialised

The kernel context exists simply as a placeholder and should never be executed with a render context. It does not need the golden render state, as that will always be applied to a user context. By skipping the initialisation we can avoid issues in attempting to program the golden render context

Re: [Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [CI,01/15] drm/i915: Move panel's backlight setup next to panel init

On Fri, Jun 24, 2016 at 01:33:34PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,01/15] drm/i915: Move panel's backlight > setup next to panel init > URL : https://patchwork.freedesktop.org/series/9138/ > State : success > > == Summary == > > Series

[Intel-gfx] ✓ Ro.CI.BAT: success for series starting with [CI,01/15] drm/i915: Move panel's backlight setup next to panel init

== Series Details == Series: series starting with [CI,01/15] drm/i915: Move panel's backlight setup next to panel init URL : https://patchwork.freedesktop.org/series/9138/ State : success == Summary == Series 9138v1 Series without cover letter

[Intel-gfx] ✓ Ro.CI.BAT: success for Revert "drm/i915: Use atomic commits for legacy page_flips"

== Series Details == Series: Revert "drm/i915: Use atomic commits for legacy page_flips" URL : https://patchwork.freedesktop.org/series/9137/ State : success == Summary == Series 9137v1 Revert "drm/i915: Use atomic commits for legacy page_flips"

[Intel-gfx] [PATCH] drm/i915: Fill unused GGTT with scratch pages for VT-d

One of the numerous VT-d workarounds we require is that the display hardware reads past the end of the buffer triggering VT-d faults. This is acknowledged in the code as being safe "since we fill the unused portions of the GGTT with the scratch page". Alas, that is no longer always true and so we

[Intel-gfx] [CI 08/15] drm/i915: Remove redundant drm_connector_register_all()

drm_connector_register_all() is now automatically called by drm_dev_register(), and so we no longer have to do so ourselves (via intel_modeset_register() after calling drm_dev_register()). Similarly for unregistering. Signed-off-by: Chris Wilson Reviewed-by: Daniel

[Intel-gfx] [CI 07/15] drm/i915: Demidlayer driver unloading

To complete the transition to manual control of load/unload, we need to take over unloading from i915_pci_remove(). This allows us to correctly order our unregister vs shutdown phases, which currently are inverted due to the midlayer. However, the unload sequence is still invalid as we shutdown

[Intel-gfx] [CI 13/15] drm/i915: Fix misleading driver debug message

From: Frank Binns Stop claiming that UMS support is disabled when it's not actually supported anymore. Signed-off-by: Frank Binns Reviewed-by: Chris Wilson Signed-off-by: Chris Wilson Link:

[Intel-gfx] [CI 04/15] drm/i915: Move connector registration to driver registration

Defer connector registration from during construction to the driver registration phase. This is important for ordering the action correctly, e.g. not using debugfs before it is ready. Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter ---

[Intel-gfx] [CI 09/15] drm/i915: Start exploiting drm_device subclassing

Baby step, update to_i915() conversion from drm_device to drm_i915_private: textdata bss dec hex filename 1108812 23207 416 1132435 114793 i915.ko (before) 1104999 23207 416 1128622 1138ae i915.ko (after) Signed-off-by: Chris Wilson Cc:

[Intel-gfx] [CI 11/15] drm/i915: Remove user controllable DRM_ERROR for i915_getparam()

The GETPARAM ioctl writes to a user supplied address. If that address is invalid, it is the user's error and not the driver's, so quietly report EFAULT and don't blame ourselves with a DRM_ERROR. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin

[Intel-gfx] [CI 14/15] drm/i915: Split out the PCI driver interface to i915_pci.c

To reclaim a bit of space from i915_drv.c, we can move the routines that just hook us into the PCI device tree into i915_pci.c Signed-off-by: Chris Wilson Cc: Daniel Vetter Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [CI 05/15] drm/i915: Register debugfs interface last

Currently debugfs files are created before the driver is even loads. This gives the opportunity for userspace to open that interface and poke around before the backing data structures are initialised - with the possibility of oopsing or worse. Move the creation of the debugfs files to our

[Intel-gfx] [CI 06/15] drm/i915: Demidlayer driver loading

Take control over allocating, loading and registering the driver from the DRM midlayer by performing it manually from i915_pci_probe. This allows us to carefully control the order of when we setup the hardware vs when it becomes visible to third parties (including userspace). The current ordering

[Intel-gfx] [CI 12/15] drm/i915: Remove user controllable DRM_ERROR for intel_get_pipe_from_crtc_id()

Don't emit a driver DRM_ERROR for a user passing in an invalid CRTC id, simply report it is missing back to the user. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_display.c | 5 + 1 file changed,

[Intel-gfx] [CI 03/15] drm/i915: Move backlight registration to connector registration

Currently the backlight is being registered in the load phase (before the display and its objects are registered). Move the backlight registration into the analogous phase by performing it from the connector registration, just after its creation. Signed-off-by: Chris Wilson

[Intel-gfx] [CI 15/15] drm/i915: Move module init/exit to i915_pci.c

The module init/exit routines are a wrapper around the PCI device init/exit, so move them across. Note that in order to avoid exporting the driver struct, instead of manipulating driver.features inside i915_init we instead opt to simply exit if i915.modeset is disabled. Signed-off-by: Chris

[Intel-gfx] [CI 02/15] drm/i915: Move registration actions to connector->late_register

With the introduction of a connector->func for callback from drm_connector_register() we can move all the tasks that we want to do upon registration into that callback. Later, this will allow us to reorder the registration and defer it until after the device is setup and ready for userspace.

[Intel-gfx] [CI 01/15] drm/i915: Move panel's backlight setup next to panel init

Currently setting up the backlight for a panel is sometimes done together with initialising the panel, and sometimes after the connector is registered. The backlight setup does not depend upon connector registration (i.e. access to sysfs/debugfs and the kobject hierachy) so perform it consistently

[Intel-gfx] [PATCH] Revert "drm/i915: Use atomic commits for legacy page_flips"

This reverts commit ee042aa40b66d18d465206845b0752c6a617ba3f. Something appears to be off in the timing, but as far as I can tell it is not along the event delivery path. The net effect appears to be rendering flicker (the current render buffer appears on the scanout, with what appears to be

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

On Fri, Jun 24, 2016 at 12:48:17PM +0100, Steven Newbury wrote: > On Fri, 2016-06-24 at 11:59 +0100, Chris Wilson wrote: > > On Thu, Jun 23, 2016 at 02:14:12PM +0100, Steven Newbury wrote: > > > On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote: > > > > On Thu, 23 Jun 2016, Steven Newbury

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

On Fri, 2016-06-24 at 11:59 +0100, Chris Wilson wrote: > On Thu, Jun 23, 2016 at 02:14:12PM +0100, Steven Newbury wrote: > > On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote: > > > On Thu, 23 Jun 2016, Steven Newbury > > > wrote: > > > > I'm seeing this on my IvyBridge.

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Small compaction of the engine init code (rev4)

On 24/06/16 11:11, Patchwork wrote: == Series Details == Series: drm/i915: Small compaction of the engine init code (rev4) URL : https://patchwork.freedesktop.org/series/9053/ State : failure == Summary == Series 9053v4 drm/i915: Small compaction of the engine init code

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

On Thu, Jun 23, 2016 at 02:14:12PM +0100, Steven Newbury wrote: > On Thu, 2016-06-23 at 15:59 +0300, Jani Nikula wrote: > > On Thu, 23 Jun 2016, Steven Newbury wrote: > > > I'm seeing this on my IvyBridge.  I'll try reverting the commit > > > here > > > too, to see if it's

Re: [Intel-gfx] [PATCH] drm/i915: Fix misleading driver debug message

On Fri, Jun 24, 2016 at 11:23:56AM +0100, Frank Binns wrote: > Stop claiming that UMS support is disabled when it's not actually > supported anymore. > > Signed-off-by: Frank Binns But not technically untrue! Reviewed-by: Chris Wilson Since I

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] pciids: Add more Kabylake PCI IDs.

== Series Details == Series: series starting with [1/2] pciids: Add more Kabylake PCI IDs. URL : https://patchwork.freedesktop.org/series/9105/ State : failure == Summary == Series 9105v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/9105/revisions/1/mbox Test

[Intel-gfx] [PATCH] drm/i915: Fix misleading driver debug message

Stop claiming that UMS support is disabled when it's not actually supported anymore. Signed-off-by: Frank Binns --- drivers/gpu/drm/i915/i915_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] i956: Add more Kabylake PCI IDs.

== Series Details == Series: series starting with [1/2] i956: Add more Kabylake PCI IDs. URL : https://patchwork.freedesktop.org/series/9104/ State : failure == Summary == Applying: i956: Add more Kabylake PCI IDs. fatal: sha1 information is lacking or useless

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] lib/intel_chipset: Add more Kabylake PCI IDs.

== Series Details == Series: series starting with [1/2] lib/intel_chipset: Add more Kabylake PCI IDs. URL : https://patchwork.freedesktop.org/series/9103/ State : failure == Summary == Applying: lib/intel_chipset: Add more Kabylake PCI IDs. fatal: sha1 information is lacking or useless

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] intel: Add more Kabylake PCI IDs.

== Series Details == Series: series starting with [1/2] intel: Add more Kabylake PCI IDs. URL : https://patchwork.freedesktop.org/series/9102/ State : failure == Summary == Applying: intel: Add more Kabylake PCI IDs. fatal: sha1 information is lacking or useless (intel/intel_chipset.h).

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,01/14] drm/i915: Move panel's backlight setup next to panel init

== Series Details == Series: series starting with [CI,01/14] drm/i915: Move panel's backlight setup next to panel init URL : https://patchwork.freedesktop.org/series/9119/ State : failure == Summary == Series 9119v1 Series without cover letter

[Intel-gfx] ✗ Ro.CI.BAT: failure for Add two-stage watermark programming for VLV/CHV (v5)

== Series Details == Series: Add two-stage watermark programming for VLV/CHV (v5) URL : https://patchwork.freedesktop.org/series/9079/ State : failure == Summary == Series 9079v1 Add two-stage watermark programming for VLV/CHV (v5)

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Small compaction of the engine init code (rev4)

== Series Details == Series: drm/i915: Small compaction of the engine init code (rev4) URL : https://patchwork.freedesktop.org/series/9053/ State : failure == Summary == Series 9053v4 drm/i915: Small compaction of the engine init code

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] drm/i915: Add more Kabylake PCI IDs.

== Series Details == Series: series starting with [1/2] drm/i915: Add more Kabylake PCI IDs. URL : https://patchwork.freedesktop.org/series/9101/ State : failure == Summary == Series 9101v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/9101/revisions/1/mbox Test

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Small compaction of the engine init code (rev3)

== Series Details == Series: drm/i915: Small compaction of the engine init code (rev3) URL : https://patchwork.freedesktop.org/series/9053/ State : failure == Summary == Series 9053v3 drm/i915: Small compaction of the engine init code

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/atomic: Make drm_atomic_legacy_backoff reset crtc->acquire_ctx

== Series Details == Series: drm/atomic: Make drm_atomic_legacy_backoff reset crtc->acquire_ctx URL : https://patchwork.freedesktop.org/series/9077/ State : failure == Summary == Series 9077v1 drm/atomic: Make drm_atomic_legacy_backoff reset crtc->acquire_ctx

Re: [Intel-gfx] [drm:intel_set_cpu_fifo_underrun_reporting]

On 16-06-13 15:35:51, Petko Manolov wrote: > On 16-06-13 13:29:46, Petko Manolov wrote: > > Hello guys, > > > > Running xorg on my Lenovo Yoga 2 Pro (MY2013) on recent kernels turn into a > > major PITA. After a couple of minutes the screen starts to flicker and > > only > > killing xorg

[Intel-gfx] [CI 14/14] drm/i915: Move module init/exit to i915_pci.c

The module init/exit routines are a wrapper around the PCI device init/exit, so move them across. Note that in order to avoid exporting the driver struct, instead of manipulating driver.features inside i915_init we instead opt to simply exit if i915.modeset is disabled. Signed-off-by: Chris

[Intel-gfx] [CI 13/14] drm/i915: Split out the PCI driver interface to i915_pci.c

To reclaim a bit of space from i915_drv.c, we can move the routines that just hook us into the PCI device tree into i915_pci.c Signed-off-by: Chris Wilson Cc: Daniel Vetter Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [CI 11/14] drm/i915: Remove user controllable DRM_ERROR for i915_getparam()

The GETPARAM ioctl writes to a user supplied address. If that address is invalid, it is the user's error and not the driver's, so quietly report EFAULT and don't blame ourselves with a DRM_ERROR. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin

[Intel-gfx] [CI 06/14] drm/i915: Demidlayer driver loading

Take control over allocating, loading and registering the driver from the DRM midlayer by performing it manually from i915_pci_probe. This allows us to carefully control the order of when we setup the hardware vs when it becomes visible to third parties (including userspace). The current ordering

[Intel-gfx] [CI 08/14] drm/i915: Remove redundant drm_connector_register_all()

drm_connector_register_all() is now automatically called by drm_dev_register(), and so we no longer have to do so ourselves (via intel_modeset_register() after calling drm_dev_register()). Similarly for unregistering. Signed-off-by: Chris Wilson Reviewed-by: Daniel

[Intel-gfx] [CI 07/14] drm/i915: Demidlayer driver unloading

To complete the transition to manual control of load/unload, we need to take over unloading from i915_pci_remove(). This allows us to correctly order our unregister vs shutdown phases, which currently are inverted due to the midlayer. However, the unload sequence is still invalid as we shutdown

[Intel-gfx] [CI 02/14] drm/i915: Move registration actions to connector->late_register

With the introduction of a connector->func for callback from drm_connector_register() we can move all the tasks that we want to do upon registration into that callback. Later, this will allow us to reorder the registration and defer it until after the device is setup and ready for userspace.

[Intel-gfx] [CI 09/14] drm/i915: Start exploiting drm_device subclassing

Baby step, update to_i915() conversion from drm_device to drm_i915_private: textdata bss dec hex filename 1108812 23207 416 1132435 114793 i915.ko (before) 1104999 23207 416 1128622 1138ae i915.ko (after) Signed-off-by: Chris Wilson Cc:

[Intel-gfx] [CI 05/14] drm/i915: Register debugfs interface last

Currently debugfs files are created before the driver is even loads. This gives the opportunity for userspace to open that interface and poke around before the backing data structures are initialised - with the possibility of oopsing or worse. Move the creation of the debugfs files to our

[Intel-gfx] [CI 12/14] drm/i915: Remove user controllable DRM_ERROR for intel_get_pipe_from_crtc_id()

Don't emit a driver DRM_ERROR for a user passing in an invalid CRTC id, simply report it is missing back to the user. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_display.c | 5 + 1 file changed,

[Intel-gfx] [CI 03/14] drm/i915: Move backlight registration to connector registration

Currently the backlight is being registered in the load phase (before the display and its objects are registered). Move the backlight registration into the analogous phase by performing it from the connector registration, just after its creation. Signed-off-by: Chris Wilson

[Intel-gfx] [CI 01/14] drm/i915: Move panel's backlight setup next to panel init

Currently setting up the backlight for a panel is sometimes done together with initialising the panel, and sometimes after the connector is registered. The backlight setup does not depend upon connector registration (i.e. access to sysfs/debugfs and the kobject hierachy) so perform it consistently

[Intel-gfx] [CI 04/14] drm/i915: Move connector registration to driver registration

Defer connector registration from during construction to the driver registration phase. This is important for ordering the action correctly, e.g. not using debugfs before it is ready. Signed-off-by: Chris Wilson Reviewed-by: Daniel Vetter ---