On Wed, 18 Apr 2012 15:27:44 -0700
Jesse Barnes wrote:
> On Wed, 18 Apr 2012 14:25:36 -0700
> Jesse Barnes wrote:
>
> > Three pipe can only be enabled in some cases and updated docs indicate
> > a bit to control FDI B+C sharing.
> >
> > This patch adds a check to make sure we can support a giv
On Wed, 18 Apr 2012 14:25:36 -0700
Jesse Barnes wrote:
> Three pipe can only be enabled in some cases and updated docs indicate
> a bit to control FDI B+C sharing.
>
> This patch adds a check to make sure we can support a given config with
> the existing FDI lane configuration, and tries to set
On Fri, Apr 13, 2012 at 06:24:38PM +0100, Chris Wilson wrote:
> From: Jesse Barnes
>
> PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
> treat them as part of the pipe.
>
> So split the code out and manage PCH PLLs separately, allocating them
> when needed or trying to re-u
Three pipe can only be enabled in some cases and updated docs indicate
a bit to control FDI B+C sharing.
This patch adds a check to make sure we can support a given config with
the existing FDI lane configuration, and tries to set the bit as
appropriate.
We may want to go further though and just
On Sat, Apr 14, 2012 at 05:41:59PM +0100, Chris Wilson wrote:
> When the change to start adjusting the sync polarity of the LVDS mode
> was introduced in
>
> commit aa9b500ddf1a6318e7cf8b1754696edddae86db9
> Author: Bryan Freed
> Date: Wed Jan 12 13:43:19 2011 -0800
>
> drm/i915: Honour LV
On Wed, Apr 18, 2012 at 03:29:22PM -0300, Eugeni Dodonov wrote:
> The murphy's law struck in, and the previous patches I sent earlier today
> managed to wreak havoc. So much for trusting git am. Please forgive me.
>
> Those new patches I redid by hand, with base on the latest
> drm-intel-next-queu
This adds intel_pm routine for generic power-related infrastructure
initialization.
v2: now that all the platform-specific stuff is initialized in one place, we
can also add back the static definitions to platform-specific functions which
we abstract now.
Acked-by: Jesse Barnes
Acked-by: Ben Wid
This moves the clock gating-related functions into intel_pm module.
Also, please note that we do change the function type from static to
non-static in this patch for the move, to prevent breaking bisecting with
non-working intermediate commit. Those are returned back to static form in
the followin
This moves the Ironlake energy monitoring functionality into intel_pm
module.
Acked-by: Jesse Barnes
Acked-by: Ben Widawsky
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 86 --
drivers/gpu/drm/i915/intel_pm.c | 86
This moves DRPS, RPS and RC6-related functionality into intel_pm module.
It also removes the linux/cpufreq.h include from intel_display, as its
only user was the GPU turbo-related functionality in Gen6+ code path.
v2: rebase on top of latest drm-intel-next-queued adding the bits that
shifted arou
The murphy's law struck in, and the previous patches I sent earlier today
managed to wreak havoc. So much for trusting git am. Please forgive me.
Those new patches I redid by hand, with base on the latest
drm-intel-next-queued, and while doing so I also improved some of their
comments, and brought
On Wed, 2012-04-18 at 10:20 -0700, Jesse Barnes wrote:
> This indicates an internal messaging issue between the CPU and PCH, but
> there's nothing the driver can do about it. We seem to be able to
> trigger it at hotplug time sometimes, possibly due to the interrupt
> corrupting an in-flight messa
This indicates an internal messaging issue between the CPU and PCH, but
there's nothing the driver can do about it. We seem to be able to
trigger it at hotplug time sometimes, possibly due to the interrupt
corrupting an in-flight message between CPU and PCH. At any rate, the
error is harmless, so
On Wed, 18 Apr 2012 09:46:03 -0700, Guo Tang wrote:
> We have a machine running ubuntu 10.04 (kernel version 2.6.32). The
> application is simple: It has a display area of 640x480 showing image
> at about 30Hz rate.
[snip]
> The application
> drawing is through GTK/Cairo. So not sure whether the
Adam Jackson was watching the screensaver fade out and expressed a
desire for the gamma updates to be synchronized to vblank to avoid the
unsightly tears.
Reported-by: Adam Jackson
Cc: Adam Jackson
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 44
Queue the unpinning of the current plane object to after the next
vblank. For special case benchmarks and others apps that may call
set_plane at a high frequency, we can unpin their objects directly
unless they are "live".
Signed-off-by: Jesse Barnes
Signed-off-by: Chris Wilson
---
drivers/gpu/
Jesse mentioned that we had reports of flickering due to switching
clocks for powersaving and that would be a useful task to be run at
vblank.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 111 --
1 file changed, 64 insertions(+), 47 de
Upon completion of a modeset, we must wait for the next vblank before
releasing the old framebufer. (The scanout registers are double-buffered
and update on the next vblank. If we unpin the old scanout too soon we
run the risk of accessing invalid memory, so we first need to wait until
the scanout
Throughout the driver, we have a number of pieces of code that must wait
for a vblank before we can update some state. Often these could be run
asynchronously since they are merely freeing a resource no long
referenced by a double-buffered registered. So we introduce a vblank
worker upon which we q
Just a small series of patches that I like to get some feedback on.
The central goal of the series is to enable asynchronous sprite updates.
However, being able to asynchronously queue work to take place after the
next vblank is useful elsewhere so I have tried to generalise and find
some other us
On Fri, 13 Apr 2012 18:24:38 +0100
Chris Wilson wrote:
> From: Jesse Barnes
>
> PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
> treat them as part of the pipe.
>
> So split the code out and manage PCH PLLs separately, allocating them
> when needed or trying to re-use ex
On Wed, 18 Apr 2012 17:12:26 +0100
Chris Wilson wrote:
> IvyBridge requires an extra frame between disabling the low power
> watermarks and enabling scaling on the sprite plane. If the scaling
> is already enabled, then we have already disabled the low power
> watermarks and need not incur an ext
IvyBridge requires an extra frame between disabling the low power
watermarks and enabling scaling on the sprite plane. If the scaling
is already enabled, then we have already disabled the low power
watermarks and need not incur an extra wait.
Similarly, as we disable the scaling when turning off t
Jesse, can you also please check whether we need the same thing on vlv?
atm the the clock gating functions are almost identical safe for this wrt
touching registers in the gt core.
-Daniel
On Sun, Apr 15, 2012 at 10:14:24AM -0700, Ben Widawsky wrote:
> On Sun, 15 Apr 2012 11:55:36 -0300
> Eugeni D
On Wed, Apr 18, 2012 at 11:51:15AM -0300, Eugeni Dodonov wrote:
> This moves DRPS, RPS and RC6-related functionality into intel_pm module.
>
> It also removes the linux/cpufreq.h include from intel_display, as its
> only user was the GPU turbo-related functionality in Gen6+ code path.
>
> Acked-b
This adds intel_pm routine for generic power-related infrastructure
initialization.
Acked-by: Jesse Barnes
Acked-by: Ben Widawsky
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 125 +-
drivers/gpu/drm/i915/intel_drv.h | 45 +-
This moves DRPS, RPS and RC6-related functionality into intel_pm module.
It also removes the linux/cpufreq.h include from intel_display, as its
only user was the GPU turbo-related functionality in Gen6+ code path.
Acked-by: Jesse Barnes
Acked-by: Ben Widawsky
Signed-off-by: Eugeni Dodonov
---
This moves the clock gating-related functions into intel_pm module.
v2: also move the gen7_setup_fixed_func_scheduler function, introduced
after the original patches, into intel_pm as well.
Acked-by: Jesse Barnes
Acked-by: Ben Widawsky
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/in
This moves the Ironlake energy monitoring functionality into intel_pm
module.
Acked-by: Jesse Barnes
Acked-by: Ben Widawsky
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_display.c | 86 --
drivers/gpu/drm/i915/intel_pm.c | 86
The previous patch had way too long lines, this fixes them to fit into a
reasonable screen space.
Signed-off-by: Eugeni Dodonov
---
drivers/gpu/drm/i915/intel_pm.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i
This rebases the intel_pm module patches on top of the drm-intel-next-queued
(on top of 2 patches Daniel has queued already), fixes one very long comment in
the 1st patch, adds the R-b when appropriate and takes care of new
gen7_setup_fixed_func_scheduler function as well that landed in the tree af
On Wed, 18 Apr 2012 14:05:02 +0200, Daniel Vetter wrote:
> On Tue, Apr 17, 2012 at 03:31:34PM +0100, Chris Wilson wrote:
> > Rename obj->tiling_changed to obj->fence_change so that it is clear that
> > it flags when the parameters for an active fence (including the
> > no-fence) register are chang
On Tue, Apr 17, 2012 at 03:31:34PM +0100, Chris Wilson wrote:
> Rename obj->tiling_changed to obj->fence_change so that it is clear that
> it flags when the parameters for an active fence (including the
> no-fence) register are changed.
>
> Signed-off-by: Chris Wilson
I've picked up all the patc
On Tue, Apr 17, 2012 at 10:05:38AM +0100, Chris Wilson wrote:
> During modeset we have to disable the pipe to reconfigure its timings
> and maybe its size. Userspace may have queued up command buffers that
> depend upon the pipe running in a certain configuration and so the
> commands may become co
On Wed, Apr 18, 2012 at 11:12:11AM +0100, Chris Wilson wrote:
> On gen2 MI_EXE_FLUSH is actually an AGP flush bit and on gen3 marked as
> reserved. On both it is documented as being must-be-zero. So obey the
> documentation, and separate the gen2 flush into its own little routine
> and share with
On gen2 MI_EXE_FLUSH is actually an AGP flush bit and on gen3 marked as
reserved. On both it is documented as being must-be-zero. So obey the
documentation, and separate the gen2 flush into its own little routine
and share with gen3.
This means that we can rename the existing render_ring_flush()
On Tue, Apr 17, 2012 at 08:49:06AM -0700, Jesse Barnes wrote:
> On Tue, 17 Apr 2012 15:08:19 +0100
> Chris Wilson wrote:
>
> > As we need to manipulate our device structure and allocate queue a task,
> > it is no longer a simple atomic operation and cannot be performed along
> > the atomic modese
On Wed, Apr 18, 2012 at 10:25:05AM +0100, Chris Wilson wrote:
> On gen2 and gen4, MI_EXE_FLUSH is actually an AGP flush bit and is
> documented as being must-be-zero. So obey the documentation, and separate
> the gen2 flush into its own little routine and share with gen3.
MI_EXE_FLUSH on gen4 is a
On gen2 and gen4, MI_EXE_FLUSH is actually an AGP flush bit and is
documented as being must-be-zero. So obey the documentation, and separate
the gen2 flush into its own little routine and share with gen3.
This means that we can rename the existing render_ring_flush() to
reflect the generation from
On Tue, Apr 17, 2012 at 07:35:53PM +0100, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> Cc: Jesse Barnes
Queued for -next, thanks for the patch.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
On Sun, Apr 15, 2012 at 12:54:00AM +0200, Daniel Vetter wrote:
> Copy&pasted from the vlv setup code. According to docs, we need that
> on ivb, too.
>
> Cc: Ben Widawsky
> Signed-Off-by: Daniel Vetter
Ben, can you please take a look at this?
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/intel_
On Mon, Apr 16, 2012 at 09:53:16AM +0100, Chris Wilson wrote:
> On gen2, MI_EXE_FLUSH is actually an AGP flush bit and is documented as
> being must-be-zero. So obey the documentation, and separate the gen2
> flush into its own little routine.
>
> Signed-off-by: Chris Wilson
I've read up on docs
On Wed, 18 Apr 2012 11:03:03 +0200, Daniel Vetter wrote:
> Now given how well-tested that code is, I expect bugs. But imo the right
> course of action is to make that code testable first before we sprinkle
> -EIO handling all over the place. I've planned to resurrect my gpu hangman
> this week, an
On Tue, Apr 17, 2012 at 04:38:12PM +0100, Chris Wilson wrote:
> The (2<<6) virtual memory space selector harks back to gen3 and is
> mandatory given our use of GTT space for batchbuffers. On gen4+, use of
> the GTT became mandatory and bit6 marked reserved. However the code must
> now explicitly se
On Tue, Apr 17, 2012 at 07:20:35PM -0700, Ben Widawsky wrote:
> On Tue, 17 Apr 2012 22:39:15 -0300
> Paulo Zanoni wrote:
>
> > 2012/4/16 Ben Widawsky :
> > > Sparse doesn't like:
> > > "error: bad constant expression"
> > >
> >
> >
> > I know you'll hate me for asking, but: how difficult is it
On Wed, 18 Apr 2012 10:51:29 +0200, Daniel Vetter wrote:
> On Sat, Apr 14, 2012 at 09:55:49AM +0100, Chris Wilson wrote:
> > i915_gem_idle() is called when we need to suspend the GPU. If the GPU is
> > already suspended by this point due to being wedged, we can safely
> > continue.
> >
> > Signed
On Sat, Apr 14, 2012 at 09:55:47AM +0100, Chris Wilson wrote:
> If we fail to flush the rendering to an object already bound to the GTT
> because the hardware is edge, all is good!
>
> Signed-off-by: Chris Wilson
As already quickly discussed on irc, I'm not too happy about -EIO special
casing in
On Sat, Apr 14, 2012 at 09:55:49AM +0100, Chris Wilson wrote:
> i915_gem_idle() is called when we need to suspend the GPU. If the GPU is
> already suspended by this point due to being wedged, we can safely
> continue.
>
> Signed-off-by: Chris Wilson
Imo the right way to fix this case here is by
On Sun, Apr 15, 2012 at 12:00:35AM +0200, Daniel Vetter wrote:
> On Sat, Apr 14, 2012 at 09:55:51AM +0100, Chris Wilson wrote:
> > As we defer updating the fence register from set-tiling to the point of
> > use, we need to declare every access through the GTT as either fenced or
> > unfenced.
> >
On Tue, Apr 17, 2012 at 11:50:11PM +0200, Daniel Vetter wrote:
> On Tue, Apr 17, 2012 at 05:19:45PM -0400, Adam Jackson wrote:
> > On Tue, 2012-04-17 at 20:37 +0100, Chris Wilson wrote:
> > > Not only do the pageflip work without it at non-native modes (i.e. with
> > > the panel fitter enabled), it
On Wed, 18 Apr 2012 07:53:36 +, "Lawrynowicz, Jacek"
wrote:
> But how would I synchronize GPU and CPU clocks without access to the
> TIMESTAMP
> register?
Issue a pipecontrol, compensate for the execution latency.
> And are you sure that over time both clocks won't desynchronize?
Given the
But how would I synchronize GPU and CPU clocks without access to the TIMESTAMP
register?
And are you sure that over time both clocks won't desynchronize?
Do you all agree that this functionality should not be implemented in the
kernel?
Regards,
Jacek
-Original Message-
From: Chris Wils
On Wed, 18 Apr 2012 06:32:04 +, "Lawrynowicz, Jacek"
wrote:
> I think that ioctl to get GPU timestamp and its resolution would be the best
> approach.
> This ioctl won't be called very often so there's no need to sacrifice
> simplicity for performance in this case.
> Using clock_gettime() s
On Tue, Apr 17, 2012 at 11:18:46PM +0100, Chris Wilson wrote:
> On Tue, 17 Apr 2012 15:06:33 -0700, Jesse Barnes
> wrote:
> > Like this?
> >
> > From fee9f6fbf2230f96b9195baf32fd67b243969a14 Mon Sep 17 00:00:00 2001
> > From: Jesse Barnes
> > Date: Wed, 11 Apr 2012 09:23:34 -0700
> > Subject: [
54 matches
Mail list logo
