---

yaml --- r: 139071 b: refs/heads/master c: 3a35ce7 h: refs/heads/master i: 139069: f5397de 139067: 41d057f 139063: e94b4cf 139055: 969b7d4 139039: 6b126fa 139007: 588d1b5 v: v3
git-mirror · Mar 30, 2009 · 76b0253 · 76b0253
1 parent 920a2c5
commit 76b0253
Show file tree

Hide file tree

Showing 1,262 changed files with 44,218 additions and 111,531 deletions.
diff --git a/[refs] b/[refs]
@@ -1,2 +1,2 @@
 ---
-refs/heads/master: 3c6fae67d026d57f64eb3da9c0d0e76983e39ae3
+refs/heads/master: 3a35ce7dcefe9e80a00603a195269fbaf6e7d901
diff --git a/trunk/Documentation/DMA-API.txt b/trunk/Documentation/DMA-API.txt
@@ -609,109 +609,3 @@ size is the size (and should be a page-sized multiple).
 The return value will be either a pointer to the processor virtual
 address of the memory, or an error (via PTR_ERR()) if any part of the
 region is occupied.
-
-Part III - Debug drivers use of the DMA-API
--------------------------------------------
-
-The DMA-API as described above as some constraints. DMA addresses must be
-released with the corresponding function with the same size for example. With
-the advent of hardware IOMMUs it becomes more and more important that drivers
-do not violate those constraints. In the worst case such a violation can
-result in data corruption up to destroyed filesystems.
-
-To debug drivers and find bugs in the usage of the DMA-API checking code can
-be compiled into the kernel which will tell the developer about those
-violations. If your architecture supports it you can select the "Enable
-debugging of DMA-API usage" option in your kernel configuration. Enabling this
-option has a performance impact. Do not enable it in production kernels.
-
-If you boot the resulting kernel will contain code which does some bookkeeping
-about what DMA memory was allocated for which device. If this code detects an
-error it prints a warning message with some details into your kernel log. An
-example warning message may look like this:
-
-------------[ cut here ]------------
-WARNING: at /data2/repos/linux-2.6-iommu/lib/dma-debug.c:448
-	check_unmap+0x203/0x490()
-Hardware name:
-forcedeth 0000:00:08.0: DMA-API: device driver frees DMA memory with wrong
-	function [device address=0x00000000640444be] [size=66 bytes] [mapped as
-single] [unmapped as page]
-Modules linked in: nfsd exportfs bridge stp llc r8169
-Pid: 0, comm: swapper Tainted: G        W  2.6.28-dmatest-09289-g8bb99c0 #1
-Call Trace:
- <IRQ>  [<ffffffff80240b22>] warn_slowpath+0xf2/0x130
- [<ffffffff80647b70>] _spin_unlock+0x10/0x30
- [<ffffffff80537e75>] usb_hcd_link_urb_to_ep+0x75/0xc0
- [<ffffffff80647c22>] _spin_unlock_irqrestore+0x12/0x40
- [<ffffffff8055347f>] ohci_urb_enqueue+0x19f/0x7c0
- [<ffffffff80252f96>] queue_work+0x56/0x60
- [<ffffffff80237e10>] enqueue_task_fair+0x20/0x50
- [<ffffffff80539279>] usb_hcd_submit_urb+0x379/0xbc0
- [<ffffffff803b78c3>] cpumask_next_and+0x23/0x40
- [<ffffffff80235177>] find_busiest_group+0x207/0x8a0
- [<ffffffff8064784f>] _spin_lock_irqsave+0x1f/0x50
- [<ffffffff803c7ea3>] check_unmap+0x203/0x490
- [<ffffffff803c8259>] debug_dma_unmap_page+0x49/0x50
- [<ffffffff80485f26>] nv_tx_done_optimized+0xc6/0x2c0
- [<ffffffff80486c13>] nv_nic_irq_optimized+0x73/0x2b0
- [<ffffffff8026df84>] handle_IRQ_event+0x34/0x70
- [<ffffffff8026ffe9>] handle_edge_irq+0xc9/0x150
- [<ffffffff8020e3ab>] do_IRQ+0xcb/0x1c0
- [<ffffffff8020c093>] ret_from_intr+0x0/0xa
- <EOI> <4>---[ end trace f6435a98e2a38c0e ]---
-
-The driver developer can find the driver and the device including a stacktrace
-of the DMA-API call which caused this warning.
-
-Per default only the first error will result in a warning message. All other
-errors will only silently counted. This limitation exist to prevent the code
-from flooding your kernel log. To support debugging a device driver this can
-be disabled via debugfs. See the debugfs interface documentation below for
-details.
-
-The debugfs directory for the DMA-API debugging code is called dma-api/. In
-this directory the following files can currently be found:
-
-	dma-api/all_errors	This file contains a numeric value. If this
-				value is not equal to zero the debugging code
-				will print a warning for every error it finds
-				into the kernel log. Be carefull with this
-				option. It can easily flood your logs.
-
-	dma-api/disabled	This read-only file contains the character 'Y'
-				if the debugging code is disabled. This can
-				happen when it runs out of memory or if it was
-				disabled at boot time
-
-	dma-api/error_count	This file is read-only and shows the total
-				numbers of errors found.
-
-	dma-api/num_errors	The number in this file shows how many
-				warnings will be printed to the kernel log
-				before it stops. This number is initialized to
-				one at system boot and be set by writing into
-				this file
-
-	dma-api/min_free_entries
-				This read-only file can be read to get the
-				minimum number of free dma_debug_entries the
-				allocator has ever seen. If this value goes
-				down to zero the code will disable itself
-				because it is not longer reliable.
-
-	dma-api/num_free_entries
-				The current number of free dma_debug_entries
-				in the allocator.
-
-If you have this code compiled into your kernel it will be enabled by default.
-If you want to boot without the bookkeeping anyway you can provide
-'dma_debug=off' as a boot parameter. This will disable DMA-API debugging.
-Notice that you can not enable it again at runtime. You have to reboot to do
-so.
-
-When the code disables itself at runtime this is most likely because it ran
-out of dma_debug_entries. These entries are preallocated at boot. The number
-of preallocated entries is defined per architecture. If it is too low for you
-boot with 'dma_debug_entries=<your_desired_number>' to overwrite the
-architectural default.
diff --git a/trunk/Documentation/DocBook/procfs_example.c b/trunk/Documentation/DocBook/procfs_example.c
@@ -117,6 +117,9 @@ static int __init init_procfs_example(void)
 		rv = -ENOMEM;
 		goto out;
 	}
+
+	example_dir->owner = THIS_MODULE;
+
 	/* create jiffies using convenience function */
 	jiffies_file = create_proc_read_entry("jiffies", 
 					      0444, example_dir, 
@@ -127,6 +130,8 @@ static int __init init_procfs_example(void)
 		goto no_jiffies;
 	}
 
+	jiffies_file->owner = THIS_MODULE;
+
 	/* create foo and bar files using same callback
 	 * functions 
 	 */
@@ -141,6 +146,7 @@ static int __init init_procfs_example(void)
 	foo_file->data = &foo_data;
 	foo_file->read_proc = proc_read_foobar;
 	foo_file->write_proc = proc_write_foobar;
+	foo_file->owner = THIS_MODULE;
 
 	bar_file = create_proc_entry("bar", 0644, example_dir);
 	if(bar_file == NULL) {
@@ -153,6 +159,7 @@ static int __init init_procfs_example(void)
 	bar_file->data = &bar_data;
 	bar_file->read_proc = proc_read_foobar;
 	bar_file->write_proc = proc_write_foobar;
+	bar_file->owner = THIS_MODULE;
 
 	/* create symlink */
 	symlink = proc_symlink("jiffies_too", example_dir, 
@@ -162,6 +169,8 @@ static int __init init_procfs_example(void)
 		goto no_symlink;
 	}
 
+	symlink->owner = THIS_MODULE;
+
 	/* everything OK */
 	printk(KERN_INFO "%s %s initialised\n",
 	       MODULE_NAME, MODULE_VERS);

diff --git a/trunk/Documentation/dvb/get_dvb_firmware b/trunk/Documentation/dvb/get_dvb_firmware
@@ -25,7 +25,7 @@ use IO::Handle;
 		"tda10046lifeview", "av7110", "dec2000t", "dec2540t",
 		"dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
 		"or51211", "or51132_qam", "or51132_vsb", "bluebird",
-		"opera1", "cx231xx", "cx18", "cx23885", "pvrusb2" );
+		"opera1");
 
 # Check args
 syntax() if (scalar(@ARGV) != 1);
@@ -37,8 +37,8 @@ for ($i=0; $i < scalar(@components); $i++) {
 	$outfile = eval($cid);
 	die $@ if $@;
 	print STDERR <<EOF;
-Firmware(s) $outfile extracted successfully.
-Now copy it(they) to either /usr/lib/hotplug/firmware or /lib/firmware
+Firmware $outfile extracted successfully.
+Now copy it to either /usr/lib/hotplug/firmware or /lib/firmware
 (depending on configuration of firmware hotplug).
 EOF
 	exit(0);
@@ -345,85 +345,6 @@ sub or51211 {
     $fwfile;
 }
 
-sub cx231xx {
-    my $fwfile = "v4l-cx231xx-avcore-01.fw";
-    my $url = "http://linuxtv.org/downloads/firmware/$fwfile";
-    my $hash = "7d3bb956dc9df0eafded2b56ba57cc42";
-
-    checkstandard();
-
-    wgetfile($fwfile, $url);
-    verify($fwfile, $hash);
-
-    $fwfile;
-}
-
-sub cx18 {
-    my $url = "http://linuxtv.org/downloads/firmware/";
-
-    my %files = (
-	'v4l-cx23418-apu.fw' => '588f081b562f5c653a3db1ad8f65939a',
-	'v4l-cx23418-cpu.fw' => 'b6c7ed64bc44b1a6e0840adaeac39d79',
-	'v4l-cx23418-dig.fw' => '95bc688d3e7599fd5800161e9971cc55',
-    );
-
-    checkstandard();
-
-    my $allfiles;
-    foreach my $fwfile (keys %files) {
-	wgetfile($fwfile, "$url/$fwfile");
-	verify($fwfile, $files{$fwfile});
-	$allfiles .= " $fwfile";
-    }
-
-    $allfiles =~ s/^\s//;
-
-    $allfiles;
-}
-
-sub cx23885 {
-    my $url = "http://linuxtv.org/downloads/firmware/";
-
-    my %files = (
-	'v4l-cx23885-avcore-01.fw' => 'a9f8f5d901a7fb42f552e1ee6384f3bb',
-	'v4l-cx23885-enc.fw'       => 'a9f8f5d901a7fb42f552e1ee6384f3bb',
-    );
-
-    checkstandard();
-
-    my $allfiles;
-    foreach my $fwfile (keys %files) {
-	wgetfile($fwfile, "$url/$fwfile");
-	verify($fwfile, $files{$fwfile});
-	$allfiles .= " $fwfile";
-    }
-
-    $allfiles =~ s/^\s//;
-
-    $allfiles;
-}
-
-sub pvrusb2 {
-    my $url = "http://linuxtv.org/downloads/firmware/";
-
-    my %files = (
-	'v4l-cx25840.fw'           => 'dadb79e9904fc8af96e8111d9cb59320',
-    );
-
-    checkstandard();
-
-    my $allfiles;
-    foreach my $fwfile (keys %files) {
-	wgetfile($fwfile, "$url/$fwfile");
-	verify($fwfile, $files{$fwfile});
-	$allfiles .= " $fwfile";
-    }
-
-    $allfiles =~ s/^\s//;
-
-    $allfiles;
-}
-
 sub or51132_qam {
     my $fwfile = "dvb-fe-or51132-qam.fw";
     my $url = "http://linuxtv.org/downloads/firmware/$fwfile";

diff --git a/trunk/Documentation/feature-removal-schedule.txt b/trunk/Documentation/feature-removal-schedule.txt
@@ -64,10 +64,10 @@ Who:	Pavel Machek <pavel@suse.cz>
 
 ---------------------------
 
-What:	Video4Linux API 1 ioctls and from Video devices.
-When:	July 2009
-Files:	include/linux/videodev.h
-Check:	include/linux/videodev.h
+What:	Video4Linux API 1 ioctls and video_decoder.h from Video devices.
+When:	December 2008
+Files:	include/linux/video_decoder.h include/linux/videodev.h
+Check:	include/linux/video_decoder.h include/linux/videodev.h
 Why:	V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6
 	series. The old API have lots of drawbacks and don't provide enough
 	means to work with all video and audio standards. The newer API is

diff --git a/trunk/Documentation/hwmon/ds1621 b/trunk/Documentation/hwmon/ds1621
@@ -49,9 +49,12 @@ of up to +/- 0.5 degrees even when compared against precise temperature
 readings. Be sure to have a high vs. low temperature limit gap of al least
 1.0 degree Celsius to avoid Tout "bouncing", though!
 
-The alarm bits are set when the high or low limits are met or exceeded and
-are reset by the module as soon as the respective temperature ranges are
-left.
+As for alarms, you can read the alarm status of the DS1621 via the 'alarms'
+/sys file interface. The result consists mainly of bit 6 and 5 of the
+configuration register of the chip; bit 6 (0x40 or 64) is the high alarm
+bit and bit 5 (0x20 or 32) the low one. These bits are set when the high or
+low limits are met or exceeded and are reset by the module as soon as the
+respective temperature ranges are left.
 
 The alarm registers are in no way suitable to find out about the actual
 status of Tout. They will only tell you about its history, whether or not
@@ -61,3 +64,45 @@ with neither of the alarms set.
 
 Temperature conversion of the DS1621 takes up to 1000ms; internal access to
 non-volatile registers may last for 10ms or below.
+
+High Accuracy Temperature Reading
+---------------------------------
+
+As said before, the temperature issued via the 9-bit i2c-bus data is
+somewhat arbitrary. Internally, the temperature conversion is of a
+different kind that is explained (not so...) well in the DS1621 data sheet.
+To cut the long story short: Inside the DS1621 there are two oscillators,
+both of them biassed by a temperature coefficient.
+
+Higher resolution of the temperature reading can be achieved using the
+internal projection, which means taking account of REG_COUNT and REG_SLOPE
+(the driver manages them):
+
+Taken from Dallas Semiconductors App Note 068: 'Increasing Temperature
+Resolution on the DS1620' and App Note 105: 'High Resolution Temperature
+Measurement with Dallas Direct-to-Digital Temperature Sensors'
+
+- Read the 9-bit temperature and strip the LSB (Truncate the .5 degs)
+- The resulting value is TEMP_READ.
+- Then, read REG_COUNT.
+- And then, REG_SLOPE.
+
+      TEMP = TEMP_READ - 0.25 + ((REG_SLOPE - REG_COUNT) / REG_SLOPE)
+
+Note that this is what the DONE bit in the DS1621 configuration register is
+good for: Internally, one temperature conversion takes up to 1000ms. Before
+that conversion is complete you will not be able to read valid things out
+of REG_COUNT and REG_SLOPE. The DONE bit, as you may have guessed by now,
+tells you whether the conversion is complete ("done", in plain English) and
+thus, whether the values you read are good or not.
+
+The DS1621 has two modes of operation: "Continuous" conversion, which can
+be understood as the default stand-alone mode where the chip gets the
+temperature and controls external devices via its Tout pin or tells other
+i2c's about it if they care. The other mode is called "1SHOT", that means
+that it only figures out about the temperature when it is explicitly told
+to do so; this can be seen as power saving mode.
+
+Now if you want to read REG_COUNT and REG_SLOPE, you have to either stop
+the continuous conversions until the contents of these registers are valid,
+or, in 1SHOT mode, you have to have one conversion made.
diff --git a/trunk/Documentation/hwmon/sysfs-interface b/trunk/Documentation/hwmon/sysfs-interface
@@ -365,7 +365,6 @@ energy[1-*]_input		Cumulative energy use
 				Unit: microJoule
 				RO
 
-
 **********
 * Alarms *
 **********
@@ -454,27 +453,6 @@ beep_mask	Bitmask for beep.
 		RW
 
 
-***********************
-* Intrusion detection *
-***********************
-
-intrusion[0-*]_alarm
-		Chassis intrusion detection
-		0: OK
-		1: intrusion detected
-		RW
-		Contrary to regular alarm flags which clear themselves
-		automatically when read, this one sticks until cleared by
-		the user. This is done by writing 0 to the file. Writing
-		other values is unsupported.
-
-intrusion[0-*]_beep
-		Chassis intrusion beep
-		0: disable
-		1: enable
-		RW
-
-
 sysfs attribute writes interpretation
 -------------------------------------