Re: [Intel-gfx] [PATCH 16/26] drm/i915: turbo RC6 support for VLV
-Original Message-
From: intel-gfx-bounces+rohit.jain=intel@lists.freedesktop.org
[mailto:intel-gfx-bounces+rohit.jain=intel@lists.freedesktop.org]
On Behalf Of Jesse Barnes
Sent: Friday, March 08, 2013 3:58 AM
To: Rohit Jain
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH 16/26] drm/i915: turbo RC6 support
for VLV
On Wed, 6 Mar 2013 16:21:03 +0530 (IST)
Rohit Jain ro...@intel.com wrote:
On Sat, 2 Mar 2013, Jesse Barnes wrote:
From: Ben Widawsky b...@bwidawsk.net
Uses slightly different interfaces than other platforms.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_pm.c | 148
+--
1 file changed, 144 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c index e3947cb..d16f4f40 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2477,6 +2477,47 @@ void gen6_set_rps(struct drm_device *dev, u8
val)
trace_intel_gpu_freq_change(val * 50); }
+void valleyview_set_rps(struct drm_device *dev, u8 val) {
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ unsigned long timeout = jiffies + msecs_to_jiffies(100);
+ u32 limits = gen6_rps_limits(dev_priv, val);
+ u32 pval;
+
+ WARN_ON(!mutex_is_locked(dev_priv-rps.hw_lock));
+ WARN_ON(val dev_priv-rps.max_delay);
+ WARN_ON(val dev_priv-rps.min_delay);
+
+ if (val == dev_priv-rps.cur_delay)
+ return;
+
+ valleyview_punit_write(dev_priv, PUNIT_REG_GPU_FREQ_REQ, val);
+
+ do {
+ valleyview_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS,
pval);
+ if (time_after(jiffies, timeout)) {
+ DRM_DEBUG_DRIVER(timed out waiting for Punit\n);
+ break;
+ }
+ udelay(10);
+ } while (pval 1);
+
+ valleyview_punit_read(dev_priv, PUNIT_REG_GPU_FREQ_STS, pval);
+ if ((pval 8) != val)
+ DRM_DEBUG_DRIVER(punit overrode freq: %d requested, but
got %d\n,
+ val, pval 8);
+
+ /* Make sure we continue to get interrupts
+ * until we hit the minimum or maximum frequencies.
+ */
+ I915_WRITE(GEN6_RP_INTERRUPT_LIMITS, limits);
+
+ dev_priv-rps.cur_delay = val;
Shouldn't we store pval 8 instead of val in cur_delay in order to
reclaim the rps state? If we store val here, the requested frequency
will eventually exceed max_delay if punit overrides with a lower
frequency.
Yeah we should track the current freq here instead. But we clamp to
max_delay in the caller right? And yeah I missed the update to
i915_irq.c, I fixed that too.
Cool! On my board, max_delay gets set to 255 while the punit refuses to go
above 222 in practice. In this case, before we can clamp to max_delay, cur_delay
overflows and gets set to min_delay instead :)
Fixing it like this solves this problem neatly.
Cheers,
Rohit
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 black screen introduced by ACPI changes
On Tue, 05 Mar 2013, Chris Li l...@chrisli.org wrote: On Mon, Mar 4, 2013 at 3:16 PM, Chris Li l...@chrisli.org wrote: Two things to test: - Can you please check whether any of the backlight drivers in /sys/class/backlight does anything? You need to frob the brightness file. Please also list all the drivers you have. This is the kernel with the ACPI change causing the black screen. lrwxrwxrwx. 1 root root 0 Mar 4 15:20 acpi_video0 - ../../devices/pci:00/:00:01.0/:01:00.0/backlight/acpi_video0 lrwxrwxrwx. 1 root root 0 Mar 4 15:20 acpi_video1 - ../../devices/pci:00/:00:02.0/backlight/acpi_video1 lrwxrwxrwx. 1 root root 0 Mar 4 15:20 intel_backlight - ../../devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1/intel_backlight Here is the interesting part. The brightness and max_brightness is all set to 4648, However, the actual brightness is 0. The bl_power is also 0. I think you are on to some thing. Hi Chris - Interesting snippets from your dmesgs: 1) good [0.00] Linux version 3.6.0-rc6+ (chr...@ideapad.lan) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #25 SMP Wed Feb 20 12:55:06 PST 2013 ... [5.341431] [drm:intel_panel_get_max_backlight], max backlight PWM = 4648 [5.341442] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4648 [5.342572] [drm:intel_panel_get_max_backlight], max backlight PWM = 4648 [5.342578] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4648 2) bad [0.00] Linux version 3.8.0-rc7+ (chr...@ideapad.lan) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #23 SMP Tue Feb 19 19:24:57 PST 2013 ... [5.692853] [drm:asle_set_backlight], bclp = 0x80ff [5.692865] [drm:intel_panel_get_max_backlight], max backlight PWM = 4648 [5.692870] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4648 [5.693401] [drm:asle_set_backlight], bclp = 0x8000 [5.693408] [drm:intel_panel_get_max_backlight], max backlight PWM = 4648 [5.693413] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0 (We've added another debug print to asle_set_backlight.) For some reason we get two asle requests in a row. In the good kernel it's the same request twice, in the bad kernel the second requests is for 0 backlight. The register dumps seem to confirm this. Please try a recent kernel, with and without the the bisected bad commit commit a57f7f9175b8ccbc9df83ac13860488913115de4 Author: Bob Moore robert.mo...@intel.com Date: Fri Aug 17 10:55:02 2012 +0800 ACPICA: Add Windows8/Server2012 string for _OSI method. reverted. Is the difference the same? Check reg dumps and dmesgs with drm.debug=0xe. Thanks, Jani. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [ANNOUNCE] xf86-video-intel 2.21.4
Release 2.21.4 (2013-03-11) === More bugs, more fixes, more releases. A minor new feature being introduced is the runtime detection of CPU instructions sets along with specialised paths to take advantage of the available CPU. * Honour LinearFramebuffer for clumsy PowerXpress integration * Disable read-read optimisations of mappings whilst the root cause of a corruption issue remains elusive. https://bugs.freedesktop.org/show_bug.cgi?id=61628 * Disable 8-bpp framebuffers in UXA as the regressions therein remain unfixed. * Restart vertex checks after lock contention https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1124576 * Handle Screen Pixmap recreation whilst exported via PRIME. * Correct application of scale factors to video source offsets. https://bugs.freedesktop.org/show_bug.cgi?id=61610 * Chain up CloseScreen so that resources are actually freed across regen https://bugs.freedesktop.org/show_bug.cgi?id=56608 * Fix Haswell CRW PCI-IDs * Handle batch submission failure during DRI copies https://bugs.freedesktop.org/show_bug.cgi?id=61708 * Probe for kernel support of requested Screen depth https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1135403 * Correct GPU limits for early gen2 and gen3 architectures and prevent an infinite recursion for particular image sizes. Complete list of changes since 2.21.3 - Carl Worth (1): Refuse to load driver for depth-8 X server. Chris Wilson (94): sna: Honour LinearFramebuffer sna: Always enable the solid-cache and gradient-cache sna/dri: Eradicate the DRI2 name exchange mechanism sna/gen7: Only a pipeline stall is required for the CA pass sna/gen7: Skip CLEAR_PARAMS for the null depthbuffer sna: Avoid migrating and making the GPU bo busy prior to mmapping it sna: Optimise mmap of GPU bo for read-read operations sna: Allow picture fixup in channel format if not changing RGB depth sna: Allow search_linear_cache() to reuse large buffers sna: Retire before looking for a large 2D buffer sna: Refuse to create larger than max temporary upload bo sna: Tidy a call to set the gamma before setting up a CRTC sna: Reduce DefaultDepth to 16 on older chipsets sna/gen3: Factor out the per-vertex divide for gradients sna/trapezoids: Instruct the compiler to flatten the callees whilst rasterising sna/gen3+: Assert that nbox is not 0 sna/gen3+: Restart vertex space checks after lock contention sna: Detect available instruction sets at runtime test: Correct ignore path for async.avi sna/gen4+: Begin specialising vertex programs for ISA sna: Reverse inverted assertions sna: Fix build on older GCC for cpuid() sna: Print detected CPU features sna/gen3: Allow conditional use of SSE2 sna: Ignore SSE4a - not an Intel ISA! sna: Mention if compiled as 64bit as part of the CPU feature detection sna: Only use the GPU bo after migrating sna/gen4+: All associated CPUs have sse2 at least sna/gen4: Cluster ISA sna: Conditionally compile avx routines sna: Conditionally compile sse4_2 routines sna: Conditionally compile sse2 routines sna: Bump required GCC for sse2 sna: Flatten unaligned box emission sna: Improve handling of migrated userptr bo sna/trapezoids: Add a pair of unlikely hints for forced box emission sna/gen3: Expand the number of SSE2 routines for basic composite ops sna: Flatten the glyph emitters sna: Force GCC to use the SSE unit for SSE2 routines sna/gen2: Add SSE2 fast paths for vertex emission sna: Migrate dirty tracking across ScreenPixmap updates sna: Remove the trailing '.' from the previous commit sna: Improve compatibility of cpuid.h detection sna: Prettify GCC version detection in headers sna/dri: Fix use of uninitialised pipe along error path sna: Fix syntax for __get_cpuid() sna/video: Correct scaling of source offsets sna: Track number of pixmaps allocated whilst counting bo leaks sna: Use depth-15 rather than depth-16 for reduced bw devices sna: Move some conditional code out-of-line sna: Assert that the ScrnInfo and ScreenPtr relationship is correct sna: Assert that we do not resurrect stale pixmap across a server regen sna: Assert that when caching a pixmap header the pScreen match sna: Assert that inplace operations are done on coherent maps sna: Chain up CloseScreen Fix Haswell CRW PCI-IDs sna: Eliminate a few used-once local variables sna/dri: Guard against failed batch submission sna: Probe for kernel support of framebuffer formats sna: Undo preferred depth for gen3 sna: CPUID return ISA features in ecx/edx sna/gen3: Add some debug around
[Intel-gfx] [PATCH] Revert drm/i915: try to train DP even harder
This reverts commit 0d71068835e2610576d369d6d4cbf90e0f802a71.
Not only that the commit introduces a bogus check (voltage_tries == 5
will never meet at the inserted code path), it brings the i915 driver
into an endless dp-train loop on HP Z1 desktop machine with IVY+eDP.
At least reverting this commit recovers the framebuffer (but X is
still broken by other reasons...)
Cc: sta...@vger.kernel.org
Signed-off-by: Takashi Iwai ti...@suse.de
---
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 f61cb79..7d250aa 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1929,7 +1929,7 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
for (i = 0; i intel_dp-lane_count; i++)
if ((intel_dp-train_set[i]
DP_TRAIN_MAX_SWING_REACHED) == 0)
break;
- if (i == intel_dp-lane_count voltage_tries == 5) {
+ if (i == intel_dp-lane_count) {
++loop_tries;
if (loop_tries == 5) {
DRM_DEBUG_KMS(too many full retries, give
up\n);
--
1.8.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/20] drm/i915: add power context allocation and setup on VLV v2
On Fri, Mar 08, 2013 at 10:45:52AM -0800, Jesse Barnes wrote:
The Gunit has a separate reg for this, so allocate some stolen space for
the power context and initialize the reg.
Is it a requirement to use stolen space? The reason we're allocating rings
and all from stolen is just to test things a bit better and ensure we have
a decent chance that stolen handling for fastboot works ... Some comment
somewhere would be good to clarify this.
Also seconded on Ben's comment.
Cheers, Daniel
v2: check for allocation before freeing at cleanup (Jani)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h|2 ++
drivers/gpu/drm/i915/i915_gem_stolen.c | 44
drivers/gpu/drm/i915/i915_reg.h|1 +
3 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2b4d9b6..3061d73 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1023,6 +1023,8 @@ typedef struct drm_i915_private {
struct i915_gpu_error gpu_error;
+ struct drm_mm_node *vlv_pctx;
+
/* list of fbdev register on this device */
struct intel_fbdev *fbdev;
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 69d97cb..8376a1b 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -171,11 +171,52 @@ void i915_gem_stolen_cleanup_compression(struct
drm_device *dev)
dev_priv-cfb_size = 0;
}
+static void i915_setup_pctx(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_mm_node *pctx;
+ unsigned long pctx_paddr;
+ int pctx_size = 24*1024;
+
+ pctx = drm_mm_search_free(dev_priv-mm.stolen, pctx_size, 4096, 0);
+ if (pctx)
+ pctx = drm_mm_get_block(pctx, pctx_size, 4096);
+ if (!pctx)
+ goto err;
+
+ pctx_paddr = dev_priv-mm.stolen_base + pctx-start;
+ if (!pctx_paddr)
+ goto err_free_pctx;
+
+ dev_priv-vlv_pctx = pctx;
+ I915_WRITE(VLV_PCBR, pctx_paddr);
+
+ return;
+
+err_free_pctx:
+ drm_mm_put_block(pctx);
+err:
+ DRM_DEBUG(not enough stolen space for PCTX, disabling\n);
+}
+
+static void i915_cleanup_pctx(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+
+ if (!dev_priv-vlv_pctx)
+ return;
+
+ I915_WRITE(VLV_PCBR, 0);
+ drm_mm_put_block(dev_priv-vlv_pctx);
+}
+
void i915_gem_cleanup_stolen(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
i915_gem_stolen_cleanup_compression(dev);
+ if (IS_VALLEYVIEW(dev) i915_powersave)
+ i915_cleanup_pctx(dev);
drm_mm_takedown(dev_priv-mm.stolen);
}
@@ -193,6 +234,9 @@ int i915_gem_init_stolen(struct drm_device *dev)
/* Basic memrange allocator for stolen space */
drm_mm_init(dev_priv-mm.stolen, 0, dev_priv-gtt.stolen_size);
+ if (IS_VALLEYVIEW(dev) i915_powersave)
+ i915_setup_pctx(dev);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c660a11..ed35805 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -623,6 +623,7 @@
#define VLV_IIR (VLV_DISPLAY_BASE + 0x20a4)
#define VLV_IMR (VLV_DISPLAY_BASE + 0x20a8)
#define VLV_ISR (VLV_DISPLAY_BASE + 0x20ac)
+#define VLV_PCBR (VLV_DISPLAY_BASE + 0x2120)
#define I915_PIPE_CONTROL_NOTIFY_INTERRUPT (118)
#define I915_DISPLAY_PORT_INTERRUPT(117)
#define I915_RENDER_COMMAND_PARSER_ERROR_INTERRUPT (115)
--
1.7.10.4
___
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: ignore hotplug event across suspend
On Mon, Mar 11, 2013 at 03:54:11AM +, Zhang, Xiong Y wrote: when system enter suspend, hibernate and poweroff state, it will disable modeset firstly, then disable irq, but some system generate hotplug event between disable modeset and disable irq, this will result in S3, S4 failure. So this hotplug event should be ignored. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61508 Signed-off-by: Xiong Zhang xiong.y.zh...@intel.com Should be fixed with commit b8efb17b3d687695b81485f606fc4e6c35a50f9a Author: Zhang Rui rui.zh...@intel.com Date: Tue Feb 5 15:41:53 2013 +0800 i915: ignore lid open event when resuming Cheers, Daniel --- drivers/gpu/drm/i915/i915_irq.c |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 2139714..68cc7a7 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -290,6 +290,12 @@ static void i915_hotplug_work_func(struct work_struct *work) struct drm_device *dev = dev_priv-dev; struct drm_mode_config *mode_config = dev-mode_config; struct intel_encoder *encoder; + +/* some system generate hotplug envent when system enter sleep state. + * it should be ignored. + */ +if (dev_priv-mm.suspended) +return; /* HPD irq before everything is fully set up. */ if (!dev_priv-enable_hotplug_processing) ___ 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 09/20] drm/i915: add power context allocation and setup on VLV v2
On Tue, Mar 12, 2013 at 12:40:30AM +0100, Daniel Vetter wrote: On Fri, Mar 08, 2013 at 10:45:52AM -0800, Jesse Barnes wrote: The Gunit has a separate reg for this, so allocate some stolen space for the power context and initialize the reg. Is it a requirement to use stolen space? The reason we're allocating rings and all from stolen is just to test things a bit better and ensure we have a decent chance that stolen handling for fastboot works ... Some comment somewhere would be good to clarify this. I'm in favour of making these small permanent allocations from stolen whereever possible. But you are right to point out that we need to clearly mark anthing that may require physically contiguous memory, just in case. -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
[Intel-gfx] linux-next: build failure after merge of the final tree (drm-intel tree related)
Hi all, After merging the final tree, today's linux-next build (i386 defconfig) failed like this: drivers/built-in.o: In function `i915_min_freq_set': i915_debugfs.c:(.text+0xb1adc): undefined reference to `__udivdi3' drivers/built-in.o: In function `i915_max_freq_set': i915_debugfs.c:(.text+0xb1bac): undefined reference to `__udivdi3' Caused by commit 2389cc500686 (drm/i915: use simple attribute in debugfs routines) from the drm-intel tree. I have reverted that commit for today. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpLGEoWS5NkQ.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
