Re: [Intel-gfx] [PATCH] drm/i915/edp: Read link status after exit PSR

-Original Message- From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] Sent: Thursday, April 27, 2017 10:39 PM To: Lee, Shawn C Cc: intel-gfx@lists.freedesktop.org; Chiou, Cooper ; Bride, Jim ; Nikula, Jani

Re: [Intel-gfx] [PATCH v7 4/4] drm/dp: Track MST link bandwidth

On Tue, 2017-04-25 at 09:51 +0200, Maarten Lankhorst wrote: > On 21-04-17 07:51, Dhinakaran Pandiyan wrote: > > From: "Pandiyan, Dhinakaran" > > > > Use the added helpers to track MST link bandwidth for atomic modesets. > > Link bw is acquired in the

Re: [Intel-gfx] [PATCH v7 12/20] drm/i915/guc: Provide register list to be saved/restored during engine reset

On Thu, Apr 27, 2017 at 04:12:52PM -0700, Michel Thierry wrote: > +#define WA_REG_WR_GUC_RESTORE(addr, val) do { \ > + const int r = guc_wa_add(dev_priv, (addr), (val)); \ > + if (r) \ > + return r; \ > + } while (0) Try to avoid burying returns

Re: [Intel-gfx] [PATCH v7 03/20] drm/i915: Add support for per engine reset recovery

On Thu, Apr 27, 2017 at 04:12:43PM -0700, Michel Thierry wrote: > From: Arun Siluvery > > This change implements support for per-engine reset as an initial, less > intrusive hang recovery option to be attempted before falling back to the > legacy full GPU reset

[Intel-gfx] ✓ Fi.CI.BAT: success for Gen8+ engine-reset (rev4)

== Series Details == Series: Gen8+ engine-reset (rev4) URL : https://patchwork.freedesktop.org/series/21868/ State : success == Summary == Series 21868v4 Gen8+ engine-reset https://patchwork.freedesktop.org/api/1.0/series/21868/revisions/4/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0

Re: [Intel-gfx] [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 27/04/17 05:20 PM, Jason Gunthorpe wrote: > It seems the most robust: test for iomem, and jump to a slow path > copy, otherwise inline the kmap and memcpy > > Every place doing memcpy from sgl will need that pattern to be > correct. Ok, sounds like a good place to start to me. I'll see what

[Intel-gfx] [PATCH v8 12/15] drm/i915/perf: Add OA unit support for Gen 8+

From: Robert Bragg Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all share (more-or-less) the same OA unit design. Of particular note in comparison to Haswell: some OA unit HW config state has become per-context state and as a consequence it is somewhat

[Intel-gfx] [PATCH v7 15/20] drm/i915: Watchdog timeout: Pass GuC shared data structure during param load

For watchdog / media reset, the firmware must know the address of the shared data page (the first page of the default context). This information should be in DWORD 9 of the GUC_CTL structure. v2: Use guc_ggtt_offset (Chris). Store the ggtt offset of the default ctx as we needed for

[Intel-gfx] [PATCH v7 18/20] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

Final enablement patch for GPU hang detection using watchdog timeout. Using the gem_context_setparam ioctl, users can specify the desired timeout value in microseconds, and the driver will do the conversion to 'timestamps'. The recommended default watchdog threshold for video engines is 6 us,

[Intel-gfx] [PATCH v7 08/20] drm/i915: Enable Engine reset and recovery support

From: Arun Siluvery This feature is made available only from Gen8, for previous gen devices driver uses legacy full gpu reset. Cc: Chris Wilson Cc: Mika Kuoppala Signed-off-by: Tomas Elf

[Intel-gfx] [PATCH v7 17/20] drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+

Emit the required commands into the ring buffer for starting and stopping the watchdog timer before/after batch buffer start during batch buffer submission. v2: Support watchdog threshold per context engine, merge lri commands, and move watchdog commands emission to emit_bb_start. Request space

[Intel-gfx] [PATCH v7 05/20] drm/i915: Cancel reset-engine if we couldn't find an active request

Before reseting an engine, check if there is an active request, and if the _hung_ request has completed. In these two cases, the seqno has moved after hang declaration and we can skip the reset. Also store the active request so that we only search for it once. Suggested-by: Chris Wilson

[Intel-gfx] [PATCH v7 01/20] drm/i915: Update i915.reset to handle engine resets

From: Arun Siluvery In preparation for engine reset work update this parameter to handle more than one type of reset. Default at the moment is still full gpu reset. Cc: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] [PATCH v7 10/20] drm/i915/selftests: reset engine self tests

Check that we can reset specific engines, also check the fallback to full reset if something didn't work. v2: rebase. Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 147 +++ 1 file changed, 147 insertions(+)

[Intel-gfx] [PATCH v7 11/20] drm/i915/guc: fix mmio whitelist mmio_start offset and add reminder

From: Daniele Ceraolo Spurio The mmio_start offset for the whitelist is the first FORCE_TO_NONPRIV register the GuC can use to restore the provided whitelist when an engine reset via GuC (which we still don't support) is triggered. We're currently adding the

[Intel-gfx] [PATCH v7 20/20] drm/i915: Watchdog timeout: Export media reset count from GuC to debugfs

From firmware v8.8, GuC provides the count of media engine resets (watchdog timeout). This information is available in the GuC shared context data struct, which resides in the first page of the default (kernel) lrc context. Since GuC handled engine resets are transparent for kernel and user,

[Intel-gfx] [PATCH v7 06/20] drm/i915: Add engine reset count to error state

From: Arun Siluvery Driver maintains count of how many times a given engine is reset, useful to capture this in error state also. It gives an idea of how engine is coping up with the workloads it is executing before this error state. A follow-up patch will provide

[Intel-gfx] [PATCH v7 16/20] drm/i915: Watchdog timeout: IRQ handler for gen8+

*** General *** Watchdog timeout (or "media engine reset") is a feature that allows userland applications to enable hang detection on individual batch buffers. The detection mechanism itself is mostly bound to the hardware and the only thing that the driver needs to do to support this form of

[Intel-gfx] [PATCH v7 03/20] drm/i915: Add support for per engine reset recovery

From: Arun Siluvery This change implements support for per-engine reset as an initial, less intrusive hang recovery option to be attempted before falling back to the legacy full GPU reset recovery mode if necessary. This is only supported from Gen8 onwards.

[Intel-gfx] [PATCH v7 14/20] drm/i915/guc: Add support for reset engine using GuC commands

This patch adds per engine reset and recovery (TDR) support when GuC is used to submit workloads to GPU. In the case of i915 directly submission to ELSP, driver manages hang detection, recovery and resubmission. With GuC submission these tasks are shared between driver and GuC. i915 is still

[Intel-gfx] [PATCH v7 19/20] drm/i915: Watchdog timeout: Include threshold value in error state

Save the watchdog threshold (in us) as part of the engine state. Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gpu_error.c | 11 +++ 2 files changed, 8 insertions(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH v7 13/20] drm/i915/guc: Rename the function that resets the GuC

intel_guc_reset sounds more like the microcontroller is the one performing a reset, while in this case is the opposite. intel_reset_guc not only makes it clearer, it follows the other intel_reset functions available. Cc: Tvrtko Ursulin Signed-off-by: Michel

[Intel-gfx] [PATCH v7 02/20] drm/i915: Modify error handler for per engine hang recovery

From: Arun Siluvery This is a preparatory patch which modifies error handler to do per engine hang recovery. The actual patch which implements this sequence follows later in the series. The aim is to prepare existing recovery function to adapt to this new function

[Intel-gfx] [PATCH v7 07/20] drm/i915: Export per-engine reset count info to debugfs

From: Arun Siluvery A new variable is added to export the reset counts to debugfs, this includes full gpu reset and engine reset count. This is useful for tests where they are expected to trigger reset; these counts are checked before and after the test to ensure

[Intel-gfx] [PATCH v7 12/20] drm/i915/guc: Provide register list to be saved/restored during engine reset

From: Arun Siluvery GuC expects a list of registers from the driver which are saved/restored during engine reset. The type of value to be saved is controlled by flags. We provide a minimal set of registers that we want GuC to save and restore. This is not an issue

[Intel-gfx] [PATCH v7 04/20] drm/i915: Skip reset request if there is one already

From: Mika Kuoppala To perform engine reset we first disable engine to capture its state. This is done by issuing a reset request. Because we are reusing existing infrastructure, again when we actually reset an engine, reset function checks engine mask and issues

[Intel-gfx] [PATCH v7 00/20] Gen8+ engine-reset

These patches add the reset-engine feature from Gen8. This is also referred to as Timeout detection and recovery (TDR). This complements to the full gpu reset feature available in i915 but it only allows to reset a particular engine instead of all engines thus providing a light weight engine reset

[Intel-gfx] [PATCH v7 09/20] drm/i915: Add engine reset count in get-reset-stats ioctl

Users/tests relying on the total reset count will start seeing a smaller number since most of the hangs can be handled by engine reset. Note that if reset engine x, context a running on engine y will be unaware and unaffected. To start the discussion, include just a total engine reset count. If

Re: [Intel-gfx] [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 27/04/17 04:11 PM, Jason Gunthorpe wrote: > On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote: > Well, that is in the current form, with more users it would make sense > to optimize for the single page case, eg by providing the existing > call, providing a faster

Re: [Intel-gfx] [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 27/04/17 02:53 PM, Jason Gunthorpe wrote: > blkfront is one of the drivers I looked at, and it appears to only be > memcpying with the bvec_data pointer, so I wonder why it does not use > sg_copy_X_buffer instead.. Yes, sort of... But you'd potentially end up calling sg_copy_to_buffer

Re: [Intel-gfx] [PATCH v9] drm/i915: Squash repeated awaits on the same fence

On Thu, Apr 27, 2017 at 09:34:10PM +0100, Chris Wilson wrote: > On Thu, Apr 27, 2017 at 06:25:47PM +0100, Chris Wilson wrote: > > On Thu, Apr 27, 2017 at 05:47:32PM +0100, Tvrtko Ursulin wrote: > > > >+int intel_timeline_sync_set(struct intel_timeline *tl, u64 id, u32 > > > >seqno) > > > >+{ > >

Re: [Intel-gfx] [PATCH v9] drm/i915: Squash repeated awaits on the same fence

On Thu, Apr 27, 2017 at 06:25:47PM +0100, Chris Wilson wrote: > On Thu, Apr 27, 2017 at 05:47:32PM +0100, Tvrtko Ursulin wrote: > > >+int intel_timeline_sync_set(struct intel_timeline *tl, u64 id, u32 seqno) > > >+{ > > >+ struct intel_timeline_sync *p = tl->sync; > > >+ > > >+ /* We expect to

Re: [Intel-gfx] [PATCH v2 15/21] xen-blkfront: Make use of the new sg_map helper function

On 26/04/17 01:37 AM, Roger Pau Monné wrote: > On Tue, Apr 25, 2017 at 12:21:02PM -0600, Logan Gunthorpe wrote: >> Straightforward conversion to the new helper, except due to the lack >> of error path, we have to use SG_MAP_MUST_NOT_FAIL which may BUG_ON in >> certain cases in the future. >> >>

Re: [Intel-gfx] [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On 26/04/17 01:44 AM, Christoph Hellwig wrote: > I think we'll at least need a draft of those to make sense of these > patches. Otherwise they just look very clumsy. Ok, what follows is a draft patch attempting to show where I'm thinking of going with this. Obviously it will not compile because

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Fix sleep under spinlock during reset

On 27/04/17 11:20, Tvrtko Ursulin wrote: On 27/04/2017 19:14, Michel Thierry wrote: On 12/04/17 09:22, Michel Thierry wrote: On 12/04/17 08:58, Chris Wilson wrote: On Wed, Apr 12, 2017 at 04:48:42PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Looks like

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Fix sleep under spinlock during reset

On 27/04/2017 19:14, Michel Thierry wrote: On 12/04/17 09:22, Michel Thierry wrote: On 12/04/17 08:58, Chris Wilson wrote: On Wed, Apr 12, 2017 at 04:48:42PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Looks like intel_guc_reset had the ability to sleep

Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Fix sleep under spinlock during reset

On 12/04/17 09:22, Michel Thierry wrote: On 12/04/17 08:58, Chris Wilson wrote: On Wed, Apr 12, 2017 at 04:48:42PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Looks like intel_guc_reset had the ability to sleep under the uncore spinlock since forever but it

Re: [Intel-gfx] [PATCH v9] drm/i915: Squash repeated awaits on the same fence

On Thu, Apr 27, 2017 at 05:47:32PM +0100, Tvrtko Ursulin wrote: > > On 27/04/2017 12:48, Chris Wilson wrote: > >diff --git a/drivers/gpu/drm/i915/i915_gem_request.c > >b/drivers/gpu/drm/i915/i915_gem_request.c > >index 5fa4e52ded06..d9f76665bc6b 100644 > >---

Re: [Intel-gfx] [PATCH v9] drm/i915: Squash repeated awaits on the same fence

On 27/04/2017 12:48, Chris Wilson wrote: Track the latest fence waited upon on each context, and only add a new asynchronous wait if the new fence is more recent than the recorded fence for that context. This requires us to filter out unordered timelines, which are noted by

Re: [Intel-gfx] [PATCH 1/2] drm: Make fbdev inherit the crtc's initial rotation

On Thu, 2017-04-27 at 19:24 +0300, Ville Syrjälä wrote: > On Wed, Apr 26, 2017 at 02:28:32PM +0200, Bastien Nocera wrote: > > On Mon, 2017-04-24 at 15:48 +0300, Ville Syrjälä wrote: > > > > > > > > > > > > > I've a patch for iio-sensor-proxy which fixes the rotation > > > > under > > > > Xorg

Re: [Intel-gfx] [PATCH 1/2] drm: Make fbdev inherit the crtc's initial rotation

On Wed, Apr 26, 2017 at 02:28:32PM +0200, Bastien Nocera wrote: > On Mon, 2017-04-24 at 15:48 +0300, Ville Syrjälä wrote: > > > > > > > I've a patch for iio-sensor-proxy which fixes the rotation under > > > Xorg / > > > Wayland when using a desktop environment which honors iio-sensor- > > >

Re: [Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9

On Thu, Apr 27, 2017 at 06:30:42PM +0300, David Weinehall wrote: > On Thu, Apr 27, 2017 at 04:55:20PM +0200, Arkadiusz Hiler wrote: > > On Wed, Apr 26, 2017 at 06:00:41PM +0300, David Weinehall wrote: > > > Add a bunch of MOCS entries for gen 9 that were missing from intel_mocs. > > > Some of

[Intel-gfx] ✓ Fi.CI.BAT: success for conf: Add multiple hdmi pcm definition for Intel LPE audio

== Series Details == Series: conf: Add multiple hdmi pcm definition for Intel LPE audio URL : https://patchwork.freedesktop.org/series/23639/ State : success == Summary == Series 23639v1 conf: Add multiple hdmi pcm definition for Intel LPE audio

[Intel-gfx] [PATCH v2 08/11] drm/i915: Clean up the LPE audio platform data

From: Ville Syrjälä Split the LPE audio platform data into a port specific chunk and device specific chunk. Eventually we'll have a port specific chunk for each port, but for now we'll stick to just one. We'll also get rid of the intel_hdmi_lpe_audio_eld structure

[Intel-gfx] [PATCH 03/11] drm/i915: Stop pretending to mask/unmask LPE audio interrupts

From: Ville Syrjälä vlv_display_irq_postinstall() enables the LPE audio interrupts regardless of whether the LPE audio irq chip has masked/unmasked them. Also the irqchip masking/unmasking doesn't consider the state of the display power well or the device, and

[Intel-gfx] [PATCH v2 11/11] ALSA: x86: Register multiple PCM devices for the LPE audio card

From: Ville Syrjälä Now that everything is in place let's register a PCM device for each port of the display engine. This will make it possible to actually output audio to multiple displays at the same time. And it avoids modesets on unrelated displays from

[Intel-gfx] [PATCH alsa-lib] conf: Add multiple hdmi pcm definition for Intel LPE audio

From: Ville Syrjälä Now that the kernel driver exposes several pcm devices, update the hdmi pcm definitions to match. Cc: Takashi Iwai Cc: Pierre-Louis Bossart Signed-off-by: Ville Syrjälä

[Intel-gfx] [PATCH v2 10/11] ALSA: x86: Split snd_intelhad into card and PCM specific structures

From: Ville Syrjälä To allow multiple PCM devices to be registered for the LPE audio card, split the private data into card and PCM specific chunks. For now we'll stick to just one PCM device as before. v2: Rework to do a pcm device per port instead of per pipe

[Intel-gfx] [PATCH 07/11] drm/i915: Reorganize intel_lpe_audio_notify() arguments

From: Ville Syrjälä Shuffle the arguments to intel_lpe_audio_notify() around a bit. Pipe and port being the most important things, so let's put the first, and thre rest can come in as is. Also constify the eld argument. Cc: Takashi Iwai Cc:

[Intel-gfx] [PATCH 09/11] ALSA: x86: Prepare LPE audio ctls for multiple PCMs

From: Ville Syrjälä In preparation for register a PCM device for each pipe adjust link up the ctl elements with the corresponding PCM device. Cc: Takashi Iwai Cc: Pierre-Louis Bossart Signed-off-by: Ville

[Intel-gfx] [PATCH 05/11] drm/i915: Replace tmds_clock_speed and link_rate with just ls_clock

From: Ville Syrjälä There's no need to distinguish between the DP link rate and HDMI TMDS clock for the purposes of the LPE audio. Both are actually the same thing more or less, which is the link symbol clock. So let's just call the thing ls_clock and simplify the

[Intel-gfx] [PATCH v2 06/11] drm/i915: Remove hdmi_connected from LPE audio pdata

From: Ville Syrjälä We can determine that the pipe was shut down from pipe<0, so there's no point in duplicating that information as 'hdmi_connected'. v2: Use pipe<0 instead of port<0 as we'll want to do per-port PCM devices later Initialize pipe to -1 to

[Intel-gfx] [PATCH v2 00/11] drm/i915: LPE audio runtime PM and multipipe (v2)

From: Ville Syrjälä Okay, here's the second attempt at getting multiple pipes playing back audio on the VLV/CHV HDMI LPE audio device. The main change from v1 is that now the PCM devices are associated with ports instead of pipes, so the audio from one device

[Intel-gfx] [PATCH v2 04/11] drm/i915: Remove the unused pending_notify from LPE platform data

From: Ville Syrjälä The pending_notify flag in the LPE audio platform data is pointless, actually unused. So let's kill it off. v2: Fix typo in patch subject Cc: Takashi Iwai Cc: Pierre-Louis Bossart

[Intel-gfx] [PATCH 01/11] drm/i915: Fix runtime PM for LPE audio

From: Ville Syrjälä Not calling pm_runtime_enable() means that runtime PM can't be enabled at all via sysfs. So we definitely need to call it from somewhere. Calling it from the driver seems like a bad idea because it would have to be paired with a

[Intel-gfx] [PATCH 02/11] ALSA: x86: Clear the pdata.notify_lpe_audio pointer before teardown

From: Ville Syrjälä Clear the notify function pointer in the platform data before we tear down the driver. Otherwise i915 would end up calling a stale function pointer and possibly explode. Cc: Takashi Iwai Cc: Pierre-Louis Bossart

Re: [Intel-gfx] [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On 27/04/17 09:27 AM, Jason Gunthorpe wrote: > On Thu, Apr 27, 2017 at 08:53:38AM +0200, Christoph Hellwig wrote: > How about first switching as many call sites as possible to use > sg_copy_X_buffer instead of kmap? Yeah, I could look at doing that first. One problem is we might get more Naks

Re: [Intel-gfx] [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On 26/04/17 09:56 PM, Herbert Xu wrote: > On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote: >> Very straightforward conversion to the new function in the caam driver >> and shash library. >> >> Signed-off-by: Logan Gunthorpe >> Cc: Herbert Xu

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Eliminate HAS_HW_CONTEXTS

On Thu, Apr 27, 2017 at 04:32:55PM +0100, Chris Wilson wrote: > On Thu, Apr 27, 2017 at 05:36:55PM +0300, Ville Syrjälä wrote: > > On Thu, Apr 27, 2017 at 04:41:33PM +0300, Joonas Lahtinen wrote: > > > According to Chris i915_gem_sanitize was meant to reset ILK too. > > > > In that case drawing

Re: [Intel-gfx] [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

On 27/04/17 12:53 AM, Christoph Hellwig wrote: > I think you'll need to follow the existing kmap semantics and never > fail the iomem version either. Otherwise you'll have a special case > that's almost never used that has a different error path. > > Again, wrong way. Suddenly making things

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Eliminate HAS_HW_CONTEXTS

On Thu, Apr 27, 2017 at 05:36:55PM +0300, Ville Syrjälä wrote: > On Thu, Apr 27, 2017 at 04:41:33PM +0300, Joonas Lahtinen wrote: > > According to Chris i915_gem_sanitize was meant to reset ILK too. > > In that case drawing the line before g4x might make more sense > since it already has a GPU

Re: [Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9

On Thu, Apr 27, 2017 at 04:55:20PM +0200, Arkadiusz Hiler wrote: > On Wed, Apr 26, 2017 at 06:00:41PM +0300, David Weinehall wrote: > > Add a bunch of MOCS entries for gen 9 that were missing from intel_mocs. > > Some of these are used by media-sdk; if these entries are missing > > the default

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

== Series Details == Series: series starting with [1/2] drm/i915: Mark CPU cache as dirty on every transition for CPU writes URL : https://patchwork.freedesktop.org/series/23634/ State : success == Summary == Series 23634v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9

On Wed, Apr 26, 2017 at 06:00:41PM +0300, David Weinehall wrote: > Add a bunch of MOCS entries for gen 9 that were missing from intel_mocs. > Some of these are used by media-sdk; if these entries are missing > the default will instead be to do everything uncached. > > This patch improves

[Intel-gfx] [PATCH 2/2] drm/i915: Store i915_gem_object_is_coherent() as a bit next to cache-dirty

For ease of use (i.e. avoiding a few checks and function calls), store the object's cache coherency next to the cache is dirty bit. Signed-off-by: Chris Wilson Cc: Dongwon Kim Cc: Matt Roper ---

[Intel-gfx] [PATCH 1/2] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

Currently, we only mark the CPU cache as dirty if we skip a clflush. This leads to some confusion where we have to ask if the object is in the write domain or missed a clflush. If we always mark the cache as dirty, this becomes a much simply question to answer. The goal remains to do as few

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/edp: Read link status after exit PSR

== Series Details == Series: drm/i915/edp: Read link status after exit PSR URL : https://patchwork.freedesktop.org/series/23631/ State : success == Summary == Series 23631v1 drm/i915/edp: Read link status after exit PSR https://patchwork.freedesktop.org/api/1.0/series/23631/revisions/1/mbox/

Re: [Intel-gfx] [PATCH] drm/i915/edp: Read link status after exit PSR

On Thu, Apr 27, 2017 at 10:35:22PM +0800, Lee, Shawn C wrote: > From: "Lee, Shawn C" > > Display driver read DPCD register 0x202, 0x203 and 0x204 to identify > eDP sink status. If PSR exit is ongoing at eDP sink, and eDP source > read these registers at the same time.

Re: [Intel-gfx] [PATCH 13/27] drm/i915/execlists: Pack the count into the low bits of the port.request

On Thu, Apr 20, 2017 at 03:58:19PM +0100, Tvrtko Ursulin wrote: > > static void record_context(struct drm_i915_error_context *e, > >diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c > >b/drivers/gpu/drm/i915/i915_guc_submission.c > >index 1642fff9cf13..370373c97b81 100644 > >---

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Eliminate HAS_HW_CONTEXTS

On Thu, Apr 27, 2017 at 04:41:33PM +0300, Joonas Lahtinen wrote: > According to Chris i915_gem_sanitize was meant to reset ILK too. In that case drawing the line before g4x might make more sense since it already has a GPU reset that doesn't clobber the display. > > CCID register existed already

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Eliminate HAS_HW_CONTEXTS

On Thu, Apr 27, 2017 at 04:41:33PM +0300, Joonas Lahtinen wrote: > According to Chris i915_gem_sanitize was meant to reset ILK too. > > CCID register existed already on ILK according to the PRM (Chris > verified the address to match too). > > HAS_HW_CONTEXTS in i915_l3_write is bogus because

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Sanitize engine context sizes

== Series Details == Series: series starting with [1/2] drm/i915: Sanitize engine context sizes URL : https://patchwork.freedesktop.org/series/23630/ State : failure == Summary == Series 23630v1 Series without cover letter

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Prevent the system suspend complete optimization

Thanks, Imre I have tested this and I confirm that it solves the pm_runtime_get_sync() failed: -13 and the issues that follow after. This is also the root-cause in freedesktop bug 100770, which will be solved by your patch. BR, Marta > -Original Message- > From: Deak, Imre > Sent:

Re: [Intel-gfx] [PATCH] drm/i915/edp: Read link status after exit PSR

On Thu, Apr 27, 2017 at 10:35:22PM +0800, Lee, Shawn C wrote: > From: "Lee, Shawn C" > > Display driver read DPCD register 0x202, 0x203 and 0x204 to identify > eDP sink status. If PSR exit is ongoing at eDP sink, and eDP source > read these registers at the same time.

[Intel-gfx] [PATCH] drm/i915/edp: Read link status after exit PSR

From: "Lee, Shawn C" Display driver read DPCD register 0x202, 0x203 and 0x204 to identify eDP sink status. If PSR exit is ongoing at eDP sink, and eDP source read these registers at the same time. Panel will report EQ & symbol lock not done. It will cause panel display

[Intel-gfx] [PATCH 2/2] drm/i915: Eliminate HAS_HW_CONTEXTS

According to Chris i915_gem_sanitize was meant to reset ILK too. CCID register existed already on ILK according to the PRM (Chris verified the address to match too). HAS_HW_CONTEXTS in i915_l3_write is bogus because each HAS_L3_DPF match also has .has_hw_contexts = 1 set. This leads to us being

[Intel-gfx] [PATCH 1/2] drm/i915: Sanitize engine context sizes

Pre-calculate engine context size based on engine class and device generation and store it in the engine instance. v2: - Squash and get rid of hw_context_size (Chris) v3: - Move after MMIO init for probing on Gen7 and 8 (Chris) - Retained rounding (Tvrtko) v4: - Rebase for deferred legacy

[Intel-gfx] [PULL] drm-intel-next-fixes for v4.12

Hi Dave, here's an assortment of drm/i915 and gvt fixes for drm-next/v4.12. BR, Jani. The following changes since commit ab6eb211b07a42a6346e284056422fd9a8576a99: Merge tag 'drm/panel/for-4.12-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next (2017-04-13 06:17:40 +1000) are

[Intel-gfx] [PATCH i-g-t] tests/kms_atomic_abi: Test event ABI corner cases

Atomic has a few special cases around async commits and event generation that we need to test. This patch addresses these two tests - kernel rejects events on a disabled pipe - events on a pipe that is getting enabled/disabled For: VIZ-6954 Signed-off-by: Mika Kahola ---

Re: [Intel-gfx] [PATCH 0/7] Add Y-tiling support into IGTs

Hi Paulo, Thanks for your review. On Wednesday 26 April 2017 08:21 PM, Paulo Zanoni wrote: Em Qua, 2017-04-26 às 10:46 -0300, Paulo Zanoni escreveu: Em Sáb, 2017-03-18 às 00:45 +0530, Praveen Paneri escreveu: This series adds Y-tiled buffer creation support into IGT libraries and goes on to

[Intel-gfx] [PATCH v4 5/8] drm/i915: Check error return when converting pipe to connector

An error from intel_get_pipe_from_connector() would mean a bug somewhere else, but we still should check for it to prevent some other more obscure bug later. v2: - Fall back to a reasonable default instead of bailing out in case of error. (Jani) v3: - Fix s/PIPE_INVALID/INVALID_PIPE/ typo.

Re: [Intel-gfx] [PATCH v3 5/8] drm/i915: Check error return when converting pipe to connector

On Thu, 27 Apr 2017, Imre Deak wrote: > On Thu, Apr 27, 2017 at 02:49:55PM +0300, Ville Syrjälä wrote: >> On Thu, Apr 27, 2017 at 11:36:54AM +0300, Imre Deak wrote: >> > An error from intel_get_pipe_from_connector() would mean a bug somewhere >> > else, but we still should

Re: [Intel-gfx] [PATCH v3 5/8] drm/i915: Check error return when converting pipe to connector

On Thu, Apr 27, 2017 at 02:49:55PM +0300, Ville Syrjälä wrote: > On Thu, Apr 27, 2017 at 11:36:54AM +0300, Imre Deak wrote: > > An error from intel_get_pipe_from_connector() would mean a bug somewhere > > else, but we still should check for it to prevent some other more > > obscure bug later. > >

Re: [Intel-gfx] [PATCH v3 5/8] drm/i915: Check error return when converting pipe to connector

On Thu, Apr 27, 2017 at 11:36:54AM +0300, Imre Deak wrote: > An error from intel_get_pipe_from_connector() would mean a bug somewhere > else, but we still should check for it to prevent some other more > obscure bug later. > > v2: > - Fall back to a reasonable default instead of bailing out in

[Intel-gfx] [PATCH v9] drm/i915: Squash repeated awaits on the same fence

Track the latest fence waited upon on each context, and only add a new asynchronous wait if the new fence is more recent than the recorded fence for that context. This requires us to filter out unordered timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the absence of a universal

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Defer context state allocation for legacy ring submission (rev2)

On Thu, Apr 27, 2017 at 11:06:18AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Defer context state allocation for legacy ring submission > (rev2) > URL : https://patchwork.freedesktop.org/series/23619/ > State : success > > == Summary == > > Series 23619v2 drm/i915:

Re: [Intel-gfx] [PATCH v8] drm/i915: Squash repeated awaits on the same fence

On Thu, Apr 27, 2017 at 10:50:28AM +0100, Chris Wilson wrote: > On Thu, Apr 27, 2017 at 08:06:36AM +0100, Chris Wilson wrote: > > +int i915_gem_timeline_mock_selftests(void) > > +{ > > + static const struct i915_subtest tests[] = { > > + SUBTEST(igt_seqmap), > > I should add a few

Re: [Intel-gfx] [PATCH v2 4/8] drm/i915: Check error return when setting DMA mask

On Wed, 26 Apr 2017, Imre Deak wrote: > Even though an error from these functions isn't fatal we still want to > have a diagnostic message about it. > > v2: > - Don't do assignments in if statements. (Jani) > > Cc: Jani Nikula > Signed-off-by: Imre

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Defer context state allocation for legacy ring submission (rev2)

== Series Details == Series: drm/i915: Defer context state allocation for legacy ring submission (rev2) URL : https://patchwork.freedesktop.org/series/23619/ State : success == Summary == Series 23619v2 drm/i915: Defer context state allocation for legacy ring submission

Re: [Intel-gfx] [PATCH v2] drm/i915: Defer context state allocation for legacy ring submission

On to, 2017-04-27 at 11:46 +0100, Chris Wilson wrote: > Almost from the outset for execlists, we used deferred allocation of the > logical context and rings. Then we ported the infrastructure for pinning > contexts back to legacy, and so now we are able to also implement > deferred allocation for

[Intel-gfx] [PATCH v2] drm/i915: Defer context state allocation for legacy ring submission

Almost from the outset for execlists, we used deferred allocation of the logical context and rings. Then we ported the infrastructure for pinning contexts back to legacy, and so now we are able to also implement deferred allocation for context objects prior to first use on the legacy submission.

[Intel-gfx] [PATCH] drm/i915: Defer context state allocation for legacy ring submission

Almost from the outset for execlists, we used deferred allocation of the logical context and rings. Then we ported the infrastructure for pinning contexts back to legacy, and so now we are able to also implement deferred allocation for context objects prior to first use on the legacy submission.

Re: [Intel-gfx] [RFC v2 2/2] drm/i915: Select engines via class and instance in execbuffer2

On Thu, Apr 27, 2017 at 11:09:35AM +0100, Tvrtko Ursulin wrote: > > On 27/04/2017 10:25, Chris Wilson wrote: > >On Thu, Apr 27, 2017 at 10:10:34AM +0100, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>Building on top of the previous patch which exported the

Re: [Intel-gfx] [PATCH v3] drm/i915: Sanitize engine context sizes

On Thu, Apr 27, 2017 at 12:01:11PM +0300, Joonas Lahtinen wrote: > @@ -266,11 +239,12 @@ __create_hw_context(struct drm_i915_private *dev_priv, > list_add_tail(>link, _priv->context_list); > ctx->i915 = dev_priv; > > - if (dev_priv->hw_context_size) { > + if

[Intel-gfx] ✓ Fi.CI.BAT: success for New engine discovery and execbuffer2 engine selection uAPI (rev3)

== Series Details == Series: New engine discovery and execbuffer2 engine selection uAPI (rev3) URL : https://patchwork.freedesktop.org/series/23189/ State : success == Summary == Series 23189v3 New engine discovery and execbuffer2 engine selection uAPI

Re: [Intel-gfx] [RFC v2 2/2] drm/i915: Select engines via class and instance in execbuffer2

On 27/04/2017 10:25, Chris Wilson wrote: On Thu, Apr 27, 2017 at 10:10:34AM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Building on top of the previous patch which exported the concept of engine classes and instances, we can also use this instead of the

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Sanitize engine context sizes (rev2)

== Series Details == Series: drm/i915: Sanitize engine context sizes (rev2) URL : https://patchwork.freedesktop.org/series/23567/ State : failure == Summary == Series 23567v2 drm/i915: Sanitize engine context sizes https://patchwork.freedesktop.org/api/1.0/series/23567/revisions/2/mbox/ Test

Re: [Intel-gfx] [PATCH 0/2] GuC logger redesign

On Thu, Apr 27, 2017 at 09:22:11AM +, Olinski, Krzysztof E wrote: > On Thu, 2017-04-27 at 10:05 +0100, Chris Wilson wrote: > > On Thu, Apr 27, 2017 at 10:59:18AM +0200, Krzysztof E. Olinski wrote: > > > GuC logger implementation simplified and moved to a library > > > (GuCLAW). > > > Adds

Re: [Intel-gfx] [PATCH v8] drm/i915: Squash repeated awaits on the same fence

On Thu, Apr 27, 2017 at 08:06:36AM +0100, Chris Wilson wrote: > +int i915_gem_timeline_mock_selftests(void) > +{ > + static const struct i915_subtest tests[] = { > + SUBTEST(igt_seqmap), I should add a few benchmarks here as well. random insertion random lookup (uses same random

Re: [Intel-gfx] [PATCH 07/27] drm/i915: Squash repeated awaits on the same fence

On Thu, Apr 27, 2017 at 10:20:36AM +0100, Tvrtko Ursulin wrote: > > On 26/04/2017 23:22, Chris Wilson wrote: > >On Wed, Apr 26, 2017 at 07:56:14PM +0100, Chris Wilson wrote: > >>On Wed, Apr 26, 2017 at 01:13:41PM +0100, Tvrtko Ursulin wrote: > >>>I was thinking of exactly the same thing as this

  1   2   >