[Intel-gfx] [PATCH v2] drm/i915: Discard previous atomic state on resume if connectors change

If an MST device is disconnected while the machine is suspended, the number of connectors will change as well after we call intel_dp_mst_resume(). This means that any previous atomic state we had before suspending is no longer valid, since it'll still be pointing to missing connectors. We need to

Re: [Intel-gfx] [PATCH] drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms

On Fri, May 06, 2016 at 09:35:55PM +0300, ville.syrj...@linux.intel.com wrote: > @@ -730,9 +730,14 @@ int i915_suspend_switcheroo(struct drm_device *dev, > pm_message_t state) > static int i915_drm_resume(struct drm_device *dev) > { > struct drm_i915_private *dev_priv = dev->dev_private;

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dmabuf: Pin pages as we flush for CPU access

On Fri, May 06, 2016 at 08:35:17PM +0100, Dave Gordon wrote: > On 06/05/16 15:36, Chris Wilson wrote: > >As a precautionary defensive measure against changes to the core (where > >we stop changing domains when unbinding), we want to ensure that the pages > >are available when we want to start CPU

[Intel-gfx] [PATCH v4] prime_mmap_kms: show case dma-buf new API and processes restrictions

dma-buf new API consists of: - mmap(dma_buf_fd, ...): the ability to map a dma-buf file-descriptor of a graphics buffer to the userspace, and more importantly, to actually write on the mapped pointer (which was not possible before). It’s worth noting that the Direct Rendering Manager (DRM) and

Re: [Intel-gfx] [PATCH 2/2] drm/i915/dmabuf: Pin pages as we flush for CPU access

On 06/05/16 15:36, Chris Wilson wrote: As a precautionary defensive measure against changes to the core (where we stop changing domains when unbinding), we want to ensure that the pages are available when we want to start CPU access, otherwise we will not perform the requisite clflushes to make

[Intel-gfx] [PATCH v3 5/6] drm/i915/guc: rework guc_add_workqueue_item()

Mostly little optimisations and future-proofing against code breakage. For instance, if the driver is correctly following the submission protocol, the "out of space" condition is impossible, so the previous runtime WARN_ON() is promoted to a GEM_BUG_ON() for a more dramatic effect in development

[Intel-gfx] [PATCH v3 6/6] drm/i915/guc: change default to using GuC submission if possible

This patch simply changes the default value of "enable_guc_submission" from 0 (never) to -1 (auto). This means that GuC submission will be used if the platform has a GuC, the GuC supports the request submission protocol, and any required GuC firmwware was successfully loaded. If any of these

[Intel-gfx] [PATCH v3 4/6] drm/i915/guc: don't spinwait if the GuC's workqueue is full

Rather than wait to see whether more space becomes available in the GuC submission workqueue, we can just return -EAGAIN and let the caller try again in a little while. This gets rid of an uninterruptable sleep in the polling code :) We'll also add a counter to the GuC client statistics, to see

[Intel-gfx] [PATCH v3 1/6] drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED

For now, anything with a GuC requires uCode loading, and then supports command submission once loaded. But these are logically distinct from simply "having a GuC", so we need a separate macro for the latter. Then, the test in intel_guc_reset() should depend only on whether the GuC exists, not

[Intel-gfx] [PATCH v3 3/6] drm/i915/guc: pass request (not client) to i915_guc_{wq_check_space, submit}()

The knowledge of how to derive the relevant client from the request should be localised within i915_guc_submission.c; the LRC code shouldn't have to know about the internal details of the GuC submission process. And all the information the GuC code needs should be encapsulated in (or reachable

[Intel-gfx] [PATCH v3 2/6] drm/i915/guc: add enable_guc_loading parameter

Split the function of "enable_guc_submission" into two separate options. The new one ("enable_guc_loading") controls only the *fetching and loading* of the GuC firmware image. The existing one is redefined to control only the *use* of the GuC for batch submission once the firmware is loaded. In

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Do not use a bitfield for INTEL_INFO->num_pipes

On 06/05/16 15:16, Tvrtko Ursulin wrote: From: Tvrtko Ursulin It just makes more work for the compiler and generates more code. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.h | 2 +- 1 file changed, 1 insertion(+), 1

Re: [Intel-gfx] i915 with valleyview

On Fri, May 06, 2016 at 12:21:04PM +0100, Sudip Mukherjee wrote: > Hi Daniel, > I am trying to use i915 in one of our board which has Intel ATOM E3840. > I know Intel has released emgd driver for this cpu to use i915 but emgd > is not supported on v4.5 (or v4.6). The board is having SFI (simple >

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Introduce INTEL_GEN_RANGE macro

On 06/05/16 15:33, Chris Wilson wrote: On Fri, May 06, 2016 at 03:16:25PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin To be used for more efficient Gen range checking. Signed-off-by: Tvrtko Ursulin ---

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

On Fri, 2016-05-06 at 14:12 -0400, Lyude Paul wrote: > On Thu, 2016-04-21 at 16:17 -0700, Matt Roper wrote: > > > > Now that we're properly pre-allocating the DDB during the atomic check > > phase and we trust that the allocation is appropriate, let's actually > > use the allocation computed and

[Intel-gfx] [PATCH] drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms

From: Ville Syrjälä Move the intel_enable_gtt() call to happen before we touch the GTT during resume. Right now it's done way too late. Before commit ebb7c78d358b ("agp/intel-gtt: Only register fake agp driver for gen1") it was actually done earlier on account of

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

On Thu, 2016-04-21 at 16:17 -0700, Matt Roper wrote: > Now that we're properly pre-allocating the DDB during the atomic check > phase and we trust that the allocation is appropriate, let's actually > use the allocation computed and not duplicate that work during the > commit phase. > > v2: >  -

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/guc: don't spinwait if the GuC's workqueue is full

On 29/04/16 16:17, Tvrtko Ursulin wrote: On 27/04/16 19:03, Dave Gordon wrote: Rather than wait to see whether more space becomes available in the GuC submission workqueue, we can just return -EAGAIN and let the caller try again in a little while. This gets rid of an uninterruptable sleep in

Re: [Intel-gfx] [PATCH v2 1/5] drm/i915/guc: add enable_guc_loading parameter

On 29/04/16 16:03, Tvrtko Ursulin wrote: Hi, On 27/04/16 19:03, Dave Gordon wrote: Split the function of "enable_guc_submission" into two separate options. The new one ("enable_guc_loading") controls only the *fetching and loading* of the GuC firmware image. The existing one is redefined to

Re: [Intel-gfx] [PATCH 0/5] IS_GENx and related code shrinkage

On Fri, May 06, 2016 at 04:20:46PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Our huge amount of "what hardware I am" checks during runtime is somewhat > distasteful but to deeply ingrained to be easily fixable. > > Instead we can make them more efficient

[Intel-gfx] [PATCH 5/5] drm/i915: Do not use a bitfield for INTEL_INFO->num_pipes

From: Tvrtko Ursulin It just makes more work for the compiler and generates more code. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH 3/5] drm/i915: Replace "INTEL_INFO->gen == x" checks with IS_GENx

From: Tvrtko Ursulin This way optimization from a previous patch works even better. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++-- drivers/gpu/drm/i915/i915_dma.c | 4 ++--

[Intel-gfx] [PATCH 2/5] drm/i915: Promote IS_BROADWELL to a simple macro

From: Tvrtko Ursulin If we allow it a dedicated flag in dev_priv we enable the compiler to nicely optimize conditions like IS_HASSWELL || IS_BROADWELL. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.c | 4

[Intel-gfx] [PATCH 4/5] drm/i915: Introduce INTEL_GEN_RANGE macro

From: Tvrtko Ursulin To be used for more efficient Gen range checking. v2: Remove spurious chunk. (Chris Wilson) Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_fbc.c| 2 +-

[Intel-gfx] [PATCH 1/5] drm/i915: Make IS_GENx macros work on a mask

From: Tvrtko Ursulin If instead of numerical comparison me make these test a bitmask, we enable the compiler to optimize all instances of IS_GENx || IS_GENy. v2: Make bit zero of gen mask mean gen 1. Signed-off-by: Tvrtko Ursulin ---

[Intel-gfx] [PATCH 0/5] IS_GENx and related code shrinkage

From: Tvrtko Ursulin Our huge amount of "what hardware I am" checks during runtime is somewhat distasteful but to deeply ingrained to be easily fixable. Instead we can make them more efficient by spotting a few easy ways of helping the compiler optimize some common

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915/guc: don't spinwait if the GuC's workqueue is full

On 29/04/16 16:45, Tvrtko Ursulin wrote: One late comment: On 27/04/16 19:03, Dave Gordon wrote: Rather than wait to see whether more space becomes available in the GuC submission workqueue, we can just return -EAGAIN and let the caller try again in a little while. This gets rid of an

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: rework guc_add_workqueue_item()

On 06/05/16 09:55, Tvrtko Ursulin wrote: On 05/05/16 19:38, Dave Gordon wrote: On 29/04/2016 16:44, Tvrtko Ursulin wrote: On 27/04/16 19:03, Dave Gordon wrote: Mostly little optimisations; for instance, if the driver is correctly following the submission protocol, the "out of space"

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Promote IS_BROADWELL to a simple macro

On Fri, May 06, 2016 at 03:44:05PM +0100, Tvrtko Ursulin wrote: > > On 06/05/16 15:29, Ville Syrjälä wrote: > > On Fri, May 06, 2016 at 03:18:16PM +0100, Tvrtko Ursulin wrote: > >> > >> On 06/05/16 15:00, Ville Syrjälä wrote: > >>> On Fri, May 06, 2016 at 02:43:50PM +0100, Tvrtko Ursulin wrote: >

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Promote IS_BROADWELL to a simple macro

On Fri, May 06, 2016 at 03:44:05PM +0100, Tvrtko Ursulin wrote: > > On 06/05/16 15:29, Ville Syrjälä wrote: > >On Fri, May 06, 2016 at 03:18:16PM +0100, Tvrtko Ursulin wrote: > >> > >>On 06/05/16 15:00, Ville Syrjälä wrote: > >>>On Fri, May 06, 2016 at 02:43:50PM +0100, Tvrtko Ursulin wrote: >

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Make IS_GENx macros work on a mask

On Fri, May 06, 2016 at 03:36:26PM +0100, Tvrtko Ursulin wrote: > > On 06/05/16 15:28, Chris Wilson wrote: > >On Fri, May 06, 2016 at 02:43:49PM +0100, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>If instead of numerical comparison me make these test a >

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Promote IS_BROADWELL to a simple macro

On 06/05/16 15:29, Ville Syrjälä wrote: On Fri, May 06, 2016 at 03:18:16PM +0100, Tvrtko Ursulin wrote: On 06/05/16 15:00, Ville Syrjälä wrote: On Fri, May 06, 2016 at 02:43:50PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin If we allow it a dedicated flag in

[Intel-gfx] [for-CI 2/3] drm/i915/execlists: Refactor common engine setup

Move all of the constant assignments up front and into a common function. This is primarily to ensure the backpointers are set as early as possible for later use during initialisation. v2: Use a constant struct so that all the similar values are set together. v3: Sanitize the engine's IMR to

[Intel-gfx] [for-CI 1/3] 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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Make IS_GENx macros work on a mask

On 06/05/16 15:28, Chris Wilson wrote: On Fri, May 06, 2016 at 02:43:49PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin If instead of numerical comparison me make these test a bitmask, we enable the compiler to optimize all instances of IS_GENx || IS_GENy.

[Intel-gfx] [PATCH 1/2] drm/i915: Pin pages as we flush for CPU access

As a precautionary defensive measure against changes to the core (where we stop changing domains when unbinding), we want to ensure that the pages are available when we want to start CPU access, otherwise we will not perform the requisite clflushes to make the contents coherent for the user. We

[Intel-gfx] [PATCH 2/2] drm/i915/dmabuf: Pin pages as we flush for CPU access

As a precautionary defensive measure against changes to the core (where we stop changing domains when unbinding), we want to ensure that the pages are available when we want to start CPU access, otherwise we will not perform the requisite clflushes to make the contents coherent for the user. In

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Introduce INTEL_GEN_RANGE macro

On Fri, May 06, 2016 at 03:16:25PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > To be used for more efficient Gen range checking. > > Signed-off-by: Tvrtko Ursulin > --- > drivers/gpu/drm/i915/i915_drv.h | 1 + >

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Promote IS_BROADWELL to a simple macro

On Fri, May 06, 2016 at 03:18:16PM +0100, Tvrtko Ursulin wrote: > > On 06/05/16 15:00, Ville Syrjälä wrote: > > On Fri, May 06, 2016 at 02:43:50PM +0100, Tvrtko Ursulin wrote: > >> From: Tvrtko Ursulin > >> > >> If we allow it a dedicated flag in dev_priv we enable the

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Make IS_GENx macros work on a mask

On Fri, May 06, 2016 at 02:43:49PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > If instead of numerical comparison me make these test a > bitmask, we enable the compiler to optimize all instances > of IS_GENx || IS_GENy. > > Signed-off-by: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Replace "INTEL_INFO->gen == x" checks with IS_GENx

On 06/05/16 14:59, Chris Wilson wrote: On Fri, May 06, 2016 at 02:43:51PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin This way optimization from a previous patch works even better. Impact on object size? The hope is that gcc is able to combine tests so

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Replace "INTEL_INFO->gen == x" checks with IS_GENx

On 06/05/16 15:16, Tvrtko Ursulin wrote: On 06/05/16 14:59, Chris Wilson wrote: On Fri, May 06, 2016 at 02:43:51PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin This way optimization from a previous patch works even better. Impact on object size? The hope is

Re: [Intel-gfx] [PATCH] drm/i915: Correctly refcount connectors in hw state readou

On Fri, May 06, 2016 at 05:07:09PM +0300, Ville Syrjälä wrote: > On Fri, May 06, 2016 at 03:39:03PM +0200, Daniel Vetter wrote: > > This was forgotten when adding the the refcounting to > > drm_connector_state. > > > > v2: Don't forget to unreference existing connectors. This isn't > > relevant

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Promote IS_BROADWELL to a simple macro

On 06/05/16 15:00, Ville Syrjälä wrote: On Fri, May 06, 2016 at 02:43:50PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin If we allow it a dedicated flag in dev_priv we enable the compiler to nicely optimize conditions like IS_HASSWELL || IS_BROADWELL.

[Intel-gfx] [PATCH 1/2] drm/i915: Introduce INTEL_GEN_RANGE macro

From: Tvrtko Ursulin To be used for more efficient Gen range checking. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_fbc.c| 2 +- drivers/gpu/drm/i915/intel_ringbuffer.c

[Intel-gfx] [PATCH 2/2] drm/i915: Do not use a bitfield for INTEL_INFO->num_pipes

From: Tvrtko Ursulin It just makes more work for the compiler and generates more code. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [Intel-gfx] [PATCH] drm/i915: Correctly refcount connectors in hw state readou

On Fri, May 06, 2016 at 03:01:17PM +0100, Chris Wilson wrote: > On Fri, May 06, 2016 at 03:39:03PM +0200, Daniel Vetter wrote: > > This was forgotten when adding the the refcounting to > > drm_connector_state. > > > > v2: Don't forget to unreference existing connectors. This isn't > > relevant on

Re: [Intel-gfx] [PATCH] drm/i915: Correctly refcount connectors in hw state readou

On Fri, May 06, 2016 at 03:39:03PM +0200, Daniel Vetter wrote: > This was forgotten when adding the the refcounting to > drm_connector_state. > > v2: Don't forget to unreference existing connectors. This isn't > relevant on driver load, but this code also runs on resume, and there > we already

Re: [Intel-gfx] [PATCH] drm/i915: Correctly refcount connectors in hw state readou

On Fri, May 06, 2016 at 03:39:03PM +0200, Daniel Vetter wrote: > This was forgotten when adding the the refcounting to > drm_connector_state. > > v2: Don't forget to unreference existing connectors. This isn't > relevant on driver load, but this code also runs on resume, and there > we already

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Promote IS_BROADWELL to a simple macro

On Fri, May 06, 2016 at 02:43:50PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > If we allow it a dedicated flag in dev_priv we enable the > compiler to nicely optimize conditions like IS_HASSWELL || > IS_BROADWELL. > > Signed-off-by: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Replace "INTEL_INFO->gen == x" checks with IS_GENx

On Fri, May 06, 2016 at 02:43:51PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > This way optimization from a previous patch works even better. Impact on object size? The hope is that gcc is able to combine tests so reduce instruction count. -Chris -- Chris

Re: [Intel-gfx] [PATCH] drm/i915: Small display interrupt handlers tidy

On 06/05/16 14:27, Tvrtko Ursulin wrote: On 06/05/16 12:27, Chris Wilson wrote: On Fri, May 06, 2016 at 12:07:04PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin I have noticed some of our interrupt handlers use both dev and dev_priv while they could get away

[Intel-gfx] [PATCH v2] drm/i915: Small display interrupt handlers tidy

From: Tvrtko Ursulin I have noticed some of our interrupt handlers use both dev and dev_priv while they could get away with only dev_priv in the huge majority of cases. Tidying that up had a cascading effect on changing functions prototypes, so relatively big churn

[Intel-gfx] [PATCH v5 1/4] drm: Add helper for DP++ adaptors

From: Ville Syrjälä Add a helper which aids in the identification of DP dual mode (aka. DP++) adaptors. There are several types of adaptors specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2

[Intel-gfx] [PATCH 3/3] drm/i915: Replace "INTEL_INFO->gen == x" checks with IS_GENx

From: Tvrtko Ursulin This way optimization from a previous patch works even better. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++-- drivers/gpu/drm/i915/i915_dma.c | 4 ++--

[Intel-gfx] [PATCH 2/3] drm/i915: Promote IS_BROADWELL to a simple macro

From: Tvrtko Ursulin If we allow it a dedicated flag in dev_priv we enable the compiler to nicely optimize conditions like IS_HASSWELL || IS_BROADWELL. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.c | 4

[Intel-gfx] [PATCH 1/3] drm/i915: Make IS_GENx macros work on a mask

From: Tvrtko Ursulin If instead of numerical comparison me make these test a bitmask, we enable the compiler to optimize all instances of IS_GENx || IS_GENy. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_dma.c | 3 +++

[Intel-gfx] [PATCH] drm/i915: Correctly refcount connectors in hw state readou

This was forgotten when adding the the refcounting to drm_connector_state. v2: Don't forget to unreference existing connectors. This isn't relevant on driver load, but this code also runs on resume, and there we already have an atomic state. Spotted by Chris Wilson. Cc: Gabriel Feceoru

[Intel-gfx] [PATCH i-g-t 2/2] tests/testdisplay: Open DRM device with DRIVER_ANY

So that this test can be run in drivers other than i915. Signed-off-by: Tomeu Vizoso --- tests/testdisplay.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/testdisplay.c b/tests/testdisplay.c index f821bcc64779..45280e4cad82 100644 ---

[Intel-gfx] [PATCH i-g-t 1/2] tests/testdisplay: Use cairo helpers to draw to plane

Paint the color key with cairo, so the test doesn't have to map the BO by itself, which depends on the driver being tested. Signed-off-by: Tomeu Vizoso --- Don't know what's the purpose of drawing this rect, so it would be better to remove it if it isn't needed. ---

Re: [Intel-gfx] [PATCH] drm/i915: Small display interrupt handlers tidy

On 06/05/16 12:27, Chris Wilson wrote: On Fri, May 06, 2016 at 12:07:04PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin I have noticed some of our interrupt handlers use both dev and dev_priv while they could get away with only dev_priv in the huge majority of

Re: [Intel-gfx] [PATCH] drm/i915/sysfs: Adding mocs_state

On Fri, 6 May 2016, Ville Syrjälä wrote: On Thu, May 05, 2016 at 07:17:02AM +, Antoine, Peter wrote: It's a little overkill? They just need to know if the cache tables have changed and to be able to sync their indexes to the KMD. We already shot ourselves in the foot with this MOCS ABI

[Intel-gfx] [PATCH v6 27/34] drm/i915: Added scheduler statistic reporting to debugfs

From: John Harrison It is useful for know what the scheduler is doing for both debugging and performance analysis purposes. This change adds a bunch of counters and such that keep track of various scheduler operations (batches submitted, completed, flush requests,

Re: [Intel-gfx] [PATCH] drm/i915: Correctly refcount connectors in hw state readou

On Fri, May 06, 2016 at 03:09:43PM +0200, Daniel Vetter wrote: > This was forgotten when adding the the refcounting to > drm_connector_state. > > Cc: Gabriel Feceoru > Cc: Chris Wilson > Cc: Marius Vlad > Cc: Dave

[Intel-gfx] [PATCH v6 24/34] drm/i915: Added scheduler queue throttling by DRM file handle

From: John Harrison The scheduler decouples the submission of batch buffers to the driver from their subsequent submission to the hardware. This means that an application which is continuously submitting buffers as fast as it can could potentialy flood the driver. To

Re: [Intel-gfx] [PATCH v4 1/4] drm: Add helper for DP++ adaptors

On Fri, May 06, 2016 at 12:37:51PM +, Zanoni, Paulo R wrote: > Em Ter, 2016-05-03 às 20:56 +0300, ville.syrj...@linux.intel.com > escreveu: > > + > > +/** > > + * drm_dp_dual_mode_read - Read from the DP dual mode adaptor > > register(s) > > + * @adapter: I2C adapter for the DDC bus > > + *

[Intel-gfx] [PATCH] drm/i915: Correctly refcount connectors in hw state readou

This was forgotten when adding the the refcounting to drm_connector_state. Cc: Gabriel Feceoru Cc: Chris Wilson Cc: Marius Vlad Cc: Dave Airlie Fixes: d2307dea14a4 ("drm/atomic: use connector

Re: [Intel-gfx] [PATCHv4 3/3] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

On Mon, 2016-04-18 at 19:01 +0530, Durgadoss R wrote: > To support USB type C alternate DP mode, the display driver needs to > know the number of lanes required by the DP panel as well as number > of lanes that can be supported by the type-C cable. Sometimes, the > type-C cable may limit the

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Split bxt_ddi_pll_select()

On Mon, 2016-04-18 at 19:01 +0530, Durgadoss R wrote: > Split out of bxt_ddi_pll_select() the logic that calculates the pll > dividers and dpll_hw_state into a new function that doesn't depend on > crtc state. This will be used for enabling the port pll when doing > upfront link training. > > v1:

Re: [Intel-gfx] [PATCHv4 1/3] drm/i915: Make finding unused crtc as a generic function

On Mon, 2016-04-18 at 19:01 +0530, Durgadoss R wrote: > Looping over the crtc list and finding an unused crtc > has other users like upfront link training. Hence move it to "will have", since this patch precedes the upfront link training one. > a common function to re-use the logic. > > v4: > *

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix modeset handling during gpu reset, v2.

On Mon, May 02, 2016 at 10:57:01AM +0200, Maarten Lankhorst wrote: > This function would call drm_modeset_lock_all, while the suspend/resume > functions already have their own locking. Fix this by factoring out > __intel_display_resume, and calling the atomic helpers for duplicating > atomic state

Re: [Intel-gfx] [PATCH v4 1/4] drm: Add helper for DP++ adaptors

Em Ter, 2016-05-03 às 20:56 +0300, ville.syrj...@linux.intel.com escreveu: > From: Ville Syrjälä > > Add a helper which aids in the identification of DP dual mode > (aka. DP++) adaptors. There are several types of adaptors > specified: type 1 DVI, type 1 HDMI, type

Re: [Intel-gfx] [PATCH v3] drm/i915: resize the GuC WOPCM for rc6

On 06/05/16 10:37, Nick Hoath wrote: On 05/05/2016 16:04, Dave Gordon wrote: On 05/05/2016 15:02, Antoine, Peter wrote: The attached version still does not explain that the WOPCM_TOP is to tell the GuC not to use that space. That's NOT what WOPCM_TOP means. The GuC is allowed to use the

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

Pretty please, use a proper email client :-) On Thu, May 05, 2016 at 10:22:11PM +0300, Navare, Manasi D wrote: > > On Fri, Apr 29, 2016 at 06:13:33PM -0700, Manasi Navare wrote: > > This is the userspace component of the Displayport Compliance testing > > software required for compliance

Re: [Intel-gfx] [PATCH] drm/i915: Small display interrupt handlers tidy

On Fri, May 06, 2016 at 12:07:04PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > I have noticed some of our interrupt handlers use both dev and > dev_priv while they could get away with only dev_priv in the > huge majority of cases. > > Tidying that up had a

[Intel-gfx] i915 with valleyview

Hi Daniel, I am trying to use i915 in one of our board which has Intel ATOM E3840. I know Intel has released emgd driver for this cpu to use i915 but emgd is not supported on v4.5 (or v4.6). The board is having SFI (simple firmware interface) and maybe for that i915 is not finding the VBIOS and

Re: [Intel-gfx] [PATCH] drm/i915/sysfs: Adding mocs_state

On Thu, May 05, 2016 at 07:17:02AM +, Antoine, Peter wrote: > It's a little overkill? > > They just need to know if the cache tables have changed and to be able to > sync their indexes to the KMD. We already shot ourselves in the foot with this MOCS ABI stuff. This sysfs stuff just feels

[Intel-gfx] [PATCH] drm/i915: Small display interrupt handlers tidy

From: Tvrtko Ursulin I have noticed some of our interrupt handlers use both dev and dev_priv while they could get away with only dev_priv in the huge majority of cases. Tidying that up had a cascading effect on changing functions prototypes, so relatively big churn

Re: [Intel-gfx] [PATCH] x86: Silence 32bit compiler warning in intel_graphics_stolen()

On Thu, May 05, 2016 at 05:15:17PM +0100, Chris Wilson wrote: > arch/x86/kernel/early-quirks.c: In function ‘intel_graphics_stolen’: > arch/x86/kernel/early-quirks.c:539:9: warning: format ‘%llx’ expects > argument of type ‘long long unsigned int’, but argument 2 has type > ‘phys_addr_t’

Re: [Intel-gfx] [PATCH] drm/i915: add missing condition for committing planes on crtc

On Thu, May 05, 2016 at 03:04:54PM +0100, Lionel Landwerlin wrote: > On 04/05/16 15:30, Ville Syrjälä wrote: > > On Wed, May 04, 2016 at 02:40:34PM +0100, Lionel Landwerlin wrote: > >> We are currently missing the color management update condition to > >> commit planes on crtc. > >> > >> v2: add

[Intel-gfx] [PATCH 2/2] drm/i915/guc: Add Broxton GuC firmware loading support

Issue: VIZ-7772 Signed-off-by: Nick Hoath --- drivers/gpu/drm/i915/intel_guc_loader.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c b/drivers/gpu/drm/i915/intel_guc_loader.c index 46b01d7..d122e74 100644 ---

[Intel-gfx] [PATCH 0/2] drm/i915/guc: GuC firmware loading updates

Updates to Skylake firmware filename & support for loading Broxton firmware. Nick Hoath (1): drm/i915/guc: Add Broxton GuC firmware loading support Tom O'Rourke (1): drm/i915/guc: Use major_minor version for filename drivers/gpu/drm/i915/intel_guc_loader.c | 9 - 1 file changed, 8

[Intel-gfx] [PATCH 1/2] drm/i915/guc: Use major_minor version for filename

From: Tom O'Rourke Load guc firmware from file with major_minor number in filename instead of using symolic link with only major number. This change is so that new firmwares can only be used with a kernel change. This in case there is a regression with a new firmware, it

Re: [Intel-gfx] [PATCH v3] prime_mmap_kms: show case dma-buf new API and processes restrictions

On Thu, May 05, 2016 at 07:32:08PM -0300, Tiago Vignatti wrote: > dma-buf new API consists of: > > - mmap(dma_buf_fd, ...): the ability to map a dma-buf file-descriptor of a > graphics buffer to the userspace, and more importantly, to actually write on > the mapped pointer (which was not possible

Re: [Intel-gfx] [PATCH 10/12] drm/i915: Add lspcon core functions

On Wed, May 04, 2016 at 09:09:06PM +, Zanoni, Paulo R wrote: > Em Ter, 2016-05-03 às 21:44 +0530, Sharma, Shashank escreveu: > > > > On 5/3/2016 9:39 PM, Ville Syrjälä wrote: > > > > > > On Tue, May 03, 2016 at 09:18:49PM +0530, Sharma, Shashank wrote: > > > > > > > > Regards > > > >

Re: [Intel-gfx] [PATCH v3] drm/i915: resize the GuC WOPCM for rc6

On 05/05/2016 16:04, Dave Gordon wrote: On 05/05/2016 15:02, Antoine, Peter wrote: The attached version still does not explain that the WOPCM_TOP is to tell the GuC not to use that space. That's NOT what WOPCM_TOP means. The GuC is allowed to use the space up to the value stored in the

Re: [Intel-gfx] [PATCH v3] drm/i915: resize the GuC WOPCM for rc6

On 06/05/2016 08:01, Peter Antoine wrote: On Thu, 5 May 2016, Dave Gordon wrote: On 05/05/2016 15:02, Antoine, Peter wrote: The attached version still does not explain that the WOPCM_TOP is to tell the GuC not to use that space. That's NOT what WOPCM_TOP means. The GuC is allowed to use the

Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

On May 05 Zanoni, Paulo R wrote: > Em Qui, 2016-05-05 às 19:45 +0200, Stefan Richter escreveu: > > Oh, and in case you - the person reading this commit message - found > > this commit through git bisect, please do the following: > >  - Check your dmesg and see if there are error

Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

On May 05 Stefan Richter wrote: > Quoting the changelog of the commit: [...] > - Download intel-gpu-tools, compile it, and run: >$ sudo ./tests/kms_frontbuffer_tracking --run-subtest '*fbc-*' 2>&1 | > tee fbc.txt >Then send us the fbc.txt file, especially if you get a

[Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

On Apr 30 Stefan Richter wrote: > On Apr 29 Stefan Richter wrote: > > On Apr 26 Stefan Richter wrote: > > > v4.6-rc solidly hangs after a short while after boot, login to X11, and > > > doing nothing much remarkable on the just brought up X desktop. > > > > > > Hardware: x86-64, E3-1245 v3

Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

On May 05 Daniel Vetter wrote: > Hm, if it's watermarks then testing with latest drm-intel-nightly would be > interesting. We finally managed to land atomic watermark updates (should > all be there in 4.7 too): > > https://cgit.freedesktop.org/drm-intel I will see if I can test this sometime

Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

On May 05 Stefan Richter wrote: > Quoting the changelog of the commit: [...] > - Boot with drm.debug=0xe, reproduce the problem, then send us the >dmesg file. > > I can try this, but I am skeptical about getting any useful kernel > messages from before the hang. I booted 4.6-rc5

Re: [Intel-gfx] [PATCH] drm/i915/sysfs: Adding mocs_state

Anymore feedback on this? -Original Message- From: Antoine, Peter Sent: Thursday, May 5, 2016 8:17 AM To: Ville Syrjälä Cc: Chris Wilson ; intel-gfx@lists.freedesktop.org; Widawsky, Benjamin Subject:

Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: rework guc_add_workqueue_item()

On 05/05/16 19:38, Dave Gordon wrote: On 29/04/2016 16:44, Tvrtko Ursulin wrote: On 27/04/16 19:03, Dave Gordon wrote: Mostly little optimisations; for instance, if the driver is correctly following the submission protocol, the "out of space" condition is impossible, so the previous runtime

[Intel-gfx] [PATCH] drm: Poke at fixing unbalanced referencing in d2307dea14

--- drivers/gpu/drm/drm_atomic.c | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 86e89db02ed7..3ff1ed7b33db 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@

[Intel-gfx] [PATCH 3/3] drm: Drop crtc argument from __drm_atomic_helper_connector_destroy_state

It's unused, and really this helper should only look at the state structure and nothing else. Note that this conflicts with a patch from Dave that adds refcounting to drm_connectors. It's not yet clear whether the check Dave adds for connector != NULL is really needed or the right check. Cc: Dave

[Intel-gfx] [PATCH 1/3] drm: Drop crtc argument from __drm_atomic_helper_crtc_destroy_state

It's unused, and really this helper should only look at the state structure and nothing else. v2: Rebase on top of rockchip changes Cc: Maarten Lankhorst Cc: Thierry Reding Cc: Eric Anholt Cc: Mark Yao

[Intel-gfx] [PATCH 2/3] drm: Drop crtc argument from __drm_atomic_helper_connector_destroy_state

It's unused, and really this helper should only look at the state structure and nothing else. Cc: Maarten Lankhorst Cc: Thierry Reding Cc: Eric Anholt Cc: Laurent Pinchart

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Allow MI_LOAD_REGISTER_REG between whitelisted registers. (rev2)

== Series Details == Series: drm/i915: Allow MI_LOAD_REGISTER_REG between whitelisted registers. (rev2) URL : https://patchwork.freedesktop.org/series/6774/ State : failure == Summary == Series 6774v2 drm/i915: Allow MI_LOAD_REGISTER_REG between whitelisted registers.

[Intel-gfx] [PATCH igt v3] igt/gem_exec_parse: Simple exercise for MI_LOAD_REGISTER_REG

Command parser version 7 introduces the ability to copy between regsiters from the Haswell RCS with MI_LOAD_REGISTER_REG. This provides a quick smoketest of that ability. v2: Add some negative tests as well Signed-off-by: Chris Wilson --- tests/gem_exec_parse.c | 119

  1   2   >