Re: [Intel-gfx] [PATCH 2/2] drm/i915: Make GPU pages movable
On 11/10/2016 12:09 PM, Hugh Dickins wrote:
On Fri, 4 Nov 2016, akash.g...@intel.com wrote:
From: Chris Wilson
On a long run of more than 2-3 days, physical memory tends to get
fragmented severely, which considerably slows down the system. In such a
scenario, the shrinker is also unable to help as lack of memory is not
the actual problem, since it has been observed that there are enough free
pages of 0 order. This also manifests itself when an indiviual zone in
the mm runs out of pages and if we cannot migrate pages between zones,
the kernel hits an out-of-memory even though there are free pages (and
often all of swap) available.
To address the issue of external fragementation, kernel does a compaction
(which involves migration of pages) but it's efficacy depends upon how
many pages are marked as MOVABLE, as only those pages can be migrated.
Currently the backing pages for GPU buffers are allocated from shmemfs
with GFP_RECLAIMABLE flag, in units of 4KB pages. In the case of limited
swap space, it may not be possible always to reclaim or swap-out pages of
all the inactive objects, to make way for free space allowing formation
of higher order groups of physically-contiguous pages on compaction.
Just marking the GPU pages as MOVABLE will not suffice, as i915.ko has to
pin the pages if they are in use by GPU, which will prevent their
migration. So the migratepage callback in shmem is also hooked up to get
a notification when kernel initiates the page migration. On the
notification, i915.ko appropriately unpin the pages. With this we can
effectively mark the GPU pages as MOVABLE and hence mitigate the
fragmentation problem.
v2:
- Rename the migration routine to gem_shrink_migratepage, move it to the
shrinker file, and use the existing constructs (Chris)
- To cleanup, add a new helper function to encapsulate all page migration
skip conditions (Chris)
- Add a new local helper function in shrinker file, for dropping the
backing pages, and call the same from gem_shrink() also (Chris)
v3:
- Fix/invert the check on the return value of unsafe_drop_pages (Chris)
v4:
- Minor tidy
v5:
- Fix unsafe usage of unsafe_drop_pages()
- Rebase onto vmap-notifier
v6:
- Remove i915_gem_object_get/put across unsafe_drop_pages() as with
struct_mutex protection object can't disappear. (Chris)
Testcase: igt/gem_shrink
Bugzilla: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=90254
Cc: Hugh Dickins
Cc: linux...@kvack.org
Signed-off-by: Sourab Gupta
Signed-off-by: Akash Goel
Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Reviewed-by: Chris Wilson
I'm confused! But perhaps it's gone around and around between you all,
I'm not sure what the rules are then. I think this sequence implies
that Sourab wrote it originally, then Akash and Chris passed it on
with refinements - but then Chris wouldn't add Reviewed-by.
Thank you very much for the review and sorry for all the needless confusion.
Chris actually conceived the patches and prepared an initial version of
them (hence he is the Author).
I & Sourab did the further refinements and fixed issues (all those
page_private stuff).
Chris then reviewed the final patch and also recently did a rebase for it.
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 9 ++-
drivers/gpu/drm/i915/i915_gem_shrinker.c | 132 +++
3 files changed, 142 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4735b417..7f2717b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1357,6 +1357,8 @@ struct intel_l3_parity {
};
struct i915_gem_mm {
+ struct shmem_dev_info shmem_info;
+
/** Memory allocator for GTT stolen memory */
struct drm_mm stolen;
/** Protects the usage of the GTT stolen memory allocator. This is
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1f995ce..f0d4ce7 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2164,6 +2164,7 @@ void __i915_gem_object_invalidate(struct
drm_i915_gem_object *obj)
if (obj->mm.madv == I915_MADV_WILLNEED)
mark_page_accessed(page);
+ set_page_private(page, 0);
put_page(page);
}
obj->mm.dirty = false;
@@ -2310,6 +2311,7 @@ static unsigned int swiotlb_max_size(void)
sg->length += PAGE_SIZE;
}
last_pfn = page_to_pfn(page);
+ set_page_private(page, (unsigned long)obj);
/* Check that the i965g/gm workaround works. */
WARN_ON((gfp & __GFP_DMA32) && (last_pfn >= 0x0010UL));
@@ -2334,8 +2336,10 @@ static unsigned int swiotlb_max_size(void)
err_pages:
sg_mark_end(sg);
- for_each_sgt_page(page, sgt_iter, st)
+ for_each_sgt_page(page,
[Intel-gfx] [PULL] topic/drm-misc
Hi Dave, - better atomic state debugging from Rob - fence prep from gustavo - sumits flushed out his backlog of pending dma-buf/fence patches from various people - drm_mm leak debugging plus trying to appease Kconfig (Chris) - a few misc things all over Cheers, Daniel The following changes since commit fb422950c6cd726fd36eb72a7cf84583440a18a2: Merge branch 'linux-4.9' of git://github.com/skeggsb/linux into drm-next (2016-10-28 14:24:56 +1000) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-11-10 for you to fetch changes up to 4b514e10157a8e34a5e909487ef6fb8342e2e3ad: drm: Make DRM_DEBUG_MM depend on STACKTRACE_SUPPORT (2016-11-09 17:27:54 +0100) Alex Deucher (2): dma-buf/fence: make timeout handling in fence_default_wait consistent (v2) dma-buf/fence: revert "don't wait when specified timeout is zero" (v2) Baoyou Xie (1): dma-buf/sw_sync: mark sync_timeline_create() static Chris Wilson (6): drm: Track drm_mm allocators and show leaks on shutdown drm/i915: Enable drm_mm debug when enabling DRM_I915_DEBUG drm: Add stackdepot include for DRM_DEBUG_MM drm: Restrict stackdepot usage to builtin drm.ko drm/i915: Restrict DRM_DEBUG_MM automatic selection drm: Make DRM_DEBUG_MM depend on STACKTRACE_SUPPORT Christian König (2): drm/ttm: fix ttm_bo_wait reservation: revert "wait only with non-zero timeout specified (v3)" v2 Gustavo Padovan (6): drm/atomic: add drm_atomic_set_fence_for_plane() drm/imx: use drm_atomic_set_fence_for_plane() to set the fence drm/msm: use drm_atomic_set_fence_for_plane() to set the fence drm/plane: add inline doc for struct drm_plane dma-buf/sw_sync: put fence reference from the fence creation MAINTAINERS: update Sync File Framework files Jani Nikula (1): drm: define drm_compat_ioctl NULL on CONFIG_COMPAT=n and reduce #ifdefs Jiang Biao (2): drm/gma500: make function static to eliminate compiling warning drm/gma500: remove unused ioctl declarations Junwei Zhang (1): drm/amdgpu: add the interface of waiting multiple fences (v4) Patrik Jakobsson (1): drm/gma500: Add compat ioctl Rob Clark (8): drm: don't override possible_crtcs for primary/cursor planes drm: helper macros to print composite types drm: add helper for printing to log or seq_file drm: add helpers to go from plane state to drm_rect drm/atomic: add new drm_debug bit to dump atomic state drm/atomic: add debugfs file to dump out atomic state drm/msm/mdp5: add atomic_print_state support drm/msm: module param to dump state on error irq Rongrong Zou (1): drm: update the documentation of drm_framebuffer_unregister_private Stefan Agner (1): drm/atomic-helper: fix reference to drm_atomic_helper_commit_planes Ville Syrjälä (2): drm/edid: Add the missing "Hz" to VIC 58,59 comment drm/uapi: Add a warning that mode flags must match the xrandr definitions monk.liu (1): dma-buf: return index of the first signaled fence (v2) Documentation/gpu/drm-internals.rst | 17 +++ MAINTAINERS | 4 +- drivers/dma-buf/dma-fence.c | 32 ++-- drivers/dma-buf/reservation.c | 5 +- drivers/dma-buf/sw_sync.c | 4 +- drivers/gpu/drm/Kconfig | 14 ++ drivers/gpu/drm/Makefile| 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 + drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 174 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c | 3 +- drivers/gpu/drm/arc/arcpgu_drv.c| 2 - drivers/gpu/drm/arm/hdlcd_drv.c | 2 - drivers/gpu/drm/arm/malidp_drv.c| 2 - drivers/gpu/drm/ast/ast_drv.c | 2 - drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c| 2 - drivers/gpu/drm/bochs/bochs_drv.c | 2 - drivers/gpu/drm/cirrus/cirrus_drv.c | 2 - drivers/gpu/drm/drm_atomic.c| 186 drivers/gpu/drm/drm_crtc.c | 4 +- drivers/gpu/drm/drm_debugfs.c | 9 ++ drivers/gpu/drm/drm_edid.c | 4 +- drivers/gpu/drm/drm_fops.c | 13 +- drivers/gpu/drm/drm_framebuffer.c | 5 + drivers/gpu/drm/drm_mm.c| 76 +- drivers/gpu/drm/drm_modes.c | 8 +- drivers/gpu/drm/drm_plane_helper.c | 11 +- drivers/gpu/drm/drm_print.c | 54 +++ drivers/gpu/drm/drm_rect.c | 11 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 - drive
Re: [Intel-gfx] [PATCH v3 04/11] drm/i915/gen9+: Kill off hw_ddb from intel_crtc.
Op 10-11-16 om 01:52 schreef Matt Roper:
> On Tue, Nov 08, 2016 at 01:55:35PM +0100, Maarten Lankhorst wrote:
>> This member is only used in skl_update_crtcs now. It's easy to remove it
>> by keeping track of which ddb entries in an array, and update them after
> I'm having trouble parsing this line...not sure if you have an extra
> word or are missing a word. But I think what you meant is that you're
> snapshotting the DDB values at the beginning of this function so that
> you'll have a copy of what the 'old' values that were already in the
> hardware , then you update that snapshot as you write the DDB for pipe
> to the hardware?
>
>> we update the crtc. This removes the last bits of SKL-style watermarks
>> kept outside of crtc_state.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 15 ---
>> drivers/gpu/drm/i915/intel_drv.h | 11 +++
>> drivers/gpu/drm/i915/intel_pm.c | 25 +++--
>> 3 files changed, 22 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 69f9addb29b3..e59adb03933e 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -14280,6 +14280,14 @@ static void skl_update_crtcs(struct
>> drm_atomic_state *state,
>> unsigned int updated = 0;
>> bool progress;
>> enum pipe pipe;
>> +int i;
>> +
>> +const struct skl_ddb_entry *entries[I915_MAX_PIPES] = {};
> Do we want this to be const?
What is intended here is that the struct skl_ddb_entry is const. The pointers
can be reassigned,
and point to either before state or after state, but the values are unmodified.
:)
>> +
>> +for_each_crtc_in_state(state, crtc, old_crtc_state, i)
>> +/* ignore allocations for crtc's that have been turned off. */
>> +if (crtc->state->active)
>> +entries[i] =
>> &to_intel_crtc_state(old_crtc_state)->wm.skl.ddb;
>>
>> /*
>> * Whenever the number of active pipes changes, we need to make sure we
>> @@ -14288,7 +14296,6 @@ static void skl_update_crtcs(struct drm_atomic_state
>> *state,
>> * cause pipe underruns and other bad stuff.
>> */
>> do {
>> -int i;
>> progress = false;
>>
>> for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
>> @@ -14299,12 +14306,14 @@ static void skl_update_crtcs(struct
>> drm_atomic_state *state,
>> cstate = to_intel_crtc_state(crtc->state);
>> pipe = intel_crtc->pipe;
>>
>> -if (updated & cmask || !crtc->state->active)
>> +if (updated & cmask || !cstate->base.active)
> This change seems unrelated/unnecessary? cstate was just set a couple
> lines above, so this is effectively just replacing crtc->state with
> to_intel_crtc_state(crtc->state)->base.
I'm planning to replace all iterations over state with a new macro that has old
and new state,
in which case dereferencing crtc->state directly becomes unneeded and dangerous
if we ever
implement queue depth > 1.
I also plan to add some new macros that can pull the new obj->state from
drm_atomic_state, or
(with locking verification) from the current state. This should kill all direct
obj->state
dereferences.
It's the same conversion we did with dev -> dev_priv cleanups, I try to sneak
those conversions
in where it makes sense. :)
~Maarten
___
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: Make GPU pages movable
On Fri, 4 Nov 2016, akash.g...@intel.com wrote:
> From: Chris Wilson
>
> On a long run of more than 2-3 days, physical memory tends to get
> fragmented severely, which considerably slows down the system. In such a
> scenario, the shrinker is also unable to help as lack of memory is not
> the actual problem, since it has been observed that there are enough free
> pages of 0 order. This also manifests itself when an indiviual zone in
> the mm runs out of pages and if we cannot migrate pages between zones,
> the kernel hits an out-of-memory even though there are free pages (and
> often all of swap) available.
>
> To address the issue of external fragementation, kernel does a compaction
> (which involves migration of pages) but it's efficacy depends upon how
> many pages are marked as MOVABLE, as only those pages can be migrated.
>
> Currently the backing pages for GPU buffers are allocated from shmemfs
> with GFP_RECLAIMABLE flag, in units of 4KB pages. In the case of limited
> swap space, it may not be possible always to reclaim or swap-out pages of
> all the inactive objects, to make way for free space allowing formation
> of higher order groups of physically-contiguous pages on compaction.
>
> Just marking the GPU pages as MOVABLE will not suffice, as i915.ko has to
> pin the pages if they are in use by GPU, which will prevent their
> migration. So the migratepage callback in shmem is also hooked up to get
> a notification when kernel initiates the page migration. On the
> notification, i915.ko appropriately unpin the pages. With this we can
> effectively mark the GPU pages as MOVABLE and hence mitigate the
> fragmentation problem.
>
> v2:
> - Rename the migration routine to gem_shrink_migratepage, move it to the
>shrinker file, and use the existing constructs (Chris)
> - To cleanup, add a new helper function to encapsulate all page migration
>skip conditions (Chris)
> - Add a new local helper function in shrinker file, for dropping the
>backing pages, and call the same from gem_shrink() also (Chris)
>
> v3:
> - Fix/invert the check on the return value of unsafe_drop_pages (Chris)
>
> v4:
> - Minor tidy
>
> v5:
> - Fix unsafe usage of unsafe_drop_pages()
> - Rebase onto vmap-notifier
>
> v6:
> - Remove i915_gem_object_get/put across unsafe_drop_pages() as with
> struct_mutex protection object can't disappear. (Chris)
>
> Testcase: igt/gem_shrink
> Bugzilla: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=90254
> Cc: Hugh Dickins
> Cc: linux...@kvack.org
> Signed-off-by: Sourab Gupta
> Signed-off-by: Akash Goel
> Signed-off-by: Chris Wilson
> Reviewed-by: Joonas Lahtinen
> Reviewed-by: Chris Wilson
I'm confused! But perhaps it's gone around and around between you all,
I'm not sure what the rules are then. I think this sequence implies
that Sourab wrote it originally, then Akash and Chris passed it on
with refinements - but then Chris wouldn't add Reviewed-by.
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/i915_gem.c | 9 ++-
> drivers/gpu/drm/i915/i915_gem_shrinker.c | 132
> +++
> 3 files changed, 142 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4735b417..7f2717b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1357,6 +1357,8 @@ struct intel_l3_parity {
> };
>
> struct i915_gem_mm {
> + struct shmem_dev_info shmem_info;
> +
> /** Memory allocator for GTT stolen memory */
> struct drm_mm stolen;
> /** Protects the usage of the GTT stolen memory allocator. This is
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 1f995ce..f0d4ce7 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2164,6 +2164,7 @@ void __i915_gem_object_invalidate(struct
> drm_i915_gem_object *obj)
> if (obj->mm.madv == I915_MADV_WILLNEED)
> mark_page_accessed(page);
>
> + set_page_private(page, 0);
> put_page(page);
> }
> obj->mm.dirty = false;
> @@ -2310,6 +2311,7 @@ static unsigned int swiotlb_max_size(void)
> sg->length += PAGE_SIZE;
> }
> last_pfn = page_to_pfn(page);
> + set_page_private(page, (unsigned long)obj);
>
> /* Check that the i965g/gm workaround works. */
> WARN_ON((gfp & __GFP_DMA32) && (last_pfn >= 0x0010UL));
> @@ -2334,8 +2336,10 @@ static unsigned int swiotlb_max_size(void)
>
> err_pages:
> sg_mark_end(sg);
> - for_each_sgt_page(page, sgt_iter, st)
> + for_each_sgt_page(page, sgt_iter, st) {
> + set_page_private(page, 0);
> put_page(page);
> + }
> sg_free_table(st);
> kfree(st);
>
I think your page_private() games there and below are correct (and
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/dp/i915: Fix DP link rate math
== Series Details == Series: series starting with [1/2] drm/dp/i915: Fix DP link rate math URL : https://patchwork.freedesktop.org/series/15084/ State : success == Summary == Series 15084v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/15084/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: fail -> PASS (fi-ivb-3520m) Subgroup suspend-read-crc-pipe-b: fail -> PASS (fi-ivb-3520m) Subgroup suspend-read-crc-pipe-c: fail -> PASS (fi-ivb-3520m) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 1afd351596b6deaead14d5812f0d6850379e30ad drm-intel-nightly: 2016y-11m-09d-21h-03m-31s UTC integration manifest 6b5ad35 drm/i915/dp: Validate mode against max. link data rate for DP MST e9bed5e drm/dp/i915: Fix DP link rate math == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2951/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 4/8] drm/i915/gen9: WM memory bandwidth related workaround
Hi,
On Friday 04 November 2016 10:39 PM, Paulo Zanoni wrote:
Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu:
This patch implemnets Workariunds related to display arbitrated
memory
bandwidth. These WA are applicabe for all gen-9 based platforms.
Changes since v1:
- Rebase on top of Paulo's patch series
Changes since v2:
- Rebase/rework after addressing Paulo's comments in previous patch
A lot of this code has changed since then, so this will need a
significant rebase. In the meantime, I added skl_needs_memory_bw_wa()
and we're now applying the WA by default: we just won't apply the WA
when we're pretty sure we don't need to. This helps avoiding underruns
by default.
See more below.
make sense, Will change default WA to WA_T_TILED
Signed-off-by: "Kumar, Mahesh"
---
drivers/gpu/drm/i915/i915_drv.h | 9 +++
drivers/gpu/drm/i915/intel_drv.h | 11 +++
drivers/gpu/drm/i915/intel_pm.c | 146
+++
3 files changed, 166 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index adbd9aa..c169360 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1092,6 +1092,13 @@ enum intel_sbi_destination {
SBI_MPHY,
};
+/* SKL+ Watermark arbitrated display bandwidth Workarounds */
+enum watermark_memory_wa {
+ WATERMARK_WA_NONE,
+ WATERMARK_WA_X_TILED,
+ WATERMARK_WA_Y_TILED,
+};
+
#define QUIRK_PIPEA_FORCE (1<<0)
#define QUIRK_LVDS_SSC_DISABLE (1<<1)
#define QUIRK_INVERT_BRIGHTNESS (1<<2)
@@ -1644,6 +1651,8 @@ struct skl_ddb_allocation {
struct skl_wm_values {
unsigned dirty_pipes;
+ /* any WaterMark memory workaround Required */
We can remove this comment since it doesn't say anything the variable
name doesn't.
+ enum watermark_memory_wa mem_wa;
Now that we have a proper variable in the state struct, it probably
makes sense to just kill skl_needs_memory_bw_wa() and read this
variable when we need to.
struct skl_ddb_allocation ddb;
uint32_t wm_linetime[I915_MAX_PIPES];
uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index f48e79a..2c1897b 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1813,6 +1813,17 @@ intel_atomic_get_crtc_state(struct
drm_atomic_state *state,
return to_intel_crtc_state(crtc_state);
}
+static inline struct intel_crtc_state *
+intel_atomic_get_existing_crtc_state(struct drm_atomic_state *state,
+ struct intel_crtc *crtc)
+{
+ struct drm_crtc_state *crtc_state;
+
+ crtc_state = drm_atomic_get_existing_crtc_state(state,
&crtc->base);
+
+ return to_intel_crtc_state(crtc_state);
I really don't like the idea of calling to_intel_crtc_state() on a
potentially NULL pointer so the caller of this function will also check
for NULL. Even though it works today, I still think it's unsafe
practice. Please check crtc_state for NULL directly and then return
NULL.
Also, I think this function should be extracted to its own commit, and
we'd probably be able to find some callers in the existing i915 code.
Will extract this function & include NULL check for crtc_state itself
+}
+
static inline struct intel_plane_state *
intel_atomic_get_existing_plane_state(struct drm_atomic_state
*state,
struct intel_plane *plane)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 84ec6b1..5b8f715 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3589,6 +3589,8 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
{
struct drm_plane_state *pstate = &intel_pstate->base;
struct drm_framebuffer *fb = pstate->fb;
+ struct intel_atomic_state *intel_state =
+ to_intel_atomic_state(cstate->base.state);
uint32_t latency = dev_priv->wm.skl_latency[level];
uint32_t method1, method2;
uint32_t plane_bytes_per_line, plane_blocks_per_line;
@@ -3598,10 +3600,17 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
uint32_t width = 0, height = 0;
uint32_t plane_pixel_rate;
uint32_t y_tile_minimum, y_min_scanlines;
+ enum watermark_memory_wa mem_wa;
if (latency == 0 || !cstate->base.active || !intel_pstate-
base.visible)
return 0;
+ mem_wa = intel_state ? intel_state->wm_results.mem_wa :
WATERMARK_WA_NONE;
+ if (mem_wa != WATERMARK_WA_NONE) {
+ if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
+ latency += 15;
+ }
+
width = drm_rect_width(&intel_pstate->base.src) >> 16;
height = drm_rect_height(&intel_pstate->base.src) >> 16;
@@ -3634,6 +3643,9 @@ static int skl_compute_plane_wm(const str
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/audio: fix hdmi audio noise issue (rev2)
== Series Details == Series: drm/i915/audio: fix hdmi audio noise issue (rev2) URL : https://patchwork.freedesktop.org/series/15012/ State : success == Summary == Series 15012v2 drm/i915/audio: fix hdmi audio noise issue https://patchwork.freedesktop.org/api/1.0/series/15012/revisions/2/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: fail -> PASS (fi-ivb-3520m) Subgroup suspend-read-crc-pipe-b: fail -> PASS (fi-ivb-3520m) Subgroup suspend-read-crc-pipe-c: fail -> PASS (fi-ivb-3520m) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 1afd351596b6deaead14d5812f0d6850379e30ad drm-intel-nightly: 2016y-11m-09d-21h-03m-31s UTC integration manifest 65718a7 drm/i915/audio: fix hdmi audio noise issue == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2950/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] shmem: Support for registration of driver/file owner specific ops
On Fri, 4 Nov 2016, akash.g...@intel.com wrote:
> From: Chris Wilson
>
> This provides support for the drivers or shmem file owners to register
> a set of callbacks, which can be invoked from the address space
> operations methods implemented by shmem. This allow the file owners to
> hook into the shmem address space operations to do some extra/custom
> operations in addition to the default ones.
>
> The private_data field of address_space struct is used to store the
> pointer to driver specific ops. Currently only one ops field is defined,
> which is migratepage, but can be extended on an as-needed basis.
>
> The need for driver specific operations arises since some of the
> operations (like migratepage) may not be handled completely within shmem,
> so as to be effective, and would need some driver specific handling also.
> Specifically, i915.ko would like to participate in migratepage().
> i915.ko uses shmemfs to provide swappable backing storage for its user
> objects, but when those objects are in use by the GPU it must pin the
> entire object until the GPU is idle. As a result, large chunks of memory
> can be arbitrarily withdrawn from page migration, resulting in premature
> out-of-memory due to fragmentation. However, if i915.ko can receive the
> migratepage() request, it can then flush the object from the GPU, remove
> its pin and thus enable the migration.
>
> Since gfx allocations are one of the major consumer of system memory, its
> imperative to have such a mechanism to effectively deal with
> fragmentation. And therefore the need for such a provision for initiating
> driver specific actions during address space operations.
Thank you for persisting with this, and sorry for all my delay.
>
> v2:
> - Drop dev_ prefix from the members of shmem_dev_info structure. (Joonas)
> - Change the return type of shmem_set_device_op() to void and remove the
> check for pre-existing data. (Joonas)
> - Rename shmem_set_device_op() to shmem_set_dev_info() to be consistent
> with shmem_dev_info structure. (Joonas)
>
> Cc: Hugh Dickins
> Cc: linux...@kvack.org
> Cc: linux-ker...@vger.linux.org
> Signed-off-by: Sourab Gupta
> Signed-off-by: Akash Goel
> Reviewed-by: Chris Wilson
That doesn't seem quite right: the From line above implies that Chris
wrote it, and should be first Signer; but perhaps the From line is wrong.
> ---
> include/linux/shmem_fs.h | 13 +
> mm/shmem.c | 17 -
> 2 files changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
> index ff078e7..454c3ba 100644
> --- a/include/linux/shmem_fs.h
> +++ b/include/linux/shmem_fs.h
> @@ -39,11 +39,24 @@ struct shmem_sb_info {
> unsigned long shrinklist_len; /* Length of shrinklist */
> };
>
> +struct shmem_dev_info {
> + void *private_data;
> + int (*migratepage)(struct address_space *mapping,
> +struct page *newpage, struct page *page,
> +enum migrate_mode mode, void *dev_priv_data);
Aren't the private_data field and dev_priv_data arg a little bit
confusing and redundant? Can't the migratepage() deduce dev_priv
for itself from mapping->private_data (perhaps wrapped by a
shmem_get_dev_info()), by using container_of()?
> +};
> +
> static inline struct shmem_inode_info *SHMEM_I(struct inode *inode)
> {
> return container_of(inode, struct shmem_inode_info, vfs_inode);
> }
>
> +static inline void shmem_set_dev_info(struct address_space *mapping,
> + struct shmem_dev_info *info)
> +{
> + mapping->private_data = info;
Nit: if this stays as is, I'd prefer dev_info there and above,
since shmem.c uses info all over for its shmem_inode_info pointer.
But in second patch I suggest obj_info may be better than dev_info.
> +}
> +
> /*
> * Functions in mm/shmem.c called directly from elsewhere:
> */
> diff --git a/mm/shmem.c b/mm/shmem.c
> index ad7813d..fce8de3 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1290,6 +1290,21 @@ static int shmem_writepage(struct page *page, struct
> writeback_control *wbc)
> return 0;
> }
>
> +#ifdef CONFIG_MIGRATION
> +static int shmem_migratepage(struct address_space *mapping,
> + struct page *newpage, struct page *page,
> + enum migrate_mode mode)
> +{
> + struct shmem_dev_info *dev_info = mapping->private_data;
> +
> + if (dev_info && dev_info->migratepage)
> + return dev_info->migratepage(mapping, newpage, page,
> + mode, dev_info->private_data);
> +
> + return migrate_page(mapping, newpage, page, mode);
> +}
> +#endif
> +
> #if defined(CONFIG_NUMA) && defined(CONFIG_TMPFS)
> static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
> {
> @@ -3654,7 +3669,7 @@ static void shmem_destroy_inodecache(void)
> .write_end = shmem_write_end,
>
[Intel-gfx] [PATCH 2/2] drm/i915/dp: Validate mode against max. link data rate for DP MST
Not validating the the mode rate against link rate results not pruning
invalid modes. For e.g, HBR2 5.4 Gpbs 2 lane configuration does not
support 4k @ 60Hz. But, we do not reject this mode currently.
So, make use of the helpers in intel_dp in validate mode rates against
max. data rate of a configuration.
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/intel_dp_mst.c | 12 +++-
drivers/gpu/drm/i915/intel_drv.h| 2 ++
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7a9e122..7a73e43 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -161,14 +161,14 @@ static u8 intel_dp_max_lane_count(struct intel_dp
*intel_dp)
return min(source_max, sink_max);
}
-static int
+int
intel_dp_link_required(int pixel_clock, int bpp)
{
/* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
return (pixel_clock * bpp + 7) / 8;
}
-static int
+int
intel_dp_max_data_rate(int max_link_clock, int max_lanes)
{
/* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 3ffbd69..38d2ce0 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -335,7 +335,17 @@ static enum drm_mode_status
intel_dp_mst_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
+ struct intel_connector *intel_connector = to_intel_connector(connector);
+ struct intel_dp *intel_dp = intel_connector->mst_port;
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
+ int link_clock = intel_dp_max_link_rate(intel_dp);
+ int lane_count = drm_dp_max_lane_count(intel_dp->dpcd);
+ int bpp = 24; /* MST uses fixed bpp */
+ int mode_rate;
+ int link_max_data_rate;
+
+ link_max_data_rate = intel_dp_max_data_rate(link_clock, lane_count);
+ mode_rate = intel_dp_link_required(mode->clock, bpp);
/* TODO - validate mode against available PBN for link */
if (mode->clock < 1)
@@ -344,7 +354,7 @@ intel_dp_mst_mode_valid(struct drm_connector *connector,
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
return MODE_H_ILLEGAL;
- if (mode->clock > max_dotclk)
+ if (mode_rate > link_max_data_rate || mode->clock > max_dotclk)
return MODE_CLOCK_HIGH;
return MODE_OK;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c2f3863..313419d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1471,6 +1471,8 @@ bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
bool __intel_dp_read_desc(struct intel_dp *intel_dp,
struct intel_dp_desc *desc);
bool intel_dp_read_desc(struct intel_dp *intel_dp);
+int intel_dp_link_required(int pixel_clock, int bpp);
+int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
/* intel_dp_aux_backlight.c */
int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector);
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/dp/i915: Fix DP link rate math
We store DP link rates as link clock frequencies in kHz, just like all
other clock values. But, DP link rates in the DP Spec are expressed in
Gbps/lane, which seems to have led to some confusion.
E.g., for HBR2
Max. data rate = 5.4 Gbps/lane x 4 lane x 8/10 x 1/8 = 216 kBps
where, 8/10 is for channel encoding and 1/8 is for bit to Byte conversion
Using link clock frequency, like we do
Max. data rate = 54 kHz * 4 lanes = 216 kSymbols/s
Because, each symbol has 8 bit of data, this is 216 kBps
and there is no need to account for channel encoding here.
But, currently we do 54 kHz * 4 lanes * (8/10) = 1728000 kBps
Similarly, while computing the required link bandwidth for a mode,
there is a mysterious 1/10 term.
This should simply be pixel_clock kHz * bpp * 1/8 to give the final
result in kBps
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_dp.c | 28 +---
1 file changed, 9 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 8f313c1..7a9e122 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -161,33 +161,23 @@ static u8 intel_dp_max_lane_count(struct intel_dp
*intel_dp)
return min(source_max, sink_max);
}
-/*
- * The units on the numbers in the next two are... bizarre. Examples will
- * make it clearer; this one parallels an example in the eDP spec.
- *
- * intel_dp_max_data_rate for one lane of 2.7GHz evaluates as:
- *
- * 27 * 1 * 8 / 10 == 216000
- *
- * The actual data capacity of that configuration is 2.16Gbit/s, so the
- * units are decakilobits. ->clock in a drm_display_mode is in kilohertz -
- * or equivalently, kilopixels per second - so for 1680x1050R it'd be
- * 119000. At 18bpp that's 2142000 kilobits per second.
- *
- * Thus the strange-looking division by 10 in intel_dp_link_required, to
- * get the result in decakilobits instead of kilobits.
- */
-
static int
intel_dp_link_required(int pixel_clock, int bpp)
{
- return (pixel_clock * bpp + 9) / 10;
+ /* pixel_clock is in kHz, divide bpp by 8 to return the value in kBps*/
+ return (pixel_clock * bpp + 7) / 8;
}
static int
intel_dp_max_data_rate(int max_link_clock, int max_lanes)
{
- return (max_link_clock * max_lanes * 8) / 10;
+ /* max_link_clock is the link symbol clock (LS_Clk) in kHz and not the
+* link rate that is generally expressed in Gbps. Since, 8 bits data is
+* transmitted every LS_Clk per lane, there is no need to account for
+* the channel encoding that is done in the PHY layer here.
+*/
+
+ return (max_link_clock * max_lanes);
}
static int
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Handle Link Training Failure during modeset
== Series Details == Series: Handle Link Training Failure during modeset URL : https://patchwork.freedesktop.org/series/15080/ State : failure == Summary == Series 15080v1 Handle Link Training Failure during modeset https://patchwork.freedesktop.org/api/1.0/series/15080/revisions/1/mbox/ Test drv_module_reload_basic: dmesg-warn -> INCOMPLETE (fi-skl-6700k) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: fail -> PASS (fi-ivb-3520m) Subgroup suspend-read-crc-pipe-b: fail -> PASS (fi-ivb-3520m) Subgroup suspend-read-crc-pipe-c: fail -> PASS (fi-ivb-3520m) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:6pass:5dwarn:0 dfail:0 fail:0 skip:0 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 1afd351596b6deaead14d5812f0d6850379e30ad drm-intel-nightly: 2016y-11m-09d-21h-03m-31s UTC integration manifest 13ab659 drm/i915: Implement Link Rate fallback on Link training failure 2793b26 drm/i915: Find fallback link rate/lane count 37a0b049 drm/i915: Update CRTC state if connector link status property changed 81cc918 drm/i915: Set link status property for DP connector 5837520 drm: Add a new connector property for link status == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2949/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/audio: fix hdmi audio noise issue
From: Libin Yang
Some monitors will have noise or even no sound after
applying the patch 6014ac12.
In patch 6014ac12, it will reset the cts value to 0 for HDMI.
However, we need to disable Enable CTS or M Prog bit. This is
the initial setting after HW reset.
Fixes: 6014ac122ed0 ("drm/i915/audio: set proper N/M in modeset")
Signed-off-by: Libin Yang
---
drivers/gpu/drm/i915/intel_audio.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 813fd74..a472d35 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -332,6 +332,13 @@ hsw_hdmi_audio_config_update(struct intel_crtc
*intel_crtc, enum port port,
int n;
u32 tmp;
+ /* reset CTS value to 0 */
+ tmp = I915_READ(HSW_AUD_M_CTS_ENABLE(pipe));
+ tmp &= ~AUD_CONFIG_M_MASK;
+ tmp &= ~AUD_M_CTS_M_VALUE_INDEX;
+ tmp |= AUD_M_CTS_M_PROG_ENABLE;
+ I915_WRITE(HSW_AUD_M_CTS_ENABLE(pipe), tmp);
+
tmp = I915_READ(HSW_AUD_CFG(pipe));
tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
@@ -351,10 +358,12 @@ hsw_hdmi_audio_config_update(struct intel_crtc
*intel_crtc, enum port port,
I915_WRITE(HSW_AUD_CFG(pipe), tmp);
+ /*
+* Let's disable "Enable CTS or M Prog bit"
+* and let HW calculate the value
+*/
tmp = I915_READ(HSW_AUD_M_CTS_ENABLE(pipe));
- tmp &= ~AUD_CONFIG_M_MASK;
- tmp &= ~AUD_M_CTS_M_VALUE_INDEX;
- tmp |= AUD_M_CTS_M_PROG_ENABLE;
+ tmp &= ~AUD_M_CTS_M_PROG_ENABLE;
I915_WRITE(HSW_AUD_M_CTS_ENABLE(pipe), tmp);
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm: Add a new connector property for link status
A new default connector property is added for keeping
track of whether the link is good (link training passed) or
link is bad (link training failed). If the link status property
is not good, then userspace should fire off a new modeset at the current
mode even if there have not been any changes in the mode list
or connector status.
Also add link status connector member corersponding to the
decoded value of link status property.
v3:
* Drop "link training" from description since this is
not specific to DP (Jani Nikula)
* Add link status member to store property value locally
(Ville Syrjala)
v2:
* Make this a default connector property (Daniel Vetter)
Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Chris Wilson
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/drm_connector.c | 17 +
include/drm/drm_connector.h | 7 ++-
include/drm/drm_crtc.h | 5 +
include/uapi/drm/drm_mode.h | 4
4 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2db7fb5..d4e852f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
drm_object_attach_property(&connector->base,
config->dpms_property, 0);
+ drm_object_attach_property(&connector->base,
+ config->link_status_property,
+ 0);
+
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(&connector->base,
config->prop_crtc_id, 0);
}
@@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum
subpixel_order order)
};
DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
+static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
+ { DRM_MODE_LINK_STATUS_GOOD, "Good" },
+ { DRM_MODE_LINK_STATUS_BAD, "Bad" },
+};
+DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
+
/**
* drm_display_info_set_bus_formats - set the supported bus formats
* @info: display info to store bus formats in
@@ -622,6 +632,13 @@ int drm_connector_create_standard_properties(struct
drm_device *dev)
return -ENOMEM;
dev->mode_config.tile_property = prop;
+ prop = drm_property_create_enum(dev, 0, "link-status",
+ drm_link_status_enum_list,
+ ARRAY_SIZE(drm_link_status_enum_list));
+ if (!prop)
+ return -ENOMEM;
+ dev->mode_config.link_status_property = prop;
+
return 0;
}
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 3e97272..ad5c8b0 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -695,6 +695,12 @@ struct drm_connector {
uint8_t num_h_tile, num_v_tile;
uint8_t tile_h_loc, tile_v_loc;
uint16_t tile_h_size, tile_v_size;
+
+ /* Connector Link status
+* 0: If the link is Good
+* 1: If the link is Bad
+*/
+ int link_status;
};
#define obj_to_connector(x) container_of(x, struct drm_connector, base)
@@ -767,7 +773,6 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
int drm_mode_create_scaling_mode_property(struct drm_device *dev);
int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
-
int drm_mode_connector_set_path_property(struct drm_connector *connector,
const char *path);
int drm_mode_connector_set_tile_property(struct drm_connector *connector);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 8cca2a8..a93148b 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1164,6 +1164,11 @@ struct drm_mode_config {
*/
struct drm_property *tile_property;
/**
+* @link_status_property: Default connector property for link status
+* of a connector
+*/
+ struct drm_property *link_status_property;
+ /**
* @plane_type_property: Default plane property to differentiate
* CURSOR, PRIMARY and OVERLAY legacy uses of planes.
*/
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 01000c9..66b145b 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -129,6 +129,10 @@
#define DRM_MODE_DIRTY_ON 1
#define DRM_MODE_DIRTY_ANNOTATE 2
+/* Link Status options */
+#define DRM_MODE_LINK_STATUS_GOOD 0
+#define DRM_MODE_LINK_STATUS_BAD 1
+
struct drm_mode_modeinfo {
__u32 clock;
__u16 hdisplay;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mail
[Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed
CRTC state connector_changed needs to be set to true
if connector link status property has changed. This will tell the
driver to do a complete modeset due to change in connector property.
Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/drm_atomic_helper.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 5007796..aeecf2f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct
drm_atomic_state *state,
connector_state);
if (ret)
return ret;
+
+ if (connector->state->crtc) {
+ crtc_state = drm_atomic_get_existing_crtc_state(state,
+
connector->state->crtc);
+ if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
+ crtc_state->connectors_changed = true;
+ }
}
/*
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: Find fallback link rate/lane count
If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.
This function finds the next lower link rate/lane count
value after link training failure.
v2:
Squash the patch that returns the link rate index (Jani Nikula)
Cc: Ville Syrjala
Cc: Jani Nikula
Cc: Daniel Vetter
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_dp.c | 42
drivers/gpu/drm/i915/intel_drv.h | 6 ++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1f1760f..9694857 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -288,6 +288,48 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
common_rates);
}
+static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
+ int *common_rates, int link_rate)
+{
+ int common_len;
+ int index;
+
+ common_len = intel_dp_common_rates(intel_dp, common_rates);
+ for (index = 0; index < common_len; index++) {
+ if (link_rate == common_rates[common_len - index - 1])
+ return common_len - index - 1;
+ }
+
+ return -1;
+}
+
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+ int link_rate, uint8_t lane_count)
+{
+ int common_rates[DP_MAX_SUPPORTED_RATES] = {};
+ int common_len;
+ int link_rate_index = -1;
+
+ common_len = intel_dp_common_rates(intel_dp, common_rates);
+ link_rate_index = intel_dp_link_rate_index(intel_dp,
+ common_rates,
+ link_rate);
+ if (link_rate_index > 0) {
+ intel_dp->fallback_link_rate_index = link_rate_index - 1;
+ intel_dp->fallback_link_rate =
common_rates[intel_dp->fallback_link_rate_index];
+ intel_dp->fallback_lane_count =
intel_dp_max_lane_count(intel_dp);
+ } else if (lane_count > 1) {
+ intel_dp->fallback_link_rate_index = common_len - 1;
+ intel_dp->fallback_link_rate =
common_rates[intel_dp->fallback_link_rate_index];
+ intel_dp->fallback_lane_count = lane_count >> 1;
+ } else {
+ DRM_ERROR("Link Training Unsuccessful\n");
+ return -1;
+ }
+
+ return 0;
+}
+
static enum drm_mode_status
intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 856dd41..4a49a2d 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -888,6 +888,10 @@ struct intel_dp {
uint32_t DP;
int link_rate;
uint8_t lane_count;
+ int fallback_link_rate;
+ uint8_t fallback_lane_count;
+ int fallback_link_rate_index;
+ bool link_train_failed;
uint8_t sink_count;
bool link_mst;
bool has_audio;
@@ -1386,6 +1390,8 @@ int intel_dp_set_link_status_property(struct
drm_connector *connector,
void intel_dp_set_link_params(struct intel_dp *intel_dp,
int link_rate, uint8_t lane_count,
bool link_mst);
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+ int link_rate, uint8_t lane_count);
void intel_dp_start_link_train(struct intel_dp *intel_dp);
void intel_dp_stop_link_train(struct intel_dp *intel_dp);
void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] Handle Link Training Failure during modeset
Link training failure is handled by lowering the link rate first until it reaches the minimum and keeping the lane count maximum and then lowering the lane count until it reaches minimim. These fallback values are saved and hotplug uevent is sent to the userspace after setting the connector link status property to BAD. Userspace should triiger another modeset on a uevent and if link status property is BAD. This will retrain the link at fallback values. This is repeated until the link is successfully trained. This has been validated to pass DP compliance. Manasi Navare (5): drm: Add a new connector property for link status drm/i915: Set link status property for DP connector drm/i915: Update CRTC state if connector link status property changed drm/i915: Find fallback link rate/lane count drm/i915: Implement Link Rate fallback on Link training failure drivers/gpu/drm/drm_atomic_helper.c | 7 ++ drivers/gpu/drm/drm_connector.c | 17 drivers/gpu/drm/i915/intel_ddi.c | 21 +++- drivers/gpu/drm/i915/intel_dp.c | 138 +- drivers/gpu/drm/i915/intel_dp_link_training.c | 12 ++- drivers/gpu/drm/i915/intel_drv.h | 12 ++- include/drm/drm_connector.h | 7 +- include/drm/drm_crtc.h| 5 + include/uapi/drm/drm_mode.h | 4 + 9 files changed, 214 insertions(+), 9 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure
If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, update the link status property
to "BAD" and use a lower link rate to prune the modes. It will redo
the modeset on the current mode at lower link rate or if the current
mode gets pruned due to lower link constraints then, it will send a
hotplug uevent for userspace to handle it.
This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
4.3.1.6.
v4:
* Add fallback support for non DDI platforms too
* Set connector->link status inside set_link_status function
(Jani Nikula)
v3:
* Set link status property to BAd unconditionally (Jani Nikula)
* Dont use two separate variables link_train_failed and link_status
to indicate same thing (Jani Nikula)
v2:
* Squashed a few patches (Jani Nikula)
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_ddi.c | 21 +-
drivers/gpu/drm/i915/intel_dp.c | 104 +-
drivers/gpu/drm/i915/intel_dp_link_training.c | 12 ++-
drivers/gpu/drm/i915/intel_drv.h | 6 +-
4 files changed, 133 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 0ad4e16..fa5989a 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1684,6 +1684,8 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
enum port port = intel_ddi_get_encoder_port(encoder);
+ struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = &intel_connector->base;
intel_dp_set_link_params(intel_dp, link_rate, lane_count,
link_mst);
@@ -1694,7 +1696,24 @@ static void intel_ddi_pre_enable_dp(struct intel_encoder
*encoder,
intel_prepare_dp_ddi_buffers(encoder);
intel_ddi_init_dp_buf_reg(encoder);
intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
- intel_dp_start_link_train(intel_dp);
+ if (!intel_dp_start_link_train(intel_dp)) {
+ DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane
count = %d",
+ link_rate, lane_count);
+ if (!intel_dp_get_link_train_fallback_values(intel_dp,
+link_rate,
+lane_count))
+ /* Schedule a Hotplug Uevent to userspace to start
modeset */
+ schedule_work(&intel_connector->modeset_retry_work);
+ } else {
+ DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane
count = %d",
+ link_rate, lane_count);
+ intel_dp->fallback_link_rate_index = -1;
+ intel_dp->fallback_link_rate = 0;
+ intel_dp->fallback_lane_count = 0;
+ intel_dp_set_link_status_property(connector,
+ DRM_MODE_LINK_STATUS_GOOD);
+ }
+
if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
intel_dp_stop_link_train(intel_dp);
}
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 9694857..b6b9405 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -353,8 +353,14 @@ int intel_dp_get_link_train_fallback_values(struct
intel_dp *intel_dp,
target_clock = fixed_mode->clock;
}
- max_link_clock = intel_dp_max_link_rate(intel_dp);
- max_lanes = intel_dp_max_lane_count(intel_dp);
+ /* Prune the modes using the fallback link rate/lane count */
+ if (connector->link_status == DRM_MODE_LINK_STATUS_BAD) {
+ max_link_clock = intel_dp->fallback_link_rate;
+ max_lanes = intel_dp->fallback_lane_count;
+ } else {
+ max_link_clock = intel_dp_max_link_rate(intel_dp);
+ max_lanes = intel_dp_max_lane_count(intel_dp);
+ }
max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
mode_rate = intel_dp_link_required(target_clock, 18);
@@ -1591,6 +1597,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
enum port port = dp_to_dig_port(intel_dp)->port;
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
struct intel_connector *intel_connector = intel_dp->attached_connector;
+ struct drm_connector *connector = &intel_connector->base;
int lane_count, clock;
int min_lane_count = 1;
int max_lane_count = intel_dp_max_lane_count(intel_dp);
@@ -1638,6 +1645,1
[Intel-gfx] [PATCH 2/5] drm/i915: Set link status property for DP connector
This defines a helper function to set the property value.
This will be used to set the link status to Bad in case
of link training failures.
v3:
* Set connector->link_status in this function
(Jani Nikula)
v2:
* Simplify the return value (Jani Nikula)
Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Cc: Chris Wilson
Signed-off-by: Manasi Navare
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 12
drivers/gpu/drm/i915/intel_drv.h | 2 ++
2 files changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 117a714..1f1760f 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4640,6 +4640,18 @@ static int intel_dp_get_modes(struct drm_connector
*connector)
return 0;
}
+int
+intel_dp_set_link_status_property(struct drm_connector *connector,
+ uint64_t val)
+{
+ struct drm_device *dev = connector->dev;
+
+ connector->link_status = val;
+ return drm_object_property_set_value(&connector->base,
+
dev->mode_config.link_status_property,
+val);
+}
+
static int
intel_dp_connector_register(struct drm_connector *connector)
{
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 003afb8..856dd41 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1381,6 +1381,8 @@ u32 skl_plane_stride(const struct drm_framebuffer *fb,
int plane,
bool intel_dp_init(struct drm_device *dev, i915_reg_t output_reg, enum port
port);
bool intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
struct intel_connector *intel_connector);
+int intel_dp_set_link_status_property(struct drm_connector *connector,
+ uint64_t val);
void intel_dp_set_link_params(struct intel_dp *intel_dp,
int link_rate, uint8_t lane_count,
bool link_mst);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 2/4 v5] lib/igt_gvt: Make use of libkmod helpers and fix reading gvt parameter.
On 2016.11.03 18:28:11 +0200, Marius Vlad wrote:
> v2:
> - use igt_sysfs_get_boolean() to get gvt status (Chris Wilson)
> - do not hard-fail when i915 module could not be loaded/unloaded (Chris
> Wilson)
>
> Signed-off-by: Marius Vlad
Looks fine to me.
Acked-by: Zhenyu Wang
> ---
> lib/igt_gvt.c | 37 ++---
> tests/gvt_basic.c | 2 +-
> 2 files changed, 19 insertions(+), 20 deletions(-)
>
> diff --git a/lib/igt_gvt.c b/lib/igt_gvt.c
> index 8bbf9bd..4ab7433 100644
> --- a/lib/igt_gvt.c
> +++ b/lib/igt_gvt.c
> @@ -24,35 +24,30 @@
> #include "igt.h"
> #include "igt_gvt.h"
> #include "igt_sysfs.h"
> +#include "igt_kmod.h"
>
> +#include
> #include
> #include
> #include
>
> static bool is_gvt_enabled(void)
> {
> - FILE *file;
> - int value;
> bool enabled = false;
> + int dir, fd;
>
> - file = fopen("/sys/module/i915/parameters/enable_gvt", "r");
> - if (!file)
> + fd = __drm_open_driver(DRIVER_INTEL);
> + dir = igt_sysfs_open_parameters(fd);
> + if (dir < 0)
> return false;
>
> - if (fscanf(file, "%d", &value) == 1)
> - enabled = value;
> - fclose(file);
> + enabled = igt_sysfs_get_boolean(dir, "enable_gvt");
>
> - errno = 0;
> - return enabled;
> -}
> + close(dir);
> + close(fd);
>
> -static void unload_i915(void)
> -{
> - kick_fbcon(false);
> - /* pkill alsact */
> + return enabled;
>
> - igt_ignore_warn(system("/sbin/modprobe -s -r i915"));
> }
>
> bool igt_gvt_load_module(void)
> @@ -60,8 +55,11 @@ bool igt_gvt_load_module(void)
> if (is_gvt_enabled())
> return true;
>
> - unload_i915();
> - igt_ignore_warn(system("/sbin/modprobe -s i915 enable_gvt=1"));
> + if (igt_i915_driver_unload())
> + return false;
> +
> + if (igt_i915_driver_load("enable_gvt=1"))
> + return false;
>
> return is_gvt_enabled();
> }
> @@ -71,8 +69,9 @@ void igt_gvt_unload_module(void)
> if (!is_gvt_enabled())
> return;
>
> - unload_i915();
> - igt_ignore_warn(system("/sbin/modprobe -s i915 enable_gvt=0"));
> + igt_i915_driver_unload();
> +
> + igt_i915_driver_load(NULL);
>
> igt_assert(!is_gvt_enabled());
> }
> diff --git a/tests/gvt_basic.c b/tests/gvt_basic.c
> index 48b853a..4e909a5 100644
> --- a/tests/gvt_basic.c
> +++ b/tests/gvt_basic.c
> @@ -32,7 +32,7 @@ igt_main
>
> igt_fixture {
> igt_require(igt_gvt_load_module());
> - fd = drm_open_driver(DRIVER_INTEL);
> + fd = __drm_open_driver(DRIVER_INTEL);
> }
>
> igt_subtest_f("invalid-placeholder-test");
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gvt: Disable access to stolen memory as a guest
On 2016.11.09 10:39:05 +, Chris Wilson wrote:
> Explicitly disable stolen memory when running as a guest in a virtual
> machine, since the memory is not mediated between clients and reserved
> entirely for the host. The actual size should be reported as zero, but
> like every other quirk we want to tell the user what is happening.
>
> Signed-off-by: Chris Wilson
> Cc: Zhenyu Wang
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_gem_stolen.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index 154fbb04419f..0f0b37cad63d 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -417,6 +417,11 @@ int i915_gem_init_stolen(struct drm_device *dev)
>
> mutex_init(&dev_priv->mm.stolen_lock);
>
> + if (intel_vgpu_active(dev_priv)) {
> + DRM_INFO("iGVT-g active, disabling use of stolen memory\n");
> + return 0;
> + }
> +
> #ifdef CONFIG_INTEL_IOMMU
> if (intel_iommu_gfx_mapped && INTEL_INFO(dev)->gen < 8) {
> DRM_INFO("DMAR active, disabling use of stolen memory\n");
> --
> 2.10.2
>
Reviewed-by: Zhenyu Wang
--
Open Source Technology Center, Intel ltd.
$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/audio: fix hdmi audio noise issue
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Wednesday, November 9, 2016 6:59 PM
> To: Yang, Libin ; intel-gfx@lists.freedesktop.org;
> ville.syrj...@linux.intel.com; Vetter, Daniel ;
> ti...@suse.de
> Cc: Yang, Libin
> Subject: Re: [PATCH] drm/i915/audio: fix hdmi audio noise issue
>
> On Wed, 09 Nov 2016, libin.y...@intel.com wrote:
> > From: Libin Yang
> >
> > This issue is caused by:
> > 6014ac12: drm/i915/audio: set proper N/M in modeset
> >
> > Some special monitors will have noise or even no sound after applying
> > the patch 6014ac12.
> >
> > In patch 6014ac12, it will reset the cts value to 0 for HDMI.
> > However, we need disable Enable CTS or M Prog bit. This is the initial
> > setting after HW reset.
> >
>
> Fixes: 6014ac122ed0 ("drm/i915/audio: set proper N/M in modeset")
Get it. Thanks.
>
> > Signed-off-by: Libin Yang
> > ---
> > drivers/gpu/drm/i915/intel_audio.c | 15 ---
> > 1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 813fd74..a472d35 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -332,6 +332,13 @@ hsw_hdmi_audio_config_update(struct intel_crtc
> *intel_crtc, enum port port,
> > int n;
> > u32 tmp;
> >
> > + /* reset CTS value to 0 */
> > + tmp = I915_READ(HSW_AUD_M_CTS_ENABLE(pipe));
> > + tmp &= ~AUD_CONFIG_M_MASK;
> > + tmp &= ~AUD_M_CTS_M_VALUE_INDEX;
> > + tmp |= AUD_M_CTS_M_PROG_ENABLE;
> > + I915_WRITE(HSW_AUD_M_CTS_ENABLE(pipe), tmp);
> > +
> > tmp = I915_READ(HSW_AUD_CFG(pipe));
> > tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
> > tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
> > @@ -351,10 +358,12 @@ hsw_hdmi_audio_config_update(struct intel_crtc
> > *intel_crtc, enum port port,
> >
> > I915_WRITE(HSW_AUD_CFG(pipe), tmp);
> >
> > + /*
> > +* Let's disable "Enable CTS or M Prog bit"
> > +* and let HW calculate the value
> > +*/
> > tmp = I915_READ(HSW_AUD_M_CTS_ENABLE(pipe));
> > - tmp &= ~AUD_CONFIG_M_MASK;
> > - tmp &= ~AUD_M_CTS_M_VALUE_INDEX;
> > - tmp |= AUD_M_CTS_M_PROG_ENABLE;
> > + tmp &= ~AUD_M_CTS_M_PROG_ENABLE;
> > I915_WRITE(HSW_AUD_M_CTS_ENABLE(pipe), tmp);
>
> Is it necessary to do the HSW_AUD_M_CTS_ENABLE updates in two places?
> Why do you both enable and disable AUD_M_CTS_M_PROG_ENABLE bit here?
>
> 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] drm/i915/gvt: Disable access to stolen memory as a guest
On 2016.11.09 13:11:11 +0200, Joonas Lahtinen wrote: > On ke, 2016-11-09 at 10:39 +, Chris Wilson wrote: > > Explicitly disable stolen memory when running as a guest in a virtual > > machine, since the memory is not mediated between clients and reserved > > entirely for the host. > > I'd kind of expect it to get sliced down just like the aperture, what's > the plan here? > No plan to do more partition on stolen mem for mediation now. I had a change to handle GMCH_CTL config which would show no stolen mem for guest driver, so that could work for all OS gfx drivers. But I think Chris's change is fine and I would polish GMCH_CTL handling patch. > > > The actual size should be reported as zero, but > > like every other quirk we want to tell the user what is happening. > > > > Signed-off-by: Chris Wilson > > Cc: Zhenyu Wang > > Cc: Joonas Lahtinen > -- > Joonas Lahtinen > Open Source Technology Center > Intel Corporation -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 04/11] drm/i915/gen9+: Kill off hw_ddb from intel_crtc.
On Tue, Nov 08, 2016 at 01:55:35PM +0100, Maarten Lankhorst wrote:
> This member is only used in skl_update_crtcs now. It's easy to remove it
> by keeping track of which ddb entries in an array, and update them after
I'm having trouble parsing this line...not sure if you have an extra
word or are missing a word. But I think what you meant is that you're
snapshotting the DDB values at the beginning of this function so that
you'll have a copy of what the 'old' values that were already in the
hardware , then you update that snapshot as you write the DDB for pipe
to the hardware?
> we update the crtc. This removes the last bits of SKL-style watermarks
> kept outside of crtc_state.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 15 ---
> drivers/gpu/drm/i915/intel_drv.h | 11 +++
> drivers/gpu/drm/i915/intel_pm.c | 25 +++--
> 3 files changed, 22 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 69f9addb29b3..e59adb03933e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14280,6 +14280,14 @@ static void skl_update_crtcs(struct drm_atomic_state
> *state,
> unsigned int updated = 0;
> bool progress;
> enum pipe pipe;
> + int i;
> +
> + const struct skl_ddb_entry *entries[I915_MAX_PIPES] = {};
Do we want this to be const?
> +
> + for_each_crtc_in_state(state, crtc, old_crtc_state, i)
> + /* ignore allocations for crtc's that have been turned off. */
> + if (crtc->state->active)
> + entries[i] =
> &to_intel_crtc_state(old_crtc_state)->wm.skl.ddb;
>
> /*
>* Whenever the number of active pipes changes, we need to make sure we
> @@ -14288,7 +14296,6 @@ static void skl_update_crtcs(struct drm_atomic_state
> *state,
>* cause pipe underruns and other bad stuff.
>*/
> do {
> - int i;
> progress = false;
>
> for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
> @@ -14299,12 +14306,14 @@ static void skl_update_crtcs(struct
> drm_atomic_state *state,
> cstate = to_intel_crtc_state(crtc->state);
> pipe = intel_crtc->pipe;
>
> - if (updated & cmask || !crtc->state->active)
> + if (updated & cmask || !cstate->base.active)
This change seems unrelated/unnecessary? cstate was just set a couple
lines above, so this is effectively just replacing crtc->state with
to_intel_crtc_state(crtc->state)->base.
Matt
> continue;
> - if (skl_ddb_allocation_overlaps(state, intel_crtc))
> +
> + if (skl_ddb_allocation_overlaps(entries,
> &cstate->wm.skl.ddb, i))
> continue;
>
> updated |= cmask;
> + entries[i] = &cstate->wm.skl.ddb;
>
> /*
>* If this is an already active pipe, it's DDB changed,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index d18444097e1c..815e8dae3904 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -728,9 +728,6 @@ struct intel_crtc {
> bool cxsr_allowed;
> } wm;
>
> - /* gen9+: ddb allocation currently being used */
> - struct skl_ddb_entry hw_ddb;
> -
> int scanline_offset;
>
> struct {
> @@ -1738,11 +1735,9 @@ int intel_enable_sagv(struct drm_i915_private
> *dev_priv);
> int intel_disable_sagv(struct drm_i915_private *dev_priv);
> bool skl_wm_level_equals(const struct skl_wm_level *l1,
>const struct skl_wm_level *l2);
> -bool skl_ddb_allocation_equals(const struct skl_ddb_allocation *old,
> -const struct skl_ddb_allocation *new,
> -enum pipe pipe);
> -bool skl_ddb_allocation_overlaps(struct drm_atomic_state *state,
> - struct intel_crtc *intel_crtc);
> +bool skl_ddb_allocation_overlaps(const struct skl_ddb_entry **entries,
> + const struct skl_ddb_entry *ddb,
> + int ignore);
> uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
> bool ilk_disable_lp_wm(struct drm_device *dev);
> int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index bde6c68eb0db..02f52b52a03d 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3914,25 +3914,16 @@ static inline bool skl_ddb_entries_overlap(const
> struct skl_ddb_entry *a,
> return a->start < b->end && b->start < a->end;
> }
>
> -bool skl_ddb_all
Re: [Intel-gfx] [PATCH v3 03/11] drm/i915/gen9+: Preserve old allocation from crtc_state.
On Tue, Nov 08, 2016 at 01:55:34PM +0100, Maarten Lankhorst wrote:
> This is the last bit required for making nonblocking modesets work
> correctly. The state in intel_crtc->hw_ddb is not updated until
> somewhere in atomic commit, while the previous crtc state should be
> accurate if the ddb hasn't changed.
The "somewhere in atomic commit" part of the commit message here is a
little bit confusing given that the change to skl_update_crtcs is
happening "somewhere in atomic commit." The key being that your
comparison happens earlier in the commit phase than the hw_ddb update.
I'm not sure exactly how best to word that, but if you can convey that
in the commit message, then the changes here look fine so
Reviewed-by: Matt Roper
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> drivers/gpu/drm/i915/intel_pm.c | 6 +-
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index abfcaa07bbe3..69f9addb29b3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14313,7 +14313,7 @@ static void skl_update_crtcs(struct drm_atomic_state
> *state,
>* new ddb allocation to take effect.
>*/
> if (!skl_ddb_entry_equal(&cstate->wm.skl.ddb,
> - &intel_crtc->hw_ddb) &&
> +
> &to_intel_crtc_state(old_crtc_state)->wm.skl.ddb) &&
> !crtc->state->active_changed &&
> intel_state->wm_results.dirty_pipes != updated)
> vbl_wait = true;
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 93e261300ef0..bde6c68eb0db 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3118,7 +3118,11 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device
> *dev,
>* we currently hold.
>*/
> if (!intel_state->active_pipe_changes) {
> - *alloc = to_intel_crtc(for_crtc)->hw_ddb;
> + /*
> + * alloc may be cleared by clear_intel_crtc_state,
> + * copy from old state to be sure
> + */
> + *alloc = to_intel_crtc_state(for_crtc->state)->wm.skl.ddb;
> return;
> }
>
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 01/11] drm/i915: Add a atomic evasion step to watermark programming, v3.
On Tue, Nov 08, 2016 at 01:55:32PM +0100, Maarten Lankhorst wrote:
> Allow the driver to write watermarks during atomic evasion.
> This will make it possible to write the watermarks in a cleaner
> way on gen9+.
>
> intel_atomic_state is not used here yet, but will be used when
> we program all watermarks as a separate step during evasion.
>
> This also writes linetime all the time, while before it was only
> done during plane updates. This looks like this could be a bugfix,
> but I'm not sure what it affects.
>
> Changes since v1:
> - Add comment about atomic evasion to commit message.
> - Unwrap I915_WRITE call. (Lyude)
> Changes since v2:
> - Rename atomic_evade_watermarks to atomic_update_watermarks. (Ville)
> - Add line wraps where appropriate, fix grammar in commit message. (Matt)
I'm not sure if these minor changes actually got applied or not; the
headline still needs s/a atomic/an atomic/ and there are still several
long lines that could be wrapped (especially the callsites of
initial_watermarks()).
But otherwise the code looks good, so if you clean up the cosmetic
issues, then my r-b still stands.
Matt
>
> Signed-off-by: Maarten Lankhorst
> Reviewed-by: Matt Roper
> Cc: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h | 9 +++--
> drivers/gpu/drm/i915/intel_display.c | 26 +-
> drivers/gpu/drm/i915/intel_pm.c | 18 --
> 3 files changed, 36 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 4735b4177100..00988d716d7e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -487,6 +487,7 @@ struct sdvo_device_mapping {
>
> struct intel_connector;
> struct intel_encoder;
> +struct intel_atomic_state;
> struct intel_crtc_state;
> struct intel_initial_plane_config;
> struct intel_crtc;
> @@ -500,8 +501,12 @@ struct drm_i915_display_funcs {
> int (*compute_intermediate_wm)(struct drm_device *dev,
> struct intel_crtc *intel_crtc,
> struct intel_crtc_state *newstate);
> - void (*initial_watermarks)(struct intel_crtc_state *cstate);
> - void (*optimize_watermarks)(struct intel_crtc_state *cstate);
> + void (*initial_watermarks)(struct intel_atomic_state *state,
> +struct intel_crtc_state *cstate);
> + void (*atomic_update_watermarks)(struct intel_atomic_state *state,
> + struct intel_crtc_state *cstate);
> + void (*optimize_watermarks)(struct intel_atomic_state *state,
> + struct intel_crtc_state *cstate);
> int (*compute_global_watermarks)(struct drm_atomic_state *state);
> void (*update_wm)(struct intel_crtc *crtc);
> int (*modeset_calc_cdclk)(struct drm_atomic_state *state);
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 92ab01f33208..66cf29ac9fe4 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5169,7 +5169,7 @@ static void intel_pre_plane_update(struct
> intel_crtc_state *old_crtc_state)
>* us to.
>*/
> if (dev_priv->display.initial_watermarks != NULL)
> - dev_priv->display.initial_watermarks(pipe_config);
> +
> dev_priv->display.initial_watermarks(to_intel_atomic_state(old_state),
> pipe_config);
> else if (pipe_config->update_wm_pre)
> intel_update_watermarks(crtc);
> }
> @@ -5383,7 +5383,7 @@ static void ironlake_crtc_enable(struct
> intel_crtc_state *pipe_config,
> intel_color_load_luts(&pipe_config->base);
>
> if (dev_priv->display.initial_watermarks != NULL)
> - dev_priv->display.initial_watermarks(intel_crtc->config);
> +
> dev_priv->display.initial_watermarks(to_intel_atomic_state(old_state),
> intel_crtc->config);
> intel_enable_pipe(intel_crtc);
>
> if (intel_crtc->config->has_pch_encoder)
> @@ -5489,7 +5489,7 @@ static void haswell_crtc_enable(struct intel_crtc_state
> *pipe_config,
> intel_ddi_enable_transcoder_func(crtc);
>
> if (dev_priv->display.initial_watermarks != NULL)
> - dev_priv->display.initial_watermarks(pipe_config);
> +
> dev_priv->display.initial_watermarks(to_intel_atomic_state(old_state),
> pipe_config);
> else
> intel_update_watermarks(intel_crtc);
>
> @@ -14474,7 +14474,7 @@ static void intel_atomic_commit_tail(struct
> drm_atomic_state *state)
> intel_cstate = to_intel_crtc_state(crtc->state);
>
> if (dev_priv->display.optimize_watermarks)
> - dev_priv->display.optimize_watermarks(intel_cstate);
> + dev_priv->display.optimize_watermarks(intel_state,
> intel_cstate);
> }
>
> for_each_crtc_in
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Don't take struct_mutex for object unreference
== Series Details == Series: drm/i915/guc: Don't take struct_mutex for object unreference URL : https://patchwork.freedesktop.org/series/15071/ State : success == Summary == Series 15071v1 drm/i915/guc: Don't take struct_mutex for object unreference https://patchwork.freedesktop.org/api/1.0/series/15071/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: fail -> PASS (fi-ivb-3520m) Subgroup suspend-read-crc-pipe-b: fail -> PASS (fi-ivb-3520m) Subgroup suspend-read-crc-pipe-c: fail -> PASS (fi-ivb-3520m) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 1afd351596b6deaead14d5812f0d6850379e30ad drm-intel-nightly: 2016y-11m-09d-21h-03m-31s UTC integration manifest 0eb7212 drm/i915/guc: Don't take struct_mutex for object unreference == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2948/ ___ 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/5] drm/i915: Always flush the dirty CPU cache when pinning the scanout
== Series Details == Series: series starting with [1/5] drm/i915: Always flush the dirty CPU cache when pinning the scanout URL : https://patchwork.freedesktop.org/series/15069/ State : failure == Summary == Series 15069v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/15069/revisions/1/mbox/ Test kms_frontbuffer_tracking: Subgroup basic: pass -> FAIL (fi-bdw-5557u) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: fail -> PASS (fi-ivb-3520m) Subgroup suspend-read-crc-pipe-b: fail -> PASS (fi-ivb-3520m) Subgroup suspend-read-crc-pipe-c: fail -> PASS (fi-ivb-3520m) fi-bdw-5557u total:244 pass:228 dwarn:0 dfail:0 fail:1 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 1afd351596b6deaead14d5812f0d6850379e30ad drm-intel-nightly: 2016y-11m-09d-21h-03m-31s UTC integration manifest 35017fc drm/i915: Drop struct_mutex around frontbuffer flushes 2ac91c1 drm/i915: struct_mutex is not required for allocating the framebuffer 4341efd drm/i915: Remove struct_mutex for destroying framebuffers 663e98d drm/i915: Mark all skipped clflushes as leaving the CPU cache dirty 8d9 drm/i915: Always flush the dirty CPU cache when pinning the scanout == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2947/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/4] drm/i915: Implement Link Rate fallback on Link training failure
On Wed, Nov 09, 2016 at 03:04:05PM +0200, Jani Nikula wrote:
> On Wed, 02 Nov 2016, Manasi Navare wrote:
> > If link training at a link rate optimal for a particular
> > mode fails during modeset's atomic commit phase, then we
> > let the modeset complete and then retry. We save the link rate
> > value at which link training failed, update the link status property
> > to "BAD" and use a lower link rate to prune the modes. It will redo
> > the modeset on the current mode at lower link rate or if the current
> > mode gets pruned due to lower link constraints then, it will send a
> > hotplug uevent for userspace to handle it.
> >
> > This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> > 4.3.1.6.
> >
> > v3:
> > * Set link status property to BAd unconditionally (Jani Nikula)
> > * Dont use two separate variables link_train_failed and link_status
> > to indicate same thing (Jani Nikula)
> > v2:
> > * Squashed a few patches (Jani Nikula)
> >
> > Cc: Jani Nikula
> > Cc: Daniel Vetter
> > Cc: Ville Syrjala
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 7 +++
> > drivers/gpu/drm/i915/intel_ddi.c | 22 -
> > drivers/gpu/drm/i915/intel_dp.c | 70
> > ---
> > drivers/gpu/drm/i915/intel_dp_link_training.c | 12 +++--
> > drivers/gpu/drm/i915/intel_drv.h | 6 ++-
> > 5 files changed, 105 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 75ad01d..94b0b3a 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct
> > drm_atomic_state *state,
> >connector_state);
> > if (ret)
> > return ret;
> > +
> > + if (connector->state->crtc) {
> > + crtc_state = drm_atomic_get_existing_crtc_state(state,
> > +
> > connector->state->crtc);
> > + if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> > + crtc_state->connectors_changed = true;
> > + }
> > }
>
> Could this be a separate patch? Anyway needs to be posted on dri-devel.
>
Yes I agree, I will move this into a separate patch right after the patch
where I declare the connector link status.
> >
> > /*
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 938ac4d..a59f8d2 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1684,6 +1684,8 @@ static void intel_ddi_pre_enable_dp(struct
> > intel_encoder *encoder,
> > struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > enum port port = intel_ddi_get_encoder_port(encoder);
> > + struct intel_connector *intel_connector = intel_dp->attached_connector;
> > + struct drm_connector *connector = &intel_connector->base;
> >
> > intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> > link_mst);
> > @@ -1694,7 +1696,25 @@ static void intel_ddi_pre_enable_dp(struct
> > intel_encoder *encoder,
> > intel_prepare_dp_ddi_buffers(encoder);
> > intel_ddi_init_dp_buf_reg(encoder);
> > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > - intel_dp_start_link_train(intel_dp);
> > + if (!intel_dp_start_link_train(intel_dp)) {
> > + DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane
> > count = %d",
> > + link_rate, lane_count);
> > + connector->link_status = DRM_MODE_LINK_STATUS_BAD;
>
> Why does this not use intel_dp_set_link_status_property()?
>
I will move this connector->link_status setting inside the set_link_status
function.
> > + intel_dp_get_link_train_fallback_values(intel_dp, link_rate,
> > + lane_count);
> > + /* Schedule a Hotplug Uevent to userspace to start modeset */
> > + schedule_work(&intel_connector->modeset_retry_work);
> > + } else {
> > + DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane
> > count = %d",
> > + link_rate, lane_count);
> > + intel_dp->fallback_link_rate_index = -1;
> > + intel_dp->fallback_link_rate = 0;
> > + intel_dp->fallback_lane_count = 0;
> > + connector->link_status = DRM_MODE_LINK_STATUS_GOOD;
> > + intel_dp_set_link_status_property(connector,
> > + DRM_MODE_LINK_STATUS_GOOD);
> > + }
> > +
> > if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > intel_dp_stop_link_train(intel_dp);
> > }
> > diff --g
[Intel-gfx] [PATCH] drm/i915/guc: Don't take struct_mutex for object unreference
We no longer need to take the struct_mutex for freeing objects, and on
the finalisation paths here the mutex is not been used for serialisation
of the pointer access, so remove the BKL wart.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_guc_loader.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 1aa85236b788..77a5c27b9da0 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -699,12 +699,9 @@ static void guc_fw_fetch(struct drm_device *dev, struct
intel_guc_fw *guc_fw)
DRM_DEBUG_DRIVER("GuC fw fetch status FAIL; err %d, fw %p, obj %p\n",
err, fw, guc_fw->guc_fw_obj);
- mutex_lock(&dev->struct_mutex);
- obj = guc_fw->guc_fw_obj;
+ obj = fetch_and_zero(&guc_fw->guc_fw_obj);
if (obj)
i915_gem_object_put(obj);
- guc_fw->guc_fw_obj = NULL;
- mutex_unlock(&dev->struct_mutex);
release_firmware(fw); /* OK even if fw is NULL */
guc_fw->guc_fw_fetch_status = GUC_FIRMWARE_FAIL;
@@ -781,16 +778,17 @@ void intel_guc_fini(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
+ struct drm_i915_gem_object *obj;
mutex_lock(&dev->struct_mutex);
guc_interrupts_release(dev_priv);
i915_guc_submission_disable(dev_priv);
i915_guc_submission_fini(dev_priv);
-
- if (guc_fw->guc_fw_obj)
- i915_gem_object_put(guc_fw->guc_fw_obj);
- guc_fw->guc_fw_obj = NULL;
mutex_unlock(&dev->struct_mutex);
+ obj = fetch_and_zero(&guc_fw->guc_fw_obj);
+ if (obj)
+ i915_gem_object_put(obj);
+
guc_fw->guc_fw_fetch_status = GUC_FIRMWARE_NONE;
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general
>-Original Message-
>From: Mcgee, Jeff
>Sent: Wednesday, November 9, 2016 12:43 PM
>To: Srivatsa, Anusha
>Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter Antoine
>
>Subject: Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading
>helper functions general
>
>When updating a patch set on the mailing list with new revisions it is
>preferred to
>send those new patches as a reply to the patch being revised and also to
>include
>the V2, V3, etc. in the subject.
>
>If you have massive changes then it is OK to submit a new set but it helps to
>include cover letter and version its subject as above to help distinquish from
>previous sets.
>
>Look through the mailing list and you will see examples of both scenarios.
>
>I think the protocol is also that if you revise a patch heavily then you
>cannot carry
>the r-b tags given on the earlier patch but rather you should get those people
>to
>re-review.
>
>Daniel - these best practices are recorded somewhere, right?
>
>Jeff
Was an oversight on my side. Will re-send the patches.
Anusha
>On Wed, Nov 09, 2016 at 10:51:30AM -0800, Anusha Srivatsa wrote:
>> From: Peter Antoine
>>
>> Rename some of the GuC fw loading code to make them more general. We
>> will utilise them for HuC loading as well.
>> s/intel_guc_fw/intel_uc_fw/g
>> s/GUC_FIRMWARE/UC_FIRMWARE/g
>>
>> Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
>> such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
>> same purpose.
>>
>> v2: rebased on top of nightly.
>> reapplied the search/replace as upstream code as changed.
>> v3: rebased again on drm-nightly.
>> v4: removed G from messages in shared fw fetch function.
>> v5: rebased.
>> v7: rebased.
>> v8: rebased.
>> v9: rebased.
>> v10: rebased.
>>
>> Signed-off-by: Anusha Srivatsa
>> Signed-off-by: Alex Dai
>> Signed-off-by: Peter Antoine
>> Reviewed-by: Dave Gordon
>> Reviewed-by: Jeff McGee
>> Reviewed-by: Carlos Santa
>> Tested-by: Carlos Santa
>> ---
>> drivers/gpu/drm/i915/i915_debugfs.c| 12 +--
>> drivers/gpu/drm/i915/i915_guc_submission.c | 4 +-
>> drivers/gpu/drm/i915/intel_guc.h | 39
>> drivers/gpu/drm/i915/intel_guc_loader.c| 156
>> ++---
>> 4 files changed, 106 insertions(+), 105 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
>> b/drivers/gpu/drm/i915/i915_debugfs.c
>> index b681d42..7e206dd 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -2353,7 +2353,7 @@ static int i915_llc(struct seq_file *m, void
>> *data) static int i915_guc_load_status_info(struct seq_file *m, void
>> *data) {
>> struct drm_i915_private *dev_priv = node_to_i915(m->private);
>> -struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
>> +struct intel_uc_fw *guc_fw = &dev_priv->guc.guc_fw;
>> u32 tmp, i;
>>
>> if (!HAS_GUC_UCODE(dev_priv))
>> @@ -2361,15 +2361,15 @@ static int i915_guc_load_status_info(struct
>> seq_file *m, void *data)
>>
>> seq_printf(m, "GuC firmware status:\n");
>> seq_printf(m, "\tpath: %s\n",
>> -guc_fw->guc_fw_path);
>> +guc_fw->uc_fw_path);
>> seq_printf(m, "\tfetch: %s\n",
>> -intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
>> +intel_uc_fw_status_repr(guc_fw->fetch_status));
>> seq_printf(m, "\tload: %s\n",
>> -intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
>> +intel_uc_fw_status_repr(guc_fw->load_status));
>> seq_printf(m, "\tversion wanted: %d.%d\n",
>> -guc_fw->guc_fw_major_wanted, guc_fw-
>>guc_fw_minor_wanted);
>> +guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
>> seq_printf(m, "\tversion found: %d.%d\n",
>> -guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
>> +guc_fw->major_ver_found, guc_fw->minor_ver_found);
>> seq_printf(m, "\theader: offset is %d; size = %d\n",
>> guc_fw->header_offset, guc_fw->header_size);
>> seq_printf(m, "\tuCode: offset is %d; size = %d\n", diff --git
>> a/drivers/gpu/drm/i915/i915_guc_submission.c
>> b/drivers/gpu/drm/i915/i915_guc_submission.c
>> index 666dab7..fb59e44 100644
>> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
>> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
>> @@ -1570,7 +1570,7 @@ int intel_guc_suspend(struct drm_device *dev)
>> struct i915_gem_context *ctx;
>> u32 data[3];
>>
>> -if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
>> +if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
>> return 0;
>>
>> gen9_disable_guc_interrupts(dev_priv);
>> @@ -1598,7 +1598,7 @@ int intel_guc_resume(struct drm_device *dev)
>> struct i915_gem_context *ctx;
>> u32 data[3];
>>
>> -if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
>> +if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
>>
[Intel-gfx] [PATCH 5/5] drm/i915: Drop struct_mutex around frontbuffer flushes
Since the frontbuffer has self-contained locking, it does not require us
to hold the BKL struct_mutex as we send invalidate and flush messages.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_fbdev.c | 43 +++---
1 file changed, 17 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 2a839b920267..9ab025bd5dc3 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -45,6 +45,14 @@
#include
#include "i915_drv.h"
+static void intel_fbdev_invalidate(struct intel_fbdev *ifbdev)
+{
+ struct drm_i915_gem_object *obj = ifbdev->fb->obj;
+ unsigned int origin = ifbdev->vma->fence ? ORIGIN_GTT : ORIGIN_CPU;
+
+ intel_fb_obj_invalidate(obj, origin);
+}
+
static int intel_fbdev_set_par(struct fb_info *info)
{
struct drm_fb_helper *fb_helper = info->par;
@@ -53,12 +61,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 +75,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;
}
@@ -87,15 +87,11 @@ static int intel_fbdev_pan_display(struct fb_var_screeninfo
*var,
struct drm_fb_helper *fb_helper = info->par;
struct intel_fbdev *ifbdev =
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;
}
@@ -839,11 +835,6 @@ void intel_fbdev_restore_mode(struct drm_device *dev)
if (!ifbdev->fb)
return;
- 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);
- }
+ if (drm_fb_helper_restore_fbdev_mode_unlocked(&ifbdev->helper) == 0)
+ intel_fbdev_invalidate(ifbdev);
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: Mark all skipped clflushes as leaving the CPU cache dirty
Currently, we may skip the clflush on an object if the object has not
yet allocated any pages. However, the object may still be polluting the
CPU cache and may now be in a coherent uncached domain - and so no
longer generating clflushing.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 921762c8f21b..48494c8c153b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3199,20 +3199,25 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
alignment, u64 flags)
void i915_gem_clflush_object(struct drm_i915_gem_object *obj,
bool force)
{
- /* If we don't have a page list set up, then we're not pinned
-* to GPU, and we can ignore the cache flush because it'll happen
-* again at bind time.
-*/
- if (!obj->mm.pages)
- return;
-
/*
* Stolen memory is always coherent with the GPU as it is explicitly
* marked as wc by the system, or the system is cache-coherent.
+* Similarly, we only access struct pages through the CPU cache, so
+* anything not backed by physical memory we consider to be always
+* coherent and not need clflushing.
*/
- if (obj->stolen || obj->phys_handle)
+ if (!i915_gem_object_has_struct_page(obj))
return;
+ /* If we don't have a page list set up, then we're not pinned
+* to GPU, and we can ignore the cache flush because it'll happen
+* again at bind time.
+*/
+ if (!obj->mm.pages) {
+ obj->cache_dirty = true;
+ return;
+ }
+
/* If the GPU is snooping the contents of the CPU cache,
* we do not need to manually clear the CPU cache lines. However,
* the caches are only snooped when the render cache is
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: struct_mutex is not required for allocating the framebuffer
We do not need the BKL struct_mutex in order to allocate a GEM object,
nor to create the framebuffer, so resist the temptation to take the BKL
willy nilly. As this changes the locking contract around internal API
calls, the patch is a little larger than a plain removal of a pair of
mutex_lock/unlock.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 115 +++
drivers/gpu/drm/i915/intel_drv.h | 7 +--
drivers/gpu/drm/i915/intel_fbdev.c | 21 +++
3 files changed, 62 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9274386fba31..e339d2b58910 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -96,10 +96,9 @@ static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
static void ironlake_pch_clock_get(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
-static int intel_framebuffer_init(struct drm_device *dev,
- struct intel_framebuffer *ifb,
- struct drm_mode_fb_cmd2 *mode_cmd,
- struct drm_i915_gem_object *obj);
+static int intel_framebuffer_init(struct intel_framebuffer *ifb,
+ struct drm_i915_gem_object *obj,
+ struct drm_mode_fb_cmd2 *mode_cmd);
static void i9xx_set_pipeconf(struct intel_crtc *intel_crtc);
static void intel_set_pipe_timings(struct intel_crtc *intel_crtc);
static void intel_set_pipe_src_size(struct intel_crtc *intel_crtc);
@@ -2118,11 +2117,13 @@ static void intel_tile_dims(const struct
drm_i915_private *dev_priv,
}
unsigned int
-intel_fb_align_height(struct drm_device *dev, unsigned int height,
- uint32_t pixel_format, uint64_t fb_modifier)
+intel_fb_align_height(struct drm_i915_private *dev_priv,
+ unsigned int height,
+ uint32_t pixel_format,
+ uint64_t fb_modifier)
{
unsigned int cpp = drm_format_plane_cpp(pixel_format, 0);
- unsigned int tile_height = intel_tile_height(to_i915(dev), fb_modifier,
cpp);
+ unsigned int tile_height = intel_tile_height(dev_priv, fb_modifier,
cpp);
return ALIGN(height, tile_height);
}
@@ -2694,15 +2695,13 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
return false;
mutex_lock(&dev->struct_mutex);
-
obj = i915_gem_object_create_stolen_for_preallocated(dev,
base_aligned,
base_aligned,
size_aligned);
- if (!obj) {
- mutex_unlock(&dev->struct_mutex);
+ mutex_unlock(&dev->struct_mutex);
+ if (!obj)
return false;
- }
if (plane_config->tiling == I915_TILING_X)
obj->tiling_and_stride = fb->pitches[0] | I915_TILING_X;
@@ -2714,13 +2713,11 @@ intel_alloc_initial_plane_obj(struct intel_crtc *crtc,
mode_cmd.modifier[0] = fb->modifier[0];
mode_cmd.flags = DRM_MODE_FB_MODIFIERS;
- if (intel_framebuffer_init(dev, to_intel_framebuffer(fb),
- &mode_cmd, obj)) {
+ if (intel_framebuffer_init(to_intel_framebuffer(fb), obj, &mode_cmd)) {
DRM_DEBUG_KMS("intel fb init failed\n");
goto out_unref_obj;
}
- mutex_unlock(&dev->struct_mutex);
DRM_DEBUG_KMS("initial plane fb obj %p\n", obj);
return true;
@@ -8759,7 +8756,8 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
val = I915_READ(DSPSTRIDE(pipe));
fb->pitches[0] = val & 0xffc0;
- aligned_height = intel_fb_align_height(dev, fb->height,
+ aligned_height = intel_fb_align_height(dev_priv,
+ fb->height,
fb->pixel_format,
fb->modifier[0]);
@@ -9806,7 +9804,8 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
fb->pixel_format);
fb->pitches[0] = (val & 0x3ff) * stride_mult;
- aligned_height = intel_fb_align_height(dev, fb->height,
+ aligned_height = intel_fb_align_height(dev_priv,
+ fb->height,
fb->pixel_format,
fb->modifier[0]);
@@ -9903,7 +9902,8 @@ ironlake_get_initial_plane_config(struct intel_crtc *crtc,
val = I915_READ(DSPSTRIDE(pipe));
fb->pitches[0] = val & 0xffc0;
- aligned_height = intel_fb_align_height(dev, fb->height,
+ aligned_height = intel_fb_align_heig
[Intel-gfx] [PATCH 3/5] drm/i915: Remove struct_mutex for destroying framebuffers
We do not need to hold struct_mutex for destroying drm_i915_gem_objects
any longer, and with a little care taken over tracking
obj->framebuffer_references, we can relinquish BKL locking around the
destroy of intel_framebuffer.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +-
drivers/gpu/drm/i915/i915_gem_tiling.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 10 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 30777dee3f9c..1b42fa9145a0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2328,7 +2328,7 @@ struct drm_i915_gem_object {
struct reservation_object *resv;
/** References from framebuffers, locks out tiling changes. */
- unsigned long framebuffer_references;
+ atomic_t framebuffer_references;
/** Record of address bit 17 of each page at last unbind. */
unsigned long *bit_17;
diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c
b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index a6fc1bdc48af..3e6eabde1827 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -216,7 +216,7 @@ i915_gem_shrink(struct drm_i915_private *dev_priv,
if (!(flags & I915_SHRINK_ACTIVE) &&
(i915_gem_object_is_active(obj) ||
-obj->framebuffer_references))
+atomic_read(&obj->framebuffer_references)))
continue;
if (!can_release_pages(obj))
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 251d51b01174..07531c350ef2 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -206,7 +206,7 @@ i915_gem_set_tiling(struct drm_device *dev, void *data,
}
mutex_lock(&dev->struct_mutex);
- if (obj->pin_display || obj->framebuffer_references) {
+ if (obj->pin_display || atomic_read(&obj->framebuffer_references)) {
err = -EBUSY;
goto err;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 318d0002d2ca..9274386fba31 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15664,14 +15664,14 @@ static void intel_setup_outputs(struct drm_device
*dev)
static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
{
- struct drm_device *dev = fb->dev;
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
drm_framebuffer_cleanup(fb);
- mutex_lock(&dev->struct_mutex);
- WARN_ON(!intel_fb->obj->framebuffer_references--);
+
+ WARN_ON(atomic_read(&intel_fb->obj->framebuffer_references) == 0);
+ atomic_dec(&intel_fb->obj->framebuffer_references);
i915_gem_object_put(intel_fb->obj);
- mutex_unlock(&dev->struct_mutex);
+
kfree(intel_fb);
}
@@ -15916,7 +15916,7 @@ static int intel_framebuffer_init(struct drm_device
*dev,
return ret;
}
- intel_fb->obj->framebuffer_references++;
+ atomic_inc(&intel_fb->obj->framebuffer_references);
return 0;
}
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: Always flush the dirty CPU cache when pinning the scanout
Currently we only clflush the scanout if it is in the CPU domain. Also
flush if we have a pending CPU clflush. We also want to treat the
dirtyfb path similar, and flush any pending writes there as well.
v2: Only send the frontbuffer flush if we have CPU dirt.
Signed-off-by: Chris Wilson
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem.c | 22 +++---
drivers/gpu/drm/i915/intel_display.c | 5 -
2 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d2ad73d0b5b9..921762c8f21b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3373,12 +3373,12 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
enum i915_cache_level cache_level)
{
struct i915_vma *vma;
- int ret = 0;
+ int ret;
lockdep_assert_held(&obj->base.dev->struct_mutex);
if (obj->cache_level == cache_level)
- goto out;
+ return 0;
/* Inspect the list of currently bound VMA and unbind any that would
* be invalid given the new cache-level. This is principally to
@@ -3472,18 +3472,14 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
}
}
+ if (obj->base.write_domain == I915_GEM_DOMAIN_CPU &&
+ cpu_cache_is_coherent(obj->base.dev, obj->cache_level))
+ obj->cache_dirty = true;
+
list_for_each_entry(vma, &obj->vma_list, obj_link)
vma->node.color = cache_level;
obj->cache_level = cache_level;
-out:
- /* Flush the dirty CPU caches to the backing storage so that the
-* object is now coherent at its new cache level (with respect
-* to the access domain).
-*/
- if (obj->cache_dirty && cpu_write_needs_clflush(obj))
- i915_gem_clflush_object(obj, true);
-
return 0;
}
@@ -3639,7 +3635,11 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
vma->display_alignment = max_t(u64, vma->display_alignment, alignment);
- i915_gem_object_flush_cpu_write_domain(obj);
+ /* Treat this as an end-of-frame, like intel_user_framebuffer_dirty() */
+ if (obj->cache_dirty || obj->base.write_domain == I915_GEM_DOMAIN_CPU) {
+ i915_gem_clflush_object(obj, true);
+ intel_fb_obj_flush(obj, false, ORIGIN_CPU);
+ }
old_write_domain = obj->base.write_domain;
old_read_domains = obj->base.read_domains;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 01dbf1b94bbe..318d0002d2ca 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15701,7 +15701,10 @@ static int intel_user_framebuffer_dirty(struct
drm_framebuffer *fb,
struct drm_i915_gem_object *obj = intel_fb->obj;
mutex_lock(&dev->struct_mutex);
- intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
+ if (obj->pin_display && obj->cache_dirty) {
+ i915_gem_clflush_object(obj, true);
+ intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
+ }
mutex_unlock(&dev->struct_mutex);
return 0;
--
2.10.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general
When updating a patch set on the mailing list with new revisions
it is preferred to send those new patches as a reply to the patch
being revised and also to include the V2, V3, etc. in the subject.
If you have massive changes then it is OK to submit a new set but
it helps to include cover letter and version its subject as above
to help distinquish from previous sets.
Look through the mailing list and you will see examples of both
scenarios.
I think the protocol is also that if you revise a patch heavily
then you cannot carry the r-b tags given on the earlier patch but
rather you should get those people to re-review.
Daniel - these best practices are recorded somewhere, right?
Jeff
On Wed, Nov 09, 2016 at 10:51:30AM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> Rename some of the GuC fw loading code to make them more general. We
> will utilise them for HuC loading as well.
> s/intel_guc_fw/intel_uc_fw/g
> s/GUC_FIRMWARE/UC_FIRMWARE/g
>
> Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
> such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
> same purpose.
>
> v2: rebased on top of nightly.
> reapplied the search/replace as upstream code as changed.
> v3: rebased again on drm-nightly.
> v4: removed G from messages in shared fw fetch function.
> v5: rebased.
> v7: rebased.
> v8: rebased.
> v9: rebased.
> v10: rebased.
>
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Alex Dai
> Signed-off-by: Peter Antoine
> Reviewed-by: Dave Gordon
> Reviewed-by: Jeff McGee
> Reviewed-by: Carlos Santa
> Tested-by: Carlos Santa
> ---
> drivers/gpu/drm/i915/i915_debugfs.c| 12 +--
> drivers/gpu/drm/i915/i915_guc_submission.c | 4 +-
> drivers/gpu/drm/i915/intel_guc.h | 39
> drivers/gpu/drm/i915/intel_guc_loader.c| 156
> ++---
> 4 files changed, 106 insertions(+), 105 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index b681d42..7e206dd 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2353,7 +2353,7 @@ static int i915_llc(struct seq_file *m, void *data)
> static int i915_guc_load_status_info(struct seq_file *m, void *data)
> {
> struct drm_i915_private *dev_priv = node_to_i915(m->private);
> - struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
> + struct intel_uc_fw *guc_fw = &dev_priv->guc.guc_fw;
> u32 tmp, i;
>
> if (!HAS_GUC_UCODE(dev_priv))
> @@ -2361,15 +2361,15 @@ static int i915_guc_load_status_info(struct seq_file
> *m, void *data)
>
> seq_printf(m, "GuC firmware status:\n");
> seq_printf(m, "\tpath: %s\n",
> - guc_fw->guc_fw_path);
> + guc_fw->uc_fw_path);
> seq_printf(m, "\tfetch: %s\n",
> - intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
> + intel_uc_fw_status_repr(guc_fw->fetch_status));
> seq_printf(m, "\tload: %s\n",
> - intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
> + intel_uc_fw_status_repr(guc_fw->load_status));
> seq_printf(m, "\tversion wanted: %d.%d\n",
> - guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
> + guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
> seq_printf(m, "\tversion found: %d.%d\n",
> - guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
> + guc_fw->major_ver_found, guc_fw->minor_ver_found);
> seq_printf(m, "\theader: offset is %d; size = %d\n",
> guc_fw->header_offset, guc_fw->header_size);
> seq_printf(m, "\tuCode: offset is %d; size = %d\n",
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index 666dab7..fb59e44 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -1570,7 +1570,7 @@ int intel_guc_suspend(struct drm_device *dev)
> struct i915_gem_context *ctx;
> u32 data[3];
>
> - if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
> + if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
> return 0;
>
> gen9_disable_guc_interrupts(dev_priv);
> @@ -1598,7 +1598,7 @@ int intel_guc_resume(struct drm_device *dev)
> struct i915_gem_context *ctx;
> u32 data[3];
>
> - if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
> + if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
> return 0;
>
> if (i915.guc_log_level >= 0)
> diff --git a/drivers/gpu/drm/i915/intel_guc.h
> b/drivers/gpu/drm/i915/intel_guc.h
> index 0053258..6dc328f 100644
> --- a/drivers/gpu/drm/i915/intel_guc.h
> +++ b/drivers/gpu/drm/i915/intel_guc.h
> @@ -91,29 +91,29 @@ struct i915_guc_client {
> uint64_t submissions[I915_NUM_ENGINES];
> };
>
> -enum intel_guc_fw_status {
> - GUC_FIRMWARE_FAIL =
Re: [Intel-gfx] [PATCH] Implement Limited Video Range
On Wed, Nov 09, 2016 at 09:11:58PM +0100, Peter Frühberger wrote:
> I am currently not sure what the way forward should be.
>
> We are successfully implementing this patch in e.g. LibreELEC an embedded
> distribution for home theater pcs. But through current bug reports - I am
> not sure, if we should give such functionality to the user, that is
> overwritten on a lower level, e.g. it does not what the user expects.
>
> E.g. since some time displays are driven with 10 or 12 bit from the intel
> driver, image data is dithered, scaled back and forth without being
> transparent for the user. In fact we have some users with hdmi capture
> cards, coming back to us if some decoded values of their video stuff does
> not match.
Re-reading what was written (can't remember anymore obviously), I think
what both me and Daniel were after was a cleaner separation of the
"what should the infoframe say?" and "how should we mangle the color data?".
Daniel's "limit_color_range" is a wee bit too similar looking to
"limited_color_range" for my liking. So how about we go with something
like "bool compress_color_range". It also conveys the fact that we're
not just clamping things. Any objections/thoughts/better ideas?
>
> Best regards
> Peter
>
> On Mon, Nov 30, 2015 at 3:11 PM, Ville Syrjälä <
> ville.syrj...@linux.intel.com> wrote:
>
> > On Mon, Nov 30, 2015 at 09:43:32AM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 30, 2015 at 08:08:48AM +0100, Peter Frühberger wrote:
> > > > (Resent cause of moderation)
> > > >
> > > > This implements a highly needed feature in a minimal non instructive
> > way.
> > > > Consider a Limited Range display (like most TVs) where you want to
> > watch a
> > > > decoded video. The TV is set to limited range and the intel driver also
> > > > uses full scaling Limited 16:235 mode, e.g. if you display the gray
> > value
> > > > 16 - the driver will postprocess it to something like ~ 22.
> > > >
> > > > The following happens currently in linux intel video world:
> > > > Video is decoded with e.g. vaapi, the decoded surface is either used
> > via
> > > > EGL directly in Limited Range. Limited Range processing takes place
> > and at
> > > > the end while rendering the intel driver will scale down the limited
> > range
> > > > data again as it cannot distunguish of the data it gets when e.g.
> > rendering
> > > > with OpenGL like we succesfully do in kodi.
> > > >
> > > > Another use case is vaapi when using the old vaCopySurfaceGLX
> > > > (vaPutSurface) which would automatically use BT601 / BT709 matrix to
> > > > upscale the content without any dithering to Full Range RGB. Later on
> > this
> > > > is scaled down again with the Limited 16:235 setting and output.
> > Quality
> > > > degrades two times.
> > > >
> > > > Users and applications widely used want to make sure that colors
> > appear on
> > > > screen like they were processed after the last processing step. In
> > video
> > > > case two use cases make sense:
> > > >
> > > > a) scaling limited range to full range with dithering applied when you
> > need
> > > > to output fullrange
> > > > b) already having limited range and outputting that without any further
> > > > touching by the driver
> > > >
> > > > Use case a) is already possible. Usecase b) will be possible with the
> > > > attached patch. It is a possibility to get Limited Range on screen in
> > > > perfect quality in 2k15.
> > > >
> > > > For the future a userspace api to provide info frames and so on in a
> > > > generic way should be considered but until we have this I bet we have 2
> > > > years to go. This solution also works on X11 (without wayland) and is
> > > > useful for existing applications.
> > > >
> > > > Thanks much for consideration.
> > > >
> > > > ---
> > > > From deaa9d730c08aefefe3671d073d93d970bb39a31 Mon Sep 17 00:00:00 2001
> > > > From: fritsch
> > > > Date: Sun, 29 Nov 2015 16:38:14 +0100
> > > > Subject: [PATCH] Intel: Implement Video Color Range
> > > >
> > > > ---
> > > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > > drivers/gpu/drm/i915/intel_display.c | 4 ++--
> > > > drivers/gpu/drm/i915/intel_drv.h | 8
> > > > drivers/gpu/drm/i915/intel_hdmi.c| 17 +++--
> > > > drivers/gpu/drm/i915/intel_modes.c | 1 +
> > > > 5 files changed, 27 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 95bb27d..e453461 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -3449,6 +3449,7 @@ int intel_freq_opcode(struct drm_i915_private
> > > > *dev_priv, int val);
> > > > #define INTEL_BROADCAST_RGB_AUTO 0
> > > > #define INTEL_BROADCAST_RGB_FULL 1
> > > > #define INTEL_BROADCAST_RGB_LIMITED 2
> > > > +#define INTEL_BROADCAST_RGB_VIDEO 3
> > > >
> > > > static inline uint32_t i915_vgacntrl_reg(struct drm_device *dev)
> > > > {
> > > > diff --git a/drivers/gpu/drm/i915/
Re: [Intel-gfx] [PATCH 6/8] drm/i915/huc: Update SKL and BXT HuC Loading Support
On Wed, Nov 09, 2016 at 10:51:35AM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> This patch adds the HuC Loading for the BXT.
> Version 1.7 of the HuC firmware.
>
> It also updates the file construction and specifying the
> required version similar to that of GuC for both SKL and BXT.
> Add an extra field for the build number. Adopted the approach used in-
> https://patchwork.freedesktop.org/patch/104355/
>
The improved file construction should be rolled in as a revision to patch 3
as we discussed. It is bad form to submit a patch set where a later patch
is fixing an issue in an earlier patch. Just fix the original patch.
-Jeff
> v2: rebased.
> v3: rebased.
> changed file name to match the install package format.
> v7: rebased.
> v8: rebased.
> v10: rebased.
>
> Cc: Tvrtko Ursulin
> Cc: Jeff Mcgee
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Peter Antoine
> Reviewed-by: David Gordon
> ---
> drivers/gpu/drm/i915/intel_huc_loader.c | 26 +++---
> 1 file changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c
> b/drivers/gpu/drm/i915/intel_huc_loader.c
> index dcd9970..9a93adb 100644
> --- a/drivers/gpu/drm/i915/intel_huc_loader.c
> +++ b/drivers/gpu/drm/i915/intel_huc_loader.c
> @@ -39,10 +39,26 @@
> *
> * Note that HuC firmware loading must be done before GuC loading.
> */
> +#define SKL_FW_MAJOR 01
> +#define SKL_FW_MINOR 07
> +#define SKL_BLD_NUM 1398
>
> -#define I915_SKL_HUC_UCODE "i915/skl_huc_ver01_07_1398.bin"
> +#define BXT_FW_MAJOR 01
> +#define BXT_FW_MINOR 07
> +#define BXT_BLD_NUM 1398
> +
> +#define HUC_FW_PATH(platform, major, minor, bld_num) \
> + "i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
> + __stringify(minor) "_" __stringify(bld_num) ".bin"
> +
> +#define I915_SKL_HUC_UCODE HUC_FW_PATH(skl, SKL_FW_MAJOR, \
> + SKL_FW_MINOR, SKL_BLD_NUM)
> MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
>
> +#define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_FW_MAJOR, \
> + BXT_FW_MINOR, BXT_BLD_NUM)
> +MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
> +
> /**
> * huc_ucode_xfer() - DMA's the firmware
> * @dev_priv: the drm device
> @@ -148,8 +164,12 @@ void intel_huc_init(struct drm_device *dev)
>
> if (IS_SKYLAKE(dev_priv)) {
> fw_path = I915_SKL_HUC_UCODE;
> - huc_fw->major_ver_wanted = 1;
> - huc_fw->minor_ver_wanted = 7;
> + huc_fw->major_ver_wanted = SKL_FW_MAJOR;
> + huc_fw->minor_ver_wanted = SKL_FW_MINOR;
> + } else if (IS_BROXTON(dev_priv)) {
> + fw_path = I915_BXT_HUC_UCODE;
> + huc_fw->major_ver_wanted = BXT_FW_MAJOR;
> + huc_fw->minor_ver_wanted = BXT_FW_MINOR;
> }
>
> if (fw_path == NULL)
> --
> 2.7.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Implement Limited Video Range
I am currently not sure what the way forward should be.
We are successfully implementing this patch in e.g. LibreELEC an embedded
distribution for home theater pcs. But through current bug reports - I am
not sure, if we should give such functionality to the user, that is
overwritten on a lower level, e.g. it does not what the user expects.
E.g. since some time displays are driven with 10 or 12 bit from the intel
driver, image data is dithered, scaled back and forth without being
transparent for the user. In fact we have some users with hdmi capture
cards, coming back to us if some decoded values of their video stuff does
not match.
Best regards
Peter
On Mon, Nov 30, 2015 at 3:11 PM, Ville Syrjälä <
ville.syrj...@linux.intel.com> wrote:
> On Mon, Nov 30, 2015 at 09:43:32AM +0100, Daniel Vetter wrote:
> > On Mon, Nov 30, 2015 at 08:08:48AM +0100, Peter Frühberger wrote:
> > > (Resent cause of moderation)
> > >
> > > This implements a highly needed feature in a minimal non instructive
> way.
> > > Consider a Limited Range display (like most TVs) where you want to
> watch a
> > > decoded video. The TV is set to limited range and the intel driver also
> > > uses full scaling Limited 16:235 mode, e.g. if you display the gray
> value
> > > 16 - the driver will postprocess it to something like ~ 22.
> > >
> > > The following happens currently in linux intel video world:
> > > Video is decoded with e.g. vaapi, the decoded surface is either used
> via
> > > EGL directly in Limited Range. Limited Range processing takes place
> and at
> > > the end while rendering the intel driver will scale down the limited
> range
> > > data again as it cannot distunguish of the data it gets when e.g.
> rendering
> > > with OpenGL like we succesfully do in kodi.
> > >
> > > Another use case is vaapi when using the old vaCopySurfaceGLX
> > > (vaPutSurface) which would automatically use BT601 / BT709 matrix to
> > > upscale the content without any dithering to Full Range RGB. Later on
> this
> > > is scaled down again with the Limited 16:235 setting and output.
> Quality
> > > degrades two times.
> > >
> > > Users and applications widely used want to make sure that colors
> appear on
> > > screen like they were processed after the last processing step. In
> video
> > > case two use cases make sense:
> > >
> > > a) scaling limited range to full range with dithering applied when you
> need
> > > to output fullrange
> > > b) already having limited range and outputting that without any further
> > > touching by the driver
> > >
> > > Use case a) is already possible. Usecase b) will be possible with the
> > > attached patch. It is a possibility to get Limited Range on screen in
> > > perfect quality in 2k15.
> > >
> > > For the future a userspace api to provide info frames and so on in a
> > > generic way should be considered but until we have this I bet we have 2
> > > years to go. This solution also works on X11 (without wayland) and is
> > > useful for existing applications.
> > >
> > > Thanks much for consideration.
> > >
> > > ---
> > > From deaa9d730c08aefefe3671d073d93d970bb39a31 Mon Sep 17 00:00:00 2001
> > > From: fritsch
> > > Date: Sun, 29 Nov 2015 16:38:14 +0100
> > > Subject: [PATCH] Intel: Implement Video Color Range
> > >
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > drivers/gpu/drm/i915/intel_display.c | 4 ++--
> > > drivers/gpu/drm/i915/intel_drv.h | 8
> > > drivers/gpu/drm/i915/intel_hdmi.c| 17 +++--
> > > drivers/gpu/drm/i915/intel_modes.c | 1 +
> > > 5 files changed, 27 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 95bb27d..e453461 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -3449,6 +3449,7 @@ int intel_freq_opcode(struct drm_i915_private
> > > *dev_priv, int val);
> > > #define INTEL_BROADCAST_RGB_AUTO 0
> > > #define INTEL_BROADCAST_RGB_FULL 1
> > > #define INTEL_BROADCAST_RGB_LIMITED 2
> > > +#define INTEL_BROADCAST_RGB_VIDEO 3
> > >
> > > static inline uint32_t i915_vgacntrl_reg(struct drm_device *dev)
> > > {
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 71860f8..ea40d81 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -8605,7 +8605,7 @@ static void intel_set_pipe_csc(struct drm_crtc
> *crtc)
> > >* consideration.
> > >*/
> > >
> > > - if (intel_crtc->config->limited_color_range)
> > > + if (intel_crtc->config->limited_color_range &&
> > > !intel_crtc->config->video_color_range)
> > > coeff = ((235 - 16) * (1 << 12) / 255) & 0xff8; /* 0.xxx... */
> > >
> > > /*
> > > @@ -8629,7 +8629,7 @@ static void intel_set_pipe_csc(struct drm_crtc
> *crtc)
> > > if (INTEL_INFO(dev)->gen > 6) {
> > > uint16_t postoff = 0;
> > >
> > > - if (intel_crtc->config->limi
Re: [Intel-gfx] [PATCH v9 01/11] drm/i915: Add i915 perf infrastructure
On 7 November 2016 at 19:49, Robert Bragg wrote:
> Adds base i915 perf infrastructure for Gen performance metrics.
>
> This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> properties to configure a stream of metrics and returns a new fd usable
> with standard VFS system calls including read() to read typed and sized
> records; ioctl() to enable or disable capture and poll() to wait for
> data.
>
> A stream is opened something like:
>
> uint64_t properties[] = {
> /* Single context sampling */
> DRM_I915_PERF_PROP_CTX_HANDLE,ctx_handle,
>
> /* Include OA reports in samples */
> DRM_I915_PERF_PROP_SAMPLE_OA, true,
>
> /* OA unit configuration */
> DRM_I915_PERF_PROP_OA_METRICS_SET,metrics_set_id,
> DRM_I915_PERF_PROP_OA_FORMAT, report_format,
> DRM_I915_PERF_PROP_OA_EXPONENT, period_exponent,
>};
>struct drm_i915_perf_open_param parm = {
> .flags = I915_PERF_FLAG_FD_CLOEXEC |
>I915_PERF_FLAG_FD_NONBLOCK |
>I915_PERF_FLAG_DISABLED,
> .properties_ptr = (uint64_t)properties,
> .num_properties = sizeof(properties) / 16,
>};
>int fd = drmIoctl(drm_fd, DRM_IOCTL_I915_PERF_OPEN, ¶m);
>
> Records read all start with a common { type, size } header with
> DRM_I915_PERF_RECORD_SAMPLE being of most interest. Sample records
> contain an extensible number of fields and it's the
> DRM_I915_PERF_PROP_SAMPLE_xyz properties given when opening that
> determine what's included in every sample.
>
> No specific streams are supported yet so any attempt to open a stream
> will return an error.
>
> v2:
> use i915_gem_context_get() - Chris Wilson
> v3:
> update read() interface to avoid passing state struct - Chris Wilson
> fix some rebase fallout, with i915-perf init/deinit
> v4:
> s/DRM_IORW/DRM_IOW/ - Emil Velikov
>
> Signed-off-by: Robert Bragg
> Reviewed-by: Matthew Auld
> Reviewed-by: Sourab Gupta
Minor nit, there are a fair few DRM_ERROR's missing a new line.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 09/11] drm/i915: add dev.i915.oa_max_sample_rate sysctl
On 7 November 2016 at 19:49, Robert Bragg wrote:
> The maximum OA sampling frequency is now configurable via a
> dev.i915.oa_max_sample_rate sysctl parameter.
>
> Following the precedent set by perf's similar
> kernel.perf_event_max_sample_rate the default maximum rate is 10Hz
>
> Signed-off-by: Robert Bragg
> ---
> drivers/gpu/drm/i915/i915_perf.c | 61
>
> 1 file changed, 50 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index e51c1d8..1a87fe9 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -82,6 +82,21 @@ static u32 i915_perf_stream_paranoid = true;
> #define INVALID_CTX_ID 0x
>
>
> +/* For sysctl proc_dointvec_minmax of i915_oa_max_sample_rate
> + *
> + * 160ns is the smallest sampling period we can theoretically program the OA
> + * unit with on Haswell, corresponding to 6.25MHz.
> + */
> +static int oa_sample_rate_hard_limit = 625;
> +
> +/* Theoretically we can program the OA unit to sample every 160ns but don't
> + * allow that by default unless root...
> + *
> + * The default threshold of 10Hz is based on perf's similar
> + * kernel.perf_event_max_sample_rate sysctl parameter.
> + */
> +static u32 i915_oa_max_sample_rate = 10;
> +
> /* XXX: beware if future OA HW adds new report formats that the current
> * code assumes all reports have a power-of-two size and ~(size - 1) can
> * be used as a mask to align the OA tail pointer.
> @@ -1314,6 +1329,7 @@ static int read_properties_unlocked(struct
> drm_i915_private *dev_priv,
> }
>
> for (i = 0; i < n_props; i++) {
> + u64 oa_period, oa_freq_hz;
> u64 id, value;
> int ret;
>
> @@ -1359,21 +1375,35 @@ static int read_properties_unlocked(struct
> drm_i915_private *dev_priv,
> return -EINVAL;
> }
>
> - /* NB: The exponent represents a period as follows:
> -*
> -* 80ns * 2^(period_exponent + 1)
> -*
> -* Theoretically we can program the OA unit to sample
> + /* Theoretically we can program the OA unit to sample
> * every 160ns but don't allow that by default unless
> * root.
> *
> -* Referring to perf's
> -* kernel.perf_event_max_sample_rate for a precedent
> -* (10 by default); with an OA exponent of 6 we
> get
> -* a period of 10.240 microseconds -just under
> 10Hz
> +* On Haswell the period is derived from the exponent
> +* as:
> +*
> +* period = 80ns * 2^(exponent + 1)
> +*/
> + BUILD_BUG_ON(sizeof(oa_period) != 8);
> + oa_period = 80ull * (2ull << value);
> +
> + /* This check is primarily to ensure that oa_period <=
> +* UINT32_MAX (before passing to do_div which only
> +* accepts a u32 denominator), but we can also skip
> +* checking anything < 1Hz which implicitly can't be
> +* limited via an integer oa_max_sample_rate.
> */
> - if (value < 6 && !capable(CAP_SYS_ADMIN)) {
> - DRM_ERROR("Minimum OA sampling exponent is 6
> without root privileges\n");
> + if (oa_period <= NSEC_PER_SEC) {
> + u64 tmp = NSEC_PER_SEC;
> + do_div(tmp, oa_period);
> + oa_freq_hz = tmp;
> + } else
> + oa_freq_hz = 0;
> +
> + if (oa_freq_hz > i915_oa_max_sample_rate &&
> + !capable(CAP_SYS_ADMIN)) {
> + DRM_ERROR("OA exponent would exceed the max
> sampling frequency (sysctl dev.i915.oa_max_sample_rate) %uHz without root
> privileges\n",
This line is getting a little too long.
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/8] drm/i915/guc: Make the GuC fw loading helper functions general
== Series Details == Series: series starting with [1/8] drm/i915/guc: Make the GuC fw loading helper functions general URL : https://patchwork.freedesktop.org/series/15061/ State : success == Summary == Series 15061v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/15061/revisions/1/mbox/ fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 52614b054251bd5869e20b34c5495c0e646fe64f drm-intel-nightly: 2016y-11m-09d-16h-58m-19s UTC integration manifest 507b7e0 drm/i915/get_params: Add HuC status to getparams a405b67 drm/i915/HuC: Add HuC Loading support on KBL c10716e drm/i915/huc: Update SKL and BXT HuC Loading Support f7aaaf3 drm/i915/huc: Support HuC authentication 987fb23 drm/i915/huc: Add debugfs for HuC loading status check a6a97d8 drm/i915/huc: Add HuC fw loading support 646a02e drm/i915/huc: Unified css_header struct for GuC and HuC e0049d2 drm/i915/guc: Make the GuC fw loading helper functions general == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2945/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/GuC: Combine the two kernel parameter into one
Replace i915.enable_guc_loading and i915.enable_guc_submission
with a single parameter - i915.enable_guc. Where:
-1 : Platform default (Only load GuC)
0 : Do not use GuC
1 : Load GuC, do not use Command Submission through GuC
2 : Load and use GuC for Command Submission
Cc: Tvrtko Ursulin
Cc: Jeff Mcgee
Cc: Rodrigo Vivi
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_guc_submission.c | 16 +---
drivers/gpu/drm/i915/i915_params.c | 17 +
drivers/gpu/drm/i915/i915_params.h | 3 +--
drivers/gpu/drm/i915/intel_guc.h | 2 ++
drivers/gpu/drm/i915/intel_guc_loader.c| 39 +++---
drivers/gpu/drm/i915/intel_lrc.c | 14 ---
6 files changed, 56 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 7809acf..a5ef268 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1471,13 +1471,15 @@ int i915_guc_submission_init(struct drm_i915_private
*dev_priv)
const size_t poolsize = GUC_MAX_GPU_CONTEXTS * ctxsize;
const size_t gemsize = round_up(poolsize, PAGE_SIZE);
struct intel_guc *guc = &dev_priv->guc;
+ struct intel_uc_fw *guc_fw = &dev_priv->guc.guc_fw;
+
struct i915_vma *vma;
/* Wipe bitmap & delete client in case of reinitialisation */
bitmap_clear(guc->doorbell_bitmap, 0, GUC_MAX_DOORBELLS);
i915_guc_submission_disable(dev_priv);
- if (!i915.enable_guc_submission)
+ if (!guc_fw->enable_guc_submission)
return 0; /* not enabled */
if (guc->ctx_pool_vma)
@@ -1629,7 +1631,9 @@ void i915_guc_capture_logs(struct drm_i915_private
*dev_priv)
void i915_guc_flush_logs(struct drm_i915_private *dev_priv)
{
- if (!i915.enable_guc_submission || (i915.guc_log_level < 0))
+ struct intel_uc_fw *guc_fw = &dev_priv->guc.guc_fw;
+
+ if (!guc_fw->enable_guc_submission || (i915.guc_log_level < 0))
return;
/* First disable the interrupts, will be renabled afterwards */
@@ -1649,7 +1653,9 @@ void i915_guc_flush_logs(struct drm_i915_private
*dev_priv)
void i915_guc_unregister(struct drm_i915_private *dev_priv)
{
- if (!i915.enable_guc_submission)
+ struct intel_uc_fw *guc_fw = &dev_priv->guc.guc_fw;
+
+ if (!guc_fw->enable_guc_submission)
return;
mutex_lock(&dev_priv->drm.struct_mutex);
@@ -1659,7 +1665,9 @@ void i915_guc_unregister(struct drm_i915_private
*dev_priv)
void i915_guc_register(struct drm_i915_private *dev_priv)
{
- if (!i915.enable_guc_submission)
+ struct intel_uc_fw *guc_fw = &dev_priv->guc.guc_fw;
+
+ if (!guc_fw->enable_guc_submission)
return;
mutex_lock(&dev_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 629e433..4600f83 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -56,8 +56,7 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
- .enable_guc_loading = 0,
- .enable_guc_submission = 0,
+ .enable_guc = 0,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
@@ -215,15 +214,11 @@ MODULE_PARM_DESC(edp_vswing,
"(0=use value from vbt [default], 1=low power swing(200mV),"
"2=default swing(400mV))");
-module_param_named_unsafe(enable_guc_loading, i915.enable_guc_loading, int,
0400);
-MODULE_PARM_DESC(enable_guc_loading,
- "Enable GuC firmware loading "
- "(-1=auto, 0=never [default], 1=if available, 2=required)");
-
-module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission,
int, 0400);
-MODULE_PARM_DESC(enable_guc_submission,
- "Enable GuC submission "
- "(-1=auto, 0=never [default], 1=if available, 2=required)");
+module_param_named_unsafe(enable_guc, i915.enable_guc, int, 0400);
+MODULE_PARM_DESC(enable_guc,
+ "Enable GuC firmware loading and loading and submission"
+ "(-1=auto [default], 0=do not use GuC, 1=load only,"
+ "2=loading and submission)");
module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
MODULE_PARM_DESC(guc_log_level,
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 94efc89..d235595 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -45,8 +45,7 @@ struct i915_params {
int enable_ips;
int invert_brightness;
int enable_cmd_parser;
- int enable_guc_loading;
- int enable_guc_submission;
+ int enable_guc;
int guc_log_level;
int use_mmio_flip;
int mmio_d
[Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams
From: Peter Antoine
This patch will allow for getparams to return the status of the HuC.
As the HuC has to be validated by the GuC this patch uses the validated
status to show when the HuC is loaded and ready for use. You cannot use
the loaded status as with the GuC as the HuC is verified after it is
loaded and is not usable until it is verified.
v2: removed the forewakes as the registers are already force-woken.
(T.Ursulin)
v4: rebased.
v5: rebased.
v6: rebased.
v7: rebased.
Tested-by: Xiang Haihao
Signed-off-by: Anusha Srivatsa
Signed-off-by: Peter Antoine
Reviewed-by: Rodrigo Vivi
Reviewed-by: Jeff McGee
---
drivers/gpu/drm/i915/i915_drv.c | 5 +
drivers/gpu/drm/i915/intel_huc.h| 1 +
drivers/gpu/drm/i915/intel_huc_loader.c | 14 ++
include/uapi/drm/i915_drm.h | 1 +
4 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index aa44d8d..52a1941 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -49,6 +49,8 @@
#include "i915_trace.h"
#include "i915_vgpu.h"
#include "intel_drv.h"
+#include "intel_guc.h"
+#include "intel_huc.h"
static struct drm_driver driver;
@@ -346,6 +348,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
*/
value = 1;
break;
+ case I915_PARAM_HAS_HUC:
+ value = intel_is_huc_valid(dev_priv);
+ break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_huc.h b/drivers/gpu/drm/i915/intel_huc.h
index 3ce0299..2e150be 100644
--- a/drivers/gpu/drm/i915/intel_huc.h
+++ b/drivers/gpu/drm/i915/intel_huc.h
@@ -39,4 +39,5 @@ struct intel_huc {
void intel_huc_init(struct drm_device *dev);
void intel_huc_fini(struct drm_device *dev);
int intel_huc_load(struct drm_device *dev);
+extern int intel_is_huc_valid(struct drm_i915_private *dev_priv);
#endif
diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c
b/drivers/gpu/drm/i915/intel_huc_loader.c
index a388437..df149b7 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -290,3 +290,17 @@ void intel_huc_fini(struct drm_device *dev)
huc_fw->fetch_status = UC_FIRMWARE_NONE;
}
+
+/**
+ * intel_is_huc_valid() - Check to see if the HuC is fully loaded.
+ * @dev_priv: drm device to check.
+ *
+ * This function will return true if the guc has been loaded and
+ * has valid firmware. The simplest way of doing this is to check
+ * if the HuC has been validated, if so it must have been loaded.
+ */
+int intel_is_huc_valid(struct drm_i915_private *dev_priv)
+{
+ return ((I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED) != 0);
+}
+
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 03725fe..aa7667e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -388,6 +388,7 @@ typedef struct drm_i915_irq_wait {
#define I915_PARAM_HAS_POOLED_EU38
#define I915_PARAM_MIN_EU_IN_POOL 39
#define I915_PARAM_MMAP_GTT_VERSION 40
+#define I915_PARAM_HAS_HUC 42
typedef struct drm_i915_getparam {
__s32 param;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/8] drm/i915/huc: Update SKL and BXT HuC Loading Support
From: Peter Antoine
This patch adds the HuC Loading for the BXT.
Version 1.7 of the HuC firmware.
It also updates the file construction and specifying the
required version similar to that of GuC for both SKL and BXT.
Add an extra field for the build number. Adopted the approach used in-
https://patchwork.freedesktop.org/patch/104355/
v2: rebased.
v3: rebased.
changed file name to match the install package format.
v7: rebased.
v8: rebased.
v10: rebased.
Cc: Tvrtko Ursulin
Cc: Jeff Mcgee
Signed-off-by: Anusha Srivatsa
Signed-off-by: Peter Antoine
Reviewed-by: David Gordon
---
drivers/gpu/drm/i915/intel_huc_loader.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c
b/drivers/gpu/drm/i915/intel_huc_loader.c
index dcd9970..9a93adb 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -39,10 +39,26 @@
*
* Note that HuC firmware loading must be done before GuC loading.
*/
+#define SKL_FW_MAJOR 01
+#define SKL_FW_MINOR 07
+#define SKL_BLD_NUM 1398
-#define I915_SKL_HUC_UCODE "i915/skl_huc_ver01_07_1398.bin"
+#define BXT_FW_MAJOR 01
+#define BXT_FW_MINOR 07
+#define BXT_BLD_NUM 1398
+
+#define HUC_FW_PATH(platform, major, minor, bld_num) \
+ "i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
+ __stringify(minor) "_" __stringify(bld_num) ".bin"
+
+#define I915_SKL_HUC_UCODE HUC_FW_PATH(skl, SKL_FW_MAJOR, \
+ SKL_FW_MINOR, SKL_BLD_NUM)
MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
+#define I915_BXT_HUC_UCODE HUC_FW_PATH(bxt, BXT_FW_MAJOR, \
+ BXT_FW_MINOR, BXT_BLD_NUM)
+MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
+
/**
* huc_ucode_xfer() - DMA's the firmware
* @dev_priv: the drm device
@@ -148,8 +164,12 @@ void intel_huc_init(struct drm_device *dev)
if (IS_SKYLAKE(dev_priv)) {
fw_path = I915_SKL_HUC_UCODE;
- huc_fw->major_ver_wanted = 1;
- huc_fw->minor_ver_wanted = 7;
+ huc_fw->major_ver_wanted = SKL_FW_MAJOR;
+ huc_fw->minor_ver_wanted = SKL_FW_MINOR;
+ } else if (IS_BROXTON(dev_priv)) {
+ fw_path = I915_BXT_HUC_UCODE;
+ huc_fw->major_ver_wanted = BXT_FW_MAJOR;
+ huc_fw->minor_ver_wanted = BXT_FW_MINOR;
}
if (fw_path == NULL)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915/huc: Support HuC authentication
From: Peter Antoine
The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.
v2: rebased on top of drm-intel-nightly.
changed name format and upped version 1.7.
v3: rebased on top of drm-intel-nightly.
v4: changed wait_for_automic to wait_for
v5: rebased.
v7: rebased.
v8: rebased.
v9: rebased. Rename intel_huc_auh() to intel_guc_auth_huc()
and place the prototype in intel_guc.h,correct the comments.
v10: rebased.
Tested-by: Xiang Haihao
Signed-off-by: Anusha Srivatsa
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
Reviewed-by: Dave Gordon
Reviewed-by: Jeff McGee
---
drivers/gpu/drm/i915/i915_guc_submission.c | 63 ++
drivers/gpu/drm/i915/intel_guc.h | 2 +-
drivers/gpu/drm/i915/intel_guc_fwif.h | 1 +
drivers/gpu/drm/i915/intel_guc_loader.c| 2 +
4 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index fb59e44..7809acf 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -27,6 +27,7 @@
#include
#include "i915_drv.h"
#include "intel_guc.h"
+#include "intel_huc.h"
/**
* DOC: GuC-based command submission
@@ -1714,3 +1715,65 @@ int i915_guc_log_control(struct drm_i915_private
*dev_priv, u64 control_val)
return ret;
}
+
+/**
+ * intel_guc_auth_huc() - authenticate ucode
+ * @dev: the drm device
+ *
+ * Triggers a HuC fw authentication request to the GuC via host-2-guc
+ * interface.
+ */
+void intel_guc_auth_huc(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_guc *guc = &dev_priv->guc;
+ struct intel_huc *huc = &dev_priv->huc;
+ struct i915_vma *vma;
+ int ret;
+ u32 data[2];
+
+ /* Bypass the case where there is no HuC firmware */
+ if (huc->huc_fw.fetch_status == UC_FIRMWARE_NONE ||
+ huc->huc_fw.load_status == UC_FIRMWARE_NONE)
+ return;
+
+ if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS) {
+ DRM_ERROR("HuC: GuC fw wasn't loaded. Can't authenticate");
+ return;
+ }
+
+ if (huc->huc_fw.load_status != UC_FIRMWARE_SUCCESS) {
+ DRM_ERROR("HuC: fw wasn't loaded. Nothing to authenticate");
+ return;
+ }
+
+ vma = i915_gem_object_ggtt_pin(huc->huc_fw.uc_fw_obj, NULL, 0, 0, 0);
+ if (IS_ERR(vma)) {
+ DRM_DEBUG_DRIVER("pin failed %d\n", (int)PTR_ERR(vma));
+ return;
+ }
+
+
+ /* Invalidate GuC TLB to let GuC take the latest updates to GTT. */
+ I915_WRITE(GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+
+ /* Specify auth action and where public signature is. */
+ data[0] = HOST2GUC_ACTION_AUTHENTICATE_HUC;
+ data[1] = i915_ggtt_offset(vma) + huc->huc_fw.rsa_offset;
+
+ ret = host2guc_action(guc, data, ARRAY_SIZE(data));
+ if (ret) {
+ DRM_ERROR("HuC: GuC did not ack Auth request\n");
+ goto out;
+ }
+
+ /* Check authentication status, it should be done by now */
+ ret = wait_for((I915_READ(HUC_STATUS2) & HUC_FW_VERIFIED) > 0, 50);
+ if (ret) {
+ DRM_ERROR("HuC: Authentication failed\n");
+ goto out;
+ }
+
+out:
+ i915_vma_unpin(vma);
+}
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index ff6aba6..67a500c 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -197,5 +197,5 @@ void i915_guc_flush_logs(struct drm_i915_private *dev_priv);
void i915_guc_register(struct drm_i915_private *dev_priv);
void i915_guc_unregister(struct drm_i915_private *dev_priv);
int i915_guc_log_control(struct drm_i915_private *dev_priv, u64 control_val);
-
+void intel_guc_auth_huc(struct drm_device *dev);
#endif
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index c2a7fdd..99a092d 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -513,6 +513,7 @@ enum host2guc_action {
HOST2GUC_ACTION_EXIT_S_STATE = 0x502,
HOST2GUC_ACTION_SLPC_REQUEST = 0x3003,
HOST2GUC_ACTION_UK_LOG_ENABLE_LOGGING = 0x0E000,
+ HOST2GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
HOST2GUC_ACTION_LIMIT
};
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index dc79968..11e3bbb 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -531,6 +531,8 @@ int intel_guc_setup(struct drm_device *dev)
intel_uc_fw_status_repr(guc_fw->fetch_status),
intel_uc_fw_status_repr(guc_fw->load_status));
+ intel_guc_auth_huc(dev);
+
if (i915.enable_guc_submission) {
if (i915.guc_log_level >= 0)
[Intel-gfx] [PATCH 2/8] drm/i915/huc: Unified css_header struct for GuC and HuC
From: Peter Antoine
HuC firmware css header has almost exactly same definition as GuC
firmware except for the sw_version. Also, add a new member fw_type
into intel_uc_fw to indicate what kind of fw it is. So, the loader
will pull right sw_version from header.
v2: rebased on-top of drm-intel-nightly
v3: rebased on-top of drm-intel-nightly (again).
v4: rebased + spaces.
v7: rebased.
v8: rebased.
v9: rebased. Rename device_id to guc_branch_client_version,
make guc_sw_version a union. . Put UC_FW_TYPE_GUC
and UC_FW_TYPE_HUC into an enum.
v10: rebased.
Tested-by: Xiang Haihao
Signed-off-by: Anusha Srivatsa
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
Reviewed-by: Dave Gordon
Reviewed-by: Jeff McGee
---
drivers/gpu/drm/i915/intel_guc.h| 6 +
drivers/gpu/drm/i915/intel_guc_fwif.h | 21 +
drivers/gpu/drm/i915/intel_guc_loader.c | 41 ++---
3 files changed, 51 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 6dc328f..45dfa40 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -98,6 +98,11 @@ enum intel_uc_fw_status {
UC_FIRMWARE_SUCCESS
};
+enum {
+ UC_FW_TYPE_GUC,
+ UC_FW_TYPE_HUC
+};
+
/*
* This structure encapsulates all the data needed during the process
* of fetching, caching, and loading the firmware image into the GuC.
@@ -115,6 +120,7 @@ struct intel_uc_fw {
uint16_t major_ver_found;
uint16_t minor_ver_found;
+ uint32_t fw_type;
uint32_t header_size;
uint32_t header_offset;
uint32_t rsa_size;
diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h
b/drivers/gpu/drm/i915/intel_guc_fwif.h
index 324ea90..c2a7fdd 100644
--- a/drivers/gpu/drm/i915/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/intel_guc_fwif.h
@@ -154,7 +154,7 @@
* The GuC firmware layout looks like this:
*
* +---+
- * |guc_css_header |
+ * | uc_css_header |
* | |
* | contains major/minor version |
* +---+
@@ -181,9 +181,16 @@
* 3. Length info of each component can be found in header, in dwords.
* 4. Modulus and exponent key are not required by driver. They may not appear
*in fw. So driver will load a truncated firmware in this case.
+ *
+ * HuC firmware layout is same as GuC firmware.
+ *
+ * HuC firmware css header is different. However, the only difference is where
+ * the version information is saved. The uc_css_header is unified to support
+ * both. Driver should get HuC version from uc_css_header.huc_sw_version, while
+ * uc_css_header.guc_sw_version for GuC.
*/
-struct guc_css_header {
+struct uc_css_header {
uint32_t module_type;
/* header_size includes all non-uCode bits, including css_header, rsa
* key, modulus key and exponent data. */
@@ -214,8 +221,14 @@ struct guc_css_header {
char username[8];
char buildnumber[12];
- uint32_t device_id;
- uint32_t guc_sw_version;
+ union {
+ uint32_t guc_branch_client_version;
+ uint32_t huc_sw_version;
+ };
+ union {
+ uint32_t guc_sw_version;
+ uint32_t huc_reserved;
+ };
uint32_t prod_preprod_fw;
uint32_t reserved[12];
uint32_t header_info;
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 6683a88..ff26d2c 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -593,7 +593,7 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct
intel_uc_fw *uc_fw)
struct pci_dev *pdev = dev->pdev;
struct drm_i915_gem_object *obj;
const struct firmware *fw;
- struct guc_css_header *css;
+ struct uc_css_header *css;
size_t size;
int err;
@@ -610,19 +610,19 @@ void intel_uc_fw_fetch(struct drm_device *dev, struct
intel_uc_fw *uc_fw)
uc_fw->uc_fw_path, fw);
/* Check the size of the blob before examining buffer contents */
- if (fw->size < sizeof(struct guc_css_header)) {
+ if (fw->size < sizeof(struct uc_css_header)) {
DRM_NOTE("Firmware header is missing\n");
goto fail;
}
- css = (struct guc_css_header *)fw->data;
+ css = (struct uc_css_header *)fw->data;
/* Firmware bits always start from header */
uc_fw->header_offset = 0;
uc_fw->header_size = (css->header_size_dw - css->modulus_size_dw -
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
- if (uc_fw->header_size != sizeof(struct guc_css_header)) {
+ if (uc_fw->header_size != sizeof(struct uc_css_header)) {
DRM_NOTE("CSS header definition mismatch\n");
got
[Intel-gfx] [PATCH 7/8] drm/i915/HuC: Add HuC Loading support on KBL
This patch adds the support to load HuC on KBL
Version 2.0
Cc: Jeff Mcgee
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_huc_loader.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c
b/drivers/gpu/drm/i915/intel_huc_loader.c
index 9a93adb..a388437 100644
--- a/drivers/gpu/drm/i915/intel_huc_loader.c
+++ b/drivers/gpu/drm/i915/intel_huc_loader.c
@@ -47,6 +47,10 @@
#define BXT_FW_MINOR 07
#define BXT_BLD_NUM 1398
+#define KBL_FW_MAJOR 02
+#define KBL_FW_MINOR 00
+#define KBL_BLD_NUM 1810
+
#define HUC_FW_PATH(platform, major, minor, bld_num) \
"i915/" __stringify(platform) "_huc_ver" __stringify(major) "_" \
__stringify(minor) "_" __stringify(bld_num) ".bin"
@@ -59,6 +63,10 @@ MODULE_FIRMWARE(I915_SKL_HUC_UCODE);
BXT_FW_MINOR, BXT_BLD_NUM)
MODULE_FIRMWARE(I915_BXT_HUC_UCODE);
+#define I915_KBL_HUC_UCODE HUC_FW_PATH(kbl, KBL_FW_MAJOR, \
+ KBL_FW_MINOR, KBL_BLD_NUM)
+MODULE_FIRMWARE(I915_KBL_HUC_UCODE);
+
/**
* huc_ucode_xfer() - DMA's the firmware
* @dev_priv: the drm device
@@ -170,6 +178,10 @@ void intel_huc_init(struct drm_device *dev)
fw_path = I915_BXT_HUC_UCODE;
huc_fw->major_ver_wanted = BXT_FW_MAJOR;
huc_fw->minor_ver_wanted = BXT_FW_MINOR;
+ } else if (IS_KABYLAKE(dev_priv)) {
+ fw_path = I915_KBL_HUC_UCODE;
+ huc_fw->major_ver_wanted = KBL_FW_MAJOR;
+ huc_fw->minor_ver_wanted = KBL_FW_MINOR;
}
if (fw_path == NULL)
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading helper functions general
From: Peter Antoine
Rename some of the GuC fw loading code to make them more general. We
will utilise them for HuC loading as well.
s/intel_guc_fw/intel_uc_fw/g
s/GUC_FIRMWARE/UC_FIRMWARE/g
Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such as 'guc' or 'guc_fw' either is renamed to 'uc' or removed for
same purpose.
v2: rebased on top of nightly.
reapplied the search/replace as upstream code as changed.
v3: rebased again on drm-nightly.
v4: removed G from messages in shared fw fetch function.
v5: rebased.
v7: rebased.
v8: rebased.
v9: rebased.
v10: rebased.
Signed-off-by: Anusha Srivatsa
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
Reviewed-by: Dave Gordon
Reviewed-by: Jeff McGee
Reviewed-by: Carlos Santa
Tested-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_debugfs.c| 12 +--
drivers/gpu/drm/i915/i915_guc_submission.c | 4 +-
drivers/gpu/drm/i915/intel_guc.h | 39
drivers/gpu/drm/i915/intel_guc_loader.c| 156 ++---
4 files changed, 106 insertions(+), 105 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b681d42..7e206dd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2353,7 +2353,7 @@ static int i915_llc(struct seq_file *m, void *data)
static int i915_guc_load_status_info(struct seq_file *m, void *data)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
- struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
+ struct intel_uc_fw *guc_fw = &dev_priv->guc.guc_fw;
u32 tmp, i;
if (!HAS_GUC_UCODE(dev_priv))
@@ -2361,15 +2361,15 @@ static int i915_guc_load_status_info(struct seq_file
*m, void *data)
seq_printf(m, "GuC firmware status:\n");
seq_printf(m, "\tpath: %s\n",
- guc_fw->guc_fw_path);
+ guc_fw->uc_fw_path);
seq_printf(m, "\tfetch: %s\n",
- intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
+ intel_uc_fw_status_repr(guc_fw->fetch_status));
seq_printf(m, "\tload: %s\n",
- intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
+ intel_uc_fw_status_repr(guc_fw->load_status));
seq_printf(m, "\tversion wanted: %d.%d\n",
- guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
+ guc_fw->major_ver_wanted, guc_fw->minor_ver_wanted);
seq_printf(m, "\tversion found: %d.%d\n",
- guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
+ guc_fw->major_ver_found, guc_fw->minor_ver_found);
seq_printf(m, "\theader: offset is %d; size = %d\n",
guc_fw->header_offset, guc_fw->header_size);
seq_printf(m, "\tuCode: offset is %d; size = %d\n",
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 666dab7..fb59e44 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1570,7 +1570,7 @@ int intel_guc_suspend(struct drm_device *dev)
struct i915_gem_context *ctx;
u32 data[3];
- if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+ if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
return 0;
gen9_disable_guc_interrupts(dev_priv);
@@ -1598,7 +1598,7 @@ int intel_guc_resume(struct drm_device *dev)
struct i915_gem_context *ctx;
u32 data[3];
- if (guc->guc_fw.guc_fw_load_status != GUC_FIRMWARE_SUCCESS)
+ if (guc->guc_fw.load_status != UC_FIRMWARE_SUCCESS)
return 0;
if (i915.guc_log_level >= 0)
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 0053258..6dc328f 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -91,29 +91,29 @@ struct i915_guc_client {
uint64_t submissions[I915_NUM_ENGINES];
};
-enum intel_guc_fw_status {
- GUC_FIRMWARE_FAIL = -1,
- GUC_FIRMWARE_NONE = 0,
- GUC_FIRMWARE_PENDING,
- GUC_FIRMWARE_SUCCESS
+enum intel_uc_fw_status {
+ UC_FIRMWARE_FAIL = -1,
+ UC_FIRMWARE_NONE = 0,
+ UC_FIRMWARE_PENDING,
+ UC_FIRMWARE_SUCCESS
};
/*
* This structure encapsulates all the data needed during the process
* of fetching, caching, and loading the firmware image into the GuC.
*/
-struct intel_guc_fw {
- struct drm_device * guc_dev;
- const char *guc_fw_path;
- size_t guc_fw_size;
- struct drm_i915_gem_object *guc_fw_obj;
- enum intel_guc_fw_statusguc_fw_fetch_status;
- enum intel_guc_fw_statusguc_fw_load_status;
-
- uint16_tguc_fw_major_wanted;
- uint16_tguc_fw_minor_wanted;
- uint16_t
[Intel-gfx] [PATCH 4/8] drm/i915/huc: Add debugfs for HuC loading status check
From: Peter Antoine
Add debugfs entry for HuC loading status check.
v2: rebase on-top of drm-intel-nightly.
v3: rebased again.
v7: rebased.
v8: rebased.
v9: rebased.
v10: rebased.
Tested-by: Xiang Haihao
Signed-off-by: Anusha Srivatsa
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
Reviewed-by: Dave Gordon
Reviewed-by: Jeff McGee
---
drivers/gpu/drm/i915/i915_debugfs.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7e206dd..83967a0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2350,6 +2350,36 @@ static int i915_llc(struct seq_file *m, void *data)
return 0;
}
+static int i915_huc_load_status_info(struct seq_file *m, void *data)
+{
+ struct drm_i915_private *dev_priv = node_to_i915(m->private);
+ struct intel_uc_fw *huc_fw = &dev_priv->huc.huc_fw;
+
+ if (!HAS_HUC_UCODE(dev_priv))
+ return 0;
+
+ seq_puts(m, "HuC firmware status:\n");
+ seq_printf(m, "\tpath: %s\n", huc_fw->uc_fw_path);
+ seq_printf(m, "\tfetch: %s\n",
+ intel_uc_fw_status_repr(huc_fw->fetch_status));
+ seq_printf(m, "\tload: %s\n",
+ intel_uc_fw_status_repr(huc_fw->load_status));
+ seq_printf(m, "\tversion wanted: %d.%d\n",
+ huc_fw->major_ver_wanted, huc_fw->minor_ver_wanted);
+ seq_printf(m, "\tversion found: %d.%d\n",
+ huc_fw->major_ver_found, huc_fw->minor_ver_found);
+ seq_printf(m, "\theader: offset is %d; size = %d\n",
+ huc_fw->header_offset, huc_fw->header_size);
+ seq_printf(m, "\tuCode: offset is %d; size = %d\n",
+ huc_fw->ucode_offset, huc_fw->ucode_size);
+ seq_printf(m, "\tRSA: offset is %d; size = %d\n",
+ huc_fw->rsa_offset, huc_fw->rsa_size);
+
+ seq_printf(m, "\nHuC status 0x%08x:\n", I915_READ(HUC_STATUS2));
+
+ return 0;
+}
+
static int i915_guc_load_status_info(struct seq_file *m, void *data)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -5411,6 +5441,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_guc_info", i915_guc_info, 0},
{"i915_guc_load_status", i915_guc_load_status_info, 0},
{"i915_guc_log_dump", i915_guc_log_dump, 0},
+ {"i915_huc_load_status", i915_huc_load_status_info, 0},
{"i915_frequency_info", i915_frequency_info, 0},
{"i915_hangcheck_info", i915_hangcheck_info, 0},
{"i915_drpc_info", i915_drpc_info, 0},
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/8] drm/i915/huc: Add HuC fw loading support
From: Peter Antoine
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.
v2: rebased on-top of drm-intel-nightly.
removed if(HAS_GUC()) before the guc call. (D.Gordon)
update huc_version number of format.
v3: rebased to drm-intel-nightly, changed the file name format to
match the one in the huc package.
Changed dev->dev_private to to_i915()
v4: moved function back to where it was.
change wait_for_atomic to wait_for.
v5: rebased + comment changes.
v7: rebased.
v8: rebased.
v9: rebased. Changed the year in the copyright message to reflect
the right year.Correct the comments,remove the unwanted WARN message,
replace drm_gem_object_unreference() with i915_gem_object_put().Make the
prototypes in intel_huc.h non-extern.
v10: rebased.
Tested-by: Xiang Haihao
Signed-off-by: Anusha Srivatsa
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
Reviewed-by: Dave Gordon
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.c | 3 +
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_guc_reg.h | 3 +
drivers/gpu/drm/i915/intel_guc.h| 1 +
drivers/gpu/drm/i915/intel_guc_loader.c | 6 +-
drivers/gpu/drm/i915/intel_huc.h| 42 ++
drivers/gpu/drm/i915/intel_huc_loader.c | 260
8 files changed, 317 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_huc.h
create mode 100644 drivers/gpu/drm/i915/intel_huc_loader.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0857e50..c99b0ee 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -55,6 +55,7 @@ i915-y += i915_cmd_parser.o \
# general-purpose microcontroller (GuC) support
i915-y += intel_guc_loader.o \
+ intel_huc_loader.o \
i915_guc_submission.o
# autogenerated null render state
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0213a30..aa44d8d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -599,6 +599,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_irq;
+ intel_huc_init(dev);
intel_guc_init(dev);
ret = i915_gem_init(dev);
@@ -626,6 +627,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
i915_gem_fini(dev_priv);
cleanup_irq:
+ intel_huc_fini(dev);
intel_guc_fini(dev);
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev);
@@ -1313,6 +1315,7 @@ void i915_driver_unload(struct drm_device *dev)
/* Flush any outstanding unpin_work. */
drain_workqueue(dev_priv->wq);
+ intel_huc_fini(dev);
intel_guc_fini(dev);
i915_gem_fini(dev_priv);
intel_fbc_cleanup_cfb(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 30777de..ebef982 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -56,6 +56,7 @@
#include "intel_bios.h"
#include "intel_dpll_mgr.h"
#include "intel_guc.h"
+#include "intel_huc.h"
#include "intel_lrc.h"
#include "intel_ringbuffer.h"
@@ -1804,6 +1805,7 @@ struct drm_i915_private {
struct intel_gvt *gvt;
+ struct intel_huc huc;
struct intel_guc guc;
struct intel_csr csr;
@@ -2928,6 +2930,7 @@ struct drm_i915_cmd_table {
#define HAS_GUC(dev) (INTEL_INFO(dev)->has_guc)
#define HAS_GUC_UCODE(dev) (HAS_GUC(dev))
#define HAS_GUC_SCHED(dev) (HAS_GUC(dev))
+#define HAS_HUC_UCODE(dev) (HAS_GUC(dev))
#define HAS_RESOURCE_STREAMER(dev) (INTEL_INFO(dev)->has_resource_streamer)
diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h
b/drivers/gpu/drm/i915/i915_guc_reg.h
index a47e1e4..64e942a 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -61,9 +61,12 @@
#define DMA_ADDRESS_SPACE_GTT (8 << 16)
#define DMA_COPY_SIZE _MMIO(0xc310)
#define DMA_CTRL _MMIO(0xc314)
+#define HUC_UKERNEL(1<<9)
#define UOS_MOVE (1<<4)
#define START_DMA (1<<0)
#define DMA_GUC_WOPCM_OFFSET _MMIO(0xc340)
+#define HUC_LOADING_AGENT_VCR (0<<1)
+#define HUC_LOADING_AGENT_GUC (1<<1)
#define GUC_WOPCM_OFFSET_VALUE 0x8 /* 512KB */
#define GUC_MAX_IDLE_COUNT _MMIO(0xC3E4)
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index 45dfa40..ff6aba6 100644
--- a/drivers/gpu/drm/i915/intel_guc.h
+++ b/drivers/gpu/drm/i915/intel_guc.h
@@ -183,6 +183,7 @@ extern co
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Make GPU pages movable
On Wed, 9 Nov 2016, Daniel Vetter wrote: > > Hi all -mm folks! > > Any feedback on these two? It's kinda an intermediate step towards a > full-blown gemfs, and I think useful for that. Or do we need to go > directly to our own backing storage thing? Aside from ack/nack from -mm I > think this is ready for merging. I'm currently considering them at last: will report back later. Full-blown gemfs does not come in here, of course; but let me fire a warning shot since you mention it: if it's going to use swap, then we shall probably have to nak it in favour of continuing to use infrastructure from mm/shmem.c. I very much understand why you would love to avoid that dependence, but I doubt it can be safely bypassed. Hugh ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: remove duplicated memsets in skl_allocate_pipe_ddb()
On Wed, Nov 09, 2016 at 11:27:37AM +0200, Jani Nikula wrote:
> On Wed, 09 Nov 2016, Matt Roper wrote:
> > On Tue, Nov 08, 2016 at 03:21:22PM -0200, Paulo Zanoni wrote:
> >> One of the memsets was added by 5a920b85f2c6 ("drm/i915/gen9: fix DDB
> >> partitioning for multi-screen cases"), and the other was added by
> >> 01c72d6c17 ("drm/i915/gen9: fix DDB partitioning for multi-screen
> >> cases"). I'm confused and I'll let the maintainers find out what went
> >> wrong here.
> >>
> >> Cc: Jani Nikula
> >> Signed-off-by: Paulo Zanoni
> >
> > I think this is just an artifact of having the patch in both -next and
> > -fixes. The context probably changed later in -next causing a conflict
> > when the two were merged, and then the merge resolution accidentally
> > duplicated this hunk. The merge commit ac4139ed7 is where we wound up
> > with the two copies:
>
> I don't have that merge commit. Is that a nightly rebuild?
Yeah, it's part of a nightly rebuild. Looks like
82282577545 is the equivalent now.
> I don't think we even have this issue in anywhere other than
> nightly. There isn't a branch we could apply this fix to.
Yeah, the patch can't apply anywhere directly, but I thought we could
make rerere forget its resolution of intel_pm.c for that merge and then
fix it by hand so that future merges behave correctly?
Matt
>
> BR,
> Jani.
>
>
> >
> > diff --cc drivers/gpu/drm/i915/intel_pm.c
> > index db24f89,cc9e0c0..88e28c9
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@@ -3361,11 -3404,13 +3404,17 @@@ skl_allocate_pipe_ddb(struct
> > intel_crtc
> > unsigned int total_data_rate;
> > int num_active;
> > int id, i;
> > + unsigned plane_data_rate[I915_MAX_PLANES] = {};
> > + unsigned plane_y_data_rate[I915_MAX_PLANES] = {};
> > +
> > + /* Clear the partitioning for disabled planes. */
> > + memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
> > + memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
> >
> > + /* Clear the partitioning for disabled planes. */
> > + memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
> > + memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
> > +
> > if (WARN_ON(!state))
> > return 0;
> >
> > Dropping one looks good to me.
> >
> > Reviewed-by: Matt Roper
> >
> >> ---
> >> drivers/gpu/drm/i915/intel_pm.c | 4
> >> 1 file changed, 4 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> >> b/drivers/gpu/drm/i915/intel_pm.c
> >> index 88e28c9..cc9e0c0 100644
> >> --- a/drivers/gpu/drm/i915/intel_pm.c
> >> +++ b/drivers/gpu/drm/i915/intel_pm.c
> >> @@ -3411,10 +3411,6 @@ skl_allocate_pipe_ddb(struct intel_crtc_state
> >> *cstate,
> >>memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
> >>memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
> >>
> >> - /* Clear the partitioning for disabled planes. */
> >> - memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
> >> - memset(ddb->y_plane[pipe], 0, sizeof(ddb->y_plane[pipe]));
> >> -
> >>if (WARN_ON(!state))
> >>return 0;
> >>
> >> --
> >> 2.7.4
> >>
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Jani Nikula, Intel Open Source Technology Center
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/8] drm/i915/skl+: use linetime latency instead of ddb size
Em Qua, 2016-11-09 às 20:28 +0530, Mahesh Kumar escreveu:
> Hi,
>
>
> On Monday 31 October 2016 11:33 PM, Paulo Zanoni wrote:
> >
> > Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu:
> > >
> > > This patch make changes to use linetime latency instead of
> > > allocated
> > > DDB size during plane watermark calculation in switch case, This
> > > is
> > > required to implement new DDB allocation algorithm.
> > >
> > > In New Algorithm DDB is allocated based on WM values, because of
> > > which
> > > number of DDB blocks will not be available during WM calculation,
> > > So this "linetime latency" is suggested by SV/HW team to use
> > > during
> > > switch-case for WM blocks selection.
> > >
> > > Changes since v1:
> > > - Rebase on top of Paulo's patch series
> > > Changes since v2:
> > > - Fix if-else condition (pointed by Maarten)
> > >
> > > Signed-off-by: "Kumar, Mahesh"
> > > ---
> > > drivers/gpu/drm/i915/intel_pm.c | 6 +-
> > > 1 file changed, 5 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > b/drivers/gpu/drm/i915/intel_pm.c
> > > index 7f1748a..098336d 100644
> > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > @@ -3616,10 +3616,14 @@ static int skl_compute_plane_wm(const
> > > struct
> > > drm_i915_private *dev_priv,
> > > fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
> > > selected_result = max(method2, y_tile_minimum);
> > > } else {
> > > + uint32_t linetime_us = 0;
> > > +
> > > + linetime_us = DIV_ROUND_UP(width * 1000,
> > > + skl_pipe_pixel_rate(cstate));
> > Can't we just call skl_compute_linetime_wm() here? I don't like
> > having
> > two pieces of the code computing the same thing. My last round of
> > bug
> > fixes included a fix for duplicated code that got out of sync after
> > spec changes.
> These two have different values in skl_compute_linetime_wm we
> multiply
> by 8, not here.
You can move the *8 multiplication to the caller that needs it.
> >
> >
> > >
> > > if ((cpp * cstate-
> > > >base.adjusted_mode.crtc_htotal /
> > > 512 < 1) &&
> > > (plane_bytes_per_line / 512 < 1))
> > > selected_result = method2;
> > > - else if ((ddb_allocation /
> > > plane_blocks_per_line) >=
> > > 1)
> > > + else if (latency >= linetime_us)
> > Still doesn't match the spec. The "ddb_allocation /
> > planes_block_per_line" is still necessary.
> After New algorithm patch, we will not have access to ddb_allocation,
> as
> allocation will happen later.
> So we can't use ddb_allocation in our calculation, This check in
> Bspec
> is kept for the environment/OS where we don't allocate DDB
> dynamically.
> hence those OS will have access to ddb_allocation during WM
> calculation
> phase.
> thanks,
So the patch that implements the DDB allocation can remove the check
when/if it gets merged. The code with only this patch does not use the
new algorithm, so let's make everything works if we only have it
applied. Bisectability is really important.
>
> Regards,
> -Mahesh
> >
> >
> > >
> > > selected_result = min(method1,
> > > method2);
> > > else
> > > selected_result = method1;
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()
On Wednesday, 2016-11-09 14:13:40 +0100, Daniel Vetter wrote: > On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom > wrote: > >> Well, had to drop it again since it didn't compile: > >> > >> > >> CC [M] drivers/gpu/drm/drm_blend.o > >> drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’: > >> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to function > >> ‘drm_get_format_name’ > >> drm_get_format_name(fb->pixel_format)); > >> ^~~ > >> In file included from ./include/drm/drmP.h:71:0, > >> from drivers/gpu/drm/drm_atomic.c:29: > >> ./include/drm/drm_fourcc.h:65:7: note: declared here > >> char *drm_get_format_name(uint32_t format, struct drm_format_name_buf > >> *buf); > >>^~~ > >> > >> Can you pls rebase onto drm-misc or linux-next or something? > > > > That was based on airlied/drm-next (last fetched on Sunday I think), > > I can rebase it on drm-misc if it helps, but it seems older than > > drm-next. > > Should I just rebase on top of current head of drm-next? > > It needs to be drm-misc (linux-next doesn't have it yet) due to the > new atomic debug work that we just landed. I'm working on drm-tip as a > drm local integration tree to ease pains like these a bit, but that > doesn't really exist yet. I'm confused as to how the different trees and branches merge back to Torvalds' tree (I'm interested in particular in drm), and I'm not sure which branch you want me to rebase on in the drm-misc tree [1], especially since all of them are older than drm-next [2]. I'll try to rebase on drm-misc-fixes (currently at 4da5caa6a6f82cda3193) as it sounds about right, but it doesn't apply at all, so it'll take a little while. Could you give me a quick explanation or point me to a doc/page that explains how the various trees and branches get merged? I googled a bit and found this doc [4] by Jani, but it doesn't mention drm-misc for instance, so I'm not sure how up-to-date and non-intel-specific it is. Looking at this page, something just occurred to me: did you mean drm-fixes [3], instead of one of the branches on drm-misc? Cheers, Eric [1] git://anongit.freedesktop.org/drm/drm-misc [2] git://people.freedesktop.org/~airlied/linux drm-next [2] git://people.freedesktop.org/~airlied/linux drm-fixes [3] https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-intel.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Trim the object sg table (rev2)
== Series Details == Series: drm/i915: Trim the object sg table (rev2) URL : https://patchwork.freedesktop.org/series/15036/ State : warning == Summary == Series 15036v2 drm/i915: Trim the object sg table https://patchwork.freedesktop.org/api/1.0/series/15036/revisions/2/mbox/ Test drv_module_reload_basic: pass -> DMESG-WARN (fi-bsw-n3050) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:203 dwarn:1 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 74d13d4fab710f664d5eeb15fd3de821a7f46818 drm-intel-nightly: 2016y-11m-09d-15h-02m-46s UTC integration manifest 2af81e6 drm/i915: Trim the object sg table == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2944/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH igt v3 01/11] igt/perf: add i915 perf stream tests for Haswell
On Wed, Nov 09, 2016 at 04:15:52PM +, Robert Bragg wrote:
> +static void
> +test_i915_ref_count(void)
> +{
> +int oa_exponent = 13; /* 1 millisecond */
> +uint64_t properties[] = {
> +/* Include OA reports in samples */
> +DRM_I915_PERF_PROP_SAMPLE_OA, true,
> +
> +/* OA unit configuration */
> +DRM_I915_PERF_PROP_OA_METRICS_SET, hsw_render_basic_id,
> +DRM_I915_PERF_PROP_OA_FORMAT, I915_OA_FORMAT_A45_B8_C8,
> +DRM_I915_PERF_PROP_OA_EXPONENT, oa_exponent,
> +};
> +struct drm_i915_perf_open_param param = {
> +.flags = I915_PERF_FLAG_FD_CLOEXEC,
> +.num_properties = sizeof(properties) / 16,
> +.properties_ptr = (uint64_t)properties,
> +};
> +unsigned baseline, ref_count0, ref_count1;
> +int stream_fd;
> +uint32_t oa_report0[64];
> +uint32_t oa_report1[64];
> +
> +close(drm_fd);
> +baseline = read_i915_module_ref();
> +igt_debug("baseline ref count (drm fd closed) = %u\n", baseline);
> +
> +drm_fd = drm_open_driver_render(DRIVER_INTEL);
Write this as a standalone (or first before igt_fixture) test and use
__drm_open_driver() (or export __drm_open_driver_render() if you insist)
so that we know that the extra driver ref taken by igt is not fouling up
your results..
> +ref_count0 = read_i915_module_ref();
> +igt_debug("initial ref count with drm_fd open = %u\n", ref_count0);
> +igt_assert(ref_count0 > baseline);
> +
> +stream_fd = __perf_open(drm_fd, ¶m);
> +ref_count1 = read_i915_module_ref();
> +igt_debug("ref count after opening i915 perf stream = %u\n",
> ref_count1);
> +igt_assert(ref_count1 > ref_count0);
> +
> +close(drm_fd);
> +ref_count0 = read_i915_module_ref();
> +igt_debug("ref count after closing drm fd = %u\n", ref_count0);
> +
> +igt_assert(ref_count0 > baseline);
> +
> +read_2_oa_reports(stream_fd,
> + I915_OA_FORMAT_A45_B8_C8, 256,
> + oa_exponent,
> + oa_report0,
> + oa_report1,
> + false); /* not just timer reports */
> +
> +close(stream_fd);
> +ref_count0 = read_i915_module_ref();
> +igt_debug("ref count after closing i915 perf stream fd = %u\n",
> ref_count0);
> +igt_assert_eq(ref_count0, baseline);
> +
> +drm_fd = drm_open_driver_render(DRIVER_INTEL);
> +}
--
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: warning for drm/i915: Add a per-pipe plane identifier enum (rev4)
== Series Details == Series: drm/i915: Add a per-pipe plane identifier enum (rev4) URL : https://patchwork.freedesktop.org/series/14978/ State : warning == Summary == Series 14978v4 drm/i915: Add a per-pipe plane identifier enum https://patchwork.freedesktop.org/api/1.0/series/14978/revisions/4/mbox/ Test drv_module_reload_basic: pass -> DMESG-WARN (fi-skl-6770hq) Test kms_force_connector_basic: Subgroup force-connector-state: pass -> SKIP (fi-ivb-3520m) Subgroup force-edid: pass -> SKIP (fi-ivb-3520m) Subgroup force-load-detect: pass -> SKIP (fi-ivb-3520m) Subgroup prune-stale-modes: pass -> SKIP (fi-ivb-3520m) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:218 dwarn:0 dfail:0 fail:0 skip:26 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-skl-6770hqtotal:244 pass:229 dwarn:1 dfail:0 fail:0 skip:14 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 74d13d4fab710f664d5eeb15fd3de821a7f46818 drm-intel-nightly: 2016y-11m-09d-15h-02m-46s UTC integration manifest e7fdae4 drm/i915: Don't populate plane->plane for cursors and sprites 776f170 drm/i915: Rename the local 'plane' variable to 'plane_id' in primary plane code 8a691eb drm/i915: Use enum plane_id in VLV/CHV wm code daca75f drm/i915: Use enum plane_id in VLV/CHV sprite code 2fc5a0b drm/i915: Use enum plane_id in SKL plane code 698ce5d drm/i915: Use enum plane_id in SKL wm code e6a137a drm/i915: Add crtc->plane_ids_mask e37903b drm/i915: Add per-pipe plane identifier caadefb drm/i915: Remove some duplicated plane swapping logic == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2943/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt v3 10/11] igt/gem_exec_parse: update registers test for v >= 8
This combines some parts of the recently added store_lri test with the
registers test to be able to first load a distinguishable value before
the LRI and explicitly read back the register to determine if the
command succeeded or was a NOOP.
For now though we won't look at OACONTROL without checking for version 9
of the command parser.
This updates the 'bad' test to check the OASTATUS2 register so that we
can explicitly read back from the register to check it becomes a NOOP.
This adds a struct test_lri for associating a mask with the init/test
values so we ignore things like hw status bits that might interfere
with the result.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 86 ++
1 file changed, 45 insertions(+), 41 deletions(-)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index f241ab7..0fa3af8 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -37,6 +37,7 @@
#define ARRAY_LEN(A) (sizeof(A) / sizeof(A[0]))
#define DERRMR 0x44050
+#define OASTATUS2 0x2368
#define OACONTROL 0x2360
#define SO_WRITE_OFFSET_0 0x5280
@@ -250,27 +251,35 @@ static void exec_batch_chained(int fd, uint32_t cmd_bo,
uint32_t *cmds,
gem_close(fd, target_bo);
}
-static void stray_lri(int fd, uint32_t handle)
+/* Be careful to take into account what register bits we can store and read
+ * from...
+ */
+struct test_lri {
+ uint32_t reg, read_mask, init_val, test_val;
+};
+
+static void
+test_lri(int fd, uint32_t handle,
+struct test_lri *test, int expected_errno, uint32_t expect)
{
- /* Ideally this would test all once whitelisted registers */
uint32_t lri[] = {
MI_LOAD_REGISTER_IMM,
- OACONTROL,
- 0x31337000,
+ test->reg,
+ test->test_val,
MI_BATCH_BUFFER_END,
};
- int err;
-
- igt_assert_eq_u32(intel_register_read(OACONTROL), 0xdeadbeef);
- err = __exec_batch(fd, handle, lri, sizeof(lri), I915_EXEC_RENDER);
- if (err == -EINVAL)
- return;
+ intel_register_write(test->reg, test->init_val);
- igt_assert_eq(err, 0);
+ exec_batch(fd, handle,
+ lri, sizeof(lri),
+ I915_EXEC_RENDER,
+ expected_errno);
gem_sync(fd, handle);
- igt_assert_eq_u32(intel_register_read(OACONTROL), 0xdeadbeef);
+ igt_assert_eq_u32((intel_register_read(test->reg) &
+ test->read_mask),
+ expect);
}
static void hsw_load_register_reg(void)
@@ -441,43 +450,38 @@ igt_main
igt_subtest_group {
igt_fixture {
intel_register_access_init(intel_get_pci_device(), 0);
-
- intel_register_write(OACONTROL, 0xdeadbeef);
- igt_assert_eq_u32(intel_register_read(OACONTROL),
0xdeadbeef);
}
- igt_subtest("basic-stray-lri")
- stray_lri(fd, handle);
+ igt_subtest("registers") {
+ struct test_lri bad_lris[] = {
+ /* dummy head pointer */
+ { OASTATUS2, 0xff80, 0xdeadf000, 0xbeeff000
}
+ };
+ struct test_lri ok_lris[] = {
+ /* NB: [1:0] MBZ */
+ { SO_WRITE_OFFSET_0, 0xfffc,
+ 0xabcdabc0, 0xbeefbee0 }
+ };
+ int bad_lri_errno = parser_version >= 8 ? 0 : -EINVAL;
+
+ for (int i = 0; i < ARRAY_LEN(ok_lris); i++) {
+ test_lri(fd, handle,
+ok_lris + i, 0,
+ok_lris[i].test_val);
+ }
+
+ for (int i = 0; i < ARRAY_LEN(bad_lris); i++) {
+ test_lri(fd, handle,
+bad_lris + i, bad_lri_errno,
+bad_lris[i].init_val);
+ }
+ }
igt_fixture {
- intel_register_write(OACONTROL, 0);
intel_register_access_fini();
}
}
- igt_subtest("registers") {
- uint32_t lri_bad[] = {
- MI_LOAD_REGISTER_IMM,
- 0, /* disallowed register address */
- 0x1200,
- MI_BATCH_BUFFER_END,
- };
- uint32_t lri_ok[] = {
- MI_LOAD_REGISTER_IMM,
- 0x5280, /* allowed register address
(SO_WRITE_OFFSET[0]) */
- 0x1,
- MI_BATCH_BUFFER_END,
- };
- ex
[Intel-gfx] [PATCH igt v3 09/11] igt/gem_exec_parse: update hsw_load_register_reg for v >= 8
This updates the checking of disallowed loads to set a distinguishable
value before the load and explicitly check the load was a NOOP by
reading back the final value.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index d6a2885..f241ab7 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -305,12 +305,17 @@ static void hsw_load_register_reg(void)
};
int fd;
uint32_t handle;
+ int parser_version;
+ int bad_lrr_errno;
/* Open again to get a non-master file descriptor */
fd = drm_open_driver(DRIVER_INTEL);
+ parser_version = command_parser_version(fd);
+ bad_lrr_errno = parser_version >= 8 ? 0 : -EINVAL;
+
igt_require(IS_HASWELL(intel_get_drm_devid(fd)));
- igt_require(command_parser_version(fd) >= 7);
+ igt_require(parser_version >= 7);
handle = gem_create(fd, 4096);
@@ -335,10 +340,21 @@ static void hsw_load_register_reg(void)
}
for (int i = 0 ; i < ARRAY_LEN(disallowed_regs); i++) {
+ exec_batch(fd, handle, init_gpr0, sizeof(init_gpr0),
+ I915_EXEC_RENDER,
+ 0);
+ exec_batch_patched(fd, handle,
+ store_gpr0, sizeof(store_gpr0),
+ 2 * sizeof(uint32_t), /* reloc */
+ 0xabcdabc0);
do_lrr[1] = disallowed_regs[i];
exec_batch(fd, handle, do_lrr, sizeof(do_lrr),
I915_EXEC_RENDER,
- -EINVAL);
+ bad_lrr_errno);
+ exec_batch_patched(fd, handle,
+ store_gpr0, sizeof(store_gpr0),
+ 2 * sizeof(uint32_t), /* reloc */
+ 0xabcdabc0);
}
close(fd);
--
2.10.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt v3 11/11] igt/gem_exec_parse: check oacontrol lri bad for >= v9
OACONTROL is no longer white listed in the command parser so this checks
at attempted LRI will be disallowed and (more importantly) checks that
userspace doesn't get an EINVAL error for an attempted OACONTROL LRI.
This is important becase Mesa application attempt OACONTROL LRIs while
initializing and will abort for any execbuf error.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 0fa3af8..702b6f4 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -457,6 +457,22 @@ igt_main
/* dummy head pointer */
{ OASTATUS2, 0xff80, 0xdeadf000, 0xbeeff000
}
};
+ struct test_lri v9_bad_lris[] = {
+ /* It's really important for us to check that
+* an LRI to OACONTROL doesn't result in an
+* EINVAL error because Mesa attempts writing
+* to OACONTROL to determine what extensions to
+* expose and will abort() for execbuffer()
+* errors.
+*
+* Mesa can gracefully recognise and handle the
+* LRI becoming a NOOP.
+*
+* The test values represent dummy context IDs
+* while leaving the OA unit disabled
+*/
+ { OACONTROL, 0xf000, 0xfeed, 0x31337000
}
+ };
struct test_lri ok_lris[] = {
/* NB: [1:0] MBZ */
{ SO_WRITE_OFFSET_0, 0xfffc,
@@ -475,6 +491,15 @@ igt_main
bad_lris + i, bad_lri_errno,
bad_lris[i].init_val);
}
+
+ if (parser_version >= 9) {
+ for (int i = 0; i < ARRAY_LEN(v9_bad_lris);
i++) {
+ test_lri(fd, handle,
+v9_bad_lris + i,
+0,
+v9_bad_lris[i].init_val);
+ }
+ }
}
igt_fixture {
--
2.10.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt v3 08/11] igt/gem_exec_parse: update cmd-crossing-page for >= v8
Since an access violation won't return an error to userspace for v >= 8
of the command parser this updates the cmd-crossing-page test to
explicitly read back from SO_WRITE_OFFSET[0] to see that the command
wasn't squashed to a NOOP.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 1aa5114..d6a2885 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -499,14 +499,25 @@ igt_main
igt_subtest("cmd-crossing-page") {
uint32_t lri_ok[] = {
MI_LOAD_REGISTER_IMM,
- 0x5280, /* allowed register address
(SO_WRITE_OFFSET[0]) */
- 0x1,
+ SO_WRITE_OFFSET_0, /* allowed register address */
+ 0xdcbaabc0, /* [1:0] MBZ */
+ MI_BATCH_BUFFER_END,
+ };
+ uint32_t store_reg[] = {
+ MI_STORE_REGISTER_MEM | (3 - 2),
+ SO_WRITE_OFFSET_0,
+ 0, /* reloc */
MI_BATCH_BUFFER_END,
};
exec_split_batch(fd,
lri_ok, sizeof(lri_ok),
I915_EXEC_RENDER,
0);
+ exec_batch_patched(fd, handle,
+ store_reg,
+ sizeof(store_reg),
+ 2 * sizeof(uint32_t), /* reloc */
+ 0xdcbaabc0);
}
igt_subtest("oacontrol-tracking") {
--
2.10.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt v3 07/11] igt/gem_exec_parse: update bitmasks test for v >=8
With v8 of the command parser (where we won't get an EINVAL for an
access violation) this updates the bitmasks test to explicitly confirm
that the command became a NOOP by reading back from where the QW_WRITE
would have otherwise landed.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 63f4efe..1aa5114 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -472,10 +472,20 @@ igt_main
0,
MI_BATCH_BUFFER_END,
};
- exec_batch(fd, handle,
- pc, sizeof(pc),
- I915_EXEC_RENDER,
- -EINVAL);
+ if (parser_version >= 8) {
+ /* Expect to read back zero since the command should be
+* squashed to a NOOP
+*/
+ exec_batch_patched(fd, handle,
+ pc, sizeof(pc),
+ 8, /* patch offset, */
+ 0x0);
+ } else {
+ exec_batch(fd, handle,
+ pc, sizeof(pc),
+ I915_EXEC_RENDER,
+ -EINVAL);
+ }
}
igt_subtest("batch-without-end") {
--
2.10.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt v3 06/11] igt/gem_exec_parse: make basic-rejected version agnostic
This adapts the basic-rejected test to focus on invalid commands that
will result in an EINVAL errno being returned to userspace even with the
upcoming version 8 parser change to stop reporting access violations as
EINVAL errors.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 368f30b..63f4efe 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -386,33 +386,39 @@ igt_main
}
igt_subtest("basic-rejected") {
- uint32_t arb_on_off[] = {
- MI_ARB_ON_OFF,
+ uint32_t invalid_cmd[] = {
+ (0x7<<29), /* Reserved command type,
+ across all engines */
MI_BATCH_BUFFER_END,
};
- uint32_t display_flip[] = {
- MI_DISPLAY_FLIP,
- 0, 0, 0,
+ uint32_t invalid_set_context[] = {
+ MI_SET_CONTEXT | 32, /* invalid length */
MI_BATCH_BUFFER_END,
- 0
};
exec_batch(fd, handle,
- arb_on_off, sizeof(arb_on_off),
+ invalid_cmd, sizeof(invalid_cmd),
I915_EXEC_RENDER,
-EINVAL);
exec_batch(fd, handle,
- arb_on_off, sizeof(arb_on_off),
+ invalid_cmd, sizeof(invalid_cmd),
I915_EXEC_BSD,
-EINVAL);
+ if (gem_has_blt(fd)) {
+ exec_batch(fd, handle,
+ invalid_cmd, sizeof(invalid_cmd),
+ I915_EXEC_BLT,
+ -EINVAL);
+ }
if (gem_has_vebox(fd)) {
exec_batch(fd, handle,
- arb_on_off, sizeof(arb_on_off),
+ invalid_cmd, sizeof(invalid_cmd),
I915_EXEC_VEBOX,
-EINVAL);
}
+
exec_batch(fd, handle,
- display_flip, sizeof(display_flip),
- I915_EXEC_BLT,
+ invalid_set_context, sizeof(invalid_set_context),
+ I915_EXEC_RENDER,
-EINVAL);
}
--
2.10.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt v3 03/11] igt/gem_exec_parse: move hsw_load_register_reg down
No functional change, just moving hsw_load_regster_reg test code down
below the execbuf utilities in preparation for updating to use them.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 182 -
1 file changed, 91 insertions(+), 91 deletions(-)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 72d7c7b..c530bb6 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -65,97 +65,6 @@ static int command_parser_version(int fd)
return -1;
}
-static void hsw_load_register_reg(void)
-{
- uint32_t buf[16] = {
- MI_LOAD_REGISTER_IMM | (5 - 2),
- HSW_CS_GPR0,
- 0xabcdabcd,
- HSW_CS_GPR1,
- 0xdeadbeef,
-
- MI_STORE_REGISTER_MEM | (3 - 2),
- HSW_CS_GPR1,
- 0, /* address0 */
-
- MI_LOAD_REGISTER_REG | (3 - 2),
- HSW_CS_GPR0,
- HSW_CS_GPR1,
-
- MI_STORE_REGISTER_MEM | (3 - 2),
- HSW_CS_GPR1,
- 4, /* address1 */
-
- MI_BATCH_BUFFER_END,
- };
- struct drm_i915_gem_execbuffer2 execbuf;
- struct drm_i915_gem_exec_object2 obj[2];
- struct drm_i915_gem_relocation_entry reloc[2];
- int fd;
-
- /* Open again to get a non-master file descriptor */
- fd = drm_open_driver(DRIVER_INTEL);
-
- igt_require(IS_HASWELL(intel_get_drm_devid(fd)));
- igt_require(command_parser_version(fd) >= 7);
-
- memset(obj, 0, sizeof(obj));
- obj[0].handle = gem_create(fd, 4096);
- obj[1].handle = gem_create(fd, 4096);
- gem_write(fd, obj[1].handle, 0, buf, sizeof(buf));
-
- memset(reloc, 0, sizeof(reloc));
- reloc[0].offset = 7*sizeof(uint32_t);
- reloc[0].target_handle = obj[0].handle;
- reloc[0].delta = 0;
- reloc[0].read_domains = I915_GEM_DOMAIN_COMMAND;
- reloc[0].write_domain = I915_GEM_DOMAIN_COMMAND;
- reloc[1].offset = 13*sizeof(uint32_t);
- reloc[1].target_handle = obj[0].handle;
- reloc[1].delta = sizeof(uint32_t);
- reloc[1].read_domains = I915_GEM_DOMAIN_COMMAND;
- reloc[1].write_domain = I915_GEM_DOMAIN_COMMAND;
- obj[1].relocs_ptr = (uintptr_t)&reloc;
- obj[1].relocation_count = 2;
-
- memset(&execbuf, 0, sizeof(execbuf));
- execbuf.buffers_ptr = (uintptr_t)obj;
- execbuf.buffer_count = 2;
- execbuf.batch_len = sizeof(buf);
- execbuf.flags = I915_EXEC_RENDER;
- gem_execbuf(fd, &execbuf);
- gem_close(fd, obj[1].handle);
-
- gem_read(fd, obj[0].handle, 0, buf, 2*sizeof(buf[0]));
- igt_assert_eq_u32(buf[0], 0xdeadbeef); /* before copy */
- igt_assert_eq_u32(buf[1], 0xabcdabcd); /* after copy */
-
- /* Now a couple of negative tests that should be filtered */
- execbuf.buffer_count = 1;
- execbuf.batch_len = 4*sizeof(buf[0]);
-
- buf[0] = MI_LOAD_REGISTER_REG | (3 - 2);
- buf[1] = HSW_CS_GPR0;
- buf[2] = 0;
- buf[3] = MI_BATCH_BUFFER_END;
- gem_write(fd, obj[0].handle, 0, buf, execbuf.batch_len);
- igt_assert_eq(__gem_execbuf(fd, &execbuf), -EINVAL);
-
- buf[2] = OACONTROL; /* filtered */
- gem_write(fd, obj[0].handle, 0, buf, execbuf.batch_len);
- igt_assert_eq(__gem_execbuf(fd, &execbuf), -EINVAL);
-
- buf[2] = DERRMR; /* master only */
- gem_write(fd, obj[0].handle, 0, buf, execbuf.batch_len);
- igt_assert_eq(__gem_execbuf(fd, &execbuf), -EINVAL);
-
- buf[2] = 0x2038; /* RING_START: invalid */
- gem_write(fd, obj[0].handle, 0, buf, execbuf.batch_len);
- igt_assert_eq(__gem_execbuf(fd, &execbuf), -EINVAL);
-
- close(fd);
-}
-
static void exec_batch_patched(int fd, uint32_t cmd_bo, uint32_t *cmds,
int size, int patch_offset, uint64_t
expected_value)
{
@@ -351,6 +260,97 @@ static void stray_lri(int fd, uint32_t handle)
igt_assert_eq_u32(intel_register_read(OACONTROL), 0xdeadbeef);
}
+static void hsw_load_register_reg(void)
+{
+ uint32_t buf[16] = {
+ MI_LOAD_REGISTER_IMM | (5 - 2),
+ HSW_CS_GPR0,
+ 0xabcdabcd,
+ HSW_CS_GPR1,
+ 0xdeadbeef,
+
+ MI_STORE_REGISTER_MEM | (3 - 2),
+ HSW_CS_GPR1,
+ 0, /* address0 */
+
+ MI_LOAD_REGISTER_REG | (3 - 2),
+ HSW_CS_GPR0,
+ HSW_CS_GPR1,
+
+ MI_STORE_REGISTER_MEM | (3 - 2),
+ HSW_CS_GPR1,
+ 4, /* address1 */
+
+ MI_BATCH_BUFFER_END,
+ };
+ struct drm_i915_gem_execbuffer2 execbuf;
+ struct drm_i915_gem_exec_object2 obj[2];
+ struct drm_i915_gem_relocation_entry reloc[2];
+ int fd;
+
+ /* Open again to get a non-master file descriptor */
+ fd = drm_open_driver(DRIVER_INTEL);
+
[Intel-gfx] [PATCH igt v3 04/11] igt/gem_exec_parse: update hsw_load_register_reg
This generalises hsw_load_register_reg to loop through an array of
allowed and disallowed registers and to use the exec_batch[_patched]
utilities.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 139 +++--
1 file changed, 66 insertions(+), 73 deletions(-)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index c530bb6..2fea060 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -34,8 +34,11 @@
#define I915_PARAM_CMD_PARSER_VERSION 28
#endif
-#define OACONTROL 0x2360
+#define ARRAY_LEN(A) (sizeof(A) / sizeof(A[0]))
+
#define DERRMR 0x44050
+#define OACONTROL 0x2360
+#define SO_WRITE_OFFSET_0 0x5280
#define HSW_CS_GPR(n) (0x2600 + 8*(n))
#define HSW_CS_GPR0 HSW_CS_GPR(0)
@@ -65,8 +68,8 @@ static int command_parser_version(int fd)
return -1;
}
-static void exec_batch_patched(int fd, uint32_t cmd_bo, uint32_t *cmds,
- int size, int patch_offset, uint64_t
expected_value)
+static uint64_t __exec_batch_patched(int fd, uint32_t cmd_bo, uint32_t *cmds,
+int size, int patch_offset)
{
struct drm_i915_gem_execbuffer2 execbuf;
struct drm_i915_gem_exec_object2 obj[2];
@@ -100,9 +103,19 @@ static void exec_batch_patched(int fd, uint32_t cmd_bo,
uint32_t *cmds,
gem_sync(fd, cmd_bo);
gem_read(fd,target_bo, 0, &actual_value, sizeof(actual_value));
- igt_assert_eq(expected_value, actual_value);
gem_close(fd, target_bo);
+
+ return actual_value;
+}
+
+static void exec_batch_patched(int fd, uint32_t cmd_bo, uint32_t *cmds,
+ int size, int patch_offset,
+ uint64_t expected_value)
+{
+ igt_assert_eq(__exec_batch_patched(fd, cmd_bo, cmds,
+ size, patch_offset),
+ expected_value);
}
static int __exec_batch(int fd, uint32_t cmd_bo, uint32_t *cmds,
@@ -262,31 +275,36 @@ static void stray_lri(int fd, uint32_t handle)
static void hsw_load_register_reg(void)
{
- uint32_t buf[16] = {
- MI_LOAD_REGISTER_IMM | (5 - 2),
+ uint32_t init_gpr0[16] = {
+ MI_LOAD_REGISTER_IMM | (3 - 2),
HSW_CS_GPR0,
- 0xabcdabcd,
- HSW_CS_GPR1,
- 0xdeadbeef,
-
+ 0xabcdabc0, /* leave [1:0] zero */
+ MI_BATCH_BUFFER_END,
+ };
+ uint32_t store_gpr0[16] = {
MI_STORE_REGISTER_MEM | (3 - 2),
- HSW_CS_GPR1,
- 0, /* address0 */
-
- MI_LOAD_REGISTER_REG | (3 - 2),
HSW_CS_GPR0,
- HSW_CS_GPR1,
-
- MI_STORE_REGISTER_MEM | (3 - 2),
- HSW_CS_GPR1,
- 4, /* address1 */
-
+ 0, /* reloc*/
MI_BATCH_BUFFER_END,
};
- struct drm_i915_gem_execbuffer2 execbuf;
- struct drm_i915_gem_exec_object2 obj[2];
- struct drm_i915_gem_relocation_entry reloc[2];
+ uint32_t do_lrr[16] = {
+ MI_LOAD_REGISTER_REG | (3 - 2),
+ 0, /* [1] = src */
+ HSW_CS_GPR0, /* dst */
+ MI_BATCH_BUFFER_END,
+ };
+ uint32_t allowed_regs[] = {
+ HSW_CS_GPR1,
+ SO_WRITE_OFFSET_0,
+ };
+ uint32_t disallowed_regs[] = {
+ 0,
+ OACONTROL, /* filtered */
+ DERRMR, /* master only */
+ 0x2038, /* RING_START: invalid */
+ };
int fd;
+ uint32_t handle;
/* Open again to get a non-master file descriptor */
fd = drm_open_driver(DRIVER_INTEL);
@@ -294,59 +312,34 @@ static void hsw_load_register_reg(void)
igt_require(IS_HASWELL(intel_get_drm_devid(fd)));
igt_require(command_parser_version(fd) >= 7);
- memset(obj, 0, sizeof(obj));
- obj[0].handle = gem_create(fd, 4096);
- obj[1].handle = gem_create(fd, 4096);
- gem_write(fd, obj[1].handle, 0, buf, sizeof(buf));
-
- memset(reloc, 0, sizeof(reloc));
- reloc[0].offset = 7*sizeof(uint32_t);
- reloc[0].target_handle = obj[0].handle;
- reloc[0].delta = 0;
- reloc[0].read_domains = I915_GEM_DOMAIN_COMMAND;
- reloc[0].write_domain = I915_GEM_DOMAIN_COMMAND;
- reloc[1].offset = 13*sizeof(uint32_t);
- reloc[1].target_handle = obj[0].handle;
- reloc[1].delta = sizeof(uint32_t);
- reloc[1].read_domains = I915_GEM_DOMAIN_COMMAND;
- reloc[1].write_domain = I915_GEM_DOMAIN_COMMAND;
- obj[1].relocs_ptr = (uintptr_t)&reloc;
- obj[1].relocation_count = 2;
+ handle = gem_create(fd, 4096);
- memset(&execbuf, 0, sizeof(execbuf));
- execbuf.buffers_ptr = (uintptr_t)obj;
- execbuf.buffer_count = 2;
- execbuf.batch_len = sizeof(buf);
- execbuf.flags = I915_EXEC_RENDER;
[Intel-gfx] [PATCH igt v3 05/11] igt/gem_exec_parse: req. v < 9 for oacontrol tracking test
This limits testing the oacontrol tracking (required pairing of oa
enable/disable per batch buffer) to version <= 8 of the command parser.
Version 9 of the command parser removes all special handling for
OACONTROL which is now going to be managed by i915-perf and not
programmed from userspace.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index 2fea060..368f30b 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -349,8 +349,9 @@ static int fd;
igt_main
{
+ int parser_version = 0;
+
igt_fixture {
- int parser_version = 0;
drm_i915_getparam_t gp;
int rc;
@@ -521,6 +522,9 @@ igt_main
0x31337000,
MI_BATCH_BUFFER_END,
};
+
+ igt_require(parser_version < 9);
+
exec_batch(fd, handle,
lri_ok, sizeof(lri_ok),
I915_EXEC_RENDER,
--
2.10.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt v3 01/11] igt/perf: add i915 perf stream tests for Haswell
Signed-off-by: Robert Bragg
---
tests/Makefile.sources |1 +
tests/perf.c | 2220
2 files changed, 2221 insertions(+)
create mode 100644 tests/perf.c
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 6d081c3..7c6de2f 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -211,6 +211,7 @@ TESTS_progs = \
kms_pwrite_crc \
kms_sink_crc_basic \
prime_udl \
+ perf \
$(NULL)
# IMPORTANT: The ZZ_ tests need to be run last!
diff --git a/tests/perf.c b/tests/perf.c
new file mode 100644
index 000..4762e36
--- /dev/null
+++ b/tests/perf.c
@@ -0,0 +1,2220 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * 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.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "igt.h"
+#include "drm.h"
+
+IGT_TEST_DESCRIPTION("Test the i915 perf metrics streaming interface");
+
+#define GEN6_MI_REPORT_PERF_COUNT ((0x28 << 23) | (3 - 2))
+
+#define GFX_OP_PIPE_CONTROL ((3 << 29) | (3 << 27) | (2 << 24))
+#define PIPE_CONTROL_CS_STALL (1 << 20)
+#define PIPE_CONTROL_GLOBAL_SNAPSHOT_COUNT_RESET(1 << 19)
+#define PIPE_CONTROL_TLB_INVALIDATE (1 << 18)
+#define PIPE_CONTROL_SYNC_GFDT (1 << 17)
+#define PIPE_CONTROL_MEDIA_STATE_CLEAR (1 << 16)
+#define PIPE_CONTROL_NO_WRITE (0 << 14)
+#define PIPE_CONTROL_WRITE_IMMEDIATE(1 << 14)
+#define PIPE_CONTROL_WRITE_DEPTH_COUNT (2 << 14)
+#define PIPE_CONTROL_WRITE_TIMESTAMP(3 << 14)
+#define PIPE_CONTROL_DEPTH_STALL(1 << 13)
+#define PIPE_CONTROL_RENDER_TARGET_FLUSH (1 << 12)
+#define PIPE_CONTROL_INSTRUCTION_INVALIDATE (1 << 11)
+#define PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE (1 << 10) /* GM45+ only */
+#define PIPE_CONTROL_ISP_DIS(1 << 9)
+#define PIPE_CONTROL_INTERRUPT_ENABLE (1 << 8)
+#define PIPE_CONTROL_FLUSH_ENABLE (1 << 7) /* Gen7+ only */
+/* GT */
+#define PIPE_CONTROL_DATA_CACHE_INVALIDATE (1 << 5)
+#define PIPE_CONTROL_VF_CACHE_INVALIDATE(1 << 4)
+#define PIPE_CONTROL_CONST_CACHE_INVALIDATE (1 << 3)
+#define PIPE_CONTROL_STATE_CACHE_INVALIDATE (1 << 2)
+#define PIPE_CONTROL_STALL_AT_SCOREBOARD(1 << 1)
+#define PIPE_CONTROL_DEPTH_CACHE_FLUSH (1 << 0)
+#define PIPE_CONTROL_PPGTT_WRITE(0 << 2)
+#define PIPE_CONTROL_GLOBAL_GTT_WRITE (1 << 2)
+
+#define NSEC_PER_SEC 10ull
+
+static struct {
+const char *name;
+uint64_t id;
+size_t size;
+int a_off; /* bytes */
+int n_a;
+int first_a;
+int b_off;
+int n_b;
+int c_off;
+int n_c;
+} hsw_oa_formats[] = {
+{ "A13", I915_OA_FORMAT_A13, .size = 64,
+.a_off = 12, .n_a = 13 },
+{ "A29", I915_OA_FORMAT_A29, .size = 128,
+.a_off = 12, .n_a = 29 },
+{ "A13_B8_C8", I915_OA_FORMAT_A13_B8_C8, .size = 128,
+.a_off = 12, .n_a = 13,
+.b_off = 64, .n_b = 8,
+.c_off = 96, .n_c = 8 },
+{ "A45_B8_C8", I915_OA_FORMAT_A45_B8_C8, .size = 256,
+.a_off = 12, .n_a = 45,
+.b_off = 192, .n_b = 8,
+.c_off = 224, .n_c = 8 },
+{ "B4_C8", I915_OA_FORMAT_B4_C8, .size = 64,
+.b_off = 16, .n_b = 4,
+.c_off = 32, .n_c = 8 },
+{ "B4_C8_A16", I915_OA_FORMAT_B4_C8_A16, .size = 128,
+.b_off = 16, .n_b = 4,
+.c_off = 32, .n_c = 8,
+.a_off = 60, .n_a = 16, .first_a = 29 },
+{ "C4_B8", I915_OA_FORMAT_C4_B8, .size = 64,
+.c_off = 16, .n_c = 4,
+.b_off = 28, .n_b = 8 },
+};
+
+static bool hsw_undefined_a_counters[45] = {
[Intel-gfx] [PATCH igt v3 02/11] igt/gem_exec_parse: some minor cleanups
This normalizes the execbuf utilities in this file to all use memset to
clear obj, reloc and execbuf structures and set them up in the same
order. As I was debugging some unpredictable test failures I was getting
unsure that all these structures were being fully initialized.
The same I915_GEM_DOMAIN_COMMAND domain is now used with all relocs.
The register/command defines have been moved to the top of the file to
be available to all tests/utilities.
The handle + fd variables are now static.
Signed-off-by: Robert Bragg
---
tests/gem_exec_parse.c | 196 +
1 file changed, 66 insertions(+), 130 deletions(-)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index a39db3e..72d7c7b 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_parse.c
@@ -37,6 +37,20 @@
#define OACONTROL 0x2360
#define DERRMR 0x44050
+#define HSW_CS_GPR(n) (0x2600 + 8*(n))
+#define HSW_CS_GPR0 HSW_CS_GPR(0)
+#define HSW_CS_GPR1 HSW_CS_GPR(1)
+
+#define MI_LOAD_REGISTER_REG (0x2a << 23)
+#define MI_STORE_REGISTER_MEM (0x24 << 23)
+#define MI_ARB_ON_OFF (0x8 << 23)
+#define MI_DISPLAY_FLIP ((0x14 << 23) | 1)
+
+#define GFX_OP_PIPE_CONTROL((0x3<<29)|(0x3<<27)|(0x2<<24)|2)
+#define PIPE_CONTROL_QW_WRITE(1<<14)
+#define PIPE_CONTROL_LRI_POST_OP (1<<23)
+
+
static int command_parser_version(int fd)
{
int version = -1;
@@ -51,12 +65,6 @@ static int command_parser_version(int fd)
return -1;
}
-#define HSW_CS_GPR(n) (0x2600 + 8*(n))
-#define HSW_CS_GPR0 HSW_CS_GPR(0)
-#define HSW_CS_GPR1 HSW_CS_GPR(1)
-
-#define MI_LOAD_REGISTER_REG (0x2a << 23)
-#define MI_STORE_REGISTER_MEM (0x24 << 23)
static void hsw_load_register_reg(void)
{
uint32_t buf[16] = {
@@ -100,13 +108,13 @@ static void hsw_load_register_reg(void)
reloc[0].offset = 7*sizeof(uint32_t);
reloc[0].target_handle = obj[0].handle;
reloc[0].delta = 0;
- reloc[0].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
- reloc[0].write_domain = I915_GEM_DOMAIN_INSTRUCTION;
+ reloc[0].read_domains = I915_GEM_DOMAIN_COMMAND;
+ reloc[0].write_domain = I915_GEM_DOMAIN_COMMAND;
reloc[1].offset = 13*sizeof(uint32_t);
reloc[1].target_handle = obj[0].handle;
reloc[1].delta = sizeof(uint32_t);
- reloc[1].read_domains = I915_GEM_DOMAIN_INSTRUCTION;
- reloc[1].write_domain = I915_GEM_DOMAIN_INSTRUCTION;
+ reloc[1].read_domains = I915_GEM_DOMAIN_COMMAND;
+ reloc[1].write_domain = I915_GEM_DOMAIN_COMMAND;
obj[1].relocs_ptr = (uintptr_t)&reloc;
obj[1].relocation_count = 2;
@@ -152,7 +160,7 @@ static void exec_batch_patched(int fd, uint32_t cmd_bo,
uint32_t *cmds,
int size, int patch_offset, uint64_t
expected_value)
{
struct drm_i915_gem_execbuffer2 execbuf;
- struct drm_i915_gem_exec_object2 objs[2];
+ struct drm_i915_gem_exec_object2 obj[2];
struct drm_i915_gem_relocation_entry reloc[1];
uint32_t target_bo = gem_create(fd, 4096);
@@ -160,42 +168,24 @@ static void exec_batch_patched(int fd, uint32_t cmd_bo,
uint32_t *cmds,
gem_write(fd, cmd_bo, 0, cmds, size);
+ memset(obj, 0, sizeof(obj));
+ obj[0].handle = target_bo;
+ obj[1].handle = cmd_bo;
+
+ memset(reloc, 0, sizeof(reloc));
reloc[0].offset = patch_offset;
+ reloc[0].target_handle = obj[0].handle;
reloc[0].delta = 0;
- reloc[0].target_handle = target_bo;
- reloc[0].read_domains = I915_GEM_DOMAIN_RENDER;
- reloc[0].write_domain = I915_GEM_DOMAIN_RENDER;
- reloc[0].presumed_offset = 0;
-
- objs[0].handle = target_bo;
- objs[0].relocation_count = 0;
- objs[0].relocs_ptr = 0;
- objs[0].alignment = 0;
- objs[0].offset = 0;
- objs[0].flags = 0;
- objs[0].rsvd1 = 0;
- objs[0].rsvd2 = 0;
-
- objs[1].handle = cmd_bo;
- objs[1].relocation_count = 1;
- objs[1].relocs_ptr = (uintptr_t)reloc;
- objs[1].alignment = 0;
- objs[1].offset = 0;
- objs[1].flags = 0;
- objs[1].rsvd1 = 0;
- objs[1].rsvd2 = 0;
-
- execbuf.buffers_ptr = (uintptr_t)objs;
+ reloc[0].read_domains = I915_GEM_DOMAIN_COMMAND;
+ reloc[0].write_domain = I915_GEM_DOMAIN_COMMAND;
+ obj[1].relocs_ptr = (uintptr_t)reloc;
+ obj[1].relocation_count = 1;
+
+ memset(&execbuf, 0, sizeof(execbuf));
+ execbuf.buffers_ptr = (uintptr_t)obj;
execbuf.buffer_count = 2;
- execbuf.batch_start_offset = 0;
execbuf.batch_len = size;
- execbuf.cliprects_ptr = 0;
- execbuf.num_cliprects = 0;
- execbuf.DR1 = 0;
- execbuf.DR4 = 0;
execbuf.flags = I915_EXEC_RENDER;
- i915_execbuffer2_set_context_id(execbuf, 0);
- execbuf.rsvd2 = 0;
gem_execbuf(fd, &execbuf);
gem_sync(fd, cmd_bo);
@@ -210,30 +200,18 @@ static int __exec_batch(int fd, uint3
[Intel-gfx] [PATCH igt v3 00/11] corresponding changes for i915-perf interface
The i915-perf series affects the command parser and itself includes new uapi which these i-g-t changes try to cover. As well as splitting up the gem_exec_parse changes this version maintains support for testing version 7 of the command parser. - Robert Robert Bragg (6): igt/perf: add i915 perf stream tests for Haswell igt/gem_exec_parse: remove oacontrol checks igt/gem_exec_parse: some minor cleanups igt/gem_exec_parse: move hsw_load_register_reg down igt/gem_exec_parse: update hsw_load_register_reg igt/gem_exec_parse: update for version 8 changes tests/Makefile.sources |1 + tests/gem_exec_parse.c | 519 +-- tests/perf.c | 2220 3 files changed, 2429 insertions(+), 311 deletions(-) create mode 100644 tests/perf.c -- 2.10.1 *** BLURB HERE *** Robert Bragg (11): igt/perf: add i915 perf stream tests for Haswell igt/gem_exec_parse: some minor cleanups igt/gem_exec_parse: move hsw_load_register_reg down igt/gem_exec_parse: update hsw_load_register_reg igt/gem_exec_parse: req. v < 9 for oacontrol tracking test igt/gem_exec_parse: make basic-rejected version agnostic igt/gem_exec_parse: update bitmasks test for v >=8 igt/gem_exec_parse: update cmd-crossing-page for >= v8 igt/gem_exec_parse: update hsw_load_register_reg for v >= 8 igt/gem_exec_parse: update registers test for v >= 8 igt/gem_exec_parse: check oacontrol lri bad for >= v9 tests/Makefile.sources |1 + tests/gem_exec_parse.c | 555 ++-- tests/perf.c | 2220 3 files changed, 2501 insertions(+), 275 deletions(-) create mode 100644 tests/perf.c -- 2.10.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC i-g-t 4/4] Add support for hotplug testing with the Chamelium
On 8 November 2016 at 01:05, Lyude wrote:
> For the purpose of testing things such as hotplugging and bad monitors,
> the ChromeOS team ended up designing a neat little device known as the
> Chamelium. More information on this can be found here:
>
> https://www.chromium.org/chromium-os/testing/chamelium
>
> This adds support for a couple of things to intel-gpu-tools:
> - igt library functions for connecting to udev and monitoring it for
>hotplug events, loosely based off of the unfinished hotplugging
>implementation in testdisplay
> - Library functions for controlling the chamelium in tests using
>xmlrpc. A couple of RPC calls were ommitted here, mainly because they
>didn't seem very useful for our needs or because they're just plain
>broken
> - A set of basic tests using the chamelium.
I think it would be good to split this patch in a few smaller bits,
each with its logical change.
> Because there's no surefire way that I know of where we can map which
> chamelium port belongs to which port on the system being tested (we
> could just use hotplugging, but then we'd be relying on something that
> might be broken on the machine and potentially give false positives for
> certain tests), most of the chamelium tests will figure out whether or
> not a connection happened by counting the number of connectors matching
> the status we're looking for before hotplugging with the chamelium, vs.
> after hotplugging it.
Back when I started work on this, it was agreed with Daniel Vetter
that a config file would be used for this mapping (and other
configuration). This is the $HOME/.igtrc I was using during
development:
[Chamelium]
server_ip=192.168.100.123
server_port=9992
port_names=HDMI
connector_names=HDMI-A-1
I used the keyfile API in glib, as we are already depending on it (and
that's also why I chose libsoup instead of libxmlrpc).
For reference, this is the WIP branch that I was using to test frame
CRC capture with Chamelium:
https://git.collabora.com/cgit/user/tomeu/intel-gpu-tools.git/commit/?h=chamelium-crc
Regards,
Tomeu
> Tests which require that we know which port belongs to a certain port
> (such as ones where we actually perform a modeset) will unplug all of
> the chamelium ports, plug the desired port, then use the first DRM
> connector with the desired connector type that's marked as connected. In
> order to ensure we don't end up using the wrong connector, these tests
> will skip if they find any connectors with the desired type marked as
> connected before performing the hotplug on the chamelium.
>
> Running these tests requires (of course) a working Chamelium, along with
> the RPC URL for the chamelium being specified in the environment
> variable CHAMELIUM_HOST. If no URL is specified, the tests will just
> skip on their own. As well, tests for connectors which are not actually
> present on the system or the chamelium will skip on their own as well.
>
> Signed-off-by: Lyude
> ---
> configure.ac | 13 +
> lib/Makefile.am| 10 +-
> lib/igt.h | 1 +
> lib/igt_chamelium.c| 628
> +
> lib/igt_chamelium.h| 77 ++
> lib/igt_kms.c | 107 +
> lib/igt_kms.h | 13 +-
> scripts/run-tests.sh | 4 +-
> tests/Makefile.am | 5 +-
> tests/Makefile.sources | 1 +
> tests/chamelium.c | 549 ++
> 11 files changed, 1403 insertions(+), 5 deletions(-)
> create mode 100644 lib/igt_chamelium.c
> create mode 100644 lib/igt_chamelium.h
> create mode 100644 tests/chamelium.c
>
> diff --git a/configure.ac b/configure.ac
> index 735cfd5..88113b2 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -259,6 +259,18 @@ if test "x$with_libunwind" = xyes; then
> AC_MSG_ERROR([libunwind not found. Use
> --without-libunwind to disable libunwind support.]))
> fi
>
> +# enable support for using the chamelium
> +AC_ARG_ENABLE(chamelium,
> + AS_HELP_STRING([--without-chamelium],
> +[Build tests without chamelium support]),
> + [], [with_chamelium=yes])
> +
> +AM_CONDITIONAL(HAVE_CHAMELIUM, [test "x$with_chamelium" = xyes])
> +if test "x$with_chamelium" = xyes; then
> + AC_DEFINE(HAVE_CHAMELIUM, 1, [chamelium suport])
> + PKG_CHECK_MODULES(XMLRPC, xmlrpc_client)
> +fi
> +
> # enable debug symbols
> AC_ARG_ENABLE(debug,
> AS_HELP_STRING([--disable-debug],
> @@ -356,6 +368,7 @@ echo " Assembler : ${enable_assembler}"
> echo " Debugger : ${enable_debugger}"
> echo " Overlay: X: ${enable_overlay_xlib}, Xv:
> ${enable_overlay_xvlib}"
> echo " x86-specific tools : ${build_x86}"
> +echo " Chamelium support : ${with_chamelium}"
> echo ""
> echo " • API-Documentation : ${enable_gtk_doc}"
> echo " • Fail on warnings : ${enable_werror}"
> diff -
Re: [Intel-gfx] [PATCH] drm/i915: Spin until breadcrumb threads are complete
On Wed, Nov 09, 2016 at 02:53:34PM +, Tvrtko Ursulin wrote: > Looks OK. Side note to myself - catch up on the rcu waiter business. > > Reviewed-by: Tvrtko Ursulin Ta, pushed to have one less wart. -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] [GIT PULL] kvm/page_track changes for i915 KVMGT
On 09/11/2016 16:15, Daniel Vetter wrote: > On Wed, Nov 09, 2016 at 03:25:19PM +0100, Paolo Bonzini wrote: >> Daniel, >> >> The following changes since commit d9092f52d7e61dd1557f2db2400ddb430e85937e: >> >> kvm: x86: Check memopp before dereference (CVE-2016-8630) (2016-11-02 >> 21:31:53 +0100) >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-kvmgt >> >> for you to fetch changes up to 871b7ef2a1850d0b435c8b324bf4a5d391adde3f: >> >> kvm/page_track: export symbols for external usage (2016-11-04 12:13:20 >> +0100) > > Pulled into drm-intel, thanks. Please also pull this into your kvm-next > tree to make sure we can land kvm/drm trees in any order for the 4.10 > merge window. Yes, I've already done that (though I have not pushed yet). Paolo > Thanks, Daniel > >> >> >> The three KVM patches that KVMGT needs. >> >> >> Jike Song (2): >> kvm/page_track: call notifiers with kvm_page_track_notifier_node >> kvm/page_track: export symbols for external usage >> >> Xiaoguang Chen (1): >> KVM: x86: add track_flush_slot page track notifier >> >> arch/x86/include/asm/kvm_page_track.h | 14 +- >> arch/x86/kvm/mmu.c| 11 ++- >> arch/x86/kvm/page_track.c | 31 ++- >> arch/x86/kvm/x86.c| 2 +- >> 4 files changed, 54 insertions(+), 4 deletions(-) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [GIT PULL] kvm/page_track changes for i915 KVMGT
On Wed, Nov 09, 2016 at 03:25:19PM +0100, Paolo Bonzini wrote: > Daniel, > > The following changes since commit d9092f52d7e61dd1557f2db2400ddb430e85937e: > > kvm: x86: Check memopp before dereference (CVE-2016-8630) (2016-11-02 > 21:31:53 +0100) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-kvmgt > > for you to fetch changes up to 871b7ef2a1850d0b435c8b324bf4a5d391adde3f: > > kvm/page_track: export symbols for external usage (2016-11-04 12:13:20 > +0100) Pulled into drm-intel, thanks. Please also pull this into your kvm-next tree to make sure we can land kvm/drm trees in any order for the 4.10 merge window. Thanks, Daniel > > > The three KVM patches that KVMGT needs. > > > Jike Song (2): > kvm/page_track: call notifiers with kvm_page_track_notifier_node > kvm/page_track: export symbols for external usage > > Xiaoguang Chen (1): > KVM: x86: add track_flush_slot page track notifier > > arch/x86/include/asm/kvm_page_track.h | 14 +- > arch/x86/kvm/mmu.c| 11 ++- > arch/x86/kvm/page_track.c | 31 ++- > arch/x86/kvm/x86.c| 2 +- > 4 files changed, 54 insertions(+), 4 deletions(-) -- 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] [PATCH v3] drm/i915: Trim the object sg table
From: Tvrtko Ursulin
At the moment we allocate enough sg table entries assuming we
will not be able to do any coalescing. But since in practice
we most often can, and more so very effectively, this ends up
wasting a lot of memory.
A simple and effective way of trimming the over-allocated
entries is to copy the table over to a new one allocated to the
exact size.
Experiments on my freshly logged and idle desktop (KDE) showed
that by doing this we can save approximately 1 MiB of RAM, or
when running a typical benchmark like gl_manhattan I have
even seen a 6 MiB saving.
More complicated techniques such as only copying the last used
page and freeing the rest are left to the reader.
v2:
* Update commit message.
* Use temporary sg_table on stack. (Chris Wilson)
v3:
* Commit message update.
* Comment added.
* Replace memcpy with copy assignment.
(Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d2ad73d0b5b9..1c20edba7f2a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2232,6 +2232,30 @@ static unsigned int swiotlb_max_size(void)
#endif
}
+static void i915_sg_trim(struct sg_table *orig_st)
+{
+ struct sg_table new_st;
+ struct scatterlist *sg, *new_sg;
+ unsigned int i;
+
+ if (orig_st->nents == orig_st->orig_nents)
+ return;
+
+ if (sg_alloc_table(&new_st, orig_st->nents, GFP_KERNEL))
+ return;
+
+ new_sg = new_st.sgl;
+ for_each_sg(orig_st->sgl, sg, orig_st->nents, i) {
+ sg_set_page(new_sg, sg_page(sg), sg->length, 0);
+ /* called before being DMA mapped, no need to copy sg->dma_* */
+ new_sg = sg_next(new_sg);
+ }
+
+ sg_free_table(orig_st);
+
+ *orig_st = new_st;
+}
+
static struct sg_table *
i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj)
{
@@ -2317,6 +2341,9 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
if (sg) /* loop terminated early; short sg table */
sg_mark_end(sg);
+ /* Trim unused sg entries to avoid wasting memory. */
+ i915_sg_trim(st);
+
ret = i915_gem_gtt_prepare_pages(obj, st);
if (ret)
goto err_pages;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Trim the object sg table
On Wed, Nov 09, 2016 at 03:07:38PM +, Tvrtko Ursulin wrote: > > On 09/11/2016 14:44, Chris Wilson wrote: > >Reviewed-by: Chris Wilson > > ^ I remembered it this time! > >Took a couple of attempts to spell my name right though. > > Thanks! I assume I can keep it for the above little changes. Yes. -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] [RFC i-g-t 0/4] intel-gpu-tools: Add support for the Chamelium
Hi Lyude, I think this looks very good. On 8 November 2016 at 01:05, Lyude wrote: > > - While writing this patch series, I found that quite a few of the RPC calls >for chameleond don't work as expected. For instance, I have had absolutely >no luck getting CRCs from any of the display types that the chamelium >supports. When I looked at this a few months ago, frame CRCs were working just fine. I was using libsoup, so maybe there's some problem with the unpacking of the checksum? > This isn't a huge deal though, since we usually just use the >native CRC read back on the GPU anyway. I'm not completely sure what you mean by that, but not all graphic pipelines are able to provide frame CRCs so I think this Chamelium work will be very useful when running tests that do check frame CRCs. Regards, Tomeu > > - Among other things that are broken with the chameleon, video signal >detection for DisplayPort is one of them. After the first plug/unplug > cycle, >the DisplayPort receiver gets stuck and gives the wrong results for >WaitForInputStable. Luckily I've already got a fix I'll be submitting to > the >ChromeOS guys when I get around to setting up their homebrew git tools: > > https://github.com/Lyude/chameleond/tree/wip/chameleon-fixes > >For now, expect the dp-display tests to fail without those patches. > > Lyude (4): > igt_aux: Add igt_skip_without_suspend_support() > igt_aux: Add igt_set_autoresume_delay() > igt_aux: Add some list helpers from wayland > Add support for hotplug testing with the Chamelium > > configure.ac | 13 + > lib/Makefile.am| 10 +- > lib/igt.h | 1 + > lib/igt_aux.c | 94 > lib/igt_aux.h | 41 > lib/igt_chamelium.c| 628 > + > lib/igt_chamelium.h| 77 ++ > lib/igt_kms.c | 107 + > lib/igt_kms.h | 13 +- > scripts/run-tests.sh | 4 +- > tests/Makefile.am | 5 +- > tests/Makefile.sources | 1 + > tests/chamelium.c | 549 ++ > 13 files changed, 1538 insertions(+), 5 deletions(-) > create mode 100644 lib/igt_chamelium.c > create mode 100644 lib/igt_chamelium.h > create mode 100644 tests/chamelium.c > > -- > 2.7.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Trim the object sg table
On 09/11/2016 14:44, Chris Wilson wrote:
On Wed, Nov 09, 2016 at 02:30:02PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
At the moment we allocate enough sg table entries assuming we
will not be able to do any coallescing. But since in practice
we most often can, and more so very effectively, this ends up
wasting a lot of memory.
A simple and effective way of trimming the over-allocated
entries is to copy the table over to a new one allocated to the
exact size.
Experiment on my freshly logged and idle desktop (KDE) showed
Experiments
that by doing this we can save approximately 1 MiB of RAM, or
when running a typical benchmark like gl_manhattan I have
even seen a 6 MiB saving.
More complicated techniques such as only copying the last used page and
freeing the rest are left to the reader.
Yes that would need to go into the core kernel since it needs access to
static alloc/free functions and performance benefit might be quite small
for that. Typically I see coalescing working really well so the delta in
saved allocations and frees would be quite small. Perhaps I need to
attempt to fragment my memory a lot to see what happens then.
v2:
* Update commit message.
* Use temporary sg_table on stack. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d2ad73d0b5b9..411aae535abe 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2232,6 +2232,28 @@ static unsigned int swiotlb_max_size(void)
#endif
}
+static void i915_sg_trim(struct sg_table *orig_st)
+{
+ struct sg_table new_st;
+ struct scatterlist *sg, *new_sg;
+ unsigned int i;
+
+ if (orig_st->nents == orig_st->orig_nents)
+ return;
+
+ if (sg_alloc_table(&new_st, orig_st->nents, GFP_KERNEL))
+ return;
+
+ new_sg = new_st.sgl;
+ for_each_sg(orig_st->sgl, sg, orig_st->nents, i) {
+ sg_set_page(new_sg, sg_page(sg), sg->length, 0);
+ new_sg = sg_next(new_sg);
Worth a
/* called before being DMA mapped, no need to copy sg->dma_* */
?
Hm, or something safer than a comment. Unfortunately entries are not
zeroed by default to enable a GEM_BUG_ON here. Unless CONFIG_GEM_DEBUG
could mean GFP_ZERO added to some our allocations. :)
Yeah I think comment is the best option as long as this function is
static only. Will add.
+ }
+
+ sg_free_table(orig_st);
+ memcpy(orig_st, &new_st, sizeof(*orig_st));
I would have used *orig_st = new;
It is more readable, agreed.
Reviewed-by: Chris Wilson
^ I remembered it this time!
Took a couple of attempts to spell my name right though.
Thanks! I assume I can keep it for the above little changes.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 4/9] drm/i915: Use enum plane_id in SKL wm code
From: Ville Syrjälä
Nuke skl_wm_plane_id() and just use the new intel_plane->id.
v2: Convert skl_write_plane_wm() as well
v3: Convert skl_pipe_wm_get_hw_state() correctly
Cc: Matt Roper
Cc: Paulo Zanoni
Cc: Maarten Lankhorst
Cc: Lyude
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 180 ---
2 files changed, 76 insertions(+), 106 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index a3c696d8bf93..6a4cd6edafa5 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1751,7 +1751,7 @@ void skl_write_cursor_wm(struct intel_crtc *intel_crtc,
void skl_write_plane_wm(struct intel_crtc *intel_crtc,
const struct skl_plane_wm *wm,
const struct skl_ddb_allocation *ddb,
- int plane);
+ enum plane_id plane_id);
uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state *pipe_config);
bool ilk_disable_lp_wm(struct drm_device *dev);
int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 88e28c989b9c..bae7eea6de16 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2863,28 +2863,6 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
#define SKL_SAGV_BLOCK_TIME30 /* µs */
/*
- * Return the index of a plane in the SKL DDB and wm result arrays. Primary
- * plane is always in slot 0, cursor is always in slot I915_MAX_PLANES-1, and
- * other universal planes are in indices 1..n. Note that this may leave unused
- * indices between the top "sprite" plane and the cursor.
- */
-static int
-skl_wm_plane_id(const struct intel_plane *plane)
-{
- switch (plane->base.type) {
- case DRM_PLANE_TYPE_PRIMARY:
- return 0;
- case DRM_PLANE_TYPE_CURSOR:
- return PLANE_CURSOR;
- case DRM_PLANE_TYPE_OVERLAY:
- return plane->plane + 1;
- default:
- MISSING_CASE(plane->base.type);
- return plane->plane;
- }
-}
-
-/*
* FIXME: We still don't have the proper code detect if we need to apply the
WA,
* so assume we'll always need it in order to avoid underruns.
*/
@@ -3022,7 +3000,6 @@ bool intel_can_enable_sagv(struct drm_atomic_state *state)
struct intel_crtc *crtc;
struct intel_plane *plane;
struct intel_crtc_state *cstate;
- struct skl_plane_wm *wm;
enum pipe pipe;
int level, latency;
@@ -3049,7 +3026,8 @@ bool intel_can_enable_sagv(struct drm_atomic_state *state)
return false;
for_each_intel_plane_on_crtc(dev, crtc, plane) {
- wm = &cstate->wm.skl.optimal.planes[skl_wm_plane_id(plane)];
+ struct skl_plane_wm *wm =
+ &cstate->wm.skl.optimal.planes[plane->id];
/* Skip this plane if it's not enabled */
if (!wm->wm[0].plane_en)
@@ -3148,28 +3126,28 @@ static void skl_ddb_entry_init_from_hw(struct
skl_ddb_entry *entry, u32 reg)
void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
struct skl_ddb_allocation *ddb /* out */)
{
- enum pipe pipe;
- int plane;
+ struct intel_crtc *crtc;
u32 val;
memset(ddb, 0, sizeof(*ddb));
- for_each_pipe(dev_priv, pipe) {
+ for_each_intel_crtc(&dev_priv->drm, crtc) {
enum intel_display_power_domain power_domain;
+ enum plane_id plane_id;
+ enum pipe pipe = crtc->pipe;
power_domain = POWER_DOMAIN_PIPE(pipe);
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
continue;
- for_each_universal_plane(dev_priv, pipe, plane) {
- val = I915_READ(PLANE_BUF_CFG(pipe, plane));
- skl_ddb_entry_init_from_hw(&ddb->plane[pipe][plane],
- val);
- }
+ for_each_plane_id_on_crtc(crtc, plane_id) {
+ if (plane_id != PLANE_CURSOR)
+ val = I915_READ(PLANE_BUF_CFG(pipe, plane_id));
+ else
+ val = I915_READ(CUR_BUF_CFG(pipe));
- val = I915_READ(CUR_BUF_CFG(pipe));
- skl_ddb_entry_init_from_hw(&ddb->plane[pipe][PLANE_CURSOR],
- val);
+ skl_ddb_entry_init_from_hw(&ddb->plane[pipe][plane_id],
val);
+ }
intel_display_power_put(dev_priv, power_domain);
}
@@ -3270,30 +3248,30 @@ skl_get_total_relative_data_rate(struct
intel_crtc_state *intel_cstate,
struct drm_crtc_state *cstate = &intel_cst
Re: [Intel-gfx] [PATCH v4 1/8] drm/i915/skl+: use linetime latency instead of ddb size
Hi,
On Monday 31 October 2016 11:33 PM, Paulo Zanoni wrote:
Em Qui, 2016-10-13 às 16:28 +0530, Kumar, Mahesh escreveu:
This patch make changes to use linetime latency instead of allocated
DDB size during plane watermark calculation in switch case, This is
required to implement new DDB allocation algorithm.
In New Algorithm DDB is allocated based on WM values, because of
which
number of DDB blocks will not be available during WM calculation,
So this "linetime latency" is suggested by SV/HW team to use during
switch-case for WM blocks selection.
Changes since v1:
- Rebase on top of Paulo's patch series
Changes since v2:
- Fix if-else condition (pointed by Maarten)
Signed-off-by: "Kumar, Mahesh"
---
drivers/gpu/drm/i915/intel_pm.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 7f1748a..098336d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3616,10 +3616,14 @@ static int skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
fb->modifier[0] == I915_FORMAT_MOD_Yf_TILED) {
selected_result = max(method2, y_tile_minimum);
} else {
+ uint32_t linetime_us = 0;
+
+ linetime_us = DIV_ROUND_UP(width * 1000,
+ skl_pipe_pixel_rate(cstate));
Can't we just call skl_compute_linetime_wm() here? I don't like having
two pieces of the code computing the same thing. My last round of bug
fixes included a fix for duplicated code that got out of sync after
spec changes.
These two have different values in skl_compute_linetime_wm we multiply
by 8, not here.
if ((cpp * cstate->base.adjusted_mode.crtc_htotal /
512 < 1) &&
(plane_bytes_per_line / 512 < 1))
selected_result = method2;
- else if ((ddb_allocation / plane_blocks_per_line) >=
1)
+ else if (latency >= linetime_us)
Still doesn't match the spec. The "ddb_allocation /
planes_block_per_line" is still necessary.
After New algorithm patch, we will not have access to ddb_allocation, as
allocation will happen later.
So we can't use ddb_allocation in our calculation, This check in Bspec
is kept for the environment/OS where we don't allocate DDB dynamically.
hence those OS will have access to ddb_allocation during WM calculation
phase.
thanks,
Regards,
-Mahesh
selected_result = min(method1, method2);
else
selected_result = method1;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Spin until breadcrumb threads are complete
On 08/11/2016 14:37, Chris Wilson wrote:
When we need to reset the global seqno on wraparound, we have to wait
until the current rbtrees are drained (or otherwise the next waiter will
be out of sequence). The current mechanism to kick and spin until
complete, may exit too early as it would break if the target thread was
currently running. Instead, we must wake up the threads, but keep
spinning until the trees have been deleted.
In order to appease Tvrtko, busy spin rather than yield().
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_request.c | 5 ++---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 31 ---
drivers/gpu/drm/i915/intel_ringbuffer.h | 3 +--
3 files changed, 15 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_request.c
b/drivers/gpu/drm/i915/i915_gem_request.c
index d866069c1767..6c71637d4be1 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -319,9 +319,8 @@ static int i915_gem_init_global_seqno(struct
drm_i915_private *i915, u32 seqno)
/* If the seqno wraps around, we need to clear the breadcrumb rbtree */
if (!i915_seqno_passed(seqno, atomic_read(&timeline->next_seqno))) {
- while (intel_kick_waiters(i915) || intel_kick_signalers(i915))
- yield();
- yield();
+ while (intel_breadcrumbs_busy(i915))
+ cond_resched(); /* spin until threads are complete */
}
atomic_set(&timeline->next_seqno, seqno);
diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index c410d3d6465f..c9c46a538edb 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -629,35 +629,28 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs
*engine)
cancel_fake_irq(engine);
}
-unsigned int intel_kick_waiters(struct drm_i915_private *i915)
+unsigned int intel_breadcrumbs_busy(struct drm_i915_private *i915)
{
struct intel_engine_cs *engine;
enum intel_engine_id id;
unsigned int mask = 0;
- /* To avoid the task_struct disappearing beneath us as we wake up
-* the process, we must first inspect the task_struct->state under the
-* RCU lock, i.e. as we call wake_up_process() we must be holding the
-* rcu_read_lock().
-*/
- for_each_engine(engine, i915, id)
- if (unlikely(intel_engine_wakeup(engine)))
- mask |= intel_engine_flag(engine);
+ for_each_engine(engine, i915, id) {
+ struct intel_breadcrumbs *b = &engine->breadcrumbs;
- return mask;
-}
+ spin_lock_irq(&b->lock);
-unsigned int intel_kick_signalers(struct drm_i915_private *i915)
-{
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
- unsigned int mask = 0;
+ if (b->first_wait) {
+ wake_up_process(b->first_wait->tsk);
+ mask |= intel_engine_flag(engine);
+ }
- for_each_engine(engine, i915, id) {
- if (unlikely(READ_ONCE(engine->breadcrumbs.first_signal))) {
- wake_up_process(engine->breadcrumbs.signaler);
+ if (b->first_signal) {
+ wake_up_process(b->signaler);
mask |= intel_engine_flag(engine);
}
+
+ spin_unlock_irq(&b->lock);
}
return mask;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index cbc148863a03..3466b4e77e7c 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -587,7 +587,6 @@ static inline bool intel_engine_wakeup(const struct
intel_engine_cs *engine)
void intel_engine_reset_breadcrumbs(struct intel_engine_cs *engine);
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
-unsigned int intel_kick_waiters(struct drm_i915_private *i915);
-unsigned int intel_kick_signalers(struct drm_i915_private *i915);
+unsigned int intel_breadcrumbs_busy(struct drm_i915_private *i915);
#endif /* _INTEL_RINGBUFFER_H_ */
Looks OK. Side note to myself - catch up on the rcu waiter business.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Trim the object sg table
On Wed, Nov 09, 2016 at 02:30:02PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> At the moment we allocate enough sg table entries assuming we
> will not be able to do any coallescing. But since in practice
> we most often can, and more so very effectively, this ends up
> wasting a lot of memory.
>
> A simple and effective way of trimming the over-allocated
> entries is to copy the table over to a new one allocated to the
> exact size.
>
> Experiment on my freshly logged and idle desktop (KDE) showed
Experiments
> that by doing this we can save approximately 1 MiB of RAM, or
> when running a typical benchmark like gl_manhattan I have
> even seen a 6 MiB saving.
More complicated techniques such as only copying the last used page and
freeing the rest are left to the reader.
> v2:
> * Update commit message.
> * Use temporary sg_table on stack. (Chris Wilson)
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d2ad73d0b5b9..411aae535abe 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2232,6 +2232,28 @@ static unsigned int swiotlb_max_size(void)
> #endif
> }
>
> +static void i915_sg_trim(struct sg_table *orig_st)
> +{
> + struct sg_table new_st;
> + struct scatterlist *sg, *new_sg;
> + unsigned int i;
> +
> + if (orig_st->nents == orig_st->orig_nents)
> + return;
> +
> + if (sg_alloc_table(&new_st, orig_st->nents, GFP_KERNEL))
> + return;
> +
> + new_sg = new_st.sgl;
> + for_each_sg(orig_st->sgl, sg, orig_st->nents, i) {
> + sg_set_page(new_sg, sg_page(sg), sg->length, 0);
> + new_sg = sg_next(new_sg);
Worth a
/* called before being DMA mapped, no need to copy sg->dma_* */
?
> + }
> +
> + sg_free_table(orig_st);
> + memcpy(orig_st, &new_st, sizeof(*orig_st));
I would have used *orig_st = new;
Reviewed-by: Chris Wilson
^ I remembered it this time!
Took a couple of attempts to spell my name right though.
-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 v2] configure.ac: correctly manage DRM_INTEL_{CFLAGS, LIBS}
Reviewed-by: Robert Foss ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Trim the object sg table
From: Tvrtko Ursulin
At the moment we allocate enough sg table entries assuming we
will not be able to do any coallescing. But since in practice
we most often can, and more so very effectively, this ends up
wasting a lot of memory.
A simple and effective way of trimming the over-allocated
entries is to copy the table over to a new one allocated to the
exact size.
Experiment on my freshly logged and idle desktop (KDE) showed
that by doing this we can save approximately 1 MiB of RAM, or
when running a typical benchmark like gl_manhattan I have
even seen a 6 MiB saving.
v2:
* Update commit message.
* Use temporary sg_table on stack. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d2ad73d0b5b9..411aae535abe 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2232,6 +2232,28 @@ static unsigned int swiotlb_max_size(void)
#endif
}
+static void i915_sg_trim(struct sg_table *orig_st)
+{
+ struct sg_table new_st;
+ struct scatterlist *sg, *new_sg;
+ unsigned int i;
+
+ if (orig_st->nents == orig_st->orig_nents)
+ return;
+
+ if (sg_alloc_table(&new_st, orig_st->nents, GFP_KERNEL))
+ return;
+
+ new_sg = new_st.sgl;
+ for_each_sg(orig_st->sgl, sg, orig_st->nents, i) {
+ sg_set_page(new_sg, sg_page(sg), sg->length, 0);
+ new_sg = sg_next(new_sg);
+ }
+
+ sg_free_table(orig_st);
+ memcpy(orig_st, &new_st, sizeof(*orig_st));
+}
+
static struct sg_table *
i915_gem_object_get_pages_gtt(struct drm_i915_gem_object *obj)
{
@@ -2317,6 +2339,9 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
if (sg) /* loop terminated early; short sg table */
sg_mark_end(sg);
+ /* Trim unused sg entries to avoid wasting memory. */
+ i915_sg_trim(st);
+
ret = i915_gem_gtt_prepare_pages(obj, st);
if (ret)
goto err_pages;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [drm-intel:topic/drm-misc 1/2] backtracetest.c:undefined reference to `save_stack_trace'
On 9 November 2016 at 14:12, Chris Wilson wrote: > On Wed, Nov 09, 2016 at 10:01:37PM +0800, kbuild test robot wrote: >> tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc >> head: 77d150b90d58ae6a43bf67af28feb26384d06cd6 >> commit: cd456f8d06d2036e1e013136c3fbf5721d04f6d7 [1/2] drm: Restrict >> stackdepot usage to builtin drm.ko >> config: m68k-allyesconfig (attached as .config) >> compiler: m68k-linux-gcc (GCC) 4.9.0 >> reproduce: >> wget >> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross >> -O ~/bin/make.cross >> chmod +x ~/bin/make.cross >> git checkout cd456f8d06d2036e1e013136c3fbf5721d04f6d7 >> # save the attached .config to linux build tree >> make.cross ARCH=m68k >> >> All errors (new ones prefixed by >>): >> >>kernel/built-in.o: In function `backtrace_regression_test': >> >> backtracetest.c:(.text+0x550d4): undefined reference to `save_stack_trace' >>mm/built-in.o: In function `set_track': >>slub.c:(.text+0x41414): undefined reference to `save_stack_trace' >>drivers/built-in.o: In function `save_stack.isra.7': >> >> drm_mm.c:(.text+0x16be82): undefined reference to `save_stack_trace' > > Anyone got an idea for this one? m68k is missing save_stack_trace(). > There's no arch CONFIG_HAS_SAVE_STACK_TRACE, it looks like an oversight > in arch/m68k. STACKTRACE_SUPPORT ? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [GIT PULL] kvm/page_track changes for i915 KVMGT
Daniel, The following changes since commit d9092f52d7e61dd1557f2db2400ddb430e85937e: kvm: x86: Check memopp before dereference (CVE-2016-8630) (2016-11-02 21:31:53 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-kvmgt for you to fetch changes up to 871b7ef2a1850d0b435c8b324bf4a5d391adde3f: kvm/page_track: export symbols for external usage (2016-11-04 12:13:20 +0100) The three KVM patches that KVMGT needs. Jike Song (2): kvm/page_track: call notifiers with kvm_page_track_notifier_node kvm/page_track: export symbols for external usage Xiaoguang Chen (1): KVM: x86: add track_flush_slot page track notifier arch/x86/include/asm/kvm_page_track.h | 14 +- arch/x86/kvm/mmu.c| 11 ++- arch/x86/kvm/page_track.c | 31 ++- arch/x86/kvm/x86.c| 2 +- 4 files changed, 54 insertions(+), 4 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2] extend page_track for external usage
On 09/11/2016 03:03, Zhenyu Wang wrote: > On 2016.11.07 10:17:54 +0100, Daniel Vetter wrote: Paolo, for this case, do you think it's feasible we pick them through drm/i915 merge path? As currently initial KVMGT patch sets require these exported symbols, that's why I ask how we should handle this dependency. >>> >>> Then it's actually a good thing that I dropped from kvm/queue! You can >>> certainly include these patches, but please do that through a topic branch. >>> >>> I've prepared a branch for you >>> (git://git.kernel.org/pub/scm/virt/kvm/kvm.git branch for-kvmgt). Once >>> Linus processes my outstanding pull request, the branch will only >>> include the three page-tracking patches. Please pull that topic branch >>> into your own branch, and ensure you have a merge commit when you send >>> the pull request to Daniel. The merge commit ensures that the workflow >>> was correct; use --no-ff if necessary. >>> >>> You can do the same for Jike's patches for the KVM-VFIO device, when >>> Alex reviews them, and I suppose you'll need a topic branch for mdev >>> too? I didn't know that KVMGT was planned for 4.10. In the future, >>> let's synchronize ahead so that we can prepare topic branches for you. >> >> Ok, back from the useless wifi at plumbers, I can mail again. Zhenyu >> confirmed on irc that the initial code pile only needs this. For the >> cross-maintainer topic tree I prefer a formal pull request with stable >> tag. Please also cc: intel-gfx on that, since I plan to merge that one >> directly into i915. >> > > Paolo, could you help to do this for Daniel? Daniel would like to merge > current KVMGT required change for KVM directly, then I'd base KVMGT change > on that. Yes, I'll send it today. Paolo signature.asc Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [drm-intel:topic/drm-misc 1/2] backtracetest.c:undefined reference to `save_stack_trace'
On Wed, Nov 09, 2016 at 10:01:37PM +0800, kbuild test robot wrote: > tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc > head: 77d150b90d58ae6a43bf67af28feb26384d06cd6 > commit: cd456f8d06d2036e1e013136c3fbf5721d04f6d7 [1/2] drm: Restrict > stackdepot usage to builtin drm.ko > config: m68k-allyesconfig (attached as .config) > compiler: m68k-linux-gcc (GCC) 4.9.0 > reproduce: > wget > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > -O ~/bin/make.cross > chmod +x ~/bin/make.cross > git checkout cd456f8d06d2036e1e013136c3fbf5721d04f6d7 > # save the attached .config to linux build tree > make.cross ARCH=m68k > > All errors (new ones prefixed by >>): > >kernel/built-in.o: In function `backtrace_regression_test': > >> backtracetest.c:(.text+0x550d4): undefined reference to `save_stack_trace' >mm/built-in.o: In function `set_track': >slub.c:(.text+0x41414): undefined reference to `save_stack_trace' >drivers/built-in.o: In function `save_stack.isra.7': > >> drm_mm.c:(.text+0x16be82): undefined reference to `save_stack_trace' Anyone got an idea for this one? m68k is missing save_stack_trace(). There's no arch CONFIG_HAS_SAVE_STACK_TRACE, it looks like an oversight in arch/m68k. -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] [RFC PATCH v2 0/8] Add support for Legacy Hdmi audio
On Sun, Nov 06, 2016 at 11:42:31PM -0700, Pierre-Louis Bossart wrote: > I am all for convergence when it makes sense but I don't see how > hdmi-codec.h provides equivalent functionality for BYT/CHT with what was > suggested in this patchset -derived from VED patches- and discussed earlier > with intel-gfx folks, specifically how LPE pipe interrupts are > masked/unmasked and passed to the audio driver? The BYT/CHT HDMI Without knowing what these things are it's hard to comment but it does seem that if Intel has a reasonable use case for them then so too will other vendors at some point. > functionality is also not modeled as an ASoC codec - which seems a > dependency from the comments in hdmi-codec.h - since it's really part of the > i915 hardware and exposed only as a set of registers+DMA, without any serial > link interface typically needed for an external device or the internal > HDAudio-display link. None of which is at all unusal. The Intel hardware really doesn't seem like the sort of special snowflake that people appear to believe it to be. signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:topic/drm-misc 1/2] backtracetest.c:undefined reference to `save_stack_trace'
tree: git://anongit.freedesktop.org/drm-intel topic/drm-misc head: 77d150b90d58ae6a43bf67af28feb26384d06cd6 commit: cd456f8d06d2036e1e013136c3fbf5721d04f6d7 [1/2] drm: Restrict stackdepot usage to builtin drm.ko config: m68k-allyesconfig (attached as .config) compiler: m68k-linux-gcc (GCC) 4.9.0 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout cd456f8d06d2036e1e013136c3fbf5721d04f6d7 # save the attached .config to linux build tree make.cross ARCH=m68k All errors (new ones prefixed by >>): kernel/built-in.o: In function `backtrace_regression_test': >> backtracetest.c:(.text+0x550d4): undefined reference to `save_stack_trace' mm/built-in.o: In function `set_track': slub.c:(.text+0x41414): undefined reference to `save_stack_trace' drivers/built-in.o: In function `save_stack.isra.7': >> drm_mm.c:(.text+0x16be82): undefined reference to `save_stack_trace' --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/4] drm: Add a new connector property for link status
On Mon, 31 Oct 2016, Manasi Navare wrote:
> A new default connector property is added for keeping
> track of whether the link is good (link training passed) or
> link is bad (link training failed). If the link status property
> is not good, then userspace should fire off a new modeset at the current
> mode even if there have not been any changes in the mode list
> or connector status.
> Also add link status connector member corersponding to the
> decoded value of link status property.
I think it would be good to expand on this, both in the commit message
and documentation. This is UABI after all.
When is the property changed, who changes it, what is the userspace
expected to do when the status goes from good to bad, how does userspace
notice it's gone bad (uevents).
While we want this for handling DP link training failures during mode
setting according to the DP spec, in a way that can pass the CTS, it's
also needed for async mode sets.
BR,
Jani.
>
> v3:
> * Drop "link training" from description since this is
> not specific to DP (Jani Nikula)
> * Add link status member to store property value locally
> (Ville Syrjala)
> v2:
> * Make this a default connector property (Daniel Vetter)
>
> Cc: dri-de...@lists.freedesktop.org
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Ville Syrjala
> Cc: Chris Wilson
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/drm_connector.c | 17 +
> include/drm/drm_connector.h | 7 ++-
> include/drm/drm_crtc.h | 5 +
> include/uapi/drm/drm_mode.h | 4
> 4 files changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 2db7fb5..d4e852f 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
> drm_object_attach_property(&connector->base,
> config->dpms_property, 0);
>
> + drm_object_attach_property(&connector->base,
> +config->link_status_property,
> +0);
> +
> if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
> drm_object_attach_property(&connector->base,
> config->prop_crtc_id, 0);
> }
> @@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum
> subpixel_order order)
> };
> DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
>
> +static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
> + { DRM_MODE_LINK_STATUS_GOOD, "Good" },
> + { DRM_MODE_LINK_STATUS_BAD, "Bad" },
> +};
> +DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
> +
> /**
> * drm_display_info_set_bus_formats - set the supported bus formats
> * @info: display info to store bus formats in
> @@ -622,6 +632,13 @@ int drm_connector_create_standard_properties(struct
> drm_device *dev)
> return -ENOMEM;
> dev->mode_config.tile_property = prop;
>
> + prop = drm_property_create_enum(dev, 0, "link-status",
> + drm_link_status_enum_list,
> + ARRAY_SIZE(drm_link_status_enum_list));
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.link_status_property = prop;
> +
> return 0;
> }
>
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index ac9d7d8..5c335e8 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -682,6 +682,12 @@ struct drm_connector {
> uint8_t num_h_tile, num_v_tile;
> uint8_t tile_h_loc, tile_v_loc;
> uint16_t tile_h_size, tile_v_size;
> +
> + /* Connector Link status
> + * 0: If the link is Good
> + * 1: If the link is Bad
> + */
> + int link_status;
> };
>
> #define obj_to_connector(x) container_of(x, struct drm_connector, base)
> @@ -754,7 +760,6 @@ int drm_mode_create_tv_properties(struct drm_device *dev,
> int drm_mode_create_scaling_mode_property(struct drm_device *dev);
> int drm_mode_create_aspect_ratio_property(struct drm_device *dev);
> int drm_mode_create_suggested_offset_properties(struct drm_device *dev);
> -
> int drm_mode_connector_set_path_property(struct drm_connector *connector,
>const char *path);
> int drm_mode_connector_set_tile_property(struct drm_connector *connector);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index fa1aa21..737f4d3 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1151,6 +1151,11 @@ struct drm_mode_config {
>*/
> struct drm_property *tile_property;
> /**
> + * @link_status_property: Default connector property for link status
> + * of a connector
> + */
> + struct drm_property *link_status_property;
> + /**
>* @plane_type_property: Default plane property to differentiat
Re: [Intel-gfx] [PATCH 2/9] drm/i915: Add per-pipe plane identifier
On Tue, Nov 08, 2016 at 04:53:20PM -0800, Matt Roper wrote:
> On Tue, Nov 08, 2016 at 04:47:12PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > As I told people in [1] we really should not be confusing enum plane
> > as a per-pipe plane identifier. Looks like that happened nonetheless, so
> > let's fix it up by splitting the two into two enums.
> >
> > We'll also want something we just directly pass to various register
> > offset macros and whatnot on SKL+. So let's make this new thing work for
> > that.
> > Currently we pass intel_plane->plane for the "sprites" and just a
> > hardcoded zero for the "primary" planes. We want to get rid of that
> > hardocoding so that we can share the same code for all planes (apart
> > from the legacy cursor of course).
> >
> > [1]
> > https://lists.freedesktop.org/archives/intel-gfx/2015-September/076082.html
> >
> > Cc: Matt Roper
> > Cc: Daniel Vetter
> > Signed-off-by: Ville Syrjälä
>
> So the goal here is to make intel_plane->plane represent which of the
> system's primary planes (A, B, or C) the plane structure refers to?
It's the index we pass to DSPCNTR & co. On SKL+ we theoretically don't
need it since we index most of plane registers via the plane->id, but
there are still a few exceptions left perhaps, which is why I didn't
outlaw it fully on SKL+ at this point.
> >From a quick Cocci test, it looks like there's only a single use of the
> value for that purpose in our driver (in primary_get_hw_state). I think
> all of the other calls to DSPCNTR are actually using crtc->plane as
> their index, which should have the same value. Would it make more sense
> to just drop intel_plane->plane entirely and switch the last user over
> to crtc->plane so that we're not carrying around a structure field that
> is either bogus or empty on the majority of the platform's planes?
crtc->plane needs to die. We want the planes to be independent of crtcs
on pre-g4x.
>
> While we're at it, we could rename 'enum plane' to something like 'enum
> primary_plane' to make it extra clear what its purpose is and avoid
> future confusion. And maybe a similar rename to crtc->plane as well.
> We use the standalone term 'plane' in a generic manner in too many
> places in our driver and it means something slightly different
> everywhere...
I think I want to resurrect plane->plane for cursor at some point since
on gen2/3 cursors can move between pipes as well. Alternative we could
add some other enum for those.
Anyways, I was thinking of calling this thing legacy_plane_id or
something like that, but couldn't really convince myself that any
particular name was good, so I left it as is for now.
>
>
> Matt
>
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 28 +---
> > drivers/gpu/drm/i915/intel_display.c | 2 ++
> > drivers/gpu/drm/i915/intel_drv.h | 3 ++-
> > drivers/gpu/drm/i915/intel_sprite.c | 1 +
> > 4 files changed, 26 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 30777dee3f9c..2451b88b1e82 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -171,22 +171,36 @@ static inline bool transcoder_is_dsi(enum transcoder
> > transcoder)
> > }
> >
> > /*
> > - * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
> > - * number of planes per CRTC. Not all platforms really have this many
> > planes,
> > - * which means some arrays of size I915_MAX_PLANES may have unused entries
> > - * between the topmost sprite plane and the cursor plane.
> > + * Global legacy plane identifier. Valid only for primary/sprite
> > + * planes on pre-g4x, and only for primary planes on g4x+.
> > */
> > enum plane {
> > - PLANE_A = 0,
> > + PLANE_A,
> > PLANE_B,
> > PLANE_C,
> > - PLANE_CURSOR,
> > - I915_MAX_PLANES,
> > };
> > #define plane_name(p) ((p) + 'A')
> >
> > #define sprite_name(p, s) ((p) * INTEL_INFO(dev_priv)->num_sprites[(p)] +
> > (s) + 'A')
> >
> > +/*
> > + * Per-pipe plane identifier.
> > + * I915_MAX_PLANES in the enum below is the maximum (across all platforms)
> > + * number of planes per CRTC. Not all platforms really have this many
> > planes,
> > + * which means some arrays of size I915_MAX_PLANES may have unused entries
> > + * between the topmost sprite plane and the cursor plane.
> > + *
> > + * This is expected to be passed to various register macros
> > + * (eg. PLANE_CTL(), PS_PLANE_SEL(), etc.) so adjust with care.
> > + */
> > +enum plane_id {
> > + PLANE_PRIMARY,
> > + PLANE_SPRITE0,
> > + PLANE_SPRITE1,
> > + PLANE_CURSOR,
> > + I915_MAX_PLANES,
> > +};
> > +
> > enum port {
> > PORT_NONE = -1,
> > PORT_A = 0,
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 10869360cfdc..b318119330e8 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > ++
Re: [Intel-gfx] [PATCH v3] drm: move allocation out of drm_get_format_name()
On Wed, Nov 9, 2016 at 12:42 PM, Eric Engestrom wrote: >> Well, had to drop it again since it didn't compile: >> >> >> CC [M] drivers/gpu/drm/drm_blend.o >> drivers/gpu/drm/drm_atomic.c: In function ‘drm_atomic_plane_print_state’: >> drivers/gpu/drm/drm_atomic.c:920:5: error: too few arguments to function >> ‘drm_get_format_name’ >> drm_get_format_name(fb->pixel_format)); >> ^~~ >> In file included from ./include/drm/drmP.h:71:0, >> from drivers/gpu/drm/drm_atomic.c:29: >> ./include/drm/drm_fourcc.h:65:7: note: declared here >> char *drm_get_format_name(uint32_t format, struct drm_format_name_buf *buf); >>^~~ >> >> Can you pls rebase onto drm-misc or linux-next or something? > > That was based on airlied/drm-next (last fetched on Sunday I think), > I can rebase it on drm-misc if it helps, but it seems older than > drm-next. > Should I just rebase on top of current head of drm-next? It needs to be drm-misc (linux-next doesn't have it yet) due to the new atomic debug work that we just landed. I'm working on drm-tip as a drm local integration tree to ease pains like these a bit, but that doesn't really exist yet. -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 v3 4/4] drm/i915: Implement Link Rate fallback on Link training failure
On Mon, 07 Nov 2016, Manasi Navare wrote: > Jani, could you please take a look at this patch? > I have addressed your comments on the previous revision. > The common_rates array can be moved into Intel dp > structure in a follow up patch since that would require changes > in a lot of places other than the link rate fallback implementation. I think this is looking good. I think you need to put this together in a series that doesn't add something first, and then remove it, i.e. build a coherent story from the start. It's not that many patches. Then you need to post all patches on both intel-gfx and dri-devel, preferrably in a fresh thread, not replying to previous versions. The thread is too confusing now with so many versions. Then we need to get r-b and acks for the drm changes. Daniel, can you help with the last part? 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 v3 4/4] drm/i915: Implement Link Rate fallback on Link training failure
On Wed, 02 Nov 2016, Manasi Navare wrote:
> If link training at a link rate optimal for a particular
> mode fails during modeset's atomic commit phase, then we
> let the modeset complete and then retry. We save the link rate
> value at which link training failed, update the link status property
> to "BAD" and use a lower link rate to prune the modes. It will redo
> the modeset on the current mode at lower link rate or if the current
> mode gets pruned due to lower link constraints then, it will send a
> hotplug uevent for userspace to handle it.
>
> This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> 4.3.1.6.
>
> v3:
> * Set link status property to BAd unconditionally (Jani Nikula)
> * Dont use two separate variables link_train_failed and link_status
> to indicate same thing (Jani Nikula)
> v2:
> * Squashed a few patches (Jani Nikula)
>
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Ville Syrjala
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 7 +++
> drivers/gpu/drm/i915/intel_ddi.c | 22 -
> drivers/gpu/drm/i915/intel_dp.c | 70
> ---
> drivers/gpu/drm/i915/intel_dp_link_training.c | 12 +++--
> drivers/gpu/drm/i915/intel_drv.h | 6 ++-
> 5 files changed, 105 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 75ad01d..94b0b3a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct
> drm_atomic_state *state,
> connector_state);
> if (ret)
> return ret;
> +
> + if (connector->state->crtc) {
> + crtc_state = drm_atomic_get_existing_crtc_state(state,
> +
> connector->state->crtc);
> + if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
> + crtc_state->connectors_changed = true;
> + }
> }
Could this be a separate patch? Anyway needs to be posted on dri-devel.
>
> /*
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 938ac4d..a59f8d2 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1684,6 +1684,8 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
> struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> enum port port = intel_ddi_get_encoder_port(encoder);
> + struct intel_connector *intel_connector = intel_dp->attached_connector;
> + struct drm_connector *connector = &intel_connector->base;
>
> intel_dp_set_link_params(intel_dp, link_rate, lane_count,
>link_mst);
> @@ -1694,7 +1696,25 @@ static void intel_ddi_pre_enable_dp(struct
> intel_encoder *encoder,
> intel_prepare_dp_ddi_buffers(encoder);
> intel_ddi_init_dp_buf_reg(encoder);
> intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> - intel_dp_start_link_train(intel_dp);
> + if (!intel_dp_start_link_train(intel_dp)) {
> + DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane
> count = %d",
> + link_rate, lane_count);
> + connector->link_status = DRM_MODE_LINK_STATUS_BAD;
Why does this not use intel_dp_set_link_status_property()?
> + intel_dp_get_link_train_fallback_values(intel_dp, link_rate,
> + lane_count);
> + /* Schedule a Hotplug Uevent to userspace to start modeset */
> + schedule_work(&intel_connector->modeset_retry_work);
> + } else {
> + DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane
> count = %d",
> + link_rate, lane_count);
> + intel_dp->fallback_link_rate_index = -1;
> + intel_dp->fallback_link_rate = 0;
> + intel_dp->fallback_lane_count = 0;
> + connector->link_status = DRM_MODE_LINK_STATUS_GOOD;
> + intel_dp_set_link_status_property(connector,
> + DRM_MODE_LINK_STATUS_GOOD);
> + }
> +
> if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> intel_dp_stop_link_train(intel_dp);
> }
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index fb4fcdd..659b17f 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -310,9 +310,6 @@ void intel_dp_get_link_train_fallback_values(struct
> intel_dp *intel_dp,
> int common_len;
> int link_rate_index = -1;
>
> - if (!intel_dp->link_train_failed)
> -
[Intel-gfx] ✓ Fi.CI.BAT: success for dev_priv cleanup continuation (rev3)
== Series Details == Series: dev_priv cleanup continuation (rev3) URL : https://patchwork.freedesktop.org/series/14844/ State : success == Summary == Series 14844v3 dev_priv cleanup continuation https://patchwork.freedesktop.org/api/1.0/series/14844/revisions/3/mbox/ fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 972b631c86ecf25d43d16b3617672f481a5cbd08 drm-intel-nightly: 2016y-11m-09d-10h-46m-28s UTC integration manifest afa7665 drm/i915: Convert i915_drv.c to INTEL_GEN 4ee340c drm/i915: Pass dev_priv to INTEL_INFO everywhere apart from the gen use b15872b drm/i915: Further assorted dev_priv cleanups 2b8c634 drm/i915: More assorted dev_priv cleanups 0e86e55 drm/i915: Assorted dev_priv cleanups == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2942/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 05/11] drm/i915/gen9+: Do not initialise active_crtcs for !modeset
Op 08-11-16 om 15:11 schreef Ville Syrjälä: > On Tue, Nov 08, 2016 at 01:55:36PM +0100, Maarten Lankhorst wrote: >> This is a hack and not needed. Use the right mask by checking >> intel_state->modeset. This works for watermark sanitization too. >> >> Signed-off-by: Maarten Lankhorst >> --- >> drivers/gpu/drm/i915/intel_pm.c | 38 +++--- >> 1 file changed, 15 insertions(+), 23 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_pm.c >> b/drivers/gpu/drm/i915/intel_pm.c >> index 02f52b52a03d..d38a46efcfed 100644 >> --- a/drivers/gpu/drm/i915/intel_pm.c >> +++ b/drivers/gpu/drm/i915/intel_pm.c >> @@ -3089,26 +3089,22 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device >> *dev, >> struct intel_atomic_state *intel_state = to_intel_atomic_state(state); >> struct drm_i915_private *dev_priv = to_i915(dev); >> struct drm_crtc *for_crtc = cstate->base.crtc; >> -unsigned int pipe_size, ddb_size; >> +unsigned int pipe_size, ddb_size, active_crtcs; >> int nth_active_pipe; >> >> +if (intel_state->modeset) >> +active_crtcs = intel_state->active_crtcs; >> +else >> +active_crtcs = dev_priv->active_crtcs; > What's the story with the locking here? if !modeset, 3 things can happen: 1. fastset, connection_mutex held, dev_priv->active_crtcs cannot change. 2. crtc disabled, active_crtcs is potentially garbage, but harmless since we don't write disabled wm's when the crtc is already disabled. (same as what happens currently) 3. crtc enabled, dev_priv->active_crtcs is valid because ddb reallocation requires locking all active crtc's for reallocation, which requires taking this lock for this crtc. This wouldn't be valid for gen8-, but is valid because of skl reallocation requirements. ~Maarten ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] qf: Document how to bisect the patch pile history
Rodrigo recently asked me about this, and I totally failed to properly document it! Cc: Rodrigo Vivi Signed-off-by: Daniel Vetter --- qf | 19 +++ 1 file changed, 19 insertions(+) diff --git a/qf b/qf index 31b9f3bae0a2..883dda0a1668 100755 --- a/qf +++ b/qf @@ -540,6 +540,25 @@ $ qf git pull && qf checkout test Doing only a git pull on the quilt branch leads to an inconsitent state if the baseline changed. +Bisecting patch history +--- + +Git history in the patches directory records every rebase or any other changes +to the patch pile, including the baseline. Which means it can be used for +bisecting not just the individual patches, but the history of the entire patch +pile: + +$ qf git bisect *old-sha1* *new-sha1* + +to start the bisect process, and then for each bisect step: + +$ qf checkout HEAD + +Run tests to figure out whether it's part of the new (bad) or old (good) +history, then tell git using + +$ qf git bisect new|old + COMMANDS -- 2.7.4 ___ 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: Demote i915_gem_open() debugging from DRIVER to USER
== Series Details == Series: drm/i915: Demote i915_gem_open() debugging from DRIVER to USER URL : https://patchwork.freedesktop.org/series/15023/ State : success == Summary == Series 15023v1 drm/i915: Demote i915_gem_open() debugging from DRIVER to USER https://patchwork.freedesktop.org/api/1.0/series/15023/revisions/1/mbox/ fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 972b631c86ecf25d43d16b3617672f481a5cbd08 drm-intel-nightly: 2016y-11m-09d-10h-46m-28s UTC integration manifest 69bcd13 drm/i915: Demote i915_gem_open() debugging from DRIVER to USER == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2941/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gvt: Disable access to stolen memory as a guest
== Series Details == Series: drm/i915/gvt: Disable access to stolen memory as a guest URL : https://patchwork.freedesktop.org/series/15022/ State : warning == Summary == Series 15022v1 drm/i915/gvt: Disable access to stolen memory as a guest https://patchwork.freedesktop.org/api/1.0/series/15022/revisions/1/mbox/ Test kms_force_connector_basic: Subgroup force-edid: pass -> DMESG-WARN (fi-snb-2520m) fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15 fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40 fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28 fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32 fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20 fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53 fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22 fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14 fi-skl-6700hqtotal:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21 fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21 fi-snb-2520m total:244 pass:211 dwarn:1 dfail:0 fail:0 skip:32 fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33 972b631c86ecf25d43d16b3617672f481a5cbd08 drm-intel-nightly: 2016y-11m-09d-10h-46m-28s UTC integration manifest 2b2fda9 drm/i915/gvt: Disable access to stolen memory as a guest == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2940/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
