Re: [Intel-gfx] [PATCH v1 00/13] Implement sw_sync test
On Wed, Aug 24, 2016 at 04:41:02PM -0400, Gustavo Padovan wrote: > 2016-08-24 Daniel Vetter : > > > On Tue, Aug 23, 2016 at 01:56:02PM -0400, robert.f...@collabora.com wrote: > > > From: Robert Foss > > > > > > This series implements the sw_sync test and the lib/sw_sync helper > > > functions > > > for said test. > > > > > > Gustavo Padovans sw_sync series was just de-staged in > > > gregkh-staging/staging-next [1], and this test is targeted at verifying > > > the > > > functionality implemented in that series. > > > > > > The sw_sync subtests range from very basic tests of the sw_sync > > > functionality, > > > to stress testing and randomized tests. > > > > > > [1] http://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/ > > > > This seems to be patches against igt (but the series is lacking the i-g-t- > > subject tag per CONTRIBUTING). I'm ok with that, but I thought the idea > > was to merge these testcases into the kernel's selftests? Did the plan > > change? > > We still have the tests for kernel's selftests and the plan is to > upstream them but I think getting complete tests explicit fencing > infrastructure in i-g-t is good idea too. We work on more complex tests > in there and leave kselftest with the basic tests from the initial > patchset for the sw_sync kselftest. I'm perfectly happy if i-g-t becomes the canonical location for all things gfx (kernel) testing. Just wondered whether we have a change of plans here or not. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [01/17] drm/i915: Skip holding an object reference for execbuf preparation (rev2)
== Series Details == Series: series starting with [01/17] drm/i915: Skip holding an object reference for execbuf preparation (rev2) URL : https://patchwork.freedesktop.org/series/11399/ State : warning == Summary == Series 11399v2 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/11399/revisions/2/mbox/ Test drv_hangman: Subgroup error-state-basic: pass -> DMESG-WARN (fi-snb-2600) Test gem_basic: Subgroup bad-close: dmesg-warn -> PASS (fi-snb-2600) Test gem_exec_gttfill: Subgroup basic: pass -> SKIP (fi-snb-2600) Test gem_ringfill: Subgroup basic-default-forked: pass -> DMESG-WARN (fi-snb-2600) dmesg-warn -> PASS (fi-snb-2520m) Subgroup basic-default-hang: dmesg-warn -> PASS (fi-snb-2600) pass -> DMESG-WARN (fi-snb-2520m) Test kms_cursor_legacy: Subgroup basic-flip-vs-cursor-legacy: fail -> PASS (fi-bsw-n3050) fail -> PASS (fi-skl-6700k) Subgroup basic-flip-vs-cursor-varying-size: fail -> PASS (fi-bsw-n3050) fail -> PASS (fi-skl-6700k) fi-bdw-5557u total:252 pass:235 dwarn:0 dfail:0 fail:2 skip:15 fi-bsw-n3050 total:252 pass:204 dwarn:0 dfail:0 fail:2 skip:46 fi-hsw-4770k total:252 pass:228 dwarn:0 dfail:0 fail:2 skip:22 fi-hsw-4770r total:252 pass:224 dwarn:0 dfail:0 fail:2 skip:26 fi-ivb-3520m total:252 pass:220 dwarn:0 dfail:0 fail:1 skip:31 fi-skl-6260u total:252 pass:236 dwarn:0 dfail:0 fail:2 skip:14 fi-skl-6700k total:252 pass:218 dwarn:4 dfail:0 fail:2 skip:28 fi-snb-2520m total:252 pass:199 dwarn:8 dfail:0 fail:2 skip:43 fi-snb-2600 total:252 pass:198 dwarn:8 dfail:0 fail:2 skip:44 Results at /archive/results/CI_IGT_test/Patchwork_2425/ e14363ed1c12c86726914e3a790662e84e631c37 drm-intel-nightly: 2016y-08m-24d-18h-39m-56s UTC integration manifest 0c45e82 drm/i915: Pin the pages whilst operating on them 1ed4323 drm/i915: Fix i915_gem_evict_for_vma (soft-pinning) dd07652 drm/i915: Allow the user to pass a context to any ring 1c729cf drm/i915: Defer active reference until required 76e71f4 drm/i915: Skip holding an object reference for execbuf preparation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Eliminate lots of iterations over the execobjects array
The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.
Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active location. Only if that fails, do we add
it to the unbound list for phase 2. In phase 2, we try and add all those
objects that could not fit into their previous location, with fallback
to retrying all objects and evicting the VM in case of severe
fragmentation. (This is the same as before, except that phase 1 is now
done inline with looking up the VMA to avoid an iteration over the
execobject array. In the ideal case, we eliminate the separate reservation
phase). During the reservation phase, we only evict from the VM between
passes (rather than currently as we try to fit every new VMA). In
testing with Unreal Engine's Atlantis demo which stresses the eviction
logic on gen7 class hardware, this speed up the framerate by a factor of
2.
The second loop amalgamation is between move_to_gpu and move_to_active.
As we always submit the request, even if incomplete, we can use the
current request to track active VMA as we perform the flushes and
synchronisation required.
The next big advancement is to avoid copying back to the user any
execobjects and relocations that are not changed.
v2: Add a Theory of Operation spiel.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h|3 +-
drivers/gpu/drm/i915/i915_gem.c|2 +-
drivers/gpu/drm/i915/i915_gem_evict.c | 64 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 1719
drivers/gpu/drm/i915/i915_gem_gtt.h|4 +-
5 files changed, 1022 insertions(+), 770 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 870e3c61eb68..f874a533eab9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3124,6 +3124,7 @@ int i915_gem_freeze_late(struct drm_i915_private
*dev_priv);
void *i915_gem_object_alloc(struct drm_device *dev);
void i915_gem_object_free(struct drm_i915_gem_object *obj);
+bool i915_gem_object_flush_active(struct drm_i915_gem_object *obj);
void i915_gem_object_init(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_object_ops *ops);
struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
@@ -3515,7 +3516,7 @@ int __must_check i915_gem_evict_something(struct
i915_address_space *vm,
unsigned flags);
int __must_check i915_gem_evict_for_vma(struct i915_vma *vma,
unsigned int flags);
-int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
+int i915_gem_evict_vm(struct i915_address_space *vm);
/* belongs in i915_gem_gtt.h */
static inline void i915_gem_chipset_flush(struct drm_i915_private *dev_priv)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 78faac2b780c..1f35dd6219cb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3034,7 +3034,7 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
alignment, u64 flags)
size, obj->base.size,
flags & PIN_MAPPABLE ? "mappable" : "total",
end);
- return -E2BIG;
+ return -ENOSPC;
}
ret = i915_gem_object_get_pages(obj);
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 79ce873b4891..d59b085de48e 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -55,7 +55,7 @@ mark_free(struct i915_vma *vma, unsigned int flags, struct
list_head *unwind)
if (flags & PIN_NONFAULT && vma->obj->fault_mappable)
return false;
- list_add(&vma->exec_list, unwind);
+ list_add(&vma->evict_link, unwind);
return drm_mm_scan_add_block(&vma->node);
}
@@ -134,7 +134,7 @@ search_again:
} while (*++phase);
/* Nothing found, clean up and bail out! */
- list_for_each_entry_safe(vma, next, &eviction_list, exec_list) {
+ list_for_each_entry_safe(vma, next, &eviction_list, evict_link) {
ret = drm_mm_scan_remove_block(&vma->node);
BUG_ON(ret);
}
@@ -179,16 +179,16 @@ found:
* calling unbind (which may remove the active reference
* of any of our objects, thus corrupting the list).
*/
- list_for_each_entry_safe(vma, next, &eviction_list, exec_list) {
+ list_for_each_entry_safe(vma, next, &eviction_list, evict_link) {
if (drm_mm_scan_remove_block(&vma->node))
__i915_vma_pin(vma);
else
- list_del(&vma->exec_list);
+ list_del
Re: [Intel-gfx] drm/i915/slpc: Update freq min/max softlimits
On 8/24/2016 2:07 PM, Chris Wilson wrote:
On Sun, Aug 21, 2016 at 09:39:17PM +0530, Kamble, Sagar A wrote:
On 8/21/2016 2:09 PM, Chris Wilson wrote:
On Sun, Aug 21, 2016 at 11:39:22AM +0530, Kamble, Sagar A wrote:
On 8/20/2016 1:32 PM, Chris Wilson wrote:
On Sat, Aug 20, 2016 at 10:39:25AM +0530, Sagar Arun Kamble wrote:
+ obj = dev_priv->guc.slpc.vma->obj;
+ if (obj) {
OOPS.
Fixed in next series.
+ intel_slpc_query_task_state(dev_priv);
+
+ page = i915_gem_object_get_page(obj, 0);
+ if (page)
+ pv = kmap_atomic(page);
+ }
+
+ if (pv) {
+ data = *(struct slpc_shared_data *) pv;
+ kunmap_atomic(pv);
Can kmap_atomic return zero?
Fixed in next series.
+
+ /*
+* TODO: Define separate variables for slice and unslice
+* frequencies for driver state variable.
+*/
+ dev_priv->rps.max_freq_softlimit =
+ data.task_state_data.freq_unslice_max;
+ dev_priv->rps.min_freq_softlimit =
+ data.task_state_data.freq_unslice_min;
These are user values, you do not get to arbitrarily rewrite them.
You control dev_priv->rps.[min|max]_freq.
With SLPC, GuC firmware SLPC S/W requested frequency be operated in
the softlimits analogous to
Host softlimits. Limits might be different with SLPC and can be
controlled through regular interfaces.
dev_priv->rps.[min|max]_freq are HW Min/Max.
Exactly. The soft limits are *only* set by the user. They are not to
modified by the driver. (The caveat would be a dynamic update of the hw
range, but that too should never be required.)
-Chris
This initialization is similar to following from intel_init_gt_powersave
dev_priv->rps.max_freq_softlimit = dev_priv->rps.max_freq;
dev_priv->rps.min_freq_softlimit = dev_priv->rps.min_freq;
I assume min_freq is hw min(RPn). With SLPC, min_freq(RPn) will not
be requested.
SLPC operating range today is (>Rpe, Rp0) so I wanted user to know
the min_softlimit being initialized by SLPC by default.
Hmm, my mistake here was thinking this was more than a one off. Setting
the initial soft (user) range on startup is fine. Continually changing
them after userspace registration is not. (The value the user writes
into the limit is what should be read back - without very good reason,
such as the hard limits changing).
-Chris
I interpreted the rewrite differently, thinking SLPC should not write it
post init_gt_powersave.
As discussed, I will change this to make sure SLPC init does not touch
these values once it is
initialized in the load path.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI] Revert "drm/i915/fbc: Allow on unfenced surfaces, for recent gen"
On Wed, Aug 24, 2016 at 09:14:59PM +, Zanoni, Paulo R wrote: > Em Qua, 2016-08-24 às 19:00 +0100, Chris Wilson escreveu: > > . In the meantime lets hope that all > > framebuffers are idle and naturally fit within the mappable aperture. > > What exactly do you mean with the sentence above? Is there some other > bug you spotted? Please share the information. Not all framebuffers will be fenced, especially if they are being rendered to before being flipped to the first time. The pressure is less for full-ppgtt systems (now that we have independent activity tracking on the vma) but that is not sufficient to guarrantee the object will be assigned a map_and_fenceable VMA for display. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI] Revert "drm/i915/fbc: Allow on unfenced surfaces, for recent gen"
Em Qua, 2016-08-24 às 19:00 +0100, Chris Wilson escreveu:
> This reverts commit 8678fdaf396c ("drm/i915/fbc: Allow on unfenced
> surfaces,
> for recent gen") as Skylake has issues with unfenced FBC tracking
> (and
> yes Skylake doesn't even enable FBC yet)
But it used to work if you had i915.enable_fbc=1 after your latest
fixes :)
> . Paulo would like to do a full
> review of all existing workarounds to see if any more are missing
> prior
> to allowing FBC on unfenced surfaces
We are missing at least one workaround for this, and it's described in
the FBC_CTL page of BSpec for SKL, bit 31 description: we need to
calculate the compressed buffer stride and program it to a register.
I didin't say I would do the review of all existing workarounds, just
that someone needs to do this before enabling FBC on non-X-tiled
buffers since I recall skipping the implementation of workarounds that
didn't apply to X-tiling. Maybe the one I mentioned was the only one,
maybe not.
Also, our test suite only tests X tiling, and the
kms_frontbuffer_tracking/fbc-tilingchange will need to be updated.
> . In the meantime lets hope that all
> framebuffers are idle and naturally fit within the mappable aperture.
What exactly do you mean with the sentence above? Is there some other
bug you spotted? Please share the information.
>
> Requested-by: Paulo Zanoni
> Fixes: 8678fdaf396c ("drm/i915/fbc: Allow on unfenced surfaces...");
> Cc: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_fbc.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index bf8b22ad9aed..faa67624e1ed 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -799,10 +799,8 @@ static bool intel_fbc_can_activate(struct
> intel_crtc *crtc)
> */
> if (cache->fb.tiling_mode != I915_TILING_X ||
> cache->fb.fence_reg == I915_FENCE_REG_NONE) {
> - if (INTEL_GEN(dev_priv) < 5) {
> - fbc->no_fbc_reason = "framebuffer not tiled
> or fenced";
> - return false;
> - }
> + fbc->no_fbc_reason = "framebuffer not tiled or
> fenced";
> + return false;
> }
> if (INTEL_INFO(dev_priv)->gen <= 4 && !IS_G4X(dev_priv) &&
> cache->plane.rotation != DRM_ROTATE_0) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/dp: Switch to using the DRM function for reading DP link status
Em Qua, 2016-08-17 às 12:02 -0700, Dhinakaran Pandiyan escreveu:
> Since a DRM function that reads link DP link status is available,
> let's
> use that instead of the i915 clone.
One could describe the i915 function as a convenient wrapper instead of
a clone, since it allows passing just intel_dp as an argument and
already does the length checking, allowing callers to stay under 80
columns :). So perhaps you could have given more arguments on why the
codebase will benefit from this change.
I'm not sure whether I think the code will be better or worse with this
change, but the patch does what it says, so:
Reviewed-by: Paulo Zanoni
>
>
> drm_dp_dpcd_read_link_status() returns a negative error code if the
> number
> of bytes read is not DP_LINK_STATUS_SIZE, drm_dp_dpcd_access() does
> the
> length check.
>
> Signed-off-by: Dhinakaran Pandiyan
>
> v2: Eliminated redundant DP_LINK_STATUS_SIZE length check.
On our driver we usually put version information above the signatures
and tags.
> ---
> drivers/gpu/drm/i915/intel_dp.c | 15 ++-
> drivers/gpu/drm/i915/intel_dp_link_training.c | 8 ++--
> drivers/gpu/drm/i915/intel_drv.h | 2 --
> 3 files changed, 8 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index 8fe2afa..8eff57e 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2863,17 +2863,6 @@ static void chv_dp_post_pll_disable(struct
> intel_encoder *encoder)
> chv_phy_post_pll_disable(encoder);
> }
>
> -/*
> - * Fetch AUX CH registers 0x202 - 0x207 which contain
> - * link status information
> - */
> -bool
> -intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t
> link_status[DP_LINK_STATUS_SIZE])
> -{
> - return drm_dp_dpcd_read(&intel_dp->aux, DP_LANE0_1_STATUS,
> link_status,
> - DP_LINK_STATUS_SIZE) ==
> DP_LINK_STATUS_SIZE;
> -}
> -
> /* These are source-specific values. */
> uint8_t
> intel_dp_voltage_max(struct intel_dp *intel_dp)
> @@ -3896,8 +3885,8 @@ intel_dp_check_link_status(struct intel_dp
> *intel_dp)
>
> WARN_ON(!drm_modeset_is_locked(&dev-
> >mode_config.connection_mutex));
>
> - if (!intel_dp_get_link_status(intel_dp, link_status)) {
> - DRM_ERROR("Failed to get link status\n");
> + if (drm_dp_dpcd_read_link_status(&intel_dp->aux,
> link_status) <= 0) {
> + DRM_ERROR("failed to get link status\n");
You just made me run "grep DRM_ERROR * | cut -d'"' -f2 | sort" in order
to check how consistent we are regarding error message capitalization
:).
return;
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 60fb39c..8e60e7c 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -150,7 +150,9 @@ intel_dp_link_training_clock_recovery(struct
> intel_dp *intel_dp)
> uint8_t link_status[DP_LINK_STATUS_SIZE];
>
> drm_dp_link_train_clock_recovery_delay(intel_dp-
> >dpcd);
> - if (!intel_dp_get_link_status(intel_dp,
> link_status)) {
> +
> + if (drm_dp_dpcd_read_link_status(&intel_dp->aux,
> link_status)
> + <= 0) {
> DRM_ERROR("failed to get link status\n");
> break;
> }
> @@ -258,7 +260,9 @@
> intel_dp_link_training_channel_equalization(struct intel_dp
> *intel_dp)
> }
>
> drm_dp_link_train_channel_eq_delay(intel_dp->dpcd);
> - if (!intel_dp_get_link_status(intel_dp,
> link_status)) {
> +
> + if (drm_dp_dpcd_read_link_status(&intel_dp->aux,
> link_status)
> + <= 0) {
> DRM_ERROR("failed to get link status\n");
> break;
> }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index b1fc67e..a3a2cb9 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1394,8 +1394,6 @@ intel_dp_pre_emphasis_max(struct intel_dp
> *intel_dp, uint8_t voltage_swing);
> void intel_dp_compute_rate(struct intel_dp *intel_dp, int
> port_clock,
> uint8_t *link_bw, uint8_t *rate_select);
> bool intel_dp_source_supports_hbr2(struct intel_dp *intel_dp);
> -bool
> -intel_dp_get_link_status(struct intel_dp *intel_dp, uint8_t
> link_status[DP_LINK_STATUS_SIZE]);
>
> static inline unsigned int intel_dp_unused_lane_mask(int lane_count)
> {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 9/13] tests/sw_sync: Add subtest test_sync_multi_consumer
From: Robert Foss
This subtest verifies the access ordering of multiple consumer threads.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 103 +-
1 file changed, 103 insertions(+), 0 deletions(-)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index db03f48..0c9c923 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -27,6 +27,8 @@
*Robert Foss
*/
+#include
+#include
#include
#include "sw_sync.h"
@@ -35,6 +37,15 @@
IGT_TEST_DESCRIPTION("Test SW Sync Framework");
+typedef struct {
+ int timeline;
+ uint32_t thread_id;
+ uint32_t nbr_threads;
+ uint32_t nbr_iterations;
+ volatile uint32_t * volatile counter;
+ sem_t *sem;
+} data_t;
+
static void test_alloc_timeline(void)
{
int timeline;
@@ -203,6 +214,95 @@ static void test_sync_merge_same(void)
sw_sync_timeline_destroy(timeline);
}
+static void * test_sync_multi_consumer_thread(void *arg)
+{
+ data_t *data = arg;
+ int thread_id = data->thread_id;
+ int nbr_threads = data->nbr_threads;
+ int timeline = data->timeline;
+ int iterations = data->nbr_iterations;
+ int ret, i;
+
+ for (i = 0; i < iterations; i++) {
+ int next_point = i * nbr_threads + thread_id;
+ int fence = sw_sync_fence_create(timeline, next_point);
+
+ ret = sw_sync_wait(fence, 1000);
+ if (ret <= 0)
+ {
+ return (void *) 1;
+ }
+
+ if (*(data->counter) != next_point)
+ {
+ return (void *) 1;
+ }
+
+ sem_post(data->sem);
+ sw_sync_fence_destroy(fence);
+ }
+ return NULL;
+}
+
+static void test_sync_multi_consumer(void)
+{
+ const uint32_t nbr_threads = 8;
+ const uint32_t nbr_iterations = 1 << 14;
+ data_t data_arr[nbr_threads];
+ pthread_t thread_arr[nbr_threads];
+ sem_t sem;
+ int timeline;
+ volatile uint32_t counter = 0;
+ uintptr_t thread_ret = 0;
+ data_t data;
+ int i, ret;
+
+ sem_init(&sem, 0, 0);
+ timeline = sw_sync_timeline_create();
+
+ data.nbr_iterations = nbr_iterations;
+ data.nbr_threads = nbr_threads;
+ data.counter = &counter;
+ data.timeline = timeline;
+ data.sem = &sem;
+
+ /* Start sync threads. */
+ for (i = 0; i < nbr_threads; i++)
+ {
+ data_arr[i] = data;
+ data_arr[i].thread_id = i;
+ ret = pthread_create(&thread_arr[i], NULL,
+test_sync_multi_consumer_thread,
+(void *) &(data_arr[i]));
+ igt_assert_eq(ret, 0);
+ }
+
+ /* Produce 'content'. */
+ for (i = 0; i < nbr_threads * nbr_iterations; i++)
+ {
+ sem_wait(&sem);
+
+ counter++;
+ sw_sync_timeline_inc(timeline, 1);
+ }
+
+ /* Wait for threads to complete. */
+ for (i = 0; i < nbr_threads; i++)
+ {
+ uintptr_t local_thread_ret;
+ pthread_join(thread_arr[i], (void **)&local_thread_ret);
+ thread_ret |= local_thread_ret;
+ }
+
+ sw_sync_timeline_destroy(timeline);
+ sem_destroy(&sem);
+
+ igt_assert_f(counter == nbr_threads * nbr_iterations,
+"Counter has unexpected value.\n");
+
+ igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -225,5 +325,8 @@ igt_main
igt_subtest("sync_merge_same")
test_sync_merge_same();
+
+ igt_subtest("sync_multi_consumer")
+ test_sync_multi_consumer();
}
--
git-series 0.8.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 10/13] tests/sw_sync: Add subtest test_sync_multi_consumer_producer
From: Robert Foss
This test verifies that stressing the kernel by creating multiple
consumer/producer threads that wait on a single timeline to be incremented
by another conumer/producer thread does not fail.
And that the order amongst the threads is maintained.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 83 ++-
1 file changed, 83 insertions(+), 0 deletions(-)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 0c9c923..0e67ad5 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -303,6 +303,86 @@ static void test_sync_multi_consumer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
}
+static void * test_sync_multi_consumer_producer_thread(void *arg)
+{
+ data_t *data = arg;
+ int thread_id = data->thread_id;
+ int nbr_threads = data->nbr_threads;
+ int timeline = data->timeline;
+ int iterations = data->nbr_iterations;
+ int ret, i;
+
+ for (i = 0; i < iterations; i++) {
+ int next_point = i * nbr_threads + thread_id;
+ int fence = sw_sync_fence_create(timeline, next_point);
+
+ ret = sw_sync_wait(fence, 1000);
+ if (ret <= 0)
+ {
+ return (void *) 1;
+ }
+
+ if (*(data->counter) != next_point)
+ {
+ return (void *) 1;
+ }
+
+ (*data->counter)++;
+
+ /* Kick off the next thread. */
+ sw_sync_timeline_inc(timeline, 1);
+
+ sw_sync_fence_destroy(fence);
+ }
+ return NULL;
+}
+
+static void test_sync_multi_consumer_producer(void)
+{
+ const uint32_t nbr_threads = 8;
+ const uint32_t nbr_iterations = 1 << 14;
+ data_t data_arr[nbr_threads];
+ pthread_t thread_arr[nbr_threads];
+ int timeline;
+ volatile uint32_t counter = 0;
+ uintptr_t thread_ret = 0;
+ data_t data;
+ int i, ret;
+
+ timeline = sw_sync_timeline_create();
+
+ data.nbr_iterations = nbr_iterations;
+ data.nbr_threads = nbr_threads;
+ data.counter = &counter;
+ data.timeline = timeline;
+
+ /* Start consumer threads. */
+ for (i = 0; i < nbr_threads; i++)
+ {
+ data_arr[i] = data;
+ data_arr[i].thread_id = i;
+ ret = pthread_create(&thread_arr[i], NULL,
+test_sync_multi_consumer_producer_thread,
+(void *) &(data_arr[i]));
+ igt_assert_eq(ret, 0);
+ }
+
+ /* Wait for threads to complete. */
+ for (i = 0; i < nbr_threads; i++)
+ {
+ uintptr_t local_thread_ret;
+ pthread_join(thread_arr[i], (void **)&local_thread_ret);
+ thread_ret |= local_thread_ret;
+ }
+
+ sw_sync_timeline_destroy(timeline);
+
+ igt_assert_f(counter == nbr_threads * nbr_iterations,
+"Counter has unexpected value.\n");
+
+ igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -328,5 +408,8 @@ igt_main
igt_subtest("sync_multi_consumer")
test_sync_multi_consumer();
+
+ igt_subtest("sync_multi_consumer_producer")
+ test_sync_multi_consumer_producer();
}
--
git-series 0.8.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 12/13] tests/sw_sync: Add subtest test_sync_multi_timeline_wait
From: Robert Foss
This subtest verifies that waiting, timing out on a wait and that counting
fences in various states works.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 66 ++-
1 file changed, 66 insertions(+), 0 deletions(-)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 93f4151..322c7b1 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -214,6 +214,69 @@ static void test_sync_merge_same(void)
sw_sync_timeline_destroy(timeline);
}
+static void test_sync_multi_timeline_wait(void)
+{
+ int timeline[3];
+ int in_fence[3];
+ int fence_merge;
+ int active, signaled, ret;
+
+ timeline[0] = sw_sync_timeline_create();
+ timeline[1] = sw_sync_timeline_create();
+ timeline[2] = sw_sync_timeline_create();
+
+ in_fence[0] = sw_sync_fence_create(timeline[0], 5);
+ in_fence[1] = sw_sync_fence_create(timeline[1], 5);
+ in_fence[2] = sw_sync_fence_create(timeline[2], 5);
+
+ fence_merge = sw_sync_merge(in_fence[0], in_fence[1]);
+ fence_merge = sw_sync_merge(in_fence[2], fence_merge);
+
+ /* Confirm fence isn't signaled */
+ active = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 3, "Fence signaled too early\n");
+
+ ret = sw_sync_wait(fence_merge, 0);
+ igt_assert_f(ret == 0, "Failure waiting on fence until timeout\n");
+
+ sw_sync_timeline_inc(timeline[0], 5);
+ active = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ signaled = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ igt_assert_f(active == 2 && signaled == 1,
+ "Fence did not signal properly\n");
+
+ sw_sync_timeline_inc(timeline[1], 5);
+ active = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ signaled = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ igt_assert_f(active == 1 && signaled == 2,
+ "Fence did not signal properly\n");
+
+ sw_sync_timeline_inc(timeline[2], 5);
+ active = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ signaled = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ igt_assert_f(active == 0 && signaled == 3,
+"Fence did not signal properly\n");
+
+ /* confirm you can successfully wait */
+ ret = sw_sync_wait(fence_merge, 100);
+ igt_assert_f(ret > 0, "Failure waiting on signaled fence\n");
+
+ sw_sync_fence_destroy(in_fence[0]);
+ sw_sync_fence_destroy(in_fence[1]);
+ sw_sync_fence_destroy(in_fence[2]);
+ sw_sync_fence_destroy(fence_merge);
+ sw_sync_timeline_destroy(timeline[0]);
+ sw_sync_timeline_destroy(timeline[1]);
+ sw_sync_timeline_destroy(timeline[2]);
+}
+
static void * test_sync_multi_consumer_thread(void *arg)
{
data_t *data = arg;
@@ -476,6 +539,9 @@ igt_main
igt_subtest("sync_merge_same")
test_sync_merge_same();
+ igt_subtest("sync_multi_timeline_wait")
+ test_sync_multi_timeline_wait();
+
igt_subtest("sync_multi_consumer")
test_sync_multi_consumer();
--
git-series 0.8.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 11/13] tests/sw_sync: Add subtest test_sync_random_merge
From: Robert Foss
This subtest verifies that creating many timelines and merging random fences
from each timeline with eachother results in merged fences that are fully
functional.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 73 ++-
1 file changed, 73 insertions(+), 0 deletions(-)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 0e67ad5..93f4151 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -383,6 +383,76 @@ static void test_sync_multi_consumer_producer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
}
+static void test_sync_random_merge(void)
+{
+ int i, size, ret;
+ const int nbr_timeline = 32;
+ const int nbr_merge = 1024;
+ int fence_map[nbr_timeline];
+ int timeline_arr[nbr_timeline];
+ int fence, tmpfence, merged;
+ int timeline, timeline_offset, sync_pt;
+
+ srand(time(NULL));
+
+ for (i = 0; i < nbr_timeline; i++) {
+ timeline_arr[i] = sw_sync_timeline_create();
+ fence_map[i] = -1;
+ }
+
+ sync_pt = rand();
+ fence = sw_sync_fence_create(timeline_arr[0], sync_pt);
+
+ fence_map[0] = sync_pt;
+
+ /* Randomly create syncpoints out of a fixed set of timelines,
+* and merge them together.
+*/
+ for (i = 0; i < nbr_merge; i++) {
+ /* Generate syncpoint. */
+ timeline_offset = rand() % nbr_timeline;
+ timeline = timeline_arr[timeline_offset];
+ sync_pt = rand();
+
+ /* Keep track of the latest sync_pt in each timeline. */
+ if (fence_map[timeline_offset] == -1)
+ fence_map[timeline_offset] = sync_pt;
+ else if (fence_map[timeline_offset] < sync_pt)
+ fence_map[timeline_offset] = sync_pt;
+
+ /* Merge. */
+ tmpfence = sw_sync_fence_create(timeline, sync_pt);
+ merged = sw_sync_merge(tmpfence, fence);
+ sw_sync_fence_destroy(tmpfence);
+ sw_sync_fence_destroy(fence);
+ fence = merged;
+ }
+
+ size = 0;
+ for (i = 0; i < nbr_timeline; i++)
+ if (fence_map[i] != -1)
+ size++;
+
+ /* Trigger the merged fence. */
+ for (i = 0; i < nbr_timeline; i++) {
+ if (fence_map[i] != -1) {
+ ret = sw_sync_wait(fence, 0);
+ igt_assert_f(ret == 0,
+ "Failure waiting on fence until timeout\n");
+ /* Increment the timeline to the last sync_pt */
+ sw_sync_timeline_inc(timeline_arr[i], fence_map[i]);
+ }
+ }
+
+ /* Check that the fence is triggered. */
+ ret = sw_sync_wait(fence, 0);
+ igt_assert_f(ret > 0, "Failure triggering fence\n");
+
+ sw_sync_fence_destroy(fence);
+ for (i = 0; i < nbr_timeline; i++)
+ sw_sync_timeline_destroy(timeline_arr[i]);
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -411,5 +481,8 @@ igt_main
igt_subtest("sync_multi_consumer_producer")
test_sync_multi_consumer_producer();
+
+ igt_subtest("sync_random_merge")
+ test_sync_random_merge();
}
--
git-series 0.8.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/13] tests/sw_sync: Add subtest test_sync_wait
From: Robert Foss
This subtest verifies that waiting on fences works properly.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 38 ++
1 file changed, 38 insertions(+), 0 deletions(-)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 851430e..07e9638 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -80,6 +80,41 @@ static void test_alloc_merge_fence(void)
sw_sync_timeline_destroy(timeline[1]);
}
+static void test_sync_wait(void)
+{
+ int fence, ret;
+ int timeline;
+
+ timeline = sw_sync_timeline_create();
+ fence = sw_sync_fence_create(timeline, 5);
+
+ /* Wait on fence until timeout */
+ ret = sw_sync_wait(fence, 0);
+ igt_assert_f(ret == 0, "Failure waiting on fence until timeout\n");
+
+ /* Advance timeline from 0 -> 1 */
+ sw_sync_timeline_inc(timeline, 1);
+
+ /* Wait on fence until timeout */
+ ret = sw_sync_wait(fence, 0);
+ igt_assert_f(ret == 0, "Failure waiting on fence until timeout\n");
+
+ /* Signal the fence */
+ sw_sync_timeline_inc(timeline, 4);
+
+ /* Wait successfully */
+ ret = sw_sync_wait(fence, 0);
+ igt_assert_f(ret > 0, "Failure waiting on fence\n");
+
+ /* Go even further, and confirm wait still succeeds */
+ sw_sync_timeline_inc(timeline, 10);
+ ret = sw_sync_wait(fence, 0);
+ igt_assert_f(ret > 0, "Failure waiting ahead\n");
+
+ sw_sync_fence_destroy(fence);
+ sw_sync_timeline_destroy(timeline);
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -93,5 +128,8 @@ igt_main
igt_subtest("alloc_merge_fence")
test_alloc_merge_fence();
+
+ igt_subtest("sync_wait")
+ test_sync_wait();
}
--
git-series 0.8.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/13] tests/sw_sync: Add subtest test_alloc_fence_invalid_timeline
From: Robert Foss
This subtests tests that creating fences on negative timelines fail.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 7 +++
1 file changed, 7 insertions(+), 0 deletions(-)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index a8c8ca4..102647d 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -55,6 +55,10 @@ static void test_alloc_fence(void)
sw_sync_timeline_destroy(timeline);
}
+static void test_alloc_fence_invalid_timeline(void)
+{
+ sw_sync_fence_create(-1, 0);
+}
igt_main
{
@@ -63,5 +67,8 @@ igt_main
igt_subtest("alloc_fence")
test_alloc_fence();
+
+ igt_subtest("alloc_fence_invalid_timeline")
+ test_alloc_fence_invalid_timeline();
}
--
git-series 0.8.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 13/13] tests/sw_sync: Add subtest test_sync_multi_producer_single_consumer
From: Robert Foss
This subtest runs a single consumer thread and multiple producer thread that
are synchronized using multiple timelines.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 139 +-
1 file changed, 139 insertions(+), 0 deletions(-)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 322c7b1..4336659 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -446,6 +446,142 @@ static void test_sync_multi_consumer_producer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
}
+static int test_mspc_wait_on_fence(int fence)
+{
+ int error, active;
+
+ do {
+ error = sw_sync_fence_count_status(fence,
+ SW_SYNC_FENCE_STATUS_ERROR);
+ igt_assert_f(error == 0, "Error occurred on fence\n");
+ active = sw_sync_fence_count_status(fence,
+
SW_SYNC_FENCE_STATUS_ACTIVE);
+ } while (active);
+
+ return 0;
+}
+
+static struct {
+ int iterations;
+ int threads;
+ int counter;
+ int cons_timeline;
+ int *prod_timeline;
+ pthread_mutex_t lock;
+} test_mpsc_data;
+
+static int mpsc_producer_thread(void *d)
+{
+ int id = (long)d;
+ int fence, i;
+ int *prod_timeline = test_mpsc_data.prod_timeline;
+ int cons_timeline = test_mpsc_data.cons_timeline;
+ int iterations = test_mpsc_data.iterations;
+
+ for (i = 0; i < iterations; i++) {
+ fence = sw_sync_fence_create(cons_timeline, i);
+
+ /* Wait for the consumer to finish. Use alternate
+* means of waiting on the fence
+*/
+ if ((iterations + id) % 8 != 0) {
+ igt_assert_f(sw_sync_wait(fence, -1) > 0,
+"Failure waiting on fence\n");
+ } else {
+ igt_assert_f(test_mspc_wait_on_fence(fence) == 0,
+"Failure waiting on fence\n");
+ }
+
+ /* Every producer increments the counter, the consumer
+* checks and erases it
+*/
+ pthread_mutex_lock(&test_mpsc_data.lock);
+ test_mpsc_data.counter++;
+ pthread_mutex_unlock(&test_mpsc_data.lock);
+
+ sw_sync_timeline_inc(prod_timeline[id], 1);
+ sw_sync_fence_destroy(fence);
+ }
+
+ return 0;
+}
+
+static int mpsc_consumer_thread(void)
+{
+ int fence, merged, tmp, it, i;
+ int *prod_timeline = test_mpsc_data.prod_timeline;
+ int cons_timeline = test_mpsc_data.cons_timeline;
+ int iterations = test_mpsc_data.iterations;
+ int n = test_mpsc_data.threads;
+
+ for (it = 1; it <= iterations; it++) {
+ fence = sw_sync_fence_create(prod_timeline[0], it);
+ for (i = 1; i < n; i++) {
+ tmp = sw_sync_fence_create(prod_timeline[i], it);
+ merged = sw_sync_merge(tmp, fence);
+ sw_sync_fence_destroy(tmp);
+ sw_sync_fence_destroy(fence);
+ fence = merged;
+ }
+
+ /* Make sure we see an increment from every producer thread.
+* Vary the means by which we wait.
+*/
+ if (iterations % 8 != 0) {
+ igt_assert_f(sw_sync_wait(fence, -1) == 0,
+ "Producers did not increment as
expected\n");
+ } else {
+ igt_assert_f(test_mspc_wait_on_fence(fence) == 0,
+"Failure waiting on fence\n");
+ }
+
+ igt_assert_f(test_mpsc_data.counter == n * it,
+"Counter value mismatch\n");
+
+ /* Release the producer threads */
+ sw_sync_timeline_inc(cons_timeline, 1);
+ sw_sync_fence_destroy(fence);
+ }
+
+ return 0;
+}
+
+/* IMPORTANT NOTE: if you see this test failing on your system, it may be
+ * due to a shortage of file descriptors. Please ensure your system has
+ * a sensible limit for this test to finish correctly.
+ */
+static void test_sync_multi_producer_single_consumer(void)
+{
+ int iterations = 1 << 12;
+ int n = 5;
+ int prod_timeline[n];
+ int cons_timeline;
+ pthread_t threads[n];
+ long i;
+
+ cons_timeline = sw_sync_timeline_create();
+ for (i = 0; i < n; i++)
+ prod_timeline[i] = sw_sync_timeline_create();
+
+ test_mpsc_data.prod_timeline = prod_timeline;
+ test_mpsc_data.cons_timeline = cons_timeline;
+ test_mpsc_data.iterations = iterations;
+ test_mpsc_data.threads = n;
+ test_mpsc_data.counter = 0;
+
[Intel-gfx] [PATCH v2 5/13] tests/sw_sync: Add subtest test_alloc_merge_fence
From: Robert Foss
This subtest verifies that merging two fences works in the simples possible
case.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 23 +++
1 file changed, 23 insertions(+), 0 deletions(-)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 102647d..851430e 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -60,6 +60,26 @@ static void test_alloc_fence_invalid_timeline(void)
sw_sync_fence_create(-1, 0);
}
+static void test_alloc_merge_fence(void)
+{
+ int in_fence[2];
+ int fence_merge;
+ int timeline[2];
+
+ timeline[0] = sw_sync_timeline_create();
+ timeline[1] = sw_sync_timeline_create();
+
+ in_fence[0] = sw_sync_fence_create(timeline[0], 1);
+ in_fence[1] = sw_sync_fence_create(timeline[1], 1);
+ fence_merge = sw_sync_merge(in_fence[1], in_fence[0]);
+
+ sw_sync_fence_destroy(in_fence[0]);
+ sw_sync_fence_destroy(in_fence[1]);
+ sw_sync_fence_destroy(fence_merge);
+ sw_sync_timeline_destroy(timeline[0]);
+ sw_sync_timeline_destroy(timeline[1]);
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -70,5 +90,8 @@ igt_main
igt_subtest("alloc_fence_invalid_timeline")
test_alloc_fence_invalid_timeline();
+
+ igt_subtest("alloc_merge_fence")
+ test_alloc_merge_fence();
}
--
git-series 0.8.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 7/13] tests/sw_sync: Add subtest test_sync_merge
From: Robert Foss
Add subtest test_sync_merge that tests merging fences and the validity of the
resulting merged fence.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 67 ++-
1 file changed, 67 insertions(+), 0 deletions(-)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 07e9638..00ac44b 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -115,6 +115,70 @@ static void test_sync_wait(void)
sw_sync_timeline_destroy(timeline);
}
+static void test_sync_merge(void)
+{
+ int in_fence[3];
+ int fence_merge;
+ int timeline;
+ int active, signaled;
+
+ timeline = sw_sync_timeline_create();
+ in_fence[0] = sw_sync_fence_create(timeline, 1);
+ in_fence[1] = sw_sync_fence_create(timeline, 2);
+ in_fence[2] = sw_sync_fence_create(timeline, 3);
+
+ fence_merge = sw_sync_merge(in_fence[0], in_fence[1]);
+ fence_merge = sw_sync_merge(in_fence[2], fence_merge);
+
+ /* confirm all fences have one active point (even d) */
+ active = sw_sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 1, "in_fence[0] has too many active fences\n");
+ active = sw_sync_fence_count_status(in_fence[1],
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 1, "in_fence[1] has too many active fences\n");
+ active = sw_sync_fence_count_status(in_fence[2],
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 1, "in_fence[2] has too many active fences\n");
+ active = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 1, "fence_merge has too many active fences\n");
+
+ /* confirm that fence_merge is not signaled until the max of fence
0,1,2 */
+ sw_sync_timeline_inc(timeline, 1);
+ signaled = sw_sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ active = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(signaled == 1, "in_fence[0] did not signal\n");
+ igt_assert_f(active == 1, "fence_merge signaled too early\n");
+
+ sw_sync_timeline_inc(timeline, 1);
+ signaled = sw_sync_fence_count_status(in_fence[1],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ active = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(signaled == 1, "in_fence[1] did not signal\n");
+ igt_assert_f(active == 1, "fence_merge signaled too early\n");
+
+ sw_sync_timeline_inc(timeline, 1);
+ signaled = sw_sync_fence_count_status(in_fence[2],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ igt_assert_f(signaled == 1, "in_fence[2] did not signal\n");
+ signaled = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ active = sw_sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_ACTIVE);
+ igt_assert_f(active == 0 && signaled == 1,
+"fence_merge did not signal\n");
+
+ sw_sync_fence_destroy(in_fence[0]);
+ sw_sync_fence_destroy(in_fence[1]);
+ sw_sync_fence_destroy(in_fence[2]);
+ sw_sync_fence_destroy(fence_merge);
+ sw_sync_timeline_destroy(timeline);
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -131,5 +195,8 @@ igt_main
igt_subtest("sync_wait")
test_sync_wait();
+
+ igt_subtest("sync_merge")
+ test_sync_merge();
}
--
git-series 0.8.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 8/13] tests/sw_sync: Add subtest test_sync_merge_same
From: Robert Foss
This subtest verifies merging a fence with itself does not fail.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 27 +++
1 file changed, 27 insertions(+), 0 deletions(-)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 00ac44b..db03f48 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -179,6 +179,30 @@ static void test_sync_merge(void)
sw_sync_timeline_destroy(timeline);
}
+static void test_sync_merge_same(void)
+{
+ int in_fence[2];
+ int timeline;
+ int signaled;
+
+ timeline = sw_sync_timeline_create();
+ in_fence[0] = sw_sync_fence_create(timeline, 1);
+ in_fence[1] = sw_sync_merge(in_fence[0], in_fence[0]);
+
+ signaled = sw_sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ igt_assert_f(signaled == 0, "fence signaled too early\n");
+
+ sw_sync_timeline_inc(timeline, 1);
+ signaled = sw_sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+ igt_assert_f(signaled == 1, "fence did not signal\n");
+
+ sw_sync_fence_destroy(in_fence[0]);
+ sw_sync_fence_destroy(in_fence[1]);
+ sw_sync_timeline_destroy(timeline);
+}
+
igt_main
{
igt_subtest("alloc_timeline")
@@ -198,5 +222,8 @@ igt_main
igt_subtest("sync_merge")
test_sync_merge();
+
+ igt_subtest("sync_merge_same")
+ test_sync_merge_same();
}
--
git-series 0.8.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/13] tests/sw_sync: Add sw_sync test
From: Robert Foss
Add initial tests for sw_sync.
Signed-off-by: Robert Foss
Signed-off-by: Gustavo Padovan
Reviewed-by: Eric Engestrom
---
tests/Makefile.sources | 1 +-
tests/sw_sync.c| 51 +++-
2 files changed, 52 insertions(+), 0 deletions(-)
create mode 100644 tests/sw_sync.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 72a58ad..0ba769f 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -125,6 +125,7 @@ TESTS_progs_M = \
prime_mmap_kms \
prime_self_import \
prime_vgem \
+ sw_sync \
template \
vgem_basic \
vgem_slow \
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
new file mode 100644
index 000..d2d4c42
--- /dev/null
+++ b/tests/sw_sync.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright 2012 Google, Inc
+ * Copyright © 2016 Collabora, Ltd.
+ *
+ * Based on the implementation from the Android Open Source Project
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Robert Foss
+ */
+
+#include
+
+#include "sw_sync.h"
+#include "igt.h"
+#include "igt_aux.h"
+
+IGT_TEST_DESCRIPTION("Test SW Sync Framework");
+
+static void test_alloc_timeline(void)
+{
+ int timeline;
+
+ timeline = sw_sync_timeline_create();
+ sw_sync_timeline_destroy(timeline);
+}
+
+igt_main
+{
+ igt_subtest("alloc_timeline")
+ test_alloc_timeline();
+}
+
--
git-series 0.8.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/13] lib/sw_sync: Add helper functions for managing synchronization primitives
From: Robert Foss
Base functions to help testing the Sync File Framework (explicit fencing
mechanism ported from Android).
These functions allow you to create, use and destroy timelines and fences.
Signed-off-by: Gustavo Padovan
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
lib/Makefile.sources | 2 +-
lib/sw_sync.c| 237 -
lib/sw_sync.h| 49 +-
3 files changed, 288 insertions(+), 0 deletions(-)
create mode 100644 lib/sw_sync.c
create mode 100644 lib/sw_sync.h
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index bac9a7f..3dc7c3c 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -61,6 +61,8 @@ lib_source_list = \
rendercopy_gen8.c \
rendercopy_gen9.c \
rendercopy.h\
+ sw_sync.c \
+ sw_sync.h \
intel_reg_map.c \
intel_iosf.c\
igt_kms.c \
diff --git a/lib/sw_sync.c b/lib/sw_sync.c
new file mode 100644
index 000..179a473
--- /dev/null
+++ b/lib/sw_sync.c
@@ -0,0 +1,237 @@
+/*
+ * Copyright 2012 Google, Inc
+ * Copyright © 2016 Collabora, Ltd.
+ *
+ * Based on the implementation from the Android Open Source Project
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Robert Foss
+ */
+
+#ifndef ANDROID
+#define _GNU_SOURCE
+#else
+#include
+#endif
+#include
+#include
+#include
+#include
+#include
+
+#include "sw_sync.h"
+#include "drmtest.h"
+#include "ioctl_wrappers.h"
+
+#ifndef SW_SYNC_IOC_INC
+struct sw_sync_create_fence_data {
+ __u32 value;
+ charname[32];
+ __s32 fence;
+};
+
+#define SW_SYNC_IOC_MAGIC 'W'
+#define SW_SYNC_IOC_CREATE_FENCE _IOWR(SW_SYNC_IOC_MAGIC, 0,\
+ struct
sw_sync_create_fence_data)
+#define SW_SYNC_IOC_INC_IOW(SW_SYNC_IOC_MAGIC, 1,
__u32)
+#endif
+
+#define DEVFS_SW_SYNC "/dev/sw_sync"
+#define DEBUGFS_SW_SYNC "/sys/kernel/debug/sync/sw_sync"
+
+
+int sw_sync_fd_is_valid(int fd)
+{
+ int status;
+
+ if (fd < 0)
+ return 0;
+
+ status = fcntl(fd, F_GETFD, 0);
+ return status >= 0;
+}
+
+static
+void sw_sync_fd_close(int fd)
+{
+ if (!sw_sync_fd_is_valid(fd))
+ return;
+
+ close(fd);
+}
+
+int sw_sync_timeline_create(void)
+{
+ int fd = open(DEVFS_SW_SYNC, O_RDWR);
+
+ if (!sw_sync_fd_is_valid(fd))
+ fd = open(DEBUGFS_SW_SYNC, O_RDWR);
+
+ igt_assert(sw_sync_fd_is_valid(fd));
+
+ return fd;
+}
+
+void sw_sync_timeline_destroy(int fd)
+{
+ return sw_sync_fd_close(fd);
+}
+
+void sw_sync_fence_destroy(int fd)
+{
+ return sw_sync_fd_close(fd);
+}
+
+int sw_sync_fence_create(int fd, int32_t seqno)
+{
+ struct sw_sync_create_fence_data data = {};
+ data.value = seqno;
+
+ if (fd >= 0) {
+ do_ioctl(fd, SW_SYNC_IOC_CREATE_FENCE, &data);
+ return data.fence;
+ } else {
+ do_ioctl_err(fd, SW_SYNC_IOC_CREATE_FENCE, &data, EBADF);
+ return -1;
+ }
+}
+
+void sw_sync_timeline_inc(int fd, uint32_t count)
+{
+ uint32_t arg = count;
+
+ if (fd == 0 || fd == -1)
+ return;
+
+ do_ioctl(fd, SW_SYNC_IOC_INC, &arg);
+}
+
+int sw_sync_merge(int fd1, int fd2)
+{
+ struct sync_merge_data data = {};
+ int err;
+
+ data.fd2 = fd2;
+
+ err = ioctl(fd1, SYNC_IOC_MERGE, &data);
+ if (err < 0)
+ return err;
+
+ sw_sync_fd_is_valid(data.fence);
+
+ return data.fence;
+}
+
+int sw_sync_wait(int fence, int timeout)
+{
+ struct pollfd fds;
+ int ret;
+
+ fds.fd = fence;
+ fds.events = POLLIN | POLLERR;
+
+ ret = poll(&fds, 1, ti
[Intel-gfx] [PATCH v2 3/13] tests/sw_sync: Add subtest test_alloc_fence
From: Robert Foss
Add subtest alloc_fence that verifies that it's possible to allocate a fence
on a timeline.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 16
1 file changed, 16 insertions(+), 0 deletions(-)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index d2d4c42..a8c8ca4 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -43,9 +43,25 @@ static void test_alloc_timeline(void)
sw_sync_timeline_destroy(timeline);
}
+static void test_alloc_fence(void)
+{
+ int in_fence;
+ int timeline;
+
+ timeline = sw_sync_timeline_create();
+ in_fence = sw_sync_fence_create(timeline, 0);
+
+ sw_sync_fence_destroy(in_fence);
+ sw_sync_timeline_destroy(timeline);
+}
+
+
igt_main
{
igt_subtest("alloc_timeline")
test_alloc_timeline();
+
+ igt_subtest("alloc_fence")
+ test_alloc_fence();
}
--
git-series 0.8.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/13] Implement sw_sync test
From: Robert Foss This series implements the sw_sync test and the lib/sw_sync helper functions for said test. Gustavo Padovans sw_sync series was just de-staged in gregkh-staging/staging-next [1], and this test is targeted at verifying the functionality implemented in that series. The sw_sync subtests range from very basic tests of the sw_sync functionality, to stress testing and randomized tests. [1] http://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/ Changes since v1: Added "Reviewed-by: Eric Engestrom " tag lib/sw_sync: - Fixed fd value checking - Fixed fd validity check in sw_sync_fd_close() - Moved sw_sync related paths to define - Switched from malloc+memset to calloc in sync_file_info() - Switched sizeof to dereferenced ptr tests/sw_sync: - Moved lib/sw_sync related code to lib/sw_sync commit - Replaced memset with assignment in loop Robert Foss (13): lib/sw_sync: Add helper functions for managing synchronization primitives tests/sw_sync: Add sw_sync test tests/sw_sync: Add subtest test_alloc_fence tests/sw_sync: Add subtest test_alloc_fence_invalid_timeline tests/sw_sync: Add subtest test_alloc_merge_fence tests/sw_sync: Add subtest test_sync_wait tests/sw_sync: Add subtest test_sync_merge tests/sw_sync: Add subtest test_sync_merge_same tests/sw_sync: Add subtest test_sync_multi_consumer tests/sw_sync: Add subtest test_sync_multi_consumer_producer tests/sw_sync: Add subtest test_sync_random_merge tests/sw_sync: Add subtest test_sync_multi_timeline_wait tests/sw_sync: Add subtest test_sync_multi_producer_single_consumer lib/Makefile.sources | 2 +- lib/sw_sync.c | 237 ++- lib/sw_sync.h | 49 +++- tests/Makefile.sources | 1 +- tests/sw_sync.c| 693 ++- 5 files changed, 982 insertions(+), 0 deletions(-) create mode 100644 lib/sw_sync.c create mode 100644 lib/sw_sync.h create mode 100644 tests/sw_sync.c -- git-series 0.8.10 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH v1 00/13] Implement sw_sync test
On 2016-08-23 06:56 PM, Eric Engestrom wrote: On Tue, Aug 23, 2016 at 01:56:02PM -0400, robert.f...@collabora.com wrote: From: Robert Foss This series implements the sw_sync test and the lib/sw_sync helper functions for said test. Gustavo Padovans sw_sync series was just de-staged in gregkh-staging/staging-next [1], and this test is targeted at verifying the functionality implemented in that series. The sw_sync subtests range from very basic tests of the sw_sync functionality, to stress testing and randomized tests. [1] http://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/ Robert Foss (13): lib/sw_sync: Add helper functions for managing synchronization primitives tests/sw_sync: Add sw_sync test tests/sw_sync: Add subtest test_alloc_fence tests/sw_sync: Add subtest test_alloc_fence_invalid_timeline tests/sw_sync: Add subtest test_alloc_merge_fence tests/sw_sync: Add subtest test_sync_wait tests/sw_sync: Add subtest test_sync_merge tests/sw_sync: Add subtest test_sync_merge_same tests/sw_sync: Add subtest test_sync_multi_consumer tests/sw_sync: Add subtest test_sync_multi_consumer_producer tests/sw_sync: Add subtest test_sync_random_merge tests/sw_sync: Add subtest test_sync_multi_timeline_wait tests/sw_sync: Add subtest test_sync_multi_producer_single_consumer lib/Makefile.sources | 2 + lib/sw_sync.c | 237 + lib/sw_sync.h | 49 tests/Makefile.sources | 1 + tests/sw_sync.c| 693 + 5 files changed, 982 insertions(+) create mode 100644 lib/sw_sync.c create mode 100644 lib/sw_sync.h create mode 100644 tests/sw_sync.c -- 2.7.4 Thanks for your work! I sent some specific comments directly to a few patches, but everything else looks good to me. With the issues raised in patches 1 & 2 fixed (and with or without my suggestions), the whole series is: Reviewed-by: Eric Engestrom Cheers, Eric Thanks for the quick feedback! All of the suggested changes have been fixed for v2, which is upcoming. Rob. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Flush to GTT domain all GGTT bound objects after hibernation
== Series Details == Series: drm/i915: Flush to GTT domain all GGTT bound objects after hibernation URL : https://patchwork.freedesktop.org/series/11532/ State : failure == Summary == Series 11532v1 drm/i915: Flush to GTT domain all GGTT bound objects after hibernation http://patchwork.freedesktop.org/api/1.0/series/11532/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> INCOMPLETE (fi-skl-6700k) pass -> INCOMPLETE (fi-bdw-5557u) pass -> INCOMPLETE (fi-bsw-n3050) pass -> INCOMPLETE (fi-ivb-3520m) dmesg-warn -> INCOMPLETE (fi-snb-2520m) pass -> INCOMPLETE (fi-skl-6260u) pass -> INCOMPLETE (fi-hsw-4770r) dmesg-warn -> INCOMPLETE (fi-snb-2600) pass -> INCOMPLETE (fi-hsw-4770k) fi-bdw-5557u total:107 pass:98 dwarn:0 dfail:0 fail:0 skip:8 fi-bsw-n3050 total:107 pass:83 dwarn:0 dfail:0 fail:0 skip:23 fi-hsw-4770k total:107 pass:91 dwarn:0 dfail:0 fail:0 skip:15 fi-hsw-4770r total:107 pass:87 dwarn:0 dfail:0 fail:0 skip:19 fi-ivb-3520m total:107 pass:84 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:107 pass:98 dwarn:0 dfail:0 fail:0 skip:8 fi-skl-6700k total:107 pass:84 dwarn:0 dfail:0 fail:0 skip:22 fi-snb-2520m total:107 pass:75 dwarn:2 dfail:0 fail:0 skip:29 fi-snb-2600 total:107 pass:75 dwarn:2 dfail:0 fail:0 skip:29 Results at /archive/results/CI_IGT_test/Patchwork_2424/ e14363ed1c12c86726914e3a790662e84e631c37 drm-intel-nightly: 2016y-08m-24d-18h-39m-56s UTC integration manifest 4f2c78e drm/i915: Flush to GTT domain all GGTT bound objects after hibernation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] i965: Embrace "unlimited" GTT mmap support
From about kernel 4.9, GTT mmaps are virtually unlimited. A new
parameter, I915_PARAM_MMAP_GTT_VERSION, is added to advertise the
feature so query it and use it to avoid limiting tiled allocations to
only fit within the mappable aperture.
Signed-off-by: Chris Wilson
Cc: Kenneth Graunke
---
src/mesa/drivers/dri/i965/brw_context.c | 17 ++---
src/mesa/drivers/dri/i965/brw_context.h | 2 +-
src/mesa/drivers/dri/i965/intel_screen.c | 32
src/mesa/drivers/dri/i965/intel_screen.h | 2 ++
4 files changed, 37 insertions(+), 16 deletions(-)
diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
index b0f9063..79dba1e 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -1033,21 +1033,6 @@ brwCreateContext(gl_api api,
brw->urb.max_ds_entries = devinfo->urb.max_ds_entries;
brw->urb.max_gs_entries = devinfo->urb.max_gs_entries;
- /* Estimate the size of the mappable aperture into the GTT. There's an
-* ioctl to get the whole GTT size, but not one to get the mappable subset.
-* It turns out it's basically always 256MB, though some ancient hardware
-* was smaller.
-*/
- uint32_t gtt_size = 256 * 1024 * 1024;
-
- /* We don't want to map two objects such that a memcpy between them would
-* just fault one mapping in and then the other over and over forever. So
-* we would need to divide the GTT size by 2. Additionally, some GTT is
-* taken up by things like the framebuffer and the ringbuffer and such, so
-* be more conservative.
-*/
- brw->max_gtt_map_object_size = gtt_size / 4;
-
if (brw->gen == 6)
brw->urb.gs_present = false;
@@ -1058,6 +1043,8 @@ brwCreateContext(gl_api api,
brw->predicate.state = BRW_PREDICATE_STATE_RENDER;
+ brw->max_gtt_map_object_size = screen->max_gtt_map_object_size;
+
brw->use_resource_streamer = screen->has_resource_streamer &&
(env_var_as_boolean("INTEL_USE_HW_BT", false) ||
env_var_as_boolean("INTEL_USE_GATHER", false));
diff --git a/src/mesa/drivers/dri/i965/brw_context.h
b/src/mesa/drivers/dri/i965/brw_context.h
index f2dd164..523f36c 100644
--- a/src/mesa/drivers/dri/i965/brw_context.h
+++ b/src/mesa/drivers/dri/i965/brw_context.h
@@ -861,7 +861,7 @@ struct brw_context
*/
bool perf_debug;
- uint32_t max_gtt_map_object_size;
+ uint64_t max_gtt_map_object_size;
int gen;
int gt;
diff --git a/src/mesa/drivers/dri/i965/intel_screen.c
b/src/mesa/drivers/dri/i965/intel_screen.c
index 98f1c76..62eacba 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.c
+++ b/src/mesa/drivers/dri/i965/intel_screen.c
@@ -1006,6 +1006,17 @@ intel_get_boolean(struct intel_screen *screen, int param)
return (intel_get_param(screen, param, &value) == 0) && value;
}
+static int
+intel_get_integer(struct intel_screen *screen, int param)
+{
+ int value = -1;
+
+ if (intel_get_param(screen, param, &value) == 0)
+ return value;
+
+ return -1;
+}
+
static void
intelDestroyScreen(__DRIscreen * sPriv)
{
@@ -1576,6 +1587,27 @@ __DRIconfig **intelInitScreen2(__DRIscreen *psp)
if (INTEL_DEBUG & DEBUG_AUB)
drm_intel_bufmgr_gem_set_aub_dump(intelScreen->bufmgr, true);
+#define I915_PARAM_MMAP_GTT_VERSION 40 /* XXX delete me with new libdrm */
+ if (intel_get_integer(intelScreen, I915_PARAM_MMAP_GTT_VERSION) >= 1) {
+ /* Theorectically unlimited! */
+ intelScreen->max_gtt_map_object_size = UINT64_MAX;
+ } else {
+ /* Estimate the size of the mappable aperture into the GTT. There's an
+ * ioctl to get the whole GTT size, but not one to get the mappable
subset.
+ * It turns out it's basically always 256MB, though some ancient hardware
+ * was smaller.
+ */
+ uint32_t gtt_size = 256 * 1024 * 1024;
+
+ /* We don't want to map two objects such that a memcpy between them would
+ * just fault one mapping in and then the other over and over forever.
So
+ * we would need to divide the GTT size by 2. Additionally, some GTT is
+ * taken up by things like the framebuffer and the ringbuffer and such,
so
+ * be more conservative.
+ */
+ intelScreen->max_gtt_map_object_size = gtt_size / 4;
+ }
+
intelScreen->hw_has_swizzling = intel_detect_swizzling(intelScreen);
intelScreen->hw_has_timestamp = intel_detect_timestamp(intelScreen);
diff --git a/src/mesa/drivers/dri/i965/intel_screen.h
b/src/mesa/drivers/dri/i965/intel_screen.h
index 35cd5df..fa806a3 100644
--- a/src/mesa/drivers/dri/i965/intel_screen.h
+++ b/src/mesa/drivers/dri/i965/intel_screen.h
@@ -44,6 +44,8 @@ struct intel_screen
__DRIscreen *driScrnPriv;
+ uint64_t max_gtt_map_object_size;
+
bool no_hw;
bool hw_has_swizzling;
bool has_fence_fd;
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https:/
[Intel-gfx] [PATCH] drm/i915: Add I915_PARAM_MMAP_GTT_VERSION to advertise unlimited mmaps
Now that we have working partial VMA and faulting support for all
objects, including fence support, advertise to userspace that it can
take advantage of unlimited GGTT mmaps.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 8
include/uapi/drm/i915_drm.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index fc9273215286..5b2c56777b75 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -355,6 +355,14 @@ static int i915_getparam(struct drm_device *dev, void
*data,
case I915_PARAM_MIN_EU_IN_POOL:
value = INTEL_INFO(dev)->min_eu_in_pool;
break;
+ case I915_PARAM_MMAP_GTT_VERSION:
+ /* 0 - Objects have to be smaller than aperture,
+* all simultaneous users have to fit within the
+* available space within the aperture.
+* 1 - Objects can any size, and X,Y or untiled
+*/
+ value = 1;
+ break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 5501fe83ed92..03725fe89859 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -387,6 +387,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_EXEC_SOFTPIN 37
#define I915_PARAM_HAS_POOLED_EU38
#define I915_PARAM_MIN_EU_IN_POOL 39
+#define I915_PARAM_MMAP_GTT_VERSION 40
typedef struct drm_i915_getparam {
__s32 param;
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Flush to GTT domain all GGTT bound objects after hibernation
Recently I have been applying an optimisation to avoid stalling and
clflushing GGTT objects based on their current binding. That is we only
set-to-gtt-domain upon first bind. However, on hibernation the objects
remain bound, but they are in the CPU domain. Currently (since commit
975f7ff42edf ("drm/i915: Lazily migrate the objects after hibernation"))
we only flush scanout objects as all other objects are expected to be
flushed prior to use. That breaks down in the face of the runtime
optimisation above - and we need to flush all GGTT pinned objects
(essentially ringbuffers).
To reduce the burden of extra clflushes, we only flush those objects we
cannot discard from the GGTT. Everything pinned to the scanout, or
current contexts or ringbuffers will be flushed and rebound. Other
objects, such as inactive contexts, will be left unbound and in the CPU
domain until first use after resuming.
Fixes: 7abc98fadfdd ("drm/i915: Only change the context object's domain...")
Fixes: 57e885318119 ("drm/i915: Use VMA for ringbuffer tracking")
References: https://bugs.freedesktop.org/show_bug.cgi?id=94722
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Cc: David Weinehall
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 570e7311a419..43054eeac9d7 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3243,20 +3243,30 @@ void i915_gem_restore_gtt_mappings(struct drm_device
*dev)
ggtt->base.clear_range(&ggtt->base, ggtt->base.start, ggtt->base.total,
true);
+ ggtt->base.closed = true; /* skip rewriting PTE on VMA unbind */
+
/* Cache flush objects bound into GGTT and rebind them. */
list_for_each_entry(obj, &dev_priv->mm.bound_list, global_list) {
+ bool ggtt_bound = false;
+
list_for_each_entry(vma, &obj->vma_list, obj_link) {
if (vma->vm != &ggtt->base)
continue;
+ if (!i915_vma_unbind(vma))
+ continue;
+
WARN_ON(i915_vma_bind(vma, obj->cache_level,
PIN_UPDATE));
+ ggtt_bound = true;
}
- if (obj->pin_display)
+ if (ggtt_bound)
WARN_ON(i915_gem_object_set_to_gtt_domain(obj, false));
}
+ ggtt->base.closed = false;
+
if (INTEL_INFO(dev)->gen >= 8) {
if (IS_CHERRYVIEW(dev) || IS_BROXTON(dev))
chv_setup_private_ppat(dev_priv);
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Revert "drm/i915/fbc: Allow on unfenced surfaces, for recent gen"
== Series Details == Series: Revert "drm/i915/fbc: Allow on unfenced surfaces, for recent gen" URL : https://patchwork.freedesktop.org/series/11529/ State : failure == Summary == Series 11529v1 Revert "drm/i915/fbc: Allow on unfenced surfaces, for recent gen" http://patchwork.freedesktop.org/api/1.0/series/11529/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-flip-vs-cursor-legacy: fail -> PASS (fi-hsw-4770k) Subgroup basic-flip-vs-cursor-varying-size: pass -> FAIL (fi-hsw-4770r) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-c: skip -> PASS (fi-hsw-4770r) fi-bdw-5557u total:252 pass:235 dwarn:0 dfail:0 fail:2 skip:15 fi-bsw-n3050 total:252 pass:203 dwarn:0 dfail:0 fail:3 skip:46 fi-hsw-4770k total:252 pass:222 dwarn:6 dfail:1 fail:1 skip:22 fi-hsw-4770r total:252 pass:223 dwarn:0 dfail:0 fail:3 skip:26 fi-ivb-3520m total:252 pass:220 dwarn:0 dfail:0 fail:1 skip:31 fi-skl-6260u total:252 pass:236 dwarn:0 dfail:0 fail:2 skip:14 fi-skl-6700k total:252 pass:216 dwarn:4 dfail:0 fail:4 skip:28 fi-snb-2520m total:252 pass:203 dwarn:4 dfail:0 fail:2 skip:43 fi-snb-2600 total:252 pass:203 dwarn:4 dfail:0 fail:2 skip:43 Results at /archive/results/CI_IGT_test/Patchwork_2423/ 6737eeadd55aa09ac998698461138309ab623dbb drm-intel-nightly: 2016y-08m-24d-15h-53m-53s UTC integration manifest a9aac28 Revert "drm/i915/fbc: Allow on unfenced surfaces, for recent gen" ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] Revert "drm/i915/fbc: Allow on unfenced surfaces, for recent gen"
This reverts commit 8678fdaf396c ("drm/i915/fbc: Allow on unfenced surfaces,
for recent gen") as Skylake has issues with unfenced FBC tracking (and
yes Skylake doesn't even enable FBC yet). Paulo would like to do a full
review of all existing workarounds to see if any more are missing prior
to allowing FBC on unfenced surfaces. In the meantime lets hope that all
framebuffers are idle and naturally fit within the mappable aperture.
Requested-by: Paulo Zanoni
Fixes: 8678fdaf396c ("drm/i915/fbc: Allow on unfenced surfaces...");
Cc: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index bf8b22ad9aed..faa67624e1ed 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -799,10 +799,8 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
*/
if (cache->fb.tiling_mode != I915_TILING_X ||
cache->fb.fence_reg == I915_FENCE_REG_NONE) {
- if (INTEL_GEN(dev_priv) < 5) {
- fbc->no_fbc_reason = "framebuffer not tiled or fenced";
- return false;
- }
+ fbc->no_fbc_reason = "framebuffer not tiled or fenced";
+ return false;
}
if (INTEL_INFO(dev_priv)->gen <= 4 && !IS_G4X(dev_priv) &&
cache->plane.rotation != DRM_ROTATE_0) {
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: fix comment referencing imaginary functions
== Series Details == Series: drm/i915: fix comment referencing imaginary functions URL : https://patchwork.freedesktop.org/series/11527/ State : failure == Summary == Series 11527v1 drm/i915: fix comment referencing imaginary functions http://patchwork.freedesktop.org/api/1.0/series/11527/revisions/1/mbox/ Test kms_cursor_legacy: Subgroup basic-cursor-vs-flip-varying-size: pass -> FAIL (fi-bsw-n3050) Subgroup basic-flip-vs-cursor-legacy: fail -> PASS (fi-hsw-4770k) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-b: pass -> SKIP (fi-hsw-4770r) Subgroup nonblocking-crc-pipe-c: skip -> PASS (fi-hsw-4770r) Subgroup read-crc-pipe-c: pass -> SKIP (fi-hsw-4770r) fi-bdw-5557u total:252 pass:235 dwarn:0 dfail:0 fail:2 skip:15 fi-bsw-n3050 total:252 pass:202 dwarn:0 dfail:0 fail:4 skip:46 fi-hsw-4770k total:252 pass:222 dwarn:6 dfail:1 fail:1 skip:22 fi-hsw-4770r total:252 pass:222 dwarn:0 dfail:0 fail:2 skip:28 fi-ivb-3520m total:252 pass:220 dwarn:0 dfail:0 fail:1 skip:31 fi-skl-6260u total:252 pass:236 dwarn:0 dfail:0 fail:2 skip:14 fi-skl-6700k total:252 pass:216 dwarn:4 dfail:0 fail:4 skip:28 fi-snb-2520m total:252 pass:203 dwarn:4 dfail:0 fail:2 skip:43 fi-snb-2600 total:252 pass:203 dwarn:4 dfail:0 fail:2 skip:43 Results at /archive/results/CI_IGT_test/Patchwork_2422/ 6737eeadd55aa09ac998698461138309ab623dbb drm-intel-nightly: 2016y-08m-24d-15h-53m-53s UTC integration manifest a58a4c2 drm/i915: fix comment referencing imaginary functions ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix comment referencing imaginary functions
The comment which documents the proper usage of the *_FW family of macros makes
reference to intel_uncore_forcewake_irq{unlock, lock}, which is just
confusing, seeing as such a set of functions don't even exist and never have
for that matter(according to git). Let's fix that by replacing them with
intel_uncore_forcewake_{get, put}.
Cc: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ff96b7a..c285d61 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3792,8 +3792,8 @@ __raw_write(64, q)
* critical sections inside IRQ handlers where forcewake is explicitly
* controlled.
* Think twice, and think again, before using these.
- * Note: Should only be used between intel_uncore_forcewake_irqlock() and
- * intel_uncore_forcewake_irqunlock().
+ * Note: Should only be used between intel_uncore_forcewake_get and
+ * intel_uncore_forcewake_put.
*/
#define I915_READ_FW(reg__) __raw_i915_read32(dev_priv, (reg__))
#define I915_WRITE_FW(reg__, val__) __raw_i915_write32(dev_priv, (reg__),
(val__))
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/17] drm/i915: Use the precomputed value for whether to enable command parsing
On 22/08/2016 09:03, Chris Wilson wrote:
As i915.enable_cmd_parser is an unsafe option, make it read-only at
runtime. Now that it is constant, we can use the value determined during
initialisation as to whether we need the cmdparser at execbuffer time.
I'm confused. I can't see where i915.enable_cmd_parse is used now. It
does not appear to be mentioned anywhere other than i915_params.c after
this patch. It is not used to calculate engine->needs_cmd_parser. There
also seems to be no longer a check for PPGTT either.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 21 -
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_params.c | 6 +++---
drivers/gpu/drm/i915/i915_params.h | 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 15 +++
5 files changed, 19 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 3c72b3b103e7..f749c8b52351 100644
--- a/drivers/gpu/drm/i915/i915_cmd_parser.c
+++ b/drivers/gpu/drm/i915/i915_cmd_parser.c
@@ -1036,27 +1036,6 @@ unpin_src:
return dst;
}
-/**
- * intel_engine_needs_cmd_parser() - should a given engine use software
- * command parsing?
- * @engine: the engine in question
- *
- * Only certain platforms require software batch buffer command parsing, and
- * only when enabled via module parameter.
- *
- * Return: true if the engine requires software command parsing
- */
-bool intel_engine_needs_cmd_parser(struct intel_engine_cs *engine)
-{
- if (!engine->needs_cmd_parser)
- return false;
-
- if (!USES_PPGTT(engine->i915))
- return false;
-
- return (i915.enable_cmd_parser == 1);
-}
-
static bool check_cmd(const struct intel_engine_cs *engine,
const struct drm_i915_cmd_descriptor *desc,
const u32 *cmd, u32 length,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 5613f2886ad3..049ac53b05da 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3603,7 +3603,6 @@ const char *i915_cache_level_str(struct drm_i915_private
*i915, int type);
int i915_cmd_parser_get_version(struct drm_i915_private *dev_priv);
void intel_engine_init_cmd_parser(struct intel_engine_cs *engine);
void intel_engine_cleanup_cmd_parser(struct intel_engine_cs *engine);
-bool intel_engine_needs_cmd_parser(struct intel_engine_cs *engine);
int intel_engine_cmd_parser(struct intel_engine_cs *engine,
struct drm_i915_gem_object *batch_obj,
struct drm_i915_gem_object *shadow_batch_obj,
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index e72a41223535..5879a7eae6cc 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -50,7 +50,7 @@ struct i915_params i915 __read_mostly = {
.error_capture = true,
.invert_brightness = 0,
.disable_display = 0,
- .enable_cmd_parser = 1,
+ .enable_cmd_parser = true,
.use_mmio_flip = 0,
.mmio_debug = 0,
.verbose_state_checks = 1,
@@ -187,9 +187,9 @@ MODULE_PARM_DESC(invert_brightness,
module_param_named(disable_display, i915.disable_display, bool, 0400);
MODULE_PARM_DESC(disable_display, "Disable display (default: false)");
-module_param_named_unsafe(enable_cmd_parser, i915.enable_cmd_parser, int, 0600);
+module_param_named_unsafe(enable_cmd_parser, i915.enable_cmd_parser, bool,
0400);
MODULE_PARM_DESC(enable_cmd_parser,
-"Enable command parsing (1=enabled [default], 0=disabled)");
+"Enable command parsing (true=enabled [default],
false=disabled)");
module_param_named_unsafe(use_mmio_flip, i915.use_mmio_flip, int, 0600);
MODULE_PARM_DESC(use_mmio_flip,
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 94efc899c1ef..ad0b1d280c2b 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -44,7 +44,6 @@ struct i915_params {
int disable_power_well;
int enable_ips;
int invert_brightness;
- int enable_cmd_parser;
int enable_guc_loading;
int enable_guc_submission;
int guc_log_level;
@@ -53,6 +52,7 @@ struct i915_params {
int edp_vswing;
unsigned int inject_load_failure;
/* leave bools at the end to not create holes */
+ bool enable_cmd_parser;
bool enable_hangcheck;
bool fastboot;
bool prefault_disable;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 84aea549de5d..c8cbe61deece 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -368,6 +368,21 @@ intel_engine_flag(const struct inte
Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: Allow on unfenced surfaces, for recent gen
Em Qua, 2016-08-24 às 07:43 +0100, Chris Wilson escreveu: > On Mon, Aug 22, 2016 at 09:39:17PM -0300, Paulo Zanoni wrote: > > > > 2016-08-18 5:21 GMT-03:00 Chris Wilson : > > > > > > Only fbc1 is tied to using a fence. Later iterations of fbc are > > > more > > > flexible and allow operation on unfenced frontbuffers. > > > > > > Signed-off-by: Chris Wilson > > > Cc: Daniel Vetter > > > Cc: "Zanoni, Paulo R" > > > > Hi > > > > I see this patch was applied. Now, on my Skylake machine, if I boot > > with i915.enable_fbc=1 I'll get FIFO underruns under fbcon. Just > > booting already gives me a FIFO underrun message, and then if I > > "sudo > > systemctl stop lightdm" I'll get a constantly-blinking screen. > > > > Of course, applying the patch that disables FBC after a FIFO > > underrun > > will help stopping the ever-blinking fbcon, but I think we should > > try > > to avoid the underruns in the places we know we can, and leave the > > "disable FBC on FIFO underruns" just for the cases we're not > > expecting. > > > > Also, please remember that I mentioned there are FBC workarounds > > for > > untiled that we still don't implement (although when I re-read my > > email it may sound like I suggested the workarounds are for non-GTT > > tracking). IMHO this argument alone should > > have prevented this patch from being merged... > > > > Based on that, can we please revert this patch? I'm afraid some > > people > > would consider these underruns as blockers to enabling FBC, so it's > > probably better to enable FBC only on X tiled for now, and leave > > this > > for when we know how to prevent the underrun (possibly by > > implementing > > the missing WAs). > > Sure you can disable FBC - just note that typically framebuffers will > be > unfenced. So we need to investigate why the underruns are happening and implement the missing workarounds. But IMHO while that's still not happening, tem porarily reverting the patch seems to be the way to keep the codebase sane. > -Chris > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] igt/kms_cursor_legacy: Reduce scope of basic-cursor-vs-flip
On Wed, Aug 24, 2016 at 03:16:15PM +0100, Chris Wilson wrote: > On Wed, Aug 24, 2016 at 03:06:25PM +0100, Chris Wilson wrote: > > Since we are experiencing too much noise in BAT from what just looks > > like scheduling delays in inspecting the vblank, reduce the basic test > > to the fundament: check that the cursor ioctl following the nonblocking > > fundametal While that sounds heavy enough, is it crazy to suggest fundamental instead? > > flip/modeset occurs within the same vblank. However, CI + debug builds > s/However/Hopefully/ > > are fast enough... Kind regards, David Weinehall ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt] igt/kms_cursor_legacy: Reduce scope of basic-cursor-vs-flip
On Wed, Aug 24, 2016 at 03:06:25PM +0100, Chris Wilson wrote: > Since we are experiencing too much noise in BAT from what just looks > like scheduling delays in inspecting the vblank, reduce the basic test > to the fundament: check that the cursor ioctl following the nonblocking fundametal > flip/modeset occurs within the same vblank. However, CI + debug builds s/However/Hopefully/ > are fast enough... -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] igt/kms_cursor_legacy: Reduce scope of basic-cursor-vs-flip
Since we are experiencing too much noise in BAT from what just looks
like scheduling delays in inspecting the vblank, reduce the basic test
to the fundament: check that the cursor ioctl following the nonblocking
flip/modeset occurs within the same vblank. However, CI + debug builds
are fast enough...
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: Maarten Lankhorst
---
tests/kms_cursor_legacy.c | 39 ++-
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/tests/kms_cursor_legacy.c b/tests/kms_cursor_legacy.c
index e0f39f7..785bf14 100644
--- a/tests/kms_cursor_legacy.c
+++ b/tests/kms_cursor_legacy.c
@@ -472,19 +472,21 @@ static void basic_flip_vs_cursor(igt_display_t *display,
enum flip_test mode, in
igt_display_commit2(display, display->is_atomic ? COMMIT_ATOMIC :
COMMIT_LEGACY);
- target = 4096;
- do {
- vblank_start = get_vblank(display->drm_fd, pipe,
DRM_VBLANK_NEXTONMISS);
- igt_assert_eq(get_vblank(display->drm_fd, pipe, 0),
vblank_start);
- for (int n = 0; n < target; n++)
- do_ioctl(display->drm_fd, DRM_IOCTL_MODE_CURSOR,
&arg[0]);
- target /= 2;
- if (get_vblank(display->drm_fd, pipe, 0) == vblank_start)
- break;
- } while (target);
- igt_require(target > 1);
+ if (nloops) {
+ target = 4096;
+ do {
+ vblank_start = get_vblank(display->drm_fd, pipe,
DRM_VBLANK_NEXTONMISS);
+ igt_assert_eq(get_vblank(display->drm_fd, pipe, 0),
vblank_start);
+ for (int n = 0; n < target; n++)
+ do_ioctl(display->drm_fd,
DRM_IOCTL_MODE_CURSOR, &arg[0]);
+ target /= 2;
+ if (get_vblank(display->drm_fd, pipe, 0) ==
vblank_start)
+ break;
+ } while (target);
+ igt_require(target > 1);
- igt_debug("Using a target of %d cursor updates per half-vblank\n",
target);
+ igt_debug("Using a target of %d cursor updates per
half-vblank\n", target);
+ }
vblank_start = get_vblank(display->drm_fd, pipe, DRM_VBLANK_NEXTONMISS);
igt_assert_eq(get_vblank(display->drm_fd, pipe, 0), vblank_start);
@@ -492,11 +494,12 @@ static void basic_flip_vs_cursor(igt_display_t *display,
enum flip_test mode, in
do_ioctl(display->drm_fd, DRM_IOCTL_MODE_CURSOR, &arg[0]);
igt_assert_eq(get_vblank(display->drm_fd, pipe, 0), vblank_start);
- while (nloops--) {
- /* Start with a synchronous query to align with the vblank */
- vblank_start = get_vblank(display->drm_fd, pipe,
DRM_VBLANK_NEXTONMISS);
+ do {
+ /* Bind the cursor first to warm up */
do_ioctl(display->drm_fd, DRM_IOCTL_MODE_CURSOR, &arg[nloops &
1]);
+ /* Start with a synchronous query to align with the vblank */
+ vblank_start = get_vblank(display->drm_fd, pipe,
DRM_VBLANK_NEXTONMISS);
switch (mode) {
default:
flip_nonblocking(display, pipe, mode >=
flip_test_atomic, &fb_info);
@@ -507,16 +510,18 @@ static void basic_flip_vs_cursor(igt_display_t *display,
enum flip_test mode, in
break;
}
+ /* The nonblocking flip should not have delayed us */
igt_assert_eq(get_vblank(display->drm_fd, pipe, 0),
vblank_start);
for (int n = 0; n < target; n++)
do_ioctl(display->drm_fd, DRM_IOCTL_MODE_CURSOR,
&arg[nloops & 1]);
+ /* Nor should it have delayed the following cursor update */
igt_assert_eq(get_vblank(display->drm_fd, pipe, 0),
vblank_start);
igt_set_timeout(1, "Stuck page flip");
igt_ignore_warn(read(display->drm_fd, &vbl, sizeof(vbl)));
igt_assert_eq(get_vblank(display->drm_fd, pipe, 0),
vblank_start + 1);
igt_reset_timeout();
- }
+ } while (nloops--);
do_cleanup_display(display);
igt_remove_fb(display->drm_fd, &fb_info);
@@ -962,7 +967,7 @@ igt_main
}
igt_subtest_f("%sflip-vs-cursor-%s", prefix, modes[i])
- basic_flip_vs_cursor(&display, i, 8);
+ basic_flip_vs_cursor(&display, i, 0);
igt_subtest_f("long-flip-vs-cursor-%s", modes[i])
basic_flip_vs_cursor(&display, i, 150);
igt_subtest_f("%scursor-vs-flip-%s", prefix, modes[i])
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] gem_busy: Remove from android builds without cairo
I put a rule in the android make file a while back that automatically adds any test starting kms_ to the cairo dependant list, so kms_busy will not need to be listed explicitly. //Derek -Original Message- From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] Sent: Wednesday, August 24, 2016 2:47 PM To: Gore, Tim ; Morton, Derek J ; intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH i-g-t] gem_busy: Remove from android builds without cairo On Wed, Aug 24, 2016 at 04:25:06PM +0300, Marius Vlad wrote: > @Chris: I assume this is no longer necessary with the split to kms_busy? You probably want to change the gem_busy in this patch to kms_busy, so that kms_busy doesn't get built without cairo? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1 00/13] Implement sw_sync test
On 2016-08-24 02:01 AM, Daniel Vetter wrote: On Tue, Aug 23, 2016 at 01:56:02PM -0400, robert.f...@collabora.com wrote: From: Robert Foss This series implements the sw_sync test and the lib/sw_sync helper functions for said test. Gustavo Padovans sw_sync series was just de-staged in gregkh-staging/staging-next [1], and this test is targeted at verifying the functionality implemented in that series. The sw_sync subtests range from very basic tests of the sw_sync functionality, to stress testing and randomized tests. [1] http://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/ This seems to be patches against igt (but the series is lacking the i-g-t- subject tag per CONTRIBUTING). I'm ok with that, but I thought the idea was to merge these testcases into the kernel's selftests? Did the plan change? -Daniel Of course igt should've been added. I think a some miscommunication must've happened :) The kernel's selftests already does some of these tests, but apart from the sw_sync test, more subtests in kms_atomic and another test (kms_fence) are on scheduled for upstreaming. Since the kernel isn't really a great place for a testing framework, collecting all of this functionality in one place might make more sense. Robert Foss (13): lib/sw_sync: Add helper functions for managing synchronization primitives tests/sw_sync: Add sw_sync test tests/sw_sync: Add subtest test_alloc_fence tests/sw_sync: Add subtest test_alloc_fence_invalid_timeline tests/sw_sync: Add subtest test_alloc_merge_fence tests/sw_sync: Add subtest test_sync_wait tests/sw_sync: Add subtest test_sync_merge tests/sw_sync: Add subtest test_sync_merge_same tests/sw_sync: Add subtest test_sync_multi_consumer tests/sw_sync: Add subtest test_sync_multi_consumer_producer tests/sw_sync: Add subtest test_sync_random_merge tests/sw_sync: Add subtest test_sync_multi_timeline_wait tests/sw_sync: Add subtest test_sync_multi_producer_single_consumer lib/Makefile.sources | 2 + lib/sw_sync.c | 237 + lib/sw_sync.h | 49 tests/Makefile.sources | 1 + tests/sw_sync.c| 693 + 5 files changed, 982 insertions(+) create mode 100644 lib/sw_sync.c create mode 100644 lib/sw_sync.h create mode 100644 tests/sw_sync.c -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] gem_busy: Remove from android builds without cairo
On Wed, Aug 24, 2016 at 04:25:06PM +0300, Marius Vlad wrote: > @Chris: I assume this is no longer necessary with the split to kms_busy? You probably want to change the gem_busy in this patch to kms_busy, so that kms_busy doesn't get built without cairo? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree
On Wed, 24 Aug 2016, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the drm-intel tree got a conflict in: > > drivers/gpu/drm/i915/intel_display.c > > between commits from the drm-intel-fixes tree (some of which are > cherry-picked from the drm-intel tree) and teh same and other commits > from the drm-inte tree. These are just going to cause new conflicts > every time you touch this file again in either tree (which happens a > lot :-(). > > I fixed it up (see below) and can carry the fix as necessary. This > is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider only putting > the fix patches into the drm-intel-fixes tree and then getting them > into the drm-intel tree by merging the -fixes tree instead of > cherry-picking them the other way. We used to do that, but switched to the current model instead. The main reason was that we wanted our development branch to always get the fixes first, without delay. We have several committers, and we want to make it efficient and hassle free for them to get fixes applied. The drm-intel tree is a fast moving target. If we fix something in -fixes, there's no guarantee the fix applies to -next. It is more important that we get the fix in -next, and all future kernels. If the fix is important for current and stable kernels, we can do the backport. This way, we can always resolve conflicts with the code in -next, and be sure it contains all the fixes. If only -fixes had the fixes, we'd have nightmare conflict resolutions trying to ensure none of the fixes get dropped while merging. Finally, you don't always know in advance whether the patch should be applied to -next or -fixes. We'd end up with cherry-picks like this anyway. Now we can do QA on the fixes in -next, and choose the ones to backport. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/17] drm/i915: Drop spinlocks around adding to the client request list
On Wed, Aug 24, 2016 at 04:16:55PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
> > index 7b8abda541e6..e432211e8b24 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3673,16 +3673,14 @@ i915_gem_ring_throttle(struct drm_device *dev,
> > struct drm_file *file)
> > return -EIO;
> >
> > spin_lock(&file_priv->mm.lock);
> > - list_for_each_entry(request, &file_priv->mm.request_list, client_list) {
> > + list_for_each_entry(request, &file_priv->mm.request_list, client_link) {
> > if (time_after_eq(request->emitted_jiffies, recent_enough))
> > break;
> >
> > - /*
> > -* Note that the request might not have been submitted yet.
> > -* In which case emitted_jiffies will be zero.
> > -*/
> > - if (!request->emitted_jiffies)
> > - continue;
> > + if (target) {
> > + list_del(&target->client_link);
> > + target->file_priv = NULL;
>
> No need for list_for_each_entry_safe as we are throwing out stuff before
> the point of traversal?
Exactly, there is a very strict ordering here. We are deleting before
the cursor and we only ever add at the end (which is past the cursor).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] gem_busy: Remove from android builds without cairo
@Chris: I assume this is no longer necessary with the split to kms_busy? On Tue, Aug 23, 2016 at 09:44:14AM +, Gore, Tim wrote: > > > Tim Gore > Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ > > > > -Original Message- > > From: Morton, Derek J > > Sent: Tuesday, August 23, 2016 9:28 AM > > To: intel-gfx@lists.freedesktop.org > > Cc: Gore, Tim; Morton, Derek J > > Subject: [PATCH i-g-t] gem_busy: Remove from android builds without cairo > > > > The test has just developed cairo dependancies (or is at least now > > dependant on igt_kms.h) so add it to the list of tests that are only built > > if > > cairo is available. > > > > Signed-off-by: Derek Morton > > --- > > tests/Android.mk | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/tests/Android.mk b/tests/Android.mk index 3186a2a..74d6d47 > > 100644 > > --- a/tests/Android.mk > > +++ b/tests/Android.mk > > @@ -58,6 +58,7 @@ else > > gem_render_copy \ > > pm_lpsp \ > > drm_read \ > > + gem_busy \ > > gem_exec_blt \ > > prime_mmap_kms > > > > -- > > 1.9.1 > > Works for me. IGT builds on Android with this patch (minus the offending test > of course) > No impact for linux > Reviewed-by: Tim Gore > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Suppress DRM_ERROR for D_COMP write on Haswell
== Series Details == Series: drm/i915: Suppress DRM_ERROR for D_COMP write on Haswell URL : https://patchwork.freedesktop.org/series/11516/ State : failure == Summary == Series 11516v1 drm/i915: Suppress DRM_ERROR for D_COMP write on Haswell http://patchwork.freedesktop.org/api/1.0/series/11516/revisions/1/mbox/ Test gem_exec_gttfill: Subgroup basic: pass -> SKIP (fi-snb-2600) Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> PASS (fi-hsw-4770k) Test kms_cursor_legacy: Subgroup basic-flip-vs-cursor-legacy: pass -> FAIL (fi-skl-6700k) fail -> PASS (fi-hsw-4770k) pass -> FAIL (fi-bdw-5557u) Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-b: skip -> PASS (fi-hsw-4770r) Subgroup suspend-read-crc-pipe-a: dmesg-warn -> PASS (fi-hsw-4770k) Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (fi-hsw-4770k) Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (fi-hsw-4770k) Test pm_rpm: Subgroup basic-pci-d3-state: dmesg-warn -> PASS (fi-hsw-4770k) Subgroup basic-rte: dmesg-warn -> PASS (fi-hsw-4770k) Test prime_vgem: Subgroup basic-fence-flip: dmesg-fail -> FAIL (fi-hsw-4770k) fi-bdw-5557u total:252 pass:234 dwarn:0 dfail:0 fail:3 skip:15 fi-bsw-n3050 total:252 pass:203 dwarn:0 dfail:0 fail:3 skip:46 fi-byt-n2820 total:252 pass:205 dwarn:0 dfail:0 fail:5 skip:42 fi-hsw-4770k total:252 pass:228 dwarn:0 dfail:0 fail:2 skip:22 fi-hsw-4770r total:252 pass:224 dwarn:0 dfail:0 fail:2 skip:26 fi-ivb-3520m total:252 pass:220 dwarn:0 dfail:0 fail:1 skip:31 fi-skl-6260u total:252 pass:236 dwarn:0 dfail:0 fail:2 skip:14 fi-skl-6700k total:252 pass:216 dwarn:4 dfail:0 fail:4 skip:28 fi-snb-2520m total:252 pass:203 dwarn:4 dfail:0 fail:2 skip:43 fi-snb-2600 total:252 pass:202 dwarn:4 dfail:0 fail:2 skip:44 Results at /archive/results/CI_IGT_test/Patchwork_2421/ 03cfce0f8cf8f0664667f5f9b50560eeab16de37 drm-intel-nightly: 2016y-08m-24d-12h-19m-49s UTC integration manifest cd93864 drm/i915: Suppress DRM_ERROR for D_COMP write on Haswell ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/17] drm/i915: Amalgamate execbuffer parameter structures
On 22/08/2016 09:03, Chris Wilson wrote:
Combine the two slightly overlapping parameter structures we pass around
the execbuffer routines into one.
Should also include something about also renaming and refactoring the
eb_* / i915_gem_execbuffer_* helper functions too.
Also, while you are doing the rename/refactor, maybe add at least some
brief kerneldocs?
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 557 -
1 file changed, 235 insertions(+), 322 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 5689445b1cd3..7cb5b9ad9212 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -49,70 +49,73 @@
#define BATCH_OFFSET_BIAS (256*1024)
-struct i915_execbuffer_params {
- struct drm_device *dev;
- struct drm_file *file;
- struct i915_vma *batch;
- u32 dispatch_flags;
- u32 args_batch_start_offset;
- struct intel_engine_cs *engine;
- struct i915_gem_context *ctx;
- struct drm_i915_gem_request *request;
-};
-
-struct eb_vmas {
+struct i915_execbuffer {
struct drm_i915_private *i915;
+ struct drm_file *file;
+ struct drm_i915_gem_execbuffer2 *args;
+ struct drm_i915_gem_exec_object2 *exec;
+ struct intel_engine_cs *engine;
+ struct i915_gem_context *ctx;
+ struct i915_address_space *vm;
+ struct i915_vma *batch;
+ struct drm_i915_gem_request *request;
+ u32 batch_start_offset;
+ unsigned int dispatch_flags;
+ struct drm_i915_gem_exec_object2 shadow_exec_entry;
+ bool need_relocs;
struct list_head vmas;
+ struct reloc_cache {
+ struct drm_mm_node node;
+ unsigned long vaddr;
+ unsigned int page;
+ bool use_64bit_reloc;
+ } reloc_cache;
int and;
union {
- struct i915_vma *lut[0];
- struct hlist_head buckets[0];
+ struct i915_vma **lut;
+ struct hlist_head *buckets;
};
};
-static struct eb_vmas *
-eb_create(struct drm_i915_private *i915,
- struct drm_i915_gem_execbuffer2 *args)
+static int
+eb_create(struct i915_execbuffer *eb)
Would this be better called eb_create_vma_lut() or similar? It doesn't
create the eb itself (that is local to i915_gem_do_execbuffer) and all
the basic initialisation is outside as well.
{
- struct eb_vmas *eb = NULL;
-
- if (args->flags & I915_EXEC_HANDLE_LUT) {
- unsigned size = args->buffer_count;
+ eb->lut = NULL;
+ if (eb->args->flags & I915_EXEC_HANDLE_LUT) {
+ unsigned int size = eb->args->buffer_count;
size *= sizeof(struct i915_vma *);
- size += sizeof(struct eb_vmas);
- eb = kmalloc(size, GFP_TEMPORARY | __GFP_NOWARN |
__GFP_NORETRY);
+ eb->lut = kmalloc(size,
+ GFP_TEMPORARY | __GFP_NOWARN | __GFP_NORETRY);
}
- if (eb == NULL) {
- unsigned size = args->buffer_count;
- unsigned count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
+ if (!eb->lut) {
+ unsigned int size = eb->args->buffer_count;
+ unsigned int count = PAGE_SIZE / sizeof(struct hlist_head) / 2;
BUILD_BUG_ON_NOT_POWER_OF_2(PAGE_SIZE / sizeof(struct
hlist_head));
while (count > 2*size)
count >>= 1;
- eb = kzalloc(count*sizeof(struct hlist_head) +
-sizeof(struct eb_vmas),
-GFP_TEMPORARY);
- if (eb == NULL)
- return eb;
+ eb->lut = kzalloc(count*sizeof(struct hlist_head),
+ GFP_TEMPORARY);
+ if (!eb->lut)
+ return -ENOMEM;
eb->and = count - 1;
} else
- eb->and = -args->buffer_count;
+ eb->and = -eb->args->buffer_count;
- eb->i915 = i915;
INIT_LIST_HEAD(&eb->vmas);
- return eb;
+ return 0;
}
static void
-eb_reset(struct eb_vmas *eb)
+eb_reset(struct i915_execbuffer *eb)
{
if (eb->and >= 0)
memset(eb->buckets, 0, (eb->and+1)*sizeof(struct hlist_head));
}
static struct i915_vma *
-eb_get_batch(struct eb_vmas *eb)
+eb_get_batch(struct i915_execbuffer *eb)
{
struct i915_vma *vma = list_entry(eb->vmas.prev, typeof(*vma),
exec_list);
@@ -132,41 +135,37 @@ eb_get_batch(struct eb_vmas *eb)
}
static int
-eb_lookup_vmas(struct eb_vmas *eb,
- struct drm_i915_gem_exec_object2 *exec,
- const struct drm_i915_gem_ex
Re: [Intel-gfx] [PATCH 08/17] drm/i915: Drop spinlocks around adding to the client request list
Chris Wilson writes:
> Adding to the tail of the client request list as the only other user is
> in the throttle ioctl that iterates forwards over the list. It only
> needs protection against deletion of a request as it reads it, it simply
> won't see a new request added to the end of the list, or it would be too
> early and rejected. We can further reduce the number of spinlocks
> required when throttling by removing stale requests from the client_list
> as we throttle.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
> drivers/gpu/drm/i915/i915_gem.c| 14 ++--
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 14 +++-
> drivers/gpu/drm/i915/i915_gem_request.c| 34
> ++
> drivers/gpu/drm/i915/i915_gem_request.h| 4 +---
> 5 files changed, 23 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 086053fa2820..996744708f31 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -480,7 +480,7 @@ static int i915_gem_object_info(struct seq_file *m, void*
> data)
> mutex_lock(&dev->struct_mutex);
> request = list_first_entry_or_null(&file_priv->mm.request_list,
> struct drm_i915_gem_request,
> -client_list);
> +client_link);
> rcu_read_lock();
> task = pid_task(request && request->ctx->pid ?
> request->ctx->pid : file->pid,
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 7b8abda541e6..e432211e8b24 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3673,16 +3673,14 @@ i915_gem_ring_throttle(struct drm_device *dev, struct
> drm_file *file)
> return -EIO;
>
> spin_lock(&file_priv->mm.lock);
> - list_for_each_entry(request, &file_priv->mm.request_list, client_list) {
> + list_for_each_entry(request, &file_priv->mm.request_list, client_link) {
> if (time_after_eq(request->emitted_jiffies, recent_enough))
> break;
>
> - /*
> - * Note that the request might not have been submitted yet.
> - * In which case emitted_jiffies will be zero.
> - */
> - if (!request->emitted_jiffies)
> - continue;
> + if (target) {
> + list_del(&target->client_link);
> + target->file_priv = NULL;
No need for list_for_each_entry_safe as we are throwing out stuff before
the point of traversal?
Mika
> + }
>
> target = request;
> }
> @@ -4639,7 +4637,7 @@ void i915_gem_release(struct drm_device *dev, struct
> drm_file *file)
>* file_priv.
>*/
> spin_lock(&file_priv->mm.lock);
> - list_for_each_entry(request, &file_priv->mm.request_list, client_list)
> + list_for_each_entry(request, &file_priv->mm.request_list, client_link)
> request->file_priv = NULL;
> spin_unlock(&file_priv->mm.lock);
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 125fb38eff40..5689445b1cd3 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -1421,6 +1421,14 @@ out:
> return vma;
> }
>
> +static void
> +add_to_client(struct drm_i915_gem_request *req,
> + struct drm_file *file)
> +{
> + req->file_priv = file->driver_priv;
> + list_add_tail(&req->client_link, &req->file_priv->mm.request_list);
> +}
> +
> static int
> execbuf_submit(struct i915_execbuffer_params *params,
> struct drm_i915_gem_execbuffer2 *args,
> @@ -1512,6 +1520,7 @@ execbuf_submit(struct i915_execbuffer_params *params,
> trace_i915_gem_ring_dispatch(params->request, params->dispatch_flags);
>
> i915_gem_execbuffer_move_to_active(vmas, params->request);
> + add_to_client(params->request, params->file);
>
> return 0;
> }
> @@ -1808,10 +1817,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> *data,
>*/
> params->request->batch = params->batch;
>
> - ret = i915_gem_request_add_to_client(params->request, file);
> - if (ret)
> - goto err_request;
> -
> /*
>* Save assorted stuff away to pass through to *_submission().
>* NB: This data should be 'persistent' and not local as it will
> @@ -1825,7 +1830,6 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
> *data,
> params->ctx = ctx;
>
> ret = execbuf_submit(params, args, &eb->vmas);
> -err_request:
> __i915_add_request(params->request, re
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: free intel_fb
On Wed, Aug 24, 2016 at 04:08:29PM +0300, Joonas Lahtinen wrote: > Hi, > > There also seems to be SUCCESS results for the series, strange. fi-bsw-n3050 was repaired and the test rerun, that seems to have done the trick. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: free intel_fb
Hi, There also seems to be SUCCESS results for the series, strange. Anyway, pushed it. Thanks for the patch and review! Regards, Joonas On ke, 2016-08-24 at 11:06 +0100, Matthew Auld wrote: > On 23 August 2016 at 20:21, Patchwork wrote: > > > > == Series Details == > > > > Series: drm/i915: free intel_fb > > URL : https://patchwork.freedesktop.org/series/11477/ > > State : failure > > > > == Summary == > > > > Series 11477v1 drm/i915: free intel_fb > > http://patchwork.freedesktop.org/api/1.0/series/11477/revisions/1/mbox/ > > > > Test gem_exec_suspend: > > Subgroup basic-s3: > > incomplete -> DMESG-WARN (fi-hsw-4770k) > Created bug report https://bugs.freedesktop.org/show_bug.cgi?id=97465 > > > > > Test kms_cursor_legacy: > > Subgroup basic-cursor-vs-flip-legacy: > > pass -> FAIL (fi-bsw-n3050) > > Subgroup basic-cursor-vs-flip-varying-size: > > pass -> FAIL (fi-bsw-n3050) > > Subgroup basic-flip-vs-cursor-legacy: > > fail -> PASS (fi-bdw-5557u) > > Subgroup basic-flip-vs-cursor-varying-size: > > fail -> PASS (fi-bsw-n3050) > https://bugs.freedesktop.org/show_bug.cgi?id=97188 > > > > > Test prime_busy: > > Subgroup basic-after-default: > > pass -> FAIL (fi-bsw-n3050) > > Subgroup basic-before-default: > > pass -> FAIL (fi-bsw-n3050) > > Subgroup basic-wait-after-default: > > pass -> FAIL (fi-bsw-n3050) > > Subgroup basic-wait-before-default: > > pass -> FAIL (fi-bsw-n3050) > Created bug report https://bugs.freedesktop.org/show_bug.cgi?id=97463 > > > > > Test prime_vgem: > > Subgroup basic-busy-default: > > pass -> FAIL (fi-bsw-n3050) > > Subgroup basic-gtt: > > pass -> FAIL (fi-bsw-n3050) > > Subgroup basic-sync-default: > > pass -> FAIL (fi-bsw-n3050) > > Subgroup basic-wait-default: > > pass -> FAIL (fi-bsw-n3050) > Created bug report https://bugs.freedesktop.org/show_bug.cgi?id=97464 -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Force RC6 restore after system resume and reset
Chris Wilson writes:
> In order for the RC6 autoenable worker to take any action, RC6 first
> must be disabled. Upon resume or reset, the sw state may be stale and so
> we require a forced restore.
>
> Fixes: b7137e0cf1e5 ("drm/i915: Defer enabling rc6 til after we submit...")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Sagar Arun Kamble
Reading the code it stood out that we could get rid of sanitize
completely and always disable before calling autoenable gt powersave.
But lets not take too big steps,
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 5a7c0c2e57d8..fc9273215286 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1560,6 +1560,7 @@ static int i915_drm_resume(struct drm_device *dev)
> int ret;
>
> disable_rpm_wakeref_asserts(dev_priv);
> + intel_sanitize_gt_powersave(dev_priv);
>
> ret = i915_ggtt_enable_hw(dev_priv);
> if (ret)
> @@ -1809,6 +1810,7 @@ int i915_reset(struct drm_i915_private *dev_priv)
>* previous concerns that it doesn't respond well to some forms
>* of re-init after reset.
>*/
> + intel_sanitize_gt_powersave(dev_priv);
> intel_autoenable_gt_powersave(dev_priv);
>
> return 0;
> --
> 2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dvo: Remove dangling call to drm_encoder_cleanup()
On Tue, 23 Aug 2016, David Weinehall wrote:
> On Tue, Aug 23, 2016 at 10:25:58AM +0100, Chris Wilson wrote:
>> If we hit the error path, we have never called drm_encoder_init() and so
>> have nothing to cleanup. Doing so hits a null dereference:
>>
>> [ 10.066261] BUG: unable to handle kernel NULL pointer dereference at
>> 0104
>> [ 10.066273] IP: [] mutex_lock+0xa/0x15
>> [ 10.066287] *pde =
>> [ 10.066295] Oops: 0002 [#1]
>> [ 10.066302] Modules linked in: i915(+) video i2c_algo_bit drm_kms_helper
>> syscopyarea sysfillrect sysimgblt fb_sys_fops drm iTCO_wdt
>> iTCO_vendor_support ppdev evdev snd_intel8x0 snd_ac97_codec ac97_bus psmouse
>> snd_pcm snd_timer snd pcspkr uhci_hcd ehci_pci soundcore sr_mod ehci_hcd
>> serio_raw i2c_i801 usbcore i2c_smbus cdrom lpc_ich mfd_core rng_core e100
>> mii floppy parport_pc parport acpi_cpufreq button processor usb_common
>> eeprom lm85 hwmon_vid autofs4
>> [ 10.066378] CPU: 0 PID: 132 Comm: systemd-udevd Not tainted
>> 4.8.0-rc3-00013-gef0e1ea #34
>> [ 10.066389] Hardware name: MicroLink
>> /D865GLC, BIOS BF86510A.86A.0077.P25.0508040031
>> 08/04/2005
>> [ 10.066401] task: f62db800 task.stack: f597
>> [ 10.066409] EIP: 0060:[] EFLAGS: 00010286 CPU: 0
>> [ 10.066417] EIP is at mutex_lock+0xa/0x15
>> [ 10.066424] EAX: 0104 EBX: 0104 ECX: EDX: 8000
>> [ 10.066432] ESI: EDI: 0104 EBP: f5be8000 ESP: f5971b58
>> [ 10.066439] DS: 007b ES: 007b FS: GS: 00e0 SS: 0068
>> [ 10.066446] CR0: 80050033 CR2: 0104 CR3: 35945000 CR4: 06d0
>> [ 10.066453] Stack:
>> [ 10.066459] f503d740 f824dddf f61170c0 f61170c0 f82371ae
>> f850f40e 0001
>> [ 10.066476] f61170c0 f5971bcc f5be8000 f9c2d401 0001 f8236fcc
>> 0001
>> [ 10.066491] f5144014 f5be8104 0008 f9c5267c 0007 f61170c0
>> f5144400 f9c4ff00
>> [ 10.066507] Call Trace:
>> [ 10.066526] [] ? drm_modeset_lock_all+0x27/0xb3 [drm]
>> [ 10.066545] [] ? drm_encoder_cleanup+0x1a/0x132 [drm]
>> [ 10.066559] [] ? drm_atomic_helper_connector_reset+0x3f/0x5c
>> [drm_kms_helper]
>> [ 10.066644] [] ? intel_dvo_init+0x569/0x788 [i915]
>> [ 10.03] [] ? drm_encoder_init+0x43/0x20b [drm]
>> [ 10.066734] [] ? intel_modeset_init+0x1436/0x17dd [i915]
>> [ 10.066791] [] ? i915_driver_load+0x85a/0x15d3 [i915]
>> [ 10.066846] [] ? i915_driver_open+0x5/0x5 [i915]
>> [ 10.066857] [] ? firmware_map_add_entry.part.2+0xc/0xc
>> [ 10.066868] [] ? pci_device_probe+0x8e/0x11c
>> [ 10.066878] [] ? driver_probe_device+0x1db/0x62e
>> [ 10.066888] [] ? kernfs_new_node+0x29/0x9c
>> [ 10.066897] [] ? pci_match_device+0xd9/0x161
>> [ 10.066905] [] ? kernfs_create_dir_ns+0x42/0x88
>> [ 10.066914] [] ? __driver_attach+0xe6/0x11b
>> [ 10.066924] [] ? kobject_add_internal+0x1bb/0x44f
>> [ 10.066933] [] ? driver_probe_device+0x62e/0x62e
>> [ 10.066941] [] ? bus_for_each_dev+0x46/0x7f
>> [ 10.066950] [] ? driver_attach+0x1a/0x34
>> [ 10.066958] [] ? driver_probe_device+0x62e/0x62e
>> [ 10.066966] [] ? bus_add_driver+0x217/0x32a
>> [ 10.066975] [] ? 0xf8403000
>> [ 10.066982] [] ? driver_register+0x5f/0x108
>> [ 10.066991] [] ? do_one_initcall+0x49/0x1f6
>> [ 10.067000] [] ? pick_next_task_fair+0x14b/0x2a3
>> [ 10.067008] [] ? __schedule+0x15c/0x4fe
>> [ 10.067016] [] ? preempt_schedule_common+0x19/0x3c
>> [ 10.067027] [] ? do_init_module+0x17/0x230
>> [ 10.067035] [] ? _cond_resched+0x12/0x1a
>> [ 10.067044] [] ? kmem_cache_alloc+0x8f/0x11f
>> [ 10.067052] [] ? do_init_module+0x17/0x230
>> [ 10.067060] [] ? kfree+0x137/0x203
>> [ 10.067068] [] ? do_init_module+0x76/0x230
>> [ 10.067078] [] ? load_module+0x2a39/0x333f
>> [ 10.067087] [] ? SyS_finit_module+0x96/0xd5
>> [ 10.067096] [] ? vm_mmap_pgoff+0x79/0xa0
>> [ 10.067105] [] ? do_fast_syscall_32+0xb5/0x1b0
>> [ 10.067114] [] ? sysenter_past_esp+0x47/0x75
>> [ 10.067121] Code: c8 f7 76 c1 e8 8e cc d2 ff e9 45 fe ff ff 66 90 66 90
>> 66 90 66 90 90 ff 00 7f 05 e8 4e 0c 00 00 c3 53 89 c3 e8 75 ec ff ff 89 d8
>> 08 79 05 e8 fa 0a 00 00 5b c3 53 89 c3 85 c0 74 1b 8b 03 83
>> [ 10.067180] EIP: [] mutex_lock+0xa/0x15 SS:ESP 0068:f5971b58
>> [ 10.067190] CR2: 0104
>> [ 10.067222] ---[ end trace 049f1f09da45a856 ]---
>>
>> Reported-by: Meelis Roos
>> Fixes: 580d8ed522e0 ("drm/i915: Give encoders useful names")
>> Signed-off-by: Chris Wilson
>> Cc: Ville Syrjälä
>> Cc: drm-intel-fi...@lists.freedesktop.org
>> ---
>> drivers/gpu/drm/i915/intel_dvo.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dvo.c
>> b/drivers/gpu/drm/i915/intel_dvo.c
>> index 47bdf9dad0d3..b9e5a63a7c9e 100644
>> --- a/drivers/gpu/drm/i915/intel_dvo.c
>> +++ b/drivers/gpu/drm/i915/intel_dvo.c
>> @@ -554,7 +554,6 @@ void intel_dvo_init(struct drm_device *dev)
>>
Re: [Intel-gfx] [PATCH] drm/i915: Suppress DRM_ERROR for D_COMP write on Haswell
On 24 August 2016 at 11:16, Chris Wilson wrote: > The D_COMP (render decompression) register write is followed by a status > check and another error (either that the decompression shutdown or the > lpll is enabled). Since we are followed by another, more pertinent, > error we can reduce the pcode timeout to a debug and squelch a sporadic > error message during suspend. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97465 > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbdev: Setup for using FBC tracking
On Wed, Aug 24, 2016 at 1:16 PM, Chris Wilson wrote:
>> > + if (i915.enable_fbc) {
>> > + obj->tiling_and_stride = mode_cmd.pitches[0] | I915_TILING_X;
>> > + mode_cmd.modifier[0] = I915_FORMAT_MOD_X_TILED;
>> > + mode_cmd.flags |= DRM_MODE_FB_MODIFIERS;
>> > + }
>>
>> Even more magic set-tiling calls, now also depending upon module options.
>> This sounds like a rather bad idea to me.
>
> FB_MODIFIERS are pretty magic, I know!
>
> This was more of if you want to use fbdev + fbc, this is what we should
> do. Note that this is not so much a module option, but fbc state. At
> this point in fbdev's lifecycle, we should be able to use HAS_FBC()
> which is equivalent to i915.enable_fbc once we've sanitized the options.
tbh I think fbdev is not something we should care about at all, beyond
making sure that it doesn't fail. For anyone who really hates X and
wayland enough to not even run them as terminal emulators there's
kmscon. Doing something "because fbdev" is imo negative justification
;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbdev: Setup for using FBC tracking
On Wed, Aug 24, 2016 at 01:05:18PM +0200, Daniel Vetter wrote:
> On Wed, Aug 24, 2016 at 08:39:52AM +0100, Chris Wilson wrote:
> > When FBC is enabled, access through the fbdev is tracked using
> > ORIGIN_GTT, i.e. native hw tracking by FBC. This requires the
> > framebuffer to be fenced, which requires us to allocate the object
> > as X-tiled.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_fbdev.c | 13 +++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> > b/drivers/gpu/drm/i915/intel_fbdev.c
> > index 8d6bfa565b50..ad3995f87485 100644
> > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > @@ -138,14 +138,17 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
> >
> > mode_cmd.pitches[0] = ALIGN(mode_cmd.width *
> > DIV_ROUND_UP(sizes->surface_bpp, 8), 64);
> > + if (i915.enable_fbc)
> > + mode_cmd.pitches[0] = ALIGN(mode_cmd.pitches[0], 512);
> > +
> > mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
> > sizes->surface_depth);
> >
> > - mutex_lock(&dev->struct_mutex);
> > -
> > size = mode_cmd.pitches[0] * mode_cmd.height;
> > size = PAGE_ALIGN(size);
> >
> > + mutex_lock(&dev->struct_mutex);
> > +
> > /* If the FB is too big, just don't use it since fbdev is not very
> > * important and we should probably use that space with FBC or other
> > * features. */
> > @@ -159,6 +162,12 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
> > goto out;
> > }
> >
> > + if (i915.enable_fbc) {
> > + obj->tiling_and_stride = mode_cmd.pitches[0] | I915_TILING_X;
> > + mode_cmd.modifier[0] = I915_FORMAT_MOD_X_TILED;
> > + mode_cmd.flags |= DRM_MODE_FB_MODIFIERS;
> > + }
>
> Even more magic set-tiling calls, now also depending upon module options.
> This sounds like a rather bad idea to me.
FB_MODIFIERS are pretty magic, I know!
This was more of if you want to use fbdev + fbc, this is what we should
do. Note that this is not so much a module option, but fbc state. At
this point in fbdev's lifecycle, we should be able to use HAS_FBC()
which is equivalent to i915.enable_fbc once we've sanitized the options.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: free intel_fb
== Series Details == Series: drm/i915: free intel_fb URL : https://patchwork.freedesktop.org/series/11477/ State : success == Summary == Series 11477v1 drm/i915: free intel_fb http://patchwork.freedesktop.org/api/1.0/series/11477/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s3: incomplete -> DMESG-WARN (fi-hsw-4770k) Test kms_cursor_legacy: Subgroup basic-flip-vs-cursor-legacy: fail -> PASS (fi-bdw-5557u) fi-bdw-5557u total:249 pass:232 dwarn:0 dfail:0 fail:1 skip:16 fi-byt-n2820 total:249 pass:204 dwarn:0 dfail:0 fail:4 skip:41 fi-hsw-4770k total:249 pass:220 dwarn:6 dfail:0 fail:1 skip:22 fi-hsw-4770r total:249 pass:222 dwarn:0 dfail:0 fail:1 skip:26 fi-ivb-3520m total:249 pass:217 dwarn:0 dfail:0 fail:1 skip:31 fi-skl-6260u total:249 pass:234 dwarn:0 dfail:0 fail:1 skip:14 fi-skl-6700k total:249 pass:214 dwarn:4 dfail:0 fail:3 skip:28 fi-snb-2520m total:249 pass:201 dwarn:4 dfail:0 fail:2 skip:42 fi-snb-2600 total:249 pass:202 dwarn:4 dfail:0 fail:1 skip:42 Results at /archive/results/CI_IGT_test/Patchwork_2411/ d05ed1828321404c7fdf369ca17fa958938913bc drm-intel-nightly: 2016y-08m-23d-16h-32m-14s UTC integration manifest b9253f5 drm/i915: free intel_fb ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: Allow on unfenced surfaces, for recent gen
On Wed, Aug 24, 2016 at 7:54 AM, Daniel Vetter wrote: > On Mon, Aug 22, 2016 at 09:39:17PM -0300, Paulo Zanoni wrote: >> 2016-08-18 5:21 GMT-03:00 Chris Wilson : >> > Only fbc1 is tied to using a fence. Later iterations of fbc are more >> > flexible and allow operation on unfenced frontbuffers. >> > >> > Signed-off-by: Chris Wilson >> > Cc: Daniel Vetter >> > Cc: "Zanoni, Paulo R" >> >> Hi >> >> I see this patch was applied. Now, on my Skylake machine, if I boot >> with i915.enable_fbc=1 I'll get FIFO underruns under fbcon. Just >> booting already gives me a FIFO underrun message, and then if I "sudo >> systemctl stop lightdm" I'll get a constantly-blinking screen. >> >> Of course, applying the patch that disables FBC after a FIFO underrun >> will help stopping the ever-blinking fbcon, but I think we should try >> to avoid the underruns in the places we know we can, and leave the >> "disable FBC on FIFO underruns" just for the cases we're not expecting. >> >> Also, please remember that I mentioned there are FBC workarounds for >> untiled that we still don't implement (although when I re-read my >> email it may sound like I suggested the workarounds are for non-GTT >> tracking). IMHO this argument alone should >> have prevented this patch from being merged... >> >> Based on that, can we please revert this patch? I'm afraid some people >> would consider these underruns as blockers to enabling FBC, so it's >> probably better to enable FBC only on X tiled for now, and leave this >> for when we know how to prevent the underrun (possibly by implementing >> the missing WAs). >> >> >> (I'm sorry if you got this message twice, but the mail servers are a >> little crazy these days and I didn't receive my copy, so I'm sending >> it again). > > Yeah, mailman was on vacation a bit the last few days due to a ddos > probably. +1 from me for just reverting if this is causing troubles. > Also, patch doesn't seem to have a Testcase: line, was the > kms_frontbuffer_tracking test not extended to cover this new use-case? In > that case definitely revert, since failed to pass testing requirements. Original patch also wasn't acked by Paulo, which it pretty much has to be as an fbc patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbdev: Setup for using FBC tracking
On Wed, Aug 24, 2016 at 08:39:52AM +0100, Chris Wilson wrote:
> When FBC is enabled, access through the fbdev is tracked using
> ORIGIN_GTT, i.e. native hw tracking by FBC. This requires the
> framebuffer to be fenced, which requires us to allocate the object
> as X-tiled.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_fbdev.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 8d6bfa565b50..ad3995f87485 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -138,14 +138,17 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
>
> mode_cmd.pitches[0] = ALIGN(mode_cmd.width *
> DIV_ROUND_UP(sizes->surface_bpp, 8), 64);
> + if (i915.enable_fbc)
> + mode_cmd.pitches[0] = ALIGN(mode_cmd.pitches[0], 512);
> +
> mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
> sizes->surface_depth);
>
> - mutex_lock(&dev->struct_mutex);
> -
> size = mode_cmd.pitches[0] * mode_cmd.height;
> size = PAGE_ALIGN(size);
>
> + mutex_lock(&dev->struct_mutex);
> +
> /* If the FB is too big, just don't use it since fbdev is not very
>* important and we should probably use that space with FBC or other
>* features. */
> @@ -159,6 +162,12 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
> goto out;
> }
>
> + if (i915.enable_fbc) {
> + obj->tiling_and_stride = mode_cmd.pitches[0] | I915_TILING_X;
> + mode_cmd.modifier[0] = I915_FORMAT_MOD_X_TILED;
> + mode_cmd.flags |= DRM_MODE_FB_MODIFIERS;
> + }
Even more magic set-tiling calls, now also depending upon module options.
This sounds like a rather bad idea to me.
-Daniel
> +
> fb = __intel_framebuffer_create(dev, &mode_cmd, obj);
> if (IS_ERR(fb)) {
> i915_gem_object_put(obj);
> --
> 2.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Populate Y-tiling from initial plane state
On Wed, Aug 24, 2016 at 08:20:32AM +0100, Chris Wilson wrote:
> It is possible that from Skylake onwards the initial plane is tiled in
> some other format than X. Copy across this information to the object
> when such formats are fence-able.
>
> Signed-off-by: Chris Wilson
So this makes an implicit set-tiling when doing an addfb? What's the
purpose of this uapi change?
-Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e363a68d97ed..187e499107af 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2700,8 +2700,15 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
> return false;
> }
>
> - if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
> - obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
> + if (fb->modifier[0]) {
> + obj->tiling_and_stride = fb->pitches[0];
> + if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
> + obj->tiling_and_stride |= I915_TILING_X;
> + else if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED)
> + obj->tiling_and_stride |= I915_TILING_Y;
> + else
> + obj->tiling_and_stride = 0; /* unfenced tiling mode */
> + }
>
> mode_cmd.pixel_format = fb->pixel_format;
> mode_cmd.width = fb->width;
> --
> 2.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/fbdev: ORIGIN_GTT is only suitable for tracked writes
== Series Details == Series: series starting with [1/2] drm/i915/fbdev: ORIGIN_GTT is only suitable for tracked writes URL : https://patchwork.freedesktop.org/series/11509/ State : failure == Summary == Series 11509v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/11509/revisions/1/mbox/ Test gem_exec_gttfill: Subgroup basic: skip -> PASS (fi-snb-2600) Test kms_cursor_legacy: Subgroup basic-cursor-vs-flip-legacy: pass -> FAIL (fi-bsw-n3050) Subgroup basic-cursor-vs-flip-varying-size: pass -> FAIL (fi-bsw-n3050) Subgroup basic-flip-vs-cursor-legacy: pass -> FAIL (fi-skl-6700k) fail -> PASS (fi-bsw-n3050) Subgroup basic-flip-vs-cursor-varying-size: fail -> PASS (fi-bsw-n3050) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> DMESG-WARN (fi-hsw-4770k) Test prime_busy: Subgroup basic-after-default: pass -> FAIL (fi-bsw-n3050) Subgroup basic-before-default: pass -> FAIL (fi-bsw-n3050) Subgroup basic-wait-after-default: pass -> FAIL (fi-bsw-n3050) Subgroup basic-wait-before-default: pass -> FAIL (fi-bsw-n3050) Test prime_vgem: Subgroup basic-busy-default: pass -> FAIL (fi-bsw-n3050) Subgroup basic-gtt: pass -> FAIL (fi-bsw-n3050) Subgroup basic-sync-default: pass -> FAIL (fi-bsw-n3050) Subgroup basic-wait-default: pass -> FAIL (fi-bsw-n3050) fi-bsw-n3050 total:249 pass:194 dwarn:0 dfail:0 fail:11 skip:44 fi-byt-n2820 total:249 pass:203 dwarn:0 dfail:0 fail:5 skip:41 fi-hsw-4770k total:249 pass:219 dwarn:6 dfail:1 fail:1 skip:22 fi-ivb-3520m total:249 pass:217 dwarn:0 dfail:0 fail:1 skip:31 fi-skl-6260u total:249 pass:233 dwarn:0 dfail:0 fail:2 skip:14 fi-skl-6700k total:249 pass:213 dwarn:4 dfail:0 fail:4 skip:28 fi-snb-2520m total:249 pass:201 dwarn:4 dfail:0 fail:2 skip:42 fi-snb-2600 total:249 pass:201 dwarn:4 dfail:0 fail:2 skip:42 Results at /archive/results/CI_IGT_test/Patchwork_2419/ 9eafbdb3b053e7cc5f425665f51adf6be1cc0aa3 drm-intel-nightly: 2016y-08m-24d-07h-49m-28s UTC integration manifest a6cfe68 drm/i915/fbdev: Setup for using FBC tracking 24da7a3 drm/i915/fbdev: ORIGIN_GTT is only suitable for tracked writes ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Suppress DRM_ERROR for D_COMP write on Haswell
The D_COMP (render decompression) register write is followed by a status
check and another error (either that the decompression shutdown or the
lpll is enabled). Since we are followed by another, more pertinent,
error we can reduce the pcode timeout to a debug and squelch a sporadic
error message during suspend.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97465
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b3ea141c0ce8..eb4c989e98a3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9973,7 +9973,7 @@ static void hsw_write_dcomp(struct drm_i915_private
*dev_priv, uint32_t val)
mutex_lock(&dev_priv->rps.hw_lock);
if (sandybridge_pcode_write(dev_priv, GEN6_PCODE_WRITE_D_COMP,
val))
- DRM_ERROR("Failed to write to D_COMP\n");
+ DRM_DEBUG_KMS("Failed to write to D_COMP\n");
mutex_unlock(&dev_priv->rps.hw_lock);
} else {
I915_WRITE(D_COMP_BDW, val);
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: free intel_fb
On 23 August 2016 at 20:21, Patchwork wrote: > == Series Details == > > Series: drm/i915: free intel_fb > URL : https://patchwork.freedesktop.org/series/11477/ > State : failure > > == Summary == > > Series 11477v1 drm/i915: free intel_fb > http://patchwork.freedesktop.org/api/1.0/series/11477/revisions/1/mbox/ > > Test gem_exec_suspend: > Subgroup basic-s3: > incomplete -> DMESG-WARN (fi-hsw-4770k) Created bug report https://bugs.freedesktop.org/show_bug.cgi?id=97465 > Test kms_cursor_legacy: > Subgroup basic-cursor-vs-flip-legacy: > pass -> FAIL (fi-bsw-n3050) > Subgroup basic-cursor-vs-flip-varying-size: > pass -> FAIL (fi-bsw-n3050) > Subgroup basic-flip-vs-cursor-legacy: > fail -> PASS (fi-bdw-5557u) > Subgroup basic-flip-vs-cursor-varying-size: > fail -> PASS (fi-bsw-n3050) https://bugs.freedesktop.org/show_bug.cgi?id=97188 > Test prime_busy: > Subgroup basic-after-default: > pass -> FAIL (fi-bsw-n3050) > Subgroup basic-before-default: > pass -> FAIL (fi-bsw-n3050) > Subgroup basic-wait-after-default: > pass -> FAIL (fi-bsw-n3050) > Subgroup basic-wait-before-default: > pass -> FAIL (fi-bsw-n3050) Created bug report https://bugs.freedesktop.org/show_bug.cgi?id=97463 > Test prime_vgem: > Subgroup basic-busy-default: > pass -> FAIL (fi-bsw-n3050) > Subgroup basic-gtt: > pass -> FAIL (fi-bsw-n3050) > Subgroup basic-sync-default: > pass -> FAIL (fi-bsw-n3050) > Subgroup basic-wait-default: > pass -> FAIL (fi-bsw-n3050) Created bug report https://bugs.freedesktop.org/show_bug.cgi?id=97464 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Force RC6 restore after system resume and reset
In order for the RC6 autoenable worker to take any action, RC6 first
must be disabled. Upon resume or reset, the sw state may be stale and so
we require a forced restore.
Fixes: b7137e0cf1e5 ("drm/i915: Defer enabling rc6 til after we submit...")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5a7c0c2e57d8..fc9273215286 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1560,6 +1560,7 @@ static int i915_drm_resume(struct drm_device *dev)
int ret;
disable_rpm_wakeref_asserts(dev_priv);
+ intel_sanitize_gt_powersave(dev_priv);
ret = i915_ggtt_enable_hw(dev_priv);
if (ret)
@@ -1809,6 +1810,7 @@ int i915_reset(struct drm_i915_private *dev_priv)
* previous concerns that it doesn't respond well to some forms
* of re-init after reset.
*/
+ intel_sanitize_gt_powersave(dev_priv);
intel_autoenable_gt_powersave(dev_priv);
return 0;
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm: Add reference counting to drm_atomic_state
On Wed, Aug 24, 2016 at 07:10:15AM +0100, Chris Wilson wrote:
> drm_atomic_state has a complicated single owner model that tracks the
> single reference from allocation through to destruction on another
> thread - or perhaps on a local error path. We can simplify this tracking
> by using reference counting (at a cost of a few more atomics). This is
> even more beneficial when the lifetime of the state becomes more
> convoluted than being passed to a single worker thread for the commit.
>
> v2: Double check !intel atomic_commit functions for missing gets
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 3 +-
> drivers/gpu/drm/drm_atomic.c | 23 +++
> drivers/gpu/drm/drm_atomic_helper.c | 98
> +++-
> drivers/gpu/drm/drm_fb_helper.c | 9 +--
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 3 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 3 +-
> drivers/gpu/drm/i915/intel_display.c | 32 -
> drivers/gpu/drm/i915/intel_sprite.c | 4 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 +-
> drivers/gpu/drm/msm/msm_atomic.c | 3 +-
> drivers/gpu/drm/omapdrm/omap_drv.c | 3 +-
> drivers/gpu/drm/rcar-du/rcar_du_kms.c| 3 +-
> drivers/gpu/drm/sti/sti_drv.c| 3 +-
> drivers/gpu/drm/tegra/drm.c | 3 +-
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 2 -
> drivers/gpu/drm/vc4/vc4_kms.c| 3 +-
> include/drm/drm_atomic.h | 12 +++-
> include/drm/drm_crtc.h | 3 +
> 18 files changed, 85 insertions(+), 128 deletions(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index d4a3d61b7b06..15a9f9d3ef9a 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -464,7 +464,7 @@ atmel_hlcdc_dc_atomic_complete(struct
> atmel_hlcdc_dc_commit *commit)
>
> drm_atomic_helper_cleanup_planes(dev, old_state);
>
> - drm_atomic_state_free(old_state);
> + drm_atomic_state_put(old_state);
>
> /* Complete the commit, wake up any waiter. */
> spin_lock(&dc->commit.wait.lock);
> @@ -521,6 +521,7 @@ static int atmel_hlcdc_dc_atomic_commit(struct drm_device
> *dev,
> /* Swap the state, this is the point of no return. */
> drm_atomic_helper_swap_state(state, true);
>
> + drm_atomic_state_get(state);
> if (async)
> queue_work(dc->wq, &commit->work);
> else
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 5cb2e22d5d55..349c2f0de900 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -74,6 +74,8 @@ EXPORT_SYMBOL(drm_atomic_state_default_release);
> int
> drm_atomic_state_init(struct drm_device *dev, struct drm_atomic_state *state)
> {
> + kref_init(&state->ref);
> +
> /* TODO legacy paths should maybe do a better job about
>* setting this appropriately?
>*/
> @@ -215,22 +217,16 @@ void drm_atomic_state_clear(struct drm_atomic_state
> *state)
> EXPORT_SYMBOL(drm_atomic_state_clear);
>
> /**
> - * drm_atomic_state_free - free all memory for an atomic state
> + * __drm_atomic_state_free - free all memory for an atomic state
> * @state: atomic state to deallocate
Doc line needs updating as well.
Other than that, this looks good to me:
Reviewed-by: Eric Engestrom
> *
> * This frees all memory associated with an atomic state, including all the
> * per-object state for planes, crtcs and connectors.
> */
> -void drm_atomic_state_free(struct drm_atomic_state *state)
> +void __drm_atomic_state_free(struct kref *ref)
> {
[snip]
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Replace initial plane_config.tiling with fb modifier
On Wed, Aug 24, 2016 at 09:56:29AM +0100, Chris Wilson wrote:
> On Wed, Aug 24, 2016 at 10:47:22AM +0200, David Weinehall wrote:
> > On Wed, Aug 24, 2016 at 08:20:31AM +0100, Chris Wilson wrote:
> > > When determining the initial plane config we set the same information in
> > > both the framebuffer (fb.modifier[0]) and in plane_config.tiling.
> > > Ultimately, we only need the information in the framebuffer so remove
> > > the redundant copy from plane_config.tiling
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 23 +++
> > > drivers/gpu/drm/i915/intel_drv.h | 1 -
> > > 2 files changed, 7 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index d61c264d5a37..e363a68d97ed 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -2700,7 +2700,7 @@ intel_alloc_initial_plane_obj(struct intel_crtc
> > > *crtc,
> > > return false;
> > > }
> > >
> > > - if (plane_config->tiling == I915_TILING_X)
> > > + if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
> > > obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
> > >
> > > mode_cmd.pixel_format = fb->pixel_format;
> > > @@ -8730,12 +8730,8 @@ i9xx_get_initial_plane_config(struct intel_crtc
> > > *crtc,
> > >
> > > fb = &intel_fb->base;
> > >
> > > - if (INTEL_INFO(dev)->gen >= 4) {
> > > - if (val & DISPPLANE_TILED) {
> > > - plane_config->tiling = I915_TILING_X;
> > > - fb->modifier[0] = I915_FORMAT_MOD_X_TILED;
> > > - }
> > > - }
> > > + if (INTEL_GEN(dev) >= 4 && val & DISPPLANE_TILED)
> > > + fb->modifier[0] = I915_FORMAT_MOD_X_TILED;
> >
> > dev_priv
>
> Would be a bit odd by itself until some one does a mass convert ;)
Working on it, but anything that helps turning the mass convert into
a small scale sermon convert[1] will ease review / merge,
and as you're doing the INTEL_INFO()->gen to INTEL_GEN() conversion
anyway, and since the function has a pointer to dev_priv already, I
think it's a sensible idea. YMMV.
Kind regards, David Weinehall
[1] OK, my sense of humour is horrible.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Replace initial plane_config.tiling with fb modifier
On Wed, Aug 24, 2016 at 10:47:22AM +0200, David Weinehall wrote:
> On Wed, Aug 24, 2016 at 08:20:31AM +0100, Chris Wilson wrote:
> > When determining the initial plane config we set the same information in
> > both the framebuffer (fb.modifier[0]) and in plane_config.tiling.
> > Ultimately, we only need the information in the framebuffer so remove
> > the redundant copy from plane_config.tiling
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 23 +++
> > drivers/gpu/drm/i915/intel_drv.h | 1 -
> > 2 files changed, 7 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index d61c264d5a37..e363a68d97ed 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2700,7 +2700,7 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
> > return false;
> > }
> >
> > - if (plane_config->tiling == I915_TILING_X)
> > + if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
> > obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
> >
> > mode_cmd.pixel_format = fb->pixel_format;
> > @@ -8730,12 +8730,8 @@ i9xx_get_initial_plane_config(struct intel_crtc
> > *crtc,
> >
> > fb = &intel_fb->base;
> >
> > - if (INTEL_INFO(dev)->gen >= 4) {
> > - if (val & DISPPLANE_TILED) {
> > - plane_config->tiling = I915_TILING_X;
> > - fb->modifier[0] = I915_FORMAT_MOD_X_TILED;
> > - }
> > - }
> > + if (INTEL_GEN(dev) >= 4 && val & DISPPLANE_TILED)
> > + fb->modifier[0] = I915_FORMAT_MOD_X_TILED;
>
> dev_priv
Would be a bit odd by itself until some one does a mass convert ;)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Replace initial plane_config.tiling with fb modifier
== Series Details == Series: series starting with [1/2] drm/i915: Replace initial plane_config.tiling with fb modifier URL : https://patchwork.freedesktop.org/series/11507/ State : failure == Summary == Series 11507v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/11507/revisions/1/mbox/ Test gem_exec_gttfill: Subgroup basic: skip -> PASS (fi-snb-2600) Test kms_cursor_legacy: Subgroup basic-flip-vs-cursor-legacy: pass -> FAIL (fi-skl-6700k) Subgroup basic-flip-vs-cursor-varying-size: fail -> PASS (fi-skl-6700k) fail -> PASS (fi-byt-n2820) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: incomplete -> DMESG-WARN (fi-hsw-4770k) fi-bsw-n3050 total:249 pass:202 dwarn:0 dfail:0 fail:3 skip:44 fi-byt-n2820 total:249 pass:204 dwarn:0 dfail:0 fail:4 skip:41 fi-hsw-4770k total:249 pass:219 dwarn:6 dfail:1 fail:1 skip:22 fi-ivb-3520m total:249 pass:217 dwarn:0 dfail:0 fail:1 skip:31 fi-skl-6260u total:249 pass:233 dwarn:0 dfail:0 fail:2 skip:14 fi-skl-6700k total:249 pass:214 dwarn:4 dfail:0 fail:3 skip:28 fi-snb-2520m total:249 pass:201 dwarn:4 dfail:0 fail:2 skip:42 fi-snb-2600 total:249 pass:201 dwarn:4 dfail:0 fail:2 skip:42 Results at /archive/results/CI_IGT_test/Patchwork_2418/ 9eafbdb3b053e7cc5f425665f51adf6be1cc0aa3 drm-intel-nightly: 2016y-08m-24d-07h-49m-28s UTC integration manifest 3323b4d drm/i915: Populate Y-tiling from initial plane state 9160e48 drm/i915: Replace initial plane_config.tiling with fb modifier ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Replace initial plane_config.tiling with fb modifier
On Wed, Aug 24, 2016 at 08:20:31AM +0100, Chris Wilson wrote:
> When determining the initial plane config we set the same information in
> both the framebuffer (fb.modifier[0]) and in plane_config.tiling.
> Ultimately, we only need the information in the framebuffer so remove
> the redundant copy from plane_config.tiling
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_display.c | 23 +++
> drivers/gpu/drm/i915/intel_drv.h | 1 -
> 2 files changed, 7 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index d61c264d5a37..e363a68d97ed 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2700,7 +2700,7 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
> return false;
> }
>
> - if (plane_config->tiling == I915_TILING_X)
> + if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
> obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
>
> mode_cmd.pixel_format = fb->pixel_format;
> @@ -8730,12 +8730,8 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
>
> fb = &intel_fb->base;
>
> - if (INTEL_INFO(dev)->gen >= 4) {
> - if (val & DISPPLANE_TILED) {
> - plane_config->tiling = I915_TILING_X;
> - fb->modifier[0] = I915_FORMAT_MOD_X_TILED;
> - }
> - }
> + if (INTEL_GEN(dev) >= 4 && val & DISPPLANE_TILED)
> + fb->modifier[0] = I915_FORMAT_MOD_X_TILED;
dev_priv
>
> pixel_format = val & DISPPLANE_PIXFORMAT_MASK;
> fourcc = i9xx_format_to_fourcc(pixel_format);
> @@ -8743,7 +8739,7 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
> fb->bits_per_pixel = drm_format_plane_cpp(fourcc, 0) * 8;
>
> if (INTEL_INFO(dev)->gen >= 4) {
> - if (plane_config->tiling)
> + if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
> offset = I915_READ(DSPTILEOFF(plane));
> else
> offset = I915_READ(DSPLINOFF(plane));
> @@ -9756,7 +9752,6 @@ skylake_get_initial_plane_config(struct intel_crtc
> *crtc,
> fb->modifier[0] = DRM_FORMAT_MOD_NONE;
> break;
> case PLANE_CTL_TILED_X:
> - plane_config->tiling = I915_TILING_X;
> fb->modifier[0] = I915_FORMAT_MOD_X_TILED;
> break;
> case PLANE_CTL_TILED_Y:
> @@ -9851,12 +9846,8 @@ ironlake_get_initial_plane_config(struct intel_crtc
> *crtc,
>
> fb = &intel_fb->base;
>
> - if (INTEL_INFO(dev)->gen >= 4) {
> - if (val & DISPPLANE_TILED) {
> - plane_config->tiling = I915_TILING_X;
> - fb->modifier[0] = I915_FORMAT_MOD_X_TILED;
> - }
> - }
> + if (INTEL_GEN(dev) >= 4 && val & DISPPLANE_TILED)
> + fb->modifier[0] = I915_FORMAT_MOD_X_TILED;
dev_priv
>
> pixel_format = val & DISPPLANE_PIXFORMAT_MASK;
> fourcc = i9xx_format_to_fourcc(pixel_format);
> @@ -9867,7 +9858,7 @@ ironlake_get_initial_plane_config(struct intel_crtc
> *crtc,
> if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
> offset = I915_READ(DSPOFFSET(pipe));
> } else {
> - if (plane_config->tiling)
> + if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
> offset = I915_READ(DSPTILEOFF(pipe));
> else
> offset = I915_READ(DSPLINOFF(pipe));
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 37cad7c779b3..3ee156aab938 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -400,7 +400,6 @@ struct intel_plane_state {
>
> struct intel_initial_plane_config {
> struct intel_framebuffer *fb;
> - unsigned int tiling;
> int size;
> u32 base;
> };
Kind regards, David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v3] lib/igt_core: Print stacktrace when receiving one of the crash signals.
While at it add SIGFPE as a crash signal.
v3: Remove calls to igt_assert_eq() as these are not async-safe. As one
user of this method remove the function pointer and recursive call.
(Chris Wilson)
v2: Added some helpers to avoid printf() inside a signal handler.
(Chris Wilson)
---
lib/igt_core.c | 179 -
1 file changed, 177 insertions(+), 2 deletions(-)
diff --git a/lib/igt_core.c b/lib/igt_core.c
index 801f02f..7e5bf76 100644
--- a/lib/igt_core.c
+++ b/lib/igt_core.c
@@ -1098,6 +1098,179 @@ static void print_backtrace(void)
(unsigned int) off);
}
}
+
+static const char hex[] = "0123456789abcdef";
+
+static void
+xputch(int c)
+{
+ write(STDERR_FILENO, (const void *) &c, 1);
+}
+
+static int
+xpow(int base, int pow)
+{
+ int i, r = 1;
+
+ for (i = 0; i < pow; i++)
+ r *= base;
+
+ return r;
+}
+
+static void
+printnum(unsigned long long num, unsigned base)
+{
+ int i = 0;
+ unsigned long long __num;
+
+ /* determine from where we should start dividing */
+ do {
+ __num /= base;
+ i++;
+ } while (__num);
+
+ while (i--)
+ xputch(hex[num / xpow(base, i) % base]);
+}
+
+static size_t
+xstrlcpy(char *dst, const char *src, size_t size)
+{
+ char *dst_in;
+
+ dst_in = dst;
+ if (size > 0) {
+ while (--size > 0 && *src != '\0')
+ *dst++ = *src++;
+ *dst = '\0';
+ }
+
+ return dst - dst_in;
+}
+
+static void
+xprintfmt(const char *fmt, va_list ap)
+{
+ const char *p;
+ int ch, base;
+ unsigned long long num;
+
+ while (1) {
+ while ((ch = *(unsigned char *) fmt++) != '%') {
+ if (ch == '\0') {
+ return;
+ }
+ xputch(ch);
+ }
+
+ ch = *(unsigned char *) fmt++;
+ switch (ch) {
+ /* character */
+ case 'c':
+ xputch(va_arg(ap, int));
+ break;
+ /* string */
+ case 's':
+ if ((p = va_arg(ap, char *)) == NULL) {
+ p = "(null)";
+ }
+
+ for (; (ch = *p++) != '\0';) {
+ if (ch < ' ' || ch > '~') {
+ xputch('?');
+ } else {
+ xputch(ch);
+ }
+ }
+ break;
+ /* (signed) decimal */
+ case 'd':
+ num = va_arg(ap, int);
+ if ((long long) num < 0) {
+ xputch('-');
+ num = -(long long) num;
+ }
+ base = 10;
+ goto number;
+ /* unsigned decimal */
+ case 'u':
+ num = va_arg(ap, unsigned int);
+ base = 10;
+ goto number;
+ /* (unsigned) hexadecimal */
+ case 'x':
+ num = va_arg(ap, unsigned int);
+ base = 16;
+number:
+ printnum(num, base);
+ break;
+
+ /* The following are not implemented */
+
+ /* width field */
+ case '1': case '2':
+ case '3': case '4':
+ case '5': case '6':
+ case '7': case '8':
+ case '9':
+ case '.': case '#':
+ /* long */
+ case 'l':
+ /* octal */
+ case 'o':
+ /* pointer */
+ case 'p':
+ /* float */
+ case 'f':
+ abort();
+ /* escaped '%' character */
+ case '%':
+ xputch(ch);
+ break;
+ /* unrecognized escape sequence - just print it literally */
+ default:
+ xputch('%');
+ for (fmt--; fmt[-1] != '%'; fmt--)
+ ; /* do nothing */
+ break;
+ }
+ }
+}
+
+/* async-safe printf */
+static void
+xprintf(const char *fmt, ...)
+{
+ va_list ap;
+
+ va_start(ap, fmt);
+ xprintfmt(fmt, ap);
+ va_end(ap);
+}
+
+static void print_backtrace_sig_safe(void)
+{
+ unw_cursor_t cursor;
+ unw_context_t uc;
+ int stack_num = 0;
+
+ write(STDERR_FILENO, "Stack trace: \n", 15);
+
+ unw_getcontext(&uc);
+ unw_init_local(&cursor, &uc);
+ while (unw_step(&curso
Re: [Intel-gfx] [PATCH i-g-t 1/2] autotools: Check target requires to a have the list of tests built.
On Fri, Apr 29, 2016 at 04:11:19PM +0300, Marius Vlad wrote: > We need to have the test list generated before running the check target. > Migrated igt_command_line.sh to tests/ from lib/tests/, which allows to > building the tests and execute the script. > > This would allow cleaning followed by a make check. > > Signed-off-by: Marius Vlad I stumbled across this make check failure, and this looks like the fix. Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/Makefile.am: Add -Wno-unused-result to tests
Removes useless warnings if a caller of a function does not use its returned value(s). Mostly aesthetic. Signed-off-by: Marius Vlad CC: Chris Wilson CC: Daniel Vetter --- tests/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index 0137597..bf27cb7 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -54,7 +54,7 @@ EXTRA_DIST = $(common_files) CLEANFILES = $(EXTRA_PROGRAMS) test-list.txt test-list-full.txt .gitignore -AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) $(DEBUG_CFLAGS)\ +AM_CFLAGS = $(DRM_CFLAGS) $(CWARNFLAGS) -Wno-unused-result $(DEBUG_CFLAGS)\ -I$(srcdir)/.. \ -I$(srcdir)/../lib \ -include "$(srcdir)/../lib/check-ndebug.h" \ -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915/slpc: Update freq min/max softlimits
On Sun, Aug 21, 2016 at 09:39:17PM +0530, Kamble, Sagar A wrote:
>
>
> On 8/21/2016 2:09 PM, Chris Wilson wrote:
> >On Sun, Aug 21, 2016 at 11:39:22AM +0530, Kamble, Sagar A wrote:
> >>
> >>On 8/20/2016 1:32 PM, Chris Wilson wrote:
> >>>On Sat, Aug 20, 2016 at 10:39:25AM +0530, Sagar Arun Kamble wrote:
> + obj = dev_priv->guc.slpc.vma->obj;
> + if (obj) {
> >>>OOPS.
> >>Fixed in next series.
> + intel_slpc_query_task_state(dev_priv);
> +
> + page = i915_gem_object_get_page(obj, 0);
> + if (page)
> + pv = kmap_atomic(page);
> + }
> +
> + if (pv) {
> + data = *(struct slpc_shared_data *) pv;
> + kunmap_atomic(pv);
> >>>Can kmap_atomic return zero?
> >>Fixed in next series.
> +
> + /*
> + * TODO: Define separate variables for slice and unslice
> + * frequencies for driver state variable.
> + */
> + dev_priv->rps.max_freq_softlimit =
> + data.task_state_data.freq_unslice_max;
> + dev_priv->rps.min_freq_softlimit =
> + data.task_state_data.freq_unslice_min;
> >>>These are user values, you do not get to arbitrarily rewrite them.
> >>>
> >>>You control dev_priv->rps.[min|max]_freq.
> >>With SLPC, GuC firmware SLPC S/W requested frequency be operated in
> >>the softlimits analogous to
> >>Host softlimits. Limits might be different with SLPC and can be
> >>controlled through regular interfaces.
> >>dev_priv->rps.[min|max]_freq are HW Min/Max.
> >Exactly. The soft limits are *only* set by the user. They are not to
> >modified by the driver. (The caveat would be a dynamic update of the hw
> >range, but that too should never be required.)
> >-Chris
> This initialization is similar to following from intel_init_gt_powersave
> dev_priv->rps.max_freq_softlimit = dev_priv->rps.max_freq;
> dev_priv->rps.min_freq_softlimit = dev_priv->rps.min_freq;
> I assume min_freq is hw min(RPn). With SLPC, min_freq(RPn) will not
> be requested.
> SLPC operating range today is (>Rpe, Rp0) so I wanted user to know
> the min_softlimit being initialized by SLPC by default.
Hmm, my mistake here was thinking this was more than a one off. Setting
the initial soft (user) range on startup is fine. Continually changing
them after userspace registration is not. (The value the user writes
into the limit is what should be read back - without very good reason,
such as the hard limits changing).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] lib: Make igt_command_line.sh selftest standalone
Allow the casual user to run igt_command_line.sh to discover what make
check is complaining about.
Signed-off-by: Chris Wilson
---
lib/tests/igt_command_line.sh | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/lib/tests/igt_command_line.sh b/lib/tests/igt_command_line.sh
index e83a548..35f580f 100755
--- a/lib/tests/igt_command_line.sh
+++ b/lib/tests/igt_command_line.sh
@@ -25,14 +25,22 @@
# Check that command line handling works consistently across all tests
#
+if [ -z "$top_builddir" ]; then
+ top_builddir="$(dirname $0)/../.."
+fi
+
TESTLIST=`cat $top_builddir/tests/test-list.txt`
if [ $? -ne 0 ]; then
echo "Error: Could not read test lists"
exit 99
fi
-for test in $TESTLIST; do
+fail () {
+ echo "FAIL: $1"
+ exit 1
+}
+for test in $TESTLIST; do
if [ "$test" = "TESTLIST" -o "$test" = "END" ]; then
continue
fi
@@ -48,29 +56,29 @@ for test in $TESTLIST; do
# check invalid option handling
echo " Checking invalid option handling..."
- ./$test --invalid-option 2> /dev/null && exit 1
+ ./$test --invalid-option 2> /dev/null && fail $test
# check valid options succeed
echo " Checking valid option handling..."
- ./$test --help > /dev/null || exit 1
+ ./$test --help > /dev/null || fail $test
# check --list-subtests works correctly
echo " Checking subtest enumeration..."
LIST=`./$test --list-subtests`
RET=$?
if [ $RET -ne 0 -a $RET -ne 79 ]; then
- exit 1
+ fail $test
fi
if [ $RET -eq 79 -a -n "$LIST" ]; then
- exit 1
+ fail $test
fi
if [ $RET -eq 0 -a -z "$LIST" ]; then
- exit 1
+ fail $test
fi
# check invalid subtest handling
echo " Checking invalid subtest handling..."
- ./$test --run-subtest invalid-subtest > /dev/null 2>&1 && exit 1
+ ./$test --run-subtest invalid-subtest > /dev/null 2>&1 && fail $test
done
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-next
Hi Dave, drm-intel-next-2016-08-22: - bugfixes and cleanups for rcu-protected requests (Chris) - atomic modeset fixes for gpu reset on pre-g4x (Maarten&Ville) - guc submission improvements (Dave Gordon) - panel power sequence cleanup (Imre) - better use of stolen and unmappable ggtt (Chris), plus prep work to make that happen - rework of framebuffer offsets, prep for multi-plane framebuffers (Ville) - fully partial ggtt vmaps, including fenced ones (Chris) - move lots more of the gem tracking from the object to the vma (Chris) - tune the command parser (Chris) - allow fbc without fences on recent platforms (Chris) - fbc frontbuffer tracking fixes (Chris) - fast prefaulting using io-mappping.h pgprot caching (Chris) Plus two fixups for io-mapping.h because gpiolib uses the wrong header. Chris is chasing 2 patches to fix that properly, this here at least avoids compile-breakage meanwhile. I tested on x86, arm and microblaze (to confirm the patch indeed fixes stuff). Cheers, Daniel The following changes since commit fc93ff608b15ae32cde3006b7af860b59cac20ec: Merge tag 'drm-intel-next-2016-08-08' of git://anongit.freedesktop.org/drm-intel into drm-next (2016-08-15 16:53:57 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel drm-intel-next for you to fetch changes up to 351243897b15aba02ad15317724d616aeaf00c7d: io-mapping: Fixup for different names of writecombine (2016-08-24 09:43:49 +0200) Chris Wilson (102): drm/i915: Remove unused i915_gem_active_peek_rcu() drm/i915: Wrap the protected active RCU dereference in a helper drm/i915: Don't check for idleness before retiring after a GPU hang drm/i915: Add smp_rmb() to busy ioctl's RCU dance drm/i915: Do not overwrite the request with zero on reallocation drm/i915: Correct typo for __i915_gem_active_get_rcu in a comment drm/i915: Always mark the writer as also a read for busy ioctl drm/i915: Move missed interrupt detection from hangcheck to breadcrumbs drm/i915: Use RCU to annotate and enforce protection for breadcrumb's bh drm/i915: Fix nesting of rps.mutex and struct_mutex during powersave init drm/i915: Mark unmappable GGTT entries as PIN_HIGH drm/i915: Move setting of request->batch into its single callsite drm/i915: Support for creating write combined type vmaps drm/i915: Use SSE4.1 movntdqa to accelerate reads from WC memory drm/i915: Initialize return value for empty i915_gem_object_unbind() drm/i915: Unbind closed vma for i915_gem_object_unbind() drm/i915: Show RPS autotuning thresholds along with waitboost drm/i915: Record the position of the start of the request drm/i915: Reduce amount of duplicate buffer information captured on error drm/i915: Store the active context object on all engines upon error drm/i915: Remove inactive/active list from debugfs drm/i915: Focus debugfs/i915_gem_pinned to show only display pins drm/i915: Reduce i915_gem_objects to only show object information drm/i915: Remove redundant WARN_ON from __i915_add_request() drm/i915: Always set the vma->pages drm/i915: Create a VMA for an object drm/i915: Add fetch_and_zero() macro drm/i915: Add convenience wrappers for vma's object get/put drm/i915: Track pinned vma inside guc drm/i915: Convert fence computations to use vma directly drm/i915: Use VMA directly for checking tiling parameters drm/i915: Use VMA as the primary object for context state drm/i915: Only change the context object's domain when binding drm/i915: Move assertion for iomap access to i915_vma_pin_iomap drm/i915: Use VMA for ringbuffer tracking drm/i915: Use VMA for scratch page tracking drm/i915: Move common scratch allocation/destroy to intel_engine_cs.c drm/i915: Move common seqno reset to intel_engine_cs.c drm/i915/overlay: Use VMA as the primary tracker for images drm/i915: Use VMA as the primary tracker for semaphore page drm/i915: Use VMA for render state page tracking drm/i915: Use VMA for wa_ctx tracking drm/i915: Consolidate i915_vma_unpin_and_release() drm/i915: Track pinned VMA drm/i915: Introduce i915_ggtt_offset() drm/i915: Move debug only per-request pid tracking from request to ctx drm/i915: Print the batchbuffer offset next to BBADDR in error state drm/i915: Only record active and pending requests upon a GPU hang drm/i915: Record the RING_MODE register for post-mortem debugging drm/i915: Initialise mmaped_count for i915_gem_object_info drm/i915: Embrace the race in busy-ioctl drm/i915: Silence GCC warning for cmn_a_well drm/i915: Mark the static key for movntqda as static drm/i915: Mark i915_hpd_poll_init_work as static drm/i915: Remember to set vma->pages fo
[Intel-gfx] [PATCH 1/2] drm/i915/fbdev: ORIGIN_GTT is only suitable for tracked writes
We can only use ORIGIN_GTT if the writes through the GTT can be tracked
by HW, i.e. if the region is fenced. If we do not fence the object,
declare the writes as originating from the CPU and do a full
invalidation.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_fbdev.c | 47 +++---
1 file changed, 23 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index b7098f98bb67..8d6bfa565b50 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -45,6 +45,19 @@
#include
#include "i915_drv.h"
+static void intel_fbdev_invalidate(struct intel_fbdev *ifbdev)
+{
+ struct drm_device *dev = ifbdev->helper.dev;
+ struct drm_i915_gem_object *obj = ifbdev->fb->obj;
+ unsigned int origin;
+
+ origin = i915_gem_object_is_tiled(obj) ? ORIGIN_GTT : ORIGIN_CPU;
+
+ mutex_lock(&dev->struct_mutex);
+ intel_fb_obj_invalidate(obj, origin);
+ mutex_unlock(&dev->struct_mutex);
+}
+
static int intel_fbdev_set_par(struct fb_info *info)
{
struct drm_fb_helper *fb_helper = info->par;
@@ -53,12 +66,8 @@ static int intel_fbdev_set_par(struct fb_info *info)
int ret;
ret = drm_fb_helper_set_par(info);
-
- if (ret == 0) {
- mutex_lock(&fb_helper->dev->struct_mutex);
- intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
- mutex_unlock(&fb_helper->dev->struct_mutex);
- }
+ if (ret == 0)
+ intel_fbdev_invalidate(ifbdev);
return ret;
}
@@ -71,12 +80,8 @@ static int intel_fbdev_blank(int blank, struct fb_info *info)
int ret;
ret = drm_fb_helper_blank(blank, info);
-
- if (ret == 0) {
- mutex_lock(&fb_helper->dev->struct_mutex);
- intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
- mutex_unlock(&fb_helper->dev->struct_mutex);
- }
+ if (ret == 0)
+ intel_fbdev_invalidate(ifbdev);
return ret;
}
@@ -89,13 +94,10 @@ static int intel_fbdev_pan_display(struct fb_var_screeninfo
*var,
container_of(fb_helper, struct intel_fbdev, helper);
int ret;
- ret = drm_fb_helper_pan_display(var, info);
- if (ret == 0) {
- mutex_lock(&fb_helper->dev->struct_mutex);
- intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
- mutex_unlock(&fb_helper->dev->struct_mutex);
- }
+ ret = drm_fb_helper_pan_display(var, info);
+ if (ret == 0)
+ intel_fbdev_invalidate(ifbdev);
return ret;
}
@@ -842,11 +844,8 @@ void intel_fbdev_restore_mode(struct drm_device *dev)
if (!ifbdev->fb)
return;
- if (drm_fb_helper_restore_fbdev_mode_unlocked(&ifbdev->helper)) {
+ if (drm_fb_helper_restore_fbdev_mode_unlocked(&ifbdev->helper))
DRM_DEBUG("failed to restore crtc mode\n");
- } else {
- mutex_lock(&dev->struct_mutex);
- intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
- mutex_unlock(&dev->struct_mutex);
- }
+ else
+ intel_fbdev_invalidate(ifbdev);
}
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/fbdev: Setup for using FBC tracking
When FBC is enabled, access through the fbdev is tracked using
ORIGIN_GTT, i.e. native hw tracking by FBC. This requires the
framebuffer to be fenced, which requires us to allocate the object
as X-tiled.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_fbdev.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 8d6bfa565b50..ad3995f87485 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -138,14 +138,17 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
mode_cmd.pitches[0] = ALIGN(mode_cmd.width *
DIV_ROUND_UP(sizes->surface_bpp, 8), 64);
+ if (i915.enable_fbc)
+ mode_cmd.pitches[0] = ALIGN(mode_cmd.pitches[0], 512);
+
mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
sizes->surface_depth);
- mutex_lock(&dev->struct_mutex);
-
size = mode_cmd.pitches[0] * mode_cmd.height;
size = PAGE_ALIGN(size);
+ mutex_lock(&dev->struct_mutex);
+
/* If the FB is too big, just don't use it since fbdev is not very
* important and we should probably use that space with FBC or other
* features. */
@@ -159,6 +162,12 @@ static int intelfb_alloc(struct drm_fb_helper *helper,
goto out;
}
+ if (i915.enable_fbc) {
+ obj->tiling_and_stride = mode_cmd.pitches[0] | I915_TILING_X;
+ mode_cmd.modifier[0] = I915_FORMAT_MOD_X_TILED;
+ mode_cmd.flags |= DRM_MODE_FB_MODIFIERS;
+ }
+
fb = __intel_framebuffer_create(dev, &mode_cmd, obj);
if (IS_ERR(fb)) {
i915_gem_object_put(obj);
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Replace initial plane_config.tiling with fb modifier
When determining the initial plane config we set the same information in
both the framebuffer (fb.modifier[0]) and in plane_config.tiling.
Ultimately, we only need the information in the framebuffer so remove
the redundant copy from plane_config.tiling
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 23 +++
drivers/gpu/drm/i915/intel_drv.h | 1 -
2 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d61c264d5a37..e363a68d97ed 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2700,7 +2700,7 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
return false;
}
- if (plane_config->tiling == I915_TILING_X)
+ if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
mode_cmd.pixel_format = fb->pixel_format;
@@ -8730,12 +8730,8 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
fb = &intel_fb->base;
- if (INTEL_INFO(dev)->gen >= 4) {
- if (val & DISPPLANE_TILED) {
- plane_config->tiling = I915_TILING_X;
- fb->modifier[0] = I915_FORMAT_MOD_X_TILED;
- }
- }
+ if (INTEL_GEN(dev) >= 4 && val & DISPPLANE_TILED)
+ fb->modifier[0] = I915_FORMAT_MOD_X_TILED;
pixel_format = val & DISPPLANE_PIXFORMAT_MASK;
fourcc = i9xx_format_to_fourcc(pixel_format);
@@ -8743,7 +8739,7 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
fb->bits_per_pixel = drm_format_plane_cpp(fourcc, 0) * 8;
if (INTEL_INFO(dev)->gen >= 4) {
- if (plane_config->tiling)
+ if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
offset = I915_READ(DSPTILEOFF(plane));
else
offset = I915_READ(DSPLINOFF(plane));
@@ -9756,7 +9752,6 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
fb->modifier[0] = DRM_FORMAT_MOD_NONE;
break;
case PLANE_CTL_TILED_X:
- plane_config->tiling = I915_TILING_X;
fb->modifier[0] = I915_FORMAT_MOD_X_TILED;
break;
case PLANE_CTL_TILED_Y:
@@ -9851,12 +9846,8 @@ ironlake_get_initial_plane_config(struct intel_crtc
*crtc,
fb = &intel_fb->base;
- if (INTEL_INFO(dev)->gen >= 4) {
- if (val & DISPPLANE_TILED) {
- plane_config->tiling = I915_TILING_X;
- fb->modifier[0] = I915_FORMAT_MOD_X_TILED;
- }
- }
+ if (INTEL_GEN(dev) >= 4 && val & DISPPLANE_TILED)
+ fb->modifier[0] = I915_FORMAT_MOD_X_TILED;
pixel_format = val & DISPPLANE_PIXFORMAT_MASK;
fourcc = i9xx_format_to_fourcc(pixel_format);
@@ -9867,7 +9858,7 @@ ironlake_get_initial_plane_config(struct intel_crtc *crtc,
if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
offset = I915_READ(DSPOFFSET(pipe));
} else {
- if (plane_config->tiling)
+ if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
offset = I915_READ(DSPTILEOFF(pipe));
else
offset = I915_READ(DSPLINOFF(pipe));
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 37cad7c779b3..3ee156aab938 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -400,7 +400,6 @@ struct intel_plane_state {
struct intel_initial_plane_config {
struct intel_framebuffer *fb;
- unsigned int tiling;
int size;
u32 base;
};
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Populate Y-tiling from initial plane state
It is possible that from Skylake onwards the initial plane is tiled in
some other format than X. Copy across this information to the object
when such formats are fence-able.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e363a68d97ed..187e499107af 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2700,8 +2700,15 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
return false;
}
- if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
- obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
+ if (fb->modifier[0]) {
+ obj->tiling_and_stride = fb->pitches[0];
+ if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
+ obj->tiling_and_stride |= I915_TILING_X;
+ else if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED)
+ obj->tiling_and_stride |= I915_TILING_Y;
+ else
+ obj->tiling_and_stride = 0; /* unfenced tiling mode */
+ }
mode_cmd.pixel_format = fb->pixel_format;
mode_cmd.width = fb->width;
--
2.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 4/4] drm/i915: start adding dp mst audio
From: Libin Yang
(This patch is developed by Dave Airlie originally)
This patch adds support for DP MST audio in i915.
Enable audio codec when DP MST is enabled if has_audio flag is set.
Disable audio codec when DP MST is disabled if has_audio flag is set.
Another separated patches to support DP MST audio will be implemented
in audio driver.
Signed-off-by: Libin Yang
Reviewed-by: Lyude
---
drivers/gpu/drm/i915/i915_debugfs.c | 19 ++-
drivers/gpu/drm/i915/intel_ddi.c| 20 +++-
drivers/gpu/drm/i915/intel_dp_mst.c | 21 +
drivers/gpu/drm/i915/intel_drv.h| 2 ++
4 files changed, 56 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d0b4c74..8ec69d0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2925,6 +2925,20 @@ static void intel_dp_info(struct seq_file *m,
intel_panel_info(m, &intel_connector->panel);
}
+static void intel_dp_mst_info(struct seq_file *m,
+ struct intel_connector *intel_connector)
+{
+ struct intel_encoder *intel_encoder = intel_connector->encoder;
+ struct intel_dp_mst_encoder *intel_mst =
+ enc_to_mst(&intel_encoder->base);
+ struct intel_digital_port *intel_dig_port = intel_mst->primary;
+ struct intel_dp *intel_dp = &intel_dig_port->dp;
+ bool has_audio = drm_dp_mst_port_has_audio(&intel_dp->mst_mgr,
+ intel_connector->port);
+
+ seq_printf(m, "\taudio support: %s\n", yesno(has_audio));
+}
+
static void intel_hdmi_info(struct seq_file *m,
struct intel_connector *intel_connector)
{
@@ -2967,7 +2981,10 @@ static void intel_connector_info(struct seq_file *m,
switch (connector->connector_type) {
case DRM_MODE_CONNECTOR_DisplayPort:
case DRM_MODE_CONNECTOR_eDP:
- intel_dp_info(m, intel_connector);
+ if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
+ intel_dp_mst_info(m, intel_connector);
+ else
+ intel_dp_info(m, intel_connector);
break;
case DRM_MODE_CONNECTOR_LVDS:
if (intel_encoder->type == INTEL_OUTPUT_LVDS)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 402755d..a0253cf 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2173,6 +2173,19 @@ void intel_ddi_fdi_disable(struct drm_crtc *crtc)
I915_WRITE(FDI_RX_CTL(PIPE_A), val);
}
+bool intel_ddi_is_audio_enabled(struct drm_i915_private *dev_priv,
+struct intel_crtc *intel_crtc)
+{
+ u32 temp;
+
+ if (intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO)) {
+ temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
+ if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
+ return true;
+ }
+ return false;
+}
+
void intel_ddi_get_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config)
{
@@ -2238,11 +2251,8 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
break;
}
- if (intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_AUDIO)) {
- temp = I915_READ(HSW_AUD_PIN_ELD_CP_VLD);
- if (temp & AUDIO_OUTPUT_ENABLE(intel_crtc->pipe))
- pipe_config->has_audio = true;
- }
+ pipe_config->has_audio =
+ intel_ddi_is_audio_enabled(dev_priv, intel_crtc);
if (encoder->type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.bpp &&
pipe_config->pipe_bpp > dev_priv->vbt.edp.bpp) {
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index d1d7e91..d3d774d 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -76,6 +76,8 @@ static bool intel_dp_mst_compute_config(struct intel_encoder
*encoder,
return false;
}
+ if (drm_dp_mst_port_has_audio(&intel_dp->mst_mgr, found->port))
+ pipe_config->has_audio = true;
mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
pipe_config->pbn = mst_pbn;
@@ -97,6 +99,10 @@ static void intel_mst_disable_dp(struct intel_encoder
*encoder)
struct intel_dp_mst_encoder *intel_mst = enc_to_mst(&encoder->base);
struct intel_digital_port *intel_dig_port = intel_mst->primary;
struct intel_dp *intel_dp = &intel_dig_port->dp;
+ struct drm_device *dev = encoder->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_crtc *crtc = encoder->base.crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
int ret;
DRM_DEBUG_KMS("%d\n", intel_dp->active_mst_links);
[Intel-gfx] [PATCH v4 2/4] drm/i915: Switch to using port stored in intel_encoder
Now that we have the port enum stored in intel_encoder, use that instead of
dereferencing intel_dig_port. Saves us a few locals.
struct intel_encoder variables have been renamed to be consistent and
convey type information.
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_audio.c | 39 +++---
1 file changed, 15 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index d32f586..5a41439 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -276,17 +276,15 @@ static void hsw_audio_codec_disable(struct intel_encoder
*encoder)
}
static void hsw_audio_codec_enable(struct drm_connector *connector,
- struct intel_encoder *encoder,
+ struct intel_encoder *intel_encoder,
const struct drm_display_mode *adjusted_mode)
{
struct drm_i915_private *dev_priv = to_i915(connector->dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
+ struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc);
enum pipe pipe = intel_crtc->pipe;
+ enum port port = intel_encoder->attached_port;
struct i915_audio_component *acomp = dev_priv->audio_component;
const uint8_t *eld = connector->eld;
- struct intel_digital_port *intel_dig_port =
- enc_to_dig_port(&encoder->base);
- enum port port = intel_dig_port->port;
uint32_t tmp;
int len, i;
int n, rate;
@@ -355,14 +353,12 @@ static void hsw_audio_codec_enable(struct drm_connector
*connector,
mutex_unlock(&dev_priv->av_mutex);
}
-static void ilk_audio_codec_disable(struct intel_encoder *encoder)
+static void ilk_audio_codec_disable(struct intel_encoder *intel_encoder)
{
- struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
- struct intel_digital_port *intel_dig_port =
- enc_to_dig_port(&encoder->base);
- enum port port = intel_dig_port->port;
+ struct drm_i915_private *dev_priv = to_i915(intel_encoder->base.dev);
+ struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc);
enum pipe pipe = intel_crtc->pipe;
+ enum port port = intel_encoder->attached_port;
uint32_t tmp, eldv;
i915_reg_t aud_config, aud_cntrl_st2;
@@ -402,18 +398,15 @@ static void ilk_audio_codec_disable(struct intel_encoder
*encoder)
}
static void ilk_audio_codec_enable(struct drm_connector *connector,
- struct intel_encoder *encoder,
+ struct intel_encoder *intel_encoder,
const struct drm_display_mode *adjusted_mode)
{
struct drm_i915_private *dev_priv = to_i915(connector->dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
- struct intel_digital_port *intel_dig_port =
- enc_to_dig_port(&encoder->base);
- enum port port = intel_dig_port->port;
+ struct intel_crtc *intel_crtc = to_intel_crtc(intel_encoder->base.crtc);
enum pipe pipe = intel_crtc->pipe;
+ enum port port = intel_encoder->attached_port;
uint8_t *eld = connector->eld;
- uint32_t eldv;
- uint32_t tmp;
+ uint32_t tmp, eldv;
int len, i;
i915_reg_t hdmiw_hdmiedid, aud_config, aud_cntl_st, aud_cntrl_st2;
@@ -495,11 +488,10 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder)
struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
const struct drm_display_mode *adjusted_mode =
&crtc->config->base.adjusted_mode;
struct drm_connector *connector;
- struct drm_device *dev = encoder->dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct i915_audio_component *acomp = dev_priv->audio_component;
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
- enum port port = intel_dig_port->port;
+ enum port port = intel_encoder->attached_port;
connector = drm_select_eld(encoder);
if (!connector)
@@ -542,11 +534,10 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder)
void intel_audio_codec_disable(struct intel_encoder *intel_encoder)
{
struct drm_encoder *encoder = &intel_encoder->base;
- struct drm_device *dev = encoder->dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct i915_audio_component *acomp = dev_priv->audio_component;
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
- enum port port = intel_dig_port->port;
+ enum por
[Intel-gfx] [PATCH v4 3/4] drm/i915: Move audio_connector to intel_encoder
With DP MST, a digital_port can carry more than one audio stream. Hence,
more than one audio_connector needs to be attached to intel_digital_port in
such cases. However, each stream is associated with an unique encoder. So,
instead of creating an array of audio_connectors per port, move
audio_connector from struct intel_digital_port to struct intel_encoder.
This also simplifies access to the right audio_connector from codec
functions in intel_audio.c that receive intel_encoder.
v2: Removed locals that are not needed anymore.
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_audio.c | 12
drivers/gpu/drm/i915/intel_drv.h | 4 ++--
2 files changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 5a41439..b86bfad 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -490,7 +490,6 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder)
struct drm_connector *connector;
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct i915_audio_component *acomp = dev_priv->audio_component;
- struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
enum port port = intel_encoder->attached_port;
connector = drm_select_eld(encoder);
@@ -515,7 +514,7 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder)
adjusted_mode);
mutex_lock(&dev_priv->av_mutex);
- intel_dig_port->audio_connector = connector;
+ intel_encoder->audio_connector = connector;
/* referred in audio callbacks */
dev_priv->dig_port_map[port] = intel_encoder;
mutex_unlock(&dev_priv->av_mutex);
@@ -536,14 +535,13 @@ void intel_audio_codec_disable(struct intel_encoder
*intel_encoder)
struct drm_encoder *encoder = &intel_encoder->base;
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct i915_audio_component *acomp = dev_priv->audio_component;
- struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
enum port port = intel_encoder->attached_port;
if (dev_priv->display.audio_codec_disable)
dev_priv->display.audio_codec_disable(intel_encoder);
mutex_lock(&dev_priv->av_mutex);
- intel_dig_port->audio_connector = NULL;
+ intel_encoder->audio_connector = NULL;
dev_priv->dig_port_map[port] = NULL;
mutex_unlock(&dev_priv->av_mutex);
@@ -704,7 +702,6 @@ static int i915_audio_component_get_eld(struct device *dev,
int port,
{
struct drm_i915_private *dev_priv = dev_to_i915(dev);
struct intel_encoder *intel_encoder;
- struct intel_digital_port *intel_dig_port;
const u8 *eld;
int ret = -EINVAL;
@@ -713,10 +710,9 @@ static int i915_audio_component_get_eld(struct device
*dev, int port,
/* intel_encoder might be NULL for DP MST */
if (intel_encoder) {
ret = 0;
- intel_dig_port = enc_to_dig_port(&intel_encoder->base);
- *enabled = intel_dig_port->audio_connector != NULL;
+ *enabled = intel_encoder->audio_connector != NULL;
if (*enabled) {
- eld = intel_dig_port->audio_connector->eld;
+ eld = intel_encoder->audio_connector->eld;
ret = drm_eld_size(eld);
memcpy(buf, eld, min(max_bytes, ret));
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 68bf134..30186bf 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -232,6 +232,8 @@ struct intel_encoder {
void (*suspend)(struct intel_encoder *);
int crtc_mask;
enum hpd_pin hpd_pin;
+ /* for communication with audio component; protected by av_mutex */
+ const struct drm_connector *audio_connector;
};
struct intel_panel {
@@ -948,8 +950,6 @@ struct intel_digital_port {
enum irqreturn (*hpd_pulse)(struct intel_digital_port *, bool);
bool release_cl2_override;
uint8_t max_lanes;
- /* for communication with audio component; protected by av_mutex */
- const struct drm_connector *audio_connector;
};
struct intel_dp_mst_encoder {
--
2.5.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 0/4] Prep. for DP audio MST support
This series lays the groundwork for more DP MST audio work that will follow. v2: Different solution replacing the enc_to_dig_port() fix (Ville, Lyude). No changes to MST audio enabling and move audio_connector patches. Reordered the patches (Lyude) v3: Different solution to get port from encoder (danvet). Removed locals that are not needed any more. Minor variable renaming clean up. Rebased on dinq. Retained r-b for "start adding dp mst audio" as it does not change. v4: Fixed missing port initialization in intel_sdvo.c Renamed the port enum member from 'attached_port' to 'port' Fixed commit message typos. Dhinakaran Pandiyan (3): drm/i915: Store port enum in intel_encoder drm/i915: Switch to using port stored in intel_encoder drm/i915: Move audio_connector to intel_encoder Libin Yang (1): drm/i915: start adding dp mst audio drivers/gpu/drm/i915/i915_debugfs.c | 19 +- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_audio.c | 51 ++--- drivers/gpu/drm/i915/intel_ddi.c| 21 +++ drivers/gpu/drm/i915/intel_dp.c | 1 + drivers/gpu/drm/i915/intel_dp_mst.c | 22 drivers/gpu/drm/i915/intel_drv.h| 7 +++-- drivers/gpu/drm/i915/intel_dsi.c| 1 + drivers/gpu/drm/i915/intel_dvo.c| 2 ++ drivers/gpu/drm/i915/intel_hdmi.c | 1 + drivers/gpu/drm/i915/intel_lvds.c | 3 ++- drivers/gpu/drm/i915/intel_sdvo.c | 1 + drivers/gpu/drm/i915/intel_tv.c | 2 ++ 13 files changed, 91 insertions(+), 41 deletions(-) -- 2.5.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/4] drm/i915: Store port enum in intel_encoder
Storing the port enum in intel_encoder makes it convenient to know the
port attached to an encoder. Moving the port information up from
intel_digital_port to intel_encoder avoids unecessary intel_digital_port
access and handles MST encoders cleanly without requiring conditional
checks for them (thanks danvet).
v2:
Renamed the port enum member from 'attached_port' to 'port' (danvet)
Fixed missing initialization of port in intel_sdvo.c (danvet)
Signed-off-by: Dhinakaran Pandiyan
Cc: Daniel Vetter
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c| 1 +
drivers/gpu/drm/i915/intel_dp.c | 1 +
drivers/gpu/drm/i915/intel_dp_mst.c | 1 +
drivers/gpu/drm/i915/intel_drv.h| 1 +
drivers/gpu/drm/i915/intel_dsi.c| 1 +
drivers/gpu/drm/i915/intel_dvo.c| 2 ++
drivers/gpu/drm/i915/intel_hdmi.c | 1 +
drivers/gpu/drm/i915/intel_lvds.c | 3 ++-
drivers/gpu/drm/i915/intel_sdvo.c | 1 +
drivers/gpu/drm/i915/intel_tv.c | 2 ++
11 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9cd102c..60e282d5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -185,6 +185,7 @@ enum plane {
#define sprite_name(p, s) ((p) * INTEL_INFO(dev)->num_sprites[(p)] + (s) + 'A')
enum port {
+ PORT_NONE = -1,
PORT_A = 0,
PORT_B,
PORT_C,
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index c2df4e4..402755d 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2426,6 +2426,7 @@ void intel_ddi_init(struct drm_device *dev, enum port
port)
intel_dig_port->max_lanes = max_lanes;
intel_encoder->type = INTEL_OUTPUT_UNKNOWN;
+ intel_encoder->port = port;
intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
intel_encoder->cloneable = 0;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 364db90..cfe2f4a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5726,6 +5726,7 @@ bool intel_dp_init(struct drm_device *dev,
intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
}
intel_encoder->cloneable = 0;
+ intel_encoder->port = port;
intel_dig_port->hpd_pulse = intel_dp_hpd_pulse;
dev_priv->hotplug.irq_port[port] = intel_dig_port;
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 629337d..d1d7e91 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -540,6 +540,7 @@ intel_dp_create_fake_mst_encoder(struct intel_digital_port
*intel_dig_port, enum
DRM_MODE_ENCODER_DPMST, "DP-MST %c", pipe_name(pipe));
intel_encoder->type = INTEL_OUTPUT_DP_MST;
+ intel_encoder->port = intel_dig_port->port;
intel_encoder->crtc_mask = 0x7;
intel_encoder->cloneable = 0;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1c700b0..68bf134 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -202,6 +202,7 @@ struct intel_encoder {
struct drm_encoder base;
enum intel_output_type type;
+ enum port port;
unsigned int cloneable;
void (*hot_plug)(struct intel_encoder *);
bool (*compute_config)(struct intel_encoder *,
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index de8e9fb..eb5cc0b 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1478,6 +1478,7 @@ void intel_dsi_init(struct drm_device *dev)
intel_connector->get_hw_state = intel_connector_get_hw_state;
+ intel_encoder->port = port;
/*
* On BYT/CHV, pipe A maps to MIPI DSI port A, pipe B maps to MIPI DSI
* port C. BXT isn't limited like this.
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 47bdf9d..6dc2791 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
+++ b/drivers/gpu/drm/i915/intel_dvo.c
@@ -511,7 +511,9 @@ void intel_dvo_init(struct drm_device *dev)
"DVO %c", intel_dvo_port_name(dvo->dvo_reg));
intel_encoder->type = INTEL_OUTPUT_DVO;
+ intel_encoder->port = PORT_NONE;
intel_encoder->crtc_mask = (1 << 0) | (1 << 1);
+
switch (dvo->type) {
case INTEL_DVO_CHIP_TMDS:
intel_encoder->cloneable = (1 << INTEL_OUTPUT_ANALOG) |
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 4df9f38..25eeac3 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1962,6 +1962,7 @@ void intel_hdmi_init(struct drm_device *dev,
}
intel_encoder->type = INTEL_
