litmus-rt.git/arch/xtensa/Kconfig, branch v2.6.28-rc2

Merge git://git.kernel.org/pub/scm/linux/kernel/git/czankel/xtensa-2.6

2008-10-23T16:16:56+00:00

* git://git.kernel.org/pub/scm/linux/kernel/git/czankel/xtensa-2.6:
  xtensa: Add config files for Diamond 232L - Rev B processor variant
  xtensa: Fix io regions
  xtensa: Add support for the Sonic Ethernet device for the XT2000 board.
  xtensa: replace remaining __FUNCTION__ occurrences
  xtensa: use newer __SPIN_LOCK_UNLOCKED macro
  XTENSA: warn about including  directly.

xtensa: Add config files for Diamond 232L - Rev B processor variant

2008-10-21T16:11:43+00:00

The Diamond 232L processor is a pre-configured Xtensa processor tailored
for Linux application.

Signed-off-by: Chris Zankel

container freezer: implement freezer cgroup subsystem

2008-10-20T15:52:34+00:00

This patch implements a new freezer subsystem in the control groups
framework.  It provides a way to stop and resume execution of all tasks in
a cgroup by writing in the cgroup filesystem.

The freezer subsystem in the container filesystem defines a file named
freezer.state.  Writing "FROZEN" to the state file will freeze all tasks
in the cgroup.  Subsequently writing "RUNNING" will unfreeze the tasks in
the cgroup.  Reading will return the current state.

* Examples of usage :

   # mkdir /containers/freezer
   # mount -t cgroup -ofreezer freezer  /containers
   # mkdir /containers/0
   # echo $some_pid > /containers/0/tasks

to get status of the freezer subsystem :

   # cat /containers/0/freezer.state
   RUNNING

to freeze all tasks in the container :

   # echo FROZEN > /containers/0/freezer.state
   # cat /containers/0/freezer.state
   FREEZING
   # cat /containers/0/freezer.state
   FROZEN

to unfreeze all tasks in the container :

   # echo RUNNING > /containers/0/freezer.state
   # cat /containers/0/freezer.state
   RUNNING

This is the basic mechanism which should do the right thing for user space
task in a simple scenario.

It's important to note that freezing can be incomplete.  In that case we
return EBUSY.  This means that some tasks in the cgroup are busy doing
something that prevents us from completely freezing the cgroup at this
time.  After EBUSY, the cgroup will remain partially frozen -- reflected
by freezer.state reporting "FREEZING" when read.  The state will remain
"FREEZING" until one of these things happens:

	1) Userspace cancels the freezing operation by writing "RUNNING" to
		the freezer.state file
	2) Userspace retries the freezing operation by writing "FROZEN" to
		the freezer.state file (writing "FREEZING" is not legal
		and returns EIO)
	3) The tasks that blocked the cgroup from entering the "FROZEN"
		state disappear from the cgroup's set of tasks.

[akpm@linux-foundation.org: coding-style fixes]
[akpm@linux-foundation.org: export thaw_process]
Signed-off-by: Cedric Le Goater 
Signed-off-by: Matt Helsley 
Acked-by: Serge E. Hallyn 
Tested-by: Matt Helsley 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

remove mention of CONFIG_KMOD from documentation

2008-07-22T09:24:29+00:00

Also includes a few Kconfig files (xtensa, blackfin)

Signed-off-by: Johannes Berg 
Cc: Michael Kerrisk 
Cc: linux-doc@vger.kernel.org
Signed-off-by: Rusty Russell 
Acked-by: Randy Dunlap

ide: introduce HAVE_IDE

2008-02-09T09:46:40+00:00

To allow flexible configuration of IDE introduce HAVE_IDE.
All archs except arm, um and s390 unconditionally select it.
For arm the actual configuration determine if IDE is supported.

This is a step towards introducing drivers/Kconfig for arm.

Signed-off-by: Sam Ravnborg 
Acked-by: Russell King - ARM Linux 
Acked-by: Bartlomiej Zolnierkiewicz

avoid overflows in kernel/time.c

2008-02-08T17:22:39+00:00

When the conversion factor between jiffies and milli- or microseconds is
not a single multiply or divide, as for the case of HZ == 300, we currently
do a multiply followed by a divide.  The intervening result, however, is
subject to overflows, especially since the fraction is not simplified (for
HZ == 300, we multiply by 300 and divide by 1000).

This is exposed to the user when passing a large timeout to poll(), for
example.

This patch replaces the multiply-divide with a reciprocal multiplication on
32-bit platforms.  When the input is an unsigned long, there is no portable
way to do this on 64-bit platforms there is no portable way to do this
since it requires a 128-bit intermediate result (which gcc does support on
64-bit platforms but may generate libgcc calls, e.g.  on 64-bit s390), but
since the output is a 32-bit integer in the cases affected, just simplify
the multiply-divide (*3/10 instead of *300/1000).

The reciprocal multiply used can have off-by-one errors in the upper half
of the valid output range.  This could be avoided at the expense of having
to deal with a potential 65-bit intermediate result.  Since the intent is
to avoid overflow problems and most of the other time conversions are only
semiexact, the off-by-one errors were considered an acceptable tradeoff.

At Ralf Baechle's suggestion, this version uses a Perl script to compute
the necessary constants.  We already have dependencies on Perl for kernel
compiles.  This does, however, require the Perl module Math::BigInt, which
is included in the standard Perl distribution starting with version 5.8.0.
In order to support older versions of Perl, include a table of canned
constants in the script itself, and structure the script so that
Math::BigInt isn't required if pulling values from said table.

Running the script requires that the HZ value is available from the
Makefile.  Thus, this patch also adds the Kconfig variable CONFIG_HZ to the
architectures which didn't already have it (alpha, cris, frv, h8300, m32r,
m68k, m68knommu, sparc, v850, and xtensa.) It does *not* touch the sh or
sh64 architectures, since Paul Mundt has dealt with those separately in the
sh tree.

Signed-off-by: H. Peter Anvin 
Cc: Ralf Baechle ,
Cc: Sam Ravnborg ,
Cc: Paul Mundt ,
Cc: Richard Henderson ,
Cc: Michael Starvik ,
Cc: David Howells ,
Cc: Yoshinori Sato ,
Cc: Hirokazu Takata ,
Cc: Geert Uytterhoeven ,
Cc: Roman Zippel ,
Cc: William L. Irwin ,
Cc: Chris Zankel ,
Cc: H. Peter Anvin ,
Cc: Jan Engelhardt 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig

2008-02-03T07:58:08+00:00

Move the instrumentation Kconfig to

arch/Kconfig for architecture dependent options
  - oprofile
  - kprobes

and

init/Kconfig for architecture independent options
  - profiling
  - markers

Remove the "Instrumentation Support" menu. Everything moves to "General setup".
Delete the kernel/Kconfig.instrumentation file.

Signed-off-by: Mathieu Desnoyers 
Cc: Linus Torvalds 
Cc: 
Signed-off-by: Sam Ravnborg

PCI: Kconfig help: don't refer to the PCI-HOWTO

2008-02-01T23:04:26+00:00

A HOWTO that hasn't been updated for half a dozen years no longer
"contains valuable information about which PCI hardware does work under
Linux and which doesn't".

Signed-off-by: Adrian Bunk 
Signed-off-by: Greg Kroah-Hartman

Kbuild/doc: fix links to Documentation files

2007-10-30T21:26:30+00:00

Fix links to files in Documentation/* in various Kconfig files

Signed-off-by: Dirk Hohndel 
Signed-off-by: Linus Torvalds

Combine instrumentation menus in kernel/Kconfig.instrumentation

2007-10-19T18:53:54+00:00

Quoting Randy:

"It seems sad that this patch sources Kconfig.marker, a 7-line file,
20-something times.  Yes, you (we) don't want to put those 7 lines into
20-something different files, so sourcing is the right thing.

However, what you did for avr32 seems more on the right track to me: make
_one_ Instrumentation support menu that includes PROFILING, OPROFILE, KPROBES,
and MARKERS and then use (source) that in all of the arches."

Signed-off-by: Mathieu Desnoyers 
Acked-by: Randy Dunlap 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds