[PATCH] libdrm/exynos: add test application for 2d gpu.
This patch adds library and test application for g2d gpu(fimg2d).
The fimg2d hardware is a 2D graphics accelerator(G2D) that
supports Bit Block Transfer(BitBLT).
The library includes the following primitive drawing operations:
.solid fill - This operation fills the given buffer with
the given color data.
.copy - This operation copies contents in source buffer to
destination buffer.
.copy_with_scale - This operation copies contents in source buffer
to destination buffer scaling up or down properly.
.blend - This operation blends contents in source buffer with
the ones in destination buffer.
And the above operations uses gem handle or user space address
allocated by malloc() as source or destination buffer.
And the test application includes just simple primitive drawing
tests with the above library.
And the guide to test is as the following,
"#exynos_fimg2d_test -s connector_id at crtc_id:mode"
With this above simple command, four primitive drawing operations
would be called step by step and also rendered on the output device
to the given connector and crtc id.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
configure.ac |1 +
exynos/Makefile.am|2 +-
exynos/exynos_drm.h | 52 +++
exynos/exynos_fimg2d.c| 630 +
exynos/fimg2d.h | 325 +
exynos/fimg2d_reg.h | 114 ++
tests/Makefile.am |4 +
tests/exynos/Makefile.am | 19 +
tests/exynos/exynos_fimg2d_test.c | 695 +
9 files changed, 1841 insertions(+), 1 deletions(-)
create mode 100644 exynos/exynos_fimg2d.c
create mode 100644 exynos/fimg2d.h
create mode 100644 exynos/fimg2d_reg.h
create mode 100644 tests/exynos/Makefile.am
create mode 100644 tests/exynos/exynos_fimg2d_test.c
diff --git a/configure.ac b/configure.ac
index e2e3466..2896f91 100644
--- a/configure.ac
+++ b/configure.ac
@@ -364,6 +364,7 @@ AC_CONFIG_FILES([
tests/kmstest/Makefile
tests/radeon/Makefile
tests/vbltest/Makefile
+ tests/exynos/Makefile
include/Makefile
include/drm/Makefile
man/Makefile
diff --git a/exynos/Makefile.am b/exynos/Makefile.am
index e782d34..539aea0 100644
--- a/exynos/Makefile.am
+++ b/exynos/Makefile.am
@@ -10,7 +10,7 @@ libdrm_exynos_ladir = $(libdir)
libdrm_exynos_la_LDFLAGS = -version-number 1:0:0 -no-undefined
libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
-libdrm_exynos_la_SOURCES = exynos_drm.c
+libdrm_exynos_la_SOURCES = exynos_drm.c exynos_fimg2d.c
libdrm_exynoscommonincludedir = ${includedir}/exynos
libdrm_exynoscommoninclude_HEADERS = exynos_drm.h
diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h
index aa97b22..c3c6579 100644
--- a/exynos/exynos_drm.h
+++ b/exynos/exynos_drm.h
@@ -123,6 +123,46 @@ enum e_drm_exynos_gem_mem_type {
EXYNOS_BO_WC
};
+struct drm_exynos_g2d_get_ver {
+ __u32 major;
+ __u32 minor;
+};
+
+struct drm_exynos_g2d_cmd {
+ __u32 offset;
+ __u32 data;
+};
+
+enum drm_exynos_g2d_buf_type {
+ G2D_BUF_USERPTR = 1 << 31,
+};
+
+enum drm_exynos_g2d_event_type {
+ G2D_EVENT_NOT,
+ G2D_EVENT_NONSTOP,
+ G2D_EVENT_STOP, /* not yet */
+};
+
+struct drm_exynos_g2d_userptr {
+ unsigned long userptr;
+ unsigned long size;
+};
+
+struct drm_exynos_g2d_set_cmdlist {
+ __u64 cmd;
+ __u64 cmd_buf;
+ __u32 cmd_nr;
+ __u32 cmd_buf_nr;
+
+ /* for g2d event */
+ __u64 event_type;
+ __u64 user_data;
+};
+
+struct drm_exynos_g2d_exec {
+ __u64 async;
+};
+
#define DRM_EXYNOS_GEM_CREATE 0x00
#define DRM_EXYNOS_GEM_MAP_OFFSET 0x01
#define DRM_EXYNOS_GEM_MMAP0x02
@@ -130,6 +170,11 @@ enum e_drm_exynos_gem_mem_type {
#define DRM_EXYNOS_GEM_GET 0x04
#define DRM_EXYNOS_VIDI_CONNECTION 0x07
+/* G2D */
+#define DRM_EXYNOS_G2D_GET_VER 0x20
+#define DRM_EXYNOS_G2D_SET_CMDLIST 0x21
+#define DRM_EXYNOS_G2D_EXEC0x22
+
#define DRM_IOCTL_EXYNOS_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_GEM_CREATE, struct drm_exynos_gem_create)
@@ -145,4 +190,11 @@ enum e_drm_exynos_gem_mem_type {
#define DRM_IOCTL_EXYNOS_VIDI_CONNECTION DRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_VIDI_CONNECTION, struct drm_exynos_vidi_connection)
+#define DRM_IOCTL_EXYNOS_G2D_GET_VER DRM_IOWR(DRM_COMMAND_BASE + \
+ DRM_EXYNOS_G2D_GET_VER, struct drm_exynos_g2d_get_ver)
+#define
Page allocation failures (was Re: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242)
On Tue, 2013-02-19 at 00:43 +0100, Jiri Slaby wrote: > On 02/19/2013 12:23 AM, Marcin Slusarz wrote: > > On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote: > >> Hi, > >> > >> we have a report of WARNING from 3.7.6 in nouveau at > >> drivers/gpu/drm/nouveau/core/core/mm.c:242 here: > >> https://bugzilla.novell.com/show_bug.cgi?id=802347#c11 > >> > >> There is an order 4 allocation failure in nouveau_drm_open -> > >> nouveau_vm_create, i.e. this one failed: > >> vm->pgt = kcalloc(vm->lpde - vm->fpde + 1, sizeof(*vm->pgt), GFP_KERNEL); Hi Jiri, I had the order 4 allocation failure and nouveau crash back in November on next-20121129. Bugzillas here: Allocation failure: https://bugzilla.kernel.org/show_bug.cgi?id=51301 Nouveau bug: https://bugzilla.kernel.org/show_bug.cgi?id=51291 https://bugs.freedesktop.org/show_bug.cgi?id=58087 IMO, the 32k allocation failure is the more serious bug. Check out the slab info from your report: Feb 06 13:16:15 desdemona kernel: Node 0 DMA32: 13378*4kB 5026*8kB 1823*16kB 135*32kB 5*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 129576kB Feb 06 13:16:15 desdemona kernel: Node 0 Normal: 1946*4kB 831*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 16496kB The pages are there: why did the allocation fail? I think this is related to all that kswapd mess. In my case, the machine really was OOM -- which made no sense. Completely out of page blocks larger than 32k on a 10gb machine with a bunch of emacs and terminal windows open for 3 days, just doing code, build, code, build, code, build? Regards, Peter Hurley
kernel BUG at mm/slub.c:3409, 3.8.0-rc7
[+cc Marcin Slusarz, dri-devel] On Tue, 2013-02-19 at 00:21 +, Christoph Lameter wrote: > The problem is that the subsystem attempted to call kfree with a pointer > that was not obtained via a slab allocation. > > On Sat, 16 Feb 2013, Denys Fedoryshchenko wrote: > > > Hi > > > > Worked for a while on 3.8.0-rc7, generally it is fine, then suddenly laptop > > stopped responding to keyboard and mouse. > > Sure it can be memory corruption by some other module, but maybe not. Worth > > to > > report i guess. > > After reboot checked logs and found this: > > > > Feb 16 00:40:17 localhost kernel: [23260.079253] [ cut here > > ] > > Feb 16 00:40:17 localhost kernel: [23260.079257] kernel BUG at > > mm/slub.c:3409! > > Feb 16 00:40:17 localhost kernel: [23260.079259] invalid opcode: [#1] > > SMP > > Feb 16 00:40:17 localhost kernel: [23260.079262] Modules linked in: > > ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 > > nf_defrag_ipv4 > > xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter > > ip_tables tun bridge stp llc nouveau snd_hda_codec_hdmi coretemp kvm_intel Was there an allocation failure earlier in the log? Might be this nouveau bug (linux-next at the time was 3.8 now): https://bugs.freedesktop.org/show_bug.cgi?id=58087 I think this was fixed but neither bug report has a cross reference :( The original report is here: https://bugzilla.kernel.org/show_bug.cgi?id=51291 Pekka, Can you please re-assign the bugzilla #51291 above to DRI? Thanks. Regards, Peter Hurley
[PATCH v2 4/4] drm/i915: use for_each_sg_page for setting up the gtt ptes
The existing gtt setup code is correct - and so doesn't need to be fixed to
handle compact dma scatter lists similarly to the previous patches. Still,
take the for_each_sg_page macro into use, to get somewhat simpler code.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 67 +--
1 file changed, 24 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 926a1e2..0c32054 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -116,41 +116,26 @@ static void gen6_ppgtt_insert_entries(struct
i915_hw_ppgtt *ppgtt,
{
gtt_pte_t *pt_vaddr;
unsigned act_pd = first_entry / I915_PPGTT_PT_ENTRIES;
- unsigned first_pte = first_entry % I915_PPGTT_PT_ENTRIES;
- unsigned i, j, m, segment_len;
- dma_addr_t page_addr;
- struct scatterlist *sg;
-
- /* init sg walking */
- sg = pages->sgl;
- i = 0;
- segment_len = sg_dma_len(sg) >> PAGE_SHIFT;
- m = 0;
-
- while (i < pages->nents) {
- pt_vaddr = kmap_atomic(ppgtt->pt_pages[act_pd]);
-
- for (j = first_pte; j < I915_PPGTT_PT_ENTRIES; j++) {
- page_addr = sg_dma_address(sg) + (m << PAGE_SHIFT);
- pt_vaddr[j] = gen6_pte_encode(ppgtt->dev, page_addr,
- cache_level);
-
- /* grab the next page */
- if (++m == segment_len) {
- if (++i == pages->nents)
- break;
+ unsigned act_pte = first_entry % I915_PPGTT_PT_ENTRIES;
+ struct sg_page_iter sg_iter;
+
+ pt_vaddr = kmap_atomic(ppgtt->pt_pages[act_pd]);
+ for_each_sg_page(pages->sgl, _iter, pages->nents, 0) {
+ dma_addr_t page_addr;
+
+ page_addr = sg_dma_address(sg_iter.sg) +
+ (sg_iter.sg_pgoffset << PAGE_SHIFT);
+ pt_vaddr[act_pte] = gen6_pte_encode(ppgtt->dev, page_addr,
+ cache_level);
+ if (++act_pte == I915_PPGTT_PT_ENTRIES) {
+ kunmap_atomic(pt_vaddr);
+ act_pd++;
+ pt_vaddr = kmap_atomic(ppgtt->pt_pages[act_pd]);
+ act_pte = 0;
- sg = sg_next(sg);
- segment_len = sg_dma_len(sg) >> PAGE_SHIFT;
- m = 0;
- }
}
-
- kunmap_atomic(pt_vaddr);
-
- first_pte = 0;
- act_pd++;
}
+ kunmap_atomic(pt_vaddr);
}
static void gen6_ppgtt_cleanup(struct i915_hw_ppgtt *ppgtt)
@@ -432,21 +417,17 @@ static void gen6_ggtt_insert_entries(struct drm_device
*dev,
enum i915_cache_level level)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- struct scatterlist *sg = st->sgl;
gtt_pte_t __iomem *gtt_entries =
(gtt_pte_t __iomem *)dev_priv->gtt.gsm + first_entry;
- int unused, i = 0;
- unsigned int len, m = 0;
+ int i = 0;
+ struct sg_page_iter sg_iter;
dma_addr_t addr;
- for_each_sg(st->sgl, sg, st->nents, unused) {
- len = sg_dma_len(sg) >> PAGE_SHIFT;
- for (m = 0; m < len; m++) {
- addr = sg_dma_address(sg) + (m << PAGE_SHIFT);
- iowrite32(gen6_pte_encode(dev, addr, level),
- _entries[i]);
- i++;
- }
+ for_each_sg_page(st->sgl, _iter, st->nents, 0) {
+ addr = sg_dma_address(sg_iter.sg) +
+ (sg_iter.sg_pgoffset << PAGE_SHIFT);
+ iowrite32(gen6_pte_encode(dev, addr, level), _entries[i]);
+ i++;
}
/* XXX: This serves as a posting read to make sure that the PTE has
--
1.7.10.4
[PATCH v2 3/4] drm/i915: create compact dma scatter lists for gem objects
So far we created a sparse dma scatter list for gem objects, where each
scatter list entry represented only a single page. In the future we'll
have to handle compact scatter lists too where each entry can consist of
multiple pages, for example for objects imported through PRIME.
The previous patches have already fixed up all other places where the
i915 driver _walked_ these lists. Here we have the corresponding fix to
_create_ compact lists. It's not a performance or memory footprint
improvement, but it helps to better exercise the new logic.
Reference: http://www.spinics.net/lists/dri-devel/msg33917.html
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_gem.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 03037cf..ec2f11f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1625,9 +1625,8 @@ i915_gem_object_is_purgeable(struct drm_i915_gem_object
*obj)
static void
i915_gem_object_put_pages_gtt(struct drm_i915_gem_object *obj)
{
- int page_count = obj->base.size / PAGE_SIZE;
- struct scatterlist *sg;
- int ret, i;
+ struct sg_page_iter sg_iter;
+ int ret;
BUG_ON(obj->madv == __I915_MADV_PURGED);
@@ -1647,8 +1646,8 @@ i915_gem_object_put_pages_gtt(struct drm_i915_gem_object
*obj)
if (obj->madv == I915_MADV_DONTNEED)
obj->dirty = 0;
- for_each_sg(obj->pages->sgl, sg, page_count, i) {
- struct page *page = sg_page(sg);
+ for_each_sg_page(obj->pages->sgl, _iter, obj->pages->nents, 0) {
+ struct page *page = sg_iter.page;
if (obj->dirty)
set_page_dirty(page);
@@ -1749,7 +1748,9 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
struct address_space *mapping;
struct sg_table *st;
struct scatterlist *sg;
+ struct sg_page_iter sg_iter;
struct page *page;
+ unsigned long last_pfn = 0; /* suppress gcc warning */
gfp_t gfp;
/* Assert that the object is not currently in any GPU domain. As it
@@ -1779,7 +1780,9 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
gfp = mapping_gfp_mask(mapping);
gfp |= __GFP_NORETRY | __GFP_NOWARN | __GFP_NO_KSWAPD;
gfp &= ~(__GFP_IO | __GFP_WAIT);
- for_each_sg(st->sgl, sg, page_count, i) {
+ sg = st->sgl;
+ st->nents = 0;
+ for (i = 0; i < page_count; i++) {
page = shmem_read_mapping_page_gfp(mapping, i, gfp);
if (IS_ERR(page)) {
i915_gem_purge(dev_priv, page_count);
@@ -1802,9 +1805,18 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
gfp &= ~(__GFP_IO | __GFP_WAIT);
}
- sg_set_page(sg, page, PAGE_SIZE, 0);
+ if (!i || page_to_pfn(page) != last_pfn + 1) {
+ if (i)
+ sg = sg_next(sg);
+ st->nents++;
+ sg_set_page(sg, page, PAGE_SIZE, 0);
+ } else {
+ sg->length += PAGE_SIZE;
+ }
+ last_pfn = page_to_pfn(page);
}
+ sg_mark_end(sg);
obj->pages = st;
if (i915_gem_object_needs_bit17_swizzle(obj))
@@ -1813,8 +1825,9 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
return 0;
err_pages:
- for_each_sg(st->sgl, sg, i, page_count)
- page_cache_release(sg_page(sg));
+ sg_mark_end(sg);
+ for_each_sg_page(st->sgl, _iter, st->nents, 0)
+ page_cache_release(sg_iter.page);
sg_free_table(st);
kfree(st);
return PTR_ERR(page);
--
1.7.10.4
[PATCH v2 2/4] drm/i915: handle walking compact dma scatter lists
So far the assumption was that each dma scatter list entry contains only
a single page. This might not hold in the future, when we'll introduce
compact scatter lists, so prepare for this everywhere in the i915 code
where we walk such a list.
We'll fix the place _creating_ these lists separately in the next patch
to help the reviewing/bisectability.
Reference: http://www.spinics.net/lists/dri-devel/msg33917.html
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.h| 17 ++---
drivers/gpu/drm/i915/i915_gem.c| 24
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 13 +++--
drivers/gpu/drm/i915/i915_gem_tiling.c | 18 ++
4 files changed, 31 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e95337c..2c03636 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1528,17 +1528,12 @@ void i915_gem_lastclose(struct drm_device *dev);
int __must_check i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
static inline struct page *i915_gem_object_get_page(struct drm_i915_gem_object
*obj, int n)
{
- struct scatterlist *sg = obj->pages->sgl;
- int nents = obj->pages->nents;
- while (nents > SG_MAX_SINGLE_ALLOC) {
- if (n < SG_MAX_SINGLE_ALLOC - 1)
- break;
-
- sg = sg_chain_ptr(sg + SG_MAX_SINGLE_ALLOC - 1);
- n -= SG_MAX_SINGLE_ALLOC - 1;
- nents -= SG_MAX_SINGLE_ALLOC - 1;
- }
- return sg_page(sg+n);
+ struct sg_page_iter sg_iter;
+
+ for_each_sg_page(obj->pages->sgl, _iter, obj->pages->nents, n)
+ return sg_iter.page;
+
+ return NULL;
}
static inline void i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
{
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8413ffc..03037cf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -411,8 +411,7 @@ i915_gem_shmem_pread(struct drm_device *dev,
int obj_do_bit17_swizzling, page_do_bit17_swizzling;
int prefaulted = 0;
int needs_clflush = 0;
- struct scatterlist *sg;
- int i;
+ struct sg_page_iter sg_iter;
user_data = (char __user *) (uintptr_t) args->data_ptr;
remain = args->size;
@@ -441,11 +440,9 @@ i915_gem_shmem_pread(struct drm_device *dev,
offset = args->offset;
- for_each_sg(obj->pages->sgl, sg, obj->pages->nents, i) {
- struct page *page;
-
- if (i < offset >> PAGE_SHIFT)
- continue;
+ for_each_sg_page(obj->pages->sgl, _iter, obj->pages->nents,
+offset >> PAGE_SHIFT) {
+ struct page *page = sg_iter.page;
if (remain <= 0)
break;
@@ -460,7 +457,6 @@ i915_gem_shmem_pread(struct drm_device *dev,
if ((shmem_page_offset + page_length) > PAGE_SIZE)
page_length = PAGE_SIZE - shmem_page_offset;
- page = sg_page(sg);
page_do_bit17_swizzling = obj_do_bit17_swizzling &&
(page_to_phys(page) & (1 << 17)) != 0;
@@ -732,8 +728,7 @@ i915_gem_shmem_pwrite(struct drm_device *dev,
int hit_slowpath = 0;
int needs_clflush_after = 0;
int needs_clflush_before = 0;
- int i;
- struct scatterlist *sg;
+ struct sg_page_iter sg_iter;
user_data = (char __user *) (uintptr_t) args->data_ptr;
remain = args->size;
@@ -768,13 +763,11 @@ i915_gem_shmem_pwrite(struct drm_device *dev,
offset = args->offset;
obj->dirty = 1;
- for_each_sg(obj->pages->sgl, sg, obj->pages->nents, i) {
- struct page *page;
+ for_each_sg_page(obj->pages->sgl, _iter, obj->pages->nents,
+offset >> PAGE_SHIFT) {
+ struct page *page = sg_iter.page;
int partial_cacheline_write;
- if (i < offset >> PAGE_SHIFT)
- continue;
-
if (remain <= 0)
break;
@@ -796,7 +789,6 @@ i915_gem_shmem_pwrite(struct drm_device *dev,
((shmem_page_offset | page_length)
& (boot_cpu_data.x86_clflush_size - 1));
- page = sg_page(sg);
page_do_bit17_swizzling = obj_do_bit17_swizzling &&
(page_to_phys(page) & (1 << 17)) != 0;
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 6a5af68..898615d 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -62,7 +62,7 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attachme
src = obj->pages->sgl;
dst = st->sgl;
for (i = 0; i <
[PATCH v2 1/4] drm: handle compact dma scatter lists in drm_clflush_sg()
So far the assumption was that each scatter list entry contains a single
page. This might not hold in the future, when we'll introduce compact
scatter lists, so prepare for this here.
Reference: http://www.spinics.net/lists/dri-devel/msg33917.html
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_cache.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index a575cb2..bc8edbe 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -105,12 +105,11 @@ drm_clflush_sg(struct sg_table *st)
{
#if defined(CONFIG_X86)
if (cpu_has_clflush) {
- struct scatterlist *sg;
- int i;
+ struct sg_page_iter sg_iter;
mb();
- for_each_sg(st->sgl, sg, st->nents, i)
- drm_clflush_page(sg_page(sg));
+ for_each_sg_page(st->sgl, _iter, st->nents, 0)
+ drm_clflush_page(sg_iter.page);
mb();
return;
--
1.7.10.4
[PATCH v2 0/4] drm/i915: handle compact dma scatter lists
This series adds support for handling compact dma scatter lists to the i915 driver. This is a dependency for the related upcoming change in the PRIME interface: http://www.spinics.net/lists/dri-devel/msg33917.html v2: - Add the sg_for_each_page macro to /lib/scatterlist instead of drivers/drm. This is a separate patchset being merged through the -mm tree. - Use the sg_for_each_page macro in the gtt pte setup code too. Imre Deak (4): drm: handle compact dma scatter lists in drm_clflush_sg() drm/i915: handle walking compact dma scatter lists drm/i915: create compact dma scatter lists for gem objects drm/i915: use for_each_sg_page for setting up the gtt ptes drivers/gpu/drm/drm_cache.c|7 ++-- drivers/gpu/drm/i915/i915_drv.h| 17 +++- drivers/gpu/drm/i915/i915_gem.c| 55 ++ drivers/gpu/drm/i915/i915_gem_dmabuf.c | 13 --- drivers/gpu/drm/i915/i915_gem_gtt.c| 67 drivers/gpu/drm/i915/i915_gem_tiling.c | 18 + 6 files changed, 80 insertions(+), 97 deletions(-) -- 1.7.10.4
[pull] tilcdc-next for 3.9
On Mon, Feb 18, 2013 at 12:16:50PM +0200, Tomi Valkeinen wrote: > On 2013-02-18 12:03, Daniel Vetter wrote: > > On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen wrote: > >> But my main concern for this series is still that it creates custom > >> panel stuff, and adds DT bindings for them. Which means we need to > >> support those custom DT bindings in the future, even though it's quite > >> sure that CDF should be used also for this driver, changing the bindings. > > > > I'm confused a bit, but shouldn't the DT bindings and CDF be rather > > orthogonal? Of course for ARM board support we need to have DT binding > > tables in the kernel to match up hw with the drivers, but I've thought > > it should be pretty much irrelevant which driver is hooking up to a > > given dt binding ... > > Yes, you're right, DT bindings should describe the HW, no matter what > the software looks like. I was a bit unclear. > > Perhaps I should rephrase my main concern to: the DT bindings in this > series does not describe the hardware properly and in enough detail. The > bindings work for now, but a more sophisticated driver needs more > information about the HW. > > For example, looking at the first patch, I see DT nodes for the LCDC and > the dvicape, but nothing describes the connection between these two. > > And looking at the third patch, there's a DT node for HDMI, using > compatible = "tilcdc,slave". Again, no connection is described, and also > "tilcdc,slave" doesn't even sound like any hardware device, but more > like a software construct for this particular driver. > > Those are just off the top of my head. These things are usually quite > difficult to find out until you actually implement the code. Ok, I understand your concern now, thanks for the elaboration. I guess even when we try really hard to get DT bindings right we'll end up with the occasional need to hardcode a few things ... Quirk tables in the driver seem to be the way of life ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v3 3/7] drm/tegra: Implement .mode_set_base()
On 02/18/2013 04:40 PM, Mark Zhang wrote: > On 02/18/2013 03:20 PM, Thierry Reding wrote: [...] >> > > Actually the dc which connects with LVDS doesn't know about 1080p > stuffs. All the video mode infos stored in this dc is still 1366x768(I > just checked the register values on my Tegra 30 cardhu). The dc just > scans 1366 pixels then jump to next line(based on the 1080p line stride > we set) and keep scanning. > > So the drm crtc helper(I believe it's function: > drm_crtc_helper_set_config) finds out that video mode is not changed so > a fb_change while not full modeset is triggered. > > I started to test this new series patch set just now. I'll let you know > whether the issue I described still exists. > Tested. This issue still exists. Mark > Mark >> Thierry >>
[PATCH] omapdrm: Make fixed resolution panels work
On Monday 18 February 2013 02:01 PM, Tomi Valkeinen wrote:
> On 2013-02-18 09:23, Archit Taneja wrote:
>
diff --git a/drivers/staging/omapdrm/omap_connector.c
b/drivers/staging/omapdrm/omap_connector.c
index 4cc9ee7..839c6e4 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -110,6 +110,11 @@ static enum drm_connector_status
omap_connector_detect(
ret = connector_status_connected;
else
ret = connector_status_disconnected;
+ } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
+ dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
+ ret = connector_status_connected;
>>>
>>> hmm, why not just have a default detect fxn for panel drivers which
>>> always returns true? Seems a bit cleaner.. otherwise, I guess we
>>> could just change omap_connector so that if dssdev->detect is null,
>>> assume always connected. Seems maybe a slightly better way since
>>> currently omap_connector doesn't really know too much about different
>>> sorts of panels. But I'm not too picky if that is a big pain because
>>> we probably end up changing all this as CFP starts coming into
>>> existence.
>>>
>>> Same goes for check_timings/set_timings.. it seems a bit cleaner just
>>> to have default fxns in the panel drivers that do-the-right-thing,
>>> although I suppose it might be a bit more convenient for out-of-tree
>>> panel drivers to just assume fixed panel if these fxns are null.
>
> Yeah, I can't make my mind about null pointer. It's nice to inform with
> a null pointer that the panel doesn't support the given operation, or
> that it doesn't make sense, but handling the null value makes the code a
> bit complex.
>
> For example, our VENC driver doesn't know if there's a TV connected or
> not, so neither true or false as connect return value makes sense there.
> Or, for a DSI command mode panel, set_timings doesn't really make much
> sense.
>
>> Maybe having default functions in omapdss might be a better idea. There
>> is an option of adding default functions in omap_dss_register_driver()
>> (drivers/video/omap2/dss/core.c).
>>
>> Tomi, do you think it's fine to add some more default panel driver funcs?
>
> We can add default funcs. However, adding them in
> omap_dss_register_driver is not so nice, as it makes the omap_dss_driver
> (which is essentially an "ops" struct) non-constable. Instead, we should
> move the setting of the default funcs to the drivers.
>
> If I'm not mistaken, we could manage that with a helper macro. Assigning
> a value to the same field of a struct should be ok by the compiler, and
> should cause only the last assignment to be taken into use. So:
>
> static struct foo zab = {
> .bar = 123, /* ignored */
> .bar = 234, /* used */
> };
>
> And so we could have:
>
> static struct omap_dss_driver my_panel_driver = {
> OMAPDSS_DEFAULT_PANEL_OPS, /* macro for default ops */
>
> .enable = my_panel_enable,
> /* ... */
> };
This sounds nice, but if the panel driver ops are going to be changed
again in CPF, then it might make sense to do this later, depending on
how it CPF handles default ops in panel drivers.
Maybe we should leave this patch as-is, since we know it will be
modified later.
Archit
[PATCH v3 3/7] drm/tegra: Implement .mode_set_base()
On 02/18/2013 03:20 PM, Thierry Reding wrote:
> On Mon, Feb 18, 2013 at 03:06:10PM +0800, Mark Zhang wrote:
>> On 02/18/2013 02:48 PM, Thierry Reding wrote:
>>> On Mon, Feb 18, 2013 at 02:17:53PM +0800, Mark Zhang wrote:
On 02/14/2013 12:05 AM, Thierry Reding wrote:
> The sequence for replacing the scanout buffer is much shorter than a
> full mode change operation so implementing this callback considerably
> speeds up cases where only a new framebuffer is to be scanned out.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v3:
> - split DC_CMD_STATE_CONTROL writes
>
> drivers/gpu/drm/tegra/dc.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 8f97b1c..cc4c85e 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -114,6 +114,27 @@ static int tegra_dc_add_planes(struct drm_device
> *drm, struct tegra_dc *dc)
> return 0;
> }
>
> +static int tegra_dc_set_base(struct tegra_dc *dc, int x, int y,
> + struct tegra_framebuffer *fb)
> +{
> + unsigned long value;
> +
> + tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
> +
> + value = fb->base.offsets[0] + y * fb->base.pitches[0] +
> + x * fb->base.bits_per_pixel / 8;
> +
> + tegra_dc_writel(dc, fb->obj->paddr + value, DC_WINBUF_START_ADDR);
> +
> + value = GENERAL_UPDATE | WIN_A_UPDATE;
> + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> +
> + value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
> + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> +
> + return 0;
> +}
Again, what do you think about the "line stride" problem I mentioned:
http://lists.freedesktop.org/archives/dri-devel/2013-January/033561.html
Don't get me wrong that I also don't want to add a line stride update
here because that doesn't make sense. It's just a workaround. But we
need to find a way to make multi-head page flip working.
>>>
>>> I'm not sure that it's something we need to support. .mode_set_base() is
>>> explicitly used only for cases where the framebuffer configuration
>>> doesn't change. That is, only in cases where the only thing that changes
>>> is the physical address of the framebuffer to be displayed.
>>>
>>> The current case where one framebuffer is used as scanout for both
>>> outputs isn't something that page-flipping can support. Page-flipping is
>>> always per-CRTC because typically each CRTC would run at a different
>>> frequency (or even if both ran at the same frequency the VBLANK is very
>>> unlikely to coincide anyway).
>>>
>>> So an application that wants to support page-flipping on two outputs
>>> also needs to take care to set them up with different framebuffers, in
>>> which case what you're describing here can't really happen.
>>
>> Yes, the userspace application needs to setup different framebuffers for
>> different crtcs. So if LVDS & HDMI are connected, here is what the
>> application does:
>>
>> 1. drm reports that 2 connectors: LVDS & HDMI are present in the system
>> 2. The resolution of them are: 1366x768 & 1080p
>> 3. Userspace application allocates 2 fbs according to the resolution got
>> above.
>> 4. call drmModeSetCrtc to switch the fb shown in LVDS to the new fb we
>> created.
>> 5. At this time, remember the line stride setting in dc which connects
>> with LVDS is calculated according to the 1080p resolution. So finally we
>> got a corrupt display because we're showing a 1366x768 fb but with
>> 1080p's line stride.
>
> I don't see how the 1080p stride would still be relevant here. Setting
> the LVDS to the new 1366x768 framebuffer should trigger a full modeset
> and therefore set the stride to the value required by the new 1366x768
> framebuffer.
>
Actually the dc which connects with LVDS doesn't know about 1080p
stuffs. All the video mode infos stored in this dc is still 1366x768(I
just checked the register values on my Tegra 30 cardhu). The dc just
scans 1366 pixels then jump to next line(based on the 1080p line stride
we set) and keep scanning.
So the drm crtc helper(I believe it's function:
drm_crtc_helper_set_config) finds out that video mode is not changed so
a fb_change while not full modeset is triggered.
I started to test this new series patch set just now. I'll let you know
whether the issue I described still exists.
Mark
> Thierry
>
[Bug 59982] Radeon: evergreen Atombios in loop during initialization on ppc64
https://bugs.freedesktop.org/show_bug.cgi?id=59982 --- Comment #16 from Alex Deucher --- (In reply to comment #15) > Can someone clarify something here? Is the bit that we are waiting to go low > a bit in the adapter's memory? If so, is it the adapter hardware that we are > waiting to set this bit? It's a memory mapped register. We are waiting for one of the display related bits to go low, so it's the GPU that would be setting that bit. The timeout is in the driver. We eventually drop out of the loop in the atom interpretor if we get stuck after a certain number of seconds. > > Is there anyway to dump the adapter to determine its state when we hit the > timeout? You can dump the mmio registers. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/f699eb50/attachment.html>
[Bug 59982] Radeon: evergreen Atombios in loop during initialization on ppc64
https://bugs.freedesktop.org/show_bug.cgi?id=59982 --- Comment #15 from Brian King --- Can someone clarify something here? Is the bit that we are waiting to go low a bit in the adapter's memory? If so, is it the adapter hardware that we are waiting to set this bit? Is there anyway to dump the adapter to determine its state when we hit the timeout? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/e6028aa3/attachment.html>
[PATCH] intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets
On Wed, Feb 13, 2013 at 07:40:05PM +0100, Daniel Vetter wrote:
> On Tue, Jan 22, 2013 at 7:55 PM, David Woodhouse
> wrote:
> > On Mon, 2013-01-21 at 19:48 +0100, Daniel Vetter wrote:
> >> We already have the quirk entry for the mobile platform, but also
> >> reports on some desktop versions. So be paranoid and set it
> >> everywhere.
> >>
> >> References: http://www.mail-archive.com/dri-devel at
> >> lists.freedesktop.org/msg33138.html
> >> Cc: stable at vger.kernel.org
> >> Cc: David Woodhouse
> >> Reported-and-tested-by: Mihai Moldovan
> >> Signed-off-by: Daniel Vetter
> >> ---
> >> drivers/iommu/intel-iommu.c |8 +++-
> >> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> >> index 9743769..19854bf 100644
> >> --- a/drivers/iommu/intel-iommu.c
> >> +++ b/drivers/iommu/intel-iommu.c
> >> @@ -4215,13 +4215,19 @@ static void __devinit quirk_iommu_rwbf(struct
> >> pci_dev *dev)
> >> {
> >> /*
> >>* Mobile 4 Series Chipset neglects to set RWBF capability,
> >> - * but needs it:
> >> + * but needs it. Same seems to hold for the desktop versions.
> >>*/
> >> printk(KERN_INFO "DMAR: Forcing write-buffer flush capability\n");
> >> rwbf_quirk = 1;
> >> }
> >>
> >> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_rwbf);
> >> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_rwbf);
> >> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e10, quirk_iommu_rwbf);
> >> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20, quirk_iommu_rwbf);
> >> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_rwbf);
> >> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, quirk_iommu_rwbf);
> >> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e90, quirk_iommu_rwbf);
> >>
> >> #define GGC 0x52
> >> #define GGC_MEMORY_SIZE_MASK (0xf << 8)
> >
> > Again, I'm really unhappy about doing this kind of thing based on
> > hearsay. This should have a specific reference (with URL) to a published
> > erratum. Rajesh?
>
> Any updates here? I'd like to include this for 3.9 -next with cc:
> stable to finally allow distros to enable DMAR/IOMMU support by
> default on Intel hw. The current state of affairs is simply
> embarrassing imo :(
Whatever, I want to get this off my table, so merged to drm-intel-fixes
for 3.9.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v17 2/7] video: add display_timing and videomode
Hi Steffen, On 2013-01-25 11:01, Steffen Trumtrar wrote: > +/* VESA display monitor timing parameters */ > +#define VESA_DMT_HSYNC_LOW BIT(0) > +#define VESA_DMT_HSYNC_HIGH BIT(1) > +#define VESA_DMT_VSYNC_LOW BIT(2) > +#define VESA_DMT_VSYNC_HIGH BIT(3) > + > +/* display specific flags */ > +#define DISPLAY_FLAGS_DE_LOW BIT(0) /* data enable flag */ > +#define DISPLAY_FLAGS_DE_HIGHBIT(1) > +#define DISPLAY_FLAGS_PIXDATA_POSEDGEBIT(2) /* drive data on pos. > edge */ > +#define DISPLAY_FLAGS_PIXDATA_NEGEDGEBIT(3) /* drive data on neg. > edge */ > +#define DISPLAY_FLAGS_INTERLACED BIT(4) > +#define DISPLAY_FLAGS_DOUBLESCAN BIT(5) > + unsigned int dmt_flags; /* VESA DMT flags */ > + unsigned int data_flags; /* video data flags */ Why did you go for this approach? To be able to represent true/false/not-specified? Would it be simpler to just have "flags" field? What does it give us to have those two separately? Should the above say raising edge/falling edge instead of positive edge/negative edge? Tomi
[PATCH v3 0/7] drm/tegra: Miscellaneous enhancements
Hi Thierry, Which version is this patch set based on? I tried to apply it on linux-next 0206 & tot 0215 but failed: Applying: drm: Add consistency check for page-flipping Applying: drm/tegra: Add plane support error: patch failed: drivers/gpu/drm/tegra/drm.h:121 error: drivers/gpu/drm/tegra/drm.h: patch does not apply Patch failed at 0002 drm/tegra: Add plane support When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". Mark On 02/14/2013 12:04 AM, Thierry Reding wrote: > This patch series introduces a number of useful features for the Tegra > DRM driver. Patch 1 is a documentation update and adds a warning to the > page-flip IOCTL to catch buggy drivers that return success but failed to > update the crtc->fb field, which would cause the reference counting to > become unbalanced. > > Patch 2 adds support for the additional two planes available on Tegra > hardware, while patch 3 implement .mode_set_base() to allow for some > nice speed up when changing the framebuffer without actually changing > the resolution. Patch 4 adds VBLANK support and patch 5 builds on the > previous two to provide the page-flipping IOCTL. Patch 6 splits the > DC_CMD_STATE_CONTROL register writes into two consecutive writes as > required by the TRM. > > Finally patch 7 adds a new file, named "framebuffers" to debugfs which > can be used to dump a list of framebuffers attached to the DRM device. > This is most useful to inspect the reference count but could also be > helpful in diagnosing out-of-memory conditions and such. > > Thierry > > Thierry Reding (7): > drm: Add consistency check for page-flipping > drm/tegra: Add plane support > drm/tegra: Implement .mode_set_base() > drm/tegra: Implement VBLANK support > drm/tegra: Implement page-flipping support > drm/tegra: Split DC_CMD_STATE_CONTROL register write > drm/tegra: Add list of framebuffers to debugfs > > Documentation/DocBook/drm.tmpl | 6 + > drivers/gpu/drm/drm_crtc.c | 7 + > drivers/gpu/drm/tegra/dc.c | 489 > - > drivers/gpu/drm/tegra/dc.h | 2 +- > drivers/gpu/drm/tegra/drm.c| 103 + > drivers/gpu/drm/tegra/drm.h| 37 > 6 files changed, 533 insertions(+), 111 deletions(-) >
[PATCH v3 2/7] drm/tegra: Add plane support
On 02/18/2013 03:01 PM, Thierry Reding wrote:
> On Mon, Feb 18, 2013 at 02:55:04PM +0800, Mark Zhang wrote:
>> On 02/18/2013 02:40 PM, Thierry Reding wrote:
>>> On Mon, Feb 18, 2013 at 02:06:56PM +0800, Mark Zhang wrote:
On 02/14/2013 12:05 AM, Thierry Reding wrote:
> Add support for the B and C planes which support RGB and YUV pixel
> formats and can be used as overlays or hardware cursor. Currently
> only 32-bit RGBA pixel formats are advertised.
>
> Signed-off-by: Thierry Reding
[...]
> +static int tegra_dc_add_planes(struct drm_device *drm, struct tegra_dc
> *dc)
> +{
> + unsigned int i;
> + int err = 0;
> +
> + for (i = 0; i < 2; i++) {
> + struct tegra_plane *plane;
> +
> + plane = devm_kzalloc(drm->dev, sizeof(*plane), GFP_KERNEL);
Using "devm_kzalloc" here seems like not a good idea. Everytime plane
disable or crtc disable, we should free "struct tegra_plane" which is
allocated here. But the memory which devm_kzalloc allocates is only
freed when the driver detach. This makes lots of memory can't be
recycled when the plane enable/disable frequently.
>>>
>>> Why would we want to do that? I don't think doing so would even work,
>>> since the planes are resources that need to be registered with the DRM
>>> core and therefore can't be allocated on-demand.
>>>
>>
>> I'm wondering if we add power management codes in the future, the
>> crtc/plane will be disabled/enabled frequently, e.g: system going to
>> suspend state then resume.
>
> In that case it makes even less sense to allocate and deallocate the
> plane every time around. However, any optimizations aside, the allocated
> memory is passed into the core via drm_plane_init(), which registers
> that plane with the given CRTC. So if we deallocate the memory when the
> plane when it is disabled, we'd have to make sure to remove it from the
> core as well. However that would also mean that it disappears from the
> list of planes supported by the CRTC and therefore we wouldn't be able
> to use it again.
>
Alright, I mixed up the "disable" & "remove" of planes and crtcs. You're
right. Just forget what I said in this thread.
Mark
> Thierry
>
[PATCH v3 3/7] drm/tegra: Implement .mode_set_base()
On 02/18/2013 02:48 PM, Thierry Reding wrote:
> On Mon, Feb 18, 2013 at 02:17:53PM +0800, Mark Zhang wrote:
>> On 02/14/2013 12:05 AM, Thierry Reding wrote:
>>> The sequence for replacing the scanout buffer is much shorter than a
>>> full mode change operation so implementing this callback considerably
>>> speeds up cases where only a new framebuffer is to be scanned out.
>>>
>>> Signed-off-by: Thierry Reding
>>> ---
>>> Changes in v3:
>>> - split DC_CMD_STATE_CONTROL writes
>>>
>>> drivers/gpu/drm/tegra/dc.c | 31 +++
>>> 1 file changed, 31 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
>>> index 8f97b1c..cc4c85e 100644
>>> --- a/drivers/gpu/drm/tegra/dc.c
>>> +++ b/drivers/gpu/drm/tegra/dc.c
>>> @@ -114,6 +114,27 @@ static int tegra_dc_add_planes(struct drm_device *drm,
>>> struct tegra_dc *dc)
>>> return 0;
>>> }
>>>
>>> +static int tegra_dc_set_base(struct tegra_dc *dc, int x, int y,
>>> +struct tegra_framebuffer *fb)
>>> +{
>>> + unsigned long value;
>>> +
>>> + tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
>>> +
>>> + value = fb->base.offsets[0] + y * fb->base.pitches[0] +
>>> + x * fb->base.bits_per_pixel / 8;
>>> +
>>> + tegra_dc_writel(dc, fb->obj->paddr + value, DC_WINBUF_START_ADDR);
>>> +
>>> + value = GENERAL_UPDATE | WIN_A_UPDATE;
>>> + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
>>> +
>>> + value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
>>> + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
>>> +
>>> + return 0;
>>> +}
>>
>> Again, what do you think about the "line stride" problem I mentioned:
>>
>> http://lists.freedesktop.org/archives/dri-devel/2013-January/033561.html
>>
>> Don't get me wrong that I also don't want to add a line stride update
>> here because that doesn't make sense. It's just a workaround. But we
>> need to find a way to make multi-head page flip working.
>
> I'm not sure that it's something we need to support. .mode_set_base() is
> explicitly used only for cases where the framebuffer configuration
> doesn't change. That is, only in cases where the only thing that changes
> is the physical address of the framebuffer to be displayed.
>
> The current case where one framebuffer is used as scanout for both
> outputs isn't something that page-flipping can support. Page-flipping is
> always per-CRTC because typically each CRTC would run at a different
> frequency (or even if both ran at the same frequency the VBLANK is very
> unlikely to coincide anyway).
>
> So an application that wants to support page-flipping on two outputs
> also needs to take care to set them up with different framebuffers, in
> which case what you're describing here can't really happen.
Yes, the userspace application needs to setup different framebuffers for
different crtcs. So if LVDS & HDMI are connected, here is what the
application does:
1. drm reports that 2 connectors: LVDS & HDMI are present in the system
2. The resolution of them are: 1366x768 & 1080p
3. Userspace application allocates 2 fbs according to the resolution got
above.
4. call drmModeSetCrtc to switch the fb shown in LVDS to the new fb we
created.
5. At this time, remember the line stride setting in dc which connects
with LVDS is calculated according to the 1080p resolution. So finally we
got a corrupt display because we're showing a 1366x768 fb but with
1080p's line stride.
Hope I explained this clear. Try this test application if you still have
problems:
https://github.com/dvdhrm/docs/blob/master/drm-howto/modeset-vsync.c
Mark
>
> Thierry
>
[Bug 60969] [r600g] Lockup while playing OpenGL games with HD6450
https://bugs.freedesktop.org/show_bug.cgi?id=60969 --- Comment #3 from Alex Deucher --- Created attachment 75046 --> https://bugs.freedesktop.org/attachment.cgi?id=75046=edit possible fix Does this patch help? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/b1b4b8ed/attachment.html>
[PATCH v3 2/7] drm/tegra: Add plane support
On 02/18/2013 02:40 PM, Thierry Reding wrote:
> On Mon, Feb 18, 2013 at 02:06:56PM +0800, Mark Zhang wrote:
>> On 02/14/2013 12:05 AM, Thierry Reding wrote:
>>> Add support for the B and C planes which support RGB and YUV pixel
>>> formats and can be used as overlays or hardware cursor. Currently
>>> only 32-bit RGBA pixel formats are advertised.
>>>
>>> Signed-off-by: Thierry Reding
>> [...]
>>> +static int tegra_dc_add_planes(struct drm_device *drm, struct tegra_dc *dc)
>>> +{
>>> + unsigned int i;
>>> + int err = 0;
>>> +
>>> + for (i = 0; i < 2; i++) {
>>> + struct tegra_plane *plane;
>>> +
>>> + plane = devm_kzalloc(drm->dev, sizeof(*plane), GFP_KERNEL);
>>
>> Using "devm_kzalloc" here seems like not a good idea. Everytime plane
>> disable or crtc disable, we should free "struct tegra_plane" which is
>> allocated here. But the memory which devm_kzalloc allocates is only
>> freed when the driver detach. This makes lots of memory can't be
>> recycled when the plane enable/disable frequently.
>
> Why would we want to do that? I don't think doing so would even work,
> since the planes are resources that need to be registered with the DRM
> core and therefore can't be allocated on-demand.
>
I'm wondering if we add power management codes in the future, the
crtc/plane will be disabled/enabled frequently, e.g: system going to
suspend state then resume.
> Thierry
>
[pull] tilcdc-next for 3.9
On 2013-02-18 14:35, Rob Clark wrote: > On Mon, Feb 18, 2013 at 7:32 AM, Tomi Valkeinen wrote: >> On 2013-02-18 14:26, Rob Clark wrote: >> >>> So I'm not going to get too hung up on supporting current DT bindings >>> in the future when we have something better. But I needed something >> >> I may be mistaken, but my understanding is that DT bindings are like >> kernel's userspace APIs. After they have been merged, they have to work >> in the future kernels also. > > and that probably *eventually* makes sense when dts files are kicked > out of the kernel. For now, it doesn't really seem useful, unlike > maintaining compatibility for userspace ABI's. Why does that matter? Afaik, the dts files are in the kernel for convenience, and as examples. You can as well have the DT data in your bootloader. Or has there been a clear decision that while the dts files are in the kernel, they are considered unstable? Tomi
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #6 from Alexandre Demers --- (In reply to comment #5) > (In reply to comment #4) > > bisected and first bad commit is: 8696e33f06b0c52195152cc6a0e3d52233f486c1 > > commit 8696e33f06b0c52195152cc6a0e3d52233f486c1 > > Author: Alex Deucher > > Date: Thu Dec 13 18:57:07 2012 -0500 > > > > drm/radeon: bump version for CS ioctl support for async DMA > > > > Signed-off-by: Alex Deucher > > That just enables the use of DMA by the 3D driver, so the issue is in mesa. > This looks like a duplicate of bug 60236. You are right, that's what I thought about the bad identified commit. I don't have the same symptoms as in bug 60236, but I'll have a look anyway. Otherwise, I'll use kernel 3.8-rc7 and I'll bisect mesa to track the bug down. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/65831fb3/attachment.html>
[pull] tilcdc-next for 3.9
On 2013-02-18 14:26, Rob Clark wrote: > So I'm not going to get too hung up on supporting current DT bindings > in the future when we have something better. But I needed something I may be mistaken, but my understanding is that DT bindings are like kernel's userspace APIs. After they have been merged, they have to work in the future kernels also. Tomi
[PATCH v3 3/7] drm/tegra: Implement .mode_set_base()
On 02/18/2013 02:17 PM, Mark Zhang wrote:
> On 02/14/2013 12:05 AM, Thierry Reding wrote:
>> The sequence for replacing the scanout buffer is much shorter than a
>> full mode change operation so implementing this callback considerably
>> speeds up cases where only a new framebuffer is to be scanned out.
>>
>> Signed-off-by: Thierry Reding
>> ---
>> Changes in v3:
>> - split DC_CMD_STATE_CONTROL writes
>>
>> drivers/gpu/drm/tegra/dc.c | 31 +++
>> 1 file changed, 31 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
>> index 8f97b1c..cc4c85e 100644
>> --- a/drivers/gpu/drm/tegra/dc.c
>> +++ b/drivers/gpu/drm/tegra/dc.c
>> @@ -114,6 +114,27 @@ static int tegra_dc_add_planes(struct drm_device *drm,
>> struct tegra_dc *dc)
>> return 0;
>> }
>>
>> +static int tegra_dc_set_base(struct tegra_dc *dc, int x, int y,
>> + struct tegra_framebuffer *fb)
>> +{
>> +unsigned long value;
>> +
>> +tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
>> +
>> +value = fb->base.offsets[0] + y * fb->base.pitches[0] +
>> +x * fb->base.bits_per_pixel / 8;
>> +
>> +tegra_dc_writel(dc, fb->obj->paddr + value, DC_WINBUF_START_ADDR);
>> +
>> +value = GENERAL_UPDATE | WIN_A_UPDATE;
>> +tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
>> +
>> +value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
>> +tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
>> +
>> +return 0;
>> +}
>
> Again, what do you think about the "line stride" problem I mentioned:
>
> http://lists.freedesktop.org/archives/dri-devel/2013-January/033561.html
>
> Don't get me wrong that I also don't want to add a line stride update
> here because that doesn't make sense. It's just a workaround. But we
> need to find a way to make multi-head page flip working.
Sorry, it's not "multi-head page flip", it should be "multi-head fb
change". For example, if LVDS & HDMI are connected, I can create 4 fbs
for them(every is double-buffered) and call drmModeSetCrtc to switch 2
fbs of LVDS & HDMI to show something.
Mark
>
> Mark
>> +
>> static const struct drm_crtc_funcs tegra_crtc_funcs = {
>> .set_config = drm_crtc_helper_set_config,
>> .destroy = drm_crtc_cleanup,
>> @@ -416,6 +437,15 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
>> return 0;
>> }
>>
>> +static int tegra_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
>> +struct drm_framebuffer *old_fb)
>> +{
>> +struct tegra_framebuffer *fb = to_tegra_fb(crtc->fb);
>> +struct tegra_dc *dc = to_tegra_dc(crtc);
>> +
>> +return tegra_dc_set_base(dc, x, y, fb);
>> +}
>> +
>> static void tegra_crtc_prepare(struct drm_crtc *crtc)
>> {
>> struct tegra_dc *dc = to_tegra_dc(crtc);
>> @@ -495,6 +525,7 @@ static const struct drm_crtc_helper_funcs
>> tegra_crtc_helper_funcs = {
>> .disable = tegra_crtc_disable,
>> .mode_fixup = tegra_crtc_mode_fixup,
>> .mode_set = tegra_crtc_mode_set,
>> +.mode_set_base = tegra_crtc_mode_set_base,
>> .prepare = tegra_crtc_prepare,
>> .commit = tegra_crtc_commit,
>> .load_lut = tegra_crtc_load_lut,
>>
[PATCH v3 3/7] drm/tegra: Implement .mode_set_base()
On 02/14/2013 12:05 AM, Thierry Reding wrote:
> The sequence for replacing the scanout buffer is much shorter than a
> full mode change operation so implementing this callback considerably
> speeds up cases where only a new framebuffer is to be scanned out.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v3:
> - split DC_CMD_STATE_CONTROL writes
>
> drivers/gpu/drm/tegra/dc.c | 31 +++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> index 8f97b1c..cc4c85e 100644
> --- a/drivers/gpu/drm/tegra/dc.c
> +++ b/drivers/gpu/drm/tegra/dc.c
> @@ -114,6 +114,27 @@ static int tegra_dc_add_planes(struct drm_device *drm,
> struct tegra_dc *dc)
> return 0;
> }
>
> +static int tegra_dc_set_base(struct tegra_dc *dc, int x, int y,
> + struct tegra_framebuffer *fb)
> +{
> + unsigned long value;
> +
> + tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
> +
> + value = fb->base.offsets[0] + y * fb->base.pitches[0] +
> + x * fb->base.bits_per_pixel / 8;
> +
> + tegra_dc_writel(dc, fb->obj->paddr + value, DC_WINBUF_START_ADDR);
> +
> + value = GENERAL_UPDATE | WIN_A_UPDATE;
> + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> +
> + value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
> + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> +
> + return 0;
> +}
Again, what do you think about the "line stride" problem I mentioned:
http://lists.freedesktop.org/archives/dri-devel/2013-January/033561.html
Don't get me wrong that I also don't want to add a line stride update
here because that doesn't make sense. It's just a workaround. But we
need to find a way to make multi-head page flip working.
Mark
> +
> static const struct drm_crtc_funcs tegra_crtc_funcs = {
> .set_config = drm_crtc_helper_set_config,
> .destroy = drm_crtc_cleanup,
> @@ -416,6 +437,15 @@ static int tegra_crtc_mode_set(struct drm_crtc *crtc,
> return 0;
> }
>
> +static int tegra_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
> + struct drm_framebuffer *old_fb)
> +{
> + struct tegra_framebuffer *fb = to_tegra_fb(crtc->fb);
> + struct tegra_dc *dc = to_tegra_dc(crtc);
> +
> + return tegra_dc_set_base(dc, x, y, fb);
> +}
> +
> static void tegra_crtc_prepare(struct drm_crtc *crtc)
> {
> struct tegra_dc *dc = to_tegra_dc(crtc);
> @@ -495,6 +525,7 @@ static const struct drm_crtc_helper_funcs
> tegra_crtc_helper_funcs = {
> .disable = tegra_crtc_disable,
> .mode_fixup = tegra_crtc_mode_fixup,
> .mode_set = tegra_crtc_mode_set,
> + .mode_set_base = tegra_crtc_mode_set_base,
> .prepare = tegra_crtc_prepare,
> .commit = tegra_crtc_commit,
> .load_lut = tegra_crtc_load_lut,
>
[PATCH v3 2/7] drm/tegra: Add plane support
On 02/14/2013 12:05 AM, Thierry Reding wrote:
> Add support for the B and C planes which support RGB and YUV pixel
> formats and can be used as overlays or hardware cursor. Currently
> only 32-bit RGBA pixel formats are advertised.
>
> Signed-off-by: Thierry Reding
[...]
> +static int tegra_dc_add_planes(struct drm_device *drm, struct tegra_dc *dc)
> +{
> + unsigned int i;
> + int err = 0;
> +
> + for (i = 0; i < 2; i++) {
> + struct tegra_plane *plane;
> +
> + plane = devm_kzalloc(drm->dev, sizeof(*plane), GFP_KERNEL);
Using "devm_kzalloc" here seems like not a good idea. Everytime plane
disable or crtc disable, we should free "struct tegra_plane" which is
allocated here. But the memory which devm_kzalloc allocates is only
freed when the driver detach. This makes lots of memory can't be
recycled when the plane enable/disable frequently.
> + if (!plane)
> + return -ENOMEM;
> +
> + plane->index = 1 + i;
> +
> + err = drm_plane_init(drm, >base, 1 << dc->pipe,
> + _plane_funcs, plane_formats,
> + ARRAY_SIZE(plane_formats), false);
> + if (err < 0)
> + return err;
> + }
> +
> + return 0;
> +}
> +
> static const struct drm_crtc_funcs tegra_crtc_funcs = {
> .set_config = drm_crtc_helper_set_config,
> .destroy = drm_crtc_cleanup,
> };
>
> -static void tegra_crtc_dpms(struct drm_crtc *crtc, int mode)
> +static void tegra_crtc_disable(struct drm_crtc *crtc)
> {
> + struct drm_device *drm = crtc->dev;
> + struct drm_plane *plane;
> +
> + list_for_each_entry(plane, >mode_config.plane_list, head) {
> + if (plane->crtc == crtc) {
> + tegra_plane_disable(plane);
> + plane->crtc = NULL;
> +
> + if (plane->fb) {
> + drm_framebuffer_unreference(plane->fb);
> + plane->fb = NULL;
> + }
> + }
> + }
If what I mentioned above(about using devm_kzalloc to allocate "struct
tegra_plane") is correct, we need to free "struct tegra_plane" here.
> }
>
> static bool tegra_crtc_mode_fixup(struct drm_crtc *crtc,
> @@ -46,10 +144,11 @@ static bool tegra_crtc_mode_fixup(struct drm_crtc *crtc,
> return true;
> }
>
[...]
>
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 Alex Deucher changed: What|Removed |Added Summary|(bisect |Corruption with DMA ring on |8696e33f06b0c52195152cc6a0e |cayman |3d52233f486c1) Kernel | |3.8-rc7 breaks rendering on | |Radeon (confirmed on| |Cayman) | Product|DRI |Mesa Component|DRM/Radeon |Drivers/Gallium/r600 --- Comment #5 from Alex Deucher --- (In reply to comment #4) > bisected and first bad commit is: 8696e33f06b0c52195152cc6a0e3d52233f486c1 > commit 8696e33f06b0c52195152cc6a0e3d52233f486c1 > Author: Alex Deucher > Date: Thu Dec 13 18:57:07 2012 -0500 > > drm/radeon: bump version for CS ioctl support for async DMA > > Signed-off-by: Alex Deucher That just enables the use of DMA by the 3D driver, so the issue is in mesa. This looks like a duplicate of bug 60236. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/10d8a84d/attachment.html>
[PATCH] omapdrm: Make fixed resolution panels work
On Thursday 14 February 2013 09:24 PM, Rob Clark wrote:
> On Thu, Feb 14, 2013 at 6:52 AM, Archit Taneja wrote:
>> The omapdrm driver requires omapdss panel drivers to expose ops like detect,
>> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI,
>> DSI
>> and SDI drivers. At some places, there are no checks to see if the panel
>> driver
>> has these ops or not, and that leads to a crash.
>>
>> The following things are done to make fixed panels work:
>>
>> - The omap_connector's detect function is modified such that it considers
>> panel
>>types which are generally fixed panels as always connected(provided the
>> panel
>>driver doesn't have a detect op). Hence, the connector corresponding to
>> these
>>panels is always in a 'connected' state.
>>
>> - If a panel driver doesn't have a check_timings op, assume that it supports
>> the
>>mode passed to omap_connector_mode_valid(the 'mode_valid' drm helper
>> function)
>>
>> - The function omap_encoder_update shouldn't really do anything for fixed
>>resolution panels, make sure that it calls set_timings only if the panel
>>driver has one.
>>
>> I tested this with picodlp on a OMAP4 sdp board. I couldn't get any other
>> working boards with fixed DPI panels. I could try the DSI video mode panel
>> on an OMAP5 sevm, but that will require me to patch a lot of things to get
>> omap5 dss work with DT. I can try if needed.
>>
>> Signed-off-by: Archit Taneja
>> ---
>> drivers/staging/omapdrm/omap_connector.c | 10 --
>> drivers/staging/omapdrm/omap_encoder.c |6 --
>> 2 files changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/staging/omapdrm/omap_connector.c
>> b/drivers/staging/omapdrm/omap_connector.c
>> index 4cc9ee7..839c6e4 100644
>> --- a/drivers/staging/omapdrm/omap_connector.c
>> +++ b/drivers/staging/omapdrm/omap_connector.c
>> @@ -110,6 +110,11 @@ static enum drm_connector_status omap_connector_detect(
>> ret = connector_status_connected;
>> else
>> ret = connector_status_disconnected;
>> + } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
>> + dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
>> + dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
>> + dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
>> + ret = connector_status_connected;
>
> hmm, why not just have a default detect fxn for panel drivers which
> always returns true? Seems a bit cleaner.. otherwise, I guess we
> could just change omap_connector so that if dssdev->detect is null,
> assume always connected. Seems maybe a slightly better way since
> currently omap_connector doesn't really know too much about different
> sorts of panels. But I'm not too picky if that is a big pain because
> we probably end up changing all this as CFP starts coming into
> existence.
>
> Same goes for check_timings/set_timings.. it seems a bit cleaner just
> to have default fxns in the panel drivers that do-the-right-thing,
> although I suppose it might be a bit more convenient for out-of-tree
> panel drivers to just assume fixed panel if these fxns are null.
Maybe having default functions in omapdss might be a better idea. There
is an option of adding default functions in omap_dss_register_driver()
(drivers/video/omap2/dss/core.c).
Tomi, do you think it's fine to add some more default panel driver funcs?
Archit
>
> BR,
> -R
>
>> } else {
>> ret = connector_status_unknown;
>> }
>> @@ -189,12 +194,13 @@ static int omap_connector_mode_valid(struct
>> drm_connector *connector,
>> struct omap_video_timings timings = {0};
>> struct drm_device *dev = connector->dev;
>> struct drm_display_mode *new_mode;
>> - int ret = MODE_BAD;
>> + int r, ret = MODE_BAD;
>>
>> copy_timings_drm_to_omap(, mode);
>> mode->vrefresh = drm_mode_vrefresh(mode);
>>
>> - if (!dssdrv->check_timings(dssdev, )) {
>> + r = dssdrv->check_timings ? dssdrv->check_timings(dssdev, )
>> : 0;
>> + if (!r) {
>> /* check if vrefresh is still valid */
>> new_mode = drm_mode_duplicate(dev, mode);
>> new_mode->clock = timings.pixel_clock;
>> diff --git a/drivers/staging/omapdrm/omap_encoder.c
>> b/drivers/staging/omapdrm/omap_encoder.c
>> index e053160..871af12e 100644
>> --- a/drivers/staging/omapdrm/omap_encoder.c
>> +++ b/drivers/staging/omapdrm/omap_encoder.c
>> @@ -128,13 +128,15 @@ int omap_encoder_update(struct drm_encoder *encoder,
>>
>> dssdev->output->manager = mgr;
>>
>> - ret = dssdrv->check_timings(dssdev, timings);
>> + ret = dssdrv->check_timings ?
>> + dssdrv->check_timings(dssdev, timings) : 0;
>> if (ret) {
>> dev_err(dev->dev, "could not set timings: %d\n", ret);
>> return
[pull] tilcdc-next for 3.9
On 2013-02-18 12:03, Daniel Vetter wrote: > On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen wrote: >> But my main concern for this series is still that it creates custom >> panel stuff, and adds DT bindings for them. Which means we need to >> support those custom DT bindings in the future, even though it's quite >> sure that CDF should be used also for this driver, changing the bindings. > > I'm confused a bit, but shouldn't the DT bindings and CDF be rather > orthogonal? Of course for ARM board support we need to have DT binding > tables in the kernel to match up hw with the drivers, but I've thought > it should be pretty much irrelevant which driver is hooking up to a > given dt binding ... Yes, you're right, DT bindings should describe the HW, no matter what the software looks like. I was a bit unclear. Perhaps I should rephrase my main concern to: the DT bindings in this series does not describe the hardware properly and in enough detail. The bindings work for now, but a more sophisticated driver needs more information about the HW. For example, looking at the first patch, I see DT nodes for the LCDC and the dvicape, but nothing describes the connection between these two. And looking at the third patch, there's a DT node for HDMI, using compatible = "tilcdc,slave". Again, no connection is described, and also "tilcdc,slave" doesn't even sound like any hardware device, but more like a software construct for this particular driver. Those are just off the top of my head. These things are usually quite difficult to find out until you actually implement the code. Tomi
WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242
Hi, we have a report of WARNING from 3.7.6 in nouveau at drivers/gpu/drm/nouveau/core/core/mm.c:242 here: https://bugzilla.novell.com/show_bug.cgi?id=802347#c11 There is an order 4 allocation failure in nouveau_drm_open -> nouveau_vm_create, i.e. this one failed: vm->pgt = kcalloc(vm->lpde - vm->fpde + 1, sizeof(*vm->pgt), GFP_KERNEL); Then, on the error path in still in nouveau_drm_open, it is followed by a call to nouveau_cli_destroy. But that one calls nouveau_vm_ref -> nouveau_mm_fini -> nouveau_vm_del -> nouveau_mm_fini which triggers the warning. Any ideas? thanks, -- js suse labs
[pull] tilcdc-next for 3.9
On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen wrote: > But my main concern for this series is still that it creates custom > panel stuff, and adds DT bindings for them. Which means we need to > support those custom DT bindings in the future, even though it's quite > sure that CDF should be used also for this driver, changing the bindings. I'm confused a bit, but shouldn't the DT bindings and CDF be rather orthogonal? Of course for ARM board support we need to have DT binding tables in the kernel to match up hw with the drivers, but I've thought it should be pretty much irrelevant which driver is hooking up to a given dt binding ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[pull] tilcdc-next for 3.9
On 2013-02-18 01:02, Rob Clark wrote: > Hi Dave, > > Here is pull request for tilcdc drm driver.. it also includes a > handful of dependent patches from me, plus a couple fixes from Daniel > Vetter which haven't showed up yet in drm-next. Why is the TFP410 driver integrated into the tilcdc, but the TDA998x is a generic driver? I think the DT bindings do not match the DT guidelines. For example, compatible = "tilcdc,slave" should be "ti,tilcdc,slave". And TI specific properties should also be prepended with "ti,". Who is going to maintain this now that you're no longer in TI? I presume you may do some small stuff, but I think this driver needs quite a lot of further development in the future. But my main concern for this series is still that it creates custom panel stuff, and adds DT bindings for them. Which means we need to support those custom DT bindings in the future, even though it's quite sure that CDF should be used also for this driver, changing the bindings. Tomi
[GMA500] Valid VCO frequency range on GMA500 platform?
Patrik Jakobsson wrote: > I've sent in a patch for this: > http://lists.freedesktop.org/archives/dri-devel/2013-February/034990.html > it is slightly different to what I proposed earlier. Would be nice if you > could > give it a spin and report back. Seems to be ok. Tested-by:
[PATCH] omapdrm: Make fixed resolution panels work
On 2013-02-18 09:23, Archit Taneja wrote:
>>> diff --git a/drivers/staging/omapdrm/omap_connector.c
>>> b/drivers/staging/omapdrm/omap_connector.c
>>> index 4cc9ee7..839c6e4 100644
>>> --- a/drivers/staging/omapdrm/omap_connector.c
>>> +++ b/drivers/staging/omapdrm/omap_connector.c
>>> @@ -110,6 +110,11 @@ static enum drm_connector_status
>>> omap_connector_detect(
>>> ret = connector_status_connected;
>>> else
>>> ret = connector_status_disconnected;
>>> + } else if (dssdev->type == OMAP_DISPLAY_TYPE_DPI ||
>>> + dssdev->type == OMAP_DISPLAY_TYPE_DBI ||
>>> + dssdev->type == OMAP_DISPLAY_TYPE_SDI ||
>>> + dssdev->type == OMAP_DISPLAY_TYPE_DSI) {
>>> + ret = connector_status_connected;
>>
>> hmm, why not just have a default detect fxn for panel drivers which
>> always returns true? Seems a bit cleaner.. otherwise, I guess we
>> could just change omap_connector so that if dssdev->detect is null,
>> assume always connected. Seems maybe a slightly better way since
>> currently omap_connector doesn't really know too much about different
>> sorts of panels. But I'm not too picky if that is a big pain because
>> we probably end up changing all this as CFP starts coming into
>> existence.
>>
>> Same goes for check_timings/set_timings.. it seems a bit cleaner just
>> to have default fxns in the panel drivers that do-the-right-thing,
>> although I suppose it might be a bit more convenient for out-of-tree
>> panel drivers to just assume fixed panel if these fxns are null.
Yeah, I can't make my mind about null pointer. It's nice to inform with
a null pointer that the panel doesn't support the given operation, or
that it doesn't make sense, but handling the null value makes the code a
bit complex.
For example, our VENC driver doesn't know if there's a TV connected or
not, so neither true or false as connect return value makes sense there.
Or, for a DSI command mode panel, set_timings doesn't really make much
sense.
> Maybe having default functions in omapdss might be a better idea. There
> is an option of adding default functions in omap_dss_register_driver()
> (drivers/video/omap2/dss/core.c).
>
> Tomi, do you think it's fine to add some more default panel driver funcs?
We can add default funcs. However, adding them in
omap_dss_register_driver is not so nice, as it makes the omap_dss_driver
(which is essentially an "ops" struct) non-constable. Instead, we should
move the setting of the default funcs to the drivers.
If I'm not mistaken, we could manage that with a helper macro. Assigning
a value to the same field of a struct should be ok by the compiler, and
should cause only the last assignment to be taken into use. So:
static struct foo zab = {
.bar = 123, /* ignored */
.bar = 234, /* used */
};
And so we could have:
static struct omap_dss_driver my_panel_driver = {
OMAPDSS_DEFAULT_PANEL_OPS, /* macro for default ops */
.enable = my_panel_enable,
/* ... */
};
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/9878bfb7/attachment.pgp>
[PATCH 0/9] System Framebuffer Bus (sysfb)
>> I'm unsure if I like this or not, and I don't see why its greatly more >> useful than the interface we have now. > > This interface at least solves the problem with having vesafb, > uvesafb, vgacon, vga16fb, efifb, dvbe, defi and all other similar > drivers from accessing the system framebuffer simultaneously. And > provides a sane way of registering devices and drivers for it. But do we have the problem now? or is it more when we get dvbe/defi? Also vgacon is kinda different since fbcon kicks it off, not a driver, > It also provides a way for real drivers to unload these drivers > (sysfb_claim()) instead of using remove_conflicting_framebuffers(), > which is horribly broken and has lots of race-conditions. (I tried > fixing the fbdev refcounting/locking, but every time I tried, some > driver broke because they worked around the bug. And fixing all > drivers is just a lot of work...). > And remove_conflicting_framebuffers() also doesn't work with > vgacon/etc. which do _not_ use fbdev. but vgacon is always kicked off by fbcon, so I'm not sure what etc there is apart from it. I'd like to make fbcon a bool as well, so we don't have to deal with it appearing after the drivers. > We could simplify this approach by removing the bus and just providing > the platform-device for vbefb/etc. from the arch-code. But I thought > the bus-infrastructure allows nice rebinding of drivers if we need it > at almost no cost. I suspect a platform device is the right answer, since vesafb is that, I think we should resolve vesafb vs dvbe by just making them not config compatible, and dvbe vs defi seems like the same solution as vesafb vs efi. I'm just trying to work out what exactly you are fixing here, the problems we have now don't seem to be addressed by this, if it addresses future problems then it needs to be more upfront. >> It doesn't solve the main problem with the current interface, which is >> that if somebody opens has vesafb /dev/fb0, mmaps it, and modprobes a >> real driver, things will fail either miserably or crappy from a users >> pov. >> >> The internal reference counts stop vesafb from unloading due to the >> mmaps, then i915 loads anyways and one bashes the other, or we fix so >> i915 doesn't load and the user gets fail. > > It's not the mmap that prevents vesafb from unloading, it's the > open-file instead. If a user does open(), mmap(), close(), they can > still access the mapped memory but vesafb might get unloaded (this is, > in fact, used by several user-space apps). So it's not about whether > vesafb is still loaded, but rather what to do about users which have > vesafb mmaped but don't expect it to go away. In theory we'd have to do like GEM/TTM, and unmap_mapping_range for all the open fd's mmaps and just point them to map something useless or even just return -EFAULT, because really userspace needs to be told something :-) > So what do you propose to detect this case? Keep track of every user > who mmap's vesafb? How can we detect when they unmap the memory? I > think the only way to detect this is to wait for the pages' > "mmap-count" to drop to zero and then release the memory. > > So lets compare this to other subsystems. If you unlink a file that is > still mmaped, I think the file isn't removed from memory until the > last user unmaps it. However, the memory-mapping is 'dead' in that it > doesn't have any effect on real files. > So why not copy that behavior to framebuffers? When a real DRM driver > is loaded, simply reserve the VBE framebuffer-memory in VMEM until the > last user unmaps it. But mark it 'dead' so it doesn't really belong to > a _real_ framebuffer. > So any access to the mmap'ed framebuffers will be a no-op as it just > modifies 'dead' framebuffers. > > Another idea is copying the VBE framebuffer into the DRM driver so all > old memory-maps are still valid. However, this prevents us from doing > any kind of mode-setting in the DRM driver until the last fbdev user > is gone (because there is no way to notify fbdev users of > mode-setting). > So in this case we are also stuck in a situation where we need to wait > for all users to unmap their framebuffers. It all kinda sucks, from the problems we've had previously with things like plymouth racing, (which all this will make much worse if we have kms vbe devices) really what we want the system to do is give the user the proper driver asap, stalling waiting for endless other things to let go is just going to screw users, so I think we need to be as upfront and brutal in the userspace interface if people mmaping vesafb or efifb or any generic interface then expect to load a real driver, then their old apps get killed. > Any comments? If you have a plan on how it is supposed to work (or > what the user-space semantics should be), tell me and I will try to > make it work. > I still think a central system-framebuffer registry like sysfb-bus > (which does _not_ explicitly depend on fbdev) is the way to go. > Whether it's a
[pull] tilcdc-next for 3.9
On Mon, Feb 18, 2013 at 7:40 AM, Tomi Valkeinen wrote: > On 2013-02-18 14:35, Rob Clark wrote: >> On Mon, Feb 18, 2013 at 7:32 AM, Tomi Valkeinen wrote: >>> On 2013-02-18 14:26, Rob Clark wrote: >>> So I'm not going to get too hung up on supporting current DT bindings in the future when we have something better. But I needed something >>> >>> I may be mistaken, but my understanding is that DT bindings are like >>> kernel's userspace APIs. After they have been merged, they have to work >>> in the future kernels also. >> >> and that probably *eventually* makes sense when dts files are kicked >> out of the kernel. For now, it doesn't really seem useful, unlike >> maintaining compatibility for userspace ABI's. > > Why does that matter? Afaik, the dts files are in the kernel for > convenience, and as examples. You can as well have the DT data in your > bootloader. > > Or has there been a clear decision that while the dts files are in the > kernel, they are considered unstable? I'm not sure.. I'm just going by what I've seen people actually using for the boards which this driver works on currently. I haven't seen anyone embed DT data in bootloader.. either they are appending it to the kernel image or keeping it as a separate file generated from kernel tree. BR, -R > Tomi >
[PATCH v3 0/7] drm/tegra: Miscellaneous enhancements
On Mon, Feb 18, 2013 at 03:42:39PM +0800, Mark Zhang wrote: > Hi Thierry, > > Which version is this patch set based on? I tried to apply it on > linux-next 0206 & tot 0215 but failed: This was based on next-20130213. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/d483d219/attachment.pgp>
[PATCH v3 3/7] drm/tegra: Implement .mode_set_base()
On Mon, Feb 18, 2013 at 03:06:10PM +0800, Mark Zhang wrote:
> On 02/18/2013 02:48 PM, Thierry Reding wrote:
> > On Mon, Feb 18, 2013 at 02:17:53PM +0800, Mark Zhang wrote:
> >> On 02/14/2013 12:05 AM, Thierry Reding wrote:
> >>> The sequence for replacing the scanout buffer is much shorter than a
> >>> full mode change operation so implementing this callback considerably
> >>> speeds up cases where only a new framebuffer is to be scanned out.
> >>>
> >>> Signed-off-by: Thierry Reding
> >>> ---
> >>> Changes in v3:
> >>> - split DC_CMD_STATE_CONTROL writes
> >>>
> >>> drivers/gpu/drm/tegra/dc.c | 31 +++
> >>> 1 file changed, 31 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> >>> index 8f97b1c..cc4c85e 100644
> >>> --- a/drivers/gpu/drm/tegra/dc.c
> >>> +++ b/drivers/gpu/drm/tegra/dc.c
> >>> @@ -114,6 +114,27 @@ static int tegra_dc_add_planes(struct drm_device
> >>> *drm, struct tegra_dc *dc)
> >>> return 0;
> >>> }
> >>>
> >>> +static int tegra_dc_set_base(struct tegra_dc *dc, int x, int y,
> >>> + struct tegra_framebuffer *fb)
> >>> +{
> >>> + unsigned long value;
> >>> +
> >>> + tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
> >>> +
> >>> + value = fb->base.offsets[0] + y * fb->base.pitches[0] +
> >>> + x * fb->base.bits_per_pixel / 8;
> >>> +
> >>> + tegra_dc_writel(dc, fb->obj->paddr + value, DC_WINBUF_START_ADDR);
> >>> +
> >>> + value = GENERAL_UPDATE | WIN_A_UPDATE;
> >>> + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> >>> +
> >>> + value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
> >>> + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> >>> +
> >>> + return 0;
> >>> +}
> >>
> >> Again, what do you think about the "line stride" problem I mentioned:
> >>
> >> http://lists.freedesktop.org/archives/dri-devel/2013-January/033561.html
> >>
> >> Don't get me wrong that I also don't want to add a line stride update
> >> here because that doesn't make sense. It's just a workaround. But we
> >> need to find a way to make multi-head page flip working.
> >
> > I'm not sure that it's something we need to support. .mode_set_base() is
> > explicitly used only for cases where the framebuffer configuration
> > doesn't change. That is, only in cases where the only thing that changes
> > is the physical address of the framebuffer to be displayed.
> >
> > The current case where one framebuffer is used as scanout for both
> > outputs isn't something that page-flipping can support. Page-flipping is
> > always per-CRTC because typically each CRTC would run at a different
> > frequency (or even if both ran at the same frequency the VBLANK is very
> > unlikely to coincide anyway).
> >
> > So an application that wants to support page-flipping on two outputs
> > also needs to take care to set them up with different framebuffers, in
> > which case what you're describing here can't really happen.
>
> Yes, the userspace application needs to setup different framebuffers for
> different crtcs. So if LVDS & HDMI are connected, here is what the
> application does:
>
> 1. drm reports that 2 connectors: LVDS & HDMI are present in the system
> 2. The resolution of them are: 1366x768 & 1080p
> 3. Userspace application allocates 2 fbs according to the resolution got
> above.
> 4. call drmModeSetCrtc to switch the fb shown in LVDS to the new fb we
> created.
> 5. At this time, remember the line stride setting in dc which connects
> with LVDS is calculated according to the 1080p resolution. So finally we
> got a corrupt display because we're showing a 1366x768 fb but with
> 1080p's line stride.
I don't see how the 1080p stride would still be relevant here. Setting
the LVDS to the new 1366x768 framebuffer should trigger a full modeset
and therefore set the stride to the value required by the new 1366x768
framebuffer.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/7e6a3642/attachment.pgp>
[PATCH 0/9] System Framebuffer Bus (sysfb)
> > This series tries to fix the mess with global system framebuffer access in > device drivers. Currently, architecture initialization sets the "screen_info" > object according to the system framebuffer that was detected during boot. The > device driver that can map VMEM first gets access to it. There is no way to > give > a specific driver access to the device and no _proper_ way to revoke access > again. In fact, some drivers don't even check whether they mapped the VMEM > successfully, letting multiple drivers to access the system framebuffer at the > same time. I'm unsure if I like this or not, and I don't see why its greatly more useful than the interface we have now. It doesn't solve the main problem with the current interface, which is that if somebody opens has vesafb /dev/fb0, mmaps it, and modprobes a real driver, things will fail either miserably or crappy from a users pov. The internal reference counts stop vesafb from unloading due to the mmaps, then i915 loads anyways and one bashes the other, or we fix so i915 doesn't load and the user gets fail. Dave.
[PATCH v3 2/7] drm/tegra: Add plane support
On Mon, Feb 18, 2013 at 02:55:04PM +0800, Mark Zhang wrote:
> On 02/18/2013 02:40 PM, Thierry Reding wrote:
> > On Mon, Feb 18, 2013 at 02:06:56PM +0800, Mark Zhang wrote:
> >> On 02/14/2013 12:05 AM, Thierry Reding wrote:
> >>> Add support for the B and C planes which support RGB and YUV pixel
> >>> formats and can be used as overlays or hardware cursor. Currently
> >>> only 32-bit RGBA pixel formats are advertised.
> >>>
> >>> Signed-off-by: Thierry Reding
> >> [...]
> >>> +static int tegra_dc_add_planes(struct drm_device *drm, struct tegra_dc
> >>> *dc)
> >>> +{
> >>> + unsigned int i;
> >>> + int err = 0;
> >>> +
> >>> + for (i = 0; i < 2; i++) {
> >>> + struct tegra_plane *plane;
> >>> +
> >>> + plane = devm_kzalloc(drm->dev, sizeof(*plane), GFP_KERNEL);
> >>
> >> Using "devm_kzalloc" here seems like not a good idea. Everytime plane
> >> disable or crtc disable, we should free "struct tegra_plane" which is
> >> allocated here. But the memory which devm_kzalloc allocates is only
> >> freed when the driver detach. This makes lots of memory can't be
> >> recycled when the plane enable/disable frequently.
> >
> > Why would we want to do that? I don't think doing so would even work,
> > since the planes are resources that need to be registered with the DRM
> > core and therefore can't be allocated on-demand.
> >
>
> I'm wondering if we add power management codes in the future, the
> crtc/plane will be disabled/enabled frequently, e.g: system going to
> suspend state then resume.
In that case it makes even less sense to allocate and deallocate the
plane every time around. However, any optimizations aside, the allocated
memory is passed into the core via drm_plane_init(), which registers
that plane with the given CRTC. So if we deallocate the memory when the
plane when it is disabled, we'd have to make sure to remove it from the
core as well. However that would also mean that it disappears from the
list of planes supported by the CRTC and therefore we wouldn't be able
to use it again.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/ced5735c/attachment.pgp>
[PATCH v3 3/7] drm/tegra: Implement .mode_set_base()
On Mon, Feb 18, 2013 at 02:17:53PM +0800, Mark Zhang wrote:
> On 02/14/2013 12:05 AM, Thierry Reding wrote:
> > The sequence for replacing the scanout buffer is much shorter than a
> > full mode change operation so implementing this callback considerably
> > speeds up cases where only a new framebuffer is to be scanned out.
> >
> > Signed-off-by: Thierry Reding
> > ---
> > Changes in v3:
> > - split DC_CMD_STATE_CONTROL writes
> >
> > drivers/gpu/drm/tegra/dc.c | 31 +++
> > 1 file changed, 31 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> > index 8f97b1c..cc4c85e 100644
> > --- a/drivers/gpu/drm/tegra/dc.c
> > +++ b/drivers/gpu/drm/tegra/dc.c
> > @@ -114,6 +114,27 @@ static int tegra_dc_add_planes(struct drm_device *drm,
> > struct tegra_dc *dc)
> > return 0;
> > }
> >
> > +static int tegra_dc_set_base(struct tegra_dc *dc, int x, int y,
> > +struct tegra_framebuffer *fb)
> > +{
> > + unsigned long value;
> > +
> > + tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
> > +
> > + value = fb->base.offsets[0] + y * fb->base.pitches[0] +
> > + x * fb->base.bits_per_pixel / 8;
> > +
> > + tegra_dc_writel(dc, fb->obj->paddr + value, DC_WINBUF_START_ADDR);
> > +
> > + value = GENERAL_UPDATE | WIN_A_UPDATE;
> > + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> > +
> > + value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
> > + tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
> > +
> > + return 0;
> > +}
>
> Again, what do you think about the "line stride" problem I mentioned:
>
> http://lists.freedesktop.org/archives/dri-devel/2013-January/033561.html
>
> Don't get me wrong that I also don't want to add a line stride update
> here because that doesn't make sense. It's just a workaround. But we
> need to find a way to make multi-head page flip working.
I'm not sure that it's something we need to support. .mode_set_base() is
explicitly used only for cases where the framebuffer configuration
doesn't change. That is, only in cases where the only thing that changes
is the physical address of the framebuffer to be displayed.
The current case where one framebuffer is used as scanout for both
outputs isn't something that page-flipping can support. Page-flipping is
always per-CRTC because typically each CRTC would run at a different
frequency (or even if both ran at the same frequency the VBLANK is very
unlikely to coincide anyway).
So an application that wants to support page-flipping on two outputs
also needs to take care to set them up with different framebuffers, in
which case what you're describing here can't really happen.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/ef80737a/attachment.pgp>
[PATCH v3 2/7] drm/tegra: Add plane support
On Mon, Feb 18, 2013 at 02:06:56PM +0800, Mark Zhang wrote:
> On 02/14/2013 12:05 AM, Thierry Reding wrote:
> > Add support for the B and C planes which support RGB and YUV pixel
> > formats and can be used as overlays or hardware cursor. Currently
> > only 32-bit RGBA pixel formats are advertised.
> >
> > Signed-off-by: Thierry Reding
> [...]
> > +static int tegra_dc_add_planes(struct drm_device *drm, struct tegra_dc *dc)
> > +{
> > + unsigned int i;
> > + int err = 0;
> > +
> > + for (i = 0; i < 2; i++) {
> > + struct tegra_plane *plane;
> > +
> > + plane = devm_kzalloc(drm->dev, sizeof(*plane), GFP_KERNEL);
>
> Using "devm_kzalloc" here seems like not a good idea. Everytime plane
> disable or crtc disable, we should free "struct tegra_plane" which is
> allocated here. But the memory which devm_kzalloc allocates is only
> freed when the driver detach. This makes lots of memory can't be
> recycled when the plane enable/disable frequently.
Why would we want to do that? I don't think doing so would even work,
since the planes are resources that need to be registered with the DRM
core and therefore can't be allocated on-demand.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/6dfd1e1d/attachment.pgp>
[pull] tilcdc-next for 3.9
On Mon, Feb 18, 2013 at 7:32 AM, Tomi Valkeinen wrote: > On 2013-02-18 14:26, Rob Clark wrote: > >> So I'm not going to get too hung up on supporting current DT bindings >> in the future when we have something better. But I needed something > > I may be mistaken, but my understanding is that DT bindings are like > kernel's userspace APIs. After they have been merged, they have to work > in the future kernels also. and that probably *eventually* makes sense when dts files are kicked out of the kernel. For now, it doesn't really seem useful, unlike maintaining compatibility for userspace ABI's. BR, -R > Tomi >
[pull] tilcdc-next for 3.9
On Mon, Feb 18, 2013 at 5:03 AM, Daniel Vetter wrote: > On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen wrote: >> But my main concern for this series is still that it creates custom >> panel stuff, and adds DT bindings for them. Which means we need to >> support those custom DT bindings in the future, even though it's quite >> sure that CDF should be used also for this driver, changing the bindings. > > I'm confused a bit, but shouldn't the DT bindings and CDF be rather > orthogonal? Of course for ARM board support we need to have DT binding > tables in the kernel to match up hw with the drivers, but I've thought > it should be pretty much irrelevant which driver is hooking up to a > given dt binding ... I expect main thing that could/would change is who is the parent device.. well that and the 'compatible' string probably changes? BR, -R > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[pull] tilcdc-next for 3.9
On Mon, Feb 18, 2013 at 4:02 AM, Tomi Valkeinen wrote: > On 2013-02-18 01:02, Rob Clark wrote: >> Hi Dave, >> >> Here is pull request for tilcdc drm driver.. it also includes a >> handful of dependent patches from me, plus a couple fixes from Daniel >> Vetter which haven't showed up yet in drm-next. > > Why is the TFP410 driver integrated into the tilcdc, but the TDA998x is > a generic driver? the way we have tfp410 wired up (not using i2c) doesn't fit too nicely into the current drm i2c-encoder-slave mechanism.. something which I expect to be addressed with CDF > I think the DT bindings do not match the DT guidelines. For example, > compatible = "tilcdc,slave" should be "ti,tilcdc,slave". And TI specific > properties should also be prepended with "ti,". oh, ok, well I guess that is simple enough to change > Who is going to maintain this now that you're no longer in TI? I presume > you may do some small stuff, but I think this driver needs quite a lot > of further development in the future. I still have a beaglebone and some display "capes", but probably also someone from TI should get a bit familiar with this driver.. although the main changes I anticipate are CDF. I kind of think this driver should make a nice simple user for CDF because the display controller block is so simple. > But my main concern for this series is still that it creates custom > panel stuff, and adds DT bindings for them. Which means we need to > support those custom DT bindings in the future, even though it's quite > sure that CDF should be used also for this driver, changing the bindings. Well, I didn't actually add the dts file parts, because for the main user (beaglebone board), how the dts files are setup depends on whether you have the (still out of tree) "not-capebus" patch series. So I'm not going to get too hung up on supporting current DT bindings in the future when we have something better. But I needed something for now, because CDF doesn't exist yet. > Tomi >
[Bug 60802] (bisect 8696e33f06b0c52195152cc6a0e3d52233f486c1) Kernel 3.8-rc7 breaks rendering on Radeon (confirmed on Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=60802 Alexandre Demers changed: What|Removed |Added Summary|Kernel 3.8-rc7 breaks |(bisect |rendering on Radeon |8696e33f06b0c52195152cc6a0e |(confirmed on Cayman) |3d52233f486c1) Kernel ||3.8-rc7 breaks rendering on ||Radeon (confirmed on ||Cayman) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/e1bd1539/attachment.html>
[Bug 60802] Kernel 3.8-rc7 breaks rendering on Radeon (confirmed on Cayman)
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #4 from Alexandre Demers --- bisected and first bad commit is: 8696e33f06b0c52195152cc6a0e3d52233f486c1 commit 8696e33f06b0c52195152cc6a0e3d52233f486c1 Author: Alex Deucher Date: Thu Dec 13 18:57:07 2012 -0500 drm/radeon: bump version for CS ioctl support for async DMA Signed-off-by: Alex Deucher -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130218/4f292c30/attachment.html>
[PATCH 0/9] System Framebuffer Bus (sysfb)
Hi Dave On Sun, Feb 17, 2013 at 11:02 PM, Dave Airlie wrote: >> >> This series tries to fix the mess with global system framebuffer access in >> device drivers. Currently, architecture initialization sets the "screen_info" >> object according to the system framebuffer that was detected during boot. The >> device driver that can map VMEM first gets access to it. There is no way to >> give >> a specific driver access to the device and no _proper_ way to revoke access >> again. In fact, some drivers don't even check whether they mapped the VMEM >> successfully, letting multiple drivers to access the system framebuffer at >> the >> same time. > > I'm unsure if I like this or not, and I don't see why its greatly more > useful than the interface we have now. This interface at least solves the problem with having vesafb, uvesafb, vgacon, vga16fb, efifb, dvbe, defi and all other similar drivers from accessing the system framebuffer simultaneously. And provides a sane way of registering devices and drivers for it. It also provides a way for real drivers to unload these drivers (sysfb_claim()) instead of using remove_conflicting_framebuffers(), which is horribly broken and has lots of race-conditions. (I tried fixing the fbdev refcounting/locking, but every time I tried, some driver broke because they worked around the bug. And fixing all drivers is just a lot of work...). And remove_conflicting_framebuffers() also doesn't work with vgacon/etc. which do _not_ use fbdev. We could simplify this approach by removing the bus and just providing the platform-device for vbefb/etc. from the arch-code. But I thought the bus-infrastructure allows nice rebinding of drivers if we need it at almost no cost. You could even register an oops/panic-screen as driver there and switch to it if necessary. > It doesn't solve the main problem with the current interface, which is > that if somebody opens has vesafb /dev/fb0, mmaps it, and modprobes a > real driver, things will fail either miserably or crappy from a users > pov. > > The internal reference counts stop vesafb from unloading due to the > mmaps, then i915 loads anyways and one bashes the other, or we fix so > i915 doesn't load and the user gets fail. It's not the mmap that prevents vesafb from unloading, it's the open-file instead. If a user does open(), mmap(), close(), they can still access the mapped memory but vesafb might get unloaded (this is, in fact, used by several user-space apps). So it's not about whether vesafb is still loaded, but rather what to do about users which have vesafb mmaped but don't expect it to go away. So what do you propose to detect this case? Keep track of every user who mmap's vesafb? How can we detect when they unmap the memory? I think the only way to detect this is to wait for the pages' "mmap-count" to drop to zero and then release the memory. So lets compare this to other subsystems. If you unlink a file that is still mmaped, I think the file isn't removed from memory until the last user unmaps it. However, the memory-mapping is 'dead' in that it doesn't have any effect on real files. So why not copy that behavior to framebuffers? When a real DRM driver is loaded, simply reserve the VBE framebuffer-memory in VMEM until the last user unmaps it. But mark it 'dead' so it doesn't really belong to a _real_ framebuffer. So any access to the mmap'ed framebuffers will be a no-op as it just modifies 'dead' framebuffers. Another idea is copying the VBE framebuffer into the DRM driver so all old memory-maps are still valid. However, this prevents us from doing any kind of mode-setting in the DRM driver until the last fbdev user is gone (because there is no way to notify fbdev users of mode-setting). So in this case we are also stuck in a situation where we need to wait for all users to unmap their framebuffers. Any comments? If you have a plan on how it is supposed to work (or what the user-space semantics should be), tell me and I will try to make it work. I still think a central system-framebuffer registry like sysfb-bus (which does _not_ explicitly depend on fbdev) is the way to go. Whether it's a bus or not is just a matter of taste. I am willing to rework this. Thanks David
Re: [PATCH v3 3/7] drm/tegra: Implement .mode_set_base()
On 02/18/2013 03:20 PM, Thierry Reding wrote:
On Mon, Feb 18, 2013 at 03:06:10PM +0800, Mark Zhang wrote:
On 02/18/2013 02:48 PM, Thierry Reding wrote:
On Mon, Feb 18, 2013 at 02:17:53PM +0800, Mark Zhang wrote:
On 02/14/2013 12:05 AM, Thierry Reding wrote:
The sequence for replacing the scanout buffer is much shorter than a
full mode change operation so implementing this callback considerably
speeds up cases where only a new framebuffer is to be scanned out.
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
Changes in v3:
- split DC_CMD_STATE_CONTROL writes
drivers/gpu/drm/tegra/dc.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 8f97b1c..cc4c85e 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -114,6 +114,27 @@ static int tegra_dc_add_planes(struct drm_device
*drm, struct tegra_dc *dc)
return 0;
}
+static int tegra_dc_set_base(struct tegra_dc *dc, int x, int y,
+ struct tegra_framebuffer *fb)
+{
+ unsigned long value;
+
+ tegra_dc_writel(dc, WINDOW_A_SELECT, DC_CMD_DISPLAY_WINDOW_HEADER);
+
+ value = fb-base.offsets[0] + y * fb-base.pitches[0] +
+ x * fb-base.bits_per_pixel / 8;
+
+ tegra_dc_writel(dc, fb-obj-paddr + value, DC_WINBUF_START_ADDR);
+
+ value = GENERAL_UPDATE | WIN_A_UPDATE;
+ tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
+
+ value = GENERAL_ACT_REQ | WIN_A_ACT_REQ;
+ tegra_dc_writel(dc, value, DC_CMD_STATE_CONTROL);
+
+ return 0;
+}
Again, what do you think about the line stride problem I mentioned:
http://lists.freedesktop.org/archives/dri-devel/2013-January/033561.html
Don't get me wrong that I also don't want to add a line stride update
here because that doesn't make sense. It's just a workaround. But we
need to find a way to make multi-head page flip working.
I'm not sure that it's something we need to support. .mode_set_base() is
explicitly used only for cases where the framebuffer configuration
doesn't change. That is, only in cases where the only thing that changes
is the physical address of the framebuffer to be displayed.
The current case where one framebuffer is used as scanout for both
outputs isn't something that page-flipping can support. Page-flipping is
always per-CRTC because typically each CRTC would run at a different
frequency (or even if both ran at the same frequency the VBLANK is very
unlikely to coincide anyway).
So an application that wants to support page-flipping on two outputs
also needs to take care to set them up with different framebuffers, in
which case what you're describing here can't really happen.
Yes, the userspace application needs to setup different framebuffers for
different crtcs. So if LVDS HDMI are connected, here is what the
application does:
1. drm reports that 2 connectors: LVDS HDMI are present in the system
2. The resolution of them are: 1366x768 1080p
3. Userspace application allocates 2 fbs according to the resolution got
above.
4. call drmModeSetCrtc to switch the fb shown in LVDS to the new fb we
created.
5. At this time, remember the line stride setting in dc which connects
with LVDS is calculated according to the 1080p resolution. So finally we
got a corrupt display because we're showing a 1366x768 fb but with
1080p's line stride.
I don't see how the 1080p stride would still be relevant here. Setting
the LVDS to the new 1366x768 framebuffer should trigger a full modeset
and therefore set the stride to the value required by the new 1366x768
framebuffer.
Actually the dc which connects with LVDS doesn't know about 1080p
stuffs. All the video mode infos stored in this dc is still 1366x768(I
just checked the register values on my Tegra 30 cardhu). The dc just
scans 1366 pixels then jump to next line(based on the 1080p line stride
we set) and keep scanning.
So the drm crtc helper(I believe it's function:
drm_crtc_helper_set_config) finds out that video mode is not changed so
a fb_change while not full modeset is triggered.
I started to test this new series patch set just now. I'll let you know
whether the issue I described still exists.
Mark
Thierry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] tilcdc-next for 3.9
On 2013-02-18 01:02, Rob Clark wrote: Hi Dave, Here is pull request for tilcdc drm driver.. it also includes a handful of dependent patches from me, plus a couple fixes from Daniel Vetter which haven't showed up yet in drm-next. Why is the TFP410 driver integrated into the tilcdc, but the TDA998x is a generic driver? I think the DT bindings do not match the DT guidelines. For example, compatible = tilcdc,slave should be ti,tilcdc,slave. And TI specific properties should also be prepended with ti,. Who is going to maintain this now that you're no longer in TI? I presume you may do some small stuff, but I think this driver needs quite a lot of further development in the future. But my main concern for this series is still that it creates custom panel stuff, and adds DT bindings for them. Which means we need to support those custom DT bindings in the future, even though it's quite sure that CDF should be used also for this driver, changing the bindings. Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/7] drm/tegra: Implement .mode_set_base()
On 02/18/2013 04:40 PM, Mark Zhang wrote: On 02/18/2013 03:20 PM, Thierry Reding wrote: [...] Actually the dc which connects with LVDS doesn't know about 1080p stuffs. All the video mode infos stored in this dc is still 1366x768(I just checked the register values on my Tegra 30 cardhu). The dc just scans 1366 pixels then jump to next line(based on the 1080p line stride we set) and keep scanning. So the drm crtc helper(I believe it's function: drm_crtc_helper_set_config) finds out that video mode is not changed so a fb_change while not full modeset is triggered. I started to test this new series patch set just now. I'll let you know whether the issue I described still exists. Tested. This issue still exists. Mark Mark Thierry ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GMA500] Valid VCO frequency range on GMA500 platform?
Patrik Jakobsson wrote: I've sent in a patch for this: http://lists.freedesktop.org/archives/dri-devel/2013-February/034990.html it is slightly different to what I proposed earlier. Would be nice if you could give it a spin and report back. Seems to be ok. Tested-by: d.muel...@elsoft.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] tilcdc-next for 3.9
On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen to...@iki.fi wrote: But my main concern for this series is still that it creates custom panel stuff, and adds DT bindings for them. Which means we need to support those custom DT bindings in the future, even though it's quite sure that CDF should be used also for this driver, changing the bindings. I'm confused a bit, but shouldn't the DT bindings and CDF be rather orthogonal? Of course for ARM board support we need to have DT binding tables in the kernel to match up hw with the drivers, but I've thought it should be pretty much irrelevant which driver is hooking up to a given dt binding ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242
Hi, we have a report of WARNING from 3.7.6 in nouveau at drivers/gpu/drm/nouveau/core/core/mm.c:242 here: https://bugzilla.novell.com/show_bug.cgi?id=802347#c11 There is an order 4 allocation failure in nouveau_drm_open - nouveau_vm_create, i.e. this one failed: vm-pgt = kcalloc(vm-lpde - vm-fpde + 1, sizeof(*vm-pgt), GFP_KERNEL); Then, on the error path in still in nouveau_drm_open, it is followed by a call to nouveau_cli_destroy. But that one calls nouveau_vm_ref - nouveau_mm_fini - nouveau_vm_del - nouveau_mm_fini which triggers the warning. Any ideas? thanks, -- js suse labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] tilcdc-next for 3.9
On Mon, Feb 18, 2013 at 4:02 AM, Tomi Valkeinen to...@iki.fi wrote: On 2013-02-18 01:02, Rob Clark wrote: Hi Dave, Here is pull request for tilcdc drm driver.. it also includes a handful of dependent patches from me, plus a couple fixes from Daniel Vetter which haven't showed up yet in drm-next. Why is the TFP410 driver integrated into the tilcdc, but the TDA998x is a generic driver? the way we have tfp410 wired up (not using i2c) doesn't fit too nicely into the current drm i2c-encoder-slave mechanism.. something which I expect to be addressed with CDF I think the DT bindings do not match the DT guidelines. For example, compatible = tilcdc,slave should be ti,tilcdc,slave. And TI specific properties should also be prepended with ti,. oh, ok, well I guess that is simple enough to change Who is going to maintain this now that you're no longer in TI? I presume you may do some small stuff, but I think this driver needs quite a lot of further development in the future. I still have a beaglebone and some display capes, but probably also someone from TI should get a bit familiar with this driver.. although the main changes I anticipate are CDF. I kind of think this driver should make a nice simple user for CDF because the display controller block is so simple. But my main concern for this series is still that it creates custom panel stuff, and adds DT bindings for them. Which means we need to support those custom DT bindings in the future, even though it's quite sure that CDF should be used also for this driver, changing the bindings. Well, I didn't actually add the dts file parts, because for the main user (beaglebone board), how the dts files are setup depends on whether you have the (still out of tree) not-capebus patch series. So I'm not going to get too hung up on supporting current DT bindings in the future when we have something better. But I needed something for now, because CDF doesn't exist yet. Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] tilcdc-next for 3.9
On 2013-02-18 14:26, Rob Clark wrote: So I'm not going to get too hung up on supporting current DT bindings in the future when we have something better. But I needed something I may be mistaken, but my understanding is that DT bindings are like kernel's userspace APIs. After they have been merged, they have to work in the future kernels also. Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] tilcdc-next for 3.9
On Mon, Feb 18, 2013 at 5:03 AM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen to...@iki.fi wrote: But my main concern for this series is still that it creates custom panel stuff, and adds DT bindings for them. Which means we need to support those custom DT bindings in the future, even though it's quite sure that CDF should be used also for this driver, changing the bindings. I'm confused a bit, but shouldn't the DT bindings and CDF be rather orthogonal? Of course for ARM board support we need to have DT binding tables in the kernel to match up hw with the drivers, but I've thought it should be pretty much irrelevant which driver is hooking up to a given dt binding ... I expect main thing that could/would change is who is the parent device.. well that and the 'compatible' string probably changes? BR, -R -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] tilcdc-next for 3.9
On Mon, Feb 18, 2013 at 7:32 AM, Tomi Valkeinen to...@iki.fi wrote: On 2013-02-18 14:26, Rob Clark wrote: So I'm not going to get too hung up on supporting current DT bindings in the future when we have something better. But I needed something I may be mistaken, but my understanding is that DT bindings are like kernel's userspace APIs. After they have been merged, they have to work in the future kernels also. and that probably *eventually* makes sense when dts files are kicked out of the kernel. For now, it doesn't really seem useful, unlike maintaining compatibility for userspace ABI's. BR, -R Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] tilcdc-next for 3.9
On 2013-02-18 14:35, Rob Clark wrote: On Mon, Feb 18, 2013 at 7:32 AM, Tomi Valkeinen to...@iki.fi wrote: On 2013-02-18 14:26, Rob Clark wrote: So I'm not going to get too hung up on supporting current DT bindings in the future when we have something better. But I needed something I may be mistaken, but my understanding is that DT bindings are like kernel's userspace APIs. After they have been merged, they have to work in the future kernels also. and that probably *eventually* makes sense when dts files are kicked out of the kernel. For now, it doesn't really seem useful, unlike maintaining compatibility for userspace ABI's. Why does that matter? Afaik, the dts files are in the kernel for convenience, and as examples. You can as well have the DT data in your bootloader. Or has there been a clear decision that while the dts files are in the kernel, they are considered unstable? Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] libdrm/exynos: add test application for 2d gpu.
This patch adds library and test application for g2d gpu(fimg2d).
The fimg2d hardware is a 2D graphics accelerator(G2D) that
supports Bit Block Transfer(BitBLT).
The library includes the following primitive drawing operations:
.solid fill - This operation fills the given buffer with
the given color data.
.copy - This operation copies contents in source buffer to
destination buffer.
.copy_with_scale - This operation copies contents in source buffer
to destination buffer scaling up or down properly.
.blend - This operation blends contents in source buffer with
the ones in destination buffer.
And the above operations uses gem handle or user space address
allocated by malloc() as source or destination buffer.
And the test application includes just simple primitive drawing
tests with the above library.
And the guide to test is as the following,
#exynos_fimg2d_test -s connector_id@crtc_id:mode
With this above simple command, four primitive drawing operations
would be called step by step and also rendered on the output device
to the given connector and crtc id.
Signed-off-by: Inki Dae inki@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
configure.ac |1 +
exynos/Makefile.am|2 +-
exynos/exynos_drm.h | 52 +++
exynos/exynos_fimg2d.c| 630 +
exynos/fimg2d.h | 325 +
exynos/fimg2d_reg.h | 114 ++
tests/Makefile.am |4 +
tests/exynos/Makefile.am | 19 +
tests/exynos/exynos_fimg2d_test.c | 695 +
9 files changed, 1841 insertions(+), 1 deletions(-)
create mode 100644 exynos/exynos_fimg2d.c
create mode 100644 exynos/fimg2d.h
create mode 100644 exynos/fimg2d_reg.h
create mode 100644 tests/exynos/Makefile.am
create mode 100644 tests/exynos/exynos_fimg2d_test.c
diff --git a/configure.ac b/configure.ac
index e2e3466..2896f91 100644
--- a/configure.ac
+++ b/configure.ac
@@ -364,6 +364,7 @@ AC_CONFIG_FILES([
tests/kmstest/Makefile
tests/radeon/Makefile
tests/vbltest/Makefile
+ tests/exynos/Makefile
include/Makefile
include/drm/Makefile
man/Makefile
diff --git a/exynos/Makefile.am b/exynos/Makefile.am
index e782d34..539aea0 100644
--- a/exynos/Makefile.am
+++ b/exynos/Makefile.am
@@ -10,7 +10,7 @@ libdrm_exynos_ladir = $(libdir)
libdrm_exynos_la_LDFLAGS = -version-number 1:0:0 -no-undefined
libdrm_exynos_la_LIBADD = ../libdrm.la @PTHREADSTUBS_LIBS@
-libdrm_exynos_la_SOURCES = exynos_drm.c
+libdrm_exynos_la_SOURCES = exynos_drm.c exynos_fimg2d.c
libdrm_exynoscommonincludedir = ${includedir}/exynos
libdrm_exynoscommoninclude_HEADERS = exynos_drm.h
diff --git a/exynos/exynos_drm.h b/exynos/exynos_drm.h
index aa97b22..c3c6579 100644
--- a/exynos/exynos_drm.h
+++ b/exynos/exynos_drm.h
@@ -123,6 +123,46 @@ enum e_drm_exynos_gem_mem_type {
EXYNOS_BO_WC
};
+struct drm_exynos_g2d_get_ver {
+ __u32 major;
+ __u32 minor;
+};
+
+struct drm_exynos_g2d_cmd {
+ __u32 offset;
+ __u32 data;
+};
+
+enum drm_exynos_g2d_buf_type {
+ G2D_BUF_USERPTR = 1 31,
+};
+
+enum drm_exynos_g2d_event_type {
+ G2D_EVENT_NOT,
+ G2D_EVENT_NONSTOP,
+ G2D_EVENT_STOP, /* not yet */
+};
+
+struct drm_exynos_g2d_userptr {
+ unsigned long userptr;
+ unsigned long size;
+};
+
+struct drm_exynos_g2d_set_cmdlist {
+ __u64 cmd;
+ __u64 cmd_buf;
+ __u32 cmd_nr;
+ __u32 cmd_buf_nr;
+
+ /* for g2d event */
+ __u64 event_type;
+ __u64 user_data;
+};
+
+struct drm_exynos_g2d_exec {
+ __u64 async;
+};
+
#define DRM_EXYNOS_GEM_CREATE 0x00
#define DRM_EXYNOS_GEM_MAP_OFFSET 0x01
#define DRM_EXYNOS_GEM_MMAP0x02
@@ -130,6 +170,11 @@ enum e_drm_exynos_gem_mem_type {
#define DRM_EXYNOS_GEM_GET 0x04
#define DRM_EXYNOS_VIDI_CONNECTION 0x07
+/* G2D */
+#define DRM_EXYNOS_G2D_GET_VER 0x20
+#define DRM_EXYNOS_G2D_SET_CMDLIST 0x21
+#define DRM_EXYNOS_G2D_EXEC0x22
+
#define DRM_IOCTL_EXYNOS_GEM_CREATEDRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_GEM_CREATE, struct drm_exynos_gem_create)
@@ -145,4 +190,11 @@ enum e_drm_exynos_gem_mem_type {
#define DRM_IOCTL_EXYNOS_VIDI_CONNECTION DRM_IOWR(DRM_COMMAND_BASE + \
DRM_EXYNOS_VIDI_CONNECTION, struct drm_exynos_vidi_connection)
+#define DRM_IOCTL_EXYNOS_G2D_GET_VER DRM_IOWR(DRM_COMMAND_BASE + \
+ DRM_EXYNOS_G2D_GET_VER, struct
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Summary|(bisect |Corruption with DMA ring on |8696e33f06b0c52195152cc6a0e |cayman |3d52233f486c1) Kernel | |3.8-rc7 breaks rendering on | |Radeon (confirmed on| |Cayman) | Product|DRI |Mesa Component|DRM/Radeon |Drivers/Gallium/r600 --- Comment #5 from Alex Deucher ag...@yahoo.com --- (In reply to comment #4) bisected and first bad commit is: 8696e33f06b0c52195152cc6a0e3d52233f486c1 commit 8696e33f06b0c52195152cc6a0e3d52233f486c1 Author: Alex Deucher alexander.deuc...@amd.com Date: Thu Dec 13 18:57:07 2012 -0500 drm/radeon: bump version for CS ioctl support for async DMA Signed-off-by: Alex Deucher alexander.deuc...@amd.com That just enables the use of DMA by the 3D driver, so the issue is in mesa. This looks like a duplicate of bug 60236. -- 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 v17 2/7] video: add display_timing and videomode
Hi Steffen, On 2013-01-25 11:01, Steffen Trumtrar wrote: +/* VESA display monitor timing parameters */ +#define VESA_DMT_HSYNC_LOW BIT(0) +#define VESA_DMT_HSYNC_HIGH BIT(1) +#define VESA_DMT_VSYNC_LOW BIT(2) +#define VESA_DMT_VSYNC_HIGH BIT(3) + +/* display specific flags */ +#define DISPLAY_FLAGS_DE_LOW BIT(0) /* data enable flag */ +#define DISPLAY_FLAGS_DE_HIGHBIT(1) +#define DISPLAY_FLAGS_PIXDATA_POSEDGEBIT(2) /* drive data on pos. edge */ +#define DISPLAY_FLAGS_PIXDATA_NEGEDGEBIT(3) /* drive data on neg. edge */ +#define DISPLAY_FLAGS_INTERLACED BIT(4) +#define DISPLAY_FLAGS_DOUBLESCAN BIT(5) snip + unsigned int dmt_flags; /* VESA DMT flags */ + unsigned int data_flags; /* video data flags */ Why did you go for this approach? To be able to represent true/false/not-specified? Would it be simpler to just have flags field? What does it give us to have those two separately? Should the above say raising edge/falling edge instead of positive edge/negative edge? Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #6 from Alexandre Demers alexandre.f.dem...@gmail.com --- (In reply to comment #5) (In reply to comment #4) bisected and first bad commit is: 8696e33f06b0c52195152cc6a0e3d52233f486c1 commit 8696e33f06b0c52195152cc6a0e3d52233f486c1 Author: Alex Deucher alexander.deuc...@amd.com Date: Thu Dec 13 18:57:07 2012 -0500 drm/radeon: bump version for CS ioctl support for async DMA Signed-off-by: Alex Deucher alexander.deuc...@amd.com That just enables the use of DMA by the 3D driver, so the issue is in mesa. This looks like a duplicate of bug 60236. You are right, that's what I thought about the bad identified commit. I don't have the same symptoms as in bug 60236, but I'll have a look anyway. Otherwise, I'll use kernel 3.8-rc7 and I'll bisect mesa to track the bug down. -- 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: [pull] tilcdc-next for 3.9
On Mon, Feb 18, 2013 at 7:40 AM, Tomi Valkeinen to...@iki.fi wrote: On 2013-02-18 14:35, Rob Clark wrote: On Mon, Feb 18, 2013 at 7:32 AM, Tomi Valkeinen to...@iki.fi wrote: On 2013-02-18 14:26, Rob Clark wrote: So I'm not going to get too hung up on supporting current DT bindings in the future when we have something better. But I needed something I may be mistaken, but my understanding is that DT bindings are like kernel's userspace APIs. After they have been merged, they have to work in the future kernels also. and that probably *eventually* makes sense when dts files are kicked out of the kernel. For now, it doesn't really seem useful, unlike maintaining compatibility for userspace ABI's. Why does that matter? Afaik, the dts files are in the kernel for convenience, and as examples. You can as well have the DT data in your bootloader. Or has there been a clear decision that while the dts files are in the kernel, they are considered unstable? I'm not sure.. I'm just going by what I've seen people actually using for the boards which this driver works on currently. I haven't seen anyone embed DT data in bootloader.. either they are appending it to the kernel image or keeping it as a separate file generated from kernel tree. BR, -R Tomi ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60969] [r600g] Lockup while playing OpenGL games with HD6450
https://bugs.freedesktop.org/show_bug.cgi?id=60969 --- Comment #3 from Alex Deucher ag...@yahoo.com --- Created attachment 75046 -- https://bugs.freedesktop.org/attachment.cgi?id=75046action=edit possible fix Does this patch help? -- 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] intel/iommu: force writebuffer-flush quirk on Gen 4 Chipsets
On Wed, Feb 13, 2013 at 07:40:05PM +0100, Daniel Vetter wrote:
On Tue, Jan 22, 2013 at 7:55 PM, David Woodhouse dw...@infradead.org wrote:
On Mon, 2013-01-21 at 19:48 +0100, Daniel Vetter wrote:
We already have the quirk entry for the mobile platform, but also
reports on some desktop versions. So be paranoid and set it
everywhere.
References:
http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg33138.html
Cc: sta...@vger.kernel.org
Cc: David Woodhouse dw...@infradead.org
Reported-and-tested-by: Mihai Moldovan io...@ionic.de
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/iommu/intel-iommu.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 9743769..19854bf 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4215,13 +4215,19 @@ static void __devinit quirk_iommu_rwbf(struct
pci_dev *dev)
{
/*
* Mobile 4 Series Chipset neglects to set RWBF capability,
- * but needs it:
+ * but needs it. Same seems to hold for the desktop versions.
*/
printk(KERN_INFO DMAR: Forcing write-buffer flush capability\n);
rwbf_quirk = 1;
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2a40, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e00, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e10, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, quirk_iommu_rwbf);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e90, quirk_iommu_rwbf);
#define GGC 0x52
#define GGC_MEMORY_SIZE_MASK (0xf 8)
Again, I'm really unhappy about doing this kind of thing based on
hearsay. This should have a specific reference (with URL) to a published
erratum. Rajesh?
Any updates here? I'd like to include this for 3.9 -next with cc:
stable to finally allow distros to enable DMAR/IOMMU support by
default on Intel hw. The current state of affairs is simply
embarrassing imo :(
Whatever, I want to get this off my table, so merged to drm-intel-fixes
for 3.9.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59982] Radeon: evergreen Atombios in loop during initialization on ppc64
https://bugs.freedesktop.org/show_bug.cgi?id=59982 --- Comment #15 from Brian King brk...@linux.vnet.ibm.com --- Can someone clarify something here? Is the bit that we are waiting to go low a bit in the adapter's memory? If so, is it the adapter hardware that we are waiting to set this bit? Is there anyway to dump the adapter to determine its state when we hit the timeout? -- 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 59982] Radeon: evergreen Atombios in loop during initialization on ppc64
https://bugs.freedesktop.org/show_bug.cgi?id=59982 --- Comment #16 from Alex Deucher ag...@yahoo.com --- (In reply to comment #15) Can someone clarify something here? Is the bit that we are waiting to go low a bit in the adapter's memory? If so, is it the adapter hardware that we are waiting to set this bit? It's a memory mapped register. We are waiting for one of the display related bits to go low, so it's the GPU that would be setting that bit. The timeout is in the driver. We eventually drop out of the loop in the atom interpretor if we get stuck after a certain number of seconds. Is there anyway to dump the adapter to determine its state when we hit the timeout? You can dump the mmio registers. -- 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: [pull] tilcdc-next for 3.9
On Mon, Feb 18, 2013 at 12:16:50PM +0200, Tomi Valkeinen wrote: On 2013-02-18 12:03, Daniel Vetter wrote: On Mon, Feb 18, 2013 at 10:02 AM, Tomi Valkeinen to...@iki.fi wrote: But my main concern for this series is still that it creates custom panel stuff, and adds DT bindings for them. Which means we need to support those custom DT bindings in the future, even though it's quite sure that CDF should be used also for this driver, changing the bindings. I'm confused a bit, but shouldn't the DT bindings and CDF be rather orthogonal? Of course for ARM board support we need to have DT binding tables in the kernel to match up hw with the drivers, but I've thought it should be pretty much irrelevant which driver is hooking up to a given dt binding ... Yes, you're right, DT bindings should describe the HW, no matter what the software looks like. I was a bit unclear. Perhaps I should rephrase my main concern to: the DT bindings in this series does not describe the hardware properly and in enough detail. The bindings work for now, but a more sophisticated driver needs more information about the HW. For example, looking at the first patch, I see DT nodes for the LCDC and the dvicape, but nothing describes the connection between these two. And looking at the third patch, there's a DT node for HDMI, using compatible = tilcdc,slave. Again, no connection is described, and also tilcdc,slave doesn't even sound like any hardware device, but more like a software construct for this particular driver. Those are just off the top of my head. These things are usually quite difficult to find out until you actually implement the code. Ok, I understand your concern now, thanks for the elaboration. I guess even when we try really hard to get DT bindings right we'll end up with the occasional need to hardcode a few things ... Quirk tables in the driver seem to be the way of life ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/4] drm: handle compact dma scatter lists in drm_clflush_sg()
So far the assumption was that each scatter list entry contains a single
page. This might not hold in the future, when we'll introduce compact
scatter lists, so prepare for this here.
Reference: http://www.spinics.net/lists/dri-devel/msg33917.html
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/drm_cache.c |7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index a575cb2..bc8edbe 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -105,12 +105,11 @@ drm_clflush_sg(struct sg_table *st)
{
#if defined(CONFIG_X86)
if (cpu_has_clflush) {
- struct scatterlist *sg;
- int i;
+ struct sg_page_iter sg_iter;
mb();
- for_each_sg(st-sgl, sg, st-nents, i)
- drm_clflush_page(sg_page(sg));
+ for_each_sg_page(st-sgl, sg_iter, st-nents, 0)
+ drm_clflush_page(sg_iter.page);
mb();
return;
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/4] drm/i915: handle compact dma scatter lists
This series adds support for handling compact dma scatter lists to the i915 driver. This is a dependency for the related upcoming change in the PRIME interface: http://www.spinics.net/lists/dri-devel/msg33917.html v2: - Add the sg_for_each_page macro to /lib/scatterlist instead of drivers/drm. This is a separate patchset being merged through the -mm tree. - Use the sg_for_each_page macro in the gtt pte setup code too. Imre Deak (4): drm: handle compact dma scatter lists in drm_clflush_sg() drm/i915: handle walking compact dma scatter lists drm/i915: create compact dma scatter lists for gem objects drm/i915: use for_each_sg_page for setting up the gtt ptes drivers/gpu/drm/drm_cache.c|7 ++-- drivers/gpu/drm/i915/i915_drv.h| 17 +++- drivers/gpu/drm/i915/i915_gem.c| 55 ++ drivers/gpu/drm/i915/i915_gem_dmabuf.c | 13 --- drivers/gpu/drm/i915/i915_gem_gtt.c| 67 drivers/gpu/drm/i915/i915_gem_tiling.c | 18 + 6 files changed, 80 insertions(+), 97 deletions(-) -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 3/4] drm/i915: create compact dma scatter lists for gem objects
So far we created a sparse dma scatter list for gem objects, where each
scatter list entry represented only a single page. In the future we'll
have to handle compact scatter lists too where each entry can consist of
multiple pages, for example for objects imported through PRIME.
The previous patches have already fixed up all other places where the
i915 driver _walked_ these lists. Here we have the corresponding fix to
_create_ compact lists. It's not a performance or memory footprint
improvement, but it helps to better exercise the new logic.
Reference: http://www.spinics.net/lists/dri-devel/msg33917.html
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c | 31 ++-
1 file changed, 22 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 03037cf..ec2f11f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1625,9 +1625,8 @@ i915_gem_object_is_purgeable(struct drm_i915_gem_object
*obj)
static void
i915_gem_object_put_pages_gtt(struct drm_i915_gem_object *obj)
{
- int page_count = obj-base.size / PAGE_SIZE;
- struct scatterlist *sg;
- int ret, i;
+ struct sg_page_iter sg_iter;
+ int ret;
BUG_ON(obj-madv == __I915_MADV_PURGED);
@@ -1647,8 +1646,8 @@ i915_gem_object_put_pages_gtt(struct drm_i915_gem_object
*obj)
if (obj-madv == I915_MADV_DONTNEED)
obj-dirty = 0;
- for_each_sg(obj-pages-sgl, sg, page_count, i) {
- struct page *page = sg_page(sg);
+ for_each_sg_page(obj-pages-sgl, sg_iter, obj-pages-nents, 0) {
+ struct page *page = sg_iter.page;
if (obj-dirty)
set_page_dirty(page);
@@ -1749,7 +1748,9 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
struct address_space *mapping;
struct sg_table *st;
struct scatterlist *sg;
+ struct sg_page_iter sg_iter;
struct page *page;
+ unsigned long last_pfn = 0; /* suppress gcc warning */
gfp_t gfp;
/* Assert that the object is not currently in any GPU domain. As it
@@ -1779,7 +1780,9 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
gfp = mapping_gfp_mask(mapping);
gfp |= __GFP_NORETRY | __GFP_NOWARN | __GFP_NO_KSWAPD;
gfp = ~(__GFP_IO | __GFP_WAIT);
- for_each_sg(st-sgl, sg, page_count, i) {
+ sg = st-sgl;
+ st-nents = 0;
+ for (i = 0; i page_count; i++) {
page = shmem_read_mapping_page_gfp(mapping, i, gfp);
if (IS_ERR(page)) {
i915_gem_purge(dev_priv, page_count);
@@ -1802,9 +1805,18 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
gfp = ~(__GFP_IO | __GFP_WAIT);
}
- sg_set_page(sg, page, PAGE_SIZE, 0);
+ if (!i || page_to_pfn(page) != last_pfn + 1) {
+ if (i)
+ sg = sg_next(sg);
+ st-nents++;
+ sg_set_page(sg, page, PAGE_SIZE, 0);
+ } else {
+ sg-length += PAGE_SIZE;
+ }
+ last_pfn = page_to_pfn(page);
}
+ sg_mark_end(sg);
obj-pages = st;
if (i915_gem_object_needs_bit17_swizzle(obj))
@@ -1813,8 +1825,9 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
return 0;
err_pages:
- for_each_sg(st-sgl, sg, i, page_count)
- page_cache_release(sg_page(sg));
+ sg_mark_end(sg);
+ for_each_sg_page(st-sgl, sg_iter, st-nents, 0)
+ page_cache_release(sg_iter.page);
sg_free_table(st);
kfree(st);
return PTR_ERR(page);
--
1.7.10.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/4] drm/i915: handle walking compact dma scatter lists
So far the assumption was that each dma scatter list entry contains only
a single page. This might not hold in the future, when we'll introduce
compact scatter lists, so prepare for this everywhere in the i915 code
where we walk such a list.
We'll fix the place _creating_ these lists separately in the next patch
to help the reviewing/bisectability.
Reference: http://www.spinics.net/lists/dri-devel/msg33917.html
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h| 17 ++---
drivers/gpu/drm/i915/i915_gem.c| 24
drivers/gpu/drm/i915/i915_gem_dmabuf.c | 13 +++--
drivers/gpu/drm/i915/i915_gem_tiling.c | 18 ++
4 files changed, 31 insertions(+), 41 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e95337c..2c03636 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1528,17 +1528,12 @@ void i915_gem_lastclose(struct drm_device *dev);
int __must_check i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
static inline struct page *i915_gem_object_get_page(struct drm_i915_gem_object
*obj, int n)
{
- struct scatterlist *sg = obj-pages-sgl;
- int nents = obj-pages-nents;
- while (nents SG_MAX_SINGLE_ALLOC) {
- if (n SG_MAX_SINGLE_ALLOC - 1)
- break;
-
- sg = sg_chain_ptr(sg + SG_MAX_SINGLE_ALLOC - 1);
- n -= SG_MAX_SINGLE_ALLOC - 1;
- nents -= SG_MAX_SINGLE_ALLOC - 1;
- }
- return sg_page(sg+n);
+ struct sg_page_iter sg_iter;
+
+ for_each_sg_page(obj-pages-sgl, sg_iter, obj-pages-nents, n)
+ return sg_iter.page;
+
+ return NULL;
}
static inline void i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
{
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 8413ffc..03037cf 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -411,8 +411,7 @@ i915_gem_shmem_pread(struct drm_device *dev,
int obj_do_bit17_swizzling, page_do_bit17_swizzling;
int prefaulted = 0;
int needs_clflush = 0;
- struct scatterlist *sg;
- int i;
+ struct sg_page_iter sg_iter;
user_data = (char __user *) (uintptr_t) args-data_ptr;
remain = args-size;
@@ -441,11 +440,9 @@ i915_gem_shmem_pread(struct drm_device *dev,
offset = args-offset;
- for_each_sg(obj-pages-sgl, sg, obj-pages-nents, i) {
- struct page *page;
-
- if (i offset PAGE_SHIFT)
- continue;
+ for_each_sg_page(obj-pages-sgl, sg_iter, obj-pages-nents,
+offset PAGE_SHIFT) {
+ struct page *page = sg_iter.page;
if (remain = 0)
break;
@@ -460,7 +457,6 @@ i915_gem_shmem_pread(struct drm_device *dev,
if ((shmem_page_offset + page_length) PAGE_SIZE)
page_length = PAGE_SIZE - shmem_page_offset;
- page = sg_page(sg);
page_do_bit17_swizzling = obj_do_bit17_swizzling
(page_to_phys(page) (1 17)) != 0;
@@ -732,8 +728,7 @@ i915_gem_shmem_pwrite(struct drm_device *dev,
int hit_slowpath = 0;
int needs_clflush_after = 0;
int needs_clflush_before = 0;
- int i;
- struct scatterlist *sg;
+ struct sg_page_iter sg_iter;
user_data = (char __user *) (uintptr_t) args-data_ptr;
remain = args-size;
@@ -768,13 +763,11 @@ i915_gem_shmem_pwrite(struct drm_device *dev,
offset = args-offset;
obj-dirty = 1;
- for_each_sg(obj-pages-sgl, sg, obj-pages-nents, i) {
- struct page *page;
+ for_each_sg_page(obj-pages-sgl, sg_iter, obj-pages-nents,
+offset PAGE_SHIFT) {
+ struct page *page = sg_iter.page;
int partial_cacheline_write;
- if (i offset PAGE_SHIFT)
- continue;
-
if (remain = 0)
break;
@@ -796,7 +789,6 @@ i915_gem_shmem_pwrite(struct drm_device *dev,
((shmem_page_offset | page_length)
(boot_cpu_data.x86_clflush_size - 1));
- page = sg_page(sg);
page_do_bit17_swizzling = obj_do_bit17_swizzling
(page_to_phys(page) (1 17)) != 0;
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 6a5af68..898615d 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -62,7 +62,7 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attachme
src = obj-pages-sgl;
dst = st-sgl;
for (i = 0; i obj-pages-nents; i++) {
-
Re: [PATCH] omapdrm: Make fixed resolution panels work
On 2013-02-18 09:23, Archit Taneja wrote:
diff --git a/drivers/staging/omapdrm/omap_connector.c
b/drivers/staging/omapdrm/omap_connector.c
index 4cc9ee7..839c6e4 100644
--- a/drivers/staging/omapdrm/omap_connector.c
+++ b/drivers/staging/omapdrm/omap_connector.c
@@ -110,6 +110,11 @@ static enum drm_connector_status
omap_connector_detect(
ret = connector_status_connected;
else
ret = connector_status_disconnected;
+ } else if (dssdev-type == OMAP_DISPLAY_TYPE_DPI ||
+ dssdev-type == OMAP_DISPLAY_TYPE_DBI ||
+ dssdev-type == OMAP_DISPLAY_TYPE_SDI ||
+ dssdev-type == OMAP_DISPLAY_TYPE_DSI) {
+ ret = connector_status_connected;
hmm, why not just have a default detect fxn for panel drivers which
always returns true? Seems a bit cleaner.. otherwise, I guess we
could just change omap_connector so that if dssdev-detect is null,
assume always connected. Seems maybe a slightly better way since
currently omap_connector doesn't really know too much about different
sorts of panels. But I'm not too picky if that is a big pain because
we probably end up changing all this as CFP starts coming into
existence.
Same goes for check_timings/set_timings.. it seems a bit cleaner just
to have default fxns in the panel drivers that do-the-right-thing,
although I suppose it might be a bit more convenient for out-of-tree
panel drivers to just assume fixed panel if these fxns are null.
Yeah, I can't make my mind about null pointer. It's nice to inform with
a null pointer that the panel doesn't support the given operation, or
that it doesn't make sense, but handling the null value makes the code a
bit complex.
For example, our VENC driver doesn't know if there's a TV connected or
not, so neither true or false as connect return value makes sense there.
Or, for a DSI command mode panel, set_timings doesn't really make much
sense.
Maybe having default functions in omapdss might be a better idea. There
is an option of adding default functions in omap_dss_register_driver()
(drivers/video/omap2/dss/core.c).
Tomi, do you think it's fine to add some more default panel driver funcs?
We can add default funcs. However, adding them in
omap_dss_register_driver is not so nice, as it makes the omap_dss_driver
(which is essentially an ops struct) non-constable. Instead, we should
move the setting of the default funcs to the drivers.
If I'm not mistaken, we could manage that with a helper macro. Assigning
a value to the same field of a struct should be ok by the compiler, and
should cause only the last assignment to be taken into use. So:
static struct foo zab = {
.bar = 123, /* ignored */
.bar = 234, /* used */
};
And so we could have:
static struct omap_dss_driver my_panel_driver = {
OMAPDSS_DEFAULT_PANEL_OPS, /* macro for default ops */
.enable = my_panel_enable,
/* ... */
};
Tomi
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242
On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote: Hi, we have a report of WARNING from 3.7.6 in nouveau at drivers/gpu/drm/nouveau/core/core/mm.c:242 here: https://bugzilla.novell.com/show_bug.cgi?id=802347#c11 There is an order 4 allocation failure in nouveau_drm_open - nouveau_vm_create, i.e. this one failed: vm-pgt = kcalloc(vm-lpde - vm-fpde + 1, sizeof(*vm-pgt), GFP_KERNEL); Then, on the error path in still in nouveau_drm_open, it is followed by a call to nouveau_cli_destroy. But that one calls nouveau_vm_ref - nouveau_mm_fini - nouveau_vm_del - nouveau_mm_fini which triggers the warning. Any ideas? Crash/warning should be fixed by commit cfd376b6bfccf33782a0748a9c70f7f752f8b869 drm/nouveau/vm: fix memory corruption when pgt allocation fails. Tomorrow I'll post a patch for page allocation failure. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242
On 02/19/2013 12:23 AM, Marcin Slusarz wrote: On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote: Hi, we have a report of WARNING from 3.7.6 in nouveau at drivers/gpu/drm/nouveau/core/core/mm.c:242 here: https://bugzilla.novell.com/show_bug.cgi?id=802347#c11 There is an order 4 allocation failure in nouveau_drm_open - nouveau_vm_create, i.e. this one failed: vm-pgt = kcalloc(vm-lpde - vm-fpde + 1, sizeof(*vm-pgt), GFP_KERNEL); Then, on the error path in still in nouveau_drm_open, it is followed by a call to nouveau_cli_destroy. But that one calls nouveau_vm_ref - nouveau_mm_fini - nouveau_vm_del - nouveau_mm_fini which triggers the warning. Any ideas? Crash/warning should be fixed by commit cfd376b6bfccf33782a0748a9c70f7f752f8b869 drm/nouveau/vm: fix memory corruption when pgt allocation fails. Oh, thanks for the pointer. Could that bug cause real memory corruption? As we're hunting one there... Isn't this a stable-3.7 candidate? Tomorrow I'll post a patch for page allocation failure. What do you mean -- what kind of patch? -- js suse labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56405] Distorted graphics on Radeon HD 6620G
https://bugs.freedesktop.org/show_bug.cgi?id=56405 Mike Lothian m...@fireburn.co.uk changed: What|Removed |Added CC||m...@fireburn.co.uk --- Comment #55 from Mike Lothian m...@fireburn.co.uk --- I'm running the latest mesa and kernels from git and I think I may have encountered this issue Everything works fine using i965, using prime with R600_LLVM=1 is also ok however when running with R600_LLVM=0 I got similar error messages about being out of memory This seemed to happen when I was testing out the highest settings of WoW - disappointingly the i965 had the highest fps -- 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 56405] Distorted graphics on Radeon HD 6620G
https://bugs.freedesktop.org/show_bug.cgi?id=56405 --- Comment #56 from Mike Lothian m...@fireburn.co.uk --- Created attachment 75082 -- https://bugs.freedesktop.org/attachment.cgi?id=75082action=edit Dmesg output -- 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 56405] Distorted graphics on Radeon HD 6620G
https://bugs.freedesktop.org/show_bug.cgi?id=56405 --- Comment #57 from Mike Lothian m...@fireburn.co.uk --- I got lots of radeon: The kernel rejected CS, see dmesg for more information. from the wine process If this is a separate issue I'll look into it more tomorrow -- 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: linux-next: build failure after merge of the drm-intel tree
Hi Daniel, On Fri, 15 Feb 2013 08:16:26 -0800 Jesse Barnes jbar...@virtuousgeek.org wrote: On Fri, 15 Feb 2013 10:30:16 +0100 Daniel Vetter daniel.vet...@ffwll.ch wrote: On Fri, Feb 15, 2013 at 3:37 AM, Stephen Rothwell s...@canb.auug.org.au wrote: After merging the drm-intel tree, today's linux-next build (x86_64 allmodconfig) failed like this: ERROR: pm_vt_switch_unregister [drivers/video/fb.ko] undefined! I have dropped the tree for today. Meh, that fail was already reported from Wu's kernel builder a few days ago, but no patch yet showed up to fix things. Since the i915 side of that work isn't ready yet either I've dropped the offending patches. I sent a patch yesterday for this. I'll bounce it over again. I am still getting that build failure. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp_MSiv83Acz.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60236] corruption of text and bottom of screen in xonotic menus since 325422c49449acdd8df1eb2ca8ed81f7696c38cc
https://bugs.freedesktop.org/show_bug.cgi?id=60236 --- Comment #36 from Alexandre Demers alexandre.f.dem...@gmail.com --- It doesn't apply correctly on kernel 3.8.0 -- 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 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.
https://bugs.freedesktop.org/show_bug.cgi?id=49981 --- Comment #30 from Chav chav.re...@gmail.com --- Macbook Pro 8,2 Late 2011 with Radeon 6750m like Ludovic Watteaux. In order to get the power profile working with the kernel 3.8rc4 I had to revert the following commits: drm/radeon/pm: fix multi-head profile handling on BTC+ (v2) 27810fb2d2edacf2961dbedfe9e9f8d2e5080ea5 drm/radeon: only adjust default clocks on NI GPUs 2e3b3b105ab3bb5b6a37198da4f193cd13781d13. And apply the following: - drivers/gpu/drm/radeon/radeon_pm.c -- index dfc59c3..c045985 100644 @@ -98,7 +98,7 @@ static void radeon_pm_update_profile(struct radeon_device *rdev) break; case PM_PROFILE_LOW: if (rdev-pm.active_crtc_count 1) -rdev-pm.profile_index = PM_PROFILE_LOW_MH_IDX; +rdev-pm.profile_index = PM_PROFILE_LOW_SH_IDX; else rdev-pm.profile_index = PM_PROFILE_LOW_SH_IDX; break; -- 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 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #7 from Alexandre Demers alexandre.f.dem...@gmail.com --- So I followed bug 60236. I sync mesa since the proposed mesa patch had already been pushed. I tested with kernel 3.8.0 and the bug was still there. I then applied the proposed kernel patch over 3.8.0 (after fixing it because it was not properly applying), built and restarted using this newly built kernel. Result: the bug is still there and the same. So this bug is not the same as bug 60236. I'll try to bisect mesa in the next couple of days. BTW, I bought Bastion on Steam and tested it. The same bug appears (or not exactly as for the demos depending of the kernel I was using), so it is not limited to some demo cases. -- 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 60802] Corruption with DMA ring on cayman
https://bugs.freedesktop.org/show_bug.cgi?id=60802 --- Comment #8 from Alexandre Demers alexandre.f.dem...@gmail.com --- Culprit commit in mesa identified as: 325422c49449acdd8df1eb2ca8ed81f7696c38cc is the first bad commit commit 325422c49449acdd8df1eb2ca8ed81f7696c38cc Author: Jerome Glisse jgli...@redhat.com Date: Mon Jan 7 17:45:59 2013 -0500 r600g: add async for staging buffer upload v2 v2: Add virtual address to dma src/dst offset for cayman Signed-off-by: Jerome Glisse jgli...@redhat.com :04 04 4ef6e784f3acb7f21da0c5e1923810c78917d16d 55f0ce7d9793ce04d392fc7943059545053a9d79 Msrc So, it is the same commit as for bug 60236, but applying patches from it doesn't help. -- 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: kernel BUG at mm/slub.c:3409, 3.8.0-rc7
[+cc Marcin Slusarz, dri-devel] On Tue, 2013-02-19 at 00:21 +, Christoph Lameter wrote: The problem is that the subsystem attempted to call kfree with a pointer that was not obtained via a slab allocation. On Sat, 16 Feb 2013, Denys Fedoryshchenko wrote: Hi Worked for a while on 3.8.0-rc7, generally it is fine, then suddenly laptop stopped responding to keyboard and mouse. Sure it can be memory corruption by some other module, but maybe not. Worth to report i guess. After reboot checked logs and found this: Feb 16 00:40:17 localhost kernel: [23260.079253] [ cut here ] Feb 16 00:40:17 localhost kernel: [23260.079257] kernel BUG at mm/slub.c:3409! Feb 16 00:40:17 localhost kernel: [23260.079259] invalid opcode: [#1] SMP Feb 16 00:40:17 localhost kernel: [23260.079262] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables tun bridge stp llc nouveau snd_hda_codec_hdmi coretemp kvm_intel Was there an allocation failure earlier in the log? Might be this nouveau bug (linux-next at the time was 3.8 now): https://bugs.freedesktop.org/show_bug.cgi?id=58087 I think this was fixed but neither bug report has a cross reference :( The original report is here: https://bugzilla.kernel.org/show_bug.cgi?id=51291 Pekka, Can you please re-assign the bugzilla #51291 above to DRI? Thanks. Regards, Peter Hurley ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Page allocation failures (was Re: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242)
On Tue, 2013-02-19 at 00:43 +0100, Jiri Slaby wrote: On 02/19/2013 12:23 AM, Marcin Slusarz wrote: On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote: Hi, we have a report of WARNING from 3.7.6 in nouveau at drivers/gpu/drm/nouveau/core/core/mm.c:242 here: https://bugzilla.novell.com/show_bug.cgi?id=802347#c11 There is an order 4 allocation failure in nouveau_drm_open - nouveau_vm_create, i.e. this one failed: vm-pgt = kcalloc(vm-lpde - vm-fpde + 1, sizeof(*vm-pgt), GFP_KERNEL); Hi Jiri, I had the order 4 allocation failure and nouveau crash back in November on next-20121129. Bugzillas here: Allocation failure: https://bugzilla.kernel.org/show_bug.cgi?id=51301 Nouveau bug: https://bugzilla.kernel.org/show_bug.cgi?id=51291 https://bugs.freedesktop.org/show_bug.cgi?id=58087 IMO, the 32k allocation failure is the more serious bug. Check out the slab info from your report: Feb 06 13:16:15 desdemona kernel: Node 0 DMA32: 13378*4kB 5026*8kB 1823*16kB 135*32kB 5*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 129576kB Feb 06 13:16:15 desdemona kernel: Node 0 Normal: 1946*4kB 831*8kB 3*16kB 1*32kB 1*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 16496kB The pages are there: why did the allocation fail? I think this is related to all that kswapd mess. In my case, the machine really was OOM -- which made no sense. Completely out of page blocks larger than 32k on a 10gb machine with a bunch of emacs and terminal windows open for 3 days, just doing code, build, code, build, code, build? Regards, Peter Hurley ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242
On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote: On 02/19/2013 12:23 AM, Marcin Slusarz wrote: On Mon, Feb 18, 2013 at 11:27:43AM +0100, Jiri Slaby wrote: Hi, we have a report of WARNING from 3.7.6 in nouveau at drivers/gpu/drm/nouveau/core/core/mm.c:242 here: https://bugzilla.novell.com/show_bug.cgi?id=802347#c11 There is an order 4 allocation failure in nouveau_drm_open - nouveau_vm_create, i.e. this one failed: vm-pgt = kcalloc(vm-lpde - vm-fpde + 1, sizeof(*vm-pgt), GFP_KERNEL); Then, on the error path in still in nouveau_drm_open, it is followed by a call to nouveau_cli_destroy. But that one calls nouveau_vm_ref - nouveau_mm_fini - nouveau_vm_del - nouveau_mm_fini which triggers the warning. Any ideas? Crash/warning should be fixed by commit cfd376b6bfccf33782a0748a9c70f7f752f8b869 drm/nouveau/vm: fix memory corruption when pgt allocation fails. Oh, thanks for the pointer. Could that bug cause real memory corruption? As we're hunting one there... Yes. Isn't this a stable-3.7 candidate? Should have been :/. Tomorrow I'll post a patch for page allocation failure. What do you mean -- what kind of patch? A patch which will change pgt allocation to use vmalloc. Marcin ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/cma-helper: fixup compilation
On Fri, Feb 15, 2013 at 11:24:35AM +0100, Daniel Vetter wrote:
/me grabs a few brown paper bags
So it looks like I've broken compilation in
commit 6aed8ec3f76a22217c9ae183d32b1aa990bed069
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Sun Jan 20 17:32:21 2013 +0100
drm: review locking for drm_fb_helper_restore_fbdev_mode
Fix it up again.
Reported-by: Wu Fengguang fengguang...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/drm_fb_cma_helper.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index e851658..ef68e34 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -377,6 +377,8 @@ EXPORT_SYMBOL_GPL(drm_fbdev_cma_fini);
*/
void drm_fbdev_cma_restore_mode(struct drm_fbdev_cma *fbdev_cma)
{
+ struct drm_device *dev = fbdev_cma-fb_helper.dev;
+
drm_modeset_lock_all(dev);
if (fbdev_cma)
drm_fb_helper_restore_fbdev_mode(fbdev_cma-fb_helper);
The above check indicates that fbdev_cma might be NULL, so you're
potentially dereferencing NULL when assigning the dev variable.
Perhaps a better way would be to move the locking into the if block, as
in the patch below.
Thierry
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index e851658..54a250f 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -377,10 +377,11 @@ EXPORT_SYMBOL_GPL(drm_fbdev_cma_fini);
*/
void drm_fbdev_cma_restore_mode(struct drm_fbdev_cma *fbdev_cma)
{
- drm_modeset_lock_all(dev);
- if (fbdev_cma)
+ if (fbdev_cma) {
+ drm_modeset_lock_all(fbdev_cma-fb_helper.dev);
drm_fb_helper_restore_fbdev_mode(fbdev_cma-fb_helper);
- drm_modeset_unlock_all(dev);
+ drm_modeset_unlock_all(fbdev_cma-fb_helper.dev);
+ }
}
EXPORT_SYMBOL_GPL(drm_fbdev_cma_restore_mode);
pgprt_wnSdjL3.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
