Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

6 participants
7474 discussions

[PATCHv2 0/4] ARM: replace custom consistent dma region with vmalloc

by Marek Szyprowski

Hello! Recent changes to ioremap and unification of vmalloc regions on ARM significantly reduces the possible size of the consistent dma region. They are significantly limited allowed dma coherent/writecombine allocations. This experimental patchset replaces custom consistent dma regions usage in dma-mapping framework in favour of generic vmalloc areas created on demand for each coherent and writecombine allocations. The main purpose for this patchset is to remove 2MiB limit of dma coherent/writecombine allocations. Atomic allocations are served from special pool preallocated on boot, becasue vmalloc areas cannot be reliably created in atomic context. This patch is based on vanilla v3.4-rc7 release. Atomic allocations have been tested with s3c-sdhci driver on Samsung UniversalC210 board with dmabounce code enabled to force dma_alloc_coherent() use on each dma_map_* call (some of them are made from interrupts). Best regards Marek Szyprowski Samsung Poland R&D Center Changelog: v2: - added support for atomic allocations (served from preallocated pool) - minor cleanup here and there - rebased onto v3.4-rc7 v1: http://thread.gmane.org/gmane.linux.kernel.mm/76703 - initial version Patch summary: Marek Szyprowski (4): mm: vmalloc: use const void * for caller argument mm: vmalloc: export find_vm_area() function mm: vmalloc: add VM_DMA flag to indicate areas used by dma-mapping framework ARM: dma-mapping: remove custom consistent dma region Documentation/kernel-parameters.txt | 4 + arch/arm/include/asm/dma-mapping.h | 2 +- arch/arm/mm/dma-mapping.c | 360 ++++++++++++++++------------------- include/linux/vmalloc.h | 10 +- mm/vmalloc.c | 31 ++-- 5 files changed, 185 insertions(+), 196 deletions(-) -- 1.7.10.1

14 years, 2 months

[GIT PULL]: dma-buf updates for 3.5

by Sumit Semwal

Hi Linus, Here's the first signed-tag pull request for dma-buf framework. Could you please pull the dma-buf updates for 3.5? This includes the following key items: - mmap support - vmap support - related documentation updates These are needed by various drivers to allow mmap/vmap of dma-buf shared buffers. Dave Airlie has some prime patches dependent on the vmap pull as well. Thanks and best regards, ~Sumit. The following changes since commit 76e10d158efb6d4516018846f60c2ab5501900bc: Linux 3.4 (2012-05-20 15:29:13 -0700) are available in the git repository at: ssh://sumitsemwal@git.linaro.org/~/public_git/linux-dma-buf.git tags/tag-for-linus-3.5 for you to fetch changes up to b25b086d23eb852bf3cfdeb60409b4967ebb3c0c: dma-buf: add initial vmap documentation (2012-05-25 12:51:11 +0530) ---------------------------------------------------------------- dma-buf updates for 3.5 ---------------------------------------------------------------- Daniel Vetter (1): dma-buf: mmap support Dave Airlie (2): dma-buf: add vmap interface dma-buf: add initial vmap documentation Sumit Semwal (1): dma-buf: minor documentation fixes. Documentation/dma-buf-sharing.txt | 109 ++++++++++++++++++++++++++++++++++--- drivers/base/dma-buf.c | 99 ++++++++++++++++++++++++++++++++- include/linux/dma-buf.h | 33 +++++++++++ 3 files changed, 233 insertions(+), 8 deletions(-)

14 years, 2 months

[RFC] Synchronizing access to buffers shared with dma-buf between drivers/devices

by Tom Cooksey

Hi All, I realise it's been a while since this was last discussed, however I'd like to bring up kernel-side synchronization again. By kernel-side synchronization, I mean allowing multiple drivers/devices wanting to access the same buffer to do so without bouncing up to userspace to resolve dependencies such as "the display controller can't start scanning out a buffer until the GPU has finished rendering into it". As such, this is really just an optimization which reduces latency between E.g. The GPU finishing a rendering job and that buffer being scanned out. I appreciate this particular example is already solved on desktop graphics cards as the display controller and 3D core are both controlled by the same driver, so no "generic" mechanism is needed. However on ARM SoCs, the 3D core (like an ARM Mali) and display controller tend to be driven by separate drivers, so some mechanism is needed to allow both drivers to synchronize their access to buffers. There are multiple ways synchronization can be achieved, fences/sync objects is one common approach, however we're presenting a different approach. Personally, I quite like fence sync objects, however we believe it requires a lot of userspace interfaces to be changed to pass around sync object handles. Our hope is that the kds approach will require less effort to make use of as no existing userspace interfaces need to be changed. E.g. To use explicit fences, the struct drm_mode_crtc_page_flip would need a new members to pass in the handle(s) of sync object(s) which the flip depends on (I.e. don't flip until these fences fire). The additional benefit of our approach is that it prevents userspace specifying dependency loops which can cause a deadlock (see kds.txt for an explanation of what I mean here). I have waited until now to bring this up again because I am now able to share the code I was trying (and failing I think) to explain previously. The code has now been released under the GPLv2 from ARM Mali's developer portal, however I've attempted to turn that into a patch to allow it to be discussed on this list. Please find the patch inline below. While KDS defines a very generic mechanism, I am proposing that this code or at least the concepts be merged with the existing dma_buf code, so a the struct kds_resource members get moved to struct dma_buf, kds_* functions get renamed to dma_buf_* functions, etc. So I guess what I'm saying is please don't review the actual code just yet, only the concepts the code describes, where kds_resource == dma_duf. Cheers, Tom Author: Tom Cooksey <tom.cooksey(a)arm.com> Date: Fri May 25 10:45:27 2012 +0100 Add new system to allow synchronizing access to resources See Documentation/kds.txt for details, however the general idea is that this kds framework synchronizes multiple drivers ("clients") wanting to access the same resources, where a resource is typically a 2D image buffer being shared around using dma-buf. Note: This patch is created by extracting the sources from the tarball on <http://www.malideveloper.com/open-source-mali-gpus-lin ux-kernel-device-drivers---dev-releases.php> and putting them in roughly the right places. diff --git a/Documentation/kds.txt b/Documentation/kds.txt new file mode 100644 index 0000000..a96db21 --- /dev/null +++ b/Documentation/kds.txt @@ -0,0 +1,113 @@ +# +# (C) COPYRIGHT 2012 ARM Limited. All rights reserved. +# +# This program is free software and is provided to you under the terms of the GNU General Public License version 2 +# as published by the Free Software Foundation, and any use by you of this program is subject to the terms of such GNU licence. +# +# A copy of the licence is included with the program, and can also be obtained from Free Software +# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +# +# + + +============================== +kds - Kernel Dependency System +============================== + +Introduction +------------ +kds provides a mechanism for clients to atomically lock down multiple abstract resources. +This can be done either synchronously or asynchronously. +Abstract resources is used to allow a set of clients to use kds to control access to any +resource, an example is structured memory buffers. + +kds supports that buffer is locked for exclusive access and sharing of buffers. + +kds can be built as either a integrated feature of the kernel or as a module. +It supports being compiled as a module both in-tree and out-of-tree. + + +Concepts +-------- +A core concept in kds is abstract resources. +A kds resource is just an abstraction for some client object, kds doesn't care what it is. +Typically EGL will consider UMP buffers as being a resource, thus each UMP buffer has +a kds resource for synchronization to the buffer. + +kds allows a client to create and destroy the abstract resource objects. +A new resource object is made available asap (it is just a simple malloc with some initializations), +while destroy it requires some external synchronization. + +The other core concept in kds is consumer of resources. +kds is requested to allow a client to consume a set of resources and the client will be notified when it can consume the resources. + +Exclusive access allows only one client to consume a resource. +Shared access permits multiple consumers to acceess a resource concurrently. + + +APIs +---- +kds provides simple resource allocate and destroy functions. +Clients use this to instantiate and control the lifetime of the resources kds manages. + +kds provides two ways to wait for resources: +- Asynchronous wait: the client specifies a function pointer to be called when wait is over +- Synchronous wait: Function blocks until access is gained. + +The synchronous API has a timeout for the wait. +The call can early out if a signal is delivered. + +After a client is done consuming the resource kds must be notified to release the resources and let some other client take ownership. +This is done via resource set release call. + +A Windows comparison: +kds implements WaitForMultipleObjectsEx(..., bWaitAll = TRUE, ...) but also has an asynchronous version in addition. +kds resources can be seen as being the same as NT object manager resources. + +Internals +--------- +kds guarantees atomicity when a set of resources is operated on. +This is implemented via a global resource lock which is taken by kds when it updates resource objects. + +Internally a resource in kds is a linked list head with some flags. + +When a consumer requests access to a set of resources it is queued on each of the resources. +The link from the consumer to the resources can be triggered. Once all links are triggered +the registered callback is called or the blocking function returns. +A link is considered triggered if it is the first on the list of consumers of a resource, +or if all the links ahead of it is marked as shared and itself is of the type shared. + +When the client is done consuming the consumer object is removed from the linked lists of +the resources and a potential new consumer becomes the head of the resources. +As we add and remove consumers atomically across all resources we can guarantee that +we never introduces a A->B + B->A type of loops/deadlocks. + + +kbase/base implementation +------------------------- +A HW job needs access to a set of shared resources. +EGL tracks this and encodes the set along with the atom in the ringbuffer. +EGL allocates a (k)base dep object to represent the dependency to the set of resources and encodes that along with the list of resources. +This dep object is use to create a dependency from a job chain(atom) to the resources it needs to run. +When kbase decodes the atom in the ringbuffer it finds the set of resources and calls kds to request all the needed resources. +As EGL needs to know when the kds request is delivered a new base event object is needed: atom enqueued. This event is only delivered for atoms which uses kds. +The callback kbase registers trigger the dependency object described which would trigger the existing JD system to release the job chain. +When the atom is done kds resource set release is call to release the resources. + +EGL will typically use exclusive access to the render target, while all buffers used as input can be marked as shared. + + +Buffer publish/vsync +-------------------- +EGL will use a separate ioctl or DRM flip to request the flip. +If the LCD driver is integrated with kds EGL can do these operations early. +The LCD driver must then implement the ioctl or DRM flip to be asynchronous with kds async call. +The LCD driver binds a kds resource to each virtual buffer (2 buffers in case of double-buffering). +EGL will make a dependency to the target kds resource in the kbase atom. +After EGL receives a atom enqueued event it can ask the LCD driver to pan to the target kds resource. +When the atom is completed it'll release the resource and the LCD driver will get its callback. +In the callback it'll load the target buffer into the DMA unit of the LCD hardware. +The LCD driver will be the consumer of both buffers for a short period. +The LCD driver will call kds resource set release on the previous on-screen buffer when the next vsync/dma read end is handled. + + diff --git a/drivers/misc/kds.c b/drivers/misc/kds.c new file mode 100644 index 0000000..8d7d55e --- /dev/null +++ b/drivers/misc/kds.c @@ -0,0 +1,461 @@ +/* + * + * (C) COPYRIGHT 2012 ARM Limited. All rights reserved. + * + * This program is free software and is provided to you under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation, and any use by you of this program is subject to the terms of such GNU licence. + * + * A copy of the licence is included with the program, and can also be obtained from Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + */ + + + +#include <linux/slab.h> +#include <linux/list.h> +#include <linux/mutex.h> +#include <linux/wait.h> +#include <linux/sched.h> +#include <linux/err.h> +#include <linux/module.h> +#include <linux/workqueue.h> +#include <linux/kds.h> + + +#define KDS_LINK_TRIGGERED (1u << 0) +#define KDS_LINK_EXCLUSIVE (1u << 1) + +#define KDS_IGNORED NULL +#define KDS_INVALID (void*)-2 +#define KDS_RESOURCE (void*)-1 + +struct kds_resource_set +{ + unsigned long num_resources; + unsigned long pending; + unsigned long locked_resources; + struct kds_callback * cb; + void * callback_parameter; + void * callback_extra_parameter; + struct list_head callback_link; + struct work_struct callback_work; + struct kds_link resources[0]; +}; + +static DEFINE_MUTEX(kds_lock); + +int kds_callback_init(struct kds_callback * cb, int direct, kds_callback_fn user_cb) +{ + int ret = 0; + + cb->direct = direct; + cb->user_cb = user_cb; + + if (!direct) + { + cb->wq = alloc_workqueue("kds", WQ_UNBOUND | WQ_HIGHPRI, WQ_UNBOUND_MAX_ACTIVE); + if (!cb->wq) + ret = -ENOMEM; + } + else + { + cb->wq = NULL; + } + + return ret; +} +EXPORT_SYMBOL(kds_callback_init); + +void kds_callback_term(struct kds_callback * cb) +{ + if (!cb->direct) + { + BUG_ON(!cb->wq); + destroy_workqueue(cb->wq); + } + else + { + BUG_ON(cb->wq); + } +} + +EXPORT_SYMBOL(kds_callback_term); + +static void kds_do_user_callback(struct kds_resource_set * rset) +{ + rset->cb->user_cb(rset->callback_parameter, rset->callback_extra_parameter); +} + +static void kds_queued_callback(struct work_struct * work) +{ + struct kds_resource_set * rset; + rset = container_of( work, struct kds_resource_set, callback_work); + + kds_do_user_callback(rset); +} + +static void kds_callback_perform(struct kds_resource_set * rset) +{ + if (rset->cb->direct) + kds_do_user_callback(rset); + else + { + int result; + result = queue_work(rset->cb->wq, &rset->callback_work); + /* if we got a 0 return it means we've triggered the same rset twice! */ + BUG_ON(!result); + } +} + +void kds_resource_init(struct kds_resource * res) +{ + BUG_ON(!res); + INIT_LIST_HEAD(&res->waiters.link); + res->waiters.parent = KDS_RESOURCE; +} +EXPORT_SYMBOL(kds_resource_init); + +void kds_resource_term(struct kds_resource * res) +{ + BUG_ON(!res); + BUG_ON(!list_empty(&res->waiters.link)); + res->waiters.parent = KDS_INVALID; +} +EXPORT_SYMBOL(kds_resource_term); + +int kds_async_waitall( + struct kds_resource_set ** pprset, + unsigned long flags, + struct kds_callback * cb, + void * callback_parameter, + void * callback_extra_parameter, + int number_resources, + unsigned long * exclusive_access_bitmap, + struct kds_resource ** resource_list) +{ + struct kds_resource_set * rset = NULL; + int i; + int triggered; + int err = -EFAULT; + + BUG_ON(!pprset); + BUG_ON(!resource_list); + BUG_ON(!cb); + + mutex_lock(&kds_lock); + + if ((flags & KDS_FLAG_LOCKED_ACTION) == KDS_FLAG_LOCKED_FAIL) + { + for (i = 0; i < number_resources; i++) + { + if (resource_list[i]->lock_count) + { + err = -EBUSY; + goto errout; + } + } + } + + rset = kmalloc(sizeof(*rset) + number_resources * sizeof(struct kds_link), GFP_KERNEL); + if (!rset) + { + err = -ENOMEM; + goto errout; + } + + rset->num_resources = number_resources; + rset->pending = number_resources; + rset->locked_resources = 0; + rset->cb = cb; + rset->callback_parameter = callback_parameter; + rset->callback_extra_parameter = callback_extra_parameter; + INIT_LIST_HEAD(&rset->callback_link); + INIT_WORK(&rset->callback_work, kds_queued_callback); + + for (i = 0; i < number_resources; i++) + { + unsigned long link_state = 0; + + INIT_LIST_HEAD(&rset->resources[i].link); + rset->resources[i].parent = rset; + + if (test_bit(i, exclusive_access_bitmap)) + { + link_state |= KDS_LINK_EXCLUSIVE; + } + + /* no-one else waiting? */ + if (list_empty(&resource_list[i]->waiters.link)) + { + link_state |= KDS_LINK_TRIGGERED; + rset->pending--; + } + /* Adding a non-exclusive and the current tail is a triggered non-exclusive? */ + else if (((link_state & KDS_LINK_EXCLUSIVE) == 0) && + (((list_entry(resource_list[i]->waiters.link.prev, struct kds_link, link)->state & (KDS_LINK_EXCLUSIVE | KDS_LINK_TRIGGERED)) == KDS_LINK_TRIGGERED))) + { + link_state |= KDS_LINK_TRIGGERED; + rset->pending--; + } + /* locked & ignore locked? */ + else if ((resource_list[i]->lock_count) && ((flags & KDS_FLAG_LOCKED_ACTION) == KDS_FLAG_LOCKED_IGNORE) ) + { + link_state |= KDS_LINK_TRIGGERED; + rset->pending--; + rset->resources[i].parent = KDS_IGNORED; /* to disable decrementing the pending count when we get the ignored resource */ + } + rset->resources[i].state = link_state; + list_add_tail(&rset->resources[i].link, &resource_list[i]->waiters.link); + } + + triggered = (rset->pending == 0); + + mutex_unlock(&kds_lock); + + /* set the pointer before the callback is called so it sees it */ + *pprset = rset; + + if (triggered) + { + /* all resources obtained, trigger callback */ + kds_callback_perform(rset); + } + + return 0; + +errout: + mutex_unlock(&kds_lock); + return err; +} +EXPORT_SYMBOL(kds_async_waitall); + +static void wake_up_sync_call(void * callback_parameter, void * callback_extra_parameter) +{ + wait_queue_head_t * wait = (wait_queue_head_t*)callback_parameter; + wake_up(wait); +} + +static struct kds_callback sync_cb = +{ + wake_up_sync_call, + 1, + NULL, +}; + +struct kds_resource_set * kds_waitall( + int number_resources, + unsigned long * exclusive_access_bitmap, + struct kds_resource ** resource_list, + unsigned long jiffies_timeout) +{ + struct kds_resource_set * rset; + int i; + int triggered = 0; + DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wake); + + rset = kmalloc(sizeof(*rset) + number_resources * sizeof(struct kds_link), GFP_KERNEL); + if (!rset) + return rset; + + rset->num_resources = number_resources; + rset->pending = number_resources; + rset->locked_resources = 1; + INIT_LIST_HEAD(&rset->callback_link); + INIT_WORK(&rset->callback_work, kds_queued_callback); + + mutex_lock(&kds_lock); + + for (i = 0; i < number_resources; i++) + { + unsigned long link_state = 0; + + if (likely(resource_list[i]->lock_count < ULONG_MAX)) + resource_list[i]->lock_count++; + else + break; + + if (test_bit(i, exclusive_access_bitmap)) + { + link_state |= KDS_LINK_EXCLUSIVE; + } + + if (list_empty(&resource_list[i]->waiters.link)) + { + link_state |= KDS_LINK_TRIGGERED; + rset->pending--; + } + /* Adding a non-exclusive and the current tail is a triggered non-exclusive? */ + else if (((link_state & KDS_LINK_EXCLUSIVE) == 0) && + (((list_entry(resource_list[i]->waiters.link.prev, struct kds_link, link)->state & (KDS_LINK_EXCLUSIVE | KDS_LINK_TRIGGERED)) == KDS_LINK_TRIGGERED))) + { + link_state |= KDS_LINK_TRIGGERED; + rset->pending--; + } + + INIT_LIST_HEAD(&rset->resources[i].link); + rset->resources[i].parent = rset; + rset->resources[i].state = link_state; + list_add_tail(&rset->resources[i].link, &resource_list[i]->waiters.link); + } + + if (i < number_resources) + { + /* an overflow was detected, roll back */ + while (i--) + { + list_del(&rset->resources[i].link); + resource_list[i]->lock_count--; + } + mutex_unlock(&kds_lock); + kfree(rset); + return ERR_PTR(-EFAULT); + } + + if (rset->pending == 0) + triggered = 1; + else + { + rset->cb = &sync_cb; + rset->callback_parameter = &wake; + rset->callback_extra_parameter = NULL; + } + + mutex_unlock(&kds_lock); + + if (!triggered) + { + long wait_res; + if ( KDS_WAIT_BLOCKING == jiffies_timeout ) + { + wait_res = wait_event_interruptible(wake, rset->pending == 0); + } + else + { + wait_res = wait_event_interruptible_timeout(wake, rset->pending == 0, jiffies_timeout); + } + if ((wait_res == -ERESTARTSYS) || (wait_res == 0)) + { + /* use \a kds_resource_set_release to roll back */ + kds_resource_set_release(&rset); + return ERR_PTR(wait_res); + } + } + return rset; +} +EXPORT_SYMBOL(kds_waitall); + +void kds_resource_set_release(struct kds_resource_set ** pprset) +{ + struct list_head triggered = LIST_HEAD_INIT(triggered); + struct kds_resource_set * rset; + struct kds_resource_set * it; + int i; + + BUG_ON(!pprset); + + mutex_lock(&kds_lock); + + rset = *pprset; + if (!rset) + { + /* caught a race between a cancelation + * and a completion, nothing to do */ + mutex_unlock(&kds_lock); + return; + } + + /* clear user pointer so we'll be the only + * thread handling the release */ + *pprset = NULL; + + for (i = 0; i < rset->num_resources; i++) + { + struct kds_resource * resource; + struct kds_link * it = NULL; + + /* fetch the previous entry on the linked list */ + it = list_entry(rset->resources[i].link.prev, struct kds_link, link); + /* unlink ourself */ + list_del(&rset->resources[i].link); + + /* any waiters? */ + if (list_empty(&it->link)) + continue; + + /* were we the head of the list? (head if prev is a resource) */ + if (it->parent != KDS_RESOURCE) + continue; + + /* we were the head, find the kds_resource */ + resource = container_of(it, struct kds_resource, waiters); + + if (rset->locked_resources) + { + resource->lock_count--; + } + + /* we know there is someone waiting from the any-waiters test above */ + + /* find the head of the waiting list */ + it = list_first_entry(&resource->waiters.link, struct kds_link, link); + + /* new exclusive owner? */ + if (it->state & KDS_LINK_EXCLUSIVE) + { + /* link now triggered */ + it->state |= KDS_LINK_TRIGGERED; + /* a parent to update? */ + if (it->parent != KDS_IGNORED) + { + if (0 == --it->parent->pending) + { + /* new owner now triggered, track for callback later */ + list_add(&it->parent->callback_link, &triggered); + } + } + } + /* exclusive releasing ? */ + else if (rset->resources[i].state & KDS_LINK_EXCLUSIVE) + { + /* trigger non-exclusive until end-of-list or first exclusive */ + list_for_each_entry(it, &resource->waiters.link, link) + { + /* exclusive found, stop triggering */ + if (it->state & KDS_LINK_EXCLUSIVE) + break; + + it->state |= KDS_LINK_TRIGGERED; + /* a parent to update? */ + if (it->parent != KDS_IGNORED) + { + if (0 == --it->parent->pending) + { + /* new owner now triggered, track for callback later */ + list_add(&it->parent->callback_link, &triggered); + } + } + } + } + + } + + mutex_unlock(&kds_lock); + + while (!list_empty(&triggered)) + { + it = list_first_entry(&triggered, struct kds_resource_set, callback_link); + list_del(&it->callback_link); + kds_callback_perform(it); + } + + cancel_work_sync(&rset->callback_work); + + /* free the resource set */ + kfree(rset); +} +EXPORT_SYMBOL(kds_resource_set_release); + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("ARM Ltd."); +MODULE_VERSION("1.0"); diff --git a/include/linux/kds.h b/include/linux/kds.h new file mode 100644 index 0000000..65e5706 --- /dev/null +++ b/include/linux/kds.h @@ -0,0 +1,154 @@ +/* + * + * (C) COPYRIGHT 2012 ARM Limited. All rights reserved. + * + * This program is free software and is provided to you under the terms of the GNU General Public License version 2 + * as published by the Free Software Foundation, and any use by you of this program is subject to the terms of such GNU licence. + * + * A copy of the licence is included with the program, and can also be obtained from Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * + */ + + + +#ifndef _KDS_H_ +#define _KDS_H_ + +#include <linux/list.h> +#include <linux/workqueue.h> + +#define KDS_WAIT_BLOCKING (ULONG_MAX) + +/* what to do when waitall must wait for a synchronous locked resource: */ +#define KDS_FLAG_LOCKED_FAIL (0u << 0) /* fail waitall */ +#define KDS_FLAG_LOCKED_IGNORE (1u << 0) /* don't wait, but block other that waits */ +#define KDS_FLAG_LOCKED_WAIT (2u << 0) /* wait (normal */ +#define KDS_FLAG_LOCKED_ACTION (3u << 0) /* mask to extract the action to do on locked resources */ + +struct kds_resource_set; + +typedef void (*kds_callback_fn) (void * callback_parameter, void * callback_extra_parameter); + +struct kds_callback +{ + kds_callback_fn user_cb; /* real cb */ + int direct; /* do direct or queued call? */ + struct workqueue_struct * wq; +}; + +struct kds_link +{ + struct kds_resource_set * parent; + struct list_head link; + unsigned long state; +}; + +struct kds_resource +{ + struct kds_link waiters; + unsigned long lock_count; +}; + +/* callback API */ + +/* Initialize a callback object. + * + * Typically created per context or per hw resource. + * + * Callbacks can be performed directly if no nested locking can + * happen in the client. + * + * Nested locking can occur when a lock is held during the kds_async_waitall or + * kds_resource_set_release call. If the callback needs to take the same lock + * nested locking will happen. + * + * If nested locking could happen non-direct callbacks can be requested. + * Callbacks will then be called asynchronous to the triggering call. + */ +int kds_callback_init(struct kds_callback * cb, int direct, kds_callback_fn user_cb); + +/* Terminate the use of a callback object. + * + * If the callback object was set up as non-direct + * any pending callbacks will be flushed first. + * Note that to avoid a deadlock the lock callbacks needs + * can't be held when a callback object is terminated. + */ +void kds_callback_term(struct kds_callback * cb); + + +/* resource object API */ + +/* initialize a resource handle for a shared resource */ +void kds_resource_init(struct kds_resource * resource); + +/* + * Will assert if the resource is being used or waited on. + * The caller should NOT try to terminate a resource that could still have clients. + * After the function returns the resource is no longer known by kds. + */ +void kds_resource_term(struct kds_resource * resource); + +/* Asynchronous wait for a set of resources. + * Callback will be called when all resources are available. + * If all the resources was available the callback will be called before kds_async_waitall returns. + * So one must not hold any locks the callback code-flow can take when calling kds_async_waitall. + * Caller considered to own/use the resources until \a kds_rset_release is called. + * flags is one or more of the KDS_FLAG_* set. + * exclusive_access_bitmap is a bitmap where a high bit means exclusive access while a low bit means shared access. + * Use the Linux __set_bit API, where the index of the buffer to control is used as the bit index. + * + * Standard Linux error return value. + */ +int kds_async_waitall( + struct kds_resource_set ** pprset, + unsigned long flags, + struct kds_callback * cb, + void * callback_parameter, + void * callback_extra_parameter, + int number_resources, + unsigned long * exclusive_access_bitmap, + struct kds_resource ** resource_list); + +/* Synchronous wait for a set of resources. + * Function will return when one of these have happened: + * - all resources have been obtained + * - timeout lapsed while waiting + * - a signal was received while waiting + * + * Caller considered to own/use the resources when the function returns. + * Caller must release the resources using \a kds_rset_release. + * + * Calling this function while holding already locked resources or other locking primitives is dangerous. + * One must if this is needed decide on a lock order of the resources and/or the other locking primitives + * and always take the resources/locking primitives in the specific order. + * + * Use the ERR_PTR framework to decode the return value. + * NULL = time out + * If IS_ERR then PTR_ERR gives: + * ERESTARTSYS = signal received, retry call after signal + * all other values = internal error, lock failed + * Other values = successful wait, now the owner, must call kds_resource_set_release + */ +struct kds_resource_set * kds_waitall( + int number_resources, + unsigned long * exclusive_access_bitmap, + struct kds_resource ** resource_list, + unsigned long jifies_timeout); + +/* Release resources after use. + * Caller must handle that other async callbacks will trigger, + * so must avoid holding any locks a callback will take. + * + * The function takes a pointer to your poiner to handle a race + * between a cancelation and a completion. + * + * If the caller can't guarantee that a race can't occur then + * the passed in pointer must be the same in both call paths + * to allow kds to manage the potential race. + */ +void kds_resource_set_release(struct kds_resource_set ** pprset); + +#endif /* _KDS_H_ */ +

14 years, 2 months

[PATCH] dma-buf: fix disabled vmap function

by Dave Airlie

From: Dave Airlie <airlied(a)redhat.com> include/linux/dma-buf.h: In function ‘dma_buf_vmap’: include/linux/dma-buf.h:260:1: warning: no return statement in function returning non-void [-Wreturn-type] Reported-by: wfg(a)linux.intel.com Signed-off-by: Dave Airlie <airlied(a)redhat.com> --- include/linux/dma-buf.h | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index d8c2865..506bb7b 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -257,6 +257,7 @@ static inline void dma_buf_kunmap(struct dma_buf *dmabuf, static inline void *dma_buf_vmap(struct dma_buf *dmabuf) { + return NULL; } static inline void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) -- 1.7.6

14 years, 2 months

Re: [Linaro-mm-sig] New "xf86-video-armsoc" DDX driver

by Dave Airlie

> > For the last few months we (ARM MPD... "The Mali guys") have been working on > getting X.Org up and running with Mali T6xx (ARM's next-generation GPU IP). > The approach is very similar (well identical I think) to how things work on > OMAP: We use a DRM driver to manage the display controller via KMS. The KMS > driver also allocates both scan-out and pixmap/back buffers via the > DRM_IOCTL_MODE_CREATE_DUMB ioctl which is internally implemented with GEM. > When returning buffers to DRI clients, the x-server uses flink to get a > global handle to a buffer which it passes back to the DRI client (in our > case the Mali-T600 X11 EGL winsys). The client then uses the new PRIME > ioctls to export the GEM buffer it received from the x-server to a dma_buf > fd. This fd is then passed into the T6xx kernel driver via our own job > dispatch user/kernel API (we're not using DRM for driving the GPU, only the > display controller). So using dumb in this was is probably a bit of an abuse, since dumb is defined to provide buffers not to be used for acceleration hw. Since when we allocate dumb buffers, we can't know what special hw layouts are required (tiling etc) for optimal performance for accel. The logic to work that out is rarely generic. > > http://git.linaro.org/gitweb?p=arm/xorg/driver/xf86-video-armsoc.git;a=summa > ry > > Note: When we originally spoke to Rob Clark about this, he suggested we take > the already-generic xf86-video-modesetting and just add the dri2 code to it. > This is indeed how we started out, however as we progressed it became clear > that the majority of the code we wanted was in the omap driver and were > having to work fairly hard to keep some of the original modesetting code. > This is why we've now changed tactic and just forked the OMAP driver, > something Rob is more than happy for us to do. It does seem like porting to -modesetting, and maybe cleaning up modesetting if its needs it. The modesetting driver is pretty much just a make it work port of the radeon/nouveau/intel code "shared" code. > One thing the DDX driver isn't doing yet is making use of 2D hw blocks. In > the short-term, we will simply create a branch off of the "generic" master > for each SoC and add 2D hardware support there. We do however want a more > permanent solution which doesn't need a separate branch per SoC. Some of the > suggested solutions are: > > * Add a new generic DRM ioctl API for larger 2D operations (I would imagine > small blits/blends would be done in SW). Not going to happen, again the hw isn't generic in this area, some hw requires 3D engines to do 2D ops etc. The limitations on some hw with overlaps etc, and finally it breaks the rule about generic ioctls for acceleration operations. > * Use SW rendering for everything other than solid blits and use v4l2's > blitting API for those (importing/exporting buffers to be blitted using > dma_buf). The theory here is that most UIs are rendered with GLES and so you > only need 2D hardware for blits. I think we'll prototype this approach on > Exynos. Seems a bit over the top, > * Define a new x-server sub-module interface to allow a seperate .so 2D > driver to be loaded (this is the approach the current OMAP DDX uses). This seems the sanest. I haven't time this week to review the code, but I'll try and take a look when time permits. Dave.

14 years, 2 months

[PATCH] dma-buf: minor documentation fixes.

by Sumit Semwal

Some minor inline documentation fixes for gaps resulting from new patches. Signed-off-by: Sumit Semwal <sumit.semwal(a)ti.com> --- drivers/base/dma-buf.c | 9 +++++---- include/linux/dma-buf.h | 3 +++ 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c index c3c88b0..24e88fe 100644 --- a/drivers/base/dma-buf.c +++ b/drivers/base/dma-buf.c @@ -429,7 +429,7 @@ EXPORT_SYMBOL_GPL(dma_buf_kunmap); /** * dma_buf_mmap - Setup up a userspace mmap with the given vma - * @dma_buf: [in] buffer that should back the vma + * @dmabuf: [in] buffer that should back the vma * @vma: [in] vma for the mmap * @pgoff: [in] offset in pages where this mmap should start within the * dma-buf buffer. @@ -470,8 +470,9 @@ int dma_buf_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma, EXPORT_SYMBOL_GPL(dma_buf_mmap); /** - * dma_buf_vmap - Create virtual mapping for the buffer object into kernel address space. Same restrictions as for vmap and friends apply. - * @dma_buf: [in] buffer to vmap + * dma_buf_vmap - Create virtual mapping for the buffer object into kernel + * address space. Same restrictions as for vmap and friends apply. + * @dmabuf: [in] buffer to vmap * * This call may fail due to lack of virtual mapping address space. * These calls are optional in drivers. The intended use for them @@ -491,7 +492,7 @@ EXPORT_SYMBOL_GPL(dma_buf_vmap); /** * dma_buf_vunmap - Unmap a vmap obtained by dma_buf_vmap. - * @dma_buf: [in] buffer to vmap + * @dmabuf: [in] buffer to vunmap */ void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) { diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index a02b1ff..eb48f38 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -65,6 +65,9 @@ struct dma_buf_attachment; * mapping needs to be coherent - if the exporter doesn't directly * support this, it needs to fake coherency by shooting down any ptes * when transitioning away from the cpu domain. + * @vmap: [optional] creates a virtual mapping for the buffer into kernel + * address space. Same restrictions as for vmap and friends apply. + * @vunmap: [optional] unmaps a vmap from the buffer */ struct dma_buf_ops { int (*attach)(struct dma_buf *, struct device *, -- 1.7.9.5

14 years, 2 months

[PATCH] dma-buf: add get_dma_buf()

by Rob Clark

From: Rob Clark <rob(a)ti.com> Works in a similar way to get_file(), and is needed in cases such as when the exporter needs to also keep a reference to the dmabuf (that is later released with a dma_buf_put()), and possibly other similar cases. Signed-off-by: Rob Clark <rob(a)ti.com> --- include/linux/dma-buf.h | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h index cbdff81..25eb287 100644 --- a/include/linux/dma-buf.h +++ b/include/linux/dma-buf.h @@ -132,6 +132,20 @@ struct dma_buf_attachment { void *priv; }; +/** + * get_dma_buf - convenience wrapper for get_file. + * @dmabuf: [in] pointer to dma_buf + * + * Increments the reference count on the dma-buf, needed in case of drivers + * that either need to create additional references to the dmabuf on the + * kernel side. For example, an exporter that needs to keep a dmabuf ptr + * so that subsequent exports don't create a new dmabuf. + */ +static inline void get_dma_buf(struct dma_buf *dmabuf) +{ + get_file(dmabuf->file); +} + #ifdef CONFIG_DMA_SHARED_BUFFER struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, struct device *dev); -- 1.7.5.4

14 years, 2 months

[PATCH] dma-buf: add initial vmap documentation

by Dave Airlie

From: Dave Airlie <airlied(a)redhat.com> Signed-off-by: Dave Airlie <airlied(a)redhat.com> --- Documentation/dma-buf-sharing.txt | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 3bbd5c5..98e9fa0 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -300,6 +300,17 @@ Access to a dma_buf from the kernel context involves three steps: Note that these calls need to always succeed. The exporter needs to complete any preparations that might fail in begin_cpu_access. + For some circumstances the overhead of kmap can be too high, a vmap interface + is introduced. This interface shouldn't be used very carefully, as vmalloc + space is a limited resources on many architectures. + + Interfaces: + void *dma_buf_vmap(struct dma_buf *dmabuf) + void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) + + This call can fail if there is no vmap support in the exporter, or if it + runs out of vmalloc space. Fallback to kmap should be implemented. + 3. Finish access When the importer is done accessing the range specified in begin_cpu_access, -- 1.7.6

14 years, 2 months

[RFC 00/13] Support for dmabuf exporting for videobuf2

by Tomasz Stanislawski

Hello everyone, The patches adds support for DMABUF [1] exporting to V4L2 stack. It was updated from [7] after Laurent Pinchart's review. The previous patchset was split into two parts. The support for DMABUF importing was posted in [2]. The exporter part is dependant on DMA mapping redesign [3] which is not merged into the mainline. Therefore it is posted as a separate patchset. This patchset is rebased on 3.4-rc1 plus the following patchsets: - support for DMABUF importing in V4L2 [2] - DMA mapping redesign [3] - support for dma_get_pages extension [4] - support for vmap extension to dmabuf framework by Dave Airlie [5][6] [1] https://lkml.org/lkml/2011/12/26/29 [2] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/46586 [3] http://thread.gmane.org/gmane.linux.kernel.cross-arch/12819 [4] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/4379… [5] http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/46713 [6] http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-dmabuf2&id=c481a54… [7] http://thread.gmane.org/gmane.comp.video.dri.devel/66213 Marek Szyprowski (1): v4l: vb2-dma-contig: let mmap method to use dma_mmap_coherent call Tomasz Stanislawski (12): v4l: add buffer exporting via dmabuf v4l: vb2: add buffer exporting via dmabuf v4l: vb2-dma-contig: add setup of sglist for MMAP buffers v4l: vb2-dma-contig: add support for DMABUF exporting v4l: vb2-dma-contig: add vmap/kmap for dmabuf exporting v4l: vb2-dma-contig: change map/unmap behaviour for importers v4l: vb2-dma-contig: change map/unmap behaviour for exporters v4l: s5p-tv: mixer: support for dmabuf importing v4l: s5p-tv: mixer: support for dmabuf exporting v4l: fimc: support for dmabuf importing v4l: fimc: support for dmabuf exporting v4l: vivi: support for dmabuf exporting drivers/media/video/Kconfig | 1 + drivers/media/video/s5p-fimc/fimc-capture.c | 11 ++- drivers/media/video/s5p-tv/Kconfig | 1 + drivers/media/video/s5p-tv/mixer_video.c | 12 ++- drivers/media/video/v4l2-compat-ioctl32.c | 1 + drivers/media/video/v4l2-ioctl.c | 7 + drivers/media/video/videobuf2-core.c | 66 ++++++++ drivers/media/video/videobuf2-dma-contig.c | 224 +++++++++++++++++++++++++- drivers/media/video/vivi.c | 9 + include/linux/videodev2.h | 23 +++ include/media/v4l2-ioctl.h | 2 + include/media/videobuf2-core.h | 2 + 12 files changed, 348 insertions(+), 11 deletions(-) -- 1.7.5.4

14 years, 2 months

New "xf86-video-armsoc" DDX driver

by Tom Cooksey

Hi All, For the last few months we (ARM MPD... "The Mali guys") have been working on getting X.Org up and running with Mali T6xx (ARM's next-generation GPU IP). The approach is very similar (well identical I think) to how things work on OMAP: We use a DRM driver to manage the display controller via KMS. The KMS driver also allocates both scan-out and pixmap/back buffers via the DRM_IOCTL_MODE_CREATE_DUMB ioctl which is internally implemented with GEM. When returning buffers to DRI clients, the x-server uses flink to get a global handle to a buffer which it passes back to the DRI client (in our case the Mali-T600 X11 EGL winsys). The client then uses the new PRIME ioctls to export the GEM buffer it received from the x-server to a dma_buf fd. This fd is then passed into the T6xx kernel driver via our own job dispatch user/kernel API (we're not using DRM for driving the GPU, only the display controller). Note: ARM doesn't generally provide the display controller IP block, so this is really for our customers/Linaro to develop, though we do have something hacked up for ARM's own PL111 display controller on our Versatile Express development platform which we'll be open sourcing/up-streaming asap via Linaro. We believe most ARM SoCs are likely to work the same way, at least those with 3rd-party GPU IP blocks/drivers (so everyone except Qualcomm & nVidia). As mentioned, this is certainly how the OMAP integration works. As such, we've taken the OMAP DDX driver Rob Clark wrote and hacked on it to make it work for Mali. The patch is actually relatively small, which is not really too surprising as all the driver is doing is allocating buffers and managing a display controller via a device-agnostic interface (KMS). All the device-specific code is kept in the DRM driver and the client GLES/EGL library. Given that the DDX driver doesn't contain any device-specific code, we're going to take the OMAP DDX as a baseline and try and make it more generic. Our immediate goals are to make it work on our own Versatile Express development platform and on Samsung's Exynos 5250 SoC, however our hope is to have a single DDX driver which can cover OMAP, Exynos, ST-E's Nova/Thor platforms and probably others too. It's even been suggested it could work with Mesa's sw backend(?). Anyway, the DDX is very much a work-in-progress and is still heavily branded OMAP, even though it's working (almost) perfectly on VExpress & Exynos too (re-branding isn't too high-up our priority list at the moment). We are actively developing this driver and will be doing so in a public git repository hosted by Linaro. We will not be maintaining any private repository behind ARM's firewall or anything like that - you'll see what we see. The first patches have now been pushed, so if anyone's interested in seeing what we have so far or wants to track development, the tree is here: http://git.linaro.org/gitweb?p=arm/xorg/driver/xf86-video-armsoc.git;a=summa ry Note: When we originally spoke to Rob Clark about this, he suggested we take the already-generic xf86-video-modesetting and just add the dri2 code to it. This is indeed how we started out, however as we progressed it became clear that the majority of the code we wanted was in the omap driver and were having to work fairly hard to keep some of the original modesetting code. This is why we've now changed tactic and just forked the OMAP driver, something Rob is more than happy for us to do. One thing the DDX driver isn't doing yet is making use of 2D hw blocks. In the short-term, we will simply create a branch off of the "generic" master for each SoC and add 2D hardware support there. We do however want a more permanent solution which doesn't need a separate branch per SoC. Some of the suggested solutions are: * Add a new generic DRM ioctl API for larger 2D operations (I would imagine small blits/blends would be done in SW). * Use SW rendering for everything other than solid blits and use v4l2's blitting API for those (importing/exporting buffers to be blitted using dma_buf). The theory here is that most UIs are rendered with GLES and so you only need 2D hardware for blits. I think we'll prototype this approach on Exynos. * Define a new x-server sub-module interface to allow a seperate .so 2D driver to be loaded (this is the approach the current OMAP DDX uses). We are hoping someone might have some advice & suggestions on how to proceed with regards to 2D. We're also very interested in any feedback, both on the DDX driver specifically and on the approach we're taking in general. Cheers, Tom

14 years, 2 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig