Re: [Intel-gfx] [PATCH 2/2] drm/i915: Make GPU pages movable

On 11/10/2016 12:09 PM, Hugh Dickins wrote: On Fri, 4 Nov 2016, akash.g...@intel.com wrote: From: Chris Wilson On a long run of more than 2-3 days, physical memory tends to get fragmented severely, which considerably slows down the system. In such a scenario, the

[Intel-gfx] [PULL] topic/drm-misc

Hi Dave, - better atomic state debugging from Rob - fence prep from gustavo - sumits flushed out his backlog of pending dma-buf/fence patches from various people - drm_mm leak debugging plus trying to appease Kconfig (Chris) - a few misc things all over Cheers, Daniel The following changes

Re: [Intel-gfx] [PATCH v3 04/11] drm/i915/gen9+: Kill off hw_ddb from intel_crtc.

Op 10-11-16 om 01:52 schreef Matt Roper: > On Tue, Nov 08, 2016 at 01:55:35PM +0100, Maarten Lankhorst wrote: >> This member is only used in skl_update_crtcs now. It's easy to remove it >> by keeping track of which ddb entries in an array, and update them after > I'm having trouble parsing this

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Make GPU pages movable

On Fri, 4 Nov 2016, akash.g...@intel.com wrote: > From: Chris Wilson > > On a long run of more than 2-3 days, physical memory tends to get > fragmented severely, which considerably slows down the system. In such a > scenario, the shrinker is also unable to help as lack

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/dp/i915: Fix DP link rate math

== Series Details == Series: series starting with [1/2] drm/dp/i915: Fix DP link rate math URL : https://patchwork.freedesktop.org/series/15084/ State : success == Summary == Series 15084v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/15084/revisions/1/mbox/

Re: [Intel-gfx] [PATCH v4 4/8] drm/i915/gen9: WM memory bandwidth related workaround

Hi, On Friday 04 November 2016 10:39 PM, Paulo Zanoni wrote: Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu: This patch implemnets Workariunds related to display arbitrated memory bandwidth. These WA are applicabe for all gen-9 based platforms. Changes since v1: - Rebase on top

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/audio: fix hdmi audio noise issue (rev2)

== Series Details == Series: drm/i915/audio: fix hdmi audio noise issue (rev2) URL : https://patchwork.freedesktop.org/series/15012/ State : success == Summary == Series 15012v2 drm/i915/audio: fix hdmi audio noise issue https://patchwork.freedesktop.org/api/1.0/series/15012/revisions/2/mbox/

Re: [Intel-gfx] [PATCH 1/2] shmem: Support for registration of driver/file owner specific ops

On Fri, 4 Nov 2016, akash.g...@intel.com wrote: > From: Chris Wilson > > This provides support for the drivers or shmem file owners to register > a set of callbacks, which can be invoked from the address space > operations methods implemented by shmem. This allow the

[Intel-gfx] [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST

Not validating the the mode rate against link rate results not pruning invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not support 4k @ 60Hz. But, we do not reject this mode currently. So, make use of the helpers in intel_dp in validate mode rates against max. data rate of a

[Intel-gfx] [PATCH 1/2] drm/dp/i915: Fix DP link rate math

We store DP link rates as link clock frequencies in kHz, just like all other clock values. But, DP link rates in the DP Spec are expressed in Gbps/lane, which seems to have led to some confusion. E.g., for HBR2 Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 216 kBps where, 8/10 is for

[Intel-gfx] ✗ Fi.CI.BAT: failure for Handle Link Training Failure during modeset

== Series Details == Series: Handle Link Training Failure during modeset URL : https://patchwork.freedesktop.org/series/15080/ State : failure == Summary == Series 15080v1 Handle Link Training Failure during modeset https://patchwork.freedesktop.org/api/1.0/series/15080/revisions/1/mbox/

[Intel-gfx] [PATCH v2] drm/i915/audio: fix hdmi audio noise issue

From: Libin Yang Some monitors will have noise or even no sound after applying the patch 6014ac12. In patch 6014ac12, it will reset the cts value to 0 for HDMI. However, we need to disable Enable CTS or M Prog bit. This is the initial setting after HW reset. Fixes:

[Intel-gfx] [PATCH 1/5] drm: Add a new connector property for link status

A new default connector property is added for keeping track of whether the link is good (link training passed) or link is bad (link training failed). If the link status property is not good, then userspace should fire off a new modeset at the current mode even if there have not been any changes

[Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

CRTC state connector_changed needs to be set to true if connector link status property has changed. This will tell the driver to do a complete modeset due to change in connector property. Cc: dri-de...@lists.freedesktop.org Cc: Jani Nikula Cc: Daniel Vetter

[Intel-gfx] [PATCH 4/5] drm/i915: Find fallback link rate/lane count

If link training fails, then we need to fallback to lower link rate first and if link training fails at RBR, then fallback to lower lane count. This function finds the next lower link rate/lane count value after link training failure. v2: Squash the patch that returns the link rate index (Jani

[Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset

Link training failure is handled by lowering the link rate first until it reaches the minimum and keeping the lane count maximum and then lowering the lane count until it reaches minimim. These fallback values are saved and hotplug uevent is sent to the userspace after setting the connector link

[Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed, update the link status property to "BAD" and use a lower link rate to prune the

[Intel-gfx] [PATCH 2/5] drm/i915: Set link status property for DP connector

This defines a helper function to set the property value. This will be used to set the link status to Bad in case of link training failures. v3: * Set connector->link_status in this function (Jani Nikula) v2: * Simplify the return value (Jani Nikula) Cc: dri-de...@lists.freedesktop.org Cc: Jani

Re: [Intel-gfx] [PATCH i-g-t 2/4 v5] lib/igt_gvt: Make use of libkmod helpers and fix reading gvt parameter.

On 2016.11.03 18:28:11 +0200, Marius Vlad wrote: > v2: > - use igt_sysfs_get_boolean() to get gvt status (Chris Wilson) > - do not hard-fail when i915 module could not be loaded/unloaded (Chris > Wilson) > > Signed-off-by: Marius Vlad Looks fine to me. Acked-by: Zhenyu

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Disable access to stolen memory as a guest

On 2016.11.09 10:39:05 +, Chris Wilson wrote: > Explicitly disable stolen memory when running as a guest in a virtual > machine, since the memory is not mediated between clients and reserved > entirely for the host. The actual size should be reported as zero, but > like every other quirk we

Re: [Intel-gfx] [PATCH] drm/i915/audio: fix hdmi audio noise issue

> -Original Message- > From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > Sent: Wednesday, November 9, 2016 6:59 PM > To: Yang, Libin ; intel-gfx@lists.freedesktop.org; > ville.syrj...@linux.intel.com; Vetter, Daniel ; > ti...@suse.de >

Re: [Intel-gfx] [PATCH] drm/i915/gvt: Disable access to stolen memory as a guest

On 2016.11.09 13:11:11 +0200, Joonas Lahtinen wrote: > On ke, 2016-11-09 at 10:39 +, Chris Wilson wrote: > > Explicitly disable stolen memory when running as a guest in a virtual > > machine, since the memory is not mediated between clients and reserved > > entirely for the host. > > I'd

Re: [Intel-gfx] [PATCH v3 04/11] drm/i915/gen9+: Kill off hw_ddb from intel_crtc.

On Tue, Nov 08, 2016 at 01:55:35PM +0100, Maarten Lankhorst wrote: > This member is only used in skl_update_crtcs now. It's easy to remove it > by keeping track of which ddb entries in an array, and update them after I'm having trouble parsing this line...not sure if you have an extra word or are

Re: [Intel-gfx] [PATCH v3 03/11] drm/i915/gen9+: Preserve old allocation from crtc_state.

On Tue, Nov 08, 2016 at 01:55:34PM +0100, Maarten Lankhorst wrote: > This is the last bit required for making nonblocking modesets work > correctly. The state in intel_crtc->hw_ddb is not updated until > somewhere in atomic commit, while the previous crtc state should be > accurate if the ddb

Re: [Intel-gfx] [PATCH v3 01/11] drm/i915: Add a atomic evasion step to watermark programming, v3.

On Tue, Nov 08, 2016 at 01:55:32PM +0100, Maarten Lankhorst wrote: > Allow the driver to write watermarks during atomic evasion. > This will make it possible to write the watermarks in a cleaner > way on gen9+. > > intel_atomic_state is not used here yet, but will be used when > we program all

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Don't take struct_mutex for object unreference

== Series Details == Series: drm/i915/guc: Don't take struct_mutex for object unreference URL : https://patchwork.freedesktop.org/series/15071/ State : success == Summary == Series 15071v1 drm/i915/guc: Don't take struct_mutex for object unreference

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915: Always flush the dirty CPU cache when pinning the scanout

== Series Details == Series: series starting with [1/5] drm/i915: Always flush the dirty CPU cache when pinning the scanout URL : https://patchwork.freedesktop.org/series/15069/ State : failure == Summary == Series 15069v1 Series without cover letter

Re: [Intel-gfx] [PATCH v3 4/4] drm/i915: Implement Link Rate fallback on Link training failure

On Wed, Nov 09, 2016 at 03:04:05PM +0200, Jani Nikula wrote: > On Wed, 02 Nov 2016, Manasi Navare wrote: > > If link training at a link rate optimal for a particular > > mode fails during modeset's atomic commit phase, then we > > let the modeset complete and then

[Intel-gfx] [PATCH] drm/i915/guc: Don't take struct_mutex for object unreference

We no longer need to take the struct_mutex for freeing objects, and on the finalisation paths here the mutex is not been used for serialisation of the pointer access, so remove the BKL wart. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_guc_loader.c | 14

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

>-Original Message- >From: Mcgee, Jeff >Sent: Wednesday, November 9, 2016 12:43 PM >To: Srivatsa, Anusha >Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter Antoine > >Subject: Re: [Intel-gfx] [PATCH 1/8]

[Intel-gfx] [PATCH 5/5] drm/i915: Drop struct_mutex around frontbuffer flushes

Since the frontbuffer has self-contained locking, it does not require us to hold the BKL struct_mutex as we send invalidate and flush messages. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_fbdev.c | 43 +++--- 1 file

[Intel-gfx] [PATCH 2/5] drm/i915: Mark all skipped clflushes as leaving the CPU cache dirty

Currently, we may skip the clflush on an object if the object has not yet allocated any pages. However, the object may still be polluting the CPU cache and may now be in a coherent uncached domain - and so no longer generating clflushing. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 4/5] drm/i915: struct_mutex is not required for allocating the framebuffer

We do not need the BKL struct_mutex in order to allocate a GEM object, nor to create the framebuffer, so resist the temptation to take the BKL willy nilly. As this changes the locking contract around internal API calls, the patch is a little larger than a plain removal of a pair of

[Intel-gfx] [PATCH 3/5] drm/i915: Remove struct_mutex for destroying framebuffers

We do not need to hold struct_mutex for destroying drm_i915_gem_objects any longer, and with a little care taken over tracking obj->framebuffer_references, we can relinquish BKL locking around the destroy of intel_framebuffer. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 1/5] drm/i915: Always flush the dirty CPU cache when pinning the scanout

Currently we only clflush the scanout if it is in the CPU domain. Also flush if we have a pending CPU clflush. We also want to treat the dirtyfb path similar, and flush any pending writes there as well. v2: Only send the frontbuffer flush if we have CPU dirt. Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

When updating a patch set on the mailing list with new revisions it is preferred to send those new patches as a reply to the patch being revised and also to include the V2, V3, etc. in the subject. If you have massive changes then it is OK to submit a new set but it helps to include cover letter

Re: [Intel-gfx] [PATCH] Implement Limited Video Range

On Wed, Nov 09, 2016 at 09:11:58PM +0100, Peter Frühberger wrote: > I am currently not sure what the way forward should be. > > We are successfully implementing this patch in e.g. LibreELEC an embedded > distribution for home theater pcs. But through current bug reports - I am > not sure, if we

Re: [Intel-gfx] [PATCH 6/8] drm/i915/huc: Update SKL and BXT HuC Loading Support

On Wed, Nov 09, 2016 at 10:51:35AM -0800, Anusha Srivatsa wrote: > From: Peter Antoine > > This patch adds the HuC Loading for the BXT. > Version 1.7 of the HuC firmware. > > It also updates the file construction and specifying the > required version similar to that of

Re: [Intel-gfx] [PATCH] Implement Limited Video Range

I am currently not sure what the way forward should be. We are successfully implementing this patch in e.g. LibreELEC an embedded distribution for home theater pcs. But through current bug reports - I am not sure, if we should give such functionality to the user, that is overwritten on a lower

Re: [Intel-gfx] [PATCH v9 01/11] drm/i915: Add i915 perf infrastructure

On 7 November 2016 at 19:49, Robert Bragg wrote: > Adds base i915 perf infrastructure for Gen performance metrics. > > This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64 > properties to configure a stream of metrics and returns a new fd usable > with

Re: [Intel-gfx] [PATCH v9 09/11] drm/i915: add dev.i915.oa_max_sample_rate sysctl

On 7 November 2016 at 19:49, Robert Bragg wrote: > The maximum OA sampling frequency is now configurable via a > dev.i915.oa_max_sample_rate sysctl parameter. > > Following the precedent set by perf's similar > kernel.perf_event_max_sample_rate the default maximum rate is

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/8] drm/i915/guc: Make the GuC fw loading helper functions general

== Series Details == Series: series starting with [1/8] drm/i915/guc: Make the GuC fw loading helper functions general URL : https://patchwork.freedesktop.org/series/15061/ State : success == Summary == Series 15061v1 Series without cover letter

[Intel-gfx] [PATCH] drm/i915/GuC: Combine the two kernel parameter into one

Replace i915.enable_guc_loading and i915.enable_guc_submission with a single parameter - i915.enable_guc. Where: -1 : Platform default (Only load GuC) 0 : Do not use GuC 1 : Load GuC, do not use Command Submission through GuC 2 : Load and use GuC for Command Submission Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

From: Peter Antoine This patch will allow for getparams to return the status of the HuC. As the HuC has to be validated by the GuC this patch uses the validated status to show when the HuC is loaded and ready for use. You cannot use the loaded status as with the GuC as

[Intel-gfx] [PATCH 6/8] drm/i915/huc: Update SKL and BXT HuC Loading Support

From: Peter Antoine This patch adds the HuC Loading for the BXT. Version 1.7 of the HuC firmware. It also updates the file construction and specifying the required version similar to that of GuC for both SKL and BXT. Add an extra field for the build number. Adopted the

[Intel-gfx] [PATCH 5/8] drm/i915/huc: Support HuC authentication

From: Peter Antoine The HuC authentication is done by host2guc call. The HuC RSA keys are sent to GuC for authentication. v2: rebased on top of drm-intel-nightly. changed name format and upped version 1.7. v3: rebased on top of drm-intel-nightly. v4: changed

[Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC

From: Peter Antoine HuC firmware css header has almost exactly same definition as GuC firmware except for the sw_version. Also, add a new member fw_type into intel_uc_fw to indicate what kind of fw it is. So, the loader will pull right sw_version from header. v2:

[Intel-gfx] [PATCH 7/8] drm/i915/HuC: Add HuC Loading support on KBL

This patch adds the support to load HuC on KBL Version 2.0 Cc: Jeff Mcgee Signed-off-by: Anusha Srivatsa --- drivers/gpu/drm/i915/intel_huc_loader.c | 12 1 file changed, 12 insertions(+) diff --git

[Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general

From: Peter Antoine Rename some of the GuC fw loading code to make them more general. We will utilise them for HuC loading as well. s/intel_guc_fw/intel_uc_fw/g s/GUC_FIRMWARE/UC_FIRMWARE/g Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,

[Intel-gfx] [PATCH 4/8] drm/i915/huc: Add debugfs for HuC loading status check

From: Peter Antoine Add debugfs entry for HuC loading status check. v2: rebase on-top of drm-intel-nightly. v3: rebased again. v7: rebased. v8: rebased. v9: rebased. v10: rebased. Tested-by: Xiang Haihao Signed-off-by: Anusha Srivatsa

[Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support

From: Peter Antoine The HuC loading process is similar to GuC. The intel_uc_fw_fetch() is used for both cases. HuC loading needs to be before GuC loading. The WOPCM setting must be done early before loading any of them. v2: rebased on-top of drm-intel-nightly.

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Make GPU pages movable

On Wed, 9 Nov 2016, Daniel Vetter wrote: > > Hi all -mm folks! > > Any feedback on these two? It's kinda an intermediate step towards a > full-blown gemfs, and I think useful for that. Or do we need to go > directly to our own backing storage thing? Aside from ack/nack from -mm I > think this is

Re: [Intel-gfx] [PATCH] drm/i915: remove duplicated memsets in skl_allocate_pipe_ddb()

On Wed, Nov 09, 2016 at 11:27:37AM +0200, Jani Nikula wrote: > On Wed, 09 Nov 2016, Matt Roper wrote: > > On Tue, Nov 08, 2016 at 03:21:22PM -0200, Paulo Zanoni wrote: > >> One of the memsets was added by 5a920b85f2c6 ("drm/i915/gen9: fix DDB > >> partitioning for

Re: [Intel-gfx] [PATCH v4 1/8] drm/i915/skl+: use linetime latency instead of ddb size

Em Qua, 2016-11-09 às 20:28 +0530, Mahesh Kumar escreveu: > Hi, > > > On Monday 31 October 2016 11:33 PM, Paulo Zanoni wrote: > > > > Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu: > > > > > > This patch make changes to use linetime latency instead of > > > allocated > > > DDB size

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

On Wednesday, 2016-11-09 14:13:40 +0100, Daniel Vetter wrote: > On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom > wrote: > >> Well, had to drop it again since it didn't compile: > >> > >> > >> CC [M] drivers/gpu/drm/drm_blend.o > >> drivers/gpu/drm/drm_atomic.c: In

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Trim the object sg table (rev2)

== Series Details == Series: drm/i915: Trim the object sg table (rev2) URL : https://patchwork.freedesktop.org/series/15036/ State : warning == Summary == Series 15036v2 drm/i915: Trim the object sg table https://patchwork.freedesktop.org/api/1.0/series/15036/revisions/2/mbox/ Test

Re: [Intel-gfx] [PATCH igt v3 01/11] igt/perf: add i915 perf stream tests for Haswell

On Wed, Nov 09, 2016 at 04:15:52PM +, Robert Bragg wrote: > +static void > +test_i915_ref_count(void) > +{ > +int oa_exponent = 13; /* 1 millisecond */ > +uint64_t properties[] = { > +/* Include OA reports in samples */ > +

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Add a per-pipe plane identifier enum (rev4)

== Series Details == Series: drm/i915: Add a per-pipe plane identifier enum (rev4) URL : https://patchwork.freedesktop.org/series/14978/ State : warning == Summary == Series 14978v4 drm/i915: Add a per-pipe plane identifier enum

[Intel-gfx] [PATCH igt v3 10/11] igt/gem_exec_parse: update registers test for v >= 8

This combines some parts of the recently added store_lri test with the registers test to be able to first load a distinguishable value before the LRI and explicitly read back the register to determine if the command succeeded or was a NOOP. For now though we won't look at OACONTROL without

[Intel-gfx] [PATCH igt v3 09/11] igt/gem_exec_parse: update hsw_load_register_reg for v >= 8

This updates the checking of disallowed loads to set a distinguishable value before the load and explicitly check the load was a NOOP by reading back the final value. Signed-off-by: Robert Bragg --- tests/gem_exec_parse.c | 20 ++-- 1 file changed, 18

[Intel-gfx] [PATCH igt v3 11/11] igt/gem_exec_parse: check oacontrol lri bad for >= v9

OACONTROL is no longer white listed in the command parser so this checks at attempted LRI will be disallowed and (more importantly) checks that userspace doesn't get an EINVAL error for an attempted OACONTROL LRI. This is important becase Mesa application attempt OACONTROL LRIs while initializing

[Intel-gfx] [PATCH igt v3 08/11] igt/gem_exec_parse: update cmd-crossing-page for >= v8

Since an access violation won't return an error to userspace for v >= 8 of the command parser this updates the cmd-crossing-page test to explicitly read back from SO_WRITE_OFFSET[0] to see that the command wasn't squashed to a NOOP. Signed-off-by: Robert Bragg ---

[Intel-gfx] [PATCH igt v3 07/11] igt/gem_exec_parse: update bitmasks test for v >=8

With v8 of the command parser (where we won't get an EINVAL for an access violation) this updates the bitmasks test to explicitly confirm that the command became a NOOP by reading back from where the QW_WRITE would have otherwise landed. Signed-off-by: Robert Bragg ---

[Intel-gfx] [PATCH igt v3 06/11] igt/gem_exec_parse: make basic-rejected version agnostic

This adapts the basic-rejected test to focus on invalid commands that will result in an EINVAL errno being returned to userspace even with the upcoming version 8 parser change to stop reporting access violations as EINVAL errors. Signed-off-by: Robert Bragg ---

[Intel-gfx] [PATCH igt v3 03/11] igt/gem_exec_parse: move hsw_load_register_reg down

No functional change, just moving hsw_load_regster_reg test code down below the execbuf utilities in preparation for updating to use them. Signed-off-by: Robert Bragg --- tests/gem_exec_parse.c | 182 - 1 file changed, 91

[Intel-gfx] [PATCH igt v3 04/11] igt/gem_exec_parse: update hsw_load_register_reg

This generalises hsw_load_register_reg to loop through an array of allowed and disallowed registers and to use the exec_batch[_patched] utilities. Signed-off-by: Robert Bragg --- tests/gem_exec_parse.c | 139 +++-- 1 file

[Intel-gfx] [PATCH igt v3 05/11] igt/gem_exec_parse: req. v < 9 for oacontrol tracking test

This limits testing the oacontrol tracking (required pairing of oa enable/disable per batch buffer) to version <= 8 of the command parser. Version 9 of the command parser removes all special handling for OACONTROL which is now going to be managed by i915-perf and not programmed from userspace.

[Intel-gfx] [PATCH igt v3 01/11] igt/perf: add i915 perf stream tests for Haswell

Signed-off-by: Robert Bragg --- tests/Makefile.sources |1 + tests/perf.c | 2220 2 files changed, 2221 insertions(+) create mode 100644 tests/perf.c diff --git a/tests/Makefile.sources

[Intel-gfx] [PATCH igt v3 02/11] igt/gem_exec_parse: some minor cleanups

This normalizes the execbuf utilities in this file to all use memset to clear obj, reloc and execbuf structures and set them up in the same order. As I was debugging some unpredictable test failures I was getting unsure that all these structures were being fully initialized. The same

[Intel-gfx] [PATCH igt v3 00/11] corresponding changes for i915-perf interface

The i915-perf series affects the command parser and itself includes new uapi which these i-g-t changes try to cover. As well as splitting up the gem_exec_parse changes this version maintains support for testing version 7 of the command parser. - Robert Robert Bragg (6): igt/perf: add i915

Re: [Intel-gfx] [RFC i-g-t 4/4] Add support for hotplug testing with the Chamelium

On 8 November 2016 at 01:05, Lyude wrote: > For the purpose of testing things such as hotplugging and bad monitors, > the ChromeOS team ended up designing a neat little device known as the > Chamelium. More information on this can be found here: > >

Re: [Intel-gfx] [PATCH] drm/i915: Spin until breadcrumb threads are complete

On Wed, Nov 09, 2016 at 02:53:34PM +, Tvrtko Ursulin wrote: > Looks OK. Side note to myself - catch up on the rcu waiter business. > > Reviewed-by: Tvrtko Ursulin Ta, pushed to have one less wart. -Chris -- Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] [GIT PULL] kvm/page_track changes for i915 KVMGT

On 09/11/2016 16:15, Daniel Vetter wrote: > On Wed, Nov 09, 2016 at 03:25:19PM +0100, Paolo Bonzini wrote: >> Daniel, >> >> The following changes since commit d9092f52d7e61dd1557f2db2400ddb430e85937e: >> >> kvm: x86: Check memopp before dereference (CVE-2016-8630) (2016-11-02 >> 21:31:53

Re: [Intel-gfx] [GIT PULL] kvm/page_track changes for i915 KVMGT

On Wed, Nov 09, 2016 at 03:25:19PM +0100, Paolo Bonzini wrote: > Daniel, > > The following changes since commit d9092f52d7e61dd1557f2db2400ddb430e85937e: > > kvm: x86: Check memopp before dereference (CVE-2016-8630) (2016-11-02 > 21:31:53 +0100) > > are available in the git repository at: >

[Intel-gfx] [PATCH v3] drm/i915: Trim the object sg table

From: Tvrtko Ursulin At the moment we allocate enough sg table entries assuming we will not be able to do any coalescing. But since in practice we most often can, and more so very effectively, this ends up wasting a lot of memory. A simple and effective way of trimming

Re: [Intel-gfx] [PATCH] drm/i915: Trim the object sg table

On Wed, Nov 09, 2016 at 03:07:38PM +, Tvrtko Ursulin wrote: > > On 09/11/2016 14:44, Chris Wilson wrote: > >Reviewed-by: Chris Wilson > > ^ I remembered it this time! > >Took a couple of attempts to spell my name right though. > > Thanks! I assume I can

Re: [Intel-gfx] [RFC i-g-t 0/4] intel-gpu-tools: Add support for the Chamelium

Hi Lyude, I think this looks very good. On 8 November 2016 at 01:05, Lyude wrote: > > - While writing this patch series, I found that quite a few of the RPC calls >for chameleond don't work as expected. For instance, I have had absolutely >no luck getting CRCs from

Re: [Intel-gfx] [PATCH] drm/i915: Trim the object sg table

On 09/11/2016 14:44, Chris Wilson wrote: On Wed, Nov 09, 2016 at 02:30:02PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin At the moment we allocate enough sg table entries assuming we will not be able to do any coallescing. But since in practice we most often

[Intel-gfx] [PATCH v3 4/9] drm/i915: Use enum plane_id in SKL wm code

From: Ville Syrjälä Nuke skl_wm_plane_id() and just use the new intel_plane->id. v2: Convert skl_write_plane_wm() as well v3: Convert skl_pipe_wm_get_hw_state() correctly Cc: Matt Roper Cc: Paulo Zanoni Cc:

Re: [Intel-gfx] [PATCH v4 1/8] drm/i915/skl+: use linetime latency instead of ddb size

Hi, On Monday 31 October 2016 11:33 PM, Paulo Zanoni wrote: Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu: This patch make changes to use linetime latency instead of allocated DDB size during plane watermark calculation in switch case, This is required to implement new DDB

Re: [Intel-gfx] [PATCH] drm/i915: Spin until breadcrumb threads are complete

On 08/11/2016 14:37, Chris Wilson wrote: When we need to reset the global seqno on wraparound, we have to wait until the current rbtrees are drained (or otherwise the next waiter will be out of sequence). The current mechanism to kick and spin until complete, may exit too early as it would

Re: [Intel-gfx] [PATCH] drm/i915: Trim the object sg table

On Wed, Nov 09, 2016 at 02:30:02PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > At the moment we allocate enough sg table entries assuming we > will not be able to do any coallescing. But since in practice > we most often can, and more so very effectively,

Re: [Intel-gfx] [PATCH i-g-t v2] configure.ac: correctly manage DRM_INTEL_{CFLAGS, LIBS}

Reviewed-by: Robert Foss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Trim the object sg table

From: Tvrtko Ursulin At the moment we allocate enough sg table entries assuming we will not be able to do any coallescing. But since in practice we most often can, and more so very effectively, this ends up wasting a lot of memory. A simple and effective way of

Re: [Intel-gfx] [drm-intel:topic/drm-misc 1/2] backtracetest.c:undefined reference to `save_stack_trace'

On 9 November 2016 at 14:12, Chris Wilson wrote: > On Wed, Nov 09, 2016 at 10:01:37PM +0800, kbuild test robot wrote: >> tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc >> head: 77d150b90d58ae6a43bf67af28feb26384d06cd6 >> commit:

[Intel-gfx] [GIT PULL] kvm/page_track changes for i915 KVMGT

Daniel, The following changes since commit d9092f52d7e61dd1557f2db2400ddb430e85937e: kvm: x86: Check memopp before dereference (CVE-2016-8630) (2016-11-02 21:31:53 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-kvmgt for you to fetch

Re: [Intel-gfx] [PATCH 0/2] extend page_track for external usage

On 09/11/2016 03:03, Zhenyu Wang wrote: > On 2016.11.07 10:17:54 +0100, Daniel Vetter wrote: Paolo, for this case, do you think it's feasible we pick them through drm/i915 merge path? As currently initial KVMGT patch sets require these exported symbols, that's why I ask how we

Re: [Intel-gfx] [drm-intel:topic/drm-misc 1/2] backtracetest.c:undefined reference to `save_stack_trace'

On Wed, Nov 09, 2016 at 10:01:37PM +0800, kbuild test robot wrote: > tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc > head: 77d150b90d58ae6a43bf67af28feb26384d06cd6 > commit: cd456f8d06d2036e1e013136c3fbf5721d04f6d7 [1/2] drm: Restrict > stackdepot usage to builtin drm.ko >

Re: [Intel-gfx] [RFC PATCH v2 0/8] Add support for Legacy Hdmi audio

On Sun, Nov 06, 2016 at 11:42:31PM -0700, Pierre-Louis Bossart wrote: > I am all for convergence when it makes sense but I don't see how > hdmi-codec.h provides equivalent functionality for BYT/CHT with what was > suggested in this patchset -derived from VED patches- and discussed earlier > with

[Intel-gfx] [drm-intel:topic/drm-misc 1/2] backtracetest.c:undefined reference to `save_stack_trace'

tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 77d150b90d58ae6a43bf67af28feb26384d06cd6 commit: cd456f8d06d2036e1e013136c3fbf5721d04f6d7 [1/2] drm: Restrict stackdepot usage to builtin drm.ko config: m68k-allyesconfig (attached as .config) compiler: m68k-linux-gcc (GCC)

Re: [Intel-gfx] [PATCH v3 1/4] drm: Add a new connector property for link status

On Mon, 31 Oct 2016, Manasi Navare wrote: > A new default connector property is added for keeping > track of whether the link is good (link training passed) or > link is bad (link training failed). If the link status property > is not good, then userspace should fire

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Add per-pipe plane identifier

On Tue, Nov 08, 2016 at 04:53:20PM -0800, Matt Roper wrote: > On Tue, Nov 08, 2016 at 04:47:12PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > As I told people in [1] we really should not be confusing enum plane > > as a per-pipe plane

Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()

On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom wrote: >> Well, had to drop it again since it didn't compile: >> >> >> CC [M] drivers/gpu/drm/drm_blend.o >> drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’: >>

Re: [Intel-gfx] [PATCH v3 4/4] drm/i915: Implement Link Rate fallback on Link training failure

On Mon, 07 Nov 2016, Manasi Navare wrote: > Jani, could you please take a look at this patch? > I have addressed your comments on the previous revision. > The common_rates array can be moved into Intel dp > structure in a follow up patch since that would require

Re: [Intel-gfx] [PATCH v3 4/4] drm/i915: Implement Link Rate fallback on Link training failure

On Wed, 02 Nov 2016, Manasi Navare wrote: > If link training at a link rate optimal for a particular > mode fails during modeset's atomic commit phase, then we > let the modeset complete and then retry. We save the link rate > value at which link training failed, update

[Intel-gfx] ✓ Fi.CI.BAT: success for dev_priv cleanup continuation (rev3)

== Series Details == Series: dev_priv cleanup continuation (rev3) URL : https://patchwork.freedesktop.org/series/14844/ State : success == Summary == Series 14844v3 dev_priv cleanup continuation https://patchwork.freedesktop.org/api/1.0/series/14844/revisions/3/mbox/ fi-bdw-5557u

Re: [Intel-gfx] [PATCH v3 05/11] drm/i915/gen9+: Do not initialise active_crtcs for !modeset

Op 08-11-16 om 15:11 schreef Ville Syrjälä: > On Tue, Nov 08, 2016 at 01:55:36PM +0100, Maarten Lankhorst wrote: >> This is a hack and not needed. Use the right mask by checking >> intel_state->modeset. This works for watermark sanitization too. >> >> Signed-off-by: Maarten Lankhorst

[Intel-gfx] [PATCH] qf: Document how to bisect the patch pile history

Rodrigo recently asked me about this, and I totally failed to properly document it! Cc: Rodrigo Vivi Signed-off-by: Daniel Vetter --- qf | 19 +++ 1 file changed, 19 insertions(+) diff --git a/qf b/qf index

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Demote i915_gem_open() debugging from DRIVER to USER

== Series Details == Series: drm/i915: Demote i915_gem_open() debugging from DRIVER to USER URL : https://patchwork.freedesktop.org/series/15023/ State : success == Summary == Series 15023v1 drm/i915: Demote i915_gem_open() debugging from DRIVER to USER

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gvt: Disable access to stolen memory as a guest

== Series Details == Series: drm/i915/gvt: Disable access to stolen memory as a guest URL : https://patchwork.freedesktop.org/series/15022/ State : warning == Summary == Series 15022v1 drm/i915/gvt: Disable access to stolen memory as a guest

  1   2   >