---

yaml
---
r: 107231
b: refs/heads/master
c: 383795c
h: refs/heads/master
i:
  107229: 88d00d2
  107227: 0270aa9
  107223: 74fbeec
  107215: 4dcab67
  107199: b4cec0e
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: b14f7fb5aa2f4289e3a9fa8d7d92417ec8607498
+refs/heads/master: 383795c206946777d87ed5f6d61d6659110f9344

trunk/Documentation/power/power_supply_class.txt

@@ -101,10 +101,6 @@ of charge when battery became full/empty". It also could mean "value of
 charge when battery considered full/empty at given conditions (temperature,
 age)". I.e. these attributes represents real thresholds, not design values.
 
-CHARGE_COUNTER - the current charge counter (in µAh).  This could easily
-be negative; there is no empty or full value.  It is only useful for
-relative, time-based measurements.
-
 ENERGY_FULL, ENERGY_EMPTY - same as above but for energy.
 
 CAPACITY - capacity in percents.

trunk/Documentation/powerpc/00-INDEX

@@ -20,6 +20,8 @@ mpc52xx-device-tree-bindings.txt
 	- MPC5200 Device Tree Bindings
 ppc_htab.txt
 	- info about the Linux/PPC /proc/ppc_htab entry
+SBC8260_memory_mapping.txt
+	- EST SBC8260 board info
 smp.txt
 	- use and state info about Linux/PPC on MP machines
 sound.txt

trunk/Documentation/powerpc/SBC8260_memory_mapping.txt

@@ -0,0 +1,197 @@
+Please mail me (Jon Diekema, diekema_jon@si.com or diekema@cideas.com)
+if you have questions, comments or corrections.
+
+	* EST SBC8260 Linux memory mapping rules
+
+	http://www.estc.com/ 
+	http://www.estc.com/products/boards/SBC8260-8240_ds.html
+
+	Initial conditions:
+	-------------------
+
+	Tasks that need to be perform by the boot ROM before control is
+	transferred to zImage (compressed Linux kernel):
+
+	- Define the IMMR to 0xf0000000
+
+	- Initialize the memory controller so that RAM is available at
+	  physical address 0x00000000.  On the SBC8260 is this 16M (64M)
+	  SDRAM.
+
+	- The boot ROM should only clear the RAM that it is using.
+
+	  The reason for doing this is to enhances the chances of a
+	  successful post mortem on a Linux panic.  One of the first
+	  items to examine is the 16k (LOG_BUF_LEN) circular console
+	  buffer called log_buf which is defined in kernel/printk.c.
+
+	- To enhance boot ROM performance, the I-cache can be enabled.
+
+	  Date: Mon, 22 May 2000 14:21:10 -0700
+	  From: Neil Russell <caret@c-side.com>
+
+	  LiMon (LInux MONitor) runs with and starts Linux with MMU
+	  off, I-cache enabled, D-cache disabled.  The I-cache doesn't
+	  need hints from the MMU to work correctly as the D-cache
+	  does.  No D-cache means no special code to handle devices in
+	  the presence of cache (no snooping, etc). The use of the
+	  I-cache means that the monitor can run acceptably fast
+	  directly from ROM, rather than having to copy it to RAM.
+
+	- Build the board information structure (see 
+	  include/asm-ppc/est8260.h for its definition)
+
+	- The compressed Linux kernel (zImage) contains a bootstrap loader 
+	  that is position independent; you can load it into any RAM, 
+	  ROM or FLASH memory address >= 0x00500000 (above 5 MB), or
+	  at its link address of 0x00400000 (4 MB).
+
+	  Note: If zImage is loaded at its link address of 0x00400000 (4 MB),
+	        then zImage will skip the step of moving itself to 
+		its link address.
+
+	- Load R3 with the address of the board information structure
+
+	- Transfer control to zImage
+
+	- The Linux console port is SMC1, and the baud rate is controlled
+	  from the bi_baudrate field of the board information structure.
+	  On thing to keep in mind when picking the baud rate, is that
+	  there is no flow control on the SMC ports.  I would stick
+	  with something safe and standard like 19200.
+
+	  On the EST SBC8260, the SMC1 port is on the COM1 connector of
+	  the board.
+
+
+	EST SBC8260 defaults:
+	---------------------
+
+                                Chip
+        Memory                  Sel  Bus   Use
+        ---------------------   ---  ---   ----------------------------------
+	0x00000000-0x03FFFFFF   CS2  60x   (16M or 64M)/64M SDRAM
+	0x04000000-0x04FFFFFF   CS4  local  4M/16M SDRAM (soldered to the board)
+	0x21000000-0x21000000   CS7  60x    1B/64K Flash present detect (from the flash SIMM)
+	0x21000001-0x21000001   CS7  60x    1B/64K Switches (read) and LEDs (write)
+	0x22000000-0x2200FFFF   CS5  60x    8K/64K EEPROM
+	0xFC000000-0xFCFFFFFF   CS6  60x    2M/16M flash (8 bits wide, soldered to the board)
+	0xFE000000-0xFFFFFFFF   CS0  60x    4M/16M flash (SIMM)
+
+	Notes:
+	------
+
+	- The chip selects can map 32K blocks and up (powers of 2)
+
+	- The SDRAM machine can handled up to 128Mbytes per chip select
+
+	- Linux uses the 60x bus memory (the SDRAM DIMM) for the 
+	  communications buffers.
+
+	- BATs can map 128K-256Mbytes each.  There are four data BATs and
+	  four instruction BATs.  Generally the data and instruction BATs
+	  are mapped the same.
+
+	- The IMMR must be set above the kernel virtual memory addresses,
+	  which start at 0xC0000000.  Otherwise, the kernel may crash as
+	  soon as you start any threads or processes due to VM collisions 
+	  in the kernel or user process space.
+
+
+	  Details from Dan Malek <dan_malek@mvista.com> on 10/29/1999:
+
+	  The user application virtual space consumes the first 2 Gbytes
+	  (0x00000000 to 0x7FFFFFFF).  The kernel virtual text starts at
+	  0xC0000000, with data following.  There is a "protection hole"
+	  between the end of kernel data and the start of the kernel
+	  dynamically allocated space, but this space is still within
+	  0xCxxxxxxx.
+
+	  Obviously the kernel can't map any physical addresses 1:1 in
+	  these ranges.
+
+
+	  Details from Dan Malek <dan_malek@mvista.com> on 5/19/2000:
+
+	  During the early kernel initialization, the kernel virtual
+	  memory allocator is not operational.  Prior to this KVM
+	  initialization, we choose to map virtual to physical addresses
+	  1:1.  That is, the kernel virtual address exactly matches the
+	  physical address on the bus.  These mappings are typically done
+	  in arch/ppc/kernel/head.S, or arch/ppc/mm/init.c.  Only
+	  absolutely necessary mappings should be done at this time, for
+	  example board control registers or a serial uart.  Normal device
+	  driver initialization should map resources later when necessary.
+
+	  Although platform dependent, and certainly the case for embedded
+	  8xx, traditionally memory is mapped at physical address zero,
+	  and I/O devices above physical address 0x80000000.  The lowest
+	  and highest (above 0xf0000000) I/O addresses are traditionally 
+	  used for devices or registers we need to map during kernel 
+	  initialization and prior to KVM operation.  For this reason, 
+	  and since it followed prior PowerPC platform examples, I chose 
+	  to map the embedded 8xx kernel to the 0xc0000000 virtual address.
+	  This way, we can enable the MMU to map the kernel for proper 
+	  operation, and still map a few windows before the KVM is operational.
+
+	  On some systems, you could possibly run the kernel at the 
+	  0x80000000 or any other virtual address.  It just depends upon 
+	  mapping that must be done prior to KVM operational.  You can never 
+	  map devices or kernel spaces that overlap with the user virtual 
+	  space.  This is why default IMMR mapping used by most BDM tools 
+	  won't work.  They put the IMMR at something like 0x10000000 or 
+	  0x02000000 for example.  You simply can't map these addresses early
+	  in the kernel, and continue proper system operation.
+
+	  The embedded 8xx/82xx kernel is mature enough that all you should 
+	  need to do is map the IMMR someplace at or above 0xf0000000 and it 
+	  should boot far enough to get serial console messages and KGDB 
+	  connected on any platform.  There are lots of other subtle memory 
+	  management design features that you simply don't need to worry 
+	  about.  If you are changing functions related to MMU initialization,
+	  you are likely breaking things that are known to work and are 
+	  heading down a path of disaster and frustration.  Your changes 
+	  should be to make the flexibility of the processor fit Linux, 
+	  not force arbitrary and non-workable memory mappings into Linux.
+
+	- You don't want to change KERNELLOAD or KERNELBASE, otherwise the
+	  virtual memory and MMU code will get confused.
+
+	  arch/ppc/Makefile:KERNELLOAD = 0xc0000000
+
+	  include/asm-ppc/page.h:#define PAGE_OFFSET    0xc0000000
+	  include/asm-ppc/page.h:#define KERNELBASE     PAGE_OFFSET
+
+	- RAM is at physical address 0x00000000, and gets mapped to 
+	  virtual address 0xC0000000 for the kernel.
+
+
+	Physical addresses used by the Linux kernel:
+	--------------------------------------------
+
+	0x00000000-0x3FFFFFFF   1GB reserved for RAM
+	0xF0000000-0xF001FFFF   128K IMMR  64K used for dual port memory,
+                                 64K for 8260 registers
+
+
+        Logical addresses used by the Linux kernel:
+	-------------------------------------------
+
+	0xF0000000-0xFFFFFFFF   256M BAT0 (IMMR: dual port RAM, registers)
+	0xE0000000-0xEFFFFFFF   256M BAT1 (I/O space for custom boards)
+	0xC0000000-0xCFFFFFFF   256M BAT2 (RAM)
+	0xD0000000-0xDFFFFFFF   256M BAT3 (if RAM > 256MByte)
+
+
+	EST SBC8260 Linux mapping:
+	--------------------------
+
+	DBAT0, IBAT0, cache inhibited:
+
+                                Chip
+        Memory                  Sel  Use
+        ---------------------   ---  ---------------------------------
+        0xF0000000-0xF001FFFF   n/a  IMMR: dual port RAM, registers
+
+        DBAT1, IBAT1, cache inhibited:
+

trunk/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt

@@ -7,15 +7,6 @@ Currently defined compatibles:
 - fsl,cpm2-scc-uart
 - fsl,qe-uart
 
-Modem control lines connected to GPIO controllers are listed in the gpios
-property as described in booting-without-of.txt, section IX.1 in the following
-order:
-
-CTS, RTS, DCD, DSR, DTR, and RI.
-
-The gpios property is optional and can be left out when control lines are
-not used.
-
 Example:
 
 	serial@11a00 {
@@ -27,6 +18,4 @@ Example:
 		interrupt-parent = <&PIC>;
 		fsl,cpm-brg = <1>;
 		fsl,cpm-command = <00800000>;
-		gpios = <&gpio_c 15 0
-			 &gpio_d 29 0>;
 	};

trunk/Documentation/rfkill.txt

@@ -390,10 +390,9 @@ rfkill lines are inactive, it must return RFKILL_STATE_SOFT_BLOCKED if its soft
 rfkill input line is active.  Only if none of the rfkill input lines are
 active, will it return RFKILL_STATE_UNBLOCKED.
 
-Since the device has a hardware rfkill line, it IS subject to state changes
-external to rfkill.  Therefore, the driver must make sure that it calls
-rfkill_force_state() to keep the status always up-to-date, and it must do a
-rfkill_force_state() on resume from sleep.
+If it doesn't implement the get_state() hook, it must make sure that its calls
+to rfkill_force_state() are enough to keep the status always up-to-date, and it
+must do a rfkill_force_state() on resume from sleep.
 
 Every time the driver gets a notification from the card that one of its rfkill
 lines changed state (polling might be needed on badly designed cards that don't
@@ -423,24 +422,13 @@ of the hardware is unknown), or read-write (where the hardware can be queried
 about its current state).
 
 The rfkill class will call the get_state hook of a device every time it needs
-to know the *real* current state of the hardware.  This can happen often, but
-it does not do any polling, so it is not enough on hardware that is subject
-to state changes outside of the rfkill subsystem.
-
-Therefore, calling rfkill_force_state() when a state change happens is
-mandatory when the device has a hardware rfkill line, or when something else
-like the firmware could cause its state to be changed without going through the
-rfkill class.
+to know the *real* current state of the hardware.  This can happen often.
 
 Some hardware provides events when its status changes.  In these cases, it is
 best for the driver to not provide a get_state hook, and instead register the
 rfkill class *already* with the correct status, and keep it updated using
 rfkill_force_state() when it gets an event from the hardware.
 
-rfkill_force_state() must be used on the device resume handlers to update the
-rfkill status, should there be any chance of the device status changing during
-the sleep.
-
 There is no provision for a statically-allocated rfkill struct.  You must
 use rfkill_allocate() to allocate one.
 

trunk/MAINTAINERS

@@ -3968,7 +3968,7 @@ M:	lethal@linux-sh.org
 L:	linux-sh@vger.kernel.org
 W:	http://www.linux-sh.org
 T:	git kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git
-S:	Supported
+S:	Maintained
 
 SUN3/3X
 P:	Sam Creasey

trunk/arch/ia64/mm/hugetlbpage.c

@@ -13,7 +13,6 @@
 #include <linux/mm.h>
 #include <linux/hugetlb.h>
 #include <linux/pagemap.h>
-#include <linux/module.h>
 #include <linux/slab.h>
 #include <linux/sysctl.h>
 #include <linux/log2.h>
@@ -22,8 +21,7 @@
 #include <asm/tlb.h>
 #include <asm/tlbflush.h>
 
-unsigned int hpage_shift = HPAGE_SHIFT_DEFAULT;
-EXPORT_SYMBOL(hpage_shift);
+unsigned int hpage_shift=HPAGE_SHIFT_DEFAULT;
 
 pte_t *
 huge_pte_alloc(struct mm_struct *mm, unsigned long addr, unsigned long sz)

trunk/arch/mips/Kconfig

@@ -3,7 +3,6 @@ config MIPS
 	default y
 	select HAVE_IDE
 	select HAVE_OPROFILE
-	select HAVE_ARCH_KGDB
 	# Horrible source of confusion.  Die, die, die ...
 	select EMBEDDED
 	select RTC_LIB
@@ -35,6 +34,7 @@ config BASLER_EXCITE
 	select SYS_HAS_CPU_RM9000
 	select SYS_SUPPORTS_32BIT_KERNEL
 	select SYS_SUPPORTS_BIG_ENDIAN
+	select SYS_SUPPORTS_KGDB
 	help
 	  The eXcite is a smart camera platform manufactured by
 	  Basler Vision Technologies AG.
@@ -280,6 +280,7 @@ config PMC_MSP
 	select SYS_HAS_CPU_MIPS32_R2
 	select SYS_SUPPORTS_32BIT_KERNEL
 	select SYS_SUPPORTS_BIG_ENDIAN
+	select SYS_SUPPORTS_KGDB
 	select IRQ_CPU
 	select SERIAL_8250
 	select SERIAL_8250_CONSOLE
@@ -305,6 +306,7 @@ config PMC_YOSEMITE
 	select SYS_SUPPORTS_64BIT_KERNEL
 	select SYS_SUPPORTS_BIG_ENDIAN
 	select SYS_SUPPORTS_HIGHMEM
+	select SYS_SUPPORTS_KGDB
 	select SYS_SUPPORTS_SMP
 	help
 	  Yosemite is an evaluation board for the RM9000x2 processor
@@ -357,6 +359,7 @@ config SGI_IP27
 	select SYS_HAS_CPU_R10000
 	select SYS_SUPPORTS_64BIT_KERNEL
 	select SYS_SUPPORTS_BIG_ENDIAN
+	select SYS_SUPPORTS_KGDB
 	select SYS_SUPPORTS_NUMA
 	select SYS_SUPPORTS_SMP
 	select GENERIC_HARDIRQS_NO__DO_IRQ
@@ -472,6 +475,7 @@ config SIBYTE_SWARM
 	select SYS_HAS_CPU_SB1
 	select SYS_SUPPORTS_BIG_ENDIAN
 	select SYS_SUPPORTS_HIGHMEM
+	select SYS_SUPPORTS_KGDB
 	select SYS_SUPPORTS_LITTLE_ENDIAN
 	select ZONE_DMA32 if 64BIT
 
@@ -864,6 +868,7 @@ config SOC_PNX8550
 	select SYS_HAS_EARLY_PRINTK
 	select SYS_SUPPORTS_32BIT_KERNEL
 	select GENERIC_HARDIRQS_NO__DO_IRQ
+	select SYS_SUPPORTS_KGDB
 	select GENERIC_GPIO
 
 config SWAP_IO_SPACE

trunk/arch/mips/Kconfig.debug

@@ -34,6 +34,28 @@ config SMTC_IDLE_HOOK_DEBUG
 	  arch/mips/kernel/smtc.c.  This debugging option result in significant
 	  overhead so should be disabled in production kernels.
 
+config KGDB
+	bool "Remote GDB kernel debugging"
+	depends on DEBUG_KERNEL && SYS_SUPPORTS_KGDB
+	select DEBUG_INFO
+	help
+	  If you say Y here, it will be possible to remotely debug the MIPS
+	  kernel using gdb. This enlarges your kernel image disk size by
+	  several megabytes and requires a machine with more than 16 MB,
+	  better 32 MB RAM to avoid excessive linking time. This is only
+	  useful for kernel hackers. If unsure, say N.
+
+config SYS_SUPPORTS_KGDB
+	bool
+
+config GDB_CONSOLE
+	bool "Console output to GDB"
+	depends on KGDB
+	help
+	  If you are using GDB for remote debugging over a serial port and
+	  would like kernel messages to be formatted into GDB $O packets so
+	  that GDB prints them as program output, say 'Y'.
+
 config SB1XXX_CORELIS
 	bool "Corelis Debugger"
 	depends on SIBYTE_SB1xxx_SOC