Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into mips-for-linux-next
Conflicts:
include/linux/ssb/ssb_driver_gige.h
Also resolves a logical merge conflict in drivers/net/ethernet/broadcom/-
bgmac.c due to change of an API.
tirimbino
Ralf Baechle
12 years ago
commit
edb15d83a8
@ -0,0 +1,62 @@ |
||||
What: /sys/devices/cpu/events/ |
||||
/sys/devices/cpu/events/branch-misses |
||||
/sys/devices/cpu/events/cache-references |
||||
/sys/devices/cpu/events/cache-misses |
||||
/sys/devices/cpu/events/stalled-cycles-frontend |
||||
/sys/devices/cpu/events/branch-instructions |
||||
/sys/devices/cpu/events/stalled-cycles-backend |
||||
/sys/devices/cpu/events/instructions |
||||
/sys/devices/cpu/events/cpu-cycles |
||||
|
||||
Date: 2013/01/08 |
||||
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> |
||||
|
||||
Description: Generic performance monitoring events |
||||
|
||||
A collection of performance monitoring events that may be |
||||
supported by many/most CPUs. These events can be monitored |
||||
using the 'perf(1)' tool. |
||||
|
||||
The contents of each file would look like: |
||||
|
||||
event=0xNNNN |
||||
|
||||
where 'N' is a hex digit and the number '0xNNNN' shows the |
||||
"raw code" for the perf event identified by the file's |
||||
"basename". |
||||
|
||||
|
||||
What: /sys/devices/cpu/events/PM_LD_MISS_L1 |
||||
/sys/devices/cpu/events/PM_LD_REF_L1 |
||||
/sys/devices/cpu/events/PM_CYC |
||||
/sys/devices/cpu/events/PM_BRU_FIN |
||||
/sys/devices/cpu/events/PM_GCT_NOSLOT_CYC |
||||
/sys/devices/cpu/events/PM_BRU_MPRED |
||||
/sys/devices/cpu/events/PM_INST_CMPL |
||||
/sys/devices/cpu/events/PM_CMPLU_STALL |
||||
|
||||
Date: 2013/01/08 |
||||
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> |
||||
Linux Powerpc mailing list <linuxppc-dev@ozlabs.org> |
||||
|
||||
Description: POWER-systems specific performance monitoring events |
||||
|
||||
A collection of performance monitoring events that may be |
||||
supported by the POWER CPU. These events can be monitored |
||||
using the 'perf(1)' tool. |
||||
|
||||
These events may not be supported by other CPUs. |
||||
|
||||
The contents of each file would look like: |
||||
|
||||
event=0xNNNN |
||||
|
||||
where 'N' is a hex digit and the number '0xNNNN' shows the |
||||
"raw code" for the perf event identified by the file's |
||||
"basename". |
||||
|
||||
Further, multiple terms like 'event=0xNNNN' can be specified |
||||
and separated with comma. All available terms are defined in |
||||
the /sys/bus/event_source/devices/<dev>/format file. |
||||
@ -0,0 +1,13 @@ |
||||
What: /sys/devices/.../power_resources_D0/ |
||||
Date: January 2013 |
||||
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
||||
Description: |
||||
The /sys/devices/.../power_resources_D0/ directory is only |
||||
present for device objects representing ACPI device nodes that |
||||
use ACPI power resources for power management. |
||||
|
||||
If present, it contains symbolic links to device directories |
||||
representing ACPI power resources that need to be turned on for |
||||
the given device node to be in ACPI power state D0. The names |
||||
of the links are the same as the names of the directories they |
||||
point to. |
||||
@ -0,0 +1,14 @@ |
||||
What: /sys/devices/.../power_resources_D1/ |
||||
Date: January 2013 |
||||
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
||||
Description: |
||||
The /sys/devices/.../power_resources_D1/ directory is only |
||||
present for device objects representing ACPI device nodes that |
||||
use ACPI power resources for power management and support ACPI |
||||
power state D1. |
||||
|
||||
If present, it contains symbolic links to device directories |
||||
representing ACPI power resources that need to be turned on for |
||||
the given device node to be in ACPI power state D1. The names |
||||
of the links are the same as the names of the directories they |
||||
point to. |
||||
@ -0,0 +1,14 @@ |
||||
What: /sys/devices/.../power_resources_D2/ |
||||
Date: January 2013 |
||||
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
||||
Description: |
||||
The /sys/devices/.../power_resources_D2/ directory is only |
||||
present for device objects representing ACPI device nodes that |
||||
use ACPI power resources for power management and support ACPI |
||||
power state D2. |
||||
|
||||
If present, it contains symbolic links to device directories |
||||
representing ACPI power resources that need to be turned on for |
||||
the given device node to be in ACPI power state D2. The names |
||||
of the links are the same as the names of the directories they |
||||
point to. |
||||
@ -0,0 +1,14 @@ |
||||
What: /sys/devices/.../power_resources_D3hot/ |
||||
Date: January 2013 |
||||
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
||||
Description: |
||||
The /sys/devices/.../power_resources_D3hot/ directory is only |
||||
present for device objects representing ACPI device nodes that |
||||
use ACPI power resources for power management and support ACPI |
||||
power state D3hot. |
||||
|
||||
If present, it contains symbolic links to device directories |
||||
representing ACPI power resources that need to be turned on for |
||||
the given device node to be in ACPI power state D3hot. The |
||||
names of the links are the same as the names of the directories |
||||
they point to. |
||||
@ -0,0 +1,20 @@ |
||||
What: /sys/devices/.../power_state |
||||
Date: January 2013 |
||||
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
||||
Description: |
||||
The /sys/devices/.../power_state attribute is only present for |
||||
device objects representing ACPI device nodes that provide power |
||||
management methods. |
||||
|
||||
If present, it contains a string representing the current ACPI |
||||
power state of the given device node. Its possible values, |
||||
"D0", "D1", "D2", "D3hot", and "D3cold", reflect the power state |
||||
names defined by the ACPI specification (ACPI 4 and above). |
||||
|
||||
If the device node uses shared ACPI power resources, this state |
||||
determines a list of power resources required not to be turned |
||||
off. However, some power resources needed by the device node in |
||||
higher-power (lower-number) states may also be ON because of |
||||
some other devices using them at the moment. |
||||
|
||||
This attribute is read-only. |
||||
@ -0,0 +1,23 @@ |
||||
What: /sys/devices/.../real_power_state |
||||
Date: January 2013 |
||||
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
||||
Description: |
||||
The /sys/devices/.../real_power_state attribute is only present |
||||
for device objects representing ACPI device nodes that provide |
||||
power management methods and use ACPI power resources for power |
||||
management. |
||||
|
||||
If present, it contains a string representing the real ACPI |
||||
power state of the given device node as returned by the _PSC |
||||
control method or inferred from the configuration of power |
||||
resources. Its possible values, "D0", "D1", "D2", "D3hot", and |
||||
"D3cold", reflect the power state names defined by the ACPI |
||||
specification (ACPI 4 and above). |
||||
|
||||
In some situations the value of this attribute may be different |
||||
from the value of the /sys/devices/.../power_state attribute for |
||||
the same device object. If that happens, some shared power |
||||
resources used by the device node are only ON because of some |
||||
other devices using them at the moment. |
||||
|
||||
This attribute is read-only. |
||||
@ -0,0 +1,12 @@ |
||||
What: /sys/devices/.../resource_in_use |
||||
Date: January 2013 |
||||
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
||||
Description: |
||||
The /sys/devices/.../resource_in_use attribute is only present |
||||
for device objects representing ACPI power resources. |
||||
|
||||
If present, it contains a number (0 or 1) representing the |
||||
current status of the given power resource (0 means that the |
||||
resource is not in use and therefore it has been turned off). |
||||
|
||||
This attribute is read-only. |
||||
@ -0,0 +1,47 @@ |
||||
What: /sys/devices/platform/ts5500/adc |
||||
Date: January 2013 |
||||
KernelVersion: 3.7 |
||||
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com> |
||||
Description: |
||||
Indicates the presence of an A/D Converter. If it is present, |
||||
it will display "1", otherwise "0". |
||||
|
||||
What: /sys/devices/platform/ts5500/ereset |
||||
Date: January 2013 |
||||
KernelVersion: 3.7 |
||||
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com> |
||||
Description: |
||||
Indicates the presence of an external reset. If it is present, |
||||
it will display "1", otherwise "0". |
||||
|
||||
What: /sys/devices/platform/ts5500/id |
||||
Date: January 2013 |
||||
KernelVersion: 3.7 |
||||
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com> |
||||
Description: |
||||
Product ID of the TS board. TS-5500 ID is 0x60. |
||||
|
||||
What: /sys/devices/platform/ts5500/jumpers |
||||
Date: January 2013 |
||||
KernelVersion: 3.7 |
||||
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com> |
||||
Description: |
||||
Bitfield showing the jumpers' state. If a jumper is present, |
||||
the corresponding bit is set. For instance, 0x0e means jumpers |
||||
2, 3 and 4 are set. |
||||
|
||||
What: /sys/devices/platform/ts5500/rs485 |
||||
Date: January 2013 |
||||
KernelVersion: 3.7 |
||||
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com> |
||||
Description: |
||||
Indicates the presence of the RS485 option. If it is present, |
||||
it will display "1", otherwise "0". |
||||
|
||||
What: /sys/devices/platform/ts5500/sram |
||||
Date: January 2013 |
||||
KernelVersion: 3.7 |
||||
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com> |
||||
Description: |
||||
Indicates the presence of the SRAM option. If it is present, |
||||
it will display "1", otherwise "0". |
||||
@ -0,0 +1,77 @@ |
||||
ACPI Scan Handlers |
||||
|
||||
Copyright (C) 2012, Intel Corporation |
||||
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
||||
|
||||
During system initialization and ACPI-based device hot-add, the ACPI namespace |
||||
is scanned in search of device objects that generally represent various pieces |
||||
of hardware. This causes a struct acpi_device object to be created and |
||||
registered with the driver core for every device object in the ACPI namespace |
||||
and the hierarchy of those struct acpi_device objects reflects the namespace |
||||
layout (i.e. parent device objects in the namespace are represented by parent |
||||
struct acpi_device objects and analogously for their children). Those struct |
||||
acpi_device objects are referred to as "device nodes" in what follows, but they |
||||
should not be confused with struct device_node objects used by the Device Trees |
||||
parsing code (although their role is analogous to the role of those objects). |
||||
|
||||
During ACPI-based device hot-remove device nodes representing pieces of hardware |
||||
being removed are unregistered and deleted. |
||||
|
||||
The core ACPI namespace scanning code in drivers/acpi/scan.c carries out basic |
||||
initialization of device nodes, such as retrieving common configuration |
||||
information from the device objects represented by them and populating them with |
||||
appropriate data, but some of them require additional handling after they have |
||||
been registered. For example, if the given device node represents a PCI host |
||||
bridge, its registration should cause the PCI bus under that bridge to be |
||||
enumerated and PCI devices on that bus to be registered with the driver core. |
||||
Similarly, if the device node represents a PCI interrupt link, it is necessary |
||||
to configure that link so that the kernel can use it. |
||||
|
||||
Those additional configuration tasks usually depend on the type of the hardware |
||||
component represented by the given device node which can be determined on the |
||||
basis of the device node's hardware ID (HID). They are performed by objects |
||||
called ACPI scan handlers represented by the following structure: |
||||
|
||||
struct acpi_scan_handler { |
||||
const struct acpi_device_id *ids; |
||||
struct list_head list_node; |
||||
int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id); |
||||
void (*detach)(struct acpi_device *dev); |
||||
}; |
||||
|
||||
where ids is the list of IDs of device nodes the given handler is supposed to |
||||
take care of, list_node is the hook to the global list of ACPI scan handlers |
||||
maintained by the ACPI core and the .attach() and .detach() callbacks are |
||||
executed, respectively, after registration of new device nodes and before |
||||
unregistration of device nodes the handler attached to previously. |
||||
|
||||
The namespace scanning function, acpi_bus_scan(), first registers all of the |
||||
device nodes in the given namespace scope with the driver core. Then, it tries |
||||
to match a scan handler against each of them using the ids arrays of the |
||||
available scan handlers. If a matching scan handler is found, its .attach() |
||||
callback is executed for the given device node. If that callback returns 1, |
||||
that means that the handler has claimed the device node and is now responsible |
||||
for carrying out any additional configuration tasks related to it. It also will |
||||
be responsible for preparing the device node for unregistration in that case. |
||||
The device node's handler field is then populated with the address of the scan |
||||
handler that has claimed it. |
||||
|
||||
If the .attach() callback returns 0, it means that the device node is not |
||||
interesting to the given scan handler and may be matched against the next scan |
||||
handler in the list. If it returns a (negative) error code, that means that |
||||
the namespace scan should be terminated due to a serious error. The error code |
||||
returned should then reflect the type of the error. |
||||
|
||||
The namespace trimming function, acpi_bus_trim(), first executes .detach() |
||||
callbacks from the scan handlers of all device nodes in the given namespace |
||||
scope (if they have scan handlers). Next, it unregisters all of the device |
||||
nodes in that scope. |
||||
|
||||
ACPI scan handlers can be added to the list maintained by the ACPI core with the |
||||
help of the acpi_scan_add_handler() function taking a pointer to the new scan |
||||
handler as an argument. The order in which scan handlers are added to the list |
||||
is the order in which they are matched against device nodes during namespace |
||||
scans. |
||||
|
||||
All scan handles must be added to the list before acpi_bus_scan() is run for the |
||||
first time and they cannot be removed from it. |
||||
@ -0,0 +1,27 @@ |
||||
Marvell Kirkwood Platforms Device Tree Bindings |
||||
----------------------------------------------- |
||||
|
||||
Boards with a SoC of the Marvell Kirkwood |
||||
shall have the following property: |
||||
|
||||
Required root node property: |
||||
|
||||
compatible: must contain "marvell,kirkwood"; |
||||
|
||||
In order to support the kirkwood cpufreq driver, there must be a node |
||||
cpus/cpu@0 with three clocks, "cpu_clk", "ddrclk" and "powersave", |
||||
where the "powersave" clock is a gating clock used to switch the CPU |
||||
between the "cpu_clk" and the "ddrclk". |
||||
|
||||
Example: |
||||
|
||||
cpus { |
||||
#address-cells = <1>; |
||||
#size-cells = <0>; |
||||
|
||||
cpu@0 { |
||||
device_type = "cpu"; |
||||
compatible = "marvell,sheeva-88SV131"; |
||||
clocks = <&core_clk 1>, <&core_clk 3>, <&gate_clk 11>; |
||||
clock-names = "cpu_clk", "ddrclk", "powersave"; |
||||
}; |
||||
@ -0,0 +1,55 @@ |
||||
* Power State Coordination Interface (PSCI) |
||||
|
||||
Firmware implementing the PSCI functions described in ARM document number |
||||
ARM DEN 0022A ("Power State Coordination Interface System Software on ARM |
||||
processors") can be used by Linux to initiate various CPU-centric power |
||||
operations. |
||||
|
||||
Issue A of the specification describes functions for CPU suspend, hotplug |
||||
and migration of secure software. |
||||
|
||||
Functions are invoked by trapping to the privilege level of the PSCI |
||||
firmware (specified as part of the binding below) and passing arguments |
||||
in a manner similar to that specified by AAPCS: |
||||
|
||||
r0 => 32-bit Function ID / return value |
||||
{r1 - r3} => Parameters |
||||
|
||||
Note that the immediate field of the trapping instruction must be set |
||||
to #0. |
||||
|
||||
|
||||
Main node required properties: |
||||
|
||||
- compatible : Must be "arm,psci" |
||||
|
||||
- method : The method of calling the PSCI firmware. Permitted |
||||
values are: |
||||
|
||||
"smc" : SMC #0, with the register assignments specified |
||||
in this binding. |
||||
|
||||
"hvc" : HVC #0, with the register assignments specified |
||||
in this binding. |
||||
|
||||
Main node optional properties: |
||||
|
||||
- cpu_suspend : Function ID for CPU_SUSPEND operation |
||||
|
||||
- cpu_off : Function ID for CPU_OFF operation |
||||
|
||||
- cpu_on : Function ID for CPU_ON operation |
||||
|
||||
- migrate : Function ID for MIGRATE operation |
||||
|
||||
|
||||
Example: |
||||
|
||||
psci { |
||||
compatible = "arm,psci"; |
||||
method = "smc"; |
||||
cpu_suspend = <0x95c10000>; |
||||
cpu_off = <0x95c10001>; |
||||
cpu_on = <0x95c10002>; |
||||
migrate = <0x95c10003>; |
||||
}; |
||||
@ -0,0 +1,73 @@ |
||||
* Clock bindings for CSR SiRFprimaII |
||||
|
||||
Required properties: |
||||
- compatible: Should be "sirf,prima2-clkc" |
||||
- reg: Address and length of the register set |
||||
- interrupts: Should contain clock controller interrupt |
||||
- #clock-cells: Should be <1> |
||||
|
||||
The clock consumer should specify the desired clock by having the clock |
||||
ID in its "clocks" phandle cell. The following is a full list of prima2 |
||||
clocks and IDs. |
||||
|
||||
Clock ID |
||||
--------------------------- |
||||
rtc 0 |
||||
osc 1 |
||||
pll1 2 |
||||
pll2 3 |
||||
pll3 4 |
||||
mem 5 |
||||
sys 6 |
||||
security 7 |
||||
dsp 8 |
||||
gps 9 |
||||
mf 10 |
||||
io 11 |
||||
cpu 12 |
||||
uart0 13 |
||||
uart1 14 |
||||
uart2 15 |
||||
tsc 16 |
||||
i2c0 17 |
||||
i2c1 18 |
||||
spi0 19 |
||||
spi1 20 |
||||
pwmc 21 |
||||
efuse 22 |
||||
pulse 23 |
||||
dmac0 24 |
||||
dmac1 25 |
||||
nand 26 |
||||
audio 27 |
||||
usp0 28 |
||||
usp1 29 |
||||
usp2 30 |
||||
vip 31 |
||||
gfx 32 |
||||
mm 33 |
||||
lcd 34 |
||||
vpp 35 |
||||
mmc01 36 |
||||
mmc23 37 |
||||
mmc45 38 |
||||
usbpll 39 |
||||
usb0 40 |
||||
usb1 41 |
||||
|
||||
Examples: |
||||
|
||||
clks: clock-controller@88000000 { |
||||
compatible = "sirf,prima2-clkc"; |
||||
reg = <0x88000000 0x1000>; |
||||
interrupts = <3>; |
||||
#clock-cells = <1>; |
||||
}; |
||||
|
||||
i2c0: i2c@b00e0000 { |
||||
cell-index = <0>; |
||||
compatible = "sirf,prima2-i2c"; |
||||
reg = <0xb00e0000 0x10000>; |
||||
interrupts = <24>; |
||||
clocks = <&clks 17>; |
||||
}; |
||||
@ -0,0 +1,22 @@ |
||||
Samsung 2D Graphic Accelerator using DRM frame work |
||||
|
||||
Samsung FIMG2D is a graphics 2D accelerator which supports Bit Block Transfer. |
||||
We set the drawing-context registers for configuring rendering parameters and |
||||
then start rendering. |
||||
This driver is for SOCs which contain G2D IPs with version 4.1. |
||||
|
||||
Required properties: |
||||
-compatible: |
||||
should be "samsung,exynos-g2d-41". |
||||
-reg: |
||||
physical base address of the controller and length |
||||
of memory mapped region. |
||||
-interrupts: |
||||
interrupt combiner values. |
||||
|
||||
Example: |
||||
g2d { |
||||
compatible = "samsung,exynos-g2d-41"; |
||||
reg = <0x10850000 0x1000>; |
||||
interrupts = <0 91 0>; |
||||
}; |
||||
@ -0,0 +1,18 @@ |
||||
ina209 properties |
||||
|
||||
Required properties: |
||||
- compatible: Must be "ti,ina209" |
||||
- reg: I2C address |
||||
|
||||
Optional properties: |
||||
|
||||
- shunt-resistor |
||||
Shunt resistor value in micro-Ohm |
||||
|
||||
Example: |
||||
|
||||
temp-sensor@4c { |
||||
compatible = "ti,ina209"; |
||||
reg = <0x4c>; |
||||
shunt-resistor = <5000>; |
||||
}; |
||||
@ -0,0 +1,64 @@ |
||||
max6697 properties |
||||
|
||||
Required properties: |
||||
- compatible: |
||||
Should be one of |
||||
maxim,max6581 |
||||
maxim,max6602 |
||||
maxim,max6622 |
||||
maxim,max6636 |
||||
maxim,max6689 |
||||
maxim,max6693 |
||||
maxim,max6694 |
||||
maxim,max6697 |
||||
maxim,max6698 |
||||
maxim,max6699 |
||||
- reg: I2C address |
||||
|
||||
Optional properties: |
||||
|
||||
- smbus-timeout-disable |
||||
Set to disable SMBus timeout. If not specified, SMBus timeout will be |
||||
enabled. |
||||
- extended-range-enable |
||||
Only valid for MAX6581. Set to enable extended temperature range. |
||||
Extended temperature will be disabled if not specified. |
||||
- beta-compensation-enable |
||||
Only valid for MAX6693 and MX6694. Set to enable beta compensation on |
||||
remote temperature channel 1. |
||||
Beta compensation will be disabled if not specified. |
||||
- alert-mask |
||||
Alert bit mask. Alert disabled for bits set. |
||||
Select bit 0 for local temperature, bit 1..7 for remote temperatures. |
||||
If not specified, alert will be enabled for all channels. |
||||
- over-temperature-mask |
||||
Over-temperature bit mask. Over-temperature reporting disabled for |
||||
bits set. |
||||
Select bit 0 for local temperature, bit 1..7 for remote temperatures. |
||||
If not specified, over-temperature reporting will be enabled for all |
||||
channels. |
||||
- resistance-cancellation |
||||
Boolean for all chips other than MAX6581. Set to enable resistance |
||||
cancellation on remote temperature channel 1. |
||||
For MAX6581, resistance cancellation enabled for all channels if |
||||
specified as boolean, otherwise as per bit mask specified. |
||||
Only supported for remote temperatures (bit 1..7). |
||||
If not specified, resistance cancellation will be disabled for all |
||||
channels. |
||||
- transistor-ideality |
||||
For MAX6581 only. Two values; first is bit mask, second is ideality |
||||
select value as per MAX6581 data sheet. Select bit 1..7 for remote |
||||
channels. |
||||
Transistor ideality will be initialized to default (1.008) if not |
||||
specified. |
||||
|
||||
Example: |
||||
|
||||
temp-sensor@1a { |
||||
compatible = "maxim,max6697"; |
||||
reg = <0x1a>; |
||||
smbus-timeout-disable; |
||||
resistance-cancellation; |
||||
alert-mask = <0x72>; |
||||
over-temperature-mask = <0x7f>; |
||||
}; |
||||
@ -0,0 +1,53 @@ |
||||
* Freescale i.MX Keypad Port(KPP) device tree bindings |
||||
|
||||
The KPP is designed to interface with a keypad matrix with 2-point contact |
||||
or 3-point contact keys. The KPP is designed to simplify the software task |
||||
of scanning a keypad matrix. The KPP is capable of detecting, debouncing, |
||||
and decoding one or multiple keys pressed simultaneously on a keypad. |
||||
|
||||
Required SoC Specific Properties: |
||||
- compatible: Should be "fsl,<soc>-kpp". |
||||
|
||||
- reg: Physical base address of the KPP and length of memory mapped |
||||
region. |
||||
|
||||
- interrupts: The KPP interrupt number to the CPU(s). |
||||
|
||||
- clocks: The clock provided by the SoC to the KPP. Some SoCs use dummy |
||||
clock(The clock for the KPP is provided by the SoCs automatically). |
||||
|
||||
Required Board Specific Properties: |
||||
- pinctrl-names: The definition can be found at |
||||
pinctrl/pinctrl-bindings.txt. |
||||
|
||||
- pinctrl-0: The definition can be found at |
||||
pinctrl/pinctrl-bindings.txt. |
||||
|
||||
- linux,keymap: The definition can be found at |
||||
bindings/input/matrix-keymap.txt. |
||||
|
||||
Example: |
||||
kpp: kpp@73f94000 { |
||||
compatible = "fsl,imx51-kpp", "fsl,imx21-kpp"; |
||||
reg = <0x73f94000 0x4000>; |
||||
interrupts = <60>; |
||||
clocks = <&clks 0>; |
||||
pinctrl-names = "default"; |
||||
pinctrl-0 = <&pinctrl_kpp_1>; |
||||
linux,keymap = <0x00000067 /* KEY_UP */ |
||||
0x0001006c /* KEY_DOWN */ |
||||
0x00020072 /* KEY_VOLUMEDOWN */ |
||||
0x00030066 /* KEY_HOME */ |
||||
0x0100006a /* KEY_RIGHT */ |
||||
0x01010069 /* KEY_LEFT */ |
||||
0x0102001c /* KEY_ENTER */ |
||||
0x01030073 /* KEY_VOLUMEUP */ |
||||
0x02000040 /* KEY_F6 */ |
||||
0x02010042 /* KEY_F8 */ |
||||
0x02020043 /* KEY_F9 */ |
||||
0x02030044 /* KEY_F10 */ |
||||
0x0300003b /* KEY_F1 */ |
||||
0x0301003c /* KEY_F2 */ |
||||
0x0302003d /* KEY_F3 */ |
||||
0x03030074>; /* KEY_POWER */ |
||||
}; |
||||
@ -1,8 +1,10 @@ |
||||
This binding is based on the matrix-keymap binding with the following |
||||
changes: |
||||
|
||||
keypad,num-rows and keypad,num-columns are required. |
||||
|
||||
Required properties: |
||||
- compatible: "ti,tca8418" |
||||
- reg: the I2C address |
||||
- interrupts: IRQ line number, should trigger on falling edge |
||||
- keypad,num-rows: The number of rows |
||||
- keypad,num-columns: The number of columns |
||||
- linux,keymap: Keys definitions, see keypad-matrix. |
||||
|
||||
@ -0,0 +1,91 @@ |
||||
TPS6507x Power Management Integrated Circuit |
||||
|
||||
Required properties: |
||||
- compatible: "ti,tps6507x" |
||||
- reg: I2C slave address |
||||
- regulators: This is the list of child nodes that specify the regulator |
||||
initialization data for defined regulators. Not all regulators for the |
||||
given device need to be present. The definition for each of these nodes |
||||
is defined using the standard binding for regulators found at |
||||
Documentation/devicetree/bindings/regulator/regulator.txt. |
||||
The regulator is matched with the regulator-compatible. |
||||
|
||||
The valid regulator-compatible values are: |
||||
tps6507x: vdcdc1, vdcdc2, vdcdc3, vldo1, vldo2 |
||||
- xxx-supply: Input voltage supply regulator. |
||||
These entries are required if regulators are enabled for a device. |
||||
Missing of these properties can cause the regulator registration |
||||
fails. |
||||
If some of input supply is powered through battery or always-on |
||||
supply then also it is require to have these parameters with proper |
||||
node handle of always on power supply. |
||||
tps6507x: |
||||
vindcdc1_2-supply: VDCDC1 and VDCDC2 input. |
||||
vindcdc3-supply : VDCDC3 input. |
||||
vldo1_2-supply : VLDO1 and VLDO2 input. |
||||
|
||||
Regulator Optional properties: |
||||
- defdcdc_default: It's property of DCDC2 and DCDC3 regulators. |
||||
0: If defdcdc pin of DCDC2/DCDC3 is pulled to GND. |
||||
1: If defdcdc pin of DCDC2/DCDC3 is driven HIGH. |
||||
If this property is not defined, it defaults to 0 (not enabled). |
||||
|
||||
Example: |
||||
|
||||
pmu: tps6507x@48 { |
||||
compatible = "ti,tps6507x"; |
||||
reg = <0x48>; |
||||
|
||||
vindcdc1_2-supply = <&vbat>; |
||||
vindcdc3-supply = <...>; |
||||
vinldo1_2-supply = <...>; |
||||
|
||||
regulators { |
||||
#address-cells = <1>; |
||||
#size-cells = <0>; |
||||
|
||||
vdcdc1_reg: regulator@0 { |
||||
regulator-compatible = "VDCDC1"; |
||||
reg = <0>; |
||||
regulator-min-microvolt = <3150000>; |
||||
regulator-max-microvolt = <3450000>; |
||||
regulator-always-on; |
||||
regulator-boot-on; |
||||
}; |
||||
vdcdc2_reg: regulator@1 { |
||||
regulator-compatible = "VDCDC2"; |
||||
reg = <1>; |
||||
regulator-min-microvolt = <1710000>; |
||||
regulator-max-microvolt = <3450000>; |
||||
regulator-always-on; |
||||
regulator-boot-on; |
||||
defdcdc_default = <1>; |
||||
}; |
||||
vdcdc3_reg: regulator@2 { |
||||
regulator-compatible = "VDCDC3"; |
||||
reg = <2>; |
||||
regulator-min-microvolt = <950000> |
||||
regulator-max-microvolt = <1350000>; |
||||
regulator-always-on; |
||||
regulator-boot-on; |
||||
defdcdc_default = <1>; |
||||
}; |
||||
ldo1_reg: regulator@3 { |
||||
regulator-compatible = "LDO1"; |
||||
reg = <3>; |
||||
regulator-min-microvolt = <1710000>; |
||||
regulator-max-microvolt = <1890000>; |
||||
regulator-always-on; |
||||
regulator-boot-on; |
||||
}; |
||||
ldo2_reg: regulator@4 { |
||||
regulator-compatible = "LDO2"; |
||||
reg = <4>; |
||||
regulator-min-microvolt = <1140000>; |
||||
regulator-max-microvolt = <1320000>; |
||||
regulator-always-on; |
||||
regulator-boot-on; |
||||
}; |
||||
}; |
||||
|
||||
}; |
||||
@ -0,0 +1,60 @@ |
||||
* Allwinner A1X Pin Controller |
||||
|
||||
The pins controlled by sunXi pin controller are organized in banks, |
||||
each bank has 32 pins. Each pin has 7 multiplexing functions, with |
||||
the first two functions being GPIO in and out. The configuration on |
||||
the pins includes drive strength and pull-up. |
||||
|
||||
Required properties: |
||||
- compatible: "allwinner,<soc>-pinctrl". Supported SoCs for now are: |
||||
sun5i-a13. |
||||
- reg: Should contain the register physical address and length for the |
||||
pin controller. |
||||
|
||||
Please refer to pinctrl-bindings.txt in this directory for details of the |
||||
common pinctrl bindings used by client devices. |
||||
|
||||
A pinctrl node should contain at least one subnodes representing the |
||||
pinctrl groups available on the machine. Each subnode will list the |
||||
pins it needs, and how they should be configured, with regard to muxer |
||||
configuration, drive strength and pullups. If one of these options is |
||||
not set, its actual value will be unspecified. |
||||
|
||||
Required subnode-properties: |
||||
|
||||
- allwinner,pins: List of strings containing the pin name. |
||||
- allwinner,function: Function to mux the pins listed above to. |
||||
|
||||
Optional subnode-properties: |
||||
- allwinner,drive: Integer. Represents the current sent to the pin |
||||
0: 10 mA |
||||
1: 20 mA |
||||
2: 30 mA |
||||
3: 40 mA |
||||
- allwinner,pull: Integer. |
||||
0: No resistor |
||||
1: Pull-up resistor |
||||
2: Pull-down resistor |
||||
|
||||
Examples: |
||||
|
||||
pinctrl@01c20800 { |
||||
compatible = "allwinner,sun5i-a13-pinctrl"; |
||||
reg = <0x01c20800 0x400>; |
||||
#address-cells = <1>; |
||||
#size-cells = <0>; |
||||
|
||||
uart1_pins_a: uart1@0 { |
||||
allwinner,pins = "PE10", "PE11"; |
||||
allwinner,function = "uart1"; |
||||
allwinner,drive = <0>; |
||||
allwinner,pull = <0>; |
||||
}; |
||||
|
||||
uart1_pins_b: uart1@1 { |
||||
allwinner,pins = "PG3", "PG4"; |
||||
allwinner,function = "uart1"; |
||||
allwinner,drive = <0>; |
||||
allwinner,pull = <0>; |
||||
}; |
||||
}; |
||||
@ -0,0 +1,120 @@ |
||||
NVIDIA Tegra114 pinmux controller |
||||
|
||||
The Tegra114 pinctrl binding is very similar to the Tegra20 and Tegra30 |
||||
pinctrl binding, as described in nvidia,tegra20-pinmux.txt and |
||||
nvidia,tegra30-pinmux.txt. In fact, this document assumes that binding as |
||||
a baseline, and only documents the differences between the two bindings. |
||||
|
||||
Required properties: |
||||
- compatible: "nvidia,tegra114-pinmux" |
||||
- reg: Should contain the register physical address and length for each of |
||||
the pad control and mux registers. The first bank of address must be the |
||||
driver strength pad control register address and second bank address must |
||||
be pinmux register address. |
||||
|
||||
Tegra114 adds the following optional properties for pin configuration subnodes: |
||||
- nvidia,enable-input: Integer. Enable the pin's input path. 0: no, 1: yes. |
||||
- nvidia,open-drain: Integer. Enable open drain mode. 0: no, 1: yes. |
||||
- nvidia,lock: Integer. Lock the pin configuration against further changes |
||||
until reset. 0: no, 1: yes. |
||||
- nvidia,io-reset: Integer. Reset the IO path. 0: no, 1: yes. |
||||
- nvidia,rcv-sel: Integer. Select VIL/VIH receivers. 0: normal, 1: high. |
||||
- nvidia,drive-type: Integer. Valid range 0...3. |
||||
|
||||
As with Tegra20 and Terga30, see the Tegra TRM for complete details regarding |
||||
which groups support which functionality. |
||||
|
||||
Valid values for pin and group names are: |
||||
|
||||
per-pin mux groups: |
||||
|
||||
These all support nvidia,function, nvidia,tristate, nvidia,pull, |
||||
nvidia,enable-input, nvidia,lock. Some support nvidia,open-drain, |
||||
nvidia,io-reset and nvidia,rcv-sel. |
||||
|
||||
ulpi_data0_po1, ulpi_data1_po2, ulpi_data2_po3, ulpi_data3_po4, |
||||
ulpi_data4_po5, ulpi_data5_po6, ulpi_data6_po7, ulpi_data7_po0, |
||||
ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, dap3_fs_pp0, |
||||
dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3, pv0, pv1, sdmmc1_clk_pz0, |
||||
sdmmc1_cmd_pz1, sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6, |
||||
sdmmc1_dat0_py7, clk2_out_pw5, clk2_req_pcc5, hdmi_int_pn7, ddc_scl_pv4, |
||||
ddc_sda_pv5, uart2_rxd_pc3, uart2_txd_pc2, uart2_rts_n_pj6, |
||||
uart2_cts_n_pj5, uart3_txd_pw6, uart3_rxd_pw7, uart3_cts_n_pa1, |
||||
uart3_rts_n_pc0, pu0, pu1, pu2, pu3, pu4, pu5, pu6, gen1_i2c_sda_pc5, |
||||
gen1_i2c_scl_pc4, dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6, dap4_sclk_pp7, |
||||
clk3_out_pee0, clk3_req_pee1, gmi_wp_n_pc7, gmi_iordy_pi5, gmi_wait_pi7, |
||||
gmi_adv_n_pk0, gmi_clk_pk1, gmi_cs0_n_pj0, gmi_cs1_n_pj2, gmi_cs2_n_pk3, |
||||
gmi_cs3_n_pk4, gmi_cs4_n_pk2, gmi_cs6_n_pi3, gmi_cs7_n_pi6, gmi_ad0_pg0, |
||||
gmi_ad1_pg1, gmi_ad2_pg2, gmi_ad3_pg3, gmi_ad4_pg4, gmi_ad5_pg5, |
||||
gmi_ad6_pg6, gmi_ad7_pg7, gmi_ad8_ph0, gmi_ad9_ph1, gmi_ad10_ph2, |
||||
gmi_ad11_ph3, gmi_ad12_ph4, gmi_ad13_ph5, gmi_ad14_ph6, gmi_ad15_ph7, |
||||
gmi_a16_pj7, gmi_a17_pb0, gmi_a18_pb1, gmi_a19_pk7, gmi_wr_n_pi0, |
||||
gmi_oe_n_pi1, gmi_dqs_p_pj3, gmi_rst_n_pi4, gen2_i2c_scl_pt5, |
||||
gen2_i2c_sda_pt6, sdmmc4_clk_pcc4, sdmmc4_cmd_pt7, sdmmc4_dat0_paa0, |
||||
sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, sdmmc4_dat3_paa3, sdmmc4_dat4_paa4, |
||||
sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, sdmmc4_dat7_paa7, cam_mclk_pcc0, |
||||
pcc1, pbb0, cam_i2c_scl_pbb1, cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6, |
||||
pbb7, pcc2, pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, kb_row0_pr0, kb_row1_pr1, |
||||
kb_row2_pr2, kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6, |
||||
kb_row7_pr7, kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_col0_pq0, |
||||
kb_col1_pq1, kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5, |
||||
kb_col6_pq6, kb_col7_pq7, clk_32k_out_pa0, sys_clk_req_pz5, core_pwr_req, |
||||
cpu_pwr_req, pwr_int_n, owr, dap1_fs_pn0, dap1_din_pn1, dap1_dout_pn2, |
||||
dap1_sclk_pn3, clk1_req_pee2, clk1_out_pw4, spdif_in_pk6, spdif_out_pk5, |
||||
dap2_fs_pa2, dap2_din_pa4, dap2_dout_pa5, dap2_sclk_pa3, dvfs_pwm_px0, |
||||
gpio_x1_aud_px1, gpio_x3_aud_px3, dvfs_clk_px2, gpio_x4_aud_px4, |
||||
gpio_x5_aud_px5, gpio_x6_aud_px6, gpio_x7_aud_px7, sdmmc3_clk_pa6, |
||||
sdmmc3_cmd_pa7, sdmmc3_dat0_pb7, sdmmc3_dat1_pb6, sdmmc3_dat2_pb5, |
||||
sdmmc3_dat3_pb4, hdmi_cec_pee3, sdmmc1_wp_n_pv3, sdmmc3_cd_n_pv2, |
||||
gpio_w2_aud_pw2, gpio_w3_aud_pw3, usb_vbus_en0_pn4, usb_vbus_en1_pn5, |
||||
sdmmc3_clk_lb_in_pee5, sdmmc3_clk_lb_out_pee4, reset_out_n. |
||||
|
||||
drive groups: |
||||
|
||||
These all support nvidia,pull-down-strength, nvidia,pull-up-strength, |
||||
nvidia,slew-rate-rising, nvidia,slew-rate-falling. Most but not all |
||||
support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode |
||||
and nvidia,drive-type. |
||||
|
||||
ao1, ao2, at1, at2, at3, at4, at5, cdev1, cdev2, dap1, dap2, dap3, dap4, |
||||
dbg, sdio3, spi, uaa, uab, uart2, uart3, sdio1, ddc, gma, gme, gmf, gmg, |
||||
gmh, owr, uda. |
||||
|
||||
Example: |
||||
|
||||
pinmux: pinmux { |
||||
compatible = "nvidia,tegra114-pinmux"; |
||||
reg = <0x70000868 0x148 /* Pad control registers */ |
||||
0x70003000 0x40c>; /* PinMux registers */ |
||||
}; |
||||
|
||||
Example board file extract: |
||||
|
||||
pinctrl { |
||||
sdmmc4_default: pinmux { |
||||
sdmmc4_clk_pcc4 { |
||||
nvidia,pins = "sdmmc4_clk_pcc4", |
||||
nvidia,function = "sdmmc4"; |
||||
nvidia,pull = <0>; |
||||
nvidia,tristate = <0>; |
||||
}; |
||||
sdmmc4_dat0_paa0 { |
||||
nvidia,pins = "sdmmc4_dat0_paa0", |
||||
"sdmmc4_dat1_paa1", |
||||
"sdmmc4_dat2_paa2", |
||||
"sdmmc4_dat3_paa3", |
||||
"sdmmc4_dat4_paa4", |
||||
"sdmmc4_dat5_paa5", |
||||
"sdmmc4_dat6_paa6", |
||||
"sdmmc4_dat7_paa7"; |
||||
nvidia,function = "sdmmc4"; |
||||
nvidia,pull = <2>; |
||||
nvidia,tristate = <0>; |
||||
}; |
||||
}; |
||||
}; |
||||
|
||||
sdhci@78000400 { |
||||
pinctrl-names = "default"; |
||||
pinctrl-0 = <&sdmmc4_default>; |
||||
}; |
||||
@ -0,0 +1,140 @@ |
||||
ST Ericsson Nomadik pinmux controller |
||||
|
||||
Required properties: |
||||
- compatible: "stericsson,nmk-pinctrl", "stericsson,nmk-pinctrl-db8540", |
||||
"stericsson,nmk-pinctrl-stn8815" |
||||
- reg: Should contain the register physical address and length of the PRCMU. |
||||
|
||||
Please refer to pinctrl-bindings.txt in this directory for details of the |
||||
common pinctrl bindings used by client devices, including the meaning of the |
||||
phrase "pin configuration node". |
||||
|
||||
ST Ericsson's pin configuration nodes act as a container for an arbitrary number of |
||||
subnodes. Each of these subnodes represents some desired configuration for a |
||||
pin, a group, or a list of pins or groups. This configuration can include the |
||||
mux function to select on those pin(s)/group(s), and various pin configuration |
||||
parameters, such as input, output, pull up, pull down... |
||||
|
||||
The name of each subnode is not important; all subnodes should be enumerated |
||||
and processed purely based on their content. |
||||
|
||||
Required subnode-properties: |
||||
- ste,pins : An array of strings. Each string contains the name of a pin or |
||||
group. |
||||
|
||||
Optional subnode-properties: |
||||
- ste,function: A string containing the name of the function to mux to the |
||||
pin or group. |
||||
|
||||
- ste,config: Handle of pin configuration node (e.g. ste,config = <&slpm_in_wkup_pdis>) |
||||
|
||||
- ste,input : <0/1/2> |
||||
0: input with no pull |
||||
1: input with pull up, |
||||
2: input with pull down, |
||||
|
||||
- ste,output: <0/1/2> |
||||
0: output low, |
||||
1: output high, |
||||
2: output (value is not specified). |
||||
|
||||
- ste,sleep: <0/1> |
||||
0: sleep mode disable, |
||||
1: sleep mode enable. |
||||
|
||||
- ste,sleep-input: <0/1/2/3> |
||||
0: sleep input with no pull, |
||||
1: sleep input with pull up, |
||||
2: sleep input with pull down. |
||||
3: sleep input and keep last input configuration (no pull, pull up or pull down). |
||||
|
||||
- ste,sleep-output: <0/1/2> |
||||
0: sleep output low, |
||||
1: sleep output high, |
||||
2: sleep output (value is not specified). |
||||
|
||||
- ste,sleep-gpio: <0/1> |
||||
0: disable sleep gpio mode, |
||||
1: enable sleep gpio mode. |
||||
|
||||
- ste,sleep-wakeup: <0/1> |
||||
0: wake-up detection enabled, |
||||
1: wake-up detection disabled. |
||||
|
||||
- ste,sleep-pull-disable: <0/1> |
||||
0: GPIO pull-up or pull-down resistor is enabled, when pin is an input, |
||||
1: GPIO pull-up and pull-down resistor are disabled. |
||||
|
||||
Example board file extract: |
||||
|
||||
pinctrl@80157000 { |
||||
compatible = "stericsson,nmk-pinctrl"; |
||||
reg = <0x80157000 0x2000>; |
||||
|
||||
pinctrl-names = "default"; |
||||
|
||||
slpm_in_wkup_pdis: slpm_in_wkup_pdis { |
||||
ste,sleep = <1>; |
||||
ste,sleep-input = <3>; |
||||
ste,sleep-wakeup = <1>; |
||||
ste,sleep-pull-disable = <0>; |
||||
}; |
||||
|
||||
slpm_out_hi_wkup_pdis: slpm_out_hi_wkup_pdis { |
||||
ste,sleep = <1>; |
||||
ste,sleep-output = <1>; |
||||
ste,sleep-wakeup = <1>; |
||||
ste,sleep-pull-disable = <0>; |
||||
}; |
||||
|
||||
slpm_out_wkup_pdis: slpm_out_wkup_pdis { |
||||
ste,sleep = <1>; |
||||
ste,sleep-output = <2>; |
||||
ste,sleep-wakeup = <1>; |
||||
ste,sleep-pull-disable = <0>; |
||||
}; |
||||
|
||||
uart0 { |
||||
uart0_default_mux: uart0_mux { |
||||
u0_default_mux { |
||||
ste,function = "u0"; |
||||
ste,pins = "u0_a_1"; |
||||
}; |
||||
}; |
||||
uart0_default_mode: uart0_default { |
||||
uart0_default_cfg1 { |
||||
ste,pins = "GPIO0", "GPIO2"; |
||||
ste,input = <1>; |
||||
}; |
||||
|
||||
uart0_default_cfg2 { |
||||
ste,pins = "GPIO1", "GPIO3"; |
||||
ste,output = <1>; |
||||
}; |
||||
}; |
||||
uart0_sleep_mode: uart0_sleep { |
||||
uart0_sleep_cfg1 { |
||||
ste,pins = "GPIO0", "GPIO2"; |
||||
ste,config = <&slpm_in_wkup_pdis>; |
||||
}; |
||||
uart0_sleep_cfg2 { |
||||
ste,pins = "GPIO1"; |
||||
ste,config = <&slpm_out_hi_wkup_pdis>; |
||||
}; |
||||
uart0_sleep_cfg3 { |
||||
ste,pins = "GPIO3"; |
||||
ste,config = <&slpm_out_wkup_pdis>; |
||||
}; |
||||
}; |
||||
}; |
||||
}; |
||||
|
||||
uart@80120000 { |
||||
compatible = "arm,pl011", "arm,primecell"; |
||||
reg = <0x80120000 0x1000>; |
||||
interrupts = <0 11 0x4>; |
||||
|
||||
pinctrl-names = "default","sleep"; |
||||
pinctrl-0 = <&uart0_default_mux>, <&uart0_default_mode>; |
||||
pinctrl-1 = <&uart0_sleep_mode>; |
||||
}; |
||||
@ -0,0 +1,13 @@ |
||||
* QNAP Power Off |
||||
|
||||
QNAP NAS devices have a microcontroller controlling the main power |
||||
supply. This microcontroller is connected to UART1 of the Kirkwood and |
||||
Orion5x SoCs. Sending the charactor 'A', at 19200 baud, tells the |
||||
microcontroller to turn the power off. This driver adds a handler to |
||||
pm_power_off which is called to turn the power off. |
||||
|
||||
Required Properties: |
||||
- compatible: Should be "qnap,power-off" |
||||
|
||||
- reg: Address and length of the register set for UART1 |
||||
- clocks: tclk clock |
||||
@ -0,0 +1,8 @@ |
||||
* Restart Power Off |
||||
|
||||
Buffalo Linkstation LS-XHL and LS-CHLv2, and other devices power off |
||||
by restarting and letting u-boot keep hold of the machine until the |
||||
user presses a button. |
||||
|
||||
Required Properties: |
||||
- compatible: Should be "restart-poweroff" |
||||
@ -0,0 +1,152 @@ |
||||
* Samsung S5M8767 Voltage and Current Regulator |
||||
|
||||
The Samsung S5M8767 is a multi-function device which includes volatage and |
||||
current regulators, rtc, charger controller and other sub-blocks. It is |
||||
interfaced to the host controller using a i2c interface. Each sub-block is |
||||
addressed by the host system using different i2c slave address. This document |
||||
describes the bindings for 'pmic' sub-block of s5m8767. |
||||
|
||||
Required properties: |
||||
- compatible: Should be "samsung,s5m8767-pmic". |
||||
- reg: Specifies the i2c slave address of the pmic block. It should be 0x66. |
||||
|
||||
- s5m8767,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt (uV) |
||||
units for buck2 when changing voltage using gpio dvs. Refer to [1] below |
||||
for additional information. |
||||
|
||||
- s5m8767,pmic-buck3-dvs-voltage: A set of 8 voltage values in micro-volt (uV) |
||||
units for buck3 when changing voltage using gpio dvs. Refer to [1] below |
||||
for additional information. |
||||
|
||||
- s5m8767,pmic-buck4-dvs-voltage: A set of 8 voltage values in micro-volt (uV) |
||||
units for buck4 when changing voltage using gpio dvs. Refer to [1] below |
||||
for additional information. |
||||
|
||||
- s5m8767,pmic-buck-ds-gpios: GPIO specifiers for three host gpio's used |
||||
for selecting GPIO DVS lines. It is one-to-one mapped to dvs gpio lines. |
||||
|
||||
[1] If none of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional |
||||
property is specified, the 's5m8767,pmic-buck[2/3/4]-dvs-voltage' |
||||
property should specify atleast one voltage level (which would be a |
||||
safe operating voltage). |
||||
|
||||
If either of the 's5m8767,pmic-buck[2/3/4]-uses-gpio-dvs' optional |
||||
property is specified, then all the eight voltage values for the |
||||
's5m8767,pmic-buck[2/3/4]-dvs-voltage' should be specified. |
||||
|
||||
Optional properties: |
||||
- interrupt-parent: Specifies the phandle of the interrupt controller to which |
||||
the interrupts from s5m8767 are delivered to. |
||||
- interrupts: Interrupt specifiers for two interrupt sources. |
||||
- First interrupt specifier is for 'irq1' interrupt. |
||||
- Second interrupt specifier is for 'alert' interrupt. |
||||
- s5m8767,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs. |
||||
- s5m8767,pmic-buck3-uses-gpio-dvs: 'buck3' can be controlled by gpio dvs. |
||||
- s5m8767,pmic-buck4-uses-gpio-dvs: 'buck4' can be controlled by gpio dvs. |
||||
|
||||
Additional properties required if either of the optional properties are used: |
||||
|
||||
- s5m8767,pmic-buck234-default-dvs-idx: Default voltage setting selected from |
||||
the possible 8 options selectable by the dvs gpios. The value of this |
||||
property should be between 0 and 7. If not specified or if out of range, the |
||||
default value of this property is set to 0. |
||||
|
||||
- s5m8767,pmic-buck-dvs-gpios: GPIO specifiers for three host gpio's used |
||||
for dvs. The format of the gpio specifier depends in the gpio controller. |
||||
|
||||
Regulators: The regulators of s5m8767 that have to be instantiated should be |
||||
included in a sub-node named 'regulators'. Regulator nodes included in this |
||||
sub-node should be of the format as listed below. |
||||
|
||||
regulator_name { |
||||
ldo1_reg: LDO1 { |
||||
regulator-name = "VDD_ALIVE_1.0V"; |
||||
regulator-min-microvolt = <1100000>; |
||||
regulator-max-microvolt = <1100000>; |
||||
regulator-always-on; |
||||
regulator-boot-on; |
||||
op_mode = <1>; /* Normal Mode */ |
||||
}; |
||||
}; |
||||
The above regulator entries are defined in regulator bindings documentation |
||||
except op_mode description. |
||||
- op_mode: describes the different operating modes of the LDO's with |
||||
power mode change in SOC. The different possible values are, |
||||
0 - always off mode |
||||
1 - on in normal mode |
||||
2 - low power mode |
||||
3 - suspend mode |
||||
|
||||
The following are the names of the regulators that the s5m8767 pmic block |
||||
supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number |
||||
as per the datasheet of s5m8767. |
||||
|
||||
- LDOn |
||||
- valid values for n are 1 to 28 |
||||
- Example: LDO0, LD01, LDO28 |
||||
- BUCKn |
||||
- valid values for n are 1 to 9. |
||||
- Example: BUCK1, BUCK2, BUCK9 |
||||
|
||||
The bindings inside the regulator nodes use the standard regulator bindings |
||||
which are documented elsewhere. |
||||
|
||||
Example: |
||||
|
||||
s5m8767_pmic@66 { |
||||
compatible = "samsung,s5m8767-pmic"; |
||||
reg = <0x66>; |
||||
|
||||
s5m8767,pmic-buck2-uses-gpio-dvs; |
||||
s5m8767,pmic-buck3-uses-gpio-dvs; |
||||
s5m8767,pmic-buck4-uses-gpio-dvs; |
||||
|
||||
s5m8767,pmic-buck-default-dvs-idx = <0>; |
||||
|
||||
s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 1 0 0>, /* DVS1 */ |
||||
<&gpx0 1 1 0 0>, /* DVS2 */ |
||||
<&gpx0 2 1 0 0>; /* DVS3 */ |
||||
|
||||
s5m8767,pmic-buck-ds-gpios = <&gpx2 3 1 0 0>, /* SET1 */ |
||||
<&gpx2 4 1 0 0>, /* SET2 */ |
||||
<&gpx2 5 1 0 0>; /* SET3 */ |
||||
|
||||
s5m8767,pmic-buck2-dvs-voltage = <1350000>, <1300000>, |
||||
<1250000>, <1200000>, |
||||
<1150000>, <1100000>, |
||||
<1000000>, <950000>; |
||||
|
||||
s5m8767,pmic-buck3-dvs-voltage = <1100000>, <1100000>, |
||||
<1100000>, <1100000>, |
||||
<1000000>, <1000000>, |
||||
<1000000>, <1000000>; |
||||
|
||||
s5m8767,pmic-buck4-dvs-voltage = <1200000>, <1200000>, |
||||
<1200000>, <1200000>, |
||||
<1200000>, <1200000>, |
||||
<1200000>, <1200000>; |
||||
|
||||
regulators { |
||||
ldo1_reg: LDO1 { |
||||
regulator-name = "VDD_ABB_3.3V"; |
||||
regulator-min-microvolt = <3300000>; |
||||
regulator-max-microvolt = <3300000>; |
||||
op_mode = <1>; /* Normal Mode */ |
||||
}; |
||||
|
||||
ldo2_reg: LDO2 { |
||||
regulator-name = "VDD_ALIVE_1.1V"; |
||||
regulator-min-microvolt = <1100000>; |
||||
regulator-max-microvolt = <1100000>; |
||||
regulator-always-on; |
||||
}; |
||||
|
||||
buck1_reg: BUCK1 { |
||||
regulator-name = "VDD_MIF_1.2V"; |
||||
regulator-min-microvolt = <950000>; |
||||
regulator-max-microvolt = <1350000>; |
||||
regulator-always-on; |
||||
regulator-boot-on; |
||||
}; |
||||
}; |
||||
}; |
||||
@ -0,0 +1,27 @@ |
||||
TPS51632 Voltage regulators |
||||
|
||||
Required properties: |
||||
- compatible: Must be "ti,tps51632" |
||||
- reg: I2C slave address |
||||
|
||||
Optional properties: |
||||
- ti,enable-pwm-dvfs: Enable the DVFS voltage control through the PWM interface. |
||||
- ti,dvfs-step-20mV: The 20mV step voltage when PWM DVFS enabled. Missing this |
||||
will set 10mV step voltage in PWM DVFS mode. In normal mode, the voltage |
||||
step is 10mV as per datasheet. |
||||
|
||||
Any property defined as part of the core regulator binding, defined in |
||||
regulator.txt, can also be used. |
||||
|
||||
Example: |
||||
|
||||
tps51632 { |
||||
compatible = "ti,tps51632"; |
||||
reg = <0x43>; |
||||
regulator-name = "tps51632-vout"; |
||||
regulator-min-microvolt = <500000>; |
||||
regulator-max-microvolt = <1500000>; |
||||
regulator-boot-on; |
||||
ti,enable-pwm-dvfs; |
||||
ti,dvfs-step-20mV; |
||||
}; |
||||
@ -0,0 +1,12 @@ |
||||
Renesas MSIOF spi controller |
||||
|
||||
Required properties: |
||||
- compatible : "renesas,sh-msiof" for SuperH or |
||||
"renesas,sh-mobile-msiof" for SH Mobile series |
||||
- reg : Offset and length of the register set for the device |
||||
- interrupts : interrupt line used by MSIOF |
||||
|
||||
Optional properties: |
||||
- num-cs : total number of chip-selects |
||||
- renesas,tx-fifo-size : Overrides the default tx fifo size given in words |
||||
- renesas,rx-fifo-size : Overrides the default rx fifo size given in words |
||||
@ -0,0 +1,93 @@ |
||||
Kernel driver ina209 |
||||
===================== |
||||
|
||||
Supported chips: |
||||
* Burr-Brown / Texas Instruments INA209 |
||||
Prefix: 'ina209' |
||||
Addresses scanned: - |
||||
Datasheet: |
||||
http://www.ti.com/lit/gpn/ina209 |
||||
|
||||
Author: Paul Hays <Paul.Hays@cattail.ca> |
||||
Author: Ira W. Snyder <iws@ovro.caltech.edu> |
||||
Author: Guenter Roeck <linux@roeck-us.net> |
||||
|
||||
|
||||
Description |
||||
----------- |
||||
|
||||
The TI / Burr-Brown INA209 monitors voltage, current, and power on the high side |
||||
of a D.C. power supply. It can perform measurements and calculations in the |
||||
background to supply readings at any time. It includes a programmable |
||||
calibration multiplier to scale the displayed current and power values. |
||||
|
||||
|
||||
Sysfs entries |
||||
------------- |
||||
|
||||
The INA209 chip is highly configurable both via hardwiring and via |
||||
the I2C bus. See the datasheet for details. |
||||
|
||||
This tries to expose most monitoring features of the hardware via |
||||
sysfs. It does not support every feature of this chip. |
||||
|
||||
|
||||
in0_input shunt voltage (mV) |
||||
in0_input_highest shunt voltage historical maximum reading (mV) |
||||
in0_input_lowest shunt voltage historical minimum reading (mV) |
||||
in0_reset_history reset shunt voltage history |
||||
in0_max shunt voltage max alarm limit (mV) |
||||
in0_min shunt voltage min alarm limit (mV) |
||||
in0_crit_max shunt voltage crit max alarm limit (mV) |
||||
in0_crit_min shunt voltage crit min alarm limit (mV) |
||||
in0_max_alarm shunt voltage max alarm limit exceeded |
||||
in0_min_alarm shunt voltage min alarm limit exceeded |
||||
in0_crit_max_alarm shunt voltage crit max alarm limit exceeded |
||||
in0_crit_min_alarm shunt voltage crit min alarm limit exceeded |
||||
|
||||
in1_input bus voltage (mV) |
||||
in1_input_highest bus voltage historical maximum reading (mV) |
||||
in1_input_lowest bus voltage historical minimum reading (mV) |
||||
in1_reset_history reset bus voltage history |
||||
in1_max bus voltage max alarm limit (mV) |
||||
in1_min bus voltage min alarm limit (mV) |
||||
in1_crit_max bus voltage crit max alarm limit (mV) |
||||
in1_crit_min bus voltage crit min alarm limit (mV) |
||||
in1_max_alarm bus voltage max alarm limit exceeded |
||||
in1_min_alarm bus voltage min alarm limit exceeded |
||||
in1_crit_max_alarm bus voltage crit max alarm limit exceeded |
||||
in1_crit_min_alarm bus voltage crit min alarm limit exceeded |
||||
|
||||
power1_input power measurement (uW) |
||||
power1_input_highest power historical maximum reading (uW) |
||||
power1_reset_history reset power history |
||||
power1_max power max alarm limit (uW) |
||||
power1_crit power crit alarm limit (uW) |
||||
power1_max_alarm power max alarm limit exceeded |
||||
power1_crit_alarm power crit alarm limit exceeded |
||||
|
||||
curr1_input current measurement (mA) |
||||
|
||||
update_interval data conversion time; affects number of samples used |
||||
to average results for shunt and bus voltages. |
||||
|
||||
General Remarks |
||||
--------------- |
||||
|
||||
The power and current registers in this chip require that the calibration |
||||
register is programmed correctly before they are used. Normally this is expected |
||||
to be done in the BIOS. In the absence of BIOS programming, the shunt resistor |
||||
voltage can be provided using platform data. The driver uses platform data from |
||||
the ina2xx driver for this purpose. If calibration register data is not provided |
||||
via platform data, the driver checks if the calibration register has been |
||||
programmed (ie has a value not equal to zero). If so, this value is retained. |
||||
Otherwise, a default value reflecting a shunt resistor value of 10 mOhm is |
||||
programmed into the calibration register. |
||||
|
||||
|
||||
Output Pins |
||||
----------- |
||||
|
||||
Output pin programming is a board feature which depends on the BIOS. It is |
||||
outside the scope of a hardware monitoring driver to enable or disable output |
||||
pins. |
||||
@ -0,0 +1,90 @@ |
||||
Kernel driver lm73 |
||||
================== |
||||
|
||||
Supported chips: |
||||
* Texas Instruments LM73 |
||||
Prefix: 'lm73' |
||||
Addresses scanned: I2C 0x48, 0x49, 0x4a, 0x4c, 0x4d, and 0x4e |
||||
Datasheet: Publicly available at the Texas Instruments website |
||||
http://www.ti.com/product/lm73 |
||||
|
||||
Author: Guillaume Ligneul <guillaume.ligneul@gmail.com> |
||||
Documentation: Chris Verges <kg4ysn@gmail.com> |
||||
|
||||
|
||||
Description |
||||
----------- |
||||
|
||||
The LM73 is a digital temperature sensor. All temperature values are |
||||
given in degrees Celsius. |
||||
|
||||
Measurement Resolution Support |
||||
------------------------------ |
||||
|
||||
The LM73 supports four resolutions, defined in terms of degrees C per |
||||
LSB: 0.25, 0.125, 0.0625, and 0.3125. Changing the resolution mode |
||||
affects the conversion time of the LM73's analog-to-digital converter. |
||||
From userspace, the desired resolution can be specified as a function of |
||||
conversion time via the 'update_interval' sysfs attribute for the |
||||
device. This attribute will normalize ranges of input values to the |
||||
maximum times defined for the resolution in the datasheet. |
||||
|
||||
Resolution Conv. Time Input Range |
||||
(C/LSB) (msec) (msec) |
||||
-------------------------------------- |
||||
0.25 14 0..14 |
||||
0.125 28 15..28 |
||||
0.0625 56 29..56 |
||||
0.03125 112 57..infinity |
||||
-------------------------------------- |
||||
|
||||
The following examples show how the 'update_interval' attribute can be |
||||
used to change the conversion time: |
||||
|
||||
$ echo 0 > update_interval |
||||
$ cat update_interval |
||||
14 |
||||
$ cat temp1_input |
||||
24250 |
||||
|
||||
$ echo 22 > update_interval |
||||
$ cat update_interval |
||||
28 |
||||
$ cat temp1_input |
||||
24125 |
||||
|
||||
$ echo 56 > update_interval |
||||
$ cat update_interval |
||||
56 |
||||
$ cat temp1_input |
||||
24062 |
||||
|
||||
$ echo 85 > update_interval |
||||
$ cat update_interval |
||||
112 |
||||
$ cat temp1_input |
||||
24031 |
||||
|
||||
As shown here, the lm73 driver automatically adjusts any user input for |
||||
'update_interval' via a step function. Reading back the |
||||
'update_interval' value after a write operation will confirm the |
||||
conversion time actively in use. |
||||
|
||||
Mathematically, the resolution can be derived from the conversion time |
||||
via the following function: |
||||
|
||||
g(x) = 0.250 * [log(x/14) / log(2)] |
||||
|
||||
where 'x' is the output from 'update_interval' and 'g(x)' is the |
||||
resolution in degrees C per LSB. |
||||
|
||||
Alarm Support |
||||
------------- |
||||
|
||||
The LM73 features a simple over-temperature alarm mechanism. This |
||||
feature is exposed via the sysfs attributes. |
||||
|
||||
The attributes 'temp1_max_alarm' and 'temp1_min_alarm' are flags |
||||
provided by the LM73 that indicate whether the measured temperature has |
||||
passed the 'temp1_max' and 'temp1_min' thresholds, respectively. These |
||||
values _must_ be read to clear the registers on the LM73. |
||||
@ -0,0 +1,58 @@ |
||||
Kernel driver max6697 |
||||
===================== |
||||
|
||||
Supported chips: |
||||
* Maxim MAX6581 |
||||
Prefix: 'max6581' |
||||
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6581.pdf |
||||
* Maxim MAX6602 |
||||
Prefix: 'max6602' |
||||
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6602.pdf |
||||
* Maxim MAX6622 |
||||
Prefix: 'max6622' |
||||
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6622.pdf |
||||
* Maxim MAX6636 |
||||
Prefix: 'max6636' |
||||
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6636.pdf |
||||
* Maxim MAX6689 |
||||
Prefix: 'max6689' |
||||
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6689.pdf |
||||
* Maxim MAX6693 |
||||
Prefix: 'max6693' |
||||
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6693.pdf |
||||
* Maxim MAX6694 |
||||
Prefix: 'max6694' |
||||
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6694.pdf |
||||
* Maxim MAX6697 |
||||
Prefix: 'max6697' |
||||
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6697.pdf |
||||
* Maxim MAX6698 |
||||
Prefix: 'max6698' |
||||
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6698.pdf |
||||
* Maxim MAX6699 |
||||
Prefix: 'max6699' |
||||
Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX6699.pdf |
||||
|
||||
Author: |
||||
Guenter Roeck <linux@roeck-us.net> |
||||
|
||||
Description |
||||
----------- |
||||
|
||||
This driver implements support for several MAX6697 compatible temperature sensor |
||||
chips. The chips support one local temperature sensor plus four, six, or seven |
||||
remote temperature sensors. Remote temperature sensors are diode-connected |
||||
thermal transitors, except for MAX6698 which supports three diode-connected |
||||
thermal transistors plus three thermistors in addition to the local temperature |
||||
sensor. |
||||
|
||||
The driver provides the following sysfs attributes. temp1 is the local (chip) |
||||
temperature, temp[2..n] are remote temperatures. The actually supported |
||||
per-channel attributes are chip type and channel dependent. |
||||
|
||||
tempX_input RO temperature |
||||
tempX_max RW temperature maximum threshold |
||||
tempX_max_alarm RO temperature maximum threshold alarm |
||||
tempX_crit RW temperature critical threshold |
||||
tempX_crit_alarm RO temperature critical threshold alarm |
||||
tempX_fault RO temperature diode fault (remote sensors only) |
||||
@ -1,203 +0,0 @@ |
||||
Released 1994-06-13 |
||||
|
||||
|
||||
CONTENTS: |
||||
|
||||
1. Introduction. |
||||
2. License. |
||||
3. Files in this release. |
||||
4. Installation. |
||||
5. Problems and tuning. |
||||
6. Using the drivers with earlier releases. |
||||
7. Acknowledgments. |
||||
|
||||
|
||||
1. INTRODUCTION. |
||||
|
||||
This is a set of Ethernet drivers for the D-Link DE-600/DE-620 |
||||
pocket adapters, for the parallel port on a Linux based machine. |
||||
Some adapter "clones" will also work. Xircom is _not_ a clone... |
||||
These drivers _can_ be used as loadable modules, |
||||
and were developed for use on Linux 1.1.13 and above. |
||||
For use on Linux 1.0.X, or earlier releases, see below. |
||||
|
||||
I have used these drivers for NFS, ftp, telnet and X-clients on |
||||
remote machines. Transmissions with ftp seems to work as |
||||
good as can be expected (i.e. > 80k bytes/sec) from a |
||||
parallel port...:-) Receive speeds will be about 60-80% of this. |
||||
Depending on your machine, somewhat higher speeds can be achieved. |
||||
|
||||
All comments/fixes to Bjorn Ekwall (bj0rn@blox.se). |
||||
|
||||
|
||||
2. LICENSE. |
||||
|
||||
This program is free software; you can redistribute it |
||||
and/or modify it under the terms of the GNU General Public |
||||
License as published by the Free Software Foundation; either |
||||
version 2, or (at your option) any later version. |
||||
|
||||
This program is distributed in the hope that it will be |
||||
useful, but WITHOUT ANY WARRANTY; without even the implied |
||||
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR |
||||
PURPOSE. See the GNU General Public License for more |
||||
details. |
||||
|
||||
You should have received a copy of the GNU General Public |
||||
License along with this program; if not, write to the Free |
||||
Software Foundation, Inc., 675 Mass Ave, Cambridge, MA |
||||
02139, USA. |
||||
|
||||
|
||||
3. FILES IN THIS RELEASE. |
||||
|
||||
README.DLINK This file. |
||||
de600.c The Source (may it be with You :-) for the DE-600 |
||||
de620.c ditto for the DE-620 |
||||
de620.h Macros for de620.c |
||||
|
||||
If you are upgrading from the d-link tar release, there will |
||||
also be a "dlink-patches" file that will patch Linux 1.1.18: |
||||
linux/drivers/net/Makefile |
||||
linux/drivers/net/CONFIG |
||||
linux/drivers/net/MODULES |
||||
linux/drivers/net/Space.c |
||||
linux/config.in |
||||
Apply the patch by: |
||||
"cd /usr/src; patch -p0 < linux/drivers/net/dlink-patches" |
||||
The old source, "linux/drivers/net/d_link.c", can be removed. |
||||
|
||||
|
||||
4. INSTALLATION. |
||||
|
||||
o Get the latest net binaries, according to current net.wisdom. |
||||
|
||||
o Read the NET-2 and Ethernet HOWTOs and modify your setup. |
||||
|
||||
o If your parallel port has a strange address or irq, |
||||
modify "linux/drivers/net/CONFIG" accordingly, or adjust |
||||
the parameters in the "tuning" section in the sources. |
||||
|
||||
If you are going to use the drivers as loadable modules, do _not_ |
||||
enable them while doing "make config", but instead make sure that |
||||
the drivers are included in "linux/drivers/net/MODULES". |
||||
|
||||
If you are _not_ going to use the driver(s) as loadable modules, |
||||
but instead have them included in the kernel, remember to enable |
||||
the drivers while doing "make config". |
||||
|
||||
o To include networking and DE600/DE620 support in your kernel: |
||||
# cd /linux |
||||
(as modules:) |
||||
# make config (answer yes on CONFIG_NET and CONFIG_INET) |
||||
(else included in the kernel:) |
||||
# make config (answer yes on CONFIG _NET, _INET and _DE600 or _DE620) |
||||
# make clean |
||||
# make zImage (or whatever magic you usually do) |
||||
|
||||
o I use lilo to boot multiple kernels, so that I at least |
||||
can have one working kernel :-). If you do too, append |
||||
these lines to /etc/lilo/config: |
||||
|
||||
image = /linux/zImage |
||||
label = newlinux |
||||
root = /dev/hda2 (or whatever YOU have...) |
||||
|
||||
# /etc/lilo/install |
||||
|
||||
o Do "sync" and reboot the new kernel with a D-Link |
||||
DE-600/DE-620 pocket adapter connected. |
||||
|
||||
o The adapter can be configured with ifconfig eth? |
||||
where the actual number is decided by the kernel |
||||
when the drivers are initialized. |
||||
|
||||
|
||||
5. "PROBLEMS" AND TUNING, |
||||
|
||||
o If you see error messages from the driver, and if the traffic |
||||
stops on the adapter, try to do "ifconfig" and "route" once |
||||
more, just as in "rc.inet1". This should take care of most |
||||
problems, including effects from power loss, or adapters that |
||||
aren't connected to the printer port in some way or another. |
||||
You can somewhat change the behaviour by enabling/disabling |
||||
the macro SHUTDOWN_WHEN_LOST in the "tuning" section. |
||||
For the DE-600 there is another macro, CHECK_LOST_DE600, |
||||
that you might want to read about in the "tuning" section. |
||||
|
||||
o Some machines have trouble handling the parallel port and |
||||
the adapter at high speed. If you experience problems: |
||||
|
||||
DE-600: |
||||
- The adapter is not recognized at boot, i.e. an Ethernet |
||||
address of 00:80:c8:... is not shown, try to add another |
||||
"; SLOW_DOWN_IO" |
||||
at DE600_SLOW_DOWN in the "tuning" section. As a last resort, |
||||
uncomment: "#define REALLY_SLOW_IO" (see <asm/io.h> for hints). |
||||
|
||||
- You experience "timeout" messages: first try to add another |
||||
"; SLOW_DOWN_IO" |
||||
at DE600_SLOW_DOWN in the "tuning" section, _then_ try to |
||||
increase the value (original value: 5) at |
||||
"if (tickssofar < 5)" near line 422. |
||||
|
||||
DE-620: |
||||
- Your parallel port might be "sluggish". To cater for |
||||
this, there are the macros LOWSPEED and READ_DELAY/WRITE_DELAY |
||||
in the "tuning" section. Your first step should be to enable |
||||
LOWSPEED, and after that you can "tune" the XXX_DELAY values. |
||||
|
||||
o If the adapter _is_ recognized at boot but you get messages |
||||
about "Network Unreachable", then the problem is probably |
||||
_not_ with the driver. Check your net configuration instead |
||||
(ifconfig and route) in "rc.inet1". |
||||
|
||||
o There is some rudimentary support for debugging, look at |
||||
the source. Use "-DDE600_DEBUG=3" or "-DDE620_DEBUG=3" |
||||
when compiling, or include it in "linux/drivers/net/CONFIG". |
||||
IF YOU HAVE PROBLEMS YOU CAN'T SOLVE: PLEASE COMPILE THE DRIVER |
||||
WITH DEBUGGING ENABLED, AND SEND ME THE RESULTING OUTPUT! |
||||
|
||||
|
||||
6. USING THE DRIVERS WITH EARLIER RELEASES. |
||||
|
||||
The later 1.1.X releases of the Linux kernel include some |
||||
changes in the networking layer (a.k.a. NET3). This affects |
||||
these drivers in a few places. The hints that follow are |
||||
_not_ tested by me, since I don't have the disk space to keep |
||||
all releases on-line. |
||||
Known needed changes to date: |
||||
- release patchfile: some patches will fail, but they should |
||||
be easy to apply "by hand", since they are trivial. |
||||
(Space.c: d_link_init() is now called de600_probe()) |
||||
- de600.c: change "mark_bh(NET_BH)" to "mark_bh(INET_BH)". |
||||
- de620.c: (maybe) change the code around "netif_rx(skb);" to be |
||||
similar to the code around "dev_rint(...)" in de600.c |
||||
|
||||
|
||||
7. ACKNOWLEDGMENTS. |
||||
|
||||
These drivers wouldn't have been done without the base |
||||
(and support) from Ross Biro, and D-Link Systems Inc. |
||||
The driver relies upon GPL-ed source from D-Link Systems Inc. |
||||
and from Russel Nelson at Crynwr Software <nelson@crynwr.com>. |
||||
|
||||
Additional input also from: |
||||
Donald Becker <becker@super.org>, Alan Cox <A.Cox@swansea.ac.uk> |
||||
and Fred N. van Kempen <waltje@uWalt.NL.Mugnet.ORG> |
||||
|
||||
DE-600 alpha release primary victim^H^H^H^H^H^Htester: |
||||
- Erik Proper <erikp@cs.kun.nl>. |
||||
Good input also from several users, most notably |
||||
- Mark Burton <markb@ordern.demon.co.uk>. |
||||
|
||||
DE-620 alpha release victims^H^H^H^H^H^H^Htesters: |
||||
- J. Joshua Kopper <kopper@rtsg.mot.com> |
||||
- Olav Kvittem <Olav.Kvittem@uninett.no> |
||||
- Germano Caronni <caronni@nessie.cs.id.ethz.ch> |
||||
- Jeremy Fitzhardinge <jeremy@suite.sw.oz.au> |
||||
|
||||
|
||||
Happy hacking! |
||||
|
||||
Bjorn Ekwall == bj0rn@blox.se |
||||
@ -1,92 +0,0 @@ |
||||
|
||||
DE10x |
||||
===== |
||||
|
||||
Memory Addresses: |
||||
|
||||
SW1 SW2 SW3 SW4 |
||||
64K on on on on d0000 dbfff |
||||
off on on on c0000 cbfff |
||||
off off on on e0000 ebfff |
||||
|
||||
32K on on off on d8000 dbfff |
||||
off on off on c8000 cbfff |
||||
off off off on e8000 ebfff |
||||
|
||||
DBR ROM on on dc000 dffff |
||||
off on cc000 cffff |
||||
off off ec000 effff |
||||
|
||||
Note that the 2K mode is set by SW3/SW4 on/off or off/off. Address |
||||
assignment is through the RBSA register. |
||||
|
||||
I/O Address: |
||||
SW5 |
||||
0x300 on |
||||
0x200 off |
||||
|
||||
Remote Boot: |
||||
SW6 |
||||
Disable on |
||||
Enable off |
||||
|
||||
Remote Boot Timeout: |
||||
SW7 |
||||
2.5min on |
||||
30s off |
||||
|
||||
IRQ: |
||||
SW8 SW9 SW10 SW11 SW12 |
||||
2 on off off off off |
||||
3 off on off off off |
||||
4 off off on off off |
||||
5 off off off on off |
||||
7 off off off off on |
||||
|
||||
DE20x |
||||
===== |
||||
|
||||
Memory Size: |
||||
|
||||
SW3 SW4 |
||||
64K on on |
||||
32K off on |
||||
2K on off |
||||
2K off off |
||||
|
||||
Start Addresses: |
||||
|
||||
SW1 SW2 SW3 SW4 |
||||
64K on on on on c0000 cffff |
||||
on off on on d0000 dffff |
||||
off on on on e0000 effff |
||||
|
||||
32K on on off off c8000 cffff |
||||
on off off off d8000 dffff |
||||
off on off off e8000 effff |
||||
|
||||
Illegal off off - - - - |
||||
|
||||
I/O Address: |
||||
SW5 |
||||
0x300 on |
||||
0x200 off |
||||
|
||||
Remote Boot: |
||||
SW6 |
||||
Disable on |
||||
Enable off |
||||
|
||||
Remote Boot Timeout: |
||||
SW7 |
||||
2.5min on |
||||
30s off |
||||
|
||||
IRQ: |
||||
SW8 SW9 SW10 SW11 SW12 |
||||
5 on off off off off |
||||
9 off on off off off |
||||
10 off off on off off |
||||
11 off off off on off |
||||
15 off off off off on |
||||
|
||||
@ -1,46 +0,0 @@ |
||||
The EtherWORKS 3 driver in this distribution is designed to work with all |
||||
kernels > 1.1.33 (approx) and includes tools in the 'ewrk3tools' |
||||
subdirectory to allow set up of the card, similar to the MSDOS |
||||
'NICSETUP.EXE' tools provided on the DOS drivers disk (type 'make' in that |
||||
subdirectory to make the tools). |
||||
|
||||
The supported cards are DE203, DE204 and DE205. All other cards are NOT |
||||
supported - refer to 'depca.c' for running the LANCE based network cards and |
||||
'de4x5.c' for the DIGITAL Semiconductor PCI chip based adapters from |
||||
Digital. |
||||
|
||||
The ability to load this driver as a loadable module has been included and |
||||
used extensively during the driver development (to save those long reboot |
||||
sequences). To utilise this ability, you have to do 8 things: |
||||
|
||||
0) have a copy of the loadable modules code installed on your system. |
||||
1) copy ewrk3.c from the /linux/drivers/net directory to your favourite |
||||
temporary directory. |
||||
2) edit the source code near line 1898 to reflect the I/O address and |
||||
IRQ you're using. |
||||
3) compile ewrk3.c, but include -DMODULE in the command line to ensure |
||||
that the correct bits are compiled (see end of source code). |
||||
4) if you are wanting to add a new card, goto 5. Otherwise, recompile a |
||||
kernel with the ewrk3 configuration turned off and reboot. |
||||
5) insmod ewrk3.o |
||||
[Alan Cox: Changed this so you can insmod ewrk3.o irq=x io=y] |
||||
[Adam Kropelin: Multiple cards now supported by irq=x1,x2 io=y1,y2] |
||||
6) run the net startup bits for your new eth?? interface manually |
||||
(usually /etc/rc.inet[12] at boot time). |
||||
7) enjoy! |
||||
|
||||
Note that autoprobing is not allowed in loadable modules - the system is |
||||
already up and running and you're messing with interrupts. |
||||
|
||||
To unload a module, turn off the associated interface |
||||
'ifconfig eth?? down' then 'rmmod ewrk3'. |
||||
|
||||
The performance we've achieved so far has been measured through the 'ttcp' |
||||
tool at 975kB/s. This measures the total TCP stack performance which |
||||
includes the card, so don't expect to get much nearer the 1.25MB/s |
||||
theoretical Ethernet rate. |
||||
|
||||
|
||||
Enjoy! |
||||
|
||||
Dave |
||||
@ -1,63 +0,0 @@ |
||||
Behaviour of Cards Under Multicast |
||||
================================== |
||||
|
||||
This is how they currently behave, not what the hardware can do--for example, |
||||
the Lance driver doesn't use its filter, even though the code for loading |
||||
it is in the DEC Lance-based driver. |
||||
|
||||
The following are requirements for multicasting |
||||
----------------------------------------------- |
||||
AppleTalk Multicast hardware filtering not important but |
||||
avoid cards only doing promisc |
||||
IP-Multicast Multicast hardware filters really help |
||||
IP-MRoute AllMulti hardware filters are of no help |
||||
|
||||
|
||||
Board Multicast AllMulti Promisc Filter |
||||
------------------------------------------------------------------------ |
||||
3c501 YES YES YES Software |
||||
3c503 YES YES YES Hardware |
||||
3c505 YES NO YES Hardware |
||||
3c507 NO NO NO N/A |
||||
3c509 YES YES YES Software |
||||
3c59x YES YES YES Software |
||||
ac3200 YES YES YES Hardware |
||||
apricot YES PROMISC YES Hardware |
||||
arcnet NO NO NO N/A |
||||
at1700 PROMISC PROMISC YES Software |
||||
atp PROMISC PROMISC YES Software |
||||
cs89x0 YES YES YES Software |
||||
de4x5 YES YES YES Hardware |
||||
de600 NO NO NO N/A |
||||
de620 PROMISC PROMISC YES Software |
||||
depca YES PROMISC YES Hardware |
||||
dmfe YES YES YES Software(*) |
||||
e2100 YES YES YES Hardware |
||||
eepro YES PROMISC YES Hardware |
||||
eexpress NO NO NO N/A |
||||
ewrk3 YES PROMISC YES Hardware |
||||
hp-plus YES YES YES Hardware |
||||
hp YES YES YES Hardware |
||||
hp100 YES YES YES Hardware |
||||
ibmtr NO NO NO N/A |
||||
ioc3-eth YES YES YES Hardware |
||||
lance YES YES YES Software(#) |
||||
ne YES YES YES Hardware |
||||
ni52 <------------------ Buggy ------------------> |
||||
ni65 YES YES YES Software(#) |
||||
seeq NO NO NO N/A |
||||
sgiseek <------------------ Buggy ------------------> |
||||
smc-ultra YES YES YES Hardware |
||||
sunlance YES YES YES Hardware |
||||
tulip YES YES YES Hardware |
||||
wavelan YES PROMISC YES Hardware |
||||
wd YES YES YES Hardware |
||||
xirc2ps_cs YES YES YES Hardware |
||||
znet YES YES YES Software |
||||
|
||||
|
||||
PROMISC = This multicast mode is in fact promiscuous mode. Avoid using |
||||
cards who go PROMISC on any multicast in a multicast kernel. |
||||
|
||||
(#) = Hardware multicast support is not used yet. |
||||
(*) = Hardware support for Davicom 9132 chipset only. |
||||
@ -0,0 +1,176 @@ |
||||
/proc/sys/net/netfilter/nf_conntrack_* Variables: |
||||
|
||||
nf_conntrack_acct - BOOLEAN |
||||
0 - disabled (default) |
||||
not 0 - enabled |
||||
|
||||
Enable connection tracking flow accounting. 64-bit byte and packet |
||||
counters per flow are added. |
||||
|
||||
nf_conntrack_buckets - INTEGER (read-only) |
||||
Size of hash table. If not specified as parameter during module |
||||
loading, the default size is calculated by dividing total memory |
||||
by 16384 to determine the number of buckets but the hash table will |
||||
never have fewer than 32 or more than 16384 buckets. |
||||
|
||||
nf_conntrack_checksum - BOOLEAN |
||||
0 - disabled |
||||
not 0 - enabled (default) |
||||
|
||||
Verify checksum of incoming packets. Packets with bad checksums are |
||||
in INVALID state. If this is enabled, such packets will not be |
||||
considered for connection tracking. |
||||
|
||||
nf_conntrack_count - INTEGER (read-only) |
||||
Number of currently allocated flow entries. |
||||
|
||||
nf_conntrack_events - BOOLEAN |
||||
0 - disabled |
||||
not 0 - enabled (default) |
||||
|
||||
If this option is enabled, the connection tracking code will |
||||
provide userspace with connection tracking events via ctnetlink. |
||||
|
||||
nf_conntrack_events_retry_timeout - INTEGER (seconds) |
||||
default 15 |
||||
|
||||
This option is only relevant when "reliable connection tracking |
||||
events" are used. Normally, ctnetlink is "lossy", that is, |
||||
events are normally dropped when userspace listeners can't keep up. |
||||
|
||||
Userspace can request "reliable event mode". When this mode is |
||||
active, the conntrack will only be destroyed after the event was |
||||
delivered. If event delivery fails, the kernel periodically |
||||
re-tries to send the event to userspace. |
||||
|
||||
This is the maximum interval the kernel should use when re-trying |
||||
to deliver the destroy event. |
||||
|
||||
A higher number means there will be fewer delivery retries and it |
||||
will take longer for a backlog to be processed. |
||||
|
||||
nf_conntrack_expect_max - INTEGER |
||||
Maximum size of expectation table. Default value is |
||||
nf_conntrack_buckets / 256. Minimum is 1. |
||||
|
||||
nf_conntrack_frag6_high_thresh - INTEGER |
||||
default 262144 |
||||
|
||||
Maximum memory used to reassemble IPv6 fragments. When |
||||
nf_conntrack_frag6_high_thresh bytes of memory is allocated for this |
||||
purpose, the fragment handler will toss packets until |
||||
nf_conntrack_frag6_low_thresh is reached. |
||||
|
||||
nf_conntrack_frag6_low_thresh - INTEGER |
||||
default 196608 |
||||
|
||||
See nf_conntrack_frag6_low_thresh |
||||
|
||||
nf_conntrack_frag6_timeout - INTEGER (seconds) |
||||
default 60 |
||||
|
||||
Time to keep an IPv6 fragment in memory. |
||||
|
||||
nf_conntrack_generic_timeout - INTEGER (seconds) |
||||
default 600 |
||||
|
||||
Default for generic timeout. This refers to layer 4 unknown/unsupported |
||||
protocols. |
||||
|
||||
nf_conntrack_helper - BOOLEAN |
||||
0 - disabled |
||||
not 0 - enabled (default) |
||||
|
||||
Enable automatic conntrack helper assignment. |
||||
|
||||
nf_conntrack_icmp_timeout - INTEGER (seconds) |
||||
default 30 |
||||
|
||||
Default for ICMP timeout. |
||||
|
||||
nf_conntrack_icmpv6_timeout - INTEGER (seconds) |
||||
default 30 |
||||
|
||||
Default for ICMP6 timeout. |
||||
|
||||
nf_conntrack_log_invalid - INTEGER |
||||
0 - disable (default) |
||||
1 - log ICMP packets |
||||
6 - log TCP packets |
||||
17 - log UDP packets |
||||
33 - log DCCP packets |
||||
41 - log ICMPv6 packets |
||||
136 - log UDPLITE packets |
||||
255 - log packets of any protocol |
||||
|
||||
Log invalid packets of a type specified by value. |
||||
|
||||
nf_conntrack_max - INTEGER |
||||
Size of connection tracking table. Default value is |
||||
nf_conntrack_buckets value * 4. |
||||
|
||||
nf_conntrack_tcp_be_liberal - BOOLEAN |
||||
0 - disabled (default) |
||||
not 0 - enabled |
||||
|
||||
Be conservative in what you do, be liberal in what you accept from others. |
||||
If it's non-zero, we mark only out of window RST segments as INVALID. |
||||
|
||||
nf_conntrack_tcp_loose - BOOLEAN |
||||
0 - disabled |
||||
not 0 - enabled (default) |
||||
|
||||
If it is set to zero, we disable picking up already established |
||||
connections. |
||||
|
||||
nf_conntrack_tcp_max_retrans - INTEGER |
||||
default 3 |
||||
|
||||
Maximum number of packets that can be retransmitted without |
||||
received an (acceptable) ACK from the destination. If this number |
||||
is reached, a shorter timer will be started. |
||||
|
||||
nf_conntrack_tcp_timeout_close - INTEGER (seconds) |
||||
default 10 |
||||
|
||||
nf_conntrack_tcp_timeout_close_wait - INTEGER (seconds) |
||||
default 60 |
||||
|
||||
nf_conntrack_tcp_timeout_established - INTEGER (seconds) |
||||
default 432000 (5 days) |
||||
|
||||
nf_conntrack_tcp_timeout_fin_wait - INTEGER (seconds) |
||||
default 120 |
||||
|
||||
nf_conntrack_tcp_timeout_last_ack - INTEGER (seconds) |
||||
default 30 |
||||
|
||||
nf_conntrack_tcp_timeout_max_retrans - INTEGER (seconds) |
||||
default 300 |
||||
|
||||
nf_conntrack_tcp_timeout_syn_recv - INTEGER (seconds) |
||||
default 60 |
||||
|
||||
nf_conntrack_tcp_timeout_syn_sent - INTEGER (seconds) |
||||
default 120 |
||||
|
||||
nf_conntrack_tcp_timeout_time_wait - INTEGER (seconds) |
||||
default 120 |
||||
|
||||
nf_conntrack_tcp_timeout_unacknowledged - INTEGER (seconds) |
||||
default 300 |
||||
|
||||
nf_conntrack_timestamp - BOOLEAN |
||||
0 - disabled (default) |
||||
not 0 - enabled |
||||
|
||||
Enable connection tracking flow timestamping. |
||||
|
||||
nf_conntrack_udp_timeout - INTEGER (seconds) |
||||
default 30 |
||||
|
||||
nf_conntrack_udp_timeout_stream2 - INTEGER (seconds) |
||||
default 180 |
||||
|
||||
This extended timeout will be used in case there is an UDP stream |
||||
detected. |
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in new issue