On 07/13/2013 08:46 AM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> According to Matthew Garrett, "Windows 8 leaves backlight control up
> to individual graphics drivers rather than making ACPI calls itself.
> There's plenty of evidence to suggest that the Intel driver for
> Windows [8
On Sun, Jul 14, 2013 at 11:31:29PM +0200, Daniel Vetter wrote:
> On Sun, Jul 14, 2013 at 01:55:20PM -0700, Ben Widawsky wrote:
> > On Fri, Jul 12, 2013 at 10:43:26PM +0200, Daniel Vetter wrote:
[snip]
> >
> > Maybe while you're doing this, explain why the L3 parity interrupt is
> > special, in a
On Sun, Jul 14, 2013 at 06:52:39PM +0200, Daniel Vetter wrote:
> On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov
> wrote:
> > This patch fixes regression in power consumtion of sandy bridge gpu, which
> > exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking
> > that
>
On Sun, Jul 14, 2013 at 11:31:29PM +0200, Daniel Vetter wrote:
> On Sun, Jul 14, 2013 at 01:55:20PM -0700, Ben Widawsky wrote:
> > On Fri, Jul 12, 2013 at 10:43:26PM +0200, Daniel Vetter wrote:
> > > Again extract a common helper. For the postinstall hook things are a
> > > bit more complicated sin
On Sun, Jul 14, 2013 at 02:06:28PM -0700, Ben Widawsky wrote:
> On Fri, Jul 12, 2013 at 10:43:27PM +0200, Daniel Vetter wrote:
> > The VECS enabling required some changes to how rps interrupts are
> > enabled/disabled since VECS interrupts are handling with the PM
> > interrupt registers.
> >
> >
On Sun, Jul 14, 2013 at 01:55:20PM -0700, Ben Widawsky wrote:
> On Fri, Jul 12, 2013 at 10:43:26PM +0200, Daniel Vetter wrote:
> > Again extract a common helper. For the postinstall hook things are a
> > bit more complicated since we have more cases on ilk-hsw/vlv here.
> >
> > But since vlv was c
On Fri, Jul 12, 2013 at 10:43:27PM +0200, Daniel Vetter wrote:
> The VECS enabling required some changes to how rps interrupts are
> enabled/disabled since VECS interrupts are handling with the PM
> interrupt registers.
>
> But now that the pre/postinstall sequences is identical for all
> platform
On Fri, Jul 12, 2013 at 10:43:26PM +0200, Daniel Vetter wrote:
> Again extract a common helper. For the postinstall hook things are a
> bit more complicated since we have more cases on ilk-hsw/vlv here.
>
> But since vlv was clearly broken by failing to initialize
> dev_priv->gt_irq_mask correctly
On Fri, Jul 12, 2013 at 10:43:25PM +0200, Daniel Vetter wrote:
> Since the addition of VECS we have a slightly different enable
> sequence for PM interrupts on ivb/hsw vs snb and vlv. Usually that
> will end up in hard to track down surprises.
>
> Hence unifiy things and since we have copies of th
On Sun, Jul 14, 2013 at 12:42:49PM -0700, Ben Widawsky wrote:
> On Fri, Jul 12, 2013 at 06:08:22PM +0100, Chris Wilson wrote:
> > Currently, the register access code is split between i915_drv.c and
> > intel_pm.c. It only bares a superficial resemblance to the reset of the
> > powermanagement code,
On Sat, Jul 13, 2013 at 11:39:44AM +0200, Daniel Vetter wrote:
> On Thu, Jul 04, 2013 at 11:42:46AM -0700, Ben Widawsky wrote:
> > We need it before we set the pte_encode function pointers, which happens
> > really early, in gtt_init.
> >
> > The problem with just doing the normal sequence earlier
On Fri, Jul 12, 2013 at 09:02:37PM -0300, Rodrigo Vivi wrote:
> On Thu, Jul 4, 2013 at 3:02 PM, Ben Widawsky wrote:
> > The EDRAM present register isn't really defined in the docs. It just
> > says check to see if it's set to 1. So I haven't defined the 1 value not
> > knowing what it actually mea
On Fri, Jul 12, 2013 at 09:00:31PM -0300, Rodrigo Vivi wrote:
> Hi Ben,
>
> sorry for taking so long to look at your patches.
> Well, since I changed my TI password I'm not able to see bspec
> anymore, so I couldn't verify many things that I'm going to ask many
> questions.
> If the answer is on s
On Fri, Jul 12, 2013 at 06:08:27PM +0100, Chris Wilson wrote:
> The TRACE_EVENT_CONDITION is supposed to generate more efficient code
> than if (cond) trace(), which is what we are currently using inside the
> register access functions.
>
> v2: Rebase onto uncore
>
> Signed-off-by: Chris Wilson
On Fri, Jul 12, 2013 at 06:08:25PM +0100, Chris Wilson wrote:
> In theory, the different register blocks were meant to be only ever
> touched when holding either the struct_mutex, mode_config.lock or even a
> specific localised lock. This does not seem to be the case, and the
> hardware reacts extr
On Fri, Jul 12, 2013 at 06:08:23PM +0100, Chris Wilson wrote:
> The GT functions for enabling register access also need to occasionally
> write to and read from registers. To avoid the potential recursion as we
> modify the public interface to be stricter, introduce a private register
> access API
This is required so we can use the existing do_switch() which tries to
map objects as non mappable and 64k aligned can work. Again, this is
only required in order to ease the transition over to the existing
context code.
This commit is left as distinct from the previous one because it also
effects
With the conversion to use the existing, well tested HW context code for
the ILK RC6 render context, let's once again try to enable RC6 by
default on ILK.
This is basically a revert of a revert and reapply of an existing patch.
RC6 has been enabled, and reverted several times on Ironlake. The most
On Sun, Jul 14, 2013 at 09:22:53AM -0700, Ben Widawsky wrote:
> With the conversion to use the existing, well tested HW context code for
> the ILK RC6 render context, let's once again try to enable RC6 by
> default on ILK.
>
> Signed-off-by: Ben Widawsky
I think this commit should cite the last
Changed the mail subject... I'm not even sure what HW Contest support
might be.
On Sun, Jul 14, 2013 at 09:24:16AM -0700, Ben Widawsky wrote:
> Why do I always forget this...?
>
> You guys can easily clone the kernel sources here for easier testing:
>
> http://cgit.freedesktop.org/~bwidawsk/drm-
On Sun, Jul 14, 2013 at 6:30 PM, Konstantin Khlebnikov
wrote:
> This patch fixes regression in power consumtion of sandy bridge gpu, which
> exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that
> it's extremely busy. After that it never reaches rc6 state.
>
> Bug was intr
Why do I always forget this...?
You guys can easily clone the kernel sources here for easier testing:
http://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=ilk_contexts
On Sun, Jul 14, 2013 at 09:22:44AM -0700, Ben Widawsky wrote:
> By the request of Ken, and Chris, I've added support for HW co
With the conversion to use the existing, well tested HW context code for
the ILK RC6 render context, let's once again try to enable RC6 by
default on ILK.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/intel_pm.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
NOTE: The error messages might need updating if the patches don't make
3.11.
NOTE2: I'm not sure if mesa devs want to make HW contexts a hard
requirement on GEN5, as it is on GEN6+. I think letting the patches soak
for a few releases first, won't be a bad idea.
Signed-off-by: Ben Widawsky
---
s
The ILK renderctx predates the generic i915 context code. With the
patches before this, I believe I have properly eased the transition to
simply using the regular default context instead of the special
renderctx.
This untangles the weirdness from the last commit, and finishes the
transition.
The
Now that I've killed renderctx, and the ILK pm code no longer has
anything shared with the regular i915 context code, make the pin
arguments the same as how they were before I started.
I do not know the reason for the original pin arguments, so it's totally
possible this commit isn't necessary (an
Turn on hardware contexts for Ironlake. This leaves the code in an
awkward place where renderctx accomplishes nothing, but the code
compiles and runs, and it makes the series overall more bisectable.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/
This patch starts the migration to the core context code for Ironlake
renderctx. It is an excellent place for a bisection point due to
complaining hardware, though notice that our sample size is quite
limited given that only machines with RC6 turned on could notice
problems.
NOTE: As mentioned in
It's similar enough to the other gens that we don't really need a
distinct function to do it.
NOTE: The new function removes the MI_FLUSH that was at the end of the
old Ironlake switching code. Recent docs can find neither the
requirement for the MI_FLUSH or the MI_SUSPEND_FLUSH. Since I remember
This is required so we can use the existing do_switch() which tries to
map objects as non mappable and 64k aligned can work. Again, this is
only required in order to ease the transition over to the existing
context code.
Signed-off-by: Ben Widawsky
fixup! drm/i915: Convert renderctx to a regular
Put it with the other context code since upcoming rework/enabling will
be easier to handle with the similar code.
Also, remove the comment which is now common knowledge, and incorrect,
given that the powerctx is really the one that allows us to accomplish
this on Ironlake.
Signed-off-by: Ben Wida
By the request of Ken, and Chris, I've added support for HW contexts to
Ironlake. This is not the first time I've done this, but I think I'll
skip the somewhat ugly history on the matter.
Our existing support for Ironlake sets up 2 contexts, the powerctx, and
the renderctx. The former is stored in
The medium term plan is to just use the existing context code on ILK as
well. The conversion just assists. Therefore, this is somewhat transient
as I plan to kill renderctx quite soon.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_dr
Release 2.21.12 (2013-07-14)
In this release, we clear up the teething troubles from preserving the KMS
configuration, notably external connections on Haswell and plugging in new
outputs after startup were broken. Besides these regression fixes, there
are a couple of f
34 matches
Mail list logo
