[Intel-gfx] [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.

[Dhinakaran Pandiyan]

Some HW vblank counters reset due to power management events, which messes
up the vblank counting logic. This leads to screen freezes with user space
waiting on vblank events that may not occur if the counter keeps resetting.

For e.g., After the HW vblank counter resets
[9.007359] [drm:drm_update_vblank_count [drm]] updating vblank count
on crtc 0: current=297, diff=4294965389, hw=5 hw_last=1912

So, fall back to the SW counter, computed using  vblank timestamps
and frame duration, when the HW counter value deviates by 50% of the SW
computed value.

I have tested this patch on my SKL laptop with i915.enable_psr=1 and it
*seems* to solve the screen freeze issue seen with PSR when DMC is loaded.

Known issues:
1) The 50% deviation margin is arbitrary.
2) "Redundant vblirq ignored" messages are more frequent.

I am sending this as an RFC to get feedback on whether the fall back
approach is sane and if it should be implemented in the core.

Cc: Daniel Vetter 
Cc: Rodrigo Vivi 
Cc: Ville Syrjälä 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_vblank.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 57cc6e37c810..8000aae5f1f7 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -190,11 +190,12 @@ static void drm_update_vblank_count(struct drm_device 
*dev, unsigned int pipe,
bool in_vblank_irq)
 {
struct drm_vblank_crtc *vblank = >vblank[pipe];
-   u32 cur_vblank, diff;
+   u32 cur_vblank;
bool rc;
ktime_t t_vblank;
int count = DRM_TIMESTAMP_MAXRETRIES;
int framedur_ns = vblank->framedur_ns;
+   u32 diff = in_vblank_irq ? 1 : 0;
 
/*
 * Interrupts were disabled prior to this call, so deal with counter
@@ -213,26 +214,31 @@ static void drm_update_vblank_count(struct drm_device 
*dev, unsigned int pipe,
rc = drm_get_last_vbltimestamp(dev, pipe, _vblank, 
in_vblank_irq);
} while (cur_vblank != __get_vblank_counter(dev, pipe) && --count > 0);
 
-   if (dev->max_vblank_count != 0) {
-   /* trust the hw counter when it's around */
+   if (dev->max_vblank_count)
diff = (cur_vblank - vblank->last) & dev->max_vblank_count;
-   } else if (rc && framedur_ns) {
+
+   if (rc && framedur_ns) {
u64 diff_ns = ktime_to_ns(ktime_sub(t_vblank, vblank->time));
+   u32 sw_diff;
 
/*
 * Figure out how many vblanks we've missed based
 * on the difference in the timestamps and the
 * frame/field duration.
 */
-   diff = DIV_ROUND_CLOSEST_ULL(diff_ns, framedur_ns);
-
-   if (diff == 0 && in_vblank_irq)
+   sw_diff = DIV_ROUND_CLOSEST_ULL(diff_ns, framedur_ns);
+   if (sw_diff == 0 && in_vblank_irq)
DRM_DEBUG_VBL("crtc %u: Redundant vblirq ignored."
  " diff_ns = %lld, framedur_ns = %d)\n",
  pipe, (long long) diff_ns, framedur_ns);
-   } else {
-   /* some kind of default for drivers w/o accurate vbl 
timestamping */
-   diff = in_vblank_irq ? 1 : 0;
+
+   if (!dev->max_vblank_count)
+   diff = sw_diff;
+   else if (sw_diff && abs(diff - sw_diff) > 
DIV_ROUND_CLOSEST(sw_diff, 2)) {
+   DRM_DEBUG_VBL("hw vblank counter(%u) deviates from sw 
(%u)\n",
+ diff, sw_diff);
+   diff = sw_diff;
+   }
}
 
/*
-- 
2.11.0

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

[Intel-gfx] [PATCH v3] drm/i915: Object w/o backing stroage is banned by -ENXIO

[Tina Zhang]

-ENXIO should be returned when operations are banned from changing
backing storage of objects without backing storage.

v3:
- Separate this patch from "Introduce GEM proxy" patch-set. (Joonas)

v2:
- update the patch description and subject to just mention objects w/o
  backing storage, instead of "GEM proxy". (Joonas)
Reviewed-by: Chris Wilson 

Signed-off-by: Tina Zhang 
---
 drivers/gpu/drm/i915/i915_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 13bc18d..e85721c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1713,7 +1713,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
 */
if (!obj->base.filp) {
i915_gem_object_put(obj);
-   return -EINVAL;
+   return -ENXIO;
}
 
addr = vm_mmap(obj->base.filp, 0, args->size,
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 2/5] drm/i915/guc: Release all client doorbells on suspend and acquire on resume

[Sagar Arun Kamble]

On 11/6/2017 5:43 PM, Chris Wilson wrote:

Quoting Sagar Arun Kamble (2017-11-05 13:39:40)

Before GT device suspend, i915 should release GuC client doorbells by
stopping doorbell controller snooping and doorbell deallocation through
GuC. They need to be acquired again on resume. This will also resolve
the driver unload issue with GuC, where doorbell deallocation was being
done post GEM suspend.
Release function is called from guc_suspend prior to sending sleep action
during runtime and drm suspend. Acquiral is different in runtime and drm
resume paths as on drm resume we are currently doing full reinit. Release
should be done in synchronization with acquire hence GuC suspend/resume
along with doorbell release/acquire should be under struct_mutex. Upcoming
suspend and resume restructuring for GuC will update these changes.

Signed-off-by: Sagar Arun Kamble 
Cc: Chris Wilson 
Cc: Michał Winiarski 
Cc: Michel Thierry 
Cc: Michal Wajdeczko 
Cc: Arkadiusz Hiler 
Cc: Joonas Lahtinen 
---
  drivers/gpu/drm/i915/i915_drv.c|  3 +++
  drivers/gpu/drm/i915/i915_gem.c|  5 +++--
  drivers/gpu/drm/i915/i915_guc_submission.c | 20 
  drivers/gpu/drm/i915/i915_guc_submission.h |  2 ++
  drivers/gpu/drm/i915/intel_guc.c   |  2 ++
  5 files changed, 26 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e7e9e06..3df8a7d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -47,6 +47,7 @@
  #include 
  
  #include "i915_drv.h"

+#include "i915_guc_submission.h"
  #include "i915_trace.h"
  #include "i915_vgpu.h"
  #include "intel_drv.h"
@@ -2615,6 +2616,8 @@ static int intel_runtime_resume(struct device *kdev)
  
 intel_guc_resume(dev_priv);
  
+   i915_guc_clients_acquire_doorbells(_priv->guc);

intel_guc_acquire_doorbells();
Prefixed "i915_guc_clients" since this modifies submission state 
(clients/doorbells). Should have kept dev_priv as parameter.
what should be the correct option here: intel_guc*(guc) or 
i915_guc*(dev_priv)


Though, if we need to specialise between resume and runtime_resume, I
suggest adding intel_guc_resume() and intel_guc_runtime_resume() entry
points. (We probably should find a better way to distinguish those two
paths, system_resume vs runtime_resume?)
Yes. these will be added in the upcoming GuC suspend/resume 
restructuring series.
Functionality along runtime/system suspend path will be same for GuC. 
Will defer in
the resume path since we are doing full gem reinit on resume from system 
suspend.

-Chris


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

Re: [Intel-gfx] [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

[Zhang, Tina]

> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Gerd Hoffmann
> Sent: Monday, November 6, 2017 5:01 PM
> To: Zhang, Tina ; alex.william...@redhat.com;
> ch...@chris-wilson.co.uk; joonas.lahti...@linux.intel.com;
> zhen...@linux.intel.com; Lv, Zhiyuan ; Wang, Zhi A
> ; Tian, Kevin ; dan...@ffwll.ch;
> kwankh...@nvidia.com
> Cc: Daniel Vetter ; intel-gfx@lists.freedesktop.org;
> intel-gvt-...@lists.freedesktop.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation
> 
>   Hi,
> 
> > +/**
> > + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> > + *struct
> > vfio_device_query_gfx_plane)
> > + *
> > + * Set the drm_plane_type and flags, then retrieve the gfx plane
> > info.
> > + *
> > + * flags supported:
> > + * - VFIO_GFX_PLANE_TYPE_PROBE and VFIO_GFX_PLANE_TYPE_DMABUF
> are
> > set
> > + *   to ask if the mdev supports dma-buf. 0 on support, -EINVAL on
> > no
> > + *   support for dma-buf.
> > + * - VFIO_GFX_PLANE_TYPE_PROBE and VFIO_GFX_PLANE_TYPE_REGION
> are
> > set
> > + *   to ask if the mdev supports region. 0 on support, -EINVAL on no
> > + *   support for region.
> > + * - VFIO_GFX_PLANE_TYPE_DMABUF or VFIO_GFX_PLANE_TYPE_REGION
> is set
> > + *   with each call to query the plane info.
> > + * - Others are invalid and return -EINVAL.
> > + *
> > + * Return: 0 on success, -ENODEV with all out fields zero on mdev
> > + * device initialization, -errno on other failure.
> 
> Should also not here that it is not an error if the guest has not defined a 
> plane
> yet.  The ioctl should return success in that case and zero-initialize plane 
> info
> (drm_format + size + width + height fields).
Indeed. I just need to update the comments, as this version is implemented with 
this in mind. Thanks.

> 
> > + */
> > +struct vfio_device_gfx_plane_info {
> > +   __u32 argsz;
> > +   __u32 flags;
> > +#define VFIO_GFX_PLANE_TYPE_PROBE (1 << 0) #define
> > +VFIO_GFX_PLANE_TYPE_DMABUF (1 << 1) #define
> > +VFIO_GFX_PLANE_TYPE_REGION (1 << 2)
> > +   /* in */
> > +   __u32 drm_plane_type;   /* type of plane:
> > DRM_PLANE_TYPE_* */
> 
> Add a head field here?  People asked @ kvm forum about multihead support.
> Even if the initial driver version doesn't support it we could add a field so 
> it
> becomes easier to add it at some point in the future.
> 
> Probing for available heads could be done with the PROBE flag, i.e.
> flags = PROBE | DMABUF, plane_type = PRIMARY, head = 0, 1, ...
Does the multihead mean multiple display monitor? So each head can have its own 
one primary plane, one cursor plane and maybe some sprite planes if supported.
And the flow could be like this:
1) flags = PROBE | DMABUF, then return the number of heads in 
vfio_device_gfx_plane_info.head.
2) flags = DMABUF with plane_type = PRIMARY, head = 0, 1, ..., then return the 
id of the exposed framebuffer of that head.
Am I correct?

Another question is if the sprite plane is supported, how we're going to 
identify them, as there could be several sprite planes for one display monitor.
Add another field "num_plane" for it? Then, I guess the flow could be like this:
1) flags = PROBE | DMABUF, then return the number of heads in 
vfio_device_gfx_plane_info.head.
2) flags = PROBE | DMABUF and head = 0, 1, ..., and plane_type = 
PRIMARY/CURSOR/SPRITE, then return the num_plane.
3) flags = DMABUF with plane_type = PRIMARY, head = 0, 1, ..., num_plane =0, 1, 
..., then return the id of the exposed framebuffer of that head.
Does it make sense?
Thanks.

> 
> > +   __u32 x_hot;/* horizontal position of cursor hotspot */
> > +   __u32 y_hot;/* vertical position of cursor hotspot */
> 
> Needs documentation how the driver signals "no hotspot information available"
> (using 0x for example).
This version has implemented this. I will update the comments.
Thanks.

BR,
Tina
> 
> cheers,
>   Gerd
> 
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

[Zhang, Tina]

> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Tuesday, November 7, 2017 4:37 AM
> To: Gerd Hoffmann 
> Cc: Zhang, Tina ; Tian, Kevin ;
> Daniel Vetter ; intel-gfx@lists.freedesktop.org;
> joonas.lahti...@linux.intel.com; linux-ker...@vger.kernel.org;
> zhen...@linux.intel.com; ch...@chris-wilson.co.uk; kwankh...@nvidia.com;
> Lv, Zhiyuan ; dan...@ffwll.ch; intel-gvt-
> d...@lists.freedesktop.org; Wang, Zhi A 
> Subject: Re: [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation
> 
> On Mon, 06 Nov 2017 10:05:34 +0100
> Gerd Hoffmann  wrote:
> 
> >   Hi,
> >
> > > > I thought we had agreed to make this behave similar to
> > > > VFIO_GROUP_GET_DEVICE_FD, the ioctl would take a __u32 dmabuf_id
> > > > and return the file descriptor as the ioctl return value.  Thanks,
> > >
> > > If we follow VFIO_GROUP_GET_DEVICE_FD, we would lose flags
> > > functionality.
> > > Zhi and Zhenyu, how do you think about it?
> >
> > The ioctl is simple enough that not having flags should not be a
> > problem I think.
> >
> > Also note that dmabuf_id is received using the PLANE_INFO ioctl, so
> > should the need arise to negotiate something in the future chances are
> > high that it can be done using the PLANE_INFO ioctl flags.
> 
> Right, the ioctl is "get fd for thing" so we have control of "thing".
> I think we had this same discussion on v15.  Thanks,
Then, OK. Thanks.

BR,
Tina
> 
> Alex
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Object w/o backing stroage is banned by -ENXIO

[Zhang, Tina]

> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Monday, November 6, 2017 6:57 PM
> To: Zhang, Tina ; zhen...@linux.intel.com; Wang, Zhi
> A ; dan...@ffwll.ch; ch...@chris-wilson.co.uk
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [PATCH v2 2/2] drm/i915: Object w/o backing stroage is banned by
> -ENXIO
> 
> Hi Tina,
> 
> Please send this patch alone (or in the beginning of your series), so it can 
> be
> merged already.
> 
> That'll save you the effort of carrying this patch.
Thank you very much :)

BR,
Tina
> 
> Regards, Joonas
> 
> On Wed, 2017-11-01 at 17:22 +0800, Tina Zhang wrote:
> > -ENXIO should be returned when operations are banned from changing
> > backing storage of objects without backing storage.
> >
> > v2:
> > - update the patch description and subject to just mention objects w/o
> >   backing storage, instead of "GEM proxy". (Joonas)
> >
> > Signed-off-by: Tina Zhang 
> > Reviewed-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> > ---
> >  drivers/gpu/drm/i915/i915_gem.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c index 13bc18d..e85721c 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -1713,7 +1713,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev,
> void *data,
> >  */
> > if (!obj->base.filp) {
> > i915_gem_object_put(obj);
> > -   return -EINVAL;
> > +   return -ENXIO;
> > }
> >
> > addr = vm_mmap(obj->base.filp, 0, args->size,
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Introduce GEM proxy

[Zhang, Tina]

> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Joonas Lahtinen
> Sent: Monday, November 6, 2017 7:24 PM
> To: Zhang, Tina ; zhen...@linux.intel.com; Wang, Zhi
> A ; dan...@ffwll.ch; ch...@chris-wilson.co.uk
> Cc: Daniel Vetter ; intel-gfx@lists.freedesktop.org;
> intel-gvt-...@lists.freedesktop.org
> Subject: Re: [PATCH v2 1/2] drm/i915: Introduce GEM proxy
> 
> On Wed, 2017-11-01 at 17:22 +0800, Tina Zhang wrote:
> > GEM proxy is a kind of GEM, whose backing physical memory is pinned
> > and produced by guest VM and is used by host as read only. With GEM
> > proxy, host is able to access guest physical memory through GEM object
> > interface. As GEM proxy is such a special kind of GEM, a new flag
> > I915_GEM_OBJECT_IS_PROXY is introduced to ban host from changing the
> > backing storage of GEM proxy.
> >
> > v2:
> > - return -ENXIO when pin and map pages of GEM proxy to kernel space.
> >   (Chris)
> >
> > Here are the histories of this patch in "Dma-buf support for Gvt-g"
> > patch-set:
> >
> > v14:
> > - return -ENXIO when gem proxy object is banned by ioctl.
> >   (Chris) (Daniel)
> >
> > v13:
> > - add comments to GEM proxy. (Chris)
> > - don't ban GEM proxy in i915_gem_sw_finish_ioctl. (Chris)
> > - check GEM proxy bar after finishing i915_gem_object_wait. (Chris)
> > - remove GEM proxy bar in i915_gem_madvise_ioctl.
> >
> > v6:
> > - add gem proxy barrier in the following ioctls. (Chris)
> >   i915_gem_set_caching_ioctl
> >   i915_gem_set_domain_ioctl
> >   i915_gem_sw_finish_ioctl
> >   i915_gem_set_tiling_ioctl
> >   i915_gem_madvise_ioctl
> >
> > Signed-off-by: Tina Zhang 
> > Reviewed-by: Joonas Lahtinen 
> > Reviewed-by: Chris Wilson 
> > Cc: Daniel Vetter 
> 
> 
> 
> > @@ -1649,6 +1659,10 @@ i915_gem_sw_finish_ioctl(struct drm_device
> *dev, void *data,
> > if (!obj)
> > return -ENOENT;
> >
> > +   /* Proxy objects are barred from CPU access, so there is no
> > +* need to ban sw_finish as it is a nop.
> > +*/
> > +
> > /* Pinned buffers may be scanout, so flush the cache */
> > i915_gem_object_flush_if_display(obj);
> > i915_gem_object_put(obj);
> > @@ -2614,7 +2628,8 @@ void *i915_gem_object_pin_map(struct
> drm_i915_gem_object *obj,
> > void *ptr;
> > int ret;
> >
> > -   GEM_BUG_ON(!i915_gem_object_has_struct_page(obj));
> > +   if (unlikely(!i915_gem_object_has_struct_page(obj)))
> > +   return ERR_PTR(-ENODEV);
> 
> You should have marked this change in the changelog and then marked the
> Reviewed-by tags to be valid only to the previous version of this patch.
> 
> It's not a fair game to claim a patch to be "Reviewed-by" at the current 
> version,
> when you've made changes that were not agreed upon.
I thought we were agreed on this :)

> 
> So that's some meta-review. Back to the actual review;
> 
> Which codepath was hitting the GEM_BUG_ON? Wondering if it would be
> cleaner to avoid the call to this function on that single codepath.
Here is the previously comments:
https://lists.freedesktop.org/archives/intel-gvt-dev/2017-October/002278.html
Thanks.

BR,
Tina
> 
> Regards, Joonas
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] tests/kms_plane_scaling: Enhanced plane scaler test case.

[Yadav Jyoti]

From: Jyoti Yadav 

Added few subtests to cover below gaps.
1. scaler with pixelformat and tiling.
2. scaler with rotation
3. scaler with multiple planes
4. scaler with multi pipe
5. scaler with clipping/clamping scenario

Signed-off-by: Jyoti Yadav 
---
 tests/kms_plane_scaling.c | 480 +-
 1 file changed, 476 insertions(+), 4 deletions(-)

diff --git a/tests/kms_plane_scaling.c b/tests/kms_plane_scaling.c
index 5ed69f3..c1bb7b1 100644
--- a/tests/kms_plane_scaling.c
+++ b/tests/kms_plane_scaling.c
@@ -43,10 +43,11 @@ typedef struct {
struct igt_fb fb1;
struct igt_fb fb2;
struct igt_fb fb3;
+   struct igt_fb fb4;
int fb_id1;
int fb_id2;
int fb_id3;
-
+   int fb_id4;
igt_plane_t *plane1;
igt_plane_t *plane2;
igt_plane_t *plane3;
@@ -54,6 +55,51 @@ typedef struct {
 } data_t;
 
 #define FILE_NAME   "1080p-left.png"
+#define MIN_SRC_WIDTH 8
+#define MAX_SRC_WIDTH 4096
+static uint32_t check_pixel_format(uint32_t pixel_format)
+{
+   const uint32_t *igt_formats;
+   int num_igt_formats;
+   int i;
+
+
+   igt_get_all_cairo_formats(_formats, _igt_formats);
+   for (i = 0; i < num_igt_formats; i++) {
+   if (pixel_format == igt_formats[i])
+   return 0;
+   }
+
+   return -1;
+}
+bool is_igt_output_connected(igt_output_t *output)
+{
+   /* Something went wrong during probe? */
+   if (!output->config.connector)
+   return false;
+
+   if (output->config.connector->connection == DRM_MODE_CONNECTED)
+   return true;
+
+   return false;
+}
+
+static igt_output_t *get_next_valid_output(igt_display_t *data, int i)
+{
+   int j = 0, valid_output = 0;
+   drmModeModeInfo *mode;
+   for (j = 0; j < data->n_outputs; j++) {
+   if (is_igt_output_connected(>outputs[j])) {
+   mode = igt_output_get_mode(>outputs[j]);
+   if (mode->hdisplay != 0 && mode->vdisplay != 0) {
+   valid_output++;
+   if (valid_output == i)
+   return >outputs[j];
+   }
+   }
+   }
+   return NULL;
+}
 
 static void prepare_crtc(data_t *data, igt_output_t *output, enum pipe pipe,
igt_plane_t *plane, drmModeModeInfo *mode, enum 
igt_commit_style s)
@@ -298,7 +344,418 @@ static void test_plane_scaling(data_t *d)
igt_require_f(valid_tests, "no valid crtc/connector combinations 
found\n");
 }
 
-igt_simple_main
+uint64_t get_tiling(int i)
+{
+   switch (i) {
+   case 0:
+   return LOCAL_DRM_FORMAT_MOD_NONE;
+   break;
+   case 1:
+   return LOCAL_I915_FORMAT_MOD_X_TILED;
+   break;
+   case 2:
+   return LOCAL_I915_FORMAT_MOD_Y_TILED;
+   break;
+   case 3:
+   return LOCAL_I915_FORMAT_MOD_Yf_TILED;
+   break;
+   default:
+   return -1;
+   }
+}
+
+void loop_plane_scaling(data_t *d, igt_plane_t *plane, uint32_t pixel_format,
+   uint64_t tiling, enum pipe pipe, igt_output_t *output)
+{
+   igt_display_t *display = >display;
+   int width, height;
+   /* create buffer in the range of  min and max source side limit.*/
+   for (width = MIN_SRC_WIDTH; width <= MAX_SRC_WIDTH; width = width + 
500) {
+   igt_output_set_pipe(output, pipe);
+   height = width + 10;
+   d->fb_id1 = igt_create_pattern_fb(display->drm_fd, width, 
height,
+   pixel_format, tiling, >fb1);
+   igt_assert(d->fb_id1);
+   igt_plane_set_fb(plane, >fb1);
+   /* check upscaling */
+   igt_fb_set_position(>fb1, plane, 0, 0);
+   igt_fb_set_size(>fb1, plane, d->fb1.width, d->fb1.height);
+   igt_plane_set_position(plane, 10, 10);
+   igt_plane_set_size(plane, width*2, height*2);
+   igt_display_commit2(display, COMMIT_ATOMIC);
+   igt_plane_set_fb(plane, NULL);
+   igt_plane_set_position(plane, 0, 0);
+   if (d->fb_id1) {
+   igt_remove_fb(d->drm_fd, >fb1);
+   d->fb_id1 = 0;
+   }
+   }
+}
+void test_scaler_with_pixel_format(data_t *d)
+{
+   igt_display_t *display = >display;
+   igt_output_t *output;
+   enum pipe pipe;
+   igt_plane_t *plane;
+   int valid_tests = 0;
+   igt_require(d->num_scalers);
+   for_each_pipe_with_valid_output(display, pipe, output) {
+   drmModeModeInfo *mode;
+   igt_output_set_pipe(output, pipe);
+   mode = 

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ (rev4)
URL   : https://patchwork.freedesktop.org/series/33087/
State : failure

== Summary ==

Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
skip   -> PASS   (shard-hsw)
Test kms_cursor_legacy:
Subgroup all-pipes-torture-bo:
pass   -> INCOMPLETE (shard-hsw)
Test kms_flip:
Subgroup plain-flip-ts-check:
fail   -> PASS   (shard-hsw) fdo#100368

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

shard-hswtotal:2500 pass:1406 dwarn:1   dfail:0   fail:10  skip:1082 
time:8962s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6978/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ (rev4)

[Patchwork]

== Series Details ==

Series: drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ (rev4)
URL   : https://patchwork.freedesktop.org/series/33087/
State : success

== Summary ==

Series 33087v4 drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+
https://patchwork.freedesktop.org/api/1.0/series/33087/revisions/4/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-gdg-551) fdo#102618
Test kms_frontbuffer_tracking:
Subgroup basic:
fail   -> PASS   (fi-glk-dsi) fdo#103167

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:445s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:452s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:380s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:532s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:278s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:502s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:505s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:507s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:491s
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:559s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:635s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:431s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:263s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:581s
fi-glk-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:491s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:429s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:431s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:427s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:499s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:574s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:588s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:573s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:448s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:591s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:652s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:527s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:502s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:461s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:572s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:420s

4295e1469b2127d79d2d02ef34d065509bdded97 drm-tip: 2017y-11m-06d-15h-35m-57s UTC 
integration manifest
19abc54ba37c drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6978/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 6/9] drm/i915: expose command stream timestamp frequency to userspace

[Rafael Antognolli]

This patch, along with the respective ones for Mesa, does fix the gl
timestamp query piglit failures on CNL. So it is

Tested-by: Rafael Antognolli 

On Thu, Nov 02, 2017 at 04:29:46PM +, Lionel Landwerlin wrote:
> We use to have this fixed per generation, but starting with CNL userspace
> cannot tell just off the PCI ID. Let's make this information available. This
> is particularly useful for performance monitoring where much of the
> normalization work is done using those timestamps (this include pipeline
> statistics in both GL & Vulkan as well as OA reports).
> 
> Signed-off-by: Lionel Landwerlin 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c  |  2 +
>  drivers/gpu/drm/i915/i915_drv.c  |  3 +
>  drivers/gpu/drm/i915/i915_drv.h  |  2 +
>  drivers/gpu/drm/i915/i915_reg.h  | 21 +++
>  drivers/gpu/drm/i915/intel_device_info.c | 99 
> 
>  include/uapi/drm/i915_drm.h  |  6 ++
>  6 files changed, 133 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 39883cd915db..0897fd616a1f 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -3246,6 +3246,8 @@ static int i915_engine_info(struct seq_file *m, void 
> *unused)
>  yesno(dev_priv->gt.awake));
>   seq_printf(m, "Global active requests: %d\n",
>  dev_priv->gt.active_requests);
> + seq_printf(m, "CS timestamp frequency: %llu\n",
> +dev_priv->info.cs_timestamp_frequency);
>  
>   p = drm_seq_file_printer(m);
>   for_each_engine(engine, dev_priv, id)
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e7e9e061073b..fdd23e79fb46 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -416,6 +416,9 @@ static int i915_getparam(struct drm_device *dev, void 
> *data,
>   if (!value)
>   return -ENODEV;
>   break;
> + case I915_PARAM_CS_TIMESTAMP_FREQUENCY:
> + value = INTEL_INFO(dev_priv)->cs_timestamp_frequency;
> + break;
>   default:
>   DRM_DEBUG("Unknown parameter %d\n", param->param);
>   return -EINVAL;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6cb7cd7f9420..4e804aaeaae1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -886,6 +886,8 @@ struct intel_device_info {
>   /* Slice/subslice/EU info */
>   struct sseu_dev_info sseu;
>  
> + uint64_t cs_timestamp_frequency;
> +
>   struct color_luts {
>   u16 degamma_lut_size;
>   u16 gamma_lut_size;
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index a2223f01ee2a..f392f28f2cfa 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1119,9 +1119,24 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
>  
>  /* RPM unit config (Gen8+) */
>  #define RPM_CONFIG0  _MMIO(0x0D00)
> +#define  GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT   3
> +#define  GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_MASK(1 << 
> GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_SHIFT)
> +#define  GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_19_2_MHZ0
> +#define  GEN9_RPM_CONFIG0_CRYSTAL_CLOCK_FREQ_24_MHZ  1
> +#define  GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT 1
> +#define  GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_MASK  (0x3 << 
> GEN10_RPM_CONFIG0_CTC_SHIFT_PARAMETER_SHIFT)
> +
>  #define RPM_CONFIG1  _MMIO(0x0D04)
>  #define  GEN10_GT_NOA_ENABLE  (1 << 9)
>  
> +/* GPM unit config (assuming Gen8+, documentation is fuzzy...) */
> +#define GEN8_CTC_MODE_MMIO(0xA26C)
> +#define  GEN8_CTC_SOURCE_PARAMETER_MASK 1
> +#define  GEN8_CTC_SOURCE_CRYSTAL_CLOCK   0
> +#define  GEN8_CTC_SOURCE_DIVIDE_LOGIC1
> +#define  GEN8_CTC_SHIFT_PARAMETER_SHIFT  1
> +#define  GEN8_CTC_SHIFT_PARAMETER_MASK   (0x3 << 
> GEN8_CTC_SHIFT_PARAMETER_SHIFT)
> +
>  /* RPC unit config (Gen8+) */
>  #define RPC_CONFIG   _MMIO(0x0D08)
>  
> @@ -8865,6 +8880,12 @@ enum skl_power_gate {
>  #define ILK_TIMESTAMP_HI _MMIO(0x70070)
>  #define IVB_TIMESTAMP_CTR_MMIO(0x44070)
>  
> +#define GEN8_TIMESTAMP_OVERRIDE  _MMIO(0x44074)
> +#define  GEN8_TIMESTAMP_OVERRIDE_US_COUNTER_SHIFT0
> +#define  GEN8_TIMESTAMP_OVERRIDE_US_COUNTER_MASK 0x3ff
> +#define  GEN8_TIMESTAMP_OVERRIDE_US_COUNTER_DENOMINATOR_SHIFT12
> +#define  GEN8_TIMESTAMP_OVERRIDE_US_COUNTER_DENOMINATOR_MASK (0xf << 12)
> +
>  #define _PIPE_FRMTMSTMP_A0x70048
>  #define PIPE_FRMTMSTMP(pipe) \
>   _MMIO_PIPE2(pipe, _PIPE_FRMTMSTMP_A)
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c 
> 

[Intel-gfx] [CI v3] drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+

[James Ausmus]

Since GLK, some plane configuration settings have moved to the
PLANE_COLOR_CTL register. Refactor handling of the register to work like
PLANE_CTL. This also allows us to fix the set/read of the plane Alpha
Mode for GLK+.

v2: Adjust ordering of platform checks to be newest->oldest, drop
redundant comment about alpha blending. (Ville)

v3: Move Alpha Mode bits out of skl_plane_ctl_format into
skl_plane_ctl_alpha, and drop glk_plane_ctl_format, drop initialization
of state->color_ctl on platforms that don't use it, and drop color_ctl
local var. (Ville)

Signed-off-by: James Ausmus 
Cc: Paulo Zanoni 
Cc: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h  | 12 --
 drivers/gpu/drm/i915/intel_display.c | 71 +---
 drivers/gpu/drm/i915/intel_drv.h |  5 +++
 drivers/gpu/drm/i915/intel_sprite.c  | 11 +++---
 4 files changed, 76 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f0f8f6059652..ecd6b236e005 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6263,7 +6263,7 @@ enum {
 #define _PLANE_CTL_2_A 0x70280
 #define _PLANE_CTL_3_A 0x70380
 #define   PLANE_CTL_ENABLE (1 << 31)
-#define   PLANE_CTL_PIPE_GAMMA_ENABLE  (1 << 30)
+#define   PLANE_CTL_PIPE_GAMMA_ENABLE  (1 << 30)   /* Pre-GLK */
 #define   PLANE_CTL_FORMAT_MASK(0xf << 24)
 #define   PLANE_CTL_FORMAT_YUV422  (  0 << 24)
 #define   PLANE_CTL_FORMAT_NV12(  1 << 24)
@@ -6273,7 +6273,7 @@ enum {
 #define   PLANE_CTL_FORMAT_AYUV(  8 << 24)
 #define   PLANE_CTL_FORMAT_INDEXED ( 12 << 24)
 #define   PLANE_CTL_FORMAT_RGB_565 ( 14 << 24)
-#define   PLANE_CTL_PIPE_CSC_ENABLE(1 << 23)
+#define   PLANE_CTL_PIPE_CSC_ENABLE(1 << 23) /* Pre-GLK */
 #define   PLANE_CTL_KEY_ENABLE_MASK(0x3 << 21)
 #define   PLANE_CTL_KEY_ENABLE_SOURCE  (  1 << 21)
 #define   PLANE_CTL_KEY_ENABLE_DESTINATION (  2 << 21)
@@ -6286,13 +6286,13 @@ enum {
 #define   PLANE_CTL_YUV422_VYUY(  3 << 16)
 #define   PLANE_CTL_DECOMPRESSION_ENABLE   (1 << 15)
 #define   PLANE_CTL_TRICKLE_FEED_DISABLE   (1 << 14)
-#define   PLANE_CTL_PLANE_GAMMA_DISABLE(1 << 13)
+#define   PLANE_CTL_PLANE_GAMMA_DISABLE(1 << 13) /* Pre-GLK */
 #define   PLANE_CTL_TILED_MASK (0x7 << 10)
 #define   PLANE_CTL_TILED_LINEAR   (  0 << 10)
 #define   PLANE_CTL_TILED_X(  1 << 10)
 #define   PLANE_CTL_TILED_Y(  4 << 10)
 #define   PLANE_CTL_TILED_YF   (  5 << 10)
-#define   PLANE_CTL_ALPHA_MASK (0x3 << 4)
+#define   PLANE_CTL_ALPHA_MASK (0x3 << 4) /* Pre-GLK */
 #define   PLANE_CTL_ALPHA_DISABLE  (  0 << 4)
 #define   PLANE_CTL_ALPHA_SW_PREMULTIPLY   (  2 << 4)
 #define   PLANE_CTL_ALPHA_HW_PREMULTIPLY   (  3 << 4)
@@ -6332,6 +6332,10 @@ enum {
 #define   PLANE_COLOR_PIPE_GAMMA_ENABLE(1 << 30)
 #define   PLANE_COLOR_PIPE_CSC_ENABLE  (1 << 23)
 #define   PLANE_COLOR_PLANE_GAMMA_DISABLE  (1 << 13)
+#define   PLANE_COLOR_ALPHA_MASK   (0x3 << 4)
+#define   PLANE_COLOR_ALPHA_DISABLE(0 << 4)
+#define   PLANE_COLOR_ALPHA_SW_PREMULTIPLY (2 << 4)
+#define   PLANE_COLOR_ALPHA_HW_PREMULTIPLY (3 << 4)
 #define _PLANE_BUF_CFG_1_A 0x7027c
 #define _PLANE_BUF_CFG_2_A 0x7037c
 #define _PLANE_NV12_BUF_CFG_1_A0x70278
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 737de251d0f8..214c0c119002 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3436,17 +3436,10 @@ static u32 skl_plane_ctl_format(uint32_t pixel_format)
return PLANE_CTL_FORMAT_XRGB_ | PLANE_CTL_ORDER_RGBX;
case DRM_FORMAT_XRGB:
return PLANE_CTL_FORMAT_XRGB_;
-   /*
-* XXX: For ARBG/ABGR formats we default to expecting scanout buffers
-* to be already pre-multiplied. We need to add a knob (or a different
-* DRM_FORMAT) for user-space to configure that.
-*/
case DRM_FORMAT_ABGR:
-   return PLANE_CTL_FORMAT_XRGB_ | PLANE_CTL_ORDER_RGBX |
-   PLANE_CTL_ALPHA_SW_PREMULTIPLY;
+   return PLANE_CTL_FORMAT_XRGB_ | PLANE_CTL_ORDER_RGBX;
case DRM_FORMAT_ARGB:
-   return PLANE_CTL_FORMAT_XRGB_ |
-   PLANE_CTL_ALPHA_SW_PREMULTIPLY;
+   return PLANE_CTL_FORMAT_XRGB_;
case DRM_FORMAT_XRGB2101010:

[Intel-gfx] [RESEND PATCH v3 05/12] drm/i915: Use drm_fb_helper_output_poll_changed()

[Noralf Trønnes]

This driver can use drm_fb_helper_output_poll_changed() as its
.output_poll_changed callback.

Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Signed-off-by: Noralf Trønnes 
Reviewed-by: Daniel Vetter 
---

I'm resending to get a CI run.

Noralf.

 drivers/gpu/drm/i915/intel_display.c | 2 +-
 drivers/gpu/drm/i915/intel_drv.h | 5 -
 drivers/gpu/drm/i915/intel_fbdev.c   | 8 
 3 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index f780f39e0758..b205e2c782bb 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14123,7 +14123,7 @@ static void intel_atomic_state_free(struct 
drm_atomic_state *state)
 static const struct drm_mode_config_funcs intel_mode_funcs = {
.fb_create = intel_user_framebuffer_create,
.get_format_info = intel_get_format_info,
-   .output_poll_changed = intel_fbdev_output_poll_changed,
+   .output_poll_changed = drm_fb_helper_output_poll_changed,
.atomic_check = intel_atomic_check,
.atomic_commit = intel_atomic_commit,
.atomic_state_alloc = intel_atomic_state_alloc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 463ed152e6b1..dfcf5ba220e8 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1607,7 +1607,6 @@ extern void intel_fbdev_initial_config_async(struct 
drm_device *dev);
 extern void intel_fbdev_unregister(struct drm_i915_private *dev_priv);
 extern void intel_fbdev_fini(struct drm_i915_private *dev_priv);
 extern void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool 
synchronous);
-extern void intel_fbdev_output_poll_changed(struct drm_device *dev);
 extern void intel_fbdev_restore_mode(struct drm_device *dev);
 #else
 static inline int intel_fbdev_init(struct drm_device *dev)
@@ -1631,10 +1630,6 @@ static inline void intel_fbdev_set_suspend(struct 
drm_device *dev, int state, bo
 {
 }
 
-static inline void intel_fbdev_output_poll_changed(struct drm_device *dev)
-{
-}
-
 static inline void intel_fbdev_restore_mode(struct drm_device *dev)
 {
 }
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index f2bb8116227c..35babbadfc5a 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -796,14 +796,6 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int 
state, bool synchronous
console_unlock();
 }
 
-void intel_fbdev_output_poll_changed(struct drm_device *dev)
-{
-   struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
-
-   if (ifbdev)
-   drm_fb_helper_hotplug_event(>helper);
-}
-
 void intel_fbdev_restore_mode(struct drm_device *dev)
 {
struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
-- 
2.14.2

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ (rev3)

[Patchwork]

== Series Details ==

Series: drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ (rev3)
URL   : https://patchwork.freedesktop.org/series/33087/
State : failure

== Summary ==

Series 33087v3 drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+
https://patchwork.freedesktop.org/api/1.0/series/33087/revisions/3/mbox/

Test gem_sync:
Subgroup basic-all:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-each:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-many-each:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-store-all:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-store-each:
pass   -> SKIP   (fi-pnv-d510)
Test gem_tiled_blits:
Subgroup basic:
pass   -> SKIP   (fi-pnv-d510)
Test gem_tiled_fence_blits:
Subgroup basic:
pass   -> SKIP   (fi-pnv-d510)
Test gem_wait:
Subgroup basic-busy-all:
pass   -> SKIP   (fi-pnv-d510)
pass   -> FAIL   (fi-glk-dsi)
Subgroup basic-wait-all:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-await-all:
pass   -> SKIP   (fi-pnv-d510)
Test kms_busy:
Subgroup basic-flip-a:
pass   -> SKIP   (fi-pnv-d510)
Subgroup basic-flip-b:
pass   -> SKIP   (fi-pnv-d510)
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-gdg-551) fdo#102618
pass   -> SKIP   (fi-pnv-d510)
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-c:
pass   -> INCOMPLETE (fi-glk-1)

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:440s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:456s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:380s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:543s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:499s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:505s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:506s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:486s
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:551s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:600s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:428s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:263s
fi-glk-1 total:237  pass:210  dwarn:0   dfail:0   fail:0   skip:26 
fi-glk-dsi   total:289  pass:257  dwarn:0   dfail:0   fail:2   skip:30  
time:506s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:433s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:431s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:424s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:492s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:458s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:575s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:479s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:577s
fi-pnv-d510  total:289  pass:209  dwarn:1   dfail:0   fail:0   skip:79  
time:551s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:449s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:598s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:651s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:519s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:504s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:459s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:581s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:420s

4295e1469b2127d79d2d02ef34d065509bdded97 drm-tip: 2017y-11m-06d-15h-35m-57s UTC 
integration manifest
7dce92f9f142 drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6977/
___
Intel-gfx 

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Deconstruct struct sgt_dma initialiser

[Patchwork]

== Series Details ==

Series: drm/i915: Deconstruct struct sgt_dma initialiser
URL   : https://patchwork.freedesktop.org/series/33291/
State : warning

== Summary ==

Series 33291v1 drm/i915: Deconstruct struct sgt_dma initialiser
https://patchwork.freedesktop.org/api/1.0/series/33291/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
fail   -> PASS   (fi-gdg-551) fdo#102618
Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (fi-byt-n2820)

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:447s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:460s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:380s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:552s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:277s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:508s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:513s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:511s
fi-byt-n2820 total:289  pass:248  dwarn:2   dfail:0   fail:0   skip:39  
time:484s
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:561s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:607s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:429s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:262s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:590s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:490s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:435s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:437s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:428s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:504s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:462s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:581s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:481s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:591s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:573s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:465s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:603s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:651s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:522s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:506s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:462s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:575s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:434s

4295e1469b2127d79d2d02ef34d065509bdded97 drm-tip: 2017y-11m-06d-15h-35m-57s UTC 
integration manifest
ad703a5d10bb drm/i915: Deconstruct struct sgt_dma initialiser

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6976/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Deconstruct struct sgt_dma initialiser

[Chris Wilson]

gcc-4.4 complains about:

struct sgt_dma iter = {
.sg = vma->pages->sgl,
.dma = sg_dma_address(iter.sg),
.max = iter.dma + iter.sg->length,
};

drivers/gpu/drm/i915/i915_gem_gtt.c: In function ‘gen8_ppgtt_insert_4lvl’:
drivers/gpu/drm/i915/i915_gem_gtt.c:938: error: ‘iter.sg’ is used uninitialized 
in this function
drivers/gpu/drm/i915/i915_gem_gtt.c:939: error: ‘iter.dma’ is used 
uninitialized in this function

and worse generates invalid code that triggers a GPF:

BUG: unable to handle kernel NULL pointer dereference at 0010
IP: gen8_ppgtt_insert_4lvl+0x1b/0x1e0 [i915]
PGD 0

Oops:  [#1] SMP
Modules linked in: snd_aloop nf_conntrack_ipv6 nf_defrag_ipv6 nf_log_ipv6 
ip6table_filter ip6_tables ctr ccm xt_state nf_log_ipv4
nf_log_common xt_LOG xt_limit xt_recent xt_owner xt_addrtype iptable_filter 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c 
ip_tables dm_mod vhost_net macvtap macvlan vhost tun kvm_intel kvm
irqbypass uas usb_storage hid_multitouch btusb btrtl uvcvideo videobuf2_v4l2 
videobuf2_core videodev media videobuf2_vmalloc videobuf2_memops
sg ppdev dell_wmi sparse_keymap mei_wdt sd_mod iTCO_wdt iTCO_vendor_support 
rtsx_pci_ms memstick rtsx_pci_sdmmc mmc_core dell_smm_hwmon hwmon
dell_laptop dell_smbios dcdbas joydev input_leds hci_uart btintel btqca btbcm 
bluetooth parport_pc parport i2c_hid
  intel_lpss_acpi intel_lpss pcspkr wmi int3400_thermal acpi_thermal_rel 
dell_rbtn mei_me mei snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_codec_generic ahci libahci acpi_pad xhci_pci xhci_hcd snd_hda_intel 
snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device
snd_pcm snd_timer snd soundcore int3403_thermal arc4 e1000e ptp pps_core 
i2c_i801 iwlmvm mac80211 rtsx_pci iwlwifi cfg80211 rfkill
intel_pch_thermal processor_thermal_device int340x_thermal_zone 
intel_soc_dts_iosf i915 video fjes
CPU: 2 PID: 2408 Comm: X Not tainted 4.10.0-rc5+ #1
Hardware name: Dell Inc. Latitude E7470/0T6HHJ, BIOS 1.11.3 11/09/2016
task: 880219fe4740 task.stack: c90005f98000
RIP: 0010:gen8_ppgtt_insert_4lvl+0x1b/0x1e0 [i915]
RSP: 0018:c90005f9b8c8 EFLAGS: 00010246
RAX:  RBX: 8802167d8000 RCX: 0001
RDX: 7000 RSI: 880219f94140 RDI: 880228444000
RBP: c90005f9b948 R08:  R09: 
R10:  R11:  R12: 0080
R13: 0001 R14: c90005f9bcd7 R15: 88020c9a83c0
FS:  7fb53e1ee920() GS:88024dd0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0010 CR3: 00022ef95000 CR4: 003406e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
  ppgtt_bind_vma+0x40/0x50 [i915]
  i915_vma_bind+0xcb/0x1c0 [i915]
  __i915_vma_do_pin+0x6e/0xd0 [i915]
  i915_gem_execbuffer_reserve_vma+0x162/0x1d0 [i915]
  i915_gem_execbuffer_reserve+0x4fc/0x510 [i915]
  ? __kmalloc+0x134/0x250
  ? i915_gem_wait_for_error+0x25/0x100 [i915]
  ? i915_gem_wait_for_error+0x25/0x100 [i915]
  i915_gem_do_execbuffer+0x2df/0xa00 [i915]
  ? drm_malloc_gfp.clone.0+0x42/0x80 [i915]
  ? path_put+0x22/0x30
  ? __check_object_size+0x62/0x1f0
  ? terminate_walk+0x44/0x90
  i915_gem_execbuffer2+0x95/0x1e0 [i915]
  drm_ioctl+0x243/0x490
  ? handle_pte_fault+0x1d7/0x220
  ? i915_gem_do_execbuffer+0xa00/0xa00 [i915]
  ? handle_mm_fault+0x10d/0x2a0
  vfs_ioctl+0x18/0x30
  do_vfs_ioctl+0x14b/0x3f0
  SyS_ioctl+0x92/0xa0
  entry_SYSCALL_64_fastpath+0x1a/0xa9
RIP: 0033:0x7fb53b4fcb77
RSP: 002b:7ffe0c572898 EFLAGS: 3246 ORIG_RAX: 0010
RAX: ffda RBX: 7fb53e17c038 RCX: 7fb53b4fcb77
RDX: 7ffe0c572900 RSI: 40406469 RDI: 000b
RBP: 7fb5376d67e0 R08:  R09: 
R10: 0028 R11: 3246 R12: 
R13:  R14: 55eecb314d00 R15: 55eecb315460
Code: 0f 84 5d ff ff ff eb a2 0f 1f 84 00 00 00 00 00 55 48 89 e5 41 57 41 56 
41 55 41 54 53 48 83 ec 58 0f 1f 44 00 00 31 c0 89 4d b0 <4c>
8b 60 10 44 8b 70 0c 48 89 d0 4c 8b 2e 48 c1 e8 27 25 ff 01
RIP: gen8_ppgtt_insert_4lvl+0x1b/0x1e0 [i915] RSP: c90005f9b8c8
CR2: 0010

Recent gccs, such as 4.9, 6.3 or 7.2, do not generate the warning nor do
they explode on use. If we manually create the struct using locals from
the stack, this should eliminate this issue, and does not alter code
generation with gcc-7.2.

Fixes: 894ccebee2b0 ("drm/i915: Micro-optimise gen8_ppgtt_insert_entries()")
Reported-by: Kelly French 
Signed-off-by: Chris Wilson 
Cc: Kelly French 
Cc: "Mika Kuoppala" 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 25 

Re: [Intel-gfx] [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

[Alex Williamson]

On Mon, 06 Nov 2017 10:05:34 +0100
Gerd Hoffmann  wrote:

>   Hi,
> 
> > > I thought we had agreed to make this behave similar to
> > > VFIO_GROUP_GET_DEVICE_FD, the ioctl would take a __u32 dmabuf_id
> > > and
> > > return the file descriptor as the ioctl return value.  Thanks,  
> > 
> > If we follow VFIO_GROUP_GET_DEVICE_FD, we would lose flags
> > functionality.
> > Zhi and Zhenyu, how do you think about it?  
> 
> The ioctl is simple enough that not having flags should not be a
> problem I think.
> 
> Also note that dmabuf_id is received using the PLANE_INFO ioctl, so
> should the need arise to negotiate something in the future chances are
> high that it can be done using the PLANE_INFO ioctl flags.

Right, the ioctl is "get fd for thing" so we have control of "thing".
I think we had this same discussion on v15.  Thanks,

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: implemented dynamic WOPCM partition.

[Yaodong Li]

On 11/06/2017 12:16 AM, Sagar Arun Kamble wrote:

Please update the subject to "Implement dynamic WOPCM partitioning"
Also, commit description should be written in present tense form.

Will update it in v2.


On 11/4/2017 5:48 AM, Jackie Li wrote:

Static WOPCM partitioning would lead to GuC loading failure
if the GuC/HuC firmware size exceeded current static 512KB
partition boundary.

This patch enabled the dynamical calculation of the WOPCM aperture
used by GuC/HuC firmware. GuC WOPCM offset was set to
HuC size + reserved WOPCM size. GuC WOPCM size was set to
total WOPCM size - GuC WOPCM offset - RC6CTX size.
Could you tell briefly here what is being done to wopcm offset and 
size in this patch.

Will update the description in v2.


Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
Cc: Daniele Ceraolo Spurio 
Cc: John Spotswood 
Cc: Oscar Mateo 
---
  drivers/gpu/drm/i915/i915_drv.c |  15 
  drivers/gpu/drm/i915/i915_drv.h |  13 
  drivers/gpu/drm/i915/i915_gem_context.c |   4 +-
  drivers/gpu/drm/i915/i915_guc_reg.h |  18 -
  drivers/gpu/drm/i915/intel_guc.c    |  46 ++--
  drivers/gpu/drm/i915/intel_guc.h    |  18 +
  drivers/gpu/drm/i915/intel_huc.c    |   3 +-
  drivers/gpu/drm/i915/intel_uc.c | 128 
+++-

  drivers/gpu/drm/i915/intel_uc_fw.c  |  12 ++-
  9 files changed, 223 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c 
b/drivers/gpu/drm/i915/i915_drv.c

index e7e9e06..19509fd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -623,6 +623,15 @@ static void i915_gem_fini(struct 
drm_i915_private *dev_priv)

  WARN_ON(!list_empty(_priv->contexts.list));
  }
  +static void i915_wopcm_init(struct drm_i915_private *dev_priv)
+{
+    struct intel_wopcm_info *wopcm = _priv->wopcm;
+
+    wopcm->size = WOPCM_DEFAULT_SIZE;
+
+    DRM_DEBUG_DRIVER("WOPCM size: %dKB\n", wopcm->size >> 10);
+}
+
  static int i915_load_modeset_init(struct drm_device *dev)
  {
  struct drm_i915_private *dev_priv = to_i915(dev);
@@ -670,6 +679,12 @@ static int i915_load_modeset_init(struct 
drm_device *dev)

  if (ret)
  goto cleanup_irq;
  +    /*
+ * Get the wopcm memory info.
+ * NOTE: this need to be called before init FW.
+ */
+    i915_wopcm_init(dev_priv);
+
I think this call might be better if done from 
i915_driver_init_hw->i915_ggtt_probe_hw->*_gmch_probe after
gem_init_stolen as this is part of stolen memory. Might help 
performing any validation w.r.t stolen memory alloc.
I am planing the reuse the info from stolen init to create the 
description in a separate patch. Likely, I will move it
right after gem_init_stolen, or make it as a part of stolen init, or 
even drop this data structure completely.

  intel_uc_init_fw(dev_priv);
    ret = i915_gem_init(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h

index 72bb5b5..61cd290 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2235,6 +2235,16 @@ struct intel_cdclk_state {
  u8 voltage_level;
  };
  +struct intel_wopcm_info {
+    u32 size;
+};
+
+struct intel_wopcm_partition {
+    u32 guc_wopcm_offset;
+    u32 guc_wopcm_size;
+    u32 guc_wopcm_top;
+};
+
*_partition can become part of *_info. This can be named as 
intel_guc_wopcm_partition and drop "guc_" prefix from variable names.
intel_wopcm_info was used for description of overall wopcm info while 
intel_wopcm_partition is about how we do the partition and it's guc
related. I agree that we can rename it to intel_guc_wopcm_partition and 
remove "guc_" prefix. but I think it makes sense keep them as
separated structures since intel_wopcm_info will be updated to reuse 
info from stolen init.

  struct drm_i915_private {
  struct drm_device drm;
  @@ -2258,6 +2268,9 @@ struct drm_i915_private {
  struct intel_huc huc;
  struct intel_guc guc;
  +    struct intel_wopcm_info wopcm;
+    struct intel_wopcm_partition wopcm_partition;
+
  struct intel_csr csr;
    struct intel_gmbus gmbus[GMBUS_NUM_PINS];
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c

index 10affb3..7347fd7 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -312,12 +312,12 @@ __create_hw_context(struct drm_i915_private 
*dev_priv,

  ctx->desc_template =
  default_desc_template(dev_priv, dev_priv->mm.aliasing_ppgtt);
  -    /* GuC requires the ring to be placed above GUC_WOPCM_TOP. If 
GuC is not
+    /* GuC requires the ring to be placed above guc wopcm top. If 
GuC is not
   * present or not in use we 

Re: [Intel-gfx] [PATCH i-g-t v2 RESEND] tests/kms_fbcon_fbt: Report fbc_status on error

[Paulo Zanoni]

Em Seg, 2017-11-06 às 16:16 -0200, Gabriel Krisman Bertazi escreveu:
> Paulo Zanoni  writes:
> 
> > Em Seg, 2017-10-30 às 15:54 -0200, Gabriel Krisman Bertazi
> > escreveu:
> > > knowing the assertion triggered on wait_until_enabled() is not
> > > that
> > > useful without knowing what exactly caused the failure.  It might
> > > be
> > > an
> > > user error, like too little stolen memory by the bios, or an
> > > actual
> > > issue in the kernel.  So, let's make life easier, particularly
> > > for
> > > the
> > > CI, by printing the status before failing out.
> > > 
> > > Case in point:
> > > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101718
> > > 
> > > Signed-off-by: Gabriel Krisman Bertazi 
> > > ---
> > >  tests/kms_fbcon_fbt.c | 24 ++--
> > >  1 file changed, 22 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/tests/kms_fbcon_fbt.c b/tests/kms_fbcon_fbt.c
> > > index d0090912694e..8371be5612f5 100644
> > > --- a/tests/kms_fbcon_fbt.c
> > > +++ b/tests/kms_fbcon_fbt.c
> > > @@ -95,6 +95,14 @@ static bool
> > > connector_can_fbc(drmModeConnectorPtr
> > > connector)
> > >   return true;
> > >  }
> > >  
> > > +static void fbc_print_status(int fd)
> > > +{
> > > + static char buf[128];
> > > +
> > > + igt_debugfs_read(fd, "i915_fbc_status", buf);
> > > + igt_debug("FBC status: %s\n", buf);
> > > +}
> > > +
> > >  static bool fbc_is_enabled(int fd)
> > >  {
> > >   char buf[128];
> > > @@ -105,7 +113,9 @@ static bool fbc_is_enabled(int fd)
> > >  
> > >  static bool fbc_wait_until_enabled(int fd)
> > >  {
> > > - return igt_wait(fbc_is_enabled(fd), 5000, 1);
> > > + bool r = igt_wait(fbc_is_enabled(fd), 5000, 1);
> > > + fbc_print_status(fd);
> > > + return r;
> > >  }
> > >  
> > >  typedef bool (*connector_possible_fn)(drmModeConnectorPtr
> > > connector);
> > > @@ -160,6 +170,14 @@ static bool
> > > connector_can_psr(drmModeConnectorPtr connector)
> > >   return (connector->connector_type ==
> > > DRM_MODE_CONNECTOR_eDP);
> > >  }
> > >  
> > > +static void psr_print_status(int fd)
> > > +{
> > > + static char buf[256];
> > > +
> > > + igt_debugfs_read(fd, "i915_edp_psr_status", buf);
> > > + igt_debug("FBC status: %s\n", buf);
> > 
> > s/FBC/PSR/
> 
> Oops!
> 
> > 
> > With that fixed:
> > Reviewed-by: Paulo Zanoni 
> 
> Hi Paulo,
> 
> Thanks for your review.  Can you push the version below, then?  I
> don't
> have commit rights on igt.

Pushed. Thanks for the patch!

> 
> > 8
> 
> Subject: [PATCH i-g-t] tests/kms_fbcon_fbt: Report fbc_status on
> error
> 
> knowing the assertion triggered on wait_until_enabled() is not that
> useful without knowing what exactly caused the failure.  It might be
> an
> user error, like too little stolen memory by the bios, or an actual
> issue in the kernel.  So, let's make life easier, particularly for
> the
> CI, by printing the status before failing out.
> 
> Case in point:
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101718
> 
> Signed-off-by: Gabriel Krisman Bertazi 
> Reviewed-by: Paulo Zanoni 
> ---
>  tests/kms_fbcon_fbt.c | 24 ++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/kms_fbcon_fbt.c b/tests/kms_fbcon_fbt.c
> index d0090912694e..51f1172839ed 100644
> --- a/tests/kms_fbcon_fbt.c
> +++ b/tests/kms_fbcon_fbt.c
> @@ -95,6 +95,14 @@ static bool connector_can_fbc(drmModeConnectorPtr
> connector)
>   return true;
>  }
>  
> +static void fbc_print_status(int fd)
> +{
> + static char buf[128];
> +
> + igt_debugfs_read(fd, "i915_fbc_status", buf);
> + igt_debug("FBC status: %s\n", buf);
> +}
> +
>  static bool fbc_is_enabled(int fd)
>  {
>   char buf[128];
> @@ -105,7 +113,9 @@ static bool fbc_is_enabled(int fd)
>  
>  static bool fbc_wait_until_enabled(int fd)
>  {
> - return igt_wait(fbc_is_enabled(fd), 5000, 1);
> + bool r = igt_wait(fbc_is_enabled(fd), 5000, 1);
> + fbc_print_status(fd);
> + return r;
>  }
>  
>  typedef bool (*connector_possible_fn)(drmModeConnectorPtr
> connector);
> @@ -160,6 +170,14 @@ static bool
> connector_can_psr(drmModeConnectorPtr connector)
>   return (connector->connector_type ==
> DRM_MODE_CONNECTOR_eDP);
>  }
>  
> +static void psr_print_status(int fd)
> +{
> + static char buf[256];
> +
> + igt_debugfs_read(fd, "i915_edp_psr_status", buf);
> + igt_debug("PSR status: %s\n", buf);
> +}
> +
>  static bool psr_is_enabled(int fd)
>  {
>   char buf[256];
> @@ -170,7 +188,9 @@ static bool psr_is_enabled(int fd)
>  
>  static bool psr_wait_until_enabled(int fd)
>  {
> - return igt_wait(psr_is_enabled(fd), 5000, 1);
> + bool r = igt_wait(psr_is_enabled(fd), 5000, 1);
> + psr_print_status(fd);
> + return r;
>  }
>  
>  struct feature {
___
Intel-gfx mailing list

[Intel-gfx] ✓ Fi.CI.IGT: success for tests/kms_plane_scaling: Fix off-by-one plane selection

[Patchwork]

== Series Details ==

Series: tests/kms_plane_scaling: Fix off-by-one plane selection
URL   : https://patchwork.freedesktop.org/series/33277/
State : success

== Summary ==

Test kms_flip:
Subgroup dpms-vs-vblank-race-interruptible:
fail   -> PASS   (shard-hsw) fdo#103060
Subgroup vblank-vs-suspend:
fail   -> PASS   (shard-hsw) fdo#103375
Subgroup wf_vblank-vs-dpms:
incomplete -> PASS   (shard-hsw) fdo#102614
Test kms_plane_lowres:
Subgroup pipe-b-tiling-none:
dmesg-warn -> PASS   (shard-hsw)
Test kms_busy:
Subgroup extended-modeset-hang-newfb-with-reset-render-c:
pass   -> DMESG-WARN (shard-hsw) fdo#102249 +1
Subgroup extended-modeset-hang-newfb-with-reset-render-b:
pass   -> DMESG-WARN (shard-hsw) fdo#103038
Test kms_setmode:
Subgroup basic:
fail   -> PASS   (shard-hsw) fdo#99912

fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060
fdo#103375 https://bugs.freedesktop.org/show_bug.cgi?id=103375
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#102249 https://bugs.freedesktop.org/show_bug.cgi?id=102249
fdo#103038 https://bugs.freedesktop.org/show_bug.cgi?id=103038
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912

shard-hswtotal:2540 pass:1432 dwarn:2   dfail:0   fail:9   skip:1097 
time:9283s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_478/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 04/20] drm/i915: Transform context WAs into static tables

[Oscar Mateo]

On 11/06/2017 03:59 AM, Joonas Lahtinen wrote:

On Fri, 2017-11-03 at 11:09 -0700, Oscar Mateo wrote:

This is for WAs that need to touch registers that get saved/restored
together with the logical context. The idea is that WAs are "pretty"
static, so a table is more declarative than a programmatic approah.
Note however that some amount is caching is needed for those things
that are dynamic (e.g. things that need some calculation, or have
a criteria different than the more obvious GEN + stepping).

Also, this makes very explicit which WAs live in the context.

Suggested-by: Joonas Lahtinen 
Signed-off-by: Oscar Mateo 
Cc: Chris Wilson 
Cc: Mika Kuoppala 




+struct i915_wa_reg;
+
+typedef bool (* wa_pre_hook_func)(struct drm_i915_private *dev_priv,
+ struct i915_wa_reg *wa);
+typedef void (* wa_post_hook_func)(struct drm_i915_private *dev_priv,
+  struct i915_wa_reg *wa);

To avoid carrying any variables over, how about just apply() hook?
Also, you don't have to have "_hook" going there, it's tak



Not all WAs are applied in the same way: ctx-style workarounds are 
emitted as LRI commands to the ring. Do you treat those differently?



  struct i915_wa_reg {
+   const char *name;

We may want some Kconfig option for skipping these.


Sure. But we should try to decide first if we want to store this at all, 
like: what do we expect to use this for? is it worth it?



+   enum wa_type {
+   I915_WA_TYPE_CONTEXT = 0,
+   I915_WA_TYPE_GT,
+   I915_WA_TYPE_DISPLAY,
+   I915_WA_TYPE_WHITELIST
+   } type;
+

Any specific reason not to have the gen here too? Then you can have one
big table, instead of tables of tables. Then the numeric code of a WA
(position in that table) would be equally identifying it compared to
the WA name (which is nice to have information, so config time opt-in).


Such a "big table" would be quite big, indeed. And we know we want to 
apply the workarounds from at least four different places, so looping 
through the table each and every time to find the relevant WAs seems 
like a waste. Also, in some places we would have to loop more than once 
( to know the number of WAs to apply before we can reserve space in the 
ring for ctx-style WAs, for example).


I could also go for 4 slightly smaller tables (one per type of WA) but 
then there is another problem to solve: how do you record WAs that apply 
for all revisions of one GEN, but a smaller number of revisions of 
another? (e.g. WaDisableFenceDestinationToSLM applies to all BDW 
steppings but only KBL A0).



+   u8 since;
+   u8 until;

Most seem to have ALL_REVS, so this could be after the coarse-grained
gen-check in the apply function.


So every single WA that applies to specific REVS gets an "apply" 
function? That looks like a lot of functions (I count 25 WAs that only 
apply to some steppings already). Or are you simply saying here that I 
check the GEN before checking the stepping (which is the only order that 
makes sense anyway)?



+
i915_reg_t addr;
-   u32 value;
-   /* bitmask representing WA bits */
u32 mask;
+   u32 value;
+   bool is_masked_reg;

I'd hide this detail into the apply function.


I see. But if you don't store the mask: what do you output in debugfs?




+
+   wa_pre_hook_func pre_hook;
+   wa_post_hook_func post_hook;

bool (*apply)(const struct i915_wa *wa,
  struct drm_i915_private *dev_priv);


+   u32 hook_data;
+   bool applied;

The big point would be to make this into const, so "applied" would
defeat that.


Yeah, I realized. Keeping a separate bitmask of which WAs have been 
applied is not a big deal, but then I became aware that there are many 
more things that would need to be cached. For example, some WAs require 
to compute the actual value you write into their register. What do you 
do with those? (remember that you still want to print the expected value 
in debugfs for these).






+#define MASK(mask, value)  ((mask) << 16 | (value))
+#define MASK_ENABLE(x) (MASK((x), (x)))
+#define MASK_DISABLE(x)(MASK((x), 0))
  
-#define WA_REG(addr, mask, val) do { \

-   const int r = wa_add(dev_priv, (addr), (mask), (val)); \
-   if (r) \
-   return r; \
-   } while (0)
+#define SET_BIT_MASKED(m)  \
+   .mask = (m),\
+   .value = MASK_ENABLE(m),\
+   .is_masked_reg = true
  
-#define WA_SET_BIT_MASKED(addr, mask) \

-   WA_REG(addr, (mask), _MASKED_BIT_ENABLE(mask))
+#define CLEAR_BIT_MASKED( m)   \
+   .mask = (m),\
+   .value = MASK_DISABLE(m),   \
+   .is_masked_reg = true
  
-#define WA_CLR_BIT_MASKED(addr, 

[Intel-gfx] ✓ Fi.CI.BAT: success for tests/kms_plane_scaling: Fix off-by-one plane selection

[Patchwork]

== Series Details ==

Series: tests/kms_plane_scaling: Fix off-by-one plane selection
URL   : https://patchwork.freedesktop.org/series/33277/
State : success

== Summary ==

IGT patchset tested on top of latest successful build
b9f2abda9503bd55690cf3c2ccf2f20e8fc19ab3 tests/gem_eio: Nerf in-flight-suspend

with latest DRM-Tip kernel build CI_DRM_3316
7210ac064da2 drm-tip: 2017y-11m-06d-14h-42m-36s UTC integration manifest

No testlist changes.

Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> DMESG-WARN (fi-bdw-5557u) fdo#102473
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-kbl-7560u) fdo#102846

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

fi-bdw-5557u total:289  pass:267  dwarn:1   dfail:0   fail:0   skip:21  
time:450s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:459s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:387s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:546s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:278s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:506s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:509s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:513s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:496s
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:567s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:632s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:433s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:265s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:588s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:497s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:431s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:432s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:434s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:502s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:459s
fi-kbl-7560u total:245  pass:228  dwarn:0   dfail:0   fail:0   skip:16 
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:485s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:581s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:579s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:596s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:653s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:528s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:507s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:460s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:574s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:432s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_478/
___
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/kms_plane_scaling: Fix off-by-one plane selection

[Robert Foss]

Hey Gabriel,

I've reviewed and pushed this patch.
Thanks.


Rob.
On Mon, 2017-11-06 at 16:28 -0200, Gabriel Krisman Bertazi wrote:
> Commit ca20170afc6f ("tests/kms_plane_scaling: Add support for
> dynamic
> number of planes") shifted the tested planes by one after the
> refactoring, accidentally ignoring the first plane, which is zero
> indexed.  A symptom of the issue appears on KBL, where the third
> plane
> is already the shared cursor, causing igt to configure an unsupported
> framebuffer format on it, triggering the following error:
> 
> [drm:__setplane_internal] Invalid pixel format XR24 little-endian
> (0x34325258)
> 
> With this fixed, we can exposes the pixel clock scaling issue, which
> is
> the actual problem being tracked in Bug 103159, but let's start by
> reverting to the old behavior.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103159
> Fixes: ca20170afc6f ("tests/kms_plane_scaling: Add support for
> dynamic number of planes")
> Signed-off-by: Gabriel Krisman Bertazi 
> ---
>  tests/kms_plane_scaling.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/kms_plane_scaling.c b/tests/kms_plane_scaling.c
> index 5ed69f35f267..403df47e2d3b 100644
> --- a/tests/kms_plane_scaling.c
> +++ b/tests/kms_plane_scaling.c
> @@ -195,7 +195,7 @@ static void test_plane_scaling(data_t *d)
>   igt_assert(d->fb_id3);
>  
>   /* Set up display with plane 1 */
> - d->plane1 = igt_output_get_plane(output, 1);
> + d->plane1 = igt_output_get_plane(output, 0);
>   prepare_crtc(d, output, pipe, d->plane1, mode,
> COMMIT_UNIVERSAL);
>  
>   if (primary_plane_scaling) {
> @@ -215,7 +215,7 @@ static void test_plane_scaling(data_t *d)
>   }
>  
>   /* Set up fb2->plane2 mapping. */
> - d->plane2 = igt_output_get_plane(output, 2);
> + d->plane2 = igt_output_get_plane(output, 1);
>   igt_plane_set_fb(d->plane2, >fb2);
>  
>   /* 2nd plane windowed */
> @@ -251,7 +251,7 @@ static void test_plane_scaling(data_t *d)
>   }
>  
>   /* Set up fb3->plane3 mapping. */
> - d->plane3 = igt_output_get_plane(output, 3);
> + d->plane3 = igt_output_get_plane(output, 2);
>   igt_plane_set_fb(d->plane3, >fb3);
>  
>   /* 3rd plane windowed - no scaling */

signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] tests/kms_plane_scaling: Fix off-by-one plane selection

[Gabriel Krisman Bertazi]

Commit ca20170afc6f ("tests/kms_plane_scaling: Add support for dynamic
number of planes") shifted the tested planes by one after the
refactoring, accidentally ignoring the first plane, which is zero
indexed.  A symptom of the issue appears on KBL, where the third plane
is already the shared cursor, causing igt to configure an unsupported
framebuffer format on it, triggering the following error:

[drm:__setplane_internal] Invalid pixel format XR24 little-endian (0x34325258)

With this fixed, we can exposes the pixel clock scaling issue, which is
the actual problem being tracked in Bug 103159, but let's start by
reverting to the old behavior.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103159
Fixes: ca20170afc6f ("tests/kms_plane_scaling: Add support for dynamic number 
of planes")
Signed-off-by: Gabriel Krisman Bertazi 
---
 tests/kms_plane_scaling.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tests/kms_plane_scaling.c b/tests/kms_plane_scaling.c
index 5ed69f35f267..403df47e2d3b 100644
--- a/tests/kms_plane_scaling.c
+++ b/tests/kms_plane_scaling.c
@@ -195,7 +195,7 @@ static void test_plane_scaling(data_t *d)
igt_assert(d->fb_id3);
 
/* Set up display with plane 1 */
-   d->plane1 = igt_output_get_plane(output, 1);
+   d->plane1 = igt_output_get_plane(output, 0);
prepare_crtc(d, output, pipe, d->plane1, mode, 
COMMIT_UNIVERSAL);
 
if (primary_plane_scaling) {
@@ -215,7 +215,7 @@ static void test_plane_scaling(data_t *d)
}
 
/* Set up fb2->plane2 mapping. */
-   d->plane2 = igt_output_get_plane(output, 2);
+   d->plane2 = igt_output_get_plane(output, 1);
igt_plane_set_fb(d->plane2, >fb2);
 
/* 2nd plane windowed */
@@ -251,7 +251,7 @@ static void test_plane_scaling(data_t *d)
}
 
/* Set up fb3->plane3 mapping. */
-   d->plane3 = igt_output_get_plane(output, 3);
+   d->plane3 = igt_output_get_plane(output, 2);
igt_plane_set_fb(d->plane3, >fb3);
 
/* 3rd plane windowed - no scaling */
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: implemented dynamic WOPCM partition.

[Yaodong Li]

On 11/06/2017 05:24 AM, Ville Syrjälä wrote:

On Fri, Nov 03, 2017 at 05:01:09PM -0700, Jackie Li wrote:

Static WOPCM partitioning would lead to GuC loading failure
if the GuC/HuC firmware size exceeded current static 512KB
partition boundary.

This patch enabled the dynamical calculation of the WOPCM aperture
used by GuC/HuC firmware. GuC WOPCM offset was set to
HuC size + reserved WOPCM size. GuC WOPCM size was set to
total WOPCM size - GuC WOPCM offset - RC6CTX size.

Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
Reviewed-by: Daniele Ceraolo Spurio 
Reviewed-by: John Spotswood 
Reviewed-by: Oscar Mateo 
---
  drivers/gpu/drm/i915/i915_drv.c |  15 
  drivers/gpu/drm/i915/i915_drv.h |  13 
  drivers/gpu/drm/i915/i915_gem_context.c |   4 +-
  drivers/gpu/drm/i915/i915_guc_reg.h |  18 -
  drivers/gpu/drm/i915/intel_guc.c|  46 ++--
  drivers/gpu/drm/i915/intel_guc.h|  18 +
  drivers/gpu/drm/i915/intel_huc.c|   3 +-
  drivers/gpu/drm/i915/intel_uc.c | 128 +++-
  drivers/gpu/drm/i915/intel_uc_fw.c  |  12 ++-
  9 files changed, 223 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e7e9e06..19509fd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -623,6 +623,15 @@ static void i915_gem_fini(struct drm_i915_private 
*dev_priv)
WARN_ON(!list_empty(_priv->contexts.list));
  }
  
+static void i915_wopcm_init(struct drm_i915_private *dev_priv)

+{
+   struct intel_wopcm_info *wopcm = _priv->wopcm;
+
+   wopcm->size = WOPCM_DEFAULT_SIZE;
+
+   DRM_DEBUG_DRIVER("WOPCM size: %dKB\n", wopcm->size >> 10);
+}
+
  static int i915_load_modeset_init(struct drm_device *dev)
  {
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -670,6 +679,12 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_irq;
  
+	/*

+* Get the wopcm memory info.
+* NOTE: this need to be called before init FW.
+*/
+   i915_wopcm_init(dev_priv);

Is this guc wopcm somehow related to the normal wopcm? And if so
are you planning to use the wopcm information we extract from the
hardware in stolen init? If this is just related to the guc then
it would seem better to bury this in some guc code.

Thanks for the comments. Yes. I am planning to reuse these
information from stolen init to create an description of overall wopcm info.
the guc related use of wopcm was encapsulated in intel_wopcm_partition.
The reason I put the initialization code here is that we are doing
a size check against the wopcm size during intel_uc_fw_fetch (so
that we won't waste time to create a gem object for a firmware object
whose size is larger than wopcm size) and we also need to guarantee the
wopcm info are available before the creation of the kernel gem context
since we need place the gem context above wopcm when guc is active.

+
intel_uc_init_fw(dev_priv);
  
  	ret = i915_gem_init(dev_priv);


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

Re: [Intel-gfx] [PATCH i-g-t v2 RESEND] tests/kms_fbcon_fbt: Report fbc_status on error

[Gabriel Krisman Bertazi]

Paulo Zanoni  writes:

> Em Seg, 2017-10-30 às 15:54 -0200, Gabriel Krisman Bertazi escreveu:
>> knowing the assertion triggered on wait_until_enabled() is not that
>> useful without knowing what exactly caused the failure.  It might be
>> an
>> user error, like too little stolen memory by the bios, or an actual
>> issue in the kernel.  So, let's make life easier, particularly for
>> the
>> CI, by printing the status before failing out.
>> 
>> Case in point:
>> 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101718
>> 
>> Signed-off-by: Gabriel Krisman Bertazi 
>> ---
>>  tests/kms_fbcon_fbt.c | 24 ++--
>>  1 file changed, 22 insertions(+), 2 deletions(-)
>> 
>> diff --git a/tests/kms_fbcon_fbt.c b/tests/kms_fbcon_fbt.c
>> index d0090912694e..8371be5612f5 100644
>> --- a/tests/kms_fbcon_fbt.c
>> +++ b/tests/kms_fbcon_fbt.c
>> @@ -95,6 +95,14 @@ static bool connector_can_fbc(drmModeConnectorPtr
>> connector)
>>  return true;
>>  }
>>  
>> +static void fbc_print_status(int fd)
>> +{
>> +static char buf[128];
>> +
>> +igt_debugfs_read(fd, "i915_fbc_status", buf);
>> +igt_debug("FBC status: %s\n", buf);
>> +}
>> +
>>  static bool fbc_is_enabled(int fd)
>>  {
>>  char buf[128];
>> @@ -105,7 +113,9 @@ static bool fbc_is_enabled(int fd)
>>  
>>  static bool fbc_wait_until_enabled(int fd)
>>  {
>> -return igt_wait(fbc_is_enabled(fd), 5000, 1);
>> +bool r = igt_wait(fbc_is_enabled(fd), 5000, 1);
>> +fbc_print_status(fd);
>> +return r;
>>  }
>>  
>>  typedef bool (*connector_possible_fn)(drmModeConnectorPtr
>> connector);
>> @@ -160,6 +170,14 @@ static bool
>> connector_can_psr(drmModeConnectorPtr connector)
>>  return (connector->connector_type ==
>> DRM_MODE_CONNECTOR_eDP);
>>  }
>>  
>> +static void psr_print_status(int fd)
>> +{
>> +static char buf[256];
>> +
>> +igt_debugfs_read(fd, "i915_edp_psr_status", buf);
>> +igt_debug("FBC status: %s\n", buf);
>
> s/FBC/PSR/

Oops!

>
> With that fixed:
> Reviewed-by: Paulo Zanoni 

Hi Paulo,

Thanks for your review.  Can you push the version below, then?  I don't
have commit rights on igt.

>8
Subject: [PATCH i-g-t] tests/kms_fbcon_fbt: Report fbc_status on error

knowing the assertion triggered on wait_until_enabled() is not that
useful without knowing what exactly caused the failure.  It might be an
user error, like too little stolen memory by the bios, or an actual
issue in the kernel.  So, let's make life easier, particularly for the
CI, by printing the status before failing out.

Case in point:

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101718

Signed-off-by: Gabriel Krisman Bertazi 
Reviewed-by: Paulo Zanoni 
---
 tests/kms_fbcon_fbt.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/tests/kms_fbcon_fbt.c b/tests/kms_fbcon_fbt.c
index d0090912694e..51f1172839ed 100644
--- a/tests/kms_fbcon_fbt.c
+++ b/tests/kms_fbcon_fbt.c
@@ -95,6 +95,14 @@ static bool connector_can_fbc(drmModeConnectorPtr connector)
return true;
 }
 
+static void fbc_print_status(int fd)
+{
+   static char buf[128];
+
+   igt_debugfs_read(fd, "i915_fbc_status", buf);
+   igt_debug("FBC status: %s\n", buf);
+}
+
 static bool fbc_is_enabled(int fd)
 {
char buf[128];
@@ -105,7 +113,9 @@ static bool fbc_is_enabled(int fd)
 
 static bool fbc_wait_until_enabled(int fd)
 {
-   return igt_wait(fbc_is_enabled(fd), 5000, 1);
+   bool r = igt_wait(fbc_is_enabled(fd), 5000, 1);
+   fbc_print_status(fd);
+   return r;
 }
 
 typedef bool (*connector_possible_fn)(drmModeConnectorPtr connector);
@@ -160,6 +170,14 @@ static bool connector_can_psr(drmModeConnectorPtr 
connector)
return (connector->connector_type == DRM_MODE_CONNECTOR_eDP);
 }
 
+static void psr_print_status(int fd)
+{
+   static char buf[256];
+
+   igt_debugfs_read(fd, "i915_edp_psr_status", buf);
+   igt_debug("PSR status: %s\n", buf);
+}
+
 static bool psr_is_enabled(int fd)
 {
char buf[256];
@@ -170,7 +188,9 @@ static bool psr_is_enabled(int fd)
 
 static bool psr_wait_until_enabled(int fd)
 {
-   return igt_wait(psr_is_enabled(fd), 5000, 1);
+   bool r = igt_wait(psr_is_enabled(fd), 5000, 1);
+   psr_print_status(fd);
+   return r;
 }
 
 struct feature {
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH 3/5] drm/vmwgfx: Try to fix plane clipping

[Ville Syrjälä]

On Thu, Nov 02, 2017 at 03:19:30PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 02, 2017 at 11:12:09AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 01, 2017 at 08:29:18PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä 
> > > 
> > > Try to fix the code to actually clip the plane to the crtc bounds
> > > instead of the user provided crtc coordinates (which would be a no-op
> > > since those are exactly the coordinates before clipping).
> > > 
> > > Cc: VMware Graphics 
> > > Cc: Sinclair Yeh 
> > > Cc: Thomas Hellstrom 
> > > Signed-off-by: Ville Syrjälä 
> > 
> > I kinda wonder whether we shouldn't push this down into the helper ...
> 
> Would require quite going through all drivers making sure they are
> happy with using the adjusted_mode.crtc_ timings. I think most drivers
> use the other adjusted_mode timings currently, and some even use the
> user mode timings (which could be an actual bug).

Let me take that back. What we want is to clip to the user mode
timings. Stereo 3D needs the special treatment from
drm_mode_get_hv_timing(). I'm getting confused by all these
different timings we have all over the place.

I think for i915 all we would need is to change the double wide/dual
link adjustent for pipe_src_w to simply reject odd widths instead.
That would guarantee that the user mode timings match the pipe_src_w/h
100%.

For the other driver we'd need to figure out why they're using
adjusted_mode timings for clipping. I guess that's just a mistake,
which I repeated here with vmwgfx after getting confused by looking
at the other drivers.

I guess I just volunteered myself to do this. Just needs plenty of
acks from driver maintainers I suppose.

> 
> > 
> > Either way, Reviewed-by: Daniel Vetter 
> > 
> > > ---
> > >  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 23 +--
> > >  1 file changed, 13 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
> > > b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > index 515b67783a41..efa41c086198 100644
> > > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> > > @@ -441,20 +441,23 @@ vmw_du_cursor_plane_atomic_update(struct drm_plane 
> > > *plane,
> > >  int vmw_du_primary_plane_atomic_check(struct drm_plane *plane,
> > > struct drm_plane_state *state)
> > >  {
> > > + struct drm_crtc_state *crtc_state = NULL;
> > >   struct drm_framebuffer *new_fb = state->fb;
> > > - struct drm_rect clip = {
> > > - .x1 = state->crtc_x,
> > > - .y1 = state->crtc_y,
> > > - .x2 = state->crtc_x + state->crtc_w,
> > > - .y2 = state->crtc_y + state->crtc_h,
> > > - };
> > > + struct drm_rect clip = {};
> > >   int ret;
> > >  
> > > - ret = drm_plane_helper_check_state(state, ,
> > > - DRM_PLANE_HELPER_NO_SCALING,
> > > - DRM_PLANE_HELPER_NO_SCALING,
> > > - false, true);
> > > + if (state->crtc)
> > > + crtc_state = drm_atomic_get_new_crtc_state(state->state, 
> > > state->crtc);
> > >  
> > > + if (crtc_state && crtc_state->enable) {
> > > + clip.x2 = crtc_state->adjusted_mode.hdisplay;
> > > + clip.y2 = crtc_state->adjusted_mode.vdisplay;
> > > + }
> > > +
> > > + ret = drm_plane_helper_check_state(state, ,
> > > +DRM_PLANE_HELPER_NO_SCALING,
> > > +DRM_PLANE_HELPER_NO_SCALING,
> > > +false, true);
> > >  
> > >   if (!ret && new_fb) {
> > >   struct drm_crtc *crtc = state->crtc;
> > > -- 
> > > 2.13.6
> > > 
> > > ___
> > > 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
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> 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 v2 RESEND] tests/kms_fbcon_fbt: Report fbc_status on error

[Paulo Zanoni]

Em Seg, 2017-10-30 às 15:54 -0200, Gabriel Krisman Bertazi escreveu:
> knowing the assertion triggered on wait_until_enabled() is not that
> useful without knowing what exactly caused the failure.  It might be
> an
> user error, like too little stolen memory by the bios, or an actual
> issue in the kernel.  So, let's make life easier, particularly for
> the
> CI, by printing the status before failing out.
> 
> Case in point:
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101718
> 
> Signed-off-by: Gabriel Krisman Bertazi 
> ---
>  tests/kms_fbcon_fbt.c | 24 ++--
>  1 file changed, 22 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/kms_fbcon_fbt.c b/tests/kms_fbcon_fbt.c
> index d0090912694e..8371be5612f5 100644
> --- a/tests/kms_fbcon_fbt.c
> +++ b/tests/kms_fbcon_fbt.c
> @@ -95,6 +95,14 @@ static bool connector_can_fbc(drmModeConnectorPtr
> connector)
>   return true;
>  }
>  
> +static void fbc_print_status(int fd)
> +{
> + static char buf[128];
> +
> + igt_debugfs_read(fd, "i915_fbc_status", buf);
> + igt_debug("FBC status: %s\n", buf);
> +}
> +
>  static bool fbc_is_enabled(int fd)
>  {
>   char buf[128];
> @@ -105,7 +113,9 @@ static bool fbc_is_enabled(int fd)
>  
>  static bool fbc_wait_until_enabled(int fd)
>  {
> - return igt_wait(fbc_is_enabled(fd), 5000, 1);
> + bool r = igt_wait(fbc_is_enabled(fd), 5000, 1);
> + fbc_print_status(fd);
> + return r;
>  }
>  
>  typedef bool (*connector_possible_fn)(drmModeConnectorPtr
> connector);
> @@ -160,6 +170,14 @@ static bool
> connector_can_psr(drmModeConnectorPtr connector)
>   return (connector->connector_type ==
> DRM_MODE_CONNECTOR_eDP);
>  }
>  
> +static void psr_print_status(int fd)
> +{
> + static char buf[256];
> +
> + igt_debugfs_read(fd, "i915_edp_psr_status", buf);
> + igt_debug("FBC status: %s\n", buf);

s/FBC/PSR/

With that fixed:
Reviewed-by: Paulo Zanoni 



> +}
> +
>  static bool psr_is_enabled(int fd)
>  {
>   char buf[256];
> @@ -170,7 +188,9 @@ static bool psr_is_enabled(int fd)
>  
>  static bool psr_wait_until_enabled(int fd)
>  {
> - return igt_wait(psr_is_enabled(fd), 5000, 1);
> + bool r = igt_wait(psr_is_enabled(fd), 5000, 1);
> + psr_print_status(fd);
> + return r;
>  }
>  
>  struct feature {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

[Ville Syrjälä]

On Mon, Nov 06, 2017 at 04:43:17PM +0100, Maarten Lankhorst wrote:
> Op 06-11-17 om 15:06 schreef Ville Syrjälä:
> > On Mon, Nov 06, 2017 at 04:01:20PM +0200, Ville Syrjälä wrote:
> >> On Thu, Nov 02, 2017 at 09:55:40AM +0100, Maarten Lankhorst wrote:
> >>> Op 01-11-17 om 18:00 schreef Ville Syrjälä:
>  On Wed, Nov 01, 2017 at 04:55:06PM +0100, Maarten Lankhorst wrote:
> > Op 01-11-17 om 16:29 schreef Ville Syrjälä:
> >> On Wed, Nov 01, 2017 at 04:04:33PM +0100, Maarten Lankhorst wrote:
> >>> This introduces a slight behavioral change to rmfb. Instead of
> >>> disabling a crtc when the primary plane is disabled, we try to
> >>> preserve it.
> >>>
> >>> Apart from old versions of the vmwgfx xorg driver, there is
> >>> nothing depending on rmfb disabling a crtc.
> >>>
> >>> Vmwgfx' and simple kms helper atomic implementation rejects CRTC
> >>> enabled without plane, so we can do this safely.
>  The code for those seems a bit inconsistent. The crtc check requires
>  that the crtc state and plane state match. But the plane check allows
>  the plane to be enabled w/o the crtc being enabled. I guess it doesn't
>  matter really since you can't enable the plane without a crtc, and the
>  crtc check would then catch the case where the crtc would be disabled.
> >>> Exactly. :-) Only when a plane is unbound and stays unbound, the crtc 
> >>> check won't
> >>> be invoked. Hence it's the most accurate way of making sure that
> >>> crtc enabled <=> primary plane bound.
> >>>
> >>> If the check was done in the primary plane, an atomic modeset could enable
> >>> the crtc without enabling the primary plane, which shouldn't be allowed 
> >>> but
> >>> a plane check won't catch it.
> >>> This has been a bug in simple-kms-helper, fixed in the below commit:
> >>>
> >>> commit 765831dc27ab141b3a0be1ab55b922b012427902
> >>> Author: Maarten Lankhorst 
> >>> Date:   Wed Jul 12 10:13:29 2017 +0200
> >>>
> >>> drm/simple-kms-helper: Fix the check for the mismatch between plane 
> >>> and CRTC enabled.
> >> Hmm. OK that part looks OK. What does seem a bit inconsistent is the
> >> fact that we pass can_update_disabled=true, but later on we reject the
> >> update when visible==false. The old code would have accepted that
> >> because it didn't even call drm_plane_helper_check_state() when the
> >> crtc (and thus also the plane) was disabled.
> > Actually how does this work at all? If you turn off both the crtc and
> > plane, then the plane check will always return -EINVAL on account of
> > visible==false?
> >
> If the crtc is turned off, enabled = false and the primary plane is not in 
> crtc_state->plane_mask.
>
> Visibility is ignored in this check, that part is handled in plane check that 
> the framebuffer has to span the entire crtc if enabled.

Hmm. I thought the !crtc->enabled check disappeared from
drm_simple_kms_plane_atomic_check() but looks like I was wrong and it's
still there. OK, just totally ignore what I wrote before. I guess one
shouldn't try to figure out what the code is going to be doing while in
the middle of an unrelated bisect.

Though for some extra consistency we might want to change that to check
to look for !fb after calling drm_plane_helper_check_state(). That way
we wouldn't have to change drivers/simple_kms_helper if come up with
something that has to be checked even for disabled planes
in drm_plane_helper_check_state().

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

Re: [Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

[Maarten Lankhorst]

Op 06-11-17 om 15:06 schreef Ville Syrjälä:
> On Mon, Nov 06, 2017 at 04:01:20PM +0200, Ville Syrjälä wrote:
>> On Thu, Nov 02, 2017 at 09:55:40AM +0100, Maarten Lankhorst wrote:
>>> Op 01-11-17 om 18:00 schreef Ville Syrjälä:
 On Wed, Nov 01, 2017 at 04:55:06PM +0100, Maarten Lankhorst wrote:
> Op 01-11-17 om 16:29 schreef Ville Syrjälä:
>> On Wed, Nov 01, 2017 at 04:04:33PM +0100, Maarten Lankhorst wrote:
>>> This introduces a slight behavioral change to rmfb. Instead of
>>> disabling a crtc when the primary plane is disabled, we try to
>>> preserve it.
>>>
>>> Apart from old versions of the vmwgfx xorg driver, there is
>>> nothing depending on rmfb disabling a crtc.
>>>
>>> Vmwgfx' and simple kms helper atomic implementation rejects CRTC
>>> enabled without plane, so we can do this safely.
 The code for those seems a bit inconsistent. The crtc check requires
 that the crtc state and plane state match. But the plane check allows
 the plane to be enabled w/o the crtc being enabled. I guess it doesn't
 matter really since you can't enable the plane without a crtc, and the
 crtc check would then catch the case where the crtc would be disabled.
>>> Exactly. :-) Only when a plane is unbound and stays unbound, the crtc check 
>>> won't
>>> be invoked. Hence it's the most accurate way of making sure that
>>> crtc enabled <=> primary plane bound.
>>>
>>> If the check was done in the primary plane, an atomic modeset could enable
>>> the crtc without enabling the primary plane, which shouldn't be allowed but
>>> a plane check won't catch it.
>>> This has been a bug in simple-kms-helper, fixed in the below commit:
>>>
>>> commit 765831dc27ab141b3a0be1ab55b922b012427902
>>> Author: Maarten Lankhorst 
>>> Date:   Wed Jul 12 10:13:29 2017 +0200
>>>
>>> drm/simple-kms-helper: Fix the check for the mismatch between plane and 
>>> CRTC enabled.
>> Hmm. OK that part looks OK. What does seem a bit inconsistent is the
>> fact that we pass can_update_disabled=true, but later on we reject the
>> update when visible==false. The old code would have accepted that
>> because it didn't even call drm_plane_helper_check_state() when the
>> crtc (and thus also the plane) was disabled.
> Actually how does this work at all? If you turn off both the crtc and
> plane, then the plane check will always return -EINVAL on account of
> visible==false?
>
If the crtc is turned off, enabled = false and the primary plane is not in 
crtc_state->plane_mask. 




  

Visibility is ignored in this check, that part is handled in plane check that 
the framebuffer has to span the entire crtc if enabled.

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

[Intel-gfx] i915: pipe B vblank wait timed out

[Borislav Petkov]

Hi,

I see this on an 32-bit acer atom mini-laptop with -rc8+tip:

[2.399416] pipe B vblank wait timed out
[2.399506] [ cut here ]
[2.399533] WARNING: CPU: 1 PID: 22 at 
/mnt/kernel/kernel/linux-2.6/drivers/gpu/drm/i915/intel_display.c:12176 
intel_atomic_commit_tail+0xe0d/0xe20
[2.399545] Modules linked in:
[2.399574] CPU: 1 PID: 22 Comm: kworker/1:1 Not tainted 4.14.0-rc8+ #2
[2.399583] Hardware name: Acer AOA150/, BIOS v0.3309 10/06/2008
[2.399597] Workqueue: events output_poll_execute
[2.399613] task: f65a3780 task.stack: f65aa000
[2.399625] EIP: intel_atomic_commit_tail+0xe0d/0xe20
[2.399634] EFLAGS: 00210286 CPU: 1
[2.399643] EAX: 001c EBX:  ECX: 00200046 EDX: c18f6926
[2.399652] ESI: 01a8 EDI: 0001 EBP: f65abdc0 ESP: f65abd40
[2.399662]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[2.399671] CR0: 80050033 CR2:  CR3: 01c81000 CR4: 06f0
[2.399680] Call Trace:
[2.399699]  ? trace_hardirqs_on_caller+0xdc/0x1c0
[2.399713]  ? wait_woken+0x80/0x80
[2.399725]  ? wait_woken+0x80/0x80
[2.399739]  intel_atomic_commit+0x18f/0x250
[2.399751]  ? intel_atomic_commit+0x18f/0x250
[2.399766]  drm_atomic_commit+0x3a/0x50
[2.399782]  restore_fbdev_mode_atomic+0x15b/0x1a0
[2.399798]  ? intel_atomic_commit_tail+0xe20/0xe20
[2.399811]  restore_fbdev_mode+0x2c/0x140
[2.399824]  drm_fb_helper_restore_fbdev_mode_unlocked.part.19+0x23/0x70
[2.399836]  drm_fb_helper_set_par+0x45/0x80
[2.399848]  drm_fb_helper_hotplug_event.part.18+0x86/0xb0
[2.399861]  drm_fb_helper_hotplug_event+0x20/0x30
[2.399874]  intel_fbdev_output_poll_changed+0x17/0x20
[2.399885]  drm_kms_helper_hotplug_event+0x21/0x30
[2.399897]  output_poll_execute+0x8c/0x190
[2.399912]  process_one_work+0x1c5/0x5c0
[2.399927]  worker_thread+0x39/0x3c0
[2.399939]  ? preempt_count_sub+0x98/0xf0
[2.399952]  ? process_one_work+0x5c0/0x5c0
[2.399964]  kthread+0x10b/0x140
[2.399975]  ? process_one_work+0x5c0/0x5c0
[2.399987]  ? kthread_create_on_node+0x20/0x20
[2.38]  ? umh_complete+0x40/0x40
[2.400233]  ret_from_fork+0x19/0x24
[2.400246] Code: 4d 94 8d 55 c4 8b 81 30 02 00 00 01 f0 83 c0 04 e8 f9 a6 
c0 ff 85 db 0f 85 e2 fb ff ff 8d 47 41 50 68 08 28 95 c1 e8 90 de c2 ff <0f> ff 
58 5a e9 cb fb ff ff 8d 76 00 8d bc 27 00 00 00 00 3e 8d
[2.400722] ---[ end trace b8984f1a73a52375 ]---


-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/7] drm/edid and drivers: ELD refactoring

[Thierry Reding]

On Wed, Nov 01, 2017 at 04:20:56PM +0200, Jani Nikula wrote:
> We were recently bitten by drm_edid_to_eld() clearing the connector
> type, and us failing to set it back for DP. Here's a few ELD related
> patches to try to unify ELD handling and make it a bit simpler for
> drivers to get it right.
> 
> Apologies for the massive Cc list; it's the maintainers of all drivers
> that call drm_edid_to_eld().
> 
> I'm open to splitting up patch 6 to driver specific patches as needed,
> but I'd think it would be just fine to merge via drm-misc as-is too.
> 
> BR,
> Jani.
> 
> Cc: Alex Deucher 
> Cc: Christian König 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Russell King 
> Cc: CK Hu 
> Cc: Philipp Zabel 
> Cc: Ben Skeggs 
> Cc: Mark Yao 
> Cc: Benjamin Gaignard 
> Cc: Vincent Abriou 
> Cc: Thierry Reding 
> Cc: Eric Anholt 
> 
> 
> Jani Nikula (7):
>   drm/edid: use macros for ELD offsets and values
>   drm/edid: set ELD connector type in drm_edid_to_eld()
>   drm/i915: remove redundant ELD connector type update
>   drm/edid: abstract connector ELD clearing
>   drm/edid: build ELD in drm_add_edid_modes()
>   drm/drivers: drop redundant drm_edid_to_eld() calls
>   drm/edid: make drm_edid_to_eld() static
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c |  1 -
>  drivers/gpu/drm/bridge/analogix-anx78xx.c  |  2 -
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c  |  2 -
>  drivers/gpu/drm/drm_edid.c | 70 
> +++---
>  drivers/gpu/drm/i2c/tda998x_drv.c  |  1 -
>  drivers/gpu/drm/i915/intel_dp.c|  1 -
>  drivers/gpu/drm/i915/intel_modes.c | 18 ---
>  drivers/gpu/drm/mediatek/mtk_hdmi.c|  1 -
>  drivers/gpu/drm/nouveau/nv50_display.c |  5 +-
>  drivers/gpu/drm/radeon/radeon_connectors.c |  1 -
>  drivers/gpu/drm/radeon/radeon_dp_mst.c |  1 -
>  drivers/gpu/drm/rockchip/cdn-dp-core.c |  4 +-
>  drivers/gpu/drm/sti/sti_hdmi.c |  1 -
>  drivers/gpu/drm/tegra/output.c |  1 -
>  drivers/gpu/drm/vc4/vc4_hdmi.c |  1 -
>  include/drm/drm_edid.h |  1 -
>  include/drm/drm_modeset_helper_vtables.h   |  3 --
>  17 files changed, 44 insertions(+), 70 deletions(-)

The series:

Acked-by: Thierry Reding 


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

Re: [Intel-gfx] [PATCH] drm/i915: Reserve powerctx for chv from the stolen allocator

[Chris Wilson]

Quoting Ville Syrjälä (2017-11-06 14:43:12)
> On Mon, Nov 06, 2017 at 02:32:50PM +, Chris Wilson wrote:
> > Quoting Ville Syrjälä (2017-11-06 14:23:24)
> > > On Sat, Nov 04, 2017 at 09:43:38PM +, Chris Wilson wrote:
> > > > Ensure that we do not overwrite the cherryview power context by
> > > > reserving its range in the stolen allocator; exactly like how we handle
> > > > the same reservation for valleyview.
> > > 
> > > IIRC CHV pctx must live inside the "reserved" region. So this
> > > should never happen.
> > 
> > It's supposed to. Otoh, the duplication for no good reason is inane.
> 
> Well, it's not really duplication because it allocates the object in a
> different place. VLV wants it below the reserved region, CHV wants it
> inside the reserved region. Given that the reserved region isn't part of
> the mm we can't use the VLV code to allocate the pctx correctly for CHV.

There's no reason why we can't allow the preallocations to be inside the
reserved portion while preventing allocations from it, it's just a
matter of tracking. It's just so aggravating to have multiple drivers
making independent decisions on shared resources.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Reserve powerctx for chv from the stolen allocator

[Ville Syrjälä]

On Mon, Nov 06, 2017 at 02:32:50PM +, Chris Wilson wrote:
> Quoting Ville Syrjälä (2017-11-06 14:23:24)
> > On Sat, Nov 04, 2017 at 09:43:38PM +, Chris Wilson wrote:
> > > Ensure that we do not overwrite the cherryview power context by
> > > reserving its range in the stolen allocator; exactly like how we handle
> > > the same reservation for valleyview.
> > 
> > IIRC CHV pctx must live inside the "reserved" region. So this
> > should never happen.
> 
> It's supposed to. Otoh, the duplication for no good reason is inane.

Well, it's not really duplication because it allocates the object in a
different place. VLV wants it below the reserved region, CHV wants it
inside the reserved region. Given that the reserved region isn't part of
the mm we can't use the VLV code to allocate the pctx correctly for CHV.

> Then to complete the picture, we should be able to merge this with ilk
> powerctx, should we resurrect it.
> -Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: Reserve powerctx for chv from the stolen allocator

[Chris Wilson]

Quoting Ville Syrjälä (2017-11-06 14:23:24)
> On Sat, Nov 04, 2017 at 09:43:38PM +, Chris Wilson wrote:
> > Ensure that we do not overwrite the cherryview power context by
> > reserving its range in the stolen allocator; exactly like how we handle
> > the same reservation for valleyview.
> 
> IIRC CHV pctx must live inside the "reserved" region. So this
> should never happen.

It's supposed to. Otoh, the duplication for no good reason is inane.
Then to complete the picture, we should be able to merge this with ilk
powerctx, should we resurrect it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Assert ctch->vma is allocated

[Patchwork]

== Series Details ==

Series: drm/i915/guc: Assert ctch->vma is allocated
URL   : https://patchwork.freedesktop.org/series/33257/
State : failure

== Summary ==

Series 33257v1 drm/i915/guc: Assert ctch->vma is allocated
https://patchwork.freedesktop.org/api/1.0/series/33257/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
pass   -> DMESG-FAIL (fi-kbl-7560u) fdo#103039
Subgroup basic-s4-devices:
pass   -> DMESG-FAIL (fi-kbl-7560u) fdo#102846 +1
Test gem_flink_basic:
Subgroup bad-flink:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#103049 +4
Test kms_busy:
Subgroup basic-flip-a:
pass   -> INCOMPLETE (fi-glk-dsi)

fdo#103039 https://bugs.freedesktop.org/show_bug.cgi?id=103039
fdo#102846 https://bugs.freedesktop.org/show_bug.cgi?id=102846
fdo#103049 https://bugs.freedesktop.org/show_bug.cgi?id=103049

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:446s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:456s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:381s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:542s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:278s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:510s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:510s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:508s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:490s
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:559s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:609s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:422s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:266s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:579s
fi-glk-dsi   total:206  pass:183  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:430s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:432s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:427s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:501s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:460s
fi-kbl-7560u total:289  pass:105  dwarn:5   dfail:2   fail:0   skip:12 
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:483s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:585s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:566s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:453s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:599s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:654s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:519s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:503s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:459s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:570s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:418s

9cc9686b44e192d2561a513f84d5ac95518cad73 drm-tip: 2017y-11m-06d-10h-10m-17s UTC 
integration manifest
334c3f1ca500 drm/i915/guc: Assert ctch->vma is allocated

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6975/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Reserve powerctx for chv from the stolen allocator

[Ville Syrjälä]

On Sat, Nov 04, 2017 at 09:43:38PM +, Chris Wilson wrote:
> Ensure that we do not overwrite the cherryview power context by
> reserving its range in the stolen allocator; exactly like how we handle
> the same reservation for valleyview.

IIRC CHV pctx must live inside the "reserved" region. So this
should never happen.

> 
> Signed-off-by: Chris Wilson 
> Cc: Mika Kuoppala 
> ---
>  drivers/gpu/drm/i915/i915_drv.h |  3 +-
>  drivers/gpu/drm/i915/intel_pm.c | 97 
> +++--
>  2 files changed, 37 insertions(+), 63 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 72bb5b51035a..d6462388c3a6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1377,6 +1377,7 @@ struct intel_rps {
>  };
>  
>  struct intel_rc6 {
> + struct drm_i915_gem_object *pctx;
>   bool enabled;
>  };
>  
> @@ -2464,8 +2465,6 @@ struct drm_i915_private {
>  
>   struct i915_gpu_error gpu_error;
>  
> - struct drm_i915_gem_object *vlv_pctx;
> -
>   /* list of fbdev register on this device */
>   struct intel_fbdev *fbdev;
>   struct work_struct fbdev_suspend_work;
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 07118c0b69d3..1a0cf53e0638 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7034,7 +7034,7 @@ static void valleyview_check_pctx(struct 
> drm_i915_private *dev_priv)
>   unsigned long pctx_addr = I915_READ(VLV_PCBR) & ~4095;
>  
>   WARN_ON(pctx_addr != dev_priv->mm.stolen_base +
> -  dev_priv->vlv_pctx->stolen->start);
> +  dev_priv->gt_pm.rc6.pctx->stolen->start);
>  }
>  
>  
> @@ -7046,77 +7046,54 @@ static void cherryview_check_pctx(struct 
> drm_i915_private *dev_priv)
>   WARN_ON((pctx_addr >> VLV_PCBR_ADDR_SHIFT) == 0);
>  }
>  
> -static void cherryview_setup_pctx(struct drm_i915_private *dev_priv)
> -{
> - struct i915_ggtt *ggtt = _priv->ggtt;
> - unsigned long pctx_paddr, paddr;
> - u32 pcbr;
> - int pctx_size = 32*1024;
> -
> - pcbr = I915_READ(VLV_PCBR);
> - if ((pcbr >> VLV_PCBR_ADDR_SHIFT) == 0) {
> - DRM_DEBUG_DRIVER("BIOS didn't set up PCBR, fixing up\n");
> - paddr = (dev_priv->mm.stolen_base +
> -  (ggtt->stolen_size - pctx_size));
> -
> - pctx_paddr = (paddr & (~4095));
> - I915_WRITE(VLV_PCBR, pctx_paddr);
> - }
> -
> - DRM_DEBUG_DRIVER("PCBR: 0x%08x\n", I915_READ(VLV_PCBR));
> -}
> -
> -static void valleyview_setup_pctx(struct drm_i915_private *dev_priv)
> +static void setup_pctx(struct drm_i915_private *dev_priv, int pctx_size)
>  {
>   struct drm_i915_gem_object *pctx;
> - unsigned long pctx_paddr;
>   u32 pcbr;
> - int pctx_size = 24*1024;
>  
>   pcbr = I915_READ(VLV_PCBR);
>   if (pcbr) {
>   /* BIOS set it up already, grab the pre-alloc'd space */
> - int pcbr_offset;
> + u32 start = round_down(pcbr, 4096);
> + u32 end = round_up(pcbr + pctx_size, 4096);
>  
> - pcbr_offset = (pcbr & (~4095)) - dev_priv->mm.stolen_base;
>   pctx = i915_gem_object_create_stolen_for_preallocated(dev_priv,
> -   
> pcbr_offset,
> +   start - 
> dev_priv->mm.stolen_base,
> 
> I915_GTT_OFFSET_NONE,
> -   
> pctx_size);
> - goto out;
> - }
> +   end - 
> start);
> + } else {
> + DRM_DEBUG_DRIVER("BIOS didn't set up PCBR, fixing up\n");
>  
> - DRM_DEBUG_DRIVER("BIOS didn't set up PCBR, fixing up\n");
> + /*
> +  * From the Gunit register HAS:
> +  * The Gfx driver is expected to program this register and
> +  * ensure proper allocation within Gfx stolen memory.  For
> +  * example, this register should be programmed such than the
> +  * PCBR range does not overlap with other ranges, such as the
> +  * frame buffer, protected memory, or any other relevant ranges.
> +  */
> + pctx = i915_gem_object_create_stolen(dev_priv, pctx_size);
> + if (!pctx) {
> + DRM_DEBUG("not enough stolen space for PCTX, 
> disabling\n");
> + return;
> + }
>  
> - /*
> -  * From the Gunit register HAS:
> -  * The Gfx driver is expected to program this register and ensure
> -  * proper allocation within Gfx stolen memory.  For example, this
> -  * register should 

Re: [Intel-gfx] [PATCH v6 1/3] drm/i915: Add Guc/HuC firmware details to error state

[Chris Wilson]

Quoting Michal Wajdeczko (2017-10-26 18:36:55)
> Include GuC and HuC firmware details in captured error state
> to provide additional debug information. To reuse existing
> uc firmware pretty printer, introduce new drm-printer variant
> that works with our i915_error_state_buf output. Also update
> uc firmware pretty printer to accept const input.
> 
> v2: don't rely on current caps (Chris)
> dump correct fw info (Michal)
> v3: simplify capture of custom paths (Chris)
> v4: improve 'why' comment (Joonas)
> trim output if no fw path (Michal)
> group code around uc error state (Michal)
> v5: use error in cleanup_uc (Michal)
> 
> Suggested-by: Chris Wilson 
> Signed-off-by: Michal Wajdeczko 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_drv.h   |  5 +++
>  drivers/gpu/drm/i915/i915_gpu_error.c | 65 
> +++
>  drivers/gpu/drm/i915/intel_uc_fw.c|  6 +++-
>  drivers/gpu/drm/i915/intel_uc_fw.h|  2 +-
>  4 files changed, 76 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 366ba74..f19f0fa 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -911,6 +911,11 @@ struct i915_gpu_state {
> struct intel_device_info device_info;
> struct i915_params params;
>  
> +   struct i915_error_uc {
> +   struct intel_uc_fw guc_fw;
> +   struct intel_uc_fw huc_fw;
> +   } uc;
> +
> /* Generic register state */
> u32 eir;
> u32 pgtbl_er;
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 653fb69..4500fc8 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -30,6 +30,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
>  #include "i915_drv.h"
>  
>  static const char *engine_str(int engine)
> @@ -175,6 +177,21 @@ static void i915_error_puts(struct 
> drm_i915_error_state_buf *e,
>  #define err_printf(e, ...) i915_error_printf(e, __VA_ARGS__)
>  #define err_puts(e, s) i915_error_puts(e, s)
>  
> +static void __i915_printfn_error(struct drm_printer *p, struct va_format 
> *vaf)
> +{
> +   i915_error_vprintf(p->arg, vaf->fmt, *vaf->va);
> +}
> +
> +static inline struct drm_printer
> +i915_error_printer(struct drm_i915_error_state_buf *e)
> +{
> +   struct drm_printer p = {
> +   .printfn = __i915_printfn_error,
> +   .arg = e,
> +   };
> +   return p;
> +}
> +
>  #ifdef CONFIG_DRM_I915_COMPRESS_ERROR
>  
>  struct compress {
> @@ -589,11 +606,26 @@ static void err_print_pciid(struct 
> drm_i915_error_state_buf *m,
>pdev->subsystem_device);
>  }
>  
> +static void err_print_uc(struct drm_i915_error_state_buf *m,
> +const struct i915_error_uc *error_uc)
> +{
> +   struct drm_printer p = i915_error_printer(m);
> +   const struct i915_gpu_state *error =
> +   container_of(error_uc, typeof(*error), uc);
> +
> +   if (!error->device_info.has_guc)
> +   return;

I am still not keen on how derived state is mixed in with checking
whether or not a piece of fw was presented to HW before the hang, it is
still better than before.

> +
> +   intel_uc_fw_dump(_uc->guc_fw, );
> +   intel_uc_fw_dump(_uc->huc_fw, );
> +}
> +
>  int i915_error_state_to_str(struct drm_i915_error_state_buf *m,
> const struct i915_gpu_state *error)
>  {
> struct drm_i915_private *dev_priv = m->i915;
> struct drm_i915_error_object *obj;
> +
> int i, j;
>  
> if (!error) {
> @@ -773,6 +805,7 @@ int i915_error_state_to_str(struct 
> drm_i915_error_state_buf *m,
>  
> err_print_capabilities(m, >device_info);
> err_print_params(m, >params);
> +   err_print_uc(m, >uc);
>  
> if (m->bytes == 0 && m->err)
> return m->err;
> @@ -831,6 +864,14 @@ static __always_inline void free_param(const char *type, 
> void *x)
> kfree(*(void **)x);
>  }
>  
> +static void cleanup_uc_state(struct i915_gpu_state *error)
> +{
> +   struct i915_error_uc *error_uc = >uc;
> +
> +   kfree(error_uc->guc_fw.path);
> +   kfree(error_uc->huc_fw.path);
> +}
> +
>  void __i915_gpu_state_free(struct kref *error_ref)
>  {
> struct i915_gpu_state *error =
> @@ -870,6 +911,8 @@ void __i915_gpu_state_free(struct kref *error_ref)
> I915_PARAMS_FOR_EACH(FREE);
>  #undef FREE
>  
> +   cleanup_uc_state(error);
> +
> kfree(error);
>  }
>  
> @@ -1559,6 +1602,26 @@ static void i915_capture_pinned_buffers(struct 
> drm_i915_private *dev_priv,
> error->pinned_bo = bo;
>  }
>  
> +static void capture_uc_state(struct i915_gpu_state *error)
> +{

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Generalize transcoder looping (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Generalize transcoder looping (rev2)
URL   : https://patchwork.freedesktop.org/series/32965/
State : failure

== Summary ==

Series 32965v2 drm/i915: Generalize transcoder looping
https://patchwork.freedesktop.org/api/1.0/series/32965/revisions/2/mbox/

Test gem_exec_parallel:
Subgroup basic:
pass   -> DMESG-FAIL (fi-glk-dsi)
Test gem_exec_reloc:
Subgroup basic-cpu:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-gtt:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-cpu-gtt:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-gtt-cpu:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-cpu-read:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-gtt-read:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-write-cpu:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-write-gtt:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-write-read:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-cpu-noreloc:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-gtt-noreloc:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-cpu-gtt-noreloc:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-gtt-cpu-noreloc:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-cpu-read-noreloc:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-gtt-read-noreloc:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-write-cpu-noreloc:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-write-gtt-noreloc:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-write-read-noreloc:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-cpu-active:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-gtt-active:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-cpu-gtt-active:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-gtt-cpu-active:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-cpu-read-active:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-gtt-read-active:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-write-cpu-active:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-write-gtt-active:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-write-read-active:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-softpin:
pass   -> SKIP   (fi-glk-dsi)
Test gem_exec_store:
Subgroup basic-all:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-blt:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-bsd:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-default:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-render:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-vebox:
pass   -> SKIP   (fi-glk-dsi)
Test gem_exec_suspend:
Subgroup basic:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-s3:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-s4-devices:
pass   -> SKIP   (fi-glk-dsi)
Test gem_linear_blits:
Subgroup basic:
pass   -> SKIP   (fi-glk-dsi)
Test gem_render_linear_blits:
Subgroup basic:
pass   -> SKIP   (fi-glk-dsi)
Test gem_render_tiled_blits:
Subgroup basic:
pass   -> SKIP   (fi-glk-dsi)
Test gem_ringfill:
Subgroup basic-default:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-default-interruptible:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-default-forked:
pass   -> SKIP   (fi-glk-dsi)
Subgroup basic-default-fd:
WARNING: Long output truncated

9cc9686b44e192d2561a513f84d5ac95518cad73 drm-tip: 2017y-11m-06d-10h-10m-17s UTC 
integration manifest
3d0c67d697a9 drm/i915: Generalize transcoder looping

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6974/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

[Ville Syrjälä]

On Mon, Nov 06, 2017 at 04:01:20PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 02, 2017 at 09:55:40AM +0100, Maarten Lankhorst wrote:
> > Op 01-11-17 om 18:00 schreef Ville Syrjälä:
> > > On Wed, Nov 01, 2017 at 04:55:06PM +0100, Maarten Lankhorst wrote:
> > >> Op 01-11-17 om 16:29 schreef Ville Syrjälä:
> > >>> On Wed, Nov 01, 2017 at 04:04:33PM +0100, Maarten Lankhorst wrote:
> >  This introduces a slight behavioral change to rmfb. Instead of
> >  disabling a crtc when the primary plane is disabled, we try to
> >  preserve it.
> > 
> >  Apart from old versions of the vmwgfx xorg driver, there is
> >  nothing depending on rmfb disabling a crtc.
> > 
> >  Vmwgfx' and simple kms helper atomic implementation rejects CRTC
> >  enabled without plane, so we can do this safely.
> > > The code for those seems a bit inconsistent. The crtc check requires
> > > that the crtc state and plane state match. But the plane check allows
> > > the plane to be enabled w/o the crtc being enabled. I guess it doesn't
> > > matter really since you can't enable the plane without a crtc, and the
> > > crtc check would then catch the case where the crtc would be disabled.
> > 
> > Exactly. :-) Only when a plane is unbound and stays unbound, the crtc check 
> > won't
> > be invoked. Hence it's the most accurate way of making sure that
> > crtc enabled <=> primary plane bound.
> > 
> > If the check was done in the primary plane, an atomic modeset could enable
> > the crtc without enabling the primary plane, which shouldn't be allowed but
> > a plane check won't catch it.
> 
> > 
> > This has been a bug in simple-kms-helper, fixed in the below commit:
> > 
> > commit 765831dc27ab141b3a0be1ab55b922b012427902
> > Author: Maarten Lankhorst 
> > Date:   Wed Jul 12 10:13:29 2017 +0200
> > 
> > drm/simple-kms-helper: Fix the check for the mismatch between plane and 
> > CRTC enabled.
> 
> Hmm. OK that part looks OK. What does seem a bit inconsistent is the
> fact that we pass can_update_disabled=true, but later on we reject the
> update when visible==false. The old code would have accepted that
> because it didn't even call drm_plane_helper_check_state() when the
> crtc (and thus also the plane) was disabled.

Actually how does this work at all? If you turn off both the crtc and
plane, then the plane check will always return -EINVAL on account of
visible==false?

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

Re: [Intel-gfx] [PATCH] drm/atomic: Try to preserve the crtc enabled state in drm_atomic_remove_fb, v2.

[Ville Syrjälä]

On Thu, Nov 02, 2017 at 09:55:40AM +0100, Maarten Lankhorst wrote:
> Op 01-11-17 om 18:00 schreef Ville Syrjälä:
> > On Wed, Nov 01, 2017 at 04:55:06PM +0100, Maarten Lankhorst wrote:
> >> Op 01-11-17 om 16:29 schreef Ville Syrjälä:
> >>> On Wed, Nov 01, 2017 at 04:04:33PM +0100, Maarten Lankhorst wrote:
>  This introduces a slight behavioral change to rmfb. Instead of
>  disabling a crtc when the primary plane is disabled, we try to
>  preserve it.
> 
>  Apart from old versions of the vmwgfx xorg driver, there is
>  nothing depending on rmfb disabling a crtc.
> 
>  Vmwgfx' and simple kms helper atomic implementation rejects CRTC
>  enabled without plane, so we can do this safely.
> > The code for those seems a bit inconsistent. The crtc check requires
> > that the crtc state and plane state match. But the plane check allows
> > the plane to be enabled w/o the crtc being enabled. I guess it doesn't
> > matter really since you can't enable the plane without a crtc, and the
> > crtc check would then catch the case where the crtc would be disabled.
> 
> Exactly. :-) Only when a plane is unbound and stays unbound, the crtc check 
> won't
> be invoked. Hence it's the most accurate way of making sure that
> crtc enabled <=> primary plane bound.
> 
> If the check was done in the primary plane, an atomic modeset could enable
> the crtc without enabling the primary plane, which shouldn't be allowed but
> a plane check won't catch it.

> 
> This has been a bug in simple-kms-helper, fixed in the below commit:
> 
> commit 765831dc27ab141b3a0be1ab55b922b012427902
> Author: Maarten Lankhorst 
> Date:   Wed Jul 12 10:13:29 2017 +0200
> 
> drm/simple-kms-helper: Fix the check for the mismatch between plane and 
> CRTC enabled.

Hmm. OK that part looks OK. What does seem a bit inconsistent is the
fact that we pass can_update_disabled=true, but later on we reject the
update when visible==false. The old code would have accepted that
because it didn't even call drm_plane_helper_check_state() when the
crtc (and thus also the plane) was disabled.

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

[Intel-gfx] [PATCH] drm/i915/guc: Assert ctch->vma is allocated

[Michal Wajdeczko]

Silence smatch by demonstrating that ctch->vma is allocated
following a successful chch_init()

drivers/gpu/drm/i915/intel_guc_ct.c:204 ctch_open() error:
 we previously assumed 'ctch->vma' could be null (see line 197)

Signed-off-by: Michal Wajdeczko 
Cc: Chris Wilson 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_guc_ct.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_guc_ct.c 
b/drivers/gpu/drm/i915/intel_guc_ct.c
index c4cbec1..24ad557 100644
--- a/drivers/gpu/drm/i915/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/intel_guc_ct.c
@@ -198,6 +198,7 @@ static int ctch_open(struct intel_guc *guc,
err = ctch_init(guc, ctch);
if (unlikely(err))
goto err_out;
+   GEM_BUG_ON(!ctch->vma);
}
 
/* vma should be already allocated and map'ed */
-- 
1.9.1

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/8] drm/i915: Assert guc->stage_desc_pool is allocated

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/8] drm/i915: Assert guc->stage_desc_pool is 
allocated
URL   : https://patchwork.freedesktop.org/series/33254/
State : failure

== Summary ==

Series 33254v1 series starting with [CI,1/8] drm/i915: Assert 
guc->stage_desc_pool is allocated
https://patchwork.freedesktop.org/api/1.0/series/33254/revisions/1/mbox/

Test kms_force_connector_basic:
Subgroup force-connector-state:
skip   -> INCOMPLETE (fi-cnl-y)

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:442s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:456s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:381s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:532s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:277s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:510s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:506s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:511s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:487s
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:552s
fi-cnl-y total:289  pass:200  dwarn:0   dfail:0   fail:0   skip:20 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:432s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:263s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:586s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:500s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:431s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:433s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:428s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:488s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:464s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:577s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:584s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:570s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:600s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:649s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:516s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:507s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:460s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:570s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:418s

9cc9686b44e192d2561a513f84d5ac95518cad73 drm-tip: 2017y-11m-06d-10h-10m-17s UTC 
integration manifest
ffe5bb7e91a8 drm/i915: Stop caching the "golden" renderstate
375f8f1836c8 drm/i915: Record the default hw state after reset upon load
340f7583c1df drm/i915: Mark the context state as dirty/written
e8fa066930d2 drm/i915: Inline intel_modeset_gem_init()
4dac3e837b68 drm/i915: Move GT powersaving init to i915_gem_init()
938a4a018762 drm/i915: Force the switch to the i915->kernel_context
9414a8c8fa04 drm/i915: Define an engine class enum for the uABI
11aade27258a drm/i915: Assert guc->stage_desc_pool is allocated

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6973/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Assert guc->stage_desc_pool is allocated

[Patchwork]

== Series Details ==

Series: drm/i915: Assert guc->stage_desc_pool is allocated
URL   : https://patchwork.freedesktop.org/series/33248/
State : success

== Summary ==

Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_flip:
Subgroup wf_vblank-vs-dpms-interruptible:
incomplete -> PASS   (shard-hsw) fdo#102614
Test perf:
Subgroup oa-exponents:
pass   -> FAIL   (shard-hsw) fdo#102254

fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#102254 https://bugs.freedesktop.org/show_bug.cgi?id=102254

shard-hswtotal:2539 pass:1432 dwarn:0   dfail:0   fail:10  skip:1097 
time:9155s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6972/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Assert guc->stage_desc_pool is allocated

[Michal Wajdeczko]

On Mon, Nov 06, 2017 at 11:48:33AM +, Chris Wilson wrote:
> Silence smatch by demonstrating that guc->stage_desc_pool is allocated
> following a successful guc_stage_desc_pool_create()
> 
> drivers/gpu/drm/i915/i915_guc_submission.c:1293 i915_guc_submission_init() 
> error: we previously assumed 'guc->stage_desc_pool' could be null (see line 
> 1261
> 
> Signed-off-by: Chris Wilson 
> Cc: Oscar Mateo 
> Cc: Daniele Ceraolo Spurio 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_guc_submission.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index d14c1342f09d..6f2548114bd2 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -1265,10 +1265,18 @@ int i915_guc_submission_init(struct drm_i915_private 
> *dev_priv)
>   if (ret)
>   return ret;
>  
> + /*
> +  * Keep static analysers happy, let them know that we allocated the
> +  * vma after testing that it didn't exist earlier.
> +  */
> + GEM_BUG_ON(!guc->stage_desc_pool);
> +
>   ret = guc_shared_data_create(guc);
>   if (ret)
>   goto err_stage_desc_pool;
>  
> + GEM_BUG_ON(!guc->shared_data);
> +
>   ret = intel_guc_log_create(guc);
>   if (ret < 0)
>   goto err_shared_data;
> @@ -1277,10 +1285,14 @@ int i915_guc_submission_init(struct drm_i915_private 
> *dev_priv)
>   if (ret)
>   goto err_log;
>  
> + GEM_BUG_ON(!guc->preempt_wq);
> +
>   ret = guc_ads_create(guc);
>   if (ret < 0)
>   goto err_wq;
>  
> + GEM_BUG_ON(!guc->ads_vma);
> +
>   return 0;
>  

Nitpick: I would place GEM_BUG_ONs right after "if(ret)" without
any separation line to emphase that those statements are related.

Also I hope that one day we will call submission_init just once and
than early check of stage_desc_pool will not be needed any more.

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

[Intel-gfx] [CI 8/8] drm/i915: Stop caching the "golden" renderstate

[Chris Wilson]

As we now record the default HW state and so only emit the "golden"
renderstate once to prepare the HW, there is no advantage in keeping the
renderstate batch around as it will never be used again.

Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h  |   1 -
 drivers/gpu/drm/i915/i915_gem_render_state.c | 135 +--
 drivers/gpu/drm/i915/i915_gem_render_state.h |   4 +-
 drivers/gpu/drm/i915/intel_engine_cs.c   |   9 +-
 drivers/gpu/drm/i915/intel_lrc.c |   1 +
 drivers/gpu/drm/i915/intel_ringbuffer.c  |   5 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h  |   2 -
 7 files changed, 51 insertions(+), 106 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 593714fe5c5e..8e66dceb820b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -67,7 +67,6 @@
 #include "i915_gem_fence_reg.h"
 #include "i915_gem_object.h"
 #include "i915_gem_gtt.h"
-#include "i915_gem_render_state.h"
 #include "i915_gem_request.h"
 #include "i915_gem_timeline.h"
 
diff --git a/drivers/gpu/drm/i915/i915_gem_render_state.c 
b/drivers/gpu/drm/i915/i915_gem_render_state.c
index 3703dc91eeda..69621d887975 100644
--- a/drivers/gpu/drm/i915/i915_gem_render_state.c
+++ b/drivers/gpu/drm/i915/i915_gem_render_state.c
@@ -26,10 +26,12 @@
  */
 
 #include "i915_drv.h"
+#include "i915_gem_render_state.h"
 #include "intel_renderstate.h"
 
 struct intel_render_state {
const struct intel_renderstate_rodata *rodata;
+   struct drm_i915_gem_object *obj;
struct i915_vma *vma;
u32 batch_offset;
u32 batch_size;
@@ -74,17 +76,16 @@ static int render_state_setup(struct intel_render_state *so,
  struct drm_i915_private *i915)
 {
const struct intel_renderstate_rodata *rodata = so->rodata;
-   struct drm_i915_gem_object *obj = so->vma->obj;
unsigned int i = 0, reloc_index = 0;
unsigned int needs_clflush;
u32 *d;
int ret;
 
-   ret = i915_gem_obj_prepare_shmem_write(obj, _clflush);
+   ret = i915_gem_obj_prepare_shmem_write(so->obj, _clflush);
if (ret)
return ret;
 
-   d = kmap_atomic(i915_gem_object_get_dirty_page(obj, 0));
+   d = kmap_atomic(i915_gem_object_get_dirty_page(so->obj, 0));
 
while (i < rodata->batch_items) {
u32 s = rodata->batch[i];
@@ -112,7 +113,7 @@ static int render_state_setup(struct intel_render_state *so,
goto err;
}
 
-   so->batch_offset = so->vma->node.start;
+   so->batch_offset = i915_ggtt_offset(so->vma);
so->batch_size = rodata->batch_items * sizeof(u32);
 
while (i % CACHELINE_DWORDS)
@@ -160,9 +161,9 @@ static int render_state_setup(struct intel_render_state *so,
drm_clflush_virt_range(d, i * sizeof(u32));
kunmap_atomic(d);
 
-   ret = i915_gem_object_set_to_gtt_domain(obj, false);
+   ret = i915_gem_object_set_to_gtt_domain(so->obj, false);
 out:
-   i915_gem_obj_finish_shmem_access(obj);
+   i915_gem_obj_finish_shmem_access(so->obj);
return ret;
 
 err:
@@ -173,112 +174,64 @@ static int render_state_setup(struct intel_render_state 
*so,
 
 #undef OUT_BATCH
 
-int i915_gem_render_state_init(struct intel_engine_cs *engine)
+int i915_gem_render_state_emit(struct drm_i915_gem_request *rq)
 {
-   struct intel_render_state *so;
-   const struct intel_renderstate_rodata *rodata;
-   struct drm_i915_gem_object *obj;
-   int ret;
+   struct intel_engine_cs *engine = rq->engine;
+   struct intel_render_state so;
+   int err;
 
if (engine->id != RCS)
return 0;
 
-   rodata = render_state_get_rodata(engine);
-   if (!rodata)
+   so.rodata = render_state_get_rodata(engine);
+   if (!so.rodata)
return 0;
 
-   if (rodata->batch_items * 4 > PAGE_SIZE)
+   if (so.rodata->batch_items * 4 > PAGE_SIZE)
return -EINVAL;
 
-   so = kmalloc(sizeof(*so), GFP_KERNEL);
-   if (!so)
-   return -ENOMEM;
+   so.obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
+   if (IS_ERR(so.obj))
+   return PTR_ERR(so.obj);
 
-   obj = i915_gem_object_create_internal(engine->i915, PAGE_SIZE);
-   if (IS_ERR(obj)) {
-   ret = PTR_ERR(obj);
-   goto err_free;
-   }
-
-   so->vma = i915_vma_instance(obj, >i915->ggtt.base, NULL);
-   if (IS_ERR(so->vma)) {
-   ret = PTR_ERR(so->vma);
+   so.vma = i915_vma_instance(so.obj, >i915->ggtt.base, NULL);
+   if (IS_ERR(so.vma)) {
+   err = PTR_ERR(so.vma);
goto err_obj;
}
 
-   so->rodata = rodata;
-   engine->render_state = so;
-   return 0;
-
-err_obj:
-   

[Intel-gfx] [PATCH v2] drm/i915: Generalize transcoder looping

[Mika Kahola]

To make looping through transcoders in intel_ddi.c more generic, let's switch
to use 'for_each_pipe()' macro to do this.

v2: Add a notion that we are dealing with transcoders instead of pipes (Jani)

Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_ddi.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index ace674c..5e83785 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1681,8 +1681,9 @@ bool intel_ddi_get_hw_state(struct intel_encoder *encoder,
struct drm_device *dev = encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
enum port port = encoder->port;
+   enum pipe p;
+   enum transcoder cpu_transcoder;
u32 tmp;
-   int i;
bool ret;
 
if (!intel_display_power_get_if_enabled(dev_priv,
@@ -1717,15 +1718,17 @@ bool intel_ddi_get_hw_state(struct intel_encoder 
*encoder,
goto out;
}
 
-   for (i = TRANSCODER_A; i <= TRANSCODER_C; i++) {
-   tmp = I915_READ(TRANS_DDI_FUNC_CTL(i));
+   for_each_pipe(dev_priv, p) {
+   cpu_transcoder = (enum transcoder) p;
+
+   tmp = I915_READ(TRANS_DDI_FUNC_CTL(cpu_transcoder));
 
if ((tmp & TRANS_DDI_PORT_MASK) == TRANS_DDI_SELECT_PORT(port)) 
{
if ((tmp & TRANS_DDI_MODE_SELECT_MASK) ==
TRANS_DDI_MODE_SELECT_DP_MST)
goto out;
 
-   *pipe = i;
+   *pipe = p;
ret = true;
 
goto out;
-- 
2.7.4

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

[Intel-gfx] [CI 1/8] drm/i915: Assert guc->stage_desc_pool is allocated

[Chris Wilson]

Silence smatch by demonstrating that guc->stage_desc_pool is allocated
following a successful guc_stage_desc_pool_create()

drivers/gpu/drm/i915/i915_guc_submission.c:1293 i915_guc_submission_init() 
error: we previously assumed 'guc->stage_desc_pool' could be null (see line 1261

Signed-off-by: Chris Wilson 
Cc: Oscar Mateo 
Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index d14c1342f09d..6f2548114bd2 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1265,10 +1265,18 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
if (ret)
return ret;
 
+   /*
+* Keep static analysers happy, let them know that we allocated the
+* vma after testing that it didn't exist earlier.
+*/
+   GEM_BUG_ON(!guc->stage_desc_pool);
+
ret = guc_shared_data_create(guc);
if (ret)
goto err_stage_desc_pool;
 
+   GEM_BUG_ON(!guc->shared_data);
+
ret = intel_guc_log_create(guc);
if (ret < 0)
goto err_shared_data;
@@ -1277,10 +1285,14 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
if (ret)
goto err_log;
 
+   GEM_BUG_ON(!guc->preempt_wq);
+
ret = guc_ads_create(guc);
if (ret < 0)
goto err_wq;
 
+   GEM_BUG_ON(!guc->ads_vma);
+
return 0;
 
 err_wq:
-- 
2.15.0

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

[Intel-gfx] [CI 2/8] drm/i915: Define an engine class enum for the uABI

[Chris Wilson]

From: Tvrtko Ursulin 

We want to be able to report back to userspace details about an engine's
class, and in return for userspace to be able to request actions
regarding certain classes of engines. To isolate the uABI from any
variations between hw generations, we define an abstract class for the
engines and internally map onto the hw.

v2: Remove MAX from the uABI; keep it internal if we need it, but don't
let userspace make the mistake of using it themselves.

Signed-off-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  | 10 +-
 drivers/gpu/drm/i915/intel_ringbuffer.h |  5 -
 include/uapi/drm/i915_drm.h | 15 +++
 3 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index ddbe5c9bf45a..0987768c311d 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -50,6 +50,8 @@ struct engine_class_info {
const char *name;
int (*init_legacy)(struct intel_engine_cs *engine);
int (*init_execlists)(struct intel_engine_cs *engine);
+
+   u8 uabi_class;
 };
 
 static const struct engine_class_info intel_engine_classes[] = {
@@ -57,21 +59,25 @@ static const struct engine_class_info 
intel_engine_classes[] = {
.name = "rcs",
.init_execlists = logical_render_ring_init,
.init_legacy = intel_init_render_ring_buffer,
+   .uabi_class = I915_ENGINE_CLASS_RENDER,
},
[COPY_ENGINE_CLASS] = {
.name = "bcs",
.init_execlists = logical_xcs_ring_init,
.init_legacy = intel_init_blt_ring_buffer,
+   .uabi_class = I915_ENGINE_CLASS_COPY,
},
[VIDEO_DECODE_CLASS] = {
.name = "vcs",
.init_execlists = logical_xcs_ring_init,
.init_legacy = intel_init_bsd_ring_buffer,
+   .uabi_class = I915_ENGINE_CLASS_VIDEO,
},
[VIDEO_ENHANCEMENT_CLASS] = {
.name = "vecs",
.init_execlists = logical_xcs_ring_init,
.init_legacy = intel_init_vebox_ring_buffer,
+   .uabi_class = I915_ENGINE_CLASS_VIDEO_ENHANCE,
},
 };
 
@@ -213,13 +219,15 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
WARN_ON(snprintf(engine->name, sizeof(engine->name), "%s%u",
 class_info->name, info->instance) >=
sizeof(engine->name));
-   engine->uabi_id = info->uabi_id;
engine->hw_id = engine->guc_id = info->hw_id;
engine->mmio_base = info->mmio_base;
engine->irq_shift = info->irq_shift;
engine->class = info->class;
engine->instance = info->instance;
 
+   engine->uabi_id = info->uabi_id;
+   engine->uabi_class = class_info->uabi_class;
+
engine->context_size = __intel_engine_context_size(dev_priv,
   engine->class);
if (WARN_ON(engine->context_size > BIT(20)))
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 1106904f6e31..7d3903b9fb1d 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -290,11 +290,14 @@ struct intel_engine_execlists {
 struct intel_engine_cs {
struct drm_i915_private *i915;
char name[INTEL_ENGINE_CS_MAX_NAME];
+
enum intel_engine_id id;
-   unsigned int uabi_id;
unsigned int hw_id;
unsigned int guc_id;
 
+   u8 uabi_id;
+   u8 uabi_class;
+
u8 class;
u8 instance;
u32 context_size;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index ac3c6503ca27..65d06da62599 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -86,6 +86,21 @@ enum i915_mocs_table_index {
I915_MOCS_CACHED,
 };
 
+/*
+ * Different engines serve different roles, and there may be more than one
+ * engine serving each role. enum drm_i915_gem_engine_class provides a
+ * classification of the role of the engine, which may be used when requesting
+ * operations to be performed on a certain subset of engines, or for providing
+ * information about that group.
+ */
+enum drm_i915_gem_engine_class {
+   I915_ENGINE_CLASS_OTHER = 0,
+   I915_ENGINE_CLASS_RENDER = 1,
+   I915_ENGINE_CLASS_COPY = 2,
+   I915_ENGINE_CLASS_VIDEO = 3,
+   I915_ENGINE_CLASS_VIDEO_ENHANCE = 4,
+};
+
 /* Each region is a minimum of 16k, and there are at most 255 of them.
  */
 #define I915_NR_TEX_REGIONS 255/* table size 2k - maximum due to use
-- 
2.15.0

___
Intel-gfx mailing list

[Intel-gfx] [CI 4/8] drm/i915: Move GT powersaving init to i915_gem_init()

[Chris Wilson]

GT powersaving is tightly coupled to the request infrastructure. To
avoid complications with the order of initialisation in the next patch
(where we want to send requests to hw during GEM init) move the
powersaving initialisation into the purview of i915_gem_init().

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c  | 2 ++
 drivers/gpu/drm/i915/intel_display.c | 2 --
 drivers/gpu/drm/i915/intel_pm.c  | 2 --
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 824515556733..37586f703c1e 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5021,6 +5021,8 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
if (ret)
goto out_unlock;
 
+   intel_init_gt_powersave(dev_priv);
+
ret = i915_gem_init_hw(dev_priv);
if (ret == -EIO) {
/* Allow engine initialisation to fail by marking the GPU as
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 737de251d0f8..c3bf87c2036c 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15174,8 +15174,6 @@ void intel_modeset_gem_init(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
 
-   intel_init_gt_powersave(dev_priv);
-
intel_setup_overlay(dev_priv);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 07118c0b69d3..6e1358d4e764 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -7900,7 +7900,6 @@ void intel_init_gt_powersave(struct drm_i915_private 
*dev_priv)
intel_runtime_pm_get(dev_priv);
}
 
-   mutex_lock(_priv->drm.struct_mutex);
mutex_lock(_priv->pcu_lock);
 
/* Initialize RPS limits (for userspace) */
@@ -7942,7 +7941,6 @@ void intel_init_gt_powersave(struct drm_i915_private 
*dev_priv)
rps->boost_freq = rps->max_freq;
 
mutex_unlock(_priv->pcu_lock);
-   mutex_unlock(_priv->drm.struct_mutex);
 
intel_autoenable_gt_powersave(dev_priv);
 }
-- 
2.15.0

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

[Intel-gfx] [CI 7/8] drm/i915: Record the default hw state after reset upon load

[Chris Wilson]

Take a copy of the HW state after a reset upon module loading by
executing a context switch from a blank context to the kernel context,
thus saving the default hw state over the blank context image.
We can then use the default hw state to initialise any future context,
ensuring that each starts with the default view of hw state.

v2: Unmap our default state from the GTT after stealing it from the
context. This should stop us from accidentally overwriting it via the
GTT (and frees up some precious GTT space).

Testcase: igt/gem_ctx_isolation
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/gvt/scheduler.c|   2 -
 drivers/gpu/drm/i915/i915_debugfs.c |   1 -
 drivers/gpu/drm/i915/i915_drv.c |   3 +
 drivers/gpu/drm/i915/i915_gem.c | 117 +++-
 drivers/gpu/drm/i915/i915_gem_context.c |  55 ---
 drivers/gpu/drm/i915/i915_gem_context.h |   4 +-
 drivers/gpu/drm/i915/intel_engine_cs.c  |  17 +
 drivers/gpu/drm/i915/intel_lrc.c|  39 +++
 drivers/gpu/drm/i915/intel_ringbuffer.c |  45 
 drivers/gpu/drm/i915/intel_ringbuffer.h |   2 +
 include/uapi/drm/i915_drm.h |  15 
 11 files changed, 226 insertions(+), 74 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index f6ded475bb2c..42cc61230ca7 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -723,8 +723,6 @@ int intel_vgpu_init_gvt_context(struct intel_vgpu *vgpu)
if (IS_ERR(vgpu->shadow_ctx))
return PTR_ERR(vgpu->shadow_ctx);
 
-   vgpu->shadow_ctx->engine[RCS].initialised = true;
-
bitmap_zero(vgpu->shadow_ctx_desc_updated, I915_NUM_ENGINES);
 
return 0;
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 39883cd915db..cfcef1899da8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1974,7 +1974,6 @@ static int i915_context_status(struct seq_file *m, void 
*unused)
struct intel_context *ce = >engine[engine->id];
 
seq_printf(m, "%s: ", engine->name);
-   seq_putc(m, ce->initialised ? 'I' : 'i');
if (ce->state)
describe_obj(m, ce->state->obj);
if (ce->ring)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 1b440f2b90a5..d97fe9c9439a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -406,6 +406,9 @@ static int i915_getparam(struct drm_device *dev, void *data,
 */
value = 1;
break;
+   case I915_PARAM_HAS_CONTEXT_ISOLATION:
+   value = intel_engines_has_context_isolation(dev_priv);
+   break;
case I915_PARAM_SLICE_MASK:
value = INTEL_INFO(dev_priv)->sseu.slice_mask;
if (!value)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 37586f703c1e..69168a36c10c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4972,6 +4972,117 @@ bool intel_sanitize_semaphores(struct drm_i915_private 
*dev_priv, int value)
return true;
 }
 
+static int __intel_engines_record_defaults(struct drm_i915_private *i915)
+{
+   struct i915_gem_context *ctx;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+   int err;
+
+   /*
+* As we reset the gpu during very early sanitisation, the current
+* register state on the GPU should reflect its defaults values.
+* We load a context onto the hw (with restore-inhibit), then switch
+* over to a second context to save that default register state. We
+* can then prime every new context with that state so they all start
+* from the same default HW values.
+*/
+
+   ctx = i915_gem_context_create_kernel(i915, 0);
+   if (IS_ERR(ctx))
+   return PTR_ERR(ctx);
+
+   for_each_engine(engine, i915, id) {
+   struct drm_i915_gem_request *rq;
+
+   rq = i915_gem_request_alloc(engine, ctx);
+   if (IS_ERR(rq)) {
+   err = PTR_ERR(rq);
+   goto out_ctx;
+   }
+
+   err = i915_switch_context(rq);
+   if (engine->init_context)
+   err = engine->init_context(rq);
+
+   __i915_add_request(rq, true);
+   if (err)
+   goto err_active;
+   }
+
+   err = i915_gem_switch_to_kernel_context(i915);
+   if (err)
+   goto err_active;
+
+   

[Intel-gfx] [CI 3/8] drm/i915: Force the switch to the i915->kernel_context

[Chris Wilson]

In the next few patches, we will have a hard requirement that we emit a
context-switch to the perma-pinned i915->kernel_context (so that we can
save the HW state using that context-switch). As the first context
itself may be classed as a kernel context, we want to be explicit in our
comparison. For an extra-layer of finesse, we can check the last
unretired context on the engine; as well as the last retired context
when idle.

v2: verbose verbosity
v3: Always force the switch, even when the engine is idle, and update
the assert that this happens before suspend.

Signed-off-by: Chris Wilson 
Cc: Joonas Lahtinen 
Reviewed-by: Joonas Lahtinen  #v1
Reviewed-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_gem.c| 10 ++
 drivers/gpu/drm/i915/intel_engine_cs.c | 26 --
 2 files changed, 30 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 889ae8810d5f..824515556733 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4693,14 +4693,16 @@ void __i915_gem_object_release_unless_active(struct 
drm_i915_gem_object *obj)
i915_gem_object_put(obj);
 }
 
-static void assert_kernel_context_is_current(struct drm_i915_private *dev_priv)
+static void assert_kernel_context_is_current(struct drm_i915_private *i915)
 {
+   struct i915_gem_context *kernel_context = i915->kernel_context;
struct intel_engine_cs *engine;
enum intel_engine_id id;
 
-   for_each_engine(engine, dev_priv, id)
-   GEM_BUG_ON(engine->last_retired_context &&
-  
!i915_gem_context_is_kernel(engine->last_retired_context));
+   for_each_engine(engine, i915, id) {
+   
GEM_BUG_ON(__i915_gem_active_peek(>timeline->last_request));
+   GEM_BUG_ON(engine->last_retired_context != kernel_context);
+   }
 }
 
 void i915_gem_sanitize(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 0987768c311d..374e398e867a 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1593,10 +1593,32 @@ bool intel_engines_are_idle(struct drm_i915_private 
*dev_priv)
return true;
 }
 
+/**
+ * intel_engine_has_kernel_context:
+ * @engine: the engine
+ *
+ * Returns true if the last context to be executed on this engine, or has been
+ * executed if the engine is already idle, is the kernel context
+ * (#i915.kernel_context).
+ */
 bool intel_engine_has_kernel_context(const struct intel_engine_cs *engine)
 {
-   return (!engine->last_retired_context ||
-   i915_gem_context_is_kernel(engine->last_retired_context));
+   const struct i915_gem_context * const kernel_context =
+   engine->i915->kernel_context;
+   struct drm_i915_gem_request *rq;
+
+   lockdep_assert_held(>i915->drm.struct_mutex);
+
+   /*
+* Check the last context seen by the engine. If active, it will be
+* the last request that remains in the timeline. When idle, it is
+* the last executed context as tracked by retirement.
+*/
+   rq = __i915_gem_active_peek(>timeline->last_request);
+   if (rq)
+   return rq->ctx == kernel_context;
+   else
+   return engine->last_retired_context == kernel_context;
 }
 
 void intel_engines_reset_default_submission(struct drm_i915_private *i915)
-- 
2.15.0

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: implemented dynamic WOPCM partition.

[Ville Syrjälä]

On Fri, Nov 03, 2017 at 05:01:09PM -0700, Jackie Li wrote:
> Static WOPCM partitioning would lead to GuC loading failure
> if the GuC/HuC firmware size exceeded current static 512KB
> partition boundary.
> 
> This patch enabled the dynamical calculation of the WOPCM aperture
> used by GuC/HuC firmware. GuC WOPCM offset was set to
> HuC size + reserved WOPCM size. GuC WOPCM size was set to
> total WOPCM size - GuC WOPCM offset - RC6CTX size.
> 
> Signed-off-by: Jackie Li 
> Cc: Michal Wajdeczko 
> Cc: Sagar Arun Kamble 
> Cc: Sujaritha Sundaresan 
> Reviewed-by: Daniele Ceraolo Spurio 
> Reviewed-by: John Spotswood 
> Reviewed-by: Oscar Mateo 
> ---
>  drivers/gpu/drm/i915/i915_drv.c |  15 
>  drivers/gpu/drm/i915/i915_drv.h |  13 
>  drivers/gpu/drm/i915/i915_gem_context.c |   4 +-
>  drivers/gpu/drm/i915/i915_guc_reg.h |  18 -
>  drivers/gpu/drm/i915/intel_guc.c|  46 ++--
>  drivers/gpu/drm/i915/intel_guc.h|  18 +
>  drivers/gpu/drm/i915/intel_huc.c|   3 +-
>  drivers/gpu/drm/i915/intel_uc.c | 128 
> +++-
>  drivers/gpu/drm/i915/intel_uc_fw.c  |  12 ++-
>  9 files changed, 223 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e7e9e06..19509fd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -623,6 +623,15 @@ static void i915_gem_fini(struct drm_i915_private 
> *dev_priv)
>   WARN_ON(!list_empty(_priv->contexts.list));
>  }
>  
> +static void i915_wopcm_init(struct drm_i915_private *dev_priv)
> +{
> + struct intel_wopcm_info *wopcm = _priv->wopcm;
> +
> + wopcm->size = WOPCM_DEFAULT_SIZE;
> +
> + DRM_DEBUG_DRIVER("WOPCM size: %dKB\n", wopcm->size >> 10);
> +}
> +
>  static int i915_load_modeset_init(struct drm_device *dev)
>  {
>   struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -670,6 +679,12 @@ static int i915_load_modeset_init(struct drm_device *dev)
>   if (ret)
>   goto cleanup_irq;
>  
> + /*
> +  * Get the wopcm memory info.
> +  * NOTE: this need to be called before init FW.
> +  */
> + i915_wopcm_init(dev_priv);

Is this guc wopcm somehow related to the normal wopcm? And if so
are you planning to use the wopcm information we extract from the
hardware in stolen init? If this is just related to the guc then
it would seem better to bury this in some guc code.

> +
>   intel_uc_init_fw(dev_priv);
>  
>   ret = i915_gem_init(dev_priv);

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

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Hide dangerous tests

[Chris Wilson]

Quoting Joonas Lahtinen (2017-11-06 10:47:52)
> On Wed, 2017-10-25 at 16:32 +0100, Chris Wilson wrote:
> > Some tests are designed to exercise the limits of the HW and may trigger
> > unintended side-effects making the machine unusable. This should not be
> > executed by default, but are still useful for early platform validation.
> > 
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=103453
> > Signed-off-by: Chris Wilson 
> > Cc: Joonas Lahtinen 
> 
> Reviewed-by: Joonas Lahtinen 

Applied and closed bug, so hopefully one less blocker towards getting
selftests being run.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Lock llist_del_first() vs llist_del_all()

[Chris Wilson]

Quoting Mika Kuoppala (2017-11-06 11:46:16)
> Chris Wilson  writes:
> 
> > An oversight in commit 87701b4b5593 ("drm/i915: Only free the oldest
> > stale object before a fresh allocation") was that not only do we have to
> > serialise concurrent users of llist_del_first(), but we also have to
> > lock llist_del_first() vs llist_del_all().
> >
> > From llist.h,
> >
> >  * This can be summarized as follows:
> >  *
> >  *   |   add| del_first |  del_all
> >  * add   |- | - | -
> >  * del_first |  | L | L
> >  * del_all   |  |   | -
> >  *
> >  * Where, a particular row's operation can happen concurrently with a 
> > column's
> >  * operation, with "-" being no lock needed, while "L" being lock is needed.
> >
> > This should hopefully explain:
> >
> > <4>[   89.287106] general protection fault:  [#1] PREEMPT SMP
> > <4>[   89.287126] Modules linked in: snd_hda_codec_hdmi 
> > snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal 
> > intel_powerclamp coretemp i915 crct10dif_pclmul crc32_pclmul 
> > ghash_clmulni_intel snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core 
> > r8169 mii mei_me mei snd_pcm prime_numbers i2c_hid pinctrl_geminilake 
> > pinctrl_intel
> > <4>[   89.287226] CPU: 2 PID: 23 Comm: ksoftirqd/2 Tainted: G U 
> >  4.14.0-rc8-CI-CI_DRM_3315+ #1
> > <4>[   89.287247] Hardware name: Intel Corp. Geminilake/GLK RVP2 LP4SD 
> > (07), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017
> > <4>[   89.287270] task: 88017ab34ec0 task.stack: c9128000
> > <4>[   89.287290] RIP: 0010:llist_add_batch+0x4/0x20
> > <4>[   89.287301] RSP: 0018:c912bdb8 EFLAGS: 00010296
> > <4>[   89.287314] RAX: 811017ad RBX: 6e468801a156 RCX: 
> > ef3e53fceecdeb81
> > <4>[   89.287330] RDX: 6e468801a1566130 RSI: 880103d73d98 RDI: 
> > 880103d73d98
> > <4>[   89.287346] RBP: c912bdb8 R08: 88017ab35780 R09: 
> > 
> > <4>[   89.287361] R10: c912bd68 R11: abb18c3d R12: 
> > a01369e0
> > <4>[   89.287377] R13: 88017fd1b8f8 R14: 88017ab34ec0 R15: 
> > 000a
> > <4>[   89.287393] FS:  () GS:88017fd0() 
> > knlGS:
> > <4>[   89.287411] CS:  0010 DS:  ES:  CR0: 80050033
> > <4>[   89.287424] CR2: 7ff0c0755018 CR3: 00016df9b000 CR4: 
> > 003406e0
> > <4>[   89.287440] Call Trace:
> > <4>[   89.287511]  __i915_gem_free_object_rcu+0x20/0x40 [i915]
> > <4>[   89.287527]  rcu_process_callbacks+0x27a/0x730
> > <4>[   89.287544]  __do_softirq+0xc0/0x4ae
> > <4>[   89.287559]  ? smpboot_thread_fn+0x2d/0x280
> > <4>[   89.287571]  run_ksoftirqd+0x1f/0x70
> > <4>[   89.287582]  smpboot_thread_fn+0x18a/0x280
> > <4>[   89.287595]  kthread+0x114/0x150
> > <4>[   89.287605]  ? sort_range+0x30/0x30
> > <4>[   89.287615]  ? kthread_create_on_node+0x40/0x40
> > <4>[   89.287628]  ret_from_fork+0x27/0x40
> > <4>[   89.287641] Code: 0d 48 83 ea 01 4c 89 c1 48 83 fa ff 74 12 48 23 0c 
> > d7 74 ed 48 c1 e2 06 48 0f bd c9 48 8d 04 0a 5d c3 90 90 90 90 90 55 48 89 
> > e5 <48> 8b 0a 48 89 0e 48 89 c8 f0 48 0f b1 3a 48 39 c1 75 ed 48 85
> > <1>[   89.287774] RIP: llist_add_batch+0x4/0x20 RSP: c912bdb8
> > <4>[   89.287826] ---[ end trace e775d15174d8ae02 ]---
> >
> > (Lockless lists are only easy (and lockless) when using
> > llist_add/llist_del_all!)
> >
> > Fixes: 87701b4b5593 ("drm/i915: Only free the oldest stale object before
> > a fresh allocation")
> > Signed-off-by: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: Joonas Lahtinen 
> 
> Similar usage pattern in contexts but the paths are
> under mutex.
> 
> Reviewed-by: Mika Kuoppala 

Thanks for the review, pushed. Hopefully that catches it before it crops
up too many times.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Lock llist_del_first() vs llist_del_all() (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Lock llist_del_first() vs llist_del_all() (rev2)
URL   : https://patchwork.freedesktop.org/series/33241/
State : success

== Summary ==

Test drv_module_reload:
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (shard-hsw) fdo#102707
Test kms_setmode:
Subgroup basic:
pass   -> FAIL   (shard-hsw) fdo#99912
Test kms_flip:
Subgroup wf_vblank-vs-dpms-interruptible:
incomplete -> PASS   (shard-hsw) fdo#102614

fdo#102707 https://bugs.freedesktop.org/show_bug.cgi?id=102707
fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614

shard-hswtotal:2539 pass:1432 dwarn:1   dfail:0   fail:9   skip:1097 
time:9313s

== Logs ==

For more details see: 
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6970/shards.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 02/20] drm/i915: Move a bunch of workaround-related code to its own file

[Joonas Lahtinen]

On Mon, 2017-11-06 at 12:42 +, Chris Wilson wrote:
> Quoting Oscar Mateo (2017-11-03 18:09:30)
> > This has grown to be a sizable amount of code, so move it to
> > its own file before we try to refactor anything. For the moment,
> > we are leaving behind the WA BB code and the WAs that get applied
> > (incorrectly) in init_clock_gating, but we will deal with it later.
> > 
> > v2: Use intel_ prefix for code that deals with the hardware (Chris)
> > v3: Rebased
> > 
> > Signed-off-by: Oscar Mateo 
> > Cc: Chris Wilson 
> > Cc: Mika Kuoppala 
> 
> I would like to start on this reclassifications of w/a early; even just
> moving the current set of register writes into the right groups should
> be a massive help wrt to our confused init ordering.
> 
> Anyone object to moving the existing code around before we get the
> universal solution?

Nope, I was actually going to suggest getting the first patches merged
first. Then it'll then be easier to spin RFCs.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 02/20] drm/i915: Move a bunch of workaround-related code to its own file

[Chris Wilson]

Quoting Oscar Mateo (2017-11-03 18:09:30)
> This has grown to be a sizable amount of code, so move it to
> its own file before we try to refactor anything. For the moment,
> we are leaving behind the WA BB code and the WAs that get applied
> (incorrectly) in init_clock_gating, but we will deal with it later.
> 
> v2: Use intel_ prefix for code that deals with the hardware (Chris)
> v3: Rebased
> 
> Signed-off-by: Oscar Mateo 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 

I would like to start on this reclassifications of w/a early; even just
moving the current set of register writes into the right groups should
be a massive help wrt to our confused init ordering.

Anyone object to moving the existing code around before we get the
universal solution?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 01/20] drm/i915: Remove Gen9 WAs with no effect

[Chris Wilson]

Quoting Oscar Mateo (2017-11-03 18:09:29)
> GEN8_CONFIG0 (0xD00) is a protected by a lock (bit 31) which is set by
> the BIOS, so there is no way we can enable the three chicken bits
> mandated by the WA (the BIOS should be doing it instead).
> 
> v2: Rebased
> v3: Standalone patch
> 
> Signed-off-by: Oscar Mateo 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 

Mika, could you do the honours to get this out of the way?
-Chris
___
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: Assert guc->stage_desc_pool is allocated

[Patchwork]

== Series Details ==

Series: drm/i915: Assert guc->stage_desc_pool is allocated
URL   : https://patchwork.freedesktop.org/series/33248/
State : success

== Summary ==

Series 33248v1 drm/i915: Assert guc->stage_desc_pool is allocated
https://patchwork.freedesktop.org/api/1.0/series/33248/revisions/1/mbox/

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:443s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:458s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:380s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:551s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:275s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:503s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:505s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:504s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:502s
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:559s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:604s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:426s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:259s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:590s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:493s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:431s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:428s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:427s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:502s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:463s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:575s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:481s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:588s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:565s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:452s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:601s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:656s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:515s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:506s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:468s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:574s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:421s

9cc9686b44e192d2561a513f84d5ac95518cad73 drm-tip: 2017y-11m-06d-10h-10m-17s UTC 
integration manifest
b00a7e7864a7 drm/i915: Assert guc->stage_desc_pool is allocated

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6972/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: i915: remove timeval users

[Patchwork]

== Series Details ==

Series: drm: i915: remove timeval users
URL   : https://patchwork.freedesktop.org/series/33147/
State : failure

== Summary ==

Series 33147v1 drm: i915: remove timeval users
https://patchwork.freedesktop.org/api/1.0/series/33147/revisions/1/mbox/

Test kms_addfb_basic:
Subgroup bad-pitch-32:
pass   -> FAIL   (fi-glk-dsi)
Subgroup bad-pitch-63:
pass   -> INCOMPLETE (fi-glk-dsi)
Test kms_flip:
Subgroup basic-plain-flip:
pass   -> INCOMPLETE (fi-cnl-y)
Test kms_frontbuffer_tracking:
Subgroup basic:
pass   -> INCOMPLETE (fi-cfl-s)
Test kms_pipe_crc_basic:
Subgroup read-crc-pipe-b-frame-sequence:
pass   -> SKIP   (fi-hsw-4770r) fdo#102332

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

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:445s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:455s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:380s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:542s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:276s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:511s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:497s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:504s
fi-cfl-s total:225  pass:199  dwarn:0   dfail:0   fail:0   skip:25 
fi-cnl-y total:220  pass:199  dwarn:0   dfail:0   fail:0   skip:20 
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:427s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:263s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:591s
fi-glk-dsi   total:182  pass:158  dwarn:0   dfail:0   fail:1   skip:22 
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:434s
fi-hsw-4770r total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:440s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:436s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:502s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:464s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:576s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:482s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:589s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:574s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:457s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:593s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:650s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:518s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:506s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:467s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:577s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:421s
fi-byt-n2820 failed to connect after reboot

9cc9686b44e192d2561a513f84d5ac95518cad73 drm-tip: 2017y-11m-06d-10h-10m-17s UTC 
integration manifest
815e64ed395b drm: i915: remove timeval users

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6971/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/i915/guc: Release all client doorbells on suspend and acquire on resume

[Chris Wilson]

Quoting Sagar Arun Kamble (2017-11-05 13:39:40)
> Before GT device suspend, i915 should release GuC client doorbells by
> stopping doorbell controller snooping and doorbell deallocation through
> GuC. They need to be acquired again on resume. This will also resolve
> the driver unload issue with GuC, where doorbell deallocation was being
> done post GEM suspend.
> Release function is called from guc_suspend prior to sending sleep action
> during runtime and drm suspend. Acquiral is different in runtime and drm
> resume paths as on drm resume we are currently doing full reinit. Release
> should be done in synchronization with acquire hence GuC suspend/resume
> along with doorbell release/acquire should be under struct_mutex. Upcoming
> suspend and resume restructuring for GuC will update these changes.
> 
> Signed-off-by: Sagar Arun Kamble 
> Cc: Chris Wilson 
> Cc: Michał Winiarski 
> Cc: Michel Thierry 
> Cc: Michal Wajdeczko 
> Cc: Arkadiusz Hiler 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_drv.c|  3 +++
>  drivers/gpu/drm/i915/i915_gem.c|  5 +++--
>  drivers/gpu/drm/i915/i915_guc_submission.c | 20 
>  drivers/gpu/drm/i915/i915_guc_submission.h |  2 ++
>  drivers/gpu/drm/i915/intel_guc.c   |  2 ++
>  5 files changed, 26 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e7e9e06..3df8a7d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -47,6 +47,7 @@
>  #include 
>  
>  #include "i915_drv.h"
> +#include "i915_guc_submission.h"
>  #include "i915_trace.h"
>  #include "i915_vgpu.h"
>  #include "intel_drv.h"
> @@ -2615,6 +2616,8 @@ static int intel_runtime_resume(struct device *kdev)
>  
> intel_guc_resume(dev_priv);
>  
> +   i915_guc_clients_acquire_doorbells(_priv->guc);

intel_guc_acquire_doorbells();

Though, if we need to specialise between resume and runtime_resume, I
suggest adding intel_guc_resume() and intel_guc_runtime_resume() entry
points. (We probably should find a better way to distinguish those two
paths, system_resume vs runtime_resume?)
-Chris
___
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: Lock llist_del_first() vs llist_del_all() (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Lock llist_del_first() vs llist_del_all() (rev2)
URL   : https://patchwork.freedesktop.org/series/33241/
State : success

== Summary ==

Series 33241v2 drm/i915: Lock llist_del_first() vs llist_del_all()
https://patchwork.freedesktop.org/api/1.0/series/33241/revisions/2/mbox/

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:454s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:455s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:380s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:557s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:278s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:508s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:507s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:488s
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:544s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:616s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:424s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:271s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:586s
fi-glk-dsi   total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  
time:493s
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:436s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:431s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:435s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:500s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:463s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:575s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:480s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:585s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:576s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:454s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:603s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:651s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:521s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:511s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:465s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:569s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:431s

9cc9686b44e192d2561a513f84d5ac95518cad73 drm-tip: 2017y-11m-06d-10h-10m-17s UTC 
integration manifest
7d117513f2a4 drm/i915: Lock llist_del_first() vs llist_del_all()

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_6970/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 04/20] drm/i915: Transform context WAs into static tables

[Joonas Lahtinen]

On Fri, 2017-11-03 at 11:09 -0700, Oscar Mateo wrote:
> This is for WAs that need to touch registers that get saved/restored
> together with the logical context. The idea is that WAs are "pretty"
> static, so a table is more declarative than a programmatic approah.
> Note however that some amount is caching is needed for those things
> that are dynamic (e.g. things that need some calculation, or have
> a criteria different than the more obvious GEN + stepping).
> 
> Also, this makes very explicit which WAs live in the context.
> 
> Suggested-by: Joonas Lahtinen 
> Signed-off-by: Oscar Mateo 
> Cc: Chris Wilson 
> Cc: Mika Kuoppala 



> +struct i915_wa_reg;
> +
> +typedef bool (* wa_pre_hook_func)(struct drm_i915_private *dev_priv,
> +   struct i915_wa_reg *wa);
> +typedef void (* wa_post_hook_func)(struct drm_i915_private *dev_priv,
> +struct i915_wa_reg *wa);

To avoid carrying any variables over, how about just apply() hook?
Also, you don't have to have "_hook" going there, it's tak

>  struct i915_wa_reg {
> + const char *name;

We may want some Kconfig option for skipping these.

> + enum wa_type {
> + I915_WA_TYPE_CONTEXT = 0,
> + I915_WA_TYPE_GT,
> + I915_WA_TYPE_DISPLAY,
> + I915_WA_TYPE_WHITELIST
> + } type;
> +

Any specific reason not to have the gen here too? Then you can have one
big table, instead of tables of tables. Then the numeric code of a WA
(position in that table) would be equally identifying it compared to
the WA name (which is nice to have information, so config time opt-in).

> + u8 since;
> + u8 until;

Most seem to have ALL_REVS, so this could be after the coarse-grained
gen-check in the apply function.

> +
>   i915_reg_t addr;
> - u32 value;
> - /* bitmask representing WA bits */
>   u32 mask;
> + u32 value;
> + bool is_masked_reg;

I'd hide this detail into the apply function.

> +
> + wa_pre_hook_func pre_hook;
> + wa_post_hook_func post_hook;

bool (*apply)(const struct i915_wa *wa,
  struct drm_i915_private *dev_priv);

> + u32 hook_data;
> + bool applied;

The big point would be to make this into const, so "applied" would
defeat that.



> +#define MASK(mask, value)((mask) << 16 | (value))
> +#define MASK_ENABLE(x)   (MASK((x), (x)))
> +#define MASK_DISABLE(x)  (MASK((x), 0))
>  
> -#define WA_REG(addr, mask, val) do { \
> - const int r = wa_add(dev_priv, (addr), (mask), (val)); \
> - if (r) \
> - return r; \
> - } while (0)
> +#define SET_BIT_MASKED(m)\
> + .mask = (m),\
> + .value = MASK_ENABLE(m),\
> + .is_masked_reg = true
>  
> -#define WA_SET_BIT_MASKED(addr, mask) \
> - WA_REG(addr, (mask), _MASKED_BIT_ENABLE(mask))
> +#define CLEAR_BIT_MASKED( m) \
> + .mask = (m),\
> + .value = MASK_DISABLE(m),   \
> + .is_masked_reg = true
>  
> -#define WA_CLR_BIT_MASKED(addr, mask) \
> - WA_REG(addr, (mask), _MASKED_BIT_DISABLE(mask))
> +#define SET_FIELD_MASKED(m, v)   \
> + .mask = (m),\
> + .value = MASK(m, v),\
> + .is_masked_reg = true

Lets try to have the struct i915_wa as small as possible, so this could
be calculated in the apply function.

So, avoiding the macros this would indeed become rather declarative;

{
WA_NAME("WaDisableAsyncFlipPerfMode")
.gen = ...,
.reg = MI_MODE,
.value = ASYNC_FLIP_PERF_DISABLE,
.apply = set_bit_masked,
},

Or, we could also have;

static const struct i915_wa WaDisableAsyncFlipPerfMode = {
.gen = ...,
.reg = MI_MODE,
.value = ASYNC_FLIP_PERF_DISABLE,
.apply = set_bit_masked,
};

And then one array of those.

WA(WaDisableAsyncFlipPerfMode),

Then you could at compile time decide if you stringify and store the
name. But that'd be more const data than necessary (pointers to
structs, instead of an array of structs).

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Assert guc->stage_desc_pool is allocated

[Chris Wilson]

Silence smatch by demonstrating that guc->stage_desc_pool is allocated
following a successful guc_stage_desc_pool_create()

drivers/gpu/drm/i915/i915_guc_submission.c:1293 i915_guc_submission_init() 
error: we previously assumed 'guc->stage_desc_pool' could be null (see line 1261

Signed-off-by: Chris Wilson 
Cc: Oscar Mateo 
Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index d14c1342f09d..6f2548114bd2 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1265,10 +1265,18 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
if (ret)
return ret;
 
+   /*
+* Keep static analysers happy, let them know that we allocated the
+* vma after testing that it didn't exist earlier.
+*/
+   GEM_BUG_ON(!guc->stage_desc_pool);
+
ret = guc_shared_data_create(guc);
if (ret)
goto err_stage_desc_pool;
 
+   GEM_BUG_ON(!guc->shared_data);
+
ret = intel_guc_log_create(guc);
if (ret < 0)
goto err_shared_data;
@@ -1277,10 +1285,14 @@ int i915_guc_submission_init(struct drm_i915_private 
*dev_priv)
if (ret)
goto err_log;
 
+   GEM_BUG_ON(!guc->preempt_wq);
+
ret = guc_ads_create(guc);
if (ret < 0)
goto err_wq;
 
+   GEM_BUG_ON(!guc->ads_vma);
+
return 0;
 
 err_wq:
-- 
2.15.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Lock llist_del_first() vs llist_del_all()

[Mika Kuoppala]

Chris Wilson  writes:

> An oversight in commit 87701b4b5593 ("drm/i915: Only free the oldest
> stale object before a fresh allocation") was that not only do we have to
> serialise concurrent users of llist_del_first(), but we also have to
> lock llist_del_first() vs llist_del_all().
>
> From llist.h,
>
>  * This can be summarized as follows:
>  *
>  *   |   add| del_first |  del_all
>  * add   |- | - | -
>  * del_first |  | L | L
>  * del_all   |  |   | -
>  *
>  * Where, a particular row's operation can happen concurrently with a column's
>  * operation, with "-" being no lock needed, while "L" being lock is needed.
>
> This should hopefully explain:
>
> <4>[   89.287106] general protection fault:  [#1] PREEMPT SMP
> <4>[   89.287126] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek 
> snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp i915 
> crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec 
> snd_hwdep snd_hda_core r8169 mii mei_me mei snd_pcm prime_numbers i2c_hid 
> pinctrl_geminilake pinctrl_intel
> <4>[   89.287226] CPU: 2 PID: 23 Comm: ksoftirqd/2 Tainted: G U  
> 4.14.0-rc8-CI-CI_DRM_3315+ #1
> <4>[   89.287247] Hardware name: Intel Corp. Geminilake/GLK RVP2 LP4SD (07), 
> BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017
> <4>[   89.287270] task: 88017ab34ec0 task.stack: c9128000
> <4>[   89.287290] RIP: 0010:llist_add_batch+0x4/0x20
> <4>[   89.287301] RSP: 0018:c912bdb8 EFLAGS: 00010296
> <4>[   89.287314] RAX: 811017ad RBX: 6e468801a156 RCX: 
> ef3e53fceecdeb81
> <4>[   89.287330] RDX: 6e468801a1566130 RSI: 880103d73d98 RDI: 
> 880103d73d98
> <4>[   89.287346] RBP: c912bdb8 R08: 88017ab35780 R09: 
> 
> <4>[   89.287361] R10: c912bd68 R11: abb18c3d R12: 
> a01369e0
> <4>[   89.287377] R13: 88017fd1b8f8 R14: 88017ab34ec0 R15: 
> 000a
> <4>[   89.287393] FS:  () GS:88017fd0() 
> knlGS:
> <4>[   89.287411] CS:  0010 DS:  ES:  CR0: 80050033
> <4>[   89.287424] CR2: 7ff0c0755018 CR3: 00016df9b000 CR4: 
> 003406e0
> <4>[   89.287440] Call Trace:
> <4>[   89.287511]  __i915_gem_free_object_rcu+0x20/0x40 [i915]
> <4>[   89.287527]  rcu_process_callbacks+0x27a/0x730
> <4>[   89.287544]  __do_softirq+0xc0/0x4ae
> <4>[   89.287559]  ? smpboot_thread_fn+0x2d/0x280
> <4>[   89.287571]  run_ksoftirqd+0x1f/0x70
> <4>[   89.287582]  smpboot_thread_fn+0x18a/0x280
> <4>[   89.287595]  kthread+0x114/0x150
> <4>[   89.287605]  ? sort_range+0x30/0x30
> <4>[   89.287615]  ? kthread_create_on_node+0x40/0x40
> <4>[   89.287628]  ret_from_fork+0x27/0x40
> <4>[   89.287641] Code: 0d 48 83 ea 01 4c 89 c1 48 83 fa ff 74 12 48 23 0c d7 
> 74 ed 48 c1 e2 06 48 0f bd c9 48 8d 04 0a 5d c3 90 90 90 90 90 55 48 89 e5 
> <48> 8b 0a 48 89 0e 48 89 c8 f0 48 0f b1 3a 48 39 c1 75 ed 48 85
> <1>[   89.287774] RIP: llist_add_batch+0x4/0x20 RSP: c912bdb8
> <4>[   89.287826] ---[ end trace e775d15174d8ae02 ]---
>
> (Lockless lists are only easy (and lockless) when using
> llist_add/llist_del_all!)
>
> Fixes: 87701b4b5593 ("drm/i915: Only free the oldest stale object before
> a fresh allocation")
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Joonas Lahtinen 

Similar usage pattern in contexts but the paths are
under mutex.

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_gem.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 6a71805be389..889ae8810d5f 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4636,11 +4636,17 @@ static void __i915_gem_free_work(struct work_struct 
> *work)
>* unbound now.
>*/
>  
> + spin_lock(>mm.free_lock);
>   while ((freed = llist_del_all(>mm.free_list))) {
> + spin_unlock(>mm.free_lock);
> +
>   __i915_gem_free_objects(i915, freed);
>   if (need_resched())
> - break;
> + return;
> +
> + spin_lock(>mm.free_lock);
>   }
> + spin_unlock(>mm.free_lock);
>  }
>  
>  static void __i915_gem_free_object_rcu(struct rcu_head *head)
> -- 
> 2.15.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Patch tag ordering (Was: Re: [PATCH v5 2/5] drm/i915/guc : Removing i915_modparams.enable_guc_loading module)

[Jani Nikula]

On Mon, 06 Nov 2017, Joonas Lahtinen  wrote:
> + Jani (and Daniel as emeritus maintainer)
>
> On Fri, 2017-11-03 at 10:08 -0700, Rodrigo Vivi wrote:
>> On Fri, Nov 03, 2017 at 08:36:01AM +, Joonas Lahtinen wrote:
>> > On Fri, 2017-11-03 at 00:03 +, Chris Wilson wrote:
>> > > Quoting Rodrigo Vivi (2017-11-02 23:52:45)
>> > > > On Wed, Oct 4, 2017 at 6:07 AM, Joonas Lahtinen
>> > > >  wrote:
>> > > > > On Tue, 2017-10-03 at 15:56 -0700, Sujaritha Sundaresan wrote:
>> > > > > > We currently have two module parameters that control GuC: 
>> > > > > > "enable_guc_loading" and "enable_guc_submission".
>> > > > > > Whenever we need i915_modparams.enable_guc_submission=1, we also 
>> > > > > > need enable_guc_loading=1.
>> > > > > > We also need enable_guc_loading=1 when we want to verify the HuC,
>> > > > > > which is every time we have a HuC (but all platforms with HuC have 
>> > > > > > a GuC and viceversa).
>> > > > > 
>> > > > > Long lines in commit message, please give a look at:
>> > > > > 
>> > > > > https://www.kernel.org/doc/html/v4.13/process/submitting-patches.html
>> > > > > 
>> > > > > Section "14) The canonical patch format".
>> > > > > 
>> > > > > Then, about the patch. I think the commit message should be more 
>> > > > > clear
>> > > > > about the fact that if we have HuC firmware to be loaded, we need to
>> > > > > have GuC to actually load it. So if an user wants to avoid the GuC 
>> > > > > from
>> > > > > getting loaded, they must not have a HuC firmware to be loaded, in
>> > > > > addition to not using GuC submission.
>> > > > > 
>> > > > > > 
>> > > > > > v2: Clarifying the commit message (Anusha)
>> > > > > > 
>> > > > > > v3: Unify seq_puts messages, Re-factoring code as per review 
>> > > > > > (Michal)
>> > > > > > 
>> > > > > > v4: Rebase
>> > > > > > 
>> > > > > > v5: Separating message unification into a separate patch
>> > > > > > 
>> > > > > > Cc: Michal Wajdeczko 
>> > > > > > Cc: Anusha Srivatsa 
>> > > > > > Cc: Oscar Mateo 
>> > > > > > Cc: Sagar Arun Kamble 
>> > > > > > Signed-off-by: Sujaritha Sundaresan 
>> > > > > > 
>> > > > > 
>> > > > > Try to keep the tags in chronological order, so start with Suggested-
>> > > > > by: (if any), Signed-off-by:, Cc: and so on.
>> > > > 
>> > > > Could we agree on have
>> > > > Suggested-by:
>> > > > Cc:
>> > > > Signed-off-by:
>> > > > as the initial chronological order and then follow the chronological
>> > > 
>> > > But CCs come after a s-o-b, because they are added after the commit. (I
>> > > write some code, then think who might be interested; usually by looking
>> > > at who previously worked on the same code). Then you also add new CCs
>> > > later on based on review feedback; a comment on v1 gets a CC on v2.
>> > > Bugzilla/reported-by/suggested-by are before since they presumably
>> > > prompted the commit to be written in the first place (plus also they
>> > > deserve extra credit for their effort in alerting us to the issue).
>> > 
>> > Yeah, this is my reasoning too.
>> 
>> So it seems the chronological order differs from case to case
>> from person to person.
>> When I write a patch most of the times I have people in mind
>> that I will cc. Like when I'm writing an email.
>> cc: people that touch this code from last time
>> cc: people that can help on review
>> cc: people that introduced this error
>> cc: people that will be futurely impacted by this change
>
> I don't follow this logic. Most of the Cc:s are chosen based on what
> the code does, in get_maintainers.pl fashion. I think one is set to
> implement a feature/bugfix, and it is not necessarily certain in the
> beginning where the code will land, could be core kernel, DRM or i915
> even. And Cc:s will vary accordingly depending on where the code
> landed.
>
> I can see an argument for some Cc:s before Signed-off-by:, but I never
> claimed that wouldn't be the case. Just that chronological ordering
> makes sense (will be easy to automate, too).
>
> I would claim that all of the four points you listed, you'll be looking
> at git blame based on what the code you wrote changed. And you don't
> know the whole scope of code in advance except for really small fixes.
> Where you wrote the code in your mind already. And it's really the IP
> you're S-o-b:ing. But this gets pretty theoritical already.
>
>> and then I sign-off on the end of the patch as I sign off in the
>> end of a message.
>> 
>> > 
>> > Also, when you add the machine assistance from Patchwork to
>> > automatically spread tags from the cover letter (Acked-by, Reviewed-by
>> > etc. and it's in the works, I understand). I don't quite see why we
>> > would have only a portion of the tags in chronological order.
>> > 
>> > If I respin a patch, it might already have:
>> > 
>> > Bugzilla:
>> > Suggested-by:
>> 

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Introduce GEM proxy

[Joonas Lahtinen]

On Wed, 2017-11-01 at 17:22 +0800, Tina Zhang wrote:
> GEM proxy is a kind of GEM, whose backing physical memory is pinned
> and produced by guest VM and is used by host as read only. With GEM
> proxy, host is able to access guest physical memory through GEM object
> interface. As GEM proxy is such a special kind of GEM, a new flag
> I915_GEM_OBJECT_IS_PROXY is introduced to ban host from changing the
> backing storage of GEM proxy.
> 
> v2:
> - return -ENXIO when pin and map pages of GEM proxy to kernel space.
>   (Chris)
> 
> Here are the histories of this patch in "Dma-buf support for Gvt-g"
> patch-set:
> 
> v14:
> - return -ENXIO when gem proxy object is banned by ioctl.
>   (Chris) (Daniel)
> 
> v13:
> - add comments to GEM proxy. (Chris)
> - don't ban GEM proxy in i915_gem_sw_finish_ioctl. (Chris)
> - check GEM proxy bar after finishing i915_gem_object_wait. (Chris)
> - remove GEM proxy bar in i915_gem_madvise_ioctl.
> 
> v6:
> - add gem proxy barrier in the following ioctls. (Chris)
>   i915_gem_set_caching_ioctl
>   i915_gem_set_domain_ioctl
>   i915_gem_sw_finish_ioctl
>   i915_gem_set_tiling_ioctl
>   i915_gem_madvise_ioctl
> 
> Signed-off-by: Tina Zhang 
> Reviewed-by: Joonas Lahtinen 
> Reviewed-by: Chris Wilson 
> Cc: Daniel Vetter 



> @@ -1649,6 +1659,10 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void 
> *data,
>   if (!obj)
>   return -ENOENT;
>  
> + /* Proxy objects are barred from CPU access, so there is no
> +  * need to ban sw_finish as it is a nop.
> +  */
> +
>   /* Pinned buffers may be scanout, so flush the cache */
>   i915_gem_object_flush_if_display(obj);
>   i915_gem_object_put(obj);
> @@ -2614,7 +2628,8 @@ void *i915_gem_object_pin_map(struct 
> drm_i915_gem_object *obj,
>   void *ptr;
>   int ret;
>  
> - GEM_BUG_ON(!i915_gem_object_has_struct_page(obj));
> + if (unlikely(!i915_gem_object_has_struct_page(obj)))
> + return ERR_PTR(-ENODEV);

You should have marked this change in the changelog and then marked the
Reviewed-by tags to be valid only to the previous version of this
patch.

It's not a fair game to claim a patch to be "Reviewed-by" at the
current version, when you've made changes that were not agreed upon.

So that's some meta-review. Back to the actual review;

Which codepath was hitting the GEM_BUG_ON? Wondering if it would be
cleaner to avoid the call to this function on that single codepath.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Lock llist_del_first() vs llist_del_all()

[Chris Wilson]

An oversight in commit 87701b4b5593 ("drm/i915: Only free the oldest
stale object before a fresh allocation") was that not only do we have to
serialise concurrent users of llist_del_first(), but we also have to
lock llist_del_first() vs llist_del_all().

From llist.h,

 * This can be summarized as follows:
 *
 *   |   add| del_first |  del_all
 * add   |- | - | -
 * del_first |  | L | L
 * del_all   |  |   | -
 *
 * Where, a particular row's operation can happen concurrently with a column's
 * operation, with "-" being no lock needed, while "L" being lock is needed.

This should hopefully explain:

<4>[   89.287106] general protection fault:  [#1] PREEMPT SMP
<4>[   89.287126] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp i915 
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec 
snd_hwdep snd_hda_core r8169 mii mei_me mei snd_pcm prime_numbers i2c_hid 
pinctrl_geminilake pinctrl_intel
<4>[   89.287226] CPU: 2 PID: 23 Comm: ksoftirqd/2 Tainted: G U  
4.14.0-rc8-CI-CI_DRM_3315+ #1
<4>[   89.287247] Hardware name: Intel Corp. Geminilake/GLK RVP2 LP4SD (07), 
BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017
<4>[   89.287270] task: 88017ab34ec0 task.stack: c9128000
<4>[   89.287290] RIP: 0010:llist_add_batch+0x4/0x20
<4>[   89.287301] RSP: 0018:c912bdb8 EFLAGS: 00010296
<4>[   89.287314] RAX: 811017ad RBX: 6e468801a156 RCX: 
ef3e53fceecdeb81
<4>[   89.287330] RDX: 6e468801a1566130 RSI: 880103d73d98 RDI: 
880103d73d98
<4>[   89.287346] RBP: c912bdb8 R08: 88017ab35780 R09: 

<4>[   89.287361] R10: c912bd68 R11: abb18c3d R12: 
a01369e0
<4>[   89.287377] R13: 88017fd1b8f8 R14: 88017ab34ec0 R15: 
000a
<4>[   89.287393] FS:  () GS:88017fd0() 
knlGS:
<4>[   89.287411] CS:  0010 DS:  ES:  CR0: 80050033
<4>[   89.287424] CR2: 7ff0c0755018 CR3: 00016df9b000 CR4: 
003406e0
<4>[   89.287440] Call Trace:
<4>[   89.287511]  __i915_gem_free_object_rcu+0x20/0x40 [i915]
<4>[   89.287527]  rcu_process_callbacks+0x27a/0x730
<4>[   89.287544]  __do_softirq+0xc0/0x4ae
<4>[   89.287559]  ? smpboot_thread_fn+0x2d/0x280
<4>[   89.287571]  run_ksoftirqd+0x1f/0x70
<4>[   89.287582]  smpboot_thread_fn+0x18a/0x280
<4>[   89.287595]  kthread+0x114/0x150
<4>[   89.287605]  ? sort_range+0x30/0x30
<4>[   89.287615]  ? kthread_create_on_node+0x40/0x40
<4>[   89.287628]  ret_from_fork+0x27/0x40
<4>[   89.287641] Code: 0d 48 83 ea 01 4c 89 c1 48 83 fa ff 74 12 48 23 0c d7 
74 ed 48 c1 e2 06 48 0f bd c9 48 8d 04 0a 5d c3 90 90 90 90 90 55 48 89 e5 <48> 
8b 0a 48 89 0e 48 89 c8 f0 48 0f b1 3a 48 39 c1 75 ed 48 85
<1>[   89.287774] RIP: llist_add_batch+0x4/0x20 RSP: c912bdb8
<4>[   89.287826] ---[ end trace e775d15174d8ae02 ]---

(Lockless lists are only easy (and lockless) when using
llist_add/llist_del_all!)

Fixes: 87701b4b5593 ("drm/i915: Only free the oldest stale object before
a fresh allocation")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6a71805be389..889ae8810d5f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4636,11 +4636,17 @@ static void __i915_gem_free_work(struct work_struct 
*work)
 * unbound now.
 */
 
+   spin_lock(>mm.free_lock);
while ((freed = llist_del_all(>mm.free_list))) {
+   spin_unlock(>mm.free_lock);
+
__i915_gem_free_objects(i915, freed);
if (need_resched())
-   break;
+   return;
+
+   spin_lock(>mm.free_lock);
}
+   spin_unlock(>mm.free_lock);
 }
 
 static void __i915_gem_free_object_rcu(struct rcu_head *head)
-- 
2.15.0

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

[Intel-gfx] [PATCH] drm/i915: Lock llist_del_first() vs llist_del_all()

[Chris Wilson]

An oversight in commit 87701b4b5593 ("drm/i915: Only free the oldest
stale object before a fresh allocation") was that not only do we have to
serialise concurrent users of llist_del_first(), but we also have to
lock llist_del_first() vs llist_del_all().

From llist.h,

 * This can be summarized as follows:
 *
 *   |   add| del_first |  del_all
 * add   |- | - | -
 * del_first |  | L | L
 * del_all   |  |   | -
 *
 * Where, a particular row's operation can happen concurrently with a column's
 * operation, with "-" being no lock needed, while "L" being lock is needed.

This should hopefully explain:

<4>[   89.287106] general protection fault:  [#1] PREEMPT SMP
<4>[   89.287126] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp i915 
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_intel snd_hda_codec 
snd_hwdep snd_hda_core r8169 mii mei_me mei snd_pcm prime_numbers i2c_hid 
pinctrl_geminilake pinctrl_intel
<4>[   89.287226] CPU: 2 PID: 23 Comm: ksoftirqd/2 Tainted: G U  
4.14.0-rc8-CI-CI_DRM_3315+ #1
<4>[   89.287247] Hardware name: Intel Corp. Geminilake/GLK RVP2 LP4SD (07), 
BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017
<4>[   89.287270] task: 88017ab34ec0 task.stack: c9128000
<4>[   89.287290] RIP: 0010:llist_add_batch+0x4/0x20
<4>[   89.287301] RSP: 0018:c912bdb8 EFLAGS: 00010296
<4>[   89.287314] RAX: 811017ad RBX: 6e468801a156 RCX: 
ef3e53fceecdeb81
<4>[   89.287330] RDX: 6e468801a1566130 RSI: 880103d73d98 RDI: 
880103d73d98
<4>[   89.287346] RBP: c912bdb8 R08: 88017ab35780 R09: 

<4>[   89.287361] R10: c912bd68 R11: abb18c3d R12: 
a01369e0
<4>[   89.287377] R13: 88017fd1b8f8 R14: 88017ab34ec0 R15: 
000a
<4>[   89.287393] FS:  () GS:88017fd0() 
knlGS:
<4>[   89.287411] CS:  0010 DS:  ES:  CR0: 80050033
<4>[   89.287424] CR2: 7ff0c0755018 CR3: 00016df9b000 CR4: 
003406e0
<4>[   89.287440] Call Trace:
<4>[   89.287511]  __i915_gem_free_object_rcu+0x20/0x40 [i915]
<4>[   89.287527]  rcu_process_callbacks+0x27a/0x730
<4>[   89.287544]  __do_softirq+0xc0/0x4ae
<4>[   89.287559]  ? smpboot_thread_fn+0x2d/0x280
<4>[   89.287571]  run_ksoftirqd+0x1f/0x70
<4>[   89.287582]  smpboot_thread_fn+0x18a/0x280
<4>[   89.287595]  kthread+0x114/0x150
<4>[   89.287605]  ? sort_range+0x30/0x30
<4>[   89.287615]  ? kthread_create_on_node+0x40/0x40
<4>[   89.287628]  ret_from_fork+0x27/0x40
<4>[   89.287641] Code: 0d 48 83 ea 01 4c 89 c1 48 83 fa ff 74 12 48 23 0c d7 
74 ed 48 c1 e2 06 48 0f bd c9 48 8d 04 0a 5d c3 90 90 90 90 90 55 48 89 e5 <48> 
8b 0a 48 89 0e 48 89 c8 f0 48 0f b1 3a 48 39 c1 75 ed 48 85
<1>[   89.287774] RIP: llist_add_batch+0x4/0x20 RSP: c912bdb8
<4>[   89.287826] ---[ end trace e775d15174d8ae02 ]---

(Lockless lists are only easy (and lockless) when using
llist_add/llist_del_all!)

Fixes: 87701b4b5593 ("drm/i915: Only free the oldest stale object before
a fresh allocation")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6a71805be389..889ae8810d5f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4636,11 +4636,17 @@ static void __i915_gem_free_work(struct work_struct 
*work)
 * unbound now.
 */
 
+   spin_lock(>mm.free_lock);
while ((freed = llist_del_all(>mm.free_list))) {
+   spin_unlock(>mm.free_lock);
+
__i915_gem_free_objects(i915, freed);
if (need_resched())
-   break;
+   return;
+
+   spin_lock(>mm.free_lock);
}
+   spin_unlock(>mm.free_lock);
 }
 
 static void __i915_gem_free_object_rcu(struct rcu_head *head)
-- 
2.15.0

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/2] lib/gt: Mark up engine classes

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/2] lib/gt: Mark up engine classes
URL   : https://patchwork.freedesktop.org/series/33239/
State : failure

== Summary ==

IGT patchset tested on top of latest successful build
c8d1ea24d3bfaf11b223bbe22407aeca196d0d89 tests/debugfs_test: Pretty print 
subdirectories

with latest DRM-Tip kernel build CI_DRM_3315
9cc9686b44e1 drm-tip: 2017y-11m-06d-10h-10m-17s UTC integration manifest

Testlist changes:
+igt@gem_ctx_isolation@blt-S3
+igt@gem_ctx_isolation@blt-S4
+igt@gem_ctx_isolation@blt-clean
+igt@gem_ctx_isolation@blt-dirty-create
+igt@gem_ctx_isolation@blt-dirty-switch
+igt@gem_ctx_isolation@blt-none
+igt@gem_ctx_isolation@blt-reset
+igt@gem_ctx_isolation@blt-unsafe
+igt@gem_ctx_isolation@bsd1-S3
+igt@gem_ctx_isolation@bsd1-S4
+igt@gem_ctx_isolation@bsd1-clean
+igt@gem_ctx_isolation@bsd1-dirty-create
+igt@gem_ctx_isolation@bsd1-dirty-switch
+igt@gem_ctx_isolation@bsd1-none
+igt@gem_ctx_isolation@bsd1-reset
+igt@gem_ctx_isolation@bsd1-unsafe
+igt@gem_ctx_isolation@bsd2-S3
+igt@gem_ctx_isolation@bsd2-S4
+igt@gem_ctx_isolation@bsd2-clean
+igt@gem_ctx_isolation@bsd2-dirty-create
+igt@gem_ctx_isolation@bsd2-dirty-switch
+igt@gem_ctx_isolation@bsd2-none
+igt@gem_ctx_isolation@bsd2-reset
+igt@gem_ctx_isolation@bsd2-unsafe
+igt@gem_ctx_isolation@bsd-S3
+igt@gem_ctx_isolation@bsd-S4
+igt@gem_ctx_isolation@bsd-clean
+igt@gem_ctx_isolation@bsd-dirty-create
+igt@gem_ctx_isolation@bsd-dirty-switch
+igt@gem_ctx_isolation@bsd-none
+igt@gem_ctx_isolation@bsd-reset
+igt@gem_ctx_isolation@bsd-unsafe
+igt@gem_ctx_isolation@default-S3
+igt@gem_ctx_isolation@default-S4
+igt@gem_ctx_isolation@default-clean
+igt@gem_ctx_isolation@default-dirty-create
+igt@gem_ctx_isolation@default-dirty-switch
+igt@gem_ctx_isolation@default-none
+igt@gem_ctx_isolation@default-reset
+igt@gem_ctx_isolation@default-unsafe
+igt@gem_ctx_isolation@render-S3
+igt@gem_ctx_isolation@render-S4
+igt@gem_ctx_isolation@render-clean
+igt@gem_ctx_isolation@render-dirty-create
+igt@gem_ctx_isolation@render-dirty-switch
+igt@gem_ctx_isolation@render-none
+igt@gem_ctx_isolation@render-reset
+igt@gem_ctx_isolation@render-unsafe
+igt@gem_ctx_isolation@vebox-S3
+igt@gem_ctx_isolation@vebox-S4
+igt@gem_ctx_isolation@vebox-clean
+igt@gem_ctx_isolation@vebox-dirty-create
+igt@gem_ctx_isolation@vebox-dirty-switch
+igt@gem_ctx_isolation@vebox-none
+igt@gem_ctx_isolation@vebox-reset
+igt@gem_ctx_isolation@vebox-unsafe

Test debugfs_test:
Subgroup read_all_entries:
pass   -> DMESG-WARN (fi-kbl-7567u)
Test gem_exec_reloc:
Subgroup basic-write-cpu:
pass   -> INCOMPLETE (fi-glk-dsi)

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:448s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:453s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:382s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:546s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:280s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:513s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:499s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:519s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:497s
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:559s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:599s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:431s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:263s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:583s
fi-glk-dsi   total:87   pass:67   dwarn:0   dfail:0   fail:0   skip:19 
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:441s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:431s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:432s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:501s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:469s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:577s
fi-kbl-7567u total:289  pass:268  dwarn:1   dfail:0   fail:0   skip:20  
time:483s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:586s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:578s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:458s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:600s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Object w/o backing stroage is banned by -ENXIO

[Joonas Lahtinen]

Hi Tina,

Please send this patch alone (or in the beginning of your series), so it can be 
merged already.

That'll save you the effort of carrying this patch.

Regards, Joonas

On Wed, 2017-11-01 at 17:22 +0800, Tina Zhang wrote:
> -ENXIO should be returned when operations are banned from changing
> backing storage of objects without backing storage.
> 
> v2:
> - update the patch description and subject to just mention objects w/o
>   backing storage, instead of "GEM proxy". (Joonas)
> 
> Signed-off-by: Tina Zhang 
> Reviewed-by: Chris Wilson 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 13bc18d..e85721c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1713,7 +1713,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
>*/
>   if (!obj->base.filp) {
>   i915_gem_object_put(obj);
> - return -EINVAL;
> + return -ENXIO;
>   }
>  
>   addr = vm_mmap(obj->base.filp, 0, args->size,
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for lib/gt: Mark up engine classes

[Patchwork]

== Series Details ==

Series: lib/gt: Mark up engine classes
URL   : https://patchwork.freedesktop.org/series/33235/
State : failure

== Summary ==

IGT patchset tested on top of latest successful build
c8d1ea24d3bfaf11b223bbe22407aeca196d0d89 tests/debugfs_test: Pretty print 
subdirectories

with latest DRM-Tip kernel build CI_DRM_3315
9cc9686b44e1 drm-tip: 2017y-11m-06d-10h-10m-17s UTC integration manifest

No testlist changes.

Test gem_ctx_basic:
pass   -> INCOMPLETE (fi-glk-dsi)

fi-bdw-5557u total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  
time:443s
fi-bdw-gvtdvmtotal:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:455s
fi-blb-e6850 total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  
time:384s
fi-bsw-n3050 total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  
time:546s
fi-bwr-2160  total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 
time:278s
fi-bxt-dsi   total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  
time:511s
fi-bxt-j4205 total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:503s
fi-byt-j1900 total:289  pass:253  dwarn:1   dfail:0   fail:0   skip:35  
time:511s
fi-byt-n2820 total:289  pass:249  dwarn:1   dfail:0   fail:0   skip:39  
time:499s
fi-cfl-s total:289  pass:254  dwarn:3   dfail:0   fail:0   skip:32  
time:553s
fi-cnl-y total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:599s
fi-elk-e7500 total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  
time:439s
fi-gdg-551   total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 
time:264s
fi-glk-1 total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  
time:596s
fi-glk-dsi   total:25   pass:15   dwarn:0   dfail:0   fail:0   skip:9  
fi-hsw-4770  total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:434s
fi-hsw-4770r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:433s
fi-ilk-650   total:289  pass:228  dwarn:0   dfail:0   fail:0   skip:61  
time:430s
fi-ivb-3520m total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:490s
fi-ivb-3770  total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  
time:470s
fi-kbl-7560u total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  
time:581s
fi-kbl-7567u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:478s
fi-kbl-r total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:596s
fi-pnv-d510  total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  
time:584s
fi-skl-6260u total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:465s
fi-skl-6600u total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  
time:596s
fi-skl-6700hqtotal:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  
time:652s
fi-skl-6700k total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  
time:523s
fi-skl-6770hqtotal:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  
time:501s
fi-skl-gvtdvmtotal:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  
time:474s
fi-snb-2520m total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  
time:568s
fi-snb-2600  total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  
time:421s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_476/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH igt v3 1/2] lib/gt: Mark up engine classes

[Chris Wilson]

We introduce the concept of classes that each engine may belong to.
There may be more than one engine available in each class, but each
engine only belongs to one class. Each class has a unique set of
capabilities and purpose (e.g. 3D rendering or video decode), but
different engines within each class may have different features (e.g.
only the first decoder instance may have the full set of fixed function
blocks, but most of the work can still be offload onto the other decoders
which shared the same ISA etc).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 lib/igt_gt.c | 16 
 lib/igt_gt.h |  7 +++
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/lib/igt_gt.c b/lib/igt_gt.c
index 89727d22..e8272d29 100644
--- a/lib/igt_gt.c
+++ b/lib/igt_gt.c
@@ -578,14 +578,14 @@ unsigned intel_detect_and_clear_missed_interrupts(int fd)
 }
 
 const struct intel_execution_engine intel_execution_engines[] = {
-   { "default", NULL, 0, 0 },
-   { "render", "rcs0", I915_EXEC_RENDER, 0 },
-   { "bsd", "vcs0", I915_EXEC_BSD, 0 },
-   { "bsd1", "vcs0", I915_EXEC_BSD, 1<<13 /*I915_EXEC_BSD_RING1*/ },
-   { "bsd2", "vcs1", I915_EXEC_BSD, 2<<13 /*I915_EXEC_BSD_RING2*/ },
-   { "blt", "bcs0", I915_EXEC_BLT, 0 },
-   { "vebox", "vecs0", I915_EXEC_VEBOX, 0 },
-   { NULL, 0, 0 }
+   { "default", NULL, 0, LOCAL_ENGINE_CLASS_OTHER, 0 },
+   { "render", "rcs0", I915_EXEC_RENDER, LOCAL_ENGINE_CLASS_RENDER, 0 },
+   { "bsd", "vcs0", I915_EXEC_BSD, LOCAL_ENGINE_CLASS_VIDEO, 0 },
+   { "bsd1", "vcs0", I915_EXEC_BSD, LOCAL_ENGINE_CLASS_VIDEO, 1<<13 
/*I915_EXEC_BSD_RING1*/ },
+   { "bsd2", "vcs1", I915_EXEC_BSD, LOCAL_ENGINE_CLASS_VIDEO, 2<<13 
/*I915_EXEC_BSD_RING2*/ },
+   { "blt", "bcs0", I915_EXEC_BLT, LOCAL_ENGINE_CLASS_COPY, 0 },
+   { "vebox", "vecs0", I915_EXEC_VEBOX, LOCAL_ENGINE_CLASS_VIDEO_ENHANCE, 
0 },
+   { NULL }
 };
 
 bool gem_can_store_dword(int fd, unsigned int engine)
diff --git a/lib/igt_gt.h b/lib/igt_gt.h
index 2579cbd3..264efce2 100644
--- a/lib/igt_gt.h
+++ b/lib/igt_gt.h
@@ -63,10 +63,17 @@ void igt_clflush_range(void *addr, int size);
 
 unsigned intel_detect_and_clear_missed_interrupts(int fd);
 
+#define LOCAL_ENGINE_CLASS_OTHER   0
+#define LOCAL_ENGINE_CLASS_RENDER  1
+#define LOCAL_ENGINE_CLASS_COPY2
+#define LOCAL_ENGINE_CLASS_VIDEO   3
+#define LOCAL_ENGINE_CLASS_VIDEO_ENHANCE   4
+
 extern const struct intel_execution_engine {
const char *name;
const char *full_name;
unsigned exec_id;
+   unsigned class_id;
unsigned flags;
 } intel_execution_engines[];
 
-- 
2.15.0

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

[Intel-gfx] [PATCH igt v3 2/2] igt/gem_ctx_isolation: Check isolation of registers between contexts

[Chris Wilson]

A new context assumes that all of its registers are in the default state
when it is created. What may happen is that a register written by one
context may leak into the second, causing mass confusion.

v2: extend back to Sandybridge, ignore non-priv registers that are not
context-saved (remind me what this test is all about!!!)
v3: Check context preserves registers across suspend/hibernate and
resets.

Signed-off-by: Chris Wilson 
---
 tests/Makefile.sources|   1 +
 tests/gem_ctx_isolation.c | 775 ++
 tests/gem_exec_fence.c|   2 +-
 3 files changed, 777 insertions(+), 1 deletion(-)
 create mode 100644 tests/gem_ctx_isolation.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 2313c12b..9a25a8b5 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -56,6 +56,7 @@ TESTS_progs = \
gem_ctx_basic \
gem_ctx_create \
gem_ctx_exec \
+   gem_ctx_isolation \
gem_ctx_param \
gem_ctx_switch \
gem_ctx_thrash \
diff --git a/tests/gem_ctx_isolation.c b/tests/gem_ctx_isolation.c
new file mode 100644
index ..a8269991
--- /dev/null
+++ b/tests/gem_ctx_isolation.c
@@ -0,0 +1,775 @@
+/*
+ * Copyright © 2017 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ */
+
+#include "igt.h"
+#include "igt_dummyload.h"
+
+#define MAX_REG 0x4
+#define NUM_REGS (MAX_REG / sizeof(uint32_t))
+
+#define PAGE_ALIGN(x) ALIGN(x, 4096)
+
+#define DIRTY1 0x1
+#define DIRTY2 0x2
+#define UNSAFE 0x4
+#define RESET 0x8
+
+enum {
+   RCS_MASK = 0x1,
+   BCS_MASK = 0x2,
+   VCS_MASK = 0x4,
+   VECS_MASK = 0x8,
+};
+
+#define ALL ~0u
+#define GEN_RANGE(x, y) ((ALL >> (32 - (y - x + 1))) << x)
+#define GEN6 (ALL << 6)
+#define GEN7 (ALL << 7)
+#define GEN8 (ALL << 8)
+#define GEN9 (ALL << 9)
+
+#define NOCTX 0
+
+#define LAST_KNOWN_GEN 10
+
+static const struct named_register {
+   const char *name;
+   unsigned int gen_mask;
+   unsigned int engine_mask;
+   uint32_t offset;
+   uint32_t count;
+} safe_registers[] = {
+   { "NOPID", NOCTX, RCS_MASK, 0x2094 },
+   { "MI_PREDICATE_RESULT_2", NOCTX, RCS_MASK, 0x23bc },
+   { "INSTPM", GEN8, RCS_MASK, 0x20c0 },
+   { "IA_VERTICES_COUNT", GEN6, RCS_MASK, 0x2310, 2 },
+   { "IA_PRIMITIVES_COUNT", GEN6, RCS_MASK, 0x2318, 2 },
+   { "VS_INVOCATION_COUNT", GEN6, RCS_MASK, 0x2320, 2 },
+   { "HS_INVOCATION_COUNT", GEN6, RCS_MASK, 0x2300, 2 },
+   { "DS_INVOCATION_COUNT", GEN6, RCS_MASK, 0x2308, 2 },
+   { "GS_INVOCATION_COUNT", GEN6, RCS_MASK, 0x2328, 2 },
+   { "GS_PRIMITIVES_COUNT", GEN6, RCS_MASK, 0x2330, 2 },
+   { "CL_INVOCATION_COUNT", GEN6, RCS_MASK, 0x2338, 2 },
+   { "CL_PRIMITIVES_COUNT", GEN6, RCS_MASK, 0x2340, 2 },
+   { "PS_INVOCATION_COUNT_0", GEN6, RCS_MASK, 0x22c8, 2 },
+   { "PS_DEPTH_COUNT_0", GEN6, RCS_MASK, 0x22d8, 2 },
+   { "GPUGPU_DISPATCHDIMX", GEN8, RCS_MASK, 0x2500 },
+   { "GPUGPU_DISPATCHDIMY", GEN8, RCS_MASK, 0x2504 },
+   { "GPUGPU_DISPATCHDIMZ", GEN8, RCS_MASK, 0x2508 },
+   { "MI_PREDICATE_SRC0", GEN8, RCS_MASK, 0x2400, 2 },
+   { "MI_PREDICATE_SRC1", GEN8, RCS_MASK, 0x2408, 2 },
+   { "MI_PREDICATE_DATA", GEN8, RCS_MASK, 0x2410, 2 },
+   { "MI_PRED_RESULT", GEN8, RCS_MASK, 0x2418 },
+   { "3DPRIM_END_OFFSET", GEN6, RCS_MASK, 0x2420 },
+   { "3DPRIM_START_VERTEX", GEN6, RCS_MASK, 0x2430 },
+   { "3DPRIM_VERTEX_COUNT", GEN6, RCS_MASK, 0x2434 },
+   { "3DPRIM_INSTANCE_COUNT", GEN6, RCS_MASK, 0x2438 },
+   { "3DPRIM_START_INSTANCE", GEN6, RCS_MASK, 0x243c },
+   { "3DPRIM_BASE_VERTEX", GEN6, RCS_MASK, 0x2440 },
+   { "GPGPU_THREADS_DISPATCHED", GEN8, RCS_MASK, 0x2290, 2 },
+   { "PS_INVOCATION_COUNT_1", GEN8, RCS_MASK, 0x22f0, 2 },
+   { "PS_DEPTH_COUNT_1", GEN8, RCS_MASK, 0x22f8, 2 

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Hide dangerous tests

[Joonas Lahtinen]

On Wed, 2017-10-25 at 16:32 +0100, Chris Wilson wrote:
> Some tests are designed to exercise the limits of the HW and may trigger
> unintended side-effects making the machine unusable. This should not be
> executed by default, but are still useful for early platform validation.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=103453
> Signed-off-by: Chris Wilson 
> Cc: Joonas Lahtinen 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Move hsw GT w/a to engine initialisation

[Chris Wilson]

Quoting Chris Wilson (2017-11-03 10:38:38)
> Quoting Ville Syrjälä (2017-11-03 10:25:17)
> > This problem doesn't seem like it should be specific to HSW. So I wonder
> > if we should start by just reverting that offending patch and move just
> > the watermark thing out to some earlier position in the sequence.
> 
> Whatever makes the simpler cc:stable patch. We have to overhaul these
> register initialisations, and I definitely pity the poor soul who has to
> navigate all the old bspecs to work out where each register needs to
> live.
> 
> Ville do you want to take a pass at splitting the wm from clock-gating?

I think the conclusion we take from the more generic patch to split vm
from clock-gating is that there are display w/a that we need to apply
very early during HW probing. So ultimately we do need to split display
and GT w/a. Should we just run with this patch to fixup the known
regression and hope there are no others before we complete the w/a
splitting?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] Patch tag ordering (Was: Re: [PATCH v5 2/5] drm/i915/guc : Removing i915_modparams.enable_guc_loading module)

[Joonas Lahtinen]

+ Jani (and Daniel as emeritus maintainer)

On Fri, 2017-11-03 at 10:08 -0700, Rodrigo Vivi wrote:
> On Fri, Nov 03, 2017 at 08:36:01AM +, Joonas Lahtinen wrote:
> > On Fri, 2017-11-03 at 00:03 +, Chris Wilson wrote:
> > > Quoting Rodrigo Vivi (2017-11-02 23:52:45)
> > > > On Wed, Oct 4, 2017 at 6:07 AM, Joonas Lahtinen
> > > >  wrote:
> > > > > On Tue, 2017-10-03 at 15:56 -0700, Sujaritha Sundaresan wrote:
> > > > > > We currently have two module parameters that control GuC: 
> > > > > > "enable_guc_loading" and "enable_guc_submission".
> > > > > > Whenever we need i915_modparams.enable_guc_submission=1, we also 
> > > > > > need enable_guc_loading=1.
> > > > > > We also need enable_guc_loading=1 when we want to verify the HuC,
> > > > > > which is every time we have a HuC (but all platforms with HuC have 
> > > > > > a GuC and viceversa).
> > > > > 
> > > > > Long lines in commit message, please give a look at:
> > > > > 
> > > > > https://www.kernel.org/doc/html/v4.13/process/submitting-patches.html
> > > > > 
> > > > > Section "14) The canonical patch format".
> > > > > 
> > > > > Then, about the patch. I think the commit message should be more clear
> > > > > about the fact that if we have HuC firmware to be loaded, we need to
> > > > > have GuC to actually load it. So if an user wants to avoid the GuC 
> > > > > from
> > > > > getting loaded, they must not have a HuC firmware to be loaded, in
> > > > > addition to not using GuC submission.
> > > > > 
> > > > > > 
> > > > > > v2: Clarifying the commit message (Anusha)
> > > > > > 
> > > > > > v3: Unify seq_puts messages, Re-factoring code as per review 
> > > > > > (Michal)
> > > > > > 
> > > > > > v4: Rebase
> > > > > > 
> > > > > > v5: Separating message unification into a separate patch
> > > > > > 
> > > > > > Cc: Michal Wajdeczko 
> > > > > > Cc: Anusha Srivatsa 
> > > > > > Cc: Oscar Mateo 
> > > > > > Cc: Sagar Arun Kamble 
> > > > > > Signed-off-by: Sujaritha Sundaresan 
> > > > > 
> > > > > Try to keep the tags in chronological order, so start with Suggested-
> > > > > by: (if any), Signed-off-by:, Cc: and so on.
> > > > 
> > > > Could we agree on have
> > > > Suggested-by:
> > > > Cc:
> > > > Signed-off-by:
> > > > as the initial chronological order and then follow the chronological
> > > 
> > > But CCs come after a s-o-b, because they are added after the commit. (I
> > > write some code, then think who might be interested; usually by looking
> > > at who previously worked on the same code). Then you also add new CCs
> > > later on based on review feedback; a comment on v1 gets a CC on v2.
> > > Bugzilla/reported-by/suggested-by are before since they presumably
> > > prompted the commit to be written in the first place (plus also they
> > > deserve extra credit for their effort in alerting us to the issue).
> > 
> > Yeah, this is my reasoning too.
> 
> So it seems the chronological order differs from case to case
> from person to person.
> When I write a patch most of the times I have people in mind
> that I will cc. Like when I'm writing an email.
> cc: people that touch this code from last time
> cc: people that can help on review
> cc: people that introduced this error
> cc: people that will be futurely impacted by this change

I don't follow this logic. Most of the Cc:s are chosen based on what
the code does, in get_maintainers.pl fashion. I think one is set to
implement a feature/bugfix, and it is not necessarily certain in the
beginning where the code will land, could be core kernel, DRM or i915
even. And Cc:s will vary accordingly depending on where the code
landed.

I can see an argument for some Cc:s before Signed-off-by:, but I never
claimed that wouldn't be the case. Just that chronological ordering
makes sense (will be easy to automate, too).

I would claim that all of the four points you listed, you'll be looking
at git blame based on what the code you wrote changed. And you don't
know the whole scope of code in advance except for really small fixes.
Where you wrote the code in your mind already. And it's really the IP
you're S-o-b:ing. But this gets pretty theoritical already.

> and then I sign-off on the end of the patch as I sign off in the
> end of a message.
> 
> > 
> > Also, when you add the machine assistance from Patchwork to
> > automatically spread tags from the cover letter (Acked-by, Reviewed-by
> > etc. and it's in the works, I understand). I don't quite see why we
> > would have only a portion of the tags in chronological order.
> > 
> > If I respin a patch, it might already have:
> > 
> > Bugzilla:
> > Suggested-by:
> > Signed-off-by:
> > Cc:
> > Cc:
> > Acked-by:
> > Reviewed-by:
> 
> I really would like to have something like:
> 
> Bugzilla:
> Suggested-by:
> Cc:
> Cc:
> Signed-off-by:
> Acked-by:
> Reviewed-by:
> 
> This seems to be 

[Intel-gfx] [PATCH igt] lib/gt: Mark up engine classes

[Chris Wilson]

We introduce the concept of classes that each engine may belong to.
There may be more than one engine available in each class, but each
engine only belongs to one class. Each class has a unique set of
capabilities and purpose (e.g. 3D rendering or video decode), but
different engines within each class may have different features (e.g.
only the first decoder instance may have the full set of fixed function
blocks, but most of the work can still be offload onto the other decoders
which shared the same ISA etc).

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 lib/igt_gt.c | 16 
 lib/igt_gt.h |  7 +++
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/lib/igt_gt.c b/lib/igt_gt.c
index 89727d22..e8272d29 100644
--- a/lib/igt_gt.c
+++ b/lib/igt_gt.c
@@ -578,14 +578,14 @@ unsigned intel_detect_and_clear_missed_interrupts(int fd)
 }
 
 const struct intel_execution_engine intel_execution_engines[] = {
-   { "default", NULL, 0, 0 },
-   { "render", "rcs0", I915_EXEC_RENDER, 0 },
-   { "bsd", "vcs0", I915_EXEC_BSD, 0 },
-   { "bsd1", "vcs0", I915_EXEC_BSD, 1<<13 /*I915_EXEC_BSD_RING1*/ },
-   { "bsd2", "vcs1", I915_EXEC_BSD, 2<<13 /*I915_EXEC_BSD_RING2*/ },
-   { "blt", "bcs0", I915_EXEC_BLT, 0 },
-   { "vebox", "vecs0", I915_EXEC_VEBOX, 0 },
-   { NULL, 0, 0 }
+   { "default", NULL, 0, LOCAL_ENGINE_CLASS_OTHER, 0 },
+   { "render", "rcs0", I915_EXEC_RENDER, LOCAL_ENGINE_CLASS_RENDER, 0 },
+   { "bsd", "vcs0", I915_EXEC_BSD, LOCAL_ENGINE_CLASS_VIDEO, 0 },
+   { "bsd1", "vcs0", I915_EXEC_BSD, LOCAL_ENGINE_CLASS_VIDEO, 1<<13 
/*I915_EXEC_BSD_RING1*/ },
+   { "bsd2", "vcs1", I915_EXEC_BSD, LOCAL_ENGINE_CLASS_VIDEO, 2<<13 
/*I915_EXEC_BSD_RING2*/ },
+   { "blt", "bcs0", I915_EXEC_BLT, LOCAL_ENGINE_CLASS_COPY, 0 },
+   { "vebox", "vecs0", I915_EXEC_VEBOX, LOCAL_ENGINE_CLASS_VIDEO_ENHANCE, 
0 },
+   { NULL }
 };
 
 bool gem_can_store_dword(int fd, unsigned int engine)
diff --git a/lib/igt_gt.h b/lib/igt_gt.h
index 2579cbd3..264efce2 100644
--- a/lib/igt_gt.h
+++ b/lib/igt_gt.h
@@ -63,10 +63,17 @@ void igt_clflush_range(void *addr, int size);
 
 unsigned intel_detect_and_clear_missed_interrupts(int fd);
 
+#define LOCAL_ENGINE_CLASS_OTHER   0
+#define LOCAL_ENGINE_CLASS_RENDER  1
+#define LOCAL_ENGINE_CLASS_COPY2
+#define LOCAL_ENGINE_CLASS_VIDEO   3
+#define LOCAL_ENGINE_CLASS_VIDEO_ENHANCE   4
+
 extern const struct intel_execution_engine {
const char *name;
const char *full_name;
unsigned exec_id;
+   unsigned class_id;
unsigned flags;
 } intel_execution_engines[];
 
-- 
2.15.0

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

Re: [Intel-gfx] [PATCH v5 5/7] drm/i915: Add "panel orientation" property to the panel connector

[Daniel Vetter]

On Sat, Nov 04, 2017 at 03:08:26PM +0100, Hans de Goede wrote:
> Ideally we could use the VBT for this, that would be simple, in
> intel_dsi_init() check dev_priv->vbt.dsi.config->rotation, set
> connector->display_info.panel_orientation accordingly and call
> drm_connector_init_panel_orientation_property(), done.
> 
> Unfortunately vbt.dsi.config->rotation is always 0 even on tablets
> with an upside down LCD and where the GOP is properly rotating the
> EFI fb in hardware.
> 
> So instead we end up reading the rotation from the primary plane.
> To read the info from the primary plane, we need to know which crtc
> the panel is hooked up to, so we do this the first time the panel
> encoder's get_config function get called, as by then the encoder
> crtc routing has been set up.
> 
> This commit only implements the panel orientation property for DSI
> panels on BYT / CHT / BXT hardware, as all known non normal oriented
> panels are only found on this hardware.
> 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -Read back the rotation applied by the GOP from the primary plane
>  instead of relying on dev_priv->vbt.dsi.config->rotation, because it
>  seems that the VBT rotation filed is always 0 even on devices where the
>  GOP does apply a rotation
> 
> Changes in v3:
> -Rewrite the code to read back the orientation from the primary
>  plane to contain all of this in intel_dsi.c instead of poking a bunch
>  of holes between all the different layers
> ---
>  drivers/gpu/drm/i915/intel_drv.h   |  1 +
>  drivers/gpu/drm/i915/intel_dsi.c   | 48 
> ++
>  drivers/gpu/drm/i915/intel_dsi.h   |  2 ++
>  drivers/gpu/drm/i915/intel_panel.c | 16 +
>  4 files changed, 67 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 47d022d48718..11efc6cb74c8 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1727,6 +1727,7 @@ void intel_panel_enable_backlight(const struct 
> intel_crtc_state *crtc_state,
> const struct drm_connector_state *conn_state);
>  void intel_panel_disable_backlight(const struct drm_connector_state 
> *old_conn_state);
>  void intel_panel_destroy_backlight(struct drm_connector *connector);
> +void intel_panel_set_orientation(struct intel_panel *panel, int orientation);
>  enum drm_connector_status intel_panel_detect(struct drm_i915_private 
> *dev_priv);
>  extern struct drm_display_mode *intel_find_panel_downclock(
>   struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index 83f15848098a..3e2f12db8d15 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -1084,13 +1084,16 @@ static void bxt_dsi_get_pipe_config(struct 
> intel_encoder *encoder,
>   struct drm_display_mode *adjusted_mode_sw;
>   struct intel_crtc *intel_crtc;
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
> + struct intel_panel *panel = _dsi->attached_connector->panel;
>   unsigned int lane_count = intel_dsi->lane_count;
>   unsigned int bpp, fmt;
> + int orientation;
>   enum port port;
>   u16 hactive, hfp, hsync, hbp, vfp, vsync, vbp;
>   u16 hfp_sw, hsync_sw, hbp_sw;
>   u16 crtc_htotal_sw, crtc_hsync_start_sw, crtc_hsync_end_sw,
>   crtc_hblank_start_sw, crtc_hblank_end_sw;
> + u32 val;
>  
>   /* FIXME: hw readout should not depend on SW state */
>   intel_crtc = to_intel_crtc(encoder->base.crtc);
> @@ -1234,6 +1237,49 @@ static void bxt_dsi_get_pipe_config(struct 
> intel_encoder *encoder,
>   if (adjusted_mode->crtc_hblank_end == crtc_hblank_end_sw)
>   adjusted_mode->crtc_hblank_end =
>   adjusted_mode_sw->crtc_hblank_end;
> +
> + if (!intel_dsi->got_panel_orientation) {
> + val = I915_READ(PLANE_CTL(intel_crtc->pipe, 0));
> + /* The rotation is used to correct for the panel orientation */
> + switch (val & PLANE_CTL_ROTATE_MASK) {
> + case PLANE_CTL_ROTATE_0:
> + orientation = DRM_MODE_PANEL_ORIENTATION_NORMAL;
> + break;
> + case PLANE_CTL_ROTATE_90:
> + orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP;
> + break;
> + case PLANE_CTL_ROTATE_180:
> + orientation = DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP;
> + break;
> + case PLANE_CTL_ROTATE_270:
> + orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP;
> + break;
> + }
> + intel_panel_set_orientation(panel, orientation);
> + intel_dsi->got_panel_orientation = true;
> + }
> +}
> +
> +static void 

Re: [Intel-gfx] [PATCH v5 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary plane

[Daniel Vetter]

On Sat, Nov 04, 2017 at 03:08:25PM +0100, Hans de Goede wrote:
> Apply the "panel orientation" drm connector prop to the primary plane so
> that fbcon and fbdev using userspace programs display the right way up.
> 
> Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=94894
> Signed-off-by: Hans de Goede 
> ---
> Changes in v2:
> -New patch in v2 of this patch-set
> 
> Changes in v3:
> -Use a rotation member in struct drm_fb_helper_crtc and set that from
>  drm_setup_crtcs instead of looping over all crtc's to find the right one
>  later
> -Since we now no longer look at rotation quirks directly in the fbcon
>  code, set fb_info.fbcon_rotate_hint when the panel is not mounted upright
>  and we cannot use hardware rotation
> 
> Changes in v4:
> -Make drm_fb_helper_init() init drm_fb_helper_crtc.rotation to
>  DRM_MODE_ROTATE_0 for all crtcs, so that we do not end up setting the
>  plane_state's rotation to an invalid value for disabled crtcs
>  (caught by Fi.CI)
> 
> Changes in v5:
> -Only use hardware (crtc primary plane) rotation for DRM_ROTATE_180,
>  90 / 270 degree rotation requires special handling which we lack atm
> -Add a TODO comment for 90 / 270 degree hardware rotation
> -Add some comments to better document the default case when mapping
>  sw_rotations to fbcon_rotate_hints

Yeah the above stuff really needs to be in the commit message. Or you need
to explain in prose, but just copying the changelog is easier.

People forgetting to update the patch justification is the no1 reason we
want to record the changelogs ...

Otherwise lgtm

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 90 
> -
>  include/drm/drm_fb_helper.h |  8 
>  2 files changed, 96 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 116d1f1337c7..5a557488bff4 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -41,6 +41,7 @@
>  #include 
>  #include 
>  
> +#include "drm_crtc_internal.h"
>  #include "drm_crtc_helper_internal.h"
>  
>  static bool drm_fbdev_emulation = true;
> @@ -350,6 +351,7 @@ EXPORT_SYMBOL(drm_fb_helper_debug_leave);
>  static int restore_fbdev_mode_atomic(struct drm_fb_helper *fb_helper, bool 
> active)
>  {
>   struct drm_device *dev = fb_helper->dev;
> + struct drm_plane_state *plane_state;
>   struct drm_plane *plane;
>   struct drm_atomic_state *state;
>   int i, ret;
> @@ -368,8 +370,6 @@ static int restore_fbdev_mode_atomic(struct drm_fb_helper 
> *fb_helper, bool activ
>  retry:
>   plane_mask = 0;
>   drm_for_each_plane(plane, dev) {
> - struct drm_plane_state *plane_state;
> -
>   plane_state = drm_atomic_get_plane_state(state, plane);
>   if (IS_ERR(plane_state)) {
>   ret = PTR_ERR(plane_state);
> @@ -392,6 +392,11 @@ static int restore_fbdev_mode_atomic(struct 
> drm_fb_helper *fb_helper, bool activ
>  
>   for (i = 0; i < fb_helper->crtc_count; i++) {
>   struct drm_mode_set *mode_set = 
> _helper->crtc_info[i].mode_set;
> + struct drm_plane *primary = mode_set->crtc->primary;
> +
> + /* Cannot fail as we've already gotten the plane state above */
> + plane_state = drm_atomic_get_new_plane_state(state, primary);
> + plane_state->rotation = fb_helper->crtc_info[i].rotation;
>  
>   ret = __drm_atomic_helper_set_config(mode_set, state);
>   if (ret != 0)
> @@ -821,6 +826,7 @@ int drm_fb_helper_init(struct drm_device *dev,
>   if (!fb_helper->crtc_info[i].mode_set.connectors)
>   goto out_free;
>   fb_helper->crtc_info[i].mode_set.num_connectors = 0;
> + fb_helper->crtc_info[i].rotation = DRM_MODE_ROTATE_0;
>   }
>  
>   i = 0;
> @@ -2334,6 +2340,62 @@ static int drm_pick_crtcs(struct drm_fb_helper 
> *fb_helper,
>   return best_score;
>  }
>  
> +/*
> + * This function checks if rotation is necessary because of panel orientation
> + * and if it is, if it is supported.
> + * If rotation is necessary and supported, its gets set in fb_crtc.rotation.
> + * If rotation is necessary but not supported, a DRM_MODE_ROTATE_* flag gets
> + * or-ed into fb_helper->sw_rotations. In drm_setup_crtcs_fb() we check if 
> only
> + * one bit is set and then we set fb_info.fbcon_rotate_hint to make fbcon do
> + * the unsupported rotation.
> + */
> +static void drm_setup_crtc_rotation(struct drm_fb_helper *fb_helper,
> + struct drm_fb_helper_crtc *fb_crtc,
> + struct drm_connector *connector)
> +{
> + struct drm_plane *plane = fb_crtc->mode_set.crtc->primary;
> + uint64_t valid_mask = 0;
> + int i, rotation;
> +
> + fb_crtc->rotation = DRM_MODE_ROTATE_0;
> +
> + switch 

Re: [Intel-gfx] [PATCH v5 3/7] drm: Add support for a panel-orientation connector property

[Daniel Vetter]

On Sat, Nov 04, 2017 at 03:08:24PM +0100, Hans de Goede wrote:
> On some devices the LCD panel is mounted in the casing in such a way that
> the up/top side of the panel does not match with the top side of the
> device (e.g. it is mounted upside-down).
> 
> This commit adds the necessary infra for lcd-panel drm_connector-s to
> have a "panel orientation" property to communicate how the panel is
> orientated vs the casing.
> 
> Userspace can use this property to check for non-normal orientation and
> then adjust the displayed image accordingly by rotating it to compensate.
> 
> Signed-off-by: Hans de Goede 
> ---

btw in drm we'd like to record the per-patch changelog, pls put them above
the ---. I know everyone's different, it's silly.

> Changes in v2:
> -Rebased on 4.14-rc1
> -Store panel_orientation in drm_display_info, so that drm_fb_helper.c can
>  access it easily
> -Have a single drm_connector_init_panel_orientation_property rather then
>  create and attach functions. The caller is expected to set
>  drm_display_info.panel_orientation before calling this, then this will
>  check for platform specific quirks overriding the panel_orientation and if
>  the panel_orientation is set after this then it will attach the property.
> ---
>  drivers/gpu/drm/Kconfig |  1 +
>  drivers/gpu/drm/drm_connector.c | 73 
> +
>  include/drm/drm_connector.h | 11 +++
>  include/drm/drm_mode_config.h   |  7 
>  include/uapi/drm/drm_mode.h |  7 
>  5 files changed, 99 insertions(+)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 9d005ac98c2b..0b166e626eb6 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -7,6 +7,7 @@
>  menuconfig DRM
>   tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI 
> support)"
>   depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && HAS_DMA
> + select DRM_PANEL_ORIENTATION_QUIRKS
>   select HDMI
>   select FB_CMDLINE
>   select I2C
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 704fc8934616..129c83a84320 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -24,6 +24,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "drm_crtc_internal.h"
>  #include "drm_internal.h"
> @@ -212,6 +213,8 @@ int drm_connector_init(struct drm_device *dev,
>   mutex_init(>mutex);
>   connector->edid_blob_ptr = NULL;
>   connector->status = connector_status_unknown;
> + connector->display_info.panel_orientation =
> + DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
>  
>   drm_connector_get_cmdline_mode(connector);
>  
> @@ -664,6 +667,13 @@ static const struct drm_prop_enum_list 
> drm_aspect_ratio_enum_list[] = {
>   { DRM_MODE_PICTURE_ASPECT_16_9, "16:9" },
>  };
>  
> +static const struct drm_prop_enum_list drm_panel_orientation_enum_list[] = {
> + { DRM_MODE_PANEL_ORIENTATION_NORMAL,"Normal"},
> + { DRM_MODE_PANEL_ORIENTATION_BOTTOM_UP, "Upside Down"   },
> + { DRM_MODE_PANEL_ORIENTATION_LEFT_UP,   "Left Side Up"  },
> + { DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,  "Right Side Up" },
> +};
> +
>  static const struct drm_prop_enum_list drm_dvi_i_select_enum_list[] = {
>   { DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
>   { DRM_MODE_SUBCONNECTOR_DVID,  "DVI-D" }, /* DVI-I  */
> @@ -768,6 +778,18 @@ DRM_ENUM_NAME_FN(drm_get_tv_subconnector_name,
>   *
>   * CRTC_ID:
>   *   Mode object ID of the _crtc this connector should be connected to.
> + *
> + * Connectors for LCD panels may also have one standardized property:
> + *
> + * panel orientation:
> + *   On some devices the LCD panel is mounted in the casing in such a way
> + *   that the up/top side of the panel does not match with the top side of
> + *   the device. Userspace can use this property to check for this.
> + *   Note that input coordinates from touchscreens (input devices with
> + *   INPUT_PROP_DIRECT) will still map 1:1 to the actual LCD panel
> + *   coordinates, so if userspace rotates the picture to adjust for
> + *   the orientation it must also apply the same transformation to the
> + *   touchscreen input coordinates.
>   */
>  
>  int drm_connector_create_standard_properties(struct drm_device *dev)
> @@ -1234,6 +1256,57 @@ void 
> drm_mode_connector_set_link_status_property(struct drm_connector *connector
>  }
>  EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
>  
> +/**
> + * drm_connector_init_panel_orientation_property -
> + *   initialize the connecters panel_orientation property
> + * @connector: connector for which to init the panel-orientation property.
> + * @width: width in pixels of the panel, used for panel quirk detection
> + * @height: height in pixels of the panel, used for panel quirk detection
> + *
> + * This function should only be called for built-in 

Re: [Intel-gfx] [PATCH v5 2/7] drm: Add panel orientation quirks

[Daniel Vetter]

On Sat, Nov 04, 2017 at 03:08:23PM +0100, Hans de Goede wrote:
> Some x86 clamshell design devices use portrait tablet screens and a display
> engine which cannot rotate in hardware, so the firmware just leaves things
> as is and we cannot figure out that the display is oriented non upright
> from the hardware.
> 
> So at least on x86, we need a quirk table for this. This commit adds a DMI
> based quirk table which is initially populated with 5 such devices: Asus
> T100HA, GPD Pocket, GPD win, I.T.Works TW891 and the VIOS LTH17.
> 
> This quirk table will be used by the drm code to let userspace know that
> the display is not mounted upright inside the devices case through a new
> panel orientation drm-connector property, as well as to tell fbcon to
> rotate the console so that it shows the right way up.
> 
> Signed-off-by: Hans de Goede 
> ---
> Changes in v5:
> -Add a kernel-doc comment documenting drm_get_panel_orientation_quirk()

The kerneldoc isn't much use without pulling it into the overall
structure. Documentation/gpu/drm-kms-helper.rst seems like a suitable
place. Pls also check it builds correctly and looks pretty using

$ make htmldocs

With that fixed:

Reviewed-by: Daniel Vetter 

> -Remove board_* matches from the dmi-matches for the VIOS LTH17 laptop,
>  keeping only the (identical) sys_vendor and product_name matches.
>  This is necessary because an older version of the bios has
>  board_vendor set to VOIS instead of VIOS
> ---
>  drivers/gpu/drm/Kconfig|   3 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/drm_panel_orientation_quirks.c | 174 
> +
>  include/drm/drm_utils.h|  18 +++
>  4 files changed, 196 insertions(+)
>  create mode 100644 drivers/gpu/drm/drm_panel_orientation_quirks.c
>  create mode 100644 include/drm/drm_utils.h
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 4d9f21831741..9d005ac98c2b 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -26,6 +26,9 @@ config DRM_MIPI_DSI
>   bool
>   depends on DRM
>  
> +config DRM_PANEL_ORIENTATION_QUIRKS
> + tristate
> +
>  config DRM_DP_AUX_CHARDEV
>   bool "DRM DP AUX Interface"
>   depends on DRM
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index a3fdc5a68dff..ffb621819bbf 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -46,6 +46,7 @@ obj-$(CONFIG_DRM_DEBUG_MM_SELFTEST) += selftests/
>  
>  obj-$(CONFIG_DRM)+= drm.o
>  obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
> +obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += drm_panel_orientation_quirks.o
>  obj-$(CONFIG_DRM_ARM)+= arm/
>  obj-$(CONFIG_DRM_TTM)+= ttm/
>  obj-$(CONFIG_DRM_TDFX)   += tdfx/
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c 
> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> new file mode 100644
> index ..b8765e2ed1d6
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_panel_orientation_quirks.c
> @@ -0,0 +1,174 @@
> +/*
> + *  drm_panel_orientation_quirks.c -- Quirks for non-normal panel orientation
> + *
> + *   Copyright (C) 2017 Hans de Goede 
> + *
> + *  This file is subject to the terms and conditions of the GNU General 
> Public
> + *  License.  See the file COPYING in the main directory of this archive for
> + *  more details.
> + */
> +
> +#include 
> +#include 
> +
> +#ifdef CONFIG_DMI
> +
> +/*
> + * Some x86 clamshell design devices use portrait tablet screens and a 
> display
> + * engine which cannot rotate in hardware, so we need to rotate the fbcon to
> + * compensate. Unfortunately these (cheap) devices also typically have quite
> + * generic DMI data, so we match on a combination of DMI data, screen 
> resolution
> + * and a list of known BIOS dates to avoid false positives.
> + */
> +
> +struct drm_dmi_panel_orientation_data {
> + int width;
> + int height;
> + const char * const *bios_dates;
> + int orientation;
> +};
> +
> +static const struct drm_dmi_panel_orientation_data asus_t100ha = {
> + .width = 800,
> + .height = 1280,
> + .orientation = DRM_MODE_PANEL_ORIENTATION_LEFT_UP,
> +};
> +
> +static const struct drm_dmi_panel_orientation_data gpd_pocket = {
> + .width = 1200,
> + .height = 1920,
> + .bios_dates = (const char * const []){ "05/26/2017", "06/28/2017",
> + "07/05/2017", "08/07/2017", NULL },
> + .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> +};
> +
> +static const struct drm_dmi_panel_orientation_data gpd_win = {
> + .width = 720,
> + .height = 1280,
> + .bios_dates = (const char * const []){
> + "10/25/2016", "11/18/2016", "12/23/2016", "12/26/2016",
> + "02/21/2017", "03/20/2017", "05/25/2017", NULL },
> + .orientation = DRM_MODE_PANEL_ORIENTATION_RIGHT_UP,
> +};
> +
> +static const struct 

Re: [Intel-gfx] [PATCH v16 1/6] drm/i915/gvt: Add framebuffer decoder support

[Zhang, Tina]

> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Gerd Hoffmann
> Sent: Monday, November 6, 2017 4:49 PM
> To: Zhang, Tina ; alex.william...@redhat.com;
> ch...@chris-wilson.co.uk; joonas.lahti...@linux.intel.com;
> zhen...@linux.intel.com; Lv, Zhiyuan ; Wang, Zhi A
> ; Tian, Kevin ; dan...@ffwll.ch;
> kwankh...@nvidia.com
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org; 
> linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v16 1/6] drm/i915/gvt: Add framebuffer decoder support
> 
>   Hi,
> 
> > +static struct pixel_format bdw_pixel_formats[] = {
> > +   {DRM_FORMAT_C8, 8, "8-bit Indexed"},
> 
> > +static struct pixel_format skl_pixel_formats[] = {
> > +   {DRM_FORMAT_YUYV, 16, "16-bit packed YUYV (8:8:8:8 MSB-
> > V:Y2:U:Y1)"},
> 
> Broadwell and Skylake.
> 
> What is the state for newer chipsets?
> 
> Is Kabylake supported by gvt meanwhile?  Does it need specific fb decoder
> support, or is it compatible with skylake?
Kabylake is supported by gvt. And the fb part should be compatible with 
skylake. But I haven't tested it yet.
Besides, the current version needs to add some platform checking logic to 
support Kabylake.
Thanks.

BR,
Tina
> 
> cheers,
>   Gerd
> 
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

[Gerd Hoffmann]

  Hi,

> > I thought we had agreed to make this behave similar to
> > VFIO_GROUP_GET_DEVICE_FD, the ioctl would take a __u32 dmabuf_id
> > and
> > return the file descriptor as the ioctl return value.  Thanks,
> 
> If we follow VFIO_GROUP_GET_DEVICE_FD, we would lose flags
> functionality.
> Zhi and Zhenyu, how do you think about it?

The ioctl is simple enough that not having flags should not be a
problem I think.

Also note that dmabuf_id is received using the PLANE_INFO ioctl, so
should the need arise to negotiate something in the future chances are
high that it can be done using the PLANE_INFO ioctl flags.

cheers,
  Gerd

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

Re: [Intel-gfx] [PATCH v16 5/6] vfio: ABI for mdev display dma-buf operation

[Gerd Hoffmann]

  Hi,

> +/**
> + * VFIO_DEVICE_QUERY_GFX_PLANE - _IOW(VFIO_TYPE, VFIO_BASE + 14,
> + *struct
> vfio_device_query_gfx_plane)
> + *
> + * Set the drm_plane_type and flags, then retrieve the gfx plane
> info.
> + *
> + * flags supported:
> + * - VFIO_GFX_PLANE_TYPE_PROBE and VFIO_GFX_PLANE_TYPE_DMABUF are
> set
> + *   to ask if the mdev supports dma-buf. 0 on support, -EINVAL on
> no
> + *   support for dma-buf.
> + * - VFIO_GFX_PLANE_TYPE_PROBE and VFIO_GFX_PLANE_TYPE_REGION are
> set
> + *   to ask if the mdev supports region. 0 on support, -EINVAL on no
> + *   support for region.
> + * - VFIO_GFX_PLANE_TYPE_DMABUF or VFIO_GFX_PLANE_TYPE_REGION is set
> + *   with each call to query the plane info.
> + * - Others are invalid and return -EINVAL.
> + *
> + * Return: 0 on success, -ENODEV with all out fields zero on mdev
> + * device initialization, -errno on other failure.

Should also not here that it is not an error if the guest has not
defined a plane yet.  The ioctl should return success in that case and
zero-initialize plane info (drm_format + size + width + height fields).

> + */
> +struct vfio_device_gfx_plane_info {
> + __u32 argsz;
> + __u32 flags;
> +#define VFIO_GFX_PLANE_TYPE_PROBE (1 << 0)
> +#define VFIO_GFX_PLANE_TYPE_DMABUF (1 << 1)
> +#define VFIO_GFX_PLANE_TYPE_REGION (1 << 2)
> + /* in */
> + __u32 drm_plane_type;   /* type of plane: 
> DRM_PLANE_TYPE_* */

Add a head field here?  People asked @ kvm forum about multihead
support.  Even if the initial driver version doesn't support it we
could add a field so it becomes easier to add it at some point in the
future.

Probing for available heads could be done with the PROBE flag, i.e.
flags = PROBE | DMABUF, plane_type = PRIMARY, head = 0, 1, ...

> + __u32 x_hot;/* horizontal position of cursor hotspot */
> + __u32 y_hot;/* vertical position of cursor hotspot */

Needs documentation how the driver signals "no hotspot information
available" (using 0x for example).

cheers,
  Gerd

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

Re: [Intel-gfx] [PATCH v16 1/6] drm/i915/gvt: Add framebuffer decoder support

[Gerd Hoffmann]

  Hi,

> +static struct pixel_format bdw_pixel_formats[] = {
> + {DRM_FORMAT_C8, 8, "8-bit Indexed"},

> +static struct pixel_format skl_pixel_formats[] = {
> + {DRM_FORMAT_YUYV, 16, "16-bit packed YUYV (8:8:8:8 MSB-
> V:Y2:U:Y1)"},

Broadwell and Skylake.

What is the state for newer chipsets?

Is Kabylake supported by gvt meanwhile?  Does it need specific fb
decoder support, or is it compatible with skylake?

cheers,
  Gerd

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: implemented dynamic WOPCM partition.

[Sagar Arun Kamble]

Please update the subject to "Implement dynamic WOPCM partitioning"
Also, commit description should be written in present tense form.

On 11/4/2017 5:48 AM, Jackie Li wrote:

Static WOPCM partitioning would lead to GuC loading failure
if the GuC/HuC firmware size exceeded current static 512KB
partition boundary.

This patch enabled the dynamical calculation of the WOPCM aperture
used by GuC/HuC firmware. GuC WOPCM offset was set to
HuC size + reserved WOPCM size. GuC WOPCM size was set to
total WOPCM size - GuC WOPCM offset - RC6CTX size.
Could you tell briefly here what is being done to wopcm offset and size 
in this patch.


Signed-off-by: Jackie Li 
Cc: Michal Wajdeczko 
Cc: Sagar Arun Kamble 
Cc: Sujaritha Sundaresan 
Cc: Daniele Ceraolo Spurio 
Cc: John Spotswood 
Cc: Oscar Mateo 
---
  drivers/gpu/drm/i915/i915_drv.c |  15 
  drivers/gpu/drm/i915/i915_drv.h |  13 
  drivers/gpu/drm/i915/i915_gem_context.c |   4 +-
  drivers/gpu/drm/i915/i915_guc_reg.h |  18 -
  drivers/gpu/drm/i915/intel_guc.c|  46 ++--
  drivers/gpu/drm/i915/intel_guc.h|  18 +
  drivers/gpu/drm/i915/intel_huc.c|   3 +-
  drivers/gpu/drm/i915/intel_uc.c | 128 +++-
  drivers/gpu/drm/i915/intel_uc_fw.c  |  12 ++-
  9 files changed, 223 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e7e9e06..19509fd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -623,6 +623,15 @@ static void i915_gem_fini(struct drm_i915_private 
*dev_priv)
WARN_ON(!list_empty(_priv->contexts.list));
  }
  
+static void i915_wopcm_init(struct drm_i915_private *dev_priv)

+{
+   struct intel_wopcm_info *wopcm = _priv->wopcm;
+
+   wopcm->size = WOPCM_DEFAULT_SIZE;
+
+   DRM_DEBUG_DRIVER("WOPCM size: %dKB\n", wopcm->size >> 10);
+}
+
  static int i915_load_modeset_init(struct drm_device *dev)
  {
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -670,6 +679,12 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_irq;
  
+	/*

+* Get the wopcm memory info.
+* NOTE: this need to be called before init FW.
+*/
+   i915_wopcm_init(dev_priv);
+
I think this call might be better if done from 
i915_driver_init_hw->i915_ggtt_probe_hw->*_gmch_probe after
gem_init_stolen as this is part of stolen memory. Might help performing 
any validation w.r.t stolen memory alloc.

intel_uc_init_fw(dev_priv);
  
  	ret = i915_gem_init(dev_priv);

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 72bb5b5..61cd290 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2235,6 +2235,16 @@ struct intel_cdclk_state {
u8 voltage_level;
  };
  
+struct intel_wopcm_info {

+   u32 size;
+};
+
+struct intel_wopcm_partition {
+   u32 guc_wopcm_offset;
+   u32 guc_wopcm_size;
+   u32 guc_wopcm_top;
+};
+
*_partition can become part of *_info. This can be named as 
intel_guc_wopcm_partition and drop "guc_" prefix from variable names.

  struct drm_i915_private {
struct drm_device drm;
  
@@ -2258,6 +2268,9 @@ struct drm_i915_private {

struct intel_huc huc;
struct intel_guc guc;
  
+	struct intel_wopcm_info wopcm;

+   struct intel_wopcm_partition wopcm_partition;
+
struct intel_csr csr;
  
  	struct intel_gmbus gmbus[GMBUS_NUM_PINS];

diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 10affb3..7347fd7 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -312,12 +312,12 @@ __create_hw_context(struct drm_i915_private *dev_priv,
ctx->desc_template =
default_desc_template(dev_priv, dev_priv->mm.aliasing_ppgtt);
  
-	/* GuC requires the ring to be placed above GUC_WOPCM_TOP. If GuC is not

+   /* GuC requires the ring to be placed above guc wopcm top. If GuC is not
 * present or not in use we still need a small bias as ring wraparound
 * at offset 0 sometimes hangs. No idea why.
 */
if (HAS_GUC(dev_priv) && i915_modparams.enable_guc_loading)
-   ctx->ggtt_offset_bias = GUC_WOPCM_TOP;
+   ctx->ggtt_offset_bias = intel_guc_wopcm_top(dev_priv);
else
ctx->ggtt_offset_bias = I915_GTT_PAGE_SIZE;
  
diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h b/drivers/gpu/drm/i915/i915_guc_reg.h

index 35cf991..d309884 100644
--- a/drivers/gpu/drm/i915/i915_guc_reg.h
+++ b/drivers/gpu/drm/i915/i915_guc_reg.h
@@ -67,17 +67,27 @@
  #define DMA_GUC_WOPCM_OFFSET