Merge tag 'xtensa-for-next-20140406' of git://github.com/jcmvbkbc/linux-xtensa into for_next

Contact:	Kay Sievers <kay.sievers@vrfy.org>

Description:

		 Shows the list of currently configured

		 tty devices used for the console,

		 like 'tty1 ttyS0'.

		 console devices, like 'tty1 ttyS0'.

		 The last entry in the file is the active

		 device connected to /dev/console.

		 The file supports poll() to detect virtual

has to request that the PCI layer set up the MSI capability for this

device.

4.2.1 pci_enable_msi_range

4.2.1 pci_enable_msi

int pci_enable_msi(struct pci_dev *dev)

A successful call allocates ONE interrupt to the device, regardless

of how many MSIs the device supports.  The device is switched from

pin-based interrupt mode to MSI mode.  The dev->irq number is changed

to a new number which represents the message signaled interrupt;

consequently, this function should be called before the driver calls

request_irq(), because an MSI is delivered via a vector that is

different from the vector of a pin-based interrupt.

4.2.2 pci_enable_msi_range

int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)

	return pci_enable_msi_range(pdev, nvec, nvec);

}

Note, unlike pci_enable_msi_exact() function, which could be also used to

enable a particular number of MSI-X interrupts, pci_enable_msi_range()

returns either a negative errno or 'nvec' (not negative errno or 0 - as

pci_enable_msi_exact() does).

4.2.1.3 Single MSI mode

The most notorious example of the request type described above is

	return pci_enable_msi_range(pdev, 1, 1);

}

4.2.2 pci_disable_msi

Note, unlike pci_enable_msi() function, which could be also used to

enable the single MSI mode, pci_enable_msi_range() returns either a

negative errno or 1 (not negative errno or 0 - as pci_enable_msi()

does).

4.2.3 pci_enable_msi_exact

int pci_enable_msi_exact(struct pci_dev *dev, int nvec)

This variation on pci_enable_msi_range() call allows a device driver to

request exactly 'nvec' MSIs.

If this function returns a negative number, it indicates an error and

the driver should not attempt to request any more MSI interrupts for

this device.

By contrast with pci_enable_msi_range() function, pci_enable_msi_exact()

returns zero in case of success, which indicates MSI interrupts have been

successfully allocated.

4.2.4 pci_disable_msi

void pci_disable_msi(struct pci_dev *dev)

Failure to do so results in a BUG_ON(), leaving the device with

MSI enabled and thus leaking its vector.

4.2.3 pci_msi_vec_count

4.2.4 pci_msi_vec_count

int pci_msi_vec_count(struct pci_dev *dev)

static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)

{

	return pci_enable_msi_range(adapter->pdev, adapter->msix_entries,

	return pci_enable_msix_range(adapter->pdev, adapter->msix_entries,

				     1, nvec);

}

static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)

{

	return pci_enable_msi_range(adapter->pdev, adapter->msix_entries,

	return pci_enable_msix_range(adapter->pdev, adapter->msix_entries,

				     FOO_DRIVER_MINIMUM_NVEC, nvec);

}

static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)

{

	return pci_enable_msi_range(adapter->pdev, adapter->msix_entries,

	return pci_enable_msix_range(adapter->pdev, adapter->msix_entries,

				     nvec, nvec);

}

Note, unlike pci_enable_msix_exact() function, which could be also used to

enable a particular number of MSI-X interrupts, pci_enable_msix_range()

returns either a negative errno or 'nvec' (not negative errno or 0 - as

pci_enable_msix_exact() does).

4.3.1.3 Specific requirements to the number of MSI-X interrupts

As noted above, there could be devices that can not operate with just any

any error code other than -ENOSPC indicates a fatal error and should not

be retried.

4.3.2 pci_disable_msix

4.3.2 pci_enable_msix_exact

int pci_enable_msix_exact(struct pci_dev *dev,

			  struct msix_entry *entries, int nvec)

This variation on pci_enable_msix_range() call allows a device driver to

request exactly 'nvec' MSI-Xs.

If this function returns a negative number, it indicates an error and

the driver should not attempt to allocate any more MSI-X interrupts for

this device.

By contrast with pci_enable_msix_range() function, pci_enable_msix_exact()

returns zero in case of success, which indicates MSI-X interrupts have been

successfully allocated.

Another version of a routine that enables MSI-X mode for a device with

specific requirements described in chapter 4.3.1.3 might look like this:

/*

 * Assume 'minvec' and 'maxvec' are non-zero

 */

static int foo_driver_enable_msix(struct foo_adapter *adapter,

				  int minvec, int maxvec)

{

	int rc;

	minvec = roundup_pow_of_two(minvec);

	maxvec = rounddown_pow_of_two(maxvec);

	if (minvec > maxvec)

		return -ERANGE;

retry:

	rc = pci_enable_msix_exact(adapter->pdev,

				   adapter->msix_entries, maxvec);

	/*

	 * -ENOSPC is the only error code allowed to be analyzed

	 */

	if (rc == -ENOSPC) {

		if (maxvec == 1)

			return -ENOSPC;

		maxvec /= 2;

		if (minvec > maxvec)

			return -ENOSPC;

		goto retry;

	} else if (rc < 0) {

		return rc;

	}

	return maxvec;

}

4.3.3 pci_disable_msix

void pci_disable_msix(struct pci_dev *dev)

Updating on-disk metadata

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

On-disk metadata is committed every time a REQ_SYNC or REQ_FUA bio is

written.  If no such requests are made then commits will occur every

second.  This means the cache behaves like a physical disk that has a

write cache (the same is true of the thin-provisioning target).  If

power is lost you may lose some recent writes.  The metadata should

always be consistent in spite of any crash.

On-disk metadata is committed every time a FLUSH or FUA bio is written.

If no such requests are made then commits will occur every second.  This

means the cache behaves like a physical disk that has a volatile write

cache.  If power is lost you may lose some recent writes.  The metadata

should always be consistent in spite of any crash.

The 'dirty' state for a cache block changes far too frequently for us

to keep updating it on the fly.  So we treat it as a hint.  In normal

userspace daemon can use this to detect a situation where a new table

already exceeds the threshold.

A low water mark for the metadata device is maintained in the kernel and

will trigger a dm event if free space on the metadata device drops below

it.

Updating on-disk metadata

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

On-disk metadata is committed every time a FLUSH or FUA bio is written.

If no such requests are made then commits will occur every second.  This

means the thin-provisioning target behaves like a physical disk that has

a volatile write cache.  If power is lost you may lose some recent

writes.  The metadata should always be consistent in spite of any crash.

If data space is exhausted the pool will either error or queue IO

according to the configuration (see: error_if_no_space).  If metadata

space is exhausted or a metadata operation fails: the pool will error IO

until the pool is taken offline and repair is performed to 1) fix any

potential inconsistencies and 2) clear the flag that imposes repair.

Once the pool's metadata device is repaired it may be resized, which

will allow the pool to return to normal operation.  Note that if a pool

is flagged as needing repair, the pool's data and metadata devices

cannot be resized until repair is performed.  It should also be noted

that when the pool's metadata space is exhausted the current metadata

transaction is aborted.  Given that the pool will cache IO whose

completion may have already been acknowledged to upper IO layers

(e.g. filesystem) it is strongly suggested that consistency checks

(e.g. fsck) be performed on those layers when repair of the pool is

required.

Thin provisioning

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

	should register for the event and then check the target's status.

    held metadata root:

	The location, in sectors, of the metadata root that has been

	The location, in blocks, of the metadata root that has been

	'held' for userspace read access.  '-' indicates there is no

	held root.  This feature is not yet implemented so '-' is

	always returned.

	held root.

    discard_passdown|no_discard_passdown

	Whether or not discards are actually being passed down to the

  compatible = "ti,omap3-beagle", "ti,omap3"

- OMAP3 Tobi with Overo : Commercial expansion board with daughter board

  compatible = "ti,omap3-tobi", "ti,omap3-overo", "ti,omap3"

  compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3"

- OMAP4 SDP : Software Development Board

  compatible = "ti,omap4-sdp", "ti,omap4430"