On Thu, 2009-02-19 at 13:57 +0100, Nick Piggin wrote:
> On Thu, Feb 19, 2009 at 10:19:05AM +0100, Peter Zijlstra wrote:
> > On Wed, 2009-02-18 at 11:38 -0500, [email protected] wrote:
> > > From: Kristian Høgsberg
> > >
> > > A number of GEM operations (and legacy drm ones) want to copy data to
On Thu, Feb 19, 2009 at 8:46 PM, Alan Hourihane wrote:
> Attached is a new DRI2 flush extension that allows the driver to perform
> a "real flush" before dispatching a swap or Xserver copy operation.
>
> Currently we do this before a DRI2CopyRegion() call.
>
> This allows drivers a real "end of sc
http://bugs.freedesktop.org/show_bug.cgi?id=20235
Stefano Avallone changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
The object is dereferenced before the NULL check. Oops.
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=20235
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drive
http://bugs.freedesktop.org/show_bug.cgi?id=20235
--- Comment #1 from Stefano Avallone 2009-02-20 09:21:39
PST ---
Created an attachment (id=23140)
--> (http://bugs.freedesktop.org/attachment.cgi?id=23140)
Xorg log
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=emai
http://bugs.freedesktop.org/show_bug.cgi?id=20235
Summary: [i915] [Regression] VT switch and suspend to disk broken
Product: DRI
Version: unspecified
Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
Severity: normal
On Friday 20 February 2009 07:31:43 Barry Scott wrote:
> I saw this and thought it was wrong.
>
> int
> i915_seqno_passed(uint32_t seq1, uint32_t seq2)
> {
> return (int32_t)(seq1 - seq2) >= 0;
>
> After a bit of thinking I realized that this is doing modulas arithmetic to
> deal with the s
I saw this and thought it was wrong.
int
i915_seqno_passed(uint32_t seq1, uint32_t seq2)
{
return (int32_t)(seq1 - seq2) >= 0;
After a bit of thinking I realized that this is doing modulas arithmetic to
deal with the seqno wrapping around. Given its not obvious at first glance
you might
Hello all,
I'm seeing a bizarre problem whilst running wayland/cairo-drm/i915 under
KMS. Occasionally after pressing a key (which is handled by wayland
through the input layer) the dark regions (I'm estimating where the
value is less than ~4) become garbage. I've managed to capture a
screenshot be
On Fri, 2009-02-20 at 13:46 +0800, Zou, Nanhai wrote:
> >+struct drm_i915_gem_page_flip {
> >+/** Handle of new front buffer */
>
> Should this be handle of new front buffer or handle of the execbuf?
I can't see how this can be an execbuf here. Do you mind elaborating?
Anyway this remin
On Thu, 2009-02-19 at 16:43 -0800, Jesse Barnes wrote:
> On Thursday 19 February 2009 11:37:01 Chris Wilson wrote:
> > With a few additional suggestions by Jesse, I've managed to get
> > tear-free compositing working on i915. Here's the diff on top of the
> > original patch (though obviously this i
On Fri, 20 Feb 2009 00:54:14 -0800 (PST) David Miller
wrote:
> From: Andrew Morton
> Date: Thu, 19 Feb 2009 15:27:26 -0800
>
> > eg:
> >
> > arch/xtensa/include/asm/shmparam.h
> > #define SHMLBA ((PAGE_SIZE > DCACHE_WAY_SIZE)? PAGE_SIZE : DCACHE_WAY_SIZE)
> >
> >
> > But including linux/sh
On Fri, 2009-02-20 at 09:31 +0100, Thomas Hellstrom wrote:
> Peter Zijlstra wrote:
> > On Thu, 2009-02-19 at 22:02 +0100, Thomas Hellstrom wrote:
> >
> >>
> >> It looks to me like the driver preferred locking order is
> >>
> >> object_mutex (which happens to be the device global struct_mutex)
From: Andrew Morton
Date: Thu, 19 Feb 2009 15:27:26 -0800
> eg:
>
> arch/xtensa/include/asm/shmparam.h
> #define SHMLBA ((PAGE_SIZE > DCACHE_WAY_SIZE)? PAGE_SIZE : DCACHE_WAY_SIZE)
>
>
> But including linux/shm.h here seems a bit silly. We'll see..
If DRM even builds on XTENSA, let alone i
From: Arnd Bergmann
Date: Thu, 19 Feb 2009 15:19:01 +0100
> On Wednesday 18 February 2009, David Miller wrote:
> > drm: Only use DRM_IOCTL_UPDATE_DRAW compat wrapper for compat X86.
> >
> > Only X86 32-bit uses a different alignment for "unsigned long long"
> > than it's 64-bit counterpart.
> >
Peter Zijlstra wrote:
> On Thu, 2009-02-19 at 22:02 +0100, Thomas Hellstrom wrote:
>
>>
>> It looks to me like the driver preferred locking order is
>>
>> object_mutex (which happens to be the device global struct_mutex)
>> mmap_sem
>> offset_mutex.
>>
>> So if one could avoid using the
16 matches
Mail list logo
