[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: clean up aliasing_gtt_bind_vma
== Series Details == Series: drm/i915: clean up aliasing_gtt_bind_vma URL : https://patchwork.freedesktop.org/series/4815/ State : failure == Summary == Series 4815v1 drm/i915: clean up aliasing_gtt_bind_vma 2016-03-23T15:56:28.165993 http://patchwork.freedesktop.org/api/1.0/series/4815/revisions/1/mbox/ Applying: drm/i915: clean up aliasing_gtt_bind_vma Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_gem_gtt.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_gem_gtt.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_gem_gtt.c Patch failed at 0001 drm/i915: clean up aliasing_gtt_bind_vma ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Enabling 30-bit depth with Intel Graphics
[resending because my previous msg didn't get through] Hi devs, I would like to get 10-bit color depth working on my system for proper playback of HEVC Main10 profile. I'm writing some software to do this, but for initial test purposes I'm using readily available applications. So far I'm not able to get proper 10-bit color output. My system is an Intel NUC NUC5i7rYH (with Iris Graphics 6100) running Ubuntu 15.10 with Intel Graphics Installer 1.4.0. The output is HDMI to a Dell U3011 monitor and I also have an Astro VA-1838 HDMI Protocol Analyzer. After installation of the Intel Graphics Installer 1.4.0, I can confirm that the output now shows as HDMI 12-bit RGB @1920x1080p60 (using the Astro VA-1838). However, display of gradient test images and video clips that have 10-bit color depth or more, are either down sampled to 8-bit depth or dithered when using XVideo output (confirmed by reading pixel values using the Astro). These tests were done using combinations of Gimp 2.9.2, ImageMagick 6.8.9.9, VLC 2.2.1, ffmpeg 2.7.6, and x265 10-bit 1.9. I noticed that the xdpyinfo utility shows that the X server display only supports depths 24, 1 , 4, 8, 15, 16, and 32 bpp. I read online that a custom xorg.conf file can be created to force the default depth to 30 bpp. I tried this and it does then make xdpyinfo report support for 30 bpp, however it causes several issues, such as the Ubuntu Unity Plugin failing to start, VLC reporting that there is no available XVideo output adapter, and sluggish VLC playback with X11 video output. Furthermore VLC playback using the X11 video output is still down sampled to 8-bit. My questions are: - Is Intel Graphics for Linux supposed to support 10-bit color depth (30 bpp) in X? - If so, what do I need to do to enable it? - If not, can you clarify what is supported and provide some advice on how I can get 10-bit color output using Intel Graphics? Thanks, -Marvin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Tidy aliasing_gtt_bind_vma()
== Series Details == Series: drm/i915: Tidy aliasing_gtt_bind_vma() URL : https://patchwork.freedesktop.org/series/990/ State : failure == Summary == Series 990v1 drm/i915: Tidy aliasing_gtt_bind_vma() 2016-03-23T16:40:39.102374 http://patchwork.freedesktop.org/api/1.0/series/990/revisions/1/mbox/ Applying: drm/i915: Tidy aliasing_gtt_bind_vma() Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 drm/i915: Tidy aliasing_gtt_bind_vma() ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Rename GGTT init functions
On ke, 2016-03-23 at 18:02 +0200, Ville Syrjälä wrote: > On Wed, Mar 23, 2016 at 05:54:09PM +0200, Mika Kuoppala wrote: > > > > Ville Syrjälä writes: > > > > > > > > [ text/plain ] > > > On Wed, Mar 23, 2016 at 03:00:22PM +0200, Joonas Lahtinen wrote: > > > > > > > > Rename and document the GGTT init functions to give a better > > > > idea of the context where they are called from. > > > > > > > > i915_gem_gtt_init => i915_init_ggtt_hw > > > Seems to me i915_ggtt_init_hw would match existing practices better. > > > > > There is also some gravity towards putting the verb first. In gem > > side atleast. > At least in this case ggtt_init_hw would match ppgtt_init_hw, which > seems like a nice thing. > Right, I have changed the order quite a few times already. If it's i915_init_* (like i915_init_userptr), will be easier to grep. Adding Chris here as we discussed this yesterday. His idea is that logic should be action_feature and object_verb, init_some_thingamagic, vs object_destroy. Whatever we decide on, we should drop a small note at kerneldoc. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 174/190] drm/i915: Show context objects in debugfs/i915_gem_objects
On Mon, Jan 11, 2016 at 11:01:15AM +, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
With ring --> ringbuf, unless your s/ringbuf/ring/ patch is merged, obviously:
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 35 +++
> 1 file changed, 35 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 19b0d6a7680d..f8ca00ce986e 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -370,6 +370,40 @@ static void print_batch_pool_stats(struct seq_file *m,
> print_file_stats(m, "[k]batch pool", stats);
> }
>
> +static int per_file_ctx_stats(int id, void *ptr, void *data)
> +{
> + struct intel_context *ctx = ptr;
> + int n;
> +
> + for (n = 0; n < ARRAY_SIZE(ctx->engine); n++) {
> + if (ctx->engine[n].state)
> + per_file_stats(0, ctx->engine[n].state, data);
> + if (ctx->engine[n].ring)
> + per_file_stats(0, ctx->engine[n].ring->obj, data);
> + }
> +
> + return 0;
> +}
> +
> +static void print_context_stats(struct seq_file *m,
> + struct drm_i915_private *dev_priv)
> +{
> + struct file_stats stats;
> + struct drm_file *file;
> +
> + memset(&stats, 0, sizeof(stats));
> +
> + if (dev_priv->kernel_context)
> + per_file_ctx_stats(0, dev_priv->kernel_context, &stats);
> +
> + list_for_each_entry(file, &dev_priv->dev->filelist, lhead) {
> + struct drm_i915_file_private *fpriv = file->driver_priv;
> + idr_for_each(&fpriv->context_idr, per_file_ctx_stats, &stats);
> + }
> +
> + print_file_stats(m, "[k]contexts", stats);
> +}
> +
> #define count_vmas(list, member) do { \
> list_for_each_entry(vma, list, member) { \
> size += vma->size; \
> @@ -471,6 +505,7 @@ static int i915_gem_object_info(struct seq_file *m, void*
> data)
>
> seq_putc(m, '\n');
> print_batch_pool_stats(m, dev_priv);
> + print_context_stats(m, dev_priv);
> list_for_each_entry_reverse(file, &dev->filelist, lhead) {
> struct file_stats stats;
> struct drm_i915_file_private *file_priv = file->driver_priv;
> --
> 2.7.0.rc3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://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 2/2] drm/i915: Make pages of GFX allocations movable
On Wed, Mar 23, 2016 at 01:55:14PM +0530, Goel, Akash wrote:
>
>
> On 3/23/2016 1:28 PM, Chris Wilson wrote:
> >On Wed, Mar 23, 2016 at 11:39:44AM +0530, akash.g...@intel.com wrote:
> >>+#ifdef CONFIG_MIGRATION
> >>+static int i915_migratepage(struct address_space *mapping,
> >>+ struct page *newpage, struct page *page,
> >>+ enum migrate_mode mode, void *dev_priv_data)
> >
> >If we move this to i915_gem_shrink_migratepage (i.e. i915_gem_shrink),
> >we can
> >
> >>+ /*
> >>+* Use trylock here, with a timeout, for struct_mutex as
> >>+* otherwise there is a possibility of deadlock due to lock
> >>+* inversion. This path, which tries to migrate a particular
> >>+* page after locking that page, can race with a path which
> >>+* truncate/purge pages of the corresponding object (after
> >>+* acquiring struct_mutex). Since page truncation will also
> >>+* try to lock the page, a scenario of deadlock can arise.
> >>+*/
> >>+ while (!mutex_trylock(&dev->struct_mutex) && --timeout)
> >>+ schedule_timeout_killable(1);
> >
> >replace this with i915_gem_shrinker_lock() and like constructs with the
> >other shrinkers.
>
> fine, will rename the function to gem_shrink_migratepage, move it
> inside the gem_shrinker.c file, and use the existing constructs.
>
> > Any reason for dropping the early
> > if (!page_private(obj)) skip?
> >
>
> Would this sequence be fine ?
>
> if (!page_private(page))
> goto migrate; /*skip */
>
> Loop for locking mutex
>
> obj = (struct drm_i915_gem_object *)page_private(page);
>
> if (!PageSwapCache(page) && obj) {
Yes.
> >Similarly there are other patterns here that would benefit from
> >integration with existing shrinker logic. However, things like tidying
> >up the pin_display, unbinding, rpm lock inversion are still only on
> >list.
>
> Tidying, like split that one single if condition into multiple if,
> else if blocks ?
Just outstanding patches that simplify the condition and work we have to
do here.
-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 164/190] drm/i915: Move obj->dirty:1 to obj->flags
On Mon, Jan 11, 2016 at 11:01:05AM +, Chris Wilson wrote:
> The obj->dirty bit is a companion to the obj->active bits that were
> moved to the obj->flags bitmask. Since we also update this bit inside
> the i915_vma_move_to_active() hotpath, we can aide gcc by also moving
> the obj->dirty bit to obj->flags bitmask.
>
> Signed-off-by: Chris Wilson
Needs rebasing -- assuming such a rebase:
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
> drivers/gpu/drm/i915/i915_drv.h| 21 -
> drivers/gpu/drm/i915/i915_gem.c| 18 +-
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 3 +--
> drivers/gpu/drm/i915/i915_gem_userptr.c| 6 +++---
> drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
> drivers/gpu/drm/i915/intel_lrc.c | 2 +-
> 7 files changed, 36 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 558d79b63e6c..8a59630fe5fb 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -136,7 +136,7 @@ describe_obj(struct seq_file *m, struct
> drm_i915_gem_object *obj)
> seq_printf(m, "] %x %s%s%s",
> i915_gem_request_get_seqno(obj->last_write.request),
> i915_cache_level_str(to_i915(obj->base.dev),
> obj->cache_level),
> -obj->dirty ? " dirty" : "",
> +i915_gem_object_is_dirty(obj) ? " dirty" : "",
> obj->madv == I915_MADV_DONTNEED ? " purgeable" : "");
> if (obj->base.name)
> seq_printf(m, " (name: %d)", obj->base.name);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 62a024a7225b..d664a67cda7b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2058,7 +2058,8 @@ struct drm_i915_gem_object {
>* This is set if the object has been written to since last bound
>* to the GTT
>*/
> - unsigned int dirty:1;
> +#define I915_BO_DIRTY_SHIFT (I915_BO_ACTIVE_REF_SHIFT + 1)
> +#define I915_BO_DIRTY_BIT (1 << I915_BO_DIRTY_SHIFT)
>
> /**
>* Advice: are the backing pages purgeable?
> @@ -2189,6 +2190,24 @@ i915_gem_object_unset_active_reference(struct
> drm_i915_gem_object *obj)
> }
> void __i915_gem_object_release_unless_active(struct drm_i915_gem_object
> *obj);
>
> +static inline bool
> +i915_gem_object_is_dirty(const struct drm_i915_gem_object *obj)
> +{
> + return obj->flags & I915_BO_DIRTY_BIT;
> +}
> +
> +static inline void
> +i915_gem_object_set_dirty(struct drm_i915_gem_object *obj)
> +{
> + obj->flags |= I915_BO_DIRTY_BIT;
> +}
> +
> +static inline void
> +i915_gem_object_unset_dirty(struct drm_i915_gem_object *obj)
> +{
> + obj->flags &= ~I915_BO_DIRTY_BIT;
> +}
> +
> void i915_gem_track_fb(struct drm_i915_gem_object *old,
> struct drm_i915_gem_object *new,
> unsigned frontbuffer_bits);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 497b68849d09..5347469bbea1 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -209,9 +209,9 @@ i915_gem_object_put_pages_phys(struct drm_i915_gem_object
> *obj)
> }
>
> if (obj->madv == I915_MADV_DONTNEED)
> - obj->dirty = 0;
> + i915_gem_object_unset_dirty(obj);
>
> - if (obj->dirty) {
> + if (i915_gem_object_is_dirty(obj)) {
> struct address_space *mapping =
> file_inode(obj->base.filp)->i_mapping;
> char *vaddr = obj->phys_handle->vaddr;
> int i;
> @@ -235,7 +235,7 @@ i915_gem_object_put_pages_phys(struct drm_i915_gem_object
> *obj)
> page_cache_release(page);
> vaddr += PAGE_SIZE;
> }
> - obj->dirty = 0;
> + i915_gem_object_unset_dirty(obj);
> }
>
> sg_free_table(obj->pages);
> @@ -589,7 +589,7 @@ int i915_gem_obj_prepare_shmem_write(struct
> drm_i915_gem_object *obj,
>
> out:
> intel_fb_obj_invalidate(obj, ORIGIN_CPU);
> - obj->dirty = 1;
> + i915_gem_object_set_dirty(obj);
> /* return with the pages pinned */
> return 0;
>
> @@ -1836,12 +1836,12 @@ i915_gem_object_put_pages_gtt(struct
> drm_i915_gem_object *obj)
> i915_gem_object_save_bit_17_swizzle(obj);
>
> if (obj->madv == I915_MADV_DONTNEED)
> - obj->dirty = 0;
> + i915_gem_object_unset_dirty(obj);
>
> for_each_sg_page(obj->pages->sgl, &sg_iter, obj->pages->nents, 0) {
> struct page *page = sg_page_iter_page(&sg_iter);
>
> - if (obj->dirty)
> + if (i915_gem_object_is_dirty(obj))
> set_page_dirty(page);
>
> if (obj->madv == I915_MADV_WILLNEED)
> @@ -1849,7 +1849,7 @@
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Add support for EDID injection.
== Series Details == Series: drm: Add support for EDID injection. URL : https://patchwork.freedesktop.org/series/4818/ State : warning == Summary == Series 4818v1 drm: Add support for EDID injection. http://patchwork.freedesktop.org/api/1.0/series/4818/revisions/1/mbox/ Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) pass -> SKIP (hsw-gt2) Test pm_rpm: Subgroup basic-pci-d3-state: dmesg-warn -> PASS (bsw-nuc-2) pass -> DMESG-WARN (byt-nuc) Subgroup basic-rte: dmesg-warn -> PASS (byt-nuc) UNSTABLE bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:192 pass:155 dwarn:0 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:156 dwarn:1 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:174 dwarn:0 dfail:0 fail:0 skip:18 ilk-hp8440p total:192 pass:128 dwarn:1 dfail:0 fail:0 skip:63 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1697/ 8f2e9bbc15607f56261aefd7a1f8caf6909c6b9d drm-intel-nightly: 2016y-03m-23d-17h-03m-10s UTC integration manifest e0174c7b8c92e7b71b0db41fe86e6c91f5843486 drm: Add support for EDID injection. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Allow mmio updates on all platforms.
Op 23-03-16 om 16:07 schreef Ville Syrjälä:
> On Wed, Mar 23, 2016 at 02:24:30PM +0100, Maarten Lankhorst wrote:
>> Rename intel_unpin_work to intel_flip_work and use it for mmio flips
>> and unpinning. Use flip_queued_req to hold the wait request in the
>> mmio case and allow the vblank interrupt to complete mmio work to
>> have mmio flips run correctly on g4 and earlier.
> Before you actually go and trust drm_vblank_count() you should make it
> race free.
How about adding the below to the patch?
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index befac649aa96..05ec832e02de 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11224,12 +11224,11 @@ static void intel_mmio_flip_work_func(struct
work_struct *w)
false, false,
MAX_SCHEDULE_TIMEOUT) < 0);
- intel_pipe_update_start(crtc);
+ intel_pipe_update_start(crtc, work);
primary->update_plane(&primary->base,
crtc->config,
to_intel_plane_state(primary->base.state));
- atomic_set(&work->pending, INTEL_FLIP_PENDING);
- intel_pipe_update_end(crtc);
+ intel_pipe_update_end(crtc, work);
}
static int intel_default_queue_flip(struct drm_device *dev,
@@ -13800,7 +13799,7 @@ static void intel_begin_crtc_commit(struct drm_crtc
*crtc,
bool modeset = needs_modeset(crtc->state);
/* Perform vblank evasion around commit operation */
- intel_pipe_update_start(intel_crtc);
+ intel_pipe_update_start(intel_crtc, NULL);
if (modeset)
return;
@@ -13816,7 +13815,7 @@ static void intel_finish_crtc_commit(struct drm_crtc
*crtc,
{
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- intel_pipe_update_end(intel_crtc);
+ intel_pipe_update_end(intel_crtc, NULL);
}
/**
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cac368138764..86d486cfd778 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1604,8 +1604,8 @@ bool intel_sdvo_init(struct drm_device *dev,
int intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane);
int intel_sprite_set_colorkey(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-void intel_pipe_update_start(struct intel_crtc *crtc);
-void intel_pipe_update_end(struct intel_crtc *crtc);
+void intel_pipe_update_start(struct intel_crtc *crtc, struct intel_flip_work
*work);
+void intel_pipe_update_end(struct intel_crtc *crtc, struct intel_flip_work
*work);
/* intel_tv.c */
void intel_tv_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 8821533561b1..8da59a1eca56 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -78,7 +78,8 @@ static int usecs_to_scanlines(const struct drm_display_mode
*adjusted_mode,
* avoid random delays. The value written to @start_vbl_count should be
* supplied to intel_pipe_update_end() for error checking.
*/
-void intel_pipe_update_start(struct intel_crtc *crtc)
+void intel_pipe_update_start(struct intel_crtc *crtc,
+struct intel_flip_work *work)
{
struct drm_device *dev = crtc->base.dev;
const struct drm_display_mode *adjusted_mode =
&crtc->config->base.adjusted_mode;
@@ -142,6 +143,9 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
crtc->debug.start_vbl_count =
dev->driver->get_vblank_counter(dev, pipe);
+ if (work)
+ work->flip_queued_vblank = crtc->debug.start_vbl_count;
+
trace_i915_pipe_update_vblank_evaded(crtc);
}
@@ -154,7 +158,7 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
* re-enables interrupts and verifies the update was actually completed
* before a vblank using the value of @start_vbl_count.
*/
-void intel_pipe_update_end(struct intel_crtc *crtc)
+void intel_pipe_update_end(struct intel_crtc *crtc, struct intel_flip_work
*work)
{
struct drm_device *dev = crtc->base.dev;
enum pipe pipe = crtc->pipe;
@@ -162,6 +166,12 @@ void intel_pipe_update_end(struct intel_crtc *crtc)
u32 end_vbl_count = dev->driver->get_vblank_counter(dev, pipe);
ktime_t end_vbl_time = ktime_get();
+ if (work) {
+ work->flip_queued_vblank = end_vbl_count;
+ smp_mb__before_atomic();
+ atomic_set(&work->pending, INTEL_FLIP_PENDING);
+ }
+
trace_i915_pipe_update_end(crtc, end_vbl_count, scanline_end);
local_irq_enable();
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Fixes and worarounds for GuC issues (rev3)
== Series Details == Series: Fixes and worarounds for GuC issues (rev3) URL : https://patchwork.freedesktop.org/series/4694/ State : failure == Summary == Series 4694v3 Fixes and worarounds for GuC issues 2016-03-23T16:43:55.381802 http://patchwork.freedesktop.org/api/1.0/series/4694/revisions/3/mbox/ Applying: drm/i915/guc: Reset GuC and retry on firmware load failure Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/i915_reg.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_reg.h Auto-merging drivers/gpu/drm/i915/i915_drv.h CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_drv.h Patch failed at 0001 drm/i915/guc: Reset GuC and retry on firmware load failure ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Fixing i915/opregion issues with firmware which lists more then 8 output devices
On Wed, 23 Mar 2016, Nicolas Repentin wrote: > Thanks ;) > > I'm sorry, but do you have a "howto" for doing this? > > Not very familiar with patching things. This should get you started: http://kernelnewbies.org/KernelBuild HTH, Jani. > > Nicolas > > Le 23/03/2016 12:36, Jani Nikula a écrit : >> On Tue, 22 Mar 2016, Nicolas Repentin wrote: >>> I'm searching for a fix for thread >>> http://www.spinics.net/lists/intel-gfx/msg79628.html >>> >>> Does someone know how to ask the intel drm team to fix this issue? >> You just have. ;) >> >> Please try this patch series [1]. It's untested, but might >> help. Feedback appreciated. >> >> BR, >> Jani. >> >> >> [1] https://patchwork.freedesktop.org/series/4783/ >> -- 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 v2] drm/i915/bxt: Fix DSI HW state readout
On Wed, 23 Mar 2016, Imre Deak wrote:
> Currently the machine hangs during booting while accessing the
> BXT_MIPI_PORT_CTRL register during pipe HW state readout. After some
> experimentation I found that the hang is caused by the DSI PLL being
> disabled, or it being enabled but with an incorrect divider
> configuration. Enabling the PLL got rid of the boot problem, so fix
> this by checking the PLL enabled state/configuration before attempting
> to read out the HW state.
>
> The DSI_PLL_ENABLE register is in the always-on power well, while the
> BXT_DSI_PLL_CTL is in power well 0. This isn't exactly matched by the
> transcoder power domain, but what we really need is just a runtime PM
> reference, which is provided by any power domain.
>
> Ville also found this dependency specified in BSpec, so I added a
> reference to that too.
>
> v2:
> - Make sure we hold a power reference while accessing the PLL registers.
>
> CC: Shashank Sharma
> CC: Uma Shankar
> CC: Jani Nikula
> Fixes: c6c794a2fc5e ("drm/i915/bxt: Initialize MIPI DSI for BXT")
I figured this might blow something up now, but then again we needed to
do it to find out all the ways it would blow up. Apologies and
thanks. ;)
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> drivers/gpu/drm/i915/intel_display.c | 13 +
> drivers/gpu/drm/i915/intel_dsi.c | 9 +
> drivers/gpu/drm/i915/intel_dsi.h | 1 +
> drivers/gpu/drm/i915/intel_dsi_pll.c | 37
>
> 5 files changed, 62 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f3ba43c..c839ce9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7811,9 +7811,11 @@ enum skl_disp_power_wells {
> #define BXT_DSIC_16X_BY2(1 << 10)
> #define BXT_DSIC_16X_BY3(2 << 10)
> #define BXT_DSIC_16X_BY4(3 << 10)
> +#define BXT_DSIC_16X_MASK (3 << 10)
> #define BXT_DSIA_16X_BY2(1 << 8)
> #define BXT_DSIA_16X_BY3(2 << 8)
> #define BXT_DSIA_16X_BY4(3 << 8)
> +#define BXT_DSIA_16X_MASK (3 << 8)
> #define BXT_DSI_FREQ_SEL_SHIFT 8
> #define BXT_DSI_FREQ_SEL_MASK (0xF << BXT_DSI_FREQ_SEL_SHIFT)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 009b03b..6fd94c4 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -36,6 +36,7 @@
> #include "intel_drv.h"
> #include
> #include "i915_drv.h"
> +#include "intel_dsi.h"
> #include "i915_trace.h"
> #include
> #include
> @@ -9852,10 +9853,12 @@ static bool bxt_get_dsi_transcoder_state(struct
> intel_crtc *crtc,
> enum intel_display_power_domain power_domain;
> enum port port;
> enum transcoder cpu_transcoder;
> + bool pll_enabled;
> u32 tmp;
>
> pipe_config->has_dsi_encoder = false;
>
> + pll_enabled = false;
It seems to me you could just bail out early here if the dsi pll is
disabled.
I'm guessing you put the check in the loop because of the power domain
reference. Two thoughts on that:
a) BXT_DSI_PLL_ENABLE is in always on power. If you dropped the paranoia
in bxt_dsi_pll_is_enabled() about valid BXT_DSI_PLL_CTL values, you
could simplify code here and in intel_dsi_get_hw_state().
b) BXT_DSI_PLL_CTL is in PG0. Here, you implicitly trust the transcoder
power domain to match that. In intel_dsi_get_hw_state() you implicitly
trust the DSI port power domain to match that. They both do, but this
seems a somewhat coincidental choice.
> for_each_port_masked(port, BIT(PORT_A) | BIT(PORT_C)) {
> if (port == PORT_A)
> cpu_transcoder = TRANSCODER_DSI_A;
> @@ -9867,6 +9870,16 @@ static bool bxt_get_dsi_transcoder_state(struct
> intel_crtc *crtc,
> continue;
> *power_domain_mask |= BIT(power_domain);
>
> + /*
> + * The PLL needs to be enabled with a valid divider
> + * configuration, otherwise accessing DSI registers will hang
> + * the machine. See BSpec North Display Engine
> + * registers/MIPI[BXT].
> + */
> + pll_enabled = pll_enabled || intel_dsi_pll_is_enabled(dev_priv);
> + if (!pll_enabled)
> + break;
> +
I guess if we want to keep the paranoia and we are happy with how the
power domain references map to the power well of BXT_DSI_PLL_CTL, the
simplest you could do is throw away the local variable and just do this:
if (!intel_dsi_pll_is_enabled(dev_priv))
continue;
This potentially leads to an extra loop here, but at least the code gets
simpler and easier to grasp.
> /* XXX: this works for video mode only */
> tmp = I915_READ(BXT_MIPI_
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: fix potential dangling else problems in for_each_ macros (rev3)
== Series Details == Series: drm/i915: fix potential dangling else problems in for_each_ macros (rev3) URL : https://patchwork.freedesktop.org/series/1142/ State : failure == Summary == Series 1142v3 drm/i915: fix potential dangling else problems in for_each_ macros http://patchwork.freedesktop.org/api/1.0/series/1142/revisions/3/mbox/ Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (snb-x220t) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: dmesg-warn -> PASS (bsw-nuc-2) pass -> DMESG-WARN (byt-nuc) Subgroup basic-rte: dmesg-warn -> PASS (byt-nuc) UNSTABLE bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:192 pass:155 dwarn:0 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:156 dwarn:1 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:192 pass:129 dwarn:0 dfail:0 fail:0 skip:63 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:192 pass:181 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:157 dwarn:0 dfail:0 fail:2 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1699/ 8f2e9bbc15607f56261aefd7a1f8caf6909c6b9d drm-intel-nightly: 2016y-03m-23d-17h-03m-10s UTC integration manifest c4613575f37039f81f8969a4e805a80ff0a64ef9 drm/i915: replace for_each_engine() 31beb6168bc53ad8b3fe008dcaa2ae038743a252 drm/i915: introduce for_each_engine_id() ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: CABC support for backlight control
In CABC (Content Adaptive Brightness Control) content grey level
scale can be increased while simultaneously decreasing
brightness of the backlight to achieve same perceived brightness.
The CABC is not standardized and panel vendors are free to follow
their implementation. The CABC implementaion here assumes that the
panels use standard SW register for control.
In this design there will be no PWM signal from the SoC and DCS
commands are sent to enable and control the backlight brightness.
v2: Moving the CABC bkl functions to new file.(Jani)
v3: Rebase
v4: Rebase
v5: Use mipi_dsi_dcs_write() instead of mipi_dsi_dcs_write_buffer() (Jani)
Move DCS macro`s to include/video/mipi_display.h (Jani)
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Yetunde Adebisi
Signed-off-by: Deepak M
---
The DCS command macro`s are defined in the patch which is posted in the
dri-devel list.
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_dsi.c | 19 -
drivers/gpu/drm/i915/intel_dsi.h | 4 +
drivers/gpu/drm/i915/intel_dsi_cabc.c | 154 ++
drivers/gpu/drm/i915/intel_panel.c| 4 +
7 files changed, 182 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_dsi_cabc.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7ffb51b..065c410 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -83,6 +83,7 @@ i915-y += dvo_ch7017.o \
intel_dp_mst.o \
intel_dp.o \
intel_dsi.o \
+ intel_dsi_cabc.o \
intel_dsi_panel_vbt.o \
intel_dsi_pll.o \
intel_dvo.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 050d860..9ed60f8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3489,7 +3489,6 @@ void intel_sbi_write(struct drm_i915_private *dev_priv,
u16 reg, u32 value,
enum intel_sbi_destination destination);
u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
-
int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c87b450..9e49396 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1325,6 +1325,8 @@ void intel_dp_mst_encoder_cleanup(struct
intel_digital_port *intel_dig_port);
/* intel_dsi.c */
void intel_dsi_init(struct drm_device *dev);
+/* intel_dsi_cabc.c */
+int intel_dsi_cabc_init_backlight_funcs(struct intel_connector
*intel_connector);
/* intel_dvo.c */
void intel_dvo_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 456676c..7aa707f 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1209,10 +1209,25 @@ void intel_dsi_init(struct drm_device *dev)
else
intel_encoder->crtc_mask = BIT(PIPE_B);
- if (dev_priv->vbt.dsi.config->dual_link)
+ if (dev_priv->vbt.dsi.config->dual_link) {
intel_dsi->ports = BIT(PORT_A) | BIT(PORT_C);
- else
+ switch (dev_priv->vbt.dsi.config->dl_cabc_port) {
+ case CABC_PORT_A:
+ intel_dsi->bkl_dcs_ports = BIT(PORT_A);
+ break;
+ case CABC_PORT_C:
+ intel_dsi->bkl_dcs_ports = BIT(PORT_C);
+ break;
+ case CABC_PORT_A_AND_C:
+ intel_dsi->bkl_dcs_ports = BIT(PORT_A) | BIT(PORT_C);
+ break;
+ default:
+ DRM_ERROR("Unknown MIPI ports for sending DCS\n");
+ }
+ } else {
intel_dsi->ports = BIT(port);
+ intel_dsi->bkl_dcs_ports = BIT(port);
+ }
/* Create a DSI host (and a device) for each port. */
for_each_dsi_port(port, intel_dsi->ports) {
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 0e758f1..5c07d59 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -34,6 +34,10 @@
#define DSI_DUAL_LINK_FRONT_BACK 1
#define DSI_DUAL_LINK_PIXEL_ALT2
+#define CABC_PORT_A 0x00
+#define CABC_PORT_C 0x01
+#define CABC_PORT_A_AND_C 0x02
+
struct intel_dsi_host;
struct intel_dsi {
diff --git a/drivers/gpu/drm/i915/intel_dsi_cabc.c
b/drivers/gpu/drm/i915/intel_dsi_cabc.c
new file mode 100644
index 000..230ee4f
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dsi_cabc.c
@@ -0,0 +1,154 @@
+/*
+ * Copyright © 2016 Inte
[Intel-gfx] [PATCH 1/2] drm/i915: Parsing the PWM cntrl and CABC ON/OFF fileds in VBT
For dual link panel scenarios there are new fileds added in the
VBT which indicate on which port the PWM cntrl and CABC ON/OFF
commands needs to be sent.
v2: Moving the comment to intel_dsi.h(Jani)
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Yetunde Adebisi
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/intel_bios.c | 10 ++
drivers/gpu/drm/i915/intel_bios.h | 5 -
drivers/gpu/drm/i915/intel_dsi.h | 9 +
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 083003b..587c06f 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -749,6 +749,16 @@ parse_mipi_config(struct drm_i915_private *dev_priv,
return;
}
+ /*
+* These fileds are introduced from the VBT version 197 onwards,
+* so making sure that these bits are set zero in the pervious
+* versions.
+*/
+ if (dev_priv->vbt.dsi.config->dual_link && bdb->version < 197) {
+ dev_priv->vbt.dsi.config->dl_cabc_port = 0;
+ dev_priv->vbt.dsi.config->pwm_bkl_ctrl = 0;
+ }
+
/* We have mandatory mipi config blocks. Initialize as generic panel */
dev_priv->vbt.dsi.panel_id = MIPI_DSI_GENERIC_PANEL_ID;
}
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index ab0ea31..7a89f79 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -113,7 +113,10 @@ struct mipi_config {
u16 dual_link:2;
u16 lane_cnt:2;
u16 pixel_overlap:3;
- u16 rsvd3:9;
+ u16 rgb_flip:1;
+ u16 dl_cabc_port:2;
+ u16 pwm_bkl_ctrl:2;
+ u16 rsvd3:4;
u16 rsvd4;
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index e582ef8..0e758f1 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -78,6 +78,15 @@ struct intel_dsi {
u8 escape_clk_div;
u8 dual_link;
+
+ /*
+* Below field will inform us on which port the panel blk_cntrl
+* and CABC ON/OFF commands needs to be sent in case of dual link
+* panels
+*/
+ u8 bkl_dcs_ports;
+ u8 pwm_blk_ctrl;
+
u8 pixel_overlap;
u32 port_bits;
u32 bw_timer;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [intelddx] v2.99.917-580-gf656f6afa288: sh: 1: ACLOCAL_FLAGS: not found
[ build-script, build and config logs attached ] Hi Chris, I am just seeing this (or noticed for the first time, here on Ubuntu/precise AMD64)... $ zgrep -A1 -B1 ACLOCAL_FLAGS: build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt.gz autoreconf: running: aclocal $(ACLOCAL_FLAGS) -I m4 sh: 1: ACLOCAL_FLAGS: not found autoreconf: configure.ac: tracing -- libtoolize: copying file `m4/lt~obsolete.m4' sh: 1: ACLOCAL_FLAGS: not found autoreconf: running: /usr/bin/autoconf What does this mean and it is ignore-able? Thanks. Regards, - Sedat - P.S.: autoconf version mumbo-jumbo $ dpkg -S /usr/bin/autoconf autoconf: /usr/bin/autoconf $ dpkg -l | grep autoconf ii autoconf2.68-1ubuntu2 automatic configure script builder - EOT - build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt.gz Description: GNU Zip compressed data config.log.gz Description: GNU Zip compressed data build_xf86-video-intel-with-llvm.sh Description: Bourne shell script ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC] drm/i915: Move execlists irq handler to a bottom half
On 23/03/16 15:23, Tvrtko Ursulin wrote: On 23/03/16 12:56, Chris Wilson wrote: On Wed, Mar 23, 2016 at 12:46:35PM +, Tvrtko Ursulin wrote: On 23/03/16 11:31, Chris Wilson wrote: On Wed, Mar 23, 2016 at 10:08:46AM +, Tvrtko Ursulin wrote: You think it is OK to continue sharing your one, https://bugs.freedesktop.org/show_bug.cgi?id=93467? Yes, it fixes the same freeze (and we've removed the loop from chv irq so there really shouldn't be any others left!) I don't see that has been merged. Is it all ready CI wise so we could? On the CI ping: id:20160314103014.30028.12...@emeril.freedesktop.org == Summary == Series 4298v3 drm/i915: Exit cherryview_irq_handler() after one pass http://patchwork.freedesktop.org/api/1.0/series/4298/revisions/3/mbox/ Test drv_module_reload_basic: pass -> SKIP (skl-i5k-2) pass -> INCOMPLETE (bsw-nuc-2) Test gem_ringfill: Subgroup basic-default-s3: dmesg-warn -> PASS (bsw-nuc-2) Test gem_tiled_pread_basic: incomplete -> PASS (byt-nuc) Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (bdw-ultra) Subgroup basic-flip-vs-modeset: incomplete -> PASS (bsw-nuc-2) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: incomplete -> PASS (hsw-gt2) Test pm_rpm: Subgroup basic-pci-d3-state: dmesg-warn -> PASS (bsw-nuc-2) bdw-nuci7total:194 pass:182 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:194 pass:173 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:189 pass:151 dwarn:0 dfail:0 fail:0 skip:37 byt-nuc total:194 pass:154 dwarn:4 dfail:0 fail:1 skip:35 hsw-brixbox total:194 pass:172 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:194 pass:176 dwarn:1 dfail:0 fail:0 skip:17 ivb-t430stotal:194 pass:169 dwarn:0 dfail:0 fail:0 skip:25 skl-i5k-2total:194 pass:170 dwarn:0 dfail:0 fail:0 skip:24 skl-i7k-2total:194 pass:171 dwarn:0 dfail:0 fail:0 skip:23 snb-dellxps total:194 pass:159 dwarn:1 dfail:0 fail:0 skip:34 snb-x220ttotal:194 pass:159 dwarn:1 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1589/ 3e5ecc8c5ff80cb1fb635ce1cf16b7cd4cfb1979 drm-intel-nightly: 2016y-03m-14d-09h-06m-00s UTC integration manifest 7928c2133b16eb2f26866ca05d1cb7bb6d41c765 drm/i915: Exit cherryview_irq_handler() after one pass == drv_module_reload_basic is weird, but it appears the hiccup CI had on the previous run were external (and affected several CI runs afaict). That part is goog then, but I am not sure what to do with the incomplete run. Maybe have it do another one? Although that is quite weak. Problem is it has no other hangs with that test in the history. goog yes :) I got a bsw-nuc2 hang in results yesterday for a series which I don't think could really have caused it. So I think there might be something really wrong either with that machine or with the driver reload on chv/bsw in general. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2 RESEND] drm/dp_helper: add workarounds from intel_dp_dpcd_read_wake()
On Wed, 23 Mar 2016, Lyude wrote:
> Some sinks need some time during the process of resuming the system from
> sleep before they're ready to handle transactions. While it would be
> nice if they responded with NACKs in these scenarios, this isn't always
> the case as a few sinks will just timeout on all of the transactions
> they receive.
>
> This patch was originally intended to be a workaround for a very
> mysterious bug on the T560, where any monitors connected to the dock
> would fail to turn back on after resume. When resuming the laptop, it
> appears that there's a short period of time where we're unable to
> complete any aux transactions, as they all immediately timeout. The only
> machine I'm able to reproduce this on is the T560 as other production
> Skylake models seem to be fine. The period during which AUX transactions
> fail appears to be around 22ms long. AFAIK, the dock for the T560 never
> actually turns off, the only difference is that it's in SST mode at the
> start of the resume process, so it's unclear as to why it would need so
> much time to come back up.
>
> There's been a discussion on this issue going on for a while on the
> intel-gfx mailing list about this that has, in addition to including
> developers from Intel, also had the correspondence of one of the
> hardware engineers for Intel:
>
> http://www.spinics.net/lists/intel-gfx/msg88831.html
> http://www.spinics.net/lists/intel-gfx/msg88410.html
>
> We've already looked into a couple of possible explanations for the
> problem:
>
> - Calling intel_dp_mst_resume() before right fix.
> intel_runtime_pm_enable_interrupts(). This was the first fix I tried,
> and while it worked it definitely wasn't the right fix. This worked
> because DP aux transactions don't actually require interrupts to work:
>
> static uint32_t
> intel_dp_aux_wait_done(struct intel_dp *intel_dp, bool has_aux_irq)
> {
> struct intel_digital_port *intel_dig_port =
> dp_to_dig_port(intel_dp);
> struct drm_device *dev = intel_dig_port->base.base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> i915_reg_t ch_ctl = intel_dp->aux_ch_ctl_reg;
> uint32_t status;
> bool done;
>
> #define C (((status = I915_READ_NOTRACE(ch_ctl)) &
> DP_AUX_CH_CTL_SEND_BUSY) == 0)
> if (has_aux_irq)
> done = wait_event_timeout(dev_priv->gmbus_wait_queue, C,
> msecs_to_jiffies_timeout(10));
> else
> done = wait_for_atomic(C, 10) == 0;
> if (!done)
> DRM_ERROR("dp aux hw did not signal timeout (has irq:
> %i)!\n",
> has_aux_irq);
> #undef C
>
> return status;
> }
>
> When there's no interrupts enabled, we end up timing out on the
> wait_event_timeout() call, which causes us to check the DP status
> register once to see if the transaction was successful or not. Since
> this adds a 10ms delay to each aux transaction, it ends up adding a
> long enough delay to the resume process for aux transactions to become
> functional again. This gave us the illusion that enabling interrupts
> had something to do with making things work again, and put me on the
> wrong track for a while.
>
> - Interrupts occurring when we try to perform the aux transactions
> required to put the dock back into MST mode. This isn't the problem,
> as the only interrupts I've observed that come during this timeout
> period are from the snd_hda_intel driver, and disabling that driver
> doesn't appear to change the behavior at all.
>
> - Skylake's PSR block causing issues by performing aux transactions
> while we try to bring the dock out of MST mode. Disabling PSR through
> i915's command line options doesn't seem to change the behavior
> either, nor does preventing the DMC firmware from being loaded.
>
> Since this investigation went on for about 2 weeks, we decided it would
> be better for the time being to just workaround this issue until we find
> a better fix. This patch adds some behavior we want in
> drm_dp_dpcd_access() anyway, since DP aux transactions aren't exactly
> robust and this will probably fix quite a few other issues with DP MST
> hardware not responding in time. Plus, this is something we already do
> in the i915 driver with intel_dp_dpcd_read_wake(), except that that
> function is somewhat of a hack and DRM helpers can't make use of it.
>
> Changes since v2
> - Reworked the patch again to incorporate all of the behavior of
> intel_dp_dpcd_read_wake() into drm_dp_dpcd_read() and
> drm_dp_dpcd_access()
>
> Changes since v1
>
> - Patch has been reworked to take the retry logic out of
> intel_dp_mst_resume() and into drm_dp_dpcd_access(), based off a
> suggestion from Daniel Vetter
>
Re: [Intel-gfx] [PATCH 2/2] drm/i915: CABC support for backlight control
On Thu, 24 Mar 2016, Deepak M wrote:
> [ text/plain ]
> In CABC (Content Adaptive Brightness Control) content grey level
> scale can be increased while simultaneously decreasing
> brightness of the backlight to achieve same perceived brightness.
>
> The CABC is not standardized and panel vendors are free to follow
> their implementation. The CABC implementaion here assumes that the
> panels use standard SW register for control.
>
> In this design there will be no PWM signal from the SoC and DCS
> commands are sent to enable and control the backlight brightness.
>
> v2: Moving the CABC bkl functions to new file.(Jani)
>
> v3: Rebase
>
> v4: Rebase
>
> v5: Use mipi_dsi_dcs_write() instead of mipi_dsi_dcs_write_buffer() (Jani)
> Move DCS macro`s to include/video/mipi_display.h (Jani)
Where's the patch actually adding the macros? We need that in the same
series to have CI actually build and run this; this fails without them.
BR,
Jani.
>
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Yetunde Adebisi
> Signed-off-by: Deepak M
> ---
>
> The DCS command macro`s are defined in the patch which is posted in the
> dri-devel list.
>
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/i915_drv.h | 1 -
> drivers/gpu/drm/i915/intel_drv.h | 2 +
> drivers/gpu/drm/i915/intel_dsi.c | 19 -
> drivers/gpu/drm/i915/intel_dsi.h | 4 +
> drivers/gpu/drm/i915/intel_dsi_cabc.c | 154
> ++
> drivers/gpu/drm/i915/intel_panel.c| 4 +
> 7 files changed, 182 insertions(+), 3 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/intel_dsi_cabc.c
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 7ffb51b..065c410 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -83,6 +83,7 @@ i915-y += dvo_ch7017.o \
> intel_dp_mst.o \
> intel_dp.o \
> intel_dsi.o \
> + intel_dsi_cabc.o \
> intel_dsi_panel_vbt.o \
> intel_dsi_pll.o \
> intel_dvo.o \
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 050d860..9ed60f8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3489,7 +3489,6 @@ void intel_sbi_write(struct drm_i915_private *dev_priv,
> u16 reg, u32 value,
>enum intel_sbi_destination destination);
> u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
> void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
> -
> int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
> int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index c87b450..9e49396 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1325,6 +1325,8 @@ void intel_dp_mst_encoder_cleanup(struct
> intel_digital_port *intel_dig_port);
> /* intel_dsi.c */
> void intel_dsi_init(struct drm_device *dev);
>
> +/* intel_dsi_cabc.c */
> +int intel_dsi_cabc_init_backlight_funcs(struct intel_connector
> *intel_connector);
>
> /* intel_dvo.c */
> void intel_dvo_init(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 456676c..7aa707f 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1209,10 +1209,25 @@ void intel_dsi_init(struct drm_device *dev)
> else
> intel_encoder->crtc_mask = BIT(PIPE_B);
>
> - if (dev_priv->vbt.dsi.config->dual_link)
> + if (dev_priv->vbt.dsi.config->dual_link) {
> intel_dsi->ports = BIT(PORT_A) | BIT(PORT_C);
> - else
> + switch (dev_priv->vbt.dsi.config->dl_cabc_port) {
> + case CABC_PORT_A:
> + intel_dsi->bkl_dcs_ports = BIT(PORT_A);
> + break;
> + case CABC_PORT_C:
> + intel_dsi->bkl_dcs_ports = BIT(PORT_C);
> + break;
> + case CABC_PORT_A_AND_C:
> + intel_dsi->bkl_dcs_ports = BIT(PORT_A) | BIT(PORT_C);
> + break;
> + default:
> + DRM_ERROR("Unknown MIPI ports for sending DCS\n");
> + }
> + } else {
> intel_dsi->ports = BIT(port);
> + intel_dsi->bkl_dcs_ports = BIT(port);
> + }
>
> /* Create a DSI host (and a device) for each port. */
> for_each_dsi_port(port, intel_dsi->ports) {
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index 0e758f1..5c07d59 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -34,6 +34,10 @@
> #define DSI_DUAL_LINK_FRONT_BACK 1
> #define DSI_DUAL_LINK_PIXEL_ALT 2
>
> +#define CABC_PORT_A 0x
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Remove impossibe checks from i915_gem_request_add_to_client
On 23/03/16 15:31, Chris Wilson wrote: On Wed, Mar 23, 2016 at 03:15:03PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin There is only one caller of this functions which calls it under strictly defined conditions. Error checking and return value can be removed. Signed-off-by: Tvrtko Ursulin --- BTW it looks like the whole point of this request list is to implement the throttle ioctl? Looks like a strange ioctl with a fixed 20ms criteria, could it be re-implemented somehow without having to have this list? Does it have to be per-client or could it wait for any requests on any engine emitted 20ms ago? It is per-client, and I long wished the 20ms wasn't defined by the ABI. Is it useful and/or widely used though? With multiple clients submitting work I don't see the semantics are deterministic. I was thinking if it could be replaced with a simpler implementation for the similar random effect, losing the list altogether? Especially wonder how the scheduler will affect it. What I proposed doing is this: https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=breadcrumbs&id=e33947505b54582964c8c202b22f88fc5705f484 How is it safe? list_add modifies various pointers in multiple steps so I didn't know that is safe against concurrent iteration. RCU flavoured list API can do such things but in this case switching to that would only enable lockless throttle and not gain anything on the add_to_client path. Please note that this also fixes a race condition I've seen in the wild. What is the race? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [intelddx] v2.99.917-580-gf656f6afa288: sh: 1: ACLOCAL_FLAGS: not found
On Thu, Mar 24, 2016 at 10:34:58AM +0100, Sedat Dilek wrote: > [ build-script, build and config logs attached ] > > Hi Chris, > > I am just seeing this (or noticed for the first time, here on > Ubuntu/precise AMD64)... > > $ zgrep -A1 -B1 ACLOCAL_FLAGS: > build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt.gz > autoreconf: running: aclocal $(ACLOCAL_FLAGS) -I m4 > sh: 1: ACLOCAL_FLAGS: not found > autoreconf: configure.ac: tracing > -- > libtoolize: copying file `m4/lt~obsolete.m4' > sh: 1: ACLOCAL_FLAGS: not found > autoreconf: running: /usr/bin/autoconf > > What does this mean and it is ignore-able? libtool vs automake. Haven't found the right fix yet. If you want to locally patch s/$(ACLOCAL_FLAGS)// that'll do the trick. I think that's what we'll have to do :| -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] [intelddx] v2.99.917-580-gf656f6afa288: sh: 1: ACLOCAL_FLAGS: not found
On Thu, Mar 24, 2016 at 10:54 AM, Chris Wilson wrote: > On Thu, Mar 24, 2016 at 10:34:58AM +0100, Sedat Dilek wrote: >> [ build-script, build and config logs attached ] >> >> Hi Chris, >> >> I am just seeing this (or noticed for the first time, here on >> Ubuntu/precise AMD64)... >> >> $ zgrep -A1 -B1 ACLOCAL_FLAGS: >> build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt.gz >> autoreconf: running: aclocal $(ACLOCAL_FLAGS) -I m4 >> sh: 1: ACLOCAL_FLAGS: not found >> autoreconf: configure.ac: tracing >> -- >> libtoolize: copying file `m4/lt~obsolete.m4' >> sh: 1: ACLOCAL_FLAGS: not found >> autoreconf: running: /usr/bin/autoconf >> >> What does this mean and it is ignore-able? > > libtool vs automake. Haven't found the right fix yet. > > If you want to locally patch s/$(ACLOCAL_FLAGS)// that'll do the trick. > I think that's what we'll have to do :| As usual a fast reply - Thanks. If you have a fix, I will try it. - Sedat - ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/bxt: Fix DSI HW state readout
On to, 2016-03-24 at 11:15 +0200, Jani Nikula wrote:
> On Wed, 23 Mar 2016, Imre Deak wrote:
> > Currently the machine hangs during booting while accessing the
> > BXT_MIPI_PORT_CTRL register during pipe HW state readout. After
> > some
> > experimentation I found that the hang is caused by the DSI PLL
> > being
> > disabled, or it being enabled but with an incorrect divider
> > configuration. Enabling the PLL got rid of the boot problem, so fix
> > this by checking the PLL enabled state/configuration before
> > attempting
> > to read out the HW state.
> >
> > The DSI_PLL_ENABLE register is in the always-on power well, while
> > the
> > BXT_DSI_PLL_CTL is in power well 0. This isn't exactly matched by
> > the
> > transcoder power domain, but what we really need is just a runtime
> > PM
> > reference, which is provided by any power domain.
> >
> > Ville also found this dependency specified in BSpec, so I added a
> > reference to that too.
> >
> > v2:
> > - Make sure we hold a power reference while accessing the PLL
> > registers.
> >
> > CC: Shashank Sharma
> > CC: Uma Shankar
> > CC: Jani Nikula
> > Fixes: c6c794a2fc5e ("drm/i915/bxt: Initialize MIPI DSI for BXT")
>
> I figured this might blow something up now, but then again we needed
> to
> do it to find out all the ways it would blow up. Apologies and
> thanks. ;)
>
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 2 ++
> > drivers/gpu/drm/i915/intel_display.c | 13 +
> > drivers/gpu/drm/i915/intel_dsi.c | 9 +
> > drivers/gpu/drm/i915/intel_dsi.h | 1 +
> > drivers/gpu/drm/i915/intel_dsi_pll.c | 37
> >
> > 5 files changed, 62 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index f3ba43c..c839ce9 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7811,9 +7811,11 @@ enum skl_disp_power_wells {
> > #define BXT_DSIC_16X_BY2 (1 << 10)
> > #define BXT_DSIC_16X_BY3 (2 << 10)
> > #define BXT_DSIC_16X_BY4 (3 << 10)
> > +#define BXT_DSIC_16X_MASK (3 << 10)
> > #define BXT_DSIA_16X_BY2 (1 << 8)
> > #define BXT_DSIA_16X_BY3 (2 << 8)
> > #define BXT_DSIA_16X_BY4 (3 << 8)
> > +#define BXT_DSIA_16X_MASK (3 << 8)
> > #define BXT_DSI_FREQ_SEL_SHIFT8
> > #define BXT_DSI_FREQ_SEL_MASK (0xF <<
> > BXT_DSI_FREQ_SEL_SHIFT)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 009b03b..6fd94c4 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -36,6 +36,7 @@
> > #include "intel_drv.h"
> > #include
> > #include "i915_drv.h"
> > +#include "intel_dsi.h"
> > #include "i915_trace.h"
> > #include
> > #include
> > @@ -9852,10 +9853,12 @@ static bool
> > bxt_get_dsi_transcoder_state(struct intel_crtc *crtc,
> > enum intel_display_power_domain power_domain;
> > enum port port;
> > enum transcoder cpu_transcoder;
> > + bool pll_enabled;
> > u32 tmp;
> >
> > pipe_config->has_dsi_encoder = false;
> >
> > + pll_enabled = false;
>
> It seems to me you could just bail out early here if the dsi pll is
> disabled.
>
> I'm guessing you put the check in the loop because of the power
> domain reference.
Yes.
> Two thoughts on that:
>
> a) BXT_DSI_PLL_ENABLE is in always on power.
Well, that means always-on, whenever the PCI device is on, that is we
still need to hold a runtime PM reference, which is provided by any
display power domain reference.
> If you dropped the paranoia
> in bxt_dsi_pll_is_enabled() about valid BXT_DSI_PLL_CTL values, you
> could simplify code here and in intel_dsi_get_hw_state().
I think it's better to check the dividers too. If the dividers are
incorrect that machine will hang even though the PLL is enabled. Ville
told me that he saw a similar misconfiguration by BIOS on CHV/VLV, so
it's not unimaginable that it could also happen on BXT.
> b) BXT_DSI_PLL_CTL is in PG0. Here, you implicitly trust the
> transcoder
> power domain to match that. In intel_dsi_get_hw_state() you
> implicitly
> trust the DSI port power domain to match that. They both do, but this
> seems a somewhat coincidental choice.
I'm actually not sure if power well 0 is simply the same as the always-
on well, there is no separate always-on well shown in BSpec "Broxton
Display Connections". In any case we don't handle either of these
wells manually (on-demand), it's only during runtime suspend when they
are powered off. So to keep them on we need a runtime PM reference and
that is guaranteed to be provided by any power domain ref.
> > for_each_port_masked(port, BIT(PORT_A) | BIT(PORT_C)) {
> > if (port == PORT_A)
> > cpu_transcoder = TRANSCODER_DSI_A;
> > @@ -9867,6 +9870,16 @@ s
[Intel-gfx] [PATCH 2/3] drm/i915: Parsing the PWM cntrl and CABC ON/OFF fileds in VBT
For dual link panel scenarios there are new fileds added in the
VBT which indicate on which port the PWM cntrl and CABC ON/OFF
commands needs to be sent.
v2: Moving the comment to intel_dsi.h(Jani)
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Yetunde Adebisi
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/intel_bios.c | 10 ++
drivers/gpu/drm/i915/intel_bios.h | 5 -
drivers/gpu/drm/i915/intel_dsi.h | 9 +
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 083003b..587c06f 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -749,6 +749,16 @@ parse_mipi_config(struct drm_i915_private *dev_priv,
return;
}
+ /*
+* These fileds are introduced from the VBT version 197 onwards,
+* so making sure that these bits are set zero in the pervious
+* versions.
+*/
+ if (dev_priv->vbt.dsi.config->dual_link && bdb->version < 197) {
+ dev_priv->vbt.dsi.config->dl_cabc_port = 0;
+ dev_priv->vbt.dsi.config->pwm_bkl_ctrl = 0;
+ }
+
/* We have mandatory mipi config blocks. Initialize as generic panel */
dev_priv->vbt.dsi.panel_id = MIPI_DSI_GENERIC_PANEL_ID;
}
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index ab0ea31..7a89f79 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -113,7 +113,10 @@ struct mipi_config {
u16 dual_link:2;
u16 lane_cnt:2;
u16 pixel_overlap:3;
- u16 rsvd3:9;
+ u16 rgb_flip:1;
+ u16 dl_cabc_port:2;
+ u16 pwm_bkl_ctrl:2;
+ u16 rsvd3:4;
u16 rsvd4;
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index e582ef8..0e758f1 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -78,6 +78,15 @@ struct intel_dsi {
u8 escape_clk_div;
u8 dual_link;
+
+ /*
+* Below field will inform us on which port the panel blk_cntrl
+* and CABC ON/OFF commands needs to be sent in case of dual link
+* panels
+*/
+ u8 bkl_dcs_ports;
+ u8 pwm_blk_ctrl;
+
u8 pixel_overlap;
u32 port_bits;
u32 bw_timer;
--
1.9.1
___
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: CABC support for backlight control
> -Original Message-
> From: Nikula, Jani
> Sent: Thursday, March 24, 2016 3:11 PM
> To: Deepak, M ; intel-gfx@lists.freedesktop.org
> Cc: Deepak, M ; Vetter, Daniel
> ; Adebisi, YetundeX
>
> Subject: Re: [PATCH 2/2] drm/i915: CABC support for backlight control
>
> On Thu, 24 Mar 2016, Deepak M wrote:
> > [ text/plain ]
> > In CABC (Content Adaptive Brightness Control) content grey level scale
> > can be increased while simultaneously decreasing brightness of the
> > backlight to achieve same perceived brightness.
> >
> > The CABC is not standardized and panel vendors are free to follow
> > their implementation. The CABC implementaion here assumes that the
> > panels use standard SW register for control.
> >
> > In this design there will be no PWM signal from the SoC and DCS
> > commands are sent to enable and control the backlight brightness.
> >
> > v2: Moving the CABC bkl functions to new file.(Jani)
> >
> > v3: Rebase
> >
> > v4: Rebase
> >
> > v5: Use mipi_dsi_dcs_write() instead of mipi_dsi_dcs_write_buffer() (Jani)
> > Move DCS macro`s to include/video/mipi_display.h (Jani)
>
> Where's the patch actually adding the macros? We need that in the same
> series to have CI actually build and run this; this fails without them.
>
> BR,
> Jani.
>
>
[Deepak, M] Okay will resend these patches including that patch also.
> >
> > Cc: Jani Nikula
> > Cc: Daniel Vetter
> > Cc: Yetunde Adebisi
> > Signed-off-by: Deepak M
> > ---
> >
> > The DCS command macro`s are defined in the patch which is posted in
> > the dri-devel list.
> >
> > drivers/gpu/drm/i915/Makefile | 1 +
> > drivers/gpu/drm/i915/i915_drv.h | 1 -
> > drivers/gpu/drm/i915/intel_drv.h | 2 +
> > drivers/gpu/drm/i915/intel_dsi.c | 19 -
> > drivers/gpu/drm/i915/intel_dsi.h | 4 +
> > drivers/gpu/drm/i915/intel_dsi_cabc.c | 154
> ++
> > drivers/gpu/drm/i915/intel_panel.c| 4 +
> > 7 files changed, 182 insertions(+), 3 deletions(-) create mode
> > 100644 drivers/gpu/drm/i915/intel_dsi_cabc.c
> >
> > diff --git a/drivers/gpu/drm/i915/Makefile
> > b/drivers/gpu/drm/i915/Makefile index 7ffb51b..065c410 100644
> > --- a/drivers/gpu/drm/i915/Makefile
> > +++ b/drivers/gpu/drm/i915/Makefile
> > @@ -83,6 +83,7 @@ i915-y += dvo_ch7017.o \
> > intel_dp_mst.o \
> > intel_dp.o \
> > intel_dsi.o \
> > + intel_dsi_cabc.o \
> > intel_dsi_panel_vbt.o \
> > intel_dsi_pll.o \
> > intel_dvo.o \
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h index 050d860..9ed60f8 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3489,7 +3489,6 @@ void intel_sbi_write(struct drm_i915_private
> *dev_priv, u16 reg, u32 value,
> > enum intel_sbi_destination destination);
> > u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
> > void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32
> > val);
> > -
> > int intel_gpu_freq(struct drm_i915_private *dev_priv, int val); int
> > intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
> >
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index c87b450..9e49396 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1325,6 +1325,8 @@ void intel_dp_mst_encoder_cleanup(struct
> > intel_digital_port *intel_dig_port);
> > /* intel_dsi.c */
> > void intel_dsi_init(struct drm_device *dev);
> >
> > +/* intel_dsi_cabc.c */
> > +int intel_dsi_cabc_init_backlight_funcs(struct intel_connector
> > +*intel_connector);
> >
> > /* intel_dvo.c */
> > void intel_dvo_init(struct drm_device *dev); diff --git
> > a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
> > index 456676c..7aa707f 100644
> > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > @@ -1209,10 +1209,25 @@ void intel_dsi_init(struct drm_device *dev)
> > else
> > intel_encoder->crtc_mask = BIT(PIPE_B);
> >
> > - if (dev_priv->vbt.dsi.config->dual_link)
> > + if (dev_priv->vbt.dsi.config->dual_link) {
> > intel_dsi->ports = BIT(PORT_A) | BIT(PORT_C);
> > - else
> > + switch (dev_priv->vbt.dsi.config->dl_cabc_port) {
> > + case CABC_PORT_A:
> > + intel_dsi->bkl_dcs_ports = BIT(PORT_A);
> > + break;
> > + case CABC_PORT_C:
> > + intel_dsi->bkl_dcs_ports = BIT(PORT_C);
> > + break;
> > + case CABC_PORT_A_AND_C:
> > + intel_dsi->bkl_dcs_ports = BIT(PORT_A) |
> BIT(PORT_C);
> > + break;
> > + default:
> > + DRM_ERROR("Unknown MIPI ports for sending
> DCS\n");
> > + }
> > + } else {
> > intel_dsi->ports = BIT(port);
> > + intel_dsi->bkl_d
[Intel-gfx] [PATCH 1/3] drm: Add new DCS commands in the enum list
Adding new DCS commands which are specified in the
DCS 1.3 spec related to CABC.
Cc: Thierry Reding
Cc: David Airlie
Cc: Ville Syrjälä
Cc: Daniel Vetter
Suggested-by: Jani Nikula
Signed-off-by: Deepak M
---
include/video/mipi_display.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
index ddcc8ca..bb8195b 100644
--- a/include/video/mipi_display.h
+++ b/include/video/mipi_display.h
@@ -117,6 +117,14 @@ enum {
MIPI_DCS_GET_SCANLINE = 0x45,
MIPI_DCS_READ_DDB_START = 0xA1,
MIPI_DCS_READ_DDB_CONTINUE = 0xA8,
+ MIPI_DCS_GET_DISPLAY_BRIGHTNESS = 0x52,
+ MIPI_DCS_GET_CABC_MIN_BRIGHTNESS = 0x5F,
+ MIPI_DCS_GET_POWER_SAVE = 0x56,
+ MIPI_DCS_GET_CONTROL_DISPLAY= 0x54,
+ MIPI_DCS_SET_DISPLAY_BRIGHTNESS = 0x51,
+ MIPI_DCS_SET_CABC_MIN_BRIGHTNESS = 0x5E,
+ MIPI_DCS_WRITE_POWER_SAVE = 0x55,
+ MIPI_DCS_WRITE_CONTROL_DISPLAY = 0x53,
};
/* MIPI DCS pixel formats */
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: CABC support for backlight control
In CABC (Content Adaptive Brightness Control) content grey level
scale can be increased while simultaneously decreasing
brightness of the backlight to achieve same perceived brightness.
The CABC is not standardized and panel vendors are free to follow
their implementation. The CABC implementaion here assumes that the
panels use standard SW register for control.
In this design there will be no PWM signal from the SoC and DCS
commands are sent to enable and control the backlight brightness.
v2: Moving the CABC bkl functions to new file.(Jani)
v3: Rebase
v4: Rebase
v5: Use mipi_dsi_dcs_write() instead of mipi_dsi_dcs_write_buffer() (Jani)
Move DCS macro`s to include/video/mipi_display.h (Jani)
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Yetunde Adebisi
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_dsi.c | 19 -
drivers/gpu/drm/i915/intel_dsi.h | 4 +
drivers/gpu/drm/i915/intel_dsi_cabc.c | 154 ++
drivers/gpu/drm/i915/intel_panel.c| 4 +
7 files changed, 182 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_dsi_cabc.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 7ffb51b..065c410 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -83,6 +83,7 @@ i915-y += dvo_ch7017.o \
intel_dp_mst.o \
intel_dp.o \
intel_dsi.o \
+ intel_dsi_cabc.o \
intel_dsi_panel_vbt.o \
intel_dsi_pll.o \
intel_dvo.o \
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 050d860..9ed60f8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3489,7 +3489,6 @@ void intel_sbi_write(struct drm_i915_private *dev_priv,
u16 reg, u32 value,
enum intel_sbi_destination destination);
u32 vlv_flisdsi_read(struct drm_i915_private *dev_priv, u32 reg);
void vlv_flisdsi_write(struct drm_i915_private *dev_priv, u32 reg, u32 val);
-
int intel_gpu_freq(struct drm_i915_private *dev_priv, int val);
int intel_freq_opcode(struct drm_i915_private *dev_priv, int val);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index c87b450..9e49396 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1325,6 +1325,8 @@ void intel_dp_mst_encoder_cleanup(struct
intel_digital_port *intel_dig_port);
/* intel_dsi.c */
void intel_dsi_init(struct drm_device *dev);
+/* intel_dsi_cabc.c */
+int intel_dsi_cabc_init_backlight_funcs(struct intel_connector
*intel_connector);
/* intel_dvo.c */
void intel_dvo_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 456676c..7aa707f 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -1209,10 +1209,25 @@ void intel_dsi_init(struct drm_device *dev)
else
intel_encoder->crtc_mask = BIT(PIPE_B);
- if (dev_priv->vbt.dsi.config->dual_link)
+ if (dev_priv->vbt.dsi.config->dual_link) {
intel_dsi->ports = BIT(PORT_A) | BIT(PORT_C);
- else
+ switch (dev_priv->vbt.dsi.config->dl_cabc_port) {
+ case CABC_PORT_A:
+ intel_dsi->bkl_dcs_ports = BIT(PORT_A);
+ break;
+ case CABC_PORT_C:
+ intel_dsi->bkl_dcs_ports = BIT(PORT_C);
+ break;
+ case CABC_PORT_A_AND_C:
+ intel_dsi->bkl_dcs_ports = BIT(PORT_A) | BIT(PORT_C);
+ break;
+ default:
+ DRM_ERROR("Unknown MIPI ports for sending DCS\n");
+ }
+ } else {
intel_dsi->ports = BIT(port);
+ intel_dsi->bkl_dcs_ports = BIT(port);
+ }
/* Create a DSI host (and a device) for each port. */
for_each_dsi_port(port, intel_dsi->ports) {
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index 0e758f1..5c07d59 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -34,6 +34,10 @@
#define DSI_DUAL_LINK_FRONT_BACK 1
#define DSI_DUAL_LINK_PIXEL_ALT2
+#define CABC_PORT_A 0x00
+#define CABC_PORT_C 0x01
+#define CABC_PORT_A_AND_C 0x02
+
struct intel_dsi_host;
struct intel_dsi {
diff --git a/drivers/gpu/drm/i915/intel_dsi_cabc.c
b/drivers/gpu/drm/i915/intel_dsi_cabc.c
new file mode 100644
index 000..230ee4f
--- /dev/null
+++ b/drivers/gpu/drm/i915/intel_dsi_cabc.c
@@ -0,0 +1,154 @@
+/*
+ * Copyright © 2016 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtainin
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Parsing the PWM cntrl and CABC ON/OFF fileds in VBT
== Series Details == Series: series starting with [1/2] drm/i915: Parsing the PWM cntrl and CABC ON/OFF fileds in VBT URL : https://patchwork.freedesktop.org/series/4847/ State : failure == Summary == CC [M] drivers/net/ethernet/intel/igb/e1000_mac.o CC [M] drivers/net/ethernet/intel/igb/e1000_nvm.o CC [M] drivers/net/ethernet/intel/e1000/e1000_hw.o CC [M] drivers/net/ethernet/intel/igb/e1000_phy.o CC [M] drivers/net/ethernet/intel/e1000/e1000_ethtool.o CC [M] drivers/net/ethernet/intel/igb/e1000_mbx.o CC [M] drivers/net/ethernet/intel/e1000e/80003es2lan.o CC [M] drivers/net/ethernet/intel/igb/igb_ptp.o CC [M] drivers/net/ethernet/intel/igb/e1000_i210.o CC [M] drivers/net/ethernet/intel/e1000e/mac.o CC [M] drivers/net/ethernet/intel/igb/igb_hwmon.o CC [M] drivers/net/ethernet/intel/e1000e/manage.o CC [M] drivers/net/ethernet/intel/e1000e/nvm.o CC [M] drivers/net/ethernet/intel/e1000/e1000_param.o CC [M] drivers/net/ethernet/intel/e1000e/phy.o CC [M] drivers/net/ethernet/intel/e1000e/param.o CC [M] drivers/net/ethernet/intel/e1000e/ethtool.o CC [M] drivers/net/ethernet/intel/e1000e/netdev.o CC [M] drivers/net/ethernet/intel/e1000e/ptp.o LD drivers/usb/host/xhci-hcd.o LD [M] drivers/net/ethernet/intel/igbvf/igbvf.o LD drivers/usb/host/built-in.o LD drivers/usb/built-in.o LD [M] drivers/net/ethernet/intel/e1000/e1000.o LD [M] drivers/net/ethernet/intel/igb/igb.o LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o LD drivers/net/ethernet/built-in.o LD drivers/net/built-in.o Makefile:950: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ 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: Remove impossibe checks from i915_gem_request_add_to_client
On Thu, Mar 24, 2016 at 09:49:25AM +, Tvrtko Ursulin wrote: > > On 23/03/16 15:31, Chris Wilson wrote: > >On Wed, Mar 23, 2016 at 03:15:03PM +, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>There is only one caller of this functions which calls it under > >>strictly defined conditions. Error checking and return value > >>can be removed. > >> > >>Signed-off-by: Tvrtko Ursulin > >>--- > >>BTW it looks like the whole point of this request list is to implement > >>the throttle ioctl? Looks like a strange ioctl with a fixed 20ms criteria, > >>could it be re-implemented somehow without having to have this list? > >> > >>Does it have to be per-client or could it wait for any requests on any > >>engine emitted 20ms ago? > > > >It is per-client, and I long wished the 20ms wasn't defined by the ABI. > > Is it useful and/or widely used though? X for throttling front buffer rendering. > With multiple clients submitting work I don't see the semantics are > deterministic. I was thinking if it could be replaced with a simpler > implementation for the similar random effect, losing the list > altogether? No, it wants per-client semantics. > Especially wonder how the scheduler will affect it. It won't because that would be breaking ABI. > >What I proposed doing is this: > > > >https://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=breadcrumbs&id=e33947505b54582964c8c202b22f88fc5705f484 > > How is it safe? list_add modifies various pointers in multiple steps > so I didn't know that is safe against concurrent iteration. It is safe. list_add() is now properly ordered using the compiler barrier (i.e. it gained the RCU semantics). > RCU flavoured list API can do such things but in this case switching > to that would only enable lockless throttle and not gain anything on > the add_to_client path. And add_to_client is the hotter of the pair. > >Please note that this also fixes a race condition I've seen in the wild. > > What is the race? file_priv not being checked after acquiring the spinlock under which the list may be reset. -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] [intelddx] v2.99.917-580-gf656f6afa288: sh: 1: ACLOCAL_FLAGS: not found
On Thu, Mar 24, 2016 at 10:54 AM, Chris Wilson wrote: > On Thu, Mar 24, 2016 at 10:34:58AM +0100, Sedat Dilek wrote: >> [ build-script, build and config logs attached ] >> >> Hi Chris, >> >> I am just seeing this (or noticed for the first time, here on >> Ubuntu/precise AMD64)... >> >> $ zgrep -A1 -B1 ACLOCAL_FLAGS: >> build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt.gz >> autoreconf: running: aclocal $(ACLOCAL_FLAGS) -I m4 >> sh: 1: ACLOCAL_FLAGS: not found >> autoreconf: configure.ac: tracing >> -- >> libtoolize: copying file `m4/lt~obsolete.m4' >> sh: 1: ACLOCAL_FLAGS: not found >> autoreconf: running: /usr/bin/autoconf >> >> What does this mean and it is ignore-able? > > libtool vs automake. Haven't found the right fix yet. > > If you want to locally patch s/$(ACLOCAL_FLAGS)// that'll do the trick. > I think that's what we'll have to do :| [ TRYOUT ] $ grep ACLOCAL -nr ./ ./Makefile.am:21:ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4 I dropped ACLOCAL_FLAG part in Makefile.am (see attached diff) and get... --- build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_ACLOCAL_FLAGS-dropped_llvm-3-8-0.txt 2016-03-24 11:13:06.429252959 +0100 +++ build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt 2016-03-24 10:25:35.913229371 +0100 @@ -1,6 +1,7 @@ autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext -autoreconf: running: aclocal -I m4 +autoreconf: running: aclocal $(ACLOCAL_FLAGS) -I m4 +sh: 1: ACLOCAL_FLAGS: not found autoreconf: configure.ac: tracing autoreconf: running: libtoolize --install --copy libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. @@ -14,6 +15,7 @@ libtoolize: copying file `m4/ltoptions.m libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' +sh: 1: ACLOCAL_FLAGS: not found autoreconf: running: /usr/bin/autoconf autoreconf: running: /usr/bin/autoheader autoreconf: running: automake --add-missing --copy --no-force BTW, my libtool-version is 2.4.2-1ubuntu1. configure-log is attached. ( In my config.log file I see an error with Clang v3.8.0 - I will send a separate email. ) - Sedat - diff --git a/Makefile.am b/Makefile.am index c60e8a729271..396f41fdc4df 100644 --- a/Makefile.am +++ b/Makefile.am @@ -18,7 +18,7 @@ # 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. -ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4 +ACLOCAL_AMFLAGS = -I m4 SUBDIRS = man libobj xvmc src tools autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal -I m4 autoreconf: configure.ac: tracing autoreconf: running: libtoolize --install --copy libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `.'. libtoolize: copying file `./config.guess' libtoolize: copying file `./config.sub' libtoolize: copying file `./install-sh' libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' autoreconf: running: /usr/bin/autoconf autoreconf: running: /usr/bin/autoheader autoreconf: running: automake --add-missing --copy --no-force configure.ac:35: installing `./missing' benchmarks/Makefile.am: installing `./depcomp' autoreconf: Leaving directory `.' checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking for gcc... clang checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether clang accepts -g... yes checking for clang option to accept ISO C89... none needed checking dependency style of clang... gcc3 checking for clang option to accept ISO C99... none needed checking how to run the C preprocessor... clang-cpp checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether __clang__ is declared... yes checking whether __INTEL_COMPILER is declared... no checking whether __SUNPRO_C
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Fix DSI HW state readout (rev2)
== Series Details == Series: drm/i915/bxt: Fix DSI HW state readout (rev2) URL : https://patchwork.freedesktop.org/series/4832/ State : failure == Summary == Series 4832v2 drm/i915/bxt: Fix DSI HW state readout http://patchwork.freedesktop.org/api/1.0/series/4832/revisions/2/mbox/ Test gem_exec_suspend: Subgroup basic-s3: pass -> DMESG-WARN (bsw-nuc-2) Test kms_force_connector_basic: Subgroup force-edid: pass -> SKIP (snb-x220t) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-c: pass -> SKIP (hsw-brixbox) Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-rte: dmesg-warn -> PASS (byt-nuc) UNSTABLE bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:192 pass:153 dwarn:2 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:157 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:192 pass:181 dwarn:0 dfail:0 fail:0 skip:11 snb-x220ttotal:192 pass:157 dwarn:0 dfail:0 fail:1 skip:34 Results at /archive/results/CI_IGT_test/Patchwork_1700/ 8f2e9bbc15607f56261aefd7a1f8caf6909c6b9d drm-intel-nightly: 2016y-03m-23d-17h-03m-10s UTC integration manifest 79a5fd5ff300da5306de558ec9835cb8d42cc3b8 drm/i915/bxt: Fix DSI HW state readout ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm: Add new DCS commands in the enum list
On Thu, 24 Mar 2016, Deepak M wrote:
> Adding new DCS commands which are specified in the
> DCS 1.3 spec related to CABC.
>
> Cc: Thierry Reding
> Cc: David Airlie
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Suggested-by: Jani Nikula
> Signed-off-by: Deepak M
Deepak, for future reference, please use scripts/get_maintainer.pl to
see whom you should include for patches touching code outside of i915.
The commands added match the MIPI DCS 1.3 spec,
Reviewed-by: Jani Nikula
Jean-Christophe, Tomi, may I have your acks for merging this via
drm/i915 tree?
BR,
Jani.
> ---
> include/video/mipi_display.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/include/video/mipi_display.h b/include/video/mipi_display.h
> index ddcc8ca..bb8195b 100644
> --- a/include/video/mipi_display.h
> +++ b/include/video/mipi_display.h
> @@ -117,6 +117,14 @@ enum {
> MIPI_DCS_GET_SCANLINE = 0x45,
> MIPI_DCS_READ_DDB_START = 0xA1,
> MIPI_DCS_READ_DDB_CONTINUE = 0xA8,
> + MIPI_DCS_GET_DISPLAY_BRIGHTNESS = 0x52,
> + MIPI_DCS_GET_CABC_MIN_BRIGHTNESS = 0x5F,
> + MIPI_DCS_GET_POWER_SAVE = 0x56,
> + MIPI_DCS_GET_CONTROL_DISPLAY= 0x54,
> + MIPI_DCS_SET_DISPLAY_BRIGHTNESS = 0x51,
> + MIPI_DCS_SET_CABC_MIN_BRIGHTNESS = 0x5E,
> + MIPI_DCS_WRITE_POWER_SAVE = 0x55,
> + MIPI_DCS_WRITE_CONTROL_DISPLAY = 0x53,
> };
>
> /* MIPI DCS pixel formats */
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915/bxt: Fix DSI HW state readout
Currently the machine hangs during booting while accessing the
BXT_MIPI_PORT_CTRL register during pipe HW state readout. After some
experimentation I found that the hang is caused by the DSI PLL being
disabled, or it being enabled but with an incorrect divider
configuration. Enabling the PLL got rid of the boot problem, so fix
this by checking the PLL enabled state/configuration before attempting
to read out the HW state.
The DSI_PLL_ENABLE register is in the always-on power well, while the
BXT_DSI_PLL_CTL is in power well 0. This isn't exactly matched by the
transcoder power domain, but what we really need is just a runtime PM
reference, which is provided by any power domain.
Ville also found this dependency specified in BSpec, so I added a
reference to that too.
v2:
- Make sure we hold a power reference while accessing the PLL registers.
v3: (Jani)
- Simplify check in bxt_get_dsi_transcoder_state()
- Add comment explaining why we check for valid dividers in
bxt_dsi_pll_is_enabled()
CC: Shashank Sharma
CC: Uma Shankar
CC: Jani Nikula
Fixes: c6c794a2fc5e ("drm/i915/bxt: Initialize MIPI DSI for BXT")
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 11 ++
drivers/gpu/drm/i915/intel_dsi.c | 9
drivers/gpu/drm/i915/intel_dsi.h | 1 +
drivers/gpu/drm/i915/intel_dsi_pll.c | 40
5 files changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f3ba43c..c839ce9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7811,9 +7811,11 @@ enum skl_disp_power_wells {
#define BXT_DSIC_16X_BY2 (1 << 10)
#define BXT_DSIC_16X_BY3 (2 << 10)
#define BXT_DSIC_16X_BY4 (3 << 10)
+#define BXT_DSIC_16X_MASK (3 << 10)
#define BXT_DSIA_16X_BY2 (1 << 8)
#define BXT_DSIA_16X_BY3 (2 << 8)
#define BXT_DSIA_16X_BY4 (3 << 8)
+#define BXT_DSIA_16X_MASK (3 << 8)
#define BXT_DSI_FREQ_SEL_SHIFT8
#define BXT_DSI_FREQ_SEL_MASK (0xF << BXT_DSI_FREQ_SEL_SHIFT)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 009b03b..e05393e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -36,6 +36,7 @@
#include "intel_drv.h"
#include
#include "i915_drv.h"
+#include "intel_dsi.h"
#include "i915_trace.h"
#include
#include
@@ -9867,6 +9868,16 @@ static bool bxt_get_dsi_transcoder_state(struct
intel_crtc *crtc,
continue;
*power_domain_mask |= BIT(power_domain);
+ /*
+* The PLL needs to be enabled with a valid divider
+* configuration, otherwise accessing DSI registers will hang
+* the machine. See BSpec North Display Engine
+* registers/MIPI[BXT]. We can break out here early, since we
+* need the same DSI PLL to be enabled for both DSI ports.
+*/
+ if (!intel_dsi_pll_is_enabled(dev_priv))
+ break;
+
/* XXX: this works for video mode only */
tmp = I915_READ(BXT_MIPI_PORT_CTRL(port));
if (!(tmp & DPI_ENABLE))
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 96ea3f7..0de74e1 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -684,6 +684,14 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
*encoder,
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
return false;
+ /*
+* On Broxton the PLL needs to be enabled with a valid divider
+* configuration, otherwise accessing DSI registers will hang the
+* machine. See BSpec North Display Engine registers/MIPI[BXT].
+*/
+ if (IS_BROXTON(dev_priv) && !intel_dsi_pll_is_enabled(dev_priv))
+ goto out_put_power;
+
/* XXX: this only works for one DSI output */
for_each_dsi_port(port, intel_dsi->ports) {
i915_reg_t ctrl_reg = IS_BROXTON(dev) ?
@@ -726,6 +734,7 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
*encoder,
break;
}
+out_put_power:
intel_display_power_put(dev_priv, power_domain);
return active;
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index e582ef8..ec58ead 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/i915/intel_dsi.h
@@ -126,6 +126,7 @@ static inline struct intel_dsi *enc_to_intel_dsi(struct
drm_encoder *encoder)
return container_of(encoder, struct intel_dsi, base.base);
}
+bool intel_dsi_pll_is_enabled(struct drm_i915_private *dev_priv);
extern void intel_enable_dsi_pll(struct intel_
[Intel-gfx] [intelddx][strlcpy | strlcat | clock_gettime] clang-3.8: error: linker command failed with exit code 1
[ Please see attached files (build-script, full logs etc.) ] With my selfmade llvm-toolchain v3.8.0 I see these errors/warnings... $ egrep -B2 -i 'linker command failed|undefined reference to' config.log "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o conftest /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.9/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.9 -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. -L/opt/llvm-toolchain-3.8.0/bin/../lib -L/lib -L/usr/lib /tmp/conftest-467d35.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.9/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o /tmp/conftest-467d35.o: In function `main': conftest.c:(.text+0x12): undefined reference to `strlcpy' clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation) -- "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o conftest /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.9/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.9 -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. -L/opt/llvm-toolchain-3.8.0/bin/../lib -L/lib -L/usr/lib /tmp/conftest-934a03.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.9/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o /tmp/conftest-934a03.o: In function `main': conftest.c:(.text+0x12): undefined reference to `strlcat' clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation) -- "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o conftest /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/4.9/crtbegin.o -L/usr/lib/gcc/x86_64-linux-gnu/4.9 -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../.. -L/opt/llvm-toolchain-3.8.0/bin/../lib -L/lib -L/usr/lib /tmp/conftest-36ad4e.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-linux-gnu/4.9/crtend.o /usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o /tmp/conftest-36ad4e.o: In function `main': conftest.c:(.text+0x12): undefined reference to `clock_gettime' clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation) Furthermore, my 'clang -v' output... $ clang -v clang version 3.8.0 (tags/RELEASE_380/final) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /opt/llvm/bin Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2 Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 If you need more inputs/informations, please let me know. Hope this helps. - Sedat - diff --git a/Makefile.am b/Makefile.am index c60e8a729271..396f41fdc4df 100644 --- a/Makefile.am +++ b/Makefile.am @@ -18,7 +18,7 @@ # 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. -ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4 +ACLOCAL_AMFLAGS = -I m4 SUBDIRS = man libobj xvmc src tools config.log.gz Description: GNU Zip compressed data configure-intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt.gz Description: GNU Zip compressed data build_xf86-video-intel-with-llvm.sh Description: Bourne shell script ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/bxt: Fix DSI HW state readout
On Thu, 24 Mar 2016, Imre Deak wrote:
> Currently the machine hangs during booting while accessing the
> BXT_MIPI_PORT_CTRL register during pipe HW state readout. After some
> experimentation I found that the hang is caused by the DSI PLL being
> disabled, or it being enabled but with an incorrect divider
> configuration. Enabling the PLL got rid of the boot problem, so fix
> this by checking the PLL enabled state/configuration before attempting
> to read out the HW state.
>
> The DSI_PLL_ENABLE register is in the always-on power well, while the
> BXT_DSI_PLL_CTL is in power well 0. This isn't exactly matched by the
> transcoder power domain, but what we really need is just a runtime PM
> reference, which is provided by any power domain.
>
> Ville also found this dependency specified in BSpec, so I added a
> reference to that too.
>
> v2:
> - Make sure we hold a power reference while accessing the PLL registers.
> v3: (Jani)
> - Simplify check in bxt_get_dsi_transcoder_state()
> - Add comment explaining why we check for valid dividers in
> bxt_dsi_pll_is_enabled()
>
> CC: Shashank Sharma
> CC: Uma Shankar
> CC: Jani Nikula
> Fixes: c6c794a2fc5e ("drm/i915/bxt: Initialize MIPI DSI for BXT")
> Signed-off-by: Imre Deak
Thanks for fixing this.
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> drivers/gpu/drm/i915/intel_display.c | 11 ++
> drivers/gpu/drm/i915/intel_dsi.c | 9
> drivers/gpu/drm/i915/intel_dsi.h | 1 +
> drivers/gpu/drm/i915/intel_dsi_pll.c | 40
>
> 5 files changed, 63 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f3ba43c..c839ce9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7811,9 +7811,11 @@ enum skl_disp_power_wells {
> #define BXT_DSIC_16X_BY2(1 << 10)
> #define BXT_DSIC_16X_BY3(2 << 10)
> #define BXT_DSIC_16X_BY4(3 << 10)
> +#define BXT_DSIC_16X_MASK (3 << 10)
> #define BXT_DSIA_16X_BY2(1 << 8)
> #define BXT_DSIA_16X_BY3(2 << 8)
> #define BXT_DSIA_16X_BY4(3 << 8)
> +#define BXT_DSIA_16X_MASK (3 << 8)
> #define BXT_DSI_FREQ_SEL_SHIFT 8
> #define BXT_DSI_FREQ_SEL_MASK (0xF << BXT_DSI_FREQ_SEL_SHIFT)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 009b03b..e05393e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -36,6 +36,7 @@
> #include "intel_drv.h"
> #include
> #include "i915_drv.h"
> +#include "intel_dsi.h"
> #include "i915_trace.h"
> #include
> #include
> @@ -9867,6 +9868,16 @@ static bool bxt_get_dsi_transcoder_state(struct
> intel_crtc *crtc,
> continue;
> *power_domain_mask |= BIT(power_domain);
>
> + /*
> + * The PLL needs to be enabled with a valid divider
> + * configuration, otherwise accessing DSI registers will hang
> + * the machine. See BSpec North Display Engine
> + * registers/MIPI[BXT]. We can break out here early, since we
> + * need the same DSI PLL to be enabled for both DSI ports.
> + */
> + if (!intel_dsi_pll_is_enabled(dev_priv))
> + break;
> +
> /* XXX: this works for video mode only */
> tmp = I915_READ(BXT_MIPI_PORT_CTRL(port));
> if (!(tmp & DPI_ENABLE))
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 96ea3f7..0de74e1 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -684,6 +684,14 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
> *encoder,
> if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
> return false;
>
> + /*
> + * On Broxton the PLL needs to be enabled with a valid divider
> + * configuration, otherwise accessing DSI registers will hang the
> + * machine. See BSpec North Display Engine registers/MIPI[BXT].
> + */
> + if (IS_BROXTON(dev_priv) && !intel_dsi_pll_is_enabled(dev_priv))
> + goto out_put_power;
> +
> /* XXX: this only works for one DSI output */
> for_each_dsi_port(port, intel_dsi->ports) {
> i915_reg_t ctrl_reg = IS_BROXTON(dev) ?
> @@ -726,6 +734,7 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
> *encoder,
> break;
> }
>
> +out_put_power:
> intel_display_power_put(dev_priv, power_domain);
>
> return active;
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index e582ef8..ec58ead 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -126,6 +126,7 @@ static
[Intel-gfx] [intelddx] TearFree still status "Experimental support"?
Hi Chris, is TearFree feature still "experimental" in current xf86-video-intel.git#master? It is enabled by default! [ configure-log ] ... xf86-video-intel 2.99.917 will be compiled with: Xorg Video ABI version: 15.0 (xorg-server-1.15.1) pixman version: pixman-1-0.30.2 Acceleration backends: none *sna uxa Additional debugging support? valgrind Support for Kernel Mode Setting? yes Support for legacy User Mode Setting (for i810)? yes Support for Direct Rendering Infrastructure: *DRI2 Support for Xv motion compensation (XvMC and libXvMC): yes Support for display hotplug notifications (udev): yes Build additional tools and utilities? xf86-video-intel-backlight-helper Experimental support: TearFree <--- XXX ... [ configure.ac ] ... AC_ARG_ENABLE(tear-free, AS_HELP_STRING([--enable-tear-free], [Enable use of TearFree by default [default=no]]), [TEARFREE="$enableval"], [TEARFREE="no"]) if test "x$TEARFREE" = "xyes"; then AC_DEFINE(TEARFREE,1,[Enable "TearFree" by default]) xp_msg="$xp_msg TearFree" <--- Line needs to be killed ??? fi ... if test -n "$xp_msg"; then echo " Experimental support:$xp_msg" fi ... Thanks. - Sedat - [1] https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/configure.ac#n742 [2] https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/configure.ac#n927 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC v2] drm/i915: Move execlists irq handler to a bottom half
On Wed, Mar 23, 2016 at 02:57:36PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Doing a lot of work in the interrupt handler introduces huge > latencies to the system as a whole. > > Most dramatic effect can be seen by running an all engine > stress test like igt/gem_exec_nop/all where, when the kernel > config is lean enough, the whole system can be brought into > multi-second periods of complete non-interactivty. That can > look for example like this: > > NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u8:3:143] > Modules linked in: [redacted for brevity] > CPU: 0 PID: 143 Comm: kworker/u8:3 Tainted: G U L 4.5.0-160321+ > #183 > Hardware name: Intel Corporation Broadwell Client platform/WhiteTip Mountain > 1 > Workqueue: i915 gen6_pm_rps_work [i915] > task: 8800aae88000 ti: 8800aae9 task.ti: 8800aae9 > RIP: 0010:[] [] __do_softirq+0x72/0x1d0 > RSP: :88014f403f38 EFLAGS: 0206 > RAX: 8800aae94000 RBX: RCX: 06e0 > RDX: 0020 RSI: 04208060 RDI: 00215d80 > RBP: 88014f403f80 R08: 000b1b42c180 R09: 0022 > R10: 0004 R11: R12: a030 > R13: 0082 R14: 8800aa4d0080 R15: 0082 > FS: () GS:88014f40() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 7fa53b90c000 CR3: 01a0a000 CR4: 001406f0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > Stack: > 042080601b33869f 8800aae94000 fffc2678 8801000a > a030 5302 8800aa4d0080 > 0206 88014f403f90 8104a716 88014f403fa8 > Call Trace: > > [] irq_exit+0x86/0x90 > [] smp_apic_timer_interrupt+0x3d/0x50 > [] apic_timer_interrupt+0x7c/0x90 > > [] ? gen8_write64+0x1a0/0x1a0 [i915] > [] ? _raw_spin_unlock_irqrestore+0x9/0x20 > [] gen8_write32+0x104/0x1a0 [i915] > [] ? n_tty_receive_buf_common+0x372/0xae0 > [] gen6_set_rps_thresholds+0x1be/0x330 [i915] > [] gen6_set_rps+0x70/0x200 [i915] > [] intel_set_rps+0x25/0x30 [i915] > [] gen6_pm_rps_work+0x10d/0x2e0 [i915] > [] ? finish_task_switch+0x72/0x1c0 > [] process_one_work+0x139/0x350 > [] worker_thread+0x126/0x490 > [] ? rescuer_thread+0x320/0x320 > [] kthread+0xc4/0xe0 > [] ? kthread_create_on_node+0x170/0x170 > [] ret_from_fork+0x3f/0x70 > [] ? kthread_create_on_node+0x170/0x170 > > I could not explain, or find a code path, which would explain > a +20 second lockup, but from some instrumentation it was > apparent the interrupts off proportion of time was between > 10-25% under heavy load which is quite bad. > > By moving the GT interrupt handling to a tasklet in a most > simple way, the problem above disappears completely. Perfect segue into gem_syslatency. I think gem_syslatency is the better tool to correlate disruptive system behaviour. And then continue on with gem_latency to demonstrate that is doesn't adversely affect our performance. > Also, gem_latency -n 100 shows 25% better throughput and CPU > usage, and 14% better latencies. Mention the benefits of parallelising dispatch. As fairly hit-and-miss as perf testing is on these machines, it is looking in favour of using tasklets vs the rt kthread. The numbers swing between 2-10%, but consistently improves in the nop sync latencies. There's still several hours to go in this run before we cover the dispatch latenies, but so far reasonable. (Hmm, looks like there may be a possible degredation on the single nop dispatch but an improvement on the continuous nop dispatch.) > I did not find any gains or regressions with Synmark2 or > GLbench under light testing. More benchmarking is certainly > required. > > v2: >* execlists_lock should be taken as spin_lock_bh when > queuing work from userspace now. (Chris Wilson) >* uncore.lock must be taken with spin_lock_irq when > submitting requests since that now runs from either > softirq or process context. There are a couple of execlist_lock usage outside of intel_lrc that may or may not be useful to convert (low frequency reset / debug paths, so way off the critical paths, but consistency in locking is invaluable). > + tasklet_init(&engine->irq_tasklet, intel_lrc_irq_handler, > + (unsigned long)engine); I like trying to split lines to cluster arguments if possible. Here I think intel_lrc_irq_handler pairs with engine, tasklet_init(&engine->irq_tasklet, intel_lrc_irq_handler, (unsigned long)engine); *shrug* > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h > b/drivers/gpu/drm/i915/intel_ringbuffer.h > index 221a94627aab..29810cba8a8c 100644 > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h > +++ b/driver
Re: [Intel-gfx] [intelddx][strlcpy | strlcat | clock_gettime] clang-3.8: error: linker command failed with exit code 1
On Thu, Mar 24, 2016 at 11:44:45AM +0100, Sedat Dilek wrote: > [ Please see attached files (build-script, full logs etc.) ] > > With my selfmade llvm-toolchain v3.8.0 I see these errors/warnings... > conftest.c:(.text+0x12): undefined reference to `strlcpy' > clang-3.8: error: linker command failed with exit code 1 (use -v to > see invocation) We don't even use strlcat! Try: diff --git a/configure.ac b/configure.ac index c18ad96..b121515 100644 --- a/configure.ac +++ b/configure.ac @@ -62,9 +62,6 @@ AC_DISABLE_STATIC AC_PROG_LIBTOOL AC_SYS_LARGEFILE -# Check for common libc routines redefined by os.h -AC_CHECK_FUNCS([strlcpy strlcat strndup], [], []) - # Platform specific settings case $host_os in *linux*) -- 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] [intelddx][strlcpy | strlcat | clock_gettime] clang-3.8: error: linker command failed with exit code 1
On Thu, Mar 24, 2016 at 12:01 PM, Chris Wilson wrote: > On Thu, Mar 24, 2016 at 11:44:45AM +0100, Sedat Dilek wrote: >> [ Please see attached files (build-script, full logs etc.) ] >> >> With my selfmade llvm-toolchain v3.8.0 I see these errors/warnings... > >> conftest.c:(.text+0x12): undefined reference to `strlcpy' >> clang-3.8: error: linker command failed with exit code 1 (use -v to >> see invocation) > > We don't even use strlcat! Try: > > diff --git a/configure.ac b/configure.ac > index c18ad96..b121515 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -62,9 +62,6 @@ AC_DISABLE_STATIC > AC_PROG_LIBTOOL > AC_SYS_LARGEFILE > > -# Check for common libc routines redefined by os.h > -AC_CHECK_FUNCS([strlcpy strlcat strndup], [], []) > - > # Platform specific settings > case $host_os in >*linux*) > > So I collected all three "issues" here and sent you the generated logs. Hope this helps. Feel free to add my credits. - Sedat - From b35261adb49107e7dd6e480b1f7c5d4fb7552f9f Mon Sep 17 00:00:00 2001 From: Sedat Dilek Date: Thu, 24 Mar 2016 12:01:37 +0100 Subject: [PATCH 1/3] configure: Remove ACLOCAL_FLAGS to fix libtool vs automake problem --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index c60e8a729271..396f41fdc4df 100644 --- a/Makefile.am +++ b/Makefile.am @@ -18,7 +18,7 @@ # 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. -ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4 +ACLOCAL_AMFLAGS = -I m4 SUBDIRS = man libobj xvmc src tools -- 2.7.4 From 7677aa3c3b6e1105ce7784bfb8d1a3b9233059ba Mon Sep 17 00:00:00 2001 From: Sedat Dilek Date: Thu, 24 Mar 2016 12:03:49 +0100 Subject: [PATCH 2/3] configure: TearFree: Remove "Experimental support" status --- configure.ac | 1 - 1 file changed, 1 deletion(-) diff --git a/configure.ac b/configure.ac index c18ad96c26d1..0457d52c04df 100644 --- a/configure.ac +++ b/configure.ac @@ -746,7 +746,6 @@ AC_ARG_ENABLE(tear-free, [TEARFREE="no"]) if test "x$TEARFREE" = "xyes"; then AC_DEFINE(TEARFREE,1,[Enable "TearFree" by default]) - xp_msg="$xp_msg TearFree" fi AC_ARG_ENABLE(create2, -- 2.7.4 From 1f951b5d65bc9b5b78606f06025a78facd5b402d Mon Sep 17 00:00:00 2001 From: Sedat Dilek Date: Thu, 24 Mar 2016 12:05:25 +0100 Subject: [PATCH 3/3] configure: Remove unused common libc routines check --- configure.ac | 3 --- 1 file changed, 3 deletions(-) diff --git a/configure.ac b/configure.ac index 0457d52c04df..840fb3d96947 100644 --- a/configure.ac +++ b/configure.ac @@ -62,9 +62,6 @@ AC_DISABLE_STATIC AC_PROG_LIBTOOL AC_SYS_LARGEFILE -# Check for common libc routines redefined by os.h -AC_CHECK_FUNCS([strlcpy strlcat strndup], [], []) - # Platform specific settings case $host_os in *linux*) -- 2.7.4 config.log.gz Description: GNU Zip compressed data configure-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_configure-fixes_llvm-3-8-0.txt.gz Description: GNU Zip compressed data ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Cache some registers in execlists hot paths
On Wed, Mar 23, 2016 at 03:15:02PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> GCC cannot optimize well calculations hidden in macros and
> assigned to temporary structures. We can cache the register in
> ELSP write, and refactor reading of the CSB a bit to enable
> it to do a better job.
>
> Code is still equally readable but the generated body of the
> CSB read loop is 30% smaller, and since that loop runs at
> least once per interrupt, which in turn can fire in tens or
> hundreds thousands times per second, must be of some value.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 26 +-
> drivers/gpu/drm/i915/intel_lrc.h | 11 ---
> 2 files changed, 21 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> b/drivers/gpu/drm/i915/intel_lrc.c
> index 3a23b9549f7b..67592f8354d6 100644
> --- a/drivers/gpu/drm/i915/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/intel_lrc.c
> @@ -361,8 +361,8 @@ static void execlists_elsp_write(struct
> drm_i915_gem_request *rq0,
> {
>
> struct intel_engine_cs *engine = rq0->engine;
> - struct drm_device *dev = engine->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_i915_private *dev_priv = rq0->i915;
> + i915_reg_t elsp_reg = RING_ELSP(engine);
If we are going to open-code it, how about going whole hog
and
/* We opencode I915_WRITE_FW(RING_ELSP(engine)) here to save gcc the
* trouble of doing so - gcc fails miserably!
*/
u32 *elsp = rq->i915->regs + i915_mmio_reg_offset(RING_ELSP(engine));
then use writel(upper_32_bits(desc[1]), elsp);
Keeping the comment around for grepping.
> uint64_t desc[2];
>
> if (rq1) {
> @@ -376,12 +376,12 @@ static void execlists_elsp_write(struct
> drm_i915_gem_request *rq0,
> rq0->elsp_submitted++;
>
> /* You must always write both descriptors in the order below. */
> - I915_WRITE_FW(RING_ELSP(engine), upper_32_bits(desc[1]));
> - I915_WRITE_FW(RING_ELSP(engine), lower_32_bits(desc[1]));
> + I915_WRITE_FW(elsp_reg, upper_32_bits(desc[1]));
> + I915_WRITE_FW(elsp_reg, lower_32_bits(desc[1]));
>
> - I915_WRITE_FW(RING_ELSP(engine), upper_32_bits(desc[0]));
> + I915_WRITE_FW(elsp_reg, upper_32_bits(desc[0]));
> /* The context is automatically loaded after the following */
> - I915_WRITE_FW(RING_ELSP(engine), lower_32_bits(desc[0]));
> + I915_WRITE_FW(elsp_reg, lower_32_bits(desc[0]));
>
> /* ELSP is a wo register, use another nearby reg for posting */
> POSTING_READ_FW(RING_EXECLIST_STATUS_LO(engine));
Observing the above, we can also kill the POSTING_READ_FW() which will
make a much bigger improvement than all of the above.
> @@ -517,21 +517,19 @@ execlists_check_remove_request(struct intel_engine_cs
> *engine, u32 request_id)
> }
>
> static u32
> -get_context_status(struct intel_engine_cs *engine, unsigned int read_pointer,
> -u32 *context_id)
> +get_context_status(struct drm_i915_private *dev_priv, u32 csb_base,
> +unsigned int read_pointer, u32 *context_id)
> {
> - struct drm_i915_private *dev_priv = engine->dev->dev_private;
> u32 status;
>
> read_pointer %= GEN8_CSB_ENTRIES;
>
> - status = I915_READ_FW(RING_CONTEXT_STATUS_BUF_LO(engine, read_pointer));
> + status = I915_READ_FW(RING_CSB_LO(csb_base, read_pointer));
If we forgo the "convenience" interface here, could we not also improve
the readability of the code by just having the csb ringbuffer and readl?
-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] [intelddx] TearFree still status "Experimental support"?
On Thu, Mar 24, 2016 at 11:56 AM, Sedat Dilek wrote: > Hi Chris, > > is TearFree feature still "experimental" in current > xf86-video-intel.git#master? > It is enabled by default! > > [ configure-log ] > ... > xf86-video-intel 2.99.917 will be compiled with: > Xorg Video ABI version: 15.0 (xorg-server-1.15.1) > pixman version: pixman-1-0.30.2 > Acceleration backends: none *sna uxa > Additional debugging support? valgrind > Support for Kernel Mode Setting? yes > Support for legacy User Mode Setting (for i810)? yes > Support for Direct Rendering Infrastructure: *DRI2 > Support for Xv motion compensation (XvMC and libXvMC): yes > Support for display hotplug notifications (udev): yes > Build additional tools and utilities? xf86-video-intel-backlight-helper > Experimental support: TearFree <--- XXX > ... > > [ configure.ac ] > ... > AC_ARG_ENABLE(tear-free, > AS_HELP_STRING([--enable-tear-free], > [Enable use of TearFree by default [default=no]]), > [TEARFREE="$enableval"], > [TEARFREE="no"]) > if test "x$TEARFREE" = "xyes"; then > AC_DEFINE(TEARFREE,1,[Enable "TearFree" by default]) > xp_msg="$xp_msg TearFree" <--- Line needs to be killed ??? > fi > ... > if test -n "$xp_msg"; then > echo " Experimental support:$xp_msg" > fi > ... > > Thanks. > > - Sedat - > > [1] > https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/configure.ac#n742 > [2] > https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/configure.ac#n927 See attached patch. - Sedat - From 8a65d6d78a2881f715e5fcbc86b236889eb7819a Mon Sep 17 00:00:00 2001 From: Sedat Dilek Date: Thu, 24 Mar 2016 12:03:49 +0100 Subject: [PATCH] configure: TearFree: Remove "Experimental support" status Signed-off-by: Sedat Dilek --- configure.ac | 1 - 1 file changed, 1 deletion(-) diff --git a/configure.ac b/configure.ac index b121515fdf8f..840fb3d96947 100644 --- a/configure.ac +++ b/configure.ac @@ -743,7 +743,6 @@ AC_ARG_ENABLE(tear-free, [TEARFREE="no"]) if test "x$TEARFREE" = "xyes"; then AC_DEFINE(TEARFREE,1,[Enable "TearFree" by default]) - xp_msg="$xp_msg TearFree" fi AC_ARG_ENABLE(create2, -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2 v2] drm/i915: replace for_each_engine()
Having provided for_each_engine_id() for cases where the third (id)
argument is useful, we can now replace all the remaining instances with
a simpler version that takes only two parameters. In many cases, this
also allows the elimination of the local variable used in the iterator
(usually 'i').
v2:
s/dev_priv/(dev_priv__)/ in body of for_each_engine_masked() [Chris Wilson]
Signed-off-by: Dave Gordon
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 50 +-
drivers/gpu/drm/i915/i915_drv.h| 17 ++
drivers/gpu/drm/i915/i915_gem.c| 50 +-
drivers/gpu/drm/i915/i915_gem_context.c| 6 ++--
drivers/gpu/drm/i915/i915_gem_debug.c | 3 +-
drivers/gpu/drm/i915/i915_gem_gtt.c| 9 ++
drivers/gpu/drm/i915/i915_guc_submission.c | 6 ++--
drivers/gpu/drm/i915/i915_irq.c| 14 +++--
drivers/gpu/drm/i915/intel_guc_loader.c| 8 ++---
drivers/gpu/drm/i915/intel_lrc.c | 3 +-
drivers/gpu/drm/i915/intel_pm.c| 19 +---
11 files changed, 82 insertions(+), 103 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 77dce52..d02f8ce 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -398,11 +398,11 @@ static void print_batch_pool_stats(struct seq_file *m,
struct drm_i915_gem_object *obj;
struct file_stats stats;
struct intel_engine_cs *engine;
- int i, j;
+ int j;
memset(&stats, 0, sizeof(stats));
- for_each_engine(engine, dev_priv, i) {
+ for_each_engine(engine, dev_priv) {
for (j = 0; j < ARRAY_SIZE(engine->batch_pool.cache_list); j++)
{
list_for_each_entry(obj,
&engine->batch_pool.cache_list[j],
@@ -638,13 +638,13 @@ static int i915_gem_batch_pool_info(struct seq_file *m,
void *data)
struct drm_i915_gem_object *obj;
struct intel_engine_cs *engine;
int total = 0;
- int ret, i, j;
+ int ret, j;
ret = mutex_lock_interruptible(&dev->struct_mutex);
if (ret)
return ret;
- for_each_engine(engine, dev_priv, i) {
+ for_each_engine(engine, dev_priv) {
for (j = 0; j < ARRAY_SIZE(engine->batch_pool.cache_list); j++)
{
int count;
@@ -682,14 +682,14 @@ static int i915_gem_request_info(struct seq_file *m, void
*data)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
struct drm_i915_gem_request *req;
- int ret, any, i;
+ int ret, any;
ret = mutex_lock_interruptible(&dev->struct_mutex);
if (ret)
return ret;
any = 0;
- for_each_engine(engine, dev_priv, i) {
+ for_each_engine(engine, dev_priv) {
int count;
count = 0;
@@ -739,14 +739,14 @@ static int i915_gem_seqno_info(struct seq_file *m, void
*data)
struct drm_device *dev = node->minor->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
- int ret, i;
+ int ret;
ret = mutex_lock_interruptible(&dev->struct_mutex);
if (ret)
return ret;
intel_runtime_pm_get(dev_priv);
- for_each_engine(engine, dev_priv, i)
+ for_each_engine(engine, dev_priv)
i915_ring_seqno_info(m, engine);
intel_runtime_pm_put(dev_priv);
@@ -933,7 +933,7 @@ static int i915_interrupt_info(struct seq_file *m, void
*data)
seq_printf(m, "Graphics Interrupt mask: %08x\n",
I915_READ(GTIMR));
}
- for_each_engine(engine, dev_priv, i) {
+ for_each_engine(engine, dev_priv) {
if (INTEL_INFO(dev)->gen >= 6) {
seq_printf(m,
"Graphics Interrupt mask (%s): %08x\n",
@@ -2044,7 +2044,7 @@ static int i915_dump_lrc(struct seq_file *m, void *unused)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *engine;
struct intel_context *ctx;
- int ret, i;
+ int ret;
if (!i915.enable_execlists) {
seq_printf(m, "Logical Ring Contexts are disabled\n");
@@ -2057,7 +2057,7 @@ static int i915_dump_lrc(struct seq_file *m, void *unused)
list_for_each_entry(ctx, &dev_priv->context_list, link)
if (ctx != dev_priv->kernel_context)
- for_each_engine(engine, dev_priv, i)
+ for_each_engine(engine, dev_priv)
i915_dump_lrc_obj(m, ctx, engine);
mutex_unlock(&dev->struct_mutex);
@@ -2077,8 +2077,7 @@ static int i915_execlists(struct seq_file *m, void *data)
[Intel-gfx] [PATCH v2 0/5] Add aspect ratio parsing
Currently DRM framework doesn't parse aspect ratio of a videomode while converting it from a umode->kmode or viceversa. This causes modeset of CEA modes with incorrect aspect ratio. While running HDMI complaince, tests (like 7-27) expect the DUT to apply the mode as per the VIC, but as driver does not consider the aspect ratio part while searching a mode from modedb, we end up setting mode with a wrong VIC, causing the test to fail. What this patch set does: Patch 1-2 - Adds aspect ratio flags in the DRM layer, in form of flags. - Adds parsing of aspect ratio, during conversion of a umode->kmode and viceversa. - Adds aspect ratio check while finding a mode, during modeset. Patch 3-5 - Adds some new aspect ratio defined in CEA-861-F specs to support HDMI 2.0 displays, in DRM and I915 layer. V2: needed a rebase Shashank Sharma (5): drm: add picture aspect ratio flags drm: Add aspect ratio parsing in DRM layer video: Add new aspect ratios for HDMI 2.0 drm: Add flags for new aspect ratios drm/i915: Add support for new aspect ratios drivers/gpu/drm/drm_modes.c | 46 +++ drivers/gpu/drm/i915/intel_hdmi.c | 6 + drivers/gpu/drm/i915/intel_sdvo.c | 6 + drivers/video/hdmi.c | 4 include/linux/hdmi.h | 2 ++ include/uapi/drm/drm_mode.h | 24 +++- 6 files changed, 83 insertions(+), 5 deletions(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/5] drm: Add flags for new aspect ratios
HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch adds DRM flags for the new aspect ratios in the existing aspect ratio flags. Signed-off-by: Shashank Sharma --- include/uapi/drm/drm_mode.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index 3389bd1..b482d73 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -77,6 +77,8 @@ #define DRM_MODE_PICTURE_ASPECT_NONE 0 #define DRM_MODE_PICTURE_ASPECT_4_31 #define DRM_MODE_PICTURE_ASPECT_16_9 2 +#define DRM_MODE_PICTURE_ASPECT_64_27 3 +#define DRM_MODE_PICTURE_ASPECT_256_1354 /* Aspect ratio flag bitmask (4 bits 21:19) */ #define DRM_MODE_FLAG_PARMASK (0x0F<<19) @@ -86,6 +88,10 @@ (DRM_MODE_PICTURE_ASPECT_4_3 << 19) #define DRM_MODE_FLAG_PAR16_9 \ (DRM_MODE_PICTURE_ASPECT_16_9 << 19) +#define DRM_MODE_FLAG_PAR64_27 \ + (DRM_MODE_PICTURE_ASPECT_64_27 << 19) +#define DRM_MODE_FLAG_PAR256_135 \ + (DRM_MODE_PICTURE_ASPECT_256_135 << 19) /* DPMS flags */ /* bit compatible with the xorg definitions. */ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/5] drm: add picture aspect ratio flags
This patch adds drm flag bits for aspect ratio information Currently drm flag bits don't have field for mode's picture aspect ratio. This field will help the driver to pick mode with right aspect ratio, and help in setting right VIC field in avi infoframes. Signed-off-by: Shashank Sharma --- include/uapi/drm/drm_mode.h | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index 50adb46..3389bd1 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -73,6 +73,19 @@ #define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM (7<<14) #define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF(8<<14) +/* Picture aspect ratio options */ +#define DRM_MODE_PICTURE_ASPECT_NONE 0 +#define DRM_MODE_PICTURE_ASPECT_4_31 +#define DRM_MODE_PICTURE_ASPECT_16_9 2 + +/* Aspect ratio flag bitmask (4 bits 21:19) */ +#define DRM_MODE_FLAG_PARMASK (0x0F<<19) +#define DRM_MODE_FLAG_PARNONE \ + (DRM_MODE_PICTURE_ASPECT_NONE << 19) +#define DRM_MODE_FLAG_PAR4_3 \ + (DRM_MODE_PICTURE_ASPECT_4_3 << 19) +#define DRM_MODE_FLAG_PAR16_9 \ + (DRM_MODE_PICTURE_ASPECT_16_9 << 19) /* DPMS flags */ /* bit compatible with the xorg definitions. */ @@ -88,11 +101,6 @@ #define DRM_MODE_SCALE_CENTER 2 /* Centered, no scaling */ #define DRM_MODE_SCALE_ASPECT 3 /* Full screen, preserve aspect */ -/* Picture aspect ratio options */ -#define DRM_MODE_PICTURE_ASPECT_NONE 0 -#define DRM_MODE_PICTURE_ASPECT_4_31 -#define DRM_MODE_PICTURE_ASPECT_16_9 2 - /* Dithering mode options */ #define DRM_MODE_DITHERING_OFF 0 #define DRM_MODE_DITHERING_ON 1 -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/5] drm/i915: Add support for new aspect ratios
HDMI 2.0/CEA-861-F introduces two new aspect ratios: - 64:27 - 256:135 This patch adds support for these aspect ratios in I915 driver, at various places. Signed-off-by: Shashank Sharma --- drivers/gpu/drm/drm_modes.c | 12 drivers/gpu/drm/i915/intel_hdmi.c | 6 ++ drivers/gpu/drm/i915/intel_sdvo.c | 6 ++ 3 files changed, 24 insertions(+) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 7824a63..7e27854 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -1483,6 +1483,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo *out, case HDMI_PICTURE_ASPECT_16_9: out->flags |= DRM_MODE_FLAG_PAR16_9; break; + case HDMI_PICTURE_ASPECT_64_27: + out->flags |= DRM_MODE_FLAG_PAR64_27; + break; + case DRM_MODE_PICTURE_ASPECT_256_135: + out->flags |= DRM_MODE_FLAG_PAR256_135; + break; case HDMI_PICTURE_ASPECT_NONE: case HDMI_PICTURE_ASPECT_RESERVED: default: @@ -1545,6 +1551,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out, case DRM_MODE_FLAG_PAR16_9: out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9; break; + case DRM_MODE_FLAG_PAR64_27: + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27; + break; + case DRM_MODE_FLAG_PAR256_135: + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135; + break; default: out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE; } diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 6825543..6d5c3ad 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1533,6 +1533,12 @@ intel_hdmi_set_property(struct drm_connector *connector, case DRM_MODE_PICTURE_ASPECT_16_9: intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_16_9; break; + case DRM_MODE_PICTURE_ASPECT_64_27: + intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_64_27; + break; + case DRM_MODE_PICTURE_ASPECT_256_135: + intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_256_135; + break; default: return -EINVAL; } diff --git a/drivers/gpu/drm/i915/intel_sdvo.c b/drivers/gpu/drm/i915/intel_sdvo.c index 2e1da06..83f30d6 100644 --- a/drivers/gpu/drm/i915/intel_sdvo.c +++ b/drivers/gpu/drm/i915/intel_sdvo.c @@ -2069,6 +2069,12 @@ intel_sdvo_set_property(struct drm_connector *connector, case DRM_MODE_PICTURE_ASPECT_16_9: intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_16_9; break; + case DRM_MODE_PICTURE_ASPECT_64_27: + intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_64_27; + break; + case DRM_MODE_PICTURE_ASPECT_256_135: + intel_sdvo->aspect_ratio = HDMI_PICTURE_ASPECT_256_135; + break; default: return -EINVAL; } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/5] video: Add new aspect ratios for HDMI 2.0
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.
Signed-off-by: Shashank Sharma
---
drivers/video/hdmi.c | 4
include/linux/hdmi.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..1cf907e 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -533,6 +533,10 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect
picture_aspect)
return "4:3";
case HDMI_PICTURE_ASPECT_16_9:
return "16:9";
+ case HDMI_PICTURE_ASPECT_64_27:
+ return "64:27";
+ case HDMI_PICTURE_ASPECT_256_135:
+ return "256:135";
case HDMI_PICTURE_ASPECT_RESERVED:
return "Reserved";
}
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index e974420..edbb4fc 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
HDMI_PICTURE_ASPECT_NONE,
HDMI_PICTURE_ASPECT_4_3,
HDMI_PICTURE_ASPECT_16_9,
+ HDMI_PICTURE_ASPECT_64_27,
+ HDMI_PICTURE_ASPECT_256_135,
HDMI_PICTURE_ASPECT_RESERVED,
};
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/5] drm: Add aspect ratio parsing in DRM layer
Current DRM layer functions dont parse aspect ratio information
while converting a user mode->kernel mode or viceversa. This
causes modeset to pick mode with wrong aspect ratio, eventually
cauing failures in HDMI compliance test cases, due to wrong VIC.
This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).
Signed-off-by: Shashank Sharma
Signed-off-by: Lin, Jia
Signed-off-by: Akashdeep Sharma
---
drivers/gpu/drm/drm_modes.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 20775c0..7824a63 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -939,6 +939,9 @@ bool drm_mode_equal_no_clocks(const struct drm_display_mode
*mode1, const struct
(mode2->flags & DRM_MODE_FLAG_3D_MASK))
return false;
+ if (mode1->picture_aspect_ratio != mode2->picture_aspect_ratio)
+ return false;
+
return drm_mode_equal_no_clocks_no_stereo(mode1, mode2);
}
EXPORT_SYMBOL(drm_mode_equal_no_clocks);
@@ -967,6 +970,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct
drm_display_mode *mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
+ mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
(mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
@@ -1470,6 +1474,22 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+ out->flags &= ~DRM_MODE_FLAG_PARMASK;
+
+ switch (in->picture_aspect_ratio) {
+ case HDMI_PICTURE_ASPECT_4_3:
+ out->flags |= DRM_MODE_FLAG_PAR4_3;
+ break;
+ case HDMI_PICTURE_ASPECT_16_9:
+ out->flags |= DRM_MODE_FLAG_PAR16_9;
+ break;
+ case HDMI_PICTURE_ASPECT_NONE:
+ case HDMI_PICTURE_ASPECT_RESERVED:
+ default:
+ out->flags |= DRM_MODE_FLAG_PARNONE;
+ break;
+ }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
}
@@ -1515,6 +1535,20 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
+ /* Clearing picture aspect ratio bits from out flags */
+ out->flags &= ~DRM_MODE_FLAG_PARMASK;
+
+ switch (in->flags & DRM_MODE_FLAG_PARMASK) {
+ case DRM_MODE_FLAG_PAR4_3:
+ out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+ break;
+ case DRM_MODE_FLAG_PAR16_9:
+ out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+ break;
+ default:
+ out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+ }
+
out->status = drm_mode_validate_basic(out);
if (out->status != MODE_OK)
goto out;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/bxt: Fix DSI HW state readout
reviewed-by: Shashank Sharma
Regards
Shashank
-Original Message-
From: Deak, Imre
Sent: Thursday, March 24, 2016 4:12 PM
To: intel-gfx@lists.freedesktop.org
Cc: Ville Syrjälä; Sharma, Shashank; Shankar, Uma; Nikula, Jani
Subject: [PATCH v3] drm/i915/bxt: Fix DSI HW state readout
Currently the machine hangs during booting while accessing the
BXT_MIPI_PORT_CTRL register during pipe HW state readout. After some
experimentation I found that the hang is caused by the DSI PLL being disabled,
or it being enabled but with an incorrect divider configuration. Enabling the
PLL got rid of the boot problem, so fix this by checking the PLL enabled
state/configuration before attempting to read out the HW state.
The DSI_PLL_ENABLE register is in the always-on power well, while the
BXT_DSI_PLL_CTL is in power well 0. This isn't exactly matched by the
transcoder power domain, but what we really need is just a runtime PM
reference, which is provided by any power domain.
Ville also found this dependency specified in BSpec, so I added a reference to
that too.
v2:
- Make sure we hold a power reference while accessing the PLL registers.
v3: (Jani)
- Simplify check in bxt_get_dsi_transcoder_state()
- Add comment explaining why we check for valid dividers in
bxt_dsi_pll_is_enabled()
CC: Shashank Sharma
CC: Uma Shankar
CC: Jani Nikula
Fixes: c6c794a2fc5e ("drm/i915/bxt: Initialize MIPI DSI for BXT")
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_reg.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 11 ++
drivers/gpu/drm/i915/intel_dsi.c | 9
drivers/gpu/drm/i915/intel_dsi.h | 1 +
drivers/gpu/drm/i915/intel_dsi_pll.c | 40
5 files changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f3ba43c..c839ce9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7811,9 +7811,11 @@ enum skl_disp_power_wells {
#define BXT_DSIC_16X_BY2 (1 << 10)
#define BXT_DSIC_16X_BY3 (2 << 10)
#define BXT_DSIC_16X_BY4 (3 << 10)
+#define BXT_DSIC_16X_MASK (3 << 10)
#define BXT_DSIA_16X_BY2 (1 << 8)
#define BXT_DSIA_16X_BY3 (2 << 8)
#define BXT_DSIA_16X_BY4 (3 << 8)
+#define BXT_DSIA_16X_MASK (3 << 8)
#define BXT_DSI_FREQ_SEL_SHIFT8
#define BXT_DSI_FREQ_SEL_MASK (0xF << BXT_DSI_FREQ_SEL_SHIFT)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 009b03b..e05393e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -36,6 +36,7 @@
#include "intel_drv.h"
#include
#include "i915_drv.h"
+#include "intel_dsi.h"
#include "i915_trace.h"
#include
#include
@@ -9867,6 +9868,16 @@ static bool bxt_get_dsi_transcoder_state(struct
intel_crtc *crtc,
continue;
*power_domain_mask |= BIT(power_domain);
+ /*
+* The PLL needs to be enabled with a valid divider
+* configuration, otherwise accessing DSI registers will hang
+* the machine. See BSpec North Display Engine
+* registers/MIPI[BXT]. We can break out here early, since we
+* need the same DSI PLL to be enabled for both DSI ports.
+*/
+ if (!intel_dsi_pll_is_enabled(dev_priv))
+ break;
+
/* XXX: this works for video mode only */
tmp = I915_READ(BXT_MIPI_PORT_CTRL(port));
if (!(tmp & DPI_ENABLE))
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 96ea3f7..0de74e1 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -684,6 +684,14 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
*encoder,
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
return false;
+ /*
+* On Broxton the PLL needs to be enabled with a valid divider
+* configuration, otherwise accessing DSI registers will hang the
+* machine. See BSpec North Display Engine registers/MIPI[BXT].
+*/
+ if (IS_BROXTON(dev_priv) && !intel_dsi_pll_is_enabled(dev_priv))
+ goto out_put_power;
+
/* XXX: this only works for one DSI output */
for_each_dsi_port(port, intel_dsi->ports) {
i915_reg_t ctrl_reg = IS_BROXTON(dev) ?
@@ -726,6 +734,7 @@ static bool intel_dsi_get_hw_state(struct intel_encoder
*encoder,
break;
}
+out_put_power:
intel_display_power_put(dev_priv, power_domain);
return active;
diff --git a/drivers/gpu/drm/i915/intel_dsi.h b/drivers/gpu/drm/i915/intel_dsi.h
index e582ef8..ec58ead 100644
--- a/drivers/gpu/drm/i915/intel_dsi.h
+++ b/drivers/gpu/drm/
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm: Add new DCS commands in the enum list
== Series Details == Series: series starting with [1/3] drm: Add new DCS commands in the enum list URL : https://patchwork.freedesktop.org/series/4849/ State : success == Summary == Series 4849v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/4849/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> PASS (bsw-nuc-2) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-c-frame-sequence: pass -> SKIP (bsw-nuc-2) Subgroup suspend-read-crc-pipe-c: incomplete -> PASS (hsw-gt2) bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:192 pass:154 dwarn:0 dfail:0 fail:0 skip:38 byt-nuc total:192 pass:156 dwarn:1 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:192 pass:181 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1702/ 79ee42317266a82b932a39e9567244ed91dd27d6 drm-intel-nightly: 2016y-03m-24d-10h-26m-54s UTC integration manifest d4f53f704b2e53d4c4bab0b0505690cda217b632 drm/i915: CABC support for backlight control db45da17126806341102dc7ce31a295abea44595 drm/i915: Parsing the PWM cntrl and CABC ON/OFF fileds in VBT ee106190a0ef5a19a18b7a6488d76c04047e1a17 drm: Add new DCS commands in the enum list ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Cache some registers in execlists hot paths
On 24/03/16 11:16, Chris Wilson wrote:
On Wed, Mar 23, 2016 at 03:15:02PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
GCC cannot optimize well calculations hidden in macros and
assigned to temporary structures. We can cache the register in
ELSP write, and refactor reading of the CSB a bit to enable
it to do a better job.
Code is still equally readable but the generated body of the
CSB read loop is 30% smaller, and since that loop runs at
least once per interrupt, which in turn can fire in tens or
hundreds thousands times per second, must be of some value.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 26 +-
drivers/gpu/drm/i915/intel_lrc.h | 11 ---
2 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3a23b9549f7b..67592f8354d6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -361,8 +361,8 @@ static void execlists_elsp_write(struct
drm_i915_gem_request *rq0,
{
struct intel_engine_cs *engine = rq0->engine;
- struct drm_device *dev = engine->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_i915_private *dev_priv = rq0->i915;
+ i915_reg_t elsp_reg = RING_ELSP(engine);
If we are going to open-code it, how about going whole hog
and
/* We opencode I915_WRITE_FW(RING_ELSP(engine)) here to save gcc the
* trouble of doing so - gcc fails miserably!
*/
u32 *elsp = rq->i915->regs + i915_mmio_reg_offset(RING_ELSP(engine));
then use writel(upper_32_bits(desc[1]), elsp);
Keeping the comment around for grepping.
Yeah I had that but thought it will be considered to tasteless for
posting. :)
uint64_t desc[2];
if (rq1) {
@@ -376,12 +376,12 @@ static void execlists_elsp_write(struct
drm_i915_gem_request *rq0,
rq0->elsp_submitted++;
/* You must always write both descriptors in the order below. */
- I915_WRITE_FW(RING_ELSP(engine), upper_32_bits(desc[1]));
- I915_WRITE_FW(RING_ELSP(engine), lower_32_bits(desc[1]));
+ I915_WRITE_FW(elsp_reg, upper_32_bits(desc[1]));
+ I915_WRITE_FW(elsp_reg, lower_32_bits(desc[1]));
- I915_WRITE_FW(RING_ELSP(engine), upper_32_bits(desc[0]));
+ I915_WRITE_FW(elsp_reg, upper_32_bits(desc[0]));
/* The context is automatically loaded after the following */
- I915_WRITE_FW(RING_ELSP(engine), lower_32_bits(desc[0]));
+ I915_WRITE_FW(elsp_reg, lower_32_bits(desc[0]));
/* ELSP is a wo register, use another nearby reg for posting */
POSTING_READ_FW(RING_EXECLIST_STATUS_LO(engine));
Observing the above, we can also kill the POSTING_READ_FW() which will
make a much bigger improvement than all of the above.
It is a different register, why it can be removed?
@@ -517,21 +517,19 @@ execlists_check_remove_request(struct intel_engine_cs
*engine, u32 request_id)
}
static u32
-get_context_status(struct intel_engine_cs *engine, unsigned int read_pointer,
- u32 *context_id)
+get_context_status(struct drm_i915_private *dev_priv, u32 csb_base,
+ unsigned int read_pointer, u32 *context_id)
{
- struct drm_i915_private *dev_priv = engine->dev->dev_private;
u32 status;
read_pointer %= GEN8_CSB_ENTRIES;
- status = I915_READ_FW(RING_CONTEXT_STATUS_BUF_LO(engine, read_pointer));
+ status = I915_READ_FW(RING_CSB_LO(csb_base, read_pointer));
If we forgo the "convenience" interface here, could we not also improve
the readability of the code by just having the csb ringbuffer and readl?
The same whole-hog open coding you mean like the above? It is slightly
more efficient, not sure that is is more readable so maybe I am not
getting exactly what you mean.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] commit 1b82b7b48d17b4b3401e9d82b0fe86df06c8d451 breaks here
Caused by "sna/present: Cancel pending unflips when resizing the screen". ... make[3]: Entering directory `/home/wearefam/src/xserver-xorg-video-intel/xf86-video-intel-git/src' CC backlight.lo CC fd.lo CC intel_device.lo CC intel_options.lo CC intel_module.lo CCLD intel_drv.la sna/.libs/libsna.a(kgem.o): In function `sna_present_cancel_flip': kgem.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_accel.o): In function `sna_present_cancel_flip': sna_accel.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_acpi.o): In function `sna_present_cancel_flip': sna_acpi.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_blt.o): In function `sna_present_cancel_flip': sna_blt.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_composite.o): In function `sna_present_cancel_flip': sna_composite.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_cpu.o): In function `sna_present_cancel_flip': sna_cpu.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_damage.o): In function `sna_present_cancel_flip': sna_damage.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_display.o): In function `sna_present_cancel_flip': sna_display.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_display_fake.o): In function `sna_present_cancel_flip': sna_display_fake.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_driver.o): In function `sna_present_cancel_flip': sna_driver.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_glyphs.o): In function `sna_present_cancel_flip': sna_glyphs.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_gradient.o): In function `sna_present_cancel_flip': sna_gradient.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_io.o): In function `sna_present_cancel_flip': sna_io.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_render.o): In function `sna_present_cancel_flip': sna_render.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_stream.o): In function `sna_present_cancel_flip': sna_stream.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_trapezoids.o): In function `sna_present_cancel_flip': sna_trapezoids.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_trapezoids_boxes.o): In function `sna_present_cancel_flip': sna_trapezoids_boxes.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_trapezoids_imprecise.o): In function `sna_present_cancel_flip': sna_trapezoids_imprecise.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_trapezoids_mono.o): In function `sna_present_cancel_flip': sna_trapezoids_mono.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_trapezoids_precise.o): In function `sna_present_cancel_flip': sna_trapezoids_precise.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_tiling.o): In function `sna_present_cancel_flip': sna_tiling.c:(.text+0x0): multiple definition of `sna_present_cancel_flip' sna/.libs/libsna.a(blt.o):blt.c:(.text+0x0): first defined here sna/.libs/libsna.a(sna_transform.o): In function `sna_present_cancel_flip': sna_transform.c:(.text+0x0): multiple definition of `sna_present_cancel_fl
Re: [Intel-gfx] [PATCH] drm/i915: Replace some more busy waits with normal ones
On 23/03/16 16:40, Chris Wilson wrote: On Wed, Mar 23, 2016 at 04:24:48PM +, Tvrtko Ursulin wrote: Biggest thing to make sure is that you don't add a lot of cycles to the forcewake loops since for example fw_domains_get can be the hottest i915 function on some benchmarks. (This area slightly annoys me anyway with redundant looping over forcewake domains and we could also potentially optimize the ack waiting by first requesting all we want, and then doing the waits. That would be one additional loop, but if removed the other one, code would stay at the same number of domain loops.) I hear you. I just end up weeping in the corner when I see fw_domain_get on the profile. We already do have a mitigation scheme to hold onto the forcewake for an extra jiffie every time. I don't like it, but without it fw_domains_get becomes a real hog. I am pretty sure I've seen some tests which somehow defeat the jiffie delay and we end up re-acquiring every ms/jiffie. This is something I wanted to get to the bottom of but did not get round to yet. It was totally unexpected because the test is hammering on everything. Note that one thing we can actually do is restrict the domains we wakeup for the engines (engine->fw_domain) in execlists_submit, that should help chv/skl+ a small amount. I even have a patch to do that somewhere. :) I don't have a good idea for how to keep rc6 residency high but avoid forcewake when those darn elsp require forcewake. As does gen6+ legacy RING_TAIL writes. And even then that spinlock causes quite a bit of traffic when it shouldn't be contended. I've been thinking of whether we can have multiple locks (hashed by register) but we would then still need some cross-communication for the common forcewake. Maybe it is not worth it at this point. This is pretty well optimised now and could switch to the next target. Like maybe move to active and retire__read, or retired_req_list, or something. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: fix potential dangling else problems in for_each_ macros (rev3)
On 24/03/16 09:06, Patchwork wrote: == Series Details == Series: drm/i915: fix potential dangling else problems in for_each_ macros (rev3) URL : https://patchwork.freedesktop.org/series/1142/ State : failure == Summary == Series 1142v3 drm/i915: fix potential dangling else problems in for_each_ macros http://patchwork.freedesktop.org/api/1.0/series/1142/revisions/3/mbox/ Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (snb-x220t) Already filed, https://bugs.freedesktop.org/show_bug.cgi?id=94294 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: dmesg-warn -> PASS (bsw-nuc-2) pass -> DMESG-WARN (byt-nuc) Ditto, https://bugs.freedesktop.org/show_bug.cgi?id=94164 Subgroup basic-rte: dmesg-warn -> PASS (byt-nuc) UNSTABLE bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:192 pass:155 dwarn:0 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:156 dwarn:1 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ilk-hp8440p total:192 pass:129 dwarn:0 dfail:0 fail:0 skip:63 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:192 pass:181 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:157 dwarn:0 dfail:0 fail:2 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1699/ 8f2e9bbc15607f56261aefd7a1f8caf6909c6b9d drm-intel-nightly: 2016y-03m-23d-17h-03m-10s UTC integration manifest c4613575f37039f81f8969a4e805a80ff0a64ef9 drm/i915: replace for_each_engine() 31beb6168bc53ad8b3fe008dcaa2ae038743a252 drm/i915: introduce for_each_engine_id() ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] commit 1b82b7b48d17b4b3401e9d82b0fe86df06c8d451 breaks here
On Thu, Mar 24, 2016 at 12:33:24PM +0100, Sedat Dilek wrote: > Caused by "sna/present: Cancel pending unflips when resizing the screen". Sorry, commit c326ed192bcaeea41bb93b7077ec37a1437a4409 Author: Chris Wilson Date: Thu Mar 24 11:38:35 2016 + sna/present: Add missing "static inline" for disabled present stubs -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 v2] drm/i915: Move execlists irq handler to a bottom half
On 24/03/16 10:56, Chris Wilson wrote:
On Wed, Mar 23, 2016 at 02:57:36PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Doing a lot of work in the interrupt handler introduces huge
latencies to the system as a whole.
Most dramatic effect can be seen by running an all engine
stress test like igt/gem_exec_nop/all where, when the kernel
config is lean enough, the whole system can be brought into
multi-second periods of complete non-interactivty. That can
look for example like this:
NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u8:3:143]
Modules linked in: [redacted for brevity]
CPU: 0 PID: 143 Comm: kworker/u8:3 Tainted: G U L 4.5.0-160321+
#183
Hardware name: Intel Corporation Broadwell Client platform/WhiteTip Mountain 1
Workqueue: i915 gen6_pm_rps_work [i915]
task: 8800aae88000 ti: 8800aae9 task.ti: 8800aae9
RIP: 0010:[] [] __do_softirq+0x72/0x1d0
RSP: :88014f403f38 EFLAGS: 0206
RAX: 8800aae94000 RBX: RCX: 06e0
RDX: 0020 RSI: 04208060 RDI: 00215d80
RBP: 88014f403f80 R08: 000b1b42c180 R09: 0022
R10: 0004 R11: R12: a030
R13: 0082 R14: 8800aa4d0080 R15: 0082
FS: () GS:88014f40() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 7fa53b90c000 CR3: 01a0a000 CR4: 001406f0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Stack:
042080601b33869f 8800aae94000 fffc2678 8801000a
a030 5302 8800aa4d0080
0206 88014f403f90 8104a716 88014f403fa8
Call Trace:
[] irq_exit+0x86/0x90
[] smp_apic_timer_interrupt+0x3d/0x50
[] apic_timer_interrupt+0x7c/0x90
[] ? gen8_write64+0x1a0/0x1a0 [i915]
[] ? _raw_spin_unlock_irqrestore+0x9/0x20
[] gen8_write32+0x104/0x1a0 [i915]
[] ? n_tty_receive_buf_common+0x372/0xae0
[] gen6_set_rps_thresholds+0x1be/0x330 [i915]
[] gen6_set_rps+0x70/0x200 [i915]
[] intel_set_rps+0x25/0x30 [i915]
[] gen6_pm_rps_work+0x10d/0x2e0 [i915]
[] ? finish_task_switch+0x72/0x1c0
[] process_one_work+0x139/0x350
[] worker_thread+0x126/0x490
[] ? rescuer_thread+0x320/0x320
[] kthread+0xc4/0xe0
[] ? kthread_create_on_node+0x170/0x170
[] ret_from_fork+0x3f/0x70
[] ? kthread_create_on_node+0x170/0x170
I could not explain, or find a code path, which would explain
a +20 second lockup, but from some instrumentation it was
apparent the interrupts off proportion of time was between
10-25% under heavy load which is quite bad.
By moving the GT interrupt handling to a tasklet in a most
simple way, the problem above disappears completely.
Perfect segue into gem_syslatency. I think gem_syslatency is the better
tool to correlate disruptive system behaviour. And then continue on with
gem_latency to demonstrate that is doesn't adversely affect our
performance.
Will do.
Also, gem_latency -n 100 shows 25% better throughput and CPU
usage, and 14% better latencies.
Mention the benefits of parallelising dispatch.
Hm, actually this should be the same as before I think.
As fairly hit-and-miss as perf testing is on these machines, it is
looking in favour of using tasklets vs the rt kthread. The numbers swing
between 2-10%, but consistently improves in the nop sync latencies.
There's still several hours to go in this run before we cover the
dispatch latenies, but so far reasonable.
(Hmm, looks like there may be a possible degredation on the single nop
dispatch but an improvement on the continuous nop dispatch.)
We can add all the numbers you get to the commit message as well.
I did not find any gains or regressions with Synmark2 or
GLbench under light testing. More benchmarking is certainly
required.
v2:
* execlists_lock should be taken as spin_lock_bh when
queuing work from userspace now. (Chris Wilson)
* uncore.lock must be taken with spin_lock_irq when
submitting requests since that now runs from either
softirq or process context.
There are a couple of execlist_lock usage outside of intel_lrc that may
or may not be useful to convert (low frequency reset / debug paths, so
way off the critical paths, but consistency in locking is invaluable).
Oh right, I've missed those.
+ tasklet_init(&engine->irq_tasklet, intel_lrc_irq_handler,
+(unsigned long)engine);
I like trying to split lines to cluster arguments if possible. Here I
think intel_lrc_irq_handler pairs with engine,
tasklet_init(&engine->irq_tasklet,
intel_lrc_irq_handler, (unsigned long)engine);
*shrug*
Yeah it is nicer.
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/
Re: [Intel-gfx] commit 1b82b7b48d17b4b3401e9d82b0fe86df06c8d451 breaks here
On Thu, Mar 24, 2016 at 12:40 PM, Chris Wilson wrote: > On Thu, Mar 24, 2016 at 12:33:24PM +0100, Sedat Dilek wrote: >> Caused by "sna/present: Cancel pending unflips when resizing the screen". > > Sorry, > > commit c326ed192bcaeea41bb93b7077ec37a1437a4409 > Author: Chris Wilson > Date: Thu Mar 24 11:38:35 2016 + > > sna/present: Add missing "static inline" for disabled present stubs Builds fines. Thanks. - Sedat - ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Cache some registers in execlists hot paths
On Thu, Mar 24, 2016 at 11:31:34AM +, Tvrtko Ursulin wrote:
>
> On 24/03/16 11:16, Chris Wilson wrote:
> >On Wed, Mar 23, 2016 at 03:15:02PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>GCC cannot optimize well calculations hidden in macros and
> >>assigned to temporary structures. We can cache the register in
> >>ELSP write, and refactor reading of the CSB a bit to enable
> >>it to do a better job.
> >>
> >>Code is still equally readable but the generated body of the
> >>CSB read loop is 30% smaller, and since that loop runs at
> >>least once per interrupt, which in turn can fire in tens or
> >>hundreds thousands times per second, must be of some value.
> >>
> >>Signed-off-by: Tvrtko Ursulin
> >>---
> >> drivers/gpu/drm/i915/intel_lrc.c | 26 +-
> >> drivers/gpu/drm/i915/intel_lrc.h | 11 ---
> >> 2 files changed, 21 insertions(+), 16 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> >>b/drivers/gpu/drm/i915/intel_lrc.c
> >>index 3a23b9549f7b..67592f8354d6 100644
> >>--- a/drivers/gpu/drm/i915/intel_lrc.c
> >>+++ b/drivers/gpu/drm/i915/intel_lrc.c
> >>@@ -361,8 +361,8 @@ static void execlists_elsp_write(struct
> >>drm_i915_gem_request *rq0,
> >> {
> >>
> >>struct intel_engine_cs *engine = rq0->engine;
> >>- struct drm_device *dev = engine->dev;
> >>- struct drm_i915_private *dev_priv = dev->dev_private;
> >>+ struct drm_i915_private *dev_priv = rq0->i915;
> >>+ i915_reg_t elsp_reg = RING_ELSP(engine);
> >
> >If we are going to open-code it, how about going whole hog
> >and
> >
> >/* We opencode I915_WRITE_FW(RING_ELSP(engine)) here to save gcc the
> > * trouble of doing so - gcc fails miserably!
> > */
> >u32 *elsp = rq->i915->regs + i915_mmio_reg_offset(RING_ELSP(engine));
> >then use writel(upper_32_bits(desc[1]), elsp);
> >
> >Keeping the comment around for grepping.
>
> Yeah I had that but thought it will be considered to tasteless for
> posting. :)
>
> >>uint64_t desc[2];
> >>
> >>if (rq1) {
> >>@@ -376,12 +376,12 @@ static void execlists_elsp_write(struct
> >>drm_i915_gem_request *rq0,
> >>rq0->elsp_submitted++;
> >>
> >>/* You must always write both descriptors in the order below. */
> >>- I915_WRITE_FW(RING_ELSP(engine), upper_32_bits(desc[1]));
> >>- I915_WRITE_FW(RING_ELSP(engine), lower_32_bits(desc[1]));
> >>+ I915_WRITE_FW(elsp_reg, upper_32_bits(desc[1]));
> >>+ I915_WRITE_FW(elsp_reg, lower_32_bits(desc[1]));
> >>
> >>- I915_WRITE_FW(RING_ELSP(engine), upper_32_bits(desc[0]));
> >>+ I915_WRITE_FW(elsp_reg, upper_32_bits(desc[0]));
> >>/* The context is automatically loaded after the following */
> >>- I915_WRITE_FW(RING_ELSP(engine), lower_32_bits(desc[0]));
> >>+ I915_WRITE_FW(elsp_reg, lower_32_bits(desc[0]));
> >>
> >>/* ELSP is a wo register, use another nearby reg for posting */
> >>POSTING_READ_FW(RING_EXECLIST_STATUS_LO(engine));
> >
> >Observing the above, we can also kill the POSTING_READ_FW() which will
> >make a much bigger improvement than all of the above.
>
> It is a different register, why it can be removed?
We use uncached mmio writes. The POSTING_READs are primarily for
documentation about where we need the write barriers to flush the WC
buffer (which we don't use nor are we ever going to because HW forbids
us). However they are most painful at times.
> >>@@ -517,21 +517,19 @@ execlists_check_remove_request(struct intel_engine_cs
> >>*engine, u32 request_id)
> >> }
> >>
> >> static u32
> >>-get_context_status(struct intel_engine_cs *engine, unsigned int
> >>read_pointer,
> >>- u32 *context_id)
> >>+get_context_status(struct drm_i915_private *dev_priv, u32 csb_base,
> >>+ unsigned int read_pointer, u32 *context_id)
> >> {
> >>- struct drm_i915_private *dev_priv = engine->dev->dev_private;
> >>u32 status;
> >>
> >>read_pointer %= GEN8_CSB_ENTRIES;
> >>
> >>- status = I915_READ_FW(RING_CONTEXT_STATUS_BUF_LO(engine, read_pointer));
> >>+ status = I915_READ_FW(RING_CSB_LO(csb_base, read_pointer));
> >
> >If we forgo the "convenience" interface here, could we not also improve
> >the readability of the code by just having the csb ringbuffer and readl?
>
> The same whole-hog open coding you mean like the above? It is
> slightly more efficient, not sure that is is more readable so maybe
> I am not getting exactly what you mean.
I think it will be. Even more so we say "we're x86 only and use u32 *
__iomem csb" ;)
quick draft
t a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 40ef4ea..b7d2ae9 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -516,26 +516,6 @@ execlists_check_remove_request(struct intel_engine_cs
*engine, u32 request_id)
return 1;
}
-static u32
-get_context_status(struct intel_engine_cs *engine, unsigned int read_pointer,
- u32 *context_id)
-{
- struct drm_i915_private *dev_priv =
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bxt: Fix DSI HW state readout (rev3)
== Series Details == Series: drm/i915/bxt: Fix DSI HW state readout (rev3) URL : https://patchwork.freedesktop.org/series/4832/ State : success == Summary == Series 4832v3 drm/i915/bxt: Fix DSI HW state readout http://patchwork.freedesktop.org/api/1.0/series/4832/revisions/3/mbox/ Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> PASS (bsw-nuc-2) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: incomplete -> PASS (hsw-gt2) bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:192 pass:155 dwarn:0 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:156 dwarn:1 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:192 pass:181 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1703/ 79ee42317266a82b932a39e9567244ed91dd27d6 drm-intel-nightly: 2016y-03m-24d-10h-26m-54s UTC integration manifest 8e94bd5898ec48db5dcfed6dbbe1cf1e9ac2499f drm/i915/bxt: Fix DSI HW state readout ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/9] drm/i915/dsi: refer to gpio index instead of gpio to avoid confusion
Housekeeping stuff.
Reviewed-by: Mika Kahola
On Fri, 2016-03-18 at 13:11 +0200, Jani Nikula wrote:
> The DSI sequence blocks contain gpio index references, not actual gpio
> numbers. No functional changes.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> index 8302a972d2d4..f687b2e9d8ca 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> @@ -198,7 +198,7 @@ static const u8 *mipi_exec_delay(struct intel_dsi
> *intel_dsi, const u8 *data)
>
> static const u8 *mipi_exec_gpio(struct intel_dsi *intel_dsi, const u8 *data)
> {
> - u8 gpio, action;
> + u8 gpio_index, action;
> u16 function, pad;
> u32 val;
> struct drm_device *dev = intel_dsi->base.base.dev;
> @@ -207,13 +207,13 @@ static const u8 *mipi_exec_gpio(struct intel_dsi
> *intel_dsi, const u8 *data)
> if (dev_priv->vbt.dsi.seq_version >= 3)
> data++;
>
> - gpio = *data++;
> + gpio_index = *data++;
>
> /* pull up/down */
> action = *data++ & 1;
>
> - if (gpio >= ARRAY_SIZE(gtable)) {
> - DRM_DEBUG_KMS("unknown gpio %u\n", gpio);
> + if (gpio_index >= ARRAY_SIZE(gtable)) {
> + DRM_DEBUG_KMS("unknown gpio index %u\n", gpio_index);
> goto out;
> }
>
> @@ -227,16 +227,16 @@ static const u8 *mipi_exec_gpio(struct intel_dsi
> *intel_dsi, const u8 *data)
> goto out;
> }
>
> - function = gtable[gpio].function_reg;
> - pad = gtable[gpio].pad_reg;
> + function = gtable[gpio_index].function_reg;
> + pad = gtable[gpio_index].pad_reg;
>
> mutex_lock(&dev_priv->sb_lock);
> - if (!gtable[gpio].init) {
> + if (!gtable[gpio_index].init) {
> /* program the function */
> /* FIXME: remove constant below */
> vlv_iosf_sb_write(dev_priv, IOSF_PORT_GPIO_NC, function,
> 0x2000CC00);
> - gtable[gpio].init = 1;
> + gtable[gpio_index].init = 1;
> }
>
> val = 0x4 | action;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 112/190] drm/i915: Move obj->active:5 to obj->flags
On Mon, Jan 11, 2016 at 10:44:56AM +, Chris Wilson wrote:
> We are motivated to avoid using a bitfield for obj->active for a couple
> of reasons. Firstly, we wish to document our lockless read of obj->active
> using READ_ONCE inside i915_gem_busy_ioctl() and that requires an
> integral type (i.e. not a bitfield). Secondly, gcc produces abysmal code
> when presented with a bitfield and that shows up high on the profiles of
> request tracking (mainly due to excess memory traffic as it converts
> the bitfield to a register and back and generates frequent AGI in the
> process).
>
> Signed-off-by: Chris Wilson
This patch, together with it's dirty counterpart, seems to make a lot of sense,
but it seems the pre-requisites to make it apply are rather extensive;
I tried to tweak it to apply to a nightly, but that's not trivial.
Still, the concept seems sounds. I dunno if there's much point of this
right now, since it cannot be merged without the pre-requisites, but:
Reviewed-by: David Weinehall
> ---
> drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
> drivers/gpu/drm/i915/i915_drv.h| 31
> +-
> drivers/gpu/drm/i915/i915_gem.c| 20 +--
> drivers/gpu/drm/i915/i915_gem_batch_pool.c | 4 ++--
> drivers/gpu/drm/i915/i915_gem_context.c| 2 +-
> drivers/gpu/drm/i915/i915_gem_execbuffer.c | 10 +-
> drivers/gpu/drm/i915/i915_gem_gtt.c| 2 +-
> drivers/gpu/drm/i915/i915_gem_shrinker.c | 5 +++--
> 8 files changed, 53 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index dee66807c6bd..6b14c59828e3 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -136,7 +136,7 @@ describe_obj(struct seq_file *m, struct
> drm_i915_gem_object *obj)
>
> seq_printf(m, "%pK: %s%s%s%s %8zdKiB %02x %02x [ ",
> &obj->base,
> -obj->active ? "*" : " ",
> +i915_gem_object_is_active(obj) ? "*" : " ",
> get_pin_flag(obj),
> get_tiling_flag(obj),
> get_global_flag(obj),
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index efa43411f0eb..1ecff535973e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2031,12 +2031,16 @@ struct drm_i915_gem_object {
>
> struct list_head batch_pool_link;
>
> + unsigned long flags;
> /**
>* This is set if the object is on the active lists (has pending
>* rendering and so a non-zero seqno), and is not set if it i s on
>* inactive (ready to be unbound) list.
>*/
> - unsigned int active:I915_NUM_RINGS;
> +#define I915_BO_ACTIVE_SHIFT 0
> +#define I915_BO_ACTIVE_MASK ((1 << I915_NUM_RINGS) - 1)
> +#define I915_BO_ACTIVE(bo) ((bo)->flags & (I915_BO_ACTIVE_MASK <<
> I915_BO_ACTIVE_SHIFT))
> +#define __I915_BO_ACTIVE(bo) (READ_ONCE((bo)->flags) & (I915_BO_ACTIVE_MASK
> << I915_BO_ACTIVE_SHIFT))
>
> /**
>* This is set if the object has been written to since last bound
> @@ -2151,6 +2155,31 @@ struct drm_i915_gem_object {
> #define GEM_BUG_ON(expr)
> #endif
>
> +static inline bool
> +i915_gem_object_is_active(const struct drm_i915_gem_object *obj)
> +{
> + return obj->flags & (I915_BO_ACTIVE_MASK << I915_BO_ACTIVE_SHIFT);
> +}
> +
> +static inline void
> +i915_gem_object_set_active(struct drm_i915_gem_object *obj, int engine)
> +{
> + obj->flags |= 1 << (engine + I915_BO_ACTIVE_SHIFT);
> +}
> +
> +static inline void
> +i915_gem_object_unset_active(struct drm_i915_gem_object *obj, int engine)
> +{
> + obj->flags &= ~(1 << (engine + I915_BO_ACTIVE_SHIFT));
> +}
> +
> +static inline bool
> +i915_gem_object_has_active_engine(const struct drm_i915_gem_object *obj,
> + int engine)
> +{
> + return obj->flags & (1 << (engine + I915_BO_ACTIVE_SHIFT));
> +}
> +
> void i915_gem_track_fb(struct drm_i915_gem_object *old,
> struct drm_i915_gem_object *new,
> unsigned frontbuffer_bits);
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 74c56716a304..6712ecf1239b 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1130,7 +1130,7 @@ i915_gem_object_wait_rendering(struct
> drm_i915_gem_object *obj,
> {
> int ret, i;
>
> - if (!obj->active)
> + if (!i915_gem_object_is_active(obj))
> return 0;
>
> if (readonly) {
> @@ -1143,7 +1143,7 @@ i915_gem_object_wait_rendering(struct
> drm_i915_gem_object *obj,
> if (ret)
> return ret;
> }
> - GEM_BUG_ON(obj->active);
> + GEM_BUG_ON(i915_gem_object_is_active(obj));
> }
>
> return 0;
> @@ -1165,7 +1165,7 @@ i91
[Intel-gfx] [PATCH 1/2] drm/i915: Update VBT fields for child devices
This patch adds new fields that are not yet added in drm code
in child devices struct
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Durgadoss R
Signed-off-by: Shubhangi Shrivastava
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_bios.c | 15 ++-
drivers/gpu/drm/i915/intel_vbt_defs.h | 16 +++-
2 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 083003b..e2f636c 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1126,7 +1126,7 @@ static void parse_ddi_port(struct drm_i915_private
*dev_priv, enum port port,
}
/* Parse the I_boost config for SKL and above */
- if (bdb->version >= 196 && (child->common.flags_1 & IBOOST_ENABLE)) {
+ if (bdb->version >= 196 && child->common.iboost) {
info->dp_boost_level =
translate_iboost(child->common.iboost_level & 0xF);
DRM_DEBUG_KMS("VBT (e)DP boost level for port %c: %d\n",
port_name(port), info->dp_boost_level);
@@ -1244,6 +1244,19 @@ parse_device_mapping(struct drm_i915_private *dev_priv,
*/
memcpy(child_dev_ptr, p_child,
min_t(size_t, p_defs->child_dev_size, sizeof(*p_child)));
+
+ /*
+* copied full block, now init values when they are not
+* available in current version
+*/
+ if (bdb->version < 196) {
+ /* Set default values for bits added from v196 */
+ child_dev_ptr->common.iboost = 0;
+ child_dev_ptr->common.hpd_invert = 0;
+ }
+
+ if (bdb->version < 192)
+ child_dev_ptr->common.lspcon = 0;
}
return;
}
diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
b/drivers/gpu/drm/i915/intel_vbt_defs.h
index 749dcea..2da7be8 100644
--- a/drivers/gpu/drm/i915/intel_vbt_defs.h
+++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
@@ -261,9 +261,6 @@ struct old_child_dev_config {
* versions. Notice that the meaning of the contents contents may still change,
* but at least the offsets are consistent. */
-/* Definitions for flags_1 */
-#define IBOOST_ENABLE (1<<3)
-
struct common_child_dev_config {
u16 handle;
u16 device_type;
@@ -272,8 +269,17 @@ struct common_child_dev_config {
u8 not_common2[2];
u8 ddc_pin;
u16 edid_ptr;
- u8 obsolete;
- u8 flags_1;
+ u8 dvo_cfg; /* See DEVICE_CFG_* above */
+ u8 efp_routed:1;
+ u8 lane_reversal:1;
+ u8 lspcon:1;
+ u8 iboost:1;
+ u8 hpd_invert:1;
+ u8 flag_reserved:3;
+ u8 hdmi_support:1;
+ u8 dp_support:1;
+ u8 tmds_support:1;
+ u8 support_reserved:5;
u8 not_common3[13];
u8 iboost_level;
} __packed;
--
2.6.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Set invert bit for hpd based on VBT
This patch sets the invert bit for hpd detection for each port
based on VBT configuration. Since each AOB can be designed to
depend on invert bit or not, it is expected if an AOB requires
invert bit, the user will set respective bit in VBT.
v2: Separated VBT parsing from the rest of the logic. (Jani)
v3: Moved setting invert bit logic to bxt_hpd_irq_setup()
and changed its logic to avoid looping twice. (Ville)
v4: Changed the logic to mask out the bits first and then
set them to remove need of temporary variable. (Ville)
v5: Moved defines to existing set of defines for the register
Changed logic to incorporate required breaks. (Ville)
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Durgadoss R
Signed-off-by: Shubhangi Shrivastava
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_irq.c | 20
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_bios.c | 32
4 files changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9d29ab0..86fb5cb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3396,6 +3396,8 @@ bool intel_bios_is_tv_present(struct drm_i915_private
*dev_priv);
bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
*i2c_pin);
bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port port);
bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
*port);
+bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
+enum port port);
/* intel_opregion.c */
#ifdef CONFIG_ACPI
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a55a7cc..8fbec3e 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3504,6 +3504,26 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
hotplug = I915_READ(PCH_PORT_HOTPLUG);
hotplug |= PORTC_HOTPLUG_ENABLE | PORTB_HOTPLUG_ENABLE |
PORTA_HOTPLUG_ENABLE;
+
+ DRM_DEBUG_KMS("Invert bit setting: hp_ctl:%x hp_port:%x\n",
+ hotplug, enabled_irqs);
+ hotplug &= ~BXT_DDI_HPD_INVERT_MASK;
+
+ /*
+* For BXT invert bit has to be set based on AOB design
+* for HPD detection logic, update it based on VBT fields.
+*/
+
+ if ((enabled_irqs & BXT_DE_PORT_HP_DDIA) &&
+intel_bios_is_port_hpd_inverted(dev_priv, PORT_A))
+ hotplug |= BXT_DDIA_HPD_INVERT;
+ if ((enabled_irqs & BXT_DE_PORT_HP_DDIB) &&
+intel_bios_is_port_hpd_inverted(dev_priv, PORT_B))
+ hotplug |= BXT_DDIB_HPD_INVERT;
+ if ((enabled_irqs & BXT_DE_PORT_HP_DDIC) &&
+intel_bios_is_port_hpd_inverted(dev_priv, PORT_C))
+ hotplug |= BXT_DDIC_HPD_INVERT;
+
I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f3ba43c..73a806c 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6185,6 +6185,7 @@ enum skl_disp_power_wells {
/* digital port hotplug */
#define PCH_PORT_HOTPLUG _MMIO(0xc4030) /* SHOTPLUG_CTL */
#define PORTA_HOTPLUG_ENABLE (1 << 28) /* LPT:LP+ & BXT */
+#define BXT_DDIA_HPD_INVERT(1 << 27)
#define PORTA_HOTPLUG_STATUS_MASK (3 << 24) /* SPT+ & BXT */
#define PORTA_HOTPLUG_NO_DETECT (0 << 24) /* SPT+ & BXT */
#define PORTA_HOTPLUG_SHORT_DETECT(1 << 24) /* SPT+ & BXT */
@@ -6200,6 +6201,7 @@ enum skl_disp_power_wells {
#define PORTD_HOTPLUG_SHORT_DETECT(1 << 16)
#define PORTD_HOTPLUG_LONG_DETECT (2 << 16)
#define PORTC_HOTPLUG_ENABLE (1 << 12)
+#define BXT_DDIC_HPD_INVERT(1 << 11)
#define PORTC_PULSE_DURATION_2ms (0 << 10) /* pre-LPT */
#define PORTC_PULSE_DURATION_4_5ms(1 << 10) /* pre-LPT */
#define PORTC_PULSE_DURATION_6ms (2 << 10) /* pre-LPT */
@@ -6210,6 +6212,7 @@ enum skl_disp_power_wells {
#define PORTC_HOTPLUG_SHORT_DETECT(1 << 8)
#define PORTC_HOTPLUG_LONG_DETECT (2 << 8)
#define PORTB_HOTPLUG_ENABLE (1 << 4)
+#define BXT_DDIB_HPD_INVERT(1 << 3)
#define PORTB_PULSE_DURATION_2ms (0 << 2) /* pre-LPT */
#define PORTB_PULSE_DURATION_4_5ms(1 << 2) /* pre-LPT */
#define PORTB_PULSE_DURATION_6ms (2 << 2) /* pre-LPT */
@@ -6219,6 +6222,9 @@ enum skl_disp_power_wells {
#define PORTB_HOTPLUG_NO_DETECT (0 << 0)
#define PORTB_HOTPLUG_SHORT_DETECT(1 << 0)
#define PORTB_HOTPLUG_LONG_DETECT (2 << 0)
+#define BXT_DDI_HPD_INVERT_MASK (BXT_DDIA_HPD_INVERT | \
+ BXT_DDIB_HPD_INVERT | \
+ BXT_DDIC_HPD_INVERT)
#define PCH_PORT_HOTPLUG2
Re: [Intel-gfx] [PATCH 1/2] shmem: Support for registration of Driver/file owner specific ops
On ke, 2016-03-23 at 11:39 +0530, 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 need 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.
>
> Cc: Hugh Dickins
> Cc: linux...@kvack.org
> Signed-off-by: Sourab Gupta
> Signed-off-by: Akash Goel
> ---
> include/linux/shmem_fs.h | 17 +
> mm/shmem.c | 17 -
> 2 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
> index 4d4780c..6cfa76a 100644
> --- a/include/linux/shmem_fs.h
> +++ b/include/linux/shmem_fs.h
> @@ -34,11 +34,28 @@ struct shmem_sb_info {
> struct mempolicy *mpol; /* default memory policy for mappings */
> };
>
> +struct shmem_dev_info {
> + void *dev_private_data;
> + int (*dev_migratepage)(struct address_space *mapping,
> + struct page *newpage, struct page *page,
> + enum migrate_mode mode, void *dev_priv_data);
One might want to have a separate shmem_dev_operations struct or
similar.
> +};
> +
> static inline struct shmem_inode_info *SHMEM_I(struct inode *inode)
> {
> return container_of(inode, struct shmem_inode_info, vfs_inode);
> }
>
> +static inline int shmem_set_device_ops(struct address_space *mapping,
> + struct shmem_dev_info *info)
> +{
> + if (mapping->private_data != NULL)
> + return -EEXIST;
> +
I did a quick random peek and most set functions are just void and
override existing data. I'd suggest the same.
> + mapping->private_data = info;
Also, doesn't this kinda steal the mapping->private_data, might that be
unexpected for the user? I notice currently it's not being touched at
all.
> + return 0;
> +}
> +
> /*
> * Functions in mm/shmem.c called directly from elsewhere:
> */
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 440e2a7..f8625c4 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -952,6 +952,21 @@ redirty:
> 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->dev_migratepage)
> + return dev_info->dev_migratepage(mapping, newpage, page,
> + mode, dev_info->dev_private_data);
> +
> + return migrate_page(mapping, newpage, page, mode);
> +}
> +#endif
> +
> #ifdef CONFIG_NUMA
> #ifdef CONFIG_TMPFS
> static void shmem_show_mpol(struct seq_file *seq, struct mempolicy *mpol)
> @@ -3168,7 +3183,7 @@ static const struct address_space_operations shmem_aops
> = {
> .write_end = shmem_write_end,
> #endif
> #ifdef CONFIG_MIGRATION
> - .migratepage= migrate_page,
> + .migratepage= shmem_migratepage,
> #endif
> .error_remove_page = generic_error_remove_page,
> };
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm/i915: Move execlists irq handler to a bottom half
From: Tvrtko Ursulin Doing a lot of work in the interrupt handler introduces huge latencies to the system as a whole. Most dramatic effect can be seen by running an all engine stress test like igt/gem_exec_nop/all where, when the kernel config is lean enough, the whole system can be brought into multi-second periods of complete non-interactivty. That can look for example like this: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/u8:3:143] Modules linked in: [redacted for brevity] CPU: 0 PID: 143 Comm: kworker/u8:3 Tainted: G U L 4.5.0-160321+ #183 Hardware name: Intel Corporation Broadwell Client platform/WhiteTip Mountain 1 Workqueue: i915 gen6_pm_rps_work [i915] task: 8800aae88000 ti: 8800aae9 task.ti: 8800aae9 RIP: 0010:[] [] __do_softirq+0x72/0x1d0 RSP: :88014f403f38 EFLAGS: 0206 RAX: 8800aae94000 RBX: RCX: 06e0 RDX: 0020 RSI: 04208060 RDI: 00215d80 RBP: 88014f403f80 R08: 000b1b42c180 R09: 0022 R10: 0004 R11: R12: a030 R13: 0082 R14: 8800aa4d0080 R15: 0082 FS: () GS:88014f40() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fa53b90c000 CR3: 01a0a000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Stack: 042080601b33869f 8800aae94000 fffc2678 8801000a a030 5302 8800aa4d0080 0206 88014f403f90 8104a716 88014f403fa8 Call Trace: [] irq_exit+0x86/0x90 [] smp_apic_timer_interrupt+0x3d/0x50 [] apic_timer_interrupt+0x7c/0x90 [] ? gen8_write64+0x1a0/0x1a0 [i915] [] ? _raw_spin_unlock_irqrestore+0x9/0x20 [] gen8_write32+0x104/0x1a0 [i915] [] ? n_tty_receive_buf_common+0x372/0xae0 [] gen6_set_rps_thresholds+0x1be/0x330 [i915] [] gen6_set_rps+0x70/0x200 [i915] [] intel_set_rps+0x25/0x30 [i915] [] gen6_pm_rps_work+0x10d/0x2e0 [i915] [] ? finish_task_switch+0x72/0x1c0 [] process_one_work+0x139/0x350 [] worker_thread+0x126/0x490 [] ? rescuer_thread+0x320/0x320 [] kthread+0xc4/0xe0 [] ? kthread_create_on_node+0x170/0x170 [] ret_from_fork+0x3f/0x70 [] ? kthread_create_on_node+0x170/0x170 I could not explain, or find a code path, which would explain a +20 second lockup, but from some instrumentation it was apparent the interrupts off proportion of time was between 10-25% under heavy load which is quite bad. When a interrupt "cliff" is reached, which was >~320k irq/s on my machine, the whole system goes into a terrible state of the above described multi-second lockups. By moving the GT interrupt handling to a tasklet in a most simple way, the problem above disappears completely. Testing the effect on sytem-wide latencies using igt/gem_syslatency shows the following before this patch: gem_syslatency: cycles=1532739, latency mean=416531.829us max=2499237us gem_syslatency: cycles=1839434, latency mean=1458099.157us max=4998944us gem_syslatency: cycles=1432570, latency mean=2688.451us max=1201185us gem_syslatency: cycles=1533543, latency mean=416520.499us max=2498886us This shows that the unrelated process is experiencing huge delays in its wake-up latency. After the patch the results look like this: gem_syslatency: cycles=808907, latency mean=53.133us max=1640us gem_syslatency: cycles=862154, latency mean=62.778us max=2117us gem_syslatency: cycles=856039, latency mean=58.079us max=2123us gem_syslatency: cycles=841683, latency mean=56.914us max=1667us Showing a huge improvement in the unrelated process wake-up latency. It also shows an approximate halving in the number of total empty batches submitted during the test. This may not be worrying since the test puts the driver under a very unrealistic load with ncpu threads doing empty batch submission to all GPU engines each. More interesting scenario with regards to throughput is "gem_latency -n 100" which shows 25% better throughput and CPU usage, and 14% better dispatch latencies. I did not find any gains or regressions with Synmark2 or GLbench under light testing. More benchmarking is certainly required. v2: * execlists_lock should be taken as spin_lock_bh when queuing work from userspace now. (Chris Wilson) * uncore.lock must be taken with spin_lock_irq when submitting requests since that now runs from either softirq or process context. v3: * Expanded commit message with more testing data; * converted missed locking sites to _bh; * added execlist_lock comment. (Chris Wilson) Signed-off-by: Tvrtko Ursulin Cc: Chris Wilson Testcase: igt/gem_exec_nop/all Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94350 Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c
Re: [Intel-gfx] [PATCH 5/5] drm/i915: force full detect on sink count change
Hi Daniel,
Is something else required for this patch series (5 patches) to be merged?
Thanks and Regards,
Shubhangi Shrivastava.
-Original Message-
From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com]
Sent: Wednesday, January 20, 2016 8:07 PM
To: Shrivastava, Shubhangi ;
intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 5/5] drm/i915: force full detect on sink count
change
On Tue, 2016-01-19 at 16:07 +0530, Shubhangi Shrivastava wrote:
> This patch checks for changes in sink count between short pulse hpds
> and forces full detect when there is a change.
>
> This will allow both detection of hotplug and unplug of panels through
> dongles that give only short pulse for such events.
>
> v2: changed variable type from u8 to bool (Jani)
> return immediately if perform_full_detect is set(Siva)
>
> v3: changed method of determining full detection from using
> pointer to return code (Siva)
>
> v4: changed comments to indicate meaning of return value of
> intel_dp_short_pulse and explain the use of return value
> from intel_dp_get_dpcd in intel_dp_short_pulse (Ander)
>
> Tested-by: Nathan D Ciobanu
> Signed-off-by: Sivakumar Thulasimani
> Signed-off-by: Shubhangi Shrivastava
Reviewed-by: Ander Conselvan de Oliveira
> ---
> drivers/gpu/drm/i915/intel_dp.c | 33
> +++--
> 1 file changed, 27 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c index cdf4919..120d263 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4325,12 +4325,19 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
> * 2. Configure link according to Receiver Capabilities
> * 3. Use Link Training from 2.5.3.3 and 3.5.1.3
> * 4. Check link status on receipt of hot-plug interrupt
> + *
> + * intel_dp_short_pulse - handles short pulse interrupts
> + * when full detection is not required.
> + * Returns %true if short pulse is handled and full detection
> + * is NOT required and %false otherwise.
> */
> -static void
> +static bool
> intel_dp_short_pulse(struct intel_dp *intel_dp) {
> struct drm_device *dev = intel_dp_to_dev(intel_dp);
> u8 sink_irq_vector;
> + u8 old_sink_count = intel_dp->sink_count;
> + bool ret;
>
> /*
>* Clearing compliance test variables to allow capturing @@ -4340,9
> +4347,17 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
> intel_dp->compliance_test_type = 0;
> intel_dp->compliance_test_data = 0;
>
> - /* Now read the DPCD to see if it's actually running */
> - if (!intel_dp_get_dpcd(intel_dp)) {
> - return;
> + /*
> + * Now read the DPCD to see if it's actually running
> + * If the current value of sink count doesn't match with
> + * the value that was stored earlier or dpcd read failed
> + * we need to do full detection
> + */
> + ret = intel_dp_get_dpcd(intel_dp);
> +
> + if ((old_sink_count != intel_dp->sink_count) || !ret) {
> + /* No need to proceed if we are going to do full detect */
> + return false;
> }
>
> /* Try to read the source of the interrupt */ @@ -4362,6 +4377,8 @@
> intel_dp_short_pulse(struct intel_dp *intel_dp)
> drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
> intel_dp_check_link_status(intel_dp);
> drm_modeset_unlock(&dev->mode_config.connection_mutex);
> +
> + return true;
> }
>
> /* XXX this is probably wrong for multiple downstream ports */ @@
> -5086,8 +5103,12 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
> }
> }
>
> - if (!intel_dp->is_mst)
> - intel_dp_short_pulse(intel_dp);
> + if (!intel_dp->is_mst) {
> + if (!intel_dp_short_pulse(intel_dp)) {
> + intel_dp_long_pulse(intel_dp
> ->attached_connector);
> + goto put_power;
> + }
> + }
> }
>
> ret = IRQ_HANDLED;
___
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: fix potential dangling else problems in for_each_ macros (rev4)
== Series Details == Series: drm/i915: fix potential dangling else problems in for_each_ macros (rev4) URL : https://patchwork.freedesktop.org/series/1142/ State : success == Summary == Series 1142v4 drm/i915: fix potential dangling else problems in for_each_ macros http://patchwork.freedesktop.org/api/1.0/series/1142/revisions/4/mbox/ Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> PASS (bsw-nuc-2) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> SKIP (byt-nuc) Subgroup suspend-read-crc-pipe-c: incomplete -> PASS (hsw-gt2) Test pm_rpm: Subgroup basic-pci-d3-state: dmesg-warn -> PASS (byt-nuc) bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:192 pass:155 dwarn:0 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:156 dwarn:0 dfail:0 fail:0 skip:36 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:192 pass:181 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1704/ 79ee42317266a82b932a39e9567244ed91dd27d6 drm-intel-nightly: 2016y-03m-24d-10h-26m-54s UTC integration manifest 0126b0b851d5abdfc08ccd48cf2babf2fdd550c0 drm/i915: replace for_each_engine() 6fe2515ba81fbeaf484a388941b776350f910ba2 drm/i915: introduce for_each_engine_id() ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Replace some more busy waits with normal ones
On Thu, Mar 24, 2016 at 11:37:07AM +, Tvrtko Ursulin wrote: > > On 23/03/16 16:40, Chris Wilson wrote: > >On Wed, Mar 23, 2016 at 04:24:48PM +, Tvrtko Ursulin wrote: > >>Biggest thing to make sure is that you don't add a lot of cycles to > >>the forcewake loops since for example fw_domains_get can be the > >>hottest i915 function on some benchmarks. > >> > >>(This area slightly annoys me anyway with redundant looping over > >>forcewake domains and we could also potentially optimize the ack > >>waiting by first requesting all we want, and then doing the waits. > >>That would be one additional loop, but if removed the other one, > >>code would stay at the same number of domain loops.) > > > >I hear you. I just end up weeping in the corner when I see fw_domain_get > >on the profile. > > > >We already do have a mitigation scheme to hold onto the forcewake for an > >extra jiffie every time. I don't like it, but without it fw_domains_get > >becomes a real hog. > > I am pretty sure I've seen some tests which somehow defeat the > jiffie delay and we end up re-acquiring every ms/jiffie. This is > something I wanted to get to the bottom of but did not get round to > yet. It was totally unexpected because the test is hammering on > everything. Absolutely sure it is not just the delay in acquiring the ack? And spinning on waiting for the thread_c0 doesn't come cheap? I've just written off fw_domain_get being high on the profiles simply due to that we have to spin so long (I'm jaded because on Sandybridge spinning for 50us+ isn't uncommon iirc). You're right though, we should instrument it and check it is working. > >Note that one thing we can actually do is restrict the domains we wakeup > >for the engines (engine->fw_domain) in execlists_submit, that should > >help chv/skl+ a small amount. > > I even have a patch to do that somewhere. :) So did I! > >I don't have a good idea for how to keep rc6 residency high but avoid > >forcewake when those darn elsp require forcewake. As does gen6+ legacy > >RING_TAIL writes. And even then that spinlock causes quite a bit of > >traffic when it shouldn't be contended. I've been thinking of whether we > >can have multiple locks (hashed by register) but we would then still > >need some cross-communication for the common forcewake. > > Maybe it is not worth it at this point. This is pretty well > optimised now and could switch to the next target. Like maybe move > to active and retire__read, or retired_req_list, or something. There is a challenge in that we are both lazy in how often we check for retirement/idleness (because it's work that we can postpone and if we do so, quite often that work is no longer required!) and that just because the driver believes the GPU should be busy, it can quite happily power itself down between operations (though that's really for gen6/gen7 semaphores with the current state of the driver). I don't have a better plan then to reduce the mmio and spinlocks where possible. -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] [intelddx] v2.99.917-580-gf656f6afa288: sh: 1: ACLOCAL_FLAGS: not found
On 24/03/16 09:54, Chris Wilson wrote:
On Thu, Mar 24, 2016 at 10:34:58AM +0100, Sedat Dilek wrote:
[ build-script, build and config logs attached ]
Hi Chris,
I am just seeing this (or noticed for the first time, here on
Ubuntu/precise AMD64)...
$ zgrep -A1 -B1 ACLOCAL_FLAGS:
build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt.gz
autoreconf: running: aclocal $(ACLOCAL_FLAGS) -I m4
sh: 1: ACLOCAL_FLAGS: not found
autoreconf: configure.ac: tracing
--
libtoolize: copying file `m4/lt~obsolete.m4'
sh: 1: ACLOCAL_FLAGS: not found
autoreconf: running: /usr/bin/autoconf
What does this mean and it is ignore-able?
libtool vs automake. Haven't found the right fix yet.
If you want to locally patch s/$(ACLOCAL_FLAGS)// that'll do the trick.
I think that's what we'll have to do :|
-Chris
Is this a confusion between an (undefined) Make-variable vs a shell
variable? The syntax above with parentheses $(VAR) would be right for
expanding a Make-variable, but it looks like it's being passed as-is to
the shell, which interprets it as command-substitution and tries to run
the (non-existent) *command* ACLOCAL_FLAGS
Try prefixing your top-level building command (make, or ./configure, or
whatever) with the assignment ACLOCAL_FLAGS= thus:
$ ACLOCAL_FLAGS= make
Note the space after the equal-sign; this sets ACLOCAL_FLAGS to the null
string in the environment of the "make" command (only).
To get more information on what aclocal is doing, consider
$ ACLOCAL_FLAGS='--verbose' make
If those don't help, check where aclocal is being invoked and see
whether it should read "aclocal ${ACLOCAL_FLAGS}" with *braces* rather
than parentheses!
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [intelddx] v2.99.917-580-gf656f6afa288: sh: 1: ACLOCAL_FLAGS: not found
On Thu, Mar 24, 2016 at 12:29:32PM +, Dave Gordon wrote:
> On 24/03/16 09:54, Chris Wilson wrote:
> >On Thu, Mar 24, 2016 at 10:34:58AM +0100, Sedat Dilek wrote:
> >>[ build-script, build and config logs attached ]
> >>
> >>Hi Chris,
> >>
> >>I am just seeing this (or noticed for the first time, here on
> >>Ubuntu/precise AMD64)...
> >>
> >>$ zgrep -A1 -B1 ACLOCAL_FLAGS:
> >>build-and-install-log_intelddx-2-99-917-580-gf656f6afa288_tearfree-enabled_llvm-3-8-0.txt.gz
> >>autoreconf: running: aclocal $(ACLOCAL_FLAGS) -I m4
> >>sh: 1: ACLOCAL_FLAGS: not found
> >>autoreconf: configure.ac: tracing
> >>--
> >>libtoolize: copying file `m4/lt~obsolete.m4'
> >>sh: 1: ACLOCAL_FLAGS: not found
> >>autoreconf: running: /usr/bin/autoconf
> >>
> >>What does this mean and it is ignore-able?
> >
> >libtool vs automake. Haven't found the right fix yet.
> >
> >If you want to locally patch s/$(ACLOCAL_FLAGS)// that'll do the trick.
> >I think that's what we'll have to do :|
> >-Chris
>
> Is this a confusion between an (undefined) Make-variable vs a shell
> variable? The syntax above with parentheses $(VAR) would be right
> for expanding a Make-variable, but it looks like it's being passed
> as-is to the shell, which interprets it as command-substitution and
> tries to run the (non-existent) *command* ACLOCAL_FLAGS
Yes. The issue is that recently libtool spits out
an obtuse error if it sees ${ACLOCAL_FLAGS} in ACLOCAL_AMFLAGS
libtoolize: error: AC_CONFIG_MACRO_DIRS([m4]) conflicts with
ACLOCAL_AMFLAGS=-I /opt/xorg/share/aclocal.
autoreconf: libtoolize failed with exit status: 1
i.e. it misses that we both include the user aclocal directory as well
as our own -I m4.
So I tried using it as a make variable instead, but then it is evaluated
as the shell $() command!
-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] [intelddx][strlcpy | strlcat | clock_gettime] clang-3.8: error: linker command failed with exit code 1
On 24/03/16 11:11, Sedat Dilek wrote:
From b35261adb49107e7dd6e480b1f7c5d4fb7552f9f Mon Sep 17 00:00:00 2001
From: Sedat Dilek
Date: Thu, 24 Mar 2016 12:01:37 +0100
Subject: [PATCH 1/3] configure: Remove ACLOCAL_FLAGS to fix libtool vs
automake problem
---
Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am
index c60e8a729271..396f41fdc4df 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -18,7 +18,7 @@
# 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.
-ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4
+ACLOCAL_AMFLAGS = -I m4
SUBDIRS = man libobj xvmc src tools
--
Looks like the issue is related to trying to layer the Make-variable
expansion.
In the shell (and most other languages) an assignment like:
$ ACLOCAL_AMFLAGS="${ACLOCAL_FLAGS} -I m4"
would take the current value of the existing ACLOCAL_FLAGS variable and
use it construct the value of the new variable ACLOCAL_AMFLAGS. Thus if
ACLOCAL_were "--XXX" this would yield "-XXX -I m4". Then later we'd see:
$ aclocal ${ACLOCAL_AMFLAGS} ...
which would use the value as previously defined.
Make doesn't do that. It sets ACLOCAL_AMFLAGS to "$(ACLOCAL_FLAGS) -I
m4" and then later, when ACLOCAL_AMFLAGS is *used* it expands it, and
then notices that the expanded version still contains a $(var) construct
and expands *that* ... and so on until there are none left. This is
sometimes useful, but often confusing. So GNU make (as POSIX, from 2012
on) supports another type of assignment,
VAR ::= expression
which does the expansion of just once, at this point, and
stores the result rather than the itself. So, try changing
the line
ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4
in the Makefile into:
ACLOCAL_AMFLAGS ::= $(ACLOCAL_FLAGS) -I m4
and see whether that helps :)
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/bxt: Fix DSI HW state readout (rev3)
On to, 2016-03-24 at 11:32 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/bxt: Fix DSI HW state readout (rev3) > URL : https://patchwork.freedesktop.org/series/4832/ > State : success > > == Summary == > > Series 4832v3 drm/i915/bxt: Fix DSI HW state readout > http://patchwork.freedesktop.org/api/1.0/series/4832/revisions/3/mbox > / > > Test gem_exec_suspend: > Subgroup basic-s3: > dmesg-warn -> PASS (bsw-nuc-2) > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-c: > incomplete -> PASS (hsw-gt2) Thanks for the review, I pushed the patch to -dinq. --Imre > bdw- > nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:1 > 2 > bdw- > ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:2 > 1 > bsw-nuc- > 2total:192 pass:155 dwarn:0 dfail:0 fail:0 skip:37 > byt- > nuc total:192 pass:156 dwarn:1 dfail:0 fail:0 skip:3 > 5 > hsw- > brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:2 > 2 > hsw- > gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:1 > 7 > ivb- > t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:2 > 5 > skl-i7k- > 2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 > skl- > nuci5total:192 pass:181 dwarn:0 dfail:0 fail:0 skip:1 > 1 > snb- > dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:3 > 4 > snb- > x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:3 > 3 > > Results at /archive/results/CI_IGT_test/Patchwork_1703/ > > 79ee42317266a82b932a39e9567244ed91dd27d6 drm-intel-nightly: 2016y- > 03m-24d-10h-26m-54s UTC integration manifest > 8e94bd5898ec48db5dcfed6dbbe1cf1e9ac2499f drm/i915/bxt: Fix DSI HW > state readout > > ___ > 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 v2 1/5] drm: add picture aspect ratio flags
On Thu, 24 Mar 2016, Shashank Sharma wrote: > This patch adds drm flag bits for aspect ratio information > > Currently drm flag bits don't have field for mode's picture > aspect ratio. This field will help the driver to pick mode with > right aspect ratio, and help in setting right VIC field in avi > infoframes. > > Signed-off-by: Shashank Sharma > --- > include/uapi/drm/drm_mode.h | 18 +- Please use scripts/get_maintainer.pl on the patch to figure out who it should be sent to. This file is not maintained by us, so we can't just merge it. For example: $ scripts/get_maintainer.pl 0001-drm-add-picture-aspect-ratio-flags.patch David Airlie (maintainer:DRM DRIVERS) dri-de...@lists.freedesktop.org (open list:DRM DRIVERS) linux-ker...@vger.kernel.org (open list) Of course, since you ultimately aim for a change in drm/i915, you should also Cc: intel-gfx. BR, Jani. > 1 file changed, 13 insertions(+), 5 deletions(-) > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h > index 50adb46..3389bd1 100644 > --- a/include/uapi/drm/drm_mode.h > +++ b/include/uapi/drm/drm_mode.h > @@ -73,6 +73,19 @@ > #define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM (7<<14) > #define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (8<<14) > > +/* Picture aspect ratio options */ > +#define DRM_MODE_PICTURE_ASPECT_NONE 0 > +#define DRM_MODE_PICTURE_ASPECT_4_3 1 > +#define DRM_MODE_PICTURE_ASPECT_16_9 2 > + > +/* Aspect ratio flag bitmask (4 bits 21:19) */ > +#define DRM_MODE_FLAG_PARMASK (0x0F<<19) > +#define DRM_MODE_FLAG_PARNONE \ > + (DRM_MODE_PICTURE_ASPECT_NONE << 19) > +#define DRM_MODE_FLAG_PAR4_3 \ > + (DRM_MODE_PICTURE_ASPECT_4_3 << 19) > +#define DRM_MODE_FLAG_PAR16_9 \ > + (DRM_MODE_PICTURE_ASPECT_16_9 << 19) > > /* DPMS flags */ > /* bit compatible with the xorg definitions. */ > @@ -88,11 +101,6 @@ > #define DRM_MODE_SCALE_CENTER2 /* Centered, no scaling */ > #define DRM_MODE_SCALE_ASPECT3 /* Full screen, preserve > aspect */ > > -/* Picture aspect ratio options */ > -#define DRM_MODE_PICTURE_ASPECT_NONE 0 > -#define DRM_MODE_PICTURE_ASPECT_4_3 1 > -#define DRM_MODE_PICTURE_ASPECT_16_9 2 > - > /* Dithering mode options */ > #define DRM_MODE_DITHERING_OFF 0 > #define DRM_MODE_DITHERING_ON1 -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Add aspect ratio parsing (rev2)
== Series Details == Series: Add aspect ratio parsing (rev2) URL : https://patchwork.freedesktop.org/series/1915/ State : failure == Summary == Series 1915v2 Add aspect ratio parsing http://patchwork.freedesktop.org/api/1.0/series/1915/revisions/2/mbox/ Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> PASS (bsw-nuc-2) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (skl-nuci5) Subgroup suspend-read-crc-pipe-c: incomplete -> PASS (hsw-gt2) Test pm_rpm: Subgroup basic-pci-d3-state: dmesg-warn -> PASS (byt-nuc) Subgroup basic-rte: pass -> DMESG-WARN (bsw-nuc-2) bdw-nuci7total:192 pass:180 dwarn:0 dfail:0 fail:0 skip:12 bdw-ultratotal:192 pass:171 dwarn:0 dfail:0 fail:0 skip:21 bsw-nuc-2total:192 pass:154 dwarn:1 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:157 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:7pass:6dwarn:0 dfail:0 fail:0 skip:0 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1705/ 79ee42317266a82b932a39e9567244ed91dd27d6 drm-intel-nightly: 2016y-03m-24d-10h-26m-54s UTC integration manifest a60eb2345fd88921efd726b87c3fcdb37ac4e354 drm/i915: Add support for new aspect ratios 88cc86a1fac6487e28c7fa417907b3cdeaf42c51 drm: Add flags for new aspect ratios 78ae236a5577f16e09246bf380d759a4ef519a58 video: Add new aspect ratios for HDMI 2.0 fa5c2406d9b48b353b1e11480610fe388fe89381 drm: Add aspect ratio parsing in DRM layer b969d1257347df863347dbe71ffe517f9ca8e263 drm: add picture aspect ratio flags ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/5] drm: add picture aspect ratio flags
Ok, will do it for other patches too. Regards Shashank -Original Message- From: Jani Nikula [mailto:jani.nik...@linux.intel.com] Sent: Thursday, March 24, 2016 6:26 PM To: Sharma, Shashank; Vivi, Rodrigo Cc: intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH v2 1/5] drm: add picture aspect ratio flags On Thu, 24 Mar 2016, Shashank Sharma wrote: > This patch adds drm flag bits for aspect ratio information > > Currently drm flag bits don't have field for mode's picture aspect > ratio. This field will help the driver to pick mode with right aspect > ratio, and help in setting right VIC field in avi infoframes. > > Signed-off-by: Shashank Sharma > --- > include/uapi/drm/drm_mode.h | 18 +- Please use scripts/get_maintainer.pl on the patch to figure out who it should be sent to. This file is not maintained by us, so we can't just merge it. For example: $ scripts/get_maintainer.pl 0001-drm-add-picture-aspect-ratio-flags.patch David Airlie (maintainer:DRM DRIVERS) dri-de...@lists.freedesktop.org (open list:DRM DRIVERS) linux-ker...@vger.kernel.org (open list) Of course, since you ultimately aim for a change in drm/i915, you should also Cc: intel-gfx. BR, Jani. > 1 file changed, 13 insertions(+), 5 deletions(-) > > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h > index 50adb46..3389bd1 100644 > --- a/include/uapi/drm/drm_mode.h > +++ b/include/uapi/drm/drm_mode.h > @@ -73,6 +73,19 @@ > #define DRM_MODE_FLAG_3D_TOP_AND_BOTTOM (7<<14) > #define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (8<<14) > > +/* Picture aspect ratio options */ > +#define DRM_MODE_PICTURE_ASPECT_NONE 0 > +#define DRM_MODE_PICTURE_ASPECT_4_3 1 > +#define DRM_MODE_PICTURE_ASPECT_16_9 2 > + > +/* Aspect ratio flag bitmask (4 bits 21:19) */ > +#define DRM_MODE_FLAG_PARMASK (0x0F<<19) > +#define DRM_MODE_FLAG_PARNONE \ > + (DRM_MODE_PICTURE_ASPECT_NONE << 19) #define > DRM_MODE_FLAG_PAR4_3 > +\ > + (DRM_MODE_PICTURE_ASPECT_4_3 << 19) #define > DRM_MODE_FLAG_PAR16_9 > +\ > + (DRM_MODE_PICTURE_ASPECT_16_9 << 19) > > /* DPMS flags */ > /* bit compatible with the xorg definitions. */ @@ -88,11 +101,6 @@ > #define DRM_MODE_SCALE_CENTER2 /* Centered, no scaling */ > #define DRM_MODE_SCALE_ASPECT3 /* Full screen, preserve > aspect */ > > -/* Picture aspect ratio options */ > -#define DRM_MODE_PICTURE_ASPECT_NONE 0 > -#define DRM_MODE_PICTURE_ASPECT_4_3 1 > -#define DRM_MODE_PICTURE_ASPECT_16_9 2 > - > /* Dithering mode options */ > #define DRM_MODE_DITHERING_OFF 0 > #define DRM_MODE_DITHERING_ON1 -- 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] [RFC v2] drm/i915: Move execlists irq handler to a bottom half
On 24/03/16 11:50, Tvrtko Ursulin wrote: Also, gem_latency -n 100 shows 25% better throughput and CPU usage, and 14% better latencies. Mention the benefits of parallelising dispatch. Hm, actually this should be the same as before I think. Of course not, silly me. Will add this at the next opportunity then. 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: Replace some more busy waits with normal ones
On 24/03/16 12:27, Chris Wilson wrote: On Thu, Mar 24, 2016 at 11:37:07AM +, Tvrtko Ursulin wrote: On 23/03/16 16:40, Chris Wilson wrote: On Wed, Mar 23, 2016 at 04:24:48PM +, Tvrtko Ursulin wrote: Biggest thing to make sure is that you don't add a lot of cycles to the forcewake loops since for example fw_domains_get can be the hottest i915 function on some benchmarks. (This area slightly annoys me anyway with redundant looping over forcewake domains and we could also potentially optimize the ack waiting by first requesting all we want, and then doing the waits. That would be one additional loop, but if removed the other one, code would stay at the same number of domain loops.) I hear you. I just end up weeping in the corner when I see fw_domain_get on the profile. We already do have a mitigation scheme to hold onto the forcewake for an extra jiffie every time. I don't like it, but without it fw_domains_get becomes a real hog. I am pretty sure I've seen some tests which somehow defeat the jiffie delay and we end up re-acquiring every ms/jiffie. This is something I wanted to get to the bottom of but did not get round to yet. It was totally unexpected because the test is hammering on everything. Absolutely sure it is not just the delay in acquiring the ack? And spinning on waiting for the thread_c0 doesn't come cheap? I've just written off fw_domain_get being high on the profiles simply due to that we have to spin so long (I'm jaded because on Sandybridge spinning for 50us+ isn't uncommon iirc). I am not sure, I just know I had a printk in the timer release and it was firing every millisecond which completely perplexed me since I was running gem_exec_nop/all at the time. Good point on that the cost might actually be in the wait for acks. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Tune down init error message due to failure injection
On ma, 2016-03-21 at 17:12 +0200, Imre Deak wrote:
> On ma, 2016-03-21 at 10:28 +0100, Daniel Vetter wrote:
> >
> > On Fri, Mar 18, 2016 at 11:15:35AM +0200, Imre Deak wrote:
> > >
> > > On Fri, 2016-03-18 at 10:59 +0200, Joonas Lahtinen wrote:
> > > >
> > > > On pe, 2016-03-18 at 00:18 +0200, Imre Deak wrote:
> > > > >
> > > > > On Thu, 2016-03-17 at 22:14 +, Chris Wilson wrote:
> > > > > >
> > > > > >
> > > > > > On Fri, Mar 18, 2016 at 12:09:30AM +0200, Imre Deak wrote:
> > > > > > >
> > > > > > >
> > > > > > > On Thu, 2016-03-17 at 21:48 +, Chris Wilson wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > I would also like this to be the preferred
> > > > > > > > DRM_ERROR reporting mechanism i.e. anytime we emit an
> > > > > > > > ERROR
> > > > > > > > we
> > > > > > > > should
> > > > > > > > be
> > > > > > > > encouraging the user to file a bug, and do so in a user
> > > > > > > > friendly
> > > > > > > > fashion.
> > > > > > > Ok, but only in i915 I assume. Should we also convert then
> > > > > > > all
> > > > > > > DRM_ERROR to dev_err - with an *ERROR* prefix - or still
> > > > > > > use
> > > > > > > DRM_ERROR?
> > > > > > Within i915. I am thinking along the lines that no DRM_ERROR
> > > > > > should
> > > > > > exist that doesn't acknowlege that it is a user facing error
> > > > > > message
> > > > > > (i.e. written in plain English and is informative, and
> > > > > > includes a
> > > > > > bug
> > > > > > reporting reference). So i915_report_error() or somesuch.
> > > > > Ok, will give it a go.
> > > > Daniel didn't want i915 debugging/erroring mechanisms to deviate
> > > > from
> > > > core DRM. So I guess this would follow in the same category.
> > > >
> > > > I'm all in for structuring a coherent debugging/error message
> > > > logic
> > > > and
> > > > functions for it and then everyone can follow the suit.
> > > The dev_err/dbg method has obvious advantages, like dynamic debug
> > > or
> > > showing the device instance, so I think that's something we want in
> > > any
> > > case. I don't see a problem with first rolling it out in i915 then
> > > proposing it for more generic use.
> > Well that's just silly me trying to apply some pressure into making
> > something that's compatible with DRM_*. Or well, porting those macros
> > over
> > to whatever the newfangled fancy thing is. Including keeping
> > drm.debug
> > alive with some hacks (we can write our own store functions, which
> > could
> > enable the right stuff with dynamic debugging, if we export a few
> > funcs)
> > so that the gazillion of howtos out there don't all break.
> Yea, currently we'd output debug messages even in case of drm.debug==0.
> I sent a patch that makes __i915_printk() behave the same as
> DRM_DEBUG_DRIVER for debug messages. I think on top of that a more
> fancy dynamic debug based filtering can be implemented later as you
> suggest.
>
Yeah, when dynamic debugging is disabled drm.debug==0 would produce all
the debug, that's the biggest problem I hit. Over-verbosity.
I have the drm.debug working in dynamic debugging cases already (I
exposed one interface from kernel and tadah).
Problem is only, if we want to have drm.debug doing its filtering thing
for the old and new code in transitino phase when dynamic debugging is
disabled. Then we'll have to go little bit further and do a few #undefs
(but we currently have those, too), because dynamic debugging also
makes itself add the line numbers and file names to allow filtering by
those.
I copy-pasted my changes at the end so you get a rough idea.
Regards, Joonas
> --Imre
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
--8<---
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 167c8d3..da818a0 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
#include "drm_legacy.h"
@@ -43,8 +44,11 @@ EXPORT_SYMBOL(drm_debug);
MODULE_AUTHOR(CORE_AUTHOR);
MODULE_DESCRIPTION(CORE_DESC);
MODULE_LICENSE("GPL and additional rights");
+
+#ifdef CONFIG_DYNAMIC_DEBUG
MODULE_PARM_DESC(debug, "Enable debug output");
module_param_named(debug, drm_debug, int, 0600);
+#endif
static DEFINE_SPINLOCK(drm_minor_lock);
static struct idr drm_minors_idr;
@@ -61,28 +65,13 @@ void drm_err(const char *format, ...)
vaf.fmt = format;
vaf.va = &args;
- printk(KERN_ERR "[" DRM_NAME ":%ps] *ERROR* %pV",
+ printk(KERN_ERR DRM_NAME ": [%ps] *ERROR* %pV",
__builtin_return_address(0), &vaf);
va_end(args);
}
EXPORT_SYMBOL(drm_err);
-void drm_ut_debug_printk(const char *function_name, const char *format, ...)
-{
- struct va_format vaf;
- va_list args;
-
- va_start(args, format);
- vaf.fmt = format;
- vaf.va = &args;
-
- printk(KERN_DEBUG "[" DRM_NAME ":%s] %pV", function_name, &vaf);
Re: [Intel-gfx] [intelddx][strlcpy | strlcat | clock_gettime] clang-3.8: error: linker command failed with exit code 1
On Thu, Mar 24, 2016 at 12:47:51PM +, Dave Gordon wrote:
> On 24/03/16 11:11, Sedat Dilek wrote:
> > From b35261adb49107e7dd6e480b1f7c5d4fb7552f9f Mon Sep 17 00:00:00 2001
> >From: Sedat Dilek
> >Date: Thu, 24 Mar 2016 12:01:37 +0100
> >Subject: [PATCH 1/3] configure: Remove ACLOCAL_FLAGS to fix libtool vs
> > automake problem
> >
> >---
> > Makefile.am | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/Makefile.am b/Makefile.am
> >index c60e8a729271..396f41fdc4df 100644
> >--- a/Makefile.am
> >+++ b/Makefile.am
> >@@ -18,7 +18,7 @@
> > # 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.
> >
> >-ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4
> >+ACLOCAL_AMFLAGS = -I m4
> >
> > SUBDIRS = man libobj xvmc src tools
> >
> >--
>
> Looks like the issue is related to trying to layer the Make-variable
> expansion.
>
> In the shell (and most other languages) an assignment like:
>
> $ ACLOCAL_AMFLAGS="${ACLOCAL_FLAGS} -I m4"
>
> would take the current value of the existing ACLOCAL_FLAGS variable
> and use it construct the value of the new variable ACLOCAL_AMFLAGS.
> Thus if ACLOCAL_were "--XXX" this would yield "-XXX -I m4". Then
> later we'd see:
>
> $ aclocal ${ACLOCAL_AMFLAGS} ...
>
> which would use the value as previously defined.
>
> Make doesn't do that. It sets ACLOCAL_AMFLAGS to "$(ACLOCAL_FLAGS)
> -I m4" and then later, when ACLOCAL_AMFLAGS is *used* it expands it,
> and then notices that the expanded version still contains a $(var)
> construct and expands *that* ... and so on until there are none
> left. This is sometimes useful, but often confusing. So GNU make (as
> POSIX, from 2012 on) supports another type of assignment,
>
> VAR ::= expression
>
> which does the expansion of just once, at this point,
> and stores the result rather than the itself. So, try
> changing the line
>
> ACLOCAL_AMFLAGS = $(ACLOCAL_FLAGS) -I m4
>
> in the Makefile into:
>
> ACLOCAL_AMFLAGS ::= $(ACLOCAL_FLAGS) -I m4
>
> and see whether that helps :)
ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS} -I m4
=> autoreconf: running: aclocal ${ACLOCAL_FLAGS} -I m4
...
With setenv ACLOCAL_FLAGS "-I /opt/xorg/share/aclocal":
=> autoreconf: running: aclocal -I /opt/xorg/share/aclocal/ ${ACLOCAL_FLAGS} -I
m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy
libtoolize: error: AC_CONFIG_MACRO_DIRS([m4]) conflicts with
ACLOCAL_AMFLAGS=-I /opt/xorg/share/aclocal.
Using ACLOCAL_AMFLAGS ::= $(ACLOCAL_FLAGS) -I m4
=> autoreconf: running: aclocal -I /opt/xorg/share/aclocal/
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy
libtoolize: Consider adding '-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
It looks like using
ACLOCAL_AMFLAGS = ${ACLOCAL_FLAGS} -I m4
is obsolete in autoreconf (GNU Autoconf) 2.69.
So looks like the answer is
AC_PREREQ([2.69])
ACLOCAL_AMFLAGS = -I m4
-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] drm/i915: Replace some more busy waits with normal ones
On Thu, Mar 24, 2016 at 01:06:41PM +, Tvrtko Ursulin wrote: > > On 24/03/16 12:27, Chris Wilson wrote: > >On Thu, Mar 24, 2016 at 11:37:07AM +, Tvrtko Ursulin wrote: > >> > >>On 23/03/16 16:40, Chris Wilson wrote: > >>>On Wed, Mar 23, 2016 at 04:24:48PM +, Tvrtko Ursulin wrote: > Biggest thing to make sure is that you don't add a lot of cycles to > the forcewake loops since for example fw_domains_get can be the > hottest i915 function on some benchmarks. > > (This area slightly annoys me anyway with redundant looping over > forcewake domains and we could also potentially optimize the ack > waiting by first requesting all we want, and then doing the waits. > That would be one additional loop, but if removed the other one, > code would stay at the same number of domain loops.) > >>> > >>>I hear you. I just end up weeping in the corner when I see fw_domain_get > >>>on the profile. > >>> > >>>We already do have a mitigation scheme to hold onto the forcewake for an > >>>extra jiffie every time. I don't like it, but without it fw_domains_get > >>>becomes a real hog. > >> > >>I am pretty sure I've seen some tests which somehow defeat the > >>jiffie delay and we end up re-acquiring every ms/jiffie. This is > >>something I wanted to get to the bottom of but did not get round to > >>yet. It was totally unexpected because the test is hammering on > >>everything. > > > >Absolutely sure it is not just the delay in acquiring the ack? And > >spinning on waiting for the thread_c0 doesn't come cheap? I've just > >written off fw_domain_get being high on the profiles simply due to that > >we have to spin so long (I'm jaded because on Sandybridge spinning for > >50us+ isn't uncommon iirc). > > I am not sure, I just know I had a printk in the timer release and > it was firing every millisecond which completely perplexed me since > I was running gem_exec_nop/all at the time. Well we don't need to arm the timer in both the get and put, do we Mika! Mika, please send a fix so we only arm the timer when putting. And blame the reviewer. Oh, that is bad. /o\ -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] drm/i915: Replace some more busy waits with normal ones
On Thu, Mar 24, 2016 at 01:16:40PM +, Chris Wilson wrote: > On Thu, Mar 24, 2016 at 01:06:41PM +, Tvrtko Ursulin wrote: > > > > On 24/03/16 12:27, Chris Wilson wrote: > > >On Thu, Mar 24, 2016 at 11:37:07AM +, Tvrtko Ursulin wrote: > > >> > > >>On 23/03/16 16:40, Chris Wilson wrote: > > >>>On Wed, Mar 23, 2016 at 04:24:48PM +, Tvrtko Ursulin wrote: > > Biggest thing to make sure is that you don't add a lot of cycles to > > the forcewake loops since for example fw_domains_get can be the > > hottest i915 function on some benchmarks. > > > > (This area slightly annoys me anyway with redundant looping over > > forcewake domains and we could also potentially optimize the ack > > waiting by first requesting all we want, and then doing the waits. > > That would be one additional loop, but if removed the other one, > > code would stay at the same number of domain loops.) > > >>> > > >>>I hear you. I just end up weeping in the corner when I see fw_domain_get > > >>>on the profile. > > >>> > > >>>We already do have a mitigation scheme to hold onto the forcewake for an > > >>>extra jiffie every time. I don't like it, but without it fw_domains_get > > >>>becomes a real hog. > > >> > > >>I am pretty sure I've seen some tests which somehow defeat the > > >>jiffie delay and we end up re-acquiring every ms/jiffie. This is > > >>something I wanted to get to the bottom of but did not get round to > > >>yet. It was totally unexpected because the test is hammering on > > >>everything. > > > > > >Absolutely sure it is not just the delay in acquiring the ack? And > > >spinning on waiting for the thread_c0 doesn't come cheap? I've just > > >written off fw_domain_get being high on the profiles simply due to that > > >we have to spin so long (I'm jaded because on Sandybridge spinning for > > >50us+ isn't uncommon iirc). > > > > I am not sure, I just know I had a printk in the timer release and > > it was firing every millisecond which completely perplexed me since > > I was running gem_exec_nop/all at the time. > > Well we don't need to arm the timer in both the get and put, do we Mika! > > Mika, please send a fix so we only arm the timer when putting. And blame > the reviewer. Even worse, you copied my mistake! Darn. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Only arm the forcewake release timer on the final put
If we arm the release timer on acquiring the forcewake, we will release
the forcewake on the jiffie afterwards. If we only arm the release timer
on the final put, we will release the forcewake slightly later instead.
Much, much worse, we did not acquire a refcount for the armed timing
during the get(), and so unbalanced our forcewake counting.
Reported-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_uncore.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 96799392c2c7..d857168c6c9b 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -60,6 +60,7 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
static inline void
fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
{
+ d->wake_count++;
mod_timer_pinned(&d->timer, jiffies + 1);
}
@@ -491,7 +492,6 @@ static void __intel_uncore_forcewake_put(struct
drm_i915_private *dev_priv,
if (--domain->wake_count)
continue;
- domain->wake_count++;
fw_domain_arm_timer(domain);
}
}
@@ -733,7 +733,6 @@ static inline void __force_wake_get(struct drm_i915_private
*dev_priv,
}
domain->wake_count++;
- fw_domain_arm_timer(domain);
}
if (fw_domains)
--
2.8.0.rc3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Only arm the forcewake release timer on the final put
On Thu, Mar 24, 2016 at 01:32:53PM +, Chris Wilson wrote:
> If we arm the release timer on acquiring the forcewake, we will release
> the forcewake on the jiffie afterwards. If we only arm the release timer
> on the final put, we will release the forcewake slightly later instead.
>
> Much, much worse, we did not acquire a refcount for the armed timing
> during the get(), and so unbalanced our forcewake counting.
>
> Reported-by: Tvrtko Ursulin
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/intel_uncore.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 96799392c2c7..d857168c6c9b 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -60,6 +60,7 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain
> *d)
> static inline void
> fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
> {
> + d->wake_count++;
> mod_timer_pinned(&d->timer, jiffies + 1);
Which raise the obvious issue that we double increment the counter if
the timer was pending (where we would only then release it once).
-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] drm/i915: Only arm the forcewake release timer on the final put
On 24/03/16 13:42, Chris Wilson wrote:
On Thu, Mar 24, 2016 at 01:32:53PM +, Chris Wilson wrote:
If we arm the release timer on acquiring the forcewake, we will release
the forcewake on the jiffie afterwards. If we only arm the release timer
on the final put, we will release the forcewake slightly later instead.
Much, much worse, we did not acquire a refcount for the armed timing
during the get(), and so unbalanced our forcewake counting.
Reported-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_uncore.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 96799392c2c7..d857168c6c9b 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -60,6 +60,7 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
static inline void
fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
{
+ d->wake_count++;
mod_timer_pinned(&d->timer, jiffies + 1);
Which raise the obvious issue that we double increment the counter if
the timer was pending (where we would only then release it once).
I don't see the bug, we got:
1) __intel_uncore_forcewake_put - if refcount reaches zero it will bump
it and arm the timer to decrement and release. This is used from
explicit get/put paths.
2) __force_wake_get - used from register reads only, so no explicit put
will happen. It just bumps the ref count and arms the timer.
I can't spot the bug, if there is one.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Only arm the forcewake release timer on the final put
If we arm the release timer on acquiring the forcewake, we will release
the forcewake on the jiffie afterwards. If we only arm the release timer
on the final put, we will release the forcewake slightly later instead.
Much, much worse, we did not acquire a refcount for the armed timing
during the get(), and so unbalanced our forcewake counting.
v2: Only claim the timer refcount if we start the timer.
Reported-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_uncore.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 96799392c2c7..b7b373900cb4 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -60,7 +60,8 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
static inline void
fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
{
- mod_timer_pinned(&d->timer, jiffies + 1);
+ if (!mod_timer_pinned(&d->timer, jiffies + 1))
+ d->wake_count++;
}
static inline void
@@ -491,7 +492,6 @@ static void __intel_uncore_forcewake_put(struct
drm_i915_private *dev_priv,
if (--domain->wake_count)
continue;
- domain->wake_count++;
fw_domain_arm_timer(domain);
}
}
@@ -733,7 +733,6 @@ static inline void __force_wake_get(struct drm_i915_private
*dev_priv,
}
domain->wake_count++;
- fw_domain_arm_timer(domain);
}
if (fw_domains)
--
2.8.0.rc3
___
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/2] drm/i915: Update VBT fields for child devices
== Series Details == Series: series starting with [1/2] drm/i915: Update VBT fields for child devices URL : https://patchwork.freedesktop.org/series/4858/ State : success == Summary == Series 4858v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/4858/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: dmesg-warn -> PASS (bsw-nuc-2) Subgroup basic-rte: dmesg-warn -> PASS (byt-nuc) UNSTABLE bdw-nuci7total:192 pass:179 dwarn:0 dfail:0 fail:1 skip:12 bdw-ultratotal:192 pass:170 dwarn:0 dfail:0 fail:1 skip:21 bsw-nuc-2total:192 pass:155 dwarn:0 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:157 dwarn:0 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:192 pass:181 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1706/ 83ec122b900baae1aca2bc11eedc28f2d9ea5060 drm-intel-nightly: 2016y-03m-24d-12h-48m-43s UTC integration manifest 031e9198b73186de00abd4fe545ac0a6cef01446 drm/i915: Set invert bit for hpd based on VBT 3a12d0a0a5a7c274d631b3e767008035139c6e99 drm/i915: Update VBT fields for child devices ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Use atomic state in debugfs.
Use proper locking, connector_state and encoder masks.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_debugfs.c | 72 ++---
1 file changed, 34 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9b740d8a3f5e..37b06ea9b112 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2655,13 +2655,11 @@ static int i915_sink_crc(struct seq_file *m, void *data)
drm_modeset_lock_all(dev);
for_each_intel_connector(dev, connector) {
- if (connector->base.dpms != DRM_MODE_DPMS_ON)
+ if (!connector->base.state->crtc ||
+ !connector->base.state->crtc->state->active)
continue;
- if (!connector->base.encoder)
- continue;
-
- encoder = to_intel_encoder(connector->base.encoder);
+ encoder = to_intel_encoder(connector->base.state->best_encoder);
if (encoder->type != INTEL_OUTPUT_EDP)
continue;
@@ -2837,14 +2835,17 @@ static void intel_encoder_info(struct seq_file *m,
struct drm_info_node *node = m->private;
struct drm_device *dev = node->minor->dev;
struct drm_crtc *crtc = &intel_crtc->base;
- struct intel_connector *intel_connector;
+ struct drm_connector *connector;
struct drm_encoder *encoder;
encoder = &intel_encoder->base;
seq_printf(m, "\tencoder %d: type: %s, connectors:\n",
encoder->base.id, encoder->name);
- for_each_connector_on_encoder(dev, encoder, intel_connector) {
- struct drm_connector *connector = &intel_connector->base;
+
+ drm_for_each_connector(connector, dev) {
+ if (connector->state->best_encoder != &intel_encoder->base)
+ continue;
+
seq_printf(m, "\t\tconnector %d: type: %s, status: %s",
connector->base.id,
connector->name,
@@ -3695,30 +3696,24 @@ static int i8xx_pipe_crc_ctl_reg(enum
intel_pipe_crc_source *source,
static int i9xx_pipe_crc_auto_source(struct drm_device *dev, enum pipe pipe,
enum intel_pipe_crc_source *source)
{
- struct intel_encoder *encoder;
- struct intel_crtc *crtc;
+ struct drm_encoder *encoder;
+ struct drm_crtc *crtc;
struct intel_digital_port *dig_port;
int ret = 0;
*source = INTEL_PIPE_CRC_SOURCE_PIPE;
drm_modeset_lock_all(dev);
- for_each_intel_encoder(dev, encoder) {
- if (!encoder->base.crtc)
- continue;
+ crtc = to_i915(dev)->pipe_to_crtc_mapping[pipe];
- crtc = to_intel_crtc(encoder->base.crtc);
-
- if (crtc->pipe != pipe)
- continue;
-
- switch (encoder->type) {
+ drm_for_each_encoder_mask(encoder, dev, crtc->state->encoder_mask) {
+ switch (to_intel_encoder(encoder)->type) {
case INTEL_OUTPUT_TVOUT:
*source = INTEL_PIPE_CRC_SOURCE_TV;
break;
case INTEL_OUTPUT_DISPLAYPORT:
case INTEL_OUTPUT_EDP:
- dig_port = enc_to_dig_port(&encoder->base);
+ dig_port = enc_to_dig_port(encoder);
switch (dig_port->port) {
case PORT_B:
*source = INTEL_PIPE_CRC_SOURCE_DP_B;
@@ -4322,14 +4317,11 @@ static ssize_t
i915_displayport_test_active_write(struct file *file,
int status = 0;
struct drm_device *dev;
struct drm_connector *connector;
- struct list_head *connector_list;
struct intel_dp *intel_dp;
int val = 0;
dev = ((struct seq_file *)file->private_data)->private;
- connector_list = &dev->mode_config.connector_list;
-
if (len == 0)
return 0;
@@ -4337,6 +4329,8 @@ static ssize_t i915_displayport_test_active_write(struct
file *file,
if (!input_buffer)
return -ENOMEM;
+ drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
+
if (copy_from_user(input_buffer, ubuf, len)) {
status = -EFAULT;
goto out;
@@ -4345,15 +4339,14 @@ static ssize_t
i915_displayport_test_active_write(struct file *file,
input_buffer[len] = '\0';
DRM_DEBUG_DRIVER("Copied %d bytes from user\n", (unsigned int)len);
- list_for_each_entry(connector, connector_list, head) {
-
+ drm_for_each_connector(connector, dev) {
if (connector->connector_type !=
DRM_MODE_CONNECTOR_DisplayPort)
continue;
if (connector->status == connector_status_connected &&
-
Re: [Intel-gfx] [PATCH] drm/i915: Only arm the forcewake release timer on the final put
On Thu, Mar 24, 2016 at 02:19:38PM +, Chris Wilson wrote:
> On Thu, Mar 24, 2016 at 01:54:36PM +, Tvrtko Ursulin wrote:
> >
> > On 24/03/16 13:42, Chris Wilson wrote:
> > >On Thu, Mar 24, 2016 at 01:32:53PM +, Chris Wilson wrote:
> > >>If we arm the release timer on acquiring the forcewake, we will release
> > >>the forcewake on the jiffie afterwards. If we only arm the release timer
> > >>on the final put, we will release the forcewake slightly later instead.
> > >>
> > >>Much, much worse, we did not acquire a refcount for the armed timing
> > >>during the get(), and so unbalanced our forcewake counting.
> > >>
> > >>Reported-by: Tvrtko Ursulin
> > >>Signed-off-by: Chris Wilson
> > >>Cc: Mika Kuoppala
> > >>Cc: Tvrtko Ursulin
> > >>---
> > >> drivers/gpu/drm/i915/intel_uncore.c | 3 +--
> > >> 1 file changed, 1 insertion(+), 2 deletions(-)
> > >>
> > >>diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> > >>b/drivers/gpu/drm/i915/intel_uncore.c
> > >>index 96799392c2c7..d857168c6c9b 100644
> > >>--- a/drivers/gpu/drm/i915/intel_uncore.c
> > >>+++ b/drivers/gpu/drm/i915/intel_uncore.c
> > >>@@ -60,6 +60,7 @@ fw_domain_reset(const struct
> > >>intel_uncore_forcewake_domain *d)
> > >> static inline void
> > >> fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
> > >> {
> > >>+ d->wake_count++;
> > >> mod_timer_pinned(&d->timer, jiffies + 1);
> > >
> > >Which raise the obvious issue that we double increment the counter if
> > >the timer was pending (where we would only then release it once).
> >
> > I don't see the bug, we got:
> >
> > 1) __intel_uncore_forcewake_put - if refcount reaches zero it will
> > bump it and arm the timer to decrement and release. This is used
> > from explicit get/put paths.
> >
> > 2) __force_wake_get - used from register reads only, so no explicit
> > put will happen. It just bumps the ref count and arms the timer.
> >
> > I can't spot the bug, if there is one.
>
> I mistook __force_wake_get for __intel_uncore_forcewake_get and jumped.
>
> Having said that we do still have the issue of double-increment if the
> timer is already armed. Or do we? I'm pretty sure we do.
I'll answer that. That is also no, because of the spinlock guarding it.
Oh well, I really thought I had an explanation there.
-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 4/6] drm/i915: Allow mmio updates on all platforms.
On Thu, Mar 24, 2016 at 09:35:04AM +0100, Maarten Lankhorst wrote:
> Op 23-03-16 om 16:07 schreef Ville Syrjälä:
> > On Wed, Mar 23, 2016 at 02:24:30PM +0100, Maarten Lankhorst wrote:
> >> Rename intel_unpin_work to intel_flip_work and use it for mmio flips
> >> and unpinning. Use flip_queued_req to hold the wait request in the
> >> mmio case and allow the vblank interrupt to complete mmio work to
> >> have mmio flips run correctly on g4 and earlier.
> > Before you actually go and trust drm_vblank_count() you should make it
> > race free.
>
> How about adding the below to the patch?
You can't just mix the hw and sw counter. Using the hw counter would be
neat because it doesn't require so much work to be race-free, but that
leaves out gen2 which I don't like. My atomic code used the hw counter
though, but I had plans to fall back to the sw counter on gen2
eventually.
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index befac649aa96..05ec832e02de 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11224,12 +11224,11 @@ static void intel_mmio_flip_work_func(struct
> work_struct *w)
> false, false,
>
> MAX_SCHEDULE_TIMEOUT) < 0);
>
> - intel_pipe_update_start(crtc);
> + intel_pipe_update_start(crtc, work);
> primary->update_plane(&primary->base,
> crtc->config,
> to_intel_plane_state(primary->base.state));
> - atomic_set(&work->pending, INTEL_FLIP_PENDING);
> - intel_pipe_update_end(crtc);
> + intel_pipe_update_end(crtc, work);
> }
>
> static int intel_default_queue_flip(struct drm_device *dev,
> @@ -13800,7 +13799,7 @@ static void intel_begin_crtc_commit(struct drm_crtc
> *crtc,
> bool modeset = needs_modeset(crtc->state);
>
> /* Perform vblank evasion around commit operation */
> - intel_pipe_update_start(intel_crtc);
> + intel_pipe_update_start(intel_crtc, NULL);
>
> if (modeset)
> return;
> @@ -13816,7 +13815,7 @@ static void intel_finish_crtc_commit(struct drm_crtc
> *crtc,
> {
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>
> - intel_pipe_update_end(intel_crtc);
> + intel_pipe_update_end(intel_crtc, NULL);
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index cac368138764..86d486cfd778 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1604,8 +1604,8 @@ bool intel_sdvo_init(struct drm_device *dev,
> int intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane);
> int intel_sprite_set_colorkey(struct drm_device *dev, void *data,
> struct drm_file *file_priv);
> -void intel_pipe_update_start(struct intel_crtc *crtc);
> -void intel_pipe_update_end(struct intel_crtc *crtc);
> +void intel_pipe_update_start(struct intel_crtc *crtc, struct intel_flip_work
> *work);
> +void intel_pipe_update_end(struct intel_crtc *crtc, struct intel_flip_work
> *work);
>
> /* intel_tv.c */
> void intel_tv_init(struct drm_device *dev);
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 8821533561b1..8da59a1eca56 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -78,7 +78,8 @@ static int usecs_to_scanlines(const struct drm_display_mode
> *adjusted_mode,
> * avoid random delays. The value written to @start_vbl_count should be
> * supplied to intel_pipe_update_end() for error checking.
> */
> -void intel_pipe_update_start(struct intel_crtc *crtc)
> +void intel_pipe_update_start(struct intel_crtc *crtc,
> + struct intel_flip_work *work)
> {
> struct drm_device *dev = crtc->base.dev;
> const struct drm_display_mode *adjusted_mode =
> &crtc->config->base.adjusted_mode;
> @@ -142,6 +143,9 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
> crtc->debug.start_vbl_count =
> dev->driver->get_vblank_counter(dev, pipe);
>
> + if (work)
> + work->flip_queued_vblank = crtc->debug.start_vbl_count;
> +
> trace_i915_pipe_update_vblank_evaded(crtc);
> }
>
> @@ -154,7 +158,7 @@ void intel_pipe_update_start(struct intel_crtc *crtc)
> * re-enables interrupts and verifies the update was actually completed
> * before a vblank using the value of @start_vbl_count.
> */
> -void intel_pipe_update_end(struct intel_crtc *crtc)
> +void intel_pipe_update_end(struct intel_crtc *crtc, struct intel_flip_work
> *work)
> {
> struct drm_device *dev = crtc->base.dev;
> enum pipe pipe = crtc->pipe;
> @@ -162,6 +166,12 @@ void intel_pipe_update_end(struct intel_crtc *crtc)
> u32 end_vbl_count = dev->driver->get_vblank_counter(dev
Re: [Intel-gfx] [PATCH] drm/i915: Only arm the forcewake release timer on the final put
On 24/03/16 13:42, Chris Wilson wrote:
On Thu, Mar 24, 2016 at 01:32:53PM +, Chris Wilson wrote:
If we arm the release timer on acquiring the forcewake, we will release
the forcewake on the jiffie afterwards. If we only arm the release timer
on the final put, we will release the forcewake slightly later instead.
Much, much worse, we did not acquire a refcount for the armed timing
during the get(), and so unbalanced our forcewake counting.
Reported-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_uncore.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 96799392c2c7..d857168c6c9b 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -60,6 +60,7 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
static inline void
fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
{
+ d->wake_count++;
mod_timer_pinned(&d->timer, jiffies + 1);
Which raise the obvious issue that we double increment the counter if
the timer was pending (where we would only then release it once).
-Chris
'jiffies + 1' might be only a nanosecond away; would it be better to use
'jiffies + 2'? OTOH that might be quite a long time and therefore
increase power consumption :( So is there a somewhat higher-resolution
cyclic timer that we could use?
Also, why mod_timer_pinned() ? I'd think that if this actually happens a
whole jiffie later, there'd be little correlation between the current
CPU activity and what's happening when the timer fires, so no real point
in pinning the timer to current CPU.
Using mod_timer() instead would allow it to apply slack and align the
callback to other timer activity, maybe reducing CPU overhead at the
possible cost of a slight increase in GPU power.
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Rename __force_wake_get to __force_wake_auto
__force_wake_get() only acquire a temporary wakeref on forcewake that is
automatically releases when a timer expires. When reading the code
again, I confused __intel_uncore_forcewake_get for __force_wake_get and
to my shame thought I found a bug in an unbalanced wake_count handling.
I claim that if the function had been called __force_wake_auto instead I
would not have embarrassed myself.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_uncore.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 96799392c2c7..165ebce5b638 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -716,8 +716,8 @@ __gen2_read(64)
trace_i915_reg_rw(false, reg, val, sizeof(val), trace); \
return val
-static inline void __force_wake_get(struct drm_i915_private *dev_priv,
- enum forcewake_domains fw_domains)
+static inline void __force_wake_auto(struct drm_i915_private *dev_priv,
+enum forcewake_domains fw_domains)
{
struct intel_uncore_forcewake_domain *domain;
enum forcewake_domain_id id;
@@ -745,7 +745,7 @@ static u##x \
gen6_read##x(struct drm_i915_private *dev_priv, i915_reg_t reg, bool trace) { \
GEN6_READ_HEADER(x); \
if (NEEDS_FORCE_WAKE(offset)) \
- __force_wake_get(dev_priv, FORCEWAKE_RENDER); \
+ __force_wake_auto(dev_priv, FORCEWAKE_RENDER); \
val = __raw_i915_read##x(dev_priv, reg); \
GEN6_READ_FOOTER; \
}
@@ -762,7 +762,7 @@ vlv_read##x(struct drm_i915_private *dev_priv, i915_reg_t
reg, bool trace) { \
else if (FORCEWAKE_VLV_MEDIA_RANGE_OFFSET(offset)) \
fw_engine = FORCEWAKE_MEDIA; \
if (fw_engine) \
- __force_wake_get(dev_priv, fw_engine); \
+ __force_wake_auto(dev_priv, fw_engine); \
val = __raw_i915_read##x(dev_priv, reg); \
GEN6_READ_FOOTER; \
}
@@ -781,7 +781,7 @@ chv_read##x(struct drm_i915_private *dev_priv, i915_reg_t
reg, bool trace) { \
else if (FORCEWAKE_CHV_COMMON_RANGE_OFFSET(offset)) \
fw_engine = FORCEWAKE_RENDER | FORCEWAKE_MEDIA; \
if (fw_engine) \
- __force_wake_get(dev_priv, fw_engine); \
+ __force_wake_auto(dev_priv, fw_engine); \
val = __raw_i915_read##x(dev_priv, reg); \
GEN6_READ_FOOTER; \
}
@@ -805,7 +805,7 @@ gen9_read##x(struct drm_i915_private *dev_priv, i915_reg_t
reg, bool trace) { \
else \
fw_engine = FORCEWAKE_BLITTER; \
if (fw_engine) \
- __force_wake_get(dev_priv, fw_engine); \
+ __force_wake_auto(dev_priv, fw_engine); \
val = __raw_i915_read##x(dev_priv, reg); \
GEN6_READ_FOOTER; \
}
@@ -969,7 +969,7 @@ static void \
gen8_write##x(struct drm_i915_private *dev_priv, i915_reg_t reg, u##x val,
bool trace) { \
GEN6_WRITE_HEADER; \
if (NEEDS_FORCE_WAKE(offset) && !is_gen8_shadowed(dev_priv, reg)) \
- __force_wake_get(dev_priv, FORCEWAKE_RENDER); \
+ __force_wake_auto(dev_priv, FORCEWAKE_RENDER); \
__raw_i915_write##x(dev_priv, reg, val); \
GEN6_WRITE_FOOTER; \
}
@@ -989,7 +989,7 @@ chv_write##x(struct drm_i915_private *dev_priv, i915_reg_t
reg, u##x val, bool t
else if (FORCEWAKE_CHV_COMMON_RANGE_OFFSET(offset)) \
fw_engine = FORCEWAKE_RENDER | FORCEWAKE_MEDIA; \
if (fw_engine) \
- __force_wake_get(dev_priv, fw_engine); \
+ __force_wake_auto(dev_priv, fw_engine); \
__raw_i915_write##x(dev_priv, reg, val); \
GEN6_WRITE_FOOTER; \
}
@@ -1036,7 +1036,7 @@ gen9_write##x(struct drm_i915_private *dev_priv,
i915_reg_t reg, u##x val, \
else \
fw_engine = FORCEWAKE_BLITTER; \
if (fw_engine) \
- __force_wake_get(dev_priv, fw_engine); \
+ __force_wake_auto(dev_priv, fw_engine); \
__raw_i915_write##x(dev_priv, reg, val); \
GEN6_WRITE_FOOTER; \
}
--
2.8.0.rc3
___
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: Refer to GGTT VM consistently
On ke, 2016-03-23 at 13:25 +, Chris Wilson wrote: > On Wed, Mar 23, 2016 at 03:00:23PM +0200, Joonas Lahtinen wrote: > > > > Refer to the GGTT VM consistently as "ggtt_vm" instead of just "ggtt", > > "vm" or indirectly through other variables like "dev_priv->ggtt.base" > > to avoid confusion with the i915_ggtt object itself and PPGTT VMs. > On the one hand, yes it seems more fitting to call it ggtt_vm. On the > other, we've been pretty consistent in calling the address space ggtt! > And I like the look of ggtt far more than ggtt_vm. Killing off more > mixed dev_priv->ggtt.base and ggtt pointer usage is definitely good > though. But I'm ambivalent about the whole. Right, ppgtt->base is also being used quite some so I guess you're right. I'll reroll the patches to get rid of ggtt_vm's everywhere and use ggtt->base. (I myself hate the convention, but lets stick to one convention). Regards, Joonas > -Chris > -- Joonas Lahtinen Open Source Technology Center Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: check vma for error in ggtt_unpin_view
On ke, 2016-03-23 at 15:39 +, Matthew Auld wrote:
> When unpinning a ggtt_view check vma for error, otherwise we may end up
> accessing an invalid pointer.
>
> Cc: Joonas Lahtinen
> Signed-off-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/i915_gem.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 8588c83..a8f3378 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4319,7 +4319,7 @@ i915_gem_object_ggtt_unpin_view(struct
> drm_i915_gem_object *obj,
> {
> struct i915_vma *vma = i915_gem_obj_to_ggtt_view(obj, view);
>
> - BUG_ON(!vma);
> + BUG_ON(IS_ERR_OR_NULL(vma));
Nicely spotted.
I discussed this with Tvrtko (CC'd him). I think we could
change i915_gem_obj_to_ggtt_view to BUG_ON(!view) instead of adding the
error handling in all places, as it is after all a programmer error to
provide NULL view.
Regards, Joonas
> WARN_ON(vma->pin_count == 0);
> WARN_ON(!i915_gem_obj_ggtt_bound_view(obj, view));
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] kernfs: Move faulting copy_user operations outside of the mutex
A fault in a user provided buffer may lead anywhere, and lockdep warns
that we have a potential deadlock between the mm->mmap_sem and the
kernfs file mutex:
[ 82.811702] ==
[ 82.811705] [ INFO: possible circular locking dependency detected ]
[ 82.811709] 4.5.0-rc4-gfxbench+ #1 Not tainted
[ 82.811711] ---
[ 82.811714] kms_setmode/5859 is trying to acquire lock:
[ 82.811717] (&dev->struct_mutex){+.+.+.}, at: []
drm_gem_mmap+0x1a1/0x270
[ 82.811731]
but task is already holding lock:
[ 82.811734] (&mm->mmap_sem){++}, at: []
vm_mmap_pgoff+0x44/0xa0
[ 82.811745]
which lock already depends on the new lock.
[ 82.811749]
the existing dependency chain (in reverse order) is:
[ 82.811752]
-> #3 (&mm->mmap_sem){++}:
[ 82.811761][] lock_acquire+0xc3/0x1d0
[ 82.811766][] __might_fault+0x75/0xa0
[ 82.811771][] kernfs_fop_write+0x8a/0x180
[ 82.811787][] __vfs_write+0x23/0xe0
[ 82.811792][] vfs_write+0xa4/0x190
[ 82.811797][] SyS_write+0x44/0xb0
[ 82.811801][] entry_SYSCALL_64_fastpath+0x16/0x73
[ 82.811807]
-> #2 (s_active#6){.+}:
[ 82.811814][] lock_acquire+0xc3/0x1d0
[ 82.811819][] __kernfs_remove+0x210/0x2f0
[ 82.811823][] kernfs_remove_by_name_ns+0x40/0xa0
[ 82.811828][] sysfs_remove_file_ns+0x10/0x20
[ 82.811832][] device_del+0x124/0x250
[ 82.811837][] device_unregister+0x19/0x60
[ 82.811841][] cpu_cache_sysfs_exit+0x51/0xb0
[ 82.811846][] cacheinfo_cpu_callback+0x38/0x70
[ 82.811851][] notifier_call_chain+0x39/0xa0
[ 82.811856][] __raw_notifier_call_chain+0x9/0x10
[ 82.811860][] cpu_notify+0x1e/0x40
[ 82.811865][] cpu_notify_nofail+0x9/0x20
[ 82.811869][] _cpu_down+0x233/0x340
[ 82.811874][] disable_nonboot_cpus+0xc9/0x350
[ 82.811878][] suspend_devices_and_enter+0x5a1/0xb50
[ 82.811883][] pm_suspend+0x543/0x8d0
[ 82.811888][] state_store+0x77/0xe0
[ 82.811892][] kobj_attr_store+0xf/0x20
[ 82.811897][] sysfs_kf_write+0x40/0x50
[ 82.811902][] kernfs_fop_write+0x13c/0x180
[ 82.811906][] __vfs_write+0x23/0xe0
[ 82.811910][] vfs_write+0xa4/0x190
[ 82.811914][] SyS_write+0x44/0xb0
[ 82.811918][] entry_SYSCALL_64_fastpath+0x16/0x73
[ 82.811923]
-> #1 (cpu_hotplug.lock){+.+.+.}:
[ 82.811929][] lock_acquire+0xc3/0x1d0
[ 82.811933][] mutex_lock_nested+0x62/0x3b0
[ 82.811940][] get_online_cpus+0x61/0x80
[ 82.811944][] stop_machine+0x1b/0xe0
[ 82.811949][]
gen8_ggtt_insert_entries__BKL+0x2d/0x30 [i915]
[ 82.812009][] ggtt_bind_vma+0x46/0x70 [i915]
[ 82.812045][] i915_vma_bind+0x140/0x290 [i915]
[ 82.812081][] i915_gem_object_do_pin+0x899/0xb00
[i915]
[ 82.812117][] i915_gem_object_pin+0x35/0x40 [i915]
[ 82.812154][] intel_init_pipe_control+0xbe/0x210
[i915]
[ 82.812192][] intel_logical_rings_init+0xe2/0xde0
[i915]
[ 82.812232][] i915_gem_init+0xf3/0x130 [i915]
[ 82.812278][] i915_driver_load+0xf2d/0x1770 [i915]
[ 82.812318][] drm_dev_register+0xa4/0xb0
[ 82.812323][] drm_get_pci_dev+0xce/0x1e0
[ 82.812328][] i915_pci_probe+0x2f/0x50 [i915]
[ 82.812360][] pci_device_probe+0x87/0xf0
[ 82.812366][] driver_probe_device+0x229/0x450
[ 82.812371][] __driver_attach+0x83/0x90
[ 82.812375][] bus_for_each_dev+0x61/0xa0
[ 82.812380][] driver_attach+0x19/0x20
[ 82.812384][] bus_add_driver+0x1ef/0x290
[ 82.812388][] driver_register+0x5b/0xe0
[ 82.812393][] __pci_register_driver+0x5b/0x60
[ 82.812398][] drm_pci_init+0xd6/0x100
[ 82.812402][] 0xa027c094
[ 82.812406][] do_one_initcall+0xae/0x1d0
[ 82.812412][] do_init_module+0x5b/0x1cb
[ 82.812417][] load_module+0x1c20/0x2480
[ 82.812422][] SyS_finit_module+0x7e/0xa0
[ 82.812428][] entry_SYSCALL_64_fastpath+0x16/0x73
[ 82.812433]
-> #0 (&dev->struct_mutex){+.+.+.}:
[ 82.812439][] __lock_acquire+0x1fc9/0x20f0
[ 82.812443][] lock_acquire+0xc3/0x1d0
[ 82.812456][] drm_gem_mmap+0x1c7/0x270
[ 82.812460][] mmap_region+0x334/0x580
[ 82.812466][] do_mmap+0x364/0x410
[ 82.812470][] vm_mmap_pgoff+0x6d/0xa0
[ 82.812474][] SyS_mmap_pgoff+0x184/0x220
[ 82.812479][] SyS_mmap+0x1d/0x20
[ 82.812484][] entry_SYSCALL_64_fastpath+0x16/0x73
[ 82.812489]
other info that might help us debug this:
[ 82.812493] Chain exists of:
&dev->struct_mutex --> s_active#6 --> &mm->mmap_sem
[ 82.812502] Possible unsafe locking scenario:
[ 82.812506]CPU
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Rename GGTT init functions
On ke, 2016-03-23 at 17:54 +0200, Mika Kuoppala wrote:
> Ville Syrjälä writes:
>
> >
> > [ text/plain ]
> > On Wed, Mar 23, 2016 at 03:00:22PM +0200, Joonas Lahtinen wrote:
> > >
> > > Rename and document the GGTT init functions to give a better
> > > idea of the context where they are called from.
> > >
> > > i915_gem_gtt_init => i915_init_ggtt_hw
> > Seems to me i915_ggtt_init_hw would match existing practices better.
> >
> There is also some gravity towards putting the verb first. In gem
> side atleast.
>
When one excludes i915_gem_init_* functions there are not so many left
(0).
So I will change it as suggested by Ville (and Daniel too).
Regards, Joonas
> -Mika
>
>
> >
> > >
> > > i915_gem_init_global_gtt => i915_gem_init_ggtt
> > > i915_global_gtt_cleanup => i915_cleanup_ggtt_hw
> > >
> > > Cc: Tvrtko Ursulin
> > > Cc: Mika Kuoppala
> > > Acked-by: Chris Wilson
> > > Signed-off-by: Joonas Lahtinen
> > > ---
> > > drivers/gpu/drm/i915/i915_dma.c | 14 +++---
> > > drivers/gpu/drm/i915/i915_gem.c | 2 +-
> > > drivers/gpu/drm/i915/i915_gem_gtt.c | 18 +++---
> > > drivers/gpu/drm/i915/i915_gem_gtt.h | 7 +++
> > > 4 files changed, 26 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_dma.c
> > > b/drivers/gpu/drm/i915/i915_dma.c
> > > index fc8ac98..124cefd 100644
> > > --- a/drivers/gpu/drm/i915/i915_dma.c
> > > +++ b/drivers/gpu/drm/i915/i915_dma.c
> > > @@ -1180,7 +1180,7 @@ static int i915_driver_init_hw(struct
> > > drm_i915_private *dev_priv)
> > >
> > > intel_device_info_runtime_init(dev);
> > >
> > > - ret = i915_gem_gtt_init(dev);
> > > + ret = i915_init_ggtt_hw(dev);
> > > if (ret)
> > > return ret;
> > >
> > > @@ -1189,13 +1189,13 @@ static int i915_driver_init_hw(struct
> > > drm_i915_private *dev_priv)
> > > ret = i915_kick_out_firmware_fb(dev_priv);
> > > if (ret) {
> > > DRM_ERROR("failed to remove conflicting framebuffer drivers\n");
> > > - goto out_gtt;
> > > + goto out_ggtt;
> > > }
> > >
> > > ret = i915_kick_out_vgacon(dev_priv);
> > > if (ret) {
> > > DRM_ERROR("failed to remove conflicting VGA console\n");
> > > - goto out_gtt;
> > > + goto out_ggtt;
> > > }
> > >
> > > pci_set_master(dev->pdev);
> > > @@ -1222,7 +1222,7 @@ static int i915_driver_init_hw(struct
> > > drm_i915_private *dev_priv)
> > > aperture_size);
> > > if (dev_priv->ggtt.mappable == NULL) {
> > > ret = -EIO;
> > > - goto out_gtt;
> > > + goto out_ggtt;
> > > }
> > >
> > > dev_priv->ggtt.mtrr = arch_phys_wc_add(dev_priv->ggtt.mappable_base,
> > > @@ -1255,8 +1255,8 @@ static int i915_driver_init_hw(struct
> > > drm_i915_private *dev_priv)
> > >
> > > return 0;
> > >
> > > -out_gtt:
> > > - i915_global_gtt_cleanup(dev);
> > > +out_ggtt:
> > > + i915_cleanup_ggtt_hw(dev);
> > >
> > > return ret;
> > > }
> > > @@ -1275,7 +1275,7 @@ static void i915_driver_cleanup_hw(struct
> > > drm_i915_private *dev_priv)
> > > pm_qos_remove_request(&dev_priv->pm_qos);
> > > arch_phys_wc_del(dev_priv->ggtt.mtrr);
> > > io_mapping_free(dev_priv->ggtt.mappable);
> > > - i915_global_gtt_cleanup(dev);
> > > + i915_cleanup_ggtt_hw(dev);
> > > }
> > >
> > > /**
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index 8588c83..506a706 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -4972,7 +4972,7 @@ int i915_gem_init(struct drm_device *dev)
> > > if (ret)
> > > goto out_unlock;
> > >
> > > - i915_gem_init_global_gtt(dev);
> > > + i915_gem_init_ggtt(dev);
> > >
> > > ret = i915_gem_context_init(dev);
> > > if (ret)
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > index 0715bb7..c23513b 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > > @@ -2808,7 +2808,11 @@ static int i915_gem_setup_global_gtt(struct
> > > drm_device *dev,
> > > return 0;
> > > }
> > >
> > > -void i915_gem_init_global_gtt(struct drm_device *dev)
> > > +/**
> > > + * i915_gem_init_ggtt - Initialize GEM for Global GTT
> > > + * @dev: DRM device
> > > + */
> > > +void i915_gem_init_ggtt(struct drm_device *dev)
> > > {
> > > struct drm_i915_private *dev_priv = dev->dev_private;
> > > u64 gtt_size, mappable_size;
> > > @@ -2819,7 +2823,11 @@ void i915_gem_init_global_gtt(struct drm_device
> > > *dev)
> > > i915_gem_setup_global_gtt(dev, 0, mappable_size, gtt_size);
> > > }
> > >
> > > -void i915_global_gtt_cleanup(struct drm_device *dev)
> > > +/**
> > > + * i915_cleanup_ggtt_hw - Clean up GGTT hardware initialization
> > > + * @dev: DRM device
> > > + */
> > > +void i915_cleanup_ggtt_hw(struct drm_device *dev)
> > > {
> > > struct drm_i915_private *dev_priv
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Move execlists irq handler to a bottom half (rev3)
== Series Details == Series: drm/i915: Move execlists irq handler to a bottom half (rev3) URL : https://patchwork.freedesktop.org/series/4764/ State : warning == Summary == Series 4764v3 drm/i915: Move execlists irq handler to a bottom half http://patchwork.freedesktop.org/api/1.0/series/4764/revisions/3/mbox/ Test gem_exec_suspend: Subgroup basic-s3: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: dmesg-warn -> PASS (bsw-nuc-2) pass -> DMESG-WARN (byt-nuc) Subgroup basic-rte: dmesg-warn -> PASS (byt-nuc) UNSTABLE bdw-nuci7total:192 pass:179 dwarn:0 dfail:0 fail:1 skip:12 bdw-ultratotal:192 pass:170 dwarn:0 dfail:0 fail:1 skip:21 bsw-nuc-2total:192 pass:155 dwarn:0 dfail:0 fail:0 skip:37 byt-nuc total:192 pass:156 dwarn:1 dfail:0 fail:0 skip:35 hsw-brixbox total:192 pass:170 dwarn:0 dfail:0 fail:0 skip:22 hsw-gt2 total:192 pass:175 dwarn:0 dfail:0 fail:0 skip:17 ivb-t430stotal:192 pass:167 dwarn:0 dfail:0 fail:0 skip:25 skl-i7k-2total:192 pass:169 dwarn:0 dfail:0 fail:0 skip:23 skl-nuci5total:192 pass:181 dwarn:0 dfail:0 fail:0 skip:11 snb-dellxps total:192 pass:158 dwarn:0 dfail:0 fail:0 skip:34 snb-x220ttotal:192 pass:158 dwarn:0 dfail:0 fail:1 skip:33 Results at /archive/results/CI_IGT_test/Patchwork_1707/ 83ec122b900baae1aca2bc11eedc28f2d9ea5060 drm-intel-nightly: 2016y-03m-24d-12h-48m-43s UTC integration manifest b4a4e726b4f10b0782c821bf73c945533ec882e8 drm/i915: Move execlists irq handler to a bottom half ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Allow mmio updates on all platforms.
Op 24-03-16 om 15:26 schreef Ville Syrjälä: > On Thu, Mar 24, 2016 at 09:35:04AM +0100, Maarten Lankhorst wrote: >> Op 23-03-16 om 16:07 schreef Ville Syrjälä: >>> On Wed, Mar 23, 2016 at 02:24:30PM +0100, Maarten Lankhorst wrote: Rename intel_unpin_work to intel_flip_work and use it for mmio flips and unpinning. Use flip_queued_req to hold the wait request in the mmio case and allow the vblank interrupt to complete mmio work to have mmio flips run correctly on g4 and earlier. >>> Before you actually go and trust drm_vblank_count() you should make it >>> race free. >> How about adding the below to the patch? > You can't just mix the hw and sw counter. Using the hw counter would be > neat because it doesn't require so much work to be race-free, but that > leaves out gen2 which I don't like. My atomic code used the hw counter > though, but I had plans to fall back to the sw counter on gen2 > eventually. > So I dug in a little bit more.. MMIO updates don't require accurate vblank count for anything, so even if it was completely removed it would work. The only thing it's used for is for cs flips, if more than 1 vblank passed since submission, the request gets a rps boost. If more than 3 vblanks have passed after the request the cs flip waits on completed, the cs page flip is considered stuck and will be forcefully completed. With stale values the worst case rps boost might get applied right away, or the cs flip is forcefully completed after only 2 vblanks. Neither affects mmio flips, so ignore this extra hunk and look at the original patch. :) ~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: Set invert bit for hpd based on VBT
On Thu, Mar 24, 2016 at 05:40:51PM +0530, Shubhangi Shrivastava wrote:
> This patch sets the invert bit for hpd detection for each port
> based on VBT configuration. Since each AOB can be designed to
> depend on invert bit or not, it is expected if an AOB requires
> invert bit, the user will set respective bit in VBT.
>
> v2: Separated VBT parsing from the rest of the logic. (Jani)
>
> v3: Moved setting invert bit logic to bxt_hpd_irq_setup()
> and changed its logic to avoid looping twice. (Ville)
>
> v4: Changed the logic to mask out the bits first and then
> set them to remove need of temporary variable. (Ville)
>
> v5: Moved defines to existing set of defines for the register
> Changed logic to incorporate required breaks. (Ville)
>
> Signed-off-by: Sivakumar Thulasimani
> Signed-off-by: Durgadoss R
> Signed-off-by: Shubhangi Shrivastava
> Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/i915_irq.c | 20
> drivers/gpu/drm/i915/i915_reg.h | 6 ++
> drivers/gpu/drm/i915/intel_bios.c | 32
> 4 files changed, 60 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9d29ab0..86fb5cb 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3396,6 +3396,8 @@ bool intel_bios_is_tv_present(struct drm_i915_private
> *dev_priv);
> bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8
> *i2c_pin);
> bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port
> port);
> bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port
> *port);
> +bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
> + enum port port);
>
> /* intel_opregion.c */
> #ifdef CONFIG_ACPI
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index a55a7cc..8fbec3e 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3504,6 +3504,26 @@ static void bxt_hpd_irq_setup(struct drm_device *dev)
> hotplug = I915_READ(PCH_PORT_HOTPLUG);
> hotplug |= PORTC_HOTPLUG_ENABLE | PORTB_HOTPLUG_ENABLE |
> PORTA_HOTPLUG_ENABLE;
> +
> + DRM_DEBUG_KMS("Invert bit setting: hp_ctl:%x hp_port:%x\n",
> + hotplug, enabled_irqs);
> + hotplug &= ~BXT_DDI_HPD_INVERT_MASK;
> +
> + /*
> + * For BXT invert bit has to be set based on AOB design
> + * for HPD detection logic, update it based on VBT fields.
> + */
> +
> + if ((enabled_irqs & BXT_DE_PORT_HP_DDIA) &&
> + intel_bios_is_port_hpd_inverted(dev_priv, PORT_A))
> + hotplug |= BXT_DDIA_HPD_INVERT;
> + if ((enabled_irqs & BXT_DE_PORT_HP_DDIB) &&
> + intel_bios_is_port_hpd_inverted(dev_priv, PORT_B))
> + hotplug |= BXT_DDIB_HPD_INVERT;
> + if ((enabled_irqs & BXT_DE_PORT_HP_DDIC) &&
> + intel_bios_is_port_hpd_inverted(dev_priv, PORT_C))
> + hotplug |= BXT_DDIC_HPD_INVERT;
> +
> I915_WRITE(PCH_PORT_HOTPLUG, hotplug);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index f3ba43c..73a806c 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6185,6 +6185,7 @@ enum skl_disp_power_wells {
> /* digital port hotplug */
> #define PCH_PORT_HOTPLUG _MMIO(0xc4030) /* SHOTPLUG_CTL */
> #define PORTA_HOTPLUG_ENABLE(1 << 28) /* LPT:LP+ & BXT */
> +#define BXT_DDIA_HPD_INVERT(1 << 27)
> #define PORTA_HOTPLUG_STATUS_MASK (3 << 24) /* SPT+ & BXT */
> #define PORTA_HOTPLUG_NO_DETECT (0 << 24) /* SPT+ & BXT */
> #define PORTA_HOTPLUG_SHORT_DETECT (1 << 24) /* SPT+ & BXT */
> @@ -6200,6 +6201,7 @@ enum skl_disp_power_wells {
> #define PORTD_HOTPLUG_SHORT_DETECT (1 << 16)
> #define PORTD_HOTPLUG_LONG_DETECT (2 << 16)
> #define PORTC_HOTPLUG_ENABLE(1 << 12)
> +#define BXT_DDIC_HPD_INVERT(1 << 11)
> #define PORTC_PULSE_DURATION_2ms(0 << 10) /* pre-LPT */
> #define PORTC_PULSE_DURATION_4_5ms (1 << 10) /* pre-LPT */
> #define PORTC_PULSE_DURATION_6ms(2 << 10) /* pre-LPT */
> @@ -6210,6 +6212,7 @@ enum skl_disp_power_wells {
> #define PORTC_HOTPLUG_SHORT_DETECT (1 << 8)
> #define PORTC_HOTPLUG_LONG_DETECT (2 << 8)
> #define PORTB_HOTPLUG_ENABLE(1 << 4)
> +#define BXT_DDIB_HPD_INVERT(1 << 3)
> #define PORTB_PULSE_DURATION_2ms(0 << 2) /* pre-LPT */
> #define PORTB_PULSE_DURATION_4_5ms (1 << 2) /* pre-LPT */
> #define PORTB_PULSE_DURATION_6ms(2 << 2) /* pre-LPT */
> @@ -6219,6 +6222,9 @@ enum skl_disp_power_wells {
> #define PORTB_HOTPLUG_NO_DETECT (0 << 0)
> #define PORTB_HOTPLUG_SHORT_DETECT (1 << 0)
> #define PORTB_HOTPLUG_LONG_DETECT (2 << 0)
> +
Re: [Intel-gfx] [PATCH] drm/i915: Only arm the forcewake release timer on the final put
On 24/03/16 13:32, Chris Wilson wrote:
If we arm the release timer on acquiring the forcewake, we will release
the forcewake on the jiffie afterwards. If we only arm the release timer
on the final put, we will release the forcewake slightly later instead.
Yes, I had wondered why we armed to timer on forcewake_get(). So
definitely agree it should be on last put().
Much, much worse, we did not acquire a refcount for the armed timing
during the get(), and so unbalanced our forcewake counting.
Hmm ... refcount /looks/ OK to me? But I'd need to check more ...
.Dave.
Reported-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_uncore.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 96799392c2c7..d857168c6c9b 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -60,6 +60,7 @@ fw_domain_reset(const struct intel_uncore_forcewake_domain *d)
static inline void
fw_domain_arm_timer(struct intel_uncore_forcewake_domain *d)
{
+ d->wake_count++;
mod_timer_pinned(&d->timer, jiffies + 1);
}
@@ -491,7 +492,6 @@ static void __intel_uncore_forcewake_put(struct
drm_i915_private *dev_priv,
if (--domain->wake_count)
continue;
- domain->wake_count++;
fw_domain_arm_timer(domain);
}
}
@@ -733,7 +733,6 @@ static inline void __force_wake_get(struct drm_i915_private
*dev_priv,
}
domain->wake_count++;
- fw_domain_arm_timer(domain);
}
if (fw_domains)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Parsing the PWM cntrl and CABC ON/OFF fileds in VBT
On Thu, 24 Mar 2016, Deepak M wrote:
> For dual link panel scenarios there are new fileds added in the
> VBT which indicate on which port the PWM cntrl and CABC ON/OFF
> commands needs to be sent.
>
> v2: Moving the comment to intel_dsi.h(Jani)
>
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Yetunde Adebisi
> Signed-off-by: Deepak M
> ---
> drivers/gpu/drm/i915/intel_bios.c | 10 ++
> drivers/gpu/drm/i915/intel_bios.h | 5 -
> drivers/gpu/drm/i915/intel_dsi.h | 9 +
> 3 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 083003b..587c06f 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -749,6 +749,16 @@ parse_mipi_config(struct drm_i915_private *dev_priv,
> return;
> }
>
> + /*
> + * These fileds are introduced from the VBT version 197 onwards,
> + * so making sure that these bits are set zero in the pervious
> + * versions.
> + */
*fields* and *previous*.
> + if (dev_priv->vbt.dsi.config->dual_link && bdb->version < 197) {
> + dev_priv->vbt.dsi.config->dl_cabc_port = 0;
> + dev_priv->vbt.dsi.config->pwm_bkl_ctrl = 0;
> + }
> +
> /* We have mandatory mipi config blocks. Initialize as generic panel */
> dev_priv->vbt.dsi.panel_id = MIPI_DSI_GENERIC_PANEL_ID;
> }
> diff --git a/drivers/gpu/drm/i915/intel_bios.h
> b/drivers/gpu/drm/i915/intel_bios.h
> index ab0ea31..7a89f79 100644
> --- a/drivers/gpu/drm/i915/intel_bios.h
> +++ b/drivers/gpu/drm/i915/intel_bios.h
> @@ -113,7 +113,10 @@ struct mipi_config {
> u16 dual_link:2;
> u16 lane_cnt:2;
> u16 pixel_overlap:3;
> - u16 rsvd3:9;
> + u16 rgb_flip:1;
> + u16 dl_cabc_port:2;
> + u16 pwm_bkl_ctrl:2;
Dunno, how about "dual_link_cabc_ports" and "dual_link_pwm_ports" or
something? These two are closely related, why do you name them so
different and difficult?
> + u16 rsvd3:4;
>
> u16 rsvd4;
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi.h
> b/drivers/gpu/drm/i915/intel_dsi.h
> index e582ef8..0e758f1 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.h
> +++ b/drivers/gpu/drm/i915/intel_dsi.h
> @@ -78,6 +78,15 @@ struct intel_dsi {
>
> u8 escape_clk_div;
> u8 dual_link;
> +
> + /*
> + * Below field will inform us on which port the panel blk_cntrl
> + * and CABC ON/OFF commands needs to be sent in case of dual link
> + * panels
> + */
It's actually not clear to me from the VBT spec which DCS commands
should use which ports. What are "Panel PWM Bklt Controller On/OFF
commands"? What are "CABC On/OFF commands"?
> + u8 bkl_dcs_ports;
> + u8 pwm_blk_ctrl;
You don't actually set or use this field for anything.
> +
> u8 pixel_overlap;
> u32 port_bits;
> u32 bw_timer;
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
