Merge tag 'xtensa-next-20130508' of git://github.com/czankel/xtensa-linux

Pull xtensa updates from Chris Zankel:
 "Support for the latest MMU architecture that allows for a larger
  accessible memory region, and various bug-fixes"

* tag 'xtensa-next-20130508' of git://github.com/czankel/xtensa-linux:
  xtensa: Switch to asm-generic/linkage.h
  xtensa: fix redboot load address
  xtensa: ISS: fix timer_lock usage in rs_open
  xtensa: disable IRQs while IRQ handler is running
  xtensa: enable lockdep support
  xtensa: fix arch_irqs_disabled_flags implementation
  xtensa: add irq flags trace support
  xtensa: provide custom CALLER_ADDR* implementations
  xtensa: add stacktrace support
  xtensa: clean up stpill_registers
  xtensa: don't use a7 in simcalls
  xtensa: don't attempt to use unconfigured timers
  xtensa: provide default platform_pcibios_init implementation
  xtensa: remove KCORE_ELF again
  xtensa: document MMUv3 setup sequence
  xtensa: add MMU v3 support
  xtensa: fix ibreakenable register update
  xtensa: fix oprofile building as module

1 files changed, 39 insertions, 18 deletions

diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig
index acdfc615cca2..0a1b95f81a32 100644
--- a/arch/xtensa/Kconfig
+++ b/arch/xtensa/Kconfig
@@ -1,11 +1,9 @@
-config FRAME_POINTER
-	def_bool n
-
 config ZONE_DMA
 	def_bool y
 
 config XTENSA
 	def_bool y
+	select ARCH_WANT_FRAME_POINTERS
 	select HAVE_IDE
 	select GENERIC_ATOMIC64
 	select HAVE_GENERIC_HARDIRQS
@@ -49,6 +47,15 @@ config HZ
 source "init/Kconfig"
 source "kernel/Kconfig.freezer"
 
+config LOCKDEP_SUPPORT
+	def_bool y
+
+config STACKTRACE_SUPPORT
+	def_bool y
+
+config TRACE_IRQFLAGS_SUPPORT
+	def_bool y
+
 config MMU
 	def_bool n
 
@@ -100,6 +107,35 @@ config MATH_EMULATION
 	help
 	Can we use information of configuration file?
 
+config INITIALIZE_XTENSA_MMU_INSIDE_VMLINUX
+	bool "Initialize Xtensa MMU inside the Linux kernel code"
+	default y
+	help
+	  Earlier version initialized the MMU in the exception vector
+	  before jumping to _startup in head.S and had an advantage that
+	  it was possible to place a software breakpoint at 'reset' and
+	  then enter your normal kernel breakpoints once the MMU was mapped
+	  to the kernel mappings (0XC0000000).
+
+	  This unfortunately doesn't work for U-Boot and likley also wont
+	  work for using KEXEC to have a hot kernel ready for doing a
+	  KDUMP.
+
+	  So now the MMU is initialized in head.S but it's necessary to
+	  use hardware breakpoints (gdb 'hbreak' cmd) to break at _startup.
+	  xt-gdb can't place a Software Breakpoint in the  0XD region prior
+	  to mapping the MMU and after mapping even if the area of low memory
+	  was mapped gdb wouldn't remove the breakpoint on hitting it as the
+	  PC wouldn't match. Since Hardware Breakpoints are recommended for
+	  Linux configurations it seems reasonable to just assume they exist
+	  and leave this older mechanism for unfortunate souls that choose
+	  not to follow Tensilica's recommendation.
+
+	  Selecting this will cause U-Boot to set the KERNEL Load and Entry
+	  address at 0x00003000 instead of the mapped std of 0xD0003000.
+
+	  If in doubt, say Y.
+
 endmenu
 
 config XTENSA_CALIBRATE_CCOUNT
@@ -249,21 +285,6 @@ endmenu
 
 menu "Executable file formats"
 
-# only elf supported
-config KCORE_ELF
-	def_bool y
-        depends on PROC_FS
-        help
-          If you enabled support for /proc file system then the file
-          /proc/kcore will contain the kernel core image in ELF format. This
-          can be used in gdb:
-
-          $ cd /usr/src/linux ; gdb vmlinux /proc/kcore
-
-          This is especially useful if you have compiled the kernel with the
-          "-g" option to preserve debugging information. It is mainly used
-	  for examining kernel data structures on the live kernel.
-
 source "fs/Kconfig.binfmt"
 
 endmenu