dri-devel July 2013

dri-devel@lists.freedesktop.org

142 participants
850 discussions

[RFC PATCH 0/2 v5] Introduce buffer synchronization framework
by Inki Dae 12 Jul '13

12 Jul '13

Hi all, This patch set introduces a buffer synchronization framework based on DMA BUF[1] and based on ww-mutexes[2] for lock mechanism. The purpose of this framework is to provide not only buffer access control to CPU and CPU, and CPU and DMA, and DMA and DMA but also easy-to-use interfaces for device drivers and user application. In addtion, this patch set suggests a way for enhancing performance. For generic user mode interface, we have used fcntl system call[3]. As you know, user application sees a buffer object as a dma-buf file descriptor. So fcntl() call with the file descriptor means to lock some buffer region being managed by the dma-buf object. For more detail, you can refer to the dma-buf-sync.txt in Documentation/ Moreover, we had tried to find how we could utilize limited hardware resources more using buffer synchronization mechanism. And finally, we have realized that it could enhance performance using multi threads with this buffer synchronization mechanism: DMA and CPU works individually so CPU could perform other works while DMA is performing some works, and vise versa. However, in the conventional way, that is not easy to do so because DMA operation is depend on CPU operation, and vice versa. Conventional way: User Kernel --------------------------------------------------------------------- CPU writes something to src send the src to driver-------------------------> update DMA register request DMA start(1)---------------------------> DMA start <---------completion signal(2)---------- CPU accesses dst (1) Request DMA start after the CPU access to src buffer is completed. (2) Access dst buffer after DMA access to the dst buffer is completed. On the other hand, if there is something to control buffer access between CPU and DMA? The below shows that: User(thread a) User(thread b) Kernel --------------------------------------------------------------------- send a src to driver----------------------------------> update DMA register lock the src request DMA start(1)----------> CPU acccess to src unlock the src lock src and dst DMA start <-------------completion signal(2)------------- lock dst DMA completion CPU access to dst unlock src and dst unlock DST (1) Try to start DMA operation while CPU is accessing the src buffer. (2) Try CPU access to dst buffer while DMA is accessing the dst buffer. This means that CPU or DMA could do more works. In the same way, we could reduce hand shaking overhead between two processes when those processes need to share a shared buffer. There may be other cases that we could reduce overhead as well. References: [1] http://lwn.net/Articles/470339/ [2] https://patchwork.kernel.org/patch/2625361/ [3] http://linux.die.net/man/2/fcntl Inki Dae (2): [RFC PATCH v5 1/2] dmabuf-sync: Introduce buffer synchronization framework [RFC PATCH v1 2/2] dma-buf: add lock callback for fcntl system call Documentation/dma-buf-sync.txt | 290 +++++++++++++++++ drivers/base/Kconfig | 7 + drivers/base/Makefile | 1 + drivers/base/dma-buf.c | 37 +++ drivers/base/dmabuf-sync.c | 674 ++++++++++++++++++++++++++++++++++++++++ include/linux/dma-buf.h | 16 + include/linux/dmabuf-sync.h | 178 +++++++++++ 7 files changed, 1203 insertions(+), 0 deletions(-) create mode 100644 Documentation/dma-buf-sync.txt create mode 100644 drivers/base/dmabuf-sync.c create mode 100644 include/linux/dmabuf-sync.h -- 1.7.5.4

1 2

Questions about TTM buffer object maping
by Jean-Sébastien Pédron 11 Jul '13

11 Jul '13

Hello, I'm trying to understand how TTM buffer object mapping works on Linux, to make this behave properly on FreeBSD. Here's what I think I understand: When a buffer object is mmap()'d, ttm_bo_vm_open() is called. When there's a page fault, the page is looked up and inserted in the VMA using vm_insert_mixed(). When a buffer object is munmap()'d, ttm_bo_vm_close() is called, which drops a reference. When the last reference is dropped, the buffer object is destroyed. What's still not clear to me is how munmap() works here. After talking about this on IRC with some people, I think that unmap_mapping_range() (called by ttm_bo_unmap_virtual_locked()) is equivalent to calling munmap() from userland. Is that true? When a buffer object is moved, what happens to the mapping? In particular, I see in ttm_bo_move_accel_cleanup() that the ttm structure can be transferred to ghost_obj, which is destroyed shortly after. This ends up in ttm_put_pages() which uses __free_page(), for each page of the buffer object. At this stage, is the ghost object already munmap()'d? Or does __free_page() unmap a page implicitly (ie. remove it from VMA)? Sorry if my questions are stupid, I'm rather new to memory management. -- Jean-Sébastien Pédron

4 7

[PATCH 1/3] drm/radeon: add fault decode function for cayman/TN (v2)
by alexdeucher＠gmail.com 11 Jul '13

11 Jul '13

From: Alex Deucher <alexander.deucher(a)amd.com> Helpful for debugging GPUVM errors as we can see what hw block and page generated the fault in the log. v2: simplify fault decoding Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/radeon/evergreen.c | 10 ++- drivers/gpu/drm/radeon/ni.c | 161 ++++++++++++++++++++++++++++++++++++ drivers/gpu/drm/radeon/nid.h | 16 ++++ 3 files changed, 185 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c index 9e14007..bc6936a 100644 --- a/drivers/gpu/drm/radeon/evergreen.c +++ b/drivers/gpu/drm/radeon/evergreen.c @@ -139,6 +139,8 @@ void evergreen_pcie_gen2_enable(struct radeon_device *rdev); void evergreen_program_aspm(struct radeon_device *rdev); extern void cayman_cp_int_cntl_setup(struct radeon_device *rdev, int ring, u32 cp_int_cntl); +extern void cayman_vm_decode_fault(struct radeon_device *rdev, + u32 status, u32 addr); static const u32 evergreen_golden_registers[] = { @@ -4629,6 +4631,7 @@ int evergreen_irq_process(struct radeon_device *rdev) bool queue_hotplug = false; bool queue_hdmi = false; bool queue_thermal = false; + u32 status, addr; if (!rdev->ih.enabled || rdev->shutdown) return IRQ_NONE; @@ -4915,11 +4918,14 @@ restart_ih: break; case 146: case 147: + addr = RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR); + status = RREG32(VM_CONTEXT1_PROTECTION_FAULT_STATUS); dev_err(rdev->dev, "GPU fault detected: %d 0x%08x\n", src_id, src_data); dev_err(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x%08X\n", - RREG32(VM_CONTEXT1_PROTECTION_FAULT_ADDR)); + addr); dev_err(rdev->dev, " VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x%08X\n", - RREG32(VM_CONTEXT1_PROTECTION_FAULT_STATUS)); + status); + cayman_vm_decode_fault(rdev, status, addr); /* reset addr and status */ WREG32_P(VM_CONTEXT1_CNTL2, 1, ~1); break; diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c index 465b17e..56bd4f3 100644 --- a/drivers/gpu/drm/radeon/ni.c +++ b/drivers/gpu/drm/radeon/ni.c @@ -2450,6 +2450,167 @@ void cayman_vm_fini(struct radeon_device *rdev) { } +/** + * cayman_vm_decode_fault - print human readable fault info + * + * @rdev: radeon_device pointer + * @status: VM_CONTEXT1_PROTECTION_FAULT_STATUS register value + * @addr: VM_CONTEXT1_PROTECTION_FAULT_ADDR register value + * + * Print human readable fault information (cayman/TN). + */ +void cayman_vm_decode_fault(struct radeon_device *rdev, + u32 status, u32 addr) +{ + u32 mc_id = (status & MEMORY_CLIENT_ID_MASK) >> MEMORY_CLIENT_ID_SHIFT; + u32 vmid = (status & FAULT_VMID_MASK) >> FAULT_VMID_SHIFT; + u32 protections = (status & PROTECTIONS_MASK) >> PROTECTIONS_SHIFT; + char *block; + + switch (mc_id) { + case 32: + case 16: + case 96: + case 80: + case 160: + case 144: + case 224: + case 208: + block = "CB"; + break; + case 33: + case 17: + case 97: + case 81: + case 161: + case 145: + case 225: + case 209: + block = "CB_FMASK"; + break; + case 34: + case 18: + case 98: + case 82: + case 162: + case 146: + case 226: + case 210: + block = "CB_CMASK"; + break; + case 35: + case 19: + case 99: + case 83: + case 163: + case 147: + case 227: + case 211: + block = "CB_IMMED"; + break; + case 36: + case 20: + case 100: + case 84: + case 164: + case 148: + case 228: + case 212: + block = "DB"; + break; + case 37: + case 21: + case 101: + case 85: + case 165: + case 149: + case 229: + case 213: + block = "DB_HTILE"; + break; + case 38: + case 22: + case 102: + case 86: + case 166: + case 150: + case 230: + case 214: + block = "SX"; + break; + case 39: + case 23: + case 103: + case 87: + case 167: + case 151: + case 231: + case 215: + block = "DB_STEN"; + break; + case 40: + case 24: + case 104: + case 88: + case 232: + case 216: + case 168: + case 152: + block = "TC_TFETCH"; + break; + case 41: + case 25: + case 105: + case 89: + case 233: + case 217: + case 169: + case 153: + block = "TC_VFETCH"; + break; + case 42: + case 26: + case 106: + case 90: + case 234: + case 218: + case 170: + case 154: + block = "VC"; + break; + case 112: + block = "CP"; + break; + case 113: + case 114: + block = "SH"; + break; + case 115: + block = "VGT"; + break; + case 178: + block = "IH"; + break; + case 51: + block = "RLC"; + break; + case 55: + block = "DMA"; + break; + case 56: + block = "HDP"; + break; + default: + block = "unknown"; + break; + } + + printk("VM fault (0x%02x, vmid %d) at page %u, %s from %s (%d)\n", + protections, vmid, addr, + (status & MEMORY_CLIENT_RW_MASK) ? "write" : "read", + block, mc_id); +} + #define R600_ENTRY_VALID (1 << 0) #define R600_PTE_SYSTEM (1 << 1) #define R600_PTE_SNOOPED (1 << 2) diff --git a/drivers/gpu/drm/radeon/nid.h b/drivers/gpu/drm/radeon/nid.h index fe24a93..22421bc 100644 --- a/drivers/gpu/drm/radeon/nid.h +++ b/drivers/gpu/drm/radeon/nid.h @@ -133,6 +133,22 @@ #define VM_CONTEXT1_CNTL2 0x1434 #define VM_INVALIDATE_REQUEST 0x1478 #define VM_INVALIDATE_RESPONSE 0x147c +#define VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x14FC +#define VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x14DC +#define PROTECTIONS_MASK (0xf << 0) +#define PROTECTIONS_SHIFT 0 + /* bit 0: range + * bit 2: pde0 + * bit 3: valid + * bit 4: read + * bit 5: write + */ +#define MEMORY_CLIENT_ID_MASK (0xff << 12) +#define MEMORY_CLIENT_ID_SHIFT 12 +#define MEMORY_CLIENT_RW_MASK (1 << 24) +#define MEMORY_CLIENT_RW_SHIFT 24 +#define FAULT_VMID_MASK (0x7 << 25) +#define FAULT_VMID_SHIFT 25 #define VM_CONTEXT0_PROTECTION_FAULT_DEFAULT_ADDR 0x1518 #define VM_CONTEXT1_PROTECTION_FAULT_DEFAULT_ADDR 0x151c #define VM_CONTEXT0_PAGE_TABLE_BASE_ADDR 0x153C -- 1.7.7.5

1 2

[Bug 61470] Driver does not turn on LCD backlight on resume
by bugzilla-daemon＠freedesktop.org 11 Jul '13

11 Jul '13

https://bugs.freedesktop.org/show_bug.cgi?id=61470 Alex Deucher <agd5f(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Alex Deucher <agd5f(a)yahoo.com> --- *** This bug has been marked as a duplicate of bug 43829 *** -- You are receiving this mail because: You are the assignee for the bug.

1 0

Commit ecff665f5e3f (drm/ttm: make ttm reservation calls...) causes system hang on Radeon RS780
by Markus Trippelsdorf 11 Jul '13

11 Jul '13

By simply copy/pasting a big document under LibreOffice my system hangs itself up. Only a hard reset gets it working again. see also: https://bugs.freedesktop.org/show_bug.cgi?id=66551 I've bisected the issue to: commit ecff665f5e3f1c6909353e00b9420e45ae23d995 Author: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> Date: Thu Jun 27 13:48:17 2013 +0200 drm/ttm: make ttm reservation calls behave like reservation calls This commit converts the source of the val_seq counter to the ww_mutex api. The reservation objects are converted later, because there is still a lockdep splat in nouveau that has to resolved first. Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> Reviewed-by: Jerome Glisse <jglisse(a)redhat.com> Signed-off-by: Dave Airlie <airlied(a)redhat.com> -- Markus

3 6

[Bug 44772] New: Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes
by bugzilla-daemon＠freedesktop.org 11 Jul '13

11 Jul '13

https://bugs.freedesktop.org/show_bug.cgi?id=44772 Bug #: 44772 Summary: Radeon HD6950 (Cayman): Resuming from hibernation fails sometimes Classification: Unclassified Product: DRI Version: XOrg CVS Platform: All OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: h.judt(a)gmx.at Resuming after hibernation fails sometimes. After reading the snapshot (the percentage reached 100%), the screen would switch back, but instead the monitor goes black and turns off and the complete system hangs. No ssh or sysreq keys work, everything is dead. Some things I noticed that might help: * It does not occur with nomodeset=1. * You don't need X to reproduce this, just console with modesetting enabled is enough. * It is not reproducible reliably, but the likelyness that it will occur is unfortunately not small (I'd say 3-4 out of 10 attempts). * The fastboot kernel parameter is not related to it. That is all with vanilla kernel. Now enter tuxonice, because it provides more information. Tuxonice reads the atomic copy first (20%..40%..60%..80%->100%). Now, it would switch on tuxoniceui and show the progress for reading in the caches. However, in the problem case the switch does not happen, because the system hangs as described for the vanilla kernel (no ssh, sysreq). At this point, one has to push the reset button to reboot. However, tuxonice has a nice feature: It will detect the image, and that it has resumed from this image before. It then asks the user whether he wants to try resuming from that same image again or remove the image and continue booting. If one presses 'C' to resume from the image, this time everything works and the system is fully functional. In fact, it's a 100% chance that the screen does not get black or the system freezes. The issue does not occur at certain cycles, sometimes three hibernation->resume cycles go well, then the fourth and fifth will not work, then the next four are ok and so on... So, I believe there is some issue with hardware initialization and hibernation. It might be that something does not really finish in time. What could there be wrong? This is with vanilla-3.2-rc5 and 3.2-rc7-tuxonice (see http://git.tuxonice.net/?p=tuxonice-head.git;a=summary), but I guess all 3.2-rc kernels will show the same problem. I had troubles hibernating with vanilla-3.2-final, so I could not test this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 12

[PATCH] drm/gpio/nv50: post nv92 cards have 32 interrupt lines
by Emil Velikov 11 Jul '13

11 Jul '13

Since the original merge of nouveau to upstream kernel, we were assuming that nv90 (and later) cards have 32 lines. Based on mmio traces of the binary driver, as well as PBUS error messages during read/write of the e070/e074 registers, we can conclude that nv92 has only 16 lines whereas nv94 (and later) cards have 32. Reported-and-tested-by: David M. Lloyd <david.lloyd(a)redhat.com> Signed-off-by: Emil Velikov <emil.l.velikov(a)gmail.com> Cc: dri-devel(a)lists.freedesktop.org Cc: Ben Skeggs <bskeggs(a)redhat.com> --- Considering that no-one has reported this issue before, I'm rather curious if we should CC stable --- drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c b/drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c index bf489dc..c4c1d41 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c +++ b/drivers/gpu/drm/nouveau/core/subdev/gpio/nv50.c @@ -103,7 +103,7 @@ nv50_gpio_intr(struct nouveau_subdev *subdev) int i; intr0 = nv_rd32(priv, 0xe054) & nv_rd32(priv, 0xe050); - if (nv_device(priv)->chipset >= 0x90) + if (nv_device(priv)->chipset > 0x92) intr1 = nv_rd32(priv, 0xe074) & nv_rd32(priv, 0xe070); hi = (intr0 & 0x0000ffff) | (intr1 << 16); @@ -115,7 +115,7 @@ nv50_gpio_intr(struct nouveau_subdev *subdev) } nv_wr32(priv, 0xe054, intr0); - if (nv_device(priv)->chipset >= 0x90) + if (nv_device(priv)->chipset > 0x92) nv_wr32(priv, 0xe074, intr1); } @@ -146,7 +146,7 @@ nv50_gpio_ctor(struct nouveau_object *parent, struct nouveau_object *engine, int ret; ret = nouveau_gpio_create(parent, engine, oclass, - nv_device(parent)->chipset >= 0x90 ? 32 : 16, + nv_device(parent)->chipset > 0x92 ? 32 : 16, &priv); *pobject = nv_object(priv); if (ret) @@ -182,7 +182,7 @@ nv50_gpio_init(struct nouveau_object *object) /* disable, and ack any pending gpio interrupts */ nv_wr32(priv, 0xe050, 0x00000000); nv_wr32(priv, 0xe054, 0xffffffff); - if (nv_device(priv)->chipset >= 0x90) { + if (nv_device(priv)->chipset > 0x92) { nv_wr32(priv, 0xe070, 0x00000000); nv_wr32(priv, 0xe074, 0xffffffff); } @@ -195,7 +195,7 @@ nv50_gpio_fini(struct nouveau_object *object, bool suspend) { struct nv50_gpio_priv *priv = (void *)object; nv_wr32(priv, 0xe050, 0x00000000); - if (nv_device(priv)->chipset >= 0x90) + if (nv_device(priv)->chipset > 0x92) nv_wr32(priv, 0xe070, 0x00000000); return nouveau_gpio_fini(&priv->base, suspend); } -- 1.8.3.2

1 0

Re: [PULL] drm-intel-fixes
by Daniel Vetter 11 Jul '13

11 Jul '13

Cc lists this time around ... -Daniel On Thu, Jul 11, 2013 at 2:06 PM, Daniel Vetter <daniel(a)ffwll.ch> wrote: > Hi Dave, > > One feature latecomer, I've forgotten to merge the patch to reeanble the > Haswell power well feature now that the audio interaction is fixed up. > Since that was the only unfixed issue with it I've figured I could throw > it in a bit late, and it's trivial to revert in case I'm wrong. > > Otherwise all bug/regression fixes: > - Fix status page reinit after gpu hangs, spotted by more paranoid igt > checks. > - Fix object list walking fumble regression in the shrinker (only the > counting part, the actual shrinking code was correct so no Oops > potential), from Xiong Zhang. > - Fix DP 1.2 bw limits (Imre). > - Restore legacy forcewake on ivb, too many broken biosen out there. We > dump a warn though that recent userspace might fall over with that > config (Guenter Roeck). > - Patch up the gen2 cs tlb w/a. > - Improve the fence coherency w/a now that we have a better understanding > what's going on. The removed wbinvd+ipi should make -rt folks happy. Big > thanks to Jon Bloomfield for figuring this out, patches from Chris. > - Fix write-read race when switching ring (Chris). Spotted with code > inspection, but now we also have an igt for it. > > There's an ugly regression we're still working on introduced between > 3.10-rc7 and 3.10.0. Unfortunately we can't just revert the offender since > that one fixes another regression :( I've asked Steven to include my > -fixes branch into linux-next to prevent such fallout in the future, > hopefully. > > Otherwise pretty calm thus far. > > Cheers, Daniel > > The following changes since commit 446f8d81ca2d9cefb614e87f2fabcc996a9e4e7e: > > drm/i915: Don't try to tear down the stolen drm_mm if it's not there (2013-07-02 11:47:19 +0200) > > are available in the git repository at: > > git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-07-11 > > for you to fetch changes up to 46a0b638f35b45fc13d3dc0deb6a7e17988170b2: > > Revert "drm/i915: Workaround incoherence between fences and LLC across multiple CPUs" (2013-07-10 15:31:12 +0200) > > ---------------------------------------------------------------- > Chris Wilson (3): > drm/i915: Fix write-read race with multiple rings > drm/i915: Fix incoherence with fence updates on Sandybridge+ > Revert "drm/i915: Workaround incoherence between fences and LLC across multiple CPUs" > > Daniel Vetter (2): > drm/i915: reinit status page registers after gpu reset > drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a > > Guenter Roeck (1): > Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb" > > Imre Deak (1): > drm/i915: fix lane bandwidth capping for DP 1.2 sinks > > Paulo Zanoni (1): > drm/i915: switch disable_power_well default value to 1 > > Xiong Zhang (1): > drm/i915: Correct obj->mm_list link to dev_priv->dev_priv->mm.inactive_list > > drivers/gpu/drm/i915/i915_drv.c | 4 +- > drivers/gpu/drm/i915/i915_gem.c | 83 +++++++++++++-------------------- > drivers/gpu/drm/i915/intel_dp.c | 5 ++ > drivers/gpu/drm/i915/intel_pm.c | 31 +++++++++++- > drivers/gpu/drm/i915/intel_ringbuffer.c | 38 +++++++++------ > 5 files changed, 93 insertions(+), 68 deletions(-) > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch

1 0

[PATCH 1/2] drm/gem: simplify object initialization
by David Herrmann 11 Jul '13

11 Jul '13

drm_gem_object_init() and drm_gem_private_object_init() do exactly the same (except for shmem alloc) so make the first use the latter to reduce code duplication. Also drop the return code from drm_gem_private_object_init(). It seems unlikely that we will extend it any time soon so no reason to keep it around. This simplifies code paths in drivers, too. Last but not least, fix gma500 to call drm_gem_object_release() before freeing objects that were allocated via drm_gem_private_object_init(). That isn't actually necessary for now, but might be in the future. Cc: Patrik Jakobsson <patrik.r.jakobsson(a)gmail.com> Signed-off-by: David Herrmann <dh.herrmann(a)gmail.com> --- drivers/gpu/drm/drm_gem.c | 20 ++++++++------------ drivers/gpu/drm/gma500/framebuffer.c | 6 ++---- drivers/gpu/drm/gma500/gem.c | 7 ++++--- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 7 +------ drivers/gpu/drm/i915/i915_gem_stolen.c | 4 +--- drivers/gpu/drm/omapdrm/omap_gem.c | 3 ++- include/drm/drmP.h | 4 ++-- 7 files changed, 20 insertions(+), 31 deletions(-) diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c index 603f256..1ad9e7e 100644 --- a/drivers/gpu/drm/drm_gem.c +++ b/drivers/gpu/drm/drm_gem.c @@ -132,16 +132,14 @@ drm_gem_destroy(struct drm_device *dev) int drm_gem_object_init(struct drm_device *dev, struct drm_gem_object *obj, size_t size) { - BUG_ON((size & (PAGE_SIZE - 1)) != 0); + struct file *filp; - obj->dev = dev; - obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE); - if (IS_ERR(obj->filp)) - return PTR_ERR(obj->filp); + filp = shmem_file_setup("drm mm object", size, VM_NORESERVE); + if (IS_ERR(filp)) + return PTR_ERR(filp); - kref_init(&obj->refcount); - atomic_set(&obj->handle_count, 0); - obj->size = size; + drm_gem_private_object_init(dev, obj, size); + obj->filp = filp; return 0; } @@ -152,8 +150,8 @@ EXPORT_SYMBOL(drm_gem_object_init); * no GEM provided backing store. Instead the caller is responsible for * backing the object and handling it. */ -int drm_gem_private_object_init(struct drm_device *dev, - struct drm_gem_object *obj, size_t size) +void drm_gem_private_object_init(struct drm_device *dev, + struct drm_gem_object *obj, size_t size) { BUG_ON((size & (PAGE_SIZE - 1)) != 0); @@ -163,8 +161,6 @@ int drm_gem_private_object_init(struct drm_device *dev, kref_init(&obj->refcount); atomic_set(&obj->handle_count, 0); obj->size = size; - - return 0; } EXPORT_SYMBOL(drm_gem_private_object_init); diff --git a/drivers/gpu/drm/gma500/framebuffer.c b/drivers/gpu/drm/gma500/framebuffer.c index 8b1b6d9..362dd2a 100644 --- a/drivers/gpu/drm/gma500/framebuffer.c +++ b/drivers/gpu/drm/gma500/framebuffer.c @@ -321,10 +321,8 @@ static struct gtt_range *psbfb_alloc(struct drm_device *dev, int aligned_size) /* Begin by trying to use stolen memory backing */ backing = psb_gtt_alloc_range(dev, aligned_size, "fb", 1); if (backing) { - if (drm_gem_private_object_init(dev, - &backing->gem, aligned_size) == 0) - return backing; - psb_gtt_free_range(dev, backing); + drm_gem_private_object_init(dev, &backing->gem, aligned_size); + return backing; } return NULL; } diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c index eefd6cc..fe1d332 100644 --- a/drivers/gpu/drm/gma500/gem.c +++ b/drivers/gpu/drm/gma500/gem.c @@ -261,11 +261,12 @@ static int psb_gem_create_stolen(struct drm_file *file, struct drm_device *dev, struct gtt_range *gtt = psb_gtt_alloc_range(dev, size, "gem", 1); if (gtt == NULL) return -ENOMEM; - if (drm_gem_private_object_init(dev, &gtt->gem, size) != 0) - goto free_gtt; + + drm_gem_private_object_init(dev, &gtt->gem, size); if (drm_gem_handle_create(file, &gtt->gem, handle) == 0) return 0; -free_gtt: + + drm_gem_object_release(&gtt->gem); psb_gtt_free_range(dev, gtt); return -ENOMEM; } diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c b/drivers/gpu/drm/i915/i915_gem_dmabuf.c index dc53a52..f2e185c 100644 --- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c +++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c @@ -289,12 +289,7 @@ struct drm_gem_object *i915_gem_prime_import(struct drm_device *dev, goto fail_detach; } - ret = drm_gem_private_object_init(dev, &obj->base, dma_buf->size); - if (ret) { - i915_gem_object_free(obj); - goto fail_detach; - } - + drm_gem_private_object_init(dev, &obj->base, dma_buf->size); i915_gem_object_init(obj, &i915_gem_object_dmabuf_ops); obj->base.import_attach = attach; diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c index 982d473..ff27968 100644 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c @@ -271,9 +271,7 @@ _i915_gem_object_create_stolen(struct drm_device *dev, if (obj == NULL) return NULL; - if (drm_gem_private_object_init(dev, &obj->base, stolen->size)) - goto cleanup; - + drm_gem_private_object_init(dev, &obj->base, stolen->size); i915_gem_object_init(obj, &i915_gem_object_stolen_ops); obj->pages = i915_pages_create_for_stolen(dev, diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c b/drivers/gpu/drm/omapdrm/omap_gem.c index ebbdf41..cbcd71e 100644 --- a/drivers/gpu/drm/omapdrm/omap_gem.c +++ b/drivers/gpu/drm/omapdrm/omap_gem.c @@ -1427,8 +1427,9 @@ struct drm_gem_object *omap_gem_new(struct drm_device *dev, omap_obj->height = gsize.tiled.height; } + ret = 0; if (flags & (OMAP_BO_DMA|OMAP_BO_EXT_MEM)) - ret = drm_gem_private_object_init(dev, obj, size); + drm_gem_private_object_init(dev, obj, size); else ret = drm_gem_object_init(dev, obj, size); diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 12083dc..ee2f049 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -1613,8 +1613,8 @@ struct drm_gem_object *drm_gem_object_alloc(struct drm_device *dev, size_t size); int drm_gem_object_init(struct drm_device *dev, struct drm_gem_object *obj, size_t size); -int drm_gem_private_object_init(struct drm_device *dev, - struct drm_gem_object *obj, size_t size); +void drm_gem_private_object_init(struct drm_device *dev, + struct drm_gem_object *obj, size_t size); void drm_gem_object_handle_free(struct drm_gem_object *obj); void drm_gem_vm_open(struct vm_area_struct *vma); void drm_gem_vm_close(struct vm_area_struct *vma); -- 1.8.3.2

5 5

[PATCH v2 00/20] Unified VMA Offset Manager v2 (+Render Node RFC)
by David Herrmann 11 Jul '13

11 Jul '13

Hi This is v2 of the unified VMA offset manager series. The first draft is available at LWN [1]. This series replaces the VMA offset managers in GEM and TTM with a unified implementation. The first 4 patches contain the new VMA offset manager and are the only patches that I propose for mainline inclusion. Patches 5-8 clean up drm_mm and are informational-only. Daniel has similar patches in i915-next and I will rebase them once it is merged. Ignore them if you're not interested. Patches 9-19 implement mmap access control. Comments are welcome! They are intended for mainline inclusion, too, but probably require some more review rounds. I'd really appreciate if driver authors could comment on the implementation. Patch 20 shows the main motivation behind this whole series: render nodes. It is marked RFC and I will resend once the VMA manager is merged upstream. Feel free to test it. One more note regarding DRM-Master: Render-clients are independent of DRM-Master (see the DocBook documentation). It really doesn't make sense to create/bind a DRM-Master object to render-clients. However, a lot of core DRM code depends on ->master != NULL. Drivers need to take care not to call into those core modules if they implement DRIVER_RENDER. I plan on removing multiple-master-support in the next series. So there will be only one global master and each open-file is bound to it. This will make it very easy to phase out "drm_master". The planned "modeset" nodes provide a nice replacement. If anyone knows a **currently used** use-case for multiple-masters, please tell me. I couldn't find one that _actually works_. (SetMaster+DropMaster will obviously stay functional even with drm_master removed). (series available at: https://github.com/dvdhrm/linux/tree/rnodes) Comments welcome! Cheers David Changes in v2: - Drop drm_mm_init() fix (already applied in drm-next) - Drop drm_mm_node_linked() in favor of drm_mm_node_allocated() - Adjust DocBook integration - Rebased on drm-next (and compile tested on ARM) - Removed unnecessary likely/unlikely marks (except for rbtree paths) - small fixes (see commit messages for more) New in v2: - Cleanup patches for drm_mm. Note that these are marked RFC as Daniel has similar patches pending in i915-next. But the patches show that most of drm_mm is obsolete and can be removed. I will rebase them once i915-next is merged into drm-next and resend. - Access Management API: Following Dave's proposal, this series implements mmap-offset access managamenet via a "file_priv" lookup-tree for each node. - Render-Nodes: Following krh's proposal, I revived render nodes which no longer have the mmap security problem. Driver-implementations still missing, but you can find working examples for i915 and nouveau on dri-devel or [2]. Still To Do: - See whether _DRM_GEM can be dropped. I haven't checked legacy user-space so far. - Patch #16 (vmwgfx) has a TODO marker. I couldn't figure out whether the proposed replacement does the same as the old code (with all the side-effects). Would be nice if Thomas could comment on that (CC'ed). - Patch #18 (gem mmap) adds filp to all VMAs during open and removes them during close. This is not necessary for TTM+GEM drivers which don't use gem_mmap(). However, it works for now and I wanted to avoid 20 more patches fixing each GEM driver. I will provide that in the final series. [1] Unified VMA Offset Manager v1: https://lwn.net/Articles/557265/ [2] Render-node driver patches: https://gitorious.org/linux-nouveau-pm/linux-nouveau-pm/commits/render_nodes David Herrmann (20): drm: add unified vma offset manager drm/gem: convert to new unified vma manager drm/ttm: convert to unified vma offset manager drm/vma: provide drm_vma_node_unmap() helper drm/mm: add "best_match" to drm_mm_insert_node() drm/ttm: replace drm_mm_pre_get() by direct alloc drm/i915: pre-alloc instead of drm_mm search/get_block drm/mm: remove unused API drm/vma: add access management helpers drm/ast: implement mmap access managament drm/cirrus: implement mmap access managament drm/mgag200: implement mmap access managament drm/nouveau: implement mmap access managament drm/radeon: implement mmap access managament drm/qxl: implement mmap access managament drm/vmwgfx: implement mmap access managament drm/ttm: prevent mmap access to unauthorized users drm/gem: implement mmap access management drm: fix minor number range calculation drm: implement render nodes Documentation/DocBook/drm.tmpl | 77 ++++++ drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/ast/ast_drv.c | 2 + drivers/gpu/drm/ast/ast_drv.h | 4 + drivers/gpu/drm/ast/ast_main.c | 17 +- drivers/gpu/drm/cirrus/cirrus_drv.h | 4 + drivers/gpu/drm/cirrus/cirrus_main.c | 17 +- drivers/gpu/drm/drm_drv.c | 15 +- drivers/gpu/drm/drm_fops.c | 14 +- drivers/gpu/drm/drm_gem.c | 111 +++----- drivers/gpu/drm/drm_gem_cma_helper.c | 9 +- drivers/gpu/drm/drm_mm.c | 139 ++-------- drivers/gpu/drm/drm_pci.c | 9 + drivers/gpu/drm/drm_platform.c | 9 + drivers/gpu/drm/drm_stub.c | 17 +- drivers/gpu/drm/drm_usb.c | 9 + drivers/gpu/drm/drm_vma_manager.c | 408 +++++++++++++++++++++++++++++ drivers/gpu/drm/exynos/exynos_drm_gem.c | 7 +- drivers/gpu/drm/gma500/gem.c | 8 +- drivers/gpu/drm/i915/i915_gem.c | 25 +- drivers/gpu/drm/i915/i915_gem_stolen.c | 72 +++-- drivers/gpu/drm/mgag200/mgag200_drv.c | 2 + drivers/gpu/drm/mgag200/mgag200_drv.h | 4 + drivers/gpu/drm/mgag200/mgag200_main.c | 17 +- drivers/gpu/drm/nouveau/nouveau_display.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 21 +- drivers/gpu/drm/omapdrm/omap_gem.c | 11 +- drivers/gpu/drm/omapdrm/omap_gem_helpers.c | 49 +--- drivers/gpu/drm/qxl/qxl_gem.c | 7 +- drivers/gpu/drm/qxl/qxl_object.h | 2 +- drivers/gpu/drm/qxl/qxl_release.c | 2 +- drivers/gpu/drm/radeon/radeon_gem.c | 7 + drivers/gpu/drm/radeon/radeon_object.h | 5 +- drivers/gpu/drm/sis/sis_mm.c | 4 +- drivers/gpu/drm/ttm/ttm_bo.c | 79 +----- drivers/gpu/drm/ttm/ttm_bo_manager.c | 40 ++- drivers/gpu/drm/ttm/ttm_bo_util.c | 3 +- drivers/gpu/drm/ttm/ttm_bo_vm.c | 82 +++--- drivers/gpu/drm/udl/udl_gem.c | 6 +- drivers/gpu/drm/via/via_mm.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 33 ++- include/drm/drmP.h | 15 +- include/drm/drm_mm.h | 110 ++------ include/drm/drm_vma_manager.h | 170 ++++++++++++ include/drm/ttm/ttm_bo_api.h | 15 +- include/drm/ttm/ttm_bo_driver.h | 7 +- include/uapi/drm/drm.h | 2 +- 47 files changed, 1074 insertions(+), 600 deletions(-) create mode 100644 drivers/gpu/drm/drm_vma_manager.c create mode 100644 include/drm/drm_vma_manager.h -- 1.8.3.2

2 24

← Newer
1
...
72
73
74
75
76
77
78
...
85
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2013