[PATCH 4/4] drm/i915: add SNB video sprite support
On Tue, 7 Jun 2011 13:07:42 -0700, Jesse Barnes wrote: > The video sprites support video surface formats natively and can handle > scaling well. So add support for them using the new DRM core overlay > support functions. > > Signed-off-by: Jesse Barnes > --- > drivers/gpu/drm/i915/Makefile |1 + > drivers/gpu/drm/i915/i915_reg.h | 52 ++ > drivers/gpu/drm/i915/intel_display.c | 19 +++- > drivers/gpu/drm/i915/intel_drv.h | 13 +++ > drivers/gpu/drm/i915/intel_fb.c |6 + > drivers/gpu/drm/i915/intel_overlay2.c | 172 > + 0 points for inspiration. intel_video_sprite? -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Intel-gfx] [PATCH 3/4] drm/i915: rename existing overlay support to "legacy"
On Tue, 7 Jun 2011 13:07:41 -0700, Jesse Barnes
wrote:
> The old overlay block has all sorts of quirks and is very different than
> ILK+ video sprites. So rename it to legacy to make that clear and clash
> less with core overlay support.
>
> Signed-off-by: Jesse Barnes
> ---
> @@ -191,7 +191,7 @@ struct drm_i915_error_state {
> u32 cache_level:2;
> } *active_bo, *pinned_bo;
> u32 active_bo_count, pinned_bo_count;
> - struct intel_overlay_error_state *overlay;
> + struct intel_legacy_overlay_error_state *overlay;
We need to change the name here as well, unless you have some
differently name error struct up your sleeve.
struct intel_sprite_error_state?
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 3cfc391..d73e622 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -161,7 +161,7 @@ struct intel_crtc {
> bool busy; /* is scanout buffer being updated frequently? */
> struct timer_list idle_timer;
> bool lowfreq_avail;
> - struct intel_overlay *overlay;
> + struct intel_legacy_overlay *overlay;
> struct intel_unpin_work *unpin_work;
> int fdi_lanes;
And here. Give the old code longer names, we don't want to be touching
it ever again. ;-)
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
CPU and GPU cache-coherence
3D render image on WC AGP aperture BO and then CPU fetch the image from this bo, in order to achieve performance, after 3D finished rendering, validate this bo into cached system memory and then read it from system memory. But I always get garbage from there. After check TTM bo validate codes, it has dealt with cache coherence properly, i wonder whether there is something I misunderstand or it is not allowed to move the WC bo from AGP to system memory for reading? thanks. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110607/9abbcb49/attachment.html> -- next part -- -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev -- next part -- -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC PATCH] KMS support for i.MX51/53
On Tue, Jun 07, 2011 at 12:17:01PM +0100, Alan Cox wrote: > > Currently I don't use any sophisticated memory allocater like GEM > > or similar. I helped myself with simple dma_alloc where needed. At > > GEM is actually pretty sane when you get your head around it a spot. The > main thing it took me a bit of time to get my head around is that it > allocates backing memory and handles but it doesn't allocate address > space on the card side. I'm not sure I understand you correctly. I have no address space on the card side since my 'card' just uses main memory. The memory I need must be a physically contiguous portion of sdram. I'm afraid shmem backing memory is not of much use for me. Correct me if I mix things up... Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[RFC PATCH] KMS support for i.MX51/53
> I'm not sure I understand you correctly. I have no address space on the > card side since my 'card' just uses main memory. The memory I need must > be a physically contiguous portion of sdram. I'm afraid shmem backing > memory is not of much use for me. I hadn't realised you had that underlying limit. If you are limited to a specific chunk of SDRAM and it must be physically linear rather than any of memory then indeed it's not. I'd been tweaking GEM so you can borrow the abstraction and handles but back them with your own allocator but in my case it makes sense because I can use either main memory or a chunk of linear preallocated memory reserved by the firmware so I wanted the commonality and single set of handles for GEM, IOCTL_MODE_CREATE_DUMB etc. Alan
[Bug 37075] objview demo has messed up geometry with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=37075 --- Comment #5 from Marek Ol??k 2011-06-07 16:25:27 PDT --- I can't reproduce this on r580. The bunny looks alright here. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #8 from Marek Ol??k 2011-06-07 16:20:33 PDT --- Created an attachment (id=47694) View: https://bugs.freedesktop.org/attachment.cgi?id=47694 Review: https://bugs.freedesktop.org/review?bug=37171=47694 patch Could you post the log again with the patch applied? Also, does it fix anything? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37171] half-life 2 with -dxlevel 90 crashes system
https://bugs.freedesktop.org/show_bug.cgi?id=37171 --- Comment #7 from Marek Ol??k 2011-06-07 16:16:37 PDT --- The messages like this: fixme:d3d:debug_d3dformat Unrecognized 0x36314644 (as fourcc: DF16) WINED3DFORMAT! fixme:d3d:wined3d_get_format Can't find format unrecognized (0x36314644) in the format lookup table should be fixed in Wine. I can help if needed. All the FOURCC codes can be implemented. ATI's formats are described here: http://developer.amd.com/gpu_assets/Advanced%20DX9%20Capabilities%20for%20ATI%20Radeon%20Cards_v2.pdf Next. Compiler failures. You hit quite a lot of hardware limitations. The one that's really weird is "Couldn't flatten if statement". I don't see any "if" statements in the dumped shaders. I will send a patch to silence that. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH/RFC] m68k/bitops: Make bitmap data pointer of atomic ops volatile
On Tuesday 07 June 2011, Ben Hutchings wrote: > On Tue, Jun 07, 2011 at 01:22:29PM +0200, Arnd Bergmann wrote: > > I guess what happened is that some variables are traditionally marked > > as volatile although they shouldn't be, and most architectures have > > adapted their bitops to make the warnings go away. If you see more > > warnings of that kind, it's probably fine to just do the same on m68k. > > The volatile modifier doesn't really hurt in this case. > > These operations are required to be atomic and therefore they > must be suitable for use with volatile-qualified variables. As I said, it's not wrong for them to have a volatile qualifier in the argument list. However, there should also not be the need for the qualifier in any of the callers, because the bitops only work if all accesses to the data are done through bitops functions, and that means that the qualifier on the variable is completely meaningless. Arnd
[Bug 37227] z-buffer errors in doom3 outside the airlock
https://bugs.freedesktop.org/show_bug.cgi?id=37227 --- Comment #1 from Marek Ol??k 2011-06-07 15:46:09 PDT --- Is this with HyperZ enabled? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37274] Crash in draw_llvm_shader23 (r300g, rs690, in warzone2100)
https://bugs.freedesktop.org/show_bug.cgi?id=37274 Marek Ol??k changed: What|Removed |Added Summary|r300g: rs690, crash in |Crash in draw_llvm_shader23 |warzone2100 |(r300g, rs690, in ||warzone2100) Component|Drivers/Gallium/r300|Mesa core AssignedTo|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org --- Comment #1 from Marek Ol??k 2011-06-07 15:44:51 PDT --- Reassigning to Mesa core. I can't reproduce this bug with r300g and the Draw path enabled (forcing HWTCL off). Could you please test latest Mesa git? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37470] OpenGL ES2 test, black screen and test crashes
https://bugs.freedesktop.org/show_bug.cgi?id=37470 Marek Ol??k changed: What|Removed |Added Component|Drivers/Gallium/r300|Mesa core AssignedTo|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org --- Comment #1 from Marek Ol??k 2011-06-07 15:37:40 PDT --- I've got no experience with ES2 (never used it). Reassigning to Mesa core. Maybe someone else can help. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37911] supertuxkart crashes with r300g
https://bugs.freedesktop.org/show_bug.cgi?id=37911 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME Component|Drivers/Gallium/r300|Mesa core AssignedTo|dri-devel at lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org --- Comment #1 from Marek Ol??k 2011-06-07 15:34:20 PDT --- That seems to be a build failure. The one who maintains the repository should rebuild the binaries (start with git clean -fdX). Supertuxkart works flawlessly with git master here. Closing as WORKSFORME. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm/radeon: fix GUI idle IH debug statements
On Tue, Jun 7, 2011 at 2:54 PM, Ilija Hadzic
wrote:
> debug statement for GUI idle interrupt is wrong and incorrectly
> reports CP EOP interrupt; trivial issue, but confusing for
> someone trying to distinguish interrupt sources while debugging
> ... fixed
>
> Signed-off-by: Ilija Hadzic
Reviewed-by: Alex Deucher
> ---
> ?drivers/gpu/drm/radeon/evergreen.c | ? ?2 +-
> ?drivers/gpu/drm/radeon/r600.c ? ? ?| ? ?2 +-
> ?2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index 34cd5a8..e30a68b 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -2865,7 +2865,7 @@ restart_ih:
> ? ? ? ? ? ? ? ? ? ? ? ?radeon_fence_process(rdev);
> ? ? ? ? ? ? ? ? ? ? ? ?break;
> ? ? ? ? ? ? ? ?case 233: /* GUI IDLE */
> - ? ? ? ? ? ? ? ? ? ? ? DRM_DEBUG("IH: CP EOP\n");
> + ? ? ? ? ? ? ? ? ? ? ? DRM_DEBUG("IH: GUI idle\n");
> ? ? ? ? ? ? ? ? ? ? ? ?rdev->pm.gui_idle = true;
> ? ? ? ? ? ? ? ? ? ? ? ?wake_up(>irq.idle_queue);
> ? ? ? ? ? ? ? ? ? ? ? ?break;
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index 669a977..9c1318d 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -3456,7 +3456,7 @@ restart_ih:
> ? ? ? ? ? ? ? ? ? ? ? ?radeon_fence_process(rdev);
> ? ? ? ? ? ? ? ? ? ? ? ?break;
> ? ? ? ? ? ? ? ?case 233: /* GUI IDLE */
> - ? ? ? ? ? ? ? ? ? ? ? DRM_DEBUG("IH: CP EOP\n");
> + ? ? ? ? ? ? ? ? ? ? ? DRM_DEBUG("IH: GUI idle\n");
> ? ? ? ? ? ? ? ? ? ? ? ?rdev->pm.gui_idle = true;
> ? ? ? ? ? ? ? ? ? ? ? ?wake_up(>irq.idle_queue);
> ? ? ? ? ? ? ? ? ? ? ? ?break;
> --
> 1.7.5.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[PATCH] drm/radeon: fix GUI idle IH debug statements
debug statement for GUI idle interrupt is wrong and incorrectly
reports CP EOP interrupt; trivial issue, but confusing for
someone trying to distinguish interrupt sources while debugging
... fixed
Signed-off-by: Ilija Hadzic
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeon/r600.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 34cd5a8..e30a68b 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2865,7 +2865,7 @@ restart_ih:
radeon_fence_process(rdev);
break;
case 233: /* GUI IDLE */
- DRM_DEBUG("IH: CP EOP\n");
+ DRM_DEBUG("IH: GUI idle\n");
rdev->pm.gui_idle = true;
wake_up(>irq.idle_queue);
break;
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 669a977..9c1318d 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3456,7 +3456,7 @@ restart_ih:
radeon_fence_process(rdev);
break;
case 233: /* GUI IDLE */
- DRM_DEBUG("IH: CP EOP\n");
+ DRM_DEBUG("IH: GUI idle\n");
rdev->pm.gui_idle = true;
wake_up(>irq.idle_queue);
break;
--
1.7.5.3
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #23 from Alex Deucher 2011-06-07 14:45:44 PDT --- Fixes pushed: 7c1d4781920e34ad5419b4c5cf9d54ae14938844 bdf2e112856659816d000699fce606adc4ee9926 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] ttm: Fix spelling mistakes and remove unused #ifdef
. and some comments to make it easier to understand.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 14 +++---
include/drm/ttm/ttm_bo_api.h |3 ---
include/drm/ttm/ttm_bo_driver.h |6 +++---
include/drm/ttm/ttm_memory.h |2 +-
include/drm/ttm/ttm_object.h |4 ++--
include/drm/ttm/ttm_page_alloc.h |2 +-
6 files changed, 14 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 9d9d929..3277965 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -355,7 +355,7 @@ restart:
if (nr_free)
goto restart;
- /* Not allowed to fall tough or break because
+ /* Not allowed to fall through or break because
* following context is inside spinlock while we are
* outside here.
*/
@@ -554,7 +554,7 @@ out:
}
/**
- * Fill the given pool if there isn't enough pages and requested number of
+ * Fill the given pool if there isn't enough pages and the requested number of
* pages is small.
*/
static void ttm_page_pool_fill_locked(struct ttm_page_pool *pool,
@@ -575,7 +575,7 @@ static void ttm_page_pool_fill_locked(struct ttm_page_pool
*pool,
pool->fill_lock = true;
/* If allocation request is small and there is not enough
-* pages in pool we fill the pool first */
+* pages in a pool we fill the pool up first. */
if (count < _manager->options.small
&& count > pool->npages) {
struct list_head new_pages;
@@ -612,9 +612,9 @@ static void ttm_page_pool_fill_locked(struct ttm_page_pool
*pool,
}
/**
- * Cut count nubmer of pages from the pool and put them to return list
+ * Cut out a number of pages from the pool and put them on the return list.
*
- * @return count of pages still to allocate to fill the request.
+ * @return count of pages still required to fulfill the request.
*/
static unsigned ttm_page_pool_get_pages(struct ttm_page_pool *pool,
struct list_head *pages, int ttm_flags,
@@ -635,7 +635,7 @@ static unsigned ttm_page_pool_get_pages(struct
ttm_page_pool *pool,
goto out;
}
/* find the last pages to include for requested number of pages. Split
-* pool to begin and halves to reduce search space. */
+* pool to begin and halve it to reduce search space. */
if (count <= pool->npages/2) {
i = 0;
list_for_each(p, >list) {
@@ -649,7 +649,7 @@ static unsigned ttm_page_pool_get_pages(struct
ttm_page_pool *pool,
break;
}
}
- /* Cut count number of pages from pool */
+ /* Cut the count number of pages from the pool */
list_cut_position(pages, >list, p);
pool->npages -= count;
count = 0;
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index 62a0e4c..42e3469 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -662,9 +662,6 @@ extern int ttm_bo_kmap(struct ttm_buffer_object *bo,
unsigned long start_page,
extern void ttm_bo_kunmap(struct ttm_bo_kmap_obj *map);
-#if 0
-#endif
-
/**
* ttm_fbdev_mmap - mmap fbdev memory backed by a ttm buffer object.
*
diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
index 09af2d7..94eb143 100644
--- a/include/drm/ttm/ttm_bo_driver.h
+++ b/include/drm/ttm/ttm_bo_driver.h
@@ -78,7 +78,7 @@ struct ttm_backend_func {
*
* Bind the backend pages into the aperture in the location
* indicated by @bo_mem. This function should be able to handle
-* differences between aperture- and system page sizes.
+* differences between aperture and system page sizes.
*/
int (*bind) (struct ttm_backend *backend, struct ttm_mem_reg *bo_mem);
@@ -88,7 +88,7 @@ struct ttm_backend_func {
* @backend: Pointer to a struct ttm_backend.
*
* Unbind previously bound backend pages. This function should be
-* able to handle differences between aperture- and system page sizes.
+* able to handle differences between aperture and system page sizes.
*/
int (*unbind) (struct ttm_backend *backend);
@@ -786,7 +786,7 @@ extern int ttm_bo_device_release(struct ttm_bo_device
*bdev);
* ttm_bo_device_init
*
* @bdev: A pointer to a struct ttm_bo_device to initialize.
- * @mem_global: A pointer to an initialized struct ttm_mem_global.
+ * @glob: A pointer to an initialized struct ttm_bo_global.
* @driver: A pointer to a struct ttm_bo_driver set up by the caller.
* @file_page_offset: Offset into the device address space that is available
* for buffer data. This ensures
[PATCH] fix spelling mistakes and clear up some wording.
While working on the DMA pool concept in the TTM code I re-read everything once more to make sure I was not missing anything. Whilst doing that I found some spelling mistakes and some wording that could be improved a bit. So fixed it up and please consider this patch for 3.1.
[PATCH/RFC] m68k/bitops: Make bitmap data pointer of atomic ops volatile
On Tue, Jun 07, 2011 at 01:22:29PM +0200, Arnd Bergmann wrote: > On Tuesday 07 June 2011, Geert Uytterhoeven wrote: > > You mean the host_busy variable in the IDE code? > > That would also apply to context_flag in the DRM code: > > > > drivers/gpu/drm/drm_context.c:233: warning: passing argument 2 of > > ?__constant_test_and_set_bit? discards qualifiers from pointer target > > type > > drivers/gpu/drm/drm_context.c:233: warning: passing argument 2 of > > ?__generic_test_and_set_bit? discards qualifiers from pointer target > > type > > Yes, that fits the same category. > > > > is wrong, though. It probably doesn't hurt to do both. > > > > asm-generic/bitops/atomic.h has the volatiles everywhere. That's why > > I'm wondering. > > I guess what happened is that some variables are traditionally marked > as volatile although they shouldn't be, and most architectures have > adapted their bitops to make the warnings go away. If you see more > warnings of that kind, it's probably fine to just do the same on m68k. > The volatile modifier doesn't really hurt in this case. These operations are required to be atomic and therefore they must be suitable for use with volatile-qualified variables. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #22 from Maggioni Marcello 2011-06-07 14:31:57 PDT --- IT WORKS! Yay! :D I kind of imagined that the problem was in the initialization of the memory somehow and this afternoon I was looking at that piece of cone in begin_query, but I completely missing the fact that it wasn't executed! Great guys, you are awesome :) I still have that strange "corruption" at the bottom of the screen (depending on the scene) , but this is a very minor problem when compared with the one you just solved. I'll let you know if I find out other major problems with the game :) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36892] page faults / general protection faults under heavy 3d load
https://bugzilla.kernel.org/show_bug.cgi?id=36892 Niels Ole Salscheider changed: What|Removed |Added CC||niels_ole at salscheider-onlin ||e.de Kernel Version||3.0-rc1 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 36892] page faults / general protection faults under heavy 3d load
https://bugzilla.kernel.org/show_bug.cgi?id=36892 --- Comment #5 from Niels Ole Salscheider 2011-06-07 14:18:17 --- btw: I do not know why it was out of memory in the first error message. I have 8GB of ram but usually less than 4GB are used (most of it for virtuoso-t and nepomukservices) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] gem: RFC: add support for private objects
These small changes should allow GEM to be used with non shmem objects as
well as shmem objects. In the GMA500 case it allows the base framebuffer to
appear as a GEM object and thus acquire a handle and work with KMS.
For i915 it ought to be trivial to get back the wasted memory but putting the
system fb back into stolen RAM and in general I can imagine it allowing the
use of GEM and thus KMS with all the older cards that have their framebuffer
firmly placed in video RAM.
Signed-off-by: Alan Cox
---
drivers/gpu/drm/drm_gem.c | 26 --
include/drm/drmP.h|2 ++
2 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 74e4ff5..d3ae55e 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -128,7 +128,7 @@ drm_gem_destroy(struct drm_device *dev)
}
/**
- * Initialize an already allocate GEM object of the specified size with
+ * Initialize an already allocated GEM object of the specified size with
* shmfs backing store.
*/
int drm_gem_object_init(struct drm_device *dev,
@@ -150,6 +150,27 @@ int drm_gem_object_init(struct drm_device *dev,
EXPORT_SYMBOL(drm_gem_object_init);
/**
+ * Initialize an already allocated GEM object of the specified size with
+ * no GEM provided backing store. Instead the caller is responsible for
+ * backing the object and handling it.
+ */
+int drm_gem_private_object_init(struct drm_device *dev,
+ struct drm_gem_object *obj, size_t size)
+{
+ BUG_ON((size & (PAGE_SIZE - 1)) != 0);
+
+ obj->dev = dev;
+ obj->filp = NULL;
+
+ kref_init(>refcount);
+ atomic_set(>handle_count, 0);
+ obj->size = size;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_gem_private_object_init);
+
+/**
* Allocate a GEM object of the specified size with shmfs backing store
*/
struct drm_gem_object *
@@ -426,7 +447,8 @@ drm_gem_release(struct drm_device *dev, struct drm_file
*file_private)
void
drm_gem_object_release(struct drm_gem_object *obj)
{
- fput(obj->filp);
+ if (obj->filp)
+ fput(obj->filp);
}
EXPORT_SYMBOL(drm_gem_object_release);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 738b3a5..111e98f 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1539,6 +1539,8 @@ struct drm_gem_object *drm_gem_object_alloc(struct
drm_device *dev,
size_t size);
int drm_gem_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size);
+int drm_gem_private_object_init(struct drm_device *dev,
+ struct drm_gem_object *obj, size_t size);
void drm_gem_object_handle_free(struct drm_gem_object *obj);
void drm_gem_vm_open(struct vm_area_struct *vma);
void drm_gem_vm_close(struct vm_area_struct *vma);
[Bug 36892] page faults / general protection faults under heavy 3d load
https://bugzilla.kernel.org/show_bug.cgi?id=36892 --- Comment #3 from Niels Ole Salscheider 2011-06-07 14:14:41 --- Created an attachment (id=61072) --> (https://bugzilla.kernel.org/attachment.cgi?id=61072) kernel message 3 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #21 from Pierre-Eric Pelloux-Prayer 2011-06-07 14:14:30 PDT --- Could you please update your git repo ? agd5f pushed a patch (r600g: always clear query memory) which could correct the problem (you still need to apply the first one too) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36892] page faults / general protection faults under heavy 3d load
https://bugzilla.kernel.org/show_bug.cgi?id=36892 --- Comment #2 from Niels Ole Salscheider 2011-06-07 14:14:24 --- Created an attachment (id=61062) --> (https://bugzilla.kernel.org/attachment.cgi?id=61062) kernel message 2 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 36892] page faults / general protection faults under heavy 3d load
https://bugzilla.kernel.org/show_bug.cgi?id=36892 --- Comment #1 from Niels Ole Salscheider 2011-06-07 14:13:59 --- Created an attachment (id=61052) --> (https://bugzilla.kernel.org/attachment.cgi?id=61052) kernel message -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 36892] New: page faults / general protection faults under heavy 3d load
https://bugzilla.kernel.org/show_bug.cgi?id=36892 Summary: page faults / general protection faults under heavy 3d load Product: Drivers Version: 2.5 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: niels_ole at salscheider-online.de Regression: No I get page faults or general protection faults under heavy 3d load (like "sauerbraten", but sometimes switching windows with kwin is enough) in random processes. I have a radeon hd 6870 and use r600g from mesa git. This happens on 3.0-rc1 and 2.6.39. I am not sure if this is a problem with older kernels, too, since I get gpu lockups with them. I am not sure what could cause these problems, maybe some bug in gem / ttm? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH 1/4] drm: add plane support
On Tue, 7 Jun 2011 13:07:39 -0700 Jesse Barnes wrote: > +#define DRM_MODE_PLANE_FORMAT_YUV422 1 /* YUV 4:2:2 packed */ > +#define DRM_MODE_PLANE_FORMAT_RGBX101010 2 /* RGB 10bpc, ign. alpha */ > +#define DRM_MODE_PLANE_FORMAT_RGBX8883 /* Standard x:8:8:8 > RGB */ > +#define DRM_MODE_PLANE_FORMAT_RGBX161616 4 /* x:16:16:16 float RGB */ > + Oops and ignore these, I knew I left some extras in there somewhere... These are replaced by the V4L defines. -- Jesse Barnes, Intel Open Source Technology Center
[PATCH 1/4] drm: add plane support
On Tue, 7 Jun 2011 13:07:39 -0700
Jesse Barnes wrote:
> +/* Planes blend with or override other bits on the CRTC */
> +struct drm_mode_set_plane {
> + __u32 plane_id;
> + __u32 crtc_id;
> + __u32 fb_id; /* contains surface format type */
> +
> + __u32 crtc_x, crtc_y;
> + __u32 x, y;
> +
> + /* FIXME: color key/mask, scaling, z-order, other? */
> +};
Forgot to add the scaling factors to this. Would:
__u32 scaling_x; /* fixed 16.16 format */
__u32 scaling_y;
work for people?
Color key and z-order can be specified through a new ioctl, as can any
atomic flip that we want to occur with other activity.
--
Jesse Barnes, Intel Open Source Technology Center
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #20 from Maggioni Marcello 2011-06-07
13:56:47 PDT ---
The second patch doesn't solve for ... I don't know if it is a mine specific
problem or if it is universal for all 5850 owners.
this is the output of GDB for the variables you requested in the begin_query
function:
r600_query_begin (ctx=0x635918, query=0x7fe690) at r600_hw_context.c:1651
1651{
(gdb)
1653int num_backends = r600_get_num_backends(ctx->radeon);
(gdb)
1657required_space = 16;
(gdb) disp ctx->max_db
3: ctx->max_db = 8
(gdb) disp num_backends
4: num_backends = 8
(gdb)
Also, I have two cards (using only one of them on linux), I don't know if this
actually may create problems.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[PATCH] drm/radeon/kms: correctness fixes for evergreen/cayman tiling
We don't actually use the tiling setup in the CS checker for
evergreen/cayman yet, but we might as well set it up properly
in case we ever enable it.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c| 15 ---
drivers/gpu/drm/radeon/evergreen_cs.c | 12 +---
drivers/gpu/drm/radeon/ni.c | 12 +++-
drivers/gpu/drm/radeon/radeon.h |3 +++
4 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 9c81b25..76d507c 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2006,14 +2006,23 @@ static void evergreen_gpu_init(struct radeon_device
*rdev)
rdev->config.evergreen.tile_config |= (3 << 0);
break;
}
+ rdev->config.evergreen.tiling_npipes =
rdev->config.evergreen.max_tile_pipes;
/* num banks is 8 on all fusion asics */
if (rdev->flags & RADEON_IS_IGP)
- rdev->config.evergreen.tile_config |= 8 << 4;
+ rdev->config.evergreen.tiling_nbanks = 8;
else
- rdev->config.evergreen.tile_config |=
- ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT) <<
4;
+ rdev->config.evergreen.tiling_nbanks =
+ ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT);
+ rdev->config.evergreen.tile_config |=
+ rdev->config.evergreen.tiling_nbanks << 4;
+ /* group size */
rdev->config.evergreen.tile_config |=
((mc_arb_ramcfg & BURSTLENGTH_MASK) >> BURSTLENGTH_SHIFT) << 8;
+ if (mc_arb_ramcfg & BURSTLENGTH_MASK)
+ rdev->config.evergreen.tiling_group_size = 512;
+ else
+ rdev->config.evergreen.tiling_group_size = 256;
+ /* row size */
rdev->config.evergreen.tile_config |=
((gb_addr_config & 0x3000) >> 28) << 12;
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 7a833dc..7bdaf41 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -1410,9 +1410,15 @@ int evergreen_cs_parse(struct radeon_cs_parser *p)
if (track == NULL)
return -ENOMEM;
evergreen_cs_track_init(track);
- track->npipes = p->rdev->config.evergreen.tiling_npipes;
- track->nbanks = p->rdev->config.evergreen.tiling_nbanks;
- track->group_size = p->rdev->config.evergreen.tiling_group_size;
+ if (p->rdev->family >= CHIP_CAYMAN) {
+ track->npipes = p->rdev->config.cayman.tiling_npipes;
+ track->nbanks = p->rdev->config.cayman.tiling_nbanks;
+ track->group_size =
p->rdev->config.cayman.tiling_group_size;
+ } else {
+ track->npipes = p->rdev->config.evergreen.tiling_npipes;
+ track->nbanks = p->rdev->config.evergreen.tiling_nbanks;
+ track->group_size =
p->rdev->config.evergreen.tiling_group_size;
+ }
p->track = track;
}
do {
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 16caafe..05ab6f9 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -826,10 +826,20 @@ static void cayman_gpu_init(struct radeon_device *rdev)
rdev->config.cayman.tile_config |= (3 << 0);
break;
}
+ rdev->config.cayman.tiling_npipes = rdev->config.cayman.max_tile_pipes;
+ /* num banks */
+ rdev->config.cayman.tiling_nbanks =
+ ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT);
rdev->config.cayman.tile_config |=
- ((mc_arb_ramcfg & NOOFBANK_MASK) >> NOOFBANK_SHIFT) << 4;
+ rdev->config.cayman.tiling_nbanks << 4;
+ /* group size */
rdev->config.cayman.tile_config |=
((gb_addr_config & PIPE_INTERLEAVE_SIZE_MASK) >>
PIPE_INTERLEAVE_SIZE_SHIFT) << 8;
+ if (gb_addr_config & PIPE_INTERLEAVE_SIZE_MASK)
+ rdev->config.cayman.tiling_group_size = 512;
+ else
+ rdev->config.cayman.tiling_group_size = 256;
+ /* row size */
rdev->config.cayman.tile_config |=
((gb_addr_config & ROW_SIZE_MASK) >> ROW_SIZE_SHIFT) << 12;
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 90dc53b..625f1af 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1141,6 +1141,9 @@ struct cayman_asic {
unsigned num_gpus;
unsigned multi_gpu_tile_size;
+ unsigned tiling_nbanks;
+ unsigned tiling_npipes;
+ unsigned tiling_group_size;
unsigned tile_config;
struct r100_gpu_lockup lockup;
};
--
1.7.1.1
[PATCH/RFC] m68k/bitops: Make bitmap data pointer of atomic ops volatile
On Tuesday 07 June 2011, Geert Uytterhoeven wrote: > You mean the host_busy variable in the IDE code? > That would also apply to context_flag in the DRM code: > > drivers/gpu/drm/drm_context.c:233: warning: passing argument 2 of > ?__constant_test_and_set_bit? discards qualifiers from pointer target > type > drivers/gpu/drm/drm_context.c:233: warning: passing argument 2 of > ?__generic_test_and_set_bit? discards qualifiers from pointer target > type Yes, that fits the same category. > > is wrong, though. It probably doesn't hurt to do both. > > asm-generic/bitops/atomic.h has the volatiles everywhere. That's why > I'm wondering. I guess what happened is that some variables are traditionally marked as volatile although they shouldn't be, and most architectures have adapted their bitops to make the warnings go away. If you see more warnings of that kind, it's probably fine to just do the same on m68k. The volatile modifier doesn't really hurt in this case. Arnd
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #19 from Sven Arvidsson 2011-06-07 13:08:38 PDT --- (In reply to comment #17) > What kernel version do you use Sven? I'm using 2.6.39. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 4/4] drm/i915: add SNB video sprite support
The video sprites support video surface formats natively and can handle
scaling well. So add support for them using the new DRM core overlay
support functions.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/Makefile |1 +
drivers/gpu/drm/i915/i915_reg.h | 52 ++
drivers/gpu/drm/i915/intel_display.c | 19 +++-
drivers/gpu/drm/i915/intel_drv.h | 13 +++
drivers/gpu/drm/i915/intel_fb.c |6 +
drivers/gpu/drm/i915/intel_overlay2.c | 172 +
6 files changed, 257 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/i915/intel_overlay2.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 0ae6a7c..6193471 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -28,6 +28,7 @@ i915-y := i915_drv.o i915_dma.o i915_irq.o i915_mem.o \
intel_dvo.o \
intel_ringbuffer.o \
intel_overlay.o \
+ intel_overlay2.o \
intel_opregion.o \
dvo_ch7xxx.o \
dvo_ch7017.o \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2f967af..c81c4e7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2627,6 +2627,58 @@
#define _DSPBSURF 0x7119C
#define _DSPBTILEOFF 0x711A4
+/* Sprite A control */
+#define _DVSACNTR 0x72180
+#define DVS_ENABLE (1<<31)
+#define DVS_GAMMA_ENABLE (1<<30)
+#define DVS_PIXFORMAT_MASK (3<<25)
+#define DVS_FORMAT_YUV422(0<<25)
+#define DVS_FORMAT_RGBX101010(1<<25)
+#define DVS_FORMAT_RGBX888 (2<<25)
+#define DVS_FORMAT_RGBX161616(3<<25)
+#define DVS_SOURCE_KEY (1<<22)
+#define DVS_RGB_ORDER_RGBX (1<<20)
+#define DVS_YUV_BYTE_ORDER_MASK (3<<16)
+#define DVS_YUV_ORDER_YUYV (0<<16)
+#define DVS_YUV_ORDER_UYVY (1<<16)
+#define DVS_YUV_ORDER_YVYU (2<<16)
+#define DVS_YUV_ORDER_VYUY (3<<16)
+#define DVS_DEST_KEY (1<<2)
+#define DVS_TRICKLE_FEED_DISABLE (1<<14)
+#define DVS_TILED(1<<10)
+#define _DVSASTRIDE0x72188
+#define _DVSAPOS 0x7218c
+#define _DVSASIZE 0x72190
+#define _DVSAKEYVAL0x72194
+#define _DVSAKEYMSK0x72198
+#define _DVSASURF 0x7219c
+#define _DVSAKEYMAXVAL 0x721a0
+#define _DVSATILEOFF 0x721a4
+#define _DVSASURFLIVE 0x721ac
+#define _DVSASCALE 0x72204
+#define _DVSAGAMC 0x72300
+
+#define _DVSBCNTR 0x73180
+#define _DVSBSTRIDE0x73188
+#define _DVSBPOS 0x7318c
+#define _DVSBSIZE 0x73190
+#define _DVSBKEYVAL0x73194
+#define _DVSBKEYMSK0x73198
+#define _DVSBSURF 0x7319c
+#define _DVSBKEYMAXVAL 0x731a0
+#define _DVSBTILEOFF 0x731a4
+#define _DVSBSURFLIVE 0x731ac
+#define _DVSBSCALE 0x73204
+#define _DVSBGAMC 0x73300
+
+#define DVSCNTR(pipe) _PIPE(pipe, _DVSACNTR, _DVSBCNTR)
+#define DVSSTRIDE(pipe) _PIPE(pipe, _DVSASTRIDE, _DVSBSTRIDE)
+#define DVSPOS(pipe) _PIPE(pipe, _DVSAPOS, _DVSBPOS)
+#define DVSSURF(pipe) _PIPE(pipe, _DVSASURF, _DVSBSURF)
+#define DVSSIZE(pipe) _PIPE(pipe, _DVSASIZE, _DVSBSIZE)
+#define DVSSCALE(pipe) _PIPE(pipe, _DVSASCALE, _DVSBSCALE)
+#define DVSTILEOFF(pipe) _PIPE(pipe, _DVSATILEOFF, _DVSBTILEOFF)
+
/* VBIOS regs */
#define VGACNTRL 0x71400
# define VGA_DISP_DISABLE (1 << 31)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7901f16..72a570a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -900,8 +900,8 @@ static void assert_panel_unlocked(struct drm_i915_private
*dev_priv,
pipe_name(pipe));
}
-static void assert_pipe(struct drm_i915_private *dev_priv,
- enum pipe pipe, bool state)
+void assert_pipe(struct drm_i915_private *dev_priv,
+enum pipe pipe, bool state)
{
int reg;
u32 val;
@@ -914,8 +914,6 @@ static void assert_pipe(struct drm_i915_private *dev_priv,
"pipe %c assertion failure (expected %s, current %s)\n",
pipe_name(pipe), state_string(state), state_string(cur_state));
}
-#define assert_pipe_enabled(d, p) assert_pipe(d, p, true)
-#define assert_pipe_disabled(d, p) assert_pipe(d, p, false)
static void assert_plane_enabled(struct drm_i915_private *dev_priv,
enum plane plane)
@@ -4319,7 +4317,8 @@ static void sandybridge_update_wm(struct drm_device *dev)
_cursor_wm_info, latency,
_wm, _wm)) {
I915_WRITE(WM0_PIPEA_ILK,
- (plane_wm << WM0_PIPE_PLANE_SHIFT) | cursor_wm);
+ (plane_wm <<
[PATCH 3/4] drm/i915: rename existing overlay support to "legacy"
The old overlay block has all sorts of quirks and is very different than
ILK+ video sprites. So rename it to legacy to make that clear and clash
less with core overlay support.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_debugfs.c |2 +-
drivers/gpu/drm/i915/i915_drv.h | 12 ++--
drivers/gpu/drm/i915/i915_irq.c |2 +-
drivers/gpu/drm/i915/intel_display.c |2 +-
drivers/gpu/drm/i915/intel_drv.h |4 +-
drivers/gpu/drm/i915/intel_overlay.c | 126 +-
6 files changed, 74 insertions(+), 74 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 51c2257..c83ed15 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -825,7 +825,7 @@ static int i915_error_state(struct seq_file *m, void
*unused)
}
if (error->overlay)
- intel_overlay_print_error_state(m, error->overlay);
+ intel_legacy_overlay_print_error_state(m, error->overlay);
if (error->display)
intel_display_print_error_state(m, dev, error->display);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 31e199f..062e80e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -117,8 +117,8 @@ struct intel_opregion {
};
#define OPREGION_SIZE(8*1024)
-struct intel_overlay;
-struct intel_overlay_error_state;
+struct intel_legacy_overlay;
+struct intel_legacy_overlay_error_state;
struct drm_i915_master_private {
drm_local_map_t *sarea;
@@ -191,7 +191,7 @@ struct drm_i915_error_state {
u32 cache_level:2;
} *active_bo, *pinned_bo;
u32 active_bo_count, pinned_bo_count;
- struct intel_overlay_error_state *overlay;
+ struct intel_legacy_overlay_error_state *overlay;
struct intel_display_error_state *display;
};
@@ -336,7 +336,7 @@ typedef struct drm_i915_private {
struct intel_opregion opregion;
/* overlay */
- struct intel_overlay *overlay;
+ struct intel_legacy_overlay *overlay;
/* LVDS info */
int backlight_level; /* restore backlight to this value */
@@ -1329,8 +1329,8 @@ extern int intel_trans_dp_port_sel (struct drm_crtc
*crtc);
/* overlay */
#ifdef CONFIG_DEBUG_FS
-extern struct intel_overlay_error_state
*intel_overlay_capture_error_state(struct drm_device *dev);
-extern void intel_overlay_print_error_state(struct seq_file *m, struct
intel_overlay_error_state *error);
+extern struct intel_legacy_overlay_error_state
*intel_legacy_overlay_capture_error_state(struct drm_device *dev);
+extern void intel_legacy_overlay_print_error_state(struct seq_file *m, struct
intel_legacy_overlay_error_state *error);
extern struct intel_display_error_state
*intel_display_capture_error_state(struct drm_device *dev);
extern void intel_display_print_error_state(struct seq_file *m,
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b79619a..7a34167 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -991,7 +991,7 @@ static void i915_capture_error_state(struct drm_device *dev)
do_gettimeofday(>time);
- error->overlay = intel_overlay_capture_error_state(dev);
+ error->overlay = intel_legacy_overlay_capture_error_state(dev);
error->display = intel_display_capture_error_state(dev);
spin_lock_irqsave(_priv->error_lock, flags);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8a6e3ab..7901f16 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2936,7 +2936,7 @@ static void intel_crtc_dpms_overlay(struct intel_crtc
*intel_crtc, bool enable)
mutex_lock(>struct_mutex);
dev_priv->mm.interruptible = false;
- (void) intel_overlay_switch_off(intel_crtc->overlay);
+ (void) intel_legacy_overlay_switch_off(intel_crtc->overlay);
dev_priv->mm.interruptible = true;
mutex_unlock(>struct_mutex);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3cfc391..d73e622 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -161,7 +161,7 @@ struct intel_crtc {
bool busy; /* is scanout buffer being updated frequently? */
struct timer_list idle_timer;
bool lowfreq_avail;
- struct intel_overlay *overlay;
+ struct intel_legacy_overlay *overlay;
struct intel_unpin_work *unpin_work;
int fdi_lanes;
@@ -337,7 +337,7 @@ extern void intel_finish_page_flip_plane(struct drm_device
*dev, int plane);
extern void intel_setup_overlay(struct drm_device *dev);
extern void intel_cleanup_overlay(struct drm_device *dev);
-extern int intel_overlay_switch_off(struct
[PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c| 71 -
drivers/gpu/drm/drm_crtc_helper.c |3 +-
drivers/gpu/drm/drm_drv.c |1 +
drivers/gpu/drm/i915/intel_display.c |9 ++--
drivers/gpu/drm/i915/intel_drv.h |2 +-
drivers/gpu/drm/i915/intel_fb.c |3 +-
drivers/gpu/drm/nouveau/nouveau_display.c |4 +-
drivers/gpu/drm/radeon/radeon_display.c |4 +-
drivers/gpu/drm/radeon/radeon_fb.c|5 +-
drivers/gpu/drm/radeon/radeon_mode.h |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |2 +-
drivers/staging/gma500/psb_fb.c |2 +-
include/drm/drm.h |1 +
include/drm/drm_crtc.h|6 ++-
include/drm/drm_crtc_helper.h |2 +-
include/drm/drm_mode.h| 14 ++
16 files changed, 112 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index dd6d149..b499cbf 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1910,7 +1910,76 @@ out:
int drm_mode_addfb(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
- struct drm_mode_fb_cmd *r = data;
+ struct drm_mode_fb_cmd *or = data;
+ struct drm_mode_fb_cmd2 r;
+ struct drm_mode_config *config = >mode_config;
+ struct drm_framebuffer *fb;
+ int ret = 0;
+
+ /* Use new struct with format internally */
+ r.fb_id = or->fb_id;
+ r.width = or->width;
+ r.height = or->height;
+ r.pitch = or->pitch;
+ r.bpp = or->bpp;
+ r.depth = or->depth;
+ r.pixel_format = 0;
+ r.handle = or->handle;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ if ((config->min_width > r.width) || (r.width > config->max_width)) {
+ DRM_ERROR("mode new framebuffer width not within limits\n");
+ return -EINVAL;
+ }
+ if ((config->min_height > r.height) || (r.height > config->max_height))
{
+ DRM_ERROR("mode new framebuffer height not within limits\n");
+ return -EINVAL;
+ }
+
+ mutex_lock(>mode_config.mutex);
+
+ /* TODO check buffer is sufficiently large */
+ /* TODO setup destructor callback */
+
+ fb = dev->mode_config.funcs->fb_create(dev, file_priv, );
+ if (IS_ERR(fb)) {
+ DRM_ERROR("could not create framebuffer\n");
+ ret = PTR_ERR(fb);
+ goto out;
+ }
+
+ or->fb_id = fb->base.id;
+ list_add(>filp_head, _priv->fbs);
+ DRM_DEBUG_KMS("[FB:%d]\n", fb->base.id);
+
+out:
+ mutex_unlock(>mode_config.mutex);
+ return ret;
+}
+
+/**
+ * drm_mode_addfb2 - add an FB to the graphics configuration
+ * @inode: inode from the ioctl
+ * @filp: file * from the ioctl
+ * @cmd: cmd from ioctl
+ * @arg: arg from ioctl
+ *
+ * LOCKING:
+ * Takes mode config lock.
+ *
+ * Add a new FB to the specified CRTC, given a user request with format.
+ *
+ * Called by the user via ioctl.
+ *
+ * RETURNS:
+ * Zero on success, errno on failure.
+ */
+int drm_mode_addfb2(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+ struct drm_mode_fb_cmd2 *r = data;
struct drm_mode_config *config = >mode_config;
struct drm_framebuffer *fb;
int ret = 0;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 9236965..5adab04 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -801,13 +801,14 @@ void drm_helper_connector_dpms(struct drm_connector
*connector, int mode)
EXPORT_SYMBOL(drm_helper_connector_dpms);
int drm_helper_mode_fill_fb_struct(struct drm_framebuffer *fb,
- struct drm_mode_fb_cmd *mode_cmd)
+ struct drm_mode_fb_cmd2 *mode_cmd)
{
fb->width = mode_cmd->width;
fb->height = mode_cmd->height;
fb->pitch = mode_cmd->pitch;
fb->bits_per_pixel = mode_cmd->bpp;
fb->depth = mode_cmd->depth;
+ fb->pixel_format = mode_cmd->pixel_format;
return 0;
}
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 15da618..f24b9b6 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -152,6 +152,7 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb,
[PATCH 1/4] drm: add plane support
Planes are a bit like half-CRTCs. They have a location and fb, but
don't drive outputs directly. Add support for handling them to the core
KMS code.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c | 230
drivers/gpu/drm/drm_drv.c |3 +
include/drm/drm.h |3 +
include/drm/drm_crtc.h | 69 +-
include/drm/drm_mode.h | 39
5 files changed, 343 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 872747c..dd6d149 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -533,6 +533,45 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
}
EXPORT_SYMBOL(drm_encoder_cleanup);
+void drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
+ const struct drm_plane_funcs *funcs,
+ uint32_t *formats, uint32_t format_count)
+{
+ mutex_lock(>mode_config.mutex);
+
+ plane->dev = dev;
+ drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_PLANE);
+ plane->funcs = funcs;
+ plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
+ GFP_KERNEL);
+ if (!plane->format_types) {
+ DRM_DEBUG_KMS("out of memory when allocating plane\n");
+ drm_mode_object_put(dev, >base);
+ return;
+ }
+
+ memcpy(plane->format_types, formats, format_count);
+ plane->format_count = format_count;
+
+ list_add_tail(>head, >mode_config.plane_list);
+ dev->mode_config.num_plane++;
+
+ mutex_unlock(>mode_config.mutex);
+}
+EXPORT_SYMBOL(drm_plane_init);
+
+void drm_plane_cleanup(struct drm_plane *plane)
+{
+ struct drm_device *dev = plane->dev;
+
+ mutex_lock(>mode_config.mutex);
+ drm_mode_object_put(dev, >base);
+ list_del(>head);
+ dev->mode_config.num_plane--;
+ mutex_unlock(>mode_config.mutex);
+}
+EXPORT_SYMBOL(drm_plane_cleanup);
+
/**
* drm_mode_create - create a new display mode
* @dev: DRM device
@@ -864,6 +903,7 @@ void drm_mode_config_init(struct drm_device *dev)
INIT_LIST_HEAD(>mode_config.encoder_list);
INIT_LIST_HEAD(>mode_config.property_list);
INIT_LIST_HEAD(>mode_config.property_blob_list);
+ INIT_LIST_HEAD(>mode_config.plane_list);
idr_init(>mode_config.crtc_idr);
mutex_lock(>mode_config.mutex);
@@ -1467,6 +1507,196 @@ out:
}
/**
+ * drm_mode_getplane_res - get plane info
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Return an plane count and set of IDs.
+ */
+int drm_mode_getplane_res(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_get_plane_res *plane_resp = data;
+ struct drm_mode_config *config;
+ struct drm_plane *plane;
+ uint32_t __user *plane_ptr;
+ int copied = 0, ret = 0;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ mutex_lock(>mode_config.mutex);
+ config = >mode_config;
+
+ /*
+* This ioctl is called twice, once to determine how much space is
+* needed, and the 2nd time to fill it.
+*/
+ if (config->num_plane &&
+ (plane_resp->count_planes >= config->num_plane)) {
+ plane_ptr = (uint32_t *)(unsigned long)plane_resp->plane_id_ptr;
+
+ list_for_each_entry(plane, >plane_list, head) {
+ if (put_user(plane->base.id, plane_ptr + copied)) {
+ ret = -EFAULT;
+ goto out;
+ }
+ copied++;
+ }
+ }
+ plane_resp->count_planes = config->num_plane;
+
+out:
+ mutex_unlock(>mode_config.mutex);
+ return ret;
+}
+
+/**
+ * drm_mode_getplane - get plane info
+ * @dev: DRM device
+ * @data: ioctl data
+ * @file_priv: DRM file info
+ *
+ * Return plane info, including formats supported, gamma size, any
+ * current fb, etc.
+ */
+int drm_mode_getplane(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+ struct drm_mode_get_plane *plane_resp = data;
+ struct drm_mode_object *obj;
+ struct drm_plane *plane;
+ uint32_t __user *format_ptr;
+ int ret = 0;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ mutex_lock(>mode_config.mutex);
+ obj = drm_mode_object_find(dev, plane_resp->plane_id,
+ DRM_MODE_OBJECT_PLANE);
+ if (!obj) {
+ ret = -EINVAL;
+ goto out;
+ }
+ plane = obj_to_plane(obj);
+
+ if (plane->crtc)
+ plane_resp->crtc_id = plane->crtc->base.id;
+ else
+ plane_resp->crtc_id = 0;
+
+ if (plane->fb)
+
[RFC] Updated DRM plane handling patches
This patchset updates the previous one, incorporating the feedback I received: 1) uses the v4l fourcc codes to communicate pixel format 2) adds a new addfb ioctl that takes a format 3) adds working SNB support for the new code Comments welcome. I'll be pushing intel-gpu-tools testdisplay support for this shortly if people want to play around with it. Next step is to incorporate it into X and Wayland to see if the API is rich enough for our needs. Thanks, Jesse
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #18 from Pierre-Eric Pelloux-Prayer 2011-06-07 12:52:35 PDT --- Created an attachment (id=47680) View: https://bugs.freedesktop.org/attachment.cgi?id=47680 Review: https://bugs.freedesktop.org/review?bug=37028=47680 2nd patch Here's a second patch to add. It removes some memory initialization logic which seems to be wrong (thanks agd5f for the help). Marcello could you please test it ? (in addition to the 1st patch) If it's still wrong, could you tell me which value the 'num_backends' and 'ctx->max_db' variables have (both in r600_query_begin for instance) ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #17 from Maggioni Marcello 2011-06-07 12:47:00 PDT --- What kernel version do you use Sven? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 5/5] DRM: Add i.MX IPUv3 support
This adds a i.MX51/53 IPU (Image Processing Unit) KMS driver. The
driver has been tested on the i.MX51 babbage board and the i.MX53
LOCO board in different clone mode and dual head setups.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/Kconfig|9 +
drivers/gpu/drm/imx/Makefile |2 +
drivers/gpu/drm/imx/imx-drm.c | 936
drivers/gpu/drm/imx/imx-priv.h |9 +
4 files changed, 956 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/imx/imx-drm.c
create mode 100644 drivers/gpu/drm/imx/imx-priv.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 01d5444..93a2c5a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -177,3 +177,12 @@ config DRM_IMX_IPUV3
depends on DRM && ARCH_MXC
help
Choose this if you have a i.MX51/53 processor.
+
+config DRM_IMX
+ tristate "i.MX IPUv3 drm support"
+ depends on DRM_IMX_IPUV3
+ select DRM_KMS_ENCON
+ select DRM_KMS_HELPER
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
index 776e6b4..0a53cf4 100644
--- a/drivers/gpu/drm/imx/Makefile
+++ b/drivers/gpu/drm/imx/Makefile
@@ -1 +1,3 @@
obj-$(CONFIG_DRM_IMX_IPUV3) += ipu-v3/
+
+obj-$(CONFIG_DRM_IMX) += imx-drm.o
diff --git a/drivers/gpu/drm/imx/imx-drm.c b/drivers/gpu/drm/imx/imx-drm.c
new file mode 100644
index 000..e9857c9
--- /dev/null
+++ b/drivers/gpu/drm/imx/imx-drm.c
@@ -0,0 +1,936 @@
+/*
+ * i.MX IPUv3 Graphics driver
+ *
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME"i.MX"
+#define DRIVER_DESC"i.MX IPUv3 Graphics"
+#define DRIVER_DATE"20110604"
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+#define DRIVER_PATCHLEVEL 0
+
+struct ipu_resource {
+ int ipu_channel_bg;
+ int dc_channel;
+ int dp_channel;
+ int display;
+ u32 interface_pix_fmt; /* FIXME: move to platform data */
+};
+
+static struct ipu_resource ipu_resources[] = {
+ {
+ .ipu_channel_bg = 23, /* IPUV3_CHANNEL_MEM_BG_SYNC */
+ .dc_channel = 5,
+ .dp_channel = IPU_DP_FLOW_SYNC_BG,
+ .display = 0,
+ .interface_pix_fmt = IPU_PIX_FMT_RGB24,
+ } , {
+ .ipu_channel_bg = 28, /* IPUV3_CHANNEL_MEM_DC_SYNC */
+ .dc_channel = 1,
+ .dp_channel = -1,
+ .display = 1,
+ .interface_pix_fmt = IPU_PIX_FMT_RGB565,
+ },
+};
+
+struct ipu_crtc {
+ struct drm_crtc base;
+ int pipe;
+ struct ipu_resource *ipu_res;
+ struct ipu_channel *ipu_ch;
+ struct ipu_dc *dc;
+ struct ipu_dp *dp;
+ struct dmfc_channel *dmfc;
+ struct ipu_di *di;
+ int di_no;
+ struct clk *pixclk;
+ int enabled;
+};
+
+struct ipu_framebuffer {
+ struct drm_framebuffer base;
+ void*virt;
+ dma_addr_t phys;
+ size_t len;
+};
+
+struct ipu_drm_private {
+ struct ipu_crtc crtc[2];
+ struct drm_encoder_connector *encon[2];
+ struct drm_fb_helperfb_helper;
+ struct ipu_framebuffer ifb;
+ int num_crtcs;
+};
+
+static struct fb_ops ipu_ipufb_ops = {
+ .owner = THIS_MODULE,
+ .fb_check_var = drm_fb_helper_check_var,
+ .fb_set_par = drm_fb_helper_set_par,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+ .fb_pan_display = drm_fb_helper_pan_display,
+ .fb_blank = drm_fb_helper_blank,
+ .fb_setcmap = drm_fb_helper_setcmap,
+ .fb_debug_enter = drm_fb_helper_debug_enter,
+ .fb_debug_leave = drm_fb_helper_debug_leave,
+};
+
+#define to_ipu_framebuffer(x) container_of(x, struct ipu_framebuffer, base)
[PATCH 3/5] DRM: Add drm encoder/connector helper
At least in the embedded world encoders and connectors are not
at all visible in software. Often enough there is a 1:1
relationship between encoders and connectors. Add helpers to
handle this case and to ease driver implementation for SoCs.
Signed-off-by: Sascha Hauer
---
drivers/gpu/drm/Kconfig |7 +
drivers/gpu/drm/Makefile|1 +
drivers/gpu/drm/drm_encon.c | 302 +++
include/drm/drm_encon.h | 46 +++
4 files changed, 356 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/drm_encon.c
create mode 100644 include/drm/drm_encon.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 969dc38..bcd9a27 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -28,6 +28,13 @@ config DRM_KMS_HELPER
help
FB and CRTC helpers for KMS drivers.
+config DRM_KMS_ENCON
+ tristate
+ depends on DRM
+ help
+ helper for KMS drivers which use connectors and encoders with
+ a 1:1 relationship
+
config DRM_TTM
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 97c35eb..19a1aec 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -19,6 +19,7 @@ drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm_kms_helper-y := drm_fb_helper.o drm_crtc_helper.o drm_dp_i2c_helper.o
obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o
+obj-$(CONFIG_DRM_KMS_ENCON) += drm_encon.o
CFLAGS_drm_trace_points.o := -I$(src)
diff --git a/drivers/gpu/drm/drm_encon.c b/drivers/gpu/drm/drm_encon.c
new file mode 100644
index 000..42d46c8
--- /dev/null
+++ b/drivers/gpu/drm/drm_encon.c
@@ -0,0 +1,302 @@
+/*
+ * Implementation of a 1:1 relationship for drm encoders and connectors
+ *
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+#include
+#include
+#include
+#include
+#include
+
+#define con_to_encon(x) container_of(x, struct drm_encoder_connector,
connector)
+#define enc_to_encon(x) container_of(x, struct drm_encoder_connector, encoder)
+
+static enum drm_connector_status connector_detect(struct drm_connector
*connector,
+ bool force)
+{
+ struct drm_encoder_connector *encon = con_to_encon(connector);
+
+ if (encon->funcs->detect)
+ return encon->funcs->detect(encon);
+
+ return connector_status_connected;
+}
+
+static int connector_set_property(struct drm_connector *connector,
+ struct drm_property *property, uint64_t val)
+{
+ struct drm_encoder_connector *encon = con_to_encon(connector);
+
+ if (encon->funcs->set_property)
+ return encon->funcs->set_property(encon, property, val);
+
+ return -EINVAL;
+}
+
+static void connector_destroy(struct drm_connector *connector)
+{
+ /* not here */
+}
+
+static int connector_get_modes(struct drm_connector *connector)
+{
+ struct drm_encoder_connector *encon = con_to_encon(connector);
+
+ if (encon->funcs->get_modes)
+ return encon->funcs->get_modes(encon);
+
+ return 0;
+}
+
+static int connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+ struct drm_encoder_connector *encon = con_to_encon(connector);
+
+ if (encon->funcs && encon->funcs->mode_valid)
+ return encon->funcs->mode_valid(encon, mode);
+
+ return 0;
+}
+
+static struct drm_encoder *connector_best_encoder(struct drm_connector
*connector)
+{
+ struct drm_encoder_connector *encon = con_to_encon(connector);
+
+ return >encoder;
+}
+
+static void encoder_reset(struct drm_encoder *encoder)
+{
+ struct drm_encoder_connector *encon = enc_to_encon(encoder);
+
+ if (encon->funcs && encon->funcs->reset)
+ encon->funcs->reset(encon);
+}
+
+static void encoder_dpms(struct drm_encoder *encoder, int mode)
+{
+ struct drm_encoder_connector *encon = enc_to_encon(encoder);
+
+ if (encon->funcs->dpms)
+ encon->funcs->dpms(encon, mode);
+}
+
+static bool encoder_mode_fixup(struct drm_encoder *encoder,
+ struct drm_display_mode *mode,
+ struct drm_display_mode
[RFC PATCH] KMS support for i.MX51/53
Hi All, The following adds a KMS driver for the Freescale i.MX51/53 SoCs. It is far from being ready but I think it is enough to send it out and get the first comments on it and to show that there's something going on. Currently I don't use any sophisticated memory allocater like GEM or similar. I helped myself with simple dma_alloc where needed. At the current state I don't need any more sophisticated allocator as I only focused on the KMS part. Many dumb framebuffers on embedded systems could use a simple allocator at least until something better usable for these kind of systems shows up. The driver currently does its allocations in the DRM_IOCTL_MODE_ADDFB ioctl, which of course is not very standard conform. I tested this driver on the i.MX51 with a DVI and VGA display connected in different clone and dual head modes. Also tested is the i.MX53 LOCO board with the optional HDMI adapter (I didn't get the TV encoder for VGA to work though). First part of the series is the IPU base driver which has been posted several times before, this time with generic interrupt support and fully multi instance safe. Also several smaller improvements have been made. For the DRM people probably only the last three patches are of interest. The series depends on several other patches not posted here. So for those who want to test this please pull the following branch: git://git.pengutronix.de/git/imx/linux-2.6.git imx-ipu-kms As said the driver is not fully standard conform and libkms currently is not suitable for this driver, so the only test utility (apart from the legacy framebuffer) is a little selfmade tool you can get here: git://git.pengutronix.de/git/sha/kmstest.git It is basically a KMS wrapper around the well known fbtest utility. Different mode settings can be supplied on the command line. A README is included. Sascha Sascha Hauer (5): DRM: add i.MX IPUv3 base driver DRM i.MX IPU: Add support for IPU submodules DRM: Add drm encoder/connector helper DRM: Add support for the sii902x HDMI/DVI encoder DRM: Add i.MX IPUv3 support arch/arm/plat-mxc/include/mach/ipu-v3.h | 22 + drivers/gpu/drm/Kconfig | 28 + drivers/gpu/drm/Makefile|2 + drivers/gpu/drm/drm_encon.c | 302 ++ drivers/gpu/drm/i2c/Makefile|3 + drivers/gpu/drm/i2c/sii902x.c | 334 +++ drivers/gpu/drm/imx/Makefile|3 + drivers/gpu/drm/imx/imx-drm.c | 936 +++ drivers/gpu/drm/imx/imx-priv.h |9 + drivers/gpu/drm/imx/ipu-v3/Makefile |3 + drivers/gpu/drm/imx/ipu-v3/ipu-common.c | 799 ++ drivers/gpu/drm/imx/ipu-v3/ipu-dc.c | 440 +++ drivers/gpu/drm/imx/ipu-v3/ipu-di.c | 665 ++ drivers/gpu/drm/imx/ipu-v3/ipu-dmfc.c | 393 + drivers/gpu/drm/imx/ipu-v3/ipu-dp.c | 342 +++ drivers/gpu/drm/imx/ipu-v3/ipu-prv.h| 218 +++ include/drm/drm_encon.h | 46 ++ include/drm/imx-ipu-v3.h| 308 ++ 18 files changed, 4853 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-mxc/include/mach/ipu-v3.h create mode 100644 drivers/gpu/drm/drm_encon.c create mode 100644 drivers/gpu/drm/i2c/sii902x.c create mode 100644 drivers/gpu/drm/imx/Makefile create mode 100644 drivers/gpu/drm/imx/imx-drm.c create mode 100644 drivers/gpu/drm/imx/imx-priv.h create mode 100644 drivers/gpu/drm/imx/ipu-v3/Makefile create mode 100644 drivers/gpu/drm/imx/ipu-v3/ipu-common.c create mode 100644 drivers/gpu/drm/imx/ipu-v3/ipu-dc.c create mode 100644 drivers/gpu/drm/imx/ipu-v3/ipu-di.c create mode 100644 drivers/gpu/drm/imx/ipu-v3/ipu-dmfc.c create mode 100644 drivers/gpu/drm/imx/ipu-v3/ipu-dp.c create mode 100644 drivers/gpu/drm/imx/ipu-v3/ipu-prv.h create mode 100644 include/drm/drm_encon.h create mode 100644 include/drm/imx-ipu-v3.h
[PATCH 1/5] DRM: add i.MX IPUv3 base driver
Hi Sascha,
On Tue, Jun 7, 2011 at 7:45 AM, Sascha Hauer wrote:
...
> +static int __init imx_ipu_init(void)
> +{
> + ? ? ? int32_t ret;
> +
> + ? ? ? ret = platform_driver_register(_ipu_driver);
> + ? ? ? return 0;
Did you intend to return ret here instead?
Regards,
Fabio Estevam
[PATCH] ttm: Fix spelling mistakes and remove unused #ifdef
On Tue, 7 Jun 2011 14:35:52 -0400 Konrad Rzeszutek Wilk wrote:
> . and some comments to make it easier to understand.
>
> Signed-off-by: Konrad Rzeszutek Wilk
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 14 +++---
> include/drm/ttm/ttm_bo_api.h |3 ---
> include/drm/ttm/ttm_bo_driver.h |6 +++---
> include/drm/ttm/ttm_memory.h |2 +-
> include/drm/ttm/ttm_object.h |4 ++--
> include/drm/ttm/ttm_page_alloc.h |2 +-
> 6 files changed, 14 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> index 9d9d929..3277965 100644
> --- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
> +++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
> @@ -355,7 +355,7 @@ restart:
> if (nr_free)
> goto restart;
>
> - /* Not allowed to fall tough or break because
> + /* Not allowed to fall through or break because
>* following context is inside spinlock while we are
>* outside here.
>*/
> @@ -554,7 +554,7 @@ out:
> }
>
> /**
> - * Fill the given pool if there isn't enough pages and requested number of
> + * Fill the given pool if there isn't enough pages and the requested number
> of
aren't
> * pages is small.
> */
> static void ttm_page_pool_fill_locked(struct ttm_page_pool *pool,
> @@ -575,7 +575,7 @@ static void ttm_page_pool_fill_locked(struct
> ttm_page_pool *pool,
> pool->fill_lock = true;
>
> /* If allocation request is small and there is not enough
are not enough
> - * pages in pool we fill the pool first */
> + * pages in a pool we fill the pool up first. */
> if (count < _manager->options.small
> && count > pool->npages) {
> struct list_head new_pages;
> @@ -612,9 +612,9 @@ static void ttm_page_pool_fill_locked(struct
> ttm_page_pool *pool,
> }
>
> /**
> - * Cut count nubmer of pages from the pool and put them to return list
> + * Cut out a number of pages from the pool and put them on the return list.
No, it wants 'count' or in there, like:
* Cut 'count' number of pages from the pool and put them on the return list.
> *
> - * @return count of pages still to allocate to fill the request.
> + * @return count of pages still required to fulfill the request.
> */
> static unsigned ttm_page_pool_get_pages(struct ttm_page_pool *pool,
> struct list_head *pages, int ttm_flags,
> @@ -635,7 +635,7 @@ static unsigned ttm_page_pool_get_pages(struct
> ttm_page_pool *pool,
> goto out;
> }
> /* find the last pages to include for requested number of pages. Split
> - * pool to begin and halves to reduce search space. */
> + * pool to begin and halve it to reduce search space. */
> if (count <= pool->npages/2) {
> i = 0;
> list_for_each(p, >list) {
> @@ -649,7 +649,7 @@ static unsigned ttm_page_pool_get_pages(struct
> ttm_page_pool *pool,
> break;
> }
> }
> - /* Cut count number of pages from pool */
> + /* Cut the count number of pages from the pool */
Not any better IMO. How about:
/* Cut number of pages from the pool */
or
/* Cut 'count' number of pages from the pool */
> list_cut_position(pages, >list, p);
> pool->npages -= count;
> count = 0;
[snip]
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
[PATCH 2/4] drm: add an fb creation ioctl that takes a pixel format
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from videodev2.h.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_crtc.c| 105 -
drivers/gpu/drm/drm_crtc_helper.c | 50 +-
drivers/gpu/drm/drm_drv.c |1 +
drivers/gpu/drm/i915/intel_display.c | 34 +-
drivers/gpu/drm/i915/intel_drv.h |2 +-
drivers/gpu/drm/i915/intel_fb.c | 11 ++--
drivers/gpu/drm/nouveau/nouveau_display.c |4 +-
drivers/gpu/drm/radeon/radeon_display.c |4 +-
drivers/gpu/drm/radeon/radeon_fb.c| 18 +++--
drivers/gpu/drm/radeon/radeon_mode.h |2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |2 +-
drivers/staging/gma500/framebuffer.c |2 +-
include/drm/drm.h |1 +
include/drm/drm_crtc.h|7 ++-
include/drm/drm_crtc_helper.h |4 +-
include/drm/drm_mode.h| 26 +++
include/linux/videodev2.h |1 +
17 files changed, 231 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index cea209a..869e177 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1894,6 +1894,42 @@ out:
return ret;
}
+/* Original addfb only supported RGB formats, so figure out which one */
+uint32_t drm_mode_legacy_fb_format(uint32_t bpp, uint32_t depth)
+{
+ uint32_t fmt;
+
+ switch (bpp) {
+ case 8:
+ fmt = V4L2_PIX_FMT_RGB332;
+ break;
+ case 16:
+ if (depth == 15)
+ fmt = V4L2_PIX_FMT_RGB555;
+ else
+ fmt = V4L2_PIX_FMT_RGB565;
+ break;
+ case 24:
+ fmt = V4L2_PIX_FMT_RGB24;
+ break;
+ case 32:
+ if (depth == 24)
+ fmt = V4L2_PIX_FMT_RGB24;
+ else if (depth == 30)
+ fmt = V4L2_PIX_FMT_INTC_RGB30;
+ else
+ fmt = V4L2_PIX_FMT_RGB32;
+ break;
+ default:
+ DRM_ERROR("bad bpp, assuming RGB24 pixel format\n");
+ fmt = V4L2_PIX_FMT_RGB24;
+ break;
+ }
+
+ return fmt;
+}
+EXPORT_SYMBOL(drm_mode_legacy_fb_format);
+
/**
* drm_mode_addfb - add an FB to the graphics configuration
* @inode: inode from the ioctl
@@ -1914,7 +1950,74 @@ out:
int drm_mode_addfb(struct drm_device *dev,
void *data, struct drm_file *file_priv)
{
- struct drm_mode_fb_cmd *r = data;
+ struct drm_mode_fb_cmd *or = data;
+ struct drm_mode_fb_cmd2 r;
+ struct drm_mode_config *config = >mode_config;
+ struct drm_framebuffer *fb;
+ int ret = 0;
+
+ /* Use new struct with format internally */
+ r.fb_id = or->fb_id;
+ r.width = or->width;
+ r.height = or->height;
+ r.pitches[0] = or->pitch;
+ r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
+ r.handle = or->handle;
+
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EINVAL;
+
+ if ((config->min_width > r.width) || (r.width > config->max_width)) {
+ DRM_ERROR("mode new framebuffer width not within limits\n");
+ return -EINVAL;
+ }
+ if ((config->min_height > r.height) || (r.height > config->max_height))
{
+ DRM_ERROR("mode new framebuffer height not within limits\n");
+ return -EINVAL;
+ }
+
+ mutex_lock(>mode_config.mutex);
+
+ /* TODO check buffer is sufficiently large */
+ /* TODO setup destructor callback */
+
+ fb = dev->mode_config.funcs->fb_create(dev, file_priv, );
+ if (IS_ERR(fb)) {
+ DRM_ERROR("could not create framebuffer\n");
+ ret = PTR_ERR(fb);
+ goto out;
+ }
+
+ or->fb_id = fb->base.id;
+ list_add(>filp_head, _priv->fbs);
+ DRM_DEBUG_KMS("[FB:%d]\n", fb->base.id);
+
+out:
+ mutex_unlock(>mode_config.mutex);
+ return ret;
+}
+
+/**
+ * drm_mode_addfb2 - add an FB to the graphics configuration
+ * @inode: inode from the ioctl
+ * @filp: file * from the ioctl
+ * @cmd: cmd from ioctl
+ * @arg: arg from ioctl
+ *
+ * LOCKING:
+ * Takes mode config lock.
+ *
+ * Add a new FB to the specified CRTC, given a user request with format.
+ *
+ * Called by the user via ioctl.
+ *
+ * RETURNS:
+ * Zero on success, errno on failure.
+ */
+int drm_mode_addfb2(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+ struct drm_mode_fb_cmd2 *r = data;
struct drm_mode_config *config = >mode_config;
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #16 from Sven Arvidsson 2011-06-07 12:29:19 PDT --- I'm using a 5670 (Redwood) and the patch seems to solve the problems here. The test application works with the patch and asserts without it: query error : 2147483647 != 68698 query: query.cpp:104: int main(int, char**): Assertion `false' failed. I have only given Amnesia a quick try, but there are no longer any obvious rendering errors, and the piglit test general/occlusion_query now passes. Great job! ?(? ?)? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[RFC PATCH] KMS support for i.MX51/53
> Currently I don't use any sophisticated memory allocater like GEM > or similar. I helped myself with simple dma_alloc where needed. At GEM is actually pretty sane when you get your head around it a spot. The main thing it took me a bit of time to get my head around is that it allocates backing memory and handles but it doesn't allocate address space on the card side. For a minimal GEM take a look at drivers/staging/gma500/psb_gem.c. As I need to use a GTT and allocate address space I also use a standard Linux resource struct. If you just need to grab RAM and don't care about address spaces then you are well away except for getting console support I imagine. The GMS500 one has no magic interfaces for things like swapping objects, as the card is just using it for 2D frame buffer objects so hopefully is a bit easier to follow than the full works. Alan
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #15 from Maggioni Marcello 2011-06-07 11:46:29 PDT --- Yes, you are perfectly right, I looked better to the application and you are right, but considering that you don't set the "random seed" value with srand the random sequence is always the same, so the first execution of the of the "while" cycle should always have the same 68698 samples drawn. So at least in the first cycle my test app should report Correct: 50 Non correct: 0 right? This is an example of a sequence of values reported in the first cycle: Param is: 68698 Param is: 2147483647 Param is: 2147483647 Param is: 2147483647 Param is: 2147483647 Param is: 68698 Param is: 2147483647 Param is: 68698 Param is: 68698 Param is: 2147483647 Param is: 68698 Param is: 68698 Param is: 68698 Param is: 2147483647 Param is: 2147483647 Param is: 2147483647 Param is: 2147483647 Param is: 68698 Param is: 68698 Param is: 68698 Param is: 68698 The patch is applied, of this I'm sure. I tried reducing the value of the "size" variable (as you suggested) to 16 (instead of the value that usually is set by num_results that is 32), and the result is : Param is: 34594 Param is: 2147483647 Param is: 34594 Param is: 34594 Param is: 34594 Param is: 2147483647 Param is: 34594 Param is: 34594 Param is: 34594 Param is: 34594 Param is: 2147483647 Param is: 34594 Param is: 34594 Param is: 2147483647 Param is: 34594 The correct values are almost half of the ones with "size = query->num_results" and the non correct ones are the same ... It seems like the memory gets corrupted or not correctly initialized sometimes. Any idea? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #14 from Pierre-Eric Pelloux-Prayer
2011-06-07 10:19:00 PDT ---
Remote debugging is hard :-/
Anyway, your modified app is wrong I think (not only the != / == inversion) :
The app is supposed to :
- draw a cube to a random position
- use query to count how many pixels were drawn (so this number change every
time the cube position changes)
- then it compares the result of all queries : if not equal it fails
Now I have no idea why it crashes on your system, did you try to debug it ?
maybe there's an obvious mistake in it ? or maybe you could try to reduce the
num_queries param ?
The issue you've seen with values obviously wrong in 'r600_query_result' is the
problem the patch is supposed to address. Without the patch, the 'size'
variable is wrong (too big) and the 'results' buffer is read too far.
Last, if you have piglit installed, I found a test case in it probably more
robust than my simple app : occlusion_query.
This test sometimes fails when using non-patched git mesa like this :
$ ./bin/occlusion_query -auto
samples passed = 400, expected = 400
samples passed = 0, expected = 0
samples passed = 2600, expected = 2600
samples passed = 2147483647, expected = 0 [<- ERROR]
samples passed = 400, expected = 400
[...]
PIGLIT: {'result': 'fail' }
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
Flat address space with gGTT / ppGTT
On Mon, 6 Jun 2011 16:23:00 -0700, "Segovia, Benjamin" wrote: > Hello all, > > I saw at some point that per-process GTT (ppGTT) may be (or is > already) implemented to handle paging. Right now, I am investigating > some flat space addressing (ab)using surface states. The idea is to > create a surface state (raw buffer only, this is GPGPU stuff) as big > enough to cover the entire address space such that I will only > manipulate offsets as pointers in this surface instead of dealing with > both offsets and surface IDs (in other words, segmented address > space). > > My concern is relative to the way bo buffers are mapped. Basically, I > must be sure that _all_ of them are either mapped using ppGTT or > GTT. Otherwise, this will also bring another form of segmentation. If > ppGTT is implemented or will be implemented, will there be anyway to > know how a bo is mapped? If an exec would be done through PPGTT, it would be something you ask for as part of the execbuffers call. It won't change out from under you. However, we stopped looking into PPGTT because we've been told by hw people that it's hopelessly broken on all hardware in undocumented ways (and basically no other details than that). -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110607/53b7e199/attachment.pgp>
[Bug 37168] Regression: Kernel hard-lock when running Second Life
https://bugs.freedesktop.org/show_bug.cgi?id=37168 --- Comment #4 from Sean McNamara 2011-06-07 10:13:26 PDT --- (In reply to comment #3) > Followup: I also get the following messages spewed to dmesg every single > frame, > regardless if I'm using Mesa 7.10.2 or git master or anything in between. I'm > not sure if this is related to the problem or just noise. But I suspect that > it's unrelated, because I don't experience any symptoms of failure (crash, > OOM) > with 7.10.2, and the messages still get spewed. The frequency is about once > every frame, or a bit more often. Maybe as frequently as once per kernel tick > (~1000 Hz timer). > > [ 564.159042] DRHD: handling fault status reg 2 > [ 564.159248] DMAR:[DMA Write] Request device [04:00.0] fault addr 44bc > [ 564.159249] DMAR:[fault reason 05] PTE Write access is not set > > The DRHD line appears less frequently, but the DMAR lines are always grouped > together like that. I tried running other GL apps and it doesn't happen there. The DMAR and DRHD lines appear to be related to my ASUS P6T Deluxe's broken BIOS. Even the latest version of this BIOS is unable to handle the Core i7's VT-d feature correctly. On boot-up, the kernel complains very loudly about my broken BIOS and the incorrect functioning of the chipset IOMMU; when I disable VT-d, all of this complaining goes away, as do these DMAR / DRHD faults. Unfortunately, when disabling VT-d, I still have the memory leak. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 Maggioni Marcello changed: What|Removed |Added Attachment #47666|0 |1 is obsolete|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #13 from Maggioni Marcello 2011-06-07 10:12:20 PDT --- Created an attachment (id=47669) --> (https://bugs.freedesktop.org/attachment.cgi?id=47669) Correct test Ups sorry, I completely botched the test application :D I placed a "!=" instead of a "==" and so all the results in the previous post are inverted. The query are correct for a little in the beginning and then they get completely wrong afterwards : [hades at artemis ~]$ ./query Correct values: 25 Not correct values: 25 Correct values: 0 Not correct values: 50 Correct values: 0 Not correct values: 50 Correct values: 0 Not correct values: 50 Correct values: 0 Not correct values: 50 Correct values: 0 Not correct values: 50 Correct values: 0 Not correct values: 50 Correct values: 0 ... Sorry for the mess, I'm quite tired in this period :p -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #12 from Maggioni Marcello 2011-06-07
09:15:59 PDT ---
Created an attachment (id=47666)
--> (https://bugs.freedesktop.org/attachment.cgi?id=47666)
Further tests
Hi, your test application crashes on my system with and without the patch.
I determined that the result that the query should return is 68698 samples each
execution.
So I modified your test application to see how many times that value is
returned instead of some other random values (the modded app is attached) and
the output is this:
[hades at artemis ~]$ ./query
Correct values: 17
Not correct values: 33
Correct values: 50
Not correct values: 0
Correct values: 50
Not correct values: 0
Correct values: 50
Not correct values: 0
Correct values: 50
Not correct values: 0
Correct values: 50
.
As you can see at the beginning the probability of wrong queries is high and
then it corrects itself out. All the subsequent queries seem to be correct.
This happens both with your patch and without it.
I tried to step inside the gallium code (r600_query_result) to see what values
are returned.
When the value is correct I get values like:
(gdb) n
1641query->result += end - start;
2: /x end = 0x8001824291f0
1: /x start = 0x800182424e0c
...
when I get an error I get values for start and end like :
(gdb) n
1641query->result += end - start;
2: /x end = 0x
1: /x start = 0x
(gdb) n
1636for (i = 0; i < size; i += 4) {
2: /x end = 0x
1: /x start = 0x
(gdb)
That are obviously wrong.
The very first r600_query_result execution gives correct results, then from the
second r600_query_result execution on the results are incorrect and then ,
after some runs, the values become correct again.
I don't know how to interpret this. Maybe a drm bug? I use kernel 2.6.39
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[PATCH/RFC] m68k/bitops: Make bitmap data pointer of atomic ops volatile
On Mon, Jun 6, 2011 at 22:11, Arnd Bergmann wrote:
> On Monday 06 June 2011 22:07:53 Geert Uytterhoeven wrote:
>>
>> This fixes a.o.
>>
>> drivers/ide/ide-io.c: In function ?ide_lock_host?:
>> drivers/ide/ide-io.c:415: warning: passing argument 2 of
>> ?__constant_test_and_set_bit? discards qualifiers from pointer target type
>> drivers/ide/ide-io.c:415: warning: passing argument 2 of
>> ?__generic_test_and_set_bit? discards qualifiers from pointer target type
>>
>> Suggested-by: Ben Hutchings
>> Signed-off-by: Geert Uytterhoeven
>
> I think the correct fix would be to mark the variable not volatile, as it
> clearly has no business be marked as such. That doesn't mean your patch
You mean the host_busy variable in the IDE code?
That would also apply to context_flag in the DRM code:
drivers/gpu/drm/drm_context.c:233: warning: passing argument 2 of
?__constant_test_and_set_bit? discards qualifiers from pointer target
type
drivers/gpu/drm/drm_context.c:233: warning: passing argument 2 of
?__generic_test_and_set_bit? discards qualifiers from pointer target
type
> is wrong, though. It probably doesn't hurt to do both.
asm-generic/bitops/atomic.h has the volatiles everywhere. That's why
I'm wondering.
Gr{oetje,eeting}s,
? ? ? ? ? ? ? ? ? ? ? ? Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?? -- Linus Torvalds
[PATCH] drm: fix fbs in DRM_IOCTL_MODE_GETRESOURCES ioctl
Hi David,
Somehow my Cc got lost. Maybe you missed this. Any comments?
Thanks
Sascha
On Fri, Jun 03, 2011 at 12:54:14PM +0200, Sascha Hauer wrote:
>
> The DRM_IOCTL_MODE_GETRESOURCES ioctl just returns bogus framebuffers.
> That is because the framebuffers for each file are in the filp_head
> member of struct drm_framebuffer, not in the head member.
>
> Signed-off-by: Sascha Hauer
> ---
> drivers/gpu/drm/drm_crtc.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 872747c..21058e6 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1113,7 +1113,7 @@ int drm_mode_getresources(struct drm_device *dev, void
> *data,
> if (card_res->count_fbs >= fb_count) {
> copied = 0;
> fb_id = (uint32_t __user *)(unsigned long)card_res->fb_id_ptr;
> - list_for_each_entry(fb, _priv->fbs, head) {
> + list_for_each_entry(fb, _priv->fbs, filp_head) {
> if (put_user(fb->base.id, fb_id + copied)) {
> ret = -EFAULT;
> goto out;
> --
> 1.7.5.3
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
[git pull] drm fixes
Hi Linus, this is just the Intel and nouveau fixes, this alongside the radeon fixes pull that is outstanding, it has one serious intel regression fix for 945 machines that got broken in the ivybridge support, along with a few fixes from nouveau. Dave. The following changes since commit 59c5f46fbe01a00eedf54a23789634438bb80603: Linux 3.0-rc2 (2011-06-06 18:06:33 +0900) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-fixes Ben Skeggs (5): drm/nvc0: recognise 0xdX chipsets as NV_C0 drm/nouveau: don't create accel engine objects when noaccel=1 drm/nouveau: fix vram page mapping when crossing page table boundaries drm/nouveau: fix leak of gart mm node drm/nv40: fall back to paged dma object for the moment Chris Wilson (5): drm/i915: s/addr & ~PAGE_MASK/offset_in_page(addr)/ drm/i915: Replace ironlake_compute_wm0 with g4x_compute_wm0 drm/i915/crt: Explicitly return false if connected to a digital monitor drm/i915: Remove unused enum "chip_family" drm/i915: Share the common force-audio property between connectors Dan Carpenter (1): drm/i915: fix if statement in ivybridge irq handler Daniel Vetter (2): drm/i915: Only print out the actual number of fences for i915_error_state drm/915: fix relaxed tiling on gen2: tile height Dave Airlie (2): Merge remote branch 'keithp/drm-intel-fixes' of /ssd/git/drm-next into drm-fixes Merge remote branch 'nouveau/drm-nouveau-fixes' of /ssd/git/drm-nouveau-next into drm-fixes Francisco Jerez (1): drm/nv17-nv40: Fix modesetting failure when pitch == 4096px (fdo bug 35901). Hans de Goede (1): drm/i915: Add a no lvds quirk for the Asus EeeBox PC EB1007 Jason Stubbs (1): drm/i915: fix regression after clock gating init split Nicolas Kaiser (1): drm: i915: correct return status in intel_hdmi_mode_valid() drivers/gpu/drm/i915/i915_debugfs.c |2 +- drivers/gpu/drm/i915/i915_drv.h |8 +-- drivers/gpu/drm/i915/i915_gem.c | 26 drivers/gpu/drm/i915/i915_irq.c |2 +- drivers/gpu/drm/i915/intel_crt.c|4 + drivers/gpu/drm/i915/intel_display.c| 89 ++-- drivers/gpu/drm/i915/intel_dp.c | 15 + drivers/gpu/drm/i915/intel_drv.h|1 + drivers/gpu/drm/i915/intel_hdmi.c | 16 + drivers/gpu/drm/i915/intel_lvds.c |8 ++ drivers/gpu/drm/i915/intel_modes.c | 30 drivers/gpu/drm/i915/intel_sdvo.c | 14 +--- drivers/gpu/drm/nouveau/nouveau_hw.c|2 + drivers/gpu/drm/nouveau/nouveau_mem.c |4 +- drivers/gpu/drm/nouveau/nouveau_sgdma.c |2 +- drivers/gpu/drm/nouveau/nouveau_state.c | 114 --- drivers/gpu/drm/nouveau/nouveau_vm.c|1 + drivers/gpu/drm/nouveau/nv04_crtc.c |8 ++- drivers/gpu/drm/nouveau/nvreg.h |2 + 19 files changed, 161 insertions(+), 187 deletions(-)
[Bug 25248] Machinarium crashes with current git radeon driver
https://bugs.freedesktop.org/show_bug.cgi?id=25248 Phil Armstrong changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Phil Armstrong 2011-06-07 05:30:44 PDT --- Seems to work fine with current Debian xorg/radeon driver. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #11 from Pierre-Eric Pelloux-Prayer 2011-06-07 05:18:56 PDT --- Created an attachment (id=47657) --> (https://bugs.freedesktop.org/attachment.cgi?id=47657) simple test app Weird, here the patch solves the white-dot-around-lights issue. I'm using a HD4850, maybe that's why... I've attached a small test app, which exhibits the problem fixed by this patch. Without the patch applied it fails almost every time (the failure is immediate). Could you please compile it and launch it a few times and tell me : 1) if it fails without the patch 2) if so, does the patch brings some improvement ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36812] Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 James Cloos changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #5 from James Cloos 2011-06-07 04:01:31 --- Ah. OK. The driver tries to load the firmware before / is mounted, then? As I do not use initrd there the answer seems to be: -CONFIG_EXTRA_FIRMWARE="" +CONFIG_EXTRA_FIRMWARE="radeon/R600_rlc.bin" +CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" to the .config. Closing as invalid. Will reopen if the above .config change doesn?t fix it. (Last time I must have manually done what EXTRA_FIRMWARE does. I lost that clone in the meantime, though, so that is only a guess. (It was a clone of my local, pristine clone. And the .configs were backed up in their own git repo. So that loss didn?t seem like much of a nuisance. But I obviously forgot about this issue in the meantime. ?) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 36812] Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #4 from Alex Deucher 2011-06-07 02:17:36 --- Most likely you did not include the firmware in your initrd. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #6 from Dave Airlie 2011-06-07 01:43:33 PDT --- can you disable page flipping and try again? /me hasn't run compiz on cayman yet too much. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #5 from Harald Judt 2011-06-07 01:16:07 PDT --- > - linux-3.0.0-rc1 with latest fixes from drm-2.6 git applied, up to 2a9e5862a38f7195931bd51788dc9ce68b28120c. Small inexactness on my part. I pulled from drm-radeon-testing branch, not master, which should already have the blitting support. I do not have all commits from the last 5 days though, the last one was "fix oops in ttm reserve when pageflipping (v2)". I might give 3.0.0-rc2 a try together with drm-radeon-fixes, but after glancing over the changelog I wonder if this is really going to help... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #4 from Dave Airlie 2011-06-07 00:55:02 PDT --- can you try with drm-radeon-fixes branch of my git trre? http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-radeon-fixes t enables cayman blitting support. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36812] Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 --- Comment #3 from James Cloos 2011-06-07 00:53:41 --- I forgot to add: I don?t see from git-grep(1)ing the tree where or how the kernel knows to find firmware in /lib/firmware. All I can see is /lib/firmware as the target to make firmware_install and several comments specifying /lib/firmware as the typical location. What am I missing? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 36812] Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 --- Comment #2 from James Cloos 2011-06-07 00:47:29 --- Longer than that. The box is usually headless; when I first got it the missing firmware prevented booting, so I added radeon.modeset=0 to the grub config and manually changed that for those occasions when I moved the box to the TV. Today I changed the grub config in honour of the upcoming 3.0. ? (That it boots now even though it fails to load that firmware is a nice progression.) My best guess, based on the timestamps of my .config archive, is that I last connected it to the TV during the 38-rc1 timeframe. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 36812] Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 Andrew Morton changed: What|Removed |Added CC||akpm at linux-foundation.org --- Comment #1 from Andrew Morton 2011-06-06 23:59:54 --- If it was Ok a couple of weeks ago then I assume that this is a psot-2.6.39 regression? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 36812] New: Radeon fails to load firmware
https://bugzilla.kernel.org/show_bug.cgi?id=36812 Summary: Radeon fails to load firmware Product: Drivers Version: 2.5 Kernel Version: 3.0-rc2 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: cloos at jhcloos.com Regression: Yes This used to work, but I had been booting with radeon.modset=0 for a few weeks, so I do not know when it broke. With 3.0-rc2 (compiled from git master) I get (note this first two lines): [ 61.920296] r600_cp: Failed to load firmware "radeon/R600_rlc.bin" [ 61.920370] [drm:r600_startup] *ERROR* Failed to load firmware! [ 61.920442] radeon :01:05.0: disabling GPU acceleration [ 61.921543] radeon :01:05.0: 8802fc74c400 unpin not necessary [ 61.921615] radeon :01:05.0: 8802fc74c400 unpin not necessary [ 61.921697] [drm] Enabling audio support [ 61.921949] [drm] Radeon Display Connectors [ 61.922030] [drm] Connector 0: [ 61.922100] [drm] VGA [ 61.922170] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [ 61.922287] [drm] Encoders: [ 61.922357] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 61.922427] [drm] Connector 1: [ 61.922496] [drm] HDMI-A [ 61.922565] [drm] HPD1 [ 61.922634] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [ 61.922751] [drm] Encoders: [ 61.922820] [drm] DFP1: INTERNAL_KLDSCP_LVTMA [ 61.942202] [drm] radeon: power management initialized [ 61.958278] No connectors reported connected with modes [ 61.958351] [drm] Cannot find any crtc or sizes - going 1024x768 [ 61.965068] [drm] fb mappable at 0xD004 [ 61.965137] [drm] vram apper at 0xD000 [ 61.965206] [drm] size 3145728 [ 61.965274] [drm] fb depth is 24 [ 61.965342] [drm]pitch is 4096 [ 61.965460] fbcon: radeondrmfb (fb0) is primary device [ 61.979478] Console: switching to colour frame buffer device 128x48 [ 61.985634] fb0: radeondrmfb frame buffer device [ 61.985696] drm: registered panic notifier [ 61.985755] [drm] Initialized radeon 2.10.0 20080528 for :01:05.0 on minor 0 and yet: :; ls -sl /lib/firmware/radeon/R600_rlc.bin 4 -rw-r--r-- 1 root root 3072 Jun 6 12:15 /lib/firmware/radeon/R600_rlc.bin (from a fresh update from http://people.freedesktop.org/~agd5f/radeon_ucode/ .) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #3 from Harald Judt 2011-06-06 23:36:06 PDT --- Created an attachment (id=47645) --> (https://bugs.freedesktop.org/attachment.cgi?id=47645) Screenshot of corrupted firefox toolbar Corruption can get quite nasty after a while. The ugly pink background once was a somewhat nicer image from some firefox persona theme. There are more of those corrupted icons too for those who got a taste of them ;-) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #2 from Harald Judt 2011-06-06 23:26:48 PDT --- Created an attachment (id=47644) --> (https://bugs.freedesktop.org/attachment.cgi?id=47644) Screenshot of corrupted xfce panel plugins. Here, parts of a previous screen (gdm login screen) shine through the lower half of the plugin widgets (gtk progress bar). I guess the gdm login screen was not active on any console at this time, so these are just remnants. Reloading the panel fixes it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #1 from Harald Judt 2011-06-06 23:21:19 PDT --- Created an attachment (id=47643) --> (https://bugs.freedesktop.org/attachment.cgi?id=47643) Screenshot of a corrupted icon. As you can see, only the lower half of the icon is corrupted. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38022] New: ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 Summary: ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: h.judt at gmx.at Created an attachment (id=47642) --> (https://bugs.freedesktop.org/attachment.cgi?id=47642) Xorg.0.log I don't know where this should go (drm, mesa?), but after a while, I notice corruption of textures / pixmaps. It can be reproduced quite easily by opening a few applications, or starting another X session. In particular, I could determine the following: - Corrupted areas resemble parts of the previous visible login screen - Icons, fonts and widgets like vertical gtk progressbars get corrupted, but only their lower half - Window (emerald) decoration seem to get corrupted completely. - It's not related to color tiling. - Pageflipping is enabled. - Restarting a corrupted application fixes it temporarily, while minimizing etc. doesn't. Restarting compiz doesn't fix it either. I believe this is specific to cayman, as the issue does not occur on a thinkpad t400 with ATI Mobility Radeon HD 3400 and similar configuration. Software configuration: - linux-3.0.0-rc1 with latest fixes from drm-2.6 git applied, up to 2a9e5862a38f7195931bd51788dc9ce68b28120c. - r600g from git mesa compiled on 12:44:56 03.06.2011 - xorg-server 1.10.2 - libdrm git 21:06:43 02.06.2011 - xf86-video-ati git 21:56:58 02.06.2011 lspci: 01:00.0 VGA compatible controller: ATI Technologies Inc Device 6719 (prog-if 00 [VGA controller]) Subsystem: ATI Technologies Inc Device 0b00 Flags: bus master, fast devsel, latency 0, IRQ 54 Memory at c000 (64-bit, prefetchable) [size=256M] Memory at fe62 (64-bit, non-prefetchable) [size=128K] I/O ports at e000 [size=256] Expansion ROM at fe60 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 Capabilities: [150] Advanced Error Reporting Kernel driver in use: radeon -- Apart from this, it works great, no crashes so far! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 38022] New: ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 Summary: ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: h.j...@gmx.at Created an attachment (id=47642) -- (https://bugs.freedesktop.org/attachment.cgi?id=47642) Xorg.0.log I don't know where this should go (drm, mesa?), but after a while, I notice corruption of textures / pixmaps. It can be reproduced quite easily by opening a few applications, or starting another X session. In particular, I could determine the following: - Corrupted areas resemble parts of the previous visible login screen - Icons, fonts and widgets like vertical gtk progressbars get corrupted, but only their lower half - Window (emerald) decoration seem to get corrupted completely. - It's not related to color tiling. - Pageflipping is enabled. - Restarting a corrupted application fixes it temporarily, while minimizing etc. doesn't. Restarting compiz doesn't fix it either. I believe this is specific to cayman, as the issue does not occur on a thinkpad t400 with ATI Mobility Radeon HD 3400 and similar configuration. Software configuration: - linux-3.0.0-rc1 with latest fixes from drm-2.6 git applied, up to 2a9e5862a38f7195931bd51788dc9ce68b28120c. - r600g from git mesa compiled on 12:44:56 03.06.2011 - xorg-server 1.10.2 - libdrm git 21:06:43 02.06.2011 - xf86-video-ati git 21:56:58 02.06.2011 lspci: 01:00.0 VGA compatible controller: ATI Technologies Inc Device 6719 (prog-if 00 [VGA controller]) Subsystem: ATI Technologies Inc Device 0b00 Flags: bus master, fast devsel, latency 0, IRQ 54 Memory at c000 (64-bit, prefetchable) [size=256M] Memory at fe62 (64-bit, non-prefetchable) [size=128K] I/O ports at e000 [size=256] Expansion ROM at fe60 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 ? Capabilities: [150] Advanced Error Reporting Kernel driver in use: radeon -- Apart from this, it works great, no crashes so far! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #1 from Harald Judt h.j...@gmx.at 2011-06-06 23:21:19 PDT --- Created an attachment (id=47643) -- (https://bugs.freedesktop.org/attachment.cgi?id=47643) Screenshot of a corrupted icon. As you can see, only the lower half of the icon is corrupted. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #2 from Harald Judt h.j...@gmx.at 2011-06-06 23:26:48 PDT --- Created an attachment (id=47644) -- (https://bugs.freedesktop.org/attachment.cgi?id=47644) Screenshot of corrupted xfce panel plugins. Here, parts of a previous screen (gdm login screen) shine through the lower half of the plugin widgets (gtk progress bar). I guess the gdm login screen was not active on any console at this time, so these are just remnants. Reloading the panel fixes it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #3 from Harald Judt h.j...@gmx.at 2011-06-06 23:36:06 PDT --- Created an attachment (id=47645) -- (https://bugs.freedesktop.org/attachment.cgi?id=47645) Screenshot of corrupted firefox toolbar Corruption can get quite nasty after a while. The ugly pink background once was a somewhat nicer image from some firefox persona theme. There are more of those corrupted icons too for those who got a taste of them ;-) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fix fbs in DRM_IOCTL_MODE_GETRESOURCES ioctl
Hi David,
Somehow my Cc got lost. Maybe you missed this. Any comments?
Thanks
Sascha
On Fri, Jun 03, 2011 at 12:54:14PM +0200, Sascha Hauer wrote:
The DRM_IOCTL_MODE_GETRESOURCES ioctl just returns bogus framebuffers.
That is because the framebuffers for each file are in the filp_head
member of struct drm_framebuffer, not in the head member.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/gpu/drm/drm_crtc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 872747c..21058e6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1113,7 +1113,7 @@ int drm_mode_getresources(struct drm_device *dev, void
*data,
if (card_res-count_fbs = fb_count) {
copied = 0;
fb_id = (uint32_t __user *)(unsigned long)card_res-fb_id_ptr;
- list_for_each_entry(fb, file_priv-fbs, head) {
+ list_for_each_entry(fb, file_priv-fbs, filp_head) {
if (put_user(fb-base.id, fb_id + copied)) {
ret = -EFAULT;
goto out;
--
1.7.5.3
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC] m68k/bitops: Make bitmap data pointer of atomic ops volatile
On Mon, Jun 6, 2011 at 22:11, Arnd Bergmann a...@arndb.de wrote:
On Monday 06 June 2011 22:07:53 Geert Uytterhoeven wrote:
This fixes a.o.
drivers/ide/ide-io.c: In function ‘ide_lock_host’:
drivers/ide/ide-io.c:415: warning: passing argument 2 of
‘__constant_test_and_set_bit’ discards qualifiers from pointer target type
drivers/ide/ide-io.c:415: warning: passing argument 2 of
‘__generic_test_and_set_bit’ discards qualifiers from pointer target type
Suggested-by: Ben Hutchings b...@decadent.org.uk
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
I think the correct fix would be to mark the variable not volatile, as it
clearly has no business be marked as such. That doesn't mean your patch
You mean the host_busy variable in the IDE code?
That would also apply to context_flag in the DRM code:
drivers/gpu/drm/drm_context.c:233: warning: passing argument 2 of
‘__constant_test_and_set_bit’ discards qualifiers from pointer target
type
drivers/gpu/drm/drm_context.c:233: warning: passing argument 2 of
‘__generic_test_and_set_bit’ discards qualifiers from pointer target
type
is wrong, though. It probably doesn't hurt to do both.
asm-generic/bitops/atomic.h has the volatiles everywhere. That's why
I'm wondering.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #4 from Dave Airlie airl...@freedesktop.org 2011-06-07 00:55:02 PDT --- can you try with drm-radeon-fixes branch of my git trre? http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=refs/heads/drm-radeon-fixes t enables cayman blitting support. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 38022] ATI Radeon 6950 (Cayman): r600g texture / pixmap corruption
https://bugs.freedesktop.org/show_bug.cgi?id=38022 --- Comment #5 from Harald Judt h.j...@gmx.at 2011-06-07 01:16:07 PDT --- - linux-3.0.0-rc1 with latest fixes from drm-2.6 git applied, up to 2a9e5862a38f7195931bd51788dc9ce68b28120c. Small inexactness on my part. I pulled from drm-radeon-testing branch, not master, which should already have the blitting support. I do not have all commits from the last 5 days though, the last one was fix oops in ttm reserve when pageflipping (v2). I might give 3.0.0-rc2 a try together with drm-radeon-fixes, but after glancing over the changelog I wonder if this is really going to help... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] DRM: Add i.MX IPUv3 support
This adds a i.MX51/53 IPU (Image Processing Unit) KMS driver. The
driver has been tested on the i.MX51 babbage board and the i.MX53
LOCO board in different clone mode and dual head setups.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/gpu/drm/Kconfig|9 +
drivers/gpu/drm/imx/Makefile |2 +
drivers/gpu/drm/imx/imx-drm.c | 936
drivers/gpu/drm/imx/imx-priv.h |9 +
4 files changed, 956 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/imx/imx-drm.c
create mode 100644 drivers/gpu/drm/imx/imx-priv.h
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 01d5444..93a2c5a 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -177,3 +177,12 @@ config DRM_IMX_IPUV3
depends on DRM ARCH_MXC
help
Choose this if you have a i.MX51/53 processor.
+
+config DRM_IMX
+ tristate i.MX IPUv3 drm support
+ depends on DRM_IMX_IPUV3
+ select DRM_KMS_ENCON
+ select DRM_KMS_HELPER
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
diff --git a/drivers/gpu/drm/imx/Makefile b/drivers/gpu/drm/imx/Makefile
index 776e6b4..0a53cf4 100644
--- a/drivers/gpu/drm/imx/Makefile
+++ b/drivers/gpu/drm/imx/Makefile
@@ -1 +1,3 @@
obj-$(CONFIG_DRM_IMX_IPUV3) += ipu-v3/
+
+obj-$(CONFIG_DRM_IMX) += imx-drm.o
diff --git a/drivers/gpu/drm/imx/imx-drm.c b/drivers/gpu/drm/imx/imx-drm.c
new file mode 100644
index 000..e9857c9
--- /dev/null
+++ b/drivers/gpu/drm/imx/imx-drm.c
@@ -0,0 +1,936 @@
+/*
+ * i.MX IPUv3 Graphics driver
+ *
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+#include linux/device.h
+#include linux/platform_device.h
+#include drm/drmP.h
+#include drm/drm_fb_helper.h
+#include drm/drm_crtc_helper.h
+#include linux/fb.h
+#include linux/clk.h
+#include drm/imx-ipu-v3.h
+#include asm/fb.h
+#include drm/drm_encon.h
+
+#define DRIVER_NAMEi.MX
+#define DRIVER_DESCi.MX IPUv3 Graphics
+#define DRIVER_DATE20110604
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+#define DRIVER_PATCHLEVEL 0
+
+struct ipu_resource {
+ int ipu_channel_bg;
+ int dc_channel;
+ int dp_channel;
+ int display;
+ u32 interface_pix_fmt; /* FIXME: move to platform data */
+};
+
+static struct ipu_resource ipu_resources[] = {
+ {
+ .ipu_channel_bg = 23, /* IPUV3_CHANNEL_MEM_BG_SYNC */
+ .dc_channel = 5,
+ .dp_channel = IPU_DP_FLOW_SYNC_BG,
+ .display = 0,
+ .interface_pix_fmt = IPU_PIX_FMT_RGB24,
+ } , {
+ .ipu_channel_bg = 28, /* IPUV3_CHANNEL_MEM_DC_SYNC */
+ .dc_channel = 1,
+ .dp_channel = -1,
+ .display = 1,
+ .interface_pix_fmt = IPU_PIX_FMT_RGB565,
+ },
+};
+
+struct ipu_crtc {
+ struct drm_crtc base;
+ int pipe;
+ struct ipu_resource *ipu_res;
+ struct ipu_channel *ipu_ch;
+ struct ipu_dc *dc;
+ struct ipu_dp *dp;
+ struct dmfc_channel *dmfc;
+ struct ipu_di *di;
+ int di_no;
+ struct clk *pixclk;
+ int enabled;
+};
+
+struct ipu_framebuffer {
+ struct drm_framebuffer base;
+ void*virt;
+ dma_addr_t phys;
+ size_t len;
+};
+
+struct ipu_drm_private {
+ struct ipu_crtc crtc[2];
+ struct drm_encoder_connector *encon[2];
+ struct drm_fb_helperfb_helper;
+ struct ipu_framebuffer ifb;
+ int num_crtcs;
+};
+
+static struct fb_ops ipu_ipufb_ops = {
+ .owner = THIS_MODULE,
+ .fb_check_var = drm_fb_helper_check_var,
+ .fb_set_par = drm_fb_helper_set_par,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+ .fb_pan_display = drm_fb_helper_pan_display,
+ .fb_blank = drm_fb_helper_blank,
+ .fb_setcmap = drm_fb_helper_setcmap,
+ .fb_debug_enter =
[PATCH 4/5] DRM: Add support for the sii902x HDMI/DVI encoder
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/gpu/drm/Kconfig |6 +
drivers/gpu/drm/i2c/Makefile |3 +
drivers/gpu/drm/i2c/sii902x.c | 334 +
3 files changed, 343 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpu/drm/i2c/sii902x.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index bcd9a27..01d5444 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -166,6 +166,12 @@ config DRM_SAVAGE
Choose this option if you have a Savage3D/4/SuperSavage/Pro/Twister
chipset. If M is selected the module will be called savage.
+config DRM_I2C_SII902X
+ tristate sii902x
+ depends on DRM I2C
+ help
+ Support for sii902x DVI/HDMI encoder chips
+
config DRM_IMX_IPUV3
tristate i.MX IPUv3
depends on DRM ARCH_MXC
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 9286256..a7a8d40 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -5,3 +5,6 @@ obj-$(CONFIG_DRM_I2C_CH7006) += ch7006.o
sil164-y := sil164_drv.o
obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
+
+sii902x := sii902x_drv.o
+obj-$(CONFIG_DRM_I2C_SII902X) += sii902x.o
diff --git a/drivers/gpu/drm/i2c/sii902x.c b/drivers/gpu/drm/i2c/sii902x.c
new file mode 100644
index 000..7928533
--- /dev/null
+++ b/drivers/gpu/drm/i2c/sii902x.c
@@ -0,0 +1,334 @@
+/*
+ * Copyright (C) 2010 Francisco Jerez.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining
+ * a copy of this software and associated documentation files (the
+ * Software), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sublicense, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial
+ * portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+ * IN NO EVENT SHALL THE COPYRIGHT OWNER(S) AND/OR ITS SUPPLIERS BE
+ * LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+ * OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+ * WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ */
+
+#include drm/drmP.h
+#include drm/drm_crtc_helper.h
+#include drm/drm_encoder_slave.h
+#include drm/drm_encon.h
+
+struct sii902x_encoder_params {
+};
+
+struct sii902x_priv {
+ struct sii902x_encoder_params config;
+ struct i2c_client *client;
+ struct drm_encoder_connector encon;
+};
+
+#define to_sii902x(x) container_of(x, struct sii902x_priv, encon)
+
+static int sii902x_write(struct i2c_client *client, uint8_t addr, uint8_t val)
+{
+ int ret;
+
+ ret = i2c_smbus_write_byte_data(client, addr, val);
+ if (ret) {
+ dev_dbg(client-dev, %s failed with %d\n, __func__, ret);
+ }
+ return ret;
+}
+
+static uint8_t sii902x_read(struct i2c_client *client, uint8_t addr)
+{
+ int dat;
+
+ dat = i2c_smbus_read_byte_data(client, addr);
+
+ return dat;
+}
+
+static int hdmi_cap = 0; /* FIXME */
+
+static void sii902x_poweron(struct sii902x_priv *priv)
+{
+ struct i2c_client *client = priv-client;
+
+ /* Turn on DVI or HDMI */
+ if (hdmi_cap)
+ sii902x_write(client, 0x1A, 0x01 | 4);
+ else
+ sii902x_write(client, 0x1A, 0x00);
+
+ return;
+}
+
+static void sii902x_poweroff(struct sii902x_priv *priv)
+{
+ struct i2c_client *client = priv-client;
+
+ /* disable tmds before changing resolution */
+ if (hdmi_cap)
+ sii902x_write(client, 0x1A, 0x11);
+ else
+ sii902x_write(client, 0x1A, 0x10);
+
+ return;
+}
+
+static int sii902x_get_modes(struct drm_encoder_connector *encon)
+{
+ struct sii902x_priv *priv = to_sii902x(encon);
+ struct i2c_client *client = priv-client;
+ struct i2c_adapter *adap = client-adapter;
+ struct drm_connector *connector = encon-connector;
+ struct edid *edid;
+ int ret;
+ int old, dat, cnt = 100;
+
+ old = sii902x_read(client, 0x1A);
+
+ sii902x_write(client, 0x1A, old | 0x4);
+ do {
+ cnt--;
+ msleep(10);
+ dat = sii902x_read(client, 0x1A);
+ } while ((!(dat 0x2)) cnt);
+
+ if (!cnt)
+ return -ETIMEDOUT;
+
+ sii902x_write(client, 0x1A, old | 0x06);
+
+ edid = drm_get_edid(connector, adap);
+ if (edid) {
+
[PATCH 2/5] DRM i.MX IPU: Add support for IPU submodules
Can be squashed into the last patch, just split up to avoid hitting
list limits.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/gpu/drm/imx/ipu-v3/Makefile |2 +-
drivers/gpu/drm/imx/ipu-v3/ipu-dc.c | 440 ++
drivers/gpu/drm/imx/ipu-v3/ipu-di.c | 665 +
drivers/gpu/drm/imx/ipu-v3/ipu-dmfc.c | 393 +++
drivers/gpu/drm/imx/ipu-v3/ipu-dp.c | 342 +
5 files changed, 1841 insertions(+), 1 deletions(-)
create mode 100644 drivers/gpu/drm/imx/ipu-v3/ipu-dc.c
create mode 100644 drivers/gpu/drm/imx/ipu-v3/ipu-di.c
create mode 100644 drivers/gpu/drm/imx/ipu-v3/ipu-dmfc.c
create mode 100644 drivers/gpu/drm/imx/ipu-v3/ipu-dp.c
diff --git a/drivers/gpu/drm/imx/ipu-v3/Makefile
b/drivers/gpu/drm/imx/ipu-v3/Makefile
index b073fd3..877433c 100644
--- a/drivers/gpu/drm/imx/ipu-v3/Makefile
+++ b/drivers/gpu/drm/imx/ipu-v3/Makefile
@@ -1,3 +1,3 @@
obj-$(CONFIG_DRM_IMX_IPUV3) += imx-ipu-v3.o
-imx-ipu-v3-objs := ipu-common.o
+imx-ipu-v3-objs := ipu-common.o ipu-dc.o ipu-di.o ipu-dp.o ipu-dmfc.o
diff --git a/drivers/gpu/drm/imx/ipu-v3/ipu-dc.c
b/drivers/gpu/drm/imx/ipu-v3/ipu-dc.c
new file mode 100644
index 000..7841a35
--- /dev/null
+++ b/drivers/gpu/drm/imx/ipu-v3/ipu-dc.c
@@ -0,0 +1,440 @@
+/*
+ * Copyright (c) 2010 Sascha Hauer s.ha...@pengutronix.de
+ * Copyright (C) 2005-2009 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+ * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+ * for more details.
+ */
+
+#include linux/types.h
+#include linux/errno.h
+#include linux/delay.h
+#include linux/io.h
+#include drm/imx-ipu-v3.h
+
+#include ipu-prv.h
+
+#define ASYNC_SER_WAVE 6
+
+#define DC_DISP_ID_SERIAL 2
+#define DC_DISP_ID_ASYNC 3
+
+#define DC_MAP_CONF_PTR(n) (0x0108 + ((n) ~0x1) * 2)
+#define DC_MAP_CONF_VAL(n) (0x0144 + ((n) ~0x1) * 2)
+
+#define DC_EVT_NF 0
+#define DC_EVT_NL 1
+#define DC_EVT_EOF 2
+#define DC_EVT_NFIELD 3
+#define DC_EVT_EOL 4
+#define DC_EVT_EOFIELD 5
+#define DC_EVT_NEW_ADDR6
+#define DC_EVT_NEW_CHAN7
+#define DC_EVT_NEW_DATA8
+
+#define DC_EVT_NEW_ADDR_W_00
+#define DC_EVT_NEW_ADDR_W_11
+#define DC_EVT_NEW_CHAN_W_02
+#define DC_EVT_NEW_CHAN_W_13
+#define DC_EVT_NEW_DATA_W_04
+#define DC_EVT_NEW_DATA_W_15
+#define DC_EVT_NEW_ADDR_R_06
+#define DC_EVT_NEW_ADDR_R_17
+#define DC_EVT_NEW_CHAN_R_08
+#define DC_EVT_NEW_CHAN_R_19
+#define DC_EVT_NEW_DATA_R_010
+#define DC_EVT_NEW_DATA_R_111
+
+#define DC_WR_CH_CONF 0x0
+#define DC_WR_CH_ADDR 0x4
+#define DC_RL_CH(evt) (8 + ((evt) ~0x1) * 2)
+
+#define DC_GEN 0x00d4
+#define DC_DISP_CONF1(disp)(0x00d8 + (disp) * 4)
+#define DC_DISP_CONF2(disp)(0x00e8 + (disp) * 4)
+#define DC_STAT0x01c8
+
+#define WROD(lf) (0x18 | (lf 1))
+
+#define DC_WR_CH_CONF_FIELD_MODE (1 9)
+#define DC_WR_CH_CONF_PROG_TYPE_OFFSET 5
+#define DC_WR_CH_CONF_PROG_TYPE_MASK (7 5)
+#define DC_WR_CH_CONF_PROG_DI_ID (1 2)
+#define DC_WR_CH_CONF_PROG_DISP_ID_OFFSET 3
+#define DC_WR_CH_CONF_PROG_DISP_ID_MASK(3 3)
+
+struct ipu_dc_priv;
+
+struct ipu_dc {
+ unsigned intdi; /* The display interface number assigned to
this dc channel */
+ void __iomem*base;
+ struct ipu_dc_priv *priv;
+ int chno;
+ boolin_use;
+};
+
+struct ipu_dc_priv {
+ void __iomem*dc_reg;
+ void __iomem*dc_tmpl_reg;
+ struct ipu_soc *ipu;
+ struct device *dev;
+ struct ipu_dc channels[10];
+ struct mutexmutex;
+};
+
+static void ipu_dc_link_event(struct ipu_dc *dc, int event, int addr, int
priority)
+{
+ u32 reg;
+
+ reg = readl(dc-base + DC_RL_CH(event));
+ reg = ~(0x (16 * (event 0x1)));
+ reg |= ((addr 8) | priority) (16 * (event 0x1));
+ writel(reg, dc-base + DC_RL_CH(event));
+}
+
+static void ipu_dc_write_tmpl(struct ipu_dc *dc, int word, u32 opcode, u32
operand,
+ int map, int wave, int glue, int sync)
+{
+ struct ipu_dc_priv *priv = dc-priv;
+ u32 reg;
+ int stop = 1;
+
+ reg = sync;
+ reg |= glue 4;
+ reg |= ++wave 11;
+ reg |= ++map 15;
+
Re: [RFC PATCH] KMS support for i.MX51/53
Currently I don't use any sophisticated memory allocater like GEM or similar. I helped myself with simple dma_alloc where needed. At GEM is actually pretty sane when you get your head around it a spot. The main thing it took me a bit of time to get my head around is that it allocates backing memory and handles but it doesn't allocate address space on the card side. For a minimal GEM take a look at drivers/staging/gma500/psb_gem.c. As I need to use a GTT and allocate address space I also use a standard Linux resource struct. If you just need to grab RAM and don't care about address spaces then you are well away except for getting console support I imagine. The GMS500 one has no magic interfaces for things like swapping objects, as the card is just using it for 2D frame buffer objects so hopefully is a bit easier to follow than the full works. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC] m68k/bitops: Make bitmap data pointer of atomic ops volatile
On Tuesday 07 June 2011, Geert Uytterhoeven wrote: You mean the host_busy variable in the IDE code? That would also apply to context_flag in the DRM code: drivers/gpu/drm/drm_context.c:233: warning: passing argument 2 of ‘__constant_test_and_set_bit’ discards qualifiers from pointer target type drivers/gpu/drm/drm_context.c:233: warning: passing argument 2 of ‘__generic_test_and_set_bit’ discards qualifiers from pointer target type Yes, that fits the same category. is wrong, though. It probably doesn't hurt to do both. asm-generic/bitops/atomic.h has the volatiles everywhere. That's why I'm wondering. I guess what happened is that some variables are traditionally marked as volatile although they shouldn't be, and most architectures have adapted their bitops to make the warnings go away. If you see more warnings of that kind, it's probably fine to just do the same on m68k. The volatile modifier doesn't really hurt in this case. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028 --- Comment #11 from Pierre-Eric Pelloux-Prayer pell...@gmail.com 2011-06-07 05:18:56 PDT --- Created an attachment (id=47657) -- (https://bugs.freedesktop.org/attachment.cgi?id=47657) simple test app Weird, here the patch solves the white-dot-around-lights issue. I'm using a HD4850, maybe that's why... I've attached a small test app, which exhibits the problem fixed by this patch. Without the patch applied it fails almost every time (the failure is immediate). Could you please compile it and launch it a few times and tell me : 1) if it fails without the patch 2) if so, does the patch brings some improvement ? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 25248] Machinarium crashes with current git radeon driver
https://bugs.freedesktop.org/show_bug.cgi?id=25248 Phil Armstrong p...@kantaka.co.uk changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Phil Armstrong p...@kantaka.co.uk 2011-06-07 05:30:44 PDT --- Seems to work fine with current Debian xorg/radeon driver. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC] m68k/bitops: Make bitmap data pointer of atomic ops volatile
On Tue, Jun 07, 2011 at 01:22:29PM +0200, Arnd Bergmann wrote: On Tuesday 07 June 2011, Geert Uytterhoeven wrote: You mean the host_busy variable in the IDE code? That would also apply to context_flag in the DRM code: drivers/gpu/drm/drm_context.c:233: warning: passing argument 2 of ‘__constant_test_and_set_bit’ discards qualifiers from pointer target type drivers/gpu/drm/drm_context.c:233: warning: passing argument 2 of ‘__generic_test_and_set_bit’ discards qualifiers from pointer target type Yes, that fits the same category. is wrong, though. It probably doesn't hurt to do both. asm-generic/bitops/atomic.h has the volatiles everywhere. That's why I'm wondering. I guess what happened is that some variables are traditionally marked as volatile although they shouldn't be, and most architectures have adapted their bitops to make the warnings go away. If you see more warnings of that kind, it's probably fine to just do the same on m68k. The volatile modifier doesn't really hurt in this case. These operations are required to be atomic and therefore they must be suitable for use with volatile-qualified variables. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
CPU and GPU cache-coherence
3D render image on WC AGP aperture BO and then CPU fetch the image from this bo, in order to achieve performance, after 3D finished rendering, validate this bo into cached system memory and then read it from system memory. But I always get garbage from there. After check TTM bo validate codes, it has dealt with cache coherence properly, i wonder whether there is something I misunderstand or it is not allowed to move the WC bo from AGP to system memory for reading? thanks. -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev-- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC] m68k/bitops: Make bitmap data pointer of atomic ops volatile
On Tuesday 07 June 2011, Ben Hutchings wrote: On Tue, Jun 07, 2011 at 01:22:29PM +0200, Arnd Bergmann wrote: I guess what happened is that some variables are traditionally marked as volatile although they shouldn't be, and most architectures have adapted their bitops to make the warnings go away. If you see more warnings of that kind, it's probably fine to just do the same on m68k. The volatile modifier doesn't really hurt in this case. These operations are required to be atomic and therefore they must be suitable for use with volatile-qualified variables. As I said, it's not wrong for them to have a volatile qualifier in the argument list. However, there should also not be the need for the qualifier in any of the callers, because the bitops only work if all accesses to the data are done through bitops functions, and that means that the qualifier on the variable is completely meaningless. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36892] New: page faults / general protection faults under heavy 3d load
https://bugzilla.kernel.org/show_bug.cgi?id=36892 Summary: page faults / general protection faults under heavy 3d load Product: Drivers Version: 2.5 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: niels_...@salscheider-online.de Regression: No I get page faults or general protection faults under heavy 3d load (like sauerbraten, but sometimes switching windows with kwin is enough) in random processes. I have a radeon hd 6870 and use r600g from mesa git. This happens on 3.0-rc1 and 2.6.39. I am not sure if this is a problem with older kernels, too, since I get gpu lockups with them. I am not sure what could cause these problems, maybe some bug in gem / ttm? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36892] page faults / general protection faults under heavy 3d load
https://bugzilla.kernel.org/show_bug.cgi?id=36892 --- Comment #1 from Niels Ole Salscheider niels_...@salscheider-online.de 2011-06-07 14:13:59 --- Created an attachment (id=61052) -- (https://bugzilla.kernel.org/attachment.cgi?id=61052) kernel message -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36892] page faults / general protection faults under heavy 3d load
https://bugzilla.kernel.org/show_bug.cgi?id=36892 --- Comment #2 from Niels Ole Salscheider niels_...@salscheider-online.de 2011-06-07 14:14:24 --- Created an attachment (id=61062) -- (https://bugzilla.kernel.org/attachment.cgi?id=61062) kernel message 2 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36892] page faults / general protection faults under heavy 3d load
https://bugzilla.kernel.org/show_bug.cgi?id=36892 --- Comment #3 from Niels Ole Salscheider niels_...@salscheider-online.de 2011-06-07 14:14:41 --- Created an attachment (id=61072) -- (https://bugzilla.kernel.org/attachment.cgi?id=61072) kernel message 3 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36892] page faults / general protection faults under heavy 3d load
https://bugzilla.kernel.org/show_bug.cgi?id=36892 --- Comment #4 from Niels Ole Salscheider niels_...@salscheider-online.de 2011-06-07 14:15:02 --- Created an attachment (id=61082) -- (https://bugzilla.kernel.org/attachment.cgi?id=61082) kernel message 4 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36892] page faults / general protection faults under heavy 3d load
https://bugzilla.kernel.org/show_bug.cgi?id=36892 --- Comment #5 from Niels Ole Salscheider niels_...@salscheider-online.de 2011-06-07 14:18:17 --- btw: I do not know why it was out of memory in the first error message. I have 8GB of ram but usually less than 4GB are used (most of it for virtuoso-t and nepomukservices) -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36892] page faults / general protection faults under heavy 3d load
https://bugzilla.kernel.org/show_bug.cgi?id=36892 Niels Ole Salscheider niels_...@salscheider-online.de changed: What|Removed |Added CC||niels_ole@salscheider-onlin ||e.de Kernel Version||3.0-rc1 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37028] Amnesia/HPL2 Demo: Strange graphical bugs on r600g
https://bugs.freedesktop.org/show_bug.cgi?id=37028
--- Comment #12 from Maggioni Marcello haya...@gmail.com 2011-06-07 09:15:59
PDT ---
Created an attachment (id=47666)
-- (https://bugs.freedesktop.org/attachment.cgi?id=47666)
Further tests
Hi, your test application crashes on my system with and without the patch.
I determined that the result that the query should return is 68698 samples each
execution.
So I modified your test application to see how many times that value is
returned instead of some other random values (the modded app is attached) and
the output is this:
[hades@artemis ~]$ ./query
Correct values: 17
Not correct values: 33
Correct values: 50
Not correct values: 0
Correct values: 50
Not correct values: 0
Correct values: 50
Not correct values: 0
Correct values: 50
Not correct values: 0
Correct values: 50
.
As you can see at the beginning the probability of wrong queries is high and
then it corrects itself out. All the subsequent queries seem to be correct.
This happens both with your patch and without it.
I tried to step inside the gallium code (r600_query_result) to see what values
are returned.
When the value is correct I get values like:
(gdb) n
1641query-result += end - start;
2: /x end = 0x8001824291f0
1: /x start = 0x800182424e0c
...
when I get an error I get values for start and end like :
(gdb) n
1641query-result += end - start;
2: /x end = 0x
1: /x start = 0x
(gdb) n
1636for (i = 0; i size; i += 4) {
2: /x end = 0x
1: /x start = 0x
(gdb)
That are obviously wrong.
The very first r600_query_result execution gives correct results, then from the
second r600_query_result execution on the results are incorrect and then ,
after some runs, the values become correct again.
I don't know how to interpret this. Maybe a drm bug? I use kernel 2.6.39
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
