[Bug 43655] Latest radeon dri driver on HD6950 with kernel 3.2 flickers
https://bugs.freedesktop.org/show_bug.cgi?id=43655 --- Comment #3 from Alexandre Demers 2011-12-12 01:03:23 PST --- OK, so after testing first all RCs, I narrowed the problem between RC3 and RC4. So, bisecting gave me the following culprit: commit 9b5a4d4f65e260a109eaeea8bbc8062a7c58b55e Merge: cb35999 67589c7 Author: Linus Torvalds Date: Mon Nov 28 13:49:43 2011 -0800 Merge branch 'for-3.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/gi * 'for-3.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu percpu: explain why per_cpu_ptr_to_phys() is more complicated than necessa percpu: fix chunk range calculation percpu: rename pcpu_mem_alloc to pcpu_mem_zalloc It has nothing to do with drm in itself. But it must be related at some point... I'll reset my tree tomorrow and retest to be sure by compiling just before this commit. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43739] New: Startx fails for Fusion Wrestler 9809
https://bugs.freedesktop.org/show_bug.cgi?id=43739 Bug #: 43739 Summary: Startx fails for Fusion Wrestler 9809 Classification: Unclassified Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: hysv...@gmail.com Created attachment 54350 --> https://bugs.freedesktop.org/attachment.cgi?id=54350 xorg.log Driver Stack Details: = 1)Kernel- 3.0.0-12-generice-pae 2)Libdrm-2.4.27 3)Mesa-7.12-devel (git-f1a677c) 4)Xorg-server-1.10.1 5)xf86-video-ati-master System Environment: === Asic/Chipset : Fusion Wrestler 9809 O.S. : Ubuntu-11.10 (32 bit) Processor: AMD E1-1200 @ 777 MHz Memory : 1.6 GB Steps to Reproduce: === Connect the Fusion Wrestler 9809 with vga cable and # startx Observation : 1) startx fails with following message 19.058] (++) using VT number 7 [19.059] (EE) No devices detected. [19.059] Fatal server error: [19.059] no screens found 2) startx works fine with Fusion Wrestler 9807/9804 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43739] Startx fails for Fusion Wrestler 9809
https://bugs.freedesktop.org/show_bug.cgi?id=43739 --- Comment #1 from samit vats 2011-12-12 01:17:20 PST --- Created attachment 54351 --> https://bugs.freedesktop.org/attachment.cgi?id=54351 xorg.conf -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43739] Startx fails for Fusion Wrestler 9809
https://bugs.freedesktop.org/show_bug.cgi?id=43739 --- Comment #2 from samit vats 2011-12-12 01:17:49 PST --- Created attachment 54352 --> https://bugs.freedesktop.org/attachment.cgi?id=54352 dmesg.txt -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43739] Startx fails for Fusion Wrestler 9809
https://bugs.freedesktop.org/show_bug.cgi?id=43739 --- Comment #3 from samit vats 2011-12-12 01:18:15 PST --- Created attachment 54353 --> https://bugs.freedesktop.org/attachment.cgi?id=54353 lspci -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43739] Startx fails for Fusion Wrestler 9809
https://bugs.freedesktop.org/show_bug.cgi?id=43739 samit vats changed: What|Removed |Added Priority|medium |high -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: add some new pci ids
From: Alex Deucher
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=43739
Signed-off-by: Alex Deucher
Cc: sta...@kernel.org
---
include/drm/drm_pciids.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 4e4fbb8..14b6cd0 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -182,8 +182,11 @@
{0x1002, 0x6748, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6749, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6750, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x6751, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6758, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6759, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x675B, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x675D, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x675F, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6760, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6761, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
@@ -195,8 +198,10 @@
{0x1002, 0x6767, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6768, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6770, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x6772, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6778, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6779, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x677B, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6840, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6841, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6842, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
@@ -246,6 +251,7 @@
{0x1002, 0x68f2, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
{0x1002, 0x68f8, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
{0x1002, 0x68f9, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x68fa, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
{0x1002, 0x68fe, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
{0x1002, 0x7100, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R520|RADEON_NEW_MEMMAP}, \
{0x1002, 0x7101, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R520|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
@@ -488,6 +494,8 @@
{0x1002, 0x9647, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_SUMO|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP},\
{0x1002, 0x9648, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_SUMO|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP},\
{0x1002, 0x964a, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_SUMO|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x964b, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_SUMO|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x964c, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_SUMO|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x964e, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_SUMO|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP},\
{0x1002, 0x964f, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_SUMO|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP},\
{0x1002, 0x9710, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
@@ -502,6 +510,8 @@
{0x1002, 0x9805, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_PALM|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9806, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_PALM|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9807, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_PALM|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x9808, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_PALM|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x9809, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_PALM|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0, 0, 0}
#define r128_PCI_IDS \
--
1.7.3.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43739] Startx fails for Fusion Wrestler 9809
https://bugs.freedesktop.org/show_bug.cgi?id=43739 --- Comment #4 from Alex Deucher 2011-12-12 06:50:42 PST --- You'll need the following patches: Mesa: http://cgit.freedesktop.org/mesa/mesa/commit/?id=23895cc006f3dbf96a502ddd15e291e071aff25a xf86-video-ati: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=aacbd629b02cbee3f9e6a0ee452b4e3f21376bd3 kernel: http://lists.freedesktop.org/archives/dri-devel/2011-December/017339.html -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: ttm dma allocator issue ?
On Fri, Dec 09, 2011 at 09:25:43PM -0500, Jerome Glisse wrote:
> Hi Konrad i stumble on this after a long period of test :
>
> Dec 9 12:00:37 homer kernel: [ cut here ]
> Dec 9 12:00:37 homer kernel: WARNING: at lib/dma-debug.c:894
> check_unmap+0x262/0x7e0()
> Dec 9 12:00:37 homer kernel: Hardware name: GA-A75M-UD2H
> Dec 9 12:00:37 homer kernel: radeon :01:00.0: DMA-API: device
> driver frees DMA memory with different CPU address [device
> address=0x0002093f3000]
>[size=4096 bytes]
>[cpu alloc
> address=0x000213bf2000]
>[cpu free
> address=0x0002093f3000]
> Dec 9 12:00:37 homer kernel: Modules linked in: radeon ttm
> drm_kms_helper drm ip6t_REJECT ipt_REJECT nf_conntrack_ipv6
> nf_conntrack_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 xt_state nf_conntrack
> ip6table_filter iptable_filter ip6_tables ip_tables dm_mirror
> dm_region_hash dm_log dm_mod snd_hda_codec_hdmi snd_hda_codec_realtek
> snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device r8169
> snd_pcm microcode serio_raw xhci_hcd mii hwmon i2c_piix4 i2c_algo_bit
> snd_timer snd soundcore snd_page_alloc ipv6 ext4 mbcache jbd2
> ata_generic pata_atiixp [last unloaded: drm]
> Dec 9 12:00:37 homer kernel: Pid: 1158, comm: Heaven_x64 Not tainted
> 3.2.0-rc4+ #72
> Dec 9 12:00:37 homer kernel: Call Trace:
> Dec 9 12:00:37 homer kernel: []
> warn_slowpath_common+0x7f/0xc0
> Dec 9 12:00:37 homer kernel: [] warn_slowpath_fmt+0x46/0x50
> Dec 9 12:00:37 homer kernel: [] check_unmap+0x262/0x7e0
> Dec 9 12:00:37 homer kernel: []
> ?vm_unmap_aliases+0x77/0x1d0
> Dec 9 12:00:37 homer kernel: []
> debug_dma_free_coherent+0x6d/0x80
> Dec 9 12:00:37 homer kernel: []
> ?__request_resource+0x60/0x60
> Dec 9 12:00:37 homer kernel: []
> __ttm_dma_free_page+0x67/0xd0 [ttm]
> Dec 9 12:00:37 homer kernel: []
> ttm_dma_unpopulate+0x2c5/0x340 [ttm]
> Dec 9 12:00:37 homer kernel: []
> radeon_ttm_tt_unpopulate+0xdf/0xf0 [radeon]
.. snip..
> Dec 9 12:00:37 homer kernel: Mapped at:
> Dec 9 12:00:37 homer kernel: []
> debug_dma_alloc_coherent+0x3b/0x90
> Dec 9 12:00:37 homer kernel: []
> ttm_dma_populate+0x340/0xa30 [ttm]
> Dec 9 12:00:37 homer kernel: []
> radeon_ttm_tt_populate+0x19f/0x280 [radeon]
> Dec 9 12:00:37 homer kernel: [] ttm_tt_bind+0x3e/0x70 [ttm]
> Dec 9 12:00:37 homer kernel: []
> ttm_bo_handle_move_mem+0x36f/0x3e0 [ttm]
> Dec 9 12:01:29 homer kernel: DMA-API: debugging out of memory - disabling
> Dec 9 19:16:54 homer kernel: [drm:radeon_dvi_detect] *ERROR* DVI-I-1:
> probed a monitor but no|invalid EDID
>
> Nothing else in the log. Quite frankly i dont this how this can happen.
> Any ideas ?
The only way to do that would be to modify the 'struct dma_page' vaddr and dma
variables from what they had in __ttm_dma_alloc_page. But I am not seeing any
willfull modifications. We do pass in to dma_free_coherent the _same_ values!
Hm, it might be worth adding in the 'struct dma_page' a 'virt_to_phys' value
(which is what the DMA debug API uses to check), and see we get inconsitent
values _before_ we call the DMA debug API. This is rather to double check
the DMA API debug API. I am going to try something like this (not compile
tested at all):
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 6678abc..2dd7d6c 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -127,6 +127,7 @@ struct dma_page {
void *vaddr;
struct page *p;
dma_addr_t dma;
+ void *phys; /* Based on virt_to_phys so not really bus addr */
};
/*
@@ -330,6 +331,11 @@ static int ttm_set_pages_caching(struct dma_pool *pool,
static void __ttm_dma_free_page(struct dma_pool *pool, struct dma_page *d_page)
{
dma_addr_t dma = d_page->dma;
+
+ WARN_ON(virt_to_phys(d_page->vaddr) != d_page->virt,
+ "WTF: saved 0x%lx, but now we get 0x%lx!\n",
+ d_page->virt, virt_to_phys(d_page->vaddr));
+
dma_free_coherent(pool->dev, pool->size, d_page->vaddr, dma);
kfree(d_page);
@@ -348,6 +354,7 @@ static struct dma_page *__ttm_dma_alloc_page(struct
dma_pool *pool)
pool->gfp_flags);
if (d_page->vaddr)
d_page->p = virt_to_page(d_page->vaddr);
+ d_page->virt = virt_to_phys(d_page->vaddr);
else {
kfree(d_page);
d_page = NULL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Memory corruption starting in i915 code, in 3.2-rc5
On Mon, 12 Dec 2011 09:51:19 -0500, Alex Villacís Lasso wrote: > Ran kernel with reverted patch for 6 hours without issues so far. Will > keep testing after work (issue happens with my home machine). Thanks much. Let me know if it's still stable this evening; I can send a revert along if you don't find any problems. -- keith.pack...@intel.com pgpQr80chfFZw.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Saturday 10 December 2011, Daniel Vetter wrote: > If userspace (through some driver calls) > tries to do stupid things, it'll just get garbage. See > Message-ID: > > for my reasons why it think this is the right way to go forward. So in > essence I'm really interested in the reasons why you want the kernel > to enforce this (or I'm completely missing what's the contentious > issue here). This has nothing to do with user space mappings. Whatever user space does, you get garbage if you don't invalidate cache lines that were introduced through speculative prefetching before you access cache lines that were DMA'd from a device. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: ttm dma allocator issue ?
> > Any ideas ?
>
> The only way to do that would be to modify the 'struct dma_page' vaddr and dma
> variables from what they had in __ttm_dma_alloc_page. But I am not seeing any
> willfull modifications. We do pass in to dma_free_coherent the _same_ values!
>
>
> Hm, it might be worth adding in the 'struct dma_page' a 'virt_to_phys' value
> (which is what the DMA debug API uses to check), and see we get inconsitent
> values _before_ we call the DMA debug API. This is rather to double check
> the DMA API debug API. I am going to try something like this (not compile
> tested at all):
This one is compile tested :-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 6678abc..659b0ee 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -32,7 +32,7 @@
* - Tracks whether the page is UC, WB or cached (and reverts to WB
* when freed).
*/
-
+#define DEBUG 1
#include
#include
#include /* for seq_printf */
@@ -127,6 +127,7 @@ struct dma_page {
void *vaddr;
struct page *p;
dma_addr_t dma;
+ void *phys; /* Based on virt_to_phys so not really bus addr */
};
/*
@@ -330,6 +331,11 @@ static int ttm_set_pages_caching(struct dma_pool *pool,
static void __ttm_dma_free_page(struct dma_pool *pool, struct dma_page *d_page)
{
dma_addr_t dma = d_page->dma;
+
+ WARN(virt_to_phys(d_page->vaddr) != d_page->phys,
+ "We saved 0x%lx, but now we get 0x%lx!?\n",
+ (unsigned long)d_page->phys, (unsigned
long)virt_to_phys(d_page->vaddr));
+
dma_free_coherent(pool->dev, pool->size, d_page->vaddr, dma);
kfree(d_page);
@@ -346,8 +352,10 @@ static struct dma_page *__ttm_dma_alloc_page(struct
dma_pool *pool)
d_page->vaddr = dma_alloc_coherent(pool->dev, pool->size,
&d_page->dma,
pool->gfp_flags);
- if (d_page->vaddr)
+ if (d_page->vaddr) {
d_page->p = virt_to_page(d_page->vaddr);
+ d_page->phys = virt_to_phys(d_page->vaddr);
+ }
else {
kfree(d_page);
d_page = NULL;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] fixes to drm-next - TTM DMA code (v1)
Jerome pointed me to some accounting error in the DMA API debugging code and while I can't figure it out yet, I did notice some extreme slowness - which is due to the nouveau driver calling the unpopulate (now that unbind + unpopulate are squashed) quite a lot (this is using Gnome Shell - I think GNOME2 did not have those issues but I can't recall). Anyhow these patches fix the 50% perf regression I saw and also some minor bugs that I noticed. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/ttm/dma: Only call set_pages_array_wb when the page is not in WB pool.
Otherwise we are doing redundant work. Especially since the 'unbind' and 'unpopulate' have been merged and nouveau driver ends up calling it quite excessivly. On a GeForce 8600 GT with Gnome Shell (GNOME 3) we end up spending about 54% CPU time in __change_page_attr_set_clr checking the page flags when I move the mouse cursor all over the screen. The callgraph (annotated) looks as so before this patch: 53.29% gnome-shell [kernel.kallsyms] [k] static_protections | --- static_protections | |--91.80%-- __change_page_attr_set_clr | change_page_attr_set_clr | set_pages_array_wb | | | |--96.55%-- ttm_dma_unpopulate | | nouveau_ttm_tt_unpopulate | | ttm_tt_destroy | | ttm_bo_cleanup_memtype_use | | ttm_bo_release | | kref_put | | ttm_bo_unref | | nouveau_gem_object_del | | drm_gem_object_free | | kref_put | | drm_gem_object_unreference_unlocked | | drm_gem_object_handle_unreference_unlocked.part.1 | | drm_gem_handle_delete | | drm_gem_close_ioctl | | drm_ioctl | | do_vfs_ioctl | | sys_ioctl | | system_call_fastpath | | __GI___ioctl | | | --3.45%-- ttm_dma_pages_put | ttm_dma_page_pool_free | ttm_dma_unpopulate | nouveau_ttm_tt_unpopulate | ttm_tt_destroy | ttm_bo_cleanup_memtype_use | ttm_bo_release | kref_put | ttm_bo_unref | nouveau_gem_object_del | drm_gem_object_free | kref_put | drm_gem_object_unreference_unlocked | drm_gem_object_handle_unreference_unlocked.part.1 | drm_gem_handle_delete | drm_gem_close_ioctl | drm_ioctl | do_vfs_ioctl | sys_ioctl | system_call_fastpath | __GI___ioctl | --8.20%-- change_page_attr_set_clr set_pages_array_wb | |--93.76%-- ttm_dma_unpopulate | nouveau_ttm_tt_unpopulate | ttm_tt_destroy | ttm_bo_cleanup_memtype_use | ttm_bo_release | kref_put | ttm_bo_unref | nouveau_gem_object_del | drm_gem_object_free | kref_put | drm_gem_object_unreference_unlocked | drm_gem_object_handle_unreference_unlocked.part.1 | drm_gem_handle_delete | drm_gem_close_ioctl | drm_ioctl | do_vfs_ioctl | sys_ioctl | system_call_fastpath | __GI___ioctl | --6.24%-- ttm_dma_pages_put ttm_dma_page_pool_free ttm_dma_unpopulate nouveau_ttm_tt_unpopulate ttm_tt_destroy ttm_bo_cleanup_memtype_use ttm_bo_release kref_put ttm_bo_unref nouveau_gem_object_del drm_gem_object_free kref_put drm_gem_object_unreferenc
[PATCH 3/3] drm/ttm/dma: Optimize when free-ing the recycled page pool.
We would free the page pool - even if it was for cached pages
(which are deleted from the pool - so there are no free pages).
Also we also missed the opportunity to batch the amount of pages
to free (similar to how ttm_page_alloc.c does it). This reintroduces
the code that was lost during rebasing.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index e57aa24..156ddcd 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -949,7 +949,7 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
struct dma_page *d_page, *next;
enum pool_type type;
bool is_cached = false;
- unsigned count = 0, i, npages;
+ unsigned count = 0, i, npages = 0;
unsigned long irq_flags;
type = ttm_to_type(ttm->page_flags, ttm->caching_state);
@@ -971,13 +971,16 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma,
struct device *dev)
pool->npages_in_use -= count;
if (is_cached) {
pool->nfrees += count;
- npages = count;
} else {
pool->npages_free += count;
list_splice(&ttm_dma->pages_list, &pool->free_list);
npages = count;
if (pool->npages_free > _manager->options.max_size) {
npages = pool->npages_free - _manager->options.max_size;
+ /* free at least NUM_PAGES_TO_ALLOC number of pages
+* to reduce calls to set_memory_wb */
+ if (npages < NUM_PAGES_TO_ALLOC)
+ npages = NUM_PAGES_TO_ALLOC;
}
}
spin_unlock_irqrestore(&pool->lock, irq_flags);
@@ -1001,7 +1004,7 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma,
struct device *dev)
ttm_dma->dma_address[i] = 0;
}
- /* shrink pool if necessary */
+ /* shrink pool if necessary (only on !is_cached pools)*/
if (npages)
ttm_dma_page_pool_free(pool, npages);
ttm->state = tt_unpopulated;
--
1.7.7.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/ttm/dma: Fix accounting error when calling ttm_mem_global_free_page.
The code to figure out how many pages to shrink the pool
ends up capping the 'count' at _manager->options.max_size - which is OK.
Except that the 'count' is also used when accounting for how many pages
are recycled - which we end up with the invalid values. This fixes
it by using a different value for the amount of pages to shrink.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 6c06d0b..e57aa24 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -949,7 +949,7 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
struct dma_page *d_page, *next;
enum pool_type type;
bool is_cached = false;
- unsigned count = 0, i;
+ unsigned count = 0, i, npages;
unsigned long irq_flags;
type = ttm_to_type(ttm->page_flags, ttm->caching_state);
@@ -971,11 +971,13 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma,
struct device *dev)
pool->npages_in_use -= count;
if (is_cached) {
pool->nfrees += count;
+ npages = count;
} else {
pool->npages_free += count;
list_splice(&ttm_dma->pages_list, &pool->free_list);
+ npages = count;
if (pool->npages_free > _manager->options.max_size) {
- count = pool->npages_free - _manager->options.max_size;
+ npages = pool->npages_free - _manager->options.max_size;
}
}
spin_unlock_irqrestore(&pool->lock, irq_flags);
@@ -1000,8 +1002,8 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma,
struct device *dev)
}
/* shrink pool if necessary */
- if (count)
- ttm_dma_page_pool_free(pool, count);
+ if (npages)
+ ttm_dma_page_pool_free(pool, npages);
ttm->state = tt_unpopulated;
}
EXPORT_SYMBOL_GPL(ttm_dma_unpopulate);
--
1.7.7.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
crash with "drm/ttm: callback move_notify any time bo placement change v4" patch
Hey, When I use the drm-next tree without the patch it works fine. (albeit slowly - but I posted the patches for that). With the patch mentioned I get this: 00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 6150SE nForce 430] (rev a2) sh-4.1# cd :00:0d.0 sh-4.1# cd driver sh-4.1# echo ":00:0d.0" > unbind [ 144.585574] BUG: unable to handle kernel NULL pointer dereference at (null) [ 144.585588] IP: [] nouveau_bo_move_ntfy+0x25/0xb0 [nouveau] [ 144.585605] PGD 30b5a067 PUD 30af1067 PMD 0 [ 144.585612] Oops: [#1] PREEMPT SMP [ 144.585619] CPU 0 [ 144.585622] Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c radeon sg sd_mod fbcon tileblit nouveau font bitblit softcursor ttm drm_kms_helper mxm_wmi wmi video sata_nv ata_generic libata skge e1000 scsi_mod xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs [last unloaded: dump_dma] [ 144.585705] [ 144.585709] Pid: 3223, comm: sh Tainted: G O 3.2.0-rc5-00169-g82d722f #2 BIOSTAR Group N61PB-M2S/N61PB-M2S [ 144.585718] RIP: e030:[] [] nouveau_bo_move_ntfy+0x25/0xb0 [nouveau] [ 144.585730] RSP: e02b:880030a69bf8 EFLAGS: 00010292 [ 144.585733] RAX: a012a7e0 RBX: 88002dacca10 RCX: 88000ef80498 [ 144.585737] RDX: 88000ef80498 RSI: RDI: 88002dacc800 [ 144.585741] RBP: 880030a69c28 R08: R09: 88000f228d38 [ 144.585745] R10: 0001 R11: R12: [ 144.585749] R13: 88002dacca10 R14: 88002dacc800 R15: 88000f228d38 [ 144.585757] FS: 7fcdfa067700() GS:88003fe5b000() knlGS: [ 144.585761] CS: e033 DS: ES: CR0: 8005003b [ 144.585765] CR2: CR3: 30bc6000 CR4: 0660 [ 144.585769] DR0: DR1: DR2: [ 144.585774] DR3: DR6: 0ff0 DR7: 0400 [ 144.585778] Process sh (pid: 3223, threadinfo 880030a68000, task 88003a3809f0) [ 144.585782] Stack: [ 144.585784] 880030a69c18 88002dacc800 0001 88000ef80728 [ 144.585793] 88000ef80320 88000f228d38 880030a69c48 a00f4aa1 [ 144.585802] 880030a69c48 88002dacc800 880030a69cb8 a00f7ad9 [ 144.585810] Call Trace: [ 144.585818] [] ttm_bo_cleanup_memtype_use+0x21/0x80 [ttm] [ 144.585825] [] ttm_bo_release+0x249/0x270 [ttm] [ 144.585833] [] ? get_parent_ip+0x11/0x50 [ 144.585839] [] ? ttm_bo_create+0x110/0x110 [ttm] [ 144.585846] [] kref_put+0x37/0x70 [ 144.585852] [] ttm_bo_unref+0x3d/0x50 [ttm] [ 144.585859] [] ? drm_gem_object_handle_free+0x90/0x90 [ 144.585868] [] nouveau_gem_object_del+0x3a/0x70 [nouveau] [ 144.585874] [] drm_gem_object_free+0x25/0x40 [ 144.585879] [] kref_put+0x37/0x70 [ 144.585890] [] nouveau_fbcon_fini+0xb1/0x130 [nouveau] [ 144.585899] [] nouveau_unload+0x1b5/0x220 [nouveau] [ 144.585904] [] ? drm_lastclose+0x2b2/0x300 [ 144.585910] [] drm_put_dev+0x6e/0x240 [ 144.585918] [] nouveau_pci_remove+0x18/0x20 [nouveau] [ 144.585924] [] pci_device_remove+0x32/0x60 [ 144.585930] [] __device_release_driver+0x61/0xc0 [ 144.585935] [] device_release_driver+0x28/0x40 [ 144.585940] [] driver_unbind+0x99/0xb0 [ 144.585945] [] drv_attr_store+0x27/0x30 [ 144.585951] [] sysfs_write_file+0xdd/0x160 [ 144.585957] [] vfs_write+0xc8/0x190 [ 144.585962] [] sys_write+0x4c/0x90 [ 144.585968] [] system_call_fastpath+0x16/0x1b [ 144.585972] Code: 84 00 00 00 00 00 55 48 89 e5 41 57 41 56 49 89 fe 41 55 4c 8d af 10 02 00 00 41 54 49 89 f4 53 48 83 ec 08 48 8b 9f 10 02 00 00 <4c> 8b 3e 4c 39 eb 75 13 eb 61 90 48 89 df e8 78 75 02 00 48 8b [ 144.586053] RIP [] nouveau_bo_move_ntfy+0x25/0xb0 [nouveau] [ 144.586059] RSP [ 144.586059] CR2: [ 144.586059] ---[ end trace 520b019831a63add ]--- Dec 12 16:49:49 tst004 init: process '/bin/sh' (pid 3223) exited. Scheduling for restart. Dec 12 16:49:49 tst004 init: starting pid 3331, tty '/dev/hvc0': '/bin/sh' sh-4.1# ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: ttm dma allocator issue ?
On Mon, Dec 12, 2011 at 12:37:43PM -0500, Konrad Rzeszutek Wilk wrote: > > > Any ideas ? > > > > The only way to do that would be to modify the 'struct dma_page' vaddr and > > dma > > variables from what they had in __ttm_dma_alloc_page. But I am not seeing > > any > > willfull modifications. We do pass in to dma_free_coherent the _same_ > > values! > > > > > > Hm, it might be worth adding in the 'struct dma_page' a 'virt_to_phys' value > > (which is what the DMA debug API uses to check), and see we get inconsitent > > values _before_ we call the DMA debug API. This is rather to double check > > the DMA API debug API. I am going to try something like this (not compile > > tested at all): > > This one is compile tested :-) > > diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c > b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c > index 6678abc..659b0ee 100644 > --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c > +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c > @@ -32,7 +32,7 @@ > * - Tracks whether the page is UC, WB or cached (and reverts to WB > * when freed). > */ > - And I think if you cherry-pick git commit 91ec37cc1015220965e39bf342fb846810d19e79 Author: Thomas Jarosch Date: Thu Nov 17 20:31:02 2011 +0100 Fix comparison using wrong pointer variable in dma debug code which fixes the DMA debug API code, the error you are getting will go away. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/exynos: Add plane support with fimd
On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote: > From: Joonyoung Shim > > The exynos fimd supports 5 window overlays. Only one window overlay of > fimd is used by the crtc, so we need plane feature to use the rest > window overlays. > > This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it > is the ioctl to decide for user to assign which window overlay. > btw, I think I will end up with a similar ioctl.. so thought I'd double check for consistency, is zorder interpreted from back to front or front to back? Ie. higher numeric value in front or behind of lower numeric value? Are negative values permitted? BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/exynos: Add plane support with fimd
On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote:
> +static int
> +exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
> + struct drm_framebuffer *fb, int crtc_x, int crtc_y,
> + unsigned int crtc_w, unsigned int crtc_h,
> + uint32_t src_x, uint32_t src_y,
> + uint32_t src_w, uint32_t src_h)
> +{
> + struct exynos_plane *exynos_plane =
> + container_of(plane, struct exynos_plane, base);
> + struct exynos_drm_overlay *overlay = &exynos_plane->overlay;
> + struct exynos_drm_crtc_pos pos;
> + int ret;
> +
> + DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
> +
> + memset(&pos, 0, sizeof(struct exynos_drm_crtc_pos));
> + pos.crtc_x = crtc_x;
> + pos.crtc_y = crtc_y;
> + pos.crtc_w = crtc_w;
> + pos.crtc_h = crtc_h;
> +
> + pos.fb_x = src_x;
> + pos.fb_y = src_y;
also, I think src_x/src_y should be interpreted at 16.16/Q16 fixed
point. But elsewhere were I see fb_x/y used it, it doesn't appear to
be interpreted this way.
Also, I *think* that comment was meant to apply to src_h/src_w
(Jesse?), but you seem to ignore these parameters..
BR,
-R
> +
> + /* TODO: scale feature */
> + ret = exynos_drm_overlay_update(overlay, fb, &crtc->mode, &pos);
> + if (ret < 0)
> + return ret;
> +
> + exynos_drm_fn_encoder(crtc, overlay,
> + exynos_drm_encoder_crtc_mode_set);
> + exynos_drm_fn_encoder(crtc, &overlay->zpos,
> + exynos_drm_encoder_crtc_plane_commit);
> +
> + exynos_plane->enabled = true;
> +
> + return 0;
> +}
> +
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/23] drm/via: use drm_mm instead of drm_sman
On Wed, Dec 07, 2011 at 04:28:45PM +, James Simmons wrote: > > > Chris Wilson rightly complained that this doesn't explain the list_del > > magic going on. New commit msg reads: > > > > To make the transition in a piece-wise and bisectable way possible, > > I've hijacked the ->owner_list from drm_sman. While transitioning, the > > list_add was done by the driver, while the list_del was still done by > > the dying sman code. > > > > Now that we are in full control of ->owner_list, do the list_del > > ourselves. > > > > He also noted the superflous additions of INIT_LIST_HEAD and the stale > > comment about spinlock locking in the idr allocation (protected by > > dev->struct_mutex) that I've copied over. All fixed up and pushed out for > > the moment to my fdo repo: > > > > http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire > > Speaking of I attempted to clone that repo but it gives me > > warning: remote HEAD refers to nonexistent ref, unable to checkout. It's a headless git repo, so you have to check out a specific branch explicitly. Simplest way to do so is with git fetch in an exisiting lk git checkout which should grab that branch into FETCH_HEAD. Then you can check it out, merge it, ... -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm_framebuffer_cleanup cleanup..
On Fri, Dec 9, 2011 at 18:44, Dave Airlie wrote:
> On Fri, Dec 9, 2011 at 5:40 PM, Rob Clark wrote:
>> On Wed, Oct 19, 2011 at 8:27 AM, Daniel Vetter wrote:
+static void omap_framebuffer_destroy(struct drm_framebuffer *fb)
+{
+ struct drm_device *dev = fb->dev;
+ struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
+
+ DBG("destroy: FB ID: %d (%p)", fb->base.id, fb);
+
+ drm_framebuffer_cleanup(fb);
>>>
>>> This is a bit a general mess in kms. All drivers need to call this, and
>>> for added hilarity
>>> - drm_crtc.c drm_mode_rmfb has a TODO that this is missing
>>> - nouveau/radeon only do this _after_ unref'ing the backing storage
>>> - gma500 also tries to restore the kernel console here which should be
>>> done in lastclose (because you might disable another userspace fb on
>>> another output).
>>>
>>> Can I prod you to write the patches to clean this up and move
>>> drm_framebuffer_cleanup into common code?
>>
>> fyi, I'm starting to look at this.. looks like crtc/encoder/connector
>> cleanup could also benefit from some similar treatment. I'll start w/
>> just fb, since that is a resource that is actually dynamically
>> created/destroyed, so seems a bit more critical..
>
> I'm not sure reversing the flow here is the right answer, this is
> mainly trying to avoid midlayering things, the driver controls when
> stuff happens and it controls init the framebuffer object it controls
> destroying it as well.
The above proposal was more in the light of eventually switching to
properly ref-counted framebuffers. The common kms code would then keep
track of the references it knows about from the current modeset
configuration and hence also responsible for dropping them (i.e. what
drm_framebuffer_cleanup currently does). The driver could then still
hold onto references it needs internally and is also still in control
of fb destruction - the driver's fb_destroy would be called when the
last reference disappears.
So I don't see an "inversion of control through stupid middle-layer"
issue here, more like "resource lifetime mess through lack of
refcounting". But I agree that we can keep the drm_framebuffer_cleanup
where it currently is until it completely disappears with proper fb
refcounting.
Cheers, Daniel
--
Daniel Vetter
daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/exynos: Add plane support with fimd
On 12/13/2011 07:48 AM, Rob Clark wrote:
On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote:
+static int
+exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
+struct drm_framebuffer *fb, int crtc_x, int crtc_y,
+unsigned int crtc_w, unsigned int crtc_h,
+uint32_t src_x, uint32_t src_y,
+uint32_t src_w, uint32_t src_h)
+{
+ struct exynos_plane *exynos_plane =
+ container_of(plane, struct exynos_plane, base);
+ struct exynos_drm_overlay *overlay =&exynos_plane->overlay;
+ struct exynos_drm_crtc_pos pos;
+ int ret;
+
+ DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
+
+ memset(&pos, 0, sizeof(struct exynos_drm_crtc_pos));
+ pos.crtc_x = crtc_x;
+ pos.crtc_y = crtc_y;
+ pos.crtc_w = crtc_w;
+ pos.crtc_h = crtc_h;
+
+ pos.fb_x = src_x;
+ pos.fb_y = src_y;
also, I think src_x/src_y should be interpreted at 16.16/Q16 fixed
point. But elsewhere were I see fb_x/y used it, it doesn't appear to
be interpreted this way.
Right, this will be fixed.
Thanks.
Also, I *think* that comment was meant to apply to src_h/src_w
(Jesse?), but you seem to ignore these parameters..
BR,
-R
+
+ /* TODO: scale feature */
+ ret = exynos_drm_overlay_update(overlay, fb,&crtc->mode,&pos);
+ if (ret< 0)
+ return ret;
+
+ exynos_drm_fn_encoder(crtc, overlay,
+ exynos_drm_encoder_crtc_mode_set);
+ exynos_drm_fn_encoder(crtc,&overlay->zpos,
+ exynos_drm_encoder_crtc_plane_commit);
+
+ exynos_plane->enabled = true;
+
+ return 0;
+}
+
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] staging: drm/omap: fix for connectors not enabled at bootup
On Sun, Dec 11, 2011 at 03:13:17PM -0600, Rob Clark wrote: > From: Rob Clark > > The connector's dpms fxn is only triggered by userspace. When the > driver is loaded and detected displays configured, drm core only > calls the crtc and encoder's dpms functions. > > Signed-off-by: Rob Clark > --- > Arguably, this could be called a work-around, and instead drm core > should call connector's dpms functions and rely on > drm_helper_connector_dpms to call encoder and crtc dpms functions. > If people think it is better to fix this in drm core, and don't > mind me making that change, then I will do that instead. Sounds like you should do that in the drm core itself, so I'll not queue up this patch for now. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/exynos: Add plane support with fimd
On 12/13/2011 06:59 AM, Rob Clark wrote: On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote: From: Joonyoung Shim The exynos fimd supports 5 window overlays. Only one window overlay of fimd is used by the crtc, so we need plane feature to use the rest window overlays. This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it is the ioctl to decide for user to assign which window overlay. btw, I think I will end up with a similar ioctl.. so thought I'd double check for consistency, is zorder interpreted from back to front or front to back? Ie. higher numeric value in front or behind of lower numeric value? Are negative values permitted? The zpos of exynos plane is just the index of overlay of exynos fimd or exynos hdmi. 0 zpos means first overlay and 1 zpos means second overlay. It isn't the priority value but higher zpos will have higher priority generally. A negative value -1 is defined to special value. A exynos crtc should use one overlay and -1 zpos means the overlay that crtc uses. Thanks. BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43768] New: [i915g] src/gallium/drivers/i915/i915_fpc_translate.c:1101:i915_translate_token: Assertion `ifs->constant_flags[i] == 0x0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=43768 Bug #: 43768 Summary: [i915g] src/gallium/drivers/i915/i915_fpc_translate.c:1101:i91 5_translate_token: Assertion `ifs->constant_flags[i] == 0x0' failed. Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/i915g AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: v...@vmware.com mesa: 23895cc006f3dbf96a502ddd15e291e071aff25a (master) Run piglit glsl-fs-convolution-1 test on i915g. $ ./bin/shader_runner tests/shaders/glsl-fs-convolution-1.shader_test -auto src/gallium/drivers/i915/i915_fpc_translate.c:1101:i915_translate_token: Assertion `ifs->constant_flags[i] == 0x0' failed. Trace/breakpoint trap (core dumped) (gdb) bt #0 0x010eee18 in _debug_assert_fail (expr=0x1a68743 "ifs->constant_flags[i] == 0x0", file=0x1a683d8 "src/gallium/drivers/i915/i915_fpc_translate.c", line=1101, function=0x1a6884b "i915_translate_token") at src/gallium/auxiliary/util/u_debug.c:278 #1 0x0109e0ad in i915_translate_token (p=0x98611f8, token=0x98a23f8, fs=0x98602f8) at src/gallium/drivers/i915/i915_fpc_translate.c:1101 #2 0x0109e372 in i915_translate_instructions (p=0x98611f8, tokens=0x9867890, fs=0x98602f8) at src/gallium/drivers/i915/i915_fpc_translate.c:1178 #3 0x0109e90c in i915_translate_fragment_program (i915=0x96ce8c0, fs=0x98602f8) at src/gallium/drivers/i915/i915_fpc_translate.c:1340 #4 0x010967d6 in i915_create_fs_state (pipe=0x96ce8c0, templ=0x98d977c) at src/gallium/drivers/i915/i915_state.c:577 #5 0x010c0910 in aaline_create_fs_state (pipe=0x96ce8c0, fs=0x98d977c) at src/gallium/auxiliary/draw/draw_pipe_aaline.c:856 #6 0x010c2a2f in aapoint_create_fs_state (pipe=0x96ce8c0, fs=0x98d977c) at src/gallium/auxiliary/draw/draw_pipe_aapoint.c:839 #7 0x0191d608 in st_translate_fragment_program (st=0x97bc488, stfp=0x98c9420, key=0xbfa60ca0) at src/mesa/state_tracker/st_program.c:710 #8 0x0191d729 in st_get_fp_variant (st=0x97bc488, stfp=0x98c9420, key=0xbfa60ca0) at src/mesa/state_tracker/st_program.c:747 #9 0x019c913d in update_fp (st=0x97bc488) at src/mesa/state_tracker/st_atom_shader.c:86 #10 0x019c543b in st_validate_state (st=0x97bc488) at src/mesa/state_tracker/st_atom.c:177 #11 0x01918144 in st_draw_vbo (ctx=0x97663d8, arrays=0x97bf8a0, prims=0xbfa60dec, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3) at src/mesa/state_tracker/st_draw.c:979 #12 0x019ab5ff in vbo_draw_arrays (ctx=0x97663d8, mode=7, start=0, count=4, numInstances=1) at src/mesa/vbo/vbo_exec_array.c:620 #13 0x019ab757 in vbo_exec_DrawArrays (mode=7, start=0, count=4) at src/mesa/vbo/vbo_exec_array.c:651 #14 0x0809cbf6 in piglit_draw_rect (x=-1, y=-1, w=2, h=2) at piglit/tests/util/piglit-util-gl.c:647 #15 0x0807289d in piglit_display () at piglit/tests/shaders/shader_runner.c:1095 #16 0x08074147 in display () at piglit/tests/util/piglit-framework.c:56 #17 0x0062ec1e in fghRedrawWindow (window=0x96c6a28) at freeglut_main.c:210 #18 fghcbDisplayWindow (window=0x96c6a28, enumerator=0xbfa61118) at freeglut_main.c:227 #19 0x00632590 in fgEnumWindows (enumCallback=0x62eb20 , enumerator=0xbfa61118) at freeglut_structure.c:394 #20 0x0062f02e in fghDisplayAll () at freeglut_main.c:249 #21 glutMainLoopEvent () at freeglut_main.c:1450 #22 0x0062f935 in glutMainLoop () at freeglut_main.c:1498 #23 0x0807487e in main (argc=2, argv=0xbfa61384) at piglit/tests/util/piglit-framework.c:294 (gdb) frame 1 #1 0x0109e0ad in i915_translate_token (p=0x98611f8, token=0x98a23f8, fs=0x98602f8) at src/gallium/drivers/i915/i915_fpc_translate.c:1101 1101assert(ifs->constant_flags[i] == 0x0); (gdb) info locals i = 32 ifs = 0x98602f8 __FUNCTION__ = "i915_translate_token" (gdb) print ifs->constant_flags[i] $1 = 255 '\377' -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/exynos: Add plane support with fimd
On Mon, Dec 12, 2011 at 6:41 PM, Joonyoung Shim wrote: > On 12/13/2011 06:59 AM, Rob Clark wrote: >> >> On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote: >>> >>> From: Joonyoung Shim >>> >>> The exynos fimd supports 5 window overlays. Only one window overlay of >>> fimd is used by the crtc, so we need plane feature to use the rest >>> window overlays. >>> >>> This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it >>> is the ioctl to decide for user to assign which window overlay. >>> >> btw, I think I will end up with a similar ioctl.. so thought I'd >> double check for consistency, is zorder interpreted from back to front >> or front to back? Ie. higher numeric value in front or behind of >> lower numeric value? Are negative values permitted? > > > The zpos of exynos plane is just the index of overlay of exynos fimd or > exynos hdmi. 0 zpos means first overlay and 1 zpos means second overlay. > It isn't the priority value but higher zpos will have higher priority > generally. I'm not sure that I quite understand that.. does that mean zpos=1 will be in front of zpos=0 (which would be in front of crtc, aka zpos=-1). Do you have a way to put overlays *behind* crtc layer (which presumably would be in some mode with an alpha channel?) (IIRC, samsung has some public TRM type document.. if this is covered there, feel free to answer by just pointing me at the section I should read) BR, -R > A negative value -1 is defined to special value. A exynos crtc should > use one overlay and -1 zpos means the overlay that crtc uses. > > Thanks. > >> BR, >> -R >> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43769] New: [i915g] src/gallium/drivers/i915/i915_fpc_translate.c:658:i915_translate_instruction: Assertion `0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=43769 Bug #: 43769 Summary: [i915g] src/gallium/drivers/i915/i915_fpc_translate.c:658:i915 _translate_instruction: Assertion `0' failed. Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/i915g AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: v...@vmware.com mesa: 23895cc006f3dbf96a502ddd15e291e071aff25a (master) Run piglit glsl-fs-discard-03 test on i915g. $ ./bin/shader_runner tests/shaders/glsl-fs-discard-03.shader_test -auto src/gallium/drivers/i915/i915_fpc_translate.c:658:i915_translate_instruction: Assertion `0' failed. Trace/breakpoint trap (core dumped) (gdb) bt #0 0x01126e18 in _debug_assert_fail (expr=0x1aa052a "0", file=0x1aa03d8 "src/gallium/drivers/i915/i915_fpc_translate.c", line=658, function=0x1aa0860 "i915_translate_instruction") at src/gallium/auxiliary/util/u_debug.c:278 #1 0x010d4666 in i915_translate_instruction (p=0xa1b7528, inst=0xa1c08c8, fs=0xa1c0118) at src/gallium/drivers/i915/i915_fpc_translate.c:658 #2 0x010d62fe in i915_translate_token (p=0xa1b7528, token=0xa1c08c8, fs=0xa1c0118) at src/gallium/drivers/i915/i915_fpc_translate.c:1157 #3 0x010d6372 in i915_translate_instructions (p=0xa1b7528, tokens=0xa15af08, fs=0xa1c0118) at src/gallium/drivers/i915/i915_fpc_translate.c:1178 #4 0x010d690c in i915_translate_fragment_program (i915=0xa0678c0, fs=0xa1c0118) at src/gallium/drivers/i915/i915_fpc_translate.c:1340 #5 0x010ce7d6 in i915_create_fs_state (pipe=0xa0678c0, templ=0xa1ebee4) at src/gallium/drivers/i915/i915_state.c:577 #6 0x010f8910 in aaline_create_fs_state (pipe=0xa0678c0, fs=0xa1ebee4) at src/gallium/auxiliary/draw/draw_pipe_aaline.c:856 #7 0x010faa2f in aapoint_create_fs_state (pipe=0xa0678c0, fs=0xa1ebee4) at src/gallium/auxiliary/draw/draw_pipe_aapoint.c:839 #8 0x01955608 in st_translate_fragment_program (st=0xa155488, stfp=0xa1dbb88, key=0xbf932470) at src/mesa/state_tracker/st_program.c:710 #9 0x01955729 in st_get_fp_variant (st=0xa155488, stfp=0xa1dbb88, key=0xbf932470) at src/mesa/state_tracker/st_program.c:747 #10 0x01a0113d in update_fp (st=0xa155488) at src/mesa/state_tracker/st_atom_shader.c:86 #11 0x019fd43b in st_validate_state (st=0xa155488) at src/mesa/state_tracker/st_atom.c:177 #12 0x01a07eec in st_Clear (ctx=0xa0ff3d8, mask=2) at src/mesa/state_tracker/st_cb_clear.c:507 #13 0x0197eeb3 in _mesa_Clear (mask=16384) at src/mesa/main/clear.c:242 #14 0x08072795 in piglit_display () at piglit/tests/shaders/shader_runner.c:1084 #15 0x08074147 in display () at piglit/tests/util/piglit-framework.c:56 #16 0x0076bc1e in fghRedrawWindow (window=0xa05fa28) at freeglut_main.c:210 #17 fghcbDisplayWindow (window=0xa05fa28, enumerator=0xbf9327b8) at freeglut_main.c:227 #18 0x0076f590 in fgEnumWindows (enumCallback=0x76bb20 , enumerator=0xbf9327b8) at freeglut_structure.c:394 #19 0x0076c02e in fghDisplayAll () at freeglut_main.c:249 #20 glutMainLoopEvent () at freeglut_main.c:1450 #21 0x0076c935 in glutMainLoop () at freeglut_main.c:1498 #22 0x0807487e in main (argc=2, argv=0xbf932a24) at piglit/tests/util/piglit-framework.c:294 (gdb) frame 1 #1 0x010d4666 in i915_translate_instruction (p=0xa1b7528, inst=0xa1c08c8, fs=0xa1c0118) at src/gallium/drivers/i915/i915_fpc_translate.c:658 658 assert(0); /* not tested yet */ (gdb) l 653 T0_TEXKILL,/* opcode */ 654 1);/* num_coord */ 655 break; 656 657 case TGSI_OPCODE_KILP: 658 assert(0); /* not tested yet */ 659 break; 660 661 case TGSI_OPCODE_LG2: 662 src0 = src_vector(p, &inst->Src[0], fs); -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] updates for drm API changes in drm-next
From: Rob Clark These two patches cover API changes that are currently in drm-next for 3.3. The 2nd of which is the first part for enabling drm_plane support (but doesn't yet enable the new overlay functionality). I'll have another patchset, hopefully later this week, which adds the remaining bits to enable overlay (drm_plane) support. Greg I'm not sure if you want these patches now, or just after the 3.3 merge window opens. Also, if it is easier for you, I can setup a tree that you could pull from. Please let me know what you prefer. Rob Clark (2): drm/omap: drm API update: make fops struct const drm/omap: drm API update: addfb2 drivers/staging/omapdrm/omap_drv.c | 24 + drivers/staging/omapdrm/omap_drv.h | 53 ++- drivers/staging/omapdrm/omap_fb.c| 96 ++--- drivers/staging/omapdrm/omap_fbdev.c | 29 ++ 4 files changed, 156 insertions(+), 46 deletions(-) -- 1.7.5.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/omap: drm API update: make fops struct const
From: Rob Clark
Update to reflect changes in:
"Make the per-driver file_operations struct const"
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_drv.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c
b/drivers/staging/omapdrm/omap_drv.c
index 7ecf578..d05e2b4 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -708,6 +708,18 @@ static struct vm_operations_struct omap_gem_vm_ops = {
.close = drm_gem_vm_close,
};
+static const struct file_operations omapdriver_fops = {
+ .owner = THIS_MODULE,
+ .open = drm_open,
+ .unlocked_ioctl = drm_ioctl,
+ .release = drm_release,
+ .mmap = omap_gem_mmap,
+ .poll = drm_poll,
+ .fasync = drm_fasync,
+ .read = drm_read,
+ .llseek = noop_llseek,
+};
+
static struct drm_driver omap_drm_driver = {
.driver_features =
DRIVER_HAVE_IRQ | DRIVER_MODESET | DRIVER_GEM,
@@ -734,17 +746,7 @@ static struct drm_driver omap_drm_driver = {
.dumb_destroy = omap_gem_dumb_destroy,
.ioctls = ioctls,
.num_ioctls = DRM_OMAP_NUM_IOCTLS,
- .fops = {
- .owner = THIS_MODULE,
- .open = drm_open,
- .unlocked_ioctl = drm_ioctl,
- .release = drm_release,
- .mmap = omap_gem_mmap,
- .poll = drm_poll,
- .fasync = drm_fasync,
- .read = drm_read,
- .llseek = noop_llseek,
- },
+ .fops = &omapdriver_fops,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
.date = DRIVER_DATE,
--
1.7.5.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/omap: drm API update: addfb2
From: Rob Clark
Update to reflect changes in:
"drm: add an fb creation ioctl that takes a pixel format v5"
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_drv.h | 53 ++-
drivers/staging/omapdrm/omap_fb.c| 96 ++---
drivers/staging/omapdrm/omap_fbdev.c | 29 ++
3 files changed, 143 insertions(+), 35 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.h
b/drivers/staging/omapdrm/omap_drv.h
index 8dd7d74..bc8daa7 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -76,9 +76,9 @@ void omap_connector_flush(struct drm_connector *connector,
void omap_connector_dpms(struct drm_connector *connector, int mode);
struct drm_framebuffer *omap_framebuffer_create(struct drm_device *dev,
- struct drm_file *file, struct drm_mode_fb_cmd *mode_cmd);
+ struct drm_file *file, struct drm_mode_fb_cmd2 *mode_cmd);
struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
- struct drm_mode_fb_cmd *mode_cmd, struct drm_gem_object *bo);
+ struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);
struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb);
int omap_framebuffer_get_buffer(struct drm_framebuffer *fb, int x, int y,
void **vaddr, dma_addr_t *paddr, unsigned int *screen_width);
@@ -128,4 +128,53 @@ static inline int align_pitch(int pitch, int width, int
bpp)
return ALIGN(pitch, 8 * bytespp);
}
+/* should these be made into common util helpers?
+ */
+
+static inline int num_planes(uint32_t pixel_format)
+{
+ switch (pixel_format) {
+ default:
+ return 1;
+ case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV21:
+ case DRM_FORMAT_NV16:
+ case DRM_FORMAT_NV61:
+ return 2;
+ case DRM_FORMAT_YUV410:
+ case DRM_FORMAT_YVU410:
+ case DRM_FORMAT_YUV411:
+ case DRM_FORMAT_YVU411:
+ case DRM_FORMAT_YUV420:
+ case DRM_FORMAT_YVU420:
+ case DRM_FORMAT_YUV422:
+ case DRM_FORMAT_YVU422:
+ case DRM_FORMAT_YUV444:
+ case DRM_FORMAT_YVU444:
+ return 3;
+ }
+}
+
+static inline int objects_lookup(struct drm_device *dev,
+ struct drm_file *filp, uint32_t pixel_format,
+ struct drm_gem_object **bos, uint32_t *handles)
+{
+ int i, n = num_planes(pixel_format);
+
+ for (i = 0; i < n; i++) {
+ bos[i] = drm_gem_object_lookup(dev, filp, handles[i]);
+ if (!bos[i]) {
+ goto fail;
+ }
+ }
+
+ return 0;
+
+fail:
+ while (--i > 0) {
+ drm_gem_object_unreference_unlocked(bos[i]);
+ }
+ return -ENOENT;
+}
+
#endif /* __OMAP_DRV_H__ */
diff --git a/drivers/staging/omapdrm/omap_fb.c
b/drivers/staging/omapdrm/omap_fb.c
index 0b50c5b..b28fee3 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -22,11 +22,41 @@
#include "drm_crtc.h"
#include "drm_crtc_helper.h"
-
/*
* framebuffer funcs
*/
+struct format {
+ enum omap_color_mode dss_format;
+ uint32_t pixel_format;
+ int stride_bpp; /* this times width is stride */
+ bool yuv;
+};
+
+static struct format formats[] = {
+ /* 16bpp [A]RGB: */
+ { OMAP_DSS_COLOR_RGB16, DRM_FORMAT_RGB565, 2, false }, /*
RGB16-565 */
+ { OMAP_DSS_COLOR_RGB12U, DRM_FORMAT_RGBX, 2, false }, /*
RGB12x- */
+ { OMAP_DSS_COLOR_RGBX16, DRM_FORMAT_XRGB, 2, false }, /*
xRGB12- */
+ { OMAP_DSS_COLOR_RGBA16, DRM_FORMAT_RGBA, 2, false }, /*
RGBA12- */
+ { OMAP_DSS_COLOR_ARGB16, DRM_FORMAT_ABGR, 2, false }, /*
ARGB16- */
+ { OMAP_DSS_COLOR_XRGB16_1555, DRM_FORMAT_XRGB1555, 2, false }, /*
xRGB15-1555 */
+ { OMAP_DSS_COLOR_ARGB16_1555, DRM_FORMAT_ARGB1555, 2, false }, /*
ARGB16-1555 */
+ /* 24bpp RGB: */
+ { OMAP_DSS_COLOR_RGB24P, DRM_FORMAT_RGB888, 3, false }, /*
RGB24-888 */
+ /* 32bpp [A]RGB: */
+ { OMAP_DSS_COLOR_RGBX32, DRM_FORMAT_RGBX, 4, false }, /*
RGBx24- */
+ { OMAP_DSS_COLOR_RGB24U, DRM_FORMAT_XRGB, 4, false }, /*
xRGB24- */
+ { OMAP_DSS_COLOR_RGBA32, DRM_FORMAT_RGBA, 4, false }, /*
RGBA32- */
+ { OMAP_DSS_COLOR_ARGB32, DRM_FORMAT_ARGB, 4, false }, /*
ARGB32- */
+ /* YUV: */
+/* TODO: multi-planar support..
+ { OMAP_DSS_COLOR_NV12,DRM_FORMAT_NV12, 1, true },
+ */
+ { OMAP_DSS_COLOR_YUV2,DRM_FORMAT_YUYV, 2, true },
+ { OMAP_DSS_COLOR_UYVY,DRM_FORMAT_UYVY, 2, true },
+};
+
#define to_omap_framebuffer(x) container_of(x, struct omap_framebuffer, base)
struct omap_framebuffer {
@@ -171,39 +201,61 @@ void omap_framebuffer_flush(struct drm_framebuffer *f
[Bug 38661] [i915g] src/gallium/drivers/i915/i915_state_static.c:122:update_framebuffer: Assertion `offset == 0' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=38661 --- Comment #3 from Vinson Lee 2011-12-12 16:50:10 PST --- mesa: 23895cc006f3dbf96a502ddd15e291e071aff25a (master) Assert still occurs. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/omap: drm API update: make fops struct const
On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote: > From: Rob Clark > > Update to reflect changes in: > "Make the per-driver file_operations struct const" This one I could take today, no need for me to rely on the drm api changes, right? greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/omap: drm API update: addfb2
On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote: > From: Rob Clark > > Update to reflect changes in: > "drm: add an fb creation ioctl that takes a pixel format v5" This one I'm going to have to wait for the drm api merges to happen, so I'll just wait for them to go into Linus's tree before taking them, ok? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/omap: drm API update: make fops struct const
On Mon, Dec 12, 2011 at 6:55 PM, Greg KH wrote: > On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote: >> From: Rob Clark >> >> Update to reflect changes in: >> "Make the per-driver file_operations struct const" > > This one I could take today, no need for me to rely on the drm api > changes, right? I don't think so, at least not if you want it to compile ;-) Previously the 'struct file_operations' was inline with the 'struct drm_driver' rather than a pointer. But if it it makes it easier for you to keep track I can keep a tree that you can pull from w/ a branch on top with the patches that depend on stuff coming in thru drm-next. BR, -R > greg k-h > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/omap: drm API update: addfb2
On Mon, Dec 12, 2011 at 6:56 PM, Greg KH wrote: > On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote: >> From: Rob Clark >> >> Update to reflect changes in: >> "drm: add an fb creation ioctl that takes a pixel format v5" > > This one I'm going to have to wait for the drm api merges to happen, so > I'll just wait for them to go into Linus's tree before taking them, ok? Yup, thanks. That was the intention. Let me know if it gets confusing to know which patches can go now and which have dependency on other trees, and I can setup a git tree on freedesktop which branches for the parts that depend on other trees. I'm not sure if it begins to get a mess to keep track otherwise. BR, -R > thanks, > > greg k-h > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/omap: drm API update: make fops struct const
On Mon, Dec 12, 2011 at 06:59:59PM -0600, Rob Clark wrote: > On Mon, Dec 12, 2011 at 6:55 PM, Greg KH wrote: > > On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote: > >> From: Rob Clark > >> > >> Update to reflect changes in: > >> "Make the per-driver file_operations struct const" > > > > This one I could take today, no need for me to rely on the drm api > > changes, right? > > I don't think so, at least not if you want it to compile ;-) Doh, you are right, sorry about that. > Previously the 'struct file_operations' was inline with the 'struct > drm_driver' rather than a pointer. But if it it makes it easier for > you to keep track I can keep a tree that you can pull from w/ a branch > on top with the patches that depend on stuff coming in thru drm-next. No, that would mix the two branches, and I can't do that, right? So let's just wait for the drm-next branch to be merged with Linus, and I'll hold onto these until then, ok? thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43770] New: [i915g] src/gallium/drivers/i915/i915_fpc_emit.c:153:i915_emit_arith: Assertion `(((dest)>>29)&0x7) != 2' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=43770 Bug #: 43770 Summary: [i915g] src/gallium/drivers/i915/i915_fpc_emit.c:153:i915_emit _arith: Assertion `(((dest)>>29)&0x7) != 2' failed. Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/i915g AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: v...@vmware.com mesa: 23895cc006f3dbf96a502ddd15e291e071aff25a (master) Run piglit fs-temp-array-mat3-index-col-row-rd test on i915g. $ ./bin/shader_runner tests/spec/glsl-1.20/execution/variable-indexing/fs-temp-array-mat3-index-col-row-rd.shader_test -auto Too many temps (16) Too many temps (17) Too many temps (18) Too many temps (19) Too many temps (20) Too many temps (21) Too many temps (22) Too many temps (23) Too many temps (24) Too many temps (25) Too many temps (26) Too many temps (27) Too many temps (28) Too many temps (29) Too many temps (30) Too many temps (31) Too many temps (32) Too many temps (33) Too many temps (34) Too many temps (35) Too many temps (36) Too many temps (37) Too many temps (38) Too many temps (39) Too many temps (40) Too many temps (41) Too many temps (42) Too many temps (43) Too many temps (44) Too many temps (45) Too many temps (46) Too many temps (47) Too many temps (48) Too many temps (49) Too many temps (50) Too many temps (51) Too many temps (52) Too many temps (53) Too many temps (54) Too many temps (55) Too many temps (56) Too many temps (57) Too many temps (58) Too many temps (59) Too many temps (60) Too many temps (61) Too many temps (62) Too many temps (63) Too many temps (64) Too many temps (65) Too many temps (66) Too many temps (67) i915_program_error: Exceeded max temporary reg i915_program_error: bad opcode 0 i915_program_error: Exceeded max temporary reg i915_program_error: bad opcode 0 i915_program_error: Exceeded max temporary reg i915_program_error: Exceeded max temporary reg i915_program_error: Exceeded max temporary reg i915_program_error: bad opcode 0 i915_program_error: Exceeded max temporary reg i915_program_error: Exceeded max temporary reg i915_program_error: Exceeded max temporary reg src/gallium/drivers/i915/i915_fpc_emit.c:153:i915_emit_arith: Assertion `(((dest)>>29)&0x7) != 2' failed. Trace/breakpoint trap (core dumped) (gdb) bt #0 0x01093e18 in _debug_assert_fail (expr=0x1a0edfd "(((dest)>>29)&0x7) != 2", file=0x1a0edd4 "src/gallium/drivers/i915/i915_fpc_emit.c", line=153, function=0x1a0ef40 "i915_emit_arith") at src/gallium/auxiliary/util/u_debug.c:278 #1 0x0104a6fa in i915_emit_arith (p=0x826d840, op=318767104, dest=1090593605, mask=15360, saturate=0, src0=1073741893, src1=0, src2=0) at src/gallium/drivers/i915/i915_fpc_emit.c:153 #2 0x0104251f in i915_translate_instruction (p=0x826d840, inst=0x8266a40, fs=0x825ca90) at src/gallium/drivers/i915/i915_fpc_translate.c:884 #3 0x010432fe in i915_translate_token (p=0x826d840, token=0x8266a40, fs=0x825ca90) at src/gallium/drivers/i915/i915_fpc_translate.c:1157 #4 0x01043372 in i915_translate_instructions (p=0x826d840, tokens=0x82598f8, fs=0x825ca90) at src/gallium/drivers/i915/i915_fpc_translate.c:1178 #5 0x0104390c in i915_translate_fragment_program (i915=0x81068c0, fs=0x825ca90) at src/gallium/drivers/i915/i915_fpc_translate.c:1340 #6 0x0103b7d6 in i915_create_fs_state (pipe=0x81068c0, templ=0x828f134) at src/gallium/drivers/i915/i915_state.c:577 #7 0x01065910 in aaline_create_fs_state (pipe=0x81068c0, fs=0x828f134) at src/gallium/auxiliary/draw/draw_pipe_aaline.c:856 #8 0x01067a2f in aapoint_create_fs_state (pipe=0x81068c0, fs=0x828f134) at src/gallium/auxiliary/draw/draw_pipe_aapoint.c:839 #9 0x018c2608 in st_translate_fragment_program (st=0x81f4488, stfp=0x827edd8, key=0xbfe38da0) at src/mesa/state_tracker/st_program.c:710 #10 0x018c2729 in st_get_fp_variant (st=0x81f4488, stfp=0x827edd8, key=0xbfe38da0) at src/mesa/state_tracker/st_program.c:747 #11 0x0196e13d in update_fp (st=0x81f4488) at src/mesa/state_tracker/st_atom_shader.c:86 #12 0x0196a43b in st_validate_state (st=0x81f4488) at src/mesa/state_tracker/st_atom.c:177 #13 0x01974eec in st_Clear (ctx=0x819e3d8, mask=2) at src/mesa/state_tracker/st_cb_clear.c:507 #14 0x018ebeb3 in _mesa_Clear (mask=16384) at src/mesa/main/clear.c:242 #15 0x08072795 in piglit_display () at piglit/tests/shaders/shader_runner.c:1084 #16 0x08074147 in display () at piglit/tests/util/piglit-framework.c:56 #17 0x007f2c1e in fghRedrawWindow (window=0x80fea28) at freeglut_main.c:210 #18 fghcbDisplayWindow (window=0x80fea28, enumerator=0xbfe390e8) at freeglut_main.c:227 #19 0x007f6590 in fgEnumWindows (enumCallback=0x7f2b20 , enumerator=0xbfe390e8) at freeglut_structure.c:394 #20 0x007f302e in fghDisplayAll () at freeglut_main.c:249 #21 glutMainLoopEvent () at
Re: [PATCH 1/2] drm/omap: drm API update: make fops struct const
On Mon, Dec 12, 2011 at 7:04 PM, Greg KH wrote: > On Mon, Dec 12, 2011 at 06:59:59PM -0600, Rob Clark wrote: >> On Mon, Dec 12, 2011 at 6:55 PM, Greg KH wrote: >> > On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote: >> >> From: Rob Clark >> >> >> >> Update to reflect changes in: >> >> "Make the per-driver file_operations struct const" >> > >> > This one I could take today, no need for me to rely on the drm api >> > changes, right? >> >> I don't think so, at least not if you want it to compile ;-) > > Doh, you are right, sorry about that. > >> Previously the 'struct file_operations' was inline with the 'struct >> drm_driver' rather than a pointer. But if it it makes it easier for >> you to keep track I can keep a tree that you can pull from w/ a branch >> on top with the patches that depend on stuff coming in thru drm-next. > > No, that would mix the two branches, and I can't do that, right? hmm, yeah > So let's just wait for the drm-next branch to be merged with Linus, and > I'll hold onto these until then, ok? ok, great.. if you don't mind just holding them until drm-next gets pulled into Linus's tree, that would be perfect. Thanks! BR, -R > thanks, > > greg k-h > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43771] New: [i915g] src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:821:lp_build_sample_mipmap: Assertion `img_filter == 1' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=43771 Bug #: 43771 Summary: [i915g] src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:821: lp_build_sample_mipmap: Assertion `img_filter == 1' failed. Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/i915g AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: v...@vmware.com mesa: 23895cc006f3dbf96a502ddd15e291e071aff25a (master) Run piglit fragment-and-vertex-texturing on i915g. The test triggers an assert on i915g but passes on llvmpipe. $ ./bin/fragment-and-vertex-texturing -autoThe result should be a solid block of half-bright yellow color src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:821:lp_build_sample_mipmap: Assertion `img_filter == 1' failed. Trace/breakpoint trap (core dumped) (gdb) bt #0 0x01131e18 in _debug_assert_fail (expr=0x1ac1858 "img_filter == 1", file=0x1ac1824 "src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c", line=821, function=0x1ac19d1 "lp_build_sample_mipmap") at src/gallium/auxiliary/util/u_debug.c:278 #1 0x011bddd1 in lp_build_sample_mipmap (bld=0xbfa61d08, img_filter=2, mip_filter=2, s=0x866a61c, t=0x866a2ec, r=0x862a480, ilevel0=0x866f4d4, ilevel1=0x0, lod_fpart=0x0, colors_lo_var=0x8665344, colors_hi_var=0x85e570c) at src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:821 #2 0x011be85f in lp_build_sample_aos (bld=0xbfa61d08, unit=0, s=0x866a61c, t=0x866a2ec, r=0x862a480, ddx=0xbfa61f40, ddy=0xbfa61f4c, lod_bias=0x0, explicit_lod=0x866b224, texel_out=0xbfa61fb0) at src/gallium/auxiliary/gallivm/lp_bld_sample_aos.c:1067 #3 0x011a89ae in lp_build_sample_soa (gallivm=0x8431fb8, static_state=0x86654d4, dynamic_state=0x8664490, type=..., unit=0, num_coords=2, coords=0xbfa61f34, ddx=0xbfa61f40, ddy=0xbfa61f4c, lod_bias=0x0, explicit_lod=0x866b224, texel_out=0xbfa61fb0) at src/gallium/auxiliary/gallivm/lp_bld_sample_soa.c:1253 #4 0x0116fe1f in draw_llvm_sampler_soa_emit_fetch_texel (base=0x8664488, gallivm=0x8431fb8, type=..., unit=0, num_coords=2, coords=0xbfa61f34, ddx=0xbfa61f40, ddy=0xbfa61f4c, lod_bias=0x0, explicit_lod=0x866b224, texel=0xbfa61fb0) at src/gallium/auxiliary/draw/draw_llvm_sample.c:186 #5 0x011aceb4 in emit_tex (bld=0xbfa62060, inst=0x86b6a98, modifier=LP_BLD_TEX_MODIFIER_EXPLICIT_LOD, texel=0xbfa61fb0) at src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:1145 #6 0x011b06e5 in emit_instruction (bld=0xbfa62060, inst=0x86b6a98, info=0x1d949e0, pc=0xbfa64758) at src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:2169 #7 0x011b13c9 in lp_build_tgsi_soa (gallivm=0x8431fb8, tokens=0x8680678, type=..., mask=0x0, consts_ptr=0x866bfcc, system_values_array=0x86648a4, pos=0x0, inputs=0xbfa64aac, outputs=0xbfa648ac, sampler=0x8664488, info=0x865abd8) at src/gallium/auxiliary/gallivm/lp_bld_tgsi_soa.c:2498 #8 0x0116c2e7 in generate_vs (llvm=0x848a6c8, builder=0x848a690, outputs=0xbfa648ac, inputs=0xbfa64aac, system_values_array=0x86648a4, context_ptr=0x86260a8, draw_sampler=0x8664488, clamp_vertex_color=1 '\001') at src/gallium/auxiliary/draw/draw_llvm.c:492 #9 0x0116ef0a in draw_llvm_generate (llvm=0x848a6c8, variant=0x8665490, elts=0 '\000') at src/gallium/auxiliary/draw/draw_llvm.c:1348 #10 0x0116c13e in draw_llvm_create_variant (llvm=0x848a6c8, num_inputs=3, key=0xbfa65078) at src/gallium/auxiliary/draw/draw_llvm.c:447 #11 0x01171d71 in llvm_middle_end_prepare (middle=0x8494c50, in_prim=7, opt=3, max_vertices=0x849204c) at src/gallium/auxiliary/draw/draw_pt_fetch_shade_pipeline_llvm.c:174 #12 0x01115ec2 in vsplit_prepare (frontend=0x8492030, in_prim=7, middle=0x8494c50, opt=3) at src/gallium/auxiliary/draw/draw_pt_vsplit.c:175 #13 0x0110bbaf in draw_pt_arrays (draw=0x84333f8, prim=7, start=0, count=4) at src/gallium/auxiliary/draw/draw_pt.c:111 #14 0x0110c746 in draw_vbo (draw=0x84333f8, info=0xbfa65494) at src/gallium/auxiliary/draw/draw_pt.c:501 #15 0x010d7a48 in i915_draw_vbo (pipe=0x84388d0, info=0xbfa65494) at src/gallium/drivers/i915/i915_context.c:88 #16 0x0195b45f in st_draw_vbo (ctx=0x84d1538, arrays=0x852aa00, prims=0xbfa6553c, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3) at src/mesa/state_tracker/st_draw.c:1058 #17 0x019ee5ff in vbo_draw_arrays (ctx=0x84d1538, mode=7, start=0, count=4, numInstances=1) at src/mesa/vbo/vbo_exec_array.c:620 #18 0x019ee757 in vbo_exec_DrawArrays (mode=7, start=0, count=4) at src/mesa/vbo/vbo_exec_array.c:651 #19 0x0809612e in piglit_draw_rect (x=-1, y=-1, w=2, h=2) at piglit/tests/util/piglit-util-gl.c:647 #20 0x0806c960 in display () at piglit/tests/texturing/fragment-and-vertex-texturing.c:147 #21 0x0806c9ab in piglit_display () at piglit/tests/texturing/fragment-and-vertex-texturing.c
RE: [PATCH 5/5] drm/exynos: Add plane support with fimd
Hi, Rob. below is my answer. > -Original Message- > From: Rob Clark [mailto:robdcl...@gmail.com] > Sent: Tuesday, December 13, 2011 9:48 AM > To: Joonyoung Shim > Cc: Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; dri- > de...@lists.freedesktop.org > Subject: Re: [PATCH 5/5] drm/exynos: Add plane support with fimd > > On Mon, Dec 12, 2011 at 6:41 PM, Joonyoung Shim > wrote: > > On 12/13/2011 06:59 AM, Rob Clark wrote: > >> > >> On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote: > >>> > >>> From: Joonyoung Shim > >>> > >>> The exynos fimd supports 5 window overlays. Only one window overlay of > >>> fimd is used by the crtc, so we need plane feature to use the rest > >>> window overlays. > >>> > >>> This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it > >>> is the ioctl to decide for user to assign which window overlay. > >>> > >> btw, I think I will end up with a similar ioctl.. so thought I'd > >> double check for consistency, is zorder interpreted from back to front > >> or front to back? Ie. higher numeric value in front or behind of > >> lower numeric value? Are negative values permitted? > > > > > > The zpos of exynos plane is just the index of overlay of exynos fimd or > > exynos hdmi. 0 zpos means first overlay and 1 zpos means second overlay. > > It isn't the priority value but higher zpos will have higher priority > > generally. > > I'm not sure that I quite understand that.. does that mean zpos=1 will > be in front of zpos=0 (which would be in front of crtc, aka zpos=-1). > Do you have a way to put overlays *behind* crtc layer (which > presumably would be in some mode with an alpha channel?) > > (IIRC, samsung has some public TRM type document.. if this is covered > there, feel free to answer by just pointing me at the section I should > read) > I know that omap, at least omap3(Display Controller of the Display Subsystem), has two modes. one is normal mode and another is alpha mode. and they also have different overlay priority but Samsung exynos has fixed priority to hardware overlays. so higher overlay always is in front of lower overlay. in case of plane module for Samsung SoC, if zpos is -1 then crtc has default overlay designated by machine code. so whether some overlay is in front of crtc or not would be decided by default overlay. Thank you, Inki Dae. > BR, > -R > > > A negative value -1 is defined to special value. A exynos crtc should > > use one overlay and -1 zpos means the overlay that crtc uses. > > > > Thanks. > > > >> BR, > >> -R > >> > >> ___ > >> dri-devel mailing list > >> dri-devel@lists.freedesktop.org > >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > >> > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] drm/exynos: Add plane support with fimd
On Mon, Dec 12, 2011 at 8:39 PM, Inki Dae wrote: > Hi, Rob. > below is my answer. > >> -Original Message- >> From: Rob Clark [mailto:robdcl...@gmail.com] >> Sent: Tuesday, December 13, 2011 9:48 AM >> To: Joonyoung Shim >> Cc: Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; dri- >> de...@lists.freedesktop.org >> Subject: Re: [PATCH 5/5] drm/exynos: Add plane support with fimd >> >> On Mon, Dec 12, 2011 at 6:41 PM, Joonyoung Shim >> wrote: >> > On 12/13/2011 06:59 AM, Rob Clark wrote: >> >> >> >> On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote: >> >>> >> >>> From: Joonyoung Shim >> >>> >> >>> The exynos fimd supports 5 window overlays. Only one window overlay of >> >>> fimd is used by the crtc, so we need plane feature to use the rest >> >>> window overlays. >> >>> >> >>> This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it >> >>> is the ioctl to decide for user to assign which window overlay. >> >>> >> >> btw, I think I will end up with a similar ioctl.. so thought I'd >> >> double check for consistency, is zorder interpreted from back to front >> >> or front to back? Ie. higher numeric value in front or behind of >> >> lower numeric value? Are negative values permitted? >> > >> > >> > The zpos of exynos plane is just the index of overlay of exynos fimd or >> > exynos hdmi. 0 zpos means first overlay and 1 zpos means second overlay. >> > It isn't the priority value but higher zpos will have higher priority >> > generally. >> >> I'm not sure that I quite understand that.. does that mean zpos=1 will >> be in front of zpos=0 (which would be in front of crtc, aka zpos=-1). >> Do you have a way to put overlays *behind* crtc layer (which >> presumably would be in some mode with an alpha channel?) >> >> (IIRC, samsung has some public TRM type document.. if this is covered >> there, feel free to answer by just pointing me at the section I should >> read) >> > > I know that omap, at least omap3(Display Controller of the Display > Subsystem), has two modes. one is normal mode and another is alpha mode. and > they also have different overlay priority but Samsung exynos has fixed > priority to hardware overlays. so higher overlay always is in front of lower > overlay. in case of plane module for Samsung SoC, if zpos is -1 then crtc > has default overlay designated by machine code. so whether some overlay is > in front of crtc or not would be decided by default overlay. ahh, ok.. I was hoping it was as easy as omap4 where we can just set arbitrary z-order (0-4) for any of the layers (crtc or overlay). So maybe not a way to completely abstract this in the same way for userspace (but the case is the same in omap3 where it is either normal or alpha mode.. and I hadn't really decided yet how to handle the difference between omap generations for this sort of API yet). I guess userspace ddx driver (or wayland compositor, etc) would still need to know a bit about what is under the hood.. sigh.. BR, -R > Thank you, > Inki Dae. > > >> BR, >> -R >> >> > A negative value -1 is defined to special value. A exynos crtc should >> > use one overlay and -1 zpos means the overlay that crtc uses. >> > >> > Thanks. >> > >> >> BR, >> >> -R >> >> >> >> ___ >> >> dri-devel mailing list >> >> dri-devel@lists.freedesktop.org >> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> >> > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/i915: By default, enable RC6 on IVB and SNB when reasonable
On Fri, Dec 09, 2011 at 03:53:49PM -0800, Keith Packard wrote: > RC6 should always work on IVB, and should work on SNB whenever IO > remapping is disabled. RC6 never works on Ironlake. Make the default > value for the parameter follow these guidelines. Setting the value > to either 0 or 1 will force the specified behavior. I still don't like this. We're in a situation where we clearly have to disable one feature or the other on SNB - but we're disabling the one that's going to be useful to a large number of people, and leaving the niche feature enabled. If we're going to merge this then let's turn off iommu on SNB by default. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Memory corruption starting in i915 code, in 3.2-rc5
El 11/12/11 16:29, Alex Villacís Lasso escribió: El 11/12/11 15:46, Keith Packard escribió: On Sun, 11 Dec 2011 13:36:30 -0500, Alex Villacís Lasso wrote: My system is a Fedora 16 x86_64 running self-compiled vanilla kernel (.config attached for -rc5). I am getting an apparent memory corruption that starts since linux 3.2-rc5. No such corruption was noticed in 3.2-rc4. On the first instance, I eventually got a NULL pointer dereference and the screen went black, the keyboard was unresponsive, and I had to hard-reboot the machine. On the second instance, I managed to reboot the machine normally. The full message log is attached. An extract of the first WARNING: The only patch in the i915 code between rc4 and rc5 is a tiny VT-d workaround fix for ILK machines, which does fiddle with how the request linked lists are managed. Can you try reverting eb1711bb94991e93669c5a1b5f84f11be2d51ea1 and see if your problem goes away? Recompiled kernel with patch reverted, testing right now. Ran kernel with reverted patch for 6 hours without issues so far. Will keep testing after work (issue happens with my home machine). ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Sat, Dec 10, 2011 at 03:13:06AM -0800, Mauro Carvalho Chehab wrote: > On 09-12-2011 20:50, Robert Morell wrote: > > On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote: > >> On Friday 02 December 2011, Sumit Semwal wrote: > >>> This is the first step in defining a dma buffer sharing mechanism. > >> > > [...] > >> > >>> + return dmabuf; > >>> +} > >>> +EXPORT_SYMBOL(dma_buf_export); > >> > >> I agree with Konrad, this should definitely be EXPORT_SYMBOL_GPL, > >> because it's really a low-level function that I would expect > >> to get used by in-kernel subsystems providing the feature to > >> users and having back-end drivers, but it's not the kind of thing > >> we want out-of-tree drivers to mess with. > > > > Is this really necessary? If this is intended to be a > > lowest-common-denominator between many drivers to allow buffer sharing, > > it seems like it needs to be able to be usable by all drivers. > > > > If the interface is not accessible then I fear many drivers will be > > forced to continue to roll their own buffer sharing mechanisms (which is > > exactly what we're trying to avoid here, needless to say). > > Doing a buffer sharing with something that is not GPL is not fun, as, if any > issue rises there, it would be impossible to discover if the problem is either > at the closed-source driver or at the open source one. At the time I was using > the Nvidia proprietary driver, it was very common to have unexplained issues > caused likely by bad code there at the buffer management code, causing X > applications and extensions (like xv) to break. > > We should really make this EXPORT_SYMBOL_GPL(), in order to be able to latter > debug future share buffer issues, when needed. Sorry, I don't buy this argument. Making these exports GPL-only is not likely to cause anybody to open-source their driver, but will rather just cause them to use yet more closed-source code that is even less debuggable than this would be, to those without access to the source. Thanks, Robert > Regards, > Mauro ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 43655] Latest radeon dri driver on HD6950 with kernel 3.2 flickers
https://bugs.freedesktop.org/show_bug.cgi?id=43655 --- Comment #3 from Alexandre Demers 2011-12-12 01:03:23 PST --- OK, so after testing first all RCs, I narrowed the problem between RC3 and RC4. So, bisecting gave me the following culprit: commit 9b5a4d4f65e260a109eaeea8bbc8062a7c58b55e Merge: cb35999 67589c7 Author: Linus Torvalds Date: Mon Nov 28 13:49:43 2011 -0800 Merge branch 'for-3.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/gi * 'for-3.2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu percpu: explain why per_cpu_ptr_to_phys() is more complicated than necessa percpu: fix chunk range calculation percpu: rename pcpu_mem_alloc to pcpu_mem_zalloc It has nothing to do with drm in itself. But it must be related at some point... I'll reset my tree tomorrow and retest to be sure by compiling just before this commit. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43739] New: Startx fails for Fusion Wrestler 9809
https://bugs.freedesktop.org/show_bug.cgi?id=43739 Bug #: 43739 Summary: Startx fails for Fusion Wrestler 9809 Classification: Unclassified Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: critical Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: hysvats at gmail.com Created attachment 54350 --> https://bugs.freedesktop.org/attachment.cgi?id=54350 xorg.log Driver Stack Details: = 1)Kernel- 3.0.0-12-generice-pae 2)Libdrm-2.4.27 3)Mesa-7.12-devel (git-f1a677c) 4)Xorg-server-1.10.1 5)xf86-video-ati-master System Environment: === Asic/Chipset : Fusion Wrestler 9809 O.S. : Ubuntu-11.10 (32 bit) Processor: AMD E1-1200 @ 777 MHz Memory : 1.6 GB Steps to Reproduce: === Connect the Fusion Wrestler 9809 with vga cable and # startx Observation : 1) startx fails with following message 19.058] (++) using VT number 7 [19.059] (EE) No devices detected. [19.059] Fatal server error: [19.059] no screens found 2) startx works fine with Fusion Wrestler 9807/9804 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43739] Startx fails for Fusion Wrestler 9809
https://bugs.freedesktop.org/show_bug.cgi?id=43739 --- Comment #1 from samit vats 2011-12-12 01:17:20 PST --- Created attachment 54351 --> https://bugs.freedesktop.org/attachment.cgi?id=54351 xorg.conf -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43739] Startx fails for Fusion Wrestler 9809
https://bugs.freedesktop.org/show_bug.cgi?id=43739 --- Comment #2 from samit vats 2011-12-12 01:17:49 PST --- Created attachment 54352 --> https://bugs.freedesktop.org/attachment.cgi?id=54352 dmesg.txt -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43739] Startx fails for Fusion Wrestler 9809
https://bugs.freedesktop.org/show_bug.cgi?id=43739 --- Comment #3 from samit vats 2011-12-12 01:18:15 PST --- Created attachment 54353 --> https://bugs.freedesktop.org/attachment.cgi?id=54353 lspci -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 43739] Startx fails for Fusion Wrestler 9809
https://bugs.freedesktop.org/show_bug.cgi?id=43739 samit vats changed: What|Removed |Added Priority|medium |high -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon/kms: add some new pci ids
From: Alex Deucher
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=43739
Signed-off-by: Alex Deucher
Cc: stable at kernel.org
---
include/drm/drm_pciids.h | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index 4e4fbb8..14b6cd0 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -182,8 +182,11 @@
{0x1002, 0x6748, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6749, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6750, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x6751, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6758, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6759, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x675B, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x675D, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x675F, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6760, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6761, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
@@ -195,8 +198,10 @@
{0x1002, 0x6767, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6768, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6770, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x6772, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6778, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6779, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x677B, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CAICOS|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6840, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6841, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6842, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_TURKS|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
@@ -246,6 +251,7 @@
{0x1002, 0x68f2, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
{0x1002, 0x68f8, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
{0x1002, 0x68f9, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
+ {0x1002, 0x68fa, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
{0x1002, 0x68fe, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_CEDAR|RADEON_NEW_MEMMAP}, \
{0x1002, 0x7100, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R520|RADEON_NEW_MEMMAP}, \
{0x1002, 0x7101, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_R520|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
@@ -488,6 +494,8 @@
{0x1002, 0x9647, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_SUMO|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP},\
{0x1002, 0x9648, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_SUMO|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP},\
{0x1002, 0x964a, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_SUMO|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x964b, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_SUMO|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x964c, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_SUMO|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x964e, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_SUMO|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP},\
{0x1002, 0x964f, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_SUMO|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP|RADEON_IS_IGP},\
{0x1002, 0x9710, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_RS880|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
@@ -502,6 +510,8 @@
{0x1002, 0x9805, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_PALM|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9806, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_PALM|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0x1002, 0x9807, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_PALM|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x9808, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_PALM|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
+ {0x1002, 0x9809, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_PALM|RADEON_NEW_MEMMAP|RADEON_IS_IGP}, \
{0, 0, 0}
#define r128_PCI_IDS \
--
1.7.3.4
[Bug 43739] Startx fails for Fusion Wrestler 9809
https://bugs.freedesktop.org/show_bug.cgi?id=43739 --- Comment #4 from Alex Deucher 2011-12-12 06:50:42 PST --- You'll need the following patches: Mesa: http://cgit.freedesktop.org/mesa/mesa/commit/?id=23895cc006f3dbf96a502ddd15e291e071aff25a xf86-video-ati: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=aacbd629b02cbee3f9e6a0ee452b4e3f21376bd3 kernel: http://lists.freedesktop.org/archives/dri-devel/2011-December/017339.html -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
ttm dma allocator issue ?
On Fri, Dec 09, 2011 at 09:25:43PM -0500, Jerome Glisse wrote:
> Hi Konrad i stumble on this after a long period of test :
>
> Dec 9 12:00:37 homer kernel: [ cut here ]
> Dec 9 12:00:37 homer kernel: WARNING: at lib/dma-debug.c:894
> check_unmap+0x262/0x7e0()
> Dec 9 12:00:37 homer kernel: Hardware name: GA-A75M-UD2H
> Dec 9 12:00:37 homer kernel: radeon :01:00.0: DMA-API: device
> driver frees DMA memory with different CPU address [device
> address=0x0002093f3000]
>[size=4096 bytes]
>[cpu alloc
> address=0x000213bf2000]
>[cpu free
> address=0x0002093f3000]
> Dec 9 12:00:37 homer kernel: Modules linked in: radeon ttm
> drm_kms_helper drm ip6t_REJECT ipt_REJECT nf_conntrack_ipv6
> nf_conntrack_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 xt_state nf_conntrack
> ip6table_filter iptable_filter ip6_tables ip_tables dm_mirror
> dm_region_hash dm_log dm_mod snd_hda_codec_hdmi snd_hda_codec_realtek
> snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device r8169
> snd_pcm microcode serio_raw xhci_hcd mii hwmon i2c_piix4 i2c_algo_bit
> snd_timer snd soundcore snd_page_alloc ipv6 ext4 mbcache jbd2
> ata_generic pata_atiixp [last unloaded: drm]
> Dec 9 12:00:37 homer kernel: Pid: 1158, comm: Heaven_x64 Not tainted
> 3.2.0-rc4+ #72
> Dec 9 12:00:37 homer kernel: Call Trace:
> Dec 9 12:00:37 homer kernel: []
> warn_slowpath_common+0x7f/0xc0
> Dec 9 12:00:37 homer kernel: [] warn_slowpath_fmt+0x46/0x50
> Dec 9 12:00:37 homer kernel: [] check_unmap+0x262/0x7e0
> Dec 9 12:00:37 homer kernel: []
> ?vm_unmap_aliases+0x77/0x1d0
> Dec 9 12:00:37 homer kernel: []
> debug_dma_free_coherent+0x6d/0x80
> Dec 9 12:00:37 homer kernel: []
> ?__request_resource+0x60/0x60
> Dec 9 12:00:37 homer kernel: []
> __ttm_dma_free_page+0x67/0xd0 [ttm]
> Dec 9 12:00:37 homer kernel: []
> ttm_dma_unpopulate+0x2c5/0x340 [ttm]
> Dec 9 12:00:37 homer kernel: []
> radeon_ttm_tt_unpopulate+0xdf/0xf0 [radeon]
.. snip..
> Dec 9 12:00:37 homer kernel: Mapped at:
> Dec 9 12:00:37 homer kernel: []
> debug_dma_alloc_coherent+0x3b/0x90
> Dec 9 12:00:37 homer kernel: []
> ttm_dma_populate+0x340/0xa30 [ttm]
> Dec 9 12:00:37 homer kernel: []
> radeon_ttm_tt_populate+0x19f/0x280 [radeon]
> Dec 9 12:00:37 homer kernel: [] ttm_tt_bind+0x3e/0x70 [ttm]
> Dec 9 12:00:37 homer kernel: []
> ttm_bo_handle_move_mem+0x36f/0x3e0 [ttm]
> Dec 9 12:01:29 homer kernel: DMA-API: debugging out of memory - disabling
> Dec 9 19:16:54 homer kernel: [drm:radeon_dvi_detect] *ERROR* DVI-I-1:
> probed a monitor but no|invalid EDID
>
> Nothing else in the log. Quite frankly i dont this how this can happen.
> Any ideas ?
The only way to do that would be to modify the 'struct dma_page' vaddr and dma
variables from what they had in __ttm_dma_alloc_page. But I am not seeing any
willfull modifications. We do pass in to dma_free_coherent the _same_ values!
Hm, it might be worth adding in the 'struct dma_page' a 'virt_to_phys' value
(which is what the DMA debug API uses to check), and see we get inconsitent
values _before_ we call the DMA debug API. This is rather to double check
the DMA API debug API. I am going to try something like this (not compile
tested at all):
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 6678abc..2dd7d6c 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -127,6 +127,7 @@ struct dma_page {
void *vaddr;
struct page *p;
dma_addr_t dma;
+ void *phys; /* Based on virt_to_phys so not really bus addr */
};
/*
@@ -330,6 +331,11 @@ static int ttm_set_pages_caching(struct dma_pool *pool,
static void __ttm_dma_free_page(struct dma_pool *pool, struct dma_page *d_page)
{
dma_addr_t dma = d_page->dma;
+
+ WARN_ON(virt_to_phys(d_page->vaddr) != d_page->virt,
+ "WTF: saved 0x%lx, but now we get 0x%lx!\n",
+ d_page->virt, virt_to_phys(d_page->vaddr));
+
dma_free_coherent(pool->dev, pool->size, d_page->vaddr, dma);
kfree(d_page);
@@ -348,6 +354,7 @@ static struct dma_page *__ttm_dma_alloc_page(struct
dma_pool *pool)
pool->gfp_flags);
if (d_page->vaddr)
d_page->p = virt_to_page(d_page->vaddr);
+ d_page->virt = virt_to_phys(d_page->vaddr);
else {
kfree(d_page);
d_page = NULL;
Memory corruption starting in i915 code, in 3.2-rc5
On Mon, 12 Dec 2011 09:51:19 -0500, Alex Villac??s Lasso wrote: > Ran kernel with reverted patch for 6 hours without issues so far. Will > keep testing after work (issue happens with my home machine). Thanks much. Let me know if it's still stable this evening; I can send a revert along if you don't find any problems. -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20111212/a20f7b67/attachment.pgp>
[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Saturday 10 December 2011, Daniel Vetter wrote: > If userspace (through some driver calls) > tries to do stupid things, it'll just get garbage. See > Message-ID: mail.gmail.com> > for my reasons why it think this is the right way to go forward. So in > essence I'm really interested in the reasons why you want the kernel > to enforce this (or I'm completely missing what's the contentious > issue here). This has nothing to do with user space mappings. Whatever user space does, you get garbage if you don't invalidate cache lines that were introduced through speculative prefetching before you access cache lines that were DMA'd from a device. Arnd
ttm dma allocator issue ?
> > Any ideas ?
>
> The only way to do that would be to modify the 'struct dma_page' vaddr and dma
> variables from what they had in __ttm_dma_alloc_page. But I am not seeing any
> willfull modifications. We do pass in to dma_free_coherent the _same_ values!
>
>
> Hm, it might be worth adding in the 'struct dma_page' a 'virt_to_phys' value
> (which is what the DMA debug API uses to check), and see we get inconsitent
> values _before_ we call the DMA debug API. This is rather to double check
> the DMA API debug API. I am going to try something like this (not compile
> tested at all):
This one is compile tested :-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 6678abc..659b0ee 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -32,7 +32,7 @@
* - Tracks whether the page is UC, WB or cached (and reverts to WB
* when freed).
*/
-
+#define DEBUG 1
#include
#include
#include /* for seq_printf */
@@ -127,6 +127,7 @@ struct dma_page {
void *vaddr;
struct page *p;
dma_addr_t dma;
+ void *phys; /* Based on virt_to_phys so not really bus addr */
};
/*
@@ -330,6 +331,11 @@ static int ttm_set_pages_caching(struct dma_pool *pool,
static void __ttm_dma_free_page(struct dma_pool *pool, struct dma_page *d_page)
{
dma_addr_t dma = d_page->dma;
+
+ WARN(virt_to_phys(d_page->vaddr) != d_page->phys,
+ "We saved 0x%lx, but now we get 0x%lx!?\n",
+ (unsigned long)d_page->phys, (unsigned
long)virt_to_phys(d_page->vaddr));
+
dma_free_coherent(pool->dev, pool->size, d_page->vaddr, dma);
kfree(d_page);
@@ -346,8 +352,10 @@ static struct dma_page *__ttm_dma_alloc_page(struct
dma_pool *pool)
d_page->vaddr = dma_alloc_coherent(pool->dev, pool->size,
&d_page->dma,
pool->gfp_flags);
- if (d_page->vaddr)
+ if (d_page->vaddr) {
d_page->p = virt_to_page(d_page->vaddr);
+ d_page->phys = virt_to_phys(d_page->vaddr);
+ }
else {
kfree(d_page);
d_page = NULL;
[PATCH] fixes to drm-next - TTM DMA code (v1)
Jerome pointed me to some accounting error in the DMA API debugging code and while I can't figure it out yet, I did notice some extreme slowness - which is due to the nouveau driver calling the unpopulate (now that unbind + unpopulate are squashed) quite a lot (this is using Gnome Shell - I think GNOME2 did not have those issues but I can't recall). Anyhow these patches fix the 50% perf regression I saw and also some minor bugs that I noticed.
[PATCH 1/3] drm/ttm/dma: Only call set_pages_array_wb when the page is not in WB pool.
Otherwise we are doing redundant work. Especially since the 'unbind' and 'unpopulate' have been merged and nouveau driver ends up calling it quite excessivly. On a GeForce 8600 GT with Gnome Shell (GNOME 3) we end up spending about 54% CPU time in __change_page_attr_set_clr checking the page flags when I move the mouse cursor all over the screen. The callgraph (annotated) looks as so before this patch: 53.29% gnome-shell [kernel.kallsyms] [k] static_protections | --- static_protections | |--91.80%-- __change_page_attr_set_clr | change_page_attr_set_clr | set_pages_array_wb | | | |--96.55%-- ttm_dma_unpopulate | | nouveau_ttm_tt_unpopulate | | ttm_tt_destroy | | ttm_bo_cleanup_memtype_use | | ttm_bo_release | | kref_put | | ttm_bo_unref | | nouveau_gem_object_del | | drm_gem_object_free | | kref_put | | drm_gem_object_unreference_unlocked | | drm_gem_object_handle_unreference_unlocked.part.1 | | drm_gem_handle_delete | | drm_gem_close_ioctl | | drm_ioctl | | do_vfs_ioctl | | sys_ioctl | | system_call_fastpath | | __GI___ioctl | | | --3.45%-- ttm_dma_pages_put | ttm_dma_page_pool_free | ttm_dma_unpopulate | nouveau_ttm_tt_unpopulate | ttm_tt_destroy | ttm_bo_cleanup_memtype_use | ttm_bo_release | kref_put | ttm_bo_unref | nouveau_gem_object_del | drm_gem_object_free | kref_put | drm_gem_object_unreference_unlocked | drm_gem_object_handle_unreference_unlocked.part.1 | drm_gem_handle_delete | drm_gem_close_ioctl | drm_ioctl | do_vfs_ioctl | sys_ioctl | system_call_fastpath | __GI___ioctl | --8.20%-- change_page_attr_set_clr set_pages_array_wb | |--93.76%-- ttm_dma_unpopulate | nouveau_ttm_tt_unpopulate | ttm_tt_destroy | ttm_bo_cleanup_memtype_use | ttm_bo_release | kref_put | ttm_bo_unref | nouveau_gem_object_del | drm_gem_object_free | kref_put | drm_gem_object_unreference_unlocked | drm_gem_object_handle_unreference_unlocked.part.1 | drm_gem_handle_delete | drm_gem_close_ioctl | drm_ioctl | do_vfs_ioctl | sys_ioctl | system_call_fastpath | __GI___ioctl | --6.24%-- ttm_dma_pages_put ttm_dma_page_pool_free ttm_dma_unpopulate nouveau_ttm_tt_unpopulate ttm_tt_destroy ttm_bo_cleanup_memtype_use ttm_bo_release kref_put ttm_bo_unref nouveau_gem_object_del drm_gem_object_free kref_put drm_gem_object_unreferenc
[PATCH 3/3] drm/ttm/dma: Optimize when free-ing the recycled page pool.
We would free the page pool - even if it was for cached pages
(which are deleted from the pool - so there are no free pages).
Also we also missed the opportunity to batch the amount of pages
to free (similar to how ttm_page_alloc.c does it). This reintroduces
the code that was lost during rebasing.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index e57aa24..156ddcd 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -949,7 +949,7 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
struct dma_page *d_page, *next;
enum pool_type type;
bool is_cached = false;
- unsigned count = 0, i, npages;
+ unsigned count = 0, i, npages = 0;
unsigned long irq_flags;
type = ttm_to_type(ttm->page_flags, ttm->caching_state);
@@ -971,13 +971,16 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma,
struct device *dev)
pool->npages_in_use -= count;
if (is_cached) {
pool->nfrees += count;
- npages = count;
} else {
pool->npages_free += count;
list_splice(&ttm_dma->pages_list, &pool->free_list);
npages = count;
if (pool->npages_free > _manager->options.max_size) {
npages = pool->npages_free - _manager->options.max_size;
+ /* free at least NUM_PAGES_TO_ALLOC number of pages
+* to reduce calls to set_memory_wb */
+ if (npages < NUM_PAGES_TO_ALLOC)
+ npages = NUM_PAGES_TO_ALLOC;
}
}
spin_unlock_irqrestore(&pool->lock, irq_flags);
@@ -1001,7 +1004,7 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma,
struct device *dev)
ttm_dma->dma_address[i] = 0;
}
- /* shrink pool if necessary */
+ /* shrink pool if necessary (only on !is_cached pools)*/
if (npages)
ttm_dma_page_pool_free(pool, npages);
ttm->state = tt_unpopulated;
--
1.7.7.3
[PATCH 2/3] drm/ttm/dma: Fix accounting error when calling ttm_mem_global_free_page.
The code to figure out how many pages to shrink the pool
ends up capping the 'count' at _manager->options.max_size - which is OK.
Except that the 'count' is also used when accounting for how many pages
are recycled - which we end up with the invalid values. This fixes
it by using a different value for the amount of pages to shrink.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 6c06d0b..e57aa24 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -949,7 +949,7 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma, struct
device *dev)
struct dma_page *d_page, *next;
enum pool_type type;
bool is_cached = false;
- unsigned count = 0, i;
+ unsigned count = 0, i, npages;
unsigned long irq_flags;
type = ttm_to_type(ttm->page_flags, ttm->caching_state);
@@ -971,11 +971,13 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma,
struct device *dev)
pool->npages_in_use -= count;
if (is_cached) {
pool->nfrees += count;
+ npages = count;
} else {
pool->npages_free += count;
list_splice(&ttm_dma->pages_list, &pool->free_list);
+ npages = count;
if (pool->npages_free > _manager->options.max_size) {
- count = pool->npages_free - _manager->options.max_size;
+ npages = pool->npages_free - _manager->options.max_size;
}
}
spin_unlock_irqrestore(&pool->lock, irq_flags);
@@ -1000,8 +1002,8 @@ void ttm_dma_unpopulate(struct ttm_dma_tt *ttm_dma,
struct device *dev)
}
/* shrink pool if necessary */
- if (count)
- ttm_dma_page_pool_free(pool, count);
+ if (npages)
+ ttm_dma_page_pool_free(pool, npages);
ttm->state = tt_unpopulated;
}
EXPORT_SYMBOL_GPL(ttm_dma_unpopulate);
--
1.7.7.3
crash with "drm/ttm: callback move_notify any time bo placement change v4" patch
Hey, When I use the drm-next tree without the patch it works fine. (albeit slowly - but I posted the patches for that). With the patch mentioned I get this: 00:0d.0 VGA compatible controller: nVidia Corporation C61 [GeForce 6150SE nForce 430] (rev a2) sh-4.1# cd :00:0d.0 sh-4.1# cd driver sh-4.1# echo ":00:0d.0" > unbind [ 144.585574] BUG: unable to handle kernel NULL pointer dereference at (null) [ 144.585588] IP: [] nouveau_bo_move_ntfy+0x25/0xb0 [nouveau] [ 144.585605] PGD 30b5a067 PUD 30af1067 PMD 0 [ 144.585612] Oops: [#1] PREEMPT SMP [ 144.585619] CPU 0 [ 144.585622] Modules linked in: dm_multipath dm_mod xen_evtchn iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi libcrc32c crc32c radeon sg sd_mod fbcon tileblit nouveau font bitblit softcursor ttm drm_kms_helper mxm_wmi wmi video sata_nv ata_generic libata skge e1000 scsi_mod xen_blkfront xen_netfront fb_sys_fops sysimgblt sysfillrect syscopyarea xenfs [last unloaded: dump_dma] [ 144.585705] [ 144.585709] Pid: 3223, comm: sh Tainted: G O 3.2.0-rc5-00169-g82d722f #2 BIOSTAR Group N61PB-M2S/N61PB-M2S [ 144.585718] RIP: e030:[] [] nouveau_bo_move_ntfy+0x25/0xb0 [nouveau] [ 144.585730] RSP: e02b:880030a69bf8 EFLAGS: 00010292 [ 144.585733] RAX: a012a7e0 RBX: 88002dacca10 RCX: 88000ef80498 [ 144.585737] RDX: 88000ef80498 RSI: RDI: 88002dacc800 [ 144.585741] RBP: 880030a69c28 R08: R09: 88000f228d38 [ 144.585745] R10: 0001 R11: R12: [ 144.585749] R13: 88002dacca10 R14: 88002dacc800 R15: 88000f228d38 [ 144.585757] FS: 7fcdfa067700() GS:88003fe5b000() knlGS: [ 144.585761] CS: e033 DS: ES: CR0: 8005003b [ 144.585765] CR2: CR3: 30bc6000 CR4: 0660 [ 144.585769] DR0: DR1: DR2: [ 144.585774] DR3: DR6: 0ff0 DR7: 0400 [ 144.585778] Process sh (pid: 3223, threadinfo 880030a68000, task 88003a3809f0) [ 144.585782] Stack: [ 144.585784] 880030a69c18 88002dacc800 0001 88000ef80728 [ 144.585793] 88000ef80320 88000f228d38 880030a69c48 a00f4aa1 [ 144.585802] 880030a69c48 88002dacc800 880030a69cb8 a00f7ad9 [ 144.585810] Call Trace: [ 144.585818] [] ttm_bo_cleanup_memtype_use+0x21/0x80 [ttm] [ 144.585825] [] ttm_bo_release+0x249/0x270 [ttm] [ 144.585833] [] ? get_parent_ip+0x11/0x50 [ 144.585839] [] ? ttm_bo_create+0x110/0x110 [ttm] [ 144.585846] [] kref_put+0x37/0x70 [ 144.585852] [] ttm_bo_unref+0x3d/0x50 [ttm] [ 144.585859] [] ? drm_gem_object_handle_free+0x90/0x90 [ 144.585868] [] nouveau_gem_object_del+0x3a/0x70 [nouveau] [ 144.585874] [] drm_gem_object_free+0x25/0x40 [ 144.585879] [] kref_put+0x37/0x70 [ 144.585890] [] nouveau_fbcon_fini+0xb1/0x130 [nouveau] [ 144.585899] [] nouveau_unload+0x1b5/0x220 [nouveau] [ 144.585904] [] ? drm_lastclose+0x2b2/0x300 [ 144.585910] [] drm_put_dev+0x6e/0x240 [ 144.585918] [] nouveau_pci_remove+0x18/0x20 [nouveau] [ 144.585924] [] pci_device_remove+0x32/0x60 [ 144.585930] [] __device_release_driver+0x61/0xc0 [ 144.585935] [] device_release_driver+0x28/0x40 [ 144.585940] [] driver_unbind+0x99/0xb0 [ 144.585945] [] drv_attr_store+0x27/0x30 [ 144.585951] [] sysfs_write_file+0xdd/0x160 [ 144.585957] [] vfs_write+0xc8/0x190 [ 144.585962] [] sys_write+0x4c/0x90 [ 144.585968] [] system_call_fastpath+0x16/0x1b [ 144.585972] Code: 84 00 00 00 00 00 55 48 89 e5 41 57 41 56 49 89 fe 41 55 4c 8d af 10 02 00 00 41 54 49 89 f4 53 48 83 ec 08 48 8b 9f 10 02 00 00 <4c> 8b 3e 4c 39 eb 75 13 eb 61 90 48 89 df e8 78 75 02 00 48 8b [ 144.586053] RIP [] nouveau_bo_move_ntfy+0x25/0xb0 [nouveau] [ 144.586059] RSP [ 144.586059] CR2: [ 144.586059] ---[ end trace 520b019831a63add ]--- Dec 12 16:49:49 tst004 init: process '/bin/sh' (pid 3223) exited. Scheduling for restart. Dec 12 16:49:49 tst004 init: starting pid 3331, tty '/dev/hvc0': '/bin/sh' sh-4.1#
ttm dma allocator issue ?
On Mon, Dec 12, 2011 at 12:37:43PM -0500, Konrad Rzeszutek Wilk wrote: > > > Any ideas ? > > > > The only way to do that would be to modify the 'struct dma_page' vaddr and > > dma > > variables from what they had in __ttm_dma_alloc_page. But I am not seeing > > any > > willfull modifications. We do pass in to dma_free_coherent the _same_ > > values! > > > > > > Hm, it might be worth adding in the 'struct dma_page' a 'virt_to_phys' value > > (which is what the DMA debug API uses to check), and see we get inconsitent > > values _before_ we call the DMA debug API. This is rather to double check > > the DMA API debug API. I am going to try something like this (not compile > > tested at all): > > This one is compile tested :-) > > diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c > b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c > index 6678abc..659b0ee 100644 > --- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c > +++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c > @@ -32,7 +32,7 @@ > * - Tracks whether the page is UC, WB or cached (and reverts to WB > * when freed). > */ > - And I think if you cherry-pick git commit 91ec37cc1015220965e39bf342fb846810d19e79 Author: Thomas Jarosch Date: Thu Nov 17 20:31:02 2011 +0100 Fix comparison using wrong pointer variable in dma debug code which fixes the DMA debug API code, the error you are getting will go away.
[PATCH 5/5] drm/exynos: Add plane support with fimd
On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote: > From: Joonyoung Shim > > The exynos fimd supports 5 window overlays. Only one window overlay of > fimd is used by the crtc, so we need plane feature to use the rest > window overlays. > > This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it > is the ioctl to decide for user to assign which window overlay. > btw, I think I will end up with a similar ioctl.. so thought I'd double check for consistency, is zorder interpreted from back to front or front to back? Ie. higher numeric value in front or behind of lower numeric value? Are negative values permitted? BR, -R
[PATCH 5/5] drm/exynos: Add plane support with fimd
On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae wrote:
> +static int
> +exynos_update_plane(struct drm_plane *plane, struct drm_crtc *crtc,
> + ? ? ? ? ? ? ? ? ? ?struct drm_framebuffer *fb, int crtc_x, int crtc_y,
> + ? ? ? ? ? ? ? ? ? ?unsigned int crtc_w, unsigned int crtc_h,
> + ? ? ? ? ? ? ? ? ? ?uint32_t src_x, uint32_t src_y,
> + ? ? ? ? ? ? ? ? ? ?uint32_t src_w, uint32_t src_h)
> +{
> + ? ? ? struct exynos_plane *exynos_plane =
> + ? ? ? ? ? ? ? container_of(plane, struct exynos_plane, base);
> + ? ? ? struct exynos_drm_overlay *overlay = &exynos_plane->overlay;
> + ? ? ? struct exynos_drm_crtc_pos pos;
> + ? ? ? int ret;
> +
> + ? ? ? DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
> +
> + ? ? ? memset(&pos, 0, sizeof(struct exynos_drm_crtc_pos));
> + ? ? ? pos.crtc_x = crtc_x;
> + ? ? ? pos.crtc_y = crtc_y;
> + ? ? ? pos.crtc_w = crtc_w;
> + ? ? ? pos.crtc_h = crtc_h;
> +
> + ? ? ? pos.fb_x = src_x;
> + ? ? ? pos.fb_y = src_y;
also, I think src_x/src_y should be interpreted at 16.16/Q16 fixed
point. But elsewhere were I see fb_x/y used it, it doesn't appear to
be interpreted this way.
Also, I *think* that comment was meant to apply to src_h/src_w
(Jesse?), but you seem to ignore these parameters..
BR,
-R
> +
> + ? ? ? /* TODO: scale feature */
> + ? ? ? ret = exynos_drm_overlay_update(overlay, fb, &crtc->mode, &pos);
> + ? ? ? if (ret < 0)
> + ? ? ? ? ? ? ? return ret;
> +
> + ? ? ? exynos_drm_fn_encoder(crtc, overlay,
> + ? ? ? ? ? ? ? ? ? ? ? exynos_drm_encoder_crtc_mode_set);
> + ? ? ? exynos_drm_fn_encoder(crtc, &overlay->zpos,
> + ? ? ? ? ? ? ? ? ? ? ? exynos_drm_encoder_crtc_plane_commit);
> +
> + ? ? ? exynos_plane->enabled = true;
> +
> + ? ? ? return 0;
> +}
> +
[PATCH 08/23] drm/via: use drm_mm instead of drm_sman
On Wed, Dec 07, 2011 at 04:28:45PM +, James Simmons wrote: > > > Chris Wilson rightly complained that this doesn't explain the list_del > > magic going on. New commit msg reads: > > > > To make the transition in a piece-wise and bisectable way possible, > > I've hijacked the ->owner_list from drm_sman. While transitioning, the > > list_add was done by the driver, while the list_del was still done by > > the dying sman code. > > > > Now that we are in full control of ->owner_list, do the list_del > > ourselves. > > > > He also noted the superflous additions of INIT_LIST_HEAD and the stale > > comment about spinlock locking in the idr allocation (protected by > > dev->struct_mutex) that I've copied over. All fixed up and pushed out for > > the moment to my fdo repo: > > > > http://cgit.freedesktop.org/~danvet/drm/log/?h=kill-with-fire > > Speaking of I attempted to clone that repo but it gives me > > warning: remote HEAD refers to nonexistent ref, unable to checkout. It's a headless git repo, so you have to check out a specific branch explicitly. Simplest way to do so is with git fetch in an exisiting lk git checkout which should grab that branch into FETCH_HEAD. Then you can check it out, merge it, ... -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH] staging: drm/omap: fix for connectors not enabled at bootup
On Sun, Dec 11, 2011 at 03:13:17PM -0600, Rob Clark wrote: > From: Rob Clark > > The connector's dpms fxn is only triggered by userspace. When the > driver is loaded and detected displays configured, drm core only > calls the crtc and encoder's dpms functions. > > Signed-off-by: Rob Clark > --- > Arguably, this could be called a work-around, and instead drm core > should call connector's dpms functions and rely on > drm_helper_connector_dpms to call encoder and crtc dpms functions. > If people think it is better to fix this in drm core, and don't > mind me making that change, then I will do that instead. Sounds like you should do that in the drm core itself, so I'll not queue up this patch for now. thanks, greg k-h
[PATCH 5/5] drm/exynos: Add plane support with fimd
On Mon, Dec 12, 2011 at 6:41 PM, Joonyoung Shim wrote: > On 12/13/2011 06:59 AM, Rob Clark wrote: >> >> On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae ?wrote: >>> >>> From: Joonyoung Shim >>> >>> The exynos fimd supports 5 window overlays. Only one window overlay of >>> fimd is used by the crtc, so we need plane feature to use the rest >>> window overlays. >>> >>> This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it >>> is the ioctl to decide for user to assign which window overlay. >>> >> btw, I think I will end up with a similar ioctl.. so thought I'd >> double check for consistency, is zorder interpreted from back to front >> or front to back? ?Ie. higher numeric value in front or behind of >> lower numeric value? ?Are negative values permitted? > > > The zpos of exynos plane is just the index of overlay of exynos fimd or > exynos hdmi. 0 zpos means first overlay and 1 zpos means second overlay. > It isn't the priority value but higher zpos will have higher priority > generally. I'm not sure that I quite understand that.. does that mean zpos=1 will be in front of zpos=0 (which would be in front of crtc, aka zpos=-1). Do you have a way to put overlays *behind* crtc layer (which presumably would be in some mode with an alpha channel?) (IIRC, samsung has some public TRM type document.. if this is covered there, feel free to answer by just pointing me at the section I should read) BR, -R > A negative value -1 is defined to special value. A exynos crtc should > use one overlay and -1 zpos means the overlay that crtc uses. > > Thanks. > >> BR, >> -R >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >
[PATCH 0/2] updates for drm API changes in drm-next
From: Rob Clark These two patches cover API changes that are currently in drm-next for 3.3. The 2nd of which is the first part for enabling drm_plane support (but doesn't yet enable the new overlay functionality). I'll have another patchset, hopefully later this week, which adds the remaining bits to enable overlay (drm_plane) support. Greg I'm not sure if you want these patches now, or just after the 3.3 merge window opens. Also, if it is easier for you, I can setup a tree that you could pull from. Please let me know what you prefer. Rob Clark (2): drm/omap: drm API update: make fops struct const drm/omap: drm API update: addfb2 drivers/staging/omapdrm/omap_drv.c | 24 + drivers/staging/omapdrm/omap_drv.h | 53 ++- drivers/staging/omapdrm/omap_fb.c| 96 ++--- drivers/staging/omapdrm/omap_fbdev.c | 29 ++ 4 files changed, 156 insertions(+), 46 deletions(-) -- 1.7.5.4
[PATCH 1/2] drm/omap: drm API update: make fops struct const
From: Rob Clark
Update to reflect changes in:
"Make the per-driver file_operations struct const"
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_drv.c | 24 +---
1 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c
b/drivers/staging/omapdrm/omap_drv.c
index 7ecf578..d05e2b4 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -708,6 +708,18 @@ static struct vm_operations_struct omap_gem_vm_ops = {
.close = drm_gem_vm_close,
};
+static const struct file_operations omapdriver_fops = {
+ .owner = THIS_MODULE,
+ .open = drm_open,
+ .unlocked_ioctl = drm_ioctl,
+ .release = drm_release,
+ .mmap = omap_gem_mmap,
+ .poll = drm_poll,
+ .fasync = drm_fasync,
+ .read = drm_read,
+ .llseek = noop_llseek,
+};
+
static struct drm_driver omap_drm_driver = {
.driver_features =
DRIVER_HAVE_IRQ | DRIVER_MODESET | DRIVER_GEM,
@@ -734,17 +746,7 @@ static struct drm_driver omap_drm_driver = {
.dumb_destroy = omap_gem_dumb_destroy,
.ioctls = ioctls,
.num_ioctls = DRM_OMAP_NUM_IOCTLS,
- .fops = {
- .owner = THIS_MODULE,
- .open = drm_open,
- .unlocked_ioctl = drm_ioctl,
- .release = drm_release,
- .mmap = omap_gem_mmap,
- .poll = drm_poll,
- .fasync = drm_fasync,
- .read = drm_read,
- .llseek = noop_llseek,
- },
+ .fops = &omapdriver_fops,
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
.date = DRIVER_DATE,
--
1.7.5.4
[PATCH 2/2] drm/omap: drm API update: addfb2
From: Rob Clark
Update to reflect changes in:
"drm: add an fb creation ioctl that takes a pixel format v5"
Signed-off-by: Rob Clark
---
drivers/staging/omapdrm/omap_drv.h | 53 ++-
drivers/staging/omapdrm/omap_fb.c| 96 ++---
drivers/staging/omapdrm/omap_fbdev.c | 29 ++
3 files changed, 143 insertions(+), 35 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.h
b/drivers/staging/omapdrm/omap_drv.h
index 8dd7d74..bc8daa7 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -76,9 +76,9 @@ void omap_connector_flush(struct drm_connector *connector,
void omap_connector_dpms(struct drm_connector *connector, int mode);
struct drm_framebuffer *omap_framebuffer_create(struct drm_device *dev,
- struct drm_file *file, struct drm_mode_fb_cmd *mode_cmd);
+ struct drm_file *file, struct drm_mode_fb_cmd2 *mode_cmd);
struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
- struct drm_mode_fb_cmd *mode_cmd, struct drm_gem_object *bo);
+ struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);
struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb);
int omap_framebuffer_get_buffer(struct drm_framebuffer *fb, int x, int y,
void **vaddr, dma_addr_t *paddr, unsigned int *screen_width);
@@ -128,4 +128,53 @@ static inline int align_pitch(int pitch, int width, int
bpp)
return ALIGN(pitch, 8 * bytespp);
}
+/* should these be made into common util helpers?
+ */
+
+static inline int num_planes(uint32_t pixel_format)
+{
+ switch (pixel_format) {
+ default:
+ return 1;
+ case DRM_FORMAT_NV12:
+ case DRM_FORMAT_NV21:
+ case DRM_FORMAT_NV16:
+ case DRM_FORMAT_NV61:
+ return 2;
+ case DRM_FORMAT_YUV410:
+ case DRM_FORMAT_YVU410:
+ case DRM_FORMAT_YUV411:
+ case DRM_FORMAT_YVU411:
+ case DRM_FORMAT_YUV420:
+ case DRM_FORMAT_YVU420:
+ case DRM_FORMAT_YUV422:
+ case DRM_FORMAT_YVU422:
+ case DRM_FORMAT_YUV444:
+ case DRM_FORMAT_YVU444:
+ return 3;
+ }
+}
+
+static inline int objects_lookup(struct drm_device *dev,
+ struct drm_file *filp, uint32_t pixel_format,
+ struct drm_gem_object **bos, uint32_t *handles)
+{
+ int i, n = num_planes(pixel_format);
+
+ for (i = 0; i < n; i++) {
+ bos[i] = drm_gem_object_lookup(dev, filp, handles[i]);
+ if (!bos[i]) {
+ goto fail;
+ }
+ }
+
+ return 0;
+
+fail:
+ while (--i > 0) {
+ drm_gem_object_unreference_unlocked(bos[i]);
+ }
+ return -ENOENT;
+}
+
#endif /* __OMAP_DRV_H__ */
diff --git a/drivers/staging/omapdrm/omap_fb.c
b/drivers/staging/omapdrm/omap_fb.c
index 0b50c5b..b28fee3 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -22,11 +22,41 @@
#include "drm_crtc.h"
#include "drm_crtc_helper.h"
-
/*
* framebuffer funcs
*/
+struct format {
+ enum omap_color_mode dss_format;
+ uint32_t pixel_format;
+ int stride_bpp; /* this times width is stride */
+ bool yuv;
+};
+
+static struct format formats[] = {
+ /* 16bpp [A]RGB: */
+ { OMAP_DSS_COLOR_RGB16, DRM_FORMAT_RGB565, 2, false }, /*
RGB16-565 */
+ { OMAP_DSS_COLOR_RGB12U, DRM_FORMAT_RGBX, 2, false }, /*
RGB12x- */
+ { OMAP_DSS_COLOR_RGBX16, DRM_FORMAT_XRGB, 2, false }, /*
xRGB12- */
+ { OMAP_DSS_COLOR_RGBA16, DRM_FORMAT_RGBA, 2, false }, /*
RGBA12- */
+ { OMAP_DSS_COLOR_ARGB16, DRM_FORMAT_ABGR, 2, false }, /*
ARGB16- */
+ { OMAP_DSS_COLOR_XRGB16_1555, DRM_FORMAT_XRGB1555, 2, false }, /*
xRGB15-1555 */
+ { OMAP_DSS_COLOR_ARGB16_1555, DRM_FORMAT_ARGB1555, 2, false }, /*
ARGB16-1555 */
+ /* 24bpp RGB: */
+ { OMAP_DSS_COLOR_RGB24P, DRM_FORMAT_RGB888, 3, false }, /*
RGB24-888 */
+ /* 32bpp [A]RGB: */
+ { OMAP_DSS_COLOR_RGBX32, DRM_FORMAT_RGBX, 4, false }, /*
RGBx24- */
+ { OMAP_DSS_COLOR_RGB24U, DRM_FORMAT_XRGB, 4, false }, /*
xRGB24- */
+ { OMAP_DSS_COLOR_RGBA32, DRM_FORMAT_RGBA, 4, false }, /*
RGBA32- */
+ { OMAP_DSS_COLOR_ARGB32, DRM_FORMAT_ARGB, 4, false }, /*
ARGB32- */
+ /* YUV: */
+/* TODO: multi-planar support..
+ { OMAP_DSS_COLOR_NV12,DRM_FORMAT_NV12, 1, true },
+ */
+ { OMAP_DSS_COLOR_YUV2,DRM_FORMAT_YUYV, 2, true },
+ { OMAP_DSS_COLOR_UYVY,DRM_FORMAT_UYVY, 2, true },
+};
+
#define to_omap_framebuffer(x) container_of(x, struct omap_framebuffer, base)
struct omap_framebuffer {
@@ -171,39 +201,61 @@ void omap_framebuffer_flush(struct drm_framebuffer *fb,
}
[PATCH 1/2] drm/omap: drm API update: make fops struct const
On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote: > From: Rob Clark > > Update to reflect changes in: > "Make the per-driver file_operations struct const" This one I could take today, no need for me to rely on the drm api changes, right? greg k-h
[PATCH 2/2] drm/omap: drm API update: addfb2
On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote: > From: Rob Clark > > Update to reflect changes in: > "drm: add an fb creation ioctl that takes a pixel format v5" This one I'm going to have to wait for the drm api merges to happen, so I'll just wait for them to go into Linus's tree before taking them, ok? thanks, greg k-h
[PATCH 1/2] drm/omap: drm API update: make fops struct const
On Mon, Dec 12, 2011 at 6:55 PM, Greg KH wrote: > On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote: >> From: Rob Clark >> >> Update to reflect changes in: >> "Make the per-driver file_operations struct const" > > This one I could take today, no need for me to rely on the drm api > changes, right? I don't think so, at least not if you want it to compile ;-) Previously the 'struct file_operations' was inline with the 'struct drm_driver' rather than a pointer. But if it it makes it easier for you to keep track I can keep a tree that you can pull from w/ a branch on top with the patches that depend on stuff coming in thru drm-next. BR, -R > greg k-h > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/omap: drm API update: addfb2
On Mon, Dec 12, 2011 at 6:56 PM, Greg KH wrote: > On Mon, Dec 12, 2011 at 06:49:44PM -0600, Rob Clark wrote: >> From: Rob Clark >> >> Update to reflect changes in: >> "drm: add an fb creation ioctl that takes a pixel format v5" > > This one I'm going to have to wait for the drm api merges to happen, so > I'll just wait for them to go into Linus's tree before taking them, ok? Yup, thanks. That was the intention. Let me know if it gets confusing to know which patches can go now and which have dependency on other trees, and I can setup a git tree on freedesktop which branches for the parts that depend on other trees. I'm not sure if it begins to get a mess to keep track otherwise. BR, -R > thanks, > > greg k-h > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/omap: drm API update: make fops struct const
On Mon, Dec 12, 2011 at 06:59:59PM -0600, Rob Clark wrote: > On Mon, Dec 12, 2011 at 6:55 PM, Greg KH wrote: > > On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote: > >> From: Rob Clark > >> > >> Update to reflect changes in: > >> "Make the per-driver file_operations struct const" > > > > This one I could take today, no need for me to rely on the drm api > > changes, right? > > I don't think so, at least not if you want it to compile ;-) Doh, you are right, sorry about that. > Previously the 'struct file_operations' was inline with the 'struct > drm_driver' rather than a pointer. But if it it makes it easier for > you to keep track I can keep a tree that you can pull from w/ a branch > on top with the patches that depend on stuff coming in thru drm-next. No, that would mix the two branches, and I can't do that, right? So let's just wait for the drm-next branch to be merged with Linus, and I'll hold onto these until then, ok? thanks, greg k-h
[PATCH 1/2] drm/omap: drm API update: make fops struct const
On Mon, Dec 12, 2011 at 7:04 PM, Greg KH wrote: > On Mon, Dec 12, 2011 at 06:59:59PM -0600, Rob Clark wrote: >> On Mon, Dec 12, 2011 at 6:55 PM, Greg KH wrote: >> > On Mon, Dec 12, 2011 at 06:49:43PM -0600, Rob Clark wrote: >> >> From: Rob Clark >> >> >> >> Update to reflect changes in: >> >> "Make the per-driver file_operations struct const" >> > >> > This one I could take today, no need for me to rely on the drm api >> > changes, right? >> >> I don't think so, at least not if you want it to compile ;-) > > Doh, you are right, sorry about that. > >> Previously the 'struct file_operations' was inline with the 'struct >> drm_driver' rather than a pointer. ?But if it it makes it easier for >> you to keep track I can keep a tree that you can pull from w/ a branch >> on top with the patches that depend on stuff coming in thru drm-next. > > No, that would mix the two branches, and I can't do that, right? hmm, yeah > So let's just wait for the drm-next branch to be merged with Linus, and > I'll hold onto these until then, ok? ok, great.. if you don't mind just holding them until drm-next gets pulled into Linus's tree, that would be perfect. Thanks! BR, -R > thanks, > > greg k-h > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/exynos: Add plane support with fimd
On Mon, Dec 12, 2011 at 8:39 PM, Inki Dae wrote: > Hi, Rob. > below is my answer. > >> -Original Message- >> From: Rob Clark [mailto:robdclark at gmail.com] >> Sent: Tuesday, December 13, 2011 9:48 AM >> To: Joonyoung Shim >> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; dri- >> devel at lists.freedesktop.org >> Subject: Re: [PATCH 5/5] drm/exynos: Add plane support with fimd >> >> On Mon, Dec 12, 2011 at 6:41 PM, Joonyoung Shim >> wrote: >> > On 12/13/2011 06:59 AM, Rob Clark wrote: >> >> >> >> On Fri, Dec 9, 2011 at 4:59 AM, Inki Dae ?wrote: >> >>> >> >>> From: Joonyoung Shim >> >>> >> >>> The exynos fimd supports 5 window overlays. Only one window overlay of >> >>> fimd is used by the crtc, so we need plane feature to use the rest >> >>> window overlays. >> >>> >> >>> This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it >> >>> is the ioctl to decide for user to assign which window overlay. >> >>> >> >> btw, I think I will end up with a similar ioctl.. so thought I'd >> >> double check for consistency, is zorder interpreted from back to front >> >> or front to back? ?Ie. higher numeric value in front or behind of >> >> lower numeric value? ?Are negative values permitted? >> > >> > >> > The zpos of exynos plane is just the index of overlay of exynos fimd or >> > exynos hdmi. 0 zpos means first overlay and 1 zpos means second overlay. >> > It isn't the priority value but higher zpos will have higher priority >> > generally. >> >> I'm not sure that I quite understand that.. does that mean zpos=1 will >> be in front of zpos=0 (which would be in front of crtc, aka zpos=-1). >> Do you have a way to put overlays *behind* crtc layer (which >> presumably would be in some mode with an alpha channel?) >> >> (IIRC, samsung has some public TRM type document.. if this is covered >> there, feel free to answer by just pointing me at the section I should >> read) >> > > I know that omap, at least omap3(Display Controller of the Display > Subsystem), has two modes. one is normal mode and another is alpha mode. and > they also have different overlay priority but Samsung exynos has fixed > priority to hardware overlays. so higher overlay always is in front of lower > overlay. in case of plane module for Samsung SoC, if zpos is -1 then crtc > has default overlay designated by machine code. so whether some overlay is > in front of crtc or not would be decided by default overlay. ahh, ok.. I was hoping it was as easy as omap4 where we can just set arbitrary z-order (0-4) for any of the layers (crtc or overlay). So maybe not a way to completely abstract this in the same way for userspace (but the case is the same in omap3 where it is either normal or alpha mode.. and I hadn't really decided yet how to handle the difference between omap generations for this sort of API yet). I guess userspace ddx driver (or wayland compositor, etc) would still need to know a bit about what is under the hood.. sigh.. BR, -R > Thank you, > Inki Dae. > > >> BR, >> -R >> >> > A negative value -1 is defined to special value. A exynos crtc should >> > use one overlay and -1 zpos means the overlay that crtc uses. >> > >> > Thanks. >> > >> >> BR, >> >> -R >> >> >> >> ___ >> >> dri-devel mailing list >> >> dri-devel at lists.freedesktop.org >> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> >> > >
Memory corruption starting in i915 code, in 3.2-rc5
El 11/12/11 16:29, Alex Villac?s Lasso escribi?: > El 11/12/11 15:46, Keith Packard escribi?: >> On Sun, 11 Dec 2011 13:36:30 -0500, Alex Villac?s Lasso> palosanto.com> wrote: >>> My system is a Fedora 16 x86_64 running self-compiled vanilla kernel >>> (.config attached for -rc5). I am getting an apparent memory corruption >>> that starts since linux 3.2-rc5. No such corruption was noticed in >>> 3.2-rc4. On the first instance, I eventually got a NULL pointer >>> dereference and the screen went black, the keyboard was unresponsive, >>> and I had to hard-reboot the machine. On the second instance, I managed >>> to reboot the machine normally. The full message log is attached. An >>> extract of the first WARNING: >> The only patch in the i915 code between rc4 and rc5 is a tiny VT-d >> workaround fix for ILK machines, which does fiddle with how the request >> linked lists are managed. >> >> Can you try reverting eb1711bb94991e93669c5a1b5f84f11be2d51ea1 and see >> if your problem goes away? >> > Recompiled kernel with patch reverted, testing right now. Ran kernel with reverted patch for 6 hours without issues so far. Will keep testing after work (issue happens with my home machine).
[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism
On Sat, Dec 10, 2011 at 03:13:06AM -0800, Mauro Carvalho Chehab wrote: > On 09-12-2011 20:50, Robert Morell wrote: > > On Mon, Dec 05, 2011 at 09:18:48AM -0800, Arnd Bergmann wrote: > >> On Friday 02 December 2011, Sumit Semwal wrote: > >>> This is the first step in defining a dma buffer sharing mechanism. > >> > > [...] > >> > >>> + return dmabuf; > >>> +} > >>> +EXPORT_SYMBOL(dma_buf_export); > >> > >> I agree with Konrad, this should definitely be EXPORT_SYMBOL_GPL, > >> because it's really a low-level function that I would expect > >> to get used by in-kernel subsystems providing the feature to > >> users and having back-end drivers, but it's not the kind of thing > >> we want out-of-tree drivers to mess with. > > > > Is this really necessary? If this is intended to be a > > lowest-common-denominator between many drivers to allow buffer sharing, > > it seems like it needs to be able to be usable by all drivers. > > > > If the interface is not accessible then I fear many drivers will be > > forced to continue to roll their own buffer sharing mechanisms (which is > > exactly what we're trying to avoid here, needless to say). > > Doing a buffer sharing with something that is not GPL is not fun, as, if any > issue rises there, it would be impossible to discover if the problem is either > at the closed-source driver or at the open source one. At the time I was using > the Nvidia proprietary driver, it was very common to have unexplained issues > caused likely by bad code there at the buffer management code, causing X > applications and extensions (like xv) to break. > > We should really make this EXPORT_SYMBOL_GPL(), in order to be able to latter > debug future share buffer issues, when needed. Sorry, I don't buy this argument. Making these exports GPL-only is not likely to cause anybody to open-source their driver, but will rather just cause them to use yet more closed-source code that is even less debuggable than this would be, to those without access to the source. Thanks, Robert > Regards, > Mauro
