Skip to content

Commit

Permalink
Merge branch 'sched/urgent' into sched/core
Browse files Browse the repository at this point in the history
Merge in the latest fixes before applying a dependent patch.

Signed-off-by: Ingo Molnar <mingo@kernel.org>
  • Loading branch information
Ingo Molnar committed Sep 20, 2013
2 parents c61037e + 7e3115e commit 40a0c68
Show file tree
Hide file tree
Showing 5,664 changed files with 332,069 additions and 149,868 deletions.
The diff you're trying to view is too large. We only load the first 3000 changed files.
12 changes: 6 additions & 6 deletions CREDITS
Original file line number Diff line number Diff line change
Expand Up @@ -637,14 +637,13 @@ S: 14509 NE 39th Street #1096
S: Bellevue, Washington 98007
S: USA

N: Christopher L. Cheney
E: ccheney@debian.org
E: ccheney@cheney.cx
W: http://www.cheney.cx
N: Chris Cheney
E: chris.cheney@gmail.com
E: ccheney@redhat.com
P: 1024D/8E384AF2 2D31 1927 87D7 1F24 9FF9 1BC5 D106 5AB3 8E38 4AF2
D: Vista Imaging usb webcam driver
S: 314 Prince of Wales
S: Conroe, TX 77304
S: 2308 Therrell Way
S: McKinney, TX 75070
S: USA

N: Stuart Cheshire
Expand Down Expand Up @@ -1120,6 +1119,7 @@ D: author of userfs filesystem
D: Improved mmap and munmap handling
D: General mm minor tidyups
D: autofs v4 maintainer
D: Xen subsystem
S: 987 Alabama St
S: San Francisco
S: CA, 94110
Expand Down
2 changes: 1 addition & 1 deletion Documentation/00-INDEX
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ IPMI.txt
IRQ-affinity.txt
- how to select which CPU(s) handle which interrupt events on SMP.
IRQ-domain.txt
- info on inerrupt numbering and setting up IRQ domains.
- info on interrupt numbering and setting up IRQ domains.
IRQ.txt
- description of what an IRQ is.
Intel-IOMMU.txt
Expand Down
9 changes: 5 additions & 4 deletions Documentation/ABI/testing/sysfs-block-zram
Original file line number Diff line number Diff line change
Expand Up @@ -5,20 +5,21 @@ Description:
The disksize file is read-write and specifies the disk size
which represents the limit on the *uncompressed* worth of data
that can be stored in this disk.
Unit: bytes

What: /sys/block/zram<id>/initstate
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The disksize file is read-only and shows the initialization
The initstate file is read-only and shows the initialization
state of the device.

What: /sys/block/zram<id>/reset
Date: August 2010
Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The disksize file is write-only and allows resetting the
device. The reset operation frees all the memory assocaited
The reset file is write-only and allows resetting the
device. The reset operation frees all the memory associated
with this device.

What: /sys/block/zram<id>/num_reads
Expand Down Expand Up @@ -48,7 +49,7 @@ Contact: Nitin Gupta <ngupta@vflare.org>
Description:
The notify_free file is read-only and specifies the number of
swap slot free notifications received by this device. These
notifications are send to a swap block device when a swap slot
notifications are sent to a swap block device when a swap slot
is freed. This statistic is applicable only when this disk is
being used as a swap disk.

Expand Down
17 changes: 14 additions & 3 deletions Documentation/ABI/testing/sysfs-class-mtd
Original file line number Diff line number Diff line change
Expand Up @@ -128,9 +128,8 @@ KernelVersion: 3.4
Contact: linux-mtd@lists.infradead.org
Description:
Maximum number of bit errors that the device is capable of
correcting within each region covering an ecc step. This will
always be a non-negative integer. Note that some devices will
have multiple ecc steps within each writesize region.
correcting within each region covering an ECC step (see
ecc_step_size). This will always be a non-negative integer.

In the case of devices lacking any ECC capability, it is 0.

Expand Down Expand Up @@ -173,3 +172,15 @@ Description:
This is generally applicable only to NAND flash devices with ECC
capability. It is ignored on devices lacking ECC capability;
i.e., devices for which ecc_strength is zero.

What: /sys/class/mtd/mtdX/ecc_step_size
Date: May 2013
KernelVersion: 3.10
Contact: linux-mtd@lists.infradead.org
Description:
The size of a single region covered by ECC, known as the ECC
step. Devices may have several equally sized ECC steps within
each writesize region.

It will always be a non-negative integer. In the case of
devices lacking any ECC capability, it is 0.
26 changes: 26 additions & 0 deletions Documentation/ABI/testing/sysfs-fs-f2fs
Original file line number Diff line number Diff line change
@@ -0,0 +1,26 @@
What: /sys/fs/f2fs/<disk>/gc_max_sleep_time
Date: July 2013
Contact: "Namjae Jeon" <namjae.jeon@samsung.com>
Description:
Controls the maximun sleep time for gc_thread. Time
is in milliseconds.

What: /sys/fs/f2fs/<disk>/gc_min_sleep_time
Date: July 2013
Contact: "Namjae Jeon" <namjae.jeon@samsung.com>
Description:
Controls the minimum sleep time for gc_thread. Time
is in milliseconds.

What: /sys/fs/f2fs/<disk>/gc_no_gc_sleep_time
Date: July 2013
Contact: "Namjae Jeon" <namjae.jeon@samsung.com>
Description:
Controls the default sleep time for gc_thread. Time
is in milliseconds.

What: /sys/fs/f2fs/<disk>/gc_idle
Date: July 2013
Contact: "Namjae Jeon" <namjae.jeon@samsung.com>
Description:
Controls the victim selection policy for garbage collection.
1 change: 1 addition & 0 deletions Documentation/DocBook/80211.tmpl
Original file line number Diff line number Diff line change
Expand Up @@ -325,6 +325,7 @@
<title>functions/definitions</title>
!Finclude/net/mac80211.h ieee80211_rx_status
!Finclude/net/mac80211.h mac80211_rx_flags
!Finclude/net/mac80211.h mac80211_tx_info_flags
!Finclude/net/mac80211.h mac80211_tx_control_flags
!Finclude/net/mac80211.h mac80211_rate_control_flags
!Finclude/net/mac80211.h ieee80211_tx_rate
Expand Down
138 changes: 97 additions & 41 deletions Documentation/DocBook/drm.tmpl
Original file line number Diff line number Diff line change
Expand Up @@ -155,13 +155,6 @@
will become a fatal error.
</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_USE_MTRR</term>
<listitem><para>
Driver uses MTRR interface for mapping memory, the DRM core will
manage MTRR resources. Deprecated.
</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_PCI_DMA</term>
<listitem><para>
Expand Down Expand Up @@ -194,28 +187,6 @@
support shared IRQs (note that this is required of PCI drivers).
</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_IRQ_VBL</term>
<listitem><para>Unused. Deprecated.</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_DMA_QUEUE</term>
<listitem><para>
Should be set if the driver queues DMA requests and completes them
asynchronously. Deprecated.
</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_FB_DMA</term>
<listitem><para>
Driver supports DMA to/from the framebuffer, mapping of frambuffer
DMA buffers to userspace will be supported. Deprecated.
</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_IRQ_VBL2</term>
<listitem><para>Unused. Deprecated.</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_GEM</term>
<listitem><para>
Expand All @@ -234,6 +205,12 @@
Driver implements DRM PRIME buffer sharing.
</para></listitem>
</varlistentry>
<varlistentry>
<term>DRIVER_RENDER</term>
<listitem><para>
Driver supports dedicated render nodes.
</para></listitem>
</varlistentry>
</variablelist>
</sect3>
<sect3>
Expand Down Expand Up @@ -2212,6 +2189,18 @@ void intel_crt_init(struct drm_device *dev)
!Iinclude/drm/drm_rect.h
!Edrivers/gpu/drm/drm_rect.c
</sect2>
<sect2>
<title>Flip-work Helper Reference</title>
!Pinclude/drm/drm_flip_work.h flip utils
!Iinclude/drm/drm_flip_work.h
!Edrivers/gpu/drm/drm_flip_work.c
</sect2>
<sect2>
<title>VMA Offset Manager</title>
!Pdrivers/gpu/drm/drm_vma_manager.c vma offset manager
!Edrivers/gpu/drm/drm_vma_manager.c
!Iinclude/drm/drm_vma_manager.h
</sect2>
</sect1>

<!-- Internals: kms properties -->
Expand Down Expand Up @@ -2422,18 +2411,18 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis>
</abstract>
<para>
The <methodname>firstopen</methodname> method is called by the DRM core
when an application opens a device that has no other opened file handle.
Similarly the <methodname>lastclose</methodname> method is called when
the last application holding a file handle opened on the device closes
it. Both methods are mostly used for UMS (User Mode Setting) drivers to
acquire and release device resources which should be done in the
<methodname>load</methodname> and <methodname>unload</methodname>
methods for KMS drivers.
for legacy UMS (User Mode Setting) drivers only when an application
opens a device that has no other opened file handle. UMS drivers can
implement it to acquire device resources. KMS drivers can't use the
method and must acquire resources in the <methodname>load</methodname>
method instead.
</para>
<para>
Note that the <methodname>lastclose</methodname> method is also called
at module unload time or, for hot-pluggable devices, when the device is
unplugged. The <methodname>firstopen</methodname> and
Similarly the <methodname>lastclose</methodname> method is called when
the last application holding a file handle opened on the device closes
it, for both UMS and KMS drivers. Additionally, the method is also
called at module unload time or, for hot-pluggable devices, when the
device is unplugged. The <methodname>firstopen</methodname> and
<methodname>lastclose</methodname> calls can thus be unbalanced.
</para>
<para>
Expand Down Expand Up @@ -2462,7 +2451,12 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis>
<para>
The <methodname>lastclose</methodname> method should restore CRTC and
plane properties to default value, so that a subsequent open of the
device will not inherit state from the previous user.
device will not inherit state from the previous user. It can also be
used to execute delayed power switching state changes, e.g. in
conjunction with the vga-switcheroo infrastructure. Beyond that KMS
drivers should not do any further cleanup. Only legacy UMS drivers might
need to clean up device state so that the vga console or an independent
fbdev driver could take over.
</para>
</sect2>
<sect2>
Expand Down Expand Up @@ -2498,7 +2492,6 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis>
<programlisting>
.poll = drm_poll,
.read = drm_read,
.fasync = drm_fasync,
.llseek = no_llseek,
</programlisting>
</para>
Expand Down Expand Up @@ -2657,6 +2650,69 @@ int (*resume) (struct drm_device *);</synopsis>
info, since man pages should cover the rest.
</para>

<!-- External: render nodes -->

<sect1>
<title>Render nodes</title>
<para>
DRM core provides multiple character-devices for user-space to use.
Depending on which device is opened, user-space can perform a different
set of operations (mainly ioctls). The primary node is always created
and called <term>card&lt;num&gt;</term>. Additionally, a currently
unused control node, called <term>controlD&lt;num&gt;</term> is also
created. The primary node provides all legacy operations and
historically was the only interface used by userspace. With KMS, the
control node was introduced. However, the planned KMS control interface
has never been written and so the control node stays unused to date.
</para>
<para>
With the increased use of offscreen renderers and GPGPU applications,
clients no longer require running compositors or graphics servers to
make use of a GPU. But the DRM API required unprivileged clients to
authenticate to a DRM-Master prior to getting GPU access. To avoid this
step and to grant clients GPU access without authenticating, render
nodes were introduced. Render nodes solely serve render clients, that
is, no modesetting or privileged ioctls can be issued on render nodes.
Only non-global rendering commands are allowed. If a driver supports
render nodes, it must advertise it via the <term>DRIVER_RENDER</term>
DRM driver capability. If not supported, the primary node must be used
for render clients together with the legacy drmAuth authentication
procedure.
</para>
<para>
If a driver advertises render node support, DRM core will create a
separate render node called <term>renderD&lt;num&gt;</term>. There will
be one render node per device. No ioctls except PRIME-related ioctls
will be allowed on this node. Especially <term>GEM_OPEN</term> will be
explicitly prohibited. Render nodes are designed to avoid the
buffer-leaks, which occur if clients guess the flink names or mmap
offsets on the legacy interface. Additionally to this basic interface,
drivers must mark their driver-dependent render-only ioctls as
<term>DRM_RENDER_ALLOW</term> so render clients can use them. Driver
authors must be careful not to allow any privileged ioctls on render
nodes.
</para>
<para>
With render nodes, user-space can now control access to the render node
via basic file-system access-modes. A running graphics server which
authenticates clients on the privileged primary/legacy node is no longer
required. Instead, a client can open the render node and is immediately
granted GPU access. Communication between clients (or servers) is done
via PRIME. FLINK from render node to legacy node is not supported. New
clients must not use the insecure FLINK interface.
</para>
<para>
Besides dropping all modeset/global ioctls, render nodes also drop the
DRM-Master concept. There is no reason to associate render clients with
a DRM-Master as they are independent of any graphics server. Besides,
they must work without any running master, anyway.
Drivers must be able to run without a master object if they support
render nodes. If, on the other hand, a driver requires shared state
between clients which is visible to user-space and accessible beyond
open-file boundaries, they cannot support render nodes.
</para>
</sect1>

<!-- External: vblank handling -->

<sect1>
Expand Down
Loading

0 comments on commit 40a0c68

Please sign in to comment.