Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 358324
b: refs/heads/master
c: 7ae764b
h: refs/heads/master
v: v3
  • Loading branch information
Alex Deucher committed Feb 20, 2013
1 parent 485913d commit d6712ad
Show file tree
Hide file tree
Showing 1,066 changed files with 12,604 additions and 28,914 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: e9f211ad7d65b264998928cea822c11c88e5586b
refs/heads/master: 7ae764b11ed63279e9dcf25be972ff4ca21a9875
68 changes: 14 additions & 54 deletions trunk/Documentation/DocBook/drm.tmpl
Original file line number Diff line number Diff line change
Expand Up @@ -743,10 +743,6 @@ char *date;</synopsis>
These two operations are mandatory for GEM drivers that support DRM
PRIME.
</para>
<sect4>
<title>DRM PRIME Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
</sect4>
</sect3>
<sect3 id="drm-gem-objects-mapping">
<title>GEM Objects Mapping</title>
Expand Down Expand Up @@ -982,25 +978,10 @@ int max_width, max_height;</synopsis>
If the parameters are deemed valid, drivers then create, initialize and
return an instance of struct <structname>drm_framebuffer</structname>.
If desired the instance can be embedded in a larger driver-specific
structure. Drivers must fill its <structfield>width</structfield>,
<structfield>height</structfield>, <structfield>pitches</structfield>,
<structfield>offsets</structfield>, <structfield>depth</structfield>,
<structfield>bits_per_pixel</structfield> and
<structfield>pixel_format</structfield> fields from the values passed
through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
should call the <function>drm_helper_mode_fill_fb_struct</function>
helper function to do so.
</para>

<para>
The initailization of the new framebuffer instance is finalized with a
call to <function>drm_framebuffer_init</function> which takes a pointer
to DRM frame buffer operations (struct
<structname>drm_framebuffer_funcs</structname>). Note that this function
publishes the framebuffer and so from this point on it can be accessed
concurrently from other threads. Hence it must be the last step in the
driver's framebuffer initialization sequence. Frame buffer operations
are
structure. The new instance is initialized with a call to
<function>drm_framebuffer_init</function> which takes a pointer to DRM
frame buffer operations (struct
<structname>drm_framebuffer_funcs</structname>). Frame buffer operations are
<itemizedlist>
<listitem>
<synopsis>int (*create_handle)(struct drm_framebuffer *fb,
Expand Down Expand Up @@ -1041,16 +1022,16 @@ int max_width, max_height;</synopsis>
</itemizedlist>
</para>
<para>
The lifetime of a drm framebuffer is controlled with a reference count,
drivers can grab additional references with
<function>drm_framebuffer_reference</function> </para> and drop them
again with <function>drm_framebuffer_unreference</function>. For
driver-private framebuffers for which the last reference is never
dropped (e.g. for the fbdev framebuffer when the struct
<structname>drm_framebuffer</structname> is embedded into the fbdev
helper struct) drivers can manually clean up a framebuffer at module
unload time with
<function>drm_framebuffer_unregister_private</function>.
After initializing the <structname>drm_framebuffer</structname>
instance drivers must fill its <structfield>width</structfield>,
<structfield>height</structfield>, <structfield>pitches</structfield>,
<structfield>offsets</structfield>, <structfield>depth</structfield>,
<structfield>bits_per_pixel</structfield> and
<structfield>pixel_format</structfield> fields from the values passed
through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
should call the <function>drm_helper_mode_fill_fb_struct</function>
helper function to do so.
</para>
</sect2>
<sect2>
<title>Output Polling</title>
Expand All @@ -1062,22 +1043,6 @@ int max_width, max_height;</synopsis>
operation.
</para>
</sect2>
<sect2>
<title>Locking</title>
<para>
Beside some lookup structures with their own locking (which is hidden
behind the interface functions) most of the modeset state is protected
by the <code>dev-&lt;mode_config.lock</code> mutex and additionally
per-crtc locks to allow cursor updates, pageflips and similar operations
to occur concurrently with background tasks like output detection.
Operations which cross domains like a full modeset always grab all
locks. Drivers there need to protect resources shared between crtcs with
additional locking. They also need to be careful to always grab the
relevant crtc locks if a modset functions touches crtc state, e.g. for
load detection (which does only grab the <code>mode_config.lock</code>
to allow concurrent screen updates on live crtcs).
</para>
</sect2>
</sect1>

<!-- Internals: kms initialization and cleanup -->
Expand Down Expand Up @@ -1644,10 +1609,6 @@ void intel_crt_init(struct drm_device *dev)
make its properties available to applications.
</para>
</sect2>
<sect2>
<title>KMS API Functions</title>
!Edrivers/gpu/drm/drm_crtc.c
</sect2>
</sect1>

<!-- Internals: kms helper functions -->
Expand Down Expand Up @@ -2143,7 +2104,6 @@ void intel_crt_init(struct drm_device *dev)
<title>fbdev Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
!Edrivers/gpu/drm/drm_fb_helper.c
!Iinclude/drm/drm_fb_helper.h
</sect2>
<sect2>
<title>Display Port Helper Functions Reference</title>
Expand Down
27 changes: 4 additions & 23 deletions trunk/Documentation/EDID/HOWTO.txt
Original file line number Diff line number Diff line change
Expand Up @@ -28,30 +28,11 @@ Makefile environment are given here.
To create binary EDID and C source code files from the existing data
material, simply type "make".

If you want to create your own EDID file, copy the file 1024x768.S,
replace the settings with your own data and add a new target to the
Makefile. Please note that the EDID data structure expects the timing
values in a different way as compared to the standard X11 format.

X11:
HTimings: hdisp hsyncstart hsyncend htotal
VTimings: vdisp vsyncstart vsyncend vtotal

EDID:
#define XPIX hdisp
#define XBLANK htotal-hdisp
#define XOFFSET hsyncstart-hdisp
#define XPULSE hsyncend-hsyncstart

#define YPIX vdisp
#define YBLANK vtotal-vdisp
#define YOFFSET (63+(vsyncstart-vdisp))
#define YPULSE (63+(vsyncend-vsyncstart))

The CRC value in the last line
If you want to create your own EDID file, copy the file 1024x768.S and
replace the settings with your own data. The CRC value in the last line
#define CRC 0x55
also is a bit tricky. After a first version of the binary data set is
created, it must be checked with the "edid-decode" utility which will
is a bit tricky. After a first version of the binary data set is
created, it must be be checked with the "edid-decode" utility which will
most probably complain about a wrong CRC. Fortunately, the utility also
displays the correct CRC which must then be inserted into the source
file. After the make procedure is repeated, the EDID data set is ready
Expand Down
1 change: 0 additions & 1 deletion trunk/Documentation/device-mapper/dm-raid.txt
Original file line number Diff line number Diff line change
Expand Up @@ -141,4 +141,3 @@ Version History
1.2.0 Handle creation of arrays that contain failed devices.
1.3.0 Added support for RAID 10
1.3.1 Allow device replacement/rebuild for RAID 10
1.3.2 Fix/improve redundancy checking for RAID10
Original file line number Diff line number Diff line change
Expand Up @@ -81,8 +81,7 @@ PA31 TXD4
Required properties for pin configuration node:
- atmel,pins: 4 integers array, represents a group of pins mux and config
setting. The format is atmel,pins = <PIN_BANK PIN_BANK_NUM PERIPH CONFIG>.
The PERIPH 0 means gpio, PERIPH 1 is periph A, PERIPH 2 is periph B...
PIN_BANK 0 is pioA, PIN_BANK 1 is pioB...
The PERIPH 0 means gpio.

Bits used for CONFIG:
PULL_UP (1 << 0): indicate this pin need a pull up.
Expand Down Expand Up @@ -127,7 +126,7 @@ pinctrl@fffff400 {
pinctrl_dbgu: dbgu-0 {
atmel,pins =
<1 14 0x1 0x0 /* PB14 periph A */
1 15 0x1 0x1>; /* PB15 periph A with pullup */
1 15 0x1 0x1>; /* PB15 periph with pullup */
};
};
};
Expand Down
109 changes: 0 additions & 109 deletions trunk/Documentation/devicetree/bindings/video/display-timing.txt

This file was deleted.

18 changes: 9 additions & 9 deletions trunk/Documentation/filesystems/f2fs.txt
Original file line number Diff line number Diff line change
Expand Up @@ -175,9 +175,9 @@ consists of multiple segments as described below.
align with the zone size <-|
|-> align with the segment size
_________________________________________________________________________
| | | Segment | Node | Segment | |
| Superblock | Checkpoint | Info. | Address | Summary | Main |
| (SB) | (CP) | Table (SIT) | Table (NAT) | Area (SSA) | |
| | | Node | Segment | Segment | |
| Superblock | Checkpoint | Address | Info. | Summary | Main |
| (SB) | (CP) | Table (NAT) | Table (SIT) | Area (SSA) | |
|____________|_____2______|______N______|______N______|______N_____|__N___|
. .
. .
Expand All @@ -200,14 +200,14 @@ consists of multiple segments as described below.
: It contains file system information, bitmaps for valid NAT/SIT sets, orphan
inode lists, and summary entries of current active segments.

- Segment Information Table (SIT)
: It contains segment information such as valid block count and bitmap for the
validity of all the blocks.

- Node Address Table (NAT)
: It is composed of a block address table for all the node blocks stored in
Main area.

- Segment Information Table (SIT)
: It contains segment information such as valid block count and bitmap for the
validity of all the blocks.

- Segment Summary Area (SSA)
: It contains summary entries which contains the owner information of all the
data and node blocks stored in Main area.
Expand Down Expand Up @@ -236,13 +236,13 @@ For file system consistency, each CP points to which NAT and SIT copies are
valid, as shown as below.

+--------+----------+---------+
| CP | SIT | NAT |
| CP | NAT | SIT |
+--------+----------+---------+
. . . .
. . . .
. . . .
+-------+-------+--------+--------+--------+--------+
| CP #0 | CP #1 | SIT #0 | SIT #1 | NAT #0 | NAT #1 |
| CP #0 | CP #1 | NAT #0 | NAT #1 | SIT #0 | SIT #1 |
+-------+-------+--------+--------+--------+--------+
| ^ ^
| | |
Expand Down
Empty file modified trunk/Documentation/hid/hid-sensor.txt
100644 → 100755
Empty file.
2 changes: 1 addition & 1 deletion trunk/Documentation/kernel-parameters.txt
Original file line number Diff line number Diff line change
Expand Up @@ -2438,7 +2438,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
real-time workloads. It can also improve energy
efficiency for asymmetric multiprocessors.

rcu_nocb_poll [KNL,BOOT]
rcu_nocbs_poll [KNL,BOOT]
Rather than requiring that offloaded CPUs
(specified by rcu_nocbs= above) explicitly
awaken the corresponding "rcuoN" kthreads,
Expand Down
Loading

0 comments on commit d6712ad

Please sign in to comment.