On Sat, Feb 11, 2012 at 08:00:39PM +, Chris Wilson wrote:
> On Sat, 11 Feb 2012 17:22:05 +0100, Daniel Vetter wrote:
> > On Thu, Feb 09, 2012 at 10:15:17AM +0100, Ben Widawsky wrote:
> > > Someday I will get simple patches in one version... Alas that day is not
> > > today.
> > >
> > > Ben Wi
Hi!
I think it's not just a placebo effect. I'm one of the users affected by
video corruption with rc6 enabled. Now I have used my pc for two days with
the patched kernel and everything seem working just fine. The glitches that
I had with the previous kernel versions were very noticeable and someti
On Sat, 11 Feb 2012 17:22:05 +0100, Daniel Vetter wrote:
> On Thu, Feb 09, 2012 at 10:15:17AM +0100, Ben Widawsky wrote:
> > Someday I will get simple patches in one version... Alas that day is not
> > today.
> >
> > Ben Widawsky (3):
> > drm/i915: use gtfifodbg
> > drm/i915: catch gtfifo err
On Sat, 11 Feb 2012 17:23:32 -0200, Eugeni Dodonov
wrote:
> This allows to select which rc6 modes are to be used via kernel parameter,
> via a bitmask parameter. E.g.:
>
> - to enable rc6, i915_enable_rc6=1
> - to enable rc6 and deep rc6, i915_enable_rc6=3
> - to enable rc6 and deepest rc6, use
On Sat, Feb 11, 2012 at 10:59, Chris Wilson wrote:
> On Sat, 11 Feb 2012 10:34:15 -0200, Eugeni Dodonov <
> eugeni.dodo...@intel.com> wrote:
> > This is yet another chapter in the ongoing saga of bringing RC6 to Sandy
> > Bridge machines by default.
> >
> > Now that we have discovered that RC6 iss
This allows to select which rc6 modes are to be used via kernel parameter,
via a bitmask parameter. E.g.:
- to enable rc6, i915_enable_rc6=1
- to enable rc6 and deep rc6, i915_enable_rc6=3
- to enable rc6 and deepest rc6, use i915_enable_rc6=5
- to enable rc6, deep and deepest rc6, use i915_enable
On Sat, Feb 11, 2012 at 16:13, Kai Krakow wrote:
> Chris Wilson schrieb:
>
> >> + if (rc6_mode > 0) {
> > I'm a little uneasy mixing signs and bitmasks, and this test looks a
> > little pointless as intel_enable_rc6 now returns the bitmask. Kill it
> > and we kill one level of indentation!
>
Chris Wilson schrieb:
>> + if (rc6_mode > 0) {
> I'm a little uneasy mixing signs and bitmasks, and this test looks a
> little pointless as intel_enable_rc6 now returns the bitmask. Kill it
> and we kill one level of indentation!
I think not, because Eugeni documented "-1" as the chipset def
On Thu, Feb 09, 2012 at 10:15:17AM +0100, Ben Widawsky wrote:
> Someday I will get simple patches in one version... Alas that day is not
> today.
>
> Ben Widawsky (3):
> drm/i915: use gtfifodbg
> drm/i915: catch gtfifo errors on forcewake_put
> drm/i915: check gtfifodbg after possibly failed
On Sat, 11 Feb 2012 10:34:15 -0200, Eugeni Dodonov
wrote:
> This is yet another chapter in the ongoing saga of bringing RC6 to Sandy
> Bridge machines by default.
>
> Now that we have discovered that RC6 issues are triggered by RC6+ state,
> let's try to disable it by default. Plain RC6 is the o
On Sat, 11 Feb 2012 10:34:14 -0200, Eugeni Dodonov
wrote:
> This allows to select which rc6 modes are to be used via kernel parameter,
> via a bitmask parameter. E.g.:
>
> - to enable rc6, i915_enable_rc6=1
> - to enable rc6 and deep rc6, i915_enable_rc6=3
> - to enable rc6 and deepest rc6, use
This is yet another chapter in the ongoing saga of bringing RC6 to Sandy
Bridge machines by default.
Now that we have discovered that RC6 issues are triggered by RC6+ state,
let's try to disable it by default. Plain RC6 is the one responsible for
most energy savings, and so far it haven't given an
This allows to select which rc6 modes are to be used via kernel parameter,
via a bitmask parameter. E.g.:
- to enable rc6, i915_enable_rc6=1
- to enable rc6 and deep rc6, i915_enable_rc6=3
- to enable rc6 and deepest rc6, use i915_enable_rc6=5
- to enable rc6, deep and deepest rc6, use i915_enable
Hi,
so far, apparently all the RC6-related issues on Sandy Bridge seem to be gone
when we enable RC6 but do not enable deep RC6. This apparently also cures
the symptoms we were seeing with RC6 when VTd was active, so in theory we
won't need the intel_iommu duct-taping anymore.
Somehow, we haven't
On Sat, Feb 11, 2012 at 11:47:36AM +, Chris Wilson wrote:
> Every access to either the GTT or CPU pointer is supposed to be
> proceeded by a set_domain ioctl so that GEM is able to manage the cache
> domains correctly and for the following access to be coherent. Of
> course, some people explici
Every access to either the GTT or CPU pointer is supposed to be
proceeded by a set_domain ioctl so that GEM is able to manage the cache
domains correctly and for the following access to be coherent. Of
course, some people explicitly want incoherent, non-blocking access
which is going to trigger war
Hi Armin,
On Sat, Feb 11, 2012 at 01:11:16AM +, Reese, Armin C wrote:
> Thanks for letting me know about the GCC warning messages. I did my
> final tweeks on the program in Android and compiled in that environment.
> The compiler there is a bit blind and the build jobs generate so much
> outp
On Fri, Feb 10, 2012 at 10:19:16PM -0800, Kenneth Graunke wrote:
> On my system, sys/fcntl.h contains exactly one line:
>
>#include
>
> So there's really no need to #ifdef it. Also, intel_mmio.c already
> included ; there's no need to include it twice.
>
> Signed-off-by: Kenneth Graunke
T
18 matches
Mail list logo
