Re: [Intel-gfx] [PATCH v2 07/10] drm/i915: Undiplicate VLV signal level code

On Tue, 2016-04-19 at 13:37 -0700, Jim Bride wrote: > On Wed, Apr 13, 2016 at 08:47:50PM +0300, Ander Conselvan de Oliveira wrote: > > The logic for setting signal levels is used for both HDMI and DP with > > small variations. But it is similar enough to put behind a function > > called from the

[Intel-gfx] [PATCH v2 07/18] drm/i915: Undiplicate VLV signal level code

The logic for setting signal levels is used for both HDMI and DP with small variations. But it is similar enough to put behind a function called from the encoders. v2: Remove unrelated MST changes due to rebase fumble. (Jim Bride) Fix typo in the commit message. (Jim Bride) Cc: Jim Bride

[Intel-gfx] [PATCH v2 06/18] drm/i915: Unduplicate CHV encoders' post pll disable code

The exact same code was used by HDMI and DP encoders, so move it to intel_dpio_phy.c. v2: Fix typo in the commit message. (Jim Bride) Cc: Jim Bride Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH v2 12/16] drm/i915/gen9: Use a bitmask to track dirty pipe watermarks

Slightly easier to work with than an array of bools. Signed-off-by: Matt Roper Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_pm.c | 10 +- 2 files changed, 6

[Intel-gfx] [PATCH v2 14/16] drm/i915/gen9: Calculate watermarks during atomic 'check'

Moving watermark calculation into the check phase will allow us to to reject display configurations for which there are no valid watermark values before we start trying to program the hardware (although those tests will come in a subsequent patch). Another advantage of moving this calculation to

[Intel-gfx] [PATCH v2 13/16] drm/i915/gen9: Propagate watermark calculation failures up the call chain

Once we move watermark calculation to the atomic check phase, we'll want to start rejecting display configurations that exceed out watermark limits. At the moment we just assume that there's always a valid set of watermarks, even though this may not actually be true. Let's prepare by passing

[Intel-gfx] [PATCH v2 16/16] drm/i915: Remove wm_config from dev_priv/intel_atomic_state

We calculate the watermark config into intel_atomic_state and then save it into dev_priv, but never actually use it from there. This is left-over from some early ILK-style watermark programming designs that got changed over time. Signed-off-by: Matt Roper Reviewed-by:

[Intel-gfx] [PATCH v2 07/16] drm/i915/gen9: Allow skl_allocate_pipe_ddb() to operate on in-flight state (v2)

We eventually want to calculate watermark values at atomic 'check' time instead of atomic 'commit' time so that any requested configurations that result in impossible watermark requirements are properly rejected. The first step along this path is to allocate the DDB at atomic 'check' time. As we

[Intel-gfx] [PATCH v2 15/16] drm/i915/gen9: Reject display updates that exceed wm limitations

If we can't find any valid level 0 watermark values for the requested atomic transaction, reject the configuration before we try to start programming the hardware. Signed-off-by: Matt Roper Reviewed-by: Maarten Lankhorst ---

[Intel-gfx] [PATCH v2 06/16] drm/i915: Track whether an atomic transaction changes the active CRTC's

For the purposes of DDB re-allocation we need to know whether a transaction changes the list of CRTC's that are active. While state->modeset could be used for this purpose, that would be slightly too aggressive since it would lead us to re-allocate the DDB when a CRTC's mode changes, but not its

[Intel-gfx] [PATCH v2 09/16] drm/i915/gen9: Drop re-allocation of DDB at atomic commit (v2)

Now that we're properly pre-allocating the DDB during the atomic check phase and we trust that the allocation is appropriate, let's actually use the allocation computed and not duplicate that work during the commit phase. v2: - Significant rebasing now that we can use cached data rates and

[Intel-gfx] [PATCH v2 05/16] drm/i915/gen9: Store plane minimum blocks in CRTC wm state

This will eventually allow us to re-use old values without re-calculating them for unchanged planes (which also helps us avoid re-grabbing extra plane states). Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_drv.h | 4 drivers/gpu/drm/i915/intel_pm.c |

[Intel-gfx] [PATCH v2 10/16] drm/i915/gen9: Calculate plane WM's from state

In a future patch we'll want to calculate plane watermarks for in-flight atomic state rather than the already-committed state. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_pm.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff

[Intel-gfx] [PATCH v2 01/16] drm/i915: Reorganize WM structs/unions in CRTC state

Reorganize the nested structures and unions we have for pipe watermark data in intel_crtc_state so that platform-specific data can be added in a more sensible manner (and save a bit of memory at the same time). The change basically changes the organization from: union {

[Intel-gfx] [PATCH v2 04/16] drm/i915/gen9: Allow calculation of data rate for in-flight state (v2)

Our skl_get_total_relative_data_rate() function gets passed a crtc state object to calculate the data rate for, but it currently always looks up the committed plane states that correspond to that CRTC. Let's check whether the CRTC state is an in-flight state (meaning cstate->state is non-NULL)

[Intel-gfx] [PATCH v2 11/16] drm/i915/gen9: Allow watermark calculation on in-flight atomic state (v2)

In an upcoming patch we'll move this calculation to the atomic 'check' phase so that the display update can be rejected early if no valid watermark programming is possible. v2: - Drop intel_pstate_for_cstate_plane() helper and add note about how the code needs to evolve in the future if we

[Intel-gfx] [PATCH v2 08/16] drm/i915/gen9: Compute DDB allocation at atomic check time (v2)

Calculate the DDB blocks needed to satisfy the current atomic transaction at atomic check time. This is a prerequisite to calculating SKL watermarks during the 'check' phase and rejecting any configurations that we can't find valid watermarks for. Due to the nature of DDB allocation, it's

[Intel-gfx] [PATCH v2 03/16] drm/i915/gen9: Cache plane data rates in CRTC state

This will be important when we start calculating CRTC data rates for in-flight CRTC states since it will allow us to calculate the total data rate without needing to grab the plane state for any planes that aren't updated by the transaction. Signed-off-by: Matt Roper

[Intel-gfx] [PATCH v2 00/16] Pre-calculate SKL-style atomic watermarks

See previous cover letter for detailed explanation of series: https://lists.freedesktop.org/archives/intel-gfx/2016-April/091293.html Key changes since the last spin (mostly based on Maarten's feedback): - During DDB/WM calculation, avoid grabbing extra plane_state's for the planes that

[Intel-gfx] [PATCH v2 02/16] drm/i915: Rename s/skl_compute_pipe_wm/skl_build_pipe_wm/

When we added atomic watermarks, we added a new display vfunc 'compute_pipe_wm' that is used to compute any pipe-specific watermark information that we can at atomic check time. This was a somewhat poor naming choice since we already had a 'skl_compute_pipe_wm' function that doesn't quite fit

Re: [Intel-gfx] i915 driver stack trace on laptop docking event

bump On Tue, Apr 19, 2016 at 4:05 AM, Colin Kincaid Williams wrote: > Hello, > > I tried to find the appropriate place to file a bug report. On my dell > latitude e5440 when I undock and redock I am unable to re-activate > both monitors using xrandr. I'm using linux kernel 4.4.5

Re: [Intel-gfx] [PATCH v2 07/10] drm/i915: Undiplicate VLV signal level code

On Tue, Apr 19, 2016 at 01:37:26PM -0700, Jim Bride wrote: > On Wed, Apr 13, 2016 at 08:47:50PM +0300, Ander Conselvan de Oliveira wrote: Same typo in this patch's subject ('Undiplicate') as the previous one. Jim > > The logic for setting signal levels is used for both HDMI and DP with > >

Re: [Intel-gfx] [PATCH v2 06/10] drm/i915: Undiplicate CHV encoders' post pll disable code

On Wed, Apr 13, 2016 at 08:47:49PM +0300, Ander Conselvan de Oliveira wrote: > The exact same code was used by HDMI and DP encoders, so move it to > intel_dpio_phy.c. > > Signed-off-by: Ander Conselvan de Oliveira > There's a typo in the subject, but

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

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

Re: [Intel-gfx] [PATCH v2 01/10] drm/i915: Set crtc_state->lane_count for HDMI

On Wed, Apr 13, 2016 at 08:47:44PM +0300, Ander Conselvan de Oliveira wrote: > Set the lane count for HDMI to 4. This will make it easier to > unduplicate CHV phy code. > > v2: Set lane_count in *_get_config() to please state checker. (0day) > v3: Set lane_count for DDI in DVI mode too. (CI) > >

Re: [Intel-gfx] [PATCH v2 07/10] drm/i915: Undiplicate VLV signal level code

On Wed, Apr 13, 2016 at 08:47:50PM +0300, Ander Conselvan de Oliveira wrote: > The logic for setting signal levels is used for both HDMI and DP with > small variations. But it is similar enough to put behind a function > called from the encoders. > > Signed-off-by: Ander Conselvan de Oliveira >

Re: [Intel-gfx] [PATCH 1/2] drm/i915: refactor i915_gem_object_pin_map()

On Tue, Apr 19, 2016 at 06:40:07PM +0100, Dave Gordon wrote: > From: Alex Dai > > The recently-added i915_gem_object_pin_map() can be further optimised > for "small" objects. To facilitate this, and simplify the error paths > before adding the new code, this patch pulls out the

Re: [Intel-gfx] SkyLake

Confirmed: Xen is completely busted for Skylake. Kernel can't boot due to i915 core dump. On 04/19/2016 07:49 AM, cac...@quantum-sci.com wrote: > No ideas? Am I right? > > > On 04/18/2016 08:21 PM, cac...@quantum-sci.com wrote: >> On 04/18/2016 07:40 PM, Felix Miata wrote: >>>

Re: [Intel-gfx] [PATCH i-g-t] scripts/run_tests.sh: Fix breakage after piglit updates.

Quoting Vivi, Rodrigo (2016-04-19 07:23:02) > Well, I don't see how to do it in a good and safe way for the old > versions that didn't have the version check, so or we do an ugly > version of it or we just ask people to upgrade the piglit when they > start to report this commit is breaking stuff.

Re: [Intel-gfx] [PATCH piglit] igt: Make "warn" status work again as expected.

Quoting Maarten Lankhorst (2016-04-19 06:33:36) > When writing a patch that adds a igt_warn() when lockdep is unavailable > I noticed that the warn error doesn't work any more. Fix this by monitoring > stderr, and only setting 'pass' when stderr is empty. > > Signed-off-by: Maarten Lankhorst

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: i915: Improve behavior in case of broken HDMI EDID

== Series Details == Series: drm: i915: Improve behavior in case of broken HDMI EDID URL : https://patchwork.freedesktop.org/series/5946/ State : failure == Summary == Series 5946v1 drm: i915: Improve behavior in case of broken HDMI EDID

[Intel-gfx] [PATCH 2/2] drm/i915: optimise i915_gem_object_map() for small objects

We're using this function for ringbuffers and other "small" objects, so it's worth avoiding an extra malloc()/free() cycle if the page array is small enough to put on the stack. Here we've chosen an arbitrary cutoff of 32 (4k) pages, which is big enough for a ringbuffer (4 pages) or a context

[Intel-gfx] [PATCH 1/2] drm/i915: refactor i915_gem_object_pin_map()

From: Alex Dai The recently-added i915_gem_object_pin_map() can be further optimised for "small" objects. To facilitate this, and simplify the error paths before adding the new code, this patch pulls out the "mapping" part of the operation (involving local allocations which

[Intel-gfx] [PATCH] drm: i915: Improve behavior in case of broken HDMI EDID

Currently, our implementation of drm_connector_funcs.detect is based on getting a valid EDID. This requirement makes the driver fail to detect connected connectors in case of EDID corruption, which in turn prevents from falling back to modes provided by builtin or user-provided EDIDs. Let's fix

Re: [Intel-gfx] [PATCH] drm/i915: Move ioremap_wc tracking onto VMA

Hi, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on next-20160419] [cannot apply to v4.6-rc4] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Chris-Wilson/drm

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915/gen8+: Do not enable DPF interrupt since the handler does not exist

== Series Details == Series: series starting with [resend-for-CI,1/3] drm/i915/gen8+: Do not enable DPF interrupt since the handler does not exist URL : https://patchwork.freedesktop.org/series/5944/ State : failure == Summary == Series 5944v1 Series without cover letter

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/guc: keep GuC doorbell & process descriptor mapped in kernel

On 19/04/16 17:24, Patchwork wrote: == Series Details == Series: series starting with [1/3] drm/i915/guc: keep GuC doorbell & process descriptor mapped in kernel URL : https://patchwork.freedesktop.org/series/5942/ State : failure == Summary == Series 5942v1 Series without cover letter

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/guc: local optimisations and updating comments

On 19/04/16 16:08, Tvrtko Ursulin wrote: On 19/04/16 12:45, Dave Gordon wrote: Tidying up guc_init_proc_desc() and adding commentary to the client structure after the recent change in GuC page mapping strategy. Signed-off-by: Dave Gordon ---

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [RESEND,FOR,CI,1/2] drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse()

Finland CI approved the patch in a resend to trybot, and the Romania failures are know issues, so I pushed those two patches to dinq. https://patchwork.freedesktop.org/series/5864/ Ander On Wed, 2016-04-13 at 16:53 +, Patchwork wrote: > == Series Details == > > Series: series starting with

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/guc: keep GuC doorbell & process descriptor mapped in kernel

== Series Details == Series: series starting with [1/3] drm/i915/guc: keep GuC doorbell & process descriptor mapped in kernel URL : https://patchwork.freedesktop.org/series/5942/ State : failure == Summary == Series 5942v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915: Set legacy properties when using legacy gamma set IOCTL. (v2)

On Tue, 19 Apr 2016 08:05:26 +0200 Maarten Lankhorst wrote: > Op 18-04-16 om 18:47 schreef Bob Paauwe: > > The i915 driver is now using atomic properties and atomic commit > > to handle the legacy set gamma IOCTL. However, if the driver is > > configured

Re: [Intel-gfx] [PATCH] drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport

On 19/04/16 15:45, tim.g...@intel.com wrote: From: Tim Gore WaEnableSamplerGPGPUPreemptionSupport fixes a problem related to mid thread pre-emption. Signed-off-by: Tim Gore Reviewed-by: Dave Gordon ---

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport (rev4)

== Series Details == Series: drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport (rev4) URL : https://patchwork.freedesktop.org/series/5367/ State : success == Summary == Series 5367v4 drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport

[Intel-gfx] [PATCH resend-for-CI 3/3] drm/i915: Fixing eDP detection on certain platforms

From: Shubhangi Shrivastava Since commit 30d9aa4265fe ("drm/i915: Read sink_count dpcd always"), the status of a DP connector depends on its sink count value. However, some eDP panels don't set that value appropriately, causing them to be reported as

[Intel-gfx] [PATCH resend-for-CI 2/3] drm/i915: Remove a couple pointless WARN_ONs

From: Tvrtko Ursulin Just two WARN_ONs followed by pointer dereference I spotted by accident. v2: Remove some more of the same. Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson ---

[Intel-gfx] [PATCH resend-for-CI 1/3] drm/i915/gen8+: Do not enable DPF interrupt since the handler does not exist

From: Tvrtko Ursulin Looks like DPF was not implemented for gen8+ but the IER and IMR are still enabled on initialization. Since there is no code to handle this interrupt, gate the irq enablement behind HAS_L3_DPF in case the feature gets enabled in the future.

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: drop cached copy of 'wq_head'

On 19/04/16 16:08, Dave Gordon wrote: From: Alex Dai Now that we keep the GuC client process descriptor permanently mapped, we don't really need to keep a local copy of the GuC's work-queue-head. So we can simplify the code a little by not doing this. Signed-off-by: Alex

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: keep GuC doorbell & process descriptor mapped in kernel

On 19/04/16 16:08, Dave Gordon wrote: Don't use kmap_atomic() for doorbell & process descriptor access. This patch fixes the BUG shown below, where the thread could sleep while holding a kmap_atomic mapping. In order not to need to call kmap_atomic() in this code path, we now set up a permanent

Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/guc: local optimisations and updating comments

On 19/04/16 12:45, Dave Gordon wrote: Tidying up guc_init_proc_desc() and adding commentary to the client structure after the recent change in GuC page mapping strategy. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_guc_submission.c | 38

[Intel-gfx] [PATCH 3/3] drm/i915/guc: local optimisations and updating comments

Tidying up guc_init_proc_desc() and adding commentary to the client structure after the recent change in GuC page mapping strategy. Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_guc_submission.c | 38 ++

[Intel-gfx] [PATCH 2/3] drm/i915/guc: drop cached copy of 'wq_head'

From: Alex Dai Now that we keep the GuC client process descriptor permanently mapped, we don't really need to keep a local copy of the GuC's work-queue-head. So we can simplify the code a little by not doing this. Signed-off-by: Alex Dai Signed-off-by: Dave

[Intel-gfx] [PATCH 1/3] drm/i915/guc: keep GuC doorbell & process descriptor mapped in kernel

Don't use kmap_atomic() for doorbell & process descriptor access. This patch fixes the BUG shown below, where the thread could sleep while holding a kmap_atomic mapping. In order not to need to call kmap_atomic() in this code path, we now set up a permanent kernel mapping of the shared doorbell

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2] drm/i915: Mark the current context as lost on suspend (rev2)

== Series Details == Series: series starting with [v2] drm/i915: Mark the current context as lost on suspend (rev2) URL : https://patchwork.freedesktop.org/series/5926/ State : failure == Summary == Series 5926v2 Series without cover letter

[Intel-gfx] [PATCH] drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport

From: Tim Gore WaEnableSamplerGPGPUPreemptionSupport fixes a problem related to mid thread pre-emption. Signed-off-by: Tim Gore --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_ringbuffer.c | 7 --- 2 files changed, 5

Re: [Intel-gfx] SkyLake

No ideas? Am I right? On 04/18/2016 08:21 PM, cac...@quantum-sci.com wrote: > On 04/18/2016 07:40 PM, Felix Miata wrote: >> cac...@quantum-sci.com composed on 2016-04-18 19:09 (UTC-0700): >>> >>> I take it there's no SkyLake support on the Xen side, since that starts >>> with kernel 4.4? >> >>

Re: [Intel-gfx] [PATCH 4/5] drm/i915: call kunmap_px on pt_vaddr

Joonas Lahtinen writes: > [ text/plain ] > On ti, 2016-04-12 at 16:57 +0100, Matthew Auld wrote: >> We need to kunmap pt_vaddr and not pt itself, otherwise we end up >> mapping a bunch of pages without ever unmapping them. >> > > It's always a good idea to use

Re: [Intel-gfx] [PATCH i-g-t] scripts/run_tests.sh: Fix breakage after piglit updates.

Well, I don't see how to do it in a good and safe way for the old versions that didn't have the version check, so or we do an ugly version of it or we just ask people to upgrade the piglit when they start to report this commit is breaking stuff. Really up to you. But I believe we need on

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen8+: Do not enable DPF interrupt since the handler does not exist

== Series Details == Series: drm/i915/gen8+: Do not enable DPF interrupt since the handler does not exist URL : https://patchwork.freedesktop.org/series/5936/ State : failure == Summary == Series 5936v1 drm/i915/gen8+: Do not enable DPF interrupt since the handler does not exist

Re: [Intel-gfx] [PATCH v2] drm/i915: Mark the current context as lost on suspend

Chris Wilson writes: > [ text/plain ] > In order to force a reload of the context image upon resume, we first > need to mark its absence on suspend. Currently we are failing to restore > the golden context state and any context w/a to the default context > after resume.

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Clean up PCI config register handling (rev3)

On ti, 2016-04-19 at 14:06 +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Clean up PCI config register handling (rev3) > URL   : https://patchwork.freedesktop.org/series/5768/ > State : failure > > == Summary == > > Series 5768v3 drm/i915: Clean up PCI config register

Re: [Intel-gfx] [PATCH i-g-t] scripts/run_tests.sh: Fix breakage after piglit updates.

There was some discussions about this before: https://lists.freedesktop.org/archives/intel-gfx/2016-March/089128.html and https://lists.freedesktop.org/archives/intel-gfx/2016-March/090302.html There's some concern that his approach might brake with older versions of piglit. Is this still the

[Intel-gfx] [PATCH v2] drm/i915: Mark the current context as lost on suspend

In order to force a reload of the context image upon resume, we first need to mark its absence on suspend. Currently we are failing to restore the golden context state and any context w/a to the default context after resume. One oversight corrected, is that we had forgotten to reapply the L3

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Clean up PCI config register handling (rev3)

== Series Details == Series: drm/i915: Clean up PCI config register handling (rev3) URL : https://patchwork.freedesktop.org/series/5768/ State : failure == Summary == Series 5768v3 drm/i915: Clean up PCI config register handling

Re: [Intel-gfx] [PATCH i-g-t] scripts/run_tests.sh: Fix breakage after piglit updates.

On Tue, Apr 19, 2016 at 03:40:46PM +0200, Maarten Lankhorst wrote: > Op 19-04-16 om 15:38 schreef Ville Syrjälä: > > On Tue, Apr 19, 2016 at 03:31:12PM +0200, Maarten Lankhorst wrote: > >> Right now scripts/run-tests.sh fails with the following error message: > >> > >> Fatal Error: Cannot

Re: [Intel-gfx] [PATCH i-g-t] scripts/run_tests.sh: Fix breakage after piglit updates.

Op 19-04-16 om 15:38 schreef Ville Syrjälä: > On Tue, Apr 19, 2016 at 03:31:12PM +0200, Maarten Lankhorst wrote: >> Right now scripts/run-tests.sh fails with the following error message: >> >> Fatal Error: Cannot overwrite existing folder without the -o/--overwrite >> option being set. >> >> Fix

Re: [Intel-gfx] [PATCH i-g-t] scripts/run_tests.sh: Fix breakage after piglit updates.

On Tue, Apr 19, 2016 at 03:31:12PM +0200, Maarten Lankhorst wrote: > Right now scripts/run-tests.sh fails with the following error message: > > Fatal Error: Cannot overwrite existing folder without the -o/--overwrite > option being set. > > Fix this by adding -o as required. > > Signed-off-by:

Re: [Intel-gfx] [PATCH 07/19] drm/i915: Allow mmio updates on all platforms, v2.

Op 19-04-16 om 14:48 schreef Ville Syrjälä: > On Tue, Apr 19, 2016 at 09:52:27AM +0200, Maarten Lankhorst wrote: >> With intel_pipe_update begin/end we ensure that the mmio updates >> don't run during vblank interrupt, using the hw counter we can >> be sure that when current vblank count != vblank

Re: [Intel-gfx] [PATCH] drm/i915/gen8+: Do not enable DPF interrupt since the handler does not exist

On Tue, Apr 19, 2016 at 02:26:51PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Looks like DPF was not implemented for gen8+ but the IER and IMR > are still enabled on initialization. > > Since there is no code to handle this interrupt, gate the irq >

[Intel-gfx] [PATCH piglit] igt: Make "warn" status work again as expected.

When writing a patch that adds a igt_warn() when lockdep is unavailable I noticed that the warn error doesn't work any more. Fix this by monitoring stderr, and only setting 'pass' when stderr is empty. Signed-off-by: Maarten Lankhorst Cc: Dylan Baker

[Intel-gfx] [PATCH] drm/i915/gen8+: Do not enable DPF interrupt since the handler does not exist

From: Tvrtko Ursulin Looks like DPF was not implemented for gen8+ but the IER and IMR are still enabled on initialization. Since there is no code to handle this interrupt, gate the irq enablement behind HAS_L3_DPF in case the feature gets enabled in the future.

[Intel-gfx] [PATCH i-g-t] scripts/run_tests.sh: Fix breakage after piglit updates.

Right now scripts/run-tests.sh fails with the following error message: Fatal Error: Cannot overwrite existing folder without the -o/--overwrite option being set. Fix this by adding -o as required. Signed-off-by: Maarten Lankhorst --- diff --git

Re: [Intel-gfx] [PATCH v2 2/4] io-mapping: Specify mapping size for io_mapping_map_wc()

On Tue, Apr 19, 2016 at 01:02:25PM +0100, Chris Wilson wrote: > On Mon, Apr 18, 2016 at 12:14:00PM +0100, Chris Wilson wrote: > > The ioremap() hidden behind the io_mapping_map_wc() convenience helper > > can be used for remapping multiple pages. Extend the helper so that > > future callers can

[Intel-gfx] i915 driver stack trace on laptop docking event

Hello, I tried to find the appropriate place to file a bug report. On my dell latitude e5440 when I undock and redock I am unable to re-activate both monitors using xrandr. I'm using linux kernel 4.4.5 and the i915 driver, and also could not find the appropriate section to file a bug report. Can

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/3] drm/i915/guc: keep GuC doorbell & process descriptor mapped in kernel

== Series Details == Series: series starting with [v3,1/3] drm/i915/guc: keep GuC doorbell & process descriptor mapped in kernel URL : https://patchwork.freedesktop.org/series/5927/ State : failure == Summary == Series 5927v1 Series without cover letter

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,01/12] drm/i915: Mark the current context as lost on suspend

== Series Details == Series: series starting with [v2,01/12] drm/i915: Mark the current context as lost on suspend URL : https://patchwork.freedesktop.org/series/5926/ State : failure == Summary == Series 5926v1 Series without cover letter

[Intel-gfx] [RFC PATCH i-g-t] lib: Add warning if lockdep is disabled before a test.

When running tests, it will produce warnings like this: (core_auth:2552) igt-core-WARNING: Lockdep is turned off. This makes sure lockdep warnings during load aren't accidentally ignored. Signed-off-by: Maarten Lankhorst --- Unfortunately this version suffers

[Intel-gfx] [PATCH v3] drm/i915: Clean up PCI config register handling

Do not use magic numbers, do not prefix stuff with "PCI_", do not declare registers in implementation files. Also move the PCI registers under correct comment in i915_reg.h. v2: - Consistently use BSM (not BDSM or other variants from PRM) (Chris) - Also include register address to help identify

[Intel-gfx] [PATCH] drm-intel.rst: Clarify the eternal draft status

Based upon a great comment from Jani. --- drm-intel.rst | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drm-intel.rst b/drm-intel.rst index 85563ddeaedf..e9af1e516839 100644 --- a/drm-intel.rst +++ b/drm-intel.rst @@ -15,7 +15,12 @@ Introduction This document describes

[Intel-gfx] [PATCH 1/2] drm/i915: Move releasing of the GEM request from free to retire/cancel

If we move the release of the GEM request (i.e. decoupling it from the various lists used for client and context tracking) after it is complete (either by the GPU retiring the request, or by the caller cancelling the request), we can remove the requirement that the final unreference of the GEM

[Intel-gfx] [PATCH 2/2] drm/i915: Track the previous pinned context inside the request

As the contexts are accessed by the hardware until the switch is completed to a new context, the hardware may still be writing to the context object after the breadcrumb is visible. We must not unpin/unbind/prune that object whilst still active and so we keep the previous context pinned until the

[Intel-gfx] Update to patches 11 and 12

Flipped the last pair to make sure GuC isn't broken in between. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/19] drm/i915: Allow mmio updates on all platforms, v2.

On Tue, Apr 19, 2016 at 09:52:27AM +0200, Maarten Lankhorst wrote: > With intel_pipe_update begin/end we ensure that the mmio updates > don't run during vblank interrupt, using the hw counter we can > be sure that when current vblank count != vblank count at the time > of pipe_update_end the mmio

Re: [Intel-gfx] [PATCH v2 10/12] drm/i915: Move the magical deferred context allocation into the request

Hi, [auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on next-20160419] [cannot apply to v4.6-rc4] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Chris-Wilson/drm

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/kbl: Don't WARN for expected secondary MISC IO power well request

On ti, 2016-04-19 at 10:56 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/kbl: Don't WARN for expected secondary MISC IO power > well request > URL   : https://patchwork.freedesktop.org/series/5917/ > State : failure > > == Summary == > > Series 5917v1 drm/i915/kbl: Don't

Re: [Intel-gfx] [CI-ping 15/15] drm/i915: Late request cancellations are harmful

On 13/04/16 15:21, John Harrison wrote: On 13/04/2016 10:57, Daniel Vetter wrote: On Tue, Apr 12, 2016 at 09:03:09PM +0100, Chris Wilson wrote: Conceptually, each request is a record of a hardware transaction - we build up a list of pending commands and then either commit them to hardware, or

Re: [Intel-gfx] [PATCH v2 2/4] io-mapping: Specify mapping size for io_mapping_map_wc()

On Tue, Apr 19, 2016 at 02:30:28PM +0200, Luis R. Rodriguez wrote: > On Tue, Apr 19, 2016 at 01:02:25PM +0100, Chris Wilson wrote: > > On Mon, Apr 18, 2016 at 12:14:00PM +0100, Chris Wilson wrote: > > > The ioremap() hidden behind the io_mapping_map_wc() convenience helper > > > can be used for

Re: [Intel-gfx] [PATCH 19/19] drm/i915: Allow async update of pageflips.

Op 19-04-16 om 10:19 schreef Chris Wilson: > On Tue, Apr 19, 2016 at 09:52:39AM +0200, Maarten Lankhorst wrote: > > If you think it's ready: > dev->mode_config.async_page_flip = true; > -Chris > Oh indeed! It seems the flag has 2 meanings though, not compatible with each other. First one

Re: [Intel-gfx] [PATCH v2 08/12] drm/i915: Refactor execlists default context pinning

On 19/04/16 12:40, Chris Wilson wrote: Refactor pinning and unpinning of contexts, such that the default context for an engine is pinned during initialisation and unpinned during teardown (pinning of the context handles the reference counting). Thus we can eliminate the special case handling of

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915/guc: keep GuC objects mapped in kernel

On 18/04/16 12:37, Chris Wilson wrote: On Mon, Apr 18, 2016 at 12:28:43PM +0100, Dave Gordon wrote: On 18/04/16 11:25, Chris Wilson wrote: On Mon, Apr 18, 2016 at 11:15:07AM +0100, Dave Gordon wrote: With the new i915_gem_obj_pin_map() interface, it makes sense to keep GuC objects (which are

Re: [Intel-gfx] [PATCH] drm/i915: Move ioremap_wc tracking onto VMA

On 19/04/16 12:06, Chris Wilson wrote: By tracking the iomapping on the VMA itself, we can share that area between multiple users. Also by only revoking the iomapping upon unbinding from the mappable portion of the GGTT, we can keep that iomap across multiple invocations (e.g. execlists context

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Move releasing of the GEM request from free to retire/cancel

On 19/04/16 07:49, Chris Wilson wrote: > If we move the release of the GEM request (i.e. decoupling it from the > various lists used for client and context tracking) after it is complete > (either by the GPU retiring the request, or by the caller cancelling the > request), we can remove the

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Track the previous pinned context inside the request

On Tue, Apr 19, 2016 at 01:02:26PM +0100, Tvrtko Ursulin wrote: > On 19/04/16 07:49, Chris Wilson wrote: > >diff --git a/drivers/gpu/drm/i915/intel_lrc.c > >b/drivers/gpu/drm/i915/intel_lrc.c > >index b0d20af38574..0e55f206e592 100644 > >--- a/drivers/gpu/drm/i915/intel_lrc.c > >+++

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Define VLV/CHV display power well domains properly

On Tue, Apr 19, 2016 at 08:54:05AM +0300, Imre Deak wrote: > On Mon, 2016-04-18 at 14:02 +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Currently we're using POWER_DOMAIN_MASK as the power domains for the > > display power well on

Re: [Intel-gfx] [PATCH v2 2/4] io-mapping: Specify mapping size for io_mapping_map_wc()

On Mon, Apr 18, 2016 at 12:14:00PM +0100, Chris Wilson wrote: > The ioremap() hidden behind the io_mapping_map_wc() convenience helper > can be used for remapping multiple pages. Extend the helper so that > future callers can use it for larger ranges. Adding Luis Rodriguez as he has been active

Re: [Intel-gfx] [PATCH 8/9] drm/i915: Track the previous pinned context inside the request

On 19/04/16 07:49, Chris Wilson wrote: As the contexts are accessed by the hardware until the switch is completed to a new context, the hardware may still be writing to the context object after the breadcrumb is visible. We must not unpin/unbind/prune that object whilst still active and so we

Re: [Intel-gfx] [PATCH] drm/i915: Fix oops in vlv_force_pll_on()

On Tue, Apr 19, 2016 at 02:25:40PM +0300, Jani Nikula wrote: > On Mon, 18 Apr 2016, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > intel_pipe_will_have_type() doesn't just look at the passied in > > pipe_config, instead it expects there to be a

Re: [Intel-gfx] [PATCH] drm/i915: Wait for power cycle delay after turning off DSI panel power

On Tue, Apr 19, 2016 at 08:00:10AM +0530, Kumar, Shobhit wrote: > On Monday 18 April 2016 09:47 PM, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > The power cycle delay starts _after_ turning off the panel power. Do the > > msleep after

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/4] drm/i915/overlay: Replace i915_gem_obj_ggtt_offset() with the known flip_addr (rev3)

== Series Details == Series: series starting with [v2,1/4] drm/i915/overlay: Replace i915_gem_obj_ggtt_offset() with the known flip_addr (rev3) URL : https://patchwork.freedesktop.org/series/5865/ State : failure == Summary == Series 5865v3 Series without cover letter

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Wait for power cycle delay after turning off DSI panel power

On Mon, Apr 18, 2016 at 05:24:47PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Wait for power cycle delay after turning off DSI panel power > URL : https://patchwork.freedesktop.org/series/5885/ > State : warning > > == Summary == > > Series 5885v1 drm/i915: Wait for

[Intel-gfx] [PATCH v3 1/3] drm/i915/guc: keep GuC doorbell & process descriptor mapped in kernel

Don't use kmap_atomic() for doorbell & process descriptor access. This patch fixes the BUG shown below, where the thread could sleep while holding a kmap_atomic mapping. In order not to need to call kmap_atomic() in this code path, we now set up a permanent kernel mapping of the shared doorbell

  1   2   >