Merge branch 'sched/urgent' into sched/core (d81344c5) · Commits · 戴 / test

Documentation/ABI/testing/sysfs-block-bcache

0 → 100644

+156 −0

Original line number	Diff line number	Diff line
		What: /sys/block/<disk>/bcache/unregister
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		A write to this file causes the backing device or cache to be
		unregistered. If a backing device had dirty data in the cache,
		writeback mode is automatically disabled and all dirty data is
		flushed before the device is unregistered. Caches unregister
		all associated backing devices before unregistering themselves.

		What: /sys/block/<disk>/bcache/clear_stats
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		Writing to this file resets all the statistics for the device.

		What: /sys/block/<disk>/bcache/cache
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		For a backing device that has cache, a symlink to
		the bcache/ dir of that cache.

		What: /sys/block/<disk>/bcache/cache_hits
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		For backing devices: integer number of full cache hits,
		counted per bio. A partial cache hit counts as a miss.

		What: /sys/block/<disk>/bcache/cache_misses
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		For backing devices: integer number of cache misses.

		What: /sys/block/<disk>/bcache/cache_hit_ratio
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		For backing devices: cache hits as a percentage.

		What: /sys/block/<disk>/bcache/sequential_cutoff
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		For backing devices: Threshold past which sequential IO will
		skip the cache. Read and written as bytes in human readable
		units (i.e. echo 10M > sequntial_cutoff).

		What: /sys/block/<disk>/bcache/bypassed
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		Sum of all reads and writes that have bypassed the cache (due
		to the sequential cutoff). Expressed as bytes in human
		readable units.

		What: /sys/block/<disk>/bcache/writeback
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		For backing devices: When on, writeback caching is enabled and
		writes will be buffered in the cache. When off, caching is in
		writethrough mode; reads and writes will be added to the
		cache but no write buffering will take place.

		What: /sys/block/<disk>/bcache/writeback_running
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		For backing devices: when off, dirty data will not be written
		from the cache to the backing device. The cache will still be
		used to buffer writes until it is mostly full, at which point
		writes transparently revert to writethrough mode. Intended only
		for benchmarking/testing.

		What: /sys/block/<disk>/bcache/writeback_delay
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		For backing devices: In writeback mode, when dirty data is
		written to the cache and the cache held no dirty data for that
		backing device, writeback from cache to backing device starts
		after this delay, expressed as an integer number of seconds.

		What: /sys/block/<disk>/bcache/writeback_percent
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		For backing devices: If nonzero, writeback from cache to
		backing device only takes place when more than this percentage
		of the cache is used, allowing more write coalescing to take
		place and reducing total number of writes sent to the backing
		device. Integer between 0 and 40.

		What: /sys/block/<disk>/bcache/synchronous
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		For a cache, a boolean that allows synchronous mode to be
		switched on and off. In synchronous mode all writes are ordered
		such that the cache can reliably recover from unclean shutdown;
		if disabled bcache will not generally wait for writes to
		complete but if the cache is not shut down cleanly all data
		will be discarded from the cache. Should not be turned off with
		writeback caching enabled.

		What: /sys/block/<disk>/bcache/discard
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		For a cache, a boolean allowing discard/TRIM to be turned off
		or back on if the device supports it.

		What: /sys/block/<disk>/bcache/bucket_size
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		For a cache, bucket size in human readable units, as set at
		cache creation time; should match the erase block size of the
		SSD for optimal performance.

		What: /sys/block/<disk>/bcache/nbuckets
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		For a cache, the number of usable buckets.

		What: /sys/block/<disk>/bcache/tree_depth
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		For a cache, height of the btree excluding leaf nodes (i.e. a
		one node tree will have a depth of 0).

		What: /sys/block/<disk>/bcache/btree_cache_size
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		Number of btree buckets/nodes that are currently cached in
		memory; cache dynamically grows and shrinks in response to
		memory pressure from the rest of the system.

		What: /sys/block/<disk>/bcache/written
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		For a cache, total amount of data in human readable units
		written to the cache, excluding all metadata.

		What: /sys/block/<disk>/bcache/btree_written
		Date: November 2010
		Contact: Kent Overstreet <kent.overstreet@gmail.com>
		Description:
		For a cache, sum of all btree writes in human readable units.

Documentation/ABI/testing/sysfs-bus-rbd

+0 −20

Original line number	Diff line number	Diff line
		@@ -66,27 +66,7 @@ current_snap

		The current snapshot for which the device is mapped.

		snap_*

		A directory per each snapshot

		parent

		Information identifying the pool, image, and snapshot id for
		the parent image in a layered rbd image (format 2 only).

		Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
		-------------------------------------------------------------

		snap_id

		The rados internal snapshot id assigned for this snapshot

		snap_size

		The size of the image when this snapshot was taken.

		snap_features

		A hexadecimal encoding of the feature bits for this snapshot.

Documentation/ABI/testing/sysfs-class-mtd

+2 −4

Original line number	Diff line number	Diff line
		@@ -14,8 +14,7 @@ Description:
		The /sys/class/mtd/mtd{0,1,2,3,...} directories correspond
		to each /dev/mtdX character device. These may represent
		physical/simulated flash devices, partitions on a flash
		device, or concatenated flash devices. They exist regardless
		of whether CONFIG_MTD_CHAR is actually enabled.
		device, or concatenated flash devices.

		What: /sys/class/mtd/mtdXro/
		Date: April 2009
		@@ -23,8 +22,7 @@ KernelVersion: 2.6.29
		Contact: linux-mtd@lists.infradead.org
		Description:
		These directories provide the corresponding read-only device
		nodes for /sys/class/mtd/mtdX/ . They are only created
		(for the benefit of udev) if CONFIG_MTD_CHAR is enabled.
		nodes for /sys/class/mtd/mtdX/ .

		What: /sys/class/mtd/mtdX/dev
		Date: April 2009

Documentation/acpi/enumeration.txt

+108 −1

Original line number	Diff line number	Diff line
		@@ -66,6 +66,83 @@ the ACPI device explicitly to acpi_platform_device_ids list defined in
		drivers/acpi/acpi_platform.c. This limitation is only for the platform
		devices, SPI and I2C devices are created automatically as described below.

		DMA support
		~~~~~~~~~~~
		DMA controllers enumerated via ACPI should be registered in the system to
		provide generic access to their resources. For example, a driver that would
		like to be accessible to slave devices via generic API call
		dma_request_slave_channel() must register itself at the end of the probe
		function like this:

		err = devm_acpi_dma_controller_register(dev, xlate_func, dw);
		/* Handle the error if it's not a case of !CONFIG_ACPI */

		and implement custom xlate function if needed (usually acpi_dma_simple_xlate()
		is enough) which converts the FixedDMA resource provided by struct
		acpi_dma_spec into the corresponding DMA channel. A piece of code for that case
		could look like:

		#ifdef CONFIG_ACPI
		struct filter_args {
		/* Provide necessary information for the filter_func */
		...
		};

		static bool filter_func(struct dma_chan chan, void param)
		{
		/* Choose the proper channel */
		...
		}

		static struct dma_chan xlate_func(struct acpi_dma_spec dma_spec,
		struct acpi_dma *adma)
		{
		dma_cap_mask_t cap;
		struct filter_args args;

		/* Prepare arguments for filter_func */
		...
		return dma_request_channel(cap, filter_func, &args);
		}
		#else
		static struct dma_chan xlate_func(struct acpi_dma_spec dma_spec,
		struct acpi_dma *adma)
		{
		return NULL;
		}
		#endif

		dma_request_slave_channel() will call xlate_func() for each registered DMA
		controller. In the xlate function the proper channel must be chosen based on
		information in struct acpi_dma_spec and the properties of the controller
		provided by struct acpi_dma.

		Clients must call dma_request_slave_channel() with the string parameter that
		corresponds to a specific FixedDMA resource. By default "tx" means the first
		entry of the FixedDMA resource array, "rx" means the second entry. The table
		below shows a layout:

		Device (I2C0)
		{
		...
		Method (_CRS, 0, NotSerialized)
		{
		Name (DBUF, ResourceTemplate ()
		{
		FixedDMA (0x0018, 0x0004, Width32bit, _Y48)
		FixedDMA (0x0019, 0x0005, Width32bit, )
		})
		...
		}
		}

		So, the FixedDMA with request line 0x0018 is "tx" and next one is "rx" in
		this example.

		In robust cases the client unfortunately needs to call
		acpi_dma_request_slave_chan_by_index() directly and therefore choose the
		specific FixedDMA resource by its index.

		SPI serial bus support
		~~~~~~~~~~~~~~~~~~~~~~
		Slave devices behind SPI bus have SpiSerialBus resource attached to them.
		@@ -199,6 +276,8 @@ the device to the driver. For example:
		{
		Name (SBUF, ResourceTemplate()
		{
		...
		// Used to power on/off the device
		GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
		IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0",
		0x00, ResourceConsumer,,)
		@@ -206,10 +285,20 @@ the device to the driver. For example:
		// Pin List
		0x0055
		}

		// Interrupt for the device
		GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone,
		0x0000, "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer,,)
		{
		// Pin list
		0x0058
		}

		...

		Return (SBUF)
		}

		Return (SBUF)
		}

		These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
		@@ -220,6 +309,24 @@ The driver can do this by including <linux/acpi_gpio.h> and then calling
		acpi_get_gpio(path, gpio). This will return the Linux GPIO number or
		negative errno if there was no translation found.

		In a simple case of just getting the Linux GPIO number from device
		resources one can use acpi_get_gpio_by_index() helper function. It takes
		pointer to the device and index of the GpioIo/GpioInt descriptor in the
		device resources list. For example:

		int gpio_irq, gpio_power;
		int ret;

		gpio_irq = acpi_get_gpio_by_index(dev, 1, NULL);
		if (gpio_irq < 0)
		/* handle error */

		gpio_power = acpi_get_gpio_by_index(dev, 0, NULL);
		if (gpio_power < 0)
		/* handle error */

		/* Now we can use the GPIO numbers */

		Other GpioIo parameters must be converted first by the driver to be
		suitable to the gpiolib before passing them.

Documentation/bcache.txt

0 → 100644

+431 −0

File added.

Preview size limit exceeded, changes collapsed.

Admin message