Re: WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242
On 03/13/2013 11:36 AM, Jiri Slaby wrote:
> On 02/19/2013 11:32 PM, Marcin Slusarz wrote:
>> On Tue, Feb 19, 2013 at 08:07:44AM +0100, Marcin Slusarz wrote:
>>> On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote:
On 02/19/2013 12:23 AM, Marcin Slusarz wrote:
> Tomorrow I'll post a patch for page allocation failure.
What do you mean -- what kind of patch?
>>>
>>> A patch which will change pgt allocation to use vmalloc.
>
> It's still not in -next. Any plans on this?
Ping...
>> ---
>> From: Marcin Slusarz
>> Subject: [PATCH] drm/nouveau: use vmalloc for pgt allocation
>>
>> Page tables on nv50 take 48kB, which can be hard to allocate in one piece.
>> Let's use vmalloc.
>>
>> Signed-off-by: Marcin Slusarz
>> Cc: sta...@vger.kernel.org
>> ---
>> drivers/gpu/drm/nouveau/core/subdev/vm/base.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
>> b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
>> index 77c67fc..e66fb77 100644
>> --- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
>> +++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
>> @@ -362,7 +362,7 @@ nouveau_vm_create(struct nouveau_vmmgr *vmm, u64 offset,
>> u64 length,
>> vm->fpde = offset >> (vmm->pgt_bits + 12);
>> vm->lpde = (offset + length - 1) >> (vmm->pgt_bits + 12);
>>
>> -vm->pgt = kcalloc(vm->lpde - vm->fpde + 1, sizeof(*vm->pgt),
>> GFP_KERNEL);
>> +vm->pgt = vzalloc((vm->lpde - vm->fpde + 1) * sizeof(*vm->pgt));
>> if (!vm->pgt) {
>> kfree(vm);
>> return -ENOMEM;
>> @@ -371,7 +371,7 @@ nouveau_vm_create(struct nouveau_vmmgr *vmm, u64 offset,
>> u64 length,
>> ret = nouveau_mm_init(&vm->mm, mm_offset >> 12, mm_length >> 12,
>>block >> 12);
>> if (ret) {
>> -kfree(vm->pgt);
>> +vfree(vm->pgt);
>> kfree(vm);
>> return ret;
>> }
>> @@ -446,7 +446,7 @@ nouveau_vm_del(struct nouveau_vm *vm)
>> }
>>
>> nouveau_mm_fini(&vm->mm);
>> -kfree(vm->pgt);
>> +vfree(vm->pgt);
>> kfree(vm);
>> }
>>
>>
>
>
--
js
suse labs
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65810] Small black box at the left top corner after playing some 3d games...
https://bugs.freedesktop.org/show_bug.cgi?id=65810 --- Comment #1 from Michel Dänzer --- It looks like there's a drop shadow around the box, so it could just be a window left behind by the games or something. What does xwininfo say when you click on the box? -- 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 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.
https://bugs.freedesktop.org/show_bug.cgi?id=64913 --- Comment #10 from Knut Andre Tidemann --- I've tested the attached patch, and it fixes the crash in kerbal space program. I've also run the piglit r600.tests before and after patching, but it seems the results are somewhat mixed. I ran piglit once before patching and a few times afterwards and the results differed each time I ran the tests. One time the test even zombied. -- 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/mgag200: Hardware cursor support
On Thu, Jun 13, 2013 at 3:17 AM, Christopher Harvey wrote: > On Wed, Jun 05 2013, Christopher Harvey wrote: >> G200 cards support, at best, 16 colour palleted images for the cursor >> so we do a conversion in the cursor_set function, and reject cursors >> with more than 16 colours, or cursors with partial transparency. Xorg >> falls back gracefully to software cursors in this case. >> >> We can't disable/enable the cursor hardware without causing momentary >> corruption around the cursor. Instead, once the cursor is on we leave >> it on, and simulate turning the cursor off by moving it >> offscreen. This works well. >> >> Since we can't disable -> update -> enable the cursors, we double >> buffer cursor icons, then just move the base address that points to >> the old cursor, to the new. This also works well, but uses an extra >> page of memory. >> >> The cursor buffers are lazily-allocated on first cursor_set. This is >> to make sure they don't take priority over any framebuffers in case of >> limited memory. >> >> Here is a representation of how the bitmap for the cursor is mapped in G200 >> memory : >> >> Each line of color cursor use 6 Slices of 8 bytes. Slices 0 to 3 >> are used for the 4bpp bitmap, slice 4 for XOR mask and slice 5 for >> AND mask. Each line has the following format: >> >> // Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 >> // >> // S0: P00-01 P02-03 P04-05 P06-07 P08-09 P10-11 P12-13 P14-15 >> // S1: P16-17 P18-19 P20-21 P22-23 P24-25 P26-27 P28-29 P30-31 >> // S2: P32-33 P34-35 P36-37 P38-39 P40-41 P42-43 P44-45 P46-47 >> // S3: P48-49 P50-51 P52-53 P54-55 P56-57 P58-59 P60-61 P62-63 >> // S4: X63-56 X55-48 X47-40 X39-32 X31-24 X23-16 X15-08 X07-00 >> // S5: A63-56 A55-48 A47-40 A39-32 A31-24 A23-16 A15-08 A07-00 >> // >> // S0 to S5 = Slices 0 to 5 >> // P00 to P63= Bitmap - pixels 0 to 63 >> // X00 to X63= always 0 - pixels 0 to 63 >> // A00 to A63= transparent markers - pixels 0 to 63 >> // 1 means colour, 0 means transparent >> >> Signed-off-by: Christopher Harvey >> Signed-off-by: Mathieu Larouche >> Acked-by: Julia Lemire >> Tested-by: Julia Lemire > > ping. I've applied this to drm-next, Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.
https://bugs.freedesktop.org/show_bug.cgi?id=64913 --- Comment #11 from Krzysztof A. Sobiecki --- Does this behavior also occurred before patching? -- 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 65810] Small black box at the left top corner after playing some 3d games...
https://bugs.freedesktop.org/show_bug.cgi?id=65810 Andreas Boll changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- 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 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.
https://bugs.freedesktop.org/show_bug.cgi?id=64913 --- Comment #12 from Knut Andre Tidemann --- Yeah, I ran the piglit tests multiple times again without the patch applied, and the same result can be observed. -- 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
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
This patch adds a buffer synchronization framework based on DMA BUF[1] and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] for lock mechanism. The purpose of this framework is not only to couple cache operations, and buffer access control to CPU and DMA but also to provide easy-to-use interfaces for device drivers and potentially user application (not implemented for user applications, yet). And this framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. Changelog v2: - use atomic_add_unless to avoid potential bug. - add a macro for checking valid access type. - code clean. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, "test sync"); dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... And the below can be used as access types: DMA_BUF_ACCESS_READ, - CPU will access a buffer for read. DMA_BUF_ACCESS_WRITE, - CPU will access a buffer for read or write. DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read or write. 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. A task may never try to unlock a buffer after taking a lock to the buffer. In this case, a timer handler to the corresponding sync object is called in five (default) seconds and then the timed-out buffer is unlocked by work queue handler to avoid lockups and to enforce resources of the buffer. The below is how to use: 1. Allocate and Initialize a sync object: struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, "test sync"); ... 2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... 3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: dmabuf_sync_lock(sync); ... 4. Now CPU or DMA can access all dmabufs locked in step 3. 5. Unlock all dmabufs added in a sync object after DMA or CPU access to these dmabufs is completed: dmabuf_sync_unlock(sync); And call the following functions to release all resources, dmabuf_sync_put_all(sync); dmabuf_sync_fini(sync); You can refer to actual example codes: https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/ commit/?h=dmabuf-sync&id=4030bdee9bab5841ad32faade528d04cc0c5fc94 https://git.kernel.org/cgit/linux/
Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
Op 17-06-13 13:15, Inki Dae schreef: > This patch adds a buffer synchronization framework based on DMA BUF[1] > and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] > for lock mechanism. > > The purpose of this framework is not only to couple cache operations, > and buffer access control to CPU and DMA but also to provide easy-to-use > interfaces for device drivers and potentially user application > (not implemented for user applications, yet). And this framework can be > used for all dma devices using system memory as dma buffer, especially > for most ARM based SoCs. > > Changelog v2: > - use atomic_add_unless to avoid potential bug. > - add a macro for checking valid access type. > - code clean. > > The mechanism of this framework has the following steps, > 1. Register dmabufs to a sync object - A task gets a new sync object and > can add one or more dmabufs that the task wants to access. > This registering should be performed when a device context or an event > context such as a page flip event is created or before CPU accesses a > shared > buffer. > > dma_buf_sync_get(a sync object, a dmabuf); > > 2. Lock a sync object - A task tries to lock all dmabufs added in its own > sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead > lock issue and for race condition between CPU and CPU, CPU and DMA, and > DMA > and DMA. Taking a lock means that others cannot access all locked dmabufs > until the task that locked the corresponding dmabufs, unlocks all the > locked > dmabufs. > This locking should be performed before DMA or CPU accesses these dmabufs. > > dma_buf_sync_lock(a sync object); > > 3. Unlock a sync object - The task unlocks all dmabufs added in its own > sync > object. The unlock means that the DMA or CPU accesses to the dmabufs have > been completed so that others may access them. > This unlocking should be performed after DMA or CPU has completed accesses > to the dmabufs. > > dma_buf_sync_unlock(a sync object); > > 4. Unregister one or all dmabufs from a sync object - A task unregisters > the given dmabufs from the sync object. This means that the task dosen't > want to lock the dmabufs. > The unregistering should be performed after DMA or CPU has completed > accesses to the dmabufs or when dma_buf_sync_lock() is failed. > > dma_buf_sync_put(a sync object, a dmabuf); > dma_buf_sync_put_all(a sync object); > > The described steps may be summarized as: > get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put > > This framework includes the following two features. > 1. read (shared) and write (exclusive) locks - A task is required to > declare > the access type when the task tries to register a dmabuf; > READ, WRITE, READ DMA, or WRITE DMA. > > The below is example codes, > struct dmabuf_sync *sync; > > sync = dmabuf_sync_init(NULL, "test sync"); > > dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); > ... > > And the below can be used as access types: > DMA_BUF_ACCESS_READ, > - CPU will access a buffer for read. > DMA_BUF_ACCESS_WRITE, > - CPU will access a buffer for read or write. > DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, > - DMA will access a buffer for read > DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, > - DMA will access a buffer for read or write. > > 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. > A task may never try to unlock a buffer after taking a lock to the buffer. > In this case, a timer handler to the corresponding sync object is called > in five (default) seconds and then the timed-out buffer is unlocked by > work > queue handler to avoid lockups and to enforce resources of the buffer. > > The below is how to use: > 1. Allocate and Initialize a sync object: > struct dmabuf_sync *sync; > > sync = dmabuf_sync_init(NULL, "test sync"); > ... > > 2. Add a dmabuf to the sync object when setting up dma buffer relevant > registers: > dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); > ... > > 3. Lock all dmabufs of the sync object before DMA or CPU accesses > the dmabufs: > dmabuf_sync_lock(sync); > ... > > 4. Now CPU or DMA can access all dmabufs locked in step 3. > > 5. Unlock all dmabufs added in a sync object after DMA or CPU access > to these dmabufs is completed: > dmabuf_sync_unlock(sync); > > And call the following functions to release all resources, > dmabuf_sync_put_all(sync); > dmabuf_sync_fini(sync); > > You can refer to actual example codes: > > https://git.kernel.org/cgi
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #65 from Marc Dietrich --- regarding crash in comment 57, there seems to be something wrong with cosine: https://www.khronos.org/registry/webgl/conformance-suites/1.0.2/conformance/glsl/functions/glsl-function-cos.html reproduces the crash. -- 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 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #66 from Marc Dietrich --- crash happens with firefox only, chrome reports test failed. both browser pass the test with R600_LLVM=0 -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tegra: Include linux/types.h
"make headers_check" complains about include/uapi/drm/tegra_drm.h:
[...]/usr/include/drm/tegra_drm.h:21: found __[us]{8,16,32,64} type without
#include
So let's include linux/types.h in this header.
Signed-off-by: Paul Bolle
---
Tested only with "make headers_check". I don't actually build or run
code that uses tegra_drm.h.
include/uapi/drm/tegra_drm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index 6e132a2..6698e81 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -17,6 +17,8 @@
#ifndef _UAPI_TEGRA_DRM_H_
#define _UAPI_TEGRA_DRM_H_
+#include
+
struct drm_tegra_gem_create {
__u64 size;
__u32 flags;
--
1.8.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 59761] Kernel fails to reset AMD HD5770 GPU properly and encounters OOPS. GPU reset fails - system remains in unusable state.
https://bugzilla.kernel.org/show_bug.cgi?id=59761 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher 2013-06-17 12:56:22 --- Can you bisect mesa and find out what commit caused the breakage? -- 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
RE: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
> -Original Message- > From: Maarten Lankhorst [mailto:maarten.lankho...@canonical.com] > Sent: Monday, June 17, 2013 8:35 PM > To: Inki Dae > Cc: dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org; linux- > arm-ker...@lists.infradead.org; linux-me...@vger.kernel.org; > dan...@ffwll.ch; robdcl...@gmail.com; kyungmin.p...@samsung.com; > myungjoo@samsung.com; yj44@samsung.com > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization > framework > > Op 17-06-13 13:15, Inki Dae schreef: > > This patch adds a buffer synchronization framework based on DMA BUF[1] > > and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] > > for lock mechanism. > > > > The purpose of this framework is not only to couple cache operations, > > and buffer access control to CPU and DMA but also to provide easy-to-use > > interfaces for device drivers and potentially user application > > (not implemented for user applications, yet). And this framework can be > > used for all dma devices using system memory as dma buffer, especially > > for most ARM based SoCs. > > > > Changelog v2: > > - use atomic_add_unless to avoid potential bug. > > - add a macro for checking valid access type. > > - code clean. > > > > The mechanism of this framework has the following steps, > > 1. Register dmabufs to a sync object - A task gets a new sync object > and > > can add one or more dmabufs that the task wants to access. > > This registering should be performed when a device context or an > event > > context such as a page flip event is created or before CPU accesses a > shared > > buffer. > > > > dma_buf_sync_get(a sync object, a dmabuf); > > > > 2. Lock a sync object - A task tries to lock all dmabufs added in its > own > > sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid > dead > > lock issue and for race condition between CPU and CPU, CPU and DMA, > and DMA > > and DMA. Taking a lock means that others cannot access all locked > dmabufs > > until the task that locked the corresponding dmabufs, unlocks all the > locked > > dmabufs. > > This locking should be performed before DMA or CPU accesses these > dmabufs. > > > > dma_buf_sync_lock(a sync object); > > > > 3. Unlock a sync object - The task unlocks all dmabufs added in its > own sync > > object. The unlock means that the DMA or CPU accesses to the dmabufs > have > > been completed so that others may access them. > > This unlocking should be performed after DMA or CPU has completed > accesses > > to the dmabufs. > > > > dma_buf_sync_unlock(a sync object); > > > > 4. Unregister one or all dmabufs from a sync object - A task > unregisters > > the given dmabufs from the sync object. This means that the task > dosen't > > want to lock the dmabufs. > > The unregistering should be performed after DMA or CPU has completed > > accesses to the dmabufs or when dma_buf_sync_lock() is failed. > > > > dma_buf_sync_put(a sync object, a dmabuf); > > dma_buf_sync_put_all(a sync object); > > > > The described steps may be summarized as: > > get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put > > > > This framework includes the following two features. > > 1. read (shared) and write (exclusive) locks - A task is required to > declare > > the access type when the task tries to register a dmabuf; > > READ, WRITE, READ DMA, or WRITE DMA. > > > > The below is example codes, > > struct dmabuf_sync *sync; > > > > sync = dmabuf_sync_init(NULL, "test sync"); > > > > dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); > > ... > > > > And the below can be used as access types: > > DMA_BUF_ACCESS_READ, > > - CPU will access a buffer for read. > > DMA_BUF_ACCESS_WRITE, > > - CPU will access a buffer for read or write. > > DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, > > - DMA will access a buffer for read > > DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, > > - DMA will access a buffer for read or write. > > > > 2. Mandatory resource releasing - a task cannot hold a lock > indefinitely. > > A task may never try to unlock a buffer after taking a lock to the > buffer. > > In this case, a timer handler to the corresponding sync object is > called > > in five (default) seconds and then the timed-out buffer is unlocked > by work > > queue handler to avoid lockups and to enforce resources of the buffer. > > > > The below is how to use: > > 1. Allocate and Initialize a sync object: > > struct dmabuf_sync *sync; > > > > sync = dmabuf_sync_init(NULL, "test sync"); > > ... > > > > 2. Add a dmabuf to the sync object when setting up dma buffer > relevant > >registers: > > dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); > >
[PATCH] drm/nouveau: remove limit on gart
Most graphics cards nowadays have a multiple of this limit as their vram, so
limiting GART doesn't seem to make much sense.
Signed-off-by: Maarten >Lnkhorst
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 3a5e19a..41ddecd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -168,9 +168,6 @@ nouveau_gart_manager_new(struct ttm_mem_type_manager *man,
struct nouveau_bo *nvbo = nouveau_bo(bo);
struct nouveau_mem *node;
- if (unlikely((mem->num_pages << PAGE_SHIFT) >= 512 * 1024 * 1024))
- return -ENOMEM;
-
node = kzalloc(sizeof(*node), GFP_KERNEL);
if (!node)
return -ENOMEM;
@@ -406,8 +403,6 @@ nouveau_ttm_init(struct nouveau_drm *drm)
/* GART init */
if (drm->agp.stat != ENABLED) {
drm->gem.gart_available = nouveau_vmmgr(drm->device)->limit;
- if (drm->gem.gart_available > 512 * 1024 * 1024)
- drm->gem.gart_available = 512 * 1024 * 1024;
} else {
drm->gem.gart_available = drm->agp.size;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/1] drm/mgag200: Added resolution and bandwidth limits for various G200e products.
At the larger resolutions, the g200e series sometimes struggles with maintaining a proper output. Problems like flickering or black bands appearing on screen can occur. In order to avoid this, limitations regarding resolutions and bandwidth have been added for the different variations of the g200e series. Julia Lemire (1): drm/mgag200: Added resolution and bandwidth limits for various G200e products. drivers/gpu/drm/mgag200/mgag200_drv.h |3 +- drivers/gpu/drm/mgag200/mgag200_main.c |2 +- drivers/gpu/drm/mgag200/mgag200_mode.c | 55 ++-- 3 files changed, 56 insertions(+), 4 deletions(-) -- 1.7.10.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/mgag200: Added resolution and bandwidth limits for various G200e products.
This code was ported from the old xorg mga driver. These limits were
implemented as a solution to a number of problems that were seen. These
problems were linked to the bandwidth limitations of the g200e series.
Signed-off-by: Julia Lemire
---
drivers/gpu/drm/mgag200/mgag200_drv.h |3 +-
drivers/gpu/drm/mgag200/mgag200_main.c |2 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 55 ++--
3 files changed, 56 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index bf29b2f..988911a 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -198,7 +198,8 @@ struct mga_device {
struct ttm_bo_device bdev;
} ttm;
- u32 reg_1e24; /* SE model number */
+ /* SE model number stored in reg 0x1e24 */
+ u32 unique_rev_id;
};
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 9905923..dafe049 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -176,7 +176,7 @@ static int mgag200_device_init(struct drm_device *dev,
/* stash G200 SE model number for later use */
if (IS_G200_SE(mdev))
- mdev->reg_1e24 = RREG32(0x1e24);
+ mdev->unique_rev_id = RREG32(0x1e24);
ret = mga_vram_init(mdev);
if (ret)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index ee66bad..3cdebe6 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1008,7 +1008,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
if (IS_G200_SE(mdev)) {
- if (mdev->reg_1e24 >= 0x02) {
+ if (mdev->unique_rev_id >= 0x02) {
u8 hi_pri_lvl;
u32 bpp;
u32 mb;
@@ -1038,7 +1038,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
WREG8(MGAREG_CRTCEXT_DATA, hi_pri_lvl);
} else {
WREG8(MGAREG_CRTCEXT_INDEX, 0x06);
- if (mdev->reg_1e24 >= 0x01)
+ if (mdev->unique_rev_id >= 0x01)
WREG8(MGAREG_CRTCEXT_DATA, 0x03);
else
WREG8(MGAREG_CRTCEXT_DATA, 0x04);
@@ -1410,6 +1410,24 @@ static int mga_vga_get_modes(struct drm_connector
*connector)
return ret;
}
+static uint32_t mga_vga_calculate_mode_bandwidth(struct drm_display_mode *
mode,
+ int bits_per_pixel)
+{
+ uint64_t active_area, total_area, pixels_per_second;
+ uint64_t bytes_per_pixel = (bits_per_pixel + 7) / 8;
+
+ if(!mode->htotal || !mode->vtotal || !mode->clock)
+ return 0;
+
+ active_area = mode->hdisplay * mode->vdisplay;
+ total_area = mode->htotal * mode->vtotal;
+ pixels_per_second = active_area * mode->clock * 1000 / total_area;
+
+ return (uint32_t)(pixels_per_second * bytes_per_pixel * 100 / (1024));
+}
+
+#define MODE_BANDWIDTH MODE_BAD
+
static int mga_vga_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
@@ -1422,6 +1440,39 @@ static int mga_vga_mode_valid(struct drm_connector
*connector,
int i = 0;
/* FIXME: Add bandwidth and g200se limitations */
+ if (IS_G200_SE(mdev)) {
+ if (mdev->unique_rev_id == 0x01) {
+ if (mode->hdisplay > 1600)
+ return MODE_VIRTUAL_X;
+ if (mode->vdisplay > 1200)
+ return MODE_VIRTUAL_Y;
+ if (mga_vga_calculate_mode_bandwidth(mode, bpp) >
(24400 * 1024))
+ return MODE_BANDWIDTH;
+ } else if (mdev->unique_rev_id >= 0x02) {
+ if (mode->hdisplay > 1920)
+ return MODE_VIRTUAL_X;
+ if (mode->vdisplay > 1200)
+ return MODE_VIRTUAL_Y;
+ if (mga_vga_calculate_mode_bandwidth(mode, bpp) >
(30100 * 1024))
+ return MODE_BANDWIDTH;
+ }
+ } else if (mdev->type == G200_WB) {
+ if (mode->hdisplay > 1280)
+ return MODE_VIRTUAL_X;
+ if (mode->vdisplay > 1024)
+ return MODE_VIRTUAL_Y;
+ if (mga_vga_calculate_mode_bandwidth(mode, bpp > (31877 *
1024)))
+ return MODE_BANDWIDTH;
+ } else if (mdev->type == G200_EV &&
+ (mga_vga_calculate_mode_bandwidth(mode, bpp) > (32700 * 1024)))
{
+ return MODE_BANDWIDTH;
+ } else if (mode->type == G200_EH &&
+
Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
Op 17-06-13 15:04, Inki Dae schreef: > >> -Original Message- >> From: Maarten Lankhorst [mailto:maarten.lankho...@canonical.com] >> Sent: Monday, June 17, 2013 8:35 PM >> To: Inki Dae >> Cc: dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org; linux- >> arm-ker...@lists.infradead.org; linux-me...@vger.kernel.org; >> dan...@ffwll.ch; robdcl...@gmail.com; kyungmin.p...@samsung.com; >> myungjoo@samsung.com; yj44@samsung.com >> Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization >> framework >> >> Op 17-06-13 13:15, Inki Dae schreef: >>> This patch adds a buffer synchronization framework based on DMA BUF[1] >>> and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] >>> for lock mechanism. >>> >>> The purpose of this framework is not only to couple cache operations, >>> and buffer access control to CPU and DMA but also to provide easy-to-use >>> interfaces for device drivers and potentially user application >>> (not implemented for user applications, yet). And this framework can be >>> used for all dma devices using system memory as dma buffer, especially >>> for most ARM based SoCs. >>> >>> Changelog v2: >>> - use atomic_add_unless to avoid potential bug. >>> - add a macro for checking valid access type. >>> - code clean. >>> >>> The mechanism of this framework has the following steps, >>> 1. Register dmabufs to a sync object - A task gets a new sync object >> and >>> can add one or more dmabufs that the task wants to access. >>> This registering should be performed when a device context or an >> event >>> context such as a page flip event is created or before CPU accesses > a >> shared >>> buffer. >>> >>> dma_buf_sync_get(a sync object, a dmabuf); >>> >>> 2. Lock a sync object - A task tries to lock all dmabufs added in > its >> own >>> sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid >> dead >>> lock issue and for race condition between CPU and CPU, CPU and DMA, >> and DMA >>> and DMA. Taking a lock means that others cannot access all locked >> dmabufs >>> until the task that locked the corresponding dmabufs, unlocks all > the >> locked >>> dmabufs. >>> This locking should be performed before DMA or CPU accesses these >> dmabufs. >>> dma_buf_sync_lock(a sync object); >>> >>> 3. Unlock a sync object - The task unlocks all dmabufs added in its >> own sync >>> object. The unlock means that the DMA or CPU accesses to the dmabufs >> have >>> been completed so that others may access them. >>> This unlocking should be performed after DMA or CPU has completed >> accesses >>> to the dmabufs. >>> >>> dma_buf_sync_unlock(a sync object); >>> >>> 4. Unregister one or all dmabufs from a sync object - A task >> unregisters >>> the given dmabufs from the sync object. This means that the task >> dosen't >>> want to lock the dmabufs. >>> The unregistering should be performed after DMA or CPU has completed >>> accesses to the dmabufs or when dma_buf_sync_lock() is failed. >>> >>> dma_buf_sync_put(a sync object, a dmabuf); >>> dma_buf_sync_put_all(a sync object); >>> >>> The described steps may be summarized as: >>> get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put >>> >>> This framework includes the following two features. >>> 1. read (shared) and write (exclusive) locks - A task is required to >> declare >>> the access type when the task tries to register a dmabuf; >>> READ, WRITE, READ DMA, or WRITE DMA. >>> >>> The below is example codes, >>> struct dmabuf_sync *sync; >>> >>> sync = dmabuf_sync_init(NULL, "test sync"); >>> >>> dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); >>> ... >>> >>> And the below can be used as access types: >>> DMA_BUF_ACCESS_READ, >>> - CPU will access a buffer for read. >>> DMA_BUF_ACCESS_WRITE, >>> - CPU will access a buffer for read or write. >>> DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, >>> - DMA will access a buffer for read >>> DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, >>> - DMA will access a buffer for read or write. >>> >>> 2. Mandatory resource releasing - a task cannot hold a lock >> indefinitely. >>> A task may never try to unlock a buffer after taking a lock to the >> buffer. >>> In this case, a timer handler to the corresponding sync object is >> called >>> in five (default) seconds and then the timed-out buffer is unlocked >> by work >>> queue handler to avoid lockups and to enforce resources of the > buffer. >>> The below is how to use: >>> 1. Allocate and Initialize a sync object: >>> struct dmabuf_sync *sync; >>> >>> sync = dmabuf_sync_init(NULL, "test sync"); >>> ... >>> >>> 2. Add a dmabuf to the sync object when setting up dma buffer >> relevant >>>registers: >>>
Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Mon, Jun 17, 2013 at 10:04:45PM +0900, Inki Dae wrote: > It's just to implement a thin sync framework coupling cache operation. This > approach is based on dma-buf for more generic implementation against android > sync driver or KDS. > > The described steps may be summarized as: > lock -> cache operation -> CPU or DMA access to a buffer/s -> unlock > > I think that there is no need to get complicated for such approach at least > for most devices sharing system memory. Simple is best. But hang on, doesn't the dmabuf API already provide that? The dmabuf API already uses dma_map_sg() and dma_unmap_sg() by providers, and the rules around the DMA API are that: dma_map_sg() /* DMA _ONLY_ has access, CPU should not access */ dma_unmap_sg() /* DMA may not access, CPU can access */ It's a little more than that if you include the sync_sg_for_cpu and sync_sg_for_device APIs too - but the above is the general idea. What this means from the dmabuf API point of view is that once you attach to a dma_buf, and call dma_buf_map_attachment() to get the SG list, the CPU doesn't have ownership of the buffer and _must_ _not_ access it via any other means - including using the other dma_buf methods, until either the appropriate dma_sync_sg_for_cpu() call has been made or the DMA mapping has been removed via dma_buf_unmap_attachment(). So, the sequence should be: dma_buf_map_attachment() /* do DMA */ dma_buf_unmap_attachment() /* CPU can now access the buffer */ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: Disable writeback by default on ppc
At least on an IBM Power 720, this check passes, but several piglit
tests will reliably trigger GPU resets due to the ring buffer pointers
not being updated. There's probably a better way to limit this to just
affected machines though.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/radeon/r600_cp.c | 7 +++
drivers/gpu/drm/radeon/radeon_cp.c | 7 +++
drivers/gpu/drm/radeon/radeon_device.c | 4 ++--
drivers/gpu/drm/radeon/radeon_drv.c| 2 +-
4 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cp.c b/drivers/gpu/drm/radeon/r600_cp.c
index 1c51c08..ef28532 100644
--- a/drivers/gpu/drm/radeon/r600_cp.c
+++ b/drivers/gpu/drm/radeon/r600_cp.c
@@ -552,6 +552,13 @@ static void r600_test_writeback(drm_radeon_private_t
*dev_priv)
dev_priv->writeback_works = 0;
DRM_INFO("writeback test failed\n");
}
+#if defined(__ppc__) || defined(__ppc64__)
+ /* the test might succeed on ppc, but it's usually not reliable */
+ if (radeon_no_wb == -1) {
+ radeon_no_wb = 1;
+ DRM_INFO("not trusting writeback test due to arch quirk\n");
+ }
+#endif
if (radeon_no_wb == 1) {
dev_priv->writeback_works = 0;
DRM_INFO("writeback forced off\n");
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon/radeon_cp.c
index efc4f64..a967b33 100644
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -892,6 +892,13 @@ static void radeon_test_writeback(drm_radeon_private_t *
dev_priv)
dev_priv->writeback_works = 0;
DRM_INFO("writeback test failed\n");
}
+#if defined(__ppc__) || defined(__ppc64__)
+ /* the test might succeed on ppc, but it's usually not reliable */
+ if (radeon_no_wb == -1) {
+ radeon_no_wb = 1;
+ DRM_INFO("not trusting writeback test due to arch quirk\n");
+ }
+#endif
if (radeon_no_wb == 1) {
dev_priv->writeback_works = 0;
DRM_INFO("writeback forced off\n");
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 1899738..524046e 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -322,8 +322,8 @@ int radeon_wb_init(struct radeon_device *rdev)
/* disable event_write fences */
rdev->wb.use_event = false;
/* disabled via module param */
- if (radeon_no_wb == 1) {
- rdev->wb.enabled = false;
+ if (radeon_no_wb != -1) {
+ rdev->wb.enabled = !!radeon_no_wb;
} else {
if (rdev->flags & RADEON_IS_AGP) {
/* often unreliable on AGP */
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 094e7e5..04809d4 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -146,7 +146,7 @@ static inline void radeon_register_atpx_handler(void) {}
static inline void radeon_unregister_atpx_handler(void) {}
#endif
-int radeon_no_wb;
+int radeon_no_wb = -1;
int radeon_modeset = -1;
int radeon_dynclks = -1;
int radeon_r4xx_atom = 0;
--
1.8.2.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. > > So I've decided to instead rip it all out. It seems to work \o/ When you say 'locking mess in our fbdev support' you mean the general core fbdev driver? Not neccessarily the i915 driver? I am asking b/c that would imply that the other fbdev drivers still hit the locking mess? Thanks! > > Of course a general purpose distro propably wants David's kmscon for any > fallbacks needs and a system compositor to ditch the VT subsystem - atm my > machine here runs with the dummy console so that VT switching between > different > X sessions still works ;-) > > Oh and: At least fedora's boot splash seems to be unhappy about the lack of an > fbdev (it doesn't seem to do anything), which breaks early disk encryption a > bit. The black screen itself shouldn't be a big issue at least for i915, since > with all the fastboot work we can just hang onto the current config and > framebuffer (one missing patch from Chris for the fb preservartion). So as > long > as the bios/grub put up something nice, it'll look ok. > > So just a small step here really, but imo into the right direction. Now, > please > bring on the flames! > > Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd > like to wait for a bit of feedback first. And one more: This also removes the > console_lock completely from our critical path in suspend/resume! > > One thing I haven't wasted a single thought about is kgdb and panic notifier > support. But since the current code is pretty decently broken already (we have > _tons_ of mutex grabbing and waits in there) I don't think people care that > much > about it anyway. Using a sprite to smash the kgdb/panic output on top of > whatever's currently displaying might be an approach. > > Cheers, Daniel > > Daniel Vetter (3): > drm: Add separate Kconfig option for fbdev helpers > drm/i915: Kconfig option to disable the legacy fbdev support > drm/i915: rename intel_fb.c to intel_fbdev.c > > drivers/gpu/drm/Kconfig | 57 ++- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig | 1 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/i915/Kconfig | 56 +++ > drivers/gpu/drm/i915/Makefile| 3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +- > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 12 +- > drivers/gpu/drm/i915/intel_drv.h | 39 - > drivers/gpu/drm/i915/intel_fb.c | 314 > --- > drivers/gpu/drm/i915/intel_fbdev.c | 314 > +++ > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig | 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig | 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 24 files changed, 452 insertions(+), 373 deletions(-) > create mode 100644 drivers/gpu/drm/i915/Kconfig > delete mode 100644 drivers/gpu/drm/i915/intel_fb.c > create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c > > -- > 1.7.11.7 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #67 from Marc Dietrich --- ok, maybe cos, sin, tan, are all broken because of bug 50317. -- 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: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
2013/6/17 Russell King - ARM Linux
> On Mon, Jun 17, 2013 at 10:04:45PM +0900, Inki Dae wrote:
> > It's just to implement a thin sync framework coupling cache operation.
> This
> > approach is based on dma-buf for more generic implementation against
> android
> > sync driver or KDS.
> >
> > The described steps may be summarized as:
> > lock -> cache operation -> CPU or DMA access to a buffer/s ->
> unlock
> >
> > I think that there is no need to get complicated for such approach at
> least
> > for most devices sharing system memory. Simple is best.
>
> But hang on, doesn't the dmabuf API already provide that?
>
> The dmabuf API already uses dma_map_sg() and dma_unmap_sg() by providers,
> and the rules around the DMA API are that:
>
> dma_map_sg()
> /* DMA _ONLY_ has access, CPU should not access */
> dma_unmap_sg()
> /* DMA may not access, CPU can access */
>
> It's a little more than that if you include the sync_sg_for_cpu and
> sync_sg_for_device APIs too - but the above is the general idea. What
> this means from the dmabuf API point of view is that once you attach to
> a dma_buf, and call dma_buf_map_attachment() to get the SG list, the CPU
> doesn't have ownership of the buffer and _must_ _not_ access it via any
> other means - including using the other dma_buf methods, until either
> the appropriate dma_sync_sg_for_cpu() call has been made or the DMA
> mapping has been removed via dma_buf_unmap_attachment().
>
> So, the sequence should be:
>
> dma_buf_map_attachment()
> /* do DMA */
> dma_buf_unmap_attachment()
> /* CPU can now access the buffer */
>
Exactly right. But that is not definitely my point. Could you please see
the below simple example?:
(Presume that CPU and DMA share a buffer and the buffer is mapped with user
space as cachable)
handle1 = drm_gem_fd_to_handle(a dmabuf fd); > 1
...
va1 = drm_gem_mmap(handle1);
va2 = drm_gem_mmap(handle2);
va3 = malloc(size);
...
while (conditions) {
memcpy(va1, some data, size);
...
drm_xxx_set_src_dma_buffer(handle1, ...);
...
drm_xxx_set_dst_dma_buffer(handle2, ...);
...
/* user need to request cache clean at here. */ > 2
...
/* blocked until dma operation is completed. */
drm_xxx_start_dma(...);
...
/* user need to request cache invalidate at here. */ >
3
memcpy(va3, va2, size);
}
gem_close(handle1); -> 4
dma_buf_map_attachment() is called by number 1 and
dma_buf_unmap_attachement() is called by number 4. However, how about
number 2 and number 3? My point is those. As I already mentioned through a
document file, user prcesses would need to request repeatedly cache
operation, number 2 and 3 as long as the conditions is true because kernel
side cannot be aware of when cpu accesses a shard buffer in this case. And
such codes could be used by user app here and there. However, we cannot
prevent such app from requesting excessive cache operations although such
app are overusing cache operations unnecessarily. So my approach is just
initial idea to prevent the overuse of cache operation: with this approach,
all cache operations are done in kernel side and that is why I try to
coulpe cache operation and buffer synchronization between CPU and DMA.
Thanks,
Inki Dae
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: Disable writeback by default on ppc
On Mon, Jun 17, 2013 at 10:06 AM, Adam Jackson wrote:
> At least on an IBM Power 720, this check passes, but several piglit
> tests will reliably trigger GPU resets due to the ring buffer pointers
> not being updated. There's probably a better way to limit this to just
> affected machines though.
What radeon chips are you seeing this on? wb is more or less required
on r6xx and newer and I'm not sure those generations will even work
properly without writeback enabled these days. We force it to always
be enabled on APUs and NI and newer asics. With KMS, wb encompasses
more than just rptr writeback; it covers pretty much everything
involving the GPU writing any status information to memory.
Alex
>
> Signed-off-by: Adam Jackson
> ---
> drivers/gpu/drm/radeon/r600_cp.c | 7 +++
> drivers/gpu/drm/radeon/radeon_cp.c | 7 +++
> drivers/gpu/drm/radeon/radeon_device.c | 4 ++--
> drivers/gpu/drm/radeon/radeon_drv.c| 2 +-
> 4 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600_cp.c
> b/drivers/gpu/drm/radeon/r600_cp.c
> index 1c51c08..ef28532 100644
> --- a/drivers/gpu/drm/radeon/r600_cp.c
> +++ b/drivers/gpu/drm/radeon/r600_cp.c
> @@ -552,6 +552,13 @@ static void r600_test_writeback(drm_radeon_private_t
> *dev_priv)
> dev_priv->writeback_works = 0;
> DRM_INFO("writeback test failed\n");
> }
> +#if defined(__ppc__) || defined(__ppc64__)
> + /* the test might succeed on ppc, but it's usually not reliable */
> + if (radeon_no_wb == -1) {
> + radeon_no_wb = 1;
> + DRM_INFO("not trusting writeback test due to arch quirk\n");
> + }
> +#endif
> if (radeon_no_wb == 1) {
> dev_priv->writeback_works = 0;
> DRM_INFO("writeback forced off\n");
> diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
> b/drivers/gpu/drm/radeon/radeon_cp.c
> index efc4f64..a967b33 100644
> --- a/drivers/gpu/drm/radeon/radeon_cp.c
> +++ b/drivers/gpu/drm/radeon/radeon_cp.c
> @@ -892,6 +892,13 @@ static void radeon_test_writeback(drm_radeon_private_t *
> dev_priv)
> dev_priv->writeback_works = 0;
> DRM_INFO("writeback test failed\n");
> }
> +#if defined(__ppc__) || defined(__ppc64__)
> + /* the test might succeed on ppc, but it's usually not reliable */
> + if (radeon_no_wb == -1) {
> + radeon_no_wb = 1;
> + DRM_INFO("not trusting writeback test due to arch quirk\n");
> + }
> +#endif
> if (radeon_no_wb == 1) {
> dev_priv->writeback_works = 0;
> DRM_INFO("writeback forced off\n");
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 1899738..524046e 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -322,8 +322,8 @@ int radeon_wb_init(struct radeon_device *rdev)
> /* disable event_write fences */
> rdev->wb.use_event = false;
> /* disabled via module param */
> - if (radeon_no_wb == 1) {
> - rdev->wb.enabled = false;
> + if (radeon_no_wb != -1) {
> + rdev->wb.enabled = !!radeon_no_wb;
> } else {
> if (rdev->flags & RADEON_IS_AGP) {
> /* often unreliable on AGP */
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 094e7e5..04809d4 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -146,7 +146,7 @@ static inline void radeon_register_atpx_handler(void) {}
> static inline void radeon_unregister_atpx_handler(void) {}
> #endif
>
> -int radeon_no_wb;
> +int radeon_no_wb = -1;
> int radeon_modeset = -1;
> int radeon_dynclks = -1;
> int radeon_r4xx_atom = 0;
> --
> 1.8.2.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
2013/6/17 Maarten Lankhorst > Op 17-06-13 15:04, Inki Dae schreef: > > > >> -Original Message- > >> From: Maarten Lankhorst [mailto:maarten.lankho...@canonical.com] > >> Sent: Monday, June 17, 2013 8:35 PM > >> To: Inki Dae > >> Cc: dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org; > linux- > >> arm-ker...@lists.infradead.org; linux-me...@vger.kernel.org; > >> dan...@ffwll.ch; robdcl...@gmail.com; kyungmin.p...@samsung.com; > >> myungjoo@samsung.com; yj44@samsung.com > >> Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer > synchronization > >> framework > >> > >> Op 17-06-13 13:15, Inki Dae schreef: > >>> This patch adds a buffer synchronization framework based on DMA BUF[1] > >>> and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] > >>> for lock mechanism. > >>> > >>> The purpose of this framework is not only to couple cache operations, > >>> and buffer access control to CPU and DMA but also to provide > easy-to-use > >>> interfaces for device drivers and potentially user application > >>> (not implemented for user applications, yet). And this framework can be > >>> used for all dma devices using system memory as dma buffer, especially > >>> for most ARM based SoCs. > >>> > >>> Changelog v2: > >>> - use atomic_add_unless to avoid potential bug. > >>> - add a macro for checking valid access type. > >>> - code clean. > >>> > >>> The mechanism of this framework has the following steps, > >>> 1. Register dmabufs to a sync object - A task gets a new sync > object > >> and > >>> can add one or more dmabufs that the task wants to access. > >>> This registering should be performed when a device context or an > >> event > >>> context such as a page flip event is created or before CPU accesses > > a > >> shared > >>> buffer. > >>> > >>> dma_buf_sync_get(a sync object, a dmabuf); > >>> > >>> 2. Lock a sync object - A task tries to lock all dmabufs added in > > its > >> own > >>> sync object. Basically, the lock mechanism uses ww-mutex[1] to > avoid > >> dead > >>> lock issue and for race condition between CPU and CPU, CPU and DMA, > >> and DMA > >>> and DMA. Taking a lock means that others cannot access all locked > >> dmabufs > >>> until the task that locked the corresponding dmabufs, unlocks all > > the > >> locked > >>> dmabufs. > >>> This locking should be performed before DMA or CPU accesses these > >> dmabufs. > >>> dma_buf_sync_lock(a sync object); > >>> > >>> 3. Unlock a sync object - The task unlocks all dmabufs added in its > >> own sync > >>> object. The unlock means that the DMA or CPU accesses to the > dmabufs > >> have > >>> been completed so that others may access them. > >>> This unlocking should be performed after DMA or CPU has completed > >> accesses > >>> to the dmabufs. > >>> > >>> dma_buf_sync_unlock(a sync object); > >>> > >>> 4. Unregister one or all dmabufs from a sync object - A task > >> unregisters > >>> the given dmabufs from the sync object. This means that the task > >> dosen't > >>> want to lock the dmabufs. > >>> The unregistering should be performed after DMA or CPU has > completed > >>> accesses to the dmabufs or when dma_buf_sync_lock() is failed. > >>> > >>> dma_buf_sync_put(a sync object, a dmabuf); > >>> dma_buf_sync_put_all(a sync object); > >>> > >>> The described steps may be summarized as: > >>> get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put > >>> > >>> This framework includes the following two features. > >>> 1. read (shared) and write (exclusive) locks - A task is required > to > >> declare > >>> the access type when the task tries to register a dmabuf; > >>> READ, WRITE, READ DMA, or WRITE DMA. > >>> > >>> The below is example codes, > >>> struct dmabuf_sync *sync; > >>> > >>> sync = dmabuf_sync_init(NULL, "test sync"); > >>> > >>> dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); > >>> ... > >>> > >>> And the below can be used as access types: > >>> DMA_BUF_ACCESS_READ, > >>> - CPU will access a buffer for read. > >>> DMA_BUF_ACCESS_WRITE, > >>> - CPU will access a buffer for read or write. > >>> DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, > >>> - DMA will access a buffer for read > >>> DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, > >>> - DMA will access a buffer for read or write. > >>> > >>> 2. Mandatory resource releasing - a task cannot hold a lock > >> indefinitely. > >>> A task may never try to unlock a buffer after taking a lock to the > >> buffer. > >>> In this case, a timer handler to the corresponding sync object is > >> called > >>> in five (default) seconds and then the timed-out buffer is unlocked > >> by work > >>> queue handler to avoid lockups and to enforce resources of the > > buffer. > >>> The below is how to use: > >
Re: [PATCH] drm/radeon: Disable writeback by default on ppc
On Mon, 2013-06-17 at 11:04 -0400, Alex Deucher wrote: > On Mon, Jun 17, 2013 at 10:06 AM, Adam Jackson wrote: > > At least on an IBM Power 720, this check passes, but several piglit > > tests will reliably trigger GPU resets due to the ring buffer pointers > > not being updated. There's probably a better way to limit this to just > > affected machines though. > > What radeon chips are you seeing this on? wb is more or less required > on r6xx and newer and I'm not sure those generations will even work > properly without writeback enabled these days. We force it to always > be enabled on APUs and NI and newer asics. With KMS, wb encompasses > more than just rptr writeback; it covers pretty much everything > involving the GPU writing any status information to memory. FirePro 2270, at least. Booting with no_wb=1, piglit runs to completion with no GPU resets or IB submission failures. Booting without no_wb, the following piglits go from pass to fail, all complaining that the kernel rejected CS: no-wb wb (info)(info) All7598/9587 7403/9553 glean 362/385 361/385 pointAtten pass fail texture_srgb pass fail shaders477/533 441/533 glsl-algebraic-add-add-1 pass fail glsl-algebraic-add-add-2 pass fail glsl-algebraic-add-add-3 pass fail glsl-algebraic-sub-zero-3 pass fail glsl-algebraic-sub-zero-4 pass fail glsl-complex-subscript pass fail glsl-copy-propagation-if-1 pass fail glsl-copy-propagation-if-2 pass fail glsl-copy-propagation-if-3 pass fail glsl-copy-propagation-vector-indexing pass fail glsl-fs-atan-2 pass fail glsl-fs-dot-vec2-2 pass fail glsl-fs-log2 pass fail glsl-fs-main-returnpass fail glsl-fs-max-3 pass fail glsl-fs-min-2 pass fail glsl-fs-min-3 pass fail glsl-fs-statevar-call pass fail glsl-fs-struct-equal pass fail glsl-function-chain16 pass fail glsl-implicit-conversion-02pass fail glsl-inout-struct-01 pass fail glsl-inout-struct-02 pass fail glsl-link-varying-TexCoord pass fail glsl-link-varyings-2 pass fail glsl-uniform-initializer-4 pass fail glsl-uniform-initializer-6 pass fail glsl-uniform-initializer-7 pass fail glsl-vs-abs-neg-with-intermediate pass fail glsl-vs-clamp-1pass fail glsl-vs-deadcode-1 pass fail glsl-vs-deadcode-2 pass fail glsl-vs-f2bpass fail glsl-vs-position-outvalpass fail link-uniform-array-sizepass fail loopfunc pass fail spec 5921/7801 5763/7767 !OpenGL 1.1118/229 101/219 depthstencil-default_fb-clear pass fail getteximage-simple pass fail texwrap formats27/50 12/40 GL_LUMINANCE12 pass fail GL_LUMINANCE16 pass fail GL_LUMINANCE4 pass fail GL_LUMINANCE4_ALPHA4 pass fail GL_LUMINANCE8
Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> 2013/6/17 Russell King - ARM Linux
> Exactly right. But that is not definitely my point. Could you please see
> the below simple example?:
> (Presume that CPU and DMA share a buffer and the buffer is mapped with user
> space as cachable)
>
> handle1 = drm_gem_fd_to_handle(a dmabuf fd); > 1
> ...
> va1 = drm_gem_mmap(handle1);
> va2 = drm_gem_mmap(handle2);
> va3 = malloc(size);
> ...
>
> while (conditions) {
> memcpy(va1, some data, size);
No!
Well, the first thing to say here is that under the requirements of the
DMA API, the above is immediately invalid, because you're writing to a
buffer which under the terms of the DMA API is currently owned by the
DMA agent, *not* by the CPU. You're supposed to call dma_sync_sg_for_cpu()
before you do that - but how is userspace supposed to know that requirement?
Why should userspace even _have_ to know these requirements of the DMA
API?
It's also entirely possible that drm_gem_fd_to_handle() (which indirectly
causes dma_map_sg() on the buffers scatterlist) followed by mmap'ing it
into userspace is a bug too, as it has the potential to touch caches or
stuff in ways that maybe the DMA or IOMMU may not expect - but I'm not
going to make too big a deal about that, because I don't think we have
anything that picky.
However, the first point above is the most important one, and exposing
the quirks of the DMA API to userland is certainly not a nice thing to be
doing. This needs to be fixed - we can't go and enforce an API which is
deeply embedded within the kernel all the way out to userland.
What we need is something along the lines of:
(a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
or
(b) drm_gem_prime_import() not to call dma_buf_map_attachment() at all.
and for the scatterlist to be mapped for DMA at the point where the DMA
operation is initiated, and unmapped at the point where the DMA operation
is complete.
So no, the problem is not that we need more APIs and code - we need the
existing kernel API fixed so that we don't go exposing userspace to the
requirements of the DMA API. Unless we do that, we're going to end
up with a huge world of pain, where kernel architecture people need to
audit every damned DRM userspace implementation that happens to be run
on their platform, and that's not something arch people really can
afford to do.
Basically, I think the dma_buf stuff needs to be rewritten with the
requirements of the DMA API in the forefront of whosever mind is doing
the rewriting.
Note: the existing stuff does have the nice side effect of being able
to pass buffers which do not have a struct page * associated with them
through the dma_buf API - I think we can still preserve that by having
dma_buf provide a couple of new APIs to do the SG list map/sync/unmap,
but in any case we need to fix the existing API so that:
dma_buf_map_attachment() becomes dma_buf_get_sg()
dma_buf_unmap_attachment() becomes dma_buf_put_sg()
both getting rid of the DMA direction argument, and then we have four
new dma_buf calls:
dma_buf_map_sg()
dma_buf_unmap_sg()
dma_buf_sync_sg_for_cpu()
dma_buf_sync_sg_for_device()
which do the actual sg map/unmap via the DMA API *at the appropriate
time for DMA*.
So, the summary of this is - at the moment, I regard DRM Prime and dmabuf
to be utterly broken in design for architectures such as ARM where the
requirements of the DMA API have to be followed if you're going to have
a happy life.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> > 2013/6/17 Russell King - ARM Linux
> > Exactly right. But that is not definitely my point. Could you please see
> > the below simple example?:
> > (Presume that CPU and DMA share a buffer and the buffer is mapped with user
> > space as cachable)
> >
> > handle1 = drm_gem_fd_to_handle(a dmabuf fd); > 1
> > ...
> > va1 = drm_gem_mmap(handle1);
> > va2 = drm_gem_mmap(handle2);
> > va3 = malloc(size);
> > ...
> >
> > while (conditions) {
> > memcpy(va1, some data, size);
>
> No!
>
> Well, the first thing to say here is that under the requirements of the
> DMA API, the above is immediately invalid, because you're writing to a
> buffer which under the terms of the DMA API is currently owned by the
> DMA agent, *not* by the CPU. You're supposed to call dma_sync_sg_for_cpu()
> before you do that - but how is userspace supposed to know that requirement?
> Why should userspace even _have_ to know these requirements of the DMA
> API?
>
> It's also entirely possible that drm_gem_fd_to_handle() (which indirectly
> causes dma_map_sg() on the buffers scatterlist) followed by mmap'ing it
> into userspace is a bug too, as it has the potential to touch caches or
> stuff in ways that maybe the DMA or IOMMU may not expect - but I'm not
> going to make too big a deal about that, because I don't think we have
> anything that picky.
>
> However, the first point above is the most important one, and exposing
> the quirks of the DMA API to userland is certainly not a nice thing to be
> doing. This needs to be fixed - we can't go and enforce an API which is
> deeply embedded within the kernel all the way out to userland.
>
> What we need is something along the lines of:
> (a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
> or
> (b) drm_gem_prime_import() not to call dma_buf_map_attachment() at all.
>
> and for the scatterlist to be mapped for DMA at the point where the DMA
> operation is initiated, and unmapped at the point where the DMA operation
> is complete.
>
> So no, the problem is not that we need more APIs and code - we need the
> existing kernel API fixed so that we don't go exposing userspace to the
> requirements of the DMA API. Unless we do that, we're going to end
> up with a huge world of pain, where kernel architecture people need to
> audit every damned DRM userspace implementation that happens to be run
> on their platform, and that's not something arch people really can
> afford to do.
>
> Basically, I think the dma_buf stuff needs to be rewritten with the
> requirements of the DMA API in the forefront of whosever mind is doing
> the rewriting.
>
> Note: the existing stuff does have the nice side effect of being able
> to pass buffers which do not have a struct page * associated with them
> through the dma_buf API - I think we can still preserve that by having
> dma_buf provide a couple of new APIs to do the SG list map/sync/unmap,
> but in any case we need to fix the existing API so that:
>
> dma_buf_map_attachment() becomes dma_buf_get_sg()
> dma_buf_unmap_attachment() becomes dma_buf_put_sg()
>
> both getting rid of the DMA direction argument, and then we have four
> new dma_buf calls:
>
> dma_buf_map_sg()
> dma_buf_unmap_sg()
> dma_buf_sync_sg_for_cpu()
> dma_buf_sync_sg_for_device()
>
> which do the actual sg map/unmap via the DMA API *at the appropriate
> time for DMA*.
>
> So, the summary of this is - at the moment, I regard DRM Prime and dmabuf
> to be utterly broken in design for architectures such as ARM where the
> requirements of the DMA API have to be followed if you're going to have
> a happy life.
An addendum to the above:
I'll also point out that the whole thing of having random buffers mapped
into userspace, and doing DMA on them is _highly_ architecture specific.
I'm told that PARISC is one architecture where this does not work (because
DMA needs to have some kind of congruence factor programmed into it which
can be different between kernel and userspace mappings of the same
physical mappings.
I ran into this when trying to come up with a cross-arch DMA-API mmap API,
and PARISC ended up killing the idea off (the remains of that attempt is
the dma_mmap_* stuff in ARM's asm/dma-mapping.h.) However, this was for
the DMA coherent stuff, not the streaming API, which is what _this_
DMA prime/dma_buf stuff is about.
What I'm saying is think _very_ _carefully_ about userspace having
interleaved access to random DMA buffers. Arguably, DRM should _not_
allow this.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65822] [radeonsi] OpenCL is broken
https://bugs.freedesktop.org/show_bug.cgi?id=65822 --- Comment #1 from Tom Stellard --- I will take a look at this when I get a chance. In the mean time it would be great if you could convert these into piglit tests. Here is a good example: http://cgit.freedesktop.org/piglit/tree/tests/cl/program/execute/sha256-Ch.cl Probably one file for each test would be good. -- 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: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
2013/6/18 Russell King - ARM Linux
> On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> > 2013/6/17 Russell King - ARM Linux
> > Exactly right. But that is not definitely my point. Could you please see
> > the below simple example?:
> > (Presume that CPU and DMA share a buffer and the buffer is mapped with
> user
> > space as cachable)
> >
> > handle1 = drm_gem_fd_to_handle(a dmabuf fd); > 1
> > ...
> > va1 = drm_gem_mmap(handle1);
> > va2 = drm_gem_mmap(handle2);
> > va3 = malloc(size);
> > ...
> >
> > while (conditions) {
> > memcpy(va1, some data, size);
>
> No!
>
> Well, the first thing to say here is that under the requirements of the
> DMA API, the above is immediately invalid, because you're writing to a
> buffer which under the terms of the DMA API is currently owned by the
> DMA agent, *not* by the CPU. You're supposed to call dma_sync_sg_for_cpu()
> before you do that - but how is userspace supposed to know that
> requirement?
> Why should userspace even _have_ to know these requirements of the DMA
> API?
>
> It's also entirely possible that drm_gem_fd_to_handle() (which indirectly
> causes dma_map_sg() on the buffers scatterlist) followed by mmap'ing it
> into userspace is a bug too, as it has the potential to touch caches or
> stuff in ways that maybe the DMA or IOMMU may not expect - but I'm not
> going to make too big a deal about that, because I don't think we have
> anything that picky.
>
> However, the first point above is the most important one, and exposing
> the quirks of the DMA API to userland is certainly not a nice thing to be
> doing. This needs to be fixed - we can't go and enforce an API which is
> deeply embedded within the kernel all the way out to userland.
>
> What we need is something along the lines of:
> (a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
> or
> (b) drm_gem_prime_import() not to call dma_buf_map_attachment() at all.
>
> and for the scatterlist to be mapped for DMA at the point where the DMA
> operation is initiated, and unmapped at the point where the DMA operation
> is complete.
>
It seems like that all pages of the scatterlist should be mapped with
DMA every time DMA operation is started (or drm_xxx_set_src_dma_buffer
function call), and the pages should be unmapped from DMA again every
time DMA operation is completed: internally, including each cache
operation. Isn't that big overhead? And If there is no problem, we should
accept such overhead? Actually, drm_gem_fd_to_handle() includes to map a
given dmabuf with iommu table (just logical data) of the DMA. And then, the
device address (or iova) already mapped will be set to buffer register of
the DMA with drm_xxx_set_src/dst_dma_buffer(handle1, ...) call.
Thanks,
Inki Dae
>
> So no, the problem is not that we need more APIs and code - we need the
> existing kernel API fixed so that we don't go exposing userspace to the
> requirements of the DMA API. Unless we do that, we're going to end
> up with a huge world of pain, where kernel architecture people need to
> audit every damned DRM userspace implementation that happens to be run
> on their platform, and that's not something arch people really can
> afford to do.
>
> Basically, I think the dma_buf stuff needs to be rewritten with the
> requirements of the DMA API in the forefront of whosever mind is doing
> the rewriting.
>
> Note: the existing stuff does have the nice side effect of being able
> to pass buffers which do not have a struct page * associated with them
> through the dma_buf API - I think we can still preserve that by having
> dma_buf provide a couple of new APIs to do the SG list map/sync/unmap,
> but in any case we need to fix the existing API so that:
>
> dma_buf_map_attachment() becomes dma_buf_get_sg()
> dma_buf_unmap_attachment() becomes dma_buf_put_sg()
>
> both getting rid of the DMA direction argument, and then we have four
> new dma_buf calls:
>
> dma_buf_map_sg()
> dma_buf_unmap_sg()
> dma_buf_sync_sg_for_cpu()
> dma_buf_sync_sg_for_device()
>
> which do the actual sg map/unmap via the DMA API *at the appropriate
> time for DMA*.
>
> So, the summary of this is - at the moment, I regard DRM Prime and dmabuf
> to be utterly broken in design for architectures such as ARM where the
> requirements of the DMA API have to be followed if you're going to have
> a happy life.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3, part2 14/20] PCI, DRM: use hotplug-safe iterators to walk PCI buses
On Sun, May 26, 2013 at 11:53:11PM +0800, Jiang Liu wrote:
> Enhance DRM drvier to use hotplug-safe iterators to walk PCI buses.
>
> Signed-off-by: Jiang Liu
> Cc: David Airlie
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> ---
> drivers/gpu/drm/drm_fops.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 429e07d..dc8c40b 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -359,9 +359,11 @@ static int drm_open_helper(struct inode *inode, struct
> file *filp,
> pci_dev_put(pci_dev);
> }
> if (!dev->hose) {
> - struct pci_bus *b = pci_bus_b(pci_root_buses.next);
> - if (b)
> + struct pci_bus *b = pci_get_next_root_bus(NULL);
> + if (b) {
> dev->hose = b->sysdata;
> + pci_bus_put(b);
> + }
This is a gross hack to begin with, and it would be far better to get
rid of the whole "#ifdef __alpha__" block that contains this code.
I can't believe alpha is so special that it needs to do something
that no other arch needs.
> }
> }
> #endif
> --
> 1.8.1.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Tue, Jun 18, 2013 at 02:19:04AM +0900, Inki Dae wrote:
> It seems like that all pages of the scatterlist should be mapped with
> DMA every time DMA operation is started (or drm_xxx_set_src_dma_buffer
> function call), and the pages should be unmapped from DMA again every
> time DMA operation is completed: internally, including each cache
> operation.
Correct.
> Isn't that big overhead?
Yes, if you _have_ to do a cache operation to ensure that the DMA agent
can see the data the CPU has written.
> And If there is no problem, we should accept such overhead?
If there is no problem then why are we discussing this and why do we need
this API extension? :)
> Actually, drm_gem_fd_to_handle() includes to map a
> given dmabuf with iommu table (just logical data) of the DMA. And then, the
> device address (or iova) already mapped will be set to buffer register of
> the DMA with drm_xxx_set_src/dst_dma_buffer(handle1, ...) call.
Consider this with a PIPT cache:
dma_map_sg()- at this point, the kernel addresses of these
buffers are cleaned and invalidated for the DMA
userspace writes to the buffer, the data sits in the CPU cache
Because the cache is PIPT, this data becomes visible to the
kernel as well.
DMA is started, and it writes to the buffer
Now, at this point, which is the correct data? The data physically in the
RAM which the DMA has written, or the data in the CPU cache. It may
the answer is - they both are, and the loss of either can be a potential
data corruption issue - there is no way to tell which data should be
kept but the system is in an inconsistent state and _one_ of them will
have to be discarded.
dma_unmap_sg() - at this point, the kernel addresses of the
buffers are _invalidated_ and any data in those
cache lines is discarded
Which also means that the data in userspace will also be discarded with
PIPT caches.
This is precisely why we have buffer rules associated with the DMA API,
which are these:
dma_map_sg()
- the buffer transfers ownership from the CPU to the DMA agent.
- the CPU may not alter the buffer in any way.
while (cpu_wants_access) {
dma_sync_sg_for_cpu()
- the buffer transfers ownership from the DMA to the CPU.
- the DMA may not alter the buffer in any way.
dma_sync_sg_for_device()
- the buffer transfers ownership from the CPU to the DMA
- the CPU may not alter the buffer in any way.
}
dma_unmap_sg()
- the buffer transfers ownership from the DMA to the CPU.
- the DMA may not alter the buffer in any way.
Any violation of that is likely to lead to data corruption. Now, some
may say that the DMA API is only about the kernel mapping. Yes it is,
because it takes no regard what so ever about what happens with the
userspace mappings. This is absolutely true when you have VIVT or
aliasing VIPT caches.
Now consider that with a PIPT cache, or a non-aliasing VIPT cache (which
is exactly the same behaviourally from this aspect) any modification of
a userspace mapping is precisely the same as modifying the kernel space
mapping - and what you find is that the above rules end up _inherently_
applying to the userspace mappings as well.
In other words, userspace applications which have mapped the buffers
must _also_ respect these rules.
And there's no way in hell that I'd ever trust userspace to get this
anywhere near right, and I *really* do not like these kinds of internal
kernel API rules being exposed to userspace.
And so the idea that userspace should be allowed to setup DMA transfers
via "set source buffer", "set destination buffer" calls into an API is
just plain rediculous. No, userspace should be allowed to ask for
"please copy from buffer X to buffer Y using this transform".
Also remember that drm_xxx_set_src/dst_dma_buffer() would have to
deal with the DRM object IDs for the buffer, and not the actual buffer
information themselves - that is kept within the kernel, so the kernel
knows what's happening.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tegra: Include linux/types.h
On Mon, Jun 17, 2013 at 01:58:14PM +0200, Paul Bolle wrote:
> "make headers_check" complains about include/uapi/drm/tegra_drm.h:
> [...]/usr/include/drm/tegra_drm.h:21: found __[us]{8,16,32,64} type
> without #include
>
> So let's include linux/types.h in this header.
>
> Signed-off-by: Paul Bolle
> ---
> Tested only with "make headers_check". I don't actually build or run
> code that uses tegra_drm.h.
>
> include/uapi/drm/tegra_drm.h | 2 ++
> 1 file changed, 2 insertions(+)
That has already been fixed in linux-next.
Thierry
pgp96HTEnF4wi.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tegra: Include linux/types.h
On Mon, 2013-06-17 at 22:33 +0200, Thierry Reding wrote: > That has already been fixed in linux-next. This header was added in v3.10-rc1. The fix in linux-next will ship in v3.11. Isn't that fix appropriate for (one of) the upcoming v3.10 release candidate(s)? Thanks, Paul Bolle ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65822] [radeonsi] OpenCL is broken
https://bugs.freedesktop.org/show_bug.cgi?id=65822 --- Comment #2 from Aaron Watry --- Created attachment 80967 --> https://bugs.freedesktop.org/attachment.cgi?id=80967&action=edit Test Code from initial post converted to piglit tests I've taken a shot at converting the original tests to piglit tests. I'll test a radeon 7850 in a bit, but I know that Cedar (radeon 5400, so evergreen) also fails each of these tests (and I got a GPU hang running the uint div test after 6-7 times). -- 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/radeon: Disable writeback by default on ppc
On Mon, Jun 17, 2013 at 12:07 PM, Adam Jackson wrote: > On Mon, 2013-06-17 at 11:04 -0400, Alex Deucher wrote: >> On Mon, Jun 17, 2013 at 10:06 AM, Adam Jackson wrote: >> > At least on an IBM Power 720, this check passes, but several piglit >> > tests will reliably trigger GPU resets due to the ring buffer pointers >> > not being updated. There's probably a better way to limit this to just >> > affected machines though. >> >> What radeon chips are you seeing this on? wb is more or less required >> on r6xx and newer and I'm not sure those generations will even work >> properly without writeback enabled these days. We force it to always >> be enabled on APUs and NI and newer asics. With KMS, wb encompasses >> more than just rptr writeback; it covers pretty much everything >> involving the GPU writing any status information to memory. > > FirePro 2270, at least. Booting with no_wb=1, piglit runs to completion > with no GPU resets or IB submission failures. Booting without no_wb, > the following piglits go from pass to fail, all complaining that the > kernel rejected CS: Weird. I wonder if there is an issue with cache snoops on PPC. We currently use the gart in cached mode (GPU snoops CPU cache) with cached pages. I wonder if we need to use uncached pages on PPC. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65822] [radeonsi] OpenCL is broken
https://bugs.freedesktop.org/show_bug.cgi?id=65822 --- Comment #3 from Aaron Watry --- Created attachment 80969 --> https://bugs.freedesktop.org/attachment.cgi?id=80969&action=edit Shader dumps from a radeon 7850 for test cases in attachment 80967 -- 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/nouveau: remove limit on gart
On Mon, Jun 17, 2013 at 11:09 PM, Maarten Lankhorst
wrote:
> Most graphics cards nowadays have a multiple of this limit as their vram, so
> limiting GART doesn't seem to make much sense.
Pushed, thanks :)
>
> Signed-off-by: Maarten >Lnkhorst
> ---
> diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> index 3a5e19a..41ddecd 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
> @@ -168,9 +168,6 @@ nouveau_gart_manager_new(struct ttm_mem_type_manager *man,
> struct nouveau_bo *nvbo = nouveau_bo(bo);
> struct nouveau_mem *node;
>
> - if (unlikely((mem->num_pages << PAGE_SHIFT) >= 512 * 1024 * 1024))
> - return -ENOMEM;
> -
> node = kzalloc(sizeof(*node), GFP_KERNEL);
> if (!node)
> return -ENOMEM;
> @@ -406,8 +403,6 @@ nouveau_ttm_init(struct nouveau_drm *drm)
> /* GART init */
> if (drm->agp.stat != ENABLED) {
> drm->gem.gart_available = nouveau_vmmgr(drm->device)->limit;
> - if (drm->gem.gart_available > 512 * 1024 * 1024)
> - drm->gem.gart_available = 512 * 1024 * 1024;
> } else {
> drm->gem.gart_available = drm->agp.size;
> }
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 65873] New: R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 Priority: medium Bug ID: 65873 Assignee: dri-devel@lists.freedesktop.org Summary: R600/SI: Cannot select store with truncate to 32-bit Severity: normal Classification: Unclassified OS: Linux (All) Reporter: awa...@gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa Created attachment 80970 --> https://bugs.freedesktop.org/attachment.cgi?id=80970&action=edit Piglit test that triggers the error on SI Running the attached piglit CL test, I'm getting the following on R600/SI (Pitcairn, 7850): LLVM ERROR: Cannot select: 0x2add8b0: ch = store 0x2add7b0, 0x2adcfb0, 0x2adc640, 0x2adbd40 [ORD=4] [ID=17] 0x2adcfb0: i64,ch = load 0x20468b8, 0x2add1b0, 0x2adbd40 [ORD=1] [ID=14] 0x2add1b0: i64 = add 0x2adc140, 0x2adc540 [ORD=1] [ID=11] 0x2adc140: i64,ch = load 0x20468b8, 0x2adc040, 0x2adbd40 [ID=9] 0x2adc040: i64 = add 0x2adba40, 0x2adbf40 [ID=7] 0x2adba40: i64,ch = CopyFromReg 0x20468b8, 0x2adb940 [ID=6] 0x2adb940: i64 = Register %vreg0 [ID=1] 0x2adbf40: i64 = Constant<44> [ID=4] 0x2adbd40: i64 = undef [ID=3] 0x2adc540: i64 = Constant<4> [ID=5] 0x2adbd40: i64 = undef [ID=3] 0x2adc640: i64 = add 0x2adbe40, 0x2adc540 [ORD=4] [ID=13] 0x2adbe40: i64,ch = load 0x20468b8, 0x2adbc40, 0x2adbd40 [ID=10] 0x2adbc40: i64 = add 0x2adba40, 0x2adbb40 [ID=8] 0x2adba40: i64,ch = CopyFromReg 0x20468b8, 0x2adb940 [ID=6] 0x2adb940: i64 = Register %vreg0 [ID=1] 0x2adbb40: i64 = Constant<36> [ID=2] 0x2adbd40: i64 = undef [ID=3] 0x2adc540: i64 = Constant<4> [ID=5] 0x2adbd40: i64 = undef [ID=3] I'll attach a dump from llc -debug-only=isel in a minute. -- 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 65873] R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 --- Comment #1 from Aaron Watry --- Created attachment 80971 --> https://bugs.freedesktop.org/attachment.cgi?id=80971&action=edit LLVM assembly that is produced from the vload-int.cl test case -- 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 65873] R600/SI: Cannot select store with truncate to 32-bit
https://bugs.freedesktop.org/show_bug.cgi?id=65873 --- Comment #2 from Aaron Watry --- Created attachment 80972 --> https://bugs.freedesktop.org/attachment.cgi?id=80972&action=edit Output from llc -debug-only=isel --march=r600 --mcpu=verde < vload-int.ll -- 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: [3.10rc6] /proc/dri/0/vma broken on nouveau.
> Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau
> loaded.
> (Note, no X running on that box)
>
> Trace below shows trinity, but I can reproduce it with just cat
> /proc/dri/0/vma
How about this, lets just rip it all out.
Dave.From 54f9605737437272f440bbc6cc4adf805334884b Mon Sep 17 00:00:00 2001
From: Dave Airlie
Date: Tue, 18 Jun 2013 11:38:10 +1000
Subject: [PATCH] drm: remove vma debug code
This lists vma in /proc and is both crash prone and quite possible horribly
racy. Just nuke it I don't think I've used it in years and years.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/drm_debugfs.c | 3 ---
drivers/gpu/drm/drm_info.c| 54 ---
drivers/gpu/drm/drm_proc.c| 3 ---
include/drm/drmP.h| 4
4 files changed, 64 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index a05087c..595c8c1 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -48,9 +48,6 @@ static struct drm_info_list drm_debugfs_list[] = {
{"clients", drm_clients_info, 0},
{"bufs", drm_bufs_info, 0},
{"gem_names", drm_gem_name_info, DRIVER_GEM},
-#if DRM_DEBUG_CODE
- {"vma", drm_vma_info, 0},
-#endif
};
#define DRM_DEBUGFS_ENTRIES ARRAY_SIZE(drm_debugfs_list)
diff --git a/drivers/gpu/drm/drm_info.c b/drivers/gpu/drm/drm_info.c
index d4b20ce..0d25f8d 100644
--- a/drivers/gpu/drm/drm_info.c
+++ b/drivers/gpu/drm/drm_info.c
@@ -222,57 +222,3 @@ int drm_gem_name_info(struct seq_file *m, void *data)
return 0;
}
-#if DRM_DEBUG_CODE
-
-int drm_vma_info(struct seq_file *m, void *data)
-{
- struct drm_info_node *node = (struct drm_info_node *) m->private;
- struct drm_device *dev = node->minor->dev;
- struct drm_vma_entry *pt;
- struct vm_area_struct *vma;
-#if defined(__i386__)
- unsigned int pgprot;
-#endif
-
- mutex_lock(&dev->struct_mutex);
- seq_printf(m, "vma use count: %d, high_memory = %pK, 0x%pK\n",
- atomic_read(&dev->vma_count),
- high_memory, (void *)(unsigned long)virt_to_phys(high_memory));
-
- list_for_each_entry(pt, &dev->vmalist, head) {
- vma = pt->vma;
- if (!vma)
- continue;
- seq_printf(m,
- "\n%5d 0x%pK-0x%pK %c%c%c%c%c%c 0x%08lx000",
- pt->pid,
- (void *)vma->vm_start, (void *)vma->vm_end,
- vma->vm_flags & VM_READ ? 'r' : '-',
- vma->vm_flags & VM_WRITE ? 'w' : '-',
- vma->vm_flags & VM_EXEC ? 'x' : '-',
- vma->vm_flags & VM_MAYSHARE ? 's' : 'p',
- vma->vm_flags & VM_LOCKED ? 'l' : '-',
- vma->vm_flags & VM_IO ? 'i' : '-',
- vma->vm_pgoff);
-
-#if defined(__i386__)
- pgprot = pgprot_val(vma->vm_page_prot);
- seq_printf(m, " %c%c%c%c%c%c%c%c%c",
- pgprot & _PAGE_PRESENT ? 'p' : '-',
- pgprot & _PAGE_RW ? 'w' : 'r',
- pgprot & _PAGE_USER ? 'u' : 's',
- pgprot & _PAGE_PWT ? 't' : 'b',
- pgprot & _PAGE_PCD ? 'u' : 'c',
- pgprot & _PAGE_ACCESSED ? 'a' : '-',
- pgprot & _PAGE_DIRTY ? 'd' : '-',
- pgprot & _PAGE_PSE ? 'm' : 'k',
- pgprot & _PAGE_GLOBAL ? 'g' : 'l');
-#endif
- seq_printf(m, "\n");
- }
- mutex_unlock(&dev->struct_mutex);
- return 0;
-}
-
-#endif
-
diff --git a/drivers/gpu/drm/drm_proc.c b/drivers/gpu/drm/drm_proc.c
index d7f2324..92e9abd 100644
--- a/drivers/gpu/drm/drm_proc.c
+++ b/drivers/gpu/drm/drm_proc.c
@@ -55,9 +55,6 @@ static const struct drm_info_list drm_proc_list[] = {
{"clients", drm_clients_info, 0},
{"bufs", drm_bufs_info, 0},
{"gem_names", drm_gem_name_info, DRIVER_GEM},
-#if DRM_DEBUG_CODE
- {"vma", drm_vma_info, 0},
-#endif
};
#define DRM_PROC_ENTRIES ARRAY_SIZE(drm_proc_list)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 63d17ee..849523d 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1600,10 +1600,6 @@ int drm_prime_add_dma_buf(struct drm_device *dev, struct drm_gem_object *obj);
int drm_prime_lookup_obj(struct drm_device *dev, struct dma_buf *buf,
struct drm_gem_object **obj);
-#if DRM_DEBUG_CODE
-extern int drm_vma_info(struct seq_file *m, void *data);
-#endif
-
/* Scatter Gather Support (drm_scatter.h) */
extern void drm_sg_cleanup(struct drm_sg_mem * entry);
extern int drm_sg_alloc_ioctl(struct drm_device *dev, void *data,
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [3.10rc6] /proc/dri/0/vma broken on nouveau.
On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote: > > > Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau > > loaded. > > (Note, no X running on that box) > > > > Trace below shows trinity, but I can reproduce it with just cat > > /proc/dri/0/vma > > How about this, lets just rip it all out. That's one way to deal with it :) If no programs use it, then yeah, sure, why not. Dave ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-intel tree with the drm tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_fb.c between commit b72447cdf129 ("drm/i915:
Drop bogus fbdev sprite disable code") from the drm tree and commit
b51b32cde175 ("drm/i915: s/drm_i915_private_t/struct drm_i915_private/")
from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_fb.c
index 3b03c3c,244060a..000
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@@ -291,7 -292,9 +292,7 @@@ void intel_fb_output_poll_changed(struc
void intel_fb_restore_mode(struct drm_device *dev)
{
int ret;
- drm_i915_private_t *dev_priv = dev->dev_private;
+ struct drm_i915_private *dev_priv = dev->dev_private;
- struct drm_mode_config *config = &dev->mode_config;
- struct drm_plane *plane;
if (INTEL_INFO(dev)->num_pipes == 0)
return;
pgpRQwC0s0e9y.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] clk/exynos5250: add clocks for hdmi subsystem
Hi Mr. Kukjin, Kindly consider the following patches for review and integration. regards, Rahul Sharma. On Fri, Jun 14, 2013 at 3:39 PM, Arun Kumar K wrote: > Hi, > Tested this series on snow board and is working fine. > > Tested-by: Arun Kumar K > > Regards > Arun > > On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma > wrote: >> Add clock changes for hdmi subsystem for exynos5250 SoC. These >> include addition of new clocks like mout_hdmi and smmu_tv, associating >> ID to clk_hdmiphy and some essential corrections. >> >> This set is based on kukjin's for-next branch at >> http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git. >> >> Arun Kumar K (1): >> clk/exynos5250: Fix HDMI clock number in documentation >> >> Rahul Sharma (4): >> clk/exynos5250: add mout_hdmi mux clock for hdmi >> clk/exynos5250: add sclk_hdmiphy in the list of special clocks >> clk/exynos5250: add clock for tv sysmmu >> clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem >> >> .../devicetree/bindings/clock/exynos5250-clock.txt | 12 +++- >> drivers/clk/samsung/clk-exynos5250.c | 18 >> +- >> 2 files changed, 24 insertions(+), 6 deletions(-) >> >> -- >> 1.7.10.4 >> >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" >> in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
On 06/16/2013 07:57 AM, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. > > So I've decided to instead rip it all out. It seems to work \o/ I wonder how badly this breaks on EFI systems. Currently, efifb is an fbdev driver. When i915 calls register_framebuffer, the fbdev core removes efifb's framebuffer. (This is scary already -- what if i915 has reused that memory for something else beforehand?) But now, if i915 doesn't call register_framebuffer, the efifb "framebuffer" might stick around forever. Presumably, efifb ought to become a framebuffer-only drm driver and there should be a saner way to hand control from efifb (or vesa?) to a real driver. --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
> -Original Message-
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> Sent: Tuesday, June 18, 2013 3:21 AM
> To: Inki Dae
> Cc: Maarten Lankhorst; linux-fbdev; Kyungmin Park; DRI mailing list; Rob
> Clark; myungjoo.ham; YoungJun Cho; Daniel Vetter; linux-arm-
> ker...@lists.infradead.org; linux-me...@vger.kernel.org
> Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization
> framework
>
> On Tue, Jun 18, 2013 at 02:19:04AM +0900, Inki Dae wrote:
> > It seems like that all pages of the scatterlist should be mapped with
> > DMA every time DMA operation is started (or drm_xxx_set_src_dma_buffer
> > function call), and the pages should be unmapped from DMA again every
> > time DMA operation is completed: internally, including each cache
> > operation.
>
> Correct.
>
> > Isn't that big overhead?
>
> Yes, if you _have_ to do a cache operation to ensure that the DMA agent
> can see the data the CPU has written.
>
> > And If there is no problem, we should accept such overhead?
>
> If there is no problem then why are we discussing this and why do we need
> this API extension? :)
Ok, another issue regardless of dmabuf-sync. Reasonable to me even though
big overhead. Besides, it seems like that most DRM drivers have same issue.
Therefore, we may need to solve this issue like below:
- do not map a dmabuf with DMA. And just create/update buffer object
of importer.
- map the buffer with DMA every time DMA start or iommu page fault
occurs.
- unmap the buffer from DMA every time DMA operation is completed
With the above approach, cache operation portion of my approach,
dmabuf-sync, can be removed. However, I'm not sure that we really have to
use the above approach with a big overhead. Of course, if we don't use the
above approach then user processes would need to do each cache operation
before DMA operation is started and also after DMA operation is completed in
some cases; user space mapped with physical memory as cachable, and CPU and
DMA share the same buffer.
So I'd like to ask for other DRM maintainers. How do you think about it? it
seems like that Intel DRM (maintained by Daniel), OMAP DRM (maintained by
Rob) and GEM CMA helper also have same issue Russell pointed out. I think
not only the above approach but also the performance is very important.
Thanks,
Inki Dae
>
> > Actually, drm_gem_fd_to_handle() includes to map a
> > given dmabuf with iommu table (just logical data) of the DMA. And then,
> the
> > device address (or iova) already mapped will be set to buffer register
> of
> > the DMA with drm_xxx_set_src/dst_dma_buffer(handle1, ...) call.
>
> Consider this with a PIPT cache:
>
> dma_map_sg()- at this point, the kernel addresses of these
> buffers are cleaned and invalidated for the DMA
>
> userspace writes to the buffer, the data sits in the CPU cache
> Because the cache is PIPT, this data becomes visible to the
> kernel as well.
>
> DMA is started, and it writes to the buffer
>
> Now, at this point, which is the correct data? The data physically in the
> RAM which the DMA has written, or the data in the CPU cache. It may
> the answer is - they both are, and the loss of either can be a potential
> data corruption issue - there is no way to tell which data should be
> kept but the system is in an inconsistent state and _one_ of them will
> have to be discarded.
>
> dma_unmap_sg() - at this point, the kernel addresses of the
> buffers are _invalidated_ and any data in those
> cache lines is discarded
>
> Which also means that the data in userspace will also be discarded with
> PIPT caches.
>
> This is precisely why we have buffer rules associated with the DMA API,
> which are these:
>
> dma_map_sg()
> - the buffer transfers ownership from the CPU to the DMA agent.
> - the CPU may not alter the buffer in any way.
> while (cpu_wants_access) {
> dma_sync_sg_for_cpu()
> - the buffer transfers ownership from the DMA to the CPU.
> - the DMA may not alter the buffer in any way.
> dma_sync_sg_for_device()
> - the buffer transfers ownership from the CPU to the DMA
> - the CPU may not alter the buffer in any way.
> }
> dma_unmap_sg()
> - the buffer transfers ownership from the DMA to the CPU.
> - the DMA may not alter the buffer in any way.
>
> Any violation of that is likely to lead to data corruption. Now, some
> may say that the DMA API is only about the kernel mapping. Yes it is,
> because it takes no regard what so ever about what happens with the
> userspace mappings. This is absolutely true when you have VIVT or
> aliasing VIPT caches.
>
> Now consider that with a PIPT cache, or a non-aliasing VIPT cache (which
> is exactly the same behaviourally from this aspect) any modification o
Re: [PATCH 0/3] fbdev no more!
Hi On Mon, Jun 17, 2013 at 10:47 PM, Andy Lutomirski wrote: > On 06/16/2013 07:57 AM, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and >> cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon >> resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > I wonder how badly this breaks on EFI systems. Currently, efifb is an > fbdev driver. When i915 calls register_framebuffer, the fbdev core > removes efifb's framebuffer. (This is scary already -- what if i915 has > reused that memory for something else beforehand?) But now, if i915 > doesn't call register_framebuffer, the efifb "framebuffer" might stick > around forever. See the i915 Patch (2/3). It still calls remove_conflicting_framebuffers() if CONFIG_FB is enabled. This will kick out efifb regardless whether i915-fbdev support is enabled or not. > Presumably, efifb ought to become a framebuffer-only drm driver and > there should be a saner way to hand control from efifb (or vesa?) to a > real driver. Already working on it. Regards David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
exynos-drm-next todo work.
Hi all, I'd like to discuss Exynos DRM TODO work. There are features we have to solve and implement. The purpose of this email is to share what we have to do so that other guys can be involved without duplicated work. 1. gscaler based on KMS interfaces - exynos5250 and later use the gscaler device instead of VP device. And now exynos drm driver has gscaler module as a sub module of IPP framework. However, this gscaler module is very specific to IPP framework so it's not easy to reuse this module. So maybe we need so many works for it. Video play back path using post process (AS IS): MFCIPPKMS-FIMD or HDMI Ideal video play back path using post process (TO BE): MFCKMSFIMD or HDMI The above scenario is to send decoded image data (YUV format) to display device via post process. However, we don't really need to use IPP framework in case of using gscaler as VP. All we have to do is to call kms interface (setplane) for it like we did before. 2. More features for HDMI sound support - we need to implement Exynos ALSA SoC DAI driver for HDMI audio (CPU DAI and CODEC DAI). Sampling freq, bit rate, and so on from user side should be sent to drm hdmi driver via ALSA interface and the ALSA SoC DAI driver. As of now, it seems like that we should implement this driver like OMAP does because there is no common framework for interfacing between ALSA SoC DAI driver and DRM HDMI driver: in case of OMAP, it seems like that ALSA SoC audio driver calls interfaces of DSS driver directly. I think we could implement ALSA SoC DAI driver in more generic way if we first implement common framework for it. Welcome to any volunteer and other opinions. Thanks, Inki Dae ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] fbdev no more!
On Mon, Jun 17, 2013 at 4:33 PM, Konrad Rzeszutek Wilk wrote: > On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: >> Hi all, >> >> So I've taken a look again at the locking mess in our fbdev support and >> cried. >> Fixing up the console_lock mess around the fbdev notifier will be real work, >> semanatically the fbdev layer does lots of stupid things (like the radeon >> resume >> issue I've just debugged) and the panic notifier is pretty much a lost cause. >> >> So I've decided to instead rip it all out. It seems to work \o/ > > > When you say 'locking mess in our fbdev support' you mean the general > core fbdev driver? Not neccessarily the i915 driver? > > I am asking b/c that would imply that the other fbdev drivers still hit > the locking mess? Yeah, the recent thing I've stumbled over is how the the fbdev/fbcon locking proliferates console_lock protected sections like mad. Which means that the initial modeset (for fbcon) is all done with the console_lock held. Which makes debugging things in that rather tricky code a mess. So nothing i915-specifc. -Daniel > > Thanks! >> >> Of course a general purpose distro propably wants David's kmscon for any >> fallbacks needs and a system compositor to ditch the VT subsystem - atm my >> machine here runs with the dummy console so that VT switching between >> different >> X sessions still works ;-) >> >> Oh and: At least fedora's boot splash seems to be unhappy about the lack of >> an >> fbdev (it doesn't seem to do anything), which breaks early disk encryption a >> bit. The black screen itself shouldn't be a big issue at least for i915, >> since >> with all the fastboot work we can just hang onto the current config and >> framebuffer (one missing patch from Chris for the fb preservartion). So as >> long >> as the bios/grub put up something nice, it'll look ok. >> >> So just a small step here really, but imo into the right direction. Now, >> please >> bring on the flames! >> >> Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd >> like to wait for a bit of feedback first. And one more: This also removes the >> console_lock completely from our critical path in suspend/resume! >> >> One thing I haven't wasted a single thought about is kgdb and panic notifier >> support. But since the current code is pretty decently broken already (we >> have >> _tons_ of mutex grabbing and waits in there) I don't think people care that >> much >> about it anyway. Using a sprite to smash the kgdb/panic output on top of >> whatever's currently displaying might be an approach. >> >> Cheers, Daniel >> >> Daniel Vetter (3): >> drm: Add separate Kconfig option for fbdev helpers >> drm/i915: Kconfig option to disable the legacy fbdev support >> drm/i915: rename intel_fb.c to intel_fbdev.c >> >> drivers/gpu/drm/Kconfig | 57 ++- >> drivers/gpu/drm/Makefile | 3 +- >> drivers/gpu/drm/ast/Kconfig | 1 + >> drivers/gpu/drm/cirrus/Kconfig | 1 + >> drivers/gpu/drm/exynos/Kconfig | 1 + >> drivers/gpu/drm/gma500/Kconfig | 1 + >> drivers/gpu/drm/i915/Kconfig | 56 +++ >> drivers/gpu/drm/i915/Makefile| 3 +- >> drivers/gpu/drm/i915/i915_debugfs.c | 4 +- >> drivers/gpu/drm/i915/i915_dma.c | 8 +- >> drivers/gpu/drm/i915/i915_drv.h | 2 + >> drivers/gpu/drm/i915/intel_display.c | 12 +- >> drivers/gpu/drm/i915/intel_drv.h | 39 - >> drivers/gpu/drm/i915/intel_fb.c | 314 >> --- >> drivers/gpu/drm/i915/intel_fbdev.c | 314 >> +++ >> drivers/gpu/drm/mgag200/Kconfig | 1 + >> drivers/gpu/drm/nouveau/Kconfig | 1 + >> drivers/gpu/drm/omapdrm/Kconfig | 1 + >> drivers/gpu/drm/qxl/Kconfig | 1 + >> drivers/gpu/drm/shmobile/Kconfig | 1 + >> drivers/gpu/drm/tilcdc/Kconfig | 1 + >> drivers/gpu/drm/udl/Kconfig | 1 + >> drivers/gpu/host1x/drm/Kconfig | 1 + >> drivers/staging/imx-drm/Kconfig | 1 + >> 24 files changed, 452 insertions(+), 373 deletions(-) >> create mode 100644 drivers/gpu/drm/i915/Kconfig >> delete mode 100644 drivers/gpu/drm/i915/intel_fb.c >> create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c >> >> -- >> 1.7.11.7 >> >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] fbdev no more!
Hi On Sun, Jun 16, 2013 at 4:57 PM, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. Hint: Take a look at fbdev ref-counting or sysfs integration. Totally broken, too. I sometimes really wonder how that still works. > So I've decided to instead rip it all out. It seems to work \o/ Yep, works for me pretty well, too. > Of course a general purpose distro propably wants David's kmscon for any > fallbacks needs and a system compositor to ditch the VT subsystem - atm my > machine here runs with the dummy console so that VT switching between > different > X sessions still works ;-) I used CONFIG_VT=n for quite a while with user-space VTs as replacement. But what we really need is a system-compositor (even if it's not really a "compositor"). But for that we need dynamic modeset nodes or we end up with the same problems as with VTs. It's on my TODO list after render/modeset nodes are done. With user-space VTs this is even backwards-compatible. > Oh and: At least fedora's boot splash seems to be unhappy about the lack of an > fbdev (it doesn't seem to do anything), which breaks early disk encryption a > bit. The black screen itself shouldn't be a big issue at least for i915, since > with all the fastboot work we can just hang onto the current config and > framebuffer (one missing patch from Chris for the fb preservartion). So as > long > as the bios/grub put up something nice, it'll look ok. Plymouth should work just fine with KMS (afaik it was even airlied who wrote the backends). It doesn't support GPU hotplugging, though. So it's probably started before i915 is loaded and so doesn't pick up the DRM device. Or with initrd user-space is started early without waiting for device-initialization to finish. So even with i915 built-in it may run before card0 shows up. The journal-log should probably help debugging this. Btw., It has /dev/dri/card0 hard-coded and only tries opening it once during startup. > So just a small step here really, but imo into the right direction. Now, > please > bring on the flames! Please, apply it! Now! Thanks David > Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd > like to wait for a bit of feedback first. And one more: This also removes the > console_lock completely from our critical path in suspend/resume! > > One thing I haven't wasted a single thought about is kgdb and panic notifier > support. But since the current code is pretty decently broken already (we have > _tons_ of mutex grabbing and waits in there) I don't think people care that > much > about it anyway. Using a sprite to smash the kgdb/panic output on top of > whatever's currently displaying might be an approach. > > Cheers, Daniel > > Daniel Vetter (3): > drm: Add separate Kconfig option for fbdev helpers > drm/i915: Kconfig option to disable the legacy fbdev support > drm/i915: rename intel_fb.c to intel_fbdev.c > > drivers/gpu/drm/Kconfig | 57 ++- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig | 1 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/i915/Kconfig | 56 +++ > drivers/gpu/drm/i915/Makefile| 3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +- > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 12 +- > drivers/gpu/drm/i915/intel_drv.h | 39 - > drivers/gpu/drm/i915/intel_fb.c | 314 > --- > drivers/gpu/drm/i915/intel_fbdev.c | 314 > +++ > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig | 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig | 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 24 files changed, 452 insertions(+), 373 deletions(-) > create mode 100644 drivers/gpu/drm/i915/Kconfig > delete mode 100644 drivers/gpu/drm/i915/intel_fb.c > create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c > > -- > 1.7.11.7 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.
https://bugs.freedesktop.org/show_bug.cgi?id=64913 --- Comment #9 from Krzysztof A. Sobiecki --- Compile mesa, make it usable in a system, run piglit, apply the patch, compile mesa,run KSP to check out if it fixes the problem, run piglit again and report regressions. That should be good enough. I hope. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/ab2d4928/attachment.html>
[PATCH 1/3] drm: add mmap function to prime helpers
On 06/15/2013 02:16 AM, Aaron Plattner wrote:
> On 06/12/2013 06:16 AM, Joonyoung Shim wrote:
>> This adds to call low-level mmap() from prime helpers.
>>
>> Signed-off-by: Joonyoung Shim
>> ---
>> drivers/gpu/drm/drm_prime.c | 5 -
>> include/drm/drmP.h | 2 ++
>> 2 files changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
>> index d92853e..3a008b2 100644
>> --- a/drivers/gpu/drm/drm_prime.c
>> +++ b/drivers/gpu/drm/drm_prime.c
>> @@ -165,7 +165,10 @@ static void drm_gem_dmabuf_kunmap(struct dma_buf
>> *dma_buf,
>> static int drm_gem_dmabuf_mmap(struct dma_buf *dma_buf,
>> struct vm_area_struct *vma)
>> {
>> -return -EINVAL;
>> +struct drm_gem_object *obj = dma_buf->priv;
>> +struct drm_device *dev = obj->dev;
>> +
>> +return dev->driver->gem_prime_mmap(obj, vma);
>
> Won't this crash if the driver doesn't fill in the new field and
> userspace tries to map it?
>
Right, if gem_prime_mmap field is NULL, should return error.
Thanks for comments.
[PATCH 1/9] drm/exynos: use SoC name to identify hdmi version
Thanks Seung-Woo,
On Fri, Jun 14, 2013 at 12:23 PM, ??? wrote:
> Hello Rahul,
>
> On 2013? 06? 11? 23:11, Rahul Sharma wrote:
>> Exynos hdmi IP version is named after hdmi specification version i.e.
>> 1.3 and 1.4. This versioning mechanism is not sufficient to handle
>> the diversity in the hdmi/phy IPs which are present across the exynos
>> SoC family.
>>
>> This patch changes the hdmi version to the name of the SoC in which
>> the IP was introduced for the first time. Same version is applicable
>> to all subsequent SoCs having the same IP version.
>>
>> Exynos4210 has 1.3 HDMI, i2c mapped phy with configuration set.
>> Exynos5250 has 1.4 HDMI, i2c mapped phy with configuration set.
>> Exynos5420 has 1.4 HDMI, Platform Bus mapped phy with configuration set.
>>
>> Based on the HDMI IP version we cannot decide to pick Exynos5250 phy conf
>> and use i2c for data transfer or Exynos5420 phy confs and platform bus
>> calls for communication.
>
> Considering your other patch to divide hdmi and hdmiphy, how do you
> think using hdmiphy version parsed from hdmiphy dt binding from phy code
> instead of using hdmi version for both hdmi and hdmiphy? If that, this
> SoC identifying hdmi version is not necessary because there is no change
> at least in hdmi side.
>
> And IMO, it seems easy to merge hdmiphy related patch first before
> merging patch for exynos5420.
>
You are right. If we isolate hdmiphy first from hdmi IP driver, we
dont need this
patch. I will revive the hdmiphy separation patch and get that merge first.
regards,
Rahul Sharma.
>>
>> Signed-off-by: Rahul Sharma
>> ---
>> drivers/gpu/drm/exynos/exynos_hdmi.c | 249
>> +-
>> drivers/gpu/drm/exynos/regs-hdmi.h | 78 +--
>> 2 files changed, 164 insertions(+), 163 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index 75a6bf3..9384ffc 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -73,9 +73,9 @@ enum HDMI_PACKET_TYPE {
>> HDMI_PACKET_TYPE_AUI = HDMI_PACKET_TYPE_INFOFRAME + 4
>> };
>>
>> -enum hdmi_type {
>> - HDMI_TYPE13,
>> - HDMI_TYPE14,
>> +enum hdmi_version {
>> + HDMI_VER_EXYNOS4210,
>> + HDMI_VER_EXYNOS4212,
>> };
>
>
>
> --
> Seung-Woo Kim
> Samsung Software R&D Center
> --
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
> in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug 57381] Radeon HD6950: Resuming from hibernation fails sometimes
https://bugzilla.kernel.org/show_bug.cgi?id=57381 Lan Tianyu changed: What|Removed |Added Component|Hibernation/Suspend |Video(DRI - non Intel) AssignedTo|tianyu.lan at intel.com|drivers_video-dri at kernel-bu ||gs.osdl.org Product|Power Management|Drivers --- Comment #18 from Lan Tianyu 2013-06-17 02:14:18 --- Thanks for test. I think you have done a very good job. (In reply to comment #16) > Ok, the following statements deactivate async for the graphics card (+ its > HDMI > audio): > echo disabled > > "/sys/devices/pci:00/:00:01.0/:01:00.0/power/async" > echo disabled > > "/sys/devices/pci:00/:00:01.0/:01:00.1/power/async" > > This seems to have a similar effect as "echo 0 > /sys/power/pm_async". > This shows the issue is still related with Graphics driver. Disable pm_async is just to make all the driver suspend callback to be executed serially. So reassign this bug to Graphic category. > With this, I ran a series of 30 hibernate/resume cycles. The 7th and the 29th > attempts failed (the last one failed twice), with the usual symptoms. So it > seems that disabling async for the graphics card indeed only alleviates the > problem. I will perform the same tests with pm_async deactivated just to be > sure. -- 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 7/9] drm/exynos: use of_get_named_gpio to get hdmi hpd gpio
Applied.
Thanks,
Inki Dae
2013/6/14 ???
> Hello Rahul,
>
> this patch is not related with others and it looks good to me.
>
> On 2013? 06? 11? 23:11, Rahul Sharma wrote:
> > Cleanup by removing flags variable from drm_hdmi_dt_parse_pdata
> > which is not used anywhere. Swtiching to of_get_named_gpio instead
> > of of_get_named_gpio_flags solved this.
> >
> > Signed-off-by: Rahul Sharma
>
> Acked-by: Seung-Woo Kim
>
> > ---
> > drivers/gpu/drm/exynos/exynos_hdmi.c |3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> > index 1eb5ffb..fc6a9b0 100644
> > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> > @@ -2081,7 +2081,6 @@ static struct s5p_hdmi_platform_data
> *drm_hdmi_dt_parse_pdata
> > {
> > struct device_node *np = dev->of_node;
> > struct s5p_hdmi_platform_data *pd;
> > - enum of_gpio_flags flags;
> > u32 value;
> >
> > pd = devm_kzalloc(dev, sizeof(*pd), GFP_KERNEL);
> > @@ -2095,7 +2094,7 @@ static struct s5p_hdmi_platform_data
> *drm_hdmi_dt_parse_pdata
> > goto err_data;
> > }
> >
> > - pd->hpd_gpio = of_get_named_gpio_flags(np, "hpd-gpio", 0, &flags);
> > + pd->hpd_gpio = of_get_named_gpio(np, "hpd-gpio", 0);
> >
> > return pd;
> >
> >
>
> --
> Seung-Woo Kim
> Samsung Software R&D Center
> --
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-samsung-soc" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/dabe6557/attachment-0001.html>
linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_display.c between commit d62cf62ad07d
("drm/i915: Quirk the pipe A quirk in the modeset state checker") from
Linus' tree and commit 6c49f24180c3 ("drm/i915: hw state readout support
for pixel_multiplier") from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_display.c
index 6eb99e1,218bc93..000
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -8177,11 -8264,14 +8264,19 @@@ check_crtc_state(struct drm_device *dev
active = dev_priv->display.get_pipe_config(crtc,
&pipe_config);
+
+ /* hw state is inconsistent with the pipe A quirk */
+ if (crtc->pipe == PIPE_A && dev_priv->quirks &
QUIRK_PIPEA_FORCE)
+ active = crtc->active;
+
+ list_for_each_entry(encoder, &dev->mode_config.encoder_list,
+ base.head) {
+ if (encoder->base.crtc != &crtc->base)
+ continue;
+ if (encoder->get_config)
+ encoder->get_config(encoder, &pipe_config);
+ }
+
WARN(crtc->active != active,
"crtc active state doesn't match with hw state "
"(expected %i, found %i)\n", crtc->active, active);
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/c3be2264/attachment.pgp>
linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_sdvo.c between commit 7ba220cec0bb ("drm/i915:
Enable hotplug interrupts after querying hw capabilities") from Linus'
tree and commit e596a02ccfc6 ("drm/i915: Remove dead code from SDVO
initialisation") from the drm-intel tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwellsfr at canb.auug.org.au
diff --cc drivers/gpu/drm/i915/intel_sdvo.c
index 7d31165,b8e1623..000
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@@ -2850,18 -2889,12 +2891,6 @@@ bool intel_sdvo_init(struct drm_device
}
}
- hotplug_mask = 0;
- if (IS_G4X(dev)) {
- hotplug_mask = intel_sdvo->is_sdvob ?
- SDVOB_HOTPLUG_INT_STATUS_G4X :
SDVOC_HOTPLUG_INT_STATUS_G4X;
- } else if (IS_GEN4(dev)) {
- hotplug_mask = intel_sdvo->is_sdvob ?
- SDVOB_HOTPLUG_INT_STATUS_I965 :
SDVOC_HOTPLUG_INT_STATUS_I965;
- } else {
- hotplug_mask = intel_sdvo->is_sdvob ?
- SDVOB_HOTPLUG_INT_STATUS_I915 :
SDVOC_HOTPLUG_INT_STATUS_I915;
- }
-
- /* Only enable the hotplug irq if we need it, to work around noisy
- * hotplug lines.
- */
- if (intel_sdvo->hotplug_active)
- intel_encoder->hpd_pin = HPD_SDVO_B ? HPD_SDVO_B : HPD_SDVO_C;
-
intel_encoder->compute_config = intel_sdvo_compute_config;
intel_encoder->disable = intel_disable_sdvo;
intel_encoder->mode_set = intel_sdvo_mode_set;
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/18a635f4/attachment.pgp>
WARNING: at drivers/gpu/drm/nouveau/core/core/mm.c:242
On 03/13/2013 11:36 AM, Jiri Slaby wrote:
> On 02/19/2013 11:32 PM, Marcin Slusarz wrote:
>> On Tue, Feb 19, 2013 at 08:07:44AM +0100, Marcin Slusarz wrote:
>>> On Tue, Feb 19, 2013 at 12:43:06AM +0100, Jiri Slaby wrote:
On 02/19/2013 12:23 AM, Marcin Slusarz wrote:
> Tomorrow I'll post a patch for page allocation failure.
What do you mean -- what kind of patch?
>>>
>>> A patch which will change pgt allocation to use vmalloc.
>
> It's still not in -next. Any plans on this?
Ping...
>> ---
>> From: Marcin Slusarz
>> Subject: [PATCH] drm/nouveau: use vmalloc for pgt allocation
>>
>> Page tables on nv50 take 48kB, which can be hard to allocate in one piece.
>> Let's use vmalloc.
>>
>> Signed-off-by: Marcin Slusarz
>> Cc: stable at vger.kernel.org
>> ---
>> drivers/gpu/drm/nouveau/core/subdev/vm/base.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
>> b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
>> index 77c67fc..e66fb77 100644
>> --- a/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
>> +++ b/drivers/gpu/drm/nouveau/core/subdev/vm/base.c
>> @@ -362,7 +362,7 @@ nouveau_vm_create(struct nouveau_vmmgr *vmm, u64 offset,
>> u64 length,
>> vm->fpde = offset >> (vmm->pgt_bits + 12);
>> vm->lpde = (offset + length - 1) >> (vmm->pgt_bits + 12);
>>
>> -vm->pgt = kcalloc(vm->lpde - vm->fpde + 1, sizeof(*vm->pgt),
>> GFP_KERNEL);
>> +vm->pgt = vzalloc((vm->lpde - vm->fpde + 1) * sizeof(*vm->pgt));
>> if (!vm->pgt) {
>> kfree(vm);
>> return -ENOMEM;
>> @@ -371,7 +371,7 @@ nouveau_vm_create(struct nouveau_vmmgr *vmm, u64 offset,
>> u64 length,
>> ret = nouveau_mm_init(&vm->mm, mm_offset >> 12, mm_length >> 12,
>>block >> 12);
>> if (ret) {
>> -kfree(vm->pgt);
>> +vfree(vm->pgt);
>> kfree(vm);
>> return ret;
>> }
>> @@ -446,7 +446,7 @@ nouveau_vm_del(struct nouveau_vm *vm)
>> }
>>
>> nouveau_mm_fini(&vm->mm);
>> -kfree(vm->pgt);
>> +vfree(vm->pgt);
>> kfree(vm);
>> }
>>
>>
>
>
--
js
suse labs
[Bug 65810] Small black box at the left top corner after playing some 3d games...
https://bugs.freedesktop.org/show_bug.cgi?id=65810 --- Comment #1 from Michel D?nzer --- It looks like there's a drop shadow around the box, so it could just be a window left behind by the games or something. What does xwininfo say when you click on the box? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/aedc978c/attachment.html>
[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.
https://bugs.freedesktop.org/show_bug.cgi?id=64913 --- Comment #10 from Knut Andre Tidemann --- I've tested the attached patch, and it fixes the crash in kerbal space program. I've also run the piglit r600.tests before and after patching, but it seems the results are somewhat mixed. I ran piglit once before patching and a few times afterwards and the results differed each time I ran the tests. One time the test even zombied. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/4308b490/attachment.html>
[PATCH] drm/mgag200: Hardware cursor support
On Thu, Jun 13, 2013 at 3:17 AM, Christopher Harvey wrote: > On Wed, Jun 05 2013, Christopher Harvey wrote: >> G200 cards support, at best, 16 colour palleted images for the cursor >> so we do a conversion in the cursor_set function, and reject cursors >> with more than 16 colours, or cursors with partial transparency. Xorg >> falls back gracefully to software cursors in this case. >> >> We can't disable/enable the cursor hardware without causing momentary >> corruption around the cursor. Instead, once the cursor is on we leave >> it on, and simulate turning the cursor off by moving it >> offscreen. This works well. >> >> Since we can't disable -> update -> enable the cursors, we double >> buffer cursor icons, then just move the base address that points to >> the old cursor, to the new. This also works well, but uses an extra >> page of memory. >> >> The cursor buffers are lazily-allocated on first cursor_set. This is >> to make sure they don't take priority over any framebuffers in case of >> limited memory. >> >> Here is a representation of how the bitmap for the cursor is mapped in G200 >> memory : >> >> Each line of color cursor use 6 Slices of 8 bytes. Slices 0 to 3 >> are used for the 4bpp bitmap, slice 4 for XOR mask and slice 5 for >> AND mask. Each line has the following format: >> >> // Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 >> // >> // S0: P00-01 P02-03 P04-05 P06-07 P08-09 P10-11 P12-13 P14-15 >> // S1: P16-17 P18-19 P20-21 P22-23 P24-25 P26-27 P28-29 P30-31 >> // S2: P32-33 P34-35 P36-37 P38-39 P40-41 P42-43 P44-45 P46-47 >> // S3: P48-49 P50-51 P52-53 P54-55 P56-57 P58-59 P60-61 P62-63 >> // S4: X63-56 X55-48 X47-40 X39-32 X31-24 X23-16 X15-08 X07-00 >> // S5: A63-56 A55-48 A47-40 A39-32 A31-24 A23-16 A15-08 A07-00 >> // >> // S0 to S5 = Slices 0 to 5 >> // P00 to P63= Bitmap - pixels 0 to 63 >> // X00 to X63= always 0 - pixels 0 to 63 >> // A00 to A63= transparent markers - pixels 0 to 63 >> // 1 means colour, 0 means transparent >> >> Signed-off-by: Christopher Harvey >> Signed-off-by: Mathieu Larouche >> Acked-by: Julia Lemire >> Tested-by: Julia Lemire > > ping. I've applied this to drm-next, Dave.
[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.
https://bugs.freedesktop.org/show_bug.cgi?id=64913 --- Comment #11 from Krzysztof A. Sobiecki --- Does this behavior also occurred before patching? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/d9276e98/attachment.html>
[Bug 65810] Small black box at the left top corner after playing some 3d games...
https://bugs.freedesktop.org/show_bug.cgi?id=65810 Andreas Boll changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/2b4b5225/attachment.html>
[Bug 64913] [r600g] KSP 0.20 crashes when entering settings / starting new game.
https://bugs.freedesktop.org/show_bug.cgi?id=64913 --- Comment #12 from Knut Andre Tidemann --- Yeah, I ran the piglit tests multiple times again without the patch applied, and the same result can be observed. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/0fa7d16c/attachment.html>
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
This patch adds a buffer synchronization framework based on DMA BUF[1] and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] for lock mechanism. The purpose of this framework is not only to couple cache operations, and buffer access control to CPU and DMA but also to provide easy-to-use interfaces for device drivers and potentially user application (not implemented for user applications, yet). And this framework can be used for all dma devices using system memory as dma buffer, especially for most ARM based SoCs. Changelog v2: - use atomic_add_unless to avoid potential bug. - add a macro for checking valid access type. - code clean. The mechanism of this framework has the following steps, 1. Register dmabufs to a sync object - A task gets a new sync object and can add one or more dmabufs that the task wants to access. This registering should be performed when a device context or an event context such as a page flip event is created or before CPU accesses a shared buffer. dma_buf_sync_get(a sync object, a dmabuf); 2. Lock a sync object - A task tries to lock all dmabufs added in its own sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead lock issue and for race condition between CPU and CPU, CPU and DMA, and DMA and DMA. Taking a lock means that others cannot access all locked dmabufs until the task that locked the corresponding dmabufs, unlocks all the locked dmabufs. This locking should be performed before DMA or CPU accesses these dmabufs. dma_buf_sync_lock(a sync object); 3. Unlock a sync object - The task unlocks all dmabufs added in its own sync object. The unlock means that the DMA or CPU accesses to the dmabufs have been completed so that others may access them. This unlocking should be performed after DMA or CPU has completed accesses to the dmabufs. dma_buf_sync_unlock(a sync object); 4. Unregister one or all dmabufs from a sync object - A task unregisters the given dmabufs from the sync object. This means that the task dosen't want to lock the dmabufs. The unregistering should be performed after DMA or CPU has completed accesses to the dmabufs or when dma_buf_sync_lock() is failed. dma_buf_sync_put(a sync object, a dmabuf); dma_buf_sync_put_all(a sync object); The described steps may be summarized as: get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put This framework includes the following two features. 1. read (shared) and write (exclusive) locks - A task is required to declare the access type when the task tries to register a dmabuf; READ, WRITE, READ DMA, or WRITE DMA. The below is example codes, struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, "test sync"); dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... And the below can be used as access types: DMA_BUF_ACCESS_READ, - CPU will access a buffer for read. DMA_BUF_ACCESS_WRITE, - CPU will access a buffer for read or write. DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, - DMA will access a buffer for read or write. 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. A task may never try to unlock a buffer after taking a lock to the buffer. In this case, a timer handler to the corresponding sync object is called in five (default) seconds and then the timed-out buffer is unlocked by work queue handler to avoid lockups and to enforce resources of the buffer. The below is how to use: 1. Allocate and Initialize a sync object: struct dmabuf_sync *sync; sync = dmabuf_sync_init(NULL, "test sync"); ... 2. Add a dmabuf to the sync object when setting up dma buffer relevant registers: dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); ... 3. Lock all dmabufs of the sync object before DMA or CPU accesses the dmabufs: dmabuf_sync_lock(sync); ... 4. Now CPU or DMA can access all dmabufs locked in step 3. 5. Unlock all dmabufs added in a sync object after DMA or CPU access to these dmabufs is completed: dmabuf_sync_unlock(sync); And call the following functions to release all resources, dmabuf_sync_put_all(sync); dmabuf_sync_fini(sync); You can refer to actual example codes: https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/ commit/?h=dmabuf-sync&id=4030bdee9bab5841ad32faade528d04cc0c5fc94 https://git.kernel.org/cgit/linux/
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
Op 17-06-13 13:15, Inki Dae schreef: > This patch adds a buffer synchronization framework based on DMA BUF[1] > and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] > for lock mechanism. > > The purpose of this framework is not only to couple cache operations, > and buffer access control to CPU and DMA but also to provide easy-to-use > interfaces for device drivers and potentially user application > (not implemented for user applications, yet). And this framework can be > used for all dma devices using system memory as dma buffer, especially > for most ARM based SoCs. > > Changelog v2: > - use atomic_add_unless to avoid potential bug. > - add a macro for checking valid access type. > - code clean. > > The mechanism of this framework has the following steps, > 1. Register dmabufs to a sync object - A task gets a new sync object and > can add one or more dmabufs that the task wants to access. > This registering should be performed when a device context or an event > context such as a page flip event is created or before CPU accesses a > shared > buffer. > > dma_buf_sync_get(a sync object, a dmabuf); > > 2. Lock a sync object - A task tries to lock all dmabufs added in its own > sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid dead > lock issue and for race condition between CPU and CPU, CPU and DMA, and > DMA > and DMA. Taking a lock means that others cannot access all locked dmabufs > until the task that locked the corresponding dmabufs, unlocks all the > locked > dmabufs. > This locking should be performed before DMA or CPU accesses these dmabufs. > > dma_buf_sync_lock(a sync object); > > 3. Unlock a sync object - The task unlocks all dmabufs added in its own > sync > object. The unlock means that the DMA or CPU accesses to the dmabufs have > been completed so that others may access them. > This unlocking should be performed after DMA or CPU has completed accesses > to the dmabufs. > > dma_buf_sync_unlock(a sync object); > > 4. Unregister one or all dmabufs from a sync object - A task unregisters > the given dmabufs from the sync object. This means that the task dosen't > want to lock the dmabufs. > The unregistering should be performed after DMA or CPU has completed > accesses to the dmabufs or when dma_buf_sync_lock() is failed. > > dma_buf_sync_put(a sync object, a dmabuf); > dma_buf_sync_put_all(a sync object); > > The described steps may be summarized as: > get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put > > This framework includes the following two features. > 1. read (shared) and write (exclusive) locks - A task is required to > declare > the access type when the task tries to register a dmabuf; > READ, WRITE, READ DMA, or WRITE DMA. > > The below is example codes, > struct dmabuf_sync *sync; > > sync = dmabuf_sync_init(NULL, "test sync"); > > dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); > ... > > And the below can be used as access types: > DMA_BUF_ACCESS_READ, > - CPU will access a buffer for read. > DMA_BUF_ACCESS_WRITE, > - CPU will access a buffer for read or write. > DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, > - DMA will access a buffer for read > DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, > - DMA will access a buffer for read or write. > > 2. Mandatory resource releasing - a task cannot hold a lock indefinitely. > A task may never try to unlock a buffer after taking a lock to the buffer. > In this case, a timer handler to the corresponding sync object is called > in five (default) seconds and then the timed-out buffer is unlocked by > work > queue handler to avoid lockups and to enforce resources of the buffer. > > The below is how to use: > 1. Allocate and Initialize a sync object: > struct dmabuf_sync *sync; > > sync = dmabuf_sync_init(NULL, "test sync"); > ... > > 2. Add a dmabuf to the sync object when setting up dma buffer relevant > registers: > dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); > ... > > 3. Lock all dmabufs of the sync object before DMA or CPU accesses > the dmabufs: > dmabuf_sync_lock(sync); > ... > > 4. Now CPU or DMA can access all dmabufs locked in step 3. > > 5. Unlock all dmabufs added in a sync object after DMA or CPU access > to these dmabufs is completed: > dmabuf_sync_unlock(sync); > > And call the following functions to release all resources, > dmabuf_sync_put_all(sync); > dmabuf_sync_fini(sync); > > You can refer to actual example codes: > > https://git.kernel.org/cgi
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #65 from Marc Dietrich --- regarding crash in comment 57, there seems to be something wrong with cosine: https://www.khronos.org/registry/webgl/conformance-suites/1.0.2/conformance/glsl/functions/glsl-function-cos.html reproduces the crash. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/1d578f97/attachment.html>
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #66 from Marc Dietrich --- crash happens with firefox only, chrome reports test failed. both browser pass the test with R600_LLVM=0 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/7c157ba0/attachment.html>
[PATCH] drm/tegra: Include linux/types.h
"make headers_check" complains about include/uapi/drm/tegra_drm.h:
[...]/usr/include/drm/tegra_drm.h:21: found __[us]{8,16,32,64} type without
#include
So let's include linux/types.h in this header.
Signed-off-by: Paul Bolle
---
Tested only with "make headers_check". I don't actually build or run
code that uses tegra_drm.h.
include/uapi/drm/tegra_drm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index 6e132a2..6698e81 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -17,6 +17,8 @@
#ifndef _UAPI_TEGRA_DRM_H_
#define _UAPI_TEGRA_DRM_H_
+#include
+
struct drm_tegra_gem_create {
__u64 size;
__u32 flags;
--
1.8.1.4
[Bug 59761] Kernel fails to reset AMD HD5770 GPU properly and encounters OOPS. GPU reset fails - system remains in unusable state.
https://bugzilla.kernel.org/show_bug.cgi?id=59761 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher 2013-06-17 12:56:22 --- Can you bisect mesa and find out what commit caused the breakage? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
> -Original Message- > From: Maarten Lankhorst [mailto:maarten.lankhorst at canonical.com] > Sent: Monday, June 17, 2013 8:35 PM > To: Inki Dae > Cc: dri-devel at lists.freedesktop.org; linux-fbdev at vger.kernel.org; linux- > arm-kernel at lists.infradead.org; linux-media at vger.kernel.org; > daniel at ffwll.ch; robdclark at gmail.com; kyungmin.park at samsung.com; > myungjoo.ham at samsung.com; yj44.cho at samsung.com > Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization > framework > > Op 17-06-13 13:15, Inki Dae schreef: > > This patch adds a buffer synchronization framework based on DMA BUF[1] > > and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] > > for lock mechanism. > > > > The purpose of this framework is not only to couple cache operations, > > and buffer access control to CPU and DMA but also to provide easy-to-use > > interfaces for device drivers and potentially user application > > (not implemented for user applications, yet). And this framework can be > > used for all dma devices using system memory as dma buffer, especially > > for most ARM based SoCs. > > > > Changelog v2: > > - use atomic_add_unless to avoid potential bug. > > - add a macro for checking valid access type. > > - code clean. > > > > The mechanism of this framework has the following steps, > > 1. Register dmabufs to a sync object - A task gets a new sync object > and > > can add one or more dmabufs that the task wants to access. > > This registering should be performed when a device context or an > event > > context such as a page flip event is created or before CPU accesses a > shared > > buffer. > > > > dma_buf_sync_get(a sync object, a dmabuf); > > > > 2. Lock a sync object - A task tries to lock all dmabufs added in its > own > > sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid > dead > > lock issue and for race condition between CPU and CPU, CPU and DMA, > and DMA > > and DMA. Taking a lock means that others cannot access all locked > dmabufs > > until the task that locked the corresponding dmabufs, unlocks all the > locked > > dmabufs. > > This locking should be performed before DMA or CPU accesses these > dmabufs. > > > > dma_buf_sync_lock(a sync object); > > > > 3. Unlock a sync object - The task unlocks all dmabufs added in its > own sync > > object. The unlock means that the DMA or CPU accesses to the dmabufs > have > > been completed so that others may access them. > > This unlocking should be performed after DMA or CPU has completed > accesses > > to the dmabufs. > > > > dma_buf_sync_unlock(a sync object); > > > > 4. Unregister one or all dmabufs from a sync object - A task > unregisters > > the given dmabufs from the sync object. This means that the task > dosen't > > want to lock the dmabufs. > > The unregistering should be performed after DMA or CPU has completed > > accesses to the dmabufs or when dma_buf_sync_lock() is failed. > > > > dma_buf_sync_put(a sync object, a dmabuf); > > dma_buf_sync_put_all(a sync object); > > > > The described steps may be summarized as: > > get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put > > > > This framework includes the following two features. > > 1. read (shared) and write (exclusive) locks - A task is required to > declare > > the access type when the task tries to register a dmabuf; > > READ, WRITE, READ DMA, or WRITE DMA. > > > > The below is example codes, > > struct dmabuf_sync *sync; > > > > sync = dmabuf_sync_init(NULL, "test sync"); > > > > dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); > > ... > > > > And the below can be used as access types: > > DMA_BUF_ACCESS_READ, > > - CPU will access a buffer for read. > > DMA_BUF_ACCESS_WRITE, > > - CPU will access a buffer for read or write. > > DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, > > - DMA will access a buffer for read > > DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, > > - DMA will access a buffer for read or write. > > > > 2. Mandatory resource releasing - a task cannot hold a lock > indefinitely. > > A task may never try to unlock a buffer after taking a lock to the > buffer. > > In this case, a timer handler to the corresponding sync object is > called > > in five (default) seconds and then the timed-out buffer is unlocked > by work > > queue handler to avoid lockups and to enforce resources of the buffer. > > > > The below is how to use: > > 1. Allocate and Initialize a sync object: > > struct dmabuf_sync *sync; > > > > sync = dmabuf_sync_init(NULL, "test sync"); > > ... > > > > 2. Add a dmabuf to the sync object when setting up dma buffer > relevant > >registers: > > dmabuf_sync_get(sync, dmabu
[PATCH] drm/nouveau: remove limit on gart
Most graphics cards nowadays have a multiple of this limit as their vram, so
limiting GART doesn't seem to make much sense.
Signed-off-by: Maarten >Lnkhorst
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 3a5e19a..41ddecd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -168,9 +168,6 @@ nouveau_gart_manager_new(struct ttm_mem_type_manager *man,
struct nouveau_bo *nvbo = nouveau_bo(bo);
struct nouveau_mem *node;
- if (unlikely((mem->num_pages << PAGE_SHIFT) >= 512 * 1024 * 1024))
- return -ENOMEM;
-
node = kzalloc(sizeof(*node), GFP_KERNEL);
if (!node)
return -ENOMEM;
@@ -406,8 +403,6 @@ nouveau_ttm_init(struct nouveau_drm *drm)
/* GART init */
if (drm->agp.stat != ENABLED) {
drm->gem.gart_available = nouveau_vmmgr(drm->device)->limit;
- if (drm->gem.gart_available > 512 * 1024 * 1024)
- drm->gem.gart_available = 512 * 1024 * 1024;
} else {
drm->gem.gart_available = drm->agp.size;
}
[PATCH 0/1] drm/mgag200: Added resolution and bandwidth limits for various G200e products.
At the larger resolutions, the g200e series sometimes struggles with maintaining a proper output. Problems like flickering or black bands appearing on screen can occur. In order to avoid this, limitations regarding resolutions and bandwidth have been added for the different variations of the g200e series. Julia Lemire (1): drm/mgag200: Added resolution and bandwidth limits for various G200e products. drivers/gpu/drm/mgag200/mgag200_drv.h |3 +- drivers/gpu/drm/mgag200/mgag200_main.c |2 +- drivers/gpu/drm/mgag200/mgag200_mode.c | 55 ++-- 3 files changed, 56 insertions(+), 4 deletions(-) -- 1.7.10.4
[PATCH 1/1] drm/mgag200: Added resolution and bandwidth limits for various G200e products.
This code was ported from the old xorg mga driver. These limits were
implemented as a solution to a number of problems that were seen. These
problems were linked to the bandwidth limitations of the g200e series.
Signed-off-by: Julia Lemire
---
drivers/gpu/drm/mgag200/mgag200_drv.h |3 +-
drivers/gpu/drm/mgag200/mgag200_main.c |2 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 55 ++--
3 files changed, 56 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index bf29b2f..988911a 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -198,7 +198,8 @@ struct mga_device {
struct ttm_bo_device bdev;
} ttm;
- u32 reg_1e24; /* SE model number */
+ /* SE model number stored in reg 0x1e24 */
+ u32 unique_rev_id;
};
diff --git a/drivers/gpu/drm/mgag200/mgag200_main.c
b/drivers/gpu/drm/mgag200/mgag200_main.c
index 9905923..dafe049 100644
--- a/drivers/gpu/drm/mgag200/mgag200_main.c
+++ b/drivers/gpu/drm/mgag200/mgag200_main.c
@@ -176,7 +176,7 @@ static int mgag200_device_init(struct drm_device *dev,
/* stash G200 SE model number for later use */
if (IS_G200_SE(mdev))
- mdev->reg_1e24 = RREG32(0x1e24);
+ mdev->unique_rev_id = RREG32(0x1e24);
ret = mga_vram_init(mdev);
if (ret)
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index ee66bad..3cdebe6 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -1008,7 +1008,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
if (IS_G200_SE(mdev)) {
- if (mdev->reg_1e24 >= 0x02) {
+ if (mdev->unique_rev_id >= 0x02) {
u8 hi_pri_lvl;
u32 bpp;
u32 mb;
@@ -1038,7 +1038,7 @@ static int mga_crtc_mode_set(struct drm_crtc *crtc,
WREG8(MGAREG_CRTCEXT_DATA, hi_pri_lvl);
} else {
WREG8(MGAREG_CRTCEXT_INDEX, 0x06);
- if (mdev->reg_1e24 >= 0x01)
+ if (mdev->unique_rev_id >= 0x01)
WREG8(MGAREG_CRTCEXT_DATA, 0x03);
else
WREG8(MGAREG_CRTCEXT_DATA, 0x04);
@@ -1410,6 +1410,24 @@ static int mga_vga_get_modes(struct drm_connector
*connector)
return ret;
}
+static uint32_t mga_vga_calculate_mode_bandwidth(struct drm_display_mode *
mode,
+ int bits_per_pixel)
+{
+ uint64_t active_area, total_area, pixels_per_second;
+ uint64_t bytes_per_pixel = (bits_per_pixel + 7) / 8;
+
+ if(!mode->htotal || !mode->vtotal || !mode->clock)
+ return 0;
+
+ active_area = mode->hdisplay * mode->vdisplay;
+ total_area = mode->htotal * mode->vtotal;
+ pixels_per_second = active_area * mode->clock * 1000 / total_area;
+
+ return (uint32_t)(pixels_per_second * bytes_per_pixel * 100 / (1024));
+}
+
+#define MODE_BANDWIDTH MODE_BAD
+
static int mga_vga_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
@@ -1422,6 +1440,39 @@ static int mga_vga_mode_valid(struct drm_connector
*connector,
int i = 0;
/* FIXME: Add bandwidth and g200se limitations */
+ if (IS_G200_SE(mdev)) {
+ if (mdev->unique_rev_id == 0x01) {
+ if (mode->hdisplay > 1600)
+ return MODE_VIRTUAL_X;
+ if (mode->vdisplay > 1200)
+ return MODE_VIRTUAL_Y;
+ if (mga_vga_calculate_mode_bandwidth(mode, bpp) >
(24400 * 1024))
+ return MODE_BANDWIDTH;
+ } else if (mdev->unique_rev_id >= 0x02) {
+ if (mode->hdisplay > 1920)
+ return MODE_VIRTUAL_X;
+ if (mode->vdisplay > 1200)
+ return MODE_VIRTUAL_Y;
+ if (mga_vga_calculate_mode_bandwidth(mode, bpp) >
(30100 * 1024))
+ return MODE_BANDWIDTH;
+ }
+ } else if (mdev->type == G200_WB) {
+ if (mode->hdisplay > 1280)
+ return MODE_VIRTUAL_X;
+ if (mode->vdisplay > 1024)
+ return MODE_VIRTUAL_Y;
+ if (mga_vga_calculate_mode_bandwidth(mode, bpp > (31877 *
1024)))
+ return MODE_BANDWIDTH;
+ } else if (mdev->type == G200_EV &&
+ (mga_vga_calculate_mode_bandwidth(mode, bpp) > (32700 * 1024)))
{
+ return MODE_BANDWIDTH;
+ } else if (mode->type == G200_EH &&
+
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
Op 17-06-13 15:04, Inki Dae schreef: > >> -Original Message- >> From: Maarten Lankhorst [mailto:maarten.lankhorst at canonical.com] >> Sent: Monday, June 17, 2013 8:35 PM >> To: Inki Dae >> Cc: dri-devel at lists.freedesktop.org; linux-fbdev at vger.kernel.org; >> linux- >> arm-kernel at lists.infradead.org; linux-media at vger.kernel.org; >> daniel at ffwll.ch; robdclark at gmail.com; kyungmin.park at samsung.com; >> myungjoo.ham at samsung.com; yj44.cho at samsung.com >> Subject: Re: [RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization >> framework >> >> Op 17-06-13 13:15, Inki Dae schreef: >>> This patch adds a buffer synchronization framework based on DMA BUF[1] >>> and reservation[2] to use dma-buf resource, and based on ww-mutexes[3] >>> for lock mechanism. >>> >>> The purpose of this framework is not only to couple cache operations, >>> and buffer access control to CPU and DMA but also to provide easy-to-use >>> interfaces for device drivers and potentially user application >>> (not implemented for user applications, yet). And this framework can be >>> used for all dma devices using system memory as dma buffer, especially >>> for most ARM based SoCs. >>> >>> Changelog v2: >>> - use atomic_add_unless to avoid potential bug. >>> - add a macro for checking valid access type. >>> - code clean. >>> >>> The mechanism of this framework has the following steps, >>> 1. Register dmabufs to a sync object - A task gets a new sync object >> and >>> can add one or more dmabufs that the task wants to access. >>> This registering should be performed when a device context or an >> event >>> context such as a page flip event is created or before CPU accesses > a >> shared >>> buffer. >>> >>> dma_buf_sync_get(a sync object, a dmabuf); >>> >>> 2. Lock a sync object - A task tries to lock all dmabufs added in > its >> own >>> sync object. Basically, the lock mechanism uses ww-mutex[1] to avoid >> dead >>> lock issue and for race condition between CPU and CPU, CPU and DMA, >> and DMA >>> and DMA. Taking a lock means that others cannot access all locked >> dmabufs >>> until the task that locked the corresponding dmabufs, unlocks all > the >> locked >>> dmabufs. >>> This locking should be performed before DMA or CPU accesses these >> dmabufs. >>> dma_buf_sync_lock(a sync object); >>> >>> 3. Unlock a sync object - The task unlocks all dmabufs added in its >> own sync >>> object. The unlock means that the DMA or CPU accesses to the dmabufs >> have >>> been completed so that others may access them. >>> This unlocking should be performed after DMA or CPU has completed >> accesses >>> to the dmabufs. >>> >>> dma_buf_sync_unlock(a sync object); >>> >>> 4. Unregister one or all dmabufs from a sync object - A task >> unregisters >>> the given dmabufs from the sync object. This means that the task >> dosen't >>> want to lock the dmabufs. >>> The unregistering should be performed after DMA or CPU has completed >>> accesses to the dmabufs or when dma_buf_sync_lock() is failed. >>> >>> dma_buf_sync_put(a sync object, a dmabuf); >>> dma_buf_sync_put_all(a sync object); >>> >>> The described steps may be summarized as: >>> get -> lock -> CPU or DMA access to a buffer/s -> unlock -> put >>> >>> This framework includes the following two features. >>> 1. read (shared) and write (exclusive) locks - A task is required to >> declare >>> the access type when the task tries to register a dmabuf; >>> READ, WRITE, READ DMA, or WRITE DMA. >>> >>> The below is example codes, >>> struct dmabuf_sync *sync; >>> >>> sync = dmabuf_sync_init(NULL, "test sync"); >>> >>> dmabuf_sync_get(sync, dmabuf, DMA_BUF_ACCESS_READ); >>> ... >>> >>> And the below can be used as access types: >>> DMA_BUF_ACCESS_READ, >>> - CPU will access a buffer for read. >>> DMA_BUF_ACCESS_WRITE, >>> - CPU will access a buffer for read or write. >>> DMA_BUF_ACCESS_READ | DMA_BUF_ACCESS_DMA, >>> - DMA will access a buffer for read >>> DMA_BUF_ACCESS_WRITE | DMA_BUF_ACCESS_DMA, >>> - DMA will access a buffer for read or write. >>> >>> 2. Mandatory resource releasing - a task cannot hold a lock >> indefinitely. >>> A task may never try to unlock a buffer after taking a lock to the >> buffer. >>> In this case, a timer handler to the corresponding sync object is >> called >>> in five (default) seconds and then the timed-out buffer is unlocked >> by work >>> queue handler to avoid lockups and to enforce resources of the > buffer. >>> The below is how to use: >>> 1. Allocate and Initialize a sync object: >>> struct dmabuf_sync *sync; >>> >>> sync = dmabuf_sync_init(NULL, "test sync"); >>> ... >>> >>> 2. Add a dmabuf to the sync object when setting up dma buffer >> re
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Mon, Jun 17, 2013 at 10:04:45PM +0900, Inki Dae wrote: > It's just to implement a thin sync framework coupling cache operation. This > approach is based on dma-buf for more generic implementation against android > sync driver or KDS. > > The described steps may be summarized as: > lock -> cache operation -> CPU or DMA access to a buffer/s -> unlock > > I think that there is no need to get complicated for such approach at least > for most devices sharing system memory. Simple is best. But hang on, doesn't the dmabuf API already provide that? The dmabuf API already uses dma_map_sg() and dma_unmap_sg() by providers, and the rules around the DMA API are that: dma_map_sg() /* DMA _ONLY_ has access, CPU should not access */ dma_unmap_sg() /* DMA may not access, CPU can access */ It's a little more than that if you include the sync_sg_for_cpu and sync_sg_for_device APIs too - but the above is the general idea. What this means from the dmabuf API point of view is that once you attach to a dma_buf, and call dma_buf_map_attachment() to get the SG list, the CPU doesn't have ownership of the buffer and _must_ _not_ access it via any other means - including using the other dma_buf methods, until either the appropriate dma_sync_sg_for_cpu() call has been made or the DMA mapping has been removed via dma_buf_unmap_attachment(). So, the sequence should be: dma_buf_map_attachment() /* do DMA */ dma_buf_unmap_attachment() /* CPU can now access the buffer */
[PATCH] drm/radeon: Disable writeback by default on ppc
At least on an IBM Power 720, this check passes, but several piglit
tests will reliably trigger GPU resets due to the ring buffer pointers
not being updated. There's probably a better way to limit this to just
affected machines though.
Signed-off-by: Adam Jackson
---
drivers/gpu/drm/radeon/r600_cp.c | 7 +++
drivers/gpu/drm/radeon/radeon_cp.c | 7 +++
drivers/gpu/drm/radeon/radeon_device.c | 4 ++--
drivers/gpu/drm/radeon/radeon_drv.c| 2 +-
4 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cp.c b/drivers/gpu/drm/radeon/r600_cp.c
index 1c51c08..ef28532 100644
--- a/drivers/gpu/drm/radeon/r600_cp.c
+++ b/drivers/gpu/drm/radeon/r600_cp.c
@@ -552,6 +552,13 @@ static void r600_test_writeback(drm_radeon_private_t
*dev_priv)
dev_priv->writeback_works = 0;
DRM_INFO("writeback test failed\n");
}
+#if defined(__ppc__) || defined(__ppc64__)
+ /* the test might succeed on ppc, but it's usually not reliable */
+ if (radeon_no_wb == -1) {
+ radeon_no_wb = 1;
+ DRM_INFO("not trusting writeback test due to arch quirk\n");
+ }
+#endif
if (radeon_no_wb == 1) {
dev_priv->writeback_works = 0;
DRM_INFO("writeback forced off\n");
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon/radeon_cp.c
index efc4f64..a967b33 100644
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -892,6 +892,13 @@ static void radeon_test_writeback(drm_radeon_private_t *
dev_priv)
dev_priv->writeback_works = 0;
DRM_INFO("writeback test failed\n");
}
+#if defined(__ppc__) || defined(__ppc64__)
+ /* the test might succeed on ppc, but it's usually not reliable */
+ if (radeon_no_wb == -1) {
+ radeon_no_wb = 1;
+ DRM_INFO("not trusting writeback test due to arch quirk\n");
+ }
+#endif
if (radeon_no_wb == 1) {
dev_priv->writeback_works = 0;
DRM_INFO("writeback forced off\n");
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 1899738..524046e 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -322,8 +322,8 @@ int radeon_wb_init(struct radeon_device *rdev)
/* disable event_write fences */
rdev->wb.use_event = false;
/* disabled via module param */
- if (radeon_no_wb == 1) {
- rdev->wb.enabled = false;
+ if (radeon_no_wb != -1) {
+ rdev->wb.enabled = !!radeon_no_wb;
} else {
if (rdev->flags & RADEON_IS_AGP) {
/* often unreliable on AGP */
diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
b/drivers/gpu/drm/radeon/radeon_drv.c
index 094e7e5..04809d4 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.c
+++ b/drivers/gpu/drm/radeon/radeon_drv.c
@@ -146,7 +146,7 @@ static inline void radeon_register_atpx_handler(void) {}
static inline void radeon_unregister_atpx_handler(void) {}
#endif
-int radeon_no_wb;
+int radeon_no_wb = -1;
int radeon_modeset = -1;
int radeon_dynclks = -1;
int radeon_r4xx_atom = 0;
--
1.8.2.1
[PATCH 0/3] fbdev no more!
On Sun, Jun 16, 2013 at 04:57:17PM +0200, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. > > So I've decided to instead rip it all out. It seems to work \o/ When you say 'locking mess in our fbdev support' you mean the general core fbdev driver? Not neccessarily the i915 driver? I am asking b/c that would imply that the other fbdev drivers still hit the locking mess? Thanks! > > Of course a general purpose distro propably wants David's kmscon for any > fallbacks needs and a system compositor to ditch the VT subsystem - atm my > machine here runs with the dummy console so that VT switching between > different > X sessions still works ;-) > > Oh and: At least fedora's boot splash seems to be unhappy about the lack of an > fbdev (it doesn't seem to do anything), which breaks early disk encryption a > bit. The black screen itself shouldn't be a big issue at least for i915, since > with all the fastboot work we can just hang onto the current config and > framebuffer (one missing patch from Chris for the fb preservartion). So as > long > as the bios/grub put up something nice, it'll look ok. > > So just a small step here really, but imo into the right direction. Now, > please > bring on the flames! > > Aside: We can hide the #ifdef mess a bit better in drm/i915 I think, but I'd > like to wait for a bit of feedback first. And one more: This also removes the > console_lock completely from our critical path in suspend/resume! > > One thing I haven't wasted a single thought about is kgdb and panic notifier > support. But since the current code is pretty decently broken already (we have > _tons_ of mutex grabbing and waits in there) I don't think people care that > much > about it anyway. Using a sprite to smash the kgdb/panic output on top of > whatever's currently displaying might be an approach. > > Cheers, Daniel > > Daniel Vetter (3): > drm: Add separate Kconfig option for fbdev helpers > drm/i915: Kconfig option to disable the legacy fbdev support > drm/i915: rename intel_fb.c to intel_fbdev.c > > drivers/gpu/drm/Kconfig | 57 ++- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/ast/Kconfig | 1 + > drivers/gpu/drm/cirrus/Kconfig | 1 + > drivers/gpu/drm/exynos/Kconfig | 1 + > drivers/gpu/drm/gma500/Kconfig | 1 + > drivers/gpu/drm/i915/Kconfig | 56 +++ > drivers/gpu/drm/i915/Makefile| 3 +- > drivers/gpu/drm/i915/i915_debugfs.c | 4 +- > drivers/gpu/drm/i915/i915_dma.c | 8 +- > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/intel_display.c | 12 +- > drivers/gpu/drm/i915/intel_drv.h | 39 - > drivers/gpu/drm/i915/intel_fb.c | 314 > --- > drivers/gpu/drm/i915/intel_fbdev.c | 314 > +++ > drivers/gpu/drm/mgag200/Kconfig | 1 + > drivers/gpu/drm/nouveau/Kconfig | 1 + > drivers/gpu/drm/omapdrm/Kconfig | 1 + > drivers/gpu/drm/qxl/Kconfig | 1 + > drivers/gpu/drm/shmobile/Kconfig | 1 + > drivers/gpu/drm/tilcdc/Kconfig | 1 + > drivers/gpu/drm/udl/Kconfig | 1 + > drivers/gpu/host1x/drm/Kconfig | 1 + > drivers/staging/imx-drm/Kconfig | 1 + > 24 files changed, 452 insertions(+), 373 deletions(-) > create mode 100644 drivers/gpu/drm/i915/Kconfig > delete mode 100644 drivers/gpu/drm/i915/intel_fb.c > create mode 100644 drivers/gpu/drm/i915/intel_fbdev.c > > -- > 1.7.11.7 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64257] RS880 issues with r600-llvm-compiler
https://bugs.freedesktop.org/show_bug.cgi?id=64257 --- Comment #67 from Marc Dietrich --- ok, maybe cos, sin, tan, are all broken because of bug 50317. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/85ca878f/attachment.html>
[PATCH] drm/radeon: Disable writeback by default on ppc
On Mon, Jun 17, 2013 at 10:06 AM, Adam Jackson wrote:
> At least on an IBM Power 720, this check passes, but several piglit
> tests will reliably trigger GPU resets due to the ring buffer pointers
> not being updated. There's probably a better way to limit this to just
> affected machines though.
What radeon chips are you seeing this on? wb is more or less required
on r6xx and newer and I'm not sure those generations will even work
properly without writeback enabled these days. We force it to always
be enabled on APUs and NI and newer asics. With KMS, wb encompasses
more than just rptr writeback; it covers pretty much everything
involving the GPU writing any status information to memory.
Alex
>
> Signed-off-by: Adam Jackson
> ---
> drivers/gpu/drm/radeon/r600_cp.c | 7 +++
> drivers/gpu/drm/radeon/radeon_cp.c | 7 +++
> drivers/gpu/drm/radeon/radeon_device.c | 4 ++--
> drivers/gpu/drm/radeon/radeon_drv.c| 2 +-
> 4 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r600_cp.c
> b/drivers/gpu/drm/radeon/r600_cp.c
> index 1c51c08..ef28532 100644
> --- a/drivers/gpu/drm/radeon/r600_cp.c
> +++ b/drivers/gpu/drm/radeon/r600_cp.c
> @@ -552,6 +552,13 @@ static void r600_test_writeback(drm_radeon_private_t
> *dev_priv)
> dev_priv->writeback_works = 0;
> DRM_INFO("writeback test failed\n");
> }
> +#if defined(__ppc__) || defined(__ppc64__)
> + /* the test might succeed on ppc, but it's usually not reliable */
> + if (radeon_no_wb == -1) {
> + radeon_no_wb = 1;
> + DRM_INFO("not trusting writeback test due to arch quirk\n");
> + }
> +#endif
> if (radeon_no_wb == 1) {
> dev_priv->writeback_works = 0;
> DRM_INFO("writeback forced off\n");
> diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
> b/drivers/gpu/drm/radeon/radeon_cp.c
> index efc4f64..a967b33 100644
> --- a/drivers/gpu/drm/radeon/radeon_cp.c
> +++ b/drivers/gpu/drm/radeon/radeon_cp.c
> @@ -892,6 +892,13 @@ static void radeon_test_writeback(drm_radeon_private_t *
> dev_priv)
> dev_priv->writeback_works = 0;
> DRM_INFO("writeback test failed\n");
> }
> +#if defined(__ppc__) || defined(__ppc64__)
> + /* the test might succeed on ppc, but it's usually not reliable */
> + if (radeon_no_wb == -1) {
> + radeon_no_wb = 1;
> + DRM_INFO("not trusting writeback test due to arch quirk\n");
> + }
> +#endif
> if (radeon_no_wb == 1) {
> dev_priv->writeback_works = 0;
> DRM_INFO("writeback forced off\n");
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 1899738..524046e 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -322,8 +322,8 @@ int radeon_wb_init(struct radeon_device *rdev)
> /* disable event_write fences */
> rdev->wb.use_event = false;
> /* disabled via module param */
> - if (radeon_no_wb == 1) {
> - rdev->wb.enabled = false;
> + if (radeon_no_wb != -1) {
> + rdev->wb.enabled = !!radeon_no_wb;
> } else {
> if (rdev->flags & RADEON_IS_AGP) {
> /* often unreliable on AGP */
> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
> b/drivers/gpu/drm/radeon/radeon_drv.c
> index 094e7e5..04809d4 100644
> --- a/drivers/gpu/drm/radeon/radeon_drv.c
> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
> @@ -146,7 +146,7 @@ static inline void radeon_register_atpx_handler(void) {}
> static inline void radeon_unregister_atpx_handler(void) {}
> #endif
>
> -int radeon_no_wb;
> +int radeon_no_wb = -1;
> int radeon_modeset = -1;
> int radeon_dynclks = -1;
> int radeon_r4xx_atom = 0;
> --
> 1.8.2.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: Disable writeback by default on ppc
On Mon, 2013-06-17 at 11:04 -0400, Alex Deucher wrote: > On Mon, Jun 17, 2013 at 10:06 AM, Adam Jackson wrote: > > At least on an IBM Power 720, this check passes, but several piglit > > tests will reliably trigger GPU resets due to the ring buffer pointers > > not being updated. There's probably a better way to limit this to just > > affected machines though. > > What radeon chips are you seeing this on? wb is more or less required > on r6xx and newer and I'm not sure those generations will even work > properly without writeback enabled these days. We force it to always > be enabled on APUs and NI and newer asics. With KMS, wb encompasses > more than just rptr writeback; it covers pretty much everything > involving the GPU writing any status information to memory. FirePro 2270, at least. Booting with no_wb=1, piglit runs to completion with no GPU resets or IB submission failures. Booting without no_wb, the following piglits go from pass to fail, all complaining that the kernel rejected CS: no-wb wb (info)(info) All7598/9587 7403/9553 glean 362/385 361/385 pointAtten pass fail texture_srgb pass fail shaders477/533 441/533 glsl-algebraic-add-add-1 pass fail glsl-algebraic-add-add-2 pass fail glsl-algebraic-add-add-3 pass fail glsl-algebraic-sub-zero-3 pass fail glsl-algebraic-sub-zero-4 pass fail glsl-complex-subscript pass fail glsl-copy-propagation-if-1 pass fail glsl-copy-propagation-if-2 pass fail glsl-copy-propagation-if-3 pass fail glsl-copy-propagation-vector-indexing pass fail glsl-fs-atan-2 pass fail glsl-fs-dot-vec2-2 pass fail glsl-fs-log2 pass fail glsl-fs-main-returnpass fail glsl-fs-max-3 pass fail glsl-fs-min-2 pass fail glsl-fs-min-3 pass fail glsl-fs-statevar-call pass fail glsl-fs-struct-equal pass fail glsl-function-chain16 pass fail glsl-implicit-conversion-02pass fail glsl-inout-struct-01 pass fail glsl-inout-struct-02 pass fail glsl-link-varying-TexCoord pass fail glsl-link-varyings-2 pass fail glsl-uniform-initializer-4 pass fail glsl-uniform-initializer-6 pass fail glsl-uniform-initializer-7 pass fail glsl-vs-abs-neg-with-intermediate pass fail glsl-vs-clamp-1pass fail glsl-vs-deadcode-1 pass fail glsl-vs-deadcode-2 pass fail glsl-vs-f2bpass fail glsl-vs-position-outvalpass fail link-uniform-array-sizepass fail loopfunc pass fail spec 5921/7801 5763/7767 !OpenGL 1.1118/229 101/219 depthstencil-default_fb-clear pass fail getteximage-simple pass fail texwrap formats27/50 12/40 GL_LUMINANCE12 pass fail GL_LUMINANCE16 pass fail GL_LUMINANCE4 pass fail GL_LUMINANCE4_ALPHA4 pass fail GL_LUMINANCE8
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> 2013/6/17 Russell King - ARM Linux
> Exactly right. But that is not definitely my point. Could you please see
> the below simple example?:
> (Presume that CPU and DMA share a buffer and the buffer is mapped with user
> space as cachable)
>
> handle1 = drm_gem_fd_to_handle(a dmabuf fd); > 1
> ...
> va1 = drm_gem_mmap(handle1);
> va2 = drm_gem_mmap(handle2);
> va3 = malloc(size);
> ...
>
> while (conditions) {
> memcpy(va1, some data, size);
No!
Well, the first thing to say here is that under the requirements of the
DMA API, the above is immediately invalid, because you're writing to a
buffer which under the terms of the DMA API is currently owned by the
DMA agent, *not* by the CPU. You're supposed to call dma_sync_sg_for_cpu()
before you do that - but how is userspace supposed to know that requirement?
Why should userspace even _have_ to know these requirements of the DMA
API?
It's also entirely possible that drm_gem_fd_to_handle() (which indirectly
causes dma_map_sg() on the buffers scatterlist) followed by mmap'ing it
into userspace is a bug too, as it has the potential to touch caches or
stuff in ways that maybe the DMA or IOMMU may not expect - but I'm not
going to make too big a deal about that, because I don't think we have
anything that picky.
However, the first point above is the most important one, and exposing
the quirks of the DMA API to userland is certainly not a nice thing to be
doing. This needs to be fixed - we can't go and enforce an API which is
deeply embedded within the kernel all the way out to userland.
What we need is something along the lines of:
(a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
or
(b) drm_gem_prime_import() not to call dma_buf_map_attachment() at all.
and for the scatterlist to be mapped for DMA at the point where the DMA
operation is initiated, and unmapped at the point where the DMA operation
is complete.
So no, the problem is not that we need more APIs and code - we need the
existing kernel API fixed so that we don't go exposing userspace to the
requirements of the DMA API. Unless we do that, we're going to end
up with a huge world of pain, where kernel architecture people need to
audit every damned DRM userspace implementation that happens to be run
on their platform, and that's not something arch people really can
afford to do.
Basically, I think the dma_buf stuff needs to be rewritten with the
requirements of the DMA API in the forefront of whosever mind is doing
the rewriting.
Note: the existing stuff does have the nice side effect of being able
to pass buffers which do not have a struct page * associated with them
through the dma_buf API - I think we can still preserve that by having
dma_buf provide a couple of new APIs to do the SG list map/sync/unmap,
but in any case we need to fix the existing API so that:
dma_buf_map_attachment() becomes dma_buf_get_sg()
dma_buf_unmap_attachment() becomes dma_buf_put_sg()
both getting rid of the DMA direction argument, and then we have four
new dma_buf calls:
dma_buf_map_sg()
dma_buf_unmap_sg()
dma_buf_sync_sg_for_cpu()
dma_buf_sync_sg_for_device()
which do the actual sg map/unmap via the DMA API *at the appropriate
time for DMA*.
So, the summary of this is - at the moment, I regard DRM Prime and dmabuf
to be utterly broken in design for architectures such as ARM where the
requirements of the DMA API have to be followed if you're going to have
a happy life.
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Mon, Jun 17, 2013 at 04:42:37PM +0100, Russell King - ARM Linux wrote:
> On Tue, Jun 18, 2013 at 12:03:31AM +0900, Inki Dae wrote:
> > 2013/6/17 Russell King - ARM Linux
> > Exactly right. But that is not definitely my point. Could you please see
> > the below simple example?:
> > (Presume that CPU and DMA share a buffer and the buffer is mapped with user
> > space as cachable)
> >
> > handle1 = drm_gem_fd_to_handle(a dmabuf fd); > 1
> > ...
> > va1 = drm_gem_mmap(handle1);
> > va2 = drm_gem_mmap(handle2);
> > va3 = malloc(size);
> > ...
> >
> > while (conditions) {
> > memcpy(va1, some data, size);
>
> No!
>
> Well, the first thing to say here is that under the requirements of the
> DMA API, the above is immediately invalid, because you're writing to a
> buffer which under the terms of the DMA API is currently owned by the
> DMA agent, *not* by the CPU. You're supposed to call dma_sync_sg_for_cpu()
> before you do that - but how is userspace supposed to know that requirement?
> Why should userspace even _have_ to know these requirements of the DMA
> API?
>
> It's also entirely possible that drm_gem_fd_to_handle() (which indirectly
> causes dma_map_sg() on the buffers scatterlist) followed by mmap'ing it
> into userspace is a bug too, as it has the potential to touch caches or
> stuff in ways that maybe the DMA or IOMMU may not expect - but I'm not
> going to make too big a deal about that, because I don't think we have
> anything that picky.
>
> However, the first point above is the most important one, and exposing
> the quirks of the DMA API to userland is certainly not a nice thing to be
> doing. This needs to be fixed - we can't go and enforce an API which is
> deeply embedded within the kernel all the way out to userland.
>
> What we need is something along the lines of:
> (a) dma_buf_map_attachment() _not_ to map the scatterlist for DMA.
> or
> (b) drm_gem_prime_import() not to call dma_buf_map_attachment() at all.
>
> and for the scatterlist to be mapped for DMA at the point where the DMA
> operation is initiated, and unmapped at the point where the DMA operation
> is complete.
>
> So no, the problem is not that we need more APIs and code - we need the
> existing kernel API fixed so that we don't go exposing userspace to the
> requirements of the DMA API. Unless we do that, we're going to end
> up with a huge world of pain, where kernel architecture people need to
> audit every damned DRM userspace implementation that happens to be run
> on their platform, and that's not something arch people really can
> afford to do.
>
> Basically, I think the dma_buf stuff needs to be rewritten with the
> requirements of the DMA API in the forefront of whosever mind is doing
> the rewriting.
>
> Note: the existing stuff does have the nice side effect of being able
> to pass buffers which do not have a struct page * associated with them
> through the dma_buf API - I think we can still preserve that by having
> dma_buf provide a couple of new APIs to do the SG list map/sync/unmap,
> but in any case we need to fix the existing API so that:
>
> dma_buf_map_attachment() becomes dma_buf_get_sg()
> dma_buf_unmap_attachment() becomes dma_buf_put_sg()
>
> both getting rid of the DMA direction argument, and then we have four
> new dma_buf calls:
>
> dma_buf_map_sg()
> dma_buf_unmap_sg()
> dma_buf_sync_sg_for_cpu()
> dma_buf_sync_sg_for_device()
>
> which do the actual sg map/unmap via the DMA API *at the appropriate
> time for DMA*.
>
> So, the summary of this is - at the moment, I regard DRM Prime and dmabuf
> to be utterly broken in design for architectures such as ARM where the
> requirements of the DMA API have to be followed if you're going to have
> a happy life.
An addendum to the above:
I'll also point out that the whole thing of having random buffers mapped
into userspace, and doing DMA on them is _highly_ architecture specific.
I'm told that PARISC is one architecture where this does not work (because
DMA needs to have some kind of congruence factor programmed into it which
can be different between kernel and userspace mappings of the same
physical mappings.
I ran into this when trying to come up with a cross-arch DMA-API mmap API,
and PARISC ended up killing the idea off (the remains of that attempt is
the dma_mmap_* stuff in ARM's asm/dma-mapping.h.) However, this was for
the DMA coherent stuff, not the streaming API, which is what _this_
DMA prime/dma_buf stuff is about.
What I'm saying is think _very_ _carefully_ about userspace having
interleaved access to random DMA buffers. Arguably, DRM should _not_
allow this.
[Bug 65822] [radeonsi] OpenCL is broken
https://bugs.freedesktop.org/show_bug.cgi?id=65822 --- Comment #1 from Tom Stellard --- I will take a look at this when I get a chance. In the mean time it would be great if you could convert these into piglit tests. Here is a good example: http://cgit.freedesktop.org/piglit/tree/tests/cl/program/execute/sha256-Ch.cl Probably one file for each test would be good. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/51c571b3/attachment.html>
[PATCH v3, part2 14/20] PCI, DRM: use hotplug-safe iterators to walk PCI buses
On Sun, May 26, 2013 at 11:53:11PM +0800, Jiang Liu wrote:
> Enhance DRM drvier to use hotplug-safe iterators to walk PCI buses.
>
> Signed-off-by: Jiang Liu
> Cc: David Airlie
> Cc: dri-devel at lists.freedesktop.org
> Cc: linux-kernel at vger.kernel.org
> ---
> drivers/gpu/drm/drm_fops.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
> index 429e07d..dc8c40b 100644
> --- a/drivers/gpu/drm/drm_fops.c
> +++ b/drivers/gpu/drm/drm_fops.c
> @@ -359,9 +359,11 @@ static int drm_open_helper(struct inode *inode, struct
> file *filp,
> pci_dev_put(pci_dev);
> }
> if (!dev->hose) {
> - struct pci_bus *b = pci_bus_b(pci_root_buses.next);
> - if (b)
> + struct pci_bus *b = pci_get_next_root_bus(NULL);
> + if (b) {
> dev->hose = b->sysdata;
> + pci_bus_put(b);
> + }
This is a gross hack to begin with, and it would be far better to get
rid of the whole "#ifdef __alpha__" block that contains this code.
I can't believe alpha is so special that it needs to do something
that no other arch needs.
> }
> }
> #endif
> --
> 1.8.1.2
>
[RFC PATCH v2] dmabuf-sync: Introduce buffer synchronization framework
On Tue, Jun 18, 2013 at 02:19:04AM +0900, Inki Dae wrote:
> It seems like that all pages of the scatterlist should be mapped with
> DMA every time DMA operation is started (or drm_xxx_set_src_dma_buffer
> function call), and the pages should be unmapped from DMA again every
> time DMA operation is completed: internally, including each cache
> operation.
Correct.
> Isn't that big overhead?
Yes, if you _have_ to do a cache operation to ensure that the DMA agent
can see the data the CPU has written.
> And If there is no problem, we should accept such overhead?
If there is no problem then why are we discussing this and why do we need
this API extension? :)
> Actually, drm_gem_fd_to_handle() includes to map a
> given dmabuf with iommu table (just logical data) of the DMA. And then, the
> device address (or iova) already mapped will be set to buffer register of
> the DMA with drm_xxx_set_src/dst_dma_buffer(handle1, ...) call.
Consider this with a PIPT cache:
dma_map_sg()- at this point, the kernel addresses of these
buffers are cleaned and invalidated for the DMA
userspace writes to the buffer, the data sits in the CPU cache
Because the cache is PIPT, this data becomes visible to the
kernel as well.
DMA is started, and it writes to the buffer
Now, at this point, which is the correct data? The data physically in the
RAM which the DMA has written, or the data in the CPU cache. It may
the answer is - they both are, and the loss of either can be a potential
data corruption issue - there is no way to tell which data should be
kept but the system is in an inconsistent state and _one_ of them will
have to be discarded.
dma_unmap_sg() - at this point, the kernel addresses of the
buffers are _invalidated_ and any data in those
cache lines is discarded
Which also means that the data in userspace will also be discarded with
PIPT caches.
This is precisely why we have buffer rules associated with the DMA API,
which are these:
dma_map_sg()
- the buffer transfers ownership from the CPU to the DMA agent.
- the CPU may not alter the buffer in any way.
while (cpu_wants_access) {
dma_sync_sg_for_cpu()
- the buffer transfers ownership from the DMA to the CPU.
- the DMA may not alter the buffer in any way.
dma_sync_sg_for_device()
- the buffer transfers ownership from the CPU to the DMA
- the CPU may not alter the buffer in any way.
}
dma_unmap_sg()
- the buffer transfers ownership from the DMA to the CPU.
- the DMA may not alter the buffer in any way.
Any violation of that is likely to lead to data corruption. Now, some
may say that the DMA API is only about the kernel mapping. Yes it is,
because it takes no regard what so ever about what happens with the
userspace mappings. This is absolutely true when you have VIVT or
aliasing VIPT caches.
Now consider that with a PIPT cache, or a non-aliasing VIPT cache (which
is exactly the same behaviourally from this aspect) any modification of
a userspace mapping is precisely the same as modifying the kernel space
mapping - and what you find is that the above rules end up _inherently_
applying to the userspace mappings as well.
In other words, userspace applications which have mapped the buffers
must _also_ respect these rules.
And there's no way in hell that I'd ever trust userspace to get this
anywhere near right, and I *really* do not like these kinds of internal
kernel API rules being exposed to userspace.
And so the idea that userspace should be allowed to setup DMA transfers
via "set source buffer", "set destination buffer" calls into an API is
just plain rediculous. No, userspace should be allowed to ask for
"please copy from buffer X to buffer Y using this transform".
Also remember that drm_xxx_set_src/dst_dma_buffer() would have to
deal with the DRM object IDs for the buffer, and not the actual buffer
information themselves - that is kept within the kernel, so the kernel
knows what's happening.
[PATCH] drm/tegra: Include linux/types.h
On Mon, Jun 17, 2013 at 01:58:14PM +0200, Paul Bolle wrote:
> "make headers_check" complains about include/uapi/drm/tegra_drm.h:
> [...]/usr/include/drm/tegra_drm.h:21: found __[us]{8,16,32,64} type
> without #include
>
> So let's include linux/types.h in this header.
>
> Signed-off-by: Paul Bolle
> ---
> Tested only with "make headers_check". I don't actually build or run
> code that uses tegra_drm.h.
>
> include/uapi/drm/tegra_drm.h | 2 ++
> 1 file changed, 2 insertions(+)
That has already been fixed in linux-next.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/e9f488c1/attachment.pgp>
[PATCH] drm/tegra: Include linux/types.h
On Mon, 2013-06-17 at 22:33 +0200, Thierry Reding wrote: > That has already been fixed in linux-next. This header was added in v3.10-rc1. The fix in linux-next will ship in v3.11. Isn't that fix appropriate for (one of) the upcoming v3.10 release candidate(s)? Thanks, Paul Bolle
[Bug 65822] [radeonsi] OpenCL is broken
https://bugs.freedesktop.org/show_bug.cgi?id=65822 --- Comment #2 from Aaron Watry --- Created attachment 80967 --> https://bugs.freedesktop.org/attachment.cgi?id=80967&action=edit Test Code from initial post converted to piglit tests I've taken a shot at converting the original tests to piglit tests. I'll test a radeon 7850 in a bit, but I know that Cedar (radeon 5400, so evergreen) also fails each of these tests (and I got a GPU hang running the uint div test after 6-7 times). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/30699879/attachment.html>
[PATCH] drm/radeon: Disable writeback by default on ppc
On Mon, Jun 17, 2013 at 12:07 PM, Adam Jackson wrote: > On Mon, 2013-06-17 at 11:04 -0400, Alex Deucher wrote: >> On Mon, Jun 17, 2013 at 10:06 AM, Adam Jackson wrote: >> > At least on an IBM Power 720, this check passes, but several piglit >> > tests will reliably trigger GPU resets due to the ring buffer pointers >> > not being updated. There's probably a better way to limit this to just >> > affected machines though. >> >> What radeon chips are you seeing this on? wb is more or less required >> on r6xx and newer and I'm not sure those generations will even work >> properly without writeback enabled these days. We force it to always >> be enabled on APUs and NI and newer asics. With KMS, wb encompasses >> more than just rptr writeback; it covers pretty much everything >> involving the GPU writing any status information to memory. > > FirePro 2270, at least. Booting with no_wb=1, piglit runs to completion > with no GPU resets or IB submission failures. Booting without no_wb, > the following piglits go from pass to fail, all complaining that the > kernel rejected CS: Weird. I wonder if there is an issue with cache snoops on PPC. We currently use the gart in cached mode (GPU snoops CPU cache) with cached pages. I wonder if we need to use uncached pages on PPC. Alex
[Bug 65822] [radeonsi] OpenCL is broken
https://bugs.freedesktop.org/show_bug.cgi?id=65822 --- Comment #3 from Aaron Watry --- Created attachment 80969 --> https://bugs.freedesktop.org/attachment.cgi?id=80969&action=edit Shader dumps from a radeon 7850 for test cases in attachment 80967 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/8f7b4103/attachment.html>
[3.10rc6] /proc/dri/0/vma broken on nouveau.
> Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau > loaded. > (Note, no X running on that box) > > Trace below shows trinity, but I can reproduce it with just cat > /proc/dri/0/vma How about this, lets just rip it all out. Dave. -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-remove-vma-debug-code.patch Type: text/x-patch Size: 4047 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130617/f7441e61/attachment.bin>
[3.10rc6] /proc/dri/0/vma broken on nouveau.
On Mon, Jun 17, 2013 at 09:49:27PM -0400, David Airlie wrote: > > > Reading /proc/dri/0/vma causes bad things to happen on a box with nouveau > > loaded. > > (Note, no X running on that box) > > > > Trace below shows trinity, but I can reproduce it with just cat > > /proc/dri/0/vma > > How about this, lets just rip it all out. That's one way to deal with it :) If no programs use it, then yeah, sure, why not. Dave
[PATCH 0/3] fbdev no more!
On 06/16/2013 07:57 AM, Daniel Vetter wrote: > Hi all, > > So I've taken a look again at the locking mess in our fbdev support and cried. > Fixing up the console_lock mess around the fbdev notifier will be real work, > semanatically the fbdev layer does lots of stupid things (like the radeon > resume > issue I've just debugged) and the panic notifier is pretty much a lost cause. > > So I've decided to instead rip it all out. It seems to work \o/ I wonder how badly this breaks on EFI systems. Currently, efifb is an fbdev driver. When i915 calls register_framebuffer, the fbdev core removes efifb's framebuffer. (This is scary already -- what if i915 has reused that memory for something else beforehand?) But now, if i915 doesn't call register_framebuffer, the efifb "framebuffer" might stick around forever. Presumably, efifb ought to become a framebuffer-only drm driver and there should be a saner way to hand control from efifb (or vesa?) to a real driver. --Andy
