Re: [Intel-gfx] [PATCH] drm/i915: expose energy counter on SNB and IVB

[Ben Widawsky]

On Wed, 20 Jun 2012 14:48:58 -0700
Jesse Barnes  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 

I have some complaints, and a bikeshed - but it's
Acked-by: Ben Widawsky 
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(1<<0)
>  #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,
> + >_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, >_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

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix eDP blank screen after S3 resume on HP desktops

[Daniel Vetter]

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: 
> Signed-off-by: Takashi Iwai 
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: rip out the PM_IIR WARN

[Daniel Vetter]

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 
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] GMA 950 Intel 945G gallium driver

[Stéphane Marchesin]

On Fri, Jun 22, 2012 at 12:41 PM, Alan W. Irwin
wrote:

> On 2012-06-22 11:18-0700 Stéphane Marchesin wrote:
>
>
>>
>> On Sun, Jun 3, 2012 at 5:44 AM, Emam Hossain 
>> 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


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] GMA 950 Intel 945G gallium driver

[Alan W. Irwin]

On 2012-06-22 11:18-0700 Stéphane Marchesin wrote:




On Sun, Jun 3, 2012 at 5:44 AM, Emam Hossain  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

[Stéphane Marchesin]

On Sun, Jun 3, 2012 at 5:44 AM, Emam Hossain  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

[Intel-gfx] Ivy Bridge open source programming manuals are now available

[Eugeni Dodonov]

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

___
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]

On Fri, 22 Jun 2012 10:40:22 -0700, Keith Packard  wrote:
> Chris Wilson  writes:
> 
> > On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard  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 
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

Re: [Intel-gfx] [PATCH] drm/i915: prefer wide & slow to fast & narrow in DP configs

[Keith Packard]

Jesse Barnes  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

[Keith Packard]

Chris Wilson  writes:

> On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard  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]

On Fri, 22 Jun 2012 10:05:19 +0100
Chris Wilson  wrote:

> On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard  wrote:
> > Jesse Barnes  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?

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...

-- 
Jesse Barnes, 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: prefer wide & slow to fast & narrow in DP configs

[Adam Jackson]

On Fri, 2012-06-22 at 10:05 +0100, Chris Wilson wrote:
> On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard  wrote:
> > Jesse Barnes  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]

On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard  wrote:
> Jesse Barnes  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 v2] drm/i915: Fix eDP blank screen after S3 resume on HP desktops

[Paul Menzel]

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: 
> Signed-off-by: Takashi Iwai 
> ---
>  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 


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