Re: [Intel-gfx] [PATCH v2] drm/i915: Fix eDP blank screen after S3 resume on HP desktops
Am Donnerstag, den 21.06.2012, 15:30 +0200 schrieb Takashi Iwai:
This patch fixes the problem on some HP desktop machines with eDP
which give blank screens after S3 resume.
It turned out that BLC_PWM_CPU_CTL must be written after
BLC_PWM_CPU_CTL2. Otherwise it doesn't take effect on these
SNB machines.
Tested with 3.5-rc3 kernel.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49233
Hmm, the bug entry does not contain a link to the discussion on
intel-gfx.
http://lists.freedesktop.org/archives/intel-gfx/2012-June/018418.html
Maybe add it there or to the commit message.
Cc: sta...@vger.kernel.org
Signed-off-by: Takashi Iwai ti...@suse.de
---
drivers/gpu/drm/i915/i915_suspend.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index 0ede02a..a748e5c 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -740,8 +740,11 @@ static void i915_restore_display(struct drm_device *dev)
if (HAS_PCH_SPLIT(dev)) {
I915_WRITE(BLC_PWM_PCH_CTL1, dev_priv-saveBLC_PWM_CTL);
I915_WRITE(BLC_PWM_PCH_CTL2, dev_priv-saveBLC_PWM_CTL2);
- I915_WRITE(BLC_PWM_CPU_CTL, dev_priv-saveBLC_CPU_PWM_CTL);
+ /* NOTE: BLC_PWM_CPU_CTL must be written after BLC_PWM_CPU_CTL2;
+ * otherwise we get blank eDP screen after S3 on some machines
Full stop at the end? Also add a reference to the list discussion or
Bugzilla entry?
+ */
I915_WRITE(BLC_PWM_CPU_CTL2, dev_priv-saveBLC_CPU_PWM_CTL2);
+ I915_WRITE(BLC_PWM_CPU_CTL, dev_priv-saveBLC_CPU_PWM_CTL);
I915_WRITE(PCH_PP_ON_DELAYS, dev_priv-savePP_ON_DELAYS);
I915_WRITE(PCH_PP_OFF_DELAYS, dev_priv-savePP_OFF_DELAYS);
I915_WRITE(PCH_PP_DIVISOR, dev_priv-savePP_DIVISOR);
With or without these changes above, this patch is
Acked-by: Paul Menzel paulepan...@users.sourceforge.net
Thanks,
Paul
signature.asc
Description: This is a digitally signed message part
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: prefer wide slow to fast narrow in DP configs
On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard kei...@keithp.com wrote: Jesse Barnes jbar...@virtuousgeek.org writes: High frequency link configurations have the potential to cause trouble with long and/or cheap cables, so prefer slow and wide configurations instead. This patch has the potential to cause trouble for eDP configurations that lie about available lanes, so if we run into that we can make it conditional on eDP. I *have* run into this on eDP machines already, which is why the code loops this way today... It was structured to minimise lane count because certain chipsets did not wire up all the lanes, right? Is that still relevant as we are using the advertised max_lane_count from the DPCD now? -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] drm/i915: prefer wide slow to fast narrow in DP configs
On Fri, 2012-06-22 at 10:05 +0100, Chris Wilson wrote: On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard kei...@keithp.com wrote: Jesse Barnes jbar...@virtuousgeek.org writes: High frequency link configurations have the potential to cause trouble with long and/or cheap cables, so prefer slow and wide configurations instead. This patch has the potential to cause trouble for eDP configurations that lie about available lanes, so if we run into that we can make it conditional on eDP. Have we considered looking at the link quality bits of DPCD for this? Section 2.5.3.5 of the DP 1.1 spec looks apropos. It looks painfully slow to get all the way to the actual spec error rate, but it might not be a bad first test to run for a second before doing actual link training. Do you have a crappy cable that produces this problem? There's also a comment about the sink clearing the symbol lock and lane alignment bits on too many errors (3.5.1.3.2); we're not periodically re-checking those bits, maybe we should. It's a shame they didn't bother to spec anything actually good, like sink must report the number of ECC corrections it's done. But I suppose that applies to DP as a whole really. I *have* run into this on eDP machines already, which is why the code loops this way today... It was structured to minimise lane count because certain chipsets did not wire up all the lanes, right? Is that still relevant as we are using the advertised max_lane_count from the DPCD now? Pretty sure it's structured to use minimum lane count because that's the correct thing to do for power. - ajax signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: prefer wide slow to fast narrow in DP configs
Chris Wilson ch...@chris-wilson.co.uk writes: On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard kei...@keithp.com wrote: It was structured to minimise lane count because certain chipsets did not wire up all the lanes, right? Is that still relevant as we are using the advertised max_lane_count from the DPCD now? We've always used the max_lane_count from dpcd; has there been some recent change that fixed usage of that? What I recall is one acer laptop that advertised 4 lanes but had only wired up two of them. -- keith.pack...@intel.com pgpmKQkYSOOOJ.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: prefer wide slow to fast narrow in DP configs
Jesse Barnes jbar...@virtuousgeek.org writes: In embedded applications, some of the lanes may not exist, but the DPCD should indicate that (though as Keith says, some lie about it). But if we set aside eDP it may be safe... Yeah, that's my thinking. We should probably include eDP hooked up to the PCH DP lanes (for all-in-one systems) too. -- keith.pack...@intel.com pgp2R7zpW2Ra3.pgp Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: prefer wide slow to fast narrow in DP configs
On Fri, 22 Jun 2012 10:40:22 -0700, Keith Packard kei...@keithp.com wrote: Chris Wilson ch...@chris-wilson.co.uk writes: On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard kei...@keithp.com wrote: It was structured to minimise lane count because certain chipsets did not wire up all the lanes, right? Is that still relevant as we are using the advertised max_lane_count from the DPCD now? We've always used the max_lane_count from dpcd; has there been some recent change that fixed usage of that? What I recall is one acer laptop that advertised 4 lanes but had only wired up two of them. The only recentish change was your commit 9a10f401a401ca69c6537641c8fc0d6b57b5aee8 Author: Keith Packard kei...@keithp.com Date: Wed Nov 2 13:03:47 2011 -0700 drm/i915: Use DPCD value for max DP lanes. The BIOS VBT value for an eDP panel has been shown to be incorrect on one machine, and we haven't found any machines where the DPCD value was wrong, so we'll use the DPCD value everywhere. We can but hope that no manufacturer lies in the DPCD. -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] Ivy Bridge open source programming manuals are now available
Hi folks, Intel Open Source HD Graphics Programmer's Reference Manuals (PRMs) for 2012 Intel Core Processor Family (codenamed Ivy Bridge) are now available at http://intellinuxgraphics.org/documentation.html. Have fun :). -- Eugeni Dodonov http://eugeni.dodonov.net/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] GMA 950 Intel 945G gallium driver
On Sun, Jun 3, 2012 at 5:44 AM, Emam Hossain imamdxl8...@gmail.com wrote: Hello Everyone, Recently I have tested one of my old desktop which got Intel 945G on a Dual Core CPU. I have installed Ubuntu 11.10 with XServer 1.11, kernel 3.2 and xf86-video-intel 2.18. What I have found that Gallium driver i915g from Mesa 7.11 and 8 is performing better than officially supported DRI i915 driver. For example, when tested against the following games: BEEP, http://www.desura.com/games/beep (gallium plays fine while dri not) BIT.TRIP.RUNNER from humble bundle, http://bittripgame.com/bittrip-runner.html (gallium smooth gameplay, dri slow) and many more. Moreover, Windows games with WINE are not playable at all or broken with DRI driver while runs good with gallium. For example with games: Need for Speed Underground Flatout 1 Need for Speed Most Wanted gallium does the job while DRI does not. So, my question is why dont support gallium driver when it is performing better than DRI driver. why not make gallium driver better since Intel 945G does not have hardware support for many features, DRI driver is just slow for modern games except GL 1.1 games while gallium driver making use of CPU to perform those missing hardware features and making games at least run. Moreover, Windows driver does similar approach like gallium 3D. I feel that the reason is that the classic i915 driver is in maintenance mode and focus is on newer GPUs. The gallium i915 driver is what we use on some Chrome OS machines, and that's the main reason I've been working on it. With that said, I'm pondering exposing GL 2.1 on it, since it seems legit per the spec to hack sRGB texture support with U8 + fragment shader instructions. That'd allow some unigine-based games to run. Stéphane ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] GMA 950 Intel 945G gallium driver
On 2012-06-22 11:18-0700 Stéphane Marchesin wrote: On Sun, Jun 3, 2012 at 5:44 AM, Emam Hossain imamdxl8...@gmail.com wrote: Hello Everyone, Recently I have tested one of my old desktop which got Intel 945G on a Dual Core CPU. I have installed Ubuntu 11.10 with XServer 1.11, kernel 3.2 and xf86-video-intel 2.18. What I have found that Gallium driver i915g from Mesa 7.11 and 8 is performing better than officially supported DRI i915 driver. For example, when tested against the following games: BEEP, http://www.desura.com/games/beep (gallium plays fine while dri not) BIT.TRIP.RUNNER from humble bundle, http://bittripgame.com/bittrip-runner.html (gallium smooth gameplay, dri slow) and many more. Moreover, Windows games with WINE are not playable at all or broken with DRI driver while runs good with gallium. For example with games: Need for Speed Underground Flatout 1 Need for Speed Most Wanted gallium does the job while DRI does not. So, my question is why dont support gallium driver when it is performing better than DRI driver. why not make gallium driver better since Intel 945G does not have hardware support for many features, DRI driver is just slow for modern games except GL 1.1 games while gallium driver making use of CPU to perform those missing hardware features and making games at least run. Moreover, Windows driver does similar approach like gallium 3D. I feel that the reason is that the classic i915 driver is in maintenance mode and focus is on newer GPUs. The gallium i915 driver is what we use on some Chrome OS machines, and that's the main reason I've been working on it. With that said, I'm pondering exposing GL 2.1 on it, since it seems legit per the spec to hack sRGB texture support with U8 + fragment shader instructions. That'd allow some unigine-based games to run. The i915g driver sounds like an interesting alternative for driving older Intel equipment. For example, one of my computers (which I am using as a thin client/X terminal) is an ASUS Eee netbook with the 945GME chipset. The Debian stable version of the classic driver works okay on that. For example, I can run env LIBGL_ALWAYS_INDIRECT=1 foobillard on our principal machine and display the results on the thin client without obvious issues. However, that is a pretty old version of X, and there have been numerous changes to the Intel graphics stack since then without much official testing on old equipment (or on thin clients for that matter) by the Intel software team. Therefore, I am not too sure whether the newer version of the Intel graphics stack will work well on that equipment when I upgrade to Debian testing, and the original post in this thread (quoted above) isn't exactly reassuring on that issue. Therefore, I would like to try out the i915g driver myself. Are there build instructions somewhere for that driver or better yet is there a Debian (or Ubuntu) package that includes it? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] GMA 950 Intel 945G gallium driver
On Fri, Jun 22, 2012 at 12:41 PM, Alan W. Irwin ir...@beluga.phys.uvic.cawrote: On 2012-06-22 11:18-0700 Stéphane Marchesin wrote: On Sun, Jun 3, 2012 at 5:44 AM, Emam Hossain imamdxl8...@gmail.com wrote: Hello Everyone, Recently I have tested one of my old desktop which got Intel 945G on a Dual Core CPU. I have installed Ubuntu 11.10 with XServer 1.11, kernel 3.2 and xf86-video-intel 2.18. What I have found that Gallium driver i915g from Mesa 7.11 and 8 is performing better than officially supported DRI i915 driver. For example, when tested against the following games: BEEP, http://www.desura.com/games/**beephttp://www.desura.com/games/beep(gallium plays fine while dri not) BIT.TRIP.RUNNER from humble bundle, http://bittripgame.com/** bittrip-runner.html http://bittripgame.com/bittrip-runner.html (gallium smooth gameplay, dri slow) and many more. Moreover, Windows games with WINE are not playable at all or broken with DRI driver while runs good with gallium. For example with games: Need for Speed Underground Flatout 1 Need for Speed Most Wanted gallium does the job while DRI does not. So, my question is why dont support gallium driver when it is performing better than DRI driver. why not make gallium driver better since Intel 945G does not have hardware support for many features, DRI driver is just slow for modern games except GL 1.1 games while gallium driver making use of CPU to perform those missing hardware features and making games at least run. Moreover, Windows driver does similar approach like gallium 3D. I feel that the reason is that the classic i915 driver is in maintenance mode and focus is on newer GPUs. The gallium i915 driver is what we use on some Chrome OS machines, and that's the main reason I've been working on it. With that said, I'm pondering exposing GL 2.1 on it, since it seems legit per the spec to hack sRGB texture support with U8 + fragment shader instructions. That'd allow some unigine-based games to run. The i915g driver sounds like an interesting alternative for driving older Intel equipment. For example, one of my computers (which I am using as a thin client/X terminal) is an ASUS Eee netbook with the 945GME chipset. The Debian stable version of the classic driver works okay on that. For example, I can run env LIBGL_ALWAYS_INDIRECT=1 foobillard on our principal machine and display the results on the thin client without obvious issues. However, that is a pretty old version of X, and there have been numerous changes to the Intel graphics stack since then without much official testing on old equipment (or on thin clients for that matter) by the Intel software team. Therefore, I am not too sure whether the newer version of the Intel graphics stack will work well on that equipment when I upgrade to Debian testing, and the original post in this thread (quoted above) isn't exactly reassuring on that issue. Therefore, I would like to try out the i915g driver myself. Are there build instructions somewhere for that driver You just need to download mesa (preferably 8.x) and: ./configure --with-gallium-drivers=i915 make make install That should do the trick :) or better yet is there a Debian (or Ubuntu) package that includes it? I don't think there is a debian/ubuntu package, but I could be wrong. Stéphane ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: rip out the PM_IIR WARN
On Thu, Jun 21, 2012 at 02:55:22PM +0200, Daniel Vetter wrote: After banging my head against this for the past few months, I still don't see how this could possible race under the premise that once an irq bit is masked in PM_IMR and reset in PM_IIR it won't show up again until we unmask it in PM_IMR. Still, we have reports of this being seen in the wild. Now Bspec has this little bit of lovely language in the PMIIR register: Public SNB Docs, Vol3Part2, 2.5.14 PMIIR: For each bit, the IIR can store a second pending interrupt if two or more of the same interrupt conditions occur before the first condition is cleared. Upon clearing the interrupt, the IIR bit will momentarily go low, then return high to indicate there is another interrupt pending. Now if we presume that PMIMR only prevent new interrupts from being queued, we could easily end up masking an interrupt and clearing it, but the 2nd pending interrupt setting the bit in PMIIR right away again. Which leads, the next time the irq handler runs, to hitting the WARN. Also, no bad side effects of this have ever been reported. And we've tracked down our issues with the gpu turbo getting stuck to bogus interrupt generation limits in th RPLIMIT register. So let's just rip out this WARN as bogus and call it a day. The only shallow thing here is that this 2-deep irq queue in the hw makes you wonder how racy the windows irq handler is ... Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42907 Cc: sta...@vger.kernel.org Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch I've picked this one up for -fixes. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Fix eDP blank screen after S3 resume on HP desktops
On Thu, Jun 21, 2012 at 03:30:41PM +0200, Takashi Iwai wrote: This patch fixes the problem on some HP desktop machines with eDP which give blank screens after S3 resume. It turned out that BLC_PWM_CPU_CTL must be written after BLC_PWM_CPU_CTL2. Otherwise it doesn't take effect on these SNB machines. Tested with 3.5-rc3 kernel. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49233 Cc: sta...@vger.kernel.org Signed-off-by: Takashi Iwai ti...@suse.de Picked up for -fixes, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: expose energy counter on SNB and IVB
On Wed, 20 Jun 2012 14:48:58 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:
On SNB and IVB, there's an MSR (also exposed through MCHBAR) we can use
to read out the amount of energy used over time. Expose this in sysfs
to make it easy to do power comparisons with different configurations.
If the platform supports it, the file will show up under the
drm/card0/power subdirectory of the PCI device in sysfs as gt_energy_uJ.
The value in the file is a running total of energy (in microjoules)
consumed by the graphics device.
v2: move to sysfs (Ben, Daniel)
expose a simple value (Chris)
drop unrelated hunk (Ben)
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
I have some complaints, and a bikeshed - but it's
Acked-by: Ben Widawsky b...@bwidawsk.net
either way.
And color-me-danvet, but I kind of get why review is so mean on ABI
stuff.
I don't really care whether you address the other complaints, but I
won't do a a proper reviewed-by until the doc complaints are addressed.
---
drivers/gpu/drm/i915/i915_reg.h |2 +
drivers/gpu/drm/i915/i915_sysfs.c | 39
+
2 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 0a61481..ca6a620 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1224,6 +1224,8 @@
#define CLKCFG_MEM_800 (3 4)
#define CLKCFG_MEM_MASK (7 4)
+#define SECP_NRG_STTS(MCHBAR_MIRROR_BASE_SNB +
0x592c)
+
I can't find where this is defined, so it's hard to review. Could you
please point me to the docs for this?
#define TSC1 0x11001
#define TSE(10)
#define TR1 0x11006
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 2f5388a..c7fe7bd 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -93,6 +93,37 @@ static struct attribute_group rc6_attr_group = {
.attrs = rc6_attrs
};
+#define MSR_IA32_PACKAGE_POWER_SKU_UNIT 0x0606
I honestly didn't try to look for this definition, but let's assume I
can't find it. Where is this one?
+
+static ssize_t
+show_gt_energy_uJ(struct device *dev, struct device_attribute *attr, char
*buf)
+{
+ struct drm_minor *dminor = container_of(dev, struct drm_minor, kdev);
+ struct drm_i915_private *dev_priv = dminor-dev-dev_private;
+ u64 ppsu;
+ u32 val, units;
+
+ rdmsrl(MSR_IA32_PACKAGE_POWER_SKU_UNIT, ppsu);
+
+ ppsu = (ppsu 0x1f00) 8;
+ units = 100 / (1 ppsu); /* convert to uJ */
+ val = I915_READ(SECP_NRG_STTS);
+
+ return snprintf(buf, PAGE_SIZE, %u, val * units);
+}
+
+static DEVICE_ATTR(gt_energy_uJ, S_IRUGO, show_gt_energy_uJ, NULL);
+
+static struct attribute *gt_attrs[] = {
+ dev_attr_gt_energy_uJ.attr,
+ NULL,
+};
I think convention dictates it should be all lowercase. And while on
that, gt_energy_uJ is about as descriptive a name as rc6 (what jerk
named that anyway?). I think something like consumed_microjoules is
better.
+
+static struct attribute_group gt_attr_group = {
+ .name = power_group_name,
+ .attrs = gt_attrs,
+};
+
static int l3_access_valid(struct drm_device *dev, loff_t offset)
{
if (!IS_IVYBRIDGE(dev))
@@ -217,10 +248,18 @@ void i915_setup_sysfs(struct drm_device *dev)
if (ret)
DRM_ERROR(l3 parity sysfs setup failed\n);
}
+
+ if (IS_GEN6(dev) || IS_IVYBRIDGE(dev)) {
+ ret = sysfs_merge_group(dev-primary-kdev.kobj,
+ gt_attr_group);
+ if (ret)
+ DRM_ERROR(GT energy sysfs setup failed\n);
+ }
}
void i915_teardown_sysfs(struct drm_device *dev)
{
device_remove_bin_file(dev-primary-kdev, dpf_attrs);
sysfs_unmerge_group(dev-primary-kdev.kobj, rc6_attr_group);
+ sysfs_unmerge_group(dev-primary-kdev.kobj, gt_attr_group);
}
teardown should occur in reverse of init, so I'd put this on top.
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
