diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 8dfc670..7033c56 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -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
diff --git a/Documentation/virtual-contiguous-memory.txt b/Documentation/virtual-contiguous-memory.txt
new file mode 100644
index 0000000..9793a86
--- /dev/null
+++ b/Documentation/virtual-contiguous-memory.txt
@@ -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.
diff --git a/include/linux/vcm-drv.h b/include/linux/vcm-drv.h
new file mode 100644
index 0000000..d7ae660
--- /dev/null
+++ b/include/linux/vcm-drv.h
@@ -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
diff --git a/include/linux/vcm.h b/include/linux/vcm.h
new file mode 100644
index 0000000..965dc9b
--- /dev/null
+++ b/include/linux/vcm.h
@@ -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
diff --git a/mm/Kconfig b/mm/Kconfig
index ae35744..7f0e4b1 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -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
 #
diff --git a/mm/Makefile b/mm/Makefile
index 9bd9f8f..b96a6cb 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -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
diff --git a/mm/vcm.c b/mm/vcm.c
new file mode 100644
index 0000000..1389ee6
--- /dev/null
+++ b/mm/vcm.c
@@ -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);
