sh: convert /proc/cpu/aligmnent, /proc/cpu/kernel_alignment to seq_file

[safe/jmp/linux-2.6] / arch / blackfin / Kconfig.debug

diff --git a/arch/blackfin/Kconfig.debug b/arch/blackfin/Kconfig.debug
index 59b87a4..87f195e 100644 (file)
--- a/arch/blackfin/Kconfig.debug
+++ b/arch/blackfin/Kconfig.debug
@@ -2,6 +2,38 @@ menu "Kernel hacking"
 
 source "lib/Kconfig.debug"
 
+config DEBUG_STACKOVERFLOW
+       bool "Check for stack overflows"
+       depends on DEBUG_KERNEL
+       help
+         This option will cause messages to be printed if free stack space
+         drops below a certain limit.
+
+config DEBUG_STACK_USAGE
+       bool "Enable stack utilization instrumentation"
+       depends on DEBUG_KERNEL
+       help
+         Enables the display of the minimum amount of free stack which each
+         task has ever had available in the sysrq-T output.
+
+         This option will slow down process creation somewhat.
+
+config HAVE_ARCH_KGDB
+       def_bool y
+
+config DEBUG_VERBOSE
+       bool "Verbose fault messages"
+       default y
+       select PRINTK
+       help
+         When a program crashes due to an exception, or the kernel detects
+         an internal error, the kernel can print a not so brief message
+         explaining what the problem was. This debugging information is
+         useful to developers and kernel hackers when tracking down problems,
+         but mostly meaningless to other people. This is always helpful for
+         debugging but serves no purpose on a production system.
+         Most people should say N here.
+
 config DEBUG_MMRS
        bool "Generate Blackfin MMR tree"
        select DEBUG_FS
@@ -22,6 +54,57 @@ config DEBUG_HWERR
          hardware error interrupts and need to know where they are coming
          from.
 
+config EXACT_HWERR
+       bool "Try to make Hardware errors exact"
+       depends on DEBUG_HWERR
+       help
+         By default, the Blackfin hardware errors are not exact - the error
+          be reported multiple cycles after the error happens. This delay
+         can cause the wrong application, or even the kernel to receive a
+         signal to be killed. If you are getting HW errors in your system,
+         try turning this on to ensure they are at least comming from the
+         proper thread.
+
+         On production systems, it is safe (and a small optimization) to say N.
+
+config DEBUG_DOUBLEFAULT
+       bool "Debug Double Faults"
+       default n
+       help
+         If an exception is caused while executing code within the exception
+         handler, the NMI handler, the reset vector, or in emulator mode,
+         a double fault occurs. On the Blackfin, this is a unrecoverable
+         event. You have two options:
+         - RESET exactly when double fault occurs. The excepting
+           instruction address is stored in RETX, where the next kernel
+           boot will print it out.
+         - Print debug message. This is much more error prone, although
+           easier to handle. It is error prone since:
+           - The excepting instruction is not committed.
+           - All writebacks from the instruction are prevented.
+           - The generated exception is not taken.
+           - The EXCAUSE field is updated with an unrecoverable event
+           The only way to check this is to see if EXCAUSE contains the
+           unrecoverable event value at every exception return. By selecting
+           this option, you are skipping over the faulting instruction, and 
+           hoping things stay together enough to print out a debug message.
+
+         This does add a little kernel code, but is the only method to debug
+         double faults - if unsure say "Y"
+
+choice
+       prompt "Double Fault Failure Method"
+       default DEBUG_DOUBLEFAULT_PRINT
+       depends on DEBUG_DOUBLEFAULT
+
+config DEBUG_DOUBLEFAULT_PRINT
+       bool "Print"
+
+config DEBUG_DOUBLEFAULT_RESET
+       bool "Reset"
+
+endchoice
+
 config DEBUG_ICACHE_CHECK
        bool "Check Instruction cache coherency"
        depends on DEBUG_KERNEL
@@ -128,11 +211,11 @@ config DEBUG_BFIN_HWTRACE_EXPAND_LEN
          4 for (2^4) 16k, or 4096 entries
 
 config DEBUG_BFIN_NO_KERN_HWTRACE
-       bool "Trace user apps (turn off hwtrace in kernel)"
+       bool "Turn off hwtrace in CPLB handlers"
        depends on DEBUG_BFIN_HWTRACE_ON
-       default n
+       default y
        help
-         Some pieces of the kernel contain a lot of flow changes which can
+         The CPLB error handler contains a lot of flow changes which can
          quickly fill up the hardware trace buffer.  When debugging crashes,
          the hardware trace may indicate that the problem lies in kernel
          space when in reality an application is buggy.
@@ -143,6 +226,7 @@ config DEBUG_BFIN_NO_KERN_HWTRACE
 config EARLY_PRINTK
        bool "Early printk" 
        default n
+       select SERIAL_CORE_CONSOLE
        help
          This option enables special console drivers which allow the kernel
          to print messages very early in the bootup process.
@@ -154,17 +238,10 @@ config EARLY_PRINTK
          all of this lives in the init section and is thrown away after the
          kernel boots completely.
 
-config DUAL_CORE_TEST_MODULE
-       tristate "Dual Core Test Module"
-       depends on (BF561)
-       default n
-       help
-         Say Y here to build-in dual core test module for dual core test.
-
 config CPLB_INFO
        bool "Display the CPLB information"
        help
-         Display the CPLB information.
+         Display the CPLB information via /proc/cplbinfo.
 
 config ACCESS_CHECK
        bool "Check the user pointer address"
@@ -175,4 +252,10 @@ config ACCESS_CHECK
 
          Say N here to disable that check to improve the performance.
 
+config BFIN_ISRAM_SELF_TEST
+       bool "isram boot self tests"
+       default n
+       help
+         Run some self tests of the isram driver code at boot.
+
 endmenu