Skip to content

Commit

Permalink
---
Browse files Browse the repository at this point in the history
yaml
---
r: 148683
b: refs/heads/master
c: 947ec0b
h: refs/heads/master
i:
  148681: fcd2857
  148679: 189f000
v: v3
  • Loading branch information
Linus Torvalds committed Jun 12, 2009
1 parent b29f8c5 commit ecca8dd
Show file tree
Hide file tree
Showing 196 changed files with 9,331 additions and 2,565 deletions.
2 changes: 1 addition & 1 deletion [refs]
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
---
refs/heads/master: 5818a6e2519b34cd6d0220d89f5729ab2725e1bf
refs/heads/master: 947ec0b0c1e7e80eef4fe64f7763a06d0cf04d2e
16 changes: 10 additions & 6 deletions trunk/MAINTAINERS
Original file line number Diff line number Diff line change
Expand Up @@ -3363,6 +3363,16 @@ F: drivers/serial/kgdboc.c
F: include/linux/kgdb.h
F: kernel/kgdb.c

KMEMLEAK
P: Catalin Marinas
M: catalin.marinas@arm.com
L: linux-kernel@vger.kernel.org
S: Maintained
F: Documentation/kmemleak.txt
F: include/linux/kmemleak.h
F: mm/kmemleak.c
F: mm/kmemleak-test.c

KMEMTRACE
P: Eduard - Gabriel Munteanu
M: eduard.munteanu@linux360.ro
Expand All @@ -3372,12 +3382,6 @@ F: Documentation/trace/kmemtrace.txt
F: include/trace/kmemtrace.h
F: kernel/trace/kmemtrace.c

KMEMLEAK
P: Catalin Marinas
M: catalin.marinas@arm.com
L: linux-kernel@vger.kernel.org
S: Maintained

KPROBES
P: Ananth N Mavinakayanahalli
M: ananth@in.ibm.com
Expand Down
84 changes: 60 additions & 24 deletions trunk/arch/blackfin/Kconfig
Original file line number Diff line number Diff line change
Expand Up @@ -223,6 +223,7 @@ endchoice

config SMP
depends on BF561
select GENERIC_TIME
bool "Symmetric multi-processing support"
---help---
This enables support for systems with more than one CPU,
Expand All @@ -241,12 +242,6 @@ config IRQ_PER_CPU
depends on SMP
default y

config TICK_SOURCE_SYSTMR0
bool
select BFIN_GPTIMERS
depends on SMP
default y

config BF_REV_MIN
int
default 0 if (BF51x || BF52x || (BF54x && !BF54xM))
Expand All @@ -263,8 +258,8 @@ config BF_REV_MAX

choice
prompt "Silicon Rev"
default BF_REV_0_1 if (BF51x || BF52x || (BF54x && !BF54xM))
default BF_REV_0_2 if (BF534 || BF536 || BF537)
default BF_REV_0_0 if (BF51x || BF52x)
default BF_REV_0_2 if (BF534 || BF536 || BF537 || (BF54x && !BF54xM))
default BF_REV_0_3 if (BF531 || BF532 || BF533 || BF54xM || BF561)

config BF_REV_0_0
Expand Down Expand Up @@ -607,27 +602,45 @@ source kernel/Kconfig.hz

config GENERIC_TIME
bool "Generic time"
depends on !SMP
default y

config GENERIC_CLOCKEVENTS
bool "Generic clock events"
depends on GENERIC_TIME
default y

choice
prompt "Kernel Tick Source"
depends on GENERIC_CLOCKEVENTS
default TICKSOURCE_CORETMR

config TICKSOURCE_GPTMR0
bool "Gptimer0 (SCLK domain)"
select BFIN_GPTIMERS
depends on !IPIPE

config TICKSOURCE_CORETMR
bool "Core timer (CCLK domain)"

endchoice

config CYCLES_CLOCKSOURCE
bool "Use 'CYCLES' as a clocksource (EXPERIMENTAL)"
depends on EXPERIMENTAL
bool "Use 'CYCLES' as a clocksource"
depends on GENERIC_CLOCKEVENTS
depends on !BFIN_SCRATCH_REG_CYCLES
default n
depends on !SMP
help
If you say Y here, you will enable support for using the 'cycles'
registers as a clock source. Doing so means you will be unable to
safely write to the 'cycles' register during runtime. You will
still be able to read it (such as for performance monitoring), but
writing the registers will most likely crash the kernel.

config GPTMR0_CLOCKSOURCE
bool "Use GPTimer0 as a clocksource (higher rating)"
depends on GENERIC_CLOCKEVENTS
depends on !TICKSOURCE_GPTMR0

source kernel/time/Kconfig

comment "Misc"
Expand Down Expand Up @@ -808,7 +821,7 @@ config APP_STACK_L1
config EXCEPTION_L1_SCRATCH
bool "Locate exception stack in L1 Scratch Memory"
default n
depends on !APP_STACK_L1 && !SYSCALL_TAB_L1
depends on !APP_STACK_L1
help
Whenever an exception occurs, use the L1 Scratch memory for
stack storage. You cannot place the stacks of FLAT binaries
Expand Down Expand Up @@ -901,7 +914,7 @@ config BFIN_ICACHE_LOCK
bool "Enable Instruction Cache Locking"

choice
prompt "Policy"
prompt "External memory cache policy"
depends on BFIN_DCACHE
default BFIN_WB if !SMP
default BFIN_WT if SMP
Expand Down Expand Up @@ -942,12 +955,22 @@ config BFIN_WT

endchoice

config BFIN_L2_CACHEABLE
bool "Cache L2 SRAM"
depends on (BFIN_DCACHE || BFIN_ICACHE) && (BF54x || (BF561 && !SMP))
default n
help
Select to make L2 SRAM cacheable in L1 data and instruction cache.
choice
prompt "L2 SRAM cache policy"
depends on (BF54x || BF561)
default BFIN_L2_WT
config BFIN_L2_WB
bool "Write back"
depends on !SMP

config BFIN_L2_WT
bool "Write through"
depends on !SMP

config BFIN_L2_NOT_CACHED
bool "Not cached"

endchoice

config MPU
bool "Enable the memory protection unit (EXPERIMENTAL)"
Expand Down Expand Up @@ -1011,21 +1034,34 @@ endmenu

menu "EBIU_AMBCTL Control"
config BANK_0
hex "Bank 0"
hex "Bank 0 (AMBCTL0.L)"
default 0x7BB0
help
These are the low 16 bits of the EBIU_AMBCTL0 MMR which are
used to control the Asynchronous Memory Bank 0 settings.

config BANK_1
hex "Bank 1"
hex "Bank 1 (AMBCTL0.H)"
default 0x7BB0
default 0x5558 if BF54x
help
These are the high 16 bits of the EBIU_AMBCTL0 MMR which are
used to control the Asynchronous Memory Bank 1 settings.

config BANK_2
hex "Bank 2"
hex "Bank 2 (AMBCTL1.L)"
default 0x7BB0
help
These are the low 16 bits of the EBIU_AMBCTL1 MMR which are
used to control the Asynchronous Memory Bank 2 settings.

config BANK_3
hex "Bank 3"
hex "Bank 3 (AMBCTL1.H)"
default 0x99B3
help
These are the high 16 bits of the EBIU_AMBCTL1 MMR which are
used to control the Asynchronous Memory Bank 3 settings.

endmenu

config EBIU_MBSCTLVAL
Expand Down
13 changes: 13 additions & 0 deletions trunk/arch/blackfin/Kconfig.debug
Original file line number Diff line number Diff line change
Expand Up @@ -54,6 +54,19 @@ 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
Expand Down
Loading

0 comments on commit ecca8dd

Please sign in to comment.