[Intel-gfx] [PATCH v4 4/4] Try inlining sg_next()

Signed-off-by: Dave Gordon Cc: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 23 +-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH v4 2/4] 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 v4 1/4] drm/i915: refactor i915_gem_object_pin_map()

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 must be undone before return) into its

[Intel-gfx] [PATCH v4 3/4] Introduce & use new lightweight SGL iterators

The existing for_each_sg_page() iterator is somewhat heavyweight, and is limiting i915 driver performance in a few benchmarks. So here we introduce somewhat lighter weight iterators, primarily for use with GEM objects or other case where we need only deal with whole aligned pages. Unlike the old

Re: [Intel-gfx] [Nouveau] [PATCH v4] vga_switcheroo: Add helper for deferred probing

Hi Lukas, On 19 May 2016 at 15:39, Lukas Wunner wrote: > +bool vga_switcheroo_client_probe_defer(struct pci_dev *pdev) > +{ > + if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) { Not sure if we want/need this, yet at least. This changes behaviour which is not what

[Intel-gfx] *ERROR* Hangcheck timer elapsed... render ring idle

I'm still seeing this periodically, previous to today it happened on April 24th. Doesn't matter what I'm doing the video will freeze however the cursor will still move. Only option is to SSH in to the system from my tablet and do a reboot. Note: This has been going on since Sept 13, 2014. There

[Intel-gfx] [PATCH 4/4] drm/i915/skl+: Use scaling amount for plane data rate calculation (v4)

From: "Kumar, Mahesh" if downscaling is enabled plane data rate increases according to scaling amount. take scaling amount under consideration while calculating plane data rate v2: Address Matt's comments, where data rate was overridden because of missing else. v3 (by

Re: [Intel-gfx] [PATCH] drm: Nuke ->vblank_disable_allowed

Hi Daniel, Thank you for the patch. On Wednesday 18 May 2016 22:29:57 Daniel Vetter wrote: > This was added in > > commit 0a3e67a4caac273a3bfc4ced3da364830b1ab241 > Author: Jesse Barnes > Date: Tue Sep 30 12:14:26 2008 -0700 > > drm: Rework vblank-wait handling

Re: [Intel-gfx] [PATCH i-g-t] tools: Add intel_dp_compliance for DisplayPort 1.2 compliance automation

Thanks for reviewing, I have a few comments/queries as below: Manasi On Thu, May 19, 2016 at 06:40:45PM +0300, Marius Vlad wrote: > On Mon, May 16, 2016 at 05:50:40PM -0700, Manasi Navare wrote: > > This is the userspace component of the Displayport Compliance > > testing software required for

Re: [Intel-gfx] [PATCH v2] drm/i915/fbdev: Limit the global async-domain synchronization

Hi Chris, On Thu, May 19, 2016 at 09:28:10AM +0100, Chris Wilson wrote: > During cleanup we have to synchronise with the async task we are using > to initialise and register our fbdev. Currently, we are using a full > synchronisation on the global domain, but we can restrict this to just >

Re: [Intel-gfx] [PATCH 22/21] drm/i915: Assert the dbuf is enabled when disabling DC5/6

On Mon, 2016-05-16 at 16:59 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Like with cdclk, the DMC is supposed to manage dbuf enabling/disabling. > Let's make sure it has correctly restored the dbuf state to enabled > when we disable the DC

Re: [Intel-gfx] [PATCH 21/21] drm/i915: Set BXT cdclk to minimum initially

On Fri, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > In case the driver is initialized without active displays, we should > just drop the cdclk to the minimum frequency right off the bat. There > might not be a modeset

Re: [Intel-gfx] [PATCH 20/21] drm/i915: Replace bxt_verify_cdclk_state() with a more generic cdclk check

On Fri, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Rather than having a BXT specific function to make sure the DE PLL is > enabled after disabling DC6, let's just make sure the current cdclk > is the same as what we

Re: [Intel-gfx] [PATCH 19/21] drm/i915: Make bxt_set_cdclk() operate in terms of the current vs target DE PLL vco

On Fri, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Make bxt_set_cdclk() more readable by looking at current vs. target > DE PLL vco to determine if the DE PLL needs disabling and/or enabling. > We can also calculate

Re: [Intel-gfx] [PATCH 18/21] drm/i915: Rewrite broxton_get_display_clock_speed() in terms of the DE PLL vco/refclk

On Fri, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Now that we've read out the DE PLL vco and refclk, we can just use them > in the cdclk calculation. While at it switch over to > DIV_ROUND_CLOSEST(). > >

Re: [Intel-gfx] [PATCH 17/21] drm/i915: Update cached cdclk state from broxton_init_cdclk()

On Fri, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Let's make sure our cached cdclk state is accurate right after > broxton_init_cdclk() whether or not we end up changing the cdclk > frequency. > > Signed-off-by:

Re: [Intel-gfx] [PATCH 16/21] drm/i915: Store BXT DE PLL vco and ref clocks in dev_priv

On Fri, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We have need to know the DE PLL refclk and output frequency in various > cdclk calculations, so let's store those in dev_priv. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 15/21] drm/i915: Extract bxt DE PLL enable/disable from broxton_set_cdclk()

On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Enabling and disalbing the DE PLL are two nice self contained > operations, so let's move them into a few small helper functions. > Makes it easier to see the forest

Re: [Intel-gfx] [PATCH 14/21] drm/i915: Store cdclk PLL reference clock under dev_priv

On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Future platforms will have multiple options for the cdclk PLL reference > clock, so let's start tracking that under dev_priv alreday on SKL, > although on SKL it's

Re: [Intel-gfx] [PATCH 13/21] drm/i915: Rename skl_vco_freq to cdclk_pll.vco

On Thu, May 19, 2016 at 07:17:17PM +0300, Imre Deak wrote: > On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > We'll want to store the cdclk PLL (whatever PLL that is in reality) vco > > frequency somewhere on

Re: [Intel-gfx] [PATCH 13/21] drm/i915: Rename skl_vco_freq to cdclk_pll.vco

On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We'll want to store the cdclk PLL (whatever PLL that is in reality) vco > frequency somewhere on other platforms too, so let's rename the > skl_vco_freq to

[Intel-gfx] ✗ Ro.CI.BAT: failure for vga_switcheroo: Add helper for deferred probing

== Series Details == Series: vga_switcheroo: Add helper for deferred probing URL : https://patchwork.freedesktop.org/series/7409/ State : failure == Summary == Series 7409v1 vga_switcheroo: Add helper for deferred probing http://patchwork.freedesktop.org/api/1.0/series/7409/revisions/1/mbox

Re: [Intel-gfx] [PATCH 12/21] drm/i915: Make 308 and 671 MHz cdclks more accurate on SKL

On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The SKL 308.57 MHz cdclk is probably 8640/28 = ~308.571 Mhz. > Similartly the 617.14 MHz cdclk is probably 8640/14 = ~617.143 MHz. > Let's use the slightly more

Re: [Intel-gfx] [PATCH 11/21] drm/i915: Move SKL+ DBUF enable/disable to display core init/uninit

On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > SKL and BXT have the same snippets of code for enabling disabling the > DBUF. Extract those into helpers and move the calls from > init/unit_cdclk() to the display core

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/userptr: Convert to drm_i915_private

== Series Details == Series: drm/i915/userptr: Convert to drm_i915_private URL : https://patchwork.freedesktop.org/series/7413/ State : failure == Summary == Series 7413v1 drm/i915/userptr: Convert to drm_i915_private http://patchwork.freedesktop.org/api/1.0/series/7413/revisions/1/mbox Test

Re: [Intel-gfx] [PATCH 10/21] drm/i915: Unify SKL cdclk init paths

On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Currently we initialize cdclk on SKL from two different places, > depending on whether it's during driver init or resume. Let's > unify it to happen from the same place

Re: [Intel-gfx] [CI 16/20] drm/i915: Only query timestamp when measuring elapsed time

On 19/05/16 12:32, Chris Wilson wrote: Avoid the two calls to ktime_get_raw_ns() (at best it reads the TSC) as we only need to compute the elapsed time for a timed wait. v2: Eliminate the unused local variable reducing the function size by 64 bytes (using the storage space on the callers stack

Re: [Intel-gfx] [PATCH i-g-t] tools: Add intel_dp_compliance for DisplayPort 1.2 compliance automation

On Mon, May 16, 2016 at 05:50:40PM -0700, Manasi Navare wrote: > This is the userspace component of the Displayport Compliance > testing software required for compliance testing of the I915 > Display Port driver. This must be running in order to successfully > complete Display Port compliance

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

On Thu, May 19, 2016 at 2:10 PM, Patrik Jakobsson wrote: > On Tue, May 17, 2016 at 03:08:04PM +0200, Maarten Lankhorst wrote: >> Signed-off-by: Maarten Lankhorst > > We could have had a short note on what the patch does, though

Re: [Intel-gfx] [PATCH] drm/i915/userptr: Convert to drm_i915_private

On 19/05/16 16:17, Chris Wilson wrote: userptr directly only uses drm_device in a single interface where it meant to use drm_i915_private (everywhere else we have to derive it from the drm_i915_gem_object and so require going from drm_device). Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH] drm/i915/userptr: Convert to drm_i915_private

userptr directly only uses drm_device in a single interface where it meant to use drm_i915_private (everywhere else we have to derive it from the drm_i915_gem_object and so require going from drm_device). Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: only disable memory self-refresh on GMCH

On Thu, May 19, 2016 at 01:23:53PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: only disable memory self-refresh on GMCH > URL : https://patchwork.freedesktop.org/series/7406/ > State : failure > > == Summary == > > Series 7406v1 drm/i915: only disable memory

Re: [Intel-gfx] [PATCH 09/21] drm/i915: Beef up skl_sanitize_cdclk() a bit

On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Also verify the DPLL_CTRL1 register value in skl_sanitize_cdclk(), throw > out a few unneeded variables, and write the CDCLK_CTL check a bit more > legible way. > >

Re: [Intel-gfx] [PATCH 08/21] drm/i915: Keep track of preferred cdclk vco frequency on SKL

On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Now that skl_vco_freq tracks the actual DPLL0 vco frequency, we'll need > something that keeps track of which vco frequency we want to use in case > the current vco is

[Intel-gfx] [PATCH 2/2] drm/i915/mst: Reset MST after resume when necessary

A follow-up to the previous commit, we skip checking the status of the MST device and completely reprobe it if drm_dp_mst_topology_mgr_resume() returns -EINVAL. Cc: sta...@vger.kernel.org Signed-off-by: Lyude --- drivers/gpu/drm/i915/intel_dp.c | 11 +-- 1 file

[Intel-gfx] [PATCH 1/2] drm/dp/mst: Reprobe EDID for MST ports on resume

As observed with the latest ThinkPad docks, we unfortunately can't rely on docks keeping us updated with hotplug events that happened while we were suspended. On top of that, even if the number of connectors remains the same between suspend and resume it's still not safe to assume that there were

Re: [Intel-gfx] [PATCH i-g-t] assembler/: Fix lex warnings for %empty and %nonassoc.

On Thu, May 19, 2016 at 07:02:40AM -0700, Ben Widawsky wrote: > On Thu, May 19, 2016 at 12:28:10PM +0100, Damien Lespiau wrote: > > On Mon, May 16, 2016 at 01:39:10PM +0300, Marius Vlad wrote: > > > Signed-off-by: Marius Vlad > > > --- > > > assembler/gram.y | 74 > > >

Re: [Intel-gfx] [PATCH i-g-t] assembler/: Fix lex warnings for %empty and %nonassoc.

On Thu, May 19, 2016 at 12:28:10PM +0100, Damien Lespiau wrote: > On Mon, May 16, 2016 at 01:39:10PM +0300, Marius Vlad wrote: > > Signed-off-by: Marius Vlad > > --- > > assembler/gram.y | 74 > > > > 1 file

[Intel-gfx] [PATCH v4] vga_switcheroo: Add helper for deferred probing

So far we've got one condition when DRM drivers need to defer probing on a dual GPU system and it's coded separately into each of the relevant drivers. As suggested by Daniel Vetter, deduplicate that code in the drivers and move it to a new vga_switcheroo helper. This yields better encapsulation

Re: [Intel-gfx] [PATCH 07/21] drm/i915: Allow enable/disable of DPLL0 around cdclk changes on SKL

On to, 2016-05-19 at 16:18 +0300, Ville Syrjälä wrote: > On Thu, May 19, 2016 at 04:04:40PM +0300, Imre Deak wrote: > > On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > > > From: Ville Syrjälä > > > > > > In case we originally guessed wrong

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: only disable memory self-refresh on GMCH

== Series Details == Series: drm/i915: only disable memory self-refresh on GMCH URL : https://patchwork.freedesktop.org/series/7406/ State : failure == Summary == Series 7406v1 drm/i915: only disable memory self-refresh on GMCH

Re: [Intel-gfx] [PATCH 07/21] drm/i915: Allow enable/disable of DPLL0 around cdclk changes on SKL

On Thu, May 19, 2016 at 04:04:40PM +0300, Imre Deak wrote: > On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > In case we originally guessed wrong which lcpll vco frequency to use, > > we will need to shut down

Re: [Intel-gfx] [CI 05/20] drm/i915: Make queueing the hangcheck work inline

On Thu, May 19, 2016 at 01:53:51PM +0100, Tvrtko Ursulin wrote: > > > On 19/05/16 12:32, Chris Wilson wrote: > >Since the function is a small wrapper around schedule_delayed_work(), > >move it inline to remove the function call overhead for the principle > >caller. > > Alternatively move it to

Re: [Intel-gfx] [CI 04/20] drm/i915: Remove the dedicated hangcheck workqueue

On Thu, May 19, 2016 at 01:50:51PM +0100, Tvrtko Ursulin wrote: > > On 19/05/16 12:32, Chris Wilson wrote: > >The queue only ever contains at most one item and has no special flags. > >It is just a very simple wrapper around the system-wq - a complication > >with no benefits. > > How much time

Re: [Intel-gfx] [PATCH 07/21] drm/i915: Allow enable/disable of DPLL0 around cdclk changes on SKL

On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > In case we originally guessed wrong which lcpll vco frequency to use, > we will need to shut down the pll and restart it when reprogamming the > cdclk. > > This also

Re: [Intel-gfx] [CI 05/20] drm/i915: Make queueing the hangcheck work inline

On 19/05/16 12:32, Chris Wilson wrote: Since the function is a small wrapper around schedule_delayed_work(), move it inline to remove the function call overhead for the principle caller. Alternatively move it to i915_gem.c and let the compiler decide? But it is small enough, so anyway:

Re: [Intel-gfx] [CI 03/20] drm/i915: Delay queuing hangcheck to wait-request

On Thu, May 19, 2016 at 01:34:55PM +0100, Tvrtko Ursulin wrote: > > On 19/05/16 12:32, Chris Wilson wrote: > >We can forgo queuing the hangcheck from the start of every request to > >until we wait upon a request. This reduces the overhead of every > >request, but may increase the latency of

Re: [Intel-gfx] [CI 04/20] drm/i915: Remove the dedicated hangcheck workqueue

On 19/05/16 12:32, Chris Wilson wrote: The queue only ever contains at most one item and has no special flags. It is just a very simple wrapper around the system-wq - a complication with no benefits. How much time do we take in the reset case - is it acceptable to do that work from the

[Intel-gfx] [PATCH] drm/i915: only disable memory self-refresh on GMCH

The atomic version of intel_pre_plane_update did not check for HAS_GMCH_DISPLAY before calling intel_set_memory_cxsr(). While this doesn't cause any issues on its own (it will return without doing anything if the hardware doesn't have the required feature), the drm_wait_one_vblank() that is needed

[Intel-gfx] [PATCH i-g-t] build: Skip configure step if is NOCONFIGURE set

Allow users of autogen.sh to skip the call to configure, which is needed when building out of tree. Signed-off-by: Tomeu Vizoso --- autogen.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/autogen.sh b/autogen.sh index

Re: [Intel-gfx] [PATCH 06/21] drm/i915: Report the current DPLL0 vco on SKL/KBL

On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Signed-off-by: Ville Syrjälä Reviewed-by: Imre Deak > --- >  drivers/gpu/drm/i915/intel_display.c | 9 +++--

Re: [Intel-gfx] [PATCH 05/21] drm/i915: Actually read out DPLL0 vco on skl from hardware

On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Currently we're trying to guess which lcpll vco frequency is used > use based on the cdclk. That doesn't work for cdclk==540 since > both vco frequencies can generate a

Re: [Intel-gfx] [CI 03/20] drm/i915: Delay queuing hangcheck to wait-request

On 19/05/16 12:32, Chris Wilson wrote: We can forgo queuing the hangcheck from the start of every request to until we wait upon a request. This reduces the overhead of every request, but may increase the latency of detecting a hang. Howeever, if nothing every waits upon a hang, did it ever

Re: [Intel-gfx] [PATCH v2 00/21] Rework page flip, remove cs flips, async unpin and unified pageflip.

On Tue, May 17, 2016 at 03:07:43PM +0200, Maarten Lankhorst wrote: > Connector lifetime patches forced a rethinking for handling connectors. > Instead of flushing modesets from the connector destroy function this > meant destroying the connector state inside the unpin_work function, > similar to

Re: [Intel-gfx] [CI 02/20] drm/i915/shrinker: Flush active on objects before counting

On 19/05/16 12:32, Chris Wilson wrote: As we inspect obj->active to decide how many objects we can shrink (we only shrink idle objects), it helps to flush the active lists first in order to have a more accurate count of available objects. Signed-off-by: Chris Wilson

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

On Tue, May 17, 2016 at 03:08:04PM +0200, Maarten Lankhorst wrote: > Signed-off-by: Maarten Lankhorst We could have had a short note on what the patch does, though reading it is quite straight forward. Either way is fine by me. Reviewed-by: Patrik Jakobsson

[Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [CI,01/20] drm: Restore double clflush on the last partial cacheline

== Series Details == Series: series starting with [CI,01/20] drm: Restore double clflush on the last partial cacheline URL : https://patchwork.freedesktop.org/series/7403/ State : warning == Summary == Series 7403v1 Series without cover letter

Re: [Intel-gfx] [PATCH 04/21] drm/i915: Extract skl_calc_cdclk()

On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We have many places where we want to pick a suitable cdclk frequency for > skl based on the dotclock and lcpll vco. Split that code into a small > helper and call it

Re: [Intel-gfx] [PATCH 03/21] drm/i915: Move the SKL DPLL0 VCO computation into intel_dp_compute_config()

On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Shared plls won't get assigned until the .compute_clocks() hook gets > called, which happens from the crtc .atomic_check hook. That's too late > as the cdclk

Re: [Intel-gfx] [PATCH v2 18/21] drm/i915: Make unpin async.

On Tue, May 17, 2016 at 03:08:01PM +0200, Maarten Lankhorst wrote: > All of intel_post_plane_update is handled there now, so move it over. > This is run after the hw state checker because it can't handle checking > crtc's separately yet. > > Signed-off-by: Maarten Lankhorst

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Enable GSE interrupt on BDW+ (rev2)

On Thu, May 19, 2016 at 10:02:40AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Enable GSE interrupt on BDW+ (rev2) > URL : https://patchwork.freedesktop.org/series/1366/ > State : failure > > == Summary == > > Series 1366v2 drm/i915: Enable GSE interrupt on BDW+ >

[Intel-gfx] [CI 06/20] drm/i915: Slaughter the thundering i915_wait_request herd

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 every client is woken up after every

[Intel-gfx] [CI 17/20] drm/i915: Convert trace-irq to the breadcrumb waiter

If we convert the tracing over from direct use of ring->irq_get() and over to the breadcrumb infrastructure, we only have a single user of the ring->irq_get and so we will be able to simplify the driver routines (eliminating the redundant validation and irq refcounting). v2: Move to a signaling

[Intel-gfx] [CI 19/20] drm/i915: Simplify enabling user-interrupts with L3-remapping

Borrow the idea from intel_lrc.c to precompute the mask of interrupts we wish to always enable to avoid having lots of conditionals inside the interrupt enabling. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_ringbuffer.c | 35

[Intel-gfx] [CI 04/20] drm/i915: Remove the dedicated hangcheck workqueue

The queue only ever contains at most one item and has no special flags. It is just a very simple wrapper around the system-wq - a complication with no benefits. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_dma.c | 8

[Intel-gfx] [CI 15/20] drm/i915: Stop setting wraparound seqno on initialisation

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. Using the testcases, we have very

[Intel-gfx] [CI 10/20] drm/i915: Allocate scratch page from stolen

With the last direct CPU access to the scratch page removed, we can now allocate it from our small amount of reserved system pages (stolen memory). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +++- 1 file changed, 3 insertions(+), 1

[Intel-gfx] [CI 18/20] drm/i915: Move the get/put irq locking into the caller

With only a single callsite for intel_engine_cs->irq_get and ->irq_put, we can reduce the code size by moving the common preamble into the caller, and we can also eliminate the reference counting. For completeness, as we are no longer doing reference counting on irq, rename the get/put vfunctions

[Intel-gfx] [CI 12/20] drm/i915: Add a delay between interrupt and inspecting the final seqno (ilk)

On Ironlake, there is no command nor register to ensure that the write from a MI_STORE command is completed (and coherent on the CPU) before the command parser continues. This means that the ordering between the seqno write and the subsequent user interrupt is undefined (like gen6+). So to ensure

[Intel-gfx] [CI 20/20] drm/i915: Remove debug noise on detecting fault-injection of missed interrupts

Since the tests can and do explicitly check debugfs/i915_ring_missed_irqs for the handling of a "missed interrupt", adding it to the dmesg at INFO is just noise. When it happens for real, we still class it as an ERROR. Signed-off-by: Chris Wilson ---

[Intel-gfx] [CI 09/20] drm/i915: Stop mapping the scratch page into CPU space

After the elimination of using the scratch page for Ironlake's breadcrumb, we no longer need to kmap the object. We therefore can move it into the high unmappable space and do not need to force the object to be coherent (i.e. snooped on !llc platforms). Signed-off-by: Chris Wilson

[Intel-gfx] [CI 07/20] drm/i915: Remove the lazy_coherency parameter from request-completed?

Now that we have split out the seqno-barrier from the engine->get_seqno() callback itself, we can move the users of the seqno-barrier to the required callsites simplifying the common code and making the required workaround handling much more explicit. Signed-off-by: Chris Wilson

[Intel-gfx] [CI 11/20] drm/i915: Refactor scratch object allocation for gen2 w/a buffer

The gen2 w/a buffer is stuffed into the same slot as the gen5+ scratch buffer. If we pass in the size we want to allocate for the scratch buffer, both callers can use the same routine. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c| 2 +-

[Intel-gfx] [CI 08/20] drm/i915: Use HWS for seqno tracking everywhere

By using the same address for storing the HWS on every platform, we can remove the platform specific vfuncs and reduce the get-seqno routine to a single read of a cached memory location. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 6 +--

[Intel-gfx] [CI 16/20] drm/i915: Only query timestamp when measuring elapsed time

Avoid the two calls to ktime_get_raw_ns() (at best it reads the TSC) as we only need to compute the elapsed time for a timed wait. v2: Eliminate the unused local variable reducing the function size by 64 bytes (using the storage space on the callers stack rather than adding to our stack frame)

[Intel-gfx] [CI 13/20] drm/i915: Check the CPU cached value of seqno after waking the waiter

If we have multiple waiters, we may find that many complete on the same wake up. If we first inspect the seqno from the CPU cache, we may reduce the number of heavyweight coherent seqno reads we require. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h |

[Intel-gfx] [CI 03/20] drm/i915: Delay queuing hangcheck to wait-request

We can forgo queuing the hangcheck from the start of every request to until we wait upon a request. This reduces the overhead of every request, but may increase the latency of detecting a hang. Howeever, if nothing every waits upon a hang, did it ever hang? It also improves the robustness of the

[Intel-gfx] [CI 01/20] drm: Restore double clflush on the last partial cacheline

This effectively reverts commit afcd950cafea6e27b739fe7772cbbeed37d05b8b Author: Chris Wilson Date: Wed Jun 10 15:58:01 2015 +0100 drm: Avoid the double clflush on the last cache line in drm_clflush_virt_range() as we have observed issues with serialisation of

[Intel-gfx] [CI 05/20] drm/i915: Make queueing the hangcheck work inline

Since the function is a small wrapper around schedule_delayed_work(), move it inline to remove the function call overhead for the principle caller. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 17 - drivers/gpu/drm/i915/i915_irq.c |

[Intel-gfx] [CI 14/20] drm/i915: Only apply one barrier after a breadcrumb interrupt is posted

If we flag the seqno as potentially stale upon receiving an interrupt, we can use that information to reduce the frequency that we apply the heavyweight coherent seqno read (i.e. if we wake up a chain of waiters). Signed-off-by: Chris Wilson ---

[Intel-gfx] [CI 02/20] drm/i915/shrinker: Flush active on objects before counting

As we inspect obj->active to decide how many objects we can shrink (we only shrink idle objects), it helps to flush the active lists first in order to have a more accurate count of available objects. Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] [PATCH i-g-t] assembler/: Fix lex warnings for %empty and %nonassoc.

On Mon, May 16, 2016 at 01:39:10PM +0300, Marius Vlad wrote: > Signed-off-by: Marius Vlad > --- > assembler/gram.y | 74 > > 1 file changed, 37 insertions(+), 37 deletions(-) The only way to test the change is to

Re: [Intel-gfx] [PATCH v2 17/21] drm/i915: Prepare connectors for nonblocking checks.

On Tue, May 17, 2016 at 03:08:00PM +0200, Maarten Lankhorst wrote: > intel_unpin_work may not take the list lock because it requires the > connector_mutex. > To prevent taking locks we add an array of old and new state. The old state > to free, > the new state to commit and verify. > >

Re: [Intel-gfx] [PATCH v2 11/21] drm/i915: Rework intel_crtc_page_flip to be almost atomic, v3.

On Tue, May 17, 2016 at 03:07:54PM +0200, Maarten Lankhorst wrote: > Create a work structure that will be used for all changes. This will > be used later on in the atomic commit function. > > Changes since v1: > - Free old_crtc_state from unpin_work_fn properly. > Changes since v2: > - Add hunk

Re: [Intel-gfx] [PATCH 2/7] drm/i915/psr: Try to program link training times correctly

On 5/18/2016 10:17 PM, Daniel Vetter wrote: Oops. Hw default for programming these fields to 0 is "skip link training". Display won't take that too well usually. But we were defaulting it to value 0, which means 500us for both TP1 and TP2 or TP3 time. I dont think it means skip link training.

[Intel-gfx] ✓ Ro.CI.BAT: success for drm/i915/fbdev: Limit the global async-domain synchronization (rev2)

== Series Details == Series: drm/i915/fbdev: Limit the global async-domain synchronization (rev2) URL : https://patchwork.freedesktop.org/series/7332/ State : success == Summary == Series 7332v2 drm/i915/fbdev: Limit the global async-domain synchronization

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Enable GSE interrupt on BDW+ (rev2)

== Series Details == Series: drm/i915: Enable GSE interrupt on BDW+ (rev2) URL : https://patchwork.freedesktop.org/series/1366/ State : failure == Summary == Series 1366v2 drm/i915: Enable GSE interrupt on BDW+ http://patchwork.freedesktop.org/api/1.0/series/1366/revisions/2/mbox Test

Re: [Intel-gfx] [PATCH v8 4/6] drm/i915: Interrupt driven fences

On Fri, May 13, 2016 at 10:19:11AM +0100, John Harrison wrote: > On 13/05/2016 08:27, Chris Wilson wrote: > >On Thu, May 12, 2016 at 10:06:34PM +0100, john.c.harri...@intel.com wrote: > >>+void i915_gem_request_notify(struct intel_engine_cs *engine, bool > >>fence_locked) > >>+{ > >>+ struct

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Enable edp psr error interrupts on hsw

On 5/18/2016 11:56 PM, Ville Syrjälä wrote: On Wed, May 18, 2016 at 06:47:10PM +0200, Daniel Vetter wrote: The definitions for the error register should be valid on bdw/skl too, but there we haven't even enabled DE_MISC handling yet. Somewhat confusing the the moved register offset on bdw is

Re: [Intel-gfx] [PATCH v8 4/6] drm/i915: Interrupt driven fences

Op 12-05-16 om 23:06 schreef john.c.harri...@intel.com: > From: John Harrison > > The intended usage model for struct fence is that the signalled status > should be set on demand rather than polled. That is, there should not > be a need for a 'signaled' function to be

Re: [Intel-gfx] [PATCH 02/21] drm/i915/skl: SKL CDCLK change on modeset tracking VCO

On Thu, May 19, 2016 at 12:08:42PM +0300, Imre Deak wrote: > On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > > From: Clint Taylor > > > > WARNING: Using ChromeOS with an eDP panel and a 4K@60 DP monitor connected > > to DDI1 the system will

[Intel-gfx] [PATCH v2] 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

Re: [Intel-gfx] [PATCH 02/21] drm/i915/skl: SKL CDCLK change on modeset tracking VCO

On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote: > From: Clint Taylor > > WARNING: Using ChromeOS with an eDP panel and a 4K@60 DP monitor connected > to DDI1 the system will hard hang during a cold boot. Occurs when DDI1 > is enabled when the

Re: [Intel-gfx] [PATCH] drm/i915/psr: Implement PSR2 w/a for gen9

Looks good to me. Reviewed-by: Sonika Jindal On 5/19/2016 12:44 PM, Daniel Vetter wrote: Found this while browsing Bspec. Looks like it applies to both skl and kbl. v2: Also for bxt (Art). Cc: Rodrigo Vivi Cc: Sonika Jindal

[Intel-gfx] [PATCH v2 1/5] drm/dp: Add drm_dp_psr_setup_time()

From: Ville Syrjälä Add a small helper to parse the PSR setup time from the DPCD PSR capabilities and return the value in microseconds. v2: Don't waste so many bytes on the psr_setup_time_us[] table Cc: Daniel Vetter Reviewed-by: Daniel

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/5] drm/i915: Convert RPS irq worker into a tasklet

== Series Details == Series: series starting with [1/5] drm/i915: Convert RPS irq worker into a tasklet URL : https://patchwork.freedesktop.org/series/7386/ State : failure == Summary == Series 7386v1 Series without cover letter

[Intel-gfx] [PATCH v2] drm/i915/fbdev: Limit the global async-domain synchronization

During cleanup we have to synchronise with the async task we are using to initialise and register our fbdev. Currently, we are using a full synchronisation on the global domain, but we can restrict this to just synchronising up to our task if we remember our cookie. v2: async_synchronize_cookie()

Re: [Intel-gfx] [PATCH v2 20/21] drm/i915: Check for unpin correctness.

On Tue, May 17, 2016 at 03:08:03PM +0200, Maarten Lankhorst wrote: > If planes are added to the state after the call to > drm_atomic_helper_check_planes planes_changed may not be set > and we will not unpin the old framebuffer. This results in a > pin leak long after the framebuffer is destroyed,

Re: [Intel-gfx] From work_struct to tasklet_struct

On Thu, May 19, 2016 at 08:48:29AM +0100, Chris Wilson wrote: > Just a small set to convert our irq bottom-halves to use a tasklet > instead of a work_struct. In theory, the tasklet has lower latency > from the interrupt (or lower upper bound at least), but in practice I > think it is clearer to

Re: [Intel-gfx] [PATCH] drm: Nuke ->vblank_disable_allowed

On Wed, May 18, 2016 at 10:29:57PM +0200, Daniel Vetter wrote: > This was added in > > commit 0a3e67a4caac273a3bfc4ced3da364830b1ab241 > Author: Jesse Barnes > Date: Tue Sep 30 12:14:26 2008 -0700 > > drm: Rework vblank-wait handling to allow interrupt reduction.

  1   2   >