Merge ../linux-2.6/ (f28e7161) · Commits · EulixOS / Software / Kernel

CREDITS

+5 −0

Original line number	Diff line number	Diff line
		@@ -24,6 +24,11 @@ S: C. Negri 6, bl. D3
		S: Iasi 6600
		S: Romania

		N: Mark Adler
		E: madler@alumni.caltech.edu
		W: http://alumnus.caltech.edu/~madler/
		D: zlib decompression

		N: Monalisa Agrawal
		E: magrawal@nortelnetworks.com
		D: Basic Interphase 5575 driver with UBR and ABR support.

Documentation/DocBook/kernel-locking.tmpl

+1 −1

Original line number	Diff line number	Diff line
		@@ -1590,7 +1590,7 @@ the amount of locking which needs to be done.
		<para>
		Our final dilemma is this: when can we actually destroy the
		removed element? Remember, a reader might be stepping through
		this element in the list right now: it we free this element and
		this element in the list right now: if we free this element and
		the <symbol>next</symbol> pointer changes, the reader will jump
		off into garbage and crash. We need to wait until we know that
		all the readers who were traversing the list when we deleted the

Documentation/RCU/torture.txt

+24 −10

Original line number	Diff line number	Diff line
		@@ -7,7 +7,7 @@ The CONFIG_RCU_TORTURE_TEST config option is available for all RCU
		implementations. It creates an rcutorture kernel module that can
		be loaded to run a torture test. The test periodically outputs
		status messages via printk(), which can be examined via the dmesg
		command (perhaps grepping for "rcutorture"). The test is started
		command (perhaps grepping for "torture"). The test is started
		when the module is loaded, and stops when the module is unloaded.

		However, actually setting this config option to "y" results in the system
		@@ -35,6 +35,19 @@ stat_interval The number of seconds between output of torture
		be printed -only- when the module is unloaded, and this
		is the default.

		shuffle_interval
		The number of seconds to keep the test threads affinitied
		to a particular subset of the CPUs. Used in conjunction
		with test_no_idle_hz.

		test_no_idle_hz Whether or not to test the ability of RCU to operate in
		a kernel that disables the scheduling-clock interrupt to
		idle CPUs. Boolean parameter, "1" to test, "0" otherwise.

		torture_type The type of RCU to test: "rcu" for the rcu_read_lock()
		API, "rcu_bh" for the rcu_read_lock_bh() API, and "srcu"
		for the "srcu_read_lock()" API.

		verbose Enable debug printk()s. Default is disabled.


		@@ -42,14 +55,14 @@ OUTPUT

		The statistics output is as follows:

		rcutorture: --- Start of test: nreaders=16 stat_interval=0 verbose=0
		rcutorture: rtc: 0000000000000000 ver: 1916 tfle: 0 rta: 1916 rtaf: 0 rtf: 1915
		rcutorture: Reader Pipe: 1466408 9747 0 0 0 0 0 0 0 0 0
		rcutorture: Reader Batch: 1464477 11678 0 0 0 0 0 0 0 0
		rcutorture: Free-Block Circulation: 1915 1915 1915 1915 1915 1915 1915 1915 1915 1915 0
		rcutorture: --- End of test
		rcu-torture: --- Start of test: nreaders=16 stat_interval=0 verbose=0
		rcu-torture: rtc: 0000000000000000 ver: 1916 tfle: 0 rta: 1916 rtaf: 0 rtf: 1915
		rcu-torture: Reader Pipe: 1466408 9747 0 0 0 0 0 0 0 0 0
		rcu-torture: Reader Batch: 1464477 11678 0 0 0 0 0 0 0 0
		rcu-torture: Free-Block Circulation: 1915 1915 1915 1915 1915 1915 1915 1915 1915 1915 0
		rcu-torture: --- End of test

		The command "dmesg \| grep rcutorture:" will extract this information on
		The command "dmesg \| grep torture:" will extract this information on
		most systems. On more esoteric configurations, it may be necessary to
		use other commands to access the output of the printk()s used by
		the RCU torture test. The printk()s use KERN_ALERT, so they should
		@@ -115,8 +128,9 @@ The following script may be used to torture RCU:
		modprobe rcutorture
		sleep 100
		rmmod rcutorture
		dmesg \| grep rcutorture:
		dmesg \| grep torture:

		The output can be manually inspected for the error flag of "!!!".
		One could of course create a more elaborate script that automatically
		checked for such errors.
		checked for such errors. The "rmmod" command forces a "SUCCESS" or
		"FAILURE" indication to be printk()ed.

Documentation/arm/Samsung-S3C24XX/Overview.txt

+14 −21

Original line number	Diff line number	Diff line
		@@ -7,11 +7,13 @@ Introduction
		------------

		The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported
		by the 's3c2410' architecture of ARM Linux. Currently the S3C2410 and
		the S3C2440 are supported CPUs.
		by the 's3c2410' architecture of ARM Linux. Currently the S3C2410,
		S3C2440 and S3C2442 devices are supported.

		Support for the S3C2400 series is in progress.

		Support for the S3C2412 and S3C2413 CPUs is being merged.


		Configuration
		-------------
		@@ -43,9 +45,18 @@ Machines

		Samsung's own development board, geared for PDA work.

		Samsung/Aiji SMDK2412

		The S3C2412 version of the SMDK2440.

		Samsung/Aiji SMDK2413

		The S3C2412 version of the SMDK2440.

		Samsung/Meritech SMDK2440

		The S3C2440 compatible version of the SMDK2440
		The S3C2440 compatible version of the SMDK2440, which has the
		option of an S3C2440 or S3C2442 CPU module.

		Thorcom VR1000

		@@ -211,24 +222,6 @@ Port Contributors
		Lucas Correia Villa Real (S3C2400 port)


		Document Changes
		----------------

		05 Sep 2004 - BJD - Added Document Changes section
		05 Sep 2004 - BJD - Added Klaus Fetscher to list of contributors
		25 Oct 2004 - BJD - Added Dimitry Andric to list of contributors
		25 Oct 2004 - BJD - Updated the MTD from the 2.6.9 merge
		21 Jan 2005 - BJD - Added rx3715, added Shannon to contributors
		10 Feb 2005 - BJD - Added Guillaume Gourat to contributors
		02 Mar 2005 - BJD - Added SMDK2440 to list of machines
		06 Mar 2005 - BJD - Added Christer Weinigel
		08 Mar 2005 - BJD - Added LCVR to list of people, updated introduction
		08 Mar 2005 - BJD - Added section on adding machines
		09 Sep 2005 - BJD - Added section on platform data
		11 Feb 2006 - BJD - Added I2C, RTC and Watchdog sections
		11 Feb 2006 - BJD - Added Osiris machine, and S3C2400 information


		Document Author
		---------------

Documentation/arm/Samsung-S3C24XX/S3C2412.txt

0 → 100644

+120 −0

Original line number	Diff line number	Diff line
		S3C2412 ARM Linux Overview
		==========================

		Introduction
		------------

		The S3C2412 is part of the S3C24XX range of ARM9 System-on-Chip CPUs
		from Samsung. This part has an ARM926-EJS core, capable of running up
		to 266MHz (see data-sheet for more information)


		Clock
		-----

		The core clock code provides a set of clocks to the drivers, and allows
		for source selection and a number of other features.


		Power
		-----

		No support for suspend/resume to RAM in the current system.


		DMA
		---

		No current support for DMA.


		GPIO
		----

		There is support for setting the GPIO to input/output/special function
		and reading or writing to them.


		UART
		----

		The UART hardware is similar to the S3C2440, and is supported by the
		s3c2410 driver in the drivers/serial directory.


		NAND
		----

		The NAND hardware is similar to the S3C2440, and is supported by the
		s3c2410 driver in the drivers/mtd/nand directory.


		USB Host
		--------

		The USB hardware is similar to the S3C2410, with extended clock source
		control. The OHCI portion is supported by the ohci-s3c2410 driver, and
		the clock control selection is supported by the core clock code.


		USB Device
		----------

		No current support in the kernel


		IRQs
		----

		All the standard, and external interrupt sources are supported. The
		extra sub-sources are not yet supported.


		RTC
		---

		The RTC hardware is similar to the S3C2410, and is supported by the
		s3c2410-rtc driver.


		Watchdog
		--------

		The watchdog harware is the same as the S3C2410, and is supported by
		the s3c2410_wdt driver.


		MMC/SD/SDIO
		-----------

		No current support for the MMC/SD/SDIO block.

		IIC
		---

		The IIC hardware is the same as the S3C2410, and is supported by the
		i2c-s3c24xx driver.


		IIS
		---

		No current support for the IIS interface.


		SPI
		---

		No current support for the SPI interfaces.


		ATA
		---

		No current support for the on-board ATA block.


		Document Author
		---------------

		Ben Dooks, (c) 2006 Simtec Electronics