Merge branch 'for-2.6.26' of...

include/linux/compile.h

include/linux/version.h

include/linux/utsrelease.h

include/linux/bounds.h

# stgit generated dirs

patches-*

Rui Saraiva <rmps@joel.ist.utl.pt>

Sachin P Sant <ssant@in.ibm.com>

Sam Ravnborg <sam@mars.ravnborg.org>

S.Çağlar Onur <caglar@pardus.org.tr>

Simon Kelley <simon@thekelleys.org.uk>

Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>

Stephen Hemminger <shemminger@osdl.org>

What:		/sys/class/bdi/<bdi>/

Date:		January 2008

Contact:	Peter Zijlstra <a.p.zijlstra@chello.nl>

Description:

Provide a place in sysfs for the backing_dev_info object.  This allows

setting and retrieving various BDI specific variables.

The <bdi> identifier can be either of the following:

MAJOR:MINOR

	Device number for block devices, or value of st_dev on

	non-block filesystems which provide their own BDI, such as NFS

	and FUSE.

default

	The default backing dev, used for non-block device backed

	filesystems which do not provide their own BDI.

Files under /sys/class/bdi/<bdi>/

---------------------------------

read_ahead_kb (read-write)

	Size of the read-ahead window in kilobytes

min_ratio (read-write)

	Under normal circumstances each device is given a part of the

	total write-back cache that relates to its current average

	writeout speed in relation to the other devices.

	The 'min_ratio' parameter allows assigning a minimum

	percentage of the write-back cache to a particular device.

	For example, this is useful for providing a minimum QoS.

max_ratio (read-write)

	Allows limiting a particular device to use not more than the

	given percentage of the write-back cache.  This is useful in

	situations where we want to avoid one device taking all or

	most of the write-back cache.  For example in case of an NFS

	mount that is prone to get stuck, or a FUSE mount which cannot

	be trusted to play fair.

int

dma_supported(struct device *dev, u64 mask)

int

pci_dma_supported(struct device *dev, u64 mask)

pci_dma_supported(struct pci_dev *hwdev, u64 mask)

Checks to see if the device can support DMA to the memory described by

mask.

dma_map_single(struct device *dev, void *cpu_addr, size_t size,

		      enum dma_data_direction direction)

dma_addr_t

pci_map_single(struct device *dev, void *cpu_addr, size_t size,

pci_map_single(struct pci_dev *hwdev, void *cpu_addr, size_t size,

		      int direction)

Maps a piece of processor virtual memory so it can be accessed by the

See also dma_map_single().

dma_addr_t

dma_map_single_attrs(struct device *dev, void *cpu_addr, size_t size,

		     enum dma_data_direction dir,

		     struct dma_attrs *attrs)

void

dma_unmap_single_attrs(struct device *dev, dma_addr_t dma_addr,

		       size_t size, enum dma_data_direction dir,

		       struct dma_attrs *attrs)

int

dma_map_sg_attrs(struct device *dev, struct scatterlist *sgl,

		 int nents, enum dma_data_direction dir,

		 struct dma_attrs *attrs)

void

dma_unmap_sg_attrs(struct device *dev, struct scatterlist *sgl,

		   int nents, enum dma_data_direction dir,

		   struct dma_attrs *attrs)

The four functions above are just like the counterpart functions

without the _attrs suffixes, except that they pass an optional

struct dma_attrs*.

struct dma_attrs encapsulates a set of "dma attributes". For the

definition of struct dma_attrs see linux/dma-attrs.h.

The interpretation of dma attributes is architecture-specific, and

each attribute should be documented in Documentation/DMA-attributes.txt.

If struct dma_attrs* is NULL, the semantics of each of these

functions is identical to those of the corresponding function

without the _attrs suffix. As a result dma_map_single_attrs()

can generally replace dma_map_single(), etc.

As an example of the use of the *_attrs functions, here's how

you could pass an attribute DMA_ATTR_FOO when mapping memory

for DMA:

#include <linux/dma-attrs.h>

/* DMA_ATTR_FOO should be defined in linux/dma-attrs.h and

 * documented in Documentation/DMA-attributes.txt */

...

	DEFINE_DMA_ATTRS(attrs);

	dma_set_attr(DMA_ATTR_FOO, &attrs);

	....

	n = dma_map_sg_attrs(dev, sg, nents, DMA_TO_DEVICE, &attr);

	....

Architectures that care about DMA_ATTR_FOO would check for its

presence in their implementations of the mapping and unmapping

routines, e.g.:

void whizco_dma_map_sg_attrs(struct device *dev, dma_addr_t dma_addr,

			     size_t size, enum dma_data_direction dir,

			     struct dma_attrs *attrs)

{

	....

	int foo =  dma_get_attr(DMA_ATTR_FOO, attrs);

	....

	if (foo)

		/* twizzle the frobnozzle */

	....

Part II - Advanced dma_ usage

-----------------------------

			DMA attributes

			==============

This document describes the semantics of the DMA attributes that are

defined in linux/dma-attrs.h.

DMA_ATTR_WRITE_BARRIER

----------------------

DMA_ATTR_WRITE_BARRIER is a (write) barrier attribute for DMA.  DMA

to a memory region with the DMA_ATTR_WRITE_BARRIER attribute forces

all pending DMA writes to complete, and thus provides a mechanism to

strictly order DMA from a device across all intervening busses and

bridges.  This barrier is not specific to a particular type of

interconnect, it applies to the system as a whole, and so its

implementation must account for the idiosyncracies of the system all

the way from the DMA device to memory.

As an example of a situation where DMA_ATTR_WRITE_BARRIER would be

useful, suppose that a device does a DMA write to indicate that data is

ready and available in memory.  The DMA of the "completion indication"

could race with data DMA.  Mapping the memory used for completion

indications with DMA_ATTR_WRITE_BARRIER would prevent the race.