Re: [Intel-gfx] [PATCH] drm/i915: Introduce bit definitions of CTXT_SR_CTRL register.
On Tue, Feb 10, 2015 at 05:11:36PM +0800, Zhi Wang wrote: > This patch introduces 2 bit definitions of context save/restore > control register. > > Thanks comments from David/Thomas/Daniel. Instead of Thanks just add the usual Suggested-by: lines. And please Cc: everyone from the previous discussion when you follow up with a patch. I've added that now. > > Signed-off-by: Zhi Wang Queued for -next, thanks for the patch. -Daniel > --- > drivers/gpu/drm/i915/intel_lrc.c | 3 ++- > drivers/gpu/drm/i915/intel_lrc.h | 2 ++ > 2 files changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > b/drivers/gpu/drm/i915/intel_lrc.c > index d05f3bc..2196e9c 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.c > +++ b/drivers/gpu/drm/i915/intel_lrc.c > @@ -1668,7 +1668,8 @@ populate_lr_context(struct intel_context *ctx, struct > drm_i915_gem_object *ctx_o > reg_state[CTX_LRI_HEADER_0] |= MI_LRI_FORCE_POSTED; > reg_state[CTX_CONTEXT_CONTROL] = RING_CONTEXT_CONTROL(ring); > reg_state[CTX_CONTEXT_CONTROL+1] = > - _MASKED_BIT_ENABLE((1<<3) | MI_RESTORE_INHIBIT); > + _MASKED_BIT_ENABLE(CTX_CTRL_INHIBIT_SYN_CTX_SWITCH | > + CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT); > reg_state[CTX_RING_HEAD] = RING_HEAD(ring->mmio_base); > reg_state[CTX_RING_HEAD+1] = 0; > reg_state[CTX_RING_TAIL] = RING_TAIL(ring->mmio_base); > diff --git a/drivers/gpu/drm/i915/intel_lrc.h > b/drivers/gpu/drm/i915/intel_lrc.h > index 6f2d7da..ced191f 100644 > --- a/drivers/gpu/drm/i915/intel_lrc.h > +++ b/drivers/gpu/drm/i915/intel_lrc.h > @@ -30,6 +30,8 @@ > #define RING_ELSP(ring) ((ring)->mmio_base+0x230) > #define RING_EXECLIST_STATUS(ring) ((ring)->mmio_base+0x234) > #define RING_CONTEXT_CONTROL(ring) ((ring)->mmio_base+0x244) > +#defineCTX_CTRL_INHIBIT_SYN_CTX_SWITCH (1 << 3) > +#defineCTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT (1 << 0) > #define RING_CONTEXT_STATUS_BUF(ring)((ring)->mmio_base+0x370) > #define RING_CONTEXT_STATUS_PTR(ring)((ring)->mmio_base+0x3a0) > > -- > 1.9.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Introduce bit definitions of CTXT_SR_CTRL register.
Thanks Daniel! :) 于 2015年02月11日 16:03, Daniel Vetter 写道: On Tue, Feb 10, 2015 at 05:11:36PM +0800, Zhi Wang wrote: This patch introduces 2 bit definitions of context save/restore control register. Thanks comments from David/Thomas/Daniel. Instead of Thanks just add the usual Suggested-by: lines. And please Cc: everyone from the previous discussion when you follow up with a patch. I've added that now. Signed-off-by: Zhi Wang Queued for -next, thanks for the patch. -Daniel --- drivers/gpu/drm/i915/intel_lrc.c | 3 ++- drivers/gpu/drm/i915/intel_lrc.h | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index d05f3bc..2196e9c 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -1668,7 +1668,8 @@ populate_lr_context(struct intel_context *ctx, struct drm_i915_gem_object *ctx_o reg_state[CTX_LRI_HEADER_0] |= MI_LRI_FORCE_POSTED; reg_state[CTX_CONTEXT_CONTROL] = RING_CONTEXT_CONTROL(ring); reg_state[CTX_CONTEXT_CONTROL+1] = - _MASKED_BIT_ENABLE((1<<3) | MI_RESTORE_INHIBIT); + _MASKED_BIT_ENABLE(CTX_CTRL_INHIBIT_SYN_CTX_SWITCH | + CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT); reg_state[CTX_RING_HEAD] = RING_HEAD(ring->mmio_base); reg_state[CTX_RING_HEAD+1] = 0; reg_state[CTX_RING_TAIL] = RING_TAIL(ring->mmio_base); diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h index 6f2d7da..ced191f 100644 --- a/drivers/gpu/drm/i915/intel_lrc.h +++ b/drivers/gpu/drm/i915/intel_lrc.h @@ -30,6 +30,8 @@ #define RING_ELSP(ring) ((ring)->mmio_base+0x230) #define RING_EXECLIST_STATUS(ring)((ring)->mmio_base+0x234) #define RING_CONTEXT_CONTROL(ring)((ring)->mmio_base+0x244) +#define CTX_CTRL_INHIBIT_SYN_CTX_SWITCH (1 << 3) +#define CTX_CTRL_ENGINE_CTX_RESTORE_INHIBIT (1 << 0) #define RING_CONTEXT_STATUS_BUF(ring) ((ring)->mmio_base+0x370) #define RING_CONTEXT_STATUS_PTR(ring) ((ring)->mmio_base+0x3a0) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 0/8] Add enlightenments for vGPU
On Tue, Feb 10, 2015 at 12:11:02PM +, Tvrtko Ursulin wrote: > On 02/10/2015 11:05 AM, Yu Zhang wrote: > >This patch set includes necessary code changes when i915 driver > >runs inside a VM. Though ideally we can run an unmodified i915 > >driver in VM, adding such enlightenments can greatly reduce the > >virtualization complexity in orders of magnitude. Code changes > >for the host side, which includes the actual Intel GVT-g > >implementation, will be sent out in other patches. > > > >The primary change introduced here is to implement so-called > >"address space ballooning" technique. XenGT partitions global > >graphics memory among multiple VMs, so each VM can directly > >access a portion of the memory without hypervisor's intervention, > >e.g. filling textures or queuing commands. However with the > >partitioning an unmodified i915 driver would assume a smaller > >graphics memory starting from address ZERO, so requires XenGT > >core module (vgt) to translate the graphics address between > >'guest view' and 'host view', for all registers and command > >opcodes which contain a graphics memory address. To reduce the > >complexity, XenGT introduces "address space ballooning", by > >telling the exact partitioning knowledge to each guest i915 > >driver, which then reserves and prevents non-allocated portions > >from allocation. Then vgt module only needs to scan and validate > >graphics addresses without complexity of translation. > > > >Note: The partitioning of global graphics memory may break some > >applications, with large objects in the aperture, because current > >userspace assumes half of the aperture usable. That would need > >separate fix either in user space (e.g. remove assumption in mesa) > >or in kernel (with some faulting mechanism). > > > >The partitioning knowledge is conveyed through a reserved MMIO > >range, called PVINFO, which will be architecturally reserved in > >future hardware generations. Another information carried through > >PVINFO is about the number of fence registers. As a global resource, > >XenGT also partitions them among VMs. > > > >Other changes are trivial as optimizations, to either reduce the > >trap overhead or disable power management features which don't > >make sense in a virtualized environment. > > > > > >Yu Zhang (8): > > drm/i915: Introduce a PV INFO page structure for Intel GVT-g. > > drm/i915: Adds graphic address space ballooning logic > > drm/i915: Partition the fence registers for vGPU in i915 driver > > drm/i915: Disable framebuffer compression for i915 driver in VM > > drm/i915: Add the display switch logic for vGPU in i915 driver > > drm/i915: Disable power management for i915 driver in VM > > drm/i915: Create vGPU specific MMIO operations to reduce traps > > drm/i915: Support alias ppgtt in VM if ppgtt is enabled > > All my comments have been addressed (and I especially like the ASCII diagram > of the memory space!) so you can put my r-b on all the patches from this > series: > > Reviewed-by: Tvrtko Ursulin All merged, thanks for patches&review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/10] Random cleanups
On Tue, Feb 10, 2015 at 07:32:15PM +, Damien Lespiau wrote: > Ran my cleanup script again and caught a few tiny oversights. Fixed three tiny spelling things and merged them all. Thanks, Daniel > > -- > Damien > > Damien Lespiau (10): > drm/i915: Garbage collect orphaned prototypes > drm/i915: Make intel_ring_setup_status_page() static > drm/i915: Remove intel_dsi_cmd.h > drm/i915: Make intel_lr_context_render_state_init() static > drm/i915: Make intel_logical_ring_begin() static > drm/i915: Make intel_logical_ring_advance_and_submit() static > drm/i915: Make intel_dp_check_link_status() static > drm/i915: Make intel_dp_unpack_aux() static > drm/i915: MAke intel_unpin_fb_obj() static > drm/i915: Remove the IS_SNB_G1 define > > drivers/gpu/drm/i915/i915_drv.h | 7 - > drivers/gpu/drm/i915/intel_display.c| 2 +- > drivers/gpu/drm/i915/intel_dp.c | 4 +- > drivers/gpu/drm/i915/intel_drv.h| 12 -- > drivers/gpu/drm/i915/intel_dsi_cmd.h| 39 - > drivers/gpu/drm/i915/intel_lrc.c| 293 > > drivers/gpu/drm/i915/intel_lrc.h| 9 - > drivers/gpu/drm/i915/intel_ringbuffer.c | 124 +++--- > drivers/gpu/drm/i915/intel_ringbuffer.h | 1 - > 9 files changed, 212 insertions(+), 279 deletions(-) > delete mode 100644 drivers/gpu/drm/i915/intel_dsi_cmd.h > > -- > 1.8.3.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/kms_addfb: Add support for fb modifiers
On Tue, Feb 10, 2015 at 05:17:34PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Just a few basic tests to make sure fb modifiers can be used and
> behave sanely when mixed with the old set_tiling API.
>
> v2:
>* Review feedback from Daniel Vetter:
> 1. Move cap detection into the subtest so skipping works.
> 2. Added some gtkdoc comments.
> 3. Two more test cases.
> 4. Removed unused parts for now.
>
> v3:
>* Removed two tests which do not make sense any more after the
> fb modifier rewrite.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> lib/ioctl_wrappers.c | 17 +
> lib/ioctl_wrappers.h | 37
> tests/kms_addfb.c| 68
>
> 3 files changed, 122 insertions(+)
>
> diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
> index 19a457a..0a7841a 100644
> --- a/lib/ioctl_wrappers.c
> +++ b/lib/ioctl_wrappers.c
> @@ -1091,3 +1091,20 @@ int gem_context_has_param(int fd, uint64_t param)
>
> return gem_context_get_param(fd, &p) == 0;
> }
> +
> +void igt_require_fb_modifiers(int fd)
gtkdoc is missing here.
-Daniel
> +{
> + static unsigned int has_modifiers, cap_modifiers_tested;
> +
> + if (!cap_modifiers_tested) {
> + uint64_t cap_modifiers;
> + int ret;
> +
> + ret = drmGetCap(fd, LOCAL_DRM_CAP_ADDFB2_MODIFIERS,
> &cap_modifiers);
> + igt_assert(ret == 0 || errno == EINVAL);
> + has_modifiers = ret == 0 && cap_modifiers == 1;
> + cap_modifiers_tested = 1;
> + }
> +
> + igt_require(has_modifiers);
> +}
> diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
> index 30ab836..9459130 100644
> --- a/lib/ioctl_wrappers.h
> +++ b/lib/ioctl_wrappers.h
> @@ -117,4 +117,41 @@ int gem_context_has_param(int fd, uint64_t param);
> int gem_context_get_param(int fd, struct local_i915_gem_context_param *p);
> int gem_context_set_param(int fd, struct local_i915_gem_context_param *p);
>
> +struct local_drm_mode_fb_cmd2 {
> + uint32_t fb_id;
> + uint32_t width, height;
> + uint32_t pixel_format;
> + uint32_t flags;
> + uint32_t handles[4];
> + uint32_t pitches[4];
> + uint32_t offsets[4];
> + uint64_t modifier[4];
> +};
> +
> +#define LOCAL_DRM_MODE_FB_MODIFIERS (1<<1)
> +
> +#define LOCAL_DRM_FORMAT_MOD_VENDOR_INTEL 0x01
> +
> +#define local_fourcc_mod_code(vendor, val) \
> + uint64_t)LOCAL_DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | \
> + (val & 0x00ffL))
> +
> +#define LOCAL_I915_FORMAT_MOD_NONE local_fourcc_mod_code(INTEL, \
> + 0x00L)
> +#define LOCAL_I915_FORMAT_MOD_X_TILEDlocal_fourcc_mod_code(INTEL, \
> + 0x01L)
> +
> +#define LOCAL_DRM_IOCTL_MODE_ADDFB2 DRM_IOWR(0xB8, \
> + struct local_drm_mode_fb_cmd2)
> +
> +#define LOCAL_DRM_CAP_ADDFB2_MODIFIERS 0x10
> +
> +/**
> + * igt_require_fb_modifiers:
> + * @fd: Open DRM file descriptor.
> + *
> + * Requires presence of DRM_CAP_ADDFB2_MODIFIERS.
> + */
> +void igt_require_fb_modifiers(int fd);
> +
> #endif /* IOCTL_WRAPPERS_H */
> diff --git a/tests/kms_addfb.c b/tests/kms_addfb.c
> index 756589e..625aa27 100644
> --- a/tests/kms_addfb.c
> +++ b/tests/kms_addfb.c
> @@ -213,6 +213,72 @@ static void size_tests(int fd)
> }
> }
>
> +static void addfb25_tests(int fd)
> +{
> + struct local_drm_mode_fb_cmd2 f = {};
> +
> +
> + memset(&f, 0, sizeof(f));
> +
> + f.width = 1024;
> + f.height = 1024;
> + f.pixel_format = DRM_FORMAT_XRGB;
> + f.pitches[0] = 1024*4;
> + f.modifier[0] = LOCAL_I915_FORMAT_MOD_NONE;
> +
> + igt_fixture {
> + gem_bo = gem_create(fd, 1024*1024*4);
> + igt_assert(gem_bo);
> + }
> +
> + f.handles[0] = gem_bo;
> +
> + igt_subtest("addfb25-modifier-no-flag") {
> + igt_require_fb_modifiers(fd);
> +
> + f.modifier[0] = LOCAL_I915_FORMAT_MOD_X_TILED;
> + igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f) < 0 &&
> errno == EINVAL);
> + f.fb_id = 0;
> + }
> +
> + f.flags = LOCAL_DRM_MODE_FB_MODIFIERS;
> +
> + igt_fixture
> + gem_set_tiling(fd, gem_bo, I915_TILING_X, 1024*4);
> + f.pitches[0] = 1024*4;
> +
> + igt_subtest("addfb25-X-tiled-mismatch") {
> + igt_require_fb_modifiers(fd);
> +
> + f.modifier[0] = LOCAL_I915_FORMAT_MOD_NONE;
> + igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f) < 0 &&
> errno == EINVAL);
> + f.fb_id = 0;
> + }
> +
> + igt_subtest("addfb25-X-tiled") {
> + igt_require_fb_modifiers(fd);
> +
> + f.modifier[0] = LOCAL_I915_FORMAT_MOD_X_TILED;
> + igt_assert(drmIoctl(fd, LOCAL_D
Re: [Intel-gfx] [PATCH v4 0/8] Add enlightenments for vGPU
On 2/11/2015 4:06 PM, Daniel Vetter wrote: On Tue, Feb 10, 2015 at 12:11:02PM +, Tvrtko Ursulin wrote: On 02/10/2015 11:05 AM, Yu Zhang wrote: This patch set includes necessary code changes when i915 driver runs inside a VM. Though ideally we can run an unmodified i915 driver in VM, adding such enlightenments can greatly reduce the virtualization complexity in orders of magnitude. Code changes for the host side, which includes the actual Intel GVT-g implementation, will be sent out in other patches. The primary change introduced here is to implement so-called "address space ballooning" technique. XenGT partitions global graphics memory among multiple VMs, so each VM can directly access a portion of the memory without hypervisor's intervention, e.g. filling textures or queuing commands. However with the partitioning an unmodified i915 driver would assume a smaller graphics memory starting from address ZERO, so requires XenGT core module (vgt) to translate the graphics address between 'guest view' and 'host view', for all registers and command opcodes which contain a graphics memory address. To reduce the complexity, XenGT introduces "address space ballooning", by telling the exact partitioning knowledge to each guest i915 driver, which then reserves and prevents non-allocated portions >from allocation. Then vgt module only needs to scan and validate graphics addresses without complexity of translation. Note: The partitioning of global graphics memory may break some applications, with large objects in the aperture, because current userspace assumes half of the aperture usable. That would need separate fix either in user space (e.g. remove assumption in mesa) or in kernel (with some faulting mechanism). The partitioning knowledge is conveyed through a reserved MMIO range, called PVINFO, which will be architecturally reserved in future hardware generations. Another information carried through PVINFO is about the number of fence registers. As a global resource, XenGT also partitions them among VMs. Other changes are trivial as optimizations, to either reduce the trap overhead or disable power management features which don't make sense in a virtualized environment. Yu Zhang (8): drm/i915: Introduce a PV INFO page structure for Intel GVT-g. drm/i915: Adds graphic address space ballooning logic drm/i915: Partition the fence registers for vGPU in i915 driver drm/i915: Disable framebuffer compression for i915 driver in VM drm/i915: Add the display switch logic for vGPU in i915 driver drm/i915: Disable power management for i915 driver in VM drm/i915: Create vGPU specific MMIO operations to reduce traps drm/i915: Support alias ppgtt in VM if ppgtt is enabled All my comments have been addressed (and I especially like the ASCII diagram of the memory space!) so you can put my r-b on all the patches from this series: Reviewed-by: Tvrtko Ursulin All merged, thanks for patches&review. -Daniel Got it. Thank you, Daniel! :) Yu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Reject garbage in unsed ctx create/destroy fields
Forgotten ever since, but luckily we're at least good at memset.
Testecase: igt/gem_ctx_create/invalid-pad
Testecase: igt/gem_ctx_bad_destroy/invalid-pad
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_context.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8603bf48d3ee..378011e4704d 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -748,6 +748,11 @@ int i915_gem_context_create_ioctl(struct drm_device *dev,
void *data,
struct intel_context *ctx;
int ret;
+ if (args->pad) {
+ DRM_DEBUG_DRIVER("garbage in pad 0x%08x\n", args->pad);
+ return -EINVAL;
+ }
+
if (!contexts_enabled(dev))
return -ENODEV;
@@ -774,6 +779,11 @@ int i915_gem_context_destroy_ioctl(struct drm_device *dev,
void *data,
struct intel_context *ctx;
int ret;
+ if (args->pad) {
+ DRM_DEBUG_DRIVER("garbage in pad 0x%08x\n", args->pad);
+ return -EINVAL;
+ }
+
if (args->ctx_id == DEFAULT_CONTEXT_HANDLE)
return -ENOENT;
--
1.9.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/9] drm/i915: add frontbuffer tracking to FBC
On Tue, Feb 10, 2015 at 10:19:10AM -0200, Paulo Zanoni wrote: > 2015-02-09 17:05 GMT-02:00 Daniel Vetter : > > Ok, here comes the gist of what needs to be changed. > > - You need to check the fbc-private copy of busy bits, otherwise the > > filtering for the GTT origin won't work. We want to keep fbc enabled (or > > renable) even when gtt is still invalidated somehow. > > - That means when you decide to reenable fbc (i.e. > > dev_priv->fbc.busy_frontbuffer_bits == 0) then it's guranteed that fbc > > is already disabled, and a plain intel_fbc_enable is good enough. > > - nuke in flush is not enough and too late - the frontbuffer rendering > > could have been going on for a while since you've seen the invalidate, > > the flush only happens when everything is quiet again. A nuke at the end > > is hence too late and not enough. > > > > This way you don't need the origin information in the flush helper. > > > > One bit I'm not yet sure off is where to put intel_fbc_update to > > reallocate buffers over pageflips. The complication since you've written > > these patches is the atomic flips, which can now asynchronously update the > > primary plane (and change the pixel format), but different from the > > pageflip code the atomic paths don't disable/enable fbc over a flip. > > > > Which means that doing the intel_fbc_update just somewhere in between the > > disable and enable won't be enough to keep everything in sync. > > > > I think what we ultimately need is a bit of logic in the atomic_check part > > which decides whether fbc must be disabled/enabled (e.g. when we need to > > realloc the cfb) around the update. And then we'll place explicit > > intel_fbc_disable/enable calls in the atomic_begin/flush callbacks. > > > > The other case is just updating the gtt fence data. At least on g4x+ we > > should try not to disable fbc but keep it going over pageflips. Which > > means there could be interesting races between the flip and gtt writes > > right afterwards (which aren't synchronized in any way). > > > > I see two options: > > - We update the fence register whenever we want, but while a pageflip is > > pending we don't filter out gtt invalidates (since we kinda don't know > > whether the hw invalidate will hit before/after the flip happens). This > > one is a bit tricky, we'd need to add fbc callbacks to > > intel_frontbuffer_flip_prepare/complete. > > - We do a manual nuke after each flip by adding calls to intel_fbc_flip to > > intel_frontbuffer_flip and flip_complete. This one has the downside that > > proper userspace which doesn't do gtt writes will get hurt by nuking the > > fbc twice: Once for the flip and once right afterwards. > > Thanks for the review! > > If you can think of any way to write a test case to reproduce the > problems you pointed above, please give me ideas! I'll try to do this > while rewriting the patches, but maybe you already have something in > your mind? I guess we need to try to find a way to get an invalidate > but only get the corresponding flush a long time (> 1 frame) after > that? Maybe keep the frame busy with tons of operations that don't > change the CRC? Well that's going to be fairly hard since you need to race pageflips with gtt writes and then try to sneak in gtt writes for the new buffer in before the fence and everything is set up correctly. The time between invalidate and flush isn't a problem since for GTT mmaps it's forever by default. So as long as you don't do any set_domain/execbuf or anything else GTT mmaps will stay invalidated. But since we want to filter out GTT invalidates (the hw actually works for that case!) the problem creeps in when we update the gtt fbc fence in a racy way. The frontbuffer tracking stuff is race-free (avoiding that race is why there's the flip_prepare/complete split) itself. If you want to try the following might work to reproduce this case: Prerequisites: We don't disable fbc any more over pageflips, which we can do on g4x as long as the pixel format stays the same. 1. Take reference crc for black, pain test buffer white. 2. Pageflip to that white buffer. 3. Immediately afterwards (i.e. before the pageflip completed) draw the buffer black through gtt mmaps with all the set_domain stuff that's required. 4. Wait a few frames, grab crc. And now that I've describe in detail there's actually no race here as long as we update the fbc fence _before_ we do the pageflip. Some invalidates will hit the old buffer still, but the pageflip will invalidate everything anyway. And any gtt writes after the flip will do line invalidation correctly. So I don't think we'll have a problem, and I also don't think we need another testcase really. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Clamp efficient frequency to valid range
On Wed, 11 Feb 2015, Tom.O'rou...@intel.com wrote: > From: Tom O'Rourke > > The efficient frequency (RPe) should stay in the range > RPn <= RPe <= RP0. The pcode clamps the returned value > internally on Broadwell but not on Haswell. > > Fix for missing range check in > commit 93ee29203f506582cca2bcec5f05041526d9ab0a > Author: Tom O'Rourke > Date: Wed Nov 19 14:21:52 2014 -0800 > > drm/i915: Use efficient frequency for HSW/BDW > > Reference: > http://lists.freedesktop.org/archives/intel-gfx/2015-February/059802.html > Reported-by: Michael Auchter > Suggested-by: Chris Wilson > Signed-off-by: Tom O'Rourke Pushed to drm-intel-next-fixes with cc: stable for v3.19. Thanks for the patch. BR, Jani. > --- > drivers/gpu/drm/i915/intel_pm.c |5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index a3b979d..602c443 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -3998,7 +3998,10 @@ static void gen6_init_rps_frequencies(struct > drm_device *dev) > &ddcc_status); > if (0 == ret) > dev_priv->rps.efficient_freq = > - (ddcc_status >> 8) & 0xff; > + clamp_t(u8, > + ((ddcc_status >> 8) & 0xff), > + dev_priv->rps.min_freq, > + dev_priv->rps.max_freq); > } > > /* Preserve min/max settings in case of re-init */ > -- > 1.7.9.5 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Really ignore long HPD pulses on eDP
On Tue, 10 Feb 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Return IRQ_HANDLED from intel_dp_hpd_pulse() to properly
> ignore the long HPD pulse on eDP to avoid the never ending
> VDD off->HPD->VDD on->VDD off->HPD... cycle.
>
> This fixes a regression intoduced by
> commit b2c5c181ed18490648a02f8c7d562a3b9e8b96de
> Author: Daniel Vetter
> Date: Fri Jan 23 06:00:31 2015 +0100
>
> drm/i915: Use symbolic irqreturn for ->hpd_pulse
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Reviewed-by: Daniel Vetter
> Signed-off-by: Ville Syrjälä
Pushed to drm-intel-next-fixes, thanks for the patch and review.
BR,
Jani.
> ---
> Jani, I decided against the goto out solution because it would have looked
> like
> ret = IRQ_HANDLED;
> goto out;
> which seemed a bit silly.
>
> drivers/gpu/drm/i915/intel_dp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 33b1b82..cc711ac 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4499,7 +4499,7 @@ intel_dp_hpd_pulse(struct intel_digital_port
> *intel_dig_port, bool long_hpd)
>*/
> DRM_DEBUG_KMS("ignoring long hpd on eDP port %c\n",
> port_name(intel_dig_port->port));
> - return false;
> + return IRQ_HANDLED;
> }
>
> DRM_DEBUG_KMS("got hpd irq on port %c - %s\n",
> --
> 2.0.5
>
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/9] drm/i915: also do frontbuffer tracking on pwrites
On Mon, Feb 09, 2015 at 07:41:17PM +0100, Daniel Vetter wrote:
> On Mon, Feb 09, 2015 at 02:46:31PM -0200, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > We need this for FBC, and possibly for PSR too.
> >
> > Reviewed-by: Rodrigo Vivi
> > Signed-off-by: Paulo Zanoni
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 3d198f8..15910fa 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -,6 +,10 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void
> > *data,
> > ret = i915_gem_phys_pwrite(obj, args, file);
> > else
> > ret = i915_gem_shmem_pwrite(dev, obj, args, file);
> > +
> > + intel_fb_obj_flush(obj, false, ORIGIN_CPU);
> > + } else {
> > + intel_fb_obj_flush(obj, false, ORIGIN_GTT);
>
> A flush alone does nothing. Well should, but you're kinda not quite using
> it correctly in the next patch to convert fbc over to frontbuffer
> tracking.
>
> I guess the docs aren't perfect, so let me try again. There are two kinds
> of events the frontbuffer tracking code supplies to tell its consumers
> that screen changes are happening:
> - invalidate/flush: Invalidate denotes the start of the frontbuffer
> rendering, from that point on psr/fbc/drrs must update the screen with
> the usual refresh rate and not cache anything anywhere. When the flush
> happens (which could easily be after a _very_ long time, e.g. fbcon)
> then only can caching recomence. Caching = enable fbc, allow psr or
> reduce refresh rate.
> - flip events: That's an instantenous event (well at least for consumer,
> internally we need to track it as prepare/complete for async flips), and
> mostly just interesting when the hw doesn't notice flips (some psr modes
> and drrs).
>
> So if you want to add frontbuffer tracking to pwrite then we need both an
> invalidate (before the actual pwrite) and a flush (after the pwrite, like
> you've added here).
>
> The other issue is that there's a bug with the origin assignemnt:
> phys_pwrite also goes through the gtt. I think it would be best if we push
> the fb_obj_invalidate/flush into the relevant pwrite functions. That
> should make it easier to review, since the invalidate/flush will be next
> to the write op.
btw what's the use-case here? We don't upload stuff to X-tiled buffers
with pwrite, so this isn't really relevant for fbc I think.
It is a real gap for psr though, since cursor updates are done with
pwrite. But that probably gets papered over by X also updating the
position when the image changes, which means we'll get another (hw)
flip combo. But that's just X, and we indeed don't have a pwrite cursor
case yet in the psr testcase.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] proposal for DVFS (Dynamic Voltage Frequency Scaling)
Hi All, I went through Ville's changes and it seems to be lacking support for our one main user experience requirement in Android. Which is as follows "Ux Restrictions: Flash/flicker should be avoided as much as possible( i.e during unplug of HDMI avoid immediately lowering the CD clock after hotunplug since it will result in flicker on LFP )." The display will be turned off eventually (especially considering Android) and would be good to change the CD clock at this point in time rather than immediately on hot unplug. So we have to add to current implementation to modify the behavior or go with the HWC+driver logic described below. regards, Sivakumar -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Thulasimani, Sivakumar Sent: Friday, January 16, 2015 9:56 AM To: Daniel Vetter Cc: intel-gfx@lists.freedesktop.org; Purushothaman, Vijay A Subject: Re: [Intel-gfx] proposal for DVFS (Dynamic Voltage Frequency Scaling) Thanks for the pointer, let me sync with Ville and get back. regards, Sivakumar -Original Message- From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Friday, January 16, 2015 1:08 AM To: Thulasimani, Sivakumar Cc: intel-gfx@lists.freedesktop.org; Purushothaman, Vijay A; Syrjala, Ville Subject: Re: [Intel-gfx] proposal for DVFS (Dynamic Voltage Frequency Scaling) You realize that Ville has implemented all this already and his patches are only waiting for review? -Daniel On Thu, Jan 15, 2015 at 2:50 PM, Thulasimani, Sivakumar wrote: > Hi, > > I’ll be working on implementing Dynamic Voltage > Frequency Scaling in i915, whose rough proposal is provided below. > Please go through the options and provide your feedback. > > > > What is DVFS ? > > Any SKU is capable of running at more than one display > CD clock value but is configured to a default value during boot and is > left untouched afterwards. Lowering this Display CD clock will result > in better power savings while raising this will result in capability > to support larger resolution displays. So the best scenario is to > always detect the attached displays and adjust the CD Clock to the minimum > required by the displays. > DVFS is the process of dynamically changing the display CD clock based > on attached displays. > > > > Usecases: ( considers low resolution LFP is used with 4K HDMI panel) > > Ø EDP (19x10) LFP panel alone is present at boot and can be driven > with lower CD clock, thus saving power. > > Ø EDP (19x10) LFP panel was present at boot and 4K HDMI display is > hot plugged in to the system. CD clock can be increased to the > required value and then we can drive 4K panel. Thus save power while > only LFP is in use but also provide the ability to support 4K displays. > > Ø 4K HDMI display is unplugged from the system, CD clock can now be > lowered to the value required to drive LFP alone to save power. > > Ø Boot with LFP and 4K HDMI connected, the CD clock will be > programmed to the value required to drive 4K HDMI. > > > > Technical Restrictions: > > Ø DVFS can be performed only when all displays are turned off > (pipe/port/plane,etc) > > > > Ux Restrictions: > > Ø Flash/flicker should be avoided as much as possible( i.e during > unplug of HDMI avoid immediately lowering the CD clock after hotunplug > since it will result in flicker on LFP ) > > > > Possible Solutions : > > Ø Policy + implementation in driver > > o Driver will set the cd clock during boot based on attached panels > > o Post boot driver has to track each modeset for CD clock and resolution > support. > > o If any change in CD clock is needed, driver has to disable all displays > , change the cd clock and enable back all displays > > o Pros: > > · Changes are contained within driver > > o Cons: > > · Complexity increases within driver > > · User land/ HWC will be blind to internal operations > > Ø Policy in HWC and implementation in driver > > o Driver will set the cd clock during boot based on attached panels > > o Post boot, driver will fail any modeset that cannot be supported > > o HWC will be responsible for disabling all displays, issuing IOCTL to > change CD clock and enabling required displays > > o Pros: > > · Driver implementation will be simple and clean > > · User land/HWC will be aware of operations and handle any special > cases such as video playback > > o Cons: > > · Solution requires HWC & Driver changes. > > > > Our recommendation is for HWC + Driver changes considering our primary > target of Android and the pros/cons mentioned there. > > > > Sorry for the long mail J, Please provide your feedback or questions > on this. > > > > regards, > > Sivakumar > > > > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freede
Re: [Intel-gfx] [PATCH i-g-t 03/17] lib/ioctl: gem_ prefix for igt_require_mmap_wc
On Tue, Feb 10, 2015 at 09:58:37PM +, Chris Wilson wrote: > On Tue, Feb 10, 2015 at 07:05:46PM +0100, Daniel Vetter wrote: > > We stick to the overall prefix even for magic require functions. > > That seems a bit perverse. Move the #define to a new header perhaps, but > the require is a function of igt, not part of the kernel GEM interface. We have lots of these in the ioctl wrapper library already. Imo no need to put them into a separate library since often they share some static function with the real ioctl wrapper. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 05/17] lib/ioctls: make gem_context_set/get_param infallible
On Tue, Feb 10, 2015 at 09:54:46PM +, Chris Wilson wrote: > On Tue, Feb 10, 2015 at 07:05:48PM +0100, Daniel Vetter wrote: > > We have separate require checks already, so these failing is a bug in > > the test logic. > > That makes it impossible to use the wrappers to test the ioctl though. Yes. Ime for ioctl testing you want to open-code it anyway so that all the nasty "put garbage into reserved stuff and padding" tests are possible. And for those cases where we want to share a bit of code we just add an __ variant which does the usual -errno integer return value. Then the infallible ones just wrap that in igt_assert/skip. So just aligning with the usual style. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 13/17] tests: Align subtest with naming convention
On Tue, Feb 10, 2015 at 09:53:32PM +, Chris Wilson wrote: > On Tue, Feb 10, 2015 at 07:05:56PM +0100, Daniel Vetter wrote: > > Yeah, historically grown but we should try to be somewhat consistent. > > It helps with filtering testcases. > > I think you are going the wrong way, since the current consensus prefers > XCS naming. Well we can switch it over, but it should be somewhat consistent. And the glossary for common subtest names should be updated in the docs, too. At least for me these subtest patterns are fairly useful to get at a reasonable testcase selection for development. Might be that everyone else just laughs at prts, dunno. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] lib/chipset: Cache devid
On Tue, Feb 10, 2015 at 10:50:33PM +, Chris Wilson wrote:
> On Tue, Feb 10, 2015 at 11:45:12PM +0100, Daniel Vetter wrote:
> > On Tue, Feb 10, 2015 at 11:39:45PM +0100, Daniel Vetter wrote:
> > > On Tue, Feb 10, 2015 at 11:37:42PM +0100, Daniel Vetter wrote:
> > > > On Tue, Feb 10, 2015 at 10:28:22PM +, Chris Wilson wrote:
> > > > > On Tue, Feb 10, 2015 at 10:59:16PM +0100, Daniel Vetter wrote:
> > > > > > Chris Wilson complained that this adds a lot of noise to the test
> > > > > > startup when full debugging is enabled, so let's cache it. We can do
> > > > > > that since there's only ever one intel gpu in a given system.
> > > > > >
> > > > > > Cc: Chris Wilson
> > > > > > Signed-off-by: Daniel Vetter
> > > > >
> > > > > Couldn't we move the devid cache to lib/drmtest.c::is_intel() ?
> > > >
> > > > Sounds like just another place where we should use the helper from
> > > > intel_chipset.c. Next patch in-flight ...
> > >
> > > Ok I'm blind, is_intel can fail. So I guess I should extract a new
> > > __get_drm_devid which can fail, put the caching in there (plus override)
> > > and use that in in intel_chipset.c ...
> >
> > Doesn't really work since doing the ioctl is part of the dance we do to
> > figure out whether the fd is really an intel or not :(
>
> Something like:
Yeah, lgtm.
-Daniel
> diff --git a/lib/drmtest.c b/lib/drmtest.c
> index 7cdef36..4090a4a 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -72,6 +72,8 @@
> * and [batchbuffer](intel-gpu-tools-intel-batchbuffer.html) libraries as
> dependencies.
> */
>
> +uint16_t __drm_device_id;
> +
> static int is_i915_device(int fd)
> {
> drm_version_t version;
> @@ -100,7 +102,11 @@ is_intel(int fd)
> if (ioctl(fd, DRM_IOCTL_I915_GETPARAM, &gp, sizeof(gp)))
> return 0;
>
> - return IS_INTEL(devid);
> + if (!IS_INTEL(devid))
> + return 0;
> +
> + __drm_device_id = devid;
> + return 1;
> }
>
> static void check_stop_rings(void)
> diff --git a/lib/drmtest.h b/lib/drmtest.h
> index 508cc83..fabf43e 100644
> --- a/lib/drmtest.h
> +++ b/lib/drmtest.h
> @@ -70,6 +70,8 @@ static inline void *igt_mmap64(void *addr, size_t length,
> int prot, int flags,
> */
> #define ALIGN(v, a) (((v) + (a)-1) & ~((a)-1))
>
> +extern uint16_t __drm_device_id;
> +
> int drm_get_card(void);
> int __drm_open_any(void);
> int drm_open_any(void);
> diff --git a/lib/intel_chipset.c b/lib/intel_chipset.c
> index fafd232..33177c6 100644
> --- a/lib/intel_chipset.c
> +++ b/lib/intel_chipset.c
> @@ -125,26 +125,15 @@ intel_get_pci_device(void)
> uint32_t
> intel_get_drm_devid(int fd)
> {
> - uint32_t devid = 0;
> const char *override;
>
> - override = getenv("INTEL_DEVID_OVERRIDE");
> - if (override) {
> - devid = strtod(override, NULL);
> - } else {
> - struct drm_i915_getparam gp;
> - int ret;
> -
> - memset(&gp, 0, sizeof(gp));
> - gp.param = I915_PARAM_CHIPSET_ID;
> - gp.value = (int *)&devid;
> -
> - ret = ioctl(fd, DRM_IOCTL_I915_GETPARAM, &gp, sizeof(gp));
> - igt_assert(ret == 0);
> - errno = 0;
> - }
> + igt_assert(__drm_device_id);
>
> - return devid;
> + override = getenv("INTEL_DEVID_OVERRIDE");
> + if (override)
> + return strtod(override, NULL);
> + else
> + return __drm_device_id;
> }
>
> /**
>
> --
> Chris Wilson, Intel Open Source Technology Centre
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] proposal for DVFS (Dynamic Voltage Frequency Scaling)
On Wed, Feb 11, 2015 at 08:32:59AM +, Thulasimani, Sivakumar wrote: > Hi All, > I went through Ville's changes and it seems to be lacking support for > our one main user experience requirement in Android. Which is as follows > "Ux Restrictions: Flash/flicker should be avoided as much as possible( i.e > during unplug of HDMI avoid immediately lowering the CD clock after hotunplug > since it will result in flicker on LFP )." > The display will be turned off eventually (especially considering Android) > and would be good to change the CD clock at this point in time rather than > immediately on hot unplug. So we have to add to current implementation to > modify the behavior or go with the HWC+driver logic described below. Hm yeah. But for upstreaming can we just start with Ville's patch series to get things going? Also when reviewing patches please reply directly to them, not in some random other thread. Thanks, Daniel > > regards, > Sivakumar > > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of > Thulasimani, Sivakumar > Sent: Friday, January 16, 2015 9:56 AM > To: Daniel Vetter > Cc: intel-gfx@lists.freedesktop.org; Purushothaman, Vijay A > Subject: Re: [Intel-gfx] proposal for DVFS (Dynamic Voltage Frequency Scaling) > > Thanks for the pointer, let me sync with Ville and get back. > > > regards, > Sivakumar > > -Original Message- > From: daniel.vet...@ffwll.ch [mailto:daniel.vet...@ffwll.ch] On Behalf Of > Daniel Vetter > Sent: Friday, January 16, 2015 1:08 AM > To: Thulasimani, Sivakumar > Cc: intel-gfx@lists.freedesktop.org; Purushothaman, Vijay A; Syrjala, Ville > Subject: Re: [Intel-gfx] proposal for DVFS (Dynamic Voltage Frequency Scaling) > > You realize that Ville has implemented all this already and his patches are > only waiting for review? > -Daniel > > On Thu, Jan 15, 2015 at 2:50 PM, Thulasimani, Sivakumar > wrote: > > Hi, > > > > I’ll be working on implementing Dynamic Voltage > > Frequency Scaling in i915, whose rough proposal is provided below. > > Please go through the options and provide your feedback. > > > > > > > > What is DVFS ? > > > > Any SKU is capable of running at more than one display > > CD clock value but is configured to a default value during boot and is > > left untouched afterwards. Lowering this Display CD clock will result > > in better power savings while raising this will result in capability > > to support larger resolution displays. So the best scenario is to > > always detect the attached displays and adjust the CD Clock to the minimum > > required by the displays. > > DVFS is the process of dynamically changing the display CD clock based > > on attached displays. > > > > > > > > Usecases: ( considers low resolution LFP is used with 4K HDMI panel) > > > > Ø EDP (19x10) LFP panel alone is present at boot and can be driven > > with lower CD clock, thus saving power. > > > > Ø EDP (19x10) LFP panel was present at boot and 4K HDMI display is > > hot plugged in to the system. CD clock can be increased to the > > required value and then we can drive 4K panel. Thus save power while > > only LFP is in use but also provide the ability to support 4K displays. > > > > Ø 4K HDMI display is unplugged from the system, CD clock can now be > > lowered to the value required to drive LFP alone to save power. > > > > Ø Boot with LFP and 4K HDMI connected, the CD clock will be > > programmed to the value required to drive 4K HDMI. > > > > > > > > Technical Restrictions: > > > > Ø DVFS can be performed only when all displays are turned off > > (pipe/port/plane,etc) > > > > > > > > Ux Restrictions: > > > > Ø Flash/flicker should be avoided as much as possible( i.e during > > unplug of HDMI avoid immediately lowering the CD clock after hotunplug > > since it will result in flicker on LFP ) > > > > > > > > Possible Solutions : > > > > Ø Policy + implementation in driver > > > > o Driver will set the cd clock during boot based on attached panels > > > > o Post boot driver has to track each modeset for CD clock and resolution > > support. > > > > o If any change in CD clock is needed, driver has to disable all displays > > , change the cd clock and enable back all displays > > > > o Pros: > > > > · Changes are contained within driver > > > > o Cons: > > > > · Complexity increases within driver > > > > · User land/ HWC will be blind to internal operations > > > > Ø Policy in HWC and implementation in driver > > > > o Driver will set the cd clock during boot based on attached panels > > > > o Post boot, driver will fail any modeset that cannot be supported > > > > o HWC will be responsible for disabling all displays, issuing IOCTL to > > change CD clock and enabling required displays > > > > o Pros: > > > > · Driver implementation will be simple and clean > > > > · User land/HWC wi
Re: [Intel-gfx] proposal for DVFS (Dynamic Voltage Frequency Scaling)
On Wed, Feb 11, 2015 at 09:51:53AM +0100, Daniel Vetter wrote: > On Wed, Feb 11, 2015 at 08:32:59AM +, Thulasimani, Sivakumar wrote: > > Hi All, > > I went through Ville's changes and it seems to be lacking support for > > our one main user experience requirement in Android. Which is as follows > > "Ux Restrictions: Flash/flicker should be avoided as much as possible( i.e > > during unplug of HDMI avoid immediately lowering the CD clock after > > hotunplug since it will result in flicker on LFP )." > > The display will be turned off eventually (especially considering Android) > > and would be good to change the CD clock at this point in time rather than > > immediately on hot unplug. So we have to add to current implementation to > > modify the behavior or go with the HWC+driver logic described below. > > Hm yeah. But for upstreaming can we just start with Ville's patch series > to get things going? Thinking about this a bit more it's easy to implement your desired behaviour just in hwc: - On unplug of hdmi only do a dpms off for that hdmi output/crtc. That way the kernel will keep all allocations/requirements and hence also cdclock high. - When you power off the panel with dpms off, then you can do the setCrtc(off) to release resources and clock down cdclock. So no real changes required on the kernel side imo. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Stop requesting error_state reports.
On Wed, 11 Feb 2015, Rodrigo Vivi wrote: > When users face a issue that bother/matter he would enabled debug and > than we would receive the report. And QA/OSVs/Devs should always let > drm.debug enabled in certain level anyway. Judging by the bug reports, most users won't enable drm.debug when they face issues and report bugs, if they attach dmesg at all. If a GPU hang does not warrant an error in the logs, what does? BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/10] drm/i915: Remove intel_dsi_cmd.h
On Tue, 10 Feb 2015, Damien Lespiau wrote: > This header has been unusued since: > > commit 063c86f60ad4064b2cf62041bee8c6389e180b76 > Author: Jani Nikula > Date: Fri Jan 16 14:27:27 2015 +0200 > > drm/i915/dsi: remove intel_dsi_cmd.c and the unused functions therein > > Signed-off-by: Damien Lespiau Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_dsi_cmd.h | 39 > > 1 file changed, 39 deletions(-) > delete mode 100644 drivers/gpu/drm/i915/intel_dsi_cmd.h > > diff --git a/drivers/gpu/drm/i915/intel_dsi_cmd.h > b/drivers/gpu/drm/i915/intel_dsi_cmd.h > deleted file mode 100644 > index 8867790..000 > --- a/drivers/gpu/drm/i915/intel_dsi_cmd.h > +++ /dev/null > @@ -1,39 +0,0 @@ > -/* > - * Copyright © 2013 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. > - * > - * Author: Jani Nikula > - */ > - > -#ifndef _INTEL_DSI_DSI_H > -#define _INTEL_DSI_DSI_H > - > -#include > -#include > -#include > -#include "i915_drv.h" > -#include "intel_drv.h" > -#include "intel_dsi.h" > - > -void dsi_hs_mode_enable(struct intel_dsi *intel_dsi, bool enable, > - enum port port); > - > -#endif /* _INTEL_DSI_DSI_H */ > -- > 1.8.3.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Macbook Air 6, 2: i915-related interrupt storm after Yosemite update -- resolved
On 2014-11-01 18:08, Christian Kastner wrote: > I have a Macbook Air (2013) (6,2) which until recently was working > flawlessly with Debian unstable, which I use almost exclusively on that > machine. I did keep the OSX installation, mainly because it's the only > way to get firmware updates. > > Recently, in a moment of weakness, I said "yes" to the offer of > upgrading OSX to Yosemite. Since then, whenever I boot Debian, there is > an i915-related interrupt storm, with a kworker thread constantly > running at 70%. > > Downgrading OSX back to Mavericks did not help. Apparently Yosemite > included firmware updates, as within OSX I am shown version numbers that > are so new they aren't even listed on Apple's homepage yet. > > Here's what I see: > > $ GPE=/sys/firmware/acpi/interrupts/gpe66 > $ while true; doe cat $GPE; sleep 1; done > 727268 enabled > 757981 enabled > 788576 enabled > 807337 enabled > 828426 enabled > ... > > I've tested this with 3.16 and 3.17 kernels; I was using the former for > about a month now without issue. > > When I boot with modprobe.blacklist=i915, the issue disappears. > > Does anyone have an idea what could be going on? Good news: the recent update of OSX to 10.10.2 contained another silent firmware update, and it appears that this update resolved the issue. Regards, Christian ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/kms_addfb: Add support for fb modifiers
On 02/11/2015 08:15 AM, Daniel Vetter wrote: On Tue, Feb 10, 2015 at 05:17:34PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Just a few basic tests to make sure fb modifiers can be used and behave sanely when mixed with the old set_tiling API. v2: * Review feedback from Daniel Vetter: 1. Move cap detection into the subtest so skipping works. 2. Added some gtkdoc comments. 3. Two more test cases. 4. Removed unused parts for now. v3: * Removed two tests which do not make sense any more after the fb modifier rewrite. Signed-off-by: Tvrtko Ursulin --- lib/ioctl_wrappers.c | 17 + lib/ioctl_wrappers.h | 37 tests/kms_addfb.c| 68 3 files changed, 122 insertions(+) diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c index 19a457a..0a7841a 100644 --- a/lib/ioctl_wrappers.c +++ b/lib/ioctl_wrappers.c @@ -1091,3 +1091,20 @@ int gem_context_has_param(int fd, uint64_t param) return gem_context_get_param(fd, &p) == 0; } + +void igt_require_fb_modifiers(int fd) gtkdoc is missing here. It's in the header - has to be in .c ? Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/13] drm/i915: Announce support for framebuffer modifiers
On 02/11/2015 07:58 AM, Daniel Vetter wrote: On Tue, Feb 10, 2015 at 05:16:16PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Let the DRM core know we can handle it. v2: Change to boolean true. (Daniel Vetter) Signed-off-by: Tvrtko Ursulin Signed-off-by: Daniel Vetter All merged except for the drm core patch - I'll do some testcases for that one first. I wanted to ask how it will compile then but saw it is already in nightly. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/13] drm/i915/skl: CS flips are not supported with execlists
On 02/11/2015 07:40 AM, Daniel Vetter wrote: On Tue, Feb 10, 2015 at 05:16:12PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Therefore remove dead code. Commit message should state that skl requires execlist, otherwise it's not really clear why this is dead code. I've added that. Ah yes, don't know how I forgot to put that in. Sorry and thanks for fixing it up. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reject garbage in unsed ctx create/destroy fields
On Wed, Feb 11, 2015 at 08:44:47AM +0100, Daniel Vetter wrote: > Forgotten ever since, but luckily we're at least good at memset. > > Testecase: igt/gem_ctx_create/invalid-pad > Testecase: igt/gem_ctx_bad_destroy/invalid-pad > Signed-off-by: Daniel Vetter I wonder if we used mbz instead of pad, we would have a slightly more obvious reminder to zero the fields. Looks like pad is only cleared fortuituosly in current userspace though. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] tests/kms_addfb: Add support for fb modifiers
On Wed, Feb 11, 2015 at 09:51:22AM +, Tvrtko Ursulin wrote: > > On 02/11/2015 08:15 AM, Daniel Vetter wrote: > >On Tue, Feb 10, 2015 at 05:17:34PM +, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>Just a few basic tests to make sure fb modifiers can be used and > >>behave sanely when mixed with the old set_tiling API. > >> > >>v2: > >>* Review feedback from Daniel Vetter: > >> 1. Move cap detection into the subtest so skipping works. > >> 2. Added some gtkdoc comments. > >> 3. Two more test cases. > >> 4. Removed unused parts for now. > >> > >>v3: > >>* Removed two tests which do not make sense any more after the > >> fb modifier rewrite. > >> > >>Signed-off-by: Tvrtko Ursulin > >>--- > >> lib/ioctl_wrappers.c | 17 + > >> lib/ioctl_wrappers.h | 37 > >> tests/kms_addfb.c| 68 > >> > >> 3 files changed, 122 insertions(+) > >> > >>diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c > >>index 19a457a..0a7841a 100644 > >>--- a/lib/ioctl_wrappers.c > >>+++ b/lib/ioctl_wrappers.c > >>@@ -1091,3 +1091,20 @@ int gem_context_has_param(int fd, uint64_t param) > >> > >>return gem_context_get_param(fd, &p) == 0; > >> } > >>+ > >>+void igt_require_fb_modifiers(int fd) > > > >gtkdoc is missing here. > > It's in the header - has to be in .c ? Yeah we generally put them all into the .c file. Increases the chance that when someone changes the code they update docs. And having them all together makes it easier to keep the wording consistent for same concepts. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/13] drm/i915: Announce support for framebuffer modifiers
On Wed, Feb 11, 2015 at 09:57:09AM +, Tvrtko Ursulin wrote: > > On 02/11/2015 07:58 AM, Daniel Vetter wrote: > >On Tue, Feb 10, 2015 at 05:16:16PM +, Tvrtko Ursulin wrote: > >>From: Tvrtko Ursulin > >> > >>Let the DRM core know we can handle it. > >> > >>v2: Change to boolean true. (Daniel Vetter) > >> > >>Signed-off-by: Tvrtko Ursulin > >>Signed-off-by: Daniel Vetter > > > >All merged except for the drm core patch - I'll do some testcases for that > >one first. > > I wanted to ask how it will compile then but saw it is already in nightly. I've meant "drm: Also check unused fields for addfb2" since the basic modifier patch landed already. I wasn't really clear. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] proposal for DVFS (Dynamic Voltage Frequency Scaling)
Thanks for the suggestion Daniel, this seems simpler solution to the problem. I'll check for corner cases and get back if any more changes are needed. regards, Sivakumar -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Wednesday, February 11, 2015 2:24 PM To: Thulasimani, Sivakumar Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org; Purushothaman, Vijay A Subject: Re: [Intel-gfx] proposal for DVFS (Dynamic Voltage Frequency Scaling) On Wed, Feb 11, 2015 at 09:51:53AM +0100, Daniel Vetter wrote: > On Wed, Feb 11, 2015 at 08:32:59AM +, Thulasimani, Sivakumar wrote: > > Hi All, > > I went through Ville's changes and it seems to be lacking support > > for our one main user experience requirement in Android. Which is as > > follows "Ux Restrictions: Flash/flicker should be avoided as much as > > possible( i.e during unplug of HDMI avoid immediately lowering the CD clock > > after hotunplug since it will result in flicker on LFP )." > > The display will be turned off eventually (especially considering Android) > > and would be good to change the CD clock at this point in time rather than > > immediately on hot unplug. So we have to add to current implementation to > > modify the behavior or go with the HWC+driver logic described below. > > Hm yeah. But for upstreaming can we just start with Ville's patch > series to get things going? Thinking about this a bit more it's easy to implement your desired behaviour just in hwc: - On unplug of hdmi only do a dpms off for that hdmi output/crtc. That way the kernel will keep all allocations/requirements and hence also cdclock high. - When you power off the panel with dpms off, then you can do the setCrtc(off) to release resources and clock down cdclock. So no real changes required on the kernel side imo. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave - Here's a batch of i915 fixes for drm-next, with more cc: stable material than fixes specific to drm-next. BR, Jani. The following changes since commit 1293eaa3ebf92f146f366d9b678a07b8b3200ea1: drm/i915: Update DRIVER_DATE to 20150130 (2015-01-30 22:37:54 +0100) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2015-02-11 for you to fetch changes up to f8bd9b326c89792bd0f793d6abfaa988accae8db: drm/i915: Clamp efficient frequency to valid range (2015-02-11 10:25:34 +0200) Chris Wilson (2): drm/i915: Insert a command barrier on BLT/BSD cache flushes drm/i915: Do not invalidate obj->pages under mempressure Daniel Vetter (1): drm/i915: Drop vblank wait from intel_dp_link_down Michał Winiarski (1): drm/i915: Prevent use-after-free in invalidate_range_start callback Mika Kuoppala (2): drm/i915: Take runtime pm reference on hangcheck_info drm/i915: Squelch overzealous uncore reset WARN_ON Shobhit Kumar (2): drm/i915: Correct the IOSF Dev_FN field for IOSF transfers drm/i915: Correct the base value while updating LP_OUTPUT_HOLD in MIPI_PORT_CTRL Tom O'Rourke (1): drm/i915: Clamp efficient frequency to valid range Ville Syrjälä (1): drm/i915: Really ignore long HPD pulses on eDP drivers/gpu/drm/i915/i915_debugfs.c | 22 +++ drivers/gpu/drm/i915/i915_gem.c | 49 ++--- drivers/gpu/drm/i915/i915_gem_userptr.c | 20 -- drivers/gpu/drm/i915/intel_dp.c | 19 ++--- drivers/gpu/drm/i915/intel_dsi.c| 5 ++-- drivers/gpu/drm/i915/intel_lrc.c| 20 -- drivers/gpu/drm/i915/intel_pm.c | 5 +++- drivers/gpu/drm/i915/intel_ringbuffer.c | 23 +--- drivers/gpu/drm/i915/intel_sideband.c | 26 - drivers/gpu/drm/i915/intel_uncore.c | 9 +- 10 files changed, 96 insertions(+), 102 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Reject garbage in unsed ctx create/destroy fields
On Wed, Feb 11, 2015 at 10:01:33AM +, Chris Wilson wrote: > On Wed, Feb 11, 2015 at 08:44:47AM +0100, Daniel Vetter wrote: > > Forgotten ever since, but luckily we're at least good at memset. > > > > Testecase: igt/gem_ctx_create/invalid-pad > > Testecase: igt/gem_ctx_bad_destroy/invalid-pad > > Signed-off-by: Daniel Vetter > > I wonder if we used mbz instead of pad, we would have a slightly more > obvious reminder to zero the fields. > > Looks like pad is only cleared fortuituosly in current userspace though. Oops, VG_CLEAR isn't as good as I've thought. Time to write more patches I guess. But I expect that most compile libdrm with valgrind support, so I still think we could try this out for 3.21 and see what happens ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/10] drm/i915: Remove the IS_SNB_G1 define
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5752 -Summary- Platform Delta drm-intel-nightly Series Applied PNV +7 275/283 282/283 ILK -2 310/310 308/310 SNB +2 320/346 322/346 IVB 380/384 380/384 BYT 296/296 296/296 HSW +3-1 422/428 424/428 BDW 318/333 318/333 -Detailed- Platform Testdrm-intel-nightly Series Applied PNV igt_gem_userptr_blits_coherency-sync CRASH(5, M7)PASS(2, M7) PASS(1, M7) PNV igt_gem_userptr_blits_coherency-unsync CRASH(5, M7)PASS(3, M7) PASS(1, M7) PNV igt_gem_userptr_blits_create-destroy-sync NRUN(1, M7)PASS(8, M7) PASS(1, M7) PNV igt_gen3_render_linear_blits FAIL(3, M7)PASS(2, M7) PASS(1, M7) PNV igt_gen3_render_mixed_blits FAIL(2, M7)PASS(3, M7) PASS(1, M7) PNV igt_gen3_render_tiledx_blits FAIL(4, M7)TIMEOUT(1, M7)PASS(4, M7) PASS(1, M7) PNV igt_gen3_render_tiledy_blits FAIL(3, M7)PASS(4, M7) PASS(1, M7) *ILK igt_gem_seqno_wrap PASS(2, M26) DMESG_WARN(1, M26) ILK igt_drv_suspend_fence-restore-tiled2untiled DMESG_WARN(1, M26)PASS(1, M26) DMESG_WARN(1, M26) *SNB igt_kms_flip_bo-too-big BLACKLIST(1, M35) PASS(1, M35) *SNB igt_kms_flip_bo-too-big-interruptible BLACKLIST(1, M35) PASS(1, M35) *HSW igt_gem_pwrite_pread_uncached-copy-performance PASS(2, M40) DMESG_WARN(1, M40) *HSW igt_kms_flip_bo-too-big BLACKLIST(1, M40) PASS(1, M40) *HSW igt_kms_flip_bo-too-big-interruptible BLACKLIST(1, M40) PASS(1, M40) HSW igt_kms_flip_plain-flip-fb-recreate-interruptible TIMEOUT(6, M40)PASS(5, M40) PASS(1, M40) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH drm-intel] drm/i915: intel_ring_setup_status_page() can be static
drivers/gpu/drm/i915/intel_ringbuffer.c:505:6: sparse: symbol
'intel_ring_setup_status_page' was not declared. Should it be static?
Signed-off-by: Fengguang Wu
---
intel_ringbuffer.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 1b1fa8c..9ebc11e 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -502,7 +502,7 @@ static void ring_setup_phys_status_page(struct
intel_engine_cs *ring)
I915_WRITE(HWS_PGA, addr);
}
-void intel_ring_setup_status_page(struct intel_engine_cs *ring)
+static void intel_ring_setup_status_page(struct intel_engine_cs *ring)
{
struct drm_device *dev = ring->dev;
struct drm_i915_private *dev_priv = ring->dev->dev_private;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:drm-intel-next-queued 161/168] drivers/gpu/drm/i915/intel_ringbuffer.c:505:6: sparse: symbol 'intel_ring_setup_status_page' was not declared. Should it be static?
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: db275e69533f74b3d5cf2884cb8bba9d7640724d commit: 64a008c61c4615ba0fffd1cdae7d39b4246048f8 [161/168] drm/i915: Make intel_ring_setup_status_page() static reproduce: # apt-get install sparse git checkout 64a008c61c4615ba0fffd1cdae7d39b4246048f8 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/i915/intel_ringbuffer.c:505:6: sparse: symbol >> 'intel_ring_setup_status_page' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center http://lists.01.org/mailman/listinfo/kbuild Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] intel: Unconditionally clear ioctl structs
We really have to do this to avoid surprises when extending the ABI
later on. Especially when growing the structures.
Signed-off-by: Daniel Vetter
---
intel/intel_bufmgr_gem.c | 68
1 file changed, 34 insertions(+), 34 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index cf85bb8ae0bf..78875fd329f2 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -74,7 +74,7 @@
#define VG(x)
#endif
-#define VG_CLEAR(s) VG(memset(&s, 0, sizeof(s)))
+#define memclear(s) memset(&s, 0, sizeof(s))
#define DBG(...) do { \
if (bufmgr_gem->bufmgr.debug) \
@@ -593,7 +593,7 @@ drm_intel_gem_bo_busy(drm_intel_bo *bo)
if (bo_gem->reusable && bo_gem->idle)
return false;
- VG_CLEAR(busy);
+ memclear(busy);
busy.handle = bo_gem->gem_handle;
ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_BUSY, &busy);
@@ -612,7 +612,7 @@ drm_intel_gem_bo_madvise_internal(drm_intel_bufmgr_gem
*bufmgr_gem,
{
struct drm_i915_gem_madvise madv;
- VG_CLEAR(madv);
+ memclear(madv);
madv.handle = bo_gem->gem_handle;
madv.madv = state;
madv.retained = 1;
@@ -741,7 +741,7 @@ retry:
bo_gem->bo.size = bo_size;
- VG_CLEAR(create);
+ memclear(create);
create.size = bo_size;
ret = drmIoctl(bufmgr_gem->fd,
@@ -888,7 +888,7 @@ drm_intel_gem_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
bo_gem->bo.size = size;
- VG_CLEAR(userptr);
+ memclear(userptr);
userptr.user_ptr = (__u64)((unsigned long)addr);
userptr.user_size = size;
userptr.flags = flags;
@@ -972,7 +972,7 @@ drm_intel_bo_gem_create_from_name(drm_intel_bufmgr *bufmgr,
}
}
- VG_CLEAR(open_arg);
+ memclear(open_arg);
open_arg.name = handle;
ret = drmIoctl(bufmgr_gem->fd,
DRM_IOCTL_GEM_OPEN,
@@ -1017,7 +1017,7 @@ drm_intel_bo_gem_create_from_name(drm_intel_bufmgr
*bufmgr,
bo_gem->global_name = handle;
bo_gem->reusable = false;
- VG_CLEAR(get_tiling);
+ memclear(get_tiling);
get_tiling.handle = bo_gem->gem_handle;
ret = drmIoctl(bufmgr_gem->fd,
DRM_IOCTL_I915_GEM_GET_TILING,
@@ -1060,7 +1060,7 @@ drm_intel_gem_bo_free(drm_intel_bo *bo)
}
/* Close this object */
- VG_CLEAR(close);
+ memclear(close);
close.handle = bo_gem->gem_handle;
ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_GEM_CLOSE, &close);
if (ret != 0) {
@@ -1292,9 +1292,8 @@ static int drm_intel_gem_bo_map(drm_intel_bo *bo, int
write_enable)
DBG("bo_map: %d (%s), map_count=%d\n",
bo_gem->gem_handle, bo_gem->name, bo_gem->map_count);
- VG_CLEAR(mmap_arg);
+ memclear(mmap_arg);
mmap_arg.handle = bo_gem->gem_handle;
- mmap_arg.offset = 0;
mmap_arg.size = bo->size;
ret = drmIoctl(bufmgr_gem->fd,
DRM_IOCTL_I915_GEM_MMAP,
@@ -1316,7 +1315,7 @@ static int drm_intel_gem_bo_map(drm_intel_bo *bo, int
write_enable)
bo_gem->mem_virtual);
bo->virtual = bo_gem->mem_virtual;
- VG_CLEAR(set_domain);
+ memclear(set_domain);
set_domain.handle = bo_gem->gem_handle;
set_domain.read_domains = I915_GEM_DOMAIN_CPU;
if (write_enable)
@@ -1362,7 +1361,7 @@ map_gtt(drm_intel_bo *bo)
DBG("bo_map_gtt: mmap %d (%s), map_count=%d\n",
bo_gem->gem_handle, bo_gem->name, bo_gem->map_count);
- VG_CLEAR(mmap_arg);
+ memclear(mmap_arg);
mmap_arg.handle = bo_gem->gem_handle;
/* Get the fake offset back... */
@@ -1430,7 +1429,7 @@ drm_intel_gem_bo_map_gtt(drm_intel_bo *bo)
* tell it when we're about to use things if we had done
* rendering and it still happens to be bound to the GTT.
*/
- VG_CLEAR(set_domain);
+ memclear(set_domain);
set_domain.handle = bo_gem->gem_handle;
set_domain.read_domains = I915_GEM_DOMAIN_GTT;
set_domain.write_domain = I915_GEM_DOMAIN_GTT;
@@ -1529,7 +1528,7 @@ static int drm_intel_gem_bo_unmap(drm_intel_bo *bo)
* Unlike GTT set domains, this only does work if the
* buffer should be scanout-related.
*/
- VG_CLEAR(sw_finish);
+ memclear(sw_finish);
sw_finish.handle = bo_gem->gem_handle;
ret = drmIoctl(bufmgr_gem->fd,
DRM_IOCTL_I915_GEM_SW_FINISH,
@@ -1571,7 +1570,7 @@ drm_intel_gem_bo_subdata(drm_intel_bo *bo, unsigned long
offset,
if (bo_gem->is_userptr)
[Intel-gfx] [PATCH 3/4] drm: use drmIoctl everywhere
Well just core drm. All the other callers in there that still use
direct calls to ioctl have some custom retry logic already, so should
be good already.
freedreno/kgsl ahas all the other bare ioctl calls, dunnot what to do
about that.
Signed-off-by: Daniel Vetter
---
xf86drm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index fb673b58afb3..263d6835c29a 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -2543,12 +2543,12 @@ void drmCloseOnce(int fd)
int drmSetMaster(int fd)
{
- return ioctl(fd, DRM_IOCTL_SET_MASTER, 0);
+ return drmIoctl(fd, DRM_IOCTL_SET_MASTER, 0);
}
int drmDropMaster(int fd)
{
- return ioctl(fd, DRM_IOCTL_DROP_MASTER, 0);
+ return drmIoctl(fd, DRM_IOCTL_DROP_MASTER, 0);
}
char *drmGetDeviceNameFromFd(int fd)
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] xf86drmMode: Unconditionally clear ioctl structs
We really have to do this to avoid surprises when extending the ABI
later on. Especially when growing the structures.
Signed-off-by: Daniel Vetter
---
xf86drmMode.c | 55 ---
1 file changed, 28 insertions(+), 27 deletions(-)
diff --git a/xf86drmMode.c b/xf86drmMode.c
index e3e599bdc39d..9ea8fe721842 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -61,7 +61,7 @@
#define VG(x)
#endif
-#define VG_CLEAR(s) VG(memset(&s, 0, sizeof(s)))
+#define memclear(s) memset(&s, 0, sizeof(s))
#define U642VOID(x) ((void *)(unsigned long)(x))
#define VOID2U64(x) ((uint64_t)(unsigned long)(x))
@@ -164,7 +164,7 @@ drmModeResPtr drmModeGetResources(int fd)
drmModeResPtr r = 0;
retry:
- memset(&res, 0, sizeof(struct drm_mode_card_res));
+ memclear(res);
if (drmIoctl(fd, DRM_IOCTL_MODE_GETRESOURCES, &res))
return 0;
@@ -259,7 +259,7 @@ int drmModeAddFB(int fd, uint32_t width, uint32_t height,
uint8_t depth,
struct drm_mode_fb_cmd f;
int ret;
- VG_CLEAR(f);
+ memclear(f);
f.width = width;
f.height = height;
f.pitch = pitch;
@@ -282,6 +282,7 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
struct drm_mode_fb_cmd2 f;
int ret;
+ memclear(f);
f.width = width;
f.height = height;
f.pixel_format = pixel_format;
@@ -300,8 +301,6 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
int drmModeRmFB(int fd, uint32_t bufferId)
{
return DRM_IOCTL(fd, DRM_IOCTL_MODE_RMFB, &bufferId);
-
-
}
drmModeFBPtr drmModeGetFB(int fd, uint32_t buf)
@@ -309,6 +308,7 @@ drmModeFBPtr drmModeGetFB(int fd, uint32_t buf)
struct drm_mode_fb_cmd info;
drmModeFBPtr r;
+ memclear(info);
info.fb_id = buf;
if (drmIoctl(fd, DRM_IOCTL_MODE_GETFB, &info))
@@ -331,8 +331,9 @@ drmModeFBPtr drmModeGetFB(int fd, uint32_t buf)
int drmModeDirtyFB(int fd, uint32_t bufferId,
drmModeClipPtr clips, uint32_t num_clips)
{
- struct drm_mode_fb_dirty_cmd dirty = { 0 };
+ struct drm_mode_fb_dirty_cmd dirty;
+ memclear(dirty);
dirty.fb_id = bufferId;
dirty.clips_ptr = VOID2U64(clips);
dirty.num_clips = num_clips;
@@ -350,7 +351,7 @@ drmModeCrtcPtr drmModeGetCrtc(int fd, uint32_t crtcId)
struct drm_mode_crtc crtc;
drmModeCrtcPtr r;
- VG_CLEAR(crtc);
+ memclear(crtc);
crtc.crtc_id = crtcId;
if (drmIoctl(fd, DRM_IOCTL_MODE_GETCRTC, &crtc))
@@ -384,7 +385,7 @@ int drmModeSetCrtc(int fd, uint32_t crtcId, uint32_t
bufferId,
{
struct drm_mode_crtc crtc;
- VG_CLEAR(crtc);
+ memclear(crtc);
crtc.x = x;
crtc.y = y;
crtc.crtc_id = crtcId;
@@ -394,8 +395,7 @@ int drmModeSetCrtc(int fd, uint32_t crtcId, uint32_t
bufferId,
if (mode) {
memcpy(&crtc.mode, mode, sizeof(struct drm_mode_modeinfo));
crtc.mode_valid = 1;
- } else
- crtc.mode_valid = 0;
+ }
return DRM_IOCTL(fd, DRM_IOCTL_MODE_SETCRTC, &crtc);
}
@@ -408,6 +408,7 @@ int drmModeSetCursor(int fd, uint32_t crtcId, uint32_t
bo_handle, uint32_t width
{
struct drm_mode_cursor arg;
+ memclear(arg);
arg.flags = DRM_MODE_CURSOR_BO;
arg.crtc_id = crtcId;
arg.width = width;
@@ -421,6 +422,7 @@ int drmModeSetCursor2(int fd, uint32_t crtcId, uint32_t
bo_handle, uint32_t widt
{
struct drm_mode_cursor2 arg;
+ memclear(arg);
arg.flags = DRM_MODE_CURSOR_BO;
arg.crtc_id = crtcId;
arg.width = width;
@@ -436,6 +438,7 @@ int drmModeMoveCursor(int fd, uint32_t crtcId, int x, int y)
{
struct drm_mode_cursor arg;
+ memclear(arg);
arg.flags = DRM_MODE_CURSOR_MOVE;
arg.crtc_id = crtcId;
arg.x = x;
@@ -452,11 +455,8 @@ drmModeEncoderPtr drmModeGetEncoder(int fd, uint32_t
encoder_id)
struct drm_mode_get_encoder enc;
drmModeEncoderPtr r = NULL;
+ memclear(enc);
enc.encoder_id = encoder_id;
- enc.crtc_id = 0;
- enc.encoder_type = 0;
- enc.possible_crtcs = 0;
- enc.possible_clones = 0;
if (drmIoctl(fd, DRM_IOCTL_MODE_GETENCODER, &enc))
return 0;
@@ -483,7 +483,7 @@ drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t
connector_id)
drmModeConnectorPtr r = NULL;
retry:
- memset(&conn, 0, sizeof(struct drm_mode_get_connector));
+ memclear(conn);
conn.connector_id = connector_id;
if (drmIoctl(fd, DRM_IOCTL_MODE_GETCONNECTOR, &conn))
@@ -576,6 +576,7 @@ int drmModeAttachMode(int fd, uint32_t connector_id,
drmModeModeInfoPtr mode_inf
{
struct drm_mode_mode_cmd res;
+ memclear(res);
memcpy(&res.mode, mode_info, sizeof(struct drm_mode_modeinfo));
res.connector
[Intel-gfx] [PATCH 4/4] xf86drm: Unconditionally clear ioctl structs
We really have to do this to avoid surprises when extending the ABI
later on. Especially when growing the structures.
A bit overkill to update all the old legacy ioctl wrappers, but can't
hurt really either.
Signed-off-by: Daniel Vetter
---
xf86drm.c | 112 ++
1 file changed, 77 insertions(+), 35 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 263d6835c29a..a2e24eb5f76c 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -89,6 +89,8 @@
#define DRM_NODE_PRIMARY 1
#define DRM_NODE_RENDER 2
+#define memclear(s) memset(&s, 0, sizeof(s))
+
static drmServerInfoPtr drm_server_info;
void drmSetServerInfo(drmServerInfoPtr info)
@@ -766,12 +768,7 @@ drmVersionPtr drmGetVersion(int fd)
drmVersionPtr retval;
drm_version_t *version = drmMalloc(sizeof(*version));
-version->name_len= 0;
-version->name= NULL;
-version->date_len= 0;
-version->date= NULL;
-version->desc_len= 0;
-version->desc= NULL;
+memclear(version);
if (drmIoctl(fd, DRM_IOCTL_VERSION, version)) {
drmFreeKernelVersion(version);
@@ -839,9 +836,12 @@ drmVersionPtr drmGetLibVersion(int fd)
int drmGetCap(int fd, uint64_t capability, uint64_t *value)
{
- struct drm_get_cap cap = { capability, 0 };
+ struct drm_get_cap cap;
int ret;
+ memclear(cap);
+ cap.capability = capability;
+
ret = drmIoctl(fd, DRM_IOCTL_GET_CAP, &cap);
if (ret)
return ret;
@@ -852,7 +852,11 @@ int drmGetCap(int fd, uint64_t capability, uint64_t *value)
int drmSetClientCap(int fd, uint64_t capability, uint64_t value)
{
- struct drm_set_client_cap cap = { capability, value };
+ struct drm_set_client_cap cap;
+
+ memclear(cap);
+ cap.capability = capability;
+ cap.value = value;
return drmIoctl(fd, DRM_IOCTL_SET_CLIENT_CAP, &cap);
}
@@ -887,8 +891,7 @@ char *drmGetBusid(int fd)
{
drm_unique_t u;
-u.unique_len = 0;
-u.unique = NULL;
+memclear(u);
if (drmIoctl(fd, DRM_IOCTL_GET_UNIQUE, &u))
return NULL;
@@ -917,6 +920,7 @@ int drmSetBusid(int fd, const char *busid)
{
drm_unique_t u;
+memclear(u);
u.unique = (char *)busid;
u.unique_len = strlen(busid);
@@ -930,6 +934,8 @@ int drmGetMagic(int fd, drm_magic_t * magic)
{
drm_auth_t auth;
+memclear(auth);
+
*magic = 0;
if (drmIoctl(fd, DRM_IOCTL_GET_MAGIC, &auth))
return -errno;
@@ -941,6 +947,7 @@ int drmAuthMagic(int fd, drm_magic_t magic)
{
drm_auth_t auth;
+memclear(auth);
auth.magic = magic;
if (drmIoctl(fd, DRM_IOCTL_AUTH_MAGIC, &auth))
return -errno;
@@ -1002,9 +1009,9 @@ int drmAddMap(int fd, drm_handle_t offset, drmSize size,
drmMapType type,
{
drm_map_t map;
+memclear(map);
map.offset = offset;
map.size= size;
-map.handle = 0;
map.type= type;
map.flags = flags;
if (drmIoctl(fd, DRM_IOCTL_ADD_MAP, &map))
@@ -1018,6 +1025,7 @@ int drmRmMap(int fd, drm_handle_t handle)
{
drm_map_t map;
+memclear(map);
map.handle = (void *)(uintptr_t)handle;
if(drmIoctl(fd, DRM_IOCTL_RM_MAP, &map))
@@ -1046,10 +1054,9 @@ int drmAddBufs(int fd, int count, int size,
drmBufDescFlags flags,
{
drm_buf_desc_t request;
+memclear(request);
request.count = count;
request.size = size;
-request.low_mark = 0;
-request.high_mark = 0;
request.flags = flags;
request.agp_start = agp_offset;
@@ -1063,8 +1070,7 @@ int drmMarkBufs(int fd, double low, double high)
drm_buf_info_t info;
inti;
-info.count = 0;
-info.list = NULL;
+memclear(info);
if (drmIoctl(fd, DRM_IOCTL_INFO_BUFS, &info))
return -EINVAL;
@@ -1114,6 +1120,7 @@ int drmFreeBufs(int fd, int count, int *list)
{
drm_buf_free_t request;
+memclear(request);
request.count = count;
request.list = list;
if (drmIoctl(fd, DRM_IOCTL_FREE_BUFS, &request))
@@ -1202,8 +1209,7 @@ drmBufInfoPtr drmGetBufInfo(int fd)
drmBufInfoPtr retval;
inti;
-info.count = 0;
-info.list = NULL;
+memclear(info);
if (drmIoctl(fd, DRM_IOCTL_INFO_BUFS, &info))
return NULL;
@@ -1253,9 +1259,7 @@ drmBufMapPtr drmMapBufs(int fd)
drmBufMapPtr retval;
int i;
-bufs.count = 0;
-bufs.list = NULL;
-bufs.virtual = NULL;
+memclear(bufs);
if (drmIoctl(fd, DRM_IOCTL_MAP_BUFS, &bufs))
return NULL;
@@ -1371,6 +1375,7 @@ int drmGetLock(int fd, drm_context_t context,
drmLockFlags flags)
{
drm_lock_t lock;
+memclear(lock);
lock.context = context;
lock.flags = 0;
if (flags & DRM_LOCK_READY) lock.flags |= _DRM_LOCK_READY;
@@ -1401,8 +1406,8 @@ int drmUnlock(int fd, drm_context_t context)
{
drm_lock_t lock;
+memc
Re: [Intel-gfx] [PULL] drm-intel-next-fixes
On Wed, Feb 11, 2015 at 01:09:51PM +0200, Jani Nikula wrote: > > Hi Dave - > > Here's a batch of i915 fixes for drm-next, with more cc: stable material > than fixes specific to drm-next. > > BR, > Jani. > > The following changes since commit 1293eaa3ebf92f146f366d9b678a07b8b3200ea1: > > drm/i915: Update DRIVER_DATE to 20150130 (2015-01-30 22:37:54 +0100) > > are available in the git repository at: > > git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2015-02-11 > > for you to fetch changes up to f8bd9b326c89792bd0f793d6abfaa988accae8db: > > drm/i915: Clamp efficient frequency to valid range (2015-02-11 10:25:34 > +0200) > > > Chris Wilson (2): > drm/i915: Insert a command barrier on BLT/BSD cache flushes > drm/i915: Do not invalidate obj->pages under mempressure As per the irc discussion this one here needs to be dropped again. Turns out userspace has been lying to the kernel and got what it asked for. -Daniel > > Daniel Vetter (1): > drm/i915: Drop vblank wait from intel_dp_link_down > > Michał Winiarski (1): > drm/i915: Prevent use-after-free in invalidate_range_start callback > > Mika Kuoppala (2): > drm/i915: Take runtime pm reference on hangcheck_info > drm/i915: Squelch overzealous uncore reset WARN_ON > > Shobhit Kumar (2): > drm/i915: Correct the IOSF Dev_FN field for IOSF transfers > drm/i915: Correct the base value while updating LP_OUTPUT_HOLD in > MIPI_PORT_CTRL > > Tom O'Rourke (1): > drm/i915: Clamp efficient frequency to valid range > > Ville Syrjälä (1): > drm/i915: Really ignore long HPD pulses on eDP > > drivers/gpu/drm/i915/i915_debugfs.c | 22 +++ > drivers/gpu/drm/i915/i915_gem.c | 49 > ++--- > drivers/gpu/drm/i915/i915_gem_userptr.c | 20 -- > drivers/gpu/drm/i915/intel_dp.c | 19 ++--- > drivers/gpu/drm/i915/intel_dsi.c| 5 ++-- > drivers/gpu/drm/i915/intel_lrc.c| 20 -- > drivers/gpu/drm/i915/intel_pm.c | 5 +++- > drivers/gpu/drm/i915/intel_ringbuffer.c | 23 +--- > drivers/gpu/drm/i915/intel_sideband.c | 26 - > drivers/gpu/drm/i915/intel_uncore.c | 9 +- > 10 files changed, 96 insertions(+), 102 deletions(-) > > -- > Jani Nikula, Intel Open Source Technology Center -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests: remove intel-specific tests
These all moved to igt meanwhile.
Signed-off-by: Daniel Vetter
---
.gitignore| 4 --
tests/Makefile.am | 9
tests/gem_basic.c | 102
tests/gem_flink.c | 137 -
tests/gem_mmap.c | 136
tests/gem_readwrite.c | 139 --
6 files changed, 527 deletions(-)
delete mode 100644 tests/gem_basic.c
delete mode 100644 tests/gem_flink.c
delete mode 100644 tests/gem_mmap.c
delete mode 100644 tests/gem_readwrite.c
diff --git a/.gitignore b/.gitignore
index 3596a4a8e4b9..06cc9283b494 100644
--- a/.gitignore
+++ b/.gitignore
@@ -79,10 +79,6 @@ tests/getclient
tests/getstats
tests/getversion
tests/lock
-tests/gem_basic
-tests/gem_flink
-tests/gem_mmap
-tests/gem_readwrite
tests/openclose
tests/setversion
tests/updatedraw
diff --git a/tests/Makefile.am b/tests/Makefile.am
index e7ec4fa5ecff..37b8d3a1a271 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -58,15 +58,6 @@ TESTS = \
SUBDIRS += vbltest $(NULL)
-if HAVE_INTEL
-TESTS += \
- gem_basic \
- gem_flink \
- gem_readwrite \
- gem_mmap\
- $(NULL)
-endif
-
check_PROGRAMS += $(TESTS)
endif
diff --git a/tests/gem_basic.c b/tests/gem_basic.c
deleted file mode 100644
index 4e4b6cbdf1a9..
--- a/tests/gem_basic.c
+++ /dev/null
@@ -1,102 +0,0 @@
-/*
- * Copyright © 2008 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.
- *
- * Authors:
- *Eric Anholt
- *
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include "drm.h"
-#include "i915_drm.h"
-
-static void
-test_bad_close(int fd)
-{
- struct drm_gem_close close;
- int ret;
-
- printf("Testing error return on bad close ioctl.\n");
-
- close.handle = 0x10101010;
- ret = ioctl(fd, DRM_IOCTL_GEM_CLOSE, &close);
-
- assert(ret == -1 && errno == EINVAL);
-}
-
-static void
-test_create_close(int fd)
-{
- struct drm_i915_gem_create create;
- struct drm_gem_close close;
- int ret;
-
- printf("Testing creating and closing an object.\n");
-
- memset(&create, 0, sizeof(create));
- create.size = 16 * 1024;
- ret = ioctl(fd, DRM_IOCTL_I915_GEM_CREATE, &create);
- assert(ret == 0);
-
- close.handle = create.handle;
- ret = ioctl(fd, DRM_IOCTL_GEM_CLOSE, &close);
-}
-
-static void
-test_create_fd_close(int fd)
-{
- struct drm_i915_gem_create create;
- int ret;
-
- printf("Testing closing with an object allocated.\n");
-
- memset(&create, 0, sizeof(create));
- create.size = 16 * 1024;
- ret = ioctl(fd, DRM_IOCTL_I915_GEM_CREATE, &create);
- assert(ret == 0);
-
- close(fd);
-}
-
-int main(int argc, char **argv)
-{
- int fd;
-
- fd = drm_open_matching("8086:*", 0);
- if (fd < 0) {
- fprintf(stderr, "failed to open intel drm device\n");
- return 0;
- }
-
- test_bad_close(fd);
- test_create_close(fd);
- test_create_fd_close(fd);
-
- return 0;
-}
diff --git a/tests/gem_flink.c b/tests/gem_flink.c
deleted file mode 100644
index ce43e42201ac..
--- a/tests/gem_flink.c
+++ /dev/null
@@ -1,137 +0,0 @@
-/*
- * Copyright © 2008 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, p
[Intel-gfx] [PULL] drm-intel-next-fixes v2
Hi Dave - Another go, with "drm/i915: Do not invalidate obj->pages under mempressure" dropped. Here's a batch of i915 fixes for drm-next, with more cc: stable material than fixes specific to drm-next. BR, Jani. The following changes since commit 1293eaa3ebf92f146f366d9b678a07b8b3200ea1: drm/i915: Update DRIVER_DATE to 20150130 (2015-01-30 22:37:54 +0100) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-fixes-2015-02-11 for you to fetch changes up to 46efa4abe5712276494adbce102f46e3214632fd: drm/i915: Clamp efficient frequency to valid range (2015-02-11 14:09:51 +0200) Chris Wilson (1): drm/i915: Insert a command barrier on BLT/BSD cache flushes Daniel Vetter (1): drm/i915: Drop vblank wait from intel_dp_link_down Michał Winiarski (1): drm/i915: Prevent use-after-free in invalidate_range_start callback Mika Kuoppala (2): drm/i915: Take runtime pm reference on hangcheck_info drm/i915: Squelch overzealous uncore reset WARN_ON Shobhit Kumar (2): drm/i915: Correct the IOSF Dev_FN field for IOSF transfers drm/i915: Correct the base value while updating LP_OUTPUT_HOLD in MIPI_PORT_CTRL Tom O'Rourke (1): drm/i915: Clamp efficient frequency to valid range Ville Syrjälä (1): drm/i915: Really ignore long HPD pulses on eDP drivers/gpu/drm/i915/i915_debugfs.c | 22 +- drivers/gpu/drm/i915/i915_gem_userptr.c | 20 ++-- drivers/gpu/drm/i915/intel_dp.c | 19 ++- drivers/gpu/drm/i915/intel_dsi.c| 5 ++--- drivers/gpu/drm/i915/intel_lrc.c| 20 +++- drivers/gpu/drm/i915/intel_pm.c | 5 - drivers/gpu/drm/i915/intel_ringbuffer.c | 23 +++ drivers/gpu/drm/i915/intel_sideband.c | 26 +- drivers/gpu/drm/i915/intel_uncore.c | 9 - 9 files changed, 94 insertions(+), 55 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm: use drmIoctl everywhere
On Wed, Feb 11, 2015 at 6:42 AM, Daniel Vetter wrote:
> Well just core drm. All the other callers in there that still use
> direct calls to ioctl have some custom retry logic already, so should
> be good already.
>
> freedreno/kgsl ahas all the other bare ioctl calls, dunnot what to do
> about that.
fwiw, the freedreno/kgsl bare ioctls are actually against the non-drm
device file.. freedreno/msm is the stuff for the upstream drm/msm
driver.
background: downstream android kernel w/ kgsl kernel driver has this
shim drm driver which is really just for getting flink names + non drm
device for everything else. It's kinda bonghits, really just exists
to give folks stuck w/ android drivers a fighting chance. And due to
different versions of kgsl floating around on the many different
android kernel branches, odds are still pretty grim (which is why kgsl
backend is disabled by default)
I guess technically they could still use drmIoctl() but it seemed a bit strange
BR,
-R
> Signed-off-by: Daniel Vetter
> ---
> xf86drm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index fb673b58afb3..263d6835c29a 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -2543,12 +2543,12 @@ void drmCloseOnce(int fd)
>
> int drmSetMaster(int fd)
> {
> - return ioctl(fd, DRM_IOCTL_SET_MASTER, 0);
> + return drmIoctl(fd, DRM_IOCTL_SET_MASTER, 0);
> }
>
> int drmDropMaster(int fd)
> {
> - return ioctl(fd, DRM_IOCTL_DROP_MASTER, 0);
> + return drmIoctl(fd, DRM_IOCTL_DROP_MASTER, 0);
> }
>
> char *drmGetDeviceNameFromFd(int fd)
> --
> 2.1.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] drm/i915: Add support for DRRS in intel_dp_set_m_n
Till Gen 7 we have two sets of M_N registers, but Gen 8 onwards
we have only one M_N register set. To support DRRS on both scenarios
a input parameter to intel_dp_set_m_n is added.
In case of DRRS, When platform provides two set of M_N registers for dp,
we can program them with two different dividers and switch between them.
But when only one such register set is provided, we have to program
the required divider M_N value on that registers itself.
Two enum members M1_N1 and M2_N2 are defined to represent the above
scenarios.
M1_N1: Program dp_m_n on M1_N1 registers
dp_m2_n2 on M2_N2 registers (If supported)
M2_N2: Program dp_m2_n2 on M1_N1 registers
M2_N2 registers are not supported
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_display.c | 30 +++---
drivers/gpu/drm/i915/intel_drv.h | 22 +-
2 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3fe9598..ced049a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4316,7 +4316,7 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
intel_prepare_shared_dpll(intel_crtc);
if (intel_crtc->config->has_dp_encoder)
- intel_dp_set_m_n(intel_crtc);
+ intel_dp_set_m_n(intel_crtc, M1_N1);
intel_set_pipe_timings(intel_crtc);
@@ -4424,7 +4424,7 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
intel_enable_shared_dpll(intel_crtc);
if (intel_crtc->config->has_dp_encoder)
- intel_dp_set_m_n(intel_crtc);
+ intel_dp_set_m_n(intel_crtc, M1_N1);
intel_set_pipe_timings(intel_crtc);
@@ -5038,7 +5038,7 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
}
if (intel_crtc->config->has_dp_encoder)
- intel_dp_set_m_n(intel_crtc);
+ intel_dp_set_m_n(intel_crtc, M1_N1);
intel_set_pipe_timings(intel_crtc);
@@ -5114,7 +5114,7 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc)
i9xx_set_pll_dividers(intel_crtc);
if (intel_crtc->config->has_dp_encoder)
- intel_dp_set_m_n(intel_crtc);
+ intel_dp_set_m_n(intel_crtc, M1_N1);
intel_set_pipe_timings(intel_crtc);
@@ -5889,13 +5889,29 @@ static void intel_cpu_transcoder_set_m_n(struct
intel_crtc *crtc,
}
}
-void intel_dp_set_m_n(struct intel_crtc *crtc)
+void intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n)
{
+ struct intel_link_m_n *dp_m_n, *dp_m2_n2 = NULL;
+
+ if (m_n == M1_N1) {
+ dp_m_n = &crtc->config->dp_m_n;
+ dp_m2_n2 = &crtc->config->dp_m2_n2;
+ } else if (m_n == M2_N2) {
+
+ /*
+* M2_N2 registers are not supported. Hence m2_n2 divider value
+* needs to be programmed into M1_N1.
+*/
+ dp_m_n = &crtc->config->dp_m2_n2;
+ } else {
+ DRM_ERROR("Unsupported divider value\n");
+ return;
+ }
+
if (crtc->config->has_pch_encoder)
intel_pch_transcoder_set_m_n(crtc, &crtc->config->dp_m_n);
else
- intel_cpu_transcoder_set_m_n(crtc, &crtc->config->dp_m_n,
- &crtc->config->dp_m2_n2);
+ intel_cpu_transcoder_set_m_n(crtc, dp_m_n, dp_m2_n2);
}
static void vlv_update_pll(struct intel_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 76b3c20..e05de19 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -593,6 +593,26 @@ struct intel_hdmi {
struct intel_dp_mst_encoder;
#define DP_MAX_DOWNSTREAM_PORTS0x10
+/*
+ * enum link_m_n_set:
+ * When platform provides two set of M_N registers for dp, we can
+ * program them and switch between them incase of DRRS.
+ * But When only one such register is provided, we have to program the
+ * required divider value on that registers itself based on the DRRS state.
+ *
+ * M1_N1 : Program dp_m_n on M1_N1 registers
+ * dp_m2_n2 on M2_N2 registers (If supported)
+ *
+ * M2_N2 : Program dp_m2_n2 on M1_N1 registers
+ * M2_N2 registers are not supported
+ */
+
+enum link_m_n_set {
+ /* Sets the m1_n1 and m2_n2 */
+ M1_N1 = 0,
+ M2_N2
+};
+
struct intel_dp {
uint32_t output_reg;
uint32_t aux_ch_ctl_reg;
@@ -994,7 +1014,7 @@ void hsw_enable_pc8(struct drm_i915_private *dev_priv);
void hsw_disable_pc8(struct drm_i915_private *dev_priv);
void intel_dp_get_m_n(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
-void intel_dp_set_m_n(struct intel_crtc
[Intel-gfx] [PATCH] drm/i915/bdw: Add support for DRRS to switch RR
From: Vandana Kannan
For Broadwell, there is one instance of Transcoder MN values per transcoder.
For dynamic switching between multiple refreshr rates, M/N values may be
reprogrammed on the fly. Link N programming triggers update of all data and
link M & N registers and the new M/N values will be used in the next frame
that is output.
V2: [By Ram]: intel_dp_set_m_n() is rewritten to accommodate
gen >= 8 [Rodrigo]
V3: Coding style correction [Ram]
V4: [By Ram] intel_dp_set_m_n modifications are moved into a
separate patch, retaining only DRRS related changes here [Rodrigo]
Signed-off-by: Vandana Kannan
Signed-off-by: Pradeep Bhat
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index eea9e36..d29d669 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4808,12 +4808,24 @@ static void intel_dp_set_drrs_state(struct drm_device
*dev, int refresh_rate)
return;
}
- if (INTEL_INFO(dev)->gen > 6 && INTEL_INFO(dev)->gen < 8) {
+ if (INTEL_INFO(dev)->gen >= 8) {
+ switch (index) {
+ case DRRS_HIGH_RR:
+ intel_dp_set_m_n(intel_crtc, M1_N1);
+ break;
+ case DRRS_LOW_RR:
+ intel_dp_set_m_n(intel_crtc, M2_N2);
+ break;
+ case DRRS_MAX_RR:
+ default:
+ DRM_ERROR("Unsupported refreshrate type\n");
+ }
+ } else if (INTEL_INFO(dev)->gen > 6) {
reg = PIPECONF(intel_crtc->config->cpu_transcoder);
val = I915_READ(reg);
+
if (index > DRRS_HIGH_RR) {
val |= PIPECONF_EDP_RR_MODE_SWITCH;
- intel_dp_set_m_n(intel_crtc);
} else {
val &= ~PIPECONF_EDP_RR_MODE_SWITCH;
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add debugfs entry for DRRS
From: Vandana Kannan
Adding a debugfs entry to determine if DRRS is supported or not
V2: [By Ram]: Following details about the active crtc will be filled
in seq-file of the debugfs
1. Encoder output type
2. DRRS Support on this CRTC
3. DRRS current state
4. Current Vrefresh
Format is as follows:
CRTC 1: Output: eDP, DRRS Supported: Yes (Seamless), DRRS_State: DRRS_HIGH_RR,
Vrefresh: 60
CRTC 2: Output: HDMI, DRRS Supported : No, VBT DRRS_type: Seamless
CRTC 1: Output: eDP, DRRS Supported: Yes (Seamless), DRRS_State: DRRS_LOW_RR,
Vrefresh: 40
CRTC 2: Output: HDMI, DRRS Supported : No, VBT DRRS_type: Seamless
V3: [By Ram]: Readability is improved.
Another error case is covered [Daniel]
V4: [By Ram]: Current status of the Idleness DRRS along with
the Front buffer bits are added to the debugfs. [Rodrigo]
Signed-off-by: Vandana Kannan
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_debugfs.c | 99 +++
1 file changed, 99 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9af17fb..a2f702a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2855,6 +2855,104 @@ static int i915_ddb_info(struct seq_file *m, void
*unused)
return 0;
}
+static void drrs_status_per_crtc(struct seq_file *m,
+ struct drm_device *dev, struct intel_crtc *intel_crtc)
+{
+ struct intel_encoder *intel_encoder;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct i915_drrs *drrs = &dev_priv->drrs;
+ int vrefresh = 0;
+
+ for_each_encoder_on_crtc(dev, &intel_crtc->base, intel_encoder) {
+ /* Encoder connected on this CRTC */
+ switch (intel_encoder->type) {
+ case INTEL_OUTPUT_EDP:
+ seq_puts(m, "Output: eDP, ");
+ break;
+ case INTEL_OUTPUT_DSI:
+ seq_puts(m, "Output: DSI, ");
+ break;
+ case INTEL_OUTPUT_HDMI:
+ seq_puts(m, "Output: HDMI, ");
+ break;
+ case INTEL_OUTPUT_DISPLAYPORT:
+ seq_puts(m, "Output: DP, ");
+ break;
+ default:
+ seq_printf(m, "Output: Others (id=%d), ",
+ intel_encoder->type);
+ }
+ }
+
+ if (intel_crtc->config->has_drrs) {
+ struct intel_panel *panel;
+
+ panel = &drrs->dp->attached_connector->panel;
+ /* DRRS Supported */
+ seq_puts(m, "DRRS Supported: Yes (Seamless), ");
+ seq_printf(m, "busy_frontbuffer_bits: 0x%X,\n\t",
+ drrs->busy_frontbuffer_bits);
+
+ if (drrs->busy_frontbuffer_bits) {
+ seq_puts(m, "Front buffer: busy, ");
+ seq_puts(m, "Idleness Timer: Suspended, ");
+ } else {
+ seq_puts(m, "Front buffer: Idle, ");
+ if (drrs->refresh_rate_type == DRRS_HIGH_RR)
+ seq_puts(m, "Idleness Timer: Ticking, ");
+ else
+ seq_puts(m, "Idleness Timer: Suspended, ");
+ }
+
+ if (drrs->refresh_rate_type == DRRS_HIGH_RR) {
+ seq_puts(m, "DRRS_State: DRRS_HIGH_RR, ");
+ vrefresh = panel->fixed_mode->vrefresh;
+ } else if (drrs->refresh_rate_type == DRRS_LOW_RR) {
+ seq_puts(m, "DRRS_State: DRRS_LOW_RR, ");
+ vrefresh = panel->downclock_mode->vrefresh;
+ } else {
+ seq_printf(m, "DRRS_State: Unknown(%d), ",
+ drrs->refresh_rate_type);
+ }
+ seq_printf(m, "Vrefresh: %d", vrefresh);
+
+ } else {
+ /* DRRS not supported. Print the VBT parameter*/
+ seq_puts(m, "DRRS Supported : No, ");
+ if (dev_priv->vbt.drrs_type == STATIC_DRRS_SUPPORT)
+ seq_puts(m, "VBT DRRS_type: Static");
+ else if (dev_priv->vbt.drrs_type == SEAMLESS_DRRS_SUPPORT)
+ seq_puts(m, "VBT DRRS_type: Seamless");
+ else if (dev_priv->vbt.drrs_type == DRRS_NOT_SUPPORTED)
+ seq_puts(m, "VBT DRRS_type: None");
+ else
+ seq_puts(m, "VBT DRRS_type: Unrecognized Value");
+ }
+ seq_puts(m, "\n");
+}
+
+static int i915_drrs_status(struct seq_file *m, void *unused)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_device *dev = node->minor->dev;
+ struct intel_crtc *intel_crtc;
+
Re: [Intel-gfx] [PATCH] drm/i915: Do not invalidate obj->pages under mempressure
On Wed, Feb 11, 2015 at 1:55 AM, Sean V Kelley wrote: > No corruption seen. I will add reloc domains to my growing audit list. One more for the libva audit list: If you do any ioctl directly, please make sure that you clear the ioctl structure with memset(&arg, 0, sizeof(arg)); or similar. Otherwise when we extended them in upstream (which we're just doing, the kernel 0-fills the new fields automatically) it'll break because after a recompile there's now garbage in the new fields. I just spent a while fixing up libdrm ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Add support for DRRS in intel_dp_set_m_n
Hi,
This is preparation patch for "[PATCH] drm/i915/bdw: Add support for
DRRS to switch RR".
My bad that I have misplaced this in the thread.
On Wednesday 11 February 2015 06:13 PM, Ramalingam C wrote:
Till Gen 7 we have two sets of M_N registers, but Gen 8 onwards
we have only one M_N register set. To support DRRS on both scenarios
a input parameter to intel_dp_set_m_n is added.
In case of DRRS, When platform provides two set of M_N registers for dp,
we can program them with two different dividers and switch between them.
But when only one such register set is provided, we have to program
the required divider M_N value on that registers itself.
Two enum members M1_N1 and M2_N2 are defined to represent the above
scenarios.
M1_N1: Program dp_m_n on M1_N1 registers
dp_m2_n2 on M2_N2 registers (If supported)
M2_N2: Program dp_m2_n2 on M1_N1 registers
M2_N2 registers are not supported
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_display.c | 30 +++---
drivers/gpu/drm/i915/intel_drv.h | 22 +-
2 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3fe9598..ced049a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4316,7 +4316,7 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
intel_prepare_shared_dpll(intel_crtc);
if (intel_crtc->config->has_dp_encoder)
- intel_dp_set_m_n(intel_crtc);
+ intel_dp_set_m_n(intel_crtc, M1_N1);
intel_set_pipe_timings(intel_crtc);
@@ -4424,7 +4424,7 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
intel_enable_shared_dpll(intel_crtc);
if (intel_crtc->config->has_dp_encoder)
- intel_dp_set_m_n(intel_crtc);
+ intel_dp_set_m_n(intel_crtc, M1_N1);
intel_set_pipe_timings(intel_crtc);
@@ -5038,7 +5038,7 @@ static void valleyview_crtc_enable(struct drm_crtc *crtc)
}
if (intel_crtc->config->has_dp_encoder)
- intel_dp_set_m_n(intel_crtc);
+ intel_dp_set_m_n(intel_crtc, M1_N1);
intel_set_pipe_timings(intel_crtc);
@@ -5114,7 +5114,7 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc)
i9xx_set_pll_dividers(intel_crtc);
if (intel_crtc->config->has_dp_encoder)
- intel_dp_set_m_n(intel_crtc);
+ intel_dp_set_m_n(intel_crtc, M1_N1);
intel_set_pipe_timings(intel_crtc);
@@ -5889,13 +5889,29 @@ static void intel_cpu_transcoder_set_m_n(struct intel_crtc *crtc,
}
}
-void intel_dp_set_m_n(struct intel_crtc *crtc)
+void intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n)
{
+ struct intel_link_m_n *dp_m_n, *dp_m2_n2 = NULL;
+
+ if (m_n == M1_N1) {
+ dp_m_n = &crtc->config->dp_m_n;
+ dp_m2_n2 = &crtc->config->dp_m2_n2;
+ } else if (m_n == M2_N2) {
+
+ /*
+* M2_N2 registers are not supported. Hence m2_n2 divider value
+* needs to be programmed into M1_N1.
+*/
+ dp_m_n = &crtc->config->dp_m2_n2;
+ } else {
+ DRM_ERROR("Unsupported divider value\n");
+ return;
+ }
+
if (crtc->config->has_pch_encoder)
intel_pch_transcoder_set_m_n(crtc, &crtc->config->dp_m_n);
else
- intel_cpu_transcoder_set_m_n(crtc, &crtc->config->dp_m_n,
- &crtc->config->dp_m2_n2);
+ intel_cpu_transcoder_set_m_n(crtc, dp_m_n, dp_m2_n2);
}
static void vlv_update_pll(struct intel_crtc *crtc,
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 76b3c20..e05de19 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -593,6 +593,26 @@ struct intel_hdmi {
struct intel_dp_mst_encoder;
#define DP_MAX_DOWNSTREAM_PORTS 0x10
+/*
+ * enum link_m_n_set:
+ * When platform provides two set of M_N registers for dp, we can
+ * program them and switch between them incase of DRRS.
+ * But When only one such register is provided, we have to program the
+ * required divider value on that registers itself based on the DRRS state.
+ *
+ * M1_N1 : Program dp_m_n on M1_N1 registers
+ * dp_m2_n2 on M2_N2 registers (If supported)
+ *
+ * M2_N2 : Program dp_m2_n2 on M1_N1 registers
+ * M2_N2 registers are not supported
+ */
+
+enum link_m_n_set {
+ /* Sets the m1_n1 and m2_n2 */
+ M1_N1 = 0,
+ M2_N2
+};
+
struct intel_dp {
uint32_t output_reg;
uint32_t aux_ch_ctl_reg;
@@ -994,7 +1014,7 @@ void hsw_enable_pc8(struct drm_i915_private *dev_priv);
void
Re: [Intel-gfx] [PATCH 3/4] drm: use drmIoctl everywhere
On 11 February 2015 at 11:42, Daniel Vetter wrote: > Well just core drm. All the other callers in there that still use > direct calls to ioctl have some custom retry logic already, so should > be good already. > Afaics intel/intel_bufmgr_gem.c has one instance, plus most of the tests. > freedreno/kgsl ahas all the other bare ioctl calls, dunnot what to do > about that. > s/ahas/has/ if you choose to keep this note. > Signed-off-by: Daniel Vetter Reviewed-by: Emil Velikov -Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] xf86drm: Unconditionally clear ioctl structs
On 11 February 2015 at 11:42, Daniel Vetter wrote:
> We really have to do this to avoid surprises when extending the ABI
> later on. Especially when growing the structures.
>
> A bit overkill to update all the old legacy ioctl wrappers, but can't
> hurt really either.
>
> Signed-off-by: Daniel Vetter
> ---
> xf86drm.c | 112
> ++
> 1 file changed, 77 insertions(+), 35 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 263d6835c29a..a2e24eb5f76c 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
[snip]
> @@ -2383,12 +2426,11 @@ int drmSetInterfaceVersion(int fd, drmSetVersion
> *version)
> */
> int drmCommandNone(int fd, unsigned long drmCommandIndex)
> {
> -void *data = NULL; /* dummy */
> unsigned long request;
>
> request = DRM_IO( DRM_COMMAND_BASE + drmCommandIndex);
>
> -if (drmIoctl(fd, request, data)) {
> +if (drmIoctl(fd, request, NULL)) {
> return -errno;
> }
> return 0;
> @@ -2543,12 +2585,12 @@ void drmCloseOnce(int fd)
>
> int drmSetMaster(int fd)
> {
> - return drmIoctl(fd, DRM_IOCTL_SET_MASTER, 0);
> + return drmIoctl(fd, DRM_IOCTL_SET_MASTER, NULL);
> }
>
> int drmDropMaster(int fd)
> {
> - return drmIoctl(fd, DRM_IOCTL_DROP_MASTER, 0);
> + return drmIoctl(fd, DRM_IOCTL_DROP_MASTER, NULL);
> }
>
These hunks are not strictly related, and maybe we can split it out.
Either way the series looks good.
Reviewed-by: Emil Velikov
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/10] drm/i915: Make intel_ring_setup_status_page() static
On Tue, Feb 10, 2015 at 07:32:17PM +, Damien Lespiau wrote:
> This function is only used in intel_ringbuffer.c, so restrict it to that
> file. The function was moved around to avoid a forward declaration and
> group it with its user.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 124
>
> drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
> 2 files changed, 62 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> b/drivers/gpu/drm/i915/intel_ringbuffer.c
> index 0631780..0a7b1af 100644
> --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> @@ -502,6 +502,68 @@ static void ring_setup_phys_status_page(struct
> intel_engine_cs *ring)
> I915_WRITE(HWS_PGA, addr);
> }
>
> +void intel_ring_setup_status_page(struct intel_engine_cs *ring)
> +{
I've actually manged to screw this one up. Daniel could you ammend this?
or do you want a new patch? (fengguang's 0day bot even generated a patch
for us).
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] tests/kms_addfb: Add support for fb modifiers
From: Tvrtko Ursulin
Just a few basic tests to make sure fb modifiers can be used and
behave sanely when mixed with the old set_tiling API.
v2:
* Review feedback from Daniel Vetter:
1. Move cap detection into the subtest so skipping works.
2. Added some gtkdoc comments.
3. Two more test cases.
4. Removed unused parts for now.
v3:
* Removed two tests which do not make sense any more after the
fb modifier rewrite.
v4:
* Moved gtkdoc comments into .c file.
* Moved all initialization into fixtures.
* Rebased for fb modifier changes.
Signed-off-by: Tvrtko Ursulin
---
lib/ioctl_wrappers.c | 23 +++
lib/ioctl_wrappers.h | 29 +++
tests/kms_addfb.c| 65
3 files changed, 117 insertions(+)
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 19a457a..47e9cbe 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1091,3 +1091,26 @@ int gem_context_has_param(int fd, uint64_t param)
return gem_context_get_param(fd, &p) == 0;
}
+
+/**
+ * igt_require_fb_modifiers:
+ * @fd: Open DRM file descriptor.
+ *
+ * Requires presence of DRM_CAP_ADDFB2_MODIFIERS.
+ */
+void igt_require_fb_modifiers(int fd)
+{
+ static bool has_modifiers, cap_modifiers_tested;
+
+ if (!cap_modifiers_tested) {
+ uint64_t cap_modifiers;
+ int ret;
+
+ ret = drmGetCap(fd, LOCAL_DRM_CAP_ADDFB2_MODIFIERS,
&cap_modifiers);
+ igt_assert(ret == 0 || errno == EINVAL);
+ has_modifiers = ret == 0 && cap_modifiers == 1;
+ cap_modifiers_tested = true;
+ }
+
+ igt_require(has_modifiers);
+}
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index 30ab836..eae19a3 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -117,4 +117,33 @@ int gem_context_has_param(int fd, uint64_t param);
int gem_context_get_param(int fd, struct local_i915_gem_context_param *p);
int gem_context_set_param(int fd, struct local_i915_gem_context_param *p);
+struct local_drm_mode_fb_cmd2 {
+ uint32_t fb_id;
+ uint32_t width, height;
+ uint32_t pixel_format;
+ uint32_t flags;
+ uint32_t handles[4];
+ uint32_t pitches[4];
+ uint32_t offsets[4];
+ uint64_t modifier[4];
+};
+
+#define LOCAL_DRM_MODE_FB_MODIFIERS(1<<1)
+
+#define LOCAL_DRM_FORMAT_MOD_VENDOR_INTEL 0x01
+
+#define local_fourcc_mod_code(vendor, val) \
+ uint64_t)LOCAL_DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | \
+ (val & 0x00ffL))
+
+#define LOCAL_DRM_FORMAT_MOD_NONE (0)
+#define LOCAL_I915_FORMAT_MOD_X_TILED local_fourcc_mod_code(INTEL, 1)
+
+#define LOCAL_DRM_IOCTL_MODE_ADDFB2DRM_IOWR(0xB8, \
+struct local_drm_mode_fb_cmd2)
+
+#define LOCAL_DRM_CAP_ADDFB2_MODIFIERS 0x10
+
+void igt_require_fb_modifiers(int fd);
+
#endif /* IOCTL_WRAPPERS_H */
diff --git a/tests/kms_addfb.c b/tests/kms_addfb.c
index 756589e..0a82619 100644
--- a/tests/kms_addfb.c
+++ b/tests/kms_addfb.c
@@ -213,6 +213,69 @@ static void size_tests(int fd)
}
}
+static void addfb25_tests(int fd)
+{
+ struct local_drm_mode_fb_cmd2 f = {};
+
+ igt_fixture {
+ gem_bo = gem_create(fd, 1024*1024*4);
+ igt_assert(gem_bo);
+
+ memset(&f, 0, sizeof(f));
+
+ f.width = 1024;
+ f.height = 1024;
+ f.pixel_format = DRM_FORMAT_XRGB;
+ f.pitches[0] = 1024*4;
+ f.modifier[0] = LOCAL_DRM_FORMAT_MOD_NONE;
+
+ f.handles[0] = gem_bo;
+ }
+
+ igt_subtest("addfb25-modifier-no-flag") {
+ igt_require_fb_modifiers(fd);
+
+ f.modifier[0] = LOCAL_I915_FORMAT_MOD_X_TILED;
+ igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f) < 0 &&
errno == EINVAL);
+ }
+
+ igt_fixture {
+ gem_set_tiling(fd, gem_bo, I915_TILING_X, 1024*4);
+ f.flags = LOCAL_DRM_MODE_FB_MODIFIERS;
+ }
+
+ igt_subtest("addfb25-X-tiled-mismatch") {
+ igt_require_fb_modifiers(fd);
+
+ f.modifier[0] = LOCAL_DRM_FORMAT_MOD_NONE;
+ igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f) < 0 &&
errno == EINVAL);
+ }
+
+ igt_subtest("addfb25-X-tiled") {
+ igt_require_fb_modifiers(fd);
+
+ f.modifier[0] = LOCAL_I915_FORMAT_MOD_X_TILED;
+ igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f) == 0);
+ igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_RMFB, &f.fb_id) == 0);
+ f.fb_id = 0;
+ }
+
+ igt_subtest("addfb25-framebuffer-vs-set-tiling") {
+ igt_require_fb_modifiers(fd);
+
+ f.modifier[0] = LOCAL_I915_FORMAT_MOD_X_TILED;
+ igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_M
Re: [Intel-gfx] [PATCH] drm/i915: Reject garbage in unsed ctx create/destroy fields
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5757 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -1 281/281 280/281 ILK 313/313 313/313 SNB -3 309/322 306/322 IVB -3 380/380 377/380 BYT -3 296/296 293/296 HSW -3 426/426 423/426 BDW -4 318/318 314/318 -Detailed- Platform Testdrm-intel-nightly Series Applied *PNV igt_gen3_render_mixed_blits PASS(2, M23) CRASH(1, M23) *SNB igt_gem_ctx_basic PASS(2, M22) NSPT(1, M22) *SNB igt_gem_ctx_create PASS(2, M22) NSPT(1, M22) *SNB igt_gem_ctx_exec_basic PASS(2, M22) FAIL(1, M22) *IVB igt_gem_ctx_basic PASS(2, M21) NSPT(1, M21) *IVB igt_gem_ctx_create PASS(2, M21) NSPT(1, M21) *IVB igt_gem_ctx_exec_basic PASS(2, M21) FAIL(1, M21) *BYT igt_gem_ctx_basic PASS(2, M50) NSPT(1, M50) *BYT igt_gem_ctx_create PASS(2, M50) NSPT(1, M50) *BYT igt_gem_ctx_exec_basic PASS(2, M50) FAIL(1, M50) *HSW igt_gem_ctx_basic PASS(2, M20) NSPT(1, M20) *HSW igt_gem_ctx_create PASS(2, M20) NSPT(1, M20) *HSW igt_gem_ctx_exec_basic PASS(2, M20) FAIL(1, M20) *BDW igt_gem_ctx_basic PASS(2, M30) NSPT(1, M30) *BDW igt_gem_ctx_create PASS(2, M30) NSPT(1, M30) *BDW igt_gem_ctx_exec_basic PASS(2, M30) FAIL(1, M30) *BDW igt_gem_gtt_hog PASS(2, M30) DMESG_WARN(1, M30) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: DP link training optimization
Reuse existing DP link training values i.e. voltage swing
and pre-emphasis levels, if DP port that we are connected
to hasn't changed. If we are unable to re-initialize DP
link, the fallback is to reset the link training values,
and restart.
modified: intel_dp.c
modified: intel_drv.h
---
drivers/gpu/drm/i915/intel_dp.c | 75 +++-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
2 files changed, 69 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 868a07b..c40d64a 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3286,6 +3286,25 @@ intel_dp_reset_link_train(struct intel_dp *intel_dp,
uint32_t *DP,
}
static bool
+intel_dp_reuse_link_train(struct intel_dp *intel_dp, uint32_t *DP,
+ uint8_t dp_train_pat)
+{
+ struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
+ intel_dp_set_signal_levels(intel_dp, DP);
+
+ I915_WRITE(intel_dp->output_reg, *DP);
+ POSTING_READ(intel_dp->output_reg);
+
+ drm_dp_dpcd_write(&intel_dp->aux, DP_TRAINING_LANE0_SET,
+ intel_dp->train_set, intel_dp->lane_count);
+
+ return intel_dp_set_link_train(intel_dp, DP, dp_train_pat);
+}
+
+static bool
intel_dp_update_link_train(struct intel_dp *intel_dp, uint32_t *DP,
const uint8_t link_status[DP_LINK_STATUS_SIZE])
{
@@ -3348,6 +3367,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
int voltage_tries, loop_tries;
uint32_t DP = intel_dp->DP;
uint8_t link_config[2];
+ uint8_t link_status[DP_LINK_STATUS_SIZE];
+ bool reuse_train_set = false;
if (HAS_DDI(dev))
intel_ddi_prepare_link_retrain(encoder);
@@ -3365,20 +3386,36 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
DP |= DP_PORT_EN;
- /* clock recovery */
- if (!intel_dp_reset_link_train(intel_dp, &DP,
- DP_TRAINING_PATTERN_1 |
- DP_LINK_SCRAMBLING_DISABLE)) {
- DRM_ERROR("failed to enable link training\n");
- return;
+ /*
+* check if DP connector has changed. Reset voltage swing and
+* pre-emphasis levels if that's the case.
+*/
+ if (intel_dp->connector_changed) {
+ /* reset link training values */
+ DRM_DEBUG_KMS("resetting link train set\n");
+ if (!intel_dp_reset_link_train(intel_dp, &DP,
+ DP_TRAINING_PATTERN_1 |
+ DP_LINK_SCRAMBLING_DISABLE)) {
+ DRM_ERROR("failed to enable link training\n");
+ return;
+ }
+ reuse_train_set = false;
+ }
+ else {
+ DRM_DEBUG_KMS("reusing current link train set\n");
+ if (!intel_dp_reuse_link_train(intel_dp, &DP,
+ DP_TRAINING_PATTERN_1 |
+ DP_LINK_SCRAMBLING_DISABLE)) {
+ DRM_DEBUG_KMS("unable to set known link training
values\n");
+ return;
+ }
+ reuse_train_set = true;
}
voltage = 0xff;
voltage_tries = 0;
loop_tries = 0;
for (;;) {
- uint8_t link_status[DP_LINK_STATUS_SIZE];
-
drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
if (!intel_dp_get_link_status(intel_dp, link_status)) {
DRM_ERROR("failed to get link status\n");
@@ -3389,6 +3426,20 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
DRM_DEBUG_KMS("clock recovery OK\n");
break;
}
+ /*
+* if we used previously trained voltage and pre-emphasis values
+* and we don't get clock recovery, reset link training values
+*/
+ if (reuse_train_set) {
+ DRM_DEBUG_KMS("clock recovery not ok, resetting DP
train set\n");
+ if (!intel_dp_reset_link_train(intel_dp, &DP,
+ DP_TRAINING_PATTERN_1 |
+
DP_LINK_SCRAMBLING_DISABLE)) {
+ DRM_ERROR("failed to enable link training\n");
+ return;
+ }
+ reuse_train_set = false;
+ }
/* Check to see if we've tried the max voltage */
for (i = 0; i < intel_dp->lane_count; i++)
@
Re: [Intel-gfx] [PATCH 3/4] drm: use drmIoctl everywhere
On Wed, Feb 11, 2015 at 01:13:26PM +, Emil Velikov wrote: > On 11 February 2015 at 11:42, Daniel Vetter wrote: > > Well just core drm. All the other callers in there that still use > > direct calls to ioctl have some custom retry logic already, so should > > be good already. > > > Afaics intel/intel_bufmgr_gem.c has one instance, plus most of the tests. That one is in set_tiling and because of a very peculiar retry semantics of that specific ioctl. Don't ask ;-) > > > freedreno/kgsl ahas all the other bare ioctl calls, dunnot what to do > > about that. > > > s/ahas/has/ if you choose to keep this note. Already reworded since kgsl is the blob library and so not a drm thing. Thanks for your review. -Daniel > > > Signed-off-by: Daniel Vetter > Reviewed-by: Emil Velikov > > -Emil -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/18] drm/i915: Support not having an init clock gating function defined
On 09/02/2015 19:33, Damien Lespiau wrote:
When enabling new platforms, we may not have any W/A to apply,
especially that, now, a bunch of them have to be done from the ring.
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_pm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 3c64810..a3b979d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6386,7 +6386,8 @@ void intel_init_clock_gating(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- dev_priv->display.init_clock_gating(dev);
+ if (dev_priv->display.init_clock_gating)
+ dev_priv->display.init_clock_gating(dev);
}
void intel_suspend_hw(struct drm_device *dev)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Hibernation test
intel-gpu-tools currently has a bunch of tests for suspend,
but currently none (that I could find) for hibernate.
Attached is a rudimentary patch to add said test. It does so
by repurposing the drv_suspend driver to handle both suspend
and hibernate, since the difference is miniscule.
I decided to split the suspend/autoresume functions in
igt_aux.c though, to be able to leave the igt_system_uspend_autoresume()
function unchanged (the other option would be to
introduce a boolean function argument and have that
decide what parameters to pass to rtcwake).
The timeout passed to rtcwake probably needs tuning (it might
even need to be dynamically adjusted, since the time hibernation takes
varies wildly depending on the amount of non-cache memory in use).
Kind regards, David Weinehall
PS: Go easy on me, mkay -- first patch to intel-gfx :P (meh, who am I
kidding,
I should be flame tolerant enough, bring it on).
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index aefa0863e9e9..c39ccd86db63 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -1,5 +1,5 @@
/*
- * Copyright © 2007, 2011, 2013, 2014 Intel Corporation
+ * Copyright © 2007, 2011, 2013, 2014, 2015 Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -411,7 +411,7 @@ void igt_cleanup_aperture_trashers(void)
* igt_system_suspend_autoresume:
*
* Execute a system suspend-to-mem cycle and automatically wake up again using
- * the firmwares resume timer.
+ * the firmware's resume timer.
*
* This is very handy for implementing any kind of suspend/resume test.
*/
@@ -430,6 +430,34 @@ void igt_system_suspend_autoresume(void)
}
/**
+ * igt_system_hibernate_autoresume:
+ *
+ * Execute a system suspend-to-disk cycle and automatically wake up again using
+ * the firmware's resume timer.
+ *
+ * This is very handy for implementing any kind of hibernate/resume test.
+ */
+void igt_system_hibernate_autoresume(void)
+{
+ int ret;
+
+ /* FIXME: I'm guessing simulation behaves the same way as with
+ * suspend/resume, but it might be prudent to make sure
+ */
+ /* FIXME: Simulation doesn't like suspend/resume, and not even a lighter
+ * approach using /sys/power/pm_test to just test our driver's callbacks
+ * seems to fare better. We need to investigate what's going on. */
+ igt_skip_on_simulation();
+
+ /* The timeout might need to be adjusted if hibernation takes too long
+ * or if we have to wait excessively long before resume
+ */
+ ret = system("rtcwake -s 90 -m disk");
+ igt_assert_f(ret == 0, "This failure means that something is wrong with the rtcwake tool "
+ "or how your distro is set up. This is not a i915.ko or i-g-t bug.");
+}
+
+/**
* igt_drop_root:
*
* Drop root privileges and make sure it actually worked. Useful for tests
diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index 798a5b45fcb9..636ab3dc06fc 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -1,5 +1,5 @@
/*
- * Copyright © 2014 Intel Corporation
+ * Copyright © 2014, 2015 Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -58,8 +58,9 @@ void igt_init_aperture_trashers(drm_intel_bufmgr *bufmgr);
void igt_trash_aperture(void);
void igt_cleanup_aperture_trashers(void);
-/* suspend and auto-resume system */
+/* suspend/hibernate and auto-resume system */
void igt_system_suspend_autoresume(void);
+void igt_system_hibernate_autoresume(void);
/* dropping priviledges */
void igt_drop_root(void);
diff --git a/tests/drv_suspend.c b/tests/drv_suspend.c
index 80f6a2254b75..8165cef9b333 100644
--- a/tests/drv_suspend.c
+++ b/tests/drv_suspend.c
@@ -1,5 +1,5 @@
/*
- * Copyright © 2013 Intel Corporation
+ * Copyright © 2013, 2015 Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
@@ -22,6 +22,7 @@
*
* Authors:
*Daniel Vetter
+ *David Weinehall
*
*/
@@ -45,7 +46,7 @@
#define OBJECT_SIZE (16*1024*1024)
static void
-test_fence_restore(int fd, bool tiled2untiled)
+test_fence_restore(int fd, bool tiled2untiled, bool hibernate)
{
uint32_t handle1, handle2, handle_tiled;
uint32_t *ptr1, *ptr2, *ptr_tiled;
@@ -80,7 +81,10 @@ test_fence_restore(int fd, bool tiled2untiled)
else
gem_set_tiling(fd, handle_tiled, I915_TI
Re: [Intel-gfx] [PATCH 02/18] drm/i915/skl: Implement WaDisableHBR2
On 09/02/2015 19:33, Damien Lespiau wrote: Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/intel_dp.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index d4c82d7..4a60c6a 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -129,7 +129,10 @@ intel_dp_max_link_bw(struct intel_dp *intel_dp) case DP_LINK_BW_2_7: break; case DP_LINK_BW_5_4: /* 1.2 capable displays may advertise higher bw */ - if (((IS_HASWELL(dev) && !IS_HSW_ULX(dev)) || + if (IS_SKYLAKE(dev) && dev->pdev->revision <= 0x1) Should be: if (IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_B0) ? + /* WaDisableHBR2:skl */ + max_link_bw = DP_LINK_BW_2_7; + else if (((IS_HASWELL(dev) && !IS_HSW_ULX(dev)) || INTEL_INFO(dev)->gen >= 8) && intel_dp->dpcd[DP_DPCD_REV] >= 0x12) max_link_bw = DP_LINK_BW_5_4; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Add process identifier to requests
We use the pid of the process which opened our device when
we track which was the culprit of the gpu hang. But as that
file descriptor might get inherited, we might blame the
wrong process when we record the error state.
Track process identifiers in requests to always find
the correct offender.
Cc: Kenneth Graunke
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
drivers/gpu/drm/i915/i915_gem.c | 3 +++
drivers/gpu/drm/i915/i915_gpu_error.c | 5 ++---
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c0b8644..9093654 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2153,6 +2153,9 @@ struct drm_i915_gem_request {
/** file_priv list entry for this request */
struct list_head client_list;
+ /** process identifier submitting this request */
+ struct pid *pid;
+
uint32_t uniq;
/**
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index c26d36c..47affaf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2483,6 +2483,7 @@ int __i915_add_request(struct intel_engine_cs *ring,
request->emitted_jiffies = jiffies;
list_add_tail(&request->list, &ring->request_list);
request->file_priv = NULL;
+ request->pid = get_pid(task_pid(current));
if (file) {
struct drm_i915_file_private *file_priv = file->driver_priv;
@@ -2572,6 +2573,8 @@ static void i915_gem_free_request(struct
drm_i915_gem_request *request)
list_del(&request->list);
i915_gem_request_remove_from_client(request);
+ put_pid(request->pid);
+
i915_gem_request_unreference(request);
}
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 48ddbf4..a982849 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -994,12 +994,11 @@ static void i915_gem_record_rings(struct drm_device *dev,
i915_error_ggtt_object_create(dev_priv,
ring->scratch.obj);
- if (request->file_priv) {
+ if (request->pid) {
struct task_struct *task;
rcu_read_lock();
- task = pid_task(request->file_priv->file->pid,
- PIDTYPE_PID);
+ task = pid_task(request->pid, PIDTYPE_PID);
if (task) {
strcpy(error->ring[i].comm, task->comm);
error->ring[i].pid = task->pid;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/18] drm/i915/skl: Document the WM read latency W/A with its name
On 09/02/2015 19:33, Damien Lespiau wrote: Signed-off-by: Damien Lespiau Reviewed-by: Nick Hoath --- drivers/gpu/drm/i915/intel_pm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index a3b979d..6fd6f26 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -1701,6 +1701,8 @@ static void intel_read_wm_latency(struct drm_device *dev, uint16_t wm[8]) GEN9_MEM_LATENCY_LEVEL_MASK; /* +* WaWmMemoryReadLatency:skl +* * punit doesn't take into account the read latency so we need * to add 2us to the various latency levels we retrieve from * the punit. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: DP link training optimization
On Wed, 11 Feb 2015, Mika Kahola wrote:
> Reuse existing DP link training values i.e. voltage swing
> and pre-emphasis levels, if DP port that we are connected
> to hasn't changed. If we are unable to re-initialize DP
> link, the fallback is to reset the link training values,
> and restart.
Sorry, I failed to remind you to sign your work:
Signed-off-by: Mika Kahola
see Documentation/SubmittingPatches for details.
BR,
Jani.
> modified: intel_dp.c
> modified: intel_drv.h
> ---
> drivers/gpu/drm/i915/intel_dp.c | 75
> +++-
> drivers/gpu/drm/i915/intel_drv.h | 2 ++
> 2 files changed, 69 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 868a07b..c40d64a 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3286,6 +3286,25 @@ intel_dp_reset_link_train(struct intel_dp *intel_dp,
> uint32_t *DP,
> }
>
> static bool
> +intel_dp_reuse_link_train(struct intel_dp *intel_dp, uint32_t *DP,
> + uint8_t dp_train_pat)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = intel_dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> +
> + intel_dp_set_signal_levels(intel_dp, DP);
> +
> + I915_WRITE(intel_dp->output_reg, *DP);
> + POSTING_READ(intel_dp->output_reg);
> +
> + drm_dp_dpcd_write(&intel_dp->aux, DP_TRAINING_LANE0_SET,
> + intel_dp->train_set, intel_dp->lane_count);
> +
> + return intel_dp_set_link_train(intel_dp, DP, dp_train_pat);
> +}
> +
> +static bool
> intel_dp_update_link_train(struct intel_dp *intel_dp, uint32_t *DP,
> const uint8_t link_status[DP_LINK_STATUS_SIZE])
> {
> @@ -3348,6 +3367,8 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> int voltage_tries, loop_tries;
> uint32_t DP = intel_dp->DP;
> uint8_t link_config[2];
> + uint8_t link_status[DP_LINK_STATUS_SIZE];
> + bool reuse_train_set = false;
>
> if (HAS_DDI(dev))
> intel_ddi_prepare_link_retrain(encoder);
> @@ -3365,20 +3386,36 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
>
> DP |= DP_PORT_EN;
>
> - /* clock recovery */
> - if (!intel_dp_reset_link_train(intel_dp, &DP,
> -DP_TRAINING_PATTERN_1 |
> -DP_LINK_SCRAMBLING_DISABLE)) {
> - DRM_ERROR("failed to enable link training\n");
> - return;
> + /*
> + * check if DP connector has changed. Reset voltage swing and
> + * pre-emphasis levels if that's the case.
> + */
> + if (intel_dp->connector_changed) {
> + /* reset link training values */
> + DRM_DEBUG_KMS("resetting link train set\n");
> + if (!intel_dp_reset_link_train(intel_dp, &DP,
> +DP_TRAINING_PATTERN_1 |
> +DP_LINK_SCRAMBLING_DISABLE)) {
> + DRM_ERROR("failed to enable link training\n");
> + return;
> + }
> + reuse_train_set = false;
> + }
> + else {
> + DRM_DEBUG_KMS("reusing current link train set\n");
> + if (!intel_dp_reuse_link_train(intel_dp, &DP,
> +DP_TRAINING_PATTERN_1 |
> +DP_LINK_SCRAMBLING_DISABLE)) {
> + DRM_DEBUG_KMS("unable to set known link training
> values\n");
> + return;
> + }
> + reuse_train_set = true;
> }
>
> voltage = 0xff;
> voltage_tries = 0;
> loop_tries = 0;
> for (;;) {
> - uint8_t link_status[DP_LINK_STATUS_SIZE];
> -
> drm_dp_link_train_clock_recovery_delay(intel_dp->dpcd);
> if (!intel_dp_get_link_status(intel_dp, link_status)) {
> DRM_ERROR("failed to get link status\n");
> @@ -3389,6 +3426,20 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> DRM_DEBUG_KMS("clock recovery OK\n");
> break;
> }
> + /*
> + * if we used previously trained voltage and pre-emphasis values
> + * and we don't get clock recovery, reset link training values
> + */
> + if (reuse_train_set) {
> + DRM_DEBUG_KMS("clock recovery not ok, resetting DP
> train set\n");
> + if (!intel_dp_reset_link_train(intel_dp, &DP,
> +DP_TRAINING_PATTERN_1 |
> +
> DP_LINK_SCRAMBLING_DISABLE)) {
> + DRM_ERROR("failed to enable link training
Re: [Intel-gfx] [PATCH 05/18] drm/i915/skl: Make the init clock gating function skylake specific
On 09/02/2015 19:33, Damien Lespiau wrote:
We'll gather cross-gen9 W/A in a separate function later.
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 6fd6f26..03e27c2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -52,7 +52,7 @@
#define INTEL_RC6p_ENABLE (1<<1)
#define INTEL_RC6pp_ENABLE(1<<2)
-static void gen9_init_clock_gating(struct drm_device *dev)
+static void skl_init_clock_gating(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -6415,7 +6415,7 @@ void intel_init_pm(struct drm_device *dev)
if (INTEL_INFO(dev)->gen >= 9) {
skl_setup_wm_latency(dev);
- dev_priv->display.init_clock_gating = gen9_init_clock_gating;
+ dev_priv->display.init_clock_gating = skl_init_clock_gating;
dev_priv->display.update_wm = skl_update_wm;
dev_priv->display.update_sprite_wm = skl_update_sprite_wm;
} else if (HAS_PCH_SPLIT(dev)) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/18] drm/i915/skl: Implement WaSetGAPSunitClckGateDisable
On 09/02/2015 19:33, Damien Lespiau wrote:
Let's also take the opportunity the remove the comment telling it's a
pre-prod W/A, it should be obvious from the stepping test.
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4ee1964..578fd90 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6016,6 +6016,7 @@ enum skl_disp_power_wells {
#define GEN6_RSTCTL 0x9420
#define GEN8_UCGCTL6 0x9430
+#define GEN8_GAPSUNIT_CLOCK_GATE_DISABLE (1<<24)
#define GEN8_SDEUNIT_CLOCK_GATE_DISABLE (1<<14)
#define GEN6_GFXPAUSE 0xA000
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 03e27c2..2c66423 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -59,9 +59,10 @@ static void skl_init_clock_gating(struct drm_device *dev)
if (INTEL_REVID(dev) == SKL_REVID_A0) {
/*
* WaDisableSDEUnitClockGating:skl
-* This seems to be a pre-production w/a.
+* WaSetGAPSunitClckGateDisable:skl
*/
I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
+ GEN8_GAPSUNIT_CLOCK_GATE_DISABLE |
GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
}
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Align initial plane backing objects correctly
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5754 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -4 275/275 271/275 ILK -1 310/310 309/310 SNB +2 320/346 322/346 IVB -2 380/384 378/384 BYT 296/296 296/296 HSW +3-1 422/428 424/428 BDW 318/333 318/333 -Detailed- Platform Testdrm-intel-nightly Series Applied *PNV igt_gem_fence_thrash_bo-write-verify-none PASS(5, M7) FAIL(1, M7) *PNV igt_gem_fence_thrash_bo-write-verify-x PASS(5, M7) FAIL(1, M7) *PNV igt_gem_fence_thrash_bo-write-verify-y PASS(6, M7) FAIL(1, M7) *PNV igt_gem_fence_thrash_bo-write-verify-threaded-none PASS(2, M7) CRASH(1, M7) ILK igt_drv_suspend_fence-restore-tiled2untiled DMESG_WARN(2, M26)PASS(1, M26) DMESG_WARN(1, M26) *SNB igt_kms_flip_bo-too-big BLACKLIST(1, M35) PASS(1, M35) *SNB igt_kms_flip_bo-too-big-interruptible BLACKLIST(1, M35) PASS(1, M35) *IVB igt_kms_cursor_crc_cursor-64x64-random PASS(2, M4) NO_RESULT(1, M4) *IVB igt_gem_partial_pwrite_pread_reads-snoop PASS(2, M4) NO_RESULT(1, M4) *HSW igt_gem_fenced_exec_thrash_no-spare-fences-busy-interruptible PASS(2, M40) NO_RESULT(1, M40) *HSW igt_kms_flip_bo-too-big BLACKLIST(1, M40) PASS(1, M40) *HSW igt_kms_flip_bo-too-big-interruptible BLACKLIST(1, M40) PASS(1, M40) HSW igt_kms_flip_plain-flip-fb-recreate-interruptible TIMEOUT(6, M40)PASS(5, M40) PASS(1, M40) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915: Implement chv display PHY lane stagger setup
From: Ville Syrjälä
Set up the chv display PHY lane stagger registers according to
"Programming Guide for 1273 CHV eDP/DP/HDMI Display PHY" v1.04
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 13 +
drivers/gpu/drm/i915/intel_dp.c | 35 +--
drivers/gpu/drm/i915/intel_hdmi.c | 35 +--
3 files changed, 79 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2196e57..4728dc2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -933,6 +933,7 @@ enum skl_disp_power_wells {
#define _VLV_PCS_DW11_CH0 0x822c
#define _VLV_PCS_DW11_CH1 0x842c
+#define DPIO_TX2_STAGGER_MASK(x) ((x)<<24)
#define DPIO_LANEDESKEW_STRAP_OVRD (1<<3)
#define DPIO_LEFT_TXFIFO_RST_MASTER (1<<1)
#define DPIO_RIGHT_TXFIFO_RST_MASTER (1<<0)
@@ -945,8 +946,20 @@ enum skl_disp_power_wells {
#define VLV_PCS01_DW11(ch) _PORT(ch, _VLV_PCS01_DW11_CH0, _VLV_PCS01_DW11_CH1)
#define VLV_PCS23_DW11(ch) _PORT(ch, _VLV_PCS23_DW11_CH0, _VLV_PCS23_DW11_CH1)
+#define _VLV_PCS01_DW12_CH00x0230
+#define _VLV_PCS23_DW12_CH00x0430
+#define _VLV_PCS01_DW12_CH10x2630
+#define _VLV_PCS23_DW12_CH10x2830
+#define VLV_PCS01_DW12(ch) _PORT(ch, _VLV_PCS01_DW12_CH0, _VLV_PCS01_DW12_CH1)
+#define VLV_PCS23_DW12(ch) _PORT(ch, _VLV_PCS23_DW12_CH0, _VLV_PCS23_DW12_CH1)
+
#define _VLV_PCS_DW12_CH0 0x8230
#define _VLV_PCS_DW12_CH1 0x8430
+#define DPIO_TX2_STAGGER_MULT(x) ((x)<<20)
+#define DPIO_TX1_STAGGER_MULT(x) ((x)<<16)
+#define DPIO_TX1_STAGGER_MASK(x) ((x)<<8)
+#define DPIO_LANESTAGGER_STRAP_OVRD (1<<6)
+#define DPIO_LANESTAGGER_STRAP(x)((x)<<0)
#define VLV_PCS_DW12(ch) _PORT(ch, _VLV_PCS_DW12_CH0, _VLV_PCS_DW12_CH1)
#define _VLV_PCS_DW14_CH0 0x8238
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index eea9e36..43129ed 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2524,7 +2524,7 @@ static void chv_pre_enable_dp(struct intel_encoder
*encoder)
to_intel_crtc(encoder->base.crtc);
enum dpio_channel ch = vlv_dport_to_channel(dport);
int pipe = intel_crtc->pipe;
- int data, i;
+ int data, i, stagger;
u32 val;
mutex_lock(&dev_priv->dpio_lock);
@@ -2569,7 +2569,38 @@ static void chv_pre_enable_dp(struct intel_encoder
*encoder)
}
/* Data lane stagger programming */
- /* FIXME: Fix up value only after power analysis */
+ if (intel_crtc->config->port_clock > 27)
+ stagger = 0x18;
+ else if (intel_crtc->config->port_clock > 135000)
+ stagger = 0xd;
+ else if (intel_crtc->config->port_clock > 67500)
+ stagger = 0x7;
+ else if (intel_crtc->config->port_clock > 33750)
+ stagger = 0x4;
+ else
+ stagger = 0x2;
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW11(ch));
+ val |= DPIO_TX2_STAGGER_MASK(0x1f);
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW11(ch), val);
+
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW11(ch));
+ val |= DPIO_TX2_STAGGER_MASK(0x1f);
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW11(ch), val);
+
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW12(ch),
+ DPIO_LANESTAGGER_STRAP(stagger) |
+ DPIO_LANESTAGGER_STRAP_OVRD |
+ DPIO_TX1_STAGGER_MASK(0x1f) |
+ DPIO_TX1_STAGGER_MULT(6) |
+ DPIO_TX2_STAGGER_MULT(0));
+
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW12(ch),
+ DPIO_LANESTAGGER_STRAP(stagger) |
+ DPIO_LANESTAGGER_STRAP_OVRD |
+ DPIO_TX1_STAGGER_MASK(0x1f) |
+ DPIO_TX1_STAGGER_MULT(7) |
+ DPIO_TX2_STAGGER_MULT(5));
mutex_unlock(&dev_priv->dpio_lock);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 995c5b2..94da7fe 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1471,7 +1471,7 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder)
&intel_crtc->config->base.adjusted_mode;
enum dpio_channel ch = vlv_dport_to_channel(dport);
int pipe = intel_crtc->pipe;
- int data, i;
+ int data, i, stagger;
u32 val;
mutex_lock(&dev_priv->dpio_lock);
@@ -1516,7 +1516,38 @@ static void chv_hdmi_pre_enable(struct intel_encoder
*encoder)
}
/* Data lane stagger programming */
- /* FIXME: Fix up value only after power analysis */
+ if (intel_crtc->config->port_clock > 27)
+ stagger = 0x18;
+ e
[Intel-gfx] [PATCH 2/4] drm/i915: Add a hack to fix link training errors on pipe A+port B on CHV
From: Ville Syrjälä
For some reason link training fails when port B is being driven by pipe
A, and was previously driven by port B or the common lane was previously
powered off.
After staring at some register dumps I noticed some oddness with the DCC
calibration status bits, and after some experimentation I came up with a
workaround that just involves toggling the DCC calibration bit for the
data lanes in chv_pre_enable_dp(). I also observed that doing the same
trick for pipe B resulted in a blinking display with pipe B + eDP port C.
So the I've limited the workaround to pipe A only for now, while not
caring which port is used.
Whether there are more factors in this mess is unclear. But for now
this seems to work at least on my BSW RVP.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 8
drivers/gpu/drm/i915/intel_dp.c | 23 +++
2 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 4728dc2..7546350 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -966,6 +966,14 @@ enum skl_disp_power_wells {
#define _VLV_PCS_DW14_CH1 0x8438
#defineVLV_PCS_DW14(ch) _PORT(ch, _VLV_PCS_DW14_CH0, _VLV_PCS_DW14_CH1)
+#define _VLV_PCS_DW17_CH0 0x8244
+#define _VLV_PCS_DW17_CH1 0x8444
+#define DPIO_TX2_DCC_CALIB_DONE (1 << 3)
+#define DPIO_TX1_DCC_CALIB_DONE (1 << 2)
+#define DPIO_TX2_DCC_CALIB_ENABLE (1 << 1)
+#define DPIO_TX1_DCC_CALIB_ENABLE (1 << 0)
+#define VLV_PCS_DW17(ch) _PORT(ch, _VLV_PCS_DW17_CH0, _VLV_PCS_DW17_CH1)
+
#define _VLV_PCS_DW23_CH0 0x825c
#define _VLV_PCS_DW23_CH1 0x845c
#define VLV_PCS_DW23(ch) _PORT(ch, _VLV_PCS_DW23_CH0, _VLV_PCS_DW23_CH1)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 43129ed..2e3fb17 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2602,6 +2602,29 @@ static void chv_pre_enable_dp(struct intel_encoder
*encoder)
DPIO_TX1_STAGGER_MULT(7) |
DPIO_TX2_STAGGER_MULT(5));
+ /*
+* FIXME: After port B has been driven by pipe B, or
+* the common lane well has been powered down, trying to drive
+* port B with pipe A results in a link training failure. Somehow
+* toggling the DCC calibrate force bits before enabling the port
+* fixes the problem. Neither pipe B or port C seem to suffer from
+* this problem, however doing the toggle on pipe B seems to cause
+* eDP port C to blink when driven by pipe B. So we only do the
+* toggle for pipe A. It's untested whether pipe C + port D might
+* also need something like this due to lack of a suitale board.
+*
+* Not sure if this is just a symptom of some problem with the PHY
+* programming we do, but this seems to be a solid workaround so far.
+*
+* All of this was tested on a BSW RVP with DP on port B,
+* eDP on port C, and HDMI on port D.
+*/
+ if (pipe == PIPE_A) {
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW17(ch),
+ DPIO_TX1_DCC_CALIB_ENABLE |
DPIO_TX2_DCC_CALIB_ENABLE);
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW17(ch), 0);
+ }
+
mutex_unlock(&dev_priv->dpio_lock);
intel_enable_dp(encoder);
--
2.0.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] drm/i915: CHV display PHY magic
From: Ville Syrjälä Here's the second part of my CHV display fixes pile. There are some really weird things going on with the PHY, and this series includes whatever workaround I managed to invent to overcome those issues. The lane stagger setup I just gleaned from one of the docs, although I'm not sure the magic numbers are even correct anymore. So not sure if it helps with anything really. And the cmnlane glue revert is just to save a bit more power when only one PHY is needed. Ville Syrjälä (4): drm/i915: Implement chv display PHY lane stagger setup drm/i915: Add a hack to fix link training errors on pipe A+port B on CHV Revert "drm/i915: Hack to tie both common lanes together on chv" drm/i915: Work around DISPLAY_PHY_CONTROL register corruption on CHV drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/i915_reg.h | 26 ++- drivers/gpu/drm/i915/intel_dp.c | 58 +++-- drivers/gpu/drm/i915/intel_hdmi.c | 35 ++-- drivers/gpu/drm/i915/intel_runtime_pm.c | 38 - 5 files changed, 138 insertions(+), 21 deletions(-) -- 2.0.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] Revert "drm/i915: Hack to tie both common lanes together on chv"
From: Ville Syrjälä
With recent hardware/firmware there don't appear to be any glitches
on the other PHY when we toggle the cmnreset for the other PHY. So
detangle the cmnlane power wells from one another and let them be
controlled independently.
This reverts commit 3dd7b97458e8aa2d8985b46622d226fa635071e7.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 6d8e29a..02b6b8f 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1145,23 +1145,13 @@ static struct i915_power_well chv_power_wells[] = {
#endif
{
.name = "dpio-common-bc",
- /*
-* XXX: cmnreset for one PHY seems to disturb the other.
-* As a workaround keep both powered on at the same
-* time for now.
-*/
- .domains = CHV_DPIO_CMN_BC_POWER_DOMAINS |
CHV_DPIO_CMN_D_POWER_DOMAINS,
+ .domains = CHV_DPIO_CMN_BC_POWER_DOMAINS,
.data = PUNIT_POWER_WELL_DPIO_CMN_BC,
.ops = &chv_dpio_cmn_power_well_ops,
},
{
.name = "dpio-common-d",
- /*
-* XXX: cmnreset for one PHY seems to disturb the other.
-* As a workaround keep both powered on at the same
-* time for now.
-*/
- .domains = CHV_DPIO_CMN_BC_POWER_DOMAINS |
CHV_DPIO_CMN_D_POWER_DOMAINS,
+ .domains = CHV_DPIO_CMN_D_POWER_DOMAINS,
.data = PUNIT_POWER_WELL_DPIO_CMN_D,
.ops = &chv_dpio_cmn_power_well_ops,
},
--
2.0.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Work around DISPLAY_PHY_CONTROL register corruption on CHV
From: Ville Syrjälä
Sometimes (exactly when is a bit unclear) DISPLAY_PHY_CONTROL appears to
get corrupted. The values I've managed to read from it seem to have some
pattern but vary quite a lot. The corruption doesn't seem to just happen
when the register is accessed, but can also happen spontaneosly during
modeset. When this happens during a modeset things go south and the
display doesn't light up.
I've managed to hit the problemn when toggling HDMI on port D on and
off. When things get corrupted the display doesn't light up, but as soon
as I manually write the correct value to the register the display comes
up.
First I was suspicious that we ourselves accidentally overwrite it with
garbage, but didn't catch anything with the reg_rw tracepoint. Also I
sprinkled check all over the modeset path to see exactly when the
corruption happens, and eg. the read back value was fine just before
intel_dp_set_m(), and corrupted immediately after it. I also made my
check function repair the register value whenever it was wrong, and with
this approach the corruption repeated several times during the modeset
operation, always seeming to trigger in the same exact calls to the
check function, while other calls to the function never caught anything.
So far I've not seen this problem occurring when carefully avoiding all
read accesses to DISPLAY_PHY_CONTROL. Not sure if that's just pure luck
or an actual workaround, but we can hope it works. So let's avoid reading
the register and instead track the desired value of the register in dev_priv.
v2: Read out the power well state to determine initial register value
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_reg.h | 5 +++-
drivers/gpu/drm/i915/intel_runtime_pm.c | 41 +
3 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b191b12..9a34cdf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1855,6 +1855,8 @@ struct drm_i915_private {
u32 fdi_rx_config;
+ u32 chv_phy_control;
+
u32 suspend_count;
struct i915_suspend_saved_registers regfile;
struct vlv_s0ix_state vlv_s0ix_state;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7546350..4b5900f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1848,7 +1848,10 @@ enum skl_disp_power_wells {
#define DPIO_PHY_STATUS(VLV_DISPLAY_BASE + 0x6240)
#define DPLL_PORTD_READY_MASK(0xf)
#define DISPLAY_PHY_CONTROL (VLV_DISPLAY_BASE + 0x60100)
-#define PHY_COM_LANE_RESET_DEASSERT(phy) (1 << (phy))
+#define PHY_CH_SU_PSR0x1
+#define PHY_CH_DEEP_PSR 0x7
+#define PHY_CH_POWER_MODE(mode, phy, ch) ((mode) << (6*(phy)+3*(ch)+2))
+#define PHY_COM_LANE_RESET_DEASSERT(phy) (1 << (phy))
#define DISPLAY_PHY_STATUS (VLV_DISPLAY_BASE + 0x60104)
#define PHY_POWERGOOD(phy) (((phy) == DPIO_PHY0) ? (1<<31) : (1<<30))
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 02b6b8f..4d5c7b5 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -630,8 +630,8 @@ static void chv_dpio_cmn_power_well_enable(struct
drm_i915_private *dev_priv,
if (wait_for(I915_READ(DISPLAY_PHY_STATUS) & PHY_POWERGOOD(phy), 1))
DRM_ERROR("Display PHY %d is not power up\n", phy);
- I915_WRITE(DISPLAY_PHY_CONTROL, I915_READ(DISPLAY_PHY_CONTROL) |
- PHY_COM_LANE_RESET_DEASSERT(phy));
+ dev_priv->chv_phy_control |= PHY_COM_LANE_RESET_DEASSERT(phy);
+ I915_WRITE(DISPLAY_PHY_CONTROL, dev_priv->chv_phy_control);
}
static void chv_dpio_cmn_power_well_disable(struct drm_i915_private *dev_priv,
@@ -651,8 +651,8 @@ static void chv_dpio_cmn_power_well_disable(struct
drm_i915_private *dev_priv,
assert_pll_disabled(dev_priv, PIPE_C);
}
- I915_WRITE(DISPLAY_PHY_CONTROL, I915_READ(DISPLAY_PHY_CONTROL) &
- ~PHY_COM_LANE_RESET_DEASSERT(phy));
+ dev_priv->chv_phy_control &= ~PHY_COM_LANE_RESET_DEASSERT(phy);
+ I915_WRITE(DISPLAY_PHY_CONTROL, dev_priv->chv_phy_control);
vlv_set_power_well(dev_priv, power_well, false);
}
@@ -1355,6 +1355,35 @@ static void intel_power_domains_resume(struct
drm_i915_private *dev_priv)
mutex_unlock(&power_domains->lock);
}
+static void chv_phy_control_init(struct drm_i915_private *dev_priv)
+{
+ struct i915_power_well *cmn_bc =
+ lookup_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_BC);
+ struct i915_power_well *cmn_d =
+ lookup_power_well(dev_priv, PUNIT_POWER_WELL_DPIO_CMN_D);
+
+ /*
+* DISPLAY_PHY_CONTROL sometimes gets
Re: [Intel-gfx] [PATCH 04/18] drm/i915/skl: Provide a gen9 specific init_render_ring()
On 09/02/2015 19:33, Damien Lespiau wrote:
WaDisableAsyncFlipPerfMode isn't listed for SKL and
INSTPM_FORCE_ORDERING is MBZ so let's make a gen9 specific render init
function.
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_lrc.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d05f3bc..fe25ced 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1149,6 +1149,17 @@ static int gen8_init_render_ring(struct intel_engine_cs
*ring)
return init_workarounds_ring(ring);
}
+static int gen9_init_render_ring(struct intel_engine_cs *ring)
+{
+ int ret;
+
+ ret = gen8_init_common_ring(ring);
+ if (ret)
+ return ret;
+
+ return init_workarounds_ring(ring);
+}
+
static int gen8_emit_bb_start(struct intel_ringbuffer *ringbuf,
struct intel_context *ctx,
u64 offset, unsigned flags)
@@ -1408,7 +1419,10 @@ static int logical_render_ring_init(struct drm_device
*dev)
if (HAS_L3_DPF(dev))
ring->irq_keep_mask |= GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
- ring->init_hw = gen8_init_render_ring;
+ if (INTEL_INFO(dev)->gen >= 9)
+ ring->init_hw = gen9_init_render_ring;
+ else
+ ring->init_hw = gen8_init_render_ring;
ring->init_context = gen8_init_rcs_context;
ring->cleanup = intel_fini_pipe_control;
ring->get_seqno = gen8_get_seqno;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/18] drm/i915/skl: Document that we implement WaRsClearFWBitsAtReset
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_uncore.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index c47a3ba..ad71575 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -972,6 +972,7 @@ static void fw_domain_init(struct drm_i915_private
*dev_priv,
d->val_set = FORCEWAKE_KERNEL;
d->val_clear = 0;
} else {
+ /* WaRsClearFWBitsAtReset:bdw,skl */
d->val_reset = _MASKED_BIT_DISABLE(0x);
d->val_set = _MASKED_BIT_ENABLE(FORCEWAKE_KERNEL);
d->val_clear = _MASKED_BIT_DISABLE(FORCEWAKE_KERNEL);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/18] drm/i915/skl: Implement WaDisableVFUnitClockGating
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2043e82..a457c28 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6007,6 +6007,7 @@ enum skl_disp_power_wells {
# define GEN6_CSUNIT_CLOCK_GATE_DISABLE (1 << 7)
#define GEN6_UCGCTL2 0x9404
+# define GEN6_VFUNIT_CLOCK_GATE_DISABLE(1 << 31)
# define GEN7_VDSUNIT_CLOCK_GATE_DISABLE (1 << 30)
# define GEN7_TDLUNIT_CLOCK_GATE_DISABLE (1 << 22)
# define GEN6_RCZUNIT_CLOCK_GATE_DISABLE (1 << 13)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ed029e7..ff4e289 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -75,6 +75,10 @@ static void skl_init_clock_gating(struct drm_device *dev)
I915_WRITE(GEN8_UCGCTL6, I915_READ(GEN8_UCGCTL6) |
GEN8_GAPSUNIT_CLOCK_GATE_DISABLE |
GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
+
+ /* WaDisableVFUnitClockGating:skl */
+ I915_WRITE(GEN6_UCGCTL2, I915_READ(GEN6_UCGCTL2) |
+ GEN6_VFUNIT_CLOCK_GATE_DISABLE);
bspec says this should be until B0
}
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/18] drm/i915/skl: Introduce a SKL specific init_workarounds()
On 09/02/2015 19:33, Damien Lespiau wrote:
This function will host SKL-only W/As.
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index b15d596..27d101c 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -928,6 +928,13 @@ static int gen9_init_workarounds(struct intel_engine_cs
*ring)
return 0;
}
+static int skl_init_workarounds(struct intel_engine_cs *ring)
+{
+ gen9_init_workarounds(ring);
+
+ return 0;
+}
+
int init_workarounds_ring(struct intel_engine_cs *ring)
{
struct drm_device *dev = ring->dev;
@@ -943,7 +950,9 @@ int init_workarounds_ring(struct intel_engine_cs *ring)
if (IS_CHERRYVIEW(dev))
return chv_init_workarounds(ring);
- if (IS_GEN9(dev))
+ if (IS_SKYLAKE(dev))
+ return skl_init_workarounds(ring);
+ else if (IS_GEN9(dev))
return gen9_init_workarounds(ring);
return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] DELL Latitude e5540 Intel 4400 3rd display problem
Dear Jani! Thank you for the quick replay. I tried and tried the v3.18 and v3.19-rv7 kernels, but thx X can't start. Do you have any other idea? BR, Gergő Üdvözlettel: Nógrádi Gergely gergely.nogr...@idata.hu 2015-02-04 14:34 GMT+01:00 Jani Nikula : > On Mon, 02 Feb 2015, Gergely Nógrádi wrote: > > I can't configure the 2nd or 3rd display on my Dell Latitude e5540 > > notebook and Dell NB Port Replicator. > > I tried to connect DVI, DP and VGA to Port Replicator and it is > > working only in mirror mode. > > The only way to use 2 external display if I connect the DVI or DP to > > Port Replicator and HDMI to notebook. > > I send the logs and system environment. > > The replicator probably needs DP MST support. Please try a newer kernel, > say v3.18 or v3.19-rc7, and see what happens. Attach dmesg with > drm.debug=14 module parameter set, running the new kernel. > > BR, > Jani. > > > -- > Jani Nikula, Intel Open Source Technology Center > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Detect eDRAM with the enabled bit only
2015-02-03 12:25 GMT-02:00 Damien Lespiau :
> At the moment we compare the whole EDRAM_PRESENT/EDRAMCAP register value
> to 1 while EDRAM_PRESENT is only bit 0 (the rest may be used to describe
> eDRAM capabilities).
>
> To be more future proof, only look at bit 0 to detect eDRAM presence.
>
> Signed-off-by: Damien Lespiau
For both patches: Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_uncore.c | 2 +-
> 2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 33b3d0a2..0aeaf7d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5980,6 +5980,7 @@ enum punit_power_well {
> #define HSW_IDICR 0x9008
> #defineIDIHASHMSK(x) (((x) & 0x3f) << 16)
> #define HSW_EDRAM_PRESENT 0x120010
> +#defineEDRAM_ENABLED 0x1
>
> #define GEN6_UCGCTL1 0x9400
> # define GEN6_EU_TCUNIT_CLOCK_GATE_DISABLE (1 << 16)
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 76b60a3..00c91be 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -328,7 +328,7 @@ static void intel_uncore_ellc_detect(struct drm_device
> *dev)
> struct drm_i915_private *dev_priv = dev->dev_private;
>
> if ((IS_HASWELL(dev) || IS_BROADWELL(dev)) &&
> - (__raw_i915_read32(dev_priv, HSW_EDRAM_PRESENT) == 1)) {
> + (__raw_i915_read32(dev_priv, HSW_EDRAM_PRESENT) & EDRAM_ENABLED))
> {
> /* The docs do not explain exactly how the calculation can be
> * made. It is somewhat guessable, but for now, it's always
> * 128MB.
> --
> 1.8.3.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add process identifier to requests
On Wed, Feb 11, 2015 at 04:50:14PM +0200, Mika Kuoppala wrote:
> We use the pid of the process which opened our device when
> we track which was the culprit of the gpu hang. But as that
> file descriptor might get inherited, we might blame the
> wrong process when we record the error state.
>
> Track process identifiers in requests to always find
> the correct offender.
>
> Cc: Kenneth Graunke
> Cc: Chris Wilson
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 +++
> drivers/gpu/drm/i915/i915_gem.c | 3 +++
> drivers/gpu/drm/i915/i915_gpu_error.c | 5 ++---
> 3 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c0b8644..9093654 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2153,6 +2153,9 @@ struct drm_i915_gem_request {
> /** file_priv list entry for this request */
> struct list_head client_list;
>
> + /** process identifier submitting this request */
> + struct pid *pid;
> +
> uint32_t uniq;
>
> /**
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index c26d36c..47affaf 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2483,6 +2483,7 @@ int __i915_add_request(struct intel_engine_cs *ring,
> request->emitted_jiffies = jiffies;
> list_add_tail(&request->list, &ring->request_list);
> request->file_priv = NULL;
> + request->pid = get_pid(task_pid(current));
>
> if (file) {
I would suggest you only track processes for requests submitted by
userspace. Then if there is no associated pid, we know that the kernel
was in control (and not stuck figuring out if kworker was acting on
behalf of the user or the kernel).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/18] drm/i915/skl: Implement WaDisablePowerCompilerClockGating
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_reg.h | 5 +++--
drivers/gpu/drm/i915/intel_ringbuffer.c | 8
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index a457c28..fdfbdb3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5241,8 +5241,9 @@ enum skl_disp_power_wells {
#define COMMON_SLICE_CHICKEN2 0x7014
# define GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE (1<<0)
-#define HIZ_CHICKEN0x7018
-# define CHV_HZ_8X8_MODE_IN_1X (1<<15)
+#define HIZ_CHICKEN0x7018
+# define CHV_HZ_8X8_MODE_IN_1X (1<<15)
+# define BDW_HIZ_POWER_COMPILER_CLOCK_GATING_DISABLE (1<<3)
#define GEN9_SLICE_COMMON_ECO_CHICKEN00x7308
#define DISABLE_PIXEL_MASK_CAMMING (1<<14)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 27d101c..3135192 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -930,8 +930,16 @@ static int gen9_init_workarounds(struct intel_engine_cs
*ring)
static int skl_init_workarounds(struct intel_engine_cs *ring)
{
+ struct drm_device *dev = ring->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
gen9_init_workarounds(ring);
+ /* WaDisablePowerCompilerClockGating:skl */
+ if (INTEL_REVID(dev) == SKL_REVID_B0)
Should this be <= ?
+ WA_SET_BIT_MASKED(HIZ_CHICKEN,
+ BDW_HIZ_POWER_COMPILER_CLOCK_GATING_DISABLE);
+
return 0;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/18] drm/i915/skl: Implement WaDisablePartialResolveInVc
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index fdfbdb3..d519ed9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1483,6 +1483,7 @@ enum skl_disp_power_wells {
#define CACHE_MODE_1 0x7004 /* IVB+ */
#define PIXEL_SUBSPAN_COLLECT_OPT_DISABLE (1<<6)
#define GEN8_4x4_STC_OPTIMIZATION_DISABLE (1<<6)
+#define GEN9_PARTIAL_RESOLVE_IN_VC_DISABLE (1<<1)
#define GEN6_BLITTER_ECOSKPD 0x221d0
#define GEN6_BLITTER_LOCK_SHIFT 16
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 3135192..db83baf 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -925,6 +925,9 @@ static int gen9_init_workarounds(struct intel_engine_cs
*ring)
/* Wa4x4STCOptimizationDisable:skl */
WA_SET_BIT_MASKED(CACHE_MODE_1, GEN8_4x4_STC_OPTIMIZATION_DISABLE);
+ /* WaDisablePartialResolveInVc:skl */
+ WA_SET_BIT_MASKED(CACHE_MODE_1, GEN9_PARTIAL_RESOLVE_IN_VC_DISABLE);
+
return 0;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/18] drm/i915/skl: Implement WaDisableLSQCROPERFforOCL
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 5 +
3 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c0b8644..0765bd1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2391,6 +2391,7 @@ struct drm_i915_cmd_table {
#define SKL_REVID_B0 (0x1)
#define SKL_REVID_C0 (0x2)
#define SKL_REVID_D0 (0x3)
+#define SKL_REVID_E0 (0x4)
/*
* The genX designation typically refers to the render engine, so render
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d519ed9..3ae7a09 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5264,6 +5264,9 @@ enum skl_disp_power_wells {
#define GEN7_L3SQCREG40xb034
#define L3SQ_URB_READ_CAM_MATCH_DISABLE (1<<27)
+#define GEN8_L3SQCREG4 0xb118
+#define GEN8_LQSC_RO_PERF_DIS (1<<27)
+
/* GEN8 chicken */
#define HDC_CHICKEN0 0x7300
#define HDC_FORCE_NON_COHERENT (1<<4)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ff4e289..f53ef11 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -80,6 +80,11 @@ static void skl_init_clock_gating(struct drm_device *dev)
I915_WRITE(GEN6_UCGCTL2, I915_READ(GEN6_UCGCTL2) |
GEN6_VFUNIT_CLOCK_GATE_DISABLE);
}
+
+ if (INTEL_REVID(dev) <= SKL_REVID_E0)
+ /* WaDisableLSQCROPERFforOCL:skl */
+ I915_WRITE(GEN8_L3SQCREG4, I915_READ(GEN8_L3SQCREG4) |
+ GEN8_LQSC_RO_PERF_DIS);
}
static void i915_pineview_get_mem_freq(struct drm_device *dev)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/18] drm/i915/skl: Implement WaDisableHDCInvalidation
On 09/02/2015 19:33, Damien Lespiau wrote: Signed-off-by: Damien Lespiau Reviewed-by: Nick Hoath --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 6 ++ 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 3ae7a09..b363c5e 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -140,6 +140,7 @@ #define GEN8_RING_PDP_LDW(ring, n)((ring)->mmio_base+0x270 + (n) * 8) #define GAM_ECOCHK0x4090 +#define BDW_DISABLE_HDC_INVALIDATION (1<<25) #define ECOCHK_SNB_BIT (1<<10) #define HSW_ECOCHK_ARB_PRIO_SOL (1<<6) #define ECOCHK_PPGTT_CACHE64B (0x3<<3) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index f53ef11..8f9149b 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -81,6 +81,12 @@ static void skl_init_clock_gating(struct drm_device *dev) GEN6_VFUNIT_CLOCK_GATE_DISABLE); } + if (INTEL_REVID(dev) <= SKL_REVID_D0) + /* WaDisableHDCInvalidation:skl */ + I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | + BDW_DISABLE_HDC_INVALIDATION); + + if (INTEL_REVID(dev) <= SKL_REVID_E0) /* WaDisableLSQCROPERFforOCL:skl */ I915_WRITE(GEN8_L3SQCREG4, I915_READ(GEN8_L3SQCREG4) | ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/18] drm/i915/skl: Implement WaDisableChickenBitTSGBarrierAckForFFSliceCS
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 7 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b363c5e..610fcd4 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5236,6 +5236,9 @@ enum skl_disp_power_wells {
#define HSW_NDE_RSTWRN_OPT0x46408
#define RESET_PCH_HANDSHAKE_ENABLE (1<<4)
+#define FF_SLICE_CS_CHICKEN2 0x02e4
+#define GEN9_TSG_BARRIER_ACK_DISABLE (1<<8)
+
/* GEN7 chicken */
#define GEN7_COMMON_SLICE_CHICKEN10x7010
# define GEN7_CSC1_RHWO_OPT_DISABLE_IN_RCC((1<<10) | (1<<26))
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8f9149b..6254102 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -81,11 +81,16 @@ static void skl_init_clock_gating(struct drm_device *dev)
GEN6_VFUNIT_CLOCK_GATE_DISABLE);
}
- if (INTEL_REVID(dev) <= SKL_REVID_D0)
+ if (INTEL_REVID(dev) <= SKL_REVID_D0) {
/* WaDisableHDCInvalidation:skl */
I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) |
BDW_DISABLE_HDC_INVALIDATION);
+ /* WaDisableChickenBitTSGBarrierAckForFFSliceCS:skl */
+ I915_WRITE(FF_SLICE_CS_CHICKEN2,
+ I915_READ(FF_SLICE_CS_CHICKEN2) |
+ GEN9_TSG_BARRIER_ACK_DISABLE);
+ }
if (INTEL_REVID(dev) <= SKL_REVID_E0)
/* WaDisableLSQCROPERFforOCL:skl */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/18] drm/i915/skl: Implement WaCcsTlbPrefetchDisable:skl
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 4
2 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 610fcd4..090ddd7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6216,6 +6216,7 @@ enum skl_disp_power_wells {
#define GEN9_HALF_SLICE_CHICKEN5 0xe188
#define GEN9_DG_MIRROR_FIX_ENABLE (1<<5)
+#define GEN9_CCS_TLB_PREFETCH_ENABLE (1<<3)
#define GEN8_ROW_CHICKEN 0xe4f0
#define PARTIAL_INSTRUCTION_SHOOTDOWN_DISABLE (1<<8)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index db83baf..57432ca 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -928,6 +928,10 @@ static int gen9_init_workarounds(struct intel_engine_cs
*ring)
/* WaDisablePartialResolveInVc:skl */
WA_SET_BIT_MASKED(CACHE_MODE_1, GEN9_PARTIAL_RESOLVE_IN_VC_DISABLE);
+ /* WaCcsTlbPrefetchDisable:skl */
+ WA_CLR_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN5,
+ GEN9_CCS_TLB_PREFETCH_ENABLE);
+
return 0;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Detect eDRAM with the enabled bit only
On Wed, Feb 11, 2015 at 01:27:14PM -0200, Paulo Zanoni wrote: > 2015-02-03 12:25 GMT-02:00 Damien Lespiau : > > At the moment we compare the whole EDRAM_PRESENT/EDRAMCAP register value > > to 1 while EDRAM_PRESENT is only bit 0 (the rest may be used to describe > > eDRAM capabilities). > > > > To be more future proof, only look at bit 0 to detect eDRAM presence. > > > > Signed-off-by: Damien Lespiau > > For both patches: Reviewed-by: Paulo Zanoni Both merged, thanks for patches&review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 18/18] drm/i915/skl: Implement WaBarrierPerformanceFixDisable
On 09/02/2015 19:33, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau
Reviewed-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ringbuffer.c | 7 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 090ddd7..b4abd50 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5276,6 +5276,7 @@ enum skl_disp_power_wells {
#define HDC_FORCE_NON_COHERENT (1<<4)
#define HDC_DONOT_FETCH_MEM_WHEN_MASKED (1<<11)
#define HDC_FENCE_DEST_SLM_DISABLE (1<<14)
+#define HDC_BARRIER_PERFORMANCE_DISABLE (1<<10)
/* WaCatErrorRejectionIssue */
#define GEN7_SQ_CHICKEN_MBCUNIT_CONFIG0x9030
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 57432ca..93365fe 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -947,6 +947,13 @@ static int skl_init_workarounds(struct intel_engine_cs
*ring)
WA_SET_BIT_MASKED(HIZ_CHICKEN,
BDW_HIZ_POWER_COMPILER_CLOCK_GATING_DISABLE);
+ if (INTEL_REVID(dev) == SKL_REVID_C0 ||
+ INTEL_REVID(dev) == SKL_REVID_D0)
+ /* WaBarrierPerformanceFixDisable:skl */
+ WA_SET_BIT_MASKED(HDC_CHICKEN0,
+ HDC_FENCE_DEST_SLM_DISABLE |
+ HDC_BARRIER_PERFORMANCE_DISABLE);
+
return 0;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/18] drm/i915/skl: Implement WaDisableChickenBitTSGBarrierAckForFFSliceCS
On Wed, Feb 11, 2015 at 03:42:16PM +, Nick Hoath wrote: > On 09/02/2015 19:33, Damien Lespiau wrote: > >Signed-off-by: Damien Lespiau > > Reviewed-by: Nick Hoath Merged all the ones Nick has reviewd already. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: DP link training optimization
On Wed, Feb 11, 2015 at 04:57:06PM +0200, Jani Nikula wrote: > On Wed, 11 Feb 2015, Mika Kahola wrote: > > - > > Intel Finland Oy > > Registered Address: PL 281, 00181 Helsinki > > Business Identity Code: 0357606 - 4 > > Domiciled in Helsinki > > > > This e-mail and any attachments may contain confidential material for > > the sole use of the intended recipient(s). Any review or distribution > > by others is strictly prohibited. If you are not the intended > > recipient, please contact the sender and delete all copies. Also please don't submit patches with this disclaimer, since that disclaimer and MIT/GPL lincense just don't agree. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/10] drm/i915: Make intel_ring_setup_status_page() static
On Wed, Feb 11, 2015 at 01:46:19PM +, Damien Lespiau wrote:
> On Tue, Feb 10, 2015 at 07:32:17PM +, Damien Lespiau wrote:
> > This function is only used in intel_ringbuffer.c, so restrict it to that
> > file. The function was moved around to avoid a forward declaration and
> > group it with its user.
> >
> > Signed-off-by: Damien Lespiau
> > ---
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 124
> >
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
> > 2 files changed, 62 insertions(+), 63 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index 0631780..0a7b1af 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -502,6 +502,68 @@ static void ring_setup_phys_status_page(struct
> > intel_engine_cs *ring)
> > I915_WRITE(HWS_PGA, addr);
> > }
> >
> > +void intel_ring_setup_status_page(struct intel_engine_cs *ring)
> > +{
>
> I've actually manged to screw this one up. Daniel could you ammend this?
> or do you want a new patch? (fengguang's 0day bot even generated a patch
> for us).
Already squashed in the 0day bot bugfix ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] xf86drm: Unconditionally clear ioctl structs
On Wed, Feb 11, 2015 at 10:57:08AM -0500, Jan Vesely wrote: > On Wed, 2015-02-11 at 12:42 +0100, Daniel Vetter wrote: > > We really have to do this to avoid surprises when extending the ABI > > later on. Especially when growing the structures. > > > > A bit overkill to update all the old legacy ioctl wrappers, but can't > > hurt really either. > > > > Signed-off-by: Daniel Vetter > > --- > > xf86drm.c | 112 > > ++ > > 1 file changed, 77 insertions(+), 35 deletions(-) > > > > diff --git a/xf86drm.c b/xf86drm.c > > index 263d6835c29a..a2e24eb5f76c 100644 > > --- a/xf86drm.c > > +++ b/xf86drm.c > > @@ -89,6 +89,8 @@ > > #define DRM_NODE_PRIMARY 1 > > #define DRM_NODE_RENDER 2 > > > > +#define memclear(s) memset(&s, 0, sizeof(s)) > > + > > static drmServerInfoPtr drm_server_info; > > > > void drmSetServerInfo(drmServerInfoPtr info) > > @@ -766,12 +768,7 @@ drmVersionPtr drmGetVersion(int fd) > > drmVersionPtr retval; > > drm_version_t *version = drmMalloc(sizeof(*version)); > > > > -version->name_len= 0; > > -version->name= NULL; > > -version->date_len= 0; > > -version->date= NULL; > > -version->desc_len= 0; > > -version->desc= NULL; > > +memclear(version); > > I think this should be memclear(*version). > Otherwise it clears the pointer not the structure. Yeah ... and stupid me already pushed this :( I'll fix it up and have another look at the patches to make sure I didn't botch another one. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Align initial plane backing objects correctly
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5755 -Summary- Platform Delta drm-intel-nightly Series Applied PNV -1 275/275 274/275 ILK -2 310/310 308/310 SNB +2 320/346 322/346 IVB -2 380/380 378/380 BYT 296/296 296/296 HSW +3-1 422/428 424/428 BDW 318/333 318/333 -Detailed- Platform Testdrm-intel-nightly Series Applied *PNV igt_gem_tiled_pread_pwrite PASS(5, M7) FAIL(1, M7) ILK igt_drv_suspend_fence-restore-tiled2untiled DMESG_WARN(3, M26)PASS(1, M26) DMESG_WARN(1, M26) *ILK igt_kms_flip_rcs-flip-vs-panning PASS(2, M26) DMESG_WARN(1, M26) *SNB igt_kms_flip_bo-too-big BLACKLIST(1, M35) PASS(1, M35) *SNB igt_kms_flip_bo-too-big-interruptible BLACKLIST(1, M35) PASS(1, M35) *IVB igt_gem_pwrite_pread_display-copy-performance PASS(2, M4) DMESG_WARN(1, M4) *IVB igt_gem_storedw_batches_loop_secure-dispatch PASS(3, M4) DMESG_WARN(1, M4) *HSW igt_gem_storedw_loop_vebox PASS(2, M40) DMESG_WARN(1, M40) *HSW igt_kms_flip_bo-too-big BLACKLIST(1, M40) PASS(1, M40) *HSW igt_kms_flip_bo-too-big-interruptible BLACKLIST(1, M40) PASS(1, M40) HSW igt_kms_flip_plain-flip-fb-recreate-interruptible TIMEOUT(6, M40)PASS(5, M40) PASS(1, M40) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915: WARN_ON(val > dev_priv->rps.max_freq_softlimit)
On Wed, Feb 11, 2015 at 08:30:44AM +0100, Daniel Vetter wrote: > On Tue, Feb 10, 2015 at 10:26:02PM -0800, O'Rourke, Tom wrote: > > On Thu, Jan 29, 2015 at 08:56:06PM -0500, Michael Auchter wrote: > > > On Thu, Jan 29, 2015 at 06:12:31PM +0100, Daniel Vetter wrote: > > > > On Wed, Jan 28, 2015 at 10:36:02PM -0800, O'Rourke, Tom wrote: > > > > > On Wed, Jan 28, 2015 at 01:28:58PM +0200, Ville Syrjälä wrote: > > > > > > On Wed, Jan 28, 2015 at 09:58:15AM +, Chris Wilson wrote: > > > > > > > On Wed, Jan 28, 2015 at 12:43:21AM -0500, Michael Auchter wrote: > > > > > > > > Testing out 3.19-rc6 on my 2014 Thinkpad X1 Carbon (Haswell) > > > > > > > > resulted in > > > > > > > > this WARN at boot (and pretty frequently afterwards): > > > > > > > > > > > > > > > > WARNING: CPU: 0 PID: 989 at > > > > > > > > drivers/gpu/drm/i915/intel_pm.c:4377 gen6_set_rps+0x371/0x3c0() > > > > > > > > WARN_ON(val > dev_priv->rps.max_freq_softlimit) > > > > > > > > > > > > > > [snip] > > > > > > > > > > > > > > > I'm not at all familiar with this hardware, but I took a quick > > > > > > > > look into > > > > > > > > what changed with this commit for my laptop. Before the commit, > > > > > > > > rps.min_freq_softlimit is 4 (from rps.min_freq) and > > > > > > > > rps.max_freq_softlimit is 22. > > > > > > > > > > > > > > > > After the commit, rps.min_freq_softlimit is set to the > > > > > > > > rps.efficient_freq value read from pcode, which is 34 on my > > > > > > > > laptop. > > > > > > > > So later when gen6_set_rps() is called with > > > > > > > > rps.min_freq_softlimit that > > > > > > > > warning is hit. > > > > > > > > > > > > > > > > Any thoughts? It certainly seems fishy that this commit causes > > > > > > > > rps.min_freq_softlimit to be greater than > > > > > > > > rps.max_freq_softlimit. > > > > > > > > > > > > > > Very fishy indeed. Moral of this story, never trust hw. > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > > > > > > b/drivers/gpu/drm/i915/intel_pm.c > > > > > > > index 3e630feb18e4..bbedd2901c54 100644 > > > > > > > --- a/drivers/gpu/drm/i915/intel_pm.c > > > > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > > > > > > @@ -4007,7 +4007,10 @@ static void > > > > > > > gen6_init_rps_frequencies(struct drm_device *dev) > > > > > > > &ddcc_status); > > > > > > > if (0 == ret) > > > > > > > dev_priv->rps.efficient_freq = > > > > > > > - (ddcc_status >> 8) & 0xff; > > > > > > > + clamp_t(u8, > > > > > > > + (ddcc_status >> 8) & 0xff, > > > > > > > + dev_priv->rps.min_freq, > > > > > > > + dev_priv->rps.max_freq); > > > > > > > > > > > > Maybe better to fall back to rp1_freq if this is bogus? > > > > > > > > > > > [TOR:] Michael, Thank you for bringing this problem to our attention. > > > > > > > > > > Yes, this function needs some range checking to maintain > > > > > RPn <= RPe <= RP0. > > > > > > > > > > A value of 34 seems too high for RPe. > > > > > What values does the Carbon X1 (Haswell) have for RPn and RP0? > > > > > > > > 4 & 22, already in Micheal's original bug report. > > > > > > > > Tom, can you pls polish the clamping into a proper patch with m-l > > > > references? > > > > > > > > Micheal, can you please test the first hunk from Chris (the one that > > > > adds > > > > the clamp) to make sure it does indeed address the WARN_ON you're > > > > seeing? > > > > > > The clamp suggested by Chris does indeed fix the WARN_ON. > > > > > > In the case where RPe is greater than RP0, RPe will now be clamped to > > > RP0. Is this likely to result in increased power consumption? > > > > > > At a quick glance on my laptop it does not (idling around 5W before and > > > after) but Ville had suggested earlier to fall back to RP1, which would > > > be more consistent with previous kernels. > > > > > > Thanks again for the quick responses, > > > Michael > > > > [TOR:] Michael, I discussed this report with a pcode architect here. > > > > The RPe value is clamped to the [RPn, RP0] range by pcode before > > returning the value to the driver on Broadwell but not on Haswell. > > > > On Haswell, an efficient frequency value above RP0 is not a garbage > > value and could result from a relatively flat efficiency curve. In > > this situation, leakage power would dominate the efficiency curve > > such that running at lower frequencies may not save power overall. > > Higher leakage power may result from a higher package temperature. > > > > Running at RP0 may actually save power compared to RP1 by allowing > > more time in RC6. > > Hm, I'd just go with clamping since that's what bdw does too. So Chris > diff essentially. > -Daniel [TOR:] Yes, we should go with clamping, essentially the diff from Chris. I am trying
[Intel-gfx] [PATCH v2] drm/i915/skl: Implement WaDisableHBR2
v2: Use the recently introduced INTEL_REVID() and SKL_REVID defines (Nick Hoath) Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/intel_dp.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index d4c82d7..a7bc3e8 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -129,7 +129,10 @@ intel_dp_max_link_bw(struct intel_dp *intel_dp) case DP_LINK_BW_2_7: break; case DP_LINK_BW_5_4: /* 1.2 capable displays may advertise higher bw */ - if (((IS_HASWELL(dev) && !IS_HSW_ULX(dev)) || + if (IS_SKYLAKE(dev) && INTEL_REVID(dev) <= SKL_REVID_B0) + /* WaDisableHBR2:skl */ + max_link_bw = DP_LINK_BW_2_7; + else if (((IS_HASWELL(dev) && !IS_HSW_ULX(dev)) || INTEL_INFO(dev)->gen >= 8) && intel_dp->dpcd[DP_DPCD_REV] >= 0x12) max_link_bw = DP_LINK_BW_5_4; -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/18] drm/i915/skl: Implement WaDisablePowerCompilerClockGating
On Wed, Feb 11, 2015 at 03:29:51PM +, Nick Hoath wrote:
> On 09/02/2015 19:33, Damien Lespiau wrote:
> >Signed-off-by: Damien Lespiau
> >---
> > drivers/gpu/drm/i915/i915_reg.h | 5 +++--
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 8
> > 2 files changed, 11 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >b/drivers/gpu/drm/i915/i915_reg.h
> >index a457c28..fdfbdb3 100644
> >--- a/drivers/gpu/drm/i915/i915_reg.h
> >+++ b/drivers/gpu/drm/i915/i915_reg.h
> >@@ -5241,8 +5241,9 @@ enum skl_disp_power_wells {
> > #define COMMON_SLICE_CHICKEN2 0x7014
> > # define GEN8_CSC2_SBE_VUE_CACHE_CONSERVATIVE (1<<0)
> >
> >-#define HIZ_CHICKEN 0x7018
> >-# define CHV_HZ_8X8_MODE_IN_1X (1<<15)
> >+#define HIZ_CHICKEN 0x7018
> >+# define CHV_HZ_8X8_MODE_IN_1X (1<<15)
> >+# define BDW_HIZ_POWER_COMPILER_CLOCK_GATING_DISABLE(1<<3)
> >
> > #define GEN9_SLICE_COMMON_ECO_CHICKEN0 0x7308
> > #define DISABLE_PIXEL_MASK_CAMMING(1<<14)
> >diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> >b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >index 27d101c..3135192 100644
> >--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> >+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >@@ -930,8 +930,16 @@ static int gen9_init_workarounds(struct intel_engine_cs
> >*ring)
> >
> > static int skl_init_workarounds(struct intel_engine_cs *ring)
> > {
> >+struct drm_device *dev = ring->dev;
> >+struct drm_i915_private *dev_priv = dev->dev_private;
> >+
> > gen9_init_workarounds(ring);
> >
> >+/* WaDisablePowerCompilerClockGating:skl */
> >+if (INTEL_REVID(dev) == SKL_REVID_B0)
>
> Should this be <= ?
Nop, both specs (SKL:GT2:B) and the wa db (SIWA_ONLY_SKL_B0) state
firmly B0 only.
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/skl: Use a LRI for WaDisableDgMirrorFixInHalfSliceChicken5
I have no idea how that crept in, but we need to do the write from the
ring and this is a masked register. Two fixes in 1!
Cc: Nick Hoath
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 8735e56..acc1669 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -959,13 +959,9 @@ static int gen9_init_workarounds(struct intel_engine_cs
*ring)
if (INTEL_REVID(dev) == SKL_REVID_A0 ||
INTEL_REVID(dev) == SKL_REVID_B0) {
- /*
- * WaDisableDgMirrorFixInHalfSliceChicken5:skl
- * This is a pre-production w/a.
- */
- I915_WRITE(GEN9_HALF_SLICE_CHICKEN5,
- I915_READ(GEN9_HALF_SLICE_CHICKEN5) &
- ~GEN9_DG_MIRROR_FIX_ENABLE);
+ /* WaDisableDgMirrorFixInHalfSliceChicken5:skl */
+ WA_CLR_BIT_MASKED(GEN9_HALF_SLICE_CHICKEN5,
+ GEN9_DG_MIRROR_FIX_ENABLE);
}
if (INTEL_REVID(dev) >= SKL_REVID_C0) {
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/skl: Fix always true comparison in a revision id check
It's always a good idea to keep static analysis happy (also because it
prompts doing the check like I proposed :), this time smatch complains:
drivers/gpu/drm/i915/intel_ringbuffer.c:891 gen9_init_workarounds() warn:
always true condition '((->dev->pdev->revision) >= (0)) => (0-255 >= 0)'
That's because revision is a u8. Tweak a bit the condition then.
Cc: Nick Hoath
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 2060610..8735e56 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -957,8 +957,8 @@ static int gen9_init_workarounds(struct intel_engine_cs
*ring)
WA_SET_BIT_MASKED(HALF_SLICE_CHICKEN3,
GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC);
- if (INTEL_REVID(dev) >= SKL_REVID_A0 &&
- INTEL_REVID(dev) <= SKL_REVID_B0) {
+ if (INTEL_REVID(dev) == SKL_REVID_A0 ||
+ INTEL_REVID(dev) == SKL_REVID_B0) {
/*
* WaDisableDgMirrorFixInHalfSliceChicken5:skl
* This is a pre-production w/a.
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] A couple of fixes on top of the recent W/A work
The first one is minor, while it's puzzling I managed to give my r-b tag for the the second one. Oh Well. -- Damien Damien Lespiau (2): drm/i915/skl: Fix always true comparison in a revision id check drm/i915/skl: Use a LRI for WaDisableDgMirrorFixInHalfSliceChicken5 drivers/gpu/drm/i915/intel_ringbuffer.c | 14 +- 1 file changed, 5 insertions(+), 9 deletions(-) -- 1.8.3.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] intel: Unconditionally clear ioctl structs
This patch is
Reviewed-by: Ian Romanick
On 02/11/2015 03:42 AM, Daniel Vetter wrote:
> We really have to do this to avoid surprises when extending the ABI
> later on. Especially when growing the structures.
>
> Signed-off-by: Daniel Vetter
> ---
> intel/intel_bufmgr_gem.c | 68
>
> 1 file changed, 34 insertions(+), 34 deletions(-)
>
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index cf85bb8ae0bf..78875fd329f2 100644
> --- a/intel/intel_bufmgr_gem.c
> +++ b/intel/intel_bufmgr_gem.c
> @@ -74,7 +74,7 @@
> #define VG(x)
> #endif
>
> -#define VG_CLEAR(s) VG(memset(&s, 0, sizeof(s)))
> +#define memclear(s) memset(&s, 0, sizeof(s))
>
> #define DBG(...) do {\
> if (bufmgr_gem->bufmgr.debug) \
> @@ -593,7 +593,7 @@ drm_intel_gem_bo_busy(drm_intel_bo *bo)
> if (bo_gem->reusable && bo_gem->idle)
> return false;
>
> - VG_CLEAR(busy);
> + memclear(busy);
> busy.handle = bo_gem->gem_handle;
>
> ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GEM_BUSY, &busy);
> @@ -612,7 +612,7 @@ drm_intel_gem_bo_madvise_internal(drm_intel_bufmgr_gem
> *bufmgr_gem,
> {
> struct drm_i915_gem_madvise madv;
>
> - VG_CLEAR(madv);
> + memclear(madv);
> madv.handle = bo_gem->gem_handle;
> madv.madv = state;
> madv.retained = 1;
> @@ -741,7 +741,7 @@ retry:
>
> bo_gem->bo.size = bo_size;
>
> - VG_CLEAR(create);
> + memclear(create);
> create.size = bo_size;
>
> ret = drmIoctl(bufmgr_gem->fd,
> @@ -888,7 +888,7 @@ drm_intel_gem_bo_alloc_userptr(drm_intel_bufmgr *bufmgr,
>
> bo_gem->bo.size = size;
>
> - VG_CLEAR(userptr);
> + memclear(userptr);
> userptr.user_ptr = (__u64)((unsigned long)addr);
> userptr.user_size = size;
> userptr.flags = flags;
> @@ -972,7 +972,7 @@ drm_intel_bo_gem_create_from_name(drm_intel_bufmgr
> *bufmgr,
> }
> }
>
> - VG_CLEAR(open_arg);
> + memclear(open_arg);
> open_arg.name = handle;
> ret = drmIoctl(bufmgr_gem->fd,
> DRM_IOCTL_GEM_OPEN,
> @@ -1017,7 +1017,7 @@ drm_intel_bo_gem_create_from_name(drm_intel_bufmgr
> *bufmgr,
> bo_gem->global_name = handle;
> bo_gem->reusable = false;
>
> - VG_CLEAR(get_tiling);
> + memclear(get_tiling);
> get_tiling.handle = bo_gem->gem_handle;
> ret = drmIoctl(bufmgr_gem->fd,
> DRM_IOCTL_I915_GEM_GET_TILING,
> @@ -1060,7 +1060,7 @@ drm_intel_gem_bo_free(drm_intel_bo *bo)
> }
>
> /* Close this object */
> - VG_CLEAR(close);
> + memclear(close);
> close.handle = bo_gem->gem_handle;
> ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_GEM_CLOSE, &close);
> if (ret != 0) {
> @@ -1292,9 +1292,8 @@ static int drm_intel_gem_bo_map(drm_intel_bo *bo, int
> write_enable)
> DBG("bo_map: %d (%s), map_count=%d\n",
> bo_gem->gem_handle, bo_gem->name, bo_gem->map_count);
>
> - VG_CLEAR(mmap_arg);
> + memclear(mmap_arg);
> mmap_arg.handle = bo_gem->gem_handle;
> - mmap_arg.offset = 0;
> mmap_arg.size = bo->size;
> ret = drmIoctl(bufmgr_gem->fd,
> DRM_IOCTL_I915_GEM_MMAP,
> @@ -1316,7 +1315,7 @@ static int drm_intel_gem_bo_map(drm_intel_bo *bo, int
> write_enable)
> bo_gem->mem_virtual);
> bo->virtual = bo_gem->mem_virtual;
>
> - VG_CLEAR(set_domain);
> + memclear(set_domain);
> set_domain.handle = bo_gem->gem_handle;
> set_domain.read_domains = I915_GEM_DOMAIN_CPU;
> if (write_enable)
> @@ -1362,7 +1361,7 @@ map_gtt(drm_intel_bo *bo)
> DBG("bo_map_gtt: mmap %d (%s), map_count=%d\n",
> bo_gem->gem_handle, bo_gem->name, bo_gem->map_count);
>
> - VG_CLEAR(mmap_arg);
> + memclear(mmap_arg);
> mmap_arg.handle = bo_gem->gem_handle;
>
> /* Get the fake offset back... */
> @@ -1430,7 +1429,7 @@ drm_intel_gem_bo_map_gtt(drm_intel_bo *bo)
>* tell it when we're about to use things if we had done
>* rendering and it still happens to be bound to the GTT.
>*/
> - VG_CLEAR(set_domain);
> + memclear(set_domain);
> set_domain.handle = bo_gem->gem_handle;
> set_domain.read_domains = I915_GEM_DOMAIN_GTT;
> set_domain.write_domain = I915_GEM_DOMAIN_GTT;
> @@ -1529,7 +1528,7 @@ static int drm_intel_gem_bo_unmap(drm_intel_bo *bo)
>* Unlike GTT set domains, this only does work if the
>* buffer should be scanout-related.
>*/
> - VG_CLEAR(sw_finish);
> + memclear(sw_finish);
> sw_finish.handle = bo_gem->gem_handle;
> ret = drmIoc
Re: [Intel-gfx] [PATCH 2/4] xf86drmMode: Unconditionally clear ioctl structs
This patch is
Reviewed-by: Ian Romanick
On 02/11/2015 03:42 AM, Daniel Vetter wrote:
> We really have to do this to avoid surprises when extending the ABI
> later on. Especially when growing the structures.
>
> Signed-off-by: Daniel Vetter
> ---
> xf86drmMode.c | 55 ---
> 1 file changed, 28 insertions(+), 27 deletions(-)
>
> diff --git a/xf86drmMode.c b/xf86drmMode.c
> index e3e599bdc39d..9ea8fe721842 100644
> --- a/xf86drmMode.c
> +++ b/xf86drmMode.c
> @@ -61,7 +61,7 @@
> #define VG(x)
> #endif
>
> -#define VG_CLEAR(s) VG(memset(&s, 0, sizeof(s)))
> +#define memclear(s) memset(&s, 0, sizeof(s))
>
> #define U642VOID(x) ((void *)(unsigned long)(x))
> #define VOID2U64(x) ((uint64_t)(unsigned long)(x))
> @@ -164,7 +164,7 @@ drmModeResPtr drmModeGetResources(int fd)
> drmModeResPtr r = 0;
>
> retry:
> - memset(&res, 0, sizeof(struct drm_mode_card_res));
> + memclear(res);
> if (drmIoctl(fd, DRM_IOCTL_MODE_GETRESOURCES, &res))
> return 0;
>
> @@ -259,7 +259,7 @@ int drmModeAddFB(int fd, uint32_t width, uint32_t height,
> uint8_t depth,
> struct drm_mode_fb_cmd f;
> int ret;
>
> - VG_CLEAR(f);
> + memclear(f);
> f.width = width;
> f.height = height;
> f.pitch = pitch;
> @@ -282,6 +282,7 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
> struct drm_mode_fb_cmd2 f;
> int ret;
>
> + memclear(f);
> f.width = width;
> f.height = height;
> f.pixel_format = pixel_format;
> @@ -300,8 +301,6 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t height,
> int drmModeRmFB(int fd, uint32_t bufferId)
> {
> return DRM_IOCTL(fd, DRM_IOCTL_MODE_RMFB, &bufferId);
> -
> -
> }
>
> drmModeFBPtr drmModeGetFB(int fd, uint32_t buf)
> @@ -309,6 +308,7 @@ drmModeFBPtr drmModeGetFB(int fd, uint32_t buf)
> struct drm_mode_fb_cmd info;
> drmModeFBPtr r;
>
> + memclear(info);
> info.fb_id = buf;
>
> if (drmIoctl(fd, DRM_IOCTL_MODE_GETFB, &info))
> @@ -331,8 +331,9 @@ drmModeFBPtr drmModeGetFB(int fd, uint32_t buf)
> int drmModeDirtyFB(int fd, uint32_t bufferId,
> drmModeClipPtr clips, uint32_t num_clips)
> {
> - struct drm_mode_fb_dirty_cmd dirty = { 0 };
> + struct drm_mode_fb_dirty_cmd dirty;
>
> + memclear(dirty);
> dirty.fb_id = bufferId;
> dirty.clips_ptr = VOID2U64(clips);
> dirty.num_clips = num_clips;
> @@ -350,7 +351,7 @@ drmModeCrtcPtr drmModeGetCrtc(int fd, uint32_t crtcId)
> struct drm_mode_crtc crtc;
> drmModeCrtcPtr r;
>
> - VG_CLEAR(crtc);
> + memclear(crtc);
> crtc.crtc_id = crtcId;
>
> if (drmIoctl(fd, DRM_IOCTL_MODE_GETCRTC, &crtc))
> @@ -384,7 +385,7 @@ int drmModeSetCrtc(int fd, uint32_t crtcId, uint32_t
> bufferId,
> {
> struct drm_mode_crtc crtc;
>
> - VG_CLEAR(crtc);
> + memclear(crtc);
> crtc.x = x;
> crtc.y = y;
> crtc.crtc_id = crtcId;
> @@ -394,8 +395,7 @@ int drmModeSetCrtc(int fd, uint32_t crtcId, uint32_t
> bufferId,
> if (mode) {
> memcpy(&crtc.mode, mode, sizeof(struct drm_mode_modeinfo));
> crtc.mode_valid = 1;
> - } else
> - crtc.mode_valid = 0;
> + }
>
> return DRM_IOCTL(fd, DRM_IOCTL_MODE_SETCRTC, &crtc);
> }
> @@ -408,6 +408,7 @@ int drmModeSetCursor(int fd, uint32_t crtcId, uint32_t
> bo_handle, uint32_t width
> {
> struct drm_mode_cursor arg;
>
> + memclear(arg);
> arg.flags = DRM_MODE_CURSOR_BO;
> arg.crtc_id = crtcId;
> arg.width = width;
> @@ -421,6 +422,7 @@ int drmModeSetCursor2(int fd, uint32_t crtcId, uint32_t
> bo_handle, uint32_t widt
> {
> struct drm_mode_cursor2 arg;
>
> + memclear(arg);
> arg.flags = DRM_MODE_CURSOR_BO;
> arg.crtc_id = crtcId;
> arg.width = width;
> @@ -436,6 +438,7 @@ int drmModeMoveCursor(int fd, uint32_t crtcId, int x, int
> y)
> {
> struct drm_mode_cursor arg;
>
> + memclear(arg);
> arg.flags = DRM_MODE_CURSOR_MOVE;
> arg.crtc_id = crtcId;
> arg.x = x;
> @@ -452,11 +455,8 @@ drmModeEncoderPtr drmModeGetEncoder(int fd, uint32_t
> encoder_id)
> struct drm_mode_get_encoder enc;
> drmModeEncoderPtr r = NULL;
>
> + memclear(enc);
> enc.encoder_id = encoder_id;
> - enc.crtc_id = 0;
> - enc.encoder_type = 0;
> - enc.possible_crtcs = 0;
> - enc.possible_clones = 0;
>
> if (drmIoctl(fd, DRM_IOCTL_MODE_GETENCODER, &enc))
> return 0;
> @@ -483,7 +483,7 @@ drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t
> connector_id)
> drmModeConnectorPtr r = NULL;
>
> retry:
> - memset(&conn, 0, sizeof(struct drm_mode_get_connector));
> + memclear(conn);
> conn.connector_id = connector_id;
>
> if (drmIoctl(fd, DRM_IOCTL_MODE_GETCONNECTOR, &conn))
> @@ -576,6 +576,7
Re: [Intel-gfx] PCH fifo underrun in 3.18
Under what product should I submit the bug? dmr.debug=14 doesn't show much. [jon@localhost]~% dmesg | grep drm [1.936241] [drm] Initialized drm 1.1.0 20060810 [2.193043] [drm] Memory usable by graphics device = 2048M [2.193046] [drm] Replacing VGA console driver [2.18] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [2.20] [drm] Driver supports precise vblank timestamp query. [2.287949] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 [2.297614] fbcon: inteldrmfb (fb0) is primary device [2.576664] [drm:cpt_set_fifo_underrun_reporting] *ERROR* uncleared pch fifo underrun on pch transcoder A [2.57] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO underrun Jon On 02/08/2015 11:18 PM, Jani Nikula wrote: On Fri, 30 Jan 2015, jon wrote: Just updated my thinkpad (x230, ivy bridge platform) to 3.18 and boot fails with the error 'PCH fifo underrun'. This is under fedora 21 with the fedora kernel version 3.18.3-201 Please file a bug on [1], attach a dmesg from boot to the problem with drm.debug=14 module parameter set. Reference this thread. Thanks, Jani. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel -- Jon ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] xf86drm: Unconditionally clear ioctl structs
On Wed, 2015-02-11 at 12:42 +0100, Daniel Vetter wrote:
> We really have to do this to avoid surprises when extending the ABI
> later on. Especially when growing the structures.
>
> A bit overkill to update all the old legacy ioctl wrappers, but can't
> hurt really either.
>
> Signed-off-by: Daniel Vetter
> ---
> xf86drm.c | 112
> ++
> 1 file changed, 77 insertions(+), 35 deletions(-)
>
> diff --git a/xf86drm.c b/xf86drm.c
> index 263d6835c29a..a2e24eb5f76c 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -89,6 +89,8 @@
> #define DRM_NODE_PRIMARY 1
> #define DRM_NODE_RENDER 2
>
> +#define memclear(s) memset(&s, 0, sizeof(s))
> +
> static drmServerInfoPtr drm_server_info;
>
> void drmSetServerInfo(drmServerInfoPtr info)
> @@ -766,12 +768,7 @@ drmVersionPtr drmGetVersion(int fd)
> drmVersionPtr retval;
> drm_version_t *version = drmMalloc(sizeof(*version));
>
> -version->name_len= 0;
> -version->name= NULL;
> -version->date_len= 0;
> -version->date= NULL;
> -version->desc_len= 0;
> -version->desc= NULL;
> +memclear(version);
I think this should be memclear(*version).
Otherwise it clears the pointer not the structure.
>
> if (drmIoctl(fd, DRM_IOCTL_VERSION, version)) {
> drmFreeKernelVersion(version);
> @@ -839,9 +836,12 @@ drmVersionPtr drmGetLibVersion(int fd)
>
> int drmGetCap(int fd, uint64_t capability, uint64_t *value)
> {
> - struct drm_get_cap cap = { capability, 0 };
> + struct drm_get_cap cap;
> int ret;
>
> + memclear(cap);
> + cap.capability = capability;
> +
> ret = drmIoctl(fd, DRM_IOCTL_GET_CAP, &cap);
> if (ret)
> return ret;
> @@ -852,7 +852,11 @@ int drmGetCap(int fd, uint64_t capability, uint64_t
> *value)
>
> int drmSetClientCap(int fd, uint64_t capability, uint64_t value)
> {
> - struct drm_set_client_cap cap = { capability, value };
> + struct drm_set_client_cap cap;
> +
> + memclear(cap);
> + cap.capability = capability;
> + cap.value = value;
>
> return drmIoctl(fd, DRM_IOCTL_SET_CLIENT_CAP, &cap);
> }
> @@ -887,8 +891,7 @@ char *drmGetBusid(int fd)
> {
> drm_unique_t u;
>
> -u.unique_len = 0;
> -u.unique = NULL;
> +memclear(u);
>
> if (drmIoctl(fd, DRM_IOCTL_GET_UNIQUE, &u))
> return NULL;
> @@ -917,6 +920,7 @@ int drmSetBusid(int fd, const char *busid)
> {
> drm_unique_t u;
>
> +memclear(u);
> u.unique = (char *)busid;
> u.unique_len = strlen(busid);
>
> @@ -930,6 +934,8 @@ int drmGetMagic(int fd, drm_magic_t * magic)
> {
> drm_auth_t auth;
>
> +memclear(auth);
> +
> *magic = 0;
> if (drmIoctl(fd, DRM_IOCTL_GET_MAGIC, &auth))
> return -errno;
> @@ -941,6 +947,7 @@ int drmAuthMagic(int fd, drm_magic_t magic)
> {
> drm_auth_t auth;
>
> +memclear(auth);
> auth.magic = magic;
> if (drmIoctl(fd, DRM_IOCTL_AUTH_MAGIC, &auth))
> return -errno;
> @@ -1002,9 +1009,9 @@ int drmAddMap(int fd, drm_handle_t offset, drmSize
> size, drmMapType type,
> {
> drm_map_t map;
>
> +memclear(map);
> map.offset = offset;
> map.size= size;
> -map.handle = 0;
> map.type= type;
> map.flags = flags;
> if (drmIoctl(fd, DRM_IOCTL_ADD_MAP, &map))
> @@ -1018,6 +1025,7 @@ int drmRmMap(int fd, drm_handle_t handle)
> {
> drm_map_t map;
>
> +memclear(map);
> map.handle = (void *)(uintptr_t)handle;
>
> if(drmIoctl(fd, DRM_IOCTL_RM_MAP, &map))
> @@ -1046,10 +1054,9 @@ int drmAddBufs(int fd, int count, int size,
> drmBufDescFlags flags,
> {
> drm_buf_desc_t request;
>
> +memclear(request);
> request.count = count;
> request.size = size;
> -request.low_mark = 0;
> -request.high_mark = 0;
> request.flags = flags;
> request.agp_start = agp_offset;
>
> @@ -1063,8 +1070,7 @@ int drmMarkBufs(int fd, double low, double high)
> drm_buf_info_t info;
> inti;
>
> -info.count = 0;
> -info.list = NULL;
> +memclear(info);
>
> if (drmIoctl(fd, DRM_IOCTL_INFO_BUFS, &info))
> return -EINVAL;
> @@ -1114,6 +1120,7 @@ int drmFreeBufs(int fd, int count, int *list)
> {
> drm_buf_free_t request;
>
> +memclear(request);
> request.count = count;
> request.list = list;
> if (drmIoctl(fd, DRM_IOCTL_FREE_BUFS, &request))
> @@ -1202,8 +1209,7 @@ drmBufInfoPtr drmGetBufInfo(int fd)
> drmBufInfoPtr retval;
> inti;
>
> -info.count = 0;
> -info.list = NULL;
> +memclear(info);
>
> if (drmIoctl(fd, DRM_IOCTL_INFO_BUFS, &info))
> return NULL;
> @@ -1253,9 +1259,7 @@ drmBufMapPtr drmMapBufs(int fd)
> drmBufMapPtr retval;
> int i;
>
> -bufs.count = 0;
> -bufs.list = NULL;
> -bufs.virtual = NULL;
[Intel-gfx] [PATCH 1/1] tools/intel_audio_dump: add support for Skylake
From: "Lu, Han"
This patch adds support for dumping audio registers of Skylake.
Signed-off-by: Lu, Han
diff --git a/tools/intel_audio_dump.c b/tools/intel_audio_dump.c
index 945b136..d447902 100644
--- a/tools/intel_audio_dump.c
+++ b/tools/intel_audio_dump.c
@@ -362,6 +362,21 @@ static const char * const en_mmio_program[] = {
[1] = "Programming by MMIO debug registers",
};
+static const char * const sdi_operate_mode[] = {
+ [0] = "2T mode with sdi data held for 2 bit clocks",
+ [1] = "1T mode with sdi data held for 1 bit clock only",
+};
+
+static const char * const bclk_96mhz[] = {
+ [0] = "iDisplay audio link 96MHz bclk off",
+ [1] = "iDisplay audio link 96MHz bclk on",
+};
+
+static const char * const bclk_48mhz[] = {
+ [0] = "iDisplay audio link 48MHz bclk off",
+ [1] = "iDisplay audio link 48MHz bclk on",
+};
+
static const char * const audio_dp_dip_status[] = {
[0] = "audfc dp fifo full",
[1] = "audfc dp fifo empty",
@@ -1293,6 +1308,7 @@ static void dump_cpt(void)
#define AUD_CNTL_ST_B (AUD_CNTL_ST_A + PIPE_OFS)
#define AUD_CNTL_ST20x0c0
#define AUD_HDMIW_STATUS0x0d4
+#define AUD_FREQ_CNTRL 0x900
/* Audio config registers of Haswell+ */
#define AUD_TCA_CONFIG AUD_CONFIG_A
@@ -1335,6 +1351,20 @@ static void dump_cpt(void)
#define AUD_TCA_M_CTS 0xf44
#define AUD_TCB_M_CTS 0xf54
#define AUD_TCC_M_CTS 0xf64
+#define AUD_HDA_DMA_REG 0xe00
+#define AUD_HDA_LPIB0_REG 0xe04
+#define AUD_HDA_LPIB1_REG 0xe08
+#define AUD_HDA_LPIB2_REG 0xe0c
+#define AUD_HDA_EXTRA_REG 0xe10
+#define AUD_FPGA_CRC_CTL_A 0xf14
+#define AUD_FPGA_CRC_CTL_B 0xf24
+#define AUD_FPGA_CRC_CTL_C 0xf34
+#define AUD_FPGA_CRC_RESULT_A 0xf18
+#define AUD_FPGA_CRC_RESULT_B 0xf28
+#define AUD_FPGA_CRC_RESULT_C 0xf38
+#define AUD_DFT_MVAL_REG0xe20
+#define AUD_DFT_NVAL_REG0xe24
+#define AUD_DFT_LOAD_REG0xe28
/* Common functions to dump audio registers */
#define MAX_PREFIX_SIZE128
@@ -2101,6 +2131,14 @@ static void parse_bdw_audio_chicken_bit_reg(uint32_t
dword)
printf("%s\n", OPNAME(en_mmio_program, BIT(dword, 0)));
}
+static void parse_skl_audio_freq_cntrl_reg(uint32_t dword)
+{
+ printf("\t");
+ printf("%s\n\t", OPNAME(sdi_operate_mode, BIT(dword, 15)));
+ printf("%s\n\t", OPNAME(bclk_96mhz,BIT(dword, 4)));
+ printf("%s\n", OPNAME(bclk_48mhz,BIT(dword, 3)));
+}
+
/* Dump audio registers for Haswell and its successors (eg. Broadwell).
* Their register layout are same in the north display engine.
*/
@@ -2162,6 +2200,8 @@ static void dump_hsw_plus(void)
dump_aud_reg(AUD_TCA_EDID_DATA,"Audio EDID Data Block -
Transcoder A");
dump_aud_reg(AUD_TCB_EDID_DATA,"Audio EDID Data Block -
Transcoder B");
dump_aud_reg(AUD_TCC_EDID_DATA,"Audio EDID Data Block -
Transcoder C");
+ if (IS_SKYLAKE(devid))
+ dump_aud_reg(AUD_FREQ_CNTRL, "Audio BCLK Frequency Control");
dump_aud_reg(AUD_TCA_INFOFR, "Audio Widget Data Island Packet
- Transcoder A");
dump_aud_reg(AUD_TCB_INFOFR, "Audio Widget Data Island Packet
- Transcoder B");
dump_aud_reg(AUD_TCC_INFOFR, "Audio Widget Data Island Packet
- Transcoder C");
@@ -2192,6 +2232,22 @@ static void dump_hsw_plus(void)
dump_aud_reg(AUD_TCA_M_CTS,"Audio M CTS Read Back
Transcoder A");
dump_aud_reg(AUD_TCB_M_CTS,"Audio M CTS Read Back
Transcoder B");
dump_aud_reg(AUD_TCC_M_CTS,"Audio M CTS Read Back
Transcoder C");
+ if (IS_SKYLAKE(devid)) {
+ dump_aud_reg(AUD_HDA_DMA_REG, "Audio HD Audio DMA Control
Register");
+ dump_aud_reg(AUD_HDA_LPIB0_REG, "Audio HD Audio Stream0 Link
Position in Buffer");
+ dump_aud_reg(AUD_HDA_LPIB1_REG, "Audio HD Audio Stream1 Link
Position in Buffer");
+ dump_aud_reg(AUD_HDA_LPIB2_REG, "Audio HD Audio Stream2 Link
Position in Buffer");
+ dump_aud_reg(AUD_HDA_EXTRA_REG, "Audio HD Audio Extra
Register");
+ dump_aud_reg(AUD_FPGA_CRC_CTL_A, "Audio FPGA Pipe A CRC
Control");
+ dump_aud_reg(AUD_FPGA_CRC_CTL_B, "Audio FPGA Pipe B CRC
Control");
+ dump_aud_reg(AUD_FPGA_CRC_CTL_C, "Audio FPGA Pipe C CRC
Control");
+ dump_aud_reg(AUD_FPGA_CRC_RESULT_A, "Audio FPGA Pipe A CRC
Result");
+ dump_aud_reg(AUD_FPGA_CRC_RESULT_B, "Audio FPGA Pipe B CRC
Result");
+ dump_aud_reg(AUD_FPGA_CRC_RESULT_C, "Audio FPGA Pipe C CRC
Result");
+ dump_aud_reg(AUD_DFT_MVAL_REG, "Audio DFT M Value Register");
+ dump_aud_reg(AUD_DFT_NVAL_REG, "Audio DFT N Value Register");
+ dump_aud_reg
Re: [Intel-gfx] PCH fifo underrun in 3.18
On Wed, 11 Feb 2015, jon wrote: > Under what product should I submit the bug? dmr.debug=14 doesn't show much. The link I provided has those filled in. Product DRI, component DRM/Intel. Jani. > > [jon@localhost]~% dmesg | grep drm > [1.936241] [drm] Initialized drm 1.1.0 20060810 > [2.193043] [drm] Memory usable by graphics device = 2048M > [2.193046] [drm] Replacing VGA console driver > [2.18] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [2.20] [drm] Driver supports precise vblank timestamp query. > [2.287949] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to > bit banging on pin 5 > [2.297614] fbcon: inteldrmfb (fb0) is primary device > [2.576664] [drm:cpt_set_fifo_underrun_reporting] *ERROR* uncleared > pch fifo underrun on pch transcoder A > [2.57] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO > underrun > > > Jon > > On 02/08/2015 11:18 PM, Jani Nikula wrote: >> On Fri, 30 Jan 2015, jon wrote: >>> Just updated my thinkpad (x230, ivy bridge platform) to 3.18 and boot >>> fails with the error 'PCH fifo underrun'. This is under fedora 21 with >>> the fedora kernel version 3.18.3-201 >> Please file a bug on [1], attach a dmesg from boot to the problem with >> drm.debug=14 module parameter set. Reference this thread. >> >> Thanks, >> Jani. >> >> [1] >> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel >> > > -- > Jon > -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PCH fifo underrun in 3.18
On Wed, 11 Feb 2015, jon wrote: > Under what product should I submit the bug? dmr.debug=14 doesn't show much. Oh, and drm.debug will be more helpful than dmr.debug. ;) Jani. > > [jon@localhost]~% dmesg | grep drm > [1.936241] [drm] Initialized drm 1.1.0 20060810 > [2.193043] [drm] Memory usable by graphics device = 2048M > [2.193046] [drm] Replacing VGA console driver > [2.18] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [2.20] [drm] Driver supports precise vblank timestamp query. > [2.287949] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to > bit banging on pin 5 > [2.297614] fbcon: inteldrmfb (fb0) is primary device > [2.576664] [drm:cpt_set_fifo_underrun_reporting] *ERROR* uncleared > pch fifo underrun on pch transcoder A > [2.57] [drm:cpt_serr_int_handler] *ERROR* PCH transcoder A FIFO > underrun > > > Jon > > On 02/08/2015 11:18 PM, Jani Nikula wrote: >> On Fri, 30 Jan 2015, jon wrote: >>> Just updated my thinkpad (x230, ivy bridge platform) to 3.18 and boot >>> fails with the error 'PCH fifo underrun'. This is under fedora 21 with >>> the fedora kernel version 3.18.3-201 >> Please file a bug on [1], attach a dmesg from boot to the problem with >> drm.debug=14 module parameter set. Reference this thread. >> >> Thanks, >> Jani. >> >> [1] >> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel >> > > -- > Jon > -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
