Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history 
yaml
---
r: 201920
b: refs/heads/master
c: eb605a5
h: refs/heads/master
v: v3
  • Loading branch information
FUJITA Tomonori authored and Konrad Rzeszutek Wilk committed Jun 7, 2010
1 parent 0c2d3e0 commit 43f0b1d
Show file tree
Hide file tree
Showing 2,349 changed files with 222,217 additions and 117,588 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: 7e6880951da86928c7f6cecf26dcb8e8d9f826da
refs/heads/master: eb605a5754d050a25a9f00d718fb173f24c486ef
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
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.
39 changes: 0 additions & 39 deletions trunk/Documentation/apparmor.txt
View file

This file was deleted.

8 changes: 1 addition & 7 deletions trunk/Documentation/arm/memory.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -33,13 +33,7 @@ ffff0000 ffff0fff CPU vector page.

fffe0000 fffeffff XScale cache flush area. This is used
in proc-xscale.S to flush the whole data
cache. (XScale does not have TCM.)

fffe8000 fffeffff DTCM mapping area for platforms with
DTCM mounted inside the CPU.

fffe0000 fffe7fff ITCM mapping area for platforms with
ITCM mounted inside the CPU.
cache. Free for other usage on non-XScale.

fff00000 fffdffff Fixmap mapping region. Addresses provided
by fix_to_virt() will be located here.
Expand Down
30 changes: 11 additions & 19 deletions trunk/Documentation/arm/tcm.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -19,8 +19,8 @@ defines a CPUID_TCM register that you can read out from the
system control coprocessor. Documentation from ARM can be found
at http://infocenter.arm.com, search for "TCM Status Register"
to see documents for all CPUs. Reading this register you can
determine if ITCM (bits 1-0) and/or DTCM (bit 17-16) is present
in the machine.
determine if ITCM (bit 0) and/or DTCM (bit 16) is present in the
machine.

There is further a TCM region register (search for "TCM Region
Registers" at the ARM site) that can report and modify the location
Expand All @@ -35,15 +35,7 @@ The TCM memory can then be remapped to another address again using
the MMU, but notice that the TCM if often used in situations where
the MMU is turned off. To avoid confusion the current Linux
implementation will map the TCM 1 to 1 from physical to virtual
memory in the location specified by the kernel. Currently Linux
will map ITCM to 0xfffe0000 and on, and DTCM to 0xfffe8000 and
on, supporting a maximum of 32KiB of ITCM and 32KiB of DTCM.

Newer versions of the region registers also support dividing these
TCMs in two separate banks, so for example an 8KiB ITCM is divided
into two 4KiB banks with its own control registers. The idea is to
be able to lock and hide one of the banks for use by the secure
world (TrustZone).
memory in the location specified by the machine.

TCM is used for a few things:

Expand Down Expand Up @@ -73,18 +65,18 @@ in <asm/tcm.h>. Using this interface it is possible to:
memory. Such a heap is great for things like saving
device state when shutting off device power domains.

A machine that has TCM memory shall select HAVE_TCM from
arch/arm/Kconfig for itself. Code that needs to use TCM shall
#include <asm/tcm.h>
A machine that has TCM memory shall select HAVE_TCM in
arch/arm/Kconfig for itself, and then the
rest of the functionality will depend on the physical
location and size of ITCM and DTCM to be defined in
mach/memory.h for the machine. Code that needs to use
TCM shall #include <asm/tcm.h> If the TCM is not located
at the place given in memory.h it will be moved using
the TCM Region registers.

Functions to go into itcm can be tagged like this:
int __tcmfunc foo(int bar);

Since these are marked to become long_calls and you may want
to have functions called locally inside the TCM without
wasting space, there is also the __tcmlocalfunc prefix that
will make the call relative.

Variables to go into dtcm can be tagged like this:
int __tcmdata foo;

Expand Down
3 changes: 0 additions & 3 deletions trunk/Documentation/credentials.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -417,9 +417,6 @@ reference on them using:
This does all the RCU magic inside of it. The caller must call put_cred() on
the credentials so obtained when they're finished with.

[*] Note: The result of __task_cred() should not be passed directly to
get_cred() as this may race with commit_cred().

There are a couple of convenience functions to access bits of another task's
credentials, hiding the RCU magic from the caller:

Expand Down
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
Loading

0 comments on commit 43f0b1d

Please sign in to comment.