https://bugs.freedesktop.org/show_bug.cgi?id=41569
--- Comment #24 from lone...@kapsi.fi 2012-02-03 23:12:13 PST ---
> The patch (in comment 22) on top of v3.2.2 works fine with kms on my Asus
> a53t..
Works on the ProBook too.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?ta
https://bugs.freedesktop.org/show_bug.cgi?id=45018
Jerome Glisse changed:
What|Removed |Added
Version|git |8.0
--- Comment #12 from Jerome Glisse
I've got a VersaLogic Ocelot (Atom Z530, Menlow) and I've been test
driving the new GMA500 driver w/out much luck. I tried the old
staging driver a few times, and just compiled and tested a checkout
from Linus' tree (d12566). I've got the gma500 driver compiled as a
module, with the optional part
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #13 from Alexandre Demers 2012-02-03
19:26:16 PST ---
(In reply to comment #12)
> Can you please record an apitrace of the affected test. Thank you
>
> https://github.com/apitrace
I'll try it during the weekend. I should be able to
https://bugs.freedesktop.org/show_bug.cgi?id=42162
Alex Deucher changed:
What|Removed |Added
AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at
lists.freedesktop
ELAN Limited
http://www.onelan.com/
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120203/f8d28b91/attachment-0001.pgp>
other no-lvds patch. I'd also like Adam to
>> > ack it, so put him on cc when resubmitting.
>>
>> I would like to see my question addressed before acking. Pretty sure
>> dmi matching is case sensitive.
>>
>> - ajax
>>
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120203/1eec7a6b/attachment.htm>
On Fri, Feb 3, 2012 at 4:30 PM, Simon Farnsworth
wrote:
> Hello,
>
> I've run out of time to work on this, as I have a fix (the unused BO trick)
> that's good enough for my needs. I've taken Christian's patches (1 and 2 of
> this series) and added the obvious ioctl interface on top, enabling
> use
Provide a mechanism for userspace to wait for kernel fences, and teach the
CS ioctl to return enough information to let userspace use this mechanism.
This mechanism isn't safe to include as-is, as there is no way for the CS
ioctl to indicate that it hasn't given you the information needed to let y
From: Christian K?nig
To support waiting for fence values from usermode.
Signed-off-by: Christian K?nig
---
Again, unchanged from Christian's original work
drivers/gpu/drm/radeon/radeon_fence.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/driv
From: Christian K?nig
They are protected by a read/write lock anyway, so
we actually don't need to use the atomic type.
Signed-off-by: Christian K?nig
---
Unchanged from Christian's original work.
drivers/gpu/drm/radeon/radeon.h |6 +++---
drivers/gpu/drm/radeon/radeon_fence.c | 2
Hello,
I've run out of time to work on this, as I have a fix (the unused BO trick)
that's good enough for my needs. I've taken Christian's patches (1 and 2 of
this series) and added the obvious ioctl interface on top, enabling
userspace to wait for a kernel fence *if* the kernel gives it some opaq
On Fri, Feb 03, 2012 at 10:08:12AM +, Dave Airlie wrote:
> On Wed, Feb 1, 2012 at 1:05 PM, Sascha Hauer wrote:
> > On Wed, Feb 01, 2012 at 07:55:40AM -0500, David Airlie wrote:
> >>
> >>
> >> > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> >> > > index 8d593ad..cdbbb40 10064
From: Dave Airlie
This is an RFC for an idea I had to make GPU lockup recovery less likely to
deadlock.
This starts using error values for the gpu lockup and fence signalling.
We can now return more information, like whether the GPU is in reset
-EAGAIN, or crashed -EIO, or fence is busy -EBUSY
https://bugs.freedesktop.org/show_bug.cgi?id=45018
Jerome Glisse changed:
What|Removed |Added
Version|git |8.0
--- Comment #12 from Jerome Glisse
Hello,
Here is the patch made from the git git://
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
The dmidecode for hp t5745 and hp st5747 are attached to their respective
bugs:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911916
https://bugs.launchpad.net/ubuntu/+source/linux/
Performing a flicker-free boot involves being able to ensure that we don't
write to the memory that's currently being scanned out, which means we need
to be able to allocate a block that matches the current framebuffer in
order to prevent that. This adds support for reading out the current
framebuf
The instmem setup code may allocate from the region that's currently being
scanned out, but we can't allocate a buffer object to cover that until the
generic vram code has been run. Flip the order to make this possible.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/nouveau/nouveau_state.c |
Add core support for allocating buffer objects that cover the existing
framebuffers at startup.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/nouveau/nouveau_drv.h |2 ++
drivers/gpu/drm/nouveau/nouveau_mem.c |4
drivers/gpu/drm/nouveau/nouveau_state.c |9 -
3 f
We want to be able to guarantee the location of the allocated buffer
object if we're going to be able to reliably allocate the existing
framebuffer at startup. Add an argument to do so and pass that through to
the ttm core.
Signed-off-by: Matthew Garrett
---
drivers/bcma/main.c
On Fri, 3 Feb 2012 10:15:41 +
Dave Airlie wrote:
> On Thu, Feb 2, 2012 at 3:17 PM, Alan Cox wrote:
> > (Resending in two bits to avoid stgit breakage)
>
> Hi Alan,
>
> Any of these important enough for -fixes? or -next good enough?
The cache one maybe the others can wait. Both though are
https://bugs.freedesktop.org/show_bug.cgi?id=42162
Alex Deucher changed:
What|Removed |Added
AssignedTo|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
The function radeon_bo_list_validate can cause a
bo to move, resulting in a different sync_obj
and a dependency to wait for this move to finish.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon.h|1 -
drivers/gpu/drm/radeon/radeon_cs.c | 21 ++---
2 file
Performing a flicker-free boot involves being able to ensure that we don't
write to the memory that's currently being scanned out, which means we need
to be able to allocate a block that matches the current framebuffer in
order to prevent that. This adds support for reading out the current
framebuf
The instmem setup code may allocate from the region that's currently being
scanned out, but we can't allocate a buffer object to cover that until the
generic vram code has been run. Flip the order to make this possible.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/nouveau/nouveau_state.c |
We want to be able to guarantee the location of the allocated buffer
object if we're going to be able to reliably allocate the existing
framebuffer at startup. Add an argument to do so and pass that through to
the ttm core.
Signed-off-by: Matthew Garrett
---
drivers/bcma/main.c
Add core support for allocating buffer objects that cover the existing
framebuffers at startup.
Signed-off-by: Matthew Garrett
---
drivers/gpu/drm/nouveau/nouveau_drv.h |2 ++
drivers/gpu/drm/nouveau/nouveau_mem.c |4
drivers/gpu/drm/nouveau/nouveau_state.c |9 -
3 f
On Thu, Feb 2, 2012 at 2:13 PM, Sascha Hauer wrote:
> Hi David,
>
> On Wed, Feb 01, 2012 at 11:38:18AM +0100, Sascha Hauer wrote:
>> The following patches contain some fixes and cleanups for the drm
>> core.
>>
>> - fix memory holes
>> - make some initialization / deinitialization more symmetric
>
On Thu, Feb 2, 2012 at 3:17 PM, Alan Cox wrote:
> (Resending in two bits to avoid stgit breakage)
Hi Alan,
Any of these important enough for -fixes? or -next good enough?
Dave.
On Wed, Feb 1, 2012 at 1:05 PM, Sascha Hauer wrote:
> On Wed, Feb 01, 2012 at 07:55:40AM -0500, David Airlie wrote:
>>
>>
>> > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> > > index 8d593ad..cdbbb40 100644
>> > > --- a/include/drm/drm_crtc.h
>> > > +++ b/include/drm/drm_crtc.h
On Wed, Feb 1, 2012 at 10:38 AM, Sascha Hauer wrote:
> The fb helper uses fixed size arrays for the associated crtcs.
> This is an unnecessary limitation, so instead use a list to
> store the crtcs and allocate them dynamically.
I need more reasons on why this is a unnecessary limitation, for wha
On Fri, Jan 27, 2012 at 9:40 PM, Daniel Vetter
wrote:
> CEA actually specifies an interlaced mode with even vtotal and
> supplies a diagram showing how this is supposed to work.
>
> Note that interlaced modes with an even vtotal seem to be a fairly
> recent invention. All modelines lore I could d
2012/2/3 Christian K?nig :
> The function radeon_bo_list_validate can cause a
> bo to move, resulting in a different sync_obj
> and a dependency to wait for this move to finish.
>
> Signed-off-by: Christian K?nig
Reviewed-by: Alex Deucher
> ---
> ?drivers/gpu/drm/radeon/radeon.h ? ?| ? ?1 -
> ?
On Friday 3 February 2012, Dave Airlie wrote:
> On Fri, Feb 3, 2012 at 4:30 PM, Simon Farnsworth
> wrote:
> > As I've got the fix I need (Mesa-dev message "[PATCH] r600g: Use a fake
> > reloc to sleep for fences"), I can't really justify continuing to work on
> > this, so I'm putting out what I'v
On Fri, Feb 3, 2012 at 4:30 PM, Simon Farnsworth
wrote:
> Hello,
>
> I've run out of time to work on this, as I have a fix (the unused BO trick)
> that's good enough for my needs. I've taken Christian's patches (1 and 2 of
> this series) and added the obvious ioctl interface on top, enabling
> use
Provide a mechanism for userspace to wait for kernel fences, and teach the
CS ioctl to return enough information to let userspace use this mechanism.
This mechanism isn't safe to include as-is, as there is no way for the CS
ioctl to indicate that it hasn't given you the information needed to let y
From: Christian König
To support waiting for fence values from usermode.
Signed-off-by: Christian König
---
Again, unchanged from Christian's original work
drivers/gpu/drm/radeon/radeon_fence.c | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/driv
From: Christian König
They are protected by a read/write lock anyway, so
we actually don't need to use the atomic type.
Signed-off-by: Christian König
---
Unchanged from Christian's original work.
drivers/gpu/drm/radeon/radeon.h |6 +++---
drivers/gpu/drm/radeon/radeon_fence.c | 2
Hello,
I've run out of time to work on this, as I have a fix (the unused BO trick)
that's good enough for my needs. I've taken Christian's patches (1 and 2 of
this series) and added the obvious ioctl interface on top, enabling
userspace to wait for a kernel fence *if* the kernel gives it some opaq
From: Dave Airlie
This is an RFC for an idea I had to make GPU lockup recovery less likely to
deadlock.
This starts using error values for the gpu lockup and fence signalling.
We can now return more information, like whether the GPU is in reset
-EAGAIN, or crashed -EIO, or fence is busy -EBUSY
2012/2/3 Christian König :
> The function radeon_bo_list_validate can cause a
> bo to move, resulting in a different sync_obj
> and a dependency to wait for this move to finish.
>
> Signed-off-by: Christian König
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon.h | 1 -
>
On Fri, 3 Feb 2012 10:15:41 +
Dave Airlie wrote:
> On Thu, Feb 2, 2012 at 3:17 PM, Alan Cox wrote:
> > (Resending in two bits to avoid stgit breakage)
>
> Hi Alan,
>
> Any of these important enough for -fixes? or -next good enough?
The cache one maybe the others can wait. Both though are
unable to have a working radeon kms framebuffer with linux-3.2.2 on ppc
video card: Radeon X1650PRO PCIE
here the boot log:
U-Boot 2010.06.05 (Jul 05 2011 - 17:53:34)
CPU: AMCC PowerPC 460EX Rev. B at 1166.667 MHz (PLB=233 OPB=116 EBC=116)
No Security/Kasumi support
Bootstrap O
unable to have a working radeon kms framebuffer with linux-3.2.2 on ppc
video card: Radeon 9250 PCI
here the boot log:
U-Boot 2010.06.05 (Jul 05 2011 - 17:53:34)
CPU: AMCC PowerPC 460EX Rev. B at 1166.667 MHz (PLB=233 OPB=116 EBC=116)
No Security/Kasumi support
Bootstrap Option H
On Thu, Feb 2, 2012 at 2:13 PM, Sascha Hauer wrote:
> Hi David,
>
> On Wed, Feb 01, 2012 at 11:38:18AM +0100, Sascha Hauer wrote:
>> The following patches contain some fixes and cleanups for the drm
>> core.
>>
>> - fix memory holes
>> - make some initialization / deinitialization more symmetric
>
On Thu, Feb 2, 2012 at 3:17 PM, Alan Cox wrote:
> (Resending in two bits to avoid stgit breakage)
Hi Alan,
Any of these important enough for -fixes? or -next good enough?
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.fr
On Wed, Feb 1, 2012 at 1:05 PM, Sascha Hauer wrote:
> On Wed, Feb 01, 2012 at 07:55:40AM -0500, David Airlie wrote:
>>
>>
>> > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> > > index 8d593ad..cdbbb40 100644
>> > > --- a/include/drm/drm_crtc.h
>> > > +++ b/include/drm/drm_crtc.h
On Wed, Feb 1, 2012 at 10:38 AM, Sascha Hauer wrote:
> The fb helper uses fixed size arrays for the associated crtcs.
> This is an unnecessary limitation, so instead use a list to
> store the crtcs and allocate them dynamically.
I need more reasons on why this is a unnecessary limitation, for wha
On Fri, Jan 27, 2012 at 9:40 PM, Daniel Vetter wrote:
> CEA actually specifies an interlaced mode with even vtotal and
> supplies a diagram showing how this is supposed to work.
>
> Note that interlaced modes with an even vtotal seem to be a fairly
> recent invention. All modelines lore I could di
The function radeon_bo_list_validate can cause a
bo to move, resulting in a different sync_obj
and a dependency to wait for this move to finish.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h|1 -
drivers/gpu/drm/radeon/radeon_cs.c | 21 ++---
2 file
50 matches
Mail list logo
