https://bugs.freedesktop.org/show_bug.cgi?id=56828
Andreas Boll changed:
What|Removed |Added
Component|Drivers/DRI/R600|Drivers/Gallium/r600
--- Comment #1 from
yload=keep completely, my monitor works
fine.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/c795c2c8/attachment.html>
he bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/1f5529fe/attachment.html>
ing the
framebuffer.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/eb4d8f75/attachment.html>
this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/f1dd5436/attachment.html>
It's unused.
Signed-off-by: Marcin Slusarz
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_memory.c | 1 -
include/drm/ttm/ttm_memory.h | 2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 479c6b0..dbc2def 100644
--
It's unused.
Signed-off-by: Marcin Slusarz
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c| 1 -
include/drm/ttm/ttm_bo_driver.h | 3 ---
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 412486c..da7a985 100644
--- a/drive
All drivers pass NULL here. ttm_buffer_object's field can still be set after
init, just like nouveau does.
Signed-off-by: Marcin Slusarz
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ast/ast_ttm.c| 7 +++
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag
All drivers set it to 0 and nothing uses it.
Signed-off-by: Marcin Slusarz
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ast/ast_ttm.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/2594c33b/attachment.html>
Fixed build warning as below:
drivers/gpu/drm/drm_pci.c: In function 'drm_pcie_get_speed_cap_mask':
drivers/gpu/drm/drm_pci.c:496:9: warning: 'lnkcap' may be used uninitialized in
this function [-Wuninitialized]
drivers/gpu/drm/drm_pci.c:497:10: warning: 'lnkcap2' may be used uninitialized
in th
On Wednesday, November 07, 2012 2:37 PM Jingoo Han wrote
>
> Fixed build warning as below:
>
> arch/arm/mm/cache-l2x0.c:37:12: warning: 'l2_wt_override' defined but not
> used [-Wunused-variable]
Sorry, this error message is wrong.
I made a mistake.
I will fix the error message and send v2 pat
Fixed build warning as below:
arch/arm/mm/cache-l2x0.c:37:12: warning: 'l2_wt_override' defined but not used
[-Wunused-variable]
Signed-off-by: Jingoo Han
---
drivers/gpu/drm/drm_pci.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_pci.c b/drivers
In 3.7-rc4, when starting X with the integrated GPU and suspending the discrete
GPU,
after one or more 32-bit applications are used (eg Skype) and X is stopped,
we hit a panic.
Prevent this by testing if the fini function is valid.
Full panic bootlog is at: http://quora.org/2012/nouveau/dmesg-cr
Hello Rahul,
On Mon, Nov 5, 2012 at 2:32 PM, Rahul Sharma wrote:
> This patch adds iommu support for hdmi driver with device tree based
> search. It searches for sysmmu property in hdmi dt node to get tv
> iommu device pointer which will be used to configure iommu hw interface.
>
> This patch is
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/e1a41338/attachment.html>
Op 06-11-12 15:48, Kelly Doran schreef:
> The vblank on nvc0 was not working correctly and would freeze X, I managed
> to track it down and fix it with some help from m.b.lankhorst, see
> https://bugs.freedesktop.org/show_bug.cgi?id=56692 for details.
>
Reviewed-by: Maarten Lankhorst
I recommen
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/338ff400/attachment.html>
Hi Linus,
a single radeon typo fix for a regressions
and two fixes for a regression in the open helper addres space stuff.
Dave.
The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
are available in the git repository at:
g
Hello David Airlie:
for the h[4] is "available" (which length is 9), at line 1107.
but for seq_printf at line 1114, its format is %8s.
I suggest to make them match with each other (although it is not a bug).
thanks.
1103 int ttm_dma_page_alloc_debugfs(struct seq_file *m, void *data
https://bugs.freedesktop.org/show_bug.cgi?id=56828
Priority: medium
Bug ID: 56828
Assignee: dri-devel@lists.freedesktop.org
Summary: Driver for Radeon has broken acceleration
functionality with HD 5450
Severity: normal
Cl
On 2012-11-05 16:21, Rob Clark wrote:
> On 11/05/2012 02:55 AM, Tomi Valkeinen wrote:
But even then, choosing the manager is not easy, as whoever chooses the
>>manager needs to observe all the possible displays used at the same
>>time...
>>> >
>>> >Right. I was wondering if omapfb/om
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #24 from Alexandre Demers ---
I'll retest it with the latest two patches, but I think setting gfxpayload=text
prevents the bug. I know for sure that with the index patch, suspend/resume
cycle is fixed. Also, if I remove gfxpayload=kee
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #23 from Alex Deucher ---
(In reply to comment #19)
> Should I try to combine patch 69113
> and patch 69370 with the others?
Worth a shot.
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #22 from Alexandre Demers ---
(In reply to comment #21)
> (In reply to comment #19)
> > If I followed you correctly, setting bit 24 to "1" disables memory but keeps
> > the CRTC state as it is (hopefully in sync with the monitor). How
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #21 from Alex Deucher ---
(In reply to comment #19)
> If I followed you correctly, setting bit 24 to "1" disables memory but keeps
> the CRTC state as it is (hopefully in sync with the monitor). However, what
> I see when grub2 kicks
Op 25-10-12 09:42, Thomas Hellstrom schreef:
> On 10/12/2012 04:58 PM, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
>> include/drm/ttm/ttm_bo_api.h | 14 ++
>> 2 files changed, 20 insertions(+), 6 deletio
This is similar to other platforms that don't allow command submission
to buffers locked on the cpu.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..2b3f69b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/d
https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #20 from Alexandre Demers ---
Should I have a look at how grub2 handles and talks to the kernel when using
gfxpayload=keep? A quick search shows this issue has been lurking for some time
(2010) with various radeon card
(https://bugs.l
It's unused.
Signed-off-by: Marcin Slusarz
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_memory.c | 1 -
include/drm/ttm/ttm_memory.h | 2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_memory.c b/drivers/gpu/drm/ttm/ttm_memory.c
index 479c6b0..dbc2def 100644
--
It's unused.
Signed-off-by: Marcin Slusarz
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c| 1 -
include/drm/ttm/ttm_bo_driver.h | 3 ---
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 412486c..da7a985 100644
--- a/drive
All drivers pass NULL here. ttm_buffer_object's field can still be set after
init, just like nouveau does.
Signed-off-by: Marcin Slusarz
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ast/ast_ttm.c| 7 +++
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag
All drivers set it to 0 and nothing uses it.
Signed-off-by: Marcin Slusarz
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ast/ast_ttm.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_ttm.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_ttm.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
From: Alan Cox
There are still some mysteries left, in particular how (and in
fact if) the EDID is supposed to work on the HDMI port. However
the basic stuff now works and I can plug my Q550 into an HDMI
display and get the expected results.
[v2: cleans up space/tab and other formatting as per D
https://bugzilla.kernel.org/show_bug.cgi?id=50091
Alan changed:
What|Removed |Added
CC||alan at lxorguk.ukuu.org.uk
Component|Vi
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #13 from Michael Dressel ---
Created attachment 69640
--> https://bugs.freedesktop.org/attachment.cgi?id=69640&action=edit
compilation errors
These are the compile errors I get with the above mentioned commit.
The compile errors ar
Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus
The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.
v2: Don'
This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock a
TTM base objects will be the first consumer.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/drm_hashtab.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index c3745c4..5729e39 100644
--
A patch series for next that removes a substantial number of read-modify-write
operations from TTM command submission, in particular if TTM objects are used
to export objects to user-space. The only per-object atomic r-m-w operations
left during a typical execbuf call should be refcount up and down
pfn = page_to_pfn(buf->pages[0]) + page_offset;
> + }
>
> return vm_insert_mixed(vma, f_vaddr, pfn);
> }
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/b160442e/attachment-0001.html>
Hi Ben,
FYI, there are new sparse warnings show up in
tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued
head: afef67fbc09aec8508c88aac1931661a36e91958
commit: a1e0e54668f41badfaf5e49cae9fc10b79635b25 [255/259] drm/i915: Stop using
AGP layer for GEN6+
+ drivers/
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/2e17b5e9/attachment.html>
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/bf8f428e/attachment.html>
Op 06-11-12 15:48, Kelly Doran schreef:
> The vblank on nvc0 was not working correctly and would freeze X, I managed
> to track it down and fix it with some help from m.b.lankhorst, see
> https://bugs.freedesktop.org/show_bug.cgi?id=56692 for details.
>
Reviewed-by: Maarten Lankhorst
I recommen
https://bugs.freedesktop.org/show_bug.cgi?id=50208
--- Comment #3 from Nicola Larosa ---
It's still not working with 3.5.0-18.29 . :-( I don't know how to bisect.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel
600g version '3.0 Mesa 9.1-devel
(git-e87a578)' (R600_LLVM=0).
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/1e204e20/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121106/47c3b59e/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121106/27ceb48e/attachment.html>
-- next part --
A non-text attachment was scrubbed...
Name: nvc0_vblank_fix.patch
Type: application/octet-stream
Size: 1647 bytes
Desc: not available
URL:
<http://lists.freede
On Tue, Nov 6, 2012 at 7:41 AM, Tomi Valkeinen wrote:
> On 2012-11-05 16:21, Rob Clark wrote:
>> On 11/05/2012 02:55 AM, Tomi Valkeinen wrote:
> But even then, choosing the manager is not easy, as whoever chooses the
> >>manager needs to observe all the possible displays used at the same
>
The vblank on nvc0 was not working correctly and would freeze X, I managed
to track it down and fix it with some help from m.b.lankhorst, see
https://bugs.freedesktop.org/show_bug.cgi?id=56692 for details.
nvc0_vblank_fix.patch
Description: Binary data
In 3.7-rc4, when starting X with the integrated GPU and suspending the discrete
GPU,
after one or more 32-bit applications are used (eg Skype) and X is stopped,
we hit a panic.
Prevent this by testing if the fini function is valid.
Full panic bootlog is at: http://quora.org/2012/nouveau/dmesg-cr
Hello David Airlie:
for the h[4] is "available" (which length is 9), at line 1107.
but for seq_printf at line 1114, its format is %8s.
I suggest to make them match with each other (although it is not a bug).
thanks.
1103 int ttm_dma_page_alloc_debugfs(struct seq_file *m, void *data
On Mon, 2012-11-05 at 11:34 -0500, alexdeucher at gmail.com wrote:
> From: Alex Deucher
>
> Add missing index that may have led us to enabling
> more crtcs than necessary.
>
> May also fix:
> https://bugs.freedesktop.org/show_bug.cgi?id=56139
>
> Signed-off-by: Alex Deucher
Reviewed-by: Mich
On Tue, Nov 6, 2012 at 7:41 AM, Tomi Valkeinen wrote:
> On 2012-11-05 16:21, Rob Clark wrote:
>> On 11/05/2012 02:55 AM, Tomi Valkeinen wrote:
> But even then, choosing the manager is not easy, as whoever chooses the
> >>manager needs to observe all the possible displays used at the same
>
From: Alan Cox
There are still some mysteries left, in particular how (and in
fact if) the EDID is supposed to work on the HDMI port. However
the basic stuff now works and I can plug my Q550 into an HDMI
display and get the expected results.
[v2: cleans up space/tab and other formatting as per D
Op 25-10-12 09:42, Thomas Hellstrom schreef:
> On 10/12/2012 04:58 PM, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/ttm/ttm_bo.c | 12 ++--
>> include/drm/ttm/ttm_bo_api.h | 14 ++
>> 2 files changed, 20 insertions(+), 6 deletio
On 2012-11-05 16:21, Rob Clark wrote:
> On 11/05/2012 02:55 AM, Tomi Valkeinen wrote:
But even then, choosing the manager is not easy, as whoever chooses the
>>manager needs to observe all the possible displays used at the same
>>time...
>>> >
>>> >Right. I was wondering if omapfb/om
This is similar to other platforms that don't allow command submission
to buffers locked on the cpu.
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index bf6e4b5..2b3f69b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/g
https://bugzilla.kernel.org/show_bug.cgi?id=50091
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
Component|Video
Reservation locking currently always takes place under the LRU spinlock.
Hence, strictly there is no need for an atomic_cmpxchg call; we can use
atomic_read followed by atomic_write since nobody else will ever reserve
without the lru spinlock held.
At least on Intel this should remove a locked bus
The mostly used lookup+get put+potential_destroy path of TTM objects
is converted to use RCU locks. This will substantially decrease the amount
of locked bus cycles during normal operation.
Since we use kfree_rcu to free the objects, no rcu synchronization is needed
at module unload time.
v2: Don'
This function is intended to simplify locking around refcounting for
objects that can be looked up from a lookup structure, and which are
removed from that lookup structure in the object destructor.
Operations on such objects require at least a read lock around
lookup + kref_get, and a write lock a
TTM base objects will be the first consumer.
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/drm_hashtab.c | 18 +++---
1 files changed, 7 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_hashtab.c b/drivers/gpu/drm/drm_hashtab.c
index c3745c4..5729e39 100644
--
A patch series for next that removes a substantial number of read-modify-write
operations from TTM command submission, in particular if TTM objects are used
to export objects to user-space. The only per-object atomic r-m-w operations
left during a typical execbuf call should be refcount up and down
https://bugs.freedesktop.org/show_bug.cgi?id=12882
Daniel Vetter changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=30845
Daniel Vetter changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=26735
Török Edwin changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
libdrm 2.4.40 has been released.
The reason is we need to use the radeon stencil mipmap allocator for combined
depth-stencil buffers in Mesa.
Alex Deucher (1):
radeon: add some new SI pci ids
Andreas Boll (1):
radeon: fix unused-fu
https://bugs.freedesktop.org/show_bug.cgi?id=56405
--- Comment #12 from Michel Dänzer ---
What are the compile errors?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
g bit. When the crtc is
> blanked, memory requests are also disabled.
If I followed you correctly, setting bit 24 to "1" disables memory but keeps
the CRTC state as it is (hopefully in sync with the monitor). However, what I
see when grub2 kicks in with the "gfxpayload=keep" is an unsynced monitor.
Sometimes the display will be black, other times it will only appear in the
first couple of vertical lines, in others it will be vertically synced but
shifted to the right at half or at two third of the screen. In other words,
this really seems to be a sync problem. Should I try to combine patch 69113 and
patch 69370 with the others?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/136a79da/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121106/314a8974/attachment.html>
73 matches
Mail list logo
