[Intel-gfx] ✓ Fi.CI.BAT: success for overlay: fix debugfs path when debugfs mounted on path '/debug'

== Series Details == Series: overlay: fix debugfs path when debugfs mounted on path '/debug' URL : https://patchwork.freedesktop.org/series/35012/ State : success == Summary == IGT patchset tested on top of latest successful build 1db12466cb5ad8483cd469753d2e312a62d717b7 meson: build a full

[Intel-gfx] [PATCH i-g-t] overlay: fix debugfs path when debugfs mounted on path '/debug'

From: Changbin Du It mistakenly set debugfs root path to "/debug/dri", so correct it. Signed-off-by: Changbin Du --- overlay/debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/overlay/debugfs.c b/overlay/debugfs.c index

Re: [Intel-gfx] [PATCH v4 4/9] drm: Add some HDCP related #defines

Looks Good to me. Reviewed-by: Ramalingam C -Ram On Thursday 07 December 2017 05:30 AM, Sean Paul wrote: In preparation for implementing HDCP in i915, add some HDCP related register offsets and defines. The dpcd register offsets will go in drm_dp_helper.h whereas the

Re: [Intel-gfx] [PATCH v4 5/9] drm/i915: Add HDCP framework + base implementation

As v3 implementation removes the mode set from the path of HDCP state change, IMO that would have been preferred until we have the ville's changes mentioned by daniel. Now once again modeset is brought back :( And have we already thought about holding the modeset lock for 5+ Sec for HDCP

[Intel-gfx] [PATCH 0/3] mmio save restore refine in vgpu switch

Merge switch_mmio_to_vgpu and switch_mmio_to_host, use delta update for mocs save restore, deal host mocs value as fixed, it won't be changed after initialization. These can save vgpu switch time to reduce CPU utilization and improve GPU performance in GVT-g with multi-VMs. Weinan Li (3):

[Intel-gfx] [PATCH 1/3] drm/i915/gvt: optimize for vGPU mmio switch

now mmio switch between vGPUs need to switch to host first then to expected vGPU, it waste one time mmio save/restore. r/w mmio usually is time-consuming, and there are so many mocs registers need to save/restore during vGPU switch. Combine the switch_to_host and switch_to_vgpu can reduce 1 time

[Intel-gfx] [PATCH 3/3] drm/i915/gvt: load host render mocs once in mocs switch

Load host render mocs registers once for delta update of mocs switch, it reduces mmio read times obviously, then brings performance improvement during multi-vms switch. Signed-off-by: Weinan Li --- drivers/gpu/drm/i915/gvt/render.c | 51

[Intel-gfx] [PATCH 2/3] drm/i915/gvt: refine mocs save restore policy

Save and restore the mocs regs of one VM in GVT-g burning too much CPU utilization. Add LRI command scan to monitor the change of mocs registers, save the state in vreg, and use delta update policy to restore them. It can obviously reduce the MMIO r/w count, and improve the performance of context

[Intel-gfx] [lkp-robot] [lib/rbtree, drm/mm] 3e6e51217d: WARNING:at_lib/stackdepot.c:#depot_save_stack

FYI, we noticed the following commit (built with gcc-7): commit: 3e6e51217dd14dcda10d4bc9a38b1440e2d42c14 ("lib/rbtree,drm/mm: Add rbtree_replace_node_cached()") git://anongit.freedesktop.org/drm-intel topic/core-for-CI in testcase: trinity with following parameters: runtime: 300s

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/4] lib: copy intel_aub.h from libdrm

== Series Details == Series: series starting with [1/4] lib: copy intel_aub.h from libdrm URL : https://patchwork.freedesktop.org/series/34999/ State : warning == Summary == Test pm_rc6_residency: Subgroup rc6-accuracy: pass -> SKIP (shard-snb) Test

Re: [Intel-gfx] [PATCH v4 9/9] drm/i915: Implement HDCP for DisplayPort

Thanks for handling the reauth req from downstream. you might want to fix the missed single occurance of "//" On Thursday 07 December 2017 05:30 AM, Sean Paul wrote: This patch adds HDCP support for DisplayPort connectors by implementing the intel_hdcp_shim. Most of this is straightforward

[Intel-gfx] ✗ Fi.CI.BAT: failure for mmio save restore refine in vgpu switch

== Series Details == Series: mmio save restore refine in vgpu switch URL : https://patchwork.freedesktop.org/series/35011/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h CHK

Re: [Intel-gfx] [PATCH v4 8/9] drm/i915: Implement HDCP for HDMI

On Thursday 07 December 2017 05:30 AM, Sean Paul wrote: This patch adds HDCP support for HDMI connectors by implementing the intel_hdcp_shim. Nothing too special, just a bunch of DDC reads/writes. Changes in v2: - Rebased on drm-intel-next Changes in v3: - Initialize new worker Changes in

Re: [Intel-gfx] [PATCH v4 0/9] drm/i915: Implement HDCP

Sean, Could you please share the level of functional testing is done on this code? like with Receiver/Repeaters and port type tested (DP/HDMI/DP over USB TypeC ?) Whether Compliance test is attempted on this code? Thanks -Ram On Thursday 07 December 2017 05:30 AM, Sean Paul wrote:

[Intel-gfx] [PATCH i-g-t] lib/rendercopy: Refactoring rendercopy libraries

Current implementation of those libraries is not alligned with our coding style. Some methods were copied from other gens and were only renamed. This patch is fixing those. No functional changes were made. Signed-off-by: Lukasz Kalamarz Cc: Arkadiusz Hiler

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture (rev2)

== Series Details == Series: drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture (rev2) URL : https://patchwork.freedesktop.org/series/34969/ State : success == Summary == Series 34969v2 drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture

Re: [Intel-gfx] [PATCH igt 2/2] igt/debugfs_tests: Record which file is being opened in kmsg

Quoting Tvrtko Ursulin (2017-12-06 16:51:24) > > On 06/12/2017 16:38, Chris Wilson wrote: > > When tracking down the cause of a particular kernel warning, knowing > > which file it is associated with can be a big clue. So write the > > filename into the kernel message log prior to opening it. > >

[Intel-gfx] ✓ Fi.CI.BAT: success for lib/rendercopy: Refactoring rendercopy libraries

== Series Details == Series: lib/rendercopy: Refactoring rendercopy libraries URL : https://patchwork.freedesktop.org/series/34972/ State : success == Summary == IGT patchset tested on top of latest successful build 1db12466cb5ad8483cd469753d2e312a62d717b7 meson: build a full dependency for

[Intel-gfx] [PATCH 06/10] drm/i915: make reserved struct resource centric

Now that we are using struct resource to track the stolen region, it is more convenient if we track the reserved portion of that region in a resource as well. v2: s/<= end + 1/< end/ (Chris) v3: prefer DEFINE_RES_MEM Signed-off-by: Matthew Auld Cc: Joonas Lahtinen

[Intel-gfx] [PATCH 08/10] drm/i915: give stolen_usable_size a more suitable home

Kick it out of i915_ggtt and keep it grouped with dsm and dsm_reserved, where it makes the most sense. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Chris Wilson Cc: Paulo Zanoni

[Intel-gfx] [PATCH 07/10] drm/i915: make mappable struct resource centric

Now that we are using struct resource to track the stolen region, it is more convenient if we track the mappable region in a resource as well. v2: prefer iomap and gmadr naming scheme prefer DEFINE_RES_MEM Signed-off-by: Matthew Auld Cc: Joonas Lahtinen

[Intel-gfx] [PATCH 05/10] drm/i915: make dsm struct resource centric

Now that we are using struct resource to track the stolen region, it is more convenient if we track dsm in a resource as well. v2: check range_overflow when writing to 32b registers (Chris) pepper in some comments (Chris) v3: refit i915_stolen_to_dma() v4: kill ggtt->stolen_size

[Intel-gfx] [PATCH 04/10] drm/i915: nuke the duplicated stolen discovery

We duplicate the stolen discovery code in early-quirks and in i915, however now that the stolen region is exported as a resource from early-quirks we can nuke the duplication. v2: check overflows_type Signed-off-by: Matthew Auld Cc: Joonas Lahtinen

[Intel-gfx] [PATCH 10/10] drm/i915: prefer stolen_usable_size for the range sanity check

In i915_pages_create_for_stolen it probably makes more sense to check if the range overflows the stolen_usable_size, since the size of dsm will also include the reserved portion which we can't touch. Signed-off-by: Matthew Auld Cc: Joonas Lahtinen

[Intel-gfx] [PATCH 03/10] x86/early-quirks: reverse the if ladders

Makes things a little easier to follow. Suggested-by: Ville Syrjälä Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Ville Syrjälä Cc: Chris Wilson

[Intel-gfx] [PATCH 09/10] drm/i915: prefer resource_size_t for everything stolen

Keeps things consistent now that we make use of struct resource. This should keep us covered in case we ever get huge amounts of stolen memory. v2: bunch of missing conversions (Chris) Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc:

Re: [Intel-gfx] [PATCH 05/10] drm/i915: make dsm struct resource centric

Quoting Matthew Auld (2017-12-06 18:17:25) > Now that we are using struct resource to track the stolen region, it is > more convenient if we track dsm in a resource as well. > > v2: check range_overflow when writing to 32b registers (Chris) > pepper in some comments (Chris) > v3: refit

Re: [Intel-gfx] [PATCH 10/10] drm/i915: prefer stolen_usable_size for the range sanity check

Quoting Matthew Auld (2017-12-06 18:17:30) > In i915_pages_create_for_stolen it probably makes more sense to check if > the range overflows the stolen_usable_size, since the size of dsm will also > include the reserved portion which we can't touch. > > Signed-off-by: Matthew Auld

Re: [Intel-gfx] [PATCH 01/10] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

Quoting Matthew Auld (2017-12-06 18:17:21) > From: Joonas Lahtinen > > To give upcoming SKU BIOSes more flexibility in placing the Intel > graphics stolen memory, make all variables storing the placement or size > compatible with full 64 bit range. Also by

Re: [Intel-gfx] [PATCH i-g-t v8] tests/kms_frontbuffer_tracking: Including DRRS test coverage

Em Qua, 2017-12-06 às 20:43 +0530, Lohith BS escreveu: > Dynamic Refresh Rate Switch(DRRS) is used to switch the panel's > refresh rate to the lowest vrefresh supported by panel, when frame is > not flipped for more than a Sec. > > In kernel, DRRS uses the front buffer tracking infrastructure. >

Re: [Intel-gfx] [PATCH 08/10] drm/i915: give stolen_usable_size a more suitable home

Quoting Matthew Auld (2017-12-06 18:17:28) > Kick it out of i915_ggtt and keep it grouped with dsm and dsm_reserved, > where it makes the most sense. > > Signed-off-by: Matthew Auld > Cc: Joonas Lahtinen > Cc: Chris Wilson

[Intel-gfx] ✓ Fi.CI.BAT: success for make stolen resource centric (rev5)

== Series Details == Series: make stolen resource centric (rev5) URL : https://patchwork.freedesktop.org/series/34256/ State : success == Summary == Series 34256v5 make stolen resource centric https://patchwork.freedesktop.org/api/1.0/series/34256/revisions/5/mbox/ Test gem_mmap_gtt:

[Intel-gfx] [PATCH i-g-t] lib/igt_sysfs: Let igt_sysfs_read|write return -errno

In some cases debugfs or sysfs may return errors that we want to check. Return -errno from helper functions to make asserts easier. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Joonas Lahtinen ---

[Intel-gfx] ✗ Fi.CI.BAT: failure for lib/igt_sysfs: Let igt_sysfs_read|write return -errno

== Series Details == Series: lib/igt_sysfs: Let igt_sysfs_read|write return -errno URL : https://patchwork.freedesktop.org/series/34989/ State : failure == Summary == IGT patchset tested on top of latest successful build 1db12466cb5ad8483cd469753d2e312a62d717b7 meson: build a full dependency

[Intel-gfx] [PATCH 01/10] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

From: Joonas Lahtinen To give upcoming SKU BIOSes more flexibility in placing the Intel graphics stolen memory, make all variables storing the placement or size compatible with full 64 bit range. Also by exporting the stolen region as a resource, we can then nuke

[Intel-gfx] [PATCH 00/10] make stolen resource centric

Continuation of Paulo' stolen series[1], addressing the feedback from Joonas and Chris. [1] https://patchwork.freedesktop.org/series/30923/ Joonas Lahtinen (1): x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit Matthew Auld (9): x86/early-quirks: replace the

[Intel-gfx] [PATCH 02/10] x86/early-quirks: replace the magical increment start values

Replace the magical +2, +9 etc. with +MB, which is far easier to read. Suggested-by: Ville Syrjälä Signed-off-by: Matthew Auld Cc: Joonas Lahtinen Cc: Ville Syrjälä Cc: Chris

[Intel-gfx] ✗ Fi.CI.IGT: warning for lib/rendercopy: Refactoring rendercopy libraries

== Series Details == Series: lib/rendercopy: Refactoring rendercopy libraries URL : https://patchwork.freedesktop.org/series/34972/ State : warning == Summary == Warning: bzip CI_DRM_3466/shard-snb2/results25.json.bz2 wasn't in correct JSON format Test kms_flip: Subgroup

Re: [Intel-gfx] [PATCH 09/10] drm/i915: prefer resource_size_t for everything stolen

Quoting Matthew Auld (2017-12-06 18:17:29) > Keeps things consistent now that we make use of struct resource. This > should keep us covered in case we ever get huge amounts of stolen > memory. > > v2: bunch of missing conversions (Chris) > > Signed-off-by: Matthew Auld >

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [1/2] lib: Export kmsg()

== Series Details == Series: series starting with [1/2] lib: Export kmsg() URL : https://patchwork.freedesktop.org/series/34974/ State : warning == Summary == Warning: bzip CI_DRM_3466/shard-snb2/results25.json.bz2 wasn't in correct JSON format Test drv_module_reload: Subgroup

Re: [Intel-gfx] [PATCH i-g-t] lib/igt_sysfs: Let igt_sysfs_read|write return -errno

Quoting Michal Wajdeczko (2017-12-06 19:00:22) > In some cases debugfs or sysfs may return errors that we > want to check. Return -errno from helper functions to make > asserts easier. > > Signed-off-by: Michal Wajdeczko > Cc: Chris Wilson >

Re: [Intel-gfx] [PATCH] e1000e: Taint a HW lockup

On Wed, 2017-12-06 at 10:47 +0100, Daniel Vetter wrote: > On Tue, Dec 5, 2017 at 7:05 PM, Chris Wilson k> wrote: > > Quoting Chris Wilson (2017-12-05 18:00:00) > > > When we see an e1000e HW lockup in CI, it is typically fatal with > > > the > > > hang repeating until

Re: [Intel-gfx] [RFC 1/4] drm/i915/perf: Add support to correlate GPU timestamp with system time

On 12/5/2017 7:28 PM, Lionel Landwerlin wrote: On 15/11/17 12:25, Chris Wilson wrote: Quoting Sagar Arun Kamble (2017-11-15 12:13:51)   #include   #include @@ -2149,6 +2150,14 @@ struct i915_perf_stream {   * @oa_config: The OA configuration used by the stream.   */

Re: [Intel-gfx] [RFC 4/4] drm/i915/perf: Send system clock monotonic time in perf samples

On 12/5/2017 7:52 PM, Lionel Landwerlin wrote: On 15/11/17 12:13, Sagar Arun Kamble wrote: From: Sourab Gupta Currently, we have the ability to only forward the GPU timestamps in the samples (which are generated via OA reports). This limits the ability to correlate

Re: [Intel-gfx] [PATCH] e1000e: Taint a HW lockup

On Tue, Dec 5, 2017 at 7:05 PM, Chris Wilson wrote: > Quoting Chris Wilson (2017-12-05 18:00:00) >> When we see an e1000e HW lockup in CI, it is typically fatal with the >> hang repeating until the host is forcibly rebooted. Speed up that >> process by tainting the

Re: [Intel-gfx] [PATCH v3 00/11] drm/fb-helper: Add .last_close and .output_poll_changed helpers

On Tue, Dec 05, 2017 at 04:11:26PM -0500, Alex Deucher wrote: > On Tue, Dec 5, 2017 at 1:24 PM, Noralf Trønnes wrote: > > The helpers are applied and have reached airlied/drm-next. > > > > amd has gained another .poll_changed user since last. > > Patches 1, 2, 9 applied to my

Re: [Intel-gfx] HDCP as a Kconfig option

On Tue, Dec 05, 2017 at 07:20:10PM -0600, A. Wilcox wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 04/12/17 15:24, Daniel Vetter wrote: > > Hi, > > > > I understand there there's concerns about the content protection > > stuff, but please note: > > > > - The patches under

Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

On 12/5/2017 8:07 PM, Lionel Landwerlin wrote: On 05/12/17 14:28, Robert Bragg wrote: On Tue, Dec 5, 2017 at 2:16 PM, Lionel Landwerlin > wrote: Hey Sagar, Sorry for the delay looking into this series.

Re: [Intel-gfx] [PATCH v3 7/8] drm/i915/huc: Load HuC only if requested

On 12/5/2017 10:08 PM, Michal Wajdeczko wrote: Our new "enable_guc" modparam allows to control whenever HuC should be loaded. However existing code will try load and authenticate HuC always when we use the GuC. This patch is trying to enforce modparam selection. v2: no need to cast PTR_ERR

Re: [Intel-gfx] [PATCH] drm/i915: Call intel_opregion_notify_encoder in intel_sanitize_encoder

Op 01-12-17 om 14:32 schreef Ville Syrjälä: > On Thu, Nov 30, 2017 at 04:18:53PM +0100, Maarten Lankhorst wrote: >> Normally this is called on a modeset, but the call is missing when >> we inherit the mode from the BIOS, so make sure it's called somewhere >> in hardware readout. >> >>

Re: [Intel-gfx] drm-intel/for-linux-next disabled on linux-next?

On Wed, Dec 06, 2017 at 01:11:05PM +1100, Stephen Rothwell wrote: > Hi Rodrigo, > > On Tue, 5 Dec 2017 17:19:21 -0800 Rodrigo Vivi wrote: > > > > We noticed that drm-intel/for-linux-next is currently disabled > > on linux-next. > > What gave you that idea? next-20171205

Re: [Intel-gfx] [RFC 2/4] drm/i915/perf: Add support for collecting 64 bit timestamps with OA reports

On 15/11/17 12:13, Sagar Arun Kamble wrote: --- a/include/uapi/drm/i915_drm.h +++ b/include/uapi/drm/i915_drm.h @@ -1447,6 +1447,12 @@ enum drm_i915_perf_property_id { DRM_I915_PERF_PROP_SAMPLE_OA, /** +* The value of this property set to 1 requests inclusion of GPU +

Re: [Intel-gfx] [PATCH v2] drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture

> -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Wednesday, December 6, 2017 7:38 AM > To: intel-gfx@lists.freedesktop.org > Cc: Chris Wilson ; Bloomfield, Jon > ; Harrison, John C

Re: [Intel-gfx] [PATCH v2] drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture

> -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Bloomfield, Jon > Sent: Wednesday, December 6, 2017 9:01 AM > To: Chris Wilson ; intel-gfx@lists.freedesktop.org > Cc: Daniel Vetter >

Re: [Intel-gfx] HDCP as a Kconfig option

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/12/17 15:24, Daniel Vetter wrote: > Hi, > > I understand there there's concerns about the content protection > stuff, but please note: > > - The patches under discussion enforce nothing, they only allow you > to enable HDCP if you chose to

[Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [v4,1/7] drm/i915/huc: Move firmware selection to init_early

== Series Details == Series: series starting with [v4,1/7] drm/i915/huc: Move firmware selection to init_early URL : https://patchwork.freedesktop.org/series/34968/ State : warning == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-render:

Re: [Intel-gfx] ✗ Fi.CI.IGT: warning for series starting with [v4,1/7] drm/i915/huc: Move firmware selection to init_early

Quoting Patchwork (2017-12-06 16:09:04) > == Series Details == > > Series: series starting with [v4,1/7] drm/i915/huc: Move firmware selection > to init_early > URL : https://patchwork.freedesktop.org/series/34968/ > State : warning > > == Summary == > > Test kms_frontbuffer_tracking: >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture (rev2)

== Series Details == Series: drm/i915: Prevent machine hang from Broxton's vtd w/a and error capture (rev2) URL : https://patchwork.freedesktop.org/series/34969/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-render:

Re: [Intel-gfx] [PATCH igt 2/2] igt/debugfs_tests: Record which file is being opened in kmsg

On 06/12/2017 16:38, Chris Wilson wrote: When tracking down the cause of a particular kernel warning, knowing which file it is associated with can be a big clue. So write the filename into the kernel message log prior to opening it. Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] [PATCH igt 2/2] igt/debugfs_tests: Record which file is being opened in kmsg

On 06/12/2017 17:02, Chris Wilson wrote: Quoting Tvrtko Ursulin (2017-12-06 16:51:24) On 06/12/2017 16:38, Chris Wilson wrote: When tracking down the cause of a particular kernel warning, knowing which file it is associated with can be a big clue. So write the filename into the kernel

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] lib: Export kmsg()

== Series Details == Series: series starting with [1/2] lib: Export kmsg() URL : https://patchwork.freedesktop.org/series/34974/ State : success == Summary == IGT patchset tested on top of latest successful build 1db12466cb5ad8483cd469753d2e312a62d717b7 meson: build a full dependency for

[Intel-gfx] ✗ Fi.CI.BAT: warning for tests/kms_frontbuffer_tracking: Idleness DRRS coverage (rev3)

== Series Details == Series: tests/kms_frontbuffer_tracking: Idleness DRRS coverage (rev3) URL : https://patchwork.freedesktop.org/series/32888/ State : warning == Summary == IGT patchset tested on top of latest successful build 1db12466cb5ad8483cd469753d2e312a62d717b7 meson: build a full

[Intel-gfx] [PATCH igt 1/2] lib: Export kmsg()

Export the kmsg() function for use by tests to write into the kernel message log, useful for tests to inline their progress with kernel error messages. Signed-off-by: Chris Wilson --- lib/igt_core.c | 20 ++-- lib/igt_core.h | 17 + 2

[Intel-gfx] [PATCH igt 2/2] igt/debugfs_tests: Record which file is being opened in kmsg

When tracking down the cause of a particular kernel warning, knowing which file it is associated with can be a big clue. So write the filename into the kernel message log prior to opening it. Signed-off-by: Chris Wilson --- tests/debugfs_test.c | 3 ++- 1 file changed,

Re: [Intel-gfx] [PATCH igt 2/2] igt/debugfs_tests: Record which file is being opened in kmsg

Quoting Tvrtko Ursulin (2017-12-06 17:04:40) > > On 06/12/2017 17:02, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2017-12-06 16:51:24) > >> > >> On 06/12/2017 16:38, Chris Wilson wrote: > >>> When tracking down the cause of a particular kernel warning, knowing > >>> which file it is

[Intel-gfx] ✓ Fi.CI.IGT: success for make stolen resource centric (rev5)

== Series Details == Series: make stolen resource centric (rev5) URL : https://patchwork.freedesktop.org/series/34256/ State : success == Summary == Warning: bzip CI_DRM_3466/shard-snb2/results25.json.bz2 wasn't in correct JSON format Test perf: Subgroup oa-exponents:

Re: [Intel-gfx] [RFC 3/4] drm/i915/perf: Extract raw GPU timestamps from OA reports

On 15/11/17 12:13, Sagar Arun Kamble wrote: From: Sourab Gupta The OA reports contain the least significant 32 bits of the gpu timestamp. This patch enables retrieval of the timestamp field from OA reports, to forward as 64 bit raw gpu timestamps in the perf samples.

[Intel-gfx] [PULL] drm-misc-fixes

Hi Dave, drm-misc-fixes-2017-12-06: Just the connector_iter corner-case regression fix. Enjoy your time off next week! Cheers, Daniel The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215: Linux 4.15-rc2 (2017-12-03 11:01:47 -0500) are available in the Git repository

Re: [Intel-gfx] [RFC 0/4] GPU/CPU timestamps correlation for relating OA samples with system events

I've put together some trival IGT tests : https://github.com/djdeath/intel-gpu-tools/commits/wip/djdeath/cpu-timestamps With a few changes which I pointed in the review : https://github.com/djdeath/linux/commit/d0e4cf4d3f464491b4ffe97d112284d1ce73656d Put together it seems to work relatively

[Intel-gfx] [PATCH] drm/i915: Use copy_from_user() in fence copying

There's no good reason to separate the access_ok() from the copy, especially since the access_ok() size is hard-coded instead of using sizeof(). Instead, just use copy_from_user() directly. Fixes: cf6e7bac6357 ("drm/i915: Add support for drm syncobjs") Cc: Jason Ekstrand

Re: [Intel-gfx] [PATCH] intel/atomic: Stop updating legacy fb parameters

Op 05-12-17 om 18:40 schreef Ville Syrjälä: > On Tue, Dec 05, 2017 at 06:00:20PM +0100, Daniel Vetter wrote: >> Even fbc isn't using this stuff anymore, so time to remove it. >> >> Cleaning up one small piece of the atomic conversion cruft at the time >> ... >> >> Cc: Paulo Zanoni

Re: [Intel-gfx] [PATCH v3 3/8] drm/i915/guc: Introduce USES_GUC_xxx helper macros

On Tue, 05 Dec 2017 23:43:19 +0100, Chris Wilson wrote: Quoting Michal Wajdeczko (2017-12-05 16:38:39) In the upcoming patch we will change the way how to recognize when GuC is in use. Using helper macros will minimize scope of that changes. While here, update

[Intel-gfx] [PATCH] drm/i915: Remove vma from object on destroy, not close

Originally we translated from the object to the vma by walking obj->vma_list to find the matching vm (for user lookups). Now we process user lookups using the rbtree, and we only use obj->vma_list itself for maintaining state (e.g. ensuring that all vma are flushed or rebound). As such maintenance

Re: [Intel-gfx] [GIT pull] x86 APIC updates for 4.15

Hey, Op 30-11-17 om 23:47 schreef Thomas Gleixner: > On Thu, 30 Nov 2017, Maarten Lankhorst wrote: >> Op 30-11-17 om 10:18 schreef Thomas Gleixner: >> # cat /sys/kernel/debug/irq/irqs/28 >> handler: handle_edge_irq >> device: :00:02.0 >> status: 0x >> istate: 0x >>

Re: [Intel-gfx] [PATCH v3 3/8] drm/i915/guc: Introduce USES_GUC_xxx helper macros

Quoting Michal Wajdeczko (2017-12-06 11:24:33) > On Tue, 05 Dec 2017 23:43:19 +0100, Chris Wilson > wrote: > > > Quoting Michal Wajdeczko (2017-12-05 16:38:39) > >> In the upcoming patch we will change the way how to recognize > >> when GuC is in use. Using helper

[Intel-gfx] [PATCH] drm/i915: Remove ancient I915_GEM_EXECBUFFER (v1) support

We transitioned to I915_GEM_EXECBUFFER2 in commit 76446cac68568fc7f5168a27deaf803ed22a4360 [v2.6.33] Author: Jesse Barnes Date: Thu Dec 17 22:05:42 2009 -0500 drm/i915: execbuf2 support and libdrm commit b50964027bef249a0cc3d511de05c2464e0a1e22 [v2.4.19]

[Intel-gfx] [PATCH] Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk"

From: Radhakrishna Sripada This reverts commit 8f067837c4b713ce2e69be95af7b2a5eb3bd7de8. HSD says "WA withdrawn. It was causing corruption with some images. WA is not strictly necessary since this bug just causes loss of FBC compression with some sizes and

[Intel-gfx] ✗ Fi.CI.BAT: failure for Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk" (rev2)

== Series Details == Series: Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk" (rev2) URL : https://patchwork.freedesktop.org/series/33969/ State : failure == Summary == Applying: Revert "drm/i915: Display WA #1133 WaFbcSkipSegments:cnl, glk" error: Failed to merge in the

[Intel-gfx] [PATCH 4/5] drm/i915: Introduce a non-blocking power domain for vblank interrupts

When DC states are enabled and PSR is active, the hardware enters DC5/DC6 states resulting in frame counter resets. The frame counter resets mess up the vblank counting logic. So in order to disable DC states when vblank interrupts are required and to disallow DC states when vblanks interrupts are

[Intel-gfx] [PATCH 1/5] drm/vblank: Do not update vblank counts if vblanks are already disabled.

Updating the vblank counts requires register reads and these reads may not return meaningful values after the vblank interrupts are disabled as the device may go to low power state. An additional change would be to allow the driver to save the vblank counts before entering a low power state, but

[Intel-gfx] [PATCH 2/5] drm/vblank: Restoring vblank counts after device runtime PM events.

The HW frame counter can get reset when devices enters low power states and this messes up any following vblank count updates. So, compute the missed vblank interrupts for that low power state duration using time stamps. This is similar to _crtc_vblank_on() except that it doesn't enable vblank

[Intel-gfx] [PATCH 5/5] drm/i915: Use the vblank power domain disallow or disable DC states.

Disable DC states before enabling vblank interrupts and conversely enable DC states after disabling. Since the frame counter may have got reset between disabling and enabling, use drm_crtc_vblank_restore() to compute the missed vblanks. Signed-off-by: Dhinakaran Pandiyan

[Intel-gfx] [PATCH 3/5] drm/i915: Use an atomic_t array to track power domain use count.

Convert the power_domains->domain_use_count array that tracks per-domain use count to atomic_t type. This is needed to be able to read/write the use counts outside of the power domain mutex. Signed-off-by: Dhinakaran Pandiyan ---

[Intel-gfx] [RFC i-g-t 1/5] igt_dummyload: Wrap function parameters into struct

The intent of this patch is to clean-up the interface of the spinning batch workload by grouping the parameters used to spawn it into a struct. Cc: Chris Wilson Signed-off-by: Antonio Argenziano --- lib/igt_dummyload.c | 19

[Intel-gfx] [RFC i-g-t 4/5] igt_dummyload: Add preemptible parameter to spin batch

This patch adds a parameter that allows to make the spinning batch pre-emptible by adding an arbitration point to the spinning loop. Cc: Chris Wilson Signed-off-by: Antonio Argenziano --- lib/igt_dummyload.c | 4 ++--

[Intel-gfx] [RFC i-g-t 3/5] lib/igt_hang_ctx: Use dummyload batch to hang ctx.

To hang a context we were effectively reimplementing a spinning batch and never stopping it. This patch reuses the recursive batch from igt_dummyload to hang a context. Cc: Chris Wilson Signed-off-by: Antonio Argenziano ---

[Intel-gfx] [RFC i-g-t 5/5] igt_hang_ctx: Add preemptible parameter

This patch adds a parameter to make the hanging context pre-emptible. Cc: Chris Wilson Signed-off-by: Antonio Argenziano --- lib/igt_gt.c| 4 ++-- lib/igt_gt.h| 1 + tests/drv_hangman.c | 2 +-

[Intel-gfx] [RFC i-g-t 2/5] igt_hang_ctx: Wrap parameters into struct

This patch wraps the parameters for the function used to hang a context (igt_hang_ctx) into a struct to cleanup the interface and make it easier to add more parameters. Cc: Chris Wilson Signed-off-by: Antonio Argenziano ---

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove vma from object on destroy, not close

== Series Details == Series: drm/i915: Remove vma from object on destroy, not close URL : https://patchwork.freedesktop.org/series/34961/ State : success == Summary == Series 34961v1 drm/i915: Remove vma from object on destroy, not close

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove vma from object on destroy, not close

== Series Details == Series: drm/i915: Remove vma from object on destroy, not close URL : https://patchwork.freedesktop.org/series/34961/ State : success == Summary == Test perf: Subgroup oa-exponents: fail -> PASS (shard-hsw) fdo#102254 Test kms_flip:

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Remove ancient I915_GEM_EXECBUFFER (v1) support

== Series Details == Series: drm/i915: Remove ancient I915_GEM_EXECBUFFER (v1) support URL : https://patchwork.freedesktop.org/series/34964/ State : success == Summary == Test kms_frontbuffer_tracking: Subgroup fbc-1p-offscren-pri-shrfb-draw-blt: fail -> PASS

Re: [Intel-gfx] [PATCH v3 3/8] drm/i915/guc: Introduce USES_GUC_xxx helper macros

Quoting Chris Wilson (2017-12-06 11:32:01) > Quoting Michal Wajdeczko (2017-12-06 11:24:33) > > On Tue, 05 Dec 2017 23:43:19 +0100, Chris Wilson > > wrote: > > > > > Quoting Michal Wajdeczko (2017-12-05 16:38:39) > > >> In the upcoming patch we will change the way how

Re: [Intel-gfx] [PATCH v3 6/8] drm/i915/guc: Combine enable_guc_loading|submission modparams

On Tue, 05 Dec 2017 23:47:21 +0100, Chris Wilson wrote: Quoting Michal Wajdeczko (2017-12-05 16:38:42) -void intel_uc_sanitize_options(struct drm_i915_private *dev_priv) +static int __get_platform_enable_guc(struct drm_i915_private *dev_priv) { - if

Re: [Intel-gfx] [PATCH v3 6/8] drm/i915/guc: Combine enable_guc_loading|submission modparams

Quoting Michal Wajdeczko (2017-12-06 12:10:15) > On Tue, 05 Dec 2017 23:47:21 +0100, Chris Wilson > wrote: > > > Quoting Michal Wajdeczko (2017-12-05 16:38:42) > >> -void intel_uc_sanitize_options(struct drm_i915_private *dev_priv) > >> +static int

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove ancient I915_GEM_EXECBUFFER (v1) support

== Series Details == Series: drm/i915: Remove ancient I915_GEM_EXECBUFFER (v1) support URL : https://patchwork.freedesktop.org/series/34964/ State : success == Summary == Series 34964v1 drm/i915: Remove ancient I915_GEM_EXECBUFFER (v1) support

Re: [Intel-gfx] [PATCH v3 5/8] drm/i915/uc: Don't use -EIO to report missing firmware

Quoting Michal Wajdeczko (2017-12-05 16:38:41) > -EIO has special meaning and is used when we want to allow > engine initialization to fail and mark GPU as wedged. > > However here at this function we should return error code > that corresponds to upload status only, as any decision how > to

[Intel-gfx] [PATCH 2/2] drm/i915: Track GGTT writes on the vma

As writes through the GTT and GGTT PTE updates do not share the same path, they are not strictly ordered and so we must explicitly flush the indirect writes prior to modifying the PTE. We do track outstanding GGTT writes on the object itself, but since the object may have multiple GGTT vma, that

[Intel-gfx] [PATCH 1/2] drm/i915: Remove vma from object on destroy, not close

Originally we translated from the object to the vma by walking obj->vma_list to find the matching vm (for user lookups). Now we process user lookups using the rbtree, and we only use obj->vma_list itself for maintaining state (e.g. ensuring that all vma are flushed or rebound). As such maintenance

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Remove vma from object on destroy, not close

== Series Details == Series: series starting with [1/2] drm/i915: Remove vma from object on destroy, not close URL : https://patchwork.freedesktop.org/series/34965/ State : success == Summary == Series 34965v1 series starting with [1/2] drm/i915: Remove vma from object on destroy, not close

[Intel-gfx] [PATCH i-g-t 3/4] lib/intel_aub: Add new MEM_TRACE commands

The memtrace aub commands are similar to the existing ones, but different. Notably memtrace has commands for register write and poll. Signed-off-by: Scott D Phillips --- lib/intel_aub.h | 26 ++ 1 file changed, 26 insertions(+) diff --git

  1   2   >