On Thu, Nov 17, 2011 at 21:52, Keith Packard kei...@keithp.com wrote:
On Wed, 28 Sep 2011 11:57:24 +0200, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
+ char __user *end = uaddr + size - 1;
...
+ if (ret == 0) {
+ if (((unsigned long)uaddr PAGE_MASK) !=
+
Update: Just tested DP and its working!
However, it's found that hot plug under X won't work...
The previous hot plug tests are done in KMS console which are all
fine: on re-inserting the monitor, -mode_set will be called and
HDMI/DP audio will be re-enabled and ELD be transfered.
However when
On Thu, Nov 17, 2011 at 19:31, Nicolas Kalkhof nkalk...@web.de wrote:
Hi Daniel,
no problem :). Your patches look good! No hangs or stalls so far with
semaphores and rc6 switched on. However I had to disable intel_iommu since it
freezes my box shortly after firing up X :(.
Meh, so ppgtt
On 11/17/11 9:13 PM, Keith Packard wrote:
On Thu, 17 Nov 2011 17:45:40 -0500, Adam Jacksona...@redhat.com wrote:
Your silicon people worry me.
In any case, the changes are mostly to move bits around so that there
are two bits for pipe select
Yeah, the patch looks like it could be correct,
On Fri, 18 Nov 2011 10:12:38 +0100, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
We want to prefault the last byte if the pfn of the last prefault
address doesn't match the pfn of the last byte of the userspace
address range. Only happens when userspace hands in badly aligned
address, not
On Fri, 18 Nov 2011 17:37:40 +0800, Wu Fengguang fengguang...@intel.com wrote:
However when in X, -mode_set won't be called at all. Only
-get_modes and -detect are called...
The desktop software will call mode_set when it configures the
monitor. Otherwise, it's not being used (and so
From: Alan Stead alan.st...@intel.com
Fixes a compiler warning concerning an uninitialized variable.
Looks like these two (xDst_copy and yDst_copy) are just set to
(xDst and yDst) on line 1168.
---
uxa/uxa-render.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git
The width and height variables are used in the call to
CopyArea in line 1209, however they are initially set on line 1137.
The if condition to use the variables on line 1209 can only be met
if localDst is changed on line 1170, which means the variables
would have been set. This just initializes
On Thu, 17 Nov 2011 17:33:50 +0100, Takashi Iwai ti...@suse.de wrote:
If it's only with 915GM, we'll just need to change IS_PINEVEW() to
IS_PINEVIEW() || IS_I915GM(). This might be a safer option at this
moment unless we check all cases or specs...
I read through the hardware docs yesterday
On IVB C0+ with newer BIOSes, the forcewake handshake has changed. There's
now a bitfield for different driver components to keep the GT powered
on. On Linux, we centralize forcewake handling in one place, so we
still just need a single bit, but we need to use the new registers if MT
forcewake
On Fri, 18 Nov 2011 11:36:32 -0800, Jesse Barnes jbar...@virtuousgeek.org
wrote:
+ while (count++ 50 (I915_READ_NOTRACE(FORCEWAKE_MT_ACK) 1))
You said this should be 16
+ I915_WRITE_NOTRACE(FORCEWAKE_MT, (115) | 1);
and this should be 16 too
+ if
On Fri, 18 Nov 2011 14:01:00 -0800
Keith Packard kei...@keithp.com wrote:
On Fri, 18 Nov 2011 11:36:32 -0800, Jesse Barnes jbar...@virtuousgeek.org
wrote:
+ while (count++ 50 (I915_READ_NOTRACE(FORCEWAKE_MT_ACK) 1))
You said this should be 16
No this one should be looking at the
On Fri, 18 Nov 2011 14:12:03 -0800, Jesse Barnes jbar...@virtuousgeek.org
wrote:
No this one should be looking at the bottom bit, so I think it's ok.
Sorry, bad mail edit. There's one 15 in both force_wake_mt_put and
force_wake_mt_get and they both need to be 16:
+void
On Fri, 18 Nov 2011 14:35:22 -0800
Keith Packard kei...@keithp.com wrote:
On Fri, 18 Nov 2011 14:12:03 -0800, Jesse Barnes jbar...@virtuousgeek.org
wrote:
No this one should be looking at the bottom bit, so I think it's ok.
Sorry, bad mail edit. There's one 15 in both force_wake_mt_put
On Fri, 18 Nov 2011 14:48:39 -0800, Jesse Barnes jbar...@virtuousgeek.org
wrote:
So the ECOBUS reg *is* in the GT power well. Which means in order to
read it we have to disable RC6 altogether, forcibly, using the 0xa090
reg, set up force wake, then re-enable RC6.
Not surprising the ECOBUS
On Fri, 18 Nov 2011 15:27:14 -0800
Keith Packard kei...@keithp.com wrote:
On Fri, 18 Nov 2011 14:48:39 -0800, Jesse Barnes jbar...@virtuousgeek.org
wrote:
So the ECOBUS reg *is* in the GT power well. Which means in order to
read it we have to disable RC6 altogether, forcibly, using the
On Sat, Nov 19, 2011 at 01:46:44AM +0800, Keith Packard wrote:
On Fri, 18 Nov 2011 17:37:40 +0800, Wu Fengguang fengguang...@intel.com
wrote:
However when in X, -mode_set won't be called at all. Only
-get_modes and -detect are called...
The desktop software will call mode_set when it
This code is currently living on my personal git repo:
git://people.freedesktop.org/~bwidawsk/drm-intel forced_throttling
Since these are RFC, I haven't spent too much time cleaning things up.
Feel free to comment on typos, comments you feel are missing, etc. I
also haven't spent any time running
From: Daniel Vetter daniel.vet...@ffwll.ch
Only forcewake has an open with special semantics, the other r/w
debugfs only assign the file private pointer.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c |
From: Daniel Vetter daniel.vet...@ffwll.ch
All r/w debugfs files are created equal.
Signed-Off-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c | 53 ++
1 files changed, 16
After my refactoring, Chris noticed that we had a bug.
dev_priv keeps track of the current addressing mode that gets set at
execbuffer time. Unfortunately the existing code was doing this before
acquiring struct_mutex which leaves a race with another thread also
doing an execbuffer. If that
Provide a way for callers to instruct the wait request to drop
struct_mutex before the actually wait. This gives an opportunity for GPU
clients to submit independent work.
While it's tempting to make i915_wait_request always drop the lock and
enforce the caller to check their specific criteria
We will be using file_priv for scheduler things, and request list which
is useful for us isn't only mm related.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_dma.c |4 ++--
drivers/gpu/drm/i915/i915_drv.h |7 +++
drivers/gpu/drm/i915/i915_gem.c | 24
There is already a list of requests outstanding for a given client.
Keeping a count is easy, and will give a quick way to determine when a
particular client has gotten too greedy.
For now a client is uniquely identified by its file descriptor. This is a
limitation in the design which is
DRM core keeps track of open clients, but that may be include clients
which are not relevant to i915. So we keep our own count to help us
track when certain events are interesting.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_dma.c |9 +
$ cat /sys/kernel/debug/dri/0/i915_clients
PID CMD
15869 X
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c | 28
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
As of now there are only two types, fairness, and none. This can be set
using the same module parameter, and will use default values for
whatever type is chosen. Those values should be readable through
debugfs.
---
drivers/gpu/drm/i915/i915_drv.h|4
Allows users to get and set the type of GPU scheduling done in the i915
driver.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c | 30 +++---
1 files changed, 23 insertions(+), 7 deletions(-)
diff --git
While the fairness scheduler also currently uses batches to attempt to
keep things fair, that is an implementation detail. A fairness scheduler
should still be fair even if we achieve a better granularity on future
products. The batch scheduler on the other hand is meant to remain
relevant even
Module parameter only allows default high/low watermarks when batch scheduling.
Here we introduce some new debugfs parsing to allow settings per pid.
This patch is a bit more than just handling batch params as the code turned out
quite ugly as a result. So a bit of cleaning up happens here too,
RC6 should always work on IVB, and should work on SNB whenever IO
remapping is disabled. Make the default value for the parameter turn
it on in these cases. Setting the value to either 0 or 1 will force
the specified behavior.
Signed-off-by: Keith Packard kei...@keithp.com
---
Hey Dave:
Here's a pile of fixes to the intel driver. This pull includes the three
patches you already merged in, but it merges cleanly so I didn't rebase
around them.
The following changes since commit 37be944a0270402f9cda291a930b0286f6dc92f5:
Merge branch 'drm-core-next' of
On 11/18/2011 10:41 PM, Keith Packard wrote:
RC6 should always work on IVB, and should work on SNB whenever IO
remapping is disabled. Make the default value for the parameter turn
it on in these cases. Setting the value to either 0 or 1 will force
the specified behavior.
Signed-off-by:
33 matches
Mail list logo
