Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix hw state verifier access to crtc->state.

[Maarten Lankhorst]

Op 15-05-17 om 15:52 schreef Daniel Vetter:
> On Thu, May 11, 2017 at 11:41:22AM +0200, Maarten Lankhorst wrote:
>> Op 11-05-17 om 11:23 schreef Daniel Vetter:
>>> On Thu, May 11, 2017 at 10:28:43AM +0200, Maarten Lankhorst wrote:
 We shouldn't inspect crtc->state, instead grab the crtc state.
 At this point the hw state verifier should be able to run even if
 crtc->state has been updated (which cannot currently happen).

 Signed-off-by: Maarten Lankhorst 
>>> Reviewed-by: Daniel Vetter 
>>>
>>> pll state checking still looks at ->state directly, we might want to port
>>> that to the new private obj helpers perhaps, with the same new/old
>>> iterators?
>> That might be an excellent idea to do in the future. :)
>>
>> If I look at it though it's race safe in the current design,
>> but not necessarily against multiple nonblocking modesets,
>> which should probably be addressed at some point.
> I looked at this more from the pov of unifying state handling across all
> blocks. If everything works roughly the same, it's much easier to
> understand. And I do kinda like DK's private state stuff, that should help
> in aligning the various internal bits we have (like shared dpll, wms, and
> all that).
> -Daniel

Agreed, it should be something for unification.

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

Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to capture the state of the GPU

[Lofstedt, Marta]

I hereby pull-out this patch.
The idea of it was to know if we were already wedged at the beginning of 
testing, that would give us information on how to interpret silly results; such 
that test starting to get skipped and/or we got dmesg-warns/incomplete on tests 
that usually should be skipped.
Also, we are planning to soon deploy a piglit.conf solution where testing will 
be terminated on wedged, so I agree that my test isn't really needed.

/Marta

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, May 15, 2017 5:01 PM
> To: Chris Wilson ; Martin Peres
> ; Lofstedt, Marta
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to 
> capture
> the state of the GPU
> 
> On Fri, May 12, 2017 at 02:17:29PM +0100, Chris Wilson wrote:
> > The ABI for testing whether the device is wedged before use is
> > gem_throttle(). This is encapsulated into igt_require_gem() and any
> > test that depends upon execution on the GPU should be checking for GEM
> first.
> >
> > This test should just be
> > igt_gem_require(drm_open_driver(DRIVER_INTEL));
> 
> Well, how do you expect people to spot your nifty tools and refactorings if
> they don't show up on the m-l, don't get acks or reviews, and don't come
> with api-docs? At least neither gmail nor google did find that patch submitted
> anywhere.
> 
> Marta, can you pls review Chris' patch:
> 
> commit 9518cb59abe35143f15abac2b7ffdb99820ef53c
> Author: Chris Wilson 
> Date:   Wed Feb 22 15:24:54 2017 +
> 
> igt: Start marking up GEM tests that require an alive GPU to function
> 
> Best would be to check that all gem tests really use this, and then also add 
> abi
> docs for this new helper.
> 
> Also, since we have igt_require_gem() already, what's the value of this
> additional testcase? If we want to reboot machines if the gpu died, then we
> need to have such a test at a higher level, in piglit. What we could do is 
> add a
> special exit code to igt that indicates a runtime problem (and tells piglit to
> reboot), essentially PLEASE_REBOOT instead of SKIP (which is what
> igt_require_gem() results in).
> -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] New "RPM wakelock ref not held during HW access" in 4.12-rc1 ?

[Jani Nikula]

On Mon, 15 May 2017, Hans de Goede  wrote:
> Hi,
>
> I'm seeing this on suspend/resume on a GPD-win,
> cherrytrail z8700 device:

Ville, does

commit 668e3b014afb66ab29e134bca7c258527273ac75
Author: Ville Syrjälä 
Date:   Thu Apr 27 19:02:20 2017 +0300

drm/i915: Fix runtime PM for LPE audio

in drm-intel-fixes address this?

BR,
Jani.



>
> [   75.514651] RPM wakelock ref not held during HW access
> [   75.514827] [ cut here ]
> [   75.515025] WARNING: CPU: 2 PID: 1832 at 
> drivers/gpu/drm/i915/intel_drv.h:1780 fwtable_write32+0x1d3/0x240 [i915]
> ...
> [   75.515704] RIP: 0010:fwtable_write32+0x1d3/0x240 [i915]
> ...
> [   75.515767] Call Trace:
> [   75.515952]  lpe_audio_irq_unmask+0x6a/0xc0 [i915]
> [   75.515972]  irq_enable+0x3a/0x50
> [   75.515984]  __enable_irq+0x34/0x60
> [   75.515996]  resume_irqs+0x8f/0xd0
> [   75.516007]  resume_device_irqs+0x10/0x20
> [   75.516021]  dpm_resume_noirq+0x23e/0x310
> [   75.516041]  suspend_devices_and_enter+0x2f3/0x7f0
> [   75.516055]  ? finish_wait+0x80/0x80
> [   75.516067]  pm_suspend+0x335/0x3a0
> [   75.516078]  state_store+0x85/0xf0
> [   75.516095]  kobj_attr_store+0xf/0x20
> [   75.516108]  sysfs_kf_write+0x37/0x40
> [   75.516117]  kernfs_fop_write+0x11c/0x1a0
> [   75.516132]  __vfs_write+0x37/0x160
> [   75.516145]  ? selinux_file_permission+0xfb/0x120
> [   75.516158]  ? security_file_permission+0x3b/0xc0
> [   75.516169]  vfs_write+0xb1/0x1a0
> [   75.516180]  SyS_write+0x55/0xc0
> [   75.516197]  entry_SYSCALL_64_fastpath+0x1a/0xa5
> ...
> [   76.584235] PM: early resume of devices complete after 1067.477 msecs
>
> If someone has a fix for this they want me to try, let me know.
>
> Regards,
>
> Hans
> ___
> 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] [PATCH v2] drm/i915/gvt: disable GVT-g if host GuC submission is enabled

[Dong, Chuanxiao]

> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Dong, Chuanxiao
> Sent: Thursday, May 11, 2017 9:38 PM
> To: Joonas Lahtinen ; intel-gvt-
> d...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH v2] drm/i915/gvt: disable GVT-g if host GuC
> submission is enabled
> 
> 
> 
> > -Original Message-
> > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> > Sent: Thursday, May 11, 2017 8:50 PM
> > To: Dong, Chuanxiao ; intel-gvt-
> > d...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/gvt: disable GVT-g if
> > host GuC submission is enabled
> >
> > On to, 2017-05-11 at 02:33 +, Dong, Chuanxiao wrote:
> > >
> > > >
> > > > -Original Message-
> > > > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> > > > Sent: Wednesday, May 10, 2017 8:48 PM
> > > > To: Dong, Chuanxiao ; intel-gvt-
> > > > d...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
> > > > Subject: Re: [Intel-gfx] [PATCH v2] drm/i915/gvt: disable GVT-g if
> > > > host GuC submission is enabled
> > > >
> > > > On ti, 2017-05-09 at 18:11 +0800, Chuanxiao Dong wrote:
> > > > >
> > > > > Currently GVT-g cannot work properly when host GuC submission is
> > > > > enabled, so disable GVT in this case.
> > > > >
> > > > > v2: update the user message (Joonas)
> > > > >
> > > > > > > > Cc: Zhenyu Wang 
> > > > > > > > Signed-off-by: Chuanxiao Dong 
> > > > > ---
> > > > >  drivers/gpu/drm/i915/intel_gvt.c | 5 +
> > > > >  1 file changed, 5 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_gvt.c
> > > > > b/drivers/gpu/drm/i915/intel_gvt.c
> > > > > index e1ab643..d85742c 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_gvt.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_gvt.c
> > > > > @@ -84,6 +84,11 @@ int intel_gvt_init(struct drm_i915_private
> > *dev_priv)
> > > > >   goto bail;
> > > > >   }
> > > > >
> > > > > + if (i915.enable_guc_submission) {
> > > > > + DRM_INFO("GPU guest virtualisation [GVT-g]
> disabled as
> > > > Graphics virtualization is not yet supported with GuC submission
> > > > [i915.enable_guc_submission module parameter]\n");
> > > > >
> > > > > + goto bail;
> > > > > + }
> > > >
> > > > As discussed earlier, driver loading should fail with -EIO when
> > > > incompatible options are specified.
> > >
> > > Sorry for not getting why should fail with -EIO? By looking into the
> > > source, Intel_gvt_init is part of i915 driver loading, and fail with
> > > -EIO will make i915 driver failed to load.
> >
> > Yes, the user has specified an unsafe kernel configuration option,
> > enable_guc_submission and the driver can rightfully stop loading if
> > enable_gvt option was passed in the same command line.
> >
> Thanks Joonas. If to fail with -EIO, how about for the other two checks: " if
> (!is_supported_device(dev_priv))" and " if (!i915.enable_execlists)"?
> Currently these two cases are failed with 0 instead of -EIO. Looks like should
> also fail with -EIO?
> 
> For the gvt init failure case, it is also failed with 0 right now, which means
> that even gvt init is failed, i915 loading will be continue instead of failed 
> due
> to gvt. Right now we also want to fail with -EIO, right?
> 
Hi Joonas,

Do you have any suggestion on how to handle the above two cases? Or you only 
want to fail with -EIO for the guc case, and keep the original for the others?

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

Re: [Intel-gfx] [PATCH 05/20] drm/i915: Cancel reset-engine if we couldn't find an active request

[Chris Wilson]

On Mon, May 15, 2017 at 03:25:27PM -0700, Michel Thierry wrote:
> On 5/15/2017 2:47 PM, Chris Wilson wrote:
> >On Mon, May 15, 2017 at 10:31:58PM +0100, Chris Wilson wrote:
> >>On Mon, May 15, 2017 at 02:20:01PM -0700, Michel Thierry wrote:
> >>>@@ -2827,21 +2830,34 @@ int i915_gem_reset_prepare_engine(struct 
> >>>intel_engine_cs *engine)
> >>>
> >>>   if (engine_stalled(engine)) {
> >>>   request = i915_gem_find_active_request(engine);
> >>>-  if (request && request->fence.error == -EIO)
> >>>-  err = -EIO; /* Previous reset failed! */
> >>>+
> >>>+  if (request) {
> >>>+  if (request->fence.error == -EIO)
> >>>+  return ERR_PTR(-EIO); /* Previous reset failed! 
> >>>*/
> >>>+
> >>>+  if (__i915_gem_request_completed(request,
> >>>+   
> >>>engine->hangcheck.seqno))
> >>
> >>This is not the seqno for the request, so this is incorrect. It will
> >>judge that the request was preempted (as hangcheck.seqno must be less
> >>thn request->global_seqno) and so conclude that the request was never
> >>completed.
> >>
> >>You just want if (i915_gem_request_completed(request))
> 
> Thanks, I'll change the function.
> 
> >
> >Also not here. This pardon check should be deferred to the caller just
> >before commiting to thre reset. In the case of global reset, we want to
> >gather up all the engines' active requests first, complete our
> >preparations and then double check the engine was hung.
> 
> i915_reset_engine calls this directly, but 'full reset' [from
> i915_gem_reset_prepare()] would not be affected and it won't pardon
> anything... i915_gem_reset_engine is doing the double check you
> mention.

Aye, but in the long run I was thinking of capturing this request in
engine->hangcheck.active_request and then we reuse that info in the later
phases.
-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 v3] drm/i915: Split execlist priority queue into rbtree + linked list

[Tvrtko Ursulin]

On 15/05/2017 14:29, Chris Wilson wrote:

All the requests at the same priority are executed in FIFO order. They
do not need to be stored in the rbtree themselves, as they are a simple
list within a level. If we move the requests at one priority into a list,
we can then reduce the rbtree to the set of priorities. This should keep
the height of the rbtree small, as the number of active priorities can not
exceed the number of active requests and should be typically only a few.

Currently, we have ~2k possible different priority levels, that may
increase to allow even more fine grained selection. Allocating those in
advance seems a waste (and may be impossible), so we opt for allocating
upon first use, and freeing after its requests are depleted. To avoid
the possibility of an allocation failure causing us to lose a request,
we preallocate the default priority (0) and bump any request to that
priority if we fail to allocate it the appropriate plist. Having a
request (that is ready to run, so not leading to corruption) execute
out-of-order is better than leaking the request (and its dependency
tree) entirely.

There should be a benefit to reducing execlists_dequeue() to principally
using a simple list (and reducing the frequency of both rbtree iteration
and balancing on erase) but for typical workloads, request coalescing
should be small enough that we don't notice any change. The main gain is
from improving PI calls to schedule, and the explicit list within a
level should make request unwinding simpler (we just need to insert at
the head of the list rather than the tail and not have to make the
rbtree search more complicated).

v2: Avoid use-after-free when deleting a depleted priolist

v3: Michał found the solution to handling the allocation failure
gracefully. If we disable all priority scheduling following the
allocation failure, those requests will be executed in fifo and we will
ensure that this request and its dependencies are in strict fifo (even
when it doesn't realise it is only a single list). Normal scheduling is
restored once we know the device is idle, until the next failure!

Signed-off-by: Chris Wilson 
Cc: Michał Winiarski 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c|  11 +-
 drivers/gpu/drm/i915/i915_gem.c|   7 +-
 drivers/gpu/drm/i915/i915_gem_request.c|   4 +-
 drivers/gpu/drm/i915/i915_gem_request.h|   2 +-
 drivers/gpu/drm/i915/i915_guc_submission.c |  50 
 drivers/gpu/drm/i915/i915_utils.h  |   9 ++
 drivers/gpu/drm/i915/intel_engine_cs.c |  12 ++
 drivers/gpu/drm/i915/intel_lrc.c   | 184 +++--
 drivers/gpu/drm/i915/intel_ringbuffer.h|   9 ++
 9 files changed, 193 insertions(+), 95 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index f13b5b895a2b..553f016efe64 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3352,7 +3352,6 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)

if (i915.enable_execlists) {
u32 ptr, read, write;
-   struct rb_node *rb;
unsigned int idx;

seq_printf(m, "\tExeclist status: 0x%08x %08x\n",
@@ -3396,9 +3395,13 @@ static int i915_engine_info(struct seq_file *m, void 
*unused)
rcu_read_unlock();

spin_lock_irq(&engine->timeline->lock);
-   for (rb = engine->execlist_first; rb; rb = rb_next(rb)) 
{
-   rq = rb_entry(rb, typeof(*rq), priotree.node);
-   print_request(m, rq, "\t\tQ ");
+   for (rb = engine->execlist_first; rb; rb = rb_next(rb)){
+   struct i915_priolist *p =
+   rb_entry(rb, typeof(*p), node);
+
+   list_for_each_entry(rq, &p->requests,
+   priotree.link)
+   print_request(m, rq, "\t\tQ ");
}
spin_unlock_irq(&engine->timeline->lock);
} else if (INTEL_GEN(dev_priv) > 6) {
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 83518cdb19f3..07db08cc6be0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3155,8 +3155,6 @@ i915_gem_idle_work_handler(struct work_struct *work)
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv), gt.idle_work.work);
struct drm_device *dev = &dev_priv->drm;
-   struct intel_engine_cs *engine;
-   enum intel_engine_id id;
bool rearm_hangcheck;

if (!READ_ONCE(dev_priv->gt.awake))
@@ -3194,10 +3192,7 @@ i915_gem_idle_work_handler(struct work_struct *work)
if (wa

Re: [Intel-gfx] [PATCH 09/12] drm/i915: Create a kmem_cache to allocate struct i915_priolist from

[Tvrtko Ursulin]

On 11/05/2017 20:59, Chris Wilson wrote:

The i915_priolist are allocated within an atomic context on a path where
we wish to minimise latency. If we use a dedicated kmem_cache, we have
the advantage of a local freelist from which to service new requests
that should keep the latency impact of an allocation small. Though
currently we expect the majority of requests to be at default priority
(and so hit the preallocate priolist), once userspace starts using
priorities they are likely to use many fine grained policies improving
the utilisation of a private slab.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_drv.h| 1 +
 drivers/gpu/drm/i915/i915_gem.c| 9 -
 drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
 drivers/gpu/drm/i915/intel_lrc.c   | 4 ++--
 4 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ff3574a56812..7f192efbe088 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2027,6 +2027,7 @@ struct drm_i915_private {
struct kmem_cache *vmas;
struct kmem_cache *requests;
struct kmem_cache *dependencies;
+   struct kmem_cache *priorities;

const struct intel_device_info info;

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 75d7575b81f4..f52d72b1a5b4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4871,12 +4871,16 @@ i915_gem_load_init(struct drm_i915_private *dev_priv)
if (!dev_priv->dependencies)
goto err_requests;

+   dev_priv->priorities = KMEM_CACHE(i915_priolist, SLAB_HWCACHE_ALIGN);
+   if (!dev_priv->priorities)
+   goto err_dependencies;
+
mutex_lock(&dev_priv->drm.struct_mutex);
INIT_LIST_HEAD(&dev_priv->gt.timelines);
err = i915_gem_timeline_init__global(dev_priv);
mutex_unlock(&dev_priv->drm.struct_mutex);
if (err)
-   goto err_dependencies;
+   goto err_priorities;

INIT_LIST_HEAD(&dev_priv->context_list);
INIT_WORK(&dev_priv->mm.free_work, __i915_gem_free_work);
@@ -4900,6 +4904,8 @@ i915_gem_load_init(struct drm_i915_private *dev_priv)

return 0;

+err_priorities:
+   kmem_cache_destroy(dev_priv->priorities);
 err_dependencies:
kmem_cache_destroy(dev_priv->dependencies);
 err_requests:
@@ -4923,6 +4929,7 @@ void i915_gem_load_cleanup(struct drm_i915_private 
*dev_priv)
WARN_ON(!list_empty(&dev_priv->gt.timelines));
mutex_unlock(&dev_priv->drm.struct_mutex);

+   kmem_cache_destroy(dev_priv->priorities);
kmem_cache_destroy(dev_priv->dependencies);
kmem_cache_destroy(dev_priv->requests);
kmem_cache_destroy(dev_priv->vmas);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 440bab856cc2..53c022c47687 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -704,7 +704,7 @@ static bool i915_guc_dequeue(struct intel_engine_cs *engine)
rb_erase(&p->node, &engine->execlist_queue);
INIT_LIST_HEAD(&p->requests);
if (p->priority != I915_PRIORITY_NORMAL)
-   kfree(p);
+   kmem_cache_free(engine->i915->priorities, p);
}
 done:
engine->execlist_first = rb;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 849b35796de7..7e41529bd074 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -500,7 +500,7 @@ static void execlists_dequeue(struct intel_engine_cs 
*engine)
rb_erase(&p->node, &engine->execlist_queue);
INIT_LIST_HEAD(&p->requests);
if (p->priority != I915_PRIORITY_NORMAL)
-   kfree(p);
+   kmem_cache_free(engine->i915->priorities, p);
}
 done:
engine->execlist_first = rb;
@@ -659,7 +659,7 @@ insert_request(struct intel_engine_cs *engine,
if (prio == I915_PRIORITY_NORMAL) {
p = &engine->default_priolist;
} else {
-   p = kmalloc(sizeof(*p), GFP_ATOMIC);
+   p = kmem_cache_alloc(engine->i915->priorities, GFP_ATOMIC);
/* Convert an allocation failure to a priority bump */
if (unlikely(!p)) {
prio = I915_PRIORITY_NORMAL; /* recurses just once */



Reviewed-by: Tvrtko Ursulin 

Regards,

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

[Intel-gfx] [PATCH 1/2] gpu: drm: i915: remove dead code

[Gustavo A. R. Silva]

Local variable has_reduced_clock is assigned to a constant value and it is
never updated again. Remove this variable and the dead code it guards.

Addresses-Coverity-ID: 1362230
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/i915/intel_display.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index ed1f4f2..b13b53b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9565,8 +9565,6 @@ static int ironlake_crtc_compute_clock(struct intel_crtc 
*crtc,
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct dpll reduced_clock;
-   bool has_reduced_clock = false;
struct intel_shared_dpll *pll;
const struct intel_limit *limit;
int refclk = 12;
@@ -9609,8 +9607,7 @@ static int ironlake_crtc_compute_clock(struct intel_crtc 
*crtc,
return -EINVAL;
}
 
-   ironlake_compute_dpll(crtc, crtc_state,
- has_reduced_clock ? &reduced_clock : NULL);
+   ironlake_compute_dpll(crtc, crtc_state, NULL);
 
pll = intel_get_shared_dpll(crtc, crtc_state, NULL);
if (pll == NULL) {
@@ -9619,10 +9616,6 @@ static int ironlake_crtc_compute_clock(struct intel_crtc 
*crtc,
return -EINVAL;
}
 
-   if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_LVDS) &&
-   has_reduced_clock)
-   crtc->lowfreq_avail = true;
-
return 0;
 }
 
-- 
2.5.0

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

[Intel-gfx] [PATCH 2/2] gpu: drm: i915: compress logic into one line

[Gustavo A. R. Silva]

Simplify logic to avoid unnecessary variable declaration and assignment.

Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/i915/intel_display.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b13b53b..ca6479a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9565,7 +9565,6 @@ static int ironlake_crtc_compute_clock(struct intel_crtc 
*crtc,
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_shared_dpll *pll;
const struct intel_limit *limit;
int refclk = 12;
 
@@ -9609,8 +9608,7 @@ static int ironlake_crtc_compute_clock(struct intel_crtc 
*crtc,
 
ironlake_compute_dpll(crtc, crtc_state, NULL);
 
-   pll = intel_get_shared_dpll(crtc, crtc_state, NULL);
-   if (pll == NULL) {
+   if (!intel_get_shared_dpll(crtc, crtc_state, NULL)) {
DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
 pipe_name(crtc->pipe));
return -EINVAL;
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to capture the state of the GPU

[Chris Wilson]

On Tue, May 16, 2017 at 07:42:51AM +, Lofstedt, Marta wrote:
> I hereby pull-out this patch.
> The idea of it was to know if we were already wedged at the beginning of 
> testing, that would give us information on how to interpret silly results; 
> such that test starting to get skipped and/or we got dmesg-warns/incomplete 
> on tests that usually should be skipped.
> Also, we are planning to soon deploy a piglit.conf solution where testing 
> will be terminated on wedged, so I agree that my test isn't really needed.

Not everything is broken by wedged; internally we just use that as an
indicator that GEM is hosed. KMS should still work, we must still be
able to drive the displays to show the error and keep the servers alive
until the data is saved (and hopefully gracefully degrade that we don't
have to interrupt their immediate session).

Whilst that may be out of scope for BAT, it should not be completely
beyond us for robustness testing.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 00/17] add support for huge-gtt-pages

[Matthew Auld]

Adds support for 64K, 2M and 1G pages for the 48b PPGTT. We select the largest
gtt page size which fits the layout of the sg table. To complement this we also
request THP for our shmem backed objects, which should be able to give us 2M or
1G pages depending on configuration.

Hopefully this addresses the concerns from the last version. 

Matthew Auld (17):
  drm/i915: introduce page_size_mask to dev_info
  drm/i915: introduce gtt page size
  drm/i915: align the vma start to the gtt page size
  drm/i915: align 64K objects to 2M
  drm/i915: fallback to normal pages on vma insert failure
  mm/shmem: expose driver overridable huge option
  drm/i915: request THP for shmem backed objects
  drm/i915: pass gtt page size to insert_entries
  drm/i915: enable IPS bit for 64K pages
  drm/i915: support inserting 64K pages into the 48b PPGTT
  drm/i915: disable GTT cache for 2M/1G pages
  drm/i915: support inserting 2M pages into the 48b PPGTT
  drm/i915: support inserting 1G pages into the 48b PPGTT
  drm/i915/debugfs: include some gtt_page_size metrics
  drm/i915: enable platform support for 64K pages
  drm/i915: enable platform support for 2M pages
  drm/i915: enable platform support for 1G pages

 drivers/gpu/drm/i915/i915_debugfs.c  |  37 +++-
 drivers/gpu/drm/i915/i915_drv.h  |   3 +
 drivers/gpu/drm/i915/i915_gem.c  |  44 +
 drivers/gpu/drm/i915/i915_gem_gtt.c  | 206 ++-
 drivers/gpu/drm/i915/i915_gem_gtt.h  |  14 +-
 drivers/gpu/drm/i915/i915_gem_object.h   |   2 +
 drivers/gpu/drm/i915/i915_pci.c  |  29 
 drivers/gpu/drm/i915/i915_reg.h  |   3 +
 drivers/gpu/drm/i915/i915_vma.c  |  36 
 drivers/gpu/drm/i915/intel_pm.c  |  12 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c|   3 +-
 drivers/gpu/drm/i915/selftests/mock_gem_device.c |   6 +
 drivers/gpu/drm/i915/selftests/mock_gtt.c|   1 +
 include/linux/shmem_fs.h |  20 +++
 mm/shmem.c   |  37 ++--
 15 files changed, 416 insertions(+), 37 deletions(-)

-- 
2.9.4

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

[Intel-gfx] [PATCH 01/17] drm/i915: introduce page_size_mask to dev_info

[Matthew Auld]

In preparation for huge gtt pages expose a page_size_mask as part of the
device info, to indicate the page sizes supported by the HW.  Currently
only 4K is supported.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 +
 drivers/gpu/drm/i915/i915_gem_gtt.h  |  8 +++-
 drivers/gpu/drm/i915/i915_pci.c  | 21 +
 drivers/gpu/drm/i915/selftests/mock_gem_device.c |  3 +++
 4 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a6f20471b4cd..e18f11f77f35 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -791,6 +791,7 @@ struct intel_device_info {
enum intel_platform platform;
u8 ring_mask; /* Rings supported by the HW */
u8 num_rings;
+   unsigned int page_size_mask; /* page sizes supported by the HW */
 #define DEFINE_FLAG(name) u8 name:1
DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG);
 #undef DEFINE_FLAG
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index fb15684c1d83..f8db231c28aa 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -42,7 +42,13 @@
 #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_MIN_ALIGNMENT I915_GTT_PAGE_SIZE
 
 #define I915_FENCE_REG_NONE -1
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f80db2ccd92f..7caccb5bf963 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ 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_SIZES \
+   .page_size_mask = I915_GTT_PAGE_SIZE_4K
+
 #define GEN2_FEATURES \
.gen = 2, .num_pipes = 1, \
.has_overlay = 1, .overlay_needs_physical = 1, \
@@ -64,6 +68,7 @@
.unfenced_needs_alignment = 1, \
.ring_mask = RENDER_RING, \
GEN_DEFAULT_PIPEOFFSETS, \
+   GEN_DEFAULT_PAGE_SIZES, \
CURSOR_OFFSETS
 
 static const struct intel_device_info intel_i830_info = {
@@ -96,6 +101,7 @@ static const struct intel_device_info intel_i865g_info = {
.has_gmch_display = 1, \
.ring_mask = RENDER_RING, \
GEN_DEFAULT_PIPEOFFSETS, \
+   GEN_DEFAULT_PAGE_SIZES, \
CURSOR_OFFSETS
 
 static const struct intel_device_info intel_i915g_info = {
@@ -158,6 +164,7 @@ static const struct intel_device_info intel_pineview_info = 
{
.has_gmch_display = 1, \
.ring_mask = RENDER_RING, \
GEN_DEFAULT_PIPEOFFSETS, \
+   GEN_DEFAULT_PAGE_SIZES, \
CURSOR_OFFSETS
 
 static const struct intel_device_info intel_i965g_info = {
@@ -198,6 +205,7 @@ static const struct intel_device_info intel_gm45_info = {
.has_gmbus_irq = 1, \
.ring_mask = RENDER_RING | BSD_RING, \
GEN_DEFAULT_PIPEOFFSETS, \
+   GEN_DEFAULT_PAGE_SIZES, \
CURSOR_OFFSETS
 
 static const struct intel_device_info intel_ironlake_d_info = {
@@ -222,6 +230,7 @@ static const struct intel_device_info intel_ironlake_m_info 
= {
.has_gmbus_irq = 1, \
.has_aliasing_ppgtt = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
+   GEN_DEFAULT_PAGE_SIZES, \
CURSOR_OFFSETS
 
 static const struct intel_device_info intel_sandybridge_d_info = {
@@ -247,6 +256,7 @@ static const struct intel_device_info 
intel_sandybridge_m_info = {
.has_aliasing_ppgtt = 1, \
.has_full_ppgtt = 1, \
GEN_DEFAULT_PIPEOFFSETS, \
+   GEN_DEFAULT_PAGE_SIZES, \
IVB_CURSOR_OFFSETS
 
 static const struct intel_device_info intel_ivybridge_d_info = {
@@ -284,6 +294,7 @@ static const struct intel_device_info intel_valleyview_info 
= {
.has_full_ppgtt = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING,
.display_mmio_offset = VLV_DISPLAY_BASE,
+   GEN_DEFAULT_PAGE_SIZES,
GEN_DEFAULT_PIPEOFFSETS,
CURSOR_OFFSETS
 };
@@ -308,6 +319,7 @@ static const struct intel_device_info intel_haswell_info = {
 #define BDW_FEATURES \
HSW_FEATURES, \
BDW_COLORS, \
+   GEN_DEFAULT_PAGE_SIZES, \
.has_logical_ring_contexts = 1, \
.has_full_48bit_ppgtt = 1, \
.has_64bit_reloc = 1
@@ -342,13 +354,18 @@ static const struct intel_device_info 
intel_cherryview_info = {
.has_aliasing_ppgtt = 1,
.has_full_ppgtt = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
+   GEN_DEFAULT_PAGE_SIZES,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
CHV_COLORS,
 };
 
+#define 

[Intel-gfx] [PATCH 02/17] drm/i915: introduce gtt page size

[Matthew Auld]

In preparation for supporting huge gtt pages for the ppgtt, we introduce
a gtt_page_size member for gem objects.  We fill in the gtt page size by
scanning the sg table to determine the max page size which satisfies the
alignment for each sg entry.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_drv.h|  2 ++
 drivers/gpu/drm/i915/i915_gem.c| 23 +++
 drivers/gpu/drm/i915/i915_gem_object.h |  2 ++
 3 files changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e18f11f77f35..a7a108d18a2d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2843,6 +2843,8 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define USES_PPGTT(dev_priv)   (i915.enable_ppgtt)
 #define USES_FULL_PPGTT(dev_priv)  (i915.enable_ppgtt >= 2)
 #define USES_FULL_48BIT_PPGTT(dev_priv)(i915.enable_ppgtt == 3)
+#define HAS_PAGE_SIZE(dev_priv, page_size) \
+   ((dev_priv)->info.page_size_mask & (page_size))
 
 #define HAS_OVERLAY(dev_priv)   ((dev_priv)->info.has_overlay)
 #define OVERLAY_NEEDS_PHYSICAL(dev_priv) \
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0c1cbe98c994..6a5e864d7710 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2294,6 +2294,8 @@ void __i915_gem_object_put_pages(struct 
drm_i915_gem_object *obj,
if (!IS_ERR(pages))
obj->ops->put_pages(obj, pages);
 
+   obj->gtt_page_size = 0;
+
 unlock:
mutex_unlock(&obj->mm.lock);
 }
@@ -2473,6 +2475,13 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
 void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
 struct sg_table *pages)
 {
+   struct drm_i915_private *i915 = to_i915(obj->base.dev);
+   unsigned long supported_page_sizes = INTEL_INFO(i915)->page_size_mask;
+   struct scatterlist *sg;
+   unsigned int sg_mask = 0;
+   unsigned int i;
+   unsigned int bit;
+
lockdep_assert_held(&obj->mm.lock);
 
obj->mm.get_page.sg_pos = pages->sgl;
@@ -2486,6 +2495,20 @@ void __i915_gem_object_set_pages(struct 
drm_i915_gem_object *obj,
__i915_gem_object_pin_pages(obj);
obj->mm.quirked = true;
}
+
+   for_each_sg(pages->sgl, sg, pages->nents, i)
+   sg_mask |= sg->length;
+
+   GEM_BUG_ON(!sg_mask);
+
+   for_each_set_bit(bit, &supported_page_sizes, BITS_PER_LONG) {
+   if (!IS_ALIGNED(sg_mask, 1 << bit))
+   break;
+
+   obj->gtt_page_size = 1 << bit;
+   }
+
+   GEM_BUG_ON(!HAS_PAGE_SIZE(i915, obj->gtt_page_size));
 }
 
 static int i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/i915_gem_object.h 
b/drivers/gpu/drm/i915/i915_gem_object.h
index 174cf923c236..75beb6a79635 100644
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -107,6 +107,8 @@ struct drm_i915_gem_object {
unsigned int cache_level:3;
unsigned int cache_dirty:1;
 
+   unsigned int gtt_page_size;
+
atomic_t frontbuffer_bits;
unsigned int frontbuffer_ggtt_origin; /* write once */
struct i915_gem_active frontbuffer_write;
-- 
2.9.4

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

[Intel-gfx] [PATCH 11/17] drm/i915: disable GTT cache for 2M/1G pages

[Matthew Auld]

When SW enables the use of 2M/1G pages, it must disable the GTT cache.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_pm.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ef0e9f8d4dbd..b39b8d394179 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -8178,10 +8178,10 @@ static void broadwell_init_clock_gating(struct 
drm_i915_private *dev_priv)
 
/*
 * WaGttCachingOffByDefault:bdw
-* GTT cache may not work with big pages, so if those
-* are ever enabled GTT cache may need to be disabled.
+* The GTT cache must be disabled if the system is planning to use
+* 2M/1G pages.
 */
-   I915_WRITE(HSW_GTT_CACHE_EN, GTT_CACHE_EN_ALL);
+   I915_WRITE(HSW_GTT_CACHE_EN, 0);
 
/* WaKVMNotificationOnConfigChange:bdw */
I915_WRITE(CHICKEN_PAR2_1, I915_READ(CHICKEN_PAR2_1)
@@ -8457,10 +8457,10 @@ static void cherryview_init_clock_gating(struct 
drm_i915_private *dev_priv)
gen8_set_l3sqc_credits(dev_priv, 38, 2);
 
/*
-* GTT cache may not work with big pages, so if those
-* are ever enabled GTT cache may need to be disabled.
+* The GTT cache must be disabled if the system is planning to use
+* 2M/1G pages.
 */
-   I915_WRITE(HSW_GTT_CACHE_EN, GTT_CACHE_EN_ALL);
+   I915_WRITE(HSW_GTT_CACHE_EN, 0);
 }
 
 static void g4x_init_clock_gating(struct drm_i915_private *dev_priv)
-- 
2.9.4

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

[Intel-gfx] [PATCH 06/17] mm/shmem: expose driver overridable huge option

[Matthew Auld]

In i915 we are aiming to support huge GTT pages for the GPU, and to
complement this we also want to enable THP for our shmem backed objects.
Even though THP is supported in shmemfs it can only be enabled through
the huge= mount option, but for users of the kernel mounted shm_mnt like
i915, we are a little stuck. There is the sysfs knob shmem_enabled to
either forcefully enable/disable the feature, but that seems to only be
useful for testing purposes. What we propose is to expose a driver
overridable huge option as part of shmem_inode_info to control the use
of THP for a given mapping.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Dave Hansen 
Cc: Daniel Vetter 
Cc: Hugh Dickins 
Cc: linux...@kvack.org
---
 include/linux/shmem_fs.h | 20 
 mm/shmem.c   | 37 +++--
 2 files changed, 35 insertions(+), 22 deletions(-)

diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h
index a7d6bd2a918f..4cfdb2e8e1d8 100644
--- a/include/linux/shmem_fs.h
+++ b/include/linux/shmem_fs.h
@@ -21,8 +21,28 @@ struct shmem_inode_info {
struct shared_policypolicy; /* NUMA memory alloc policy */
struct simple_xattrsxattrs; /* list of xattrs */
struct inodevfs_inode;
+   unsigned char   huge;   /* driver override sbinfo->huge 
*/
 };
 
+/*
+ * Definitions for "huge tmpfs": tmpfs mounted with the huge= option
+ *
+ * SHMEM_HUGE_NEVER:
+ * disables huge pages for the mount;
+ * SHMEM_HUGE_ALWAYS:
+ * enables huge pages for the mount;
+ * SHMEM_HUGE_WITHIN_SIZE:
+ * only allocate huge pages if the page will be fully within i_size,
+ * also respect fadvise()/madvise() hints;
+ * SHMEM_HUGE_ADVISE:
+ * only allocate huge pages if requested with fadvise()/madvise();
+ */
+
+#define SHMEM_HUGE_NEVER   0
+#define SHMEM_HUGE_ALWAYS  1
+#define SHMEM_HUGE_WITHIN_SIZE 2
+#define SHMEM_HUGE_ADVISE  3
+
 struct shmem_sb_info {
unsigned long max_blocks;   /* How many blocks are allowed */
struct percpu_counter used_blocks;  /* How many are allocated */
diff --git a/mm/shmem.c b/mm/shmem.c
index e67d6ba4e98e..4fa042694957 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -346,25 +346,6 @@ static bool shmem_confirm_swap(struct address_space 
*mapping,
 }
 
 /*
- * Definitions for "huge tmpfs": tmpfs mounted with the huge= option
- *
- * SHMEM_HUGE_NEVER:
- * disables huge pages for the mount;
- * SHMEM_HUGE_ALWAYS:
- * enables huge pages for the mount;
- * SHMEM_HUGE_WITHIN_SIZE:
- * only allocate huge pages if the page will be fully within i_size,
- * also respect fadvise()/madvise() hints;
- * SHMEM_HUGE_ADVISE:
- * only allocate huge pages if requested with fadvise()/madvise();
- */
-
-#define SHMEM_HUGE_NEVER   0
-#define SHMEM_HUGE_ALWAYS  1
-#define SHMEM_HUGE_WITHIN_SIZE 2
-#define SHMEM_HUGE_ADVISE  3
-
-/*
  * Special values.
  * Only can be set via /sys/kernel/mm/transparent_hugepage/shmem_enabled:
  *
@@ -1715,6 +1696,8 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t 
index,
swap_free(swap);
 
} else {
+   unsigned char sbinfo_huge = sbinfo->huge;
+
if (vma && userfaultfd_missing(vma)) {
*fault_type = handle_userfault(vmf, VM_UFFD_MISSING);
return 0;
@@ -1727,7 +1710,10 @@ static int shmem_getpage_gfp(struct inode *inode, 
pgoff_t index,
goto alloc_nohuge;
if (shmem_huge == SHMEM_HUGE_FORCE)
goto alloc_huge;
-   switch (sbinfo->huge) {
+   /* driver override sbinfo->huge */
+   if (info->huge)
+   sbinfo_huge = info->huge;
+   switch (sbinfo_huge) {
loff_t i_size;
pgoff_t off;
case SHMEM_HUGE_NEVER:
@@ -2032,10 +2018,13 @@ unsigned long shmem_get_unmapped_area(struct file *file,
 
if (shmem_huge != SHMEM_HUGE_FORCE) {
struct super_block *sb;
+   unsigned char sbinfo_huge = 0;
 
if (file) {
VM_BUG_ON(file->f_op != &shmem_file_operations);
sb = file_inode(file)->i_sb;
+   /* driver override sbinfo->huge */
+   sbinfo_huge = SHMEM_I(file_inode(file))->huge;
} else {
/*
 * Called directly from mm/mmap.c, or drivers/char/mem.c
@@ -2045,7 +2034,8 @@ unsigned long shmem_get_unmapped_area(struct file *file,
return addr;
sb = shm_mnt->mnt_sb;
}
-   if (SHMEM_SB(sb)->huge == SHMEM_HUGE_NEVER)
+   if (SHMEM_SB(sb)->huge == SHMEM_HUGE_NEVER &&
+   sbinfo_huge == SHMEM_HUGE_NEVER)

[Intel-gfx] [PATCH 07/17] drm/i915: request THP for shmem backed objects

[Matthew Auld]

Default to transparent-huge-pages for shmem backed objects through the
SHMEM_HUGE_WITHIN_SIZE huge option. Best effort only.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Dave Hansen 
Cc: Daniel Vetter 
Cc: Hugh Dickins 
Cc: linux...@kvack.org
---
 drivers/gpu/drm/i915/i915_gem.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6a5e864d7710..e4ee54f0f55f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4308,6 +4308,16 @@ i915_gem_object_create(struct drm_i915_private 
*dev_priv, u64 size)
mapping = obj->base.filp->f_mapping;
mapping_set_gfp_mask(mapping, mask);
 
+   /* If configured attempt to use THP through shmemfs. This will
+* effectively default to huge-pages for this mapping if it makes sense
+* given the object size and HPAGE_PMD_SIZE. This is best effort only.
+*/
+#ifdef CONFIG_TRANSPARENT_HUGE_PAGECACHE
+   if (has_transparent_hugepage() &&
+   HAS_PAGE_SIZE(dev_priv, HPAGE_PMD_SIZE))
+   SHMEM_I(mapping->host)->huge = SHMEM_HUGE_WITHIN_SIZE;
+#endif
+
i915_gem_object_init(obj, &i915_gem_object_ops);
 
obj->base.write_domain = I915_GEM_DOMAIN_CPU;
-- 
2.9.4

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

[Intel-gfx] [PATCH 08/17] drm/i915: pass gtt page size to insert_entries

[Matthew Auld]

Expose a page size parameter for insert_entries, this is only relevant
for inserting into the 4lvl ppgtt where we pass the gtt_page_size of the
object.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 32 +++
 drivers/gpu/drm/i915/i915_gem_gtt.h   |  1 +
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  3 ++-
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  1 +
 4 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index bc3c63e92c16..3be3cbfb6d28 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -210,7 +210,8 @@ static int ppgtt_bind_vma(struct i915_vma *vma,
pte_flags |= PTE_READ_ONLY;
 
vma->vm->insert_entries(vma->vm, vma->pages, vma->node.start,
-   cache_level, pte_flags);
+   vma->obj->gtt_page_size, cache_level,
+   pte_flags);
 
return 0;
 }
@@ -911,6 +912,7 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt,
 static void gen8_ppgtt_insert_3lvl(struct i915_address_space *vm,
   struct sg_table *pages,
   u64 start,
+  unsigned int page_size,
   enum i915_cache_level cache_level,
   u32 unused)
 {
@@ -929,6 +931,7 @@ static void gen8_ppgtt_insert_3lvl(struct 
i915_address_space *vm,
 static void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm,
   struct sg_table *pages,
   u64 start,
+  unsigned int page_size,
   enum i915_cache_level cache_level,
   u32 unused)
 {
@@ -940,9 +943,24 @@ static void gen8_ppgtt_insert_4lvl(struct 
i915_address_space *vm,
};
struct i915_page_directory_pointer **pdps = ppgtt->pml4.pdps;
struct gen8_insert_pte idx = gen8_insert_pte(start);
+   bool (*insert_entries)(struct i915_hw_ppgtt *ppgtt,
+  struct i915_page_directory_pointer *pdp,
+  struct sgt_dma *iter,
+  struct gen8_insert_pte *idx,
+  enum i915_cache_level cache_level);
+
+   /* TODO: turn this into vfunc */
+   switch (page_size) {
+   case I915_GTT_PAGE_SIZE_4K:
+   insert_entries = gen8_ppgtt_insert_pte_entries;
+   break;
+   default:
+   MISSING_CASE(page_size);
+   return;
+   }
 
-   while (gen8_ppgtt_insert_pte_entries(ppgtt, pdps[idx.pml4e++], &iter,
-&idx, cache_level))
+   while (insert_entries(ppgtt, pdps[idx.pml4e++], &iter, &idx,
+ cache_level))
GEM_BUG_ON(idx.pml4e >= GEN8_PML4ES_PER_PML4);
 }
 
@@ -1625,6 +1643,7 @@ static void gen6_ppgtt_clear_range(struct 
i915_address_space *vm,
 static void gen6_ppgtt_insert_entries(struct i915_address_space *vm,
  struct sg_table *pages,
  u64 start,
+ unsigned int page_size,
  enum i915_cache_level cache_level,
  u32 flags)
 {
@@ -2098,6 +2117,7 @@ static void gen8_ggtt_insert_page(struct 
i915_address_space *vm,
 static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
 struct sg_table *st,
 u64 start,
+unsigned int page_size,
 enum i915_cache_level level,
 u32 unused)
 {
@@ -2145,6 +2165,7 @@ static void gen6_ggtt_insert_page(struct 
i915_address_space *vm,
 static void gen6_ggtt_insert_entries(struct i915_address_space *vm,
 struct sg_table *st,
 u64 start,
+unsigned int page_size,
 enum i915_cache_level level,
 u32 flags)
 {
@@ -2229,6 +2250,7 @@ static void i915_ggtt_insert_page(struct 
i915_address_space *vm,
 static void i915_ggtt_insert_entries(struct i915_address_space *vm,
 struct sg_table *pages,
 u64 start,
+unsigned int page_size,
 enum i915_cache_level cache_level,
 u32 unused)
 {
@@ -2265,7 +2287,7 @@ static int ggtt_bind_vma(struct i915_vma *vma,
 
intel_runtime

[Intel-gfx] [PATCH 05/17] drm/i915: fallback to normal pages on vma insert failure

[Matthew Auld]

Part of the cost in choosing huge-gtt-pages is potentially using a
larger alignment and/or size. Therefore if our vma insert fails either
because of the insert/reserve or the pin-offset-fixed we should fallback
to normal pages and retry before giving up.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_vma.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index d2e8edd351cf..9d4ffd76184e 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -427,6 +427,8 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
 {
struct drm_i915_private *dev_priv = vma->vm->i915;
struct drm_i915_gem_object *obj = vma->obj;
+   u64 requested_alignment;
+   u64 requested_size;
u64 start, end;
int ret;
 
@@ -471,6 +473,9 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
if (ret)
return ret;
 
+   requested_alignment = alignment;
+   requested_size = size;
+
if (i915_vm_is_48bit(vma->vm) &&
obj->gtt_page_size > I915_GTT_PAGE_SIZE) {
unsigned int page_alignment = obj->gtt_page_size;
@@ -488,6 +493,7 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
GEM_BUG_ON(!IS_ALIGNED(vma->size, obj->gtt_page_size));
}
 
+retry_insert:
if (flags & PIN_OFFSET_FIXED) {
u64 offset = flags & PIN_OFFSET_MASK;
if (!IS_ALIGNED(offset, alignment) ||
@@ -522,6 +528,19 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
return 0;
 
 err_unpin:
+   /* We try to use huge-gtt-pages whenever we can, but part of the cost
+* is that we may need adjust the alignment and possibly the size
+* before we insert into a vm, and so we should always fallback and
+* retry without huge-gtt-pages if we ever encounter a failure, before
+* giving up.
+*/
+   if (alignment > requested_alignment || size > requested_size) {
+   obj->gtt_page_size = I915_GTT_PAGE_SIZE;
+   alignment = requested_alignment;
+   size = requested_size;
+   goto retry_insert;
+   }
+
i915_gem_object_unpin_pages(obj);
return ret;
 }
-- 
2.9.4

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

[Intel-gfx] [PATCH 13/17] drm/i915: support inserting 1G pages into the 48b PPGTT

[Matthew Auld]

To enable 1G pages we set the PS bit in the PDPE, aka PDPE[7] to
indicate a 1G page, and not a PD.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 47 +
 drivers/gpu/drm/i915/i915_gem_gtt.h |  2 ++
 2 files changed, 49 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 3dadb501daa6..e81c78ffbea5 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -854,6 +854,50 @@ static __always_inline struct gen8_insert_pte 
gen8_insert_pte(u64 start)
 }
 
 static __always_inline bool
+gen8_ppgtt_insert_1G_pdpe_entries(struct i915_hw_ppgtt *ppgtt,
+ struct i915_page_directory_pointer *pdp,
+ struct sgt_dma *iter,
+ struct gen8_insert_pte *idx,
+ enum i915_cache_level cache_level)
+{
+   const gen8_pte_t pdpe_encode = gen8_pte_encode(GEN8_PDPE_PS_1G,
+  cache_level);
+   gen8_pte_t *vaddr;
+   bool ret;
+
+   GEM_BUG_ON(idx->pte);
+   GEM_BUG_ON(idx->pde);
+   GEM_BUG_ON(idx->pdpe >= i915_pdpes_per_pdp(&ppgtt->base));
+   vaddr = kmap_atomic_px(pdp);
+   do {
+   vaddr[idx->pdpe] = pdpe_encode | iter->dma;
+   iter->dma += I915_GTT_PAGE_SIZE_1G;
+   if (iter->dma >= iter->max) {
+   iter->sg = __sg_next(iter->sg);
+   if (!iter->sg) {
+   ret = false;
+   break;
+   }
+
+   iter->dma = sg_dma_address(iter->sg);
+   iter->max = iter->dma + iter->sg->length;
+   }
+
+   if (++idx->pdpe == GEN8_PML4ES_PER_PML4) {
+   idx->pdpe = 0;
+   ret = true;
+   break;
+   }
+
+   } while (1);
+   kunmap_atomic(vaddr);
+
+   mark_tlbs_dirty(ppgtt);
+
+   return ret;
+}
+
+static __always_inline bool
 gen8_ppgtt_insert_2M_pde_entries(struct i915_hw_ppgtt *ppgtt,
 struct i915_page_directory_pointer *pdp,
 struct sgt_dma *iter,
@@ -1081,6 +1125,9 @@ static void gen8_ppgtt_insert_4lvl(struct 
i915_address_space *vm,
case I915_GTT_PAGE_SIZE_2M:
insert_entries = gen8_ppgtt_insert_2M_pde_entries;
break;
+   case I915_GTT_PAGE_SIZE_1G:
+   insert_entries = gen8_ppgtt_insert_1G_pdpe_entries;
+   break;
default:
MISSING_CASE(page_size);
return;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 840d08be8fa3..1517cfdbd5ce 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -152,6 +152,8 @@ typedef u64 gen8_ppgtt_pml4e_t;
 #define GEN8_PDE_IPS_64K BIT(11)
 #define GEN8_PDE_PS_2M   BIT(7)
 
+#define GEN8_PDPE_PS_1G  BIT(7)
+
 struct sg_table;
 
 struct intel_rotation_info {
-- 
2.9.4

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

[Intel-gfx] [PATCH 10/17] drm/i915: support inserting 64K pages into the 48b PPGTT

[Matthew Auld]

If we set the IPS bit, aka PDE[11] then every 16th entry should be used
to index, the HW makes no assumptions for any other PTEs.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 74 +
 drivers/gpu/drm/i915/i915_gem_gtt.h |  2 +
 2 files changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 3be3cbfb6d28..874854e77247 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -854,6 +854,77 @@ static __always_inline struct gen8_insert_pte 
gen8_insert_pte(u64 start)
 }
 
 static __always_inline bool
+gen8_ppgtt_insert_64K_pte_entries(struct i915_hw_ppgtt *ppgtt,
+ struct i915_page_directory_pointer *pdp,
+ struct sgt_dma *iter,
+ struct gen8_insert_pte *idx,
+ enum i915_cache_level cache_level)
+{
+   struct i915_page_directory *pd;
+   const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level);
+   gen8_pte_t *vaddr;
+   bool ret;
+
+   /* Currently 64K objects should be aligned to 2M to prevent mixing 4K
+* and 64K pte's in the same page-table.
+*/
+   GEM_BUG_ON(idx->pte);
+   GEM_BUG_ON(idx->pdpe >= i915_pdpes_per_pdp(&ppgtt->base));
+   pd = pdp->page_directory[idx->pdpe];
+
+   vaddr = kmap_atomic_px(pd);
+   vaddr[idx->pde] |= GEN8_PDE_IPS_64K;
+   kunmap_atomic(vaddr);
+
+   vaddr = kmap_atomic_px(pd->page_table[idx->pde]);
+   do {
+   vaddr[idx->pte] = pte_encode | iter->dma;
+   iter->dma += I915_GTT_PAGE_SIZE_64K;
+   if (iter->dma >= iter->max) {
+   iter->sg = __sg_next(iter->sg);
+   if (!iter->sg) {
+   ret = false;
+   break;
+   }
+
+   iter->dma = sg_dma_address(iter->sg);
+   iter->max = iter->dma + iter->sg->length;
+   }
+
+   idx->pte += 16;
+
+   if (idx->pte == GEN8_PTES) {
+   idx->pte = 0;
+
+   if (++idx->pde == I915_PDES) {
+   idx->pde = 0;
+
+   if (++idx->pdpe == GEN8_PML4ES_PER_PML4) {
+   idx->pdpe = 0;
+   ret = true;
+   break;
+   }
+
+   GEM_BUG_ON(idx->pdpe >= 
i915_pdpes_per_pdp(&ppgtt->base));
+   pd = pdp->page_directory[idx->pdpe];
+   }
+
+   kunmap_atomic(vaddr);
+   vaddr = kmap_atomic_px(pd);
+   vaddr[idx->pde] |= GEN8_PDE_IPS_64K;
+   kunmap_atomic(vaddr);
+
+   vaddr = kmap_atomic_px(pd->page_table[idx->pde]);
+   }
+   } while (1);
+   kunmap_atomic(vaddr);
+
+   mark_tlbs_dirty(ppgtt);
+
+   return ret;
+}
+
+static __always_inline bool
 gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt,
  struct i915_page_directory_pointer *pdp,
  struct sgt_dma *iter,
@@ -954,6 +1025,9 @@ static void gen8_ppgtt_insert_4lvl(struct 
i915_address_space *vm,
case I915_GTT_PAGE_SIZE_4K:
insert_entries = gen8_ppgtt_insert_pte_entries;
break;
+   case I915_GTT_PAGE_SIZE_64K:
+   insert_entries = gen8_ppgtt_insert_64K_pte_entries;
+   break;
default:
MISSING_CASE(page_size);
return;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 5a2a3907d266..04d37c62c3ef 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -149,6 +149,8 @@ typedef u64 gen8_ppgtt_pml4e_t;
 #define GEN8_PPAT_ELLC_OVERRIDE(0<<2)
 #define GEN8_PPAT(i, x)((u64)(x) << ((i) * 8))
 
+#define GEN8_PDE_IPS_64K BIT(11)
+
 struct sg_table;
 
 struct intel_rotation_info {
-- 
2.9.4

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

[Intel-gfx] [PATCH 04/17] drm/i915: align 64K objects to 2M

[Matthew Auld]

We can't mix 64K and 4K pte's in the same page-table, so for now we
align 64K objects to 2M to avoid any potential mixing. This is
potentially wasteful but in reality shouldn't be too bad since this only
applies to the virtual address space of a 48b PPGTT.

Suggested-by: Chris Wilson 
Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_vma.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 53f6c94b2ee6..d2e8edd351cf 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -475,6 +475,15 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
obj->gtt_page_size > I915_GTT_PAGE_SIZE) {
unsigned int page_alignment = obj->gtt_page_size;
 
+   /* We can't mix 64K and 4K pte's in the same page-table (2M
+* block), and so to avoid the ugliness and complexity of
+* coloring we opt for just aligning 64K objects to 2M.
+*/
+   if (page_alignment == I915_GTT_PAGE_SIZE_64K) {
+   page_alignment = I915_GTT_PAGE_SIZE_2M;
+   size = roundup(size, page_alignment);
+   }
+
alignment = max_t(typeof(alignment), alignment, page_alignment);
GEM_BUG_ON(!IS_ALIGNED(vma->size, obj->gtt_page_size));
}
-- 
2.9.4

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

[Intel-gfx] [PATCH 12/17] drm/i915: support inserting 2M pages into the 48b PPGTT

[Matthew Auld]

To enable 2M pages we set the PS bit of PDE, aka PDE[7] to indicate a 2M
page and not a page-table.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 53 +
 drivers/gpu/drm/i915/i915_gem_gtt.h |  1 +
 2 files changed, 54 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 874854e77247..3dadb501daa6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -854,6 +854,56 @@ static __always_inline struct gen8_insert_pte 
gen8_insert_pte(u64 start)
 }
 
 static __always_inline bool
+gen8_ppgtt_insert_2M_pde_entries(struct i915_hw_ppgtt *ppgtt,
+struct i915_page_directory_pointer *pdp,
+struct sgt_dma *iter,
+struct gen8_insert_pte *idx,
+enum i915_cache_level cache_level)
+{
+   const gen8_pte_t pde_encode = gen8_pte_encode(GEN8_PDE_PS_2M,
+ cache_level);
+   gen8_pte_t *vaddr;
+   bool ret;
+
+   GEM_BUG_ON(idx->pte);
+   GEM_BUG_ON(idx->pdpe >= i915_pdpes_per_pdp(&ppgtt->base));
+   vaddr = kmap_atomic_px(pdp->page_directory[idx->pdpe]);
+   do {
+   vaddr[idx->pde] = pde_encode | iter->dma;
+   iter->dma += I915_GTT_PAGE_SIZE_2M;
+   if (iter->dma >= iter->max) {
+   iter->sg = __sg_next(iter->sg);
+   if (!iter->sg) {
+   ret = false;
+   break;
+   }
+
+   iter->dma = sg_dma_address(iter->sg);
+   iter->max = iter->dma + iter->sg->length;
+   }
+
+   if (++idx->pde == I915_PDES) {
+   idx->pde = 0;
+
+   if (++idx->pdpe == GEN8_PML4ES_PER_PML4) {
+   idx->pdpe = 0;
+   ret = true;
+   break;
+   }
+
+   kunmap_atomic(vaddr);
+   vaddr = kmap_atomic_px(pdp->page_directory[idx->pdpe]);
+   }
+
+   } while (1);
+   kunmap_atomic(vaddr);
+
+   mark_tlbs_dirty(ppgtt);
+
+   return ret;
+}
+
+static __always_inline bool
 gen8_ppgtt_insert_64K_pte_entries(struct i915_hw_ppgtt *ppgtt,
  struct i915_page_directory_pointer *pdp,
  struct sgt_dma *iter,
@@ -1028,6 +1078,9 @@ static void gen8_ppgtt_insert_4lvl(struct 
i915_address_space *vm,
case I915_GTT_PAGE_SIZE_64K:
insert_entries = gen8_ppgtt_insert_64K_pte_entries;
break;
+   case I915_GTT_PAGE_SIZE_2M:
+   insert_entries = gen8_ppgtt_insert_2M_pde_entries;
+   break;
default:
MISSING_CASE(page_size);
return;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index 04d37c62c3ef..840d08be8fa3 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -150,6 +150,7 @@ typedef u64 gen8_ppgtt_pml4e_t;
 #define GEN8_PPAT(i, x)((u64)(x) << ((i) * 8))
 
 #define GEN8_PDE_IPS_64K BIT(11)
+#define GEN8_PDE_PS_2M   BIT(7)
 
 struct sg_table;
 
-- 
2.9.4

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

[Intel-gfx] [PATCH 09/17] drm/i915: enable IPS bit for 64K pages

[Matthew Auld]

Before we can enable 64K pages through the IPS bit, we must first enable
it through MMIO, otherwise the page-walker will simply ignore it.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 11 +++
 drivers/gpu/drm/i915/i915_reg.h |  3 +++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e4ee54f0f55f..fa133aa61261 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4717,6 +4717,17 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
}
}
 
+   /* To support 64K PTE's we need to first enable the use of the
+* Intermediate-Page-Size(IPS) bit of the PDE field via some magical
+* mmio, otherwise the page-walker will simply ignore the IPS bit. This
+* shouldn't be needed after GEN10.
+*/
+   if (HAS_PAGE_SIZE(dev_priv, I915_GTT_PAGE_SIZE_64K) &&
+   INTEL_GEN(dev_priv) <= 10)
+   I915_WRITE(GEN8_GAMW_ECO_DEV_RW_IA,
+  I915_READ(GEN8_GAMW_ECO_DEV_RW_IA) |
+  GAMW_ECO_ENABLE_64K_IPS_FIELD);
+
i915_gem_init_swizzling(dev_priv);
 
/*
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ee144ec57935..7416e7d7d472 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1993,6 +1993,9 @@ enum skl_disp_power_wells {
 #define GEN9_GAMT_ECO_REG_RW_IA _MMIO(0x4ab0)
 #define   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS  (1<<18)
 
+#define GEN8_GAMW_ECO_DEV_RW_IA _MMIO(0x4080)
+#define   GAMW_ECO_ENABLE_64K_IPS_FIELD 0xF
+
 #define GAMT_CHKN_BIT_REG  _MMIO(0x4ab8)
 #define   GAMT_CHKN_DISABLE_DYNAMIC_CREDIT_SHARING (1<<28)
 
-- 
2.9.4

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

[Intel-gfx] [PATCH 03/17] drm/i915: align the vma start to the gtt page size

[Matthew Auld]

When inserting into a 48bit PPGTT we need to align the vma start address
to the required page size boundary. The size will already be aligned so
no padding is needed.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_vma.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 1aba47024656..53f6c94b2ee6 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -471,6 +471,14 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
if (ret)
return ret;
 
+   if (i915_vm_is_48bit(vma->vm) &&
+   obj->gtt_page_size > I915_GTT_PAGE_SIZE) {
+   unsigned int page_alignment = obj->gtt_page_size;
+
+   alignment = max_t(typeof(alignment), alignment, page_alignment);
+   GEM_BUG_ON(!IS_ALIGNED(vma->size, obj->gtt_page_size));
+   }
+
if (flags & PIN_OFFSET_FIXED) {
u64 offset = flags & PIN_OFFSET_MASK;
if (!IS_ALIGNED(offset, alignment) ||
-- 
2.9.4

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

[Intel-gfx] [PATCH 17/17] drm/i915: enable platform support for 1G pages

[Matthew Auld]

For gen8+ enable platform level support for 1G pages. Also enable for
mock testing.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_pci.c  | 9 ++---
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 3 ++-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 452f061fd7b3..68baefe6566c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -320,7 +320,8 @@ static const struct intel_device_info intel_haswell_info = {
HSW_FEATURES, \
BDW_COLORS, \
.page_size_mask = I915_GTT_PAGE_SIZE_4K | \
- I915_GTT_PAGE_SIZE_2M, \
+ I915_GTT_PAGE_SIZE_2M | \
+ I915_GTT_PAGE_SIZE_1G, \
.has_logical_ring_contexts = 1, \
.has_full_48bit_ppgtt = 1, \
.has_64bit_reloc = 1
@@ -357,7 +358,8 @@ static const struct intel_device_info intel_cherryview_info 
= {
.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_2M |
+ I915_GTT_PAGE_SIZE_1G,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
CHV_COLORS,
@@ -366,7 +368,8 @@ static const struct intel_device_info intel_cherryview_info 
= {
 #define GEN9_DEFAULT_PAGE_SIZES \
.page_size_mask = I915_GTT_PAGE_SIZE_4K | \
  I915_GTT_PAGE_SIZE_64K | \
- I915_GTT_PAGE_SIZE_2M
+ I915_GTT_PAGE_SIZE_2M | \
+ I915_GTT_PAGE_SIZE_1G
 
 static const struct intel_device_info intel_skylake_info = {
BDW_FEATURES,
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 23f0db2dbb5d..2535e211650c 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -146,7 +146,8 @@ struct drm_i915_private *mock_gem_device(void)
mkwrite_device_info(i915)->page_size_mask =
I915_GTT_PAGE_SIZE_4K |
I915_GTT_PAGE_SIZE_64K |
-   I915_GTT_PAGE_SIZE_2M;
+   I915_GTT_PAGE_SIZE_2M |
+   I915_GTT_PAGE_SIZE_1G;
 
spin_lock_init(&i915->mm.object_stat_lock);
mock_uncore_init(i915);
-- 
2.9.4

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

[Intel-gfx] [PATCH 15/17] drm/i915: enable platform support for 64K pages

[Matthew Auld]

For gen9+ enable platform level support for 64K pages. Also enable for
mock testing.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_pci.c  | 6 --
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 3 ++-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 7caccb5bf963..0a6940c3841d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -354,14 +354,16 @@ static const struct intel_device_info 
intel_cherryview_info = {
.has_aliasing_ppgtt = 1,
.has_full_ppgtt = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
-   GEN_DEFAULT_PAGE_SIZES,
+   .page_size_mask = I915_GTT_PAGE_SIZE_4K |
+ I915_GTT_PAGE_SIZE_64K,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
CHV_COLORS,
 };
 
 #define GEN9_DEFAULT_PAGE_SIZES \
-   .page_size_mask = I915_GTT_PAGE_SIZE_4K
+   .page_size_mask = I915_GTT_PAGE_SIZE_4K | \
+ I915_GTT_PAGE_SIZE_64K
 
 static const struct intel_device_info intel_skylake_info = {
BDW_FEATURES,
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index b7e4ba03e3bc..d41ed2178e3e 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -144,7 +144,8 @@ struct drm_i915_private *mock_gem_device(void)
mkwrite_device_info(i915)->gen = -1;
 
mkwrite_device_info(i915)->page_size_mask =
-   I915_GTT_PAGE_SIZE_4K;
+   I915_GTT_PAGE_SIZE_4K |
+   I915_GTT_PAGE_SIZE_64K;
 
spin_lock_init(&i915->mm.object_stat_lock);
mock_uncore_init(i915);
-- 
2.9.4

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

[Intel-gfx] [PATCH 16/17] drm/i915: enable platform support for 2M pages

[Matthew Auld]

For gen8+ enable platform level support for 2M pages. Also enable for
mock testing.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_pci.c  | 9 ++---
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 3 ++-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 0a6940c3841d..452f061fd7b3 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -319,7 +319,8 @@ static const struct intel_device_info intel_haswell_info = {
 #define BDW_FEATURES \
HSW_FEATURES, \
BDW_COLORS, \
-   GEN_DEFAULT_PAGE_SIZES, \
+   .page_size_mask = I915_GTT_PAGE_SIZE_4K | \
+ I915_GTT_PAGE_SIZE_2M, \
.has_logical_ring_contexts = 1, \
.has_full_48bit_ppgtt = 1, \
.has_64bit_reloc = 1
@@ -355,7 +356,8 @@ static const struct intel_device_info intel_cherryview_info 
= {
.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_64K |
+ I915_GTT_PAGE_SIZE_2M,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
CHV_COLORS,
@@ -363,7 +365,8 @@ static const struct intel_device_info intel_cherryview_info 
= {
 
 #define GEN9_DEFAULT_PAGE_SIZES \
.page_size_mask = I915_GTT_PAGE_SIZE_4K | \
- I915_GTT_PAGE_SIZE_64K
+ I915_GTT_PAGE_SIZE_64K | \
+ I915_GTT_PAGE_SIZE_2M
 
 static const struct intel_device_info intel_skylake_info = {
BDW_FEATURES,
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index d41ed2178e3e..23f0db2dbb5d 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -145,7 +145,8 @@ struct drm_i915_private *mock_gem_device(void)
 
mkwrite_device_info(i915)->page_size_mask =
I915_GTT_PAGE_SIZE_4K |
-   I915_GTT_PAGE_SIZE_64K;
+   I915_GTT_PAGE_SIZE_64K |
+   I915_GTT_PAGE_SIZE_2M;
 
spin_lock_init(&i915->mm.object_stat_lock);
mock_uncore_init(i915);
-- 
2.9.4

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

[Intel-gfx] [PATCH 14/17] drm/i915/debugfs: include some gtt_page_size metrics

[Matthew Auld]

Good to know, mostly for debugging purposes.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 37 ++---
 1 file changed, 34 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index bd9abef40c66..dd36baa47667 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -117,6 +117,23 @@ static u64 i915_gem_obj_total_ggtt_size(struct 
drm_i915_gem_object *obj)
return size;
 }
 
+static const char *stringify_page_size(unsigned int page_size)
+{
+   switch (page_size) {
+   case I915_GTT_PAGE_SIZE_4K:
+   return "4K";
+   case I915_GTT_PAGE_SIZE_64K:
+   return "64K";
+   case I915_GTT_PAGE_SIZE_2M:
+   return "2M";
+   case I915_GTT_PAGE_SIZE_1G:
+   return "1G";
+   default:
+   MISSING_CASE(page_size);
+   return "";
+   }
+}
+
 static void
 describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj)
 {
@@ -128,7 +145,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
 
lockdep_assert_held(&obj->base.dev->struct_mutex);
 
-   seq_printf(m, "%pK: %c%c%c%c%c %8zdKiB %02x %02x %s%s%s",
+   seq_printf(m, "%pK: %c%c%c%c%c %8zdKiB %s %02x %02x %s%s%s",
   &obj->base,
   get_active_flag(obj),
   get_pin_flag(obj),
@@ -136,6 +153,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object 
*obj)
   get_global_flag(obj),
   get_pin_mapped_flag(obj),
   obj->base.size / 1024,
+  stringify_page_size(obj->gtt_page_size),
   obj->base.read_domains,
   obj->base.write_domain,
   i915_cache_level_str(dev_priv, obj->cache_level),
@@ -399,8 +417,8 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
struct drm_i915_private *dev_priv = node_to_i915(m->private);
struct drm_device *dev = &dev_priv->drm;
struct i915_ggtt *ggtt = &dev_priv->ggtt;
-   u32 count, mapped_count, purgeable_count, dpy_count;
-   u64 size, mapped_size, purgeable_size, dpy_size;
+   u32 count, mapped_count, purgeable_count, dpy_count, huge_count;
+   u64 size, mapped_size, purgeable_size, dpy_size, huge_size;
struct drm_i915_gem_object *obj;
struct drm_file *file;
int ret;
@@ -416,6 +434,7 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
size = count = 0;
mapped_size = mapped_count = 0;
purgeable_size = purgeable_count = 0;
+   huge_size = huge_count = 0;
list_for_each_entry(obj, &dev_priv->mm.unbound_list, global_link) {
size += obj->base.size;
++count;
@@ -429,6 +448,11 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
mapped_count++;
mapped_size += obj->base.size;
}
+
+   if (obj->gtt_page_size > I915_GTT_PAGE_SIZE) {
+   huge_count++;
+   huge_size += obj->base.size;
+   }
}
seq_printf(m, "%u unbound objects, %llu bytes\n", count, size);
 
@@ -451,6 +475,11 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
mapped_count++;
mapped_size += obj->base.size;
}
+
+   if (obj->gtt_page_size > I915_GTT_PAGE_SIZE) {
+   huge_count++;
+   huge_size += obj->base.size;
+   }
}
seq_printf(m, "%u bound objects, %llu bytes\n",
   count, size);
@@ -458,6 +487,8 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
   purgeable_count, purgeable_size);
seq_printf(m, "%u mapped objects, %llu bytes\n",
   mapped_count, mapped_size);
+   seq_printf(m, "%u huge-paged objects, %llu bytes\n",
+  huge_count, huge_size);
seq_printf(m, "%u display objects (pinned), %llu bytes\n",
   dpy_count, dpy_size);
 
-- 
2.9.4

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

Re: [Intel-gfx] [PATCH 05/17] drm/i915: fallback to normal pages on vma insert failure

[Chris Wilson]

On Tue, May 16, 2017 at 09:29:36AM +0100, Matthew Auld wrote:
> Part of the cost in choosing huge-gtt-pages is potentially using a
> larger alignment and/or size. Therefore if our vma insert fails either
> because of the insert/reserve or the pin-offset-fixed we should fallback
> to normal pages and retry before giving up.

Too late. By the point you do this, we will already have been evicting
from the GTT. We need a larger shakeup to take this trial-and-error
approach into consideration, though perhaps with just including NOEVICT,
it may make more sense.
-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 03/17] drm/i915: align the vma start to the gtt page size

[Chris Wilson]

On Tue, May 16, 2017 at 09:29:34AM +0100, Matthew Auld wrote:
> When inserting into a 48bit PPGTT we need to align the vma start address
> to the required page size boundary. The size will already be aligned so
> no padding is needed.
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_vma.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 1aba47024656..53f6c94b2ee6 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -471,6 +471,14 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
> alignment, u64 flags)
>   if (ret)
>   return ret;
>  
> + if (i915_vm_is_48bit(vma->vm) &&
> + obj->gtt_page_size > I915_GTT_PAGE_SIZE) {
> + unsigned int page_alignment = obj->gtt_page_size;
> +
> + alignment = max_t(typeof(alignment), alignment, page_alignment);
> + GEM_BUG_ON(!IS_ALIGNED(vma->size, obj->gtt_page_size));
> + }
> +
>   if (flags & PIN_OFFSET_FIXED) {

We should only increase the minimum alignment for !FIXED. Otherwise the
softpin user will not know what games we are playing and be able to
compensate.
-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/17] drm/i915: introduce gtt page size

[Chris Wilson]

On Tue, May 16, 2017 at 09:29:33AM +0100, Matthew Auld wrote:
> In preparation for supporting huge gtt pages for the ppgtt, we introduce
> a gtt_page_size member for gem objects.  We fill in the gtt page size by
> scanning the sg table to determine the max page size which satisfies the
> alignment for each sg entry.
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  2 ++
>  drivers/gpu/drm/i915/i915_gem.c| 23 +++
>  drivers/gpu/drm/i915/i915_gem_object.h |  2 ++
>  3 files changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e18f11f77f35..a7a108d18a2d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2843,6 +2843,8 @@ intel_info(const struct drm_i915_private *dev_priv)
>  #define USES_PPGTT(dev_priv) (i915.enable_ppgtt)
>  #define USES_FULL_PPGTT(dev_priv)(i915.enable_ppgtt >= 2)
>  #define USES_FULL_48BIT_PPGTT(dev_priv)  (i915.enable_ppgtt == 3)
> +#define HAS_PAGE_SIZE(dev_priv, page_size) \
> + ((dev_priv)->info.page_size_mask & (page_size))
>  
>  #define HAS_OVERLAY(dev_priv) ((dev_priv)->info.has_overlay)
>  #define OVERLAY_NEEDS_PHYSICAL(dev_priv) \
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 0c1cbe98c994..6a5e864d7710 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2294,6 +2294,8 @@ void __i915_gem_object_put_pages(struct 
> drm_i915_gem_object *obj,
>   if (!IS_ERR(pages))
>   obj->ops->put_pages(obj, pages);
>  
> + obj->gtt_page_size = 0;
> +
>  unlock:
>   mutex_unlock(&obj->mm.lock);
>  }
> @@ -2473,6 +2475,13 @@ i915_gem_object_get_pages_gtt(struct 
> drm_i915_gem_object *obj)
>  void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
>struct sg_table *pages)
>  {
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + unsigned long supported_page_sizes = INTEL_INFO(i915)->page_size_mask;
> + struct scatterlist *sg;
> + unsigned int sg_mask = 0;
> + unsigned int i;
> + unsigned int bit;
> +
>   lockdep_assert_held(&obj->mm.lock);
>  
>   obj->mm.get_page.sg_pos = pages->sgl;
> @@ -2486,6 +2495,20 @@ void __i915_gem_object_set_pages(struct 
> drm_i915_gem_object *obj,
>   __i915_gem_object_pin_pages(obj);
>   obj->mm.quirked = true;
>   }
> +
> + for_each_sg(pages->sgl, sg, pages->nents, i)
> + sg_mask |= sg->length;
> +
> + GEM_BUG_ON(!sg_mask);
> +
> + for_each_set_bit(bit, &supported_page_sizes, BITS_PER_LONG) {
> + if (!IS_ALIGNED(sg_mask, 1 << bit))
> + break;
> +
> + obj->gtt_page_size = 1 << bit;
> + }

Not here. This is the synchronous part, and we really do not want to
loop again. However, we have just looped over and can compute this mask
inline in the asynchronous portion of get_pages.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for add support for huge-gtt-pages

[Patchwork]

== Series Details ==

Series: add support for huge-gtt-pages
URL   : https://patchwork.freedesktop.org/series/24481/
State : success

== Summary ==

Series 24481v1 add support for huge-gtt-pages
https://patchwork.freedesktop.org/api/1.0/series/24481/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:442s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:432s
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:504s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:509s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:422s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:418s
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:505s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:468s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:469s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:577s
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:588s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:470s
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:433s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:555s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:409s

9b25870f9fa4548ec2bb40e42fa28f35db2189e1 drm-tip: 2017y-05m-15d-15h-47m-31s UTC 
integration manifest
cf035b2 drm/i915: enable platform support for 1G pages
ead918b drm/i915: enable platform support for 2M pages
ee0e57d drm/i915: enable platform support for 64K pages
d0bfa76 drm/i915/debugfs: include some gtt_page_size metrics
c6fb01e drm/i915: support inserting 1G pages into the 48b PPGTT
2dc2ed8 drm/i915: support inserting 2M pages into the 48b PPGTT
f06788c drm/i915: disable GTT cache for 2M/1G pages
86ce13d drm/i915: support inserting 64K pages into the 48b PPGTT
fcc9241 drm/i915: enable IPS bit for 64K pages
34b66cf drm/i915: pass gtt page size to insert_entries
61d5eb7 drm/i915: request THP for shmem backed objects
34a823b mm/shmem: expose driver overridable huge option
9b38f26 drm/i915: fallback to normal pages on vma insert failure
1fa7ce3 drm/i915: align 64K objects to 2M
d357c27 drm/i915: align the vma start to the gtt page size
0ecfdaa drm/i915: introduce gtt page size
176907c drm/i915: introduce page_size_mask to dev_info

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: use vma->size for appgtt allocate_va_range

[Matthew Auld]

For the aliasing ppgtt we clear the va range up to vma->size, but seem
to allocate up to vma->node.size, which is a little inconsistent given
that vma->node.size >= vma->size. Not that is really matters all that
much since we preallocate anyway, but for consistency just use
vma->size.

Fixes: ff685975d97f ("drm/i915: Move allocate_va_range to GTT")
Signed-off-by: Matthew Auld 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index bc3c63e92c16..a9d78ebcabfe 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2313,7 +2313,7 @@ static int aliasing_gtt_bind_vma(struct i915_vma *vma,
appgtt->base.allocate_va_range) {
ret = appgtt->base.allocate_va_range(&appgtt->base,
 vma->node.start,
-vma->node.size);
+vma->size);
if (ret)
goto err_pages;
}
-- 
2.9.4

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

Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to capture the state of the GPU

[Lofstedt, Marta]

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, May 16, 2017 11:21 AM
> To: Lofstedt, Marta 
> Cc: Daniel Vetter ; Martin Peres
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to 
> capture
> the state of the GPU
> 
> On Tue, May 16, 2017 at 07:42:51AM +, Lofstedt, Marta wrote:
> > I hereby pull-out this patch.
> > The idea of it was to know if we were already wedged at the beginning of
> testing, that would give us information on how to interpret silly results; 
> such
> that test starting to get skipped and/or we got dmesg-warns/incomplete on
> tests that usually should be skipped.
> > Also, we are planning to soon deploy a piglit.conf solution where testing
> will be terminated on wedged, so I agree that my test isn't really needed.
> 
> Not everything is broken by wedged; internally we just use that as an
> indicator that GEM is hosed. KMS should still work, we must still be able to
> drive the displays to show the error and keep the servers alive until the data
> is saved (and hopefully gracefully degrade that we don't have to interrupt
> their immediate session).

It doesn't matter if it is broken or not, if we are terminally wedged the rest 
of the result may be silly. Look for example at CI_DRM_2612, the fi-elk-e7500 
is wedged at igt@gem_busy@basic-hang-default, then all test are skipped until 
gem_exec_reloc@basic-cpu-gtt-noreloc where the machine hangs, but it is a gem 
test so it should have been skipped, right. My conclusion from seeing this 
pattern multiple times is that after terminally wedged, silly things can 
happen, i.e. we can't trust the results, and since we don't want silly bugs, 
the CI testing should be stopped.

> 
> Whilst that may be out of scope for BAT, it should not be completely beyond
> us for robustness testing.
> -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] drm/i915: Import the kfence selftests for i915_sw_fence

[Chris Wilson]

On Mon, May 15, 2017 at 11:52:55AM +0100, Chris Wilson wrote:
> A long time ago, I wrote some selftests for the struct kfence idea. Now
> that we have infrastructure in i915/igt for running kselftests, include
> some for i915_sw_fence.
> 
> Signed-off-by: Chris Wilson 

Anyone want to stamp these?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to capture the state of the GPU

[Chris Wilson]

On Tue, May 16, 2017 at 08:54:51AM +, Lofstedt, Marta wrote:
> 
> 
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Tuesday, May 16, 2017 11:21 AM
> > To: Lofstedt, Marta 
> > Cc: Daniel Vetter ; Martin Peres
> > ; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to 
> > capture
> > the state of the GPU
> > 
> > On Tue, May 16, 2017 at 07:42:51AM +, Lofstedt, Marta wrote:
> > > I hereby pull-out this patch.
> > > The idea of it was to know if we were already wedged at the beginning of
> > testing, that would give us information on how to interpret silly results; 
> > such
> > that test starting to get skipped and/or we got dmesg-warns/incomplete on
> > tests that usually should be skipped.
> > > Also, we are planning to soon deploy a piglit.conf solution where testing
> > will be terminated on wedged, so I agree that my test isn't really needed.
> > 
> > Not everything is broken by wedged; internally we just use that as an
> > indicator that GEM is hosed. KMS should still work, we must still be able to
> > drive the displays to show the error and keep the servers alive until the 
> > data
> > is saved (and hopefully gracefully degrade that we don't have to interrupt
> > their immediate session).
> 
> It doesn't matter if it is broken or not, if we are terminally wedged the 
> rest of the result may be silly. Look for example at CI_DRM_2612, the 
> fi-elk-e7500 is wedged at igt@gem_busy@basic-hang-default, then all test are 
> skipped until gem_exec_reloc@basic-cpu-gtt-noreloc where the machine hangs, 
> but it is a gem test so it should have been skipped, right. My conclusion 
> from seeing this pattern multiple times is that after terminally wedged, 
> silly things can happen, i.e. we can't trust the results, and since we don't 
> want silly bugs, the CI testing should be stopped.

The machine didn't hang, it was remotely killed because the run timed out.
-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] [PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

Three tags in total. I also just realized that in the last one I've
forgotten to mention the LPE audio fixes from Ville, which also touch
sound/. Those patches are all reviewed by Takashi.

drm-intel-next-2017-05-15:
Another pile of stuff for 4.12:

- OA improvements and fixes from Robert Bragg
- fixes for the dp aux backlight driver (Puthikorn Voravootivat)
- no RCU during shrinking (unfortunately), from Joonas
- small atomic leftovers (better unpin, statified hw verifier), from
  Maarten
- g4x wm fixes (Ville)
- piles of cursor fixes/improvements (Ville)
- g4x overlay plane support (Ville)
- prep for new guc logging/notification (Michal Wajdeczko)
- pile of static checker appeasement from Imre
- implement dma_buf->kmap, good for testing (Chris)
- fine-tune ring handling (Chris)
drm-intel-next-2017-05-02:
Somehow not much these 2 weeks ...

- (hopefully) stability fixes for byt/bsw gt wake (Chris)
- tighten up requests (especially restarts) checks and debug tracking
  (Chris)
- unify context handling more for gen5+ (Chris+Joonas)
- oddball bugfixes as usual
drm-intel-next-2017-04-18:
First slice of 4.13 features:

new uabi:
- extend error state dumping to include non-batch buffers requested by
  userspace (Chris), so that mesa gets more useful error state dumps
- reapply the link status patch, for handlig dp link failures
  (Manasi). This needs updated -modesetting to work correctly.
- Add new _WC cache domain, our assumption that wc can be subsumed by
  the existing cache domains didn't pan out (Chris)

feature work:
- first pile of conversion to atomic properties for connectors
  (Maarten)
- refactor dp link rate handling code and related areas (Jani)
- split engine info into class and runtime stuff (Oscar Mateo)
- more robust wait_for_register code (Chris, Michal Wajdeczko)
- fix rcu issues in the shrinker and simplify locking (Joonas)
- guc/huc for glk (Anusha)
- enable atomic modesetting for vlv/chv (Ville), plus final fixes for
  that

I chatted with Sean, and the plan is that he'll send you the drm-misc-next
pull for opening 4.13 drm-next later today. We need to backmerge the
entire thing into drm-intel afterwards, Maarten needs the connector state
hooks for landing the remaining connector atomicification patches for
i915.

Cheers, Daniel


The following changes since commit 8b03d1ed2c43a2ba5ef3381322ee4515b97381bf:

  Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-next 
(2017-05-02 04:46:01 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-next-2017-05-15

for you to fetch changes up to 2388cd9c5056b10c8e461ca2ab075f49d6f1b25d:

  drm/i915: Update DRIVER_DATE to 20170515 (2017-05-15 09:11:48 +0200)


Another pile of stuff for 4.12:

- OA improvements and fixes from Robert Bragg
- fixes for the dp aux backlight driver (Puthikorn Voravootivat)
- no RCU during shrinking (unfortunately), from Joonas
- small atomic leftovers (better unpin, statified hw verifier), from
  Maarten
- g4x wm fixes (Ville)
- piles of cursor fixes/improvements (Ville)
- g4x overlay plane support (Ville)
- prep for new guc logging/notification (Michal Wajdeczko)
- pile of static checker appeasement from Imre
- implement dma_buf->kmap, good for testing (Chris)
- fine-tune ring handling (Chris)


Ander Conselvan de Oliveira (2):
  drm/i915/glk: Don't allow 12 bpc when htotal is too big
  drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

Andrea Arcangeli (1):
  i915: initialize the free_list of the fencing atomic_helper

Anusha Srivatsa (2):
  drm/i915/GuC/GLK: Load GuC on GLK
  drm/i915/GLK/HuC: Load HuC on GLK

Chris Wilson (51):
  drm/i915: intel_ring.engine is unused
  drm/i915: Onion unwind for intel_init_ring_common()
  drm/i915: Park the signaler before sleeping
  drm/i915: Apply a cond_resched() to the saturated signaler
  drm/i915: Use the right mapping_gfp_mask for final shmem allocation
  drm/i915: Assert the engine is idle before overwiting the HWS
  drm/i915: Advance ring->head fully when idle
  drm/i915: The shrinker already acquires struct_mutex, so call it unlocked
  drm/i915: Drain any freed objects prior to hibernation
  drm/i915: Break up long runs of freeing objects
  drm/i915: Insert cond_resched() into i915_gem_free_objects
  drm/i915: Use drm_i915_private directly from debugfs
  drm/i915: Stop second guessing the caller for 
intel_uncore_wait_for_register()
  drm/i915: Stop sleeping from inside gen6_bsd_submit_request()
  drm/i915: Acquire uncore.lock over intel_uncore_wait_for_register()
  drm/i915: Use __intel_uncore_wait_for_register_fw for 
sandybride_pcode_read
  drm/i915: Use safer intel_uncore_wait_for_register in ring-init
  drm/i915: Rename intel_engine_cs.exec_id to uabi_id

Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to capture the state of the GPU

[Chris Wilson]

On Tue, May 16, 2017 at 08:54:51AM +, Lofstedt, Marta wrote:
> 
> 
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Tuesday, May 16, 2017 11:21 AM
> > To: Lofstedt, Marta 
> > Cc: Daniel Vetter ; Martin Peres
> > ; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to 
> > capture
> > the state of the GPU
> > 
> > On Tue, May 16, 2017 at 07:42:51AM +, Lofstedt, Marta wrote:
> > > I hereby pull-out this patch.
> > > The idea of it was to know if we were already wedged at the beginning of
> > testing, that would give us information on how to interpret silly results; 
> > such
> > that test starting to get skipped and/or we got dmesg-warns/incomplete on
> > tests that usually should be skipped.
> > > Also, we are planning to soon deploy a piglit.conf solution where testing
> > will be terminated on wedged, so I agree that my test isn't really needed.
> > 
> > Not everything is broken by wedged; internally we just use that as an
> > indicator that GEM is hosed. KMS should still work, we must still be able to
> > drive the displays to show the error and keep the servers alive until the 
> > data
> > is saved (and hopefully gracefully degrade that we don't have to interrupt
> > their immediate session).
> 
> It doesn't matter if it is broken or not, if we are terminally wedged the 
> rest of the result may be silly. Look for example at CI_DRM_2612, the 
> fi-elk-e7500 is wedged at igt@gem_busy@basic-hang-default, then all test are 
> skipped until gem_exec_reloc@basic-cpu-gtt-noreloc where the machine hangs, 
> but it is a gem test so it should have been skipped, right. My conclusion 
> from seeing this pattern multiple times is that after terminally wedged, 
> silly things can happen, i.e. we can't trust the results, and since we don't 
> want silly bugs, the CI testing should be stopped.

Oh, and note it was running so slowly because of a KMS bug that is quite
common.
-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: use vma->size for appgtt allocate_va_range

[Chris Wilson]

On Tue, May 16, 2017 at 09:55:14AM +0100, Matthew Auld wrote:
> For the aliasing ppgtt we clear the va range up to vma->size, but seem
> to allocate up to vma->node.size, which is a little inconsistent given
> that vma->node.size >= vma->size. Not that is really matters all that
> much since we preallocate anyway, but for consistency just use
> vma->size.

We clear vma->size, so we have better allocate vma->size as well.
 
> Fixes: ff685975d97f ("drm/i915: Move allocate_va_range to GTT")
> Signed-off-by: Matthew Auld 
> Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/guc:fix spelling mistake: "adddress" -> "address"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in seq_printf message.

Fixes: a8b9370fc79c1 ("drm/i915/guc: Dump the GuC stage descriptor pool in 
debugfs")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index bd9abef40c66..76abff186d01 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2582,7 +2582,7 @@ static int i915_guc_stage_pool(struct seq_file *m, void 
*data)
   desc->db_trigger_uk);
seq_printf(m, "\tProcess descriptor: 0x%x\n",
   desc->process_desc);
-   seq_printf(m, "\tWorkqueue adddress: 0x%x, size: 0x%x\n",
+   seq_printf(m, "\tWorkqueue address: 0x%x, size: 0x%x\n",
   desc->wq_addr, desc->wq_size);
seq_putc(m, '\n');
 
-- 
2.11.0

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

[Intel-gfx] [PATCH] Revert "Revert "sched/clock: Fix broken stable to unstable transfer""

[Daniel Vetter]

This reverts commit 471199349134ed612e15deec17c95fafe6b07231.

For CI testing only, before I drop the patch from our CI hacks pile.
-Daniel
---
 kernel/sched/clock.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
index 24a3e01bf8cb..00a45c45beca 100644
--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -221,7 +221,7 @@ static inline u64 wrap_max(u64 x, u64 y)
  */
 static u64 sched_clock_local(struct sched_clock_data *scd)
 {
-   u64 now, clock, old_clock, min_clock, max_clock;
+   u64 now, clock, old_clock, min_clock, max_clock, gtod;
s64 delta;
 
 again:
@@ -238,9 +238,10 @@ static u64 sched_clock_local(struct sched_clock_data *scd)
 *scd->tick_gtod + TICK_NSEC);
 */
 
-   clock = scd->tick_gtod + __gtod_offset + delta;
-   min_clock = wrap_max(scd->tick_gtod, old_clock);
-   max_clock = wrap_max(old_clock, scd->tick_gtod + TICK_NSEC);
+   gtod = scd->tick_gtod + __gtod_offset;
+   clock = gtod + delta;
+   min_clock = wrap_max(gtod, old_clock);
+   max_clock = wrap_max(old_clock, gtod + TICK_NSEC);
 
clock = wrap_max(clock, min_clock);
clock = wrap_min(clock, max_clock);
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH] drm/i915/guc:fix spelling mistake: "adddress" -> "address"

[Daniel Vetter]

On Tue, May 16, 2017 at 10:22:35AM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in seq_printf message.
> 
> Fixes: a8b9370fc79c1 ("drm/i915/guc: Dump the GuC stage descriptor pool in 
> debugfs")
> Signed-off-by: Colin Ian King 

Applied, thanks.
-Daniel
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index bd9abef40c66..76abff186d01 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2582,7 +2582,7 @@ static int i915_guc_stage_pool(struct seq_file *m, void 
> *data)
>  desc->db_trigger_uk);
>   seq_printf(m, "\tProcess descriptor: 0x%x\n",
>  desc->process_desc);
> - seq_printf(m, "\tWorkqueue adddress: 0x%x, size: 0x%x\n",
> + seq_printf(m, "\tWorkqueue address: 0x%x, size: 0x%x\n",
>  desc->wq_addr, desc->wq_size);
>   seq_putc(m, '\n');
>  
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [PATCH 2/2] gpu: drm: i915: compress logic into one line

[Daniel Vetter]

On Mon, May 15, 2017 at 05:00:28PM -0500, Gustavo A. R. Silva wrote:
> Simplify logic to avoid unnecessary variable declaration and assignment.
> 
> Signed-off-by: Gustavo A. R. Silva 

Both applied, thanks.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_display.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b13b53b..ca6479a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9565,7 +9565,6 @@ static int ironlake_crtc_compute_clock(struct 
> intel_crtc *crtc,
>  {
>   struct drm_device *dev = crtc->base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_shared_dpll *pll;
>   const struct intel_limit *limit;
>   int refclk = 12;
>  
> @@ -9609,8 +9608,7 @@ static int ironlake_crtc_compute_clock(struct 
> intel_crtc *crtc,
>  
>   ironlake_compute_dpll(crtc, crtc_state, NULL);
>  
> - pll = intel_get_shared_dpll(crtc, crtc_state, NULL);
> - if (pll == NULL) {
> + if (!intel_get_shared_dpll(crtc, crtc_state, NULL)) {
>   DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
>pipe_name(crtc->pipe));
>   return -EINVAL;
> -- 
> 2.5.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
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 10/12] drm/i915/skl+: use linetime latency if ddb size is not available

[Mahesh Kumar]

Hi,


On Tuesday 16 May 2017 04:08 AM, Matt Roper wrote:

On Mon, May 15, 2017 at 02:04:35PM +0530, Mahesh Kumar wrote:

From: "Kumar, Mahesh" 

This patch make changes to use linetime latency if allocated
DDB size during plane watermark calculation is not available,
This is required to implement new DDB allocation algorithm.

In New Algorithm DDB is allocated based on WM values, because of which
number of DDB blocks will not be available during WM calculation,
So this "linetime latency" is suggested by SV/HW team to be used during
switch-case for WM blocks selection.

(Just realized I never actually sent my review of this patch on the
previous series review; sorry for the delay.)

I'm not sure if the term "linetime" is completely self-explanatory.  You
might want to explicitly clarify that it's the time it takes to fill a
single row at a given clock rate.  So "linetime latency" here is defined
as "line time in microseconds = pipe horizontal total number of pixels /
pixel rate in MHz."

Will update commit message.



Changes since v1:
  - Rebase on top of Paulo's patch series
Changes since v2:
  - Fix if-else condition (pointed by Maarten)
Changes since v3:
  - Use common function for timetime_us calculation (Paulo)
  - rebase on drm-tip
Changes since v4:
  - Use consistent name for fixed_point operation

Signed-off-by: "Mahesh Kumar" 
---
  drivers/gpu/drm/i915/i915_drv.h |  7 +++
  drivers/gpu/drm/i915/intel_pm.c | 42 -
  2 files changed, 40 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a1858c3eb33a..84052990e695 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -115,6 +115,13 @@ typedef struct {
fp; \
  })
  
+static inline bool is_fixed16_zero(uint_fixed_16_16_t val)

+{
+   if (val.val == 0)
+   return true;
+   return false;
+}
+
  static inline uint_fixed_16_16_t u32_to_fixed_16_16(uint32_t val)
  {
uint_fixed_16_16_t fp;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0f1d9f672e83..d73369c2c2d9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4197,6 +4197,27 @@ static uint_fixed_16_16_t skl_wm_method2(uint32_t 
pixel_rate,
return ret;
  }
  
+static uint_fixed_16_16_t

+skl_get_linetime_us(struct intel_crtc_state *cstate)

We use the same definition of linetime for all platforms that use the
concept of 'linetime' (hsw+).  So maybe the skl_ prefix here isn't
really appropriate?

will make it intel_get_linetime_us.

For consistency, should we also call this new function when calculating
the HSW/BDW watermarks in hsw_compute_linetime_wm()?  Or consolidate
skl_compute_linetime_wm() with hsw_compute_linetime_wm()?  Potentially
something we could do as a follow-up patch if we don't want to deal with
it while getting this series in.
sounds good :), will create a new patch to use intel_get_linetime_us in 
hsw_compute_linetime_wm.
hsw & skl require bunch of other calculations/WA in linetime_wm, so will 
keep them separate function only.



+{
+   uint32_t pixel_rate;
+   uint32_t crtc_htotal;
+   uint_fixed_16_16_t linetime_us;
+
+   if (!cstate->base.active)
+   return u32_to_fixed_16_16(0);
+
+   pixel_rate = cstate->pixel_rate;
+
+   if (WARN_ON(pixel_rate == 0))
+   return u32_to_fixed_16_16(0);
+
+   crtc_htotal = cstate->base.adjusted_mode.crtc_htotal;
+   linetime_us = fixed_16_16_div_u64(crtc_htotal * 1000, pixel_rate);
+
+   return linetime_us;
+}
+
  static uint32_t
  skl_adjusted_plane_pixel_rate(const struct intel_crtc_state *cstate,
  const struct intel_plane_state *pstate)
@@ -4331,12 +4352,18 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
if (y_tiled) {
selected_result = max_fixed_16_16(method2, y_tile_minimum);
} else {
+   uint32_t linetime_us;
+
+   linetime_us = fixed_16_16_to_u32_round_up(
+   skl_get_linetime_us(cstate));
if ((cpp * cstate->base.adjusted_mode.crtc_htotal / 512 < 1) &&
(plane_bytes_per_line / 512 < 1))
selected_result = method2;
-   else if ((ddb_allocation /
+   else if ((ddb_allocation && ddb_allocation /
fixed_16_16_to_u32_round_up(plane_blocks_per_line)) >= 
1)
selected_result = min_fixed_16_16(method1, method2);
+   else if (latency >= linetime_us)
+   selected_result = method2;

Based on the commit message, I'm a little bit confused.  The plan is to
switch to the new algorithm where we calculate watermarks first and then
partition DDB second.  So at the end, ddb_allocation should never be
available here, right?  In that case, can we just rem

Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to capture the state of the GPU

[Lofstedt, Marta]

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, May 16, 2017 12:04 PM
> To: Lofstedt, Marta 
> Cc: Daniel Vetter ; Martin Peres
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to 
> capture
> the state of the GPU
> 
> On Tue, May 16, 2017 at 08:54:51AM +, Lofstedt, Marta wrote:
> >
> >
> > > -Original Message-
> > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > Sent: Tuesday, May 16, 2017 11:21 AM
> > > To: Lofstedt, Marta 
> > > Cc: Daniel Vetter ; Martin Peres
> > > ; intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a
> > > test to capture the state of the GPU
> > >
> > > On Tue, May 16, 2017 at 07:42:51AM +, Lofstedt, Marta wrote:
> > > > I hereby pull-out this patch.
> > > > The idea of it was to know if we were already wedged at the
> > > > beginning of
> > > testing, that would give us information on how to interpret silly
> > > results; such that test starting to get skipped and/or we got
> > > dmesg-warns/incomplete on tests that usually should be skipped.
> > > > Also, we are planning to soon deploy a piglit.conf solution where
> > > > testing
> > > will be terminated on wedged, so I agree that my test isn't really needed.
> > >
> > > Not everything is broken by wedged; internally we just use that as
> > > an indicator that GEM is hosed. KMS should still work, we must still
> > > be able to drive the displays to show the error and keep the servers
> > > alive until the data is saved (and hopefully gracefully degrade that
> > > we don't have to interrupt their immediate session).
> >
> > It doesn't matter if it is broken or not, if we are terminally wedged the 
> > rest
> of the result may be silly. Look for example at CI_DRM_2612, the fi-elk-e7500
> is wedged at igt@gem_busy@basic-hang-default, then all test are skipped
> until gem_exec_reloc@basic-cpu-gtt-noreloc where the machine hangs, but
> it is a gem test so it should have been skipped, right. My conclusion from
> seeing this pattern multiple times is that after terminally wedged, silly 
> things
> can happen, i.e. we can't trust the results, and since we don't want silly 
> bugs,
> the CI testing should be stopped.
> 
> The machine didn't hang, it was remotely killed because the run timed out.
How do you know that?
> -Chris
> 
> --
> Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to capture the state of the GPU

[Chris Wilson]

On Tue, May 16, 2017 at 09:43:52AM +, Lofstedt, Marta wrote:
> 
> 
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Tuesday, May 16, 2017 12:04 PM
> > To: Lofstedt, Marta 
> > Cc: Daniel Vetter ; Martin Peres
> > ; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to 
> > capture
> > the state of the GPU
> > 
> > On Tue, May 16, 2017 at 08:54:51AM +, Lofstedt, Marta wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > > Sent: Tuesday, May 16, 2017 11:21 AM
> > > > To: Lofstedt, Marta 
> > > > Cc: Daniel Vetter ; Martin Peres
> > > > ; intel-gfx@lists.freedesktop.org
> > > > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a
> > > > test to capture the state of the GPU
> > > >
> > > > On Tue, May 16, 2017 at 07:42:51AM +, Lofstedt, Marta wrote:
> > > > > I hereby pull-out this patch.
> > > > > The idea of it was to know if we were already wedged at the
> > > > > beginning of
> > > > testing, that would give us information on how to interpret silly
> > > > results; such that test starting to get skipped and/or we got
> > > > dmesg-warns/incomplete on tests that usually should be skipped.
> > > > > Also, we are planning to soon deploy a piglit.conf solution where
> > > > > testing
> > > > will be terminated on wedged, so I agree that my test isn't really 
> > > > needed.
> > > >
> > > > Not everything is broken by wedged; internally we just use that as
> > > > an indicator that GEM is hosed. KMS should still work, we must still
> > > > be able to drive the displays to show the error and keep the servers
> > > > alive until the data is saved (and hopefully gracefully degrade that
> > > > we don't have to interrupt their immediate session).
> > >
> > > It doesn't matter if it is broken or not, if we are terminally wedged the 
> > > rest
> > of the result may be silly. Look for example at CI_DRM_2612, the 
> > fi-elk-e7500
> > is wedged at igt@gem_busy@basic-hang-default, then all test are skipped
> > until gem_exec_reloc@basic-cpu-gtt-noreloc where the machine hangs, but
> > it is a gem test so it should have been skipped, right. My conclusion from
> > seeing this pattern multiple times is that after terminally wedged, silly 
> > things
> > can happen, i.e. we can't trust the results, and since we don't want silly 
> > bugs,
> > the CI testing should be stopped.
> > 
> > The machine didn't hang, it was remotely killed because the run timed out.
> How do you know that?

The dmesg is a stream of flip timeouts until we run out of total BAT
runtime (12 minutes + some startup slack).
-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: Disable decoupled mmio for GEN9LP

[Chris Wilson]

On Mon, May 15, 2017 at 04:18:27PM -0700, kai.c...@intel.com wrote:
> From: Kai Chen 
> 
> The decoupled mmio feature doesn't work as intended by HW team. Enabling
> it with forcewake will only make debugging efforts more difficult, so
> let's just simply remove it.

Is the code going to be reused in the near future, i.e. why not remove
the dead code as well?
-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] New "RPM wakelock ref not held during HW access" in 4.12-rc1 ?

[Ville Syrjälä]

mn Tue, May 16, 2017 at 10:47:48AM +0300, Jani Nikula wrote:
> On Mon, 15 May 2017, Hans de Goede  wrote:
> > Hi,
> >
> > I'm seeing this on suspend/resume on a GPD-win,
> > cherrytrail z8700 device:
> 
> Ville, does
> 
> commit 668e3b014afb66ab29e134bca7c258527273ac75
> Author: Ville Syrjälä 
> Date:   Thu Apr 27 19:02:20 2017 +0300
> 
> drm/i915: Fix runtime PM for LPE audio
> 
> in drm-intel-fixes address this?

ebf5f921478b ("drm/i915: Stop pretending to mask/unmask LPE audio
interrupts") is a more likely candidate.

> 
> BR,
> Jani.
> 
> 
> 
> >
> > [   75.514651] RPM wakelock ref not held during HW access
> > [   75.514827] [ cut here ]
> > [   75.515025] WARNING: CPU: 2 PID: 1832 at 
> > drivers/gpu/drm/i915/intel_drv.h:1780 fwtable_write32+0x1d3/0x240 [i915]
> > ...
> > [   75.515704] RIP: 0010:fwtable_write32+0x1d3/0x240 [i915]
> > ...
> > [   75.515767] Call Trace:
> > [   75.515952]  lpe_audio_irq_unmask+0x6a/0xc0 [i915]
> > [   75.515972]  irq_enable+0x3a/0x50
> > [   75.515984]  __enable_irq+0x34/0x60
> > [   75.515996]  resume_irqs+0x8f/0xd0
> > [   75.516007]  resume_device_irqs+0x10/0x20
> > [   75.516021]  dpm_resume_noirq+0x23e/0x310
> > [   75.516041]  suspend_devices_and_enter+0x2f3/0x7f0
> > [   75.516055]  ? finish_wait+0x80/0x80
> > [   75.516067]  pm_suspend+0x335/0x3a0
> > [   75.516078]  state_store+0x85/0xf0
> > [   75.516095]  kobj_attr_store+0xf/0x20
> > [   75.516108]  sysfs_kf_write+0x37/0x40
> > [   75.516117]  kernfs_fop_write+0x11c/0x1a0
> > [   75.516132]  __vfs_write+0x37/0x160
> > [   75.516145]  ? selinux_file_permission+0xfb/0x120
> > [   75.516158]  ? security_file_permission+0x3b/0xc0
> > [   75.516169]  vfs_write+0xb1/0x1a0
> > [   75.516180]  SyS_write+0x55/0xc0
> > [   75.516197]  entry_SYSCALL_64_fastpath+0x1a/0xa5
> > ...
> > [   76.584235] PM: early resume of devices complete after 1067.477 msecs
> >
> > If someone has a fix for this they want me to try, let me know.
> >
> > Regards,
> >
> > Hans
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
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 02/17] drm/i915: introduce gtt page size

[Chris Wilson]

On Tue, May 16, 2017 at 09:29:33AM +0100, Matthew Auld wrote:
> In preparation for supporting huge gtt pages for the ppgtt, we introduce
> a gtt_page_size member for gem objects.  We fill in the gtt page size by
> scanning the sg table to determine the max page size which satisfies the
> alignment for each sg entry.
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  2 ++
>  drivers/gpu/drm/i915/i915_gem.c| 23 +++
>  drivers/gpu/drm/i915/i915_gem_object.h |  2 ++
>  3 files changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e18f11f77f35..a7a108d18a2d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2843,6 +2843,8 @@ intel_info(const struct drm_i915_private *dev_priv)
>  #define USES_PPGTT(dev_priv) (i915.enable_ppgtt)
>  #define USES_FULL_PPGTT(dev_priv)(i915.enable_ppgtt >= 2)
>  #define USES_FULL_48BIT_PPGTT(dev_priv)  (i915.enable_ppgtt == 3)
> +#define HAS_PAGE_SIZE(dev_priv, page_size) \
> + ((dev_priv)->info.page_size_mask & (page_size))
>  
>  #define HAS_OVERLAY(dev_priv) ((dev_priv)->info.has_overlay)
>  #define OVERLAY_NEEDS_PHYSICAL(dev_priv) \
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 0c1cbe98c994..6a5e864d7710 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2294,6 +2294,8 @@ void __i915_gem_object_put_pages(struct 
> drm_i915_gem_object *obj,
>   if (!IS_ERR(pages))
>   obj->ops->put_pages(obj, pages);
>  
> + obj->gtt_page_size = 0;
> +
>  unlock:
>   mutex_unlock(&obj->mm.lock);
>  }
> @@ -2473,6 +2475,13 @@ i915_gem_object_get_pages_gtt(struct 
> drm_i915_gem_object *obj)
>  void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
>struct sg_table *pages)
>  {
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + unsigned long supported_page_sizes = INTEL_INFO(i915)->page_size_mask;
> + struct scatterlist *sg;
> + unsigned int sg_mask = 0;
> + unsigned int i;
> + unsigned int bit;
> +
>   lockdep_assert_held(&obj->mm.lock);
>  
>   obj->mm.get_page.sg_pos = pages->sgl;
> @@ -2486,6 +2495,20 @@ void __i915_gem_object_set_pages(struct 
> drm_i915_gem_object *obj,
>   __i915_gem_object_pin_pages(obj);
>   obj->mm.quirked = true;
>   }
> +
> + for_each_sg(pages->sgl, sg, pages->nents, i)
> + sg_mask |= sg->length;
> +
> + GEM_BUG_ON(!sg_mask);
> +

This should just be obj->gtt_page_sizes = sg_mask & supported_sizes;

And it should be obj->mm.gtt_page_sizes.

Then latter steps can make decisions based on the most strict
requirements, or least strict etc.
-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 06/17] mm/shmem: expose driver overridable huge option

[Kirill A. Shutemov]

On Tue, May 16, 2017 at 09:29:37AM +0100, Matthew Auld wrote:
> In i915 we are aiming to support huge GTT pages for the GPU, and to
> complement this we also want to enable THP for our shmem backed objects.
> Even though THP is supported in shmemfs it can only be enabled through
> the huge= mount option, but for users of the kernel mounted shm_mnt like
> i915, we are a little stuck. There is the sysfs knob shmem_enabled to
> either forcefully enable/disable the feature, but that seems to only be
> useful for testing purposes. What we propose is to expose a driver
> overridable huge option as part of shmem_inode_info to control the use
> of THP for a given mapping.

I don't like this. It's kinda hacky.

Is there a reason why i915 cannot mount a new tmpfs for own use?

Or other option would be to change default to SHMEM_HUGE_ADVISE and wire
up fadvise handle to control per-file allocation policy.

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

Re: [Intel-gfx] [PATCH 11/17] drm/i915: disable GTT cache for 2M/1G pages

[Ville Syrjälä]

On Tue, May 16, 2017 at 09:29:42AM +0100, Matthew Auld wrote:
> When SW enables the use of 2M/1G pages, it must disable the GTT cache.
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ef0e9f8d4dbd..b39b8d394179 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -8178,10 +8178,10 @@ static void broadwell_init_clock_gating(struct 
> drm_i915_private *dev_priv)
>  
>   /*
>* WaGttCachingOffByDefault:bdw
> -  * GTT cache may not work with big pages, so if those
> -  * are ever enabled GTT cache may need to be disabled.
> +  * The GTT cache must be disabled if the system is planning to use
> +  * 2M/1G pages.
>*/
> - I915_WRITE(HSW_GTT_CACHE_EN, GTT_CACHE_EN_ALL);
> + I915_WRITE(HSW_GTT_CACHE_EN, 0);
>  
>   /* WaKVMNotificationOnConfigChange:bdw */
>   I915_WRITE(CHICKEN_PAR2_1, I915_READ(CHICKEN_PAR2_1)
> @@ -8457,10 +8457,10 @@ static void cherryview_init_clock_gating(struct 
> drm_i915_private *dev_priv)
>   gen8_set_l3sqc_credits(dev_priv, 38, 2);
>  
>   /*
> -  * GTT cache may not work with big pages, so if those
> -  * are ever enabled GTT cache may need to be disabled.
> +  * The GTT cache must be disabled if the system is planning to use
> +  * 2M/1G pages.
>*/
> - I915_WRITE(HSW_GTT_CACHE_EN, GTT_CACHE_EN_ALL);
> + I915_WRITE(HSW_GTT_CACHE_EN, 0);
>  }

Should we perhaps have a modparam to make it easier to evaluate
whether big pages are actually beneficial or not? If so, it should also
affect whether we enable the the GTT cache or not.

>  
>  static void g4x_init_clock_gating(struct drm_i915_private *dev_priv)
> -- 
> 2.9.4
> 
> ___
> 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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to capture the state of the GPU

[Lofstedt, Marta]

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, May 16, 2017 12:48 PM
> To: Lofstedt, Marta 
> Cc: Daniel Vetter ; Martin Peres
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to 
> capture
> the state of the GPU
> 
> On Tue, May 16, 2017 at 09:43:52AM +, Lofstedt, Marta wrote:
> >
> >
> > > -Original Message-
> > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > Sent: Tuesday, May 16, 2017 12:04 PM
> > > To: Lofstedt, Marta 
> > > Cc: Daniel Vetter ; Martin Peres
> > > ; intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a
> > > test to capture the state of the GPU
> > >
> > > On Tue, May 16, 2017 at 08:54:51AM +, Lofstedt, Marta wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > > > Sent: Tuesday, May 16, 2017 11:21 AM
> > > > > To: Lofstedt, Marta 
> > > > > Cc: Daniel Vetter ; Martin Peres
> > > > > ; intel-gfx@lists.freedesktop.org
> > > > > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add
> > > > > a test to capture the state of the GPU
> > > > >
> > > > > On Tue, May 16, 2017 at 07:42:51AM +, Lofstedt, Marta wrote:
> > > > > > I hereby pull-out this patch.
> > > > > > The idea of it was to know if we were already wedged at the
> > > > > > beginning of
> > > > > testing, that would give us information on how to interpret
> > > > > silly results; such that test starting to get skipped and/or we
> > > > > got dmesg-warns/incomplete on tests that usually should be skipped.
> > > > > > Also, we are planning to soon deploy a piglit.conf solution
> > > > > > where testing
> > > > > will be terminated on wedged, so I agree that my test isn't really
> needed.
> > > > >
> > > > > Not everything is broken by wedged; internally we just use that
> > > > > as an indicator that GEM is hosed. KMS should still work, we
> > > > > must still be able to drive the displays to show the error and
> > > > > keep the servers alive until the data is saved (and hopefully
> > > > > gracefully degrade that we don't have to interrupt their immediate
> session).
> > > >
> > > > It doesn't matter if it is broken or not, if we are terminally
> > > > wedged the rest
> > > of the result may be silly. Look for example at CI_DRM_2612, the
> > > fi-elk-e7500 is wedged at igt@gem_busy@basic-hang-default, then all
> > > test are skipped until gem_exec_reloc@basic-cpu-gtt-noreloc where
> > > the machine hangs, but it is a gem test so it should have been
> > > skipped, right. My conclusion from seeing this pattern multiple
> > > times is that after terminally wedged, silly things can happen, i.e.
> > > we can't trust the results, and since we don't want silly bugs, the CI
> testing should be stopped.
> > >
> > > The machine didn't hang, it was remotely killed because the run timed
> out.
> > How do you know that?
> 
> The dmesg is a stream of flip timeouts until we run out of total BAT runtime
> (12 minutes + some startup slack).
> -Chris

Then look at CI_DRM_2602, wedged at igt@gem_busy@basic-hang-default, after a 
lot of skipping, we get incomplete result for another test, this time 
gem_exec_reloc@basic-gtt-cpu-noreloc

So, gem_exec_reloc@basic-cpu-gtt-noreloc and 
gem_exec_reloc@basic-gtt-cpu-noreloc are falsely getting blamed and my 
conclusion is that this is due to the permanent wedging started at 
gem_busy@basic-hang-default. So, to avoid bug reports for 
gem_exec_reloc@basic-cpu-gtt-noreloc and gem_exec_reloc@basic-gtt-cpu- noreloc 
the suggestion is to stop testing after we are terminally wedged. 

> 
> --
> 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 11/17] drm/i915: disable GTT cache for 2M/1G pages

[Chris Wilson]

On Tue, May 16, 2017 at 01:04:38PM +0300, Ville Syrjälä wrote:
> On Tue, May 16, 2017 at 09:29:42AM +0100, Matthew Auld wrote:
> > When SW enables the use of 2M/1G pages, it must disable the GTT cache.
> > 
> > Signed-off-by: Matthew Auld 
> > Cc: Joonas Lahtinen 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c 
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index ef0e9f8d4dbd..b39b8d394179 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -8178,10 +8178,10 @@ static void broadwell_init_clock_gating(struct 
> > drm_i915_private *dev_priv)
> >  
> > /*
> >  * WaGttCachingOffByDefault:bdw
> > -* GTT cache may not work with big pages, so if those
> > -* are ever enabled GTT cache may need to be disabled.
> > +* The GTT cache must be disabled if the system is planning to use
> > +* 2M/1G pages.
> >  */
> > -   I915_WRITE(HSW_GTT_CACHE_EN, GTT_CACHE_EN_ALL);
> > +   I915_WRITE(HSW_GTT_CACHE_EN, 0);
> >  
> > /* WaKVMNotificationOnConfigChange:bdw */
> > I915_WRITE(CHICKEN_PAR2_1, I915_READ(CHICKEN_PAR2_1)
> > @@ -8457,10 +8457,10 @@ static void cherryview_init_clock_gating(struct 
> > drm_i915_private *dev_priv)
> > gen8_set_l3sqc_credits(dev_priv, 38, 2);
> >  
> > /*
> > -* GTT cache may not work with big pages, so if those
> > -* are ever enabled GTT cache may need to be disabled.
> > +* The GTT cache must be disabled if the system is planning to use
> > +* 2M/1G pages.
> >  */
> > -   I915_WRITE(HSW_GTT_CACHE_EN, GTT_CACHE_EN_ALL);
> > +   I915_WRITE(HSW_GTT_CACHE_EN, 0);
> >  }
> 
> Should we perhaps have a modparam to make it easier to evaluate
> whether big pages are actually beneficial or not? If so, it should also
> affect whether we enable the the GTT cache or not.

If we are sticking to only using it on bdw 48b, then ppgtt=4? It doesn't
seem a good idea for a long term modparam, but who wants to keep a
modparam around where users might find it?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: use vma->size for appgtt allocate_va_range

[Patchwork]

== Series Details ==

Series: drm/i915: use vma->size for appgtt allocate_va_range
URL   : https://patchwork.freedesktop.org/series/24485/
State : success

== Summary ==

Series 24485v1 drm/i915: use vma->size for appgtt allocate_va_range
https://patchwork.freedesktop.org/api/1.0/series/24485/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass   -> FAIL   (fi-snb-2600) fdo#100215

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:448s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:439s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:585s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:517s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:489s
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:409s
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:502s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:466s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:466s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:579s
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:584s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:464s
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:439s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:544s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:400s

eb4cff1ea4032532931b804ecae4f29b1c9a8e6e drm-tip: 2017y-05m-16d-09h-32m-03s UTC 
integration manifest
d0f205e drm/i915: use vma->size for appgtt allocate_va_range

== Logs ==

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

Re: [Intel-gfx] [PATCH] dma-buf/sync-file: Defer creation of sync_file->name

[kbuild test robot]

Hi Chris,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc1 next-20170516]
[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/dma-buf-sync-file-Defer-creation-of-sync_file-name/20170512-193751
config: x86_64-rhel (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 errors (new ones prefixed by >>):

   drivers//dma-buf/sync_debug.c: In function 'sync_print_sync_file':
>> drivers//dma-buf/sync_debug.c:137:53: error: 'struct sync_file' has no 
>> member named 'name'
 seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
^~

vim +137 drivers//dma-buf/sync_debug.c

0f0d8406 drivers/staging/android/sync_debug.c Maarten Lankhorst 2014-07-01  131 
 
d7fdb0ae drivers/staging/android/sync_debug.c Gustavo Padovan   2016-01-21  132 
 static void sync_print_sync_file(struct seq_file *s,
d7fdb0ae drivers/staging/android/sync_debug.c Gustavo Padovan   2016-01-21  133 
  struct sync_file *sync_file)
0f0d8406 drivers/staging/android/sync_debug.c Maarten Lankhorst 2014-07-01  134 
 {
0f0d8406 drivers/staging/android/sync_debug.c Maarten Lankhorst 2014-07-01  135 
int i;
0f0d8406 drivers/staging/android/sync_debug.c Maarten Lankhorst 2014-07-01  136 
 
d7fdb0ae drivers/staging/android/sync_debug.c Gustavo Padovan   2016-01-21 @137 
seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
d6c99f4b drivers/dma-buf/sync_debug.c Chris Wilson  2017-01-04  138 
   sync_status_str(dma_fence_get_status(sync_file->fence)));
0f0d8406 drivers/staging/android/sync_debug.c Maarten Lankhorst 2014-07-01  139 
 
f54d1867 drivers/dma-buf/sync_debug.c Chris Wilson  2016-10-25  140 
if (dma_fence_is_array(sync_file->fence)) {

:: The code at line 137 was first introduced by commit
:: d7fdb0ae9d115fa14ff3a5382c8a62de41c7786a staging/android: rename 
sync_fence to sync_file

:: TO: Gustavo Padovan 
:: CC: Greg Kroah-Hartman 

---
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] ✓ Fi.CI.BAT: success for drm/i915: use vma->size for appgtt allocate_va_range

[Chris Wilson]

On Tue, May 16, 2017 at 10:19:42AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: use vma->size for appgtt allocate_va_range
> URL   : https://patchwork.freedesktop.org/series/24485/
> State : success
> 
> == Summary ==
> 
> Series 24485v1 drm/i915: use vma->size for appgtt allocate_va_range
> https://patchwork.freedesktop.org/api/1.0/series/24485/revisions/1/mbox/
> 
> Test kms_cursor_legacy:
> Subgroup basic-busy-flip-before-cursor-atomic:
> pass   -> FAIL   (fi-snb-2600) fdo#100215
> 
> fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215

Applied, thanks for yet another bugfix.
-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] New "RPM wakelock ref not held during HW access" in 4.12-rc1 ?

[Jani Nikula]

On Tue, 16 May 2017, Ville Syrjälä  wrote:
> mn Tue, May 16, 2017 at 10:47:48AM +0300, Jani Nikula wrote:
>> On Mon, 15 May 2017, Hans de Goede  wrote:
>> > Hi,
>> >
>> > I'm seeing this on suspend/resume on a GPD-win,
>> > cherrytrail z8700 device:
>> 
>> Ville, does
>> 
>> commit 668e3b014afb66ab29e134bca7c258527273ac75
>> Author: Ville Syrjälä 
>> Date:   Thu Apr 27 19:02:20 2017 +0300
>> 
>> drm/i915: Fix runtime PM for LPE audio
>> 
>> in drm-intel-fixes address this?
>
> ebf5f921478b ("drm/i915: Stop pretending to mask/unmask LPE audio
> interrupts") is a more likely candidate.

Is that applicable to v4.12-rc1?

BR,
Jani.


>
>> 
>> BR,
>> Jani.
>> 
>> 
>> 
>> >
>> > [   75.514651] RPM wakelock ref not held during HW access
>> > [   75.514827] [ cut here ]
>> > [   75.515025] WARNING: CPU: 2 PID: 1832 at 
>> > drivers/gpu/drm/i915/intel_drv.h:1780 fwtable_write32+0x1d3/0x240 [i915]
>> > ...
>> > [   75.515704] RIP: 0010:fwtable_write32+0x1d3/0x240 [i915]
>> > ...
>> > [   75.515767] Call Trace:
>> > [   75.515952]  lpe_audio_irq_unmask+0x6a/0xc0 [i915]
>> > [   75.515972]  irq_enable+0x3a/0x50
>> > [   75.515984]  __enable_irq+0x34/0x60
>> > [   75.515996]  resume_irqs+0x8f/0xd0
>> > [   75.516007]  resume_device_irqs+0x10/0x20
>> > [   75.516021]  dpm_resume_noirq+0x23e/0x310
>> > [   75.516041]  suspend_devices_and_enter+0x2f3/0x7f0
>> > [   75.516055]  ? finish_wait+0x80/0x80
>> > [   75.516067]  pm_suspend+0x335/0x3a0
>> > [   75.516078]  state_store+0x85/0xf0
>> > [   75.516095]  kobj_attr_store+0xf/0x20
>> > [   75.516108]  sysfs_kf_write+0x37/0x40
>> > [   75.516117]  kernfs_fop_write+0x11c/0x1a0
>> > [   75.516132]  __vfs_write+0x37/0x160
>> > [   75.516145]  ? selinux_file_permission+0xfb/0x120
>> > [   75.516158]  ? security_file_permission+0x3b/0xc0
>> > [   75.516169]  vfs_write+0xb1/0x1a0
>> > [   75.516180]  SyS_write+0x55/0xc0
>> > [   75.516197]  entry_SYSCALL_64_fastpath+0x1a/0xa5
>> > ...
>> > [   76.584235] PM: early resume of devices complete after 1067.477 msecs
>> >
>> > If someone has a fix for this they want me to try, let me know.
>> >
>> > Regards,
>> >
>> > Hans
>> > ___
>> > Intel-gfx mailing list
>> > Intel-gfx@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> 
>> -- 
>> Jani Nikula, Intel Open Source Technology Center

-- 
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 i-g-t] tests/initial_state: Add a test to capture the state of the GPU

[Chris Wilson]

On Tue, May 16, 2017 at 10:07:41AM +, Lofstedt, Marta wrote:
> 
> 
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Tuesday, May 16, 2017 12:48 PM
> > To: Lofstedt, Marta 
> > Cc: Daniel Vetter ; Martin Peres
> > ; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to 
> > capture
> > the state of the GPU
> > 
> > On Tue, May 16, 2017 at 09:43:52AM +, Lofstedt, Marta wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > > Sent: Tuesday, May 16, 2017 12:04 PM
> > > > To: Lofstedt, Marta 
> > > > Cc: Daniel Vetter ; Martin Peres
> > > > ; intel-gfx@lists.freedesktop.org
> > > > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a
> > > > test to capture the state of the GPU
> > > >
> > > > On Tue, May 16, 2017 at 08:54:51AM +, Lofstedt, Marta wrote:
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > > > > Sent: Tuesday, May 16, 2017 11:21 AM
> > > > > > To: Lofstedt, Marta 
> > > > > > Cc: Daniel Vetter ; Martin Peres
> > > > > > ; intel-gfx@lists.freedesktop.org
> > > > > > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add
> > > > > > a test to capture the state of the GPU
> > > > > >
> > > > > > On Tue, May 16, 2017 at 07:42:51AM +, Lofstedt, Marta wrote:
> > > > > > > I hereby pull-out this patch.
> > > > > > > The idea of it was to know if we were already wedged at the
> > > > > > > beginning of
> > > > > > testing, that would give us information on how to interpret
> > > > > > silly results; such that test starting to get skipped and/or we
> > > > > > got dmesg-warns/incomplete on tests that usually should be skipped.
> > > > > > > Also, we are planning to soon deploy a piglit.conf solution
> > > > > > > where testing
> > > > > > will be terminated on wedged, so I agree that my test isn't really
> > needed.
> > > > > >
> > > > > > Not everything is broken by wedged; internally we just use that
> > > > > > as an indicator that GEM is hosed. KMS should still work, we
> > > > > > must still be able to drive the displays to show the error and
> > > > > > keep the servers alive until the data is saved (and hopefully
> > > > > > gracefully degrade that we don't have to interrupt their immediate
> > session).
> > > > >
> > > > > It doesn't matter if it is broken or not, if we are terminally
> > > > > wedged the rest
> > > > of the result may be silly. Look for example at CI_DRM_2612, the
> > > > fi-elk-e7500 is wedged at igt@gem_busy@basic-hang-default, then all
> > > > test are skipped until gem_exec_reloc@basic-cpu-gtt-noreloc where
> > > > the machine hangs, but it is a gem test so it should have been
> > > > skipped, right. My conclusion from seeing this pattern multiple
> > > > times is that after terminally wedged, silly things can happen, i.e.
> > > > we can't trust the results, and since we don't want silly bugs, the CI
> > testing should be stopped.
> > > >
> > > > The machine didn't hang, it was remotely killed because the run timed
> > out.
> > > How do you know that?
> > 
> > The dmesg is a stream of flip timeouts until we run out of total BAT runtime
> > (12 minutes + some startup slack).
> > -Chris
> 
> Then look at CI_DRM_2602, wedged at igt@gem_busy@basic-hang-default, after a 
> lot of skipping, we get incomplete result for another test, this time 
> gem_exec_reloc@basic-gtt-cpu-noreloc
> 
> So, gem_exec_reloc@basic-cpu-gtt-noreloc and 
> gem_exec_reloc@basic-gtt-cpu-noreloc are falsely getting blamed and my 
> conclusion is that this is due to the permanent wedging started at 
> gem_busy@basic-hang-default. So, to avoid bug reports for 
> gem_exec_reloc@basic-cpu-gtt-noreloc and gem_exec_reloc@basic-gtt-cpu- 
> noreloc the suggestion is to stop testing after we are terminally wedged. 

The conclusion is still wrong though, it doesn't derive from the wedged
state itself but from another bug that can be triggered by a recovered
gpu hang. The issue is that post-processing isn't yet smart enough to
determine the real cause and picks on the victim. We are always going to
have that problem in some form, the question is what can be done to make
the process smart to avoid false positives or rather just say this is a
general bug and be careful not to be precise on the blame.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "Revert "sched/clock: Fix broken stable to unstable transfer""

[Patchwork]

== Series Details ==

Series: Revert "Revert "sched/clock: Fix broken stable to unstable transfer""
URL   : https://patchwork.freedesktop.org/series/24489/
State : success

== Summary ==

Series 24489v1 Revert "Revert "sched/clock: Fix broken stable to unstable 
transfer""
https://patchwork.freedesktop.org/api/1.0/series/24489/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-snb-2600) fdo#100125

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:457s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:435s
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:515s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
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:419s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:408s
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:491s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:472s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:465s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:570s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:459s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:580s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:466s
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:438s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:538s
fi-snb-2600  total:278  pass:248  dwarn:1   dfail:0   fail:0   skip:29  
time:407s

eb4cff1ea4032532931b804ecae4f29b1c9a8e6e drm-tip: 2017y-05m-16d-09h-32m-03s UTC 
integration manifest
c544214 Revert "Revert "sched/clock: Fix broken stable to unstable transfer""

== Logs ==

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

[Intel-gfx] [PATCH v5] dma-buf/sync-file: Defer creation of sync_file->name

[Chris Wilson]

Constructing the name takes the majority of the time for allocating a
sync_file to wrap a fence, and the name is very rarely used (only via
the sync_file status user interface). To reduce the impact on the common
path (that of creating sync_file to pass around), defer the construction
of the name until it is first used.

v2: Update kerneldoc (kbuild test robot)
v3: sync_debug.c was peeking at the name
v4: Comment upon the potential race between two users of
sync_file_get_name() and claim that such a race is below the level of
notice. However, to prevent any future nuisance, use a global spinlock
to serialize the assignment of the name.
v5: Completely avoid the read/write race by only storing the name passed
in from the user inside sync_file->user_name and passing in a buffer to
dynamically construct the name otherwise.

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: Daniel Vetter 
Cc: David Herrmann 
---
 drivers/dma-buf/sync_debug.c |  4 +++-
 drivers/dma-buf/sync_file.c  | 39 ---
 include/linux/sync_file.h|  5 +++--
 3 files changed, 38 insertions(+), 10 deletions(-)

diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
index 4b1731ee7458..59a3b2f8ee91 100644
--- a/drivers/dma-buf/sync_debug.c
+++ b/drivers/dma-buf/sync_debug.c
@@ -132,9 +132,11 @@ static void sync_print_obj(struct seq_file *s, struct 
sync_timeline *obj)
 static void sync_print_sync_file(struct seq_file *s,
  struct sync_file *sync_file)
 {
+   char buf[128];
int i;
 
-   seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
+   seq_printf(s, "[%p] %s: %s\n", sync_file,
+  sync_file_get_name(sync_file, buf, sizeof(buf)),
   sync_status_str(dma_fence_get_status(sync_file->fence)));
 
if (dma_fence_is_array(sync_file->fence)) {
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index c9eb4997cfcc..d7e219d2669d 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -80,11 +80,6 @@ struct sync_file *sync_file_create(struct dma_fence *fence)
 
sync_file->fence = dma_fence_get(fence);
 
-   snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%llu-%d",
-fence->ops->get_driver_name(fence),
-fence->ops->get_timeline_name(fence), fence->context,
-fence->seqno);
-
return sync_file;
 }
 EXPORT_SYMBOL(sync_file_create);
@@ -129,6 +124,36 @@ struct dma_fence *sync_file_get_fence(int fd)
 }
 EXPORT_SYMBOL(sync_file_get_fence);
 
+/**
+ * sync_file_get_name - get the name of the sync_file
+ * @sync_file: sync_file to get the fence from
+ * @buf:   destination buffer to copy sync_file name into
+ * @len:   available size of destination buffer.
+ *
+ * Each sync_file may have a name assigned either by the user (when merging
+ * sync_files together) or created from the fence it contains. In the latter
+ * case construction of the name is deferred until use, and so requires
+ * sync_file_get_name().
+ *
+ * Returns: a string representing the name.
+ */
+char *sync_file_get_name(struct sync_file *sync_file, char *buf, int len)
+{
+   if (sync_file->user_name[0]) {
+   strlcpy(buf, sync_file->user_name, len);
+   } else {
+   struct dma_fence *fence = sync_file->fence;
+
+   snprintf(buf, len, "%s-%s%llu-%d",
+fence->ops->get_driver_name(fence),
+fence->ops->get_timeline_name(fence),
+fence->context,
+fence->seqno);
+   }
+
+   return buf;
+}
+
 static int sync_file_set_fence(struct sync_file *sync_file,
   struct dma_fence **fences, int num_fences)
 {
@@ -266,7 +291,7 @@ static struct sync_file *sync_file_merge(const char *name, 
struct sync_file *a,
goto err;
}
 
-   strlcpy(sync_file->name, name, sizeof(sync_file->name));
+   strlcpy(sync_file->user_name, name, sizeof(sync_file->user_name));
return sync_file;
 
 err:
@@ -419,7 +444,7 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
}
 
 no_fences:
-   strlcpy(info.name, sync_file->name, sizeof(info.name));
+   sync_file_get_name(sync_file, info.name, sizeof(info.name));
info.status = dma_fence_is_signaled(sync_file->fence);
info.num_fences = num_fences;
 
diff --git a/include/linux/sync_file.h b/include/linux/sync_file.h
index d37beefdfbd5..5226d62ae91b 100644
--- a/include/linux/sync_file.h
+++ b/include/linux/sync_file.h
@@ -23,7 +23,7 @@
 /**
  * struct sync_file - sync file to export to the userspace
  * @file:  file representing this fence
- * @name:  name of sync_file.  Useful for debugging
+ * @user_name: name of sync_file.  Useful for debugging
  * @sync_file_list:membersh

Re: [Intel-gfx] [PATCH 12/12] drm/i915/skl+: consider max supported plane pixel rate while scaling

[Maarten Lankhorst]

Op 15-05-17 om 10:34 schreef Mahesh Kumar:
> From: "Kumar, Mahesh" 
>
> A display resolution is only supported if it meets all the restrictions
> below for Maximum Pipe Pixel Rate.
>
> The display resolution must fit within the maximum pixel rate output
> from the pipe. Make sure that the display pipe is able to feed pixels at
> a rate required to support the desired resolution.
> For each enabled plane on the pipe {
> If plane scaling enabled {
>   Horizontal down scale amount = Maximum[1, plane horizontal size /
>   scaler horizontal window size]
>   Vertical down scale amount = Maximum[1, plane vertical size /
>   scaler vertical window size]
>   Plane down scale amount = Horizontal down scale amount *
>   Vertical down scale amount
>   Plane Ratio = 1 / Plane down scale amount
> }
> Else {
>   Plane Ratio = 1
> }
> If plane source pixel format is 64 bits per pixel {
>   Plane Ratio = Plane Ratio * 8/9
> }
> }
>
> Pipe Ratio = Minimum Plane Ratio of all enabled planes on the pipe
>
> If pipe scaling is enabled {
> Horizontal down scale amount = Maximum[1, pipe horizontal source size /
>   scaler horizontal window size]
> Vertical down scale amount = Maximum[1, pipe vertical source size /
>   scaler vertical window size]
> Note: The progressive fetch - interlace display mode is equivalent to a
>   2.0 vertical down scale
> Pipe down scale amount = Horizontal down scale amount *
>   Vertical down scale amount
> Pipe Ratio = Pipe Ratio / Pipe down scale amount
> }
>
> Pipe maximum pixel rate = CDCLK frequency * Pipe Ratio
>
> Changes since V1:
>  - separate out fixed_16_16 wrapper API definition
> Changes since V2:
>  - Fix buggy crtc !active condition (Maarten)
>  - use intel_wm_plane_visible wrapper as per Maarten's suggestion
> Changes since V3:
>  - Change failure return from ERANGE to EINVAL
> Changes since V3:
>  - Rebase based on previous patch changes
>
> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/i915/intel_display.c |  3 ++
>  drivers/gpu/drm/i915/intel_drv.h |  2 +
>  drivers/gpu/drm/i915/intel_pm.c  | 87 
> 
>  3 files changed, 92 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index c1cbfcef1f89..2cc1d11d9e6c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11186,6 +11186,9 @@ static int intel_crtc_atomic_check(struct drm_crtc 
> *crtc,
>   ret = skl_update_scaler_crtc(pipe_config);
>  
>   if (!ret)
> + ret = skl_check_pipe_max_pixel_rate(intel_crtc,
> + pipe_config);
> + if (!ret)
>   ret = intel_atomic_setup_scalers(dev_priv, intel_crtc,
>pipe_config);
>   }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index bd500977b3fc..93afac4a83fa 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1885,6 +1885,8 @@ bool skl_ddb_allocation_overlaps(const struct 
> skl_ddb_entry **entries,
>int ignore);
>  bool ilk_disable_lp_wm(struct drm_device *dev);
>  int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
> +int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc,
> +   struct intel_crtc_state *cstate);
>  static inline int intel_enable_rc6(void)
>  {
>   return i915.enable_rc6;
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index d6b0ae0ef7a2..5a3d3398ae19 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3863,6 +3863,93 @@ skl_plane_downscale_amount(const struct 
> intel_crtc_state *cstate,
>   return mul_fixed16(downscale_w, downscale_h);
>  }
>  
> +static uint_fixed_16_16_t
> +skl_pipe_downscale_amount(const struct intel_crtc_state *config)
> +{
> + uint_fixed_16_16_t pipe_downscale = u32_to_fixed_16_16(1);
> +
> + if (!config->base.active)
> + return pipe_downscale;
> +
> + if (config->pch_pfit.enabled) {
> + uint32_t src_w, src_h, dst_w, dst_h;
> + uint32_t pfit_size = config->pch_pfit.size;
> + uint_fixed_16_16_t fp_w_ratio, fp_h_ratio;
> + uint_fixed_16_16_t downscale_h, downscale_w;
> +
> + src_w = config->pipe_src_w;
> + src_h = config->pipe_src_h;
> + dst_w = pfit_size >> 16;
> + dst_h = pfit_size & 0x;
> +
> + if (!dst_w || !dst_h)
> + return pipe_downscale;
> +
> + fp_w_ratio = fixed_16_16_div(src_w, dst_w);
> + fp_h_ratio = 

[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf/sync-file: Defer creation of sync_file->name (rev4)

[Patchwork]

== Series Details ==

Series: dma-buf/sync-file: Defer creation of sync_file->name (rev4)
URL   : https://patchwork.freedesktop.org/series/24353/
State : success

== Summary ==

Series 24353v4 dma-buf/sync-file: Defer creation of sync_file->name
https://patchwork.freedesktop.org/api/1.0/series/24353/revisions/4/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> FAIL   (fi-snb-2600) fdo#100215

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:447s
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:582s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:512s
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:493s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:423s
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:417s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:506s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:472s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:467s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:579s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:459s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:582s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:466s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:500s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:442s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:538s
fi-snb-2600  total:278  pass:247  dwarn:0   dfail:0   fail:2   skip:29  
time:404s

fb5cb398a048f8e0fd9dab5686caba61961131be drm-tip: 2017y-05m-16d-11h-13m-20s UTC 
integration manifest
d559328 dma-buf/sync-file: Defer creation of sync_file->name

== Logs ==

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

Re: [Intel-gfx] [PATCH 11/12] drm/i915/skl: New ddb allocation algorithm

[Mahesh Kumar]

Hi,


On Tuesday 16 May 2017 04:08 AM, Matt Roper wrote:

On Mon, May 15, 2017 at 02:04:36PM +0530, Mahesh Kumar wrote:

From: "Kumar, Mahesh" 

This patch implements new DDB allocation algorithm as per HW team
recommendation. This algo takecare of scenario where we allocate less DDB
for the planes with lower relative pixel rate, but they require more DDB
to work.
It also takes care of enabling same watermark level for each
plane in crtc, for efficient power saving.

Changes since v1:
  - Rebase on top of Paulo's patch series

Changes since v2:
  - Fix the for loop condition to enable WM

Changes since v3:
  - Fix crash in cursor i-g-t reported by Maarten
  - Rebase after addressing Paulo's comments
  - Few other ULT fixes
Changes since v4:
  - Rebase on drm-tip
  - Added separate function to enable WM levels
Changes since v5:
  - Fix a crash identified in skl-6770HQ system

Signed-off-by: Mahesh Kumar 
---
  drivers/gpu/drm/i915/intel_pm.c | 253 
  1 file changed, 152 insertions(+), 101 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d73369c2c2d9..d6b0ae0ef7a2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4039,13 +4039,41 @@ skl_ddb_calc_min(const struct intel_crtc_state *cstate, 
int num_active,
minimum[PLANE_CURSOR] = skl_cursor_allocation(num_active);
  }
  
+static void

+skl_enable_plane_wm_levels(const struct drm_i915_private *dev_priv,
+  uint16_t plane_ddb,
+  uint16_t max_level,
+  struct skl_plane_wm *wm)
+{
+   int level;
+   /*
+* Now enable all levels in WM structure which can be enabled
+* using current DDB allocation
+*/
+   for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {
+   struct skl_wm_level *level_wm = &wm->wm[level];
+
+   if (level > max_level || level_wm->plane_res_b == 0
+ || level_wm->plane_res_l >= 31
+ || level_wm->plane_res_b >= plane_ddb) {

Is it possible to hit level_wm->plane_res_b >= plane_ddb without hitting
level > max_level given our new logic?
Yes, this is possible for cursor plane, in multi-display scenario we 
allocate fixed 8 blocks to cursor.
In some cases this may not be sufficient to enable all the WM levels 
which can be enabled for other planes.





+   level_wm->plane_en = false;
+   level_wm->plane_res_b = 0;
+   level_wm->plane_res_l = 0;
+   } else {
+   level_wm->plane_en = true;
+   }
+   }
+}
+
  static int
  skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
- struct skl_ddb_allocation *ddb /* out */)
+ struct skl_ddb_allocation *ddb /* out */,
+ struct skl_pipe_wm *pipe_wm)

Not a huge deal, but it's a bit confusing to have the 'out' parameter in
the middle of 'in' parameters.  Maybe move the pipe_wm before the ddb
just to make this a little cleaner?

sure, will fix this.



  {
struct drm_atomic_state *state = cstate->base.state;
struct drm_crtc *crtc = cstate->base.crtc;
struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc->pipe;
struct skl_ddb_entry *alloc = &cstate->wm.skl.ddb;
@@ -4058,6 +4086,8 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
unsigned plane_data_rate[I915_MAX_PLANES] = {};
unsigned plane_y_data_rate[I915_MAX_PLANES] = {};
uint16_t total_min_blocks = 0;
+   uint16_t total_level_ddb;
+   int max_level, level;
  
  	/* Clear the partitioning for disabled planes. */

memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
@@ -4096,10 +4126,43 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
return -EINVAL;
}
  
-	alloc_size -= total_min_blocks;

-   ddb->plane[pipe][PLANE_CURSOR].start = alloc->end - 
minimum[PLANE_CURSOR];
+   alloc_size -= minimum[PLANE_CURSOR];
+   ddb->plane[pipe][PLANE_CURSOR].start = alloc->end -
+   minimum[PLANE_CURSOR];
ddb->plane[pipe][PLANE_CURSOR].end = alloc->end;
  
+	for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {

+   total_level_ddb = 0;
+   for_each_plane_id_on_crtc(intel_crtc, plane_id) {
+   /*
+* TODO: We should calculate watermark values for Y/UV
+* plane both in case of NV12 format and use both values
+* for ddb calculation. NV12 is disabled as of now, So
+* using only single/UV plane value here.
+   

[Intel-gfx] [PATCH 2/2] drm/i915: Reorder media/render reset on g4x

[Chris Wilson]

Ville found a reference to WaMediaResetBeforeFullReset which we presume
means that we should simply do the media reset first.

References: https://bugs.freedesktop.org/show_bug.cgi?id=100942
Suggested-by: Ville Syrjälä 
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_uncore.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index fc3da0a6fdbb..c3d0d81b50e4 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1504,12 +1504,6 @@ static int g4x_do_reset(struct drm_i915_private 
*dev_priv, unsigned engine_mask)
struct pci_dev *pdev = dev_priv->drm.pdev;
int ret;
 
-   pci_write_config_byte(pdev, I915_GDRST,
- GRDOM_RENDER | GRDOM_RESET_ENABLE);
-   ret =  wait_for(g4x_reset_complete(pdev), 500);
-   if (ret)
-   goto out;
-
/* WaVcpClkGateDisableForMediaReset:ctg,elk */
I915_WRITE(VDECCLK_GATE_D, I915_READ(VDECCLK_GATE_D) | 
VCP_UNIT_CLOCK_GATE_DISABLE);
POSTING_READ(VDECCLK_GATE_D);
@@ -1517,11 +1511,17 @@ static int g4x_do_reset(struct drm_i915_private 
*dev_priv, unsigned engine_mask)
pci_write_config_byte(pdev, I915_GDRST,
  GRDOM_MEDIA | GRDOM_RESET_ENABLE);
ret =  wait_for(g4x_reset_complete(pdev), 500);
+   if (ret)
+   goto out;
 
/* WaVcpClkGateDisableForMediaReset:ctg,elk */
I915_WRITE(VDECCLK_GATE_D, I915_READ(VDECCLK_GATE_D) & 
~VCP_UNIT_CLOCK_GATE_DISABLE);
POSTING_READ(VDECCLK_GATE_D);
 
+   pci_write_config_byte(pdev, I915_GDRST,
+ GRDOM_RENDER | GRDOM_RESET_ENABLE);
+   ret =  wait_for(g4x_reset_complete(pdev), 500);
+
 out:
pci_write_config_byte(pdev, I915_GDRST, 0);
return ret;
-- 
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: Try harder to reset the GPU

[Chris Wilson]

Repeat the reset a couple of times if at first we do not succeed.

Signed-off-by: Chris Wilson 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170513083726.502-1-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/intel_uncore.c | 44 +
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 71b9b387ad04..fc3da0a6fdbb 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1463,9 +1463,10 @@ int i915_reg_read_ioctl(struct drm_device *dev,
return ret;
 }
 
-static int i915_reset_complete(struct pci_dev *pdev)
+static bool i915_reset_complete(struct pci_dev *pdev)
 {
u8 gdrst;
+
pci_read_config_byte(pdev, I915_GDRST, &gdrst);
return (gdrst & GRDOM_RESET_STATUS) == 0;
 }
@@ -1476,15 +1477,16 @@ static int i915_do_reset(struct drm_i915_private 
*dev_priv, unsigned engine_mask
 
/* assert reset for at least 20 usec */
pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
-   udelay(20);
+   usleep_range(50, 200);
pci_write_config_byte(pdev, I915_GDRST, 0);
 
return wait_for(i915_reset_complete(pdev), 500);
 }
 
-static int g4x_reset_complete(struct pci_dev *pdev)
+static bool g4x_reset_complete(struct pci_dev *pdev)
 {
u8 gdrst;
+
pci_read_config_byte(pdev, I915_GDRST, &gdrst);
return (gdrst & GRDOM_RESET_ENABLE) == 0;
 }
@@ -1492,6 +1494,7 @@ static int g4x_reset_complete(struct pci_dev *pdev)
 static int g33_do_reset(struct drm_i915_private *dev_priv, unsigned 
engine_mask)
 {
struct pci_dev *pdev = dev_priv->drm.pdev;
+
pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
return wait_for(g4x_reset_complete(pdev), 500);
 }
@@ -1505,7 +1508,7 @@ static int g4x_do_reset(struct drm_i915_private 
*dev_priv, unsigned engine_mask)
  GRDOM_RENDER | GRDOM_RESET_ENABLE);
ret =  wait_for(g4x_reset_complete(pdev), 500);
if (ret)
-   return ret;
+   goto out;
 
/* WaVcpClkGateDisableForMediaReset:ctg,elk */
I915_WRITE(VDECCLK_GATE_D, I915_READ(VDECCLK_GATE_D) | 
VCP_UNIT_CLOCK_GATE_DISABLE);
@@ -1514,16 +1517,14 @@ static int g4x_do_reset(struct drm_i915_private 
*dev_priv, unsigned engine_mask)
pci_write_config_byte(pdev, I915_GDRST,
  GRDOM_MEDIA | GRDOM_RESET_ENABLE);
ret =  wait_for(g4x_reset_complete(pdev), 500);
-   if (ret)
-   return ret;
 
/* WaVcpClkGateDisableForMediaReset:ctg,elk */
I915_WRITE(VDECCLK_GATE_D, I915_READ(VDECCLK_GATE_D) & 
~VCP_UNIT_CLOCK_GATE_DISABLE);
POSTING_READ(VDECCLK_GATE_D);
 
+out:
pci_write_config_byte(pdev, I915_GDRST, 0);
-
-   return 0;
+   return ret;
 }
 
 static int ironlake_do_reset(struct drm_i915_private *dev_priv,
@@ -1531,25 +1532,21 @@ static int ironlake_do_reset(struct drm_i915_private 
*dev_priv,
 {
int ret;
 
-   I915_WRITE(ILK_GDSR,
-  ILK_GRDOM_RENDER | ILK_GRDOM_RESET_ENABLE);
+   I915_WRITE(ILK_GDSR, ILK_GRDOM_RENDER | ILK_GRDOM_RESET_ENABLE);
ret = intel_wait_for_register(dev_priv,
  ILK_GDSR, ILK_GRDOM_RESET_ENABLE, 0,
  500);
if (ret)
-   return ret;
+   goto out;
 
-   I915_WRITE(ILK_GDSR,
-  ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE);
+   I915_WRITE(ILK_GDSR, ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE);
ret = intel_wait_for_register(dev_priv,
  ILK_GDSR, ILK_GRDOM_RESET_ENABLE, 0,
  500);
-   if (ret)
-   return ret;
-
+out:
I915_WRITE(ILK_GDSR, 0);
-
-   return 0;
+   POSTING_READ(ILK_GDSR);
+   return ret;
 }
 
 /* Reset the hardware domains (GENX_GRDOM_*) specified by mask */
@@ -1758,8 +1755,11 @@ static reset_func intel_get_gpu_reset(struct 
drm_i915_private *dev_priv)
 int intel_gpu_reset(struct drm_i915_private *dev_priv, unsigned engine_mask)
 {
reset_func reset;
+   int retry;
int ret;
 
+   might_sleep();
+
reset = intel_get_gpu_reset(dev_priv);
if (reset == NULL)
return -ENODEV;
@@ -1768,7 +1768,13 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv, 
unsigned engine_mask)
 * request may be dropped and never completes (causing -EIO).
 */
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
-   ret = reset(dev_priv, engine_mask);
+   for (retry = 0; retry < 3; retry++) {
+   ret = reset(dev_priv, engine_mask);
+   if (ret != -ETIMEDOUT)
+   break;
+
+   cond_resched();
+   }
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
 

[Intel-gfx] [PATCH i-g-t 02/13] Make conditions on HAVE_UDEV consistent

[Arkadiusz Hiler]

We have a lot of `#ifdef HAVE_UDEV` and ` #if HAVE_UDEV` all over the
place, but ifdef and if have a slightly different semantics.

Let make it consistent by using #ifdefs only.

Signed-off-by: Arkadiusz Hiler 
---
 lib/igt_aux.c  | 2 +-
 tests/testdisplay_hotplug.c| 2 +-
 tools/intel_l3_parity.c| 2 +-
 tools/intel_l3_parity.h| 2 +-
 tools/intel_l3_udev_listener.c | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 1222806..2ec6b78 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -388,7 +388,7 @@ void igt_stop_shrink_helper(void)
igt_stop_helper(&shrink_helper);
 }
 
-#if HAVE_UDEV
+#ifdef HAVE_UDEV
 #include 
 
 static struct igt_helper_process hang_detector;
diff --git a/tests/testdisplay_hotplug.c b/tests/testdisplay_hotplug.c
index 3b900ca..cf15511 100644
--- a/tests/testdisplay_hotplug.c
+++ b/tests/testdisplay_hotplug.c
@@ -34,7 +34,7 @@
 #endif
 
 
-#if HAVE_UDEV
+#ifdef HAVE_UDEV
 #include 
 static struct udev_monitor *uevent_monitor;
 static struct udev *udev;
diff --git a/tools/intel_l3_parity.c b/tools/intel_l3_parity.c
index dce7f32..eb00c50 100644
--- a/tools/intel_l3_parity.c
+++ b/tools/intel_l3_parity.c
@@ -42,7 +42,7 @@
 #ifdef HAVE_CONFIG_H
 #include "config.h"
 #endif
-#if HAVE_UDEV
+#ifdef HAVE_UDEV
 #include 
 #include 
 #endif
diff --git a/tools/intel_l3_parity.h b/tools/intel_l3_parity.h
index 65697c4..759c4f4 100644
--- a/tools/intel_l3_parity.h
+++ b/tools/intel_l3_parity.h
@@ -18,7 +18,7 @@ struct l3_location {
uint8_t subbank;
 };
 
-#if HAVE_UDEV
+#ifdef HAVE_UDEV
 int l3_uevent_setup(struct l3_parity *par);
 /* Listens (blocks) for an l3 parity event. Returns the location of the error. 
*/
 int l3_listen(struct l3_parity *par, bool daemon, struct l3_location *loc);
diff --git a/tools/intel_l3_udev_listener.c b/tools/intel_l3_udev_listener.c
index 0b94c1c..270bfff 100644
--- a/tools/intel_l3_udev_listener.c
+++ b/tools/intel_l3_udev_listener.c
@@ -25,7 +25,7 @@
 #include "config.h"
 #endif
 
-#if HAVE_UDEV
+#ifdef HAVE_UDEV
 #include 
 #ifndef _GNU_SOURCE
 #define _GNU_SOURCE
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 01/13] tests/drm_import_export: Include {i915_, }drm.h properly

[Arkadiusz Hiler]

Using `libdrm/` impairs compatibility with android build system and
pkg-config manages -I for us on regular distros.

Signed-off-by: Arkadiusz Hiler 
---
 tests/drm_import_export.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/drm_import_export.c b/tests/drm_import_export.c
index cfe5f6d..f1234bd 100644
--- a/tests/drm_import_export.c
+++ b/tests/drm_import_export.c
@@ -32,8 +32,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t v2 00/13] Fix IGTs for Android

[Arkadiusz Hiler]

IGTs are broken for Android since the introduction of dependency on procps. Over
time other incompatibilities built up.

I took the liberty to fix some of the issues, workaround couple of others and
blacklist heavily incompatible tools/tests.

It builds on (almost) vanilla AOSP now.

Github: 
Howto:  
now including docker exmaple / script for your convenience

DEP1:  - just builds Google's one
DEP2: 

We should include a note on Android compatibility in the README and do
"continuous compilation" of the patches as they arrive on the mailing list,
otherwise this **will get broken again soon**.

This is long as it is, but not complete yet.

Here are some of more obvious TODOs:
 * introduce something like IGT_HAS_CAIRO define for convenience
 * revise igt_kms dependency on cairo and enable everything what is independent
 * revise kms tests and do the above
 * review all things that are disabled on Android and try to enable them
 * do something less ugly with config.h generation on Android

v2: couple of suggested fixed + everything that was not compatible since last
patch

Cc: Petri Latvala 
Cc: Antonio Argenziano 
Cc: Vinay Belgaumkar 
Cc: Chris Wilson 
Cc: Robert Foss 


Arkadiusz Hiler (13):
  tests/drm_import_export: Include {i915_,}drm.h properly
  Make conditions on HAVE_UDEV consistent
  lib/igt_aux: Include unistd.h for gettid() on Android
  lib/igt_aux: Make procps optional
  chamelium: Fix build issues on Android
  tools/Android.mk: Add guc_logger and l3_parity skip list
  tests/Android.mk: Add perf to skip list
  Android.mk: Fix libkmod use
  Android.mk: Filter out *.h from src files
  Android.mk: Use drm stubs
  tools/Android.mk: Fix zlib inclusion
  tests/gem_exec_nop: Disable headless subtest on cairoless Android
  tests/gem_exec_nop: Rename signal() to fence_signal()

 benchmarks/Android.mk  |  5 -
 configure.ac   |  6 +-
 demos/Android.mk   |  3 ++-
 lib/Android.mk |  7 ---
 lib/Makefile.am|  7 +++
 lib/Makefile.sources   |  7 ---
 lib/igt.h  |  2 ++
 lib/igt_aux.c  | 37 +
 lib/igt_aux.h  |  5 +
 lib/igt_chamelium.h|  3 +++
 lib/igt_kmod.h |  4 
 lib/tests/Android.mk   |  4 ++--
 tests/Android.mk   |  9 +
 tests/Makefile.am  |  6 ++
 tests/Makefile.sources |  6 --
 tests/drm_import_export.c  |  4 ++--
 tests/gem_exec_nop.c   | 14 +-
 tests/testdisplay_hotplug.c|  2 +-
 tools/Android.mk   | 14 +-
 tools/intel_l3_parity.c|  2 +-
 tools/intel_l3_parity.h|  2 +-
 tools/intel_l3_udev_listener.c |  2 +-
 22 files changed, 106 insertions(+), 45 deletions(-)

-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 04/13] lib/igt_aux: Make procps optional

[Arkadiusz Hiler]

Android does not have procps and it's not easy to compile it as a
dependency.

We can provide alternative, "naive" implementation that just shells out
to external commands (i.e. pkill and lsof) in case we do not have the
library.

v2: have separate functions for naive impls (J. Nikula)

Cc: Jani Nikula 
Signed-off-by: Arkadiusz Hiler 
---
 configure.ac  |  6 +-
 lib/igt_aux.c | 35 ---
 2 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 5342e33..72cb32f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -123,7 +123,11 @@ AC_SUBST(ASSEMBLER_WARN_CFLAGS)
 PKG_CHECK_MODULES(DRM, [libdrm])
 PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
 PKG_CHECK_MODULES(KMOD, [libkmod])
-PKG_CHECK_MODULES(PROCPS, [libprocps])
+PKG_CHECK_MODULES(PROCPS, [libprocps], [procps=yes], [procps=no])
+AM_CONDITIONAL(HAVE_PROCPS, [test "x$procps" = xyes])
+if test x"$procps" = xyes; then
+   AC_DEFINE(HAVE_PROCPS,1,[Enable process managment without shelling out])
+fi
 PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
[have_valgrind=no])
 
 if test x$have_valgrind = xyes; then
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 2ec6b78..f76e55d 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -50,9 +50,7 @@
 #include 
 #include 
 #include 
-
-#include 
-
+#include 
 #include "drmtest.h"
 #include "i915_drm.h"
 #include "intel_chipset.h"
@@ -71,6 +69,10 @@
 #include/* for dirname() */
 #endif
 
+#ifdef HAVE_PROCPS
+#include 
+#endif
+
 /**
  * SECTION:igt_aux
  * @short_description: Auxiliary libraries and support functions
@@ -1293,6 +1295,7 @@ void igt_set_module_param_int(const char *name, int val)
  * This function sends the signal @sig for a process found in process table
  * with name @comm.
  */
+#ifdef HAVE_PROCPS
 int igt_terminate_process(int sig, const char *comm)
 {
PROCTAB *proc;
@@ -1317,7 +1320,19 @@ int igt_terminate_process(int sig, const char *comm)
closeproc(proc);
return err;
 }
+#else
+#warning "No procps, using naive implementation of igt_terminate_process"
 
+int igt_terminate_process(int sig, const char *comm)
+{
+   char pkill_cmd[NAME_MAX];
+
+   snprintf(pkill_cmd, sizeof(pkill_cmd), "pkill -x -%d %s", sig, comm);
+   return system(pkill_cmd);
+}
+#endif
+
+#ifdef HAVE_PROCPS
 struct pinfo {
pid_t pid;
const char *comm;
@@ -1499,6 +1514,7 @@ __igt_lsof(const char *dir)
 
closeproc(proc);
 }
+#endif
 
 /**
  * igt_lsof: Lists information about files opened by processes.
@@ -1507,6 +1523,7 @@ __igt_lsof(const char *dir)
  * This function mimics (a restrictive form of) lsof(8), but also shows
  * information about opened fds.
  */
+#ifdef HAVE_PROCPS
 void
 igt_lsof(const char *dpath)
 {
@@ -1531,6 +1548,18 @@ igt_lsof(const char *dpath)
 
free(sanitized);
 }
+#else
+#warning "No procps, using naive implementation of igt_lsof"
+
+void
+igt_lsof(const char *dpath)
+{
+   char lsof_cmd[NAME_MAX];
+
+   snprintf(lsof_cmd, sizeof(lsof_cmd), "lsof +d %s", dpath);
+   system(lsof_cmd);
+}
+#endif
 
 static struct igt_siglatency {
timer_t timer;
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 05/13] chamelium: Fix build issues on Android

[Arkadiusz Hiler]

Makefile.sources are included 1:1 in Android.mk files, and are not
parsed by automake. And yet those had some automake conditional logic.
Moving it to .am file is enough for now.

Also igt_chamelium.h included config.h without proper "HAVE_CONFIG_H"
guard, and the file itself was included unconditionally.

Signed-off-by: Arkadiusz Hiler 
---
 lib/Makefile.am| 7 +++
 lib/Makefile.sources   | 7 ---
 lib/igt.h  | 2 ++
 lib/igt_chamelium.h| 3 +++
 tests/Makefile.am  | 6 ++
 tests/Makefile.sources | 6 --
 6 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/lib/Makefile.am b/lib/Makefile.am
index c0ddf29..91e72c4 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -22,6 +22,13 @@ if !HAVE_LIBDRM_INTEL
 stubs/drm/intel_bufmgr.h
 endif
 
+if HAVE_CHAMELIUM
+lib_source_list += \
+   igt_chamelium.h \
+   igt_chamelium.c \
+   $(NULL)
+endif
+
 AM_CPPFLAGS = -I$(top_srcdir)
 AM_CFLAGS = \
$(CWARNFLAGS) \
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 6348487..53fdb54 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -85,13 +85,6 @@ lib_source_list =\
igt_kmod.h  \
$(NULL)
 
-if HAVE_CHAMELIUM
-lib_source_list += \
-   igt_chamelium.h \
-   igt_chamelium.c \
-   $(NULL)
-endif
-
 .PHONY: version.h.tmp
 
 # leaving a space here to work around automake's conditionals
diff --git a/lib/igt.h b/lib/igt.h
index a97923e..a069deb 100644
--- a/lib/igt.h
+++ b/lib/igt.h
@@ -38,7 +38,9 @@
 #include "igt_kms.h"
 #include "igt_pm.h"
 #include "igt_stats.h"
+#ifdef HAVE_CHAMELIUM
 #include "igt_chamelium.h"
+#endif
 #include "instdone.h"
 #include "intel_batchbuffer.h"
 #include "intel_chipset.h"
diff --git a/lib/igt_chamelium.h b/lib/igt_chamelium.h
index f421d83..15f6024 100644
--- a/lib/igt_chamelium.h
+++ b/lib/igt_chamelium.h
@@ -26,7 +26,10 @@
 #ifndef IGT_CHAMELIUM_H
 #define IGT_CHAMELIUM_H
 
+#ifdef HAVE_CONFIG_H
 #include "config.h"
+#endif
+
 #include "igt.h"
 #include 
 
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 05681d5..61c7a15 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -12,6 +12,12 @@ if HAVE_LIBDRM_VC4
 TESTS_progs_M += $(VC4_TESTS_M)
 endif
 
+if HAVE_CHAMELIUM
+TESTS_progs_M += \
+   chamelium \
+   $(NULL)
+endif
+
 if BUILD_TESTS
 test-list.txt: Makefile.sources
@echo TESTLIST > $@
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 9553e4d..df1fee5 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -154,12 +154,6 @@ TESTS_progs_M = \
meta_test \
$(NULL)
 
-if HAVE_CHAMELIUM
-TESTS_progs_M += \
-   chamelium \
-   $(NULL)
-endif
-
 TESTS_progs_XM = \
 gem_concurrent_all \
 $(NULL)
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 03/13] lib/igt_aux: Include unistd.h for gettid() on Android

[Arkadiusz Hiler]

We define gettid() using syscall() because glibc does not provide a
wrapper.

Android's bionic got the syscall covered though.

Signed-off-by: Arkadiusz Hiler 
---
 lib/igt_aux.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index e62858e..54b9716 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -43,7 +43,12 @@ extern int num_trash_bos;
 #define NSEC_PER_SEC (1000*USEC_PER_SEC)
 
 /* signal interrupt helpers */
+#ifdef ANDROID
+#include  /* on Android bionic has this implemented */
+#else
 #define gettid() syscall(__NR_gettid)
+#endif
+
 #define sigev_notify_thread_id _sigev_un._tid
 
 /* auxialiary igt helpers from igt_aux.c */
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 09/13] Android.mk: Filter out *.h from src files

[Arkadiusz Hiler]

Newer Android's build system complains about unused files if we leave
those there.

Signed-off-by: Arkadiusz Hiler 
---
 lib/Android.mk   | 2 +-
 tools/Android.mk | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/Android.mk b/lib/Android.mk
index 0596e4a..003ade5 100644
--- a/lib/Android.mk
+++ b/lib/Android.mk
@@ -45,7 +45,7 @@ skip_lib_list := \
 -DANDROID_HAS_CAIRO=0
 endif
 
-LOCAL_SRC_FILES := $(filter-out $(skip_lib_list),$(lib_source_list))
+LOCAL_SRC_FILES := $(filter-out %.h $(skip_lib_list),$(lib_source_list))
 
 include $(BUILD_STATIC_LIBRARY)
 
diff --git a/tools/Android.mk b/tools/Android.mk
index a8e649b..0bad29c 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -12,7 +12,7 @@ define add_tool
 ifeq ($($(1)_SOURCES),)
 LOCAL_SRC_FILES := $1.c
 else
-LOCAL_SRC_FILES := $($(1)_SOURCES)
+LOCAL_SRC_FILES := $(filter-out %.h,$($(1)_SOURCES))
 endif
 
 LOCAL_CFLAGS += -DHAVE_TERMIOS_H
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 08/13] Android.mk: Fix libkmod use

[Arkadiusz Hiler]

On Android libkmod.h is nested under libkmod directory, so we should
include appropriately.

Also we need to link with it.

Signed-off-by: Arkadiusz Hiler 
---
 benchmarks/Android.mk | 2 ++
 lib/Android.mk| 1 +
 lib/igt_kmod.h| 4 
 tests/Android.mk  | 4 ++--
 tools/Android.mk  | 2 ++
 5 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/benchmarks/Android.mk b/benchmarks/Android.mk
index c0fa09f..faa73b7 100644
--- a/benchmarks/Android.mk
+++ b/benchmarks/Android.mk
@@ -18,6 +18,7 @@ define add_benchmark
 LOCAL_CFLAGS += -Wno-error=return-type
 # Excessive complaining for established cases. Rely on the Linux version 
warnings.
 LOCAL_CFLAGS += -Wno-sign-compare
+LOCAL_LDFLAGS += -lkmod
 
 LOCAL_MODULE := $1_benchmark
 LOCAL_MODULE_TAGS := optional
@@ -26,6 +27,7 @@ define add_benchmark
 LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
 
 LOCAL_SHARED_LIBRARIES := libpciaccess  \
+  libkmod   \
   libdrm\
   libdrm_intel
 
diff --git a/lib/Android.mk b/lib/Android.mk
index eb72f84..0596e4a 100644
--- a/lib/Android.mk
+++ b/lib/Android.mk
@@ -29,6 +29,7 @@ LOCAL_CFLAGS += -std=gnu99 -UNDEBUG
 LOCAL_MODULE:= libintel_gpu_tools
 
 LOCAL_SHARED_LIBRARIES := libpciaccess  \
+ libkmod   \
  libdrm\
  libdrm_intel
 
diff --git a/lib/igt_kmod.h b/lib/igt_kmod.h
index fd307a4..6a7584f 100644
--- a/lib/igt_kmod.h
+++ b/lib/igt_kmod.h
@@ -24,7 +24,11 @@
 #ifndef IGT_KMOD_H
 #define IGT_KMOD_H
 
+#ifdef ANDROID
+#include 
+#else
 #include 
+#endif
 
 #include "igt_aux.h"
 
diff --git a/tests/Android.mk b/tests/Android.mk
index c67ddbd..b664dff 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -19,7 +19,7 @@ define add_test
 
 LOCAL_MODULE_TAGS := optional
 # ask linker to define a specific symbol; we use this to identify IGT tests
-LOCAL_LDFLAGS := -Wl,--defsym=$2=0
+LOCAL_LDFLAGS := -Wl,--defsym=$2=0 -lkmod
 LOCAL_MODULE_PATH := $(TARGET_OUT_VENDOR)/intel/validation/core/igt
 
 include $(BUILD_EXECUTABLE)
@@ -45,7 +45,7 @@ IGT_LOCAL_C_INCLUDES += 
${ANDROID_BUILD_TOP}/external/PRIVATE/drm/include/drm
 
 # set local libraries
 IGT_LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
-IGT_LOCAL_SHARED_LIBRARIES := libpciaccess libdrm libdrm_intel
+IGT_LOCAL_SHARED_LIBRARIES := libpciaccess libkmod libdrm libdrm_intel
 
 # handle cairo requirements if it is enabled
 ifeq ("${ANDROID_HAS_CAIRO}", "1")
diff --git a/tools/Android.mk b/tools/Android.mk
index 0602e8c..a8e649b 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -23,6 +23,7 @@ define add_tool
 LOCAL_CFLAGS += -Wno-error=return-type
 # Excessive complaining for established cases. Rely on the Linux version 
warnings.
 LOCAL_CFLAGS += -Wno-sign-compare
+LOCAL_LDFLAGS += -lkmod
 ifeq ($($(1)_LDFLAGS),)
 else
 LOCAL_LDFLAGS += $($(1)_LDFLAGS)
@@ -38,6 +39,7 @@ define add_tool
 LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
 
 LOCAL_SHARED_LIBRARIES := libpciaccess  \
+  libkmod   \
   libdrm\
   libdrm_intel
 
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 11/13] tools/Android.mk: Fix zlib inclusion

[Arkadiusz Hiler]

Add dependency on libz instead of doing path magic.

Signed-off-by: Arkadiusz Hiler 
---
 tools/Android.mk | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/Android.mk b/tools/Android.mk
index 5653572..96075c9 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -29,9 +29,8 @@ define add_tool
 LOCAL_LDFLAGS += $($(1)_LDFLAGS)
 endif
 
-LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib
-LOCAL_C_INCLUDES += $(LOCAL_PATH)/../lib/stubs/drm/
-LOCAL_C_INCLUDES += ${ANDROID_BUILD_TOP}/external/zlib
+LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib \
+   $(LOCAL_PATH)/../lib/stubs/drm/
 
 LOCAL_MODULE := $1_tool
 LOCAL_MODULE_TAGS := optional
@@ -41,7 +40,8 @@ define add_tool
 LOCAL_SHARED_LIBRARIES := libpciaccess  \
   libkmod   \
   libdrm\
-  libdrm_intel
+  libdrm_intel \
+  libz
 
 # Tools dir on host
 LOCAL_MODULE_PATH := $(TARGET_OUT_VENDOR)/$(LOCAL_TOOLS_DIR)
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 06/13] tools/Android.mk: Add guc_logger and l3_parity skip list

[Arkadiusz Hiler]

Those tools does not build on Android due to "Linux-only" dependencies.

Let's blacklist them for now.

Signed-off-by: Arkadiusz Hiler 
---
 tools/Android.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/Android.mk b/tools/Android.mk
index 6cdedeb..0602e8c 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -59,6 +59,8 @@ bin_PROGRAMS := $(tools_prog_lists)
 
 skip_tools_list := \
 intel_framebuffer_dump \
+intel_guc_logger \
+intel_l3_parity \
 intel_reg_dumper \
 intel_vga_read \
 intel_vga_write
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 10/13] Android.mk: Use drm stubs

[Arkadiusz Hiler]

Use drm stubs that sit under lib/stubs.

Also drop strange, nonexistent additions to LOCAL_C_INCLUDES.

Signed-off-by: Arkadiusz Hiler 
---
 benchmarks/Android.mk | 3 ++-
 demos/Android.mk  | 3 ++-
 lib/Android.mk| 4 ++--
 lib/tests/Android.mk  | 4 ++--
 tests/Android.mk  | 4 ++--
 tools/Android.mk  | 2 +-
 6 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/benchmarks/Android.mk b/benchmarks/Android.mk
index faa73b7..4ea275c 100644
--- a/benchmarks/Android.mk
+++ b/benchmarks/Android.mk
@@ -10,7 +10,8 @@ define add_benchmark
 
 LOCAL_SRC_FILES := $1.c
 
-LOCAL_C_INCLUDES = ${IGT_LOCAL_C_INCLUDES}
+LOCAL_C_INCLUDES = ${IGT_LOCAL_C_INCLUDES} \
+   $(LOCAL_PATH)/../lib/stubs/drm/
 LOCAL_CFLAGS += -DHAVE_STRUCT_SYSINFO_TOTALRAM
 LOCAL_CFLAGS += -DANDROID -UNDEBUG -include "check-ndebug.h"
 LOCAL_CFLAGS += -std=gnu99
diff --git a/demos/Android.mk b/demos/Android.mk
index 90d8b37..1f50fdc 100644
--- a/demos/Android.mk
+++ b/demos/Android.mk
@@ -16,7 +16,8 @@ LOCAL_CFLAGS += -std=gnu99
 # Excessive complaining for established cases. Rely on the Linux version 
warnings.
 LOCAL_CFLAGS += -Wno-sign-compare
 
-LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib
+LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib \
+   $(LOCAL_PATH)/../lib/stubs/drm/
 
 LOCAL_MODULE := intel_sprite_on
 
diff --git a/lib/Android.mk b/lib/Android.mk
index 003ade5..31f88be 100644
--- a/lib/Android.mk
+++ b/lib/Android.mk
@@ -17,8 +17,8 @@ LOCAL_GENERATED_SOURCES :=   \
$(IGT_LIB_PATH)/version.h  \
$(GPU_TOOLS_PATH)/config.h
 
-LOCAL_C_INCLUDES +=  \
-   $(LOCAL_PATH)/..
+LOCAL_C_INCLUDES += $(LOCAL_PATH)/.. \
+$(LOCAL_PATH)/stubs/drm/
 
 LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)
 
diff --git a/lib/tests/Android.mk b/lib/tests/Android.mk
index 026f17f..bbbd4d8 100644
--- a/lib/tests/Android.mk
+++ b/lib/tests/Android.mk
@@ -30,8 +30,8 @@ IGT_LOCAL_CFLAGS += -std=gnu99
 IGT_LOCAL_CFLAGS += -Wno-error=return-type
 
 # set local includes
-IGT_LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib
-IGT_LOCAL_C_INCLUDES += ${ANDROID_BUILD_TOP}/external/PRIVATE/drm/include/drm
+IGT_LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib \
+   $(LOCAL_PATH)/../lib/stubs/drm/
 
 # set local libraries
 IGT_LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
diff --git a/tests/Android.mk b/tests/Android.mk
index b664dff..c6e966f 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -40,8 +40,8 @@ IGT_LOCAL_CFLAGS += -Wno-error=return-type
 IGT_LOCAL_CFLAGS += -Wno-sign-compare
 
 # set local includes
-IGT_LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib
-IGT_LOCAL_C_INCLUDES += ${ANDROID_BUILD_TOP}/external/PRIVATE/drm/include/drm
+IGT_LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib \
+   $(LOCAL_PATH)/../lib/stubs/drm/
 
 # set local libraries
 IGT_LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
diff --git a/tools/Android.mk b/tools/Android.mk
index 0bad29c..5653572 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -30,7 +30,7 @@ define add_tool
 endif
 
 LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib
-LOCAL_C_INCLUDES += ${ANDROID_BUILD_TOP}/external/PRIVATE/drm/include/drm
+LOCAL_C_INCLUDES += $(LOCAL_PATH)/../lib/stubs/drm/
 LOCAL_C_INCLUDES += ${ANDROID_BUILD_TOP}/external/zlib
 
 LOCAL_MODULE := $1_tool
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 07/13] tests/Android.mk: Add perf to skip list

[Arkadiusz Hiler]

It does not build on Android with top libdrm.

Temporary hax.

Signed-off-by: Arkadiusz Hiler 
---
 tests/Android.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/Android.mk b/tests/Android.mk
index 3186a2a..c67ddbd 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -59,6 +59,7 @@ else
 pm_lpsp \
drm_read \
gem_exec_blt \
+   perf \
prime_mmap_kms
 
 # All kms tests depend on cairo
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 12/13] tests/gem_exec_nop: Disable headless subtest on cairoless Android

[Arkadiusz Hiler]

Currently whole igt_kms.c is disabled while compiling on Android without
cairo, so this tests does not compile.

There should be cleaner a way to disable only cairo dependant parts
which should allow us to enable at least some of the KMS tests, but
that's a bigger rework for another time.

v2: simplified #ifs on CAIRO/ANDROID (P. Latvala)

Cc: Petri Latvala 
Signed-off-by: Arkadiusz Hiler 
---
 tests/gem_exec_nop.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tests/gem_exec_nop.c b/tests/gem_exec_nop.c
index 440e357..d96f068 100644
--- a/tests/gem_exec_nop.c
+++ b/tests/gem_exec_nop.c
@@ -139,6 +139,7 @@ stable_nop_on_ring(int fd, uint32_t handle, unsigned int 
engine,
return n;
 }
 
+#if !defined(ANDROID) || ANDROID_HAS_CAIRO
 #define assert_within_epsilon(x, ref, tolerance) \
 igt_assert_f((x) <= (1.0 + tolerance) * ref && \
  (x) >= (1.0 - tolerance) * ref, \
@@ -183,6 +184,7 @@ static void headless(int fd, uint32_t handle)
/* check that the two execution speeds are roughly the same */
assert_within_epsilon(n_headless, n_display, 0.1f);
 }
+#endif
 
 static bool ignore_engine(int fd, unsigned engine)
 {
@@ -681,8 +683,10 @@ igt_main
igt_subtest("context-sequential")
sequential(device, handle, FORKED | CONTEXT, 150);
 
+#if !defined(ANDROID) || ANDROID_HAS_CAIRO
igt_subtest("headless")
headless(device, handle);
+#endif
 
igt_fixture {
igt_stop_hang_detector();
-- 
2.9.3

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

[Intel-gfx] [PATCH i-g-t 13/13] tests/gem_exec_nop: Rename signal() to fence_signal()

[Arkadiusz Hiler]

Unfortunately  is included through some obscure dependencies
when using bionic, so we have a name clash on signal().

Changed the test function name to fence_signal() to avoid this, but left
the test cases names unchanged.

Signed-off-by: Arkadiusz Hiler 
---
 tests/gem_exec_nop.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/gem_exec_nop.c b/tests/gem_exec_nop.c
index d96f068..d61e120 100644
--- a/tests/gem_exec_nop.c
+++ b/tests/gem_exec_nop.c
@@ -517,9 +517,9 @@ static bool fence_wait(int fence)
return poll(&(struct pollfd){fence, POLLIN}, 1, -1) == 1;
 }
 
-static void signal(int fd, uint32_t handle,
-  unsigned ring_id, const char *ring_name,
-  int timeout)
+static void fence_signal(int fd, uint32_t handle,
+unsigned ring_id, const char *ring_name,
+int timeout)
 {
 #define NFENCES 512
struct drm_i915_gem_execbuffer2 execbuf;
@@ -659,11 +659,11 @@ igt_main
igt_subtest_f("%s", e->name)
single(device, handle, e->exec_id | e->flags, e->name);
igt_subtest_f("signal-%s", e->name)
-   signal(device, handle, e->exec_id | e->flags, e->name, 
5);
+   fence_signal(device, handle, e->exec_id | e->flags, 
e->name, 5);
}
 
igt_subtest("signal-all")
-   signal(device, handle, -1, "all", 150);
+   fence_signal(device, handle, -1, "all", 150);
 
igt_subtest("series")
series(device, handle, 150);
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH i-g-t 13/13] tests/gem_exec_nop: Rename signal() to fence_signal()

[Chris Wilson]

On Tue, May 16, 2017 at 03:25:02PM +0200, Arkadiusz Hiler wrote:
> Unfortunately  is included through some obscure dependencies
> when using bionic, so we have a name clash on signal().
> 
> Changed the test function name to fence_signal() to avoid this, but left
> the test cases names unchanged.

Ack.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 04/13] lib/igt_aux: Make procps optional

[Chris Wilson]

On Tue, May 16, 2017 at 03:24:53PM +0200, Arkadiusz Hiler wrote:
> Android does not have procps and it's not easy to compile it as a
> dependency.
> 
> We can provide alternative, "naive" implementation that just shells out
> to external commands (i.e. pkill and lsof) in case we do not have the
> library.

This patch should carry a health warning: do not mix with kasan. :-p
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 07/13] tests/Android.mk: Add perf to skip list

[Chris Wilson]

On Tue, May 16, 2017 at 03:24:56PM +0200, Arkadiusz Hiler wrote:
> It does not build on Android with top libdrm.

Ah, libdrm strikes back. I was thinking that Android is definitely a
target for the kernel interface so wondered how much work it will be to
fix.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 05/13] chamelium: Fix build issues on Android

[Michal Wajdeczko]

On Tue, May 16, 2017 at 03:24:54PM +0200, Arkadiusz Hiler wrote:
> Makefile.sources are included 1:1 in Android.mk files, and are not
> parsed by automake. And yet those had some automake conditional logic.
> Moving it to .am file is enough for now.

Hmm, all sources shall be listed only in Makefile.sources, which in turn,
shall not have any logic.

> 
> Also igt_chamelium.h included config.h without proper "HAVE_CONFIG_H"
> guard, and the file itself was included unconditionally.
> 
> Signed-off-by: Arkadiusz Hiler 
> ---
>  lib/Makefile.am| 7 +++
>  lib/Makefile.sources   | 7 ---
>  lib/igt.h  | 2 ++
>  lib/igt_chamelium.h| 3 +++
>  tests/Makefile.am  | 6 ++
>  tests/Makefile.sources | 6 --
>  6 files changed, 18 insertions(+), 13 deletions(-)
> 
> diff --git a/lib/Makefile.am b/lib/Makefile.am
> index c0ddf29..91e72c4 100644
> --- a/lib/Makefile.am
> +++ b/lib/Makefile.am
> @@ -22,6 +22,13 @@ if !HAVE_LIBDRM_INTEL
>  stubs/drm/intel_bufmgr.h
>  endif
>  
> +if HAVE_CHAMELIUM
> +lib_source_list +=   \
> + igt_chamelium.h \
> + igt_chamelium.c \
> + $(NULL)
> +endif
> +

Try this:

if HAVE_CHAMELIUM
lib_source_list += $(chamelium_lib_source_list)
endif


>  AM_CPPFLAGS = -I$(top_srcdir)
>  AM_CFLAGS = \
>   $(CWARNFLAGS) \
> diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> index 6348487..53fdb54 100644
> --- a/lib/Makefile.sources
> +++ b/lib/Makefile.sources
> @@ -85,13 +85,6 @@ lib_source_list =  \
>   igt_kmod.h  \
>   $(NULL)
>  
> -if HAVE_CHAMELIUM
> -lib_source_list +=   \
> - igt_chamelium.h \
> - igt_chamelium.c \
> - $(NULL)
> -endif

Try this:

chamelium_lib_source_list +=\
igt_chamelium.h \
igt_chamelium.c \
$(NULL)

> -
>  .PHONY: version.h.tmp
>  
>  # leaving a space here to work around automake's conditionals
> diff --git a/lib/igt.h b/lib/igt.h
> index a97923e..a069deb 100644
> --- a/lib/igt.h
> +++ b/lib/igt.h
> @@ -38,7 +38,9 @@
>  #include "igt_kms.h"
>  #include "igt_pm.h"
>  #include "igt_stats.h"
> +#ifdef HAVE_CHAMELIUM
>  #include "igt_chamelium.h"
> +#endif
>  #include "instdone.h"
>  #include "intel_batchbuffer.h"
>  #include "intel_chipset.h"
> diff --git a/lib/igt_chamelium.h b/lib/igt_chamelium.h
> index f421d83..15f6024 100644
> --- a/lib/igt_chamelium.h
> +++ b/lib/igt_chamelium.h
> @@ -26,7 +26,10 @@
>  #ifndef IGT_CHAMELIUM_H
>  #define IGT_CHAMELIUM_H
>  
> +#ifdef HAVE_CONFIG_H
>  #include "config.h"
> +#endif
> +
>  #include "igt.h"
>  #include 
>  
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index 05681d5..61c7a15 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -12,6 +12,12 @@ if HAVE_LIBDRM_VC4
>  TESTS_progs_M += $(VC4_TESTS_M)
>  endif
>  
> +if HAVE_CHAMELIUM
> +TESTS_progs_M += \
> + chamelium \
> + $(NULL)
> +endif
> +
>  if BUILD_TESTS
>  test-list.txt: Makefile.sources
>   @echo TESTLIST > $@
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 9553e4d..df1fee5 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -154,12 +154,6 @@ TESTS_progs_M = \
>   meta_test \
>   $(NULL)
>  
> -if HAVE_CHAMELIUM
> -TESTS_progs_M += \
> - chamelium \
> - $(NULL)
> -endif
> -

Maybe instead of removing this from .sources, try this:

CHAMELIUM_TESTS_progs_M += \
chamelium \
$(NULL)

and then use it in .am under HAVE_CHAMELIUM 

Michal

>  TESTS_progs_XM = \
>  gem_concurrent_all \
>  $(NULL)
> -- 
> 2.9.3
> 
> ___
> 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] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Try harder to reset the GPU

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Try harder to reset the GPU
URL   : https://patchwork.freedesktop.org/series/24505/
State : success

== Summary ==

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:452s
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:589s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:512s
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:492s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:418s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
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:498s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:474s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:462s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:582s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:463s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:578s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:469s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:502s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:442s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:543s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:409s

1ccfa1579c1dd3e45e4d9d5ef44329f04a77910e drm-tip: 2017y-05m-16d-13h-14m-11s UTC 
integration manifest
82bf9db drm/i915: Reorder media/render reset on g4x

== Logs ==

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

[Intel-gfx] [PULL] drm-misc-next

[Sean Paul]

Hi Dave,
Apologies for the previous early pull request. This one, hopefully, is more
appropriately timed. I've rolled the previous PR into this one, so you might
notice a couple familiar summaries.

As with the previous pull, I've Cc'd all of the summary-line contributors so
they can keep me honest in my summarization.


drm-misc-next-2017-05-16:
UAPI Changes:
- Return -ENODEV instead of -ENXIO when creating cma fb w/o valid gem (Daniel)
- Add aspect ratio and custom scaling propertis to connector state (Maarten)

Cross-subsystem Changes:
- None

Core Changes:
- Add Laurent as bridge reviewer and Andrzej as bridge maintainer (Archit)
- Maintain new STM driver through -misc (Yannick)
- Misc doc improvements (as is tradition) (Daniel)
- Add driver-private objects to atomic state (Dhinakaran)
- Deprecate preclose hook in modern drivers (use postclose) (Daniel)
- Add hwmode to vblank struct. This fixes mode access in irq context and reduced
  a bunch of boilerplate (Daniel)

Driver Changes:
- vc4: Add out-fence support to vc4 V3D rendering (Eric)
- stm: Add stm32f429 display hw and am-480272h3tmqw-t01h panel support (Yannick)
- vc4: Remove 256MB cma limit from vc4 (Eric)
- dw-hdmi: Disable audio when inactive, instead of always enabled (Romain)
- zte: Add support for VGA to the ZTE driver (Shawn)
- i915: Track DP MST bandwidth and check it in atomic_check (Dhinakaran)
- vgem: Enable gem dmabuf import iface to facilitate ion testing (Laura)
- vc4: Add support for Cygnus (new dt compat string + couple bug fixes) (Eric)
- pl111: Add driver for pl111 CLCD display controller (Eric/Tom)
- vgem: Subclass drm_device instead of standalone platform device (Chris)

Cc: Archit Taneja 
Cc: Eric Anholt 
Cc: Yannick Fertre 
Cc: Romain Perier 
Cc: Navare, Manasi D 
Cc: Shawn Guo 
Cc: Dhinakaran Pandiyan 
Cc: Laura Abbott 
Cc: Maarten Lankhorst 
Cc: Tom Cooksey 
Cc: Daniel Vetter 
Cc: Chris Wilson 

Thanks,

Sean


The following changes since commit 8b03d1ed2c43a2ba5ef3381322ee4515b97381bf:

  Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-next 
(2017-05-02 04:46:01 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-05-16

for you to fetch changes up to 9cf8f5802f39d9991158b29033c852bccfc3a4d4:

  drm: add missing declaration to drm_blend.h (2017-05-16 15:09:56 +0200)


UAPI Changes:
- Return -ENODEV instead of -ENXIO when creating cma fb w/o valid gem (Daniel)
- Add aspect ratio and custom scaling propertis to connector state (Maarten)

Cross-subsystem Changes:
- None

Core Changes:
- Add Laurent as bridge reviewer and Andrzej as bridge maintainer (Archit)
- Maintain new STM driver through -misc (Yannick)
- Misc doc improvements (as is tradition) (Daniel)
- Add driver-private objects to atomic state (Dhinakaran)
- Deprecate preclose hook in modern drivers (use postclose) (Daniel)
- Add hwmode to vblank struct. This fixes mode access in irq context and reduced
  a bunch of boilerplate (Daniel)

Driver Changes:
- vc4: Add out-fence support to vc4 V3D rendering (Eric)
- stm: Add stm32f429 display hw and am-480272h3tmqw-t01h panel support (Yannick)
- vc4: Remove 256MB cma limit from vc4 (Eric)
- dw-hdmi: Disable audio when inactive, instead of always enabled (Romain)
- zte: Add support for VGA to the ZTE driver (Shawn)
- i915: Track DP MST bandwidth and check it in atomic_check (Dhinakaran)
- vgem: Enable gem dmabuf import iface to facilitate ion testing (Laura)
- vc4: Add support for Cygnus (new dt compat string + couple bug fixes) (Eric)
- pl111: Add driver for pl111 CLCD display controller (Eric/Tom)
- vgem: Subclass drm_device instead of standalone platform device (Chris)

Cc: Archit Taneja 
Cc: Eric Anholt 
Cc: Yannick Fertre 
Cc: Romain Perier 
Cc: Navare, Manasi D 
Cc: Shawn Guo 
Cc: Dhinakaran Pandiyan 
Cc: Laura Abbott 
Cc: Maarten Lankhorst 
Cc: Tom Cooksey 
Cc: Daniel Vetter 
Cc: Chris Wilson 


Andres Rodriguez (1):
  dma-buf: avoid scheduling on fence status query v2

Archit Taneja (1):
  MAINTAINERS: Update maintainers/reviewers for bridge drivers

Boris Brezillon (1):
  drm/vc4: Add runtime PM support to the HDMI encoder driver

Chris Wilson (4):
  drm/mm: Split up long running selftests with cond_resched()
  drm/vgem: Convert to a struct drm_device subclass
  drm/dp: Read the tx msg state once after checking for an event
  drm/dp: Wait up all outstanding tx waiters

Clint Taylor (1):
  drm/cec: Add CEC over Aux register definitions

Colin Ian King (1):
  drm: fix spelling mistake: "committing"

Daniel Vetter (12):
  drm/doc: Fix missing @ctx documentation
  drm/doc: Interlink color manager docs better
  drm/cma-helper: Return ENOENT for "no such gem obj"
  drm/nouveau: Merge pre/postclose hooks
  drm/tegra: switch to postclose
  drm/exynos: M

Re: [Intel-gfx] [PATCH 11/12] drm/i915/skl: New ddb allocation algorithm

[Maarten Lankhorst]

Op 15-05-17 om 10:34 schreef Mahesh Kumar:
> From: "Kumar, Mahesh" 
>
> This patch implements new DDB allocation algorithm as per HW team
> recommendation. This algo takecare of scenario where we allocate less DDB
> for the planes with lower relative pixel rate, but they require more DDB
> to work.
> It also takes care of enabling same watermark level for each
> plane in crtc, for efficient power saving.
>
> Changes since v1:
>  - Rebase on top of Paulo's patch series
>
> Changes since v2:
>  - Fix the for loop condition to enable WM
>
> Changes since v3:
>  - Fix crash in cursor i-g-t reported by Maarten
>  - Rebase after addressing Paulo's comments
>  - Few other ULT fixes
> Changes since v4:
>  - Rebase on drm-tip
>  - Added separate function to enable WM levels
> Changes since v5:
>  - Fix a crash identified in skl-6770HQ system
My main fear is that we may now add crtc's that were not part of the state 
before, so anything that may change watermarks may cause a pageflip on a 
unrelated crtc to return -EBUSY.
However this only happens during atomic commit and might also happen on 
nonblocking modesets, so it's probably harmless for now.

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

Re: [Intel-gfx] [PATCH v4] drm/i915/guc: capture GuC logs if FW fails to load

[Michal Wajdeczko]

On Mon, May 15, 2017 at 04:47:16PM -0700, Daniele Ceraolo Spurio wrote:
> 
> 
> On 15/05/17 10:41, Michal Wajdeczko wrote:
> > On Mon, May 15, 2017 at 09:35:30AM -0700, Daniele Ceraolo Spurio wrote:
> > > We're currently deleting the GuC logs if the FW fails to load, but those
> > > are still useful to understand why the loading failed. Keeping the
> > > object around allows us to access them after driver load is completed.
> > > 
> > > v2: keep the object around instead of using kernel memory (chris)
> > > don't store the logs in the gpu_error struct (Chris)
> > > add a check on guc_log_level to avoid snapshotting empty logs
> > > 
> > > v3: use separate debugfs for error log (Chris)
> > > 
> > > v4: rebased
> > > 
> > > Reviewed-by: Chris Wilson  (v3)
> > > Cc: Chris Wilson 
> > > Cc: Oscar Mateo 
> > > Cc: Michal Wajdeczko 
> > > Signed-off-by: Daniele Ceraolo Spurio 
> > > ---
> > >  drivers/gpu/drm/i915/i915_debugfs.c  | 35 
> > > ++-
> > >  drivers/gpu/drm/i915/i915_drv.c  |  3 +++
> > >  drivers/gpu/drm/i915/intel_guc_log.c | 17 +
> > >  drivers/gpu/drm/i915/intel_uc.c  |  7 +--
> > >  drivers/gpu/drm/i915/intel_uc.h  |  5 +
> > >  5 files changed, 52 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index bd9abef..d9a5bd8 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2607,27 +2607,35 @@ static int i915_guc_stage_pool(struct seq_file 
> > > *m, void *data)
> > > 
> > >  static int i915_guc_log_dump(struct seq_file *m, void *data)
> > >  {
> > > - struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > > + struct drm_info_node *node = m->private;
> > > + struct drm_i915_private *dev_priv = node_to_i915(node);
> > > + bool dump_err_log = !!node->info_ent->data;
> > >   struct drm_i915_gem_object *obj;
> > > - int i = 0, pg;
> > > + u32 *log;
> > > + int i = 0;
> > > 
> > > - if (!dev_priv->guc.log.vma)
> > > + if (!dump_err_log && dev_priv->guc.log.vma)
> > > + obj = dev_priv->guc.log.vma->obj;
> > > + else if (dump_err_log && dev_priv->guc.err_load_log)
> > > + obj = dev_priv->guc.err_load_log;
> > > + else
> > >   return 0;
> > 
> > Maybe we can move actual printfs into separate generic function that
> > will just take desired obj? It will simplify this function and possibly
> > allow more reuse of that new funcion in the future.
> > 
> 
> The problem here would be that each debugfs function has its own desired
> formatting and might only be interested in a section of an object (e.g.
> i915_dump_lrc_obj), not sure how much we can reuse. I'd prefer to wait for
> an actual use case before splitting it out.
> 
> > We can even try define two separate small functions with names that
> > corresponds to the debugfs entry, to follow all other functions
> > 
> 
> We already have a case where 2 debugfs entries are pointing to the same
> function (i915_gem_gtt and i915_gem_pin_display) and it feels cleaner to me
> compared to having 2 one-liner function just to pick between the different
> objects. If you're ok with it I'd prefer to instead clean up the if
> statement the following way to make the obj selection more evident:
> 
>   if (dump_err_log)
>   obj = dev_priv->guc.log.err_load;
>   else
>   obj = dev_priv->guc.log.vma->obj;
> 
>   if (!obj)
>   return 0;
> 

Ok, we start with this.

> > > 
> > > - obj = dev_priv->guc.log.vma->obj;
> > > - for (pg = 0; pg < obj->base.size / PAGE_SIZE; pg++) {
> > > - u32 *log = kmap_atomic(i915_gem_object_get_page(obj, pg));
> > > -
> > > - for (i = 0; i < PAGE_SIZE / sizeof(u32); i += 4)
> > > - seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
> > > -*(log + i), *(log + i + 1),
> > > -*(log + i + 2), *(log + i + 3));
> > > -
> > > - kunmap_atomic(log);
> > > + log = i915_gem_object_pin_map(obj, I915_MAP_WC);
> > > + if (IS_ERR(log)) {
> > > + DRM_ERROR("Failed to pin guc_log object\n");
> > > + return PTR_ERR(log);
> > >   }
> > > 
> > > + for (i = 0; i < obj->base.size / sizeof(u32); i += 4)
> > > + seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
> > > +*(log + i), *(log + i + 1),
> > > +*(log + i + 2), *(log + i + 3));
> > > +
> > >   seq_putc(m, '\n');
> > > 
> > > + i915_gem_object_unpin_map(obj);
> > > +
> > >   return 0;
> > >  }
> > > 
> > > @@ -4811,6 +4819,7 @@ static int i915_hpd_storm_ctl_open(struct inode 
> > > *inode, struct file *file)
> > >   {"i915_guc_info", i915_guc_info, 0},
> > >   {"i915_guc_load_status", i915_guc_load_status_info, 0},
> > >   {"i915_guc_log_dump", i915_guc_log_dump, 0},
> > > + {"i915_guc_err_load_log_dump", i915_guc_log_dump, 0, (void *)1},
> > >   {"i915_guc_s

Re: [Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

[Puthikorn Voravootivat]

On Mon, May 15, 2017 at 11:21 PM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@intel.com> wrote:

> On Mon, 2017-05-15 at 17:43 -0700, Puthikorn Voravootivat wrote:
> >
> >
> > On Mon, May 15, 2017 at 4:07 PM, Pandiyan, Dhinakaran
> >  wrote:
> > On Fri, 2017-05-12 at 17:31 -0700, Puthikorn Voravootivat
> > wrote:
> > >
> > >
> > >
> > > On Fri, May 12, 2017 at 5:12 PM, Pandiyan, Dhinakaran
> > >  wrote:
> > > On Thu, 2017-05-11 at 16:02 -0700, Puthikorn
> > Voravootivat
> > > wrote:
> > > > Read desired PWM frequency from panel vbt and
> > calculate the
> > > > value for divider in DPCD address 0x724 and 0x728
> > to have
> > > > as many bits as possible for PWM duty cyle for
> > granularity
> > > of
> > > > brightness adjustment while the frequency is still
> > within
> > > 25%
> > > > of the desired frequency.
> > >
> > > I read a few eDP panel data sheets, the PWM
> > frequencies all
> > > start from
> > > ~200Hz. If the VBT chooses this lowest value to
> > allow for more
> > > brightness control, and then this patch lowers the
> > value by
> > > another 25%,
> > > we'll end up below the panel allowed PWM frequency.
> > >
> > > In fact, one of the systems I checked had PWM
> > frequency as
> > > 200Hz in VBT
> > > and the panel datasheet also had PWM frequency range
> > starting
> > > from
> > > 200Hz. Have you considered this case?
> > >
> > > The spec said "A given LCD panel typically has a limited
> > range of
> > > backlight frequency capability.
> > > To limit the programmable frequency range, limitations are
> > placed on
> > > the allowable total divider ratio with the Sink device"
> > >  So I think it should be auto cap to 200Hz in this case.
> > >
> > > -DK
> > > >
> > > > Signed-off-by: Puthikorn Voravootivat
> > 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c |
> > 81
> > > +++
> > > >  1 file changed, 81 insertions(+)
> > > >
> > > > diff --git
> > a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > index 0b48851013cc..6f10a2f1ab76 100644
> > > > ---
> > a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > +++
> > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > @@ -113,12 +113,86 @@
> > > intel_dp_aux_set_dynamic_backlight_percent(struct
> > intel_dp
> > > *intel_dp,
> > > >   }
> > > >  }
> > > >
> > > > +/*
> > > > + * Set PWM Frequency divider to match desired
> > frequency in
> > > vbt.
> > > > + * The PWM Frequency is calculated as 27Mhz / (F
> > x P).
> > > > + * - Where F = PWM Frequency Pre-Divider value
> > programmed
> > > by field 7:0 of the
> > > > + * EDP_BACKLIGHT_FREQ_SET register
> > (DPCD
> > > Address 00728h)
> > > > + * - Where P = 2^Pn, where Pn is the value
> > programmed by
> > > field 4:0 of the
> > > > + * EDP_PWMGEN_BIT_COUNT register
> > (DPCD Address
> > > 00724h)
> > > > + */
> > > > +static void intel_dp_aux_set_pwm_freq(struct
> > > intel_connector *connector)
> > > > +{
> > > > + struct drm_i915_private *dev_priv =
> > > to_i915(connector->base.dev);
> > > > + struct intel_dp *intel_dp =
> > > enc_to_intel_dp(&connector->encoder->base);
> > > > + int freq, fxp, fxp_min, fxp_max, fxp_actual,
> > f = 1;
> > > > + u8 pn, pn_min, pn_max;
> > > > +
> > > > + /* Find desired value of (F x P)
> > > > +  * Note that, if F x P is out of supported
> > range, the
> > > maximum value or
> > > > +  * minimum value will applied automatically.
> > So no
> > > need to check that.
> > > > +  */
> >   

Re: [Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

[Pandiyan, Dhinakaran]

On Tue, 2017-05-16 at 11:07 -0700, Puthikorn Voravootivat wrote:
> 
> 
> On Mon, May 15, 2017 at 11:21 PM, Pandiyan, Dhinakaran
>  wrote:
> On Mon, 2017-05-15 at 17:43 -0700, Puthikorn Voravootivat
> wrote:
> >
> >
> > On Mon, May 15, 2017 at 4:07 PM, Pandiyan, Dhinakaran
> >  wrote:
> > On Fri, 2017-05-12 at 17:31 -0700, Puthikorn
> Voravootivat
> > wrote:
> > >
> > >
> > >
> > > On Fri, May 12, 2017 at 5:12 PM, Pandiyan,
> Dhinakaran
> > >  wrote:
> > > On Thu, 2017-05-11 at 16:02 -0700,
> Puthikorn
> > Voravootivat
> > > wrote:
> > > > Read desired PWM frequency from panel
> vbt and
> > calculate the
> > > > value for divider in DPCD address 0x724
> and 0x728
> > to have
> > > > as many bits as possible for PWM duty
> cyle for
> > granularity
> > > of
> > > > brightness adjustment while the
> frequency is still
> > within
> > > 25%
> > > > of the desired frequency.
> > >
> > > I read a few eDP panel data sheets, the
> PWM
> > frequencies all
> > > start from
> > > ~200Hz. If the VBT chooses this lowest
> value to
> > allow for more
> > > brightness control, and then this patch
> lowers the
> > value by
> > > another 25%,
> > > we'll end up below the panel allowed PWM
> frequency.
> > >
> > > In fact, one of the systems I checked had
> PWM
> > frequency as
> > > 200Hz in VBT
> > > and the panel datasheet also had PWM
> frequency range
> > starting
> > > from
> > > 200Hz. Have you considered this case?
> > >
> > > The spec said "A given LCD panel typically has a
> limited
> > range of
> > > backlight frequency capability.
> > > To limit the programmable frequency range,
> limitations are
> > placed on
> > > the allowable total divider ratio with the Sink
> device"
> > >  So I think it should be auto cap to 200Hz in this
> case.
> > >
> > > -DK
> > > >
> > > > Signed-off-by: Puthikorn Voravootivat
> > 
> > > > ---
> > > >
> drivers/gpu/drm/i915/intel_dp_aux_backlight.c |
> > 81
> > > +++
> > > >  1 file changed, 81 insertions(+)
> > > >
> > > > diff --git
> > a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > >
>  b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > index 0b48851013cc..6f10a2f1ab76 100644
> > > > ---
> > a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > +++
> > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > @@ -113,12 +113,86 @@
> > >
>  intel_dp_aux_set_dynamic_backlight_percent(struct
> > intel_dp
> > > *intel_dp,
> > > >   }
> > > >  }
> > > >
> > > > +/*
> > > > + * Set PWM Frequency divider to match
> desired
> > frequency in
> > > vbt.
> > > > + * The PWM Frequency is calculated as
> 27Mhz / (F
> > x P).
> > > > + * - Where F = PWM Frequency
> Pre-Divider value
> > programmed
> > > by field 7:0 of the
> > > > + * EDP_BACKLIGHT_FREQ_SET
> register
> > (DPCD
> > > Address 00728h)
> > > > + * - Where P = 2^Pn, where Pn is the
> value
> > programmed by
> > > field 4:0 of the
> > > > + * EDP_PWMGEN_BIT_

Re: [Intel-gfx] Call trace on 4.12.0-rc1

[Hans de Goede]

Hi,

On 05/16/2017 09:55 PM, FKr wrote:

Hi,
I'm using 4.12.0-rc1 from https://github.com/jwrdegoede/linux-sunxi and got
the following weird trace yesterday. Previously I've been getting output
similar to https://www.spinics.net/lists/intel-gfx/msg127638.html, some boots
on 4.12.0-rc1  I don't get any trace at all.


This is really weird, we are getting the error while we are trying to
acquire the wakelock ... ? Or do we need some other lock before we can
take the wakelock ?

Any input from one of the Intel developers would be appreciated.

Regards,

Hans




[ 2383.844192] perf: interrupt took too long (2522 > 2500), lowering
kernel.perf_event_max_sample_rate to 79200
[ 2634.863978] [drm:intel_pipe_update_end] *ERROR* Atomic update failure on
pipe A (start=157909 end=157910) time 322 us, min 1073, max 1079, scanline
start 1063, end 1084
[ 2647.881794] perf: interrupt took too long (3193 > 3152), lowering
kernel.perf_event_max_sample_rate to 62400
[ 3297.857921] perf: interrupt took too long (4020 > 3991), lowering
kernel.perf_event_max_sample_rate to 49500
[ 4670.977136] mmc0: Tuning timeout, falling back to fixed sampling clock
[ 4671.436604] mmc0: Tuning timeout, falling back to fixed sampling clock
[ 4680.756302] mmc0: Tuning timeout, falling back to fixed sampling clock
[ 4707.846872] perf: interrupt took too long (5046 > 5025), lowering
kernel.perf_event_max_sample_rate to 39600
[ 4846.672969] RPM wakelock ref not held during HW access
[ 4846.673050] [ cut here ]
[ 4846.673084] WARNING: CPU: 0 PID: 5227 at drivers/gpu/drm/i915/intel_drv.h:
1780 intel_uncore_forcewake_get+0xa0/0xb0
[ 4846.673088] Modules linked in: snd_soc_sst_cht_bsw_nau8824 btusb btintel
bluetooth axp288_fuel_gauge ecdh_generic axp288_charger extcon_axp288
axp288_adc snd_hdmi_lpe_audio snd_intel_sst_acpi extcon_intel_int3496
snd_intel_sst_core extcon_core snd_soc_nau8824 snd_soc_sst_atom_hifi2_platform
snd_soc_core snd_compress snd_soc_sst_match snd_pcm snd_timer kxcjk_1013
industrialio_triggered_buffer intel_cht_int33fe snd soundcore intel_int0002
[ 4846.673201] CPU: 0 PID: 5227 Comm: kworker/0:1 Not tainted 4.12.0-rc1+ #3
[ 4846.673206] Hardware name: MEDION E2228T MD60250/NT16H, BIOS 5.11
02/27/2017
[ 4846.673224] Workqueue: events fuel_gauge_status_monitor [axp288_fuel_gauge]
[ 4846.673235] task: 8800a85be800 task.stack: c9000261
[ 4846.673248] RIP: 0010:intel_uncore_forcewake_get+0xa0/0xb0
[ 4846.673255] RSP: 0018:c90002613aa0 EFLAGS: 00010286
[ 4846.673265] RAX: 002a RBX: 880136cc8000 RCX:
82063e88
[ 4846.673272] RDX:  RSI: 0082 RDI:
0247
[ 4846.673278] RBP: c90002613ac0 R08: 002a R09:
02ac
[ 4846.673284] R10: 0001 R11:  R12:
0007
[ 4846.673289] R13: 0001 R14:  R15:

[ 4846.673298] FS:  () GS:88013fc0() knlGS:

[ 4846.673305] CS:  0010 DS:  ES:  CR0: 80050033
[ 4846.673311] CR2: 0758c709c000 CR3: 02009000 CR4:
001006f0
[ 4846.673317] Call Trace:
[ 4846.673340]  i915_pmic_bus_access_notifier+0x37/0x40
[ 4846.673354]  notifier_call_chain+0x4a/0x70
[ 4846.673368]  __blocking_notifier_call_chain+0x47/0x60
[ 4846.673380]  blocking_notifier_call_chain+0x16/0x20
[ 4846.673393]  iosf_mbi_call_pmic_bus_access_notifier_chain+0x1b/0x20
[ 4846.673406]  baytrail_i2c_acquire+0x64/0x220
[ 4846.673420]  i2c_dw_acquire_lock+0x21/0x50
[ 4846.673431]  i2c_dw_xfer+0xa3/0x4a0
[ 4846.673444]  __i2c_transfer+0x115/0x430
[ 4846.673456]  i2c_transfer+0x5c/0xc0
[ 4846.673469]  regmap_i2c_read+0x6d/0xa0
[ 4846.673482]  _regmap_raw_read+0xda/0x210
[ 4846.673491]  ? _regmap_raw_read+0xda/0x210
[ 4846.673503]  ? __update_load_avg_se.isra.5+0x15b/0x180
[ 4846.673514]  _regmap_bus_read+0x2a/0x60
[ 4846.673524]  _regmap_read+0x6c/0x130
[ 4846.673535]  regmap_read+0x3f/0x60
[ 4846.673549]  fuel_gauge_reg_readb.isra.5+0x40/0x90 [axp288_fuel_gauge]
[ 4846.673564]  fuel_gauge_get_status+0x2d/0x100 [axp288_fuel_gauge]
[ 4846.673577]  ? __schedule+0x2e3/0x840
[ 4846.673590]  fuel_gauge_status_monitor+0x16/0x40 [axp288_fuel_gauge]
[ 4846.673603]  process_one_work+0x1e0/0x420
[ 4846.673616]  worker_thread+0x48/0x3f0
[ 4846.673629]  kthread+0x108/0x140
[ 4846.673640]  ? process_one_work+0x420/0x420
[ 4846.673650]  ? kthread_create_on_node+0x70/0x70
[ 4846.673662]  ret_from_fork+0x2c/0x40
[ 4846.673673] Code: 05 51 79 a1 00 01 e8 84 3c ae ff 0f ff eb a5 80 3d 40 79
a1 00 00 75 a6 48 c7 c7 98 fe e9 81 c6 05 30 79 a1 00 01 e8 64 3c ae ff <0f>
ff eb 8f 66 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
[ 4846.673896] ---[ end trace 4f0b6934a8fd8068 ]---

Regards,
FKr


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

Re: [Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

[Puthikorn Voravootivat]

On Tue, May 16, 2017 at 1:29 PM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@intel.com> wrote:

> On Tue, 2017-05-16 at 11:07 -0700, Puthikorn Voravootivat wrote:
> >
> >
> > On Mon, May 15, 2017 at 11:21 PM, Pandiyan, Dhinakaran
> >  wrote:
> > On Mon, 2017-05-15 at 17:43 -0700, Puthikorn Voravootivat
> > wrote:
> > >
> > >
> > > On Mon, May 15, 2017 at 4:07 PM, Pandiyan, Dhinakaran
> > >  wrote:
> > > On Fri, 2017-05-12 at 17:31 -0700, Puthikorn
> > Voravootivat
> > > wrote:
> > > >
> > > >
> > > >
> > > > On Fri, May 12, 2017 at 5:12 PM, Pandiyan,
> > Dhinakaran
> > > >  wrote:
> > > > On Thu, 2017-05-11 at 16:02 -0700,
> > Puthikorn
> > > Voravootivat
> > > > wrote:
> > > > > Read desired PWM frequency from panel
> > vbt and
> > > calculate the
> > > > > value for divider in DPCD address 0x724
> > and 0x728
> > > to have
> > > > > as many bits as possible for PWM duty
> > cyle for
> > > granularity
> > > > of
> > > > > brightness adjustment while the
> > frequency is still
> > > within
> > > > 25%
> > > > > of the desired frequency.
> > > >
> > > > I read a few eDP panel data sheets, the
> > PWM
> > > frequencies all
> > > > start from
> > > > ~200Hz. If the VBT chooses this lowest
> > value to
> > > allow for more
> > > > brightness control, and then this patch
> > lowers the
> > > value by
> > > > another 25%,
> > > > we'll end up below the panel allowed PWM
> > frequency.
> > > >
> > > > In fact, one of the systems I checked had
> > PWM
> > > frequency as
> > > > 200Hz in VBT
> > > > and the panel datasheet also had PWM
> > frequency range
> > > starting
> > > > from
> > > > 200Hz. Have you considered this case?
> > > >
> > > > The spec said "A given LCD panel typically has a
> > limited
> > > range of
> > > > backlight frequency capability.
> > > > To limit the programmable frequency range,
> > limitations are
> > > placed on
> > > > the allowable total divider ratio with the Sink
> > device"
> > > >  So I think it should be auto cap to 200Hz in this
> > case.
> > > >
> > > > -DK
> > > > >
> > > > > Signed-off-by: Puthikorn Voravootivat
> > > 
> > > > > ---
> > > > >
> > drivers/gpu/drm/i915/intel_dp_aux_backlight.c |
> > > 81
> > > > +++
> > > > >  1 file changed, 81 insertions(+)
> > > > >
> > > > > diff --git
> > > a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > >
> >  b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > > index 0b48851013cc..6f10a2f1ab76 100644
> > > > > ---
> > > a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > > +++
> > > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > > @@ -113,12 +113,86 @@
> > > >
> >  intel_dp_aux_set_dynamic_backlight_percent(struct
> > > intel_dp
> > > > *intel_dp,
> > > > >   }
> > > > >  }
> > > > >
> > > > > +/*
> > > > > + * Set PWM Frequency divider to match
> > desired
> > > frequency in
> > > > vbt.
> > > > > + * The PWM Frequency is calculated as
> > 27Mhz / (F
> > > x P).
> > > > > + * - Where F = PWM Frequency
> > Pre-Divider value
> > > programmed
> > > > by field 7:0 of the
> > > > > + * EDP_BACKLIGHT_FRE

Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob

[Ben Widawsky]

On 17-05-03 17:08:27, Daniel Vetter wrote:

On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:

Updated blob layout (Rob, Daniel, Kristian, xerpi)

Cc: Rob Clark 
Cc: Daniel Stone 
Cc: Kristian H. Kristensen 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/drm_mode_config.c |   7 +++
 drivers/gpu/drm/drm_plane.c   | 119 ++
 include/drm/drm_mode_config.h |   6 ++
 include/uapi/drm/drm_mode.h   |  26 +
 4 files changed, 158 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index d9862259a2a7..6bfbc3839df5 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.gamma_lut_size_property = prop;

+   prop = drm_property_create(dev,
+  DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+  "IN_FORMATS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.modifiers = prop;
+
return 0;
 }

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 286e183891e5..2e89e0e73435 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -62,6 +62,117 @@ static unsigned int drm_num_planes(struct drm_device *dev)
return num;
 }

+struct drm_format_modifier_blob {
+#define FORMAT_BLOB_CURRENT 1
+   /* Version of this blob format */
+   u32 version;
+
+   /* Flags */
+   u32 flags;
+
+   /* Number of fourcc formats supported */
+   u32 count_formats;
+
+   /* Where in this blob the formats exist (in bytes) */
+   u32 formats_offset;
+
+   /* Number of drm_format_modifiers */
+   u32 count_modifiers;
+
+   /* Where in this blob the modifiers exist (in bytes) */
+   u32 modifiers_offset;
+
+   /* u32 formats[] */
+   /* struct drm_format_modifier modifiers[] */
+} __packed;


The struct should be in the uapi header. Otherwise it won't show up in
libdrm headers when following the proper process.
-Daniel



I don't agree that blobs are ever really part of the API, but it doesn't hurt to
move it... in other words, done.


+
+static inline u32 *
+formats_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (u32 *)(((char *)blob) + blob->formats_offset);
+}
+
+static inline struct drm_format_modifier *
+modifiers_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (struct drm_format_modifier *)(((char *)blob) + 
blob->modifiers_offset);
+}
+
+static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
*plane,
+const struct drm_plane_funcs *funcs,
+const uint32_t *formats, unsigned int 
format_count,
+const uint64_t *format_modifiers)
+{
+   const struct drm_mode_config *config = &dev->mode_config;
+   const uint64_t *temp_modifiers = format_modifiers;
+   unsigned int format_modifier_count = 0;
+   struct drm_property_blob *blob = NULL;
+   struct drm_format_modifier *mod;
+   size_t blob_size = 0, formats_size, modifiers_size;
+   struct drm_format_modifier_blob *blob_data;
+   int i, j, ret = 0;
+
+   if (format_modifiers)
+   while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
+   format_modifier_count++;
+
+   formats_size = sizeof(__u32) * format_count;
+   if (WARN_ON(!formats_size)) {
+   /* 0 formats are never expected */
+   return 0;
+   }
+
+   modifiers_size =
+   sizeof(struct drm_format_modifier) * format_modifier_count;
+
+   blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
+   blob_size += ALIGN(formats_size, 8);
+   blob_size += modifiers_size;
+
+   blob = drm_property_create_blob(dev, blob_size, NULL);
+   if (IS_ERR(blob))
+   return -1;
+
+   blob_data = (struct drm_format_modifier_blob *)blob->data;
+   blob_data->version = FORMAT_BLOB_CURRENT;
+   blob_data->count_formats = format_count;
+   blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
+   blob_data->count_modifiers = format_modifier_count;
+
+   /* Modifiers offset is a pointer to a struct with a 64 bit field so it
+* should be naturally aligned to 8B.
+*/
+   blob_data->modifiers_offset =
+   ALIGN(blob_data->formats_offset + formats_size, 8);
+
+   memcpy(formats_ptr(blob_data), formats, formats_size);
+
+   /* If we can't determine support, just bail */
+   if (!funcs->format_mod_supported)
+   goto done;
+
+   mod = modifiers_ptr(blob_data);
+   for (i = 0; i < format_modifier_count; i++) {
+   for (j = 0; j < format_count; j++) {
+  

Re: [Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

[Pandiyan, Dhinakaran]

On Tue, 2017-05-16 at 13:56 -0700, Puthikorn Voravootivat wrote:
> 
> 
> On Tue, May 16, 2017 at 1:29 PM, Pandiyan, Dhinakaran
>  wrote:
> On Tue, 2017-05-16 at 11:07 -0700, Puthikorn Voravootivat
> wrote:
> >
> >
> > On Mon, May 15, 2017 at 11:21 PM, Pandiyan, Dhinakaran
> >  wrote:
> > On Mon, 2017-05-15 at 17:43 -0700, Puthikorn
> Voravootivat
> > wrote:
> > >
> > >
> > > On Mon, May 15, 2017 at 4:07 PM, Pandiyan,
> Dhinakaran
> > >  wrote:
> > > On Fri, 2017-05-12 at 17:31 -0700,
> Puthikorn
> > Voravootivat
> > > wrote:
> > > >
> > > >
> > > >
> > > > On Fri, May 12, 2017 at 5:12 PM,
> Pandiyan,
> > Dhinakaran
> > > >  wrote:
> > > > On Thu, 2017-05-11 at 16:02
> -0700,
> > Puthikorn
> > > Voravootivat
> > > > wrote:
> > > > > Read desired PWM frequency
> from panel
> > vbt and
> > > calculate the
> > > > > value for divider in DPCD
> address 0x724
> > and 0x728
> > > to have
> > > > > as many bits as possible for
> PWM duty
> > cyle for
> > > granularity
> > > > of
> > > > > brightness adjustment while
> the
> > frequency is still
> > > within
> > > > 25%
> > > > > of the desired frequency.
> > > >
> > > > I read a few eDP panel data
> sheets, the
> > PWM
> > > frequencies all
> > > > start from
> > > > ~200Hz. If the VBT chooses this
> lowest
> > value to
> > > allow for more
> > > > brightness control, and then
> this patch
> > lowers the
> > > value by
> > > > another 25%,
> > > > we'll end up below the panel
> allowed PWM
> > frequency.
> > > >
> > > > In fact, one of the systems I
> checked had
> > PWM
> > > frequency as
> > > > 200Hz in VBT
> > > > and the panel datasheet also had
> PWM
> > frequency range
> > > starting
> > > > from
> > > > 200Hz. Have you considered this
> case?
> > > >
> > > > The spec said "A given LCD panel
> typically has a
> > limited
> > > range of
> > > > backlight frequency capability.
> > > > To limit the programmable frequency
> range,
> > limitations are
> > > placed on
> > > > the allowable total divider ratio with
> the Sink
> > device"
> > > >  So I think it should be auto cap to
> 200Hz in this
> > case.
> > > >
> > > > -DK
> > > > >
> > > > > Signed-off-by: Puthikorn
> Voravootivat
> > > 
> > > > > ---
> > > > >
> > drivers/gpu/drm/i915/intel_dp_aux_backlight.c |
> > > 81
> > > > +++
> > > > >  1 file changed, 81
> insertions(+)
> > > > >
> > > > > diff --git
> > >
>  a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > >
> >  b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > > index
> 0b48851013cc..6f10a2f1ab76 100644
> > > > > ---
> > >
>  a/drivers/gpu/drm/i

[Intel-gfx] [PATCH v2 2/3] drm: Create a format/modifier blob

[Ben Widawsky]

Updated blob layout (Rob, Daniel, Kristian, xerpi)

v2:
* Removed __packed, and alignment (.+)
* Fix indent in drm_format_modifier fields (Liviu)
* Remove duplicated modifier > 64 check (Liviu)
* Change comment about modifier (Liviu)
* Remove arguments to blob creation, use plane instead (Liviu)
* Fix data types (Ben)
* Make the blob part of uapi (Daniel)

Cc: Rob Clark 
Cc: Daniel Stone 
Cc: Kristian H. Kristensen 
Cc: Liviu Dudau 
Signed-off-by: Ben Widawsky 
Reviewed-by: Daniel Stone 
---
 drivers/gpu/drm/drm_mode_config.c |  7 +++
 drivers/gpu/drm/drm_plane.c   | 89 +++
 include/drm/drm_mode_config.h |  6 +++
 include/uapi/drm/drm_mode.h   | 50 ++
 4 files changed, 152 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index d9862259a2a7..6bfbc3839df5 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.gamma_lut_size_property = prop;
 
+   prop = drm_property_create(dev,
+  DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+  "IN_FORMATS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.modifiers = prop;
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 20203871e06d..f5b032b5f761 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -62,6 +62,92 @@ static unsigned int drm_num_planes(struct drm_device *dev)
return num;
 }
 
+static inline u32 *
+formats_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (u32 *)(((char *)blob) + blob->formats_offset);
+}
+
+static inline struct drm_format_modifier *
+modifiers_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (struct drm_format_modifier *)(((char *)blob) + 
blob->modifiers_offset);
+}
+
+static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
*plane)
+{
+   const struct drm_mode_config *config = &dev->mode_config;
+   const uint64_t *temp_modifiers = plane->modifiers;
+   unsigned int format_modifier_count = 0;
+   struct drm_property_blob *blob = NULL;
+   struct drm_format_modifier *mod;
+   size_t blob_size = 0, formats_size, modifiers_size;
+   struct drm_format_modifier_blob *blob_data;
+   int i, j, ret = 0;
+
+   if (plane->modifiers)
+   while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
+   format_modifier_count++;
+
+   formats_size = sizeof(*plane->format_types) * plane->format_count;
+   if (WARN_ON(!formats_size)) {
+   /* 0 formats are never expected */
+   return 0;
+   }
+
+   modifiers_size =
+   sizeof(struct drm_format_modifier) * format_modifier_count;
+
+   blob_size = sizeof(struct drm_format_modifier_blob);
+   blob_size += ALIGN(formats_size, 8);
+   blob_size += modifiers_size;
+
+   blob = drm_property_create_blob(dev, blob_size, NULL);
+   if (IS_ERR(blob))
+   return -1;
+
+   blob_data = (struct drm_format_modifier_blob *)blob->data;
+   blob_data->version = FORMAT_BLOB_CURRENT;
+   blob_data->count_formats = plane->format_count;
+   blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
+   blob_data->count_modifiers = format_modifier_count;
+
+   /* Modifiers offset is a pointer to a struct with a 64 bit field so it
+* should be naturally aligned to 8B.
+*/
+   blob_data->modifiers_offset =
+   ALIGN(blob_data->formats_offset + formats_size, 8);
+
+   memcpy(formats_ptr(blob_data), plane->format_types, formats_size);
+
+   /* If we can't determine support, just bail */
+   if (!plane->funcs->format_mod_supported)
+   goto done;
+
+   mod = modifiers_ptr(blob_data);
+   for (i = 0; i < format_modifier_count; i++) {
+   for (j = 0; j < plane->format_count; j++) {
+   if (plane->funcs->format_mod_supported(plane,
+  
plane->format_types[j],
+  
plane->modifiers[i])) {
+
+   mod->formats |= 1 << j;
+   }
+   }
+
+   mod->modifier = plane->modifiers[i];
+   mod->offset = 0;
+   mod->pad = 0;
+   mod++;
+   }
+
+done:
+   drm_object_attach_property(&plane->base, config->modifiers,
+  blob->base.id);
+
+   return ret;
+}
+
 /**
  * drm_universal_plane_init - Initialize a new universal plane object
  * @dev: DRM device
@@ -180,6 +266,9 @@ int drm_universal_plane_init(struc

[Intel-gfx] [PATCH v3 1/3] drm: Plumb modifiers through plane init

[Ben Widawsky]

This is the plumbing for supporting fb modifiers on planes. Modifiers
have already been introduced to some extent, but this series will extend
this to allow querying modifiers per plane. Based on this, the client to
enable optimal modifications for framebuffers.

This patch simply allows the DRM drivers to initialize their list of
supported modifiers upon initializing the plane.

v2: A minor addition from Daniel

v3: Updated commit message
s/INVALID/DRM_FORMAT_MOD_INVALID (Liviu)
Remove some excess newlines (Liviu)
Update comment for > 64 modifiers (Liviu)

Cc: Liviu Dudau 
Reviewed-by: Daniel Stone  (v2)
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c   |  1 +
 drivers/gpu/drm/arm/hdlcd_crtc.c|  1 +
 drivers/gpu/drm/arm/malidp_planes.c |  2 +-
 drivers/gpu/drm/armada/armada_crtc.c|  1 +
 drivers/gpu/drm/armada/armada_overlay.c |  1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  4 ++-
 drivers/gpu/drm/drm_modeset_helper.c|  1 +
 drivers/gpu/drm/drm_plane.c | 35 -
 drivers/gpu/drm/drm_simple_kms_helper.c |  3 +++
 drivers/gpu/drm/exynos/exynos_drm_plane.c   |  2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |  1 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c|  5 +++-
 drivers/gpu/drm/i915/intel_sprite.c |  4 +--
 drivers/gpu/drm/imx/ipuv3-plane.c   |  4 +--
 drivers/gpu/drm/mediatek/mtk_drm_plane.c|  2 +-
 drivers/gpu/drm/meson/meson_plane.c |  1 +
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c   |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  4 +--
 drivers/gpu/drm/mxsfb/mxsfb_drv.c   |  2 +-
 drivers/gpu/drm/nouveau/nv50_display.c  |  5 ++--
 drivers/gpu/drm/omapdrm/omap_plane.c|  3 ++-
 drivers/gpu/drm/qxl/qxl_display.c   |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  4 +--
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  4 +--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  4 +--
 drivers/gpu/drm/sti/sti_cursor.c|  2 +-
 drivers/gpu/drm/sti/sti_gdp.c   |  2 +-
 drivers/gpu/drm/sti/sti_hqvdp.c |  2 +-
 drivers/gpu/drm/sun4i/sun4i_layer.c |  2 +-
 drivers/gpu/drm/tegra/dc.c  | 12 -
 drivers/gpu/drm/vc4/vc4_plane.c |  2 +-
 drivers/gpu/drm/virtio/virtgpu_plane.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |  4 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|  4 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|  4 +--
 drivers/gpu/drm/zte/zx_plane.c  |  2 +-
 include/drm/drm_plane.h | 20 +-
 include/drm/drm_simple_kms_helper.h |  1 +
 include/uapi/drm/drm_fourcc.h   | 11 
 41 files changed, 126 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a95916f1f..cd8a24c7c67d 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -218,6 +218,7 @@ static struct drm_plane *arc_pgu_plane_init(struct 
drm_device *drm)
 
ret = drm_universal_plane_init(drm, plane, 0xff, &arc_pgu_plane_funcs,
   formats, ARRAY_SIZE(formats),
+  NULL,
   DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 798a3cc480a2..0caa03ae8708 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -303,6 +303,7 @@ static struct drm_plane *hdlcd_plane_init(struct drm_device 
*drm)
 
ret = drm_universal_plane_init(drm, plane, 0xff, &hdlcd_plane_funcs,
   formats, ARRAY_SIZE(formats),
+  NULL,
   DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret) {
devm_kfree(drm->dev, plane);
diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 814fda23cead..b156610c68a5 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -400,7 +400,7 @@ int malidp_de_planes_init(struct drm_device *drm)
DRM_PLANE_TYPE_OVERLAY;
ret = drm_universal_plane_init(drm, &plane->base, crtcs,
   &malidp_de_plane_funcs, formats,
-  n, plane_type, NULL);
+  n, NULL, plane_type, NULL);
if (ret < 0)

[Intel-gfx] [PATCH v5 3/3] drm/i915: Add format modifiers for Intel

[Ben Widawsky]

This was based on a patch originally by Kristian. It has been modified
pretty heavily to use the new callbacks from the previous patch.

v2:
  - Add LINEAR and Yf modifiers to list (Ville)
  - Combine i8xx and i965 into one list of formats (Ville)
  - Allow 1010102 formats for Y/Yf tiled (Ville)

v3:
  - Handle cursor formats (Ville)
  - Put handling for LINEAR in the mod_support functions (Ville)

v4:
  - List each modifier explicitly in supported modifiers (Ville)
  - Handle the CURSOR plane (Ville)

v5:
  - Split out cursor and sprite handling (Ville)

Cc: Ville Syrjälä 
Cc: Kristian H. Kristensen 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_display.c | 131 +--
 drivers/gpu/drm/i915/intel_sprite.c  |  76 +++-
 2 files changed, 201 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9dd67d51e7c9..3519c10abcc3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -72,6 +72,12 @@ static const uint32_t i965_primary_formats[] = {
DRM_FORMAT_XBGR2101010,
 };
 
+static const uint64_t i9xx_format_modifiers[] = {
+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+};
+
 static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -87,6 +93,14 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static const uint64_t skl_format_modifiers[] = {
+   I915_FORMAT_MOD_Yf_TILED,
+   I915_FORMAT_MOD_Y_TILED,
+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+};
+
 /* Cursor formats */
 static const uint32_t intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
@@ -13381,6 +13395,103 @@ void intel_plane_destroy(struct drm_plane *plane)
kfree(to_intel_plane(plane));
 }
 
+static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB1555:
+   case DRM_FORMAT_XRGB:
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED;
+   default:
+   return false;
+   }
+}
+
+static bool i965_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_XBGR2101010:
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED;
+   default:
+   return false;
+   }
+}
+
+static bool skl_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   switch (modifier) {
+   case DRM_FORMAT_MOD_LINEAR:
+   case I915_FORMAT_MOD_X_TILED:
+   case I915_FORMAT_MOD_Y_TILED:
+   return true;
+   default:
+   return false;
+   }
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ABGR:
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_XBGR2101010:
+   case DRM_FORMAT_YUYV:
+   case DRM_FORMAT_YVYU:
+   case DRM_FORMAT_UYVY:
+   case DRM_FORMAT_VYUY:
+   /* All i915 modifiers are fine */
+   switch (modifier) {
+   case DRM_FORMAT_MOD_LINEAR:
+   case I915_FORMAT_MOD_X_TILED:
+   case I915_FORMAT_MOD_Y_TILED:
+   case I915_FORMAT_MOD_Yf_TILED:
+   return true;
+   default:
+   return false;
+   }
+   default:
+   return false;
+   }
+}
+
+static bool intel_primary_plane_format_mod_supported(struct drm_plane *plane,
+uint32_t format,
+uint64_t modifier)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->dev);
+
+   if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
+   return false;
+
+   if (INTEL_GEN(dev_priv) >= 9)
+   return skl_mod_supported(format, modifier);
+   else if (INTEL_GEN(dev_priv) >= 4)
+   return i965_mod_supported(format, modifier);
+   else
+   return i8xx_mod_supported(format, modifier);
+
+   return false;
+}
+
+static bool intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
+   uint32_t format,
+   uint64_t modifier)
+{
+   if (WARN_ON(modifier 

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/3] drm: Plumb modifiers through plane init

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/3] drm: Plumb modifiers through plane init
URL   : https://patchwork.freedesktop.org/series/24528/
State : failure

== Summary ==

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

Test core_auth:
Subgroup basic-auth:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-gvtdvm)
Test core_prop_blob:
Subgroup basic:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-subslice-total:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_basic:
Subgroup bad-close:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-close:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-fd-close:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-

[Intel-gfx] [PATCH v5] drm/i915/guc: capture GuC logs if FW fails to load

[Daniele Ceraolo Spurio]

We're currently deleting the GuC logs if the FW fails to load, but those
are still useful to understand why the loading failed. Keeping the
object around allows us to access them after driver load is completed.

v2: keep the object around instead of using kernel memory (chris)
don't store the logs in the gpu_error struct (Chris)
add a check on guc_log_level to avoid snapshotting empty logs

v3: use separate debugfs for error log (Chris)

v4: rebased

v5: clean up obj selection, move err_load inside guc_log, move err_load
cleanup, rename functions (Michal)

Cc: Chris Wilson 
Cc: Oscar Mateo 
Cc: Michal Wajdeczko 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 38 +++-
 drivers/gpu/drm/i915/intel_guc_log.c | 17 
 drivers/gpu/drm/i915/intel_uc.c  | 14 +++--
 drivers/gpu/drm/i915/intel_uc.h  |  5 +
 4 files changed, 58 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index bd9abef..740395c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2607,27 +2607,36 @@ static int i915_guc_stage_pool(struct seq_file *m, void 
*data)
 
 static int i915_guc_log_dump(struct seq_file *m, void *data)
 {
-   struct drm_i915_private *dev_priv = node_to_i915(m->private);
-   struct drm_i915_gem_object *obj;
-   int i = 0, pg;
-
-   if (!dev_priv->guc.log.vma)
-   return 0;
+   struct drm_info_node *node = m->private;
+   struct drm_i915_private *dev_priv = node_to_i915(node);
+   bool dump_load_err = !!node->info_ent->data;
+   struct drm_i915_gem_object *obj = NULL;
+   u32 *log;
+   int i = 0;
 
-   obj = dev_priv->guc.log.vma->obj;
-   for (pg = 0; pg < obj->base.size / PAGE_SIZE; pg++) {
-   u32 *log = kmap_atomic(i915_gem_object_get_page(obj, pg));
+   if (dump_load_err)
+   obj = dev_priv->guc.log.load_err;
+   else if (dev_priv->guc.log.vma)
+   obj = dev_priv->guc.log.vma->obj;
 
-   for (i = 0; i < PAGE_SIZE / sizeof(u32); i += 4)
-   seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
-  *(log + i), *(log + i + 1),
-  *(log + i + 2), *(log + i + 3));
+   if (!obj)
+   return 0;
 
-   kunmap_atomic(log);
+   log = i915_gem_object_pin_map(obj, I915_MAP_WC);
+   if (IS_ERR(log)) {
+   seq_puts(m, "Failed to pin object\n");
+   return PTR_ERR(log);
}
 
+   for (i = 0; i < obj->base.size / sizeof(u32); i += 4)
+   seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
+  *(log + i), *(log + i + 1),
+  *(log + i + 2), *(log + i + 3));
+
seq_putc(m, '\n');
 
+   i915_gem_object_unpin_map(obj);
+
return 0;
 }
 
@@ -4811,6 +4820,7 @@ static int i915_hpd_storm_ctl_open(struct inode *inode, 
struct file *file)
{"i915_guc_info", i915_guc_info, 0},
{"i915_guc_load_status", i915_guc_load_status_info, 0},
{"i915_guc_log_dump", i915_guc_log_dump, 0},
+   {"i915_guc_load_err_log_dump", i915_guc_log_dump, 0, (void *)1},
{"i915_guc_stage_pool", i915_guc_stage_pool, 0},
{"i915_huc_load_status", i915_huc_load_status_info, 0},
{"i915_frequency_info", i915_frequency_info, 0},
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 16d3b87..31e7bec 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -660,3 +660,20 @@ void i915_guc_log_unregister(struct drm_i915_private 
*dev_priv)
guc_log_runtime_destroy(&dev_priv->guc);
mutex_unlock(&dev_priv->drm.struct_mutex);
 }
+
+void intel_guc_log_capture_load_err(struct intel_guc *guc)
+{
+   if (!guc->log.vma || i915.guc_log_level < 0)
+   return;
+
+   if (!guc->log.load_err)
+   guc->log.load_err = i915_gem_object_get(guc->log.vma->obj);
+
+   return;
+}
+
+void intel_guc_log_free_load_err(struct intel_guc *guc)
+{
+   if (guc->log.load_err)
+   i915_gem_object_put(guc->log.load_err);
+}
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 07c5658..dfea7d0 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -309,6 +309,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 
guc_disable_communication(guc);
gen9_reset_guc_interrupts(dev_priv);
+   intel_guc_log_free_load_err(guc);
 
/* We need to notify the guc whenever we change the GGTT */
i915_ggtt_enable_guc(dev_priv);
@@ -355,11 +356,11 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 
/* Did we succeded or run out of retries? */
if (ret)
-  

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: capture GuC logs if FW fails to load (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915/guc: capture GuC logs if FW fails to load (rev5)
URL   : https://patchwork.freedesktop.org/series/23982/
State : success

== Summary ==

Series 23982v5 drm/i915/guc: capture GuC logs if FW fails to load
https://patchwork.freedesktop.org/api/1.0/series/23982/revisions/5/mbox/

fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:433s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:493s
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:418s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:424s
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:539s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:415s
fi-bsw-n3050 failed to connect after reboot
fi-bxt-j4205 failed to connect after reboot
fi-ivb-3520m failed to connect after reboot
fi-skl-6700k failed to connect after reboot

713f8ec675d5a793326b94d9a0cc484608eff75e drm-tip: 2017y-05m-16d-15h-22m-08s UTC 
integration manifest
909d83e drm/i915/guc: capture GuC logs if FW fails to load

== Logs ==

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

Re: [Intel-gfx] [PATCH v2 2/3] drm: Create a format/modifier blob

[Liviu Dudau]

On Tue, May 16, 2017 at 02:31:25PM -0700, Ben Widawsky wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
> 
> v2:
> * Removed __packed, and alignment (.+)
> * Fix indent in drm_format_modifier fields (Liviu)
> * Remove duplicated modifier > 64 check (Liviu)
> * Change comment about modifier (Liviu)
> * Remove arguments to blob creation, use plane instead (Liviu)
> * Fix data types (Ben)
> * Make the blob part of uapi (Daniel)

Thanks for updating the patch!

> 
> Cc: Rob Clark 
> Cc: Daniel Stone 
> Cc: Kristian H. Kristensen 
> Cc: Liviu Dudau 
> Signed-off-by: Ben Widawsky 
> Reviewed-by: Daniel Stone 

Looks good to me!
Reviewed-by: Liviu Dudau 

Best regards,
Liviu

> ---
>  drivers/gpu/drm/drm_mode_config.c |  7 +++
>  drivers/gpu/drm/drm_plane.c   | 89 
> +++
>  include/drm/drm_mode_config.h |  6 +++
>  include/uapi/drm/drm_mode.h   | 50 ++
>  4 files changed, 152 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index d9862259a2a7..6bfbc3839df5 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.gamma_lut_size_property = prop;
>  
> + prop = drm_property_create(dev,
> +DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
> +"IN_FORMATS", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.modifiers = prop;
> +
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 20203871e06d..f5b032b5f761 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -62,6 +62,92 @@ static unsigned int drm_num_planes(struct drm_device *dev)
>   return num;
>  }
>  
> +static inline u32 *
> +formats_ptr(struct drm_format_modifier_blob *blob)
> +{
> + return (u32 *)(((char *)blob) + blob->formats_offset);
> +}
> +
> +static inline struct drm_format_modifier *
> +modifiers_ptr(struct drm_format_modifier_blob *blob)
> +{
> + return (struct drm_format_modifier *)(((char *)blob) + 
> blob->modifiers_offset);
> +}
> +
> +static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
> *plane)
> +{
> + const struct drm_mode_config *config = &dev->mode_config;
> + const uint64_t *temp_modifiers = plane->modifiers;
> + unsigned int format_modifier_count = 0;
> + struct drm_property_blob *blob = NULL;
> + struct drm_format_modifier *mod;
> + size_t blob_size = 0, formats_size, modifiers_size;
> + struct drm_format_modifier_blob *blob_data;
> + int i, j, ret = 0;
> +
> + if (plane->modifiers)
> + while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
> + format_modifier_count++;
> +
> + formats_size = sizeof(*plane->format_types) * plane->format_count;
> + if (WARN_ON(!formats_size)) {
> + /* 0 formats are never expected */
> + return 0;
> + }
> +
> + modifiers_size =
> + sizeof(struct drm_format_modifier) * format_modifier_count;
> +
> + blob_size = sizeof(struct drm_format_modifier_blob);
> + blob_size += ALIGN(formats_size, 8);
> + blob_size += modifiers_size;
> +
> + blob = drm_property_create_blob(dev, blob_size, NULL);
> + if (IS_ERR(blob))
> + return -1;
> +
> + blob_data = (struct drm_format_modifier_blob *)blob->data;
> + blob_data->version = FORMAT_BLOB_CURRENT;
> + blob_data->count_formats = plane->format_count;
> + blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
> + blob_data->count_modifiers = format_modifier_count;
> +
> + /* Modifiers offset is a pointer to a struct with a 64 bit field so it
> +  * should be naturally aligned to 8B.
> +  */
> + blob_data->modifiers_offset =
> + ALIGN(blob_data->formats_offset + formats_size, 8);
> +
> + memcpy(formats_ptr(blob_data), plane->format_types, formats_size);
> +
> + /* If we can't determine support, just bail */
> + if (!plane->funcs->format_mod_supported)
> + goto done;
> +
> + mod = modifiers_ptr(blob_data);
> + for (i = 0; i < format_modifier_count; i++) {
> + for (j = 0; j < plane->format_count; j++) {
> + if (plane->funcs->format_mod_supported(plane,
> +
> plane->format_types[j],
> +
> plane->modifiers[i])) {
> +
> + mod->formats |= 1 << j;
> + }
> + }
> +
> + mod->modifier = plane->modifiers[i];
> + mod->offset = 0;
> + mod->pad = 0;
> + mod++;
> + }
>