You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/holtmann/bluetooth-next-2.6
Conflicts: drivers/net/wireless/iwlwifi/iwl-commands.h
This commit is contained in:
@@ -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
|
||||
|
||||
@@ -0,0 +1,20 @@
|
||||
What: /sys/class/power/ds2760-battery.*/charge_now
|
||||
Date: May 2010
|
||||
KernelVersion: 2.6.35
|
||||
Contact: Daniel Mack <daniel@caiaq.de>
|
||||
Description:
|
||||
This file is writeable and can be used to set the current
|
||||
coloumb counter value inside the battery monitor chip. This
|
||||
is needed for unavoidable corrections of aging batteries.
|
||||
A userspace daemon can monitor the battery charging logic
|
||||
and once the counter drops out of considerable bounds, take
|
||||
appropriate action.
|
||||
|
||||
What: /sys/class/power/ds2760-battery.*/charge_full
|
||||
Date: May 2010
|
||||
KernelVersion: 2.6.35
|
||||
Contact: Daniel Mack <daniel@caiaq.de>
|
||||
Description:
|
||||
This file is writeable and can be used to set the assumed
|
||||
battery 'full level'. As batteries age, this value has to be
|
||||
amended over time.
|
||||
@@ -0,0 +1,7 @@
|
||||
What: /sys/devices/system/node/nodeX/compact
|
||||
Date: February 2010
|
||||
Contact: Mel Gorman <mel@csn.ul.ie>
|
||||
Description:
|
||||
When this file is written to, all memory within that node
|
||||
will be compacted. When it completes, memory will be freed
|
||||
into blocks which have as many contiguous pages as possible
|
||||
@@ -0,0 +1,43 @@
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/operation_mode
|
||||
Date: March 2010
|
||||
Contact: Bruno Prémont <bonbons@linux-vserver.org>
|
||||
Description: Make it possible to switch the PicoLCD device between LCD
|
||||
(firmware) and bootloader (flasher) operation modes.
|
||||
|
||||
Reading: returns list of available modes, the active mode being
|
||||
enclosed in brackets ('[' and ']')
|
||||
|
||||
Writing: causes operation mode switch. Permitted values are
|
||||
the non-active mode names listed when read.
|
||||
|
||||
Note: when switching mode the current PicoLCD HID device gets
|
||||
disconnected and reconnects after above delay (see attribute
|
||||
operation_mode_delay for its value).
|
||||
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/operation_mode_delay
|
||||
Date: April 2010
|
||||
Contact: Bruno Prémont <bonbons@linux-vserver.org>
|
||||
Description: Delay PicoLCD waits before restarting in new mode when
|
||||
operation_mode has changed.
|
||||
|
||||
Reading/Writing: It is expressed in ms and permitted range is
|
||||
0..30000ms.
|
||||
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/fb_update_rate
|
||||
Date: March 2010
|
||||
Contact: Bruno Prémont <bonbons@linux-vserver.org>
|
||||
Description: Make it possible to adjust defio refresh rate.
|
||||
|
||||
Reading: returns list of available refresh rates (expressed in Hz),
|
||||
the active refresh rate being enclosed in brackets ('[' and ']')
|
||||
|
||||
Writing: accepts new refresh rate expressed in integer Hz
|
||||
within permitted rates.
|
||||
|
||||
Note: As device can barely do 2 complete refreshes a second
|
||||
it only makes sense to adjust this value if only one or two
|
||||
tiles get changed and it's not appropriate to expect the application
|
||||
to flush it's tiny changes explicitely at higher than default rate.
|
||||
|
||||
@@ -0,0 +1,29 @@
|
||||
What: /sys/bus/hid/drivers/prodikeys/.../channel
|
||||
Date: April 2010
|
||||
KernelVersion: 2.6.34
|
||||
Contact: Don Prince <dhprince.devel@yahoo.co.uk>
|
||||
Description:
|
||||
Allows control (via software) the midi channel to which
|
||||
that the pc-midi keyboard will output.midi data.
|
||||
Range: 0..15
|
||||
Type: Read/write
|
||||
What: /sys/bus/hid/drivers/prodikeys/.../sustain
|
||||
Date: April 2010
|
||||
KernelVersion: 2.6.34
|
||||
Contact: Don Prince <dhprince.devel@yahoo.co.uk>
|
||||
Description:
|
||||
Allows control (via software) the sustain duration of a
|
||||
note held by the pc-midi driver.
|
||||
0 means sustain mode is disabled.
|
||||
Range: 0..5000 (milliseconds)
|
||||
Type: Read/write
|
||||
What: /sys/bus/hid/drivers/prodikeys/.../octave
|
||||
Date: April 2010
|
||||
KernelVersion: 2.6.34
|
||||
Contact: Don Prince <dhprince.devel@yahoo.co.uk>
|
||||
Description:
|
||||
Controls the octave shift modifier in the pc-midi driver.
|
||||
The octave can be shifted via software up/down 2 octaves.
|
||||
0 means the no ocatve shift.
|
||||
Range: -2..2 (minus 2 to plus 2)
|
||||
Type: Read/Write
|
||||
@@ -0,0 +1,111 @@
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_dpi
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: It is possible to switch the dpi setting of the mouse with the
|
||||
press of a button.
|
||||
When read, this file returns the raw number of the actual dpi
|
||||
setting reported by the mouse. This number has to be further
|
||||
processed to receive the real dpi value.
|
||||
|
||||
VALUE DPI
|
||||
1 800
|
||||
2 1200
|
||||
3 1600
|
||||
4 2000
|
||||
5 2400
|
||||
6 3200
|
||||
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/actual_profile
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the number of the actual profile.
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/firmware_version
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the raw integer version number of the
|
||||
firmware reported by the mouse. Using the integer value eases
|
||||
further usage in other programs. To receive the real version
|
||||
number the decimal point has to be shifted 2 positions to the
|
||||
left. E.g. a returned value of 138 means 1.38
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/kone_driver_version
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the driver version.
|
||||
The format of the string is "v<major>.<minor>.<patchlevel>".
|
||||
This attribute is used by the userland tools to find the sysfs-
|
||||
paths of installed kone-mice and determine the capabilites of
|
||||
the driver. Versions of this driver for old kernels replace
|
||||
usbhid instead of generic-usb. The way to scan for this file
|
||||
has been chosen to provide a consistent way for all supported
|
||||
kernel versions.
|
||||
This file is readonly.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/profile[1-5]
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can store 5 profiles which can be switched by the
|
||||
press of a button. A profile holds informations like button
|
||||
mappings, sensitivity, the colors of the 5 leds and light
|
||||
effects.
|
||||
When read, these files return the respective profile. The
|
||||
returned data is 975 bytes in size.
|
||||
When written, this file lets one write the respective profile
|
||||
data back to the mouse. The data has to be 975 bytes long.
|
||||
The mouse will reject invalid data, whereas the profile number
|
||||
stored in the profile doesn't need to fit the number of the
|
||||
store.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/settings
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns the settings stored in the mouse.
|
||||
The size of the data is 36 bytes and holds information like the
|
||||
startup_profile, tcu state and calibration_data.
|
||||
When written, this file lets write settings back to the mouse.
|
||||
The data has to be 36 bytes long. The mouse will reject invalid
|
||||
data.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/startup_profile
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 1 to 5.
|
||||
When read, this attribute returns the number of the profile
|
||||
that's active when the mouse is powered on.
|
||||
When written, this file sets the number of the startup profile
|
||||
and the mouse activates this profile immediately.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/tcu
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse has a "Tracking Control Unit" which lets the user
|
||||
calibrate the laser power to fit the mousepad surface.
|
||||
When read, this file returns the current state of the TCU,
|
||||
where 0 means off and 1 means on.
|
||||
Writing 0 in this file will switch the TCU off.
|
||||
Writing 1 in this file will start the calibration which takes
|
||||
around 6 seconds to complete and activates the TCU.
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/weight
|
||||
Date: March 2010
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The mouse can be equipped with one of four supplied weights
|
||||
ranging from 5 to 20 grams which are recognized by the mouse
|
||||
and its value can be read out. When read, this file returns the
|
||||
raw value returned by the mouse which eases further processing
|
||||
in other software.
|
||||
The values map to the weights as follows:
|
||||
|
||||
VALUE WEIGHT
|
||||
0 none
|
||||
1 5g
|
||||
2 10g
|
||||
3 15g
|
||||
4 20g
|
||||
|
||||
This file is readonly.
|
||||
@@ -0,0 +1,15 @@
|
||||
What: /sys/firmware/sfi/tables/
|
||||
Date: May 2010
|
||||
Contact: Len Brown <lenb@kernel.org>
|
||||
Description:
|
||||
SFI defines a number of small static memory tables
|
||||
so the kernel can get platform information from firmware.
|
||||
|
||||
The tables are defined in the latest SFI specification:
|
||||
http://simplefirmware.org/documentation
|
||||
|
||||
While the tables are used by the kernel, user-space
|
||||
can observe them this way:
|
||||
|
||||
# cd /sys/firmware/sfi/tables
|
||||
# cat $TABLENAME > $TABLENAME.bin
|
||||
@@ -0,0 +1,10 @@
|
||||
What: /sys/class/hidraw/hidraw*/device/speed
|
||||
Date: April 2010
|
||||
Kernel Version: 2.6.35
|
||||
Contact: linux-bluetooth@vger.kernel.org
|
||||
Description:
|
||||
The /sys/class/hidraw/hidraw*/device/speed file controls
|
||||
reporting speed of wacom bluetooth tablet. Reading from
|
||||
this file returns 1 if tablet reports in high speed mode
|
||||
or 0 otherwise. Writing to this file one of these values
|
||||
switches reporting speed.
|
||||
@@ -639,6 +639,36 @@ is planned to completely remove virt_to_bus() and bus_to_virt() as
|
||||
they are entirely deprecated. Some ports already do not provide these
|
||||
as it is impossible to correctly support them.
|
||||
|
||||
Handling Errors
|
||||
|
||||
DMA address space is limited on some architectures and an allocation
|
||||
failure can be determined by:
|
||||
|
||||
- checking if dma_alloc_coherent returns NULL or dma_map_sg returns 0
|
||||
|
||||
- checking the returned dma_addr_t of dma_map_single and dma_map_page
|
||||
by using dma_mapping_error():
|
||||
|
||||
dma_addr_t dma_handle;
|
||||
|
||||
dma_handle = dma_map_single(dev, addr, size, direction);
|
||||
if (dma_mapping_error(dev, dma_handle)) {
|
||||
/*
|
||||
* reduce current DMA mapping usage,
|
||||
* delay and try again later or
|
||||
* reset driver.
|
||||
*/
|
||||
}
|
||||
|
||||
Networking drivers must call dev_kfree_skb to free the socket buffer
|
||||
and return NETDEV_TX_OK if the DMA mapping fails on the transmit hook
|
||||
(ndo_start_xmit). This means that the socket buffer is just dropped in
|
||||
the failure case.
|
||||
|
||||
SCSI drivers must return SCSI_MLQUEUE_HOST_BUSY if the DMA mapping
|
||||
fails in the queuecommand hook. This means that the SCSI subsystem
|
||||
passes the command to the driver again later.
|
||||
|
||||
Optimizing Unmap State Space Consumption
|
||||
|
||||
On many platforms, dma_unmap_{single,page}() is simply a nop.
|
||||
@@ -703,42 +733,25 @@ to "Closing".
|
||||
|
||||
1) Struct scatterlist requirements.
|
||||
|
||||
Struct scatterlist must contain, at a minimum, the following
|
||||
members:
|
||||
Don't invent the architecture specific struct scatterlist; just use
|
||||
<asm-generic/scatterlist.h>. You need to enable
|
||||
CONFIG_NEED_SG_DMA_LENGTH if the architecture supports IOMMUs
|
||||
(including software IOMMU).
|
||||
|
||||
struct page *page;
|
||||
unsigned int offset;
|
||||
unsigned int length;
|
||||
2) ARCH_KMALLOC_MINALIGN
|
||||
|
||||
The base address is specified by a "page+offset" pair.
|
||||
Architectures must ensure that kmalloc'ed buffer is
|
||||
DMA-safe. Drivers and subsystems depend on it. If an architecture
|
||||
isn't fully DMA-coherent (i.e. hardware doesn't ensure that data in
|
||||
the CPU cache is identical to data in main memory),
|
||||
ARCH_KMALLOC_MINALIGN must be set so that the memory allocator
|
||||
makes sure that kmalloc'ed buffer doesn't share a cache line with
|
||||
the others. See arch/arm/include/asm/cache.h as an example.
|
||||
|
||||
Previous versions of struct scatterlist contained a "void *address"
|
||||
field that was sometimes used instead of page+offset. As of Linux
|
||||
2.5., page+offset is always used, and the "address" field has been
|
||||
deleted.
|
||||
|
||||
2) More to come...
|
||||
|
||||
Handling Errors
|
||||
|
||||
DMA address space is limited on some architectures and an allocation
|
||||
failure can be determined by:
|
||||
|
||||
- checking if dma_alloc_coherent returns NULL or dma_map_sg returns 0
|
||||
|
||||
- checking the returned dma_addr_t of dma_map_single and dma_map_page
|
||||
by using dma_mapping_error():
|
||||
|
||||
dma_addr_t dma_handle;
|
||||
|
||||
dma_handle = dma_map_single(dev, addr, size, direction);
|
||||
if (dma_mapping_error(dev, dma_handle)) {
|
||||
/*
|
||||
* reduce current DMA mapping usage,
|
||||
* delay and try again later or
|
||||
* reset driver.
|
||||
*/
|
||||
}
|
||||
Note that ARCH_KMALLOC_MINALIGN is about DMA memory alignment
|
||||
constraints. You don't need to worry about the architecture data
|
||||
alignment constraints (e.g. the alignment constraints about 64-bit
|
||||
objects).
|
||||
|
||||
Closing
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@ DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \
|
||||
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
|
||||
mac80211.xml debugobjects.xml sh.xml regulator.xml \
|
||||
alsa-driver-api.xml writing-an-alsa-driver.xml \
|
||||
tracepoint.xml media.xml
|
||||
tracepoint.xml media.xml drm.xml
|
||||
|
||||
###
|
||||
# The build process is as follows (targets):
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
+526
-186
File diff suppressed because it is too large
Load Diff
@@ -269,7 +269,7 @@ static void board_hwcontrol(struct mtd_info *mtd, int cmd)
|
||||
information about the device.
|
||||
</para>
|
||||
<programlisting>
|
||||
int __init board_init (void)
|
||||
static int __init board_init (void)
|
||||
{
|
||||
struct nand_chip *this;
|
||||
int err = 0;
|
||||
|
||||
@@ -13,7 +13,7 @@ Reporting (AER) driver and provides information on how to use it, as
|
||||
well as how to enable the drivers of endpoint devices to conform with
|
||||
PCI Express AER driver.
|
||||
|
||||
1.2 Copyright © Intel Corporation 2006.
|
||||
1.2 Copyright (C) Intel Corporation 2006.
|
||||
|
||||
1.3 What is the PCI Express AER Driver?
|
||||
|
||||
@@ -71,15 +71,11 @@ console. If it's a correctable error, it is outputed as a warning.
|
||||
Otherwise, it is printed as an error. So users could choose different
|
||||
log level to filter out correctable error messages.
|
||||
|
||||
Below shows an example.
|
||||
+------ PCI-Express Device Error -----+
|
||||
Error Severity : Uncorrected (Fatal)
|
||||
PCIE Bus Error type : Transaction Layer
|
||||
Unsupported Request : First
|
||||
Requester ID : 0500
|
||||
VendorID=8086h, DeviceID=0329h, Bus=05h, Device=00h, Function=00h
|
||||
TLB Header:
|
||||
04000001 00200a03 05010000 00050100
|
||||
Below shows an example:
|
||||
0000:50:00.0: PCIe Bus Error: severity=Uncorrected (Fatal), type=Transaction Layer, id=0500(Requester ID)
|
||||
0000:50:00.0: device [8086:0329] error status/mask=00100000/00000000
|
||||
0000:50:00.0: [20] Unsupported Request (First)
|
||||
0000:50:00.0: TLP Header: 04000001 00200a03 05010000 00050100
|
||||
|
||||
In the example, 'Requester ID' means the ID of the device who sends
|
||||
the error message to root port. Pls. refer to pci express specs for
|
||||
@@ -112,7 +108,7 @@ but the PCI Express link itself is fully functional. Fatal errors, on
|
||||
the other hand, cause the link to be unreliable.
|
||||
|
||||
When AER is enabled, a PCI Express device will automatically send an
|
||||
error message to the PCIE root port above it when the device captures
|
||||
error message to the PCIe root port above it when the device captures
|
||||
an error. The Root Port, upon receiving an error reporting message,
|
||||
internally processes and logs the error message in its PCI Express
|
||||
capability structure. Error information being logged includes storing
|
||||
@@ -198,8 +194,9 @@ to reset link, AER port service driver is required to provide the
|
||||
function to reset link. Firstly, kernel looks for if the upstream
|
||||
component has an aer driver. If it has, kernel uses the reset_link
|
||||
callback of the aer driver. If the upstream component has no aer driver
|
||||
and the port is downstream port, we will use the aer driver of the
|
||||
root port who reports the AER error. As for upstream ports,
|
||||
and the port is downstream port, we will perform a hot reset as the
|
||||
default by setting the Secondary Bus Reset bit of the Bridge Control
|
||||
register associated with the downstream port. As for upstream ports,
|
||||
they should provide their own aer service drivers with reset_link
|
||||
function. If error_detected returns PCI_ERS_RESULT_CAN_RECOVER and
|
||||
reset_link returns PCI_ERS_RESULT_RECOVERED, the error handling goes
|
||||
@@ -253,11 +250,11 @@ cleanup uncorrectable status register. Pls. refer to section 3.3.
|
||||
|
||||
4. Software error injection
|
||||
|
||||
Debugging PCIE AER error recovery code is quite difficult because it
|
||||
Debugging PCIe AER error recovery code is quite difficult because it
|
||||
is hard to trigger real hardware errors. Software based error
|
||||
injection can be used to fake various kinds of PCIE errors.
|
||||
injection can be used to fake various kinds of PCIe errors.
|
||||
|
||||
First you should enable PCIE AER software error injection in kernel
|
||||
First you should enable PCIe AER software error injection in kernel
|
||||
configuration, that is, following item should be in your .config.
|
||||
|
||||
CONFIG_PCIEAER_INJECT=y or CONFIG_PCIEAER_INJECT=m
|
||||
|
||||
@@ -18,6 +18,8 @@ kernel patches.
|
||||
|
||||
2b: Passes allnoconfig, allmodconfig
|
||||
|
||||
2c: Builds successfully when using O=builddir
|
||||
|
||||
3: Builds on multiple CPU architectures by using local cross-compile tools
|
||||
or some other build farm.
|
||||
|
||||
@@ -95,3 +97,13 @@ kernel patches.
|
||||
|
||||
25: If any ioctl's are added by the patch, then also update
|
||||
Documentation/ioctl/ioctl-number.txt.
|
||||
|
||||
26: If your modified source code depends on or uses any of the kernel
|
||||
APIs or features that are related to the following kconfig symbols,
|
||||
then test multiple builds with the related kconfig symbols disabled
|
||||
and/or =m (if that option is available) [not all of these at the
|
||||
same time, just various/random combinations of them]:
|
||||
|
||||
CONFIG_SMP, CONFIG_SYSFS, CONFIG_PROC_FS, CONFIG_INPUT, CONFIG_PCI,
|
||||
CONFIG_BLOCK, CONFIG_PM, CONFIG_HOTPLUG, CONFIG_MAGIC_SYSRQ,
|
||||
CONFIG_NET, CONFIG_INET=n (but latter with CONFIG_NET=y)
|
||||
|
||||
@@ -130,6 +130,8 @@ Linux kernel master tree:
|
||||
ftp.??.kernel.org:/pub/linux/kernel/...
|
||||
?? == your country code, such as "us", "uk", "fr", etc.
|
||||
|
||||
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git
|
||||
|
||||
Linux kernel mailing list:
|
||||
linux-kernel@vger.kernel.org
|
||||
[mail majordomo@vger.kernel.org to subscribe]
|
||||
@@ -160,3 +162,6 @@ How to NOT write kernel driver by Arjan van de Ven:
|
||||
|
||||
Kernel Janitor:
|
||||
http://janitor.kernelnewbies.org/
|
||||
|
||||
GIT, Fast Version Control System:
|
||||
http://git-scm.com/
|
||||
|
||||
@@ -0,0 +1,59 @@
|
||||
APEI Error INJection
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
EINJ provides a hardware error injection mechanism
|
||||
It is very useful for debugging and testing of other APEI and RAS features.
|
||||
|
||||
To use EINJ, make sure the following are enabled in your kernel
|
||||
configuration:
|
||||
|
||||
CONFIG_DEBUG_FS
|
||||
CONFIG_ACPI_APEI
|
||||
CONFIG_ACPI_APEI_EINJ
|
||||
|
||||
The user interface of EINJ is debug file system, under the
|
||||
directory apei/einj. The following files are provided.
|
||||
|
||||
- available_error_type
|
||||
Reading this file returns the error injection capability of the
|
||||
platform, that is, which error types are supported. The error type
|
||||
definition is as follow, the left field is the error type value, the
|
||||
right field is error description.
|
||||
|
||||
0x00000001 Processor Correctable
|
||||
0x00000002 Processor Uncorrectable non-fatal
|
||||
0x00000004 Processor Uncorrectable fatal
|
||||
0x00000008 Memory Correctable
|
||||
0x00000010 Memory Uncorrectable non-fatal
|
||||
0x00000020 Memory Uncorrectable fatal
|
||||
0x00000040 PCI Express Correctable
|
||||
0x00000080 PCI Express Uncorrectable fatal
|
||||
0x00000100 PCI Express Uncorrectable non-fatal
|
||||
0x00000200 Platform Correctable
|
||||
0x00000400 Platform Uncorrectable non-fatal
|
||||
0x00000800 Platform Uncorrectable fatal
|
||||
|
||||
The format of file contents are as above, except there are only the
|
||||
available error type lines.
|
||||
|
||||
- error_type
|
||||
This file is used to set the error type value. The error type value
|
||||
is defined in "available_error_type" description.
|
||||
|
||||
- error_inject
|
||||
Write any integer to this file to trigger the error
|
||||
injection. Before this, please specify all necessary error
|
||||
parameters.
|
||||
|
||||
- param1
|
||||
This file is used to set the first error parameter value. Effect of
|
||||
parameter depends on error_type specified. For memory error, this is
|
||||
physical memory address.
|
||||
|
||||
- param2
|
||||
This file is used to set the second error parameter value. Effect of
|
||||
parameter depends on error_type specified. For memory error, this is
|
||||
physical memory address mask.
|
||||
|
||||
For more information about EINJ, please refer to ACPI specification
|
||||
version 4.0, section 17.5.
|
||||
@@ -12,6 +12,8 @@ Introduction
|
||||
of the s3c2410 GPIO system, please read the Samsung provided
|
||||
data-sheet/users manual to find out the complete list.
|
||||
|
||||
See Documentation/arm/Samsung/GPIO.txt for the core implemetation.
|
||||
|
||||
|
||||
GPIOLIB
|
||||
-------
|
||||
@@ -24,8 +26,60 @@ GPIOLIB
|
||||
listed below will be removed (they may be marked as __deprecated
|
||||
in the near future).
|
||||
|
||||
- s3c2410_gpio_getpin
|
||||
- s3c2410_gpio_setpin
|
||||
The following functions now either have a s3c_ specific variant
|
||||
or are merged into gpiolib. See the definitions in
|
||||
arch/arm/plat-samsung/include/plat/gpio-cfg.h:
|
||||
|
||||
s3c2410_gpio_setpin() gpio_set_value() or gpio_direction_output()
|
||||
s3c2410_gpio_getpin() gpio_get_value() or gpio_direction_input()
|
||||
s3c2410_gpio_getirq() gpio_to_irq()
|
||||
s3c2410_gpio_cfgpin() s3c_gpio_cfgpin()
|
||||
s3c2410_gpio_getcfg() s3c_gpio_getcfg()
|
||||
s3c2410_gpio_pullup() s3c_gpio_setpull()
|
||||
|
||||
|
||||
GPIOLIB conversion
|
||||
------------------
|
||||
|
||||
If you need to convert your board or driver to use gpiolib from the exiting
|
||||
s3c2410 api, then here are some notes on the process.
|
||||
|
||||
1) If your board is exclusively using an GPIO, say to control peripheral
|
||||
power, then it will require to claim the gpio with gpio_request() before
|
||||
it can use it.
|
||||
|
||||
It is recommended to check the return value, with at least WARN_ON()
|
||||
during initialisation.
|
||||
|
||||
2) The s3c2410_gpio_cfgpin() can be directly replaced with s3c_gpio_cfgpin()
|
||||
as they have the same arguments, and can either take the pin specific
|
||||
values, or the more generic special-function-number arguments.
|
||||
|
||||
3) s3c2410_gpio_pullup() changs have the problem that whilst the
|
||||
s3c2410_gpio_pullup(x, 1) can be easily translated to the
|
||||
s3c_gpio_setpull(x, S3C_GPIO_PULL_NONE), the s3c2410_gpio_pullup(x, 0)
|
||||
are not so easy.
|
||||
|
||||
The s3c2410_gpio_pullup(x, 0) case enables the pull-up (or in the case
|
||||
of some of the devices, a pull-down) and as such the new API distinguishes
|
||||
between the UP and DOWN case. There is currently no 'just turn on' setting
|
||||
which may be required if this becomes a problem.
|
||||
|
||||
4) s3c2410_gpio_setpin() can be replaced by gpio_set_value(), the old call
|
||||
does not implicitly configure the relevant gpio to output. The gpio
|
||||
direction should be changed before using gpio_set_value().
|
||||
|
||||
5) s3c2410_gpio_getpin() is replaceable by gpio_get_value() if the pin
|
||||
has been set to input. It is currently unknown what the behaviour is
|
||||
when using gpio_get_value() on an output pin (s3c2410_gpio_getpin
|
||||
would return the value the pin is supposed to be outputting).
|
||||
|
||||
6) s3c2410_gpio_getirq() should be directly replacable with the
|
||||
gpio_to_irq() call.
|
||||
|
||||
The s3c2410_gpio and gpio_ calls have always operated on the same gpio
|
||||
numberspace, so there is no problem with converting the gpio numbering
|
||||
between the calls.
|
||||
|
||||
|
||||
Headers
|
||||
@@ -54,6 +108,11 @@ PIN Numbers
|
||||
eg S3C2410_GPA(0) or S3C2410_GPF(1). These defines are used to tell
|
||||
the GPIO functions which pin is to be used.
|
||||
|
||||
With the conversion to gpiolib, there is no longer a direct conversion
|
||||
from gpio pin number to register base address as in earlier kernels. This
|
||||
is due to the number space required for newer SoCs where the later
|
||||
GPIOs are not contiguous.
|
||||
|
||||
|
||||
Configuring a pin
|
||||
-----------------
|
||||
@@ -71,6 +130,8 @@ Configuring a pin
|
||||
which would turn GPA(0) into the lowest Address line A0, and set
|
||||
GPE(8) to be connected to the SDIO/MMC controller's SDDAT1 line.
|
||||
|
||||
The s3c_gpio_cfgpin() call is a functional replacement for this call.
|
||||
|
||||
|
||||
Reading the current configuration
|
||||
---------------------------------
|
||||
@@ -82,6 +143,9 @@ Reading the current configuration
|
||||
The return value will be from the same set of values which can be
|
||||
passed to s3c2410_gpio_cfgpin().
|
||||
|
||||
The s3c_gpio_getcfg() call should be a functional replacement for
|
||||
this call.
|
||||
|
||||
|
||||
Configuring a pull-up resistor
|
||||
------------------------------
|
||||
@@ -95,6 +159,10 @@ Configuring a pull-up resistor
|
||||
Where the to value is zero to set the pull-up off, and 1 to enable
|
||||
the specified pull-up. Any other values are currently undefined.
|
||||
|
||||
The s3c_gpio_setpull() offers similar functionality, but with the
|
||||
ability to encode whether the pull is up or down. Currently there
|
||||
is no 'just on' state, so up or down must be selected.
|
||||
|
||||
|
||||
Getting the state of a PIN
|
||||
--------------------------
|
||||
@@ -106,6 +174,9 @@ Getting the state of a PIN
|
||||
This will return either zero or non-zero. Do not count on this
|
||||
function returning 1 if the pin is set.
|
||||
|
||||
This call is now implemented by the relevant gpiolib calls, convert
|
||||
your board or driver to use gpiolib.
|
||||
|
||||
|
||||
Setting the state of a PIN
|
||||
--------------------------
|
||||
@@ -117,6 +188,9 @@ Setting the state of a PIN
|
||||
Which sets the given pin to the value. Use 0 to write 0, and 1 to
|
||||
set the output to 1.
|
||||
|
||||
This call is now implemented by the relevant gpiolib calls, convert
|
||||
your board or driver to use gpiolib.
|
||||
|
||||
|
||||
Getting the IRQ number associated with a PIN
|
||||
--------------------------------------------
|
||||
@@ -128,6 +202,9 @@ Getting the IRQ number associated with a PIN
|
||||
|
||||
Note, not all pins have an IRQ.
|
||||
|
||||
This call is now implemented by the relevant gpiolib calls, convert
|
||||
your board or driver to use gpiolib.
|
||||
|
||||
|
||||
Authour
|
||||
-------
|
||||
|
||||
@@ -8,10 +8,16 @@ Introduction
|
||||
|
||||
The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
|
||||
by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
|
||||
S3C2412, S3C2413, S3C2440, S3C2442 and S3C2443 devices are supported.
|
||||
S3C2412, S3C2413, S3C2416 S3C2440, S3C2442, S3C2443 and S3C2450 devices
|
||||
are supported.
|
||||
|
||||
Support for the S3C2400 and S3C24A0 series are in progress.
|
||||
|
||||
The S3C2416 and S3C2450 devices are very similar and S3C2450 support is
|
||||
included under the arch/arm/mach-s3c2416 directory. Note, whilst core
|
||||
support for these SoCs is in, work on some of the extra peripherals
|
||||
and extra interrupts is still ongoing.
|
||||
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
@@ -209,6 +215,13 @@ GPIO
|
||||
Newer kernels carry GPIOLIB, and support is being moved towards
|
||||
this with some of the older support in line to be removed.
|
||||
|
||||
As of v2.6.34, the move towards using gpiolib support is almost
|
||||
complete, and very little of the old calls are left.
|
||||
|
||||
See Documentation/arm/Samsung-S3C24XX/GPIO.txt for the S3C24XX specific
|
||||
support and Documentation/arm/Samsung/GPIO.txt for the core Samsung
|
||||
implementation.
|
||||
|
||||
|
||||
Clock Management
|
||||
----------------
|
||||
|
||||
@@ -0,0 +1,42 @@
|
||||
Samsung GPIO implementation
|
||||
===========================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
This outlines the Samsung GPIO implementation and the architecture
|
||||
specfic calls provided alongisde the drivers/gpio core.
|
||||
|
||||
|
||||
S3C24XX (Legacy)
|
||||
----------------
|
||||
|
||||
See Documentation/arm/Samsung-S3C24XX/GPIO.txt for more information
|
||||
about these devices. Their implementation is being brought into line
|
||||
with the core samsung implementation described in this document.
|
||||
|
||||
|
||||
GPIOLIB integration
|
||||
-------------------
|
||||
|
||||
The gpio implementation uses gpiolib as much as possible, only providing
|
||||
specific calls for the items that require Samsung specific handling, such
|
||||
as pin special-function or pull resistor control.
|
||||
|
||||
GPIO numbering is synchronised between the Samsung and gpiolib system.
|
||||
|
||||
|
||||
PIN configuration
|
||||
-----------------
|
||||
|
||||
Pin configuration is specific to the Samsung architecutre, with each SoC
|
||||
registering the necessary information for the core gpio configuration
|
||||
implementation to configure pins as necessary.
|
||||
|
||||
The s3c_gpio_cfgpin() and s3c_gpio_setpull() provide the means for a
|
||||
driver or machine to change gpio configuration.
|
||||
|
||||
See arch/arm/plat-samsung/include/plat/gpio-cfg.h for more information
|
||||
on these functions.
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user