Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 375631
b: refs/heads/master
c: fbd44a6
h: refs/heads/master
i:
  375629: 62715ca
  375627: 5bbc3d0
  375623: 97350e2
  375615: d4ddef8
v: v3
  • Loading branch information
Thomas Gleixner authored and Ingo Molnar committed May 5, 2013
1 parent f6cb570 commit 0ab3a20
Show file tree
Hide file tree
Showing 2,989 changed files with 59,237 additions and 161,466 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: 37cae5e24981f4619372e6a29456d34e4cbdc5e2
refs/heads/master: fbd44a607a1a5019bc32c3615cead8c5ee8f89c9
156 changes: 0 additions & 156 deletions trunk/Documentation/ABI/testing/sysfs-block-bcache

This file was deleted.

20 changes: 20 additions & 0 deletions trunk/Documentation/ABI/testing/sysfs-bus-rbd
Original file line number Diff line number Diff line change
Expand Up @@ -66,7 +66,27 @@ 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.

6 changes: 4 additions & 2 deletions trunk/Documentation/ABI/testing/sysfs-class-mtd
Original file line number Diff line number Diff line change
Expand Up @@ -14,15 +14,17 @@ 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.
device, or concatenated flash devices. They exist regardless
of whether CONFIG_MTD_CHAR is actually enabled.

What: /sys/class/mtd/mtdXro/
Date: April 2009
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/ .
nodes for /sys/class/mtd/mtdX/ . They are only created
(for the benefit of udev) if CONFIG_MTD_CHAR is enabled.

What: /sys/class/mtd/mtdX/dev
Date: April 2009
Expand Down
12 changes: 7 additions & 5 deletions trunk/Documentation/DocBook/writing-an-alsa-driver.tmpl
Original file line number Diff line number Diff line change
Expand Up @@ -6164,12 +6164,14 @@ struct _snd_pcm_runtime {

<para>
The macro takes an conditional expression to evaluate.
When <constant>CONFIG_SND_DEBUG</constant>, is set, if the
expression is non-zero, it shows the warning message such as
When <constant>CONFIG_SND_DEBUG</constant>, is set, the
expression is actually evaluated. If it's non-zero, it shows
the warning message such as
<computeroutput>BUG? (xxx)</computeroutput>
normally followed by stack trace.

In both cases it returns the evaluated value.
normally followed by stack trace. It returns the evaluated
value.
When no <constant>CONFIG_SND_DEBUG</constant> is set, this
macro always returns zero.
</para>

</section>
Expand Down
2 changes: 1 addition & 1 deletion trunk/Documentation/RCU/stallwarn.txt
Original file line number Diff line number Diff line change
Expand Up @@ -191,7 +191,7 @@ o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that
o A hardware or software issue shuts off the scheduler-clock
interrupt on a CPU that is not in dyntick-idle mode. This
problem really has happened, and seems to be most likely to
result in RCU CPU stall warnings for CONFIG_NO_HZ_COMMON=n kernels.
result in RCU CPU stall warnings for CONFIG_NO_HZ=n kernels.

o A bug in the RCU implementation.

Expand Down
109 changes: 1 addition & 108 deletions trunk/Documentation/acpi/enumeration.txt
Original file line number Diff line number Diff line change
Expand Up @@ -66,83 +66,6 @@ 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.
Expand Down Expand Up @@ -276,29 +199,17 @@ 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,,)
{
// 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"
Expand All @@ -309,24 +220,6 @@ 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.

Expand Down
Loading

0 comments on commit 0ab3a20

Please sign in to comment.