Re: [Intel-gfx] Enable GSE interrupt on Broadwell and later?

On Tue, Dec 01, 2015 at 09:53:50PM +0100, Mark Kettenis wrote: > I just committed the following cange to the OpenBSD inteldrm(4) > driver, which currently is mostly a port of the Linux 3.14 codebase. > This enables the GSE interrupt on Broadwell. Without this interrupt, > the ASLE backlight

[Intel-gfx] [PATCH] drm/i915: Enable GSE interrupt on BDW+

From: Ville Syrjälä We've never actually enabled or unmasked the GSE interrupt on BDW+, even though the interrupt handler was always prepared for it. Let's enable it and see what happens. Credit to Mark Kettenis who fixed this in the OpenBSD fork of the driver. He

[Intel-gfx] [PATCH v3 03/10] drm/i915: Check VBT for CRT port presence on HSW/BDW

From: Ville Syrjälä Unfortunatey there appear to quite a few HSW/BDW machines (eg. NUCs, Brix Pro) in the wild with LPT/WPT-H that have no physical CRT connector and non-working FDI. FDI training fails every single time on these machines. Dunno, maybe they just

[Intel-gfx] [PATCH v2 04/10] drm/i915: Add "missing" break to haswell_get_ddi_pll()

From: Ville Syrjälä While not technically needed on the last case in the switch statement, the 'break' makes it look better IMO. v2: Fixed a typo in the commit message (Paulo) Signed-off-by: Ville Syrjälä Reviewed-by: Paulo Zanoni

[Intel-gfx] Enable GSE interrupt on Broadwell and later?

I just committed the following cange to the OpenBSD inteldrm(4) driver, which currently is mostly a port of the Linux 3.14 codebase. This enables the GSE interrupt on Broadwell. Without this interrupt, the ASLE backlight brightness mechanism doesn't work. I've verified that this fixed the ACPI

[Intel-gfx] [PATCH v2 01/10] drm/i915: Don't register the CRT connector when it's fused off on LPT-H

From: Ville Syrjälä LPT-H has a strap bit for fused off CRT block. Check it to see if we should register the CRT connector or not. Supposedly this also forces the ADAP enable bit to 0, so the detection we added in commit 6c03a6bd0dd8 ("drm/i915: Don't register CRT

[Intel-gfx] [PATCH v2 02/10] drm/i915: Don't register CRT connector when DDI E can't be used

From: Ville Syrjälä On HSW/BDW DDI A and E share 2 lanes, so when DDI A requires the shared lanes DDI E can't be used. The lanes are not supposed to be dynamically switched between the two uses, so there's no point in registering the CRT connector when DDI E has no

Re: [Intel-gfx] [PATCH v8 2/2] drm/dp: Set aux.dev to the drm_connector device, instead of drm_device.

On Tue, Nov 24, 2015 at 10:31:41PM +0200, Ville Syrjälä wrote: > On Mon, Nov 02, 2015 at 12:33:48PM -0800, Rafael Antognolli wrote: > > So far, the i915 driver and some other drivers set it to the drm_device, > > which doesn't allow one to know which DP a given aux channel is related > > to.

[Intel-gfx] [PATCH] drm/i915: Restore waitboost credit to the synchronous waiter

Ideally, we want to automagically have the GPU respond to the instantaneous load by reclocking itself. However, reclocking occurs relatively slowly, and to the client waiting for a result from the GPU, too late. To compensate and reduce the client latency, we allow the first wait from a client to

Re: [Intel-gfx] [PATCH i-g-t 2/8] kms_frontbuffer_tracking: Skip on unreliable CRC.

On Thu, Nov 5, 2015 at 12:30 PM, Paulo Zanoni wrote: > 2015-11-05 16:53 GMT-02:00 Rodrigo Vivi : >> Even with all sink crc re-works we still have platforms >> where after 6 vblanks it is unable to calculate the >> sink crc. But if we don't get the sink

[Intel-gfx] [PATCH] drm/i915: Separate cherryview from valleyview

The cherryview device shares many characteristics with the valleyview device. When support was added to the driver for cherryview, the corresponding device info structure included .is_valleyview = 1. This is not correct and leads to some confusion. This patch changes .is_valleyview to

Re: [Intel-gfx] [PATCH v5] PCI / PM: Tune down retryable runtime suspend error messages

On Monday, November 30, 2015 09:02:55 PM Imre Deak wrote: > The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver > suspend hooks as errors, but they still show up as errors in dmesg. Tune > them down. See rpm_suspend() for details of handling these return values. > > Note

Re: [Intel-gfx] [PATCH i-g-t 1/8] kms_frontbuffer_tracking: Increase the time we wait for PSR.

On Thu, Nov 5, 2015 at 12:11 PM, Paulo Zanoni wrote: > 2015-11-05 16:53 GMT-02:00 Rodrigo Vivi : >> With commit (drm/i915: Delay first PSR activation.) in kernel >> PSR might take a bit longer to really activate after the modeset. > > Can you please

Re: [Intel-gfx] [PATCH 1/3] drm/i915/bxt: add support for setting backlight freq from vbt

On ti, 2015-12-01 at 10:23 +0200, Jani Nikula wrote: > The only missing piece is the function to convert frequency to PWM > register value. The PWM is based on 19.2 MHz clock, except for BXT A > step, which is based on CDCLK, and which we ignore. > > Signed-off-by: Jani Nikula

[Intel-gfx] [PATCH] drm/i915/bxt: Disable power well support

BXT power well support is not yet stable. Starting with patch commit 9f836f9016ad5320e0c9230419d2102cf15a28aa Author: Patrik Jakobsson Date: Mon Nov 16 16:20:01 2015 +0100 drm/i915/gen9: Turn DC handling into a power well

Re: [Intel-gfx] [PATCH i-g-t] tests/pm_rpm: Don't compare edid blob IDs

2015-12-01 14:47 GMT-02:00 Daniel Vetter : > On Tue, Dec 01, 2015 at 02:40:22PM -0200, Paulo Zanoni wrote: >> 2015-12-01 14:37 GMT-02:00 Daniel Vetter : >> > The kernel is free to allocate blob ids however it wants to. And also >> > to reallocate them

Re: [Intel-gfx] [PATCH 13/15] drm/i915: Stop setting wraparound seqno on initialisation

On 29/11/15 08:48, Chris Wilson wrote: We have testcases to ensure that seqno wraparound works fine, so we can forgo forcing everyone to encounter seqno wraparound during early uptime. seqno wraparound incurs a full GPU stall so not forcing it will eliminate one jitter from the early system.

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915: Reduce pointer indirection during cmd parser lookup

On Fri, Nov 20, 2015 at 05:27:43PM +0200, Ville Syrjälä wrote: > On Fri, Nov 20, 2015 at 10:56:00AM +, Chris Wilson wrote: > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/i915_cmd_parser.c | 51 > > -- > >

Re: [Intel-gfx] [PATCH i-g-t] tests/pm_rpm: Don't compare edid blob IDs

On Tue, Dec 01, 2015 at 02:40:22PM -0200, Paulo Zanoni wrote: > 2015-12-01 14:37 GMT-02:00 Daniel Vetter : > > The kernel is free to allocate blob ids however it wants to. And also > > to reallocate them whenever it sees fit. The only thing we are allowed > > to compare is

Re: [Intel-gfx] [PATCH v2 3/6] drm/i915: Use WC copies on !llc platforms for the command parser

On Fri, Nov 20, 2015 at 03:22:03PM +, Chris Wilson wrote: > On Fri, Nov 20, 2015 at 05:05:05PM +0200, Ville Syrjälä wrote: > > On Fri, Nov 20, 2015 at 10:55:58AM +, Chris Wilson wrote: > > > Since we blow the TLB caches by using kmap/kunmap, we may as well go the > > > whole hog and see if

Re: [Intel-gfx] [PATCH] drm/i915: Fix idle_frames counter.

2015-12-01 14:54 GMT-02:00 Rodrigo Vivi : > 'commit 97173eaf5 ("drm/i915: PSR: Increase idle_frames")' was a mistake. > The special case it tried to cover was already being covered by > the DP_PSR_NO_TRAIN_ON_EXIT. So this ended up duplicated. > > So, instead of reverting

Re: [Intel-gfx] [PATCH 03/15] drm/i915: Only spin whilst waiting on the current request

On 01/12/15 15:58, Chris Wilson wrote: On Tue, Dec 01, 2015 at 03:47:34PM +, Dave Gordon wrote: On 30/11/15 10:06, Tvrtko Ursulin wrote: On 29/11/15 08:48, Chris Wilson wrote: Limit busywaiting only to the request currently being processed by the GPU. If the request is not currently

Re: [Intel-gfx] [PATCH i-g-t] tests: add core_setmaster_vs_auth

On Tue, Dec 01, 2015 at 03:27:44PM +0100, Thomas Hellstrom wrote: > Daniel, > > LGTM, except one comment below: Thanks, I've updated the comment and pushed it out. -Daniel > > On 12/01/2015 08:45 AM, Daniel Vetter wrote: > > Tests that master state isn't leaked to new masters by checking > >

Re: [Intel-gfx] [PATCH 08/15] drm/i915: Slaughter the thundering i915_wait_request herd

On 30/11/15 14:18, Chris Wilson wrote: On Mon, Nov 30, 2015 at 01:32:16PM +, Tvrtko Ursulin wrote: On 30/11/15 12:30, Chris Wilson wrote: On Mon, Nov 30, 2015 at 12:05:50PM +, Tvrtko Ursulin wrote: + struct intel_breadcrumbs { + spinlock_t lock; /* protects the

Re: [Intel-gfx] [PATCH 2/2] igt/pm_rps: Add checks for freq = idle (RPn) in specific cases.

On Tue, 1 Dec 2015 15:56:55 +0200 Imre Deak wrote: > On ma, 2015-11-30 at 16:23 -0800, Bob Paauwe wrote: > > Now that the frequency can drop below the user specified minimum when > > the gpu is idle, add some checking to verify that it really does drop > > down to the RPn

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915: Cache last cmd descriptor when parsing

On Fri, Nov 20, 2015 at 10:55:57AM +, Chris Wilson wrote: > The cmd parser has the biggest impact on the BLT ring, because it is > relatively verbose composed to the other engines as the vertex data is > inline. It also typically has runs of repeating commands (again since > the vertex data is

Re: [Intel-gfx] [PATCH 2/2] igt/pm_rps: Add checks for freq = idle (RPn) in specific cases.

On ti, 2015-12-01 at 09:22 -0800, Bob Paauwe wrote: > On Tue, 1 Dec 2015 15:56:55 +0200 > Imre Deak wrote: > > > On ma, 2015-11-30 at 16:23 -0800, Bob Paauwe wrote: > > > Now that the frequency can drop below the user specified minimum > > > when > > > the gpu is idle, add

[Intel-gfx] [PATCH i-g-t 1/3] lib: add missing documentation for drm open functions

Signed-off-by: Thomas Wood --- lib/drmtest.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lib/drmtest.c b/lib/drmtest.c index 16a3638..2896af0 100644 --- a/lib/drmtest.c +++ b/lib/drmtest.c @@ -225,11 +225,10 @@ int drm_get_card(void) /**

[Intel-gfx] [PATCH i-g-t 2/3] lib: document intel_pipe_crc_source enum values

Signed-off-by: Thomas Wood --- lib/igt_debugfs.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/lib/igt_debugfs.h b/lib/igt_debugfs.h index ee9ff40..3d5a811 100644 --- a/lib/igt_debugfs.h +++ b/lib/igt_debugfs.h @@ -77,6 +77,17 @@ typedef struct { /**

Re: [Intel-gfx] [PATCH] drm/i915: Remove redundant get_pages call

On 28/10/15 12:08, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma A call to i915_gem_obj_ggtt_pin is being made after this, which again calls the get_pages function. Hence removing the redundant call to get_pages. Signed-off-by: Ankitprasad

Re: [Intel-gfx] [PATCH v2 03/10] drm/i915: Check VBT for CRT port presence on HSW/BDW

On Tue, Dec 01, 2015 at 06:07:09PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Unfortunatey there appear to quite a few HSW/BDW machines (eg. > NUCs, Brix Pro) in the wild with LPT/WPT-H but non-working FDI. > FDI training fails every

[Intel-gfx] [PATCH i-g-t 3/3] docs: exclude gpgpu_fill.h

gpgpu_fill.h is only used internally by the library. Signed-off-by: Thomas Wood --- docs/reference/intel-gpu-tools/Makefile.am | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/reference/intel-gpu-tools/Makefile.am

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Disable power well support

On ti, 2015-12-01 at 09:26 -0800, Matt Roper wrote: > BXT power well support is not yet stable.  Starting with patch > > commit 9f836f9016ad5320e0c9230419d2102cf15a28aa > Author: Patrik Jakobsson > Date:   Mon Nov 16 16:20:01 2015 +0100 >

[Intel-gfx] [PATCH] drm/i915: Fix mode_get() for Broxton

Making changes in intel_crtc_mode_get() to get correct values for crtc clock, vdisplay, hdisplay, vtotal. 1. intel_crtc_mode_get() gets clock using i9xx_crtc_clock_get() which wil not work for hsw, skl, bxt. 2. For BXT DSI, hdisplay, vdisplay, vtotal registers are different. In the current

Re: [Intel-gfx] [PATCH V3 2/2] drm/i915: start adding dp mst audio

On 11/27/2015 08:29 PM, Ander Conselvan De Oliveira wrote: On Wed, 2015-11-25 at 13:19 +0800, libin.y...@linux.intel.com wrote: From: Libin Yang This patch adds support for DP MST audio in i915. The title says "start adding" so a note of what's still missing

[Intel-gfx] [PATCH V4 2/2] drm/i915: start adding dp mst audio

From: Libin Yang This patch adds support for DP MST audio in i915. Enable audio codec when DP MST is enabled if has_audio flag is set. Disable audio codec when DP MST is disabled if has_audio flag is set. Another separated patches to support DP MST audio will be

[Intel-gfx] [PATCH V4 1/2] dp/mst: add SDP stream support

From: Libin Yang This adds code to initialise the SDP streams for a sink in the simplest ordering. I've no idea how you'd want to control the ordering at this level, so don't bother until someone comes up with a use case. Reviewed-by: Ander Conselvan de Oliveira

[Intel-gfx] [PATCH v4] drm/i915 : Avoid superfluous invalidation of CPU cache lines

From: Akash Goel When the object is moved out of CPU read domain, the cachelines are not invalidated immediately. The invalidation is deferred till next time the object is brought back into CPU read domain. But the invalidation is done unconditionally, i.e. even for the

Re: [Intel-gfx] [PATCH v5] PCI / PM: Tune down retryable runtime suspend error messages

On Wed, Dec 02, 2015 at 02:54:45AM +0100, Rafael J. Wysocki wrote: > On Monday, November 30, 2015 09:02:55 PM Imre Deak wrote: > > The runtime PM core doesn't treat EBUSY and EAGAIN retvals from the driver > > suspend hooks as errors, but they still show up as errors in dmesg. Tune > > them down.

[Intel-gfx] [PATCH] drm/i915: Enabling RC6 immediately during init/resume

Since RC6 enabling does not involve PCU communication overhead, it can be enabled immediately during the resume time. This will help save additional power & meet power requirements for active Idle KPI where power is evaluated over number of transitions of suspend/resume. v2: RPM ref count is not

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Don't register the CRT connector when it's fused off

2015-12-01 11:08 GMT-02:00 : > From: Ville Syrjälä > > LPT-H has a strap bit for fused off CRT block. Check it to see if > we should register the CRT connector or not. Supposedly this also > forces the ADAP enable bit to 0, so the

Re: [Intel-gfx] [PATCH] drm/i915: Force PSR exit when IRQ_HPD is detected on eDP.

On Wed, Nov 18, 2015 at 11:19:06AM -0800, Rodrigo Vivi wrote: > According to VESA spec: "If a Source device receives and IRQ_HPD > while in a PSR active state, and cannot identify what caused the > IRQ_HPD to be generated, based on Sink device status registers, > the Source device can take

Re: [Intel-gfx] [PATCH 02/10] drm/i915: Don't register CRT connectro when DDI E can't be used

2015-12-01 11:08 GMT-02:00 : > From: Ville Syrjälä Subject: s/connectro/connector/ > > On HSW/BDW DDI A and E share 2 lanes, so when DDI A requires the > shared lanes DDI E can't be used. The lanes are not suppsoed to

Re: [Intel-gfx] [PATCH v4] drm/i915: Slaughter the thundering i915_wait_request herd

On 30/11/15 14:34, Chris Wilson wrote: One particularly stressful scenario consists of many independent tasks all competing for GPU time and waiting upon the results (e.g. realtime transcoding of many, many streams). One bottleneck in particular is that each client waits on its own results, but

Re: [Intel-gfx] [PATCH 01/10] drm/i915: Don't register the CRT connector when it's fused off

On Tue, Dec 01, 2015 at 05:05:42PM -0200, Paulo Zanoni wrote: > 2015-12-01 11:08 GMT-02:00 : > > From: Ville Syrjälä > > > > LPT-H has a strap bit for fused off CRT block. Check it to see if > > we should register the CRT connector or

[Intel-gfx] [PATCH i-g-t] tests/gem_softpin: New tests for softpin feature

These tests exercise the userptr ioctl to create shared buffers between CPU and GPU. They contain error and normal usage scenarios. They also contain a couple of stress tests which copy buffers between CPU and GPU. These tests rely on the softpin patch in order to pin buffers to a certain VA.

Re: [Intel-gfx] [PATCH v2 03/10] drm/i915: Check VBT for CRT port presence on HSW/BDW

2015-12-01 14:07 GMT-02:00 : > From: Ville Syrjälä > > Unfortunatey there appear to quite a few HSW/BDW machines (eg. > NUCs, Brix Pro) in the wild with LPT/WPT-H but non-working FDI. > FDI training fails every single time on these

Re: [Intel-gfx] [PATCH 04/10] drm/i915: Add "missing" break to haswell_get_ddi_pll()

2015-12-01 11:08 GMT-02:00 : > From: Ville Syrjälä > > While not techically needed on the last case in the switch statement, "techically" > the 'break' makes it look better IMO. Just out of curiosity: what's your opinion on the

[Intel-gfx] [PATCH] drm/i915: Clean up device info structure definitions

Beginning with gen7, newer devices repetitively redefine values for the device info structure members. This patch simplifies the structure definitions by grouping member value definitions into the existing GEN7_FEATURES #define and into the new GEN7_LP_FEATURES and HSW_FEATURES #defines.

Re: [Intel-gfx] [PATCH v2 03/10] drm/i915: Check VBT for CRT port presence on HSW/BDW

On Tue, Dec 01, 2015 at 05:28:19PM -0200, Paulo Zanoni wrote: > 2015-12-01 14:07 GMT-02:00 : > > From: Ville Syrjälä > > > > Unfortunatey there appear to quite a few HSW/BDW machines (eg. > > NUCs, Brix Pro) in the wild with LPT/WPT-H

Re: [Intel-gfx] [PATCH] drm/i915: Force PSR exit when IRQ_HPD is detected on eDP.

On Tue, 2015-12-01 at 20:56 +0200, Ville Syrjälä wrote: > On Wed, Nov 18, 2015 at 11:19:06AM -0800, Rodrigo Vivi wrote: > > According to VESA spec: "If a Source device receives and IRQ_HPD > > while in a PSR active state, and cannot identify what caused the > > IRQ_HPD to be generated, based on

Re: [Intel-gfx] [PATCH 04/10] drm/i915: Add "missing" break to haswell_get_ddi_pll()

On Tue, Dec 01, 2015 at 05:34:40PM -0200, Paulo Zanoni wrote: > 2015-12-01 11:08 GMT-02:00 : > > From: Ville Syrjälä > > > > While not techically needed on the last case in the switch statement, > > "techically" > > > the 'break'

Re: [Intel-gfx] [PATCH 04/15] drm/i915: Cache the reset_counter for the request

On Sun, Nov 29, 2015 at 08:48:02AM +, Chris Wilson wrote: > Instead of querying the reset counter before every access to the ring, > query it the first time we touch the ring, and do a final compare when > submitting the request. For correctness, we need to then sanitize how > the

[Intel-gfx] [PATCH 09/20] drm: fix inclusion of drm.h in exynos_sarea.h

Using `#include "drm.h"` instead of `#include ` allow drm headers to be moved in another directory without changes, like for the libdrm imports. Signed-off-by: Gabriel Laskar CC: Emil Velikov CC: Mikko Rapeli ---

Re: [Intel-gfx] [PATCH v4] drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping

On Tue, 24 Nov 2015, Daniel Vetter wrote: > On Sat, Nov 21, 2015 at 02:01:55AM +0800, kbuild test robot wrote: >> Hi Chris, >> >> [auto build test WARNING on drm-intel/for-linux-next] >> [cannot apply to v4.4-rc1 next-20151120] >> >> url: >>

Re: [Intel-gfx] [PATCH 04/15] drm/i915: Cache the reset_counter for the request

On Tue, Dec 01, 2015 at 08:47:44AM +, Chris Wilson wrote: > On Tue, Dec 01, 2015 at 09:31:31AM +0100, Daniel Vetter wrote: > > On Sun, Nov 29, 2015 at 08:48:02AM +, Chris Wilson wrote: > > > Instead of querying the reset counter before every access to the ring, > > > query it the first

Re: [Intel-gfx] [PATCH 05/15] drm/i915: Suppress error message when GPU resets are disabled

On Sun, Nov 29, 2015 at 08:48:03AM +, Chris Wilson wrote: > If we do not have lowlevel support for reseting the GPU, or if the user > has explicitly disabled reseting the device, the failure is expected. > Since it is an expected failure, we should be using a lower priority > message than

Re: [Intel-gfx] [PATCH 04/11] drm/i915: Kill duplicated PNV .get_display_clock_speed() assignment

On Mon, Nov 30, 2015 at 04:23:45PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Somehow we accumulated a duplicated .get_display_clock_speed() > assignment for PNV in > commit 34edce2fea69 ("drm/i915: Add cdclk extraction for g33, g965gm

Re: [Intel-gfx] [PATCH 04/15] drm/i915: Cache the reset_counter for the request

On Tue, Dec 01, 2015 at 09:31:31AM +0100, Daniel Vetter wrote: > On Sun, Nov 29, 2015 at 08:48:02AM +, Chris Wilson wrote: > > Instead of querying the reset counter before every access to the ring, > > query it the first time we touch the ring, and do a final compare when > > submitting the

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Let hangcheck score decay faster than loop increment

On Mon, Nov 30, 2015 at 05:18:43PM +, Chris Wilson wrote: > On Mon, Nov 30, 2015 at 06:53:07PM +0200, Mika Kuoppala wrote: > > We decay hangcheck score, instead of setting it to zero, > > when seqno moves forward. This was added as mechanism to > > detect batches full of invalid waits. > >

Re: [Intel-gfx] [PATCH] drm/i915: Check the timeout passed to i915_wait_request

On Thu, 26 Nov 2015, Chris Wilson wrote: > On Thu, Nov 26, 2015 at 03:49:00PM +0100, Daniel Vetter wrote: >> On Thu, Nov 26, 2015 at 01:31:42PM +, Chris Wilson wrote: >> > We have relied upon the sole caller (wait_ioctl) validating the timeout >> > argument. However,

Re: [Intel-gfx] [PATCH v2] drm/i915: Do a better job at disabling primary plane in the noatomic case.

On Mon, 23 Nov 2015, Maarten Lankhorst wrote: > Op 13-11-15 om 14:28 schreef Ander Conselvan De Oliveira: >> On Thu, 2015-11-12 at 14:58 +0100, Maarten Lankhorst wrote: >>> Op 12-11-15 om 14:37 schreef Ander Conselvan De Oliveira: On Wed, 2015-11-11 at

Re: [Intel-gfx] [PATCH 1/2] tests/gem_eio: New ABI - no EIO even from wait_ioctl

On Tue, Dec 01, 2015 at 09:28:08AM +0100, Daniel Vetter wrote: > On Mon, Nov 30, 2015 at 10:11:12AM +, Chris Wilson wrote: > > On Thu, Nov 26, 2015 at 12:34:34PM +0100, Daniel Vetter wrote: > > > So there's 3 competing proposals for what wait_ioctl should do wrt > > > -EIO: > > > > > > -

Re: [Intel-gfx] [PATCH 1/2] tests/gem_eio: New ABI - no EIO even from wait_ioctl

On Tue, Dec 01, 2015 at 09:04:23AM +, Chris Wilson wrote: > On Tue, Dec 01, 2015 at 09:28:08AM +0100, Daniel Vetter wrote: > > On Mon, Nov 30, 2015 at 10:11:12AM +, Chris Wilson wrote: > > > On Thu, Nov 26, 2015 at 12:34:34PM +0100, Daniel Vetter wrote: > > > > So there's 3 competing

Re: [Intel-gfx] [PATCH 1/2] tests/gem_eio: New ABI - no EIO even from wait_ioctl

On Tue, Dec 01, 2015 at 10:13:10AM +0100, Daniel Vetter wrote: > On Tue, Dec 01, 2015 at 09:04:23AM +, Chris Wilson wrote: > > On Tue, Dec 01, 2015 at 09:28:08AM +0100, Daniel Vetter wrote: > > > On Mon, Nov 30, 2015 at 10:11:12AM +, Chris Wilson wrote: > > > > On Thu, Nov 26, 2015 at

Re: [Intel-gfx] [PATCH i-g-t 1/3] tests/kms_force_connector: Fixes

On 1 December 2015 at 08:08, Daniel Vetter wrote: > Two things: > - Somehow the kernel's mode list changed with our EDID. No idea > whether that's the right thing here since I'm not really an EDID > expert. But then again the testcase wants to check that the >

[Intel-gfx] [PATCH v2] drm/i915: Disable fast link training if DP config changes

Disable DP fast link training if DP link configuration changes. If one of the DP link parameters i.e. link bandwidth, lane count, rate selection, port clock or bpp changes the link training does no longer apply the previously computed voltage swing and pre-emphasis values. Instead, the link

Re: [Intel-gfx] [PATCH i-g-t 1/3] tests/kms_force_connector: Fixes

On Tue, Dec 01, 2015 at 10:11:14AM +, Thomas Wood wrote: > On 1 December 2015 at 08:08, Daniel Vetter wrote: > > Two things: > > - Somehow the kernel's mode list changed with our EDID. No idea > > whether that's the right thing here since I'm not really an EDID > >

[Intel-gfx] [PATCH i-g-t 1/3] tests/kms_force_connector: Fixes

Somehow the kernel's mode list changed with our EDID. No idea whether that's the right thing here since I'm not really an EDID expert. But then again the testcase wants to check that the injection works, not validate the kernel's parser. v2: Only check the preferred mode for more future-proofing

[Intel-gfx] [PATCH i-g-t 3/3] tests/kms_force_connector: Include in BAT set

Forcing connector state is a basic piece of our test infrastructure that we use in all the kms_ tests. It allows us to run tests even if no outputs are connected. They're also really fast, so perfect candidates for inclusion into the BAT set. Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH i-g-t 2/3] lib/kms+tests: Use cached connector state

Speeds up testcases except for those where we want to exercise the probing itself. The only exceptions left where we do a full probe are - pm_rpm: We use it to make sure the kernel doesn't get things wrong with power domains, so we really want to exercise the full probe paths. And there the

Re: [Intel-gfx] [PATCH] drm/i915: fix fdi related fifo underruns on hsw

On Sat, 2015-11-28 at 11:05 +0100, Daniel Vetter wrote: > Similar to > > commit 37ca8d4ccd9860df0747aa2ea281a3c9c4bf8826 > Author: Ville Syrjälä > Date: Fri Oct 30 19:20:27 2015 +0200 > > drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB > > we can

Re: [Intel-gfx] [PATCH] drm/i915: fix fdi related fifo underruns on hsw

On Sat, 2015-11-28 at 11:05 +0100, Daniel Vetter wrote: > Similar to > > commit 37ca8d4ccd9860df0747aa2ea281a3c9c4bf8826 > Author: Ville Syrjälä > Date: Fri Oct 30 19:20:27 2015 +0200 > > drm/i915: Enable PCH FIFO underruns later on ILK/SNB/IVB > > we can

[Intel-gfx] [PATCH 3/3] drm/i915/bxt: backlight clock gating workaround

From: Imre Deak Per bspec, "Backlight PWM may stop in the asserted state, causing backlight to stay fully on. WA: Before disabling PWM, set CLKGATE_DIS_0 0x46530 bit 13 PWM1 Gating Dis (for PWM1) or bit 14 PWM2 Gating Dis (for PWM2). The bits can remain set without harm."

[Intel-gfx] [PATCH 2/3] drm/i915: use default 200 Hz backlight frequency

If the backlight modulation frequency can't be extracted from the registers or from VBT, use 200 Hz as the default. This may enable backlight on some machines that previously failed. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_panel.c | 16 +---

[Intel-gfx] [PATCH 1/3] drm/i915/bxt: add support for setting backlight freq from vbt

The only missing piece is the function to convert frequency to PWM register value. The PWM is based on 19.2 MHz clock, except for BXT A step, which is based on CDCLK, and which we ignore. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_panel.c | 9 + 1

Re: [Intel-gfx] [PATCH] drm/i915: fix fdi related fifo underruns on hsw

On Tue, Dec 01, 2015 at 10:15:01AM +0200, Mika Kahola wrote: > On Sat, 2015-11-28 at 11:05 +0100, Daniel Vetter wrote: > > Similar to > > > > commit 37ca8d4ccd9860df0747aa2ea281a3c9c4bf8826 > > Author: Ville Syrjälä > > Date: Fri Oct 30 19:20:27 2015 +0200 > > >

Re: [Intel-gfx] [PATCH 1/2] tests/gem_eio: New ABI - no EIO even from wait_ioctl

On Mon, Nov 30, 2015 at 10:11:12AM +, Chris Wilson wrote: > On Thu, Nov 26, 2015 at 12:34:34PM +0100, Daniel Vetter wrote: > > So there's 3 competing proposals for what wait_ioctl should do wrt > > -EIO: > > > > - return -EIO when the gpu is wedged. Not terribly useful for > > userspace

[Intel-gfx] [PATCH i-g-t 3/3] tests/kms_force_connector: Include in BAT set

Forcing connector state is a basic piece of our test infrastructure that we use in all the kms_ tests. It allows us to run tests even if no outputs are connected. They're also really fast, so perfect candidates for inclusion into the BAT set. Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH i-g-t 1/3] tests/kms_force_connector: Fixes

Two things: - Somehow the kernel's mode list changed with our EDID. No idea whether that's the right thing here since I'm not really an EDID expert. But then again the testcase wants to check that the injection works, not validate the kernel's parser. - We need to disable the forcing

[Intel-gfx] [PATCH i-g-t 2/3] lib/kms+tests: Use cached connector state

Speeds up testcases except for those where we want to exercise the probing itself. The only exceptions left where we do a full probe are - pm_rpm: We use it to make sure the kernel doesn't get things wrong with power domains, so we really want to exercise the full probe paths. And there the

Re: [Intel-gfx] [PATCH i-g-t 3/3] tests/kms_force_connector: Include in BAT set

On 1 December 2015 at 10:24, Daniel Vetter wrote: > Forcing connector state is a basic piece of our test infrastructure > that we use in all the kms_ tests. It allows us to run tests even if > no outputs are connected. > > They're also really fast, so perfect candidates

Re: [Intel-gfx] [PATCH i-g-t] tests/gem_softpin: New tests for softpin feature

Hi, Just one comment deep down. On 30/11/15 18:22, Vinay Belgaumkar wrote: These tests exercise the userptr ioctl to create shared buffers between CPU and GPU. They contain error and normal usage scenarios. They also contain a couple of stress tests which copy buffers between CPU and GPU.

[Intel-gfx] [PATCH 2/3] drm/i915: Store the reset counter when constructing a request

As the request is only valid during the same global reset epoch, we can record the current reset_counter when constructing the request and reuse it when waiting upon that request in future. This removes a very hairy atomic check serialised by the struct_mutex at the time of waiting and allows us

[Intel-gfx] [PATCH 3/3] drm/i915: Prevent leaking of -EIO from i915_wait_request()

Reporting -EIO from i915_wait_request() has proven very troublematic over the years, with numerous hard-to-reproduce bugs cropping up in the corner case of where a reset occurs and the code wasn't expecting such an error. If the we reset the GPU or have detected a hang and wish to reset the GPU,

[Intel-gfx] [PATCH 1/3] drm/i915: Hide the atomic_read(reset_counter) behind a helper

This is just a little bit of syntatic sugar to hide the atomic_reads() throughout the code to retrieve the current reset_counter. It also provides the other utility functions to check the reset state on the already read reset_counter, so that we can read it once and do multiple tests rather than

[Intel-gfx] [PATCH 2/2] drm/edid: report latency due to reading edids

A forced EDID read takes 22.5ms best-case, and that's per 128byte block. HDMI screens tend to have 2-3 of those. Mutliply that by a few outputs and then it's clear that userspace really never ever should re-probe connector state on its own and trust the kernel to tell it when anything changed. The

[Intel-gfx] [PATCH 1/2] kernel/latencytop: Add non-scheduler interface for latency reporting

Some sources of significant amounts of latency aren't simple sleeps but instead busy-loops or a series of hundreds of small sleeps simply because the hardware can't do better. Unfortunately latencytop doesn't register these and so they slip under the radar. Hence expose a simplified interface to

Re: [Intel-gfx] [PATCH 2/2] drm/i915: abstract i2c bit banging fallback in gmbus xfer

On Tue, 01 Dec 2015, Ville Syrjälä wrote: > On Tue, Dec 01, 2015 at 04:29:26PM +0200, Jani Nikula wrote: >> Choose between i2c bit banging and gmbus in a new higher level function, >> and let the i2c core retry the first time we fall back to bit banging. >> >>

Re: [Intel-gfx] [PATCH 07/11] drm/i915: Store rawclk_freq in dev_priv

On Tue, 01 Dec 2015, Ville Syrjälä wrote: > On Tue, Dec 01, 2015 at 02:47:41PM +0200, Jani Nikula wrote: >> On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote: >> > From: Ville Syrjälä >> > >> > Generalize rawclk handling by

Re: [Intel-gfx] [PATCH 03/15] drm/i915: Only spin whilst waiting on the current request

On 30/11/15 10:06, Tvrtko Ursulin wrote: On 29/11/15 08:48, Chris Wilson wrote: Limit busywaiting only to the request currently being processed by the GPU. If the request is not currently being processed by the GPU, there is a very low likelihood of it being completed within the 2 microsecond

Re: [Intel-gfx] [PATCH 1/2] kernel/latencytop: Add non-scheduler interface for latency reporting

On Tue, Dec 01, 2015 at 04:29:27PM +0100, Daniel Vetter wrote: > Some sources of significant amounts of latency aren't simple sleeps > but instead busy-loops or a series of hundreds of small sleeps simply > because the hardware can't do better. Unfortunately latencytop doesn't > register these and

Re: [Intel-gfx] [PATCH 2/2] drm/i915: abstract i2c bit banging fallback in gmbus xfer

On Tue, Dec 01, 2015 at 05:38:30PM +0200, Jani Nikula wrote: > On Tue, 01 Dec 2015, Ville Syrjälä wrote: > > On Tue, Dec 01, 2015 at 04:29:26PM +0200, Jani Nikula wrote: > >> Choose between i2c bit banging and gmbus in a new higher level function, > >> and let the

[Intel-gfx] [PATCH] kernel/latencytop: Add non-scheduler interface for latency reporting

Some sources of significant amounts of latency aren't simple sleeps but instead busy-loops or a series of hundreds of small sleeps simply because the hardware can't do better. Unfortunately latencytop doesn't register these and so they slip under the radar. Hence expose a simplified interface to

Re: [Intel-gfx] [PATCH 03/15] drm/i915: Only spin whilst waiting on the current request

On Tue, Dec 01, 2015 at 03:47:34PM +, Dave Gordon wrote: > On 30/11/15 10:06, Tvrtko Ursulin wrote: > > > >On 29/11/15 08:48, Chris Wilson wrote: > >>Limit busywaiting only to the request currently being processed by the > >>GPU. If the request is not currently being processed by the GPU,

[Intel-gfx] [PATCH] drm/i915: Inspect subunit states on hangcheck

If head seems stuck and engine in question is rcs, inspect subunit state transitions from undone to done, before deciding that this really is a hang instead of limited progress. Only account the transitions of subunits from undone to done once, to prevent unstable subunit states to keep us falsely

[Intel-gfx] [PATCH] drm/i915: Inspect subunit states on hangcheck

If head seems stuck and engine in question is rcs, inspect subunit state transitions before deciding that this really is a hang instead of limited progress. References: https://bugs.freedesktop.org/show_bug.cgi?id=93029 Cc: Chris Wilson Cc: Dave Gordon

Re: [Intel-gfx] [PATCH 02/11] drm/i915: Fix vbt PWM max setup for CTG

On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > CTG uses hrawclk for backlight, so calculate the max based on that > instead of cdclk. If you say so. Acked-by: Jani Nikula > Fixes: aa17cdb4f836

Re: [Intel-gfx] [PATCH 06/11] drm/i915: Use cached cdclk_freq for PWM calculations

On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > No need to read out cdclk from the hardware, we have it already > cached in dev_priv. > > Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula

Re: [Intel-gfx] [PATCH 09/11] drm/i915: Use g4x_get_aux_clock_divider() for VLV/CHV

On Mon, 30 Nov 2015, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > With the hrawclk frequency cached in dev_priv, we can simply use > g4x_get_aux_clock_divider() for VLV/CHV. > > Signed-off-by: Ville Syrjälä

  1   2   >