[Intel-gfx] i915 driver failure
Hi all, I hope I'm sending this to the correct mailing list (if not, please, suggest a proper one). I'm using kernel 3.17.4 32-bit (custom build) and during boot I got a crash in i915 driver. It happens on the motherboard with old BIOS, newer BIOS version works ok. Anyway, I assume driver shall not crash regardless of BIOS version. Here it is a copy of kernel log: Nov 28 13:47:05 kernel: [0.264801] Non-volatile memory driver v1.3 Nov 28 13:47:05 kernel: [0.264988] [drm] Initialized drm 1.1.0 20060810 Nov 28 13:47:05 kernel: [0.265695] pci :00:00.0: Intel GMA3150 Chipset Nov 28 13:47:05 kernel: [0.265816] pci :00:00.0: detected gtt size: 524288K total, 262144K mappable Nov 28 13:47:05 kernel: [0.265958] pci :00:00.0: detected 8192K stolen memory Nov 28 13:47:05 kernel: [0.266148] [drm] Memory usable by graphics device = 512M Nov 28 13:47:05 kernel: [0.266239] [drm] Replacing VGA console driver Nov 28 13:47:05 kernel: [0.266983] Console: switching to colour dummy device 80x25 Nov 28 13:47:05 kernel: [0.273080] i915 :00:02.0: irq 27 for MSI/MSI-X Nov 28 13:47:05 kernel: [0.273101] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Nov 28 13:47:05 kernel: [0.273112] [drm] Driver supports precise vblank timestamp query. Nov 28 13:47:05 kernel: [0.273252] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem Nov 28 13:47:05 kernel: [0.273578] [drm] Skipping LVDS initialization for Supermicro X7SPA-H Nov 28 13:47:05 kernel: [0.275328] [drm] initialized overlay support Nov 28 13:47:05 kernel: [0.304391] fbcon: inteldrmfb (fb0) is primary device Nov 28 13:47:05 kernel: [0.335118] [ cut here ] Nov 28 13:47:05 kernel: [0.335130] WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/i915/intel_display.c:1218 assert_panel_unlocked+0x8d/0xa0() Nov 28 13:47:05 kernel: [0.335132] panel assertion failure, pipe B regs locked Nov 28 13:47:05 kernel: [0.335135] Modules linked in: Nov 28 13:47:05 kernel: [0.335140] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.17.4-sm1118 #1 Nov 28 13:47:05 kernel: [0.335142] Hardware name: Supermicro X7SPA-H/X7SPA-H, BIOS 1.0 12/31/2009 Nov 28 13:47:05 kernel: [0.335150] 04c2 c14cdf11 f60879a0 c103af9a c15ea970 f60879b8 0001 c15ea398 Nov 28 13:47:05 kernel: [0.335156] 04c2 c130522d c130522d f6378000 00061180 0042 f5858800 c103afe4 Nov 28 13:47:05 kernel: [0.335162] 0009 f60879a0 c15ea970 f60879b8 c130522d c15ea398 04c2 c15ea970 Nov 28 13:47:05 kernel: [0.335163] Call Trace: Nov 28 13:47:05 kernel: [0.335171] [] ? dump_stack+0x3e/0x4e Nov 28 13:47:05 kernel: [0.335177] [] ? warn_slowpath_common+0x7a/0x90 Nov 28 13:47:05 kernel: [0.335182] [] ? assert_panel_unlocked+0x8d/0xa0 Nov 28 13:47:05 kernel: [0.335186] [] ? assert_panel_unlocked+0x8d/0xa0 Nov 28 13:47:05 kernel: [0.335191] [] ? warn_slowpath_fmt+0x34/0x40 Nov 28 13:47:05 kernel: [0.335195] [] ? assert_panel_unlocked+0x8d/0xa0 Nov 28 13:47:05 kernel: [0.335200] [] ? i9xx_crtc_enable+0x24f/0x450 Nov 28 13:47:05 kernel: [0.335204] [] ? __intel_set_mode+0x78b/0x14e0 Nov 28 13:47:05 kernel: [0.335209] [] ? intel_set_mode+0x1e/0x40 Nov 28 13:47:05 kernel: [0.335213] [] ? intel_crtc_set_config+0x86b/0xcb0 Nov 28 13:47:05 kernel: [0.335220] [] ? drm_mode_set_config_internal+0x4a/0xb0 Nov 28 13:47:05 kernel: [0.335225] [] ? restore_fbdev_mode+0xa2/0xd0 Nov 28 13:47:05 kernel: [0.335230] [] ? drm_fb_helper_restore_fbdev_mode_unlocked+0x15/0x30 Nov 28 13:47:05 kernel: [0.335234] [] ? drm_fb_helper_set_par+0x1f/0x60 Nov 28 13:47:05 kernel: [0.335239] [] ? intel_fbdev_set_par+0xd/0x40 Nov 28 13:47:05 kernel: [0.335244] [] ? fbcon_init+0x4ca/0x510 Nov 28 13:47:05 kernel: [0.335249] [] ? kernfs_add_one+0xd8/0x130 Nov 28 13:47:05 kernel: [0.335255] [] ? visual_init+0x96/0xf0 Nov 28 13:47:05 kernel: [0.335259] [] ? do_bind_con_driver+0x106/0x310 Nov 28 13:47:05 kernel: [0.335264] [] ? do_take_over_console+0x106/0x1a0 Nov 28 13:47:05 kernel: [0.335269] [] ? do_fbcon_takeover+0x5f/0xd0 Nov 28 13:47:05 kernel: [0.335274] [] ? notifier_call_chain+0x46/0x60 Nov 28 13:47:05 kernel: [0.335278] [] ? __blocking_notifier_call_chain+0x38/0x50 Nov 28 13:47:05 kernel: [0.335282] [] ? blocking_notifier_call_chain+0x18/0x20 Nov 28 13:47:05 kernel: [0.335287] [] ? register_framebuffer+0x1b2/0x2c0 Nov 28 13:47:05 kernel: [0.335293] [] ? drm_fb_helper_initial_config+0x33c/0x4c0 Nov 28 13:47:05 kernel: [0.335297] [] ? intel_fbdev_init+0x1b7/0x540 Nov 28 13:47:05 kernel: [0.335303] [] ? i915_driver_load+0xf29/0xfb0 Nov 28 13:47:05 kernel: [0.335307] [] ? i915_emit_breadcrumb+0xc0/0xc0 Nov 28 13:47:05 kernel: [0.335311] [] ? usbhid_quirks_exit+0x70/0x70 Nov 28 13:47:05 kernel: [0.335316] [] ? call_usermodehelper_exe
Re: [Intel-gfx] [RFC PATCH v3 1/4] drm/i915: add i915_ved.c to setup bridge for VED
> -Original Message-
> From: Beckett, Robert
> Sent: Saturday, November 29, 2014 0:59
> To: Cheng, Yao; intel-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; daniel.vet...@ffwll.ch; Kelley, Sean V; Chehab,
> John
> Cc: emil.l.veli...@gmail.com; Jiang, Fei; dh.herrm...@gmail.com;
> dan...@fooishbar.org
> Subject: Re: [Intel-gfx] [RFC PATCH v3 1/4] drm/i915: add i915_ved.c to setup
> bridge for VED
> > + * Threats:
> > + * Due to the restriction in Linux platform device model, user need
> > +manually
> > + * uninstall ipvr driver before uninstalling i915 module, otherwise
> > +he might
> > + * run into use-after-free issues after i915 removes the platform device.
>
> Can you go in to more detail on what you consider to be the restriction in the
> platform device model?
>
> When removing the device via platform_device_unregister, it will call the
> remove callback of any drivers handling this device (via the bus remove
> function). It is then up to the driver to ensure no further usage of the
> device
> from which it is being removed. This usually involves removing all user input
> vectors, disabling interrupts involved and flushing/canceling any delayed
> work. This should prevent any further use of the device by the driver.
>
> The driver's remove function is called in a direct call chain from
> platform_device_unregister, so by the time it returns, there should be no
> further chance of accesses.
>
Bob, thx for your review comments.
The symptom is, after "rmmod i915", though drm_drv_release() is also called on
the child device "ipvr", I still see the module exist in the system (check it
by "lsmod"). This causes issue when I modprobe i915 and ipvr again later.
Actually I don't understand why this restriction exists, but accroding to
Daniel, grabbing a module refcount for the platform device doesn't work (it
would pin the module forever).
> > +void vlv_teardown_ved(struct drm_device *dev) {
> > + struct drm_i915_private *dev_priv = dev->dev_private;
>
> you may want to mask the i915 interrupt for the VED block before removing
> the device.
>
Thx, will add it.
> > + vlv_ved_platdev_destroy(dev);
> > + if (dev_priv->ved.irq >= 0)
> > + irq_free_desc(dev_priv->ved.irq);
> > +}
> >
>
>
> Generally it is a nicely interfaced child device.
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support
> -Original Message- > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Monday, November 24, 2014 21:15 > To: Thierry Reding > Cc: Daniel Vetter; Cheng, Yao; intel-gfx@lists.freedesktop.org; dri- > de...@lists.freedesktop.org; daniel.vet...@ffwll.ch; Kelley, Sean V; Chehab, > John; emil.l.veli...@gmail.com; Jiang, Fei > Subject: Re: [RFC PATCH v3 4/4] tests/drv_module_reload: add ipvr support > > On Mon, Nov 24, 2014 at 10:55:46AM +0100, Thierry Reding wrote: > > On Fri, Nov 21, 2014 at 09:36:33PM +0100, Daniel Vetter wrote: > > > On Fri, Nov 21, 2014 at 09:27:04PM +0100, Thierry Reding wrote: > > > > On Sat, Nov 22, 2014 at 03:10:01AM +0800, Yao Cheng wrote: > > > > > on vlv, if ipvr is installed, it need be manually unloaded > > > > > before i915, otherwise user might run into use-after-free issue. > > > > > > > > Huh? That doesn't sound right. What exactly is it that's going wrong? > > > > You should never have to do this. If you do you're almost > > > > certainly doing something wrong in the kernel module. > > > > > > It's the hilarity called platform devices. Removing them is somewhat > > > racy, so doing that upfront makes the entire thing a bit safer. The > > > use after free is on the text, since grabbing a module refcount for > > > the platform device doesn't work (it would pin the module forever). > > > > I don't understand what the issue is here. I've used platform devices > > quite extensively on ARM and I've never encountered a situation where > > they were insufficient (or racy for that matter). > > > > If I understand correctly what this commit tries to achieve, then it > > unloads one module before another module that it depends on so that > > the dependency can be removed subsequently without causing a crash. > > That sounds really brittle to me. How are you going to document this > > for users so that they don't accidentally go and unload the i915 > > module and crash their system? > > Module unloading taints your kernel and isn't an end-user supported feature. > That simple ;-) > > Also afaik the problem is that you actually can't unload i915 until you've > unloaded the subordinate driver, since i915 registering the platform driver > prevents unload. Or at least that was my understanding, I didn't test this > myself. I just asked whether the unload script still works and apparently it > breaks. > > I guess what's different with ARM is that DT creates all the platform devices, > and not modules themselves? > -Daniel Thierry/Daniel, the actual symptom is, after "rmmod i915", though drm_drv_release() is also called on the child device "ipvr", I still see the module exist in the system (check it by "lsmod"). This causes issue when I modprobe i915 and ipvr again later. I don't understand why this happens but I believe what Daniel said: "grabbing a module refcount for the platform device doesn't work (it would pin the module forever)". > -- > 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] [RFC PATCH v3 2/4] drm/ipvr: drm driver for VED
Add Jon/Bob/Raf for detail review.
> -Original Message-
> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> Of Cheng, Yao
> Sent: Thursday, November 27, 2014 19:49
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; Kelley, Sean V; Chehab, John
> Cc: emil.l.veli...@gmail.com; Jiang, Fei
> Subject: RE: [RFC PATCH v3 2/4] drm/ipvr: drm driver for VED
>
> > -Original Message-
> > From: Cheng, Yao
> > Sent: Saturday, November 22, 2014 3:07
> > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> > daniel.vet...@ffwll.ch; Kelley, Sean V; Chehab, John
> > Cc: Jiang, Fei; dh.herrm...@gmail.com; jani.nik...@linux.intel.com;
> > emil.l.veli...@gmail.com; ville.syrj...@linux.intel.com;
> > jbar...@virtuousgeek.org; dan...@fooishbar.org; Cheng, Yao
> > Subject: [RFC PATCH v3 2/4] drm/ipvr: drm driver for VED
> > +typedef struct drm_ipvr_private {
> > + struct drm_device *dev;
> > + struct pci_dev *pci_root;
> > +
> > + /* IMG video context */
> > + struct list_head ipvr_ctx_list;
>
> The current design leads to ctx leak. There's no ctx_list for each file
> struct, so
> each create_context_ioctl causes one ctx leak.
> Need to move the ctx_list from dev_private to file_private.
>
> > + spinlock_t ipvr_ctx_lock;
> > + struct idr ipvr_ctx_idr;
> > + struct ipvr_context default_ctx;
> > +
> > + /* PM related */
> > + atomic_t pending_events;
> > +
> > + /* exec related */
> > + struct ipvr_validate_context validate_ctx;
> > +
> > + /* IMG MMU specific */
> > + struct ipvr_mmu_driver *mmu;
> > + /*struct ipvr_mmu_pd *pf_pd;*/
> > + atomic_t ipvr_mmu_invaldc;
> > +
> > + /* GEM mm related */
> > + struct ipvr_gem_stat ipvr_stat;
> > + struct kmem_cache *ipvr_bo_slab;
> > + struct ipvr_address_space addr_space;
> > +
> > + /* fence related */
> > + u32 last_seq;
> > + wait_queue_head_t fence_queue;
> > + struct ipvr_fence_driver fence_drv;
> > +
> > + /* MMIO window shared from parent device */
> > + u8 __iomem* reg_base;
> > +
> > + /*
> > +* VED specific
> > +*/
> > + struct ved_private *ved_private;
> > +}drm_ipvr_private_t;
> ___
> 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
Re: [Intel-gfx] [RFC PATCH v3 3/4] ipvr: user mode helper for ipvr drm driver
Add Jon/Bob/Raf for detail review. > -Original Message- > From: Cheng, Yao > Sent: Saturday, November 22, 2014 3:09 > To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; > daniel.vet...@ffwll.ch; Kelley, Sean V; Chehab, John > Cc: Jiang, Fei; dh.herrm...@gmail.com; jani.nik...@linux.intel.com; > emil.l.veli...@gmail.com; ville.syrj...@linux.intel.com; > jbar...@virtuousgeek.org; dan...@fooishbar.org; Cheng, Yao > Subject: [RFC PATCH v3 3/4] ipvr: user mode helper for ipvr drm driver > > add usermode helper for the ipvr kernel driver. > test_ioctl: test kernel driver by directly ioctl > > v2: > take Emil's comments > - correctly align ipvr_drm.h > > v3: > take Daniel Vetter and Daniel Stone's comments, and implement PRIME > - correctly align ipvr_drm.h > - use __u32 family in ipvr_drm.h > - rip out explicit fence from libdrm_ipvr > - implemented PRIME support > - add relocation fixup implementation > > Signed-off-by: Yao Cheng > --- > Makefile.am|6 +- > Makefile.sources |1 + > configure.ac | 26 +- > include/drm/ipvr_drm.h | 278 +++ > ipvr/Makefile.am | 57 +++ > ipvr/Makefile.sources |5 + > ipvr/ipvr_bufmgr.h | 149 ++ > ipvr/ipvr_bufmgr_gem.c | 1200 > > ipvr/libdrm_ipvr.pc.in | 11 + > ipvr/test_ioctl.c | 423 + > 10 files changed, 2154 insertions(+), 2 deletions(-) > create mode 100644 include/drm/ipvr_drm.h > create mode 100644 ipvr/Makefile.am > create mode 100644 ipvr/Makefile.sources > create mode 100644 ipvr/ipvr_bufmgr.h > create mode 100644 ipvr/ipvr_bufmgr_gem.c > create mode 100644 ipvr/libdrm_ipvr.pc.in > create mode 100644 ipvr/test_ioctl.c > > diff --git a/Makefile.am b/Makefile.am > index 3952a88..2227add 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -33,6 +33,10 @@ if HAVE_INTEL > INTEL_SUBDIR = intel > endif > > +if HAVE_IPVR > +IPVR_SUBDIR = ipvr > +endif > + > if HAVE_NOUVEAU > NOUVEAU_SUBDIR = nouveau > endif > @@ -53,7 +57,7 @@ if HAVE_FREEDRENO > FREEDRENO_SUBDIR = freedreno > endif > > -SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(NOUVEAU_SUBDIR) > $(RADEON_SUBDIR) $(OMAP_SUBDIR) $(EXYNOS_SUBDIR) > $(FREEDRENO_SUBDIR) tests man > +SUBDIRS = . $(LIBKMS_SUBDIR) $(INTEL_SUBDIR) $(IPVR_SUBDIR) > $(NOUVEAU_SUBDIR) $(RADEON_SUBDIR) $(OMAP_SUBDIR) > $(EXYNOS_SUBDIR) $(FREEDRENO_SUBDIR) tests man > > libdrm_la_LTLIBRARIES = libdrm.la > libdrm_ladir = $(libdir) > diff --git a/Makefile.sources b/Makefile.sources > index d86fb2a..96f8c60 100644 > --- a/Makefile.sources > +++ b/Makefile.sources > @@ -18,6 +18,7 @@ LIBDRM_INCLUDE_H_FILES := \ > include/drm/drm_mode.h \ > include/drm/drm_sarea.h \ > include/drm/i915_drm.h \ > + include/drm/ipvr_drm.h \ > include/drm/mach64_drm.h \ > include/drm/mga_drm.h \ > include/drm/nouveau_drm.h \ > diff --git a/configure.ac b/configure.ac > index ee59b03..6dcf1b2 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -68,6 +68,11 @@ AC_ARG_ENABLE(intel, > [Enable support for intel's KMS API (default: auto)]), > [INTEL=$enableval], [INTEL=auto]) > > +AC_ARG_ENABLE(ipvr, > + AS_HELP_STRING([--disable-ipvr], > + [Enable support for baytrail's hardware VP8 decode (default: > auto)]), > + [IPVR=$enableval], [IPVR=auto]) > + > AC_ARG_ENABLE(radeon, > AS_HELP_STRING([--disable-radeon], > [Enable support for radeon's KMS API (default: auto)]), > @@ -204,7 +209,7 @@ if test "x$drm_cv_atomic_primitives" = "xlibatomic- > ops"; then > AC_DEFINE(HAVE_LIB_ATOMIC_OPS, 1, [Enable if you have > libatomic-ops-dev installed]) > fi > > -if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o "x$NOUVEAU" != > "xno"; then > +if test "x$INTEL" != "xno" -o "x$IPVR" != "xno" -o "x$RADEON" != "xno" -o > "x$NOUVEAU" != "xno"; then > if test "x$drm_cv_atomic_primitives" = "xnone"; then > if test "x$INTEL" != "xauto"; then > if test "x$INTEL" != "xno"; then > @@ -214,6 +219,14 @@ if test "x$INTEL" != "xno" -o "x$RADEON" != "xno" -o > "x$NOUVEAU" != "xno"; then > AC_MSG_WARN([Disabling libdrm_intel. It depends > on atomic operations, which were not found for your compiler/cpu. Try > compiling with -march=native, or install the libatomics-op-dev package.]) > INTEL=no > fi > + if test "x$IPVR" != "xauto"; then > + if test "x$IPVR" != "xno"; then > + AC_MSG_ERROR([libdrm_ipvr depends upon > atomic operations, which were not found for your compiler/cpu. Try > compiling with -march=native, or install the libatomics-op-dev package, or, > failing both of those, disable support for Baytrail VP8 by passing > --disable-ipvr > to ./configure]) > + fi > +
[Intel-gfx] [PATCH v1 1/2] drm/i915: Enabling RC6 immediately instead of enabling via delayed work item
From: Sagar Kamble
RC6 was getting enabled through deferred work item which was scheduled
after 1s. This will keep render and media well ON for 1s. Since RC6 enabling
does
not involve PCU communication, processing time in intel_enable_gt_powersave will
not be increased. Enabling RC6 immediately will help power gate render and media
well immediately that will save power.
Signed-off-by: Akash Goel
Signed-off-by: Sagar Kamble
---
drivers/gpu/drm/i915/intel_pm.c | 88 -
1 file changed, 61 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9af0af4..1fb3084 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -5276,11 +5276,11 @@ static void valleyview_cleanup_gt_powersave(struct
drm_device *dev)
valleyview_cleanup_pctx(dev);
}
-static void cherryview_enable_rps(struct drm_device *dev)
+static void cherryview_enable_rc6(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *ring;
- u32 gtfifodbg, val, rc6_mode = 0, pcbr;
+ u32 gtfifodbg, rc6_mode = 0, pcbr;
int i;
WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
@@ -5294,10 +5294,10 @@ static void cherryview_enable_rps(struct drm_device
*dev)
cherryview_check_pctx(dev_priv);
- /* 1a & 1b: Get forcewake during program sequence. Although the driver
-* hasn't enabled a state yet where we need forcewake, BIOS may have.*/
- gen6_gt_force_wake_get(dev_priv, FORCEWAKE_ALL);
-
+ /*
+* Assuming RC6 disabled by uncore_sanitize we dont need to do
+* force wake get/put here.
+*/
/* 2a: Program RC6 thresholds.*/
I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 40 << 16);
I915_WRITE(GEN6_RC_EVALUATION_INTERVAL, 125000); /* 12500 * 1280ns */
@@ -5324,6 +5324,18 @@ static void cherryview_enable_rps(struct drm_device *dev)
rc6_mode = GEN6_RC_CTL_EI_MODE(1);
I915_WRITE(GEN6_RC_CONTROL, rc6_mode);
+}
+
+static void cherryview_enable_rps(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 val;
+
+ WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
+
+ /* 1a & 1b: Get forcewake during program sequence. Although the driver
+* hasn't enabled a state yet where we need forcewake, BIOS may have.*/
+ gen6_gt_force_wake_get(dev_priv, FORCEWAKE_ALL);
/* 4 Program defaults and thresholds for RPS*/
I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
@@ -5367,11 +5379,11 @@ static void cherryview_enable_rps(struct drm_device
*dev)
gen6_gt_force_wake_put(dev_priv, FORCEWAKE_ALL);
}
-static void valleyview_enable_rps(struct drm_device *dev)
+static void valleyview_enable_rc6(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *ring;
- u32 gtfifodbg, val, rc6_mode = 0;
+ u32 gtfifodbg, rc6_mode = 0;
int i;
WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
@@ -5384,25 +5396,10 @@ static void valleyview_enable_rps(struct drm_device
*dev)
I915_WRITE(GTFIFODBG, gtfifodbg);
}
- /* If VLV, Forcewake all wells, else re-direct to regular path */
- gen6_gt_force_wake_get(dev_priv, FORCEWAKE_ALL);
-
- I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
- I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 245000);
- I915_WRITE(GEN6_RP_UP_EI, 66000);
- I915_WRITE(GEN6_RP_DOWN_EI, 35);
-
- I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
- I915_WRITE(GEN6_RP_DOWN_TIMEOUT, 0xf4240);
-
- I915_WRITE(GEN6_RP_CONTROL,
- GEN6_RP_MEDIA_TURBO |
- GEN6_RP_MEDIA_HW_NORMAL_MODE |
- GEN6_RP_MEDIA_IS_GFX |
- GEN6_RP_ENABLE |
- GEN6_RP_UP_BUSY_AVG |
- GEN6_RP_DOWN_IDLE_CONT);
-
+ /*
+* Assuming RC6 disabled by uncore_sanitize we dont need to do
+* force wake get/put here.
+*/
I915_WRITE(GEN6_RC6_WAKE_RATE_LIMIT, 0x0028);
I915_WRITE(GEN6_RC_EVALUATION_INTERVAL, 125000);
I915_WRITE(GEN6_RC_IDLE_HYSTERSIS, 25);
@@ -5425,6 +5422,32 @@ static void valleyview_enable_rps(struct drm_device *dev)
intel_print_rc6_info(dev, rc6_mode);
I915_WRITE(GEN6_RC_CONTROL, rc6_mode);
+}
+
+static void valleyview_enable_rps(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ u32 val;
+
+ WARN_ON(!mutex_is_locked(&dev_priv->rps.hw_lock));
+
+ gen6_gt_force_wake_get(dev_priv, FORCEWAKE_ALL);
+
+ I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
+ I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 245000);
+ I915_WRITE(GEN6_RP_UP_EI, 66000);
+ I915_WRITE(GEN6_RP_DOWN_EI, 35);
+
+ I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
+
[Intel-gfx] [PATCH v1 2/2] drm/i915: Deferring uncore early sanitize, sanitize, disable pc8 to resume
From: Sagar Kamble
Due to disabling of RC6 in uncore_sanitize in early resume, power is drained
till it RC6 is re-enabled post resume.
With this change RC6 disabling will be done at beginning of resume only.
This helps yield additional power benefits.
Signed-off-by: Akash Goel
Signed-off-by: Sagar Kamble
---
drivers/gpu/drm/i915/i915_drv.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 71be3c9..0e08ec0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -675,6 +675,13 @@ static int i915_drm_resume(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
+ intel_uncore_early_sanitize(dev, true);
+
+ if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
+ hsw_disable_pc8(dev_priv);
+
+ intel_uncore_sanitize(dev);
+
if (drm_core_check_feature(dev, DRIVER_MODESET)) {
mutex_lock(&dev->struct_mutex);
i915_gem_restore_gtt_mappings(dev);
@@ -761,12 +768,6 @@ static int i915_drm_resume_early(struct drm_device *dev)
if (ret)
DRM_ERROR("Resume prepare failed: %d,Continuing resume\n", ret);
- intel_uncore_early_sanitize(dev, true);
-
- if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv))
- hsw_disable_pc8(dev_priv);
-
- intel_uncore_sanitize(dev);
intel_power_domains_init_hw(dev_priv);
return ret;
--
1.8.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v1 1/1] drm/i915: Perform modeset based on DPMS state during resume
From: Akash Goel
During resume, modeset was being performed independent of DPMS state which
increased resume time as well as it kept display wells ON. With this change
this modeset will be skipped.
Signed-off-by: Akash Goel
Signed-off-by: Sagar Kamble
---
drivers/gpu/drm/i915/i915_drv.c | 33 ++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 71be3c9..919e552 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -671,6 +671,31 @@ int i915_suspend_legacy(struct drm_device *dev,
pm_message_t state)
return i915_drm_suspend_late(dev);
}
+static bool display_is_on(struct drm_device *dev)
+{
+ struct drm_connector *connector;
+ bool display_is_on = false;
+
+ drm_modeset_lock_all(dev);
+ list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
+ if (!connector->encoder || !connector->encoder->crtc)
+ continue;
+ /*
+* If Display wasn't turned off, before going to suspend then
+* it should be re-enabled now, as we don't expect the DPMS ON
+* call to come in that case
+*/
+ if (connector->dpms != DRM_MODE_DPMS_OFF) {
+ DRM_DEBUG_KMS("Display was on before suspend\n");
+ display_is_on = true;
+ break;
+ }
+ }
+ drm_modeset_unlock_all(dev);
+
+ return display_is_on;
+}
+
static int i915_drm_resume(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -707,9 +732,11 @@ static int i915_drm_resume(struct drm_device *dev)
spin_unlock_irq(&dev_priv->irq_lock);
intel_dp_mst_resume(dev);
- drm_modeset_lock_all(dev);
- intel_modeset_setup_hw_state(dev, true);
- drm_modeset_unlock_all(dev);
+ if (display_is_on(dev)) {
+ drm_modeset_lock_all(dev);
+ intel_modeset_setup_hw_state(dev, true);
+ drm_modeset_unlock_all(dev);
+ }
/*
* ... but also need to make sure that hotplug processing
--
1.8.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1 1/1] drm/i915: Perform modeset based on DPMS state during resume
On Mon, 2014-12-01 at 12:29 +0530, sagar.a.kam...@intel.com wrote:
> From: Akash Goel
>
> During resume, modeset was being performed independent of DPMS state which
> increased resume time as well as it kept display wells ON. With this change
> this modeset will be skipped.
>
> Signed-off-by: Akash Goel
> Signed-off-by: Sagar Kamble
> ---
> drivers/gpu/drm/i915/i915_drv.c | 33 ++---
> 1 file changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 71be3c9..919e552 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -671,6 +671,31 @@ int i915_suspend_legacy(struct drm_device *dev,
> pm_message_t state)
> return i915_drm_suspend_late(dev);
> }
>
> +static bool display_is_on(struct drm_device *dev)
> +{
> + struct drm_connector *connector;
> + bool display_is_on = false;
> +
> + drm_modeset_lock_all(dev);
> + list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> + if (!connector->encoder || !connector->encoder->crtc)
> + continue;
> + /*
> + * If Display wasn't turned off, before going to suspend then
> + * it should be re-enabled now, as we don't expect the DPMS ON
> + * call to come in that case
> + */
> + if (connector->dpms != DRM_MODE_DPMS_OFF) {
> + DRM_DEBUG_KMS("Display was on before suspend\n");
> + display_is_on = true;
> + break;
> + }
> + }
> + drm_modeset_unlock_all(dev);
> +
> + return display_is_on;
> +}
> +
> static int i915_drm_resume(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -707,9 +732,11 @@ static int i915_drm_resume(struct drm_device *dev)
> spin_unlock_irq(&dev_priv->irq_lock);
>
> intel_dp_mst_resume(dev);
> - drm_modeset_lock_all(dev);
> - intel_modeset_setup_hw_state(dev, true);
> - drm_modeset_unlock_all(dev);
> + if (display_is_on(dev)) {
> + drm_modeset_lock_all(dev);
> + intel_modeset_setup_hw_state(dev, true);
> + drm_modeset_unlock_all(dev);
> + }
Need an additional change here, call to
'intel_display_set_init_power(dev_priv, false);'
is also required at the end of i915_drm_resume function.
This will put the Display wells back into D3 state before
the runtime suspend is triggered, which could happen immediately,
as call to modeset was skipped.
Best Regards
Akash
> /*
>* ... but also need to make sure that hotplug processing
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1 1/1] drm/i915: Perform modeset based on DPMS state during resume
On Mon, Dec 01, 2014 at 12:29:34PM +0530, sagar.a.kam...@intel.com wrote:
> From: Akash Goel
>
> During resume, modeset was being performed independent of DPMS state which
> increased resume time as well as it kept display wells ON. With this change
> this modeset will be skipped.
>
> Signed-off-by: Akash Goel
> Signed-off-by: Sagar Kamble
> ---
> drivers/gpu/drm/i915/i915_drv.c | 33 ++---
> 1 file changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 71be3c9..919e552 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -671,6 +671,31 @@ int i915_suspend_legacy(struct drm_device *dev,
> pm_message_t state)
> return i915_drm_suspend_late(dev);
> }
>
> +static bool display_is_on(struct drm_device *dev)
> +{
> + struct drm_connector *connector;
> + bool display_is_on = false;
> +
> + drm_modeset_lock_all(dev);
> + list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
> + if (!connector->encoder || !connector->encoder->crtc)
> + continue;
> + /*
> + * If Display wasn't turned off, before going to suspend then
> + * it should be re-enabled now, as we don't expect the DPMS ON
> + * call to come in that case
> + */
> + if (connector->dpms != DRM_MODE_DPMS_OFF) {
> + DRM_DEBUG_KMS("Display was on before suspend\n");
> + display_is_on = true;
> + break;
> + }
> + }
> + drm_modeset_unlock_all(dev);
> +
> + return display_is_on;
> +}
> +
> static int i915_drm_resume(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -707,9 +732,11 @@ static int i915_drm_resume(struct drm_device *dev)
> spin_unlock_irq(&dev_priv->irq_lock);
>
> intel_dp_mst_resume(dev);
> - drm_modeset_lock_all(dev);
> - intel_modeset_setup_hw_state(dev, true);
I thought it was meant to be setup_hw_state(force=false) here and then
we use the hotplug event to reconfigure?
You cannot simply skip setup_hw_state() as we need to detect and adjust
for whatever changes happened to the hardware whilst we slept.
-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
