On Fri, Jul 27, 2012 at 12:46:50PM +0800, joeyli wrote:
> 於 四，2012-07-26 於 23:31 -0400，Alex Deucher 提到：
> > On Thu, Jul 26, 2012 at 10:50 PM, joeyli wrote:
> > > 於 四，2012-07-26 於 14:58 +0200，Luca Tettamanti 提到：
> > >> - again ACPI video module gets the nodification (in this case
> > >> ACPI_VIDE
https://bugs.freedesktop.org/show_bug.cgi?id=52574
Bug #: 52574
Summary: crash in memcpy_texture because of NULL dstAddr
(gl_texture_image.Data)
Classification: Unclassified
Product: Mesa
Version: 7.11
Platform: x86-64
https://bugs.freedesktop.org/show_bug.cgi?id=52574
--- Comment #1 from Andriy Gapon 2012-07-27 09:17:54 UTC ---
Just notice that the following message appeared in Xorg.log before the crash:
__glXDRIbindTexImage: Failed to register texture offset override
Not sure if this is related.
--
Configur
On czwartek, 26 lipca 2012 o 14:38:28 Daniel Vetter wrote:
> On Wed, Jul 25, 2012 at 01:55:59PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 25, 2012 at 12:57 PM, Maciej Rutecki
> >
> > wrote:
> > > On środa, 25 lipca 2012 o 11:29:28 Daniel Vetter wrote:
> > >> On Wed, Jul 25, 2012 at 10:54:25AM +
On Fri, Jul 27, 2012 at 12:46 AM, joeyli wrote:
> 於 四，2012-07-26 於 23:31 -0400，Alex Deucher 提到：
>> On Thu, Jul 26, 2012 at 10:50 PM, joeyli wrote:
>> > 於 四，2012-07-26 於 14:58 +0200，Luca Tettamanti 提到：
>> >> - again ACPI video module gets the nodification (in this case
>> >> ACPI_VIDEO_NOTIFY_PR
Signed-off-by: Maarten Lankhorst
dma-buf-mgr handles the case of reserving single or multiple dma-bufs
while trying to prevent deadlocks from buffers being reserved
simultaneously. For this to happen extra functions have been introduced:
+ dma_buf_reserve()
+ dma_buf_unreserve()
+ dma_buf_
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
dma_buf[offset] >= value has been met, accounting for wraparound.
A software fallback still has to be provided in case the fence is used
with a device that doesn't support
A dma-fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering
https://bugs.freedesktop.org/show_bug.cgi?id=40790
--- Comment #13 from ojab 2012-07-27 16:29:20 PDT ---
Still the same with mesa git-11ff18f
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for
On Fri, Jul 27, 2012 at 11:32 AM, joeyli wrote:
> 於 五，2012-07-27 於 09:21 -0400，Alex Deucher 提到：
>> On Fri, Jul 27, 2012 at 12:46 AM, joeyli wrote:
>> >
>> > + * flags
>> > + * bits 1:0:
>> > + * 0 - Notify(VGA, 0x81) is not used for notification
>> > + * 1 - Notify(VGA, 0x81) is used for notifica
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #69 from Alexandre Demers 2012-07-27
18:26:19 PDT ---
(In reply to comment #67)
> Created attachment 64585 [details] [review]
> Adding an environment variable to disable VM if wanted
>
> By setting R600_VM=0, we disable the virtual
So first patch is a fix in itself, smallest possible and should go to
stable. Second patch is an improvement as a first step to flicker free
boot.
I have yet extensively tested second patch, especialy not on AGP but
so far on few GPU/motherboard it looks good. It can probably wait 3.7.
Will test i
From: Jerome Glisse
It seems we can not update the crtc scanout address. After disabling
crtc, update to base address do not take effect after crtc being
reenable leading to at least frame being scanout from the old crtc
base address. Disabling crtc display request lead to same behavior.
So afte
From: Jerome Glisse
It seems we can't move the VRAM GPU address without disabling CRTC.
Thus if we want to support flicker free boot from UEFI to X, we need
to keep the VRAM GPU address UEFI programmed. So far on all UEFI
checked this address was something sane.
Signed-off-by: Jerome Glisse
---
Let's allow GCC to optimize better.
This exposed some five unused functions, but this patch doesn't remove them.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/atombios_encoders.c |4 +-
drivers/gpu/drm/radeon/evergreen.c | 12 +-
drivers/gpu/drm/radeon/evergree
From: Rob Clark
I've been working for the better part of the week on solving some of
the omapdss vs kms mismatches, which is one of the bigger remaining
issues in the TODO before moving omapdrm out of staging.
The biggest place that this shows up is in GO bit handling. Basically,
some of the sc
From: Rob Clark
Not very clean, just for proof of concept.
Signed-off-by: Rob Clark
---
drivers/video/omap2/dss/apply.c |4 ++-
drivers/video/omap2/dss/dispc.c | 76 ++-
drivers/video/omap2/dss/dss.h |2 ++
drivers/video/omap2/dss/hdmi.c | 18
From: Rob Clark
We need this so that platform_get_irq() works when drm core sets up the
irq handling.
Signed-off-by: Rob Clark
---
arch/arm/mach-omap2/drm.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mac
From: Rob Clark
This is still work in progress, but it nicely solves the omapdss vs drm
impedence mismatches, and properly fixes unpin confusion vs GO bit status.
As an added bonus, we also no longer leave the last overlay buffer pinned.
Adding the previously missing vblank event handling for use
https://bugs.freedesktop.org/show_bug.cgi?id=52560
Bug #: 52560
Summary: Xorg -configure creats useless xorg.conf for tdfx
Classification: Unclassified
Product: DRI
Version: XOrg CVS
Platform: All
OS/Version: Linux (All)
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #15 from Alexander E. Patrakov 2012-07-26
20:39:37 PDT ---
I also have an affected Sony VAIO laptop, and the failure mode is the same:
cannot read BIOS on the AMD card. Is there any debugging information that I can
provide (from Wind
https://bugs.freedesktop.org/show_bug.cgi?id=52563
Bug #: 52563
Summary: build failure - struct radeon_renderbuffer has no
member named Base
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD
https://bugs.freedesktop.org/show_bug.cgi?id=52563
Brian Paul changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #16 from Ben Alex 2012-07-26 22:08:07
PDT ---
As per comment #15, I also have an affected Sony Vaio Z Series (model
SVZ13115GGXI). Anything logs/debugs/tests I can provide to assist resolve this
issue?
--
Configure bugmail: https:/
https://bugs.freedesktop.org/show_bug.cgi?id=52563
U. Artie Eoff changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #2 from U. Artie Eo
https://bugs.freedesktop.org/show_bug.cgi?id=41265
--- Comment #17 from Alex Deucher 2012-07-26 22:16:41 PDT
---
Probably need to ask Sony where they store the discrete vbios on these systems.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=52467
--- Comment #8 from Jerome Glisse 2012-07-26
23:25:59 PDT ---
Created attachment 64758
--> https://bugs.freedesktop.org/attachment.cgi?id=64758
Cleanup and fix mc programing
This patch should fix your issue
--
Configure bugmail: https://bug
https://bugs.freedesktop.org/show_bug.cgi?id=42373
--- Comment #16 from Jerome Glisse 2012-07-26
23:26:33 PDT ---
Created attachment 64759
--> https://bugs.freedesktop.org/attachment.cgi?id=64759
Fixup mc programing
This patch should fix your issue.
--
Configure bugmail: https://bugs.freede
https://bugs.freedesktop.org/show_bug.cgi?id=52467
--- Comment #9 from sowadski at miner.mst.edu 2012-07-27 05:39:06 PDT ---
I do not see any improvement after applying the proposed patch
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this ma
On Fri, Jul 27, 2012 at 12:46:50PM +0800, joeyli wrote:
> ? ??2012-07-26 ? 23:31 -0400?Alex Deucher ???
> > On Thu, Jul 26, 2012 at 10:50 PM, joeyli wrote:
> > > ? ??2012-07-26 ? 14:58 +0200?Luca Tettamanti ???
> > >> - again ACPI video module gets the nodification (in this case
> > >> ACPI_VIDE
https://bugs.freedesktop.org/show_bug.cgi?id=52574
Bug #: 52574
Summary: crash in memcpy_texture because of NULL dstAddr
(gl_texture_image.Data)
Classification: Unclassified
Product: Mesa
Version: 7.11
Platform: x86-64
https://bugs.freedesktop.org/show_bug.cgi?id=52574
--- Comment #1 from Andriy Gapon 2012-07-27 09:17:54 UTC
---
Just notice that the following message appeared in Xorg.log before the crash:
__glXDRIbindTexImage: Failed to register texture offset override
Not sure if this is related.
--
Configu
On czwartek, 26 lipca 2012 o 14:38:28 Daniel Vetter wrote:
> On Wed, Jul 25, 2012 at 01:55:59PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 25, 2012 at 12:57 PM, Maciej Rutecki
> >
> > wrote:
> > > On ?roda, 25 lipca 2012 o 11:29:28 Daniel Vetter wrote:
> > >> On Wed, Jul 25, 2012 at 10:54:25AM +
On Fri, Jul 27, 2012 at 12:46 AM, joeyli wrote:
> ? ??2012-07-26 ? 23:31 -0400?Alex Deucher ???
>> On Thu, Jul 26, 2012 at 10:50 PM, joeyli wrote:
>> > ? ??2012-07-26 ? 14:58 +0200?Luca Tettamanti ???
>> >> - again ACPI video module gets the nodification (in this case
>> >> ACPI_VIDEO_NOTIFY_PR
Signed-off-by: Maarten Lankhorst
dma-buf-mgr handles the case of reserving single or multiple dma-bufs
while trying to prevent deadlocks from buffers being reserved
simultaneously. For this to happen extra functions have been introduced:
+ dma_buf_reserve()
+ dma_buf_unreserve()
+ dma_buf_
This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
dma_buf[offset] >= value has been met, accounting for wraparound.
A software fallback still has to be provided in case the fence is used
with a device that doesn't support
A dma-fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device. For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering
https://bugs.freedesktop.org/show_bug.cgi?id=40790
--- Comment #13 from ojab 2012-07-27 16:29:20 PDT ---
Still the same with mesa git-11ff18f
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for
On Fri, Jul 27, 2012 at 11:32 AM, joeyli wrote:
> ? ??2012-07-27 ? 09:21 -0400?Alex Deucher ???
>> On Fri, Jul 27, 2012 at 12:46 AM, joeyli wrote:
>> >
>> > + * flags
>> > + * bits 1:0:
>> > + * 0 - Notify(VGA, 0x81) is not used for notification
>> > + * 1 - Notify(VGA, 0x81) is used for notifica
So first patch is a fix in itself, smallest possible and should go to
stable. Second patch is an improvement as a first step to flicker free
boot.
I have yet extensively tested second patch, especialy not on AGP but
so far on few GPU/motherboard it looks good. It can probably wait 3.7.
Will test i
From: Jerome Glisse
It seems we can not update the crtc scanout address. After disabling
crtc, update to base address do not take effect after crtc being
reenable leading to at least frame being scanout from the old crtc
base address. Disabling crtc display request lead to same behavior.
So afte
From: Jerome Glisse
It seems we can't move the VRAM GPU address without disabling CRTC.
Thus if we want to support flicker free boot from UEFI to X, we need
to keep the VRAM GPU address UEFI programmed. So far on all UEFI
checked this address was something sane.
Signed-off-by: Jerome Glisse
---
From: Rob Clark
I've been working for the better part of the week on solving some of
the omapdss vs kms mismatches, which is one of the bigger remaining
issues in the TODO before moving omapdrm out of staging.
The biggest place that this shows up is in GO bit handling. Basically,
some of the sc
From: Rob Clark
Not very clean, just for proof of concept.
Signed-off-by: Rob Clark
---
drivers/video/omap2/dss/apply.c |4 ++-
drivers/video/omap2/dss/dispc.c | 76 ++-
drivers/video/omap2/dss/dss.h |2 ++
drivers/video/omap2/dss/hdmi.c | 18
From: Rob Clark
We need this so that platform_get_irq() works when drm core sets up the
irq handling.
Signed-off-by: Rob Clark
---
arch/arm/mach-omap2/drm.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/drm.c b/arch/arm/mac
From: Rob Clark
This is still work in progress, but it nicely solves the omapdss vs drm
impedence mismatches, and properly fixes unpin confusion vs GO bit status.
As an added bonus, we also no longer leave the last overlay buffer pinned.
Adding the previously missing vblank event handling for use
? ??2012-07-26 ? 14:58 +0200?Luca Tettamanti ???
> - again ACPI video module gets the nodification (in this case
> ACPI_VIDEO_NOTIFY_PROBE), re-enumerated and send KEY_SWITCHVIDEOMODE
> - KDE seems this and muck with the screen configuration :(
> - meanwhile the brightness notification is propaga
? ??2012-07-26 ? 23:31 -0400?Alex Deucher ???
> On Thu, Jul 26, 2012 at 10:50 PM, joeyli wrote:
> > ? ??2012-07-26 ? 14:58 +0200?Luca Tettamanti ???
> >> - again ACPI video module gets the nodification (in this case
> >> ACPI_VIDEO_NOTIFY_PROBE), re-enumerated and send KEY_SWITCHVIDEOMODE
> >> -
? ??2012-07-27 ? 09:21 -0400?Alex Deucher ???
> On Fri, Jul 27, 2012 at 12:46 AM, joeyli wrote:
> >
> > + * flags
> > + * bits 1:0:
> > + * 0 - Notify(VGA, 0x81) is not used for notification
> > + * 1 - Notify(VGA, 0x81) is used for notification
> >
> > Per the above flags, when we detect bit set
? ??2012-07-27 ? 23:32 +0800?joeyli ???
> ? ??2012-07-27 ? 09:21 -0400?Alex Deucher ???
> > On Fri, Jul 27, 2012 at 12:46 AM, joeyli wrote:
> > >
> > > + * flags
> > > + * bits 1:0:
> > > + * 0 - Notify(VGA, 0x81) is not used for notification
> > > + * 1 - Notify(VGA, 0x81) is used for notificatio
50 matches
Mail list logo
