Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history 
yaml
---
r: 201305
b: refs/heads/master
c: a13773a
h: refs/heads/master
i:
  201303: 8c4b158
v: v3
  • Loading branch information
Vladislav Zolotarov authored and David S. Miller committed Jul 21, 2010
1 parent c53ab41 commit 8e477f2
Show file tree
Hide file tree
Showing 1,787 changed files with 208,214 additions and 92,243 deletions.
2 changes: 1 addition & 1 deletion [refs]
View file
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: 1a041a23da7c77b53c71fe11b4f940388bee37b1
refs/heads/master: a13773a53faa28cf79982601b6fc9ddb0ca45f36
1 change: 0 additions & 1 deletion trunk/.gitignore
View file
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,6 @@ modules.builtin
*.gz
*.bz2
*.lzma
*.lzo
*.patch
*.gcno

Expand Down
7 changes: 0 additions & 7 deletions trunk/Documentation/.gitignore
View file

This file was deleted.

6 changes: 2 additions & 4 deletions trunk/Documentation/00-INDEX
View file
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,8 @@ DocBook/
- directory with DocBook templates etc. for kernel documentation.
HOWTO
- the process and procedures of how to do Linux kernel development.
IO-mapping.txt
- how to access I/O mapped memory from within device drivers.
IPMI.txt
- info on Linux Intelligent Platform Management Interface (IPMI) Driver.
IRQ-affinity.txt
Expand Down Expand Up @@ -82,8 +84,6 @@ blockdev/
- info on block devices & drivers
btmrvl.txt
- info on Marvell Bluetooth driver usage.
bus-virt-phys-mapping.txt
- how to access I/O mapped memory from within device drivers.
cachetlb.txt
- describes the cache/TLB flushing interfaces Linux uses.
cdrom/
Expand Down Expand Up @@ -168,8 +168,6 @@ initrd.txt
- how to use the RAM disk as an initial/temporary root filesystem.
input/
- info on Linux input device support.
io-mapping.txt
- description of io_mapping functions in linux/io-mapping.h
io_ordering.txt
- info on ordering I/O writes to memory-mapped addresses.
ioctl/
Expand Down
40 changes: 40 additions & 0 deletions trunk/Documentation/ABI/testing/sysfs-bus-pci
View file
Original file line number Diff line number Diff line change
Expand Up @@ -133,6 +133,46 @@ Description:
The symbolic link points to the PCI device sysfs entry of the
Physical Function this device associates with.


What: /sys/bus/pci/slots/...
Date: April 2005 (possibly older)
KernelVersion: 2.6.12 (possibly older)
Contact: linux-pci@vger.kernel.org
Description:
When the appropriate driver is loaded, it will create a
directory per claimed physical PCI slot in
/sys/bus/pci/slots/. The names of these directories are
specific to the driver, which in turn, are specific to the
platform, but in general, should match the label on the
machine's physical chassis.

The drivers that can create slot directories include the
PCI hotplug drivers, and as of 2.6.27, the pci_slot driver.

The slot directories contain, at a minimum, a file named
'address' which contains the PCI bus:device:function tuple.
Other files may appear as well, but are specific to the
driver.

What: /sys/bus/pci/slots/.../function[0-7]
Date: March 2010
KernelVersion: 2.6.35
Contact: linux-pci@vger.kernel.org
Description:
If PCI slot directories (as described above) are created,
and the physical slot is actually populated with a device,
symbolic links in the slot directory pointing to the
device's PCI functions are created as well.

What: /sys/bus/pci/devices/.../slot
Date: March 2010
KernelVersion: 2.6.35
Contact: linux-pci@vger.kernel.org
Description:
If PCI slot directories (as described above) are created,
a symbolic link pointing to the slot directory will be
created as well.

What: /sys/bus/pci/slots/.../module
Date: June 2009
Contact: linux-pci@vger.kernel.org
Expand Down
12 changes: 6 additions & 6 deletions trunk/Documentation/DocBook/drm.tmpl
View file
Original file line number Diff line number Diff line change
Expand Up @@ -389,7 +389,7 @@
</para>
<para>
If your driver supports memory management (it should!), you'll
need to set that up at load time as well. How you initialize
need to set that up at load time as well. How you intialize
it depends on which memory manager you're using, TTM or GEM.
</para>
<sect3>
Expand All @@ -399,7 +399,7 @@
aperture space for graphics devices. TTM supports both UMA devices
and devices with dedicated video RAM (VRAM), i.e. most discrete
graphics devices. If your device has dedicated RAM, supporting
TTM is desirable. TTM also integrates tightly with your
TTM is desireable. TTM also integrates tightly with your
driver specific buffer execution function. See the radeon
driver for examples.
</para>
Expand Down Expand Up @@ -443,7 +443,7 @@
likely eventually calling ttm_bo_global_init and
ttm_bo_global_release, respectively. Also like the previous
object, ttm_global_item_ref is used to create an initial reference
count for the TTM, which will call your initialization function.
count for the TTM, which will call your initalization function.
</para>
</sect3>
<sect3>
Expand Down Expand Up @@ -557,7 +557,7 @@ void intel_crt_init(struct drm_device *dev)
CRT connector and encoder combination is created. A device
specific i2c bus is also created, for fetching EDID data and
performing monitor detection. Once the process is complete,
the new connector is registered with sysfs, to make its
the new connector is regsitered with sysfs, to make its
properties available to applications.
</para>
<sect4>
Expand All @@ -581,12 +581,12 @@ void intel_crt_init(struct drm_device *dev)
<para>
For each encoder, CRTC and connector, several functions must
be provided, depending on the object type. Encoder objects
need to provide a DPMS (basically on/off) function, mode fixup
need should provide a DPMS (basically on/off) function, mode fixup
(for converting requested modes into native hardware timings),
and prepare, set and commit functions for use by the core DRM
helper functions. Connector helpers need to provide mode fetch and
validity functions as well as an encoder matching function for
returning an ideal encoder for a given connector. The core
returing an ideal encoder for a given connector. The core
connector functions include a DPMS callback, (deprecated)
save/restore routines, detection, mode probing, property handling,
and cleanup functions.
Expand Down
2 changes: 1 addition & 1 deletion trunk/Documentation/DocBook/v4l/v4l2.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -58,7 +58,7 @@ MPEG stream embedded, sliced VBI data format in this specification.
</contrib>
<affiliation>
<address>
<email>awalls@md.metrocast.net</email>
<email>awalls@radix.net</email>
</address>
</affiliation>
</author>
Expand Down
6 changes: 2 additions & 4 deletions trunk/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -53,10 +53,8 @@ input</refpurpose>
automatically, similar to sensing the video standard. To do so, applications
call <constant> VIDIOC_QUERY_DV_PRESET</constant> with a pointer to a
&v4l2-dv-preset; type. Once the hardware detects a preset, that preset is
returned in the preset field of &v4l2-dv-preset;. If the preset could not be
detected because there was no signal, or the signal was unreliable, or the
signal did not map to a supported preset, then the value V4L2_DV_INVALID is
returned.</para>
returned in the preset field of &v4l2-dv-preset;. When detection is not
possible or fails, the value V4L2_DV_INVALID is returned.</para>
</refsect1>

<refsect1>
Expand Down
0 ...k/Documentation/bus-virt-phys-mapping.txt → trunk/Documentation/IO-mapping.txt
View file
File renamed without changes.
152 changes: 0 additions & 152 deletions trunk/Documentation/edac.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,6 @@ Written by Doug Thompson <dougthompson@xmission.com>
7 Dec 2005
17 Jul 2007 Updated

(c) Mauro Carvalho Chehab <mchehab@redhat.com>
05 Aug 2009 Nehalem interface

EDAC is maintained and written by:

Expand Down Expand Up @@ -719,153 +717,3 @@ unique drivers for their hardware systems.
The 'test_device_edac' sample driver is located at the
bluesmoke.sourceforge.net project site for EDAC.

=======================================================================
NEHALEM USAGE OF EDAC APIs

This chapter documents some EXPERIMENTAL mappings for EDAC API to handle
Nehalem EDAC driver. They will likely be changed on future versions
of the driver.

Due to the way Nehalem exports Memory Controller data, some adjustments
were done at i7core_edac driver. This chapter will cover those differences

1) On Nehalem, there are one Memory Controller per Quick Patch Interconnect
(QPI). At the driver, the term "socket" means one QPI. This is
associated with a physical CPU socket.

Each MC have 3 physical read channels, 3 physical write channels and
3 logic channels. The driver currenty sees it as just 3 channels.
Each channel can have up to 3 DIMMs.

The minimum known unity is DIMMs. There are no information about csrows.
As EDAC API maps the minimum unity is csrows, the driver sequencially
maps channel/dimm into different csrows.

For example, suposing the following layout:
Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs
dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400
Ch1 phy rd1, wr1 (0x063f4031): 2 ranks, UDIMMs
dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
Ch2 phy rd3, wr3 (0x063f4031): 2 ranks, UDIMMs
dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
The driver will map it as:
csrow0: channel 0, dimm0
csrow1: channel 0, dimm1
csrow2: channel 1, dimm0
csrow3: channel 2, dimm0

exports one
DIMM per csrow.

Each QPI is exported as a different memory controller.

2) Nehalem MC has the hability to generate errors. The driver implements this
functionality via some error injection nodes:

For injecting a memory error, there are some sysfs nodes, under
/sys/devices/system/edac/mc/mc?/:

inject_addrmatch/*:
Controls the error injection mask register. It is possible to specify
several characteristics of the address to match an error code:
dimm = the affected dimm. Numbers are relative to a channel;
rank = the memory rank;
channel = the channel that will generate an error;
bank = the affected bank;
page = the page address;
column (or col) = the address column.
each of the above values can be set to "any" to match any valid value.

At driver init, all values are set to any.

For example, to generate an error at rank 1 of dimm 2, for any channel,
any bank, any page, any column:
echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
echo 1 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank

To return to the default behaviour of matching any, you can do:
echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm
echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank

inject_eccmask:
specifies what bits will have troubles,

inject_section:
specifies what ECC cache section will get the error:
3 for both
2 for the highest
1 for the lowest

inject_type:
specifies the type of error, being a combination of the following bits:
bit 0 - repeat
bit 1 - ecc
bit 2 - parity

inject_enable starts the error generation when something different
than 0 is written.

All inject vars can be read. root permission is needed for write.

Datasheet states that the error will only be generated after a write on an
address that matches inject_addrmatch. It seems, however, that reading will
also produce an error.

For example, the following code will generate an error for any write access
at socket 0, on any DIMM/address on channel 2:

echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/channel
echo 2 >/sys/devices/system/edac/mc/mc0/inject_type
echo 64 >/sys/devices/system/edac/mc/mc0/inject_eccmask
echo 3 >/sys/devices/system/edac/mc/mc0/inject_section
echo 1 >/sys/devices/system/edac/mc/mc0/inject_enable
dd if=/dev/mem of=/dev/null seek=16k bs=4k count=1 >& /dev/null

For socket 1, it is needed to replace "mc0" by "mc1" at the above
commands.

The generated error message will look like:

EDAC MC0: UE row 0, channel-a= 0 channel-b= 0 labels "-": NON_FATAL (addr = 0x0075b980, socket=0, Dimm=0, Channel=2, syndrome=0x00000040, count=1, Err=8c0000400001009f:4000080482 (read error: read ECC error))

3) Nehalem specific Corrected Error memory counters

Nehalem have some registers to count memory errors. The driver uses those
registers to report Corrected Errors on devices with Registered Dimms.

However, those counters don't work with Unregistered Dimms. As the chipset
offers some counters that also work with UDIMMS (but with a worse level of
granularity than the default ones), the driver exposes those registers for
UDIMM memories.

They can be read by looking at the contents of all_channel_counts/

$ for i in /sys/devices/system/edac/mc/mc0/all_channel_counts/*; do echo $i; cat $i; done
/sys/devices/system/edac/mc/mc0/all_channel_counts/udimm0
0
/sys/devices/system/edac/mc/mc0/all_channel_counts/udimm1
0
/sys/devices/system/edac/mc/mc0/all_channel_counts/udimm2
0

What happens here is that errors on different csrows, but at the same
dimm number will increment the same counter.
So, in this memory mapping:
csrow0: channel 0, dimm0
csrow1: channel 0, dimm1
csrow2: channel 1, dimm0
csrow3: channel 2, dimm0
The hardware will increment udimm0 for an error at the first dimm at either
csrow0, csrow2 or csrow3;
The hardware will increment udimm1 for an error at the second dimm at either
csrow0, csrow2 or csrow3;
The hardware will increment udimm2 for an error at the third dimm at either
csrow0, csrow2 or csrow3;

4) Standard error counters

The standard error counters are generated when an mcelog error is received
by the driver. Since, with udimm, this is counted by software, it is
possible that some errors could be lost. With rdimm's, they displays the
contents of the registers
16 changes: 9 additions & 7 deletions trunk/Documentation/feature-removal-schedule.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -578,6 +578,15 @@ Who: Avi Kivity <avi@redhat.com>

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

What: "acpi=ht" boot option
When: 2.6.35
Why: Useful in 2003, implementation is a hack.
Generally invoked by accident today.
Seen as doing more harm than good.
Who: Len Brown <len.brown@intel.com>

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

What: iwlwifi 50XX module parameters
When: 2.6.40
Why: The "..50" modules parameters were used to configure 5000 series and
Expand Down Expand Up @@ -647,10 +656,3 @@ Who: Stefan Richter <stefanr@s5r6.in-berlin.de>

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

What: The acpi_sleep=s4_nonvs command line option
When: 2.6.37
Files: arch/x86/kernel/acpi/sleep.c
Why: superseded by acpi_sleep=nonvs
Who: Rafael J. Wysocki <rjw@sisk.pl>

----------------------------
5 changes: 5 additions & 0 deletions trunk/Documentation/filesystems/xfs-delayed-logging-design.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -794,6 +794,11 @@ designed.

Roadmap:

2.6.35 Inclusion in mainline as an experimental mount option
=> approximately 2-3 months to merge window
=> needs to be in xfs-dev tree in 4-6 weeks
=> code is nearing readiness for review

2.6.37 Remove experimental tag from mount option
=> should be roughly 6 months after initial merge
=> enough time to:
Expand Down
4 changes: 2 additions & 2 deletions trunk/Documentation/i2c/busses/i2c-ali1535
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6,12 +6,12 @@ Supported adapters:
http://www.ali.com.tw/eng/support/datasheet_request.php

Authors:
Frodo Looijaard <frodol@dds.nl>,
Frodo Looijaard <frodol@dds.nl>,
Philip Edelbrock <phil@netroedge.com>,
Mark D. Studebaker <mdsxyz123@yahoo.com>,
Dan Eaton <dan.eaton@rocketlogix.com>,
Stephen Rousset<stephen.rousset@rocketlogix.com>

Description
-----------

Expand Down
2 changes: 1 addition & 1 deletion trunk/Documentation/i2c/busses/i2c-ali1563
View file
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ For an overview of these chips see http://www.acerlabs.com
The M1563 southbridge is deceptively similar to the M1533, with a few
notable exceptions. One of those happens to be the fact they upgraded the
i2c core to be SMBus 2.0 compliant, and happens to be almost identical to
the i2c controller found in the Intel 801 south bridges.
the i2c controller found in the Intel 801 south bridges.

Features
--------
Expand Down
Loading

0 comments on commit 8e477f2

Please sign in to comment.