Re: [Intel-gfx] [PATCH 09/18] drm/i915: support inserting 64K pages in the ppgtt

[kbuild test robot]

Hi Matthew,

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20170405]
[cannot apply to v4.11-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Matthew-Auld/drm-i915-initial-support-for-huge-gtt-pages-V2/20170406-060958
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-s2-04061013 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ppgtt_insert_4lvl':
>> drivers/gpu/drm/i915/i915_gem_gtt.c:1002: warning: 'iter' is used 
>> uninitialized in this function
   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ppgtt_insert_3lvl':
   drivers/gpu/drm/i915/i915_gem_gtt.c:983: warning: 'iter.sg' is used 
uninitialized in this function
   drivers/gpu/drm/i915/i915_gem_gtt.c:984: warning: 'iter.dma' is used 
uninitialized in this function

vim +/iter +1002 drivers/gpu/drm/i915/i915_gem_gtt.c

9e89f9ee3 Chris Wilson   2017-02-25   986   struct gen8_insert_pte idx = 
gen8_insert_pte(start);
de5ba8eb9 Michel Thierry 2015-08-03   987  
9e89f9ee3 Chris Wilson   2017-02-25   988   
gen8_ppgtt_insert_pte_entries(ppgtt, >pdp, , ,
9e89f9ee3 Chris Wilson   2017-02-25   989 
cache_level);
de5ba8eb9 Michel Thierry 2015-08-03   990  }
894ccebee Chris Wilson   2017-02-15   991  
894ccebee Chris Wilson   2017-02-15   992  static void 
gen8_ppgtt_insert_4lvl(struct i915_address_space *vm,
894ccebee Chris Wilson   2017-02-15   993  
struct sg_table *pages,
75c7b0b86 Chris Wilson   2017-02-15   994  u64 
start,
c7a43c911 Matthew Auld   2017-04-04   995  
unsigned int page_size,
894ccebee Chris Wilson   2017-02-15   996  enum 
i915_cache_level cache_level,
894ccebee Chris Wilson   2017-02-15   997  u32 
unused)
894ccebee Chris Wilson   2017-02-15   998  {
894ccebee Chris Wilson   2017-02-15   999   struct i915_hw_ppgtt *ppgtt = 
i915_vm_to_ppgtt(vm);
894ccebee Chris Wilson   2017-02-15  1000   struct sgt_dma iter = {
894ccebee Chris Wilson   2017-02-15  1001   .sg = pages->sgl,
894ccebee Chris Wilson   2017-02-15 @1002   .dma = 
sg_dma_address(iter.sg),
894ccebee Chris Wilson   2017-02-15  1003   .max = iter.dma + 
iter.sg->length,
894ccebee Chris Wilson   2017-02-15  1004   };
894ccebee Chris Wilson   2017-02-15  1005   struct 
i915_page_directory_pointer **pdps = ppgtt->pml4.pdps;
9e89f9ee3 Chris Wilson   2017-02-25  1006   struct gen8_insert_pte idx = 
gen8_insert_pte(start);
c7a43c911 Matthew Auld   2017-04-04  1007   bool (*insert_entries)(struct 
i915_hw_ppgtt *ppgtt,
c7a43c911 Matthew Auld   2017-04-04  1008  struct 
i915_page_directory_pointer *pdp,
c7a43c911 Matthew Auld   2017-04-04  1009  struct 
sgt_dma *iter,
c7a43c911 Matthew Auld   2017-04-04  1010  struct 
gen8_insert_pte *idx,

:: The code at line 1002 was first introduced by commit
:: 894ccebee2b0e606ba9638d20dd87b33568482d7 drm/i915: Micro-optimise 
gen8_ppgtt_insert_entries()

:: TO: Chris Wilson <ch...@chris-wilson.co.uk>
:: CC: Chris Wilson <ch...@chris-wilson.co.uk>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/atomic: Add connector atomic_check function.

[Pandiyan, Dhinakaran]

On Wed, 2017-04-05 at 12:06 +0200, Daniel Vetter wrote:
> On Wed, Apr 05, 2017 at 10:41:24AM +0200, Maarten Lankhorst wrote:
> > The connector atomic check function may be called multiple times,
> > or not at all. It's mostly useful for implementing properties but if you
> > call check_modeset twice it can be used for other modeset related checks
> > as well.
> > 
> > Signed-off-by: Maarten Lankhorst 
> > ---
> >  drivers/gpu/drm/drm_atomic_helper.c  | 25 +
> >  include/drm/drm_modeset_helper_vtables.h | 37 
> > 
> >  2 files changed, 58 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index c3994b4d5f32..d550e79e8347 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -459,10 +459,20 @@ mode_fixup(struct drm_atomic_state *state)
> >   *
> >   * Check the state object to see if the requested state is physically 
> > possible.
> >   * This does all the crtc and connector related computations for an atomic
> > - * update and adds any additional connectors needed for full modesets and 
> > calls
> > - * down into _crtc_helper_funcs.mode_fixup and
> > - * _encoder_helper_funcs.mode_fixup or
> > - * _encoder_helper_funcs.atomic_check functions of the driver backend.
> > + * update and adds any additional connectors needed for full modesets. It 
> > calls
> > + * the various per-object callbacks in the follow order:
> > + *
> > + * 1. _connector_helper_funcs.atomic_best_encoder for determining the 
> > new encoder.
> > + * 2. _connector_helper_funcs.atomic_check to validate the connector 
> > state.
> > + * 3. If it's determined a modeset is needed then all connectors on the 
> > affected crtc
> > + *crtc are added.
Typo - 'crtc' typed twice.

update_output_state which is called before _helper_check_modeset() also
adds all affected connectors. Why is that not considered when you say
affected connectors are added in Step 3? Is that because
update_output_state() is in the legacy modeset path?


> > + * 4. _bridge_funcs.mode_fixup is called on all encoder bridges.
> > + * 5. _encoder_helper_funcs.atomic_check is called to validate any 
> > encoder state.
> > + *This function is only called when the encoder will be part of a 
> > configured crtc,
> > + *it must not be used for implementing connector property validation.
> > + *If this function is NULL, 
> > _atomic_encoder_helper_funcs.mode_fixup is called
> > + *instead.
> > + * 6. _crtc_helper_funcs.mode_fixup is called last, to fix up the mode 
> > with crtc constraints.
> 
> Line too I think. And maybe insert empty lines between each item, to make
> them stand out more. Shouldn't affect rendering, but better to recheck.
> 
> >   *
> >   * _crtc_state.mode_changed is set when the input mode is changed.
> >   * _crtc_state.connectors_changed is set when a connector is added or
> > @@ -522,6 +532,8 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > return ret;
> >  
> > for_each_oldnew_connector_in_state(state, connector, 
> > old_connector_state, new_connector_state, i) {
> > +   const struct drm_connector_helper_funcs *funcs = 
> > connector->helper_private;
> > +
> > /*
> >  * This only sets crtc->connectors_changed for routing changes,
> >  * drivers must set crtc->connectors_changed themselves when
> > @@ -539,6 +551,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> > new_connector_state->link_status)
> > new_crtc_state->connectors_changed = true;
> > }
> > +
> > +   if (funcs->atomic_check)
> > +   ret = funcs->atomic_check(connector, 
> > new_connector_state);
> > +   if (ret)
> > +   return ret;
> > }
> >  
> > /*
> > diff --git a/include/drm/drm_modeset_helper_vtables.h 
> > b/include/drm/drm_modeset_helper_vtables.h
> > index b304950b402d..7b5dd909f189 100644
> > --- a/include/drm/drm_modeset_helper_vtables.h
> > +++ b/include/drm/drm_modeset_helper_vtables.h
> > @@ -860,6 +860,43 @@ struct drm_connector_helper_funcs {
> >  */
> > struct drm_encoder *(*atomic_best_encoder)(struct drm_connector 
> > *connector,
> >struct drm_connector_state 
> > *connector_state);
> > +
> > +   /**
> > +* @atomic_check:
> > +*
> > +* Drivers should check connector properties in this
> > +* hook. This function is called from _atomic_helper_check_modeset.
> > +*
> > +* This function may not be called at all on a modeset or connector
> > +* change, so it should only be used to validate properties.

I did not understand this part - "function may not be called at all on a
modeset or connector change". Why is that?

> > +* If it's required to 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use the right mapping_gfp_mask for final shmem allocation

[Patchwork]

== Series Details ==

Series: drm/i915: Use the right mapping_gfp_mask for final shmem allocation
URL   : https://patchwork.freedesktop.org/series/22554/
State : success

== Summary ==

Series 22554v1 drm/i915: Use the right mapping_gfp_mask for final shmem 
allocation
https://patchwork.freedesktop.org/api/1.0/series/22554/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 427s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 423s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time: 569s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 506s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 552s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time: 488s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 479s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 412s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 417s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 423s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 478s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 471s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 455s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 566s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 461s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 573s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 458s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 491s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 437s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 532s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 400s

39a0f48c8bc7c528cc705016dafa08a9dedfd36b drm-tip: 2017y-04m-05d-13h-22m-47s UTC 
integration manifest
2648b12 drm/i915: Use the right mapping_gfp_mask for final shmem allocation

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4416/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Use the right mapping_gfp_mask for final shmem allocation

[Chris Wilson]

Many sightings report the greater prevalence of allocation failures.
This is all due to the incorrect use of mapping_gfp_constraint(), so
remove it in favour of just querying the mapping_gfp_mask() which are
the exact gfp_t we wanted in the first place.

We still do expect a higher chance of reporting ENOMEM, as that is the
intention of using __GFP_NORETRY -- to fail rather than oom after having
reclaimed from our bo caches, and having done a direct|kswapd reclaim
pass.

Reported-by: Jason Ekstrand 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100594
Fixes: 24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than incur the 
oom for gfx allocations")
Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Cc: Daniel Vetter 
---
 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 5f911a25e99a..57f51f1dac69 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2314,7 +2314,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
 * defer the oom here by reporting the ENOMEM back
 * to userspace.
 */
-   reclaim = mapping_gfp_constraint(mapping, 0);
+   reclaim = mapping_gfp_mask(mapping);
reclaim |= __GFP_NORETRY; /* reclaim, but no oom */
 
page = shmem_read_mapping_page_gfp(mapping, i, reclaim);
-- 
2.11.0

___
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: Treat WC a separate cache domain

[Patchwork]

== Series Details ==

Series: drm/i915: Treat WC a separate cache domain
URL   : https://patchwork.freedesktop.org/series/22549/
State : success

== Summary ==

Series 22549v1 drm/i915: Treat WC a separate cache domain
https://patchwork.freedesktop.org/api/1.0/series/22549/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 432s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 426s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time: 581s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 508s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 534s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time: 491s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 485s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 413s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 415s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 425s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 490s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 474s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 459s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 565s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 446s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 566s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 457s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 497s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 435s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 529s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 404s

39a0f48c8bc7c528cc705016dafa08a9dedfd36b drm-tip: 2017y-04m-05d-13h-22m-47s UTC 
integration manifest
72b1aff drm/i915: Treat WC a separate cache domain

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4415/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Treat WC a separate cache domain

[Chris Wilson]

When discussing a new WC mmap, we based the interface upon the
assumption that GTT was fully coherent. How naive! Commits 3b5724d702ef
("drm/i915: Wait for writes through the GTT to land before reading
back") and ed4596ea992d ("drm/i915/guc: WA to address the Ringbuffer
coherency issue") demonstrate that writes through the GTT are indeed
delayed and may be overtaken by direct WC access. To be safe, if
userspace is mixing WC mmaps with other potential GTT access (pwrite,
GTT mmaps) it should use set_domain(WC).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96563
Testcase: igt/gem_pwrite/small-gtt*
Testcase: igt/drv_selftest/coherency
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h|  5 +-
 drivers/gpu/drm/i915/i915_gem.c| 77 --
 drivers/gpu/drm/i915/intel_guc_log.c   |  6 +-
 .../gpu/drm/i915/selftests/i915_gem_coherency.c| 10 +--
 drivers/gpu/drm/i915/selftests/i915_gem_request.c  |  2 +-
 include/uapi/drm/i915_drm.h|  2 +
 6 files changed, 86 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c9b0949f6c1a..37d2dc7308e7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3447,8 +3447,9 @@ int i915_gem_object_wait_priority(struct 
drm_i915_gem_object *obj,
 #define I915_PRIORITY_DISPLAY I915_PRIORITY_MAX
 
 int __must_check
-i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj,
- bool write);
+i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object *obj, bool write);
+int __must_check
+i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write);
 int __must_check
 i915_gem_object_set_to_cpu_domain(struct drm_i915_gem_object *obj, bool write);
 struct i915_vma * __must_check
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4ca88f2539c0..497c669d0096 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1591,10 +1591,12 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void 
*data,
if (err)
goto out_unpin;
 
-   if (read_domains & I915_GEM_DOMAIN_GTT)
-   err = i915_gem_object_set_to_gtt_domain(obj, write_domain != 0);
+   if (read_domains & I915_GEM_DOMAIN_WC)
+   err = i915_gem_object_set_to_wc_domain(obj, write_domain);
+   else if (read_domains & I915_GEM_DOMAIN_GTT)
+   err = i915_gem_object_set_to_gtt_domain(obj, write_domain);
else
-   err = i915_gem_object_set_to_cpu_domain(obj, write_domain != 0);
+   err = i915_gem_object_set_to_cpu_domain(obj, write_domain);
 
/* And bump the LRU for this access */
i915_gem_object_bump_inactive_ggtt(obj);
@@ -1737,6 +1739,9 @@ static unsigned int tile_row_pages(struct 
drm_i915_gem_object *obj)
  * into userspace. (This view is aligned and sized appropriately for
  * fenced access.)
  *
+ * 2 - Recognise WC as a separate cache domain so that we can flush the
+ * delayed writes via GTT before performing direct access via WC.
+ *
  * Restrictions:
  *
  *  * snoopable objects cannot be accessed via the GTT. It can cause machine
@@ -1764,7 +1769,7 @@ static unsigned int tile_row_pages(struct 
drm_i915_gem_object *obj)
  */
 int i915_gem_mmap_gtt_version(void)
 {
-   return 1;
+   return 2;
 }
 
 static inline struct i915_ggtt_view
@@ -3390,6 +3395,70 @@ void i915_gem_object_flush_if_display(struct 
drm_i915_gem_object *obj)
 }
 
 /**
+ * Moves a single object to the WC read, and possibly write domain.
+ * @obj: object to act on
+ * @write: ask for write access or read only
+ *
+ * This function returns when the move is complete, including waiting on
+ * flushes to occur.
+ */
+int
+i915_gem_object_set_to_wc_domain(struct drm_i915_gem_object *obj, bool write)
+{
+   int ret;
+
+   lockdep_assert_held(>base.dev->struct_mutex);
+
+   ret = i915_gem_object_wait(obj,
+  I915_WAIT_INTERRUPTIBLE |
+  I915_WAIT_LOCKED |
+  (write ? I915_WAIT_ALL : 0),
+  MAX_SCHEDULE_TIMEOUT,
+  NULL);
+   if (ret)
+   return ret;
+
+   if (obj->base.write_domain == I915_GEM_DOMAIN_WC)
+   return 0;
+
+   /* Flush and acquire obj->pages so that we are coherent through
+* direct access in memory with previous cached writes through
+* shmemfs and that our cache domain tracking remains valid.
+* For example, if the obj->filp was moved to swap without us
+* being notified and releasing the pages, we would mistakenly
+* continue to assume that the obj remained out of the CPU cached
+* domain.
+*/
+   ret = 

[Intel-gfx] [maintainer-tools PATCH v2] dim: Add examples section to dim.rst

[Sean Paul]

Along with a recipe for creating a topic branch and sending a pull
request from it.

Signed-off-by: Sean Paul 
---

Changes in v2:
  - Address danvet's comments
- added paragraph about selecting a baseline
- s_origin/master_*baseline*_
- s/build test/test/
- add breadcrumb in drm-misc docs


 dim.rst  | 57 +
 drm-misc.rst |  3 ++-
 2 files changed, 59 insertions(+), 1 deletion(-)

diff --git a/dim.rst b/dim.rst
index b99248e..3dd19f9 100644
--- a/dim.rst
+++ b/dim.rst
@@ -472,6 +472,63 @@ listed using the **list-aliases** subcommand.
 
 The alias functionality requires **bash(1)** version 4.3 or later to work.
 
+EXAMPLES
+
+
+Cross-subsystem topic branches
+--
+So you want to send a pull request to another subsystem? Maintainers will 
likely
+get cranky if you ask them to pull a swath of unrelated drm patches, so we'll
+use a topic branch based upon Linus' tree with only the relevant patches.
+
+First select a suitable *baseline* for your topic branch. For topic
+branches shared within the gpu/drm subsystem, base it on the latest
+drm-next branch. For anything else, base it on the latest -rc tag from
+Upstream (not just any random position). In very rare cases you might need
+to apply topic branch pull requests from other maintainers before you can
+apply patches to construct a suitable baseline first.
+
+Next, create the topic branch using dim. Use whichever dim remote is most
+applicable, and name the branch in a manner that describes the set of patches
+you want pulled. The upstream will be Linus' tree.
+
+  $ dim create-branch *dim-remote*/topic/*topic-branch* *baseline*
+
+Once the branch is created, you can apply the patches to be pulled.
+
+  $ dim apply-branch topic/*topic-branch*
+
+Test your new topic branch and push it.
+
+  $ dim push-branch topic/*topic-branch*
+
+Ensure that your topic branch was merged into drm-tip. The drm-tip tree is
+located in $DIM_PREFIX/drm-tip, test it to ensure the new topic branch
+didn't break anything.
+
+Once you're satisfied that nothing is broken, create the pull request.
+
+  $ dim pull-request topic/*topic-branch* *baseline*
+
+You'll be prompted to enter a tag description and your mail user agent will 
open
+with the pull request email. Change names and emails as appropriate to reflect
+who the sender and recipient of the pull is, and send it.
+
+Once the pull has been acked by your maintainer counterpart, you can pull it
+into the appropriate local dim branch.
+
+  $ dim apply-pull *dim-branch*
+
+Perform a final test, and push *dim-branch* to *dim-remote*.
+
+  $ dim push-branch *dim-branch*
+
+You can now remove the topic branch, as it is no longer useful (you could 
remove
+it any time after the pull request, since it creates a tag, but this is as good
+a place as any).
+
+  $ dim remove-branch topic/*topic-branch*
+
 CONTRIBUTING
 
 
diff --git a/drm-misc.rst b/drm-misc.rst
index 8c6e4bf..45ea795 100644
--- a/drm-misc.rst
+++ b/drm-misc.rst
@@ -86,7 +86,8 @@ Right now the only hard merge criteria are:
 
 * Any non-linear actions (backmerges, merging topic branches and sending out
   pull requests) are only done by the official drm-misc maintainers (currently
-  Daniel, Jani and Sean, see MAINTAINERS), and not by committers.
+  Daniel, Jani and Sean, see MAINTAINERS), and not by committers. See the
+  `examples section in dim `_ for more info
 
 * All the x86, arm and arm64 DRM drivers need to still compile. To simplify 
this
   we track defconfigs for all three platforms in the `drm-intel-rerere` branch.
-- 
2.12.2.715.g7642488e1d-goog

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 00/15] acquire ctx wire-up, part 2

[Alex Deucher]

On Mon, Apr 3, 2017 at 4:32 AM, Daniel Vetter  wrote:
> Hi all,
>
> Partially this is a resend of the patches now unblocked by the vmwgfx atomic
> conversion just merged. I could entirely drop the vmwgfx patch since it's all
> fixed now.
>
> Then a bit of follow-up, plus converting the gamma_set/get ioctls. fbdev
> emulation and the property paths are still infested by drm_modeset_lock_all, 
> but
> I think at least for fbdev we now have a semi-clear path with Thierry's 
> series.
> Properties are still unclear to me, because it's a rather layered maze with 
> lots
> of different callsites.
>
> As always, comments and review highly welcome.

Patches 1-3, 5-8, 10-15:
Acked-by: Alex Deucher 

Patch 4:
typo in the commit message.  With that fixed:
Acked-by: Alex Deucher 


>
> Cheers, Daniel
>
> Daniel Vetter (15):
>   drm: Make drm_modeset_lock_crtc internal
>   drm: Remove drm_modeset_(un)lock_crtc
>   drm: Remove drm_modeset_legacy_acquire_ctx and crtc->acquire_ctx
>   drm/atomic-helper: remove modeset_lock_all from helper_resume
>   drm: drop modeset_lock_all from drm_state_info
>   drm: Drop modeset_lock_all from the getproperty ioctl
>   drm: Only take crtc lock in get_gamma ioctl
>   drm/i915: Nuke intel_atomic_legacy_gamma_set
>   drm/msm: Nerf zpos property
>   drm/fb-helper: Give up on kgdb for atomic drivers
>   drm: Add explicit acquire ctx handling around ->gamma_set
>   drm: Add acquire ctx to ->gamma_set hook
>   drm/atomic-helper: Remove legacy backoff hack from gamma_set
>   drm: extract legacy framebuffer remove
>   drm/fb-helper: Extract _legacy kms functions
>
>  drivers/gpu/drm/amd/amdgpu/dce_v10_0.c|   3 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v11_0.c|   3 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v6_0.c |   3 +-
>  drivers/gpu/drm/amd/amdgpu/dce_v8_0.c |   3 +-
>  drivers/gpu/drm/amd/amdgpu/dce_virtual.c  |   3 +-
>  drivers/gpu/drm/ast/ast_mode.c|   3 +-
>  drivers/gpu/drm/cirrus/cirrus_mode.c  |   3 +-
>  drivers/gpu/drm/drm_atomic.c  | 162 
> +++---
>  drivers/gpu/drm/drm_atomic_helper.c   |  35 +++
>  drivers/gpu/drm/drm_color_mgmt.c  |  51 +-
>  drivers/gpu/drm/drm_crtc_internal.h   |   1 -
>  drivers/gpu/drm/drm_fb_helper.c   |  81 +--
>  drivers/gpu/drm/drm_framebuffer.c | 137 +
>  drivers/gpu/drm/drm_modeset_lock.c| 102 ---
>  drivers/gpu/drm/drm_plane.c   |  49 +
>  drivers/gpu/drm/drm_property.c|  72 ++---
>  drivers/gpu/drm/gma500/gma_display.c  |   3 +-
>  drivers/gpu/drm/gma500/gma_display.h  |   3 +-
>  drivers/gpu/drm/i915/intel_display.c  |  60 +--
>  drivers/gpu/drm/i915/intel_pipe_crc.c |   2 +-
>  drivers/gpu/drm/mgag200/mgag200_mode.c|   3 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c |   2 -
>  drivers/gpu/drm/nouveau/dispnv04/crtc.c   |   3 +-
>  drivers/gpu/drm/nouveau/nv50_display.c|  13 +--
>  drivers/gpu/drm/radeon/radeon_display.c   |   3 +-
>  drivers/gpu/drm/vc4/vc4_crtc.c|   3 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |   3 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.h   |   3 +-
>  include/drm/drm_atomic_helper.h   |   3 +-
>  include/drm/drm_crtc.h|  12 +--
>  include/drm/drm_modeset_lock.h|   5 -
>  31 files changed, 344 insertions(+), 488 deletions(-)
>
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 04/15] drm/atomic-helper: remove modeset_lock_all from helper_resume

[Alex Deucher]

On Mon, Apr 3, 2017 at 4:32 AM, Daniel Vetter  wrote:
> Atomic code rely shouldn't rely on the magic hidden acquire context.

Repeated rely in commit message.  I'm assuming you mean:
"Atomic code shouldn't rely on the magic hidden acquire context."

>
> v2: Remove unused config local var (gcc).
>
> Signed-off-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 8999da789bb0..978dd8f49476 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2623,14 +2623,22 @@ 
> EXPORT_SYMBOL(drm_atomic_helper_commit_duplicated_state);
>  int drm_atomic_helper_resume(struct drm_device *dev,
>  struct drm_atomic_state *state)
>  {
> -   struct drm_mode_config *config = >mode_config;
> +   struct drm_modeset_acquire_ctx ctx;
> int err;
>
> drm_mode_config_reset(dev);
>
> -   drm_modeset_lock_all(dev);
> -   err = drm_atomic_helper_commit_duplicated_state(state, 
> config->acquire_ctx);
> -   drm_modeset_unlock_all(dev);
> +   drm_modeset_acquire_init(, 0);
> +   while (1) {
> +   err = drm_atomic_helper_commit_duplicated_state(state, );
> +   if (err != -EDEADLK)
> +   break;
> +
> +   drm_modeset_backoff();
> +   }
> +
> +   drm_modeset_drop_locks();
> +   drm_modeset_acquire_fini();
>
> return err;
>  }
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable OA unit for Gen 8 and 9 in i915 perf (rev5)

[Patchwork]

== Series Details ==

Series: Enable OA unit for Gen 8 and 9 in i915 perf (rev5)
URL   : https://patchwork.freedesktop.org/series/20084/
State : success

== Summary ==

Series 20084v5 Enable OA unit for Gen 8 and 9 in i915 perf
https://patchwork.freedesktop.org/api/1.0/series/20084/revisions/5/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 431s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 433s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time: 575s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 510s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 557s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time: 485s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 485s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 409s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 402s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 421s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 492s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 484s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 453s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 566s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 462s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 570s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 461s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 489s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 432s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 528s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 400s

39a0f48c8bc7c528cc705016dafa08a9dedfd36b drm-tip: 2017y-04m-05d-13h-22m-47s UTC 
integration manifest
03537e7 drm/i915/perf: Add 'render basic' Gen8+ OA unit configs
48f53b0 drm/i915: expose _SUBSLICE_MASK GETPARM
6b8b475 drm/i915: expose _SLICE_MASK GETPARM

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4414/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915/perf: per-gen timebase for checking sample freq

[Robert Bragg]

An oa_exponent_to_ns() utility and per-gen timebase constants where
recently removed when updating the tail pointer race condition WA, and
this restores those so we can update the _PROP_OA_EXPONENT validation
done in read_properties_unlocked() to not assume we have a 12.5MHz
timebase as we did for Haswell.

Accordingly the oa_sample_rate_hard_limit value that's referenced by
proc_dointvec_minmax defining the absolute limit for the OA sampling
frequency is now initialized to (timestamp_frequency / 2) instead of the
6.25MHz constant for Haswell.

v2:
Specify frequency of 19.2MHz for BXT (Ville)
Initialize oa_sample_rate_hard_limit per-gen too (Lionel)

Signed-off-by: Robert Bragg 
Cc: Lionel Landwerlin 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_perf.c | 31 ++-
 2 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3a22b6fd0ee6..48b07d706f06 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2463,6 +2463,7 @@ struct drm_i915_private {
 
bool periodic;
int period_exponent;
+   int timestamp_frequency;
 
int metrics_set;
 
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 98eb6415b63a..980b4a1fd7cc 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -288,10 +288,12 @@ static u32 i915_perf_stream_paranoid = true;
 
 /* For sysctl proc_dointvec_minmax of i915_oa_max_sample_rate
  *
- * 160ns is the smallest sampling period we can theoretically program the OA
- * unit with on Haswell, corresponding to 6.25MHz.
+ * The highest sampling frequency we can theoretically program the OA unit
+ * with is always half the timestamp frequency: E.g. 6.25Mhz for Haswell.
+ *
+ * Initialized just before we register the sysctl parameter.
  */
-static int oa_sample_rate_hard_limit = 625;
+static int oa_sample_rate_hard_limit;
 
 /* Theoretically we can program the OA unit to sample every 160ns but don't
  * allow that by default unless root...
@@ -2549,6 +2551,12 @@ i915_perf_open_ioctl_locked(struct drm_i915_private 
*dev_priv,
return ret;
 }
 
+static u64 oa_exponent_to_ns(struct drm_i915_private *dev_priv, int exponent)
+{
+   return div_u64(10ULL * (2ULL << exponent),
+  dev_priv->perf.oa.timestamp_frequency);
+}
+
 /**
  * read_properties_unlocked - validate + copy userspace stream open properties
  * @dev_priv: i915 device instance
@@ -2647,14 +2655,9 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,
/* Theoretically we can program the OA unit to sample
 * every 160ns but don't allow that by default unless
 * root.
-*
-* On Haswell the period is derived from the exponent
-* as:
-*
-*   period = 80ns * 2^(exponent + 1)
 */
BUILD_BUG_ON(sizeof(oa_period) != 8);
-   oa_period = 80ull * (2ull << value);
+   oa_period = oa_exponent_to_ns(dev_priv, value);
 
/* This check is primarily to ensure that oa_period <=
 * UINT32_MAX (before passing to do_div which only
@@ -2910,6 +2913,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.ops.oa_hw_tail_read =
gen7_oa_hw_tail_read;
 
+   dev_priv->perf.oa.timestamp_frequency = 1250;
+
dev_priv->perf.oa.oa_formats = hsw_oa_formats;
 
dev_priv->perf.oa.n_builtin_sets =
@@ -2923,6 +2928,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
 */
 
if (IS_GEN8(dev_priv)) {
+   dev_priv->perf.oa.timestamp_frequency = 1250;
+
dev_priv->perf.oa.ctx_oactxctrl_offset = 0x120;
dev_priv->perf.oa.ctx_flexeu0_offset = 0x2ce;
dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<25);
@@ -2939,6 +2946,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
i915_oa_select_metric_set_chv;
}
} else if (IS_GEN9(dev_priv)) {
+   dev_priv->perf.oa.timestamp_frequency = 1200;
+
dev_priv->perf.oa.ctx_oactxctrl_offset = 0x128;
dev_priv->perf.oa.ctx_flexeu0_offset = 0x3de;
dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<16);
@@ -2959,6 +2968,8 @@ void 

Re: [Intel-gfx] [PATCH v3 6/7] drm/i915/perf: per-gen timebase for checking sample freq

[Robert Bragg]

On Wed, Apr 5, 2017 at 6:26 PM, Ville Syrjälä  wrote:

> On Wed, Apr 05, 2017 at 06:17:36PM +0100, Lionel Landwerlin wrote:
> > On 05/04/17 18:06, Ville Syrjälä wrote:
> > > On Wed, Apr 05, 2017 at 05:23:19PM +0100, Robert Bragg wrote:
> > >> An oa_exponent_to_ns() utility and per-gen timebase constants where
> > >> recently removed when updating the tail pointer race condition WA, and
> > >> this restores those so we can update the _PROP_OA_EXPONENT validation
> > >> done in read_properties_unlocked() to not assume we have a 12.5KHz
> > >> timebase as we did for Haswell.
> > >>
> > >> Signed-off-by: Robert Bragg 
> > >> Cc: Lionel Landwerlin 
> > >> ---
> > >>   drivers/gpu/drm/i915/i915_drv.h  |  1 +
> > >>   drivers/gpu/drm/i915/i915_perf.c | 21 +++--
> > >>   2 files changed, 16 insertions(+), 6 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> > >> index 3a22b6fd0ee6..48b07d706f06 100644
> > >> --- a/drivers/gpu/drm/i915/i915_drv.h
> > >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> > >> @@ -2463,6 +2463,7 @@ struct drm_i915_private {
> > >>
> > >>bool periodic;
> > >>int period_exponent;
> > >> +  int timestamp_frequency;
> > >>
> > >>int metrics_set;
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> > >> index 98eb6415b63a..87c0d1ce1b9f 100644
> > >> --- a/drivers/gpu/drm/i915/i915_perf.c
> > >> +++ b/drivers/gpu/drm/i915/i915_perf.c
> > >> @@ -2549,6 +2549,12 @@ i915_perf_open_ioctl_locked(struct
> drm_i915_private *dev_priv,
> > >>return ret;
> > >>   }
> > >>
> > >> +static u64 oa_exponent_to_ns(struct drm_i915_private *dev_priv, int
> exponent)
> > >> +{
> > >> +   return div_u64(10ULL * (2ULL << exponent),
> > >> +  dev_priv->perf.oa.timestamp_frequency);
> > >> +}
> > >> +
> > >>   /**
> > >>* read_properties_unlocked - validate + copy userspace stream open
> properties
> > >>* @dev_priv: i915 device instance
> > >> @@ -2647,14 +2653,9 @@ static int read_properties_unlocked(struct
> drm_i915_private *dev_priv,
> > >>/* Theoretically we can program the OA unit to
> sample
> > >> * every 160ns but don't allow that by default
> unless
> > >> * root.
> > >> -   *
> > >> -   * On Haswell the period is derived from the
> exponent
> > >> -   * as:
> > >> -   *
> > >> -   *   period = 80ns * 2^(exponent + 1)
> > >> */
> > >>BUILD_BUG_ON(sizeof(oa_period) != 8);
> > >> -  oa_period = 80ull * (2ull << value);
> > >> +  oa_period = oa_exponent_to_ns(dev_priv, value);
> > >>
> > >>/* This check is primarily to ensure that
> oa_period <=
> > >> * UINT32_MAX (before passing to do_div which only
> > >> @@ -2910,6 +2911,8 @@ void i915_perf_init(struct drm_i915_private
> *dev_priv)
> > >>dev_priv->perf.oa.ops.oa_hw_tail_read =
> > >>gen7_oa_hw_tail_read;
> > >>
> > >> +  dev_priv->perf.oa.timestamp_frequency = 1250;
> > >> +
> > >>dev_priv->perf.oa.oa_formats = hsw_oa_formats;
> > >>
> > >>dev_priv->perf.oa.n_builtin_sets =
> > >> @@ -2923,6 +2926,8 @@ void i915_perf_init(struct drm_i915_private
> *dev_priv)
> > >> */
> > >>
> > >>if (IS_GEN8(dev_priv)) {
> > >> +  dev_priv->perf.oa.timestamp_frequency = 1250;
> > >> +
> > >>dev_priv->perf.oa.ctx_oactxctrl_offset = 0x120;
> > >>dev_priv->perf.oa.ctx_flexeu0_offset = 0x2ce;
> > >>dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<25);
> > >> @@ -2939,6 +2944,8 @@ void i915_perf_init(struct drm_i915_private
> *dev_priv)
> > >>i915_oa_select_metric_set_chv;
> > >>}
> > >>} else if (IS_GEN9(dev_priv)) {
> > >> +  dev_priv->perf.oa.timestamp_frequency = 1200;
> > >> +
> > >>dev_priv->perf.oa.ctx_oactxctrl_offset = 0x128;
> > >>dev_priv->perf.oa.ctx_flexeu0_offset = 0x3de;
> > >>dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<16);
> > >> @@ -2959,6 +2966,8 @@ void i915_perf_init(struct drm_i915_private
> *dev_priv)
> > >>dev_priv->perf.oa.ops.select_metric_set =
> > >>i915_oa_select_metric_set_sklgt4;
> > >>} else if (IS_BROXTON(dev_priv)) {
> > >> +  dev_priv->perf.oa.timestamp_frequency =
> 19200123;
> > >> +
> > > Why isn't this exactly 19.2MHz?
> >
> > It's based off the timestamp 

Re: [Intel-gfx] [PATCH v3 6/7] drm/i915/perf: per-gen timebase for checking sample freq

[Ville Syrjälä]

On Wed, Apr 05, 2017 at 06:17:36PM +0100, Lionel Landwerlin wrote:
> On 05/04/17 18:06, Ville Syrjälä wrote:
> > On Wed, Apr 05, 2017 at 05:23:19PM +0100, Robert Bragg wrote:
> >> An oa_exponent_to_ns() utility and per-gen timebase constants where
> >> recently removed when updating the tail pointer race condition WA, and
> >> this restores those so we can update the _PROP_OA_EXPONENT validation
> >> done in read_properties_unlocked() to not assume we have a 12.5KHz
> >> timebase as we did for Haswell.
> >>
> >> Signed-off-by: Robert Bragg 
> >> Cc: Lionel Landwerlin 
> >> ---
> >>   drivers/gpu/drm/i915/i915_drv.h  |  1 +
> >>   drivers/gpu/drm/i915/i915_perf.c | 21 +++--
> >>   2 files changed, 16 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index 3a22b6fd0ee6..48b07d706f06 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -2463,6 +2463,7 @@ struct drm_i915_private {
> >>   
> >>bool periodic;
> >>int period_exponent;
> >> +  int timestamp_frequency;
> >>   
> >>int metrics_set;
> >>   
> >> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> >> b/drivers/gpu/drm/i915/i915_perf.c
> >> index 98eb6415b63a..87c0d1ce1b9f 100644
> >> --- a/drivers/gpu/drm/i915/i915_perf.c
> >> +++ b/drivers/gpu/drm/i915/i915_perf.c
> >> @@ -2549,6 +2549,12 @@ i915_perf_open_ioctl_locked(struct drm_i915_private 
> >> *dev_priv,
> >>return ret;
> >>   }
> >>   
> >> +static u64 oa_exponent_to_ns(struct drm_i915_private *dev_priv, int 
> >> exponent)
> >> +{
> >> +   return div_u64(10ULL * (2ULL << exponent),
> >> +  dev_priv->perf.oa.timestamp_frequency);
> >> +}
> >> +
> >>   /**
> >>* read_properties_unlocked - validate + copy userspace stream open 
> >> properties
> >>* @dev_priv: i915 device instance
> >> @@ -2647,14 +2653,9 @@ static int read_properties_unlocked(struct 
> >> drm_i915_private *dev_priv,
> >>/* Theoretically we can program the OA unit to sample
> >> * every 160ns but don't allow that by default unless
> >> * root.
> >> -   *
> >> -   * On Haswell the period is derived from the exponent
> >> -   * as:
> >> -   *
> >> -   *   period = 80ns * 2^(exponent + 1)
> >> */
> >>BUILD_BUG_ON(sizeof(oa_period) != 8);
> >> -  oa_period = 80ull * (2ull << value);
> >> +  oa_period = oa_exponent_to_ns(dev_priv, value);
> >>   
> >>/* This check is primarily to ensure that oa_period <=
> >> * UINT32_MAX (before passing to do_div which only
> >> @@ -2910,6 +2911,8 @@ void i915_perf_init(struct drm_i915_private 
> >> *dev_priv)
> >>dev_priv->perf.oa.ops.oa_hw_tail_read =
> >>gen7_oa_hw_tail_read;
> >>   
> >> +  dev_priv->perf.oa.timestamp_frequency = 1250;
> >> +
> >>dev_priv->perf.oa.oa_formats = hsw_oa_formats;
> >>   
> >>dev_priv->perf.oa.n_builtin_sets =
> >> @@ -2923,6 +2926,8 @@ void i915_perf_init(struct drm_i915_private 
> >> *dev_priv)
> >> */
> >>   
> >>if (IS_GEN8(dev_priv)) {
> >> +  dev_priv->perf.oa.timestamp_frequency = 1250;
> >> +
> >>dev_priv->perf.oa.ctx_oactxctrl_offset = 0x120;
> >>dev_priv->perf.oa.ctx_flexeu0_offset = 0x2ce;
> >>dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<25);
> >> @@ -2939,6 +2944,8 @@ void i915_perf_init(struct drm_i915_private 
> >> *dev_priv)
> >>i915_oa_select_metric_set_chv;
> >>}
> >>} else if (IS_GEN9(dev_priv)) {
> >> +  dev_priv->perf.oa.timestamp_frequency = 1200;
> >> +
> >>dev_priv->perf.oa.ctx_oactxctrl_offset = 0x128;
> >>dev_priv->perf.oa.ctx_flexeu0_offset = 0x3de;
> >>dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<16);
> >> @@ -2959,6 +2966,8 @@ void i915_perf_init(struct drm_i915_private 
> >> *dev_priv)
> >>dev_priv->perf.oa.ops.select_metric_set =
> >>i915_oa_select_metric_set_sklgt4;
> >>} else if (IS_BROXTON(dev_priv)) {
> >> +  dev_priv->perf.oa.timestamp_frequency = 
> >> 19200123;
> >> +
> > Why isn't this exactly 19.2MHz?
> 
> It's based off the timestamp base (from documentation) :
> 
> BDW: 80ns
> SKL: 83.333ns
> BXT: 52.083ns
> 
> 10 / 19200123 is the closest we can get.

I'm pretty sure the clock is actually 19.2 and the 52.083 is just a
truncated value. Same 

Re: [Intel-gfx] [PATCH v3 6/7] drm/i915/perf: per-gen timebase for checking sample freq

[Lionel Landwerlin]

On 05/04/17 18:06, Ville Syrjälä wrote:

On Wed, Apr 05, 2017 at 05:23:19PM +0100, Robert Bragg wrote:

An oa_exponent_to_ns() utility and per-gen timebase constants where
recently removed when updating the tail pointer race condition WA, and
this restores those so we can update the _PROP_OA_EXPONENT validation
done in read_properties_unlocked() to not assume we have a 12.5KHz
timebase as we did for Haswell.

Signed-off-by: Robert Bragg 
Cc: Lionel Landwerlin 
---
  drivers/gpu/drm/i915/i915_drv.h  |  1 +
  drivers/gpu/drm/i915/i915_perf.c | 21 +++--
  2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3a22b6fd0ee6..48b07d706f06 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2463,6 +2463,7 @@ struct drm_i915_private {
  
  			bool periodic;

int period_exponent;
+   int timestamp_frequency;
  
  			int metrics_set;
  
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c

index 98eb6415b63a..87c0d1ce1b9f 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2549,6 +2549,12 @@ i915_perf_open_ioctl_locked(struct drm_i915_private 
*dev_priv,
return ret;
  }
  
+static u64 oa_exponent_to_ns(struct drm_i915_private *dev_priv, int exponent)

+{
+   return div_u64(10ULL * (2ULL << exponent),
+  dev_priv->perf.oa.timestamp_frequency);
+}
+
  /**
   * read_properties_unlocked - validate + copy userspace stream open properties
   * @dev_priv: i915 device instance
@@ -2647,14 +2653,9 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,
/* Theoretically we can program the OA unit to sample
 * every 160ns but don't allow that by default unless
 * root.
-*
-* On Haswell the period is derived from the exponent
-* as:
-*
-*   period = 80ns * 2^(exponent + 1)
 */
BUILD_BUG_ON(sizeof(oa_period) != 8);
-   oa_period = 80ull * (2ull << value);
+   oa_period = oa_exponent_to_ns(dev_priv, value);
  
  			/* This check is primarily to ensure that oa_period <=

 * UINT32_MAX (before passing to do_div which only
@@ -2910,6 +2911,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.ops.oa_hw_tail_read =
gen7_oa_hw_tail_read;
  
+		dev_priv->perf.oa.timestamp_frequency = 1250;

+
dev_priv->perf.oa.oa_formats = hsw_oa_formats;
  
  		dev_priv->perf.oa.n_builtin_sets =

@@ -2923,6 +2926,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
 */
  
  		if (IS_GEN8(dev_priv)) {

+   dev_priv->perf.oa.timestamp_frequency = 1250;
+
dev_priv->perf.oa.ctx_oactxctrl_offset = 0x120;
dev_priv->perf.oa.ctx_flexeu0_offset = 0x2ce;
dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<25);
@@ -2939,6 +2944,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
i915_oa_select_metric_set_chv;
}
} else if (IS_GEN9(dev_priv)) {
+   dev_priv->perf.oa.timestamp_frequency = 1200;
+
dev_priv->perf.oa.ctx_oactxctrl_offset = 0x128;
dev_priv->perf.oa.ctx_flexeu0_offset = 0x3de;
dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<16);
@@ -2959,6 +2966,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.ops.select_metric_set =
i915_oa_select_metric_set_sklgt4;
} else if (IS_BROXTON(dev_priv)) {
+   dev_priv->perf.oa.timestamp_frequency = 
19200123;
+

Why isn't this exactly 19.2MHz?


It's based off the timestamp base (from documentation) :

BDW: 80ns
SKL: 83.333ns
BXT: 52.083ns

10 / 19200123 is the closest we can get.




dev_priv->perf.oa.n_builtin_sets =
i915_oa_n_builtin_metric_sets_bxt;
dev_priv->perf.oa.ops.select_metric_set =
--
2.12.0

___
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 v3 6/7] drm/i915/perf: per-gen timebase for checking sample freq

[Ville Syrjälä]

On Wed, Apr 05, 2017 at 05:23:19PM +0100, Robert Bragg wrote:
> An oa_exponent_to_ns() utility and per-gen timebase constants where
> recently removed when updating the tail pointer race condition WA, and
> this restores those so we can update the _PROP_OA_EXPONENT validation
> done in read_properties_unlocked() to not assume we have a 12.5KHz
> timebase as we did for Haswell.
> 
> Signed-off-by: Robert Bragg 
> Cc: Lionel Landwerlin 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  1 +
>  drivers/gpu/drm/i915/i915_perf.c | 21 +++--
>  2 files changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3a22b6fd0ee6..48b07d706f06 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2463,6 +2463,7 @@ struct drm_i915_private {
>  
>   bool periodic;
>   int period_exponent;
> + int timestamp_frequency;
>  
>   int metrics_set;
>  
> diff --git a/drivers/gpu/drm/i915/i915_perf.c 
> b/drivers/gpu/drm/i915/i915_perf.c
> index 98eb6415b63a..87c0d1ce1b9f 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -2549,6 +2549,12 @@ i915_perf_open_ioctl_locked(struct drm_i915_private 
> *dev_priv,
>   return ret;
>  }
>  
> +static u64 oa_exponent_to_ns(struct drm_i915_private *dev_priv, int exponent)
> +{
> +   return div_u64(10ULL * (2ULL << exponent),
> +  dev_priv->perf.oa.timestamp_frequency);
> +}
> +
>  /**
>   * read_properties_unlocked - validate + copy userspace stream open 
> properties
>   * @dev_priv: i915 device instance
> @@ -2647,14 +2653,9 @@ static int read_properties_unlocked(struct 
> drm_i915_private *dev_priv,
>   /* Theoretically we can program the OA unit to sample
>* every 160ns but don't allow that by default unless
>* root.
> -  *
> -  * On Haswell the period is derived from the exponent
> -  * as:
> -  *
> -  *   period = 80ns * 2^(exponent + 1)
>*/
>   BUILD_BUG_ON(sizeof(oa_period) != 8);
> - oa_period = 80ull * (2ull << value);
> + oa_period = oa_exponent_to_ns(dev_priv, value);
>  
>   /* This check is primarily to ensure that oa_period <=
>* UINT32_MAX (before passing to do_div which only
> @@ -2910,6 +2911,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
>   dev_priv->perf.oa.ops.oa_hw_tail_read =
>   gen7_oa_hw_tail_read;
>  
> + dev_priv->perf.oa.timestamp_frequency = 1250;
> +
>   dev_priv->perf.oa.oa_formats = hsw_oa_formats;
>  
>   dev_priv->perf.oa.n_builtin_sets =
> @@ -2923,6 +2926,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
>*/
>  
>   if (IS_GEN8(dev_priv)) {
> + dev_priv->perf.oa.timestamp_frequency = 1250;
> +
>   dev_priv->perf.oa.ctx_oactxctrl_offset = 0x120;
>   dev_priv->perf.oa.ctx_flexeu0_offset = 0x2ce;
>   dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<25);
> @@ -2939,6 +2944,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
>   i915_oa_select_metric_set_chv;
>   }
>   } else if (IS_GEN9(dev_priv)) {
> + dev_priv->perf.oa.timestamp_frequency = 1200;
> +
>   dev_priv->perf.oa.ctx_oactxctrl_offset = 0x128;
>   dev_priv->perf.oa.ctx_flexeu0_offset = 0x3de;
>   dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<16);
> @@ -2959,6 +2966,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
>   dev_priv->perf.oa.ops.select_metric_set =
>   i915_oa_select_metric_set_sklgt4;
>   } else if (IS_BROXTON(dev_priv)) {
> + dev_priv->perf.oa.timestamp_frequency = 
> 19200123;
> +

Why isn't this exactly 19.2MHz?

>   dev_priv->perf.oa.n_builtin_sets =
>   i915_oa_n_builtin_metric_sets_bxt;
>   dev_priv->perf.oa.ops.select_metric_set =
> -- 
> 2.12.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org

[Intel-gfx] ✓ Fi.CI.BAT: success for Classify the engines in class + instance

[Patchwork]

== Series Details ==

Series: Classify the engines in class + instance
URL   : https://patchwork.freedesktop.org/series/22535/
State : success

== Summary ==

Series 22535v1 Classify the engines in class + instance
https://patchwork.freedesktop.org/api/1.0/series/22535/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 432s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 425s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time: 574s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 543s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time: 479s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 484s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 412s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 406s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 422s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 488s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 465s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 455s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 575s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 450s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 573s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 459s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 491s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 436s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 529s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 411s
fi-bxt-j4205 failed to collect. IGT log at Patchwork_4413/fi-bxt-j4205/igt.log

39a0f48c8bc7c528cc705016dafa08a9dedfd36b drm-tip: 2017y-04m-05d-13h-22m-47s UTC 
integration manifest
c328081 drm/i915: Use the engine class to get the context size
dab2e3f drm/i915: Split the engine info table in two levels, using class + 
instance
f3c78f4 drm/i915: Generate the engine name based on the instance number
14f39bb drm/i915: Use the same vfunc for BSD2 ring init
50e8315 drm/i915: Classify the engines in class + instance

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4413/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 6/7] drm/i915/perf: per-gen timebase for checking sample freq

[Lionel Landwerlin]

Hey Rob,

Thanks for sending this, it looks good to me.
I think we also need to update the oa_sample_rate_hard_limit & 
i915_oa_max_sample_rate variables.


This patch is :

Reviewed-by: Lionel Landwerlin 


On 05/04/17 17:23, Robert Bragg wrote:

An oa_exponent_to_ns() utility and per-gen timebase constants where
recently removed when updating the tail pointer race condition WA, and
this restores those so we can update the _PROP_OA_EXPONENT validation
done in read_properties_unlocked() to not assume we have a 12.5KHz
timebase as we did for Haswell.

Signed-off-by: Robert Bragg 
Cc: Lionel Landwerlin 
---
  drivers/gpu/drm/i915/i915_drv.h  |  1 +
  drivers/gpu/drm/i915/i915_perf.c | 21 +++--
  2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3a22b6fd0ee6..48b07d706f06 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2463,6 +2463,7 @@ struct drm_i915_private {
  
  			bool periodic;

int period_exponent;
+   int timestamp_frequency;
  
  			int metrics_set;
  
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c

index 98eb6415b63a..87c0d1ce1b9f 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2549,6 +2549,12 @@ i915_perf_open_ioctl_locked(struct drm_i915_private 
*dev_priv,
return ret;
  }
  
+static u64 oa_exponent_to_ns(struct drm_i915_private *dev_priv, int exponent)

+{
+   return div_u64(10ULL * (2ULL << exponent),
+  dev_priv->perf.oa.timestamp_frequency);
+}
+
  /**
   * read_properties_unlocked - validate + copy userspace stream open properties
   * @dev_priv: i915 device instance
@@ -2647,14 +2653,9 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,
/* Theoretically we can program the OA unit to sample
 * every 160ns but don't allow that by default unless
 * root.
-*
-* On Haswell the period is derived from the exponent
-* as:
-*
-*   period = 80ns * 2^(exponent + 1)
 */
BUILD_BUG_ON(sizeof(oa_period) != 8);
-   oa_period = 80ull * (2ull << value);
+   oa_period = oa_exponent_to_ns(dev_priv, value);
  
  			/* This check is primarily to ensure that oa_period <=

 * UINT32_MAX (before passing to do_div which only
@@ -2910,6 +2911,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.ops.oa_hw_tail_read =
gen7_oa_hw_tail_read;
  
+		dev_priv->perf.oa.timestamp_frequency = 1250;

+
dev_priv->perf.oa.oa_formats = hsw_oa_formats;
  
  		dev_priv->perf.oa.n_builtin_sets =

@@ -2923,6 +2926,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
 */
  
  		if (IS_GEN8(dev_priv)) {

+   dev_priv->perf.oa.timestamp_frequency = 1250;
+
dev_priv->perf.oa.ctx_oactxctrl_offset = 0x120;
dev_priv->perf.oa.ctx_flexeu0_offset = 0x2ce;
dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<25);
@@ -2939,6 +2944,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
i915_oa_select_metric_set_chv;
}
} else if (IS_GEN9(dev_priv)) {
+   dev_priv->perf.oa.timestamp_frequency = 1200;
+
dev_priv->perf.oa.ctx_oactxctrl_offset = 0x128;
dev_priv->perf.oa.ctx_flexeu0_offset = 0x3de;
dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<16);
@@ -2959,6 +2966,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.ops.select_metric_set =
i915_oa_select_metric_set_sklgt4;
} else if (IS_BROXTON(dev_priv)) {
+   dev_priv->perf.oa.timestamp_frequency = 
19200123;
+
dev_priv->perf.oa.n_builtin_sets =
i915_oa_n_builtin_metric_sets_bxt;
dev_priv->perf.oa.ops.select_metric_set =



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v3] benchmarks/gem_wsim: Command submission workload simulator

[Chris Wilson]

On Wed, Apr 05, 2017 at 05:14:01PM +0100, Tvrtko Ursulin wrote:
> +static void
> +__emit_bb_end(struct w_step *w, bool terminate, bool seqnos, uint32_t seqno)
> +{
> + const uint32_t bbe = 0xa << 23;
> + unsigned long bb_sz = get_bb_sz(>duration);
> + unsigned long mmap_start, cmd_offset, mmap_len;
> + uint32_t *ptr, *cs;
> +
> + mmap_len = (seqnos ? 5 : 1) * sizeof(uint32_t);
> + cmd_offset = bb_sz - mmap_len;
> + mmap_start = rounddown(cmd_offset, PAGE_SIZE);
> + mmap_len += cmd_offset - mmap_start;
> +
> + gem_set_domain(fd, w->bb_handle,
> +I915_GEM_DOMAIN_CPU, I915_GEM_DOMAIN_CPU);
> +
> + ptr = gem_mmap__cpu(fd, w->bb_handle, mmap_start, mmap_len, PROT_WRITE);
> + cs = (uint32_t *)((char *)ptr + cmd_offset - mmap_start);
> +
> + if (seqnos) {
> + const int gen = intel_gen(intel_get_drm_devid(fd));
> +
> + igt_assert(gen >= 8);
> +
> + w->reloc.offset = bb_sz - 4 * sizeof(uint32_t);
> + w->seqno_offset = bb_sz - 2 * sizeof(uint32_t);
> +
> + *cs++ = terminate ? MI_STORE_DWORD_IMM : 0;
> + *cs++ = 0;
> + *cs++ = 0;
> + *cs++ = seqno;
> + }
> +
> + *cs = terminate ? bbe : 0;
> +
> + munmap(ptr, mmap_len);
> +}
> +
> +static void terminate_bb(struct w_step *w, bool seqnos, uint32_t seqno)
> +{
> + __emit_bb_end(w, true, seqnos, seqno);
> +}
> +
> +static void unterminate_bb(struct w_step *w, bool seqnos)
> +{
> + __emit_bb_end(w, false, seqnos, 0);
> +}
> +
> +static void
> +prepare_workload(struct workload *wrk, bool swap_vcs, bool seqnos)
> +{
> + int max_ctx = -1;
> + struct w_step *w;
> + int i;
> +
> + if (seqnos) {
> + const unsigned int status_sz = sizeof(uint32_t);
> +
> + for (i = 0; i < NUM_ENGINES; i++) {
> + wrk->status_page_handle[i] = gem_create(fd, status_sz);

Need to set_cache_level(CACHED) for llc.

You can use one page for all engines. Just use a different cacheline
for each, for safety.

> + wrk->status_page[i] =
> + gem_mmap__cpu(fd, wrk->status_page_handle[i],
> +   0, status_sz, PROT_READ);
> + }
> + }
> +
> + for (i = 0, w = wrk->steps; i < wrk->nr_steps; i++, w++) {
> + if ((int)w->context > max_ctx) {
> + int delta = w->context + 1 - wrk->nr_ctxs;
> +
> + wrk->nr_ctxs += delta;
> + wrk->ctx_id = realloc(wrk->ctx_id,
> +   wrk->nr_ctxs * sizeof(uint32_t));
> + memset(>ctx_id[wrk->nr_ctxs - delta], 0,
> +delta * sizeof(uint32_t));
> +
> + max_ctx = w->context;
> + }
> +
> + if (!wrk->ctx_id[w->context]) {
> + struct drm_i915_gem_context_create arg = {};
> +
> + drmIoctl(fd, DRM_IOCTL_I915_GEM_CONTEXT_CREATE, );
> + igt_assert(arg.ctx_id);
> +
> + wrk->ctx_id[w->context] = arg.ctx_id;
> + }
> + }
> +
> + for (i = 0, w = wrk->steps; i < wrk->nr_steps; i++, w++) {
> + enum intel_engine_id engine = w->engine;
> + unsigned int bb_i, j = 0;
> +
> + if (w->type != BATCH)
> + continue;
> +
> + w->obj[j].handle = gem_create(fd, 4096);
> + w->obj[j].flags = EXEC_OBJECT_WRITE;
> + j++;
> +
> + if (seqnos) {
> + w->obj[j].handle = wrk->status_page_handle[engine];
> + w->obj[j].flags = EXEC_OBJECT_WRITE;

The trick for sharing between engines is to not mark this as a WRITE.
Fun little lies.

> + j++;
> + }
> +
> + bb_i = j++;
> + w->duration.cur = w->duration.max;
> + w->bb_sz = get_bb_sz(>duration);
> + w->bb_handle = w->obj[bb_i].handle = gem_create(fd, w->bb_sz);
> + terminate_bb(w, seqnos, 0);
> + if (seqnos) {
> + w->reloc.presumed_offset = -1;
> + w->reloc.target_handle = 1;
> + w->reloc.read_domains = I915_GEM_DOMAIN_INSTRUCTION;
> + w->reloc.write_domain = I915_GEM_DOMAIN_INSTRUCTION;

Ugh. That's a magic w/a value for pipecontrols. Fortunately we don't want
to set write_domain here anyway.

> + }
> +
> + igt_assert(w->dependency <= 0);
> + if (w->dependency) {
> + int dep_idx = i + w->dependency;
> +
> + igt_assert(dep_idx >= 0 && dep_idx < wrk->nr_steps);
> + igt_assert(wrk->steps[dep_idx].type == BATCH);
> +
> + w->obj[j].handle = w->obj[bb_i].handle;
> + bb_i = j;
> +

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable OA unit for Gen 8 and 9 in i915 perf (rev4)

[Patchwork]

== Series Details ==

Series: Enable OA unit for Gen 8 and 9 in i915 perf (rev4)
URL   : https://patchwork.freedesktop.org/series/20084/
State : success

== Summary ==

Series 20084v4 Enable OA unit for Gen 8 and 9 in i915 perf
https://patchwork.freedesktop.org/api/1.0/series/20084/revisions/4/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 427s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 423s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time: 575s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 510s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 550s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time: 481s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 486s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 407s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 403s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 417s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 492s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 469s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 463s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 564s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 450s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 569s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 461s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 489s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 438s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 522s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 401s

39a0f48c8bc7c528cc705016dafa08a9dedfd36b drm-tip: 2017y-04m-05d-13h-22m-47s UTC 
integration manifest
922f6e8 drm/i915/perf: Add 'render basic' Gen8+ OA unit configs
e167dac drm/i915: expose _SUBSLICE_MASK GETPARM
edcd041 drm/i915: expose _SLICE_MASK GETPARM

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4412/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Suspend GuC prior to GPU Reset during GEM suspend

[Daniele Ceraolo Spurio]

On 05/04/17 05:24, Chris Wilson wrote:

On Wed, Apr 05, 2017 at 03:51:50PM +0530, Sagar Arun Kamble wrote:

i915 is currently doing Full GPU reset at the end of suspend followed by
GuC suspend. This reset bypasses the GuC. We need to tell the GuC to
suspend before we do a direct intel_gpu_reset, Otherwise the gpu state will
no longer match the GuC's expectations and its suspend will not be
successful. With this change, i915 suspends GuC after suspending GEM and


Here I would say here that GuC suspend fails because we're resetting GuC 
as part of the GPU reset and not because the expectation doesn't match.



before doing Full GPU reset.


I'll massage the commit message slightly (much easier when proofreading
someone else's writing). It makes sense to me, any takers from those who
know guc more intimately or at least have observed and tested this patch?
-Chris



Change looks good to me:
Reviewed-by: Daniele Ceraolo Spurio 

On a related note, we only allocate the pages for saving the GuC state 
if i915.enable_guc_submission=1 (they're part of the ADS), but from what 
I can see we call intel_guc_suspend/resume unconditionally.
Since the ADS are not designed to be submission-only structs I think we 
should move the ADS allocation to always happen when the GuC is loaded 
without looking at i915.enable_guc_submission.


Daniele
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/5] drm/i915: Split the engine info table in two levels, using class + instance

[Oscar Mateo]

Cc: Tvrtko Ursulin 
Cc: Paulo Zanoni 
Cc: Rodrigo Vivi 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_engine_cs.c | 72 +-
 1 file changed, 44 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 530f822..691689c 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -26,71 +26,83 @@
 #include "intel_ringbuffer.h"
 #include "intel_lrc.h"
 
-static const struct engine_info {
+struct engine_class_info {
const char *name;
unsigned int exec_id;
+   int (*init_legacy)(struct intel_engine_cs *engine);
+   int (*init_execlists)(struct intel_engine_cs *engine);
+};
+
+static const struct engine_class_info intel_engine_classes[] = {
+   [RENDER_CLASS] = {
+   .name = "rcs",
+   .exec_id = I915_EXEC_RENDER,
+   .init_execlists = logical_render_ring_init,
+   .init_legacy = intel_init_render_ring_buffer,
+   },
+   [COPY_ENGINE_CLASS] = {
+   .name = "bcs",
+   .exec_id = I915_EXEC_BLT,
+   .init_execlists = logical_xcs_ring_init,
+   .init_legacy = intel_init_blt_ring_buffer,
+   },
+   [VIDEO_DECODE_CLASS] = {
+   .name = "vcs",
+   .exec_id = I915_EXEC_BSD,
+   .init_execlists = logical_xcs_ring_init,
+   .init_legacy = intel_init_bsd_ring_buffer,
+   },
+   [VIDEO_ENHANCEMENT_CLASS] = {
+   .name = "vecs",
+   .exec_id = I915_EXEC_VEBOX,
+   .init_execlists = logical_xcs_ring_init,
+   .init_legacy = intel_init_vebox_ring_buffer,
+   },
+};
+
+struct engine_info {
unsigned int hw_id;
enum intel_engine_class class;
u32 instance;
u32 mmio_base;
unsigned irq_shift;
-   int (*init_legacy)(struct intel_engine_cs *engine);
-   int (*init_execlists)(struct intel_engine_cs *engine);
-} intel_engines[] = {
+};
+
+static const struct engine_info intel_engines[] = {
[RCS] = {
-   .name = "rcs",
.hw_id = RCS_HW,
-   .exec_id = I915_EXEC_RENDER,
.class = RENDER_CLASS,
.instance = 0,
.mmio_base = RENDER_RING_BASE,
.irq_shift = GEN8_RCS_IRQ_SHIFT,
-   .init_execlists = logical_render_ring_init,
-   .init_legacy = intel_init_render_ring_buffer,
},
[BCS] = {
-   .name = "bcs",
.hw_id = BCS_HW,
-   .exec_id = I915_EXEC_BLT,
.class = COPY_ENGINE_CLASS,
.instance = 0,
.mmio_base = BLT_RING_BASE,
.irq_shift = GEN8_BCS_IRQ_SHIFT,
-   .init_execlists = logical_xcs_ring_init,
-   .init_legacy = intel_init_blt_ring_buffer,
},
[VCS] = {
-   .name = "vcs",
.hw_id = VCS_HW,
-   .exec_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 0,
.mmio_base = GEN6_BSD_RING_BASE,
.irq_shift = GEN8_VCS1_IRQ_SHIFT,
-   .init_execlists = logical_xcs_ring_init,
-   .init_legacy = intel_init_bsd_ring_buffer,
},
[VCS2] = {
-   .name = "vcs",
.hw_id = VCS2_HW,
-   .exec_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
.instance = 1,
.mmio_base = GEN8_BSD2_RING_BASE,
.irq_shift = GEN8_VCS2_IRQ_SHIFT,
-   .init_execlists = logical_xcs_ring_init,
-   .init_legacy = intel_init_bsd_ring_buffer,
},
[VECS] = {
-   .name = "vecs",
.hw_id = VECS_HW,
-   .exec_id = I915_EXEC_VEBOX,
.class = VIDEO_ENHANCEMENT_CLASS,
.instance = 0,
.mmio_base = VEBOX_RING_BASE,
.irq_shift = GEN8_VECS_IRQ_SHIFT,
-   .init_execlists = logical_xcs_ring_init,
-   .init_legacy = intel_init_vebox_ring_buffer,
},
 };
 
@@ -99,6 +111,8 @@
   enum intel_engine_id id)
 {
const struct engine_info *info = _engines[id];
+   const struct engine_class_info *class_info =
+   _engine_classes[info->class];
struct intel_engine_cs *engine;
char instance[3] = "";
 
@@ -112,8 +126,8 @@
/* For historical reasons the engines are called: name, name2... */
if (info->instance)
snprintf(instance, sizeof(instance), "%u", info->instance + 

[Intel-gfx] [PATCH 2/5] drm/i915: Use the same vfunc for BSD2 ring init

[Oscar Mateo]

If we needed to do something different for the init functions, we could
always look at the instance number to make the distinction.But, in any
case, the two functions are virtually identical already (please notice
that BSD2_RING is only used from gen8 onwards).

Cc: Tvrtko Ursulin 
Cc: Paulo Zanoni 
Cc: Rodrigo Vivi 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  |  2 +-
 drivers/gpu/drm/i915/intel_ringbuffer.c | 14 --
 drivers/gpu/drm/i915/intel_ringbuffer.h |  1 -
 3 files changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index b3d575a..abc0a9c 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -79,7 +79,7 @@
.mmio_base = GEN8_BSD2_RING_BASE,
.irq_shift = GEN8_VCS2_IRQ_SHIFT,
.init_execlists = logical_xcs_ring_init,
-   .init_legacy = intel_init_bsd2_ring_buffer,
+   .init_legacy = intel_init_bsd_ring_buffer,
},
[VECS] = {
.name = "vecs",
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c 
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index c98acc2..81eee42 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -2175,20 +2175,6 @@ int intel_init_bsd_ring_buffer(struct intel_engine_cs 
*engine)
return intel_init_ring_buffer(engine);
 }
 
-/**
- * Initialize the second BSD ring (eg. Broadwell GT3, Skylake GT3)
- */
-int intel_init_bsd2_ring_buffer(struct intel_engine_cs *engine)
-{
-   struct drm_i915_private *dev_priv = engine->i915;
-
-   intel_ring_default_vfuncs(dev_priv, engine);
-
-   engine->emit_flush = gen6_bsd_ring_flush;
-
-   return intel_init_ring_buffer(engine);
-}
-
 int intel_init_blt_ring_buffer(struct intel_engine_cs *engine)
 {
struct drm_i915_private *dev_priv = engine->i915;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 4ab590b..5c1a27f 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -561,7 +561,6 @@ int intel_ring_pin(struct intel_ring *ring,
 
 int intel_init_render_ring_buffer(struct intel_engine_cs *engine);
 int intel_init_bsd_ring_buffer(struct intel_engine_cs *engine);
-int intel_init_bsd2_ring_buffer(struct intel_engine_cs *engine);
 int intel_init_blt_ring_buffer(struct intel_engine_cs *engine);
 int intel_init_vebox_ring_buffer(struct intel_engine_cs *engine);
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/5] Classify the engines in class + instance

[Oscar Mateo]

This refactoring helps simplify a few things here and there.

Daniele Ceraolo Spurio (2):
  drm/i915: Classify the engines in class + instance
  drm/i915: Use the engine class to get the context size

Oscar Mateo (3):
  drm/i915: Use the same vfunc for BSD2 ring init
  drm/i915: Generate the engine name based on the instance number
  drm/i915: Split the engine info table in two levels, using class +
instance

 drivers/gpu/drm/i915/intel_engine_cs.c   | 90 +++-
 drivers/gpu/drm/i915/intel_lrc.c | 34 +++
 drivers/gpu/drm/i915/intel_lrc.h |  7 ++-
 drivers/gpu/drm/i915/intel_ringbuffer.c  | 14 -
 drivers/gpu/drm/i915/intel_ringbuffer.h  | 15 -
 drivers/gpu/drm/i915/selftests/mock_engine.c |  2 +-
 6 files changed, 104 insertions(+), 58 deletions(-)

-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/5] drm/i915: Classify the engines in class + instance

[Oscar Mateo]

From: Daniele Ceraolo Spurio 

In such a way that vcs and vcs2 are just two different instances (0 and 1)
of the same engine class (VIDEO_DECODE_CLASS).

Cc: Tvrtko Ursulin 
Cc: Paulo Zanoni 
Cc: Rodrigo Vivi 
Cc: Chris Wilson 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  | 14 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h | 10 ++
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 854e8e0..b3d575a 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -30,6 +30,8 @@
const char *name;
unsigned int exec_id;
unsigned int hw_id;
+   enum intel_engine_class class;
+   u32 instance;
u32 mmio_base;
unsigned irq_shift;
int (*init_legacy)(struct intel_engine_cs *engine);
@@ -39,6 +41,8 @@
.name = "rcs",
.hw_id = RCS_HW,
.exec_id = I915_EXEC_RENDER,
+   .class = RENDER_CLASS,
+   .instance = 0,
.mmio_base = RENDER_RING_BASE,
.irq_shift = GEN8_RCS_IRQ_SHIFT,
.init_execlists = logical_render_ring_init,
@@ -48,6 +52,8 @@
.name = "bcs",
.hw_id = BCS_HW,
.exec_id = I915_EXEC_BLT,
+   .class = COPY_ENGINE_CLASS,
+   .instance = 0,
.mmio_base = BLT_RING_BASE,
.irq_shift = GEN8_BCS_IRQ_SHIFT,
.init_execlists = logical_xcs_ring_init,
@@ -57,6 +63,8 @@
.name = "vcs",
.hw_id = VCS_HW,
.exec_id = I915_EXEC_BSD,
+   .class = VIDEO_DECODE_CLASS,
+   .instance = 0,
.mmio_base = GEN6_BSD_RING_BASE,
.irq_shift = GEN8_VCS1_IRQ_SHIFT,
.init_execlists = logical_xcs_ring_init,
@@ -66,6 +74,8 @@
.name = "vcs2",
.hw_id = VCS2_HW,
.exec_id = I915_EXEC_BSD,
+   .class = VIDEO_DECODE_CLASS,
+   .instance = 1,
.mmio_base = GEN8_BSD2_RING_BASE,
.irq_shift = GEN8_VCS2_IRQ_SHIFT,
.init_execlists = logical_xcs_ring_init,
@@ -75,6 +85,8 @@
.name = "vecs",
.hw_id = VECS_HW,
.exec_id = I915_EXEC_VEBOX,
+   .class = VIDEO_ENHANCEMENT_CLASS,
+   .instance = 0,
.mmio_base = VEBOX_RING_BASE,
.irq_shift = GEN8_VECS_IRQ_SHIFT,
.init_execlists = logical_xcs_ring_init,
@@ -101,6 +113,8 @@
engine->hw_id = engine->guc_id = info->hw_id;
engine->mmio_base = info->mmio_base;
engine->irq_shift = info->irq_shift;
+   engine->class = info->class;
+   engine->instance = info->instance;
 
/* Nothing to do here, execute in order of dependencies */
engine->schedule = NULL;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index cbe61d3..4ab590b 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -193,6 +193,16 @@ struct intel_engine_cs {
enum intel_engine_id id;
unsigned int exec_id;
unsigned int hw_id;
+
+   enum intel_engine_class {
+   RENDER_CLASS = 0,
+   VIDEO_DECODE_CLASS = 1,
+   VIDEO_ENHANCEMENT_CLASS = 2,
+   COPY_ENGINE_CLASS = 3,
+   OTHER_CLASS = 4
+   } class;
+   u8 instance;
+
unsigned int guc_id;
u32 mmio_base;
unsigned int irq_shift;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/5] drm/i915: Use the engine class to get the context size

[Oscar Mateo]

From: Daniele Ceraolo Spurio 

Technically speaking, the context size is per engine class, not per
instance.

Cc: Tvrtko Ursulin 
Cc: Paulo Zanoni 
Cc: Rodrigo Vivi 
Cc: Chris Wilson 
Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_lrc.c | 34 ++
 drivers/gpu/drm/i915/intel_lrc.h |  7 ++-
 2 files changed, 28 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 0dc1cc4..6b1fc4a 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1908,8 +1908,10 @@ static void execlists_init_reg_state(u32 *regs,
 }
 
 /**
- * intel_lr_context_size() - return the size of the context for an engine
- * @engine: which engine to find the context size for
+ * intel_lr_class_context_size() - return the size of the context for a given
+ * engine class
+ * @dev_priv: i915 device private
+ * @class: which engine class to find the context size for
  *
  * Each engine may require a different amount of space for a context image,
  * so when allocating (or copying) an image, this function can be used to
@@ -1921,25 +1923,33 @@ static void execlists_init_reg_state(u32 *regs,
  * in LRC mode, but does not include the "shared data page" used with
  * GuC submission. The caller should account for this if using the GuC.
  */
-uint32_t intel_lr_context_size(struct intel_engine_cs *engine)
+uint32_t intel_lr_class_context_size(struct drm_i915_private *dev_priv,
+enum intel_engine_class class)
 {
int ret = 0;
 
-   WARN_ON(INTEL_GEN(engine->i915) < 8);
+   WARN_ON(INTEL_GEN(dev_priv) < 8);
 
-   switch (engine->id) {
-   case RCS:
-   if (INTEL_GEN(engine->i915) >= 9)
+   switch (class) {
+   case RENDER_CLASS:
+   switch (INTEL_GEN(dev_priv)) {
+   default:
+   DRM_ERROR("Unknown context size for GEN\n");
+   case 9:
ret = GEN9_LR_CONTEXT_RENDER_SIZE;
-   else
+   break;
+   case 8:
ret = GEN8_LR_CONTEXT_RENDER_SIZE;
+   break;
+   }
break;
-   case VCS:
-   case BCS:
-   case VECS:
-   case VCS2:
+   case VIDEO_DECODE_CLASS:
+   case VIDEO_ENHANCEMENT_CLASS:
+   case COPY_ENGINE_CLASS:
ret = GEN8_LR_CONTEXT_OTHER_SIZE;
break;
+   default:
+   MISSING_CASE(class);
}
 
return ret;
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index e8015e7..b3a4331 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -78,7 +78,12 @@ enum {
 struct drm_i915_private;
 struct i915_gem_context;
 
-uint32_t intel_lr_context_size(struct intel_engine_cs *engine);
+uint32_t intel_lr_class_context_size(struct drm_i915_private *dev_priv,
+enum intel_engine_class class);
+static inline uint32_t intel_lr_context_size(struct intel_engine_cs *engine)
+{
+   return intel_lr_class_context_size(engine->i915, engine->class);
+}
 
 void intel_lr_context_resume(struct drm_i915_private *dev_priv);
 uint64_t intel_lr_context_descriptor(struct i915_gem_context *ctx,
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/5] drm/i915: Generate the engine name based on the instance number

[Oscar Mateo]

Not really needed, but makes the next change a little bit more compact.

Cc: Tvrtko Ursulin 
Cc: Paulo Zanoni 
Cc: Rodrigo Vivi 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Signed-off-by: Oscar Mateo 
---
 drivers/gpu/drm/i915/intel_engine_cs.c   | 8 ++--
 drivers/gpu/drm/i915/intel_ringbuffer.h  | 4 +++-
 drivers/gpu/drm/i915/selftests/mock_engine.c | 2 +-
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index abc0a9c..530f822 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -71,7 +71,7 @@
.init_legacy = intel_init_bsd_ring_buffer,
},
[VCS2] = {
-   .name = "vcs2",
+   .name = "vcs",
.hw_id = VCS2_HW,
.exec_id = I915_EXEC_BSD,
.class = VIDEO_DECODE_CLASS,
@@ -100,6 +100,7 @@
 {
const struct engine_info *info = _engines[id];
struct intel_engine_cs *engine;
+   char instance[3] = "";
 
GEM_BUG_ON(dev_priv->engine[id]);
engine = kzalloc(sizeof(*engine), GFP_KERNEL);
@@ -108,7 +109,10 @@
 
engine->id = id;
engine->i915 = dev_priv;
-   engine->name = info->name;
+   /* For historical reasons the engines are called: name, name2... */
+   if (info->instance)
+   snprintf(instance, sizeof(instance), "%u", info->instance + 1);
+   snprintf(engine->name, sizeof(engine->name), "%s%s", info->name, 
instance);
engine->exec_id = info->exec_id;
engine->hw_id = engine->guc_id = info->hw_id;
engine->mmio_base = info->mmio_base;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 5c1a27f..d617049 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -187,9 +187,11 @@ enum intel_engine_id {
VECS
 };
 
+#define INTEL_ENGINE_CS_MAX_NAME 8
+
 struct intel_engine_cs {
struct drm_i915_private *i915;
-   const char  *name;
+   char name[INTEL_ENGINE_CS_MAX_NAME];
enum intel_engine_id id;
unsigned int exec_id;
unsigned int hw_id;
diff --git a/drivers/gpu/drm/i915/selftests/mock_engine.c 
b/drivers/gpu/drm/i915/selftests/mock_engine.c
index b89050e..4a1ffca 100644
--- a/drivers/gpu/drm/i915/selftests/mock_engine.c
+++ b/drivers/gpu/drm/i915/selftests/mock_engine.c
@@ -140,7 +140,7 @@ struct intel_engine_cs *mock_engine(struct drm_i915_private 
*i915,
 
/* minimal engine setup for requests */
engine->base.i915 = i915;
-   engine->base.name = name;
+   strncpy(engine->base.name, name, sizeof(engine->base.name) - 1);
engine->base.id = id++;
engine->base.status_page.page_addr = (void *)(engine + 1);
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Assert the engine is idle before overwiting the HWS (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Assert the engine is idle before 
overwiting the HWS (rev2)
URL   : https://patchwork.freedesktop.org/series/22527/
State : warning

== Summary ==

Series 22527v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/22527/revisions/2/mbox/

Test kms_force_connector_basic:
Subgroup force-connector-state:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup force-edid:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup force-load-detect:
pass   -> SKIP   (fi-ivb-3520m)
Subgroup prune-stale-modes:
pass   -> SKIP   (fi-ivb-3520m)

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 434s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 424s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time: 583s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 507s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 554s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time: 476s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 488s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 408s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 407s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 426s
fi-ivb-3520m total:278  pass:256  dwarn:0   dfail:0   fail:0   skip:22  
time: 487s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 469s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 453s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 565s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 458s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 573s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 455s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 494s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 433s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 520s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 400s

39a0f48c8bc7c528cc705016dafa08a9dedfd36b drm-tip: 2017y-04m-05d-13h-22m-47s UTC 
integration manifest
ffc28f6 drm/i915: Advance ring->head fully when idle
61cbb1b drm/i915: Assert the engine is idle before overwiting the HWS

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4411/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 6/7] drm/i915/perf: per-gen timebase for checking sample freq

[Robert Bragg]

An oa_exponent_to_ns() utility and per-gen timebase constants where
recently removed when updating the tail pointer race condition WA, and
this restores those so we can update the _PROP_OA_EXPONENT validation
done in read_properties_unlocked() to not assume we have a 12.5KHz
timebase as we did for Haswell.

Signed-off-by: Robert Bragg 
Cc: Lionel Landwerlin 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_perf.c | 21 +++--
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3a22b6fd0ee6..48b07d706f06 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2463,6 +2463,7 @@ struct drm_i915_private {
 
bool periodic;
int period_exponent;
+   int timestamp_frequency;
 
int metrics_set;
 
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 98eb6415b63a..87c0d1ce1b9f 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2549,6 +2549,12 @@ i915_perf_open_ioctl_locked(struct drm_i915_private 
*dev_priv,
return ret;
 }
 
+static u64 oa_exponent_to_ns(struct drm_i915_private *dev_priv, int exponent)
+{
+   return div_u64(10ULL * (2ULL << exponent),
+  dev_priv->perf.oa.timestamp_frequency);
+}
+
 /**
  * read_properties_unlocked - validate + copy userspace stream open properties
  * @dev_priv: i915 device instance
@@ -2647,14 +2653,9 @@ static int read_properties_unlocked(struct 
drm_i915_private *dev_priv,
/* Theoretically we can program the OA unit to sample
 * every 160ns but don't allow that by default unless
 * root.
-*
-* On Haswell the period is derived from the exponent
-* as:
-*
-*   period = 80ns * 2^(exponent + 1)
 */
BUILD_BUG_ON(sizeof(oa_period) != 8);
-   oa_period = 80ull * (2ull << value);
+   oa_period = oa_exponent_to_ns(dev_priv, value);
 
/* This check is primarily to ensure that oa_period <=
 * UINT32_MAX (before passing to do_div which only
@@ -2910,6 +2911,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.ops.oa_hw_tail_read =
gen7_oa_hw_tail_read;
 
+   dev_priv->perf.oa.timestamp_frequency = 1250;
+
dev_priv->perf.oa.oa_formats = hsw_oa_formats;
 
dev_priv->perf.oa.n_builtin_sets =
@@ -2923,6 +2926,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
 */
 
if (IS_GEN8(dev_priv)) {
+   dev_priv->perf.oa.timestamp_frequency = 1250;
+
dev_priv->perf.oa.ctx_oactxctrl_offset = 0x120;
dev_priv->perf.oa.ctx_flexeu0_offset = 0x2ce;
dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<25);
@@ -2939,6 +2944,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
i915_oa_select_metric_set_chv;
}
} else if (IS_GEN9(dev_priv)) {
+   dev_priv->perf.oa.timestamp_frequency = 1200;
+
dev_priv->perf.oa.ctx_oactxctrl_offset = 0x128;
dev_priv->perf.oa.ctx_flexeu0_offset = 0x3de;
dev_priv->perf.oa.gen8_valid_ctx_bit = (1<<16);
@@ -2959,6 +2966,8 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
dev_priv->perf.oa.ops.select_metric_set =
i915_oa_select_metric_set_sklgt4;
} else if (IS_BROXTON(dev_priv)) {
+   dev_priv->perf.oa.timestamp_frequency = 
19200123;
+
dev_priv->perf.oa.n_builtin_sets =
i915_oa_n_builtin_metric_sets_bxt;
dev_priv->perf.oa.ops.select_metric_set =
-- 
2.12.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 4/7] drm/i915/perf: Add OA unit support for Gen 8+

[Robert Bragg]

Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all
share (more-or-less) the same OA unit design.

Of particular note in comparison to Haswell: some OA unit HW config
state has become per-context state and as a consequence it is somewhat
more complicated to manage synchronous state changes from the cpu while
there's no guarantee of what context (if any) is currently actively
running on the gpu.

The periodic sampling frequency which can be particularly useful for
system-wide analysis (as opposed to command stream synchronised
MI_REPORT_PERF_COUNT commands) is perhaps the most surprising state to
have become per-context save and restored (while the OABUFFER
destination is still a shared, system-wide resource).

This support for gen8+ takes care to consider a number of timing
challenges involved in synchronously updating per-context state
primarily by programming all config state from the cpu and updating all
current and saved contexts synchronously while the OA unit is still
disabled.

The driver intentionally avoids depending on command streamer
programming to update OA state considering the lack of synchronization
between the automatic loading of OACTXCONTROL state (that includes the
periodic sampling state and enable state) on context restore and the
parsing of any general purpose BB the driver can control. I.e. this
implementation is careful to avoid the possibility of a context restore
temporarily enabling any out-of-date periodic sampling state. In
addition to the risk of transiently-out-of-date state being loaded
automatically; there are also internal HW latencies involved in the
loading of MUX configurations which would be difficult to account for
from the command streamer (and we only want to enable the unit when once
the MUX configuration is complete).

Since the Gen8+ OA unit design no longer supports clock gating the unit
off for a single given context (which effectively stopped any progress
of counters while any other context was running) and instead supports
tagging OA reports with a context ID for filtering on the CPU, it means
we can no longer hide the system-wide progress of counters from a
non-privileged application only interested in metrics for its own
context. Although we could theoretically try and subtract the progress
of other contexts before forwarding reports via read() we aren't in a
position to filter reports captured via MI_REPORT_PERF_COUNT commands.
As a result, for Gen8+, we always require the
dev.i915.perf_stream_paranoid to be unset for any access to OA metrics
if not root.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.h |  45 +-
 drivers/gpu/drm/i915/i915_gem_context.h |   1 +
 drivers/gpu/drm/i915/i915_perf.c| 938 +---
 drivers/gpu/drm/i915/i915_reg.h |  22 +
 drivers/gpu/drm/i915/intel_lrc.c|   5 +
 include/uapi/drm/i915_drm.h |  19 +-
 6 files changed, 937 insertions(+), 93 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9c37b73ac7ac..3a22b6fd0ee6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2067,9 +2067,17 @@ struct i915_oa_ops {
void (*init_oa_buffer)(struct drm_i915_private *dev_priv);
 
/**
-* @enable_metric_set: Applies any MUX configuration to set up the
-* Boolean and Custom (B/C) counters that are part of the counter
-* reports being sampled. May apply system constraints such as
+* @select_metric_set: The auto generated code that checks whether a
+* requested OA config is applicable to the system and if so sets up
+* the mux, oa and flex eu register config pointers according to the
+* current dev_priv->perf.oa.metrics_set.
+*/
+   int (*select_metric_set)(struct drm_i915_private *dev_priv);
+
+   /**
+* @enable_metric_set: Selects and applies any MUX configuration to set
+* up the Boolean and Custom (B/C) counters that are part of the
+* counter reports being sampled. May apply system constraints such as
 * disabling EU clock gating as required.
 */
int (*enable_metric_set)(struct drm_i915_private *dev_priv);
@@ -2100,20 +2108,13 @@ struct i915_oa_ops {
size_t *offset);
 
/**
-* @oa_buffer_check: Check for OA buffer data + update tail
-*
-* This is either called via fops or the poll check hrtimer (atomic
-* ctx) without any locks taken.
+* @oa_hw_tail_read: read the OA tail pointer register
 *
-* It's safe to read OA config state here unlocked, assuming that this
-* is only called while the stream is enabled, while the global OA
-* configuration can't be modified.
-*
-* Efficiency is more important than avoiding some false positives
-* here, which will be handled gracefully - likely 

[Intel-gfx] [PATCH v3 1/7] drm/i915: expose _SLICE_MASK GETPARM

[Robert Bragg]

Enables userspace to determine the number of slices enabled and also
know what specific slices are enabled. This information is required, for
example, to be able to analyse some OA counter reports where the counter
configuration depends on the HW slice configuration.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.c | 5 +
 include/uapi/drm/i915_drm.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5852eed2a867..337acf034d36 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -357,6 +357,11 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
 */
value = 1;
break;
+   case I915_PARAM_SLICE_MASK:
+   value = INTEL_INFO(dev_priv)->sseu.slice_mask;
+   if (!value)
+   return -ENODEV;
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 3554495bef13..f47fb7f26f36 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -392,6 +392,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_HAS_POOLED_EU38
 #define I915_PARAM_MIN_EU_IN_POOL   39
 #define I915_PARAM_MMAP_GTT_VERSION 40
+#define I915_PARAM_SLICE_MASK   45 /* XXX: rebase before landing */
 
 /* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
  * priorities and the driver will attempt to execute batches in priority order.
-- 
2.12.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 7/7] drm/i915/perf: remove perf.hook_lock

[Robert Bragg]

In earlier iterations of the i915-perf driver we had a number of
callbacks/hooks from other parts of the i915 driver to e.g. notify us
when a legacy context was pinned and these could run asynchronously with
respect to the stream file operations and might also run in atomic
context.

dev_priv->perf.hook_lock had been for serialising access to state needed
within these callbacks, but as the code has evolved some of the hooks
have gone away or are implemented to avoid needing to lock any state.

The remaining use of this lock was actually redundant considering how
the gen7 oacontrol state used to be updated as part of a context pin
hook.

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 --
 drivers/gpu/drm/i915/i915_perf.c | 32 ++--
 2 files changed, 10 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 48b07d706f06..67ac4e6dbccb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2444,8 +2444,6 @@ struct drm_i915_private {
struct mutex lock;
struct list_head streams;
 
-   spinlock_t hook_lock;
-
struct {
struct i915_perf_stream *exclusive_stream;
 
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 87c0d1ce1b9f..63a1152766f8 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1677,9 +1677,17 @@ static void gen8_disable_metric_set(struct 
drm_i915_private *dev_priv)
/* NOP */
 }
 
-static void gen7_update_oacontrol_locked(struct drm_i915_private *dev_priv)
+static void gen7_oa_enable(struct drm_i915_private *dev_priv)
 {
-   lockdep_assert_held(_priv->perf.hook_lock);
+   /* Reset buf pointers so we don't forward reports from before now.
+*
+* Think carefully if considering trying to avoid this, since it
+* also ensures status flags and the buffer itself are cleared
+* in error paths, and we have checks for invalid reports based
+* on the assumption that certain fields are written to zeroed
+* memory which this helps maintains.
+*/
+   gen7_init_oa_buffer(dev_priv);
 
if (dev_priv->perf.oa.exclusive_stream->enabled) {
struct i915_gem_context *ctx =
@@ -1702,25 +1710,6 @@ static void gen7_update_oacontrol_locked(struct 
drm_i915_private *dev_priv)
I915_WRITE(GEN7_OACONTROL, 0);
 }
 
-static void gen7_oa_enable(struct drm_i915_private *dev_priv)
-{
-   unsigned long flags;
-
-   /* Reset buf pointers so we don't forward reports from before now.
-*
-* Think carefully if considering trying to avoid this, since it
-* also ensures status flags and the buffer itself are cleared
-* in error paths, and we have checks for invalid reports based
-* on the assumption that certain fields are written to zeroed
-* memory which this helps maintains.
-*/
-   gen7_init_oa_buffer(dev_priv);
-
-   spin_lock_irqsave(_priv->perf.hook_lock, flags);
-   gen7_update_oacontrol_locked(dev_priv);
-   spin_unlock_irqrestore(_priv->perf.hook_lock, flags);
-}
-
 static void gen8_oa_enable(struct drm_i915_private *dev_priv)
 {
u32 report_format = dev_priv->perf.oa.oa_buffer.format;
@@ -2999,7 +2988,6 @@ void i915_perf_init(struct drm_i915_private *dev_priv)
 
INIT_LIST_HEAD(_priv->perf.streams);
mutex_init(_priv->perf.lock);
-   spin_lock_init(_priv->perf.hook_lock);
spin_lock_init(_priv->perf.oa.oa_buffer.ptr_lock);
 
dev_priv->perf.sysctl_header = register_sysctl_table(dev_root);
-- 
2.12.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 2/7] drm/i915: expose _SUBSLICE_MASK GETPARM

[Robert Bragg]

Assuming a uniform mask across all slices, this enables userspace to
determine the specific sub slices enabled. This information is required,
for example, to be able to analyse some OA counter reports where the
counter configuration depends on the HW sub slice configuration.

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_drv.c | 5 +
 include/uapi/drm/i915_drm.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 337acf034d36..e4ed70d21e91 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -362,6 +362,11 @@ static int i915_getparam(struct drm_device *dev, void 
*data,
if (!value)
return -ENODEV;
break;
+   case I915_PARAM_SUBSLICE_MASK:
+   value = INTEL_INFO(dev_priv)->sseu.subslice_mask;
+   if (!value)
+   return -ENODEV;
+   break;
default:
DRM_DEBUG("Unknown parameter %d\n", param->param);
return -EINVAL;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index f47fb7f26f36..e0599e729e68 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -393,6 +393,7 @@ typedef struct drm_i915_irq_wait {
 #define I915_PARAM_MIN_EU_IN_POOL   39
 #define I915_PARAM_MMAP_GTT_VERSION 40
 #define I915_PARAM_SLICE_MASK   45 /* XXX: rebase before landing */
+#define I915_PARAM_SUBSLICE_MASK46
 
 /* Query whether DRM_I915_GEM_EXECBUFFER2 supports user defined execution
  * priorities and the driver will attempt to execute batches in priority order.
-- 
2.12.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 3/7] drm/i915/perf: Add 'render basic' Gen8+ OA unit configs

[Robert Bragg]

Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
render metrics on Broadwell, Cherryview, Skylake and Broxton. These are
auto generated from an XML description of metric sets, currently
maintained in gputop, ref:

 https://github.com/rib/gputop
 > gputop-data/oa-*.xml
 > scripts/i915-perf-kernelgen.py

 $ make -C gputop-data -f Makefile.xml WHITELIST=RenderBasic

v2: add newlines to debug messages + fix comment (Matthew Auld)

Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 
---
 drivers/gpu/drm/i915/Makefile |   8 +-
 drivers/gpu/drm/i915/i915_drv.h   |   2 +
 drivers/gpu/drm/i915/i915_oa_bdw.c| 380 ++
 drivers/gpu/drm/i915/i915_oa_bdw.h|  38 
 drivers/gpu/drm/i915/i915_oa_bxt.c| 238 +
 drivers/gpu/drm/i915/i915_oa_bxt.h|  38 
 drivers/gpu/drm/i915/i915_oa_chv.c| 225 
 drivers/gpu/drm/i915/i915_oa_chv.h|  38 
 drivers/gpu/drm/i915/i915_oa_sklgt2.c | 228 
 drivers/gpu/drm/i915/i915_oa_sklgt2.h |  38 
 drivers/gpu/drm/i915/i915_oa_sklgt3.c | 236 +
 drivers/gpu/drm/i915/i915_oa_sklgt3.h |  38 
 drivers/gpu/drm/i915/i915_oa_sklgt4.c | 247 ++
 drivers/gpu/drm/i915/i915_oa_sklgt4.h |  38 
 14 files changed, 1791 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2cf04504e494..41400a138a1e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -127,7 +127,13 @@ i915-y += i915_vgpu.o
 
 # perf code
 i915-y += i915_perf.o \
- i915_oa_hsw.o
+ i915_oa_hsw.o \
+ i915_oa_bdw.o \
+ i915_oa_chv.o \
+ i915_oa_sklgt2.o \
+ i915_oa_sklgt3.o \
+ i915_oa_sklgt4.o \
+ i915_oa_bxt.o
 
 ifeq ($(CONFIG_DRM_I915_GVT),y)
 i915-y += intel_gvt.o
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 51bd6c6034bb..9c37b73ac7ac 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2469,6 +2469,8 @@ struct drm_i915_private {
int mux_regs_len;
const struct i915_oa_reg *b_counter_regs;
int b_counter_regs_len;
+   const struct i915_oa_reg *flex_regs;
+   int flex_regs_len;
 
struct {
struct i915_vma *vma;
diff --git a/drivers/gpu/drm/i915/i915_oa_bdw.c 
b/drivers/gpu/drm/i915/i915_oa_bdw.c
new file mode 100644
index ..b0b1b75fb431
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_oa_bdw.c
@@ -0,0 +1,380 @@
+/*
+ * Autogenerated file, DO NOT EDIT manually!
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+
+#include "i915_drv.h"
+#include "i915_oa_bdw.h"
+
+enum metric_set_id {
+   METRIC_SET_ID_RENDER_BASIC = 1,
+};
+
+int i915_oa_n_builtin_metric_sets_bdw = 1;
+
+static const struct i915_oa_reg b_counter_config_render_basic[] = {
+   { _MMIO(0x2710), 0x },
+   { _MMIO(0x2714), 

[Intel-gfx] [PATCH v3 0/7] Enable OA unit for Gen 8 and 9 in i915 perf

[Robert Bragg]

Adds some R/Bs from from Matthew and some updates based on Matthew's feedback

Notably the 'Add OA unit support for Gen 8+' patch now avoids duplicating lots
of fiddly tail race workaround code by adding a vfunc for reading the OA tail
pointer register.

Robert Bragg (7):
  drm/i915: expose _SLICE_MASK GETPARM
  drm/i915: expose _SUBSLICE_MASK GETPARM
  drm/i915/perf: Add 'render basic' Gen8+ OA unit configs
  drm/i915/perf: Add OA unit support for Gen 8+
  drm/i915/perf: Add more OA configs for BDW, CHV, SKL + BXT
  drm/i915/perf: per-gen timebase for checking sample freq
  drm/i915/perf: remove perf.hook_lock

 drivers/gpu/drm/i915/Makefile   |8 +-
 drivers/gpu/drm/i915/i915_drv.c |   10 +
 drivers/gpu/drm/i915/i915_drv.h |   50 +-
 drivers/gpu/drm/i915/i915_gem_context.h |1 +
 drivers/gpu/drm/i915/i915_oa_bdw.c  | 5154 +++
 drivers/gpu/drm/i915/i915_oa_bdw.h  |   38 +
 drivers/gpu/drm/i915/i915_oa_bxt.c  | 2541 +++
 drivers/gpu/drm/i915/i915_oa_bxt.h  |   38 +
 drivers/gpu/drm/i915/i915_oa_chv.c  | 2730 
 drivers/gpu/drm/i915/i915_oa_chv.h  |   38 +
 drivers/gpu/drm/i915/i915_oa_hsw.c  |   58 +-
 drivers/gpu/drm/i915/i915_oa_sklgt2.c   | 3303 
 drivers/gpu/drm/i915/i915_oa_sklgt2.h   |   38 +
 drivers/gpu/drm/i915/i915_oa_sklgt3.c   | 2856 +
 drivers/gpu/drm/i915/i915_oa_sklgt3.h   |   38 +
 drivers/gpu/drm/i915/i915_oa_sklgt4.c   | 2910 +
 drivers/gpu/drm/i915/i915_oa_sklgt4.h   |   38 +
 drivers/gpu/drm/i915/i915_perf.c|  963 +-
 drivers/gpu/drm/i915/i915_reg.h |   22 +
 drivers/gpu/drm/i915/intel_lrc.c|5 +
 include/uapi/drm/i915_drm.h |   21 +-
 21 files changed, 20745 insertions(+), 115 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bdw.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_bxt.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_chv.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt2.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt3.h
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.c
 create mode 100644 drivers/gpu/drm/i915/i915_oa_sklgt4.h

-- 
2.12.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v3] benchmarks/gem_wsim: Command submission workload simulator

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Tool which emits batch buffers to engines with configurable
sequences, durations, contexts, dependencies and userspace waits.

Unfinished but shows promise so sending out for early feedback.

v2:
 * Load workload descriptors from files. (also -w)
 * Help text.
 * Calibration control if needed. (-t)
 * NORELOC | LUT to eb flags.
 * Added sample workload to wsim/workload1.

v3:
 * Multiple parallel different workloads (-w -w ...).
 * Multi-context workloads.
 * Variable (random) batch length.
 * Load balancing (round robin and queue depth estimation).
 * Workloads delays and explicit sync steps.
 * Workload frequency (period) control.

TODO list:

 * Fence support.
 * Move majority of help text to README.
 * Better error handling.
 * Less 1980's workload parsing.
 * Proper workloads.
 * Explicit waits?
 * Threads?
 * ... ?

Signed-off-by: Tvrtko Ursulin 
Cc: Chris Wilson 
Cc: "Rogozhkin, Dmitry V" 
---
 benchmarks/Makefile.sources |1 +
 benchmarks/gem_wsim.c   | 1053 +++
 benchmarks/wsim/workload1   |7 +
 benchmarks/wsim/workload2   |7 +
 benchmarks/wsim/workload3   |7 +
 benchmarks/wsim/workload4   |8 +
 benchmarks/wsim/workload5   |8 +
 benchmarks/wsim/workload6   |8 +
 8 files changed, 1099 insertions(+)
 create mode 100644 benchmarks/gem_wsim.c
 create mode 100644 benchmarks/wsim/workload1
 create mode 100644 benchmarks/wsim/workload2
 create mode 100644 benchmarks/wsim/workload3
 create mode 100644 benchmarks/wsim/workload4
 create mode 100644 benchmarks/wsim/workload5
 create mode 100644 benchmarks/wsim/workload6

diff --git a/benchmarks/Makefile.sources b/benchmarks/Makefile.sources
index 3af54ebe36f2..3a941150abb3 100644
--- a/benchmarks/Makefile.sources
+++ b/benchmarks/Makefile.sources
@@ -14,6 +14,7 @@ benchmarks_prog_list =\
gem_prw \
gem_set_domain  \
gem_syslatency  \
+   gem_wsim\
kms_vblank  \
prime_lookup\
vgem_mmap   \
diff --git a/benchmarks/gem_wsim.c b/benchmarks/gem_wsim.c
new file mode 100644
index ..38041da1f6e3
--- /dev/null
+++ b/benchmarks/gem_wsim.c
@@ -0,0 +1,1053 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+
+#include "intel_chipset.h"
+#include "drm.h"
+#include "ioctl_wrappers.h"
+#include "drmtest.h"
+#include "intel_io.h"
+
+enum intel_engine_id {
+   RCS,
+   BCS,
+   VCS,
+   VCS1,
+   VCS2,
+   VECS,
+   NUM_ENGINES
+};
+
+struct duration {
+   unsigned int min, max, cur;
+};
+
+enum w_type
+{
+   BATCH,
+   SYNC,
+   DELAY,
+   PERIOD
+};
+
+struct w_step
+{
+   /* Workload step metadata */
+   enum w_type type;
+   unsigned int context;
+   unsigned int engine;
+   struct duration duration;
+   int dependency;
+   int wait;
+
+   /* Implementation details */
+   struct drm_i915_gem_execbuffer2 eb;
+   struct drm_i915_gem_exec_object2 obj[4];
+   struct drm_i915_gem_relocation_entry reloc;
+   unsigned long bb_sz;
+   uint32_t bb_handle;
+   uint64_t seqno_offset;
+};
+
+struct workload
+{
+   unsigned int nr_steps;
+   struct w_step *steps;
+
+   struct timespec repeat_start;
+
+   unsigned int nr_ctxs;
+   uint32_t *ctx_id;
+
+   unsigned long seqno[NUM_ENGINES];
+   uint32_t status_page_handle[NUM_ENGINES];
+   uint32_t 

[Intel-gfx] ✓ Fi.CI.BAT: success for Some minor i915-perf prep changes (rev3)

[Patchwork]

== Series Details ==

Series: Some minor i915-perf prep changes (rev3)
URL   : https://patchwork.freedesktop.org/series/20073/
State : success

== Summary ==

Series 20073v3 Some minor i915-perf prep changes
https://patchwork.freedesktop.org/api/1.0/series/20073/revisions/3/mbox/

Test kms_flip:
Subgroup basic-flip-vs-wf_vblank:
pass   -> FAIL   (fi-skl-6700hq) fdo#99739

fdo#99739 https://bugs.freedesktop.org/show_bug.cgi?id=99739

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 433s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 431s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time: 572s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 506s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 548s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time: 489s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 480s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 411s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 404s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 420s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 488s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 461s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 452s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 571s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 451s
fi-skl-6700hqtotal:278  pass:260  dwarn:0   dfail:0   fail:1   skip:17  
time: 572s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 463s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 489s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 429s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 529s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 404s

39a0f48c8bc7c528cc705016dafa08a9dedfd36b drm-tip: 2017y-04m-05d-13h-22m-47s UTC 
integration manifest
4fd9f5e drm/i915/perf: improve invalid OA format debug message

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4410/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3] drm/i915/perf: rate limit spurious oa report notice

[Matthew Auld]

On 04/05, Robert Bragg wrote:
> Instead of initializing and summarising the number of throttled messages in
> the driver _init / _fini we now do this when opening / closing an OA stream.
> 
> --- >8 ---
> 
> This change is pre-emptively aiming to avoid a potential cause of kernel
> logging noise in case some condition were to result in us seeing invalid
> OA reports.
> 
> The workaround for the OA unit's tail pointer race condition is what
> avoids the primary known cause of invalid reports being seen and with
> that in place we aren't expecting to see this notice but it can't be
> entirely ruled out.
> 
> Just in case some condition does lead to the notice then it's likely
> that it will be triggered repeatedly while attempting to append a
> sequence of reports and depending on the configured OA sampling
> frequency that might be a large number of repeat notices.
> 
> v2: (Chris) avoid inconsistent warning on throttle with
> printk_ratelimit()
> v3: (Matt) init and summarise with stream init/close not driver init/fini
> 
> Signed-off-by: Robert Bragg 
Reviewed-by: Matthew Auld 

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2] drm/i915: Advance ring->head fully when idle

[Chris Wilson]

When we retire the last request on the ring, before we ever access that
ring again we know it will be completely idle and so we can advance the
ring->head fully to the end (i.e. ring->tail) and not just to the start
of the breadcrumb. This allows us to skip re-emitting the breadcrumb
after resetting the GPU if the ring was entirely idle. This prevents us
from overwriting a seqno wraparound by re-executing a stale breadcrumb,
i.e.
submit_request(1)
intel_engine_init_global_seqno(0)
i915_reset()
would then leave 1 in the HWS, but the next request to execute would
also be with seqno 1. The sanity checks upon submission detect this as a
timewarp and explode. By setting the ring as empty, upon reset the HWS
is left as 0, leaving it consistent with the timeline.

v2: Fix check for deleting last element of list. We know that this
request is always the first element of the ring, so only if next
points back to the start will this be the only request in flight.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100144
Testcase: igt/gem_exec_whisper/hang-*
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 2f8c5132b54e..e535036132b0 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -295,8 +295,11 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
 * Note this requires that we are always called in request
 * completion order.
 */
+   if (request->ring_link.next == >ring->request_list)
+   request->ring->head = request->ring->tail;
+   else
+   request->ring->head = request->postfix;
list_del(>ring_link);
-   request->ring->head = request->postfix;
if (!--request->i915->gt.active_requests) {
GEM_BUG_ON(!request->i915->gt.awake);
mod_delayed_work(request->i915->wq,
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Suspend GuC prior to GPU Reset during GEM suspend

[David Weinehall]

On 2017-04-05 18:46, Kamble, Sagar A wrote:

On 4/5/2017 6:32 PM, David Weinehall wrote:

On 2017-04-05 15:54, Joonas Lahtinen wrote:

On ke, 2017-04-05 at 15:51 +0530, Sagar Arun Kamble wrote:
i915 is currently doing Full GPU reset at the end of suspend 
followed by

GuC suspend. This reset bypasses the GuC. We need to tell the GuC to
suspend before we do a direct intel_gpu_reset, Otherwise the gpu 
state will

no longer match the GuC's expectations and its suspend will not be
successful. With this change, i915 suspends GuC after suspending 
GEM and

before doing Full GPU reset.

+ David, Oscar and Michel

My understanding is that reloading GuC firmware after each resume is a
major bottleneck in resume time, and we instead should be telling GuC
to suspend and not reset the GPU, at most only reset the engines.

Regards, Joonas


If this is possible, then yes, it'd definitely be preferable. If not,
then doing the GuC + HuC loading asynchronously on resume would be 
preferable.

Anusha mentioned working on asynchronous loading, hence added to CC.


Kind regards, David
Data points about GuC load times for reference that I collected today 
on SKL and APL.
At Rpn(lowest frequency) it loads/becomes ready in 3-4 jiffies. 
Running at >=RPe it becomes ready in a jiffy.

Are these times in tolerable limits?
Another concern Daniele highlighted was rare chance of WOPCM 
persisting post suspend/resume and hence needing reload.
I believe the fetch from disk must be time consuming during boot time 
load and for that asynchronous

load can be pursued.

I've seen times on the order of 30-35ms. It should be noted though that 
this included HuC (and HuC verifying the integrity of HuC or whatever it 
does).


I can re-run the tests once I'm done with various other tests I'm doing 
right now though;
my GuC-related tests are quite old, since it's not loaded by default 
(which is probably a good

thing, considering the stability issues we're seeing with GuC).


Kind regards, David
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 


This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Assert the engine is idle before overwiting the HWS

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Assert the engine is idle before 
overwiting the HWS
URL   : https://patchwork.freedesktop.org/series/22527/
State : failure

== Summary ==

Series 22527v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/22527/revisions/1/mbox/

Test gem_ctx_switch:
Subgroup basic-default:
pass   -> INCOMPLETE (fi-kbl-7560u)
pass   -> INCOMPLETE (fi-bdw-5557u)
pass   -> INCOMPLETE (fi-skl-6260u)
pass   -> INCOMPLETE (fi-skl-6700hq)
pass   -> INCOMPLETE (fi-skl-gvtdvm)
pass   -> INCOMPLETE (fi-skl-6770hq)
pass   -> INCOMPLETE (fi-kbl-7500u)
pass   -> INCOMPLETE (fi-bxt-t5700)
pass   -> INCOMPLETE (fi-skl-6700k)
Subgroup basic-default-heavy:
pass   -> INCOMPLETE (fi-bxt-j4205)
pass   -> FAIL   (fi-snb-2520m)
pass   -> INCOMPLETE (fi-bsw-n3050)
pass   -> INCOMPLETE (fi-bdw-gvtdvm)
pass   -> FAIL   (fi-snb-2600)

fi-bdw-5557u total:21   pass:20   dwarn:0   dfail:0   fail:0   skip:0   
time: 0s
fi-bdw-gvtdvmtotal:22   pass:21   dwarn:0   dfail:0   fail:0   skip:0   
time: 0s
fi-bsw-n3050 total:22   pass:21   dwarn:0   dfail:0   fail:0   skip:0   
time: 0s
fi-bxt-j4205 total:22   pass:21   dwarn:0   dfail:0   fail:0   skip:0   
time: 0s
fi-bxt-t5700 total:21   pass:20   dwarn:0   dfail:0   fail:0   skip:0   
time: 0s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time: 485s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 480s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 409s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 402s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 422s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 490s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 461s
fi-kbl-7500u total:21   pass:20   dwarn:0   dfail:0   fail:0   skip:0   
time: 0s
fi-kbl-7560u total:21   pass:20   dwarn:0   dfail:0   fail:0   skip:0   
time: 0s
fi-skl-6260u total:21   pass:20   dwarn:0   dfail:0   fail:0   skip:0   
time: 0s
fi-skl-6700hqtotal:21   pass:20   dwarn:0   dfail:0   fail:0   skip:0   
time: 0s
fi-skl-6700k total:21   pass:20   dwarn:0   dfail:0   fail:0   skip:0   
time: 0s
fi-skl-6770hqtotal:21   pass:20   dwarn:0   dfail:0   fail:0   skip:0   
time: 0s
fi-skl-gvtdvmtotal:21   pass:20   dwarn:0   dfail:0   fail:0   skip:0   
time: 0s
fi-snb-2520m total:278  pass:249  dwarn:0   dfail:0   fail:1   skip:28  
time: 538s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time: 416s

39a0f48c8bc7c528cc705016dafa08a9dedfd36b drm-tip: 2017y-04m-05d-13h-22m-47s UTC 
integration manifest
0a69b3e drm/i915: Advance ring->head fully when idle
b5914e6 drm/i915: Assert the engine is idle before overwiting the HWS

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4409/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Suspend GuC prior to GPU Reset during GEM suspend

[Kamble, Sagar A]

On 4/5/2017 6:32 PM, David Weinehall wrote:

On 2017-04-05 15:54, Joonas Lahtinen wrote:

On ke, 2017-04-05 at 15:51 +0530, Sagar Arun Kamble wrote:
i915 is currently doing Full GPU reset at the end of suspend 
followed by

GuC suspend. This reset bypasses the GuC. We need to tell the GuC to
suspend before we do a direct intel_gpu_reset, Otherwise the gpu 
state will

no longer match the GuC's expectations and its suspend will not be
successful. With this change, i915 suspends GuC after suspending GEM 
and

before doing Full GPU reset.

+ David, Oscar and Michel

My understanding is that reloading GuC firmware after each resume is a
major bottleneck in resume time, and we instead should be telling GuC
to suspend and not reset the GPU, at most only reset the engines.

Regards, Joonas


If this is possible, then yes, it'd definitely be preferable. If not,
then doing the GuC + HuC loading asynchronously on resume would be 
preferable.

Anusha mentioned working on asynchronous loading, hence added to CC.


Kind regards, David
Data points about GuC load times for reference that I collected today on 
SKL and APL.
At Rpn(lowest frequency) it loads/becomes ready in 3-4 jiffies. Running 
at >=RPe it becomes ready in a jiffy.

Are these times in tolerable limits?
Another concern Daniele highlighted was rare chance of WOPCM persisting 
post suspend/resume and hence needing reload.
I believe the fetch from disk must be time consuming during boot time 
load and for that asynchronous

load can be pursued.

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3] drm/i915/perf: rate limit spurious oa report notice

[Robert Bragg]

Instead of initializing and summarising the number of throttled messages in
the driver _init / _fini we now do this when opening / closing an OA stream.

--- >8 ---

This change is pre-emptively aiming to avoid a potential cause of kernel
logging noise in case some condition were to result in us seeing invalid
OA reports.

The workaround for the OA unit's tail pointer race condition is what
avoids the primary known cause of invalid reports being seen and with
that in place we aren't expecting to see this notice but it can't be
entirely ruled out.

Just in case some condition does lead to the notice then it's likely
that it will be triggered repeatedly while attempting to append a
sequence of reports and depending on the configured OA sampling
frequency that might be a large number of repeat notices.

v2: (Chris) avoid inconsistent warning on throttle with
printk_ratelimit()
v3: (Matt) init and summarise with stream init/close not driver init/fini

Signed-off-by: Robert Bragg 
---
 drivers/gpu/drm/i915/i915_drv.h  |  6 ++
 drivers/gpu/drm/i915/i915_perf.c | 28 +++-
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 51a410911d81..51bd6c6034bb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2454,6 +2454,12 @@ struct drm_i915_private {
wait_queue_head_t poll_wq;
bool pollin;
 
+   /**
+* For rate limiting any notifications of spurious
+* invalid OA reports
+*/
+   struct ratelimit_state spurious_report_rs;
+
bool periodic;
int period_exponent;
 
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 5738b99caa5b..3277a52ce98e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -632,7 +632,8 @@ static int gen7_append_oa_reports(struct i915_perf_stream 
*stream,
 * copying it to userspace...
 */
if (report32[0] == 0) {
-   DRM_NOTE("Skipping spurious, invalid OA report\n");
+   if (__ratelimit(_priv->perf.oa.spurious_report_rs))
+   DRM_NOTE("Skipping spurious, invalid OA 
report\n");
continue;
}
 
@@ -913,6 +914,11 @@ static void i915_oa_stream_destroy(struct i915_perf_stream 
*stream)
oa_put_render_ctx_id(stream);
 
dev_priv->perf.oa.exclusive_stream = NULL;
+
+   if (dev_priv->perf.oa.spurious_report_rs.missed) {
+   DRM_NOTE("%d spurious OA report notices suppressed due to 
ratelimiting\n",
+dev_priv->perf.oa.spurious_report_rs.missed);
+   }
 }
 
 static void gen7_init_oa_buffer(struct drm_i915_private *dev_priv)
@@ -1268,6 +1274,26 @@ static int i915_oa_stream_init(struct i915_perf_stream 
*stream,
return -EINVAL;
}
 
+   /* We set up some ratelimit state to potentially throttle any _NOTES
+* about spurious, invalid OA reports which we don't forward to
+* userspace.
+*
+* The initialization is associated with opening the stream (not driver
+* init) considering we print a _NOTE about any throttling when closing
+* the stream instead of waiting until driver _fini which no one would
+* ever see.
+*
+* Using the same limiting factors as printk_ratelimit()
+*/
+   ratelimit_state_init(_priv->perf.oa.spurious_report_rs,
+5 * HZ, 10);
+   /* Since we use a DRM_NOTE for spurious reports it would be
+* inconsistent to let __ratelimit() automatically print a warning for
+* throttling.
+*/
+   ratelimit_set_flags(_priv->perf.oa.spurious_report_rs,
+   RATELIMIT_MSG_ON_RELEASE);
+
stream->sample_size = sizeof(struct drm_i915_perf_record_header);
 
format_size = dev_priv->perf.oa.oa_formats[props->oa_format].size;
-- 
2.12.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 5/5] drm/i915: Add more OA configs for BDW, CHV, SKL + BXT

[Robert Bragg]

On Mon, Mar 27, 2017 at 7:16 PM, Matthew Auld <
matthew.william.a...@gmail.com> wrote:

> On 03/23, Robert Bragg wrote:
> > These are auto generated from an XML description of metric sets,
> > currently maintained in gputop, ref:
> >
> >  https://github.com/rib/gputop
> >  > gputop-data/oa-*.xml
> >  > scripts/i915-perf-kernelgen.py
> >
> >  $ make -C gputop-data -f Makefile.xml
> >
> > Signed-off-by: Robert Bragg 
> > ---
>
> 
>
> >  int i915_oa_select_metric_set_bdw(struct drm_i915_private *dev_priv)
> >  {
> > - dev_priv->perf.oa.mux_regs = NULL;
> > - dev_priv->perf.oa.mux_regs_len = 0;
> > - dev_priv->perf.oa.b_counter_regs = NULL;
> > - dev_priv->perf.oa.b_counter_regs_len = 0;
> > - dev_priv->perf.oa.flex_regs = NULL;
> > - dev_priv->perf.oa.flex_regs_len = 0;
> > + dev_priv->perf.oa.mux_regs = NULL;
> > + dev_priv->perf.oa.mux_regs_len = 0;
> > + dev_priv->perf.oa.b_counter_regs = NULL;
> > + dev_priv->perf.oa.b_counter_regs_len = 0;
> > + dev_priv->perf.oa.flex_regs = NULL;
> > + dev_priv->perf.oa.flex_regs_len = 0;
> What changed? I can't tell from the diff...
>

I don't think anything changed in those lines, it's just that the diff uses
the start of the function for context and then has to delete these to add
the full replacement for the function body which included substantial
changes to add the cases for the additional configs.


>
> Otherwise assuming you re-spin with the DRM_DEBUG changes:
> Reviewed-by: Matthew Auld 
>

thanks
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/2] drm/i915: Advance ring->head fully when idle

[Chris Wilson]

When we retire the last request on the ring, before we ever access that
ring again we know it will be completely idle and so we can advance the
ring->head fully to the end (i.e. ring->tail) and not just to the start
of the breadcrumb. This allows us to skip re-emitting the breadcrumb
after resetting the GPU if the ring was entirely idle. This prevents us
from overwriting a seqno wraparound by re-executing a stale breadcrumb,
i.e.
submit_request(1)
intel_engine_init_global_seqno(0)
i915_reset()
would then leave 1 in the HWS, but the next request to execute would
also be with seqno 1. The sanity checks upon submission detect this as a
timewarp and explode. By setting the ring as empty, upon reset the HWS
is left as 0, leaving it consistent with the timeline.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100144
Testcase: igt/gem_exec_whisper/hang-*
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 2f8c5132b54e..2cc090ee1440 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -295,8 +295,11 @@ static void i915_gem_request_retire(struct 
drm_i915_gem_request *request)
 * Note this requires that we are always called in request
 * completion order.
 */
+   if (request->ring_link.prev == >ring->request_list)
+   request->ring->head = request->ring->tail;
+   else
+   request->ring->head = request->postfix;
list_del(>ring_link);
-   request->ring->head = request->postfix;
if (!--request->i915->gt.active_requests) {
GEM_BUG_ON(!request->i915->gt.awake);
mod_delayed_work(request->i915->wq,
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Assert the engine is idle before overwiting the HWS

[Chris Wilson]

When we update the global seqno (on the engine timeline), we modify HW
state (both registers and mapped pages). As we do this, we should be
sure that the HW is idle and we are not causing a conflict. The caller
is supposed to wait_for_idle before calling us to update the seqno, so
let's assert they have and the engine is indeed idle.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_request.c | 2 +-
 drivers/gpu/drm/i915/intel_engine_cs.c  | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 6348353b91ec..2f8c5132b54e 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -214,8 +214,8 @@ static int reset_all_global_seqno(struct drm_i915_private 
*i915, u32 seqno)
}
 
/* Finally reset hw state */
-   tl->seqno = seqno;
intel_engine_init_global_seqno(engine, seqno);
+   tl->seqno = seqno;
 
list_for_each_entry(timeline, >gt.timelines, link)
memset(timeline->engine[id].sync_seqno, 0,
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 854e8e0c836b..92f871cf3265 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -223,6 +223,8 @@ void intel_engine_init_global_seqno(struct intel_engine_cs 
*engine, u32 seqno)
 {
struct drm_i915_private *dev_priv = engine->i915;
 
+   GEM_BUG_ON(!intel_engine_is_idle(engine));
+
/* Our semaphore implementation is strictly monotonic (i.e. we proceed
 * so long as the semaphore value in the register/page is greater
 * than the sync value), so whenever we reset the seqno,
@@ -260,6 +262,8 @@ void intel_engine_init_global_seqno(struct intel_engine_cs 
*engine, u32 seqno)
 * there are any waiters for that seqno.
 */
intel_engine_wakeup(engine);
+
+   GEM_BUG_ON(intel_engine_get_seqno(engine) != seqno);
 }
 
 static void intel_engine_init_timeline(struct intel_engine_cs *engine)
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/18] drm/i915: introduce ppgtt page coloring

[Matthew Auld]

On 5 April 2017 at 15:02, Chris Wilson  wrote:
> On Wed, Apr 05, 2017 at 02:50:41PM +0100, Matthew Auld wrote:
>> On 5 April 2017 at 14:41, Chris Wilson  wrote:
>> > On Tue, Apr 04, 2017 at 11:11:17PM +0100, Matthew Auld wrote:
>> >> To enable 64K pages we need to set the intermediate-page-size(IPS) bit
>> >> of the pde, therefore a page table is said to be either operating in 64K
>> >> or 4K mode. To accommodate this vm placement restriction we introduce a
>> >> color for pages and corresponding color_adjust callback.
>> >>
>> >> Signed-off-by: Matthew Auld 
>> >> ---
>> >>  drivers/gpu/drm/i915/i915_gem_gtt.c | 25 +
>> >>  drivers/gpu/drm/i915/i915_gem_gtt.h |  6 ++
>> >>  drivers/gpu/drm/i915/i915_vma.c |  2 ++
>> >>  3 files changed, 33 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
>> >> b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> >> index 0989af4a17e4..ddc3db345b76 100644
>> >> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> >> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> >> @@ -1332,6 +1332,28 @@ static int gen8_preallocate_top_level_pdp(struct 
>> >> i915_hw_ppgtt *ppgtt)
>> >>   return -ENOMEM;
>> >>  }
>> >>
>> >> +static void i915_page_color_adjust(const struct drm_mm_node *node,
>> >> +unsigned long color,
>> >> +u64 *start,
>> >> +u64 *end)
>> >> +{
>> >> + GEM_BUG_ON(!is_valid_gtt_page_size(color));
>> >> +
>> >> + if (!(color & (I915_GTT_PAGE_SIZE_4K | I915_GTT_PAGE_SIZE_64K)))
>> >> + return;
>> >> +
>> >> + GEM_BUG_ON(node->allocated && !is_valid_gtt_page_size(node->color));
>> >> +
>> >> + if (i915_node_color_differs(node, color))
>> >> + *start = roundup(*start, 1 << GEN8_PDE_SHIFT);
>> >> +
>> >> + node = list_next_entry(node, node_list);
>> >> + if (i915_node_color_differs(node, color))
>> >> + *end = rounddown(*end, 1 << GEN8_PDE_SHIFT);
>> >> +
>> >> + GEM_BUG_ON(node->allocated && !is_valid_gtt_page_size(node->color));
>> >> +}
>> >> +
>> >>  /*
>> >>   * GEN8 legacy ppgtt programming is accomplished through a max 4 PDP 
>> >> registers
>> >>   * with a net effect resembling a 2-level page table in normal x86 
>> >> terms. Each
>> >> @@ -1372,6 +1394,9 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt 
>> >> *ppgtt)
>> >>   ppgtt->base.allocate_va_range = gen8_ppgtt_alloc_4lvl;
>> >>   ppgtt->base.insert_entries = gen8_ppgtt_insert_4lvl;
>> >>   ppgtt->base.clear_range = gen8_ppgtt_clear_4lvl;
>> >> +
>> >> + if (SUPPORTS_PAGE_SIZE(dev_priv, I915_GTT_PAGE_SIZE_64K))
>> >> + ppgtt->base.mm.color_adjust = 
>> >> i915_page_color_adjust;
>> >>   } else {
>> >>   ret = __pdp_init(>base, >pdp);
>> >>   if (ret)
>> >> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
>> >> b/drivers/gpu/drm/i915/i915_gem_gtt.h
>> >> index 9c592e2de516..8d893ddd98f2 100644
>> >> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
>> >> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
>> >> @@ -353,6 +353,12 @@ i915_vm_has_cache_coloring(const struct 
>> >> i915_address_space *vm)
>> >>  }
>> >>
>> >>  static inline bool
>> >> +i915_vm_has_page_coloring(const struct i915_address_space *vm)
>> >> +{
>> >> + return vm->mm.color_adjust && !i915_is_ggtt(vm);
>> >> +}
>> >> +
>> >> +static inline bool
>> >>  i915_vm_is_48bit(const struct i915_address_space *vm)
>> >>  {
>> >>   return (vm->total - 1) >> 32;
>> >> diff --git a/drivers/gpu/drm/i915/i915_vma.c 
>> >> b/drivers/gpu/drm/i915/i915_vma.c
>> >> index 8f0041ba328f..4043145b4310 100644
>> >> --- a/drivers/gpu/drm/i915/i915_vma.c
>> >> +++ b/drivers/gpu/drm/i915/i915_vma.c
>> >> @@ -471,6 +471,8 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
>> >> alignment, u64 flags)
>> >>
>> >>   if (i915_vm_has_cache_coloring(vma->vm))
>> >>   color = obj->cache_level;
>> >> + else if (i915_vm_has_page_coloring(vma->vm))
>> >> + color = obj->gtt_page_size;
>> >
>> > This does not need color_adjust since you are just specifying an
>> > alignment and size. Why the extra complications? I remember asking the
>> > same last time.
>> Hmm, are you saying the whole idea of needing a color_adjust for
>> 4K/64K vm placement is completely unnecessary?
>
> As constructed here, yes. Since you just want to request a
> obj->gtt_page_size aligned block:
>
> .size = round_up(size, obj->gtt_page_size),
> .align = max(align, obj->gtt_page_size).
Unless I've gone completely mad, I really don't think it's that
simple, we never ever want a 4K object or 64K object to overlap the
same page-table. We derive the pde and hence the page-table from
node.start, so if we just request an obj->gtt_page_size aligned block,
we could have a page-table with a mixture of 64K 

Re: [Intel-gfx] [PATCH 07/18] drm/i915: introduce ppgtt page coloring

[Chris Wilson]

On Wed, Apr 05, 2017 at 02:50:41PM +0100, Matthew Auld wrote:
> On 5 April 2017 at 14:41, Chris Wilson  wrote:
> > On Tue, Apr 04, 2017 at 11:11:17PM +0100, Matthew Auld wrote:
> >> To enable 64K pages we need to set the intermediate-page-size(IPS) bit
> >> of the pde, therefore a page table is said to be either operating in 64K
> >> or 4K mode. To accommodate this vm placement restriction we introduce a
> >> color for pages and corresponding color_adjust callback.
> >>
> >> Signed-off-by: Matthew Auld 
> >> ---
> >>  drivers/gpu/drm/i915/i915_gem_gtt.c | 25 +
> >>  drivers/gpu/drm/i915/i915_gem_gtt.h |  6 ++
> >>  drivers/gpu/drm/i915/i915_vma.c |  2 ++
> >>  3 files changed, 33 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> >> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >> index 0989af4a17e4..ddc3db345b76 100644
> >> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> >> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> >> @@ -1332,6 +1332,28 @@ static int gen8_preallocate_top_level_pdp(struct 
> >> i915_hw_ppgtt *ppgtt)
> >>   return -ENOMEM;
> >>  }
> >>
> >> +static void i915_page_color_adjust(const struct drm_mm_node *node,
> >> +unsigned long color,
> >> +u64 *start,
> >> +u64 *end)
> >> +{
> >> + GEM_BUG_ON(!is_valid_gtt_page_size(color));
> >> +
> >> + if (!(color & (I915_GTT_PAGE_SIZE_4K | I915_GTT_PAGE_SIZE_64K)))
> >> + return;
> >> +
> >> + GEM_BUG_ON(node->allocated && !is_valid_gtt_page_size(node->color));
> >> +
> >> + if (i915_node_color_differs(node, color))
> >> + *start = roundup(*start, 1 << GEN8_PDE_SHIFT);
> >> +
> >> + node = list_next_entry(node, node_list);
> >> + if (i915_node_color_differs(node, color))
> >> + *end = rounddown(*end, 1 << GEN8_PDE_SHIFT);
> >> +
> >> + GEM_BUG_ON(node->allocated && !is_valid_gtt_page_size(node->color));
> >> +}
> >> +
> >>  /*
> >>   * GEN8 legacy ppgtt programming is accomplished through a max 4 PDP 
> >> registers
> >>   * with a net effect resembling a 2-level page table in normal x86 terms. 
> >> Each
> >> @@ -1372,6 +1394,9 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt 
> >> *ppgtt)
> >>   ppgtt->base.allocate_va_range = gen8_ppgtt_alloc_4lvl;
> >>   ppgtt->base.insert_entries = gen8_ppgtt_insert_4lvl;
> >>   ppgtt->base.clear_range = gen8_ppgtt_clear_4lvl;
> >> +
> >> + if (SUPPORTS_PAGE_SIZE(dev_priv, I915_GTT_PAGE_SIZE_64K))
> >> + ppgtt->base.mm.color_adjust = i915_page_color_adjust;
> >>   } else {
> >>   ret = __pdp_init(>base, >pdp);
> >>   if (ret)
> >> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
> >> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> >> index 9c592e2de516..8d893ddd98f2 100644
> >> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> >> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> >> @@ -353,6 +353,12 @@ i915_vm_has_cache_coloring(const struct 
> >> i915_address_space *vm)
> >>  }
> >>
> >>  static inline bool
> >> +i915_vm_has_page_coloring(const struct i915_address_space *vm)
> >> +{
> >> + return vm->mm.color_adjust && !i915_is_ggtt(vm);
> >> +}
> >> +
> >> +static inline bool
> >>  i915_vm_is_48bit(const struct i915_address_space *vm)
> >>  {
> >>   return (vm->total - 1) >> 32;
> >> diff --git a/drivers/gpu/drm/i915/i915_vma.c 
> >> b/drivers/gpu/drm/i915/i915_vma.c
> >> index 8f0041ba328f..4043145b4310 100644
> >> --- a/drivers/gpu/drm/i915/i915_vma.c
> >> +++ b/drivers/gpu/drm/i915/i915_vma.c
> >> @@ -471,6 +471,8 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
> >> alignment, u64 flags)
> >>
> >>   if (i915_vm_has_cache_coloring(vma->vm))
> >>   color = obj->cache_level;
> >> + else if (i915_vm_has_page_coloring(vma->vm))
> >> + color = obj->gtt_page_size;
> >
> > This does not need color_adjust since you are just specifying an
> > alignment and size. Why the extra complications? I remember asking the
> > same last time.
> Hmm, are you saying the whole idea of needing a color_adjust for
> 4K/64K vm placement is completely unnecessary?

As constructed here, yes. Since you just want to request a
obj->gtt_page_size aligned block:

.size = round_up(size, obj->gtt_page_size),
.align = max(align, obj->gtt_page_size).

(Hmm, now I think about it you shouldn't round size up unless the
insert_pages() is careful not to assume that the last page is a full
superpage. More I think about this, you only want to align the base and
let insert_pages group up the superpages.)

Unless I have completely misunderstood, you do not need to insert
gaps between blocks. Both the color_adjust approach and this approach
still need lower level support to amalgamate pages.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] [PATCH 07/18] drm/i915: introduce ppgtt page coloring

[Matthew Auld]

On 5 April 2017 at 14:41, Chris Wilson  wrote:
> On Tue, Apr 04, 2017 at 11:11:17PM +0100, Matthew Auld wrote:
>> To enable 64K pages we need to set the intermediate-page-size(IPS) bit
>> of the pde, therefore a page table is said to be either operating in 64K
>> or 4K mode. To accommodate this vm placement restriction we introduce a
>> color for pages and corresponding color_adjust callback.
>>
>> Signed-off-by: Matthew Auld 
>> ---
>>  drivers/gpu/drm/i915/i915_gem_gtt.c | 25 +
>>  drivers/gpu/drm/i915/i915_gem_gtt.h |  6 ++
>>  drivers/gpu/drm/i915/i915_vma.c |  2 ++
>>  3 files changed, 33 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
>> b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> index 0989af4a17e4..ddc3db345b76 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
>> @@ -1332,6 +1332,28 @@ static int gen8_preallocate_top_level_pdp(struct 
>> i915_hw_ppgtt *ppgtt)
>>   return -ENOMEM;
>>  }
>>
>> +static void i915_page_color_adjust(const struct drm_mm_node *node,
>> +unsigned long color,
>> +u64 *start,
>> +u64 *end)
>> +{
>> + GEM_BUG_ON(!is_valid_gtt_page_size(color));
>> +
>> + if (!(color & (I915_GTT_PAGE_SIZE_4K | I915_GTT_PAGE_SIZE_64K)))
>> + return;
>> +
>> + GEM_BUG_ON(node->allocated && !is_valid_gtt_page_size(node->color));
>> +
>> + if (i915_node_color_differs(node, color))
>> + *start = roundup(*start, 1 << GEN8_PDE_SHIFT);
>> +
>> + node = list_next_entry(node, node_list);
>> + if (i915_node_color_differs(node, color))
>> + *end = rounddown(*end, 1 << GEN8_PDE_SHIFT);
>> +
>> + GEM_BUG_ON(node->allocated && !is_valid_gtt_page_size(node->color));
>> +}
>> +
>>  /*
>>   * GEN8 legacy ppgtt programming is accomplished through a max 4 PDP 
>> registers
>>   * with a net effect resembling a 2-level page table in normal x86 terms. 
>> Each
>> @@ -1372,6 +1394,9 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
>>   ppgtt->base.allocate_va_range = gen8_ppgtt_alloc_4lvl;
>>   ppgtt->base.insert_entries = gen8_ppgtt_insert_4lvl;
>>   ppgtt->base.clear_range = gen8_ppgtt_clear_4lvl;
>> +
>> + if (SUPPORTS_PAGE_SIZE(dev_priv, I915_GTT_PAGE_SIZE_64K))
>> + ppgtt->base.mm.color_adjust = i915_page_color_adjust;
>>   } else {
>>   ret = __pdp_init(>base, >pdp);
>>   if (ret)
>> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
>> b/drivers/gpu/drm/i915/i915_gem_gtt.h
>> index 9c592e2de516..8d893ddd98f2 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
>> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
>> @@ -353,6 +353,12 @@ i915_vm_has_cache_coloring(const struct 
>> i915_address_space *vm)
>>  }
>>
>>  static inline bool
>> +i915_vm_has_page_coloring(const struct i915_address_space *vm)
>> +{
>> + return vm->mm.color_adjust && !i915_is_ggtt(vm);
>> +}
>> +
>> +static inline bool
>>  i915_vm_is_48bit(const struct i915_address_space *vm)
>>  {
>>   return (vm->total - 1) >> 32;
>> diff --git a/drivers/gpu/drm/i915/i915_vma.c 
>> b/drivers/gpu/drm/i915/i915_vma.c
>> index 8f0041ba328f..4043145b4310 100644
>> --- a/drivers/gpu/drm/i915/i915_vma.c
>> +++ b/drivers/gpu/drm/i915/i915_vma.c
>> @@ -471,6 +471,8 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
>> alignment, u64 flags)
>>
>>   if (i915_vm_has_cache_coloring(vma->vm))
>>   color = obj->cache_level;
>> + else if (i915_vm_has_page_coloring(vma->vm))
>> + color = obj->gtt_page_size;
>
> This does not need color_adjust since you are just specifying an
> alignment and size. Why the extra complications? I remember asking the
> same last time.
Hmm, are you saying the whole idea of needing a color_adjust for
4K/64K vm placement is completely unnecessary?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/3] drm/i915: Fix SKL+ 90/270 degree rotated scanout

[Ville Syrjälä]

On Fri, Mar 31, 2017 at 10:23:18PM +0100, Chris Wilson wrote:
> On Fri, Mar 31, 2017 at 09:00:53PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> > 
> > I figured it's about time I fix what I broke with my fb offset stuff.
> > I've posted the scaler thing before, but the watermark and fbc stuff
> > is new.
> > 
> > Based on some quick tests the WM fixes seem effective. Or at least
> > underruns seemed to disappear when I was running xonotic with 90/270
> > degree rotation.
> 
> The key question for me is would we be able to detect any of the errors
> in igt? How can we improve our testing?

The rotation test definitely would need some love. It fails to detect
these problems because it scans out a square image. Making it non-square
would at least catch the use of the scaler when it shouldn't be used.

Detecting the watermark breakage is less clear. I suppose making the
plane have a very wide or very tall aspect ratio might help induce
underruns with the broken wm code.

Another thing that may or may not be missing from the test is panning.
I'd also like to test scaling, but sadly our hardware makes that
rather hard by not allowing us to force nearest and/or linear filtering,
and bspec doesn't actually document what kind of algorithm the hardware
uses for the different filter modes.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/18] drm/i915: introduce ppgtt page coloring

[Chris Wilson]

On Tue, Apr 04, 2017 at 11:11:17PM +0100, Matthew Auld wrote:
> To enable 64K pages we need to set the intermediate-page-size(IPS) bit
> of the pde, therefore a page table is said to be either operating in 64K
> or 4K mode. To accommodate this vm placement restriction we introduce a
> color for pages and corresponding color_adjust callback.
> 
> Signed-off-by: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 25 +
>  drivers/gpu/drm/i915/i915_gem_gtt.h |  6 ++
>  drivers/gpu/drm/i915/i915_vma.c |  2 ++
>  3 files changed, 33 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 0989af4a17e4..ddc3db345b76 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -1332,6 +1332,28 @@ static int gen8_preallocate_top_level_pdp(struct 
> i915_hw_ppgtt *ppgtt)
>   return -ENOMEM;
>  }
>  
> +static void i915_page_color_adjust(const struct drm_mm_node *node,
> +unsigned long color,
> +u64 *start,
> +u64 *end)
> +{
> + GEM_BUG_ON(!is_valid_gtt_page_size(color));
> +
> + if (!(color & (I915_GTT_PAGE_SIZE_4K | I915_GTT_PAGE_SIZE_64K)))
> + return;
> +
> + GEM_BUG_ON(node->allocated && !is_valid_gtt_page_size(node->color));
> +
> + if (i915_node_color_differs(node, color))
> + *start = roundup(*start, 1 << GEN8_PDE_SHIFT);
> +
> + node = list_next_entry(node, node_list);
> + if (i915_node_color_differs(node, color))
> + *end = rounddown(*end, 1 << GEN8_PDE_SHIFT);
> +
> + GEM_BUG_ON(node->allocated && !is_valid_gtt_page_size(node->color));
> +}
> +
>  /*
>   * GEN8 legacy ppgtt programming is accomplished through a max 4 PDP 
> registers
>   * with a net effect resembling a 2-level page table in normal x86 terms. 
> Each
> @@ -1372,6 +1394,9 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
>   ppgtt->base.allocate_va_range = gen8_ppgtt_alloc_4lvl;
>   ppgtt->base.insert_entries = gen8_ppgtt_insert_4lvl;
>   ppgtt->base.clear_range = gen8_ppgtt_clear_4lvl;
> +
> + if (SUPPORTS_PAGE_SIZE(dev_priv, I915_GTT_PAGE_SIZE_64K))
> + ppgtt->base.mm.color_adjust = i915_page_color_adjust;
>   } else {
>   ret = __pdp_init(>base, >pdp);
>   if (ret)
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index 9c592e2de516..8d893ddd98f2 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -353,6 +353,12 @@ i915_vm_has_cache_coloring(const struct 
> i915_address_space *vm)
>  }
>  
>  static inline bool
> +i915_vm_has_page_coloring(const struct i915_address_space *vm)
> +{
> + return vm->mm.color_adjust && !i915_is_ggtt(vm);
> +}
> +
> +static inline bool
>  i915_vm_is_48bit(const struct i915_address_space *vm)
>  {
>   return (vm->total - 1) >> 32;
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 8f0041ba328f..4043145b4310 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -471,6 +471,8 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
> alignment, u64 flags)
>  
>   if (i915_vm_has_cache_coloring(vma->vm))
>   color = obj->cache_level;
> + else if (i915_vm_has_page_coloring(vma->vm))
> + color = obj->gtt_page_size;

This does not need color_adjust since you are just specifying an
alignment and size. Why the extra complications? I remember asking the
same last time.
-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 09/15] drm/msm: Nerf zpos property

[Daniel Vetter]

On Mon, Apr 03, 2017 at 10:32:58AM +0200, Daniel Vetter wrote:
> It's not wired up, and if it is, it should be moved over to the new
> fancy standardized zpos property exposed through
> drm_plane_create_zpos_property().
> 
> Cc: Rob Clark 
> Signed-off-by: Daniel Vetter 

Discussed this with Rob Clark on irc, I was wrong, this is all properly
wired up. No idea why I failed at parsing git grep output ... This should
be moved over to drm_plane_create_zpos_property(), but this patch here is
bogus. I'll drop it.
-Daniel

> ---
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
> b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> index 60a5451ae0b9..9229c6e201a2 100644
> --- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> +++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
> @@ -108,8 +108,6 @@ static void mdp5_plane_install_properties(struct 
> drm_plane *plane,
>   create_enum, name##_prop_enum_list, \
>   ARRAY_SIZE(name##_prop_enum_list))
>  
> - INSTALL_RANGE_PROPERTY(zpos, ZPOS, 1, 255, 1);
> -
>   mdp5_plane_install_rotation_property(dev, plane);
>  
>  #undef INSTALL_RANGE_PROPERTY
> -- 
> 2.11.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: limit pixel clock to 99% of cdclk workaround (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/glk: limit pixel clock to 99% of cdclk workaround (rev2)
URL   : https://patchwork.freedesktop.org/series/22404/
State : success

== Summary ==

Series 22404v2 drm/i915/glk: limit pixel clock to 99% of cdclk workaround
https://patchwork.freedesktop.org/api/1.0/series/22404/revisions/2/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
incomplete -> PASS   (fi-snb-2520m)

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 429s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 425s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time: 581s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 503s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 547s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time: 485s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 481s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 410s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 400s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 419s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 490s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 465s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 457s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time: 564s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 456s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 568s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 459s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 483s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 431s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 539s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time: 404s

3c5f424b9e2697352118ee33514b29b7cd57f69c drm-tip: 2017y-04m-05d-11h-46m-45s UTC 
integration manifest
6dbd9dc drm/i915/glk: limit pixel clock to 99% of cdclk workaround

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4408/
___
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: Only report a wakeup if the waiter was truly asleep (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Only report a wakeup if the waiter was truly asleep (rev2)
URL   : https://patchwork.freedesktop.org/series/22445/
State : success

== Summary ==

Series 22445v2 drm/i915: Only report a wakeup if the waiter was truly asleep
https://patchwork.freedesktop.org/api/1.0/series/22445/revisions/2/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125
Test kms_pipe_crc_basic:
Subgroup hang-read-crc-pipe-a:
incomplete -> PASS   (fi-snb-2520m)

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 430s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 429s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time: 583s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 505s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 560s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time: 495s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 477s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 409s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 405s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 415s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 488s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 465s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 455s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 572s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 469s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 577s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 461s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 495s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 436s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 527s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 397s

3c5f424b9e2697352118ee33514b29b7cd57f69c drm-tip: 2017y-04m-05d-11h-46m-45s UTC 
integration manifest
b1843ef drm/i915: Only report a wakeup if the waiter was truly asleep

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4407/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Suspend GuC prior to GPU Reset during GEM suspend

[David Weinehall]

On 2017-04-05 15:54, Joonas Lahtinen wrote:

On ke, 2017-04-05 at 15:51 +0530, Sagar Arun Kamble wrote:

i915 is currently doing Full GPU reset at the end of suspend followed by
GuC suspend. This reset bypasses the GuC. We need to tell the GuC to
suspend before we do a direct intel_gpu_reset, Otherwise the gpu state will
no longer match the GuC's expectations and its suspend will not be
successful. With this change, i915 suspends GuC after suspending GEM and
before doing Full GPU reset.

+ David, Oscar and Michel

My understanding is that reloading GuC firmware after each resume is a
major bottleneck in resume time, and we instead should be telling GuC
to suspend and not reset the GPU, at most only reset the engines.

Regards, Joonas


If this is possible, then yes, it'd definitely be preferable. If not,
then doing the GuC + HuC loading asynchronously on resume would be 
preferable.

Anusha mentioned working on asynchronous loading, hence added to CC.


Kind regards, David
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 


This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround

[Madhav Chauhan]

As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz.
Practically we can achive only 99% of these cdclk values (HW team
checking on this). So cdclk should be calculated for the given pixclk as
per that otherwise it may lead to screen corruption, explained below:
1. For DSI AUO panel(1920x1200 @60) required pixclk is 157100 KHZ
2. glk_calc_cdclk returns 79200 KHZ for this pixclk, For 2PPC it
   will be 158400 KHZ
3. Practically 100% of the cdclk can’t be achieved, so 99% of 158400
   KHZ  = 156816 which is less than the desired pixlclk and causes
   panel corruption.

v2: Rebased to new CDLCK code framework
v3: Addressed review comments from Ander/Jani
- Add comment in code about 99% usage of CDCLK
- Calculate max dot clock as well with 99% limit
v4 by Jani:
- drop superfluous whitespace change
- rewrite code comments to clarify
v5: Added details of non-working scenario in commit message

Cc: Ander Conselvan de Oliveira 
Cc: Ville Syrjälä 
Signed-off-by: Madhav Chauhan 
Signed-off-by: Jani Nikula 
Reviewed-by: Ander Conselvan de Oliveira 
---
 drivers/gpu/drm/i915/intel_cdclk.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index dd3ad52..763010f 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1071,9 +1071,15 @@ static int bxt_calc_cdclk(int max_pixclk)
 
 static int glk_calc_cdclk(int max_pixclk)
 {
-   if (max_pixclk > 2 * 158400)
+   /*
+* FIXME: Avoid using a pixel clock that is more than 99% of the cdclk
+* as a temporary workaround. Use a higher cdclk instead. (Note that
+* intel_compute_max_dotclk() limits the max pixel clock to 99% of max
+* cdclk.)
+*/
+   if (max_pixclk > DIV_ROUND_UP(2 * 158400 * 99, 100))
return 316800;
-   else if (max_pixclk > 2 * 79200)
+   else if (max_pixclk > DIV_ROUND_UP(2 * 79200 * 99, 100))
return 158400;
else
return 79200;
@@ -1664,7 +1670,11 @@ static int intel_compute_max_dotclk(struct 
drm_i915_private *dev_priv)
int max_cdclk_freq = dev_priv->max_cdclk_freq;
 
if (IS_GEMINILAKE(dev_priv))
-   return 2 * max_cdclk_freq;
+   /*
+* FIXME: Limiting to 99% as a temporary workaround. See
+* glk_calc_cdclk() for details.
+*/
+   return 2 * max_cdclk_freq * 99 / 100;
else if (INTEL_INFO(dev_priv)->gen >= 9 ||
 IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
return max_cdclk_freq;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/1] drm/i915: Suspend GuC prior to GPU Reset during GEM suspend

[Chris Wilson]

On Wed, Apr 05, 2017 at 03:54:27PM +0300, Joonas Lahtinen wrote:
> On ke, 2017-04-05 at 15:51 +0530, Sagar Arun Kamble wrote:
> > i915 is currently doing Full GPU reset at the end of suspend followed by
> > GuC suspend. This reset bypasses the GuC. We need to tell the GuC to
> > suspend before we do a direct intel_gpu_reset, Otherwise the gpu state will
> > no longer match the GuC's expectations and its suspend will not be
> > successful. With this change, i915 suspends GuC after suspending GEM and
> > before doing Full GPU reset.
> 
> + David, Oscar and Michel
> 
> My understanding is that reloading GuC firmware after each resume is a
> major bottleneck in resume time, and we instead should be telling GuC
> to suspend and not reset the GPU, at most only reset the engines.

resetting the gpu is for robustness, to make sure that the gpu is truly
inactive after we lose control. Now you might argue to move that to only
the hibernate paths, but paranoia says to do it before the bios is
invovled on suspend.

We do not need to wait for firmware to load, on init or resume, along
with most things we can do it asynchronously. We could even start
userspace with execlists and then switch to guc, if firmware loading was
that slow (or just the firmware was non-existent e.g. builtin with no
initrd).
-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 01/18] drm/i915: add page_size_mask to dev_info

[Joonas Lahtinen]

On ke, 2017-04-05 at 09:45 +0100, Chris Wilson wrote:
> 
> Also not in this patch. First patch is to set everything to the status
> quo. Last patch will be to enable the (completed) feature on the
> platforms using. In testing, that enabling patch comes early on to check
> bisection of the series.

Except if the feature is implemented in increments, but I already
mentioned in another patch that the ordering could be shuffled to allow
for easier review (which will lead to easier bisecting, too).

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 v2 1/1] drm/i915: Suspend GuC prior to GPU Reset during GEM suspend

[Joonas Lahtinen]

On ke, 2017-04-05 at 15:51 +0530, Sagar Arun Kamble wrote:
> i915 is currently doing Full GPU reset at the end of suspend followed by
> GuC suspend. This reset bypasses the GuC. We need to tell the GuC to
> suspend before we do a direct intel_gpu_reset, Otherwise the gpu state will
> no longer match the GuC's expectations and its suspend will not be
> successful. With this change, i915 suspends GuC after suspending GEM and
> before doing Full GPU reset.

+ David, Oscar and Michel

My understanding is that reloading GuC firmware after each resume is a
major bottleneck in resume time, and we instead should be telling GuC
to suspend and not reset the GPU, at most only reset the engines.

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

[Intel-gfx] [PATCH v2] drm/i915: Only report a wakeup if the waiter was truly asleep

[Chris Wilson]

If we attempt to wake up a waiter, who is currently checking the seqno
it will be in the TASK_INTERRUPTIBLE state and ttwu will report success.
However, it is actually awake and functioning -- so delay reporting the
actual wake up until it sleeps.

v2: Defend against !CONFIG_SMP

References: https://bugs.freedesktop.org/show_bug.cgi?id=17
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 9ccbf26124c6..4fdf7868e2f1 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -27,6 +27,23 @@
 
 #include "i915_drv.h"
 
+#ifdef CONFIG_SMP
+#define task_asleep(tsk) (!(tsk)->on_cpu)
+#else
+#define task_asleep(tsk) ((tsk) != current)
+#endif
+
+static inline bool __wake_up_sleeper(struct task_struct *tsk)
+{
+   /* Be careful not to report a successful wakeup if the waiter is
+* currently processing the seqno, where it will have already
+* called set_task_state(TASK_INTERRUPTIBLE). We first check whether
+* the task is currently asleep before calling ttwu, and then we
+* only report success if we were the ones to then trigger the wakeup.
+*/
+   return task_asleep(tsk) && wake_up_process(tsk);
+}
+
 static unsigned int __intel_breadcrumbs_wakeup(struct intel_breadcrumbs *b)
 {
struct intel_wait *wait;
@@ -37,7 +54,7 @@ static unsigned int __intel_breadcrumbs_wakeup(struct 
intel_breadcrumbs *b)
wait = b->irq_wait;
if (wait) {
result = ENGINE_WAKEUP_WAITER;
-   if (wake_up_process(wait->tsk))
+   if (__wake_up_sleeper(wait->tsk))
result |= ENGINE_WAKEUP_ASLEEP;
}
 
@@ -198,7 +215,7 @@ void intel_engine_disarm_breadcrumbs(struct intel_engine_cs 
*engine)
 
rbtree_postorder_for_each_entry_safe(wait, n, >waiters, node) {
RB_CLEAR_NODE(>node);
-   if (wake_up_process(wait->tsk) && wait == first)
+   if (__wake_up_sleeper(wait->tsk) && wait == first)
missed_breadcrumb(engine);
}
b->waiters = RB_ROOT;
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/18] drm/i915: introduce drm_i915_gem_object page_size members

[Chris Wilson]

On Wed, Apr 05, 2017 at 01:32:30PM +0100, Chris Wilson wrote:
> An approach that might be interesting. On pinning the pages
> (i.e. ops->get_pages) if we fill in the bitmask of page sizes, something
> like
> 
> for_each_sg() {
>   obj->mm.page_sizes |= fls(sg->length);
> 
> obj->mm.pages_sizes &= ~i915->info.page_sizes;

Well, that was written in haste. You'll need a precomputed translation
table to map the order to the nearest supported page size.
-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 02/18] drm/i915: introduce drm_i915_gem_object page_size members

[Chris Wilson]

On Wed, Apr 05, 2017 at 11:07:55AM +0100, Matthew Auld wrote:
> On 04/05, Chris Wilson wrote:
> > On Wed, Apr 05, 2017 at 08:49:17AM +0200, Daniel Vetter wrote:
> > > On Tue, Apr 04, 2017 at 11:11:12PM +0100, Matthew Auld wrote:
> > > > diff --git a/drivers/gpu/drm/i915/i915_gem_object.h 
> > > > b/drivers/gpu/drm/i915/i915_gem_object.h
> > > > index 174cf923c236..b1dacbfe5173 100644
> > > > --- a/drivers/gpu/drm/i915/i915_gem_object.h
> > > > +++ b/drivers/gpu/drm/i915/i915_gem_object.h
> > > > @@ -107,6 +107,9 @@ struct drm_i915_gem_object {
> > > > unsigned int cache_level:3;
> > > > unsigned int cache_dirty:1;
> > > >  
> > > > +   unsigned int page_size; /* CPU pov - 4K(default), 2M, 1G */
> > > > +   unsigned int gtt_page_size; /* GPU pov - 4K(default), 64K, 2M, 
> > > > 1G */
> > > 
> > > Just kinda archecture review, with a long-term view: Is the plan to
> > > eventually become more flexible here, i.e. allow mixed mode?
> > 
> > Simply put we can not support obj->page_size. Every object will be
> > composed of a mixture of page sizes, often outside of our control and
> > those page sizes may vary over the lifetime of the object.
> > 
> > Trying to design around an a priori static page_size is a bad idea, imo.
> 
> I think I've misrepresented the intention of obj->page_size, it merely
> serves as a hint to get pages, thereafter it represents the minimum page
> size in the mapping and is just bookkeeping, so mixed pages are totally
> fine and expected. I mostly wanted it to make it clear to the reader
> that we have a gtt and cpu page size. I also wanted to know if an object
> is entirely composed of huge-pages for debugfs purposes. I'll try to
> rework this to make it less terrible.

An approach that might be interesting. On pinning the pages
(i.e. ops->get_pages) if we fill in the bitmask of page sizes, something
like

for_each_sg() {
obj->mm.page_sizes |= fls(sg->length);

obj->mm.pages_sizes &= ~i915->info.page_sizes;

Then in insert_pages or probably better as vma_insert:

gtt_page_alignment = fls(obj->mm.page_sizes);

I think that will be useful info even prior to trying to put it to good
use, i.e. that will be enough to start dumping debugfs stats over how
frequently we get large allocations.
-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 v2 1/1] drm/i915: Suspend GuC prior to GPU Reset during GEM suspend

[Chris Wilson]

On Wed, Apr 05, 2017 at 03:51:50PM +0530, Sagar Arun Kamble wrote:
> i915 is currently doing Full GPU reset at the end of suspend followed by
> GuC suspend. This reset bypasses the GuC. We need to tell the GuC to
> suspend before we do a direct intel_gpu_reset, Otherwise the gpu state will
> no longer match the GuC's expectations and its suspend will not be
> successful. With this change, i915 suspends GuC after suspending GEM and
> before doing Full GPU reset.

I'll massage the commit message slightly (much easier when proofreading
someone else's writing). It makes sense to me, any takers from those who
know guc more intimately or at least have observed and tested this patch?
-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 report a wakeup if the waiter was truly asleep

[kbuild test robot]

Hi Chris,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20170405]
[cannot apply to v4.11-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Only-report-a-wakeup-if-the-waiter-was-truly-asleep/20170405-165353
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-sb0-04050506 (attached as .config)
compiler: gcc-5 (Debian 5.4.1-2) 5.4.1 20160904
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_breadcrumbs.c: In function '__wake_up_sleeper':
>> drivers/gpu/drm/i915/intel_breadcrumbs.c:38:13: error: 'struct task_struct' 
>> has no member named 'on_cpu'
 return !tsk->on_cpu && wake_up_process(tsk);
^
   drivers/gpu/drm/i915/intel_breadcrumbs.c:39:1: warning: control reaches end 
of non-void function [-Wreturn-type]
}
^

vim +38 drivers/gpu/drm/i915/intel_breadcrumbs.c

32  /* Be careful not to report a successful wakeup if the waiter is
33   * currently processing the seqno, where it will have already
34   * called set_task_state(TASK_INTERRUPTIBLE). We first check 
whether
35   * the task is currently asleep before calling ttwu, and then we
36   * only report success if we were the ones to then trigger the 
wakeup.
37   */
  > 38  return !tsk->on_cpu && wake_up_process(tsk);
39  }
40  
41  static unsigned int __intel_breadcrumbs_wakeup(struct intel_breadcrumbs 
*b)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/18] drm/i915: introduce drm_i915_gem_object page_size members

[Daniel Vetter]

On Wed, Apr 05, 2017 at 11:07:55AM +0100, Matthew Auld wrote:
> On 04/05, Chris Wilson wrote:
> > On Wed, Apr 05, 2017 at 08:49:17AM +0200, Daniel Vetter wrote:
> > > On Tue, Apr 04, 2017 at 11:11:12PM +0100, Matthew Auld wrote:
> > > > Signed-off-by: Matthew Auld 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_gem.c| 5 +
> > > >  drivers/gpu/drm/i915/i915_gem_object.h | 3 +++
> > > >  2 files changed, 8 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > > > b/drivers/gpu/drm/i915/i915_gem.c
> > > > index 4ca88f2539c0..cbf97f4bbb72 100644
> > > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > > @@ -2441,6 +2441,8 @@ static int i915_gem_object_get_pages(struct 
> > > > drm_i915_gem_object *obj)
> > > > struct sg_table *pages;
> > > >  
> > > > GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
> > > > +   GEM_BUG_ON(!is_valid_gtt_page_size(obj->page_size));
> > > > +   GEM_BUG_ON(!is_valid_gtt_page_size(obj->gtt_page_size));
> > > >  
> > > > if (unlikely(obj->mm.madv != I915_MADV_WILLNEED)) {
> > > > DRM_DEBUG("Attempting to obtain a purgeable object\n");
> > > > @@ -4159,6 +4161,9 @@ void i915_gem_object_init(struct 
> > > > drm_i915_gem_object *obj,
> > > >  
> > > > obj->ops = ops;
> > > >  
> > > > +   obj->page_size = PAGE_SIZE;
> > > > +   obj->gtt_page_size = I915_GTT_PAGE_SIZE;
> > > > +
> > > > reservation_object_init(>__builtin_resv);
> > > > obj->resv = >__builtin_resv;
> > > >  
> > > > diff --git a/drivers/gpu/drm/i915/i915_gem_object.h 
> > > > b/drivers/gpu/drm/i915/i915_gem_object.h
> > > > index 174cf923c236..b1dacbfe5173 100644
> > > > --- a/drivers/gpu/drm/i915/i915_gem_object.h
> > > > +++ b/drivers/gpu/drm/i915/i915_gem_object.h
> > > > @@ -107,6 +107,9 @@ struct drm_i915_gem_object {
> > > > unsigned int cache_level:3;
> > > > unsigned int cache_dirty:1;
> > > >  
> > > > +   unsigned int page_size; /* CPU pov - 4K(default), 2M, 1G */
> > > > +   unsigned int gtt_page_size; /* GPU pov - 4K(default), 64K, 2M, 
> > > > 1G */
> > > 
> > > Just kinda archecture review, with a long-term view: Is the plan to
> > > eventually become more flexible here, i.e. allow mixed mode?
> > 
> > Simply put we can not support obj->page_size. Every object will be
> > composed of a mixture of page sizes, often outside of our control and
> > those page sizes may vary over the lifetime of the object.
> > 
> > Trying to design around an a priori static page_size is a bad idea, imo.
> 
> I think I've misrepresented the intention of obj->page_size, it merely
> serves as a hint to get pages, thereafter it represents the minimum page
> size in the mapping and is just bookkeeping, so mixed pages are totally
> fine and expected. I mostly wanted it to make it clear to the reader
> that we have a gtt and cpu page size. I also wanted to know if an object
> is entirely composed of huge-pages for debugfs purposes. I'll try to
> rework this to make it less terrible.

But if you already handle mixed pages, why do we need this still? Viz.
this thread, it does seem to cause quite a bit of confusion.

And I have no idea why we need the cpu_page_size, we kmap at the page
level anyway, and shmem handles the cpu mmap stuff for us.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH maintainer-tools 3/3] dim.rst: update CONTRIBUTING instructions

[Daniel Vetter]

On Wed, Apr 05, 2017 at 12:15:25PM +0100, Eric Engestrom wrote:
> Suggest using git-config instead of a flag on format-patch.
> While at it, use the more common "PATCH foo" subject prefix.
> 
> Signed-off-by: Eric Engestrom 
> ---
>  dim.rst | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/dim.rst b/dim.rst
> index b99248e..c650317 100644
> --- a/dim.rst
> +++ b/dim.rst
> @@ -476,10 +476,11 @@ CONTRIBUTING
>  
>  
>  Submit patches for any of the maintainer tools to the
> -intel-gfx@lists.freedesktop.org mailing list with [maintainer-tools PATCH]
> +intel-gfx@lists.freedesktop.org mailing list with [PATCH maintainer-tools]
>  prefix. Use::
>  
> -  $ git format-patch --subject-prefix="maintainer-tools PATCH"
> +  $ git config sendemail.to intel-gfx@lists.freedesktop.org
> +  $ git config format.subjectprefix 'PATCH maintainer-tools'

With dim this is a worktree checkout, which means all kernel patches end
up looking like this. Can we make this branch-specific?
-Daniel

>  
>  for that. Please make sure your patches pass the build and self tests by
>  running::
> -- 
> Cheers,
>   Eric
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH maintainer-tools 1/3] make: run check on current `dim`, not the installed one

[Jani Nikula]

On Wed, 05 Apr 2017, Eric Engestrom  wrote:
> Signed-off-by: Eric Engestrom 

For me "current dim" *is* the "installed one". ;)

Pushed patches 1-2.

BR,
Jani.

> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index b4cea98..4291049 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -33,7 +33,7 @@ shellcheck:
>   shellcheck $(SC_EXCLUDE) dim bash_completion
>  
>  mancheck:
> - @for cmd in $$(dim list-commands); do \
> + @for cmd in $$(./dim list-commands); do \
>   if ! grep -q "^$$cmd" dim.rst; then \
>   echo "$@: $$cmd not documented"; \
>   fi \

-- 
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 maintainer-tools 3/3] dim.rst: update CONTRIBUTING instructions

[Jani Nikula]

On Wed, 05 Apr 2017, Eric Engestrom  wrote:
> Suggest using git-config instead of a flag on format-patch.
> While at it, use the more common "PATCH foo" subject prefix.

More common? That's all so subjective.

And I've mostly used [dim PATCH]...

BR,
Jani.

>
> Signed-off-by: Eric Engestrom 
> ---
>  dim.rst | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/dim.rst b/dim.rst
> index b99248e..c650317 100644
> --- a/dim.rst
> +++ b/dim.rst
> @@ -476,10 +476,11 @@ CONTRIBUTING
>  
>  
>  Submit patches for any of the maintainer tools to the
> -intel-gfx@lists.freedesktop.org mailing list with [maintainer-tools PATCH]
> +intel-gfx@lists.freedesktop.org mailing list with [PATCH maintainer-tools]
>  prefix. Use::
>  
> -  $ git format-patch --subject-prefix="maintainer-tools PATCH"
> +  $ git config sendemail.to intel-gfx@lists.freedesktop.org
> +  $ git config format.subjectprefix 'PATCH maintainer-tools'
>  
>  for that. Please make sure your patches pass the build and self tests by
>  running::

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/15] drm/i915: Nuke intel_atomic_legacy_gamma_set

[Daniel Vetter]

On Tue, Apr 04, 2017 at 12:44:26PM +0200, Maarten Lankhorst wrote:
> Op 03-04-17 om 10:32 schreef Daniel Vetter:
> > We do set DRIVER_ATOMIC now.
> >
> > Signed-off-by: Daniel Vetter 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 44 
> > +---
> >  1 file changed, 1 insertion(+), 43 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index ba6687e31cbd..779ab46200c2 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -13113,50 +13113,8 @@ void intel_crtc_restore_mode(struct drm_crtc *crtc)
> > drm_atomic_state_put(state);
> >  }
> >  
> > -/*
> > - * FIXME: Remove this once i915 is fully DRIVER_ATOMIC by calling
> > - *drm_atomic_helper_legacy_gamma_set() directly.
> > - */
> > -static int intel_atomic_legacy_gamma_set(struct drm_crtc *crtc,
> > -u16 *red, u16 *green, u16 *blue,
> > -uint32_t size)
> > -{
> > -   struct drm_device *dev = crtc->dev;
> > -   struct drm_mode_config *config = >mode_config;
> > -   struct drm_crtc_state *state;
> > -   int ret;
> > -
> > -   ret = drm_atomic_helper_legacy_gamma_set(crtc, red, green, blue, size);
> > -   if (ret)
> > -   return ret;
> > -
> > -   /*
> > -* Make sure we update the legacy properties so this works when
> > -* atomic is not enabled.
> > -*/
> > -
> > -   state = crtc->state;
> > -
> > -   drm_object_property_set_value(>base,
> > - config->degamma_lut_property,
> > - (state->degamma_lut) ?
> > - state->degamma_lut->base.id : 0);
> > -
> > -   drm_object_property_set_value(>base,
> > - config->ctm_property,
> > - (state->ctm) ?
> > - state->ctm->base.id : 0);
> > -
> > -   drm_object_property_set_value(>base,
> > - config->gamma_lut_property,
> > - (state->gamma_lut) ?
> > - state->gamma_lut->base.id : 0);
> > -
> > -   return 0;
> > -}
> > -
> >  static const struct drm_crtc_funcs intel_crtc_funcs = {
> > -   .gamma_set = intel_atomic_legacy_gamma_set,
> > +   .gamma_set = drm_atomic_helper_legacy_gamma_set,
> > .set_config = drm_atomic_helper_set_config,
> > .set_property = drm_atomic_helper_crtc_set_property,
> > .destroy = intel_crtc_destroy,
> 
> I guess the comment is out of date with drm_object_property_get_value now 
> checking for
> drm_drv_uses_atomic_modeset instead.

Good point, I added a note about that to the commit message before
applying.
> 
> All patches in this series look good, I've seen nothing to comment on. :)
> 
> Reviewed-by: Maarten Lankhorst 

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH maintainer-tools 1/3] make: run check on current `dim`, not the installed one

[Eric Engestrom]

Signed-off-by: Eric Engestrom 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index b4cea98..4291049 100644
--- a/Makefile
+++ b/Makefile
@@ -33,7 +33,7 @@ shellcheck:
shellcheck $(SC_EXCLUDE) dim bash_completion
 
 mancheck:
-   @for cmd in $$(dim list-commands); do \
+   @for cmd in $$(./dim list-commands); do \
if ! grep -q "^$$cmd" dim.rst; then \
echo "$@: $$cmd not documented"; \
fi \
-- 
Cheers,
  Eric

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH maintainer-tools 3/3] dim.rst: update CONTRIBUTING instructions

[Eric Engestrom]

Suggest using git-config instead of a flag on format-patch.
While at it, use the more common "PATCH foo" subject prefix.

Signed-off-by: Eric Engestrom 
---
 dim.rst | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/dim.rst b/dim.rst
index b99248e..c650317 100644
--- a/dim.rst
+++ b/dim.rst
@@ -476,10 +476,11 @@ CONTRIBUTING
 
 
 Submit patches for any of the maintainer tools to the
-intel-gfx@lists.freedesktop.org mailing list with [maintainer-tools PATCH]
+intel-gfx@lists.freedesktop.org mailing list with [PATCH maintainer-tools]
 prefix. Use::
 
-  $ git format-patch --subject-prefix="maintainer-tools PATCH"
+  $ git config sendemail.to intel-gfx@lists.freedesktop.org
+  $ git config format.subjectprefix 'PATCH maintainer-tools'
 
 for that. Please make sure your patches pass the build and self tests by
 running::
-- 
Cheers,
  Eric

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH maintainer-tools 2/3] dim: send 'not configured' error to stderr

[Eric Engestrom]

This fixes `make check` when dim is not configured.

Signed-off-by: Eric Engestrom 
---
 dim | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dim b/dim
index 588e859..b373901 100755
--- a/dim
+++ b/dim
@@ -197,7 +197,7 @@ export __dim_running=1
 if [ "$subcommand" != "setup" ] && [ "$subcommand" != "help" ] && [ 
"$subcommand" != "usage" ]; then
for d in $DIM_PREFIX $DIM_PREFIX/$DIM_DRM_INTEL $DIM_PREFIX/drm-rerere 
$DIM_PREFIX/drm-tip; do
if [ ! -d $d ]; then
-   echo "$d is missing, please check your configuration 
and/or run dim setup"
+   echoerr "$d is missing, please check your configuration 
and/or run dim setup"
exit 1
fi
done
-- 
Cheers,
  Eric

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Only report a wakeup if the waiter was truly asleep

[kbuild test robot]

Hi Chris,

[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20170405]
[cannot apply to v4.11-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Only-report-a-wakeup-if-the-waiter-was-truly-asleep/20170405-165353
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-x004-201714 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/gpu//drm/i915/intel_breadcrumbs.c: In function '__wake_up_sleeper':
>> drivers/gpu//drm/i915/intel_breadcrumbs.c:38:13: error: 'struct task_struct' 
>> has no member named 'on_cpu'; did you mean 'on_rq'?
 return !tsk->on_cpu && wake_up_process(tsk);
^~
>> drivers/gpu//drm/i915/intel_breadcrumbs.c:39:1: warning: control reaches end 
>> of non-void function [-Wreturn-type]
}
^

vim +38 drivers/gpu//drm/i915/intel_breadcrumbs.c

32  /* Be careful not to report a successful wakeup if the waiter is
33   * currently processing the seqno, where it will have already
34   * called set_task_state(TASK_INTERRUPTIBLE). We first check 
whether
35   * the task is currently asleep before calling ttwu, and then we
36   * only report success if we were the ones to then trigger the 
wakeup.
37   */
  > 38  return !tsk->on_cpu && wake_up_process(tsk);
  > 39  }
40  
41  static unsigned int __intel_breadcrumbs_wakeup(struct intel_breadcrumbs 
*b)
42  {

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/1] drm/i915: Suspend GuC prior to GPU Reset during GEM suspend

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/1] drm/i915: Suspend GuC prior to GPU Reset 
during GEM suspend
URL   : https://patchwork.freedesktop.org/series/22512/
State : success

== Summary ==

Series 22512v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/22512/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 435s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 425s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 573s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 505s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 541s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 479s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 475s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 405s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 404s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 423s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 483s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 465s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 451s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 570s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 462s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 574s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 467s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 499s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 432s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 533s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time: 398s

bdea8c440d1dba4f8f8145cf86852011f396282f drm-tip: 2017y-04m-05d-09h-08m-21s UTC 
integration manifest
080b177 drm/i915: Suspend GuC prior to GPU Reset during GEM suspend

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4406/
___
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: Enable atomic for VLV/CHV

[Ville Syrjälä]

On Tue, Apr 04, 2017 at 05:34:17PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Enable atomic for VLV/CHV
> URL   : https://patchwork.freedesktop.org/series/20634/
> State : success
> 
> == Summary ==
> 
> Series 20634v1 drm/i915: Enable atomic for VLV/CHV
> https://patchwork.freedesktop.org/api/1.0/series/20634/revisions/1/mbox/
> 
> Test gem_busy:
> Subgroup basic-hang-default:
> incomplete -> PASS   (fi-hsw-4770r) fdo#100561
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-uc:
> pass   -> FAIL   (fi-snb-2600) fdo#17
> Test gem_exec_suspend:
> Subgroup basic-s4-devices:
> dmesg-warn -> PASS   (fi-bxt-t5700) fdo#100125
> Test kms_cursor_legacy:
> Subgroup basic-busy-flip-before-cursor-atomic:
> skip   -> PASS   (fi-byt-j1900)
> skip   -> PASS   (fi-bsw-n3050)
> skip   -> PASS   (fi-byt-n2820) fdo#100415
> Subgroup basic-flip-after-cursor-atomic:
> skip   -> PASS   (fi-byt-j1900)
> skip   -> PASS   (fi-bsw-n3050)
> skip   -> PASS   (fi-byt-n2820) fdo#100415
> Subgroup basic-flip-after-cursor-varying-size:
> pass   -> FAIL   (fi-byt-n2820) fdo#100415
> Subgroup basic-flip-before-cursor-atomic:
> skip   -> PASS   (fi-byt-j1900)
> skip   -> PASS   (fi-bsw-n3050)
> skip   -> PASS   (fi-byt-n2820) fdo#100415
> Subgroup basic-flip-before-cursor-varying-size:
> pass   -> FAIL   (fi-byt-n2820) fdo#100415

OK, so we're just down to the varying-size tests not passing
on fi-byt-n2820, so I'm going to declare victory.

Rest of the series pushed to dinq. Thanks for the review.

> Test kms_pipe_crc_basic:
> Subgroup nonblocking-crc-pipe-a-frame-sequence:
> dmesg-warn -> PASS   (fi-byt-n2820) fdo#100094
> 
> fdo#100561 https://bugs.freedesktop.org/show_bug.cgi?id=100561
> fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
> fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
> fdo#100415 https://bugs.freedesktop.org/show_bug.cgi?id=100415
> fdo#100094 https://bugs.freedesktop.org/show_bug.cgi?id=100094
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
> time: 434s
> fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
> time: 426s
> fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
> time: 576s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time: 514s
> fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
> time: 547s
> fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
> time: 485s
> fi-byt-n2820 total:278  pass:248  dwarn:0   dfail:0   fail:2   skip:28  
> time: 491s
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time: 411s
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time: 405s
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
> time: 422s
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time: 490s
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time: 488s
> fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time: 459s
> fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time: 564s
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time: 453s
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
> time: 575s
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time: 454s
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time: 490s
> fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
> time: 431s
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time: 526s
> fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
> time: 403s
> 
> 5467cb1fdc74248d650217938305b8f51a0af3f8 drm-tip: 2017y-04m-04d-16h-54m-17s 
> UTC integration manifest
> d6807fd5 drm/i915: Enable atomic on VLV/CHV
> 7e86af5 drm/i915: Use intel_wm_plane_visible() on VLV/CHV as well
> d300717 drm/i915: Check for id==PLANE_CURSOR instead of 
> type==DRM_PLANE_TYPE_CURSOR
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4398/

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/atomic: Add connector atomic_check function.

[Maarten Lankhorst]

Op 05-04-17 om 12:06 schreef Daniel Vetter:
> On Wed, Apr 05, 2017 at 10:41:24AM +0200, Maarten Lankhorst wrote:
>> The connector atomic check function may be called multiple times,
>> or not at all. It's mostly useful for implementing properties but if you
>> call check_modeset twice it can be used for other modeset related checks
>> as well.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/drm_atomic_helper.c  | 25 +
>>  include/drm/drm_modeset_helper_vtables.h | 37 
>> 
>>  2 files changed, 58 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index c3994b4d5f32..d550e79e8347 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -459,10 +459,20 @@ mode_fixup(struct drm_atomic_state *state)
>>   *
>>   * Check the state object to see if the requested state is physically 
>> possible.
>>   * This does all the crtc and connector related computations for an atomic
>> - * update and adds any additional connectors needed for full modesets and 
>> calls
>> - * down into _crtc_helper_funcs.mode_fixup and
>> - * _encoder_helper_funcs.mode_fixup or
>> - * _encoder_helper_funcs.atomic_check functions of the driver backend.
>> + * update and adds any additional connectors needed for full modesets. It 
>> calls
>> + * the various per-object callbacks in the follow order:
>> + *
>> + * 1. _connector_helper_funcs.atomic_best_encoder for determining the 
>> new encoder.
>> + * 2. _connector_helper_funcs.atomic_check to validate the connector 
>> state.
>> + * 3. If it's determined a modeset is needed then all connectors on the 
>> affected crtc
>> + *crtc are added.
>> + * 4. _bridge_funcs.mode_fixup is called on all encoder bridges.
>> + * 5. _encoder_helper_funcs.atomic_check is called to validate any 
>> encoder state.
>> + *This function is only called when the encoder will be part of a 
>> configured crtc,
>> + *it must not be used for implementing connector property validation.
>> + *If this function is NULL, _atomic_encoder_helper_funcs.mode_fixup 
>> is called
>> + *instead.
>> + * 6. _crtc_helper_funcs.mode_fixup is called last, to fix up the mode 
>> with crtc constraints.
> Line too I think. And maybe insert empty lines between each item, to make
> them stand out more. Shouldn't affect rendering, but better to recheck.
>
>>   *
>>   * _crtc_state.mode_changed is set when the input mode is changed.
>>   * _crtc_state.connectors_changed is set when a connector is added or
>> @@ -522,6 +532,8 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>>  return ret;
>>  
>>  for_each_oldnew_connector_in_state(state, connector, 
>> old_connector_state, new_connector_state, i) {
>> +const struct drm_connector_helper_funcs *funcs = 
>> connector->helper_private;
>> +
>>  /*
>>   * This only sets crtc->connectors_changed for routing changes,
>>   * drivers must set crtc->connectors_changed themselves when
>> @@ -539,6 +551,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>>  new_connector_state->link_status)
>>  new_crtc_state->connectors_changed = true;
>>  }
>> +
>> +if (funcs->atomic_check)
>> +ret = funcs->atomic_check(connector, 
>> new_connector_state);
>> +if (ret)
>> +return ret;
>>  }
>>  
>>  /*
>> diff --git a/include/drm/drm_modeset_helper_vtables.h 
>> b/include/drm/drm_modeset_helper_vtables.h
>> index b304950b402d..7b5dd909f189 100644
>> --- a/include/drm/drm_modeset_helper_vtables.h
>> +++ b/include/drm/drm_modeset_helper_vtables.h
>> @@ -860,6 +860,43 @@ struct drm_connector_helper_funcs {
>>   */
>>  struct drm_encoder *(*atomic_best_encoder)(struct drm_connector 
>> *connector,
>> struct drm_connector_state 
>> *connector_state);
>> +
>> +/**
>> + * @atomic_check:
>> + *
>> + * Drivers should check connector properties in this
>> + * hook. This function is called from _atomic_helper_check_modeset.
>> + *
>> + * This function may not be called at all on a modeset or connector
>> + * change, so it should only be used to validate properties.
>> + * If it's required to validate all connectors from there, call
>> + * _atomic_helper_check_modeset twice. This will result in
>> + * atomic_check possibly being called twice as well, which the callback
>> + * should be made to handle correctly.
>> + *
>> + * This function is also allowed to inspect any other object's state and
>> + * can add more state objects to the atomic commit if needed. Care must
>> + * be taken though to ensure that state check and compute functions for

[Intel-gfx] [PATCH v2 1/1] drm/i915: Suspend GuC prior to GPU Reset during GEM suspend

[Sagar Arun Kamble]

i915 is currently doing Full GPU reset at the end of suspend followed by
GuC suspend. This reset bypasses the GuC. We need to tell the GuC to
suspend before we do a direct intel_gpu_reset, Otherwise the gpu state will
no longer match the GuC's expectations and its suspend will not be
successful. With this change, i915 suspends GuC after suspending GEM and
before doing Full GPU reset.

v2: Commit message update. (Chris)

Cc: Jeff McGee 
Cc: Daniele Ceraolo Spurio 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/i915_drv.c | 2 --
 drivers/gpu/drm/i915/i915_gem.c | 2 ++
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c616b4e..7b4fa84 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1469,8 +1469,6 @@ static int i915_drm_suspend(struct drm_device *dev)
goto out;
}
 
-   intel_guc_suspend(dev_priv);
-
intel_display_suspend(dev);
 
intel_dp_mst_suspend(dev);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bbc6f1c..9234334 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4456,6 +4456,8 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv)
i915_gem_context_lost(dev_priv);
mutex_unlock(>struct_mutex);
 
+   intel_guc_suspend(dev_priv);
+
cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work);
cancel_delayed_work_sync(_priv->gt.retire_work);
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/18] drm/i915: introduce drm_i915_gem_object page_size members

[Matthew Auld]

On 04/05, Chris Wilson wrote:
> On Wed, Apr 05, 2017 at 08:49:17AM +0200, Daniel Vetter wrote:
> > On Tue, Apr 04, 2017 at 11:11:12PM +0100, Matthew Auld wrote:
> > > Signed-off-by: Matthew Auld 
> > > ---
> > >  drivers/gpu/drm/i915/i915_gem.c| 5 +
> > >  drivers/gpu/drm/i915/i915_gem_object.h | 3 +++
> > >  2 files changed, 8 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index 4ca88f2539c0..cbf97f4bbb72 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -2441,6 +2441,8 @@ static int i915_gem_object_get_pages(struct 
> > > drm_i915_gem_object *obj)
> > >   struct sg_table *pages;
> > >  
> > >   GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
> > > + GEM_BUG_ON(!is_valid_gtt_page_size(obj->page_size));
> > > + GEM_BUG_ON(!is_valid_gtt_page_size(obj->gtt_page_size));
> > >  
> > >   if (unlikely(obj->mm.madv != I915_MADV_WILLNEED)) {
> > >   DRM_DEBUG("Attempting to obtain a purgeable object\n");
> > > @@ -4159,6 +4161,9 @@ void i915_gem_object_init(struct 
> > > drm_i915_gem_object *obj,
> > >  
> > >   obj->ops = ops;
> > >  
> > > + obj->page_size = PAGE_SIZE;
> > > + obj->gtt_page_size = I915_GTT_PAGE_SIZE;
> > > +
> > >   reservation_object_init(>__builtin_resv);
> > >   obj->resv = >__builtin_resv;
> > >  
> > > diff --git a/drivers/gpu/drm/i915/i915_gem_object.h 
> > > b/drivers/gpu/drm/i915/i915_gem_object.h
> > > index 174cf923c236..b1dacbfe5173 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem_object.h
> > > +++ b/drivers/gpu/drm/i915/i915_gem_object.h
> > > @@ -107,6 +107,9 @@ struct drm_i915_gem_object {
> > >   unsigned int cache_level:3;
> > >   unsigned int cache_dirty:1;
> > >  
> > > + unsigned int page_size; /* CPU pov - 4K(default), 2M, 1G */
> > > + unsigned int gtt_page_size; /* GPU pov - 4K(default), 64K, 2M, 1G */
> > 
> > Just kinda archecture review, with a long-term view: Is the plan to
> > eventually become more flexible here, i.e. allow mixed mode?
> 
> Simply put we can not support obj->page_size. Every object will be
> composed of a mixture of page sizes, often outside of our control and
> those page sizes may vary over the lifetime of the object.
> 
> Trying to design around an a priori static page_size is a bad idea, imo.

I think I've misrepresented the intention of obj->page_size, it merely
serves as a hint to get pages, thereafter it represents the minimum page
size in the mapping and is just bookkeeping, so mixed pages are totally
fine and expected. I mostly wanted it to make it clear to the reader
that we have a gtt and cpu page size. I also wanted to know if an object
is entirely composed of huge-pages for debugfs purposes. I'll try to
rework this to make it less terrible.

> -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 mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] tests/meta_test: Add a meta test for sanity checks of CI systems

[Marta Lofstedt]

The intention of this test is use it to test that the CI system
that runs IGT is collecting the results correctly.

For: VIZ-10281

Signed-off-by: Marta Lofstedt 
---
 tests/Makefile.sources   |   1 +
 tests/intel-ci/meta.testlist |   7 +++
 tests/meta_test.c| 145 +++
 3 files changed, 153 insertions(+)
 create mode 100644 tests/intel-ci/meta.testlist
 create mode 100644 tests/meta_test.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 45c21a0..7fa9b8f 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -143,6 +143,7 @@ TESTS_progs_M = \
template \
vgem_basic \
vgem_slow \
+   meta_test \
$(NULL)
 
 if HAVE_CHAMELIUM
diff --git a/tests/intel-ci/meta.testlist b/tests/intel-ci/meta.testlist
new file mode 100644
index 000..b3e2923
--- /dev/null
+++ b/tests/intel-ci/meta.testlist
@@ -0,0 +1,7 @@
+igt@meta_test@pass-result
+igt@meta_test@fail-result
+igt@meta_test@dmesg-pass
+igt@meta_test@dmesg-warn
+igt@meta_test@user-crash
+igt@meta_test@piglit-timeout
+igt@meta_test@generate-panic
diff --git a/tests/meta_test.c b/tests/meta_test.c
new file mode 100644
index 000..8a420ba
--- /dev/null
+++ b/tests/meta_test.c
@@ -0,0 +1,145 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+
+#include 
+#include 
+#include "igt.h"
+
+/*
+ * The purpose of this test is to test the CI system that we have
+ * for running the tests. The test should generate all possible
+ * exit states for igt tests.
+ *
+ * Possible exit-states of igt tests:
+ * 1. pass - subtest: pass-result
+ * 2. fail - subtest: fail-result
+ * 3. dmesg warn - subtest: dmesg-fail,
+ *  subtest: dmesg-pass is a sanity check for the dmesg-fail.
+ * 4. crash - subtest: user-crash
+ * 5. piglit timeout - subtest: piglit-timeout
+ * 6. incomplete - subtest: generate-panic
+ *  NOTE: inorder for this to generate the incomplete state
+ *  the kernel must be configured to reboot on panic.
+ *  NOTE: if the tested CI system have features such as
+ *  PSTORE and/or kexec/kdump enabled. This test could be
+ *  used to make sure that the CI system stores the generated
+ *  log/dumps as expected.
+ * 7. incomplete - where user hang is not caught by piglit timeout.
+ *  This would be caught by a user-side softdog daemon,
+ *  such as owatch by ezbench. However, I don't know
+ *  how to trigger this state, so it will not be tested.
+ * 8. incomplete - system requires hard reboot :
+ *  This state could be triggered by calling an evil kernel
+ *  module that was developed hang the system. Such
+ *  a module will not be developed for this purpose,
+ *  so this "exit state" will not be tested.
+ *
+ * TODO: If this test was deployed on a CI system that
+ * was able to pick up testing again after reboot,
+ * such as ezbench, a post-analyze test should be added
+ * that collected and analyzed the result of the tests
+ * run before reboot.
+ */
+
+__attribute__((format(printf, 1, 2)))
+static void kmsg(const char *format, ...)
+#define KERN_EMER"<0>"
+#define KERN_ALERT"<1>"
+#define KERN_CRIT"<2>"
+#define KERN_ERR"<3>"
+#define KERN_WARNING"<4>"
+#define KERN_NOTICE"<5>"
+#define KERN_INFO"<6>"
+#define KERN_DEBUG"<7>"
+{
+   va_list ap;
+   FILE *file;
+
+   file = fopen("/dev/kmsg", "w");
+   if (file == NULL)
+   return;
+
+   va_start(ap, format);
+   vfprintf(file, format, ap);
+   va_end(ap);
+   fclose(file);
+}
+
+static void test_result(bool result)
+{
+   igt_assert_eq(result, true);
+}
+
+static void test_dmesg(bool pass)
+{
+   if (pass)
+   kmsg(KERN_DEBUG "drm: IGT inserted string.");
+   else
+   kmsg(KERN_WARNING "drm: IGT inserted string.");
+}
+
+static 

Re: [Intel-gfx] [PATCH] drm/atomic: Add connector atomic_check function.

[Daniel Vetter]

On Wed, Apr 05, 2017 at 10:41:24AM +0200, Maarten Lankhorst wrote:
> The connector atomic check function may be called multiple times,
> or not at all. It's mostly useful for implementing properties but if you
> call check_modeset twice it can be used for other modeset related checks
> as well.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/drm_atomic_helper.c  | 25 +
>  include/drm/drm_modeset_helper_vtables.h | 37 
> 
>  2 files changed, 58 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index c3994b4d5f32..d550e79e8347 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -459,10 +459,20 @@ mode_fixup(struct drm_atomic_state *state)
>   *
>   * Check the state object to see if the requested state is physically 
> possible.
>   * This does all the crtc and connector related computations for an atomic
> - * update and adds any additional connectors needed for full modesets and 
> calls
> - * down into _crtc_helper_funcs.mode_fixup and
> - * _encoder_helper_funcs.mode_fixup or
> - * _encoder_helper_funcs.atomic_check functions of the driver backend.
> + * update and adds any additional connectors needed for full modesets. It 
> calls
> + * the various per-object callbacks in the follow order:
> + *
> + * 1. _connector_helper_funcs.atomic_best_encoder for determining the 
> new encoder.
> + * 2. _connector_helper_funcs.atomic_check to validate the connector 
> state.
> + * 3. If it's determined a modeset is needed then all connectors on the 
> affected crtc
> + *crtc are added.
> + * 4. _bridge_funcs.mode_fixup is called on all encoder bridges.
> + * 5. _encoder_helper_funcs.atomic_check is called to validate any 
> encoder state.
> + *This function is only called when the encoder will be part of a 
> configured crtc,
> + *it must not be used for implementing connector property validation.
> + *If this function is NULL, _atomic_encoder_helper_funcs.mode_fixup 
> is called
> + *instead.
> + * 6. _crtc_helper_funcs.mode_fixup is called last, to fix up the mode 
> with crtc constraints.

Line too I think. And maybe insert empty lines between each item, to make
them stand out more. Shouldn't affect rendering, but better to recheck.

>   *
>   * _crtc_state.mode_changed is set when the input mode is changed.
>   * _crtc_state.connectors_changed is set when a connector is added or
> @@ -522,6 +532,8 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>   return ret;
>  
>   for_each_oldnew_connector_in_state(state, connector, 
> old_connector_state, new_connector_state, i) {
> + const struct drm_connector_helper_funcs *funcs = 
> connector->helper_private;
> +
>   /*
>* This only sets crtc->connectors_changed for routing changes,
>* drivers must set crtc->connectors_changed themselves when
> @@ -539,6 +551,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
>   new_connector_state->link_status)
>   new_crtc_state->connectors_changed = true;
>   }
> +
> + if (funcs->atomic_check)
> + ret = funcs->atomic_check(connector, 
> new_connector_state);
> + if (ret)
> + return ret;
>   }
>  
>   /*
> diff --git a/include/drm/drm_modeset_helper_vtables.h 
> b/include/drm/drm_modeset_helper_vtables.h
> index b304950b402d..7b5dd909f189 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -860,6 +860,43 @@ struct drm_connector_helper_funcs {
>*/
>   struct drm_encoder *(*atomic_best_encoder)(struct drm_connector 
> *connector,
>  struct drm_connector_state 
> *connector_state);
> +
> + /**
> +  * @atomic_check:
> +  *
> +  * Drivers should check connector properties in this
> +  * hook. This function is called from _atomic_helper_check_modeset.
> +  *
> +  * This function may not be called at all on a modeset or connector
> +  * change, so it should only be used to validate properties.
> +  * If it's required to validate all connectors from there, call
> +  * _atomic_helper_check_modeset twice. This will result in
> +  * atomic_check possibly being called twice as well, which the callback
> +  * should be made to handle correctly.
> +  *
> +  * This function is also allowed to inspect any other object's state and
> +  * can add more state objects to the atomic commit if needed. Care must
> +  * be taken though to ensure that state check and compute functions for
> +  * these added states are all called, and derived state in other objects
> +  * all updated. Again the 

Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_atomic_allow_modeset: Add DRM_MODE_ATOMIC_ALLOW_MODESET test

[Mika Kahola]

On Tue, 2017-04-04 at 14:28 +0200, Maarten Lankhorst wrote:
> Hey,
> 
> Op 04-04-17 om 13:59 schreef Mika Kahola:
> > 
> > When doing a full atomic modeset, kernel should fail if the flag
> > DRM_MODE_ATOMIC_ALLOW_MODESET is not set. Let's add this test as
> > part of
> > Intel-GPU-Tools. The test procedure is the following:
> > 
> > - Try to do atomic commit without DRM_MODE_ATOMIC_ALLOW_MODESET
> > flag.
> >   Kernel should reject this request.
> > - Do full modeset
> > - Enable DRM_MODE_ATOMIC_ALLOW_MODESET and try to do atmic commit.
> >   Kernel should now allow atomic modeset.
> > 
> > For: VIZ-6955
> > 
> > Signed-off-by: Mika Kahola 
> > ---
> >  tests/Makefile.sources   |   1 +
> >  tests/kms_atomic_allow_modeset.c | 133
> > +++
> >  2 files changed, 134 insertions(+)
> >  create mode 100644 tests/kms_atomic_allow_modeset.c
> > 
> > diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> > index 45c21a0..d3ee629 100644
> > --- a/tests/Makefile.sources
> > +++ b/tests/Makefile.sources
> > @@ -94,6 +94,7 @@ TESTS_progs_M = \
> >     kms_addfb_basic \
> >     kms_atomic \
> >     kms_atomic_transition \
> > +   kms_atomic_allow_modeset \
> >     kms_busy \
> >     kms_ccs \
> >     kms_chv_cursor_fail \
> > diff --git a/tests/kms_atomic_allow_modeset.c
> > b/tests/kms_atomic_allow_modeset.c
> > new file mode 100644
> > index 000..b4d8c16
> > --- /dev/null
> > +++ b/tests/kms_atomic_allow_modeset.c
> > @@ -0,0 +1,133 @@
> > +/*
> > + * Copyright © 2017 Intel Corporation
> > + *
> > + * Permission is hereby granted, free of charge, to any person
> > obtaining a
> > + * copy of this software and associated documentation files (the
> > "Software"),
> > + * to deal in the Software without restriction, including without
> > limitation
> > + * the rights to use, copy, modify, merge, publish, distribute,
> > sublicense,
> > + * and/or sell copies of the Software, and to permit persons to
> > whom the
> > + * Software is furnished to do so, subject to the following
> > conditions:
> > + *
> > + * The above copyright notice and this permission notice
> > (including the next
> > + * paragraph) shall be included in all copies or substantial
> > portions of the
> > + * Software.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > EXPRESS OR
> > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > MERCHANTABILITY,
> > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO
> > EVENT SHALL
> > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> > DAMAGES OR OTHER
> > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> > ARISING
> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> > OTHER DEALINGS
> > + * IN THE SOFTWARE.
> > + *
> > + */
> > +
> > +#include "igt.h"
> > +
> > +IGT_TEST_DESCRIPTION("Test that kernel rejects atomic modeset if
> > ALLOW_MODESET flag is not set");
> > +
> > +static void
> > +test_init(igt_display_t *display, struct igt_fb *fb, igt_output_t
> > *output)
> > +{
> > +   drmModeModeInfo *mode;
> > +   igt_plane_t *primary;
> > +   int id;
> > +
> > +   mode = igt_output_get_mode(output);
> > +
> > +   id = igt_create_pattern_fb(display->drm_fd,
> > +      mode->hdisplay, mode->vdisplay,
> > +      DRM_FORMAT_XRGB,
> > +      LOCAL_I915_FORMAT_MOD_X_TILED,
> > +      fb);
> > +   igt_assert(id);
> > +
> > +   primary = igt_output_get_plane_type(output,
> > DRM_PLANE_TYPE_PRIMARY);
> > +   igt_plane_set_fb(primary, fb);
> > +}
> > +
> > +static void
> > +test_finish(igt_display_t *display, struct igt_fb *fb,
> > igt_output_t *output)
> > +{
> > +   igt_plane_t *primary;
> > +
> > +   primary = igt_output_get_plane_type(output,
> > DRM_PLANE_TYPE_PRIMARY);
> > +
> > +   igt_remove_fb(display->drm_fd, fb);
> > +
> > +   igt_plane_set_fb(primary, NULL);
> > +   igt_output_set_pipe(output, PIPE_ANY);
> > +
> > +   igt_display_commit2(display, COMMIT_ATOMIC);
> > +}
> > +
> > +static void
> > +test_allow_modeset(igt_display_t *display, enum pipe pipe,
> > igt_output_t *output)
> > +{
> > +   struct igt_fb fb;
> > +   int flags = DRM_MODE_ATOMIC_NONBLOCK;
> > +   int ret;
> > +
> > +   igt_output_set_pipe(output, pipe);
> > +
> > +   test_init(display, , output);
> > +
> > +   /*
> > +    * Try to do atomic commit without
> > DRM_MODE_ATOMIC_ALLOW_MODESET flag.
> > +    * Kernel should reject this request.
> > +    */
> > +   ret = igt_display_try_commit_atomic(display, flags, NULL);
> > +   igt_assert_eq(ret, -EINVAL);
> > +
> > +   /* do modeset */
> > +   igt_output_set_pipe(output, pipe);
> > +
> > +   /*
> > +    * Try to do atomic commit with
> > DRM_MODE_ATOMIC_ALLOW_MODESET flag set.
> > +    * The kernel should now accept this request.
> > +    */
> > +   flags |= DRM_MODE_ATOMIC_ALLOW_MODESET;
> > +   ret = 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/atomic: Add connector atomic_check function.

[Patchwork]

== Series Details ==

Series: drm/atomic: Add connector atomic_check function.
URL   : https://patchwork.freedesktop.org/series/22507/
State : success

== Summary ==

Series 22507v1 drm/atomic: Add connector atomic_check function.
https://patchwork.freedesktop.org/api/1.0/series/22507/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time: 430s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time: 429s
fi-bsw-n3050 total:278  pass:239  dwarn:0   dfail:0   fail:0   skip:39  
time: 572s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time: 512s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time: 536s
fi-byt-j1900 total:278  pass:251  dwarn:0   dfail:0   fail:0   skip:27  
time: 487s
fi-byt-n2820 total:278  pass:247  dwarn:0   dfail:0   fail:0   skip:31  
time: 482s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 410s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time: 506s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time: 426s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 493s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 460s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time: 455s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time: 568s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 460s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time: 570s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time: 460s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time: 486s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time: 434s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time: 531s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time: 410s

bdea8c440d1dba4f8f8145cf86852011f396282f drm-tip: 2017y-04m-05d-09h-08m-21s UTC 
integration manifest
9fcc128 drm/atomic: Add connector atomic_check function.

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4405/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Suspend GuC during GEM Suspend prior to GPU Reset

[Kamble, Sagar A]

On 4/5/2017 2:30 PM, Chris Wilson wrote:

On Wed, Apr 05, 2017 at 11:04:34AM +0530, Sagar Arun Kamble wrote:

During S3/S4 suspend, i915 sends HOST2GUC with ENTER_S_STATE action
for suspending GuC. GuC stops scheduling at this point. i915 is
currently doing explicit GPU reset during suspend ensuring GEM is idle.
Suspend GuC prior to triggering GPU Reset to ensure GuC stays idle too.

Why would a gpu reset cause the guc to think it was not idle, and
futhermore ignore the suspend request afterwards? Should we not be
completely disabling the guc along the system suspend path? Especially
if it is so easily confused?
-Chris
Post GPU reset, GuC firmware is unloaded and GuC is not ready till we 
reinitialize the firmware so
all Host to GuC actions are bound to fail. ENTER_S_STATE is disabling 
GuC scheduling completely.
GuC is saving the needed state and ensuring wake events are disabled. So 
we need to trigger this

action prior to resetting GPU in suspend path.




___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [dim PATCH 4/4] dim: run executables in $PATH named dim-subcommand as dim subcommands

[Daniel Vetter]

On Wed, Apr 05, 2017 at 10:28:06AM +0300, Jani Nikula wrote:
> On Tue, 04 Apr 2017, Daniel Vetter  wrote:
> > On Tue, Apr 04, 2017 at 04:59:02PM +0300, Jani Nikula wrote:
> >> Similar to git. Don't allow override of internal commands though.
> >
> > git did this, and then went to a slightly different version because
> > git doesn't complete to a space due to the various git-foo commands
> > in path. Imo the right way to do this is to have a libexec/ subdir,
> > complete just those (and switch the completion to recognize them), i.e.
> > git foo would run maintainer-tools/libexec/git-foo or maybe
> > maintainer-tools/git-foo. But not depend upon git-foo being in your path
> > (because that is really annoying to me).
> 
> Agreed on the annoyance. But libexec is annoying too because it
> precludes the user from adding their own extensions in $PATH. An
> alternative is to mandate a *different* prefix for external dim
> commands, for example external-dim-foo.
> 
> I'm not hung up on this patch anyway, it was just a quick idea in case
> we want to add largish related tools without cluttering the already
> pretty big dim source.

You can add the libexec path (or well, DIM_SRC/maintainer-tools) and get
both. Or do you mean adding your own extensions, not in the upstream
maintainer-tools? I'd say for that case some pressure to get tools merged
into upstream would be good :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc: Use GUC prefix for CORE_FAMILY definitions

[Chris Wilson]

On Tue, Apr 04, 2017 at 02:52:06PM +0100, Tvrtko Ursulin wrote:
> 
> On 04/04/2017 14:38, Michal Wajdeczko wrote:
> >Almost all other GuC fw definitions are using GUC|guc prefix.
> >While around, in get_core_family() change explicit WARN into MISSING_CASE
> >as it looks more appropriate, since GuC support capability we are controlling
> >by intel_device_info.has_guc flag.
> >
> >Signed-off-by: Michal Wajdeczko 
> >Cc: Joonas Lahtinen 
> >Cc: Tvrtko Ursulin 
> Reviewed-by: Tvrtko Ursulin 

Reviewed-by: Chris Wilson 

And pushed, thanks for the patch and review.
-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/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes, v3.

[Daniel Vetter]

On Wed, Apr 05, 2017 at 10:11:18AM +0200, Maarten Lankhorst wrote:
> mode_valid() called from drm_helper_probe_single_connector_modes()
> may need to look at connector->state because what a valid mode is may
> depend on connector properties being set. For example some HDMI modes
> might be rejected when a connector property forces the connector
> into DVI mode.
> 
> Some implementations of detect() already lock all state,
> so we have to pass an acquire_ctx to them to prevent a deadlock.
> 
> This means changing the function signature of detect() slightly,
> and passing the acquire_ctx for locking multiple crtc's.
> For the callbacks, it will always be non-zero. To allow callers
> not to worry about this, drm_helper_probe_detect_ctx is added
> which might handle -EDEADLK for you.
> 
> Changes since v1:
> - Always set ctx parameter.
> Changes since v2:
> - Always take connection_mutex when probing.
> 
> Signed-off-by: Maarten Lankhorst 
> Cc: Boris Brezillon 

A few minor nits, mostly to improve checks and docs. With those all
addressed:

Reviewed-by: Daniel Vetter 

> ---
>  Fixed drm_helper_probe_detect,
>  is this version better?
>  drivers/gpu/drm/drm_probe_helper.c   | 100 
> ---
>  drivers/gpu/drm/i915/intel_crt.c |  25 
>  drivers/gpu/drm/i915/intel_display.c |  25 
>  drivers/gpu/drm/i915/intel_dp.c  |  24 
>  drivers/gpu/drm/i915/intel_drv.h |   8 +--
>  drivers/gpu/drm/i915/intel_hotplug.c |   3 +-
>  drivers/gpu/drm/i915/intel_tv.c  |  21 +++
>  include/drm/drm_connector.h  |   5 ++
>  include/drm/drm_crtc_helper.h|   3 +
>  include/drm/drm_modeset_helper_vtables.h |  24 
>  10 files changed, 175 insertions(+), 63 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index efb5e5e8ce62..ba0160446aac 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -169,12 +169,73 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
>  EXPORT_SYMBOL(drm_kms_helper_poll_enable);
>  
>  static enum drm_connector_status
> -drm_connector_detect(struct drm_connector *connector, bool force)
> +drm_helper_probe_detect_ctx(struct drm_connector *connector, bool force)
>  {
> - return connector->funcs->detect ?
> - connector->funcs->detect(connector, force) :
> - connector_status_connected;
> + const struct drm_connector_helper_funcs *funcs = 
> connector->helper_private;
> + struct drm_modeset_acquire_ctx ctx;
> + int ret;
> +
> + drm_modeset_acquire_init(, 0);
> +
> +retry:
> + ret = drm_modeset_lock(>dev->mode_config.connection_mutex, 
> );
> + if (!ret) {
> + if (funcs->detect_ctx)
> + ret = funcs->detect_ctx(connector, , force);
> + else if (connector->funcs->detect)
> + ret = connector->funcs->detect(connector, force);
> + else
> + ret = connector_status_connected;
> + }
> +
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff();
> + goto retry;
> + }
> +
> + if (WARN_ON(ret < 0))
> + ret = connector_status_unknown;
> +
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +
> + return ret;
> +}
> +
> +/**
> + * drm_helper_probe_detect - probe connector status
> + * @connector: connector to probe
> + * @ctx: acquire_ctx, or NULL to let this function handle locking.
> + * @force: Whether destructive probe operations should be performed.
> + *
> + * This function calls the detect callbacks of the connector.
> + * This function returns drm_connector_status, or
> + * if @ctx is set, it might also return -EDEADLK.
> + */
> +int
> +drm_helper_probe_detect(struct drm_connector *connector,
> + struct drm_modeset_acquire_ctx *ctx,
> + bool force)
> +{
> + const struct drm_connector_helper_funcs *funcs = 
> connector->helper_private;
> + struct drm_device *dev = connector->dev;
> + int ret;
> +
> + if (!ctx)
> + return drm_helper_probe_detect_ctx(connector, force);
> +
> + ret = drm_modeset_lock(>mode_config.connection_mutex, ctx);
> + if (ret)
> + return ret;
> +
> + if (funcs->detect_ctx)
> + return funcs->detect_ctx(connector, ctx, force);
> + else if (connector->funcs->detect)
> + return connector->funcs->detect(connector, force);
> + else
> + return connector_status_connected;
>  }
> +EXPORT_SYMBOL(drm_helper_probe_detect);
>  
>  /**
>   * drm_helper_probe_single_connector_modes - get complete set of display 
> modes
> @@ -239,15 +300,27 @@ int drm_helper_probe_single_connector_modes(struct 
> drm_connector *connector,
>   struct 

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Suspend GuC during GEM Suspend prior to GPU Reset

[Chris Wilson]

On Wed, Apr 05, 2017 at 11:04:34AM +0530, Sagar Arun Kamble wrote:
> During S3/S4 suspend, i915 sends HOST2GUC with ENTER_S_STATE action
> for suspending GuC. GuC stops scheduling at this point. i915 is
> currently doing explicit GPU reset during suspend ensuring GEM is idle.
> Suspend GuC prior to triggering GPU Reset to ensure GuC stays idle too.

Why would a gpu reset cause the guc to think it was not idle, and
futhermore ignore the suspend request afterwards? Should we not be
completely disabling the guc along the system suspend path? Especially
if it is so easily confused?
-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] [maintainer-tools PATCH] dim: Add examples section to dim.rst

[Daniel Vetter]

On Mon, Apr 03, 2017 at 01:42:18PM -0400, Sean Paul wrote:
> Along with a recipe for creating a topic branch and sending a pull
> request from it.
> 
> Signed-off-by: Sean Paul 
> ---
>  dim.rst | 50 ++
>  1 file changed, 50 insertions(+)
> 
> diff --git a/dim.rst b/dim.rst
> index bc4d9a0..4b905ad 100644
> --- a/dim.rst
> +++ b/dim.rst
> @@ -465,6 +465,56 @@ listed using the **list-aliases** subcommand.
>  
>  The alias functionality requires **bash(1)** version 4.3 or later to work.
>  
> +EXAMPLES
> +
> +
> +Cross-subsystem pull requests
> +-
> +So you want to send a pull request to another subsystem? Maintainers will 
> likely
> +get cranky if you ask them to pull a swath of unrelated drm patches, so we'll
> +use a topic branch based upon Linus' tree with only the relevant patches.
> +
> +First, create the topic branch using dim. Use whichever dim remote is most
> +applicable, and name the branch in a manner that describes the set of patches
> +you want pulled. The upstream will be Linus' tree.
> +
> +  $ dim create-branch *dim-remote*/topic/*topic-branch* origin/master
> +
> +Once the branch is created, you can apply the patches to be pulled.
> +
> +  $ dim apply-branch topic/*topic-branch*
> +
> +Build test your new topic branch and push it.
> +
> +  $ dim push-branch topic/*topic-branch*
> +
> +Ensure that your topic branch was merged into drm-tip. The drm-tip tree is
> +located in $DIM_PREFIX/drm-tip, build test it to ensure the new topic branch
> +didn't break anything.
> +
> +Once you're satisfied that nothing is broken, create the pull request.
> +
> +  $ dim pull-request topic/*topic-branch* origin/master
> +
> +You'll be prompted to enter a tag description and your mail user agent will 
> open
> +with the pull request email. Change names and emails as appropriate to 
> reflect
> +who the sender and recipient of the pull is, and send it.
> +
> +Once the pull has been acked by your maintainer counterpart, you can pull it
> +into the appropriate local dim branch.
> +
> +  $ dim apply-pull *dim-branch*
> +
> +Perform a final build test, and push *dim-branch* to *dim-remote*.
> +
> +  $ dim push-branch *dim-branch*
> +
> +You can now remove the topic branch, as it is no longer useful (you could 
> remove
> +it any time after the pull request, since it creates a tag, but this is as 
> good
> +a place as any).
> +
> +  $ dim remote-branch topic/*topic-branch*

s/remote/remove/

-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 00/18] drm/i915: initial support for huge gtt pages V2

[Chris Wilson]

On Tue, Apr 04, 2017 at 11:11:10PM +0100, Matthew Auld wrote:
> Same as before, folding in review comments. Notably we now hook in transparent
> huge pages through by shmem, and *attempt* to deal with all the fun which that
> brings. Again should be considered very much RFC.

But where's the explanation for persisting with an inflexible design? I
still do not like the static page size assignments, and trying to force
that down into the GTT, rather than it percolating up.
-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 02/18] drm/i915: introduce drm_i915_gem_object page_size members

[Chris Wilson]

On Wed, Apr 05, 2017 at 08:49:17AM +0200, Daniel Vetter wrote:
> On Tue, Apr 04, 2017 at 11:11:12PM +0100, Matthew Auld wrote:
> > Signed-off-by: Matthew Auld 
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c| 5 +
> >  drivers/gpu/drm/i915/i915_gem_object.h | 3 +++
> >  2 files changed, 8 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c 
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 4ca88f2539c0..cbf97f4bbb72 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -2441,6 +2441,8 @@ static int i915_gem_object_get_pages(struct 
> > drm_i915_gem_object *obj)
> > struct sg_table *pages;
> >  
> > GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
> > +   GEM_BUG_ON(!is_valid_gtt_page_size(obj->page_size));
> > +   GEM_BUG_ON(!is_valid_gtt_page_size(obj->gtt_page_size));
> >  
> > if (unlikely(obj->mm.madv != I915_MADV_WILLNEED)) {
> > DRM_DEBUG("Attempting to obtain a purgeable object\n");
> > @@ -4159,6 +4161,9 @@ void i915_gem_object_init(struct drm_i915_gem_object 
> > *obj,
> >  
> > obj->ops = ops;
> >  
> > +   obj->page_size = PAGE_SIZE;
> > +   obj->gtt_page_size = I915_GTT_PAGE_SIZE;
> > +
> > reservation_object_init(>__builtin_resv);
> > obj->resv = >__builtin_resv;
> >  
> > diff --git a/drivers/gpu/drm/i915/i915_gem_object.h 
> > b/drivers/gpu/drm/i915/i915_gem_object.h
> > index 174cf923c236..b1dacbfe5173 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_object.h
> > +++ b/drivers/gpu/drm/i915/i915_gem_object.h
> > @@ -107,6 +107,9 @@ struct drm_i915_gem_object {
> > unsigned int cache_level:3;
> > unsigned int cache_dirty:1;
> >  
> > +   unsigned int page_size; /* CPU pov - 4K(default), 2M, 1G */
> > +   unsigned int gtt_page_size; /* GPU pov - 4K(default), 64K, 2M, 1G */
> 
> Just kinda archecture review, with a long-term view: Is the plan to
> eventually become more flexible here, i.e. allow mixed mode?

Simply put we can not support obj->page_size. Every object will be
composed of a mixture of page sizes, often outside of our control and
those page sizes may vary over the lifetime of the object.

Trying to design around an a priori static page_size is a bad idea, imo.
-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 01/18] drm/i915: add page_size_mask to dev_info

[Chris Wilson]

On Wed, Apr 05, 2017 at 09:19:49AM +0300, Joonas Lahtinen wrote:
> On ti, 2017-04-04 at 23:11 +0100, Matthew Auld wrote:
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -56,6 +56,10 @@
> >     .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 }
> >  
> >  /* Keep in gen based order, and chronological order within a gen */
> > +
> > +#define GEN_DEFAULT_PAGE_SZ \
> > +   .page_size_mask = I915_GTT_PAGE_SIZE_4K
> 
> GEN_DEFAULT_PAGE_SIZES
> 
> > @@ -346,13 +358,18 @@ static const struct intel_device_info 
> > intel_cherryview_info = {
> >     .has_aliasing_ppgtt = 1,
> >     .has_full_ppgtt = 1,
> >     .display_mmio_offset = VLV_DISPLAY_BASE,
> > +   .page_size_mask = I915_GTT_PAGE_SIZE_4K | I915_GTT_PAGE_SIZE_64K | 
> > I915_GTT_PAGE_SIZE_2M | I915_GTT_PAGE_SIZE_1G,
> 
> Split long line.
> 
> >     GEN_CHV_PIPEOFFSETS,
> >     CURSOR_OFFSETS,
> > >   CHV_COLORS,
> >  };
> >  
> > +#define GEN9_DEFAULT_PAGE_SZ \
> > +   .page_size_mask = I915_GTT_PAGE_SIZE_4K | I915_GTT_PAGE_SIZE_64K | 
> > I915_GTT_PAGE_SIZE_2M | I915_GTT_PAGE_SIZE_1G
> 
> GEN9_DEFAULT_PAGE_SIZES, also split long line.

Also not in this patch. First patch is to set everything to the status
quo. Last patch will be to enable the (completed) feature on the
platforms using. In testing, that enabling patch comes early on to check
bisection of the series.
-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 01/18] drm/i915: add page_size_mask to dev_info

[Chris Wilson]

On Tue, Apr 04, 2017 at 11:11:11PM +0100, Matthew Auld wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index fb15684c1d83..27b2b9e681db 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -42,7 +42,22 @@
>  #include "i915_gem_request.h"
>  #include "i915_selftest.h"
>  
> -#define I915_GTT_PAGE_SIZE 4096UL
> +#define I915_GTT_PAGE_SIZE_4K BIT(12)
> +#define I915_GTT_PAGE_SIZE_64K BIT(16)
> +#define I915_GTT_PAGE_SIZE_2M BIT(21)
> +#define I915_GTT_PAGE_SIZE_1G BIT(30)
> +
> +#define I915_GTT_PAGE_SIZE I915_GTT_PAGE_SIZE_4K
> +
> +#define I915_GTT_PAGE_SIZE_MASK (I915_GTT_PAGE_SIZE_4K | \
> +  I915_GTT_PAGE_SIZE_64K | \
> +  I915_GTT_PAGE_SIZE_2M | \
> +  I915_GTT_PAGE_SIZE_1G)
> +
> +#define is_valid_gtt_page_size(page_size) \
> + (is_power_of_2(page_size) && \
> +  (page_size) & I915_GTT_PAGE_SIZE_MASK)

({ unsigned int __size = (page_size); (__size & SIZE_MASK) == __size; })

-- 
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/atomic: Add connector atomic_check function.

[Maarten Lankhorst]

The connector atomic check function may be called multiple times,
or not at all. It's mostly useful for implementing properties but if you
call check_modeset twice it can be used for other modeset related checks
as well.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c  | 25 +
 include/drm/drm_modeset_helper_vtables.h | 37 
 2 files changed, 58 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index c3994b4d5f32..d550e79e8347 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -459,10 +459,20 @@ mode_fixup(struct drm_atomic_state *state)
  *
  * Check the state object to see if the requested state is physically possible.
  * This does all the crtc and connector related computations for an atomic
- * update and adds any additional connectors needed for full modesets and calls
- * down into _crtc_helper_funcs.mode_fixup and
- * _encoder_helper_funcs.mode_fixup or
- * _encoder_helper_funcs.atomic_check functions of the driver backend.
+ * update and adds any additional connectors needed for full modesets. It calls
+ * the various per-object callbacks in the follow order:
+ *
+ * 1. _connector_helper_funcs.atomic_best_encoder for determining the new 
encoder.
+ * 2. _connector_helper_funcs.atomic_check to validate the connector state.
+ * 3. If it's determined a modeset is needed then all connectors on the 
affected crtc
+ *crtc are added.
+ * 4. _bridge_funcs.mode_fixup is called on all encoder bridges.
+ * 5. _encoder_helper_funcs.atomic_check is called to validate any encoder 
state.
+ *This function is only called when the encoder will be part of a 
configured crtc,
+ *it must not be used for implementing connector property validation.
+ *If this function is NULL, _atomic_encoder_helper_funcs.mode_fixup is 
called
+ *instead.
+ * 6. _crtc_helper_funcs.mode_fixup is called last, to fix up the mode 
with crtc constraints.
  *
  * _crtc_state.mode_changed is set when the input mode is changed.
  * _crtc_state.connectors_changed is set when a connector is added or
@@ -522,6 +532,8 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
return ret;
 
for_each_oldnew_connector_in_state(state, connector, 
old_connector_state, new_connector_state, i) {
+   const struct drm_connector_helper_funcs *funcs = 
connector->helper_private;
+
/*
 * This only sets crtc->connectors_changed for routing changes,
 * drivers must set crtc->connectors_changed themselves when
@@ -539,6 +551,11 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
new_connector_state->link_status)
new_crtc_state->connectors_changed = true;
}
+
+   if (funcs->atomic_check)
+   ret = funcs->atomic_check(connector, 
new_connector_state);
+   if (ret)
+   return ret;
}
 
/*
diff --git a/include/drm/drm_modeset_helper_vtables.h 
b/include/drm/drm_modeset_helper_vtables.h
index b304950b402d..7b5dd909f189 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -860,6 +860,43 @@ struct drm_connector_helper_funcs {
 */
struct drm_encoder *(*atomic_best_encoder)(struct drm_connector 
*connector,
   struct drm_connector_state 
*connector_state);
+
+   /**
+* @atomic_check:
+*
+* Drivers should check connector properties in this
+* hook. This function is called from _atomic_helper_check_modeset.
+*
+* This function may not be called at all on a modeset or connector
+* change, so it should only be used to validate properties.
+* If it's required to validate all connectors from there, call
+* _atomic_helper_check_modeset twice. This will result in
+* atomic_check possibly being called twice as well, which the callback
+* should be made to handle correctly.
+*
+* This function is also allowed to inspect any other object's state and
+* can add more state objects to the atomic commit if needed. Care must
+* be taken though to ensure that state check and compute functions for
+* these added states are all called, and derived state in other objects
+* all updated. Again the recommendation is to just call check helpers
+* until a maximal configuration is reached.
+*
+* NOTE:
+*
+* This function is called in the check phase of an atomic update. The
+* driver is not allowed to change anything outside of the free-standing
+* state objects passed-in or assembled in the overall 

Re: [Intel-gfx] [PATCH] drm/i915: Typo fix - 'pipe bpc' to 'pipe bpp'

[Jani Nikula]

On Wed, 05 Apr 2017, Jani Nikula  wrote:
> On Tue, 04 Apr 2017, Dhinakaran Pandiyan  
> wrote:
>> Noticed this while I was looking at some debug output,
>>  [drm:intel_hdmi_compute_config [i915]] picking bpc to 12 for HDMI output
>>  [drm:intel_hdmi_compute_config [i915]] forcing pipe bpc to 36 for HDMI
>>
>> I believe the second line should be pipe *bpp*
>>
>> Signed-off-by: Dhinakaran Pandiyan 
>
> Reviewed-by: Jani Nikula 

And pushed, thanks for the patch.

BR,
Jani.

>
>
>> ---
>>  drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
>> b/drivers/gpu/drm/i915/intel_hdmi.c
>> index 1d623b5..6efc3cb 100644
>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>> @@ -1392,7 +1392,7 @@ bool intel_hdmi_compute_config(struct intel_encoder 
>> *encoder,
>>  }
>>  
>>  if (!pipe_config->bw_constrained) {
>> -DRM_DEBUG_KMS("forcing pipe bpc to %i for HDMI\n", desired_bpp);
>> +DRM_DEBUG_KMS("forcing pipe bpp to %i for HDMI\n", desired_bpp);
>>  pipe_config->pipe_bpp = desired_bpp;
>>  }

-- 
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] drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes, v3.

[Maarten Lankhorst]

mode_valid() called from drm_helper_probe_single_connector_modes()
may need to look at connector->state because what a valid mode is may
depend on connector properties being set. For example some HDMI modes
might be rejected when a connector property forces the connector
into DVI mode.

Some implementations of detect() already lock all state,
so we have to pass an acquire_ctx to them to prevent a deadlock.

This means changing the function signature of detect() slightly,
and passing the acquire_ctx for locking multiple crtc's.
For the callbacks, it will always be non-zero. To allow callers
not to worry about this, drm_helper_probe_detect_ctx is added
which might handle -EDEADLK for you.

Changes since v1:
- Always set ctx parameter.
Changes since v2:
- Always take connection_mutex when probing.

Signed-off-by: Maarten Lankhorst 
Cc: Boris Brezillon 
---
 Fixed drm_helper_probe_detect,
 is this version better?
 drivers/gpu/drm/drm_probe_helper.c   | 100 ---
 drivers/gpu/drm/i915/intel_crt.c |  25 
 drivers/gpu/drm/i915/intel_display.c |  25 
 drivers/gpu/drm/i915/intel_dp.c  |  24 
 drivers/gpu/drm/i915/intel_drv.h |   8 +--
 drivers/gpu/drm/i915/intel_hotplug.c |   3 +-
 drivers/gpu/drm/i915/intel_tv.c  |  21 +++
 include/drm/drm_connector.h  |   5 ++
 include/drm/drm_crtc_helper.h|   3 +
 include/drm/drm_modeset_helper_vtables.h |  24 
 10 files changed, 175 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index efb5e5e8ce62..ba0160446aac 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -169,12 +169,73 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
 EXPORT_SYMBOL(drm_kms_helper_poll_enable);
 
 static enum drm_connector_status
-drm_connector_detect(struct drm_connector *connector, bool force)
+drm_helper_probe_detect_ctx(struct drm_connector *connector, bool force)
 {
-   return connector->funcs->detect ?
-   connector->funcs->detect(connector, force) :
-   connector_status_connected;
+   const struct drm_connector_helper_funcs *funcs = 
connector->helper_private;
+   struct drm_modeset_acquire_ctx ctx;
+   int ret;
+
+   drm_modeset_acquire_init(, 0);
+
+retry:
+   ret = drm_modeset_lock(>dev->mode_config.connection_mutex, 
);
+   if (!ret) {
+   if (funcs->detect_ctx)
+   ret = funcs->detect_ctx(connector, , force);
+   else if (connector->funcs->detect)
+   ret = connector->funcs->detect(connector, force);
+   else
+   ret = connector_status_connected;
+   }
+
+   if (ret == -EDEADLK) {
+   drm_modeset_backoff();
+   goto retry;
+   }
+
+   if (WARN_ON(ret < 0))
+   ret = connector_status_unknown;
+
+   drm_modeset_drop_locks();
+   drm_modeset_acquire_fini();
+
+   return ret;
+}
+
+/**
+ * drm_helper_probe_detect - probe connector status
+ * @connector: connector to probe
+ * @ctx: acquire_ctx, or NULL to let this function handle locking.
+ * @force: Whether destructive probe operations should be performed.
+ *
+ * This function calls the detect callbacks of the connector.
+ * This function returns drm_connector_status, or
+ * if @ctx is set, it might also return -EDEADLK.
+ */
+int
+drm_helper_probe_detect(struct drm_connector *connector,
+   struct drm_modeset_acquire_ctx *ctx,
+   bool force)
+{
+   const struct drm_connector_helper_funcs *funcs = 
connector->helper_private;
+   struct drm_device *dev = connector->dev;
+   int ret;
+
+   if (!ctx)
+   return drm_helper_probe_detect_ctx(connector, force);
+
+   ret = drm_modeset_lock(>mode_config.connection_mutex, ctx);
+   if (ret)
+   return ret;
+
+   if (funcs->detect_ctx)
+   return funcs->detect_ctx(connector, ctx, force);
+   else if (connector->funcs->detect)
+   return connector->funcs->detect(connector, force);
+   else
+   return connector_status_connected;
 }
+EXPORT_SYMBOL(drm_helper_probe_detect);
 
 /**
  * drm_helper_probe_single_connector_modes - get complete set of display modes
@@ -239,15 +300,27 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
struct drm_display_mode *mode;
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
-   int count = 0;
+   int count = 0, ret;
int mode_flags = 0;
bool verbose_prune = true;
enum drm_connector_status old_status;
+   struct drm_modeset_acquire_ctx ctx;
 

Re: [Intel-gfx] [PATCH] drm/i915: Typo fix - 'pipe bpc' to 'pipe bpp'

[Jani Nikula]

On Tue, 04 Apr 2017, Dhinakaran Pandiyan  wrote:
> Noticed this while I was looking at some debug output,
>  [drm:intel_hdmi_compute_config [i915]] picking bpc to 12 for HDMI output
>  [drm:intel_hdmi_compute_config [i915]] forcing pipe bpc to 36 for HDMI
>
> I believe the second line should be pipe *bpp*
>
> Signed-off-by: Dhinakaran Pandiyan 

Reviewed-by: Jani Nikula 


> ---
>  drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1d623b5..6efc3cb 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1392,7 +1392,7 @@ bool intel_hdmi_compute_config(struct intel_encoder 
> *encoder,
>   }
>  
>   if (!pipe_config->bw_constrained) {
> - DRM_DEBUG_KMS("forcing pipe bpc to %i for HDMI\n", desired_bpp);
> + DRM_DEBUG_KMS("forcing pipe bpp to %i for HDMI\n", desired_bpp);
>   pipe_config->pipe_bpp = desired_bpp;
>   }

-- 
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 V4] drm/i915: Enhanced disable access to stolen memory as a guest

[Jani Nikula]

On Wed, 05 Apr 2017, Daniel Vetter  wrote:
> On Wed, Apr 05, 2017 at 10:08:26AM +0800, Xiong Zhang wrote:
>> Stolen memory is in RMRR and has identity mapping in iommu, so
>> gt could access stolen memory in host OS. While RMRR isn't supported
>> by kvm, both EPT and guest iommu domain lack of maaping for stolen memory,
>> so both vcpu and gt couldn't access stolen memory in guest.
>> 
>> commit "04a68a3 drm/i915/gvt: Disable access to stolen memory as a guest"
>> isn't enough in IGD passthrough environment where vgt code doesn't run. This
>> patch detects i915 running as a guest through the existence of emulated ISA
>> bridge.
>> 
>> v2:GVT-g may run in non qemu (Zhenyu)
>> v3:Make commit message clear (Daniel)
>> v4:Fix typo  
>> 
>> References: c875d2c iommu/vt-d: Exclude devices using RMRRs from IOMMU API 
>> domains

What does it mean to References: a commit? The message text doesn't say
anything about this commit.

Does this patch fix commit 04a68a3 or c875d2c? If so, there should be a
Fixes: tag.

The canonical format for commit references is

04a68a35ce6d ("drm/i915/gvt: Disable access to stolen memory as a guest")
c875d2c1b808 ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API domains")

In particular, note that 12 digits is preferred for sha1 references to
avoid ambiguity in the kernel git repo.

>> Link: https://access.redhat.com/sites/default/files/attachments/rmrr-wp1.pdf

Please use References: for stuff like this. Link: is reserved for the
backlink to the patch and discussion.

>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99028
>> 
>> Signed-off-by: Xiong Zhang 
>> Reviewed-by: Zhenyu Wang 
>> Cc: sta...@vger.kernel.org

With a Fixes: tag it would be possible to decide which stable kernels to
backport to.

> Yeah, commit message is now much improved.

I'm sorry, but from the fixes backports POV it still lacks clarity. I
wouldn't know if and where this should be backported.


BR,
Jani.


>
> Reviewed-by: Daniel Vetter 
>
>> ---
>>  drivers/gpu/drm/i915/i915_drv.c| 1 +
>>  drivers/gpu/drm/i915/i915_drv.h| 1 +
>>  drivers/gpu/drm/i915/i915_gem_stolen.c | 4 ++--
>>  3 files changed, 4 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_drv.c 
>> b/drivers/gpu/drm/i915/i915_drv.c
>> index 03d9e45..8b807a9 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.c
>> +++ b/drivers/gpu/drm/i915/i915_drv.c
>> @@ -223,6 +223,7 @@ static void intel_detect_pch(struct drm_i915_private 
>> *dev_priv)
>>  PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
>>  pch->subsystem_device ==
>>  PCI_SUBDEVICE_ID_QEMU)) {
>> +dev_priv->run_on_qemu = true;
>>  dev_priv->pch_type =
>>  intel_virt_detect_pch(dev_priv);
>>  } else
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index a5947a4..ad95c87 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -2145,6 +2145,7 @@ struct drm_i915_private {
>>  struct intel_uncore uncore;
>>  
>>  struct i915_virtual_gpu vgpu;
>> +bool run_on_qemu;
>>  
>>  struct intel_gvt *gvt;
>>  
>> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
>> b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> index f3abdc2..6a011b0 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> @@ -409,8 +409,8 @@ int i915_gem_init_stolen(struct drm_i915_private 
>> *dev_priv)
>>  
>>  mutex_init(_priv->mm.stolen_lock);
>>  
>> -if (intel_vgpu_active(dev_priv)) {
>> -DRM_INFO("iGVT-g active, disabling use of stolen memory\n");
>> +if (dev_priv->run_on_qemu || intel_vgpu_active(dev_priv)) {
>> +DRM_INFO("Running in guest, disabling use of stolen memory\n");
>>  return 0;
>>  }
>>  
>> -- 
>> 1.9.1
>> 

-- 
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] [dim PATCH 4/4] dim: run executables in $PATH named dim-subcommand as dim subcommands

[Jani Nikula]

On Tue, 04 Apr 2017, Daniel Vetter  wrote:
> On Tue, Apr 04, 2017 at 04:59:02PM +0300, Jani Nikula wrote:
>> Similar to git. Don't allow override of internal commands though.
>
> git did this, and then went to a slightly different version because
> git doesn't complete to a space due to the various git-foo commands
> in path. Imo the right way to do this is to have a libexec/ subdir,
> complete just those (and switch the completion to recognize them), i.e.
> git foo would run maintainer-tools/libexec/git-foo or maybe
> maintainer-tools/git-foo. But not depend upon git-foo being in your path
> (because that is really annoying to me).

Agreed on the annoyance. But libexec is annoying too because it
precludes the user from adding their own extensions in $PATH. An
alternative is to mandate a *different* prefix for external dim
commands, for example external-dim-foo.

I'm not hung up on this patch anyway, it was just a quick idea in case
we want to add largish related tools without cluttering the already
pretty big dim source.

> Other cleanup patches are all acked.

Pushed those, thanks.

BR,
Jani.

> -Daniel
>> 
>> Signed-off-by: Jani Nikula 
>> ---
>>  dim | 6 ++
>>  1 file changed, 6 insertions(+)
>> 
>> diff --git a/dim b/dim
>> index 45dc07cd0426..85da1542087e 100755
>> --- a/dim
>> +++ b/dim
>> @@ -1907,6 +1907,12 @@ fi
>>  # look up the function by the subcommand name
>>  subcmd_func=dim_${subcmd//-/_}
>>  if ! declare -f $subcmd_func >/dev/null; then
>> +# look up dim-subcommand in PATH, and run it
>> +ext_subcmd=${subcmd_func//_/-}
>> +if hash $ext_subcmd 2>/dev/null; then
>> +exec $ext_subcmd "$@"
>> +fi
>> +
>>  echoerr "'$subcommand' is not a dim command."
>>  dim_usage
>>  exit 1
>> -- 
>> 2.1.4
>> 
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] linux-next: build warning after merge of the drm-misc tree

[Neil Armstrong]

On 04/05/2017 02:41 AM, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the drm-misc tree, today's linux-next build
> (arm_multi_v7_defconfig) produced this warning:
> 
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:608:13: warning: 
> 'hdmi_bus_fmt_is_yuv420' defined but not used [-Wunused-function]
>  static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
>  ^
> 
> Introduced by commit
> 
>   def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and 
> encodings")
> 

Hi,

I'm preparing a fix for that, sorry for the noise.

Thanks,
Neil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH V4] drm/i915: Enhanced disable access to stolen memory as a guest

[Daniel Vetter]

On Wed, Apr 05, 2017 at 10:08:26AM +0800, Xiong Zhang wrote:
> Stolen memory is in RMRR and has identity mapping in iommu, so
> gt could access stolen memory in host OS. While RMRR isn't supported
> by kvm, both EPT and guest iommu domain lack of maaping for stolen memory,
> so both vcpu and gt couldn't access stolen memory in guest.
> 
> commit "04a68a3 drm/i915/gvt: Disable access to stolen memory as a guest"
> isn't enough in IGD passthrough environment where vgt code doesn't run. This
> patch detects i915 running as a guest through the existence of emulated ISA
> bridge.
> 
> v2:GVT-g may run in non qemu (Zhenyu)
> v3:Make commit message clear (Daniel)
> v4:Fix typo   
> 
> References: c875d2c iommu/vt-d: Exclude devices using RMRRs from IOMMU API 
> domains
> Link: https://access.redhat.com/sites/default/files/attachments/rmrr-wp1.pdf
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99028
> 
> Signed-off-by: Xiong Zhang 
> Reviewed-by: Zhenyu Wang 
> Cc: sta...@vger.kernel.org

Yeah, commit message is now much improved.

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/i915_drv.c| 1 +
>  drivers/gpu/drm/i915/i915_drv.h| 1 +
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 4 ++--
>  3 files changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 03d9e45..8b807a9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -223,6 +223,7 @@ static void intel_detect_pch(struct drm_i915_private 
> *dev_priv)
>   PCI_SUBVENDOR_ID_REDHAT_QUMRANET &&
>   pch->subsystem_device ==
>   PCI_SUBDEVICE_ID_QEMU)) {
> + dev_priv->run_on_qemu = true;
>   dev_priv->pch_type =
>   intel_virt_detect_pch(dev_priv);
>   } else
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a5947a4..ad95c87 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2145,6 +2145,7 @@ struct drm_i915_private {
>   struct intel_uncore uncore;
>  
>   struct i915_virtual_gpu vgpu;
> + bool run_on_qemu;
>  
>   struct intel_gvt *gvt;
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
> b/drivers/gpu/drm/i915/i915_gem_stolen.c
> index f3abdc2..6a011b0 100644
> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
> @@ -409,8 +409,8 @@ int i915_gem_init_stolen(struct drm_i915_private 
> *dev_priv)
>  
>   mutex_init(_priv->mm.stolen_lock);
>  
> - if (intel_vgpu_active(dev_priv)) {
> - DRM_INFO("iGVT-g active, disabling use of stolen memory\n");
> + if (dev_priv->run_on_qemu || intel_vgpu_active(dev_priv)) {
> + DRM_INFO("Running in guest, disabling use of stolen memory\n");
>   return 0;
>   }
>  
> -- 
> 1.9.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/18] drm/i915: introduce drm_i915_gem_object page_size members

[Daniel Vetter]

On Tue, Apr 04, 2017 at 11:11:12PM +0100, Matthew Auld wrote:
> Signed-off-by: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/i915_gem.c| 5 +
>  drivers/gpu/drm/i915/i915_gem_object.h | 3 +++
>  2 files changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 4ca88f2539c0..cbf97f4bbb72 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2441,6 +2441,8 @@ static int i915_gem_object_get_pages(struct 
> drm_i915_gem_object *obj)
>   struct sg_table *pages;
>  
>   GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj));
> + GEM_BUG_ON(!is_valid_gtt_page_size(obj->page_size));
> + GEM_BUG_ON(!is_valid_gtt_page_size(obj->gtt_page_size));
>  
>   if (unlikely(obj->mm.madv != I915_MADV_WILLNEED)) {
>   DRM_DEBUG("Attempting to obtain a purgeable object\n");
> @@ -4159,6 +4161,9 @@ void i915_gem_object_init(struct drm_i915_gem_object 
> *obj,
>  
>   obj->ops = ops;
>  
> + obj->page_size = PAGE_SIZE;
> + obj->gtt_page_size = I915_GTT_PAGE_SIZE;
> +
>   reservation_object_init(>__builtin_resv);
>   obj->resv = >__builtin_resv;
>  
> diff --git a/drivers/gpu/drm/i915/i915_gem_object.h 
> b/drivers/gpu/drm/i915/i915_gem_object.h
> index 174cf923c236..b1dacbfe5173 100644
> --- a/drivers/gpu/drm/i915/i915_gem_object.h
> +++ b/drivers/gpu/drm/i915/i915_gem_object.h
> @@ -107,6 +107,9 @@ struct drm_i915_gem_object {
>   unsigned int cache_level:3;
>   unsigned int cache_dirty:1;
>  
> + unsigned int page_size; /* CPU pov - 4K(default), 2M, 1G */
> + unsigned int gtt_page_size; /* GPU pov - 4K(default), 64K, 2M, 1G */

Just kinda archecture review, with a long-term view: Is the plan to
eventually become more flexible here, i.e. allow mixed mode? We can of
course ask shmem to try really hard to give us huge pages, but at the end
it might not be able to give us a huge page (if the obj size isn't rounded
to 2M), and there's no hw reason to not map everything else as hugepage.
Through sg table coalescing we can cope with that, and we can check fairly
cheaply whether an entry is big enough to be eligible for huge page
mapping.

That also means in the pte functions we'd not make a top-level decision
whether to use huge entries or not, but do that at each level by looking
at the sg table. This should also make it easier for stolen, which is
always contiguous but rather often not size-rounded.

It's a bit more tricky for 64kb pages, but I think those only can be used
for an object which already has huge pages/is contiguous, but where the
size is only rounded to 64kb and not 2m (because 2m would wast too much
space). Then we can map the partial 2m using 64kb entries.

Just some long-term thoughts on this here, wher I expect things will head
towards eventually.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx