On Wed, Jul 03, 2013 at 03:00:39PM -0700, Ben Widawsky wrote:
On Wed, Jul 03, 2013 at 11:58:31PM +0200, Daniel Vetter wrote:
On Wed, Jul 3, 2013 at 11:44 PM, Ben Widawsky b...@bwidawsk.net wrote:
Yes. It won't be a requirement for mesa to know, but since I want to
kill aliasing ppgtt as
On Wed, Jul 03, 2013 at 05:00:51PM -0300, Paulo Zanoni wrote:
2013/6/6 Daniel Vetter dan...@ffwll.ch:
On Thu, May 30, 2013 at 10:07:07PM +0800, Wang Xingchao wrote:
Hi all,
This is V7 and here're some changes notes:
change from V6--V7:
- rename variable
- use
Hi
On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky b...@bwidawsk.net wrote:
For an upcoming patch where we introduce the i915 VMA, it's ideal to
have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
Part of the conversion to VMAs is to kill off obj-gtt_space. Doing this
will
Hi
On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky b...@bwidawsk.net wrote:
For an upcoming patch where we introduce the i915 VMA, it's ideal to
have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
Part of the conversion to VMAs is to kill off obj-gtt_space. Doing this
will
On Thu, Jul 04, 2013 at 12:55:08AM +0100, Chris Wilson wrote:
On Thu, Jul 04, 2013 at 01:38:05AM +0200, Daniel Vetter wrote:
On Thu, Jul 4, 2013 at 1:33 AM, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Thu, Jul 04, 2013 at 01:26:03AM +0200, Daniel Vetter wrote:
On Thu, Jul 4, 2013
This makes sparse happy and also makes it a bit more obvious where we
pull off this trick - after all we're only allowed to do it eithe as a
default or on platforms where there is no disdinction between the pipe
and the cpu transcoder.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
We only do this on IBX where there's a fixed pch dpll to pipe
assignment. Being explicit about it can't really hurt and makes
sparse happy.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_display.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
A magic -1 is a obscure, especially since it's actually passed as an
unsigned, so depens upon the magic sign extension rules in C. This has
been added in
commit 3727d55e4d85836aa6cb759a965daaef88074150
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Wed May 8 10:45:14 2013 -0700
On Thu, Jul 04, 2013 at 12:01:15PM +0200, Daniel Vetter wrote:
This makes sparse happy and also makes it a bit more obvious where we
pull off this trick - after all we're only allowed to do it eithe as a
default or on platforms where there is no disdinction between the pipe
and the cpu
On Thu, Jul 04, 2013 at 12:22:34PM +0200, Daniel Vetter wrote:
A magic -1 is a obscure, especially since it's actually passed as an
unsigned, so depens upon the magic sign extension rules in C. This has
been added in
commit 3727d55e4d85836aa6cb759a965daaef88074150
Author: Jesse Barnes
Sanity check that the memory region found through the Graphics Base
of Stolen Memory is reserved and hidden from the rest of the system
through the use of the resource API.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Daniel Vetter daniel.vet...@ffwll.ch
---
A magic -1 is a obscure, especially since it's actually passed as an
unsigned, so depens upon the magic sign extension rules in C. This has
been added in
commit 3727d55e4d85836aa6cb759a965daaef88074150
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Wed May 8 10:45:14 2013 -0700
On Thu, Jul 4, 2013 at 12:53 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
Sanity check that the memory region found through the Graphics Base
of Stolen Memory is reserved and hidden from the rest of the system
through the use of the resource API.
Signed-off-by: Chris Wilson
Sanity check that the memory region found through the Graphics Base
of Stolen Memory is reserved and hidden from the rest of the system
through the use of the resource API.
v2: Graphics Stolen Memory is such a more bodacious name than the lame
i915 stolen, and convert to using devres for
On Thu, Jul 04, 2013 at 01:06:28PM +0200, Daniel Vetter wrote:
A magic -1 is a obscure, especially since it's actually passed as an
unsigned, so depens upon the magic sign extension rules in C. This has
s/depens/depends/.
been added in
commit 3727d55e4d85836aa6cb759a965daaef88074150
On Wed, Jul 03, 2013 at 02:45:23PM -0700, Ben Widawsky wrote:
With the getters in place from the previous patch this members serves no
purpose other than saving one spare pointer chase, which will be killed
in the next patch anyway.
Moving to VMAs, this members adds unnecessary confusion
On Wed, Jul 03, 2013 at 02:45:24PM -0700, Ben Widawsky wrote:
Shortly we'll want to switch to an embedded drm_mm_node per object, and
therefore using pointers as we're doing is unfeasible.
I've chosen an impossible gtt start offset as the way to denote a
reservation.
CC: Chris Wilson
On Wed, Jul 03, 2013 at 02:45:25PM -0700, Ben Widawsky wrote:
Embedding the node in the obj is more natural in the transition to VMAs
which will also have embedded nodes. This change also helps transition
away from put_block to remove node.
Though it's quite an uncommon occurrence, it's
On Thu, Jul 04, 2013 at 11:23:52AM +0100, Damien Lespiau wrote:
On Thu, Jul 04, 2013 at 12:01:15PM +0200, Daniel Vetter wrote:
This makes sparse happy and also makes it a bit more obvious where we
pull off this trick - after all we're only allowed to do it eithe as a
default or on platforms
On Thu, Jul 04, 2013 at 12:31:37PM +0100, Chris Wilson wrote:
On Thu, Jul 04, 2013 at 01:06:28PM +0200, Daniel Vetter wrote:
A magic -1 is a obscure, especially since it's actually passed as an
unsigned, so depens upon the magic sign extension rules in C. This has
s/depens/depends/.
Fixed
On Thu, Jul 04, 2013 at 12:28:35PM +0100, Chris Wilson wrote:
Sanity check that the memory region found through the Graphics Base
of Stolen Memory is reserved and hidden from the rest of the system
through the use of the resource API.
v2: Graphics Stolen Memory is such a more bodacious name
2013/7/4 Wang xingchao xingchao.w...@linux.intel.com:
On Wed, Jul 03, 2013 at 05:00:51PM -0300, Paulo Zanoni wrote:
2013/6/6 Daniel Vetter dan...@ffwll.ch:
On Thu, May 30, 2013 at 10:07:07PM +0800, Wang Xingchao wrote:
Hi all,
This is V7 and here're some changes notes:
change
On Thu, Jul 04, 2013 at 10:24:15AM -0300, Paulo Zanoni wrote:
2013/7/4 Wang xingchao xingchao.w...@linux.intel.com:
On Wed, Jul 03, 2013 at 05:00:51PM -0300, Paulo Zanoni wrote:
2013/6/6 Daniel Vetter dan...@ffwll.ch:
On Thu, May 30, 2013 at 10:07:07PM +0800, Wang Xingchao wrote:
Hi
On Thu, Jul 04, 2013 at 10:54:58AM +0300, Ville Syrjälä wrote:
On Wed, Jul 03, 2013 at 03:00:39PM -0700, Ben Widawsky wrote:
On Wed, Jul 03, 2013 at 11:58:31PM +0200, Daniel Vetter wrote:
On Wed, Jul 3, 2013 at 11:44 PM, Ben Widawsky b...@bwidawsk.net wrote:
Yes. It won't be a
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 means.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
The eLLC cannot be determined by PCIID because as far as we know, even
machines supporting eLLC may not have it enabled, or fused off or
whatever. It's possible this isn't actually true, and at that point we
can switch to a DEV_INFO flag instead.
I've defined everything where the docs are clear,
From: Ben Widawsky benjamin.widaw...@intel.com
The cacheability controls have changed, and the bits have been
rearranged in general.
v2: Remove comments for snb/ivb cache leves, that's a separate change.
v3: Resolve conflicts due to patch series reordering.
v4: Rebased on top of Kenneth
DRI clients really should be using MOCS to get fine grained streaming
cache controls. With that note, I *hope* that this patch doesn't improve
performance overwhelmingly, because if it does - it means there is a
problem elsewhere.
In any case, the kernel, and old userspace should get some benefit
To make users life a little easier figuring out what they have on their
system.
Ideally, I'd really like to report LLC size, but it turned out to be a
bit of a pain. Maybe I'll revisit it in the future.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c | 14
On Thu, Jul 04, 2013 at 11:02:07AM -0700, Ben Widawsky wrote:
To make users life a little easier figuring out what they have on their
system.
Ideally, I'd really like to report LLC size, but it turned out to be a
bit of a pain. Maybe I'll revisit it in the future.
Signed-off-by: Ben
On Thu, Jul 04, 2013 at 11:02:06AM -0700, Ben Widawsky wrote:
DRI clients really should be using MOCS to get fine grained streaming
cache controls. With that note, I *hope* that this patch doesn't improve
performance overwhelmingly, because if it does - it means there is a
problem elsewhere.
At least for the common cases where we only need special file
operations. The forcewake file is still rather more special.
v2: Fix up the debugfs unregister code.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_debugfs.c | 94
On Thu, Jul 04, 2013 at 08:14:41PM +0200, Daniel Vetter wrote:
On Thu, Jul 04, 2013 at 11:02:07AM -0700, Ben Widawsky wrote:
To make users life a little easier figuring out what they have on their
system.
Ideally, I'd really like to report LLC size, but it turned out to be a
bit of a
On Thu, Jul 04, 2013 at 08:17:09PM +0200, Daniel Vetter wrote:
On Thu, Jul 04, 2013 at 11:02:06AM -0700, Ben Widawsky wrote:
DRI clients really should be using MOCS to get fine grained streaming
cache controls. With that note, I *hope* that this patch doesn't improve
performance
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 is we don't have
the ability to use forcewake until after the pte functions have been set
up.
Since all solutions are somewhat ugly (barring
On Thu, Jul 4, 2013 at 8:40 PM, Ben Widawsky b...@bwidawsk.net wrote:
On Thu, Jul 04, 2013 at 08:14:41PM +0200, Daniel Vetter wrote:
On Thu, Jul 04, 2013 at 11:02:07AM -0700, Ben Widawsky wrote:
To make users life a little easier figuring out what they have on their
system.
Ideally, I'd
On Thu, Jul 04, 2013 at 08:43:58PM +0200, Daniel Vetter wrote:
On Thu, Jul 4, 2013 at 8:40 PM, Ben Widawsky b...@bwidawsk.net wrote:
On Thu, Jul 04, 2013 at 08:14:41PM +0200, Daniel Vetter wrote:
On Thu, Jul 04, 2013 at 11:02:07AM -0700, Ben Widawsky wrote:
To make users life a little
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
include/uapi/drm/i915_drm.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 7eda8ab..435fc4a 100644
---
On Wed, Jul 03, 2013 at 05:12:13PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Now that the audio driver is using our power well API, everything
should be working correctly, so let's give it a try.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
Picked up
On Mon, Jul 1, 2013 at 5:54 PM, Shuah Khan shuah...@samsung.com wrote:
On 06/26/2013 04:24 PM, Shuah Khan wrote:
On 06/26/2013 04:12 PM, Winkler, Tomas wrote:
42f132f mei: me: clear interrupts on the resume path
2753ff5 mei: nfc: fix nfc device freeing
5e85b36 mei: init: Flush scheduled
Setting the node directly is good enough. We don't need a special value
to store the gtt_offset, and we no longer have the pointer to tuck
things away neatly.
This is temporarily broken since:
commit 7dedae28b41000539b6c18bcf72107c97e4937e4
Author: Ben Widawsky b...@bwidawsk.net
Date: Wed Jul 3
On Thu, Jun 27, 2013 at 04:34:25PM -0300, Paulo Zanoni wrote:
2013/6/12 Daniel Vetter daniel.vet...@ffwll.ch:
The preinstallhook is supposed to clear all interrupts. Doing it
again in the postinstall hook has the risk that we're eating
an interrupt source from the handler. If that happens
On Thu, Jun 27, 2013 at 05:19:06PM -0300, Paulo Zanoni wrote:
2013/6/12 Daniel Vetter daniel.vet...@ffwll.ch:
The current code won't report any fifo underruns on cpt if just one
pipe has fifo underrun reporting disabled. We can't enable the
interrupts, but we can still check the
On Thu, Jul 04, 2013 at 11:19:58AM +0200, David Herrmann wrote:
Hi
On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky b...@bwidawsk.net wrote:
For an upcoming patch where we introduce the i915 VMA, it's ideal to
have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
Part of
For an upcoming patch where we introduce the i915 VMA, it's ideal to
have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
Part of the conversion to VMAs is to kill off obj-gtt_space. Doing this
will break a bunch of code, but amongst them are 2 callers of
drm_mm_create_block(),
From: Paulo Zanoni paulo.r.zan...@intel.com
It's the code that deals with de_iir.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 104 +---
1 file changed, 56 insertions(+), 48 deletions(-)
diff --git
From: Paulo Zanoni paulo.r.zan...@intel.com
This is something that have always bothered me: we have two functions that do
almost the same thing, but their implementations are quite different. On this
series I try to reorganize the two irq handlers so their implementations become
very similar, and
From: Paulo Zanoni paulo.r.zan...@intel.com
The register doesn't exist on Gen 5.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c
From: Paulo Zanoni paulo.r.zan...@intel.com
Just like we did with ilk_display_irq_handler.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c | 63 +++--
1 file changed, 35 insertions(+), 28 deletions(-)
diff --git
From: Paulo Zanoni paulo.r.zan...@intel.com
The ironlake_irq_handler and ivybridge_irq_handler functions do
basically the same thing, but they have different implementation
styles. With this patch we reorganize ironlake_irq_handler in a way
that makes it look very similar to
From: Paulo Zanoni paulo.r.zan...@intel.com
We have this POSTING_READ inside ironlake_irq_handler. I suppose we
also want it on IVB because we want to stop the IRQ handler as soon as
possible at this point. Also, I'll add ILK/SNB support to
ivybridge_irq_handler on the next patch.
Signed-off-by:
Hi
On Thu, Jul 4, 2013 at 10:14 PM, Ben Widawsky b...@bwidawsk.net wrote:
For an upcoming patch where we introduce the i915 VMA, it's ideal to
have the drm_mm_node as part of the VMA struct (ie. it's pre-allocated).
Part of the conversion to VMAs is to kill off obj-gtt_space. Doing this
will
On Thu, Jun 27, 2013 at 05:45:29PM -0300, Paulo Zanoni wrote:
2013/6/12 Daniel Vetter daniel.vet...@ffwll.ch:
It's racy: There's no guarantee that we won't walk this code (due to a
pch fifo underrun interrupt) while someone is changing the pointers
around.
Can you please exemplify the
On Fri, Jun 28, 2013 at 10:24:32AM -0700, Ben Widawsky wrote:
On Wed, Jun 12, 2013 at 01:37:20PM +0200, Daniel Vetter wrote:
With the simplified locking there's no reason any more to keep the
refcounts seperate.
I guess my nitpick from previous patch is echoed here. The reason still
On Fri, Jun 28, 2013 at 10:01:12AM -0700, Ben Widawsky wrote:
On Wed, Jun 12, 2013 at 01:37:22PM +0200, Daniel Vetter wrote:
Preinstall disables interrupts, we clear the status register in the
postinstall hook before we actually enable interrupt sources.
Also add a comment for the curios
On Fri, Jun 28, 2013 at 10:26:37AM -0700, Ben Widawsky wrote:
On Wed, Jun 12, 2013 at 01:37:23PM +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
On Thu, Jul 04, 2013 at 12:42:15PM -0700, Ben Widawsky wrote:
Setting the node directly is good enough. We don't need a special value
to store the gtt_offset, and we no longer have the pointer to tuck
things away neatly.
This is temporarily broken since:
commit
This way all changes to SDEIMR all go through the same function, with
the exception of the (single-threaded) setup/teardown code.
For paranoia again add an assert_spin_locked.
v2: For even more paranoia also sprinkle a spinlock assert over
cpt_can_enable_serr_int since we need to have that one
Hi all,
So I've hopefully taken all review feedback into account, fixed a few other
things on top (accessing gen6+ PM registers on ilk mostly) and polished the turd
otherwise.
I've also tried to come up with some infrastructure to reproduce fifo underruns
for testing so that we can make sure we
Same treatment as for SERR_INT: If we clear only the bit for the pipe
we're enabling (but unconditionally) then we can always check for
possible underruns after having disabled the interrupt. That way pipe
underruns won't be lost, but at worst only get reported in a delayed
fashion.
v2: The same
The current code won't report any fifo underruns on cpt if just one
pipe has fifo underrun reporting disabled. We can't enable the
interrupts, but we can still check the per-transcoder bits and so
report the underrun delayed if:
- We always clear the transcoder's bit (and none of the other bits)
It's racy: There's no guarantee that we won't walk this code (due to a
pch fifo underrun interrupt) while someone is changing the pointers
around.
The only reason we do this is to use the righ crtc for the pch fifo
underrun accounting. But we never expose this to userspace, so
essentially no one
Since we only have one interrupt handler and interrupt handlers are
non-reentrant.
To drive the point really home give them all an _irq_handler suffix.
This is a tiny micro-optimization but even more important it makes it
clearer what locking we actually need. And in case someone screws this
up:
The if (pm_iir ~GEN6_PM_RPS_EVENTS) check was redunandant. Otoh
adding a check for rps events allows us to avoid the spinlock grabbing
for VECS interrupts.
v2: Drop misplaced hunk which now moved to the right patch.
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Daniel Vetter
And kill the comment about it. Queueing work is a barrier type event,
no amount of locking will help in ordering things (as long as we queue
the work after having updated all relevant data structures). Also, the
queue_work works itself as a sufficient memory barrier.
Again on the surface this is
Now that the rps interrupt locking isn't clearly separated (at elast
conceptually) from all the other interrupt locking having a different
lock stopped making sense: It protects much more than just the rps
workqueue it started out with. But with the addition of VECS the
separation started to blurr
With the simplified locking there's no reason any more to keep the
refcounts seperate.
v2: Readd the lost comment that ring-irq_refcount is protected by
dev_priv-irq_lock.
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
The code to handle it is broken - there's simply no code to clear CS
parser errors on gen5+. And behold, for all the other rings we also
don't enable it!
Leave the handling code itself in place just to be consistent with the
existing mess though. And in case someone feels like fixing it all up.
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 this code in 3 places
now, extract it into its own little helper.
v3:
This just unifies the vlv code with the snb-hsw code which matched
exactly before the VECS enabling.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_pm.c | 59 -
1 file changed, 29 insertions(+), 30 deletions(-)
diff
At the moment we have the following interrupt enabling sequence:
1. irq preinstall hook
2. enabling the interrupt handler and calling irq postinstall hook
3. enable rps interrupts from the async work
And the folliwing disable sequence:
1. disabling the interrupt handler and calling the uninstall
This is an old series to make sprite and primary plane flip that little
bit more asynchronous. Shaving 16-20ms off X start up time is no small
feat when we can start X in around 100-200ms.
-Chris
___
Intel-gfx mailing list
If we are forced to do an uninterruptible wait for a result from the
GPU, boost the qos of DMA operations to minimise the latency and
minimise the amount of time spent waiting for the operation whilst
uninterruptible.
This shaves a modicum of time off waiting for GPU operations to
complete before
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
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 jbar...@virtuousgeek.org
Signed-off-by: Chris
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.
Find some testers
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 96
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 a...@redhat.com
Cc: Adam Jackson a...@redhat.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
77 matches
Mail list logo
