From 58687acba59266735adb8ccd9b5b9aa2c7cd205b Mon Sep 17 00:00:00 2001 From: Don Zickus Date: Fri, 7 May 2010 17:11:44 -0400 Subject: lockup_detector: Combine nmi_watchdog and softlockup detector The new nmi_watchdog (which uses the perf event subsystem) is very similar in structure to the softlockup detector. Using Ingo's suggestion, I combined the two functionalities into one file: kernel/watchdog.c. Now both the nmi_watchdog (or hardlockup detector) and softlockup detector sit on top of the perf event subsystem, which is run every 60 seconds or so to see if there are any lockups. To detect hardlockups, cpus not responding to interrupts, I implemented an hrtimer that runs 5 times for every perf event overflow event. If that stops counting on a cpu, then the cpu is most likely in trouble. To detect softlockups, tasks not yielding to the scheduler, I used the previous kthread idea that now gets kicked every time the hrtimer fires. If the kthread isn't being scheduled neither is anyone else and the warning is printed to the console. I tested this on x86_64 and both the softlockup and hardlockup paths work. V2: - cleaned up the Kconfig and softlockup combination - surrounded hardlockup cases with #ifdef CONFIG_PERF_EVENTS_NMI - seperated out the softlockup case from perf event subsystem - re-arranged the enabling/disabling nmi watchdog from proc space - added cpumasks for hardlockup failure cases - removed fallback to soft events if no PMU exists for hard events V3: - comment cleanups - drop support for older softlockup code - per_cpu cleanups - completely remove software clock base hardlockup detector - use per_cpu masking on hard/soft lockup detection - #ifdef cleanups - rename config option NMI_WATCHDOG to LOCKUP_DETECTOR - documentation additions V4: - documentation fixes - convert per_cpu to __get_cpu_var - powerpc compile fixes V5: - split apart warn flags for hard and soft lockups TODO: - figure out how to make an arch-agnostic clock2cycles call (if possible) to feed into perf events as a sample period [fweisbec: merged conflict patch] Signed-off-by: Don Zickus Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Cyrill Gorcunov Cc: Eric Paris Cc: Randy Dunlap LKML-Reference: <1273266711-18706-2-git-send-email-dzickus@redhat.com> Signed-off-by: Frederic Weisbecker --- Documentation/kernel-parameters.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 839b21b..dfe8d1c 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1777,6 +1777,8 @@ and is between 256 and 4096 characters. It is defined in the file nousb [USB] Disable the USB subsystem + nowatchdog [KNL] Disable the lockup detector. + nowb [ARM] nox2apic [X86-64,APIC] Do not enable x2APIC mode. -- cgit v1.1 From 3f8dc2362fd43a0adee2f6f05bf1ac4d619675b6 Mon Sep 17 00:00:00 2001 From: Ian Campbell Date: Wed, 26 May 2010 00:09:41 +0000 Subject: arp_notify: document that a gratuitous ARP request is sent when this option is enabled This option causes a gratuitous ARP request, not a reply as the documentation currently suggests. Signed-off-by: Ian Campbell Cc: Stephen Hemminger Cc: Jeremy Fitzhardinge Cc: David S. Miller Cc: netdev@vger.kernel.org Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index d0536b5..f350c69 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -903,7 +903,7 @@ arp_ignore - INTEGER arp_notify - BOOLEAN Define mode for notification of address and device changes. 0 - (default): do nothing - 1 - Generate gratuitous arp replies when device is brought up + 1 - Generate gratuitous arp requests when device is brought up or hardware address changes. arp_accept - BOOLEAN -- cgit v1.1 From 33ccbc320fc38094128c68b2ee0b305884965bd4 Mon Sep 17 00:00:00 2001 From: Stefan Achatz Date: Wed, 26 May 2010 20:52:43 +0200 Subject: HID: roccat: change kone_driver_version to kone_abi_version Renamed the sysfs attribute kone_driver_version to kone_abi_version and simplified returned data to integer. Signed-off-by: Stefan Achatz Signed-off-by: Jiri Kosina --- Documentation/ABI/testing/sysfs-driver-hid-roccat-kone | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone index 88340a2..36bfa23 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone @@ -33,11 +33,10 @@ Description: When read, this file returns the raw integer version number of the left. E.g. a returned value of 138 means 1.38 This file is readonly. -What: /sys/bus/usb/devices/-:./kone_driver_version -Date: March 2010 +What: /sys/bus/usb/devices/-:./kone_abi_version +Date: May 2010 Contact: Stefan Achatz -Description: When read, this file returns the driver version. - The format of the string is "v..". +Description: When read, this file returns the abi version as an integer value. This attribute is used by the userland tools to find the sysfs- paths of installed kone-mice and determine the capabilites of the driver. Versions of this driver for old kernels replace -- cgit v1.1 From 614f60fa9d73a9e8fdff3df83381907fea7c5649 Mon Sep 17 00:00:00 2001 From: Scott McMillan Date: Wed, 2 Jun 2010 05:53:56 -0700 Subject: packet_mmap: expose hw packet timestamps to network packet capture utilities This patch adds a setting, PACKET_TIMESTAMP, to specify the packet timestamp source that is exported to capture utilities like tcpdump by packet_mmap. PACKET_TIMESTAMP accepts the same integer bit field as SO_TIMESTAMPING. However, only the SOF_TIMESTAMPING_SYS_HARDWARE and SOF_TIMESTAMPING_RAW_HARDWARE values are currently recognized by PACKET_TIMESTAMP. SOF_TIMESTAMPING_SYS_HARDWARE takes precedence over SOF_TIMESTAMPING_RAW_HARDWARE if both bits are set. If PACKET_TIMESTAMP is not set, a software timestamp generated inside the networking stack is used (the behavior before this setting was added). Signed-off-by: Scott McMillan Signed-off-by: David S. Miller --- Documentation/networking/packet_mmap.txt | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt index 98f71a5..2546aa4 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt @@ -493,6 +493,32 @@ The user can also use poll() to check if a buffer is available: pfd.events = POLLOUT; retval = poll(&pfd, 1, timeout); +------------------------------------------------------------------------------- ++ PACKET_TIMESTAMP +------------------------------------------------------------------------------- + +The PACKET_TIMESTAMP setting determines the source of the timestamp in +the packet meta information. If your NIC is capable of timestamping +packets in hardware, you can request those hardware timestamps to used. +Note: you may need to enable the generation of hardware timestamps with +SIOCSHWTSTAMP. + +PACKET_TIMESTAMP accepts the same integer bit field as +SO_TIMESTAMPING. However, only the SOF_TIMESTAMPING_SYS_HARDWARE +and SOF_TIMESTAMPING_RAW_HARDWARE values are recognized by +PACKET_TIMESTAMP. SOF_TIMESTAMPING_SYS_HARDWARE takes precedence over +SOF_TIMESTAMPING_RAW_HARDWARE if both bits are set. + + int req = 0; + req |= SOF_TIMESTAMPING_SYS_HARDWARE; + setsockopt(fd, SOL_PACKET, PACKET_TIMESTAMP, (void *) &req, sizeof(req)) + +If PACKET_TIMESTAMP is not set, a software timestamp generated inside +the networking stack is used (the behavior before this setting was added). + +See include/linux/net_tstamp.h and Documentation/networking/timestamping +for more information on hardware timestamps. + -------------------------------------------------------------------------------- + THANKS -------------------------------------------------------------------------------- -- cgit v1.1 From 8cbccbe76168a0c627d2274e4a322116804db30f Mon Sep 17 00:00:00 2001 From: Wu Fengguang Date: Wed, 2 Jun 2010 16:02:44 +0000 Subject: ipconfig: document DHCP hostname and DNS record Now it's possible to update the DNS record for $HOST_NAME with ip=::::$HOST_NAME::dhcp CC: Andi Kleen Signed-off-by: Wu Fengguang Signed-off-by: David S. Miller --- Documentation/filesystems/nfs/nfsroot.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/nfs/nfsroot.txt b/Documentation/filesystems/nfs/nfsroot.txt index 3ba0b94..f2430a7 100644 --- a/Documentation/filesystems/nfs/nfsroot.txt +++ b/Documentation/filesystems/nfs/nfsroot.txt @@ -124,6 +124,8 @@ ip=:::::: Name of the client. May be supplied by autoconfiguration, but its absence will not trigger autoconfiguration. + If specified and DHCP is used, the user provided hostname will + be carried in the DHCP request to hopefully update DNS record. Default: Client IP address is used in ASCII notation. -- cgit v1.1 From bb1d912323d5dd50e1079e389f4e964be14f0ae3 Mon Sep 17 00:00:00 2001 From: Andy Gospodarek Date: Wed, 2 Jun 2010 08:40:18 +0000 Subject: bonding: allow user-controlled output slave selection v2: changed bonding module version, modified to apply on top of changes from previous patch in series, and updated documentation to elaborate on multiqueue awareness that now exists in bonding driver. This patch give the user the ability to control the output slave for round-robin and active-backup bonding. Similar functionality was discussed in the past, but Jay Vosburgh indicated he would rather see a feature like this added to existing modes rather than creating a completely new mode. Jay's thoughts as well as Neil's input surrounding some of the issues with the first implementation pushed us toward a design that relied on the queue_mapping rather than skb marks. Round-robin and active-backup modes were chosen as the first users of this slave selection as they seemed like the most logical choices when considering a multi-switch environment. Round-robin mode works without any modification, but active-backup does require inclusion of the first patch in this series and setting the 'all_slaves_active' flag. This will allow reception of unicast traffic on any of the backup interfaces. This was tested with IPv4-based filters as well as VLAN-based filters with good results. More information as well as a configuration example is available in the patch to Documentation/networking/bonding.txt. Signed-off-by: Andy Gospodarek Signed-off-by: Neil Horman Signed-off-by: David S. Miller --- Documentation/networking/bonding.txt | 84 +++++++++++++++++++++++++++++++++++- 1 file changed, 82 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 61f516b..d091478 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -49,6 +49,7 @@ Table of Contents 3.3 Configuring Bonding Manually with Ifenslave 3.3.1 Configuring Multiple Bonds Manually 3.4 Configuring Bonding Manually via Sysfs +3.5 Overriding Configuration for Special Cases 4. Querying Bonding Configuration 4.1 Bonding Configuration @@ -1318,8 +1319,87 @@ echo 2000 > /sys/class/net/bond1/bonding/arp_interval echo +eth2 > /sys/class/net/bond1/bonding/slaves echo +eth3 > /sys/class/net/bond1/bonding/slaves - -4. Querying Bonding Configuration +3.5 Overriding Configuration for Special Cases +---------------------------------------------- +When using the bonding driver, the physical port which transmits a frame is +typically selected by the bonding driver, and is not relevant to the user or +system administrator. The output port is simply selected using the policies of +the selected bonding mode. On occasion however, it is helpful to direct certain +classes of traffic to certain physical interfaces on output to implement +slightly more complex policies. For example, to reach a web server over a +bonded interface in which eth0 connects to a private network, while eth1 +connects via a public network, it may be desirous to bias the bond to send said +traffic over eth0 first, using eth1 only as a fall back, while all other traffic +can safely be sent over either interface. Such configurations may be achieved +using the traffic control utilities inherent in linux. + +By default the bonding driver is multiqueue aware and 16 queues are created +when the driver initializes (see Documentation/networking/multiqueue.txt +for details). If more or less queues are desired the module parameter +tx_queues can be used to change this value. There is no sysfs parameter +available as the allocation is done at module init time. + +The output of the file /proc/net/bonding/bondX has changed so the output Queue +ID is now printed for each slave: + +Bonding Mode: fault-tolerance (active-backup) +Primary Slave: None +Currently Active Slave: eth0 +MII Status: up +MII Polling Interval (ms): 0 +Up Delay (ms): 0 +Down Delay (ms): 0 + +Slave Interface: eth0 +MII Status: up +Link Failure Count: 0 +Permanent HW addr: 00:1a:a0:12:8f:cb +Slave queue ID: 0 + +Slave Interface: eth1 +MII Status: up +Link Failure Count: 0 +Permanent HW addr: 00:1a:a0:12:8f:cc +Slave queue ID: 2 + +The queue_id for a slave can be set using the command: + +# echo "eth1:2" > /sys/class/net/bond0/bonding/queue_id + +Any interface that needs a queue_id set should set it with multiple calls +like the one above until proper priorities are set for all interfaces. On +distributions that allow configuration via initscripts, multiple 'queue_id' +arguments can be added to BONDING_OPTS to set all needed slave queues. + +These queue id's can be used in conjunction with the tc utility to configure +a multiqueue qdisc and filters to bias certain traffic to transmit on certain +slave devices. For instance, say we wanted, in the above configuration to +force all traffic bound to 192.168.1.100 to use eth1 in the bond as its output +device. The following commands would accomplish this: + +# tc qdisc add dev bond0 handle 1 root multiq + +# tc filter add dev bond0 protocol ip parent 1: prio 1 u32 match ip dst \ + 192.168.1.100 action skbedit queue_mapping 2 + +These commands tell the kernel to attach a multiqueue queue discipline to the +bond0 interface and filter traffic enqueued to it, such that packets with a dst +ip of 192.168.1.100 have their output queue mapping value overwritten to 2. +This value is then passed into the driver, causing the normal output path +selection policy to be overridden, selecting instead qid 2, which maps to eth1. + +Note that qid values begin at 1. Qid 0 is reserved to initiate to the driver +that normal output policy selection should take place. One benefit to simply +leaving the qid for a slave to 0 is the multiqueue awareness in the bonding +driver that is now present. This awareness allows tc filters to be placed on +slave devices as well as bond devices and the bonding driver will simply act as +a pass-through for selecting output queues on the slave device rather than +output port selection. + +This feature first appeared in bonding driver version 3.7.0 and support for +output slave selection was limited to round-robin and active-backup modes. + +4 Querying Bonding Configuration ================================= 4.1 Bonding Configuration -- cgit v1.1 From c20cbe46bd5c13444e30cefc997704514dc74cc5 Mon Sep 17 00:00:00 2001 From: Jim Cromie Date: Thu, 3 Jun 2010 08:40:55 -0600 Subject: variable name fix to Documentation/rt-mutex-design.txt Signed-off-by: Jim Cromie Signed-off-by: Jiri Kosina --- Documentation/rt-mutex-design.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/rt-mutex-design.txt b/Documentation/rt-mutex-design.txt index 8df0b78..33ed800 100644 --- a/Documentation/rt-mutex-design.txt +++ b/Documentation/rt-mutex-design.txt @@ -364,7 +364,7 @@ process this is rather easy to know what needs to be adjusted. The functions implementing the task adjustments are rt_mutex_adjust_prio, __rt_mutex_adjust_prio (same as the former, but expects the task pi_lock -to already be taken), rt_mutex_get_prio, and rt_mutex_setprio. +to already be taken), rt_mutex_getprio, and rt_mutex_setprio. rt_mutex_getprio and rt_mutex_setprio are only used in __rt_mutex_adjust_prio. -- cgit v1.1 From bcfde3347cadfc8967e9481b5a9ceae16ef95e38 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Mon, 7 Jun 2010 17:10:38 -0700 Subject: sound: move driver parameters to their own files Move sound (OSS & ALSA) kernel parameters to their own files. Signed-off-by: Randy Dunlap Signed-off-by: Takashi Iwai --- Documentation/kernel-parameters.txt | 167 +-------------------------- Documentation/sound/alsa/alsa-parameters.txt | 135 ++++++++++++++++++++++ Documentation/sound/oss/oss-parameters.txt | 51 ++++++++ 3 files changed, 192 insertions(+), 161 deletions(-) create mode 100644 Documentation/sound/alsa/alsa-parameters.txt create mode 100644 Documentation/sound/oss/oss-parameters.txt (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 1808f11..8d443e7 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -280,19 +280,12 @@ and is between 256 and 4096 characters. It is defined in the file no: ACPI OperationRegions are not marked as reserved, no further checks are performed. - ad1848= [HW,OSS] - Format: ,,,, - add_efi_memmap [EFI; X86] Include EFI memory map in kernel's map of available physical RAM. advansys= [HW,SCSI] See header of drivers/scsi/advansys.c. - aedsp16= [HW,OSS] Audio Excel DSP 16 - Format: ,,,,, - See also header of sound/oss/aedsp16.c. - agp= [AGP] { off | try_unsupported } off: disable AGP support @@ -311,6 +304,9 @@ and is between 256 and 4096 characters. It is defined in the file aic79xx= [HW,SCSI] See Documentation/scsi/aic79xx.txt. + ALSA [HW,ALSA] + See Documentation/sound/alsa/alsa-parameters.txt + alignment= [KNL,ARM] Allow the default userspace alignment fault handler behaviour to be specified. Bit 0 enables warnings, @@ -655,8 +651,6 @@ and is between 256 and 4096 characters. It is defined in the file Disable PIN 1 of APIC timer Can be useful to work around chipset bugs. - dmasound= [HW,OSS] Sound subsystem buffers - dma_debug=off If the kernel is compiled with DMA_API_DEBUG support, this option disables the debugging code at boot. @@ -1523,9 +1517,6 @@ and is between 256 and 4096 characters. It is defined in the file that the amount of memory usable for all allocations is not too small. - mpu401= [HW,OSS] - Format: , - MTD_Partition= [MTD] Format: ,,, @@ -1849,9 +1840,6 @@ and is between 256 and 4096 characters. It is defined in the file For example, to override I2C bus2: omap_mux=i2c2_scl.i2c2_scl=0x100,i2c2_sda.i2c2_sda=0x100 - opl3= [HW,OSS] - Format: - oprofile.timer= [HW] Use timer interrupt instead of performance counters @@ -1863,6 +1851,9 @@ and is between 256 and 4096 characters. It is defined in the file perfmon on Intel CPUs instead of the CPU specific event set. + OSS [HW,OSS] + See Documentation/sound/oss/oss-parameters.txt + osst= [HW,SCSI] SCSI Tape Driver Format: , See also Documentation/scsi/st.txt. @@ -1899,9 +1890,6 @@ and is between 256 and 4096 characters. It is defined in the file Currently this function knows 686a and 8231 chips. Format: [spp|ps2|epp|ecp|ecpepp] - pas2= [HW,OSS] Format: - ,,,,,,, - pas16= [HW,SCSI] See header of drivers/scsi/pas16.c. @@ -2169,10 +2157,6 @@ and is between 256 and 4096 characters. It is defined in the file [HW,MOUSE] Controls Logitech smartscroll autorepeat. 0 = disabled, 1 = enabled (default). - pss= [HW,OSS] Personal Sound System (ECHO ESC614) - Format: - ,,,,, - pt. [PARIDE] See Documentation/blockdev/paride.txt. @@ -2381,128 +2365,6 @@ and is between 256 and 4096 characters. It is defined in the file 1: Fast pin select (default) 2: ATC IRMode - snd-ad1816a= [HW,ALSA] - - snd-ad1848= [HW,ALSA] - - snd-ali5451= [HW,ALSA] - - snd-als100= [HW,ALSA] - - snd-als4000= [HW,ALSA] - - snd-azt2320= [HW,ALSA] - - snd-cmi8330= [HW,ALSA] - - snd-cmipci= [HW,ALSA] - - snd-cs4231= [HW,ALSA] - - snd-cs4232= [HW,ALSA] - - snd-cs4236= [HW,ALSA] - - snd-cs4281= [HW,ALSA] - - snd-cs46xx= [HW,ALSA] - - snd-dt019x= [HW,ALSA] - - snd-dummy= [HW,ALSA] - - snd-emu10k1= [HW,ALSA] - - snd-ens1370= [HW,ALSA] - - snd-ens1371= [HW,ALSA] - - snd-es968= [HW,ALSA] - - snd-es1688= [HW,ALSA] - - snd-es18xx= [HW,ALSA] - - snd-es1938= [HW,ALSA] - - snd-es1968= [HW,ALSA] - - snd-fm801= [HW,ALSA] - - snd-gusclassic= [HW,ALSA] - - snd-gusextreme= [HW,ALSA] - - snd-gusmax= [HW,ALSA] - - snd-hdsp= [HW,ALSA] - - snd-ice1712= [HW,ALSA] - - snd-intel8x0= [HW,ALSA] - - snd-interwave= [HW,ALSA] - - snd-interwave-stb= - [HW,ALSA] - - snd-korg1212= [HW,ALSA] - - snd-maestro3= [HW,ALSA] - - snd-mpu401= [HW,ALSA] - - snd-mtpav= [HW,ALSA] - - snd-nm256= [HW,ALSA] - - snd-opl3sa2= [HW,ALSA] - - snd-opti92x-ad1848= - [HW,ALSA] - - snd-opti92x-cs4231= - [HW,ALSA] - - snd-opti93x= [HW,ALSA] - - snd-pmac= [HW,ALSA] - - snd-rme32= [HW,ALSA] - - snd-rme96= [HW,ALSA] - - snd-rme9652= [HW,ALSA] - - snd-sb8= [HW,ALSA] - - snd-sb16= [HW,ALSA] - - snd-sbawe= [HW,ALSA] - - snd-serial= [HW,ALSA] - - snd-sgalaxy= [HW,ALSA] - - snd-sonicvibes= [HW,ALSA] - - snd-sun-amd7930= - [HW,ALSA] - - snd-sun-cs4231= [HW,ALSA] - - snd-trident= [HW,ALSA] - - snd-usb-audio= [HW,ALSA,USB] - - snd-via82xx= [HW,ALSA] - - snd-virmidi= [HW,ALSA] - - snd-wavefront= [HW,ALSA] - - snd-ymfpci= [HW,ALSA] - softlockup_panic= [KNL] Should the soft-lockup detector generate panics. @@ -2517,9 +2379,6 @@ and is between 256 and 4096 characters. It is defined in the file spia_pedr= spia_peddr= - sscape= [HW,OSS] - Format: ,,,, - st= [HW,SCSI] SCSI tape parameters (buffers, etc.) See Documentation/scsi/st.txt. @@ -2659,10 +2518,6 @@ and is between 256 and 4096 characters. It is defined in the file to facilitate early boot debugging. See also Documentation/trace/events.txt - trix= [HW,OSS] MediaTrix AudioTrix Pro - Format: - ,,,,,,,, - tsc= Disable clocksource-must-verify flag for TSC. Format: [x86] reliable: mark tsc clocksource as reliable, this @@ -2679,12 +2534,6 @@ and is between 256 and 4096 characters. It is defined in the file u14-34f= [HW,SCSI] UltraStor 14F/34F SCSI host adapter See header of drivers/scsi/u14-34f.c. - uart401= [HW,OSS] - Format: , - - uart6850= [HW,OSS] - Format: , - uhash_entries= [KNL,NET] Set number of hash buckets for UDP/UDP-Lite connections @@ -2850,9 +2699,6 @@ and is between 256 and 4096 characters. It is defined in the file overridden by individual drivers. 0 will hide cursors, 1 will display them. - waveartist= [HW,OSS] - Format: ,,, - wd33c93= [HW,SCSI] See header of drivers/scsi/wd33c93.c. @@ -2885,5 +2731,4 @@ ______________________________________________________________________ TODO: - Add documentation for ALSA options. Add more DRM drivers. diff --git a/Documentation/sound/alsa/alsa-parameters.txt b/Documentation/sound/alsa/alsa-parameters.txt new file mode 100644 index 0000000..0fa4067 --- /dev/null +++ b/Documentation/sound/alsa/alsa-parameters.txt @@ -0,0 +1,135 @@ + ALSA Kernel Parameters + ~~~~~~~~~~~~~~~~~~~~~~ + +See Documentation/kernel-parameters.txt for general information on +specifying module parameters. + +This document may not be entirely up to date and comprehensive. The command +"modinfo -p ${modulename}" shows a current list of all parameters of a loadable +module. Loadable modules, after being loaded into the running kernel, also +reveal their parameters in /sys/module/${modulename}/parameters/. Some of these +parameters may be changed at runtime by the command +"echo -n ${value} > /sys/module/${modulename}/parameters/${parm}". + + + snd-ad1816a= [HW,ALSA] + + snd-ad1848= [HW,ALSA] + + snd-ali5451= [HW,ALSA] + + snd-als100= [HW,ALSA] + + snd-als4000= [HW,ALSA] + + snd-azt2320= [HW,ALSA] + + snd-cmi8330= [HW,ALSA] + + snd-cmipci= [HW,ALSA] + + snd-cs4231= [HW,ALSA] + + snd-cs4232= [HW,ALSA] + + snd-cs4236= [HW,ALSA] + + snd-cs4281= [HW,ALSA] + + snd-cs46xx= [HW,ALSA] + + snd-dt019x= [HW,ALSA] + + snd-dummy= [HW,ALSA] + + snd-emu10k1= [HW,ALSA] + + snd-ens1370= [HW,ALSA] + + snd-ens1371= [HW,ALSA] + + snd-es968= [HW,ALSA] + + snd-es1688= [HW,ALSA] + + snd-es18xx= [HW,ALSA] + + snd-es1938= [HW,ALSA] + + snd-es1968= [HW,ALSA] + + snd-fm801= [HW,ALSA] + + snd-gusclassic= [HW,ALSA] + + snd-gusextreme= [HW,ALSA] + + snd-gusmax= [HW,ALSA] + + snd-hdsp= [HW,ALSA] + + snd-ice1712= [HW,ALSA] + + snd-intel8x0= [HW,ALSA] + + snd-interwave= [HW,ALSA] + + snd-interwave-stb= + [HW,ALSA] + + snd-korg1212= [HW,ALSA] + + snd-maestro3= [HW,ALSA] + + snd-mpu401= [HW,ALSA] + + snd-mtpav= [HW,ALSA] + + snd-nm256= [HW,ALSA] + + snd-opl3sa2= [HW,ALSA] + + snd-opti92x-ad1848= + [HW,ALSA] + + snd-opti92x-cs4231= + [HW,ALSA] + + snd-opti93x= [HW,ALSA] + + snd-pmac= [HW,ALSA] + + snd-rme32= [HW,ALSA] + + snd-rme96= [HW,ALSA] + + snd-rme9652= [HW,ALSA] + + snd-sb8= [HW,ALSA] + + snd-sb16= [HW,ALSA] + + snd-sbawe= [HW,ALSA] + + snd-serial= [HW,ALSA] + + snd-sgalaxy= [HW,ALSA] + + snd-sonicvibes= [HW,ALSA] + + snd-sun-amd7930= + [HW,ALSA] + + snd-sun-cs4231= [HW,ALSA] + + snd-trident= [HW,ALSA] + + snd-usb-audio= [HW,ALSA,USB] + + snd-via82xx= [HW,ALSA] + + snd-virmidi= [HW,ALSA] + + snd-wavefront= [HW,ALSA] + + snd-ymfpci= [HW,ALSA] diff --git a/Documentation/sound/oss/oss-parameters.txt b/Documentation/sound/oss/oss-parameters.txt new file mode 100644 index 0000000..3ab391e --- /dev/null +++ b/Documentation/sound/oss/oss-parameters.txt @@ -0,0 +1,51 @@ + OSS Kernel Parameters + ~~~~~~~~~~~~~~~~~~~~~ + +See Documentation/kernel-parameters.txt for general information on +specifying module parameters. + +This document may not be entirely up to date and comprehensive. The command +"modinfo -p ${modulename}" shows a current list of all parameters of a loadable +module. Loadable modules, after being loaded into the running kernel, also +reveal their parameters in /sys/module/${modulename}/parameters/. Some of these +parameters may be changed at runtime by the command +"echo -n ${value} > /sys/module/${modulename}/parameters/${parm}". + + + ad1848= [HW,OSS] + Format: ,,,, + + aedsp16= [HW,OSS] Audio Excel DSP 16 + Format: ,,,,, + See also header of sound/oss/aedsp16.c. + + dmasound= [HW,OSS] Sound subsystem buffers + + mpu401= [HW,OSS] + Format: , + + opl3= [HW,OSS] + Format: + + pas2= [HW,OSS] Format: + ,,,,,,, + + pss= [HW,OSS] Personal Sound System (ECHO ESC614) + Format: + ,,,,, + + sscape= [HW,OSS] + Format: ,,,, + + trix= [HW,OSS] MediaTrix AudioTrix Pro + Format: + ,,,,,,,, + + uart401= [HW,OSS] + Format: , + + uart6850= [HW,OSS] + Format: , + + waveartist= [HW,OSS] + Format: ,,, -- cgit v1.1 From 039ca4e74a1cf60bd7487324a564ecf5c981f254 Mon Sep 17 00:00:00 2001 From: Li Zefan Date: Wed, 26 May 2010 17:22:17 +0800 Subject: tracing: Remove kmemtrace ftrace plugin We have been resisting new ftrace plugins and removing existing ones, and kmemtrace has been superseded by kmem trace events and perf-kmem, so we remove it. Signed-off-by: Li Zefan Acked-by: Pekka Enberg Acked-by: Eduard - Gabriel Munteanu Cc: Ingo Molnar Cc: Steven Rostedt [ remove kmemtrace from the makefile, handle slob too ] Signed-off-by: Frederic Weisbecker --- Documentation/ABI/testing/debugfs-kmemtrace | 71 ---------------- Documentation/trace/kmemtrace.txt | 126 ---------------------------- 2 files changed, 197 deletions(-) delete mode 100644 Documentation/ABI/testing/debugfs-kmemtrace delete mode 100644 Documentation/trace/kmemtrace.txt (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-kmemtrace b/Documentation/ABI/testing/debugfs-kmemtrace deleted file mode 100644 index 5e6a92a..0000000 --- a/Documentation/ABI/testing/debugfs-kmemtrace +++ /dev/null @@ -1,71 +0,0 @@ -What: /sys/kernel/debug/kmemtrace/ -Date: July 2008 -Contact: Eduard - Gabriel Munteanu -Description: - -In kmemtrace-enabled kernels, the following files are created: - -/sys/kernel/debug/kmemtrace/ - cpu (0400) Per-CPU tracing data, see below. (binary) - total_overruns (0400) Total number of bytes which were dropped from - cpu files because of full buffer condition, - non-binary. (text) - abi_version (0400) Kernel's kmemtrace ABI version. (text) - -Each per-CPU file should be read according to the relay interface. That is, -the reader should set affinity to that specific CPU and, as currently done by -the userspace application (though there are other methods), use poll() with -an infinite timeout before every read(). Otherwise, erroneous data may be -read. The binary data has the following _core_ format: - - Event ID (1 byte) Unsigned integer, one of: - 0 - represents an allocation (KMEMTRACE_EVENT_ALLOC) - 1 - represents a freeing of previously allocated memory - (KMEMTRACE_EVENT_FREE) - Type ID (1 byte) Unsigned integer, one of: - 0 - this is a kmalloc() / kfree() - 1 - this is a kmem_cache_alloc() / kmem_cache_free() - 2 - this is a __get_free_pages() et al. - Event size (2 bytes) Unsigned integer representing the - size of this event. Used to extend - kmemtrace. Discard the bytes you - don't know about. - Sequence number (4 bytes) Signed integer used to reorder data - logged on SMP machines. Wraparound - must be taken into account, although - it is unlikely. - Caller address (8 bytes) Return address to the caller. - Pointer to mem (8 bytes) Pointer to target memory area. Can be - NULL, but not all such calls might be - recorded. - -In case of KMEMTRACE_EVENT_ALLOC events, the next fields follow: - - Requested bytes (8 bytes) Total number of requested bytes, - unsigned, must not be zero. - Allocated bytes (8 bytes) Total number of actually allocated - bytes, unsigned, must not be lower - than requested bytes. - Requested flags (4 bytes) GFP flags supplied by the caller. - Target CPU (4 bytes) Signed integer, valid for event id 1. - If equal to -1, target CPU is the same - as origin CPU, but the reverse might - not be true. - -The data is made available in the same endianness the machine has. - -Other event ids and type ids may be defined and added. Other fields may be -added by increasing event size, but see below for details. -Every modification to the ABI, including new id definitions, are followed -by bumping the ABI version by one. - -Adding new data to the packet (features) is done at the end of the mandatory -data: - Feature size (2 byte) - Feature ID (1 byte) - Feature data (Feature size - 3 bytes) - - -Users: - kmemtrace-user - git://repo.or.cz/kmemtrace-user.git - diff --git a/Documentation/trace/kmemtrace.txt b/Documentation/trace/kmemtrace.txt deleted file mode 100644 index 6308735..0000000 --- a/Documentation/trace/kmemtrace.txt +++ /dev/null @@ -1,126 +0,0 @@ - kmemtrace - Kernel Memory Tracer - - by Eduard - Gabriel Munteanu - - -I. Introduction -=============== - -kmemtrace helps kernel developers figure out two things: -1) how different allocators (SLAB, SLUB etc.) perform -2) how kernel code allocates memory and how much - -To do this, we trace every allocation and export information to the userspace -through the relay interface. We export things such as the number of requested -bytes, the number of bytes actually allocated (i.e. including internal -fragmentation), whether this is a slab allocation or a plain kmalloc() and so -on. - -The actual analysis is performed by a userspace tool (see section III for -details on where to get it from). It logs the data exported by the kernel, -processes it and (as of writing this) can provide the following information: -- the total amount of memory allocated and fragmentation per call-site -- the amount of memory allocated and fragmentation per allocation -- total memory allocated and fragmentation in the collected dataset -- number of cross-CPU allocation and frees (makes sense in NUMA environments) - -Moreover, it can potentially find inconsistent and erroneous behavior in -kernel code, such as using slab free functions on kmalloc'ed memory or -allocating less memory than requested (but not truly failed allocations). - -kmemtrace also makes provisions for tracing on some arch and analysing the -data on another. - -II. Design and goals -==================== - -kmemtrace was designed to handle rather large amounts of data. Thus, it uses -the relay interface to export whatever is logged to userspace, which then -stores it. Analysis and reporting is done asynchronously, that is, after the -data is collected and stored. By design, it allows one to log and analyse -on different machines and different arches. - -As of writing this, the ABI is not considered stable, though it might not -change much. However, no guarantees are made about compatibility yet. When -deemed stable, the ABI should still allow easy extension while maintaining -backward compatibility. This is described further in Documentation/ABI. - -Summary of design goals: - - allow logging and analysis to be done across different machines - - be fast and anticipate usage in high-load environments (*) - - be reasonably extensible - - make it possible for GNU/Linux distributions to have kmemtrace - included in their repositories - -(*) - one of the reasons Pekka Enberg's original userspace data analysis - tool's code was rewritten from Perl to C (although this is more than a - simple conversion) - - -III. Quick usage guide -====================== - -1) Get a kernel that supports kmemtrace and build it accordingly (i.e. enable -CONFIG_KMEMTRACE). - -2) Get the userspace tool and build it: -$ git clone git://repo.or.cz/kmemtrace-user.git # current repository -$ cd kmemtrace-user/ -$ ./autogen.sh -$ ./configure -$ make - -3) Boot the kmemtrace-enabled kernel if you haven't, preferably in the -'single' runlevel (so that relay buffers don't fill up easily), and run -kmemtrace: -# '$' does not mean user, but root here. -$ mount -t debugfs none /sys/kernel/debug -$ mount -t proc none /proc -$ cd path/to/kmemtrace-user/ -$ ./kmemtraced -Wait a bit, then stop it with CTRL+C. -$ cat /sys/kernel/debug/kmemtrace/total_overruns # Check if we didn't - # overrun, should - # be zero. -$ (Optionally) [Run kmemtrace_check separately on each cpu[0-9]*.out file to - check its correctness] -$ ./kmemtrace-report - -Now you should have a nice and short summary of how the allocator performs. - -IV. FAQ and known issues -======================== - -Q: 'cat /sys/kernel/debug/kmemtrace/total_overruns' is non-zero, how do I fix -this? Should I worry? -A: If it's non-zero, this affects kmemtrace's accuracy, depending on how -large the number is. You can fix it by supplying a higher -'kmemtrace.subbufs=N' kernel parameter. ---- - -Q: kmemtrace_check reports errors, how do I fix this? Should I worry? -A: This is a bug and should be reported. It can occur for a variety of -reasons: - - possible bugs in relay code - - possible misuse of relay by kmemtrace - - timestamps being collected unorderly -Or you may fix it yourself and send us a patch. ---- - -Q: kmemtrace_report shows many errors, how do I fix this? Should I worry? -A: This is a known issue and I'm working on it. These might be true errors -in kernel code, which may have inconsistent behavior (e.g. allocating memory -with kmem_cache_alloc() and freeing it with kfree()). Pekka Enberg pointed -out this behavior may work with SLAB, but may fail with other allocators. - -It may also be due to lack of tracing in some unusual allocator functions. - -We don't want bug reports regarding this issue yet. ---- - -V. See also -=========== - -Documentation/kernel-parameters.txt -Documentation/ABI/testing/debugfs-kmemtrace - -- cgit v1.1 From e228b1e6513b43b837ceff7256ae02e9ada619fa Mon Sep 17 00:00:00 2001 From: Nicolas Palix Date: Sun, 6 Jun 2010 17:15:02 +0200 Subject: Add Documentation/coccinelle.txt The purpose of this file is to document how to use Coccinelle and its spatch tool to check the Linux kernel. It gives information on where and how to retrieve Coccinelle, and how to use it with the Coccinelle scripts integrated in the Linux kernel. Signed-off-by: Nicolas Palix Signed-off-by: Julia Lawall Signed-off-by: Michal Marek --- Documentation/coccinelle.txt | 258 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 258 insertions(+) create mode 100644 Documentation/coccinelle.txt (limited to 'Documentation') diff --git a/Documentation/coccinelle.txt b/Documentation/coccinelle.txt new file mode 100644 index 0000000..ba3315d --- /dev/null +++ b/Documentation/coccinelle.txt @@ -0,0 +1,258 @@ +Copyright 2010 Nicolas Palix +Copyright 2010 Julia Lawall +Copyright 2010 Gilles Muller + + + Getting Coccinelle +~~~~~~~~~~~~~~~~~~~~ + +The semantic patches included in the kernel use the 'virtual rule' +feature which was introduced in Coccinelle version 0.1.11. + +Coccinelle (>=0.2.0) is available through the package manager +of many distributions, e.g. : + + - Debian (>=squeeze) + - Fedora (>=13) + - Ubuntu (>=10.04 Karmic Koala) + - OpenSUSE + - Arch Linux + - NetBSD + - FreeBSD + + +You can get the latest version released from the Coccinelle homepage at +http://coccinelle.lip6.fr/ + +Once you have it, run the following command: + + ./configure + make + +as a regular user, and install it with + + sudo make install + + + Using Coccinelle on the Linux kernel +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A Coccinelle-specific target is defined in the top level +Makefile. This target is named 'coccicheck' and calls the 'coccicheck' +front-end in the 'scripts' directory. + +Four modes are defined: report, patch, context, and org. The mode to +use is specified by setting the MODE variable with 'MODE='. + +'report' generates a list in the following format: + file:line:column-column: message + +'patch' proposes a fix, when possible. + +'context' highlights lines of interest and their context in a +diff-like style.Lines of interest are indicated with '-'. + +'org' generates a report in the Org mode format of Emacs. + +Note that not all semantic patches implement all modes. + +To make a report for every semantic patch, run the following command: + + make coccicheck MODE=report + +NB: The 'report' mode is the default one. + +To produce patches, run: + + make coccicheck MODE=patch + + +The coccicheck target applies every semantic patch available in the +subdirectories of 'scripts/coccinelle' to the entire Linux kernel. + +For each semantic patch, a changelog message is proposed. It gives a +description of the problem being checked by the semantic patch, and +includes a reference to Coccinelle. + +As any static code analyzer, Coccinelle produces false +positives. Thus, reports must be carefully checked, and patches +reviewed. + + + Using Coccinelle with a single semantic patch +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The optional make variable COCCI can be used to check a single +semantic patch. In that case, the variable must be initialized with +the name of the semantic patch to apply. + +For instance: + + make coccicheck COCCI= MODE=patch +or + make coccicheck COCCI= MODE=report + + + Proposing new semantic patches +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +New semantic patches can be proposed and submitted by kernel +developers. For sake of clarity, they should be organized in the +subdirectories of 'scripts/coccinelle/'. + + + Detailed description of the 'report' mode +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +'report' generates a list in the following format: + file:line:column-column: message + +Example: + +Running + + make coccicheck MODE=report COCCI=scripts/coccinelle/err_cast.cocci + +will execute the following part of the SmPL script. + + +@r depends on !context && !patch && (org || report)@ +expression x; +position p; +@@ + + ERR_PTR@p(PTR_ERR(x)) + +@script:python depends on report@ +p << r.p; +x << r.x; +@@ + +msg="ERR_CAST can be used with %s" % (x) +coccilib.report.print_report(p[0], msg) + + +This SmPL excerpt generates entries on the standard output, as +illustrated below: + +/home/user/linux/crypto/ctr.c:188:9-16: ERR_CAST can be used with alg +/home/user/linux/crypto/authenc.c:619:9-16: ERR_CAST can be used with auth +/home/user/linux/crypto/xts.c:227:9-16: ERR_CAST can be used with alg + + + Detailed description of the 'patch' mode +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When the 'patch' mode is available, it proposes a fix for each problem +identified. + +Example: + +Running + make coccicheck MODE=patch COCCI=scripts/coccinelle/err_cast.cocci + +will execute the following part of the SmPL script. + + +@ depends on !context && patch && !org && !report @ +expression x; +@@ + +- ERR_PTR(PTR_ERR(x)) ++ ERR_CAST(x) + + +This SmPL excerpt generates patch hunks on the standard output, as +illustrated below: + +diff -u -p a/crypto/ctr.c b/crypto/ctr.c +--- a/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200 ++++ b/crypto/ctr.c 2010-06-03 23:44:49.000000000 +0200 +@@ -185,7 +185,7 @@ static struct crypto_instance *crypto_ct + alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER, + CRYPTO_ALG_TYPE_MASK); + if (IS_ERR(alg)) +- return ERR_PTR(PTR_ERR(alg)); ++ return ERR_CAST(alg); + + /* Block size must be >= 4 bytes. */ + err = -EINVAL; + + Detailed description of the 'context' mode +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +'context' highlights lines of interest and their context +in a diff-like style. + +NOTE: The diff-like output generated is NOT an applicable patch. The + intent of the 'context' mode is to highlight the important lines + (annotated with minus, '-') and gives some surrounding context + lines around. This output can be used with the diff mode of + Emacs to review the code. + +Example: + +Running + make coccicheck MODE=context COCCI=scripts/coccinelle/err_cast.cocci + +will execute the following part of the SmPL script. + + +@ depends on context && !patch && !org && !report@ +expression x; +@@ + +* ERR_PTR(PTR_ERR(x)) + + +This SmPL excerpt generates diff hunks on the standard output, as +illustrated below: + +diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing +--- /home/user/linux/crypto/ctr.c 2010-05-26 10:49:38.000000000 +0200 ++++ /tmp/nothing +@@ -185,7 +185,6 @@ static struct crypto_instance *crypto_ct + alg = crypto_attr_alg(tb[1], CRYPTO_ALG_TYPE_CIPHER, + CRYPTO_ALG_TYPE_MASK); + if (IS_ERR(alg)) +- return ERR_PTR(PTR_ERR(alg)); + + /* Block size must be >= 4 bytes. */ + err = -EINVAL; + + Detailed description of the 'org' mode +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +'org' generates a report in the Org mode format of Emacs. + +Example: + +Running + make coccicheck MODE=org COCCI=scripts/coccinelle/err_cast.cocci + +will execute the following part of the SmPL script. + + +@r depends on !context && !patch && (org || report)@ +expression x; +position p; +@@ + + ERR_PTR@p(PTR_ERR(x)) + +@script:python depends on org@ +p << r.p; +x << r.x; +@@ + +msg="ERR_CAST can be used with %s" % (x) +msg_safe=msg.replace("[","@(").replace("]",")") +coccilib.org.print_todo(p[0], msg_safe) + + +This SmPL excerpt generates Org entries on the standard output, as +illustrated below: + +* TODO [[view:/home/user/linux/crypto/ctr.c::face=ovl-face1::linb=188::colb=9::cole=16][ERR_CAST can be used with alg]] +* TODO [[view:/home/user/linux/crypto/authenc.c::face=ovl-face1::linb=619::colb=9::cole=16][ERR_CAST can be used with auth]] +* TODO [[view:/home/user/linux/crypto/xts.c::face=ovl-face1::linb=227::colb=9::cole=16][ERR_CAST can be used with alg]] -- cgit v1.1 From 43d28b6515a6ea580a198df3e253e88236f08978 Mon Sep 17 00:00:00 2001 From: Daniel Turull Date: Wed, 9 Jun 2010 22:49:57 +0000 Subject: pktgen: increasing transmission granularity This patch increases the granularity of the rate generated by pktgen. The previous version of pktgen uses micro seconds (udelay) resolution when it was delayed causing gaps in the rates. It is changed to nanosecond (ndelay). Now any rate is possible. Also it allows to set, the desired rate in Mb/s or packets per second. The documentation has been updated. Signed-off-by: Daniel Turull Signed-off-by: Robert Olsson Signed-off-by: David S. Miller --- Documentation/networking/pktgen.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt index 61bb645..75e4fd7 100644 --- a/Documentation/networking/pktgen.txt +++ b/Documentation/networking/pktgen.txt @@ -151,6 +151,8 @@ Examples: pgset stop aborts injection. Also, ^C aborts generator. + pgset "rate 300M" set rate to 300 Mb/s + pgset "ratep 1000000" set rate to 1Mpps Example scripts =============== @@ -241,6 +243,9 @@ src6 flows flowlen +rate +ratep + References: ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/ ftp://robur.slu.se/pub/Linux/net-development/pktgen-testing/examples/ -- cgit v1.1 From c086abae5baa2df449ea5247011e8b7d52bb13f4 Mon Sep 17 00:00:00 2001 From: "ubuntu@tjworld.net" Date: Mon, 23 Mar 2009 20:29:28 +0000 Subject: ipw2200: Enable LED by default BugLink: http://bugs.launchpad.net/bugs/21367 Enable LED by default and update the MODULE_PARM_DESC. The original reason for defaulting to disabled was documented in 2005 and noted, "The LED code has been reported to hang some systems when running ifconfig and is therefore disabled by default." This no longer appears applicable and users have been requesting this be enabled for several years. Signed-off-by: TJ Signed-off-by: Tim Gardner Signed-off-by: Andy Whitcroft Acked-by: Stefan Bader Signed-off-by: Leann Ogasawara Signed-off-by: John W. Linville --- Documentation/networking/README.ipw2200 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/README.ipw2200 b/Documentation/networking/README.ipw2200 index 80c7285..e4d3267 100644 --- a/Documentation/networking/README.ipw2200 +++ b/Documentation/networking/README.ipw2200 @@ -171,7 +171,7 @@ Where the supported parameter are: led Can be used to turn on experimental LED code. - 0 = Off, 1 = On. Default is 0. + 0 = Off, 1 = On. Default is 1. mode Can be used to set the default mode of the adapter. -- cgit v1.1 From f7154de220f14073ef0d76638f85e254ad2e202f Mon Sep 17 00:00:00 2001 From: Herton Ronaldo Krzesinski Date: Thu, 17 Jun 2010 14:15:06 -0300 Subject: ALSA: hda - add ideapad model for Conexant 5051 codec Lenovo IdeaPad Y430 has an additional subwoofer connected at pin 0x1b, which isn't muted when headphone is plugged in. This adds additional support to the extra subwoofer via new ideapad model. Signed-off-by: Herton Ronaldo Krzesinski Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 1d38b0d..84e81ad 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -282,6 +282,7 @@ Conexant 5051 hp HP Spartan laptop hp-dv6736 HP dv6736 hp-f700 HP Compaq Presario F700 + ideapad Lenovo IdeaPad laptop lenovo-x200 Lenovo X200 laptop toshiba Toshiba Satellite M300 -- cgit v1.1 From fd699c76552bbfa66631f019be415a87dbb08237 Mon Sep 17 00:00:00 2001 From: Andres Salomon Date: Fri, 18 Jun 2010 17:46:53 -0400 Subject: x86, olpc: Add support for calling into OpenFirmware Add support for saving OFW's cif, and later calling into it to run OFW commands. OFW remains resident in memory, living within virtual range 0xff800000 - 0xffc00000. A single page directory entry points to the pgdir that OFW actually uses, so rather than saving the entire page table, we grab and install that one entry permanently in the kernel's page table. This is currently only used by the OLPC XO. Note that this particular calling convention breaks PAE and PAT, and so cannot be used on newer x86 hardware. Signed-off-by: Andres Salomon LKML-Reference: <20100618174653.7755a39a@dev.queued.net> Signed-off-by: H. Peter Anvin --- Documentation/x86/zero-page.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt index feb37e1..cf5437d 100644 --- a/Documentation/x86/zero-page.txt +++ b/Documentation/x86/zero-page.txt @@ -18,6 +18,7 @@ Offset Proto Name Meaning 080/010 ALL hd0_info hd0 disk parameter, OBSOLETE!! 090/010 ALL hd1_info hd1 disk parameter, OBSOLETE!! 0A0/010 ALL sys_desc_table System description table (struct sys_desc_table) +0B0/010 ALL olpc_ofw_header OLPC's OpenFirmware CIF and friends 140/080 ALL edid_info Video mode setup (struct edid_info) 1C0/020 ALL efi_info EFI 32 information (struct efi_info) 1E0/004 ALL alk_mem_k Alternative mem check, in KB -- cgit v1.1 From 0b3fa399bef02f3658295f8dd334fc26a59c3a95 Mon Sep 17 00:00:00 2001 From: Stefan Achatz Date: Fri, 18 Jun 2010 16:42:25 +0200 Subject: HID: roccat: remove obsolete kone_abi_version sysfs attribute The newest version of the accompanying userland tools cuts backward compatibility and uses libudev to find its devices superseding the quirky kone_abi_version sysfs attribute. Therefore it should be removed. Signed-off-by: Stefan Achatz Signed-off-by: Jiri Kosina --- Documentation/ABI/testing/sysfs-driver-hid-roccat-kone | 12 ------------ 1 file changed, 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone index 36bfa23..063bda7 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone @@ -33,18 +33,6 @@ Description: When read, this file returns the raw integer version number of the left. E.g. a returned value of 138 means 1.38 This file is readonly. -What: /sys/bus/usb/devices/-:./kone_abi_version -Date: May 2010 -Contact: Stefan Achatz -Description: When read, this file returns the abi version as an integer value. - This attribute is used by the userland tools to find the sysfs- - paths of installed kone-mice and determine the capabilites of - the driver. Versions of this driver for old kernels replace - usbhid instead of generic-usb. The way to scan for this file - has been chosen to provide a consistent way for all supported - kernel versions. - This file is readonly. - What: /sys/bus/usb/devices/-:./profile[1-5] Date: March 2010 Contact: Stefan Achatz -- cgit v1.1 From d4a86d81944d3cccb3f4a309230e835823a61252 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Wed, 23 Jun 2010 17:51:26 +0200 Subject: ALSA: hda - Add missing ALC680_* definitions Also update the documentation. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 84e81ad..03771d7 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -114,6 +114,11 @@ ALC662/663/272 samsung-nc10 Samsung NC10 mini notebook auto auto-config reading BIOS (default) +ALC680 +====== + base Base model (ASUS NX90) + auto auto-config reading BIOS (default) + ALC882/883/885/888/889 ====================== 3stack-dig 3-jack with SPDIF I/O -- cgit v1.1 From d70a011dbbaa6335a19deb63ec3eb613f48faafd Mon Sep 17 00:00:00 2001 From: Tim Gardner Date: Fri, 25 Jun 2010 14:46:56 +0200 Subject: netfilter: complete the deprecation of CONFIG_NF_CT_ACCT CONFIG_NF_CT_ACCT has been deprecated for awhile and was originally scheduled for removal by 2.6.29. Removing support for this config option also stops this deprecation warning message in the kernel log. [ 61.669627] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) [ 61.669850] CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use [ 61.669852] nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or [ 61.669853] sysctl net.netfilter.nf_conntrack_acct=1 to enable it. Signed-off-by: Tim Gardner [Patrick: changed default value to 0] Signed-off-by: Patrick McHardy --- Documentation/feature-removal-schedule.txt | 9 --------- Documentation/kernel-parameters.txt | 3 +-- 2 files changed, 1 insertion(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 672be01..92f021a 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -303,15 +303,6 @@ Who: Johannes Berg --------------------------- -What: CONFIG_NF_CT_ACCT -When: 2.6.29 -Why: Accounting can now be enabled/disabled without kernel recompilation. - Currently used only to set a default value for a feature that is also - controlled by a kernel/module/sysfs/sysctl parameter. -Who: Krzysztof Piotr Oledzki - ---------------------------- - What: sysfs ui for changing p4-clockmod parameters When: September 2009 Why: See commits 129f8ae9b1b5be94517da76009ea956e89104ce8 and diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 1808f11..cee6251 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1597,8 +1597,7 @@ and is between 256 and 4096 characters. It is defined in the file [NETFILTER] Enable connection tracking flow accounting 0 to disable accounting 1 to enable accounting - Default value depends on CONFIG_NF_CT_ACCT that is - going to be removed in 2.6.29. + Default value is 0. nfsaddrs= [NFS] See Documentation/filesystems/nfs/nfsroot.txt. -- cgit v1.1 From 2174efb6a22a0002f2002b708a28d3adfabb3bc5 Mon Sep 17 00:00:00 2001 From: Kulikov Vasiliy Date: Mon, 28 Jun 2010 13:59:28 +0200 Subject: Documentation/sysctl/vm.txt typo Fix trivial typo: duplicated word. Signed-off-by: Kulikov Vasiliy Acked-by: Randy Dunlap Signed-off-by: Jiri Kosina --- Documentation/sysctl/vm.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 5fdbb61..82b2da1 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -196,7 +196,7 @@ controlled by this knob are discussed in Documentation/laptops/laptop-mode.txt. legacy_va_layout -If non-zero, this sysctl disables the new 32-bit mmap mmap layout - the kernel +If non-zero, this sysctl disables the new 32-bit mmap layout - the kernel will use the legacy (2.4) layout for all processes. ============================================================== -- cgit v1.1 From 529d6dad5bc69de14cdd24831e2a14264e93daa4 Mon Sep 17 00:00:00 2001 From: Sjur Braendeland Date: Tue, 29 Jun 2010 00:08:21 -0700 Subject: caif-driver: Add CAIF-SPI Protocol driver. This patch introduces the CAIF SPI Protocol Driver for CAIF Link Layer. This driver implements a platform driver to accommodate for a platform specific SPI device. A general platform driver is not possible as there are no SPI Slave side Kernel API defined. A sample CAIF SPI Platform device can be found in .../Documentation/networking/caif/spi_porting.txt Signed-off-by: Sjur Braendeland Signed-off-by: David S. Miller --- Documentation/networking/caif/spi_porting.txt | 208 ++++++++++++++++++++++++++ 1 file changed, 208 insertions(+) create mode 100644 Documentation/networking/caif/spi_porting.txt (limited to 'Documentation') diff --git a/Documentation/networking/caif/spi_porting.txt b/Documentation/networking/caif/spi_porting.txt new file mode 100644 index 0000000..61d7c92 --- /dev/null +++ b/Documentation/networking/caif/spi_porting.txt @@ -0,0 +1,208 @@ +- CAIF SPI porting - + +- CAIF SPI basics: + +Running CAIF over SPI needs some extra setup, owing to the nature of SPI. +Two extra GPIOs have been added in order to negotiate the transfers + between the master and the slave. The minimum requirement for running +CAIF over SPI is a SPI slave chip and two GPIOs (more details below). +Please note that running as a slave implies that you need to keep up +with the master clock. An overrun or underrun event is fatal. + +- CAIF SPI framework: + +To make porting as easy as possible, the CAIF SPI has been divided in +two parts. The first part (called the interface part) deals with all +generic functionality such as length framing, SPI frame negotiation +and SPI frame delivery and transmission. The other part is the CAIF +SPI slave device part, which is the module that you have to write if +you want to run SPI CAIF on a new hardware. This part takes care of +the physical hardware, both with regard to SPI and to GPIOs. + +- Implementing a CAIF SPI device: + + - Functionality provided by the CAIF SPI slave device: + + In order to implement a SPI device you will, as a minimum, + need to implement the following + functions: + + int (*init_xfer) (struct cfspi_xfer * xfer, struct cfspi_dev *dev): + + This function is called by the CAIF SPI interface to give + you a chance to set up your hardware to be ready to receive + a stream of data from the master. The xfer structure contains + both physical and logical adresses, as well as the total length + of the transfer in both directions.The dev parameter can be used + to map to different CAIF SPI slave devices. + + void (*sig_xfer) (bool xfer, struct cfspi_dev *dev): + + This function is called by the CAIF SPI interface when the output + (SPI_INT) GPIO needs to change state. The boolean value of the xfer + variable indicates whether the GPIO should be asserted (HIGH) or + deasserted (LOW). The dev parameter can be used to map to different CAIF + SPI slave devices. + + - Functionality provided by the CAIF SPI interface: + + void (*ss_cb) (bool assert, struct cfspi_ifc *ifc); + + This function is called by the CAIF SPI slave device in order to + signal a change of state of the input GPIO (SS) to the interface. + Only active edges are mandatory to be reported. + This function can be called from IRQ context (recommended in order + not to introduce latency). The ifc parameter should be the pointer + returned from the platform probe function in the SPI device structure. + + void (*xfer_done_cb) (struct cfspi_ifc *ifc); + + This function is called by the CAIF SPI slave device in order to + report that a transfer is completed. This function should only be + called once both the transmission and the reception are completed. + This function can be called from IRQ context (recommended in order + not to introduce latency). The ifc parameter should be the pointer + returned from the platform probe function in the SPI device structure. + + - Connecting the bits and pieces: + + - Filling in the SPI slave device structure: + + Connect the necessary callback functions. + Indicate clock speed (used to calculate toggle delays). + Chose a suitable name (helps debugging if you use several CAIF + SPI slave devices). + Assign your private data (can be used to map to your structure). + + - Filling in the SPI slave platform device structure: + Add name of driver to connect to ("cfspi_sspi"). + Assign the SPI slave device structure as platform data. + +- Padding: + +In order to optimize throughput, a number of SPI padding options are provided. +Padding can be enabled independently for uplink and downlink transfers. +Padding can be enabled for the head, the tail and for the total frame size. +The padding needs to be correctly configured on both sides of the link. +The padding can be changed via module parameters in cfspi_sspi.c or via +the sysfs directory of the cfspi_sspi driver (before device registration). + +- CAIF SPI device template: + +/* + * Copyright (C) ST-Ericsson AB 2010 + * Author: Daniel Martensson / Daniel.Martensson@stericsson.com + * License terms: GNU General Public License (GPL), version 2. + * + */ + +#include +#include +#include +#include +#include +#include +#include + +MODULE_LICENSE("GPL"); + +struct sspi_struct { + struct cfspi_dev sdev; + struct cfspi_xfer *xfer; +}; + +static struct sspi_struct slave; +static struct platform_device slave_device; + +static irqreturn_t sspi_irq(int irq, void *arg) +{ + /* You only need to trigger on an edge to the active state of the + * SS signal. Once a edge is detected, the ss_cb() function should be + * called with the parameter assert set to true. It is OK + * (and even advised) to call the ss_cb() function in IRQ context in + * order not to add any delay. */ + + return IRQ_HANDLED; +} + +static void sspi_complete(void *context) +{ + /* Normally the DMA or the SPI framework will call you back + * in something similar to this. The only thing you need to + * do is to call the xfer_done_cb() function, providing the pointer + * to the CAIF SPI interface. It is OK to call this function + * from IRQ context. */ +} + +static int sspi_init_xfer(struct cfspi_xfer *xfer, struct cfspi_dev *dev) +{ + /* Store transfer info. For a normal implementation you should + * set up your DMA here and make sure that you are ready to + * receive the data from the master SPI. */ + + struct sspi_struct *sspi = (struct sspi_struct *)dev->priv; + + sspi->xfer = xfer; + + return 0; +} + +void sspi_sig_xfer(bool xfer, struct cfspi_dev *dev) +{ + /* If xfer is true then you should assert the SPI_INT to indicate to + * the master that you are ready to recieve the data from the master + * SPI. If xfer is false then you should de-assert SPI_INT to indicate + * that the transfer is done. + */ + + struct sspi_struct *sspi = (struct sspi_struct *)dev->priv; +} + +static void sspi_release(struct device *dev) +{ + /* + * Here you should release your SPI device resources. + */ +} + +static int __init sspi_init(void) +{ + /* Here you should initialize your SPI device by providing the + * necessary functions, clock speed, name and private data. Once + * done, you can register your device with the + * platform_device_register() function. This function will return + * with the CAIF SPI interface initialized. This is probably also + * the place where you should set up your GPIOs, interrupts and SPI + * resources. */ + + int res = 0; + + /* Initialize slave device. */ + slave.sdev.init_xfer = sspi_init_xfer; + slave.sdev.sig_xfer = sspi_sig_xfer; + slave.sdev.clk_mhz = 13; + slave.sdev.priv = &slave; + slave.sdev.name = "spi_sspi"; + slave_device.dev.release = sspi_release; + + /* Initialize platform device. */ + slave_device.name = "cfspi_sspi"; + slave_device.dev.platform_data = &slave.sdev; + + /* Register platform device. */ + res = platform_device_register(&slave_device); + if (res) { + printk(KERN_WARNING "sspi_init: failed to register dev.\n"); + return -ENODEV; + } + + return res; +} + +static void __exit sspi_exit(void) +{ + platform_device_del(&slave_device); +} + +module_init(sspi_init); +module_exit(sspi_exit); -- cgit v1.1 From 7974891db234467eaf1fec613ec0129cb4ac2332 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Mon, 28 Jun 2010 14:15:54 +0200 Subject: x86: Always use irq stacks IRQ stacks provide much better safety against unexpected stack use from interrupts, at the minimal downside of slightly higher memory usage. Enable irq stacks also for the default 8k stack on 32-bit kernels to minimize the problem of stack overflows through interrupt activity. This is what the 64-bit kernel and various other architectures already do. Signed-off-by: Christoph Hellwig LKML-Reference: <20100628121554.GA6605@lst.de> Signed-off-by: Thomas Gleixner --- Documentation/x86/x86_64/kernel-stacks | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/x86/x86_64/kernel-stacks b/Documentation/x86/x86_64/kernel-stacks index 5ad65d5..a01eec5 100644 --- a/Documentation/x86/x86_64/kernel-stacks +++ b/Documentation/x86/x86_64/kernel-stacks @@ -18,9 +18,9 @@ specialized stacks contain no useful data. The main CPU stacks are: Used for external hardware interrupts. If this is the first external hardware interrupt (i.e. not a nested hardware interrupt) then the kernel switches from the current task to the interrupt stack. Like - the split thread and interrupt stacks on i386 (with CONFIG_4KSTACKS), - this gives more room for kernel interrupt processing without having - to increase the size of every per thread stack. + the split thread and interrupt stacks on i386, this gives more room + for kernel interrupt processing without having to increase the size + of every per thread stack. The interrupt stack is also used when processing a softirq. -- cgit v1.1 From fbe3290f4558c72abf6e264c4a2ee708b0495d55 Mon Sep 17 00:00:00 2001 From: Kulikov Vasiliy Date: Tue, 29 Jun 2010 16:31:16 +0400 Subject: Documentation: fix ubuntu distro name 10.04 is Lucid, not Karmic. Signed-off-by: Kulikov Vasiliy Acked-by: Nicolas Palix Signed-off-by: Michal Marek --- Documentation/coccinelle.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/coccinelle.txt b/Documentation/coccinelle.txt index ba3315d..cd2b028 100644 --- a/Documentation/coccinelle.txt +++ b/Documentation/coccinelle.txt @@ -14,7 +14,7 @@ of many distributions, e.g. : - Debian (>=squeeze) - Fedora (>=13) - - Ubuntu (>=10.04 Karmic Koala) + - Ubuntu (>=10.04 Lucid Lynx) - OpenSUSE - Arch Linux - NetBSD -- cgit v1.1 From e09c8614b32915c16f68e039ac7040e602d73e35 Mon Sep 17 00:00:00 2001 From: Masami Hiramatsu Date: Mon, 5 Jul 2010 15:54:45 -0300 Subject: tracing/kprobes: Support "string" type Support string type tracing and printing in kprobe-tracer. This allows user to trace string data in kernel including __user data. Note that sometimes __user data may not be accessed if it is paged-out (sorry, but kprobes operation should be done in atomic, we can not wait for page-in). Commiter note: Fixed up conflicts with b7e2ece. Cc: Ingo Molnar Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Mike Galbraith Cc: Frederic Weisbecker LKML-Reference: <20100519195724.2885.18788.stgit@localhost6.localdomain6> Signed-off-by: Masami Hiramatsu Signed-off-by: Arnaldo Carvalho de Melo --- Documentation/trace/kprobetrace.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/trace/kprobetrace.txt b/Documentation/trace/kprobetrace.txt index ec94748..5f77d94 100644 --- a/Documentation/trace/kprobetrace.txt +++ b/Documentation/trace/kprobetrace.txt @@ -42,7 +42,7 @@ Synopsis of kprobe_events +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(**) NAME=FETCHARG : Set NAME as the argument name of FETCHARG. FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types - (u8/u16/u32/u64/s8/s16/s32/s64) are supported. + (u8/u16/u32/u64/s8/s16/s32/s64) and string are supported. (*) only for return probe. (**) this is useful for fetching a field of data structures. -- cgit v1.1 From 831334cbbbdc2b2923513104e6e70c80dda0bff0 Mon Sep 17 00:00:00 2001 From: Tilman Schmidt Date: Mon, 5 Jul 2010 14:18:22 +0000 Subject: Documentation/isdn: CAPI controller interface amendment Mention that the CAPI controller methods load_firmware() and reset_ctr() are asynchronous, and should signal completion. Signed-off-by: Tilman Schmidt Signed-off-by: David S. Miller --- Documentation/isdn/INTERFACE.CAPI | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/isdn/INTERFACE.CAPI b/Documentation/isdn/INTERFACE.CAPI index f172091..309eb5e 100644 --- a/Documentation/isdn/INTERFACE.CAPI +++ b/Documentation/isdn/INTERFACE.CAPI @@ -113,12 +113,16 @@ char *driver_name int (*load_firmware)(struct capi_ctr *ctrlr, capiloaddata *ldata) (optional) pointer to a callback function for sending firmware and configuration data to the device + The function may return before the operation has completed. + Completion must be signalled by a call to capi_ctr_ready(). Return value: 0 on success, error code on error Called in process context. void (*reset_ctr)(struct capi_ctr *ctrlr) - (optional) pointer to a callback function for performing a reset on - the device, releasing all registered applications + (optional) pointer to a callback function for stopping the device, + releasing all registered applications + The function may return before the operation has completed. + Completion must be signalled by a call to capi_ctr_down(). Called in process context. void (*register_appl)(struct capi_ctr *ctrlr, u16 applid, -- cgit v1.1 From 29124c70d779c89e04289468f437c093eb0811df Mon Sep 17 00:00:00 2001 From: Tilman Schmidt Date: Mon, 5 Jul 2010 14:19:25 +0000 Subject: isdn/gigaset: document dial-out number format Add a paragraph to the driver documentation describing how to make internal and external calls. Impact: documentation Signed-off-by: Tilman Schmidt Signed-off-by: David S. Miller --- Documentation/isdn/README.gigaset | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/isdn/README.gigaset b/Documentation/isdn/README.gigaset index e472df8..702c046 100644 --- a/Documentation/isdn/README.gigaset +++ b/Documentation/isdn/README.gigaset @@ -263,7 +263,22 @@ GigaSet 307x Device Driver change its CID mode while the driver is loaded, eg. echo 0 > /sys/class/tty/ttyGU0/cidmode -2.7. Unregistered Wireless Devices (M101/M105) +2.7. Dialing Numbers + --------------- + The called party number provided by an application for dialing out must + be a public network number according to the local dialing plan, without + any dial prefix for getting an outside line. + + Internal calls can be made by providing an internal extension number + prefixed with "**" (two asterisks) as the called party number. So to dial + eg. the first registered DECT handset, give "**11" as the called party + number. Dialing "***" (three asterisks) calls all extensions + simultaneously (global call). + + This holds for both CAPI 2.0 and ISDN4Linux applications. Unimodem mode + does not support internal calls. + +2.8. Unregistered Wireless Devices (M101/M105) ----------------------------------------- The main purpose of the ser_gigaset and usb_gigaset drivers is to allow the M101 and M105 wireless devices to be used as ISDN devices for ISDN -- cgit v1.1 From d9bed6bbd4f2a0120c93fed68605950651e1f225 Mon Sep 17 00:00:00 2001 From: Tilman Schmidt Date: Mon, 5 Jul 2010 14:19:30 +0000 Subject: isdn/gigaset: remove EXPERIMENTAL tag from GIGASET_CAPI The CAPI variant of the Gigaset drivers can, in combination with capidrv, now fully replace the legacy ISDN4Linux variant. All reported problems have been fixed. So remove the EXPERIMENTAL tag from the Kconfig option selecting it, and adapt the documentation accordingly to encourage users to switch to it. Impact: documentation/status update, no functional change Signed-off-by: Tilman Schmidt Signed-off-by: David S. Miller --- Documentation/isdn/README.gigaset | 100 ++++++++++++++++++++------------------ 1 file changed, 53 insertions(+), 47 deletions(-) (limited to 'Documentation') diff --git a/Documentation/isdn/README.gigaset b/Documentation/isdn/README.gigaset index 702c046..ef3343e 100644 --- a/Documentation/isdn/README.gigaset +++ b/Documentation/isdn/README.gigaset @@ -47,9 +47,9 @@ GigaSet 307x Device Driver 1.2. Software -------- - The driver works with ISDN4linux and so can be used with any software - which is able to use ISDN4linux for ISDN connections (voice or data). - Experimental Kernel CAPI support is available as a compilation option. + The driver works with the Kernel CAPI subsystem as well as the old + ISDN4Linux subsystem, so it can be used with any software which is able + to use CAPI 2.0 or ISDN4Linux for ISDN connections (voice or data). There are some user space tools available at http://sourceforge.net/projects/gigaset307x/ @@ -152,61 +152,42 @@ GigaSet 307x Device Driver - GIGVER_FWBASE: retrieve the firmware version of the base Upon return, version[] is filled with the requested version information. -2.3. ISDN4linux - ---------- - This is the "normal" mode of operation. After loading the module you can - set up the ISDN system just as you'd do with any ISDN card supported by - the ISDN4Linux subsystem. Most distributions provide some configuration - utility. If not, you can use some HOWTOs like - http://www.linuxhaven.de/dlhp/HOWTO/DE-ISDN-HOWTO-5.html - If this doesn't work, because you have some device like SX100 where - debug output (see section 3.2.) shows something like this when dialing - CMD Received: ERROR - Available Params: 0 - Connection State: 0, Response: -1 - gigaset_process_response: resp_code -1 in ConState 0 ! - Timeout occurred - you probably need to use unimodem mode. (see section 2.5.) - -2.4. CAPI +2.3. CAPI ---- If the driver is compiled with CAPI support (kernel configuration option - GIGASET_CAPI, experimental) it can also be used with CAPI 2.0 kernel and - user space applications. For user space access, the module capi.ko must - be loaded. The capiinit command (included in the capi4k-utils package) - does this for you. - - The CAPI variant of the driver supports legacy ISDN4Linux applications - via the capidrv compatibility driver. The kernel module capidrv.ko must - be loaded explicitly with the command + GIGASET_CAPI) the devices will show up as CAPI controllers as soon as the + corresponding driver module is loaded, and can then be used with CAPI 2.0 + kernel and user space applications. For user space access, the module + capi.ko must be loaded. + + Legacy ISDN4Linux applications are supported via the capidrv + compatibility driver. The kernel module capidrv.ko must be loaded + explicitly with the command modprobe capidrv if needed, and cannot be unloaded again without unloading the driver first. (These are limitations of capidrv.) - The note about unimodem mode in the preceding section applies here, too. - -2.5. Unimodem mode - ------------- - This is needed for some devices [e.g. SX100] as they have problems with - the "normal" commands. + Most distributions handle loading and unloading of the various CAPI + modules automatically via the command capiinit(1) from the capi4k-utils + package or a similar mechanism. Note that capiinit(1) cannot unload the + Gigaset drivers because it doesn't support more than one module per + driver. - If you have installed the command line tool gigacontr, you can enter - unimodem mode using - gigacontr --mode unimodem - You can switch back using - gigacontr --mode isdn +2.4. ISDN4Linux + ---------- + If the driver is compiled without CAPI support (native ISDN4Linux + variant), it registers the device with the legacy ISDN4Linux subsystem + after loading the module. It can then be used with ISDN4Linux + applications only. Most distributions provide some configuration utility + for setting up that subsystem. Otherwise you can use some HOWTOs like + http://www.linuxhaven.de/dlhp/HOWTO/DE-ISDN-HOWTO-5.html - You can also put the driver directly into Unimodem mode when it's loaded, - by passing the module parameter startmode=0 to the hardware specific - module, e.g. - modprobe usb_gigaset startmode=0 - or by adding a line like - options usb_gigaset startmode=0 - to an appropriate module configuration file, like /etc/modprobe.d/gigaset - or /etc/modprobe.conf.local. +2.5. Unimodem mode + ------------- In this mode the device works like a modem connected to a serial port (the /dev/ttyGU0, ... mentioned above) which understands the commands + ATZ init, reset => OK or ERROR ATD @@ -234,6 +215,31 @@ GigaSet 307x Device Driver to an appropriate module configuration file, like /etc/modprobe.d/gigaset or /etc/modprobe.conf.local. + Unimodem mode is needed for making some devices [e.g. SX100] work which + do not support the regular Gigaset command set. If debug output (see + section 3.2.) shows something like this when dialing: + CMD Received: ERROR + Available Params: 0 + Connection State: 0, Response: -1 + gigaset_process_response: resp_code -1 in ConState 0 ! + Timeout occurred + then switching to unimodem mode may help. + + If you have installed the command line tool gigacontr, you can enter + unimodem mode using + gigacontr --mode unimodem + You can switch back using + gigacontr --mode isdn + + You can also put the driver directly into Unimodem mode when it's loaded, + by passing the module parameter startmode=0 to the hardware specific + module, e.g. + modprobe usb_gigaset startmode=0 + or by adding a line like + options usb_gigaset startmode=0 + to an appropriate module configuration file, like /etc/modprobe.d/gigaset + or /etc/modprobe.conf.local. + 2.6. Call-ID (CID) mode ------------------ Call-IDs are numbers used to tag commands to, and responses from, the -- cgit v1.1 From 54a3b8dc38d47834336400cbe376a3aca0437cae Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 8 Jul 2010 09:01:17 +0200 Subject: ALSA: Update documents about new bits of xrun_debug proc file Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/Procfile.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/Procfile.txt b/Documentation/sound/alsa/Procfile.txt index 07301de..7fcd1ad 100644 --- a/Documentation/sound/alsa/Procfile.txt +++ b/Documentation/sound/alsa/Procfile.txt @@ -103,6 +103,8 @@ card*/pcm*/xrun_debug bit 2 = Enable additional jiffies check bit 3 = Log hwptr update at each period interrupt bit 4 = Log hwptr update at each snd_pcm_update_hw_ptr() + bit 5 = Show last 10 positions on error + bit 6 = Do above only once When the bit 0 is set, the driver will show the messages to kernel log when an xrun is detected. The debug message is @@ -122,6 +124,12 @@ card*/pcm*/xrun_debug Bits 3 and 4 are for logging the hwptr records. Note that these will give flood of kernel messages. + When bit 5 is set, the driver logs the last 10 xrun errors and + the proc file shows each jiffies, position, period_size, + buffer_size, old_hw_ptr, and hw_ptr_base values. + + When bit 6 is set, the full xrun log is shown only once. + card*/pcm*/sub*/info The general information of this PCM sub-stream. -- cgit v1.1 From a6557737584457c8d202cb164585973e8d15a29c Mon Sep 17 00:00:00 2001 From: "Justin P. Mattock" Date: Sat, 3 Jul 2010 15:46:13 -0700 Subject: Documentation update broken web addresses I've found some web addresses not responding, giving the cannot connect error when trying to load them. The below patch updates the addresses that are not connecting with the best that I can find, and also fixes a couple of addresses, so people can either choose an older version of the package and/or a newer version(i.e. ppp). Signed-off-by: Justin P. Mattock Signed-off-by: Jiri Kosina --- Documentation/Changes | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/Changes b/Documentation/Changes index eca9f6e..4fb88f1 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -331,7 +331,7 @@ o Mkinitrd -------- -o +o E2fsprogs --------- @@ -343,11 +343,11 @@ o Reiserfsprogs ------------- -o +o Xfsprogs -------- -o +o Pcmciautils ----------- @@ -387,18 +387,18 @@ o mcelog ------ -o +o Networking ********** PPP --- -o +o Isdn4k-utils ------------ -o +o NFS-utils --------- -- cgit v1.1 From fa964e1aab51178d690d1c58d8b831eac434912f Mon Sep 17 00:00:00 2001 From: Kulikov Vasiliy Date: Sat, 10 Jul 2010 18:35:43 +0400 Subject: Documentation: pci.txt: fix typo Doubled 'not'. Signed-off-by: Kulikov Vasiliy Signed-off-by: Jiri Kosina --- Documentation/PCI/pci.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/PCI/pci.txt b/Documentation/PCI/pci.txt index 7f6de6e..6148d40 100644 --- a/Documentation/PCI/pci.txt +++ b/Documentation/PCI/pci.txt @@ -581,7 +581,7 @@ to be handled by platform and generic code, not individual drivers. 8. Vendor and device identifications ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -One is not not required to add new device ids to include/linux/pci_ids.h. +One is not required to add new device ids to include/linux/pci_ids.h. Please add PCI_VENDOR_ID_xxx for vendors and a hex constant for device ids. PCI_VENDOR_ID_xxx constants are re-used. The device ids are arbitrary -- cgit v1.1 From a7ce2e0d04b1a6ee8056e7fea5ea96566d33a6f4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= Date: Mon, 12 Jul 2010 17:15:44 +0200 Subject: fix comnment/printk typos concerning "empty" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Uwe Kleine-König Signed-off-by: Jiri Kosina --- Documentation/scsi/ChangeLog.lpfc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/scsi/ChangeLog.lpfc b/Documentation/scsi/ChangeLog.lpfc index e759e92..337c924 100644 --- a/Documentation/scsi/ChangeLog.lpfc +++ b/Documentation/scsi/ChangeLog.lpfc @@ -807,7 +807,7 @@ Changes from 20040908 to 20040920 lpfc_disc_done/lpfc_do_dpc cleanup - lpfc_disc_done can return void - move lpfc_do_dpc and lpfc_disc_done to lpfc_hbadisc.c - remove checking of list emptiness before calling lpfc_disc_done, - it handles the emtpy list case just fine and the additional + it handles the empty list case just fine and the additional instructions cost less then the bustlocked spinlock operations. * Integrated patch from Christoph Hellwig: This adds a new 64bit counter instead, brd_no isn't reused anymore. Also some tiny -- cgit v1.1 From 2197f9a16df9de94655992941d80953ba47042c2 Mon Sep 17 00:00:00 2001 From: Steffen Klassert Date: Wed, 7 Jul 2010 15:34:03 +0200 Subject: padata: update documentation This patch updates the padata documentation to the changed API of padata_start/padata_stop and padata_do parallel. Signed-off-by: Steffen Klassert Signed-off-by: Herbert Xu --- Documentation/padata.txt | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/padata.txt b/Documentation/padata.txt index 269d7d0d..93dd4e6 100644 --- a/Documentation/padata.txt +++ b/Documentation/padata.txt @@ -22,12 +22,15 @@ actually be done; it should be a multithreaded queue, naturally. There are functions for enabling and disabling the instance: - void padata_start(struct padata_instance *pinst); + int padata_start(struct padata_instance *pinst); void padata_stop(struct padata_instance *pinst); -These functions literally do nothing beyond setting or clearing the -"padata_start() was called" flag; if that flag is not set, other functions -will refuse to work. +These functions are setting or clearing the "PADATA_INIT" flag; +if that flag is not set, other functions will refuse to work. +padata_start returns zero on success (flag set) or -EINVAL if the +padata cpumask contains no active cpu (flag not set). +padata_stop clears the flag and blocks until the padata instance +is unused. The list of CPUs to be used can be adjusted with these functions: @@ -63,12 +66,10 @@ The submission of work is done with: The pinst and padata structures must be set up as described above; cb_cpu specifies which CPU will be used for the final callback when the work is done; it must be in the current instance's CPU mask. The return value from -padata_do_parallel() is a little strange; zero is an error return -indicating that the caller forgot the padata_start() formalities. -EBUSY -means that somebody, somewhere else is messing with the instance's CPU -mask, while -EINVAL is a complaint about cb_cpu not being in that CPU mask. -If all goes well, this function will return -EINPROGRESS, indicating that -the work is in progress. +padata_do_parallel() is zero on success, indicating that the work is in +progress. -EBUSY means that somebody, somewhere else is messing with the +instance's CPU mask, while -EINVAL is a complaint about cb_cpu not being +in that CPU mask or about a not running instance. Each task submitted to padata_do_parallel() will, in turn, be passed to exactly one call to the above-mentioned parallel() function, on one CPU, so -- cgit v1.1 From 72c8a94a585afea1f45aa8c4f6938ed6d05be57a Mon Sep 17 00:00:00 2001 From: Henrik Rydberg Date: Thu, 15 Jul 2010 23:22:07 -0700 Subject: Input: document the MT event slot protocol This patch adds documentation for the ABS_MT_SLOT event and gives examples of how to use the event slot protocol. Reviewed-by: Ping Cheng Signed-off-by: Henrik Rydberg Signed-off-by: Dmitry Torokhov --- Documentation/input/multi-touch-protocol.txt | 218 ++++++++++++++++++--------- 1 file changed, 149 insertions(+), 69 deletions(-) (limited to 'Documentation') diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt index c0fc1c7..bdcba154 100644 --- a/Documentation/input/multi-touch-protocol.txt +++ b/Documentation/input/multi-touch-protocol.txt @@ -6,31 +6,149 @@ Multi-touch (MT) Protocol Introduction ------------ -In order to utilize the full power of the new multi-touch devices, a way to -report detailed finger data to user space is needed. This document -describes the multi-touch (MT) protocol which allows kernel drivers to -report details for an arbitrary number of fingers. +In order to utilize the full power of the new multi-touch and multi-user +devices, a way to report detailed data from multiple contacts, i.e., +objects in direct contact with the device surface, is needed. This +document describes the multi-touch (MT) protocol which allows kernel +drivers to report details for an arbitrary number of contacts. + +The protocol is divided into two types, depending on the capabilities of the +hardware. For devices handling anonymous contacts (type A), the protocol +describes how to send the raw data for all contacts to the receiver. For +devices capable of tracking identifiable contacts (type B), the protocol +describes how to send updates for individual contacts via event slots. + + +Protocol Usage +-------------- + +Contact details are sent sequentially as separate packets of ABS_MT +events. Only the ABS_MT events are recognized as part of a contact +packet. Since these events are ignored by current single-touch (ST) +applications, the MT protocol can be implemented on top of the ST protocol +in an existing driver. + +Drivers for type A devices separate contact packets by calling +input_mt_sync() at the end of each packet. This generates a SYN_MT_REPORT +event, which instructs the receiver to accept the data for the current +contact and prepare to receive another. + +Drivers for type B devices separate contact packets by calling +input_mt_slot(), with a slot as argument, at the beginning of each packet. +This generates an ABS_MT_SLOT event, which instructs the receiver to +prepare for updates of the given slot. + +All drivers mark the end of a multi-touch transfer by calling the usual +input_sync() function. This instructs the receiver to act upon events +accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new set +of events/packets. + +The main difference between the stateless type A protocol and the stateful +type B slot protocol lies in the usage of identifiable contacts to reduce +the amount of data sent to userspace. The slot protocol requires the use of +the ABS_MT_TRACKING_ID, either provided by the hardware or computed from +the raw data [5]. + +For type A devices, the kernel driver should generate an arbitrary +enumeration of the full set of anonymous contacts currently on the +surface. The order in which the packets appear in the event stream is not +important. Event filtering and finger tracking is left to user space [3]. + +For type B devices, the kernel driver should associate a slot with each +identified contact, and use that slot to propagate changes for the contact. +Creation, replacement and destruction of contacts is achieved by modifying +the ABS_MT_TRACKING_ID of the associated slot. A non-negative tracking id +is interpreted as a contact, and the value -1 denotes an unused slot. A +tracking id not previously present is considered new, and a tracking id no +longer present is considered removed. Since only changes are propagated, +the full state of each initiated contact has to reside in the receiving +end. Upon receiving an MT event, one simply updates the appropriate +attribute of the current slot. + + +Protocol Example A +------------------ + +Here is what a minimal event sequence for a two-contact touch would look +like for a type A device: + + ABS_MT_POSITION_X x[0] + ABS_MT_POSITION_Y y[0] + SYN_MT_REPORT + ABS_MT_POSITION_X x[1] + ABS_MT_POSITION_Y y[1] + SYN_MT_REPORT + SYN_REPORT +The sequence after moving one of the contacts looks exactly the same; the +raw data for all present contacts are sent between every synchronization +with SYN_REPORT. -Usage ------ +Here is the sequence after lifting the first contact: + + ABS_MT_POSITION_X x[1] + ABS_MT_POSITION_Y y[1] + SYN_MT_REPORT + SYN_REPORT + +And here is the sequence after lifting the second contact: + + SYN_MT_REPORT + SYN_REPORT + +If the driver reports one of BTN_TOUCH or ABS_PRESSURE in addition to the +ABS_MT events, the last SYN_MT_REPORT event may be omitted. Otherwise, the +last SYN_REPORT will be dropped by the input core, resulting in no +zero-contact event reaching userland. -Anonymous finger details are sent sequentially as separate packets of ABS -events. Only the ABS_MT events are recognized as part of a finger -packet. The end of a packet is marked by calling the input_mt_sync() -function, which generates a SYN_MT_REPORT event. This instructs the -receiver to accept the data for the current finger and prepare to receive -another. The end of a multi-touch transfer is marked by calling the usual -input_sync() function. This instructs the receiver to act upon events -accumulated since last EV_SYN/SYN_REPORT and prepare to receive a new -set of events/packets. + +Protocol Example B +------------------ + +Here is what a minimal event sequence for a two-contact touch would look +like for a type B device: + + ABS_MT_SLOT 0 + ABS_MT_TRACKING_ID 45 + ABS_MT_POSITION_X x[0] + ABS_MT_POSITION_Y y[0] + ABS_MT_SLOT 1 + ABS_MT_TRACKING_ID 46 + ABS_MT_POSITION_X x[1] + ABS_MT_POSITION_Y y[1] + SYN_REPORT + +Here is the sequence after moving contact 45 in the x direction: + + ABS_MT_SLOT 0 + ABS_MT_POSITION_X x[0] + SYN_REPORT + +Here is the sequence after lifting the contact in slot 0: + + ABS_MT_TRACKING_ID -1 + SYN_REPORT + +The slot being modified is already 0, so the ABS_MT_SLOT is omitted. The +message removes the association of slot 0 with contact 45, thereby +destroying contact 45 and freeing slot 0 to be reused for another contact. + +Finally, here is the sequence after lifting the second contact: + + ABS_MT_SLOT 1 + ABS_MT_TRACKING_ID -1 + SYN_REPORT + + +Event Usage +----------- A set of ABS_MT events with the desired properties is defined. The events are divided into categories, to allow for partial implementation. The minimum set consists of ABS_MT_POSITION_X and ABS_MT_POSITION_Y, which -allows for multiple fingers to be tracked. If the device supports it, the +allows for multiple contacts to be tracked. If the device supports it, the ABS_MT_TOUCH_MAJOR and ABS_MT_WIDTH_MAJOR may be used to provide the size -of the contact area and approaching finger, respectively. +of the contact area and approaching contact, respectively. The TOUCH and WIDTH parameters have a geometrical interpretation; imagine looking through a window at someone gently holding a finger against the @@ -41,56 +159,26 @@ ABS_MT_TOUCH_MAJOR, the diameter of the outer region is ABS_MT_WIDTH_MAJOR. Now imagine the person pressing the finger harder against the glass. The inner region will increase, and in general, the ratio ABS_MT_TOUCH_MAJOR / ABS_MT_WIDTH_MAJOR, which is always smaller than -unity, is related to the finger pressure. For pressure-based devices, +unity, is related to the contact pressure. For pressure-based devices, ABS_MT_PRESSURE may be used to provide the pressure on the contact area instead. -In addition to the MAJOR parameters, the oval shape of the finger can be +In addition to the MAJOR parameters, the oval shape of the contact can be described by adding the MINOR parameters, such that MAJOR and MINOR are the major and minor axis of an ellipse. Finally, the orientation of the oval shape can be describe with the ORIENTATION parameter. The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a -finger or a pen or something else. Devices with more granular information +contact or a pen or something else. Devices with more granular information may specify general shapes as blobs, i.e., as a sequence of rectangular shapes grouped together by an ABS_MT_BLOB_ID. Finally, for the few devices that currently support it, the ABS_MT_TRACKING_ID event may be used to -report finger tracking from hardware [5]. +report contact tracking from hardware [5]. -Here is what a minimal event sequence for a two-finger touch would look -like: - - ABS_MT_POSITION_X - ABS_MT_POSITION_Y - SYN_MT_REPORT - ABS_MT_POSITION_X - ABS_MT_POSITION_Y - SYN_MT_REPORT - SYN_REPORT - -Here is the sequence after lifting one of the fingers: - - ABS_MT_POSITION_X - ABS_MT_POSITION_Y - SYN_MT_REPORT - SYN_REPORT - -And here is the sequence after lifting the remaining finger: - - SYN_MT_REPORT - SYN_REPORT - -If the driver reports one of BTN_TOUCH or ABS_PRESSURE in addition to the -ABS_MT events, the last SYN_MT_REPORT event may be omitted. Otherwise, the -last SYN_REPORT will be dropped by the input core, resulting in no -zero-finger event reaching userland. Event Semantics --------------- -The word "contact" is used to describe a tool which is in direct contact -with the surface. A finger, a pen or a rubber all classify as contacts. - ABS_MT_TOUCH_MAJOR The length of the major axis of the contact. The length should be given in @@ -157,15 +245,16 @@ MT_TOOL_PEN [2]. ABS_MT_BLOB_ID The BLOB_ID groups several packets together into one arbitrarily shaped -contact. This is a low-level anonymous grouping, and should not be confused -with the high-level trackingID [5]. Most kernel drivers will not have blob -capability, and can safely omit the event. +contact. This is a low-level anonymous grouping for type A devices, and +should not be confused with the high-level trackingID [5]. Most type A +devices do not have blob capability, so drivers can safely omit this event. ABS_MT_TRACKING_ID The TRACKING_ID identifies an initiated contact throughout its life cycle -[5]. There are currently only a few devices that support it, so this event -should normally be omitted. +[5]. This event is mandatory for type B devices. The value range of the +TRACKING_ID should be large enough to ensure unique identification of a +contact maintained over an extended period of time. Event Computation @@ -192,20 +281,11 @@ finger along the X axis (1). Finger Tracking --------------- -The kernel driver should generate an arbitrary enumeration of the set of -anonymous contacts currently on the surface. The order in which the packets -appear in the event stream is not important. - The process of finger tracking, i.e., to assign a unique trackingID to each -initiated contact on the surface, is left to user space; preferably the -multi-touch X driver [3]. In that driver, the trackingID stays the same and -unique until the contact vanishes (when the finger leaves the surface). The -problem of assigning a set of anonymous fingers to a set of identified -fingers is a euclidian bipartite matching problem at each event update, and -relies on a sufficiently rapid update rate. - -There are a few devices that support trackingID in hardware. User space can -make use of these native identifiers to reduce bandwidth and cpu usage. +initiated contact on the surface, is a Euclidian Bipartite Matching +problem. At each event synchronization, the set of actual contacts is +matched to the set of contacts from the previous synchronization. A full +implementation can be found in [3]. Gestures -- cgit v1.1 From c125e96f044427f38d106fab7bc5e4a5e6a18262 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Mon, 5 Jul 2010 22:43:53 +0200 Subject: PM: Make it possible to avoid races between wakeup and system sleep One of the arguments during the suspend blockers discussion was that the mainline kernel didn't contain any mechanisms making it possible to avoid races between wakeup and system suspend. Generally, there are two problems in that area. First, if a wakeup event occurs exactly when /sys/power/state is being written to, it may be delivered to user space right before the freezer kicks in, so the user space consumer of the event may not be able to process it before the system is suspended. Second, if a wakeup event occurs after user space has been frozen, it is not generally guaranteed that the ongoing transition of the system into a sleep state will be aborted. To address these issues introduce a new global sysfs attribute, /sys/power/wakeup_count, associated with a running counter of wakeup events and three helper functions, pm_stay_awake(), pm_relax(), and pm_wakeup_event(), that may be used by kernel subsystems to control the behavior of this attribute and to request the PM core to abort system transitions into a sleep state already in progress. The /sys/power/wakeup_count file may be read from or written to by user space. Reads will always succeed (unless interrupted by a signal) and return the current value of the wakeup events counter. Writes, however, will only succeed if the written number is equal to the current value of the wakeup events counter. If a write is successful, it will cause the kernel to save the current value of the wakeup events counter and to abort the subsequent system transition into a sleep state if any wakeup events are reported after the write has returned. [The assumption is that before writing to /sys/power/state user space will first read from /sys/power/wakeup_count. Next, user space consumers of wakeup events will have a chance to acknowledge or veto the upcoming system transition to a sleep state. Finally, if the transition is allowed to proceed, /sys/power/wakeup_count will be written to and if that succeeds, /sys/power/state will be written to as well. Still, if any wakeup events are reported to the PM core by kernel subsystems after that point, the transition will be aborted.] Additionally, put a wakeup events counter into struct dev_pm_info and make these per-device wakeup event counters available via sysfs, so that it's possible to check the activity of various wakeup event sources within the kernel. To illustrate how subsystems can use pm_wakeup_event(), make the low-level PCI runtime PM wakeup-handling code use it. Signed-off-by: Rafael J. Wysocki Acked-by: Jesse Barnes Acked-by: Greg Kroah-Hartman Acked-by: markgross Reviewed-by: Alan Stern --- Documentation/ABI/testing/sysfs-power | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index d6a801f..2875f1f 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -114,3 +114,18 @@ Description: if this file contains "1", which is the default. It may be disabled by writing "0" to this file, in which case all devices will be suspended and resumed synchronously. + +What: /sys/power/wakeup_count +Date: July 2010 +Contact: Rafael J. Wysocki +Description: + The /sys/power/wakeup_count file allows user space to put the + system into a sleep state while taking into account the + concurrent arrival of wakeup events. Reading from it returns + the current number of registered wakeup events and it blocks if + some wakeup events are being processed at the time the file is + read from. Writing to it will only succeed if the current + number of wakeup events is equal to the written value and, if + successful, will make the kernel abort a subsequent transition + to a sleep state if any wakeup events are reported after the + write has returned. -- cgit v1.1 From a2531293dbb7608fa672ff28efe3ab4027917a2f Mon Sep 17 00:00:00 2001 From: Pavel Machek Date: Sun, 18 Jul 2010 14:27:13 +0200 Subject: update email address pavel@suse.cz no longer works, replace it with working address. Signed-off-by: Pavel Machek Signed-off-by: Jiri Kosina --- Documentation/feature-removal-schedule.txt | 2 +- Documentation/hwmon/hpfall.c | 2 +- Documentation/power/tricks.txt | 2 +- Documentation/sparse.txt | 2 +- Documentation/zh_CN/sparse.txt | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index c268783..1a0fc32 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -93,7 +93,7 @@ Why: Broken design for runtime control over driver power states, confusing inputs. This framework was never widely used, and most attempts to use it were broken. Drivers should instead be exposing domain-specific interfaces either to kernel or to userspace. -Who: Pavel Machek +Who: Pavel Machek --------------------------- diff --git a/Documentation/hwmon/hpfall.c b/Documentation/hwmon/hpfall.c index 681ec22..a4a8fc5 100644 --- a/Documentation/hwmon/hpfall.c +++ b/Documentation/hwmon/hpfall.c @@ -1,7 +1,7 @@ /* Disk protection for HP machines. * * Copyright 2008 Eric Piel - * Copyright 2009 Pavel Machek + * Copyright 2009 Pavel Machek * * GPLv2. */ diff --git a/Documentation/power/tricks.txt b/Documentation/power/tricks.txt index 3b26bb5..a1b8f72 100644 --- a/Documentation/power/tricks.txt +++ b/Documentation/power/tricks.txt @@ -1,6 +1,6 @@ swsusp/S3 tricks ~~~~~~~~~~~~~~~~ -Pavel Machek +Pavel Machek If you want to trick swsusp/S3 into working, you might want to try: diff --git a/Documentation/sparse.txt b/Documentation/sparse.txt index 9b659c7..4909d41 100644 --- a/Documentation/sparse.txt +++ b/Documentation/sparse.txt @@ -1,5 +1,5 @@ Copyright 2004 Linus Torvalds -Copyright 2004 Pavel Machek +Copyright 2004 Pavel Machek Copyright 2006 Bob Copeland Using sparse for typechecking diff --git a/Documentation/zh_CN/sparse.txt b/Documentation/zh_CN/sparse.txt index 75992a6..cc144e5 100644 --- a/Documentation/zh_CN/sparse.txt +++ b/Documentation/zh_CN/sparse.txt @@ -22,7 +22,7 @@ Documentation/sparse.txt 的中文翻译 --------------------------------------------------------------------- Copyright 2004 Linus Torvalds -Copyright 2004 Pavel Machek +Copyright 2004 Pavel Machek Copyright 2006 Bob Copeland 使用 sparse 工具做类型检查 -- cgit v1.1 From 9849ed4d72251d273524efb8b70be0be9aecb1df Mon Sep 17 00:00:00 2001 From: Mike Frysinger Date: Tue, 20 Jul 2010 03:13:35 -0400 Subject: tracing/documentation: Document dynamic ftracer internals Add more details to the dynamic function tracing design implementation. Signed-off-by: Mike Frysinger LKML-Reference: <1279610015-10250-1-git-send-email-vapier@gentoo.org> Signed-off-by: Steven Rostedt --- Documentation/trace/ftrace-design.txt | 153 ++++++++++++++++++++++++++++++++-- 1 file changed, 148 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/trace/ftrace-design.txt b/Documentation/trace/ftrace-design.txt index f1f81af..dc52bd4 100644 --- a/Documentation/trace/ftrace-design.txt +++ b/Documentation/trace/ftrace-design.txt @@ -13,6 +13,9 @@ Note that this focuses on architecture implementation details only. If you want more explanation of a feature in terms of common code, review the common ftrace.txt file. +Ideally, everyone who wishes to retain performance while supporting tracing in +their kernel should make it all the way to dynamic ftrace support. + Prerequisites ------------- @@ -215,7 +218,7 @@ An arch may pass in a unique value (frame pointer) to both the entering and exiting of a function. On exit, the value is compared and if it does not match, then it will panic the kernel. This is largely a sanity check for bad code generation with gcc. If gcc for your port sanely updates the frame -pointer under different opitmization levels, then ignore this option. +pointer under different optimization levels, then ignore this option. However, adding support for it isn't terribly difficult. In your assembly code that calls prepare_ftrace_return(), pass the frame pointer as the 3rd argument. @@ -234,7 +237,7 @@ If you can't trace NMI functions, then skip this option. HAVE_SYSCALL_TRACEPOINTS ---------------------- +------------------------ You need very few things to get the syscalls tracing in an arch. @@ -250,12 +253,152 @@ You need very few things to get the syscalls tracing in an arch. HAVE_FTRACE_MCOUNT_RECORD ------------------------- -See scripts/recordmcount.pl for more info. +See scripts/recordmcount.pl for more info. Just fill in the arch-specific +details for how to locate the addresses of mcount call sites via objdump. +This option doesn't make much sense without also implementing dynamic ftrace. + +HAVE_DYNAMIC_FTRACE +------------------- + +You will first need HAVE_FTRACE_MCOUNT_RECORD and HAVE_FUNCTION_TRACER, so +scroll your reader back up if you got over eager. + +Once those are out of the way, you will need to implement: + - asm/ftrace.h: + - MCOUNT_ADDR + - ftrace_call_adjust() + - struct dyn_arch_ftrace{} + - asm code: + - mcount() (new stub) + - ftrace_caller() + - ftrace_call() + - ftrace_stub() + - C code: + - ftrace_dyn_arch_init() + - ftrace_make_nop() + - ftrace_make_call() + - ftrace_update_ftrace_func() + +First you will need to fill out some arch details in your asm/ftrace.h. + +Define MCOUNT_ADDR as the address of your mcount symbol similar to: + #define MCOUNT_ADDR ((unsigned long)mcount) +Since no one else will have a decl for that function, you will need to: + extern void mcount(void); + +You will also need the helper function ftrace_call_adjust(). Most people +will be able to stub it out like so: + static inline unsigned long ftrace_call_adjust(unsigned long addr) + { + return addr; + }
+Lastly you will need the custom dyn_arch_ftrace structure. If you need +some extra state when runtime patching arbitrary call sites, this is the +place. For now though, create an empty struct: + struct dyn_arch_ftrace { + /* No extra data needed */ + }; + +With the header out of the way, we can fill out the assembly code. While we +did already create a mcount() function earlier, dynamic ftrace only wants a +stub function. This is because the mcount() will only be used during boot +and then all references to it will be patched out never to return. Instead, +the guts of the old mcount() will be used to create a new ftrace_caller() +function. Because the two are hard to merge, it will most likely be a lot +easier to have two separate definitions split up by #ifdefs. Same goes for +the ftrace_stub() as that will now be inlined in ftrace_caller(). + +Before we get confused anymore, let's check out some pseudo code so you can +implement your own stuff in assembly: -HAVE_DYNAMIC_FTRACE ---------------------- +void mcount(void) +{ + return; +} + +void ftrace_caller(void) +{ + /* implement HAVE_FUNCTION_TRACE_MCOUNT_TEST if you desire */ + + /* save all state needed by the ABI (see paragraph above) */ + + unsigned long frompc = ...; + unsigned long selfpc = - MCOUNT_INSN_SIZE; + +ftrace_call: + ftrace_stub(frompc, selfpc); + + /* restore all state needed by the ABI */ + +ftrace_stub: + return; +} + +This might look a little odd at first, but keep in mind that we will be runtime +patching multiple things. First, only functions that we actually want to trace +will be patched to call ftrace_caller(). Second, since we only have one tracer +active at a time, we will patch the ftrace_caller() function itself to call the +specific tracer in question. That is the point of the ftrace_call label. + +With that in mind, let's move on to the C code that will actually be doing the +runtime patching. You'll need a little knowledge of your arch's opcodes in +order to make it through the next section. + +Every arch has an init callback function. If you need to do something early on +to initialize some state, this is the time to do that. Otherwise, this simple +function below should be sufficient for most people: + +int __init ftrace_dyn_arch_init(void *data) +{ + /* return value is done indirectly via data */ + *(unsigned long *)data = 0; + + return 0; +} + +There are two functions that are used to do runtime patching of arbitrary +functions. The first is used to turn the mcount call site into a nop (which +is what helps us retain runtime performance when not tracing). The second is +used to turn the mcount call site into a call to an arbitrary location (but +typically that is ftracer_caller()). See the general function definition in +linux/ftrace.h for the functions: + ftrace_make_nop() + ftrace_make_call() +The rec->ip value is the address of the mcount call site that was collected +by the scripts/recordmcount.pl during build time. + +The last function is used to do runtime patching of the active tracer. This +will be modifying the assembly code at the location of the ftrace_call symbol +inside of the ftrace_caller() function. So you should have sufficient padding +at that location to support the new function calls you'll be inserting. Some +people will be using a "call" type instruction while others will be using a +"branch" type instruction. Specifically, the function is: + ftrace_update_ftrace_func() + + +HAVE_DYNAMIC_FTRACE + HAVE_FUNCTION_GRAPH_TRACER +------------------------------------------------ + +The function grapher needs a few tweaks in order to work with dynamic ftrace. +Basically, you will need to: + - update: + - ftrace_caller() + - ftrace_graph_call() + - ftrace_graph_caller() + - implement: + - ftrace_enable_ftrace_graph_caller() + - ftrace_disable_ftrace_graph_caller()
+Quick notes: + - add a nop stub after the ftrace_call location named ftrace_graph_call; + stub needs to be large enough to support a call to ftrace_graph_caller() + - update ftrace_graph_caller() to work with being called by the new + ftrace_caller() since some semantics may have changed + - ftrace_enable_ftrace_graph_caller() will runtime patch the + ftrace_graph_call location with a call to ftrace_graph_caller() + - ftrace_disable_ftrace_graph_caller() will runtime patch the + ftrace_graph_call location with nops -- cgit v1.1 From 8b8edefa2fffbff97f9eec8b70e78ae23abad1a0 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Tue, 20 Jul 2010 22:09:01 +0200 Subject: fscache: convert object to use workqueue instead of slow-work Make fscache object state transition callbacks use workqueue instead of slow-work. New dedicated unbound CPU workqueue fscache_object_wq is created. get/put callbacks are renamed and modified to take @object and called directly from the enqueue wrapper and the work function. While at it, make all open coded instances of get/put to use fscache_get/put_object(). * Unbound workqueue is used. * work_busy() output is printed instead of slow-work flags in object debugging outputs. They mean basically the same thing bit-for-bit. * sysctl fscache.object_max_active added to control concurrency. The default value is nr_cpus clamped between 4 and WQ_UNBOUND_MAX_ACTIVE. * slow_work_sleep_till_thread_needed() is replaced with fscache private implementation fscache_object_sleep_till_congested() which waits on fscache_object_wq congestion. * debugfs support is dropped for now. Tracing API based debug facility is planned to be added. Signed-off-by: Tejun Heo Acked-by: David Howells --- Documentation/filesystems/caching/fscache.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/caching/fscache.txt b/Documentation/filesystems/caching/fscache.txt index a91e2e2..770267a 100644 --- a/Documentation/filesystems/caching/fscache.txt +++ b/Documentation/filesystems/caching/fscache.txt @@ -343,8 +343,8 @@ This will look something like: [root@andromeda ~]# head /proc/fs/fscache/objects OBJECT PARENT STAT CHLDN OPS OOP IPR EX READS EM EV F S | NETFS_COOKIE_DEF TY FL NETFS_DATA OBJECT_KEY, AUX_DATA ======== ======== ==== ===== === === === == ===== == == = = | ================ == == ================ ================ - 17e4b 2 ACTV 0 0 0 0 0 0 7b 4 0 8 | NFS.fh DT 0 ffff88001dd82820 010006017edcf8bbc93b43298fdfbe71e50b57b13a172c0117f38472, e567634700000000000000000000000063f2404a000000000000000000000000c9030000000000000000000063f2404a - 1693a 2 ACTV 0 0 0 0 0 0 7b 4 0 8 | NFS.fh DT 0 ffff88002db23380 010006017edcf8bbc93b43298fdfbe71e50b57b1e0162c01a2df0ea6, 420ebc4a000000000000000000000000420ebc4a0000000000000000000000000e1801000000000000000000420ebc4a + 17e4b 2 ACTV 0 0 0 0 0 0 7b 4 0 0 | NFS.fh DT 0 ffff88001dd82820 010006017edcf8bbc93b43298fdfbe71e50b57b13a172c0117f38472, e567634700000000000000000000000063f2404a000000000000000000000000c9030000000000000000000063f2404a + 1693a 2 ACTV 0 0 0 0 0 0 7b 4 0 0 | NFS.fh DT 0 ffff88002db23380 010006017edcf8bbc93b43298fdfbe71e50b57b1e0162c01a2df0ea6, 420ebc4a000000000000000000000000420ebc4a0000000000000000000000000e1801000000000000000000420ebc4a where the first set of columns before the '|' describe the object: @@ -362,7 +362,7 @@ where the first set of columns before the '|' describe the object: EM Object's event mask EV Events raised on this object F Object flags - S Object slow-work work item flags + S Object work item busy state mask (1:pending 2:running) and the second set of columns describe the object's cookie, if present: @@ -395,8 +395,8 @@ and the following paired letters: w Show objects that don't have pending writes R Show objects that have outstanding reads r Show objects that don't have outstanding reads - S Show objects that have slow work queued - s Show objects that don't have slow work queued + S Show objects that have work queued + s Show objects that don't have work queued If neither side of a letter pair is given, then both are implied. For example: -- cgit v1.1 From 773bc4f3b6898634a80a41c72a1f34cb89992dcd Mon Sep 17 00:00:00 2001 From: Ryusuke Konishi Date: Mon, 5 Jul 2010 13:00:08 +0900 Subject: nilfs2: add barrier mount option Nilfs enables write barriers by default and has "nobarrier" mount option to disable this feature. But it lacks the complementary option and has no way to re-enable the feature on remount. This adds "barrier" option to resolve this imbalance. Signed-off-by: Ryusuke Konishi --- Documentation/filesystems/nilfs2.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/nilfs2.txt b/Documentation/filesystems/nilfs2.txt index d3e7673..54f61c0 100644 --- a/Documentation/filesystems/nilfs2.txt +++ b/Documentation/filesystems/nilfs2.txt @@ -49,7 +49,10 @@ Mount options NILFS2 supports the following mount options: (*) == default -nobarrier Disables barriers. +barrier(*) This enables/disables the use of write barriers. This +nobarrier requires an IO stack which can support barriers, and + if nilfs gets an error on a barrier write, it will + disable again with a warning. errors=continue Keep going on a filesystem error. errors=remount-ro(*) Remount the filesystem read-only on an error. errors=panic Panic and halt the machine if an error occurs. -- cgit v1.1 From 802d31775404ee335ca1e97a82e1e706a4c843be Mon Sep 17 00:00:00 2001 From: Ryusuke Konishi Date: Mon, 5 Jul 2010 14:27:04 +0900 Subject: nilfs2: add nodiscard mount option Nilfs has "discard" mount option which issues discard/TRIM commands to underlying block device, but it lacks a complementary option and has no way to disable the feature through remount. This adds "nodiscard" option to resolve this imbalance. Signed-off-by: Ryusuke Konishi --- Documentation/filesystems/nilfs2.txt | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/nilfs2.txt b/Documentation/filesystems/nilfs2.txt index 54f61c0..d5c0cef 100644 --- a/Documentation/filesystems/nilfs2.txt +++ b/Documentation/filesystems/nilfs2.txt @@ -77,9 +77,10 @@ norecovery Disable recovery of the filesystem on mount. This disables every write access on the device for read-only mounts or snapshots. This option will fail for r/w mounts on an unclean volume. -discard Issue discard/TRIM commands to the underlying block - device when blocks are freed. This is useful for SSD - devices and sparse/thinly-provisioned LUNs. +discard This enables/disables the use of discard/TRIM commands. +nodiscard(*) The discard/TRIM commands are sent to the underlying + block device when blocks are freed. This is useful + for SSD devices and sparse/thinly-provisioned LUNs. NILFS2 usage ============ -- cgit v1.1 From 181a51f6e040d0ac006d6adaf4a031ffa440f41c Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Tue, 20 Jul 2010 22:09:02 +0200 Subject: slow-work: kill it slow-work doesn't have any user left. Kill it. Signed-off-by: Tejun Heo Acked-by: David Howells --- Documentation/slow-work.txt | 322 -------------------------------------------- 1 file changed, 322 deletions(-) delete mode 100644 Documentation/slow-work.txt (limited to 'Documentation') diff --git a/Documentation/slow-work.txt b/Documentation/slow-work.txt deleted file mode 100644 index 9dbf4470c..0000000 --- a/Documentation/slow-work.txt +++ /dev/null @@ -1,322 +0,0 @@ - ==================================== - SLOW WORK ITEM EXECUTION THREAD POOL - ==================================== - -By: David Howells - -The slow work item execution thread pool is a pool of threads for performing -things that take a relatively long time, such as making mkdir calls. -Typically, when processing something, these items will spend a lot of time -blocking a thread on I/O, thus making that thread unavailable for doing other -work. - -The standard workqueue model is unsuitable for this class of work item as that -limits the owner to a single thread or a single thread per CPU. For some -tasks, however, more threads - or fewer - are required. - -There is just one pool per system. It contains no threads unless something -wants to use it - and that something must register its interest first. When -the pool is active, the number of threads it contains is dynamic, varying -between a maximum and minimum setting, depending on the load. - - -==================== -CLASSES OF WORK ITEM -==================== - -This pool support two classes of work items: - - (*) Slow work items. - - (*) Very slow work items. - -The former are expected to finish much quicker than the latter. - -An operation of the very slow class may do a batch combination of several -lookups, mkdirs, and a create for instance. - -An operation of the ordinarily slow class may, for example, write stuff or -expand files, provided the time taken to do so isn't too long. - -Operations of both types may sleep during execution, thus tying up the thread -loaned to it. - -A further class of work item is available, based on the slow work item class: - - (*) Delayed slow work items. - -These are slow work items that have a timer to defer queueing of the item for -a while. - - -THREAD-TO-CLASS ALLOCATION --------------------------- - -Not all the threads in the pool are available to work on very slow work items. -The number will be between one and one fewer than the number of active threads. -This is configurable (see the "Pool Configuration" section). - -All the threads are available to work on ordinarily slow work items, but a -percentage of the threads will prefer to work on very slow work items. - -The configuration ensures that at least one thread will be available to work on -very slow work items, and at least one thread will be available that won't work -on very slow work items at all. - - -===================== -USING SLOW WORK ITEMS -===================== - -Firstly, a module or subsystem wanting to make use of slow work items must -register its interest: - - int ret = slow_work_register_user(struct module *module); - -This will return 0 if successful, or a -ve error upon failure. The module -pointer should be the module interested in using this facility (almost -certainly THIS_MODULE). - - -Slow work items may then be set up by: - - (1) Declaring a slow_work struct type variable: - - #include - - struct slow_work myitem; - - (2) Declaring the operations to be used for this item: - - struct slow_work_ops myitem_ops = { - .get_ref = myitem_get_ref, - .put_ref = myitem_put_ref, - .execute = myitem_execute, - }; - - [*] For a description of the ops, see section "Item Operations". - - (3) Initialising the item: - - slow_work_init(&myitem, &myitem_ops); - - or: - - delayed_slow_work_init(&myitem, &myitem_ops); - - or: - - vslow_work_init(&myitem, &myitem_ops); - - depending on its class. - -A suitably set up work item can then be enqueued for processing: - - int ret = slow_work_enqueue(&myitem); - -This will return a -ve error if the thread pool is unable to gain a reference -on the item, 0 otherwise, or (for delayed work): - - int ret = delayed_slow_work_enqueue(&myitem, my_jiffy_delay); - - -The items are reference counted, so there ought to be no need for a flush -operation. But as the reference counting is optional, means to cancel -existing work items are also included: - - cancel_slow_work(&myitem); - cancel_delayed_slow_work(&myitem); - -can be used to cancel pending work. The above cancel function waits for -existing work to have been executed (or prevent execution of them, depending -on timing). - - -When all a module's slow work items have been processed, and the -module has no further interest in the facility, it should unregister its -interest: - - slow_work_unregister_user(struct module *module); - -The module pointer is used to wait for all outstanding work items for that -module before completing the unregistration. This prevents the put_ref() code -from being taken away before it completes. module should almost certainly be -THIS_MODULE. - - -================ -HELPER FUNCTIONS -================ - -The slow-work facility provides a function by which it can be determined -whether or not an item is queued for later execution: - - bool queued = slow_work_is_queued(struct slow_work *work); - -If it returns false, then the item is not on the queue (it may be executing -with a requeue pending). This can be used to work out whether an item on which -another depends is on the queue, thus allowing a dependent item to be queued -after it. - -If the above shows an item on which another depends not to be queued, then the -owner of the dependent item might need to wait. However, to avoid locking up -the threads unnecessarily be sleeping in them, it can make sense under some -circumstances to return the work item to the queue, thus deferring it until -some other items have had a chance to make use of the yielded thread. - -To yield a thread and defer an item, the work function should simply enqueue -the work item again and return. However, this doesn't work if there's nothing -actually on the queue, as the thread just vacated will jump straight back into -the item's work function, thus busy waiting on a CPU. - -Instead, the item should use the thread to wait for the dependency to go away, -but rather than using schedule() or schedule_timeout() to sleep, it should use -the following function: - - bool requeue = slow_work_sleep_till_thread_needed( - struct slow_work *work, - signed long *_timeout); - -This will add a second wait and then sleep, such that it will be woken up if -either something appears on the queue that could usefully make use of the -thread - and behind which this item can be queued, or if the event the caller -set up to wait for happens. True will be returned if something else appeared -on the queue and this work function should perhaps return, of false if -something else woke it up. The timeout is as for schedule_timeout(). - -For example: - - wq = bit_waitqueue(&my_flags, MY_BIT); - init_wait(&wait); - requeue = false; - do { - prepare_to_wait(wq, &wait, TASK_UNINTERRUPTIBLE); - if (!test_bit(MY_BIT, &my_flags)) - break; - requeue = slow_work_sleep_till_thread_needed(&my_work, - &timeout); - } while (timeout > 0 && !requeue); - finish_wait(wq, &wait); - if (!test_bit(MY_BIT, &my_flags) - goto do_my_thing; - if (requeue) - return; // to slow_work - - -=============== -ITEM OPERATIONS -=============== - -Each work item requires a table of operations of type struct slow_work_ops. -Only ->execute() is required; the getting and putting of a reference and the -describing of an item are all optional. - - (*) Get a reference on an item: - - int (*get_ref)(struct slow_work *work); - - This allows the thread pool to attempt to pin an item by getting a - reference on it. This function should return 0 if the reference was - granted, or a -ve error otherwise. If an error is returned, - slow_work_enqueue() will fail. - - The reference is held whilst the item is queued and whilst it is being - executed. The item may then be requeued with the same reference held, or - the reference will be released. - - (*) Release a reference on an item: - - void (*put_ref)(struct slow_work *work); - - This allows the thread pool to unpin an item by releasing the reference on - it. The thread pool will not touch the item again once this has been - called. - - (*) Execute an item: - - void (*execute)(struct slow_work *work); - - This should perform the work required of the item. It may sleep, it may - perform disk I/O and it may wait for locks. - - (*) View an item through /proc: - - void (*desc)(struct slow_work *work, struct seq_file *m); - - If supplied, this should print to 'm' a small string describing the work - the item is to do. This should be no more than about 40 characters, and - shouldn't include a newline character. - - See the 'Viewing executing and queued items' section below. - - -================== -POOL CONFIGURATION -================== - -The slow-work thread pool has a number of configurables: - - (*) /proc/sys/kernel/slow-work/min-threads - - The minimum number of threads that should be in the pool whilst it is in - use. This may be anywhere between 2 and max-threads. - - (*) /proc/sys/kernel/slow-work/max-threads - - The maximum number of threads that should in the pool. This may be - anywhere between min-threads and 255 or NR_CPUS * 2, whichever is greater. - - (*) /proc/sys/kernel/slow-work/vslow-percentage - - The percentage of active threads in the pool that may be used to execute - very slow work items. This may be between 1 and 99. The resultant number - is bounded to between 1 and one fewer than the number of active threads. - This ensures there is always at least one thread that can process very - slow work items, and always at least one thread that won't. - - -================================== -VIEWING EXECUTING AND QUEUED ITEMS -================================== - -If CONFIG_SLOW_WORK_DEBUG is enabled, a debugfs file is made available: - - /sys/kernel/debug/slow_work/runqueue - -through which the list of work items being executed and the queues of items to -be executed may be viewed. The owner of a work item is given the chance to -add some information of its own. - -The contents look something like the following: - - THR PID ITEM ADDR FL MARK DESC - === ===== ================ == ===== ========== - 0 3005 ffff880023f52348 a 952ms FSC: OBJ17d3: LOOK - 1 3006 ffff880024e33668 2 160ms FSC: OBJ17e5 OP60d3b: Write1/Store fl=2 - 2 3165 ffff8800296dd180 a 424ms FSC: OBJ17e4: LOOK - 3 4089 ffff8800262c8d78 a 212ms FSC: OBJ17ea: CRTN - 4 4090 ffff88002792bed8 2 388ms FSC: OBJ17e8 OP60d36: Write1/Store fl=2 - 5 4092 ffff88002a0ef308 2 388ms FSC: OBJ17e7 OP60d2e: Write1/Store fl=2 - 6 4094 ffff88002abaf4b8 2 132ms FSC: OBJ17e2 OP60d4e: Write1/Store fl=2 - 7 4095 ffff88002bb188e0 a 388ms FSC: OBJ17e9: CRTN - vsq - ffff880023d99668 1 308ms FSC: OBJ17e0 OP60f91: Write1/EnQ fl=2 - vsq - ffff8800295d1740 1 212ms FSC: OBJ16be OP4d4b6: Write1/EnQ fl=2 - vsq - ffff880025ba3308 1 160ms FSC: OBJ179a OP58dec: Write1/EnQ fl=2 - vsq - ffff880024ec83e0 1 160ms FSC: OBJ17ae OP599f2: Write1/EnQ fl=2 - vsq - ffff880026618e00 1 160ms FSC: OBJ17e6 OP60d33: Write1/EnQ fl=2 - vsq - ffff880025a2a4b8 1 132ms FSC: OBJ16a2 OP4d583: Write1/EnQ fl=2 - vsq - ffff880023cbe6d8 9 212ms FSC: OBJ17eb: LOOK - vsq - ffff880024d37590 9 212ms FSC: OBJ17ec: LOOK - vsq - ffff880027746cb0 9 212ms FSC: OBJ17ed: LOOK - vsq - ffff880024d37ae8 9 212ms FSC: OBJ17ee: LOOK - vsq - ffff880024d37cb0 9 212ms FSC: OBJ17ef: LOOK - vsq - ffff880025036550 9 212ms FSC: OBJ17f0: LOOK - vsq - ffff8800250368e0 9 212ms FSC: OBJ17f1: LOOK - vsq - ffff880025036aa8 9 212ms FSC: OBJ17f2: LOOK - -In the 'THR' column, executing items show the thread they're occupying and -queued threads indicate which queue they're on. 'PID' shows the process ID of -a slow-work thread that's executing something. 'FL' shows the work item flags. -'MARK' indicates how long since an item was queued or began executing. Lastly, -the 'DESC' column permits the owner of an item to give some information. - -- cgit v1.1 From a64afb057b607c04383ab5fb53c51421ba18c434 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Tue, 20 Jul 2010 17:50:52 +1000 Subject: xfs: remove obsolete osyncisosync mount option Since Linux 2.6.33 the kernel has support for real O_SYNC, which made the osyncisosync option a no-op. Warn the users about this and remove the mount flag for it. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner --- Documentation/filesystems/xfs.txt | 11 ----------- 1 file changed, 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt index 9878f50..7bff3e4 100644 --- a/Documentation/filesystems/xfs.txt +++ b/Documentation/filesystems/xfs.txt @@ -131,17 +131,6 @@ When mounting an XFS filesystem, the following options are accepted. Don't check for double mounted file systems using the file system uuid. This is useful to mount LVM snapshot volumes. - osyncisosync - Make O_SYNC writes implement true O_SYNC. WITHOUT this option, - Linux XFS behaves as if an "osyncisdsync" option is used, - which will make writes to files opened with the O_SYNC flag set - behave as if the O_DSYNC flag had been used instead. - This can result in better performance without compromising - data safety. - However if this option is not in effect, timestamp updates from - O_SYNC writes can be lost if the system crashes. - If timestamp updates are critical, use the osyncisosync option. - uquota/usrquota/uqnoenforce/quota User disk quota accounting enabled, and limits (optionally) enforced. Refer to xfs_quota(8) for further details. -- cgit v1.1 From c1c5413ad58cb73267d328e6020268aa2e50d8ca Mon Sep 17 00:00:00 2001 From: Stefano Stabellini Date: Fri, 14 May 2010 12:44:30 +0100 Subject: x86: Unplug emulated disks and nics. Add a xen_emul_unplug command line option to the kernel to unplug xen emulated disks and nics. Set the default value of xen_emul_unplug depending on whether or not the Xen PV frontends and the Xen platform PCI driver have been compiled for this kernel (modules or built-in are both OK). The user can specify xen_emul_unplug=ignore to enable PV drivers on HVM even if the host platform doesn't support unplug. Signed-off-by: Stefano Stabellini Signed-off-by: Jeremy Fitzhardinge --- Documentation/kernel-parameters.txt | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 82d6aeb..eefcd80 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -115,6 +115,7 @@ parameter is applicable: More X86-64 boot options can be found in Documentation/x86/x86_64/boot-options.txt . X86 Either 32bit or 64bit x86 (same as X86-32+X86-64) + XEN Xen support is enabled In addition, the following text indicates that the option: @@ -2879,6 +2880,16 @@ and is between 256 and 4096 characters. It is defined in the file xd= [HW,XT] Original XT pre-IDE (RLL encoded) disks. xd_geo= See header of drivers/block/xd.c. + xen_emul_unplug= [HW,X86,XEN] + Unplug Xen emulated devices + Format: [unplug0,][unplug1] + ide-disks -- unplug primary master IDE devices + aux-ide-disks -- unplug non-primary-master IDE devices + nics -- unplug network devices + all -- unplug all emulated devices (NICs and IDE disks) + ignore -- continue loading the Xen platform PCI driver even + if the version check failed + xirc2ps_cs= [NET,PCMCIA] Format: ,,,,,[,[,[,]]] -- cgit v1.1 From aed69d2b79bb5af008526998e466da6d0eac7ae5 Mon Sep 17 00:00:00 2001 From: Stefan Richter Date: Thu, 22 Jul 2010 19:50:32 +0200 Subject: firewire: nosy: note ioctls in ioctl-number.txt These are the ioctls for the special-purpose misc device /dev/nosy, the interface to the IEEE 1394 packet sniffer/ protocol analyzer driver. Currently only the numbers 00...02 are in use; let's block a few more for unforeseen use cases. Cc: Randy Dunlap Signed-off-by: Stefan Richter --- Documentation/ioctl/ioctl-number.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index dd5806f..81ff9fc 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -79,6 +79,7 @@ Code Seq#(hex) Include File Comments 0x22 all scsi/sg.h '#' 00-3F IEEE 1394 Subsystem Block for the entire subsystem '$' 00-0F linux/perf_counter.h, linux/perf_event.h +'&' 00-07 drivers/firewire/nosy-user.h '1' 00-1F PPS kit from Ulrich Windl '2' 01-04 linux/i2o.h -- cgit v1.1 From 1dbd30e9890fd69e50b17edd70ca583546b0fe4e Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Mon, 12 Jul 2010 21:53:28 +0100 Subject: ARM: 6225/1: make TCM allocation static and common for all archs This changes the TCM handling so that a fixed area is reserved at 0xfffe0000-0xfffeffff for TCM. This areas is used by XScale but XScale does not have TCM so the mechanisms are mutually exclusive. This change is needed to make TCM detection more dynamic while still being able to compile code into it, and is a must for the unified ARM goals: the current TCM allocation at different places in memory for each machine would be a nightmare if you want to compile a single image for more than one machine with TCM so it has to be nailed down in one place. Signed-off-by: Linus Walleij Signed-off-by: Russell King --- Documentation/arm/memory.txt | 8 +++++++- Documentation/arm/tcm.txt | 30 +++++++++++++++++++----------- 2 files changed, 26 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt index eb0fae1..771d48d 100644 --- a/Documentation/arm/memory.txt +++ b/Documentation/arm/memory.txt @@ -33,7 +33,13 @@ ffff0000 ffff0fff CPU vector page. fffe0000 fffeffff XScale cache flush area. This is used in proc-xscale.S to flush the whole data - cache. Free for other usage on non-XScale. + cache. (XScale does not have TCM.) + +fffe8000 fffeffff DTCM mapping area for platforms with + DTCM mounted inside the CPU. + +fffe0000 fffe7fff ITCM mapping area for platforms with + ITCM mounted inside the CPU. fff00000 fffdffff Fixmap mapping region. Addresses provided by fix_to_virt() will be located here. diff --git a/Documentation/arm/tcm.txt b/Documentation/arm/tcm.txt index 77fd937..7c15871 100644 --- a/Documentation/arm/tcm.txt +++ b/Documentation/arm/tcm.txt @@ -19,8 +19,8 @@ defines a CPUID_TCM register that you can read out from the system control coprocessor. Documentation from ARM can be found at http://infocenter.arm.com, search for "TCM Status Register" to see documents for all CPUs. Reading this register you can -determine if ITCM (bit 0) and/or DTCM (bit 16) is present in the -machine. +determine if ITCM (bits 1-0) and/or DTCM (bit 17-16) is present +in the machine. There is further a TCM region register (search for "TCM Region Registers" at the ARM site) that can report and modify the location @@ -35,7 +35,15 @@ The TCM memory can then be remapped to another address again using the MMU, but notice that the TCM if often used in situations where the MMU is turned off. To avoid confusion the current Linux implementation will map the TCM 1 to 1 from physical to virtual -memory in the location specified by the machine. +memory in the location specified by the kernel. Currently Linux +will map ITCM to 0xfffe0000 and on, and DTCM to 0xfffe8000 and +on, supporting a maximum of 32KiB of ITCM and 32KiB of DTCM. + +Newer versions of the region registers also support dividing these +TCMs in two separate banks, so for example an 8KiB ITCM is divided +into two 4KiB banks with its own control registers. The idea is to +be able to lock and hide one of the banks for use by the secure +world (TrustZone). TCM is used for a few things: @@ -65,18 +73,18 @@ in . Using this interface it is possible to: memory. Such a heap is great for things like saving device state when shutting off device power domains. -A machine that has TCM memory shall select HAVE_TCM in -arch/arm/Kconfig for itself, and then the -rest of the functionality will depend on the physical -location and size of ITCM and DTCM to be defined in -mach/memory.h for the machine. Code that needs to use -TCM shall #include If the TCM is not located -at the place given in memory.h it will be moved using -the TCM Region registers. +A machine that has TCM memory shall select HAVE_TCM from +arch/arm/Kconfig for itself. Code that needs to use TCM shall +#include Functions to go into itcm can be tagged like this: int __tcmfunc foo(int bar); +Since these are marked to become long_calls and you may want +to have functions called locally inside the TCM without +wasting space, there is also the __tcmlocalfunc prefix that +will make the call relative. + Variables to go into dtcm can be tagged like this: int __tcmdata foo; -- cgit v1.1 From 592913ecb87a9e06f98ddb55b298f1a66bf94c6b Mon Sep 17 00:00:00 2001 From: John Stultz Date: Tue, 13 Jul 2010 17:56:20 -0700 Subject: time: Kill off CONFIG_GENERIC_TIME Now that all arches have been converted over to use generic time via clocksources or arch_gettimeoffset(), we can remove the GENERIC_TIME config option and simplify the generic code. Signed-off-by: John Stultz LKML-Reference: <1279068988-21864-4-git-send-email-johnstul@us.ibm.com> Signed-off-by: Thomas Gleixner --- Documentation/kernel-parameters.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 2b2407d..8abdfd7 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -73,7 +73,6 @@ parameter is applicable: MTD MTD (Memory Technology Device) support is enabled. NET Appropriate network support is enabled. NUMA NUMA support is enabled. - GENERIC_TIME The generic timeofday code is enabled. NFS Appropriate NFS support is enabled. OSS OSS sound support is enabled. PV_OPS A paravirtualized kernel is enabled. @@ -468,7 +467,7 @@ and is between 256 and 4096 characters. It is defined in the file clocksource is not available, it defaults to PIT. Format: { pit | tsc | cyclone | pmtmr } - clocksource= [GENERIC_TIME] Override the default clocksource + clocksource= Override the default clocksource Format: Override the default clocksource and use the clocksource with the name specified. -- cgit v1.1 From 0fb86b06298b6cd3205cac2e68a499f269282dac Mon Sep 17 00:00:00 2001 From: John Stultz Date: Tue, 13 Jul 2010 17:56:26 -0700 Subject: timekeeping: Make xtime and wall_to_monotonic static This patch makes xtime and wall_to_monotonic static, as planned in Documentation/feature-removal-schedule.txt. This will allow for further cleanups to the timekeeping core. Signed-off-by: John Stultz LKML-Reference: <1279068988-21864-10-git-send-email-johnstul@us.ibm.com> Signed-off-by: Thomas Gleixner --- Documentation/feature-removal-schedule.txt | 10 ---------- 1 file changed, 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 1571c0c..cd648db 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -549,16 +549,6 @@ Who: Avi Kivity ---------------------------- -What: xtime, wall_to_monotonic -When: 2.6.36+ -Files: kernel/time/timekeeping.c include/linux/time.h -Why: Cleaning up timekeeping internal values. Please use - existing timekeeping accessor functions to access - the equivalent functionality. -Who: John Stultz - ----------------------------- - What: KVM kernel-allocated memory slots When: July 2010 Why: Since 2.6.25, kvm supports user-allocated memory slots, which are -- cgit v1.1 From 992ebcf14f3cf029b8d0da4f479d752c19d8c726 Mon Sep 17 00:00:00 2001 From: "Stephen M. Cameron" Date: Thu, 27 May 2010 15:14:29 -0500 Subject: [SCSI] hpsa: Add hpsa.txt to Documentation/scsi Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley --- Documentation/scsi/hpsa.txt | 100 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 Documentation/scsi/hpsa.txt (limited to 'Documentation') diff --git a/Documentation/scsi/hpsa.txt b/Documentation/scsi/hpsa.txt new file mode 100644 index 0000000..4055657 --- /dev/null +++ b/Documentation/scsi/hpsa.txt @@ -0,0 +1,100 @@ + +HPSA - Hewlett Packard Smart Array driver +----------------------------------------- + +This file describes the hpsa SCSI driver for HP Smart Array controllers. +The hpsa driver is intended to supplant the cciss driver for newer +Smart Array controllers. The hpsa driver is a SCSI driver, while the +cciss driver is a "block" driver. Actually cciss is both a block +driver (for logical drives) AND a SCSI driver (for tape drives). This +"split-brained" design of the cciss driver is a source of excess +complexity and eliminating that complexity is one of the reasons +for hpsa to exist. + +Supported devices: +------------------ + +Smart Array P212 +Smart Array P410 +Smart Array P410i +Smart Array P411 +Smart Array P812 +Smart Array P712m +Smart Array P711m +StorageWorks P1210m + +Additionally, older Smart Arrays may work with the hpsa driver if the kernel +boot parameter "hpsa_allow_any=1" is specified, however these are not tested +nor supported by HP with this driver. For older Smart Arrays, the cciss +driver should still be used. + +HPSA specific entries in /sys +----------------------------- + + In addition to the generic SCSI attributes available in /sys, hpsa supports + the following attributes: + + HPSA specific host attributes: + ------------------------------ + + /sys/class/scsi_host/host*/rescan + + the host "rescan" attribute is a write only attribute. Writing to this + attribute will cause the driver to scan for new, changed, or removed devices + (e.g. hot-plugged tape drives, or newly configured or deleted logical drives, + etc.) and notify the SCSI midlayer of any changes detected. Normally this is + triggered automatically by HP's Array Configuration Utility (either the GUI or + command line variety) so for logical drive changes, the user should not + normally have to use this. It may be useful when hot plugging devices like + tape drives, or entire storage boxes containing pre-configured logical drives. + + HPSA specific disk attributes: + ------------------------------ + + /sys/class/scsi_disk/c:b:t:l/device/unique_id + /sys/class/scsi_disk/c:b:t:l/device/raid_level + /sys/class/scsi_disk/c:b:t:l/device/lunid + + (where c:b:t:l are the controller, bus, target and lun of the device) + + For example: + + root@host:/sys/class/scsi_disk/4:0:0:0/device# cat unique_id + 600508B1001044395355323037570F77 + root@host:/sys/class/scsi_disk/4:0:0:0/device# cat lunid + 0x0000004000000000 + root@host:/sys/class/scsi_disk/4:0:0:0/device# cat raid_level + RAID 0 + +HPSA specific ioctls: +--------------------- + + For compatibility with applications written for the cciss driver, many, but + not all of the ioctls supported by the cciss driver are also supported by the + hpsa driver. The data structures used by these are described in + include/linux/cciss_ioctl.h + + CCISS_DEREGDISK + CCISS_REGNEWDISK + CCISS_REGNEWD + + The above three ioctls all do exactly the same thing, which is to cause the driver + to rescan for new devices. This does exactly the same thing as writing to the + hpsa specific host "rescan" attribute. + + CCISS_GETPCIINFO + + Returns PCI domain, bus, device and function and "board ID" (PCI subsystem ID). + + CCISS_GETDRIVVER + + Returns driver version in three bytes encoded as: + (major_version << 16) | (minor_version << 8) | (subminor_version) + + CCISS_PASSTHRU + CCISS_BIG_PASSTHRU + + Allows "BMIC" and "CISS" commands to be passed through to the Smart Array. + These are used extensively by the HP Array Configuration Utility, SNMP storage + agents, etc. See cciss_vol_status at http://cciss.sf.net for some examples. + -- cgit v1.1 From d28ce020fb0ef9254fc9e0bd07f5898c69af9f7d Mon Sep 17 00:00:00 2001 From: "Stephen M. Cameron" Date: Thu, 27 May 2010 15:14:34 -0500 Subject: [SCSI] hpsa: expose controller firmware revision via /sys. Signed-off-by: Stephen M. Cameron Signed-off-by: James Bottomley --- Documentation/scsi/hpsa.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/scsi/hpsa.txt b/Documentation/scsi/hpsa.txt index 4055657..dca6583 100644 --- a/Documentation/scsi/hpsa.txt +++ b/Documentation/scsi/hpsa.txt @@ -38,6 +38,7 @@ HPSA specific entries in /sys ------------------------------ /sys/class/scsi_host/host*/rescan + /sys/class/scsi_host/host*/firmware_revision the host "rescan" attribute is a write only attribute. Writing to this attribute will cause the driver to scan for new, changed, or removed devices @@ -48,6 +49,12 @@ HPSA specific entries in /sys normally have to use this. It may be useful when hot plugging devices like tape drives, or entire storage boxes containing pre-configured logical drives. + The "firmware_revision" attribute contains the firmware version of the Smart Array. + For example: + + root@host:/sys/class/scsi_host/host4# cat firmware_revision + 7.14 + HPSA specific disk attributes: ------------------------------ -- cgit v1.1 From 2dfc1cae4c42b93b831b2417540df2b895ab7108 Mon Sep 17 00:00:00 2001 From: Eric Paris Date: Thu, 17 Dec 2009 20:30:52 -0500 Subject: inotify: remove inotify in kernel interface nothing uses inotify in the kernel, drop it! Signed-off-by: Eric Paris --- Documentation/feature-removal-schedule.txt | 8 -------- 1 file changed, 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 1571c0c..a8188bd 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -367,14 +367,6 @@ When: 2.6.33 Why: Should be implemented in userspace, policy daemon. Who: Johannes Berg ---------------------------- - -What: CONFIG_INOTIFY -When: 2.6.33 -Why: last user (audit) will be converted to the newer more generic - and more easily maintained fsnotify subsystem -Who: Eric Paris - ---------------------------- What: lock_policy_rwsem_* and unlock_policy_rwsem_* will not be -- cgit v1.1 From 7bd1c365fd124624191d49dcc1eb9759d6017ec3 Mon Sep 17 00:00:00 2001 From: Mike Habeck Date: Wed, 12 May 2010 11:14:32 -0700 Subject: x86/PCI: Add option to not assign BAR's if not already assigned The Linux kernel assigns BARs that a BIOS did not assign, most likely to handle broken BIOSes that didn't enumerate the devices correctly. On UV the BIOS purposely doesn't assign I/O BARs for certain devices/ drivers we know don't use them (examples, LSI SAS, Qlogic FC, ...). We purposely don't assign these I/O BARs because I/O Space is a very limited resource. There is only 64k of I/O Space, and in a PCIe topology that space gets divided up into 4k chucks (this is due to the fact that a pci-to-pci bridge's I/O decoder is aligned at 4k)... Thus a system can have at most 16 cards with I/O BARs: (64k / 4k = 16) SGI needs to scale to >16 devices with I/O BARs. So by not assigning I/O BARs on devices we know don't use them, we can do that (iff the kernel doesn't go and assign these BARs that the BIOS purposely didn't assign). This patch will not assign a resource to a device BAR if that BAR was not assigned by the BIOS, and the kernel cmdline option 'pci=nobar' was specified. This patch is closely modeled after the 'pci=norom' option that currently exists in the tree. Signed-off-by: Mike Habeck Signed-off-by: Mike Travis Signed-off-by: Jesse Barnes --- Documentation/kernel-parameters.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 2b2407d..4fac69b 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1970,6 +1970,8 @@ and is between 256 and 4096 characters. It is defined in the file norom [X86] Do not assign address space to expansion ROMs that do not already have BIOS assigned address ranges. + nobar [X86] Do not assign address space to the + BARs that weren't assigned by the BIOS. irqmask=0xMMMM [X86] Set a bit mask of IRQs allowed to be assigned automatically to PCI devices. You can make the kernel exclude IRQs of your ISA cards -- cgit v1.1 From 8633328be242677fdedc42052838dd0608e7f342 Mon Sep 17 00:00:00 2001 From: Alex Williamson Date: Mon, 19 Jul 2010 09:45:34 -0600 Subject: PCI: Allow read/write access to sysfs I/O port resources PCI sysfs resource files currently only allow mmap'ing. On x86 this works fine for memory backed BARs, but doesn't work at all for I/O port backed BARs. Add read/write to I/O port PCI sysfs resource files to allow userspace access to these device regions. Acked-by: Chris Wright Signed-off-by: Alex Williamson Signed-off-by: Jesse Barnes --- Documentation/filesystems/sysfs-pci.txt | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt index 85354b3..74eaac2 100644 --- a/Documentation/filesystems/sysfs-pci.txt +++ b/Documentation/filesystems/sysfs-pci.txt @@ -39,7 +39,7 @@ files, each with their own function. local_cpus nearby CPU mask (cpumask, ro) remove remove device from kernel's list (ascii, wo) resource PCI resource host addresses (ascii, ro) - resource0..N PCI resource N, if present (binary, mmap) + resource0..N PCI resource N, if present (binary, mmap, rw[1]) resource0_wc..N_wc PCI WC map resource N, if prefetchable (binary, mmap) rom PCI ROM resource, if present (binary, ro) subsystem_device PCI subsystem device (ascii, ro) @@ -54,13 +54,16 @@ files, each with their own function. binary - file contains binary data cpumask - file contains a cpumask type +[1] rw for RESOURCE_IO (I/O port) regions only + The read only files are informational, writes to them will be ignored, with the exception of the 'rom' file. Writable files can be used to perform actions on the device (e.g. changing config space, detaching a device). mmapable files are available via an mmap of the file at offset 0 and can be used to do actual device programming from userspace. Note that some platforms don't support mmapping of certain resources, so be sure to check the return -value from any attempted mmap. +value from any attempted mmap. The most notable of these are I/O port +resources, which also provide read/write access. The 'enable' file provides a counter that indicates how many times the device has been enabled. If the 'enable' file currently returns '4', and a '1' is -- cgit v1.1 From 911e1c9b05a8e3559a7aa89083930700a0b9e7ee Mon Sep 17 00:00:00 2001 From: Narendra K Date: Mon, 26 Jul 2010 05:56:50 -0500 Subject: PCI: export SMBIOS provided firmware instance and label to sysfs This patch exports SMBIOS provided firmware instance and label of onboard PCI devices to sysfs. New files are: /sys/bus/pci/devices/.../label which contains the firmware name for the device in question, and /sys/bus/pci/devices/.../index which contains the firmware device type instance for the given device. Signed-off-by: Jordan Hargrave Signed-off-by: Narendra K Signed-off-by: Jesse Barnes --- Documentation/ABI/testing/sysfs-bus-pci | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index 25be325..f979d82 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci @@ -139,3 +139,30 @@ Contact: linux-pci@vger.kernel.org Description: This symbolic link points to the PCI hotplug controller driver module that manages the hotplug slot. + +What: /sys/bus/pci/devices/.../label +Date: July 2010 +Contact: Narendra K , linux-bugs@dell.com +Description: + Reading this attribute will provide the firmware + given name(SMBIOS type 41 string) of the PCI device. + The attribute will be created only if the firmware + has given a name to the PCI device. +Users: + Userspace applications interested in knowing the + firmware assigned name of the PCI device. + +What: /sys/bus/pci/devices/.../index +Date: July 2010 +Contact: Narendra K , linux-bugs@dell.com +Description: + Reading this attribute will provide the firmware + given instance(SMBIOS type 41 device type instance) + of the PCI device. The attribute will be created + only if the firmware has given a device type instance + to the PCI device. +Users: + Userspace applications interested in knowing the + firmware assigned device type instance of the PCI + device that can help in understanding the firmware + intended order of the PCI device. -- cgit v1.1 From 5716d415f8c5a17d44f6e1d5a1e4998f7306a93b Mon Sep 17 00:00:00 2001 From: Dominik Brodowski Date: Sun, 11 Jul 2010 09:51:14 +0200 Subject: pcmcia: remove obsolete ioctl Signed-off-by: Dominik Brodowski --- Documentation/feature-removal-schedule.txt | 23 ----------------------- 1 file changed, 23 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index c268783..27ed68d 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -116,29 +116,6 @@ Who: Mauro Carvalho Chehab --------------------------- -What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) -When: 2.6.35/2.6.36 -Files: drivers/pcmcia/: pcmcia_ioctl.c -Why: With the 16-bit PCMCIA subsystem now behaving (almost) like a - normal hotpluggable bus, and with it using the default kernel - infrastructure (hotplug, driver core, sysfs) keeping the PCMCIA - control ioctl needed by cardmgr and cardctl from pcmcia-cs is - unnecessary and potentially harmful (it does not provide for - proper locking), and makes further cleanups and integration of the - PCMCIA subsystem into the Linux kernel device driver model more - difficult. The features provided by cardmgr and cardctl are either - handled by the kernel itself now or are available in the new - pcmciautils package available at - http://kernel.org/pub/linux/utils/kernel/pcmcia/ - - For all architectures except ARM, the associated config symbol - has been removed from kernel 2.6.34; for ARM, it will be likely - be removed from kernel 2.6.35. The actual code will then likely - be removed from kernel 2.6.36. -Who: Dominik Brodowski - ---------------------------- - What: sys_sysctl When: September 2010 Option: CONFIG_SYSCTL_SYSCALL -- cgit v1.1 From ac8b422838046ffc26be4874a3cbae0d313f4209 Mon Sep 17 00:00:00 2001 From: Dominik Brodowski Date: Wed, 21 Jul 2010 22:38:13 +0200 Subject: pcmcia: remove cs_types.h Remove cs_types.h which is no longer needed: Most definitions aren't used at all, a few can be made away with, and two remaining definitions (typedefs, unfortunatley) may be moved to more specific places. CC: linux-ide@vger.kernel.org CC: linux-usb@vger.kernel.org CC: laforge@gnumonks.org CC: linux-mtd@lists.infradead.org CC: alsa-devel@alsa-project.org CC: linux-serial@vger.kernel.org Acked-by: Marcel Holtmann (for drivers/bluetooth/) Acked-by: David S. Miller Signed-off-by: Dominik Brodowski --- Documentation/pcmcia/driver-changes.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/pcmcia/driver-changes.txt b/Documentation/pcmcia/driver-changes.txt index 61bc4e9..ff5f0be 100644 --- a/Documentation/pcmcia/driver-changes.txt +++ b/Documentation/pcmcia/driver-changes.txt @@ -1,4 +1,9 @@ This file details changes in 2.6 which affect PCMCIA card driver authors: +* No dev_info_t, no cs_types.h (as of 2.6.36) + dev_info_t and a few other typedefs are removed. No longer use them + in PCMCIA device drivers. Also, do not include pcmcia/cs_types.h, as + this file is gone. + * No dev_node_t (as of 2.6.35) There is no more need to fill out a "dev_node_t" structure. -- cgit v1.1 From 313910d3b98029a867bb4aa3ee552ae573db0458 Mon Sep 17 00:00:00 2001 From: Steffen Klassert Date: Tue, 27 Jul 2010 07:20:47 +0200 Subject: padata: update API documentation Signed-off-by: Steffen Klassert Signed-off-by: Herbert Xu --- Documentation/padata.txt | 76 ++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 64 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/padata.txt b/Documentation/padata.txt index 93dd4e6..473ebf2 100644 --- a/Documentation/padata.txt +++ b/Documentation/padata.txt @@ -1,5 +1,5 @@ The padata parallel execution mechanism -Last updated for 2.6.34 +Last updated for 2.6.36 Padata is a mechanism by which the kernel can farm work out to be done in parallel on multiple CPUs while retaining the ordering of tasks. It was @@ -13,12 +13,28 @@ overall control of how tasks are to be run: #include - struct padata_instance *padata_alloc(const struct cpumask *cpumask, - struct workqueue_struct *wq); + struct padata_instance *padata_alloc(struct workqueue_struct *wq, + const struct cpumask *pcpumask, + const struct cpumask *cbcpumask); -The cpumask describes which processors will be used to execute work -submitted to this instance. The workqueue wq is where the work will -actually be done; it should be a multithreaded queue, naturally. +The pcpumask describes which processors will be used to execute work +submitted to this instance in parallel. The cbcpumask defines which +processors are allowed to use as the serialization callback processor. +The workqueue wq is where the work will actually be done; it should be +a multithreaded queue, naturally. + +To allocate a padata instance with the cpu_possible_mask for both +cpumasks this helper function can be used: + + struct padata_instance *padata_alloc_possible(struct workqueue_struct *wq); + +Note: Padata maintains two kinds of cpumasks internally. The user supplied +cpumasks, submitted by padata_alloc/padata_alloc_possible and the 'usable' +cpumasks. The usable cpumasks are always the subset of active cpus in the +user supplied cpumasks, these are the cpumasks padata actually use. So +it is legal to supply a cpumask to padata that contains offline cpus. +Once a offline cpu in the user supplied cpumask comes online, padata +is going to use it. There are functions for enabling and disabling the instance: @@ -34,13 +50,49 @@ is unused. The list of CPUs to be used can be adjusted with these functions: - int padata_set_cpumask(struct padata_instance *pinst, + int padata_set_cpumasks(struct padata_instance *pinst, + cpumask_var_t pcpumask, + cpumask_var_t cbcpumask); + int padata_set_cpumask(struct padata_instance *pinst, int cpumask_type, cpumask_var_t cpumask); - int padata_add_cpu(struct padata_instance *pinst, int cpu); - int padata_remove_cpu(struct padata_instance *pinst, int cpu); + int padata_add_cpu(struct padata_instance *pinst, int cpu, int mask); + int padata_remove_cpu(struct padata_instance *pinst, int cpu, int mask); + +Changing the CPU masks are expensive operations, though, so it should not be +done with great frequency. + +It's possible to change both cpumasks of a padata instance with +padata_set_cpumasks by specifying the cpumasks for parallel execution (pcpumask) +and for the serial callback function (cbcpumask). padata_set_cpumask is to +change just one of the cpumasks. Here cpumask_type is one of PADATA_CPU_SERIAL, +PADATA_CPU_PARALLEL and cpumask specifies the new cpumask to use. +To simply add or remove one cpu from a certain cpumask the functions +padata_add_cpu/padata_remove_cpu are used. cpu specifies the cpu to add or +remove and mask is one of PADATA_CPU_SERIAL, PADATA_CPU_PARALLEL. + +If a user is interested in padata cpumask changes, he can register to +the padata cpumask change notifier: + + int padata_register_cpumask_notifier(struct padata_instance *pinst, + struct notifier_block *nblock); + +To unregister from that notifier: + + int padata_unregister_cpumask_notifier(struct padata_instance *pinst, + struct notifier_block *nblock); + +The padata cpumask change notifier notifies about changes of the usable +cpumasks, i.e. the subset of active cpus in the user supplied cpumask. + +Padata calls the notifier chain with: + + blocking_notifier_call_chain(&pinst->cpumask_change_notifier, + notification_mask, + &pd_new->cpumask); -Changing the CPU mask has the look of an expensive operation, though, so it -probably should not be done with great frequency. +Here cpumask_change_notifier is registered notifier, notification_mask +is one of PADATA_CPU_SERIAL, PADATA_CPU_PARALLEL and cpumask is a pointer +to a struct padata_cpumask that contains the new cpumask informations. Actually submitting work to the padata instance requires the creation of a padata_priv structure: @@ -53,7 +105,7 @@ padata_priv structure: This structure will almost certainly be embedded within some larger structure specific to the work to be done. Most its fields are private to -padata, but the structure should be zeroed at initialization time, and the +padata, but the structure should be zeroed at initialisation time, and the parallel() and serial() functions should be provided. Those functions will be called in the process of getting the work done as we will see momentarily. -- cgit v1.1 From 47dbb84f9e04e3261585da384d96b8c63f3376e3 Mon Sep 17 00:00:00 2001 From: Avi Kivity Date: Thu, 29 Apr 2010 12:08:56 +0300 Subject: KVM: Document KVM_SET_IDENTITY_MAP ioctl Signed-off-by: Avi Kivity --- Documentation/kvm/api.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt index a237518..0f96e52 100644 --- a/Documentation/kvm/api.txt +++ b/Documentation/kvm/api.txt @@ -892,6 +892,24 @@ arguments. This ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel irqchip, the multiprocessing state must be maintained by userspace. +4.39 KVM_SET_IDENTITY_MAP_ADDR + +Capability: KVM_CAP_SET_IDENTITY_MAP_ADDR +Architectures: x86 +Type: vm ioctl +Parameters: unsigned long identity (in) +Returns: 0 on success, -1 on error + +This ioctl defines the physical address of a one-page region in the guest +physical address space. The region must be within the first 4GB of the +guest physical address space and must not conflict with any memory slot +or any mmio address. The guest may malfunction if it accesses this memory +region. + +This ioctl is required on Intel-based hosts. This is needed on Intel hardware +because of a quirk in the virtualization implementation (see the internals +documentation when it pops into existence). + 5. The kvm_run structure Application code obtains a pointer to the kvm_run structure by -- cgit v1.1 From 57bc24cfd655c912498983130326b312e0404db1 Mon Sep 17 00:00:00 2001 From: Avi Kivity Date: Thu, 29 Apr 2010 12:12:57 +0300 Subject: KVM: Document KVM_SET_BOOT_CPU_ID Signed-off-by: Avi Kivity --- Documentation/kvm/api.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt index 0f96e52..159b4ef 100644 --- a/Documentation/kvm/api.txt +++ b/Documentation/kvm/api.txt @@ -910,6 +910,18 @@ This ioctl is required on Intel-based hosts. This is needed on Intel hardware because of a quirk in the virtualization implementation (see the internals documentation when it pops into existence). +4.40 KVM_SET_BOOT_CPU_ID + +Capability: KVM_CAP_SET_BOOT_CPU_ID +Architectures: x86, ia64 +Type: vm ioctl +Parameters: unsigned long vcpu_id +Returns: 0 on success, -1 on error + +Define which vcpu is the Bootstrap Processor (BSP). Values are the same +as the vcpu id in KVM_CREATE_VCPU. If this ioctl is not called, the default +is vcpu 0. + 5. The kvm_run structure Application code obtains a pointer to the kvm_run structure by -- cgit v1.1 From 6859762e8ae32ec258a671faf5c9fef07b25b83f Mon Sep 17 00:00:00 2001 From: Gui Jianfeng Date: Tue, 11 May 2010 14:36:58 +0800 Subject: KVM: update mmu documetation for role.nxe There's no member "cr4_nxe" in struct kvm_mmu_page_role, it names "nxe" now. Update mmu document. Signed-off-by: Gui Jianfeng Signed-off-by: Marcelo Tosatti --- Documentation/kvm/mmu.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kvm/mmu.txt b/Documentation/kvm/mmu.txt index aaed6ab..0e872ae 100644 --- a/Documentation/kvm/mmu.txt +++ b/Documentation/kvm/mmu.txt @@ -161,7 +161,7 @@ Shadow pages contain the following information: role.cr4_pae: Contains the value of cr4.pae for which the page is valid (e.g. whether 32-bit or 64-bit gptes are in use). - role.cr4_nxe: + role.nxe: Contains the value of efer.nxe for which the page is valid. role.cr0_wp: Contains the value of cr0.wp for which the page is valid. -- cgit v1.1 From 2032a93d66fa282ba0f2ea9152eeff9511fa9a96 Mon Sep 17 00:00:00 2001 From: Lai Jiangshan Date: Wed, 26 May 2010 16:49:59 +0800 Subject: KVM: MMU: Don't allocate gfns page for direct mmu pages When sp->role.direct is set, sp->gfns does not contain any essential information, leaf sptes reachable from this sp are for a continuous guest physical memory range (a linear range). So sp->gfns[i] (if it was set) equals to sp->gfn + i. (PT_PAGE_TABLE_LEVEL) Obviously, it is not essential information, we can calculate it when need. It means we don't need sp->gfns when sp->role.direct=1, Thus we can save one page usage for every kvm_mmu_page. Note: Access to sp->gfns must be wrapped by kvm_mmu_page_get_gfn() or kvm_mmu_page_set_gfn(). It is only exposed in FNAME(sync_page). Signed-off-by: Lai Jiangshan Signed-off-by: Avi Kivity --- Documentation/kvm/mmu.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kvm/mmu.txt b/Documentation/kvm/mmu.txt index 0e872ae..2201dcb 100644 --- a/Documentation/kvm/mmu.txt +++ b/Documentation/kvm/mmu.txt @@ -180,7 +180,9 @@ Shadow pages contain the following information: guest pages as leaves. gfns: An array of 512 guest frame numbers, one for each present pte. Used to - perform a reverse map from a pte to a gfn. + perform a reverse map from a pte to a gfn. When role.direct is set, any + element of this array can be calculated from the gfn field when used, in + this case, the array of gfns is not allocated. See role.direct and gfn. slot_bitmap: A bitmap containing one bit per memory slot. If the page contains a pte mapping a page from memory slot n, then bit n of slot_bitmap will be set -- cgit v1.1 From ec87fe2afcbcc4f430554980ec3e408bae34229d Mon Sep 17 00:00:00 2001 From: Avi Kivity Date: Thu, 27 May 2010 14:46:04 +0300 Subject: KVM: MMU: Document cr0.wp emulation Signed-off-by: Avi Kivity --- Documentation/kvm/mmu.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kvm/mmu.txt b/Documentation/kvm/mmu.txt index 2201dcb..1e7ecdd 100644 --- a/Documentation/kvm/mmu.txt +++ b/Documentation/kvm/mmu.txt @@ -298,6 +298,25 @@ Host translation updates: - look up affected sptes through reverse map - drop (or update) translations +Emulating cr0.wp +================ + +If tdp is not enabled, the host must keep cr0.wp=1 so page write protection +works for the guest kernel, not guest guest userspace. When the guest +cr0.wp=1, this does not present a problem. However when the guest cr0.wp=0, +we cannot map the permissions for gpte.u=1, gpte.w=0 to any spte (the +semantics require allowing any guest kernel access plus user read access). + +We handle this by mapping the permissions to two possible sptes, depending +on fault type: + +- kernel write fault: spte.u=0, spte.w=1 (allows full kernel access, + disallows user access) +- read fault: spte.u=1, spte.w=0 (allows full read access, disallows kernel + write access) + +(user write faults generate a #PF) + Further reading =============== -- cgit v1.1 From 316b95216e277cdb22bd65346f9b9d9e10d0f53d Mon Sep 17 00:00:00 2001 From: Avi Kivity Date: Thu, 27 May 2010 16:44:12 +0300 Subject: KVM: MMU: Document large pages Signed-off-by: Avi Kivity Signed-off-by: Marcelo Tosatti --- Documentation/kvm/mmu.txt | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kvm/mmu.txt b/Documentation/kvm/mmu.txt index 1e7ecdd..8cb42b9 100644 --- a/Documentation/kvm/mmu.txt +++ b/Documentation/kvm/mmu.txt @@ -317,6 +317,29 @@ on fault type: (user write faults generate a #PF) +Large pages +=========== + +The mmu supports all combinations of large and small guest and host pages. +Supported page sizes include 4k, 2M, 4M, and 1G. 4M pages are treated as +two separate 2M pages, on both guest and host, since the mmu always uses PAE +paging. + +To instantiate a large spte, four constraints must be satisfied: + +- the spte must point to a large host page +- the guest pte must be a large pte of at least equivalent size (if tdp is + enabled, there is no guest pte and this condition is satisified) +- if the spte will be writeable, the large page frame may not overlap any + write-protected pages +- the guest page must be wholly contained by a single memory slot + +To check the last two conditions, the mmu maintains a ->write_count set of +arrays for each memory slot and large page size. Every write protected page +causes its write_count to be incremented, thus preventing instantiation of +a large spte. The frames at the end of an unaligned memory slot have +artificically inflated ->write_counts so they can never be instantiated. + Further reading =============== -- cgit v1.1 From d2d7a61127ced8ce9ec7666991aad1d846932212 Mon Sep 17 00:00:00 2001 From: Glauber Costa Date: Tue, 1 Jun 2010 08:22:48 -0400 Subject: KVM: Add Documentation/kvm/msr.txt This patch adds a file that documents the usage of KVM-specific MSRs. Signed-off-by: Glauber Costa Reviewed-by: Randy Dunlap Signed-off-by: Marcelo Tosatti --- Documentation/kvm/msr.txt | 153 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 153 insertions(+) create mode 100644 Documentation/kvm/msr.txt (limited to 'Documentation') diff --git a/Documentation/kvm/msr.txt b/Documentation/kvm/msr.txt new file mode 100644 index 0000000..8ddcfe8 --- /dev/null +++ b/Documentation/kvm/msr.txt @@ -0,0 +1,153 @@ +KVM-specific MSRs. +Glauber Costa , Red Hat Inc, 2010 +===================================================== + +KVM makes use of some custom MSRs to service some requests. +At present, this facility is only used by kvmclock. + +Custom MSRs have a range reserved for them, that goes from +0x4b564d00 to 0x4b564dff. There are MSRs outside this area, +but they are deprecated and their use is discouraged. + +Custom MSR list +-------- + +The current supported Custom MSR list is: + +MSR_KVM_WALL_CLOCK_NEW: 0x4b564d00 + + data: 4-byte alignment physical address of a memory area which must be + in guest RAM. This memory is expected to hold a copy of the following + structure: + + struct pvclock_wall_clock { + u32 version; + u32 sec; + u32 nsec; + } __attribute__((__packed__)); + + whose data will be filled in by the hypervisor. The hypervisor is only + guaranteed to update this data at the moment of MSR write. + Users that want to reliably query this information more than once have + to write more than once to this MSR. Fields have the following meanings: + + version: guest has to check version before and after grabbing + time information and check that they are both equal and even. + An odd version indicates an in-progress update. + + sec: number of seconds for wallclock. + + nsec: number of nanoseconds for wallclock. + + Note that although MSRs are per-CPU entities, the effect of this + particular MSR is global. + + Availability of this MSR must be checked via bit 3 in 0x4000001 cpuid + leaf prior to usage. + +MSR_KVM_SYSTEM_TIME_NEW: 0x4b564d01 + + data: 4-byte aligned physical address of a memory area which must be in + guest RAM, plus an enable bit in bit 0. This memory is expected to hold + a copy of the following structure: + + struct pvclock_vcpu_time_info { + u32 version; + u32 pad0; + u64 tsc_timestamp; + u64 system_time; + u32 tsc_to_system_mul; + s8 tsc_shift; + u8 flags; + u8 pad[2]; + } __attribute__((__packed__)); /* 32 bytes */ + + whose data will be filled in by the hypervisor periodically. Only one + write, or registration, is needed for each VCPU. The interval between + updates of this structure is arbitrary and implementation-dependent. + The hypervisor may update this structure at any time it sees fit until + anything with bit0 == 0 is written to it. + + Fields have the following meanings: + + version: guest has to check version before and after grabbing + time information and check that they are both equal and even. + An odd version indicates an in-progress update. + + tsc_timestamp: the tsc value at the current VCPU at the time + of the update of this structure. Guests can subtract this value + from current tsc to derive a notion of elapsed time since the + structure update. + + system_time: a host notion of monotonic time, including sleep + time at the time this structure was last updated. Unit is + nanoseconds. + + tsc_to_system_mul: a function of the tsc frequency. One has + to multiply any tsc-related quantity by this value to get + a value in nanoseconds, besides dividing by 2^tsc_shift + + tsc_shift: cycle to nanosecond divider, as a power of two, to + allow for shift rights. One has to shift right any tsc-related + quantity by this value to get a value in nanoseconds, besides + multiplying by tsc_to_system_mul. + + With this information, guests can derive per-CPU time by + doing: + + time = (current_tsc - tsc_timestamp) + time = (time * tsc_to_system_mul) >> tsc_shift + time = time + system_time + + flags: bits in this field indicate extended capabilities + coordinated between the guest and the hypervisor. Availability + of specific flags has to be checked in 0x40000001 cpuid leaf. + Current flags are: + + flag bit | cpuid bit | meaning + ------------------------------------------------------------- + | | time measures taken across + 0 | 24 | multiple cpus are guaranteed to + | | be monotonic + ------------------------------------------------------------- + + Availability of this MSR must be checked via bit 3 in 0x4000001 cpuid + leaf prior to usage. + + +MSR_KVM_WALL_CLOCK: 0x11 + + data and functioning: same as MSR_KVM_WALL_CLOCK_NEW. Use that instead. + + This MSR falls outside the reserved KVM range and may be removed in the + future. Its usage is deprecated. + + Availability of this MSR must be checked via bit 0 in 0x4000001 cpuid + leaf prior to usage. + +MSR_KVM_SYSTEM_TIME: 0x12 + + data and functioning: same as MSR_KVM_SYSTEM_TIME_NEW. Use that instead. + + This MSR falls outside the reserved KVM range and may be removed in the + future. Its usage is deprecated. + + Availability of this MSR must be checked via bit 0 in 0x4000001 cpuid + leaf prior to usage. + + The suggested algorithm for detecting kvmclock presence is then: + + if (!kvm_para_available()) /* refer to cpuid.txt */ + return NON_PRESENT; + + flags = cpuid_eax(0x40000001); + if (flags & 3) { + msr_kvm_system_time = MSR_KVM_SYSTEM_TIME_NEW; + msr_kvm_wall_clock = MSR_KVM_WALL_CLOCK_NEW; + return PRESENT; + } else if (flags & 0) { + msr_kvm_system_time = MSR_KVM_SYSTEM_TIME; + msr_kvm_wall_clock = MSR_KVM_WALL_CLOCK; + return PRESENT; + } else + return NON_PRESENT; -- cgit v1.1 From 2d5b5a665508c60577c1088e0405850a965b6795 Mon Sep 17 00:00:00 2001 From: Sheng Yang Date: Sun, 13 Jun 2010 17:29:39 +0800 Subject: KVM: x86: XSAVE/XRSTOR live migration support This patch enable save/restore of xsave state. Signed-off-by: Sheng Yang Signed-off-by: Marcelo Tosatti --- Documentation/kvm/api.txt | 74 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt index 159b4ef..ffba03f 100644 --- a/Documentation/kvm/api.txt +++ b/Documentation/kvm/api.txt @@ -922,6 +922,80 @@ Define which vcpu is the Bootstrap Processor (BSP). Values are the same as the vcpu id in KVM_CREATE_VCPU. If this ioctl is not called, the default is vcpu 0. +4.41 KVM_GET_XSAVE + +Capability: KVM_CAP_XSAVE +Architectures: x86 +Type: vcpu ioctl +Parameters: struct kvm_xsave (out) +Returns: 0 on success, -1 on error + +struct kvm_xsave { + __u32 region[1024]; +}; + +This ioctl would copy current vcpu's xsave struct to the userspace. + +4.42 KVM_SET_XSAVE + +Capability: KVM_CAP_XSAVE +Architectures: x86 +Type: vcpu ioctl +Parameters: struct kvm_xsave (in) +Returns: 0 on success, -1 on error + +struct kvm_xsave { + __u32 region[1024]; +}; + +This ioctl would copy userspace's xsave struct to the kernel. + +4.43 KVM_GET_XCRS + +Capability: KVM_CAP_XCRS +Architectures: x86 +Type: vcpu ioctl +Parameters: struct kvm_xcrs (out) +Returns: 0 on success, -1 on error + +struct kvm_xcr { + __u32 xcr; + __u32 reserved; + __u64 value; +}; + +struct kvm_xcrs { + __u32 nr_xcrs; + __u32 flags; + struct kvm_xcr xcrs[KVM_MAX_XCRS]; + __u64 padding[16]; +}; + +This ioctl would copy current vcpu's xcrs to the userspace. + +4.44 KVM_SET_XCRS + +Capability: KVM_CAP_XCRS +Architectures: x86 +Type: vcpu ioctl +Parameters: struct kvm_xcrs (in) +Returns: 0 on success, -1 on error + +struct kvm_xcr { + __u32 xcr; + __u32 reserved; + __u64 value; +}; + +struct kvm_xcrs { + __u32 nr_xcrs; + __u32 flags; + struct kvm_xcr xcrs[KVM_MAX_XCRS]; + __u64 padding[16]; +}; + +This ioctl would set vcpu's xcr to the value userspace specified. + 5. The kvm_run structure Application code obtains a pointer to the kvm_run structure by -- cgit v1.1 From 21bbe18b2d53e0941cbd1621400ba7b4028972cb Mon Sep 17 00:00:00 2001 From: Jason Wang Date: Thu, 17 Jun 2010 16:49:22 +0800 Subject: KVM: Fix typos in Documentation/kvm/mmu.txt Signed-off-by: Jason Wang Signed-off-by: Marcelo Tosatti --- Documentation/kvm/mmu.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kvm/mmu.txt b/Documentation/kvm/mmu.txt index 8cb42b9..142cc51 100644 --- a/Documentation/kvm/mmu.txt +++ b/Documentation/kvm/mmu.txt @@ -77,10 +77,10 @@ Memory Guest memory (gpa) is part of the user address space of the process that is using kvm. Userspace defines the translation between guest addresses and user -addresses (gpa->hva); note that two gpas may alias to the same gva, but not +addresses (gpa->hva); note that two gpas may alias to the same hva, but not vice versa. -These gvas may be backed using any method available to the host: anonymous +These hvas may be backed using any method available to the host: anonymous memory, file backed memory, and device memory. Memory might be paged by the host at any time. -- cgit v1.1 From a1f4d39500ad8ed61825eff061debff42386ab5b Mon Sep 17 00:00:00 2001 From: Avi Kivity Date: Mon, 21 Jun 2010 11:44:20 +0300 Subject: KVM: Remove memory alias support As advertised in feature-removal-schedule.txt. Equivalent support is provided by overlapping memory regions. Signed-off-by: Avi Kivity --- Documentation/feature-removal-schedule.txt | 11 ----------- Documentation/kvm/api.txt | 12 +----------- 2 files changed, 1 insertion(+), 22 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 1571c0c..ad1e90d 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -538,17 +538,6 @@ Who: Jan Kiszka ---------------------------- -What: KVM memory aliases support -When: July 2010 -Why: Memory aliasing support is used for speeding up guest vga access - through the vga windows. - - Modern userspace no longer uses this feature, so it's just bitrotted - code and can be removed with no impact. -Who: Avi Kivity - ----------------------------- - What: xtime, wall_to_monotonic When: 2.6.36+ Files: kernel/time/timekeeping.c include/linux/time.h diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt index ffba03f..7e41594 100644 --- a/Documentation/kvm/api.txt +++ b/Documentation/kvm/api.txt @@ -226,17 +226,7 @@ Type: vm ioctl Parameters: struct kvm_memory_alias (in) Returns: 0 (success), -1 (error) -struct kvm_memory_alias { - __u32 slot; /* this has a different namespace than memory slots */ - __u32 flags; - __u64 guest_phys_addr; - __u64 memory_size; - __u64 target_phys_addr; -}; - -Defines a guest physical address space region as an alias to another -region. Useful for aliased address, for example the VGA low memory -window. Should not be used with userspace memory. +This ioctl is obsolete and has been removed. 4.9 KVM_RUN -- cgit v1.1 From b74a07beed0e64bfba413dcb70dd6749c57f43dc Mon Sep 17 00:00:00 2001 From: Avi Kivity Date: Mon, 21 Jun 2010 11:48:05 +0300 Subject: KVM: Remove kernel-allocated memory regions Equivalent (and better) functionality is provided by user-allocated memory regions. Signed-off-by: Avi Kivity --- Documentation/feature-removal-schedule.txt | 10 ---------- Documentation/kvm/api.txt | 24 +----------------------- 2 files changed, 1 insertion(+), 33 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index ad1e90d..123ec0e 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -548,16 +548,6 @@ Who: John Stultz ---------------------------- -What: KVM kernel-allocated memory slots -When: July 2010 -Why: Since 2.6.25, kvm supports user-allocated memory slots, which are - much more flexible than kernel-allocated slots. All current userspace - supports the newer interface and this code can be removed with no - impact. -Who: Avi Kivity - ----------------------------- - What: KVM paravirt mmu host support When: January 2011 Why: The paravirt mmu host support is slower than non-paravirt mmu, both diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt index 7e41594..d9b00f1 100644 --- a/Documentation/kvm/api.txt +++ b/Documentation/kvm/api.txt @@ -160,29 +160,7 @@ Type: vm ioctl Parameters: struct kvm_memory_region (in) Returns: 0 on success, -1 on error -struct kvm_memory_region { - __u32 slot; - __u32 flags; - __u64 guest_phys_addr; - __u64 memory_size; /* bytes */ -}; - -/* for kvm_memory_region::flags */ -#define KVM_MEM_LOG_DIRTY_PAGES 1UL - -This ioctl allows the user to create or modify a guest physical memory -slot. When changing an existing slot, it may be moved in the guest -physical memory space, or its flags may be modified. It may not be -resized. Slots may not overlap. - -The flags field supports just one flag, KVM_MEM_LOG_DIRTY_PAGES, which -instructs kvm to keep track of writes to memory within the slot. See -the KVM_GET_DIRTY_LOG ioctl. - -It is recommended to use the KVM_SET_USER_MEMORY_REGION ioctl instead -of this API, if available. This newer API allows placing guest memory -at specified locations in the host address space, yielding better -control and easy access. +This ioctl is obsolete and has been removed. 4.6 KVM_CREATE_VCPU -- cgit v1.1 From cf3e3d3e19868ca01da163200bbfc687523df0fc Mon Sep 17 00:00:00 2001 From: Avi Kivity Date: Thu, 24 Jun 2010 14:10:09 +0300 Subject: KVM: Document KVM specific review items Signed-off-by: Avi Kivity Signed-off-by: Marcelo Tosatti --- Documentation/kvm/review-checklist.txt | 38 ++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 Documentation/kvm/review-checklist.txt (limited to 'Documentation') diff --git a/Documentation/kvm/review-checklist.txt b/Documentation/kvm/review-checklist.txt new file mode 100644 index 0000000..730475a --- /dev/null +++ b/Documentation/kvm/review-checklist.txt @@ -0,0 +1,38 @@ +Review checklist for kvm patches +================================ + +1. The patch must follow Documentation/CodingStyle and + Documentation/SubmittingPatches. + +2. Patches should be against kvm.git master branch. + +3. If the patch introduces or modifies a new userspace API: + - the API must be documented in Documentation/kvm/api.txt + - the API must be discoverable using KVM_CHECK_EXTENSION + +4. New state must include support for save/restore. + +5. New features must default to off (userspace should explicitly request them). + Performance improvements can and should default to on. + +6. New cpu features should be exposed via KVM_GET_SUPPORTED_CPUID2 + +7. Emulator changes should be accompanied by unit tests for qemu-kvm.git + kvm/test directory. + +8. Changes should be vendor neutral when possible. Changes to common code + are better than duplicating changes to vendor code. + +9. Similarly, prefer changes to arch independent code than to arch dependent + code. + +10. User/kernel interfaces and guest/host interfaces must be 64-bit clean + (all variables and sizes naturally aligned on 64-bit; use specific types + only - u64 rather than ulong). + +11. New guest visible features must either be documented in a hardware manual + or be accompanied by documentation. + +12. Features must be robust against reset and kexec - for example, shared + host/guest memory must be unshared to prevent the host from writing to + guest memory that the guest has not reserved for this purpose. -- cgit v1.1 From a027b33348df3512d7680eed29bada1247f01ad7 Mon Sep 17 00:00:00 2001 From: Anatolij Gustschin Date: Fri, 23 Jul 2010 04:00:38 +0000 Subject: powerpc/5121: doc/dts-bindings: update doc of FSL DIU bindings Update compatible and interrupt properties description. Furthermore an example for the MPC5121 has been added. Signed-off-by: Anatolij Gustschin Acked-by: Timur Tabi Signed-off-by: Grant Likely --- Documentation/powerpc/dts-bindings/fsl/diu.txt | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/powerpc/dts-bindings/fsl/diu.txt b/Documentation/powerpc/dts-bindings/fsl/diu.txt index deb35de..326cddf 100644 --- a/Documentation/powerpc/dts-bindings/fsl/diu.txt +++ b/Documentation/powerpc/dts-bindings/fsl/diu.txt @@ -4,10 +4,12 @@ The Freescale DIU is a LCD controller, with proper hardware, it can also drive DVI monitors. Required properties: -- compatible : should be "fsl-diu". +- compatible : should be "fsl,diu" or "fsl,mpc5121-diu". - reg : should contain at least address and length of the DIU register set. -- Interrupts : one DIU interrupt should be describe here. +- interrupts : one DIU interrupt should be described here. +- interrupt-parent : the phandle for the interrupt controller that + services interrupts for this device. Example (MPC8610HPCD): display@2c000 { @@ -16,3 +18,11 @@ Example (MPC8610HPCD): interrupts = <72 2>; interrupt-parent = <&mpic>; }; + +Example for MPC5121: + display@2100 { + compatible = "fsl,mpc5121-diu"; + reg = <0x2100 0x100>; + interrupts = <64 0x8>; + interrupt-parent = <&ipic>; + }; -- cgit v1.1 From 8b856f040c09024aa9d1f363c1a5cf2d3db73ebd Mon Sep 17 00:00:00 2001 From: Anatolij Gustschin Date: Fri, 23 Jul 2010 04:00:39 +0000 Subject: powerpc/fsl-diu-fb: Support setting display mode using EDID Adds support for encoding display mode information in the device tree using verbatim EDID block. If the EDID entry in the DIU node is present, the driver will build mode database using EDID data and allow setting the display modes from this database. Otherwise display mode will be set using mode entries from driver's internal database as usual. This patch also updates device tree bindings. Signed-off-by: Anatolij Gustschin Acked-by: Timur Tabi Signed-off-by: Grant Likely --- Documentation/powerpc/dts-bindings/fsl/diu.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/powerpc/dts-bindings/fsl/diu.txt b/Documentation/powerpc/dts-bindings/fsl/diu.txt index 326cddf..b66cb6d 100644 --- a/Documentation/powerpc/dts-bindings/fsl/diu.txt +++ b/Documentation/powerpc/dts-bindings/fsl/diu.txt @@ -11,6 +11,11 @@ Required properties: - interrupt-parent : the phandle for the interrupt controller that services interrupts for this device. +Optional properties: +- edid : verbatim EDID data block describing attached display. + Data from the detailed timing descriptor will be used to + program the display controller. + Example (MPC8610HPCD): display@2c000 { compatible = "fsl,diu"; @@ -25,4 +30,5 @@ Example for MPC5121: reg = <0x2100 0x100>; interrupts = <64 0x8>; interrupt-parent = <&ipic>; + edid = [edid-data]; }; -- cgit v1.1 From 0c2daaafcdec726e89cbccca61d576de8429c537 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Albrecht=20Dre=C3=9F?= Date: Wed, 17 Feb 2010 08:59:14 +0000 Subject: powerpc/5200/i2c: improve i2c bus error recovery MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This patch improves the recovery of the MPC's I2C bus from errors like bus hangs resulting in timeouts: 1. make the bus timeout configurable, as it depends on the bus clock and the attached slave chip(s); default is still 1 second; 2. detect any of the cases indicated by the CF, BB and RXAK MSR flags if a timeout occurs, and add a missing (required) MAL reset; 3. use a more reliable method to fixup the bus if a hang has been detected. The sequence is sent 9 times which seems to be necessary if a slave "misses" more than one clock cycle. For 400 kHz bus speed, the fixup is also ~70us (81us vs. 150us) faster. Tested on a custom Lite5200b derived board, with a Dallas RTC, AD sensors and NXP IO expander chips attached to the i2c. Changes vs. v1: - use improved bus fixup sequence for all chips (not only the 5200) - calculate real clock from defaults if no clock is given in the device tree - better description (I hope) of the changes. I didn't split the changes in this file into three parts as recommended by Grant, as they actually belong together (i.e. they address one single problem, just in three places of one single source file). Signed-off-by: Albrecht Dreß [grant.likely@secretlab.ca: fixup for ->node to ->dev.of_node transition] Signed-off-by: Grant Likely --- Documentation/powerpc/dts-bindings/fsl/i2c.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/powerpc/dts-bindings/fsl/i2c.txt b/Documentation/powerpc/dts-bindings/fsl/i2c.txt index 50da203..1eacd6b 100644 --- a/Documentation/powerpc/dts-bindings/fsl/i2c.txt +++ b/Documentation/powerpc/dts-bindings/fsl/i2c.txt @@ -20,6 +20,7 @@ Recommended properties : - fsl,preserve-clocking : boolean; if defined, the clock settings from the bootloader are preserved (not touched). - clock-frequency : desired I2C bus clock frequency in Hz. + - fsl,timeout : I2C bus timeout in microseconds. Examples : @@ -59,4 +60,5 @@ Examples : interrupts = <43 2>; interrupt-parent = <&mpic>; clock-frequency = <400000>; + fsl,timeout = <10000>; }; -- cgit v1.1 From 2e2602ca5df09e4c4e2b593bc30abead9a8617d4 Mon Sep 17 00:00:00 2001 From: Avi Kivity Date: Wed, 7 Jul 2010 14:09:39 +0300 Subject: KVM: Document MCE banks non-exposure via KVM_GET_MSR_INDEX_LIST Signed-off-by: Avi Kivity Signed-off-by: Marcelo Tosatti --- Documentation/kvm/api.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt index d9b00f1..179cc51 100644 --- a/Documentation/kvm/api.txt +++ b/Documentation/kvm/api.txt @@ -126,6 +126,10 @@ user fills in the size of the indices array in nmsrs, and in return kvm adjusts nmsrs to reflect the actual number of msrs and fills in the indices array with their numbers. +Note: if kvm indicates supports MCE (KVM_CAP_MCE), then the MCE bank MSRs are +not returned in the MSR list, as different vcpus can have a different number +of banks, as set via the KVM_X86_SETUP_MCE ioctl. + 4.4 KVM_CHECK_EXTENSION Capability: basic -- cgit v1.1 From d153513ddef5698a292b53790008b2e7660cd08d Mon Sep 17 00:00:00 2001 From: Avi Kivity Date: Wed, 14 Jul 2010 09:45:21 +0300 Subject: KVM: Document KVM_GET_SUPPORTED_CPUID2 ioctl Signed-off-by: Avi Kivity Signed-off-by: Marcelo Tosatti --- Documentation/kvm/api.txt | 64 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt index 179cc51..5f5b649 100644 --- a/Documentation/kvm/api.txt +++ b/Documentation/kvm/api.txt @@ -968,6 +968,70 @@ struct kvm_xcrs { This ioctl would set vcpu's xcr to the value userspace specified. +4.45 KVM_GET_SUPPORTED_CPUID + +Capability: KVM_CAP_EXT_CPUID +Architectures: x86 +Type: system ioctl +Parameters: struct kvm_cpuid2 (in/out) +Returns: 0 on success, -1 on error + +struct kvm_cpuid2 { + __u32 nent; + __u32 padding; + struct kvm_cpuid_entry2 entries[0]; +}; + +#define KVM_CPUID_FLAG_SIGNIFCANT_INDEX 1 +#define KVM_CPUID_FLAG_STATEFUL_FUNC 2 +#define KVM_CPUID_FLAG_STATE_READ_NEXT 4 + +struct kvm_cpuid_entry2 { + __u32 function; + __u32 index; + __u32 flags; + __u32 eax; + __u32 ebx; + __u32 ecx; + __u32 edx; + __u32 padding[3]; +}; + +This ioctl returns x86 cpuid features which are supported by both the hardware +and kvm. Userspace can use the information returned by this ioctl to +construct cpuid information (for KVM_SET_CPUID2) that is consistent with +hardware, kernel, and userspace capabilities, and with user requirements (for +example, the user may wish to constrain cpuid to emulate older hardware, +or for feature consistency across a cluster). + +Userspace invokes KVM_GET_SUPPORTED_CPUID by passing a kvm_cpuid2 structure +with the 'nent' field indicating the number of entries in the variable-size +array 'entries'. If the number of entries is too low to describe the cpu +capabilities, an error (E2BIG) is returned. If the number is too high, +the 'nent' field is adjusted and an error (ENOMEM) is returned. If the +number is just right, the 'nent' field is adjusted to the number of valid +entries in the 'entries' array, which is then filled. + +The entries returned are the host cpuid as returned by the cpuid instruction, +with unknown or unsupported features masked out. The fields in each entry +are defined as follows: + + function: the eax value used to obtain the entry + index: the ecx value used to obtain the entry (for entries that are + affected by ecx) + flags: an OR of zero or more of the following: + KVM_CPUID_FLAG_SIGNIFCANT_INDEX: + if the index field is valid + KVM_CPUID_FLAG_STATEFUL_FUNC: + if cpuid for this function returns different values for successive + invocations; there will be several entries with the same function, + all with this flag set + KVM_CPUID_FLAG_STATE_READ_NEXT: + for KVM_CPUID_FLAG_STATEFUL_FUNC entries, set if this entry is + the first entry to be read by a cpu + eax, ebx, ecx, edx: the values returned by the cpuid instruction for + this function/index combination + 5. The kvm_run structure Application code obtains a pointer to the kvm_run structure by -- cgit v1.1 From e6f6a4cc955d626ed26562d98de5766bf1f73526 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Tue, 27 Jul 2010 17:17:06 +0900 Subject: TOMOYO: Update version to 2.3.0 Signed-off-by: Tetsuo Handa Signed-off-by: James Morris --- Documentation/tomoyo.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/tomoyo.txt b/Documentation/tomoyo.txt index b3a232c..200a2d3 100644 --- a/Documentation/tomoyo.txt +++ b/Documentation/tomoyo.txt @@ -3,8 +3,8 @@ TOMOYO is a name-based MAC extension (LSM module) for the Linux kernel. LiveCD-based tutorials are available at -http://tomoyo.sourceforge.jp/en/1.6.x/1st-step/ubuntu8.04-live/ -http://tomoyo.sourceforge.jp/en/1.6.x/1st-step/centos5-live/ . +http://tomoyo.sourceforge.jp/1.7/1st-step/ubuntu10.04-live/ +http://tomoyo.sourceforge.jp/1.7/1st-step/centos5-live/ . Though these tutorials use non-LSM version of TOMOYO, they are useful for you to know what TOMOYO is. @@ -13,12 +13,12 @@ to know what TOMOYO is. Build the kernel with CONFIG_SECURITY_TOMOYO=y and pass "security=tomoyo" on kernel's command line. -Please see http://tomoyo.sourceforge.jp/en/2.2.x/ for details. +Please see http://tomoyo.sourceforge.jp/2.3/ for details. --- Where is documentation? --- User <-> Kernel interface documentation is available at -http://tomoyo.sourceforge.jp/en/2.2.x/policy-reference.html . +http://tomoyo.sourceforge.jp/2.3/policy-reference.html . Materials we prepared for seminars and symposiums are available at http://sourceforge.jp/projects/tomoyo/docs/?category_id=532&language_id=1 . @@ -50,6 +50,6 @@ multiple LSM modules at the same time. We feel sorry that you have to give up SELinux/SMACK/AppArmor etc. when you want to use TOMOYO. We hope that LSM becomes stackable in future. Meanwhile, you can use non-LSM -version of TOMOYO, available at http://tomoyo.sourceforge.jp/en/1.6.x/ . +version of TOMOYO, available at http://tomoyo.sourceforge.jp/1.7/ . LSM version of TOMOYO is a subset of non-LSM version of TOMOYO. We are planning to port non-LSM version's functionalities to LSM versions. -- cgit v1.1 From c1c124e91e7c6d5a600c98f6fb5b443c403a14f4 Mon Sep 17 00:00:00 2001 From: John Johansen Date: Thu, 29 Jul 2010 14:48:09 -0700 Subject: AppArmor: update Maintainer and Documentation Signed-off-by: John Johansen Signed-off-by: James Morris --- Documentation/apparmor.txt | 39 +++++++++++++++++++++++++++++++++++++ Documentation/kernel-parameters.txt | 8 ++++++++ 2 files changed, 47 insertions(+) create mode 100644 Documentation/apparmor.txt (limited to 'Documentation') diff --git a/Documentation/apparmor.txt b/Documentation/apparmor.txt new file mode 100644 index 0000000..93c1fd7 --- /dev/null +++ b/Documentation/apparmor.txt @@ -0,0 +1,39 @@ +--- What is AppArmor? --- + +AppArmor is MAC style security extension for the Linux kernel. It implements +a task centered policy, with task "profiles" being created and loaded +from user space. Tasks on the system that do not have a profile defined for +them run in an unconfined state which is equivalent to standard Linux DAC +permissions. + +--- How to enable/disable --- + +set CONFIG_SECURITY_APPARMOR=y + +If AppArmor should be selected as the default security module then + set CONFIG_DEFAULT_SECURITY="apparmor" + and CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1 + +Build the kernel + +If AppArmor is not the default security module it can be enabled by passing +security=apparmor on the kernel's command line. + +If AppArmor is the default security module it can be disabled by passing +apparmor=0, security=XXXX (where XXX is valid security module), on the +kernel's command line + +For AppArmor to enforce any restrictions beyond standard Linux DAC permissions +policy must be loaded into the kernel from user space (see the Documentation +and tools links). + +--- Documentation --- + +Documentation can be found on the wiki. + +--- Links --- + +Mailing List - apparmor@lists.ubuntu.com +Wiki - http://apparmor.wiki.kernel.org/ +User space tools - https://launchpad.net/apparmor +Kernel module - git://git.kernel.org/pub/scm/linux/kernel/git/jj/apparmor-dev.git diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 2b2407d..b61f89f 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -93,6 +93,7 @@ parameter is applicable: Documentation/scsi/. SECURITY Different security models are enabled. SELINUX SELinux support is enabled. + APPARMOR AppArmor support is enabled. SERIAL Serial support is enabled. SH SuperH architecture is enabled. SMP The kernel is an SMP kernel. @@ -2312,6 +2313,13 @@ and is between 256 and 4096 characters. It is defined in the file If enabled at boot time, /selinux/disable can be used later to disable prior to initial policy load. + apparmor= [APPARMOR] Disable or enable AppArmor at boot time + Format: { "0" | "1" } + See security/apparmor/Kconfig help text + 0 -- disable. + 1 -- enable. + Default value is set via kernel config option. + serialnumber [BUGS=X86-32] shapers= [NET] -- cgit v1.1 From 618a864ee7b720aa3560796e0dfad0e674366e60 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jean-Fran=C3=A7ois=20Moine?= Date: Sat, 5 Jun 2010 07:45:04 -0300 Subject: V4L/DVB: gspca - sq930x: New subdriver MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Jean-François Moine Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/gspca.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index f13eb03..a258107 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt @@ -29,8 +29,12 @@ zc3xx 041e:4029 Creative WebCam Vista Pro zc3xx 041e:4034 Creative Instant P0620 zc3xx 041e:4035 Creative Instant P0620D zc3xx 041e:4036 Creative Live ! +sq930x 041e:4038 Creative Joy-IT zc3xx 041e:403a Creative Nx Pro 2 spca561 041e:403b Creative Webcam Vista (VF0010) +sq930x 041e:403c Creative Live! Ultra +sq930x 041e:403d Creative Live! Ultra for Notebooks +sq930x 041e:4041 Creative Live! Motion zc3xx 041e:4051 Creative Live!Cam Notebook Pro (VF0250) ov519 041e:4052 Creative Live! VISTA IM zc3xx 041e:4053 Creative Live!Cam Video IM @@ -362,6 +366,8 @@ sq905c 2770:9052 Disney pix micro 2 (VGA) sq905c 2770:905c All 11 known cameras with this ID sq905 2770:9120 All 24 known cameras with this ID sq905c 2770:913d All 4 known cameras with this ID +sq930x 2770:930b Sweex Motion Tracking / I-Tec iCam Tracer +sq930x 2770:930c Trust WB-3500T / NSG Robbie 2.0 spca500 2899:012c Toptro Industrial ov519 8020:ef04 ov519 spca508 8086:0110 Intel Easy PC Camera -- cgit v1.1 From 5b0ff8c43afefbd42a1aa3cd89808eec829bbbb7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jean-Fran=C3=A7ois=20Moine?= Date: Sat, 5 Jun 2010 07:57:56 -0300 Subject: V4L/DVB: gspca - spca1528: New subdriver MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Jean-François Moine Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/gspca.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index a258107..58adb71 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt @@ -142,6 +142,7 @@ finepix 04cb:013d Fujifilm FinePix unknown model finepix 04cb:013f Fujifilm FinePix F420 sunplus 04f1:1001 JVC GC A50 spca561 04fc:0561 Flexcam 100 +spca1528 04fc:1528 Sunplus MD80 clone sunplus 04fc:500c Sunplus CA500C sunplus 04fc:504a Aiptek Mini PenCam 1.3 sunplus 04fc:504b Maxell MaxPocket LE 1.3 -- cgit v1.1 From 4e6aeefeb822c70d70de4d3b9970939e5de9c647 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?M=C3=A1rton=20N=C3=A9meth?= Date: Mon, 14 Jun 2010 17:21:37 -0300 Subject: V4L/DVB: gspca - pac7302: add Genius iSlim 310 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add Genius iSlim 310 webcam to the supported list of the PAC7302 driver. For more information see http://linuxtv.org/wiki/index.php/PixArt_PAC7301/PAC7302 . Signed-off-by: Márton Németh Signed-off-by: Jean-François Moine Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/gspca.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index 58adb71..56ba7bb 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt @@ -258,6 +258,7 @@ pac7302 093a:2620 Apollo AC-905 pac7302 093a:2621 PAC731x pac7302 093a:2622 Genius Eye 312 pac7302 093a:2624 PAC7302 +pac7302 093a:2625 Genius iSlim 310 pac7302 093a:2626 Labtec 2200 pac7302 093a:2628 Genius iLook 300 pac7302 093a:2629 Genious iSlim 300 -- cgit v1.1 From 8d3557e21d0b305392ac73a64411dfab0e794960 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 3 Jul 2010 17:39:17 -0300 Subject: V4L/DVB: DocBook/dvb: Update spec to reflect the current FE capabilities Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/dvb/dvbapi.xml | 19 ++++++++++++++++--- Documentation/DocBook/dvb/frontend.h.xml | 1 + Documentation/DocBook/dvb/frontend.xml | 10 ++++++++-- Documentation/DocBook/media.tmpl | 4 ++-- 4 files changed, 27 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/dvb/dvbapi.xml b/Documentation/DocBook/dvb/dvbapi.xml index 63c528f..e3a97fd 100644 --- a/Documentation/DocBook/dvb/dvbapi.xml +++ b/Documentation/DocBook/dvb/dvbapi.xml @@ -12,10 +12,12 @@ O. C.
rjkm@metzlerbros.de
 + + Mauro -Chehab Carvalho +Chehab
mchehab@redhat.com
 Ported document to Docbook XML. @@ -23,13 +25,24 @@ 2002 2003 - 2009 Convergence GmbH + + 2009-2010 + Mauro Carvalho Chehab + + 2.0.3 + 2010-07-03 + mcc + + Add some frontend capabilities flags, present on kernel, but missing at the specs. + + + 2.0.2 2009-10-25 mcc @@ -63,7 +76,7 @@ Added ISDB-T test originally written by Patrick Boettcher LINUX DVB API -Version 3 +Version 5.2 &sub-intro; diff --git a/Documentation/DocBook/dvb/frontend.h.xml b/Documentation/DocBook/dvb/frontend.h.xml index b99644f..d08e0d4 100644 --- a/Documentation/DocBook/dvb/frontend.h.xml +++ b/Documentation/DocBook/dvb/frontend.h.xml @@ -63,6 +63,7 @@ typedef enum fe_caps { FE_CAN_8VSB = 0x200000, FE_CAN_16VSB = 0x400000, FE_HAS_EXTENDED_CAPS = 0x800000, /* We need more bitspace for newer APIs, indicate this. */ + FE_CAN_TURBO_FEC = 0x8000000, /* frontend supports "turbo fec modulation" */ FE_CAN_2G_MODULATION = 0x10000000, /* frontend supports "2nd generation modulation" (DVB-S2) */ FE_NEEDS_BENDING = 0x20000000, /* not supported anymore, don't use (frontend requires frequency bending) */ FE_CAN_RECOVER = 0x40000000, /* frontend can recover from a cable unplug automatically */ diff --git a/Documentation/DocBook/dvb/frontend.xml b/Documentation/DocBook/dvb/frontend.xml index 300ba1f..78d756d 100644 --- a/Documentation/DocBook/dvb/frontend.xml +++ b/Documentation/DocBook/dvb/frontend.xml @@ -64,8 +64,14 @@ a specific frontend type. FE_CAN_BANDWIDTH_AUTO = 0x40000, FE_CAN_GUARD_INTERVAL_AUTO = 0x80000, FE_CAN_HIERARCHY_AUTO = 0x100000, - FE_CAN_MUTE_TS = 0x80000000, - FE_CAN_CLEAN_SETUP = 0x40000000 + FE_CAN_8VSB = 0x200000, + FE_CAN_16VSB = 0x400000, + FE_HAS_EXTENDED_CAPS = 0x800000, + FE_CAN_TURBO_FEC = 0x8000000, + FE_CAN_2G_MODULATION = 0x10000000, + FE_NEEDS_BENDING = 0x20000000, + FE_CAN_RECOVER = 0x40000000, + FE_CAN_MUTE_TS = 0x80000000 } fe_caps_t; diff --git a/Documentation/DocBook/media.tmpl b/Documentation/DocBook/media.tmpl index eea564b..fe10bd7 100644 --- a/Documentation/DocBook/media.tmpl +++ b/Documentation/DocBook/media.tmpl @@ -28,7 +28,7 @@ LINUX MEDIA INFRASTRUCTURE API - 2009 + 2009-2010 LinuxTV Developers @@ -86,7 +86,7 @@ Foundation. A copy of the license is included in the chapter entitled - 2009 + 2009-2010 Mauro Carvalho Chehab -- cgit v1.1 From f0cae143e113d28ab89a930934c36f619c4367f0 Mon Sep 17 00:00:00 2001 From: Jarod Wilson Date: Sat, 3 Jul 2010 01:10:09 -0300 Subject: V4L/DVB: IR/lirc: add docbook info covering lirc device interface First ever crack at creating docbook documentation... Contains a bevy of information on the various lirc device interface ioctls, as well as a bit about the read and write interfaces. Signed-off-by: Jarod Wilson Signed-off-by: Mauro Carvalho Chehab --- .../DocBook/v4l/lirc_device_interface.xml | 235 +++++++++++++++++++++ 1 file changed, 235 insertions(+) create mode 100644 Documentation/DocBook/v4l/lirc_device_interface.xml (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/lirc_device_interface.xml b/Documentation/DocBook/v4l/lirc_device_interface.xml new file mode 100644 index 0000000..d9ae680 --- /dev/null +++ b/Documentation/DocBook/v4l/lirc_device_interface.xml @@ -0,0 +1,235 @@ +LIRC Device Interface + + +
+Introduction + +The LIRC device interface is a bi-directional interface for +transporting raw IR data between userspace and kernelspace. Fundamentally, +it is just a chardev (/dev/lircX, for X = 0, 1, 2, ...), with a number +of standard struct file_operations defined on it. With respect to +transporting raw IR data to and fro, the essential fops are read, write +and ioctl. + +Example dmesg output upon a driver registering w/LIRC: +
+ $ dmesg |grep lirc_dev + lirc_dev: IR Remote Control driver registered, major 248 + rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0 +
+ + +What you should see for a chardev: +
+ $ ls -l /dev/lirc* + crw-rw---- 1 root root 248, 0 Jul 2 22:20 /dev/lirc0 +
+ + + +
+LIRC read fop + +The lircd userspace daemon reads raw IR data from the LIRC chardev. The +exact format of the data depends on what modes a driver supports, and what +mode has been selected. lircd obtains supported modes and sets the active mode +via the ioctl interface, detailed at . The generally +preferred mode is LIRC_MODE_MODE2, in which packets containing an int value +describing an IR signal are read from the chardev. + +See also http://www.lirc.org/html/technical.html for more info. + + +
+LIRC write fop + +The data written to the chardev is a pulse/space sequence of integer +values. Pulses and spaces are only marked implicitly by their position. The +data must start and end with a pulse, therefore, the data must always include +an unevent number of samples. The write function must block until the data has +been transmitted by the hardware. + + +
+ LIRC ioctl fop + +The LIRC device's ioctl definition is bound by the ioctl function +definition of struct file_operations, leaving us with an unsigned int +for the ioctl command and an unsigned long for the arg. For the purposes +of ioctl portability across 32-bit and 64-bit, these values are capped +to their 32-bit sizes. + +The following ioctls can be used to change specific hardware settings. +In general each driver should have a default set of settings. The driver +implementation is expected to re-apply the default settings when the device +is closed by user-space, so that every application opening the device can rely +on working with the default settings initially. + + + + LIRC_GET_FEATURES + + Obviously, get the underlying hardware device's features. If a driver + does not announce support of certain features, calling of the corresponding + ioctls is undefined. + + + + LIRC_GET_SEND_MODE + + Get supported transmit mode. Only LIRC_MODE_PULSE is supported by lircd. + + + + LIRC_GET_REC_MODE + + Get supported receive modes. Only LIRC_MODE_MODE2 and LIRC_MODE_LIRCCODE + are supported by lircd. + + + + LIRC_GET_SEND_CARRIER + + Get carrier frequency (in Hz) currently used for transmit. + + + + LIRC_GET_REC_CARRIER + + Get carrier frequency (in Hz) currently used for IR reception. + + + + LIRC_{G,S}ET_{SEND,REC}_DUTY_CYCLE + + Get/set the duty cycle (from 0 to 100) of the carrier signal. Currently, + no special meaning is defined for 0 or 100, but this could be used to switch + off carrier generation in the future, so these values should be reserved. + + + + LIRC_GET_REC_RESOLUTION + + Some receiver have maximum resolution which is defined by internal + sample rate or data format limitations. E.g. it's common that signals can + only be reported in 50 microsecond steps. This integer value is used by + lircd to automatically adjust the aeps tolerance value in the lircd + config file. + + + + LIRC_GET_M{IN,AX}_TIMEOUT + + Some devices have internal timers that can be used to detect when + there's no IR activity for a long time. This can help lircd in detecting + that a IR signal is finished and can speed up the decoding process. + Returns an integer value with the minimum/maximum timeout that can be + set. Some devices have a fixed timeout, in that case both ioctls will + return the same value even though the timeout cannot be changed. + + + + LIRC_GET_M{IN,AX}_FILTER_{PULSE,SPACE} + + Some devices are able to filter out spikes in the incoming signal + using given filter rules. These ioctls return the hardware capabilities + that describe the bounds of the possible filters. Filter settings depend + on the IR protocols that are expected. lircd derives the settings from + all protocols definitions found in its config file. + + + + LIRC_GET_LENGTH + + Retrieves the code length in bits (only for LIRC_MODE_LIRCCODE). + Reads on the device must be done in blocks matching the bit count. + The bit could should be rounded up so that it matches full bytes. + + + + LIRC_SET_{SEND,REC}_MODE + + Set send/receive mode. Largely obsolete for send, as only + LIRC_MODE_PULSE is supported. + + + + LIRC_SET_{SEND,REC}_CARRIER + + Set send/receive carrier (in Hz). + + + + LIRC_SET_TRANSMITTER_MASK + + This enables the given set of transmitters. The first transmitter + is encoded by the least significant bit, etc. When an invalid bit mask + is given, i.e. a bit is set, even though the device does not have so many + transitters, then this ioctl returns the number of available transitters + and does nothing otherwise. + + + + LIRC_SET_REC_TIMEOUT + + Sets the integer value for IR inactivity timeout (cf. + LIRC_GET_MIN_TIMEOUT and LIRC_GET_MAX_TIMEOUT). A value of 0 (if + supported by the hardware) disables all hardware timeouts and data should + be reported as soon as possible. If the exact value cannot be set, then + the next possible value _greater_ than the given value should be set. + + + + LIRC_SET_REC_TIMEOUT_REPORTS + + Enable (1) or disable (0) timeout reports in LIRC_MODE_MODE2. By + default, timeout reports should be turned off. + + + + LIRC_SET_REC_FILTER_{,PULSE,SPACE} + + Pulses/spaces shorter than this are filtered out by hardware. If + filters cannot be set independently for pulse/space, the corresponding + ioctls must return an error and LIRC_SET_REC_FILTER shall be used instead. + + + + LIRC_SET_MEASURE_CARRIER_MODE + + Enable (1)/disable (0) measure mode. If enabled, from the next key + press on, the driver will send LIRC_MODE2_FREQUENCY packets. By default + this should be turned off. + + + + LIRC_SET_REC_{DUTY_CYCLE,CARRIER}_RANGE + + To set a range use LIRC_SET_REC_DUTY_CYCLE_RANGE/LIRC_SET_REC_CARRIER_RANGE + with the lower bound first and later LIRC_SET_REC_DUTY_CYCLE/LIRC_SET_REC_CARRIER + with the upper bound. + + + + LIRC_NOTIFY_DECODE + + This ioctl is called by lircd whenever a successful decoding of an + incoming IR signal could be done. This can be used by supporting hardware + to give visual feedback to the user e.g. by flashing a LED. + + + + LIRC_SETUP_{START,END} + + Setting of several driver parameters can be optimized by encapsulating + the according ioctl calls with LIRC_SETUP_START/LIRC_SETUP_END. When a + driver receives a LIRC_SETUP_START ioctl it can choose to not commit + further setting changes to the hardware until a LIRC_SETUP_END is received. + But this is open to the driver implementation and every driver must also + handle parameter changes which are not encapsulated by LIRC_SETUP_START + and LIRC_SETUP_END. Drivers can also choose to ignore these ioctls. + + + + +
-- cgit v1.1 From fab8125919c0fc724e11b184b1c812dfb8990549 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sun, 4 Jul 2010 12:23:19 -0300 Subject: V4L/DVB: DocBook/media: Add LIRC DocBook to media.html Add LIRC interface into the media.html DocBook, fixing several small XML errors at the original spec. Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media-entities.tmpl | 1 + Documentation/DocBook/media.tmpl | 4 +- .../DocBook/v4l/lirc_device_interface.xml | 88 +++++++++++----------- Documentation/DocBook/v4l/remote_controllers.xml | 2 + 4 files changed, 49 insertions(+), 46 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index 5d4d40f4..6ae9715 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -218,6 +218,7 @@ + diff --git a/Documentation/DocBook/media.tmpl b/Documentation/DocBook/media.tmpl index fe10bd7..f11048d 100644 --- a/Documentation/DocBook/media.tmpl +++ b/Documentation/DocBook/media.tmpl @@ -61,7 +61,7 @@ Foundation. A copy of the license is included in the chapter entitled in fact it covers several different video standards including DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated to documment support also for DVB-S2, ISDB-T and ISDB-S. - The third part covers other API's used by all media infrastructure devices + The third part covers Remote Controller API For additional information and for the latest development code, see: http://linuxtv.org. For discussing improvements, reporting troubles, sending new drivers, etc, please mail to: Linux Media Mailing List (LMML).. @@ -101,7 +101,7 @@ Foundation. A copy of the license is included in the chapter entitled -Other API's used by media infrastructure drivers +Remote Controller API &sub-remote_controllers; diff --git a/Documentation/DocBook/v4l/lirc_device_interface.xml b/Documentation/DocBook/v4l/lirc_device_interface.xml index d9ae680..0413234 100644 --- a/Documentation/DocBook/v4l/lirc_device_interface.xml +++ b/Documentation/DocBook/v4l/lirc_device_interface.xml @@ -1,3 +1,4 @@ +
LIRC Device Interface @@ -17,15 +18,13 @@ and ioctl. lirc_dev: IR Remote Control driver registered, major 248 rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0 - What you should see for a chardev:
$ ls -l /dev/lirc* crw-rw---- 1 root root 248, 0 Jul 2 22:20 /dev/lirc0
- - +
LIRC read fop @@ -33,12 +32,12 @@ and ioctl. The lircd userspace daemon reads raw IR data from the LIRC chardev. The exact format of the data depends on what modes a driver supports, and what mode has been selected. lircd obtains supported modes and sets the active mode -via the ioctl interface, detailed at . The generally +via the ioctl interface, detailed at . The generally preferred mode is LIRC_MODE_MODE2, in which packets containing an int value describing an IR signal are read from the chardev. -See also http://www.lirc.org/html/technical.html for more info. - +See also http://www.lirc.org/html/technical.html for more info. +
LIRC write fop @@ -48,10 +47,10 @@ values. Pulses and spaces are only marked implicitly by their position. The data must start and end with a pulse, therefore, the data must always include an unevent number of samples. The write function must block until the data has been transmitted by the hardware. - +
- LIRC ioctl fop +LIRC ioctl fop The LIRC device's ioctl definition is bound by the ioctl function definition of struct file_operations, leaving us with an unsigned int @@ -69,167 +68,168 @@ on working with the default settings initially. LIRC_GET_FEATURES - Obviously, get the underlying hardware device's features. If a driver + Obviously, get the underlying hardware device's features. If a driver does not announce support of certain features, calling of the corresponding - ioctls is undefined. + ioctls is undefined. LIRC_GET_SEND_MODE - Get supported transmit mode. Only LIRC_MODE_PULSE is supported by lircd. + Get supported transmit mode. Only LIRC_MODE_PULSE is supported by lircd. LIRC_GET_REC_MODE - Get supported receive modes. Only LIRC_MODE_MODE2 and LIRC_MODE_LIRCCODE - are supported by lircd. + Get supported receive modes. Only LIRC_MODE_MODE2 and LIRC_MODE_LIRCCODE + are supported by lircd. LIRC_GET_SEND_CARRIER - Get carrier frequency (in Hz) currently used for transmit. + Get carrier frequency (in Hz) currently used for transmit. LIRC_GET_REC_CARRIER - Get carrier frequency (in Hz) currently used for IR reception. + Get carrier frequency (in Hz) currently used for IR reception. LIRC_{G,S}ET_{SEND,REC}_DUTY_CYCLE - Get/set the duty cycle (from 0 to 100) of the carrier signal. Currently, + Get/set the duty cycle (from 0 to 100) of the carrier signal. Currently, no special meaning is defined for 0 or 100, but this could be used to switch - off carrier generation in the future, so these values should be reserved. + off carrier generation in the future, so these values should be reserved. LIRC_GET_REC_RESOLUTION - Some receiver have maximum resolution which is defined by internal + Some receiver have maximum resolution which is defined by internal sample rate or data format limitations. E.g. it's common that signals can only be reported in 50 microsecond steps. This integer value is used by lircd to automatically adjust the aeps tolerance value in the lircd - config file. + config file. LIRC_GET_M{IN,AX}_TIMEOUT - Some devices have internal timers that can be used to detect when + Some devices have internal timers that can be used to detect when there's no IR activity for a long time. This can help lircd in detecting that a IR signal is finished and can speed up the decoding process. Returns an integer value with the minimum/maximum timeout that can be set. Some devices have a fixed timeout, in that case both ioctls will - return the same value even though the timeout cannot be changed. + return the same value even though the timeout cannot be changed. LIRC_GET_M{IN,AX}_FILTER_{PULSE,SPACE} - Some devices are able to filter out spikes in the incoming signal + Some devices are able to filter out spikes in the incoming signal using given filter rules. These ioctls return the hardware capabilities that describe the bounds of the possible filters. Filter settings depend on the IR protocols that are expected. lircd derives the settings from - all protocols definitions found in its config file. + all protocols definitions found in its config file. LIRC_GET_LENGTH - Retrieves the code length in bits (only for LIRC_MODE_LIRCCODE). + Retrieves the code length in bits (only for LIRC_MODE_LIRCCODE). Reads on the device must be done in blocks matching the bit count. - The bit could should be rounded up so that it matches full bytes. + The bit could should be rounded up so that it matches full bytes. LIRC_SET_{SEND,REC}_MODE - Set send/receive mode. Largely obsolete for send, as only - LIRC_MODE_PULSE is supported. + Set send/receive mode. Largely obsolete for send, as only + LIRC_MODE_PULSE is supported. LIRC_SET_{SEND,REC}_CARRIER - Set send/receive carrier (in Hz). + Set send/receive carrier (in Hz). LIRC_SET_TRANSMITTER_MASK - This enables the given set of transmitters. The first transmitter + This enables the given set of transmitters. The first transmitter is encoded by the least significant bit, etc. When an invalid bit mask is given, i.e. a bit is set, even though the device does not have so many transitters, then this ioctl returns the number of available transitters - and does nothing otherwise. + and does nothing otherwise. LIRC_SET_REC_TIMEOUT - Sets the integer value for IR inactivity timeout (cf. + Sets the integer value for IR inactivity timeout (cf. LIRC_GET_MIN_TIMEOUT and LIRC_GET_MAX_TIMEOUT). A value of 0 (if supported by the hardware) disables all hardware timeouts and data should be reported as soon as possible. If the exact value cannot be set, then - the next possible value _greater_ than the given value should be set. + the next possible value _greater_ than the given value should be set. LIRC_SET_REC_TIMEOUT_REPORTS - Enable (1) or disable (0) timeout reports in LIRC_MODE_MODE2. By - default, timeout reports should be turned off. + Enable (1) or disable (0) timeout reports in LIRC_MODE_MODE2. By + default, timeout reports should be turned off. LIRC_SET_REC_FILTER_{,PULSE,SPACE} - Pulses/spaces shorter than this are filtered out by hardware. If + Pulses/spaces shorter than this are filtered out by hardware. If filters cannot be set independently for pulse/space, the corresponding - ioctls must return an error and LIRC_SET_REC_FILTER shall be used instead. + ioctls must return an error and LIRC_SET_REC_FILTER shall be used instead. LIRC_SET_MEASURE_CARRIER_MODE - Enable (1)/disable (0) measure mode. If enabled, from the next key + Enable (1)/disable (0) measure mode. If enabled, from the next key press on, the driver will send LIRC_MODE2_FREQUENCY packets. By default - this should be turned off. + this should be turned off. LIRC_SET_REC_{DUTY_CYCLE,CARRIER}_RANGE - To set a range use LIRC_SET_REC_DUTY_CYCLE_RANGE/LIRC_SET_REC_CARRIER_RANGE + To set a range use LIRC_SET_REC_DUTY_CYCLE_RANGE/LIRC_SET_REC_CARRIER_RANGE with the lower bound first and later LIRC_SET_REC_DUTY_CYCLE/LIRC_SET_REC_CARRIER - with the upper bound. + with the upper bound. LIRC_NOTIFY_DECODE - This ioctl is called by lircd whenever a successful decoding of an + This ioctl is called by lircd whenever a successful decoding of an incoming IR signal could be done. This can be used by supporting hardware - to give visual feedback to the user e.g. by flashing a LED. + to give visual feedback to the user e.g. by flashing a LED. LIRC_SETUP_{START,END} - Setting of several driver parameters can be optimized by encapsulating + Setting of several driver parameters can be optimized by encapsulating the according ioctl calls with LIRC_SETUP_START/LIRC_SETUP_END. When a driver receives a LIRC_SETUP_START ioctl it can choose to not commit further setting changes to the hardware until a LIRC_SETUP_END is received. But this is open to the driver implementation and every driver must also handle parameter changes which are not encapsulated by LIRC_SETUP_START - and LIRC_SETUP_END. Drivers can also choose to ignore these ioctls. + and LIRC_SETUP_END. Drivers can also choose to ignore these ioctls.
+
diff --git a/Documentation/DocBook/v4l/remote_controllers.xml b/Documentation/DocBook/v4l/remote_controllers.xml index 73f5eab..3c3b667b 100644 --- a/Documentation/DocBook/v4l/remote_controllers.xml +++ b/Documentation/DocBook/v4l/remote_controllers.xml @@ -173,3 +173,5 @@ keymapping. This program demonstrates how to replace the keymap tables. &sub-keytable-c;
+ +&sub-lirc_device_interface; -- cgit v1.1 From 566789f6b0b6d4c6ec1618412184f05c7aa85f4d Mon Sep 17 00:00:00 2001 From: Amerigo Wang Date: Fri, 28 May 2010 06:26:32 -0300 Subject: V4L/DVB: Remove usbvideo quickcam_messenger driver obsolete v4l1 driver replaced by gspca_stv06xx Signed-off-by: Amerigo Wang Signed-off-by: Mauro Carvalho Chehab --- Documentation/feature-removal-schedule.txt | 8 -------- 1 file changed, 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 1571c0c..1ec3eb3 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -459,14 +459,6 @@ Who: Corentin Chary ---------------------------- -What: usbvideo quickcam_messenger driver -When: 2.6.35 -Files: drivers/media/video/usbvideo/quickcam_messenger.[ch] -Why: obsolete v4l1 driver replaced by gspca_stv06xx -Who: Hans de Goede - ----------------------------- - What: ov511 v4l1 driver When: 2.6.35 Files: drivers/media/video/ov511.[ch] -- cgit v1.1 From 7373ab3669aec93f8c8f1ace7845c41d54ed6e3e Mon Sep 17 00:00:00 2001 From: Amerigo Wang Date: Fri, 28 May 2010 06:31:39 -0300 Subject: V4L/DVB: Remove obsolete ov511 driver obsolete v4l1 driver replaced by gspca_ov519 Signed-off-by: Amerigo Wang Signed-off-by: Mauro Carvalho Chehab --- Documentation/feature-removal-schedule.txt | 8 -------- 1 file changed, 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 1ec3eb3..79ef731 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -459,14 +459,6 @@ Who: Corentin Chary ---------------------------- -What: ov511 v4l1 driver -When: 2.6.35 -Files: drivers/media/video/ov511.[ch] -Why: obsolete v4l1 driver replaced by gspca_ov519 -Who: Hans de Goede - ----------------------------- - What: w9968cf v4l1 driver When: 2.6.35 Files: drivers/media/video/w9968cf*.[ch] -- cgit v1.1 From 51c555690d16d1d1354ee9b5a3c9098766702094 Mon Sep 17 00:00:00 2001 From: Amerigo Wang Date: Fri, 28 May 2010 06:41:07 -0300 Subject: V4L/DVB: Remove obsolete w9968cf v4l1 driver >From a97df96226e89d3539be93ddb5a8df3a2f7edcb6 Mon Sep 17 00:00:00 2001 obsolete v4l1 driver replaced by gspca_ov519 Signed-off-by: Amerigo Wang Signed-off-by: Mauro Carvalho Chehab --- Documentation/feature-removal-schedule.txt | 8 -------- 1 file changed, 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 79ef731..d4c9894 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -459,14 +459,6 @@ Who: Corentin Chary ---------------------------- -What: w9968cf v4l1 driver -When: 2.6.35 -Files: drivers/media/video/w9968cf*.[ch] -Why: obsolete v4l1 driver replaced by gspca_ov519 -Who: Hans de Goede - ----------------------------- - What: ovcamchip sensor framework When: 2.6.35 Files: drivers/media/video/ovcamchip/* -- cgit v1.1 From 3b23bc5731d476b0913c437626d6a6f51687d1d6 Mon Sep 17 00:00:00 2001 From: Amerigo Wang Date: Fri, 28 May 2010 06:45:38 -0300 Subject: V4L/DVB: Remove obsolete ovcamchip sensor framework Only used by obsoleted v4l1 driver Signed-off-by: Amerigo Wang Signed-off-by: Mauro Carvalho Chehab --- Documentation/feature-removal-schedule.txt | 8 -------- 1 file changed, 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index d4c9894..af1d071 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -459,14 +459,6 @@ Who: Corentin Chary ---------------------------- -What: ovcamchip sensor framework -When: 2.6.35 -Files: drivers/media/video/ovcamchip/* -Why: Only used by obsoleted v4l1 drivers -Who: Hans de Goede - ----------------------------- - What: stv680 v4l1 driver When: 2.6.35 Files: drivers/media/video/stv680.[ch] -- cgit v1.1 From a96076096bca746ddad3a5d8bfd3bbb1d9b96444 Mon Sep 17 00:00:00 2001 From: Amerigo Wang Date: Fri, 28 May 2010 06:49:57 -0300 Subject: V4L/DVB: Remove obsolete stv680 v4l1 driver obsolete v4l1 driver replaced by gspca_stv0680 Signed-off-by: Amerigo Wang Signed-off-by: Mauro Carvalho Chehab --- Documentation/feature-removal-schedule.txt | 8 -------- 1 file changed, 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index af1d071..61a54fd 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -459,14 +459,6 @@ Who: Corentin Chary ---------------------------- -What: stv680 v4l1 driver -When: 2.6.35 -Files: drivers/media/video/stv680.[ch] -Why: obsolete v4l1 driver replaced by gspca_stv0680 -Who: Hans de Goede - ----------------------------- - What: zc0301 v4l driver When: 2.6.35 Files: drivers/media/video/zc0301/* -- cgit v1.1 From 0d58cef664e01fb1848833455bfdbe1a3d91044c Mon Sep 17 00:00:00 2001 From: Amerigo Wang Date: Mon, 31 May 2010 03:16:17 -0300 Subject: V4L/DVB: Remove obsolete zc0301 v4l driver On 05/29/10 01:30, Jean-Francois Moine wrote: > On Fri, 28 May 2010 13:03:28 -0400 > Amerigo Wang wrote: > >> Subject: [PATCH 6/6] Remove obsolete zc0301 v4l driver >> >> Duplicate functionality with the gspca_zc3xx driver, zc0301 only >> supports 2 USB-ID's (because it only supports a limited set of >> sensors) wich are also supported by the gspca_zc3xx driver >> (which supports 53 USB-ID's in total). > > You forgot to remove the conditionnal compilation in the gspca_zc3xx > driver (USB_DEVICE(0x046d, 0x08ae) in gspca/zc3xx.c) > Right, thanks for pointing this out! Attached is the updated patch, please use this one instead. Thanks! Duplicate functionality with the gspca_zc3xx driver, zc0301 only supports 2 USB-ID's (because it only supports a limited set of sensors) wich are also supported by the gspca_zc3xx driver (which supports 53 USB-ID's in total). Signed-off-by: Amerigo Wang Signed-off-by: Mauro Carvalho Chehab --- Documentation/feature-removal-schedule.txt | 11 ----------- 1 file changed, 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 61a54fd..79cb554 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -459,17 +459,6 @@ Who: Corentin Chary ---------------------------- -What: zc0301 v4l driver -When: 2.6.35 -Files: drivers/media/video/zc0301/* -Why: Duplicate functionality with the gspca_zc3xx driver, zc0301 only - supports 2 USB-ID's (because it only supports a limited set of - sensors) wich are also supported by the gspca_zc3xx driver - (which supports 53 USB-ID's in total) -Who: Hans de Goede - ----------------------------- - What: sysfs-class-rfkill state file When: Feb 2014 Files: net/rfkill/core.c -- cgit v1.1 From 128fe95d77d6c5239ce6af6c3edacafc79eb0a39 Mon Sep 17 00:00:00 2001 From: Vadim Catana Date: Sat, 29 May 2010 12:49:16 -0300 Subject: V4L/DVB: TechnoTrend TT-budget T-3000 This patch adds support for TechnoTrend TT-budget T-3000 DVB-T card. Signed-off-by: Vadim Catana Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/CARDLIST.saa7134 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index 1387a69..4000c29 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -178,4 +178,5 @@ 177 -> Hawell HW-404M7 178 -> Beholder BeholdTV H7 [5ace:7190] 179 -> Beholder BeholdTV A7 [5ace:7090] -180 -> Avermedia M733A [1461:4155,1461:4255] +180 -> Avermedia PCI M733A [1461:4155,1461:4255] +181 -> TechoTrend TT-budget T-3000 [13c2:2804] -- cgit v1.1 From 7d7b5284d710f42f4c0c0d376d9a6af544c39afd Mon Sep 17 00:00:00 2001 From: Michael Krufky Date: Wed, 30 Jun 2010 18:17:35 -0300 Subject: V4L/DVB: cx23885: add support for new model revisions of the HVR12xx board family Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/CARDLIST.cx23885 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 index 16ca030..87c4634 100644 --- a/Documentation/video4linux/CARDLIST.cx23885 +++ b/Documentation/video4linux/CARDLIST.cx23885 @@ -17,9 +17,9 @@ 16 -> DVBWorld DVB-S2 2005 [0001:2005] 17 -> NetUP Dual DVB-S2 CI [1b55:2a2c] 18 -> Hauppauge WinTV-HVR1270 [0070:2211] - 19 -> Hauppauge WinTV-HVR1275 [0070:2215] - 20 -> Hauppauge WinTV-HVR1255 [0070:2251] - 21 -> Hauppauge WinTV-HVR1210 [0070:2291,0070:2295] + 19 -> Hauppauge WinTV-HVR1275 [0070:2215,0070:221d,0070:22f2] + 20 -> Hauppauge WinTV-HVR1255 [0070:2251,0070:2259,0070:22f1] + 21 -> Hauppauge WinTV-HVR1210 [0070:2291,0070:2295,0070:2299,0070:229d,0070:22f0,0070:22f3,0070:22f4,0070:22f5] 22 -> Mygica X8506 DMB-TH [14f1:8651] 23 -> Magic-Pro ProHDTV Extreme 2 [14f1:8657] 24 -> Hauppauge WinTV-HVR1850 [0070:8541] -- cgit v1.1 From 89d328d5782cb7efebe733fb994aac4bc64c255a Mon Sep 17 00:00:00 2001 From: Renzo Dani Date: Tue, 6 Jul 2010 07:23:33 -0300 Subject: V4L/DVB: Retrieve firmware for az6027 Signed-off-by: Renzo Dani Signed-off-by: Mauro Carvalho Chehab --- Documentation/dvb/get_dvb_firmware | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index 239cbdb..9ea94dc 100644 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware @@ -26,7 +26,7 @@ use IO::Handle; "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004", "or51211", "or51132_qam", "or51132_vsb", "bluebird", "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718", - "af9015", "ngene"); + "af9015", "ngene", "az6027"); # Check args syntax() if (scalar(@ARGV) != 1); @@ -567,6 +567,23 @@ sub ngene { "$file1, $file2"; } +sub az6027{ + my $file = "AZ6027_Linux_Driver.tar.gz"; + my $url = "http://linux.terratec.de/files/$file"; + my $firmware = "dvb-usb-az6027-03.fw"; + + wgetfile($file, $url); + + #untar + if( system("tar xzvf $file $firmware")){ + die "failed to untar firmware"; + } + if( system("rm $file")){ + die ("unable to remove unnecessary files"); + } + + $firmware; +} # --------------------------------------------------------------- # Utilities -- cgit v1.1 From 4e9f5677755c8f2eda6a293139084010cbbf2044 Mon Sep 17 00:00:00 2001 From: Antti Palosaari Date: Fri, 14 May 2010 15:24:28 -0300 Subject: V4L/DVB: get_dvb_firmware: update af9015 New driver contains new firmware 5.1.0.0. Fix script to get that. Signed-off-by: Antti Palosaari Signed-off-by: Mauro Carvalho Chehab --- Documentation/dvb/get_dvb_firmware | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index 9ea94dc..350959f 100644 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware @@ -518,11 +518,11 @@ sub bluebird { sub af9015 { my $sourcefile = "download.ashx?file=57"; my $url = "http://www.ite.com.tw/EN/Services/$sourcefile"; - my $hash = "ff5b096ed47c080870eacdab2de33ad6"; + my $hash = "e3f08935158038d385ad382442f4bb2d"; my $outfile = "dvb-usb-af9015.fw"; my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1); - my $fwoffset = 0x22708; - my $fwlength = 18225; + my $fwoffset = 0x25690; + my $fwlength = 18725; my ($chunklength, $buf, $rcount); checkstandard(); -- cgit v1.1 From 7e48b30af033076c85ab48a8306b5588faf5fb4b Mon Sep 17 00:00:00 2001 From: Jarod Wilson Date: Sun, 7 Mar 2010 17:55:43 -0300 Subject: V4L/DVB: dvb: add support for kworld 340u and ub435-q to em28xx-dvb This adds support for the KWorld PlusTV 340U and KWorld UB345-Q ATSC sticks, which are really the same device. The sticks have an eMPIA em2870 usb bridge chipset, an LG Electronics LGDT3304 ATSC/QAM demodulator and an NXP TDA18271HD tuner -- early versions of the 340U have a a TDA18271HD/C1, later models and the UB435-Q have a C2. The stick has been tested succesfully with both VSB_8 and QAM_256 signals. Its using lgdt3304 support added to the lgdt3305 driver by a prior patch, rather than the current lgdt3304 driver, as its severely lacking in functionality by comparison (see said patch for details). Signed-off-by: Jarod Wilson Signed-off-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/CARDLIST.em28xx | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index 3a623aa..5c56875 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx @@ -72,3 +72,4 @@ 73 -> Reddo DVB-C USB TV Box (em2870) 74 -> Actionmaster/LinXcel/Digitus VC211A (em2800) 75 -> Dikom DK300 (em2882) + 76 -> KWorld PlusTV 340U or UB435-Q (ATSC) (em2870) [1b80:a340] -- cgit v1.1 From 90abdc3b973229bae98dd96649d9f7106cc177a4 Mon Sep 17 00:00:00 2001 From: Dominik Brodowski Date: Sat, 24 Jul 2010 17:23:51 +0200 Subject: pcmcia: do not use io_req_t when calling pcmcia_request_io() Instead of io_req_t, drivers are now requested to fill out struct pcmcia_device *p_dev->resource[0,1] for up to two ioport ranges. After a call to pcmcia_request_io(), the ports found there are reserved, after calling pcmcia_request_configuration(), they may be used. CC: netdev@vger.kernel.org CC: linux-wireless@vger.kernel.org CC: linux-ide@vger.kernel.org CC: linux-usb@vger.kernel.org CC: laforge@gnumonks.org CC: linux-mtd@lists.infradead.org CC: alsa-devel@alsa-project.org CC: linux-serial@vger.kernel.org CC: Michael Buesch Acked-by: Marcel Holtmann (for drivers/bluetooth/) Signed-off-by: Dominik Brodowski --- Documentation/pcmcia/driver-changes.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/pcmcia/driver-changes.txt b/Documentation/pcmcia/driver-changes.txt index ff5f0be..26c0f9c 100644 --- a/Documentation/pcmcia/driver-changes.txt +++ b/Documentation/pcmcia/driver-changes.txt @@ -1,4 +1,11 @@ This file details changes in 2.6 which affect PCMCIA card driver authors: +* pcmcia_request_io changes (as of 2.6.36) + Instead of io_req_t, drivers are now requested to fill out + struct pcmcia_device *p_dev->resource[0,1] for up to two ioport + ranges. After a call to pcmcia_request_io(), the ports found there + are reserved, after calling pcmcia_request_configuration(), they may + be used. + * No dev_info_t, no cs_types.h (as of 2.6.36) dev_info_t and a few other typedefs are removed. No longer use them in PCMCIA device drivers. Also, do not include pcmcia/cs_types.h, as -- cgit v1.1 From 0748cb3e1fbd89c03a98c15e91ad65797981de77 Mon Sep 17 00:00:00 2001 From: Sam Ravnborg Date: Sat, 31 Jul 2010 23:35:31 +0200 Subject: kconfig: add alldefconfig alldefconfig create a configuration with all values set to their default value (form the Kconfig files). This may be useful when we try to use more sensible default values and may also be used in combination with the minimal defconfigs. Signed-off-by: Sam Ravnborg Signed-off-by: Michal Marek --- Documentation/kbuild/kconfig.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt index 49efae7..0e69dd5 100644 --- a/Documentation/kbuild/kconfig.txt +++ b/Documentation/kbuild/kconfig.txt @@ -65,7 +65,7 @@ also use the environment variable KCONFIG_ALLCONFIG as a flag or a filename that contains config symbols that the user requires to be set to a specific value. If KCONFIG_ALLCONFIG is used without a filename, "make *config" checks for a file named -"all{yes/mod/no/random}.config" (corresponding to the *config command +"all{yes/mod/no/def/random}.config" (corresponding to the *config command that was used) for symbol values that are to be forced. If this file is not found, it checks for a file named "all.config" to contain forced values. -- cgit v1.1 From a420e46412ad9d33c7174cd4311b91728122e2c4 Mon Sep 17 00:00:00 2001 From: Thomas Renninger Date: Fri, 16 Jul 2010 13:11:35 +0200 Subject: X86 platform drivers: Remove EC dump from thinkpad_acpi There is a general interface for that now (provided by other patches in this patch series): /sys/kernel/debug/ec/*/io Signed-off-by: Thomas Renninger CC: Alexey Starikovskiy CC: Len Brown CC: linux-kernel@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: platform-driver-x86@vger.kernel.org CC: Henrique de Moraes Holschuh CC: ibm-acpi-devel@lists.sourceforge.net Signed-off-by: Matthew Garrett --- Documentation/laptops/thinkpad-acpi.txt | 71 +++++---------------------------- 1 file changed, 11 insertions(+), 60 deletions(-) (limited to 'Documentation') diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index fc15538..f6f8025 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt @@ -960,70 +960,21 @@ Sysfs notes: subsystem, and follow all of the hwmon guidelines at Documentation/hwmon. +EXPERIMENTAL: Embedded controller register dump +----------------------------------------------- -EXPERIMENTAL: Embedded controller register dump -- /proc/acpi/ibm/ecdump ------------------------------------------------------------------------- - -This feature is marked EXPERIMENTAL because the implementation -directly accesses hardware registers and may not work as expected. USE -WITH CAUTION! To use this feature, you need to supply the -experimental=1 parameter when loading the module. - -This feature dumps the values of 256 embedded controller -registers. Values which have changed since the last time the registers -were dumped are marked with a star: - -[root@x40 ibm-acpi]# cat /proc/acpi/ibm/ecdump -EC +00 +01 +02 +03 +04 +05 +06 +07 +08 +09 +0a +0b +0c +0d +0e +0f -EC 0x00: a7 47 87 01 fe 96 00 08 01 00 cb 00 00 00 40 00 -EC 0x10: 00 00 ff ff f4 3c 87 09 01 ff 42 01 ff ff 0d 00 -EC 0x20: 00 00 00 00 00 00 00 00 00 00 00 03 43 00 00 80 -EC 0x30: 01 07 1a 00 30 04 00 00 *85 00 00 10 00 50 00 00 -EC 0x40: 00 00 00 00 00 00 14 01 00 04 00 00 00 00 00 00 -EC 0x50: 00 c0 02 0d 00 01 01 02 02 03 03 03 03 *bc *02 *bc -EC 0x60: *02 *bc *02 00 00 00 00 00 00 00 00 00 00 00 00 00 -EC 0x70: 00 00 00 00 00 12 30 40 *24 *26 *2c *27 *20 80 *1f 80 -EC 0x80: 00 00 00 06 *37 *0e 03 00 00 00 0e 07 00 00 00 00 -EC 0x90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -EC 0xa0: *ff 09 ff 09 ff ff *64 00 *00 *00 *a2 41 *ff *ff *e0 00 -EC 0xb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -EC 0xc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -EC 0xd0: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -EC 0xe0: 00 00 00 00 00 00 00 00 11 20 49 04 24 06 55 03 -EC 0xf0: 31 55 48 54 35 38 57 57 08 2f 45 73 07 65 6c 1a - -This feature can be used to determine the register holding the fan -speed on some models. To do that, do the following: +This feature is not included in the thinkpad driver anymore. +Instead the EC can be accessed through /sys/kernel/debug/ec with +a userspace tool which can be found here: +ftp://ftp.suse.com/pub/people/trenn/sources/ec +Use it to determine the register holding the fan +speed on some models. To do that, do the following: - make sure the battery is fully charged - make sure the fan is running - - run 'cat /proc/acpi/ibm/ecdump' several times, once per second or so - -The first step makes sure various charging-related values don't -vary. The second ensures that the fan-related values do vary, since -the fan speed fluctuates a bit. The third will (hopefully) mark the -fan register with a star: - -[root@x40 ibm-acpi]# cat /proc/acpi/ibm/ecdump -EC +00 +01 +02 +03 +04 +05 +06 +07 +08 +09 +0a +0b +0c +0d +0e +0f -EC 0x00: a7 47 87 01 fe 96 00 08 01 00 cb 00 00 00 40 00 -EC 0x10: 00 00 ff ff f4 3c 87 09 01 ff 42 01 ff ff 0d 00 -EC 0x20: 00 00 00 00 00 00 00 00 00 00 00 03 43 00 00 80 -EC 0x30: 01 07 1a 00 30 04 00 00 85 00 00 10 00 50 00 00 -EC 0x40: 00 00 00 00 00 00 14 01 00 04 00 00 00 00 00 00 -EC 0x50: 00 c0 02 0d 00 01 01 02 02 03 03 03 03 bc 02 bc -EC 0x60: 02 bc 02 00 00 00 00 00 00 00 00 00 00 00 00 00 -EC 0x70: 00 00 00 00 00 12 30 40 24 27 2c 27 21 80 1f 80 -EC 0x80: 00 00 00 06 *be 0d 03 00 00 00 0e 07 00 00 00 00 -EC 0x90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -EC 0xa0: ff 09 ff 09 ff ff 64 00 00 00 a2 41 ff ff e0 00 -EC 0xb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -EC 0xc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -EC 0xd0: 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -EC 0xe0: 00 00 00 00 00 00 00 00 11 20 49 04 24 06 55 03 -EC 0xf0: 31 55 48 54 35 38 57 57 08 2f 45 73 07 65 6c 1a - -Another set of values that varies often is the temperature + - use above mentioned tool to read out the EC + +Often fan and temperature values vary between readings. Since temperatures don't change vary fast, you can take several quick dumps to eliminate them. -- cgit v1.1 From cd89e08fa020f5a882f922e3c9e2628235ca6715 Mon Sep 17 00:00:00 2001 From: Thomas Renninger Date: Fri, 16 Jul 2010 13:11:37 +0200 Subject: Documentation: Add new /sys/kernel/debug/ec/* files to ABI Signed-off-by: Thomas Renninger CC: Alexey Starikovskiy CC: Len Brown CC: linux-kernel@vger.kernel.org CC: linux-acpi@vger.kernel.org CC: platform-driver-x86@vger.kernel.org Signed-off-by: Matthew Garrett --- Documentation/ABI/testing/debugfs-ec | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 Documentation/ABI/testing/debugfs-ec (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-ec b/Documentation/ABI/testing/debugfs-ec new file mode 100644 index 0000000..6546115 --- /dev/null +++ b/Documentation/ABI/testing/debugfs-ec @@ -0,0 +1,20 @@ +What: /sys/kernel/debug/ec/*/{gpe,use_global_lock,io} +Date: July 2010 +Contact: Thomas Renninger +Description: + +General information like which GPE is assigned to the EC and whether +the global lock should get used. +Knowing the EC GPE one can watch the amount of HW events related to +the EC here (XY -> GPE number from /sys/kernel/debug/ec/*/gpe): +/sys/firmware/acpi/interrupts/gpeXY + +The io file is binary and a userspace tool located here: +ftp://ftp.suse.com/pub/people/trenn/sources/ec/ +should get used to read out the 256 Embedded Controller registers +or writing to them. + +CAUTION: Do not write to the Embedded Controller if you don't know +what you are doing! Rebooting afterwards also is a good idea. +This can influence the way your machine is cooled and fans may +not get switched on again after you did a wrong write. -- cgit v1.1 From 226528c6100e4191842e61997110c8ace40605f7 Mon Sep 17 00:00:00 2001 From: Amerigo Wang Date: Thu, 4 Mar 2010 03:23:36 -0500 Subject: [CPUFREQ] unexport (un)lock_policy_rwsem* functions lock_policy_rwsem_* and unlock_policy_rwsem_* functions are scheduled to be unexported when 2.6.33. Now there are no other callers of them out of cpufreq.c, unexport them and make them static. Signed-off-by: WANG Cong Cc: Venkatesh Pallipadi Signed-off-by: Dave Jones --- Documentation/feature-removal-schedule.txt | 10 ---------- 1 file changed, 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 1571c0c..182bbe4 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -377,16 +377,6 @@ Who: Eric Paris ---------------------------- -What: lock_policy_rwsem_* and unlock_policy_rwsem_* will not be - exported interface anymore. -When: 2.6.33 -Why: cpu_policy_rwsem has a new cleaner definition making it local to - cpufreq core and contained inside cpufreq.c. Other dependent - drivers should not use it in order to safely avoid lockdep issues. -Who: Venkatesh Pallipadi - ----------------------------- - What: sound-slot/service-* module aliases and related clutters in sound/sound_core.c When: August 2010 -- cgit v1.1 From a3159864f2978bf2ace9cc787d73d315c98bbf9a Mon Sep 17 00:00:00 2001 From: Fenghua Yu Date: Thu, 29 Jul 2010 17:13:46 -0700 Subject: x86, hwmon: Package Level Thermal/Power: pkgtemp documentation Document for package level thermal hwmon driver. Signed-off-by: Fenghua Yu LKML-Reference: <1280448826-12004-6-git-send-email-fenghua.yu@intel.com> Reviewed-by: Len Brown Signed-off-by: H. Peter Anvin --- Documentation/hwmon/pkgtemp | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 Documentation/hwmon/pkgtemp (limited to 'Documentation') diff --git a/Documentation/hwmon/pkgtemp b/Documentation/hwmon/pkgtemp new file mode 100644 index 0000000..c8e1fb0 --- /dev/null +++ b/Documentation/hwmon/pkgtemp @@ -0,0 +1,36 @@ +Kernel driver pkgtemp +====================== + +Supported chips: + * Intel family + Prefix: 'pkgtemp' + CPUID: + Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual + Volume 3A: System Programming Guide + +Author: Fenghua Yu + +Description +----------- + +This driver permits reading package level temperature sensor embedded inside +Intel CPU package. The sensors can be in core, uncore, memory controller, or +other components in a package. The feature is first implemented in Intel Sandy +Bridge platform. + +Temperature is measured in degrees Celsius and measurement resolution is +1 degree C. Valid temperatures are from 0 to TjMax degrees C, because the actual +value of temperature register is in fact a delta from TjMax. + +Temperature known as TjMax is the maximum junction temperature of package. +We get this from MSR_IA32_TEMPERATURE_TARGET. If the MSR is not accessible, +we define TjMax as 100 degrees Celsius. At this temperature, protection +mechanism will perform actions to forcibly cool down the package. Alarm +may be raised, if the temperature grows enough (more than TjMax) to trigger +the Out-Of-Spec bit. Following table summarizes the exported sysfs files: + +temp1_input - Package temperature (in millidegrees Celsius). +temp1_max - All cooling devices should be turned on. +temp1_crit - Maximum junction temperature (in millidegrees Celsius). +temp1_crit_alarm - Set when Out-of-spec bit is set, never clears. + Correct CPU operation is no longer guaranteed. -- cgit v1.1 From 0fcb80818bc3ade5befd409051089f710adcf7b0 Mon Sep 17 00:00:00 2001 From: Patrick Pannuto Date: Mon, 2 Aug 2010 15:01:05 -0700 Subject: Documentation: Add timers/timers-howto.txt This file seeks to explain the nuances in various delays; many driver writers are not necessarily familiar with the various kernel timers, their shortfalls, and quirks. When faced with ndelay, udelay, mdelay, usleep_range, msleep, and msleep_interrubtible the question "How do I just wait 1 ms for my hardware to latch?" has the non-intuitive "best" answer: usleep_range(1000,1500) This patch is followed by a series of checkpatch additions that seek to help kernel hackers pick the best delay. Signed-off-by: Patrick Pannuto Cc: apw@canonical.com Cc: corbet@lwn.net Cc: arjan@linux.intel.com Cc: Randy Dunlap Cc: Andrew Morton LKML-Reference: <1280786467-26999-3-git-send-email-ppannuto@codeaurora.org> Signed-off-by: Thomas Gleixner --- Documentation/timers/timers-howto.txt | 105 ++++++++++++++++++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 Documentation/timers/timers-howto.txt (limited to 'Documentation') diff --git a/Documentation/timers/timers-howto.txt b/Documentation/timers/timers-howto.txt new file mode 100644 index 0000000..c9ef29d --- /dev/null +++ b/Documentation/timers/timers-howto.txt @@ -0,0 +1,105 @@ +delays - Information on the various kernel delay / sleep mechanisms +------------------------------------------------------------------- + +This document seeks to answer the common question: "What is the +RightWay (TM) to insert a delay?" + +This question is most often faced by driver writers who have to +deal with hardware delays and who may not be the most intimately +familiar with the inner workings of the Linux Kernel. + + +Inserting Delays +---------------- + +The first, and most important, question you need to ask is "Is my +code in an atomic context?" This should be followed closely by "Does +it really need to delay in atomic context?" If so... + +ATOMIC CONTEXT: + You must use the *delay family of functions. These + functions use the jiffie estimation of clock speed + and will busy wait for enough loop cycles to achieve + the desired delay: + + ndelay(unsigned long nsecs) + udelay(unsigned long usecs) + mdelay(unsgined long msecs) + + udelay is the generally preferred API; ndelay-level + precision may not actually exist on many non-PC devices. + + mdelay is macro wrapper around udelay, to account for + possible overflow when passing large arguments to udelay. + In general, use of mdelay is discouraged and code should + be refactored to allow for the use of msleep. + +NON-ATOMIC CONTEXT: + You should use the *sleep[_range] family of functions. + There are a few more options here, while any of them may + work correctly, using the "right" sleep function will + help the scheduler, power management, and just make your + driver better :) + + -- Backed by busy-wait loop: + udelay(unsigned long usecs) + -- Backed by hrtimers: + usleep_range(unsigned long min, unsigned long max) + -- Backed by jiffies / legacy_timers + msleep(unsigned long msecs) + msleep_interruptible(unsigned long msecs) + + Unlike the *delay family, the underlying mechanism + driving each of these calls varies, thus there are + quirks you should be aware of. + + + SLEEPING FOR "A FEW" USECS ( < ~10us? ): + * Use udelay + + - Why not usleep? + On slower systems, (embedded, OR perhaps a speed- + stepped PC!) the overhead of setting up the hrtimers + for usleep *may* not be worth it. Such an evaluation + will obviously depend on your specific situation, but + it is something to be aware of. + + SLEEPING FOR ~USECS OR SMALL MSECS ( 10us - 20ms): + * Use usleep_range + + - Why not msleep for (1ms - 20ms)? + Explained originally here: + http://lkml.org/lkml/2007/8/3/250 + msleep(1~20) may not do what the caller intends, and + will often sleep longer (~20 ms actual sleep for any + value given in the 1~20ms range). In many cases this + is not the desired behavior. + + - Why is there no "usleep" / What is a good range? + Since usleep_range is built on top of hrtimers, the + wakeup will be very precise (ish), thus a simple + usleep function would likely introduce a large number + of undesired interrupts. + + With the introduction of a range, the scheduler is + free to coalesce your wakeup with any other wakeup + that may have happened for other reasons, or at the + worst case, fire an interrupt for your upper bound. + + The larger a range you supply, the greater a chance + that you will not trigger an interrupt; this should + be balanced with what is an acceptable upper bound on + delay / performance for your specific code path. Exact + tolerances here are very situation specific, thus it + is left to the caller to determine a reasonable range. + + SLEEPING FOR LARGER MSECS ( 10ms+ ) + * Use msleep or possibly msleep_interruptible + + - What's the difference? + msleep sets the current task to TASK_UNINTERRUPTIBLE + whereas msleep_interruptible sets the current task to + TASK_INTERRUPTIBLE before scheduling the sleep. In + short, the difference is whether the sleep can be ended + early by a signal. In general, just use msleep unless + you know you have a need for the interruptible variant. -- cgit v1.1 From 0ea6e61122196509af82cc4f36cbdaacbefb8227 Mon Sep 17 00:00:00 2001 From: "Justin P. Mattock" Date: Fri, 23 Jul 2010 20:51:24 -0700 Subject: Documentation: update broken web addresses. Below you will find an updated version from the original series bunching all patches into one big patch updating broken web addresses that are located in Documentation/* Some of the addresses date as far far back as 1995 etc... so searching became a bit difficult, the best way to deal with these is to use web.archive.org to locate these addresses that are outdated. Now there are also some addresses pointing to .spec files some are located, but some(after searching on the companies site)where still no where to be found. In this case I just changed the address to the company site this way the users can contact the company and they can locate them for the users. Signed-off-by: Justin P. Mattock Signed-off-by: Thomas Weber Signed-off-by: Mike Frysinger Cc: Paulo Marques Cc: Randy Dunlap Cc: Michael Neuling Signed-off-by: Jiri Kosina --- Documentation/ABI/testing/sysfs-devices-memory | 6 +- Documentation/ABI/testing/sysfs-devices-system-cpu | 2 +- Documentation/DocBook/scsi.tmpl | 2 +- Documentation/DocBook/v4l/compat.xml | 5 +- Documentation/DocBook/v4l/fdl-appendix.xml | 2 +- Documentation/HOWTO | 6 +- Documentation/RCU/RTFP.txt | 2 +- Documentation/SubmittingDrivers | 2 +- Documentation/aoe/aoe.txt | 2 +- Documentation/arm/IXP2000 | 2 +- Documentation/arm/IXP4xx | 14 ++--- Documentation/arm/README | 4 +- Documentation/arm/SA1100/Assabet | 5 +- Documentation/arm/SA1100/Brutus | 2 +- Documentation/arm/SA1100/FreeBird | 2 +- Documentation/arm/SA1100/GraphicsClient | 2 +- Documentation/arm/SA1100/GraphicsMaster | 2 +- Documentation/arm/SA1100/Itsy | 2 +- Documentation/arm/SA1100/PLEB | 2 +- Documentation/arm/SA1100/Victor | 2 +- Documentation/arm/SA1100/nanoEngine | 2 +- Documentation/binfmt_misc.txt | 2 +- Documentation/blockdev/paride.txt | 2 +- Documentation/cdrom/packet-writing.txt | 2 +- Documentation/cgroups/cpusets.txt | 2 +- Documentation/development-process/4.Coding | 2 +- Documentation/device-mapper/dm-crypt.txt | 2 +- Documentation/devices.txt | 9 +-- Documentation/dvb/faq.txt | 2 +- Documentation/fb/framebuffer.txt | 2 +- Documentation/filesystems/9p.txt | 2 +- Documentation/filesystems/affs.txt | 2 +- Documentation/filesystems/befs.txt | 4 +- Documentation/filesystems/isofs.txt | 2 +- Documentation/filesystems/proc.txt | 4 +- Documentation/filesystems/vfat.txt | 3 +- Documentation/hwmon/adm1026 | 2 +- Documentation/hwmon/g760a | 2 +- Documentation/hwmon/gl518sm | 3 +- Documentation/hwmon/k8temp | 2 +- Documentation/hwmon/lm85 | 6 +- Documentation/hwmon/smsc47m1 | 11 ++-- Documentation/hwmon/thmc50 | 2 +- Documentation/hwmon/via686a | 2 +- Documentation/hwmon/w83627hf | 6 +- Documentation/hwmon/w83781d | 2 +- Documentation/hwmon/w83792d | 2 +- Documentation/i2c/busses/i2c-ali1535 | 2 +- Documentation/i2c/busses/i2c-ali1563 | 2 +- Documentation/i2c/busses/i2c-ali15x3 | 2 +- Documentation/i2c/busses/i2c-piix4 | 2 +- Documentation/i2c/busses/i2c-sis630 | 2 +- Documentation/ia64/aliasing.txt | 2 - Documentation/ia64/serial.txt | 2 +- Documentation/infiniband/user_verbs.txt | 2 +- Documentation/input/appletouch.txt | 2 +- Documentation/input/bcm5974.txt | 2 +- Documentation/input/iforce-protocol.txt | 2 +- Documentation/input/sentelic.txt | 2 +- Documentation/input/xpad.txt | 2 +- Documentation/intel_txt.txt | 12 ++-- Documentation/ioctl/ioctl-number.txt | 10 +-- Documentation/isdn/README | 2 +- Documentation/isdn/README.HiSax | 2 +- Documentation/ja_JP/HOWTO | 2 +- Documentation/ja_JP/SubmittingPatches | 6 +- Documentation/kernel-docs.txt | 39 ++++++------ Documentation/ko_KR/HOWTO | 8 +-- Documentation/laptops/acer-wmi.txt | 2 +- Documentation/ldm.txt | 2 +- Documentation/md.txt | 2 +- Documentation/misc-devices/c2port.txt | 4 +- Documentation/mtd/nand_ecc.txt | 2 +- Documentation/networking/3c509.txt | 2 +- Documentation/networking/README.ipw2100 | 3 +- Documentation/networking/README.ipw2200 | 2 +- Documentation/networking/README.sb1000 | 4 +- Documentation/networking/arcnet.txt | 4 +- Documentation/networking/bonding.txt | 2 +- Documentation/networking/decnet.txt | 2 +- Documentation/networking/fore200e.txt | 2 +- Documentation/networking/ipddp.txt | 5 -- Documentation/networking/iphase.txt | 2 +- Documentation/networking/packet_mmap.txt | 4 +- Documentation/networking/ray_cs.txt | 4 +- Documentation/networking/s2io.txt | 3 +- Documentation/networking/tlan.txt | 4 +- Documentation/networking/udplite.txt | 13 ++-- Documentation/networking/wavelan.txt | 3 +- Documentation/power/apm-acpi.txt | 2 +- Documentation/power/basic-pm-debugging.txt | 3 +- Documentation/power/video.txt | 12 ++-- Documentation/powerpc/booting-without-of.txt | 2 +- Documentation/s390/Debugging390.txt | 2 +- Documentation/scsi/BusLogic.txt | 2 +- Documentation/scsi/ChangeLog.megaraid | 2 +- Documentation/scsi/FlashPoint.txt | 4 +- Documentation/scsi/Mylex.txt | 2 +- Documentation/scsi/NinjaSCSI.txt | 2 - Documentation/scsi/aic79xx.txt | 2 +- Documentation/scsi/aic7xxx.txt | 2 +- Documentation/scsi/ibmmca.txt | 2 +- Documentation/scsi/osst.txt | 2 +- Documentation/scsi/ppa.txt | 6 +- Documentation/scsi/scsi-generic.txt | 8 +-- Documentation/scsi/scsi.txt | 4 +- Documentation/scsi/scsi_mid_low_api.txt | 2 +- Documentation/serial/moxa-smartio | 2 +- Documentation/sound/alsa/ALSA-Configuration.txt | 2 +- Documentation/sound/alsa/HD-Audio.txt | 2 +- Documentation/sound/alsa/soc/DAI.txt | 2 +- Documentation/sound/alsa/soc/codec.txt | 2 +- Documentation/sound/alsa/soc/platform.txt | 2 +- Documentation/sound/oss/README.OSS | 5 +- Documentation/telephony/ixj.txt | 9 +-- Documentation/uml/UserModeLinux-HOWTO.txt | 73 +++------------------- Documentation/usb/linux.inf | 2 +- Documentation/usb/mtouchusb.txt | 6 +- Documentation/usb/usb-serial.txt | 4 +- Documentation/video4linux/API.html | 2 +- Documentation/video4linux/CQcam.txt | 4 +- Documentation/video4linux/README.cpia | 2 +- Documentation/video4linux/README.ivtv | 2 +- Documentation/video4linux/Zoran | 6 +- Documentation/video4linux/bttv/Cards | 6 +- Documentation/video4linux/bttv/MAKEDEV | 2 +- Documentation/video4linux/bttv/Specs | 4 +- .../video4linux/cx88/hauppauge-wintv-cx88-ir.txt | 2 +- .../video4linux/hauppauge-wintv-cx88-ir.txt | 2 +- Documentation/video4linux/ibmcam.txt | 5 +- Documentation/video4linux/se401.txt | 2 +- Documentation/video4linux/w9966.txt | 2 +- Documentation/w1/masters/ds2482 | 4 +- Documentation/w1/masters/mxc-w1 | 3 +- Documentation/w1/masters/omap-hdq | 2 +- Documentation/zh_CN/HOWTO | 8 +-- Documentation/zh_CN/SubmittingDrivers | 2 +- Documentation/zh_CN/SubmittingPatches | 6 +- 138 files changed, 238 insertions(+), 330 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-memory b/Documentation/ABI/testing/sysfs-devices-memory index aba7d98..7405de2 100644 --- a/Documentation/ABI/testing/sysfs-devices-memory +++ b/Documentation/ABI/testing/sysfs-devices-memory @@ -7,7 +7,7 @@ Description: added or removed dynamically to represent hot-add/remove operations. Users: hotplug memory add/remove tools - https://w3.opensource.ibm.com/projects/powerpc-utils/ + http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils What: /sys/devices/system/memory/memoryX/removable Date: June 2008 @@ -19,7 +19,7 @@ Description: identify removable sections of the memory before attempting potentially expensive hot-remove memory operation Users: hotplug memory remove tools - https://w3.opensource.ibm.com/projects/powerpc-utils/ + http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils What: /sys/devices/system/memory/memoryX/phys_device Date: September 2008 @@ -58,7 +58,7 @@ Description: by root to offline that section. # echo offline > /sys/devices/system/memory/memory22/state Users: hotplug memory remove tools - https://w3.opensource.ibm.com/projects/powerpc-utils/ + http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils What: /sys/devices/system/memoryX/nodeY diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 84a710f..7564e88 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -197,7 +197,7 @@ Description: These files exist in every cpu's cache index directories. Currently, only AMD Family 10h Processors support cache index disable, and only for their L3 caches. See the BIOS and Kernel Developer's Guide at - http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/31116-Public-GH-BKDG_3.20_2-4-09.pdf + http://support.amd.com/us/Embedded_TechDocs/31116-Public-GH-BKDG_3-28_5-28-09.pdf for formatting information and other details on the cache index disable. Users: joachim.deguara@amd.com diff --git a/Documentation/DocBook/scsi.tmpl b/Documentation/DocBook/scsi.tmpl index d87f456..324b534 100644 --- a/Documentation/DocBook/scsi.tmpl +++ b/Documentation/DocBook/scsi.tmpl @@ -393,7 +393,7 @@ For documentation see - http://www.torque.net/sg/sdebug26.html + http://sg.danny.cz/sg/sdebug26.html diff --git a/Documentation/DocBook/v4l/compat.xml b/Documentation/DocBook/v4l/compat.xml index b42b935..54447f0 100644 --- a/Documentation/DocBook/v4l/compat.xml +++ b/Documentation/DocBook/v4l/compat.xml @@ -1091,8 +1091,9 @@ signed 64-bit integer. Output devices should not send a buffer out until the time in the timestamp field has arrived. I would like to follow SGI's lead, and adopt a multimedia timestamping system like their UST (Unadjusted System Time). See -http://reality.sgi.com/cpirazzi_engr/lg/time/intro.html. [This link is -no longer valid.] UST uses timestamps that are 64-bit signed integers +http://web.archive.org/web/*/http://reality.sgi.com +/cpirazzi_engr/lg/time/intro.html. +UST uses timestamps that are 64-bit signed integers (not struct timeval's) and given in nanosecond units. The UST clock starts at zero when the system is booted and runs continuously and uniformly. It takes a little over 292 years for UST to overflow. There diff --git a/Documentation/DocBook/v4l/fdl-appendix.xml b/Documentation/DocBook/v4l/fdl-appendix.xml index b6ce50d..ae22394 100644 --- a/Documentation/DocBook/v4l/fdl-appendix.xml +++ b/Documentation/DocBook/v4l/fdl-appendix.xml @@ -2,7 +2,7 @@ The GNU Free Documentation License 1.1 in DocBook Markup by Eric Baudais Maintained by the GNOME Documentation Project - http://developer.gnome.org/projects/gdp + http://live.gnome.org/DocumentationProject Version: 1.0.1 Last Modified: Nov 16, 2000 --> diff --git a/Documentation/HOWTO b/Documentation/HOWTO index 40ada93..365bda9 100644 --- a/Documentation/HOWTO +++ b/Documentation/HOWTO @@ -187,7 +187,7 @@ apply a patch. If you do not know where you want to start, but you want to look for some task to start doing to join into the kernel development community, go to the Linux Kernel Janitor's project: - http://janitor.kernelnewbies.org/ + http://kernelnewbies.org/KernelJanitors It is a great place to start. It describes a list of relatively simple problems that need to be cleaned up and fixed within the Linux kernel source tree. Working with the developers in charge of this project, you @@ -315,7 +315,7 @@ process is tracked with the tool patchwork. Patchwork offers a web interface which shows patch postings, any comments on a patch or revisions to it, and maintainers can mark patches as under review, accepted, or rejected. Most of these patchwork sites are listed at -http://patchwork.kernel.org/ or http://patchwork.ozlabs.org/. +http://patchwork.kernel.org/. 2.6.x -next kernel tree for integration tests --------------------------------------------- @@ -595,7 +595,7 @@ start exactly where you are now. ---------- Thanks to Paolo Ciarrocchi who allowed the "Development Process" -(http://linux.tar.bz/articles/2.6-development_process) section +(http://lwn.net/Articles/94386/) section to be based on text he had written, and to Randy Dunlap and Gerrit Huizenga for some of the list of things you should and should not say. Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt index 5aea459..c43460d 100644 --- a/Documentation/RCU/RTFP.txt +++ b/Documentation/RCU/RTFP.txt @@ -606,7 +606,7 @@ Suparna Bhattacharya" ,Year="2006" ,pages="v2 123-138" ,note="Available: -\url{http://www.linuxsymposium.org/2006/view_abstract.php?content_key=184} +\url{http://www.linuxsymposium.org/2006/index_2006.php} \url{http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf} [Viewed January 1, 2007]" ,annotation=" diff --git a/Documentation/SubmittingDrivers b/Documentation/SubmittingDrivers index 4947fd8..38d2aab 100644 --- a/Documentation/SubmittingDrivers +++ b/Documentation/SubmittingDrivers @@ -161,7 +161,7 @@ How to NOT write kernel driver by Arjan van de Ven: http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf Kernel Janitor: - http://janitor.kernelnewbies.org/ + http://kernelnewbies.org/KernelJanitors GIT, Fast Version Control System: http://git-scm.com/ diff --git a/Documentation/aoe/aoe.txt b/Documentation/aoe/aoe.txt index 3a4dbe4..b5aada9 100644 --- a/Documentation/aoe/aoe.txt +++ b/Documentation/aoe/aoe.txt @@ -1,6 +1,6 @@ The EtherDrive (R) HOWTO for users of 2.6 kernels is found at ... - http://www.coraid.com/support/linux/EtherDrive-2.6-HOWTO.html + http://www.coraid.com/SUPPORT/EtherDrive-HBA It has many tips and hints! diff --git a/Documentation/arm/IXP2000 b/Documentation/arm/IXP2000 index e0148b6..68d21d9 100644 --- a/Documentation/arm/IXP2000 +++ b/Documentation/arm/IXP2000 @@ -14,7 +14,7 @@ telecom systems. In addition to an XScale core, it contains up to 8 interfaces (UTOPIA, SPI, etc), a PCI host bridge, one serial port, flash interface, and some other odds and ends. For more information, see: -http://developer.intel.com/design/network/products/npfamily/ixp2xxx.htm +http://developer.intel.com 2. Linux Support diff --git a/Documentation/arm/IXP4xx b/Documentation/arm/IXP4xx index 72fbcc4..133c5fa 100644 --- a/Documentation/arm/IXP4xx +++ b/Documentation/arm/IXP4xx @@ -45,7 +45,7 @@ require the use of Intel's propietary CSR softare: If you need to use any of the above, you need to download Intel's software from: - http://developer.intel.com/design/network/products/npfamily/ixp425swr1.htm + http://developer.intel.com/design/network/products/npfamily/ixp425.htm DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPIETARY SOFTWARE. @@ -53,7 +53,7 @@ SOFTWARE. There are several websites that provide directions/pointers on using Intel's software: -http://ixp4xx-osdg.sourceforge.net/ + http://sourceforge.net/projects/ixp4xx-osdg/ Open Source Developer's Guide for using uClinux and the Intel libraries http://gatewaymaker.sourceforge.net/ @@ -112,21 +112,21 @@ http://www.adiengineering.com/productsCoyote.html Finally, there is an IDE port hanging off the expansion bus. Gateworks Avila Network Platform -http://www.gateworks.com/avila_sbc.htm +http://www.gateworks.com/support/overview.php The Avila platform is basically and IXDP425 with the 4 PCI slots replaced with mini-PCI slots and a CF IDE interface hanging off the expansion bus. Intel IXDP425 Development Platform -http://developer.intel.com/design/network/products/npfamily/ixdp425.htm +http://www.intel.com/design/network/products/npfamily/ixdpg425.htm This is Intel's standard reference platform for the IXDP425 and is also known as the Richfield board. It contains 4 PCI slots, 16MB of flash, two 10/100 ports and one ADSL port. Intel IXDP465 Development Platform -http://developer.intel.com/design/network/products/npfamily/ixdp465.htm +http://www.intel.com/design/network/products/npfamily/ixdp465.htm This is basically an IXDP425 with an IXP465 and 32M of flash instead of just 16. @@ -141,15 +141,13 @@ Intel IXDPG425 Development Platform a pivot_root to NFS. Motorola PrPMC1100 Processor Mezanine Card -http://www.fountainsys.com/datasheet/PrPMC1100.pdf +http://www.fountainsys.com The PrPMC1100 is based on the IXCP1100 and is meant to plug into and IXP2400/2800 system to act as the system controller. It simply contains a CPU and 16MB of flash on the board and needs to be plugged into a carrier board to function. Currently Linux only supports the Motorola PrPMC carrier board for this platform. - See https://mcg.motorola.com/us/ds/pdf/ds0144.pdf for info - on the carrier board. 5. TODO LIST diff --git a/Documentation/arm/README b/Documentation/arm/README index d98783f..aea3409 100644 --- a/Documentation/arm/README +++ b/Documentation/arm/README @@ -41,12 +41,12 @@ Bug reports etc --------------- Please send patches to the patch system. For more information, see - http://www.arm.linux.org.uk/patches/info.html Always include some + http://www.arm.linux.org.uk/developer/patches/info.php Always include some explanation as to what the patch does and why it is needed. Bug reports should be sent to linux-arm-kernel@lists.arm.linux.org.uk, or submitted through the web form at - http://www.arm.linux.org.uk/forms/solution.shtml + http://www.arm.linux.org.uk/developer/ When sending bug reports, please ensure that they contain all relevant information, eg. the kernel messages that were printed before/during diff --git a/Documentation/arm/SA1100/Assabet b/Documentation/arm/SA1100/Assabet index 91f7ce7..08b885d 100644 --- a/Documentation/arm/SA1100/Assabet +++ b/Documentation/arm/SA1100/Assabet @@ -2,8 +2,7 @@ The Intel Assabet (SA-1110 evaluation) board ============================================ Please see: -http://developer.intel.com/design/strong/quicklist/eval-plat/sa-1110.htm -http://developer.intel.com/design/strong/guides/278278.htm +http://developer.intel.com Also some notes from John G Dorsey : http://www.cs.cmu.edu/~wearable/software/assabet.html @@ -64,7 +63,7 @@ Initial RedBoot configuration ----------------------------- The commands used here are explained in The RedBoot User's Guide available -on-line at http://sources.redhat.com/ecos/docs-latest/redboot/redboot.html. +on-line at http://sources.redhat.com/ecos/docs.html. Please refer to it for explanations. If you have a CF network card (my Assabet kit contained a CF+ LP-E from diff --git a/Documentation/arm/SA1100/Brutus b/Documentation/arm/SA1100/Brutus index b1cfd40..6a3aa95 100644 --- a/Documentation/arm/SA1100/Brutus +++ b/Documentation/arm/SA1100/Brutus @@ -1,7 +1,7 @@ Brutus is an evaluation platform for the SA1100 manufactured by Intel. For more details, see: -http://developer.intel.com/design/strong/applnots/sa1100lx/getstart.htm +http://developer.intel.com To compile for Brutus, you must issue the following commands: diff --git a/Documentation/arm/SA1100/FreeBird b/Documentation/arm/SA1100/FreeBird index eda28b3..fb23b77 100644 --- a/Documentation/arm/SA1100/FreeBird +++ b/Documentation/arm/SA1100/FreeBird @@ -1,5 +1,5 @@ Freebird-1.1 is produced by Legned(C) ,Inc. -(http://www.legend.com.cn) +http://web.archive.org/web/*/http://www.legend.com.cn and software/linux mainatined by Coventive(C),Inc. (http://www.coventive.com) diff --git a/Documentation/arm/SA1100/GraphicsClient b/Documentation/arm/SA1100/GraphicsClient index 6c9c4f5..867bb35 100644 --- a/Documentation/arm/SA1100/GraphicsClient +++ b/Documentation/arm/SA1100/GraphicsClient @@ -71,7 +71,7 @@ Supported peripherals: - serial ports (ttyS[0-2]) - ttyS0 is default for serial console - Smart I/O (ADC, keypad, digital inputs, etc) - See http://www.applieddata.com/developers/linux for IOCTL documentation + See http://www.eurotech-inc.com/linux-sbc.asp for IOCTL documentation and example user space code. ps/2 keybd is multiplexed through this driver To do: diff --git a/Documentation/arm/SA1100/GraphicsMaster b/Documentation/arm/SA1100/GraphicsMaster index ee7c659..9145088 100644 --- a/Documentation/arm/SA1100/GraphicsMaster +++ b/Documentation/arm/SA1100/GraphicsMaster @@ -28,7 +28,7 @@ Supported peripherals: - serial ports (ttyS[0-2]) - ttyS0 is default for serial console - Smart I/O (ADC, keypad, digital inputs, etc) - See http://www.applieddata.com/developers/linux for IOCTL documentation + See http://www.eurotech-inc.com/linux-sbc.asp for IOCTL documentation and example user space code. ps/2 keybd is multiplexed through this driver To do: diff --git a/Documentation/arm/SA1100/Itsy b/Documentation/arm/SA1100/Itsy index 3b59453..44b9499 100644 --- a/Documentation/arm/SA1100/Itsy +++ b/Documentation/arm/SA1100/Itsy @@ -4,7 +4,7 @@ research projects at Compaq that are related to pocket computing. For more information, see: - http://www.research.digital.com/wrl/itsy/index.html + http://www.hpl.hp.com/downloads/crl/itsy/ Notes on initial 2.4 Itsy support (8/27/2000) : The port was done on an Itsy version 1.5 machine with a daughtercard with diff --git a/Documentation/arm/SA1100/PLEB b/Documentation/arm/SA1100/PLEB index 92cae066..b9c8a63 100644 --- a/Documentation/arm/SA1100/PLEB +++ b/Documentation/arm/SA1100/PLEB @@ -6,6 +6,6 @@ PLEB support has yet to be fully integrated. For more information, see: - http://www.cse.unsw.edu.au/~pleb/ + http://www.cse.unsw.edu.au diff --git a/Documentation/arm/SA1100/Victor b/Documentation/arm/SA1100/Victor index f938a29..9cff415 100644 --- a/Documentation/arm/SA1100/Victor +++ b/Documentation/arm/SA1100/Victor @@ -3,7 +3,7 @@ VisuAide, Inc. to be used by blind people. For more information related to Victor, see: - http://www.visuaide.com/victor + http://www.humanware.com/en-usa/products Of course Victor is using Linux as its main operating system. The Victor implementation for Linux is maintained by Nicolas Pitre: diff --git a/Documentation/arm/SA1100/nanoEngine b/Documentation/arm/SA1100/nanoEngine index fc431cb..48a7934f 100644 --- a/Documentation/arm/SA1100/nanoEngine +++ b/Documentation/arm/SA1100/nanoEngine @@ -7,5 +7,5 @@ for more info. (Ref: Stuart Adams ) Also visit Larry Doolittle's "Linux for the nanoEngine" site: -http://recycle.lbl.gov/~ldoolitt/bse/ +http://www.brightstareng.com/arm/nanoeng.htm diff --git a/Documentation/binfmt_misc.txt b/Documentation/binfmt_misc.txt index f609ebf..c1ed694 100644 --- a/Documentation/binfmt_misc.txt +++ b/Documentation/binfmt_misc.txt @@ -111,6 +111,6 @@ cause unexpected behaviour and can be a security hazard. There is a web page about binfmt_misc at -http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html +http://www.tat.physik.uni-tuebingen.de Richard Günther diff --git a/Documentation/blockdev/paride.txt b/Documentation/blockdev/paride.txt index e431267..ee6717e 100644 --- a/Documentation/blockdev/paride.txt +++ b/Documentation/blockdev/paride.txt @@ -412,6 +412,6 @@ have in your mail headers, when sending mail to the list server. You might also find some useful information on the linux-parport web pages (although they are not always up to date) at - http://www.torque.net/parport/ + http://web.archive.org/web/*/http://www.torque.net/parport/ diff --git a/Documentation/cdrom/packet-writing.txt b/Documentation/cdrom/packet-writing.txt index 1c40777..13c251d 100644 --- a/Documentation/cdrom/packet-writing.txt +++ b/Documentation/cdrom/packet-writing.txt @@ -95,7 +95,7 @@ Using the pktcdvd sysfs interface Since Linux 2.6.20, the pktcdvd module has a sysfs interface and can be controlled by it. For example the "pktcdvd" tool uses -this interface. (see http://people.freenet.de/BalaGi#pktcdvd ) +this interface. (see http://tom.ist-im-web.de/download/pktcdvd ) "pktcdvd" works similar to "pktsetup", e.g.: diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt index 51682ab..5d0d569 100644 --- a/Documentation/cgroups/cpusets.txt +++ b/Documentation/cgroups/cpusets.txt @@ -691,7 +691,7 @@ There are ways to query or modify cpusets: cat, rmdir commands from the shell, or their equivalent from C. - via the C library libcpuset. - via the C library libcgroup. - (http://sourceforge.net/proects/libcg/) + (http://sourceforge.net/projects/libcg/) - via the python application cset. (http://developer.novell.com/wiki/index.php/Cpuset) diff --git a/Documentation/development-process/4.Coding b/Documentation/development-process/4.Coding index a5a3450..2278693 100644 --- a/Documentation/development-process/4.Coding +++ b/Documentation/development-process/4.Coding @@ -281,7 +281,7 @@ With sparse, the programmer can be warned about confusion between user-space and kernel-space addresses, mixture of big-endian and small-endian quantities, the passing of integer values where a set of bit flags is expected, and so on. Sparse must be installed separately (it can -be found at http://www.kernel.org/pub/software/devel/sparse/ if your +be found at https://sparse.wiki.kernel.org/index.php/Main_Page if your distributor does not package it); it can then be run on the code by adding "C=1" to your make command. diff --git a/Documentation/device-mapper/dm-crypt.txt b/Documentation/device-mapper/dm-crypt.txt index 6680cab..524de92 100644 --- a/Documentation/device-mapper/dm-crypt.txt +++ b/Documentation/device-mapper/dm-crypt.txt @@ -36,7 +36,7 @@ Example scripts =============== LUKS (Linux Unified Key Setup) is now the preferred way to set up disk encryption with dm-crypt using the 'cryptsetup' utility, see -http://luks.endorphin.org/ +http://clemens.endorphin.org/cryptography [[ #!/bin/sh diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 1d83d12..f2da781 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -1517,7 +1517,7 @@ Your cooperation is appreciated. ... The driver and documentation may be obtained from - http://www.proximity.com.au/~brian/winradio/ + http://www.winradio.com/ 82 block I2O hard disk 0 = /dev/i2o/hdag 33rd I2O hard disk, whole disk @@ -1723,7 +1723,7 @@ Your cooperation is appreciated. 1 = /dev/comedi1 Second comedi device ... - See http://stm.lbl.gov/comedi or http://www.llp.fu-berlin.de/. + See http://stm.lbl.gov/comedi. 98 block User-mode virtual block device 0 = /dev/ubda First user-mode block device @@ -1984,7 +1984,7 @@ Your cooperation is appreciated. 256 NetWare volumes can be supported in a single machine. - http://www.kernel.org/pub/linux/kernel/people/jmerkey/nwfs + http://cgfa.telepac.pt/ftp2/kernel.org/linux/kernel/people/jmerkey/nwfs/ 0 = /dev/nwfs/v0 First NetWare (NWFS) Logical Volume 1 = /dev/nwfs/v1 Second NetWare (NWFS) Logical Volume @@ -2591,7 +2591,8 @@ Your cooperation is appreciated. 1 = /dev/intermezzo1 Second cache manager ... - See http://www.inter-mezzo.org/ for more information. + See http://web.archive.org/web/20080115195241/ + http://inter-mezzo.org/index.html 186 char Object-based storage control device 0 = /dev/obd0 First obd control device diff --git a/Documentation/dvb/faq.txt b/Documentation/dvb/faq.txt index 2511a33..121832e 100644 --- a/Documentation/dvb/faq.txt +++ b/Documentation/dvb/faq.txt @@ -76,7 +76,7 @@ Some very frequently asked questions about linuxtv-dvb the TuxBox CVS many interesting DVB applications and the dBox2 DVB source - http://sourceforge.net/projects/dvbsak/ + http://www.linuxtv.org/downloads/ DVB Swiss Army Knife library and utilities http://www.nenie.org/misc/mpsys/ diff --git a/Documentation/fb/framebuffer.txt b/Documentation/fb/framebuffer.txt index fe79e3c..58c5ae2 100644 --- a/Documentation/fb/framebuffer.txt +++ b/Documentation/fb/framebuffer.txt @@ -330,7 +330,7 @@ and on its mirrors. The latest version of fbset can be found at - http://home.tvd.be/cr26864/Linux/fbdev/ + http://www.linux-fbdev.org/ 10. Credits diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt index c0236e7..f9765e8 100644 --- a/Documentation/filesystems/9p.txt +++ b/Documentation/filesystems/9p.txt @@ -128,7 +128,7 @@ OPTIONS RESOURCES ========= -Our current recommendation is to use Inferno (http://www.vitanuova.com/inferno) +Our current recommendation is to use Inferno (http://www.vitanuova.com/nferno/index.html) as the 9p server. You can start a 9p server under Inferno by issuing the following command: ; styxlisten -A tcp!*!564 export '#U*' diff --git a/Documentation/filesystems/affs.txt b/Documentation/filesystems/affs.txt index 2d152446..81ac488 100644 --- a/Documentation/filesystems/affs.txt +++ b/Documentation/filesystems/affs.txt @@ -216,4 +216,4 @@ due to an incompatibility with the Amiga floppy controller. If you are interested in an Amiga Emulator for Linux, look at -http://www.freiburg.linux.de/~uae/ +http://web.archive.org/web/*/http://www.freiburg.linux.de/~uae/ diff --git a/Documentation/filesystems/befs.txt b/Documentation/filesystems/befs.txt index 67391a1..6e49c36 100644 --- a/Documentation/filesystems/befs.txt +++ b/Documentation/filesystems/befs.txt @@ -31,7 +31,7 @@ Current maintainer: Sergey S. Kostyliov WHAT IS THIS DRIVER? ================== -This module implements the native filesystem of BeOS +This module implements the native filesystem of BeOS http://www.beincorporated.com/ for the linux 2.4.1 and later kernels. Currently it is a read-only implementation. @@ -61,7 +61,7 @@ step 2. Configuration & make kernel The linux kernel has many compile-time options. Most of them are beyond the scope of this document. I suggest the Kernel-HOWTO document as a good general -reference on this topic. +reference on this topic. http://www.linuxdocs.org/HOWTOs/Kernel-HOWTO-4.html However, to use the BeFS module, you must enable it at configure time. diff --git a/Documentation/filesystems/isofs.txt b/Documentation/filesystems/isofs.txt index 3c367c3..ba0a933 100644 --- a/Documentation/filesystems/isofs.txt +++ b/Documentation/filesystems/isofs.txt @@ -41,7 +41,7 @@ Mount options unique to the isofs filesystem. sbsector=xxx Session begins from sector xxx Recommended documents about ISO 9660 standard are located at: -http://www.y-adagio.com/public/standards/iso_cdromr/tocont.htm +http://www.y-adagio.com/ ftp://ftp.ecma.ch/ecma-st/Ecma-119.pdf Quoting from the PDF "This 2nd Edition of Standard ECMA-119 is technically identical with ISO 9660.", so it is a valid and gratis substitute of the diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 9fb6cbe..8fe8895 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -73,9 +73,9 @@ contact Bodo Bauer at bb@ricochet.net. We'll be happy to add them to this document. The latest version of this document is available online at -http://skaro.nightcrawler.com/~bb/Docs/Proc as HTML version. +http://tldp.org/LDP/Linux-Filesystem-Hierarchy/html/proc.html -If the above direction does not works for you, ypu could try the kernel +If the above direction does not works for you, you could try the kernel mailing list at linux-kernel@vger.kernel.org and/or try to reach me at comandante@zaralinux.com. diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt index eed520f..ead764b 100644 --- a/Documentation/filesystems/vfat.txt +++ b/Documentation/filesystems/vfat.txt @@ -165,7 +165,8 @@ TEST SUITE If you plan to make any modifications to the vfat filesystem, please get the test suite that comes with the vfat distribution at - http://bmrc.berkeley.edu/people/chaffee/vfat.html + http://web.archive.org/web/*/http://bmrc.berkeley.edu/ + people/chaffee/vfat.html This tests quite a few parts of the vfat filesystem and additional tests for new features or untested features would be appreciated. diff --git a/Documentation/hwmon/adm1026 b/Documentation/hwmon/adm1026 index f4327db..d8fabe0 100644 --- a/Documentation/hwmon/adm1026 +++ b/Documentation/hwmon/adm1026 @@ -6,7 +6,7 @@ Supported chips: Prefix: 'adm1026' Addresses scanned: I2C 0x2c, 0x2d, 0x2e Datasheet: Publicly available at the Analog Devices website - http://www.analog.com/en/prod/0,,766_825_ADM1026,00.html + http://www.onsemi.com/PowerSolutions/product.do?id=ADM1026 Authors: Philip Pokorny for Penguin Computing diff --git a/Documentation/hwmon/g760a b/Documentation/hwmon/g760a index e032eeb..cfc8945 100644 --- a/Documentation/hwmon/g760a +++ b/Documentation/hwmon/g760a @@ -5,7 +5,7 @@ Supported chips: * Global Mixed-mode Technology Inc. G760A Prefix: 'g760a' Datasheet: Publicly available at the GMT website - http://www.gmt.com.tw/datasheet/g760a.pdf + http://www.gmt.com.tw/product/datasheet/EDS-760A.pdf Author: Herbert Valerio Riedel diff --git a/Documentation/hwmon/gl518sm b/Documentation/hwmon/gl518sm index 229f8b7..26f9f3c 100644 --- a/Documentation/hwmon/gl518sm +++ b/Documentation/hwmon/gl518sm @@ -5,11 +5,10 @@ Supported chips: * Genesys Logic GL518SM release 0x00 Prefix: 'gl518sm' Addresses scanned: I2C 0x2c and 0x2d - Datasheet: http://www.genesyslogic.com/pdf * Genesys Logic GL518SM release 0x80 Prefix: 'gl518sm' Addresses scanned: I2C 0x2c and 0x2d - Datasheet: http://www.genesyslogic.com/pdf + Datasheet: http://www.genesyslogic.com/ Authors: Frodo Looijaard , diff --git a/Documentation/hwmon/k8temp b/Documentation/hwmon/k8temp index 0005c71..716dc24 100644 --- a/Documentation/hwmon/k8temp +++ b/Documentation/hwmon/k8temp @@ -5,7 +5,7 @@ Supported chips: * AMD Athlon64/FX or Opteron CPUs Prefix: 'k8temp' Addresses scanned: PCI space - Datasheet: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf + Datasheet: http://support.amd.com/us/Processor_TechDocs/32559.pdf Author: Rudolf Marek Contact: Rudolf Marek diff --git a/Documentation/hwmon/lm85 b/Documentation/hwmon/lm85 index a76aefe..b98e0e0 100644 --- a/Documentation/hwmon/lm85 +++ b/Documentation/hwmon/lm85 @@ -9,15 +9,15 @@ Supported chips: * Analog Devices ADM1027 Prefix: 'adm1027' Addresses scanned: I2C 0x2c, 0x2d, 0x2e - Datasheet: http://www.analog.com/en/prod/0,,766_825_ADM1027,00.html + Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADM1027 * Analog Devices ADT7463 Prefix: 'adt7463' Addresses scanned: I2C 0x2c, 0x2d, 0x2e - Datasheet: http://www.analog.com/en/prod/0,,766_825_ADT7463,00.html + Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7463 * SMSC EMC6D100, SMSC EMC6D101 Prefix: 'emc6d100' Addresses scanned: I2C 0x2c, 0x2d, 0x2e - Datasheet: http://www.smsc.com/main/tools/discontinued/6d100.pdf + Datasheet: http://www.smsc.com/media/Downloads_Public/discontinued/6d100.pdf * SMSC EMC6D102 Prefix: 'emc6d102' Addresses scanned: I2C 0x2c, 0x2d, 0x2e diff --git a/Documentation/hwmon/smsc47m1 b/Documentation/hwmon/smsc47m1 index 42c8431..2a13378 100644 --- a/Documentation/hwmon/smsc47m1 +++ b/Documentation/hwmon/smsc47m1 @@ -7,13 +7,10 @@ Supported chips: Addresses scanned: none, address read from Super I/O config space Prefix: 'smsc47m1' Datasheets: - http://www.smsc.com/main/datasheets/47b27x.pdf - http://www.smsc.com/main/datasheets/47m10x.pdf - http://www.smsc.com/main/datasheets/47m112.pdf - http://www.smsc.com/main/tools/discontinued/47m13x.pdf - http://www.smsc.com/main/datasheets/47m14x.pdf - http://www.smsc.com/main/tools/discontinued/47m15x.pdf - http://www.smsc.com/main/datasheets/47m192.pdf + http://www.smsc.com/media/Downloads_Public/Data_Sheets/47b272.pdf + http://www.smsc.com/media/Downloads_Public/Data_Sheets/47m10x.pdf + http://www.smsc.com/media/Downloads_Public/Data_Sheets/47m112.pdf + http://www.smsc.com/ * SMSC LPC47M292 Addresses scanned: none, address read from Super I/O config space Prefix: 'smsc47m2' diff --git a/Documentation/hwmon/thmc50 b/Documentation/hwmon/thmc50 index 9639ca9..8a7772a 100644 --- a/Documentation/hwmon/thmc50 +++ b/Documentation/hwmon/thmc50 @@ -9,7 +9,7 @@ Supported chips: * Texas Instruments THMC50 Prefix: 'thmc50' Addresses scanned: I2C 0x2c - 0x2e - Datasheet: http://focus.ti.com/docs/prod/folders/print/thmc50.html + Datasheet: http://www.ti.com/ Author: Krzysztof Helt diff --git a/Documentation/hwmon/via686a b/Documentation/hwmon/via686a index d651b25..e5f90ab 100644 --- a/Documentation/hwmon/via686a +++ b/Documentation/hwmon/via686a @@ -5,7 +5,7 @@ Supported chips: * Via VT82C686A, VT82C686B Southbridge Integrated Hardware Monitor Prefix: 'via686a' Addresses scanned: ISA in PCI-space encoded address - Datasheet: On request through web form (http://www.via.com.tw/en/support/datasheets/) + Datasheet: On request through web form (http://www.via.com.tw/en/resources/download-center/) Authors: Kyösti Mälkki , diff --git a/Documentation/hwmon/w83627hf b/Documentation/hwmon/w83627hf index 44dd2bc..fb145e5 100644 --- a/Documentation/hwmon/w83627hf +++ b/Documentation/hwmon/w83627hf @@ -5,23 +5,19 @@ Supported chips: * Winbond W83627HF (ISA accesses ONLY) Prefix: 'w83627hf' Addresses scanned: ISA address retrieved from Super I/O registers - Datasheet: http://www.winbond.com/PDF/sheet/w83627hf.pdf * Winbond W83627THF Prefix: 'w83627thf' Addresses scanned: ISA address retrieved from Super I/O registers - Datasheet: http://www.winbond.com/PDF/sheet/w83627thf.pdf * Winbond W83697HF Prefix: 'w83697hf' Addresses scanned: ISA address retrieved from Super I/O registers - Datasheet: http://www.winbond.com/PDF/sheet/697hf.pdf * Winbond W83637HF Prefix: 'w83637hf' Addresses scanned: ISA address retrieved from Super I/O registers - Datasheet: http://www.winbond.com/PDF/sheet/w83637hf.pdf * Winbond W83687THF Prefix: 'w83687thf' Addresses scanned: ISA address retrieved from Super I/O registers - Datasheet: Provided by Winbond on request + Datasheet: Provided by Winbond on request(http://www.winbond.com/hq/enu) Authors: Frodo Looijaard , diff --git a/Documentation/hwmon/w83781d b/Documentation/hwmon/w83781d index c91e0b6..ecbc1e4 100644 --- a/Documentation/hwmon/w83781d +++ b/Documentation/hwmon/w83781d @@ -9,7 +9,7 @@ Supported chips: * Winbond W83782D Prefix: 'w83782d' Addresses scanned: I2C 0x28 - 0x2f, ISA 0x290 (8 I/O ports) - Datasheet: http://www.winbond.com/PDF/sheet/w83782d.pdf + Datasheet: http://www.winbond.com * Winbond W83783S Prefix: 'w83783s' Addresses scanned: I2C 0x2d diff --git a/Documentation/hwmon/w83792d b/Documentation/hwmon/w83792d index 14a668e..8a023ce 100644 --- a/Documentation/hwmon/w83792d +++ b/Documentation/hwmon/w83792d @@ -5,7 +5,7 @@ Supported chips: * Winbond W83792D Prefix: 'w83792d' Addresses scanned: I2C 0x2c - 0x2f - Datasheet: http://www.winbond.com.tw/E-WINBONDHTM/partner/PDFresult.asp?Pname=1035 + Datasheet: http://www.winbond.com.tw Author: Chunhao Huang Contact: DZShen diff --git a/Documentation/i2c/busses/i2c-ali1535 b/Documentation/i2c/busses/i2c-ali1535 index acbc65a..5d46342 100644 --- a/Documentation/i2c/busses/i2c-ali1535 +++ b/Documentation/i2c/busses/i2c-ali1535 @@ -3,7 +3,7 @@ Kernel driver i2c-ali1535 Supported adapters: * Acer Labs, Inc. ALI 1535 (south bridge) Datasheet: Now under NDA - http://www.ali.com.tw/eng/support/datasheet_request.php + http://www.ali.com.tw/ Authors: Frodo Looijaard , diff --git a/Documentation/i2c/busses/i2c-ali1563 b/Documentation/i2c/busses/i2c-ali1563 index 5469169..41b1a07 100644 --- a/Documentation/i2c/busses/i2c-ali1563 +++ b/Documentation/i2c/busses/i2c-ali1563 @@ -3,7 +3,7 @@ Kernel driver i2c-ali1563 Supported adapters: * Acer Labs, Inc. ALI 1563 (south bridge) Datasheet: Now under NDA - http://www.ali.com.tw/eng/support/datasheet_request.php + http://www.ali.com.tw/ Author: Patrick Mochel diff --git a/Documentation/i2c/busses/i2c-ali15x3 b/Documentation/i2c/busses/i2c-ali15x3 index 600da90..42888d8 100644 --- a/Documentation/i2c/busses/i2c-ali15x3 +++ b/Documentation/i2c/busses/i2c-ali15x3 @@ -3,7 +3,7 @@ Kernel driver i2c-ali15x3 Supported adapters: * Acer Labs, Inc. ALI 1533 and 1543C (south bridge) Datasheet: Now under NDA - http://www.ali.com.tw/eng/support/datasheet_request.php + http://www.ali.com.tw/ Authors: Frodo Looijaard , diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4 index ac540c7..475bb4a 100644 --- a/Documentation/i2c/busses/i2c-piix4 +++ b/Documentation/i2c/busses/i2c-piix4 @@ -97,4 +97,4 @@ of all affected systems, so the only safe solution was to prevent access to the SMBus on all IBM systems (detected using DMI data.) For additional information, read: -http://www.lm-sensors.org/browser/lm-sensors/trunk/README.thinkpad +http://www.lm-sensors.org/browser/lm-sensors/trunk/README diff --git a/Documentation/i2c/busses/i2c-sis630 b/Documentation/i2c/busses/i2c-sis630 index 629ea2c3..0b96973 100644 --- a/Documentation/i2c/busses/i2c-sis630 +++ b/Documentation/i2c/busses/i2c-sis630 @@ -2,7 +2,7 @@ Kernel driver i2c-sis630 Supported adapters: * Silicon Integrated Systems Corp (SiS) - 630 chipset (Datasheet: available at http://amalysh.bei.t-online.de/docs/SIS/) + 630 chipset (Datasheet: available at http://www.sfr-fresh.com/linux) 730 chipset * Possible other SiS chipsets ? diff --git a/Documentation/ia64/aliasing.txt b/Documentation/ia64/aliasing.txt index aa3e953..5a4dea6 100644 --- a/Documentation/ia64/aliasing.txt +++ b/Documentation/ia64/aliasing.txt @@ -168,8 +168,6 @@ PAST PROBLEM CASES mmap of 0x0-0x9FFFF /dev/mem by "hwinfo" on HP sx1000 with VGA enabled - See https://bugzilla.novell.com/show_bug.cgi?id=140858. - The EFI memory map reports the following attributes: 0x00000-0x9FFFF WB only 0xA0000-0xBFFFF UC only (VGA frame buffer) diff --git a/Documentation/ia64/serial.txt b/Documentation/ia64/serial.txt index 040b977..6869c73 100644 --- a/Documentation/ia64/serial.txt +++ b/Documentation/ia64/serial.txt @@ -133,7 +133,7 @@ TROUBLESHOOTING SERIAL CONSOLE PROBLEMS -[1] http://www.dig64.org/specifications/DIG64_PCDPv20.pdf +[1] http://www.dig64.org/specifications/agreement The table was originally defined as the "HCDP" for "Headless Console/Debug Port." The current version is the "PCDP" for "Primary Console and Debug Port Devices." diff --git a/Documentation/infiniband/user_verbs.txt b/Documentation/infiniband/user_verbs.txt index afe3f8d..e5092d6 100644 --- a/Documentation/infiniband/user_verbs.txt +++ b/Documentation/infiniband/user_verbs.txt @@ -5,7 +5,7 @@ USERSPACE VERBS ACCESS described in chapter 11 of the InfiniBand Architecture Specification. To use the verbs, the libibverbs library, available from - , is required. libibverbs contains a + http://www.openfabrics.org/, is required. libibverbs contains a device-independent API for using the ib_uverbs interface. libibverbs also requires appropriate device-dependent kernel and userspace driver for your InfiniBand hardware. For example, to use diff --git a/Documentation/input/appletouch.txt b/Documentation/input/appletouch.txt index 4f7c633..b13de3f 100644 --- a/Documentation/input/appletouch.txt +++ b/Documentation/input/appletouch.txt @@ -82,4 +82,4 @@ Links: ------ [1]: http://johannes.sipsolutions.net/PowerBook/touchpad/ -[2]: http://web.telia.com/~u89404340/touchpad/index.html +[2]: http://web.archive.org/web/*/http://web.telia.com/~u89404340/touchpad/index.html diff --git a/Documentation/input/bcm5974.txt b/Documentation/input/bcm5974.txt index 5e22dcf..74d3876 100644 --- a/Documentation/input/bcm5974.txt +++ b/Documentation/input/bcm5974.txt @@ -62,4 +62,4 @@ Links ----- [1] http://ubuntuforums.org/showthread.php?t=840040 -[2] http://http://bitmath.org/code/ +[2] http://bitmath.org/code/ diff --git a/Documentation/input/iforce-protocol.txt b/Documentation/input/iforce-protocol.txt index 3ac9241..2d5fbfd 100644 --- a/Documentation/input/iforce-protocol.txt +++ b/Documentation/input/iforce-protocol.txt @@ -251,7 +251,7 @@ Check www.immerse.com for Immersion Studio, and www.fcoder.com for ComPortSpy. ** Author of this document ** Johann Deneux -Home page at http://www.esil.univ-mrs.fr/~jdeneux/projects/ff/ +Home page at http://web.archive.org/web/*/http://www.esil.univ-mrs.fr Additions by Vojtech Pavlik. diff --git a/Documentation/input/sentelic.txt b/Documentation/input/sentelic.txt index b35affd..b2ef125 100644 --- a/Documentation/input/sentelic.txt +++ b/Documentation/input/sentelic.txt @@ -341,7 +341,7 @@ Byte 5~8: Don't care (Absolute packet) FSP supports basic PS/2 commanding set and modes, refer to following URL for details about PS/2 commands: -http://www.computer-engineering.org/index.php?title=PS/2_Mouse_Interface +http://www.computer-engineering.org/ps2mouse/ ============================================================================== * Programming Sequence for Determining Packet Parsing Flow diff --git a/Documentation/input/xpad.txt b/Documentation/input/xpad.txt index aae0d40..7cc9a43 100644 --- a/Documentation/input/xpad.txt +++ b/Documentation/input/xpad.txt @@ -150,7 +150,7 @@ the basic functionality. 1. http://euc.jp/periphs/xbox-controller.ja.html (ITO Takayuki) 2. http://xpad.xbox-scene.com/ -3. http://www.xboxhackz.com/Hackz-Reference.htm +3. http://www.markosweb.com/www/xboxhackz.com/ 4. /proc/bus/usb/devices - dump from InterAct PowerPad Pro (Germany): diff --git a/Documentation/intel_txt.txt b/Documentation/intel_txt.txt index 5dc59b0..849de1a 100644 --- a/Documentation/intel_txt.txt +++ b/Documentation/intel_txt.txt @@ -25,20 +25,18 @@ which has been updated for the new released platforms. Intel TXT has been presented at various events over the past few years, some of which are: LinuxTAG 2008: - http://www.linuxtag.org/2008/en/conf/events/vp-donnerstag/ - details.html?talkid=110 + http://www.linuxtag.org/2008/en/conf/events/vp-donnerstag.html TRUST2008: - http://www.trust2008.eu/downloads/Keynote-Speakers/ + http://www.trust-conference.eu/downloads/Keynote-Speakers/ 3_David-Grawrock_The-Front-Door-of-Trusted-Computing.pdf - IDF 2008, Shanghai: - http://inteldeveloperforum.com.edgesuite.net/shanghai_2008/ - aep/PROS003/index.html + IDF, Shanghai: + http://www.prcidf.com.cn/index_en.html IDFs 2006, 2007 (I'm not sure if/where they are online) Trusted Boot Project Overview: ============================= -Trusted Boot (tboot) is an open source, pre- kernel/VMM module that +Trusted Boot (tboot) is an open source, pre-kernel/VMM module that uses Intel TXT to perform a measured and verified launch of an OS kernel/VMM. diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index dd5806f..2ec3d7d 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -74,7 +74,7 @@ Code Seq#(hex) Include File Comments 0x10 00-0F drivers/char/s390/vmcp.h 0x12 all linux/fs.h linux/blkpg.h -0x1b all InfiniBand Subsystem +0x1b all InfiniBand Subsystem 0x20 all drivers/cdrom/cm206.h 0x22 all scsi/sg.h '#' 00-3F IEEE 1394 Subsystem Block for the entire subsystem @@ -190,7 +190,7 @@ Code Seq#(hex) Include File Comments '[' 00-07 linux/usb/tmc.h USB Test and Measurement Devices 'a' all linux/atm*.h, linux/sonet.h ATM on linux - + 'b' 00-FF conflict! bit3 vme host bridge 'b' 00-0F media/bt819.h conflict! @@ -225,7 +225,7 @@ Code Seq#(hex) Include File Comments 'k' 00-0F linux/spi/spidev.h conflict! 'k' 00-05 video/kyro.h conflict! 'l' 00-3F linux/tcfs_fs.h transparent cryptographic file system - + 'l' 40-7F linux/udf_fs_i.h in development: 'm' 00-09 linux/mmtimer.h conflict! @@ -252,7 +252,7 @@ Code Seq#(hex) Include File Comments 'q' 00-1F linux/serio.h 'q' 80-FF linux/telephony.h Internet PhoneJACK, Internet LineJACK - linux/ixjuser.h + linux/ixjuser.h 'r' 00-1F linux/msdos_fs.h and fs/fat/dir.c 's' all linux/cdk.h 't' 00-7F linux/if_ppp.h @@ -286,7 +286,7 @@ Code Seq#(hex) Include File Comments 0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range 0x8B all linux/wireless.h 0x8C 00-3F WiNRADiO driver - + 0x90 00 drivers/cdrom/sbpcd.h 0x92 00-0F drivers/usb/mon/mon_bin.c 0x93 60-7F linux/auto_fs.h diff --git a/Documentation/isdn/README b/Documentation/isdn/README index 6783437..cfb1884 100644 --- a/Documentation/isdn/README +++ b/Documentation/isdn/README @@ -36,7 +36,7 @@ README for the ISDN-subsystem http://www.mhessler.de/i4lfaq/ It can be viewed online, or downloaded in sgml/text/html format. The FAQ can also be viewed online at - http://www.isdn4inux.de/faq/ + http://www.isdn4linux.de/faq/ or downloaded from ftp://ftp.isdn4linux.de/pub/isdn4linux/FAQ/ diff --git a/Documentation/isdn/README.HiSax b/Documentation/isdn/README.HiSax index 031c8d8..99e87a6 100644 --- a/Documentation/isdn/README.HiSax +++ b/Documentation/isdn/README.HiSax @@ -486,7 +486,7 @@ Appendix: Teles PCMCIA driver ----------------------------- See - http://www.stud.uni-wuppertal.de/~ea0141/pcmcia.html + http://www.linux.no/teles_cs.txt for instructions. Appendix: Linux and ISDN-leased lines diff --git a/Documentation/ja_JP/HOWTO b/Documentation/ja_JP/HOWTO index 5547698..b63301a 100644 --- a/Documentation/ja_JP/HOWTO +++ b/Documentation/ja_JP/HOWTO @@ -223,7 +223,7 @@ web サイトには、コードの構成、サブシステム、現在存在す あなたがどこからスタートして良いかわからないが、Linux カーネル開発コミュ ニティに参加して何かすることをさがしている場合には、Linux kernel Janitor's プロジェクトにいけば良いでしょう - - http://janitor.kernelnewbies.org/ + http://kernelnewbies.org/KernelJanitors ここはそのようなスタートをするのにうってつけの場所です。ここには、 Linux カーネルソースツリーの中に含まれる、きれいにし、修正しなければな らない、単純な問題のリストが記述されています。このプロジェクトに関わる diff --git a/Documentation/ja_JP/SubmittingPatches b/Documentation/ja_JP/SubmittingPatches index a9dc124..f107c83 100644 --- a/Documentation/ja_JP/SubmittingPatches +++ b/Documentation/ja_JP/SubmittingPatches @@ -97,7 +97,7 @@ Quilt: http://savannah.nongnu.org/projects/quilt Andrew Morton's patch scripts: -http://www.zip.com.au/~akpm/linux/patches/ +http://userweb.kernel.org/~akpm/stuff/tpp.txt このリンクの先のスクリプトの代わりとして、quilt がパッチマネジメント ツールとして推奨されています(上のリンクを見てください)。 @@ -210,7 +210,7 @@ VGER.KERNEL.ORG でホスティングされているメーリングリストの ・移植性のないコードから移植性のあるコードへの置き換え(小さい範囲で あればアーキテクチャ特有のことでも他の人がコピーできます) ・作者やメンテナによる修正(すなわち patch monkey の再転送モード) -URL: +EMAIL: 7) MIME やリンクや圧縮ファイルや添付ファイルではなくプレインテキストのみ @@ -534,7 +534,7 @@ gcc においては、マクロと同じくらい軽いです。 ---------------------- Andrew Morton, "The perfect patch" (tpp). - + Jeff Garzik, "Linux kernel patch submission format". diff --git a/Documentation/kernel-docs.txt b/Documentation/kernel-docs.txt index ec8d31ee..715eaaf 100644 --- a/Documentation/kernel-docs.txt +++ b/Documentation/kernel-docs.txt @@ -75,7 +75,7 @@ * Title: "Conceptual Architecture of the Linux Kernel" Author: Ivan T. Bowman. - URL: http://plg.uwaterloo.ca/~itbowman/papers/CS746G-a1.html + URL: http://plg.uwaterloo.ca/ Keywords: conceptual software architecture, extracted design, reverse engineering, system structure. Description: Conceptual software architecture of the Linux kernel, @@ -84,7 +84,7 @@ * Title: "Concrete Architecture of the Linux Kernel" Author: Ivan T. Bowman, Saheem Siddiqi, and Meyer C. Tanuan. - URL: http://plg.uwaterloo.ca/~itbowman/papers/CS746G-a2.html + URL: http://plg.uwaterloo.ca/ Keywords: concrete architecture, extracted design, reverse engineering, system structure, dependencies. Description: Concrete architecture of the Linux kernel, @@ -95,7 +95,7 @@ * Title: "Linux as a Case Study: Its Extracted Software Architecture" Author: Ivan T. Bowman, Richard C. Holt and Neil V. Brewster. - URL: http://plg.uwaterloo.ca/~itbowman/papers/linuxcase.html + URL: http://plg.uwaterloo.ca/ Keywords: software architecture, architecture recovery, redocumentation. Description: Paper appeared at ICSE'99, Los Angeles, May 16-22, @@ -104,7 +104,7 @@ * Title: "Overview of the Virtual File System" Author: Richard Gooch. - URL: http://www.atnf.csiro.au/~rgooch/linux/vfs.txt + URL: http://www.mjmwired.net/kernel/Documentation/filesystems/vfs.txt Keywords: VFS, File System, mounting filesystems, opening files, dentries, dcache. Description: Brief introduction to the Linux Virtual File System. @@ -267,15 +267,13 @@ * Title: "Kernel API changes from 2.0 to 2.2" Author: Richard Gooch. URL: - http://www.atnf.csiro.au/~rgooch/linux/docs/porting-to-2.2.html + http://www.linuxhq.com/guides/LKMPG/node28.html Keywords: 2.2, changes. Description: Kernel functions/structures/variables which changed from 2.0.x to 2.2.x. * Title: "Kernel API changes from 2.2 to 2.4" Author: Richard Gooch. - URL: - http://www.atnf.csiro.au/~rgooch/linux/docs/porting-to-2.4.html Keywords: 2.4, changes. Description: Kernel functions/structures/variables which changed from 2.2.x to 2.4.x. @@ -290,7 +288,6 @@ * Title: "I/O Event Handling Under Linux" Author: Richard Gooch. - URL: http://www.atnf.csiro.au/~rgooch/linux/docs/io-events.html Keywords: IO, I/O, select(2), poll(2), FDs, aio_read(2), readiness event queues. Description: From the Introduction: "I/O Event handling is about @@ -386,64 +383,64 @@ * Title: "Porting Device Drivers To Linux 2.2: part II" Author: Alan Cox. - URL: http://www.linux-mag.com/1999-06/gear_01.html + URL: http://www.linux-mag.com/id/238 Keywords: ports, porting. Description: Second part on porting from 2.0 to 2.2 kernels. * Title: "How To Make Sure Your Driver Will Work On The Power Macintosh" Author: Paul Mackerras. - URL: http://www.linux-mag.com/1999-07/gear_01.html + URL: http://www.linux-mag.com/id/261 Keywords: Mac, Power Macintosh, porting, drivers, compatibility. Description: The title says it all. * Title: "An Introduction to SCSI Drivers" Author: Alan Cox. - URL: http://www.linux-mag.com/1999-08/gear_01.html + URL: http://www.linux-mag.com/id/284 Keywords: SCSI, device, driver. Description: The title says it all. * Title: "Advanced SCSI Drivers And Other Tales" Author: Alan Cox. - URL: http://www.linux-mag.com/1999-09/gear_01.html + URL: http://www.linux-mag.com/id/307 Keywords: SCSI, device, driver, advanced. Description: The title says it all. * Title: "Writing Linux Mouse Drivers" Author: Alan Cox. - URL: http://www.linux-mag.com/1999-10/gear_01.html + URL: http://www.linux-mag.com/id/330 Keywords: mouse, driver, gpm. Description: The title says it all. * Title: "More on Mouse Drivers" Author: Alan Cox. - URL: http://www.linux-mag.com/1999-11/gear_01.html + URL: http://www.linux-mag.com/id/356 Keywords: mouse, driver, gpm, races, asynchronous I/O. Description: The title still says it all. * Title: "Writing Video4linux Radio Driver" Author: Alan Cox. - URL: http://www.linux-mag.com/1999-12/gear_01.html + URL: http://www.linux-mag.com/id/381 Keywords: video4linux, driver, radio, radio devices. Description: The title says it all. * Title: "Video4linux Drivers, Part 1: Video-Capture Device" Author: Alan Cox. - URL: http://www.linux-mag.com/2000-01/gear_01.html + URL: http://www.linux-mag.com/id/406 Keywords: video4linux, driver, video capture, capture devices, camera driver. Description: The title says it all. * Title: "Video4linux Drivers, Part 2: Video-capture Devices" Author: Alan Cox. - URL: http://www.linux-mag.com/2000-02/gear_01.html + URL: http://www.linux-mag.com/id/429 Keywords: video4linux, driver, video capture, capture devices, camera driver, control, query capabilities, capability, facility. Description: The title says it all. * Title: "PCI Management in Linux 2.2" Author: Alan Cox. - URL: http://www.linux-mag.com/2000-03/gear_01.html + URL: http://www.linux-mag.com/id/452 Keywords: PCI, bus, bus-mastering. Description: The title says it all. @@ -502,7 +499,7 @@ * Title: "A Linux vm README" Author: Kanoj Sarcar. - URL: http://reality.sgi.com/kanoj_engr/vm229.html + URL: http://kos.enix.org/pub/linux-vmm.html Keywords: virtual memory, mm, pgd, vma, page, page flags, page cache, swap cache, kswapd. Description: Telegraphic, short descriptions and definitions @@ -659,7 +656,7 @@ * Name: "Linux Kernel Source Reference" Author: Thomas Graichen. - URL: http://innominate.org/~graichen/projects/lksr/ + URL: http://marc.info/?l=linux-kernel&m=96446640102205&w=4 Keywords: CVS, web, cvsweb, browsing source code. Description: Web interface to a CVS server with the kernel sources. "Here you can have a look at any file of the Linux kernel @@ -682,7 +679,7 @@ produced during the week. Published every Thursday. * Name: "Kernel Traffic" - URL: http://kt.zork.net/kernel-traffic/ + URL: http://kt.earth.li/kernel-traffic/index.html Keywords: linux-kernel mailing list, weekly kernel news. Description: Weekly newsletter covering the most relevant discussions of the linux-kernel mailing list. diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO index 029fca9..e3a55b6 100644 --- a/Documentation/ko_KR/HOWTO +++ b/Documentation/ko_KR/HOWTO @@ -122,7 +122,7 @@ mtk.manpages@gmail.com의 메인테이너에게 보낼 것을 권장한다. 올바른 패치들을 만드는 법에 관한 훌륭한 다른 문서들이 있다. "The Perfect Patch" - http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt + http://userweb.kernel.org/~akpm/stuff/tpp.txt "Linux kernel patch submission format" http://linux.yyz.us/patch-format.html @@ -192,7 +192,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H 여러분이 어디서 시작해야 할진 모르지만 커널 개발 커뮤니티에 참여할 수 있는 일들을 찾길 원한다면 리눅스 커널 Janitor 프로젝트를 살펴봐라. - http://janitor.kernelnewbies.org/ + http://kernelnewbies.org/KernelJanitors 그곳은 시작하기에 훌륭한 장소이다. 그곳은 리눅스 커널 소스 트리내에 간단히 정리되고 수정될 수 있는 문제들에 관하여 설명한다. 여러분은 이 프로젝트를 대표하는 개발자들과 일하면서 자신의 패치를 리눅스 커널 트리에 @@ -596,7 +596,7 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅 이것이 무엇인지 더 자세한 것을 알고 싶다면 다음 문서의 ChageLog 항을 봐라. "The Perfect Patch" - http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt + http://userweb.kernel.org/~akpm/stuff/tpp.txt @@ -610,7 +610,7 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅 ---------- -"개발 프로세스"(http://linux.tar.gz/articles/2.6-development_process) 섹션을 +"개발 프로세스"(http://lwn.net/Articles/94386/) 섹션을 작성하는데 있어 참고할 문서를 사용하도록 허락해준 Paolo Ciarrocchi에게 감사한다. 여러분들이 말해야 할 것과 말해서는 안되는 것의 목록 중 일부를 제공해준 Randy Dunlap과 Gerrit Huizenga에게 감사한다. 또한 검토와 의견 그리고 diff --git a/Documentation/laptops/acer-wmi.txt b/Documentation/laptops/acer-wmi.txt index 0768fcc..4beafa6 100644 --- a/Documentation/laptops/acer-wmi.txt +++ b/Documentation/laptops/acer-wmi.txt @@ -173,7 +173,7 @@ Credits ******* Olaf Tauber, who did the real hard work when he developed acerhk -http://www.informatik.hu-berlin.de/~tauber/acerhk +http://www.cakey.de/acerhk/ All the authors of laptop ACPI modules in the kernel, whose work was an inspiration in the early days of acer_acpi Mathieu Segaud, who solved the problem with having to modprobe the driver diff --git a/Documentation/ldm.txt b/Documentation/ldm.txt index 718085b..4f80edd 100644 --- a/Documentation/ldm.txt +++ b/Documentation/ldm.txt @@ -98,7 +98,7 @@ More Documentation There is an Overview of the LDM together with complete Technical Documentation. It is available for download. - http://www.linux-ntfs.org/content/view/19/37/ + http://www.linux-ntfs.org/ If you have any LDM questions that aren't answered in the documentation, email me. diff --git a/Documentation/md.txt b/Documentation/md.txt index e4e893e..a81c7b4 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -1,5 +1,5 @@ Tools that manage md devices can be found at - http://www..kernel.org/pub/linux/utils/raid/.... + http://www.kernel.org/pub/linux/utils/raid/ Boot time assembly of RAID arrays diff --git a/Documentation/misc-devices/c2port.txt b/Documentation/misc-devices/c2port.txt index d9bf93e..ea73444 100644 --- a/Documentation/misc-devices/c2port.txt +++ b/Documentation/misc-devices/c2port.txt @@ -32,10 +32,10 @@ The C2 Interface main references are at (http://www.silabs.com) Silicon Laboratories site], see: - AN127: FLASH Programming via the C2 Interface at -http://www.silabs.com/public/documents/tpub_doc/anote/Microcontrollers/Small_Form_Factor/en/an127.pdf, and +http://www.silabs.com/Support Documents/TechnicalDocs/an127.pdf - C2 Specification at -http://www.silabs.com/public/documents/tpub_doc/spec/Microcontrollers/en/C2spec.pdf, +http://www.silabs.com/pages/DownloadDoc.aspx?FILEURL=Support%20Documents/TechnicalDocs/an127.pdf&src=SearchResults however it implements a two wire serial communication protocol (bit banging) designed to enable in-system programming, debugging, and diff --git a/Documentation/mtd/nand_ecc.txt b/Documentation/mtd/nand_ecc.txt index 274821b..990efd7 100644 --- a/Documentation/mtd/nand_ecc.txt +++ b/Documentation/mtd/nand_ecc.txt @@ -91,7 +91,7 @@ ECC 1 rp15 rp14 rp13 rp12 rp11 rp10 rp09 rp08 ECC 2 cp5 cp4 cp3 cp2 cp1 cp0 1 1 I detected after writing this that ST application note AN1823 -(http://www.st.com/stonline/books/pdf/docs/10123.pdf) gives a much +(http://www.st.com/stonline/) gives a much nicer picture.(but they use line parity as term where I use row parity) Oh well, I'm graphically challenged, so suffer with me for a moment :-) And I could not reuse the ST picture anyway for copyright reasons. diff --git a/Documentation/networking/3c509.txt b/Documentation/networking/3c509.txt index 3c45d5d..dcc9eaf 100644 --- a/Documentation/networking/3c509.txt +++ b/Documentation/networking/3c509.txt @@ -31,7 +31,7 @@ models: Large portions of this documentation were heavily borrowed from the guide written the original author of the 3c509 driver, Donald Becker. The master copy of that document, which contains notes on older versions of the driver, -currently resides on Scyld web server: http://www.scyld.com/network/3c509.html. +currently resides on Scyld web server: http://www.scyld.com/. (1) Special Driver Features diff --git a/Documentation/networking/README.ipw2100 b/Documentation/networking/README.ipw2100 index f3fcaa4..6f85e1d 100644 --- a/Documentation/networking/README.ipw2100 +++ b/Documentation/networking/README.ipw2100 @@ -72,8 +72,7 @@ such, if you are interested in deploying or shipping a driver as part of solution intended to be used for purposes other than development, please obtain a tested driver from Intel Customer Support at: -http://support.intel.com/support/notebook/sb/CS-006408.htm - +http://www.intel.com/support/wireless/sb/CS-006408.htm 1. Introduction ----------------------------------------------- diff --git a/Documentation/networking/README.ipw2200 b/Documentation/networking/README.ipw2200 index 80c7285..c276490 100644 --- a/Documentation/networking/README.ipw2200 +++ b/Documentation/networking/README.ipw2200 @@ -85,7 +85,7 @@ such, if you are interested in deploying or shipping a driver as part of solution intended to be used for purposes other than development, please obtain a tested driver from Intel Customer Support at: -http://support.intel.com/support/notebook/sb/CS-006408.htm +http://support.intel.com 1. Introduction diff --git a/Documentation/networking/README.sb1000 b/Documentation/networking/README.sb1000 index f82d425..f92c2aa 100644 --- a/Documentation/networking/README.sb1000 +++ b/Documentation/networking/README.sb1000 @@ -27,8 +27,8 @@ cable modem easy. in Franco's original source code distribution .tar.gz file. Support for the sb1000 driver can be found at: - http://home.adelphia.net/~siglercm/sb1000.html - http://linuxpower.cx/~cable/ + http://web.archive.org/web/*/http://home.adelphia.net/~siglercm/sb1000.html + http://web.archive.org/web/*/http://linuxpower.cx/~cable/ along with these utilities. diff --git a/Documentation/networking/arcnet.txt b/Documentation/networking/arcnet.txt index 7960125..9ff5795 100644 --- a/Documentation/networking/arcnet.txt +++ b/Documentation/networking/arcnet.txt @@ -68,7 +68,7 @@ REAL NAME" to listserv@tichy.ch.uj.edu.pl. Then, to submit messages to the list, mail to linux-arcnet@tichy.ch.uj.edu.pl. There are archives of the mailing list at: - http://tichy.ch.uj.edu.pl/lists/linux-arcnet + http://epistolary.org/mailman/listinfo.cgi/arcnet The people on linux-net@vger.kernel.org have also been known to be very helpful, especially when we're talking about ALPHA Linux kernels that may or @@ -79,7 +79,7 @@ Other Drivers and Info ---------------------- You can try my ARCNET page on the World Wide Web at: - http://www.worldvisions.ca/~apenwarr/arcnet/ + http://www.qis.net/~jschmitz/arcnet/ Also, SMC (one of the companies that makes ARCnet cards) has a WWW site you might be interested in, which includes several drivers for various cards diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 61f516b..e0ec7cb 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -2432,7 +2432,7 @@ be found at: https://lists.sourceforge.net/lists/listinfo/bonding-devel Donald Becker's Ethernet Drivers and diag programs may be found at : - - http://www.scyld.com/network/ + - http://web.archive.org/web/*/http://www.scyld.com/network/ You will also find a lot of information regarding Ethernet, NWay, MII, etc. at www.scyld.com. diff --git a/Documentation/networking/decnet.txt b/Documentation/networking/decnet.txt index d896895..e12a490 100644 --- a/Documentation/networking/decnet.txt +++ b/Documentation/networking/decnet.txt @@ -4,7 +4,7 @@ 1) Other documentation.... o Project Home Pages - http://www.chygwyn.com/DECnet/ - Kernel info + http://www.chygwyn.com/ - Kernel info http://linux-decnet.sourceforge.net/ - Userland tools http://www.sourceforge.net/projects/linux-decnet/ - Status page diff --git a/Documentation/networking/fore200e.txt b/Documentation/networking/fore200e.txt index b1f337f..6e0d2a9 100644 --- a/Documentation/networking/fore200e.txt +++ b/Documentation/networking/fore200e.txt @@ -39,7 +39,7 @@ version. Alternative binary firmware images can be found somewhere on the ForeThought CD-ROM supplied with your adapter by FORE Systems. You can also get the latest firmware images from FORE Systems at -http://www.fore.com. Register TACTics Online and go to +http://en.wikipedia.org/wiki/FORE_Systems. Register TACTics Online and go to the 'software updates' pages. The firmware binaries are part of the various ForeThought software distributions. diff --git a/Documentation/networking/ipddp.txt b/Documentation/networking/ipddp.txt index 661a555..ba5c217 100644 --- a/Documentation/networking/ipddp.txt +++ b/Documentation/networking/ipddp.txt @@ -36,11 +36,6 @@ AppleTalk-IP to IP decapsulation. Basic instructions for user space tools ======================================= -To enable AppleTalk-IP decapsulation/encapsulation you will need the -proper tools. You can get the tools for decapsulation from -http://spacs1.spacs.k12.wi.us/~jschlst/index.html and for encapsulation -from http://www.maths.unm.edu/~bradford/ltpc.html - I will briefly describe the operation of the tools, but you will need to consult the supporting documentation for each set of tools. diff --git a/Documentation/networking/iphase.txt b/Documentation/networking/iphase.txt index 55eac4a..670b72f 100644 --- a/Documentation/networking/iphase.txt +++ b/Documentation/networking/iphase.txt @@ -22,7 +22,7 @@ The features and limitations of this driver are as follows: - All variants of Interphase ATM PCI (i)Chip adapter cards are supported, including x575 (OC3, control memory 128K , 512K and packet memory 128K, 512K and 1M), x525 (UTP25) and x531 (DS3 and E3). See - http://www.iphase.com/site/iphase-web/?epi_menuItemID=e196f04b4b3b40502f150882e21046a0 + http://www.iphase.com/ for details. - Only x86 platforms are supported. - SMP is supported. diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt index 98f71a5..2a72262 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt @@ -8,7 +8,7 @@ capture network traffic with utilities like tcpdump or any other that needs raw access to network interface. You can find the latest version of this document at: - http://pusa.uv.es/~ulisses/packet_mmap/ + http://wiki.ipxwarzone.com/index.php5?title=Linux_packet_mmap Howto can be found at: http://wiki.gnu-log.net (packet_mmap) @@ -56,7 +56,7 @@ support for PACKET_MMAP, and also probably the libpcap included in your distribu I'm aware of two implementations of PACKET_MMAP in libpcap: - http://pusa.uv.es/~ulisses/packet_mmap/ (by Simon Patarin, based on libpcap 0.6.2) + http://wiki.ipxwarzone.com/ (by Simon Patarin, based on libpcap 0.6.2) http://public.lanl.gov/cpw/ (by Phil Wood, based on lastest libpcap) The rest of this document is intended for people who want to understand diff --git a/Documentation/networking/ray_cs.txt b/Documentation/networking/ray_cs.txt index 145d27a..c0c1230 100644 --- a/Documentation/networking/ray_cs.txt +++ b/Documentation/networking/ray_cs.txt @@ -13,8 +13,8 @@ wireless LAN cards. As of kernel 2.3.18, the ray_cs driver is part of the Linux kernel source. My web page for the development of ray_cs is at -http://world.std.com/~corey/raylink.html and I can be emailed at -corey@world.std.com +http://web.ralinktech.com/ralink/Home/Support/Linux.html +and I can be emailed at corey@world.std.com The kernel driver is based on ray_cs-1.62.tgz diff --git a/Documentation/networking/s2io.txt b/Documentation/networking/s2io.txt index c3d6b4d..9d4e0f4 100644 --- a/Documentation/networking/s2io.txt +++ b/Documentation/networking/s2io.txt @@ -133,7 +133,8 @@ bring down CPU utilization. ** For AMD opteron platforms with 8131 chipset, MMRBC=1 and MOST=1 are recommended as safe parameters. For more information, please review the AMD8131 errata at -http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26310.pdf +http://vip.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/ +26310_AMD-8131_HyperTransport_PCI-X_Tunnel_Revision_Guide_rev_3_18.pdf 6. Available Downloads Neterion "s2io" driver in Red Hat and Suse 2.6-based distributions is kept up diff --git a/Documentation/networking/tlan.txt b/Documentation/networking/tlan.txt index 7e6aa5b..34550df 100644 --- a/Documentation/networking/tlan.txt +++ b/Documentation/networking/tlan.txt @@ -2,7 +2,7 @@ (C) 1998 James Banks (C) 1999-2001 Torben Mathiasen -For driver information/updates visit http://opensource.compaq.com +For driver information/updates visit http://www.compaq.com TLAN driver for Linux, version 1.14a @@ -113,5 +113,5 @@ III. Things to try if you have problems. There is also a tlan mailing list which you can join by sending "subscribe tlan" in the body of an email to majordomo@vuser.vu.union.edu. -There is also a tlan website at http://opensource.compaq.com +There is also a tlan website at http://www.compaq.com diff --git a/Documentation/networking/udplite.txt b/Documentation/networking/udplite.txt index 855d8da..d727a38 100644 --- a/Documentation/networking/udplite.txt +++ b/Documentation/networking/udplite.txt @@ -11,11 +11,13 @@ This file briefly describes the existing kernel support and the socket API. For in-depth information, you can consult: - o The UDP-Lite Homepage: http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/ + o The UDP-Lite Homepage: + http://web.archive.org/web/*/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/ From here you can also download some example application source code. o The UDP-Lite HOWTO on - http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/UDP-Lite-HOWTO.txt + http://web.archive.org/web/*/http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/ + files/UDP-Lite-HOWTO.txt o The Wireshark UDP-Lite WiKi (with capture files): http://wiki.wireshark.org/Lightweight_User_Datagram_Protocol @@ -26,12 +28,7 @@ I) APPLICATIONS Several applications have been ported successfully to UDP-Lite. Ethereal - (now called wireshark) has UDP-Litev4/v6 support by default. The tarball on - - http://www.erg.abdn.ac.uk/users/gerrit/udp-lite/files/udplite_linux.tar.gz - - has source code for several v4/v6 client-server and network testing examples. - + (now called wireshark) has UDP-Litev4/v6 support by default. Porting applications to UDP-Lite is straightforward: only socket level and IPPROTO need to be changed; senders additionally set the checksum coverage length (default = header length = 8). Details are in the next section. diff --git a/Documentation/networking/wavelan.txt b/Documentation/networking/wavelan.txt index afa6e52..90e0ac4 100644 --- a/Documentation/networking/wavelan.txt +++ b/Documentation/networking/wavelan.txt @@ -50,7 +50,8 @@ and a Lucent Modem, and NOT 802.11 compatible. ----------------- o Config : Not yet in kernel o Location : Pcmcia package 3.1.10+ - o on-line doc : http://www.fasta.fh-dortmund.de/users/andy/wvlan/ + o on-line doc : + http://web.archive.org/web/*/http://www.fasta.fh-dortmund.de/users/andy/wvlan/ This is the driver for the current generation of Wavelan IEEE, which is 802.11 compatible. Depending on version, it is 2 Mb/s or 11 diff --git a/Documentation/power/apm-acpi.txt b/Documentation/power/apm-acpi.txt index 1bd799d..6cc423d 100644 --- a/Documentation/power/apm-acpi.txt +++ b/Documentation/power/apm-acpi.txt @@ -28,5 +28,5 @@ and be sure that they are started sometime in the system boot process. Go ahead and start both. If ACPI or APM is not available on your system the associated daemon will exit gracefully. - apmd: http://worldvisions.ca/~apenwarr/apmd/ + apmd: http://ftp.debian.org/pool/main/a/apmd/ acpid: http://acpid.sf.net/ diff --git a/Documentation/power/basic-pm-debugging.txt b/Documentation/power/basic-pm-debugging.txt index 1555001..ddd78172 100644 --- a/Documentation/power/basic-pm-debugging.txt +++ b/Documentation/power/basic-pm-debugging.txt @@ -179,8 +179,7 @@ use the PM_TRACE mechanism documented in Documentation/s2ram.txt . To verify that the STR works, it is generally more convenient to use the s2ram tool available from http://suspend.sf.net and documented at -http://en.opensuse.org/s2ram . However, before doing that it is recommended to -carry out STR testing using the facility described in section 1. +http://en.opensuse.org/SDB:Suspend_to_RAM. Namely, after writing "freezer", "devices", "platform", "processors", or "core" into /sys/power/pm_test (available if the kernel is compiled with diff --git a/Documentation/power/video.txt b/Documentation/power/video.txt index 2b35849..3e6272b 100644 --- a/Documentation/power/video.txt +++ b/Documentation/power/video.txt @@ -67,11 +67,11 @@ There are a few types of systems where video works after S3 resume: POSTing bios works. Ole Rohne has patch to do just that at http://dev.gentoo.org/~marineam/patch-radeonfb-2.6.11-rc2-mm2. -(8) on some systems, you can use the video_post utility mentioned here: - http://bugzilla.kernel.org/show_bug.cgi?id=3670. Do echo 3 > /sys/power/state - && /usr/sbin/video_post - which will initialize the display in console mode. - If you are in X, you can switch to a virtual terminal and back to X using - CTRL+ALT+F1 - CTRL+ALT+F7 to get the display working in graphical mode again. +(8) on some systems, you can use the video_post utility and or + do echo 3 > /sys/power/state && /usr/sbin/video_post - which will + initialize the display in console mode. If you are in X, you can switch + to a virtual terminal and back to X using CTRL+ALT+F1 - CTRL+ALT+F7 to get + the display working in graphical mode again. Now, if you pass acpi_sleep=something, and it does not work with your bios, you'll get a hard crash during resume. Be careful. Also it is @@ -177,7 +177,7 @@ Mainboard Graphics card hack (or "how to do it") Asus A7V8X nVidia RIVA TNT2 model 64 s3_bios,s3_mode (4) -(*) from http://www.ubuntulinux.org/wiki/HoaryPMResults, not sure +(*) from https://wiki.ubuntu.com/HoaryPMResults, not sure which options to use. If you know, please tell me. (***) To be tested with a newer kernel. diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 46d2210..568fa08 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -1048,7 +1048,7 @@ IV - "dtc", the device tree compiler dtc source code can be found at - + WARNING: This version is still in early development stage; the resulting device-tree "blobs" have not yet been validated with the diff --git a/Documentation/s390/Debugging390.txt b/Documentation/s390/Debugging390.txt index 1eb576a..86f9f74 100644 --- a/Documentation/s390/Debugging390.txt +++ b/Documentation/s390/Debugging390.txt @@ -2531,5 +2531,5 @@ Special Thanks ============== Special thanks to Neale Ferguson who maintains a much prettier HTML version of this page at -http://penguinvm.princeton.edu/notes.html#Debug390 +http://linuxvm.org/penguinvm/ Bob Grainger Stefan Bader & others for reporting bugs diff --git a/Documentation/scsi/BusLogic.txt b/Documentation/scsi/BusLogic.txt index 98023ba..d7fbc94 100644 --- a/Documentation/scsi/BusLogic.txt +++ b/Documentation/scsi/BusLogic.txt @@ -47,7 +47,7 @@ tune driver performance and error recovery to their particular needs. The latest information on Linux support for BusLogic SCSI Host Adapters, as well as the most recent release of this driver and the latest firmware for the BT-948/958/958D, will always be available from my Linux Home Page at URL -"http://www.dandelion.com/Linux/". +"http://sourceforge.net/projects/dandelion/". Bug reports should be sent via electronic mail to "lnz@dandelion.com". Please include with the bug report the complete configuration messages reported by the diff --git a/Documentation/scsi/ChangeLog.megaraid b/Documentation/scsi/ChangeLog.megaraid index 38e9e7c..5e07d32 100644 --- a/Documentation/scsi/ChangeLog.megaraid +++ b/Documentation/scsi/ChangeLog.megaraid @@ -215,7 +215,7 @@ Older Version : 2.20.4.5 (scsi module), 2.20.2.5 (cmm module) 3. Convert pci_module_init to pci_register_driver Convert from pci_module_init to pci_register_driver - (from:http://kerneljanitors.org/TODO) + (from:http://kernelnewbies.org/KernelJanitors/TODO) - Signed-off-by: Domen Puncer 4. Use the pre defined DMA mask constants from dma-mapping.h diff --git a/Documentation/scsi/FlashPoint.txt b/Documentation/scsi/FlashPoint.txt index 1540a92..5b5f29c 100644 --- a/Documentation/scsi/FlashPoint.txt +++ b/Documentation/scsi/FlashPoint.txt @@ -13,7 +13,7 @@ operating system support to its BusLogic brand of FlashPoint Ultra SCSI host adapters. All of BusLogic's other SCSI host adapters, including the MultiMaster line, currently support the Linux operating system. Linux drivers and information will be available on October 15th at -http://www.dandelion.com/Linux/. +http://sourceforge.net/projects/dandelion/. "Mylex is committed to supporting the Linux community," says Peter Shambora, vice president of marketing for Mylex. "We have supported Linux driver @@ -27,7 +27,7 @@ Linux is a freely-distributed implementation of UNIX for Intel x86, Sun SPARC, SGI MIPS, Motorola 68k, Digital Alpha AXP and Motorola PowerPC machines. It supports a wide range of software, including the X Window System, Emacs, and TCP/IP networking. Further information is available at -http://www.linux.org and http://www.ssc.com/linux. +http://www.linux.org and http://www.ssc.com/. FlashPoint Host Adapters diff --git a/Documentation/scsi/Mylex.txt b/Documentation/scsi/Mylex.txt index cdf6929..3797f3e 100644 --- a/Documentation/scsi/Mylex.txt +++ b/Documentation/scsi/Mylex.txt @@ -2,4 +2,4 @@ Please see the file README.BusLogic for information about Linux support for Mylex (formerly BusLogic) MultiMaster and FlashPoint SCSI Host Adapters. The Mylex DAC960 PCI RAID Controllers are now supported. Please consult -http://www.dandelion.com/Linux/ for further information on the DAC960 driver. +http://sourceforge.net/projects/dandelion for further information on the DAC960 driver. diff --git a/Documentation/scsi/NinjaSCSI.txt b/Documentation/scsi/NinjaSCSI.txt index 3229b64..ac8db8c 100644 --- a/Documentation/scsi/NinjaSCSI.txt +++ b/Documentation/scsi/NinjaSCSI.txt @@ -3,8 +3,6 @@ 1. Comment This is Workbit corp.'s(http://www.workbit.co.jp/) NinjaSCSI-3 -(http://www.workbit.co.jp/ts/z_nj3r.html) and NinjaSCSI-32Bi -(http://www.workbit.co.jp/ts/z_njsc32bi.html) PCMCIA card driver module for Linux. 2. My Linux environment diff --git a/Documentation/scsi/aic79xx.txt b/Documentation/scsi/aic79xx.txt index c014ecc..16e054c 100644 --- a/Documentation/scsi/aic79xx.txt +++ b/Documentation/scsi/aic79xx.txt @@ -447,7 +447,7 @@ The following information is available in this file: http://www.adaptec.com/buy-cables/. Europe - - Visit our Web site at http://www.adaptec-europe.com/. + - Visit our Web site at http://www.adaptec.com/en-US/_common/world_index. - To speak with a Technical Support Specialist, call, or email, * German: +49 89 4366 5522, Monday-Friday, 9:00-17:00 CET, http://ask-de.adaptec.com/. diff --git a/Documentation/scsi/aic7xxx.txt b/Documentation/scsi/aic7xxx.txt index b7e238c..18f8d19 100644 --- a/Documentation/scsi/aic7xxx.txt +++ b/Documentation/scsi/aic7xxx.txt @@ -344,7 +344,7 @@ The following information is available in this file: http://www.adaptec.com/buy-cables/. Europe - - Visit our Web site at http://www.adaptec-europe.com/. + - Visit our Web site at http://www.adaptec.com/en-US/_common/world_index. - To speak with a Technical Support Specialist, call, or email, * German: +49 89 4366 5522, Monday-Friday, 9:00-17:00 CET, http://ask-de.adaptec.com/. diff --git a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt index 3920f28..45d61ad 100644 --- a/Documentation/scsi/ibmmca.txt +++ b/Documentation/scsi/ibmmca.txt @@ -1109,7 +1109,7 @@ Q: Where can I find the latest info about this driver? A: See the file MAINTAINERS for the current WWW-address, which offers updates, info and Q/A lists. At this file's origin, the webaddress - was: http://www.uni-mainz.de/~langm000/linux.html + was: http://www.staff.uni-mainz.de/mlang/linux.html Q: My SCSI-adapter is not recognized by the driver, what can I do? A: Just force it to be recognized by kernel parameters. See section 5.1. If this really happens, do also send e-mail to the maintainer, as diff --git a/Documentation/scsi/osst.txt b/Documentation/scsi/osst.txt index 2b21890..ad86c6d 100644 --- a/Documentation/scsi/osst.txt +++ b/Documentation/scsi/osst.txt @@ -135,7 +135,7 @@ The driver development is coordinated through a mailing list a CVS repository and some web pages. The tester's pages which contain recent news and updated drivers to download can be found on -http://linux1.onstream.nl/test/ +http://sourceforge.net/projects/osst/ If you find any problems, please have a look at the tester's page in order to see whether the problem is already known and solved. Otherwise, please diff --git a/Documentation/scsi/ppa.txt b/Documentation/scsi/ppa.txt index 067ac39..05ff47d 100644 --- a/Documentation/scsi/ppa.txt +++ b/Documentation/scsi/ppa.txt @@ -1,13 +1,13 @@ -------- Terse where to get ZIP Drive help info -------- General Iomega ZIP drive page for Linux: -http://www.torque.net/~campbell/ +http://web.archive.org/web/*/http://www.torque.net/~campbell/ Driver archive for old drivers: -http://www.torque.net/~campbell/ppa/ +http://web.archive.org/web/*/http://www.torque.net/~campbell/ppa Linux Parport page (parallel port) -http://www.torque.net/parport/ +http://web.archive.org/web/*/http://www.torque.net/parport/ Email list for Linux Parport linux-parport@torque.net diff --git a/Documentation/scsi/scsi-generic.txt b/Documentation/scsi/scsi-generic.txt index c38e2b3..0a22ab8 100644 --- a/Documentation/scsi/scsi-generic.txt +++ b/Documentation/scsi/scsi-generic.txt @@ -34,11 +34,11 @@ http://www.tldp.org/HOWTO/SCSI-Generic-HOWTO This describes the sg version 3 driver found in the lk 2.4 series. The LDP renders documents in single and multiple page HTML, postscript and pdf. This document can also be found at: -http://www.torque.net/sg/p/sg_v3_ho.html +http://sg.danny.cz/sg/p/sg_v3_ho.html Documentation for the version 2 sg driver found in the lk 2.2 series can -be found at http://www.torque.net/sg/p/scsi-generic.txt . A larger version -is at: http://www.torque.net/sg/p/scsi-generic_long.txt . +be found at http://sg.danny.cz/sg/. A larger version +is at: http://sg.danny.cz/sg/p/scsi-generic_long.txt. The original documentation for the sg driver (prior to lk 2.2.6) can be found at http://www.torque.net/sg/p/original/SCSI-Programming-HOWTO.txt @@ -61,7 +61,7 @@ There are two packages of sg utilities: - sg_utils for the sg version 2 (and original) driver found in lk 2.2 and earlier Both packages will work in the lk 2.4 series however sg3_utils offers more -capabilities. They can be found at: http://www.torque.net/sg and +capabilities. They can be found at: http://sg.danny.cz/sg/sg3_utils.html and freshmeat.net Another approach is to look at the applications that use the sg driver. diff --git a/Documentation/scsi/scsi.txt b/Documentation/scsi/scsi.txt index dd1bbf4..3d99d38 100644 --- a/Documentation/scsi/scsi.txt +++ b/Documentation/scsi/scsi.txt @@ -4,8 +4,8 @@ The Linux Documentation Project (LDP) maintains a document describing the SCSI subsystem in the Linux kernel (lk) 2.4 series. See: http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO . The LDP has single and multiple page HTML renderings as well as postscript and pdf. -It can also be found at http://www.torque.net/scsi/SCSI-2.4-HOWTO . - +It can also be found at: +http://web.archive.org/web/*/http://www.torque.net/scsi/SCSI-2.4-HOWTO Notes on using modules in the SCSI subsystem ============================================ diff --git a/Documentation/scsi/scsi_mid_low_api.txt b/Documentation/scsi/scsi_mid_low_api.txt index de67229..570ef2b 100644 --- a/Documentation/scsi/scsi_mid_low_api.txt +++ b/Documentation/scsi/scsi_mid_low_api.txt @@ -43,7 +43,7 @@ There is a SCSI documentation directory within the kernel source tree, typically Documentation/scsi . Most documents are in plain (i.e. ASCII) text. This file is named scsi_mid_low_api.txt and can be found in that directory. A more recent copy of this document may be found -at http://www.torque.net/scsi/scsi_mid_low_api.txt.gz . +at http://web.archive.org/web/20070107183357rn_1/sg.torque.net/scsi/. Many LLDs are documented there (e.g. aic7xxx.txt). The SCSI mid-level is briefly described in scsi.txt which contains a url to a document describing the SCSI subsystem in the lk 2.4 series. Two upper level diff --git a/Documentation/serial/moxa-smartio b/Documentation/serial/moxa-smartio index 5337e80..d104439 100644 --- a/Documentation/serial/moxa-smartio +++ b/Documentation/serial/moxa-smartio @@ -76,7 +76,7 @@ Content GNU General Public License in this version. Please refer to GNU General Public License announcement in each source code file for more detail. - In Moxa's Web sites, you may always find latest driver at http://web.moxa.com. + In Moxa's Web sites, you may always find latest driver at http://www.moxa.com/. This version of driver can be installed as Loadable Module (Module driver) or built-in into kernel (Static driver). You may refer to following diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 2075bbb..7f4dceb 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -1285,7 +1285,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. about this driver. Note that it has been discontinued, but the Voyetra Turtle Beach knowledge base entry for it is still available at - http://www.turtlebeach.com/site/kb_ftp/790.asp + http://www.turtlebeach.com Module snd-msnd-pinnacle ------------------------ diff --git a/Documentation/sound/alsa/HD-Audio.txt b/Documentation/sound/alsa/HD-Audio.txt index bdafdbd..278cc21 100644 --- a/Documentation/sound/alsa/HD-Audio.txt +++ b/Documentation/sound/alsa/HD-Audio.txt @@ -562,7 +562,7 @@ compare the codec registers directly. Send a bug report either the followings: kernel-bugzilla:: - http://bugme.linux-foundation.org/ + https://bugzilla.kernel.org/ alsa-devel ML:: alsa-devel@alsa-project.org diff --git a/Documentation/sound/alsa/soc/DAI.txt b/Documentation/sound/alsa/soc/DAI.txt index 0ebd7ea..c967926 100644 --- a/Documentation/sound/alsa/soc/DAI.txt +++ b/Documentation/sound/alsa/soc/DAI.txt @@ -13,7 +13,7 @@ frame (FRAME) (usually 48kHz) is always driven by the controller. Each AC97 frame is 21uS long and is divided into 13 time slots. The AC97 specification can be found at :- -http://www.intel.com/design/chipsets/audio/ac97_r23.pdf +http://www.intel.com/p/en_US/business/design I2S diff --git a/Documentation/sound/alsa/soc/codec.txt b/Documentation/sound/alsa/soc/codec.txt index 1e95342..37ba3a7 100644 --- a/Documentation/sound/alsa/soc/codec.txt +++ b/Documentation/sound/alsa/soc/codec.txt @@ -143,7 +143,7 @@ struct snd_soc_ops { }; Please refer to the ALSA driver PCM documentation for details. -http://www.alsa-project.org/~iwai/writing-an-alsa-driver/c436.htm +http://www.alsa-project.org/~iwai/writing-an-alsa-driver/ 5 - DAPM description. diff --git a/Documentation/sound/alsa/soc/platform.txt b/Documentation/sound/alsa/soc/platform.txt index b681d17..06d8359 100644 --- a/Documentation/sound/alsa/soc/platform.txt +++ b/Documentation/sound/alsa/soc/platform.txt @@ -39,7 +39,7 @@ struct snd_soc_platform { }; Please refer to the ALSA driver documentation for details of audio DMA. -http://www.alsa-project.org/~iwai/writing-an-alsa-driver/c436.htm +http://www.alsa-project.org/~iwai/writing-an-alsa-driver/ An example DMA driver is soc/pxa/pxa2xx-pcm.c diff --git a/Documentation/sound/oss/README.OSS b/Documentation/sound/oss/README.OSS index fd42b05..c615deb 100644 --- a/Documentation/sound/oss/README.OSS +++ b/Documentation/sound/oss/README.OSS @@ -36,7 +36,7 @@ with OSS API. Packages "snd-util-3.8.tar.gz" and "snd-data-0.1.tar.Z" contain useful utilities to be used with this driver. -See http://www.opensound.com/ossfree/getting.html for +See http://www.opensound.com/ossfree/ for download instructions. If you are looking for the installation instructions, please @@ -1438,7 +1438,7 @@ of this driver (see http://www.4Front-tech.com/oss.html for more info). There are some common audio chipsets that are not supported yet. For example Sierra Aria and IBM Mwave. It's possible that these architectures get some support in future but I can't make any promises. Just look -at the home page (http://www.opensound.com/ossfree/new_cards.html) +at the home page (http://www.opensound.com/ossfree/) for latest info. Information about unsupported sound cards and chipsets is welcome as well @@ -1449,7 +1449,6 @@ If you have any corrections and/or comments, please contact me. Hannu Savolainen hannu@opensound.com -Personal home page: http://www.compusonic.fi/~hannu home page of OSS/Free: http://www.opensound.com/ossfree home page of commercial OSS diff --git a/Documentation/telephony/ixj.txt b/Documentation/telephony/ixj.txt index 44d12400..4fb314d 100644 --- a/Documentation/telephony/ixj.txt +++ b/Documentation/telephony/ixj.txt @@ -108,14 +108,9 @@ applications. 1.4 Where to get things -You can download the latest versions of the driver from: - -http://www.quicknet.net/develop.htm - -You can download the latest version of this document from: - -http://www.quicknet.net/develop.htm +Info on latest versions of the driver are here: +http://web.archive.org/web/*/http://www.quicknet.net/develop.htm 1.5 Mailing List diff --git a/Documentation/uml/UserModeLinux-HOWTO.txt b/Documentation/uml/UserModeLinux-HOWTO.txt index 628013f..9b7e190 100644 --- a/Documentation/uml/UserModeLinux-HOWTO.txt +++ b/Documentation/uml/UserModeLinux-HOWTO.txt @@ -8,62 +8,6 @@ Table of Contents - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1. Introduction 1.1 How is User Mode Linux Different? @@ -277,8 +221,7 @@ 1. Download the latest UML patch from - the download page + the download page know, and + know, and they'll be "taken care of". @@ -498,8 +441,8 @@ You will need a filesystem to boot UML from. There are a number available for download from here . There are also several tools - which can be + linux.sourceforge.net/> . There are also several tools + which can be used to generate UML-compatible filesystem images from media. The kernel will boot up and present you with a login prompt. @@ -1236,7 +1179,7 @@ Harald's original README is here and explains these in detail, as well as + forge.net/> and explains these in detail, as well as some other issues. @@ -1311,7 +1254,7 @@ kernel. These were pointed out by Tim Robinson in - name="this uml- + name="this uml- user post"> . @@ -2038,7 +1981,7 @@ uml_moo is installed with the UML deb and RPM. If you didn't install UML from one of those packages, you can also get it from the UML - utilities tar file in tools/moo. @@ -4599,7 +4542,7 @@ Michael Jennings sent in some material which is now gracing the top of the index page of this site. + linux.sourceforge.net/> of this site. SGI (and more specifically Ralf Baechle ) gave me an account on oss.sgi.com diff --git a/Documentation/usb/linux.inf b/Documentation/usb/linux.inf index 2f7217d..af71d87 100644 --- a/Documentation/usb/linux.inf +++ b/Documentation/usb/linux.inf @@ -9,7 +9,7 @@ ; ; Microsoft only directly supports RNDIS drivers, and bundled them into XP. ; The Microsoft "Remote NDIS USB Driver Kit" is currently found at: -; http://www.microsoft.com/whdc/hwdev/resources/HWservices/rndis.mspx +; http://www.microsoft.com/whdc/device/network/ndis/rmndis.mspx [Version] diff --git a/Documentation/usb/mtouchusb.txt b/Documentation/usb/mtouchusb.txt index e43cfff..86302cd 100644 --- a/Documentation/usb/mtouchusb.txt +++ b/Documentation/usb/mtouchusb.txt @@ -54,10 +54,6 @@ generic functions like calibrations, resets, and vendor information can be requested from the userspace (And the drivers would handle the vendor specific tasks). -ADDITIONAL INFORMATION/UPDATES/X CONFIGURATION EXAMPLE: - -http://groomlakelabs.com/grandamp/code/microtouch/ - TODO: Implement a control urb again to handle requests to and from the device @@ -68,7 +64,7 @@ DISCLAIMER: I am not a MicroTouch/3M employee, nor have I ever been. 3M does not support this driver! If you want touch drivers only supported within X, please go to: -http://www.3m.com/3MTouchSystems/downloads/ +http://www.3m.com/3MTouchSystems/ THANKS: diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt index f4d2145..5bd7926 100644 --- a/Documentation/usb/usb-serial.txt +++ b/Documentation/usb/usb-serial.txt @@ -83,7 +83,7 @@ HandSpring Visor, Palm USB, and Clié USB driver parameters. e.g. modprobe visor vendor=0x54c product=0x66 There is a webpage and mailing lists for this portion of the driver at: - http://usbvisor.sourceforge.net/ + http://sourceforge.net/projects/usbvisor/ For any questions or problems with this driver, please contact Greg Kroah-Hartman at greg@kroah.com @@ -184,7 +184,7 @@ Keyspan USA-series Serial Adapters functionality. More information is available at: - http://misc.nu/hugh/keyspan.html + http://www.carnationsoftware.com/carnation/Keyspan.html For any questions or problems with this driver, please contact Hugh Blemings at hugh@misc.nu diff --git a/Documentation/video4linux/API.html b/Documentation/video4linux/API.html index d749d41..d72fd2a 100644 --- a/Documentation/video4linux/API.html +++ b/Documentation/video4linux/API.html @@ -17,7 +17,7 @@ - V4L2 API + V4L2 API Should be used for new projects diff --git a/Documentation/video4linux/CQcam.txt b/Documentation/video4linux/CQcam.txt index d230878e..8977e7c 100644 --- a/Documentation/video4linux/CQcam.txt +++ b/Documentation/video4linux/CQcam.txt @@ -203,11 +203,11 @@ The V4L2 API spec: http://v4l2spec.bytesex.org/ Some web pages about the quickcams: - http://www.dkfz-heidelberg.de/Macromol/wedemann/mini-HOWTO-cqcam.html + http://www.pingouin-land.com/howto/QuickCam-HOWTO.html http://www.crynwr.com/qcpc/ QuickCam Third-Party Drivers http://www.crynwr.com/qcpc/re.html Some Reverse Engineering - http://cse.unl.edu/~cluening/gqcam/ v4l client + http://www.wirelesscouch.net/software/gqcam/ v4l client http://phobos.illtel.denver.co.us/pub/qcread/ doesn't use v4l ftp://ftp.cs.unm.edu/pub/chris/quickcam/ Has lots of drivers http://www.cs.duke.edu/~reynolds/quickcam/ Has lots of information diff --git a/Documentation/video4linux/README.cpia b/Documentation/video4linux/README.cpia index 19cd3bf..8a747fe 100644 --- a/Documentation/video4linux/README.cpia +++ b/Documentation/video4linux/README.cpia @@ -185,7 +185,7 @@ THANKS (in no particular order): --------------------------------------------------------------------------- REFERENCES - 1. http://www.risc.uni-linz.ac.at/people/ppregler + 1. http://www.risc.uni-linz.ac.at/ mailto:Peter_Pregler@email.com 2. see the file COPYING in the top directory of the kernel tree 3. http://webcam.sourceforge.net/ diff --git a/Documentation/video4linux/README.ivtv b/Documentation/video4linux/README.ivtv index 73df22c..42b0668 100644 --- a/Documentation/video4linux/README.ivtv +++ b/Documentation/video4linux/README.ivtv @@ -10,7 +10,7 @@ Hauppauge PVR-350. NOTE: this driver requires the latest encoder firmware (version 2.06.039, size 376836 bytes). Get the firmware from here: -http://dl.ivtvdriver.org/ivtv/firmware/firmware.tar.gz +http://dl.ivtvdriver.org/ivtv/firmware/ NOTE: 'normal' TV applications do not work with this driver, you need an application that can handle MPEG input such as mplayer, xine, MythTV, diff --git a/Documentation/video4linux/Zoran b/Documentation/video4linux/Zoran index 0e89e76..00e3f92 100644 --- a/Documentation/video4linux/Zoran +++ b/Documentation/video4linux/Zoran @@ -174,7 +174,7 @@ and is used in Argentinia, Uruguay, an a few others We do not talk about how the audio is broadcast ! A rather good sites about the TV standards are: -http://www.sony.jp/ServiceArea/Voltage_map/ +http://www.sony.jp/support/ http://info.electronicwerkstatt.de/bereiche/fernsehtechnik/frequenzen_und_normen/Fernsehnormen/ and http://www.cabl.com/restaurant/channel.html @@ -330,7 +330,7 @@ These extensions are known as the v4l/mjpeg extensions. See zoran.h for details (structs/ioctls). Information - video4linux: -http://roadrunner.swansea.linux.org.uk/v4lapi.shtml +http://linux.bytesex.org/v4l2/API.html Documentation/video4linux/API.html /usr/include/linux/videodev.h @@ -390,7 +390,7 @@ BUZIOC_G_STATUS Get the status of the input lines (video source connected/norm). For programming example, please, look at lavrec.c and lavplay.c code in -lavtools-1.2p2 package (URL: http://www.cicese.mx/~mirsev/DC10plus/) +lavtools-1.2p2 package (URL: http://www.cicese.mx/) and the 'examples' directory in the original Buz driver distribution. Additional notes for software developers: diff --git a/Documentation/video4linux/bttv/Cards b/Documentation/video4linux/bttv/Cards index d338965..12217fc 100644 --- a/Documentation/video4linux/bttv/Cards +++ b/Documentation/video4linux/bttv/Cards @@ -802,7 +802,7 @@ Kworld (www.kworld.com.tw) -JTT/ Justy Corp.http://www.justy.co.jp/ (www.jtt.com.jp website down) +JTT/ Justy Corp.(http://www.jtt.ne.jp/) --------------------------------------------------------------------- JTT-02 (JTT TV) "TV watchmate pro" (bt848) @@ -828,7 +828,7 @@ Eline www.eline-net.com/ Eline Vision TVMaster / TVMaster FM (ELV-TVM/ ELV-TVM-FM) = LR26 (bt878) Eline Vision TVMaster-2000 (ELV-TVM-2000, ELV-TVM-2000-FM)= LR138 (saa713x) -Spirit http://www.spiritmodems.com.au/ +Spirit ------ Spirit TV Tuner/Video Capture Card (bt848) @@ -959,6 +959,6 @@ Asus www.asuscom.com Hoontech -------- -http://www.hoontech.com/korean/download/down_driver_list03.html +http://www.hoontech.de/ HART Vision 848 (H-ART Vision 848) HART Vision 878 (H-Art Vision 878) diff --git a/Documentation/video4linux/bttv/MAKEDEV b/Documentation/video4linux/bttv/MAKEDEV index 6c29ba4..9d112f7 100644 --- a/Documentation/video4linux/bttv/MAKEDEV +++ b/Documentation/video4linux/bttv/MAKEDEV @@ -14,7 +14,7 @@ function makedev () { ln -s /dev/${1}0 /dev/$1 } -# see http://roadrunner.swansea.uk.linux.org/v4lapi.shtml +# see http://linux.bytesex.org/v4l2/API.html echo "*** new device names ***" makedev video 0 diff --git a/Documentation/video4linux/bttv/Specs b/Documentation/video4linux/bttv/Specs index 79b9e57..f32466c 100644 --- a/Documentation/video4linux/bttv/Specs +++ b/Documentation/video4linux/bttv/Specs @@ -1,3 +1,3 @@ Philips http://www.Semiconductors.COM/pip/ -Conexant http://www.conexant.com/techinfo/default.asp -Micronas http://www.micronas.de/pages/product_documentation/index.html +Conexant http://www.conexant.com/ +Micronas http://www.micronas.com/en/home/index.html diff --git a/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt b/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt index faccee6..f4329a3 100644 --- a/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt +++ b/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt @@ -44,7 +44,7 @@ http://www.atmel.com/dyn/resources/prod_documents/doc2817.pdf This data sheet (google search) seems to have a lovely description of the RC5 basics -http://users.pandora.be/nenya/electronics/rc5/ and more data +http://www.nenya.be/beor/electronics/rc5.htm and more data http://www.ee.washington.edu/circuit_archive/text/ir_decode.txt and even a reference to how to decode a bi-phase data stream. diff --git a/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt b/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt index faccee6..a2fd363 100644 --- a/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt +++ b/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt @@ -44,7 +44,7 @@ http://www.atmel.com/dyn/resources/prod_documents/doc2817.pdf This data sheet (google search) seems to have a lovely description of the RC5 basics -http://users.pandora.be/nenya/electronics/rc5/ and more data +http://www.nenya.be/beor/electronics/rc5.htm and more data http://www.ee.washington.edu/circuit_archive/text/ir_decode.txt and even a reference to how to decode a bi-phase data stream. diff --git a/Documentation/video4linux/ibmcam.txt b/Documentation/video4linux/ibmcam.txt index 397a94e..a5105521 100644 --- a/Documentation/video4linux/ibmcam.txt +++ b/Documentation/video4linux/ibmcam.txt @@ -27,9 +27,8 @@ SUPPORTED CAMERAS: Xirlink "C-It" camera, also known as "IBM PC Camera". The device uses proprietary ASIC (and compression method); -it is manufactured by Xirlink. See http://www.xirlink.com/ -(renamed to http://www.veo.com), http://www.ibmpccamera.com, -or http://www.c-itnow.com/ for details and pictures. +it is manufactured by Xirlink. See http://xirlinkwebcam.sourceforge.net, +http://www.ibmpccamera.com, or http://www.c-itnow.com/ for details and pictures. This very chipset ("X Chip", as marked at the factory) is used in several other cameras, and they are supported diff --git a/Documentation/video4linux/se401.txt b/Documentation/video4linux/se401.txt index 7b9d1c9..bd6526e 100644 --- a/Documentation/video4linux/se401.txt +++ b/Documentation/video4linux/se401.txt @@ -49,6 +49,6 @@ order to increase the throughput (and thus framerate). HELP: The latest info on this driver can be found at: -http://www.chello.nl/~j.vreeken/se401/ +http://members.chello.nl/~j.vreeken/se401/ And questions to me can be send to: pe1rxq@amsat.org diff --git a/Documentation/video4linux/w9966.txt b/Documentation/video4linux/w9966.txt index 78a6512..8550245 100644 --- a/Documentation/video4linux/w9966.txt +++ b/Documentation/video4linux/w9966.txt @@ -24,7 +24,7 @@ where every two pixels take 4 bytes. In SDL (www.libsdl.org) this format is called VIDEO_PALETTE_YUV422 (16 bpp). A minimal test application (with source) is available from: - http://hem.fyristorg.com/mogul/w9966.html + http://www.slackwaresupport.com/howtos/Webcam-HOWTO The slow framerate is due to missing DMA ECP read support in the parport drivers. I might add working EPP support later. diff --git a/Documentation/w1/masters/ds2482 b/Documentation/w1/masters/ds2482 index 299b91c..56f8eda 100644 --- a/Documentation/w1/masters/ds2482 +++ b/Documentation/w1/masters/ds2482 @@ -6,8 +6,8 @@ Supported chips: Prefix: 'ds2482' Addresses scanned: None Datasheets: - http://pdfserv.maxim-ic.com/en/ds/DS2482-100-DS2482S-100.pdf - http://pdfserv.maxim-ic.com/en/ds/DS2482-800-DS2482S-800.pdf + http://datasheets.maxim-ic.com/en/ds/DS2482-100.pdf + http://datasheets.maxim-ic.com/en/ds/DS2482-800.pdf Author: Ben Gardner diff --git a/Documentation/w1/masters/mxc-w1 b/Documentation/w1/masters/mxc-w1 index 97f6199..38be1ad 100644 --- a/Documentation/w1/masters/mxc-w1 +++ b/Documentation/w1/masters/mxc-w1 @@ -5,7 +5,8 @@ Supported chips: * Freescale MX27, MX31 and probably other i.MX SoCs Datasheets: http://www.freescale.com/files/32bit/doc/data_sheet/MCIMX31.pdf?fpsp=1 - http://www.freescale.com/files/dsp/MCIMX27.pdf?fpsp=1 + http://cache.freescale.com/files/dsp/doc/archive/MCIMX27.pdf?fsrch=1&WT_TYPE= + Data%20Sheets&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation Author: Originally based on Freescale code, prepared for mainline by Sascha Hauer diff --git a/Documentation/w1/masters/omap-hdq b/Documentation/w1/masters/omap-hdq index ca722e0..884dc28 100644 --- a/Documentation/w1/masters/omap-hdq +++ b/Documentation/w1/masters/omap-hdq @@ -7,7 +7,7 @@ Supported chips: A useful link about HDQ basics: =============================== -http://focus.ti.com/lit/an/slua408/slua408.pdf +http://focus.ti.com/lit/an/slua408a/slua408a.pdf Description: ============ diff --git a/Documentation/zh_CN/HOWTO b/Documentation/zh_CN/HOWTO index 3d80e8a..6916077 100644 --- a/Documentation/zh_CN/HOWTO +++ b/Documentation/zh_CN/HOWTO @@ -112,7 +112,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与 其他关于如何正确地生成补丁的优秀文档包括： "The Perfect Patch" - http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt + http://userweb.kernel.org/~akpm/stuff/tpp.txt "Linux kernel patch submission format" http://linux.yyz.us/patch-format.html @@ -168,7 +168,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与 如果你想加入内核开发社区并协助完成一些任务，却找不到从哪里开始，可以访问 “Linux内核房管员”计划： - http://janitor.kernelnewbies.org/ + http://kernelnewbies.org/KernelJanitors 这是极佳的起点。它提供一个相对简单的任务列表，列出内核代码中需要被重新 整理或者改正的地方。通过和负责这个计划的开发者们一同工作，你会学到将补丁 集成进内核的基本原理。如果还没有决定下一步要做什么的话，你还可能会得到方 @@ -515,7 +515,7 @@ Linux内核社区并不喜欢一下接收大段的代码。修改需要被恰当 想了解它具体应该看起来像什么，请查阅以下文档中的“ChangeLog”章节： “The Perfect Patch” - http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt + http://userweb.kernel.org/~akpm/stuff/tpp.txt 这些事情有时候做起来很难。要在任何方面都做到完美可能需要好几年时间。这是 @@ -525,7 +525,7 @@ Linux内核社区并不喜欢一下接收大段的代码。修改需要被恰当 --------------- 感谢Paolo Ciarrocchi允许“开发流程”部分基于他所写的文章 -(http://linux.tar.bz/articles/2.6-development_process)，感谢Randy +(http://www.kerneltravel.net/newbie/2.6-development_process)，感谢Randy Dunlap和Gerrit Huizenga完善了应该说和不该说的列表。感谢Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers, Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi Kleen, Vadim Lobanov, Jesper Juhl, Adrian diff --git a/Documentation/zh_CN/SubmittingDrivers b/Documentation/zh_CN/SubmittingDrivers index 5f4815c..c27b0f6 100644 --- a/Documentation/zh_CN/SubmittingDrivers +++ b/Documentation/zh_CN/SubmittingDrivers @@ -165,4 +165,4 @@ Linux USB项目： http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf 内核清洁工 (Kernel Janitor): - http://janitor.kernelnewbies.org/ + http://kernelnewbies.org/KernelJanitors diff --git a/Documentation/zh_CN/SubmittingPatches b/Documentation/zh_CN/SubmittingPatches index 985c92e..9a1a6e1 100644 --- a/Documentation/zh_CN/SubmittingPatches +++ b/Documentation/zh_CN/SubmittingPatches @@ -83,7 +83,7 @@ Quilt: http://savannah.nongnu.org/projects/quilt Andrew Morton 的补丁脚本: -http://www.zip.com.au/~akpm/linux/patches/ +http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz 作为这些脚本的替代，quilt 是值得推荐的补丁管理工具(看上面的链接)。 2)描述你的改动。 @@ -166,7 +166,7 @@ MAITAINERS 文件里的）发送一个手册页（man-pages）补丁，或者至 人拷贝，只要它是琐碎的） 任何文件的作者/维护者对该文件的改动（例如 patch monkey 在重传模式下） -URL: +EMAIL: trivial@kernel.org (译注，关于“琐碎补丁”的一些说明：因为原文的这一部分写得比较简单，所以不得不 违例写一下译注。"trivial"这个英文单词的本意是“琐碎的，不重要的。”但是在这里 @@ -394,7 +394,7 @@ Static inline 函数相比宏来说，是好得多的选择。Static inline 函 ---------------- Andrew Morton, "The perfect patch" (tpp). - + Jeff Garzik, "Linux kernel patch submission format". -- cgit v1.1 From 9bb4d9dfd890372092338cc460b3f921c8be8e31 Mon Sep 17 00:00:00 2001 From: David Daney Date: Tue, 3 Aug 2010 11:22:22 -0700 Subject: Documentation: Mention that KProbes is supported on MIPS MIPS now has KProbes support, so kprobes.txt should reflect it. Signed-off-by: David Daney To: linux-mips@linux-mips.org To: ananth@in.ibm.com To: anil.s.keshavamurthy@intel.com To: davem@davemloft.net To: masami.hiramatsu.pt@hitachi.com Cc: linux-kernel@vger.kernel.org Cc: hschauhan@nulltrace.org Patchwork: https://patchwork.linux-mips.org/patch/1527/ Signed-off-by: Ralf Baechle --- Documentation/kprobes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt index 6653017..1762b81 100644 --- a/Documentation/kprobes.txt +++ b/Documentation/kprobes.txt @@ -285,6 +285,7 @@ architectures: - sparc64 (Return probes not yet implemented.) - arm - ppc +- mips 3. Configuring Kprobes -- cgit v1.1 From 6e57559022a2c6e3decfb77a228f8a354ac23ba1 Mon Sep 17 00:00:00 2001 From: Nick Piggin Date: Thu, 5 Aug 2010 21:08:09 +1000 Subject: nick piggin: change email address Signed-off-by: Nick Piggin Signed-off-by: Linus Torvalds --- Documentation/block/biodoc.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index 508b5b2..b9a83dd 100644 --- a/Documentation/block/biodoc.txt +++ b/Documentation/block/biodoc.txt @@ -7,7 +7,7 @@ Notes Written on Jan 15, 2002: Last Updated May 2, 2002 September 2003: Updated I/O Scheduler portions - Nick Piggin + Nick Piggin Introduction: -- cgit v1.1 From 65b5ac1479840a3e87f086d68e5ef91f3002e8e2 Mon Sep 17 00:00:00 2001 From: Jason Wessel Date: Thu, 5 Aug 2010 09:22:33 -0500 Subject: kgdb,docs: Update the kgdb docs to include kms Update the kgdb docs to include information about kernel mode setting support. [Randy Dunlap : grammatical corrections] CC: Randy Dunlap Signed-off-by: Jason Wessel --- Documentation/DocBook/kgdb.tmpl | 108 +++++++++++++++++++++++++++++++++--- Documentation/kernel-parameters.txt | 9 ++- 2 files changed, 106 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl index 55f12ac..490d862 100644 --- a/Documentation/DocBook/kgdb.tmpl +++ b/Documentation/DocBook/kgdb.tmpl @@ -199,10 +199,33 @@ may be configured as a kernel built-in or a kernel loadable module. You can only make use of kgdbwait and early debugging if you build kgdboc into the kernel as a built-in. + Optionally you can elect to activate kms (Kernel Mode + Setting) integration. When you use kms with kgdboc and you have a + video driver that has atomic mode setting hooks, it is possible to + enter the debugger on the graphics console. When the kernel + execution is resumed, the previous graphics mode will be restored. + This integration can serve as a useful tool to aid in diagnosing + crashes or doing analysis of memory with kdb while allowing the + full graphics console applications to run. + kgdboc arguments - Usage: kgdboc=[kbd][[,]serial_device][,baud] + Usage: kgdboc=[kms][[,]kbd][[,]serial_device][,baud] + The order listed above must be observed if you use any of the + optional configurations together. + + Abbreviations: + + kms = Kernel Mode Setting + kbd = Keyboard + + + You can configure kgdboc to use the keyboard, and or a serial + device depending on if you are using kdb and or kgdb, in one of the + following scenarios. The order listed above must be observed if + you use any of the optional configurations together. Using kms + + only gdb is generally not a useful combination. Using loadable module or built-in @@ -212,7 +235,7 @@ As a kernel loadable module: Use the command: modprobe kgdboc kgdboc=<tty-device>,[baud] - Here are two examples of how you might formate the kgdboc + Here are two examples of how you might format the kgdboc string. The first is for an x86 target using the first serial port. The second example is for the ARM Versatile AB using the second serial port. @@ -240,6 +263,9 @@ More examples + You can configure kgdboc to use the keyboard, and or a serial + device depending on if you are using kdb and or kgdb, in one of the + following scenarios. You can configure kgdboc to use the keyboard, and or a serial device depending on if you are using kdb and or kgdb, in one of the following scenarios. @@ -255,6 +281,12 @@ kdb with a keyboard kgdboc=kbd + kdb with kernel mode setting + kgdboc=kms,kbd + + kdb with kernel mode setting and kgdb over a serial port + kgdboc=kms,kbd,ttyS0,115200 + @@ -637,6 +669,8 @@ Task Addr Pid Parent [*] cpu State Thread Command The logic to perform safe memory reads and writes to memory while using the debugger A full implementation for software breakpoints unless overridden by the arch The API to invoke either the kdb or kgdb frontend to the debug core. + The structures and callback API for atomic kernel mode setting. + NOTE: kgdboc is where the kms callbacks are invoked. @@ -747,6 +781,8 @@ Task Addr Pid Parent [*] cpu State Thread Command kgdboc internals + + kgdboc and uarts The kgdboc driver is actually a very thin driver that relies on the underlying low level to the hardware driver having "polling hooks" @@ -754,11 +790,8 @@ Task Addr Pid Parent [*] cpu State Thread Command implementation of kgdboc it the serial_core was changed to expose a low level UART hook for doing polled mode reading and writing of a single character while in an atomic context. When kgdb makes an I/O - request to the debugger, kgdboc invokes a call back in the serial - core which in turn uses the call back in the UART driver. It is - certainly possible to extend kgdboc to work with non-UART based - consoles in the future. - + request to the debugger, kgdboc invokes a callback in the serial + core which in turn uses the callback in the UART driver. When using kgdboc with a UART, the UART driver must implement two callbacks in the struct uart_ops. Example from drivers/8250.c: #ifdef CONFIG_CONSOLE_POLL @@ -772,9 +805,68 @@ Task Addr Pid Parent [*] cpu State Thread Command that they can be called from an atomic context and have to restore the state of the UART chip on return such that the system can return to normal when the debugger detaches. You need to be very careful - with any kind of lock you consider, because failing here is most + with any kind of lock you consider, because failing here is most likely going to mean pressing the reset button. + + + kgdboc and keyboards + The kgdboc driver contains logic to configure communications + with an attached keyboard. The keyboard infrastructure is only + compiled into the kernel when CONFIG_KDB_KEYBOARD=y is set in the + kernel configuration. + The core polled keyboard driver driver for PS/2 type keyboards + is in drivers/char/kdb_keyboard.c. This driver is hooked into the + debug core when kgdboc populates the callback in the array + called kdb_poll_funcs[]. The + kdb_get_kbd_char() is the top-level function which polls hardware + for single character input. + + + + kgdboc and kms + The kgdboc driver contains logic to request the graphics + display to switch to a text context when you are using + "kgdboc=kms,kbd", provided that you have a video driver which has a + frame buffer console and atomic kernel mode setting support. + + Every time the kernel + debugger is entered it calls kgdboc_pre_exp_handler() which in turn + calls con_debug_enter() in the virtual console layer. On resuming kernel + execution, the kernel debugger calls kgdboc_post_exp_handler() which + in turn calls con_debug_leave(). + Any video driver that wants to be compatible with the kernel + debugger and the atomic kms callbacks must implement the + mode_set_base_atomic, fb_debug_enter and fb_debug_leave operations. + For the fb_debug_enter and fb_debug_leave the option exists to use + the generic drm fb helper functions or implement something custom for + the hardware. The following example shows the initialization of the + .mode_set_base_atomic operation in + drivers/gpu/drm/i915/intel_display.c: + + +static const struct drm_crtc_helper_funcs intel_helper_funcs = { +[...] + .mode_set_base_atomic = intel_pipe_set_base_atomic, +[...] +}; + + + + Here is an example of how the i915 driver initializes the fb_debug_enter and fb_debug_leave functions to use the generic drm helpers in + drivers/gpu/drm/i915/intel_fb.c: + + +static struct fb_ops intelfb_ops = { +[...] + .fb_debug_enter = drm_fb_helper_debug_enter, + .fb_debug_leave = drm_fb_helper_debug_leave, +[...] +}; + + + + diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 2b2407d..0e4f39f 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1143,9 +1143,12 @@ and is between 256 and 4096 characters. It is defined in the file kgdboc= [KGDB,HW] kgdb over consoles. Requires a tty driver that supports console polling, or a supported polling keyboard driver (non-usb). - Serial only format: [,baud] - keyboard only format: kbd - keyboard and serial format: kbd,[,baud] + Serial only format: [,baud] + keyboard only format: kbd + keyboard and serial format: kbd,[,baud] + Optional Kernel mode setting: + kms, kbd format: kms,kbd + kms, kbd and serial format: kms,kbd,[,baud] kgdbwait [KGDB] Stop kernel execution and enter the kernel debugger at the earliest opportunity. -- cgit v1.1 From 1a4240f4764ac78adbf4b0ebb49b3bd8c72ffa11 Mon Sep 17 00:00:00 2001 From: Wang Lei Date: Wed, 4 Aug 2010 15:16:33 +0100 Subject: DNS: Separate out CIFS DNS Resolver code Separate out the DNS resolver key type from the CIFS filesystem into its own module so that it can be made available for general use, including the AFS filesystem module. This facility makes it possible for the kernel to upcall to userspace to have it issue DNS requests, package up the replies and present them to the kernel in a useful form. The kernel is then able to cache the DNS replies as keys can be retained in keyrings. Resolver keys are of type "dns_resolver" and have a case-insensitive description that is of the form "[:]". The optional indicates the particular DNS lookup and packaging that's required. The is the query to be made. If isn't given, a basic hostname to IP address lookup is made, and the result is stored in the key in the form of a printable string consisting of a comma-separated list of IPv4 and IPv6 addresses. This key type is supported by userspace helpers driven from /sbin/request-key and configured through /etc/request-key.conf. The cifs.upcall utility is invoked for UNC path server name to IP address resolution. The CIFS functionality is encapsulated by the dns_resolve_unc_to_ip() function, which is used to resolve a UNC path to an IP address for CIFS filesystem. This part remains in the CIFS module for now. See the added Documentation/networking/dns_resolver.txt for more information. Signed-off-by: Wang Lei Signed-off-by: David Howells Acked-by: Jeff Layton Signed-off-by: Steve French --- Documentation/networking/dns_resolver.txt | 146 ++++++++++++++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 Documentation/networking/dns_resolver.txt (limited to 'Documentation') diff --git a/Documentation/networking/dns_resolver.txt b/Documentation/networking/dns_resolver.txt new file mode 100644 index 0000000..d8e0ce1 --- /dev/null +++ b/Documentation/networking/dns_resolver.txt @@ -0,0 +1,146 @@ + =================== + DNS Resolver Module + =================== + +Contents: + + - Overview. + - Compilation. + - Setting up. + - Usage. + - Mechanism. + - Debugging. + + +======== +OVERVIEW +======== + +The DNS resolver module provides a way for kernel services to make DNS queries +by way of requesting a key of key type dns_resolver. These queries are +upcalled to userspace through /sbin/request-key. + +These routines must be supported by userspace tools dns.upcall, cifs.upcall and +request-key. It is under development and does not yet provide the full feature +set. The features it does support include: + + (*) Implements the dns_resolver key_type to contact userspace. + +It does not yet support the following AFS features: + + (*) Dns query support for AFSDB resource record. + +This code is extracted from the CIFS filesystem. + + +=========== +COMPILATION +=========== + +The module should be enabled by turning on the kernel configuration options: + + CONFIG_DNS_RESOLVER - tristate "DNS Resolver support" + + +========== +SETTING UP +========== + +To set up this facility, the /etc/request-key.conf file must be altered so that +/sbin/request-key can appropriately direct the upcalls. For example, to handle +basic dname to IPv4/IPv6 address resolution, the following line should be +added: + + #OP TYPE DESC CO-INFO PROGRAM ARG1 ARG2 ARG3 ... + #====== ============ ======= ======= ========================== + create dns_resolver * * /usr/sbin/cifs.upcall %k + +To direct a query for query type 'foo', a line of the following should be added +before the more general line given above as the first match is the one taken. + + create dns_resolver foo:* * /usr/sbin/dns.foo %k + + + +===== +USAGE +===== + +To make use of this facility, one of the following functions that are +implemented in the module can be called after doing: + + #include + + (1) int dns_query(const char *type, const char *name, size_t namelen, + const char *options, char **_result, time_t *_expiry); + + This is the basic access function. It looks for a cached DNS query and if + it doesn't find it, it upcalls to userspace to make a new DNS query, which + may then be cached. The key description is constructed as a string of the + form: + + [:] + + where optionally specifies the particular upcall program to invoke, + and thus the type of query to do, and specifies the string to be + looked up. The default query type is a straight hostname to IP address + set lookup. + + The name parameter is not required to be a NUL-terminated string, and its + length should be given by the namelen argument. + + The options parameter may be NULL or it may be a set of options + appropriate to the query type. + + The return value is a string appropriate to the query type. For instance, + for the default query type it is just a list of comma-separated IPv4 and + IPv6 addresses. The caller must free the result. + + The length of the result string is returned on success, and a -ve error + code is returned otherwise. -EKEYREJECTED will be returned if the DNS + lookup failed. + + If _expiry is non-NULL, the expiry time (TTL) of the result will be + returned also. + + +========= +MECHANISM +========= + +The dnsresolver module registers a key type called "dns_resolver". Keys of +this type are used to transport and cache DNS lookup results from userspace. + +When dns_query() is invoked, it calls request_key() to search the local +keyrings for a cached DNS result. If that fails to find one, it upcalls to +userspace to get a new result. + +Upcalls to userspace are made through the request_key() upcall vector, and are +directed by means of configuration lines in /etc/request-key.conf that tell +/sbin/request-key what program to run to instantiate the key. + +The upcall handler program is responsible for querying the DNS, processing the +result into a form suitable for passing to the keyctl_instantiate_key() +routine. This then passes the data to dns_resolver_instantiate() which strips +off and processes any options included in the data, and then attaches the +remainder of the string to the key as its payload. + +The upcall handler program should set the expiry time on the key to that of the +lowest TTL of all the records it has extracted a result from. This means that +the key will be discarded and recreated when the data it holds has expired. + +dns_query() returns a copy of the value attached to the key, or an error if +that is indicated instead. + +See for further information about +request-key function. + + +========= +DEBUGGING +========= + +Debugging messages can be turned on dynamically by writing a 1 into the +following file: + + /sys/module/dnsresolver/parameters/debug -- cgit v1.1 From c7825cfac6f34e66797905f365761f66fd51ebda Mon Sep 17 00:00:00 2001 From: Tommi Rantala Date: Thu, 5 Aug 2010 11:23:11 -0700 Subject: Documentation/vm: fix spelling in page-types.c Trivial typo fixes. Signed-off-by: Tommi Rantala Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/vm/page-types.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/vm/page-types.c b/Documentation/vm/page-types.c index 66e9358..ccd951f 100644 --- a/Documentation/vm/page-types.c +++ b/Documentation/vm/page-types.c @@ -694,7 +694,7 @@ static void usage(void) #endif " -l|--list Show page details in ranges\n" " -L|--list-each Show page details one by one\n" -" -N|--no-summary Don't show summay info\n" +" -N|--no-summary Don't show summary info\n" " -X|--hwpoison hwpoison pages\n" " -x|--unpoison unpoison pages\n" " -h|--help Show this usage message\n" -- cgit v1.1 From 4f8272802739f5c6ce6b0a548810a181d2f1b652 Mon Sep 17 00:00:00 2001 From: Matt Mooney Date: Thu, 5 Aug 2010 11:23:11 -0700 Subject: Documentation: update kbuild loadable modules goals & examples Update section 3.3 Loadable module goals - obj-m, from $(-objs) to $(-y) for easier addition of conditional objects to the module. The examples are also updated to reflect the current state of each Makefile used. Signed-off-by: matt mooney Reviewed-by: WANG Cong Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/kbuild/makefiles.txt | 37 +++++++++++++++++++------------------ 1 file changed, 19 insertions(+), 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 71c602d..f29dca3 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -187,34 +187,35 @@ more details, with real examples. Note: In this example $(CONFIG_ISDN_PPP_BSDCOMP) evaluates to 'm' If a kernel module is built from several source files, you specify - that you want to build a module in the same way as above. - - Kbuild needs to know which the parts that you want to build your - module from, so you have to tell it by setting an - $(-objs) variable. + that you want to build a module in the same way as above; however, + kbuild needs to know which object files you want to build your + module from, so you have to tell it by setting a $(-y) + variable. Example: #drivers/isdn/i4l/Makefile - obj-$(CONFIG_ISDN) += isdn.o - isdn-objs := isdn_net_lib.o isdn_v110.o isdn_common.o + obj-$(CONFIG_ISDN_I4L) += isdn.o + isdn-y := isdn_net_lib.o isdn_v110.o isdn_common.o In this example, the module name will be isdn.o. Kbuild will - compile the objects listed in $(isdn-objs) and then run + compile the objects listed in $(isdn-y) and then run "$(LD) -r" on the list of these files to generate isdn.o. - Kbuild recognises objects used for composite objects by the suffix - -objs, and the suffix -y. This allows the Makefiles to use - the value of a CONFIG_ symbol to determine if an object is part - of a composite object. + Due to kbuild recognizing $(-y) for composite objects, + you can use the value of a CONFIG_ symbol to optionally include an + object file as part of a composite object. Example: #fs/ext2/Makefile - obj-$(CONFIG_EXT2_FS) += ext2.o - ext2-y := balloc.o bitmap.o - ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o - - In this example, xattr.o is only part of the composite object - ext2.o if $(CONFIG_EXT2_FS_XATTR) evaluates to 'y'. + obj-$(CONFIG_EXT2_FS) += ext2.o + ext2-y := balloc.o dir.o file.o ialloc.o inode.o ioctl.o \ + namei.o super.o symlink.o + ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o \ + xattr_trusted.o + + In this example, xattr.o, xattr_user.o and xattr_trusted.o are only + part of the composite object ext2.o if $(CONFIG_EXT2_FS_XATTR) + evaluates to 'y'. Note: Of course, when you are building objects into the kernel, the syntax above will also work. So, if you have CONFIG_EXT2_FS=y, -- cgit v1.1 From 2f5a2f81843ccef626c3db30aa19ed5abf8f0181 Mon Sep 17 00:00:00 2001 From: Matt Mooney Date: Thu, 5 Aug 2010 11:23:11 -0700 Subject: Documentation: update kbuild make examples#2 to reflect changes Update section 3.2 and 3.5 example, along with text in section 3.5 to reflect change. Signed-off-by: matt mooney Reviewed-by: WANG Cong Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/kbuild/makefiles.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index f29dca3..d77e24e 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -168,7 +168,7 @@ more details, with real examples. #drivers/isdn/i4l/Makefile # Makefile for the kernel ISDN subsystem and device drivers. # Each configuration option enables a list of files. - obj-$(CONFIG_ISDN) += isdn.o + obj-$(CONFIG_ISDN_I4L) += isdn.o obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o --- 3.3 Loadable module goals - obj-m @@ -245,12 +245,12 @@ more details, with real examples. may contain both a built-in.o and a lib.a file. Example: - #arch/i386/lib/Makefile - lib-y := checksum.o delay.o + #arch/x86/lib/Makefile + lib-y := delay.o - This will create a library lib.a based on checksum.o and delay.o. - For kbuild to actually recognize that there is a lib.a being built, - the directory shall be listed in libs-y. + This will create a library lib.a based on delay.o. For kbuild to + actually recognize that there is a lib.a being built, the directory + shall be listed in libs-y. See also "6.3 List directories to visit when descending". Use of lib-y is normally restricted to lib/ and arch/*/lib. -- cgit v1.1 From eb07e1b4ac544abaf4ec8ad25cdbe39485de6842 Mon Sep 17 00:00:00 2001 From: Matt Mooney Date: Thu, 5 Aug 2010 11:23:11 -0700 Subject: Documentation: update kbuild make typos/grammar/text flow Update section 3.7 examples to reflect the current state of the Makefiles used. Fix spelling and grammar errors along with flow of text. Signed-off-by: matt mooney Reviewed-by: WANG Cong Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/kbuild/makefiles.txt | 53 ++++++++++++++++++-------------------- 1 file changed, 25 insertions(+), 28 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index d77e24e..31bfcbf 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -285,45 +285,42 @@ more details, with real examples. --- 3.7 Compilation flags ccflags-y, asflags-y and ldflags-y - The three flags listed above applies only to the kbuild makefile - where they are assigned. They are used for all the normal - cc, as and ld invocation happenign during a recursive build. + The three flags listed above apply only to the kbuild makefile where + they are assigned (i.e., per-directory). They are used for all the + normal cc, as and ld invocation happening during a recursive build. Note: Flags with the same behaviour were previously named: - EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS. - They are yet supported but their use are deprecated. + EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS. They are still + supported but their use is deprecated. - ccflags-y specifies options for compiling C files with $(CC). + ccflags-y specifies options for compiling with $(CC). Example: - # drivers/sound/emu10k1/Makefile - ccflags-y += -I$(obj) - ccflags-$(DEBUG) += -DEMU10K1_DEBUG - + # drivers/acpi/Makefile + ccflags-y := -Os + ccflags-$(CONFIG_ACPI_DEBUG) += -DACPI_DEBUG_OUTPUT This variable is necessary because the top Makefile owns the variable $(KBUILD_CFLAGS) and uses it for compilation flags for the entire tree. - asflags-y is a similar string for per-directory options - when compiling assembly language source. + asflags-y specifies options for assembling with $(AS). Example: - #arch/x86_64/kernel/Makefile - asflags-y := -traditional - + #arch/sparc/kernel/Makefile + asflags-y := -ansi - ldflags-y is a string for per-directory options to $(LD). + ldflags-y specifies options for linking with $(LD). Example: - #arch/m68k/fpsp040/Makefile - ldflags-y := -x + #arch/cris/boot/compressed/Makefile + ldflags-y += -T $(srctree)/$(src)/decompress_$(arch-y).lds subdir-ccflags-y, subdir-asflags-y - The two flags listed above are similar to ccflags-y and as-falgs-y. - The difference is that the subdir- variants has effect for the kbuild - file where tey are present and all subdirectories. - Options specified using subdir-* are added to the commandline before - the options specified using the non-subdir variants. + The two flags listed above are similar to ccflags-y and asflags-y. + The difference is that the subdir- variants affect the kbuild + file where they are present and all subdirectories. Options specified + using subdir-* are added to the commandline before the options + specified using the non-subdir variants. Example: subdir-ccflags-y := -Werror @@ -341,18 +338,18 @@ more details, with real examples. CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF CFLAGS_gdth.o = # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ \ -DGDTH_STATISTICS - CFLAGS_seagate.o = -DARBITRATE -DPARITY -DSEAGATE_USE_ASM - These three lines specify compilation flags for aha152x.o, - gdth.o, and seagate.o + These two lines specify compilation flags for aha152x.o and gdth.o. $(AFLAGS_$@) is a similar feature for source files in assembly languages. Example: # arch/arm/kernel/Makefile - AFLAGS_head-armv.o := -DTEXTADDR=$(TEXTADDR) -traditional - AFLAGS_head-armo.o := -DTEXTADDR=$(TEXTADDR) -traditional + AFLAGS_head.o := -DTEXT_OFFSET=$(TEXT_OFFSET) + AFLAGS_crunch-bits.o := -Wa,-mcpu=ep9312 + AFLAGS_iwmmxt.o := -Wa,-mcpu=iwmmxt + --- 3.9 Dependency tracking -- cgit v1.1 From c95940f264e59ff8d21d76ace47bac1018912800 Mon Sep 17 00:00:00 2001 From: Nicolas Kaiser Date: Thu, 5 Aug 2010 11:23:11 -0700 Subject: Documentation: fix kbuild typos and wording Fixed some typos and wording. Signed-off-by: Nicolas Kaiser Signed-off-by: Linus Torvalds --- Documentation/kbuild/kbuild.txt | 8 ++++---- Documentation/kbuild/makefiles.txt | 24 ++++++++++++------------ 2 files changed, 16 insertions(+), 16 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt index 634c625..0d8addb 100644 --- a/Documentation/kbuild/kbuild.txt +++ b/Documentation/kbuild/kbuild.txt @@ -40,15 +40,15 @@ Set the directory to look for the kernel source when building external modules. The directory can be specified in several ways: 1) Use "M=..." on the command line -2) Environmnet variable KBUILD_EXTMOD -3) Environmnet variable SUBDIRS +2) Environment variable KBUILD_EXTMOD +3) Environment variable SUBDIRS The possibilities are listed in the order they take precedence. Using "M=..." will always override the others. KBUILD_OUTPUT -------------------------------------------------- Specify the output directory when building the kernel. -The output directory can also be specificed using "O=...". +The output directory can also be specified using "O=...". Setting "O=..." takes precedence over KBUILD_OUTPUT. ARCH @@ -90,7 +90,7 @@ The script will be called with the following arguments: $3 - kernel map file $4 - default install path (use root directory if blank) -The implmentation of "make install" is architecture specific +The implementation of "make install" is architecture specific and it may differ from the above. INSTALLKERNEL is provided to enable the possibility to diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 31bfcbf..8abd041 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -285,12 +285,12 @@ more details, with real examples. --- 3.7 Compilation flags ccflags-y, asflags-y and ldflags-y - The three flags listed above apply only to the kbuild makefile where - they are assigned (i.e., per-directory). They are used for all the - normal cc, as and ld invocation happening during a recursive build. + These three flags apply only to the kbuild makefile in which they + are assigned. They are used for all the normal cc, as and ld + invocations happening during a recursive build. Note: Flags with the same behaviour were previously named: - EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS. They are still - supported but their use is deprecated. + EXTRA_CFLAGS, EXTRA_AFLAGS and EXTRA_LDFLAGS. + They are still supported but their usage is deprecated. ccflags-y specifies options for compiling with $(CC). @@ -317,10 +317,10 @@ more details, with real examples. subdir-ccflags-y, subdir-asflags-y The two flags listed above are similar to ccflags-y and asflags-y. - The difference is that the subdir- variants affect the kbuild - file where they are present and all subdirectories. Options specified - using subdir-* are added to the commandline before the options - specified using the non-subdir variants. + The difference is that the subdir- variants have effect for the kbuild + file where they are present and all subdirectories. + Options specified using subdir-* are added to the commandline before + the options specified using the non-subdir variants. Example: subdir-ccflags-y := -Werror @@ -1174,14 +1174,14 @@ When kbuild executes, the following steps are followed (roughly): === 7 Kbuild syntax for exported headers The kernel include a set of headers that is exported to userspace. -Many headers can be exported as-is but other headers requires a +Many headers can be exported as-is but other headers require a minimal pre-processing before they are ready for user-space. The pre-processing does: - drop kernel specific annotations - drop include of compiler.h -- drop all sections that is kernel internat (guarded by ifdef __KERNEL__) +- drop all sections that are kernel internal (guarded by ifdef __KERNEL__) -Each relevant directory contain a file name "Kbuild" which specify the +Each relevant directory contains a file name "Kbuild" which specifies the headers to be exported. See subsequent chapter for the syntax of the Kbuild file. -- cgit v1.1 From ab265d5cdde7133f2569e2b5f341a80907b8600e Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Thu, 5 Aug 2010 11:23:11 -0700 Subject: docbook: use IDs as filenames to support multiple books I'm trying to generate a of s in docbook for wireless to link together all the cfg80211 and mac80211 documentation. However, docbook will generate "re01.html" anew for each book for the first , presumably due to a bug in the stylesheets. An effective workaround is to use IDs for the filenames, which makes them more descriptive as well, e.g. API-enum-ieee80211-band.html. Signed-off-by: Johannes Berg Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/DocBook/stylesheet.xsl | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/stylesheet.xsl b/Documentation/DocBook/stylesheet.xsl index 254c1d5..85b2527 100644 --- a/Documentation/DocBook/stylesheet.xsl +++ b/Documentation/DocBook/stylesheet.xsl @@ -6,4 +6,5 @@ 0 2 +1 -- cgit v1.1 From 44f28bdea09415d40b4d73a7668db5961362ec53 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= Date: Mon, 21 Jun 2010 16:11:44 +0200 Subject: Driver core: reduce duplicated code for platform_device creation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This makes the two similar functions platform_device_register_simple and platform_device_register_data one line inline functions using a new generic function platform_device_register_resndata. Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman --- Documentation/DocBook/device-drivers.tmpl | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 1b2dd4f..ecd35e9 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -111,6 +111,7 @@ X!Edrivers/base/attribute_container.c +!Iinclude/linux/platform_device.h !Edrivers/base/platform.c !Edrivers/base/bus.c -- cgit v1.1 From 3317fad5e9c741e758707879c68e20de2cb08f87 Mon Sep 17 00:00:00 2001 From: Magnus Damm Date: Fri, 25 Jun 2010 17:55:11 +0900 Subject: firmware: Update hotplug script Update the in-kernel hotplug example script to work properly with recent kernels. Without this fix the script may load the firmware twice - both at "add" and "remove" time. The second load only triggers in the case when multiple firmware images are used. A good example is the b43 driver which does not work properly without this fix. Signed-off-by: Magnus Damm Signed-off-by: Greg Kroah-Hartman --- Documentation/firmware_class/hotplug-script | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/firmware_class/hotplug-script b/Documentation/firmware_class/hotplug-script index 1990130..8143a95 100644 --- a/Documentation/firmware_class/hotplug-script +++ b/Documentation/firmware_class/hotplug-script @@ -6,11 +6,12 @@ HOTPLUG_FW_DIR=/usr/lib/hotplug/firmware/ -echo 1 > /sys/$DEVPATH/loading -cat $HOTPLUG_FW_DIR/$FIRMWARE > /sys/$DEVPATH/data -echo 0 > /sys/$DEVPATH/loading - -# To cancel the load in case of error: -# -# echo -1 > /sys/$DEVPATH/loading -# +if [ "$SUBSYSTEM" == "firmware" -a "$ACTION" == "add" ]; then + if [ -f $HOTPLUG_FW_DIR/$FIRMWARE ]; then + echo 1 > /sys/$DEVPATH/loading + cat $HOTPLUG_FW_DIR/$FIRMWARE > /sys/$DEVPATH/data + echo 0 > /sys/$DEVPATH/loading + else + echo -1 > /sys/$DEVPATH/loading + fi +fi -- cgit v1.1 From 30a69000a4ba9cf49e8b826431847cc80881b59b Mon Sep 17 00:00:00 2001 From: Bart Van Assche Date: Tue, 20 Jul 2010 15:22:05 -0700 Subject: sysfs: fix discrepancies between implementation and documentation Fix all discrepancies I know of between the sysfs implementation and its documentation. Signed-off-by: Bart Van Assche Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- Documentation/filesystems/sysfs.txt | 44 +++++++++++++++++++++---------------- 1 file changed, 25 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt index 931c806..d78ed0b 100644 --- a/Documentation/filesystems/sysfs.txt +++ b/Documentation/filesystems/sysfs.txt @@ -4,7 +4,7 @@ sysfs - _The_ filesystem for exporting kernel objects. Patrick Mochel Mike Murphy -Revised: 22 February 2009 +Revised: 10 July 2010 Original: 10 January 2003 @@ -124,7 +124,7 @@ show and store methods of the attribute owners. struct sysfs_ops { ssize_t (*show)(struct kobject *, struct attribute *, char *); - ssize_t (*store)(struct kobject *, struct attribute *, const char *); + ssize_t (*store)(struct kobject *, struct attribute *, const char *, size_t); }; [ Subsystems should have already defined a struct kobj_type as a @@ -139,18 +139,22 @@ calls the associated methods. To illustrate: +#define to_dev(obj) container_of(obj, struct device, kobj) #define to_dev_attr(_attr) container_of(_attr, struct device_attribute, attr) -#define to_dev(d) container_of(d, struct device, kobj) -static ssize_t -dev_attr_show(struct kobject * kobj, struct attribute * attr, char * buf) +static ssize_t dev_attr_show(struct kobject *kobj, struct attribute *attr, + char *buf) { - struct device_attribute * dev_attr = to_dev_attr(attr); - struct device * dev = to_dev(kobj); - ssize_t ret = 0; + struct device_attribute *dev_attr = to_dev_attr(attr); + struct device *dev = to_dev(kobj); + ssize_t ret = -EIO; if (dev_attr->show) - ret = dev_attr->show(dev, buf); + ret = dev_attr->show(dev, dev_attr, buf); + if (ret >= (ssize_t)PAGE_SIZE) { + print_symbol("dev_attr_show: %s returned bad count\n", + (unsigned long)dev_attr->show); + } return ret; } @@ -163,10 +167,9 @@ To read or write attributes, show() or store() methods must be specified when declaring the attribute. The method types should be as simple as those defined for device attributes: -ssize_t (*show)(struct device * dev, struct device_attribute * attr, - char * buf); -ssize_t (*store)(struct device * dev, struct device_attribute * attr, - const char * buf); +ssize_t (*show)(struct device *dev, struct device_attribute *attr, char *buf); +ssize_t (*store)(struct device *dev, struct device_attribute *attr, + const char *buf, size_t count); IOW, they should take only an object, an attribute, and a buffer as parameters. @@ -209,8 +212,8 @@ Other notes: - show() should always use snprintf(). -- store() should return the number of bytes used from the buffer. This - can be done using strlen(). +- store() should return the number of bytes used from the buffer. If the + entire buffer has been used, just return the count argument. - show() or store() can always return errors. If a bad value comes through, be sure to return an error. @@ -223,15 +226,18 @@ Other notes: A very simple (and naive) implementation of a device attribute is: -static ssize_t show_name(struct device *dev, struct device_attribute *attr, char *buf) +static ssize_t show_name(struct device *dev, struct device_attribute *attr, + char *buf) { return snprintf(buf, PAGE_SIZE, "%s\n", dev->name); } -static ssize_t store_name(struct device * dev, const char * buf) +static ssize_t store_name(struct device *dev, struct device_attribute *attr, + const char *buf, size_t count) { - sscanf(buf, "%20s", dev->name); - return strnlen(buf, PAGE_SIZE); + snprintf(dev->name, sizeof(dev->name), "%.*s", + (int)min(count, sizeof(dev->name) - 1), buf); + return count; } static DEVICE_ATTR(name, S_IRUGO, show_name, store_name); -- cgit v1.1 From a5307032718b1e90e6d07008d7fd44d1446db7d7 Mon Sep 17 00:00:00 2001 From: Ira Weiny Date: Thu, 15 Jul 2010 11:34:44 -0700 Subject: sysfs: Fix one more signature discrepancy between sysfs implementation and docs. Signed-off-by: Ira Weiny Signed-off-by: Greg Kroah-Hartman --- Documentation/filesystems/sysfs.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt index d78ed0b..5d1335fae 100644 --- a/Documentation/filesystems/sysfs.txt +++ b/Documentation/filesystems/sysfs.txt @@ -4,7 +4,7 @@ sysfs - _The_ filesystem for exporting kernel objects. Patrick Mochel Mike Murphy -Revised: 10 July 2010 +Revised: 15 July 2010 Original: 10 January 2003 @@ -333,7 +333,7 @@ Structure: struct bus_attribute { struct attribute attr; ssize_t (*show)(struct bus_type *, char * buf); - ssize_t (*store)(struct bus_type *, const char * buf); + ssize_t (*store)(struct bus_type *, const char * buf, size_t count); }; Declaring: -- cgit v1.1 From 4b676d2dbed3dadc6ef913d58f85360547fa071e Mon Sep 17 00:00:00 2001 From: Phillip Lougher Date: Thu, 5 Aug 2010 23:42:54 +0100 Subject: Squashfs: update Kconfig and documentation for LZO Update compression types supported and add some help text for the LZO Kconfig option. Also add missing "default n" line and make some trivial whitespace cleanups too. Signed-off-by: Phillip Lougher --- Documentation/filesystems/squashfs.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/squashfs.txt b/Documentation/filesystems/squashfs.txt index 203f720..66699af 100644 --- a/Documentation/filesystems/squashfs.txt +++ b/Documentation/filesystems/squashfs.txt @@ -2,7 +2,7 @@ SQUASHFS 4.0 FILESYSTEM ======================= Squashfs is a compressed read-only filesystem for Linux. -It uses zlib compression to compress files, inodes and directories. +It uses zlib/lzo compression to compress files, inodes and directories. Inodes in the system are very small and all blocks are packed to minimise data overhead. Block sizes greater than 4K are supported up to a maximum of 1Mbytes (default block size 128K). -- cgit v1.1 From ff9517a68792bb363c16f4e3155c4fc5a7f9d738 Mon Sep 17 00:00:00 2001 From: David Howells Date: Fri, 6 Aug 2010 03:13:52 +0100 Subject: DNS: Fixes for the DNS query module Fixes for the DNS query module, including: (1) Use 'negative' instead of '-ve' in the documentation. (2) Mark the kdoc comment with '/**' on dns_query(). Reported-by: Randy Dunlap Signed-off-by: David Howells Signed-off-by: Steve French --- Documentation/networking/dns_resolver.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/dns_resolver.txt b/Documentation/networking/dns_resolver.txt index d8e0ce1..aefd1e6 100644 --- a/Documentation/networking/dns_resolver.txt +++ b/Documentation/networking/dns_resolver.txt @@ -96,9 +96,9 @@ implemented in the module can be called after doing: for the default query type it is just a list of comma-separated IPv4 and IPv6 addresses. The caller must free the result. - The length of the result string is returned on success, and a -ve error - code is returned otherwise. -EKEYREJECTED will be returned if the DNS - lookup failed. + The length of the result string is returned on success, and a negative + error code is returned otherwise. -EKEYREJECTED will be returned if the + DNS lookup failed. If _expiry is non-NULL, the expiry time (TTL) of the result will be returned also. -- cgit v1.1 From 58b0e22ab68d055a9563835daef10fbc9fe8f5ae Mon Sep 17 00:00:00 2001 From: Michael Hennerich Date: Tue, 6 Jul 2010 13:01:06 +0000 Subject: Blackfin: remove useless and outdated documentation The filesystem and cache files duplicate existing & better documents, and these contain outdated information. So punt them. Signed-off-by: Michael Hennerich Signed-off-by: Mike Frysinger --- Documentation/blackfin/00-INDEX | 6 -- Documentation/blackfin/Filesystems | 169 ------------------------------- Documentation/blackfin/cachefeatures.txt | 55 ---------- 3 files changed, 230 deletions(-) delete mode 100644 Documentation/blackfin/Filesystems delete mode 100644 Documentation/blackfin/cachefeatures.txt (limited to 'Documentation') diff --git a/Documentation/blackfin/00-INDEX b/Documentation/blackfin/00-INDEX index c34e124..10391d3 100644 --- a/Documentation/blackfin/00-INDEX +++ b/Documentation/blackfin/00-INDEX @@ -1,11 +1,5 @@ 00-INDEX - This file -cachefeatures.txt - - Supported cache features. - -Filesystems - - Requirements for mounting the root file system. - bfin-gpio-note.txt - Notes in developing/using bfin-gpio driver. diff --git a/Documentation/blackfin/Filesystems b/Documentation/blackfin/Filesystems deleted file mode 100644 index 51260a1..0000000 --- a/Documentation/blackfin/Filesystems +++ /dev/null @@ -1,169 +0,0 @@ -/* - * File: Documentation/blackfin/Filesystems - * Based on: - * Author: - * - * Created: - * Description: This file contains the simple DMA Implementation for Blackfin - * - * Rev: $Id: Filesystems 2384 2006-11-01 04:12:43Z magicyang $ - * - * Modified: - * Copyright 2004-2006 Analog Devices Inc. - * - * Bugs: Enter bugs at http://blackfin.uclinux.org/ - * - */ - - How to mount the root file system in uClinux/Blackfin - ----------------------------------------------------- - -1 Mounting EXT3 File system. - ------------------------ - - Creating an EXT3 File system for uClinux/Blackfin: - - -Please follow the steps to form the EXT3 File system and mount the same as root -file system. - -a Make an ext3 file system as large as you want the final root file - system. - - mkfs.ext3 /dev/ram0 - -b Mount this Empty file system on a free directory as: - - mount -t ext3 /dev/ram0 ./test - where ./test is the empty directory. - -c Copy your root fs directory that you have so carefully made over. - - cp -af /tmp/my_final_rootfs_files/* ./test - - (For ex: cp -af uClinux-dist/romfs/* ./test) - -d If you have done everything right till now you should be able to see - the required "root" dir's (that's etc, root, bin, lib, sbin...) - -e Now unmount the file system - - umount ./test - -f Create the root file system image. - - dd if=/dev/ram0 bs=1k count= \ - > ext3fs.img - - -Now you have to tell the kernel that will be mounting this file system as -rootfs. -So do a make menuconfig under kernel and select the Ext3 journaling file system -support under File system --> submenu. - - -2. Mounting EXT2 File system. - ------------------------- - -By default the ext2 file system image will be created if you invoke make from -the top uClinux-dist directory. - - -3. Mounting CRAMFS File System - ---------------------------- - -To create a CRAMFS file system image execute the command - - mkfs.cramfs ./test cramfs.img - - where ./test is the target directory. - - -4. Mounting ROMFS File System - -------------------------- - -To create a ROMFS file system image execute the command - - genromfs -v -V "ROMdisk" -f romfs.img -d ./test - - where ./test is the target directory - - -5. Mounting the JFFS2 Filesystem - ----------------------------- - -To create a compressed JFFS filesystem (JFFS2), please execute the command - - mkfs.jffs2 -d ./test -o jffs2.img - - where ./test is the target directory. - -However, please make sure the following is in your kernel config. - -/* - * RAM/ROM/Flash chip drivers - */ -#define CONFIG_MTD_CFI 1 -#define CONFIG_MTD_ROM 1 -/* - * Mapping drivers for chip access - */ -#define CONFIG_MTD_COMPLEX_MAPPINGS 1 -#define CONFIG_MTD_BF533 1 -#undef CONFIG_MTD_UCLINUX - -Through the u-boot boot loader, use the jffs2.img in the corresponding -partition made in linux-2.6.x/drivers/mtd/maps/bf533_flash.c. - -NOTE - Currently the Flash driver is available only for EZKIT. Watch out for a - STAMP driver soon. - - -6. Mounting the NFS File system - ----------------------------- - - For mounting the NFS please do the following in the kernel config. - - In Networking Support --> Networking options --> TCP/IP networking --> - IP: kernel level autoconfiguration - - Enable BOOTP Support. - - In Kernel hacking --> Compiled-in kernel boot parameter add the following - - root=/dev/nfs rw ip=bootp - - In File system --> Network File system, Enable - - NFS file system support --> NFSv3 client support - Root File system on NFS - - in uClibc menuconfig, do the following - In Networking Support - enable Remote Procedure Call (RPC) support - Full RPC Support - - On the Host side, ensure that /etc/dhcpd.conf looks something like this - - ddns-update-style ad-hoc; - allow bootp; - subnet 10.100.4.0 netmask 255.255.255.0 { - default-lease-time 122209600; - max-lease-time 31557600; - group { - host bf533 { - hardware ethernet 00:CF:52:49:C3:01; - fixed-address 10.100.4.50; - option root-path "/home/nfsmount"; - } - } - - ensure that /etc/exports looks something like this - /home/nfsmount *(rw,no_root_squash,no_all_squash) - - run the following commands as root (may differ depending on your - distribution) : - - service nfs start - - service portmap start - - service dhcpd start - - /usr/sbin/exportfs diff --git a/Documentation/blackfin/cachefeatures.txt b/Documentation/blackfin/cachefeatures.txt deleted file mode 100644 index 75de51f..0000000 --- a/Documentation/blackfin/cachefeatures.txt +++ /dev/null @@ -1,55 +0,0 @@ -/* - * File: Documentation/blackfin/cachefeatures.txt - * Based on: - * Author: - * - * Created: - * Description: This file contains the simple DMA Implementation for Blackfin - * - * Rev: $Id: cachefeatures.txt 2384 2006-11-01 04:12:43Z magicyang $ - * - * Modified: - * Copyright 2004-2006 Analog Devices Inc. - * - * Bugs: Enter bugs at http://blackfin.uclinux.org/ - * - */ - - - Instruction and Data cache initialization. - icache_init(); - dcache_init(); - - - Instruction and Data cache Invalidation Routines, when flushing the - same is not required. - _icache_invalidate(); - _dcache_invalidate(); - - Also, for invalidating the entire instruction and data cache, the below - routines are provided (another method for invalidation, refer page no 267 and 287 of - ADSP-BF533 Hardware Reference manual) - - invalidate_entire_dcache(); - invalidate_entire_icache(); - - -External Flushing of Instruction and data cache routines. - - flush_instruction_cache(); - flush_data_cache(); - - - Internal Flushing of Instruction and Data Cache. - - icplb_flush(); - dcplb_flush(); - - - Miscellaneous cache functions. - - flush_cache_all(); - flush_cache_mm(); - invalidate_dcache_range(); - flush_dcache_range(); - flush_dcache_page(); - flush_cache_range(); - flush_cache_page(); - invalidate_dcache_range(); - flush_page_to_ram(); - -- cgit v1.1 From 3322c7bbf60801da2a22d7bd88865d2dc3bd73ac Mon Sep 17 00:00:00 2001 From: Michael Hennerich Date: Tue, 6 Jul 2010 13:57:12 +0000 Subject: Blackfin: document SPI CS limitations with CPHA=0 With the Blackfin on-chip SPI peripheral, there is some logic tied to the CPHA bit whether the Slave Select Line is controlled by hardware (CPHA=0) or controlled by software (CPHA=1). However, the Linux SPI bus driver assumes that the Slave Select being asserted during the entire SPI transfer. So explain these small details for people who need certain SPI modes with standard CS behavior. Signed-off-by: Michael Hennerich Signed-off-by: Mike Frysinger --- Documentation/blackfin/00-INDEX | 5 ++++- Documentation/blackfin/bfin-spi-notes.txt | 14 ++++++++++++++ 2 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 Documentation/blackfin/bfin-spi-notes.txt (limited to 'Documentation') diff --git a/Documentation/blackfin/00-INDEX b/Documentation/blackfin/00-INDEX index 10391d3..2df0365 100644 --- a/Documentation/blackfin/00-INDEX +++ b/Documentation/blackfin/00-INDEX @@ -1,5 +1,8 @@ 00-INDEX - This file -bfin-gpio-note.txt +bfin-gpio-notes.txt - Notes in developing/using bfin-gpio driver. + +bfin-spi-notes.txt + - Notes for using bfin spi bus driver. diff --git a/Documentation/blackfin/bfin-spi-notes.txt b/Documentation/blackfin/bfin-spi-notes.txt new file mode 100644 index 0000000..556fa87 --- /dev/null +++ b/Documentation/blackfin/bfin-spi-notes.txt @@ -0,0 +1,14 @@ +SPI Chip Select behavior: + +With the Blackfin on-chip SPI peripheral, there is some logic tied to the CPHA +bit whether the Slave Select Line is controlled by hardware (CPHA=0) or +controlled by software (CPHA=1). However, the Linux SPI bus driver assumes that +the Slave Select is always under software control and being asserted during +the entire SPI transfer. - And not just bits_per_word duration. + +In most cases you can utilize SPI MODE_3 instead of MODE_0 to work-around this +behavior. If your SPI slave device in question requires SPI MODE_0 or MODE_2 +timing, you can utilize the GPIO controlled SPI Slave Select option instead. + +You can even use the same pin whose peripheral role is a SSEL, +but use it as a GPIO instead. -- cgit v1.1 From e589333f346b58f8da5bb8152e1219c52d375ccc Mon Sep 17 00:00:00 2001 From: Maxim Levitsky Date: Sat, 31 Jul 2010 11:59:23 -0300 Subject: V4L/DVB: IR: extend interfaces to support more device settings LIRC: add new IOCTL that enables learning mode (wide band receiver) Still missing features: carrier report & timeout reports. Will need to pack these into ir_raw_event Signed-off-by: Maxim Levitsky Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/lirc_device_interface.xml | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/lirc_device_interface.xml b/Documentation/DocBook/v4l/lirc_device_interface.xml index 0413234..68134c0 100644 --- a/Documentation/DocBook/v4l/lirc_device_interface.xml +++ b/Documentation/DocBook/v4l/lirc_device_interface.xml @@ -229,6 +229,22 @@ on working with the default settings initially. and LIRC_SETUP_END. Drivers can also choose to ignore these ioctls. + + LIRC_SET_WIDEBAND_RECEIVER + + Some receivers are equipped with special wide band receiver which is intended + to be used to learn output of existing remote. + Calling that ioctl with (1) will enable it, and with (0) disable it. + This might be useful of receivers that have otherwise narrow band receiver + that prevents them to be used with some remotes. + Wide band receiver might also be more precise + On the other hand its disadvantage it usually reduced range of reception. + Note: wide band receiver might be implictly enabled if you enable + carrier reports. In that case it will be disabled as soon as you disable + carrier reports. Trying to disable wide band receiver while carrier + reports are active will do nothing. + +
-- cgit v1.1 From 5fd8f7388c9a8601c2dbe0da458df602fe427e83 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Tue, 3 Aug 2010 09:50:29 -0300 Subject: V4L/DVB: v4l: Add driver for Samsung S5P SoC video postprocessor This driver exports a video device node per each camera interface/ video postprocessor (FIMC) device contained in Samsung S5P SoC series. The driver is based on v4l2-mem2mem framework. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park Signed-off-by: Pawel Osciak Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/pixfmt-packed-rgb.xml | 78 +++++++++++++++++++++++++ 1 file changed, 78 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/pixfmt-packed-rgb.xml b/Documentation/DocBook/v4l/pixfmt-packed-rgb.xml index d2dd697..26e8792 100644 --- a/Documentation/DocBook/v4l/pixfmt-packed-rgb.xml +++ b/Documentation/DocBook/v4l/pixfmt-packed-rgb.xml @@ -240,6 +240,45 @@ colorspace V4L2_COLORSPACE_SRGB. r1 r0 + + V4L2_PIX_FMT_BGR666 + 'BGRH' + + b5 + b4 + b3 + b2 + b1 + b0 + g5 + g4 + + g3 + g2 + g1 + g0 + r5 + r4 + r3 + r2 + + r1 + r0 + + + + + + + + + + + + + + + V4L2_PIX_FMT_BGR24 'BGR3' @@ -700,6 +739,45 @@ defined in error. Drivers may interpret them as in b1 b0 + + V4L2_PIX_FMT_BGR666 + 'BGRH' + + b5 + b4 + b3 + b2 + b1 + b0 + g5 + g4 + + g3 + g2 + g1 + g0 + r5 + r4 + r3 + r2 + + r1 + r0 + + + + + + + + + + + + + + + V4L2_PIX_FMT_BGR24 'BGR3' -- cgit v1.1 From a42b57f5aacf2b43f3e7931e8b9c609051839aa8 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Sun, 1 Aug 2010 14:35:53 -0300 Subject: V4L/DVB: Documentation: add v4l2-controls.txt documenting the new controls API Signed-off-by: Hans Verkuil Reviewed-by: Laurent Pinchart Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-controls.txt | 648 ++++++++++++++++++++++++++++ 1 file changed, 648 insertions(+) create mode 100644 Documentation/video4linux/v4l2-controls.txt (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-controls.txt b/Documentation/video4linux/v4l2-controls.txt new file mode 100644 index 0000000..8773778d --- /dev/null +++ b/Documentation/video4linux/v4l2-controls.txt @@ -0,0 +1,648 @@ +Introduction +============ + +The V4L2 control API seems simple enough, but quickly becomes very hard to +implement correctly in drivers. But much of the code needed to handle controls +is actually not driver specific and can be moved to the V4L core framework. + +After all, the only part that a driver developer is interested in is: + +1) How do I add a control? +2) How do I set the control's value? (i.e. s_ctrl) + +And occasionally: + +3) How do I get the control's value? (i.e. g_volatile_ctrl) +4) How do I validate the user's proposed control value? (i.e. try_ctrl) + +All the rest is something that can be done centrally. + +The control framework was created in order to implement all the rules of the +V4L2 specification with respect to controls in a central place. And to make +life as easy as possible for the driver developer. + +Note that the control framework relies on the presence of a struct v4l2_device +for V4L2 drivers and struct v4l2_subdev for sub-device drivers. + + +Objects in the framework +======================== + +There are two main objects: + +The v4l2_ctrl object describes the control properties and keeps track of the +control's value (both the current value and the proposed new value). + +v4l2_ctrl_handler is the object that keeps track of controls. It maintains a +list of v4l2_ctrl objects that it owns and another list of references to +controls, possibly to controls owned by other handlers. + + +Basic usage for V4L2 and sub-device drivers +=========================================== + +1) Prepare the driver: + +1.1) Add the handler to your driver's top-level struct: + + struct foo_dev { + ... + struct v4l2_ctrl_handler ctrl_handler; + ... + }; + + struct foo_dev *foo; + +1.2) Initialize the handler: + + v4l2_ctrl_handler_init(&foo->ctrl_handler, nr_of_controls); + + The second argument is a hint telling the function how many controls this + handler is expected to handle. It will allocate a hashtable based on this + information. It is a hint only. + +1.3) Hook the control handler into the driver: + +1.3.1) For V4L2 drivers do this: + + struct foo_dev { + ... + struct v4l2_device v4l2_dev; + ... + struct v4l2_ctrl_handler ctrl_handler; + ... + }; + + foo->v4l2_dev.ctrl_handler = &foo->ctrl_handler; + + Where foo->v4l2_dev is of type struct v4l2_device. + + Finally, remove all control functions from your v4l2_ioctl_ops: + vidioc_queryctrl, vidioc_querymenu, vidioc_g_ctrl, vidioc_s_ctrl, + vidioc_g_ext_ctrls, vidioc_try_ext_ctrls and vidioc_s_ext_ctrls. + Those are now no longer needed. + +1.3.2) For sub-device drivers do this: + + struct foo_dev { + ... + struct v4l2_subdev sd; + ... + struct v4l2_ctrl_handler ctrl_handler; + ... + }; + + foo->sd.ctrl_handler = &foo->ctrl_handler; + + Where foo->sd is of type struct v4l2_subdev. + + And set all core control ops in your struct v4l2_subdev_core_ops to these + helpers: + + .queryctrl = v4l2_subdev_queryctrl, + .querymenu = v4l2_subdev_querymenu, + .g_ctrl = v4l2_subdev_g_ctrl, + .s_ctrl = v4l2_subdev_s_ctrl, + .g_ext_ctrls = v4l2_subdev_g_ext_ctrls, + .try_ext_ctrls = v4l2_subdev_try_ext_ctrls, + .s_ext_ctrls = v4l2_subdev_s_ext_ctrls, + + Note: this is a temporary solution only. Once all V4L2 drivers that depend + on subdev drivers are converted to the control framework these helpers will + no longer be needed. + +1.4) Clean up the handler at the end: + + v4l2_ctrl_handler_free(&foo->ctrl_handler); + + +2) Add controls: + +You add non-menu controls by calling v4l2_ctrl_new_std: + + struct v4l2_ctrl *v4l2_ctrl_new_std(struct v4l2_ctrl_handler *hdl, + const struct v4l2_ctrl_ops *ops, + u32 id, s32 min, s32 max, u32 step, s32 def); + +Menu controls are added by calling v4l2_ctrl_new_std_menu: + + struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct v4l2_ctrl_handler *hdl, + const struct v4l2_ctrl_ops *ops, + u32 id, s32 max, s32 skip_mask, s32 def); + +These functions are typically called right after the v4l2_ctrl_handler_init: + + v4l2_ctrl_handler_init(&foo->ctrl_handler, nr_of_controls); + v4l2_ctrl_new_std(&foo->ctrl_handler, &foo_ctrl_ops, + V4L2_CID_BRIGHTNESS, 0, 255, 1, 128); + v4l2_ctrl_new_std(&foo->ctrl_handler, &foo_ctrl_ops, + V4L2_CID_CONTRAST, 0, 255, 1, 128); + v4l2_ctrl_new_std_menu(&foo->ctrl_handler, &foo_ctrl_ops, + V4L2_CID_POWER_LINE_FREQUENCY, + V4L2_CID_POWER_LINE_FREQUENCY_60HZ, 0, + V4L2_CID_POWER_LINE_FREQUENCY_DISABLED); + ... + if (foo->ctrl_handler.error) { + int err = foo->ctrl_handler.error; + + v4l2_ctrl_handler_free(&foo->ctrl_handler); + return err; + } + +The v4l2_ctrl_new_std function returns the v4l2_ctrl pointer to the new +control, but if you do not need to access the pointer outside the control ops, +then there is no need to store it. + +The v4l2_ctrl_new_std function will fill in most fields based on the control +ID except for the min, max, step and default values. These are passed in the +last four arguments. These values are driver specific while control attributes +like type, name, flags are all global. The control's current value will be set +to the default value. + +The v4l2_ctrl_new_std_menu function is very similar but it is used for menu +controls. There is no min argument since that is always 0 for menu controls, +and instead of a step there is a skip_mask argument: if bit X is 1, then menu +item X is skipped. + +Note that if something fails, the function will return NULL or an error and +set ctrl_handler->error to the error code. If ctrl_handler->error was already +set, then it will just return and do nothing. This is also true for +v4l2_ctrl_handler_init if it cannot allocate the internal data structure. + +This makes it easy to init the handler and just add all controls and only check +the error code at the end. Saves a lot of repetitive error checking. + +It is recommended to add controls in ascending control ID order: it will be +a bit faster that way. + +3) Optionally force initial control setup: + + v4l2_ctrl_handler_setup(&foo->ctrl_handler); + +This will call s_ctrl for all controls unconditionally. Effectively this +initializes the hardware to the default control values. It is recommended +that you do this as this ensures that both the internal data structures and +the hardware are in sync. + +4) Finally: implement the v4l2_ctrl_ops + + static const struct v4l2_ctrl_ops foo_ctrl_ops = { + .s_ctrl = foo_s_ctrl, + }; + +Usually all you need is s_ctrl: + + static int foo_s_ctrl(struct v4l2_ctrl *ctrl) + { + struct foo *state = container_of(ctrl->handler, struct foo, ctrl_handler); + + switch (ctrl->id) { + case V4L2_CID_BRIGHTNESS: + write_reg(0x123, ctrl->val); + break; + case V4L2_CID_CONTRAST: + write_reg(0x456, ctrl->val); + break; + } + return 0; + } + +The control ops are called with the v4l2_ctrl pointer as argument. +The new control value has already been validated, so all you need to do is +to actually update the hardware registers. + +You're done! And this is sufficient for most of the drivers we have. No need +to do any validation of control values, or implement QUERYCTRL/QUERYMENU. And +G/S_CTRL as well as G/TRY/S_EXT_CTRLS are automatically supported. + + +============================================================================== + +The remainder of this document deals with more advanced topics and scenarios. +In practice the basic usage as described above is sufficient for most drivers. + +=============================================================================== + + +Inheriting Controls +=================== + +When a sub-device is registered with a V4L2 driver by calling +v4l2_device_register_subdev() and the ctrl_handler fields of both v4l2_subdev +and v4l2_device are set, then the controls of the subdev will become +automatically available in the V4L2 driver as well. If the subdev driver +contains controls that already exist in the V4L2 driver, then those will be +skipped (so a V4L2 driver can always override a subdev control). + +What happens here is that v4l2_device_register_subdev() calls +v4l2_ctrl_add_handler() adding the controls of the subdev to the controls +of v4l2_device. + + +Accessing Control Values +======================== + +The v4l2_ctrl struct contains these two unions: + + /* The current control value. */ + union { + s32 val; + s64 val64; + char *string; + } cur; + + /* The new control value. */ + union { + s32 val; + s64 val64; + char *string; + }; + +Within the control ops you can freely use these. The val and val64 speak for +themselves. The string pointers point to character buffers of length +ctrl->maximum + 1, and are always 0-terminated. + +In most cases 'cur' contains the current cached control value. When you create +a new control this value is made identical to the default value. After calling +v4l2_ctrl_handler_setup() this value is passed to the hardware. It is generally +a good idea to call this function. + +Whenever a new value is set that new value is automatically cached. This means +that most drivers do not need to implement the g_volatile_ctrl() op. The +exception is for controls that return a volatile register such as a signal +strength read-out that changes continuously. In that case you will need to +implement g_volatile_ctrl like this: + + static int foo_g_volatile_ctrl(struct v4l2_ctrl *ctrl) + { + switch (ctrl->id) { + case V4L2_CID_BRIGHTNESS: + ctrl->cur.val = read_reg(0x123); + break; + } + } + +The 'new value' union is not used in g_volatile_ctrl. In general controls +that need to implement g_volatile_ctrl are read-only controls. + +To mark a control as volatile you have to set the is_volatile flag: + + ctrl = v4l2_ctrl_new_std(&sd->ctrl_handler, ...); + if (ctrl) + ctrl->is_volatile = 1; + +For try/s_ctrl the new values (i.e. as passed by the user) are filled in and +you can modify them in try_ctrl or set them in s_ctrl. The 'cur' union +contains the current value, which you can use (but not change!) as well. + +If s_ctrl returns 0 (OK), then the control framework will copy the new final +values to the 'cur' union. + +While in g_volatile/s/try_ctrl you can access the value of all controls owned +by the same handler since the handler's lock is held. If you need to access +the value of controls owned by other handlers, then you have to be very careful +not to introduce deadlocks. + +Outside of the control ops you have to go through to helper functions to get +or set a single control value safely in your driver: + + s32 v4l2_ctrl_g_ctrl(struct v4l2_ctrl *ctrl); + int v4l2_ctrl_s_ctrl(struct v4l2_ctrl *ctrl, s32 val); + +These functions go through the control framework just as VIDIOC_G/S_CTRL ioctls +do. Don't use these inside the control ops g_volatile/s/try_ctrl, though, that +will result in a deadlock since these helpers lock the handler as well. + +You can also take the handler lock yourself: + + mutex_lock(&state->ctrl_handler.lock); + printk(KERN_INFO "String value is '%s'\n", ctrl1->cur.string); + printk(KERN_INFO "Integer value is '%s'\n", ctrl2->cur.val); + mutex_unlock(&state->ctrl_handler.lock); + + +Menu Controls +============= + +The v4l2_ctrl struct contains this union: + + union { + u32 step; + u32 menu_skip_mask; + }; + +For menu controls menu_skip_mask is used. What it does is that it allows you +to easily exclude certain menu items. This is used in the VIDIOC_QUERYMENU +implementation where you can return -EINVAL if a certain menu item is not +present. Note that VIDIOC_QUERYCTRL always returns a step value of 1 for +menu controls. + +A good example is the MPEG Audio Layer II Bitrate menu control where the +menu is a list of standardized possible bitrates. But in practice hardware +implementations will only support a subset of those. By setting the skip +mask you can tell the framework which menu items should be skipped. Setting +it to 0 means that all menu items are supported. + +You set this mask either through the v4l2_ctrl_config struct for a custom +control, or by calling v4l2_ctrl_new_std_menu(). + + +Custom Controls +=============== + +Driver specific controls can be created using v4l2_ctrl_new_custom(): + + static const struct v4l2_ctrl_config ctrl_filter = { + .ops = &ctrl_custom_ops, + .id = V4L2_CID_MPEG_CX2341X_VIDEO_SPATIAL_FILTER, + .name = "Spatial Filter", + .type = V4L2_CTRL_TYPE_INTEGER, + .flags = V4L2_CTRL_FLAG_SLIDER, + .max = 15, + .step = 1, + }; + + ctrl = v4l2_ctrl_new_custom(&foo->ctrl_handler, &ctrl_filter, NULL); + +The last argument is the priv pointer which can be set to driver-specific +private data. + +The v4l2_ctrl_config struct also has fields to set the is_private and is_volatile +flags. + +If the name field is not set, then the framework will assume this is a standard +control and will fill in the name, type and flags fields accordingly. + + +Active and Grabbed Controls +=========================== + +If you get more complex relationships between controls, then you may have to +activate and deactivate controls. For example, if the Chroma AGC control is +on, then the Chroma Gain control is inactive. That is, you may set it, but +the value will not be used by the hardware as long as the automatic gain +control is on. Typically user interfaces can disable such input fields. + +You can set the 'active' status using v4l2_ctrl_activate(). By default all +controls are active. Note that the framework does not check for this flag. +It is meant purely for GUIs. The function is typically called from within +s_ctrl. + +The other flag is the 'grabbed' flag. A grabbed control means that you cannot +change it because it is in use by some resource. Typical examples are MPEG +bitrate controls that cannot be changed while capturing is in progress. + +If a control is set to 'grabbed' using v4l2_ctrl_grab(), then the framework +will return -EBUSY if an attempt is made to set this control. The +v4l2_ctrl_grab() function is typically called from the driver when it +starts or stops streaming. + + +Control Clusters +================ + +By default all controls are independent from the others. But in more +complex scenarios you can get dependencies from one control to another. +In that case you need to 'cluster' them: + + struct foo { + struct v4l2_ctrl_handler ctrl_handler; +#define AUDIO_CL_VOLUME (0) +#define AUDIO_CL_MUTE (1) + struct v4l2_ctrl *audio_cluster[2]; + ... + }; + + state->audio_cluster[AUDIO_CL_VOLUME] = + v4l2_ctrl_new_std(&state->ctrl_handler, ...); + state->audio_cluster[AUDIO_CL_MUTE] = + v4l2_ctrl_new_std(&state->ctrl_handler, ...); + v4l2_ctrl_cluster(ARRAY_SIZE(state->audio_cluster), state->audio_cluster); + +From now on whenever one or more of the controls belonging to the same +cluster is set (or 'gotten', or 'tried'), only the control ops of the first +control ('volume' in this example) is called. You effectively create a new +composite control. Similar to how a 'struct' works in C. + +So when s_ctrl is called with V4L2_CID_AUDIO_VOLUME as argument, you should set +all two controls belonging to the audio_cluster: + + static int foo_s_ctrl(struct v4l2_ctrl *ctrl) + { + struct foo *state = container_of(ctrl->handler, struct foo, ctrl_handler); + + switch (ctrl->id) { + case V4L2_CID_AUDIO_VOLUME: { + struct v4l2_ctrl *mute = ctrl->cluster[AUDIO_CL_MUTE]; + + write_reg(0x123, mute->val ? 0 : ctrl->val); + break; + } + case V4L2_CID_CONTRAST: + write_reg(0x456, ctrl->val); + break; + } + return 0; + } + +In the example above the following are equivalent for the VOLUME case: + + ctrl == ctrl->cluster[AUDIO_CL_VOLUME] == state->audio_cluster[AUDIO_CL_VOLUME] + ctrl->cluster[AUDIO_CL_MUTE] == state->audio_cluster[AUDIO_CL_MUTE] + +Note that controls in a cluster may be NULL. For example, if for some +reason mute was never added (because the hardware doesn't support that +particular feature), then mute will be NULL. So in that case we have a +cluster of 2 controls, of which only 1 is actually instantiated. The +only restriction is that the first control of the cluster must always be +present, since that is the 'master' control of the cluster. The master +control is the one that identifies the cluster and that provides the +pointer to the v4l2_ctrl_ops struct that is used for that cluster. + +Obviously, all controls in the cluster array must be initialized to either +a valid control or to NULL. + + +VIDIOC_LOG_STATUS Support +========================= + +This ioctl allow you to dump the current status of a driver to the kernel log. +The v4l2_ctrl_handler_log_status(ctrl_handler, prefix) can be used to dump the +value of the controls owned by the given handler to the log. You can supply a +prefix as well. If the prefix didn't end with a space, then ': ' will be added +for you. + + +Different Handlers for Different Video Nodes +============================================ + +Usually the V4L2 driver has just one control handler that is global for +all video nodes. But you can also specify different control handlers for +different video nodes. You can do that by manually setting the ctrl_handler +field of struct video_device. + +That is no problem if there are no subdevs involved but if there are, then +you need to block the automatic merging of subdev controls to the global +control handler. You do that by simply setting the ctrl_handler field in +struct v4l2_device to NULL. Now v4l2_device_register_subdev() will no longer +merge subdev controls. + +After each subdev was added, you will then have to call v4l2_ctrl_add_handler +manually to add the subdev's control handler (sd->ctrl_handler) to the desired +control handler. This control handler may be specific to the video_device or +for a subset of video_device's. For example: the radio device nodes only have +audio controls, while the video and vbi device nodes share the same control +handler for the audio and video controls. + +If you want to have one handler (e.g. for a radio device node) have a subset +of another handler (e.g. for a video device node), then you should first add +the controls to the first handler, add the other controls to the second +handler and finally add the first handler to the second. For example: + + v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_VOLUME, ...); + v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_MUTE, ...); + v4l2_ctrl_new_std(&video_ctrl_handler, &video_ops, V4L2_CID_BRIGHTNESS, ...); + v4l2_ctrl_new_std(&video_ctrl_handler, &video_ops, V4L2_CID_CONTRAST, ...); + v4l2_ctrl_add_handler(&video_ctrl_handler, &radio_ctrl_handler); + +Or you can add specific controls to a handler: + + volume = v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_AUDIO_VOLUME, ...); + v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_BRIGHTNESS, ...); + v4l2_ctrl_new_std(&video_ctrl_handler, &ops, V4L2_CID_CONTRAST, ...); + v4l2_ctrl_add_ctrl(&radio_ctrl_handler, volume); + +What you should not do is make two identical controls for two handlers. +For example: + + v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_MUTE, ...); + v4l2_ctrl_new_std(&video_ctrl_handler, &video_ops, V4L2_CID_AUDIO_MUTE, ...); + +This would be bad since muting the radio would not change the video mute +control. The rule is to have one control for each hardware 'knob' that you +can twiddle. + + +Finding Controls +================ + +Normally you have created the controls yourself and you can store the struct +v4l2_ctrl pointer into your own struct. + +But sometimes you need to find a control from another handler that you do +not own. For example, if you have to find a volume control from a subdev. + +You can do that by calling v4l2_ctrl_find: + + struct v4l2_ctrl *volume; + + volume = v4l2_ctrl_find(sd->ctrl_handler, V4L2_CID_AUDIO_VOLUME); + +Since v4l2_ctrl_find will lock the handler you have to be careful where you +use it. For example, this is not a good idea: + + struct v4l2_ctrl_handler ctrl_handler; + + v4l2_ctrl_new_std(&ctrl_handler, &video_ops, V4L2_CID_BRIGHTNESS, ...); + v4l2_ctrl_new_std(&ctrl_handler, &video_ops, V4L2_CID_CONTRAST, ...); + +...and in video_ops.s_ctrl: + + case V4L2_CID_BRIGHTNESS: + contrast = v4l2_find_ctrl(&ctrl_handler, V4L2_CID_CONTRAST); + ... + +When s_ctrl is called by the framework the ctrl_handler.lock is already taken, so +attempting to find another control from the same handler will deadlock. + +It is recommended not to use this function from inside the control ops. + + +Inheriting Controls +=================== + +When one control handler is added to another using v4l2_ctrl_add_handler, then +by default all controls from one are merged to the other. But a subdev might +have low-level controls that make sense for some advanced embedded system, but +not when it is used in consumer-level hardware. In that case you want to keep +those low-level controls local to the subdev. You can do this by simply +setting the 'is_private' flag of the control to 1: + + static const struct v4l2_ctrl_config ctrl_private = { + .ops = &ctrl_custom_ops, + .id = V4L2_CID_..., + .name = "Some Private Control", + .type = V4L2_CTRL_TYPE_INTEGER, + .max = 15, + .step = 1, + .is_private = 1, + }; + + ctrl = v4l2_ctrl_new_custom(&foo->ctrl_handler, &ctrl_private, NULL); + +These controls will now be skipped when v4l2_ctrl_add_handler is called. + + +V4L2_CTRL_TYPE_CTRL_CLASS Controls +================================== + +Controls of this type can be used by GUIs to get the name of the control class. +A fully featured GUI can make a dialog with multiple tabs with each tab +containing the controls belonging to a particular control class. The name of +each tab can be found by querying a special control with ID . + +Drivers do not have to care about this. The framework will automatically add +a control of this type whenever the first control belonging to a new control +class is added. + + +Differences from the Spec +========================= + +There are a few places where the framework acts slightly differently from the +V4L2 Specification. Those differences are described in this section. We will +have to see whether we need to adjust the spec or not. + +1) It is no longer required to have all controls contained in a +v4l2_ext_control array be from the same control class. The framework will be +able to handle any type of control in the array. You need to set ctrl_class +to 0 in order to enable this. If ctrl_class is non-zero, then it will still +check that all controls belong to that control class. + +If you set ctrl_class to 0 and count to 0, then it will only return an error +if there are no controls at all. + +2) Clarified the way error_idx works. For get and set it will be equal to +count if nothing was done yet. If it is less than count then only the controls +up to error_idx-1 were successfully applied. + +3) When attempting to read a button control the framework will return -EACCES +instead of -EINVAL as stated in the spec. It seems to make more sense since +button controls are write-only controls. + +4) Attempting to write to a read-only control will return -EACCES instead of +-EINVAL as the spec says. + +5) The spec does not mention what should happen when you try to set/get a +control class controls. ivtv currently returns -EINVAL (indicating that the +control ID does not exist) while the framework will return -EACCES, which +makes more sense. + + +Proposals for Extensions +======================== + +Some ideas for future extensions to the spec: + +1) Add a V4L2_CTRL_FLAG_HEX to have values shown as hexadecimal instead of +decimal. Useful for e.g. video_mute_yuv. + +2) It is possible to mark in the controls array which controls have been +successfully written and which failed by for example adding a bit to the +control ID. Not sure if it is worth the effort, though. + +3) Trying to set volatile inactive controls should result in -EACCESS. + +4) Add a new flag to mark volatile controls. Any application that wants +to store the state of the controls can then skip volatile inactive controls. +Currently it is not possible to detect such controls. -- cgit v1.1 From b55c52b1938c9320819144e060ca28244d8ee7eb Mon Sep 17 00:00:00 2001 From: Jeff Kirsher Date: Sun, 8 Aug 2010 15:54:11 +0000 Subject: igb.txt: Add igb documentation Add documentation for the igb networking driver. v2: - Removed trailing white space - Removed Ethtool version info - Removed LRO kernel version info Signed-off-by: Jeff Kirsher Tested-by: Jeff Pieper Signed-off-by: David S. Miller --- Documentation/networking/igb.txt | 132 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 Documentation/networking/igb.txt (limited to 'Documentation') diff --git a/Documentation/networking/igb.txt b/Documentation/networking/igb.txt new file mode 100644 index 0000000..ab2d718 --- /dev/null +++ b/Documentation/networking/igb.txt @@ -0,0 +1,132 @@ +Linux* Base Driver for Intel(R) Network Connection +================================================== + +Intel Gigabit Linux driver. +Copyright(c) 1999 - 2010 Intel Corporation. + +Contents +======== + +- Identifying Your Adapter +- Additional Configurations +- Support + +Identifying Your Adapter +======================== + +This driver supports all 82575, 82576 and 82580-based Intel (R) gigabit network +connections. + +For specific information on how to identify your adapter, go to the Adapter & +Driver ID Guide at: + + http://support.intel.com/support/go/network/adapter/idguide.htm + +Command Line Parameters +======================= + +The default value for each parameter is generally the recommended setting, +unless otherwise noted. + +max_vfs +------- +Valid Range: 0-7 +Default Value: 0 + +This parameter adds support for SR-IOV. It causes the driver to spawn up to +max_vfs worth of virtual function. + +Additional Configurations +========================= + + Jumbo Frames + ------------ + Jumbo Frames support is enabled by changing the MTU to a value larger than + the default of 1500. Use the ifconfig command to increase the MTU size. + For example: + + ifconfig eth mtu 9000 up + + This setting is not saved across reboots. + + Notes: + + - The maximum MTU setting for Jumbo Frames is 9216. This value coincides + with the maximum Jumbo Frames size of 9234 bytes. + + - Using Jumbo Frames at 10 or 100 Mbps may result in poor performance or + loss of link. + + Ethtool + ------- + The driver utilizes the ethtool interface for driver configuration and + diagnostics, as well as displaying statistical information. + + http://sourceforge.net/projects/gkernel. + + Enabling Wake on LAN* (WoL) + --------------------------- + WoL is configured through the Ethtool* utility. + + For instructions on enabling WoL with Ethtool, refer to the Ethtool man page. + + WoL will be enabled on the system during the next shut down or reboot. + For this driver version, in order to enable WoL, the igb driver must be + loaded when shutting down or rebooting the system. + + Wake On LAN is only supported on port A of multi-port adapters. + + Wake On LAN is not supported for the Intel(R) Gigabit VT Quad Port Server + Adapter. + + Multiqueue + ---------- + In this mode, a separate MSI-X vector is allocated for each queue and one + for "other" interrupts such as link status change and errors. All + interrupts are throttled via interrupt moderation. Interrupt moderation + must be used to avoid interrupt storms while the driver is processing one + interrupt. The moderation value should be at least as large as the expected + time for the driver to process an interrupt. Multiqueue is off by default. + + REQUIREMENTS: MSI-X support is required for Multiqueue. If MSI-X is not + found, the system will fallback to MSI or to Legacy interrupts. + + LRO + --- + Large Receive Offload (LRO) is a technique for increasing inbound throughput + of high-bandwidth network connections by reducing CPU overhead. It works by + aggregating multiple incoming packets from a single stream into a larger + buffer before they are passed higher up the networking stack, thus reducing + the number of packets that have to be processed. LRO combines multiple + Ethernet frames into a single receive in the stack, thereby potentially + decreasing CPU utilization for receives. + + NOTE: You need to have inet_lro enabled via either the CONFIG_INET_LRO or + CONFIG_INET_LRO_MODULE kernel config option. Additionally, if + CONFIG_INET_LRO_MODULE is used, the inet_lro module needs to be loaded + before the igb driver. + + You can verify that the driver is using LRO by looking at these counters in + Ethtool: + + lro_aggregated - count of total packets that were combined + lro_flushed - counts the number of packets flushed out of LRO + lro_no_desc - counts the number of times an LRO descriptor was not available + for the LRO packet + + NOTE: IPv6 and UDP are not supported by LRO. + +Support +======= + +For general information, go to the Intel support website at: + + www.intel.com/support/ + +or the Intel Wired Networking project hosted by Sourceforge at: + + http://sourceforge.net/projects/e1000 + +If an issue is identified with the released source code on the supported +kernel with a supported adapter, email the specific information related +to the issue to e1000-devel@lists.sf.net -- cgit v1.1 From c4e9b56e24422e71424b24eee27c2b134a191d7b Mon Sep 17 00:00:00 2001 From: Jeff Kirsher Date: Sun, 8 Aug 2010 15:54:31 +0000 Subject: igbvf.txt: Add igbvf Documentation Adds documentation for the igbvf (igb virtual function driver). v2: - Removed trailing white space - Removed Ethtool version info Signed-off-by: Jeff Kirsher Tested-by: Jeff Pieper Signed-off-by: David S. Miller --- Documentation/networking/igbvf.txt | 78 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 Documentation/networking/igbvf.txt (limited to 'Documentation') diff --git a/Documentation/networking/igbvf.txt b/Documentation/networking/igbvf.txt new file mode 100644 index 0000000..05602813 --- /dev/null +++ b/Documentation/networking/igbvf.txt @@ -0,0 +1,78 @@ +Linux* Base Driver for Intel(R) Network Connection +================================================== + +Intel Gigabit Linux driver. +Copyright(c) 1999 - 2010 Intel Corporation. + +Contents +======== + +- Identifying Your Adapter +- Additional Configurations +- Support + +This file describes the igbvf Linux* Base Driver for Intel Network Connection. + +The igbvf driver supports 82576-based virtual function devices that can only +be activated on kernels that support SR-IOV. SR-IOV requires the correct +platform and OS support. + +The igbvf driver requires the igb driver, version 2.0 or later. The igbvf +driver supports virtual functions generated by the igb driver with a max_vfs +value of 1 or greater. For more information on the max_vfs parameter refer +to the README included with the igb driver. + +The guest OS loading the igbvf driver must support MSI-X interrupts. + +This driver is only supported as a loadable module at this time. Intel is +not supplying patches against the kernel source to allow for static linking +of the driver. For questions related to hardware requirements, refer to the +documentation supplied with your Intel Gigabit adapter. All hardware +requirements listed apply to use with Linux. + +Instructions on updating ethtool can be found in the section "Additional +Configurations" later in this document. + +VLANs: There is a limit of a total of 32 shared VLANs to 1 or more VFs. + +Identifying Your Adapter +======================== + +The igbvf driver supports 82576-based virtual function devices that can only +be activated on kernels that support SR-IOV. + +For more information on how to identify your adapter, go to the Adapter & +Driver ID Guide at: + + http://support.intel.com/support/go/network/adapter/idguide.htm + +For the latest Intel network drivers for Linux, refer to the following +website. In the search field, enter your adapter name or type, or use the +networking link on the left to search for your adapter: + + http://downloadcenter.intel.com/scripts-df-external/Support_Intel.aspx + +Additional Configurations +========================= + + Ethtool + ------- + The driver utilizes the ethtool interface for driver configuration and + diagnostics, as well as displaying statistical information. + + http://sourceforge.net/projects/gkernel. + +Support +======= + +For general information, go to the Intel support website at: + + http://support.intel.com + +or the Intel Wired Networking project hosted by Sourceforge at: + + http://sourceforge.net/projects/e1000 + +If an issue is identified with the released source code on the supported +kernel with a supported adapter, email the specific information related +to the issue to e1000-devel@lists.sf.net -- cgit v1.1 From 1e2317350971c8b01e6adddc798a00e9bcc1a440 Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Mon, 7 Jun 2010 09:29:20 +0200 Subject: update documentation for the new truncate sequence Signed-off-by: Christoph Hellwig Signed-off-by: Al Viro --- Documentation/filesystems/porting | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index a7e9746..f9547a5 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -273,3 +273,21 @@ it's safe to remove it. If you don't need it, remove it. deliberate; as soon as struct block_device * is propagated in a reasonable way by that code fixing will become trivial; until then nothing can be done. + +[mandatory] + + block truncatation on error exit from ->write_begin, and ->direct_IO +moved from generic methods (block_write_begin, cont_write_begin, +nobh_write_begin, blockdev_direct_IO*) to callers. Take a look at +ext2_write_failed and callers for an example. + +[mandatory] + + ->truncate is going away. The whole truncate sequence needs to be +implemented in ->setattr, which is now mandatory for filesystems +implementing on-disk size changes. Start with a copy of the old inode_setattr +and vmtruncate, and the reorder the vmtruncate + foofs_vmtruncate sequence to +be in order of zeroing blocks using block_truncate_page or similar helpers, +size update and on finally on-disk truncation which should not fail. +inode_change_ok now includes the size checks for ATTR_SIZE and must be called +in the beginning of ->setattr unconditionally. -- cgit v1.1 From 336fb3b97b78edc65bae0b223b83bf676cfe29e2 Mon Sep 17 00:00:00 2001 From: Al Viro Date: Tue, 8 Jun 2010 00:37:12 -0400 Subject: update VFS documentation for method changes. Signed-off-by: Al Viro --- Documentation/filesystems/Locking | 22 ++++++++++++---------- Documentation/filesystems/porting | 27 +++++++++++++++++++++++++++ 2 files changed, 39 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 96d4293..bbcc156 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -92,8 +92,8 @@ prototypes: void (*destroy_inode)(struct inode *); void (*dirty_inode) (struct inode *); int (*write_inode) (struct inode *, int); - void (*drop_inode) (struct inode *); - void (*delete_inode) (struct inode *); + int (*drop_inode) (struct inode *); + void (*evict_inode) (struct inode *); void (*put_super) (struct super_block *); void (*write_super) (struct super_block *); int (*sync_fs)(struct super_block *sb, int wait); @@ -101,14 +101,13 @@ prototypes: int (*unfreeze_fs) (struct super_block *); int (*statfs) (struct dentry *, struct kstatfs *); int (*remount_fs) (struct super_block *, int *, char *); - void (*clear_inode) (struct inode *); void (*umount_begin) (struct super_block *); int (*show_options)(struct seq_file *, struct vfsmount *); ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t); ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t); locking rules: - All may block. + All may block [not true, see below] None have BKL s_umount alloc_inode: @@ -116,22 +115,25 @@ destroy_inode: dirty_inode: (must not sleep) write_inode: drop_inode: !!!inode_lock!!! -delete_inode: +evict_inode: put_super: write write_super: read sync_fs: read freeze_fs: read unfreeze_fs: read -statfs: no -remount_fs: maybe (see below) -clear_inode: +statfs: maybe(read) (see below) +remount_fs: write umount_begin: no show_options: no (namespace_sem) quota_read: no (see below) quota_write: no (see below) -->remount_fs() will have the s_umount exclusive lock if it's already mounted. -When called from get_sb_single, it does NOT have the s_umount lock. +->statfs() has s_umount (shared) when called by ustat(2) (native or +compat), but that's an accident of bad API; s_umount is used to pin +the superblock down when we only have dev_t given us by userland to +identify the superblock. Everything else (statfs(), fstatfs(), etc.) +doesn't hold it when calling ->statfs() - superblock is pinned down +by resolving the pathname passed to syscall. ->quota_read() and ->quota_write() functions are both guaranteed to be the only ones operating on the quota file by the quota code (via dqio_sem) (unless an admin really wants to screw up something and diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index f9547a5..b12c895 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -291,3 +291,30 @@ be in order of zeroing blocks using block_truncate_page or similar helpers, size update and on finally on-disk truncation which should not fail. inode_change_ok now includes the size checks for ATTR_SIZE and must be called in the beginning of ->setattr unconditionally. + +[mandatory] + + ->clear_inode() and ->delete_inode() are gone; ->evict_inode() should +be used instead. It gets called whenever the inode is evicted, whether it has +remaining links or not. Caller does *not* evict the pagecache or inode-associated +metadata buffers; getting rid of those is responsibility of method, as it had +been for ->delete_inode(). + ->drop_inode() returns int now; it's called on final iput() with inode_lock +held and it returns true if filesystems wants the inode to be dropped. As before, +generic_drop_inode() is still the default and it's been updated appropriately. +generic_delete_inode() is also alive and it consists simply of return 1. Note that +all actual eviction work is done by caller after ->drop_inode() returns. + clear_inode() is gone; use end_writeback() instead. As before, it must +be called exactly once on each call of ->evict_inode() (as it used to be for +each call of ->delete_inode()). Unlike before, if you are using inode-associated +metadata buffers (i.e. mark_buffer_dirty_inode()), it's your responsibility to +call invalidate_inode_buffers() before end_writeback(). + No async writeback (and thus no calls of ->write_inode()) will happen +after end_writeback() returns, so actions that should not overlap with ->write_inode() +(e.g. freeing on-disk inode if i_nlink is 0) ought to be done after that call. + + NOTE: checking i_nlink in the beginning of ->write_inode() and bailing out +if it's zero is not *and* *never* *had* *been* enough. Final unlink() and iput() +may happen while the inode is in the middle of ->write_inode(); e.g. if you blindly +free the on-disk inode, you may end up doing that while ->write_inode() is writing +to it. -- cgit v1.1 From d1423d5679875ebbbc2fc63b33d465baceee0430 Mon Sep 17 00:00:00 2001 From: Chris Wright Date: Tue, 20 Jul 2010 11:06:49 -0700 Subject: intr-remap: allow disabling source id checking Allow disabling the source id checking while programming the interrupt remap table entry. Useful for debugging or working around the broken source id checks on some platforms. Signed-off-by: Chris Wright Acked-by: Suresh Siddha Acked-by: Weidong Han Signed-off-by: David Woodhouse --- Documentation/kernel-parameters.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 2b2407d..0afdd28 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1028,6 +1028,12 @@ and is between 256 and 4096 characters. It is defined in the file result in a hardware IOTLB flush operation as opposed to batching them for performance. + intremap= [X86-64, Intel-IOMMU] + Format: { on (default) | off | nosid } + on enable Interrupt Remapping (default) + off disable Interrupt Remapping + nosid disable Source ID checking + inttest= [IA64] iomem= Disable strict checking of access to MMIO memory @@ -1755,6 +1761,7 @@ and is between 256 and 4096 characters. It is defined in the file nointremap [X86-64, Intel-IOMMU] Do not enable interrupt remapping. + [Deprecated - use intremap=off] nointroute [IA-64] -- cgit v1.1 From ad915c432eccb482427c1bbd77c74e6f7bfe60b3 Mon Sep 17 00:00:00 2001 From: David Rientjes Date: Mon, 9 Aug 2010 17:18:53 -0700 Subject: oom: enable oom tasklist dump by default The oom killer tasklist dump, enabled with the oom_dump_tasks sysctl, is very helpful information in diagnosing why a user's task has been killed. It emits useful information such as each eligible thread's memory usage that can determine why the system is oom, so it should be enabled by default. Signed-off-by: David Rientjes Acked-by: KOSAKI Motohiro Cc: KAMEZAWA Hiroyuki Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/sysctl/vm.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index 82b2da1..b606c2c 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -511,7 +511,7 @@ information may not be desired. If this is set to non-zero, this information is shown whenever the OOM killer actually kills a memory-hogging task. -The default value is 0. +The default value is 1 (enabled). ============================================================== -- cgit v1.1 From b898cc70019ce1835bbf6c47bdf978adc36faa42 Mon Sep 17 00:00:00 2001 From: Mel Gorman Date: Mon, 9 Aug 2010 17:19:24 -0700 Subject: vmscan: tracing: add a postprocessing script for reclaim-related ftrace events Add a simple post-processing script for the reclaim-related trace events. It can be used to give an indication of how much traffic there is on the LRU lists and how severe latencies due to reclaim are. Example output looks like the following Reclaim latencies expressed as order-latency_in_ms uname-3942 9-200.179000000004 9-98.7900000000373 9-99.8330000001006 kswapd0-311 0-662.097999999998 0-2.79700000002049 \ 0-149.100000000035 0-3295.73600000003 0-9806.31799999997 0-35528.833 \ 0-10043.197 0-129740.979 0-3.50500000000466 0-3.54899999999907 \ 0-9297.78999999992 0-3.48499999998603 0-3596.97999999998 0-3.92799999995623 \ 0-3.35000000009313 0-16729.017 0-3.57799999997951 0-47435.0630000001 \ 0-3.7819999998901 0-5864.06999999995 0-18635.334 0-10541.289 9-186011.565 \ 9-3680.86300000001 9-1379.06499999994 9-958571.115 9-66215.474 \ 9-6721.14699999988 9-1962.15299999993 9-1094806.125 9-2267.83199999994 \ 9-47120.9029999999 9-427653.886 9-2.6359999999404 9-632.148999999976 \ 9-476.753000000026 9-495.577000000048 9-8.45900000003166 9-6.6820000000298 \ 9-1.30500000016764 9-251.746000000043 9-383.905000000028 9-80.1419999999925 \ 9-281.160000000149 9-14.8780000000261 9-381.45299999998 9-512.07799999998 \ 9-49.5519999999087 9-167.439000000013 9-183.820999999996 9-239.527999999933 \ 9-19.9479999998584 9-148.747999999905 9-164.583000000101 9-16.9480000000913 \ 9-192.376000000164 9-64.1010000000242 9-1.40800000005402 9-3.60800000000745 \ 9-17.1359999999404 9-4.69500000006519 9-2.06400000001304 9-1582488.554 \ 9-6244.19499999983 9-348153.812 9-2.0999999998603 9-0.987999999895692 \ 0-32218.473 0-1.6140000000596 0-1.28100000019185 0-1.41300000017509 \ 0-1.32299999985844 0-602.584000000032 0-1.34400000004098 0-1.6929999999702 \ 1-22101.8190000001 9-174876.724 9-16.2420000000857 9-175.165999999736 \ 9-15.8589999997057 9-0.604999999981374 9-3061.09000000032 9-479.277000000235 \ 9-1.54499999992549 9-771.985000000335 9-4.88700000010431 9-15.0649999999441 \ 9-0.879999999888241 9-252.01500000013 9-1381.03600000031 9-545.689999999944 \ 9-3438.0129999998 9-3343.70099999988 bench-stresshig-3942 9-7063.33900000004 9-129960.482 9-2062.27500000002 \ 9-3845.59399999992 9-171.82799999998 9-16493.821 9-7615.23900000006 \ 9-10217.848 9-983.138000000035 9-2698.39999999991 9-4016.1540000001 \ 9-5522.37700000009 9-21630.429 \ 9-15061.048 9-10327.953 9-542.69700000016 9-317.652000000002 \ 9-8554.71699999995 9-1786.61599999992 9-1899.31499999994 9-2093.41899999999 \ 9-4992.62400000007 9-942.648999999976 9-1923.98300000001 9-3.7980000001844 \ 9-5.99899999983609 9-0.912000000011176 9-1603.67700000014 9-1.98300000000745 \ 9-3.96500000008382 9-0.902999999932945 9-2802.72199999983 9-1078.24799999991 \ 9-2155.82900000014 9-10.058999999892 9-1984.723 9-1687.97999999998 \ 9-1136.05300000007 9-3183.61699999985 9-458.731000000145 9-6.48600000003353 \ 9-1013.25200000009 9-8415.22799999989 9-10065.584 9-2076.79600000009 \ 9-3792.65699999989 9-71.2010000001173 9-2560.96999999997 9-2260.68400000012 \ 9-2862.65799999982 9-1255.81500000018 9-15.7440000001807 9-4.33499999996275 \ 9-1446.63800000004 9-238.635000000009 9-60.1790000000037 9-4.38800000003539 \ 9-639.567000000039 9-306.698000000091 9-31.4070000001229 9-74.997999999905 \ 9-632.725999999791 9-1625.93200000003 9-931.266000000061 9-98.7749999999069 \ 9-984.606999999844 9-225.638999999966 9-421.316000000108 9-653.744999999879 \ 9-572.804000000004 9-769.158999999985 9-603.918000000063 9-4.28499999991618 \ 9-626.21399999992 9-1721.25 9-0.854999999981374 9-572.39599999995 \ 9-681.881999999983 9-1345.12599999993 9-363.666999999899 9-3823.31099999999 \ 9-2991.28200000012 9-4.27099999994971 9-309.76500000013 9-3068.35700000008 \ 9-788.25 9-3515.73999999999 9-2065.96100000013 9-286.719999999972 \ 9-316.076000000117 9-344.151000000071 9-2.51000000000931 9-306.688000000082 \ 9-1515.00099999993 9-336.528999999864 9-793.491999999853 9-457.348999999929 \ 9-13620.155 9-119.933999999892 9-35.0670000000391 9-918.266999999993 \ 9-828.569000000134 9-4863.81099999999 9-105.222000000067 9-894.23900000006 \ 9-110.964999999851 9-0.662999999942258 9-12753.3150000002 9-12.6129999998957 \ 9-13368.0899999999 9-12.4199999999255 9-1.00300000002608 9-1.41100000008009 \ 9-10300.5290000001 9-16.502000000095 9-30.7949999999255 9-6283.0140000002 \ 9-4320.53799999994 9-6826.27300000004 9-3.07299999985844 9-1497.26799999992 \ 9-13.4040000000969 9-3.12999999988824 9-3.86100000003353 9-11.3539999998175 \ 9-0.10799999977462 9-21.780999999959 9-209.695999999996 9-299.647000000114 \ 9-6.01699999999255 9-20.8349999999627 9-22.5470000000205 9-5470.16800000006 \ 9-7.60499999998137 9-0.821000000229105 9-1.56600000010803 9-14.1669999998994 \ 9-0.209000000031665 9-1.82300000009127 9-1.70000000018626 9-19.9429999999702 \ 9-124.266999999993 9-0.0389999998733401 9-6.71400000015274 9-16.7710000001825 \ 9-31.0409999999683 9-0.516999999992549 9-115.888000000035 9-5.19900000002235 \ 9-222.389999999898 9-11.2739999999758 9-80.9050000000279 9-8.14500000001863 \ 9-4.44599999999627 9-0.218999999808148 9-0.715000000083819 9-0.233000000007451 \ 9-48.2630000000354 9-248.560999999987 9-374.96800000011 9-644.179000000004 \ 9-0.835999999893829 9-79.0060000000522 9-128.447999999858 9-0.692000000039116 \ 9-5.26500000013039 9-128.449000000022 9-2.04799999995157 9-12.0990000001621 \ 9-8.39899999997579 9-10.3860000001732 9-11.9310000000987 9-53.4450000000652 \ 9-0.46999999997206 9-2.96299999998882 9-17.9699999999721 9-0.776000000070781 \ 9-25.2919999998994 9-33.1110000000335 9-0.434000000124797 9-0.641000000061467 \ 9-0.505000000121072 9-1.12800000002608 9-149.222000000067 9-1.17599999997765 \ 9-3247.33100000001 9-10.7439999999478 9-153.523000000045 9-1.38300000014715 \ 9-794.762000000104 9-3.36199999996461 9-128.765999999829 9-181.543999999994 \ 9-78149.8229999999 9-176.496999999974 9-89.9940000001807 9-9.12700000009499 \ 9-250.827000000048 9-0.224999999860302 9-0.388999999966472 9-1.16700000036508 \ 9-32.1740000001155 9-12.6800000001676 9-0.0720000001601875 9-0.274999999906868 \ 9-0.724000000394881 9-266.866000000387 9-45.5709999999963 9-4.54399999976158 \ 9-8.27199999988079 9-4.38099999958649 9-0.512000000104308 9-0.0640000002458692 \ 9-5.20000000018626 9-0.0839999997988343 9-12.816000000108 9-0.503000000026077 \ 9-0.507999999914318 9-6.23999999975786 9-3.35100000025705 9-18.8530000001192 \ 9-25.2220000000671 9-68.2309999996796 9-98.9939999999478 9-0.441000000108033 \ 9-4.24599999981001 9-261.702000000048 9-3.01599999982864 9-0.0749999997206032 \ 9-0.0370000000111759 9-4.375 9-3.21800000034273 9-11.3960000001825 \ 9-0.0540000000037253 9-0.286000000312924 9-0.865999999921769 \ 9-0.294999999925494 9-6.45999999996275 9-4.31099999975413 9-128.248999999836 \ 9-0.282999999821186 9-102.155000000261 9-0.0860000001266599 \ 9-0.0540000000037253 9-0.935000000055879 9-0.0670000002719462 \ 9-5.8640000000596 9-19.9860000000335 9-4.18699999991804 9-0.566000000108033 \ 9-2.55099999997765 9-0.702000000048429 9-131.653999999631 9-0.638999999966472 \ 9-14.3229999998584 9-183.398000000045 9-178.095999999903 9-3.22899999981746 \ 9-7.31399999978021 9-22.2400000002235 9-11.7979999999516 9-108.10599999968 \ 9-99.0159999998286 9-102.640999999829 9-38.414000000339 Process Direct Wokeup Pages Pages Pages details Rclms Kswapd Scanned Sync-IO ASync-IO cc1-30800 0 1 0 0 0 wakeup-0=1 cc1-24260 0 1 0 0 0 wakeup-0=1 cc1-24152 0 12 0 0 0 wakeup-0=12 cc1-8139 0 1 0 0 0 wakeup-0=1 cc1-4390 0 1 0 0 0 wakeup-0=1 cc1-4648 0 7 0 0 0 wakeup-0=7 cc1-4552 0 3 0 0 0 wakeup-0=3 dd-4550 0 31 0 0 0 wakeup-0=31 date-4898 0 1 0 0 0 wakeup-0=1 cc1-6549 0 7 0 0 0 wakeup-0=7 as-22202 0 17 0 0 0 wakeup-0=17 cc1-6495 0 9 0 0 0 wakeup-0=9 cc1-8299 0 1 0 0 0 wakeup-0=1 cc1-6009 0 1 0 0 0 wakeup-0=1 cc1-2574 0 2 0 0 0 wakeup-0=2 cc1-30568 0 1 0 0 0 wakeup-0=1 cc1-2679 0 6 0 0 0 wakeup-0=6 sh-13747 0 12 0 0 0 wakeup-0=12 cc1-22193 0 18 0 0 0 wakeup-0=18 cc1-30725 0 2 0 0 0 wakeup-0=2 as-4392 0 2 0 0 0 wakeup-0=2 cc1-28180 0 14 0 0 0 wakeup-0=14 cc1-13697 0 2 0 0 0 wakeup-0=2 cc1-22207 0 8 0 0 0 wakeup-0=8 cc1-15270 0 179 0 0 0 wakeup-0=179 cc1-22011 0 82 0 0 0 wakeup-0=82 cp-14682 0 1 0 0 0 wakeup-0=1 as-11926 0 2 0 0 0 wakeup-0=2 cc1-6016 0 5 0 0 0 wakeup-0=5 make-18554 0 13 0 0 0 wakeup-0=13 cc1-8292 0 12 0 0 0 wakeup-0=12 make-24381 0 1 0 0 0 wakeup-1=1 date-18681 0 33 0 0 0 wakeup-0=33 cc1-32276 0 1 0 0 0 wakeup-0=1 timestamp-outpu-2809 0 253 0 0 0 wakeup-0=240 wakeup-1=13 date-18624 0 7 0 0 0 wakeup-0=7 cc1-30960 0 9 0 0 0 wakeup-0=9 cc1-4014 0 1 0 0 0 wakeup-0=1 cc1-30706 0 22 0 0 0 wakeup-0=22 uname-3942 4 1 306 0 17 direct-9=4 wakeup-9=1 cc1-28207 0 1 0 0 0 wakeup-0=1 cc1-30563 0 9 0 0 0 wakeup-0=9 cc1-22214 0 10 0 0 0 wakeup-0=10 cc1-28221 0 11 0 0 0 wakeup-0=11 cc1-28123 0 6 0 0 0 wakeup-0=6 kswapd0-311 0 7 357302 0 34233 wakeup-0=7 cc1-5988 0 7 0 0 0 wakeup-0=7 as-30734 0 161 0 0 0 wakeup-0=161 cc1-22004 0 45 0 0 0 wakeup-0=45 date-4590 0 4 0 0 0 wakeup-0=4 cc1-15279 0 213 0 0 0 wakeup-0=213 date-30735 0 1 0 0 0 wakeup-0=1 cc1-30583 0 4 0 0 0 wakeup-0=4 cc1-32324 0 2 0 0 0 wakeup-0=2 cc1-23933 0 3 0 0 0 wakeup-0=3 cc1-22001 0 36 0 0 0 wakeup-0=36 bench-stresshig-3942 287 287 80186 6295 12196 direct-9=287 wakeup-9=287 cc1-28170 0 7 0 0 0 wakeup-0=7 date-7932 0 92 0 0 0 wakeup-0=92 cc1-22222 0 6 0 0 0 wakeup-0=6 cc1-32334 0 16 0 0 0 wakeup-0=16 cc1-2690 0 6 0 0 0 wakeup-0=6 cc1-30733 0 9 0 0 0 wakeup-0=9 cc1-32298 0 2 0 0 0 wakeup-0=2 cc1-13743 0 18 0 0 0 wakeup-0=18 cc1-22186 0 4 0 0 0 wakeup-0=4 cc1-28214 0 11 0 0 0 wakeup-0=11 cc1-13735 0 1 0 0 0 wakeup-0=1 updatedb-8173 0 18 0 0 0 wakeup-0=18 cc1-13750 0 3 0 0 0 wakeup-0=3 cat-2808 0 2 0 0 0 wakeup-0=2 cc1-15277 0 169 0 0 0 wakeup-0=169 date-18317 0 1 0 0 0 wakeup-0=1 cc1-15274 0 197 0 0 0 wakeup-0=197 cc1-30732 0 1 0 0 0 wakeup-0=1 Kswapd Kswapd Order Pages Pages Pages Instance Wakeups Re-wakeup Scanned Sync-IO ASync-IO kswapd0-311 91 24 357302 0 34233 wake-0=31 wake-1=1 wake-9=59 rewake-0=10 rewake-1=1 rewake-9=13 Summary Direct reclaims: 291 Direct reclaim pages scanned: 437794 Direct reclaim write sync I/O: 6295 Direct reclaim write async I/O: 46446 Wake kswapd requests: 2152 Time stalled direct reclaim: 519.163009000002 ms Kswapd wakeups: 91 Kswapd pages scanned: 357302 Kswapd reclaim write sync I/O: 0 Kswapd reclaim write async I/O: 34233 Time kswapd awake: 5282.749757 ms Signed-off-by: Mel Gorman Acked-by: Rik van Riel Acked-by: Larry Woodman Cc: Dave Chinner Cc: Chris Mason Cc: Nick Piggin Cc: Rik van Riel Cc: Johannes Weiner Cc: Christoph Hellwig Cc: KAMEZAWA Hiroyuki Cc: KOSAKI Motohiro Cc: Andrea Arcangeli Cc: Michael Rubin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- .../trace/postprocess/trace-vmscan-postprocess.pl | 686 +++++++++++++++++++++ 1 file changed, 686 insertions(+) create mode 100644 Documentation/trace/postprocess/trace-vmscan-postprocess.pl (limited to 'Documentation') diff --git a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl new file mode 100644 index 0000000..1b55146 --- /dev/null +++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl @@ -0,0 +1,686 @@ +#!/usr/bin/perl +# This is a POC for reading the text representation of trace output related to +# page reclaim. It makes an attempt to extract some high-level information on +# what is going on. The accuracy of the parser may vary +# +# Example usage: trace-vmscan-postprocess.pl < /sys/kernel/debug/tracing/trace_pipe +# other options +# --read-procstat If the trace lacks process info, get it from /proc +# --ignore-pid Aggregate processes of the same name together +# +# Copyright (c) IBM Corporation 2009 +# Author: Mel Gorman +use strict; +use Getopt::Long; + +# Tracepoint events +use constant MM_VMSCAN_DIRECT_RECLAIM_BEGIN => 1; +use constant MM_VMSCAN_DIRECT_RECLAIM_END => 2; +use constant MM_VMSCAN_KSWAPD_WAKE => 3; +use constant MM_VMSCAN_KSWAPD_SLEEP => 4; +use constant MM_VMSCAN_LRU_SHRINK_ACTIVE => 5; +use constant MM_VMSCAN_LRU_SHRINK_INACTIVE => 6; +use constant MM_VMSCAN_LRU_ISOLATE => 7; +use constant MM_VMSCAN_WRITEPAGE_FILE_SYNC => 8; +use constant MM_VMSCAN_WRITEPAGE_ANON_SYNC => 9; +use constant MM_VMSCAN_WRITEPAGE_FILE_ASYNC => 10; +use constant MM_VMSCAN_WRITEPAGE_ANON_ASYNC => 11; +use constant MM_VMSCAN_WRITEPAGE_ASYNC => 12; +use constant EVENT_UNKNOWN => 13; + +# Per-order events +use constant MM_VMSCAN_DIRECT_RECLAIM_BEGIN_PERORDER => 11; +use constant MM_VMSCAN_WAKEUP_KSWAPD_PERORDER => 12; +use constant MM_VMSCAN_KSWAPD_WAKE_PERORDER => 13; +use constant HIGH_KSWAPD_REWAKEUP_PERORDER => 14; + +# Constants used to track state +use constant STATE_DIRECT_BEGIN => 15; +use constant STATE_DIRECT_ORDER => 16; +use constant STATE_KSWAPD_BEGIN => 17; +use constant STATE_KSWAPD_ORDER => 18; + +# High-level events extrapolated from tracepoints +use constant HIGH_DIRECT_RECLAIM_LATENCY => 19; +use constant HIGH_KSWAPD_LATENCY => 20; +use constant HIGH_KSWAPD_REWAKEUP => 21; +use constant HIGH_NR_SCANNED => 22; +use constant HIGH_NR_TAKEN => 23; +use constant HIGH_NR_RECLAIM => 24; +use constant HIGH_NR_CONTIG_DIRTY => 25; + +my %perprocesspid; +my %perprocess; +my %last_procmap; +my $opt_ignorepid; +my $opt_read_procstat; + +my $total_wakeup_kswapd; +my ($total_direct_reclaim, $total_direct_nr_scanned); +my ($total_direct_latency, $total_kswapd_latency); +my ($total_direct_writepage_file_sync, $total_direct_writepage_file_async); +my ($total_direct_writepage_anon_sync, $total_direct_writepage_anon_async); +my ($total_kswapd_nr_scanned, $total_kswapd_wake); +my ($total_kswapd_writepage_file_sync, $total_kswapd_writepage_file_async); +my ($total_kswapd_writepage_anon_sync, $total_kswapd_writepage_anon_async); + +# Catch sigint and exit on request +my $sigint_report = 0; +my $sigint_exit = 0; +my $sigint_pending = 0; +my $sigint_received = 0; +sub sigint_handler { + my $current_time = time; + if ($current_time - 2 > $sigint_received) { + print "SIGINT received, report pending. Hit ctrl-c again to exit\n"; + $sigint_report = 1; + } else { + if (!$sigint_exit) { + print "Second SIGINT received quickly, exiting\n"; + } + $sigint_exit++; + } + + if ($sigint_exit > 3) { + print "Many SIGINTs received, exiting now without report\n"; + exit; + } + + $sigint_received = $current_time; + $sigint_pending = 1; +} +$SIG{INT} = "sigint_handler"; + +# Parse command line options +GetOptions( + 'ignore-pid' => \$opt_ignorepid, + 'read-procstat' => \$opt_read_procstat, +); + +# Defaults for dynamically discovered regex's +my $regex_direct_begin_default = 'order=([0-9]*) may_writepage=([0-9]*) gfp_flags=([A-Z_|]*)'; +my $regex_direct_end_default = 'nr_reclaimed=([0-9]*)'; +my $regex_kswapd_wake_default = 'nid=([0-9]*) order=([0-9]*)'; +my $regex_kswapd_sleep_default = 'nid=([0-9]*)'; +my $regex_wakeup_kswapd_default = 'nid=([0-9]*) zid=([0-9]*) order=([0-9]*)'; +my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_taken=([0-9]*) contig_taken=([0-9]*) contig_dirty=([0-9]*) contig_failed=([0-9]*)'; +my $regex_lru_shrink_inactive_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) priority=([0-9]*)'; +my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) nr_rotated=([0-9]*) priority=([0-9]*)'; +my $regex_writepage_default = 'page=([0-9a-f]*) pfn=([0-9]*) flags=([A-Z_|]*)'; + +# Dyanically discovered regex +my $regex_direct_begin; +my $regex_direct_end; +my $regex_kswapd_wake; +my $regex_kswapd_sleep; +my $regex_wakeup_kswapd; +my $regex_lru_isolate; +my $regex_lru_shrink_inactive; +my $regex_lru_shrink_active; +my $regex_writepage; + +# Static regex used. Specified like this for readability and for use with /o +# (process_pid) (cpus ) ( time ) (tpoint ) (details) +my $regex_traceevent = '\s*([a-zA-Z0-9-]*)\s*(\[[0-9]*\])\s*([0-9.]*):\s*([a-zA-Z_]*):\s*(.*)'; +my $regex_statname = '[-0-9]*\s\((.*)\).*'; +my $regex_statppid = '[-0-9]*\s\(.*\)\s[A-Za-z]\s([0-9]*).*'; + +sub generate_traceevent_regex { + my $event = shift; + my $default = shift; + my $regex; + + # Read the event format or use the default + if (!open (FORMAT, "/sys/kernel/debug/tracing/events/$event/format")) { + print("WARNING: Event $event format string not found\n"); + return $default; + } else { + my $line; + while (!eof(FORMAT)) { + $line = ; + $line =~ s/, REC->.*//; + if ($line =~ /^print fmt:\s"(.*)".*/) { + $regex = $1; + $regex =~ s/%s/\([0-9a-zA-Z|_]*\)/g; + $regex =~ s/%p/\([0-9a-f]*\)/g; + $regex =~ s/%d/\([-0-9]*\)/g; + $regex =~ s/%ld/\([-0-9]*\)/g; + $regex =~ s/%lu/\([0-9]*\)/g; + } + } + } + + # Can't handle the print_flags stuff but in the context of this + # script, it really doesn't matter + $regex =~ s/\(REC.*\) \? __print_flags.*//; + + # Verify fields are in the right order + my $tuple; + foreach $tuple (split /\s/, $regex) { + my ($key, $value) = split(/=/, $tuple); + my $expected = shift; + if ($key ne $expected) { + print("WARNING: Format not as expected for event $event '$key' != '$expected'\n"); + $regex =~ s/$key=\((.*)\)/$key=$1/; + } + } + + if (defined shift) { + die("Fewer fields than expected in format"); + } + + return $regex; +} + +$regex_direct_begin = generate_traceevent_regex( + "vmscan/mm_vmscan_direct_reclaim_begin", + $regex_direct_begin_default, + "order", "may_writepage", + "gfp_flags"); +$regex_direct_end = generate_traceevent_regex( + "vmscan/mm_vmscan_direct_reclaim_end", + $regex_direct_end_default, + "nr_reclaimed"); +$regex_kswapd_wake = generate_traceevent_regex( + "vmscan/mm_vmscan_kswapd_wake", + $regex_kswapd_wake_default, + "nid", "order"); +$regex_kswapd_sleep = generate_traceevent_regex( + "vmscan/mm_vmscan_kswapd_sleep", + $regex_kswapd_sleep_default, + "nid"); +$regex_wakeup_kswapd = generate_traceevent_regex( + "vmscan/mm_vmscan_wakeup_kswapd", + $regex_wakeup_kswapd_default, + "nid", "zid", "order"); +$regex_lru_isolate = generate_traceevent_regex( + "vmscan/mm_vmscan_lru_isolate", + $regex_lru_isolate_default, + "isolate_mode", "order", + "nr_requested", "nr_scanned", "nr_taken", + "contig_taken", "contig_dirty", "contig_failed"); +$regex_lru_shrink_inactive = generate_traceevent_regex( + "vmscan/mm_vmscan_lru_shrink_inactive", + $regex_lru_shrink_inactive_default, + "nid", "zid", + "lru", + "nr_scanned", "nr_reclaimed", "priority"); +$regex_lru_shrink_active = generate_traceevent_regex( + "vmscan/mm_vmscan_lru_shrink_active", + $regex_lru_shrink_active_default, + "nid", "zid", + "lru", + "nr_scanned", "nr_rotated", "priority"); +$regex_writepage = generate_traceevent_regex( + "vmscan/mm_vmscan_writepage", + $regex_writepage_default, + "page", "pfn", "flags"); + +sub read_statline($) { + my $pid = $_[0]; + my $statline; + + if (open(STAT, "/proc/$pid/stat")) { + $statline = ; + close(STAT); + } + + if ($statline eq '') { + $statline = "-1 (UNKNOWN_PROCESS_NAME) R 0"; + } + + return $statline; +} + +sub guess_process_pid($$) { + my $pid = $_[0]; + my $statline = $_[1]; + + if ($pid == 0) { + return "swapper-0"; + } + + if ($statline !~ /$regex_statname/o) { + die("Failed to math stat line for process name :: $statline"); + } + return "$1-$pid"; +} + +# Convert sec.usec timestamp format +sub timestamp_to_ms($) { + my $timestamp = $_[0]; + + my ($sec, $usec) = split (/\./, $timestamp); + return ($sec * 1000) + ($usec / 1000); +} + +sub process_events { + my $traceevent; + my $process_pid; + my $cpus; + my $timestamp; + my $tracepoint; + my $details; + my $statline; + + # Read each line of the event log +EVENT_PROCESS: + while ($traceevent = ) { + if ($traceevent =~ /$regex_traceevent/o) { + $process_pid = $1; + $timestamp = $3; + $tracepoint = $4; + + $process_pid =~ /(.*)-([0-9]*)$/; + my $process = $1; + my $pid = $2; + + if ($process eq "") { + $process = $last_procmap{$pid}; + $process_pid = "$process-$pid"; + } + $last_procmap{$pid} = $process; + + if ($opt_read_procstat) { + $statline = read_statline($pid); + if ($opt_read_procstat && $process eq '') { + $process_pid = guess_process_pid($pid, $statline); + } + } + } else { + next; + } + + # Perl Switch() sucks majorly + if ($tracepoint eq "mm_vmscan_direct_reclaim_begin") { + $timestamp = timestamp_to_ms($timestamp); + $perprocesspid{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}++; + $perprocesspid{$process_pid}->{STATE_DIRECT_BEGIN} = $timestamp; + + $details = $5; + if ($details !~ /$regex_direct_begin/o) { + print "WARNING: Failed to parse mm_vmscan_direct_reclaim_begin as expected\n"; + print " $details\n"; + print " $regex_direct_begin\n"; + next; + } + my $order = $1; + $perprocesspid{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN_PERORDER}[$order]++; + $perprocesspid{$process_pid}->{STATE_DIRECT_ORDER} = $order; + } elsif ($tracepoint eq "mm_vmscan_direct_reclaim_end") { + # Count the event itself + my $index = $perprocesspid{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_END}; + $perprocesspid{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_END}++; + + # Record how long direct reclaim took this time + if (defined $perprocesspid{$process_pid}->{STATE_DIRECT_BEGIN}) { + $timestamp = timestamp_to_ms($timestamp); + my $order = $perprocesspid{$process_pid}->{STATE_DIRECT_ORDER}; + my $latency = ($timestamp - $perprocesspid{$process_pid}->{STATE_DIRECT_BEGIN}); + $perprocesspid{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$index] = "$order-$latency"; + } + } elsif ($tracepoint eq "mm_vmscan_kswapd_wake") { + $details = $5; + if ($details !~ /$regex_kswapd_wake/o) { + print "WARNING: Failed to parse mm_vmscan_kswapd_wake as expected\n"; + print " $details\n"; + print " $regex_kswapd_wake\n"; + next; + } + + my $order = $2; + $perprocesspid{$process_pid}->{STATE_KSWAPD_ORDER} = $order; + if (!$perprocesspid{$process_pid}->{STATE_KSWAPD_BEGIN}) { + $timestamp = timestamp_to_ms($timestamp); + $perprocesspid{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}++; + $perprocesspid{$process_pid}->{STATE_KSWAPD_BEGIN} = $timestamp; + $perprocesspid{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE_PERORDER}[$order]++; + } else { + $perprocesspid{$process_pid}->{HIGH_KSWAPD_REWAKEUP}++; + $perprocesspid{$process_pid}->{HIGH_KSWAPD_REWAKEUP_PERORDER}[$order]++; + } + } elsif ($tracepoint eq "mm_vmscan_kswapd_sleep") { + + # Count the event itself + my $index = $perprocesspid{$process_pid}->{MM_VMSCAN_KSWAPD_SLEEP}; + $perprocesspid{$process_pid}->{MM_VMSCAN_KSWAPD_SLEEP}++; + + # Record how long kswapd was awake + $timestamp = timestamp_to_ms($timestamp); + my $order = $perprocesspid{$process_pid}->{STATE_KSWAPD_ORDER}; + my $latency = ($timestamp - $perprocesspid{$process_pid}->{STATE_KSWAPD_BEGIN}); + $perprocesspid{$process_pid}->{HIGH_KSWAPD_LATENCY}[$index] = "$order-$latency"; + $perprocesspid{$process_pid}->{STATE_KSWAPD_BEGIN} = 0; + } elsif ($tracepoint eq "mm_vmscan_wakeup_kswapd") { + $perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}++; + + $details = $5; + if ($details !~ /$regex_wakeup_kswapd/o) { + print "WARNING: Failed to parse mm_vmscan_wakeup_kswapd as expected\n"; + print " $details\n"; + print " $regex_wakeup_kswapd\n"; + next; + } + my $order = $3; + $perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD_PERORDER}[$order]++; + } elsif ($tracepoint eq "mm_vmscan_lru_isolate") { + $details = $5; + if ($details !~ /$regex_lru_isolate/o) { + print "WARNING: Failed to parse mm_vmscan_lru_isolate as expected\n"; + print " $details\n"; + print " $regex_lru_isolate/o\n"; + next; + } + my $nr_scanned = $4; + my $nr_contig_dirty = $7; + $perprocesspid{$process_pid}->{HIGH_NR_SCANNED} += $nr_scanned; + $perprocesspid{$process_pid}->{HIGH_NR_CONTIG_DIRTY} += $nr_contig_dirty; + } elsif ($tracepoint eq "mm_vmscan_writepage") { + $details = $5; + if ($details !~ /$regex_writepage/o) { + print "WARNING: Failed to parse mm_vmscan_writepage as expected\n"; + print " $details\n"; + print " $regex_writepage\n"; + next; + } + + my $flags = $3; + my $file = 0; + my $sync_io = 0; + if ($flags =~ /RECLAIM_WB_FILE/) { + $file = 1; + } + if ($flags =~ /RECLAIM_WB_SYNC/) { + $sync_io = 1; + } + if ($sync_io) { + if ($file) { + $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC}++; + } else { + $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}++; + } + } else { + if ($file) { + $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC}++; + } else { + $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}++; + } + } + } else { + $perprocesspid{$process_pid}->{EVENT_UNKNOWN}++; + } + + if ($sigint_pending) { + last EVENT_PROCESS; + } + } +} + +sub dump_stats { + my $hashref = shift; + my %stats = %$hashref; + + # Dump per-process stats + my $process_pid; + my $max_strlen = 0; + + # Get the maximum process name + foreach $process_pid (keys %perprocesspid) { + my $len = length($process_pid); + if ($len > $max_strlen) { + $max_strlen = $len; + } + } + $max_strlen += 2; + + # Work out latencies + printf("\n") if !$opt_ignorepid; + printf("Reclaim latencies expressed as order-latency_in_ms\n") if !$opt_ignorepid; + foreach $process_pid (keys %stats) { + + if (!$stats{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[0] && + !$stats{$process_pid}->{HIGH_KSWAPD_LATENCY}[0]) { + next; + } + + printf "%-" . $max_strlen . "s ", $process_pid if !$opt_ignorepid; + my $index = 0; + while (defined $stats{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$index] || + defined $stats{$process_pid}->{HIGH_KSWAPD_LATENCY}[$index]) { + + if ($stats{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$index]) { + printf("%s ", $stats{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$index]) if !$opt_ignorepid; + my ($dummy, $latency) = split(/-/, $stats{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$index]); + $total_direct_latency += $latency; + } else { + printf("%s ", $stats{$process_pid}->{HIGH_KSWAPD_LATENCY}[$index]) if !$opt_ignorepid; + my ($dummy, $latency) = split(/-/, $stats{$process_pid}->{HIGH_KSWAPD_LATENCY}[$index]); + $total_kswapd_latency += $latency; + } + $index++; + } + print "\n" if !$opt_ignorepid; + } + + # Print out process activity + printf("\n"); + printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s %8s\n", "Process", "Direct", "Wokeup", "Pages", "Pages", "Pages", "Time"); + printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s %8s\n", "details", "Rclms", "Kswapd", "Scanned", "Sync-IO", "ASync-IO", "Stalled"); + foreach $process_pid (keys %stats) { + + if (!$stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}) { + next; + } + + $total_direct_reclaim += $stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}; + $total_wakeup_kswapd += $stats{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}; + $total_direct_nr_scanned += $stats{$process_pid}->{HIGH_NR_SCANNED}; + $total_direct_writepage_file_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC}; + $total_direct_writepage_anon_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}; + $total_direct_writepage_file_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC}; + + $total_direct_writepage_anon_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}; + + my $index = 0; + my $this_reclaim_delay = 0; + while (defined $stats{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$index]) { + my ($dummy, $latency) = split(/-/, $stats{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$index]); + $this_reclaim_delay += $latency; + $index++; + } + + printf("%-" . $max_strlen . "s %8d %10d %8u %8u %8u %8.3f", + $process_pid, + $stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}, + $stats{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}, + $stats{$process_pid}->{HIGH_NR_SCANNED}, + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}, + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}, + $this_reclaim_delay / 1000); + + if ($stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}) { + print " "; + for (my $order = 0; $order < 20; $order++) { + my $count = $stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN_PERORDER}[$order]; + if ($count != 0) { + print "direct-$order=$count "; + } + } + } + if ($stats{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}) { + print " "; + for (my $order = 0; $order < 20; $order++) { + my $count = $stats{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD_PERORDER}[$order]; + if ($count != 0) { + print "wakeup-$order=$count "; + } + } + } + if ($stats{$process_pid}->{HIGH_NR_CONTIG_DIRTY}) { + print " "; + my $count = $stats{$process_pid}->{HIGH_NR_CONTIG_DIRTY}; + if ($count != 0) { + print "contig-dirty=$count "; + } + } + + print "\n"; + } + + # Print out kswapd activity + printf("\n"); + printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s\n", "Kswapd", "Kswapd", "Order", "Pages", "Pages", "Pages"); + printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s\n", "Instance", "Wakeups", "Re-wakeup", "Scanned", "Sync-IO", "ASync-IO"); + foreach $process_pid (keys %stats) { + + if (!$stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}) { + next; + } + + $total_kswapd_wake += $stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}; + $total_kswapd_nr_scanned += $stats{$process_pid}->{HIGH_NR_SCANNED}; + $total_kswapd_writepage_file_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC}; + $total_kswapd_writepage_anon_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}; + $total_kswapd_writepage_file_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC}; + $total_kswapd_writepage_anon_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}; + + printf("%-" . $max_strlen . "s %8d %10d %8u %8i %8u", + $process_pid, + $stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}, + $stats{$process_pid}->{HIGH_KSWAPD_REWAKEUP}, + $stats{$process_pid}->{HIGH_NR_SCANNED}, + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}, + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}); + + if ($stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}) { + print " "; + for (my $order = 0; $order < 20; $order++) { + my $count = $stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE_PERORDER}[$order]; + if ($count != 0) { + print "wake-$order=$count "; + } + } + } + if ($stats{$process_pid}->{HIGH_KSWAPD_REWAKEUP}) { + print " "; + for (my $order = 0; $order < 20; $order++) { + my $count = $stats{$process_pid}->{HIGH_KSWAPD_REWAKEUP_PERORDER}[$order]; + if ($count != 0) { + print "rewake-$order=$count "; + } + } + } + printf("\n"); + } + + # Print out summaries + $total_direct_latency /= 1000; + $total_kswapd_latency /= 1000; + print "\nSummary\n"; + print "Direct reclaims: $total_direct_reclaim\n"; + print "Direct reclaim pages scanned: $total_direct_nr_scanned\n"; + print "Direct reclaim write file sync I/O: $total_direct_writepage_file_sync\n"; + print "Direct reclaim write anon sync I/O: $total_direct_writepage_anon_sync\n"; + print "Direct reclaim write file async I/O: $total_direct_writepage_file_async\n"; + print "Direct reclaim write anon async I/O: $total_direct_writepage_anon_async\n"; + print "Wake kswapd requests: $total_wakeup_kswapd\n"; + printf "Time stalled direct reclaim: %-1.2f seconds\n", $total_direct_latency; + print "\n"; + print "Kswapd wakeups: $total_kswapd_wake\n"; + print "Kswapd pages scanned: $total_kswapd_nr_scanned\n"; + print "Kswapd reclaim write file sync I/O: $total_kswapd_writepage_file_sync\n"; + print "Kswapd reclaim write anon sync I/O: $total_kswapd_writepage_anon_sync\n"; + print "Kswapd reclaim write file async I/O: $total_kswapd_writepage_file_async\n"; + print "Kswapd reclaim write anon async I/O: $total_kswapd_writepage_anon_async\n"; + printf "Time kswapd awake: %-1.2f seconds\n", $total_kswapd_latency; +} + +sub aggregate_perprocesspid() { + my $process_pid; + my $process; + undef %perprocess; + + foreach $process_pid (keys %perprocesspid) { + $process = $process_pid; + $process =~ s/-([0-9])*$//; + if ($process eq '') { + $process = "NO_PROCESS_NAME"; + } + + $perprocess{$process}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN} += $perprocesspid{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}; + $perprocess{$process}->{MM_VMSCAN_KSWAPD_WAKE} += $perprocesspid{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}; + $perprocess{$process}->{MM_VMSCAN_WAKEUP_KSWAPD} += $perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}; + $perprocess{$process}->{HIGH_KSWAPD_REWAKEUP} += $perprocesspid{$process_pid}->{HIGH_KSWAPD_REWAKEUP}; + $perprocess{$process}->{HIGH_NR_SCANNED} += $perprocesspid{$process_pid}->{HIGH_NR_SCANNED}; + $perprocess{$process}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC}; + $perprocess{$process}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}; + $perprocess{$process}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC}; + $perprocess{$process}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}; + + for (my $order = 0; $order < 20; $order++) { + $perprocess{$process}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN_PERORDER}[$order] += $perprocesspid{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN_PERORDER}[$order]; + $perprocess{$process}->{MM_VMSCAN_WAKEUP_KSWAPD_PERORDER}[$order] += $perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD_PERORDER}[$order]; + $perprocess{$process}->{MM_VMSCAN_KSWAPD_WAKE_PERORDER}[$order] += $perprocesspid{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE_PERORDER}[$order]; + + } + + # Aggregate direct reclaim latencies + my $wr_index = $perprocess{$process}->{MM_VMSCAN_DIRECT_RECLAIM_END}; + my $rd_index = 0; + while (defined $perprocesspid{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$rd_index]) { + $perprocess{$process}->{HIGH_DIRECT_RECLAIM_LATENCY}[$wr_index] = $perprocesspid{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$rd_index]; + $rd_index++; + $wr_index++; + } + $perprocess{$process}->{MM_VMSCAN_DIRECT_RECLAIM_END} = $wr_index; + + # Aggregate kswapd latencies + my $wr_index = $perprocess{$process}->{MM_VMSCAN_KSWAPD_SLEEP}; + my $rd_index = 0; + while (defined $perprocesspid{$process_pid}->{HIGH_KSWAPD_LATENCY}[$rd_index]) { + $perprocess{$process}->{HIGH_KSWAPD_LATENCY}[$wr_index] = $perprocesspid{$process_pid}->{HIGH_KSWAPD_LATENCY}[$rd_index]; + $rd_index++; + $wr_index++; + } + $perprocess{$process}->{MM_VMSCAN_DIRECT_RECLAIM_END} = $wr_index; + } +} + +sub report() { + if (!$opt_ignorepid) { + dump_stats(\%perprocesspid); + } else { + aggregate_perprocesspid(); + dump_stats(\%perprocess); + } +} + +# Process events or signals until neither is available +sub signal_loop() { + my $sigint_processed; + do { + $sigint_processed = 0; + process_events(); + + # Handle pending signals if any + if ($sigint_pending) { + my $current_time = time; + + if ($sigint_exit) { + print "Received exit signal\n"; + $sigint_pending = 0; + } + if ($sigint_report) { + if ($current_time >= $sigint_received + 2) { + report(); + $sigint_report = 0; + $sigint_pending = 0; + $sigint_processed = 1; + } + } + } + } while ($sigint_pending || $sigint_processed); +} + +signal_loop(); +report(); -- cgit v1.1 From a63d83f427fbce97a6cea0db2e64b0eb8435cd10 Mon Sep 17 00:00:00 2001 From: David Rientjes Date: Mon, 9 Aug 2010 17:19:46 -0700 Subject: oom: badness heuristic rewrite This a complete rewrite of the oom killer's badness() heuristic which is used to determine which task to kill in oom conditions. The goal is to make it as simple and predictable as possible so the results are better understood and we end up killing the task which will lead to the most memory freeing while still respecting the fine-tuning from userspace. Instead of basing the heuristic on mm->total_vm for each task, the task's rss and swap space is used instead. This is a better indication of the amount of memory that will be freeable if the oom killed task is chosen and subsequently exits. This helps specifically in cases where KDE or GNOME is chosen for oom kill on desktop systems instead of a memory hogging task. The baseline for the heuristic is a proportion of memory that each task is currently using in memory plus swap compared to the amount of "allowable" memory. "Allowable," in this sense, means the system-wide resources for unconstrained oom conditions, the set of mempolicy nodes, the mems attached to current's cpuset, or a memory controller's limit. The proportion is given on a scale of 0 (never kill) to 1000 (always kill), roughly meaning that if a task has a badness() score of 500 that the task consumes approximately 50% of allowable memory resident in RAM or in swap space. The proportion is always relative to the amount of "allowable" memory and not the total amount of RAM systemwide so that mempolicies and cpusets may operate in isolation; they shall not need to know the true size of the machine on which they are running if they are bound to a specific set of nodes or mems, respectively. Root tasks are given 3% extra memory just like __vm_enough_memory() provides in LSMs. In the event of two tasks consuming similar amounts of memory, it is generally better to save root's task. Because of the change in the badness() heuristic's baseline, it is also necessary to introduce a new user interface to tune it. It's not possible to redefine the meaning of /proc/pid/oom_adj with a new scale since the ABI cannot be changed for backward compatability. Instead, a new tunable, /proc/pid/oom_score_adj, is added that ranges from -1000 to +1000. It may be used to polarize the heuristic such that certain tasks are never considered for oom kill while others may always be considered. The value is added directly into the badness() score so a value of -500, for example, means to discount 50% of its memory consumption in comparison to other tasks either on the system, bound to the mempolicy, in the cpuset, or sharing the same memory controller. /proc/pid/oom_adj is changed so that its meaning is rescaled into the units used by /proc/pid/oom_score_adj, and vice versa. Changing one of these per-task tunables will rescale the value of the other to an equivalent meaning. Although /proc/pid/oom_adj was originally defined as a bitshift on the badness score, it now shares the same linear growth as /proc/pid/oom_score_adj but with different granularity. This is required so the ABI is not broken with userspace applications and allows oom_adj to be deprecated for future removal. Signed-off-by: David Rientjes Cc: Nick Piggin Cc: KAMEZAWA Hiroyuki Cc: KOSAKI Motohiro Cc: Oleg Nesterov Cc: Balbir Singh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/proc.txt | 94 +++++++++++++++++++++++--------------- 1 file changed, 57 insertions(+), 37 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 8fe8895..cf1295c 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -33,7 +33,8 @@ Table of Contents 2 Modifying System Parameters 3 Per-Process Parameters - 3.1 /proc//oom_adj - Adjust the oom-killer score + 3.1 /proc//oom_adj & /proc//oom_score_adj - Adjust the oom-killer + score 3.2 /proc//oom_score - Display current oom-killer score 3.3 /proc//io - Display the IO accounting fields 3.4 /proc//coredump_filter - Core dump filtering settings @@ -1234,42 +1235,61 @@ of the kernel. CHAPTER 3: PER-PROCESS PARAMETERS ------------------------------------------------------------------------------ -3.1 /proc//oom_adj - Adjust the oom-killer score ------------------------------------------------------- - -This file can be used to adjust the score used to select which processes -should be killed in an out-of-memory situation. Giving it a high score will -increase the likelihood of this process being killed by the oom-killer. Valid -values are in the range -16 to +15, plus the special value -17, which disables -oom-killing altogether for this process. - -The process to be killed in an out-of-memory situation is selected among all others -based on its badness score. This value equals the original memory size of the process -and is then updated according to its CPU time (utime + stime) and the -run time (uptime - start time). The longer it runs the smaller is the score. -Badness score is divided by the square root of the CPU time and then by -the double square root of the run time. - -Swapped out tasks are killed first. Half of each child's memory size is added to -the parent's score if they do not share the same memory. Thus forking servers -are the prime candidates to be killed. Having only one 'hungry' child will make -parent less preferable than the child. - -/proc//oom_score shows process' current badness score. - -The following heuristics are then applied: - * if the task was reniced, its score doubles - * superuser or direct hardware access tasks (CAP_SYS_ADMIN, CAP_SYS_RESOURCE - or CAP_SYS_RAWIO) have their score divided by 4 - * if oom condition happened in one cpuset and checked process does not belong - to it, its score is divided by 8 - * the resulting score is multiplied by two to the power of oom_adj, i.e. - points <<= oom_adj when it is positive and - points >>= -(oom_adj) otherwise - -The task with the highest badness score is then selected and its children -are killed, process itself will be killed in an OOM situation when it does -not have children or some of them disabled oom like described above. +3.1 /proc//oom_adj & /proc//oom_score_adj- Adjust the oom-killer score +-------------------------------------------------------------------------------- + +These file can be used to adjust the badness heuristic used to select which +process gets killed in out of memory conditions. + +The badness heuristic assigns a value to each candidate task ranging from 0 +(never kill) to 1000 (always kill) to determine which process is targeted. The +units are roughly a proportion along that range of allowed memory the process +may allocate from based on an estimation of its current memory and swap use. +For example, if a task is using all allowed memory, its badness score will be +1000. If it is using half of its allowed memory, its score will be 500. + +There is an additional factor included in the badness score: root +processes are given 3% extra memory over other tasks. + +The amount of "allowed" memory depends on the context in which the oom killer +was called. If it is due to the memory assigned to the allocating task's cpuset +being exhausted, the allowed memory represents the set of mems assigned to that +cpuset. If it is due to a mempolicy's node(s) being exhausted, the allowed +memory represents the set of mempolicy nodes. If it is due to a memory +limit (or swap limit) being reached, the allowed memory is that configured +limit. Finally, if it is due to the entire system being out of memory, the +allowed memory represents all allocatable resources. + +The value of /proc//oom_score_adj is added to the badness score before it +is used to determine which task to kill. Acceptable values range from -1000 +(OOM_SCORE_ADJ_MIN) to +1000 (OOM_SCORE_ADJ_MAX). This allows userspace to +polarize the preference for oom killing either by always preferring a certain +task or completely disabling it. The lowest possible value, -1000, is +equivalent to disabling oom killing entirely for that task since it will always +report a badness score of 0. + +Consequently, it is very simple for userspace to define the amount of memory to +consider for each task. Setting a /proc//oom_score_adj value of +500, for +example, is roughly equivalent to allowing the remainder of tasks sharing the +same system, cpuset, mempolicy, or memory controller resources to use at least +50% more memory. A value of -500, on the other hand, would be roughly +equivalent to discounting 50% of the task's allowed memory from being considered +as scoring against the task. + +For backwards compatibility with previous kernels, /proc//oom_adj may also +be used to tune the badness score. Its acceptable values range from -16 +(OOM_ADJUST_MIN) to +15 (OOM_ADJUST_MAX) and a special value of -17 +(OOM_DISABLE) to disable oom killing entirely for that task. Its value is +scaled linearly with /proc//oom_score_adj. + +Writing to /proc//oom_score_adj or /proc//oom_adj will change the +other with its scaled value. + +Caveat: when a parent task is selected, the oom killer will sacrifice any first +generation children with seperate address spaces instead, if possible. This +avoids servers and important system daemons from being killed and loses the +minimal amount of work. + 3.2 /proc//oom_score - Display current oom-killer score ------------------------------------------------------------- -- cgit v1.1 From 51b1bd2ace1595b72956224deda349efa880b693 Mon Sep 17 00:00:00 2001 From: David Rientjes Date: Mon, 9 Aug 2010 17:19:47 -0700 Subject: oom: deprecate oom_adj tunable /proc/pid/oom_adj is now deprecated so that that it may eventually be removed. The target date for removal is August 2012. A warning will be printed to the kernel log if a task attempts to use this interface. Future warning will be suppressed until the kernel is rebooted to prevent spamming the kernel log. Signed-off-by: David Rientjes Cc: Nick Piggin Cc: KAMEZAWA Hiroyuki Cc: KOSAKI Motohiro Cc: Oleg Nesterov Cc: Balbir Singh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/feature-removal-schedule.txt | 25 +++++++++++++++++++++++++ Documentation/filesystems/proc.txt | 3 +++ 2 files changed, 28 insertions(+) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 71f0fea..56cee47 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -151,6 +151,31 @@ Who: Eric Biederman --------------------------- +What: /proc//oom_adj +When: August 2012 +Why: /proc//oom_adj allows userspace to influence the oom killer's + badness heuristic used to determine which task to kill when the kernel + is out of memory. + + The badness heuristic has since been rewritten since the introduction of + this tunable such that its meaning is deprecated. The value was + implemented as a bitshift on a score generated by the badness() + function that did not have any precise units of measure. With the + rewrite, the score is given as a proportion of available memory to the + task allocating pages, so using a bitshift which grows the score + exponentially is, thus, impossible to tune with fine granularity. + + A much more powerful interface, /proc//oom_score_adj, was + introduced with the oom killer rewrite that allows users to increase or + decrease the badness() score linearly. This interface will replace + /proc//oom_adj. + + A warning will be emitted to the kernel log if an application uses this + deprecated interface. After it is printed once, future warnings will be + suppressed until the kernel is rebooted. + +--------------------------- + What: remove EXPORT_SYMBOL(kernel_thread) When: August 2006 Files: arch/*/kernel/*_ksyms.c diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index cf1295c..a6aca87 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -1285,6 +1285,9 @@ scaled linearly with /proc//oom_score_adj. Writing to /proc//oom_score_adj or /proc//oom_adj will change the other with its scaled value. +NOTICE: /proc//oom_adj is deprecated and will be removed, please see +Documentation/feature-removal-schedule.txt. + Caveat: when a parent task is selected, the oom killer will sacrifice any first generation children with seperate address spaces instead, if possible. This avoids servers and important system daemons from being killed and loses the -- cgit v1.1 From d89b1945b760a6e0e887da004d68432c0bff899a Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Mon, 9 Aug 2010 17:20:21 -0700 Subject: SubmittingPatches: add more about patch descriptions Add more information about patch descriptions. Signed-off-by: Randy Dunlap Reviewed-by: Christoph Lameter Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/SubmittingPatches | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 72651f7..689e237 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -98,6 +98,17 @@ system, git, as a "commit log". See #15, below. If your description starts to get long, that's a sign that you probably need to split up your patch. See #3, next. +When you submit or resubmit a patch or patch series, include the +complete patch description and justification for it. Don't just +say that this is version N of the patch (series). Don't expect the +patch merger to refer back to earlier patch versions or referenced +URLs to find the patch description and put that into the patch. +I.e., the patch (series) and its description should be self-contained. +This benefits both the patch merger(s) and reviewers. Some reviewers +probably didn't even receive earlier versions of the patch. + +If the patch fixes a logged bug entry, refer to that bug entry by +number and URL. 3) Separate your changes. -- cgit v1.1 From 5bf1d290b57e392eaf4bfb15c67f315fce4140be Mon Sep 17 00:00:00 2001 From: Christoph Mair Date: Mon, 9 Aug 2010 17:20:28 -0700 Subject: drivers/misc: support for the pressure sensor BMP085 from Bosch Sensortec This driver adds support for the BMP085 digital pressure sensor from Bosch Sensortec. It exposes a sysfs api to userspace where pressure and temperature measurement results can be read from the pressure0_input and temp0_input file. The chip is able to calculate the average of up to eight samples to increase the accuracy. This feature can be controlled by writing to the oversampling file. The BMP085 digital pressure sensor can measure ambient air pressure and temperature. Both values can be obtained from sysfs files. The pressure is measured by reading from pressure0_input. Valid values range from 30000 to 110000 pascal with a resolution of 1 pascal (=0.01 millibar). temp0_input holds the current temperature in degree celsius, multiplied by 10. This results in a resolution of a tenth degree celsius. Values range from -400 to 850. To increase the accuracy, this chip can calculate the average of 1, 2, 4 or 8 samples. This behavior is controlled through the oversampling sysfs file. Two to the power of the value written to that file specifies how many samples will be used. Valid values: 0..3. [akpm@linux-foundation.org: fix typo] [shubhrajyoti@ti.com: optimize the wait time for the pressure sensor, definition of long is arch dependent so make it u32] [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Christoph Mair Signed-off-by: Shubhrajyoti D Acked-by: Jonathan Cameron Cc: Stefan Schmidt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/ABI/testing/sysfs-i2c-bmp085 | 31 ++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-i2c-bmp085 (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-i2c-bmp085 b/Documentation/ABI/testing/sysfs-i2c-bmp085 new file mode 100644 index 0000000..585962a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-i2c-bmp085 @@ -0,0 +1,31 @@ +What: /sys/bus/i2c/devices/-/pressure0_input +Date: June 2010 +Contact: Christoph Mair +Description: Start a pressure measurement and read the result. Values + represent the ambient air pressure in pascal (0.01 millibar). + + Reading: returns the current air pressure. + + +What: /sys/bus/i2c/devices/-/temp0_input +Date: June 2010 +Contact: Christoph Mair +Description: Measure the ambient temperature. The returned value represents + the ambient temperature in units of 0.1 degree celsius. + + Reading: returns the current temperature. + + +What: /sys/bus/i2c/devices/-/oversampling +Date: June 2010 +Contact: Christoph Mair +Description: Tell the bmp085 to use more samples to calculate a pressure + value. When writing to this file the chip will use 2^x samples + to calculate the next pressure value with x being the value + written. Using this feature will decrease RMS noise and + increase the measurement time. + + Reading: returns the current oversampling setting. + + Writing: sets a new oversampling setting. + Accepted values: 0..3. -- cgit v1.1 From cfa3b24c38b58cb6acabe6441b4668e530e957af Mon Sep 17 00:00:00 2001 From: Kalhan Trisal Date: Mon, 9 Aug 2010 17:21:05 -0700 Subject: hmc6352: add driver for the HMC6352 compass This driver will report the heading values in degrees to the sysfs interface. The values returned are headings . e.g. 245.6 Alan: Cleanups requested now all folded in and a sysfs description to keep Andrew happy. The sysfs description now resembles hwmon. Signed-off-by: Kalhan Trisal Reviewed-by: Jean Delvare Signed-off-by: Alan Cox Cc: Jonathan Cameron Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- .../ABI/testing/sysfs-bus-i2c-devices-hm6352 | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-hm6352 (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-hm6352 b/Documentation/ABI/testing/sysfs-bus-i2c-devices-hm6352 new file mode 100644 index 0000000..feb2e4a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-hm6352 @@ -0,0 +1,21 @@ +Where: /sys/bus/i2c/devices/.../heading0_input +Date: April 2010 +Kernel Version: 2.6.36? +Contact: alan.cox@intel.com +Description: Reports the current heading from the compass as a floating + point value in degrees. + +Where: /sys/bus/i2c/devices/.../power_state +Date: April 2010 +Kernel Version: 2.6.36? +Contact: alan.cox@intel.com +Description: Sets the power state of the device. 0 sets the device into + sleep mode, 1 wakes it up. + +Where: /sys/bus/i2c/devices/.../calibration +Date: April 2010 +Kernel Version: 2.6.36? +Contact: alan.cox@intel.com +Description: Sets the calibration on or off (1 = on, 0 = off). See the + chip data sheet. + -- cgit v1.1 From 920fa1ffce48d36d7e7bc54eb38c58313bc0a667 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Mon, 9 Aug 2010 17:21:06 -0700 Subject: hwmon: driver for SMM665 Six-Channel Active DC Output Controller/Monitor This driver adds support for the monitoring features of the Summit Microelectronics SMM665 Six-Channel Active DC Output Controller/Monitor. Signed-off-by: Guenter Roeck Acked-by: Jonathan Cameron Cc: Jean Delvare Cc: Hans de Goede Cc: Mark Brown Cc: Samuel Ortiz Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/hwmon/smm665 | 157 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 157 insertions(+) create mode 100644 Documentation/hwmon/smm665 (limited to 'Documentation') diff --git a/Documentation/hwmon/smm665 b/Documentation/hwmon/smm665 new file mode 100644 index 0000000..3820fc9 --- /dev/null +++ b/Documentation/hwmon/smm665 @@ -0,0 +1,157 @@ +Kernel driver smm665 +==================== + +Supported chips: + * Summit Microelectronics SMM465 + Prefix: 'smm465' + Addresses scanned: - + Datasheet: + http://www.summitmicro.com/prod_select/summary/SMM465/SMM465DS.pdf + * Summit Microelectronics SMM665, SMM665B + Prefix: 'smm665' + Addresses scanned: - + Datasheet: + http://www.summitmicro.com/prod_select/summary/SMM665/SMM665B_2089_20.pdf + * Summit Microelectronics SMM665C + Prefix: 'smm665c' + Addresses scanned: - + Datasheet: + http://www.summitmicro.com/prod_select/summary/SMM665C/SMM665C_2125.pdf + * Summit Microelectronics SMM764 + Prefix: 'smm764' + Addresses scanned: - + Datasheet: + http://www.summitmicro.com/prod_select/summary/SMM764/SMM764_2098.pdf + * Summit Microelectronics SMM766, SMM766B + Prefix: 'smm766' + Addresses scanned: - + Datasheets: + http://www.summitmicro.com/prod_select/summary/SMM766/SMM766_2086.pdf + http://www.summitmicro.com/prod_select/summary/SMM766B/SMM766B_2122.pdf + +Author: Guenter Roeck + + +Module Parameters +----------------- + +* vref: int + Default: 1250 (mV) + Reference voltage on VREF_ADC pin in mV. It should not be necessary to set + this parameter unless a non-default reference voltage is used. + + +Description +----------- + +[From datasheet] The SMM665 is an Active DC Output power supply Controller +that monitors, margins and cascade sequences power. The part monitors six +power supply channels as well as VDD, 12V input, two general-purpose analog +inputs and an internal temperature sensor using a 10-bit ADC. + +Each monitored channel has its own high and low limits, plus a critical +limit. + +Support for SMM465, SMM764, and SMM766 has been implemented but is untested. + + +Usage Notes +----------- + +This driver does not probe for devices, since there is no register which +can be safely used to identify the chip. You will have to instantiate +the devices explicitly. When instantiating the device, you have to specify +its configuration register address. + +Example: the following will load the driver for an SMM665 at address 0x57 +on I2C bus #1: +$ modprobe smm665 +$ echo smm665 0x57 > /sys/bus/i2c/devices/i2c-1/new_device + + +Sysfs entries +------------- + +This driver uses the values in the datasheet to convert ADC register values +into the values specified in the sysfs-interface document. All attributes are +read only. + +Min, max, lcrit, and crit values are used by the chip to trigger external signals +and/or other activity. Triggered signals can include HEALTHY, RST, Power Off, +or Fault depending on the chip configuration. The driver reports values as lcrit +or crit if exceeding the limits triggers RST, Power Off, or Fault, and as min or +max otherwise. For details please see the SMM665 datasheet. + +For SMM465 and SMM764, values for Channel E and F are reported but undefined. + +in1_input 12V input voltage (mV) +in2_input 3.3V (VDD) input voltage (mV) +in3_input Channel A voltage (mV) +in4_input Channel B voltage (mV) +in5_input Channel C voltage (mV) +in6_input Channel D voltage (mV) +in7_input Channel E voltage (mV) +in8_input Channel F voltage (mV) +in9_input AIN1 voltage (mV) +in10_input AIN2 voltage (mV) + +in1_min 12v input minimum voltage (mV) +in2_min 3.3V (VDD) input minimum voltage (mV) +in3_min Channel A minimum voltage (mV) +in4_min Channel B minimum voltage (mV) +in5_min Channel C minimum voltage (mV) +in6_min Channel D minimum voltage (mV) +in7_min Channel E minimum voltage (mV) +in8_min Channel F minimum voltage (mV) +in9_min AIN1 minimum voltage (mV) +in10_min AIN2 minimum voltage (mV) + +in1_max 12v input maximum voltage (mV) +in2_max 3.3V (VDD) input maximum voltage (mV) +in3_max Channel A maximum voltage (mV) +in4_max Channel B maximum voltage (mV) +in5_max Channel C maximum voltage (mV) +in6_max Channel D maximum voltage (mV) +in7_max Channel E maximum voltage (mV) +in8_max Channel F maximum voltage (mV) +in9_max AIN1 maximum voltage (mV) +in10_max AIN2 maximum voltage (mV) + +in1_lcrit 12v input critical minimum voltage (mV) +in2_lcrit 3.3V (VDD) input critical minimum voltage (mV) +in3_lcrit Channel A critical minimum voltage (mV) +in4_lcrit Channel B critical minimum voltage (mV) +in5_lcrit Channel C critical minimum voltage (mV) +in6_lcrit Channel D critical minimum voltage (mV) +in7_lcrit Channel E critical minimum voltage (mV) +in8_lcrit Channel F critical minimum voltage (mV) +in9_lcrit AIN1 critical minimum voltage (mV) +in10_lcrit AIN2 critical minimum voltage (mV) + +in1_crit 12v input critical maximum voltage (mV) +in2_crit 3.3V (VDD) input critical maximum voltage (mV) +in3_crit Channel A critical maximum voltage (mV) +in4_crit Channel B critical maximum voltage (mV) +in5_crit Channel C critical maximum voltage (mV) +in6_crit Channel D critical maximum voltage (mV) +in7_crit Channel E critical maximum voltage (mV) +in8_crit Channel F critical maximum voltage (mV) +in9_crit AIN1 critical maximum voltage (mV) +in10_crit AIN2 critical maximum voltage (mV) + +in1_crit_alarm 12v input critical alarm +in2_crit_alarm 3.3V (VDD) input critical alarm +in3_crit_alarm Channel A critical alarm +in4_crit_alarm Channel B critical alarm +in5_crit_alarm Channel C critical alarm +in6_crit_alarm Channel D critical alarm +in7_crit_alarm Channel E critical alarm +in8_crit_alarm Channel F critical alarm +in9_crit_alarm AIN1 critical alarm +in10_crit_alarm AIN2 critical alarm + +temp1_input Chip tempererature +temp1_min Mimimum chip tempererature +temp1_max Maximum chip tempererature +temp1_crit Critical chip tempererature +temp1_crit_alarm Temperature critical alarm -- cgit v1.1 From 4453d7364d3b1f92475f104d4625abee36a7733d Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Mon, 9 Aug 2010 17:21:08 -0700 Subject: hwmon: add support for JEDEC JC 42.4 compliant temperature sensors [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Guenter Roeck Cc: Jean Delvare Cc: Randy Dunlap Cc: Hans de Goede Cc: Mark Brown Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/hwmon/jc42 | 97 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 Documentation/hwmon/jc42 (limited to 'Documentation') diff --git a/Documentation/hwmon/jc42 b/Documentation/hwmon/jc42 new file mode 100644 index 0000000..0e76ef1 --- /dev/null +++ b/Documentation/hwmon/jc42 @@ -0,0 +1,97 @@ +Kernel driver jc42 +================== + +Supported chips: + * Analog Devices ADT7408 + Prefix: 'adt7408' + Addresses scanned: I2C 0x18 - 0x1f + Datasheets: + http://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf + * IDT TSE2002B3, TS3000B3 + Prefix: 'tse2002b3', 'ts3000b3' + Addresses scanned: I2C 0x18 - 0x1f + Datasheets: + http://www.idt.com/products/getdoc.cfm?docid=18715691 + http://www.idt.com/products/getdoc.cfm?docid=18715692 + * Maxim MAX6604 + Prefix: 'max6604' + Addresses scanned: I2C 0x18 - 0x1f + Datasheets: + http://datasheets.maxim-ic.com/en/ds/MAX6604.pdf + * Microchip MCP9805, MCP98242, MCP98243, MCP9843 + Prefixes: 'mcp9805', 'mcp98242', 'mcp98243', 'mcp9843' + Addresses scanned: I2C 0x18 - 0x1f + Datasheets: + http://ww1.microchip.com/downloads/en/DeviceDoc/21977b.pdf + http://ww1.microchip.com/downloads/en/DeviceDoc/21996a.pdf + http://ww1.microchip.com/downloads/en/DeviceDoc/22153c.pdf + * NXP Semiconductors SE97, SE97B + Prefix: 'se97' + Addresses scanned: I2C 0x18 - 0x1f + Datasheets: + http://www.nxp.com/documents/data_sheet/SE97.pdf + http://www.nxp.com/documents/data_sheet/SE97B.pdf + * NXP Semiconductors SE98 + Prefix: 'se98' + Addresses scanned: I2C 0x18 - 0x1f + Datasheets: + http://www.nxp.com/documents/data_sheet/SE98.pdf + * ON Semiconductor CAT34TS02, CAT6095 + Prefix: 'cat34ts02', 'cat6095' + Addresses scanned: I2C 0x18 - 0x1f + Datasheet: + http://www.onsemi.com/pub_link/Collateral/CAT34TS02-D.PDF + http://www.onsemi.com/pub/Collateral/CAT6095-D.PDF + * ST Microelectronics STTS424, STTS424E02 + Prefix: 'stts424' + Addresses scanned: I2C 0x18 - 0x1f + Datasheets: + http://www.st.com/stonline/products/literature/ds/13447/stts424.pdf + http://www.st.com/stonline/products/literature/ds/13448/stts424e02.pdf + * JEDEC JC 42.4 compliant temperature sensor chips + Prefix: 'jc42' + Addresses scanned: I2C 0x18 - 0x1f + Datasheet: - + +Author: + Guenter Roeck + + +Description +----------- + +This driver implements support for JEDEC JC 42.4 compliant temperature sensors. +The driver auto-detects the chips listed above, but can be manually instantiated +to support other JC 42.4 compliant chips. + +Example: the following will load the driver for a generic JC 42.4 compliant +temperature sensor at address 0x18 on I2C bus #1: + +# modprobe jc42 +# echo jc42 0x18 > /sys/bus/i2c/devices/i2c-1/new_device + +A JC 42.4 compliant chip supports a single temperature sensor. Minimum, maximum, +and critical temperature can be configured. There are alarms for high, low, +and critical thresholds. + +There is also an hysteresis to control the thresholds for resetting alarms. +Per JC 42.4 specification, the hysteresis threshold can be configured to 0, 1.5, +3.0, and 6.0 degrees C. Configured hysteresis values will be rounded to those +limits. The chip supports only a single register to configure the hysteresis, +which applies to all limits. This register can be written by writing into +temp1_crit_hyst. Other hysteresis attributes are read-only. + +Sysfs entries +------------- + +temp1_input Temperature (RO) +temp1_min Minimum temperature (RW) +temp1_max Maximum temperature (RW) +temp1_crit Critical high temperature (RW) + +temp1_crit_hyst Critical hysteresis temperature (RW) +temp1_max_hyst Maximum hysteresis temperature (RO) + +temp1_min_alarm Temperature low alarm +temp1_max_alarm Temperature high alarm +temp1_crit_alarm Temperature critical alarm -- cgit v1.1 From f3cffe4d1a20208da9bf2c9cc0a973bf091eb160 Mon Sep 17 00:00:00 2001 From: Chen Gong Date: Mon, 9 Aug 2010 17:21:10 -0700 Subject: hwmon: coretemp: documentation update and cleanup Update coretemp supported CPU TjMax lists and some cleanup work. Signed-off-by: Chen Gong Cc: Rudolf Marek Cc: Huaxu Wan Cc: Jean Delvare Cc: Guenter Roeck Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/hwmon/coretemp | 105 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 103 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp index 92267b6..25568f8 100644 --- a/Documentation/hwmon/coretemp +++ b/Documentation/hwmon/coretemp @@ -21,8 +21,8 @@ Temperature is measured in degrees Celsius and measurement resolution is 1 degree C. Valid temperatures are from 0 to TjMax degrees C, because the actual value of temperature register is in fact a delta from TjMax. -Temperature known as TjMax is the maximum junction temperature of processor. -Intel defines this temperature as 85C or 100C. At this temperature, protection +Temperature known as TjMax is the maximum junction temperature of processor, +which depends on the CPU model. See table below. At this temperature, protection mechanism will perform actions to forcibly cool down the processor. Alarm may be raised, if the temperature grows enough (more than TjMax) to trigger the Out-Of-Spec bit. Following table summarizes the exported sysfs files: @@ -38,3 +38,104 @@ temp1_label - Contains string "Core X", where X is processor The TjMax temperature is set to 85 degrees C if undocumented model specific register (UMSR) 0xee has bit 30 set. If not the TjMax is 100 degrees C as (sometimes) documented in processor datasheet. + +Appendix A. Known TjMax lists (TBD): +Some information comes from ark.intel.com + +Process Processor TjMax(C) + +32nm Core i3/i5/i7 Processors + i7 660UM/640/620, 640LM/620, 620M, 610E 105 + i5 540UM/520/430, 540M/520/450/430 105 + i3 330E, 370M/350/330 90 rPGA, 105 BGA + i3 330UM 105 + +32nm Core i7 Extreme Processors + 980X 100 + +32nm Celeron Processors + U3400 105 + P4505/P4500 90 + +45nm Xeon Processors 5400 Quad-Core + X5492, X5482, X5472, X5470, X5460, X5450 85 + E5472, E5462, E5450/40/30/20/10/05 85 + L5408 95 + L5430, L5420, L5410 70 + +45nm Xeon Processors 5200 Dual-Core + X5282, X5272, X5270, X5260 90 + E5240 90 + E5205, E5220 70, 90 + L5240 70 + L5238, L5215 95 + +45nm Atom Processors + D525/510/425/410 100 + Z560/550/540/530P/530/520PT/520/515/510PT/510P 90 + Z510/500 90 + N475/470/455/450 100 + N280/270 90 + 330/230 125 + +45nm Core2 Processors + Solo ULV SU3500/3300 100 + T9900/9800/9600/9550/9500/9400/9300/8300/8100 105 + T6670/6500/6400 105 + T6600 90 + SU9600/9400/9300 105 + SP9600/9400 105 + SL9600/9400/9380/9300 105 + P9700/9600/9500/8800/8700/8600/8400/7570 105 + P7550/7450 90 + +45nm Core2 Quad Processors + Q9100/9000 100 + +45nm Core2 Extreme Processors + X9100/9000 105 + QX9300 100 + +45nm Core i3/i5/i7 Processors + i7 940XM/920 100 + i7 840QM/820/740/720 100 + +45nm Celeron Processors + SU2300 100 + 900 105 + +65nm Core2 Duo Processors + Solo U2200, U2100 100 + U7700/7600/7500 100 + T7800/7700/7600/7500/7400/7300/7250/7200/7100 100 + T5870/5670/5600/5550/5500/5470/5450/5300/5270 100 + T5250 100 + T5800/5750/5200 85 + L7700/7500/7400/7300/7200 100 + +65nm Core2 Extreme Processors + X7900/7800 100 + +65nm Core Duo Processors + U2500/2400 100 + T2700/2600/2450/2400/2350/2300E/2300/2250/2050 100 + L2500/2400/2300 100 + +65nm Core Solo Processors + U1500/1400/1300 100 + T1400/1350/1300/1250 100 + +65nm Xeon Processors 5000 Quad-Core + X5000 90-95 + E5000 80 + L5000 70 + L5318 95 + +65nm Xeon Processors 5000 Dual-Core + 5080, 5063, 5060, 5050, 5030 80-90 + 5160, 5150, 5148, 5140, 5130, 5120, 5110 80 + L5138 100 + +65nm Celeron Processors + T1700/1600 100 + 560/550/540/530 100 -- cgit v1.1 From 7721fea3d0fd93fb4d000eb737b444369358d6d3 Mon Sep 17 00:00:00 2001 From: Giel van Schijndel Date: Mon, 9 Aug 2010 17:21:13 -0700 Subject: hwmon: f71882fg: add support for the Fintek F71808E Allow device probing to recognise the Fintek F71808E. Sysfs interface: * Fan/pwm control is the same as for F71889FG * Temperature and voltage sensor handling is largely the same as for the F71889FG - Has one temperature sensor less (doesn't have temp3) - Misses one voltage sensor (doesn't have V6, thus in6_input refers to what in7_input refers for F71889FG) For the purpose of the sysfs interface fxxxx_in_temp_attr[] is split up such that it can largely be reused. Signed-off-by: Giel van Schijndel Cc: Jean Delvare Cc: Hans de Goede Cc: Jonathan Cameron Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/hwmon/f71882fg | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/f71882fg b/Documentation/hwmon/f71882fg index a7952c2..1a07fd6 100644 --- a/Documentation/hwmon/f71882fg +++ b/Documentation/hwmon/f71882fg @@ -2,6 +2,10 @@ Kernel driver f71882fg ====================== Supported chips: + * Fintek F71808E + Prefix: 'f71808fg' + Addresses scanned: none, address read from Super I/O config space + Datasheet: Not public * Fintek F71858FG Prefix: 'f71858fg' Addresses scanned: none, address read from Super I/O config space -- cgit v1.1 From dc9bee37738444492ee7b2d7ed576d11e03ae162 Mon Sep 17 00:00:00 2001 From: Clemens Ladisch Date: Tue, 10 Aug 2010 10:39:39 +0200 Subject: ALSA: hda: document VIA models Add documentation about the autodetection of the VIA codec models to avoid the false impression that they are not supported. Signed-off-by: Clemens Ladisch Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 03771d7..84b2375 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -416,3 +416,7 @@ Cirrus Logic CS4206/4207 mbp55 MacBook Pro 5,5 imac27 IMac 27 Inch auto BIOS setup (default) + +VIA VT17xx/VT18xx/VT20xx +======================== + auto BIOS setup (default) -- cgit v1.1 From 9b200d7d55763f15f3bb8539db3f3e014fb27593 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Tue, 10 Aug 2010 09:15:04 +0200 Subject: ALSA: hda - Update model entries in HD-Audio-Models.txt Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 84b2375..ce46fa1 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -83,8 +83,8 @@ ALC269 ====== basic Basic preset quanta Quanta FL1 - eeepc-p703 ASUS Eeepc P703 P900A - eeepc-p901 ASUS Eeepc P901 S101 + laptop-amic Laptops with analog-mic input + laptop-dmic Laptops with digital-mic input fujitsu FSC Amilo lifebook Fujitsu Lifebook S6420 auto auto-config reading BIOS (default) @@ -109,6 +109,8 @@ ALC662/663/272 asus-mode4 ASUS asus-mode5 ASUS asus-mode6 ASUS + asus-mode7 ASUS + asus-mode8 ASUS dell Dell with ALC272 dell-zm1 Dell ZM1 with ALC272 samsung-nc10 Samsung NC10 mini notebook @@ -295,8 +297,10 @@ Conexant 5066 ============= laptop Basic Laptop config (default) dell-laptop Dell laptops + dell-vostro Dell Vostro olpc-xo-1_5 OLPC XO 1.5 ideapad Lenovo IdeaPad U150 + thinkpad Lenovo Thinkpad STAC9200 ======== @@ -404,6 +408,7 @@ STAC92HD83* mic-ref Reference board with power management for ports dell-s14 Dell laptop hp HP laptops with (inverted) mute-LED + hp-dv7-4000 HP dv-7 4000 auto BIOS setup (default) STAC9872 -- cgit v1.1 From 429d646d9aeafdb57717dab75c807215f5cce9c2 Mon Sep 17 00:00:00 2001 From: Stefan Weil Date: Thu, 5 Aug 2010 10:44:48 +0200 Subject: Doc: Fix spelling Legned -> Legend mainatined -> maintained Legend is now Lenovo, so more fixes (text and url) would be possible, too. Cc: Jiri Kosina Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Stefan Weil Signed-off-by: Jiri Kosina --- Documentation/arm/SA1100/FreeBird | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm/SA1100/FreeBird b/Documentation/arm/SA1100/FreeBird index fb23b77..ab91936 100644 --- a/Documentation/arm/SA1100/FreeBird +++ b/Documentation/arm/SA1100/FreeBird @@ -1,6 +1,6 @@ -Freebird-1.1 is produced by Legned(C) ,Inc. +Freebird-1.1 is produced by Legend(C), Inc. http://web.archive.org/web/*/http://www.legend.com.cn -and software/linux mainatined by Coventive(C),Inc. +and software/linux maintained by Coventive(C), Inc. (http://www.coventive.com) Based on the Nicolas's strongarm kernel tree. -- cgit v1.1 From 1917ac76e023339c73844bec775375b147f57ac7 Mon Sep 17 00:00:00 2001 From: Samium Gromoff <_deepfire@feelingofgreen.ru> Date: Tue, 20 Jul 2010 15:26:51 -0700 Subject: serial: MMIO32 support for 8250_early.c Provide MMIO32 support in 8250_early (aka earlycon) [randy.dunlap@oracle.com: fix printk format warnings] [akpm@linux-foundation.org: fix printk args some more] Signed-off-by: Samium Gromoff <_deepfire@feelingofgreen.ru> Signed-off-by: Randy Dunlap Cc: KOSAKI Motohiro Signed-off-by: Andrew Morton Signed-off-by: Greg Kroah-Hartman --- Documentation/kernel-parameters.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 44f6b19..d529b13 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -681,8 +681,11 @@ and is between 256 and 4096 characters. It is defined in the file earlycon= [KNL] Output early console device and options. uart[8250],io,[,options] uart[8250],mmio,[,options] + uart[8250],mmio32,[,options] Start an early, polled-mode console on the 8250/16550 UART at the specified I/O port or MMIO address. + MMIO inter-register address stride is either 8bit (mmio) + or 32bit (mmio32). The options are the same as for ttyS, above. earlyprintk= [X86,SH,BLACKFIN] -- cgit v1.1 From 254217d1a86f80981e6dfc54d7412931c6f6e80b Mon Sep 17 00:00:00 2001 From: Andrea Gelmini Date: Sun, 23 May 2010 21:56:41 +0200 Subject: USB: Documentation/usb/ehci.txt: Checkpatch cleanup Documentation/usb/ehci.txt:12: ERROR: trailing whitespace Signed-off-by: Andrea Gelmini Signed-off-by: Greg Kroah-Hartman --- Documentation/usb/ehci.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/usb/ehci.txt b/Documentation/usb/ehci.txt index 1536b7e..9dcafa7 100644 --- a/Documentation/usb/ehci.txt +++ b/Documentation/usb/ehci.txt @@ -9,7 +9,7 @@ compatible with the USB 1.1 standard. It defines three transfer speeds: - "Low Speed" 1.5 Mbit/sec USB 1.1 only addressed full speed and low speed. High speed devices -can be used on USB 1.1 systems, but they slow down to USB 1.1 speeds. +can be used on USB 1.1 systems, but they slow down to USB 1.1 speeds. USB 1.1 devices may also be used on USB 2.0 systems. When plugged into an EHCI controller, they are given to a USB 1.1 "companion" -- cgit v1.1 From b03dbffdcf7903ae3f1e2d61887462301752d060 Mon Sep 17 00:00:00 2001 From: Andrea Gelmini Date: Sun, 23 May 2010 21:56:42 +0200 Subject: USB: Documentation/usb/hotplug.txt: Checkpatch cleanup Documentation/usb/hotplug.txt:13: ERROR: trailing whitespace Documentation/usb/hotplug.txt:87: ERROR: trailing whitespace Signed-off-by: Andrea Gelmini Signed-off-by: Greg Kroah-Hartman --- Documentation/usb/hotplug.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/usb/hotplug.txt b/Documentation/usb/hotplug.txt index f531706..4c94571 100644 --- a/Documentation/usb/hotplug.txt +++ b/Documentation/usb/hotplug.txt @@ -10,7 +10,7 @@ immediately usable. That means the system must do many things, including: - Bind a driver to that device. Bus frameworks do that using a device driver's probe() routine. - + - Tell other subsystems to configure the new device. Print queues may need to be enabled, networks brought up, disk partitions mounted, and so on. In some cases these will @@ -84,7 +84,7 @@ USB MODUTILS SUPPORT Current versions of module-init-tools will create a "modules.usbmap" file which contains the entries from each driver's MODULE_DEVICE_TABLE. Such files can be used by various user mode policy agents to make sure all the -right driver modules get loaded, either at boot time or later. +right driver modules get loaded, either at boot time or later. See for full information about such table entries; or look at existing drivers. Each table entry describes one or more criteria to -- cgit v1.1 From e9c64f2b39d6861d5f3108ec135966349fc66adb Mon Sep 17 00:00:00 2001 From: Andrea Gelmini Date: Sun, 23 May 2010 21:56:43 +0200 Subject: USB: Documentation/usb/linux.inf: Checkpatch cleanup Documentation/usb/linux.inf:66: ERROR: trailing whitespace Documentation/usb/linux.inf:67: ERROR: trailing whitespace Documentation/usb/linux.inf:98: ERROR: trailing whitespace Documentation/usb/linux.inf:99: ERROR: trailing whitespace Documentation/usb/linux.inf:115: ERROR: trailing whitespace Documentation/usb/linux.inf:116: ERROR: trailing whitespace Documentation/usb/linux.inf:120: ERROR: trailing whitespace Documentation/usb/linux.inf:121: ERROR: trailing whitespace Documentation/usb/linux.inf:122: ERROR: trailing whitespace Documentation/usb/linux.inf:123: ERROR: trailing whitespace Documentation/usb/linux.inf:144: ERROR: trailing whitespace Documentation/usb/linux.inf:145: ERROR: trailing whitespace Documentation/usb/linux.inf:146: ERROR: trailing whitespace Documentation/usb/linux.inf:147: ERROR: trailing whitespace Documentation/usb/linux.inf:158: ERROR: trailing whitespace Signed-off-by: Andrea Gelmini Signed-off-by: Greg Kroah-Hartman --- Documentation/usb/linux.inf | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/usb/linux.inf b/Documentation/usb/linux.inf index af71d87..ebd02be 100644 --- a/Documentation/usb/linux.inf +++ b/Documentation/usb/linux.inf @@ -63,8 +63,8 @@ HKR, Ndi, DeviceId, 0, "USB\VID_0525&PID_a4a2" CopyFiles=RNDIS_CopyFiles_98 [RNDIS_CopyFiles_98] -usb8023.sys, usb8023w.sys, , 0 -rndismp.sys, rndismpw.sys, , 0 +usb8023.sys, usb8023w.sys, , 0 +rndismp.sys, rndismpw.sys, , 0 ; Windows Millennium Edition specific sections -------------------- @@ -95,8 +95,8 @@ HKR, Ndi, DeviceId, 0, "USB\VID_0525&PID_a4a2" CopyFiles=RNDIS_CopyFiles_ME [RNDIS_CopyFiles_ME] -usb8023.sys, usb8023m.sys, , 0 -rndismp.sys, rndismpm.sys, , 0 +usb8023.sys, usb8023m.sys, , 0 +rndismp.sys, rndismpm.sys, , 0 ; Windows 2000 specific sections --------------------------------- @@ -112,15 +112,15 @@ AddService = USB_RNDIS, 2, RNDIS_ServiceInst_NT, RNDIS_EventLog [RNDIS_CopyFiles_NT] ; no rename of files on Windows 2000, use the 'k' names as is -usb8023k.sys, , , 0 -rndismpk.sys, , , 0 +usb8023k.sys, , , 0 +rndismpk.sys, , , 0 [RNDIS_ServiceInst_NT] DisplayName = %ServiceDisplayName% -ServiceType = 1 -StartType = 3 -ErrorControl = 1 -ServiceBinary = %12%\usb8023k.sys +ServiceType = 1 +StartType = 3 +ErrorControl = 1 +ServiceBinary = %12%\usb8023k.sys LoadOrderGroup = NDIS AddReg = RNDIS_WMI_AddReg_NT @@ -141,10 +141,10 @@ AddService = USB_RNDIS, 2, RNDIS_ServiceInst_51, RNDIS_EventLog [RNDIS_ServiceInst_51] DisplayName = %ServiceDisplayName% -ServiceType = 1 -StartType = 3 -ErrorControl = 1 -ServiceBinary = %12%\usb8023.sys +ServiceType = 1 +StartType = 3 +ErrorControl = 1 +ServiceBinary = %12%\usb8023.sys LoadOrderGroup = NDIS AddReg = RNDIS_WMI_AddReg_51 @@ -155,7 +155,7 @@ HKR, , MofImagePath, 0x00020000, "System32\drivers\rndismp.sys" [RNDIS_AddReg_NT] HKR, Ndi, Service, 0, "USB_RNDIS" -HKR, Ndi\Interfaces, UpperRange, 0, "ndis5" +HKR, Ndi\Interfaces, UpperRange, 0, "ndis5" HKR, Ndi\Interfaces, LowerRange, 0, "ethernet" [RNDIS_EventLog] -- cgit v1.1 From 90eef5b8acb459da65b269cf1db9f92debda1a24 Mon Sep 17 00:00:00 2001 From: Michal Nazarewicz Date: Mon, 21 Jun 2010 13:57:05 +0200 Subject: USB: gadget: g_ether: updated INF file Updated the INF file for the g_ether gadget. It should work with most recent Windows systems now. Signed-off-by: Michal Nazarewicz Signed-off-by: Kyungmin Park Signed-off-by: Greg Kroah-Hartman --- Documentation/usb/linux.inf | 228 +++++++++----------------------------------- 1 file changed, 47 insertions(+), 181 deletions(-) (limited to 'Documentation') diff --git a/Documentation/usb/linux.inf b/Documentation/usb/linux.inf index ebd02be..b9e538c 100644 --- a/Documentation/usb/linux.inf +++ b/Documentation/usb/linux.inf @@ -1,200 +1,66 @@ -; MS-Windows driver config matching some basic modes of the -; Linux-USB Ethernet/RNDIS gadget firmware: -; -; - RNDIS plus CDC Ethernet ... this may be familiar as a DOCSIS -; cable modem profile, and supports most non-Microsoft USB hosts -; -; - RNDIS plus CDC Subset ... used by hardware that incapable of -; full CDC Ethernet support. -; -; Microsoft only directly supports RNDIS drivers, and bundled them into XP. -; The Microsoft "Remote NDIS USB Driver Kit" is currently found at: -; http://www.microsoft.com/whdc/device/network/ndis/rmndis.mspx - +; Based on template INF file found at +; +; which was: +; Copyright (c) Microsoft Corporation +; and released under the MLPL as found at: +; . +; For use only on Windows operating systems. [Version] -Signature = "$CHICAGO$" +Signature = "$Windows NT$" Class = Net ClassGUID = {4d36e972-e325-11ce-bfc1-08002be10318} Provider = %Linux% -Compatible = 1 -MillenniumPreferred = .ME -DriverVer = 03/30/2004,0.0.0.0 -; catalog file would be used by WHQL -;CatalogFile = Linux.cat +DriverVer = 06/21/2006,6.0.6000.16384 [Manufacturer] -%Linux% = LinuxDevices,NT.5.1 +%Linux% = LinuxDevices,NTx86,NTamd64,NTia64 + +; Decoration for x86 architecture +[LinuxDevices.NTx86] +%LinuxDevice% = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2 -[LinuxDevices] -; NetChip IDs, used by both firmware modes -%LinuxDevice% = RNDIS, USB\VID_0525&PID_a4a2 +; Decoration for x64 architecture +[LinuxDevices.NTamd64] +%LinuxDevice% = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2 -[LinuxDevices.NT.5.1] -%LinuxDevice% = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2 +; Decoration for ia64 architecture +[LinuxDevices.NTia64] +%LinuxDevice% = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2 +;@@@ This is the common setting for setup [ControlFlags] ExcludeFromSelect=* -; Windows 98, Windows 98 Second Edition specific sections -------- - -[RNDIS] -DeviceID = usb8023 -MaxInstance = 512 -DriverVer = 03/30/2004,0.0.0.0 -AddReg = RNDIS_AddReg_98, RNDIS_AddReg_Common - -[RNDIS_AddReg_98] -HKR, , DevLoader, 0, *ndis -HKR, , DeviceVxDs, 0, usb8023.sys -HKR, NDIS, LogDriverName, 0, "usb8023" -HKR, NDIS, MajorNdisVersion, 1, 5 -HKR, NDIS, MinorNdisVersion, 1, 0 -HKR, Ndi\Interfaces, DefUpper, 0, "ndis3,ndis4,ndis5" -HKR, Ndi\Interfaces, DefLower, 0, "ethernet" -HKR, Ndi\Interfaces, UpperRange, 0, "ndis3,ndis4,ndis5" -HKR, Ndi\Interfaces, LowerRange, 0, "ethernet" -HKR, Ndi\Install, ndis3, 0, "RNDIS_Install_98" -HKR, Ndi\Install, ndis4, 0, "RNDIS_Install_98" -HKR, Ndi\Install, ndis5, 0, "RNDIS_Install_98" -HKR, Ndi, DeviceId, 0, "USB\VID_0525&PID_a4a2" - -[RNDIS_Install_98] -CopyFiles=RNDIS_CopyFiles_98 - -[RNDIS_CopyFiles_98] -usb8023.sys, usb8023w.sys, , 0 -rndismp.sys, rndismpw.sys, , 0 - -; Windows Millennium Edition specific sections -------------------- - -[RNDIS.ME] -DeviceID = usb8023 -MaxInstance = 512 -DriverVer = 03/30/2004,0.0.0.0 -AddReg = RNDIS_AddReg_ME, RNDIS_AddReg_Common -Characteristics = 0x84 ; NCF_PHYSICAL + NCF_HAS_UI -BusType = 15 - -[RNDIS_AddReg_ME] -HKR, , DevLoader, 0, *ndis -HKR, , DeviceVxDs, 0, usb8023.sys -HKR, NDIS, LogDriverName, 0, "usb8023" -HKR, NDIS, MajorNdisVersion, 1, 5 -HKR, NDIS, MinorNdisVersion, 1, 0 -HKR, Ndi\Interfaces, DefUpper, 0, "ndis3,ndis4,ndis5" -HKR, Ndi\Interfaces, DefLower, 0, "ethernet" -HKR, Ndi\Interfaces, UpperRange, 0, "ndis3,ndis4,ndis5" -HKR, Ndi\Interfaces, LowerRange, 0, "ethernet" -HKR, Ndi\Install, ndis3, 0, "RNDIS_Install_ME" -HKR, Ndi\Install, ndis4, 0, "RNDIS_Install_ME" -HKR, Ndi\Install, ndis5, 0, "RNDIS_Install_ME" -HKR, Ndi, DeviceId, 0, "USB\VID_0525&PID_a4a2" - -[RNDIS_Install_ME] -CopyFiles=RNDIS_CopyFiles_ME - -[RNDIS_CopyFiles_ME] -usb8023.sys, usb8023m.sys, , 0 -rndismp.sys, rndismpm.sys, , 0 - -; Windows 2000 specific sections --------------------------------- - -[RNDIS.NT] -Characteristics = 0x84 ; NCF_PHYSICAL + NCF_HAS_UI -BusType = 15 -DriverVer = 03/30/2004,0.0.0.0 -AddReg = RNDIS_AddReg_NT, RNDIS_AddReg_Common -CopyFiles = RNDIS_CopyFiles_NT - -[RNDIS.NT.Services] -AddService = USB_RNDIS, 2, RNDIS_ServiceInst_NT, RNDIS_EventLog - -[RNDIS_CopyFiles_NT] -; no rename of files on Windows 2000, use the 'k' names as is -usb8023k.sys, , , 0 -rndismpk.sys, , , 0 - -[RNDIS_ServiceInst_NT] -DisplayName = %ServiceDisplayName% -ServiceType = 1 -StartType = 3 -ErrorControl = 1 -ServiceBinary = %12%\usb8023k.sys -LoadOrderGroup = NDIS -AddReg = RNDIS_WMI_AddReg_NT - -[RNDIS_WMI_AddReg_NT] -HKR, , MofImagePath, 0x00020000, "System32\drivers\rndismpk.sys" - -; Windows XP specific sections ----------------------------------- - +; DDInstall section +; References the in-build Netrndis.inf [RNDIS.NT.5.1] -Characteristics = 0x84 ; NCF_PHYSICAL + NCF_HAS_UI -BusType = 15 -DriverVer = 03/30/2004,0.0.0.0 -AddReg = RNDIS_AddReg_NT, RNDIS_AddReg_Common -; no copyfiles - the files are already in place - +Characteristics = 0x84 ; NCF_PHYSICAL + NCF_HAS_UI +BusType = 15 +; NEVER REMOVE THE FOLLOWING REFERENCE FOR NETRNDIS.INF +include = netrndis.inf +needs = Usb_Rndis.ndi +AddReg = Rndis_AddReg_Vista + +; DDInstal.Services section [RNDIS.NT.5.1.Services] -AddService = USB_RNDIS, 2, RNDIS_ServiceInst_51, RNDIS_EventLog - -[RNDIS_ServiceInst_51] -DisplayName = %ServiceDisplayName% -ServiceType = 1 -StartType = 3 -ErrorControl = 1 -ServiceBinary = %12%\usb8023.sys -LoadOrderGroup = NDIS -AddReg = RNDIS_WMI_AddReg_51 - -[RNDIS_WMI_AddReg_51] -HKR, , MofImagePath, 0x00020000, "System32\drivers\rndismp.sys" - -; Windows 2000 and Windows XP common sections -------------------- - -[RNDIS_AddReg_NT] -HKR, Ndi, Service, 0, "USB_RNDIS" -HKR, Ndi\Interfaces, UpperRange, 0, "ndis5" -HKR, Ndi\Interfaces, LowerRange, 0, "ethernet" - -[RNDIS_EventLog] -AddReg = RNDIS_EventLog_AddReg - -[RNDIS_EventLog_AddReg] -HKR, , EventMessageFile, 0x00020000, "%%SystemRoot%%\System32\netevent.dll" -HKR, , TypesSupported, 0x00010001, 7 - -; Common Sections ------------------------------------------------- - -[RNDIS_AddReg_Common] -HKR, NDI\params\NetworkAddress, ParamDesc, 0, %NetworkAddress% -HKR, NDI\params\NetworkAddress, type, 0, "edit" -HKR, NDI\params\NetworkAddress, LimitText, 0, "12" -HKR, NDI\params\NetworkAddress, UpperCase, 0, "1" -HKR, NDI\params\NetworkAddress, default, 0, " " -HKR, NDI\params\NetworkAddress, optional, 0, "1" - -[SourceDisksNames] -1=%SourceDisk%,,1 - -[SourceDisksFiles] -usb8023m.sys=1 -rndismpm.sys=1 -usb8023w.sys=1 -rndismpw.sys=1 -usb8023k.sys=1 -rndismpk.sys=1 - -[DestinationDirs] -RNDIS_CopyFiles_98 = 10, system32/drivers -RNDIS_CopyFiles_ME = 10, system32/drivers -RNDIS_CopyFiles_NT = 12 +include = netrndis.inf +needs = Usb_Rndis.ndi.Services + +; Optional registry settings. You can modify as needed. +[RNDIS_AddReg_Vista] +HKR, NDI\params\VistaProperty, ParamDesc, 0, %Vista_Property% +HKR, NDI\params\VistaProperty, type, 0, "edit" +HKR, NDI\params\VistaProperty, LimitText, 0, "12" +HKR, NDI\params\VistaProperty, UpperCase, 0, "1" +HKR, NDI\params\VistaProperty, default, 0, " " +HKR, NDI\params\VistaProperty, optional, 0, "1" + +; No sys copyfiles - the sys files are already in-build +; (part of the operating system). +; We do not support XP SP1-, 2003 SP1-, ME, 9x. [Strings] -ServiceDisplayName = "USB Remote NDIS Network Device Driver" -NetworkAddress = "Network Address" Linux = "Linux Developer Community" LinuxDevice = "Linux USB Ethernet/RNDIS Gadget" -SourceDisk = "Ethernet/RNDIS Gadget Driver Install Disk" - +Vista_Property = "Optional Vista Property" -- cgit v1.1 From e41e134e34fbbfc7868f4784cd1370847462b879 Mon Sep 17 00:00:00 2001 From: Michal Nazarewicz Date: Mon, 21 Jun 2010 13:57:06 +0200 Subject: USB: gadget: g_serial: INF file updated Updated the INF file for g_serial gadget. It should work with most recent Windows systems now. Signed-off-by: Michal Nazarewicz Signed-off-by: Kyungmin Park Signed-off-by: Greg Kroah-Hartman --- Documentation/usb/gadget_serial.txt | 87 ++++------------------------- Documentation/usb/linux-cdc-acm.inf | 107 ++++++++++++++++++++++++++++++++++++ 2 files changed, 117 insertions(+), 77 deletions(-) create mode 100644 Documentation/usb/linux-cdc-acm.inf (limited to 'Documentation') diff --git a/Documentation/usb/gadget_serial.txt b/Documentation/usb/gadget_serial.txt index eac7df9..61e67f6 100644 --- a/Documentation/usb/gadget_serial.txt +++ b/Documentation/usb/gadget_serial.txt @@ -151,88 +151,23 @@ instructions below to install the host side driver. Installing the Windows Host ACM Driver -------------------------------------- -To use the Windows ACM driver you must have the files "gserial.inf" -and "usbser.sys" together in a folder on the Windows machine. - -The "gserial.inf" file is given here. - --------------------- CUT HERE -------------------- -[Version] -Signature="$Windows NT$" -Class=Ports -ClassGuid={4D36E978-E325-11CE-BFC1-08002BE10318} -Provider=%LINUX% -DriverVer=08/17/2004,0.0.2.0 -; Copyright (C) 2004 Al Borchers (alborchers@steinerpoint.com) - -[Manufacturer] -%LINUX%=GSerialDeviceList - -[GSerialDeviceList] -%GSERIAL%=GSerialInstall, USB\VID_0525&PID_A4A7 - -[DestinationDirs] -DefaultDestDir=10,System32\Drivers - -[GSerialInstall] -CopyFiles=GSerialCopyFiles -AddReg=GSerialAddReg - -[GSerialCopyFiles] -usbser.sys - -[GSerialAddReg] -HKR,,DevLoader,,*ntkern -HKR,,NTMPDriver,,usbser.sys -HKR,,EnumPropPages32,,"MsPorts.dll,SerialPortPropPageProvider" - -[GSerialInstall.Services] -AddService = usbser,0x0002,GSerialService - -[GSerialService] -DisplayName = %GSERIAL_DISPLAY_NAME% -ServiceType = 1 ; SERVICE_KERNEL_DRIVER -StartType = 3 ; SERVICE_DEMAND_START -ErrorControl = 1 ; SERVICE_ERROR_NORMAL -ServiceBinary = %10%\System32\Drivers\usbser.sys -LoadOrderGroup = Base - -[Strings] -LINUX = "Linux" -GSERIAL = "Gadget Serial" -GSERIAL_DISPLAY_NAME = "USB Gadget Serial Driver" --------------------- CUT HERE -------------------- - -The "usbser.sys" file comes with various versions of Windows. -For example, it can be found on Windows XP typically in - - C:\WINDOWS\Driver Cache\i386\driver.cab - -Or it can be found on the Windows 98SE CD in the "win98" folder -in the "DRIVER11.CAB" through "DRIVER20.CAB" cab files. You will -need the DOS "expand" program, the Cygwin "cabextract" program, or -a similar program to unpack these cab files and extract "usbser.sys". - -For example, to extract "usbser.sys" into the current directory -on Windows XP, open a DOS window and run a command like - - expand C:\WINDOWS\Driver~1\i386\driver.cab -F:usbser.sys . - -(Thanks to Nishant Kamat for pointing out this DOS command.) +To use the Windows ACM driver you must have the "linux-cdc-acm.inf" +file (provided along this document) which supports all recent versions +of Windows. When the gadget serial driver is loaded and the USB device connected to the Windows host with a USB cable, Windows should recognize the gadget serial device and ask for a driver. Tell Windows to find the -driver in the folder that contains "gserial.inf" and "usbser.sys". +driver in the folder that contains the "linux-cdc-acm.inf" file. For example, on Windows XP, when the gadget serial device is first plugged in, the "Found New Hardware Wizard" starts up. Select -"Install from a list or specific location (Advanced)", then on -the next screen select "Include this location in the search" and -enter the path or browse to the folder containing "gserial.inf" and -"usbser.sys". Windows will complain that the Gadget Serial driver -has not passed Windows Logo testing, but select "Continue anyway" -and finish the driver installation. +"Install from a list or specific location (Advanced)", then on the +next screen select "Include this location in the search" and enter the +path or browse to the folder containing the "linux-cdc-acm.inf" file. +Windows will complain that the Gadget Serial driver has not passed +Windows Logo testing, but select "Continue anyway" and finish the +driver installation. On Windows XP, in the "Device Manager" (under "Control Panel", "System", "Hardware") expand the "Ports (COM & LPT)" entry and you @@ -345,5 +280,3 @@ you should be able to send data back and forth between the gadget side and host side systems. Anything you type on the terminal window on the gadget side should appear in the terminal window on the host side and vice versa. - - diff --git a/Documentation/usb/linux-cdc-acm.inf b/Documentation/usb/linux-cdc-acm.inf new file mode 100644 index 0000000..14d2b87 --- /dev/null +++ b/Documentation/usb/linux-cdc-acm.inf @@ -0,0 +1,107 @@ +; Windows USB CDC ACM Setup File + +; Based on INF template which was: +; Copyright (c) 2000 Microsoft Corporation +; Copyright (c) 2007 Microchip Technology Inc. +; likely to be covered by the MLPL as found at: +; . +; For use only on Windows operating systems. + +[Version] +Signature="$Windows NT$" +Class=Ports +ClassGuid={4D36E978-E325-11CE-BFC1-08002BE10318} +Provider=%Linux% +DriverVer=11/15/2007,5.1.2600.0 + +[Manufacturer] +%Linux%=DeviceList, NTamd64 + +[DestinationDirs] +DefaultDestDir=12 + + +;------------------------------------------------------------------------------ +; Windows 2000/XP/Vista-32bit Sections +;------------------------------------------------------------------------------ + +[DriverInstall.nt] +include=mdmcpq.inf +CopyFiles=DriverCopyFiles.nt +AddReg=DriverInstall.nt.AddReg + +[DriverCopyFiles.nt] +usbser.sys,,,0x20 + +[DriverInstall.nt.AddReg] +HKR,,DevLoader,,*ntkern +HKR,,NTMPDriver,,USBSER.sys +HKR,,EnumPropPages32,,"MsPorts.dll,SerialPortPropPageProvider" + +[DriverInstall.nt.Services] +AddService=usbser, 0x00000002, DriverService.nt + +[DriverService.nt] +DisplayName=%SERVICE% +ServiceType=1 +StartType=3 +ErrorControl=1 +ServiceBinary=%12%\USBSER.sys + +;------------------------------------------------------------------------------ +; Vista-64bit Sections +;------------------------------------------------------------------------------ + +[DriverInstall.NTamd64] +include=mdmcpq.inf +CopyFiles=DriverCopyFiles.NTamd64 +AddReg=DriverInstall.NTamd64.AddReg + +[DriverCopyFiles.NTamd64] +USBSER.sys,,,0x20 + +[DriverInstall.NTamd64.AddReg] +HKR,,DevLoader,,*ntkern +HKR,,NTMPDriver,,USBSER.sys +HKR,,EnumPropPages32,,"MsPorts.dll,SerialPortPropPageProvider" + +[DriverInstall.NTamd64.Services] +AddService=usbser, 0x00000002, DriverService.NTamd64 + +[DriverService.NTamd64] +DisplayName=%SERVICE% +ServiceType=1 +StartType=3 +ErrorControl=1 +ServiceBinary=%12%\USBSER.sys + + +;------------------------------------------------------------------------------ +; Vendor and Product ID Definitions +;------------------------------------------------------------------------------ +; When developing your USB device, the VID and PID used in the PC side +; application program and the firmware on the microcontroller must match. +; Modify the below line to use your VID and PID. Use the format as shown +; below. +; Note: One INF file can be used for multiple devices with different +; VID and PIDs. For each supported device, append +; ",USB\VID_xxxx&PID_yyyy" to the end of the line. +;------------------------------------------------------------------------------ +[SourceDisksFiles] +[SourceDisksNames] +[DeviceList] +%DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7 + +[DeviceList.NTamd64] +%DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7 + + +;------------------------------------------------------------------------------ +; String Definitions +;------------------------------------------------------------------------------ +;Modify these strings to customize your device +;------------------------------------------------------------------------------ +[Strings] +Linux = "Linux Developer Community" +DESCRIPTION = "Gadget Serial" +SERVICE = "USB RS-232 Emulation Driver" -- cgit v1.1 From c7ba692294ef2f69a76b24b2ad45fc6c0ac0d497 Mon Sep 17 00:00:00 2001 From: Michal Nazarewicz Date: Mon, 21 Jun 2010 13:57:07 +0200 Subject: USB: gadget: g_multi: added documentation and INF files A short documentation of the g_multi driver along with INF files for Windows XP SP3 are provided. Signed-off-by: Michal Nazarewicz Signed-off-by: Kyungmin Park Signed-off-by: Greg Kroah-Hartman --- Documentation/usb/gadget_multi.txt | 150 ++++++++++++++++++++++++++++++++++++ Documentation/usb/linux-cdc-acm.inf | 4 +- Documentation/usb/linux.inf | 6 +- 3 files changed, 155 insertions(+), 5 deletions(-) create mode 100644 Documentation/usb/gadget_multi.txt (limited to 'Documentation') diff --git a/Documentation/usb/gadget_multi.txt b/Documentation/usb/gadget_multi.txt new file mode 100644 index 0000000..80f4ef0 --- /dev/null +++ b/Documentation/usb/gadget_multi.txt @@ -0,0 +1,150 @@ + -*- org -*- + +* Overview + +The Multifunction Composite Gadget (or g_multi) is a composite gadget +that makes extensive use of the composite framework to provide +a... multifunction gadget. + +In it's standard configuration it provides a single USB configuration +with RNDIS[1] (that is Ethernet), USB CDC[2] ACM (that is serial) and +USB Mass Storage functions. + +A CDC ECM (Ethernet) function may be turned on via a Kconfig option +and RNDIS can be turned off. If they are both enabled the gadget will +have two configurations -- one with RNDIS and another with CDC ECM[3]. + +Please not that if you use non-standard configuration (that is enable +CDC ECM) you may need to change vendor and/or product ID. + +* Host drivers + +To make use of the gadget one needs to make it work on host side -- +without that there's no hope of achieving anything with the gadget. +As one might expect, things one need to do very from system to system. + +** Linux host drivers + +Since the gadget uses standard composite framework and appears as such +to Linux host it does not need any additional drivers on Linux host +side. All the functions are handled by respective drivers developed +for them. + +This is also true for two configuration set-up with RNDIS +configuration being the first one. Linux host will use the second +configuration with CDC ECM which should work better under Linux. + +** Windows host drivers + +For the gadget two work under Windows two conditions have to be met: + +*** Detecting as composite gadget + +First of all, Windows need to detect the gadget as an USB composite +gadget which on its own have some conditions[4]. If they are met, +Windows lets USB Generic Parent Driver[5] handle the device which then +tries to much drivers for each individual interface (sort of, don't +get into too many details). + +The good news is: you do not have to worry about most of the +conditions! + +The only thing to worry is that the gadget has to have a single +configuration so a dual RNDIS and CDC ECM gadget won't work unless you +create a proper INF -- and of course, if you do submit it! + +*** Installing drivers for each function + +The other, trickier thing is making Windows install drivers for each +individual function. + +For mass storage it is trivial since Windows detect it's an interface +implementing USB Mass Storage class and selects appropriate driver. + +Things are harder with RDNIS and CDC ACM. + +**** RNDIS + +To make Windows select RNDIS drivers for the first function in the +gadget, one needs to use the [[file:linux.inf]] file provided with this +document. It "attaches" Window's RNDIS driver to the first interface +of the gadget. + +Please note, that while testing we encountered some issues[6] when +RNDIS was not the first interface. You do not need to worry abut it +unless you are trying to develop your own gadget in which case watch +out for this bug. + +**** CDC ACM + +Similarly, [[file:linux-cdc-acm.inf]] is provided for CDC ACM. + +**** Customising the gadget + +If you intend to hack the g_multi gadget be advised that rearranging +functions will obviously change interface numbers for each of the +functionality. As an effect provided INFs won't work since they have +interface numbers hard-coded in them (it's not hard to change those +though[7]). + +This also means, that after experimenting with g_multi and changing +provided functions one should change gadget's vendor and/or product ID +so there will be no collision with other customised gadgets or the +original gadget. + +Failing to comply may cause brain damage after wondering for hours why +things don't work as intended before realising Windows have cached +some drivers information (changing USB port may sometimes help plus +you might try using USBDeview[8] to remove the phantom device). + +**** INF testing + +Provided INF files have been tested on Windows XP SP3, Windows Vista +and Windows 7, all 32-bit versions. It should work on 64-bit versions +as well. It most likely won't work on Windows prior to Windows XP +SP2. + +** Other systems + +At this moment, drivers for any other systems have not been tested. +Knowing how MacOS is based on BSD and BSD is an Open Source it is +believed that it should (read: "I have no idea whether it will") work +out-of-the-box. + +For more exotic systems I have even less to say... + +Any testing and drivers *are* *welcome*! + +* Authors + +This document has been written by Michal Nazarewicz +([[mailto:mina86@mina86.com]]). INF files have been hacked with +support of Marek Szyprowski ([[mailto:m.szyprowski@samsung.com]]) and +Xiaofan Chen ([[mailto:xiaofanc@gmail.com]]) basing on the MS RNDIS +template[9], Microchip's CDC ACM INF file and David Brownell's +([[mailto:dbrownell@users.sourceforge.net]]) original INF files. + +* Footnotes + +[1] Remote Network Driver Interface Specification, +[[http://msdn.microsoft.com/en-us/library/ee484414.aspx]]. + +[2] Communications Device Class Abstract Control Model, spec for this +and other USB classes can be found at +[[http://www.usb.org/developers/devclass_docs/]]. + +[3] CDC Ethernet Control Model. + +[4] [[http://msdn.microsoft.com/en-us/library/ff537109(v=VS.85).aspx]] + +[5] [[http://msdn.microsoft.com/en-us/library/ff539234(v=VS.85).aspx]] + +[6] To put it in some other nice words, Windows failed to respond to +any user input. + +[7] You may find [[http://www.cygnal.org/ubb/Forum9/HTML/001050.html]] +useful. + +[8] http://www.nirsoft.net/utils/usb_devices_view.html + +[9] [[http://msdn.microsoft.com/en-us/library/ff570620.aspx]] diff --git a/Documentation/usb/linux-cdc-acm.inf b/Documentation/usb/linux-cdc-acm.inf index 14d2b87..612e722 100644 --- a/Documentation/usb/linux-cdc-acm.inf +++ b/Documentation/usb/linux-cdc-acm.inf @@ -90,10 +90,10 @@ ServiceBinary=%12%\USBSER.sys [SourceDisksFiles] [SourceDisksNames] [DeviceList] -%DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7 +%DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7, USB\VID_0525&PID_A4AB&MI_02 [DeviceList.NTamd64] -%DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7 +%DESCRIPTION%=DriverInstall, USB\VID_0525&PID_A4A7, USB\VID_0525&PID_A4AB&MI_02 ;------------------------------------------------------------------------------ diff --git a/Documentation/usb/linux.inf b/Documentation/usb/linux.inf index b9e538c..4dee958 100644 --- a/Documentation/usb/linux.inf +++ b/Documentation/usb/linux.inf @@ -18,15 +18,15 @@ DriverVer = 06/21/2006,6.0.6000.16384 ; Decoration for x86 architecture [LinuxDevices.NTx86] -%LinuxDevice% = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2 +%LinuxDevice% = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2, USB\VID_0525&PID_a4ab&MI_00 ; Decoration for x64 architecture [LinuxDevices.NTamd64] -%LinuxDevice% = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2 +%LinuxDevice% = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2, USB\VID_0525&PID_a4ab&MI_00 ; Decoration for ia64 architecture [LinuxDevices.NTia64] -%LinuxDevice% = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2 +%LinuxDevice% = RNDIS.NT.5.1, USB\VID_0525&PID_a4a2, USB\VID_0525&PID_a4ab&MI_00 ;@@@ This is the common setting for setup [ControlFlags] -- cgit v1.1 From a93917d39fc388c4761d2530af82513e2d3bf9f6 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 22 Jul 2010 17:53:56 +0300 Subject: USB: gadget: storage: optional SCSI WRITE FUA bit MS Windows mounts removable storage in "Removal optimized mode" by default. All the writes to the media are synchronous which is achieved by setting FUA (Force Unit Access) bit in SCSI WRITE(10,12) commands. This prevents I/O requests aggregation in block layer dramatically decreasing performance. This patch brings an option to accept or ignore mentioned bit a) via specifying module parameter "nofua", or b) through sysfs entry /sys/devices/platform/_UDC_/gadget/gadget-lunX/nofua (_UDC_ is the name of the USB Device Controller driver) Patch is based on the work that was done by Denis Karpov for Maemo 5 platform. Signed-off-by: Andy Shevchenko Acked-by: Alan Stern Cc: Denis Karpov Cc: Adrian Hunter Cc: David Brownell Signed-off-by: Greg Kroah-Hartman --- .../ABI/testing/sysfs-devices-platform-_UDC_-gadget | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-platform-_UDC_-gadget b/Documentation/ABI/testing/sysfs-devices-platform-_UDC_-gadget index 3403402..d548eaa 100644 --- a/Documentation/ABI/testing/sysfs-devices-platform-_UDC_-gadget +++ b/Documentation/ABI/testing/sysfs-devices-platform-_UDC_-gadget @@ -7,3 +7,15 @@ Description: 0 -> resumed (_UDC_ is the name of the USB Device Controller driver) + +What: /sys/devices/platform/_UDC_/gadget/gadget-lunX/nofua +Date: July 2010 +Contact: Andy Shevchenko +Description: + Show or set the reaction on the FUA (Force Unit Access) bit in + the SCSI WRITE(10,12) commands when a gadget in USB Mass + Storage mode. + + Possible values are: + 1 -> ignore the FUA flag + 0 -> obey the FUA flag -- cgit v1.1 From 0f7436a5b09d9c6d67ed272be9641af003b1b3b2 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Mon, 9 Aug 2010 16:30:40 -0700 Subject: docbook: fixup media support files for htmldocs also 'make htmldocs' produces errors due to missing a supporting media file, so add 'xmldoclinks' to the htmldocs dependencies so that the needed supporting file will be present. Documentation/DocBook/media.xml:4: warning: failed to load external entity "Documentation/DocBook/media-entities.tmpl" Signed-off-by: Randy Dunlap Acked-by: Mauro Carvalho Chehab Signed-off-by: Linus Torvalds --- Documentation/DocBook/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index c7e5dc7..4b603c5 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -45,7 +45,7 @@ PDF := $(patsubst %.xml, %.pdf, $(BOOKS)) pdfdocs: $(PDF) HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS))) -htmldocs: $(HTML) +htmldocs: $(HTML) xmldoclinks $(call build_main_index) $(call build_images) -- cgit v1.1 From d2800800d795350435936b08afb402ed9aab1e66 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Wed, 11 Aug 2010 23:04:08 -0600 Subject: documentation: fix erroneous email address. Hey, at least it has both l's. Reported-by: Marin Mitov Signed-off-by: Rusty Russell --- Documentation/cpu-hotplug.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index a99d703..45d5a21 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt @@ -2,7 +2,7 @@ Maintainers: CPU Hotplug Core: - Rusty Russell + Rusty Russell Srivatsa Vaddagiri i386: Zwane Mwaikambo -- cgit v1.1 From 05e57eec23eadf6641911ff07560f9ec7c6457c1 Mon Sep 17 00:00:00 2001 From: Roy Zang Date: Tue, 10 Aug 2010 18:02:00 -0700 Subject: dts: add sdhci,auto-cmd12 field for p4080 device tree Signed-off-by: Roy Zang Cc: Jerry Huang Cc: Benjamin Herrenschmidt Cc: Kumar Gala Cc: Grant Likely Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/powerpc/dts-bindings/fsl/esdhc.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt index 8a00407..64bcb8b 100644 --- a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt +++ b/Documentation/powerpc/dts-bindings/fsl/esdhc.txt @@ -14,6 +14,8 @@ Required properties: reports inverted write-protect state; - sdhci,1-bit-only : (optional) specifies that a controller can only handle 1-bit data transfers. + - sdhci,auto-cmd12: (optional) specifies that a controller can + only handle auto CMD12. Example: -- cgit v1.1 From 9c4ba9466117b16a2b85034bb87db528aaeb3f07 Mon Sep 17 00:00:00 2001 From: David Brownell Date: Tue, 10 Aug 2010 18:02:24 -0700 Subject: gpiolib: decouple might_sleep_if() from DEBUG Be more consistent about runtime programming interface abuse warnings, which can reduce some confusion and trigger bugfixes. Based on an observation and patch from Jani Nikula. Also update doc to highlight some sleeping-call issues and to match some recent changes. Signed-off-by: David Brownell Cc: Jani Nikula Cc: "Ryan Mallon" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/gpio.txt | 35 +++++++++++++++++++++++++++++------ 1 file changed, 29 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt index c2c6e9b..d96a6db 100644 --- a/Documentation/gpio.txt +++ b/Documentation/gpio.txt @@ -158,10 +158,11 @@ and configure pullups/pulldowns appropriately.) Spinlock-Safe GPIO access ------------------------- Most GPIO controllers can be accessed with memory read/write instructions. -That doesn't need to sleep, and can safely be done from inside IRQ handlers. -(That includes hardirq contexts on RT kernels.) +Those don't need to sleep, and can safely be done from inside hard +(nonthreaded) IRQ handlers and similar contexts. -Use these calls to access such GPIOs: +Use the following calls to access such GPIOs, +for which gpio_cansleep() will always return false (see below): /* GPIO INPUT: return zero or nonzero */ int gpio_get_value(unsigned gpio); @@ -210,9 +211,31 @@ To access such GPIOs, a different set of accessors is defined: /* GPIO OUTPUT, might sleep */ void gpio_set_value_cansleep(unsigned gpio, int value); -Other than the fact that these calls might sleep, and will not be ignored -for GPIOs that can't be accessed from IRQ handlers, these calls act the -same as the spinlock-safe calls. + +Accessing such GPIOs requires a context which may sleep, for example +a threaded IRQ handler, and those accessors must be used instead of +spinlock-safe accessors without the cansleep() name suffix. + +Other than the fact that these accessors might sleep, and will work +on GPIOs that can't be accessed from hardIRQ handlers, these calls act +the same as the spinlock-safe calls. + + ** IN ADDITION ** calls to setup and configure such GPIOs must be made +from contexts which may sleep, since they may need to access the GPIO +controller chip too: (These setup calls are usually made from board +setup or driver probe/teardown code, so this is an easy constraint.) + + gpio_direction_input() + gpio_direction_output() + gpio_request() + +## gpio_request_one() +## gpio_request_array() +## gpio_free_array() + + gpio_free() + gpio_set_debounce() + Claiming and Releasing GPIOs -- cgit v1.1 From 79872e07ab92557e2a7eeb55452f262e179db5bc Mon Sep 17 00:00:00 2001 From: Joe Perches Date: Tue, 10 Aug 2010 18:02:50 -0700 Subject: Documentation/networking/wavelan.txt: deleted, not in tree Commit 1d794e3b353b ("Staging: wavelan: delete the driver") removed the source, so remove the documentation as well. Signed-off-by: Joe Perches Cc: Jean Tourrilhes Acked-by: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/networking/wavelan.txt | 74 ------------------------------------ 1 file changed, 74 deletions(-) delete mode 100644 Documentation/networking/wavelan.txt (limited to 'Documentation') diff --git a/Documentation/networking/wavelan.txt b/Documentation/networking/wavelan.txt deleted file mode 100644 index 90e0ac4..0000000 --- a/Documentation/networking/wavelan.txt +++ /dev/null @@ -1,74 +0,0 @@ - The Wavelan drivers saga - ------------------------ - - By Jean Tourrilhes - - The Wavelan is a Radio network adapter designed by -Lucent. Under this generic name is hidden quite a variety of hardware, -and many Linux driver to support it. - The get the full story on Wireless LANs, please consult : - http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/ - -"wavelan" driver (old ISA Wavelan) ----------------- - o Config : Network device -> Wireless LAN -> AT&T WaveLAN - o Location : .../drivers/net/wireless/wavelan* - o in-line doc : .../drivers/net/wireless/wavelan.p.h - o on-line doc : - http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wavelan.html - - This is the driver for the ISA version of the first generation -of the Wavelan, now discontinued. The device is 2 Mb/s, composed of a -Intel 82586 controller and a Lucent Modem, and is NOT 802.11 compliant. - The driver has been tested with the following hardware : - o Wavelan ISA 915 MHz (full length ISA card) - o Wavelan ISA 915 MHz 2.0 (half length ISA card) - o Wavelan ISA 2.4 GHz (full length ISA card, fixed frequency) - o Wavelan ISA 2.4 GHz 2.0 (half length ISA card, frequency selectable) - o Above cards with the optional DES encryption feature - -"wavelan_cs" driver (old Pcmcia Wavelan) -------------------- - o Config : Network device -> PCMCIA network -> - Pcmcia Wireless LAN -> AT&T/Lucent WaveLAN - o Location : .../drivers/net/pcmcia/wavelan* - o in-line doc : .../drivers/net/pcmcia/wavelan_cs.h - o on-line doc : - http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wavelan.html - - This is the driver for the PCMCIA version of the first -generation of the Wavelan, now discontinued. The device is 2 Mb/s, -composed of a Intel 82593 controller (totally different from the 82586) -and a Lucent Modem, and NOT 802.11 compatible. - The driver has been tested with the following hardware : - o Wavelan Pcmcia 915 MHz 2.0 (Pcmcia card + separate - modem/antenna block) - o Wavelan Pcmcia 2.4 GHz 2.0 (Pcmcia card + separate - modem/antenna block) - -"wvlan_cs" driver (Wavelan IEEE, GPL) ------------------ - o Config : Not yet in kernel - o Location : Pcmcia package 3.1.10+ - o on-line doc : - http://web.archive.org/web/*/http://www.fasta.fh-dortmund.de/users/andy/wvlan/ - - This is the driver for the current generation of Wavelan IEEE, -which is 802.11 compatible. Depending on version, it is 2 Mb/s or 11 -Mb/s, with or without encryption, all implemented in Lucent specific -DSP (the Hermes). - This is a GPL full source PCMCIA driver (ISA is just a Pcmcia -card with ISA-Pcmcia bridge). - -"wavelan2_cs" driver (Wavelan IEEE, binary) --------------------- - o Config : Not yet in kernel - o Location : ftp://sourceforge.org/pcmcia/contrib/ - - This driver support exactly the same hardware as the previous -driver, the main difference is that it is based on a binary library -and supported by Lucent. - - I hope it clears the confusion ;-) - - Jean -- cgit v1.1 From a435600e5b43238cfa84bc3d3e66fe02a10b3318 Mon Sep 17 00:00:00 2001 From: Ben Hutchings Date: Tue, 10 Aug 2010 18:02:51 -0700 Subject: docbook: need xmldoclinks for all doc types $ rm -rf build $ mkdir build $ cp .config build $ make O=build htmldocs ... xmlto: linux-2.6/build/Documentation/DocBook/media.xml does not validate (status 3) xmlto: Fix document syntax or use --skip-validation option linux-2.6/build/Documentation/DocBook/media.xml:4: warning: failed to load external entity "linux-2.6/build/Documentation/DocBook/media-entities.tmpl" We need the xmldoclinks built for any document types built from the XML sources. Signed-off-by: Ben Hutchings Acked-by: Andy Whitcroft Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/DocBook/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 4b603c5..34929f2 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -35,7 +35,7 @@ PS_METHOD = $(prefer-db2x) PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs xmldoclinks BOOKS := $(addprefix $(obj)/,$(DOCBOOKS)) -xmldocs: $(BOOKS) xmldoclinks +xmldocs: $(BOOKS) sgmldocs: xmldocs PS := $(patsubst %.xml, %.ps, $(BOOKS)) @@ -95,7 +95,7 @@ define rule_docproc ) > $(dir $@).$(notdir $@).cmd endef -%.xml: %.tmpl FORCE +%.xml: %.tmpl xmldoclinks FORCE $(call if_changed_rule,docproc) ### -- cgit v1.1 From a3038ea5e2d446a2baf4f2893c1edea9e4e48c26 Mon Sep 17 00:00:00 2001 From: Huang Shijie Date: Tue, 10 Aug 2010 18:02:52 -0700 Subject: Documentation/00-INDEX: remove reference to exception.txt The exception.txt has been removed from the Documentation directory. So update the index file for it. Signed-off-by: Huang Shijie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/00-INDEX | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 5405f7a..9e642c5 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -130,8 +130,6 @@ edac.txt - information on EDAC - Error Detection And Correction eisa.txt - info on EISA bus support. -exception.txt - - how Linux v2.2 handles exceptions without verify_area etc. fault-injection/ - dir with docs about the fault injection capabilities infrastructure. fb/ -- cgit v1.1 From 2b24706a798d07cf40534d7763f608045e42e15f Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Tue, 10 Aug 2010 18:02:53 -0700 Subject: Documentation/padata.txt: fix typos etc. Fix typos & grammar. Use CPU instead of cpu in text. Signed-off-by: Randy Dunlap Acked-by: Steffen Klassert Cc: Herbert Xu Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/padata.txt | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/padata.txt b/Documentation/padata.txt index 473ebf2..7ddfe21 100644 --- a/Documentation/padata.txt +++ b/Documentation/padata.txt @@ -19,7 +19,7 @@ overall control of how tasks are to be run: The pcpumask describes which processors will be used to execute work submitted to this instance in parallel. The cbcpumask defines which -processors are allowed to use as the serialization callback processor. +processors are allowed to be used as the serialization callback processor. The workqueue wq is where the work will actually be done; it should be a multithreaded queue, naturally. @@ -30,10 +30,10 @@ cpumasks this helper function can be used: Note: Padata maintains two kinds of cpumasks internally. The user supplied cpumasks, submitted by padata_alloc/padata_alloc_possible and the 'usable' -cpumasks. The usable cpumasks are always the subset of active cpus in the -user supplied cpumasks, these are the cpumasks padata actually use. So -it is legal to supply a cpumask to padata that contains offline cpus. -Once a offline cpu in the user supplied cpumask comes online, padata +cpumasks. The usable cpumasks are always a subset of active CPUs in the +user supplied cpumasks; these are the cpumasks padata actually uses. So +it is legal to supply a cpumask to padata that contains offline CPUs. +Once an offline CPU in the user supplied cpumask comes online, padata is going to use it. There are functions for enabling and disabling the instance: @@ -44,7 +44,7 @@ There are functions for enabling and disabling the instance: These functions are setting or clearing the "PADATA_INIT" flag; if that flag is not set, other functions will refuse to work. padata_start returns zero on success (flag set) or -EINVAL if the -padata cpumask contains no active cpu (flag not set). +padata cpumask contains no active CPU (flag not set). padata_stop clears the flag and blocks until the padata instance is unused. @@ -63,11 +63,11 @@ done with great frequency. It's possible to change both cpumasks of a padata instance with padata_set_cpumasks by specifying the cpumasks for parallel execution (pcpumask) -and for the serial callback function (cbcpumask). padata_set_cpumask is to +and for the serial callback function (cbcpumask). padata_set_cpumask is used to change just one of the cpumasks. Here cpumask_type is one of PADATA_CPU_SERIAL, PADATA_CPU_PARALLEL and cpumask specifies the new cpumask to use. -To simply add or remove one cpu from a certain cpumask the functions -padata_add_cpu/padata_remove_cpu are used. cpu specifies the cpu to add or +To simply add or remove one CPU from a certain cpumask the functions +padata_add_cpu/padata_remove_cpu are used. cpu specifies the CPU to add or remove and mask is one of PADATA_CPU_SERIAL, PADATA_CPU_PARALLEL. If a user is interested in padata cpumask changes, he can register to @@ -82,7 +82,7 @@ To unregister from that notifier: struct notifier_block *nblock); The padata cpumask change notifier notifies about changes of the usable -cpumasks, i.e. the subset of active cpus in the user supplied cpumask. +cpumasks, i.e. the subset of active CPUs in the user supplied cpumask. Padata calls the notifier chain with: @@ -92,7 +92,7 @@ Padata calls the notifier chain with: Here cpumask_change_notifier is registered notifier, notification_mask is one of PADATA_CPU_SERIAL, PADATA_CPU_PARALLEL and cpumask is a pointer -to a struct padata_cpumask that contains the new cpumask informations. +to a struct padata_cpumask that contains the new cpumask information. Actually submitting work to the padata instance requires the creation of a padata_priv structure: @@ -104,7 +104,7 @@ padata_priv structure: }; This structure will almost certainly be embedded within some larger -structure specific to the work to be done. Most its fields are private to +structure specific to the work to be done. Most of its fields are private to padata, but the structure should be zeroed at initialisation time, and the parallel() and serial() functions should be provided. Those functions will be called in the process of getting the work done as we will see -- cgit v1.1 From 3b9c6c11f519718d618f5d7c9508daf78b207f6f Mon Sep 17 00:00:00 2001 From: FUJITA Tomonori Date: Tue, 10 Aug 2010 18:03:25 -0700 Subject: dma-mapping: remove dma_is_consistent API Architectures implement dma_is_consistent() in different ways (some misinterpret the definition of API in DMA-API.txt). So it hasn't been so useful for drivers. We have only one user of the API in tree. Unlikely out-of-tree drivers use the API. Even if we fix dma_is_consistent() in some architectures, it doesn't look useful at all. It was invented long ago for some old systems that can't allocate coherent memory at all. It's better to export only APIs that are definitely necessary for drivers. Let's remove this API. Signed-off-by: FUJITA Tomonori Cc: James Bottomley Reviewed-by: Konrad Rzeszutek Wilk Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/DMA-API.txt | 6 ------ 1 file changed, 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 05e2ae2..fe23269 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -456,12 +456,6 @@ be identical to those passed in (and returned by dma_alloc_noncoherent()). int -dma_is_consistent(struct device *dev, dma_addr_t dma_handle) - -Returns true if the device dev is performing consistent DMA on the memory -area pointed to by the dma_handle. - -int dma_get_cache_alignment(void) Returns the processor cache alignment. This is the absolute minimum -- cgit v1.1 From c31e74c4c34fa863393c28b95409aee934b4f8e1 Mon Sep 17 00:00:00 2001 From: FUJITA Tomonori Date: Tue, 10 Aug 2010 18:03:25 -0700 Subject: Documentation: DMA-API-HOWTO.txt: add multiple types of IOMMUs support Signed-off-by: FUJITA Tomonori Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/DMA-API-HOWTO.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index 98ce517..3c4e071 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt @@ -753,6 +753,16 @@ to "Closing". alignment constraints (e.g. the alignment constraints about 64-bit objects). +3) Supporting multiple types of IOMMUs + + If your architecture needs to support multiple types of IOMMUs, you + can use include/linux/asm-generic/dma-mapping-common.h. It's a + library to support the DMA API with multiple types of IOMMUs. Lots + of architectures (x86, powerpc, sh, alpha, ia64, microblaze and + sparc) use it. Choose one to see how it can be used. If you need to + support multiple types of IOMMUs in a single system, the example of + x86 or powerpc helps. + Closing This document, and the API itself, would not be in its current -- cgit v1.1 From 175833635fe6e96548ccab802ed0b0f25251cbbe Mon Sep 17 00:00:00 2001 From: FUJITA Tomonori Date: Tue, 10 Aug 2010 18:03:26 -0700 Subject: pci: add PCI DMA unamp state API to feature-removal-schedule.txt It was replaced with the DMA unamp state API (which can be used for any bus). Signed-off-by: FUJITA Tomonori Cc: Jesse Barnes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/feature-removal-schedule.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index b16cbe4..1ebf5fd 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -547,3 +547,12 @@ Why: superseded by acpi_sleep=nonvs Who: Rafael J. Wysocki ---------------------------- + +What: PCI DMA unmap state API +When: August 2012 +Why: PCI DMA unmap state API (include/linux/pci-dma.h) was replaced + with DMA unmap state API (DMA unmap state API can be used for + any bus). +Who: FUJITA Tomonori + +---------------------------- -- cgit v1.1 From a35274cd109222e40716485d856b3ccc9ffccb37 Mon Sep 17 00:00:00 2001 From: FUJITA Tomonori Date: Tue, 10 Aug 2010 18:03:26 -0700 Subject: dma-mapping: add DMA_xxBIT_MASK to feature-removal-schedule.txt DMA_xxBIT_MASK macros were marked as deprecated in June 2009. One more year is long enough, I think. Signed-off-by: FUJITA Tomonori Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/feature-removal-schedule.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 1ebf5fd..842aa9d 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -556,3 +556,11 @@ Why: PCI DMA unmap state API (include/linux/pci-dma.h) was replaced Who: FUJITA Tomonori ---------------------------- + +What: DMA_xxBIT_MASK macros +When: Jun 2011 +Why: DMA_xxBIT_MASK macros were replaced with DMA_BIT_MASK() macros. +Who: FUJITA Tomonori + +---------------------------- + -- cgit v1.1 From c7ff0d9c92435e836e13aaa8d0e56d4000424bcc Mon Sep 17 00:00:00 2001 From: TAMUKI Shoichi Date: Tue, 10 Aug 2010 18:03:28 -0700 Subject: panic: keep blinking in spite of long spin timer mode To keep panic_timeout accuracy when running under a hypervisor, the current implementation only spins on long time (1 second) calls to mdelay. That brings a good effect, but the problem is the keyboard LEDs don't blink at all on that situation. This patch changes to call to panic_blink_enter() between every mdelay and keeps blinking in spite of long spin timer mode. The time to call to mdelay is now 100ms. Even this change will keep panic_timeout accuracy enough when running under a hypervisor. Signed-off-by: TAMUKI Shoichi Cc: Ben Dooks Cc: Russell King Acked-by: Dmitry Torokhov Cc: Anton Blanchard Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/kernel-parameters.txt | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index d529b13..873b680 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -915,9 +915,6 @@ and is between 256 and 4096 characters. It is defined in the file controller i8042.nopnp [HW] Don't use ACPIPnP / PnPBIOS to discover KBD/AUX controllers - i8042.panicblink= - [HW] Frequency with which keyboard LEDs should blink - when kernel panics (default is 0.5 sec) i8042.reset [HW] Reset the controller during init and cleanup i8042.unlock [HW] Unlock (ignore) the keylock -- cgit v1.1 From 2e956fb320568cc70861761483e2f0e2db75fd66 Mon Sep 17 00:00:00 2001 From: Stefani Seibold Date: Tue, 10 Aug 2010 18:03:38 -0700 Subject: kfifo: replace the old non generic API Simply replace the whole kfifo.c and kfifo.h files with the new generic version and fix the kerneldoc API template file. Signed-off-by: Stefani Seibold Cc: Greg KH Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/DocBook/kernel-api.tmpl | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index 44b3def..a20c6f6 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -132,7 +132,6 @@ X!Ilib/string.c FIFO Buffer kfifo interface !Iinclude/linux/kfifo.h -!Ekernel/kfifo.c -- cgit v1.1 From 9a94241afcc9a481691a9c29b7460217925b59b8 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Wed, 11 Aug 2010 18:20:56 +0200 Subject: i2c: Add support for custom probe function The probe method used by i2c_new_probed_device() may not be suitable for all cases. Let the caller provide its own, optional probe function. Signed-off-by: Jean Delvare Acked-by: Mauro Carvalho Chehab --- Documentation/i2c/instantiating-devices | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices index e894902..87da405 100644 --- a/Documentation/i2c/instantiating-devices +++ b/Documentation/i2c/instantiating-devices @@ -102,7 +102,7 @@ static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev) memset(&i2c_info, 0, sizeof(struct i2c_board_info)); strlcpy(i2c_info.name, "isp1301_pnx", I2C_NAME_SIZE); isp1301_i2c_client = i2c_new_probed_device(i2c_adap, &i2c_info, - normal_i2c); + normal_i2c, NULL); i2c_put_adapter(i2c_adap); (...) } -- cgit v1.1 From 7e507eb6432afdd798d4c6dccf949b8c43ef151c Mon Sep 17 00:00:00 2001 From: Peter Rajnoha Date: Thu, 12 Aug 2010 04:14:05 +0100 Subject: dm: allow autoloading of dm mod Add devname:mapper/control and MAPPER_CTRL_MINOR module alias to support dm-mod module autoloading. Signed-off-by: Kay Sievers Signed-off-by: Peter Rajnoha Signed-off-by: Alasdair G Kergon --- Documentation/devices.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devices.txt b/Documentation/devices.txt index f2da781..d0d1df6 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -445,6 +445,7 @@ Your cooperation is appreciated. 233 = /dev/kmview View-OS A process with a view 234 = /dev/btrfs-control Btrfs control device 235 = /dev/autofs Autofs control device + 236 = /dev/mapper/control Device-Mapper control device 240-254 Reserved for local use 255 Reserved for MISC_DYNAMIC_MINOR -- cgit v1.1 From dfe86cba7676d58db8de7e623f5e72f1b0d3ca35 Mon Sep 17 00:00:00 2001 From: Adrian Hunter Date: Wed, 11 Aug 2010 14:17:46 -0700 Subject: mmc: add erase, secure erase, trim and secure trim operations SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4 cards can support secure erase, trim and secure trim operations that are all variants of the basic erase command. SD/MMC device attributes "erase_size" and "preferred_erase_size" have been added. "erase_size" is the minimum size, in bytes, of an erase operation. For MMC, "erase_size" is the erase group size reported by the card. Note that "erase_size" does not apply to trim or secure trim operations where the minimum size is always one 512 byte sector. For SD, "erase_size" is 512 if the card is block-addressed, 0 otherwise. SD/MMC cards can erase an arbitrarily large area up to and including the whole card. When erasing a large area it may be desirable to do it in smaller chunks for three reasons: 1. A single erase command will make all other I/O on the card wait. This is not a problem if the whole card is being erased, but erasing one partition will make I/O for another partition on the same card wait for the duration of the erase - which could be a several minutes. 2. To be able to inform the user of erase progress. 3. The erase timeout becomes too large to be very useful. Because the erase timeout contains a margin which is multiplied by the size of the erase area, the value can end up being several minutes for large areas. "erase_size" is not the most efficient unit to erase (especially for SD where it is just one sector), hence "preferred_erase_size" provides a good chunk size for erasing large areas. For MMC, "preferred_erase_size" is the high-capacity erase size if a card specifies one, otherwise it is based on the capacity of the card. For SD, "preferred_erase_size" is the allocation unit size specified by the card. "preferred_erase_size" is in bytes. Signed-off-by: Adrian Hunter Acked-by: Jens Axboe Cc: Kyungmin Park Cc: Madhusudhan Chikkature Cc: Christoph Hellwig Cc: Ben Gardiner Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/00-INDEX | 2 ++ Documentation/mmc/00-INDEX | 4 +++ Documentation/mmc/mmc-dev-attrs.txt | 56 +++++++++++++++++++++++++++++++++++++ 3 files changed, 62 insertions(+) create mode 100644 Documentation/mmc/00-INDEX create mode 100644 Documentation/mmc/mmc-dev-attrs.txt (limited to 'Documentation') diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 9e642c5..8dfc670 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -232,6 +232,8 @@ memory.txt - info on typical Linux memory problems. mips/ - directory with info about Linux on MIPS architecture. +mmc/ + - directory with info about the MMC subsystem mono.txt - how to execute Mono-based .NET binaries with the help of BINFMT_MISC. mutex-design.txt diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX new file mode 100644 index 0000000..fca586f --- /dev/null +++ b/Documentation/mmc/00-INDEX @@ -0,0 +1,4 @@ +00-INDEX + - this file +mmc-dev-attrs.txt + - info on SD and MMC device attributes diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt new file mode 100644 index 0000000..ff2bd68 --- /dev/null +++ b/Documentation/mmc/mmc-dev-attrs.txt @@ -0,0 +1,56 @@ +SD and MMC Device Attributes +============================ + +All attributes are read-only. + + cid Card Identifaction Register + csd Card Specific Data Register + scr SD Card Configuration Register (SD only) + date Manufacturing Date (from CID Register) + fwrev Firmware/Product Revision (from CID Register) (SD and MMCv1 only) + hwrev Hardware/Product Revision (from CID Register) (SD and MMCv1 only) + manfid Manufacturer ID (from CID Register) + name Product Name (from CID Register) + oemid OEM/Application ID (from CID Register) + serial Product Serial Number (from CID Register) + erase_size Erase group size + preferred_erase_size Preferred erase size + +Note on Erase Size and Preferred Erase Size: + + "erase_size" is the minimum size, in bytes, of an erase + operation. For MMC, "erase_size" is the erase group size + reported by the card. Note that "erase_size" does not apply + to trim or secure trim operations where the minimum size is + always one 512 byte sector. For SD, "erase_size" is 512 + if the card is block-addressed, 0 otherwise. + + SD/MMC cards can erase an arbitrarily large area up to and + including the whole card. When erasing a large area it may + be desirable to do it in smaller chunks for three reasons: + 1. A single erase command will make all other I/O on + the card wait. This is not a problem if the whole card + is being erased, but erasing one partition will make + I/O for another partition on the same card wait for the + duration of the erase - which could be a several + minutes. + 2. To be able to inform the user of erase progress. + 3. The erase timeout becomes too large to be very + useful. Because the erase timeout contains a margin + which is multiplied by the size of the erase area, + the value can end up being several minutes for large + areas. + + "erase_size" is not the most efficient unit to erase + (especially for SD where it is just one sector), + hence "preferred_erase_size" provides a good chunk + size for erasing large areas. + + For MMC, "preferred_erase_size" is the high-capacity + erase size if a card specifies one, otherwise it is + based on the capacity of the card. + + For SD, "preferred_erase_size" is the allocation unit + size specified by the card. + + "preferred_erase_size" is in bytes. -- cgit v1.1 From 495311927ffbe3604e915aeafdf03325e9925b9d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ren=C3=A9=20Herman?= Date: Wed, 11 Aug 2010 13:08:06 +0200 Subject: ALSA: ISA: New Aztech Sound Galaxy driver This is a new driver for Aztech Sound Galaxy ISA soundcards based on the AZT1605 and AZT2316 chipsets. It's constructed as two seperate drivers for either chipset generated from the same source file, with (very) minimal ifdeffery. The drivers check the SB DSP version to decide if they are being loaded for the right chip. AZT1605 returns 2.1 by default and AZT2316 3.1. This isn't full-proof as the DSP version can actually be set through software but it's close enough -- as far as I've been able to see, the DSP version can not be stored in the EEPROM and the cards will therefore startup with the defaults. This distinction could (with the same success rate) also be used to decide which chip we're looking at at runtime meaning a single, merged driver is also an option but I feel it's actually nicer this way. A merged driver would have to postpone translating the passed in resource values to the card configuration until it knew which one it was looking at and would need to postpone erring out on mpu_irq=10 for azt1605 and mpu_irq=3 for azt2316. The drivers have been tested on various cards. For snd-azt1605: FCC-ID I38-MMSN811: Aztech Sound Galaxy Nova 16 Extra FCC-ID I38-MMSN822: Aztech Sound Galaxy Pro 16 II and for snd-azt2316: FCC-ID I38-MMSN824: Aztech Sound Galaxy Pro 16 AB FCC-ID I38-MMSN826: Trust Sound Expert DeLuxe Wave 32 (05201) FCC-ID I38-MMSN830: Trust Sound Expert DeLuxe 16+ (05202) FCC-ID I38-MMSN837: Packard Bell ISA Soundcard 030069 FCC-ID I38-MMSN846: Trust Sound Expert DeLuxe 16-3D (06300) FCC-ID I38-MMSN847: Trust Sound Expert DeLuxe Wave 32-3D (06301) FCC-ID I38-MMSN852: Aztech Sound Galaxy Waverider Pro 32-3D 826 and 846 were also marketed directly by Aztech and then known as: FCC-ID I38-MMSN826: Aztech Sound Galaxy Waverider 32+ FCC-ID I38-MMSN846: Aztech Sound Galaxy Nova 16 Extra II-3D Together, these cover the AZT1605 and AT2316A, AZT2316R and AZT2316-S chipsets. All cards work fully -- full-duplex PCM, MIDI and FM. Full duplex is a little flaky on some. I38-MSN811 tends to not work in full-duplex but sometimes does with the highest success rate being achieved when you first start the capture and then a playback instead of the other way around (it's a CS4231-KL codec). The cards with an AD1845XP codec (my I38-MMSN826 and one of my I38-MMSN830s) are also somewhat duplex-challenged. Sometimes full-duplex works, sometimes not and this varies from try to try. This seems likely to be a timing problem somewhere inside wss-lib. I38-MMSN826 has an additional "ICS2115 WaveFront" wavetable synth onboard that isn't supported yet. The wavetable synths on I38-MMSN847 and I38-MMSN852 are wired directly to the standard MPU-401 UART and the AUX1 input on the codec and work without problem. CD-ROM audio on the cards is routed to the codec "Line" input, Line-In to its Aux input, and FM/Wavetable to its AUX1 input. I did not rename the controls due to the capture source enumeration: I see that capture-source overrides are hardcoded in wss-lib and this is just too ugly to live. Versus the old snd-sgalaxy driver these drivers add support for the models without a configuration EEPROM (which are common), full-duplex, MPU-401 UART and OPL3. In the future they might grow support for that ICS2115 WaveFront synth on 826 and an hwdep interface to write to the EEPROM on the models that have one. Signed-off-by: Rene Herman Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/ALSA-Configuration.txt | 68 +++++++++++++++++++++++++ 1 file changed, 68 insertions(+) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 7f4dceb..e25555c 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -300,6 +300,74 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. control correctly. If you have problems regarding this, try another ALSA compliant mixer (alsamixer works). + Module snd-azt1605 + ------------------ + + Module for Aztech Sound Galaxy soundcards based on the Aztech AZT1605 + chipset. + + port - port # for BASE (0x220,0x240,0x260,0x280) + wss_port - port # for WSS (0x530,0x604,0xe80,0xf40) + irq - IRQ # for WSS (7,9,10,11) + dma1 - DMA # for WSS playback (0,1,3) + dma2 - DMA # for WSS capture (0,1), -1 = disabled (default) + mpu_port - port # for MPU-401 UART (0x300,0x330), -1 = disabled (default) + mpu_irq - IRQ # for MPU-401 UART (3,5,7,9), -1 = disabled (default) + fm_port - port # for OPL3 (0x388), -1 = disabled (default) + + This module supports multiple cards. It does not support autoprobe: port, + wss_port, irq and dma1 have to be specified. The other values are + optional. + + "port" needs to match the BASE ADDRESS jumper on the card (0x220 or 0x240) + or the value stored in the card's EEPROM for cards that have an EEPROM and + their "CONFIG MODE" jumper set to "EEPROM SETTING". The other values can + be choosen freely from the options enumerated above. + + If dma2 is specified and different from dma1, the card will operate in + full-duplex mode. When dma1=3, only dma2=0 is valid and the only way to + enable capture since only channels 0 and 1 are available for capture. + + Generic settings are "port=0x220 wss_port=0x530 irq=10 dma1=1 dma2=0 + mpu_port=0x330 mpu_irq=9 fm_port=0x388". + + Whatever IRQ and DMA channels you pick, be sure to reserve them for + legacy ISA in your BIOS. + + Module snd-azt2316 + ------------------ + + Module for Aztech Sound Galaxy soundcards based on the Aztech AZT2316 + chipset. + + port - port # for BASE (0x220,0x240,0x260,0x280) + wss_port - port # for WSS (0x530,0x604,0xe80,0xf40) + irq - IRQ # for WSS (7,9,10,11) + dma1 - DMA # for WSS playback (0,1,3) + dma2 - DMA # for WSS capture (0,1), -1 = disabled (default) + mpu_port - port # for MPU-401 UART (0x300,0x330), -1 = disabled (default) + mpu_irq - IRQ # for MPU-401 UART (5,7,9,10), -1 = disabled (default) + fm_port - port # for OPL3 (0x388), -1 = disabled (default) + + This module supports multiple cards. It does not support autoprobe: port, + wss_port, irq and dma1 have to be specified. The other values are + optional. + + "port" needs to match the BASE ADDRESS jumper on the card (0x220 or 0x240) + or the value stored in the card's EEPROM for cards that have an EEPROM and + their "CONFIG MODE" jumper set to "EEPROM SETTING". The other values can + be choosen freely from the options enumerated above. + + If dma2 is specified and different from dma1, the card will operate in + full-duplex mode. When dma1=3, only dma2=0 is valid and the only way to + enable capture since only channels 0 and 1 are available for capture. + + Generic settings are "port=0x220 wss_port=0x530 irq=10 dma1=1 dma2=0 + mpu_port=0x330 mpu_irq=9 fm_port=0x388". + + Whatever IRQ and DMA channels you pick, be sure to reserve them for + legacy ISA in your BIOS. + Module snd-aw2 -------------- -- cgit v1.1 From cbaa9f60d5d5c3af10f94e0d49789d5b82341a4a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ren=C3=A9=20Herman?= Date: Fri, 13 Aug 2010 10:43:48 +0200 Subject: ALSA: ISA: Remove snd-sgalaxy Its hardware is handled more fully by the new azt1605/azt2316 drivers. Signed-off-by: Rene Herman Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/ALSA-Configuration.txt | 14 -------------- 1 file changed, 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index e25555c..d0eb696 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -1709,20 +1709,6 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. This card is also known as Audio Excel DSP 16 or Zoltrix AV302. - Module snd-sgalaxy - ------------------ - - Module for Aztech Sound Galaxy sound card. - - sbport - Port # for SB16 interface (0x220,0x240) - wssport - Port # for WSS interface (0x530,0xe80,0xf40,0x604) - irq - IRQ # (7,9,10,11) - dma1 - DMA # - - This module supports multiple cards. - - The power-management is supported. - Module snd-sscape ----------------- -- cgit v1.1 From b19dd42faf413b4705d4adb38521e82d73fa4249 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Sun, 4 Jul 2010 00:15:10 +0200 Subject: bkl: Remove locked .ioctl file operation The last user is gone, so we can safely remove this Signed-off-by: Arnd Bergmann Cc: John Kacur Cc: Al Viro Cc: Thomas Gleixner Signed-off-by: Frederic Weisbecker --- Documentation/filesystems/Locking | 8 +------- Documentation/filesystems/vfs.txt | 6 +----- 2 files changed, 2 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index bbcc156..2db4283 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -374,8 +374,6 @@ prototypes: ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t); int (*readdir) (struct file *, void *, filldir_t); unsigned int (*poll) (struct file *, struct poll_table_struct *); - int (*ioctl) (struct inode *, struct file *, unsigned int, - unsigned long); long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long); long (*compat_ioctl) (struct file *, unsigned int, unsigned long); int (*mmap) (struct file *, struct vm_area_struct *); @@ -409,8 +407,7 @@ write: no aio_write: no readdir: no poll: no -ioctl: yes (see below) -unlocked_ioctl: no (see below) +unlocked_ioctl: no compat_ioctl: no mmap: no open: no @@ -453,9 +450,6 @@ move ->readdir() to inode_operations and use a separate method for directory anything that resembles union-mount we won't have a struct file for all components. And there are other reasons why the current interface is a mess... -->ioctl() on regular files is superceded by the ->unlocked_ioctl() that -doesn't take the BKL. - ->read on directories probably must go away - we should just enforce -EISDIR in sys_read() and friends. diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 94677e7..ed7e5ef 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -727,7 +727,6 @@ struct file_operations { ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t); int (*readdir) (struct file *, void *, filldir_t); unsigned int (*poll) (struct file *, struct poll_table_struct *); - int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long); long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long); long (*compat_ioctl) (struct file *, unsigned int, unsigned long); int (*mmap) (struct file *, struct vm_area_struct *); @@ -768,10 +767,7 @@ otherwise noted. activity on this file and (optionally) go to sleep until there is activity. Called by the select(2) and poll(2) system calls - ioctl: called by the ioctl(2) system call - - unlocked_ioctl: called by the ioctl(2) system call. Filesystems that do not - require the BKL should use this method instead of the ioctl() above. + unlocked_ioctl: called by the ioctl(2) system call. compat_ioctl: called by the ioctl(2) system call when 32 bit system calls are used on 64 bit kernels. -- cgit v1.1 From ce00f7feb0a497b4280e1efe16e03728ed292687 Mon Sep 17 00:00:00 2001 From: FUJITA Tomonori Date: Sat, 14 Aug 2010 16:36:17 +0900 Subject: Documentation: DMA-API-HOWTO.txt: rename ARCH_KMALLOC_MINALIGN to ARCH_DMA_MINALIGN ARCH_KMALLOC_MINALIGN was renamed to ARCH_DMA_MINALIGN (the commit a6eb9fe105d5de0053b261148cee56c94b4720ca). ARCH_DMA_MINALIGN must be defined instead of ARCH_KMALLOC_MINALIGN to ensure that kmalloc'ed buffer is DMA-safe. Signed-off-by: FUJITA Tomonori Signed-off-by: Linus Torvalds --- Documentation/DMA-API-HOWTO.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index 3c4e071..d568bc2 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt @@ -738,17 +738,17 @@ to "Closing". CONFIG_NEED_SG_DMA_LENGTH if the architecture supports IOMMUs (including software IOMMU). -2) ARCH_KMALLOC_MINALIGN +2) ARCH_DMA_MINALIGN Architectures must ensure that kmalloc'ed buffer is DMA-safe. Drivers and subsystems depend on it. If an architecture isn't fully DMA-coherent (i.e. hardware doesn't ensure that data in the CPU cache is identical to data in main memory), - ARCH_KMALLOC_MINALIGN must be set so that the memory allocator + ARCH_DMA_MINALIGN must be set so that the memory allocator makes sure that kmalloc'ed buffer doesn't share a cache line with the others. See arch/arm/include/asm/cache.h as an example. - Note that ARCH_KMALLOC_MINALIGN is about DMA memory alignment + Note that ARCH_DMA_MINALIGN is about DMA memory alignment constraints. You don't need to worry about the architecture data alignment constraints (e.g. the alignment constraints about 64-bit objects). -- cgit v1.1 From 5950ec8d3e47a08ec0b678a0e0ba5d1b9b62dd8e Mon Sep 17 00:00:00 2001 From: "Ira W. Snyder" Date: Sat, 14 Aug 2010 21:08:49 +0200 Subject: hwmon: (ltc4245) Expose all GPIO pins as analog voltages Add support for exposing all GPIO pins as analog voltages. Though this is not an ideal use of the chip, some hardware engineers may decide that the LTC4245 meets their design requirements when studying the datasheet. The GPIO pins are sampled in round-robin fashion, meaning that a slow reader will see stale data. A userspace application can detect this, because it will get -EAGAIN when reading from a sysfs file which contains stale data. Users can choose to use this feature on a per-chip basis by using either platform data or the OF device tree (where applicable). Signed-off-by: Ira W. Snyder Signed-off-by: Jean Delvare --- Documentation/hwmon/ltc4245 | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/ltc4245 b/Documentation/hwmon/ltc4245 index 86b5880..b478b08 100644 --- a/Documentation/hwmon/ltc4245 +++ b/Documentation/hwmon/ltc4245 @@ -72,9 +72,31 @@ in6_min_alarm 5v output undervoltage alarm in7_min_alarm 3v output undervoltage alarm in8_min_alarm Vee (-12v) output undervoltage alarm -in9_input GPIO voltage data +in9_input GPIO voltage data (see note 1) +in10_input GPIO voltage data (see note 1) +in11_input GPIO voltage data (see note 1) power1_input 12v power usage (mW) power2_input 5v power usage (mW) power3_input 3v power usage (mW) power4_input Vee (-12v) power usage (mW) + + +Note 1 +------ + +If you have NOT configured the driver to sample all GPIO pins as analog +voltages, then the in10_input and in11_input sysfs attributes will not be +created. The driver will sample the GPIO pin that is currently connected to the +ADC as an analog voltage, and report the value in in9_input. + +If you have configured the driver to sample all GPIO pins as analog voltages, +then they will be sampled in round-robin fashion. If userspace reads too +slowly, -EAGAIN will be returned when you read the sysfs attribute containing +the sensor reading. + +The LTC4245 chip can be configured to sample all GPIO pins with two methods: +1) platform data -- see include/linux/i2c/ltc4245.h +2) OF device tree -- add the "ltc4245,use-extra-gpios" property to each chip + +The default mode of operation is to sample a single GPIO pin. -- cgit v1.1 From f46fc8cd382f318a7d9c6cd0af1b771c74e5dfd0 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Sat, 14 Aug 2010 21:08:52 +0200 Subject: hwmon: Add 3 critical limit attributes to sysfs-interface Added _lcrit and _crit to voltage attributes. Added _lcrit to temperature attributes. Signed-off-by: Guenter Roeck Signed-off-by: Jean Delvare --- Documentation/hwmon/sysfs-interface | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index d4e2917..2e49218 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -107,10 +107,24 @@ in[0-*]_min Voltage min value. Unit: millivolt RW +in[0-*]_lcrit Voltage critical min value. + Unit: millivolt + RW + If voltage drops to or below this limit, the system may + take drastic action such as power down or reset. At the very + least, it should report a fault. + in[0-*]_max Voltage max value. Unit: millivolt RW +in[0-*]_crit Voltage critical max value. + Unit: millivolt + RW + If voltage reaches or exceeds this limit, the system may + take drastic action such as power down or reset. At the very + least, it should report a fault. + in[0-*]_input Voltage input value. Unit: millivolt RO @@ -284,7 +298,7 @@ temp[1-*]_input Temperature input value. Unit: millidegree Celsius RO -temp[1-*]_crit Temperature critical value, typically greater than +temp[1-*]_crit Temperature critical max value, typically greater than corresponding temp_max values. Unit: millidegree Celsius RW @@ -296,6 +310,11 @@ temp[1-*]_crit_hyst from the critical value. RW +temp[1-*]_lcrit Temperature critical min value, typically lower than + corresponding temp_min values. + Unit: millidegree Celsius + RW + temp[1-*]_offset Temperature offset which is added to the temperature reading by the chip. -- cgit v1.1 From e04a715e4e1210a6ecfcaa0e6ceefde07020710b Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Sat, 14 Aug 2010 21:08:53 +0200 Subject: hwmon: Add 4 current alarm/beep attributes to sysfs-interface Add currX_alarm, currX_min_alarm, currX_max_alarm and currX_beep attributes to the hwmon sysfs API. currX_min_alarm and currX_max_alarm are already supported by the LTC4215 and LTC4245 drivers. currX_alarm is supported by the LTC4261 driver. Signed-off-by: Guenter Roeck Signed-off-by: Jean Delvare --- Documentation/hwmon/sysfs-interface | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index 2e49218..d4d175b 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -363,9 +363,6 @@ Also see the Alarms section for status flags associated with temperatures. * Currents * ************ -Note that no known chip provides current measurements as of writing, -so this part is theoretical, so to say. - curr[1-*]_max Current max value Unit: milliampere RW @@ -490,6 +487,7 @@ limit-related alarms, not both. The driver should just reflect the hardware implementation. in[0-*]_alarm +curr[1-*]_alarm fan[1-*]_alarm temp[1-*]_alarm Channel alarm @@ -501,6 +499,8 @@ OR in[0-*]_min_alarm in[0-*]_max_alarm +curr[1-*]_min_alarm +curr[1-*]_max_alarm fan[1-*]_min_alarm fan[1-*]_max_alarm temp[1-*]_min_alarm @@ -532,6 +532,7 @@ beep_enable Master beep enable RW in[0-*]_beep +curr[1-*]_beep fan[1-*]_beep temp[1-*]_beep Channel beep -- cgit v1.1 From 5a9c2cd881f48d4bec627cccde386f8e3a28bb4a Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Sat, 14 Aug 2010 21:08:54 +0200 Subject: hwmon: Remove in[0-*]_fault from sysfs-interface Fault files are for hardware failures that can be reported. So far we've seen chips reporting such failures for temperature sensors and fans, but not for voltages. Remove in[0-*]_fault for now. It can be added back later if really needed, but I doubt it. Signed-off-by: Jean Delvare Acked-by: Guenter Roeck --- Documentation/hwmon/sysfs-interface | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index d4d175b..ff45d1f 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -516,7 +516,6 @@ to notify open diodes, unconnected fans etc. where the hardware supports it. When this boolean has value 1, the measurement for that channel should not be trusted. -in[0-*]_fault fan[1-*]_fault temp[1-*]_fault Input fault condition -- cgit v1.1 From 9df7305b5a8651eb940e98496bc1d4742379c578 Mon Sep 17 00:00:00 2001 From: Steve Glendinning Date: Sat, 14 Aug 2010 21:08:54 +0200 Subject: hwmon: Add driver for SMSC EMC2103 temperature monitor and fan controller SMSC's EMC2103 family of temperature/fan controllers have 1 onboard and up to 3 external temperature sensors, and allow closed-loop control of one fan. This patch adds support for them. Signed-off-by: Steve Glendinning Signed-off-by: Jean Delvare --- Documentation/hwmon/emc2103 | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/hwmon/emc2103 (limited to 'Documentation') diff --git a/Documentation/hwmon/emc2103 b/Documentation/hwmon/emc2103 new file mode 100644 index 0000000..a12b2c12 --- /dev/null +++ b/Documentation/hwmon/emc2103 @@ -0,0 +1,33 @@ +Kernel driver emc2103 +====================== + +Supported chips: + * SMSC EMC2103 + Addresses scanned: I2C 0x2e + Prefix: 'emc2103' + Datasheet: Not public + +Authors: + Steve Glendinning + +Description +----------- + +The Standard Microsystems Corporation (SMSC) EMC2103 chips +contain up to 4 temperature sensors and a single fan controller. + +Fan rotation speeds are reported in RPM (rotations per minute). An alarm is +triggered if the rotation speed has dropped below a programmable limit. Fan +readings can be divided by a programmable divider (1, 2, 4 or 8) to give +the readings more range or accuracy. Not all RPM values can accurately be +represented, so some rounding is done. With a divider of 1, the lowest +representable value is 480 RPM. + +This driver supports RPM based control, to use this a fan target +should be written to fan1_target and pwm1_enable should be set to 3. + +The 2103-2 and 2103-4 variants have a third temperature sensor, which can +be connected to two anti-parallel diodes. These values can be read +as temp3 and temp4. If only one diode is attached to this channel, temp4 +will show as "fault". The module parameter "apd=0" can be used to suppress +this 4th channel when anti-parallel diodes are not fitted. -- cgit v1.1 From c39aedafb242601729bef48db052ebc055ce3ab4 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Sat, 14 Aug 2010 21:08:55 +0200 Subject: hwmon: (w83627ehf) Add support for W83667HG-B Add support for W83667HG-B (very similar to the W83667HG). Signed-off-by: Guenter Roeck Signed-off-by: Jean Delvare --- Documentation/hwmon/w83627ehf | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/w83627ehf b/Documentation/hwmon/w83627ehf index b7e42ec..13d5561 100644 --- a/Documentation/hwmon/w83627ehf +++ b/Documentation/hwmon/w83627ehf @@ -20,6 +20,10 @@ Supported chips: Prefix: 'w83667hg' Addresses scanned: ISA address retrieved from Super I/O registers Datasheet: not available + * Winbond W83667HG-B + Prefix: 'w83667hg' + Addresses scanned: ISA address retrieved from Super I/O registers + Datasheet: Available from Nuvoton upon request Authors: Jean Delvare @@ -32,8 +36,8 @@ Description ----------- This driver implements support for the Winbond W83627EHF, W83627EHG, -W83627DHG, W83627DHG-P and W83667HG super I/O chips. We will refer to them -collectively as Winbond chips. +W83627DHG, W83627DHG-P, W83667HG and W83667HG-B super I/O chips. +We will refer to them collectively as Winbond chips. The chips implement three temperature sensors, five fan rotation speed sensors, ten analog voltage sensors (only nine for the 627DHG), one @@ -68,14 +72,15 @@ follows: temp1 -> pwm1 temp2 -> pwm2 temp3 -> pwm3 -prog -> pwm4 (not on 667HG; the programmable setting is not supported by - the driver) +prog -> pwm4 (not on 667HG and 667HG-B; the programmable setting is not + supported by the driver) /sys files ---------- name - this is a standard hwmon device entry. For the W83627EHF and W83627EHG, - it is set to "w83627ehf" and for the W83627DHG it is set to "w83627dhg" + it is set to "w83627ehf", for the W83627DHG it is set to "w83627dhg", + and for the W83667HG it is set to "w83667hg". pwm[1-4] - this file stores PWM duty cycle or DC value (fan speed) in range: 0 (stop) to 255 (full) -- cgit v1.1 From 328716bc16b7077ea5f6293c7420247c570d6480 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Sat, 14 Aug 2010 21:08:58 +0200 Subject: hwmon: (pc87427) Add support for manual fan speed control Add initial support for PWM outputs of the PC87427 Super-I/O chip. Only mode change and manual fan speed control are supported. Automatic mode configuration isn't supported, and won't be until at least one board is known, which makes uses of the PWM outputs. Signed-off-by: Jean Delvare Acked-by: Guenter Roeck --- Documentation/hwmon/pc87427 | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/pc87427 b/Documentation/hwmon/pc87427 index db5cc12..3282bf3 100644 --- a/Documentation/hwmon/pc87427 +++ b/Documentation/hwmon/pc87427 @@ -20,8 +20,8 @@ The National Semiconductor Super I/O chip includes complete hardware monitoring capabilities. It can monitor up to 18 voltages, 8 fans and 6 temperature sensors. Only the fans are supported at the moment. -This chip also has fan controlling features, which are not yet supported -by this driver either. +This chip also has fan controlling features (up to 4 PWM outputs), +which are partly supported by this driver. The driver assumes that no more than one chip is present, which seems reasonable. @@ -36,3 +36,12 @@ signal. Speeds down to 83 RPM can be measured. An alarm is triggered if the rotation speed drops below a programmable limit. Another alarm is triggered if the speed is too low to be measured (including stalled or missing fan). + + +Fan Speed Control +----------------- + +Fan speed can be controlled by PWM outputs. There are 4 possible modes: +always off, always on, manual and automatic. The latter isn't supported +by the driver: you can only return to that mode if it was the original +setting, and the configuration interface is missing. -- cgit v1.1 From 008e5f3350e0a474baff3ed3eb4f79653a6b6745 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Sat, 14 Aug 2010 21:08:59 +0200 Subject: hwmon: (pc87427) Add temperature monitoring support Add support for the 6 temperature monitoring channels of the PC87427. Note that the sensors resolution can vary, and I couldn't find a way to figure it out, so we might have to compensate in user-space. Signed-off-by: Jean Delvare Acked-by: Guenter Roeck --- Documentation/hwmon/pc87427 | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/pc87427 b/Documentation/hwmon/pc87427 index 3282bf3..8fdd08c 100644 --- a/Documentation/hwmon/pc87427 +++ b/Documentation/hwmon/pc87427 @@ -18,7 +18,8 @@ Description The National Semiconductor Super I/O chip includes complete hardware monitoring capabilities. It can monitor up to 18 voltages, 8 fans and -6 temperature sensors. Only the fans are supported at the moment. +6 temperature sensors. Only the fans and temperatures are supported at +the moment, voltages aren't. This chip also has fan controlling features (up to 4 PWM outputs), which are partly supported by this driver. @@ -45,3 +46,14 @@ Fan speed can be controlled by PWM outputs. There are 4 possible modes: always off, always on, manual and automatic. The latter isn't supported by the driver: you can only return to that mode if it was the original setting, and the configuration interface is missing. + + +Temperature Monitoring +---------------------- + +The PC87427 relies on external sensors (following the SensorPath +standard), so the resolution and range depend on the type of sensor +connected. The integer part can be 8-bit or 9-bit, and can be signed or +not. I couldn't find a way to figure out the external sensor data +temperature format, so user-space adjustment (typically by a factor 2) +may be required. -- cgit v1.1 From 7cfddeef357aac78179ea804b11cffb5fbba8288 Mon Sep 17 00:00:00 2001 From: Sam Ravnborg Date: Sat, 14 Aug 2010 10:22:58 +0200 Subject: kbuild: drop unifdef-y support unifdef-y is not used anymore - drop remaining references Signed-off-by: Sam Ravnborg --- Documentation/kbuild/makefiles.txt | 6 ------ 1 file changed, 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index c375313..c787ae5 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -45,7 +45,6 @@ This document describes the Linux kernel Makefiles. --- 7.1 header-y --- 7.2 objhdr-y --- 7.3 destination-y - --- 7.4 unifdef-y (deprecated) === 8 Kbuild Variables === 9 Makefile language @@ -1245,11 +1244,6 @@ See subsequent chapter for the syntax of the Kbuild file. will be located in the directory "include/linux" when exported. - --- 7.4 unifdef-y (deprecated) - - unifdef-y is deprecated. A direct replacement is header-y. - - === 8 Kbuild Variables The top Makefile exports the following variables: -- cgit v1.1 From 163475fb111cb2f85aef2428a6c1f9eefba8be23 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sat, 14 Aug 2010 12:36:14 -0700 Subject: Documentation: move SCSI parameters to their own text file Move SCSI parameters from kernel-parameters.txt to their own text file. This continues a trend of moving non-core parameters out of kernel-parameters.txt. Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/kernel-parameters.txt | 128 +----------------------------- Documentation/scsi/scsi-parameters.txt | 139 +++++++++++++++++++++++++++++++++ 2 files changed, 141 insertions(+), 126 deletions(-) create mode 100644 Documentation/scsi/scsi-parameters.txt (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 873b680..4956686 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -88,8 +88,8 @@ parameter is applicable: RAM RAM disk support is enabled. S390 S390 architecture is enabled. SCSI Appropriate SCSI support is enabled. - A lot of drivers has their options described inside of - Documentation/scsi/. + A lot of drivers have their options described inside + the Documentation/scsi/ sub-directory. SECURITY Different security models are enabled. SELINUX SELinux support is enabled. APPARMOR AppArmor support is enabled. @@ -284,27 +284,12 @@ and is between 256 and 4096 characters. It is defined in the file add_efi_memmap [EFI; X86] Include EFI memory map in kernel's map of available physical RAM. - advansys= [HW,SCSI] - See header of drivers/scsi/advansys.c. - agp= [AGP] { off | try_unsupported } off: disable AGP support try_unsupported: try to drive unsupported chipsets (may crash computer or cause data corruption) - aha152x= [HW,SCSI] - See Documentation/scsi/aha152x.txt. - - aha1542= [HW,SCSI] - Format: [,,[,]] - - aic7xxx= [HW,SCSI] - See Documentation/scsi/aic7xxx.txt. - - aic79xx= [HW,SCSI] - See Documentation/scsi/aic79xx.txt. - ALSA [HW,ALSA] See Documentation/sound/alsa/alsa-parameters.txt @@ -368,8 +353,6 @@ and is between 256 and 4096 characters. It is defined in the file atarimouse= [HW,MOUSE] Atari Mouse - atascsi= [HW,SCSI] Atari SCSI - atkbd.extra= [HW] Enable extra LEDs and keys on IBM RapidAccess, EzKey and similar keyboards @@ -419,10 +402,6 @@ and is between 256 and 4096 characters. It is defined in the file bttv.pll= See Documentation/video4linux/bttv/Insmod-options bttv.tuner= and Documentation/video4linux/bttv/CARDLIST - BusLogic= [HW,SCSI] - See drivers/scsi/BusLogic.c, comment before function - BusLogic_ParseDriverOptions(). - c101= [NET] Moxa C101 synchronous serial card cachesize= [BUGS=X86-32] Override level 2 CPU cache size detection. @@ -671,8 +650,6 @@ and is between 256 and 4096 characters. It is defined in the file dscc4.setup= [NET] - dtc3181e= [HW,SCSI] - dynamic_printk Enables pr_debug()/dev_dbg() calls if CONFIG_DYNAMIC_PRINTK_DEBUG has been enabled. These can also be switched on/off via @@ -713,8 +690,6 @@ and is between 256 and 4096 characters. It is defined in the file This is desgined to be used in conjunction with the boot argument: earlyprintk=vga - eata= [HW,SCSI] - edd= [EDD] Format: {"off" | "on" | "skip[mbr]"} @@ -770,12 +745,6 @@ and is between 256 and 4096 characters. It is defined in the file Format: ,,, See also /Documentation/fault-injection/. - fd_mcs= [HW,SCSI] - See header of drivers/scsi/fd_mcs.c. - - fdomain= [HW,SCSI] - See header of drivers/scsi/fdomain.c. - floppy= [HW] See Documentation/blockdev/floppy.txt. @@ -835,14 +804,9 @@ and is between 256 and 4096 characters. It is defined in the file When zero, profiling data is discarded and associated debugfs files are removed at module unload time. - gdth= [HW,SCSI] - See header of drivers/scsi/gdth.c. - gpt [EFI] Forces disk with valid GPT signature but invalid Protective MBR to be treated as GPT. - gvp11= [HW,SCSI] - hashdist= [KNL,NUMA] Large hashes allocated during boot are distributed across NUMA nodes. Defaults on for 64bit NUMA, off otherwise. @@ -931,9 +895,6 @@ and is between 256 and 4096 characters. It is defined in the file i8k.restricted [HW] Allow controlling fans only if SYS_ADMIN capability is set. - ibmmcascsi= [HW,MCA,SCSI] IBM MicroChannel SCSI adapter - See Documentation/mca.txt. - icn= [HW,ISDN] Format: [,[,[,]]] @@ -983,9 +944,6 @@ and is between 256 and 4096 characters. It is defined in the file programs exec'd, files mmap'd for exec, and all files opened for read by uid=0. - in2000= [HW,SCSI] - See header of drivers/scsi/in2000.c. - init= [KNL] Format: Run specified binary instead of /sbin/init as init @@ -1063,9 +1021,6 @@ and is between 256 and 4096 characters. It is defined in the file See comment before ip2_setup() in drivers/char/ip2/ip2base.c. - ips= [HW,SCSI] Adaptec / IBM ServeRAID controller - See header of drivers/scsi/ips.c. - irqfixup [HW] When an interrupt is not handled search all handlers for it. Intended to get systems with badly broken @@ -1341,9 +1296,6 @@ and is between 256 and 4096 characters. It is defined in the file ltpc= [NET] Format: ,, - mac5380= [HW,SCSI] Format: - ,,,, - machvec= [IA64] Force the use of a particular machine-vector (machvec) in a generic kernel. Example: machvec=hpzx1_swiotlb @@ -1365,13 +1317,6 @@ and is between 256 and 4096 characters. It is defined in the file be mounted Format: <1-256> - max_luns= [SCSI] Maximum number of LUNs to probe. - Should be between 1 and 2^32-1. - - max_report_luns= - [SCSI] Maximum number of LUNs received. - Should be between 1 and 16384. - mcatest= [IA-64] mce [X86-32] Machine Check Exception @@ -1568,19 +1513,6 @@ and is between 256 and 4096 characters. It is defined in the file n2= [NET] SDL Inc. RISCom/N2 synchronous serial card - NCR_D700= [HW,SCSI] - See header of drivers/scsi/NCR_D700.c. - - ncr5380= [HW,SCSI] - - ncr53c400= [HW,SCSI] - - ncr53c400a= [HW,SCSI] - - ncr53c406a= [HW,SCSI] - - ncr53c8xx= [HW,SCSI] - netdev= [NET] Network devices parameters Format: ,,,, Note that mem_start is often overloaded to mean @@ -1859,10 +1791,6 @@ and is between 256 and 4096 characters. It is defined in the file OSS [HW,OSS] See Documentation/sound/oss/oss-parameters.txt - osst= [HW,SCSI] SCSI Tape Driver - Format: , - See also Documentation/scsi/st.txt. - panic= [KNL] Kernel behaviour on panic Format: @@ -1895,9 +1823,6 @@ and is between 256 and 4096 characters. It is defined in the file Currently this function knows 686a and 8231 chips. Format: [spp|ps2|epp|ecp|ecpepp] - pas16= [HW,SCSI] - See header of drivers/scsi/pas16.c. - pause_on_oops= Halt all CPUs after the first oops has been printed for the specified number of seconds. This is to be used if @@ -2264,30 +2189,6 @@ and is between 256 and 4096 characters. It is defined in the file sched_debug [KNL] Enables verbose scheduler debug messages. - scsi_debug_*= [SCSI] - See drivers/scsi/scsi_debug.c. - - scsi_default_dev_flags= - [SCSI] SCSI default device flags - Format: - - scsi_dev_flags= [SCSI] Black/white list entry for vendor and model - Format: :: - (flags are integer value) - - scsi_logging_level= [SCSI] a bit mask of logging levels - See drivers/scsi/scsi_logging.h for bits. Also - settable via sysctl at dev.scsi.logging_level - (/proc/sys/dev/scsi/logging_level). - There is also a nice 'scsi_logging_level' script in the - S390-tools package, available for download at - http://www-128.ibm.com/developerworks/linux/linux390/s390-tools-1.5.4.html - - scsi_mod.scan= [SCSI] sync (default) scans SCSI busses as they are - discovered. async scans them in kernel threads, - allowing boot to proceed. none ignores them, expecting - user space to do the scan. - security= [SECURITY] Choose a security module to enable at boot. If this boot parameter is not specified, only the first security module asking for security registration will be @@ -2321,9 +2222,6 @@ and is between 256 and 4096 characters. It is defined in the file The parameter means the number of CPUs to show, for example 1 means boot CPU only. - sim710= [SCSI,HW] - See header of drivers/scsi/sim710.c. - simeth= [IA-64] simscsi= @@ -2395,9 +2293,6 @@ and is between 256 and 4096 characters. It is defined in the file spia_pedr= spia_peddr= - st= [HW,SCSI] SCSI tape parameters (buffers, etc.) - See Documentation/scsi/st.txt. - stacktrace [FTRACE] Enabled the stack tracer on boot up. @@ -2455,18 +2350,12 @@ and is between 256 and 4096 characters. It is defined in the file switches= [HW,M68k] - sym53c416= [HW,SCSI] - See header of drivers/scsi/sym53c416.c. - sysrq_always_enabled [KNL] Ignore sysrq setting - this boot parameter will neutralize any effect of /proc/sys/kernel/sysrq. Useful for debugging. - t128= [HW,SCSI] - See header of drivers/scsi/t128.c. - tdfx= [HW,DRM] test_suspend= [SUSPEND] @@ -2503,10 +2392,6 @@ and is between 256 and 4096 characters. It is defined in the file : poll all this frequency 0: no polling (default) - tmscsim= [HW,SCSI] - See comment before function dc390_setup() in - drivers/scsi/tmscsim.c. - topology= [S390] Format: {off | on} Specify if the kernel should make use of the cpu @@ -2547,9 +2432,6 @@ and is between 256 and 4096 characters. It is defined in the file ,,,,,,, See also Documentation/input/joystick-parport.txt - u14-34f= [HW,SCSI] UltraStor 14F/34F SCSI host adapter - See header of drivers/scsi/u14-34f.c. - uhash_entries= [KNL,NET] Set number of hash buckets for UDP/UDP-Lite connections @@ -2715,12 +2597,6 @@ and is between 256 and 4096 characters. It is defined in the file overridden by individual drivers. 0 will hide cursors, 1 will display them. - wd33c93= [HW,SCSI] - See header of drivers/scsi/wd33c93.c. - - wd7000= [HW,SCSI] - See header of drivers/scsi/wd7000.c. - watchdog timers [HW,WDT] For information on watchdog timers, see Documentation/watchdog/watchdog-parameters.txt or other driver-specific files in the diff --git a/Documentation/scsi/scsi-parameters.txt b/Documentation/scsi/scsi-parameters.txt new file mode 100644 index 0000000..21e5798 --- /dev/null +++ b/Documentation/scsi/scsi-parameters.txt @@ -0,0 +1,139 @@ + SCSI Kernel Parameters + ~~~~~~~~~~~~~~~~~~~~~~ + +See Documentation/kernel-parameters.txt for general information on +specifying module parameters. + +This document may not be entirely up to date and comprehensive. The command +"modinfo -p ${modulename}" shows a current list of all parameters of a loadable +module. Loadable modules, after being loaded into the running kernel, also +reveal their parameters in /sys/module/${modulename}/parameters/. Some of these +parameters may be changed at runtime by the command +"echo -n ${value} > /sys/module/${modulename}/parameters/${parm}". + + + advansys= [HW,SCSI] + See header of drivers/scsi/advansys.c. + + aha152x= [HW,SCSI] + See Documentation/scsi/aha152x.txt. + + aha1542= [HW,SCSI] + Format: [,,[,]] + + aic7xxx= [HW,SCSI] + See Documentation/scsi/aic7xxx.txt. + + aic79xx= [HW,SCSI] + See Documentation/scsi/aic79xx.txt. + + atascsi= [HW,SCSI] Atari SCSI + + BusLogic= [HW,SCSI] + See drivers/scsi/BusLogic.c, comment before function + BusLogic_ParseDriverOptions(). + + dtc3181e= [HW,SCSI] + + eata= [HW,SCSI] + + fd_mcs= [HW,SCSI] + See header of drivers/scsi/fd_mcs.c. + + fdomain= [HW,SCSI] + See header of drivers/scsi/fdomain.c. + + gdth= [HW,SCSI] + See header of drivers/scsi/gdth.c. + + gvp11= [HW,SCSI] + + ibmmcascsi= [HW,MCA,SCSI] IBM MicroChannel SCSI adapter + See Documentation/mca.txt. + + in2000= [HW,SCSI] + See header of drivers/scsi/in2000.c. + + ips= [HW,SCSI] Adaptec / IBM ServeRAID controller + See header of drivers/scsi/ips.c. + + mac5380= [HW,SCSI] Format: + ,,,, + + max_luns= [SCSI] Maximum number of LUNs to probe. + Should be between 1 and 2^32-1. + + max_report_luns= + [SCSI] Maximum number of LUNs received. + Should be between 1 and 16384. + + NCR_D700= [HW,SCSI] + See header of drivers/scsi/NCR_D700.c. + + ncr5380= [HW,SCSI] + + ncr53c400= [HW,SCSI] + + ncr53c400a= [HW,SCSI] + + ncr53c406a= [HW,SCSI] + + ncr53c8xx= [HW,SCSI] + + nodisconnect [HW,SCSI,M68K] Disables SCSI disconnects. + + osst= [HW,SCSI] SCSI Tape Driver + Format: , + See also Documentation/scsi/st.txt. + + pas16= [HW,SCSI] + See header of drivers/scsi/pas16.c. + + scsi_debug_*= [SCSI] + See drivers/scsi/scsi_debug.c. + + scsi_default_dev_flags= + [SCSI] SCSI default device flags + Format: + + scsi_dev_flags= [SCSI] Black/white list entry for vendor and model + Format: :: + (flags are integer value) + + scsi_logging_level= [SCSI] a bit mask of logging levels + See drivers/scsi/scsi_logging.h for bits. Also + settable via sysctl at dev.scsi.logging_level + (/proc/sys/dev/scsi/logging_level). + There is also a nice 'scsi_logging_level' script in the + S390-tools package, available for download at + http://www-128.ibm.com/developerworks/linux/linux390/s390-tools-1.5.4.html + + scsi_mod.scan= [SCSI] sync (default) scans SCSI busses as they are + discovered. async scans them in kernel threads, + allowing boot to proceed. none ignores them, expecting + user space to do the scan. + + sim710= [SCSI,HW] + See header of drivers/scsi/sim710.c. + + st= [HW,SCSI] SCSI tape parameters (buffers, etc.) + See Documentation/scsi/st.txt. + + sym53c416= [HW,SCSI] + See header of drivers/scsi/sym53c416.c. + + t128= [HW,SCSI] + See header of drivers/scsi/t128.c. + + tmscsim= [HW,SCSI] + See comment before function dc390_setup() in + drivers/scsi/tmscsim.c. + + u14-34f= [HW,SCSI] UltraStor 14F/34F SCSI host adapter + See header of drivers/scsi/u14-34f.c. + + wd33c93= [HW,SCSI] + See header of drivers/scsi/wd33c93.c. + + wd7000= [HW,SCSI] + See header of drivers/scsi/wd7000.c. -- cgit v1.1 From c637e4861c7db8165d0f438db3829e7878c96059 Mon Sep 17 00:00:00 2001 From: Zhang Rui Date: Thu, 15 Jul 2010 10:46:17 +0800 Subject: ACPI: introduce module parameter acpi.aml_debug_output Introduce module parameter acpi.aml_debug_output. With acpi.aml_debug_output set, we can get AML debug object output (Store (AAA, Debug)), even with CONFIG_ACPI_DEBUG cleared. Together with the runtime custom method mechanism, we can debug AML code problems without rebuilding the kernel. Signed-off-by: Zhang Rui Signed-off-by: Len Brown --- Documentation/acpi/method-customizing.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/acpi/method-customizing.txt b/Documentation/acpi/method-customizing.txt index e628cd2..3e1d25a 100644 --- a/Documentation/acpi/method-customizing.txt +++ b/Documentation/acpi/method-customizing.txt @@ -19,6 +19,8 @@ Note: Only ACPI METHOD can be overridden, any other object types like "Device", "OperationRegion", are not recognized. Note: The same ACPI control method can be overridden for many times, and it's always the latest one that used by Linux/kernel. +Note: To get the ACPI debug object output (Store (AAAA, Debug)), + please run "echo 1 > /sys/module/acpi/parameters/aml_debug_output". 1. override an existing method a) get the ACPI table via ACPI sysfs I/F. e.g. to get the DSDT, -- cgit v1.1 From bbff2168c1088995753e889580c756971eca51e4 Mon Sep 17 00:00:00 2001 From: Jiri Kosina Date: Wed, 11 Aug 2010 18:34:09 +0200 Subject: paravirt: noreplace-paravirt is implemented for x86 and ia-64 kernel-parameters.txt lists 'noreplace-paravirt' parameter as being limited to X86-32, which is incorrect -- it's actually supported by x86-32, x86-64 and ia-64. Signed-off-by: Jiri Kosina Acked-by: Jeremy Fitzhardinge --- Documentation/kernel-parameters.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index d529b13..8ed3a77 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1777,7 +1777,7 @@ and is between 256 and 4096 characters. It is defined in the file norandmaps Don't use address space randomization. Equivalent to echo 0 > /proc/sys/kernel/randomize_va_space - noreplace-paravirt [X86-32,PV_OPS] Don't patch paravirt_ops + noreplace-paravirt [X86,IA-64,PV_OPS] Don't patch paravirt_ops noreplace-smp [X86-32,SMP] Don't replace SMP instructions with UP alternatives -- cgit v1.1 From 217f09631a420295a9688e18aa4dbad1b385e56c Mon Sep 17 00:00:00 2001 From: Henrique de Moraes Holschuh Date: Mon, 9 Aug 2010 23:48:19 -0300 Subject: thinkpad-acpi: untangle ACPI/vendor backlight selection acpi_video_backlight_support() already tells us if ACPI is handling backlight control through the generic ACPI handle. It is better to just trust it. While at it, adjust down a printk priority, and test earlier for brightness_enable=0. Signed-off-by: Henrique de Moraes Holschuh Signed-off-by: Matthew Garrett --- Documentation/laptops/thinkpad-acpi.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index f6f8025..1565eefd 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt @@ -1024,6 +1024,10 @@ ThinkPad-specific interface. The driver will disable its native backlight brightness control interface if it detects that the standard ACPI interface is available in the ThinkPad. +If you want to use the thinkpad-acpi backlight brightness control +instead of the generic ACPI video backlight brightness control for some +reason, you should use the acpi_backlight=vendor kernel parameter. + The brightness_enable module parameter can be used to control whether the LCD brightness control feature will be enabled when available. brightness_enable=0 forces it to be disabled. brightness_enable=1 -- cgit v1.1 From b9e0ba8114583b0462cfb18b4ca01fc82894c5c0 Mon Sep 17 00:00:00 2001 From: Anton Vorontsov Date: Wed, 11 Aug 2010 20:56:03 +0400 Subject: booting-without-of: Remove nonexistent chapters from TOC, fix numbering Marvell and GPIO bindings live in their own files, so the TOC should not mention them. Also fix chapters numbering. Signed-off-by: Anton Vorontsov Signed-off-by: Grant Likely --- Documentation/powerpc/booting-without-of.txt | 31 ++-------------------------- 1 file changed, 2 insertions(+), 29 deletions(-) (limited to 'Documentation') diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 568fa08..302db5d 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -49,40 +49,13 @@ Table of Contents f) MDIO on GPIOs g) SPI busses - VII - Marvell Discovery mv64[345]6x System Controller chips - 1) The /system-controller node - 2) Child nodes of /system-controller - a) Marvell Discovery MDIO bus - b) Marvell Discovery ethernet controller - c) Marvell Discovery PHY nodes - d) Marvell Discovery SDMA nodes - e) Marvell Discovery BRG nodes - f) Marvell Discovery CUNIT nodes - g) Marvell Discovery MPSCROUTING nodes - h) Marvell Discovery MPSCINTR nodes - i) Marvell Discovery MPSC nodes - j) Marvell Discovery Watch Dog Timer nodes - k) Marvell Discovery I2C nodes - l) Marvell Discovery PIC (Programmable Interrupt Controller) nodes - m) Marvell Discovery MPP (Multipurpose Pins) multiplexing nodes - n) Marvell Discovery GPP (General Purpose Pins) nodes - o) Marvell Discovery PCI host bridge node - p) Marvell Discovery CPU Error nodes - q) Marvell Discovery SRAM Controller nodes - r) Marvell Discovery PCI Error Handler nodes - s) Marvell Discovery Memory Controller nodes - - VIII - Specifying interrupt information for devices + VII - Specifying interrupt information for devices 1) interrupts property 2) interrupt-parent property 3) OpenPIC Interrupt Controllers 4) ISA Interrupt Controllers - IX - Specifying GPIO information for devices - 1) gpios property - 2) gpio-controller nodes - - X - Specifying device power management information (sleep property) + VIII - Specifying device power management information (sleep property) Appendix A - Sample SOC node for MPC8540 -- cgit v1.1 From 2244d07bfa2097cb00600da91c715a8aa547917e Mon Sep 17 00:00:00 2001 From: Oliver Hartkopp Date: Tue, 17 Aug 2010 08:59:14 +0000 Subject: net: simplify flags for tx timestamping This patch removes the abstraction introduced by the union skb_shared_tx in the shared skb data. The access of the different union elements at several places led to some confusion about accessing the shared tx_flags e.g. in skb_orphan_try(). http://marc.info/?l=linux-netdev&m=128084897415886&w=2 Signed-off-by: Oliver Hartkopp Signed-off-by: David S. Miller --- Documentation/networking/timestamping.txt | 22 +++++++++++++--------- 1 file changed, 13 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt index e8c8f4f..98097d8 100644 --- a/Documentation/networking/timestamping.txt +++ b/Documentation/networking/timestamping.txt @@ -172,15 +172,19 @@ struct skb_shared_hwtstamps { }; Time stamps for outgoing packets are to be generated as follows: -- In hard_start_xmit(), check if skb_tx(skb)->hardware is set no-zero. - If yes, then the driver is expected to do hardware time stamping. +- In hard_start_xmit(), check if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP) + is set no-zero. If yes, then the driver is expected to do hardware time + stamping. - If this is possible for the skb and requested, then declare - that the driver is doing the time stamping by setting the field - skb_tx(skb)->in_progress non-zero. You might want to keep a pointer - to the associated skb for the next step and not free the skb. A driver - not supporting hardware time stamping doesn't do that. A driver must - never touch sk_buff::tstamp! It is used to store software generated - time stamps by the network subsystem. + that the driver is doing the time stamping by setting the flag + SKBTX_IN_PROGRESS in skb_shinfo(skb)->tx_flags , e.g. with + + skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS; + + You might want to keep a pointer to the associated skb for the next step + and not free the skb. A driver not supporting hardware time stamping doesn't + do that. A driver must never touch sk_buff::tstamp! It is used to store + software generated time stamps by the network subsystem. - As soon as the driver has sent the packet and/or obtained a hardware time stamp for it, it passes the time stamp back by calling skb_hwtstamp_tx() with the original skb, the raw @@ -191,6 +195,6 @@ Time stamps for outgoing packets are to be generated as follows: this would occur at a later time in the processing pipeline than other software time stamping and therefore could lead to unexpected deltas between time stamps. -- If the driver did not call set skb_tx(skb)->in_progress, then +- If the driver did not set the SKBTX_IN_PROGRESS flag (see above), then dev_hard_start_xmit() checks whether software time stamping is wanted as fallback and potentially generates the time stamp. -- cgit v1.1 From 84483ea42cd4f2781d6e97a83ab3ebd0ff19fb10 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Wed, 16 Jun 2010 16:48:13 -0700 Subject: rcu: add shiny new debug assists to Documentation/RCU/checklist.txt Add a section describing PROVE_RCU, DEBUG_OBJECTS_RCU_HEAD, and the __rcu sparse checking to the RCU checklist. Suggested-by: David Miller Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett --- Documentation/RCU/checklist.txt | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) (limited to 'Documentation') diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index 790d1a8..c7c6788 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -365,3 +365,26 @@ over a rather long period of time, but improvements are always welcome! and the compiler to freely reorder code into and out of RCU read-side critical sections. It is the responsibility of the RCU update-side primitives to deal with this. + +17. Use CONFIG_PROVE_RCU, CONFIG_DEBUG_OBJECTS_RCU_HEAD, and + the __rcu sparse checks to validate your RCU code. These + can help find problems as follows: + + CONFIG_PROVE_RCU: check that accesses to RCU-protected data + structures are carried out under the proper RCU + read-side critical section, while holding the right + combination of locks, or whatever other conditions + are appropriate. + + CONFIG_DEBUG_OBJECTS_RCU_HEAD: check that you don't pass the + same object to call_rcu() (or friends) before an RCU + grace period has elapsed since the last time that you + passed that same object to call_rcu() (or friends). + + __rcu sparse checks: tag the pointer to the RCU-protected data + structure with __rcu, and sparse will warn you if you + access that pointer without the services of one of the + variants of rcu_dereference(). + + These debugging aids can help you find problems that are + otherwise extremely difficult to spot. -- cgit v1.1 From 65e423f8ee5843e1ea3f2d94adf4ba3560a17f7b Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Wed, 19 May 2010 10:42:16 -0700 Subject: Update documentation to note the passage of INIT_RCU_HEAD() Signed-off-by: Alexey Dobriyan Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett --- Documentation/DocBook/kernel-locking.tmpl | 8 -------- 1 file changed, 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl index 084f6ad..e6cc574 100644 --- a/Documentation/DocBook/kernel-locking.tmpl +++ b/Documentation/DocBook/kernel-locking.tmpl @@ -1725,14 +1725,6 @@ the amount of locking which needs to be done. if (++cache_num > MAX_CACHE_SIZE) { struct object *i, *outcast = NULL; list_for_each_entry(i, &cache, list) { -@@ -85,6 +94,7 @@ - obj->popularity = 0; - atomic_set(&obj->refcnt, 1); /* The cache holds a reference */ - spin_lock_init(&obj->lock); -+ INIT_RCU_HEAD(&obj->rcu); - - spin_lock_irqsave(&cache_lock, flags); - __cache_add(obj); @@ -104,12 +114,11 @@ struct object *cache_find(int id) { -- cgit v1.1 From ded5e5ed2f3348ba2f9a319c6497e46c22850e97 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Wed, 19 May 2010 10:46:55 -0700 Subject: Update call_rcu() usage, add synchronize_rcu() Reported-by: Kyle Hubert Signed-off-by: Paul E. McKenney Reviewed-by: Josh Triplett --- Documentation/DocBook/kernel-locking.tmpl | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl index e6cc574..ed64d22 100644 --- a/Documentation/DocBook/kernel-locking.tmpl +++ b/Documentation/DocBook/kernel-locking.tmpl @@ -1645,7 +1645,9 @@ the amount of locking which needs to be done. all the readers who were traversing the list when we deleted the element are finished. We use call_rcu() to register a callback which will actually destroy the object once - the readers are finished. + all pre-existing readers are finished. Alternatively, + synchronize_rcu() may be used to block until + all pre-existing are finished. But how does Read Copy Update know when the readers are @@ -1714,7 +1716,7 @@ the amount of locking which needs to be done. - object_put(obj); + list_del_rcu(&obj->list); cache_num--; -+ call_rcu(&obj->rcu, cache_delete_rcu, obj); ++ call_rcu(&obj->rcu, cache_delete_rcu); } /* Must be holding cache_lock */ -- cgit v1.1 From 5cc6517abdeccb6690b344a43b5ce8eaee82da3c Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Fri, 13 Aug 2010 16:34:22 -0700 Subject: rcu: document ways of stalling updates in low-memory situations Signed-off-by: Paul E. McKenney --- Documentation/RCU/checklist.txt | 23 ++++++++++++++++------- 1 file changed, 16 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index c7c6788..0c134f8 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -218,13 +218,22 @@ over a rather long period of time, but improvements are always welcome! include: a. Keeping a count of the number of data-structure elements - used by the RCU-protected data structure, including those - waiting for a grace period to elapse. Enforce a limit - on this number, stalling updates as needed to allow - previously deferred frees to complete. - - Alternatively, limit only the number awaiting deferred - free rather than the total number of elements. + used by the RCU-protected data structure, including + those waiting for a grace period to elapse. Enforce a + limit on this number, stalling updates as needed to allow + previously deferred frees to complete. Alternatively, + limit only the number awaiting deferred free rather than + the total number of elements. + + One way to stall the updates is to acquire the update-side + mutex. (Don't try this with a spinlock -- other CPUs + spinning on the lock could prevent the grace period + from ever ending.) Another way to stall the updates + is for the updates to use a wrapper function around + the memory allocator, so that this wrapper function + simulates OOM when there is too much memory awaiting an + RCU grace period. There are of course many other + variations on this theme. b. Limiting update rate. For example, if updates occur only once per hour, then no explicit rate limiting is required, -- cgit v1.1 From f2e41e910320197d55b52e28d99a07130f2ae738 Mon Sep 17 00:00:00 2001 From: Andrew Morton Date: Thu, 19 Aug 2010 14:13:31 -0700 Subject: revert "hwmon: f71882fg: add support for the Fintek F71808E" Revert commit 7721fea3d0fd93fb4d000eb737b444369358d6d3 ("hwmon: f71882fg: add support for the Fintek F71808E"). Hans said: : A second review after I've received a data sheet for this device from : Fintek has turned up a few bugs. : : Unfortunately Giel (nor I) have time to fix this in time for the 2.6.36 : cycle. Therefor I would like to see this patch reverted as not having any : support for the hwmon function of this superio chip is better then having : unreliable support. Cc: Giel van Schijndel Cc: Jean Delvare Cc: Hans de Goede Cc: Jonathan Cameron Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/hwmon/f71882fg | 4 ---- 1 file changed, 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/f71882fg b/Documentation/hwmon/f71882fg index 1a07fd6..a7952c2 100644 --- a/Documentation/hwmon/f71882fg +++ b/Documentation/hwmon/f71882fg @@ -2,10 +2,6 @@ Kernel driver f71882fg ====================== Supported chips: - * Fintek F71808E - Prefix: 'f71808fg' - Addresses scanned: none, address read from Super I/O config space - Datasheet: Not public * Fintek F71858FG Prefix: 'f71858fg' Addresses scanned: none, address read from Super I/O config space -- cgit v1.1 From 1ee41680572971e34d90d5f584daf33195ec6dcb Mon Sep 17 00:00:00 2001 From: Stefan Richter Date: Thu, 19 Aug 2010 14:13:43 -0700 Subject: Documentation: kernel-locking: mutex_trylock cannot be used in interrupt context Chapter 6 is right about mutex_trylock, but chapter 10 wasn't. This error was introduced during semaphore-to-mutex conversion of the Unreliable guide. :-) If user context which performs mutex_lock() or mutex_trylock() is preempted by interrupt context which performs mutex_trylock() on the same mutex instance, a deadlock occurs. This is because these functions do not disable local IRQs when they operate on mutex->wait_lock. Signed-off-by: Stefan Richter Acked-by: Rusty Russell Cc: Matthew Wilcox Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/DocBook/kernel-locking.tmpl | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl index 084f6ad..0b1a3f9 100644 --- a/Documentation/DocBook/kernel-locking.tmpl +++ b/Documentation/DocBook/kernel-locking.tmpl @@ -1922,9 +1922,12 @@ machines due to caching. mutex_lock() - There is a mutex_trylock() which can be - used inside interrupt context, as it will not sleep. + There is a mutex_trylock() which does not + sleep. Still, it must not be used inside interrupt context since + its implementation is not safe for that. mutex_unlock() will also never sleep. + It cannot be used in interrupt context either since a mutex + must be released by the same task that acquired it. -- cgit v1.1 From f6143a9b732977859cb6e04c604d04976aa5ccbd Mon Sep 17 00:00:00 2001 From: Stephen Rothwell Date: Fri, 20 Aug 2010 19:56:31 +1000 Subject: Documentation: fix ozlabs.org mailing list address This list moved to lists.ozlabs.org quite some time ago. Signed-off-by: Stephen Rothwell Signed-off-by: Linus Torvalds --- Documentation/powerpc/hvcs.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/powerpc/hvcs.txt b/Documentation/powerpc/hvcs.txt index f93462c..6d8be34 100644 --- a/Documentation/powerpc/hvcs.txt +++ b/Documentation/powerpc/hvcs.txt @@ -560,7 +560,7 @@ The proper channel for reporting bugs is either through the Linux OS distribution company that provided your OS or by posting issues to the PowerPC development mailing list at: -linuxppc-dev@ozlabs.org +linuxppc-dev@lists.ozlabs.org This request is to provide a documented and searchable public exchange of the problems and solutions surrounding this driver for the benefit of -- cgit v1.1 From 6d6ac1c1a3d4f95953aa3b085e8f16692d3a7179 Mon Sep 17 00:00:00 2001 From: Vivek Goyal Date: Mon, 23 Aug 2010 12:25:29 +0200 Subject: cfq-iosched: Documentation help for new tunables Some documentation to provide help with tunables. Signed-off-by: Vivek Goyal Acked-by: Jeff Moyer Signed-off-by: Jens Axboe --- Documentation/block/cfq-iosched.txt | 45 ++++++++++++++++++++++++++++++ Documentation/cgroups/blkio-controller.txt | 28 +++++++++++++++++++ 2 files changed, 73 insertions(+) create mode 100644 Documentation/block/cfq-iosched.txt (limited to 'Documentation') diff --git a/Documentation/block/cfq-iosched.txt b/Documentation/block/cfq-iosched.txt new file mode 100644 index 0000000..e578fee --- /dev/null +++ b/Documentation/block/cfq-iosched.txt @@ -0,0 +1,45 @@ +CFQ ioscheduler tunables +======================== + +slice_idle +---------- +This specifies how long CFQ should idle for next request on certain cfq queues +(for sequential workloads) and service trees (for random workloads) before +queue is expired and CFQ selects next queue to dispatch from. + +By default slice_idle is a non-zero value. That means by default we idle on +queues/service trees. This can be very helpful on highly seeky media like +single spindle SATA/SAS disks where we can cut down on overall number of +seeks and see improved throughput. + +Setting slice_idle to 0 will remove all the idling on queues/service tree +level and one should see an overall improved throughput on faster storage +devices like multiple SATA/SAS disks in hardware RAID configuration. The down +side is that isolation provided from WRITES also goes down and notion of +IO priority becomes weaker. + +So depending on storage and workload, it might be useful to set slice_idle=0. +In general I think for SATA/SAS disks and software RAID of SATA/SAS disks +keeping slice_idle enabled should be useful. For any configurations where +there are multiple spindles behind single LUN (Host based hardware RAID +controller or for storage arrays), setting slice_idle=0 might end up in better +throughput and acceptable latencies. + +CFQ IOPS Mode for group scheduling +=================================== +Basic CFQ design is to provide priority based time slices. Higher priority +process gets bigger time slice and lower priority process gets smaller time +slice. Measuring time becomes harder if storage is fast and supports NCQ and +it would be better to dispatch multiple requests from multiple cfq queues in +request queue at a time. In such scenario, it is not possible to measure time +consumed by single queue accurately. + +What is possible though is to measure number of requests dispatched from a +single queue and also allow dispatch from multiple cfq queue at the same time. +This effectively becomes the fairness in terms of IOPS (IO operations per +second). + +If one sets slice_idle=0 and if storage supports NCQ, CFQ internally switches +to IOPS mode and starts providing fairness in terms of number of requests +dispatched. Note that this mode switching takes effect only for group +scheduling. For non-cgroup users nothing should change. diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroups/blkio-controller.txt index 48e0b21..6919d62 100644 --- a/Documentation/cgroups/blkio-controller.txt +++ b/Documentation/cgroups/blkio-controller.txt @@ -217,6 +217,7 @@ Details of cgroup files CFQ sysfs tunable ================= /sys/block//queue/iosched/group_isolation +----------------------------------------------- If group_isolation=1, it provides stronger isolation between groups at the expense of throughput. By default group_isolation is 0. In general that @@ -243,6 +244,33 @@ By default one should run with group_isolation=0. If that is not sufficient and one wants stronger isolation between groups, then set group_isolation=1 but this will come at cost of reduced throughput. +/sys/block//queue/iosched/slice_idle +------------------------------------------ +On a faster hardware CFQ can be slow, especially with sequential workload. +This happens because CFQ idles on a single queue and single queue might not +drive deeper request queue depths to keep the storage busy. In such scenarios +one can try setting slice_idle=0 and that would switch CFQ to IOPS +(IO operations per second) mode on NCQ supporting hardware. + +That means CFQ will not idle between cfq queues of a cfq group and hence be +able to driver higher queue depth and achieve better throughput. That also +means that cfq provides fairness among groups in terms of IOPS and not in +terms of disk time. + +/sys/block//queue/iosched/group_idle +------------------------------------------ +If one disables idling on individual cfq queues and cfq service trees by +setting slice_idle=0, group_idle kicks in. That means CFQ will still idle +on the group in an attempt to provide fairness among groups. + +By default group_idle is same as slice_idle and does not do anything if +slice_idle is enabled. + +One can experience an overall throughput drop if you have created multiple +groups and put applications in that group which are not driving enough +IO to keep disk busy. In that case set group_idle=0, and CFQ will not idle +on individual groups and throughput should improve. + What works ========== - Currently only sync IO queues are support. All the buffered writes are -- cgit v1.1 From c93a4dfb31f2c023da3ad1238c352452f2cc0e05 Mon Sep 17 00:00:00 2001 From: Ian Campbell Date: Mon, 23 Aug 2010 11:59:28 +0100 Subject: xen: pvhvm: allow user to request no emulated device unplug this allows the user to disable pvhvm and revert to emulated devices in case of a system misconfiguration (e.g. initramfs with only emulated drivers in it). Signed-off-by: Ian Campbell Acked-by: Jeremy Fitzhardinge Acked-by: Stefano Stabellini --- Documentation/kernel-parameters.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 2c85c06..8bbe83b 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2631,6 +2631,7 @@ and is between 256 and 4096 characters. It is defined in the file all -- unplug all emulated devices (NICs and IDE disks) ignore -- continue loading the Xen platform PCI driver even if the version check failed + never -- do not unplug even if version check succeeds xirc2ps_cs= [NET,PCMCIA] Format: -- cgit v1.1 From 1dc7ce99b091a11cce0f34456c1ffcb928f17edd Mon Sep 17 00:00:00 2001 From: Ian Campbell Date: Mon, 23 Aug 2010 11:59:29 +0100 Subject: xen: pvhvm: rename xen_emul_unplug=ignore to =unnnecessary It is not immediately clear what this option causes to become ignored. The actual meaning is that it is not necessary to unplug the emulated devices to safely use the PV ones, even if the platform does not support the unplug protocol. (pressumably the user will only add this option if they have ensured that their domain configuration is safe). I think xen_emul_unplug=unnecessary better captures this. Signed-off-by: Ian Campbell Acked-by: Jeremy Fitzhardinge Acked-by: Stefano Stabellini --- Documentation/kernel-parameters.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 8bbe83b..f084af0 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2629,8 +2629,9 @@ and is between 256 and 4096 characters. It is defined in the file aux-ide-disks -- unplug non-primary-master IDE devices nics -- unplug network devices all -- unplug all emulated devices (NICs and IDE disks) - ignore -- continue loading the Xen platform PCI driver even - if the version check failed + unnecessary -- unplugging emulated devices is + unnecessary even if the host did not respond to + the unplug protocol never -- do not unplug even if version check succeeds xirc2ps_cs= [NET,PCMCIA] -- cgit v1.1 From 9863c90f682fba34cdc26c3437e8c00da6c83fa4 Mon Sep 17 00:00:00 2001 From: Alok Kataria Date: Mon, 23 Aug 2010 14:49:11 -0700 Subject: x86, vmware: Remove deprecated VMI kernel support With the recent innovations in CPU hardware acceleration technologies from Intel and AMD, VMware ran a few experiments to compare these techniques to guest paravirtualization technique on VMware's platform. These hardware assisted virtualization techniques have outperformed the performance benefits provided by VMI in most of the workloads. VMware expects that these hardware features will be ubiquitous in a couple of years, as a result, VMware has started a phased retirement of this feature from the hypervisor. Please note that VMI has always been an optimization and non-VMI kernels still work fine on VMware's platform. Latest versions of VMware's product which support VMI are, Workstation 7.0 and VSphere 4.0 on ESX side, future maintainence releases for these products will continue supporting VMI. For more details about VMI retirement take a look at this, http://blogs.vmware.com/guestosguide/2009/09/vmi-retirement.html This feature removal was scheduled for 2.6.37 back in September 2009. Signed-off-by: Alok N Kataria LKML-Reference: <1282600151.19396.22.camel@ank32.eng.vmware.com> Signed-off-by: H. Peter Anvin --- Documentation/feature-removal-schedule.txt | 28 ---------------------------- Documentation/kernel-parameters.txt | 2 +- 2 files changed, 1 insertion(+), 29 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 842aa9d..5e2bc4a 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -386,34 +386,6 @@ Who: Tejun Heo ---------------------------- -What: Support for VMware's guest paravirtuliazation technique [VMI] will be - dropped. -When: 2.6.37 or earlier. -Why: With the recent innovations in CPU hardware acceleration technologies - from Intel and AMD, VMware ran a few experiments to compare these - techniques to guest paravirtualization technique on VMware's platform. - These hardware assisted virtualization techniques have outperformed the - performance benefits provided by VMI in most of the workloads. VMware - expects that these hardware features will be ubiquitous in a couple of - years, as a result, VMware has started a phased retirement of this - feature from the hypervisor. We will be removing this feature from the - Kernel too. Right now we are targeting 2.6.37 but can retire earlier if - technical reasons (read opportunity to remove major chunk of pvops) - arise. - - Please note that VMI has always been an optimization and non-VMI kernels - still work fine on VMware's platform. - Latest versions of VMware's product which support VMI are, - Workstation 7.0 and VSphere 4.0 on ESX side, future maintainence - releases for these products will continue supporting VMI. - - For more details about VMI retirement take a look at this, - http://blogs.vmware.com/guestosguide/2009/09/vmi-retirement.html - -Who: Alok N Kataria - ----------------------------- - What: Support for lcd_switch and display_get in asus-laptop driver When: March 2010 Why: These two features use non-standard interfaces. There are the diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 2c85c06..5824098 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -455,7 +455,7 @@ and is between 256 and 4096 characters. It is defined in the file [ARM] imx_timer1,OSTS,netx_timer,mpu_timer2, pxa_timer,timer3,32k_counter,timer0_1 [AVR32] avr32 - [X86-32] pit,hpet,tsc,vmi-timer; + [X86-32] pit,hpet,tsc; scx200_hrt on Geode; cyclone on IBM x440 [MIPS] MIPS [PARISC] cr16 -- cgit v1.1 From 2c96c7751d2bb822542b03ddfaca70933f5aaf02 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Mon, 23 Aug 2010 16:34:02 -0700 Subject: rcu: upgrade stallwarn.txt documentation for CPU-bound RT processes CPU-bound real-time processes can cause RCU CPU stall warnings, and much other trouble as well. Document the fact that they can cause RCU CPU stall warnings. Suggested-by: Darren Hart Signed-off-by: Paul E. McKenney --- Documentation/RCU/stallwarn.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt index 44c6dcc9..862c08e 100644 --- a/Documentation/RCU/stallwarn.txt +++ b/Documentation/RCU/stallwarn.txt @@ -80,6 +80,24 @@ o A CPU looping with bottom halves disabled. This condition can o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel without invoking schedule(). +o A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might + happen to preempt a low-priority task in the middle of an RCU + read-side critical section. This is especially damaging if + that low-priority task is not permitted to run on any other CPU, + in which case the next RCU grace period can never complete, which + will eventually cause the system to run out of memory and hang. + While the system is in the process of running itself out of + memory, you might see stall-warning messages. + +o A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that + is running at a higher priority than the RCU softirq threads. + This will prevent RCU callbacks from ever being invoked, + and in a CONFIG_TREE_PREEMPT_RCU kernel will further prevent + RCU grace periods from ever completing. Either way, the + system will eventually run out of memory and hang. In the + CONFIG_TREE_PREEMPT_RCU case, you might see stall-warning + messages. + o A bug in the RCU implementation. o A hardware failure. This is quite unlikely, but has occurred -- cgit v1.1 From 352de5573f60af0ab054859931cfb68eecb1832b Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Tue, 17 Aug 2010 12:04:34 +0200 Subject: wireless: move documentation books This moves mac80211 documentation into a new 802.11 bookset and also adds a cfg80211 book to the set. All of this is rather incomplete, but it's easier to work with big code moving as a separate patch. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville --- Documentation/DocBook/80211.tmpl | 371 ++++++++++++++++++++++++++++++++++++ Documentation/DocBook/Makefile | 2 +- Documentation/DocBook/mac80211.tmpl | 337 -------------------------------- 3 files changed, 372 insertions(+), 338 deletions(-) create mode 100644 Documentation/DocBook/80211.tmpl delete mode 100644 Documentation/DocBook/mac80211.tmpl (limited to 'Documentation') diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl new file mode 100644 index 0000000..6f88e18 --- /dev/null +++ b/Documentation/DocBook/80211.tmpl @@ -0,0 +1,371 @@ + + + + + The 802.11 subsystems – for kernel developers + + Explaining wireless 802.11 networking in the Linux kernel + + + + 2007-2009 + Johannes Berg + + + + + Johannes + Berg + +
johannes@sipsolutions.net
+ + + + + + + This documentation is free software; you can redistribute + it and/or modify it under the terms of the GNU General Public + License version 2 as published by the Free Software Foundation. + + + This documentation 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 documentation; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, + MA 02111-1307 USA + + + For more details see the file COPYING in the source + distribution of Linux. + + + + + + These books attempt to give a description of the + various subsystems that play a role in 802.11 wireless + networking in Linux. Since these books are for kernel + developers they attempts to document the structures + and functions used in the kernel as well as giving a + higher-level overview. + + + The reader is expected to be familiar with the 802.11 + standard as published by the IEEE in 802.11-2007 (or + possibly later versions). References to this standard + will be given as "802.11-2007 8.1.5". + + + + + + The cfg80211 subsystem + + + +MISSING + + + + +!Finclude/net/cfg80211.h ieee80211_band + + + + + The mac80211 subsystem + +!Pinclude/net/mac80211.h Introduction +!Pinclude/net/mac80211.h Warning + + + + + + + + + The basic mac80211 driver interface + + + You should read and understand the information contained + within this part of the book while implementing a driver. + In some chapters, advanced usage is noted, that may be + skipped at first. + + + This part of the book only covers station and monitor mode + functionality, additional information required to implement + the other modes is covered in the second part of the book. + + + + + Basic hardware handling + TBD + + This chapter shall contain information on getting a hw + struct allocated and registered with mac80211. + + + Since it is required to allocate rates/modes before registering + a hw struct, this chapter shall also contain information on setting + up the rate/mode structs. + + + Additionally, some discussion about the callbacks and + the general programming model should be in here, including + the definition of ieee80211_ops which will be referred to + a lot. + + + Finally, a discussion of hardware capabilities should be done + with references to other parts of the book. + + +!Finclude/net/mac80211.h ieee80211_hw +!Finclude/net/mac80211.h ieee80211_hw_flags +!Finclude/net/mac80211.h SET_IEEE80211_DEV +!Finclude/net/mac80211.h SET_IEEE80211_PERM_ADDR +!Finclude/net/mac80211.h ieee80211_ops +!Finclude/net/mac80211.h ieee80211_alloc_hw +!Finclude/net/mac80211.h ieee80211_register_hw +!Finclude/net/mac80211.h ieee80211_get_tx_led_name +!Finclude/net/mac80211.h ieee80211_get_rx_led_name +!Finclude/net/mac80211.h ieee80211_get_assoc_led_name +!Finclude/net/mac80211.h ieee80211_get_radio_led_name +!Finclude/net/mac80211.h ieee80211_unregister_hw +!Finclude/net/mac80211.h ieee80211_free_hw + + + + PHY configuration + TBD + + This chapter should describe PHY handling including + start/stop callbacks and the various structures used. + +!Finclude/net/mac80211.h ieee80211_conf +!Finclude/net/mac80211.h ieee80211_conf_flags + + + + Virtual interfaces + TBD + + This chapter should describe virtual interface basics + that are relevant to the driver (VLANs, MGMT etc are not.) + It should explain the use of the add_iface/remove_iface + callbacks as well as the interface configuration callbacks. + + Things related to AP mode should be discussed there. + + Things related to supporting multiple interfaces should be + in the appropriate chapter, a BIG FAT note should be here about + this though and the recommendation to allow only a single + interface in STA mode at first! + +!Finclude/net/mac80211.h ieee80211_vif + + + + Receive and transmit processing + + what should be here + TBD + + This should describe the receive and transmit + paths in mac80211/the drivers as well as + transmit status handling. + + + + Frame format +!Pinclude/net/mac80211.h Frame format + + + Packet alignment +!Pnet/mac80211/rx.c Packet alignment + + + Calling into mac80211 from interrupts +!Pinclude/net/mac80211.h Calling mac80211 from interrupts + + + functions/definitions +!Finclude/net/mac80211.h ieee80211_rx_status +!Finclude/net/mac80211.h mac80211_rx_flags +!Finclude/net/mac80211.h ieee80211_tx_info +!Finclude/net/mac80211.h ieee80211_rx +!Finclude/net/mac80211.h ieee80211_rx_irqsafe +!Finclude/net/mac80211.h ieee80211_tx_status +!Finclude/net/mac80211.h ieee80211_tx_status_irqsafe +!Finclude/net/mac80211.h ieee80211_rts_get +!Finclude/net/mac80211.h ieee80211_rts_duration +!Finclude/net/mac80211.h ieee80211_ctstoself_get +!Finclude/net/mac80211.h ieee80211_ctstoself_duration +!Finclude/net/mac80211.h ieee80211_generic_frame_duration +!Finclude/net/mac80211.h ieee80211_wake_queue +!Finclude/net/mac80211.h ieee80211_stop_queue +!Finclude/net/mac80211.h ieee80211_wake_queues +!Finclude/net/mac80211.h ieee80211_stop_queues + + + + + Frame filtering +!Pinclude/net/mac80211.h Frame filtering +!Finclude/net/mac80211.h ieee80211_filter_flags + + + + + Advanced driver interface + + + Information contained within this part of the book is + of interest only for advanced interaction of mac80211 + with drivers to exploit more hardware capabilities and + improve performance. + + + + + Hardware crypto acceleration +!Pinclude/net/mac80211.h Hardware crypto acceleration + +!Finclude/net/mac80211.h set_key_cmd +!Finclude/net/mac80211.h ieee80211_key_conf +!Finclude/net/mac80211.h ieee80211_key_alg +!Finclude/net/mac80211.h ieee80211_key_flags + + + + Powersave support +!Pinclude/net/mac80211.h Powersave support + + + + Beacon filter support +!Pinclude/net/mac80211.h Beacon filter support +!Finclude/net/mac80211.h ieee80211_beacon_loss + + + + Multiple queues and QoS support + TBD +!Finclude/net/mac80211.h ieee80211_tx_queue_params + + + + Access point mode support + TBD + Some parts of the if_conf should be discussed here instead + + Insert notes about VLAN interfaces with hw crypto here or + in the hw crypto chapter. + +!Finclude/net/mac80211.h ieee80211_get_buffered_bc +!Finclude/net/mac80211.h ieee80211_beacon_get + + + + Supporting multiple virtual interfaces + TBD + + Note: WDS with identical MAC address should almost always be OK + + + Insert notes about having multiple virtual interfaces with + different MAC addresses here, note which configurations are + supported by mac80211, add notes about supporting hw crypto + with it. + + + + + Hardware scan offload + TBD +!Finclude/net/mac80211.h ieee80211_scan_completed + + + + + Rate control interface + + TBD + + This part of the book describes the rate control algorithm + interface and how it relates to mac80211 and drivers. + + + + dummy chapter + TBD + + + + + Internals + + TBD + + This part of the book describes mac80211 internals. + + + + + Key handling + + Key handling basics +!Pnet/mac80211/key.c Key handling basics + + + MORE TBD + TBD + + + + + Receive processing + TBD + + + + Transmit processing + TBD + + + + Station info handling + + Programming information +!Fnet/mac80211/sta_info.h sta_info +!Fnet/mac80211/sta_info.h ieee80211_sta_info_flags + + + STA information lifetime rules +!Pnet/mac80211/sta_info.c STA information lifetime rules + + + + + Synchronisation + TBD + Locking, lots of RCU + + + + diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index c7e5dc7..b6f2ba2 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -12,7 +12,7 @@ DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \ kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ - mac80211.xml debugobjects.xml sh.xml regulator.xml \ + 80211.xml debugobjects.xml sh.xml regulator.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ tracepoint.xml media.xml drm.xml diff --git a/Documentation/DocBook/mac80211.tmpl b/Documentation/DocBook/mac80211.tmpl deleted file mode 100644 index affb15a..0000000 --- a/Documentation/DocBook/mac80211.tmpl +++ /dev/null @@ -1,337 +0,0 @@ - - - - - - The mac80211 subsystem for kernel developers - - - - Johannes - Berg - -
johannes@sipsolutions.net
- - - - - - 2007-2009 - Johannes Berg - - - - - This documentation is free software; you can redistribute - it and/or modify it under the terms of the GNU General Public - License version 2 as published by the Free Software Foundation. - - - - This documentation 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 documentation; if not, write to the Free - Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, - MA 02111-1307 USA - - - - For more details see the file COPYING in the source - distribution of Linux. - - - - -!Pinclude/net/mac80211.h Introduction -!Pinclude/net/mac80211.h Warning - - - - - - - - - The basic mac80211 driver interface - - - You should read and understand the information contained - within this part of the book while implementing a driver. - In some chapters, advanced usage is noted, that may be - skipped at first. - - - This part of the book only covers station and monitor mode - functionality, additional information required to implement - the other modes is covered in the second part of the book. - - - - - Basic hardware handling - TBD - - This chapter shall contain information on getting a hw - struct allocated and registered with mac80211. - - - Since it is required to allocate rates/modes before registering - a hw struct, this chapter shall also contain information on setting - up the rate/mode structs. - - - Additionally, some discussion about the callbacks and - the general programming model should be in here, including - the definition of ieee80211_ops which will be referred to - a lot. - - - Finally, a discussion of hardware capabilities should be done - with references to other parts of the book. - - -!Finclude/net/mac80211.h ieee80211_hw -!Finclude/net/mac80211.h ieee80211_hw_flags -!Finclude/net/mac80211.h SET_IEEE80211_DEV -!Finclude/net/mac80211.h SET_IEEE80211_PERM_ADDR -!Finclude/net/mac80211.h ieee80211_ops -!Finclude/net/mac80211.h ieee80211_alloc_hw -!Finclude/net/mac80211.h ieee80211_register_hw -!Finclude/net/mac80211.h ieee80211_get_tx_led_name -!Finclude/net/mac80211.h ieee80211_get_rx_led_name -!Finclude/net/mac80211.h ieee80211_get_assoc_led_name -!Finclude/net/mac80211.h ieee80211_get_radio_led_name -!Finclude/net/mac80211.h ieee80211_unregister_hw -!Finclude/net/mac80211.h ieee80211_free_hw - - - - PHY configuration - TBD - - This chapter should describe PHY handling including - start/stop callbacks and the various structures used. - -!Finclude/net/mac80211.h ieee80211_conf -!Finclude/net/mac80211.h ieee80211_conf_flags - - - - Virtual interfaces - TBD - - This chapter should describe virtual interface basics - that are relevant to the driver (VLANs, MGMT etc are not.) - It should explain the use of the add_iface/remove_iface - callbacks as well as the interface configuration callbacks. - - Things related to AP mode should be discussed there. - - Things related to supporting multiple interfaces should be - in the appropriate chapter, a BIG FAT note should be here about - this though and the recommendation to allow only a single - interface in STA mode at first! - -!Finclude/net/mac80211.h ieee80211_vif - - - - Receive and transmit processing - - what should be here - TBD - - This should describe the receive and transmit - paths in mac80211/the drivers as well as - transmit status handling. - - - - Frame format -!Pinclude/net/mac80211.h Frame format - - - Packet alignment -!Pnet/mac80211/rx.c Packet alignment - - - Calling into mac80211 from interrupts -!Pinclude/net/mac80211.h Calling mac80211 from interrupts - - - functions/definitions -!Finclude/net/mac80211.h ieee80211_rx_status -!Finclude/net/mac80211.h mac80211_rx_flags -!Finclude/net/mac80211.h ieee80211_tx_info -!Finclude/net/mac80211.h ieee80211_rx -!Finclude/net/mac80211.h ieee80211_rx_irqsafe -!Finclude/net/mac80211.h ieee80211_tx_status -!Finclude/net/mac80211.h ieee80211_tx_status_irqsafe -!Finclude/net/mac80211.h ieee80211_rts_get -!Finclude/net/mac80211.h ieee80211_rts_duration -!Finclude/net/mac80211.h ieee80211_ctstoself_get -!Finclude/net/mac80211.h ieee80211_ctstoself_duration -!Finclude/net/mac80211.h ieee80211_generic_frame_duration -!Finclude/net/mac80211.h ieee80211_wake_queue -!Finclude/net/mac80211.h ieee80211_stop_queue -!Finclude/net/mac80211.h ieee80211_wake_queues -!Finclude/net/mac80211.h ieee80211_stop_queues - - - - - Frame filtering -!Pinclude/net/mac80211.h Frame filtering -!Finclude/net/mac80211.h ieee80211_filter_flags - - - - - Advanced driver interface - - - Information contained within this part of the book is - of interest only for advanced interaction of mac80211 - with drivers to exploit more hardware capabilities and - improve performance. - - - - - Hardware crypto acceleration -!Pinclude/net/mac80211.h Hardware crypto acceleration - -!Finclude/net/mac80211.h set_key_cmd -!Finclude/net/mac80211.h ieee80211_key_conf -!Finclude/net/mac80211.h ieee80211_key_alg -!Finclude/net/mac80211.h ieee80211_key_flags - - - - Powersave support -!Pinclude/net/mac80211.h Powersave support - - - - Beacon filter support -!Pinclude/net/mac80211.h Beacon filter support -!Finclude/net/mac80211.h ieee80211_beacon_loss - - - - Multiple queues and QoS support - TBD -!Finclude/net/mac80211.h ieee80211_tx_queue_params - - - - Access point mode support - TBD - Some parts of the if_conf should be discussed here instead - - Insert notes about VLAN interfaces with hw crypto here or - in the hw crypto chapter. - -!Finclude/net/mac80211.h ieee80211_get_buffered_bc -!Finclude/net/mac80211.h ieee80211_beacon_get - - - - Supporting multiple virtual interfaces - TBD - - Note: WDS with identical MAC address should almost always be OK - - - Insert notes about having multiple virtual interfaces with - different MAC addresses here, note which configurations are - supported by mac80211, add notes about supporting hw crypto - with it. - - - - - Hardware scan offload - TBD -!Finclude/net/mac80211.h ieee80211_scan_completed - - - - - Rate control interface - - TBD - - This part of the book describes the rate control algorithm - interface and how it relates to mac80211 and drivers. - - - - dummy chapter - TBD - - - - - Internals - - TBD - - This part of the book describes mac80211 internals. - - - - - Key handling - - Key handling basics -!Pnet/mac80211/key.c Key handling basics - - - MORE TBD - TBD - - - - - Receive processing - TBD - - - - Transmit processing - TBD - - - - Station info handling - - Programming information -!Fnet/mac80211/sta_info.h sta_info -!Fnet/mac80211/sta_info.h ieee80211_sta_info_flags - - - STA information lifetime rules -!Pnet/mac80211/sta_info.c STA information lifetime rules - - - - - Synchronisation - TBD - Locking, lots of RCU - - - -- cgit v1.1 From 633dd1ea683d907af944bcd9814092efe9869b05 Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Wed, 18 Aug 2010 15:01:23 +0200 Subject: mac80211: fix docbook Fix a small problem in the documentation for ieee80211_request_smps, and a now erroneous inclusion of enum ieee80211_key_alg, which no longer exists after the change to ciphers. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville --- Documentation/DocBook/80211.tmpl | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index 6f88e18..52310ac 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -248,7 +248,6 @@ MISSING !Finclude/net/mac80211.h set_key_cmd !Finclude/net/mac80211.h ieee80211_key_conf -!Finclude/net/mac80211.h ieee80211_key_alg !Finclude/net/mac80211.h ieee80211_key_flags -- cgit v1.1 From d70e96932de55fb2c05b1c0af1dff178651a9b77 Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Thu, 19 Aug 2010 16:11:27 +0200 Subject: cfg80211: add some documentation Add some documentation for cfg80211. I'm hoping some of the regulatory documentation will be filled by somebody more familiar with it, hint hint! :) Signed-off-by: Johannes Berg Signed-off-by: John W. Linville --- Documentation/DocBook/80211.tmpl | 136 +++++++++++++++++++++++++++++++++++++-- 1 file changed, 131 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index 52310ac..b84c928 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -65,18 +65,144 @@ +!Ainclude/net/cfg80211.h The cfg80211 subsystem - -MISSING - +!Pinclude/net/cfg80211.h Introduction - + + Device registration +!Pinclude/net/cfg80211.h Device registration !Finclude/net/cfg80211.h ieee80211_band - +!Finclude/net/cfg80211.h ieee80211_channel_flags +!Finclude/net/cfg80211.h ieee80211_channel +!Finclude/net/cfg80211.h ieee80211_rate_flags +!Finclude/net/cfg80211.h ieee80211_rate +!Finclude/net/cfg80211.h ieee80211_sta_ht_cap +!Finclude/net/cfg80211.h ieee80211_supported_band +!Finclude/net/cfg80211.h cfg80211_signal_type +!Finclude/net/cfg80211.h wiphy_params_flags +!Finclude/net/cfg80211.h wiphy_flags +!Finclude/net/cfg80211.h wiphy +!Finclude/net/cfg80211.h wireless_dev +!Finclude/net/cfg80211.h wiphy_new +!Finclude/net/cfg80211.h wiphy_register +!Finclude/net/cfg80211.h wiphy_unregister +!Finclude/net/cfg80211.h wiphy_free + +!Finclude/net/cfg80211.h wiphy_name +!Finclude/net/cfg80211.h wiphy_dev +!Finclude/net/cfg80211.h wiphy_priv +!Finclude/net/cfg80211.h priv_to_wiphy +!Finclude/net/cfg80211.h set_wiphy_dev +!Finclude/net/cfg80211.h wdev_priv + + + Actions and configuration +!Pinclude/net/cfg80211.h Actions and configuration +!Finclude/net/cfg80211.h cfg80211_ops +!Finclude/net/cfg80211.h vif_params +!Finclude/net/cfg80211.h key_params +!Finclude/net/cfg80211.h survey_info_flags +!Finclude/net/cfg80211.h survey_info +!Finclude/net/cfg80211.h beacon_parameters +!Finclude/net/cfg80211.h plink_actions +!Finclude/net/cfg80211.h station_parameters +!Finclude/net/cfg80211.h station_info_flags +!Finclude/net/cfg80211.h rate_info_flags +!Finclude/net/cfg80211.h rate_info +!Finclude/net/cfg80211.h station_info +!Finclude/net/cfg80211.h monitor_flags +!Finclude/net/cfg80211.h mpath_info_flags +!Finclude/net/cfg80211.h mpath_info +!Finclude/net/cfg80211.h bss_parameters +!Finclude/net/cfg80211.h ieee80211_txq_params +!Finclude/net/cfg80211.h cfg80211_crypto_settings +!Finclude/net/cfg80211.h cfg80211_auth_request +!Finclude/net/cfg80211.h cfg80211_assoc_request +!Finclude/net/cfg80211.h cfg80211_deauth_request +!Finclude/net/cfg80211.h cfg80211_disassoc_request +!Finclude/net/cfg80211.h cfg80211_ibss_params +!Finclude/net/cfg80211.h cfg80211_connect_params +!Finclude/net/cfg80211.h cfg80211_pmksa +!Finclude/net/cfg80211.h cfg80211_send_rx_auth +!Finclude/net/cfg80211.h cfg80211_send_auth_timeout +!Finclude/net/cfg80211.h __cfg80211_auth_canceled +!Finclude/net/cfg80211.h cfg80211_send_rx_assoc +!Finclude/net/cfg80211.h cfg80211_send_assoc_timeout +!Finclude/net/cfg80211.h cfg80211_send_deauth +!Finclude/net/cfg80211.h __cfg80211_send_deauth +!Finclude/net/cfg80211.h cfg80211_send_disassoc +!Finclude/net/cfg80211.h __cfg80211_send_disassoc +!Finclude/net/cfg80211.h cfg80211_ibss_joined +!Finclude/net/cfg80211.h cfg80211_connect_result +!Finclude/net/cfg80211.h cfg80211_roamed +!Finclude/net/cfg80211.h cfg80211_disconnected +!Finclude/net/cfg80211.h cfg80211_ready_on_channel +!Finclude/net/cfg80211.h cfg80211_remain_on_channel_expired +!Finclude/net/cfg80211.h cfg80211_new_sta +!Finclude/net/cfg80211.h cfg80211_rx_mgmt +!Finclude/net/cfg80211.h cfg80211_mgmt_tx_status +!Finclude/net/cfg80211.h cfg80211_cqm_rssi_notify +!Finclude/net/cfg80211.h cfg80211_michael_mic_failure + + + Scanning and BSS list handling +!Pinclude/net/cfg80211.h Scanning and BSS list handling +!Finclude/net/cfg80211.h cfg80211_ssid +!Finclude/net/cfg80211.h cfg80211_scan_request +!Finclude/net/cfg80211.h cfg80211_scan_done +!Finclude/net/cfg80211.h cfg80211_bss +!Finclude/net/cfg80211.h cfg80211_inform_bss_frame +!Finclude/net/cfg80211.h cfg80211_inform_bss +!Finclude/net/cfg80211.h cfg80211_unlink_bss +!Finclude/net/cfg80211.h cfg80211_find_ie +!Finclude/net/cfg80211.h ieee80211_bss_get_ie + + + Utility functions +!Pinclude/net/cfg80211.h Utility functions +!Finclude/net/cfg80211.h ieee80211_channel_to_frequency +!Finclude/net/cfg80211.h ieee80211_frequency_to_channel +!Finclude/net/cfg80211.h ieee80211_get_channel +!Finclude/net/cfg80211.h ieee80211_get_response_rate +!Finclude/net/cfg80211.h ieee80211_hdrlen +!Finclude/net/cfg80211.h ieee80211_get_hdrlen_from_skb +!Finclude/net/cfg80211.h ieee80211_radiotap_iterator + + + Data path helpers +!Pinclude/net/cfg80211.h Data path helpers +!Finclude/net/cfg80211.h ieee80211_data_to_8023 +!Finclude/net/cfg80211.h ieee80211_data_from_8023 +!Finclude/net/cfg80211.h ieee80211_amsdu_to_8023s +!Finclude/net/cfg80211.h cfg80211_classify8021d + + + Regulatory enforcement infrastructure +!Pinclude/net/cfg80211.h Regulatory enforcement infrastructure +!Finclude/net/cfg80211.h regulatory_hint +!Finclude/net/cfg80211.h wiphy_apply_custom_regulatory +!Finclude/net/cfg80211.h freq_reg_info + + + RFkill integration +!Pinclude/net/cfg80211.h RFkill integration +!Finclude/net/cfg80211.h wiphy_rfkill_set_hw_state +!Finclude/net/cfg80211.h wiphy_rfkill_start_polling +!Finclude/net/cfg80211.h wiphy_rfkill_stop_polling + + + Test mode +!Pinclude/net/cfg80211.h Test mode +!Finclude/net/cfg80211.h cfg80211_testmode_alloc_reply_skb +!Finclude/net/cfg80211.h cfg80211_testmode_reply +!Finclude/net/cfg80211.h cfg80211_testmode_alloc_event_skb +!Finclude/net/cfg80211.h cfg80211_testmode_event + -- cgit v1.1 From 79dd9182db2072d63ccf160bb9a3463b1c952723 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Sat, 21 Aug 2010 01:51:44 +0200 Subject: PCI: PCIe: Introduce commad line switch for disabling port services Introduce kernel command line switch pcie_ports= allowing one to disable all of the native PCIe port services, so that PCIe ports are treated like PCI-to-PCI bridges. Signed-off-by: Rafael J. Wysocki Signed-off-by: Jesse Barnes --- Documentation/kernel-parameters.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 873b680..b9008fc 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2042,6 +2042,10 @@ and is between 256 and 4096 characters. It is defined in the file force Enable ASPM even on devices that claim not to support it. WARNING: Forcing ASPM on may cause system lockups. + pcie_ports= [PCIE] PCIe ports handling: + compat Treat PCIe ports as PCI-to-PCI bridges, disable the PCIe + ports driver. + pcie_pme= [PCIE,PM] Native PCIe PME signaling options: Format: {auto|force}[,nomsi] auto Use native PCIe PME signaling if the BIOS allows the -- cgit v1.1 From 28eb5f274a305bf3a13b2c80c4804d4515d05c64 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Sat, 21 Aug 2010 22:02:38 +0200 Subject: PCI: PCIe: Ask BIOS for control of all native services at once After commit 852972acff8f10f3a15679be2059bb94916cba5d (ACPI: Disable ASPM if the platform won't provide _OSC control for PCIe) control of the PCIe Capability Structure is unconditionally requested by acpi_pci_root_add(), which in principle may cause problems to happen in two ways. First, the BIOS may refuse to give control of the PCIe Capability Structure if it is not asked for any of the _OSC features depending on it at the same time. Second, the BIOS may assume that control of the _OSC features depending on the PCIe Capability Structure will be requested in the future and may behave incorrectly if that doesn't happen. For this reason, control of the PCIe Capability Structure should always be requested along with control of any other _OSC features that may depend on it (ie. PCIe native PME, PCIe native hot-plug, PCIe AER). Rework the PCIe port driver so that (1) it checks which native PCIe port services can be enabled, according to the BIOS, and (2) it requests control of all these services simultaneously. In particular, this causes pcie_portdrv_probe() to fail if the BIOS refuses to grant control of the PCIe Capability Structure, which means that no native PCIe port services can be enabled for the PCIe Root Complex the given port belongs to. If that happens, ASPM is disabled to avoid problems with mishandling it by the part of the PCIe hierarchy for which control of the PCIe Capability Structure has not been received. Make it possible to override this behavior using 'pcie_ports=native' (use the PCIe native services regardless of the BIOS response to the control request), or 'pcie_ports=compat' (do not use the PCIe native services at all). Accordingly, rework the existing PCIe port service drivers so that they don't request control of the services directly. Signed-off-by: Rafael J. Wysocki Signed-off-by: Jesse Barnes --- Documentation/kernel-parameters.txt | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index b9008fc..8f126e8 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2043,18 +2043,17 @@ and is between 256 and 4096 characters. It is defined in the file WARNING: Forcing ASPM on may cause system lockups. pcie_ports= [PCIE] PCIe ports handling: + auto Ask the BIOS whether or not to use native PCIe services + associated with PCIe ports (PME, hot-plug, AER). Use + them only if that is allowed by the BIOS. + native Use native PCIe services associated with PCIe ports + unconditionally. compat Treat PCIe ports as PCI-to-PCI bridges, disable the PCIe ports driver. pcie_pme= [PCIE,PM] Native PCIe PME signaling options: - Format: {auto|force}[,nomsi] - auto Use native PCIe PME signaling if the BIOS allows the - kernel to control PCIe config registers of root ports. - force Use native PCIe PME signaling even if the BIOS refuses - to allow the kernel to control the relevant PCIe config - registers. nomsi Do not use MSI for native PCIe PME signaling (this makes - all PCIe root ports use INTx for everything). + all PCIe root ports use INTx for all services). pcmv= [HW,PCMCIA] BadgePAD 4 -- cgit v1.1 From 9ea77bdb39b62c9bf9fd3cdd1c25a9420bccd380 Mon Sep 17 00:00:00 2001 From: "H. Peter Anvin" Date: Wed, 25 Aug 2010 16:38:20 -0700 Subject: x86, bios: Make the x86 early memory reservation a kernel option Add a kernel command-line option so the x86 early memory reservation size can be adjusted at runtime instead of only at compile time. Suggested-by: Andrew Morton LKML-Reference: Signed-off-by: H. Peter Anvin --- Documentation/kernel-parameters.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 2c85c06..41ce93e 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2150,6 +2150,11 @@ and is between 256 and 4096 characters. It is defined in the file Reserves a hole at the top of the kernel virtual address space. + reservelow= [X86] + Format: nn[K] + Set the amount of memory to reserve for BIOS at + the bottom of the address space. + reset_devices [KNL] Force drivers to reset the underlying device during initialization. -- cgit v1.1 From f846619e7f875b0efa9853b1c821bbc756656d47 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Fri, 27 Aug 2010 08:39:48 -0600 Subject: lguest: clean up warnings in demonstration launcher. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit These days the headers we use are in glibc. If those are too old, you can add the -I lines to get the kernel headers. In file included from ../../include/linux/if_tun.h:19, from lguest.c:33: ../../include/linux/types.h:13:2: warning: #warning "Attempt to use kernel headers from user space, see http://kernelnewbies.org/KernelHeaders" lguest.c: In function ‘setup_tun_net’: lguest.c:1456: warning: dereferencing pointer ‘sin’ does break strict-aliasing rules lguest.c:1457: warning: dereferencing pointer ‘sin’ does break strict-aliasing rules lguest.c:1450: note: initialized from here Signed-off-by: Rusty Russell --- Documentation/lguest/Makefile | 3 ++- Documentation/lguest/lguest.c | 23 ++++++++++++----------- 2 files changed, 14 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/lguest/Makefile b/Documentation/lguest/Makefile index 28c8cdf..bebac6b 100644 --- a/Documentation/lguest/Makefile +++ b/Documentation/lguest/Makefile @@ -1,5 +1,6 @@ # This creates the demonstration utility "lguest" which runs a Linux guest. -CFLAGS:=-m32 -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -I../../include -I../../arch/x86/include -U_FORTIFY_SOURCE +# Missing headers? Add "-I../../include -I../../arch/x86/include" +CFLAGS:=-m32 -Wall -Wmissing-declarations -Wmissing-prototypes -O3 -U_FORTIFY_SOURCE all: lguest diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c index e9ce3c5..8a6a8c6 100644 --- a/Documentation/lguest/lguest.c +++ b/Documentation/lguest/lguest.c @@ -39,14 +39,14 @@ #include #include #include -#include "linux/lguest_launcher.h" -#include "linux/virtio_config.h" -#include "linux/virtio_net.h" -#include "linux/virtio_blk.h" -#include "linux/virtio_console.h" -#include "linux/virtio_rng.h" -#include "linux/virtio_ring.h" -#include "asm/bootparam.h" +#include +#include +#include +#include +#include +#include +#include +#include "../../include/linux/lguest_launcher.h" /*L:110 * We can ignore the 42 include files we need for this program, but I do want * to draw attention to the use of kernel-style types. @@ -1447,14 +1447,15 @@ static void add_to_bridge(int fd, const char *if_name, const char *br_name) static void configure_device(int fd, const char *tapif, u32 ipaddr) { struct ifreq ifr; - struct sockaddr_in *sin = (struct sockaddr_in *)&ifr.ifr_addr; + struct sockaddr_in sin; memset(&ifr, 0, sizeof(ifr)); strcpy(ifr.ifr_name, tapif); /* Don't read these incantations. Just cut & paste them like I did! */ - sin->sin_family = AF_INET; - sin->sin_addr.s_addr = htonl(ipaddr); + sin.sin_family = AF_INET; + sin.sin_addr.s_addr = htonl(ipaddr); + memcpy(&ifr.ifr_addr, &sin, sizeof(sin)); if (ioctl(fd, SIOCSIFADDR, &ifr) != 0) err(1, "Setting %s interface address", tapif); ifr.ifr_flags = IFF_UP; -- cgit v1.1 From 7c38875a0d0a9b90eee66be79e36995c86acc70c Mon Sep 17 00:00:00 2001 From: Jason Baron Date: Thu, 26 Aug 2010 10:35:43 -0400 Subject: workqueue: Add a workqueue chapter to the tracepoint docbook Add a workqueue chapter to the traceopint docbook. Current book is at: http://www.kernel.org/doc/htmldocs/tracepoint/ Signed-off-by: Jason Baron Signed-off-by: Tejun Heo --- Documentation/DocBook/tracepoint.tmpl | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/tracepoint.tmpl b/Documentation/DocBook/tracepoint.tmpl index e8473ea..b57a9ed 100644 --- a/Documentation/DocBook/tracepoint.tmpl +++ b/Documentation/DocBook/tracepoint.tmpl @@ -104,4 +104,9 @@ Block IO !Iinclude/trace/events/block.h + + + Workqueue +!Iinclude/trace/events/workqueue.h + -- cgit v1.1 From b49d09c5bf9a3261ae711ac3bb91e22c172db428 Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Fri, 27 Aug 2010 11:29:24 +0200 Subject: cfg80211 docbook: remove erronous !A My previous patch erroneously included an !A line (for some checking I am working on) that isn't yet supported by the docbook tools, so remove it. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville --- Documentation/DocBook/80211.tmpl | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index b84c928..19a1210 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -65,7 +65,6 @@ -!Ainclude/net/cfg80211.h The cfg80211 subsystem -- cgit v1.1 From 29cf28ae8dc244f89e213dc198f2286659d521b5 Mon Sep 17 00:00:00 2001 From: Rafi Rubin Date: Thu, 26 Aug 2010 00:54:54 -0400 Subject: HID: ntrig: add documention The doctumentation includes a brief introduction to the driver and explanations of the filtering parameters as well as a discussion of the need for and working of the filters. Signed-off-by: Rafi Rubin Signed-off-by: Jiri Kosina --- Documentation/input/ntrig.txt | 126 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 126 insertions(+) create mode 100644 Documentation/input/ntrig.txt (limited to 'Documentation') diff --git a/Documentation/input/ntrig.txt b/Documentation/input/ntrig.txt new file mode 100644 index 0000000..be1fd98 --- /dev/null +++ b/Documentation/input/ntrig.txt @@ -0,0 +1,126 @@ +N-Trig touchscreen Driver +------------------------- + Copyright (c) 2008-2010 Rafi Rubin + Copyright (c) 2009-2010 Stephane Chatty + +This driver provides support for N-Trig pen and multi-touch sensors. Single +and multi-touch events are translated to the appropriate protocols for +the hid and input systems. Pen events are sufficiently hid compliant and +are left to the hid core. The driver also provides additional filtering +and utility functions accessible with sysfs and module parameters. + +This driver has been reported to work properly with multiple N-Trig devices +attached. + + +Parameters +---------- + +Note: values set at load time are global and will apply to all applicable +devices. Adjusting parameters with sysfs will override the load time values, +but only for that one device. + +The following parameters are used to configure filters to reduce noise: + +activate_slack number of fingers to ignore before processing events + +activation_height size threshold to activate immediately +activation_width + +min_height size threshold bellow which fingers are ignored +min_width both to decide activation and during activity + +deactivate_slack the number of "no contact" frames to ignore before + propagating the end of activity events + +When the last finger is removed from the device, it sends a number of empty +frames. By holding off on deactivation for a few frames we can tolerate false +erroneous disconnects, where the sensor may mistakenly not detect a finger that +is still present. Thus deactivate_slack addresses problems where a users might +see breaks in lines during drawing, or drop an object during a long drag. + + +Additional sysfs items +---------------------- + +These nodes just provide easy access to the ranges reported by the device. +sensor_logical_height the range for positions reported during activity +sensor_logical_width + +sensor_physical_height internal ranges not used for normal events but +sensor_physical_width useful for tuning + +All N-Trig devices with product id of 1 report events in the ranges of +X: 0-9600 +Y: 0-7200 +However not all of these devices have the same physical dimensions. Most +seem to be 12" sensors (Dell Latitude XT and XT2 and the HP TX2), and +at least one model (Dell Studio 17) has a 17" sensor. The ratio of physical +to logical sizes is used to adjust the size based filter parameters. + + +Filtering +--------- + +With the release of the early multi-touch firmwares it became increasingly +obvious that these sensors were prone to erroneous events. Users reported +seeing both inappropriately dropped contact and ghosts, contacts reported +where no finger was actually touching the screen. + +Deactivation slack helps prevent dropped contact for single touch use, but does +not address the problem of dropping one of more contacts while other contacts +are still active. Drops in the multi-touch context require additional +processing and should be handled in tandem with tacking. + +As observed ghost contacts are similar to actual use of the sensor, but they +seem to have different profiles. Ghost activity typically shows up as small +short lived touches. As such, I assume that the longer the continuous stream +of events the more likely those events are from a real contact, and that the +larger the size of each contact the more likely it is real. Balancing the +goals of preventing ghosts and accepting real events quickly (to minimize +user observable latency), the filter accumulates confidence for incoming +events until it hits thresholds and begins propagating. In the interest in +minimizing stored state as well as the cost of operations to make a decision, +I've kept that decision simple. + +Time is measured in terms of the number of fingers reported, not frames since +the probability of multiple simultaneous ghosts is expected to drop off +dramatically with increasing numbers. Rather than accumulate weight as a +function of size, I just use it as a binary threshold. A sufficiently large +contact immediately overrides the waiting period and leads to activation. + +Setting the activation size thresholds to large values will result in deciding +primarily on activation slack. If you see longer lived ghosts, turning up the +activation slack while reducing the size thresholds may suffice to eliminate +the ghosts while keeping the screen quite responsive to firm taps. + +Contacts continue to be filtered with min_height and min_width even after +the initial activation filter is satisfied. The intent is to provide +a mechanism for filtering out ghosts in the form of an extra finger while +you actually are using the screen. In practice this sort of ghost has +been far less problematic or relatively rare and I've left the defaults +set to 0 for both parameters, effectively turning off that filter. + +I don't know what the optimal values are for these filters. If the defaults +don't work for you, please play with the parameters. If you do find other +values more comfortable, I would appreciate feedback. + +The calibration of these devices does drift over time. If ghosts or contact +dropping worsen and interfere with the normal usage of your device, try +recalibrating it. + + +Calibration +----------- + +The N-Trig windows tools provide calibration and testing routines. Also an +unofficial unsupported set of user space tools including a calibrator is +available at: +http://code.launchpad.net/~rafi-seas/+junk/ntrig_calib + + +Tracking +-------- + +As of yet, all tested N-Trig firmwares do not track fingers. When multiple +contacts are active they seem to be sorted primarily by Y position. -- cgit v1.1 From 4886fcad6e12572afbd230dfab1b268eace20d6d Mon Sep 17 00:00:00 2001 From: Gerrit Renker Date: Sun, 29 Aug 2010 19:23:13 +0000 Subject: dccp ccid-2: Share TCP's minimum RTO code Using a fixed RTO_MIN of 0.2 seconds was found to cause problems for CCID-2 over 802.11g: at least once per session there was a spurious timeout. It helped to then increase the the value of RTO_MIN over this link. Since the problem is the same as in TCP, this patch makes the solution from commit "05bb1fad1cde025a864a90cfeb98dcbefe78a44a" "[TCP]: Allow minimum RTO to be configurable via routing metrics." available to DCCP. This avoids reinventing the wheel, so that e.g. the following works in the expected way now also for CCID-2: > ip route change 10.0.0.2 rto_min 800 dev ath0 Luckily this useful rto_min function was recently moved to net/tcp.h, which simplifies sharing code originating from TCP. Documentation also updated (plus minor whitespace fixes). Signed-off-by: Gerrit Renker Signed-off-by: David S. Miller --- Documentation/networking/dccp.txt | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/dccp.txt b/Documentation/networking/dccp.txt index a62fdf7..cdb6492 100644 --- a/Documentation/networking/dccp.txt +++ b/Documentation/networking/dccp.txt @@ -1,18 +1,20 @@ DCCP protocol -============ +============= Contents ======== - - Introduction - Missing features - Socket options +- Sysctl variables +- IOCTLs +- Other tunables - Notes + Introduction ============ - Datagram Congestion Control Protocol (DCCP) is an unreliable, connection oriented protocol designed to solve issues present in UDP and TCP, particularly for real-time and multimedia (streaming) traffic. @@ -29,9 +31,9 @@ It has a base protocol and pluggable congestion control IDs (CCIDs). DCCP is a Proposed Standard (RFC 2026), and the homepage for DCCP as a protocol is at http://www.ietf.org/html.charters/dccp-charter.html + Missing features ================ - The Linux DCCP implementation does not currently support all the features that are specified in RFCs 4340...42. @@ -45,7 +47,6 @@ http://linux-net.osdl.org/index.php/DCCP_Testing#Experimental_DCCP_source_tree Socket options ============== - DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of service codes (RFC 4340, sec. 8.1.2); if this socket option is not set, the socket will fall back to 0 (which means that no meaningful service code @@ -112,6 +113,7 @@ DCCP_SOCKOPT_CCID_TX_INFO On unidirectional connections it is useful to close the unused half-connection via shutdown (SHUT_WR or SHUT_RD): this will reduce per-packet processing costs. + Sysctl variables ================ Several DCCP default parameters can be managed by the following sysctls @@ -155,15 +157,27 @@ sync_ratelimit = 125 ms sequence-invalid packets on the same socket (RFC 4340, 7.5.4). The unit of this parameter is milliseconds; a value of 0 disables rate-limiting. + IOCTLS ====== FIONREAD Works as in udp(7): returns in the `int' argument pointer the size of the next pending datagram in bytes, or 0 when no datagram is pending. + +Other tunables +============== +Per-route rto_min support + CCID-2 supports the RTAX_RTO_MIN per-route setting for the minimum value + of the RTO timer. This setting can be modified via the 'rto_min' option + of iproute2; for example: + > ip route change 10.0.0.0/24 rto_min 250j dev wlan0 + > ip route add 10.0.0.254/32 rto_min 800j dev wlan0 + > ip route show dev wlan0 + + Notes ===== - DCCP does not travel through NAT successfully at present on many boxes. This is because the checksum covers the pseudo-header as per TCP and UDP. Linux NAT support for DCCP has been added. -- cgit v1.1 From 89858ad14307a398961a0f1414b04053c1475e4f Mon Sep 17 00:00:00 2001 From: Gerrit Renker Date: Sun, 29 Aug 2010 19:23:14 +0000 Subject: dccp ccid-3: use per-route RTO or TCP RTO as fallback This makes RTAX_RTO_MIN also available to CCID-3, replacing the compile-time RTO lower bound with a per-route tunable value. The original Kconfig option solved the problem that a very low RTT (in the order of HZ) can trigger too frequent and unnecessary reductions of the sending rate. This tunable does not affect the initial RTO value of 2 seconds specified in RFC 5348, section 4.2 and Appendix B. But like the hardcoded Kconfig value, it allows to adapt to network conditions. The same effect as the original Kconfig option of 100ms is now achieved by > ip route replace to unicast 192.168.0.0/24 rto_min 100j dev eth0 (assuming HZ=1000). Signed-off-by: Gerrit Renker Signed-off-by: David S. Miller --- Documentation/networking/dccp.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/dccp.txt b/Documentation/networking/dccp.txt index cdb6492..271d524 100644 --- a/Documentation/networking/dccp.txt +++ b/Documentation/networking/dccp.txt @@ -174,6 +174,9 @@ Per-route rto_min support > ip route change 10.0.0.0/24 rto_min 250j dev wlan0 > ip route add 10.0.0.254/32 rto_min 800j dev wlan0 > ip route show dev wlan0 + CCID-3 also supports the rto_min setting: it is used to define the lower + bound for the expiry of the nofeedback timer. This can be useful on LANs + with very low RTTs (e.g., loopback, Gbit ethernet). Notes -- cgit v1.1 From e98419c23b1a189c932775f7833e94cb5230a16b Mon Sep 17 00:00:00 2001 From: Nitin Gupta Date: Mon, 9 Aug 2010 22:56:56 +0530 Subject: Staging: zram: Document sysfs entries Signed-off-by: Nitin Gupta Acked-by: Pekka Enberg Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-block-zram | 99 ++++++++++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-block-zram (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-block-zram b/Documentation/ABI/testing/sysfs-block-zram new file mode 100644 index 0000000..c8b3b48 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-block-zram @@ -0,0 +1,99 @@ +What: /sys/block/zram/disksize +Date: August 2010 +Contact: Nitin Gupta +Description: + The disksize file is read-write and specifies the disk size + which represents the limit on the *uncompressed* worth of data + that can be stored in this disk. + +What: /sys/block/zram/initstate +Date: August 2010 +Contact: Nitin Gupta +Description: + The disksize file is read-only and shows the initialization + state of the device. + +What: /sys/block/zram/reset +Date: August 2010 +Contact: Nitin Gupta +Description: + The disksize file is write-only and allows resetting the + device. The reset operation frees all the memory assocaited + with this device. + +What: /sys/block/zram/num_reads +Date: August 2010 +Contact: Nitin Gupta +Description: + The num_reads file is read-only and specifies the number of + reads (failed or successful) done on this device. + +What: /sys/block/zram/num_writes +Date: August 2010 +Contact: Nitin Gupta +Description: + The num_writes file is read-only and specifies the number of + writes (failed or successful) done on this device. + +What: /sys/block/zram/invalid_io +Date: August 2010 +Contact: Nitin Gupta +Description: + The invalid_io file is read-only and specifies the number of + non-page-size-aligned I/O requests issued to this device. + +What: /sys/block/zram/notify_free +Date: August 2010 +Contact: Nitin Gupta +Description: + The notify_free file is read-only and specifies the number of + swap slot free notifications received by this device. These + notifications are send to a swap block device when a swap slot + is freed. This statistic is applicable only when this disk is + being used as a swap disk. + +What: /sys/block/zram/discard +Date: August 2010 +Contact: Nitin Gupta +Description: + The discard file is read-only and specifies the number of + discard requests received by this device. These requests + provide information to block device regarding blocks which are + no longer used by filesystem. + +What: /sys/block/zram/zero_pages +Date: August 2010 +Contact: Nitin Gupta +Description: + The zero_pages file is read-only and specifies number of zero + filled pages written to this disk. No memory is allocated for + such pages. + +What: /sys/block/zram/orig_data_size +Date: August 2010 +Contact: Nitin Gupta +Description: + The orig_data_size file is read-only and specifies uncompressed + size of data stored in this disk. This excludes zero-filled + pages (zero_pages) since no memory is allocated for them. + Unit: bytes + +What: /sys/block/zram/compr_data_size +Date: August 2010 +Contact: Nitin Gupta +Description: + The compr_data_size file is read-only and specifies compressed + size of data stored in this disk. So, compression ratio can be + calculated using orig_data_size and this statistic. + Unit: bytes + +What: /sys/block/zram/mem_used_total +Date: August 2010 +Contact: Nitin Gupta +Description: + The mem_used_total file is read-only and specifies the amount + of memory, including allocator fragmentation and metadata + overhead, allocated for this disk. So, allocator space + efficiency can be calculated using compr_data_size and this + statistic. + Unit: bytes \ No newline at end of file -- cgit v1.1 From cb7cf3da0daa9830e00640da8f7d2380f4b4de42 Mon Sep 17 00:00:00 2001 From: Stefan Achatz Date: Sun, 29 Aug 2010 12:30:18 +0200 Subject: HID: roccat: add driver for Roccat Pyra mouse This patch add support for Pyra mobile gaming mouse from Roccat. It provides access to profiles, settings, actual settings etc. through sysfs attributes. This driver is conceptual similar to the existing Kone driver. Userland tools can soon be found at http://sourceforge.net/projects/roccat Signed-off-by: Stefan Achatz Signed-off-by: Jiri Kosina --- .../ABI/testing/sysfs-driver-hid-roccat-pyra | 98 ++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra new file mode 100644 index 0000000..ad1125b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra @@ -0,0 +1,98 @@ +What: /sys/bus/usb/devices/-:./actual_cpi +Date: August 2010 +Contact: Stefan Achatz +Description: It is possible to switch the cpi setting of the mouse with the + press of a button. + When read, this file returns the raw number of the actual cpi + setting reported by the mouse. This number has to be further + processed to receive the real dpi value. + + VALUE DPI + 1 400 + 2 800 + 4 1600 + + This file is readonly. + +What: /sys/bus/usb/devices/-:./actual_profile +Date: August 2010 +Contact: Stefan Achatz +Description: When read, this file returns the number of the actual profile in + range 0-4. + This file is readonly. + +What: /sys/bus/usb/devices/-:./firmware_version +Date: August 2010 +Contact: Stefan Achatz +Description: When read, this file returns the raw integer version number of the + firmware reported by the mouse. Using the integer value eases + further usage in other programs. To receive the real version + number the decimal point has to be shifted 2 positions to the + left. E.g. a returned value of 138 means 1.38 + This file is readonly. + +What: /sys/bus/usb/devices/-:./profile_settings +Date: August 2010 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_settings holds informations like resolution, sensitivity + and light effects. + When written, this file lets one write the respective profile + settings back to the mouse. The data has to be 13 bytes long. + The mouse will reject invalid data. + Which profile to write is determined by the profile number + contained in the data. + This file is writeonly. + +What: /sys/bus/usb/devices/-:./profile[1-5]_settings +Date: August 2010 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_settings holds informations like resolution, sensitivity + and light effects. + When read, these files return the respective profile settings. + The returned data is 13 bytes in size. + This file is readonly. + +What: /sys/bus/usb/devices/-:./profile_buttons +Date: August 2010 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_buttons holds informations about button layout. + When written, this file lets one write the respective profile + buttons back to the mouse. The data has to be 19 bytes long. + The mouse will reject invalid data. + Which profile to write is determined by the profile number + contained in the data. + This file is writeonly. + +What: /sys/bus/usb/devices/-:./profile[1-5]_buttons +Date: August 2010 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_buttons holds informations about button layout. + When read, these files return the respective profile buttons. + The returned data is 19 bytes in size. + This file is readonly. + +What: /sys/bus/usb/devices/-:./startup_profile +Date: August 2010 +Contact: Stefan Achatz +Description: The integer value of this attribute ranges from 0-4. + When read, this attribute returns the number of the profile + that's active when the mouse is powered on. + This file is readonly. + +What: /sys/bus/usb/devices/-:./settings +Date: August 2010 +Contact: Stefan Achatz +Description: When read, this file returns the settings stored in the mouse. + The size of the data is 3 bytes and holds information on the + startup_profile. + When written, this file lets write settings back to the mouse. + The data has to be 3 bytes long. The mouse will reject invalid + data. -- cgit v1.1 From 606b2f490fb80e55d05cf0e6cec0b6c0ff0fc18f Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Fri, 27 Aug 2010 22:33:38 +0100 Subject: regulator: Update e-mail address for Liam Girdwood Signed-off-by: Mark Brown Signed-off-by: Liam Girdwood --- Documentation/power/regulator/overview.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/power/regulator/overview.txt b/Documentation/power/regulator/overview.txt index 9363e05..8ed1758 100644 --- a/Documentation/power/regulator/overview.txt +++ b/Documentation/power/regulator/overview.txt @@ -13,7 +13,7 @@ regulators (where voltage output is controllable) and current sinks (where current limit is controllable). (C) 2008 Wolfson Microelectronics PLC. -Author: Liam Girdwood +Author: Liam Girdwood Nomenclature -- cgit v1.1 From 048e78a5bc22c27410cb5ca9680c3c7ac400607f Mon Sep 17 00:00:00 2001 From: David Henningsson Date: Thu, 2 Sep 2010 08:35:47 +0200 Subject: ALSA: hda - Add a new hp-laptop model for Conexant 5066, tested on HP G60 This new model adds the following functionality to HP G60: - Automute of internal speakers - Autoswitch of internal/external mics - Remove SPDIF not physically present BugLink: http://launchpad.net/bugs/587388 Cc: stable@kernel.org Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index ce46fa1..37c6aad 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -296,6 +296,7 @@ Conexant 5051 Conexant 5066 ============= laptop Basic Laptop config (default) + hp-laptop HP laptops, e g G60 dell-laptop Dell laptops dell-vostro Dell Vostro olpc-xo-1_5 OLPC XO 1.5 -- cgit v1.1 From ef5dc121d5a0bb1fa477c5395277259f07d318a3 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Thu, 2 Sep 2010 15:48:16 -0700 Subject: mutex: Fix annotations to include it in kernel-locking docbook Fix kernel-doc notation in linux/mutex.h and kernel/mutex.c, then add these 2 files to the kernel-locking docbook as the Mutex API reference chapter. Add one API function to mutex-design.txt and correct a typo in that file. Signed-off-by: Randy Dunlap Cc: Rusty Russell LKML-Reference: <20100902154816.6cc2f9ad.randy.dunlap@oracle.com> Signed-off-by: Ingo Molnar --- Documentation/DocBook/kernel-locking.tmpl | 6 ++++++ Documentation/mutex-design.txt | 3 ++- 2 files changed, 8 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl index 0b1a3f9..a0d479d 100644 --- a/Documentation/DocBook/kernel-locking.tmpl +++ b/Documentation/DocBook/kernel-locking.tmpl @@ -1961,6 +1961,12 @@ machines due to caching. + + Mutex API reference +!Iinclude/linux/mutex.h +!Ekernel/mutex.c + + Further reading diff --git a/Documentation/mutex-design.txt b/Documentation/mutex-design.txt index c91ccc0..38c10fd 100644 --- a/Documentation/mutex-design.txt +++ b/Documentation/mutex-design.txt @@ -9,7 +9,7 @@ firstly, there's nothing wrong with semaphores. But if the simpler mutex semantics are sufficient for your code, then there are a couple of advantages of mutexes: - - 'struct mutex' is smaller on most architectures: .e.g on x86, + - 'struct mutex' is smaller on most architectures: E.g. on x86, 'struct semaphore' is 20 bytes, 'struct mutex' is 16 bytes. A smaller structure size means less RAM footprint, and better CPU-cache utilization. @@ -136,3 +136,4 @@ the APIs of 'struct mutex' have been streamlined: void mutex_lock_nested(struct mutex *lock, unsigned int subclass); int mutex_lock_interruptible_nested(struct mutex *lock, unsigned int subclass); + int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock); -- cgit v1.1 From ae8abfa00efb8ec550f772cbd1e1854977d06212 Mon Sep 17 00:00:00 2001 From: Thomas Graf Date: Fri, 3 Sep 2010 05:47:30 +0000 Subject: ipv6: Update ip-sysctl.txt documentation for recent changes to accept_ra and forwarding Documentation for recent changes to the tunables accept_ra and forwarding. Signed-off-by: Thomas Graf Signed-off-by: David S. Miller --- Documentation/networking/ip-sysctl.txt | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index f350c69..c7165f4 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -1014,6 +1014,12 @@ conf/interface/*: accept_ra - BOOLEAN Accept Router Advertisements; autoconfigure using them. + Possible values are: + 0 Do not accept Router Advertisements. + 1 Accept Router Advertisements if forwarding is disabled. + 2 Overrule forwarding behaviour. Accept Router Advertisements + even if forwarding is enabled. + Functional default: enabled if local forwarding is disabled. disabled if local forwarding is enabled. @@ -1075,7 +1081,12 @@ forwarding - BOOLEAN Note: It is recommended to have the same setting on all interfaces; mixed router/host scenarios are rather uncommon. - FALSE: + Possible values are: + 0 Forwarding disabled + 1 Forwarding enabled + 2 Forwarding enabled (Hybrid Mode) + + FALSE (0): By default, Host behaviour is assumed. This means: @@ -1085,18 +1096,24 @@ forwarding - BOOLEAN Advertisements (and do autoconfiguration). 4. If accept_redirects is TRUE (default), accept Redirects. - TRUE: + TRUE (1): If local forwarding is enabled, Router behaviour is assumed. This means exactly the reverse from the above: 1. IsRouter flag is set in Neighbour Advertisements. 2. Router Solicitations are not sent. - 3. Router Advertisements are ignored. + 3. Router Advertisements are ignored unless accept_ra is 2. 4. Redirects are ignored. - Default: FALSE if global forwarding is disabled (default), - otherwise TRUE. + TRUE (2): + + Hybrid mode. Same behaviour as TRUE, except for: + + 2. Router Solicitations are being sent when necessary. + + Default: 0 (disabled) if global forwarding is disabled (default), + otherwise 1 (enabled). hop_limit - INTEGER Default Hop Limit to set. -- cgit v1.1 From b40d8ed4e42c79f8ed1cf345eed0888f4a2f0678 Mon Sep 17 00:00:00 2001 From: Heiko Carstens Date: Tue, 31 Aug 2010 10:28:17 +0200 Subject: topology/sysfs: Provide book id and siblings attributes Create attributes: /sys/devices/system/cpu/cpuX/topology/book_id /sys/devices/system/cpu/cpuX/topology/book_siblings which show the book id and the book siblings of a cpu. Unlike the attributes for SMT and MC these attributes are only present if CONFIG_SCHED_BOOK is set. There is no reason to pollute sysfs for every architecture with unused attributes. Signed-off-by: Heiko Carstens Signed-off-by: Peter Zijlstra LKML-Reference: <20100831082844.435648457@de.ibm.com> Signed-off-by: Ingo Molnar --- Documentation/cputopology.txt | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cputopology.txt b/Documentation/cputopology.txt index f1c5c4b..902d315 100644 --- a/Documentation/cputopology.txt +++ b/Documentation/cputopology.txt @@ -14,25 +14,39 @@ to /proc/cpuinfo. identifier (rather than the kernel's). The actual value is architecture and platform dependent. -3) /sys/devices/system/cpu/cpuX/topology/thread_siblings: +3) /sys/devices/system/cpu/cpuX/topology/book_id: + + the book ID of cpuX. Typically it is the hardware platform's + identifier (rather than the kernel's). The actual value is + architecture and platform dependent. + +4) /sys/devices/system/cpu/cpuX/topology/thread_siblings: internel kernel map of cpuX's hardware threads within the same core as cpuX -4) /sys/devices/system/cpu/cpuX/topology/core_siblings: +5) /sys/devices/system/cpu/cpuX/topology/core_siblings: internal kernel map of cpuX's hardware threads within the same physical_package_id. +6) /sys/devices/system/cpu/cpuX/topology/book_siblings: + + internal kernel map of cpuX's hardware threads within the same + book_id. + To implement it in an architecture-neutral way, a new source file, -drivers/base/topology.c, is to export the 4 attributes. +drivers/base/topology.c, is to export the 4 or 6 attributes. The two book +related sysfs files will only be created if CONFIG_SCHED_BOOK is selected. For an architecture to support this feature, it must define some of these macros in include/asm-XXX/topology.h: #define topology_physical_package_id(cpu) #define topology_core_id(cpu) +#define topology_book_id(cpu) #define topology_thread_cpumask(cpu) #define topology_core_cpumask(cpu) +#define topology_book_cpumask(cpu) The type of **_id is int. The type of siblings is (const) struct cpumask *. @@ -45,6 +59,9 @@ not defined by include/asm-XXX/topology.h: 3) thread_siblings: just the given CPU 4) core_siblings: just the given CPU +For architectures that don't support books (CONFIG_SCHED_BOOK) there are no +default definitions for topology_book_id() and topology_book_cpumask(). + Additionally, CPU topology information is provided under /sys/devices/system/cpu and includes these files. The internal source for the output is in brackets ("[]"). -- cgit v1.1 From c956126c137d97acb6f4d56fa9572d0bcc84e4ed Mon Sep 17 00:00:00 2001 From: David Brownell Date: Thu, 9 Sep 2010 16:38:03 -0700 Subject: gpio: doc updates There's been some recent confusion about error checking GPIO numbers. briefly, it should be handled mostly during setup, when gpio_request() is called, and NEVER by expectig gpio_is_valid to report more than never-usable GPIO numbers. [akpm@linux-foundation.org: terminate unterminated comment] Signed-off-by: David Brownell Cc: Eric Miao" Cc: "Ryan Mallon" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/gpio.txt | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt index d96a6db..9633da0 100644 --- a/Documentation/gpio.txt +++ b/Documentation/gpio.txt @@ -109,17 +109,19 @@ use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders. If you want to initialize a structure with an invalid GPIO number, use some negative number (perhaps "-EINVAL"); that will never be valid. To -test if a number could reference a GPIO, you may use this predicate: +test if such number from such a structure could reference a GPIO, you +may use this predicate: int gpio_is_valid(int number); A number that's not valid will be rejected by calls which may request or free GPIOs (see below). Other numbers may also be rejected; for -example, a number might be valid but unused on a given board. - -Whether a platform supports multiple GPIO controllers is currently a -platform-specific implementation issue. +example, a number might be valid but temporarily unused on a given board. +Whether a platform supports multiple GPIO controllers is a platform-specific +implementation issue, as are whether that support can leave "holes" in the space +of GPIO numbers, and whether new controllers can be added at runtime. Such issues +can affect things including whether adjacent GPIO numbers are both valid. Using GPIOs ----------- @@ -480,12 +482,16 @@ To support this framework, a platform's Kconfig will "select" either ARCH_REQUIRE_GPIOLIB or ARCH_WANT_OPTIONAL_GPIOLIB and arrange that its includes and defines three functions: gpio_get_value(), gpio_set_value(), and gpio_cansleep(). -They may also want to provide a custom value for ARCH_NR_GPIOS. -ARCH_REQUIRE_GPIOLIB means that the gpio-lib code will always get compiled +It may also provide a custom value for ARCH_NR_GPIOS, so that it better +reflects the number of GPIOs in actual use on that platform, without +wasting static table space. (It should count both built-in/SoC GPIOs and +also ones on GPIO expanders. + +ARCH_REQUIRE_GPIOLIB means that the gpiolib code will always get compiled into the kernel on that architecture. -ARCH_WANT_OPTIONAL_GPIOLIB means the gpio-lib code defaults to off and the user +ARCH_WANT_OPTIONAL_GPIOLIB means the gpiolib code defaults to off and the user can enable it and build it into the kernel optionally. If neither of these options are selected, the platform does not support -- cgit v1.1 From 04ccc65cd1f57aee861708e08cd2272c5a0d088c Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Fri, 3 Sep 2010 11:56:17 +0200 Subject: block: update documentation for REQ_FLUSH / REQ_FUA Signed-off-by: Christoph Hellwig Signed-off-by: Tejun Heo Signed-off-by: Jens Axboe --- Documentation/block/00-INDEX | 4 +- Documentation/block/barrier.txt | 261 ------------------------ Documentation/block/writeback_cache_control.txt | 86 ++++++++ 3 files changed, 88 insertions(+), 263 deletions(-) delete mode 100644 Documentation/block/barrier.txt create mode 100644 Documentation/block/writeback_cache_control.txt (limited to 'Documentation') diff --git a/Documentation/block/00-INDEX b/Documentation/block/00-INDEX index a406286f..d111e3b 100644 --- a/Documentation/block/00-INDEX +++ b/Documentation/block/00-INDEX @@ -1,7 +1,5 @@ 00-INDEX - This file -barrier.txt - - I/O Barriers biodoc.txt - Notes on the Generic Block Layer Rewrite in Linux 2.5 capability.txt @@ -16,3 +14,5 @@ stat.txt - Block layer statistics in /sys/block//stat switching-sched.txt - Switching I/O schedulers at runtime +writeback_cache_control.txt + - Control of volatile write back caches diff --git a/Documentation/block/barrier.txt b/Documentation/block/barrier.txt deleted file mode 100644 index 2c2f24f6..0000000 --- a/Documentation/block/barrier.txt +++ /dev/null @@ -1,261 +0,0 @@ -I/O Barriers -============ -Tejun Heo , July 22 2005 - -I/O barrier requests are used to guarantee ordering around the barrier -requests. Unless you're crazy enough to use disk drives for -implementing synchronization constructs (wow, sounds interesting...), -the ordering is meaningful only for write requests for things like -journal checkpoints. All requests queued before a barrier request -must be finished (made it to the physical medium) before the barrier -request is started, and all requests queued after the barrier request -must be started only after the barrier request is finished (again, -made it to the physical medium). - -In other words, I/O barrier requests have the following two properties. - -1. Request ordering - -Requests cannot pass the barrier request. Preceding requests are -processed before the barrier and following requests after. - -Depending on what features a drive supports, this can be done in one -of the following three ways. - -i. For devices which have queue depth greater than 1 (TCQ devices) and -support ordered tags, block layer can just issue the barrier as an -ordered request and the lower level driver, controller and drive -itself are responsible for making sure that the ordering constraint is -met. Most modern SCSI controllers/drives should support this. - -NOTE: SCSI ordered tag isn't currently used due to limitation in the - SCSI midlayer, see the following random notes section. - -ii. For devices which have queue depth greater than 1 but don't -support ordered tags, block layer ensures that the requests preceding -a barrier request finishes before issuing the barrier request. Also, -it defers requests following the barrier until the barrier request is -finished. Older SCSI controllers/drives and SATA drives fall in this -category. - -iii. Devices which have queue depth of 1. This is a degenerate case -of ii. Just keeping issue order suffices. Ancient SCSI -controllers/drives and IDE drives are in this category. - -2. Forced flushing to physical medium - -Again, if you're not gonna do synchronization with disk drives (dang, -it sounds even more appealing now!), the reason you use I/O barriers -is mainly to protect filesystem integrity when power failure or some -other events abruptly stop the drive from operating and possibly make -the drive lose data in its cache. So, I/O barriers need to guarantee -that requests actually get written to non-volatile medium in order. - -There are four cases, - -i. No write-back cache. Keeping requests ordered is enough. - -ii. Write-back cache but no flush operation. There's no way to -guarantee physical-medium commit order. This kind of devices can't to -I/O barriers. - -iii. Write-back cache and flush operation but no FUA (forced unit -access). We need two cache flushes - before and after the barrier -request. - -iv. Write-back cache, flush operation and FUA. We still need one -flush to make sure requests preceding a barrier are written to medium, -but post-barrier flush can be avoided by using FUA write on the -barrier itself. - - -How to support barrier requests in drivers ------------------------------------------- - -All barrier handling is done inside block layer proper. All low level -drivers have to are implementing its prepare_flush_fn and using one -the following two functions to indicate what barrier type it supports -and how to prepare flush requests. Note that the term 'ordered' is -used to indicate the whole sequence of performing barrier requests -including draining and flushing. - -typedef void (prepare_flush_fn)(struct request_queue *q, struct request *rq); - -int blk_queue_ordered(struct request_queue *q, unsigned ordered, - prepare_flush_fn *prepare_flush_fn); - -@q : the queue in question -@ordered : the ordered mode the driver/device supports -@prepare_flush_fn : this function should prepare @rq such that it - flushes cache to physical medium when executed - -For example, SCSI disk driver's prepare_flush_fn looks like the -following. - -static void sd_prepare_flush(struct request_queue *q, struct request *rq) -{ - memset(rq->cmd, 0, sizeof(rq->cmd)); - rq->cmd_type = REQ_TYPE_BLOCK_PC; - rq->timeout = SD_TIMEOUT; - rq->cmd[0] = SYNCHRONIZE_CACHE; - rq->cmd_len = 10; -} - -The following seven ordered modes are supported. The following table -shows which mode should be used depending on what features a -device/driver supports. In the leftmost column of table, -QUEUE_ORDERED_ prefix is omitted from the mode names to save space. - -The table is followed by description of each mode. Note that in the -descriptions of QUEUE_ORDERED_DRAIN*, '=>' is used whereas '->' is -used for QUEUE_ORDERED_TAG* descriptions. '=>' indicates that the -preceding step must be complete before proceeding to the next step. -'->' indicates that the next step can start as soon as the previous -step is issued. - - write-back cache ordered tag flush FUA ------------------------------------------------------------------------ -NONE yes/no N/A no N/A -DRAIN no no N/A N/A -DRAIN_FLUSH yes no yes no -DRAIN_FUA yes no yes yes -TAG no yes N/A N/A -TAG_FLUSH yes yes yes no -TAG_FUA yes yes yes yes - - -QUEUE_ORDERED_NONE - I/O barriers are not needed and/or supported. - - Sequence: N/A - -QUEUE_ORDERED_DRAIN - Requests are ordered by draining the request queue and cache - flushing isn't needed. - - Sequence: drain => barrier - -QUEUE_ORDERED_DRAIN_FLUSH - Requests are ordered by draining the request queue and both - pre-barrier and post-barrier cache flushings are needed. - - Sequence: drain => preflush => barrier => postflush - -QUEUE_ORDERED_DRAIN_FUA - Requests are ordered by draining the request queue and - pre-barrier cache flushing is needed. By using FUA on barrier - request, post-barrier flushing can be skipped. - - Sequence: drain => preflush => barrier - -QUEUE_ORDERED_TAG - Requests are ordered by ordered tag and cache flushing isn't - needed. - - Sequence: barrier - -QUEUE_ORDERED_TAG_FLUSH - Requests are ordered by ordered tag and both pre-barrier and - post-barrier cache flushings are needed. - - Sequence: preflush -> barrier -> postflush - -QUEUE_ORDERED_TAG_FUA - Requests are ordered by ordered tag and pre-barrier cache - flushing is needed. By using FUA on barrier request, - post-barrier flushing can be skipped. - - Sequence: preflush -> barrier - - -Random notes/caveats --------------------- - -* SCSI layer currently can't use TAG ordering even if the drive, -controller and driver support it. The problem is that SCSI midlayer -request dispatch function is not atomic. It releases queue lock and -switch to SCSI host lock during issue and it's possible and likely to -happen in time that requests change their relative positions. Once -this problem is solved, TAG ordering can be enabled. - -* Currently, no matter which ordered mode is used, there can be only -one barrier request in progress. All I/O barriers are held off by -block layer until the previous I/O barrier is complete. This doesn't -make any difference for DRAIN ordered devices, but, for TAG ordered -devices with very high command latency, passing multiple I/O barriers -to low level *might* be helpful if they are very frequent. Well, this -certainly is a non-issue. I'm writing this just to make clear that no -two I/O barrier is ever passed to low-level driver. - -* Completion order. Requests in ordered sequence are issued in order -but not required to finish in order. Barrier implementation can -handle out-of-order completion of ordered sequence. IOW, the requests -MUST be processed in order but the hardware/software completion paths -are allowed to reorder completion notifications - eg. current SCSI -midlayer doesn't preserve completion order during error handling. - -* Requeueing order. Low-level drivers are free to requeue any request -after they removed it from the request queue with -blkdev_dequeue_request(). As barrier sequence should be kept in order -when requeued, generic elevator code takes care of putting requests in -order around barrier. See blk_ordered_req_seq() and -ELEVATOR_INSERT_REQUEUE handling in __elv_add_request() for details. - -Note that block drivers must not requeue preceding requests while -completing latter requests in an ordered sequence. Currently, no -error checking is done against this. - -* Error handling. Currently, block layer will report error to upper -layer if any of requests in an ordered sequence fails. Unfortunately, -this doesn't seem to be enough. Look at the following request flow. -QUEUE_ORDERED_TAG_FLUSH is in use. - - [0] [1] [2] [3] [pre] [barrier] [post] < [4] [5] [6] ... > - still in elevator - -Let's say request [2], [3] are write requests to update file system -metadata (journal or whatever) and [barrier] is used to mark that -those updates are valid. Consider the following sequence. - - i. Requests [0] ~ [post] leaves the request queue and enters - low-level driver. - ii. After a while, unfortunately, something goes wrong and the - drive fails [2]. Note that any of [0], [1] and [3] could have - completed by this time, but [pre] couldn't have been finished - as the drive must process it in order and it failed before - processing that command. - iii. Error handling kicks in and determines that the error is - unrecoverable and fails [2], and resumes operation. - iv. [pre] [barrier] [post] gets processed. - v. *BOOM* power fails - -The problem here is that the barrier request is *supposed* to indicate -that filesystem update requests [2] and [3] made it safely to the -physical medium and, if the machine crashes after the barrier is -written, filesystem recovery code can depend on that. Sadly, that -isn't true in this case anymore. IOW, the success of a I/O barrier -should also be dependent on success of some of the preceding requests, -where only upper layer (filesystem) knows what 'some' is. - -This can be solved by implementing a way to tell the block layer which -requests affect the success of the following barrier request and -making lower lever drivers to resume operation on error only after -block layer tells it to do so. - -As the probability of this happening is very low and the drive should -be faulty, implementing the fix is probably an overkill. But, still, -it's there. - -* In previous drafts of barrier implementation, there was fallback -mechanism such that, if FUA or ordered TAG fails, less fancy ordered -mode can be selected and the failed barrier request is retried -automatically. The rationale for this feature was that as FUA is -pretty new in ATA world and ordered tag was never used widely, there -could be devices which report to support those features but choke when -actually given such requests. - - This was removed for two reasons 1. it's an overkill 2. it's -impossible to implement properly when TAG ordering is used as low -level drivers resume after an error automatically. If it's ever -needed adding it back and modifying low level drivers accordingly -shouldn't be difficult. diff --git a/Documentation/block/writeback_cache_control.txt b/Documentation/block/writeback_cache_control.txt new file mode 100644 index 0000000..83407d3 --- /dev/null +++ b/Documentation/block/writeback_cache_control.txt @@ -0,0 +1,86 @@ + +Explicit volatile write back cache control +===================================== + +Introduction +------------ + +Many storage devices, especially in the consumer market, come with volatile +write back caches. That means the devices signal I/O completion to the +operating system before data actually has hit the non-volatile storage. This +behavior obviously speeds up various workloads, but it means the operating +system needs to force data out to the non-volatile storage when it performs +a data integrity operation like fsync, sync or an unmount. + +The Linux block layer provides two simple mechanisms that let filesystems +control the caching behavior of the storage device. These mechanisms are +a forced cache flush, and the Force Unit Access (FUA) flag for requests. + + +Explicit cache flushes +---------------------- + +The REQ_FLUSH flag can be OR ed into the r/w flags of a bio submitted from +the filesystem and will make sure the volatile cache of the storage device +has been flushed before the actual I/O operation is started. This explicitly +guarantees that previously completed write requests are on non-volatile +storage before the flagged bio starts. In addition the REQ_FLUSH flag can be +set on an otherwise empty bio structure, which causes only an explicit cache +flush without any dependent I/O. It is recommend to use +the blkdev_issue_flush() helper for a pure cache flush. + + +Forced Unit Access +----------------- + +The REQ_FUA flag can be OR ed into the r/w flags of a bio submitted from the +filesystem and will make sure that I/O completion for this request is only +signaled after the data has been committed to non-volatile storage. + + +Implementation details for filesystems +-------------------------------------- + +Filesystems can simply set the REQ_FLUSH and REQ_FUA bits and do not have to +worry if the underlying devices need any explicit cache flushing and how +the Forced Unit Access is implemented. The REQ_FLUSH and REQ_FUA flags +may both be set on a single bio. + + +Implementation details for make_request_fn based block drivers +-------------------------------------------------------------- + +These drivers will always see the REQ_FLUSH and REQ_FUA bits as they sit +directly below the submit_bio interface. For remapping drivers the REQ_FUA +bits need to be propagated to underlying devices, and a global flush needs +to be implemented for bios with the REQ_FLUSH bit set. For real device +drivers that do not have a volatile cache the REQ_FLUSH and REQ_FUA bits +on non-empty bios can simply be ignored, and REQ_FLUSH requests without +data can be completed successfully without doing any work. Drivers for +devices with volatile caches need to implement the support for these +flags themselves without any help from the block layer. + + +Implementation details for request_fn based block drivers +-------------------------------------------------------------- + +For devices that do not support volatile write caches there is no driver +support required, the block layer completes empty REQ_FLUSH requests before +entering the driver and strips off the REQ_FLUSH and REQ_FUA bits from +requests that have a payload. For devices with volatile write caches the +driver needs to tell the block layer that it supports flushing caches by +doing: + + blk_queue_flush(sdkp->disk->queue, REQ_FLUSH); + +and handle empty REQ_FLUSH requests in its prep_fn/request_fn. Note that +REQ_FLUSH requests with a payload are automatically turned into a sequence +of an empty REQ_FLUSH request followed by the actual write by the block +layer. For devices that also support the FUA bit the block layer needs +to be told to pass through the REQ_FUA bit using: + + blk_queue_flush(sdkp->disk->queue, REQ_FLUSH | REQ_FUA); + +and the driver must handle write requests that have the REQ_FUA bit set +in prep_fn/request_fn. If the FUA bit is not natively supported the block +layer turns it into an empty REQ_FLUSH request after the actual write. -- cgit v1.1 From 7bc9fddab074d6bb630344e1969e28d20b140621 Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Fri, 3 Sep 2010 11:56:18 +0200 Subject: lguest: replace VIRTIO_F_BARRIER support with VIRTIO_F_FLUSH support VIRTIO_F_BARRIER is deprecated. Replace it with VIRTIO_F_FLUSH support. Signed-off-by: Tejun Heo Cc: Rusty Russell Cc: Christoph Hellwig Signed-off-by: Jens Axboe --- Documentation/lguest/lguest.c | 29 +++++++++-------------------- 1 file changed, 9 insertions(+), 20 deletions(-) (limited to 'Documentation') diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c index e9ce3c5..fbc64b3 100644 --- a/Documentation/lguest/lguest.c +++ b/Documentation/lguest/lguest.c @@ -1639,15 +1639,6 @@ static void blk_request(struct virtqueue *vq) off = out->sector * 512; /* - * The block device implements "barriers", where the Guest indicates - * that it wants all previous writes to occur before this write. We - * don't have a way of asking our kernel to do a barrier, so we just - * synchronize all the data in the file. Pretty poor, no? - */ - if (out->type & VIRTIO_BLK_T_BARRIER) - fdatasync(vblk->fd); - - /* * In general the virtio block driver is allowed to try SCSI commands. * It'd be nice if we supported eject, for example, but we don't. */ @@ -1679,6 +1670,13 @@ static void blk_request(struct virtqueue *vq) /* Die, bad Guest, die. */ errx(1, "Write past end %llu+%u", off, ret); } + + wlen = sizeof(*in); + *in = (ret >= 0 ? VIRTIO_BLK_S_OK : VIRTIO_BLK_S_IOERR); + } else if (out->type & VIRTIO_BLK_T_FLUSH) { + /* Flush */ + ret = fdatasync(vblk->fd); + verbose("FLUSH fdatasync: %i\n", ret); wlen = sizeof(*in); *in = (ret >= 0 ? VIRTIO_BLK_S_OK : VIRTIO_BLK_S_IOERR); } else { @@ -1702,15 +1700,6 @@ static void blk_request(struct virtqueue *vq) } } - /* - * OK, so we noted that it was pretty poor to use an fdatasync as a - * barrier. But Christoph Hellwig points out that we need a sync - * *afterwards* as well: "Barriers specify no reordering to the front - * or the back." And Jens Axboe confirmed it, so here we are: - */ - if (out->type & VIRTIO_BLK_T_BARRIER) - fdatasync(vblk->fd); - /* Finished that request. */ add_used(vq, head, wlen); } @@ -1735,8 +1724,8 @@ static void setup_block_file(const char *filename) vblk->fd = open_or_die(filename, O_RDWR|O_LARGEFILE); vblk->len = lseek64(vblk->fd, 0, SEEK_END); - /* We support barriers. */ - add_feature(dev, VIRTIO_BLK_F_BARRIER); + /* We support FLUSH. */ + add_feature(dev, VIRTIO_BLK_F_FLUSH); /* Tell Guest how many sectors this device has. */ conf.capacity = cpu_to_le64(vblk->len / 512); -- cgit v1.1 From eda603f6cdba4b14dbf80531fab2fe545232e7a0 Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Sat, 11 Sep 2010 15:55:22 -0700 Subject: docbook: warn on unused doc entries When you don't use !E or !I but only !F, then it's very easy to miss including some functions, structs etc. in documentation. To help finding which ones were missed, allow printing out the unused ones as warnings. For example, using this on mac80211 yields a lot of warnings like this: Warning: didn't use docs for DOC: mac80211 workqueue Warning: didn't use docs for ieee80211_max_queues Warning: didn't use docs for ieee80211_bss_change Warning: didn't use docs for ieee80211_bss_conf when generating the documentation for it. Signed-off-by: Johannes Berg Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/kernel-doc-nano-HOWTO.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-doc-nano-HOWTO.txt b/Documentation/kernel-doc-nano-HOWTO.txt index 27a52b3..3d8a977 100644 --- a/Documentation/kernel-doc-nano-HOWTO.txt +++ b/Documentation/kernel-doc-nano-HOWTO.txt @@ -345,5 +345,10 @@ documentation, in , for the functions listed. section titled
from . Spaces are allowed in
; do not quote the
. +!C is replaced by nothing, but makes the tools check that +all DOC: sections and documented functions, symbols, etc. are used. +This makes sense to use when you use !F/!P only and want to verify +that all documentation is included. + Tim. */ -- cgit v1.1 From 39d709392ffc1d05f825191b07b7d865d434f282 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Sat, 11 Sep 2010 15:55:26 -0700 Subject: docbook: skip files with no docs since they generate scary warnings Fix docbook templates that reference files that do not contain the expected kernel-doc notation. Fixes these warnings: Warning(arch/x86/include/asm/unaligned.h): no structured comments found Warning(lib/vsprintf.c): no structured comments found These cause errors in the generated html output, like below, so drop these lines. Name arch/x86/include/asm/unaligned.h - Document generation inconsistency Oops Warning The template for this document tried to insert the structured comment from the file arch/x86/include/asm/unaligned.h at this point, but none was found. This dummy section is inserted to allow generation to continue. Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/DocBook/device-drivers.tmpl | 1 - Documentation/DocBook/kernel-api.tmpl | 1 - 2 files changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index ecd35e9..feca075 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -46,7 +46,6 @@ Atomic and pointer manipulation !Iarch/x86/include/asm/atomic.h -!Iarch/x86/include/asm/unaligned.h Delaying, scheduling, and timer routines diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index a20c6f6..6899f47 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -57,7 +57,6 @@ String Conversions -!Ilib/vsprintf.c !Elib/vsprintf.c String Manipulation -- cgit v1.1 From c54fce6eff197d9c57c97afbf6c9722ce434fc8f Mon Sep 17 00:00:00 2001 From: Tejun Heo Date: Fri, 10 Sep 2010 16:51:36 +0200 Subject: workqueue: add documentation Update copyright notice and add Documentation/workqueue.txt. Randy Dunlap, Dave Chinner: misc fixes. Signed-off-by: Tejun Heo Reviewed-By: Florian Mickler Cc: Ingo Molnar Cc: Christoph Lameter Cc: Randy Dunlap Cc: Dave Chinner --- Documentation/workqueue.txt | 380 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 380 insertions(+) create mode 100644 Documentation/workqueue.txt (limited to 'Documentation') diff --git a/Documentation/workqueue.txt b/Documentation/workqueue.txt new file mode 100644 index 0000000..e4498a2 --- /dev/null +++ b/Documentation/workqueue.txt @@ -0,0 +1,380 @@ + +Concurrency Managed Workqueue (cmwq) + +September, 2010 Tejun Heo + Florian Mickler + +CONTENTS + +1. Introduction +2. Why cmwq? +3. The Design +4. Application Programming Interface (API) +5. Example Execution Scenarios +6. Guidelines + + +1. Introduction + +There are many cases where an asynchronous process execution context +is needed and the workqueue (wq) API is the most commonly used +mechanism for such cases. + +When such an asynchronous execution context is needed, a work item +describing which function to execute is put on a queue. An +independent thread serves as the asynchronous execution context. The +queue is called workqueue and the thread is called worker. + +While there are work items on the workqueue the worker executes the +functions associated with the work items one after the other. When +there is no work item left on the workqueue the worker becomes idle. +When a new work item gets queued, the worker begins executing again. + + +2. Why cmwq? + +In the original wq implementation, a multi threaded (MT) wq had one +worker thread per CPU and a single threaded (ST) wq had one worker +thread system-wide. A single MT wq needed to keep around the same +number of workers as the number of CPUs. The kernel grew a lot of MT +wq users over the years and with the number of CPU cores continuously +rising, some systems saturated the default 32k PID space just booting +up. + +Although MT wq wasted a lot of resource, the level of concurrency +provided was unsatisfactory. The limitation was common to both ST and +MT wq albeit less severe on MT. Each wq maintained its own separate +worker pool. A MT wq could provide only one execution context per CPU +while a ST wq one for the whole system. Work items had to compete for +those very limited execution contexts leading to various problems +including proneness to deadlocks around the single execution context. + +The tension between the provided level of concurrency and resource +usage also forced its users to make unnecessary tradeoffs like libata +choosing to use ST wq for polling PIOs and accepting an unnecessary +limitation that no two polling PIOs can progress at the same time. As +MT wq don't provide much better concurrency, users which require +higher level of concurrency, like async or fscache, had to implement +their own thread pool. + +Concurrency Managed Workqueue (cmwq) is a reimplementation of wq with +focus on the following goals. + +* Maintain compatibility with the original workqueue API. + +* Use per-CPU unified worker pools shared by all wq to provide + flexible level of concurrency on demand without wasting a lot of + resource. + +* Automatically regulate worker pool and level of concurrency so that + the API users don't need to worry about such details. + + +3. The Design + +In order to ease the asynchronous execution of functions a new +abstraction, the work item, is introduced. + +A work item is a simple struct that holds a pointer to the function +that is to be executed asynchronously. Whenever a driver or subsystem +wants a function to be executed asynchronously it has to set up a work +item pointing to that function and queue that work item on a +workqueue. + +Special purpose threads, called worker threads, execute the functions +off of the queue, one after the other. If no work is queued, the +worker threads become idle. These worker threads are managed in so +called thread-pools. + +The cmwq design differentiates between the user-facing workqueues that +subsystems and drivers queue work items on and the backend mechanism +which manages thread-pool and processes the queued work items. + +The backend is called gcwq. There is one gcwq for each possible CPU +and one gcwq to serve work items queued on unbound workqueues. + +Subsystems and drivers can create and queue work items through special +workqueue API functions as they see fit. They can influence some +aspects of the way the work items are executed by setting flags on the +workqueue they are putting the work item on. These flags include +things like CPU locality, reentrancy, concurrency limits and more. To +get a detailed overview refer to the API description of +alloc_workqueue() below. + +When a work item is queued to a workqueue, the target gcwq is +determined according to the queue parameters and workqueue attributes +and appended on the shared worklist of the gcwq. For example, unless +specifically overridden, a work item of a bound workqueue will be +queued on the worklist of exactly that gcwq that is associated to the +CPU the issuer is running on. + +For any worker pool implementation, managing the concurrency level +(how many execution contexts are active) is an important issue. cmwq +tries to keep the concurrency at a minimal but sufficient level. +Minimal to save resources and sufficient in that the system is used at +its full capacity. + +Each gcwq bound to an actual CPU implements concurrency management by +hooking into the scheduler. The gcwq is notified whenever an active +worker wakes up or sleeps and keeps track of the number of the +currently runnable workers. Generally, work items are not expected to +hog a CPU and consume many cycles. That means maintaining just enough +concurrency to prevent work processing from stalling should be +optimal. As long as there are one or more runnable workers on the +CPU, the gcwq doesn't start execution of a new work, but, when the +last running worker goes to sleep, it immediately schedules a new +worker so that the CPU doesn't sit idle while there are pending work +items. This allows using a minimal number of workers without losing +execution bandwidth. + +Keeping idle workers around doesn't cost other than the memory space +for kthreads, so cmwq holds onto idle ones for a while before killing +them. + +For an unbound wq, the above concurrency management doesn't apply and +the gcwq for the pseudo unbound CPU tries to start executing all work +items as soon as possible. The responsibility of regulating +concurrency level is on the users. There is also a flag to mark a +bound wq to ignore the concurrency management. Please refer to the +API section for details. + +Forward progress guarantee relies on that workers can be created when +more execution contexts are necessary, which in turn is guaranteed +through the use of rescue workers. All work items which might be used +on code paths that handle memory reclaim are required to be queued on +wq's that have a rescue-worker reserved for execution under memory +pressure. Else it is possible that the thread-pool deadlocks waiting +for execution contexts to free up. + + +4. Application Programming Interface (API) + +alloc_workqueue() allocates a wq. The original create_*workqueue() +functions are deprecated and scheduled for removal. alloc_workqueue() +takes three arguments - @name, @flags and @max_active. @name is the +name of the wq and also used as the name of the rescuer thread if +there is one. + +A wq no longer manages execution resources but serves as a domain for +forward progress guarantee, flush and work item attributes. @flags +and @max_active control how work items are assigned execution +resources, scheduled and executed. + +@flags: + + WQ_NON_REENTRANT + + By default, a wq guarantees non-reentrance only on the same + CPU. A work item may not be executed concurrently on the same + CPU by multiple workers but is allowed to be executed + concurrently on multiple CPUs. This flag makes sure + non-reentrance is enforced across all CPUs. Work items queued + to a non-reentrant wq are guaranteed to be executed by at most + one worker system-wide at any given time. + + WQ_UNBOUND + + Work items queued to an unbound wq are served by a special + gcwq which hosts workers which are not bound to any specific + CPU. This makes the wq behave as a simple execution context + provider without concurrency management. The unbound gcwq + tries to start execution of work items as soon as possible. + Unbound wq sacrifices locality but is useful for the following + cases. + + * Wide fluctuation in the concurrency level requirement is + expected and using bound wq may end up creating large number + of mostly unused workers across different CPUs as the issuer + hops through different CPUs. + + * Long running CPU intensive workloads which can be better + managed by the system scheduler. + + WQ_FREEZEABLE + + A freezeable wq participates in the freeze phase of the system + suspend operations. Work items on the wq are drained and no + new work item starts execution until thawed. + + WQ_RESCUER + + All wq which might be used in the memory reclaim paths _MUST_ + have this flag set. This reserves one worker exclusively for + the execution of this wq under memory pressure. + + WQ_HIGHPRI + + Work items of a highpri wq are queued at the head of the + worklist of the target gcwq and start execution regardless of + the current concurrency level. In other words, highpri work + items will always start execution as soon as execution + resource is available. + + Ordering among highpri work items is preserved - a highpri + work item queued after another highpri work item will start + execution after the earlier highpri work item starts. + + Although highpri work items are not held back by other + runnable work items, they still contribute to the concurrency + level. Highpri work items in runnable state will prevent + non-highpri work items from starting execution. + + This flag is meaningless for unbound wq. + + WQ_CPU_INTENSIVE + + Work items of a CPU intensive wq do not contribute to the + concurrency level. In other words, runnable CPU intensive + work items will not prevent other work items from starting + execution. This is useful for bound work items which are + expected to hog CPU cycles so that their execution is + regulated by the system scheduler. + + Although CPU intensive work items don't contribute to the + concurrency level, start of their executions is still + regulated by the concurrency management and runnable + non-CPU-intensive work items can delay execution of CPU + intensive work items. + + This flag is meaningless for unbound wq. + + WQ_HIGHPRI | WQ_CPU_INTENSIVE + + This combination makes the wq avoid interaction with + concurrency management completely and behave as a simple + per-CPU execution context provider. Work items queued on a + highpri CPU-intensive wq start execution as soon as resources + are available and don't affect execution of other work items. + +@max_active: + +@max_active determines the maximum number of execution contexts per +CPU which can be assigned to the work items of a wq. For example, +with @max_active of 16, at most 16 work items of the wq can be +executing at the same time per CPU. + +Currently, for a bound wq, the maximum limit for @max_active is 512 +and the default value used when 0 is specified is 256. For an unbound +wq, the limit is higher of 512 and 4 * num_possible_cpus(). These +values are chosen sufficiently high such that they are not the +limiting factor while providing protection in runaway cases. + +The number of active work items of a wq is usually regulated by the +users of the wq, more specifically, by how many work items the users +may queue at the same time. Unless there is a specific need for +throttling the number of active work items, specifying '0' is +recommended. + +Some users depend on the strict execution ordering of ST wq. The +combination of @max_active of 1 and WQ_UNBOUND is used to achieve this +behavior. Work items on such wq are always queued to the unbound gcwq +and only one work item can be active at any given time thus achieving +the same ordering property as ST wq. + + +5. Example Execution Scenarios + +The following example execution scenarios try to illustrate how cmwq +behave under different configurations. + + Work items w0, w1, w2 are queued to a bound wq q0 on the same CPU. + w0 burns CPU for 5ms then sleeps for 10ms then burns CPU for 5ms + again before finishing. w1 and w2 burn CPU for 5ms then sleep for + 10ms. + +Ignoring all other tasks, works and processing overhead, and assuming +simple FIFO scheduling, the following is one highly simplified version +of possible sequences of events with the original wq. + + TIME IN MSECS EVENT + 0 w0 starts and burns CPU + 5 w0 sleeps + 15 w0 wakes up and burns CPU + 20 w0 finishes + 20 w1 starts and burns CPU + 25 w1 sleeps + 35 w1 wakes up and finishes + 35 w2 starts and burns CPU + 40 w2 sleeps + 50 w2 wakes up and finishes + +And with cmwq with @max_active >= 3, + + TIME IN MSECS EVENT + 0 w0 starts and burns CPU + 5 w0 sleeps + 5 w1 starts and burns CPU + 10 w1 sleeps + 10 w2 starts and burns CPU + 15 w2 sleeps + 15 w0 wakes up and burns CPU + 20 w0 finishes + 20 w1 wakes up and finishes + 25 w2 wakes up and finishes + +If @max_active == 2, + + TIME IN MSECS EVENT + 0 w0 starts and burns CPU + 5 w0 sleeps + 5 w1 starts and burns CPU + 10 w1 sleeps + 15 w0 wakes up and burns CPU + 20 w0 finishes + 20 w1 wakes up and finishes + 20 w2 starts and burns CPU + 25 w2 sleeps + 35 w2 wakes up and finishes + +Now, let's assume w1 and w2 are queued to a different wq q1 which has +WQ_HIGHPRI set, + + TIME IN MSECS EVENT + 0 w1 and w2 start and burn CPU + 5 w1 sleeps + 10 w2 sleeps + 10 w0 starts and burns CPU + 15 w0 sleeps + 15 w1 wakes up and finishes + 20 w2 wakes up and finishes + 25 w0 wakes up and burns CPU + 30 w0 finishes + +If q1 has WQ_CPU_INTENSIVE set, + + TIME IN MSECS EVENT + 0 w0 starts and burns CPU + 5 w0 sleeps + 5 w1 and w2 start and burn CPU + 10 w1 sleeps + 15 w2 sleeps + 15 w0 wakes up and burns CPU + 20 w0 finishes + 20 w1 wakes up and finishes + 25 w2 wakes up and finishes + + +6. Guidelines + +* Do not forget to use WQ_RESCUER if a wq may process work items which + are used during memory reclaim. Each wq with WQ_RESCUER set has one + rescuer thread reserved for it. If there is dependency among + multiple work items used during memory reclaim, they should be + queued to separate wq each with WQ_RESCUER. + +* Unless strict ordering is required, there is no need to use ST wq. + +* Unless there is a specific need, using 0 for @max_active is + recommended. In most use cases, concurrency level usually stays + well under the default limit. + +* A wq serves as a domain for forward progress guarantee (WQ_RESCUER), + flush and work item attributes. Work items which are not involved + in memory reclaim and don't need to be flushed as a part of a group + of work items, and don't require any special attribute, can use one + of the system wq. There is no difference in execution + characteristics between using a dedicated wq and a system wq. + +* Unless work items are expected to consume a huge amount of CPU + cycles, using a bound wq is usually beneficial due to the increased + level of locality in wq operations and work item execution. -- cgit v1.1 From 274a517ec13b3b47047b97a2e7c912138c9806e0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?R=C3=A9mi=20Denis-Courmont?= Date: Wed, 15 Sep 2010 12:30:15 +0000 Subject: Phonet: resource routing documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Rémi Denis-Courmont Signed-off-by: David S. Miller --- Documentation/networking/phonet.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/phonet.txt b/Documentation/networking/phonet.txt index 6e8ce09..cf76608 100644 --- a/Documentation/networking/phonet.txt +++ b/Documentation/networking/phonet.txt @@ -112,6 +112,22 @@ However, connect() and getpeername() are not supported, as they did not seem useful with Phonet usages (could be added easily). +Resource subscription +--------------------- + +A Phonet datagram socket can be subscribed to any number of 8-bits +Phonet resources, as follow: + + uint32_t res = 0xXX; + ioctl(fd, SIOCPNADDRESOURCE, &res); + +Subscription is similarly cancelled using the SIOCPNDELRESOURCE I/O +control request, or when the socket is closed. + +Note that no more than one socket can be subcribed to any given +resource at a time. If not, ioctl() will return EBUSY. + + Phonet Pipe protocol -------------------- -- cgit v1.1 From 2786c4e5e54802c34297e55050fef3e862a27b3f Mon Sep 17 00:00:00 2001 From: Vivek Goyal Date: Wed, 15 Sep 2010 17:06:38 -0400 Subject: blkio: Documentation Update o Documentation update Signed-off-by: Vivek Goyal Signed-off-by: Jens Axboe --- Documentation/cgroups/blkio-controller.txt | 106 ++++++++++++++++++++++++++++- 1 file changed, 103 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroups/blkio-controller.txt index 48e0b21..2f5613f 100644 --- a/Documentation/cgroups/blkio-controller.txt +++ b/Documentation/cgroups/blkio-controller.txt @@ -8,12 +8,17 @@ both at leaf nodes as well as at intermediate nodes in a storage hierarchy. Plan is to use the same cgroup based management interface for blkio controller and based on user options switch IO policies in the background. -In the first phase, this patchset implements proportional weight time based -division of disk policy. It is implemented in CFQ. Hence this policy takes -effect only on leaf nodes when CFQ is being used. +Currently two IO control policies are implemented. First one is proportional +weight time based division of disk policy. It is implemented in CFQ. Hence +this policy takes effect only on leaf nodes when CFQ is being used. The second +one is throttling policy which can be used to specify upper IO rate limits +on devices. This policy is implemented in generic block layer and can be +used on leaf nodes as well as higher level logical devices like device mapper. HOWTO ===== +Proportional Weight division of bandwidth +----------------------------------------- You can do a very simple testing of running two dd threads in two different cgroups. Here is what you can do. @@ -55,6 +60,35 @@ cgroups. Here is what you can do. group dispatched to the disk. We provide fairness in terms of disk time, so ideally io.disk_time of cgroups should be in proportion to the weight. +Throttling/Upper Limit policy +----------------------------- +- Enable Block IO controller + CONFIG_BLK_CGROUP=y + +- Enable throttling in block layer + CONFIG_BLK_DEV_THROTTLING=y + +- Mount blkio controller + mount -t cgroup -o blkio none /cgroup/blkio + +- Specify a bandwidth rate on particular device for root group. The format + for policy is ": ". + + echo "8:16 1048576" > /cgroup/blkio/blkio.read_bps_device + + Above will put a limit of 1MB/second on reads happening for root group + on device having major/minor number 8:16. + +- Run dd to read a file and see if rate is throttled to 1MB/s or not. + + # dd if=/mnt/common/zerofile of=/dev/null bs=4K count=1024 + # iflag=direct + 1024+0 records in + 1024+0 records out + 4194304 bytes (4.2 MB) copied, 4.0001 s, 1.0 MB/s + + Limits for writes can be put using blkio.write_bps_device file. + Various user visible config options =================================== CONFIG_BLK_CGROUP @@ -68,8 +102,13 @@ CONFIG_CFQ_GROUP_IOSCHED - Enables group scheduling in CFQ. Currently only 1 level of group creation is allowed. +CONFIG_BLK_DEV_THROTTLING + - Enable block device throttling support in block layer. + Details of cgroup files ======================= +Proportional weight policy files +-------------------------------- - blkio.weight - Specifies per cgroup weight. This is default weight of the group on all the devices until and unless overridden by per device rule. @@ -210,6 +249,67 @@ Details of cgroup files and minor number of the device and third field specifies the number of times a group was dequeued from a particular device. +Throttling/Upper limit policy files +----------------------------------- +- blkio.throttle.read_bps_device + - Specifies upper limit on READ rate from the device. IO rate is + specified in bytes per second. Rules are per deivce. Following is + the format. + + echo ": " > /cgrp/blkio.read_bps_device + +- blkio.throttle.write_bps_device + - Specifies upper limit on WRITE rate to the device. IO rate is + specified in bytes per second. Rules are per deivce. Following is + the format. + + echo ": " > /cgrp/blkio.write_bps_device + +- blkio.throttle.read_iops_device + - Specifies upper limit on READ rate from the device. IO rate is + specified in IO per second. Rules are per deivce. Following is + the format. + + echo ": " > /cgrp/blkio.read_iops_device + +- blkio.throttle.write_iops_device + - Specifies upper limit on WRITE rate to the device. IO rate is + specified in io per second. Rules are per deivce. Following is + the format. + + echo ": " > /cgrp/blkio.write_iops_device + +Note: If both BW and IOPS rules are specified for a device, then IO is + subjectd to both the constraints. + +- blkio.throttle.io_serviced + - Number of IOs (bio) completed to/from the disk by the group (as + seen by throttling policy). These are further divided by the type + of operation - read or write, sync or async. First two fields specify + the major and minor number of the device, third field specifies the + operation type and the fourth field specifies the number of IOs. + + blkio.io_serviced does accounting as seen by CFQ and counts are in + number of requests (struct request). On the other hand, + blkio.throttle.io_serviced counts number of IO in terms of number + of bios as seen by throttling policy. These bios can later be + merged by elevator and total number of requests completed can be + lesser. + +- blkio.throttle.io_service_bytes + - Number of bytes transferred to/from the disk by the group. These + are further divided by the type of operation - read or write, sync + or async. First two fields specify the major and minor number of the + device, third field specifies the operation type and the fourth field + specifies the number of bytes. + + These numbers should roughly be same as blkio.io_service_bytes as + updated by CFQ. The difference between two is that + blkio.io_service_bytes will not be updated if CFQ is not operating + on request queue. + +Common files among various policies +----------------------------------- - blkio.reset_stats - Writing an int to this file will result in resetting all the stats for that cgroup. -- cgit v1.1 From dc880abef75e7c62c9048171f5112500f36a9244 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Tue, 6 Jul 2010 18:54:47 +0200 Subject: drm: use noop_llseek The drm device drivers currently allow seeking on the character device but never care about the actual file position. When we change the default llseek operation to be no_llseek, calling llseek on a drm device would return an error condition, which is an API change. Explicitly setting noop_llseek lets us keep the current API. Signed-off-by: Arnd Bergmann Cc: David Airlie Cc: dri-devel@lists.freedesktop.org --- Documentation/DocBook/drm.tmpl | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 910c923..2861055 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -136,6 +136,7 @@ #ifdef CONFIG_COMPAT .compat_ioctl = i915_compat_ioctl, #endif + .llseek = noop_llseek, }, .pci_driver = { .name = DRIVER_NAME, -- cgit v1.1 From 306a075362a288683f6346185f97dd0e06df19da Mon Sep 17 00:00:00 2001 From: Chuck Lever Date: Fri, 17 Sep 2010 10:54:37 -0400 Subject: NFS: Allow NFSROOT debugging messages to be enabled dynamically As a convenience, introduce a kernel command line option to enable NFSROOT debugging messages. Signed-off-by: Chuck Lever Signed-off-by: Trond Myklebust --- Documentation/filesystems/nfs/nfsroot.txt | 22 ++++++++++++++++++++++ Documentation/kernel-parameters.txt | 5 ++++- 2 files changed, 26 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/nfs/nfsroot.txt b/Documentation/filesystems/nfs/nfsroot.txt index f2430a7..90c71c6 100644 --- a/Documentation/filesystems/nfs/nfsroot.txt +++ b/Documentation/filesystems/nfs/nfsroot.txt @@ -159,6 +159,28 @@ ip=:::::: Default: any +nfsrootdebug + + This parameter enables debugging messages to appear in the kernel + log at boot time so that administrators can verify that the correct + NFS mount options, server address, and root path are passed to the + NFS client. + + +rdinit= + + To specify which file contains the program that starts system + initialization, administrators can use this command line parameter. + The default value of this parameter is "/init". If the specified + file exists and the kernel can execute it, root filesystem related + kernel command line parameters, including `nfsroot=', are ignored. + + A description of the process of mounting the root file system can be + found in: + + Documentation/early-userspace/README + + 3.) Boot Loader diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index f084af0..0fe70b2 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1532,12 +1532,15 @@ and is between 256 and 4096 characters. It is defined in the file 1 to enable accounting Default value is 0. - nfsaddrs= [NFS] + nfsaddrs= [NFS] Deprecated. Use ip= instead. See Documentation/filesystems/nfs/nfsroot.txt. nfsroot= [NFS] nfs root filesystem for disk-less boxes. See Documentation/filesystems/nfs/nfsroot.txt. + nfsrootdebug [NFS] enable nfsroot debugging messages. + See Documentation/filesystems/nfs/nfsroot.txt. + nfs.callback_tcpport= [NFS] set the TCP port on which the NFSv4 callback channel should listen. -- cgit v1.1 From a51b9944a1aaca34c9061d3973663fee54e9d1c1 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Fri, 17 Sep 2010 17:24:14 +0200 Subject: hwmon: (adm1031) Replace update_rate sysfs attribute with update_interval The attribute reflects an interval, not a rate. Signed-off-by: Guenter Roeck Acked-by: Ira W. Snyder Signed-off-by: Jean Delvare --- Documentation/hwmon/sysfs-interface | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index ff45d1f..48ceabe 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -91,12 +91,11 @@ name The chip name. I2C devices get this attribute created automatically. RO -update_rate The rate at which the chip will update readings. +update_interval The interval at which the chip will update readings. Unit: millisecond RW - Some devices have a variable update rate. This attribute - can be used to change the update rate to the desired - frequency. + Some devices have a variable update rate or interval. + This attribute can be used to change it to the desired value. ************ -- cgit v1.1 From 8ea13e2c87c83b7cb0b360cb8779415967727647 Mon Sep 17 00:00:00 2001 From: Arnaud Lacombe Date: Mon, 16 Aug 2010 22:55:31 -0400 Subject: kconfig: implement the `mainmenu' directive If specified, the directive must be placed at the top of the Kconfig file. We need to change the grammar to make the mainmenu directive set the `rootmenu' prompt. This reflect how menu_add_prompt() works internally, ie. set the prompt of the `current_entry', pointing originally to `rootmenu'. Signed-off-by: Arnaud Lacombe Reviewed-by: Sam Ravnborg Reviewed-by: Michal Marek --- Documentation/kbuild/kconfig-language.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt index b472e4e..2fe93ca 100644 --- a/Documentation/kbuild/kconfig-language.txt +++ b/Documentation/kbuild/kconfig-language.txt @@ -322,7 +322,8 @@ mainmenu: "mainmenu" This sets the config program's title bar if the config program chooses -to use it. +to use it. It should be placed at the top of the configuration, before any +other statement. Kconfig hints -- cgit v1.1 From 0bc79f7f58f5d0670c776818e38f482555bc27ae Mon Sep 17 00:00:00 2001 From: Nikanth Karthikesan Date: Mon, 20 Sep 2010 11:43:58 +0530 Subject: Doc: Fix typo s/packages/packaged Fix typo s/packages/packaged in Documentation/vm/numa_memory_policy.txt. Signed-off-by: Nikanth Karthikesan Signed-off-by: Jiri Kosina --- Documentation/vm/numa_memory_policy.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/vm/numa_memory_policy.txt b/Documentation/vm/numa_memory_policy.txt index 6690fc3..4e7da65 100644 --- a/Documentation/vm/numa_memory_policy.txt +++ b/Documentation/vm/numa_memory_policy.txt @@ -424,7 +424,7 @@ a command line tool, numactl(8), exists that allows one to: + set the shared policy for a shared memory segment via mbind(2) -The numactl(8) tool is packages with the run-time version of the library +The numactl(8) tool is packaged with the run-time version of the library containing the memory policy system call wrappers. Some distributions package the headers and compile-time libraries in a separate development package. -- cgit v1.1 From c67874f942e30039442d925b03793e0a46ddcddd Mon Sep 17 00:00:00 2001 From: NeilBrown Date: Wed, 22 Sep 2010 12:55:07 +1000 Subject: nfsd: formally deprecate legacy nfsd syscall interface The syscall interface is has been replaced by a more flexible interface since 2.6.0. It is time to work towards discarding the old interface. So add a entry in feature-removal-schedule.txt and print a warning when the interface is used. Signed-off-by: NeilBrown Signed-off-by: J. Bruce Fields --- Documentation/feature-removal-schedule.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 842aa9d..076a2c0 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -564,3 +564,13 @@ Who: FUJITA Tomonori ---------------------------- +What: access to nfsd auth cache through sys_nfsservctl or '.' files + in the 'nfsd' filesystem. +When: 2.6.40 +Why: This is a legacy interface which have been replaced by a more + dynamic cache. Continuing to maintain this interface is an + unnecessary burden. +Who: NeilBrown + +---------------------------- + -- cgit v1.1 From 269dcc1c2ec25864308ee03a3fa26ea819d9f5d0 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Tue, 7 Sep 2010 14:23:09 -0700 Subject: rcu: Add tracing data to support queueing models The current tracing data is not sufficient to deduce the average time that a callback spends waiting for a grace period to end. Add three per-CPU counters recording the number of callbacks invoked (ci), the number of callbacks orphaned (co), and the number of callbacks adopted (ca). Given the existing callback queue length (ql), the average wait time in absence of CPU hotplug operations is ql/ci. The units of wait time will be in terms of the duration over which ci was measured. In the presence of CPU hotplug operations, there is room for argument, but ql/(ci-co+ca) won't steer you too far wrong. Also fixes a typo called out by Lucas De Marchi . Signed-off-by: Paul E. McKenney --- Documentation/RCU/trace.txt | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/RCU/trace.txt b/Documentation/RCU/trace.txt index efd8cc9..a851118 100644 --- a/Documentation/RCU/trace.txt +++ b/Documentation/RCU/trace.txt @@ -125,6 +125,17 @@ o "b" is the batch limit for this CPU. If more than this number of RCU callbacks is ready to invoke, then the remainder will be deferred. +o "ci" is the number of RCU callbacks that have been invoked for + this CPU. Note that ci+ql is the number of callbacks that have + been registered in absence of CPU-hotplug activity. + +o "co" is the number of RCU callbacks that have been orphaned due to + this CPU going offline. + +o "ca" is the number of RCU callbacks that have been adopted due to + other CPUs going offline. Note that ci+co-ca+ql is the number of + RCU callbacks registered on this CPU. + There is also an rcu/rcudata.csv file with the same information in comma-separated-variable spreadsheet format. @@ -180,7 +191,7 @@ o "s" is the "signaled" state that drives force_quiescent_state()'s o "jfq" is the number of jiffies remaining for this grace period before force_quiescent_state() is invoked to help push things - along. Note that CPUs in dyntick-idle mode thoughout the grace + along. Note that CPUs in dyntick-idle mode throughout the grace period will not report on their own, but rather must be check by some other CPU via force_quiescent_state(). -- cgit v1.1 From 47eb1d841790082d2fb4bc7a83c81e0a84a30a9e Mon Sep 17 00:00:00 2001 From: Florian Tobias Schandinat Date: Sun, 19 Sep 2010 05:35:44 +0000 Subject: viafb: add documentation for proc interface This patch adds documentation for the new proc interface that allows modification of the output device configuration. Should be stable and useful enough now for daily use. Signed-off-by: Florian Tobias Schandinat Acked-by: Jonathan Corbet Cc: Joseph Chan Cc: Andrew Morton --- Documentation/fb/viafb.txt | 48 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) (limited to 'Documentation') diff --git a/Documentation/fb/viafb.txt b/Documentation/fb/viafb.txt index f3e046a..1a2e8aa 100644 --- a/Documentation/fb/viafb.txt +++ b/Documentation/fb/viafb.txt @@ -197,6 +197,54 @@ Notes: example, # fbset -depth 16 + +[Configure viafb via /proc] +--------------------------- + The following files exist in /proc/viafb + + supported_output_devices + + This read-only file contains a full ',' seperated list containing all + output devices that could be available on your platform. It is likely + that not all of those have a connector on your hardware but it should + provide a good starting point to figure out which of those names match + a real connector. + Example: + # cat /proc/viafb/supported_output_devices + + iga1/output_devices + iga2/output_devices + + These two files are readable and writable. iga1 and iga2 are the two + independent units that produce the screen image. Those images can be + forwarded to one or more output devices. Reading those files is a way + to query which output devices are currently used by an iga. + Example: + # cat /proc/viafb/iga1/output_devices + If there are no output devices printed the output of this iga is lost. + This can happen for example if only one (the other) iga is used. + Writing to these files allows adjusting the output devices during + runtime. One can add new devices, remove existing ones or switch + between igas. Essentially you can write a ',' seperated list of device + names (or a single one) in the same format as the output to those + files. You can add a '+' or '-' as a prefix allowing simple addition + and removal of devices. So a prefix '+' adds the devices from your list + to the already existing ones, '-' removes the listed devices from the + existing ones and if no prefix is given it replaces all existing ones + with the listed ones. If you remove devices they are expected to turn + off. If you add devices that are already part of the other iga they are + removed there and added to the new one. + Examples: + Add CRT as output device to iga1 + # echo +CRT > /proc/viafb/iga1/output_devices + + Remove (turn off) DVP1 and LVDS1 as output devices of iga2 + # echo -DVP1,LVDS1 > /proc/viafb/iga2/output_devices + + Replace all iga1 output devices by CRT + # echo CRT > /proc/viafb/iga1/output_devices + + [Bootup with viafb]: -------------------- Add the following line to your grub.conf: -- cgit v1.1 From 4d443a085de2b6bcae5e0a773c63b8731ff27101 Mon Sep 17 00:00:00 2001 From: Kumar Sanghvi Date: Mon, 27 Sep 2010 19:35:06 +0000 Subject: Documentation: Update Phonet doc for Pipe Controller implementation Updates the Phonet document with description related to Pipe controller implementation Signed-off-by: Kumar Sanghvi Acked-by: Linus Walleij Signed-off-by: David S. Miller --- Documentation/networking/phonet.txt | 53 +++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/phonet.txt b/Documentation/networking/phonet.txt index cf76608..cccf5ff 100644 --- a/Documentation/networking/phonet.txt +++ b/Documentation/networking/phonet.txt @@ -182,6 +182,59 @@ The pipe protocol provides two socket options at the SOL_PNPIPE level: or zero if encapsulation is off. +Phonet Pipe-controller Implementation +------------------------------------- + +Phonet Pipe-controller is enabled by selecting the CONFIG_PHONET_PIPECTRLR Kconfig +option. It is useful when communicating with those Nokia Modems which do not +implement Pipe controller in them e.g. Nokia Slim Modem used in ST-Ericsson +U8500 platform. + +The implementation is based on the Data Connection Establishment Sequence +depicted in 'Nokia Wireless Modem API - Wireless_modem_user_guide.pdf' +document. + +It allows a phonet sequenced socket (host-pep) to initiate a Pipe connection +between itself and a remote pipe-end point (e.g. modem). + +The implementation adds socket options at SOL_PNPIPE level: + + PNPIPE_CREATE + It accepts an integer argument where-in + lower order 16 bits: pn_dev and pn_port pair for remote pep. + higher order 16 bits: 8 bit pipe-handle + + It sends a PNS_PEP_CONNECT_REQ on sequenced socket itself. On getting + PNS_PEP_CONNECT_RESP, it sends PNS_PEP_CONNECT_REQ to remote pep. On + getting response from remote pep, it selects the best possible Flow + control mechanism supported by remote-pep (modem) and then it sends + PNS_PEP_CREATED_IND to the sequenced socket and to the remote pep. + + It then updates the pipe state associated with the sequenced socket to + be PIPE_DISABLED. + + PNPIPE_ENABLE + It follows the same sequence as above for enabling a pipe by sending + PNS_PEP_ENABLE_REQ initially and then sending PNS_PEP_ENABLED_IND after + getting responses from sequenced socket and remote-pep. + It will also update the pipe state associated with the sequenced socket + to PIPE_ENABLED. + + PNPIPE_DESTROY + This will send out PNS_PEP_DISCONNECT_REQ on the sequenced socket and + the remote pep. + It will also update the pipe state associated with the sequenced socket + to PIPE_IDLE + + PNPIPE_INQ + This getsocktopt allows the user-space running on the sequenced socket + to examine the pipe state associated with that socket ie. whether the + pipe is created (PIPE_DISABLED) or enabled (PIPE_ENABLED) or disabled + (PIPE_DISABLED) or no pipe exists (PIPE_IDLE). + +After a pipe has been created and enabled successfully, the Pipe data can be +exchanged between the host-pep and remote-pep (modem). + Authors ------- -- cgit v1.1 From efdf02cf0651c951de055b0f52128804e11a92fa Mon Sep 17 00:00:00 2001 From: matt mooney Date: Sat, 18 Sep 2010 18:33:57 -0700 Subject: Documentation/kbuild: major edit of modules.txt sections 1-4 Omit needless words and sentences; reorganize and tighten sentence structure; swap sections 2.2 and 2.3 for a more logical flow; remove section 3, therefore shifting 4->3; add to explanations; and add section on building multiple modules. Signed-off-by: matt mooney Signed-off-by: Michal Marek --- Documentation/kbuild/modules.txt | 387 +++++++++++++++++++-------------------- 1 file changed, 189 insertions(+), 198 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt index 0767cf6..799b683 100644 --- a/Documentation/kbuild/modules.txt +++ b/Documentation/kbuild/modules.txt @@ -1,215 +1,185 @@ +Building External Modules -In this document you will find information about: -- how to build external modules -- how to make your module use the kbuild infrastructure -- how kbuild will install a kernel -- how to install modules in a non-standard location +This document describes how-to build an out-of-tree kernel module. === Table of Contents === 1 Introduction - === 2 How to build external modules - --- 2.1 Building external modules - --- 2.2 Available targets - --- 2.3 Available options - --- 2.4 Preparing the kernel tree for module build - --- 2.5 Building separate files for a module - === 3. Example commands - === 4. Creating a kbuild file for an external module - === 5. Include files - --- 5.1 How to include files from the kernel include dir - --- 5.2 External modules using an include/ dir - --- 5.3 External modules using several directories - === 6. Module installation - --- 6.1 INSTALL_MOD_PATH - --- 6.2 INSTALL_MOD_DIR - === 7. Module versioning & Module.symvers - --- 7.1 Symbols from the kernel (vmlinux + modules) - --- 7.2 Symbols and external modules - --- 7.3 Symbols from another external module - === 8. Tips & Tricks - --- 8.1 Testing for CONFIG_FOO_BAR + === 2 How-to Build External Modules + --- 2.1 Command Syntax + --- 2.2 Options + --- 2.3 Targets + --- 2.4 Building Separate Files + === 3. Creating a Kbuild File for an External Module + --- 3.1 Shared Makefile + --- 3.2 Separate Kbuild file and Makefile + --- 3.3 Binary Blobs + --- 3.4 Building Multiple Modules + === 4. Include files + --- 4.1 How to include files from the kernel include dir + --- 4.2 External modules using an include/ dir + --- 4.3 External modules using several directories + === 5. Module installation + --- 5.1 INSTALL_MOD_PATH + --- 5.2 INSTALL_MOD_DIR + === 6. Module versioning & Module.symvers + --- 6.1 Symbols from the kernel (vmlinux + modules) + --- 6.2 Symbols and external modules + --- 6.3 Symbols from another external module + === 7. Tips & Tricks + --- 7.1 Testing for CONFIG_FOO_BAR === 1. Introduction -kbuild includes functionality for building modules both -within the kernel source tree and outside the kernel source tree. -The latter is usually referred to as external or "out-of-tree" -modules and is used both during development and for modules that -are not planned to be included in the kernel tree. +"kbuild" is the build system used by the Linux kernel. Modules must use +kbuild to stay compatible with changes in the build infrastructure and +to pick up the right flags to "gcc." Functionality for building modules +both in-tree and out-of-tree is provided. The method for building +either is similar, and all modules are initially developed and built +out-of-tree. -What is covered within this file is mainly information to authors -of modules. The author of an external module should supply -a makefile that hides most of the complexity, so one only has to type -'make' to build the module. A complete example will be presented in -chapter 4, "Creating a kbuild file for an external module". +Covered in this document is information aimed at developers interested +in building out-of-tree (or "external") modules. The author of an +external module should supply a makefile that hides most of the +complexity, so one only has to type "make" to build the module. This is +easily accomplished, and a complete example will be presented in +section 3. -=== 2. How to build external modules +=== 2. How-to Build External Modules -kbuild offers functionality to build external modules, with the -prerequisite that there is a pre-built kernel available with full source. -A subset of the targets available when building the kernel is available -when building an external module. +To build external modules, you must have a pre-built kernel available +that contains the configuration and header files used in the build. +Also, the kernel must have been built with modules enabled. If you are +using a distribution kernel, there will be a package for the kernel you +are running provided by your distribution. ---- 2.1 Building external modules +An alternative is to use the "make" target "modules_prepare." This will +make sure the kernel contains the information required. The target +exists solely as a simple way to prepare a kernel source tree for +building external modules. - Use the following command to build an external module: +NOTE: "modules_prepare" will not build Module.symvers even if +CONFIG_MODVERSIONS is set; therefore, a full kernel build needs to be +executed to make module versioning work. - make -C M=`pwd` +--- 2.1 Command Syntax - For the running kernel use: + The command to build an external module is: - make -C /lib/modules/`uname -r`/build M=`pwd` + make -C M=$PWD - For the above command to succeed, the kernel must have been - built with modules enabled. + The kbuild system knows that an external module is being built + due to the "M=" option given in the command. - To install the modules that were just built: + To build against the running kernel use: - make -C M=`pwd` modules_install + make -C /lib/modules/`uname -r`/build M=$PWD - More complex examples will be shown later, the above should - be enough to get you started. + Then to install the module(s) just built, add the target + "modules_install" to the command: ---- 2.2 Available targets + make -C /lib/modules/`uname -r`/build M=$PWD modules_install - $KDIR refers to the path to the kernel source top-level directory +--- 2.2 Options - make -C $KDIR M=`pwd` - Will build the module(s) located in current directory. - All output files will be located in the same directory - as the module source. - No attempts are made to update the kernel source, and it is - a precondition that a successful make has been executed - for the kernel. + ($KDIR refers to the path of the kernel source directory.) - make -C $KDIR M=`pwd` modules - The modules target is implied when no target is given. - Same functionality as if no target was specified. - See description above. + make -C $KDIR M=$PWD - make -C $KDIR M=`pwd` modules_install - Install the external module(s). - Installation default is in /lib/modules//extra, - but may be prefixed with INSTALL_MOD_PATH - see separate - chapter. + -C $KDIR + The directory where the kernel source is located. + "make" will actually change to the specified directory + when executing and will change back when finished. - make -C $KDIR M=`pwd` clean - Remove all generated files for the module - the kernel - source directory is not modified. + M=$PWD + Informs kbuild that an external module is being built. + The value given to "M" is the absolute path of the + directory where the external module (kbuild file) is + located. - make -C $KDIR M=`pwd` help - help will list the available target when building external - modules. +--- 2.3 Targets ---- 2.3 Available options: + When building an external module, only a subset of the "make" + targets are available. - $KDIR refers to the path to the kernel source top-level directory + make -C $KDIR M=$PWD [target] - make -C $KDIR - Used to specify where to find the kernel source. - '$KDIR' represent the directory where the kernel source is. - Make will actually change directory to the specified directory - when executed but change back when finished. + The default will build the module(s) located in the current + directory, so a target does not need to be specified. All + output files will also be generated in this directory. No + attempts are made to update the kernel source, and it is a + precondition that a successful "make" has been executed for the + kernel. - make -C $KDIR M=`pwd` - M= is used to tell kbuild that an external module is - being built. - The option given to M= is the directory where the external - module (kbuild file) is located. - When an external module is being built only a subset of the - usual targets are available. + modules + The default target for external modules. It has the + same functionality as if no target was specified. See + description above. - make -C $KDIR SUBDIRS=`pwd` - Same as M=. The SUBDIRS= syntax is kept for backwards - compatibility. + modules_install + Install the external module(s). The default location is + /lib/modules//extra, but a prefix may + be added with INSTALL_MOD_PATH (discussed in section 5). ---- 2.4 Preparing the kernel tree for module build + clean + Remove all generated files in the module directory only. - To make sure the kernel contains the information required to - build external modules the target 'modules_prepare' must be used. - 'modules_prepare' exists solely as a simple way to prepare - a kernel source tree for building external modules. - Note: modules_prepare will not build Module.symvers even if - CONFIG_MODVERSIONS is set. Therefore a full kernel build - needs to be executed to make module versioning work. + help + List the available targets for external modules. ---- 2.5 Building separate files for a module - It is possible to build single files which are part of a module. - This works equally well for the kernel, a module and even for - external modules. - Examples (module foo.ko, consist of bar.o, baz.o): - make -C $KDIR M=`pwd` bar.lst - make -C $KDIR M=`pwd` bar.o - make -C $KDIR M=`pwd` foo.ko - make -C $KDIR M=`pwd` / - - -=== 3. Example commands - -This example shows the actual commands to be executed when building -an external module for the currently running kernel. -In the example below, the distribution is supposed to use the -facility to locate output files for a kernel compile in a different -directory than the kernel source - but the examples will also work -when the source and the output files are mixed in the same directory. - -# Kernel source -/lib/modules//source -> /usr/src/linux- +--- 2.4 Building Separate Files -# Output from kernel compile -/lib/modules//build -> /usr/src/linux--up - -Change to the directory where the kbuild file is located and execute -the following commands to build the module: + It is possible to build single files that are part of a module. + This works equally well for the kernel, a module, and even for + external modules. - cd /home/user/src/module - make -C /usr/src/`uname -r`/source \ - O=/lib/modules/`uname-r`/build \ - M=`pwd` + Example (The module foo.ko, consist of bar.o and baz.o): + make -C $KDIR M=$PWD bar.lst + make -C $KDIR M=$PWD baz.o + make -C $KDIR M=$PWD foo.ko + make -C $KDIR M=$PWD / -Then, to install the module use the following command: - make -C /usr/src/`uname -r`/source \ - O=/lib/modules/`uname-r`/build \ - M=`pwd` \ - modules_install +=== 3. Creating a Kbuild File for an External Module -If you look closely you will see that this is the same command as -listed before - with the directories spelled out. +In the last section we saw the command to build a module for the +running kernel. The module is not actually built, however, because a +build file is required. Contained in this file will be the name of +the module(s) being built, along with the list of requisite source +files. The file may be as simple as a single line: -The above are rather long commands, and the following chapter -lists a few tricks to make it all easier. + obj-m := .o +The kbuild system will build .o from .c, +and, after linking, will result in the kernel module .ko. +The above line can be put in either a "Kbuild" file or a "Makefile." +When the module is built from multiple sources, an additional line is +needed listing the files: -=== 4. Creating a kbuild file for an external module + -y := .o .o ... -kbuild is the build system for the kernel, and external modules -must use kbuild to stay compatible with changes in the build system -and to pick up the right flags to gcc etc. +NOTE: Further documentation describing the syntax used by kbuild is +located in Documentation/kbuild/makefiles.txt. -The kbuild file used as input shall follow the syntax described -in Documentation/kbuild/makefiles.txt. This chapter will introduce a few -more tricks to be used when dealing with external modules. +The examples below demonstrate how-to create a build file for the +module 8123.ko, which is built from the following files: -In the following a Makefile will be created for a module with the -following files: 8123_if.c 8123_if.h 8123_pci.c 8123_bin.o_shipped <= Binary blob ---- 4.1 Shared Makefile for module and kernel +--- 3.1 Shared Makefile - An external module always includes a wrapper Makefile supporting - building the module using 'make' with no arguments. - The Makefile provided will most likely include additional - functionality such as test targets etc. and this part shall - be filtered away from kbuild since it may impact kbuild if - name clashes occurs. + An external module always includes a wrapper makefile that + supports building the module using "make" with no arguments. + This target is not used by kbuild; it is only for convenience. + Additional functionality, such as test targets, can be included + but should be filtered out from kbuild due to possible name + clashes. Example 1: --> filename: Makefile @@ -219,11 +189,11 @@ following files: 8123-y := 8123_if.o 8123_pci.o 8123_bin.o else - # Normal Makefile + # normal makefile + KDIR ?= /lib/modules/`uname -r`/build - KERNELDIR := /lib/modules/`uname -r`/build - all:: - $(MAKE) -C $(KERNELDIR) M=`pwd` $@ + default: + $(MAKE) -C $(KDIR) M=$$PWD # Module specific targets genbin: @@ -231,15 +201,20 @@ following files: endif - In example 1, the check for KERNELRELEASE is used to separate - the two parts of the Makefile. kbuild will only see the two - assignments whereas make will see everything except the two - kbuild assignments. + The check for KERNELRELEASE is used to separate the two parts + of the makefile. In the example, kbuild will only see the two + assignments, whereas "make" will see everything except these + two assignments. This is due to two passes made on the file: + the first pass is by the "make" instance run on the + command line; the second pass is by the kbuild system, which is + initiated by the parameterized "make" in the default target. - In recent versions of the kernel, kbuild will look for a file named - Kbuild and as second option look for a file named Makefile. - Utilising the Kbuild file makes us split up the Makefile in example 1 - into two files as shown in example 2: +--- 3.2 Separate Kbuild File and Makefile + + In newer versions of the kernel, kbuild will first look for a + file named "Kbuild", and only if that is not found, will it + then look for a makefile. Utilizing a "Kbuild" file allows us + to split up the makefile from example 1 into two files: Example 2: --> filename: Kbuild @@ -247,20 +222,21 @@ following files: 8123-y := 8123_if.o 8123_pci.o 8123_bin.o --> filename: Makefile - KERNELDIR := /lib/modules/`uname -r`/build - all:: - $(MAKE) -C $(KERNELDIR) M=`pwd` $@ + KDIR ?= /lib/modules/`uname -r`/build + + default: + $(MAKE) -C $(KDIR) M=$$PWD # Module specific targets genbin: echo "X" > 8123_bin.o_shipped + The split in example 2 is questionable due to the simplicity of + each file; however, some external modules use makefiles + consisting of several hundred lines, and here it really pays + off to separate the kbuild part from the rest. - In example 2, we are down to two fairly simple files and for simple - files as used in this example the split is questionable. But some - external modules use Makefiles of several hundred lines and here it - really pays off to separate the kbuild part from the rest. - Example 3 shows a backward compatible version. + The next example shows a backward compatible version. Example 3: --> filename: Kbuild @@ -269,13 +245,15 @@ following files: --> filename: Makefile ifneq ($(KERNELRELEASE),) + # kbuild part of makefile include Kbuild + else - # Normal Makefile + # normal makefile + KDIR ?= /lib/modules/`uname -r`/build - KERNELDIR := /lib/modules/`uname -r`/build - all:: - $(MAKE) -C $(KERNELDIR) M=`pwd` $@ + default: + $(MAKE) -C $(KDIR) M=$$PWD # Module specific targets genbin: @@ -283,28 +261,41 @@ following files: endif - The trick here is to include the Kbuild file from Makefile, so - if an older version of kbuild picks up the Makefile, the Kbuild - file will be included. + Here the "Kbuild" file is included from the makefile. This + allows an older version of kbuild, which only knows of + makefiles, to be used when the "make" and kbuild parts are + split into separate files. ---- 4.2 Binary blobs included in a module +--- 3.3 Binary Blobs - Some external modules needs to include a .o as a blob. kbuild - has support for this, but requires the blob file to be named - _shipped. In our example the blob is named - 8123_bin.o_shipped and when the kbuild rules kick in the file - 8123_bin.o is created as a simple copy off the 8213_bin.o_shipped file - with the _shipped part stripped of the filename. - This allows the 8123_bin.o filename to be used in the assignment to - the module. + Some external modules need to include an object file as a blob. + kbuild has support for this, but requires the blob file to be + named _shipped. When the kbuild rules kick in, a copy + of _shipped is created with _shipped stripped off, + giving us . This shortened filename can be used in + the assignment to the module. + + Throughout this section, 8123_bin.o_shipped has been used to + build the kernel module 8123.ko; it has been included as + 8123_bin.o. - Example 4: - obj-m := 8123.o 8123-y := 8123_if.o 8123_pci.o 8123_bin.o - In example 4, there is no distinction between the ordinary .c/.h files - and the binary file. But kbuild will pick up different rules to create - the .o file. + Although there is no distinction between the ordinary source + files and the binary file, kbuild will pick up different rules + when creating the object file for the module. + +--- 3.4 Building Multiple Modules + + kbuild supports building multiple modules with a single build + file. For example, if you want to build two modules, foo and + bar, the kbuild lines would be: + + obj-m := foo.o bar.o + foo-y := + bar-y := + + It is that simple! === 5. Include files -- cgit v1.1 From 9f02186c236ba4ce11ba4e50d5a756c53d56c29e Mon Sep 17 00:00:00 2001 From: matt mooney Date: Sun, 19 Sep 2010 23:06:36 -0700 Subject: Documentation/kbuild: major edit of modules.txt sections 5-8 A follow-up to my edit of the first 4 sections. Shift sections down by one due to the deletion of section 3; grammar corrections along with some rewording; margin width cleanup; and change EXTRA_CFLAGS -> ccflags-y. Signed-off-by: matt mooney Signed-off-by: Michal Marek --- Documentation/kbuild/modules.txt | 358 +++++++++++++++++++-------------------- 1 file changed, 177 insertions(+), 181 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt index 799b683..b572db3 100644 --- a/Documentation/kbuild/modules.txt +++ b/Documentation/kbuild/modules.txt @@ -15,17 +15,17 @@ This document describes how-to build an out-of-tree kernel module. --- 3.2 Separate Kbuild file and Makefile --- 3.3 Binary Blobs --- 3.4 Building Multiple Modules - === 4. Include files - --- 4.1 How to include files from the kernel include dir - --- 4.2 External modules using an include/ dir - --- 4.3 External modules using several directories - === 5. Module installation + === 4. Include Files + --- 4.1 Kernel Includes + --- 4.2 Single Subdirectory + --- 4.3 Several Subdirectories + === 5. Module Installation --- 5.1 INSTALL_MOD_PATH --- 5.2 INSTALL_MOD_DIR - === 6. Module versioning & Module.symvers - --- 6.1 Symbols from the kernel (vmlinux + modules) - --- 6.2 Symbols and external modules - --- 6.3 Symbols from another external module + === 6. Module Versioning + --- 6.1 Symbols From the Kernel (vmlinux + modules) + --- 6.2 Symbols and External Modules + --- 6.3 Symbols From Another External Module === 7. Tips & Tricks --- 7.1 Testing for CONFIG_FOO_BAR @@ -298,236 +298,232 @@ module 8123.ko, which is built from the following files: It is that simple! -=== 5. Include files +=== 4. Include Files -Include files are a necessity when a .c file uses something from other .c -files (not strictly in the sense of C, but if good programming practice is -used). Any module that consists of more than one .c file will have a .h file -for one of the .c files. +Within the kernel, header files are kept in standard locations +according to the following rule: -- If the .h file only describes a module internal interface, then the .h file - shall be placed in the same directory as the .c files. -- If the .h files describe an interface used by other parts of the kernel - located in different directories, the .h files shall be located in - include/linux/ or other include/ directories as appropriate. + * If the header file only describes the internal interface of a + module, then the file is placed in the same directory as the + source files. + * If the header file describes an interface used by other parts + of the kernel that are located in different directories, then + the file is placed in include/linux/. -One exception for this rule is larger subsystems that have their own directory -under include/ such as include/scsi. Another exception is arch-specific -.h files which are located under include/asm-$(ARCH)/*. + NOTE: There are two notable exceptions to this rule: larger + subsystems have their own directory under include/, such as + include/scsi; and architecture specific headers are located + under arch/$(ARCH)/include/. -External modules have a tendency to locate include files in a separate include/ -directory and therefore need to deal with this in their kbuild file. +--- 4.1 Kernel Includes ---- 5.1 How to include files from the kernel include dir - - When a module needs to include a file from include/linux/, then one - just uses: + To include a header file located under include/linux/, simply + use: #include - kbuild will make sure to add options to gcc so the relevant - directories are searched. - Likewise for .h files placed in the same directory as the .c file. - - #include "8123_if.h" - - will do the job. + kbuild will add options to "gcc" so the relevant directories + are searched. ---- 5.2 External modules using an include/ dir +--- 4.2 Single Subdirectory - External modules often locate their .h files in a separate include/ - directory although this is not usual kernel style. When an external - module uses an include/ dir then kbuild needs to be told so. - The trick here is to use either EXTRA_CFLAGS (take effect for all .c - files) or CFLAGS_$F.o (take effect only for a single file). + External modules tend to place header files in a separate + include/ directory where their source is located, although this + is not the usual kernel style. To inform kbuild of the + directory use either ccflags-y or CFLAGS_.o. - In our example, if we move 8123_if.h to a subdirectory named include/ - the resulting Kbuild file would look like: + Using the example from section 3, if we moved 8123_if.h to a + subdirectory named include, the resulting kbuild file would + look like: --> filename: Kbuild - obj-m := 8123.o + obj-m := 8123.o - EXTRA_CFLAGS := -Iinclude + ccflags-y := -Iinclude 8123-y := 8123_if.o 8123_pci.o 8123_bin.o - Note that in the assignment there is no space between -I and the path. - This is a kbuild limitation: there must be no space present. - ---- 5.3 External modules using several directories + Note that in the assignment there is no space between -I and + the path. This is a limitation of kbuild: there must be no + space present. - If an external module does not follow the usual kernel style, but - decides to spread files over several directories, then kbuild can - handle this too. +--- 4.3 Several Subdirectories + kbuild can handle files that are spread over several directories. Consider the following example: - | - +- src/complex_main.c - | +- hal/hardwareif.c - | +- hal/include/hardwareif.h - +- include/complex.h - - To build a single module named complex.ko, we then need the following + . + |__ src + | |__ complex_main.c + | |__ hal + | |__ hardwareif.c + | |__ include + | |__ hardwareif.h + |__ include + |__ complex.h + + To build the module complex.ko, we then need the following kbuild file: - Kbuild: + --> filename: Kbuild obj-m := complex.o complex-y := src/complex_main.o complex-y += src/hal/hardwareif.o - EXTRA_CFLAGS := -I$(src)/include - EXTRA_CFLAGS += -I$(src)src/hal/include + ccflags-y := -I$(src)/include + ccflags-y += -I$(src)/src/hal/include + As you can see, kbuild knows how to handle object files located + in other directories. The trick is to specify the directory + relative to the kbuild file's location. That being said, this + is NOT recommended practice. - kbuild knows how to handle .o files located in another directory - - although this is NOT recommended practice. The syntax is to specify - the directory relative to the directory where the Kbuild file is - located. + For the header files, kbuild must be explicitly told where to + look. When kbuild executes, the current directory is always the + root of the kernel tree (the argument to "-C") and therefore an + absolute path is needed. $(src) provides the absolute path by + pointing to the directory where the currently executing kbuild + file is located. - To find the .h files, we have to explicitly tell kbuild where to look - for the .h files. When kbuild executes, the current directory is always - the root of the kernel tree (argument to -C) and therefore we have to - tell kbuild how to find the .h files using absolute paths. - $(src) will specify the absolute path to the directory where the - Kbuild file are located when being build as an external module. - Therefore -I$(src)/ is used to point out the directory of the Kbuild - file and any additional path are just appended. -=== 6. Module installation +=== 5. Module Installation -Modules which are included in the kernel are installed in the directory: +Modules which are included in the kernel are installed in the +directory: /lib/modules/$(KERNELRELEASE)/kernel -External modules are installed in the directory: +And external modules are installed in: /lib/modules/$(KERNELRELEASE)/extra ---- 6.1 INSTALL_MOD_PATH +--- 5.1 INSTALL_MOD_PATH - Above are the default directories, but as always, some level of - customization is possible. One can prefix the path using the variable - INSTALL_MOD_PATH: + Above are the default directories but as always some level of + customization is possible. A prefix can be added to the + installation path using the variable INSTALL_MOD_PATH: $ make INSTALL_MOD_PATH=/frodo modules_install => Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel - INSTALL_MOD_PATH may be set as an ordinary shell variable or as in the - example above, can be specified on the command line when calling make. - INSTALL_MOD_PATH has effect both when installing modules included in - the kernel as well as when installing external modules. + INSTALL_MOD_PATH may be set as an ordinary shell variable or, + as shown above, can be specified on the command line when + calling "make." This has effect when installing both in-tree + and out-of-tree modules. ---- 6.2 INSTALL_MOD_DIR +--- 5.2 INSTALL_MOD_DIR - When installing external modules they are by default installed to a - directory under /lib/modules/$(KERNELRELEASE)/extra, but one may wish - to locate modules for a specific functionality in a separate - directory. For this purpose, one can use INSTALL_MOD_DIR to specify an - alternative name to 'extra'. + External modules are by default installed to a directory under + /lib/modules/$(KERNELRELEASE)/extra, but you may wish to locate + modules for a specific functionality in a separate directory. + For this purpose, use INSTALL_MOD_DIR to specify an alternative + name to "extra." - $ make INSTALL_MOD_DIR=gandalf -C KERNELDIR \ - M=`pwd` modules_install + $ make INSTALL_MOD_DIR=gandalf -C $KDIR \ + M=$PWD modules_install => Install dir: /lib/modules/$(KERNELRELEASE)/gandalf -=== 7. Module versioning & Module.symvers +=== 6. Module Versioning -Module versioning is enabled by the CONFIG_MODVERSIONS tag. +Module versioning is enabled by the CONFIG_MODVERSIONS tag, and is used +as a simple ABI consistency check. A CRC value of the full prototype +for an exported symbol is created. When a module is loaded/used, the +CRC values contained in the kernel are compared with similar values in +the module; if they are not equal, the kernel refuses to load the +module. -Module versioning is used as a simple ABI consistency check. The Module -versioning creates a CRC value of the full prototype for an exported symbol and -when a module is loaded/used then the CRC values contained in the kernel are -compared with similar values in the module. If they are not equal, then the -kernel refuses to load the module. +Module.symvers contains a list of all exported symbols from a kernel +build. -Module.symvers contains a list of all exported symbols from a kernel build. +--- 6.1 Symbols From the Kernel (vmlinux + modules) ---- 7.1 Symbols from the kernel (vmlinux + modules) - - During a kernel build, a file named Module.symvers will be generated. - Module.symvers contains all exported symbols from the kernel and - compiled modules. For each symbols, the corresponding CRC value - is stored too. + During a kernel build, a file named Module.symvers will be + generated. Module.symvers contains all exported symbols from + the kernel and compiled modules. For each symbol, the + corresponding CRC value is also stored. The syntax of the Module.symvers file is: - - Sample: + + 0x2d036834 scsi_remove_host drivers/scsi/scsi_mod - For a kernel build without CONFIG_MODVERSIONS enabled, the crc - would read: 0x00000000 + For a kernel build without CONFIG_MODVERSIONS enabled, the CRC + would read 0x00000000. Module.symvers serves two purposes: - 1) It lists all exported symbols both from vmlinux and all modules - 2) It lists the CRC if CONFIG_MODVERSIONS is enabled - ---- 7.2 Symbols and external modules - - When building an external module, the build system needs access to - the symbols from the kernel to check if all external symbols are - defined. This is done in the MODPOST step and to obtain all - symbols, modpost reads Module.symvers from the kernel. - If a Module.symvers file is present in the directory where - the external module is being built, this file will be read too. - During the MODPOST step, a new Module.symvers file will be written - containing all exported symbols that were not defined in the kernel. - ---- 7.3 Symbols from another external module - - Sometimes, an external module uses exported symbols from another - external module. Kbuild needs to have full knowledge on all symbols - to avoid spitting out warnings about undefined symbols. - Three solutions exist to let kbuild know all symbols of more than - one external module. - The method with a top-level kbuild file is recommended but may be - impractical in certain situations. - - Use a top-level Kbuild file - If you have two modules: 'foo' and 'bar', and 'foo' needs - symbols from 'bar', then one can use a common top-level kbuild - file so both modules are compiled in same build. - - Consider following directory layout: - ./foo/ <= contains the foo module - ./bar/ <= contains the bar module - The top-level Kbuild file would then look like: - - #./Kbuild: (this file may also be named Makefile) + 1) It lists all exported symbols from vmlinux and all modules. + 2) It lists the CRC if CONFIG_MODVERSIONS is enabled. + +--- 6.2 Symbols and External Modules + + When building an external module, the build system needs access + to the symbols from the kernel to check if all external symbols + are defined. This is done in the MODPOST step. modpost obtains + the symbols by reading Module.symvers from the kernel source + tree. If a Module.symvers file is present in the directory + where the external module is being built, this file will be + read too. During the MODPOST step, a new Module.symvers file + will be written containing all exported symbols that were not + defined in the kernel. + +--- 6.3 Symbols From Another External Module + + Sometimes, an external module uses exported symbols from + another external module. kbuild needs to have full knowledge of + all symbols to avoid spitting out warnings about undefined + symbols. Three solutions exist for this situation. + + NOTE: The method with a top-level kbuild file is recommended + but may be impractical in certain situations. + + Use a top-level kbuild file + If you have two modules, foo.ko and bar.ko, where + foo.ko needs symbols from bar.ko, then you can use a + common top-level kbuild file so both modules are + compiled in the same build. Consider following + directory layout: + + ./foo/ <= contains foo.ko + ./bar/ <= contains bar.ko + + The top-level kbuild file would then look like: + + #./Kbuild (or ./Makefile): obj-y := foo/ bar/ - Executing: - make -C $KDIR M=`pwd` + And executing: + $ make -C $KDIR M=$PWD - will then do the expected and compile both modules with full - knowledge on symbols from both modules. + Will then do the expected and compile both modules with + full knowledge of symbols from either module. Use an extra Module.symvers file - When an external module is built, a Module.symvers file is - generated containing all exported symbols which are not - defined in the kernel. - To get access to symbols from module 'bar', one can copy the - Module.symvers file from the compilation of the 'bar' module - to the directory where the 'foo' module is built. - During the module build, kbuild will read the Module.symvers - file in the directory of the external module and when the - build is finished, a new Module.symvers file is created - containing the sum of all symbols defined and not part of the - kernel. - - Use make variable KBUILD_EXTRA_SYMBOLS in the Makefile - If it is impractical to copy Module.symvers from another - module, you can assign a space separated list of files to - KBUILD_EXTRA_SYMBOLS in your Makfile. These files will be - loaded by modpost during the initialisation of its symbol - tables. - -=== 8. Tips & Tricks - ---- 8.1 Testing for CONFIG_FOO_BAR - - Modules often need to check for certain CONFIG_ options to decide if - a specific feature shall be included in the module. When kbuild is used - this is done by referencing the CONFIG_ variable directly. + When an external module is built, a Module.symvers file + is generated containing all exported symbols which are + not defined in the kernel. To get access to symbols + from bar.ko, copy the Module.symvers file from the + compilation of bar.ko to the directory where foo.ko is + built. During the module build, kbuild will read the + Module.symvers file in the directory of the external + module, and when the build is finished, a new + Module.symvers file is created containing the sum of + all symbols defined and not part of the kernel. + + Use "make" variable KBUILD_EXTRA_SYMBOLS + If it is impractical to copy Module.symvers from + another module, you can assign a space separated list + of files to KBUILD_EXTRA_SYMBOLS in your build + file. These files will be loaded by modpost during the + initialization of its symbol tables. + +=== 7. Tips & Tricks + +--- 7.1 Testing for CONFIG_FOO_BAR + + Modules often need to check for certain CONFIG_ options to + decide if a specific feature is included in the module. In + kbuild this is done by referencing the CONFIG_ variable + directly. #fs/ext2/Makefile obj-$(CONFIG_EXT2_FS) += ext2.o @@ -535,9 +531,9 @@ Module.symvers contains a list of all exported symbols from a kernel build. ext2-y := balloc.o bitmap.o dir.o ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o - External modules have traditionally used grep to check for specific - CONFIG_ settings directly in .config. This usage is broken. - As introduced before, external modules shall use kbuild when building - and therefore can use the same methods as in-kernel modules when - testing for CONFIG_ definitions. + External modules have traditionally used "grep" to check for + specific CONFIG_ settings directly in .config. This usage is + broken. As introduced before, external modules should use + kbuild for building and can therefore use the same methods as + in-tree modules when testing for CONFIG_ definitions. -- cgit v1.1 From cdb138080b78146d1cdadba9f5dadbeb97445b91 Mon Sep 17 00:00:00 2001 From: Dominik Brodowski Date: Wed, 28 Jul 2010 10:59:06 +0200 Subject: pcmcia: do not use win_req_t when calling pcmcia_request_window() Instead of win_req_t, drivers are now requested to fill out struct pcmcia_device *p_dev->resource[2,3,4,5] for up to four iomem ranges. After a call to pcmcia_request_window(), the windows found there are reserved and may be used until pcmcia_release_window() is called. CC: netdev@vger.kernel.org CC: linux-wireless@vger.kernel.org CC: linux-mtd@lists.infradead.org CC: Jiri Kosina CC: linux-scsi@vger.kernel.org Tested-by: Wolfram Sang Signed-off-by: Dominik Brodowski --- Documentation/pcmcia/driver-changes.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/pcmcia/driver-changes.txt b/Documentation/pcmcia/driver-changes.txt index 26c0f9c..86e0f49 100644 --- a/Documentation/pcmcia/driver-changes.txt +++ b/Documentation/pcmcia/driver-changes.txt @@ -1,4 +1,11 @@ This file details changes in 2.6 which affect PCMCIA card driver authors: +* pcmcia_request_window changes (as of 2.6.36) + Instead of win_req_t, drivers are now requested to fill out + struct pcmcia_device *p_dev->resource[2,3,4,5] for up to four ioport + ranges. After a call to pcmcia_request_window(), the regions found there + are reserved and may be used immediately -- until pcmcia_release_window() + is called. + * pcmcia_request_io changes (as of 2.6.36) Instead of io_req_t, drivers are now requested to fill out struct pcmcia_device *p_dev->resource[0,1] for up to two ioport -- cgit v1.1 From 1ac71e5a35eebee60cdcf15b3980bd94498f037b Mon Sep 17 00:00:00 2001 From: Dominik Brodowski Date: Thu, 29 Jul 2010 19:27:09 +0200 Subject: pcmcia: convert pcmcia_request_configuration to pcmcia_enable_device pcmcia_enable_device() now replaces pcmcia_request_configuration(). Instead of config_req_t, all necessary flags are either passed as a parameter to pcmcia_enable_device(), or (in rare circumstances) set in struct pcmcia_device -> flags. With the last remaining user of include/pcmcia/cs.h gone, remove all references. CC: netdev@vger.kernel.org CC: linux-wireless@vger.kernel.org CC: linux-ide@vger.kernel.org CC: linux-usb@vger.kernel.org CC: laforge@gnumonks.org CC: linux-mtd@lists.infradead.org CC: alsa-devel@alsa-project.org CC: linux-serial@vger.kernel.org CC: Jiri Kosina CC: linux-scsi@vger.kernel.org Acked-by: Gustavo F. Padovan (for drivers/bluetooth) Tested-by: Wolfram Sang Signed-off-by: Dominik Brodowski --- Documentation/pcmcia/driver-changes.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/pcmcia/driver-changes.txt b/Documentation/pcmcia/driver-changes.txt index 86e0f49..62a029f 100644 --- a/Documentation/pcmcia/driver-changes.txt +++ b/Documentation/pcmcia/driver-changes.txt @@ -1,4 +1,10 @@ This file details changes in 2.6 which affect PCMCIA card driver authors: +* pcmcia_request_configuration -> pcmcia_enable_device (as of 2.6.36) + pcmcia_request_configuration() got renamed to pcmcia_enable_device(), + as it mirrors pcmcia_disable_device(). Configuration settings are now + stored in struct pcmcia_device, e.g. in the fields config_flags, + config_index, config_base, vpp. + * pcmcia_request_window changes (as of 2.6.36) Instead of win_req_t, drivers are now requested to fill out struct pcmcia_device *p_dev->resource[2,3,4,5] for up to four ioport -- cgit v1.1 From 00990e7ce0b0e596fe41d9c64d6933ea70084003 Mon Sep 17 00:00:00 2001 From: Dominik Brodowski Date: Fri, 30 Jul 2010 13:13:46 +0200 Subject: pcmcia: use autoconfiguration feature for ioports and iomem When CONF_AUTO_SET_IO or CONF_AUTO_SET_IOMEM are set, the corresponding fields in struct pcmcia_device *p_dev->resource[0,1,2] are set accordinly. Drivers wishing to override certain settings may do so in the callback function, but they no longer need to parse the CIS entries stored in cistpl_cftable_entry_t themselves. CC: netdev@vger.kernel.org CC: linux-wireless@vger.kernel.org CC: linux-ide@vger.kernel.org CC: linux-usb@vger.kernel.org CC: laforge@gnumonks.org CC: linux-mtd@lists.infradead.org CC: linux-bluetooth@vger.kernel.org CC: alsa-devel@alsa-project.org CC: linux-serial@vger.kernel.org CC: Jiri Kosina CC: linux-scsi@vger.kernel.org Tested-by: Wolfram Sang Signed-off-by: Dominik Brodowski --- Documentation/pcmcia/driver-changes.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/pcmcia/driver-changes.txt b/Documentation/pcmcia/driver-changes.txt index 62a029f..dd04361 100644 --- a/Documentation/pcmcia/driver-changes.txt +++ b/Documentation/pcmcia/driver-changes.txt @@ -1,4 +1,16 @@ This file details changes in 2.6 which affect PCMCIA card driver authors: +* pcmcia_loop_config() and autoconfiguration (as of 2.6.36) + If struct pcmcia_device *p_dev->config_flags is set accordingly, + pcmcia_loop_config() now sets up certain configuration values + automatically, though the driver may still override the settings + in the callback function. The following autoconfiguration options + are provided at the moment: + CONF_AUTO_CHECK_VCC : check for matching Vcc + CONF_AUTO_SET_VPP : set Vpp + CONF_AUTO_AUDIO : auto-enable audio line, if required + CONF_AUTO_SET_IO : set ioport resources (->resource[0,1]) + CONF_AUTO_SET_IOMEM : set first iomem resource (->resource[2]) + * pcmcia_request_configuration -> pcmcia_enable_device (as of 2.6.36) pcmcia_request_configuration() got renamed to pcmcia_enable_device(), as it mirrors pcmcia_disable_device(). Configuration settings are now -- cgit v1.1 From 4cb36310848fd17766aa72afd1f2873f54b4e055 Mon Sep 17 00:00:00 2001 From: David Henningsson Date: Thu, 30 Sep 2010 10:12:50 +0200 Subject: ALSA: HDA: Add position_fix=3 module option, and refactor related code What was previously known as via_dmapos_patch, and hard-coded to be used for VIA and ATI controllers, is now configurable through a module option. The background is that some VIA controllers seem to prefer via_dmapos_patch to be turned off. Signed-off-by: David Henningsson Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio.txt | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio.txt b/Documentation/sound/alsa/HD-Audio.txt index 278cc21..c82beb0 100644 --- a/Documentation/sound/alsa/HD-Audio.txt +++ b/Documentation/sound/alsa/HD-Audio.txt @@ -57,9 +57,11 @@ dead. However, this detection isn't perfect on some devices. In such a case, you can change the default method via `position_fix` option. `position_fix=1` means to use LPIB method explicitly. -`position_fix=2` means to use the position-buffer. 0 is the default -value, the automatic check and fallback to LPIB as described in the -above. If you get a problem of repeated sounds, this option might +`position_fix=2` means to use the position-buffer. +`position_fix=3` means to use a combination of both methods, needed +for some VIA and ATI controllers. 0 is the default value for all other +controllers, the automatic check and fallback to LPIB as described in +the above. If you get a problem of repeated sounds, this option might help. In addition to that, every controller is known to be broken regarding -- cgit v1.1 From 2116b7a473bf1c8d26998b477c294e7fe294921f Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Mon, 4 Oct 2010 22:55:57 +0200 Subject: smbfs: move to drivers/staging smbfs has been scheduled for removal in 2.6.27, so maybe we can now move it to drivers/staging on the way out. smbfs still uses the big kernel lock and nobody is going to fix that, so we should be getting rid of it soon. This removes the 32 bit compat mount and ioctl handling code, which is implemented in common fs code, and moves all smbfs related files into drivers/staging/smbfs. Signed-off-by: Arnd Bergmann Acked-by: Jeff Layton Signed-off-by: Greg Kroah-Hartman --- Documentation/filesystems/00-INDEX | 2 -- Documentation/filesystems/smbfs.txt | 8 -------- Documentation/ioctl/ioctl-number.txt | 2 +- 3 files changed, 1 insertion(+), 11 deletions(-) delete mode 100644 Documentation/filesystems/smbfs.txt (limited to 'Documentation') diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index 4303614..8c624a1 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX @@ -96,8 +96,6 @@ seq_file.txt - how to use the seq_file API sharedsubtree.txt - a description of shared subtrees for namespaces. -smbfs.txt - - info on using filesystems with the SMB protocol (Win 3.11 and NT). spufs.txt - info and mount options for the SPU filesystem used on Cell. sysfs-pci.txt diff --git a/Documentation/filesystems/smbfs.txt b/Documentation/filesystems/smbfs.txt deleted file mode 100644 index 194fb0d..0000000 --- a/Documentation/filesystems/smbfs.txt +++ /dev/null @@ -1,8 +0,0 @@ -Smbfs is a filesystem that implements the SMB protocol, which is the -protocol used by Windows for Workgroups, Windows 95 and Windows NT. -Smbfs was inspired by Samba, the program written by Andrew Tridgell -that turns any Unix host into a file server for DOS or Windows clients. - -Smbfs is a SMB client, but uses parts of samba for its operation. For -more info on samba, including documentation, please go to -http://www.samba.org/ and then on to your nearest mirror. diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 33223ff..d15834a 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -259,7 +259,7 @@ Code Seq#(hex) Include File Comments 't' 00-7F linux/if_ppp.h 't' 80-8F linux/isdn_ppp.h 't' 90 linux/toshiba.h -'u' 00-1F linux/smb_fs.h +'u' 00-1F linux/smb_fs.h gone 'v' all linux/videodev.h conflict! 'v' 00-1F linux/ext2_fs.h conflict! 'v' 00-1F linux/fs.h conflict! -- cgit v1.1 From 5793210cb1a431f98c85803920d5ba1440c6246e Mon Sep 17 00:00:00 2001 From: matt mooney Date: Fri, 1 Oct 2010 21:21:55 -0700 Subject: Documentation/kbuild: modules.txt cleanup A few modifications done for consistency, such as adding the shell prompt for command line examples and trailing slash for directories. Also corrects the module include header and fixes a few grammar issues that I introduced. Signed-off-by: matt mooney Signed-off-by: Michal Marek --- Documentation/kbuild/modules.txt | 62 +++++++++++++++++++++------------------- 1 file changed, 32 insertions(+), 30 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt index b572db3..3fb39e0 100644 --- a/Documentation/kbuild/modules.txt +++ b/Documentation/kbuild/modules.txt @@ -1,11 +1,11 @@ Building External Modules -This document describes how-to build an out-of-tree kernel module. +This document describes how to build an out-of-tree kernel module. === Table of Contents === 1 Introduction - === 2 How-to Build External Modules + === 2 How to Build External Modules --- 2.1 Command Syntax --- 2.2 Options --- 2.3 Targets @@ -48,9 +48,9 @@ easily accomplished, and a complete example will be presented in section 3. -=== 2. How-to Build External Modules +=== 2. How to Build External Modules -To build external modules, you must have a pre-built kernel available +To build external modules, you must have a prebuilt kernel available that contains the configuration and header files used in the build. Also, the kernel must have been built with modules enabled. If you are using a distribution kernel, there will be a package for the kernel you @@ -69,19 +69,19 @@ executed to make module versioning work. The command to build an external module is: - make -C M=$PWD + $ make -C M=$PWD The kbuild system knows that an external module is being built due to the "M=" option given in the command. To build against the running kernel use: - make -C /lib/modules/`uname -r`/build M=$PWD + $ make -C /lib/modules/`uname -r`/build M=$PWD Then to install the module(s) just built, add the target "modules_install" to the command: - make -C /lib/modules/`uname -r`/build M=$PWD modules_install + $ make -C /lib/modules/`uname -r`/build M=$PWD modules_install --- 2.2 Options @@ -121,7 +121,7 @@ executed to make module versioning work. modules_install Install the external module(s). The default location is - /lib/modules//extra, but a prefix may + /lib/modules//extra/, but a prefix may be added with INSTALL_MOD_PATH (discussed in section 5). clean @@ -164,7 +164,7 @@ needed listing the files: NOTE: Further documentation describing the syntax used by kbuild is located in Documentation/kbuild/makefiles.txt. -The examples below demonstrate how-to create a build file for the +The examples below demonstrate how to create a build file for the module 8123.ko, which is built from the following files: 8123_if.c @@ -205,14 +205,14 @@ module 8123.ko, which is built from the following files: of the makefile. In the example, kbuild will only see the two assignments, whereas "make" will see everything except these two assignments. This is due to two passes made on the file: - the first pass is by the "make" instance run on the - command line; the second pass is by the kbuild system, which is + the first pass is by the "make" instance run on the command + line; the second pass is by the kbuild system, which is initiated by the parameterized "make" in the default target. --- 3.2 Separate Kbuild File and Makefile In newer versions of the kernel, kbuild will first look for a - file named "Kbuild", and only if that is not found, will it + file named "Kbuild," and only if that is not found, will it then look for a makefile. Utilizing a "Kbuild" file allows us to split up the makefile from example 1 into two files: @@ -288,8 +288,8 @@ module 8123.ko, which is built from the following files: --- 3.4 Building Multiple Modules kbuild supports building multiple modules with a single build - file. For example, if you want to build two modules, foo and - bar, the kbuild lines would be: + file. For example, if you wanted to build two modules, foo.ko + and bar.ko, the kbuild lines would be: obj-m := foo.o bar.o foo-y := @@ -320,7 +320,7 @@ according to the following rule: To include a header file located under include/linux/, simply use: - #include + #include kbuild will add options to "gcc" so the relevant directories are searched. @@ -330,7 +330,7 @@ according to the following rule: External modules tend to place header files in a separate include/ directory where their source is located, although this is not the usual kernel style. To inform kbuild of the - directory use either ccflags-y or CFLAGS_.o. + directory, use either ccflags-y or CFLAGS_.o. Using the example from section 3, if we moved 8123_if.h to a subdirectory named include, the resulting kbuild file would @@ -390,11 +390,11 @@ according to the following rule: Modules which are included in the kernel are installed in the directory: - /lib/modules/$(KERNELRELEASE)/kernel + /lib/modules/$(KERNELRELEASE)/kernel/ And external modules are installed in: - /lib/modules/$(KERNELRELEASE)/extra + /lib/modules/$(KERNELRELEASE)/extra/ --- 5.1 INSTALL_MOD_PATH @@ -403,7 +403,7 @@ And external modules are installed in: installation path using the variable INSTALL_MOD_PATH: $ make INSTALL_MOD_PATH=/frodo modules_install - => Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel + => Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel/ INSTALL_MOD_PATH may be set as an ordinary shell variable or, as shown above, can be specified on the command line when @@ -413,14 +413,14 @@ And external modules are installed in: --- 5.2 INSTALL_MOD_DIR External modules are by default installed to a directory under - /lib/modules/$(KERNELRELEASE)/extra, but you may wish to locate - modules for a specific functionality in a separate directory. - For this purpose, use INSTALL_MOD_DIR to specify an alternative - name to "extra." + /lib/modules/$(KERNELRELEASE)/extra/, but you may wish to + locate modules for a specific functionality in a separate + directory. For this purpose, use INSTALL_MOD_DIR to specify an + alternative name to "extra." $ make INSTALL_MOD_DIR=gandalf -C $KDIR \ M=$PWD modules_install - => Install dir: /lib/modules/$(KERNELRELEASE)/gandalf + => Install dir: /lib/modules/$(KERNELRELEASE)/gandalf/ === 6. Module Versioning @@ -478,9 +478,9 @@ build. Use a top-level kbuild file If you have two modules, foo.ko and bar.ko, where - foo.ko needs symbols from bar.ko, then you can use a + foo.ko needs symbols from bar.ko, you can use a common top-level kbuild file so both modules are - compiled in the same build. Consider following + compiled in the same build. Consider the following directory layout: ./foo/ <= contains foo.ko @@ -491,10 +491,11 @@ build. #./Kbuild (or ./Makefile): obj-y := foo/ bar/ - And executing: + And executing + $ make -C $KDIR M=$PWD - Will then do the expected and compile both modules with + will then do the expected and compile both modules with full knowledge of symbols from either module. Use an extra Module.symvers file @@ -512,10 +513,11 @@ build. Use "make" variable KBUILD_EXTRA_SYMBOLS If it is impractical to copy Module.symvers from another module, you can assign a space separated list - of files to KBUILD_EXTRA_SYMBOLS in your build - file. These files will be loaded by modpost during the + of files to KBUILD_EXTRA_SYMBOLS in your build file. + These files will be loaded by modpost during the initialization of its symbol tables. + === 7. Tips & Tricks --- 7.1 Testing for CONFIG_FOO_BAR -- cgit v1.1 From c4b8c01112a16f3cb8a4bffb11b89f2df079f904 Mon Sep 17 00:00:00 2001 From: Jeff Kirsher Date: Tue, 5 Oct 2010 01:16:44 +0000 Subject: ixgbevf.txt: Update ixgbevf documentation Update the documentation for the ixgbevf (ixgbe virtual function driver). Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller --- Documentation/networking/ixgbevf.txt | 40 +++--------------------------------- 1 file changed, 3 insertions(+), 37 deletions(-) mode change 100755 => 100644 Documentation/networking/ixgbevf.txt (limited to 'Documentation') diff --git a/Documentation/networking/ixgbevf.txt b/Documentation/networking/ixgbevf.txt old mode 100755 new mode 100644 index 19015de..21dd5d1 --- a/Documentation/networking/ixgbevf.txt +++ b/Documentation/networking/ixgbevf.txt @@ -1,19 +1,16 @@ Linux* Base Driver for Intel(R) Network Connection ================================================== -November 24, 2009 +Intel Gigabit Linux driver. +Copyright(c) 1999 - 2010 Intel Corporation. Contents ======== -- In This Release - Identifying Your Adapter - Known Issues/Troubleshooting - Support -In This Release -=============== - This file describes the ixgbevf Linux* Base Driver for Intel Network Connection. @@ -33,7 +30,7 @@ Identifying Your Adapter For more information on how to identify your adapter, go to the Adapter & Driver ID Guide at: - http://support.intel.com/support/network/sb/CS-008441.htm + http://support.intel.com/support/go/network/adapter/idguide.htm Known Issues/Troubleshooting ============================ @@ -57,34 +54,3 @@ or the Intel Wired Networking project hosted by Sourceforge at: If an issue is identified with the released source code on the supported kernel with a supported adapter, email the specific information related to the issue to e1000-devel@lists.sf.net - -License -======= - -Intel 10 Gigabit Linux driver. -Copyright(c) 1999 - 2009 Intel Corporation. - -This program is free software; you can redistribute it and/or modify it -under the terms and conditions of the GNU General Public License, -version 2, as published by the Free Software Foundation. - -This program is distributed in the hope 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., -51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA. - -The full GNU General Public License is included in this distribution in -the file called "COPYING". - -Trademarks -========== - -Intel, Itanium, and Pentium are trademarks or registered trademarks of -Intel Corporation or its subsidiaries in the United States and other -countries. - -* Other names and brands may be claimed as the property of others. -- cgit v1.1 From 2bff89c3f340776398bfaf6c94404ffcd09f6e77 Mon Sep 17 00:00:00 2001 From: Jeff Kirsher Date: Tue, 5 Oct 2010 01:17:05 +0000 Subject: e1000.txt: Update e1000 documentation Updated the e1000 networking driver documentation. Signed-off-by: Jeff Kirsher Signed-off-by: David S. Miller --- Documentation/networking/e1000.txt | 373 ++++++++++--------------------------- 1 file changed, 96 insertions(+), 277 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.txt index 2df7186..d9271e7 100644 --- a/Documentation/networking/e1000.txt +++ b/Documentation/networking/e1000.txt @@ -1,82 +1,35 @@ Linux* Base Driver for the Intel(R) PRO/1000 Family of Adapters =============================================================== -September 26, 2006 - +Intel Gigabit Linux driver. +Copyright(c) 1999 - 2010 Intel Corporation. Contents ======== -- In This Release - Identifying Your Adapter -- Building and Installation - Command Line Parameters - Speed and Duplex Configuration - Additional Configurations -- Known Issues - Support - -In This Release -=============== - -This file describes the Linux* Base Driver for the Intel(R) PRO/1000 Family -of Adapters. This driver includes support for Itanium(R)2-based systems. - -For questions related to hardware requirements, refer to the documentation -supplied with your Intel PRO/1000 adapter. All hardware requirements listed -apply to use with Linux. - -The following features are now available in supported kernels: - - Native VLANs - - Channel Bonding (teaming) - - SNMP - -Channel Bonding documentation can be found in the Linux kernel source: -/Documentation/networking/bonding.txt - -The driver information previously displayed in the /proc filesystem is not -supported in this release. Alternatively, you can use ethtool (version 1.6 -or later), lspci, and ifconfig to obtain the same information. - -Instructions on updating ethtool can be found in the section "Additional -Configurations" later in this document. - -NOTE: The Intel(R) 82562v 10/100 Network Connection only provides 10/100 -support. - - Identifying Your Adapter ======================== For more information on how to identify your adapter, go to the Adapter & Driver ID Guide at: - http://support.intel.com/support/network/adapter/pro100/21397.htm + http://support.intel.com/support/go/network/adapter/idguide.htm For the latest Intel network drivers for Linux, refer to the following website. In the search field, enter your adapter name or type, or use the networking link on the left to search for your adapter: - http://downloadfinder.intel.com/scripts-df/support_intel.asp - + http://support.intel.com/support/go/network/adapter/home.htm Command Line Parameters ======================= -If the driver is built as a module, the following optional parameters -are used by entering them on the command line with the modprobe command -using this syntax: - - modprobe e1000 [
+
+ V4L2 in Linux 2.6.37 + + + Remove the vtx (videotext/teletext) API. This API was no longer +used and no hardware exists to verify the API. Nor were any userspace applications found +that used it. It was originally scheduled for removal in 2.6.35. + + + +
Relation of V4L2 to other Linux multimedia APIs diff --git a/Documentation/DocBook/v4l/dev-teletext.xml b/Documentation/DocBook/v4l/dev-teletext.xml index 76184e8..414b1cf 100644 --- a/Documentation/DocBook/v4l/dev-teletext.xml +++ b/Documentation/DocBook/v4l/dev-teletext.xml @@ -1,35 +1,32 @@ Teletext Interface - This interface aims at devices receiving and demodulating + This interface was aimed at devices receiving and demodulating Teletext data [, ], evaluating the Teletext packages and storing formatted pages in cache memory. Such devices are usually implemented as microcontrollers with serial -interface (I2C) and can be found on older +interface (I2C) and could be found on old TV cards, dedicated Teletext decoding cards and home-brew devices connected to the PC parallel port. - The Teletext API was designed by Martin Buck. It is defined in + The Teletext API was designed by Martin Buck. It was defined in the kernel header file linux/videotext.h, the specification is available from ftp://ftp.gwdg.de/pub/linux/misc/videotext/. (Videotext is the name of -the German public television Teletext service.) Conventional character -device file names are /dev/vtx and -/dev/vttuner, with device number 83, 0 and 83, 16 -respectively. A similar interface exists for the Philips SAA5249 -Teletext decoder [specification?] with character device file names -/dev/tlkN, device number 102, N. +the German public television Teletext service.) Eventually the Teletext API was integrated into the V4L API with character device file names /dev/vtx0 to /dev/vtx31, device major number 81, minor numbers -192 to 223. For reference the V4L Teletext API specification is -reproduced here in full: "Teletext interfaces talk the existing VTX -API." Teletext devices with major number 83 and 102 will be removed in -Linux 2.6. +192 to 223. - There are no plans to replace the Teletext API or to integrate -it into V4L2. Please write to the linux-media mailing list: &v4l-ml; -when the need arises. + However, teletext decoders were quickly replaced by more +generic VBI demodulators and those dedicated teletext decoders no longer exist. +For many years the vtx devices were still around, even though nobody used +them. So the decision was made to finally remove support for the Teletext API in +kernel 2.6.37. + + Modern devices all use the raw or +sliced VBI API. + 2.6.37 + 2010-08-06 + hv + Removed obsolete vtx (videotext) API. + + + 2.6.33 2009-12-03 mk diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 842aa9d..2372fb2 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -498,29 +498,6 @@ When: April 2011 Why: Superseded by xt_CT Who: Netfilter developer team ---------------------------- - -What: video4linux /dev/vtx teletext API support -When: 2.6.35 -Files: drivers/media/video/saa5246a.c drivers/media/video/saa5249.c - include/linux/videotext.h -Why: The vtx device nodes have been superseded by vbi device nodes - for many years. No applications exist that use the vtx support. - Of the two i2c drivers that actually support this API the saa5249 - has been impossible to use for a year now and no known hardware - that supports this device exists. The saa5246a is theoretically - supported by the old mxb boards, but it never actually worked. - - In summary: there is no hardware that can use this API and there - are no applications actually implementing this API. - - The vtx support still reserves minors 192-223 and we would really - like to reuse those for upcoming new functionality. In the unlikely - event that new hardware appears that wants to use the functionality - provided by the vtx API, then that functionality should be build - around the sliced VBI API instead. -Who: Hans Verkuil - ---------------------------- What: IRQF_DISABLED diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 33223ff..10f5af8 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -278,7 +278,6 @@ Code Seq#(hex) Include File Comments 'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict! 0x80 00-1F linux/fb.h -0x81 00-1F linux/videotext.h 0x88 00-3F media/ovcamchip.h 0x89 00-06 arch/x86/include/asm/sockios.h 0x89 0B-DF linux/sockios.h diff --git a/Documentation/video4linux/bttv/MAKEDEV b/Documentation/video4linux/bttv/MAKEDEV index 9d112f7..093c0cd 100644 --- a/Documentation/video4linux/bttv/MAKEDEV +++ b/Documentation/video4linux/bttv/MAKEDEV @@ -19,7 +19,6 @@ function makedev () { echo "*** new device names ***" makedev video 0 makedev radio 64 -makedev vtx 192 makedev vbi 224 #echo "*** old device names (for compatibility only) ***" diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index f5fdb39..8fb9de4 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -44,8 +44,8 @@ All drivers have the following structure: 2) A way of initializing and commanding sub-devices (if any). -3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX, /dev/radioX and - /dev/vtxX) and keeping track of device-node specific data. +3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX and /dev/radioX) + and keeping track of device-node specific data. 4) Filehandle-specific structs containing per-filehandle data; @@ -488,7 +488,6 @@ types exist: VFL_TYPE_GRABBER: videoX for video input/output devices VFL_TYPE_VBI: vbiX for vertical blank data (i.e. closed captions, teletext) VFL_TYPE_RADIO: radioX for radio tuners -VFL_TYPE_VTX: vtxX for teletext devices (deprecated, don't use) The last argument gives you a certain amount of control over the device device node number used (i.e. the X in videoX). Normally you will pass -1 -- cgit v1.1 From 87660547def9d343dd5d21644b7a79a15a9b83c1 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 4 Sep 2010 00:53:30 -0300 Subject: devices.txt: Remove the old obsolete vtx device nodes Teletext interface is provided via VBI interface for a long time. There's no need nor is there any known program using those old /dev/vtx nodes. Signed-off-by: Mauro Carvalho Chehab --- Documentation/devices.txt | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devices.txt b/Documentation/devices.txt index d0d1df6..76b1d2f 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -1495,9 +1495,6 @@ Your cooperation is appreciated. 64 = /dev/radio0 Radio device ... 127 = /dev/radio63 Radio device - 192 = /dev/vtx0 Teletext device - ... - 223 = /dev/vtx31 Teletext device 224 = /dev/vbi0 Vertical blank interrupt ... 255 = /dev/vbi31 Vertical blank interrupt -- cgit v1.1 From 860e7f474cb5bd9a691ebde302ac094093a1f5a7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jean-Fran=C3=A7ois=20Moine?= Date: Mon, 13 Sep 2010 06:40:17 -0300 Subject: V4L/DVB: gspca - sonixj: Webcam 0c45:6102 added MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Tested-by: Simon Danner Signed-off-by: Jean-François Moine Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/gspca.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index 56ba7bb..3a2f407 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt @@ -302,6 +302,7 @@ sonixj 0c45:60fb Surfer NoName sonixj 0c45:60fc LG-LIC300 sonixj 0c45:60fe Microdia Audio sonixj 0c45:6100 PC Camera (SN9C128) +sonixj 0c45:6102 PC Camera (SN9C128) sonixj 0c45:610a PC Camera (SN9C128) sonixj 0c45:610b PC Camera (SN9C128) sonixj 0c45:610c PC Camera (SN9C128) -- cgit v1.1 From 2a3b501ffd28b2be355f558479543028ccdead48 Mon Sep 17 00:00:00 2001 From: Alexander Goncharov Date: Mon, 13 Sep 2010 06:58:16 -0300 Subject: V4L/DVB: gspca - sonixj: Add webcam 0c45:612b MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Alexander Goncharov Signed-off-by: Jean-François Moine Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/gspca.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index 3a2f407..6a562ee 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt @@ -309,6 +309,7 @@ sonixj 0c45:610c PC Camera (SN9C128) sonixj 0c45:610e PC Camera (SN9C128) sonixj 0c45:6128 Microdia/Sonix SNP325 sonixj 0c45:612a Avant Camera +sonixj 0c45:612b Speed-Link REFLECT2 sonixj 0c45:612c Typhoon Rasy Cam 1.3MPix sonixj 0c45:6130 Sonix Pccam sonixj 0c45:6138 Sn9c120 Mo4000 -- cgit v1.1 From 008d35f2f5256751a18f1f4aea79e3caf140098d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jean-Fran=C3=A7ois=20Moine?= Date: Mon, 13 Sep 2010 07:04:49 -0300 Subject: V4L/DVB: v4l2: Add illuminator controls MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Some media devices (microscopes) may have one or many illuminators. This patch makes them controlable by the applications. Acked-by: Hans Verkuil Acked-by: Andy Walls Signed-off-by: Jean-François Moine Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/controls.xml | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index 8408caa..68c8344 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -312,10 +312,17 @@ minimum value disables backlight compensation. information and bits 24-31 must be zero. + V4L2_CID_ILLUMINATORS_1 + V4L2_CID_ILLUMINATORS_2 + boolean + Switch on or off the illuminator 1 or 2 of the device + (usually a microscope). + + V4L2_CID_LASTP1 End of the predefined control IDs (currently -V4L2_CID_BG_COLOR + 1). +V4L2_CID_ILLUMINATORS_2 + 1). V4L2_CID_PRIVATE_BASE -- cgit v1.1 From 5e765c6e445da16527a04aa3931f21e5deb476d8 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Sat, 11 Sep 2010 08:36:55 -0300 Subject: V4L/DVB: V4L Doc: fix DocBook syntax errors Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/pixfmt.xml | 4 ++-- Documentation/DocBook/v4l/vidioc-g-dv-preset.xml | 3 +-- Documentation/DocBook/v4l/vidioc-g-dv-timings.xml | 3 +-- Documentation/DocBook/v4l/vidioc-query-dv-preset.xml | 2 +- 4 files changed, 5 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/pixfmt.xml b/Documentation/DocBook/v4l/pixfmt.xml index 5376aef..f4cc0a9 100644 --- a/Documentation/DocBook/v4l/pixfmt.xml +++ b/Documentation/DocBook/v4l/pixfmt.xml @@ -787,14 +787,14 @@ http://www.thedirks.org/winnov/ 'TM60' Used by Trident tm6000 - + V4L2_PIX_FMT_CIT_YYVYUY 'CITV' Used by xirlink CIT, found at IBM webcams. Uses one line of Y then 1 line of VYUY - + V4L2_PIX_FMT_KONICA420 'KONI' Used by Konica webcams. diff --git a/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml b/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml index 3c6784e..d733721 100644 --- a/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml +++ b/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml @@ -16,8 +16,7 @@ int ioctl int fd int request - &v4l2-dv-preset; -*argp + struct v4l2_dv_preset *argp diff --git a/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml b/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml index ecc1957..d5ec6ab 100644 --- a/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml +++ b/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml @@ -16,8 +16,7 @@ int ioctl int fd int request - &v4l2-dv-timings; -*argp + struct v4l2_dv_timings *argp diff --git a/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml b/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml index 402229e..d272f7a 100644 --- a/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml +++ b/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml @@ -16,7 +16,7 @@ input int ioctl int fd int request - &v4l2-dv-preset; *argp + struct v4l2_dv_preset *argp -- cgit v1.1 From 0827d0664dfa046dc9359c1a45f613d916431ed7 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Sat, 11 Sep 2010 08:39:47 -0300 Subject: V4L/DVB: V4L Doc: document V4L2_CAP_RDS_OUTPUT capability We forgot to add this capability to the QUERYCAP documentation. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/vidioc-querycap.xml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/vidioc-querycap.xml b/Documentation/DocBook/v4l/vidioc-querycap.xml index 6ab7e25..d499da9 100644 --- a/Documentation/DocBook/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/v4l/vidioc-querycap.xml @@ -184,7 +184,7 @@ data. V4L2_CAP_RDS_CAPTURE 0x00000100 - The device supports the RDS interface. + The device supports the RDS capture interface. V4L2_CAP_VIDEO_OUTPUT_OVERLAY @@ -206,6 +206,11 @@ driver capabilities. hardware frequency seeking. + V4L2_CAP_RDS_OUTPUT + 0x00000800 + The device supports the RDS output interface. + + V4L2_CAP_TUNER 0x00010000 The device has some sort of tuner to -- cgit v1.1 From 6756207a71a0f976ab027186d0966a2162aaf922 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Sat, 11 Sep 2010 11:38:51 -0300 Subject: V4L/DVB: V4L Doc: correct the documentation for VIDIOC_QUERYMENU The VIDIOC_QUERYMENU documentation was not correct. EINVAL can be returned if the driver does not support some of the menu items. I.e. in a list of MPEG bitrates a driver generally supports only a subset of these. This behavior has been in place for years, but was never properly documented. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/controls.xml | 3 --- Documentation/DocBook/v4l/vidioc-queryctrl.xml | 18 ++++++++++++------ 2 files changed, 12 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index 68c8344..2fae3e8 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml @@ -364,9 +364,6 @@ enumerate_menu (void) querymenu.index++) { if (0 == ioctl (fd, &VIDIOC-QUERYMENU;, &querymenu)) { printf (" %s\n", querymenu.name); - } else { - perror ("VIDIOC_QUERYMENU"); - exit (EXIT_FAILURE); } } } diff --git a/Documentation/DocBook/v4l/vidioc-queryctrl.xml b/Documentation/DocBook/v4l/vidioc-queryctrl.xml index 8e0e055..0d5e828 100644 --- a/Documentation/DocBook/v4l/vidioc-queryctrl.xml +++ b/Documentation/DocBook/v4l/vidioc-queryctrl.xml @@ -103,8 +103,12 @@ structure. The driver fills the rest of the structure or returns an index is invalid. Menu items are enumerated by calling VIDIOC_QUERYMENU with successive index values from &v4l2-queryctrl; -minimum (0) to -maximum, inclusive. +minimum to +maximum, inclusive. Note that it is possible +for VIDIOC_QUERYMENU to return an &EINVAL; for some +indices between minimum and maximum. +In that case that particular menu item is not supported by this driver. Also note that +the minimum value is not necessarily 0. See also the examples in . @@ -139,7 +143,7 @@ string. This information is intended for the user. minimum Minimum value, inclusive. This field gives a lower bound for V4L2_CTRL_TYPE_INTEGER controls and the -lowest valid index (always 0) for V4L2_CTRL_TYPE_MENU controls. +lowest valid index for V4L2_CTRL_TYPE_MENU controls. For V4L2_CTRL_TYPE_STRING controls the minimum value gives the minimum length of the string. This length does not include the terminating zero. It may not be valid for any other type of control, including @@ -279,7 +283,7 @@ values which are actually different on the hardware. V4L2_CTRL_TYPE_MENU - 0 + ≥ 0 1 N-1 The control has a menu of N choices. The names of @@ -405,8 +409,10 @@ writing a value will cause the device to carry out a given action EINVAL The &v4l2-queryctrl; id -is invalid. The &v4l2-querymenu; id or -index is invalid. +is invalid. The &v4l2-querymenu; id is +invalid or index is out of range (less than +minimum or greater than maximum) +or this particular menu item is not supported by the driver. -- cgit v1.1 From a1de2e4b72f27b906cb2eea3003fd62377dbf5ea Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Sat, 11 Sep 2010 07:05:47 -0300 Subject: V4L/DVB: V4L Doc: removed duplicate link Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/pixfmt-packed-rgb.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/pixfmt-packed-rgb.xml b/Documentation/DocBook/v4l/pixfmt-packed-rgb.xml index 26e8792..4db272b 100644 --- a/Documentation/DocBook/v4l/pixfmt-packed-rgb.xml +++ b/Documentation/DocBook/v4l/pixfmt-packed-rgb.xml @@ -739,7 +739,7 @@ defined in error. Drivers may interpret them as in b1 b0 - + V4L2_PIX_FMT_BGR666 'BGRH' -- cgit v1.1 From 7af97effb3f5a374482179aca490b5038de56fa6 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 30 Sep 2010 08:25:42 -0300 Subject: V4L/DVB: Deprecate cpia driver (used for parallel port webcams) cpia driver were re-written inside gspca driver, for USB devices. The only functionality that were not migrated is the support for parallel port, as: 1) the developer didn't find any hardware; 2) it doesn't seem important to keep support for a parallel port webcam, as this is an obsolete technology; 3) the changes at gspca for it to work with parallel port would be very large; 4) this driver still uses BKL. So, let's move it to drivers/staging and label it to die at 2.6.38, if nobody cares enough to port parallel port support to gspca or to create a new driver that uses the same gspca-cpia sub-driver. Signed-off-by: Mauro Carvalho Chehab --- Documentation/feature-removal-schedule.txt | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 2372fb2..4487225 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -98,7 +98,7 @@ Who: Pavel Machek --------------------------- What: Video4Linux API 1 ioctls and from Video devices. -When: July 2009 +When: kernel 2.6.38 Files: include/linux/videodev.h Check: include/linux/videodev.h Why: V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6 @@ -116,6 +116,21 @@ Who: Mauro Carvalho Chehab --------------------------- +What: Video4Linux obsolete drivers using V4L1 API +When: kernel 2.6.38 +Files: drivers/staging/cpia/* +Check: drivers/staging/cpia/cpia.c +Why: There are some drivers still using V4L1 API, despite all efforts we've done + to migrate. Those drivers are for obsolete hardware that the old maintainer + didn't care (or not have the hardware anymore), and that no other developer + could find any hardware to buy. They probably have no practical usage today, + and people with such old hardware could probably keep using an older version + of the kernel. Those drivers will be moved to staging on 2.6.37 and, if nobody + care enough to port and test them with V4L2 API, they'll be removed on 2.6.38. +Who: Mauro Carvalho Chehab + +--------------------------- + What: sys_sysctl When: September 2010 Option: CONFIG_SYSCTL_SYSCALL -- cgit v1.1 From 96322b80e29802d2d3087987f6dc4e5aa19df64b Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 30 Sep 2010 08:26:28 -0300 Subject: V4L/DVB: Deprecate stradis driver The driver author seems to not worked on this driver since its conversion from 2.2 to 2.4. Nobody is known to have a stradis hardware for testing. As it still uses V4L1 API, BKL and probably some other old stuff, someone would need to work on it to preserve the driver. Instead of investing time and efforts to keep porting it to work with new API's, it seems better to just drop the driver. So, let's move it to drivers/staging and label it to die at 2.6.38, if nobody cares enough to port parallel port support to gspca or to create a new driver that uses the same gspca-cpia sub-driver. Signed-off-by: Mauro Carvalho Chehab --- Documentation/feature-removal-schedule.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 4487225..d87ee17 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -118,8 +118,8 @@ Who: Mauro Carvalho Chehab What: Video4Linux obsolete drivers using V4L1 API When: kernel 2.6.38 -Files: drivers/staging/cpia/* -Check: drivers/staging/cpia/cpia.c +Files: drivers/staging/cpia/* drivers/staging/stradis/* +Check: drivers/staging/cpia/cpia.c drivers/staging/stradis/stradis.c Why: There are some drivers still using V4L1 API, despite all efforts we've done to migrate. Those drivers are for obsolete hardware that the old maintainer didn't care (or not have the hardware anymore), and that no other developer -- cgit v1.1 From d69f27186c16008540166c8017e9d4db2b477588 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Sun, 26 Sep 2010 08:16:56 -0300 Subject: V4L/DVB: v4l2-dev: after a disconnect any ioctl call will be blocked Until now all fops except release and (unlocked_)ioctl returned an error after the device node was unregistered. Extend this as well to the ioctl fops. There is nothing useful that an application can do here and it complicates the driver code unnecessarily. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 8fb9de4..9b1d81c 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -551,9 +551,8 @@ from /dev). After video_unregister_device() returns no new opens can be done. However, in the case of USB devices some application might still have one of these -device nodes open. So after the unregister all file operations will return -an error as well, except for the ioctl and unlocked_ioctl file operations: -those will still be passed on since some buffer ioctls may still be needed. +device nodes open. So after the unregister all file operations (except +release, of course) will return an error as well. When the last user of the video device node exits, then the vdev->release() callback is called and you can do the final cleanup there. -- cgit v1.1 From ee6869afc922a9849979e49bb3bbcad794872fcb Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Sun, 26 Sep 2010 08:47:38 -0300 Subject: V4L/DVB: v4l2: add core serialization lock Drivers can optionally set a pointer to a mutex in struct video_device. The core will use that to lock before calling open, read, write, unlocked_ioctl, poll, mmap or release. Updated the documentation as well and ensure that v4l2-event knows about the lock: it will unlock it before doing a blocking wait on an event and relock it afterwards. Ensure that the 'video_is_registered' check is done when the lock is held: a typical disconnect will take the lock as well before unregistering the device nodes, so to prevent race conditions the video_is_registered check should also be done with the lock held. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 9b1d81c..a128e01 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -453,6 +453,10 @@ You should also set these fields: - ioctl_ops: if you use the v4l2_ioctl_ops to simplify ioctl maintenance (highly recommended to use this and it might become compulsory in the future!), then set this to your v4l2_ioctl_ops struct. +- lock: leave to NULL if you want to do all the locking in the driver. + Otherwise you give it a pointer to a struct mutex_lock and before any + of the v4l2_file_operations is called this lock will be taken by the + core and released afterwards. - parent: you only set this if v4l2_device was registered with NULL as the parent device struct. This only happens in cases where one hardware device has multiple PCI devices that all share the same v4l2_device core. @@ -469,6 +473,22 @@ If you use v4l2_ioctl_ops, then you should set either .unlocked_ioctl or The v4l2_file_operations struct is a subset of file_operations. The main difference is that the inode argument is omitted since it is never used. +v4l2_file_operations and locking +-------------------------------- + +You can set a pointer to a mutex_lock in struct video_device. Usually this +will be either a top-level mutex or a mutex per device node. If you want +finer-grained locking then you have to set it to NULL and do you own locking. + +If a lock is specified then all file operations will be serialized on that +lock. If you use videobuf then you must pass the same lock to the videobuf +queue initialize function: if videobuf has to wait for a frame to arrive, then +it will temporarily unlock the lock and relock it afterwards. If your driver +also waits in the code, then you should do the same to allow other processes +to access the device node while the first process is waiting for something. + +The implementation of a hotplug disconnect should also take the lock before +calling v4l2_device_disconnect and video_unregister_device. video_device registration ------------------------- -- cgit v1.1 From 9c84d89bf13b702ca0e0db5eb3880300c4bd58f4 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Mon, 11 Oct 2010 12:36:37 -0300 Subject: [media] radio-mr800: fix locking order Don't hold the lock before unregistering the device, since when the device is unregistered the datastruct containing the lock may be freed (if the refcount went to 0). Also fixed the framework documentation that erroneously suggested the wrong locking order as well. Reported-by: David Ellingsworth Signed-off-by: Hans Verkuil Acked-by: David Ellingsworth Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/v4l2-framework.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index a128e01..f22f35c 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -488,7 +488,7 @@ also waits in the code, then you should do the same to allow other processes to access the device node while the first process is waiting for something. The implementation of a hotplug disconnect should also take the lock before -calling v4l2_device_disconnect and video_unregister_device. +calling v4l2_device_disconnect. video_device registration ------------------------- -- cgit v1.1 From 1e55659ce6ddb5247cee0b1f720d77a799902b85 Mon Sep 17 00:00:00 2001 From: Oliver Hartkopp Date: Tue, 19 Oct 2010 09:32:04 +0000 Subject: can-raw: add msg_flags to distinguish local traffic CAN has no addressing scheme. It is currently impossible for userspace to tell is a received CAN frame comes from another process on the local host, or from a remote CAN device. This patch add support for userspace applications to distinguish between 'own', 'local' and 'remote' CAN traffic. The distinction is made by returning flags in msg->msg_flags in the call to recvmsg(). The added documentation explains the introduced flags. Signed-off-by: Kurt Van Dijck Signed-off-by: Oliver Hartkopp Signed-off-by: David S. Miller --- Documentation/networking/can.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index cd79735..5b04b67 100644 --- a/Documentation/networking/can.txt +++ b/Documentation/networking/can.txt @@ -22,6 +22,7 @@ This file contains 4.1.2 RAW socket option CAN_RAW_ERR_FILTER 4.1.3 RAW socket option CAN_RAW_LOOPBACK 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS + 4.1.5 RAW socket returned message flags 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM) 4.3 connected transport protocols (SOCK_SEQPACKET) 4.4 unconnected transport protocols (SOCK_DGRAM) @@ -471,6 +472,17 @@ solution for a couple of reasons: setsockopt(s, SOL_CAN_RAW, CAN_RAW_RECV_OWN_MSGS, &recv_own_msgs, sizeof(recv_own_msgs)); + 4.1.5 RAW socket returned message flags + + When using recvmsg() call, the msg->msg_flags may contain following flags: + + MSG_DONTROUTE: set when the received frame was created on the local host. + + MSG_CONFIRM: set when the frame was sent via the socket it is received on. + This flag can be interpreted as a 'transmission confirmation' when the + CAN driver supports the echo of frames on driver level, see 3.2 and 6.2. + In order to receive such messages, CAN_RAW_RECV_OWN_MSGS must be set. + 4.2 Broadcast Manager protocol sockets (SOCK_DGRAM) 4.3 connected transport protocols (SOCK_SEQPACKET) 4.4 unconnected transport protocols (SOCK_DGRAM) -- cgit v1.1 From 4d1529043705737ba442f5a0048043718e601ce4 Mon Sep 17 00:00:00 2001 From: Mike Snitzer Date: Thu, 21 Oct 2010 14:54:19 +0200 Subject: Added blk-lib.c and blk-barrier.c was renamed to blk-flush.c Signed-off-by: Mike Snitzer Signed-off-by: Jens Axboe --- Documentation/DocBook/kernel-api.tmpl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index 6899f47..6b4e07f 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -257,7 +257,8 @@ X!Earch/x86/kernel/mca_32.c !Iblock/blk-sysfs.c !Eblock/blk-settings.c !Eblock/blk-exec.c -!Eblock/blk-barrier.c +!Eblock/blk-flush.c +!Eblock/blk-lib.c !Eblock/blk-tag.c !Iblock/blk-tag.c !Eblock/blk-integrity.c -- cgit v1.1 From 35f0ce032b0f2d6974da516b5a113f49b7b70b09 Mon Sep 17 00:00:00 2001 From: Vernon Mauery Date: Tue, 5 Oct 2010 15:47:18 -0700 Subject: IBM Real-Time "SMI Free" mode driver -v7 After a period of RFC for this driver, I think it is ready for inclusion in the platform-driver-x86 tree, hopefully to be staged in the next merge window into Linus's tree. --Vernon ------------------------------------------------------------ IBM Real-Time "SMI Free" mode driver This driver supports the Real-Time Linux (RTL) BIOS feature. The RTL feature allows non-fatal System Management Interrupts (SMIs) to be disabled on supported IBM platforms and is intended to be coupled with a user-space daemon to monitor the hardware in a way that can be prioritized and scheduled to better suit the requirements for the system. The Device is presented as a special "_RTL_" table to the OS in the Extended BIOS Data Area. There is a simple protocol for entering and exiting the mode at runtime. This driver creates a simple sysfs interface to allow a simple entry and exit from RTL mode in the UFI/BIOS. Since the driver is specific to IBM SystemX hardware (x86- based servers) it only builds on x86 builds. To reduce the risk of loading on the wrong hardware, the module uses DMI information and checks a list of servers that are known to work. Signed-off-by: Vernon Mauery Signed-off-by: Matthew Garrett --- .../ABI/testing/sysfs-devices-system-ibm-rtl | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-devices-system-ibm-rtl (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-system-ibm-rtl b/Documentation/ABI/testing/sysfs-devices-system-ibm-rtl new file mode 100644 index 0000000..b82deea --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-system-ibm-rtl @@ -0,0 +1,22 @@ +What: state +Date: Sep 2010 +KernelVersion: 2.6.37 +Contact: Vernon Mauery +Description: The state file allows a means by which to change in and + out of Premium Real-Time Mode (PRTM), as well as the + ability to query the current state. + 0 => PRTM off + 1 => PRTM enabled +Users: The ibm-prtm userspace daemon uses this interface. + + +What: version +Date: Sep 2010 +KernelVersion: 2.6.37 +Contact: Vernon Mauery +Description: The version file provides a means by which to query + the RTL table version that lives in the Extended + BIOS Data Area (EBDA). +Users: The ibm-prtm userspace daemon uses this interface. + + -- cgit v1.1 From d9027470b88631d0956ac37cdadfdeb9cdcf2c99 Mon Sep 17 00:00:00 2001 From: Gwendal Grignou Date: Tue, 25 May 2010 12:31:38 -0700 Subject: [libata] Add ATA transport class This is a scheleton for libata transport class. All information is read only, exporting information from libata: - ata_port class: one per ATA port - ata_link class: one per ATA port or 15 for SATA Port Multiplier - ata_device class: up to 2 for PATA link, usually one for SATA. Signed-off-by: Gwendal Grignou Reviewed-by: Grant Grundler Signed-off-by: Jeff Garzik --- Documentation/ABI/testing/sysfs-ata | 99 +++++++++++++++++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-ata (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-ata b/Documentation/ABI/testing/sysfs-ata new file mode 100644 index 0000000..0a93215 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-ata @@ -0,0 +1,99 @@ +What: /sys/class/ata_... +Date: August 2008 +Contact: Gwendal Grignou +Description: + +Provide a place in sysfs for storing the ATA topology of the system. This allows +retrieving various information about ATA objects. + +Files under /sys/class/ata_port +------------------------------- + + For each port, a directory ataX is created where X is the ata_port_id of + the port. The device parent is the ata host device. + +idle_irq (read) + + Number of IRQ received by the port while idle [some ata HBA only]. + +nr_pmp_links (read) + + If a SATA Port Multiplier (PM) is connected, number of link behind it. + +Files under /sys/class/ata_link +------------------------------- + + Behind each port, there is a ata_link. If there is a SATA PM in the + topology, 15 ata_link objects are created. + + If a link is behind a port, the directory name is linkX, where X is + ata_port_id of the port. + If a link is behind a PM, its name is linkX.Y where X is ata_port_id + of the parent port and Y the PM port. + +hw_sata_spd_limit + + Maximum speed supported by the connected SATA device. + +sata_spd_limit + + Maximum speed imposed by libata. + +sata_spd + + Current speed of the link [1.5, 3Gps,...]. + +Files under /sys/class/ata_device +--------------------------------- + + Behind each link, up to two ata device are created. + The name of the directory is devX[.Y].Z where: + - X is ata_port_id of the port where the device is connected, + - Y the port of the PM if any, and + - Z the device id: for PATA, there is usually 2 devices [0,1], + only 1 for SATA. + +class + Device class. Can be "ata" for disk, "atapi" for packet device, + "pmp" for PM, or "none" if no device was found behind the link. + +dma_mode + + Transfer modes supported by the device when in DMA mode. + Mostly used by PATA device. + +pio_mode + + Transfer modes supported by the device when in PIO mode. + Mostly used by PATA device. + +xfer_mode + + Current transfer mode. + +id + + Cached result of IDENTIFY command, as described in ATA8 7.16 and 7.17. + Only valid if the device is not a PM. + +gscr + + Cached result of the dump of PM GSCR register. + Valid registers are: + 0: SATA_PMP_GSCR_PROD_ID, + 1: SATA_PMP_GSCR_REV, + 2: SATA_PMP_GSCR_PORT_INFO, + 32: SATA_PMP_GSCR_ERROR, + 33: SATA_PMP_GSCR_ERROR_EN, + 64: SATA_PMP_GSCR_FEAT, + 96: SATA_PMP_GSCR_FEAT_EN, + 130: SATA_PMP_GSCR_SII_GPIO + Only valid if the device is a PM. + +spdn_cnt + + Number of time libata decided to lower the speed of link due to errors. + +ering + + Formatted output of the error ring of the device. -- cgit v1.1 From a648ec05bb950fae2f35d0490ddd6cf15010af72 Mon Sep 17 00:00:00 2001 From: Thomas Renninger Date: Fri, 6 Aug 2010 16:11:02 +0200 Subject: Dynamic Debug: Introduce ddebug_query= boot parameter Dynamic debug lacks the ability to enable debug messages at boot time. One could patch initramfs or service startup scripts to write to /sys/../dynamic_debug/control, but this sucks. This patch makes it possible to pass a query in the same format one can write to /sys/../dynamic_debug/control via boot param. When dynamic debug gets initialized, this query will automatically be applied. Signed-off-by: Thomas Renninger Acked-by: jbaron@redhat.com Acked-by: Pekka Enberg Signed-off-by: Greg Kroah-Hartman --- Documentation/dynamic-debug-howto.txt | 22 +++++++++++++++++++++- Documentation/kernel-parameters.txt | 7 ++++++- 2 files changed, 27 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt index 674c566..58ea64a 100644 --- a/Documentation/dynamic-debug-howto.txt +++ b/Documentation/dynamic-debug-howto.txt @@ -24,7 +24,7 @@ Dynamic debug has even more useful features: read to display the complete list of known debug statements, to help guide you Controlling dynamic debug Behaviour -=============================== +=================================== The behaviour of pr_debug()/dev_debug()s are controlled via writing to a control file in the 'debugfs' filesystem. Thus, you must first mount the debugfs @@ -212,6 +212,26 @@ Note the regexp ^[-+=][scp]+$ matches a flags specification. Note also that there is no convenient syntax to remove all the flags at once, you need to use "-psc". + +Debug messages during boot process +================================== + +To be able to activate debug messages during the boot process, +even before userspace and debugfs exists, use the boot parameter: +ddebug_query="QUERY" + +QUERY follows the syntax described above, but must not exceed 1023 +characters. The enablement of debug messages is done as an arch_initcall. +Thus you can enable debug messages in all code processed after this +arch_initcall via this boot parameter. +On an x86 system for example ACPI enablement is a subsys_initcall and +ddebug_query="file ec.c +p" +will show early Embedded Controller transactions during ACPI setup if +your machine (typically a laptop) has an Embedded Controller. +PCI (or other devices) initialization also is a hot candidate for using +this boot parameter for debugging purposes. + + Examples ======== diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 8dd7248..3d854c9 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -43,10 +43,11 @@ parameter is applicable: AVR32 AVR32 architecture is enabled. AX25 Appropriate AX.25 support is enabled. BLACKFIN Blackfin architecture is enabled. - DRM Direct Rendering Management support is enabled. EDD BIOS Enhanced Disk Drive Services (EDD) is enabled EFI EFI Partitioning (GPT) is enabled EIDE EIDE/ATAPI support is enabled. + DRM Direct Rendering Management support is enabled. + DYNAMIC_DEBUG Build in debug messages and enable them at runtime FB The frame buffer device is enabled. GCOV GCOV profiling is enabled. HW Appropriate hardware is enabled. @@ -570,6 +571,10 @@ and is between 256 and 4096 characters. It is defined in the file Format: , See also Documentation/input/joystick-parport.txt + ddebug_query= [KNL,DYNAMIC_DEBUG] Enable debug messages at early boot + time. See Documentation/dynamic-debug-howto.txt for + details. + debug [KNL] Enable kernel debugging (events log level). debug_locks_verbose= -- cgit v1.1 From cf4ece53460c64a04a643ef13f6b6cb4bf3a8342 Mon Sep 17 00:00:00 2001 From: Masayuki Ohtak Date: Wed, 1 Sep 2010 21:16:30 +0900 Subject: add Packet hub driver for Topcliff Platform controller hub Packet hub driver of Topcliff PCH Topcliff PCH is the platform controller hub that is going to be used in Intel's upcoming general embedded platform. All IO peripherals in Topcliff PCH are actually devices sitting on AMBA bus. Packet hub is a special converter device in Topcliff PCH that translate AMBA transactions to PCI Express transactions and vice versa. Thus packet hub helps present all IO peripherals in Topcliff PCH as PCIE devices to IA system. Topcliff PCH has MAC address and Option ROM data. These data are in SROM which is connected to PCIE bus. Packet hub driver of Topcliff PCH can access MAC address and Option ROM data in SROM via sysfs interface. Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-module | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-module (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-module b/Documentation/ABI/testing/sysfs-module new file mode 100644 index 0000000..cfcec3b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-module @@ -0,0 +1,12 @@ +What: /sys/module/pch_phub/drivers/.../pch_mac +Date: August 2010 +KernelVersion: 2.6.35 +Contact: masa-korg@dsn.okisemi.com +Description: Write/read GbE MAC address. + +What: /sys/module/pch_phub/drivers/.../pch_firmware +Date: August 2010 +KernelVersion: 2.6.35 +Contact: masa-korg@dsn.okisemi.com +Description: Write/read Option ROM data. + -- cgit v1.1 From e52eec13cd6b7f30ab19081b387813e03e592ae5 Mon Sep 17 00:00:00 2001 From: Andi Kleen Date: Wed, 8 Sep 2010 16:54:17 +0200 Subject: SYSFS: Allow boot time switching between deprecated and modern sysfs layout I have some systems which need legacy sysfs due to old tools that are making assumptions that a directory can never be a symlink to another directory, and it's a big hazzle to compile separate kernels for them. This patch turns CONFIG_SYSFS_DEPRECATED into a run time option that can be switched on/off the kernel command line. This way the same binary can be used in both cases with just a option on the command line. The old CONFIG_SYSFS_DEPRECATED_V2 option is still there to set the default. I kept the weird name to not break existing config files. Also the compat code can be still completely disabled by undefining CONFIG_SYSFS_DEPRECATED_SWITCH -- just the optimizer takes care of this now instead of lots of ifdefs. This makes the code look nicer. v2: This is an updated version on top of Kay's patch to only handle the block devices. I tested it on my old systems and that seems to work. Cc: axboe@kernel.dk Signed-off-by: Andi Kleen Cc: Kay Sievers Signed-off-by: Greg Kroah-Hartman --- Documentation/kernel-parameters.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 3d854c9..67fa3fd 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2365,6 +2365,15 @@ and is between 256 and 4096 characters. It is defined in the file switches= [HW,M68k] + sysfs.deprecated=0|1 [KNL] + Enable/disable old style sysfs layout for old udev + on older distributions. When this option is enabled + very new udev will not work anymore. When this option + is disabled (or CONFIG_SYSFS_DEPRECATED not compiled) + in older udev will not work anymore. + Default depends on CONFIG_SYSFS_DEPRECATED_V2 set in + the kernel configuration. + sysrq_always_enabled [KNL] Ignore sysrq setting - this boot parameter will -- cgit v1.1 From 24b4b67d17c308aaa956b73ab1e88190f6642bbe Mon Sep 17 00:00:00 2001 From: Samo Pogacnik Date: Wed, 25 Aug 2010 20:44:07 +0200 Subject: add ttyprintk driver Ttyprintk is a pseudo TTY driver, which allows users to make printk messages, via output to ttyprintk device. It is possible to store "console" messages inline with kernel messages for better analyses of the boot process, for example. Signed-off-by: Samo Pogacnik Acked-by: Alan Cox Signed-off-by: Greg Kroah-Hartman --- Documentation/devices.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devices.txt b/Documentation/devices.txt index d0d1df6..6a08fd7 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -239,6 +239,7 @@ Your cooperation is appreciated. 0 = /dev/tty Current TTY device 1 = /dev/console System console 2 = /dev/ptmx PTY master multiplex + 3 = /dev/ttyprintk User messages via printk TTY device 64 = /dev/cua0 Callout device for ttyS0 ... 255 = /dev/cua191 Callout device for ttyS191 -- cgit v1.1 From f4a3e0bceb57466c31757f25e4e0ed108d1299ec Mon Sep 17 00:00:00 2001 From: "Dr. Werner Fink" Date: Wed, 22 Sep 2010 12:45:40 +0200 Subject: tty: Add a new file /proc/tty/consoles Add a new file /proc/tty/consoles to be able to determine the registered system console lines. If the reading process holds /dev/console open at the regular standard input stream the active device will be marked by an asterisk. Show possible operations and also decode the used flags of the listed console lines. Signed-off-by: Werner Fink Cc: Alan Cox Signed-off-by: Greg Kroah-Hartman --- Documentation/filesystems/proc.txt | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index a6aca87..98223a6 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -1075,6 +1075,7 @@ Table 1-11: Files in /proc/tty drivers list of drivers and their usage ldiscs registered line disciplines driver/serial usage statistic and status of single tty lines + consoles registered system console lines .............................................................................. To see which tty's are currently in use, you can simply look into the file @@ -1093,6 +1094,37 @@ To see which tty's are currently in use, you can simply look into the file /dev/tty /dev/tty 5 0 system:/dev/tty unknown /dev/tty 4 1-63 console +To see which character device lines are currently used for the system console +/dev/console, you may simply look into the file /proc/tty/consoles: + + > cat /proc/tty/consoles + tty0 -WU (ECp) 4:7 + ttyS0 -W- (Ep) 4:64 + +The columns are: + + device name of the device + operations R = can do read operations + W = can do write operations + U = can do unblank + flags E = it is enabled + C = it is prefered console + B = it is primary boot console + p = it is used for printk buffer + b = it is not a TTY but a Braille device + a = it is safe to use when cpu is offline + * = it is standard input of the reading process + major:minor major and minor number of the device separated by a colon + +If the reading process holds /dev/console open at the regular standard input +stream the active device will be marked by an asterisk: + + > cat /proc/tty/consoles < /dev/console + tty0 -WU (ECp*) 4:7 + ttyS0 -W- (Ep) 4:64 + > tty + /dev/pts/3 + 1.8 Miscellaneous kernel statistics in /proc/stat ------------------------------------------------- -- cgit v1.1 From 834e2312e7a384877a876b0d34dffc3046c96bcb Mon Sep 17 00:00:00 2001 From: Alan Stern Date: Mon, 13 Sep 2010 10:43:25 -0400 Subject: USB: teach "devices" file about Wireless and SuperSpeed USB The /sys/kernel/debug/usb/devices file doesn't know about Wireless or SuperSpeed USB. This patch (as1416b) teaches it, and updates the Documentation/usb/proc_sub_info.txt file accordingly. Signed-off-by: Alan Stern CC: David Vrabel CC: Sarah Sharp Signed-off-by: Greg Kroah-Hartman --- Documentation/usb/proc_usb_info.txt | 34 ++++++++++++++++++++++------------ 1 file changed, 22 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/usb/proc_usb_info.txt b/Documentation/usb/proc_usb_info.txt index fafcd47..afe596d 100644 --- a/Documentation/usb/proc_usb_info.txt +++ b/Documentation/usb/proc_usb_info.txt @@ -1,12 +1,17 @@ /proc/bus/usb filesystem output =============================== -(version 2003.05.30) +(version 2010.09.13) The usbfs filesystem for USB devices is traditionally mounted at /proc/bus/usb. It provides the /proc/bus/usb/devices file, as well as the /proc/bus/usb/BBB/DDD files. +In many modern systems the usbfs filsystem isn't used at all. Instead +USB device nodes are created under /dev/usb/ or someplace similar. The +"devices" file is available in debugfs, typically as +/sys/kernel/debug/usb/devices. + **NOTE**: If /proc/bus/usb appears empty, and a host controller driver has been linked, then you need to mount the @@ -106,8 +111,8 @@ Legend: Topology info: -T: Bus=dd Lev=dd Prnt=dd Port=dd Cnt=dd Dev#=ddd Spd=ddd MxCh=dd -| | | | | | | | |__MaxChildren +T: Bus=dd Lev=dd Prnt=dd Port=dd Cnt=dd Dev#=ddd Spd=dddd MxCh=dd +| | | | | | | | |__MaxChildren | | | | | | | |__Device Speed in Mbps | | | | | | |__DeviceNumber | | | | | |__Count of devices at this level @@ -120,8 +125,13 @@ T: Bus=dd Lev=dd Prnt=dd Port=dd Cnt=dd Dev#=ddd Spd=ddd MxCh=dd Speed may be: 1.5 Mbit/s for low speed USB 12 Mbit/s for full speed USB - 480 Mbit/s for high speed USB (added for USB 2.0) + 480 Mbit/s for high speed USB (added for USB 2.0); + also used for Wireless USB, which has no fixed speed + 5000 Mbit/s for SuperSpeed USB (added for USB 3.0) + For reasons lost in the mists of time, the Port number is always + too low by 1. For example, a device plugged into port 4 will + show up with "Port=03". Bandwidth info: B: Alloc=ddd/ddd us (xx%), #Int=ddd, #Iso=ddd @@ -291,7 +301,7 @@ Here's an example, from a system which has a UHCI root hub, an external hub connected to the root hub, and a mouse and a serial converter connected to the external hub. -T: Bus=00 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 +T: Bus=00 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 B: Alloc= 28/900 us ( 3%), #Int= 2, #Iso= 0 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0000 ProdID=0000 Rev= 0.00 @@ -301,21 +311,21 @@ C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms -T: Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 +T: Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0451 ProdID=1446 Rev= 1.00 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms -T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 +T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=04b4 ProdID=0001 Rev= 0.00 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=mouse E: Ad=81(I) Atr=03(Int.) MxPS= 3 Ivl= 10ms -T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 +T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0565 ProdID=0001 Rev= 1.08 S: Manufacturer=Peracom Networks, Inc. @@ -330,12 +340,12 @@ E: Ad=82(I) Atr=03(Int.) MxPS= 8 Ivl= 8ms Selecting only the "T:" and "I:" lines from this (for example, by using "procusb ti"), we have: -T: Bus=00 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 -T: Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 +T: Bus=00 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#= 1 Spd=12 MxCh= 2 +T: Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub -T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 +T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=mouse -T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 +T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 I: If#= 0 Alt= 0 #EPs= 3 Cls=00(>ifc ) Sub=00 Prot=00 Driver=serial -- cgit v1.1 From 1b62d2583963d5974974aa923214bada7aa7b5d1 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Thu, 30 Sep 2010 05:01:22 -0700 Subject: USB: yurex: assign a real minor number to the driver This assigns the minor number 192 to the yurex driver. We also fix up the previous usb minor number entry, it was wrong. Cc: Tomoki Sekiyama Signed-off-by: Greg Kroah-Hartman --- Documentation/devices.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devices.txt b/Documentation/devices.txt index d0d1df6..3cab6b3 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -2553,7 +2553,10 @@ Your cooperation is appreciated. 175 = /dev/usb/legousbtower15 16th USB Legotower device 176 = /dev/usb/usbtmc1 First USB TMC device ... - 192 = /dev/usb/usbtmc16 16th USB TMC device + 191 = /dev/usb/usbtmc16 16th USB TMC device + 192 = /dev/usb/yurex1 First USB Yurex device + ... + 209 = /dev/usb/yurex16 16th USB Yurex device 240 = /dev/usb/dabusb0 First daubusb device ... 243 = /dev/usb/dabusb3 Fourth dabusb device -- cgit v1.1 From 230f7ede6c2f0e403f29e03e0251a470aa9350dd Mon Sep 17 00:00:00 2001 From: Anatolij Gustschin Date: Tue, 28 Sep 2010 20:55:21 +0200 Subject: USB: add USB EHCI support for MPC5121 SoC Extends FSL EHCI platform driver glue layer to support MPC5121 USB controllers. MPC5121 Rev 2.0 silicon EHCI registers are in big endian format. The appropriate flags are set using the information in the platform data structure. MPC83xx system interface registers are not available on MPC512x, so the access to these registers is isolated in MPC512x case. Furthermore the USB controller clocks must be enabled before 512x register accesses which is done by providing platform specific init callback. The MPC512x internal USB PHY doesn't provide supply voltage. For boards using different power switches allow specifying DRVVBUS and PWR_FAULT signal polarity of the MPC5121 internal PHY using "fsl,invert-drvvbus" and "fsl,invert-pwr-fault" properties in the device tree USB nodes. Adds documentation for this new device tree bindings. Signed-off-by: Anatolij Gustschin Cc: Grant Likely Signed-off-by: Greg Kroah-Hartman --- Documentation/powerpc/dts-bindings/fsl/usb.txt | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'Documentation') diff --git a/Documentation/powerpc/dts-bindings/fsl/usb.txt b/Documentation/powerpc/dts-bindings/fsl/usb.txt index b001524..bd5723f 100644 --- a/Documentation/powerpc/dts-bindings/fsl/usb.txt +++ b/Documentation/powerpc/dts-bindings/fsl/usb.txt @@ -8,6 +8,7 @@ and additions : Required properties : - compatible : Should be "fsl-usb2-mph" for multi port host USB controllers, or "fsl-usb2-dr" for dual role USB controllers + or "fsl,mpc5121-usb2-dr" for dual role USB controllers of MPC5121 - phy_type : For multi port host USB controllers, should be one of "ulpi", or "serial". For dual role USB controllers, should be one of "ulpi", "utmi", "utmi_wide", or "serial". @@ -33,6 +34,12 @@ Recommended properties : - interrupt-parent : the phandle for the interrupt controller that services interrupts for this device. +Optional properties : + - fsl,invert-drvvbus : boolean; for MPC5121 USB0 only. Indicates the + port power polarity of internal PHY signal DRVVBUS is inverted. + - fsl,invert-pwr-fault : boolean; for MPC5121 USB0 only. Indicates + the PWR_FAULT signal polarity is inverted. + Example multi port host USB controller device node : usb@22000 { compatible = "fsl-usb2-mph"; @@ -57,3 +64,18 @@ Example dual role USB controller device node : dr_mode = "otg"; phy = "ulpi"; }; + +Example dual role USB controller device node for MPC5121ADS: + + usb@4000 { + compatible = "fsl,mpc5121-usb2-dr"; + reg = <0x4000 0x1000>; + #address-cells = <1>; + #size-cells = <0>; + interrupt-parent = < &ipic >; + interrupts = <44 0x8>; + dr_mode = "otg"; + phy_type = "utmi_wide"; + fsl,invert-drvvbus; + fsl,invert-pwr-fault; + }; -- cgit v1.1 From 69194aba3d998af0a51efdf1bde9ce6642b8ab76 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 22 Oct 2010 20:50:50 -0200 Subject: [media] Documentation/video4linux/CARDLIST.[cx88|saa7134] Fix a few troubles at the card entries Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/CARDLIST.cx88 | 1 + Documentation/video4linux/CARDLIST.saa7134 | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88 index f251054..42517d9 100644 --- a/Documentation/video4linux/CARDLIST.cx88 +++ b/Documentation/video4linux/CARDLIST.cx88 @@ -83,3 +83,4 @@ 82 -> WinFast DTV2000 H rev. J [107d:6f2b] 83 -> Prof 7301 DVB-S/S2 [b034:3034] 84 -> Samsung SMT 7020 DVB-S [18ac:dc00,18ac:dccd] + 85 -> Twinhan VP-1027 DVB-S [1822:0023] diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index 4000c29..8d9afc7 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -126,7 +126,7 @@ 125 -> Beholder BeholdTV 409 [0000:4090] 126 -> Beholder BeholdTV 505 FM [5ace:5050] 127 -> Beholder BeholdTV 507 FM / BeholdTV 509 FM [5ace:5070,5ace:5090] -128 -> Beholder BeholdTV Columbus TVFM [0000:5201] +128 -> Beholder BeholdTV Columbus TV/FM [0000:5201] 129 -> Beholder BeholdTV 607 FM [5ace:6070] 130 -> Beholder BeholdTV M6 [5ace:6190] 131 -> Twinhan Hybrid DTV-DVB 3056 PCI [1822:0022] -- cgit v1.1 From 8298f2f810b988dccfa0ab51cd874e107514c036 Mon Sep 17 00:00:00 2001 From: Adrian Taylor Date: Wed, 20 Oct 2010 07:55:33 -0300 Subject: [media] Support for Elgato Video Capture This patch allows this device successfully to show video, at least from its composite input. I have no information about the true hardware contents of this device and so this patch is based solely on fiddling with things until it worked. The chip appears to be em2860, and the closest device with equivalent inputs is the Typhoon DVD Maker. Copying the settings for that device appears to do the trick. That's what this patch does. [mchehab@redhat.com: update CARDLIST.em28xx accordingly, via script] Signed-off-by: Adrian Taylor Reviewed-by: Jarod Wilson Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/CARDLIST.em28xx | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index 5c56875..ac2616a 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx @@ -31,6 +31,7 @@ 30 -> Videology 20K14XUSB USB2.0 (em2820/em2840) 31 -> Usbgear VD204v9 (em2821) 32 -> Supercomp USB 2.0 TV (em2821) + 33 -> Elgato Video Capture (em2860) [0fd9:0033] 34 -> Terratec Cinergy A Hybrid XS (em2860) [0ccd:004f] 35 -> Typhoon DVD Maker (em2860) 36 -> NetGMBH Cam (em2860) @@ -45,7 +46,7 @@ 45 -> Pinnacle PCTV DVB-T (em2870) 46 -> Compro, VideoMate U3 (em2870) [185b:2870] 47 -> KWorld DVB-T 305U (em2880) [eb1a:e305] - 48 -> KWorld DVB-T 310U (em2880) [eb1a:e310] + 48 -> KWorld DVB-T 310U (em2880) 49 -> MSI DigiVox A/D (em2880) [eb1a:e310] 50 -> MSI DigiVox A/D II (em2880) [eb1a:e320] 51 -> Terratec Hybrid XS Secam (em2880) [0ccd:004c] -- cgit v1.1 From ab599a6d474e0dd4db3557a46dd15cff6e126d0b Mon Sep 17 00:00:00 2001 From: Malcolm Priestley Date: Sat, 16 Oct 2010 16:44:43 -0300 Subject: [media] lmedm04: driver for DM04/QQBOX updated to version 1.60 These include -later kill of usb_buffer to avoid kernel crash on hot unplugging. -DiSEqC functions. -LNB Power switch -Faster channel change. -support for LG tuner on LME2510C. -firmware switching for LG tuner. Signed-off-by: Malcolm Priestley Signed-off-by: Mauro Carvalho Chehab --- Documentation/dvb/lmedm04.txt | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dvb/lmedm04.txt b/Documentation/dvb/lmedm04.txt index 4bde457..e175784 100644 --- a/Documentation/dvb/lmedm04.txt +++ b/Documentation/dvb/lmedm04.txt @@ -45,10 +45,13 @@ and run Other LG firmware can be extracted manually from US280D.sys only found in windows/system32/driver. -However, this firmware does not run very well under Windows -or with the Linux driver. -dd if=US280D.sys ibs=1 skip=36856 count=3976 of=dvb-usb-lme2510-lg.fw +dd if=US280D.sys ibs=1 skip=42616 count=3668 of=dvb-usb-lme2510-lg.fw + +for DM04 LME2510C (LG Tuner) +--------------------------- + +dd if=US280D.sys ibs=1 skip=35200 count=3850 of=dvb-usb-lme2510c-lg.fw --------------------------------------------------------------------- -- cgit v1.1 From eb8942e9b6150d3cc89640f1fb243ca9626a1d14 Mon Sep 17 00:00:00 2001 From: Matti Aaltonen Date: Mon, 18 Oct 2010 10:52:37 -0300 Subject: [media] Documentation: v4l: Add hw_seek spacing and two TUNER_RDS_CAP flags Add a couple of words about the spacing field in the HW seek struct, also a few words about the new RDS tuner capability flags V4L2_TUNER_CAP_RDS_BLOCK-IO and V4L2_TUNER_CAP_RDS_CONTROLS. Signed-off-by: Matti J. Aaltonen Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/dev-rds.xml | 68 ++++++++++++++++------ .../DocBook/v4l/vidioc-s-hw-freq-seek.xml | 10 +++- 2 files changed, 59 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/dev-rds.xml b/Documentation/DocBook/v4l/dev-rds.xml index 0869d70..360d273 100644 --- a/Documentation/DocBook/v4l/dev-rds.xml +++ b/Documentation/DocBook/v4l/dev-rds.xml @@ -3,15 +3,16 @@ The Radio Data System transmits supplementary information in binary format, for example the station name or travel information, on an inaudible audio subcarrier of a radio program. This -interface is aimed at devices capable of receiving and decoding RDS +interface is aimed at devices capable of receiving and/or transmitting RDS information. For more information see the core RDS standard and the RBDS standard . Note that the RBDS standard as is used in the USA is almost identical -to the RDS standard. Any RDS decoder can also handle RBDS. Only some of the fields -have slightly different meanings. See the RBDS standard for more information. +to the RDS standard. Any RDS decoder/encoder can also handle RBDS. Only some of the +fields have slightly different meanings. See the RBDS standard for more +information. The RBDS standard also specifies support for MMBS (Modified Mobile Search). This is a proprietary format which seems to be discontinued. The RDS interface does not @@ -21,16 +22,25 @@ be needed, then please contact the linux-media mailing list: &v4l-ml;.
Querying Capabilities - Devices supporting the RDS capturing API -set the V4L2_CAP_RDS_CAPTURE flag in + Devices supporting the RDS capturing API set +the V4L2_CAP_RDS_CAPTURE flag in the capabilities field of &v4l2-capability; -returned by the &VIDIOC-QUERYCAP; ioctl. -Any tuner that supports RDS will set the -V4L2_TUNER_CAP_RDS flag in the capability -field of &v4l2-tuner;. -Whether an RDS signal is present can be detected by looking at -the rxsubchans field of &v4l2-tuner;: the -V4L2_TUNER_SUB_RDS will be set if RDS data was detected. +returned by the &VIDIOC-QUERYCAP; ioctl. Any tuner that supports RDS +will set the V4L2_TUNER_CAP_RDS flag in +the capability field of &v4l2-tuner;. If +the driver only passes RDS blocks without interpreting the data +the V4L2_TUNER_SUB_RDS_BLOCK_IO flag has to be +set, see Reading RDS data. +For future use the +flag V4L2_TUNER_SUB_RDS_CONTROLS has also been +defined. However, a driver for a radio tuner with this capability does +not yet exist, so if you are planning to write such a driver you +should discuss this on the linux-media mailing list: &v4l-ml;. + + Whether an RDS signal is present can be detected by looking +at the rxsubchans field of &v4l2-tuner;: +the V4L2_TUNER_SUB_RDS will be set if RDS data +was detected. Devices supporting the RDS output API set the V4L2_CAP_RDS_OUTPUT flag in @@ -40,16 +50,31 @@ Any modulator that supports RDS will set the V4L2_TUNER_CAP_RDS flag in the capability field of &v4l2-modulator;. In order to enable the RDS transmission one must set the V4L2_TUNER_SUB_RDS -bit in the txsubchans field of &v4l2-modulator;. - +bit in the txsubchans field of &v4l2-modulator;. +If the driver only passes RDS blocks without interpreting the data +the V4L2_TUNER_SUB_RDS_BLOCK_IO flag has to be set. If the +tuner is capable of handling RDS entities like program identification codes and radio +text, the flag V4L2_TUNER_SUB_RDS_CONTROLS should be set, +see Writing RDS data and +FM Transmitter Control Reference.
-
+
Reading RDS data RDS data can be read from the radio device -with the &func-read; function. The data is packed in groups of three bytes, +with the &func-read; function. The data is packed in groups of three bytes. +
+ +
+ Writing RDS data + + RDS data can be written to the radio device +with the &func-write; function. The data is packed in groups of three bytes, as follows: +
+ +
struct <structname>v4l2_rds_data</structname> @@ -111,48 +136,57 @@ as follows: V4L2_RDS_BLOCK_MSK + 7 Mask for bits 0-2 to get the block ID. V4L2_RDS_BLOCK_A + 0 Block A. V4L2_RDS_BLOCK_B + 1 Block B. V4L2_RDS_BLOCK_C + 2 Block C. V4L2_RDS_BLOCK_D + 3 Block D. V4L2_RDS_BLOCK_C_ALT + 4 Block C'. V4L2_RDS_BLOCK_INVALID + read-only 7 An invalid block. V4L2_RDS_BLOCK_CORRECTED + read-only 0x40 A bit error was detected but corrected. V4L2_RDS_BLOCK_ERROR + read-only 0x80 - An incorrectable error occurred. + An uncorrectable error occurred. diff --git a/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml index 14b3ec7..c30dcc4 100644 --- a/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml +++ b/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml @@ -51,7 +51,8 @@ Start a hardware frequency seek from the current frequency. To do this applications initialize the tuner, -type, seek_upward and +type, seek_upward, +spacing and wrap_around fields, and zero out the reserved array of a &v4l2-hw-freq-seek; and call the VIDIOC_S_HW_FREQ_SEEK ioctl with a pointer @@ -89,7 +90,12 @@ field and the &v4l2-tuner; index field. __u32 - reserved[8] + spacing + If non-zero, defines the hardware seek resolution in Hz. The driver selects the nearest value that is supported by the device. If spacing is zero a reasonable default value is used. + + + __u32 + reserved[7] Reserved for future extensions. Drivers and applications must set the array to zero. -- cgit v1.1 From a99e3c515e4e59eb66213baf57137b9ae78a1493 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 25 Feb 2010 14:33:27 -0300 Subject: [media] DocBook/v4l: Add missing formats used on gspca cpia1 and sn9c2028 Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/pixfmt.xml | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/pixfmt.xml b/Documentation/DocBook/v4l/pixfmt.xml index f4cc0a9..861664d 100644 --- a/Documentation/DocBook/v4l/pixfmt.xml +++ b/Documentation/DocBook/v4l/pixfmt.xml @@ -685,6 +685,11 @@ http://www.ivtvdriver.org/The format is documented in the kernel sources in the file Documentation/video4linux/cx2341x/README.hm12 + + V4L2_PIX_FMT_CPIA1 + 'CPIA' + YUV format used by the gspca cpia1 driver. + V4L2_PIX_FMT_SPCA501 'S501' @@ -770,6 +775,11 @@ kernel sources in the file Documentation/video4linux/cx2341x/README.hm 'S920' YUV 4:2:0 format of the gspca sn9c20x driver. + + V4L2_PIX_FMT_SN9C2028 + 'SONX' + Compressed GBRG bayer format of the gspca sn9c2028 driver. + V4L2_PIX_FMT_STV0680 'S680' -- cgit v1.1 From 039aa70218e28a07fdf78220b814cfc4c1c6c3d2 Mon Sep 17 00:00:00 2001 From: Guennadi Liakhovetski Date: Thu, 25 Feb 2010 14:33:27 -0300 Subject: [media] v4l: document new Bayer and monochrome pixel formats Document all four 10-bit Bayer formats, 10-bit monochrome and a missing 8-bit Bayer formats. create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb10.xml create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb8.xml create mode 100644 Documentation/DocBook/v4l/pixfmt-y10.xml [mchehab@redhat.com: remove duplicated symbol for V4L2-PIX-FMT-SGRBG10 and added the corresponding entries at media-entities.tmpl] Signed-off-by: Guennadi Liakhovetski Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media-entities.tmpl | 6 ++ Documentation/DocBook/v4l/pixfmt-srggb10.xml | 90 ++++++++++++++++++++++++++++ Documentation/DocBook/v4l/pixfmt-srggb8.xml | 67 +++++++++++++++++++++ Documentation/DocBook/v4l/pixfmt-y10.xml | 79 ++++++++++++++++++++++++ Documentation/DocBook/v4l/pixfmt.xml | 8 +-- 5 files changed, 245 insertions(+), 5 deletions(-) create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb10.xml create mode 100644 Documentation/DocBook/v4l/pixfmt-srggb8.xml create mode 100644 Documentation/DocBook/v4l/pixfmt-y10.xml (limited to 'Documentation') diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index 6ae9715..be34dcb 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl @@ -250,6 +250,9 @@ + + + @@ -347,6 +350,9 @@ + + + diff --git a/Documentation/DocBook/v4l/pixfmt-srggb10.xml b/Documentation/DocBook/v4l/pixfmt-srggb10.xml new file mode 100644 index 0000000..7b27409 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-srggb10.xml @@ -0,0 +1,90 @@ + + + V4L2_PIX_FMT_SRGGB10 ('RG10'), + V4L2_PIX_FMT_SGRBG10 ('BA10'), + V4L2_PIX_FMT_SGBRG10 ('GB10'), + V4L2_PIX_FMT_SBGGR10 ('BG10'), + + &manvol; + + + V4L2_PIX_FMT_SRGGB10 + V4L2_PIX_FMT_SGRBG10 + V4L2_PIX_FMT_SGBRG10 + V4L2_PIX_FMT_SBGGR10 + 10-bit Bayer formats expanded to 16 bits + + + Description + + The following four pixel formats are raw sRGB / Bayer formats with +10 bits per colour. Each colour component is stored in a 16-bit word, with 6 +unused high bits filled with zeros. Each n-pixel row contains n/2 green samples +and n/2 blue or red samples, with alternating red and blue rows. Bytes are +stored in memory in little endian order. They are conventionally described +as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these +formats + + + <constant>V4L2_PIX_FMT_SBGGR10</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte, high 6 bits in high bytes are 0. + + + + + + start + 0: + B00low + B00high + G01low + G01high + B02low + B02high + G03low + G03high + + + start + 8: + G10low + G10high + R11low + R11high + G12low + G12high + R13low + R13high + + + start + 16: + B20low + B20high + G21low + G21high + B22low + B22high + G23low + G23high + + + start + 24: + G30low + G30high + R31low + R31high + G32low + G32high + R33low + R33high + + + + + + + + + diff --git a/Documentation/DocBook/v4l/pixfmt-srggb8.xml b/Documentation/DocBook/v4l/pixfmt-srggb8.xml new file mode 100644 index 0000000..2570e3b --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-srggb8.xml @@ -0,0 +1,67 @@ + + + V4L2_PIX_FMT_SRGGB8 ('RGGB') + &manvol; + + + V4L2_PIX_FMT_SRGGB8 + Bayer RGB format + + + Description + + This is commonly the native format of digital cameras, +reflecting the arrangement of sensors on the CCD device. Only one red, +green or blue value is given for each pixel. Missing components must +be interpolated from neighbouring pixels. From left to right the first +row consists of a red and green value, the second row of a green and +blue value. This scheme repeats to the right and down for every two +columns and rows. + + + <constant>V4L2_PIX_FMT_SRGGB8</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + R00 + G01 + R02 + G03 + + + start + 4: + G10 + B11 + G12 + B13 + + + start + 8: + R20 + G21 + R22 + G23 + + + start + 12: + G30 + B31 + G32 + B33 + + + + + + + + + diff --git a/Documentation/DocBook/v4l/pixfmt-y10.xml b/Documentation/DocBook/v4l/pixfmt-y10.xml new file mode 100644 index 0000000..d065043 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-y10.xml @@ -0,0 +1,79 @@ + + + V4L2_PIX_FMT_Y10 ('Y10 ') + &manvol; + + + V4L2_PIX_FMT_Y10 + Grey-scale image + + + Description + + This is a grey-scale image with a depth of 10 bits per pixel. Pixels +are stored in 16-bit words with unused high bits padded with 0. The least +significant byte is stored at lower memory addresses (little-endian). + + + <constant>V4L2_PIX_FMT_Y10</constant> 4 × 4 +pixel image + + + Byte Order. + Each cell is one byte. + + + + + + start + 0: + Y'00low + Y'00high + Y'01low + Y'01high + Y'02low + Y'02high + Y'03low + Y'03high + + + start + 8: + Y'10low + Y'10high + Y'11low + Y'11high + Y'12low + Y'12high + Y'13low + Y'13high + + + start + 16: + Y'20low + Y'20high + Y'21low + Y'21high + Y'22low + Y'22high + Y'23low + Y'23high + + + start + 24: + Y'30low + Y'30high + Y'31low + Y'31high + Y'32low + Y'32high + Y'33low + Y'33high + + + + + + + + + diff --git a/Documentation/DocBook/v4l/pixfmt.xml b/Documentation/DocBook/v4l/pixfmt.xml index 861664d..d7c4671 100644 --- a/Documentation/DocBook/v4l/pixfmt.xml +++ b/Documentation/DocBook/v4l/pixfmt.xml @@ -566,7 +566,9 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.< &sub-sbggr8; &sub-sgbrg8; &sub-sgrbg8; + &sub-srggb8; &sub-sbggr16; + &sub-srggb10;
@@ -589,6 +591,7 @@ information. &sub-packed-yuv; &sub-grey; + &sub-y10; &sub-y16; &sub-yuyv; &sub-uyvy; @@ -710,11 +713,6 @@ kernel sources in the file Documentation/video4linux/cx2341x/README.hm 'S561' Compressed GBRG Bayer format used by the gspca driver. - - V4L2_PIX_FMT_SGRBG10 - 'DA10' - 10 bit raw Bayer, expanded to 16 bits. - V4L2_PIX_FMT_SGRBG10DPCM8 'DB10' -- cgit v1.1 From d8d627834b1f4dd21a63c2b524e9eb56173df57b Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Sat, 23 Oct 2010 09:28:12 -0200 Subject: videodev2.h.xml: Update to reflect the latest changes at videodev2.h Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/v4l/videodev2.h.xml | 104 +++++++++++++++++++++++------- 1 file changed, 80 insertions(+), 24 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/v4l/videodev2.h.xml b/Documentation/DocBook/v4l/videodev2.h.xml index eda3858..325b23b6 100644 --- a/Documentation/DocBook/v4l/videodev2.h.xml +++ b/Documentation/DocBook/v4l/videodev2.h.xml @@ -154,23 +154,13 @@ enum v4l2_buf_type { V4L2_BUF_TYPE_VBI_OUTPUT = 5, V4L2_BUF_TYPE_SLICED_VBI_CAPTURE = 6, V4L2_BUF_TYPE_SLICED_VBI_OUTPUT = 7, -#if 1 /*KEEP*/ +#if 1 /* Experimental */ V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8, #endif V4L2_BUF_TYPE_PRIVATE = 0x80, }; -enum v4l2_ctrl_type { - V4L2_CTRL_TYPE_INTEGER = 1, - V4L2_CTRL_TYPE_BOOLEAN = 2, - V4L2_CTRL_TYPE_MENU = 3, - V4L2_CTRL_TYPE_BUTTON = 4, - V4L2_CTRL_TYPE_INTEGER64 = 5, - V4L2_CTRL_TYPE_CTRL_CLASS = 6, - V4L2_CTRL_TYPE_STRING = 7, -}; - enum v4l2_tuner_type { V4L2_TUNER_RADIO = 1, V4L2_TUNER_ANALOG_TV = 2, @@ -288,6 +278,7 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_RGB565 v4l2_fourcc('R', 'G', 'B', 'P') /* 16 RGB-5-6-5 */ #define V4L2_PIX_FMT_RGB555X v4l2_fourcc('R', 'G', 'B', 'Q') /* 16 RGB-5-5-5 BE */ #define V4L2_PIX_FMT_RGB565X v4l2_fourcc('R', 'G', 'B', 'R') /* 16 RGB-5-6-5 BE */ +#define V4L2_PIX_FMT_BGR666 v4l2_fourcc('B', 'G', 'R', 'H') /* 18 BGR-6-6-6 */ #define V4L2_PIX_FMT_BGR24 v4l2_fourcc('B', 'G', 'R', '3') /* 24 BGR-8-8-8 */ #define V4L2_PIX_FMT_RGB24 v4l2_fourcc('R', 'G', 'B', '3') /* 24 RGB-8-8-8 */ #define V4L2_PIX_FMT_BGR32 v4l2_fourcc('B', 'G', 'R', '4') /* 32 BGR-8-8-8-8 */ @@ -295,6 +286,9 @@ struct v4l2_pix_format { /* Grey formats */ #define V4L2_PIX_FMT_GREY v4l2_fourcc('G', 'R', 'E', 'Y') /* 8 Greyscale */ +#define V4L2_PIX_FMT_Y4 v4l2_fourcc('Y', '0', '4', ' ') /* 4 Greyscale */ +#define V4L2_PIX_FMT_Y6 v4l2_fourcc('Y', '0', '6', ' ') /* 6 Greyscale */ +#define V4L2_PIX_FMT_Y10 v4l2_fourcc('Y', '1', '0', ' ') /* 10 Greyscale */ #define V4L2_PIX_FMT_Y16 v4l2_fourcc('Y', '1', '6', ' ') /* 16 Greyscale */ /* Palette formats */ @@ -330,7 +324,11 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_SBGGR8 v4l2_fourcc('B', 'A', '8', '1') /* 8 BGBG.. GRGR.. */ #define V4L2_PIX_FMT_SGBRG8 v4l2_fourcc('G', 'B', 'R', 'G') /* 8 GBGB.. RGRG.. */ #define V4L2_PIX_FMT_SGRBG8 v4l2_fourcc('G', 'R', 'B', 'G') /* 8 GRGR.. BGBG.. */ -#define V4L2_PIX_FMT_SGRBG10 v4l2_fourcc('B', 'A', '1', '0') /* 10bit raw bayer */ +#define V4L2_PIX_FMT_SRGGB8 v4l2_fourcc('R', 'G', 'G', 'B') /* 8 RGRG.. GBGB.. */ +#define V4L2_PIX_FMT_SBGGR10 v4l2_fourcc('B', 'G', '1', '0') /* 10 BGBG.. GRGR.. */ +#define V4L2_PIX_FMT_SGBRG10 v4l2_fourcc('G', 'B', '1', '0') /* 10 GBGB.. RGRG.. */ +#define V4L2_PIX_FMT_SGRBG10 v4l2_fourcc('B', 'A', '1', '0') /* 10 GRGR.. BGBG.. */ +#define V4L2_PIX_FMT_SRGGB10 v4l2_fourcc('R', 'G', '1', '0') /* 10 RGRG.. GBGB.. */ /* 10bit raw bayer DPCM compressed to 8 bits */ #define V4L2_PIX_FMT_SGRBG10DPCM8 v4l2_fourcc('B', 'D', '1', '0') /* @@ -346,6 +344,7 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4 */ /* Vendor-specific formats */ +#define V4L2_PIX_FMT_CPIA1 v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */ #define V4L2_PIX_FMT_WNVA v4l2_fourcc('W', 'N', 'V', 'A') /* Winnov hw compress */ #define V4L2_PIX_FMT_SN9C10X v4l2_fourcc('S', '9', '1', '0') /* SN9C10x compression */ #define V4L2_PIX_FMT_SN9C20X_I420 v4l2_fourcc('S', '9', '2', '0') /* SN9C20x YUV 4:2:0 */ @@ -358,12 +357,13 @@ struct v4l2_pix_format { #define V4L2_PIX_FMT_SPCA561 v4l2_fourcc('S', '5', '6', '1') /* compressed GBRG bayer */ #define V4L2_PIX_FMT_PAC207 v4l2_fourcc('P', '2', '0', '7') /* compressed BGGR bayer */ #define V4L2_PIX_FMT_MR97310A v4l2_fourcc('M', '3', '1', '0') /* compressed BGGR bayer */ +#define V4L2_PIX_FMT_SN9C2028 v4l2_fourcc('S', 'O', 'N', 'X') /* compressed GBRG bayer */ #define V4L2_PIX_FMT_SQ905C v4l2_fourcc('9', '0', '5', 'C') /* compressed RGGB bayer */ #define V4L2_PIX_FMT_PJPG v4l2_fourcc('P', 'J', 'P', 'G') /* Pixart 73xx JPEG */ #define V4L2_PIX_FMT_OV511 v4l2_fourcc('O', '5', '1', '1') /* ov511 JPEG */ #define V4L2_PIX_FMT_OV518 v4l2_fourcc('O', '5', '1', '8') /* ov518 JPEG */ -#define V4L2_PIX_FMT_TM6000 v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */ #define V4L2_PIX_FMT_STV0680 v4l2_fourcc('S', '6', '8', '0') /* stv0680 bayer */ +#define V4L2_PIX_FMT_TM6000 v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */ #define V4L2_PIX_FMT_CIT_YYVYUY v4l2_fourcc('C', 'I', 'T', 'V') /* one line of Y then 1 line of VYUY */ #define V4L2_PIX_FMT_KONICA420 v4l2_fourcc('K', 'O', 'N', 'I') /* YUV420 planar in blocks of 256 pixels */ @@ -382,7 +382,7 @@ struct v4l2_fmtdesc { #define V4L2_FMT_FLAG_COMPRESSED 0x0001 #define V4L2_FMT_FLAG_EMULATED 0x0002 -#if 1 /*KEEP*/ +#if 1 /* Experimental Frame Size and frame rate enumeration */ /* * F R A M E S I Z E E N U M E R A T I O N @@ -546,6 +546,8 @@ struct v4l2_buffer { #define V4L2_BUF_FLAG_KEYFRAME 0x0008 /* Image is a keyframe (I-frame) */ #define V4L2_BUF_FLAG_PFRAME 0x0010 /* Image is a P-frame */ #define V4L2_BUF_FLAG_BFRAME 0x0020 /* Image is a B-frame */ +/* Buffer is ready, but the data contained within is corrupted. */ +#define V4L2_BUF_FLAG_ERROR 0x0040 #define V4L2_BUF_FLAG_TIMECODE 0x0100 /* timecode field is valid */ #define V4L2_BUF_FLAG_INPUT 0x0200 /* input field is valid */ @@ -936,6 +938,16 @@ struct v4l2_ext_controls { #define V4L2_CTRL_ID2CLASS(id) ((id) & 0x0fff0000UL) #define V4L2_CTRL_DRIVER_PRIV(id) (((id) & 0xffff) >= 0x1000) +enum v4l2_ctrl_type { + V4L2_CTRL_TYPE_INTEGER = 1, + V4L2_CTRL_TYPE_BOOLEAN = 2, + V4L2_CTRL_TYPE_MENU = 3, + V4L2_CTRL_TYPE_BUTTON = 4, + V4L2_CTRL_TYPE_INTEGER64 = 5, + V4L2_CTRL_TYPE_CTRL_CLASS = 6, + V4L2_CTRL_TYPE_STRING = 7, +}; + /* Used in the VIDIOC_QUERYCTRL ioctl for querying controls */ struct v4l2_queryctrl { __u32 id; @@ -1020,21 +1032,27 @@ enum v4l2_colorfx { V4L2_COLORFX_NONE = 0, V4L2_COLORFX_BW = 1, V4L2_COLORFX_SEPIA = 2, - V4L2_COLORFX_NEGATIVE = 3, - V4L2_COLORFX_EMBOSS = 4, - V4L2_COLORFX_SKETCH = 5, - V4L2_COLORFX_SKY_BLUE = 6, + V4L2_COLORFX_NEGATIVE = 3, + V4L2_COLORFX_EMBOSS = 4, + V4L2_COLORFX_SKETCH = 5, + V4L2_COLORFX_SKY_BLUE = 6, V4L2_COLORFX_GRASS_GREEN = 7, V4L2_COLORFX_SKIN_WHITEN = 8, - V4L2_COLORFX_VIVID = 9. + V4L2_COLORFX_VIVID = 9, }; #define V4L2_CID_AUTOBRIGHTNESS (V4L2_CID_BASE+32) #define V4L2_CID_BAND_STOP_FILTER (V4L2_CID_BASE+33) #define V4L2_CID_ROTATE (V4L2_CID_BASE+34) #define V4L2_CID_BG_COLOR (V4L2_CID_BASE+35) + +#define V4L2_CID_CHROMA_GAIN (V4L2_CID_BASE+36) + +#define V4L2_CID_ILLUMINATORS_1 (V4L2_CID_BASE+37) +#define V4L2_CID_ILLUMINATORS_2 (V4L2_CID_BASE+38) + /* last CID + 1 */ -#define V4L2_CID_LASTP1 (V4L2_CID_BASE+36) +#define V4L2_CID_LASTP1 (V4L2_CID_BASE+39) /* MPEG-class control IDs defined by V4L2 */ #define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900) @@ -1351,6 +1369,8 @@ struct v4l2_modulator { #define V4L2_TUNER_CAP_SAP 0x0020 #define V4L2_TUNER_CAP_LANG1 0x0040 #define V4L2_TUNER_CAP_RDS 0x0080 +#define V4L2_TUNER_CAP_RDS_BLOCK_IO 0x0100 +#define V4L2_TUNER_CAP_RDS_CONTROLS 0x0200 /* Flags for the 'rxsubchans' field */ #define V4L2_TUNER_SUB_MONO 0x0001 @@ -1380,7 +1400,8 @@ struct v4l2_hw_freq_seek { enum v4l2_tuner_type type; __u32 seek_upward; __u32 wrap_around; - __u32 reserved[8]; + __u32 spacing; + __u32 reserved[7]; }; /* @@ -1435,7 +1456,7 @@ struct v4l2_audioout { * * NOTE: EXPERIMENTAL API */ -#if 1 /*KEEP*/ +#if 1 #define V4L2_ENC_IDX_FRAME_I (0) #define V4L2_ENC_IDX_FRAME_P (1) #define V4L2_ENC_IDX_FRAME_B (2) @@ -1628,6 +1649,38 @@ struct v4l2_streamparm { }; /* + * E V E N T S + */ + +#define V4L2_EVENT_ALL 0 +#define V4L2_EVENT_VSYNC 1 +#define V4L2_EVENT_EOS 2 +#define V4L2_EVENT_PRIVATE_START 0x08000000 + +/* Payload for V4L2_EVENT_VSYNC */ +struct v4l2_event_vsync { + /* Can be V4L2_FIELD_ANY, _NONE, _TOP or _BOTTOM */ + __u8 field; +} __attribute__ ((packed)); + +struct v4l2_event { + __u32 type; + union { + struct v4l2_event_vsync vsync; + __u8 data[64]; + } u; + __u32 pending; + __u32 sequence; + struct timespec timestamp; + __u32 reserved[9]; +}; + +struct v4l2_event_subscription { + __u32 type; + __u32 reserved[7]; +}; + +/* * A D V A N C E D D E B U G G I N G * * NOTE: EXPERIMENTAL API, NEVER RELY ON THIS IN APPLICATIONS! @@ -1722,7 +1775,7 @@ struct v4l2_dbg_chip_ident { #define VIDIOC_G_EXT_CTRLS _IOWR('V', 71, struct v4l2_ext_controls) #define VIDIOC_S_EXT_CTRLS _IOWR('V', 72, struct v4l2_ext_controls) #define VIDIOC_TRY_EXT_CTRLS _IOWR('V', 73, struct v4l2_ext_controls) -#if 1 /*KEEP*/ +#if 1 #define VIDIOC_ENUM_FRAMESIZES _IOWR('V', 74, struct v4l2_frmsizeenum) #define VIDIOC_ENUM_FRAMEINTERVALS _IOWR('V', 75, struct v4l2_frmivalenum) #define VIDIOC_G_ENC_INDEX _IOR('V', 76, struct v4l2_enc_idx) @@ -1730,7 +1783,7 @@ struct v4l2_dbg_chip_ident { #define VIDIOC_TRY_ENCODER_CMD _IOWR('V', 78, struct v4l2_encoder_cmd) #endif -#if 1 /*KEEP*/ +#if 1 /* Experimental, meant for debugging, testing and internal use. Only implemented if CONFIG_VIDEO_ADV_DEBUG is defined. You must be root to use these ioctls. Never use these in applications! */ @@ -1749,6 +1802,9 @@ struct v4l2_dbg_chip_ident { #define VIDIOC_QUERY_DV_PRESET _IOR('V', 86, struct v4l2_dv_preset) #define VIDIOC_S_DV_TIMINGS _IOWR('V', 87, struct v4l2_dv_timings) #define VIDIOC_G_DV_TIMINGS _IOWR('V', 88, struct v4l2_dv_timings) +#define VIDIOC_DQEVENT _IOR('V', 89, struct v4l2_event) +#define VIDIOC_SUBSCRIBE_EVENT _IOW('V', 90, struct v4l2_event_subscription) +#define VIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 91, struct v4l2_event_subscription) /* Reminder: when adding new ioctls please add support for them to drivers/media/video/v4l2-compat-ioctl32.c as well! */ -- cgit v1.1 From 6c2754c28f2388a276fe21edde826f2113c8f60e Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Sat, 23 Oct 2010 08:14:12 -0700 Subject: Revert "tty: Add a new file /proc/tty/consoles" This reverts commit f4a3e0bceb57466c31757f25e4e0ed108d1299ec. Jiri Sladby points out that the tty structure we're using may already be gone, and Al Viro doesn't hold back in complaining about the random loading of 'filp->private_data' which doesn't have to be a pointer at all, nor does checking the magic field for TTY_MAGIC prove anything. Belated review by Al: "a) global variable depending on stdin of the last opener? Affecting output of read(2)? Really? b) iterator is broken; list should be locked in ->start(), unlocked in ->stop() and *NOT* unlocked/relocked in ->next() c) ->show() ought to do nothing in case of ->device == NULL, instead of skipping those in ->next()/->start() d) regardless of the merits of the bright idea about asterisk at that line in output *and* regardless of (a), the implementation is not only atrociously ugly, it's actually very likely to be a roothole. Verifying that Cthulhu knows what number happens to be address of a tty_struct by blindly dereferencing memory at that address... Ouch. Please revert that crap." And Christoph pipes in and NAK's the approach of walking fd tables etc too. So it's pretty unanimous. Noticed-by: Jri Slaby Requested-by: Al Viro Cc: Greg Kroah-Hartman Cc: Werner Fink Cc: Alan Cox Cc: Christoph Hellwig Signed-off-by: Linus Torvalds --- Documentation/filesystems/proc.txt | 32 -------------------------------- 1 file changed, 32 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 98223a6..a6aca87 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -1075,7 +1075,6 @@ Table 1-11: Files in /proc/tty drivers list of drivers and their usage ldiscs registered line disciplines driver/serial usage statistic and status of single tty lines - consoles registered system console lines .............................................................................. To see which tty's are currently in use, you can simply look into the file @@ -1094,37 +1093,6 @@ To see which tty's are currently in use, you can simply look into the file /dev/tty /dev/tty 5 0 system:/dev/tty unknown /dev/tty 4 1-63 console -To see which character device lines are currently used for the system console -/dev/console, you may simply look into the file /proc/tty/consoles: - - > cat /proc/tty/consoles - tty0 -WU (ECp) 4:7 - ttyS0 -W- (Ep) 4:64 - -The columns are: - - device name of the device - operations R = can do read operations - W = can do write operations - U = can do unblank - flags E = it is enabled - C = it is prefered console - B = it is primary boot console - p = it is used for printk buffer - b = it is not a TTY but a Braille device - a = it is safe to use when cpu is offline - * = it is standard input of the reading process - major:minor major and minor number of the device separated by a colon - -If the reading process holds /dev/console open at the regular standard input -stream the active device will be marked by an asterisk: - - > cat /proc/tty/consoles < /dev/console - tty0 -WU (ECp*) 4:7 - ttyS0 -W- (Ep) 4:64 - > tty - /dev/pts/3 - 1.8 Miscellaneous kernel statistics in /proc/stat ------------------------------------------------- -- cgit v1.1 From d7d3c2ea99c4845611997cf728af88c4c232e908 Mon Sep 17 00:00:00 2001 From: Alexander Graf Date: Thu, 29 Jul 2010 14:48:07 +0200 Subject: KVM: PPC: Add Documentation about PV interface We just introduced a new PV interface that screams for documentation. So here it is - a shiny new and awesome text file describing the internal works of the PPC KVM paravirtual interface. Signed-off-by: Alexander Graf Signed-off-by: Avi Kivity --- Documentation/kvm/ppc-pv.txt | 179 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 179 insertions(+) create mode 100644 Documentation/kvm/ppc-pv.txt (limited to 'Documentation') diff --git a/Documentation/kvm/ppc-pv.txt b/Documentation/kvm/ppc-pv.txt new file mode 100644 index 0000000..41ee16d --- /dev/null +++ b/Documentation/kvm/ppc-pv.txt @@ -0,0 +1,179 @@ +The PPC KVM paravirtual interface +================================= + +The basic execution principle by which KVM on PowerPC works is to run all kernel +space code in PR=1 which is user space. This way we trap all privileged +instructions and can emulate them accordingly. + +Unfortunately that is also the downfall. There are quite some privileged +instructions that needlessly return us to the hypervisor even though they +could be handled differently. + +This is what the PPC PV interface helps with. It takes privileged instructions +and transforms them into unprivileged ones with some help from the hypervisor. +This cuts down virtualization costs by about 50% on some of my benchmarks. + +The code for that interface can be found in arch/powerpc/kernel/kvm* + +Querying for existence +====================== + +To find out if we're running on KVM or not, we leverage the device tree. When +Linux is running on KVM, a node /hypervisor exists. That node contains a +compatible property with the value "linux,kvm". + +Once you determined you're running under a PV capable KVM, you can now use +hypercalls as described below. + +KVM hypercalls +============== + +Inside the device tree's /hypervisor node there's a property called +'hypercall-instructions'. This property contains at most 4 opcodes that make +up the hypercall. To call a hypercall, just call these instructions. + +The parameters are as follows: + + Register IN OUT + + r0 - volatile + r3 1st parameter Return code + r4 2nd parameter 1st output value + r5 3rd parameter 2nd output value + r6 4th parameter 3rd output value + r7 5th parameter 4th output value + r8 6th parameter 5th output value + r9 7th parameter 6th output value + r10 8th parameter 7th output value + r11 hypercall number 8th output value + r12 - volatile + +Hypercall definitions are shared in generic code, so the same hypercall numbers +apply for x86 and powerpc alike with the exception that each KVM hypercall +also needs to be ORed with the KVM vendor code which is (42 << 16). + +Return codes can be as follows: + + Code Meaning + + 0 Success + 12 Hypercall not implemented + <0 Error + +The magic page +============== + +To enable communication between the hypervisor and guest there is a new shared +page that contains parts of supervisor visible register state. The guest can +map this shared page using the KVM hypercall KVM_HC_PPC_MAP_MAGIC_PAGE. + +With this hypercall issued the guest always gets the magic page mapped at the +desired location in effective and physical address space. For now, we always +map the page to -4096. This way we can access it using absolute load and store +functions. The following instruction reads the first field of the magic page: + + ld rX, -4096(0) + +The interface is designed to be extensible should there be need later to add +additional registers to the magic page. If you add fields to the magic page, +also define a new hypercall feature to indicate that the host can give you more +registers. Only if the host supports the additional features, make use of them. + +The magic page has the following layout as described in +arch/powerpc/include/asm/kvm_para.h: + +struct kvm_vcpu_arch_shared { + __u64 scratch1; + __u64 scratch2; + __u64 scratch3; + __u64 critical; /* Guest may not get interrupts if == r1 */ + __u64 sprg0; + __u64 sprg1; + __u64 sprg2; + __u64 sprg3; + __u64 srr0; + __u64 srr1; + __u64 dar; + __u64 msr; + __u32 dsisr; + __u32 int_pending; /* Tells the guest if we have an interrupt */ +}; + +Additions to the page must only occur at the end. Struct fields are always 32 +or 64 bit aligned, depending on them being 32 or 64 bit wide respectively. + +MSR bits +======== + +The MSR contains bits that require hypervisor intervention and bits that do +not require direct hypervisor intervention because they only get interpreted +when entering the guest or don't have any impact on the hypervisor's behavior. + +The following bits are safe to be set inside the guest: + + MSR_EE + MSR_RI + MSR_CR + MSR_ME + +If any other bit changes in the MSR, please still use mtmsr(d). + +Patched instructions +==================== + +The "ld" and "std" instructions are transormed to "lwz" and "stw" instructions +respectively on 32 bit systems with an added offset of 4 to accomodate for big +endianness. + +The following is a list of mapping the Linux kernel performs when running as +guest. Implementing any of those mappings is optional, as the instruction traps +also act on the shared page. So calling privileged instructions still works as +before. + +From To +==== == + +mfmsr rX ld rX, magic_page->msr +mfsprg rX, 0 ld rX, magic_page->sprg0 +mfsprg rX, 1 ld rX, magic_page->sprg1 +mfsprg rX, 2 ld rX, magic_page->sprg2 +mfsprg rX, 3 ld rX, magic_page->sprg3 +mfsrr0 rX ld rX, magic_page->srr0 +mfsrr1 rX ld rX, magic_page->srr1 +mfdar rX ld rX, magic_page->dar +mfdsisr rX lwz rX, magic_page->dsisr + +mtmsr rX std rX, magic_page->msr +mtsprg 0, rX std rX, magic_page->sprg0 +mtsprg 1, rX std rX, magic_page->sprg1 +mtsprg 2, rX std rX, magic_page->sprg2 +mtsprg 3, rX std rX, magic_page->sprg3 +mtsrr0 rX std rX, magic_page->srr0 +mtsrr1 rX std rX, magic_page->srr1 +mtdar rX std rX, magic_page->dar +mtdsisr rX stw rX, magic_page->dsisr + +tlbsync nop + +mtmsrd rX, 0 b +mtmsr rX b + +mtmsrd rX, 1 b + +[BookE only] +wrteei [0|1] b + + +Some instructions require more logic to determine what's going on than a load +or store instruction can deliver. To enable patching of those, we keep some +RAM around where we can live translate instructions to. What happens is the +following: + + 1) copy emulation code to memory + 2) patch that code to fit the emulated instruction + 3) patch that code to return to the original pc + 4 + 4) patch the original instruction to branch to the new code + +That way we can inject an arbitrary amount of code as replacement for a single +instruction. This allows us to check for pending interrupts when setting EE=1 +for example. -- cgit v1.1 From 15711e9c927bfc08e66791cbf0ca7887c0880768 Mon Sep 17 00:00:00 2001 From: Alexander Graf Date: Thu, 29 Jul 2010 14:48:08 +0200 Subject: KVM: PPC: Add get_pvinfo interface to query hypercall instructions We need to tell the guest the opcodes that make up a hypercall through interfaces that are controlled by userspace. So we need to add a call for userspace to allow it to query those opcodes so it can pass them on. This is required because the hypercall opcodes can change based on the hypervisor conditions. If we're running in hardware accelerated hypervisor mode, a hypercall looks different from when we're running without hardware acceleration. Signed-off-by: Alexander Graf Signed-off-by: Avi Kivity --- Documentation/kvm/api.txt | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt index 5f5b649..44d9893 100644 --- a/Documentation/kvm/api.txt +++ b/Documentation/kvm/api.txt @@ -1032,6 +1032,29 @@ are defined as follows: eax, ebx, ecx, edx: the values returned by the cpuid instruction for this function/index combination +4.46 KVM_PPC_GET_PVINFO + +Capability: KVM_CAP_PPC_GET_PVINFO +Architectures: ppc +Type: vm ioctl +Parameters: struct kvm_ppc_pvinfo (out) +Returns: 0 on success, !0 on error + +struct kvm_ppc_pvinfo { + __u32 flags; + __u32 hcall[4]; + __u8 pad[108]; +}; + +This ioctl fetches PV specific information that need to be passed to the guest +using the device tree or other means from vm context. + +For now the only implemented piece of information distributed here is an array +of 4 instructions that make up a hypercall. + +If any additional field gets added to this structure later on, a bit for that +additional piece of information will be set in the flags bitmap. + 5. The kvm_run structure Application code obtains a pointer to the kvm_run structure by -- cgit v1.1 From 9cf4c4fcb59704f0c50f6aa7933399db5d2edf1a Mon Sep 17 00:00:00 2001 From: Jiri Kosina Date: Mon, 16 Aug 2010 17:51:20 +0200 Subject: KVM: x86: explain 'no-kvmclock' kernel parameter no-kvmclock kernel parameter is missing its explanation in Documentation/kernel-parameters.txt. Add it. Signed-off-by: Jiri Kosina Signed-off-by: Avi Kivity --- Documentation/kernel-parameters.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 8dd7248..6bd2375 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1693,6 +1693,8 @@ and is between 256 and 4096 characters. It is defined in the file nojitter [IA64] Disables jitter checking for ITC timers. + no-kvmclock [X86,KVM] Disable paravirtualized KVM clock driver + nolapic [X86-32,APIC] Do not enable or use the local APIC. nolapic_timer [X86-32,APIC] Do not use the local APIC timer. -- cgit v1.1 From f392eb2546170e539668a5ab8df6c1254d15a201 Mon Sep 17 00:00:00 2001 From: Zachary Amsden Date: Thu, 19 Aug 2010 22:07:33 -1000 Subject: KVM: x86: Add timekeeping documentation Basic informational document about x86 timekeeping and how KVM is affected. Signed-off-by: Zachary Amsden Signed-off-by: Marcelo Tosatti --- Documentation/kvm/timekeeping.txt | 612 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 612 insertions(+) create mode 100644 Documentation/kvm/timekeeping.txt (limited to 'Documentation') diff --git a/Documentation/kvm/timekeeping.txt b/Documentation/kvm/timekeeping.txt new file mode 100644 index 0000000..0c5033a --- /dev/null +++ b/Documentation/kvm/timekeeping.txt @@ -0,0 +1,612 @@ + + Timekeeping Virtualization for X86-Based Architectures + + Zachary Amsden + Copyright (c) 2010, Red Hat. All rights reserved. + +1) Overview +2) Timing Devices +3) TSC Hardware +4) Virtualization Problems + +========================================================================= + +1) Overview + +One of the most complicated parts of the X86 platform, and specifically, +the virtualization of this platform is the plethora of timing devices available +and the complexity of emulating those devices. In addition, virtualization of +time introduces a new set of challenges because it introduces a multiplexed +division of time beyond the control of the guest CPU. + +First, we will describe the various timekeeping hardware available, then +present some of the problems which arise and solutions available, giving +specific recommendations for certain classes of KVM guests. + +The purpose of this document is to collect data and information relevant to +timekeeping which may be difficult to find elsewhere, specifically, +information relevant to KVM and hardware-based virtualization. + +========================================================================= + +2) Timing Devices + +First we discuss the basic hardware devices available. TSC and the related +KVM clock are special enough to warrant a full exposition and are described in +the following section. + +2.1) i8254 - PIT + +One of the first timer devices available is the programmable interrupt timer, +or PIT. The PIT has a fixed frequency 1.193182 MHz base clock and three +channels which can be programmed to deliver periodic or one-shot interrupts. +These three channels can be configured in different modes and have individual +counters. Channel 1 and 2 were not available for general use in the original +IBM PC, and historically were connected to control RAM refresh and the PC +speaker. Now the PIT is typically integrated as part of an emulated chipset +and a separate physical PIT is not used. + +The PIT uses I/O ports 0x40 - 0x43. Access to the 16-bit counters is done +using single or multiple byte access to the I/O ports. There are 6 modes +available, but not all modes are available to all timers, as only timer 2 +has a connected gate input, required for modes 1 and 5. The gate line is +controlled by port 61h, bit 0, as illustrated in the following diagram. + + -------------- ---------------- +| | | | +| 1.1932 MHz |---------->| CLOCK OUT | ---------> IRQ 0 +| Clock | | | | + -------------- | +->| GATE TIMER 0 | + | ---------------- + | + | ---------------- + | | | + |------>| CLOCK OUT | ---------> 66.3 KHZ DRAM + | | | (aka /dev/null) + | +->| GATE TIMER 1 | + | ---------------- + | + | ---------------- + | | | + |------>| CLOCK OUT | ---------> Port 61h, bit 5 + | | | +Port 61h, bit 0 ---------->| GATE TIMER 2 | \_.---- ____ + ---------------- _| )--|LPF|---Speaker + / *---- \___/ +Port 61h, bit 1 -----------------------------------/ + +The timer modes are now described. + +Mode 0: Single Timeout. This is a one-shot software timeout that counts down + when the gate is high (always true for timers 0 and 1). When the count + reaches zero, the output goes high. + +Mode 1: Triggered One-shot. The output is intially set high. When the gate + line is set high, a countdown is initiated (which does not stop if the gate is + lowered), during which the output is set low. When the count reaches zero, + the output goes high. + +Mode 2: Rate Generator. The output is initially set high. When the countdown + reaches 1, the output goes low for one count and then returns high. The value + is reloaded and the countdown automatically resumes. If the gate line goes + low, the count is halted. If the output is low when the gate is lowered, the + output automatically goes high (this only affects timer 2). + +Mode 3: Square Wave. This generates a high / low square wave. The count + determines the length of the pulse, which alternates between high and low + when zero is reached. The count only proceeds when gate is high and is + automatically reloaded on reaching zero. The count is decremented twice at + each clock to generate a full high / low cycle at the full periodic rate. + If the count is even, the clock remains high for N/2 counts and low for N/2 + counts; if the clock is odd, the clock is high for (N+1)/2 counts and low + for (N-1)/2 counts. Only even values are latched by the counter, so odd + values are not observed when reading. This is the intended mode for timer 2, + which generates sine-like tones by low-pass filtering the square wave output. + +Mode 4: Software Strobe. After programming this mode and loading the counter, + the output remains high until the counter reaches zero. Then the output + goes low for 1 clock cycle and returns high. The counter is not reloaded. + Counting only occurs when gate is high. + +Mode 5: Hardware Strobe. After programming and loading the counter, the + output remains high. When the gate is raised, a countdown is initiated + (which does not stop if the gate is lowered). When the counter reaches zero, + the output goes low for 1 clock cycle and then returns high. The counter is + not reloaded. + +In addition to normal binary counting, the PIT supports BCD counting. The +command port, 0x43 is used to set the counter and mode for each of the three +timers. + +PIT commands, issued to port 0x43, using the following bit encoding: + +Bit 7-4: Command (See table below) +Bit 3-1: Mode (000 = Mode 0, 101 = Mode 5, 11X = undefined) +Bit 0 : Binary (0) / BCD (1) + +Command table: + +0000 - Latch Timer 0 count for port 0x40 + sample and hold the count to be read in port 0x40; + additional commands ignored until counter is read; + mode bits ignored. + +0001 - Set Timer 0 LSB mode for port 0x40 + set timer to read LSB only and force MSB to zero; + mode bits set timer mode + +0010 - Set Timer 0 MSB mode for port 0x40 + set timer to read MSB only and force LSB to zero; + mode bits set timer mode + +0011 - Set Timer 0 16-bit mode for port 0x40 + set timer to read / write LSB first, then MSB; + mode bits set timer mode + +0100 - Latch Timer 1 count for port 0x41 - as described above +0101 - Set Timer 1 LSB mode for port 0x41 - as described above +0110 - Set Timer 1 MSB mode for port 0x41 - as described above +0111 - Set Timer 1 16-bit mode for port 0x41 - as described above + +1000 - Latch Timer 2 count for port 0x42 - as described above +1001 - Set Timer 2 LSB mode for port 0x42 - as described above +1010 - Set Timer 2 MSB mode for port 0x42 - as described above +1011 - Set Timer 2 16-bit mode for port 0x42 as described above + +1101 - General counter latch + Latch combination of counters into corresponding ports + Bit 3 = Counter 2 + Bit 2 = Counter 1 + Bit 1 = Counter 0 + Bit 0 = Unused + +1110 - Latch timer status + Latch combination of counter mode into corresponding ports + Bit 3 = Counter 2 + Bit 2 = Counter 1 + Bit 1 = Counter 0 + + The output of ports 0x40-0x42 following this command will be: + + Bit 7 = Output pin + Bit 6 = Count loaded (0 if timer has expired) + Bit 5-4 = Read / Write mode + 01 = MSB only + 10 = LSB only + 11 = LSB / MSB (16-bit) + Bit 3-1 = Mode + Bit 0 = Binary (0) / BCD mode (1) + +2.2) RTC + +The second device which was available in the original PC was the MC146818 real +time clock. The original device is now obsolete, and usually emulated by the +system chipset, sometimes by an HPET and some frankenstein IRQ routing. + +The RTC is accessed through CMOS variables, which uses an index register to +control which bytes are read. Since there is only one index register, read +of the CMOS and read of the RTC require lock protection (in addition, it is +dangerous to allow userspace utilities such as hwclock to have direct RTC +access, as they could corrupt kernel reads and writes of CMOS memory). + +The RTC generates an interrupt which is usually routed to IRQ 8. The interrupt +can function as a periodic timer, an additional once a day alarm, and can issue +interrupts after an update of the CMOS registers by the MC146818 is complete. +The type of interrupt is signalled in the RTC status registers. + +The RTC will update the current time fields by battery power even while the +system is off. The current time fields should not be read while an update is +in progress, as indicated in the status register. + +The clock uses a 32.768kHz crystal, so bits 6-4 of register A should be +programmed to a 32kHz divider if the RTC is to count seconds. + +This is the RAM map originally used for the RTC/CMOS: + +Location Size Description +------------------------------------------ +00h byte Current second (BCD) +01h byte Seconds alarm (BCD) +02h byte Current minute (BCD) +03h byte Minutes alarm (BCD) +04h byte Current hour (BCD) +05h byte Hours alarm (BCD) +06h byte Current day of week (BCD) +07h byte Current day of month (BCD) +08h byte Current month (BCD) +09h byte Current year (BCD) +0Ah byte Register A + bit 7 = Update in progress + bit 6-4 = Divider for clock + 000 = 4.194 MHz + 001 = 1.049 MHz + 010 = 32 kHz + 10X = test modes + 110 = reset / disable + 111 = reset / disable + bit 3-0 = Rate selection for periodic interrupt + 000 = periodic timer disabled + 001 = 3.90625 uS + 010 = 7.8125 uS + 011 = .122070 mS + 100 = .244141 mS + ... + 1101 = 125 mS + 1110 = 250 mS + 1111 = 500 mS +0Bh byte Register B + bit 7 = Run (0) / Halt (1) + bit 6 = Periodic interrupt enable + bit 5 = Alarm interrupt enable + bit 4 = Update-ended interrupt enable + bit 3 = Square wave interrupt enable + bit 2 = BCD calendar (0) / Binary (1) + bit 1 = 12-hour mode (0) / 24-hour mode (1) + bit 0 = 0 (DST off) / 1 (DST enabled) +OCh byte Register C (read only) + bit 7 = interrupt request flag (IRQF) + bit 6 = periodic interrupt flag (PF) + bit 5 = alarm interrupt flag (AF) + bit 4 = update interrupt flag (UF) + bit 3-0 = reserved +ODh byte Register D (read only) + bit 7 = RTC has power + bit 6-0 = reserved +32h byte Current century BCD (*) + (*) location vendor specific and now determined from ACPI global tables + +2.3) APIC + +On Pentium and later processors, an on-board timer is available to each CPU +as part of the Advanced Programmable Interrupt Controller. The APIC is +accessed through memory-mapped registers and provides interrupt service to each +CPU, used for IPIs and local timer interrupts. + +Although in theory the APIC is a safe and stable source for local interrupts, +in practice, many bugs and glitches have occurred due to the special nature of +the APIC CPU-local memory-mapped hardware. Beware that CPU errata may affect +the use of the APIC and that workarounds may be required. In addition, some of +these workarounds pose unique constraints for virtualization - requiring either +extra overhead incurred from extra reads of memory-mapped I/O or additional +functionality that may be more computationally expensive to implement. + +Since the APIC is documented quite well in the Intel and AMD manuals, we will +avoid repetition of the detail here. It should be pointed out that the APIC +timer is programmed through the LVT (local vector timer) register, is capable +of one-shot or periodic operation, and is based on the bus clock divided down +by the programmable divider register. + +2.4) HPET + +HPET is quite complex, and was originally intended to replace the PIT / RTC +support of the X86 PC. It remains to be seen whether that will be the case, as +the de facto standard of PC hardware is to emulate these older devices. Some +systems designated as legacy free may support only the HPET as a hardware timer +device. + +The HPET spec is rather loose and vague, requiring at least 3 hardware timers, +but allowing implementation freedom to support many more. It also imposes no +fixed rate on the timer frequency, but does impose some extremal values on +frequency, error and slew. + +In general, the HPET is recommended as a high precision (compared to PIT /RTC) +time source which is independent of local variation (as there is only one HPET +in any given system). The HPET is also memory-mapped, and its presence is +indicated through ACPI tables by the BIOS. + +Detailed specification of the HPET is beyond the current scope of this +document, as it is also very well documented elsewhere. + +2.5) Offboard Timers + +Several cards, both proprietary (watchdog boards) and commonplace (e1000) have +timing chips built into the cards which may have registers which are accessible +to kernel or user drivers. To the author's knowledge, using these to generate +a clocksource for a Linux or other kernel has not yet been attempted and is in +general frowned upon as not playing by the agreed rules of the game. Such a +timer device would require additional support to be virtualized properly and is +not considered important at this time as no known operating system does this. + +========================================================================= + +3) TSC Hardware + +The TSC or time stamp counter is relatively simple in theory; it counts +instruction cycles issued by the processor, which can be used as a measure of +time. In practice, due to a number of problems, it is the most complicated +timekeeping device to use. + +The TSC is represented internally as a 64-bit MSR which can be read with the +RDMSR, RDTSC, or RDTSCP (when available) instructions. In the past, hardware +limitations made it possible to write the TSC, but generally on old hardware it +was only possible to write the low 32-bits of the 64-bit counter, and the upper +32-bits of the counter were cleared. Now, however, on Intel processors family +0Fh, for models 3, 4 and 6, and family 06h, models e and f, this restriction +has been lifted and all 64-bits are writable. On AMD systems, the ability to +write the TSC MSR is not an architectural guarantee. + +The TSC is accessible from CPL-0 and conditionally, for CPL > 0 software by +means of the CR4.TSD bit, which when enabled, disables CPL > 0 TSC access. + +Some vendors have implemented an additional instruction, RDTSCP, which returns +atomically not just the TSC, but an indicator which corresponds to the +processor number. This can be used to index into an array of TSC variables to +determine offset information in SMP systems where TSCs are not synchronized. +The presence of this instruction must be determined by consulting CPUID feature +bits. + +Both VMX and SVM provide extension fields in the virtualization hardware which +allows the guest visible TSC to be offset by a constant. Newer implementations +promise to allow the TSC to additionally be scaled, but this hardware is not +yet widely available. + +3.1) TSC synchronization + +The TSC is a CPU-local clock in most implementations. This means, on SMP +platforms, the TSCs of different CPUs may start at different times depending +on when the CPUs are powered on. Generally, CPUs on the same die will share +the same clock, however, this is not always the case. + +The BIOS may attempt to resynchronize the TSCs during the poweron process and +the operating system or other system software may attempt to do this as well. +Several hardware limitations make the problem worse - if it is not possible to +write the full 64-bits of the TSC, it may be impossible to match the TSC in +newly arriving CPUs to that of the rest of the system, resulting in +unsynchronized TSCs. This may be done by BIOS or system software, but in +practice, getting a perfectly synchronized TSC will not be possible unless all +values are read from the same clock, which generally only is possible on single +socket systems or those with special hardware support. + +3.2) TSC and CPU hotplug + +As touched on already, CPUs which arrive later than the boot time of the system +may not have a TSC value that is synchronized with the rest of the system. +Either system software, BIOS, or SMM code may actually try to establish the TSC +to a value matching the rest of the system, but a perfect match is usually not +a guarantee. This can have the effect of bringing a system from a state where +TSC is synchronized back to a state where TSC synchronization flaws, however +small, may be exposed to the OS and any virtualization environment. + +3.3) TSC and multi-socket / NUMA + +Multi-socket systems, especially large multi-socket systems are likely to have +individual clocksources rather than a single, universally distributed clock. +Since these clocks are driven by different crystals, they will not have +perfectly matched frequency, and temperature and electrical variations will +cause the CPU clocks, and thus the TSCs to drift over time. Depending on the +exact clock and bus design, the drift may or may not be fixed in absolute +error, and may accumulate over time. + +In addition, very large systems may deliberately slew the clocks of individual +cores. This technique, known as spread-spectrum clocking, reduces EMI at the +clock frequency and harmonics of it, which may be required to pass FCC +standards for telecommunications and computer equipment. + +It is recommended not to trust the TSCs to remain synchronized on NUMA or +multiple socket systems for these reasons. + +3.4) TSC and C-states + +C-states, or idling states of the processor, especially C1E and deeper sleep +states may be problematic for TSC as well. The TSC may stop advancing in such +a state, resulting in a TSC which is behind that of other CPUs when execution +is resumed. Such CPUs must be detected and flagged by the operating system +based on CPU and chipset identifications. + +The TSC in such a case may be corrected by catching it up to a known external +clocksource. + +3.5) TSC frequency change / P-states + +To make things slightly more interesting, some CPUs may change frequency. They +may or may not run the TSC at the same rate, and because the frequency change +may be staggered or slewed, at some points in time, the TSC rate may not be +known other than falling within a range of values. In this case, the TSC will +not be a stable time source, and must be calibrated against a known, stable, +external clock to be a usable source of time. + +Whether the TSC runs at a constant rate or scales with the P-state is model +dependent and must be determined by inspecting CPUID, chipset or vendor +specific MSR fields. + +In addition, some vendors have known bugs where the P-state is actually +compensated for properly during normal operation, but when the processor is +inactive, the P-state may be raised temporarily to service cache misses from +other processors. In such cases, the TSC on halted CPUs could advance faster +than that of non-halted processors. AMD Turion processors are known to have +this problem. + +3.6) TSC and STPCLK / T-states + +External signals given to the processor may also have the effect of stopping +the TSC. This is typically done for thermal emergency power control to prevent +an overheating condition, and typically, there is no way to detect that this +condition has happened. + +3.7) TSC virtualization - VMX + +VMX provides conditional trapping of RDTSC, RDMSR, WRMSR and RDTSCP +instructions, which is enough for full virtualization of TSC in any manner. In +addition, VMX allows passing through the host TSC plus an additional TSC_OFFSET +field specified in the VMCS. Special instructions must be used to read and +write the VMCS field. + +3.8) TSC virtualization - SVM + +SVM provides conditional trapping of RDTSC, RDMSR, WRMSR and RDTSCP +instructions, which is enough for full virtualization of TSC in any manner. In +addition, SVM allows passing through the host TSC plus an additional offset +field specified in the SVM control block. + +3.9) TSC feature bits in Linux + +In summary, there is no way to guarantee the TSC remains in perfect +synchronization unless it is explicitly guaranteed by the architecture. Even +if so, the TSCs in multi-sockets or NUMA systems may still run independently +despite being locally consistent. + +The following feature bits are used by Linux to signal various TSC attributes, +but they can only be taken to be meaningful for UP or single node systems. + +X86_FEATURE_TSC : The TSC is available in hardware +X86_FEATURE_RDTSCP : The RDTSCP instruction is available +X86_FEATURE_CONSTANT_TSC : The TSC rate is unchanged with P-states +X86_FEATURE_NONSTOP_TSC : The TSC does not stop in C-states +X86_FEATURE_TSC_RELIABLE : TSC sync checks are skipped (VMware) + +4) Virtualization Problems + +Timekeeping is especially problematic for virtualization because a number of +challenges arise. The most obvious problem is that time is now shared between +the host and, potentially, a number of virtual machines. Thus the virtual +operating system does not run with 100% usage of the CPU, despite the fact that +it may very well make that assumption. It may expect it to remain true to very +exacting bounds when interrupt sources are disabled, but in reality only its +virtual interrupt sources are disabled, and the machine may still be preempted +at any time. This causes problems as the passage of real time, the injection +of machine interrupts and the associated clock sources are no longer completely +synchronized with real time. + +This same problem can occur on native harware to a degree, as SMM mode may +steal cycles from the naturally on X86 systems when SMM mode is used by the +BIOS, but not in such an extreme fashion. However, the fact that SMM mode may +cause similar problems to virtualization makes it a good justification for +solving many of these problems on bare metal. + +4.1) Interrupt clocking + +One of the most immediate problems that occurs with legacy operating systems +is that the system timekeeping routines are often designed to keep track of +time by counting periodic interrupts. These interrupts may come from the PIT +or the RTC, but the problem is the same: the host virtualization engine may not +be able to deliver the proper number of interrupts per second, and so guest +time may fall behind. This is especially problematic if a high interrupt rate +is selected, such as 1000 HZ, which is unfortunately the default for many Linux +guests. + +There are three approaches to solving this problem; first, it may be possible +to simply ignore it. Guests which have a separate time source for tracking +'wall clock' or 'real time' may not need any adjustment of their interrupts to +maintain proper time. If this is not sufficient, it may be necessary to inject +additional interrupts into the guest in order to increase the effective +interrupt rate. This approach leads to complications in extreme conditions, +where host load or guest lag is too much to compensate for, and thus another +solution to the problem has risen: the guest may need to become aware of lost +ticks and compensate for them internally. Although promising in theory, the +implementation of this policy in Linux has been extremely error prone, and a +number of buggy variants of lost tick compensation are distributed across +commonly used Linux systems. + +Windows uses periodic RTC clocking as a means of keeping time internally, and +thus requires interrupt slewing to keep proper time. It does use a low enough +rate (ed: is it 18.2 Hz?) however that it has not yet been a problem in +practice. + +4.2) TSC sampling and serialization + +As the highest precision time source available, the cycle counter of the CPU +has aroused much interest from developers. As explained above, this timer has +many problems unique to its nature as a local, potentially unstable and +potentially unsynchronized source. One issue which is not unique to the TSC, +but is highlighted because of its very precise nature is sampling delay. By +definition, the counter, once read is already old. However, it is also +possible for the counter to be read ahead of the actual use of the result. +This is a consequence of the superscalar execution of the instruction stream, +which may execute instructions out of order. Such execution is called +non-serialized. Forcing serialized execution is necessary for precise +measurement with the TSC, and requires a serializing instruction, such as CPUID +or an MSR read. + +Since CPUID may actually be virtualized by a trap and emulate mechanism, this +serialization can pose a performance issue for hardware virtualization. An +accurate time stamp counter reading may therefore not always be available, and +it may be necessary for an implementation to guard against "backwards" reads of +the TSC as seen from other CPUs, even in an otherwise perfectly synchronized +system. + +4.3) Timespec aliasing + +Additionally, this lack of serialization from the TSC poses another challenge +when using results of the TSC when measured against another time source. As +the TSC is much higher precision, many possible values of the TSC may be read +while another clock is still expressing the same value. + +That is, you may read (T,T+10) while external clock C maintains the same value. +Due to non-serialized reads, you may actually end up with a range which +fluctuates - from (T-1.. T+10). Thus, any time calculated from a TSC, but +calibrated against an external value may have a range of valid values. +Re-calibrating this computation may actually cause time, as computed after the +calibration, to go backwards, compared with time computed before the +calibration. + +This problem is particularly pronounced with an internal time source in Linux, +the kernel time, which is expressed in the theoretically high resolution +timespec - but which advances in much larger granularity intervals, sometimes +at the rate of jiffies, and possibly in catchup modes, at a much larger step. + +This aliasing requires care in the computation and recalibration of kvmclock +and any other values derived from TSC computation (such as TSC virtualization +itself). + +4.4) Migration + +Migration of a virtual machine raises problems for timekeeping in two ways. +First, the migration itself may take time, during which interrupts cannot be +delivered, and after which, the guest time may need to be caught up. NTP may +be able to help to some degree here, as the clock correction required is +typically small enough to fall in the NTP-correctable window. + +An additional concern is that timers based off the TSC (or HPET, if the raw bus +clock is exposed) may now be running at different rates, requiring compensation +in some way in the hypervisor by virtualizing these timers. In addition, +migrating to a faster machine may preclude the use of a passthrough TSC, as a +faster clock cannot be made visible to a guest without the potential of time +advancing faster than usual. A slower clock is less of a problem, as it can +always be caught up to the original rate. KVM clock avoids these problems by +simply storing multipliers and offsets against the TSC for the guest to convert +back into nanosecond resolution values. + +4.5) Scheduling + +Since scheduling may be based on precise timing and firing of interrupts, the +scheduling algorithms of an operating system may be adversely affected by +virtualization. In theory, the effect is random and should be universally +distributed, but in contrived as well as real scenarios (guest device access, +causes of virtualization exits, possible context switch), this may not always +be the case. The effect of this has not been well studied. + +In an attempt to work around this, several implementations have provided a +paravirtualized scheduler clock, which reveals the true amount of CPU time for +which a virtual machine has been running. + +4.6) Watchdogs + +Watchdog timers, such as the lock detector in Linux may fire accidentally when +running under hardware virtualization due to timer interrupts being delayed or +misinterpretation of the passage of real time. Usually, these warnings are +spurious and can be ignored, but in some circumstances it may be necessary to +disable such detection. + +4.7) Delays and precision timing + +Precise timing and delays may not be possible in a virtualized system. This +can happen if the system is controlling physical hardware, or issues delays to +compensate for slower I/O to and from devices. The first issue is not solvable +in general for a virtualized system; hardware control software can't be +adequately virtualized without a full real-time operating system, which would +require an RT aware virtualization platform. + +The second issue may cause performance problems, but this is unlikely to be a +significant issue. In many cases these delays may be eliminated through +configuration or paravirtualization. + +4.8) Covert channels and leaks + +In addition to the above problems, time information will inevitably leak to the +guest about the host in anything but a perfect implementation of virtualized +time. This may allow the guest to infer the presence of a hypervisor (as in a +red-pill type detection), and it may allow information to leak between guests +by using CPU utilization itself as a signalling channel. Preventing such +problems would require completely isolated virtual time which may not track +real time any longer. This may be useful in certain security or QA contexts, +but in general isn't recommended for real-world deployment scenarios. -- cgit v1.1 From cbe487fac7fc016dbabbcbe83f11384e1803a56d Mon Sep 17 00:00:00 2001 From: Alexander Graf Date: Tue, 3 Aug 2010 10:39:35 +0200 Subject: KVM: PPC: Add mtsrin PV code This is the guest side of the mtsr acceleration. Using this a guest can now call mtsrin with almost no overhead as long as it ensures that it only uses it with (MSR_IR|MSR_DR) == 0. Linux does that, so we're good. Signed-off-by: Alexander Graf --- Documentation/kvm/ppc-pv.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kvm/ppc-pv.txt b/Documentation/kvm/ppc-pv.txt index 41ee16d..922cf95 100644 --- a/Documentation/kvm/ppc-pv.txt +++ b/Documentation/kvm/ppc-pv.txt @@ -160,6 +160,9 @@ mtmsr rX b mtmsrd rX, 1 b +[Book3S only] +mtsrin rX, rY b + [BookE only] wrteei [0|1] b -- cgit v1.1 From 6f7a2bd41fa8d52cbf5f32fdf8ba659d4ce4ae59 Mon Sep 17 00:00:00 2001 From: Alexander Graf Date: Tue, 31 Aug 2010 02:03:32 +0200 Subject: KVM: PPC: Document KVM_INTERRUPT ioctl This adds some documentation for the KVM_INTERRUPT special cases that PowerPC now implements. Signed-off-by: Alexander Graf --- Documentation/kvm/api.txt | 33 +++++++++++++++++++++++++++++++-- 1 file changed, 31 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt index 44d9893..24d6341 100644 --- a/Documentation/kvm/api.txt +++ b/Documentation/kvm/api.txt @@ -320,13 +320,13 @@ struct kvm_translation { 4.15 KVM_INTERRUPT Capability: basic -Architectures: x86 +Architectures: x86, ppc Type: vcpu ioctl Parameters: struct kvm_interrupt (in) Returns: 0 on success, -1 on error Queues a hardware interrupt vector to be injected. This is only -useful if in-kernel local APIC is not used. +useful if in-kernel local APIC or equivalent is not used. /* for KVM_INTERRUPT */ struct kvm_interrupt { @@ -334,8 +334,37 @@ struct kvm_interrupt { __u32 irq; }; +X86: + Note 'irq' is an interrupt vector, not an interrupt pin or line. +PPC: + +Queues an external interrupt to be injected. This ioctl is overleaded +with 3 different irq values: + +a) KVM_INTERRUPT_SET + + This injects an edge type external interrupt into the guest once it's ready + to receive interrupts. When injected, the interrupt is done. + +b) KVM_INTERRUPT_UNSET + + This unsets any pending interrupt. + + Only available with KVM_CAP_PPC_UNSET_IRQ. + +c) KVM_INTERRUPT_SET_LEVEL + + This injects a level type external interrupt into the guest context. The + interrupt stays pending until a specific ioctl with KVM_INTERRUPT_UNSET + is triggered. + + Only available with KVM_CAP_PPC_IRQ_LEVEL. + +Note that any value for 'irq' other than the ones stated above is invalid +and incurs unexpected behavior. + 4.16 KVM_DEBUG_GUEST Capability: basic -- cgit v1.1 From d1e87c7ee65a20b10faf7e59dbe2cc934c32473b Mon Sep 17 00:00:00 2001 From: Alexander Graf Date: Tue, 31 Aug 2010 04:25:39 +0200 Subject: KVM: PPC: Add documentation for magic page enhancements This documents how to detect additional features inside the magic page when a guest maps it. Signed-off-by: Alexander Graf --- Documentation/kvm/ppc-pv.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kvm/ppc-pv.txt b/Documentation/kvm/ppc-pv.txt index 922cf95..a7f2244 100644 --- a/Documentation/kvm/ppc-pv.txt +++ b/Documentation/kvm/ppc-pv.txt @@ -102,6 +102,20 @@ struct kvm_vcpu_arch_shared { Additions to the page must only occur at the end. Struct fields are always 32 or 64 bit aligned, depending on them being 32 or 64 bit wide respectively. +Magic page features +=================== + +When mapping the magic page using the KVM hypercall KVM_HC_PPC_MAP_MAGIC_PAGE, +a second return value is passed to the guest. This second return value contains +a bitmap of available features inside the magic page. + +The following enhancements to the magic page are currently available: + + KVM_MAGIC_FEAT_SR Maps SR registers r/w in the magic page + +For enhanced features in the magic page, please check for the existence of the +feature before using them! + MSR bits ======== -- cgit v1.1 From c39cbd2a0012334714409eec1e9cf4d542e359e9 Mon Sep 17 00:00:00 2001 From: Avi Kivity Date: Sun, 12 Sep 2010 16:39:11 +0200 Subject: KVM: Document that KVM_GET_SUPPORTED_CPUID may return emulated values Signed-off-by: Avi Kivity --- Documentation/kvm/api.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt index 24d6341..b336266 100644 --- a/Documentation/kvm/api.txt +++ b/Documentation/kvm/api.txt @@ -1042,8 +1042,9 @@ number is just right, the 'nent' field is adjusted to the number of valid entries in the 'entries' array, which is then filled. The entries returned are the host cpuid as returned by the cpuid instruction, -with unknown or unsupported features masked out. The fields in each entry -are defined as follows: +with unknown or unsupported features masked out. Some features (for example, +x2apic), may not be present in the host cpu, but are exposed by kvm if it can +emulate them efficiently. The fields in each entry are defined as follows: function: the eax value used to obtain the entry index: the ecx value used to obtain the entry (for entries that are -- cgit v1.1 From 8475f94abfa40d6975923ff022280cf7250fc5fb Mon Sep 17 00:00:00 2001 From: Xiao Guangrong Date: Mon, 20 Sep 2010 22:16:45 +0800 Subject: KVM: fix the description of kvm-amd.nested in documentation The default state of 'kvm-amd.nested' is enabled now, so fix the documentation Signed-off-by: Xiao Guangrong Signed-off-by: Marcelo Tosatti --- Documentation/kernel-parameters.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 6bd2375..3170edb 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1127,7 +1127,7 @@ and is between 256 and 4096 characters. It is defined in the file Default is 1 (enabled) kvm-amd.nested= [KVM,AMD] Allow nested virtualization in KVM/SVM. - Default is 0 (off) + Default is 1 (enabled) kvm-amd.npt= [KVM,AMD] Disable nested paging (virtualized MMU) for all guests. -- cgit v1.1 From a182d8737f0bdfb684b3255c8e266e71999e2225 Mon Sep 17 00:00:00 2001 From: Xiao Guangrong Date: Mon, 20 Sep 2010 22:17:48 +0800 Subject: KVM: document 'kvm.mmu_audit' parameter Document this parameter into Documentation/kernel-parameters.txt Signed-off-by: Xiao Guangrong Signed-off-by: Marcelo Tosatti --- Documentation/kernel-parameters.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 3170edb..8dc2548 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1126,6 +1126,10 @@ and is between 256 and 4096 characters. It is defined in the file kvm.oos_shadow= [KVM] Disable out-of-sync shadow paging. Default is 1 (enabled) + kvm.mmu_audit= [KVM] This is a R/W parameter which allows audit + KVM MMU at runtime. + Default is 0 (off) + kvm-amd.nested= [KVM,AMD] Allow nested virtualization in KVM/SVM. Default is 1 (enabled) -- cgit v1.1 From 02c35fca7cf4ea2dfdc6db279e230cacbbf4b870 Mon Sep 17 00:00:00 2001 From: Fred Isaman Date: Wed, 20 Oct 2010 00:17:59 -0400 Subject: NFSv4.1: pnfs: full mount/umount infrastructure Allow a module implementing a layout type to register, and have its mount/umount routines called for filesystems that the server declares support it. Signed-off-by: Fred Isaman Signed-off-by: Marc Eshel Signed-off-by: Andy Adamson Signed-off-by: Bian Naimeng Signed-off-by: Benny Halevy Signed-off-by: Trond Myklebust --- Documentation/filesystems/nfs/00-INDEX | 2 ++ Documentation/filesystems/nfs/pnfs.txt | 48 ++++++++++++++++++++++++++++++++++ 2 files changed, 50 insertions(+) create mode 100644 Documentation/filesystems/nfs/pnfs.txt (limited to 'Documentation') diff --git a/Documentation/filesystems/nfs/00-INDEX b/Documentation/filesystems/nfs/00-INDEX index 3225a56..a57e124 100644 --- a/Documentation/filesystems/nfs/00-INDEX +++ b/Documentation/filesystems/nfs/00-INDEX @@ -12,6 +12,8 @@ nfs-rdma.txt - how to install and setup the Linux NFS/RDMA client and server software nfsroot.txt - short guide on setting up a diskless box with NFS root filesystem. +pnfs.txt + - short explanation of some of the internals of the pnfs client code rpc-cache.txt - introduction to the caching mechanisms in the sunrpc layer. idmapper.txt diff --git a/Documentation/filesystems/nfs/pnfs.txt b/Documentation/filesystems/nfs/pnfs.txt new file mode 100644 index 0000000..bc0b9cf --- /dev/null +++ b/Documentation/filesystems/nfs/pnfs.txt @@ -0,0 +1,48 @@ +Reference counting in pnfs: +========================== + +The are several inter-related caches. We have layouts which can +reference multiple devices, each of which can reference multiple data servers. +Each data server can be referenced by multiple devices. Each device +can be referenced by multiple layouts. To keep all of this straight, +we need to reference count. + + +struct pnfs_layout_hdr +---------------------- +The on-the-wire command LAYOUTGET corresponds to struct +pnfs_layout_segment, usually referred to by the variable name lseg. +Each nfs_inode may hold a pointer to a cache of of these layout +segments in nfsi->layout, of type struct pnfs_layout_hdr. + +We reference the header for the inode pointing to it, across each +outstanding RPC call that references it (LAYOUTGET, LAYOUTRETURN, +LAYOUTCOMMIT), and for each lseg held within. + +Each header is also (when non-empty) put on a list associated with +struct nfs_client (cl_layouts). Being put on this list does not bump +the reference count, as the layout is kept around by the lseg that +keeps it in the list. + +deviceid_cache +-------------- +lsegs reference device ids, which are resolved per nfs_client and +layout driver type. The device ids are held in a RCU cache (struct +nfs4_deviceid_cache). The cache itself is referenced across each +mount. The entries (struct nfs4_deviceid) themselves are held across +the lifetime of each lseg referencing them. + +RCU is used because the deviceid is basically a write once, read many +data structure. The hlist size of 32 buckets needs better +justification, but seems reasonable given that we can have multiple +deviceid's per filesystem, and multiple filesystems per nfs_client. + +The hash code is copied from the nfsd code base. A discussion of +hashing and variations of this algorithm can be found at: +http://groups.google.com/group/comp.lang.c/browse_thread/thread/9522965e2b8d3809 + +data server cache +----------------- +file driver devices refer to data servers, which are kept in a module +level cache. Its reference is held over the lifetime of the deviceid +pointing to it. -- cgit v1.1 From 89ff05ec553f3e70b8773c501da01bf7ad952cab Mon Sep 17 00:00:00 2001 From: stephen hemminger Date: Thu, 21 Oct 2010 08:37:41 +0000 Subject: phylib: make local function static The following functions are not used directly by any drivers: phy_attach_direct phy_device_create phy_prepare_link genphy_config_advert genphy_setup_forced phy_config_interrupt phy_clear_interrypt phy_sanitize_settings phy_enable_interrupts phy_disable_interrupts Signed-off-by: Stephen Hemminger Signed-off-by: David S. Miller --- Documentation/networking/phy.txt | 18 ------------------ 1 file changed, 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt index 88bb71b..9eb1ba5 100644 --- a/Documentation/networking/phy.txt +++ b/Documentation/networking/phy.txt @@ -177,18 +177,6 @@ Doing it all yourself A convenience function to print out the PHY status neatly. - int phy_clear_interrupt(struct phy_device *phydev); - int phy_config_interrupt(struct phy_device *phydev, u32 interrupts); - - Clear the PHY's interrupt, and configure which ones are allowed, - respectively. Currently only supports all on, or all off. - - int phy_enable_interrupts(struct phy_device *phydev); - int phy_disable_interrupts(struct phy_device *phydev); - - Functions which enable/disable PHY interrupts, clearing them - before and after, respectively. - int phy_start_interrupts(struct phy_device *phydev); int phy_stop_interrupts(struct phy_device *phydev); @@ -213,12 +201,6 @@ Doing it all yourself Fills the phydev structure with up-to-date information about the current settings in the PHY. - void phy_sanitize_settings(struct phy_device *phydev) - - Resolves differences between currently desired settings, and - supported settings for the given PHY device. Does not make - the changes in the hardware, though. - int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd); int phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd); -- cgit v1.1 From 5e71b7a64cb4c6cff75ca42b535d8227526ec592 Mon Sep 17 00:00:00 2001 From: Olof Johansson Date: Fri, 17 Sep 2010 21:19:57 -0400 Subject: mmc: make number of mmcblk minors configurable The old limit of number of minor numbers per mmcblk device was hardcoded at 8. This isn't enough for some of the more elaborate partitioning schemes, for example those used by Chrome OS. Since there might be a bunch of systems out there with static /dev contents that relies on the old numbering scheme, let's make it a build-time option with the default set to the previous 8. Also provide a boot/modprobe-time parameter to override the config default: mmcblk.perdev_minors. Signed-off-by: Olof Johansson Cc: Mandeep Baines Cc: Signed-off-by: Andrew Morton Signed-off-by: Chris Ball --- Documentation/devices.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devices.txt b/Documentation/devices.txt index c58abf1..170cc1e 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -2520,6 +2520,12 @@ Your cooperation is appreciated. 8 = /dev/mmcblk1 Second SD/MMC card ... + The start of next SD/MMC card can be configured with + CONFIG_MMC_BLOCK_MINORS, or overridden at boot/modprobe + time using the mmcblk.perdev_minors option. That would + bump the offset between each card to be the configured + value instead of the default 8. + 179 char CCube DVXChip-based PCI products 0 = /dev/dvxirq0 First DVX device 1 = /dev/dvxirq1 Second DVX device -- cgit v1.1 From c9af3fa9e1e3e5154649991a14b74f3a2dee19ee Mon Sep 17 00:00:00 2001 From: Heiko Carstens Date: Mon, 25 Oct 2010 16:10:43 +0200 Subject: [S390] topology: change default Switch default value of the kernel parameter 'topology' from off to on. Various performance measurements have finally shown that there are no (known) regressions anywhere. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky --- Documentation/kernel-parameters.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 0b68155..b660085 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2438,7 +2438,7 @@ and is between 256 and 4096 characters. It is defined in the file topology informations if the hardware supports these. The scheduler will make use of these informations and e.g. base its process migration decisions on it. - Default is off. + Default is on. tp720= [HW,PS2] -- cgit v1.1 From e5f5c99a39375ce533aacfdfb269978070121e1c Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Fri, 25 Jun 2010 11:59:54 -0700 Subject: hwmon: LTC4261 Hardware monitoring driver This driver adds support for Linear Technology LTC4261 I2C Negative Voltage Hot Swap Controller. Reviewed-by: Ira W. Snyder Reviewed-by: Tom Grennan Signed-off-by: Guenter Roeck --- Documentation/hwmon/ltc4261 | 63 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 Documentation/hwmon/ltc4261 (limited to 'Documentation') diff --git a/Documentation/hwmon/ltc4261 b/Documentation/hwmon/ltc4261 new file mode 100644 index 0000000..eba2e2c --- /dev/null +++ b/Documentation/hwmon/ltc4261 @@ -0,0 +1,63 @@ +Kernel driver ltc4261 +===================== + +Supported chips: + * Linear Technology LTC4261 + Prefix: 'ltc4261' + Addresses scanned: - + Datasheet: + http://cds.linear.com/docs/Datasheet/42612fb.pdf + +Author: Guenter Roeck + + +Description +----------- + +The LTC4261/LTC4261-2 negative voltage Hot Swap controllers allow a board +to be safely inserted and removed from a live backplane. + + +Usage Notes +----------- + +This driver does not probe for LTC4261 devices, since there is no register +which can be safely used to identify the chip. You will have to instantiate +the devices explicitly. + +Example: the following will load the driver for an LTC4261 at address 0x10 +on I2C bus #1: +$ modprobe ltc4261 +$ echo ltc4261 0x10 > /sys/bus/i2c/devices/i2c-1/new_device + + +Sysfs entries +------------- + +Voltage readings provided by this driver are reported as obtained from the ADC +registers. If a set of voltage divider resistors is installed, calculate the +real voltage by multiplying the reported value with (R1+R2)/R2, where R1 is the +value of the divider resistor against the measured voltage and R2 is the value +of the divider resistor against Ground. + +Current reading provided by this driver is reported as obtained from the ADC +Current Sense register. The reported value assumes that a 1 mOhm sense resistor +is installed. If a different sense resistor is installed, calculate the real +current by dividing the reported value by the sense resistor value in mOhm. + +The chip has two voltage sensors, but only one set of voltage alarm status bits. +In many many designs, those alarms are associated with the ADIN2 sensor, due to +the proximity of the ADIN2 pin to the OV pin. ADIN2 is, however, not available +on all chip variants. To ensure that the alarm condition is reported to the user, +report it with both voltage sensors. + +in1_input ADIN2 voltage (mV) +in1_min_alarm ADIN/ADIN2 Undervoltage alarm +in1_max_alarm ADIN/ADIN2 Overvoltage alarm + +in2_input ADIN voltage (mV) +in2_min_alarm ADIN/ADIN2 Undervoltage alarm +in2_max_alarm ADIN/ADIN2 Overvoltage alarm + +curr1_input SENSE current (mA) +curr1_alarm SENSE overcurrent alarm -- cgit v1.1 From d9d1dc802ffae507956ceb350eb3f4a995734f1e Mon Sep 17 00:00:00 2001 From: Valerie Aurora Date: Mon, 30 Aug 2010 17:23:12 -0400 Subject: Documentation: Fix trivial typo in filesystems/sharedsubtree.txt Documentation: Fix trivial typo in filesystems/sharedsubtree.txt This typo is easy to ignore unless you have spent a great deal of time thinking about how to eliminate duplicate dentries in unions. Signed-off-by: Valerie Aurora Signed-off-by: Al Viro --- Documentation/filesystems/sharedsubtree.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/sharedsubtree.txt b/Documentation/filesystems/sharedsubtree.txt index fc0e39a..4ede421 100644 --- a/Documentation/filesystems/sharedsubtree.txt +++ b/Documentation/filesystems/sharedsubtree.txt @@ -62,10 +62,10 @@ replicas continue to be exactly same. # mount /dev/sd0 /tmp/a #ls /tmp/a - t1 t2 t2 + t1 t2 t3 #ls /mnt/a - t1 t2 t2 + t1 t2 t3 Note that the mount has propagated to the mount at /mnt as well. -- cgit v1.1 From e1455d1bdccbe056ba53479741b1452106ce59aa Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Wed, 6 Oct 2010 10:46:53 +0200 Subject: update block_device_operations documentation Updated Documentation/filesystems/Locking to match the code. Signed-off-by: Christoph Hellwig --- Documentation/filesystems/Locking | 31 +++++++++++++++++++++++-------- 1 file changed, 23 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 2db4283..8a817f6 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -349,21 +349,36 @@ call this method upon the IO completion. --------------------------- block_device_operations ----------------------- prototypes: - int (*open) (struct inode *, struct file *); - int (*release) (struct inode *, struct file *); - int (*ioctl) (struct inode *, struct file *, unsigned, unsigned long); + int (*open) (struct block_device *, fmode_t); + int (*release) (struct gendisk *, fmode_t); + int (*ioctl) (struct block_device *, fmode_t, unsigned, unsigned long); + int (*compat_ioctl) (struct block_device *, fmode_t, unsigned, unsigned long); + int (*direct_access) (struct block_device *, sector_t, void **, unsigned long *); int (*media_changed) (struct gendisk *); + void (*unlock_native_capacity) (struct gendisk *); int (*revalidate_disk) (struct gendisk *); + int (*getgeo)(struct block_device *, struct hd_geometry *); + void (*swap_slot_free_notify) (struct block_device *, unsigned long); locking rules: - BKL bd_sem -open: yes yes -release: yes yes -ioctl: yes no + BKL bd_mutex +open: no yes +release: no yes +ioctl: no no +compat_ioctl: no no +direct_access: no no media_changed: no no +unlock_native_capacity: no no revalidate_disk: no no +getgeo: no no +swap_slot_free_notify: no no (see below) + +media_changed, unlock_native_capacity and revalidate_disk are called only from +check_disk_change(). + +swap_slot_free_notify is called with swap_lock and sometimes the page lock +held. -The last two are called only from check_disk_change(). --------------------------- file_operations ------------------------------- prototypes: -- cgit v1.1 From e340c3537239d5b6a2b21d4245c8577d457b0476 Mon Sep 17 00:00:00 2001 From: "Yang, Bo" Date: Tue, 12 Oct 2010 07:21:59 -0600 Subject: [SCSI] megaraid_sas: Version and documentation update Signed-off-by Bo Yang Signed-off-by: James Bottomley --- Documentation/scsi/ChangeLog.megaraid_sas | 47 +++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) (limited to 'Documentation') diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index 3002356..00301ed 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas @@ -1,3 +1,50 @@ +1 Release Date : Thur. May 03, 2010 09:12:45 PST 2009 - + (emaild-id:megaraidlinux@lsi.com) + Bo Yang + +2 Current Version : 00.00.04.31-rc1 +3 Older Version : 00.00.04.17.1-rc1 + +1. Add the Online Controller Reset (OCR) to the Driver. + OCR is the new feature for megaraid_sas driver which + will allow the fw to do the chip reset which will not + affact the OS behavious. + + To add the OCR support, driver need to do: + a). reset the controller chips -- Xscale and Gen2 which + will change the function calls and add the reset function + related to this two chips. + + b). during the reset, driver will store the pending cmds + which not returned by FW to driver's pending queue. Driver + will re-issue those pending cmds again to FW after the OCR + finished. + + c). In driver's timeout routine, driver will report to + OS as reset. Also driver's queue routine will block the + cmds until the OCR finished. + + d). in Driver's ISR routine, if driver get the FW state as + state change, FW in Failure status and FW support online controller + reset (OCR), driver will start to do the controller reset. + + e). In driver's IOCTL routine, the application cmds will wait for the + OCR to finish, then issue the cmds to FW. + + f). Before driver kill adapter, driver will do last chance of + OCR to see if driver can bring back the FW. + +2. Add the support update flag to the driver to tell LSI megaraid_sas + application which driver will support the device update. So application + will not need to do the device update after application add/del the device + from the system. +3. In driver's timeout routine, driver will do three time reset if fw is in + failed state. Driver will kill adapter if can't bring back FW after the + this three times reset. +4. Add the input parameter max_sectors to 1MB support to our GEN2 controller. + customer can use the input paramenter max_sectors to add 1MB support to GEN2 + controller. + 1 Release Date : Thur. Oct 29, 2009 09:12:45 PST 2009 - (emaild-id:megaraidlinux@lsi.com) Bo Yang -- cgit v1.1 From eb1c86b8b501ad9a073d9d519105979d31fa0ef2 Mon Sep 17 00:00:00 2001 From: Bryan Schumaker Date: Tue, 26 Oct 2010 13:27:42 -0400 Subject: NFS: rename nfs.upcall -> nfs.idmap This patch renames the idmapper upcall program from nfs.upcall to nfs.idmap in the NFS documentation. This is because the program has been renamed in the nfs-utils source. Signed-off-by: Bryan Schumaker Signed-off-by: Trond Myklebust --- Documentation/filesystems/nfs/idmapper.txt | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/nfs/idmapper.txt b/Documentation/filesystems/nfs/idmapper.txt index c385204..b9b4192 100644 --- a/Documentation/filesystems/nfs/idmapper.txt +++ b/Documentation/filesystems/nfs/idmapper.txt @@ -6,7 +6,7 @@ Id mapper is used by NFS to translate user and group ids into names, and to translate user and group names into ids. Part of this translation involves performing an upcall to userspace to request the information. Id mapper will user request-key to perform this upcall and cache the result. The program -/usr/sbin/nfs.upcall should be called by request-key, and will perform the +/usr/sbin/nfs.idmap should be called by request-key, and will perform the translation and initialize a key with the resulting information. NFS_USE_NEW_IDMAPPER must be selected when configuring the kernel to use this @@ -20,12 +20,12 @@ direct the upcall. The following line should be added: #OP TYPE DESCRIPTION CALLOUT INFO PROGRAM ARG1 ARG2 ARG3 ... #====== ======= =============== =============== =============================== -create id_resolver * * /usr/sbin/nfs.upcall %k %d 600 +create id_resolver * * /usr/sbin/nfs.idmap %k %d 600 -This will direct all id_resolver requests to the program /usr/sbin/nfs.upcall. +This will direct all id_resolver requests to the program /usr/sbin/nfs.idmap. The last parameter, 600, defines how many seconds into the future the key will -expire. This parameter is optional for /usr/sbin/nfs.upcall. When the timeout -is not specified, nfs.upcall will default to 600 seconds. +expire. This parameter is optional for /usr/sbin/nfs.idmap. When the timeout +is not specified, nfs.idmap will default to 600 seconds. id mapper uses for key descriptions: uid: Find the UID for the given user @@ -39,29 +39,29 @@ would edit your request-key.conf so it look similar to this: #OP TYPE DESCRIPTION CALLOUT INFO PROGRAM ARG1 ARG2 ARG3 ... #====== ======= =============== =============== =============================== -create id_resolver uid:* * /some/other/program %k %d 600 -create id_resolver * * /usr/sbin/nfs.upcall %k %d 600 +create id_resolver uid:* * /some/other/program %k %d 600 +create id_resolver * * /usr/sbin/nfs.idmap %k %d 600 Notice that the new line was added above the line for the generic program. request-key will find the first matching line and corresponding program. In this case, /some/other/program will handle all uid lookups and -/usr/sbin/nfs.upcall will handle gid, user, and group lookups. +/usr/sbin/nfs.idmap will handle gid, user, and group lookups. See for more information about the request-key function. -========== -nfs.upcall -========== -nfs.upcall is designed to be called by request-key, and should not be run "by +========= +nfs.idmap +========= +nfs.idmap is designed to be called by request-key, and should not be run "by hand". This program takes two arguments, a serialized key and a key description. The serialized key is first converted into a key_serial_t, and then passed as an argument to keyctl_instantiate (both are part of keyutils.h). -The actual lookups are performed by functions found in nfsidmap.h. nfs.upcall +The actual lookups are performed by functions found in nfsidmap.h. nfs.idmap determines the correct function to call by looking at the first part of the description string. For example, a uid lookup description will appear as "uid:user@domain". -nfs.upcall will return 0 if the key was instantiated, and non-zero otherwise. +nfs.idmap will return 0 if the key was instantiated, and non-zero otherwise. -- cgit v1.1 From e7f8567db9a7f6b3151b0b275e245c1cef0d9c70 Mon Sep 17 00:00:00 2001 From: Bjorn Helgaas Date: Tue, 26 Oct 2010 15:41:33 -0600 Subject: resources: support allocating space within a region from the top down Allocate space from the top of a region first, then work downward, if an architecture desires this. When we allocate space from a resource, we look for gaps between children of the resource. Previously, we always looked at gaps from the bottom up. For example, given this: [mem 0xbff00000-0xf7ffffff] PCI Bus 0000:00 [mem 0xbff00000-0xbfffffff] gap -- available [mem 0xc0000000-0xdfffffff] PCI Bus 0000:02 [mem 0xe0000000-0xf7ffffff] gap -- available we attempted to allocate from the [mem 0xbff00000-0xbfffffff] gap first, then the [mem 0xe0000000-0xf7ffffff] gap. With this patch an architecture can choose to allocate from the top gap [mem 0xe0000000-0xf7ffffff] first. We can't do this across the board because iomem_resource.end is initialized to 0xffffffff_ffffffff on 64-bit architectures, and most machines can't address the entire 64-bit physical address space. Therefore, we only allocate top-down if the arch requests it by clearing "resource_alloc_from_bottom". Signed-off-by: Bjorn Helgaas Signed-off-by: Jesse Barnes --- Documentation/kernel-parameters.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 8dd7248..fe50cbd 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2156,6 +2156,11 @@ and is between 256 and 4096 characters. It is defined in the file reset_devices [KNL] Force drivers to reset the underlying device during initialization. + resource_alloc_from_bottom + Allocate new resources from the beginning of available + space, not the end. If you need to use this, please + report a bug. + resume= [SWSUSP] Specify the partition device for software suspend -- cgit v1.1 From 0f4d208f1975f16f269134cee5f44c1f048581da Mon Sep 17 00:00:00 2001 From: Matt Mackall Date: Tue, 26 Oct 2010 14:21:22 -0700 Subject: Documentation/filesystems/proc.txt: improve smaps field documentation Signed-off-by: Matt Mackall Cc: Nikanth Karthikesan Cc: Balbir Singh Cc: Wu Fengguang Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/proc.txt | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index a6aca87..a563b74 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -374,13 +374,13 @@ Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB -The first of these lines shows the same information as is displayed for the -mapping in /proc/PID/maps. The remaining lines show the size of the mapping, -the amount of the mapping that is currently resident in RAM, the "proportional -set size” (divide each shared page by the number of processes sharing it), the -number of clean and dirty shared pages in the mapping, and the number of clean -and dirty private pages in the mapping. The "Referenced" indicates the amount -of memory currently marked as referenced or accessed. +The first of these lines shows the same information as is displayed for the +mapping in /proc/PID/maps. The remaining lines show the size of the mapping +(size), the amount of the mapping that is currently resident in RAM (RSS), the +process' proportional share of this mapping (PSS), the number of clean and +dirty shared pages in the mapping, and the number of clean and dirty private +pages in the mapping. The "Referenced" indicates the amount of memory +currently marked as referenced or accessed. This file is only present if the CONFIG_MMU kernel configuration option is enabled. -- cgit v1.1 From e11da5b4fdf01d71d73c21cb92b00595b917d7fd Mon Sep 17 00:00:00 2001 From: Mel Gorman Date: Tue, 26 Oct 2010 14:21:40 -0700 Subject: tracing, vmscan: add trace events for LRU list shrinking There have been numerous reports of stalls that pointed at the problem being somewhere in the VM. There are multiple roots to the problems which means dealing with any of the root problems in isolation is tricky to justify on their own and they would still need integration testing. This patch series puts together two different patch sets which in combination should tackle some of the root causes of latency problems being reported. Patch 1 adds a tracepoint for shrink_inactive_list. For this series, the most important results is being able to calculate the scanning/reclaim ratio as a measure of the amount of work being done by page reclaim. Patch 2 accounts for time spent in congestion_wait. Patches 3-6 were originally developed by Kosaki Motohiro but reworked for this series. It has been noted that lumpy reclaim is far too aggressive and trashes the system somewhat. As SLUB uses high-order allocations, a large cost incurred by lumpy reclaim will be noticeable. It was also reported during transparent hugepage support testing that lumpy reclaim was trashing the system and these patches should mitigate that problem without disabling lumpy reclaim. Patch 7 adds wait_iff_congested() and replaces some callers of congestion_wait(). wait_iff_congested() only sleeps if there is a BDI that is currently congested. Patch 8 notes that any BDI being congested is not necessarily a problem because there could be multiple BDIs of varying speeds and numberous zones. It attempts to track when a zone being reclaimed contains many pages backed by a congested BDI and if so, reclaimers wait on the congestion queue. I ran a number of tests with monitoring on X86, X86-64 and PPC64. Each machine had 3G of RAM and the CPUs were X86: Intel P4 2-core X86-64: AMD Phenom 4-core PPC64: PPC970MP Each used a single disk and the onboard IO controller. Dirty ratio was left at 20. I'm just going to report for X86-64 and PPC64 in a vague attempt to keep this report short. Four kernels were tested each based on v2.6.36-rc4 traceonly-v2r2: Patches 1 and 2 to instrument vmscan reclaims and congestion_wait lowlumpy-v2r3: Patches 1-6 to test if lumpy reclaim is better waitcongest-v2r3: Patches 1-7 to only wait on congestion waitwriteback-v2r4: Patches 1-8 to detect when a zone is congested nocongest-v1r5: Patches 1-3 for testing wait_iff_congestion nodirect-v1r5: Patches 1-10 to disable filesystem writeback for better IO The tests run were as follows kernbench compile-based benchmark. Smoke test performance sysbench OLTP read-only benchmark. Will be re-run in the future as read-write micro-mapped-file-stream This is a micro-benchmark from Johannes Weiner that accesses a large sparse-file through mmap(). It was configured to run in only single-CPU mode but can be indicative of how well page reclaim identifies suitable pages. stress-highalloc Tries to allocate huge pages under heavy load. kernbench, iozone and sysbench did not report any performance regression on any machine. sysbench did pressure the system lightly and there was reclaim activity but there were no difference of major interest between the kernels. X86-64 micro-mapped-file-stream traceonly-v2r2 lowlumpy-v2r3 waitcongest-v2r3 waitwriteback-v2r4 pgalloc_dma 1639.00 ( 0.00%) 667.00 (-145.73%) 1167.00 ( -40.45%) 578.00 (-183.56%) pgalloc_dma32 2842410.00 ( 0.00%) 2842626.00 ( 0.01%) 2843043.00 ( 0.02%) 2843014.00 ( 0.02%) pgalloc_normal 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) pgsteal_dma 729.00 ( 0.00%) 85.00 (-757.65%) 609.00 ( -19.70%) 125.00 (-483.20%) pgsteal_dma32 2338721.00 ( 0.00%) 2447354.00 ( 4.44%) 2429536.00 ( 3.74%) 2436772.00 ( 4.02%) pgsteal_normal 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) pgscan_kswapd_dma 1469.00 ( 0.00%) 532.00 (-176.13%) 1078.00 ( -36.27%) 220.00 (-567.73%) pgscan_kswapd_dma32 4597713.00 ( 0.00%) 4503597.00 ( -2.09%) 4295673.00 ( -7.03%) 3891686.00 ( -18.14%) pgscan_kswapd_normal 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) pgscan_direct_dma 71.00 ( 0.00%) 134.00 ( 47.01%) 243.00 ( 70.78%) 352.00 ( 79.83%) pgscan_direct_dma32 305820.00 ( 0.00%) 280204.00 ( -9.14%) 600518.00 ( 49.07%) 957485.00 ( 68.06%) pgscan_direct_normal 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) pageoutrun 16296.00 ( 0.00%) 21254.00 ( 23.33%) 18447.00 ( 11.66%) 20067.00 ( 18.79%) allocstall 443.00 ( 0.00%) 273.00 ( -62.27%) 513.00 ( 13.65%) 1568.00 ( 71.75%) These are based on the raw figures taken from /proc/vmstat. It's a rough measure of reclaim activity. Note that allocstall counts are higher because we are entering direct reclaim more often as a result of not sleeping in congestion. In itself, it's not necessarily a bad thing. It's easier to get a view of what happened from the vmscan tracepoint report. FTrace Reclaim Statistics: vmscan traceonly-v2r2 lowlumpy-v2r3 waitcongest-v2r3 waitwriteback-v2r4 Direct reclaims 443 273 513 1568 Direct reclaim pages scanned 305968 280402 600825 957933 Direct reclaim pages reclaimed 43503 19005 30327 117191 Direct reclaim write file async I/O 0 0 0 0 Direct reclaim write anon async I/O 0 3 4 12 Direct reclaim write file sync I/O 0 0 0 0 Direct reclaim write anon sync I/O 0 0 0 0 Wake kswapd requests 187649 132338 191695 267701 Kswapd wakeups 3 1 4 1 Kswapd pages scanned 4599269 4454162 4296815 3891906 Kswapd pages reclaimed 2295947 2428434 2399818 2319706 Kswapd reclaim write file async I/O 1 0 1 1 Kswapd reclaim write anon async I/O 59 187 41 222 Kswapd reclaim write file sync I/O 0 0 0 0 Kswapd reclaim write anon sync I/O 0 0 0 0 Time stalled direct reclaim (seconds) 4.34 2.52 6.63 2.96 Time kswapd awake (seconds) 11.15 10.25 11.01 10.19 Total pages scanned 4905237 4734564 4897640 4849839 Total pages reclaimed 2339450 2447439 2430145 2436897 %age total pages scanned/reclaimed 47.69% 51.69% 49.62% 50.25% %age total pages scanned/written 0.00% 0.00% 0.00% 0.00% %age file pages scanned/written 0.00% 0.00% 0.00% 0.00% Percentage Time Spent Direct Reclaim 29.23% 19.02% 38.48% 20.25% Percentage Time kswapd Awake 78.58% 78.85% 76.83% 79.86% What is interesting here for nocongest in particular is that while direct reclaim scans more pages, the overall number of pages scanned remains the same and the ratio of pages scanned to pages reclaimed is more or less the same. In other words, while we are sleeping less, reclaim is not doing more work and as direct reclaim and kswapd is awake for less time, it would appear to be doing less work. FTrace Reclaim Statistics: congestion_wait Direct number congest waited 87 196 64 0 Direct time congest waited 4604ms 4732ms 5420ms 0ms Direct full congest waited 72 145 53 0 Direct number conditional waited 0 0 324 1315 Direct time conditional waited 0ms 0ms 0ms 0ms Direct full conditional waited 0 0 0 0 KSwapd number congest waited 20 10 15 7 KSwapd time congest waited 1264ms 536ms 884ms 284ms KSwapd full congest waited 10 4 6 2 KSwapd number conditional waited 0 0 0 0 KSwapd time conditional waited 0ms 0ms 0ms 0ms KSwapd full conditional waited 0 0 0 0 The vanilla kernel spent 8 seconds asleep in direct reclaim and no time at all asleep with the patches. MMTests Statistics: duration User/Sys Time Running Test (seconds) 10.51 10.73 10.6 11.66 Total Elapsed Time (seconds) 14.19 13.00 14.33 12.76 Overall, the tests completed faster. It is interesting to note that backing off further when a zone is congested and not just a BDI was more efficient overall. PPC64 micro-mapped-file-stream pgalloc_dma 3024660.00 ( 0.00%) 3027185.00 ( 0.08%) 3025845.00 ( 0.04%) 3026281.00 ( 0.05%) pgalloc_normal 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) pgsteal_dma 2508073.00 ( 0.00%) 2565351.00 ( 2.23%) 2463577.00 ( -1.81%) 2532263.00 ( 0.96%) pgsteal_normal 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) pgscan_kswapd_dma 4601307.00 ( 0.00%) 4128076.00 ( -11.46%) 3912317.00 ( -17.61%) 3377165.00 ( -36.25%) pgscan_kswapd_normal 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) pgscan_direct_dma 629825.00 ( 0.00%) 971622.00 ( 35.18%) 1063938.00 ( 40.80%) 1711935.00 ( 63.21%) pgscan_direct_normal 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) 0.00 ( 0.00%) pageoutrun 27776.00 ( 0.00%) 20458.00 ( -35.77%) 18763.00 ( -48.04%) 18157.00 ( -52.98%) allocstall 977.00 ( 0.00%) 2751.00 ( 64.49%) 2098.00 ( 53.43%) 5136.00 ( 80.98%) Similar trends to x86-64. allocstalls are up but it's not necessarily bad. FTrace Reclaim Statistics: vmscan Direct reclaims 977 2709 2098 5136 Direct reclaim pages scanned 629825 963814 1063938 1711935 Direct reclaim pages reclaimed 75550 242538 150904 387647 Direct reclaim write file async I/O 0 0 0 2 Direct reclaim write anon async I/O 0 10 0 4 Direct reclaim write file sync I/O 0 0 0 0 Direct reclaim write anon sync I/O 0 0 0 0 Wake kswapd requests 392119 1201712 571935 571921 Kswapd wakeups 3 2 3 3 Kswapd pages scanned 4601307 4128076 3912317 3377165 Kswapd pages reclaimed 2432523 2318797 2312673 2144616 Kswapd reclaim write file async I/O 20 1 1 1 Kswapd reclaim write anon async I/O 57 132 11 121 Kswapd reclaim write file sync I/O 0 0 0 0 Kswapd reclaim write anon sync I/O 0 0 0 0 Time stalled direct reclaim (seconds) 6.19 7.30 13.04 10.88 Time kswapd awake (seconds) 21.73 26.51 25.55 23.90 Total pages scanned 5231132 5091890 4976255 5089100 Total pages reclaimed 2508073 2561335 2463577 2532263 %age total pages scanned/reclaimed 47.95% 50.30% 49.51% 49.76% %age total pages scanned/written 0.00% 0.00% 0.00% 0.00% %age file pages scanned/written 0.00% 0.00% 0.00% 0.00% Percentage Time Spent Direct Reclaim 18.89% 20.65% 32.65% 27.65% Percentage Time kswapd Awake 72.39% 80.68% 78.21% 77.40% Again, a similar trend that the congestion_wait changes mean that direct reclaim scans more pages but the overall number of pages scanned while slightly reduced, are very similar. The ratio of scanning/reclaimed remains roughly similar. The downside is that kswapd and direct reclaim was awake longer and for a larger percentage of the overall workload. It's possible there were big differences in the amount of time spent reclaiming slab pages between the different kernels which is plausible considering that the micro tests runs after fsmark and sysbench. Trace Reclaim Statistics: congestion_wait Direct number congest waited 845 1312 104 0 Direct time congest waited 19416ms 26560ms 7544ms 0ms Direct full congest waited 745 1105 72 0 Direct number conditional waited 0 0 1322 2935 Direct time conditional waited 0ms 0ms 12ms 312ms Direct full conditional waited 0 0 0 3 KSwapd number congest waited 39 102 75 63 KSwapd time congest waited 2484ms 6760ms 5756ms 3716ms KSwapd full congest waited 20 48 46 25 KSwapd number conditional waited 0 0 0 0 KSwapd time conditional waited 0ms 0ms 0ms 0ms KSwapd full conditional waited 0 0 0 0 The vanilla kernel spent 20 seconds asleep in direct reclaim and only 312ms asleep with the patches. The time kswapd spent congest waited was also reduced by a large factor. MMTests Statistics: duration ser/Sys Time Running Test (seconds) 26.58 28.05 26.9 28.47 Total Elapsed Time (seconds) 30.02 32.86 32.67 30.88 With all patches applies, the completion times are very similar. X86-64 STRESS-HIGHALLOC traceonly-v2r2 lowlumpy-v2r3 waitcongest-v2r3waitwriteback-v2r4 Pass 1 82.00 ( 0.00%) 84.00 ( 2.00%) 85.00 ( 3.00%) 85.00 ( 3.00%) Pass 2 90.00 ( 0.00%) 87.00 (-3.00%) 88.00 (-2.00%) 89.00 (-1.00%) At Rest 92.00 ( 0.00%) 90.00 (-2.00%) 90.00 (-2.00%) 91.00 (-1.00%) Success figures across the board are broadly similar. traceonly-v2r2 lowlumpy-v2r3 waitcongest-v2r3waitwriteback-v2r4 Direct reclaims 1045 944 886 887 Direct reclaim pages scanned 135091 119604 109382 101019 Direct reclaim pages reclaimed 88599 47535 47863 46671 Direct reclaim write file async I/O 494 283 465 280 Direct reclaim write anon async I/O 29357 13710 16656 13462 Direct reclaim write file sync I/O 154 2 2 3 Direct reclaim write anon sync I/O 14594 571 509 561 Wake kswapd requests 7491 933 872 892 Kswapd wakeups 814 778 731 780 Kswapd pages scanned 7290822 15341158 11916436 13703442 Kswapd pages reclaimed 3587336 3142496 3094392 3187151 Kswapd reclaim write file async I/O 91975 32317 28022 29628 Kswapd reclaim write anon async I/O 1992022 789307 829745 849769 Kswapd reclaim write file sync I/O 0 0 0 0 Kswapd reclaim write anon sync I/O 0 0 0 0 Time stalled direct reclaim (seconds) 4588.93 2467.16 2495.41 2547.07 Time kswapd awake (seconds) 2497.66 1020.16 1098.06 1176.82 Total pages scanned 7425913 15460762 12025818 13804461 Total pages reclaimed 3675935 3190031 3142255 3233822 %age total pages scanned/reclaimed 49.50% 20.63% 26.13% 23.43% %age total pages scanned/written 28.66% 5.41% 7.28% 6.47% %age file pages scanned/written 1.25% 0.21% 0.24% 0.22% Percentage Time Spent Direct Reclaim 57.33% 42.15% 42.41% 42.99% Percentage Time kswapd Awake 43.56% 27.87% 29.76% 31.25% Scanned/reclaimed ratios again look good with big improvements in efficiency. The Scanned/written ratios also look much improved. With a better scanned/written ration, there is an expectation that IO would be more efficient and indeed, the time spent in direct reclaim is much reduced by the full series and kswapd spends a little less time awake. Overall, indications here are that allocations were happening much faster and this can be seen with a graph of the latency figures as the allocations were taking place http://www.csn.ul.ie/~mel/postings/vmscanreduce-20101509/highalloc-interlatency-hydra-mean.ps FTrace Reclaim Statistics: congestion_wait Direct number congest waited 1333 204 169 4 Direct time congest waited 78896ms 8288ms 7260ms 200ms Direct full congest waited 756 92 69 2 Direct number conditional waited 0 0 26 186 Direct time conditional waited 0ms 0ms 0ms 2504ms Direct full conditional waited 0 0 0 25 KSwapd number congest waited 4 395 227 282 KSwapd time congest waited 384ms 25136ms 10508ms 18380ms KSwapd full congest waited 3 232 98 176 KSwapd number conditional waited 0 0 0 0 KSwapd time conditional waited 0ms 0ms 0ms 0ms KSwapd full conditional waited 0 0 0 0 KSwapd full conditional waited 318 0 312 9 Overall, the time spent speeping is reduced. kswapd is still hitting congestion_wait() but that is because there are callers remaining where it wasn't clear in advance if they should be changed to wait_iff_congested() or not. Overall the sleep imes are reduced though - from 79ish seconds to about 19. MMTests Statistics: duration User/Sys Time Running Test (seconds) 3415.43 3386.65 3388.39 3377.5 Total Elapsed Time (seconds) 5733.48 3660.33 3689.41 3765.39 With the full series, the time to complete the tests are reduced by 30% PPC64 STRESS-HIGHALLOC traceonly-v2r2 lowlumpy-v2r3 waitcongest-v2r3waitwriteback-v2r4 Pass 1 17.00 ( 0.00%) 34.00 (17.00%) 38.00 (21.00%) 43.00 (26.00%) Pass 2 25.00 ( 0.00%) 37.00 (12.00%) 42.00 (17.00%) 46.00 (21.00%) At Rest 49.00 ( 0.00%) 43.00 (-6.00%) 45.00 (-4.00%) 51.00 ( 2.00%) Success rates there are *way* up particularly considering that the 16MB huge pages on PPC64 mean that it's always much harder to allocate them. FTrace Reclaim Statistics: vmscan stress-highalloc stress-highalloc stress-highalloc stress-highalloc traceonly-v2r2 lowlumpy-v2r3 waitcongest-v2r3waitwriteback-v2r4 Direct reclaims 499 505 564 509 Direct reclaim pages scanned 223478 41898 51818 45605 Direct reclaim pages reclaimed 137730 21148 27161 23455 Direct reclaim write file async I/O 399 136 162 136 Direct reclaim write anon async I/O 46977 2865 4686 3998 Direct reclaim write file sync I/O 29 0 1 3 Direct reclaim write anon sync I/O 31023 159 237 239 Wake kswapd requests 420 351 360 326 Kswapd wakeups 185 294 249 277 Kswapd pages scanned 15703488 16392500 17821724 17598737 Kswapd pages reclaimed 5808466 2908858 3139386 3145435 Kswapd reclaim write file async I/O 159938 18400 18717 13473 Kswapd reclaim write anon async I/O 3467554 228957 322799 234278 Kswapd reclaim write file sync I/O 0 0 0 0 Kswapd reclaim write anon sync I/O 0 0 0 0 Time stalled direct reclaim (seconds) 9665.35 1707.81 2374.32 1871.23 Time kswapd awake (seconds) 9401.21 1367.86 1951.75 1328.88 Total pages scanned 15926966 16434398 17873542 17644342 Total pages reclaimed 5946196 2930006 3166547 3168890 %age total pages scanned/reclaimed 37.33% 17.83% 17.72% 17.96% %age total pages scanned/written 23.27% 1.52% 1.94% 1.43% %age file pages scanned/written 1.01% 0.11% 0.11% 0.08% Percentage Time Spent Direct Reclaim 44.55% 35.10% 41.42% 36.91% Percentage Time kswapd Awake 86.71% 43.58% 52.67% 41.14% While the scanning rates are slightly up, the scanned/reclaimed and scanned/written figures are much improved. The time spent in direct reclaim and with kswapd are massively reduced, mostly by the lowlumpy patches. FTrace Reclaim Statistics: congestion_wait Direct number congest waited 725 303 126 3 Direct time congest waited 45524ms 9180ms 5936ms 300ms Direct full congest waited 487 190 52 3 Direct number conditional waited 0 0 200 301 Direct time conditional waited 0ms 0ms 0ms 1904ms Direct full conditional waited 0 0 0 19 KSwapd number congest waited 0 2 23 4 KSwapd time congest waited 0ms 200ms 420ms 404ms KSwapd full congest waited 0 2 2 4 KSwapd number conditional waited 0 0 0 0 KSwapd time conditional waited 0ms 0ms 0ms 0ms KSwapd full conditional waited 0 0 0 0 Not as dramatic a story here but the time spent asleep is reduced and we can still see what wait_iff_congested is going to sleep when necessary. MMTests Statistics: duration User/Sys Time Running Test (seconds) 12028.09 3157.17 3357.79 3199.16 Total Elapsed Time (seconds) 10842.07 3138.72 3705.54 3229.85 The time to complete this test goes way down. With the full series, we are allocating over twice the number of huge pages in 30% of the time and there is a corresponding impact on the allocation latency graph available at. http://www.csn.ul.ie/~mel/postings/vmscanreduce-20101509/highalloc-interlatency-powyah-mean.ps This patch: Add a trace event for shrink_inactive_list() and updates the sample postprocessing script appropriately. It can be used to determine how many pages were reclaimed and for non-lumpy reclaim where exactly the pages were reclaimed from. Signed-off-by: Mel Gorman Cc: Johannes Weiner Cc: Minchan Kim Cc: Wu Fengguang Cc: KAMEZAWA Hiroyuki Cc: KOSAKI Motohiro Cc: Rik van Riel Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- .../trace/postprocess/trace-vmscan-postprocess.pl | 39 ++++++++++++++++------ 1 file changed, 29 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl index 1b55146..b3e73dd 100644 --- a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl +++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl @@ -46,7 +46,7 @@ use constant HIGH_KSWAPD_LATENCY => 20; use constant HIGH_KSWAPD_REWAKEUP => 21; use constant HIGH_NR_SCANNED => 22; use constant HIGH_NR_TAKEN => 23; -use constant HIGH_NR_RECLAIM => 24; +use constant HIGH_NR_RECLAIMED => 24; use constant HIGH_NR_CONTIG_DIRTY => 25; my %perprocesspid; @@ -58,11 +58,13 @@ my $opt_read_procstat; my $total_wakeup_kswapd; my ($total_direct_reclaim, $total_direct_nr_scanned); my ($total_direct_latency, $total_kswapd_latency); +my ($total_direct_nr_reclaimed); my ($total_direct_writepage_file_sync, $total_direct_writepage_file_async); my ($total_direct_writepage_anon_sync, $total_direct_writepage_anon_async); my ($total_kswapd_nr_scanned, $total_kswapd_wake); my ($total_kswapd_writepage_file_sync, $total_kswapd_writepage_file_async); my ($total_kswapd_writepage_anon_sync, $total_kswapd_writepage_anon_async); +my ($total_kswapd_nr_reclaimed); # Catch sigint and exit on request my $sigint_report = 0; @@ -104,7 +106,7 @@ my $regex_kswapd_wake_default = 'nid=([0-9]*) order=([0-9]*)'; my $regex_kswapd_sleep_default = 'nid=([0-9]*)'; my $regex_wakeup_kswapd_default = 'nid=([0-9]*) zid=([0-9]*) order=([0-9]*)'; my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_taken=([0-9]*) contig_taken=([0-9]*) contig_dirty=([0-9]*) contig_failed=([0-9]*)'; -my $regex_lru_shrink_inactive_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) priority=([0-9]*)'; +my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) zid=([0-9]*) nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)'; my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) nr_rotated=([0-9]*) priority=([0-9]*)'; my $regex_writepage_default = 'page=([0-9a-f]*) pfn=([0-9]*) flags=([A-Z_|]*)'; @@ -203,8 +205,8 @@ $regex_lru_shrink_inactive = generate_traceevent_regex( "vmscan/mm_vmscan_lru_shrink_inactive", $regex_lru_shrink_inactive_default, "nid", "zid", - "lru", - "nr_scanned", "nr_reclaimed", "priority"); + "nr_scanned", "nr_reclaimed", "priority", + "flags"); $regex_lru_shrink_active = generate_traceevent_regex( "vmscan/mm_vmscan_lru_shrink_active", $regex_lru_shrink_active_default, @@ -375,6 +377,16 @@ EVENT_PROCESS: my $nr_contig_dirty = $7; $perprocesspid{$process_pid}->{HIGH_NR_SCANNED} += $nr_scanned; $perprocesspid{$process_pid}->{HIGH_NR_CONTIG_DIRTY} += $nr_contig_dirty; + } elsif ($tracepoint eq "mm_vmscan_lru_shrink_inactive") { + $details = $5; + if ($details !~ /$regex_lru_shrink_inactive/o) { + print "WARNING: Failed to parse mm_vmscan_lru_shrink_inactive as expected\n"; + print " $details\n"; + print " $regex_lru_shrink_inactive/o\n"; + next; + } + my $nr_reclaimed = $4; + $perprocesspid{$process_pid}->{HIGH_NR_RECLAIMED} += $nr_reclaimed; } elsif ($tracepoint eq "mm_vmscan_writepage") { $details = $5; if ($details !~ /$regex_writepage/o) { @@ -464,8 +476,8 @@ sub dump_stats { # Print out process activity printf("\n"); - printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s %8s\n", "Process", "Direct", "Wokeup", "Pages", "Pages", "Pages", "Time"); - printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s %8s\n", "details", "Rclms", "Kswapd", "Scanned", "Sync-IO", "ASync-IO", "Stalled"); + printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s %8s %8s\n", "Process", "Direct", "Wokeup", "Pages", "Pages", "Pages", "Pages", "Time"); + printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s %8s %8s\n", "details", "Rclms", "Kswapd", "Scanned", "Rclmed", "Sync-IO", "ASync-IO", "Stalled"); foreach $process_pid (keys %stats) { if (!$stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}) { @@ -475,6 +487,7 @@ sub dump_stats { $total_direct_reclaim += $stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}; $total_wakeup_kswapd += $stats{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}; $total_direct_nr_scanned += $stats{$process_pid}->{HIGH_NR_SCANNED}; + $total_direct_nr_reclaimed += $stats{$process_pid}->{HIGH_NR_RECLAIMED}; $total_direct_writepage_file_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC}; $total_direct_writepage_anon_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}; $total_direct_writepage_file_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC}; @@ -489,11 +502,12 @@ sub dump_stats { $index++; } - printf("%-" . $max_strlen . "s %8d %10d %8u %8u %8u %8.3f", + printf("%-" . $max_strlen . "s %8d %10d %8u %8u %8u %8u %8.3f", $process_pid, $stats{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}, $stats{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}, $stats{$process_pid}->{HIGH_NR_SCANNED}, + $stats{$process_pid}->{HIGH_NR_RECLAIMED}, $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}, $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}, $this_reclaim_delay / 1000); @@ -529,8 +543,8 @@ sub dump_stats { # Print out kswapd activity printf("\n"); - printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s\n", "Kswapd", "Kswapd", "Order", "Pages", "Pages", "Pages"); - printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s\n", "Instance", "Wakeups", "Re-wakeup", "Scanned", "Sync-IO", "ASync-IO"); + printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s\n", "Kswapd", "Kswapd", "Order", "Pages", "Pages", "Pages", "Pages"); + printf("%-" . $max_strlen . "s %8s %10s %8s %8s %8s %8s\n", "Instance", "Wakeups", "Re-wakeup", "Scanned", "Rclmed", "Sync-IO", "ASync-IO"); foreach $process_pid (keys %stats) { if (!$stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}) { @@ -539,16 +553,18 @@ sub dump_stats { $total_kswapd_wake += $stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}; $total_kswapd_nr_scanned += $stats{$process_pid}->{HIGH_NR_SCANNED}; + $total_kswapd_nr_reclaimed += $stats{$process_pid}->{HIGH_NR_RECLAIMED}; $total_kswapd_writepage_file_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC}; $total_kswapd_writepage_anon_sync += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}; $total_kswapd_writepage_file_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC}; $total_kswapd_writepage_anon_async += $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}; - printf("%-" . $max_strlen . "s %8d %10d %8u %8i %8u", + printf("%-" . $max_strlen . "s %8d %10d %8u %8u %8i %8u", $process_pid, $stats{$process_pid}->{MM_VMSCAN_KSWAPD_WAKE}, $stats{$process_pid}->{HIGH_KSWAPD_REWAKEUP}, $stats{$process_pid}->{HIGH_NR_SCANNED}, + $stats{$process_pid}->{HIGH_NR_RECLAIMED}, $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}, $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} + $stats{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_ASYNC}); @@ -579,6 +595,7 @@ sub dump_stats { print "\nSummary\n"; print "Direct reclaims: $total_direct_reclaim\n"; print "Direct reclaim pages scanned: $total_direct_nr_scanned\n"; + print "Direct reclaim pages reclaimed: $total_direct_nr_reclaimed\n"; print "Direct reclaim write file sync I/O: $total_direct_writepage_file_sync\n"; print "Direct reclaim write anon sync I/O: $total_direct_writepage_anon_sync\n"; print "Direct reclaim write file async I/O: $total_direct_writepage_file_async\n"; @@ -588,6 +605,7 @@ sub dump_stats { print "\n"; print "Kswapd wakeups: $total_kswapd_wake\n"; print "Kswapd pages scanned: $total_kswapd_nr_scanned\n"; + print "Kswapd pages reclaimed: $total_kswapd_nr_reclaimed\n"; print "Kswapd reclaim write file sync I/O: $total_kswapd_writepage_file_sync\n"; print "Kswapd reclaim write anon sync I/O: $total_kswapd_writepage_anon_sync\n"; print "Kswapd reclaim write file async I/O: $total_kswapd_writepage_file_async\n"; @@ -612,6 +630,7 @@ sub aggregate_perprocesspid() { $perprocess{$process}->{MM_VMSCAN_WAKEUP_KSWAPD} += $perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}; $perprocess{$process}->{HIGH_KSWAPD_REWAKEUP} += $perprocesspid{$process_pid}->{HIGH_KSWAPD_REWAKEUP}; $perprocess{$process}->{HIGH_NR_SCANNED} += $perprocesspid{$process_pid}->{HIGH_NR_SCANNED}; + $perprocess{$process}->{HIGH_NR_RECLAIMED} += $perprocesspid{$process_pid}->{HIGH_NR_RECLAIMED}; $perprocess{$process}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_SYNC}; $perprocess{$process}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_ANON_SYNC}; $perprocess{$process}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC} += $perprocesspid{$process_pid}->{MM_VMSCAN_WRITEPAGE_FILE_ASYNC}; -- cgit v1.1 From d65bfacb046f3df8aa11a9cb9b6e448f6171174d Mon Sep 17 00:00:00 2001 From: Peter Zijlstra Date: Tue, 26 Oct 2010 14:21:54 -0700 Subject: mm: highmem documentation Document outlining some of the highmem issues, started by me, edited by David. Signed-off-by: David Howells Signed-off-by: Peter Zijlstra Acked-by: Chris Metcalf Cc: Hugh Dickins Cc: Rik van Riel Cc: Ingo Molnar Cc: Thomas Gleixner Cc: "H. Peter Anvin" Cc: Steven Rostedt Cc: Russell King Cc: Ralf Baechle Cc: David Miller Cc: Paul Mackerras Cc: Benjamin Herrenschmidt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/highmem.txt | 162 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 162 insertions(+) create mode 100644 Documentation/vm/highmem.txt (limited to 'Documentation') diff --git a/Documentation/vm/highmem.txt b/Documentation/vm/highmem.txt new file mode 100644 index 0000000..4324d24 --- /dev/null +++ b/Documentation/vm/highmem.txt @@ -0,0 +1,162 @@ + + ==================== + HIGH MEMORY HANDLING + ==================== + +By: Peter Zijlstra + +Contents: + + (*) What is high memory? + + (*) Temporary virtual mappings. + + (*) Using kmap_atomic. + + (*) Cost of temporary mappings. + + (*) i386 PAE. + + +==================== +WHAT IS HIGH MEMORY? +==================== + +High memory (highmem) is used when the size of physical memory approaches or +exceeds the maximum size of virtual memory. At that point it becomes +impossible for the kernel to keep all of the available physical memory mapped +at all times. This means the kernel needs to start using temporary mappings of +the pieces of physical memory that it wants to access. + +The part of (physical) memory not covered by a permanent mapping is what we +refer to as 'highmem'. There are various architecture dependent constraints on +where exactly that border lies. + +In the i386 arch, for example, we choose to map the kernel into every process's +VM space so that we don't have to pay the full TLB invalidation costs for +kernel entry/exit. This means the available virtual memory space (4GiB on +i386) has to be divided between user and kernel space. + +The traditional split for architectures using this approach is 3:1, 3GiB for +userspace and the top 1GiB for kernel space: + + +--------+ 0xffffffff + | Kernel | + +--------+ 0xc0000000 + | | + | User | + | | + +--------+ 0x00000000 + +This means that the kernel can at most map 1GiB of physical memory at any one +time, but because we need virtual address space for other things - including +temporary maps to access the rest of the physical memory - the actual direct +map will typically be less (usually around ~896MiB). + +Other architectures that have mm context tagged TLBs can have separate kernel +and user maps. Some hardware (like some ARMs), however, have limited virtual +space when they use mm context tags. + + +========================== +TEMPORARY VIRTUAL MAPPINGS +========================== + +The kernel contains several ways of creating temporary mappings: + + (*) vmap(). This can be used to make a long duration mapping of multiple + physical pages into a contiguous virtual space. It needs global + synchronization to unmap. + + (*) kmap(). This permits a short duration mapping of a single page. It needs + global synchronization, but is amortized somewhat. It is also prone to + deadlocks when using in a nested fashion, and so it is not recommended for + new code. + + (*) kmap_atomic(). This permits a very short duration mapping of a single + page. Since the mapping is restricted to the CPU that issued it, it + performs well, but the issuing task is therefore required to stay on that + CPU until it has finished, lest some other task displace its mappings. + + kmap_atomic() may also be used by interrupt contexts, since it is does not + sleep and the caller may not sleep until after kunmap_atomic() is called. + + It may be assumed that k[un]map_atomic() won't fail. + + +================= +USING KMAP_ATOMIC +================= + +When and where to use kmap_atomic() is straightforward. It is used when code +wants to access the contents of a page that might be allocated from high memory +(see __GFP_HIGHMEM), for example a page in the pagecache. The API has two +functions, and they can be used in a manner similar to the following: + + /* Find the page of interest. */ + struct page *page = find_get_page(mapping, offset); + + /* Gain access to the contents of that page. */ + void *vaddr = kmap_atomic(page); + + /* Do something to the contents of that page. */ + memset(vaddr, 0, PAGE_SIZE); + + /* Unmap that page. */ + kunmap_atomic(vaddr); + +Note that the kunmap_atomic() call takes the result of the kmap_atomic() call +not the argument. + +If you need to map two pages because you want to copy from one page to +another you need to keep the kmap_atomic calls strictly nested, like: + + vaddr1 = kmap_atomic(page1); + vaddr2 = kmap_atomic(page2); + + memcpy(vaddr1, vaddr2, PAGE_SIZE); + + kunmap_atomic(vaddr2); + kunmap_atomic(vaddr1); + + +========================== +COST OF TEMPORARY MAPPINGS +========================== + +The cost of creating temporary mappings can be quite high. The arch has to +manipulate the kernel's page tables, the data TLB and/or the MMU's registers. + +If CONFIG_HIGHMEM is not set, then the kernel will try and create a mapping +simply with a bit of arithmetic that will convert the page struct address into +a pointer to the page contents rather than juggling mappings about. In such a +case, the unmap operation may be a null operation. + +If CONFIG_MMU is not set, then there can be no temporary mappings and no +highmem. In such a case, the arithmetic approach will also be used. + + +======== +i386 PAE +======== + +The i386 arch, under some circumstances, will permit you to stick up to 64GiB +of RAM into your 32-bit machine. This has a number of consequences: + + (*) Linux needs a page-frame structure for each page in the system and the + pageframes need to live in the permanent mapping, which means: + + (*) you can have 896M/sizeof(struct page) page-frames at most; with struct + page being 32-bytes that would end up being something in the order of 112G + worth of pages; the kernel, however, needs to store more than just + page-frames in that memory... + + (*) PAE makes your page tables larger - which slows the system down as more + data has to be accessed to traverse in TLB fills and the like. One + advantage is that PAE has more PTE bits and can provide advanced features + like NX and PAT. + +The general recommendation is that you don't use more than 8GiB on a 32-bit +machine - although more might work for you and your workload, you're pretty +much on your own - don't expect kernel developers to really care much if things +come apart. -- cgit v1.1 From aaaddfe0b3bb449b8734bf29bbd36141076e5277 Mon Sep 17 00:00:00 2001 From: Jaswinder Singh Rajput Date: Tue, 26 Oct 2010 14:22:14 -0700 Subject: Documentation/timers/hpet_example.c: add supporting info for hpet_example $./hpet_example info /dev/hpet -hpet: executing info hpet_info: hi_irqfreq 0x0 hi_flags 0x0 hi_hpet 0 hi_timer 2 Signed-off-by: Jaswinder Singh Rajput Cc: Clemens Ladisch Cc: "Venkatesh Pallipadi (Venki)" Cc: john stultz Cc: Thomas Gleixner Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/timers/hpet_example.c | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) (limited to 'Documentation') diff --git a/Documentation/timers/hpet_example.c b/Documentation/timers/hpet_example.c index 4bfafb7..9a3e701 100644 --- a/Documentation/timers/hpet_example.c +++ b/Documentation/timers/hpet_example.c @@ -97,6 +97,33 @@ hpet_open_close(int argc, const char **argv) void hpet_info(int argc, const char **argv) { + struct hpet_info info; + int fd; + + if (argc != 1) { + fprintf(stderr, "hpet_info: device-name\n"); + return; + } + + fd = open(argv[0], O_RDONLY); + if (fd < 0) { + fprintf(stderr, "hpet_info: open of %s failed\n", argv[0]); + return; + } + + if (ioctl(fd, HPET_INFO, &info) < 0) { + fprintf(stderr, "hpet_info: failed to get info\n"); + goto out; + } + + fprintf(stderr, "hpet_info: hi_irqfreq 0x%lx hi_flags 0x%lx ", + info.hi_ireqfreq, info.hi_flags); + fprintf(stderr, "hi_hpet %d hi_timer %d\n", + info.hi_hpet, info.hi_timer); + +out: + close(fd); + return; } void -- cgit v1.1 From 3f0f4a3f2008613c601e97f773dbd80ac400e459 Mon Sep 17 00:00:00 2001 From: Samu Onkalo Date: Tue, 26 Oct 2010 14:22:39 -0700 Subject: Documentation: short descriptions for bh1770glc and apds990x drivers Add short documentation for two ALS / proximity chip drivers. Signed-off-by: Samu Onkalo Acked-by: Jonathan Cameron Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/misc-devices/apds990x.txt | 111 +++++++++++++++++++++++++++++ Documentation/misc-devices/bh1770glc.txt | 116 +++++++++++++++++++++++++++++++ 2 files changed, 227 insertions(+) create mode 100644 Documentation/misc-devices/apds990x.txt create mode 100644 Documentation/misc-devices/bh1770glc.txt (limited to 'Documentation') diff --git a/Documentation/misc-devices/apds990x.txt b/Documentation/misc-devices/apds990x.txt new file mode 100644 index 0000000..d5408ca --- /dev/null +++ b/Documentation/misc-devices/apds990x.txt @@ -0,0 +1,111 @@ +Kernel driver apds990x +====================== + +Supported chips: +Avago APDS990X + +Data sheet: +Not freely available + +Author: +Samu Onkalo + +Description +----------- + +APDS990x is a combined ambient light and proximity sensor. ALS and proximity +functionality are highly connected. ALS measurement path must be running +while the proximity functionality is enabled. + +ALS produces raw measurement values for two channels: Clear channel +(infrared + visible light) and IR only. However, threshold comparisons happen +using clear channel only. Lux value and the threshold level on the HW +might vary quite much depending the spectrum of the light source. + +Driver makes necessary conversions to both directions so that user handles +only lux values. Lux value is calculated using information from the both +channels. HW threshold level is calculated from the given lux value to match +with current type of the lightning. Sometimes inaccuracy of the estimations +lead to false interrupt, but that doesn't harm. + +ALS contains 4 different gain steps. Driver automatically +selects suitable gain step. After each measurement, reliability of the results +is estimated and new measurement is trigged if necessary. + +Platform data can provide tuned values to the conversion formulas if +values are known. Otherwise plain sensor default values are used. + +Proximity side is little bit simpler. There is no need for complex conversions. +It produces directly usable values. + +Driver controls chip operational state using pm_runtime framework. +Voltage regulators are controlled based on chip operational state. + +SYSFS +----- + + +chip_id + RO - shows detected chip type and version + +power_state + RW - enable / disable chip. Uses counting logic + 1 enables the chip + 0 disables the chip +lux0_input + RO - measured lux value + sysfs_notify called when threshold interrupt occurs + +lux0_sensor_range + RO - lux0_input max value. Actually never reaches since sensor tends + to saturate much before that. Real max value varies depending + on the light spectrum etc. + +lux0_rate + RW - measurement rate in Hz + +lux0_rate_avail + RO - supported measurement rates + +lux0_calibscale + RW - calibration value. Set to neutral value by default. + Output results are multiplied with calibscale / calibscale_default + value. + +lux0_calibscale_default + RO - neutral calibration value + +lux0_thresh_above_value + RW - HI level threshold value. All results above the value + trigs an interrupt. 65535 (i.e. sensor_range) disables the above + interrupt. + +lux0_thresh_below_value + RW - LO level threshold value. All results below the value + trigs an interrupt. 0 disables the below interrupt. + +prox0_raw + RO - measured proximity value + sysfs_notify called when threshold interrupt occurs + +prox0_sensor_range + RO - prox0_raw max value (1023) + +prox0_raw_en + RW - enable / disable proximity - uses counting logic + 1 enables the proximity + 0 disables the proximity + +prox0_reporting_mode + RW - trigger / periodic. In "trigger" mode the driver tells two possible + values: 0 or prox0_sensor_range value. 0 means no proximity, + 1023 means proximity. This causes minimal number of interrupts. + In "periodic" mode the driver reports all values above + prox0_thresh_above. This causes more interrupts, but it can give + _rough_ estimate about the distance. + +prox0_reporting_mode_avail + RO - accepted values to prox0_reporting_mode (trigger, periodic) + +prox0_thresh_above_value + RW - threshold level which trigs proximity events. diff --git a/Documentation/misc-devices/bh1770glc.txt b/Documentation/misc-devices/bh1770glc.txt new file mode 100644 index 0000000..7d64c01 --- /dev/null +++ b/Documentation/misc-devices/bh1770glc.txt @@ -0,0 +1,116 @@ +Kernel driver bh1770glc +======================= + +Supported chips: +ROHM BH1770GLC +OSRAM SFH7770 + +Data sheet: +Not freely available + +Author: +Samu Onkalo + +Description +----------- +BH1770GLC and SFH7770 are combined ambient light and proximity sensors. +ALS and proximity parts operates on their own, but they shares common I2C +interface and interrupt logic. In principle they can run on their own, +but ALS side results are used to estimate reliability of the proximity sensor. + +ALS produces 16 bit lux values. The chip contains interrupt logic to produce +low and high threshold interrupts. + +Proximity part contains IR-led driver up to 3 IR leds. The chip measures +amount of reflected IR light and produces proximity result. Resolution is +8 bit. Driver supports only one channel. Driver uses ALS results to estimate +reliability of the proximity results. Thus ALS is always running while +proximity detection is needed. + +Driver uses threshold interrupts to avoid need for polling the values. +Proximity low interrupt doesn't exists in the chip. This is simulated +by using a delayed work. As long as there is proximity threshold above +interrupts the delayed work is pushed forward. So, when proximity level goes +below the threshold value, there is no interrupt and the delayed work will +finally run. This is handled as no proximity indication. + +Chip state is controlled via runtime pm framework when enabled in config. + +Calibscale factor is used to hide differences between the chips. By default +value set to neutral state meaning factor of 1.00. To get proper values, +calibrated source of light is needed as a reference. Calibscale factor is set +so that measurement produces about the expected lux value. + +SYSFS +----- + +chip_id + RO - shows detected chip type and version + +power_state + RW - enable / disable chip. Uses counting logic + 1 enables the chip + 0 disables the chip + +lux0_input + RO - measured lux value + sysfs_notify called when threshold interrupt occurs + +lux0_sensor_range + RO - lux0_input max value + +lux0_rate + RW - measurement rate in Hz + +lux0_rate_avail + RO - supported measurement rates + +lux0_thresh_above_value + RW - HI level threshold value. All results above the value + trigs an interrupt. 65535 (i.e. sensor_range) disables the above + interrupt. + +lux0_thresh_below_value + RW - LO level threshold value. All results below the value + trigs an interrupt. 0 disables the below interrupt. + +lux0_calibscale + RW - calibration value. Set to neutral value by default. + Output results are multiplied with calibscale / calibscale_default + value. + +lux0_calibscale_default + RO - neutral calibration value + +prox0_raw + RO - measured proximity value + sysfs_notify called when threshold interrupt occurs + +prox0_sensor_range + RO - prox0_raw max value + +prox0_raw_en + RW - enable / disable proximity - uses counting logic + 1 enables the proximity + 0 disables the proximity + +prox0_thresh_above_count + RW - number of proximity interrupts needed before triggering the event + +prox0_rate_above + RW - Measurement rate (in Hz) when the level is above threshold + i.e. when proximity on has been reported. + +prox0_rate_below + RW - Measurement rate (in Hz) when the level is below threshold + i.e. when proximity off has been reported. + +prox0_rate_avail + RO - Supported proximity measurement rates in Hz + +prox0_thresh_above0_value + RW - threshold level which trigs proximity events. + Filtered by persistence filter (prox0_thresh_above_count) + +prox0_thresh_above1_value + RW - threshold level which trigs event immediately -- cgit v1.1 From 003bb8ab7cecbfd1830bbccf9c6a9e2047d27c5c Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Tue, 26 Oct 2010 14:20:40 -0700 Subject: documentation: update sysrq.txt magic sysrq keys Update Documentation/sysrq.txt magic sysrq keys: - 'g' is for kgdb (not arch-specific); - add 2 new uses for 'v', remove the Voyager info; - add 'y' info (SPARC-64 specific); Signed-off-by: Randy Dunlap Cc: Jason Wessel Cc: "David S. Miller" Cc: "James E.J. Bottomley" Cc: David Airlie Acked-by: Alexander Shishkin Signed-off-by: Linus Torvalds --- Documentation/sysrq.txt | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt index 5c17196..312e375 100644 --- a/Documentation/sysrq.txt +++ b/Documentation/sysrq.txt @@ -75,7 +75,7 @@ On all - write a character to /proc/sysrq-trigger. e.g.: 'f' - Will call oom_kill to kill a memory hog process. -'g' - Used by kgdb on ppc and sh platforms. +'g' - Used by kgdb (kernel debugger) 'h' - Will display help (actually any other key than those listed here will display help. but 'h' is easy to remember :-) @@ -110,12 +110,15 @@ On all - write a character to /proc/sysrq-trigger. e.g.: 'u' - Will attempt to remount all mounted filesystems read-only. -'v' - Dumps Voyager SMP processor info to your console. +'v' - Forcefully restores framebuffer console +'v' - Causes ETM buffer dump [ARM-specific] 'w' - Dumps tasks that are in uninterruptable (blocked) state. 'x' - Used by xmon interface on ppc/powerpc platforms. +'y' - Show global CPU Registers [SPARC-64 specific] + 'z' - Dump the ftrace buffer '0'-'9' - Sets the console log level, controlling which kernel messages -- cgit v1.1 From ee2f154a598e96df2ebb01648a7699373bc085c7 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Tue, 26 Oct 2010 14:17:25 -0700 Subject: docbook: add more wait/wake/completion to device-drivers docbook Add more wait, wake, and completion interfaces to the device-drivers docbook. Fix kernel-doc notation in the added files. Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/DocBook/device-drivers.tmpl | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index feca075..22edcbb 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -51,8 +51,13 @@ Delaying, scheduling, and timer routines !Iinclude/linux/sched.h !Ekernel/sched.c +!Iinclude/linux/completion.h !Ekernel/timer.c + Wait queues and Wake events +!Iinclude/linux/wait.h +!Ekernel/wait.c + High-resolution timers !Iinclude/linux/ktime.h !Iinclude/linux/hrtimer.h -- cgit v1.1 From 56083ab17e0075e538270823c374b59cc97e73b9 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Tue, 26 Oct 2010 14:19:08 -0700 Subject: docbook: add idr/ida to kernel-api docbook Add idr/ida to kernel-api docbook. Fix typos and kernel-doc notation. Signed-off-by: Randy Dunlap Acked-by: Tejun Heo Cc: Naohiro Aota Cc: Jiri Kosina Signed-off-by: Linus Torvalds --- Documentation/DocBook/kernel-api.tmpl | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index 6b4e07f..7160652 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -93,6 +93,12 @@ X!Ilib/string.c !Elib/crc32.c !Elib/crc-ccitt.c + + idr/ida Functions +!Pinclude/linux/idr.h idr sync +!Plib/idr.c IDA description +!Elib/idr.c + -- cgit v1.1 From 9dcf7990c2b8afe865d59f809a35a84d10f241f8 Mon Sep 17 00:00:00 2001 From: Nicolas Palix Date: Sun, 24 Oct 2010 23:37:33 +0200 Subject: Coccinelle: Fix documentation A file used as example has been moved elsewhere. Update the documentation accordingly Signed-off-by: Nicolas Palix Reported-by: Julia Lawall Signed-off-by: Michal Marek --- Documentation/coccinelle.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/coccinelle.txt b/Documentation/coccinelle.txt index de51a3e..4a276ea 100644 --- a/Documentation/coccinelle.txt +++ b/Documentation/coccinelle.txt @@ -139,7 +139,7 @@ Example: Running - make coccicheck MODE=report COCCI=scripts/coccinelle/err_cast.cocci + make coccicheck MODE=report COCCI=scripts/coccinelle/api/err_cast.cocci will execute the following part of the SmPL script. @@ -177,7 +177,7 @@ identified. Example: Running - make coccicheck MODE=patch COCCI=scripts/coccinelle/err_cast.cocci + make coccicheck MODE=patch COCCI=scripts/coccinelle/api/err_cast.cocci will execute the following part of the SmPL script. @@ -221,7 +221,7 @@ NOTE: The diff-like output generated is NOT an applicable patch. The Example: Running - make coccicheck MODE=context COCCI=scripts/coccinelle/err_cast.cocci + make coccicheck MODE=context COCCI=scripts/coccinelle/api/err_cast.cocci will execute the following part of the SmPL script. @@ -256,7 +256,7 @@ diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing Example: Running - make coccicheck MODE=org COCCI=scripts/coccinelle/err_cast.cocci + make coccicheck MODE=org COCCI=scripts/coccinelle/api/err_cast.cocci will execute the following part of the SmPL script. -- cgit v1.1 From abffc0207f12563f17bbde96e4cc0d9f3d7e2a53 Mon Sep 17 00:00:00 2001 From: Andrea Righi Date: Wed, 27 Oct 2010 15:33:31 -0700 Subject: doc: clarify the behaviour of dirty_ratio/dirty_bytes When dirty_ratio or dirty_bytes is written the other parameter is disabled and set to 0 (in dirty_bytes_handler() / dirty_ratio_handler()). We do the same for dirty_background_ratio and dirty_background_bytes. However, in the sysctl documentation, we say that the counterpart becomes a function of the old value, that is not correct. Clarify the documentation reporting the actual behaviour. Reviewed-by: Greg Thelen Acked-by: David Rientjes Signed-off-by: Andrea Righi Cc: Randy Dunlap Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/sysctl/vm.txt | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index b606c2c..30289fa 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -80,8 +80,10 @@ dirty_background_bytes Contains the amount of dirty memory at which the pdflush background writeback daemon will start writeback. -If dirty_background_bytes is written, dirty_background_ratio becomes a function -of its value (dirty_background_bytes / the amount of dirtyable system memory). +Note: dirty_background_bytes is the counterpart of dirty_background_ratio. Only +one of them may be specified at a time. When one sysctl is written it is +immediately taken into account to evaluate the dirty memory limits and the +other appears as 0 when read. ============================================================== @@ -97,8 +99,10 @@ dirty_bytes Contains the amount of dirty memory at which a process generating disk writes will itself start writeback. -If dirty_bytes is written, dirty_ratio becomes a function of its value -(dirty_bytes / the amount of dirtyable system memory). +Note: dirty_bytes is the counterpart of dirty_ratio. Only one of them may be +specified at a time. When one sysctl is written it is immediately taken into +account to evaluate the dirty memory limits and the other appears as 0 when +read. Note: the minimum value allowed for dirty_bytes is two pages (in bytes); any value lower than this limit will be ignored and the old configuration will be -- cgit v1.1 From 97978e6d1f2da0073416870410459694fbdbfd9b Mon Sep 17 00:00:00 2001 From: Daniel Lezcano Date: Wed, 27 Oct 2010 15:33:35 -0700 Subject: cgroup: add clone_children control file The ns_cgroup is a control group interacting with the namespaces. When a new namespace is created, a corresponding cgroup is automatically created too. The cgroup name is the pid of the process who did 'unshare' or the child of 'clone'. This cgroup is tied with the namespace because it prevents a process to escape the control group and use the post_clone callback, so the child cgroup inherits the values of the parent cgroup. Unfortunately, the more we use this cgroup and the more we are facing problems with it: (1) when a process unshares, the cgroup name may conflict with a previous cgroup with the same pid, so unshare or clone return -EEXIST (2) the cgroup creation is out of control because there may have an application creating several namespaces where the system will automatically create several cgroups in his back and let them on the cgroupfs (eg. a vrf based on the network namespace). (3) the mix of (1) and (2) force an administrator to regularly check and clean these cgroups. This patchset removes the ns_cgroup by adding a new flag to the cgroup and the cgroupfs mount option. It enables the copy of the parent cgroup when a child cgroup is created. We can then safely remove the ns_cgroup as this flag brings a compatibility. We have now to manually create and add the task to a cgroup, which is consistent with the cgroup framework. This patch: Sent as an answer to a previous thread around the ns_cgroup. https://lists.linux-foundation.org/pipermail/containers/2009-June/018627.html It adds a control file 'clone_children' for a cgroup. This control file is a boolean specifying if the child cgroup should be a clone of the parent cgroup or not. The default value is 'false'. This flag makes the child cgroup to call the post_clone callback of all the subsystem, if it is available. At present, the cpuset is the only one which had implemented the post_clone callback. The option can be set at mount time by specifying the 'clone_children' mount option. Signed-off-by: Daniel Lezcano Signed-off-by: Serge E. Hallyn Cc: Eric W. Biederman Acked-by: Paul Menage Reviewed-by: Li Zefan Cc: Jamal Hadi Salim Cc: Matt Helsley Acked-by: Balbir Singh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/cgroups/cgroups.txt | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt index b34823f..190018b 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroups/cgroups.txt @@ -18,7 +18,8 @@ CONTENTS: 1.2 Why are cgroups needed ? 1.3 How are cgroups implemented ? 1.4 What does notify_on_release do ? - 1.5 How do I use cgroups ? + 1.5 What does clone_children do ? + 1.6 How do I use cgroups ? 2. Usage Examples and Syntax 2.1 Basic Usage 2.2 Attaching processes @@ -293,7 +294,16 @@ notify_on_release in the root cgroup at system boot is disabled value of their parents notify_on_release setting. The default value of a cgroup hierarchy's release_agent path is empty. -1.5 How do I use cgroups ? +1.5 What does clone_children do ? +--------------------------------- + +If the clone_children flag is enabled (1) in a cgroup, then all +cgroups created beneath will call the post_clone callbacks for each +subsystem of the newly created cgroup. Usually when this callback is +implemented for a subsystem, it copies the values of the parent +subsystem, this is the case for the cpuset. + +1.6 How do I use cgroups ? -------------------------- To start a new job that is to be contained within a cgroup, using -- cgit v1.1 From 45531757b45cae0ce64c5aff08c2534d5a0fa3e7 Mon Sep 17 00:00:00 2001 From: Daniel Lezcano Date: Wed, 27 Oct 2010 15:33:38 -0700 Subject: cgroup: notify ns_cgroup deprecated The ns_cgroup will be removed very soon. Let's warn, for this version, ns_cgroup is deprecated. Make ns_cgroup and clone_children exclusive. If the clone_children is set and the ns_cgroup is mounted, let's fail with EINVAL when the ns_cgroup subsys is created (a printk will help the user to understand why the creation fails). Update the feature remove schedule file with the deprecated ns_cgroup. Signed-off-by: Daniel Lezcano Acked-by: Paul Menage Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/feature-removal-schedule.txt | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index d2af87b..f3da8c0 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -526,6 +526,23 @@ Who: FUJITA Tomonori ---------------------------- +What: namespace cgroup (ns_cgroup) +When: 2.6.38 +Why: The ns_cgroup leads to some problems: + * cgroup creation is out-of-control + * cgroup name can conflict when pids are looping + * it is not possible to have a single process handling + a lot of namespaces without falling in a exponential creation time + * we may want to create a namespace without creating a cgroup + + The ns_cgroup is replaced by a compatibility flag 'clone_children', + where a newly created cgroup will copy the parent cgroup values. + The userspace has to manually create a cgroup and add a task to + the 'tasks' file. +Who: Daniel Lezcano + +---------------------------- + What: iwlwifi disable_hw_scan module parameters When: 2.6.40 Why: Hareware scan is the prefer method for iwlwifi devices for -- cgit v1.1 From b40d4f84becd69275451baee7f0801c85eb58437 Mon Sep 17 00:00:00 2001 From: Nikanth Karthikesan Date: Wed, 27 Oct 2010 15:34:10 -0700 Subject: /proc/pid/smaps: export amount of anonymous memory in a mapping Export the number of anonymous pages in a mapping via smaps. Even the private pages in a mapping backed by a file, would be marked as anonymous, when they are modified. Export this information to user-space via smaps. Exporting this count will help gdb to make a better decision on which areas need to be dumped in its coredump; and should be useful to others studying the memory usage of a process. Signed-off-by: Nikanth Karthikesan Acked-by: Hugh Dickins Reviewed-by: KOSAKI Motohiro Cc: Matt Mackall Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/proc.txt | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index a563b74..976de6e 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -370,6 +370,7 @@ Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 0 kB Referenced: 892 kB +Anonymous: 0 kB Swap: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB @@ -378,9 +379,15 @@ The first of these lines shows the same information as is displayed for the mapping in /proc/PID/maps. The remaining lines show the size of the mapping (size), the amount of the mapping that is currently resident in RAM (RSS), the process' proportional share of this mapping (PSS), the number of clean and -dirty shared pages in the mapping, and the number of clean and dirty private -pages in the mapping. The "Referenced" indicates the amount of memory -currently marked as referenced or accessed. +dirty private pages in the mapping. Note that even a page which is part of a +MAP_SHARED mapping, but has only a single pte mapped, i.e. is currently used +by only one process, is accounted as private and not as shared. "Referenced" +indicates the amount of memory currently marked as referenced or accessed. +"Anonymous" shows the amount of memory that does not belong to any file. Even +a mapping associated with a file may contain anonymous pages: when MAP_PRIVATE +and a page is modified, the file page is replaced by a private anonymous copy. +"Swap" shows how much would-be-anonymous memory is also used, but out on +swap. This file is only present if the CONFIG_MMU kernel configuration option is enabled. -- cgit v1.1 From 03f890f8c2f5c9008d3d8f6d85267717ced4bd79 Mon Sep 17 00:00:00 2001 From: Nikanth Karthikesan Date: Wed, 27 Oct 2010 15:34:11 -0700 Subject: /proc/pid/pagemap: document in Documentation/filesystems/proc.txt Document /proc/pid/pagemap in Documentation/filesystems/proc.txt Signed-off-by: Nikanth Karthikesan Cc: Richard Guenther Cc: Balbir Singh Cc: KOSAKI Motohiro Acked-by: Matt Mackall Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/proc.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 976de6e..e73df27 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -136,6 +136,7 @@ Table 1-1: Process specific entries in /proc statm Process memory status information status Process status in human readable form wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan + pagemap Page table stack Report full stack trace, enable via CONFIG_STACKTRACE smaps a extension based on maps, showing the memory consumption of each mapping @@ -404,6 +405,9 @@ To clear the bits for the file mapped pages associated with the process > echo 3 > /proc/PID/clear_refs Any other value written to /proc/PID/clear_refs will have no effect. +The /proc/pid/pagemap gives the PFN, which can be used to find the pageflags +using /proc/kpageflags and number of times a page is mapped using +/proc/kpagecount. For detailed explanation, see Documentation/vm/pagemap.txt. 1.2 Kernel data --------------- -- cgit v1.1 From db9e5679d6aecb17253f41bd06d98194800f9c01 Mon Sep 17 00:00:00 2001 From: Mel Gorman Date: Wed, 27 Oct 2010 15:34:42 -0700 Subject: delay-accounting: reimplement -c for getdelays.c to report information on a target command Task delay-accounting was identified as one means of determining how long a process spends in congestion_wait() without adding new statistics. For example, if the workload should not be doing IO, delay-accounting could reveal how long it was spending in unexpected IO or delays. Unfortunately, on closer examination it was clear that getdelays does not act as documented. Commit a3baf649 ("per-task-delay-accounting: documentation") added Documentation/accounting/getdelays.c with a -c switch that was documented to fork/exec a child and report statistics on it but for reasons that are unclear to me, commit 9e06d3f9 deleted support for this switch but did not update the documentation. It might be an oversight or it might be because the control flow of the program meant that accounting information would be printed once early in the lifetime of the program making it of limited use. This patch reimplements -c for getdelays.c to act as documented. Unlike the original version, it waits until the command completes before printing any information on it. An example of it being used looks like $ ./getdelays -d -c find /home/mel -name mel print delayacct stats ON /home/mel /home/mel/.notes-wine/drive_c/windows/profiles/mel /home/mel/.wine/drive_c/windows/profiles/mel /home/mel/git-configs/dot.kde/share/apps/konqueror/home/mel PID 5923 CPU count real total virtual total delay total 42779 5051232096 5164722692 564207988 IO count delay total 41727 97804147758 SWAP count delay total 0 0 RECLAIM count delay total 0 0 [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: Mel Gorman Acked-by: Balbir Singh Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/accounting/getdelays.c | 38 ++++++++++++++++++++++++++++++++++-- 1 file changed, 36 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index 6e25c26..a2976a6 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c @@ -21,6 +21,7 @@ #include #include #include +#include #include #include @@ -266,11 +267,13 @@ int main(int argc, char *argv[]) int containerset = 0; char containerpath[1024]; int cfd = 0; + int forking = 0; + sigset_t sigset; struct msgtemplate msg; - while (1) { - c = getopt(argc, argv, "qdiw:r:m:t:p:vlC:"); + while (!forking) { + c = getopt(argc, argv, "qdiw:r:m:t:p:vlC:c:"); if (c < 0) break; @@ -319,6 +322,28 @@ int main(int argc, char *argv[]) err(1, "Invalid pid\n"); cmd_type = TASKSTATS_CMD_ATTR_PID; break; + case 'c': + + /* Block SIGCHLD for sigwait() later */ + if (sigemptyset(&sigset) == -1) + err(1, "Failed to empty sigset"); + if (sigaddset(&sigset, SIGCHLD)) + err(1, "Failed to set sigchld in sigset"); + sigprocmask(SIG_BLOCK, &sigset, NULL); + + /* fork/exec a child */ + tid = fork(); + if (tid < 0) + err(1, "Fork failed\n"); + if (tid == 0) + if (execvp(argv[optind - 1], + &argv[optind - 1]) < 0) + exit(-1); + + /* Set the command type and avoid further processing */ + cmd_type = TASKSTATS_CMD_ATTR_PID; + forking = 1; + break; case 'v': printf("debug on\n"); dbg = 1; @@ -370,6 +395,15 @@ int main(int argc, char *argv[]) goto err; } + /* + * If we forked a child, wait for it to exit. Cannot use waitpid() + * as all the delicious data would be reaped as part of the wait + */ + if (tid && forking) { + int sig_received; + sigwait(&sigset, &sig_received); + } + if (tid) { rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET, cmd_type, &tid, sizeof(__u32)); -- cgit v1.1 From bfff68738f1cb5c93dab1114634cea02aae9e7ba Mon Sep 17 00:00:00 2001 From: Lukas Czerner Date: Wed, 27 Oct 2010 21:30:05 -0400 Subject: ext4: add support for lazy inode table initialization When the lazy_itable_init extended option is passed to mke2fs, it considerably speeds up filesystem creation because inode tables are not zeroed out. The fact that parts of the inode table are uninitialized is not a problem so long as the block group descriptors, which contain information regarding how much of the inode table has been initialized, has not been corrupted However, if the block group checksums are not valid, e2fsck must scan the entire inode table, and the the old, uninitialized data could potentially cause e2fsck to report false problems. Hence, it is important for the inode tables to be initialized as soon as possble. This commit adds this feature so that mke2fs can safely use the lazy inode table initialization feature to speed up formatting file systems. This is done via a new new kernel thread called ext4lazyinit, which is created on demand and destroyed, when it is no longer needed. There is only one thread for all ext4 filesystems in the system. When the first filesystem with inititable mount option is mounted, ext4lazyinit thread is created, then the filesystem can register its request in the request list. This thread then walks through the list of requests picking up scheduled requests and invoking ext4_init_inode_table(). Next schedule time for the request is computed by multiplying the time it took to zero out last inode table with wait multiplier, which can be set with the (init_itable=n) mount option (default is 10). We are doing this so we do not take the whole I/O bandwidth. When the thread is no longer necessary (request list is empty) it frees the appropriate structures and exits (and can be created later later by another filesystem). We do not disturb regular inode allocations in any way, it just do not care whether the inode table is, or is not zeroed. But when zeroing, we have to skip used inodes, obviously. Also we should prevent new inode allocations from the group, while zeroing is on the way. For that we take write alloc_sem lock in ext4_init_inode_table() and read alloc_sem in the ext4_claim_inode, so when we are unlucky and allocator hits the group which is currently being zeroed, it just has to wait. This can be suppresed using the mount option no_init_itable. Signed-off-by: Lukas Czerner Signed-off-by: "Theodore Ts'o" --- Documentation/filesystems/ext4.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index e1def17..6ab9442 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt @@ -353,6 +353,20 @@ noauto_da_alloc replacing existing files via patterns such as system crashes before the delayed allocation blocks are forced to disk. +noinit_itable Do not initialize any uninitialized inode table + blocks in the background. This feature may be + used by installation CD's so that the install + process can complete as quickly as possible; the + inode table initialization process would then be + deferred until the next time the file system + is unmounted. + +init_itable=n The lazy itable init code will wait n times the + number of milliseconds it took to zero out the + previous block group's inode table. This + minimizes the impact on the systme performance + while file system's inode table is being initialized. + discard Controls whether ext4 should issue discard/TRIM nodiscard(*) commands to the underlying block device when blocks are freed. This is useful for SSD devices -- cgit v1.1 From 76381a42e4a5606774fd48413e6282cd7130ff2c Mon Sep 17 00:00:00 2001 From: "Aneesh Kumar K.V" Date: Tue, 28 Sep 2010 00:27:41 +0530 Subject: fs/9p: Add access = client option to opt in acl evaluation. Signed-off-by: Aneesh Kumar K.V Signed-off-by: Venkateswararao Jujjuri Signed-off-by: Eric Van Hensbergen --- Documentation/filesystems/9p.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt index f9765e8..b22abba 100644 --- a/Documentation/filesystems/9p.txt +++ b/Documentation/filesystems/9p.txt @@ -111,7 +111,7 @@ OPTIONS This can be used to share devices/named pipes/sockets between hosts. This functionality will be expanded in later versions. - access there are three access modes. + access there are four access modes. user = if a user tries to access a file on v9fs filesystem for the first time, v9fs sends an attach command (Tattach) for that user. @@ -120,6 +120,8 @@ OPTIONS the files on the mounted filesystem any = v9fs does single attach and performs all operations as one user + client = ACL based access check on the 9p client + side for access validation cachetag cache tag to use the specified persistent cache. cache tags for existing cache sessions can be listed at -- cgit v1.1 From 28e7438faacbd47aaf3e3b43c3074c64be98f5be Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Thu, 28 Oct 2010 20:31:42 +0200 Subject: hwmon: Add tempX_emergency attribute to sysfs ABI Signed-off-by: Guenter Roeck Signed-off-by: Jean Delvare --- Documentation/hwmon/sysfs-interface | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index 48ceabe..6456990 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface @@ -309,6 +309,20 @@ temp[1-*]_crit_hyst from the critical value. RW +temp[1-*]_emergency + Temperature emergency max value, for chips supporting more than + two upper temperature limits. Must be equal or greater than + corresponding temp_crit values. + Unit: millidegree Celsius + RW + +temp[1-*]_emergency_hyst + Temperature hysteresis value for emergency limit. + Unit: millidegree Celsius + Must be reported as an absolute temperature, NOT a delta + from the emergency value. + RW + temp[1-*]_lcrit Temperature critical min value, typically lower than corresponding temp_min values. Unit: millidegree Celsius @@ -505,6 +519,7 @@ fan[1-*]_max_alarm temp[1-*]_min_alarm temp[1-*]_max_alarm temp[1-*]_crit_alarm +temp[1-*]_emergency_alarm Limit alarm 0: no alarm 1: alarm -- cgit v1.1 From 13c84951a3d75ba820adf47eb2a3b1c5ab1fa635 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Thu, 28 Oct 2010 20:31:43 +0200 Subject: hwmon: (lm90) Add explicit support for max6659 Signed-off-by: Guenter Roeck Signed-off-by: Jean Delvare --- Documentation/hwmon/lm90 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/lm90 b/Documentation/hwmon/lm90 index 6a03dd4..d5ce9f4 100644 --- a/Documentation/hwmon/lm90 +++ b/Documentation/hwmon/lm90 @@ -63,8 +63,8 @@ Supported chips: Datasheet: Publicly available at the Maxim website http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578 * Maxim MAX6659 - Prefix: 'max6657' - Addresses scanned: I2C 0x4c, 0x4d (unsupported 0x4e) + Prefix: 'max6659' + Addresses scanned: I2C 0x4c, 0x4d, 0x4e Datasheet: Publicly available at the Maxim website http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578 * Maxim MAX6680 -- cgit v1.1 From 6948708dd07573c578aa99f80915cd1867334abe Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Thu, 28 Oct 2010 20:31:43 +0200 Subject: hwmon: (lm90) Add support for extra features of max6659 Signed-off-by: Guenter Roeck Signed-off-by: Jean Delvare --- Documentation/hwmon/lm90 | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/lm90 b/Documentation/hwmon/lm90 index d5ce9f4..bc2c2b4 100644 --- a/Documentation/hwmon/lm90 +++ b/Documentation/hwmon/lm90 @@ -101,10 +101,11 @@ well as the temperature of up to one external diode. It is compatible with many other devices, many of which are supported by this driver. Note that there is no easy way to differentiate between the MAX6657, -MAX6658 and MAX6659 variants. The extra address and features of the -MAX6659 are not supported by this driver. The MAX6680 and MAX6681 only -differ in their pinout, therefore they obviously can't (and don't need to) -be distinguished. +MAX6658 and MAX6659 variants. The extra features of the MAX6659 are only +supported by this driver if the chip is located at address 0x4d or 0x4e, +or if the chip type is explicitly selected as max6659. +The MAX6680 and MAX6681 only differ in their pinout, therefore they obviously +can't (and don't need to) be distinguished. The specificity of this family of chipsets over the ADM1021/LM84 family is that it features critical limits with hysteresis, and an -- cgit v1.1 From 06e1c0a2167d48442d0bd06373390886670aa6e5 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Thu, 28 Oct 2010 20:31:43 +0200 Subject: hwmon: (lm90) Add support for max6695 and max6696 Signed-off-by: Guenter Roeck Signed-off-by: Jean Delvare --- Documentation/hwmon/lm90 | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/lm90 b/Documentation/hwmon/lm90 index bc2c2b4..6e963b6 100644 --- a/Documentation/hwmon/lm90 +++ b/Documentation/hwmon/lm90 @@ -84,6 +84,17 @@ Supported chips: Addresses scanned: I2C 0x4c Datasheet: Publicly available at the Maxim website http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3500 + * Maxim MAX6695 + Prefix: 'max6695' + Addresses scanned: I2C 0x18 + Datasheet: Publicly available at the Maxim website + http://www.maxim-ic.com/datasheet/index.mvp/id/4199 + * Maxim MAX6696 + Prefix: 'max6695' + Addresses scanned: I2C 0x18, 0x19, 0x1a, 0x29, 0x2a, 0x2b, + 0x4c, 0x4d and 0x4e + Datasheet: Publicly available at the Maxim website + http://www.maxim-ic.com/datasheet/index.mvp/id/4199 * Winbond/Nuvoton W83L771AWG/ASG Prefix: 'w83l771' Addresses scanned: I2C 0x4c @@ -152,6 +163,12 @@ MAX6680 and MAX6681: * Selectable address * Remote sensor type selection +MAX6695 and MAX6696: + * Better local resolution + * Selectable address (max6696) + * Second critical temperature limit + * Two remote sensors + W83L771AWG/ASG * The AWG and ASG variants only differ in package format. * Filter and alert configuration register at 0xBF -- cgit v1.1 From c4f99a2b8fb4c564865f0037a2b7be690d4409f3 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Thu, 28 Oct 2010 20:31:44 +0200 Subject: hwmon: (lm90) Add support for the W83L771W/G I was wondering if that chip ever existed publicly... Apparently yes, so add support for it. Signed-off-by: Jean Delvare Tested-by: Alexander Stein Acked-by: Guenter Roeck --- Documentation/hwmon/lm90 | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/lm90 b/Documentation/hwmon/lm90 index 6e963b6..fa475c0 100644 --- a/Documentation/hwmon/lm90 +++ b/Documentation/hwmon/lm90 @@ -95,6 +95,10 @@ Supported chips: 0x4c, 0x4d and 0x4e Datasheet: Publicly available at the Maxim website http://www.maxim-ic.com/datasheet/index.mvp/id/4199 + * Winbond/Nuvoton W83L771W/G + Prefix: 'w83l771' + Addresses scanned: I2C 0x4c + Datasheet: No longer available * Winbond/Nuvoton W83L771AWG/ASG Prefix: 'w83l771' Addresses scanned: I2C 0x4c @@ -169,11 +173,15 @@ MAX6695 and MAX6696: * Second critical temperature limit * Two remote sensors +W83L771W/G + * The G variant is lead-free, otherwise similar to the W. + * Filter and alert configuration register at 0xBF + * Moving average (depending on conversion rate) + W83L771AWG/ASG + * Successor of the W83L771W/G, same features. * The AWG and ASG variants only differ in package format. - * Filter and alert configuration register at 0xBF * Diode ideality factor configuration (remote sensor) at 0xE3 - * Moving average (depending on conversion rate) All temperature values are given in degrees Celsius. Resolution is 1.0 degree for the local temperature, 0.125 degree for the remote -- cgit v1.1 From 6dfee85397a47063291fe199eaf950bee7944454 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Thu, 28 Oct 2010 20:31:50 +0200 Subject: hwmon: (pcf8591) Don't attempt to detect devices The PCF8591 can't be detected, don't even try. There are plenty of other means to instantiate i2c devices these days. Signed-off-by: Jean Delvare Reviewed-by: Guenter Roeck Cc: Aurelien Jarno --- Documentation/hwmon/pcf8591 | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/pcf8591 b/Documentation/hwmon/pcf8591 index e76a789..ac020b3 100644 --- a/Documentation/hwmon/pcf8591 +++ b/Documentation/hwmon/pcf8591 @@ -4,7 +4,7 @@ Kernel driver pcf8591 Supported chips: * Philips/NXP PCF8591 Prefix: 'pcf8591' - Addresses scanned: I2C 0x48 - 0x4f + Addresses scanned: none Datasheet: Publicly available at the NXP website http://www.nxp.com/pip/PCF8591_6.html @@ -58,18 +58,16 @@ Module parameters Accessing PCF8591 via /sys interface ------------------------------------- -! Be careful ! -The PCF8591 is plainly impossible to detect! Stupid chip. -So every chip with address in the interval [0x48..0x4f] is -detected as PCF8591. If you have other chips in this address -range, the workaround is to load this module after the one -for your others chips. +The PCF8591 is plainly impossible to detect! Thus the driver won't even +try. You have to explicitly instantiate the device at the relevant +address (in the interval [0x48..0x4f]) either through platform data, or +using the sysfs interface. See Documentation/i2c/instantiating-devices +for details. -On detection (i.e. insmod, modprobe et al.), directories are being -created for each detected PCF8591: +Directories are being created for each instantiated PCF8591: /sys/bus/i2c/devices/<0>-<1>/ -where <0> is the bus the chip was detected on (e. g. i2c-0) +where <0> is the bus the chip is connected to (e. g. i2c-0) and <1> the chip address ([48..4f]) Inside these directories, there are such files: -- cgit v1.1 From c36364dbf38382ef6be2fb99a3ce361a679c0ecb Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Thu, 28 Oct 2010 20:31:50 +0200 Subject: hwmon: (lm85) Document the ADT7468 as supported Signed-off-by: Jean Delvare Cc: Darrick J. Wong Acked-by: Guenter Roeck --- Documentation/hwmon/lm85 | 53 ++++++++++++++++++++++++++---------------------- 1 file changed, 29 insertions(+), 24 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/lm85 b/Documentation/hwmon/lm85 index b98e0e0..83cd5bb 100644 --- a/Documentation/hwmon/lm85 +++ b/Documentation/hwmon/lm85 @@ -14,6 +14,10 @@ Supported chips: Prefix: 'adt7463' Addresses scanned: I2C 0x2c, 0x2d, 0x2e Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7463 + * Analog Devices ADT7468 + Prefix: 'adt7468' + Addresses scanned: I2C 0x2c, 0x2d, 0x2e + Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7468 * SMSC EMC6D100, SMSC EMC6D101 Prefix: 'emc6d100' Addresses scanned: I2C 0x2c, 0x2d, 0x2e @@ -34,7 +38,7 @@ Description ----------- This driver implements support for the National Semiconductor LM85 and -compatible chips including the Analog Devices ADM1027, ADT7463 and +compatible chips including the Analog Devices ADM1027, ADT7463, ADT7468 and SMSC EMC6D10x chips family. The LM85 uses the 2-wire interface compatible with the SMBUS 2.0 @@ -87,14 +91,15 @@ To smooth the response of fans to changes in temperature, the LM85 has an optional filter for smoothing temperatures. The ADM1027 has the same config option but uses it to rate limit the changes to fan speed instead. -The ADM1027 and ADT7463 have a 10-bit ADC and can therefore measure -temperatures with 0.25 degC resolution. They also provide an offset to the -temperature readings that is automatically applied during measurement. -This offset can be used to zero out any errors due to traces and placement. -The documentation says that the offset is in 0.25 degC steps, but in -initial testing of the ADM1027 it was 1.00 degC steps. Analog Devices has -confirmed this "bug". The ADT7463 is reported to work as described in the -documentation. The current lm85 driver does not show the offset register. +The ADM1027, ADT7463 and ADT7468 have a 10-bit ADC and can therefore +measure temperatures with 0.25 degC resolution. They also provide an offset +to the temperature readings that is automatically applied during +measurement. This offset can be used to zero out any errors due to traces +and placement. The documentation says that the offset is in 0.25 degC +steps, but in initial testing of the ADM1027 it was 1.00 degC steps. Analog +Devices has confirmed this "bug". The ADT7463 is reported to work as +described in the documentation. The current lm85 driver does not show the +offset register. See the vendor datasheets for more information. There is application note from National (AN-1260) with some additional information about the LM85. @@ -125,17 +130,17 @@ datasheet for a complete description of the differences. Other than identifying the chip, the driver behaves no differently with regard to these two chips. The LM85B is recommended for new designs. -The ADM1027 and ADT7463 chips have an optional SMBALERT output that can be -used to signal the chipset in case a limit is exceeded or the temperature -sensors fail. Individual sensor interrupts can be masked so they won't -trigger SMBALERT. The SMBALERT output if configured replaces one of the other -functions (PWM2 or IN0). This functionality is not implemented in current -driver. +The ADM1027, ADT7463 and ADT7468 chips have an optional SMBALERT output +that can be used to signal the chipset in case a limit is exceeded or the +temperature sensors fail. Individual sensor interrupts can be masked so +they won't trigger SMBALERT. The SMBALERT output if configured replaces one +of the other functions (PWM2 or IN0). This functionality is not implemented +in current driver. -The ADT7463 also has an optional THERM output/input which can be connected -to the processor PROC_HOT output. If available, the autofan control -dynamic Tmin feature can be enabled to keep the system temperature within -spec (just?!) with the least possible fan noise. +The ADT7463 and ADT7468 also have an optional THERM output/input which can +be connected to the processor PROC_HOT output. If available, the autofan +control dynamic Tmin feature can be enabled to keep the system temperature +within spec (just?!) with the least possible fan noise. Configuration Notes ------------------- @@ -201,8 +206,8 @@ the temperatures to compensate for systemic errors in the measurements. These features are not currently supported by the lm85 driver. -In addition to the ADM1027 features, the ADT7463 also has Tmin control -and THERM asserted counts. Automatic Tmin control acts to adjust the -Tmin value to maintain the measured temperature sensor at a specified -temperature. There isn't much documentation on this feature in the -ADT7463 data sheet. This is not supported by current driver. +In addition to the ADM1027 features, the ADT7463 and ADT7468 also have +Tmin control and THERM asserted counts. Automatic Tmin control acts to +adjust the Tmin value to maintain the measured temperature sensor at a +specified temperature. There isn't much documentation on this feature in +the ADT7463 data sheet. This is not supported by current driver. -- cgit v1.1 From f6c61cff8bcb58b8dfb645d4243a049908c02024 Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Thu, 28 Oct 2010 20:31:50 +0200 Subject: hwmon: (lm85) Add support for ADT7468 high-frequency PWM mode The ADT7468 supports a high-frequency PWM output mode where all PWM outputs are driven by a 22.5 kHz clock. Add support for this mode, and document it, as it may surprise the user that setting one PWM output frequency also affects the other PWM outputs. Signed-off-by: Jean Delvare Cc: Darrick J. Wong Acked-by: Guenter Roeck --- Documentation/hwmon/lm85 | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/lm85 b/Documentation/hwmon/lm85 index 83cd5bb..239258a 100644 --- a/Documentation/hwmon/lm85 +++ b/Documentation/hwmon/lm85 @@ -101,6 +101,13 @@ Devices has confirmed this "bug". The ADT7463 is reported to work as described in the documentation. The current lm85 driver does not show the offset register. +The ADT7468 has a high-frequency PWM mode, where all PWM outputs are +driven by a 22.5 kHz clock. This is a global mode, not per-PWM output, +which means that setting any PWM frequency above 11.3 kHz will switch +all 3 PWM outputs to a 22.5 kHz frequency. Conversely, setting any PWM +frequency below 11.3 kHz will switch all 3 PWM outputs to a frequency +between 10 and 100 Hz, which can then be tuned separately. + See the vendor datasheets for more information. There is application note from National (AN-1260) with some additional information about the LM85. The Analog Devices datasheet is very detailed and describes a procedure for -- cgit v1.1 From 44c1bcd4bcde32b2a31a6775a277706ab489c0dc Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Thu, 28 Oct 2010 20:31:51 +0200 Subject: hwmon: (it87) Add support for the IT8721F/IT8758E Add support for the IT8721F/IT8758E. These new chips differ from the older IT87xxF chips in the following ways: * ADC LSB is 12 mV instead of 16 mV. * PWM values are 8-bit instead of 7-bit. There are other minor changes we don't have to care about in the driver. Another change is that we will handle internal voltage scaling in the driver instead of delegating the work to user-space. Signed-off-by: Jean Delvare --- Documentation/hwmon/it87 | 28 +++++++++++++++++++--------- 1 file changed, 19 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87 index 8d08bf0..38425f0 100644 --- a/Documentation/hwmon/it87 +++ b/Documentation/hwmon/it87 @@ -22,6 +22,10 @@ Supported chips: Prefix: 'it8720' Addresses scanned: from Super I/O config space (8 I/O ports) Datasheet: Not publicly available + * IT8721F/IT8758E + Prefix: 'it8721' + Addresses scanned: from Super I/O config space (8 I/O ports) + Datasheet: Not publicly available * SiS950 [clone of IT8705F] Prefix: 'it87' Addresses scanned: from Super I/O config space (8 I/O ports) @@ -67,7 +71,7 @@ Description ----------- This driver implements support for the IT8705F, IT8712F, IT8716F, -IT8718F, IT8720F, IT8726F and SiS950 chips. +IT8718F, IT8720F, IT8721F, IT8726F, IT8758E and SiS950 chips. These chips are 'Super I/O chips', supporting floppy disks, infrared ports, joysticks and other miscellaneous stuff. For hardware monitoring, they @@ -86,14 +90,15 @@ the driver won't notice and report changes in the VID value. The two upper VID bits share their pins with voltage inputs (in5 and in6) so you can't have both on a given board. -The IT8716F, IT8718F, IT8720F and later IT8712F revisions have support for -2 additional fans. The additional fans are supported by the driver. +The IT8716F, IT8718F, IT8720F, IT8721F/IT8758E and later IT8712F revisions +have support for 2 additional fans. The additional fans are supported by the +driver. -The IT8716F, IT8718F and IT8720F, and late IT8712F and IT8705F also have -optional 16-bit tachometer counters for fans 1 to 3. This is better (no more -fan clock divider mess) but not compatible with the older chips and -revisions. The 16-bit tachometer mode is enabled by the driver when one -of the above chips is detected. +The IT8716F, IT8718F, IT8720F and IT8721F/IT8758E, and late IT8712F and +IT8705F also have optional 16-bit tachometer counters for fans 1 to 3. This +is better (no more fan clock divider mess) but not compatible with the older +chips and revisions. The 16-bit tachometer mode is enabled by the driver when +one of the above chips is detected. The IT8726F is just bit enhanced IT8716F with additional hardware for AMD power sequencing. Therefore the chip will appear as IT8716F @@ -115,7 +120,12 @@ alarm is triggered if the voltage has crossed a programmable minimum or maximum limit. Note that minimum in this case always means 'closest to zero'; this is important for negative voltage measurements. All voltage inputs can measure voltages between 0 and 4.08 volts, with a resolution of -0.016 volt. The battery voltage in8 does not have limit registers. +0.016 volt (except IT8721F/IT8758E: 0.012 volt.) The battery voltage in8 does +not have limit registers. + +On the IT8721F/IT8758E, some voltage inputs are internal and scaled inside +the chip (in7, in8 and optionally in3). The driver handles this transparently +so user-space doesn't have to care. The VID lines (IT8712F/IT8716F/IT8718F/IT8720F) encode the core voltage value: the voltage level your processor should work with. This is hardcoded by -- cgit v1.1 From 4aad8f51d0672f1c95e2cf0e1bc7b9ab42d8e1ea Mon Sep 17 00:00:00 2001 From: Jason Wessel Date: Mon, 25 Oct 2010 10:14:05 -0500 Subject: kdb: Add kdb kernel module sample Add an example of how to add a dynamic kdb shell command via a kernel module. Signed-off-by: Jason Wessel --- Documentation/DocBook/kgdb.tmpl | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl index 490d862..d71b57f 100644 --- a/Documentation/DocBook/kgdb.tmpl +++ b/Documentation/DocBook/kgdb.tmpl @@ -710,7 +710,18 @@ Task Addr Pid Parent [*] cpu State Thread Command A simple shell The kdb core command set A registration API to register additional kdb shell commands. - A good example of a self-contained kdb module is the "ftdump" command for dumping the ftrace buffer. See: kernel/trace/trace_kdb.c + + A good example of a self-contained kdb module + is the "ftdump" command for dumping the ftrace buffer. See: + kernel/trace/trace_kdb.c + For an example of how to dynamically register + a new kdb command you can build the kdb_hello.ko kernel module + from samples/kdb/kdb_hello.c. To build this example you can + set CONFIG_SAMPLES=y and CONFIG_SAMPLE_KDB=m in your kernel + config. Later run "modprobe kdb_hello" and the next time you + enter the kdb shell, you can run the "hello" + command. + The implementation for kdb_printf() which emits messages directly to I/O drivers, bypassing the kernel log. -- cgit v1.1 From bb8430a2c8fe2b726033017daadf73c69b0348ea Mon Sep 17 00:00:00 2001 From: Christoph Hellwig Date: Sun, 31 Oct 2010 08:35:31 -0400 Subject: locks: remove fl_copy_lock lock_manager operation This one was only used for a nasty hack in nfsd, which has recently been removed. Signed-off-by: Christoph Hellwig Signed-off-by: Linus Torvalds --- Documentation/filesystems/Locking | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 8a817f6..a91f308 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -322,7 +322,6 @@ fl_release_private: yes yes prototypes: int (*fl_compare_owner)(struct file_lock *, struct file_lock *); void (*fl_notify)(struct file_lock *); /* unblock callback */ - void (*fl_copy_lock)(struct file_lock *, struct file_lock *); void (*fl_release_private)(struct file_lock *); void (*fl_break)(struct file_lock *); /* break_lease callback */ @@ -330,7 +329,6 @@ locking rules: BKL may block fl_compare_owner: yes no fl_notify: yes no -fl_copy_lock: yes no fl_release_private: yes yes fl_break: yes no -- cgit v1.1 From e30d9859cf08920ae711f57ecd9726804451d29f Mon Sep 17 00:00:00 2001 From: Seth Heasley Date: Sun, 31 Oct 2010 21:06:59 +0100 Subject: i2c-i801: Add Intel Patsburg device ID Add support for the Intel Patsburg PCH SMBus Controller. Signed-off-by: Seth Heasley Signed-off-by: Jean Delvare --- Documentation/i2c/busses/i2c-i801 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index e307914..a417cb1 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -15,8 +15,9 @@ Supported adapters: * Intel 82801I (ICH9) * Intel EP80579 (Tolapai) * Intel 82801JI (ICH10) - * Intel 3400/5 Series (PCH) + * Intel 5/3400 Series (PCH) * Intel Cougar Point (PCH) + * Intel Patsburg (PCH) Datasheets: Publicly available at the Intel website Authors: -- cgit v1.1 From 55fee8d7f7cb011d7f161cf816220ac74e34b6b1 Mon Sep 17 00:00:00 2001 From: David Woodhouse Date: Sun, 31 Oct 2010 21:07:00 +0100 Subject: i2c-i801: Add PCI idents for Patsburg 'IDF' SMBus controllers These are the extra 'Integrated Device Function' SMBus controllers found on the Patsburg chipset. Mention the absence of slave mode support. Signed-off-by: David Woodhouse Signed-off-by: Jean Delvare --- Documentation/i2c/busses/i2c-i801 | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index a417cb1..93fe76e 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -20,6 +20,9 @@ Supported adapters: * Intel Patsburg (PCH) Datasheets: Publicly available at the Intel website +On Intel Patsburg and later chipsets, both the normal host SMBus controller +and the additional 'Integrated Device Function' controllers are supported. + Authors: Mark Studebaker Jean Delvare -- cgit v1.1