Re: [Intel-gfx] [PATCH 2/2] drm/i915/gvt: fix compilation

On 2016.10.21 17:25:50 +0200, Arnd Bergmann wrote: > Two functions in the newly added gvt render code are obviously > broken, as they reference a variable without initialization and > don't reference another variable at all: > > drivers/gpu/drm/i915/gvt/render.c: In function >

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gvt: add ACPI and 64BIT dependencies

On 2016.10.21 17:25:49 +0200, Arnd Bergmann wrote: > The newly added gvt code produces lots of serious warnings and errors > when either built on 32-bit x86, or built with ACPI disabled, e.g. > > drivers/gpu/drm/i915/gvt/gtt.c: In function ???read_pte64???: > drivers/gpu/drm/i915/gvt/gtt.c:277:2:

[Intel-gfx] ✗ Fi.CI.BAT: warning for Handle link training failure for DDI platforms

== Series Details == Series: Handle link training failure for DDI platforms URL : https://patchwork.freedesktop.org/series/14192/ State : warning == Summary == Series 14192v1 Handle link training failure for DDI platforms

[Intel-gfx] [PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

This function provides a way for the driver to redo a modeset on the current mode and retry the link training at a lower link rate/lane count/bpp. This will get called incase the link training fails during the current modeset. Cc: dri-de...@lists.freedesktop.org Cc: Jani Nikula

[Intel-gfx] [PATCH 4/5] drm/i915; Add a function to return index of link rate

This is required to return the index of link rate into common_rates array. This gets used to retry the link training at lower link rate. Cc: Jani Nikula Cc: Daniel Vetter Cc: Ville Syrjala Signed-off-by:

[Intel-gfx] [PATCH 0/5] Handle link training failure for DDI platforms

According to the DP spec 1.2, link training failure needs to be handled by lowering the link rate and retraining the link. These patches implement this link rate fallback. Currently the driver trains the link in atomic commit. This could fail if Clock Recovery or Channel EQ fails during actual

[Intel-gfx] [PATCH 2/5] drm: Define a work struct for scheduling a uevent for modeset retry

This work struct will be used to schedule a uevent on a separate thread. This will be scheduled after a link train failure during modeset to indicate a modeset retry request. It will get executed after the current modeset is complete and all locks are released. This was required to avoid deadlock.

[Intel-gfx] [PATCH 5/5] drm/i915: 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 and use a lower link rate to prune the modes. It will redo the modeset on the current

[Intel-gfx] [PATCH 3/5] drm/i915: Change the placement of some static functions in intel_dp.c

From: "Navare, Manasi D" These static helper functions are required to be used during fallback link rate implemnetation so they need to be placed at the top of the file. v3: * Add cleanup to other patch (Mika Kahola) v2: * Dont move around functions declared in

Re: [Intel-gfx] [PATCH] drm/i915: Stop setting SNB min-freq-table 0 on powersave setup

On Fri, Oct 21, 2016 at 09:55:31PM +0100, Chris Wilson wrote: > The min-freq-table is an array of values that match each CPU frequency to > an equivalent GPU frequency. Setting a single value of 0 on init is both > illegal (generates an error from the PCU) and nonsensical. Let's see if > we

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Stop setting SNB min-freq-table 0 on powersave setup

== Series Details == Series: drm/i915: Stop setting SNB min-freq-table 0 on powersave setup URL : https://patchwork.freedesktop.org/series/14187/ State : failure == Summary == Series 14187v1 drm/i915: Stop setting SNB min-freq-table 0 on powersave setup

[Intel-gfx] [PATCH] drm/i915: Stop setting SNB min-freq-table 0 on powersave setup

The min-freq-table is an array of values that match each CPU frequency to an equivalent GPU frequency. Setting a single value of 0 on init is both illegal (generates an error from the PCU) and nonsensical. Let's see if we survive without that error. Signed-off-by: Chris Wilson

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm: i915: Wait for fences on new fb, not old

On Fri, Oct 21, 2016 at 07:49:34PM +0100, Daniel Stone wrote: >Hi, > >On Friday, 21 October 2016, Patchwork ><[1]patchw...@emeril.freedesktop.org> wrote: > > Test gem_ringfill: >         Subgroup basic-default-hang: >                 pass       -> TIMEOUT   

[Intel-gfx] [PATCH] igt/gem_exec_parse: update for version 8 changes

Just wanted to show how I'd been looking at updating gem_exec_parse considering my interface change to stop returning EINVAL to userspace. I think maybe it'd be good to split the patch up since I moved things around a bit, but hopefully it's not too bad to skim for now. I wasn't quite sure what

[Intel-gfx] [PATCH 08/18] dim: remove integration-tree remotes

With the remotes stored in nightly.conf and git worktrees we can avoid hard-coding them in even more places. Signed-off-by: Daniel Vetter --- dim | 12 1 file changed, 12 deletions(-) diff --git a/dim b/dim index adaffecf4015..3792abe4d190 100755 --- a/dim

[Intel-gfx] [PATCH 00/18] dim: split out drm-misc/tip.git

Hi all, So here's all the bits I think we need for: - split out drm-misc.git repo - rolling model in drm-misc to avoid the merge window, like for drm-intel branches. - split out rerere stuff into a shared drm-tip.git repo - sharing .git metadata using git worktrees. Conversion howto: 1. Update

[Intel-gfx] [PATCH 16/18] dim: remove DIM_DRM_UPSTREAM_REMOTE config var

With the automatic remote lookup this is no longer needed. That means moving get_remote_name a bit, and I'm too lazy to rebase that out. v2: Wrap strings in "" (Jani). Signed-off-by: Daniel Vetter --- dim | 56

[Intel-gfx] [PATCH 05/18] dim: support git worktree for aux checkouts

If available by default. This saves quite a pile of disk-space that imo making it the default is justified. Note that this will break the rebuild-nightly script for now, follow-up patches will fix that. Signed-off-by: Daniel Vetter --- dim | 23 ---

[Intel-gfx] [PATCH 06/18] dim: Nuke nightly-forget

With our proliferation of branches it's become long useless. Nowadays my MO is to revert the offending commit in the rerere-cache branch explicitly, remove drm-intel-nightly/.git/rr-cache and then re-run rebuild-nightly. That works much better, hence nuke this helper. Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH 09/18] dim: Split out drm-nightly.git

This is a prep step to eventually split out the drm-misc branches all into their own repo. To get there we first need to split out the integration tree mangling. Since dim doesn't auto-update and since the transition is a good reason to switch over to worktrees and it's tricky it's not scripted.

[Intel-gfx] [PATCH 13/18] dim: use get_maintainers.pl in dim fixes

For even more Cc! Result is sometimes a bit excessive and will need some trimming sometimes. v2: Don't sort, since that makes a mess of the list. Signed-off-by: Daniel Vetter --- dim | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/dim b/dim

[Intel-gfx] [PATCH 14/18] dim-update-next: Update DRIVER_TIMESTAMP

From: Chris Wilson Along with the DRIVER_DATE, also update the DRIVER_TIMESTAMP as measured in seconds from the start of the epoch. Signed-off-by: Chris Wilson Cc: Daniel Vetter Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH 18/18] dim: Make update_linux_next multi-repo compliant

- Only update the for-linux-next branches in the repo for the branch just pushed. - Roll out the same logic (to allow us to always merge feature patches) for drm-misc. Signed-off-by: Daniel Vetter --- dim | 67

[Intel-gfx] [PATCH 11/18] dim: use git branch --list

... instead of git branch | grep. Handles submatches and branches starting with - reliably. Motivated by a review from Jani. Cc: Jani Nikula Signed-off-by: Daniel Vetter --- dim | 10 +- 1 file changed, 5 insertions(+), 5

[Intel-gfx] [PATCH 17/18] dim: Adapat create/remove-branch

Looking up the remote for deleting the branch is a bit an exercise. v2: Correctly keep the fake remote name from nightly.conf and the real (local) remote name apart. Signed-off-by: Daniel Vetter --- dim | 54 +-

[Intel-gfx] [PATCH 15/18] dim: support multiple remotes for branches

Still left to do is fixing up create-branch and remove-branch. Everything else should work here now. Signed-off-by: Daniel Vetter --- dim | 36 ++-- 1 file changed, 26 insertions(+), 10 deletions(-) diff --git a/dim b/dim index

[Intel-gfx] [PATCH 10/18] dim: s/drm-nightly/drm-tip

tip = testing and integration pile Also rename drm-intel-rerere directory to drm-rerere. v2: don't call get_remote_name before switching directories. Signed-off-by: Daniel Vetter --- dim| 52 ++-- dim.rst

[Intel-gfx] [PATCH 07/18] dim: autodetect branches in rebuild-nightly

Needs new url-mapping information in nightly.conf to work properly. v2: - Fix typo when calling rr_cache_dir. Oops. - Use cut -f 1 instead of sed/regex horrors (jani). v3: Fix bug that resulted in nesting rr-cache directories. Signed-off-by: Daniel Vetter --- dim | 50

[Intel-gfx] [PATCH 12/18] dim: add revert-rerere

Encodes the best practices for undoing a botched-up conflict resolution. Signed-off-by: Daniel Vetter --- dim | 7 +++ dim.rst | 12 +++- 2 files changed, 18 insertions(+), 1 deletion(-) diff --git a/dim b/dim index d01407a7b10c..91aa99f230e7 100755

[Intel-gfx] [PATCH 03/18] dim: echoerr helper for printing to stderr

Signed-off-by: Daniel Vetter --- dim | 19 --- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/dim b/dim index 192d6ee10838..2601bb7dbbad 100755 --- a/dim +++ b/dim @@ -102,12 +102,17 @@ DRY= FORCE= HELP= +function echoerr +{ +

[Intel-gfx] [PATCH 04/18] dim: autodetect remotes, first part for dim_setup

The goals here are multiple: - simpler configuration through autodetection - allows seamless upgrading to git worktree for the aux checkouts - eventually I want to split up drm-misc into a separate remote ... And yes this is just a start. v2: Print errors to stderr, otherwise they can't be seen

[Intel-gfx] [PATCH 02/18] dim: Autocheck for up-to-dateness

Exits script to annoy people roughly every 100th time ... Also switch to the magic @{upstream} reference, in case the remote is not called origin (which is pretty normal in case of using git worktree). Signed-off-by: Daniel Vetter --- dim | 6 +- 1 file changed, 5

[Intel-gfx] [PATCH 01/18] dim: Extract TODO

Just maybe a bit more visibility, the scripts are growing. Signed-off-by: Daniel Vetter --- TODO | 27 +++ dim | 17 - qf | 11 --- 3 files changed, 27 insertions(+), 28 deletions(-) create mode 100644 TODO diff --git

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm: i915: Wait for fences on new fb, not old

> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm: i915: Wait for fences > on new fb, not old > > On Friday, 21 October 2016, Patchwork > wrote: > > Test gem_ringfill: > Subgroup

[Intel-gfx] [PATCH v3 0/6] drm: Per-plane rotation etc.

From: Ville Syrjälä Remainder of the patches from the per-plane rotation series [1]. Rebased and also Rob's r-b picked up from [2]. [1] https://lists.freedesktop.org/archives/dri-devel/2016-September/119451.html [2]

[Intel-gfx] [PATCH v2 5/6] drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup

From: Ville Syrjälä Move the plane control register rotation setup away from the coordinate munging code. This will result in neater looking code once we add reflection support for CHV. v2: Drop the BIT(), drop some usless parens, Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH v3 6/6] drm/i915: Add horizontal mirroring support for CHV pipe B planes

From: Ville Syrjälä The primary and sprite planes on CHV pipe B support horizontal mirroring. Expose it to the world. Sadly the hardware ignores the mirror bit when the rotate bit is set, so we'll have to reject the 180+X case. v2: Drop the BIT() v3: Pass

[Intel-gfx] [PATCH v2 1/6] drm/msm/mdp5: Use per-plane rotation property

From: Ville Syrjälä The global mode_config.rotation_property is going away, switch over to per-plane rotation_property. v2: Drop the BIT() Cc: Rob Clark Cc: Jilai Wang Cc: Archit Taneja

[Intel-gfx] [PATCH v2 4/6] drm/i915: Use & instead if == to check for rotations

From: Ville Syrjälä Using == to check for 180 degree rotation only works as long as the reflection bits aren't set. That will change soon enough for CHV, so let's stop doing things the wrong way. v2: Drop the BIT() Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v6,01/11] drm/i915: Add i915 perf infrastructure (rev2)

> == Series Details == > > Series: series starting with [v6,01/11] drm/i915: Add i915 perf infrastructure > (rev2) > URL : https://patchwork.freedesktop.org/series/14135/ > State : failure > > == Summary == > > Series 14135v2 Series without cover letter >

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm: i915: Wait for fences on new fb, not old

Hi, On Friday, 21 October 2016, Patchwork wrote: > > Test gem_ringfill: > Subgroup basic-default-hang: > pass -> TIMEOUT(fi-hsw-4770r) > Subgroup basic-default-interruptible: > pass -> INCOMPLETE

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v6,01/11] drm/i915: Add i915 perf infrastructure (rev2)

== Series Details == Series: series starting with [v6,01/11] drm/i915: Add i915 perf infrastructure (rev2) URL : https://patchwork.freedesktop.org/series/14135/ State : failure == Summary == Series 14135v2 Series without cover letter

[Intel-gfx] [PATCH] drm/i915: Enable i915 perf stream for Haswell OA unit

Gen graphics hardware can be set up to periodically write snapshots of performance counters into a circular buffer via its Observation Architecture and this patch exposes that capability to userspace via the i915 perf interface. v2: Make sure to initialize ->specific_ctx_id when opening,

Re: [Intel-gfx] [PATCH v6 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

On Thu, Oct 20, 2016 at 11:10 PM, Chris Wilson wrote: > On Thu, Oct 20, 2016 at 10:19:05PM +0100, Robert Bragg wrote: > > +int i915_gem_context_pin_legacy_rcs_state(struct drm_i915_private > *dev_priv, > > + struct i915_gem_context

Re: [Intel-gfx] i915 monitor hotplug on 4.1/4.4 PREEMPT

On Fri, Oct 21, 2016 at 04:21:53PM +0300, Nicolae Rosia wrote: > Hello, > > On Fri, Oct 21, 2016 at 3:27 PM, Daniel Vetter wrote: > > So yeah, "upgrade" is very likely is. > I see... > > i915.disable_power_well=0 seems to do the trick. > Is it safe to use? The kernel gets

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/fbc: fix CFB size calculation for gen8+

== Series Details == Series: series starting with [1/2] drm/i915/fbc: fix CFB size calculation for gen8+ URL : https://patchwork.freedesktop.org/series/14173/ State : warning == Summary == Series 14173v1 Series without cover letter

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/gvt: add ACPI and 64BIT dependencies

== Series Details == Series: series starting with [1/2] drm/i915/gvt: add ACPI and 64BIT dependencies URL : https://patchwork.freedesktop.org/series/14170/ State : warning == Summary == Series 14170v1 Series without cover letter

Re: [Intel-gfx] [PATCH v2 08/15] drm/msm/mdp5: Set rotation property initial value to BIT(DRM_ROTATE_0) insted of 0

On Fri, Oct 21, 2016 at 06:26:54PM +0200, Daniel Vetter wrote: > On Mon, Sep 26, 2016 at 07:30:53PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > 0 isn't a valid rotation property value, so let's set the initial value > > of the

[Intel-gfx] Are these known failures for the Intel Skylake graphics card?

Hi I recently updated from a T540p to a T460, and I've been noticing that the laptop doesn't always come back from a suspend. This is on a kernel which is 4.8.0 plus the ext4 development branch (since merged in Linus's tree): Oct 18 11:36:07 callcc kernel: [78989.876606] general protection

Re: [Intel-gfx] [PATCH v3 11/15] drm/i915: Use the per-plane rotation property

On Tue, Sep 27, 2016 at 12:58:49PM +0300, Joonas Lahtinen wrote: > On ma, 2016-09-26 at 19:30 +0300, ville.syrj...@linux.intel.com wrote: > > > From: Ville Syrjälä > > > > On certain platforms not all planes support the same set of > > rotations/reflections, so

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: i915: Wait for fences on new fb, not old

== Series Details == Series: drm: i915: Wait for fences on new fb, not old URL : https://patchwork.freedesktop.org/series/14168/ State : failure == Summary == Series 14168v1 drm: i915: Wait for fences on new fb, not old https://patchwork.freedesktop.org/api/1.0/series/14168/revisions/1/mbox/

Re: [Intel-gfx] [PATCH v2 08/15] drm/msm/mdp5: Set rotation property initial value to BIT(DRM_ROTATE_0) insted of 0

On Mon, Sep 26, 2016 at 07:30:53PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > 0 isn't a valid rotation property value, so let's set the initial value > of the property to BIT(DRM_ROTATE_0) instead. > > In the same vein, we must always

Re: [Intel-gfx] [PATCH v3 03/15] drm: Add support for optional per-plane rotation property

On Tue, Sep 27, 2016 at 01:22:48PM +0300, Ville Syrjälä wrote: > On Tue, Sep 27, 2016 at 12:54:46PM +0300, Joonas Lahtinen wrote: > > On ma, 2016-09-26 at 19:30 +0300, ville.syrj...@linux.intel.com wrote: > > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > > > > > >

Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: fix FBC_COMPRESSION_MASK on BDW+

On Fri, Oct 21, 2016 at 01:55:46PM -0200, Paulo Zanoni wrote: > Its size is 11:0 instead of 10:0. Found by inspecting the spec. I'm > not aware of any real-world IGT failures caused by this. > > Signed-off-by: Paulo Zanoni > --- > drivers/gpu/drm/i915/i915_debugfs.c |

Re: [Intel-gfx] [PATCH 1/2] drm/i915/fbc: fix CFB size calculation for gen8+

On Fri, Oct 21, 2016 at 01:55:45PM -0200, Paulo Zanoni wrote: > Broadwell and newer actually compress up to 2560 lines instead of 2048 > (as documented in the FBC_CTL page). If we don't take this into > consideration we end up reserving too little stolen memory for the > CFB, so we may allocate

[Intel-gfx] ✗ Fi.CI.BAT: failure for Avoid pessimistic scatter-gather allocation

== Series Details == Series: Avoid pessimistic scatter-gather allocation URL : https://patchwork.freedesktop.org/series/14166/ State : failure == Summary == Series 14166v1 Avoid pessimistic scatter-gather allocation https://patchwork.freedesktop.org/api/1.0/series/14166/revisions/1/mbox/

Re: [Intel-gfx] [PATCH v6 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

On Thu, Oct 20, 2016 at 11:10 PM, Chris Wilson wrote: > On Thu, Oct 20, 2016 at 10:19:05PM +0100, Robert Bragg wrote: > > +int i915_gem_context_pin_legacy_rcs_state(struct drm_i915_private > *dev_priv, > > + struct i915_gem_context

Re: [Intel-gfx] [PATCH] drm/i915: Refresh that status of MST capable connectors in ->detect()

On Fri, Oct 21, 2016 at 04:46:38PM +0100, Chris Wilson wrote: > On Fri, Oct 21, 2016 at 04:44:38PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Once we've determined that the sink is MST capable we never end up > > running through the

[Intel-gfx] [PATCH 2/2] drm/i915/fbc: fix FBC_COMPRESSION_MASK on BDW+

Its size is 11:0 instead of 10:0. Found by inspecting the spec. I'm not aware of any real-world IGT failures caused by this. Signed-off-by: Paulo Zanoni --- drivers/gpu/drm/i915/i915_debugfs.c | 10 ++ drivers/gpu/drm/i915/i915_reg.h | 5 +++-- 2 files

[Intel-gfx] [PATCH 1/2] drm/i915/fbc: fix CFB size calculation for gen8+

Broadwell and newer actually compress up to 2560 lines instead of 2048 (as documented in the FBC_CTL page). If we don't take this into consideration we end up reserving too little stolen memory for the CFB, so we may allocate something else (such as a ring) right after what we reserved, and the

Re: [Intel-gfx] [PATCH] drm/i915: Refresh that status of MST capable connectors in ->detect()

On Fri, Oct 21, 2016 at 04:44:38PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Once we've determined that the sink is MST capable we never end up > running through the full detect cycle again, despite getting HPDs. > Fix tht by ripping out

[Intel-gfx] [PATCH 1/2] drm/i915/gvt: add ACPI and 64BIT dependencies

The newly added gvt code produces lots of serious warnings and errors when either built on 32-bit x86, or built with ACPI disabled, e.g. drivers/gpu/drm/i915/gvt/gtt.c: In function ‘read_pte64’: drivers/gpu/drm/i915/gvt/gtt.c:277:2: error: left shift count >= width of type [-Werror]

Re: [Intel-gfx] [PATCH] drm/i915: Always send a hotplug event after resume

On Fri, Oct 21, 2016 at 11:16:07AM +0100, Chris Wilson wrote: > Curently after resume we reset all connector status to unknown and then > try to tell userspace about the probable changes (e.g. a laptop being > unplugged from one dock and plugged into another). However, we call >

[Intel-gfx] [PATCH 2/2] drm/i915/gvt: fix compilation

Two functions in the newly added gvt render code are obviously broken, as they reference a variable without initialization and don't reference another variable at all: drivers/gpu/drm/i915/gvt/render.c: In function ‘intel_gvt_load_render_mmio’: drivers/gpu/drm/i915/gvt/render.c:148:13: error:

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Use __sg_alloc_table_from_pages for allocating object backing store

On 21/10/2016 15:27, Chris Wilson wrote: On Fri, Oct 21, 2016 at 03:11:22PM +0100, Tvrtko Ursulin wrote: @@ -2236,18 +2233,16 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj) BUG_ON(obj->base.read_domains & I915_GEM_GPU_DOMAINS); BUG_ON(obj->base.write_domain

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gvt: fix compilation errors in gtt.c

== Series Details == Series: drm/i915/gvt: fix compilation errors in gtt.c URL : https://patchwork.freedesktop.org/series/14165/ State : warning == Summary == Series 14165v1 drm/i915/gvt: fix compilation errors in gtt.c https://patchwork.freedesktop.org/api/1.0/series/14165/revisions/1/mbox/

[Intel-gfx] [PATCH] drm: i915: Wait for fences on new fb, not old

The previous code would wait for fences on the framebuffer from the old plane state to complete, rather than the new, so you would see tearing everywhere. Fix this to wait on the new state before we make it active. Signed-off-by: Daniel Stone Fixes: 94f050246b42

Re: [Intel-gfx] [patch] drm/i915/gvt: cleanup a type issue in submit_context()

On Fri, Oct 21, 2016 at 04:27:38PM +0800, Zhenyu Wang wrote: > On 2016.10.21 11:06:01 +0300, Dan Carpenter wrote: > > submit_context() should return negative error codes and zero on success > > but by mistake we made it a bool. I've changed it to int. Also I made > > it static because this isn't

Re: [Intel-gfx] [RESEND PATCH 4/6] drm/i915: Update atomic modeset state synchronously

On Wed, Oct 19, 2016 at 03:55:37PM +0200, Maarten Lankhorst wrote: > All of this state should be updated as soon as possible. It shouldn't be > done later because then future updates may not depend on it. > > Signed-off-by: Maarten Lankhorst > --- >

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Use __sg_alloc_table_from_pages for allocating object backing store

On Fri, Oct 21, 2016 at 03:11:22PM +0100, Tvrtko Ursulin wrote: > @@ -2236,18 +2233,16 @@ i915_gem_object_get_pages_gtt(struct > drm_i915_gem_object *obj) > BUG_ON(obj->base.read_domains & I915_GEM_GPU_DOMAINS); > BUG_ON(obj->base.write_domain & I915_GEM_GPU_DOMAINS); > > -

[Intel-gfx] [PATCH 2/5] lib/scatterlist: Avoid potential scatterlist entry overflow

From: Tvrtko Ursulin Since the scatterlist length field is an unsigned int, make sure that sg_alloc_table_from_pages does not overflow it while coallescing pages to a single entry. It is I think only a theoretical possibility at the moment, but the ability to limit the

Re: [Intel-gfx] [RESEND PATCH 4/6] drm/i915: Update atomic modeset state synchronously

On Wed, Oct 19, 2016 at 03:55:37PM +0200, Maarten Lankhorst wrote: > All of this state should be updated as soon as possible. It shouldn't be > done later because then future updates may not depend on it. > > Signed-off-by: Maarten Lankhorst > --- >

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Broxton ddi phy refactoring (rev5)

On Fri, Oct 21, 2016 at 05:16:45PM +0300, Ander Conselvan De Oliveira wrote: > On Wed, 2016-10-19 at 16:56 +, Patchwork wrote: > > == Series Details == > > > > Series: Broxton ddi phy refactoring (rev5) > > URL   : https://patchwork.freedesktop.org/series/13320/ > > State : failure > > > >

Re: [Intel-gfx] [RESEND PATCH 3/6] drm/edid: Remove drm_select_eld

On Fri, Oct 21, 2016 at 05:05:16PM +0300, Ville Syrjälä wrote: > On Wed, Oct 19, 2016 at 03:55:36PM +0200, Maarten Lankhorst wrote: > > The only user was i915, which is now gone. > > > > Signed-off-by: Maarten Lankhorst > > cc: dri-devel missing Also

Re: [Intel-gfx] [RESEND PATCH 2/6] drm/i915: Pass atomic state to intel_audio_codec_enable

On Fri, Oct 21, 2016 at 05:04:46PM +0300, Ville Syrjälä wrote: > On Wed, Oct 19, 2016 at 03:55:35PM +0200, Maarten Lankhorst wrote: > > drm_select_eld requires mode_config.mutex and connection_mutex > > because it looks at the connector list and at the legacy encoders. > > > > This is not

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Refresh that status of MST capable connectors in ->detect()

== Series Details == Series: drm/i915: Refresh that status of MST capable connectors in ->detect() URL : https://patchwork.freedesktop.org/series/14163/ State : failure == Summary == Series 14163v1 drm/i915: Refresh that status of MST capable connectors in ->detect()

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Broxton ddi phy refactoring (rev5)

On Wed, 2016-10-19 at 16:56 +, Patchwork wrote: > == Series Details == > > Series: Broxton ddi phy refactoring (rev5) > URL   : https://patchwork.freedesktop.org/series/13320/ > State : failure > > == Summary == > > Series 13320v5 Broxton ddi phy refactoring >

Re: [Intel-gfx] [RESEND PATCH 1/6] drm/i915: Convert intel_hdmi to use atomic state

On Wed, Oct 19, 2016 at 03:55:34PM +0200, Maarten Lankhorst wrote: > This is the last connector still looking at crtc->config. Fix this. > > Signed-off-by: Maarten Lankhorst looks all right Reviewed-by: Ville Syrjälä > --- >

[Intel-gfx] [PATCH 4/5] drm/i915: Use __sg_alloc_table_from_pages for allocating object backing store

From: Tvrtko Ursulin With the current way of allocating backing store which over-estimates the number of sg entries required we typically waste around 1-6 MiB of memory on unused sg entries at runtime. We can instead have the intermediate step of storing our pages in

[Intel-gfx] [PATCH 5/5] drm/i915: Use __sg_alloc_table_from_pages for userptr allocations

From: Tvrtko Ursulin With the addition of __sg_alloc_table_from_pages we can control the maximum coallescing size and eliminate a separate path for allocating backing store here. This also makes the tables as compact as possible in all cases. Signed-off-by: Tvrtko

[Intel-gfx] [PATCH 0/5] Avoid pessimistic scatter-gather allocation

From: Tvrtko Ursulin We can decrease the i915 kernel memory usage by doing more sg list coallescing and avoiding the pessimistic list allocation. At the moment we got two places in our code, the main shmemfs backed object allocator, and the userptr object allocator,

[Intel-gfx] [PATCH 1/5] lib/scatterlist: Fix offset type in sg_alloc_table_from_pages

From: Tvrtko Ursulin Scatterlist entries have an unsigned int for the offset so correct the sg_alloc_table_from_pages function accordingly. Since these are offsets withing a page, unsigned int is wide enough. Also converts callers which were using unsigned long

[Intel-gfx] [PATCH 3/5] lib/scatterlist: Introduce and export __sg_alloc_table_from_pages

From: Tvrtko Ursulin Drivers like i915 benefit from being able to control the maxium size of the sg coallesced segment while building the scatter- gather list. Introduce and export the __sg_alloc_table_from_pages function which will allow it that control.

Re: [Intel-gfx] [RESEND PATCH 3/6] drm/edid: Remove drm_select_eld

On Wed, Oct 19, 2016 at 03:55:36PM +0200, Maarten Lankhorst wrote: > The only user was i915, which is now gone. > > Signed-off-by: Maarten Lankhorst cc: dri-devel missing > --- > drivers/gpu/drm/drm_edid.c | 26 -- >

[Intel-gfx] [PATCH v2] drm/i915: Move fence cancellation to runtime suspend

At the moment, we have dependency on the RPM as a barrier itself in both i915_gem_release_all_mmaps() and i915_gem_restore_fences(). i915_gem_restore_fences() is also called along !runtime pm paths, but we can move the markup of lost fences alongside releasing the mmaps into a common

Re: [Intel-gfx] [RESEND PATCH 2/6] drm/i915: Pass atomic state to intel_audio_codec_enable

On Wed, Oct 19, 2016 at 03:55:35PM +0200, Maarten Lankhorst wrote: > drm_select_eld requires mode_config.mutex and connection_mutex > because it looks at the connector list and at the legacy encoders. > > This is not required, because when we call audio_codec_enable we know > which connector it

Re: [Intel-gfx] [PATCH] drm/i915: fix comment referencing imaginary functions

On Fri, Oct 21, 2016 at 04:00:10PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > On Fri, Oct 21, 2016 at 02:16:46PM +0200, Arkadiusz Hiler wrote: > >> On Wed, Aug 24, 2016 at 05:03:11PM +0100, Matthew Auld wrote: > >> > The comment which documents the proper

[Intel-gfx] [PATCH 2/2] drm/i915/gvt: fix an error string format

It is better to use %p format for void pointers instead of casting them because a void* is not necessary a 64 bits value. Signed-off-by: Jérémy Lefaure --- drivers/gpu/drm/i915/gvt/gtt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [Intel-gfx] [PATCH 05/41] drm/i915: Move fence cancellation to runtime suspend

On Fri, Oct 21, 2016 at 03:48:27PM +0300, Imre Deak wrote: > On to, 2016-10-20 at 16:03 +0100, Chris Wilson wrote: > > At the moment, we have dependency on the RPM as a barrier itself in both > > i915_gem_release_all_mmaps() and i915_gem_restore_fences(). > > i915_gem_restore_fences() is also

[Intel-gfx] [patch] drm/i915/gvt: i915_gem_object_create() returns error pointers

The i915_gem_object_create() returns error pointers on error, it never returns NULLs. Fixes: ("drm/i915/gvt: vGPU command scanner") Signed-off-by: Dan Carpenter --- The error handling in perform_bb_shadow() is a bit leaky as well. diff --git

[Intel-gfx] [PATCH 0/2] drm/i915/gvt: fix compilation errors in gtt.c

This series fixes 2 compilations errors in gvt/gtt.c on 32-bits platform: [PATCH 1/2] drm/i915/gvt: fix bad 32 bit shift in gtt [PATCH 2/2] drm/i915/gvt: fix an error string format The file gtt.c still does not compile because of shifting errors. Should the 32 bits architecture be supported ?

[Intel-gfx] [PATCH 1/2] drm/i915/gvt: fix bad 32 bit shift in gtt

Since ioread32 returns a 32-bit value, it is impossible to left-shift this value by 32 bits (it produces a compilation error). Casting the return value of ioread32 fix this issue. Signed-off-by: Jérémy Lefaure --- drivers/gpu/drm/i915/gvt/gtt.c | 2 +- 1 file

[Intel-gfx] [PATCH] drm/i915: Refresh that status of MST capable connectors in ->detect()

From: Ville Syrjälä Once we've determined that the sink is MST capable we never end up running through the full detect cycle again, despite getting HPDs. Fix tht by ripping out the incorrect piece of code responsible. This got broken when I moved the long HPD

Re: [Intel-gfx] i915 monitor hotplug on 4.1/4.4 PREEMPT

Hello, On Fri, Oct 21, 2016 at 3:27 PM, Daniel Vetter wrote: > So yeah, "upgrade" is very likely is. I see... i915.disable_power_well=0 seems to do the trick. Is it safe to use? The kernel gets tainted because of this. Regards, Nicolae

Re: [Intel-gfx] [PATCH v3 3/4] drm/i915: Clean up DDI DDC/AUX CH sanitation

On Fri, Oct 21, 2016 at 12:00:56AM +0200, Maarten Maathuis wrote: > I meant DON't suspect > > On Thu, Oct 20, 2016 at 11:53 PM, Maarten Maathuis > wrote: > > > Also tested v3 on top of 4.8.3 (mainline git is a mess right now for > > booting). > > > > I did encounter a

Re: [Intel-gfx] [PATCH v2] drm: Pass along the hotplug connector to the uevent

On Fri, Oct 21, 2016 at 02:45:41PM +0200, Daniel Vetter wrote: > On Fri, Oct 21, 2016 at 10:14:21AM +0100, Chris Wilson wrote: > > If we know which connector was plugged/unplugged or > > connected/disconnected, we can pass that information along to userspace > > inside the uevent to reduce the

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2)

On Thu, Oct 20, 2016 at 10:39:57AM +0100, Matthew Auld wrote: > On 19 October 2016 at 22:47, Patchwork > wrote: > > == Series Details == > > > > Series: drm/i915/dp: add lane_count check in intel_dp_check_link_status > > (rev2) > > URL :

Re: [Intel-gfx] [PATCH] drm/i915: fix comment referencing imaginary functions

Chris Wilson writes: > On Fri, Oct 21, 2016 at 02:16:46PM +0200, Arkadiusz Hiler wrote: >> On Wed, Aug 24, 2016 at 05:03:11PM +0100, Matthew Auld wrote: >> > The comment which documents the proper usage of the *_FW family of macros >> > makes >> > reference to

Re: [Intel-gfx] [PATCH 05/41] drm/i915: Move fence cancellation to runtime suspend

On to, 2016-10-20 at 16:03 +0100, Chris Wilson wrote: > At the moment, we have dependency on the RPM as a barrier itself in both > i915_gem_release_all_mmaps() and i915_gem_restore_fences(). > i915_gem_restore_fences() is also called along !runtime pm paths, but we > can move the markup of lost

Re: [Intel-gfx] [PATCH v2] drm: Pass along the hotplug connector to the uevent

On Fri, Oct 21, 2016 at 10:14:21AM +0100, Chris Wilson wrote: > If we know which connector was plugged/unplugged or > connected/disconnected, we can pass that information along to userspace > inside the uevent to reduce the amount of work userspace has to perform > after the event (i.e. instead of

  1   2   >