Skip to content

Commit

Permalink
Merge branch 'viro'
Browse files Browse the repository at this point in the history
  • Loading branch information
jgarzik committed Feb 9, 2006
2 parents 5d1769a + 2746b86 commit 70c07e0
Show file tree
Hide file tree
Showing 342 changed files with 4,981 additions and 2,179 deletions.
9 changes: 9 additions & 0 deletions Documentation/feature-removal-schedule.txt
Original file line number Diff line number Diff line change
Expand Up @@ -169,3 +169,12 @@ What: pci_module_init(driver)
When: January 2007
Why: Is replaced by pci_register_driver(pci_driver).
Who: Richard Knutsson <[email protected]> and Greg Kroah-Hartman <[email protected]>

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

What: I2C interface of the it87 driver
When: January 2007
Why: The ISA interface is faster and should be always available. The I2C
probing is also known to cause trouble in at least one case (see
bug #5889.)
Who: Jean Delvare <[email protected]>
105 changes: 105 additions & 0 deletions Documentation/hwmon/f71805f
Original file line number Diff line number Diff line change
@@ -0,0 +1,105 @@
Kernel driver f71805f
=====================

Supported chips:
* Fintek F71805F/FG
Prefix: 'f71805f'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Provided by Fintek on request

Author: Jean Delvare <[email protected]>

Thanks to Denis Kieft from Barracuda Networks for the donation of a
test system (custom Jetway K8M8MS motherboard, with CPU and RAM) and
for providing initial documentation.

Thanks to Kris Chen from Fintek for answering technical questions and
providing additional documentation.

Thanks to Chris Lin from Jetway for providing wiring schematics and
anwsering technical questions.


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

The Fintek F71805F/FG Super I/O chip includes complete hardware monitoring
capabilities. It can monitor up to 9 voltages (counting its own power
source), 3 fans and 3 temperature sensors.

This chip also has fan controlling features, using either DC or PWM, in
three different modes (one manual, two automatic). The driver doesn't
support these features yet.

The driver assumes that no more than one chip is present, which seems
reasonable.


Voltage Monitoring
------------------

Voltages are sampled by an 8-bit ADC with a LSB of 8 mV. The supported
range is thus from 0 to 2.040 V. Voltage values outside of this range
need external resistors. An exception is in0, which is used to monitor
the chip's own power source (+3.3V), and is divided internally by a
factor 2.

The two LSB of the voltage limit registers are not used (always 0), so
you can only set the limits in steps of 32 mV (before scaling).

The wirings and resistor values suggested by Fintek are as follow:

pin expected
name use R1 R2 divider raw val.

in0 VCC VCC3.3V int. int. 2.00 1.65 V
in1 VIN1 VTT1.2V 10K - 1.00 1.20 V
in2 VIN2 VRAM 100K 100K 2.00 ~1.25 V (1)
in3 VIN3 VCHIPSET 47K 100K 1.47 2.24 V (2)
in4 VIN4 VCC5V 200K 47K 5.25 0.95 V
in5 VIN5 +12V 200K 20K 11.00 1.05 V
in6 VIN6 VCC1.5V 10K - 1.00 1.50 V
in7 VIN7 VCORE 10K - 1.00 ~1.40 V (1)
in8 VIN8 VSB5V 200K 47K 1.00 0.95 V

(1) Depends on your hardware setup.
(2) Obviously not correct, swapping R1 and R2 would make more sense.

These values can be used as hints at best, as motherboard manufacturers
are free to use a completely different setup. As a matter of fact, the
Jetway K8M8MS uses a significantly different setup. You will have to
find out documentation about your own motherboard, and edit sensors.conf
accordingly.

Each voltage measured has associated low and high limits, each of which
triggers an alarm when crossed.


Fan Monitoring
--------------

Fan rotation speeds are reported as 12-bit values from a gated clock
signal. Speeds down to 366 RPM can be measured. There is no theoretical
high limit, but values over 6000 RPM seem to cause problem. The effective
resolution is much lower than you would expect, the step between different
register values being 10 rather than 1.

The chip assumes 2 pulse-per-revolution fans.

An alarm is triggered if the rotation speed drops below a programmable
limit or is too low to be measured.


Temperature Monitoring
----------------------

Temperatures are reported in degrees Celsius. Each temperature measured
has a high limit, those crossing triggers an alarm. There is an associated
hysteresis value, below which the temperature has to drop before the
alarm is cleared.

All temperature channels are external, there is no embedded temperature
sensor. Each channel can be used for connecting either a thermal diode
or a thermistor. The driver reports the currently selected mode, but
doesn't allow changing it. In theory, the BIOS should have configured
everything properly.
2 changes: 1 addition & 1 deletion Documentation/hwmon/it87
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ Supported chips:
http://www.ite.com.tw/
* IT8712F
Prefix: 'it8712'
Addresses scanned: I2C 0x28 - 0x2f
Addresses scanned: I2C 0x2d
from Super I/O config space (8 I/O ports)
Datasheet: Publicly available at the ITE website
http://www.ite.com.tw/
Expand Down
18 changes: 17 additions & 1 deletion Documentation/hwmon/sysfs-interface
Original file line number Diff line number Diff line change
Expand Up @@ -179,11 +179,12 @@ temp[1-*]_auto_point[1-*]_temp_hyst
****************

temp[1-3]_type Sensor type selection.
Integers 1, 2, 3 or thermistor Beta value (3435)
Integers 1 to 4 or thermistor Beta value (typically 3435)
Read/Write.
1: PII/Celeron Diode
2: 3904 transistor
3: thermal diode
4: thermistor (default/unknown Beta)
Not all types are supported by all chips

temp[1-4]_max Temperature max value.
Expand Down Expand Up @@ -261,6 +262,21 @@ alarms Alarm bitmask.
of individual bits.
Bits are defined in kernel/include/sensors.h.

alarms_in Alarm bitmask relative to in (voltage) channels
Read only
A '1' bit means an alarm, LSB corresponds to in0 and so on
Prefered to 'alarms' for newer chips

alarms_fan Alarm bitmask relative to fan channels
Read only
A '1' bit means an alarm, LSB corresponds to fan1 and so on
Prefered to 'alarms' for newer chips

alarms_temp Alarm bitmask relative to temp (temperature) channels
Read only
A '1' bit means an alarm, LSB corresponds to temp1 and so on
Prefered to 'alarms' for newer chips

beep_enable Beep/interrupt enable
0 to disable.
1 to enable.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ Supported adapters:
Any combination of these host bridges:
645, 645DX (aka 646), 648, 650, 651, 655, 735, 745, 746
and these south bridges:
961, 962, 963(L)
961, 962, 963(L)

Author: Mark M. Hoffman <[email protected]>

Expand All @@ -29,7 +29,7 @@ The command "lspci" as root should produce something like these lines:

or perhaps this...

00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
00:00.0 Host bridge: Silicon Integrated Systems [SiS]: Unknown device 0645
00:02.0 ISA bridge: Silicon Integrated Systems [SiS]: Unknown device 0961
00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016

Expand Down
8 changes: 8 additions & 0 deletions Documentation/powerpc/booting-without-of.txt
Original file line number Diff line number Diff line change
Expand Up @@ -880,6 +880,10 @@ address which can extend beyond that limit.
- device_type : Should be "soc"
- ranges : Should be defined as specified in 1) to describe the
translation of SOC addresses for memory mapped SOC registers.
- bus-frequency: Contains the bus frequency for the SOC node.
Typically, the value of this field is filled in by the boot
loader.


Recommended properties:

Expand Down Expand Up @@ -919,6 +923,7 @@ SOC.
device_type = "soc";
ranges = <00000000 e0000000 00100000>
reg = <e0000000 00003000>;
bus-frequency = <0>;
}


Expand Down Expand Up @@ -1170,6 +1175,8 @@ platforms are moved over to use the flattened-device-tree model.

mdio@24520 {
reg = <24520 20>;
device_type = "mdio";
compatible = "gianfar";

ethernet-phy@0 {
......
Expand Down Expand Up @@ -1317,6 +1324,7 @@ not necessary as they are usually the same as the root node.
device_type = "soc";
ranges = <00000000 e0000000 00100000>
reg = <e0000000 00003000>;
bus-frequency = <0>;

mdio@24520 {
reg = <24520 20>;
Expand Down
23 changes: 17 additions & 6 deletions Documentation/spi/butterfly
Original file line number Diff line number Diff line change
Expand Up @@ -12,13 +12,20 @@ You can make this adapter from an old printer cable and solder things
directly to the Butterfly. Or (if you have the parts and skills) you
can come up with something fancier, providing ciruit protection to the
Butterfly and the printer port, or with a better power supply than two
signal pins from the printer port.
signal pins from the printer port. Or for that matter, you can use
similar cables to talk to many AVR boards, even a breadboard.

This is more powerful than "ISP programming" cables since it lets kernel
SPI protocol drivers interact with the AVR, and could even let the AVR
issue interrupts to them. Later, your protocol driver should work
easily with a "real SPI controller", instead of this bitbanger.


The first cable connections will hook Linux up to one SPI bus, with the
AVR and a DataFlash chip; and to the AVR reset line. This is all you
need to reflash the firmware, and the pins are the standard Atmel "ISP"
connector pins (used also on non-Butterfly AVR boards).
connector pins (used also on non-Butterfly AVR boards). On the parport
side this is like "sp12" programming cables.

Signal Butterfly Parport (DB-25)
------ --------- ---------------
Expand All @@ -40,10 +47,14 @@ by clearing PORTB.[0-3]); (b) configure the mtd_dataflash driver; and
SELECT = J400.PB0/nSS = pin 17/C3,nSELECT
GND = J400.GND = pin 24/GND

The "USI" controller, using J405, can be used for a second SPI bus. That
would let you talk to the AVR over SPI, running firmware that makes it act
as an SPI slave, while letting either Linux or the AVR use the DataFlash.
There are plenty of spare parport pins to wire this one up, such as:
Or you could flash firmware making the AVR into an SPI slave (keeping the
DataFlash in reset) and tweak the spi_butterfly driver to make it bind to
the driver for your custom SPI-based protocol.

The "USI" controller, using J405, can also be used for a second SPI bus.
That would let you talk to the AVR using custom SPI-with-USI firmware,
while letting either Linux or the AVR use the DataFlash. There are plenty
of spare parport pins to wire this one up, such as:

Signal Butterfly Parport (DB-25)
------ --------- ---------------
Expand Down
Loading

0 comments on commit 70c07e0

Please sign in to comment.