@@ -342,6 +342,8 @@ video-output.txt
- sysfs class driver interface to enable/disable a video output device.
video4linux/
- directory with info regarding video/TV/radio cards and linux.
+virtual-contiguous-memory.txt
+ - documentation on virtual contiguous memory manager framework.
vm/
- directory with info on the Linux vm code.
volatile-considered-harmful.txt
new file mode 100644
@@ -0,0 +1,720 @@
+ -*- org -*-
+
+This document covers how to use the Virtual Contiguous Memory framework
+(VCM), how the implementation works, and how to implement MMU drivers
+that can be plugged into VCM. It also contains a rationale for VCM.
+
+* The Virtual Contiguous Memory Manager
+
+The VCM was built to solve the system-wide memory mapping issues that
+occur when many bus-masters have IOMMUs.
+
+An IOMMU maps device addresses to physical addresses. It also
+insulates the system from spurious or malicious device bus
+transactions and allows fine-grained mapping attribute control. The
+Linux kernel core does not contain a generic API to handle IOMMU
+mapped memory; device driver writers must implement device specific
+code to interoperate with the Linux kernel core. As the number of
+IOMMUs increases, coordinating the many address spaces mapped by all
+discrete IOMMUs becomes difficult without in-kernel support.
+
+The VCM API enables device independent IOMMU control, virtual memory
+manager (VMM) interoperation and non-IOMMU enabled device
+interoperation by treating devices with or without IOMMUs and all CPUs
+with or without MMUs, their mapping contexts and their mappings using
+common abstractions. Physical hardware is given a generic device type
+and mapping contexts are abstracted into Virtual Contiguous Memory
+(VCM) regions. Users "reserve" memory from VCMs and "bind" their
+reservations with physical memory.
+
+If drivers limit their use of VCM contexts to a some subset of VCM
+functionality, they can work with no changes with or without MMU.
+
+** Why the VCM is Needed
+
+Driver writers who control devices with IOMMUs must contend with
+device control and memory management. Driver writers have a large
+device driver API that they can leverage to control their devices, but
+they are lacking a unified API to help them program mappings into
+IOMMUs and share those mappings with other devices and CPUs in the
+system.
+
+Sharing is complicated by Linux's CPU-centric VMM. The CPU-centric
+model generally makes sense because average hardware only contains
+a MMU for the CPU and possibly a graphics MMU. If every device in the
+system has one or more MMUs the CPU-centric memory management (MM)
+programming model breaks down.
+
+Abstracting IOMMU device programming into a common API has already
+begun in the Linux kernel. It was built to abstract the difference
+between AMD and Intel IOMMUs to support x86 virtualization on both
+platforms. The interface is listed in include/linux/iommu.h. It
+contains interfaces for mapping and unmapping as well as domain
+management. This interface has not gained widespread use outside the
+x86; PA-RISC, Alpha and SPARC architectures and ARM and PowerPC
+platforms all use their own mapping modules to control their IOMMUs.
+The VCM contains an IOMMU programming layer, but since its
+abstraction supports map management independent of device control, the
+layer is not used directly. This higher-level view enables a new
+kernel service, not just an IOMMU interoperation layer.
+
+** The General Idea: Map Management using Graphs
+
+Looking at mapping from a system-wide perspective reveals a general
+graph problem. The VCM's API is built to manage the general mapping
+graph. Each node that talks to memory, either through an MMU or
+directly (physically mapped) can be thought of as the device-end of
+a mapping edge. The other edge is the physical memory (or
+intermediate virtual space) that is mapped. The figure below shows
+an example three with CPU and a few devices connected to the memory
+directly or through a MMU.
+
++--------------------------------------------------------------------+
+| Memory |
++--------------------------------------------------------------------+
+ |
+ +------------------+-----------+-------+----------+-----------+
+ | | | | |
++-----+ +-----+ +-----+ +--------+ +--------+
+| MMU | | MMU | | MMU | | Device | | Device |
++-----+ +-----+ +-----+ +--------+ +--------+
+ | | |
++-----+ +-------+---+-----.... +-----+
+| CPU | | | | GPU |
++-----+ +--------+ +--------+ +-----+
+ | Device | | Device | ...
+ +--------+ +--------+
+
+For each MMU in the system a VCM context is created through an through
+which drivers can make reservations and bind virtual addresses to
+physical space. In the direct-mapped case the device is assigned
+a one-to-one MMU (as shown on the figure below). This scheme allows
+direct mapped devices to participate in general graph management.
+
++--------------------------------------------------------------------+
+| Memory |
++--------------------------------------------------------------------+
+ |
+ +------------------+-----------+-------+----------------+
+ | | | |
++-----+ +-----+ +-----+ +------------+
+| MMU | | MMU | | MMU | | One-to-One |
++-----+ +-----+ +-----+ +------------+
+ | | | |
++-----+ +-------+---+-----.... +-----+ +-----+-----+
+| CPU | | | | GPU | | |
++-----+ +--------+ +--------+ +-----+ +--------+ +--------+
+ | Device | | Device | ... | Device | | Device |
+ +--------+ +--------+ +--------+ +--------+
+
+The CPU nodes can also be brought under the same mapping abstraction
+with the use of a light overlay on the existing VMM. This light
+overlay allows VCM-managed mappings to interoperate with the common
+API. The light overlay enables this without substantial modifications
+to the existing VMM.
+
+In addition to CPU nodes that are running Linux (and the VMM), remote
+CPU nodes that may be running other operating systems can be brought
+into the general abstraction. Routing all memory management requests
+from a remote node through the central memory management framework
+enables new features like system-wide memory migration. This feature
+may only be feasible for large buffers that are managed outside of the
+fast-path, but having remote allocation in a system enables features
+that are impossible to build without it.
+
+The fundamental objects that support graph-based map management are:
+Virtual Contiguous Memory contexts, reservations, and physical memory
+allocations.
+
+* Usage Overview
+
+In a nutshell, platform initialises VCM context for each MMU on the
+system and possibly one-to-one VCM contexts which are passed to device
+drivers. Later on, drivers make reservation of virtual address space
+from the VCM context. At this point no physical memory has been
+committed to the reservation. To bind physical memory with a
+reservation, physical memory is allocated (possibly discontiguous) and
+then bound to the reservation.
+
+Single physical allocation can be bound to several different
+reservations also from different VCM contexts. This allows for
+devices connected through different MMUs (or directly) to the memory
+banks to share physical memory buffers; this also lets it possible to
+map such memory into CPU's address space (be it kernel or user space)
+so that the same data can be accessed by the CPU.
+
+[[file:../include/linux/vcm.h][include/linux/vcm.h]] includes comments documenting each API.
+
+** Virtual Contiguous Memory context
+
+A Virtual Contiguous Memory context (VCM) abstracts an address space
+a device sees. A VCM is created with a VCM driver dependent call. It
+is destroyed with a call to:
+
+ void vcm_destroy(struct vcm *vcm);
+
+The newly created VCM instance can be passed to any function that needs to
+operate on or with a virtual contiguous memory region. All internals
+of the VCM driver and how the mappings are handled is hidden and VCM
+driver dependent.
+
+** Bindings
+
+If all that driver needs is allocate some physical space and map it
+into its address space, a vcm_make_binding() call can be used:
+
+ struct vcm_res *__must_check
+ vcm_make_binding(struct vcm *vcm, resource_size_t size,
+ unsigned alloc_flags, unsigned res_flags);
+
+This call allocates physical memory, reserves virtual address space
+and binds those together. If all those succeeds a reservation is
+returned which has physical memory associated with it.
+
+If driver does not require more complicated VCM functionality, it is
+desirable to use this function since it will work on both real MMUs
+and one-to-one mappings.
+
+To destroy created binding, vcm_destroy_binding() can be used:
+
+ void vcm_destroy_binding(struct vcm_res *res);
+
+** Physical memory
+
+Physical memory allocations are handled using the following functions:
+
+ struct vcm_phys *__must_check
+ vcm_alloc(struct vcm *vcm, resource_size_t size, unsigned flags);
+
+ void vcm_free(struct vcm_phys *phys);
+
+It is noteworthy that physical space allocation is done in the context
+of a VCM. This is especially important in case of one-to-one VCM
+contexts which cannot handle discontiguous physical memory.
+
+Also, depending on VCM context, the physical space may be allocated in
+parts of different sizes. For instance, if a given MMU supports
+16MiB, 1MiB, 64KiB and 4KiB pages, it is likely that vcm_alloc() in
+context of this MMU's driver will try to split into as few as possible
+parts of those sizes.
+
+In case of one-to-one VCM contexts, a physical memory allocated with
+the call to vcm_alloc() may be usable only with vcm_map() function.
+
+** Mappings
+
+The easiest way to map a physical space into virtual address space
+represented by VCM context is to use the vcm_map() function:
+
+ struct vcm_res *__must_check
+ vcm_map(struct vcm *vcm, struct vcm_phys *phys, unsigned flags);
+
+This functions reserves address space from VCM context and binds
+physical space to it. To reverse the process vcm_unmap() can be used:
+
+ void vcm_unmap(struct vcm_res *res);
+
+Similarly to vcm_make_binding(), Usage vcm_map() may be advantageous
+over the use of vcm_reserve() followed by vcm_bind(). This is not
+only true for one-to-one mapping but if it so happens that the call to
+vcm_map() request mapping of a physically contiguous space into kernel
+space, a direct mapping can be returned instead of creating a new one.
+
+In some cases, a reservation created with vcm_map() can be used only
+with the physical memory passed as the argument to vcm_map() (so if
+user chooses to call vcm_unbind() and then vcm_bind() on a different
+physical memory, the call may fail).
+
+** Reservations
+
+A reservation is a contiguous region allocated from a virtual address
+space represented by VCM context. Just after reservation is created,
+no physical memory needs to be is bound to it. To manage reservations
+following two functions are provided:
+
+ struct vcm_res *__must_check
+ vcm_reserve(struct vcm *vcm, resource_size_t size,
+ unsigned flags);
+
+ void vcm_unreserve(struct vcm_res *res);
+
+The first one creates a reservation of desired size, and the second
+one destroys it.
+
+** Binding memory
+
+To bind a physical memory into a reservation vcm_bind() function is
+used:
+
+ int __must_check vcm_bind(struct vcm_res *res,
+ struct vcm_phys *phys);
+
+When the binding is no longer needed, vcm_unbind() destroys the
+connection:
+
+ struct vcm_phys *vcm_unbind(struct vcm_res *res);
+
+** Activating mappings
+
+Unless a VCM context is activated, none of the bindings are actually
+guaranteed to be available. When device driver needs the mappings
+it need to call vcm_activate() function to guarantee that the mappings
+are sent to hardware MMU.
+
+ int __must_check vcm_activate(struct vcm *vcm);
+
+After VCM context is activated all further bindings (made with
+vcm_make_binding(), vcm_map() or vcm_bind()) will be updated so there
+is no need to call vcm_activate() after each binding is done or
+undone.
+
+To deactivate the VCM context vcm_deactivate() function is used:
+
+ void vcm_deactivate(struct vcm *vcm);
+
+Both of those functions can be called several times if all calls to
+vcm_activate() are paired with a later call to vcm_deactivate().
+
+** Device driver example
+
+The following is a simple, untested example of how platform and
+devices work together to use the VCM framework. Platform initialises
+contexts for each MMU in the systems, and through platform device data
+passes them to correct drivers.
+
+Device driver header file:
+
+ struct foo_platform_data {
+ /* ... */
+ struct vcm *vcm;
+ /* ... */
+ };
+
+Platform code:
+
+ static int plat_bar_vcm_init(void)
+ {
+ struct foo_platform_data *fpdata;
+ struct vcm *vcm;
+
+ vcm = vcm_baz_create(...);
+ if (IS_ERR(vcm))
+ return PTR_ERR(vcm);
+
+ fpdata = dev_get_platdata(&foo_device.dev);
+ fpdata->vcm = vcm;
+
+ /* ... */
+
+ return 0;
+ }
+
+Device driver implementation:
+
+ struct foo_private {
+ /* ... */
+ struct vcm_res *fw;
+ /* ... */
+ };
+
+ static inline struct vcm_res *__must_check
+ __foo_alloc(struct device *dev, size_t size)
+ {
+ struct foo_platform_data *pdata =
+ dev_get_platdata(dev);
+ return vcm_make_binding(pdata->vcm, size, 0, 0);
+ }
+
+ static inline void __foo_free(struct vcm_res *res)
+ {
+ vcm_destroy_binding(res);
+ }
+
+ static int foo_probe(struct device *dev)
+ {
+ struct foo_platform_data *pdata =
+ dev_get_platdata(dev);
+ struct foo_private *priv;
+
+ if (IS_ERR_OR_NULL(pdata->vcm))
+ return pdata->vcm ? PTR_ERR(pdata->vcm) : -EINVAL;
+
+ priv = kzalloc(sizeof *priv, GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ /* ... */
+
+ priv->fw = __foo_alloc(dev, 1 << 20);
+ if (IS_ERR(priv->fw)) {
+ kfree(priv);
+ return PTR_ERR(priv->fw);
+ }
+ /* copy firmware to fw */
+
+ vcm_activate(pdata->vcm);
+
+ dev->p = priv;
+
+ return 0;
+ }
+
+ static int foo_remove(struct device *dev)
+ {
+ struct foo_platform_data *pdata =
+ dev_get_platdata(dev);
+ struct foo_private *priv = dev->p;
+
+ /* ... */
+
+ vcm_deactivate(pdata->vcm);
+ __foo_free(priv->fw);
+
+ kfree(priv);
+
+ return 0;
+ }
+
+ static int foo_do_something(struct device *dev, /* ... */)
+ {
+ struct foo_platform_data *pdata =
+ dev_get_platdata(dev);
+ struct vcm_res *buf;
+ int ret;
+
+ buf = __foo_alloc(/* ... size ...*/);
+ if (IS_ERR(buf))
+ return ERR_PTR(buf);
+
+ /*
+ * buf->start is address visible from device's
+ * perspective.
+ */
+
+ /* ... set hardware up ... */
+
+ /* ... wait for completion ... */
+
+ __foo_free(buf);
+
+ return ret;
+ }
+
+In the above example only vcm_make_binding() function is used so that
+the above scheme will work not only for systems with MMU but also in
+case of one-to-one VCM context.
+
+** IOMMU and one-to-one contexts
+
+The following example demonstrates mapping IOMMU and one-to-one
+reservations to the same physical memory. For readability, error
+handling is not shown on the listings.
+
+First, each contexts needs to be created. A call used for creating
+context is dependent on the driver used. The following is just an
+example of how this could look like:
+
+ struct vcm *vcm_onetoone, *vcm_iommu;
+
+ vcm_onetoone = vcm_onetoone_create();
+ vcm_iommu = vcm_foo_mmu_create();
+
+Once contexts are created, physical space needs to be allocated,
+reservations made on each context and physical memory mapped to those
+reservations. Because there is a one-to-one context, the memory has
+to be allocated from its context. It's also best to map the memory in
+the single call using vcm_make_binding():
+
+ struct vcm_res *res_onetoone;
+
+ res_onetoone = vcm_make_binding(vcm_o2o, SZ_2MB | SZ_4K, 0, 0);
+
+What's left is map the space in the other context. If the reservation
+in the other two contexts won't be used for any other purpose then to
+reference the memory allocated in above, it's best to use vcm_map():
+
+ struct vcm_res *res_iommu;
+
+ res_iommu = vcm_map(vcm_iommu, res_onetoone->phys, 0);
+
+Once the bindings have been created, the contexts need to be activated
+to make sure that they are actually on the hardware. (In case of
+one-to-one mapping it's most likely a no-operation but it's still
+required by the VCM API so it must not be omitted.)
+
+ vcm_activate(vcm_onetoone);
+ vcm_activate(vcm_iommu);
+
+At this point, both reservations represent addresses in respective
+address space that is bound to the same physical memory. Devices
+connected through the MMU can access it, as well as devices connected
+directly to the memory banks. The bus address for the devices and
+virtual address for the CPU is available through the 'start' member of
+the vcm_res structure (ie. res_* objects above).
+
+Once the mapping is no longer used and memory no longer needed it can
+be freed as follows:
+
+ vcm_unmap(res_iommu);
+ vcm_destroy_binding(res_onetoone);
+
+If the contexts are not needed either, they can be disabled:
+
+ vcm_deactivate(vcm_iommu);
+ vcm_deactivate(vcm_onetoone);
+
+and than, even destroyed:
+
+ vcm_destroy(vcm_iommu);
+ vcm_destroy(vcm_onetoone);
+
+* Available drivers
+
+Not all drivers support all of the VCM functionality. What is always
+supported is:
+
+ vcm_free()
+ vcm_unbind()
+ vcm_unreserve()
+
+Even though, vcm_unbind() may leave virtual reservation in unusable
+state.
+
+The following VCM drivers are provided:
+
+** Real hardware drivers
+
+There are no real hardware drivers at this time.
+
+** One-to-One drivers
+
+As it has been noted, one-to-One drivers are limited in the sense that
+certain operations are very unlikely to succeed. In fact, it is often
+certain that some operations will fail. If your driver needs to be
+able to run with One-to-One driver you should limit operations to:
+
+ vcm_make_binding()
+ vcm_destroy_binding()
+
+unless the above are not enough, then the following two may be used as
+well:
+
+ vcm_map()
+ vcm_unmap()
+
+If one uses vcm_unbind() then vcm_bind() on the same reservation,
+physical memory pair should also work.
+
+There are no One-to-One drivers at this time.
+
+* Writing a VCM driver
+
+The core of VCM does not handle communication with the MMU. For this
+purpose a VCM driver is used. Its purpose is to manage virtual
+address space reservations, physical allocations as well as updating
+mappings in the hardware MMU.
+
+API designed for VCM drivers is described in the
+[[file:../include/linux/vcm-drv.h][include/linux/vcm-drv.h]] file so it might be a good idea to take a look
+inside.
+
+VCM provides API for three different kinds of drivers. The most
+basic is a core VCM which VCM use directly. Other then that, VCM
+provides two wrappers -- VCM MMU and VCM One-to-One -- which can be
+used to create drivers for real hardware VCM contexts and for
+One-to-One contexts.
+
+All of the drivers need to provide a context creation functions which
+will allocate memory, fill start address, size and pointer to driver
+operations, and then call an init function which fills rest of the
+fields and validates entered values.
+
+** Writing a core VCM driver
+
+The core driver needs to provide a context creation function as well
+as at least some of the following operations:
+
+ void (*cleanup)(struct vcm *vcm);
+
+ int (*alloc)(struct vcm *vcm, resource_size_t size,
+ struct vcm_phys **phys, unsigned alloc_flags,
+ struct vcm_res **res, unsigned res_flags);
+ struct vcm_res *(*res)(struct vcm *vcm, resource_size_t size,
+ unsigned flags);
+ struct vcm_phys *(*phys)(struct vcm *vcm, resource_size_t size,
+ unsigned flags);
+
+ void (*unreserve)(struct vcm_res *res);
+
+ struct vcm_res *(*map)(struct vcm *vcm, struct vcm_phys *phys,
+ unsigned flags);
+ int (*bind)(struct vcm_res *res, struct vcm_phys *phys);
+ void (*unbind)(struct vcm_res *res);
+
+ int (*activate)(struct vcm *vcm);
+ void (*deactivate)(struct vcm *vcm);
+
+All of the operations (expect for the alloc) may assume that all
+pointer arguments are not-NULL. (In case of alloc, if any argument is
+NULL it is either phys or res (never both).)
+
+*** Context creation
+
+To use a VCM driver a VCM context has to be provided which is bound to
+the driver. This is done by a driver-dependent call defined in it's
+header file. Such a call may take varyous arguments to configure the
+context of the MMU. Its prototype may look as follows:
+
+ struct vcm *__must_check vcm_samp_create(/* ... */);
+
+The driver will most likely define a structure encapsulating the vcm
+structure (in the usual way). The context creation function must
+allocate space for such a structure and initialise it correctly
+including all members of the vcm structure expect for activations.
+The activations member is initialised by calling:
+
+ struct vcm *__must_check vcm_init(struct vcm *vcm);
+
+This function also validates that all fields are set correctly.
+
+The driver field of the vcm structure must point to a structure with
+all operations supported by the driver.
+
+If everything succeeds, the function has to return pointer to the vcm
+structure inside the encapsulating structure. It is the pointer that
+will be passed to all of the driver's operations. On error,
+a pointer-error must be returned (ie. not NULL).
+
+The function might look something like the following:
+
+ struct vcm *__must_check vcm_foo_create(/* ... */)
+ {
+ struct vcm_foo *foo;
+ struct vcm *vcm;
+
+ foo = kzalloc(sizeof *foo, GFP_KERNEL);
+ if (!foo)
+ return ERR_PTR(-ENOMEM);
+
+ /* ... do stuff ... */
+
+ foo->vcm.start = /* ... */;
+ foo->vcm.size = /* ... */;
+ foo->vcm.driver = &vcm_foo_driver;
+
+ vcm = vcm_init(&foo->vcm);
+ if (IS_ERR(vcm)) {
+ /* ... error recovery ... */
+ kfree(foo);
+ }
+ return vcm;
+ }
+
+*** Cleaning up
+
+The cleanup operation is called when the VCM context is destroyed.
+Its purpose is to free all resources acquired when VCM context was
+created including the space for the context structure. If it is not
+given, the memory is freed using the kfree() function.
+
+*** Allocation and reservations
+
+If alloc operation is specified, res and phys operations are ignored.
+The observable behaviour of the alloc operation should mimic as
+closely as possible res and phys operations called one after the
+other.
+
+The reason for this operation is that in case of one-to-one VCM
+contexts, the driver may not be able to bind together arbitrary
+reservation with an arbitrary physical space. In one-to-one contexts,
+reservations and physical memory are tight together and need to be
+made at the same time to make binding possible.
+
+The alloc operation may be called with both, res and phys being set,
+or at most one of them being NULL.
+
+The res operation reserves virtual address space in the VCM context.
+The function must set the start and res_size members of the vcm_res
+structure -- all other fields are filled by the VCM framework.
+
+The phys operation allocates physical space which can later be bound
+to the reservation.
+
+Both phys and alloc callbacks need to provide a free callbakc along
+with the vc_phys structure, which will, as one may imagine, free
+allocated space when user calls vcm_free().
+
+All those operations may assume that size is a non-zero and divisible
+by PAGE_SIZE.
+
+*** Binding
+
+The map operation is optional and it joins res and bind operations
+together. Like alloc operation, this is provided because in case of
+one-to-one mappings, the VCM driver may be unable to bind together
+physical space with an arbitrary reservation.
+
+Moreover, in case of some VCM drivers, a mapping for given physical
+memory can already be present (ie. in case of using VMM).
+
+Reservation created with map operation does not have to be usable
+with any other physical space then the one provided when reservation
+was created.
+
+The bind operation binds given reservation with a given physical
+memory. The operation may assume that reservation given as an
+argument is not bound to any physical memory.
+
+Whichever of the two operation is used, the binding must be reflected
+on the hardware if the VCM context has been activated. If VCM context
+has not been activated this is not required.
+
+The vcm_map() function uses map operation if one is provided.
+Otherwise, it falls back to alloc or res operation followed by bind
+operation. If this is also not possible, -EOPNOTSUPP is returned.
+Similarly, vcm_bind() function uses the bind operation unless it is
+not provided in which case -EOPNOTSUPP is returned.
+
+Also, if alloc operation is not provided but map is, the
+vcm_make_binding() function will use phys and map operations.
+
+*** Freeing resources
+
+The unbind callback removes the binding between reservation and
+a physical memory. If unbind operation is not provided, VCM assumes
+that it is a no-operation.
+
+The unreserve callback releases a reservation as well as free
+allocated space for the vcm_res structure. It is required and if it
+is not provided vcm_unreserve() will generate a warning.
+
+*** Activation
+
+When VCM context is activated, the activate callback is called. It is
+called only once even if vcm_activate() is called several times on the
+same context.
+
+When VCM context is deactivated (that is, if for each call to
+vcm_activate(), vcm_deactivate() was called) the deactivate callback
+is called.
+
+When VCM context is activated, all bound reservations must be
+reflected on the hardware MMU (if any). Also, ofter activation, all
+calls to vcm_bind(), vcm_map() or vcm_make_binding() must
+automatically reflect new mappings on the hardware MMU.
+
+Neither of the operations are required and if missing, VCM will
+assume they are a no-operation and no warning will be generated.
+
+* Epilogue
+
+The initial version of the VCM framework was written by Zach Pfeffer
+<zpfeffer@codeaurora.org>. It was then redesigned and mostly
+rewritten by Michal Nazarewicz <m.nazarewicz@samsung.com>.
+
+The new version is still lacking a few important features. Most
+notably, no real hardware MMU has been implemented yet. This may be
+ported from original Zach's proposal.
+
+Also, support for VMM is lacking. This is another thing that can be
+ported from Zach's proposal.
new file mode 100644
@@ -0,0 +1,117 @@
+/*
+ * Virtual Contiguous Memory driver API header
+ * Copyright (c) 2010 by Samsung Electronics.
+ * Written by Michal Nazarewicz (m.nazarewicz@samsung.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License or (at your optional) any later version of the license.
+ */
+
+/*
+ * See Documentation/virtual-contiguous-memory.txt for details.
+ */
+
+#ifndef __LINUX_VCM_DRV_H
+#define __LINUX_VCM_DRV_H
+
+#include <linux/vcm.h>
+#include <linux/list.h>
+#include <linux/mutex.h>
+#include <linux/gfp.h>
+
+#include <linux/atomic.h>
+
+/**
+ * struct vcm_driver - the MMU driver operations.
+ * @cleanup: called when vcm objects is destroyed; if omitted,
+ * kfree() will be used.
+ * @alloc: callback function for allocating physical memory and
+ * reserving virtual address space; XXX FIXME: document;
+ * if set, @res and @alloc are ignored.
+ * @res: creates a reservation of virtual address space; XXX FIXME:
+ * document; if @alloc is provided this is ignored.
+ * @phys: allocates a physical memory; XXX FIXME: document; if @alloc
+ * is provided this is ignored.
+ * @unreserve: destroys a virtual address space reservation created by @alloc;
+ * required.
+ * @map: reserves address space and binds a physical memory to it.
+ * @bind: binds a physical memory to a reserved address space.
+ * @unbind: unbinds a physical memory from reserved address space.
+ * @activate: activates the context making all bindings active; once
+ * the context has been activated, this callback is not
+ * called again until context is deactivated and
+ * activated again (so if user calls vcm_activate()
+ * several times only the first call in sequence will
+ * invoke this callback).
+ * @deactivate: deactivates the context making all bindings inactive;
+ * call this callback always accompanies call to the
+ * @activate callback.
+ */
+struct vcm_driver {
+ void (*cleanup)(struct vcm *vcm);
+
+ int (*alloc)(struct vcm *vcm, resource_size_t size,
+ struct vcm_phys **phys, unsigned alloc_flags,
+ struct vcm_res **res, unsigned res_flags);
+ struct vcm_res *(*res)(struct vcm *vcm, resource_size_t size,
+ unsigned flags);
+ struct vcm_phys *(*phys)(struct vcm *vcm, resource_size_t size,
+ unsigned flags);
+
+ void (*unreserve)(struct vcm_res *res);
+
+ struct vcm_res *(*map)(struct vcm *vcm, struct vcm_phys *phys,
+ unsigned flags);
+ int (*bind)(struct vcm_res *res, struct vcm_phys *phys);
+ void (*unbind)(struct vcm_res *res);
+
+ int (*activate)(struct vcm *vcm);
+ void (*deactivate)(struct vcm *vcm);
+};
+
+/**
+ * struct vcm_phys - representation of allocated physical memory.
+ * @count: number of contiguous parts the memory consists of; if this
+ * equals one the whole memory block is physically contiguous;
+ * read only.
+ * @size: total size of the allocated memory; read only.
+ * @free: callback function called when memory is freed; internal.
+ * @bindings: how many virtual address space reservations this memory has
+ * been bound to; internal.
+ * @parts: array of @count parts describing each physically contiguous
+ * memory block that the whole area consists of; each element
+ * describes part's physical starting address in bytes
+ * (@parts->start), its size in bytes (@parts->size) and
+ * (optionally) pointer to first struct poge (@parts->page);
+ * read only.
+ */
+struct vcm_phys {
+ unsigned count;
+ resource_size_t size;
+
+ void (*free)(struct vcm_phys *phys);
+ atomic_t bindings;
+
+ struct vcm_phys_part {
+ phys_addr_t start;
+ struct page *page;
+ resource_size_t size;
+ } parts[0];
+};
+
+/**
+ * vcm_init() - initialises VCM context structure.
+ * @vcm: the VCM context to initialise.
+ *
+ * This function initialises the vcm structure created by a MMU driver
+ * when setting things up. It sets up all fields of the vcm structure
+ * expect for @vcm->start, @vcm->size and @vcm->driver which are
+ * validated by this function. If they have invalid value function
+ * produces warning and returns an error-pointer. If everything is
+ * fine, @vcm is returned.
+ */
+struct vcm *__must_check vcm_init(struct vcm *vcm);
+
+#endif
new file mode 100644
@@ -0,0 +1,275 @@
+/*
+ * Virtual Contiguous Memory header
+ * Copyright (c) 2010 by Samsung Electronics.
+ * Written by Michal Nazarewicz (m.nazarewicz@samsung.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License or (at your optional) any later version of the license.
+ */
+
+/*
+ * See Documentation/virtual-contiguous-memory.txt for details.
+ */
+
+#ifndef __LINUX_VCM_H
+#define __LINUX_VCM_H
+
+#include <linux/kref.h>
+#include <linux/compiler.h>
+
+struct vcm_driver;
+struct vcm_phys;
+
+/**
+ * struct vcm - A virtually contiguous memory context.
+ * @start: the smallest possible address available in this context.
+ * @size: size of available address space in bytes; internal, read
+ * only for MMU drivers.
+ * @activations: How many times context was activated; internal,
+ * read only for MMU drivers.
+ * @driver: driver handling this driver; internal.
+ *
+ * This structure represents a context of virtually contiguous memory
+ * managed by a MMU pointed by the @mmu pointer. This is the main
+ * structure used to interact with the VCM framework.
+ *
+ * Whenever driver wants to reserve virtual address space or allocate
+ * backing storage this pointer to this structure must be passed.
+ *
+ */
+struct vcm {
+ dma_addr_t start;
+ resource_size_t size;
+ atomic_t activations;
+ const struct vcm_driver *driver;
+};
+
+/**
+ * struct vcm_res - A reserved virtually contiguous address space.
+ * @start: bus address of the region in bytes; read only.
+ * @bound_size: number of bytes actually bound to the virtual address;
+ * read only.
+ * @res_size: size of the reserved address space in bytes; read only.
+ * @vcm: VCM context; internal, read only for MMU drivers.
+ * @phys: pointer to physical memory bound to this reservation; NULL
+ * if no physical memory is bound; read only.
+ *
+ * This structure represents a portion virtually contiguous address
+ * space reserved for use with the driver. Once address space is
+ * reserved a physical memory can be bound to it so that it will paint
+ * to real memory.
+ */
+struct vcm_res {
+ dma_addr_t start;
+ resource_size_t bound_size;
+ resource_size_t res_size;
+
+ struct vcm *vcm;
+ struct vcm_phys *phys;
+};
+
+
+/**
+ * vcm_destroy() - destroys a VCM context.
+ * @vcm: VCM to destroy.
+ */
+void vcm_destroy(struct vcm *vcm);
+
+/**
+ * vcm_make_binding() - allocates memory and binds it to virtual address space
+ * @vcm: VCM context to reserve virtual address space in
+ * @size: number of bytes to allocate; aligned up to a PAGE_SIZE
+ * @alloc_flags: additional allocator flags; see vcm_alloc() for
+ * description of those.
+ * @res_flags: additional reservation flags; see vcm_reserve() for
+ * description of those.
+ *
+ * This is a call that binds together three other calls:
+ * vcm_reserve(), vcm_alloc() and vcm_bind(). The purpose of this
+ * function is that on systems with no IO MMU separate calls to
+ * vcm_alloc() and vcm_reserve() may fail whereas when called together
+ * they may work correctly.
+ *
+ * This is a consequence of the fact that with no IO MMU the simulated
+ * virtual address must be the same as physical address, thus if first
+ * virtual address space were to be reserved and then physical memory
+ * allocated, both addresses may not match.
+ *
+ * With this call, a driver that simulates IO MMU may simply allocate
+ * a physical memory and when this succeeds create correct reservation.
+ *
+ * In short, if device drivers do not need more advanced MMU
+ * functionolities, they should limit themselves to this function
+ * since then the drivers may be easily ported to systems without IO
+ * MMU.
+ *
+ * To access the vcm_phys structure created by this call a phys field
+ * of returned vcm_res structure should be used.
+ *
+ * On error returns a pointer which yields true when tested with
+ * IS_ERR().
+ */
+struct vcm_res *__must_check
+vcm_make_binding(struct vcm *vcm, resource_size_t size,
+ unsigned alloc_flags, unsigned res_flags);
+
+/**
+ * vcm_map() - makes a reservation and binds physical memory to it
+ * @vcm: VCM context
+ * @phys: physical memory to bind.
+ * @flags: additional flags; see vcm_reserve() for description of
+ * those.
+ *
+ * This is a call that binds together two other calls: vcm_reserve()
+ * and vcm_bind(). If all you need is reserve address space and
+ * bind physical memory it's better to use this call since it may
+ * create better mappings in some situations.
+ *
+ * Drivers may be optimised in such a way that it won't be possible to
+ * use reservation with a different physical memory.
+ *
+ * On error returns a pointer which yields true when tested with
+ * IS_ERR().
+ */
+struct vcm_res *__must_check
+vcm_map(struct vcm *vcm, struct vcm_phys *phys, unsigned flags);
+
+/**
+ * vcm_alloc() - allocates a physical memory for use with vcm_res.
+ * @vcm: VCM context allocation is performed in.
+ * @size: number of bytes to allocate; aligned up to a PAGE_SIZE
+ * @flags: additional allocator flags; XXX FIXME: describe
+ *
+ * In case of some MMU drivers, the @vcm may be important and later
+ * binding (vcm_bind()) may fail if done on another @vcm.
+ *
+ * On success returns a vcm_phys structure representing an allocated
+ * physical memory that can be bound to reserved virtual address
+ * space. On error returns a pointer which yields true when tested with
+ * IS_ERR().
+ */
+struct vcm_phys *__must_check
+vcm_alloc(struct vcm *vcm, resource_size_t size, unsigned flags);
+
+/**
+ * vcm_free() - frees an allocated physical memory
+ * @phys: physical memory to free.
+ *
+ * If the physical memory is bound to any reserved address space it
+ * must be unbound first. Otherwise a warning will be issued and
+ * the memory won't be freed causing memory leaks.
+ */
+void vcm_free(struct vcm_phys *phys);
+
+/**
+ * vcm_reserve() - reserves a portion of virtual address space.
+ * @vcm: VCM context reservation is performed in.
+ * @size: number of bytes to allocate; aligned up to a PAGE_SIZE
+ * @flags: additional reservation flags; XXX FIXME: describe
+ * @alignment: required alignment of the reserved space; must be
+ * a power of two or zero.
+ *
+ * On success returns a vcm_res structure representing a reserved
+ * (contiguous) virtual address space that physical memory can be
+ * bound to (using vcm_bind()). On error returns a pointer which
+ * yields true when tested with IS_ERR().
+ */
+struct vcm_res *__must_check
+vcm_reserve(struct vcm *vcm, resource_size_t size, unsigned flags);
+
+/**
+ * vcm_unreserve() - destroyers a virtual address space reservation
+ * @res: reservation to destroy.
+ *
+ * If any physical memory is bound to the reserved address space it
+ * must be unbound first. Otherwise it will be unbound and warning
+ * will be issued.
+ */
+void vcm_unreserve(struct vcm_res *res);
+
+/**
+ * vcm_bind() - binds a physical memory to virtual address space
+ * @res: virtual address space to bind the physical memory.
+ * @phys: physical memory to bind to the virtual addresses.
+ *
+ * The mapping won't be active unless vcm_activate() on the VCM @res
+ * was created in context of was called.
+ *
+ * If @phys is already bound to @res this function returns -EALREADY.
+ * If some other physical memory is bound to @res -EADDRINUSE is
+ * returned. If size of the physical memory is larger then the
+ * virtual space -ENOSPC is returned. In all other cases the physical
+ * memory is bound to the virtual address and on success zero is
+ * returned, on error a negative number.
+ */
+int __must_check vcm_bind(struct vcm_res *res, struct vcm_phys *phys);
+
+/**
+ * vcm_unbind() - unbinds a physical memory from virtual address space
+ * @res: virtual address space to unbind the physical memory from.
+ *
+ * This reverses the effect of the vcm_bind() function. Function
+ * returns physical space that was bound to the reservation (or NULL
+ * if no space was bound in which case also a warning is issued).
+ */
+struct vcm_phys *vcm_unbind(struct vcm_res *res);
+
+/**
+ * vcm_destroy_binding() - destroys the binding
+ * @res: a bound reserved address space to destroy.
+ *
+ * This function incorporates three functions: vcm_unbind(),
+ * vcm_free() and vcm_unreserve() (in that order) in one call.
+ */
+void vcm_destroy_binding(struct vcm_res *res);
+
+/**
+ * vcm_unmap() - unbinds physical memory and unreserves address space
+ * @res: reservation to destroy
+ *
+ * This is a call that binds together two other calls: vcm_unbind()
+ * and vcm_unreserve().
+ */
+static inline void vcm_unmap(struct vcm_res *res)
+{
+ vcm_unbind(res);
+ vcm_unreserve(res);
+}
+
+/**
+ * vcm_activate() - activates bindings in VCM.
+ * @vcm: VCM to activate bindings in.
+ *
+ * All of the bindings on the @vcm done before this function is called
+ * are inactive and do not take effect. The call to this function
+ * guarantees that all bindings are sent to the hardware MMU (if any).
+ *
+ * After VCM is activated all bindings will be automatically updated
+ * on the hardware MMU, so there is no need to call this function
+ * after each vcm_bind()/vcm_unbind().
+ *
+ * Each call to vcm_activate() should be later accompanied by a call
+ * to vcm_deactivate(). Otherwise a warning will be issued when VCM
+ * context is destroyed (vcm_destroy()). This function can be called
+ * several times.
+ *
+ * On success returns zero, on error a negative error code.
+ */
+int __must_check vcm_activate(struct vcm *vcm);
+
+/**
+ * vcm_deactivate() - deactivates bindings in VCM.
+ * @vcm: VCM to deactivate bindings in.
+ *
+ * This function reverts effect of the vcm_activate() function. After
+ * calling this function caller has no guarantee that bindings defined
+ * in VCM are active.
+ *
+ * If this is called without calling the vcm_activate() warning is
+ * issued.
+ */
+void vcm_deactivate(struct vcm *vcm);
+
+#endif
@@ -338,6 +338,21 @@ config CMA_DEBUG
This is mostly used during development. If unsure, say "n".
+config VCM
+ bool "Virtual Contiguous Memory framework"
+ help
+ This enables the Virtual Contiguous Memory framework which
+ provides an abstraction for virtual address space provided by
+ various MMUs present on the platform.
+
+ The framework uses plugable MMU drivers for hardware MMUs and
+ if drivers obeys some limitations it can be also used on
+ platforms with no MMU.
+
+ For more information see
+ <Documentation/virtual-contiguous-memory.txt>. If unsure, say
+ "n".
+
#
# UP and nommu archs use km based percpu allocator
#
@@ -43,3 +43,4 @@ obj-$(CONFIG_HWPOISON_INJECT) += hwpoison-inject.o
obj-$(CONFIG_DEBUG_KMEMLEAK) += kmemleak.o
obj-$(CONFIG_DEBUG_KMEMLEAK_TEST) += kmemleak-test.o
obj-$(CONFIG_CMA) += cma.o
+obj-$(CONFIG_VCM) += vcm.o
new file mode 100644
@@ -0,0 +1,304 @@
+/*
+ * Virtual Contiguous Memory core
+ * Copyright (c) 2010 by Samsung Electronics.
+ * Written by Michal Nazarewicz (m.nazarewicz@samsung.com)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License or (at your optional) any later version of the license.
+ */
+
+/*
+ * See Documentation/virtual-contiguous-memory.txt for details.
+ */
+
+#include <linux/vcm-drv.h>
+#include <linux/module.h>
+#include <linux/mm.h>
+#include <linux/err.h>
+#include <linux/slab.h>
+
+/******************************** Devices API *******************************/
+
+void vcm_destroy(struct vcm *vcm)
+{
+ if (WARN_ON(atomic_read(&vcm->activations)))
+ vcm->driver->deactivate(vcm);
+
+ if (vcm->driver->cleanup)
+ vcm->driver->cleanup(vcm);
+ else
+ kfree(vcm);
+}
+EXPORT_SYMBOL_GPL(vcm_destroy);
+
+static void
+__vcm_alloc_and_reserve(struct vcm *vcm, resource_size_t size,
+ struct vcm_phys **phys, unsigned alloc_flags,
+ struct vcm_res **res, unsigned res_flags)
+{
+ int ret, alloc = 0;
+
+ if (WARN_ON(!vcm) || !size) {
+ ret = -EINVAL;
+ goto error;
+ }
+
+ size = PAGE_ALIGN(size);
+
+ if (vcm->driver->alloc) {
+ ret = vcm->driver->alloc(vcm, size,
+ phys, alloc_flags, res, res_flags);
+ if (ret)
+ goto error;
+ alloc = 1;
+ } else if ((res && !vcm->driver->res) || (phys && !vcm->driver->phys)) {
+ ret = -EOPNOTSUPP;
+ goto error;
+ }
+
+ if (res) {
+ if (!alloc) {
+ *res = vcm->driver->res(vcm, size, res_flags);
+ if (IS_ERR(*res)) {
+ ret = PTR_ERR(*res);
+ goto error;
+ }
+ }
+ (*res)->bound_size = 0;
+ (*res)->vcm = vcm;
+ (*res)->phys = NULL;
+ }
+
+ if (phys) {
+ if (!alloc) {
+ *phys = vcm->driver->phys(vcm, size, alloc_flags);
+ if (WARN_ON(!(*phys)->free))
+ phys = ERR_PTR(-EINVAL);
+ if (IS_ERR(*phys)) {
+ ret = PTR_ERR(*phys);
+ goto error;
+ }
+ }
+ atomic_set(&(*phys)->bindings, 0);
+ }
+
+ return;
+
+error:
+ if (phys)
+ *phys = ERR_PTR(ret);
+ if (res) {
+ if (*res)
+ vcm_unreserve(*res);
+ *res = ERR_PTR(ret);
+ }
+}
+
+struct vcm_res *__must_check
+vcm_make_binding(struct vcm *vcm, resource_size_t size,
+ unsigned alloc_flags, unsigned res_flags)
+{
+ struct vcm_phys *phys;
+ struct vcm_res *res;
+
+ if (WARN_ON(!vcm || !size || (size & (PAGE_SIZE - 1))))
+ return ERR_PTR(-EINVAL);
+ else if (vcm->driver->alloc || !vcm->driver->map) {
+ int ret;
+
+ __vcm_alloc_and_reserve(vcm, size, &phys, alloc_flags,
+ &res, res_flags);
+
+ if (IS_ERR(res))
+ return res;
+
+ ret = vcm_bind(res, phys);
+ if (!ret)
+ return res;
+
+ if (vcm->driver->unreserve)
+ vcm->driver->unreserve(res);
+ phys->free(phys);
+ return ERR_PTR(ret);
+ } else {
+ __vcm_alloc_and_reserve(vcm, size, &phys, alloc_flags,
+ NULL, 0);
+
+ if (IS_ERR(phys))
+ return ERR_CAST(res);
+
+ res = vcm_map(vcm, phys, res_flags);
+ if (IS_ERR(res))
+ phys->free(phys);
+
+ return res;
+ }
+}
+EXPORT_SYMBOL_GPL(vcm_make_binding);
+
+struct vcm_phys *__must_check
+vcm_alloc(struct vcm *vcm, resource_size_t size, unsigned flags)
+{
+ struct vcm_phys *phys;
+
+ __vcm_alloc_and_reserve(vcm, size, &phys, flags, NULL, 0);
+
+ return phys;
+}
+EXPORT_SYMBOL_GPL(vcm_alloc);
+
+struct vcm_res *__must_check
+vcm_reserve(struct vcm *vcm, resource_size_t size, unsigned flags)
+{
+ struct vcm_res *res;
+
+ __vcm_alloc_and_reserve(vcm, size, NULL, 0, &res, flags);
+
+ return res;
+}
+EXPORT_SYMBOL_GPL(vcm_reserve);
+
+struct vcm_res *__must_check
+vcm_map(struct vcm *vcm, struct vcm_phys *phys, unsigned flags)
+{
+ struct vcm_res *res;
+ int ret;
+
+ if (WARN_ON(!vcm))
+ return ERR_PTR(-EINVAL);
+
+ if (vcm->driver->map) {
+ res = vcm->driver->map(vcm, phys, flags);
+ if (!IS_ERR(res)) {
+ atomic_inc(&phys->bindings);
+ res->phys = phys;
+ res->bound_size = phys->size;
+ res->vcm = vcm;
+ }
+ return res;
+ }
+
+ res = vcm_reserve(vcm, phys->size, flags);
+ if (IS_ERR(res))
+ return res;
+
+ ret = vcm_bind(res, phys);
+ if (!ret)
+ return res;
+
+ vcm_unreserve(res);
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(vcm_map);
+
+void vcm_unreserve(struct vcm_res *res)
+{
+ if (!WARN_ON(!res)) {
+ if (WARN_ON(res->phys))
+ vcm_unbind(res);
+ if (!WARN_ON_ONCE(!res->vcm->driver->unreserve))
+ res->vcm->driver->unreserve(res);
+ }
+}
+EXPORT_SYMBOL_GPL(vcm_unreserve);
+
+void vcm_free(struct vcm_phys *phys)
+{
+ if (!WARN_ON(!phys || atomic_read(&phys->bindings)))
+ phys->free(phys);
+}
+EXPORT_SYMBOL_GPL(vcm_free);
+
+int __must_check vcm_bind(struct vcm_res *res, struct vcm_phys *phys)
+{
+ int ret;
+
+ if (WARN_ON(!res || !phys))
+ return -EINVAL;
+
+ if (res->phys == phys)
+ return -EALREADY;
+
+ if (res->phys)
+ return -EADDRINUSE;
+
+ if (phys->size > res->res_size)
+ return -ENOSPC;
+
+ if (!res->vcm->driver->bind)
+ return -EOPNOTSUPP;
+
+ ret = res->vcm->driver->bind(res, phys);
+ if (ret >= 0) {
+ atomic_inc(&phys->bindings);
+ res->phys = phys;
+ res->bound_size = phys->size;
+ }
+ return ret;
+}
+EXPORT_SYMBOL_GPL(vcm_bind);
+
+struct vcm_phys *vcm_unbind(struct vcm_res *res)
+{
+ struct vcm_phys *phys = NULL;
+ if (!WARN_ON(!res || !res->phys)) {
+ phys = res->phys;
+ if (res->vcm->driver->unbind)
+ res->vcm->driver->unbind(res);
+ WARN_ON(!atomic_add_unless(&phys->bindings, -1, 0));
+ res->phys = NULL;
+ res->bound_size = 0;
+ }
+ return phys;
+}
+EXPORT_SYMBOL_GPL(vcm_unbind);
+
+void vcm_destroy_binding(struct vcm_res *res)
+{
+ if (!WARN_ON(!res)) {
+ struct vcm_phys *phys = vcm_unbind(res);
+ if (phys)
+ vcm_free(phys);
+ vcm_unreserve(res);
+ }
+}
+EXPORT_SYMBOL_GPL(vcm_destroy_binding);
+
+int __must_check vcm_activate(struct vcm *vcm)
+{
+ if (WARN_ON(!vcm))
+ return -EINVAL;
+ else if (atomic_inc_return(&vcm->activations) != 1
+ || !vcm->driver->activate)
+ return 0;
+ else
+ return vcm->driver->activate(vcm);
+}
+EXPORT_SYMBOL_GPL(vcm_activate);
+
+void vcm_deactivate(struct vcm *vcm)
+{
+ if (!WARN_ON(!vcm || !atomic_read(&vcm->activations))
+ && atomic_dec_and_test(&vcm->activations)
+ && vcm->driver->deactivate)
+ vcm->driver->deactivate(vcm);
+}
+EXPORT_SYMBOL_GPL(vcm_deactivate);
+
+
+/****************************** VCM Drivers API *****************************/
+
+struct vcm *__must_check vcm_init(struct vcm *vcm)
+{
+ if (WARN_ON(!vcm || !vcm->size
+ || ((vcm->start | vcm->size) & ~PAGE_MASK)
+ || !vcm->driver || !vcm->driver->unreserve))
+ return ERR_PTR(-EINVAL);
+
+ atomic_set(&vcm->activations, 0);
+
+ return vcm;
+}
+EXPORT_SYMBOL_GPL(vcm_init);