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 | 61 ++
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 | 96 +---
1 file changed, 55 insertions(+), 41 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
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
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
Intel-gfx@lists.freedesktop.org
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 h
This just unifies the vlv code with the snb-hsw code which matched
exactly before the VECS enabling.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_pm.c | 59 -
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i9
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 correclty (mayb that explains the strange
RING_IMR clearing in the preinstall hook
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: Reba
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.
T
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
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 20 ++--
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
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i
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 j
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 r
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 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)
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 l
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 d
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 th
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 7dedae28b41000539b6c18bc
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 d
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 th
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 Thu, Jun 27, 2013 at 05:45:29PM -0300, Paulo Zanoni wrote:
> 2013/6/12 Daniel Vetter :
> > 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 "someone is chan
Hi
On Thu, Jul 4, 2013 at 10:14 PM, Ben Widawsky 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 break a bunch
From: Paulo Zanoni
And then rename it to ironlake_irq_handler. Also move
ilk_gt_irq_handler up to avoid forward declarations.
In the previous patches I did small modifications to both
ironlake_irq_handler an ivybridge_irq_handler so they became very
similar functions. Now it should be very easy
From: Paulo Zanoni
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: Paulo Zanoni
---
drive
From: Paulo Zanoni
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 ivybridge_irq_handler.
One of the advantages
From: Paulo Zanoni
The register doesn't exist on Gen 5.
Signed-off-by: Paulo Zanoni
---
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 b/drivers/gpu/drm/i915/i915_irq.c
index c45578d..f9b97ab 100644
--
From: Paulo Zanoni
Just like we did with ilk_display_irq_handler.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 63 +++--
1 file changed, 35 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i9
From: Paulo Zanoni
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 in the last patch I add
From: Paulo Zanoni
It's the code that deals with de_iir.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_irq.c | 104 +---
1 file changed, 56 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_i
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(),
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 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 conve
On Thu, Jun 27, 2013 at 05:19:06PM -0300, Paulo Zanoni wrote:
> 2013/6/12 Daniel Vetter :
> > 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
On Thu, Jun 27, 2013 at 04:34:25PM -0300, Paulo Zanoni wrote:
> 2013/6/12 Daniel Vetter :
> > 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 too often,
> > th
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
Date: Wed Jul 3 14:45:24 2013 -07
On Mon, Jul 1, 2013 at 5:54 PM, Shuah Khan 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 work
On Thu, Jun 27, 2013 at 05:52:10PM +0200, Daniel Vetter wrote:
> Just to keep the paranoia equal also sprinkle locking asserts over the
> pipestat interrupt enable/disable functions.
>
> Again this results in false positives in the interrupt setup. Add
> bogo-locking for these and a big comment ex
On Wed, Jul 03, 2013 at 05:12:13PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> 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
Picked up for -fixes, thanks for the patch.
-Daniel
--
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.
v3: Actually squash in the right fixup.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 94 -
Signed-off-by: Ben Widawsky
---
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
--- a/drivers/gpu/drm/i915/i915_dma.c
+++
On Thu, Jul 04, 2013 at 08:43:58PM +0200, Daniel Vetter wrote:
> On Thu, Jul 4, 2013 at 8:40 PM, Ben Widawsky 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 figur
On Thu, Jul 4, 2013 at 8:40 PM, Ben Widawsky 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 rea
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 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
> >
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 overw
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
---
drivers/gpu/drm/i915/i915_debugfs.c | 94 -
drivers/gpu/drm/i91
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
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
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
---
drivers/gpu/drm/i915/i915_debugfs.c | 14 ++
1 f
From: Ben Widawsky
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 Graunke's ->pet_encode refactoring
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, 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
---
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
drivers/gpu/drm/i915/i915_reg.h | 4
2 file
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 wrote:
> > > > Yes. It won't be a requirement for me
On Thu, Jul 04, 2013 at 10:24:15AM -0300, Paulo Zanoni wrote:
> 2013/7/4 Wang xingchao :
> > On Wed, Jul 03, 2013 at 05:00:51PM -0300, Paulo Zanoni wrote:
> >> 2013/6/6 Daniel Vetter :
> >> > On Thu, May 30, 2013 at 10:07:07PM +0800, Wang Xingchao wrote:
> >> >> Hi all,
> >> >>
> >> >>This is V
2013/7/4 Wang xingchao :
> On Wed, Jul 03, 2013 at 05:00:51PM -0300, Paulo Zanoni wrote:
>> 2013/6/6 Daniel Vetter :
>> > 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:
>> >>- r
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
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/.
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 pla
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 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 Wilso
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 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
>
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 a
On Thu, Jul 4, 2013 at 12:53 PM, 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.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
Two little
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
Date: Wed May 8 10:45:14 2013 -0700
drm/i915: allow stolen, pre-all
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
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 21 +
1 fil
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
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 tran
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
Date: Wed May 8 10:45:14 2013 -0700
drm/i915: allow stolen, pre-all
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
---
drivers/gpu/drm/i915/intel_display.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/d
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
---
drivers/gpu/drm/i915/intel_
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
> > wrote:
> > > On Thu, Jul 04, 2013 at 01:26:03AM +0200, Daniel Vetter wrote:
> > >> On Thu, Jul 4, 2013 at 1:23 AM, Ch
Hi
On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky 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 break a bunch
Hi
On Wed, Jul 3, 2013 at 11:45 PM, Ben Widawsky 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 break a bunch
On Wed, Jul 03, 2013 at 05:00:51PM -0300, Paulo Zanoni wrote:
> 2013/6/6 Daniel Vetter :
> > 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 HAS_P
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 wrote:
> > > Yes. It won't be a requirement for mesa to know, but since I want to
> > > kill aliasing ppgtt as much as po
81 matches
Mail list logo
