diff options
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/00-INDEX | 2 | ||||
-rw-r--r-- | Documentation/ABI/testing/sysfs-c2port | 88 | ||||
-rw-r--r-- | Documentation/c2port.txt | 90 | ||||
-rw-r--r-- | Documentation/cgroups/freezer-subsystem.txt | 21 | ||||
-rw-r--r-- | Documentation/filesystems/xip.txt | 9 | ||||
-rw-r--r-- | Documentation/hwmon/adt7462 | 67 | ||||
-rw-r--r-- | Documentation/hwmon/lis3lv02d | 49 | ||||
-rw-r--r-- | Documentation/ics932s401 | 31 | ||||
-rw-r--r-- | Documentation/printk-formats.txt | 35 | ||||
-rw-r--r-- | Documentation/w1/masters/omap-hdq | 46 |
10 files changed, 425 insertions, 13 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 2f969e2bece1..2a39aeba1464 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX | |||
@@ -266,6 +266,8 @@ powerpc/ | |||
266 | - directory with info on using Linux with the PowerPC. | 266 | - directory with info on using Linux with the PowerPC. |
267 | preempt-locking.txt | 267 | preempt-locking.txt |
268 | - info on locking under a preemptive kernel. | 268 | - info on locking under a preemptive kernel. |
269 | printk-formats.txt | ||
270 | - how to get printk format specifiers right | ||
269 | prio_tree.txt | 271 | prio_tree.txt |
270 | - info on radix-priority-search-tree use for indexing vmas. | 272 | - info on radix-priority-search-tree use for indexing vmas. |
271 | rbtree.txt | 273 | rbtree.txt |
diff --git a/Documentation/ABI/testing/sysfs-c2port b/Documentation/ABI/testing/sysfs-c2port new file mode 100644 index 000000000000..716cffc457e9 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-c2port | |||
@@ -0,0 +1,88 @@ | |||
1 | What: /sys/class/c2port/ | ||
2 | Date: October 2008 | ||
3 | Contact: Rodolfo Giometti <giometti@linux.it> | ||
4 | Description: | ||
5 | The /sys/class/c2port/ directory will contain files and | ||
6 | directories that will provide a unified interface to | ||
7 | the C2 port interface. | ||
8 | |||
9 | What: /sys/class/c2port/c2portX | ||
10 | Date: October 2008 | ||
11 | Contact: Rodolfo Giometti <giometti@linux.it> | ||
12 | Description: | ||
13 | The /sys/class/c2port/c2portX/ directory is related to X-th | ||
14 | C2 port into the system. Each directory will contain files to | ||
15 | manage and control its C2 port. | ||
16 | |||
17 | What: /sys/class/c2port/c2portX/access | ||
18 | Date: October 2008 | ||
19 | Contact: Rodolfo Giometti <giometti@linux.it> | ||
20 | Description: | ||
21 | The /sys/class/c2port/c2portX/access file enable the access | ||
22 | to the C2 port from the system. No commands can be sent | ||
23 | till this entry is set to 0. | ||
24 | |||
25 | What: /sys/class/c2port/c2portX/dev_id | ||
26 | Date: October 2008 | ||
27 | Contact: Rodolfo Giometti <giometti@linux.it> | ||
28 | Description: | ||
29 | The /sys/class/c2port/c2portX/dev_id file show the device ID | ||
30 | of the connected micro. | ||
31 | |||
32 | What: /sys/class/c2port/c2portX/flash_access | ||
33 | Date: October 2008 | ||
34 | Contact: Rodolfo Giometti <giometti@linux.it> | ||
35 | Description: | ||
36 | The /sys/class/c2port/c2portX/flash_access file enable the | ||
37 | access to the on-board flash of the connected micro. | ||
38 | No commands can be sent till this entry is set to 0. | ||
39 | |||
40 | What: /sys/class/c2port/c2portX/flash_block_size | ||
41 | Date: October 2008 | ||
42 | Contact: Rodolfo Giometti <giometti@linux.it> | ||
43 | Description: | ||
44 | The /sys/class/c2port/c2portX/flash_block_size file show | ||
45 | the on-board flash block size of the connected micro. | ||
46 | |||
47 | What: /sys/class/c2port/c2portX/flash_blocks_num | ||
48 | Date: October 2008 | ||
49 | Contact: Rodolfo Giometti <giometti@linux.it> | ||
50 | Description: | ||
51 | The /sys/class/c2port/c2portX/flash_blocks_num file show | ||
52 | the on-board flash blocks number of the connected micro. | ||
53 | |||
54 | What: /sys/class/c2port/c2portX/flash_data | ||
55 | Date: October 2008 | ||
56 | Contact: Rodolfo Giometti <giometti@linux.it> | ||
57 | Description: | ||
58 | The /sys/class/c2port/c2portX/flash_data file export | ||
59 | the content of the on-board flash of the connected micro. | ||
60 | |||
61 | What: /sys/class/c2port/c2portX/flash_erase | ||
62 | Date: October 2008 | ||
63 | Contact: Rodolfo Giometti <giometti@linux.it> | ||
64 | Description: | ||
65 | The /sys/class/c2port/c2portX/flash_erase file execute | ||
66 | the "erase" command on the on-board flash of the connected | ||
67 | micro. | ||
68 | |||
69 | What: /sys/class/c2port/c2portX/flash_erase | ||
70 | Date: October 2008 | ||
71 | Contact: Rodolfo Giometti <giometti@linux.it> | ||
72 | Description: | ||
73 | The /sys/class/c2port/c2portX/flash_erase file show the | ||
74 | on-board flash size of the connected micro. | ||
75 | |||
76 | What: /sys/class/c2port/c2portX/reset | ||
77 | Date: October 2008 | ||
78 | Contact: Rodolfo Giometti <giometti@linux.it> | ||
79 | Description: | ||
80 | The /sys/class/c2port/c2portX/reset file execute a "reset" | ||
81 | command on the connected micro. | ||
82 | |||
83 | What: /sys/class/c2port/c2portX/rev_id | ||
84 | Date: October 2008 | ||
85 | Contact: Rodolfo Giometti <giometti@linux.it> | ||
86 | Description: | ||
87 | The /sys/class/c2port/c2portX/rev_id file show the revision ID | ||
88 | of the connected micro. | ||
diff --git a/Documentation/c2port.txt b/Documentation/c2port.txt new file mode 100644 index 000000000000..d9bf93ea4398 --- /dev/null +++ b/Documentation/c2port.txt | |||
@@ -0,0 +1,90 @@ | |||
1 | C2 port support | ||
2 | --------------- | ||
3 | |||
4 | (C) Copyright 2007 Rodolfo Giometti <giometti@enneenne.com> | ||
5 | |||
6 | This program is free software; you can redistribute it and/or modify | ||
7 | it under the terms of the GNU General Public License as published by | ||
8 | the Free Software Foundation; either version 2 of the License, or | ||
9 | (at your option) any later version. | ||
10 | |||
11 | This program is distributed in the hope that it will be useful, | ||
12 | but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
13 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
14 | GNU General Public License for more details. | ||
15 | |||
16 | |||
17 | |||
18 | Overview | ||
19 | -------- | ||
20 | |||
21 | This driver implements the support for Linux of Silicon Labs (Silabs) | ||
22 | C2 Interface used for in-system programming of micro controllers. | ||
23 | |||
24 | By using this driver you can reprogram the in-system flash without EC2 | ||
25 | or EC3 debug adapter. This solution is also useful in those systems | ||
26 | where the micro controller is connected via special GPIOs pins. | ||
27 | |||
28 | References | ||
29 | ---------- | ||
30 | |||
31 | The C2 Interface main references are at (http://www.silabs.com) | ||
32 | Silicon Laboratories site], see: | ||
33 | |||
34 | - AN127: FLASH Programming via the C2 Interface at | ||
35 | http://www.silabs.com/public/documents/tpub_doc/anote/Microcontrollers/Small_Form_Factor/en/an127.pdf, and | ||
36 | |||
37 | - C2 Specification at | ||
38 | http://www.silabs.com/public/documents/tpub_doc/spec/Microcontrollers/en/C2spec.pdf, | ||
39 | |||
40 | however it implements a two wire serial communication protocol (bit | ||
41 | banging) designed to enable in-system programming, debugging, and | ||
42 | boundary-scan testing on low pin-count Silicon Labs devices. Currently | ||
43 | this code supports only flash programming but extensions are easy to | ||
44 | add. | ||
45 | |||
46 | Using the driver | ||
47 | ---------------- | ||
48 | |||
49 | Once the driver is loaded you can use sysfs support to get C2port's | ||
50 | info or read/write in-system flash. | ||
51 | |||
52 | # ls /sys/class/c2port/c2port0/ | ||
53 | access flash_block_size flash_erase rev_id | ||
54 | dev_id flash_blocks_num flash_size subsystem/ | ||
55 | flash_access flash_data reset uevent | ||
56 | |||
57 | Initially the C2port access is disabled since you hardware may have | ||
58 | such lines multiplexed with other devices so, to get access to the | ||
59 | C2port, you need the command: | ||
60 | |||
61 | # echo 1 > /sys/class/c2port/c2port0/access | ||
62 | |||
63 | after that you should read the device ID and revision ID of the | ||
64 | connected micro controller: | ||
65 | |||
66 | # cat /sys/class/c2port/c2port0/dev_id | ||
67 | 8 | ||
68 | # cat /sys/class/c2port/c2port0/rev_id | ||
69 | 1 | ||
70 | |||
71 | However, for security reasons, the in-system flash access in not | ||
72 | enabled yet, to do so you need the command: | ||
73 | |||
74 | # echo 1 > /sys/class/c2port/c2port0/flash_access | ||
75 | |||
76 | After that you can read the whole flash: | ||
77 | |||
78 | # cat /sys/class/c2port/c2port0/flash_data > image | ||
79 | |||
80 | erase it: | ||
81 | |||
82 | # echo 1 > /sys/class/c2port/c2port0/flash_erase | ||
83 | |||
84 | and write it: | ||
85 | |||
86 | # cat image > /sys/class/c2port/c2port0/flash_data | ||
87 | |||
88 | after writing you have to reset the device to execute the new code: | ||
89 | |||
90 | # echo 1 > /sys/class/c2port/c2port0/reset | ||
diff --git a/Documentation/cgroups/freezer-subsystem.txt b/Documentation/cgroups/freezer-subsystem.txt index c50ab58b72eb..41f37fea1276 100644 --- a/Documentation/cgroups/freezer-subsystem.txt +++ b/Documentation/cgroups/freezer-subsystem.txt | |||
@@ -1,4 +1,4 @@ | |||
1 | The cgroup freezer is useful to batch job management system which start | 1 | The cgroup freezer is useful to batch job management system which start |
2 | and stop sets of tasks in order to schedule the resources of a machine | 2 | and stop sets of tasks in order to schedule the resources of a machine |
3 | according to the desires of a system administrator. This sort of program | 3 | according to the desires of a system administrator. This sort of program |
4 | is often used on HPC clusters to schedule access to the cluster as a | 4 | is often used on HPC clusters to schedule access to the cluster as a |
@@ -6,7 +6,7 @@ whole. The cgroup freezer uses cgroups to describe the set of tasks to | |||
6 | be started/stopped by the batch job management system. It also provides | 6 | be started/stopped by the batch job management system. It also provides |
7 | a means to start and stop the tasks composing the job. | 7 | a means to start and stop the tasks composing the job. |
8 | 8 | ||
9 | The cgroup freezer will also be useful for checkpointing running groups | 9 | The cgroup freezer will also be useful for checkpointing running groups |
10 | of tasks. The freezer allows the checkpoint code to obtain a consistent | 10 | of tasks. The freezer allows the checkpoint code to obtain a consistent |
11 | image of the tasks by attempting to force the tasks in a cgroup into a | 11 | image of the tasks by attempting to force the tasks in a cgroup into a |
12 | quiescent state. Once the tasks are quiescent another task can | 12 | quiescent state. Once the tasks are quiescent another task can |
@@ -16,7 +16,7 @@ recoverable error occur. This also allows the checkpointed tasks to be | |||
16 | migrated between nodes in a cluster by copying the gathered information | 16 | migrated between nodes in a cluster by copying the gathered information |
17 | to another node and restarting the tasks there. | 17 | to another node and restarting the tasks there. |
18 | 18 | ||
19 | Sequences of SIGSTOP and SIGCONT are not always sufficient for stopping | 19 | Sequences of SIGSTOP and SIGCONT are not always sufficient for stopping |
20 | and resuming tasks in userspace. Both of these signals are observable | 20 | and resuming tasks in userspace. Both of these signals are observable |
21 | from within the tasks we wish to freeze. While SIGSTOP cannot be caught, | 21 | from within the tasks we wish to freeze. While SIGSTOP cannot be caught, |
22 | blocked, or ignored it can be seen by waiting or ptracing parent tasks. | 22 | blocked, or ignored it can be seen by waiting or ptracing parent tasks. |
@@ -37,26 +37,29 @@ demonstrate this problem using nested bash shells: | |||
37 | 37 | ||
38 | <at this point 16990 exits and causes 16644 to exit too> | 38 | <at this point 16990 exits and causes 16644 to exit too> |
39 | 39 | ||
40 | This happens because bash can observe both signals and choose how it | 40 | This happens because bash can observe both signals and choose how it |
41 | responds to them. | 41 | responds to them. |
42 | 42 | ||
43 | Another example of a program which catches and responds to these | 43 | Another example of a program which catches and responds to these |
44 | signals is gdb. In fact any program designed to use ptrace is likely to | 44 | signals is gdb. In fact any program designed to use ptrace is likely to |
45 | have a problem with this method of stopping and resuming tasks. | 45 | have a problem with this method of stopping and resuming tasks. |
46 | 46 | ||
47 | In contrast, the cgroup freezer uses the kernel freezer code to | 47 | In contrast, the cgroup freezer uses the kernel freezer code to |
48 | prevent the freeze/unfreeze cycle from becoming visible to the tasks | 48 | prevent the freeze/unfreeze cycle from becoming visible to the tasks |
49 | being frozen. This allows the bash example above and gdb to run as | 49 | being frozen. This allows the bash example above and gdb to run as |
50 | expected. | 50 | expected. |
51 | 51 | ||
52 | The freezer subsystem in the container filesystem defines a file named | 52 | The freezer subsystem in the container filesystem defines a file named |
53 | freezer.state. Writing "FROZEN" to the state file will freeze all tasks in the | 53 | freezer.state. Writing "FROZEN" to the state file will freeze all tasks in the |
54 | cgroup. Subsequently writing "THAWED" will unfreeze the tasks in the cgroup. | 54 | cgroup. Subsequently writing "THAWED" will unfreeze the tasks in the cgroup. |
55 | Reading will return the current state. | 55 | Reading will return the current state. |
56 | 56 | ||
57 | Note freezer.state doesn't exist in root cgroup, which means root cgroup | ||
58 | is non-freezable. | ||
59 | |||
57 | * Examples of usage : | 60 | * Examples of usage : |
58 | 61 | ||
59 | # mkdir /containers/freezer | 62 | # mkdir /containers |
60 | # mount -t cgroup -ofreezer freezer /containers | 63 | # mount -t cgroup -ofreezer freezer /containers |
61 | # mkdir /containers/0 | 64 | # mkdir /containers/0 |
62 | # echo $some_pid > /containers/0/tasks | 65 | # echo $some_pid > /containers/0/tasks |
@@ -94,6 +97,6 @@ things happens: | |||
94 | the freezer.state file | 97 | the freezer.state file |
95 | 2) Userspace retries the freezing operation by writing "FROZEN" to | 98 | 2) Userspace retries the freezing operation by writing "FROZEN" to |
96 | the freezer.state file (writing "FREEZING" is not legal | 99 | the freezer.state file (writing "FREEZING" is not legal |
97 | and returns EIO) | 100 | and returns EINVAL) |
98 | 3) The tasks that blocked the cgroup from entering the "FROZEN" | 101 | 3) The tasks that blocked the cgroup from entering the "FROZEN" |
99 | state disappear from the cgroup's set of tasks. | 102 | state disappear from the cgroup's set of tasks. |
diff --git a/Documentation/filesystems/xip.txt b/Documentation/filesystems/xip.txt index 3cc4010521a0..0466ee569278 100644 --- a/Documentation/filesystems/xip.txt +++ b/Documentation/filesystems/xip.txt | |||
@@ -39,10 +39,11 @@ The block device operation is optional, these block devices support it as of | |||
39 | today: | 39 | today: |
40 | - dcssblk: s390 dcss block device driver | 40 | - dcssblk: s390 dcss block device driver |
41 | 41 | ||
42 | An address space operation named get_xip_page is used to retrieve reference | 42 | An address space operation named get_xip_mem is used to retrieve references |
43 | to a struct page. To address the target page, a reference to an address_space, | 43 | to a page frame number and a kernel address. To obtain these values a reference |
44 | and a sector number is provided. A 3rd argument indicates whether the | 44 | to an address_space is provided. This function assigns values to the kmem and |
45 | function should allocate blocks if needed. | 45 | pfn parameters. The third argument indicates whether the function should allocate |
46 | blocks if needed. | ||
46 | 47 | ||
47 | This address space operation is mutually exclusive with readpage&writepage that | 48 | This address space operation is mutually exclusive with readpage&writepage that |
48 | do page cache read/write operations. | 49 | do page cache read/write operations. |
diff --git a/Documentation/hwmon/adt7462 b/Documentation/hwmon/adt7462 new file mode 100644 index 000000000000..ec660b328275 --- /dev/null +++ b/Documentation/hwmon/adt7462 | |||
@@ -0,0 +1,67 @@ | |||
1 | Kernel driver adt7462 | ||
2 | ====================== | ||
3 | |||
4 | Supported chips: | ||
5 | * Analog Devices ADT7462 | ||
6 | Prefix: 'adt7462' | ||
7 | Addresses scanned: I2C 0x58, 0x5C | ||
8 | Datasheet: Publicly available at the Analog Devices website | ||
9 | |||
10 | Author: Darrick J. Wong | ||
11 | |||
12 | Description | ||
13 | ----------- | ||
14 | |||
15 | This driver implements support for the Analog Devices ADT7462 chip family. | ||
16 | |||
17 | This chip is a bit of a beast. It has 8 counters for measuring fan speed. It | ||
18 | can also measure 13 voltages or 4 temperatures, or various combinations of the | ||
19 | two. See the chip documentation for more details about the exact set of | ||
20 | configurations. This driver does not allow one to configure the chip; that is | ||
21 | left to the system designer. | ||
22 | |||
23 | A sophisticated control system for the PWM outputs is designed into the ADT7462 | ||
24 | that allows fan speed to be adjusted automatically based on any of the three | ||
25 | temperature sensors. Each PWM output is individually adjustable and | ||
26 | programmable. Once configured, the ADT7462 will adjust the PWM outputs in | ||
27 | response to the measured temperatures without further host intervention. This | ||
28 | feature can also be disabled for manual control of the PWM's. | ||
29 | |||
30 | Each of the measured inputs (voltage, temperature, fan speed) has | ||
31 | corresponding high/low limit values. The ADT7462 will signal an ALARM if | ||
32 | any measured value exceeds either limit. | ||
33 | |||
34 | The ADT7462 samples all inputs continuously. The driver will not read | ||
35 | the registers more often than once every other second. Further, | ||
36 | configuration data is only read once per minute. | ||
37 | |||
38 | Special Features | ||
39 | ---------------- | ||
40 | |||
41 | The ADT7462 have a 10-bit ADC and can therefore measure temperatures | ||
42 | with 0.25 degC resolution. | ||
43 | |||
44 | The Analog Devices datasheet is very detailed and describes a procedure for | ||
45 | determining an optimal configuration for the automatic PWM control. | ||
46 | |||
47 | The driver will report sensor labels when it is able to determine that | ||
48 | information from the configuration registers. | ||
49 | |||
50 | Configuration Notes | ||
51 | ------------------- | ||
52 | |||
53 | Besides standard interfaces driver adds the following: | ||
54 | |||
55 | * PWM Control | ||
56 | |||
57 | * pwm#_auto_point1_pwm and temp#_auto_point1_temp and | ||
58 | * pwm#_auto_point2_pwm and temp#_auto_point2_temp - | ||
59 | |||
60 | point1: Set the pwm speed at a lower temperature bound. | ||
61 | point2: Set the pwm speed at a higher temperature bound. | ||
62 | |||
63 | The ADT7462 will scale the pwm between the lower and higher pwm speed when | ||
64 | the temperature is between the two temperature boundaries. PWM values range | ||
65 | from 0 (off) to 255 (full speed). Fan speed will be set to maximum when the | ||
66 | temperature sensor associated with the PWM control exceeds temp#_max. | ||
67 | |||
diff --git a/Documentation/hwmon/lis3lv02d b/Documentation/hwmon/lis3lv02d new file mode 100644 index 000000000000..65dfb0c0fd67 --- /dev/null +++ b/Documentation/hwmon/lis3lv02d | |||
@@ -0,0 +1,49 @@ | |||
1 | Kernel driver lis3lv02d | ||
2 | ================== | ||
3 | |||
4 | Supported chips: | ||
5 | |||
6 | * STMicroelectronics LIS3LV02DL and LIS3LV02DQ | ||
7 | |||
8 | Author: | ||
9 | Yan Burman <burman.yan@gmail.com> | ||
10 | Eric Piel <eric.piel@tremplin-utc.net> | ||
11 | |||
12 | |||
13 | Description | ||
14 | ----------- | ||
15 | |||
16 | This driver provides support for the accelerometer found in various HP laptops | ||
17 | sporting the feature officially called "HP Mobile Data Protection System 3D" or | ||
18 | "HP 3D DriveGuard". It detect automatically laptops with this sensor. Known models | ||
19 | (for now the HP 2133, nc6420, nc2510, nc8510, nc84x0, nw9440 and nx9420) will | ||
20 | have their axis automatically oriented on standard way (eg: you can directly | ||
21 | play neverball). The accelerometer data is readable via | ||
22 | /sys/devices/platform/lis3lv02d. | ||
23 | |||
24 | Sysfs attributes under /sys/devices/platform/lis3lv02d/: | ||
25 | position - 3D position that the accelerometer reports. Format: "(x,y,z)" | ||
26 | calibrate - read: values (x, y, z) that are used as the base for input class device operation. | ||
27 | write: forces the base to be recalibrated with the current position. | ||
28 | rate - reports the sampling rate of the accelerometer device in HZ | ||
29 | |||
30 | This driver also provides an absolute input class device, allowing | ||
31 | the laptop to act as a pinball machine-esque joystick. | ||
32 | |||
33 | Axes orientation | ||
34 | ---------------- | ||
35 | |||
36 | For better compatibility between the various laptops. The values reported by | ||
37 | the accelerometer are converted into a "standard" organisation of the axes | ||
38 | (aka "can play neverball out of the box"): | ||
39 | * When the laptop is horizontal the position reported is about 0 for X and Y | ||
40 | and a positive value for Z | ||
41 | * If the left side is elevated, X increases (becomes positive) | ||
42 | * If the front side (where the touchpad is) is elevated, Y decreases (becomes negative) | ||
43 | * If the laptop is put upside-down, Z becomes negative | ||
44 | |||
45 | If your laptop model is not recognized (cf "dmesg"), you can send an email to the | ||
46 | authors to add it to the database. When reporting a new laptop, please include | ||
47 | the output of "dmidecode" plus the value of /sys/devices/platform/lis3lv02d/position | ||
48 | in these four cases. | ||
49 | |||
diff --git a/Documentation/ics932s401 b/Documentation/ics932s401 new file mode 100644 index 000000000000..07a739f406d8 --- /dev/null +++ b/Documentation/ics932s401 | |||
@@ -0,0 +1,31 @@ | |||
1 | Kernel driver ics932s401 | ||
2 | ====================== | ||
3 | |||
4 | Supported chips: | ||
5 | * IDT ICS932S401 | ||
6 | Prefix: 'ics932s401' | ||
7 | Addresses scanned: I2C 0x69 | ||
8 | Datasheet: Publically available at the IDT website | ||
9 | |||
10 | Author: Darrick J. Wong | ||
11 | |||
12 | Description | ||
13 | ----------- | ||
14 | |||
15 | This driver implements support for the IDT ICS932S401 chip family. | ||
16 | |||
17 | This chip has 4 clock outputs--a base clock for the CPU (which is likely | ||
18 | multiplied to get the real CPU clock), a system clock, a PCI clock, a USB | ||
19 | clock, and a reference clock. The driver reports selected and actual | ||
20 | frequency. If spread spectrum mode is enabled, the driver also reports by what | ||
21 | percent the clock signal is being spread, which should be between 0 and -0.5%. | ||
22 | All frequencies are reported in KHz. | ||
23 | |||
24 | The ICS932S401 monitors all inputs continuously. The driver will not read | ||
25 | the registers more often than once every other second. | ||
26 | |||
27 | Special Features | ||
28 | ---------------- | ||
29 | |||
30 | The clocks could be reprogrammed to increase system speed. I will not help you | ||
31 | do this, as you risk damaging your system! | ||
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt new file mode 100644 index 000000000000..1b5a5ddbc3ef --- /dev/null +++ b/Documentation/printk-formats.txt | |||
@@ -0,0 +1,35 @@ | |||
1 | If variable is of Type, use printk format specifier: | ||
2 | --------------------------------------------------------- | ||
3 | int %d or %x | ||
4 | unsigned int %u or %x | ||
5 | long %ld or %lx | ||
6 | unsigned long %lu or %lx | ||
7 | long long %lld or %llx | ||
8 | unsigned long long %llu or %llx | ||
9 | size_t %zu or %zx | ||
10 | ssize_t %zd or %zx | ||
11 | |||
12 | Raw pointer value SHOULD be printed with %p. | ||
13 | |||
14 | u64 SHOULD be printed with %llu/%llx, (unsigned long long): | ||
15 | |||
16 | printk("%llu", (unsigned long long)u64_var); | ||
17 | |||
18 | s64 SHOULD be printed with %lld/%llx, (long long): | ||
19 | |||
20 | printk("%lld", (long long)s64_var); | ||
21 | |||
22 | If <type> is dependent on a config option for its size (e.g., sector_t, | ||
23 | blkcnt_t, phys_addr_t, resource_size_t) or is architecture-dependent | ||
24 | for its size (e.g., tcflag_t), use a format specifier of its largest | ||
25 | possible type and explicitly cast to it. Example: | ||
26 | |||
27 | printk("test: sector number/total blocks: %llu/%llu\n", | ||
28 | (unsigned long long)sector, (unsigned long long)blockcount); | ||
29 | |||
30 | Reminder: sizeof() result is of type size_t. | ||
31 | |||
32 | Thank you for your cooperation and attention. | ||
33 | |||
34 | |||
35 | By Randy Dunlap <rdunlap@xenotime.net> | ||
diff --git a/Documentation/w1/masters/omap-hdq b/Documentation/w1/masters/omap-hdq new file mode 100644 index 000000000000..ca722e09b6a1 --- /dev/null +++ b/Documentation/w1/masters/omap-hdq | |||
@@ -0,0 +1,46 @@ | |||
1 | Kernel driver for omap HDQ/1-wire module. | ||
2 | ======================================== | ||
3 | |||
4 | Supported chips: | ||
5 | ================ | ||
6 | HDQ/1-wire controller on the TI OMAP 2430/3430 platforms. | ||
7 | |||
8 | A useful link about HDQ basics: | ||
9 | =============================== | ||
10 | http://focus.ti.com/lit/an/slua408/slua408.pdf | ||
11 | |||
12 | Description: | ||
13 | ============ | ||
14 | The HDQ/1-Wire module of TI OMAP2430/3430 platforms implement the hardware | ||
15 | protocol of the master functions of the Benchmark HDQ and the Dallas | ||
16 | Semiconductor 1-Wire protocols. These protocols use a single wire for | ||
17 | communication between the master (HDQ/1-Wire controller) and the slave | ||
18 | (HDQ/1-Wire external compliant device). | ||
19 | |||
20 | A typical application of the HDQ/1-Wire module is the communication with battery | ||
21 | monitor (gas gauge) integrated circuits. | ||
22 | |||
23 | The controller supports operation in both HDQ and 1-wire mode. The essential | ||
24 | difference between the HDQ and 1-wire mode is how the slave device responds to | ||
25 | initialization pulse.In HDQ mode, the firmware does not require the host to | ||
26 | create an initialization pulse to the slave.However, the slave can be reset by | ||
27 | using an initialization pulse (also referred to as a break pulse).The slave | ||
28 | does not respond with a presence pulse as it does in the 1-Wire protocol. | ||
29 | |||
30 | Remarks: | ||
31 | ======== | ||
32 | The driver (drivers/w1/masters/omap_hdq.c) supports the HDQ mode of the | ||
33 | controller. In this mode, as we can not read the ID which obeys the W1 | ||
34 | spec(family:id:crc), a module parameter can be passed to the driver which will | ||
35 | be used to calculate the CRC and pass back an appropriate slave ID to the W1 | ||
36 | core. | ||
37 | |||
38 | By default the master driver and the BQ slave i/f | ||
39 | driver(drivers/w1/slaves/w1_bq27000.c) sets the ID to 1. | ||
40 | Please note to load both the modules with a different ID if required, but note | ||
41 | that the ID used should be same for both master and slave driver loading. | ||
42 | |||
43 | e.g: | ||
44 | insmod omap_hdq.ko W1_ID=2 | ||
45 | inamod w1_bq27000.ko F_ID=2 | ||
46 | |||