Merge ../linux-2.6

S: USA

N: Tristan Greaves

E: Tristan.Greaves@icl.com

E: tmg296@ecs.soton.ac.uk

W: http://www.ecs.soton.ac.uk/~tmg296

E: tristan@extricate.org

W: http://www.extricate.org/

D: Miscellaneous ipv4 sysctl patches

S: 15 Little Mead

S: Denmead

S: Hampshire

S: PO7 6HS

S: United Kingdom

N: Michael A. Griffith

E: grif@cs.ucr.edu

S: Beaverton, Oregon 97005

S: USA

N: Marcelo W. Tosatti

E: marcelo.tosatti@cyclades.com

D: Miscellaneous kernel hacker

N: Marcelo Tosatti

E: marcelo@kvack.org

D: v2.4 kernel maintainer

D: Current pc300/cyclades maintainer

S: Cyclades Corporation

S: Av Cristovao Colombo, 462. Floresta.

S: Porto Alegre

S: Brazil

N: Stefan Traby

Consistent memory is memory for which a write by either the device or

the processor can immediately be read by the processor or device

without having to worry about caching effects.

without having to worry about caching effects.  (You may however need

to make sure to flush the processor's write buffers before telling

devices to read that memory.)

This routine allocates a region of <size> bytes of consistent memory.

it also returns a <dma_handle> which may be cast to an unsigned

reduce current DMA mapping usage or delay and try again later).

	int

dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,

	   enum dma_data_direction direction)

	dma_map_sg(struct device *dev, struct scatterlist *sg,

		int nents, enum dma_data_direction direction)

	int

	pci_map_sg(struct pci_dev *hwdev, struct scatterlist *sg,

		int nents, int direction)

aborting the request or even oopsing is better than doing nothing and

corrupting the filesystem.

With scatterlists, you use the resulting mapping like this:

	int i, count = dma_map_sg(dev, sglist, nents, direction);

	struct scatterlist *sg;

	for (i = 0, sg = sglist; i < count; i++, sg++) {

		hw_address[i] = sg_dma_address(sg);

		hw_len[i] = sg_dma_len(sg);

	}

where nents is the number of entries in the sglist.

The implementation is free to merge several consecutive sglist entries

into one (e.g. with an IOMMU, or if several pages just happen to be

physically contiguous) and returns the actual number of sg entries it

mapped them to. On failure 0, is returned.

Then you should loop count times (note: this can be less than nents times)

and use sg_dma_address() and sg_dma_len() macros where you previously

accessed sg->address and sg->length as shown above.

	void

dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nhwentries,

	     enum dma_data_direction direction)

	dma_unmap_sg(struct device *dev, struct scatterlist *sg,

		int nhwentries, enum dma_data_direction direction)

	void

	pci_unmap_sg(struct pci_dev *hwdev, struct scatterlist *sg,

		int nents, int direction)

something like __va().  [ EDIT: Update this when we integrate

Gerd Knorr's generic code which does this. ]

This rule also means that you may not use kernel image addresses

(ie. items in the kernel's data/text/bss segment, or your driver's)

nor may you use kernel stack addresses for DMA.  Both of these items

might be mapped somewhere entirely different than the rest of physical

memory.

This rule also means that you may use neither kernel image addresses

(items in data/text/bss segments), nor module image addresses, nor

stack addresses for DMA.  These could all be mapped somewhere entirely

different than the rest of physical memory.  Even if those classes of

memory could physically work with DMA, you'd need to ensure the I/O

buffers were cacheline-aligned.  Without that, you'd see cacheline

sharing problems (data corruption) on CPUs with DMA-incoherent caches.

(The CPU could write to one word, DMA would write to a different one

in the same cache line, and one of them could be overwritten.)

Also, this means that you cannot take the return of a kmap()

call and DMA to/from that.  This is similar to vmalloc().

             in order to get correct behavior on all platforms.

	     Also, on some platforms your driver may need to flush CPU write

	     buffers in much the same way as it needs to flush write buffers

	     found in PCI bridges (such as by reading a register's value

	     after writing it).

- Streaming DMA mappings which are usually mapped for one DMA transfer,

  unmapped right after it (unless you use pci_dma_sync_* below) and for which

  hardware can optimize for sequential accesses.

Neither type of DMA mapping has alignment restrictions that come

from PCI, although some devices may have such restrictions.

Also, systems with caches that aren't DMA-coherent will work better

when the underlying buffers don't share cache lines with other data.

		 Using Consistent DMA mappings.

----------

Thanks to Paolo Ciarrocchi who allowed the "Development Process" section

Thanks to Paolo Ciarrocchi who allowed the "Development Process"

(http://linux.tar.bz/articles/2.6-development_process) section

to be based on text he had written, and to Randy Dunlap and Gerrit

Huizenga for some of the list of things you should and should not say.

Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,

As of the Linux 2.6.10 kernel, it is now possible to change the

IO scheduler for a given block device on the fly (thus making it possible,

for instance, to set the CFQ scheduler for the system default, but

set a specific device to use the anticipatory or noop schedulers - which

can improve that device's throughput).

To set a specific scheduler, simply do this:

echo SCHEDNAME > /sys/block/DEV/queue/scheduler

where SCHEDNAME is the name of a defined IO scheduler, and DEV is the

device name (hda, hdb, sga, or whatever you happen to have).

The list of defined schedulers can be found by simply doing

a "cat /sys/block/DEV/queue/scheduler" - the list of valid names

will be displayed, with the currently selected scheduler in brackets:

# cat /sys/block/hda/queue/scheduler

noop anticipatory deadline [cfq]

# echo anticipatory > /sys/block/hda/queue/scheduler

# cat /sys/block/hda/queue/scheduler

noop [anticipatory] deadline cfq