[Intel-gfx] [RFC PATCH] drm/vblanks: Deal with HW vblank counter resets.
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 = &dev->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, &t_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
-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
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(&dev_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
> -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
> -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
> -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
> -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.
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(&igt_formats, &num_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(&data->outputs[j])) { + mode = igt_output_get_mode(&data->outputs[j]); + if (mode->hdisplay != 0 && mode->vdisplay != 0) { + valid_output++; + if (valid_output == i) + return &data->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 = &d->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, &d->fb1); + igt_assert(d->fb_id1); + igt_plane_set_fb(plane, &d->fb1); + /* check upscaling */ + igt_fb_set_position(&d->fb1, plane, 0, 0); + igt_fb_set_size(&d->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, &d->fb1); + d->fb_id1 = 0; + } + } +} +void test_scaler_with_pixel_format(data_t *d) +{ + igt_display_t *display = &d->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 = igt_output_get_mode(output)
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+ (rev4)
== 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)
== 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
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 > b/drivers/gpu/drm/i915/intel_device_info.c > index db03d179fc85..9b71a9b6d80e
[Intel-gfx] [CI v3] drm/i915/glk: Refactor handling of PLANE_COLOR_CTL for GLK+
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: return PLANE_CTL_FORMAT_XRGB_2101010; case DRM_FORMAT_XBGR2101010: @@ -3466,6
[Intel-gfx] [RESEND PATCH v3 05/12] drm/i915: Use drm_fb_helper_output_poll_changed()
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(&ifbdev->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)
== 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 maili
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Deconstruct struct sgt_dma initialiser
== 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
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 + 1 file changed, 9 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/i915/
Re: [Intel-gfx] [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, 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.
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(&dev_priv->contexts.list)); } +static void i915_wopcm_init(struct drm_i915_private *dev_priv) +{ + struct intel_wopcm_info *wopcm = &dev_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 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->gg
Re: [Intel-gfx] [PATCH i-g-t v2 RESEND] tests/kms_fbcon_fbt: Report fbc_status on error
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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for tests/kms_plane_scaling: Fix off-by-one plane selection
== 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
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, mask) \ - WA_REG(addr, (mask), _MASKED_BIT_DISABLE(mask)) +#define SET_FIELD_MASKED(m, v) \
[Intel-gfx] ✓ Fi.CI.BAT: success for tests/kms_plane_scaling: Fix off-by-one plane selection
== 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
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, &d->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, &d->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
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, &d->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, &d->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.
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(&dev_priv->contexts.list)); } +static void i915_wopcm_init(struct drm_i915_private *dev_priv) +{ + struct intel_wopcm_info *wopcm = &dev_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
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
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, &clip, > > > - 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, &clip, > > > +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
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.
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.
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
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
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
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
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
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
== 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
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 = &dev_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 be programmed such than the PCBR range does not > -
Re: [Intel-gfx] [PATCH v6 1/3] drm/i915: Add Guc/HuC firmware details to error state
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(&error_uc->guc_fw, &p); > + intel_uc_fw_dump(&error_uc->huc_fw, &p); > +} > + > 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, &error->device_info); > err_print_params(m, &error->params); > + err_print_uc(m, &error->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 = &error->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) > +{ > + struct drm_i915_private *i915 = error->i915; > + struc
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Generalize transcoder looping (rev2)
== 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.
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.
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
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
== 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
== 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
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
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, &needs_clflush); + ret = i915_gem_obj_prepare_shmem_write(so->obj, &needs_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, &engine->i915->ggtt.base, NULL); - if (IS_ERR(so->vma)) { - ret = PTR_ERR(so->vma); + so.vma = i915_vma_instance(so.obj, &engine->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: - i915_gem_object_put(obj); -err_fre
[Intel-gfx] [PATCH v2] drm/i915: Generalize transcoder looping
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
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
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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 4/8] drm/i915: Move GT powersaving init to i915_gem_init()
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(&dev_priv->drm.struct_mutex); mutex_lock(&dev_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(&dev_priv->pcu_lock); - mutex_unlock(&dev_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 5/8] drm/i915: Inline intel_modeset_gem_init()
intel_modeset_gem_init() now only sets up the legacy overlay, so let's remove the function and call the setup directly during driver load. This should help us find a better point in the initialisation sequence for it later. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.c | 2 +- drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/intel_display.c | 7 --- 3 files changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index e7e9e061073b..1b440f2b90a5 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -676,7 +676,7 @@ static int i915_load_modeset_init(struct drm_device *dev) if (ret) goto cleanup_uc; - intel_modeset_gem_init(dev); + intel_setup_overlay(dev_priv); if (INTEL_INFO(dev_priv)->num_pipes == 0) return 0; diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 72bb5b51035a..593714fe5c5e 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -4118,7 +4118,6 @@ void intel_device_info_dump(struct drm_i915_private *dev_priv); /* modesetting */ extern void intel_modeset_init_hw(struct drm_device *dev); extern int intel_modeset_init(struct drm_device *dev); -extern void intel_modeset_gem_init(struct drm_device *dev); extern void intel_modeset_cleanup(struct drm_device *dev); extern int intel_connector_register(struct drm_connector *); extern void intel_connector_unregister(struct drm_connector *); diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index c3bf87c2036c..5debb79540a2 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -15170,13 +15170,6 @@ void intel_display_resume(struct drm_device *dev) drm_atomic_state_put(state); } -void intel_modeset_gem_init(struct drm_device *dev) -{ - struct drm_i915_private *dev_priv = to_i915(dev); - - intel_setup_overlay(dev_priv); -} - int intel_connector_register(struct drm_connector *connector) { struct intel_connector *intel_connector = to_intel_connector(connector); -- 2.15.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 6/8] drm/i915: Mark the context state as dirty/written
In the next few patches, we will want to both copy out of the context image and write a valid image into a new context. To be completely safe, we should then couple in our domain tracking to ensure that we don't have any issues with stale data remaining in unwanted cachelines. Historically, we omitted the .write=true from the call to set-gtt-domain in i915_switch_context() in order to avoid a stall between every request as we would want to wait for the previous context write from the gpu. Since then, we limit the set-gtt-domain to only occur when we first bind the vma, so once in use we will never stall, and we are sure to flush the context following a load from swap. Equally we never applied the lessons learnt from ringbuffer submission to execlists; so time to apply the flush of the lrc after load as well. Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Acked-by: Joonas Lahtinen Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_lrc.c| 32 drivers/gpu/drm/i915/intel_ringbuffer.c | 6 +++--- 2 files changed, 27 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 6840ec8db037..9b4e74151ace 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1060,12 +1060,34 @@ static void execlists_schedule(struct drm_i915_gem_request *request, int prio) spin_unlock_irq(&engine->timeline->lock); } +static int __context_pin(struct i915_gem_context *ctx, struct i915_vma *vma) +{ + unsigned int flags; + int err; + + /* +* Clear this page out of any CPU caches for coherent swap-in/out. +* We only want to do this on the first bind so that we do not stall +* on an active context (which by nature is already on the GPU). +*/ + if (!(vma->flags & I915_VMA_GLOBAL_BIND)) { + err = i915_gem_object_set_to_gtt_domain(vma->obj, true); + if (err) + return err; + } + + flags = PIN_GLOBAL | PIN_HIGH; + if (ctx->ggtt_offset_bias) + flags |= PIN_OFFSET_BIAS | ctx->ggtt_offset_bias; + + return i915_vma_pin(vma, 0, GEN8_LR_CONTEXT_ALIGN, flags); +} + static struct intel_ring * execlists_context_pin(struct intel_engine_cs *engine, struct i915_gem_context *ctx) { struct intel_context *ce = &ctx->engine[engine->id]; - unsigned int flags; void *vaddr; int ret; @@ -1082,11 +1104,7 @@ execlists_context_pin(struct intel_engine_cs *engine, } GEM_BUG_ON(!ce->state); - flags = PIN_GLOBAL | PIN_HIGH; - if (ctx->ggtt_offset_bias) - flags |= PIN_OFFSET_BIAS | ctx->ggtt_offset_bias; - - ret = i915_vma_pin(ce->state, 0, GEN8_LR_CONTEXT_ALIGN, flags); + ret = __context_pin(ctx, ce->state); if (ret) goto err; @@ -1106,9 +1124,7 @@ execlists_context_pin(struct intel_engine_cs *engine, ce->lrc_reg_state[CTX_RING_BUFFER_START+1] = i915_ggtt_offset(ce->ring->vma); - ce->state->obj->mm.dirty = true; ce->state->obj->pin_global++; - i915_gem_context_get(ctx); out: return ce->ring; diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index 47fadf8da84e..7e2a671882fb 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@ -1363,12 +1363,13 @@ static int context_pin(struct i915_gem_context *ctx) struct i915_vma *vma = ctx->engine[RCS].state; int ret; - /* Clear this page out of any CPU caches for coherent swap-in/out. + /* +* Clear this page out of any CPU caches for coherent swap-in/out. * We only want to do this on the first bind so that we do not stall * on an active context (which by nature is already on the GPU). */ if (!(vma->flags & I915_VMA_GLOBAL_BIND)) { - ret = i915_gem_object_set_to_gtt_domain(vma->obj, false); + ret = i915_gem_object_set_to_gtt_domain(vma->obj, true); if (ret) return ret; } @@ -1445,7 +1446,6 @@ intel_ring_context_pin(struct intel_engine_cs *engine, if (ret) goto err; - ce->state->obj->mm.dirty = true; ce->state->obj->pin_global++; } -- 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
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 = &ctx->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; + + err = i915_gem_wait_for_idle(i915, I915_WAIT_LOCKED); + if (err) + goto err_active; + +
[Intel-gfx] [CI 3/8] drm/i915: Force the switch to the i915->kernel_context
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(&engine->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(&engine->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(&engine->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.
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(&dev_priv->contexts.list)); > } > > +static void i915_wopcm_init(struct drm_i915_private *dev_priv) > +{ > + struct intel_wopcm_info *wopcm = &dev_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
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()
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)
== 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
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
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
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
== 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
== 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
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(&dev_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)
== 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
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
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()
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(&i915->mm.free_lock); > while ((freed = llist_del_all(&i915->mm.free_list))) { > + spin_unlock(&i915->mm.free_lock); > + > __i915_gem_free_objects(i915, freed); > if (need_resched()) > - break; > + return; > + > + spin_lock(&i915->mm.free_lock); > } > + spin_unlock(&i915->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)
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: >> > 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: >> R
Re: [Intel-gfx] [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. 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()
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(&i915->mm.free_lock); while ((freed = llist_del_all(&i915->mm.free_list))) { + spin_unlock(&i915->mm.free_lock); + __i915_gem_free_objects(i915, freed); if (need_resched()) - break; + return; + + spin_lock(&i915->mm.free_lock); } + spin_unlock(&i915->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()
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(&i915->mm.free_lock); while ((freed = llist_del_all(&i915->mm.free_list))) { + spin_unlock(&i915->mm.free_lock); + __i915_gem_free_objects(i915, freed); if (need_resched()) - break; + return; + + spin_lock(&i915->mm.free_lock); } + spin_unlock(&i915->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
== 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 skip:26
Re: [Intel-gfx] [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. 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
== 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
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
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 }, + { "BB_OFFSET", G
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Hide dangerous tests
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
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)
+ 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 the most used in kernel. > the most intuitive and the easier to read. > > The worst case this approach is creating is > > Signed-off: > Cc: > Cc: > Cc: > > really ugly o
[Intel-gfx] [PATCH igt] lib/gt: Mark up engine classes
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
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(&encoder->base); > + struct intel_panel *panel = &intel_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 vlv_dsi_get_pipe_config(stru
Re: [Intel-gfx] [PATCH v5 4/7] drm/fb-helper: Apply panel orientation connector prop to the primary plane
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 = > &fb_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 (connector->display_info.panel_orientation) { > +
Re: [Intel-gfx] [PATCH v5 3/7] drm: Add support for a panel-orientation connector property
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(&connector->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 &drm_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 panels, a
Re: [Intel-gfx] [PATCH v5 2/7] drm: Add panel orientation quirks
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 drm_dmi_panel_orientation_data itworks_tw891 = { > + .width = 800,
Re: [Intel-gfx] [PATCH v16 1/6] drm/i915/gvt: Add framebuffer decoder support
> -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
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
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
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.
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(&dev_priv->contexts.list)); } +static void i915_wopcm_init(struct drm_i915_private *dev_priv) +{ + struct intel_wopcm_info *wopcm = &dev_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 _MMIO(0xc340) #define HUC_LOADING_AGENT_VCR (0<<1) #define HUC_LOADING_AGENT_GUC (1<<1) -#define GUC_WOPCM_OFFSET_VALUE 0x8 /* 512KB */